linux/include, branch v2.6.25.16

x86: fix spin_is_contended()

2008-08-20T18:15:47Z

commit 7bc069c6bc4ede519a7116be1b9e149a1dbf787a upstream The masked difference is what needs to be compared against 1, rather than the difference of masked values (which can be negative). Signed-off-by: Jan Beulich Acked-by: Nick Piggin Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

radeon: misc corrections

2008-08-20T18:15:43Z

Commit efc491814308f89d5ef6c4fe19ae4552a67d4132 upstream radeon: misc corrections I have a new PCI-E radeon RV380 series card (PCI device ID 5b64) that hangs in my sparc64 boxes when the init scripts set the font. The problem goes away if I disable acceleration. I haven't figured out that bug yet, but along the way I found some corrections to make based upon some auditing. 1) The RB2D_DC_FLUSH_ALL value used by the kernel fb driver and the XORG video driver differ. I've made the kernel match what XORG is using. 2) In radeonfb_engine_reset() we have top-level code structure that roughly looks like: if (family is 300, 350, or V350) do this; else do that; ... if (family is NOT 300, OR family is NOT 350, OR family is NOT V350) do another thing; this last conditional makes no sense, is always true, and obviously was likely meant to be "family is NOT 300, 350, or V350". So I've made the code match the intent. Signed-off-by: David S. Miller Acked-by: Benjamin Herrenschmidt Tested-by: Benjamin Herrenschmidt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

sparc64: FUTEX_OP_ANDN fix

2008-08-20T18:15:29Z

[ Upstream commit d72609e17fd93bb2f7e0f7e1bdc70b6d20e43843 ] Correct sparc64's implementation of FUTEX_OP_ANDN to do a bitwise negate of the oparg parameter before applying the AND operation. All other archs that support FUTEX_OP_ANDN either negate oparg explicitly (frv, ia64, mips, sh, x86), or do so indirectly by using an and-not instruction (powerpc). Since sparc64 has and-not, I chose to use that solution. I've not found any use of FUTEX_OP_ANDN in glibc so the impact of this bug is probably minor. But other user-space components may try to use it so it should still get fixed. Signed-off-by: Mikael Pettersson Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

radeonfb: fix accel engine hangs

2008-08-20T18:15:24Z

commit 969830b2fedf8336c41d6195f49d250b1e166ff8 upstream Some chips appear to have the 2D engine hang during screen redraw, typically in a sequence of copyarea operations. This appear to be solved by adding a flush of the engine destination pixel cache and waiting for the engine to be idle before issuing the accel operation. The performance impact seems to be fairly small. Here is a trace on an RV370 (PCI device ID 0x5b64), it records the RBBM_STATUS register, then the source x/y, destination x/y, and width/height used for the copy: ---------------------------------------- radeonfb_prim_copyarea: STATUS[00000140] src[210:70] dst[210:60] wh[a0:10] radeonfb_prim_copyarea: STATUS[00000140] src[2b8:70] dst[2b8:60] wh[88:10] radeonfb_prim_copyarea: STATUS[00000140] src[348:70] dst[348:60] wh[40:10] radeonfb_prim_copyarea: STATUS[80020140] src[390:70] dst[390:60] wh[88:10] radeonfb_prim_copyarea: STATUS[8002613f] src[40:80] dst[40:70] wh[28:10] radeonfb_prim_copyarea: STATUS[80026139] src[a8:80] dst[a8:70] wh[38:10] radeonfb_prim_copyarea: STATUS[80026133] src[e8:80] dst[e8:70] wh[80:10] radeonfb_prim_copyarea: STATUS[8002612d] src[170:80] dst[170:70] wh[30:10] radeonfb_prim_copyarea: STATUS[80026127] src[1a8:80] dst[1a8:70] wh[8:10] radeonfb_prim_copyarea: STATUS[80026121] src[1b8:80] dst[1b8:70] wh[88:10] radeonfb_prim_copyarea: STATUS[8002611b] src[248:80] dst[248:70] wh[68:10] ---------------------------------------- When things are going fine the copies complete before the next ROP is even issued, but all of a sudden the 2D unit becomes active (bit 17 in RBBM_STATUS) and the FIFO retry (bit 13) and FIFO pipeline busy (bit 14) are set as well. The FIFO begins to backup until it becomes full. What happens next is the radeon_fifo_wait() times out, and we access the chip illegally leading to a bus error which usually wedges the box. None of this makes it to the console screen, of course :-) radeon_fifo_wait() should be modified to reset the accelerator when this timeout happens instead of programming the chip anyways. ---------------------------------------- radeonfb: FIFO Timeout ! ERROR(0): Cheetah error trap taken afsr[0010080005000000] afar[000007f900800e40] TL1(0) ERROR(0): TPC[595114] TNPC[595118] O7[459788] TSTATE[11009601] ERROR(0): TPC ERROR(0): M_SYND(0), E_SYND(0), Privileged ERROR(0): Highest priority error (0000080000000000) "Bus error response from system bus" ERROR(0): D-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] ERROR(0): D-cache data0[0000000000000000] data1[0000000000000000] data2[0000000000000000] data3[0000000000000000] ERROR(0): I-cache idx[0] tag[0000000000000000] utag[0000000000000000] stag[0000000000000000] u[0000000000000000] l[00\ ERROR(0): I-cache INSN0[0000000000000000] INSN1[0000000000000000] INSN2[0000000000000000] INSN3[0000000000000000] ERROR(0): I-cache INSN4[0000000000000000] INSN5[0000000000000000] INSN6[0000000000000000] INSN7[0000000000000000] ERROR(0): E-cache idx[800e40] tag[000000000e049f4c] ERROR(0): E-cache data0[fffff8127d300180] data1[00000000004b5384] data2[0000000000000000] data3[0000000000000000] Ker:xnel panic - not syncing: Irrecoverable deferred error trap. ---------------------------------------- Another quirk is that these copyarea calls will not happen until the first drivers/char/vt.c:redraw_screen() occurs. This will only happen if you 1) VC switch or 2) run "consolechars" or 3) unblank the screen. This seems to happen because until a redraw_screen() the screen scrolling method used by fbcon is not finalized yet. I've seen this with other fb drivers too. So if all you do is boot straight into X you will never see this bug on the relevant chips. Signed-off-by: David S. Miller Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

