Linus Torvalds [Fri, 17 Nov 2006 19:14:56 +0000 (11:14 -0800)]
x86: be more careful when walking back the frame pointer chain
When showing the stack backtrace, make sure that we never accept not
only an unchanging frame pointer, but also a frame pointer that moves
back down the stack frame. It must always grow up (toward older stack
frames).
I doubt this has triggered, but a subtly corrupt stack with extremely
unlucky contents could cause us to loop forever on a bogus endless frame
pointer chain.
This review was triggered by much worse problems happening in some of
the other stack unwinding code.
Steven Rostedt found the bug: static_obj() check did not take
PERCPU_ENOUGH_ROOM into account, so in-module DEFINE_PER_CPU-area locks
were triggering this message.
Ingo Molnar [Fri, 17 Nov 2006 13:26:18 +0000 (14:26 +0100)]
[PATCH] i386/x86_64: ACPI cpu_idle_wait() fix
The scheduler on Andreas Friedrich's hyperthreading system stopped
working properly: the scheduler would never move tasks to another CPU!
The lask known working kernel was 2.6.8.
After a couple of attempts to corner the bug, the following smoking gun
was found:
a quick look at cpu_idle_wait() shows how broken that code is
on i386: it changes the init task's affinity map but never
restores it ...
and because all userspace tasks get forked by init, they all
inherited that single-CPU affinity mask. x86_64 cloned this
bug too.
Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Andreas Friedrich <andreas.friedrich@fujitsu-siemens.com> Cc: Wolfgang Erig <Wolfgang.Erig@fujitsu-siemens.com> Cc: Andrew Morton <akpm@osdl.org> Cc: Adrian Bunk <bunk@stusta.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
this crash happened because it did not sanitize the dwarf2 data it
got, and got an unaligned stack pointer - which happily walked past
the process stack (and eventually reached the end of kernel memory
and pagefaulted there) due to this naive iteration condition:
Linus Torvalds [Fri, 17 Nov 2006 06:18:28 +0000 (22:18 -0800)]
Fix generic fb_ddc i2c edid probe msg
Benh points out that the msgs[0].flags entry never got initialized, and
since it's an automatic stack allocation, it could have any random
value, which is bad.
Rewrite the initializer to explicitly initialize all fields of the small
i2c_msg structure array we generate. Just to keep it all obvious, let's
handle msgs[1].buf in the same initializer while we're at it, instead of
initializing that one separately later.
When radeonfb was changed to use the new "generic" ddc, a bit of
code initializing the GPIO lines was lost, causing it to not work
if the firmware didn't configure them properly, which seems to
happen on some cards.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6:
aoe: Add forgotten NULL at end of attribute list in aoeblk.c
debugfs: check return value correctly
W1: ioremap balanced with iounmap
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6:
USB: auerswald possible memleak fix
USB: ipaq: Add HTC Modem Support
USB: Fixed outdated usb_get_device_descriptor() documentation
usb-storage: Remove duplicated unusual_devs.h entries for Sony Ericsson P990i
USB: hid-core: Add quirk for new Apple keyboard/trackpad
USB Storage: unusual_devs.h entry for Sony Ericsson P990i
USB: correct keymapping on Powerbook built-in USB ISO keyboards
USB: OHCI: fix root-hub resume bug
USB: Fix UCR-61S2B unusual_dev entry
USB: ftdi driver pid for dmx-interfaces
USB: ftdi_sio: adds vendor/product id for a RFID construction kit
OHCI: disallow autostop when wakeup is not available
usb_get_device_descriptor() used to convert several descriptor fields to host
CPU's byte order. Now that it doesn't convert them anymore, update the
documentation to reflect this.
Sergey Vlasov [Mon, 6 Nov 2006 13:33:07 +0000 (16:33 +0300)]
usb-storage: Remove duplicated unusual_devs.h entries for Sony Ericsson P990i
For some reason the unusual_devs.h entry for Sony Ericsson P990i had
three identical copies in a wrong place in the file in addition to the
correct entry.
Olaf Hering [Thu, 9 Nov 2006 03:58:07 +0000 (19:58 -0800)]
USB: correct keymapping on Powerbook built-in USB ISO keyboards
similar to the version in adbhid_input_register(): The '<>' key and the
'^°' key on a german keyboard is swapped. Provide correct keys to
userland, external USB keyboards will not work correctly when the
'badmap'/'goodmap' workarounds from xkeyboard-config are used.
It is expected that distributions drop the badmap/goodmap part from
keycodes/macintosh in the xkeyboard-config package.
This is probably 2.6.18.x material, if major distros settle on 2.6.18.
Signed-off-by: Olaf Hering <olh@suse.de> Cc: Dmitry Torokhov <dtor@mail.ru> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Alan Stern [Tue, 24 Oct 2006 16:04:22 +0000 (12:04 -0400)]
USB: OHCI: fix root-hub resume bug
When a suspended OHCI controller sees a port's status change, it sets
both the Root-Hub-Status-Change and the Resume-Detect bits in the
Interrupt Status register. Processing both these bits, the driver
tries to resume the root hub twice!
This patch (as807) fixes the bug by ignoring RD if RHSC is set. It
also prints a slightly more informative log message when a
remote-wakeup event occurs.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Phil Dibowitz [Fri, 3 Nov 2006 07:14:10 +0000 (23:14 -0800)]
USB: Fix UCR-61S2B unusual_dev entry
Recently this entry's bcd scope was narrowed so as not to falsly apply
to bcd's other than 0x0110. But while it breaks those of a larger bcd,
it is still needed for those of a smaller bcd - so this changes the
lower bcd limit to 0x0000.
Signed-off-by: Phil Dibowitz <phil@ipom.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
on x86_64, the CONFIG_CC_STACKPROTECTOR build fails if used in a
distcc setup that has "CC" defined to "distcc gcc":
gcc: gcc: linker input file unused because linking not done
gcc: gcc: linker input file unused because linking not done
gcc: gcc: linker input file unused because linking not done
this is because the gcc-x86_64-has-stack-protector.sh script
has a 2-parameters assumption. Fix this by passing $(CC) as
a single parameter.
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
[TG3]: Disable TSO on 5906 if CLKREQ is enabled.
[TCP]: Fix up sysctl_tcp_mem initialization.
[NETFILTER]: ip6_tables: use correct nexthdr value in ipv6_find_hdr()
[NETFILTER]: ip6_tables: fixed conflicted optname for getsockopt
[NETFILTER]: Use pskb_trim in {ip,ip6,nfnetlink}_queue
[NETFILTER]: nfnetlink_log: fix byteorder of NFULA_SEQ_GLOBAL
[TG3]: Increase 5906 firmware poll time.
Linus Torvalds [Thu, 16 Nov 2006 19:44:38 +0000 (11:44 -0800)]
Merge branch 'release' of master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6
* 'release' of master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6:
[IA64] a fix towards allmodconfig build
[IA64] use generic_handle_irq()
[IA64] typename -> name conversion
[IA64] irqs: use `name' not `typename'
[IA64] bte_unaligned_copy() transfers one extra cache line.
Tejun Heo [Thu, 16 Nov 2006 09:19:31 +0000 (01:19 -0800)]
[PATCH] scsi: clear garbage after CDBs on SG_IO
ATAPI devices transfer fixed number of bytes for CDBs (12 or 16). Some
ATAPI devices choke when shorter CDB is used and the left bytes contain
garbage. Block SG_IO cleared left bytes but SCSI SG_IO didn't. This patch
makes SCSI SG_IO clear it and simplify CDB clearing in block SG_IO.
Signed-off-by: Tejun Heo <htejun@gmail.com> Cc: Mathieu Fluhr <mfluhr@nero.com> Cc: James Bottomley <James.Bottomley@steeleye.com> Cc: Douglas Gilbert <dougg@torque.net> Acked-by: Jens Axboe <jens.axboe@oracle.com> Cc: <stable@kernel.org> Acked-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Michael Halcrow [Thu, 16 Nov 2006 09:19:30 +0000 (01:19 -0800)]
[PATCH] eCryptfs: CIFS nlink fixes
When CIFS is the lower filesystem, the old lower dentry needs to be explicitly
dropped from inside eCryptfs to force a revalidate. In addition, when CIFS is
the lower filesystem, the inode attributes need to be copied back up from the
lower inode to the eCryptfs inode on an eCryptfs revalidate.
Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Phillip Susi [Thu, 16 Nov 2006 09:19:23 +0000 (01:19 -0800)]
[PATCH] Update udf documentation to reflect current state of read/write support
Change Documentation/filesystems/udf.txt from saying that read/write mounts
on cd media are not supported to instead state the current level of
support. Specifically that it works fine on dvd+rw media and can be made
to work on cd-rw media via the pktcdvd device.
Cc: Peter Osterlund <petero2@telia.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Michael Halcrow [Thu, 16 Nov 2006 09:19:16 +0000 (01:19 -0800)]
[PATCH] eCryptfs: dput() lower d_parent on rename
On rename, for both the old and new lower dentry objects, eCryptfs is
missing a dput on the lower parent directory dentry. This patch will
prevent the BUG() at fs/dcache.c:613 from being hit after renaming a file
inside eCryptfs and then doing a umount on the lower filesystem.
Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Vitaly Wool [Thu, 16 Nov 2006 09:19:11 +0000 (01:19 -0800)]
[PATCH] pnx4008: rename driver
Make the drivers' names less generic to avoid possible confusion in future,
as was requested by Russell King.
Signed-off-by: Vitaly Wool <vwool@ru.mvista.com> Acked-by: James Simmons <jsimmons@infradead.org> Cc: Russell King <rmk@arm.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The root cause is that some irq_chip variables, especially ia64_msi_chip,
initiate their memeber end to point to NULL. __do_IRQ doesn't check
if irq_chip->end is null and just calls it after processing the interrupt.
As irq_chip->end is called at many places, so I fix it by reinitiating
irq_chip->end to dummy_irq_chip.end, e.g., a noop function.
The root cause is the device struct is initialized twice.
If the device is allocated dynamically by platform_device_alloc,
platform_device_alloc will initialize struct device, then,
platform_device_add should be used to register the device.
The difference between platform_device_register and platform_device_add is
platform_device_register will initiate the device while platform_device_add
won't.
Michael Chan [Thu, 16 Nov 2006 05:14:42 +0000 (21:14 -0800)]
[TG3]: Disable TSO on 5906 if CLKREQ is enabled.
Due to hardware errata, TSO must be disabled if the PCI Express clock
request is enabled on 5906. The chip may hang when transmitting TSO
frames if CLKREQ is enabled.
Update version to 3.69.
Signed-off-by: Michael Chan <mchan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Yasuyuki Kozakai [Wed, 15 Nov 2006 03:48:48 +0000 (19:48 -0800)]
[NETFILTER]: ip6_tables: fixed conflicted optname for getsockopt
66 and 67 for getsockopt on IPv6 socket is doubly used for IPv6 Advanced
API and ip6tables. This moves numbers for ip6tables to 68 and 69.
This also kills XT_SO_* because {ip,ip6,arp}_tables doesn't have so much
common numbers now.
The old userland tools keep to behave as ever, because old kernel always
calls functions of IPv6 Advanced API for their numbers.
Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp> Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Patrick McHardy [Wed, 15 Nov 2006 03:48:09 +0000 (19:48 -0800)]
[NETFILTER]: Use pskb_trim in {ip,ip6,nfnetlink}_queue
Based on patch by James D. Nurmi:
I've got some code very dependant on nfnetlink_queue, and turned up a
large number of warns coming from skb_trim. While it's quite possibly
my code, having not seen it on older kernels made me a bit suspect.
Anyhow, based on some googling I turned up this thread:
http://lkml.org/lkml/2006/8/13/56
And believe the issue to be related, so attached is a small patch to
the kernel -- not sure if this is completely correct, but for anyone
else hitting the WARN_ON(1) in skbuff.h, it might be helpful..
Signed-off-by: James D. Nurmi <jdnurmi@gmail.com>
Ported to ip6_queue and nfnetlink_queue and added return value
checks.
Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Gary Zambrano [Wed, 15 Nov 2006 00:34:00 +0000 (16:34 -0800)]
[TG3]: Increase 5906 firmware poll time.
Newer 5906 bootcode needs about 7ms to finish resetting so the poll
firmware loop was changed to maximum 20ms.
Signed-off-by: Gary Zambrano <zambrano@broadcom.com> Signed-off-by: Michael Chan <mchan@broadcom.com> Acked-by: Jeff Garzik <jeff@garzik.org> Signed-off-by: David S. Miller <davem@davemloft.net>
[PATCH] powerpc: windfarm shall request it's sub modules
The windfarm code, in it's current incarnation, uses request_module() to
load the various submodules it needs for a given platform so that only
the main platform control module needs to be modprobed. However, it was
missing various bits. This fixes it. In the future, we'll use some
hotplug mecanisms to try to get all of this auto-loaded on the platforms
where it matters but that isn't ready yet.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Robin Holt [Wed, 15 Nov 2006 02:50:59 +0000 (20:50 -0600)]
[IA64] bte_unaligned_copy() transfers one extra cache line.
When called to do a transfer that has a start offset within the cache
line which is uneven between source and destination and a length which
terminates the source of the copy exactly on a cache line, one extra
line gets copied into a temporary buffer. This is normally not an issue
since the buffer is a kernel buffer and only the requested information
gets copied into the user buffer.
The problem arises when the source ends at the very last physical page
of memory. That last cache line does not exist and results in the SHUB
chip raising an MCA.
Signed-off-by: Robin Holt <holt@sgi.com> Signed-off-by: Dean Nelson <dcn@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
"Now, edge-triggered interrupts are a _lot_ harder to mask, because the
Intel APIC is an unbelievable piece of sh*t, and has the edge-detect logic
_before_ the mask logic, so if a edge happens _while_ the device is
masked, you'll never ever see the edge ever again (unmasking will not
cause a new edge, so you simply lost the interrupt).
So when you "mask" an edge-triggered IRQ, you can't really mask it at all,
because if you did that, you'd lose it forever if the IRQ comes in while
you masked it. Instead, we're supposed to leave it active, and set a flag,
and IF the IRQ comes in, we just remember it, and mask it at that point
instead, and then on unmasking, we have to replay it by sending a
self-IPI."
This trivial patch solves the problem.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Cc: Ingo Molnar <mingo@redhat.com> Acked-by: Komuro <komurojun-mbn@nifty.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Linus Torvalds [Tue, 14 Nov 2006 23:23:17 +0000 (15:23 -0800)]
Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6
* 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6:
[PATCH] x86-64: Fix race in exit_idle
[PATCH] x86-64: Fix vgetcpu when CONFIG_HOTPLUG_CPU is disabled
[PATCH] x86: Add acpi_user_timer_override option for Asus boards
[PATCH] x86-64: setup saved_max_pfn correctly (kdump)
[PATCH] x86-64: Handle reserve_bootmem_generic beyond end_pfn
[PATCH] x86-64: shorten the x86_64 boot setup GDT to what the comment says
[PATCH] x86-64: Fix PTRACE_[SG]ET_THREAD_AREA regression with ia32 emulation.
[PATCH] x86-64: Fix partial page check to ensure unusable memory is not being marked usable.
Revert "[PATCH] MMCONFIG and new Intel motherboards"
Sergey Vlasov points out (and Vadim Lobanov concurs) that the bug it was
supposed to fix must be some unrelated memory corruption, and the "fix"
actually causes more problems:
"However, the new code does not look safe in all cases. If some other
task has opened more files while dup_fd() released oldf->file_lock, the
new code will update open_files to the new larger value. But newf was
allocated with the old smaller value of open_files, therefore subsequent
accesses to newf may try to write into unallocated memory."
Hugh Dickins [Tue, 14 Nov 2006 13:43:38 +0000 (13:43 +0000)]
[PATCH] hugetlb: fix error return for brk() entering a hugepage region
Commit cb07c9a1864a8eac9f3123e428100d5b2a16e65a causes the wrong return
value. is_hugepage_only_range() is a boolean, so we should return
-EINVAL rather than 1.
Also - we can use "mm" instead of looking up "current->mm" again.
Brian King [Mon, 13 Nov 2006 22:32:36 +0000 (16:32 -0600)]
[PATCH] libata: Convert from module_init to subsys_initcall
When building a monolithic kernel, the load order of drivers does not
work for SAS libata users, resulting in a kernel oops.
Convert libata to use subsys_initcall instead of module_init, which
ensures that libata gets loaded before any LLDD.
This is the same thing that scsi core does to solve the problem. The
load order problem was observed on ipr SAS adapters and should exist for
other SAS users as well.
Signed-off-by: Brian King <brking@us.ibm.com> Acked-by: Jeff Garzik <jgarzik@pobox.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
David Gibson [Tue, 14 Nov 2006 10:03:38 +0000 (02:03 -0800)]
[PATCH] hugetlb: check for brk() entering a hugepage region
Unlike mmap(), the codepath for brk() creates a vma without first checking
that it doesn't touch a region exclusively reserved for hugepages. On
powerpc, this can allow it to create a normal page vma in a hugepage
region, causing oopses and other badness.
Add a test to prevent this. With this patch, brk() will simply fail if it
attempts to move the break into a hugepage reserved region.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Cc: Adam Litke <agl@us.ibm.com> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Hugh Dickins [Tue, 14 Nov 2006 10:03:32 +0000 (02:03 -0800)]
[PATCH] hugetlb: prepare_hugepage_range check offset too
(David:)
If hugetlbfs_file_mmap() returns a failure to do_mmap_pgoff() - for example,
because the given file offset is not hugepage aligned - then do_mmap_pgoff
will go to the unmap_and_free_vma backout path.
But at this stage the vma hasn't been marked as hugepage, and the backout path
will call unmap_region() on it. That will eventually call down to the
non-hugepage version of unmap_page_range(). On ppc64, at least, that will
cause serious problems if there are any existing hugepage pagetable entries in
the vicinity - for example if there are any other hugepage mappings under the
same PUD. unmap_page_range() will trigger a bad_pud() on the hugepage pud
entries. I suspect this will also cause bad problems on ia64, though I don't
have a machine to test it on.
(Hugh:)
prepare_hugepage_range() should check file offset alignment when it checks
virtual address and length, to stop MAP_FIXED with a bad huge offset from
unmapping before it fails further down. PowerPC should apply the same
prepare_hugepage_range alignment checks as ia64 and all the others do.
Then none of the alignment checks in hugetlbfs_file_mmap are required (nor
is the check for too small a mapping); but even so, move up setting of
VM_HUGETLB and add a comment to warn of what David Gibson discovered - if
hugetlbfs_file_mmap fails before setting it, do_mmap_pgoff's unmap_region
when unwinding from error will go the non-huge way, which may cause bad
behaviour on architectures (powerpc and ia64) which segregate their huge
mappings into a separate region of the address space.
Signed-off-by: Hugh Dickins <hugh@veritas.com> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: "David S. Miller" <davem@davemloft.net> Acked-by: Adam Litke <agl@us.ibm.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Nathan Lynch [Tue, 14 Nov 2006 10:03:30 +0000 (02:03 -0800)]
[PATCH] nvidiafb: fix unreachable code in nv10GetConfig
Fix binary/logical operator typo which leads to unreachable code. Noticed
while looking at other issues; I don't have the relevant hardware to test
this.
Signed-off-by: Nathan Lynch <ntl@pobox.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Acked-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Ian Kent [Tue, 14 Nov 2006 10:03:29 +0000 (02:03 -0800)]
[PATCH] autofs4: panic after mount fail
Resolve the panic on failed mount of an autofs filesystem originally
reported by Mao Bibo.
It addresses two issues that happen after the mount fail. The first a NULL
pointer reference to a field (pipe) in the autofs superblock info structure
and second the lack of super block cleanup by the autofs and autofs4
modules.
Signed-off-by: Ian Kent <raven@themaw.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Nicolas Kaiser [Tue, 14 Nov 2006 10:03:28 +0000 (02:03 -0800)]
[PATCH] drivers/ide: stray bracket
Stray bracket in debug code.
Signed-off-by: Nicolas Kaiser <nikai@nikai.net> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Daniel Ritz [Tue, 14 Nov 2006 10:03:25 +0000 (02:03 -0800)]
[PATCH] fix via586 irq routing for pirq 5
Fix interrupt routing for via 586 bridges. pirq can be 5 which needs to be
mapped to INTD. But currently the access functions can handle only pirq
1-4. this is similar to the other via chipsets where pirq 4 and 5 are both
mapped to INTD. Fixes bugzilla #7490
Cc: Daniel Paschka <monkey20181@gmx.net> Cc: Adrian Bunk <bunk@susta.de> Signed-off-by: Daniel Ritz <daniel.ritz@gmx.ch> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andrew Morton [Tue, 14 Nov 2006 10:03:23 +0000 (02:03 -0800)]
[PATCH] setup_irq(): better mismatch debugging
When we get a mismatch between handlers on the same IRQ, all we get is "IRQ
handler type mismatch for IRQ n". Let's print the name of the
presently-registered handler with which we got the mismatch.
Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Andi Kleen [Tue, 14 Nov 2006 15:57:46 +0000 (16:57 +0100)]
[PATCH] x86-64: Fix vgetcpu when CONFIG_HOTPLUG_CPU is disabled
The vgetcpu per CPU initialization previously relied on CPU hotplug
events for all CPUs to initialize the per CPU state. That only
worked only on kernels with CONFIG_HOTPLUG_CPU enabled. On the
others some CPUs didn't get their state initialized properly
and vgetcpu wouldn't work.
Change the initialization sequence to instead run in a normal
initcall (which runs after the normal CPU bootup) and initialize
all running CPUs there. Later hotplug CPUs are still handled
with an hotplug notifier.
Andi Kleen [Tue, 14 Nov 2006 15:57:46 +0000 (16:57 +0100)]
[PATCH] x86: Add acpi_user_timer_override option for Asus boards
Timer overrides are normally disabled on Nvidia board because
they are commonly wrong, except on new ones with HPET support.
Unfortunately there are quite some Asus boards around that
don't have HPET, but need a timer override.
We don't know yet how to handle this transparently,
but at least add a command line option to force the timer override
and let them boot.
2.6.19-rc4 has broken CONFIG_CRASH_DUMP support on x86_64. It is impossible
to read out the kernel contents from /proc/vmcore because saved_max_pfn is set
to zero instead of the max_pfn value before the user map is setup.
This happens because saved_max_pfn is initialized at parse_early_param() time,
and at this time no active regions have been registered. save_max_pfn is setup
from e820_end_of_ram(), more exact find_max_pfn_with_active_regions() which
returns 0 because no regions exist.
This patch fixes this by registering before and removing after the call
to e820_end_of_ram().
Signed-off-by: Magnus Damm <magnus@valinux.co.jp> Signed-off-by: Andi Kleen <ak@suse.de>
Steven Rostedt [Tue, 14 Nov 2006 15:57:46 +0000 (16:57 +0100)]
[PATCH] x86-64: shorten the x86_64 boot setup GDT to what the comment says
Stephen Tweedie, Herbert Xu, and myself have been struggling with a very
nasty bug in Xen. But it also pointed out a small bug in the x86_64
kernel boot setup.
The GDT limit being setup by the initial bzImage code when entering into
protected mode is way too big. The comment by the code states that the
size of the GDT is 2048, but the actual size being set up is much bigger
(32768). This happens simply because of one extra '0'.
Instead of setting up a 0x800 size, 0x8000 is set up. On bare metal this
is fine because the CPU wont load any segments unless they are
explicitly used. But unfortunately, this breaks Xen on vmx FV, since it
(for now) blindly loads all the segments into the VMCS if they are less
than the gdt limit. Since the real mode segments are around 0x3000, we are
getting junk into the VMCS and that later causes an exception.
Stephen Tweedie has written up a patch to fix the Xen side and will be
submitting that to those folks. But that doesn't excuse the GDT limit
being a magnitude too big.
AK: changed to compute true gdt size in assembler, fixed comment
Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Andi Kleen <ak@suse.de>
Darrick J. Wong [Tue, 14 Nov 2006 14:55:41 +0000 (09:55 -0500)]
libata: fix double-completion on error
A curious thing happens, however, when ata_qc_new_init fails to get
an ata_queued_cmd:
First, ata_qc_new_init handles the failure like this:
cmd->result = (DID_OK << 16) | (QUEUE_FULL << 1);
done(cmd);
Then, we return to ata_scsi_translate and do this:
err_mem:
cmd->result = (DID_ERROR << 16);
done(cmd);
It appears to me that first we set a status code indicating that we're
ok but the device queue is full and finish the command, but then
we blow away that status code and replace it with an error flag and
finish the command a second time! That does not seem to be desirable
behavior since we merely want the I/O to wait until a command slot
frees up, not send errors up the block layer.
In the err_mem case, we should simply exit out of ata_scsi_translate
instead.
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
Linus Torvalds [Mon, 13 Nov 2006 19:50:28 +0000 (11:50 -0800)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc:
MMC: Do not set unsupported bits in OCR response
MMC: Poll card status after rescanning cards
Linus Torvalds [Mon, 13 Nov 2006 17:52:04 +0000 (09:52 -0800)]
Merge branch 'for-linus' of master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband
* 'for-linus' of master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband:
IB/mad: Fix race between cancel and receive completion
RDMA/amso1100: Fix && typo
RDMA/amso1100: Fix unitialized pseudo_netdev accessed in c2_register_device
IB/ehca: Activate scaling code by default
IB/ehca: Use named constant for max mtu
IB/ehca: Assure 4K alignment for firmware control blocks
Roland Dreier [Mon, 13 Nov 2006 17:38:07 +0000 (09:38 -0800)]
IB/mad: Fix race between cancel and receive completion
When ib_cancel_mad() is called, it puts the canceled send on a list
and schedules a "flushed" callback from process context. However,
this leaves a window where a receive completion could be processed
before the send is fully flushed.
This is fine, except that ib_find_send_mad() will find the MAD and
return it to the receive processing, which results in the sender
getting both a successful receive and a "flushed" send completion for
the same request. Understandably, this confuses the sender, which is
expecting only one of these two callbacks, and leads to grief such as
a use-after-free in IPoIB.
Fix this by changing ib_find_send_mad() to return a send struct only
if the status is still successful (and not "flushed"). The search of
the send_list already had this check, so this patch just adds the same
check to the search of the wait_list.
projects / linux-2.6 / log