ChangeSet@1.1527, 2004-12-08 19:28:12-02:00, bunk@stusta.de [PATCH] let SCSI_SATA_NV depend on EXPERIMENTAL Jeff, Mike Castle noticed that CONFIG_SCSI_SATA_NV in 2.4 is marked as "(EXPERIMENTAL)", but doesn't depend on EXPERIMENTAL. Since it depends on EXPERIMENTAL in 2.6, I'd sugget the patch below to add this dependency in 2.4, too. Signed-off-by: Adrian Bunk ChangeSet@1.1526, 2004-12-08 19:27:11-02:00, bunk@stusta.de [PATCH] USB_ETH{,_RNDIS} EXPERIMENTAL dependencies Mike Castle noted that USB_ETH and USB_ETH_RNDIS in 2.4 are marked as "(EXPERIMENTAL)", but don't depend on EXPERIMENTAL. The patch below removes the "(EXPERIMENTAL)" string from USB_ETH and lets USB_ETH_RNDIS depend on EXPERIMENTAL. This is similar to the dependencies 2.6 . Signed-off-by: Adrian Bunk ChangeSet@1.1521.1.2, 2004-12-08 19:10:01-02:00, alexn@dsv.su.se [PATCH] Correct /dev/mptctl major number in Configure.help Hi! Apparently the real minor of /dev/mptctl according to devices.txt is 220, better late than never huh? :) ChangeSet@1.1516.6.3, 2004-12-08 13:33:08-08:00, davem@nuts.davemloft.net [NET]: CMSG compat code needs signedness fixes too. Signed-off-by: David S. Miller ChangeSet@1.1516.6.2, 2004-12-08 13:13:56-08:00, herbert@gondor.apana.org.au [NET]: Fix CMSG validation checks wrt. signedness. Noticed by Georgi Guninski. Signed-off-by: Herbert Xu Signed-off-by: David S. Miller ChangeSet@1.1516.6.1, 2004-12-08 12:40:30-08:00, davem@nuts.davemloft.net [IPV4]: Do not leak IP options. If the user makes ip_cmsg_send call ip_options_get multiple times, we leak kmalloced IP options data. Noticed by Georgi Guninski. Signed-off-by: David S. Miller ChangeSet@1.1524, 2004-12-07 19:26:27-05:00, dougg@torque.net [PATCH] off-by-1 libata-scsi INQUIRY VPD pages 0x80 and 0x83 I have some code (in sginfo) that requests the first 4 bytes of SCSI INQUIRY VPD pages to get their length then asks for that exact length in a follow up request to fetch the payload. Just like I saw with 36 byte standard INQUIRYs (no fixed) I get a buffer full or zeroes. BTW SCSI standards dictate that in situations where the allocation length (in the cdb) is less than what is needed that what can be sent shall be sent (i.e. truncated and without any error indication or modification to the part of the response returned). In other words it is up the the application client to take remedial action. Changelog: - fix off-by-1 allocation length issue with SCSI INQUIRY VPD pages 0x80 and 0x83 Signed-off-by: Jeff Garzik ChangeSet@1.1523, 2004-12-07 19:14:44-05:00, jgarzik@pobox.com [libata] only DMA map data for DMA commands (fix >=4GB bug) libata made the assumption that (for PIO commands in this case) it could modify DMA memory at the kernel-virtual address, after mapping this. This is incorrect, and fails on e.g. platforms that copy DMA memory back and forth (swiotlb on Intel EM64T and IA64). Remove this assumption by ensuring that we only call the DMA mapping routines if we really are going to use DMA for data xfer. Also: remove a bogus WARN_ON() in ata_sg_init_one() which caused bug reports (but no problems). ChangeSet@1.1520, 2004-12-03 20:43:03-08:00, davem@nuts.davemloft.net [SPARC64]: Fix SMP cpu bringup bug when bigkernel. We have to load the bigkernel second TLB entry on secondary processors before we move over the use the kernel trap table. Otherwise we can take a TLB miss somewhere in the post-4MB area and the TLB handler is not prepared to service that. The case that usually occurs is the prom_set_trap_table call made by trampoline.S, since p1275buf usually sits very near the end of the kernel image. It worked by luck most of the time as long as p1275buf sits within a single page since earlier code running in trampoline.S forced that TLB entry to be loaded by the OBP TLB miss handler. This was not fun to figure out. Signed-off-by: David S. Miller ChangeSet@1.1519, 2004-12-03 16:17:53-08:00, davem@nuts.davemloft.net [SPARC64]: Update defconfig. ChangeSet@1.1516.4.5, 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.1516.4.4, 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.1516.4.3, 2004-12-03 21:08:19-02:00, marcelo@dmt.cyclades backport v2.6 fork/thread file descriptor race fix ChangeSet@1.1458.1.9, 2004-12-02 21:08:56-05:00, len.brown@intel.com [ACPI] acpi=off must disable acpi_early_init() Signed-off-by: Philippe Troin Signed-off-by: Len Brown ChangeSet@1.1516.4.2, 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.1516.4.1, 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.1516.1.39, 2004-12-01 08:59:24-02:00, marcelo@dmt.cyclades Cset exclude: vince@arm.linux.org.uk|ChangeSet|20041125151649|65331 ChangeSet@1.1516.1.38, 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.1516.1.37, 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.1516.1.36, 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.1516.1.35, 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.1516.1.34, 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.1516.1.33, 2004-11-25 17:46:49-02:00, marcelo@logos.cnet fix get_user_pages() change typo TAG: v2.4.29-pre1