ChangeSet@1.1560, 2004-12-03 22:12:07-02:00, mingo@elte.hu [PATCH] floppy boot-time detection fix found the bug that causes the fd detection failure. It's a generic race in the upstream floppy driver, which happens to work by chance in the vanilla kernel but breaks when IRQ and softirq threading is enabled: when the FDC hardware is initialized, it sometimes generates a floppy interrupt right away - without being told to. This interrupt can hit the detection code that executes right after the initialization code, in particular it can get intermixed with user_reset_fdc() that the detection code uses. The fd driver is fundamentally single-threaded when it comes to handling events: an unexpected irq that arrives in the wrong moment can confuse the reset_fdc() code, which, with softirq and hardirq threading on, executes in keventd. in the stock kernel this stale irq doesnt seem to hit the detection code in the wrong moment, but i think under certain circumstances it may still happen. One of the typical incarnations of the race was the following message: reset set in interrupt, calling c0258400 and googling for "reset set in interrupt, calling" does turn up a fair number of bootlogs (most of them 2.4 ones) that show such a detection failure, so i think upstream wants to have the fix too. the fix is simple: delay a bit after initialization, to make sure the stale irq does not interfere with the detection code. It will be safely ignored, since do_floppy is still NULL. It might look sloppy that i went for a delay, but delay i think it is better than waiting for the irq to occur, because i dont think there's a guarantee that fdc initialization triggers an interrupt, so waiting for it could hang the boot process. A delay OTOH is totally harmless. The attached patch implements this fix, which resolves the detection problem on my testbox. here's again how a failure looks like: Floppy drive(s): fd0 is 1.44M reset set in interrupt, calling c0258400 floppy0: no floppy controllers found and this is how it works with the fix: Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 i've tested this on vanilla 2.6.10-rc2-mm3 too (to make sure this doesnt break the floppy driver), and it should work fine in -BK too. (this does not solve the irq threading related SMP lockup though, i'm attacking that problem next - now that my fd0 gets detected fine ;-) ) Ingo Signed-off-by: Ingo Molnar ChangeSet@1.1559, 2004-12-03 21:23:44-02:00, rddunlap@osdl.org [PATCH] Fix unresolved symbol on x86-64: export swiotlb > When modprobing any of the modules I get: > unresolved symbol swiotlb Looks like it just needs 'swiotlb' exported (as in 2.6.x). ChangeSet@1.1558, 2004-12-03 21:08:19-02:00, marcelo@dmt.cyclades backport v2.6 fork/thread file descriptor race fix ChangeSet@1.1557, 2004-12-02 17:16:08-02:00, kronos@people.it [PATCH] Add new PCI id to radeonfb Hi Marcelo, this is a trivial patch for 2.4.29-pre1. Add support for the following radeon board (thanks to Jurriaan): lspci: 0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV350 AQ [Radeon 9600] 0000:01:00.1 Display controller: ATI Technologies Inc RV350 AQ [Radeon 9600] (Secondary) lspci -n: 0000:01:00.0 Class 0300: 1002:4151 0000:01:00.1 Class 0380: 1002:4171 Signed-off-by: Luca Tettamanti ChangeSet@1.1556, 2004-12-02 10:42:28-02:00, kronos@people.it [PATCH] radeonfb: don't try to ioreamp the entire VRAM Make fb layer aware of the difference between the ioremap()'ed VRAM and total available VRAM. smem_len in struct fb_fix_screeninfo contains the amount of physical VRAM (reported to userspace via FBIOGET_FSCREENINFO ioctl) while the new field mapped_vram in struct fb_info contains the amount of VRAM actually ioremap()'ed by drivers (used in read/write/mmap operations). If mapped_vram is not set it's assumed that the entire framebuffer is mapped, thus other drivers are unaffected by this patch. Signed-off-by: Luca Tettamanti ChangeSet@1.1555, 2004-12-01 08:59:24-02:00, marcelo@dmt.cyclades Cset exclude: vince@arm.linux.org.uk|ChangeSet|20041125151649|65331 ChangeSet@1.1554, 2004-11-30 15:04:16-02:00, chrisw@osdl.org [PATCH] proc_tty.c warning fix > The /proc/tty/driver/serial vulnerability fix in 2.4.29-pre1 > calls a function without a prototype in scope, resulting in: > > proc_tty.c: In function `proc_tty_init': > proc_tty.c:183: warning: implicit declaration of function `proc_mkdir_mode' > proc_tty.c:183: warning: assignment makes pointer from integer without a cast Yes, oversight, please apply. Well, here's an insignificant variation which comes straight from 2.6 to minimize divergence. ===== include/linux/proc_fs.h 1.10 vs edited ===== ChangeSet@1.1553, 2004-11-30 15:01:31-02:00, bunk@stusta.de [PATCH] add missing SCSI_SATA_AHCI Configure.help entry Could you introduce a penalty for people forgetting the Configure.help entry when adding a new option? ;-) Signed-off-by: Adrian Bunk ChangeSet@1.1552, 2004-11-30 14:48:35-02:00, cp@absolutedigital.net [PATCH] remove obsolete PIIX config help Hi Marcelo, The patch below removes some obsolete config help for the Intel PIIX chipsets. Signed-off-by: Cal Peake ChangeSet@1.1551, 2004-11-30 12:39:13-02:00, bunk@stusta.de [PATCH] remove bouncing email address of Deanna Bonds On Mon, Nov 29, 2004 at 08:27:39AM -0500, Salyzyn, Mark wrote: > That address should instead become aacraid@adaptec.com to capture > engineers at Adaptec. Sounds reasonable. Updated patch below. > Sincerely -- Mark Salyzyn diffstat output: drivers/scsi/aacraid/README | 2 +- drivers/scsi/dpt/dpti_ioctl.h | 2 +- drivers/scsi/dpt_i2o.c | 2 +- drivers/scsi/dpti.h | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) Signed-off-by: Adrian Bunk ChangeSet@1.1550, 2004-11-30 12:33:21-02:00, tv@lio96.de [PATCH] VM documentation fix: vm_anon_lru default is 0 > o Marc-Christian Petersen: VM documentation update Here is a typo. /proc/sys/vm/vm_anon_lru is default 0 ChangeSet@1.1549, 2004-11-25 17:46:49-02:00, marcelo@logos.cnet fix get_user_pages() change typo TAG: v2.4.29-pre1