- 24 Sep, 2009 38 commits
-
-
Avi Kivity authored
commit c9eaf20f upstream. Absolute jumps use zero extended immediate operands. Signed-off-by:
Avi Kivity <avi@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Gleb Natapov authored
commit 5fff7d27 upstream. Don't call adjust_vmx_controls() two times for the same control. It restores options that were dropped earlier. This loses us the cr8 exit control, which causes a massive performance regression Windows x64. Signed-off-by:
Gleb Natapov <gleb@redhat.com> Signed-off-by:
-
Jan Kiszka authored
commit 07708c4a upstream. So far unprivileged guest callers running in ring 3 can issue, e.g., MMU hypercalls. Normally, such callers cannot provide any hand-crafted MMU command structure as it has to be passed by its physical address, but they can still crash the guest kernel by passing random addresses. To close the hole, this patch considers hypercalls valid only if issued from guest ring 0. This may still be relaxed on a per-hypercall base in the future once required. Signed-off-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
-
Glauber Costa authored
commit a20316d2 upstream. The use of __pa() to calculate the address of a C-visible symbol is wrong, and can lead to unpredictable results. See arch/x86/include/asm/page.h for details. It should be replaced with __pa_symbol(), that does the correct math here, by taking relocations into account. This ensures the correct wallclock data structure physical address is passed to the hypervisor. Signed-off-by:
Glauber Costa <glommer@redhat.com> Signed-off-by:
-
Avi Kivity authored
commit 0a79b009 upstream. Debug registers may only be accessed from cpl 0. Unfortunately, vmx will code to emulate the instruction even though it was issued from guest userspace, possibly leading to an unexpected trap later. Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Gleb Natapov authored
commit 65a82211 upstream. This bug was introduced by b4a2f5e7. Signed-off-by:
-
Marcelo Tosatti authored
commit 6ba66178 upstream. Commit b8bcfe99 made paravirt pte updates synchronous in interrupt context. Unfortunately the KVM pv mmu code caches the lazy/nonlazy mode internally, so a pte update from interrupt context during a lazy mmu operation can be batched while it should be performed synchronously. https://bugzilla.redhat.com/show_bug.cgi?id=518022 Drop the internal mode variable and use paravirt_get_lazy_mode(), which returns the correct state. Signed-off-by:
-
Nicolas Pitre authored
commit 7929eb9c upstream. Let's suppose a highmem page is kmap'd with kmap(). A pkmap entry is used, the page mapped to it, and the virtual cache is dirtied. Then kunmap() is used which does virtually nothing except for decrementing a usage count. Then, let's suppose the _same_ page gets mapped using kmap_atomic(). It is therefore mapped onto a fixmap entry instead, which has a different virtual address unaware of the dirty cache data for that page sitting in the pkmap mapping. Fortunately it is easy to know if a pkmap mapping still exists for that page and use it directly with kmap_atomic(), thanks to kmap_high_get(). And actual testing with a printk in the added code path shows that this condition is actually met *extremely* frequently. Seems that we've been quite lucky that things have worked so well with highmem so far. Signed-off-by:
Nicolas Pitre <nico@marvell.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Jack Steiner authored
commit fa526d0d upstream. Fix address passed to cpa_flush_range() when changing page attributes from WB to UC. The address (*addr) is modified by __change_page_attr_set_clr(). The result is that the pages being flushed start at the _end_ of the changed range instead of the beginning. This should be considered for 2.6.30-stable and 2.6.31-stable. Signed-off-by:
Jack Steiner <steiner@sgi.com> Acked-by:
Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by:
H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Tejun Heo authored
commit 6dab62ee upstream. http://bugzilla.kernel.org/show_bug.cgi?id=12542 reports that with the quirk not applied on resume, msi stops working after resuming and mcp78s ahci fails due to IRQ mis-delivery. Apply it on resume too. Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Peer Chen <pchen@nvidia.com> Cc: Tj <linux@tjworld.net> Reported-by:
Nicolas Derive <kalon33@ubuntu.com> Cc: Greg KH <greg@kroah.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jeremy Fitzhardinge authored
commit 1ea0d14e upstream. The Intel Optimization Reference Guide says: In Intel Atom microarchitecture, the address generation unit assumes that the segment base will be 0 by default. Non-zero segment base will cause load and store operations to experience a delay. - If the segment base isn't aligned to a cache line boundary, the max throughput of memory operations is reduced to one [e]very 9 cycles. [...] Assembly/Compiler Coding Rule 15. (H impact, ML generality) For Intel Atom processors, use segments with base set to 0 whenever possible; avoid non-zero segment base address that is not aligned to cache line boundary at all cost. We can't avoid having a non-zero base for the stack-protector segment, but we can make it cache-aligned. Signed-off-by:
Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> LKML-Reference: <4AA01893.6000507@goop.org> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Roel Kluin authored
commit 005155b1 upstream. For the x86_model to be greater than 6 or less than 12 is logically always true. Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Peter Zijlstra authored
commit 506d4bc8 upstream. The current noise computation does: \Sum abs(n_i - avg(n)) * N^-1.5 Which is (afaik) not a regular noise function, and needs the complete sample set available to post-process. Change this to use a regular stddev computation which can be done by keeping a two sums: stddev = sqrt( 1/N (\Sum n_i^2) - avg(n)^2 ) For which we only need to keep \Sum n_i and \Sum n_i^2. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: <stable@kernel.org> LKML-Reference: <new-submission> Signed-off-by:
-
Roland Dreier authored
commit fa0681d2 upstream. The current implementation allocates a single host page for EQ context memory, which was OK when we only allocated a few EQs. However, since we now allocate an EQ for each CPU core, this patch removes the hard-coded limit (which we exceed with 4 KB pages and 128 byte EQ context entries with 32 CPUs) and uses the same ICM table code as all other context tables, which ends up simplifying the code quite a bit while fixing the problem. This problem was actually hit in practice on a dual-socket Nehalem box with 16 real hardware threads and sufficiently odd ACPI tables that it shows on boot SMP: Allowing 32 CPUs, 16 hotplug CPUs so num_possible_cpus() ends up 32, and mlx4 ends up creating 33 MSI-X interrupts and 33 EQs. This mlx4 bug means that mlx4 can't even initialize at all on this quite mainstream system. Reported-by:
Eli Cohen <eli@mellanox.co.il> Tested-by:
Christoph Lameter <cl@linux-foundation.org> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Clemens Ladisch authored
commit f1bc07af upstream. When the volume is changed continuously (e.g., when the user drags a volume slider with the mouse), the driver does lots of I2C writes. Apparently, the sound chip can get confused when we poll the I2C status register too much, and fails to complete a read from it. On the PCI-E models, the PCI-E/PCI bridge gets upset by this and generates a machine check exception. To avoid this, this patch replaces the polling with an unconditional wait that is guaranteed to be long enough. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Tested-by: Johann Messner <johann.messner at jku.at> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Mark Brown authored
commit 87831cb6 upstream. It's the 8th enum of a zero indexed array. This is why I don't let new drivers use these arrays of enums... Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Sophie Hamilton authored
commit 6148b130 upstream. Fix minimum period size for cs46xx cards. This fixes a problem in the case where neither a period size nor a buffer size is passed to ALSA; this is the case in Audacious, OpenAL, and others. Signed-off-by:
Sophie Hamilton <kernel@theblob.org> Signed-off-by:
-
Zhenyu Wang authored
commit 12126482 upstream. As early pci resume has already restored config for host bridge and graphics device, don't need to restore it again, This removes an original order hack for graphics device restore. This fixed the resume hang issue found by Alan Stern on 845G, caused by extra config restore on graphics device. Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
Dave Airlie <airlied@linux.ie> Signed-off-by:
-
Jens Axboe authored
commit b8a9ae77 upstream. Stacked devices do not. For now, just error out with -EINVAL. Later we could make the limit apply on stacked devices too, for throttling reasons. This fixes 5a54cd13353bb3b88887604e2c980aa01e314309 and should go into 2.6.31 stable as well. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Geoff Levand authored
commit bc00351e upstream. A workaround for flash memory I/O errors when the PS3 internal hard disk has not been formatted for OtherOS use. This error condition mainly effects 'Live CD' users who have not formatted the PS3's internal hard disk for OtherOS. Fixes errors similar to these when using the ps3-flash-util or ps3-boot-game-os programs: ps3flash read failed 0x2050000 os_area_header_read: read error: os_area_header: Input/output error main:627: os_area_read_hp error. ERROR: can't change boot flag Signed-off-by:
Geoff Levand <geoffrey.levand@am.sony.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Paul Mackerras authored
commit a6dbf93a upstream. Currently there is a bug where if you use oprofile on a pSeries machine, then use perf_counters, then use oprofile again, oprofile will not work correctly; it will lose the PMU configuration the next time the hypervisor does a partition context switch, and thereafter won't count anything. Maynard Johnson identified the sequence causing the problem: - oprofile setup calls ppc_enable_pmcs(), which calls pseries_lpar_enable_pmcs, which tells the hypervisor that we want to use the PMU, and sets the "PMU in use" flag in the lppaca. This flag tells the hypervisor whether it needs to save and restore the PMU config. - The perf_counter code sets and clears the "PMU in use" flag directly as it context-switches the PMU between tasks, and leaves it clear when it finishes. - oprofile setup, called for a new oprofile run, calls ppc_enable_pmcs, which does nothing because it has already been called. In particular it doesn't set the "PMU in use" flag. This fixes the problem by arranging for ppc_enable_pmcs to always set the "PMU in use" flag. It makes the perf_counter code call ppc_enable_pmcs also rather than calling the lower-level function directly, and removes the setting of the "PMU in use" flag from pseries_lpar_enable_pmcs, since that is now done in its caller. This also removes the declaration of pasemi_enable_pmcs because it isn't defined anywhere. Reported-by:
Maynard Johnson <mpjohn@us.ibm.com> Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
-
Paul Mackerras authored
commit e51ee31e upstream. Michael Ellerman reported stack-frame size warnings being produced for power_check_constraints(), which uses an 8*8 array of u64 and two 8*8 arrays of unsigned long, which are currently allocated on the stack, along with some other smaller variables. These arrays come to 1.5kB on 64-bit or 1kB on 32-bit, which is a bit too much for the stack. This fixes the problem by putting these arrays in the existing per-cpu cpu_hw_counters struct. This is OK because two of the call sites have interrupts disabled already; for the third call site we use get_cpu_var, which disables preemption, so we know we won't get a context switch while we're in power_check_constraints(). Note that power_check_constraints() can be called during context switch but is not called from interrupts. Reported-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
-
Paul Mackerras authored
commit fa289bec upstream. Currently, if a group is created where the group leader is initially disabled but a non-leader member is initially enabled, and then the leader is subsequently enabled some time later, the time_enabled for the non-leader member will reflect the whole time since it was created, not just the time since the leader was enabled. This is incorrect, because all of the members are effectively disabled while the leader is disabled, since none of the members can go on the PMU if the leader can't. Thus we have to update the ->tstamp_enabled for all the enabled group members when a group leader is enabled, so that the time_enabled computation only counts the time since the leader was enabled. Similarly, when disabling a group leader we have to update the time_enabled and time_running for all of the group members. Also, in update_counter_times, we have to treat a counter whose group leader is disabled as being disabled. Reported-by:
Stephane Eranian <eranian@googlemail.com> Signed-off-by:
-
Xiao Guangrong authored
commit b3e62e35 upstream. If we pass a big size data over perf_counter_open() syscall, the kernel will copy this data to a small buffer, it will cause kernel crash. This bug makes the kernel unsafe and non-root local user can trigger it. Signed-off-by:
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com> Acked-by:
Peter Zijlstra <peterz@infradead.org> Acked-by:
-
Hugh Dickins authored
commit 2195d281 upstream. My 353d5c30 "mm: fix hugetlb bug due to user_shm_unlock call" broke the CONFIG_SYSVIPC !CONFIG_MMU build of both 2.6.31 and 2.6.30.6: "undefined reference to `user_shm_unlock'". gcc didn't understand my comment! so couldn't figure out to optimize away user_shm_unlock() from the error path in the hugetlb-less case, as it does elsewhere. Help it to do so, in a language it understands. Reported-by:
Mike Frysinger <vapier@gentoo.org> Signed-off-by:
Hugh Dickins <hugh.dickins@tiscali.co.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Joerg Roedel authored
commit e0faf54e upstream. The amd_iommu_pd_table is indexed by protection domain number and not by device id. So this check is broken and must be removed. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit 0d03d59d upstream. Commit b8313b6d ("dm log: remove incorrect field from userspace table output") added a call to strstr() with a single-character "needle" string parameter. Unfortunately some versions of gcc replace such calls to strstr() by calls to strchr() behind our back. This causes linking errors if strchr() is defined as an inline function in <asm/string.h> (e.g. on m68k): | WARNING: "strchr" [drivers/md/dm-log-userspace.ko] undefined! Avoid this by explicitly calling strchr() instead. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Jason Gunthorpe authored
commit ec579358 upstream. When probing the device in tpm_tis_init the call request_locality uses timeout_a, which wasn't being initalized until after request_locality. This results in request_locality falsely timing out if the chip is still starting. Move the initialization to before request_locality. This probably only matters for embedded cases (ie mine), a BIOS likely gets the TPM into a state where this code path isn't necessary. Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Acked-by:
Rajiv Andrade <srajiv@linux.vnet.ibm.com> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
Roland McGrath authored
commit 9f0ab4a3 upstream. In fs/binfmt_elf.c, load_elf_interp() calls padzero() for .bss even if the PT_LOAD has no PROT_WRITE and no .bss. This generates EFAULT. Here is a small test case. (Yes, there are other, useful PT_INTERP which have only .text and no .data/.bss.) ----- ptinterp.S _start: .globl _start nop int3 ----- $ gcc -m32 -nostartfiles -nostdlib -o ptinterp ptinterp.S $ gcc -m32 -Wl,--dynamic-linker=ptinterp -o hello hello.c $ ./hello Segmentation fault # during execve() itself After applying the patch: $ ./hello Trace trap # user-mode execution after execve() finishes If the ELF headers are actually self-inconsistent, then dying is fine. But having no PROT_WRITE segment is perfectly normal and correct if there is no segment with p_memsz > p_filesz (i.e. bss). John Reiser suggested checking for PROT_WRITE in the bss logic. I think it makes most sense to simply apply the bss logic only when there is bss. This patch looks less trivial than it is due to some reindentation. It just moves the "if (last_bss > elf_bss) {" test up to include the partial-page bss logic as well as the more-pages bss logic. Reported-by:
John Reiser <jreiser@bitwagon.com> Signed-off-by:
Roland McGrath <roland@redhat.com> Signed-off-by:
-
Bob Copeland authored
commit 3355443a upstream. "Ath5k: unify resets" introduced a regression into 2.6.28 where the PCU registers are never initialized, due to ath5k_reset() always passing true for change_channel. We subsequently program a lot of these registers but several may start in an unknown state. Reported-by:
Forrest Zhang <forrest@hifulltech.com> Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Bob Copeland authored
commit fcc6cb0c upstream. The find_ie() function uses a size_t for the len parameter, and directly uses len as a loop variable. If any received packets are malformed, it is possible for the decrease of len to overflow, and since the result is unsigned, the loop will not terminate. Change it to a signed int so the loop conditional works for negative values. This fixes the following soft lockup: [38573.102007] BUG: soft lockup - CPU#0 stuck for 61s! [phy0:2230] [38573.102007] Modules linked in: aes_i586 aes_generic fuse af_packet ipt_REJECT xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_state iptable_filter ip_tables x_tables acpi_cpufreq binfmt_misc dm_mirror dm_region_hash dm_log dm_multipath dm_mod kvm_intel kvm uinput i915 arc4 ecb drm snd_hda_codec_idt ath5k snd_hda_intel hid_apple mac80211 usbhid appletouch snd_hda_codec snd_pcm ath cfg80211 snd_timer i2c_algo_bit ohci1394 video snd processor ieee1394 rfkill ehci_hcd sg sky2 backlight snd_page_alloc uhci_hcd joydev output ac thermal button battery sr_mod applesmc cdrom input_polldev evdev unix [last unloaded: scsi_wait_scan] [38573.102007] irq event stamp: 2547724535 [38573.102007] hardirqs last enabled at (2547724534): [<c1002ffc>] restore_all_notrace+0x0/0x18 [38573.102007] hardirqs last disabled at (2547724535): [<c10038f4>] apic_timer_interrupt+0x28/0x34 [38573.102007] softirqs last enabled at (92950144): [<c103ab48>] __do_softirq+0x108/0x210 [38573.102007] softirqs last disabled at (92950274): [<c1348e74>] _spin_lock_bh+0x14/0x80 [38573.102007] [38573.102007] Pid: 2230, comm: phy0 Tainted: G W (2.6.31-rc7-wl #8) MacBook1,1 [38573.102007] EIP: 0060:[<f8ea2d50>] EFLAGS: 00010292 CPU: 0 [38573.102007] EIP is at cmp_ies+0x30/0x180 [cfg80211] [38573.102007] EAX: 00000082 EBX: 00000000 ECX: ffffffc1 EDX: d8efd014 [38573.102007] ESI: ffffff7c EDI: 0000004d EBP: eee2dc50 ESP: eee2dc3c [38573.102007] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [38573.102007] CR0: 8005003b CR2: d8efd014 CR3: 01694000 CR4: 000026d0 [38573.102007] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [38573.102007] DR6: ffff0ff0 DR7: 00000400 [38573.102007] Call Trace: [38573.102007] [<f8ea2f8d>] cmp_bss+0xed/0x100 [cfg80211] [38573.102007] [<f8ea33e4>] cfg80211_bss_update+0x84/0x410 [cfg80211] [38573.102007] [<f8ea3884>] cfg80211_inform_bss_frame+0x114/0x180 [cfg80211] [38573.102007] [<f97255ff>] ieee80211_bss_info_update+0x4f/0x180 [mac80211] [38573.102007] [<f972b118>] ieee80211_rx_bss_info+0x88/0xf0 [mac80211] [38573.102007] [<f9739297>] ? ieee802_11_parse_elems+0x27/0x30 [mac80211] [38573.102007] [<f972b224>] ieee80211_rx_mgmt_probe_resp+0xa4/0x1c0 [mac80211] [38573.102007] [<f972bc59>] ieee80211_sta_rx_queued_mgmt+0x919/0xc50 [mac80211] [38573.102007] [<c1009707>] ? sched_clock+0x27/0xa0 [38573.102007] [<c1009707>] ? sched_clock+0x27/0xa0 [38573.102007] [<c105ffd0>] ? mark_held_locks+0x60/0x80 [38573.102007] [<c1348be5>] ? _spin_unlock_irqrestore+0x55/0x70 [38573.102007] [<c134baa5>] ? sub_preempt_count+0x85/0xc0 [38573.102007] [<c1348bce>] ? _spin_unlock_irqrestore+0x3e/0x70 [38573.102007] [<c12c1c0f>] ? skb_dequeue+0x4f/0x70 [38573.102007] [<f972c021>] ieee80211_sta_work+0x91/0xb80 [mac80211] [38573.102007] [<c1009707>] ? sched_clock+0x27/0xa0 [38573.102007] [<c134baa5>] ? sub_preempt_count+0x85/0xc0 [38573.102007] [<c10479af>] worker_thread+0x18f/0x320 [38573.102007] [<c104794e>] ? worker_thread+0x12e/0x320 [38573.102007] [<c1348be5>] ? _spin_unlock_irqrestore+0x55/0x70 [38573.102007] [<f972bf90>] ? ieee80211_sta_work+0x0/0xb80 [mac80211] [38573.102007] [<c104cbb0>] ? autoremove_wake_function+0x0/0x50 [38573.102007] [<c1047820>] ? worker_thread+0x0/0x320 [38573.102007] [<c104c854>] kthread+0x84/0x90 [38573.102007] [<c104c7d0>] ? kthread+0x0/0x90 [38573.102007] [<c1003ab7>] kernel_thread_helper+0x7/0x10 Signed-off-by:
-
Bart Van Assche authored
commit afffd3da upstream. This patch fixes a memory leak in the libsrp function srp_ring_free(). It is not documented whether or not this function should free the ring pointer itself. But the source code of the callers of this function (srp_target_alloc() and srp_target_free()) makes it clear that srp_ring_free() should deallocate the ring pointer itself. Furthermore, the patch below makes srp_ring_free() deallocate all memory allocated by srp_ring_alloc(). This patch affects the ibmvstgt driver, which is the only in-tree driver that calls the srp_ring_free() function (indirectly). Signed-off-by:
Bart Van Assche <bart.vanassche@gmail.com> Acked-by:
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> Signed-off-by:
James Bottomley <James.Bottomley@suse.de> Signed-off-by:
-
James Bottomley authored
commit ea038f63 upstream. Chris Webb reported: p0# uname -a Linux f7ea8425-d45b-490f-a738-d181d0df6963.host.elastichosts.com 2.6.30.4-elastic-lon-p #2 SMP PREEMPT Thu Aug 20 14:30:50 BST 2009 x86_64 Intel(R) Xeon(R) CPU E5420 @ 2.50GHz GenuineIntel GNU/Linux p0# zgrep SCAN_ASYNC /proc/config.gz # CONFIG_SCSI_SCAN_ASYNC is not set p0# cat /var/log/kern/2009-08-20 [...] 15:27:10.485 kernel: scsi9 : iSCSI Initiator over TCP/IP 15:27:11.493 kernel: scsi 9:0:0:0: RAID IET Controller 0001 PQ: 0 ANSI: 5 15:27:11.493 kernel: scsi 9:0:0:0: Attached scsi generic sg6 type 12 15:27:11.495 kernel: scsi 9:0:0:1: Direct-Access IET VIRTUAL-DISK 0001 PQ: 0 ANSI: 5 15:27:11.495 kernel: sd 9:0:0:1: Attached scsi generic sg7 type 0 15:27:11.495 kernel: sd 9:0:0:1: [sdg] 4194304 512-byte hardware sectors: (2.14 GB/2.00 GiB) 15:27:11.495 kernel: sd 9:0:0:1: [sdg] Write Protect is off 15:27:11.495 kernel: sd 9:0:0:1: [sdg] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA 15:27:13.012 kernel: sdg:<6>scsi 9:0:0:1: [sdg] Unhandled error code 15:27:13.012 kernel: scsi 9:0:0:1: [sdg] Result: hostbyte=0x07 driverbyte=0x00 15:27:13.012 kernel: end_request: I/O error, dev sdg, sector 0 15:27:13.012 kernel: Buffer I/O error on device sdg, logical block 0 15:27:13.012 kernel: ldm_validate_partition_table(): Disk read failed. 15:27:13.012 kernel: unable to read partition table 15:27:13.014 kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 15:27:13.014 kernel: IP: [<ffffffff803f0d77>] disk_part_iter_next+0x74/0xfd 15:27:13.014 kernel: PGD 82ad0b067 PUD 82cd7e067 PMD 0 15:27:13.014 kernel: Oops: 0000 [#1] PREEMPT SMP 15:27:13.014 kernel: last sysfs file: /sys/devices/platform/host9/session4/iscsi_session/session4/ifacename 15:27:13.014 kernel: CPU 5 15:27:13.014 kernel: Modules linked in: 15:27:13.014 kernel: Pid: 13999, comm: async/0 Not tainted 2.6.30.4-elastic-lon-p #2 X7DBN 15:27:13.014 kernel: RIP: 0010:[<ffffffff803f0d77>] [<ffffffff803f0d77>] disk_part_iter_next+0x74/0xfd 15:27:13.014 kernel: RSP: 0018:ffff88066afa3dd0 EFLAGS: 00010246 15:27:13.014 kernel: RAX: ffff88082b58a000 RBX: ffff88066afa3e00 RCX: 0000000000000000 15:27:13.014 kernel: RDX: 0000000000000000 RSI: ffff88082b58a000 RDI: 0000000000000000 15:27:13.014 kernel: RBP: ffff88066afa3df0 R08: ffff88066afa2000 R09: ffff8806a204f000 15:27:13.014 kernel: R10: 000000fb12c7d274 R11: ffff8806c2bf0628 R12: ffff88066afa3e00 15:27:13.014 kernel: R13: ffff88082c829a00 R14: 0000000000000000 R15: ffff8806bc50c920 15:27:13.014 kernel: FS: 0000000000000000(0000) GS:ffff88002818a000(0000) knlGS:0000000000000000 15:27:13.014 kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b 15:27:13.014 kernel: CR2: 0000000000000010 CR3: 000000082ade3000 CR4: 00000000000426e0 15:27:13.014 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 15:27:13.014 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 15:27:13.014 kernel: Process async/0 (pid: 13999, threadinfo ffff88066afa2000, task ffff8806c2bf05e0) 15:27:13.014 kernel: Stack: 15:27:13.014 kernel: 0000000000000000 ffff88066afa3e00 ffff88066afa3e00 ffff88082c829a00 15:27:13.014 kernel: ffff88066afa3e40 ffffffff80306feb ffff88082b58a000 0000000000000000 15:27:13.014 kernel: 0000000000000001 ffff8806bc50c920 ffff88066afa3e40 ffff88082b58a000 15:27:13.014 kernel: Call Trace: 15:27:13.014 kernel: [<ffffffff80306feb>] register_disk+0x122/0x13a 15:27:13.014 kernel: [<ffffffff803f0b0f>] add_disk+0xaa/0x106 15:27:13.014 kernel: [<ffffffff80493609>] sd_probe_async+0x198/0x25b 15:27:13.014 kernel: [<ffffffff80270482>] async_thread+0x10c/0x20d 15:27:13.014 kernel: [<ffffffff802545ff>] ? default_wake_function+0x0/0xf 15:27:13.014 kernel: [<ffffffff80270376>] ? async_thread+0x0/0x20d 15:27:13.014 kernel: [<ffffffff8026ad89>] kthread+0x55/0x80 15:27:13.014 kernel: [<ffffffff8022be6a>] child_rip+0xa/0x20 15:27:13.014 kernel: [<ffffffff8026ad34>] ? kthread+0x0/0x80 15:27:13.014 kernel: [<ffffffff8022be60>] ? child_rip+0x0/0x20 15:27:13.014 kernel: Code: c8 ff 80 e1 0c b9 00 00 00 00 0f 44 c1 41 83 cd ff 48 8d 7a 20 48 be ff ff ff ff 08 00 00 00 48 b9 00 00 00 00 08 00 00 00 eb 50 <8b> 42 10 41 bd 01 00 00 00 eb db 4c 63 c2 4e 8d 04 c7 4d 8b 20 15:27:13.015 kernel: RIP [<ffffffff803f0d77>] disk_part_iter_next+0x74/0xfd 15:27:13.015 kernel: RSP <ffff88066afa3dd0> 15:27:13.015 kernel: CR2: 0000000000000010 15:27:13.015 kernel: ---[ end trace 6104b56ef5590e25 ]--- The problem is caused because the async scanning split in sd.c doesn't hold any reference to the device when it kicks off the async piece. What's happening is that an iSCSI disconnect is destorying the device again *before* the async sd scanning thread even starts. Fix this by taking a reference before starting the thread and dropping it again when the thread completes. Reported-by:
Chris Webb <chris@arachsys.com> Signed-off-by:
-
Kashyap, Desai authored
commit ed79f128 upstream. This patch modifies the slave_configure callback so the messages that get sent to system log for RAID1E volumes contain the string "RAID10" instead of "RAID1E". These messages contain information regarding what kind of scsi device is being added. Certain OEMS can enable displaying the RAID10 string instead of RAID1E via manufacturing page 10. The driver will read this config page at driver load time, then determine from the GenericFlags0 bits whether display the RAID10 or RAID1E string, also even drive count is taken into consideration. Signed-off-by:
Kashyap Desai <kashyap.desai@lsi.com> Reviewed-by:
Eric Moore <Eric.moore@lsi.com> Signed-off-by:
-
Kashyap, Desai authored
commit 34a03bef upstream. Changing SDEV Running state from interrupt context. Previously It was handle in work queue thread. With this change It will not wait for work queue thread to execute scsih_ublock_io_device to put SDEV into Running state. This will reduce delay for Device becoming RUNNING. Modified this patch considering James comment "Not to change SDEV state using scsi_device_set_state API, instead use scsi_internal_device_unblock scsi_internal_device_block API" Signed-off-by:
-
Kashyap, Desai authored
commit 155dd4c7 upstream. This patch renames the flag for indicating host reset from ioc_reset_in_progress to shost_recovery. It also removes the spin locks surrounding the setting of this flag, which are unnecessary. Sanity checks on the shost_recovery flag were added thru out the code so as to prevent sending firmware commands during host reset. Also, the setting of the shost state to SHOST_RECOVERY was removed to prevent deadlocks, this is actually better handled by the shost_recovery flag. Signed-off-by:
-
Kashyap, Desai authored
commit cd4e12e8 upstream. Following host reset its possible that the controller firmware could assign new handles for devices, as well as adding or deleting devices. There is code in the driver that will rescan the topology folowing host reset; updating device handles, and remove devices that are no longer responding. This patch will improve the responsivness by moving this rescaning from the delayed hotplug worker thread to immediately following the host reset. Signed-off-by:
-
Michal Schmidt authored
commit e71044ee upstream. When the allocation fails in sg_build_indirect(), an oops happens in the error path. It's caused by an obvious typo. Signed-off-by:
Michal Schmidt <mschmidt@redhat.com> Reported-by:
Bob Tracy <rct@gherkin.frus.com> Acked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
- 09 Sep, 2009 2 commits
-
-
Linus Torvalds authored
-
Ed Cashin authored
Andy Whitcroft reported an oops in aoe triggered by use of an incorrectly initialised request_queue object: [ 2645.959090] kobject '<NULL>' (ffff880059ca22c0): tried to add an uninitialized object, something is seriously wrong. [ 2645.959104] Pid: 6, comm: events/0 Not tainted 2.6.31-5-generic #24-Ubuntu [ 2645.959107] Call Trace: [ 2645.959139] [<ffffffff8126ca2f>] kobject_add+0x5f/0x70 [ 2645.959151] [<ffffffff8125b4ab>] blk_register_queue+0x8b/0xf0 [ 2645.959155] [<ffffffff8126043f>] add_disk+0x8f/0x160 [ 2645.959161] [<ffffffffa01673c4>] aoeblk_gdalloc+0x164/0x1c0 [aoe] The request queue of an aoe device is not used but can be allocated in code that does not sleep. Bruno bisected this regression down to cd43e26f block: Expose stacked device queues in sysfs "This seems to generate /sys/block/$device/queue and its contents for everyone who is using queues, not just for those queues that have a non-NULL queue->request_fn." Addresses http://bugs.launchpad.net/bugs/410198 Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13942 Note that embedding a queue inside another object has always been an illegal construct, since the queues are reference counted and must persist until the last reference is dropped. So aoe was always buggy in this respect (Jens). Signed-off-by:
Ed Cashin <ecashin@coraid.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Bruno Premont <bonbons@linux-vserver.org> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
