- 21 Dec, 2007 1 commit
-
-
Ingo Molnar authored
Andrew "Eagle Eye" Morton noticed that we use raw_local_save_flags() instead of raw_local_irq_save(flags) in die(). This allows the preemption of oopsing contexts - which is highly undesirable. It also causes CONFIG_DEBUG_PREEMPT to complain, as reported by Miles Lane. this bug was introduced via: commit 39743c9e Author: Andi Kleen <ak@suse.de> Date: Fri Oct 19 20:35:03 2007 +0200 x86: use raw locks during oopses - spin_lock_irqsave(&die.lock, flags); + __raw_spin_lock(&die.lock); + raw_local_save_flags(flags); that is not a correct open-coding of spin_lock_irqsave(): both the ordering is wrong (irqs should be disabled _first_), and the wrong flags-saving API was used. Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
- 20 Dec, 2007 11 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-schedLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched: debug: add end-of-oops marker sched: rt: account the cpu time during the tick
-
git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dmLinus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/agk/linux-2.6-dm: dm crypt: use bio_add_page dm: merge max_hw_sector dm: trigger change uevent on rename dm crypt: fix write endio dm mpath: hp requires scsi dm: table detect io beyond device
-
Milan Broz authored
Fix possible max_phys_segments violation in cloned dm-crypt bio. In write operation dm-crypt needs to allocate new bio request and run crypto operation on this clone. Cloned request has always the same size, but number of physical segments can be increased and violate max_phys_segments restriction. This can lead to data corruption and serious hardware malfunction. This was observed when using XFS over dm-crypt and at least two HBA controller drivers (arcmsr, cciss) recently. Fix it by using bio_add_page() call (which tests for other restrictions too) instead of constructing own biovec. All versions of dm-crypt are affected by this bug. Cc: stable@kernel.org Cc: dm-crypt@saout.de Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
-
Neil Brown authored
Make sure dm honours max_hw_sectors of underlying devices We still have no firm testing evidence in support of this patch but believe it may help to resolve some bug reports. - agk Signed-off-by: Neil Brown <neilb@suse.de> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
-
Alasdair G Kergon authored
Insert a missing KOBJ_CHANGE notification when a device is renamed. Cc: Scott James Remnant <scott@ubuntu.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
-
Milan Broz authored
Fix BIO_UPTODATE test for write io. Cc: stable@kernel.org Cc: dm-crypt@saout.de Signed-off-by: Milan Broz <mbroz@redhat.com> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
-
Paul Mundt authored
With CONFIG_SCSI=n __scsi_print_sense() is never linked in. drivers/built-in.o: In function `hp_sw_end_io': dm-mpath-hp-sw.c:(.text+0x914f8): undefined reference to `__scsi_print_sense' Caught with a randconfig on current git. Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Alasdair G Kergon <agk@redhat.com>
-
Jun'ichi Nomura authored
This patch fixes a panic on shrinking a DM device if there is outstanding I/O to the part of the device that is being removed. (Normally this doesn't happen - a filesystem would be resized first, for example.) The bug is that __clone_and_map() assumes dm_table_find_target() always returns a valid pointer. It may fail if a bio arrives from the block layer but its target sector is no longer included in the DM btree. This patch appends an empty entry to table->targets[] which will be returned by a lookup beyond the end of the device. After calling dm_table_find_target(), __clone_and_map() and target_message() check for this condition using dm_target_is_valid(). Sample test script to trigger oops:
-
Ivan Kokshaysky authored
The problem was introduced by commit "mm: variable length argument support" (b6a2fea3) as it didn't update fs/binfmt_aout.c like other binfmt's. I noticed that on alpha when accidentally launched old OSF/1 Acrobat Reader binary. Obviously, other architectures are affected as well. Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Ollie Wild <aaw@google.com> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Hugh Dickins <hugh@veritas.com> Cc: Adrian Bunk <bunk@stusta.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Arjan van de Ven authored
Right now it's nearly impossible for parsers that collect kernel crashes from logs or emails (such as www.kerneloops.org) to detect the end-of-oops condition. In addition, it's not currently possible to detect whether or not 2 oopses that look alike are actually the same oops reported twice, or are truly two unique oopses. This patch adds an end-of-oops marker, and makes the end marker include a very simple 64-bit random ID to be able to detect duplicate reports. Normally, this ID is calculated as a late_initcall() (in the hope that at that time there is enough entropy to get a unique enough ID); however for early oopses the oops_exit() function needs to generate the ID on the fly. We do this all at the _end_ of an oops printout, so this does not impact our ability to get the most important portions of a crash out to the console first. [ Sidenote: the already existing oopses-since-bootup counter we print during crashes serves as the differentiator between multiple oopses that trigger during the same bootup. ] Tested on 32-bit and 64-bit x86. Artificially injected very early crashes as well, as expected they result in this constant ID after multiple bootups: ---[ end trace ca143223eefdc828 ]--- ---[ end trace ca143223eefdc828 ]--- because the random pools are still all zero. But it all still works fine and causes no additional problems (which is the main goal of instrumentation code). Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
Peter Zijlstra authored
Realtime tasks would not account their runtime during ticks. Which would lead to: struct sched_param param = { .sched_priority = 10 }; pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶m); while (1) ; Not showing up in top. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-
- 19 Dec, 2007 24 commits
-
-
Mike Travis authored
when called by setup_arch) after smp_store_cpu_info() had set it to the correct value. The error shows up in 'cat /proc/cpuinfo' will all cpus = 0. Signed-off-by: Mike Travis <travis@sgi.com> Cc: Andi Kleen <ak@suse.de> Cc: Christoph Lameter <clameter@sgi.com> Cc: Jack Steiner <steiner@sgi.com> Cc: Suresh B Siddha <suresh.b.siddha@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Adrian Bunk authored
CONFIG_HOTPLUG_CPU=y: WARNING: vmlinux.o(.text+0xfa52): Section mismatch: reference to .init.data:disable_pse (between 'identify_cpu' and 'identify_secondary_cpu') [ akpm@linux-foundation.org: initializer fix. ] Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Adrian Bunk authored
CONFIG_HOTPLUG_CPU=y: WARNING: vmlinux.o(.text+0x1199a): Section mismatch: reference to .init.text.5:select_idle_routine (between 'init_intel' and 'init_nexgen') Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Adrian Bunk authored
CONFIG_HOTPLUG_CPU=y: WARNING: vmlinux.o(.text+0x22c60): Section mismatch: reference to .init.data:cpu_idle_tasks (between 'do_boot_cpu' and 'do_warm_boot_cpu') WARNING: vmlinux.o(.text+0x22c99): Section mismatch: reference to .init.data:cpu_idle_tasks (between 'do_boot_cpu' and 'do_warm_boot_cpu') WARNING: vmlinux.o(.text+0x2359b): Section mismatch: reference to .init.data:smp_b_stepping (between 'smp_store_cpu_info' and 'cpu_exit_clear') WARNING: vmlinux.o(.text+0x235a0): Section mismatch: reference to .init.data:smp_b_stepping (between 'smp_store_cpu_info' and 'cpu_exit_clear') Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-
Adrian Bunk authored
CONFIG_HOTPLUG_CPU=y: WARNING: vmlinux.o(.text+0x2390d): Section mismatch: reference to .init.text.5:setup_local_APIC (between 'start_secondary' and 'check_tsc_warp') Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6Linus Torvalds authored
* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6: [IA64] Adjust CMCI mask on CPU hotplug [IA64] make flush_tlb_kernel_range() an inline function [IA64] Guard elfcorehdr_addr with #if CONFIG_PROC_FS [IA64] Fix Altix BTE error return status [IA64] Remove assembler warnings on head.S [IA64] Remove compiler warinings about uninitialized variable in irq_ia64.c [IA64] set_thread_area fails in IA32 chroot [IA64] print kernel release in OOPS to make kerneloops.org happy [IA64] Two trivial spelling fixes [IA64] Avoid unnecessary TLB flushes when allocating memory [IA64] ia32 nopage [IA64] signal: remove redundant code in setup_sigcontext() IA64: Slim down __clear_bit_unlock
-
Alan Cox authored
Bug #9261 Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Geoff Levand authored
The dev_id arg passed to free_irq() must match that passed to request_irq(). Fixes this PS3 error message: Trying to free already-free IRQ 44 Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Geert Uytterhoeven authored
ps3fb: Update for firmware 2.10 As of PS3 firmware version 2.10, the GPU command buffer size must be at least 2 MiB large. Since we use only a small part of the GPU command buffer and don't want to waste precious XDR memory, move the GPU command buffer back to the start of the XDR memory reserved for ps3fb and let the unused part overlap with the actual frame buffer. Signed-off-by: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6: [SCSI] initio: bugfix for accessors patch [SCSI] st: fix kernel BUG at include/linux/scatterlist.h:59! [SCSI] initio: fix conflict when loading driver [SCSI] sym53c8xx: fix "irq X: nobody cared" regression [SCSI] dpt_i2o: driver is only 32 bit so don't set 64 bit DMA mask [SCSI] sym53c8xx: fix free_irq() regression
-
Linus Torvalds authored
Krzysztof Oledzki noticed a dirty page accounting leak on some of his machines, causing the machine to eventually lock up when the kernel decided that there was too much dirty data, but nobody could actually write anything out to fix it. The culprit turns out to be filesystems (cough ext3 with data=journal cough) that re-dirty the page when the "->invalidatepage()" callback is called. Fix it up by doing a final dirty page accounting check when we actually remove the page from the page cache. This fixes bugzilla entry 9182: http://bugzilla.kernel.org/show_bug.cgi?id=9182Tested-by: Ingo Molnar <mingo@elte.hu> Tested-by: Krzysztof Oledzki <olel@ans.pl> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
Hidetoshi Seto authored
Currently CMCI mask of hot-added CPU is always disabled after CPU hotplug. We should adjust this mask depending on CMC polling state. Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
Jan Beulich authored
This fixes an unused variable warning in mm/vmalloc.c. Tony: also fix resulting fallout in uncached.c with a typo in args to flush_tlb_kernel_range(). Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
Simon Horman authored
Access to elfcorehdr_addr needs to be guarded by #if CONFIG_PROC_FS as well as the existing #if guards. Fixes the following build problem: arch/ia64/hp/common/built-in.o: In function `sba_init':arch/ia64/hp/common/sba_iommu.c:2043: undefined reference to `elfcorehdr_addr' :arch/ia64/hp/common/sba_iommu.c:2043: undefined reference to `elfcorehdr_addr' Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
Russ Anderson authored
The Altix shub2 BTE error detail bits are in a different location than on shub1. The current code does not take this into account resulting in all shub2 BTE failures mapping to "unknown". This patch reads the error detail bits from the proper location, so the correct BTE failure reason is returned for both shub1 and shub2. Signed-off-by: Russ Anderson <rja@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
Hidetoshi Seto authored
This patch removes the following assembler warning messages. AS arch/ia64/kernel/head.o arch/ia64/kernel/head.S: Assembler messages: arch/ia64/kernel/head.S:1179: Warning: Use of 'ld8' violates RAW dependency 'CR[PTA]' (data) arch/ia64/kernel/head.S:1179: Warning: Only the first path encountering the conflict is reported arch/ia64/kernel/head.S:1178: Warning: This is the location of the conflicting usage arch/ia64/kernel/head.S:1180: Warning: Use of 'ld8' violates RAW dependency 'CR[PTA]' (data) arch/ia64/kernel/head.S:1180: Warning: Only the first path encountering the conflict is reported arch/ia64/kernel/head.S:1178: Warning: This is the location of the conflicting usage : arch/ia64/kernel/head.S:1213: Warning: Use of 'ldf.fill.nta' violates RAW dependency 'CR[PTA]' (data) arch/ia64/kernel/head.S:1213: Warning: Only the first path encountering the conflict is reported arch/ia64/kernel/head.S:1178: Warning: This is the location of the conflicting usage Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
Kenji Kaneshige authored
This patch removes the following compiler warning messages. CC arch/ia64/kernel/irq_ia64.o arch/ia64/kernel/irq_ia64.c: In function 'create_irq': arch/ia64/kernel/irq_ia64.c:343: warning: 'domain.bits[0u]' may be used uninitialized in this function arch/ia64/kernel/irq_ia64.c: In function 'assign_irq_vector': arch/ia64/kernel/irq_ia64.c:203: warning: 'domain.bits[0u]' may be used uninitialized in this function Signed-off-by: Kenji Kaneshige <kaneshige.kenji@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
Ian Wienand authored
I tried to upgrade an IA32 chroot on my IA64 to a new glibc with TLS. It kept dying because set_thread_area was returning -ESRCH (bugs.debian.org/451939). I instrumented arch/ia64/ia32/sys_ia32.c:get_free_idx() and ended up seeing output like [pid] idx desc->a desc->b ----------------------------- [2710] 0 -> c6b0ffff 40dff31b [2710] 1 -> 0 0 [2710] 2 -> 0 0 [2710] 0 -> c6b0ffff 40dff31b [2710] 1 -> c6b0ffff 40dff31b [2710] 2 -> 0 0 [2711] 0 -> c6b0ffff 40dff31b [2711] 1 -> c6b0ffff 40dff31b [2711] 2 -> 48c0ffff 40dff317 which suggested to me that TLS pointers were surviving exec() calls, leading to GDT pointers filling up and the eventual failure of get_free_idx(). I think the solution is flushing the tls array on exec. Signed-Off-By: Ian Wienand <ianw@gelato.unsw.edu.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
Luck, Tony authored
The ia64 oops message doesn't include the kernel version, which makes it hard to automatically categorize oops messages scraped from mailing lists and bug databases. Signed-off-by: Tony Luck <tony.luck@intel.com>
-
Joe Perches authored
s/addres/address/ s/performanc/performance/ Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
Improve performance of memory allocations on ia64 by avoiding a global TLB purge to purge a single page from the file cache. This happens whenever we evict a page from the buffer cache to make room for some other allocation. Test case: Run 'find /usr -type f | xargs cat > /dev/null' in the background to fill the buffer cache, then run something that uses memory, e.g. 'gmake -j50 install'. Instrumentation showed that the number of global TLB purges went from a few millions down to about 170 over a 12 hours run of the above. The performance impact is particularly noticeable under virtualization, because a virtual TLB is generally both larger and slower to purge than a physical one. Signed-off-by: Christophe de Dinechin <ddd@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
Nick Piggin authored
Convert ia64's ia32 support from nopage to fault. Signed-off-by: Nick Piggin <npiggin@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
Shi Weihua authored
This patch removes some redundant code in the function setup_sigcontext(). The registers ar.ccv,b7,r14,ar.csd,ar.ssd,r2-r3 and r16-r31 are not restored in restore_sigcontext() when (flags & IA64_SC_FLAG_IN_SYSCALL) is true. So we don't need to zero those variables in setup_sigcontext(). Signed-off-by: Shi Weihua <shiwh@cn.fujitsu.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
Christoph Lameter authored
__clear_bit_unlock does not need to perform atomic operations on the variable. Avoid a cmpxchg and simply do a store with release semantics. Add a barrier to be safe that the compiler does not do funky things. Tony: Use intrinsic rather than inline assembler Signed-off-by: Christoph Lameter <clameter@sgi.com> Acked-by: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
-
- 18 Dec, 2007 4 commits
-
-
Boaz Harrosh authored
patch: [SCSI] initio: convert to use the data buffer accessors had a small but fatal bug in that it didn't increment the pointer into the initio scatterlist descriptors as it looped over the block generated ones. Fixed here. Signed-off-by: Boaz Harrosh <bharrosh@panasas.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
-
FUJITA Tomonori authored
This is caused by a missing scatterlist initialisation (it only shows up when sg list handling debugging is turned on). Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Cc: Kai Makisara <Kai.Makisara@kolumbus.fi> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
-
Alan Cox authored
> I have a scanner connected to a Initio INI-950 SCSI card and I recently > upgraded from SuSE 10.2 to 10.3. The new kernel doesn't see any of my > devices. I get the following in /var/log/messages: > > ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 17 (level, low) -> IRQ 16 > initio: I/O port range 0x0 is busy. > ACPI: PCI interrupt for device 0000:00:0a.0 disabled Humm not a collision - thats a bug in the driver updating. Looks like the changes I made and combined with Christoph's lost a line somewhere when I was merging it all. Signed-off-by: Alan Cox <alan@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
-
Tony Battersby authored
The patch described by the following excerpt from ChangeLog-2.6.24-rc1 eventually causes a "irq X: nobody cared" error after a while: commit 99c9e0a1 Author: Matthew Wilcox <matthew@wil.cx> Date: Fri Oct 5 15:55:12 2007 -0400 [SCSI] sym53c8xx: Make interrupt handler capable of returning IRQ_NONE After this happens, the kernel disables the IRQ, causing the SCSI card to stop working until the next reboot. The problem is caused by the interrupt handler returning IRQ_NONE instead of IRQ_HANDLED after handling an interrupt-on-the-fly (INTF) condition. The following patch fixes the problem. Signed-off-by: Tony Battersby <tonyb@cybernetics.com> Acked-by: Matthew Wilcox <willy@linux.intel.com> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
-