linux/drivers, branch v2.6.15.3

[PATCH] Fix mkiss locking bug

2006-01-31T06:13:18Z

ax_encaps() forgot to drop the bufferlock at the end of the function. Patch is already in 2.6.16-rc1. Signed-off-by: Ralf Baechle DL5RB Signed-off-by: Greg Kroah-Hartman

[PATCH] Fix i2o_scsi oops on abort

2006-01-31T06:13:18Z

>From http://bugzilla.kernel.org/show_bug.cgi?id=5923 When a scsi command failed, an oops would result. Back-to-back SMART queries would make the Seagate drives unhappy. The second SMART query would timeout, and the command would be aborted. From: Markus Lidel Cc: Kenny Simpson Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman

[PATCH] Input: HID - fix an oops in PID initialization code

2006-01-31T06:13:17Z

Input: HID - fix an oops in PID initialization code Signed-off-by: Dmitry Torokhov Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] Kill blk_attempt_remerge()

2006-01-31T06:13:17Z

[BLOCK] Kill blk_attempt_remerge() It's a broken interface, it's done way too late. And apparently it triggers slab problems in recent kernels as well (most likely after the generic dispatch code was merged). So kill it, ide-cd is the only user of it. Signed-off-by: Jens Axboe chrisw: backport to 2.6.15 tree Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] moxa serial: add proper capability check

2006-01-15T06:15:30Z

This requires the proper capabilities for the moxa bios update ioctl's. Signed-off-by: Alan Cox Signed-off-by: Linus Torvalds Signed-off-by: Chris Wright

[PATCH] vgacon: fix doublescan mode

2006-01-15T06:15:28Z

When doublescan mode is in use, scanlines must be doubled. Thanks to Jason Dravet for reporting and testing. Signed-off-by: Samuel Thibault Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Wright

[PATCH] Fix onboard video on SPARC Blade 100 for 2.6.{13,14,15}

2006-01-15T06:15:27Z

I have recently been switching from using 2.4.32 on my trusty old Sparc Blade 100 to using 2.6.15 . Some of the problems I ran into were distorted video when the console was active (missing first character, skipped dots) and when running X windows (colored snow, stripes, missing pixels). A quick examination of the 2.6 versus 2.4 source for the ATY driver revealed alot of changes. A closer look at the code/data for the 64GR/XL chip revealed two minor "typos" that the rewriter(s) of the code made. The first is a incorrect clock value (230 .vs. 235) and the second is a missing flag (M64F_SDRAM_MAGIC_PLL). Making both these changes seems to have fixed my problem. I tend to think the 235 value is the correct one, as there is a 29.4 Mhz clock crystal close to the video chip and 235.2 (29.4*8) is too close to 235 to make it a coincidence. The flag for M64F_SDRAM_MAGIC_PLL was dropped during the changes made by adaplas in file revision 1.72 on the old bitkeeper repository. The change relating to the clock rate has been there forever, at least in the 2.6 tree. I'm not sure where to look for the old 2.5 tree or if anyone cares when it happened. On SPARC Blades 100's, which use the ATY MACH64GR video chipset, the clock crystal frequency is 235.2 Mhz, not 230 Mhz. The chipset also requires the use of M64F_SDRAM_MAGIC_PLL in order to setup the PLL properly for the DRAM. Signed-off-by: Luis F. Ortiz Signed-off-by: David S. Miller Signed-off-by: Chris Wright

[PATCH] skge: handle out of memory on ring changes

2006-01-15T06:15:27Z

Please consider this for 2.6.15.1; it fixes several cases where the skge driver can get in a bad state and later crash; if an admin operation that causes a restart fails from out of memory. Such as changing the MTU or increasing the ring size. The fixes involve checking the return value and doing necessary unwinds. Or in some cases avoiding doing a full restart. The same code is the netdev-2.6 tree for 2.6.16 but as separate pieces Signed-off-by: Stephen Hemminger Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

[PATCH] powerpc: more g5 overtemp problem fix

2006-01-02T16:38:37Z

Some G5s still occasionally experience shutdowns due to overtemp conditions despite the recent fix. After analyzing logs from such machines, it appears that the overtemp code is a bit too quick at shutting the machine down when reaching the critical temperature (tmax + 8) and doesn't leave the fan enough time to actually cool it down. This happens if the temperature of a CPU suddenly rises too high in a very short period of time, or occasionally on boot (that is the CPUs are already overtemp by the time the driver loads). This patches makes the code a bit more relaxed, leaving a few seconds to the fans to do their job before kicking the machine shutown. Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Linus Torvalds

Merge master.kernel.org:/home/rmk/linux-2.6-serial

2005-12-31T21:49:26Z