usb-serial: don't release unregistered minors

2008-08-20T18:15:20Z

commit 0282b7f2a874e72c18fcd5a112ccf67f71ba7f5c upstream This patch (as1121) fixes a bug in the USB serial core. When a device is unregistered, the core will give back its minors -- even if the device hasn't been assigned any! The patch reserves the highest minor value (255) to mean that no minor was assigned. It also removes some dead code and does a small style fixup. Signed-off-by: Alan Stern Signed-off-by: Greg Kroah-Hartman

ALSA: emu10k1 - Fix inverted Analog/Digital mixer switch on Audigy2

2008-08-06T17:11:06Z

commit d2cd74b158d7214a556226e3312f9fb1de64d7ae upstream On Audigy2 Platinum, the Analog/Digital mixer switch is inverted. https://bugzilla.novell.com/show_bug.cgi?id=396204 The patch adds a simple workaround. There might be another device requiring a similar fix, too (or fix for audigy2 generically), but right now I fix only the known broken one. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

ALSA: ac97 - Fix ASUS A9T laptop output

2008-08-06T17:11:06Z

commit e48d6d97bb6bd8c008045ea0522ea8278fdccc55 upstream ASUS A9T laptop uses line-out pin as the real front-output while other devices use it as the surround. Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

FAT_VALID_MEDIA(): remove pointless test

2008-08-06T17:11:01Z

commit 73f20e58b1d586e9f6d3ddc3aad872829aca7743 upstream The on-disk media specification field in FAT is only 8-bits, so testing for <=0xff is pointless, and can generate a "comparison is always true due to limited range of data type" warning. While we're there, convert FAT_VALID_MEDIA() into a C function - the present implementation is buggy: it generates either one or two references to its argument. Cc: Frank Seidel Acked-by: OGAWA Hirofumi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Correct hash flushing from huge_ptep_set_wrprotect()

2008-08-01T18:51:01Z

Correct hash flushing from huge_ptep_set_wrprotect() [stable tree version] A fix for incorrect flushing of the hash page table at fork() for hugepages was recently committed as 86df86424939d316b1f6cfac1b6204f0c7dee317. Without this fix, a process can make a MAP_PRIVATE hugepage mapping, then fork() and have writes to the mapping after the fork() pollute the child's version. Unfortunately this bug also exists in the stable branch. In fact in that case copy_hugetlb_page_range() from mm/hugetlb.c calls ptep_set_wrprotect() directly, the hugepage variant hook huge_ptep_set_wrprotect() doesn't even exist. The patch below is a port of the fix to the stable25/master branch. It introduces a huge_ptep_set_wrprotect() call, but this is #defined to be equal to ptep_set_wrprotect() unless the arch defines its own version and sets __HAVE_ARCH_HUGE_PTEP_SET_WRPROTECT. This arch preprocessor flag is kind of nasty, but it seems the sanest way to introduce this fix with minimum risk of breaking other archs for whom prep_set_wprotect() is suitable for hugepages. Signed-off-by: Andy Whitcroft Signed-off-by: David Gibson Signed-off-by: Greg Kroah-Hartman

cpufreq acpi: only call _PPC after cpufreq ACPI init funcs got called already

2008-08-01T18:50:58Z

commit a1531acd43310a7e4571d52e8846640667f4c74b upstream Ingo Molnar provided a fix to not call _PPC at processor driver initialization time in "[PATCH] ACPI: fix cpufreq regression" (git commit e4233dec749a3519069d9390561b5636a75c7579) But it can still happen that _PPC is called at processor driver initialization time. This patch should make sure that this is not possible anymore. Signed-off-by: Thomas Renninger Cc: Andi Kleen Cc: Len Brown Cc: Dave Jones Cc: Ingo Molnar Cc: Venkatesh Pallipadi Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman