linux/drivers, branch v2.6.19.4

[PATCH] jmicron: 40/80pin primary detection

2007-02-05T16:31:44Z

jmicron module detects all JMB36x as JMB361 and PATA0 has wrong pin status of XICBLID. Cc: Jeff Garzik Cc: Alan Cox Cc: Bartlomiej Zolnierkiewicz Cc: Sergei Shtylyov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds cebbert@redhat.com: I folded in the warning fix (a51545ab25) because otherwise it makes the tester think the patch caused the warning that was already there. Cc: Dave Jones Signed-off-by: Chuck Ebbert Signed-off-by: Chris Wright

[PATCH] bonding: ARP monitoring broken on x86_64

2007-02-05T16:31:44Z

While working with the latest bonding code I noticed a nasty problem that will prevent arp monitoring from always functioning correctly on x86_64 systems. Comparing ints to longs and expecting reliable results on x86_64 is a bad idea. With this patch, arp monitoring works correctly again. Signed-off-by: Andy Gospodarek Cc: "David S. Miller" Cc: Stephen Hemminger Cc: Jeff Garzik Signed-off-by: Andrew Morton Signed-off-by: Jeff Garzik Signed-off-by: Chris Wright

[PATCH] libata: use kmap_atomic(KM_IRQ0) in SCSI simulator

2007-02-05T16:31:44Z

We are inside spin_lock_irqsave(). quoth akpm's debug facility: [ 231.948000] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB) [ 232.232000] ata1.00: configured for UDMA/33 [ 232.404000] WARNING (1) at arch/i386/mm/highmem.c:47 kmap_atomic() [ 232.404000] [] kmap_atomic+0xa9/0x1ab [ 232.404000] [] ata_scsi_rbuf_get+0x1c/0x30 [ 232.404000] [] ata_scsi_rbuf_fill+0x1a/0x87 [ 232.404000] [] ata_scsiop_mode_sense+0x0/0x309 [ 232.404000] [] end_bio_bh_io_sync+0x0/0x37 [ 232.404000] [] scsi_done+0x0/0x16 [ 232.404000] [] scsi_done+0x0/0x16 [ 232.404000] [] ata_scsi_simulate+0xb0/0x13f [...] Signed-off-by: Jeff Garzik Cc: Andrew Morton Signed-off-by: Chris Wright

[PATCH] md: fix potential memalloc deadlock in md

2007-02-05T16:31:43Z

If a GFP_KERNEL allocation is attempted in md while the mddev_lock is held, it is possible for a deadlock to eventuate. This happens if the array was marked 'clean', and the memalloc triggers a write-out to the md device. For the writeout to succeed, the array must be marked 'dirty', and that requires getting the mddev_lock. So, before attempting a GFP_KERNEL alloction while holding the lock, make sure the array is marked 'dirty' (unless it is currently read-only). Signed-off-by: Neil Brown Signed-off-by: Chris Wright

[PATCH] md: fix a few problems with the interface (sysfs and ioctl) to md.

2007-02-05T16:31:43Z

While developing more functionality in mdadm I found some bugs in md... - When we remove a device from an inactive array (write 'remove' to the 'state' sysfs file - see 'state_store') would should not update the superblock information - as we may not have read and processed it all properly yet. - initialise all raid_disk entries to '-1' else the 'slot sysfs file will claim '0' for all devices in an array before the array is started. - all '\n' not to be present at the end of words written to sysfs files - when we use SET_ARRAY_INFO to set the md metadata version, set the flag to say that there is persistant metadata. - allow GET_BITMAP_FILE to be called on an array that hasn't been started yet. Signed-off-by: Neil Brown Signed-off-by: Chris Wright

[PATCH] md: make 'repair' actually work for raid1.

2007-02-05T16:31:43Z

When 'repair' finds a block that is different one the various parts of the mirror. it is meant to write a chosen good version to the others. However it currently writes out the original data to each. The memcpy to make all the data the same is missing. Signed-off-by: Neil Brown Signed-off-by: Chris Wright

[PATCH] md: assorted md and raid1 one-liners

2007-02-05T16:31:43Z

Fix few bugs that meant that: - superblocks weren't alway written at exactly the right time (this could show up if the array was not written to - writting to the array causes lots of superblock updates and so hides these errors). - restarting device recovery after a clean shutdown (version-1 metadata only) didn't work as intended (or at all). 1/ Ensure superblock is updated when a new device is added. 2/ Remove an inappropriate test on MD_RECOVERY_SYNC in md_do_sync. The body of this if takes one of two branches depending on whether MD_RECOVERY_SYNC is set, so testing it in the clause of the if is wrong. 3/ Flag superblock for updating after a resync/recovery finishes. 4/ If we find the neeed to restart a recovery in the middle (version-1 metadata only) make sure a full recovery (not just as guided by bitmaps) does get done. Signed-off-by: Neil Brown Signed-off-by: Chris Wright

[PATCH] sis190: failure to set the MAC address from EEPROM

2007-02-05T16:31:43Z

Fix from http://bugzilla.kernel.org/show_bug.cgi?id=7747 Signed-off-by: Andrew Morton Cc: Signed-off-by: Francois Romieu Signed-off-by: Jeff Garzik Signed-off-by: Chris Wright

[PATCH] remove __devinit markings from rtc_sysfs_add_device()

2007-02-05T16:31:42Z

rtc_sysfs_add_device is needed even after dev initialization, so drop __devinit. Signed-off-by: Mike Frysinger Acked-by: Alessandro Zummo Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] Revert "[PATCH] Fix up mmap_kmem"

2007-02-05T16:31:42Z

This reverts commit 99a10a60ba9bedcf5d70ef81414d3e03816afa3f. As per Hugh Dickins: "Nadia Derbey has reported that mmap of /dev/kmem no longer works with the kernel virtual address as offset, and Franck has confirmed that his patch came from a misunderstanding of what an offset means to /dev/kmem - whereas his patch description seems to say that he was correcting the offset on a few plaforms, there was no such problem to correct, and his patch was in fact changing its API on all platforms." Suggested-by: Hugh Dickins Cc: Franck Bui-Huu Cc: Nadia Derbey Cc: Andi Kleen Cc: Arjan van de Ven Cc: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright