Bug#634023: linux-source-2.6.32: Kernel panic when inserting usb stick

Bug#634023: linux-source-2.6.32: Kernel panic when inserting usb stick

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 5022 bytes --]

This oops (and consequent panic) was reported as occurring when a USB
stick is inserted, and as being a regression between Debian's package
version 2.6.32-34squeeze1 (longterm 2.6.32.39) and 2.6.32-35 (longterm
2.6.32.41).

On Sat, 2011-07-16 at 12:22 +0200, Simon Brandmair wrote:
> Netconsole output:
> 
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
> IP: [<ffffffff81128b5b>] elv_queue_empty+0x1b/0x30
> PGD 12a8cc067 PUD 12ae62067 PMD 0
> Oops: 0000 [#1]
> sd 6:0:0:0: [sdb] 1994752 512-byte logical blocks: (1.02 GB/974 MiB)
> SMP
> last sysfs file:  
> /sys/devices/pci0000:00/0000:00:13.5/usb1/1-10/1-10:1.0/host6/scsi_host/host6/uevent
> CPU 1
> Modules linked in: usb_storage uvcvideo videodev v4l1_compat
> sd 6:0:0:0: [sdb] Write Protect is off
> sd 6:0:0:0: [sdb] Mode Sense: 43 00 00 00
> sd 6:0:0:0: [sdb] Assuming drive cache: write through
> usb-storage: device scan complete
>   v4l2_compat_ioctl32 netconsole powernow_k8 fuse nfsd exportfs nfs lockd  
> auth_rpcgss sunrpc psmouse sha256_generic ansi_cprng krng eseqiv rng  
> aes_x86_64 aes_generic cbc cryptomgr crypto_hash aead pcompress dm_crypt  
> crypto_blkcipher crypto_algapi crypto dm_mod usbhid snd_hda_codec_realtek  
> snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy  
> snd_seq_oss snd_seq_midi_event snd_seq sg
> sd 6:0:0:0: [sdb] Assuming drive cache: write through
>   sdb: snd_timer snd_seq_device sr_mod firewire_ohci firewire_core snd cdrom  
> r8169 bitrev soundcore crc_itu_t crc32 sdb1
>   ohci_hcd ehci_hcd rtc_cmos snd_page_alloc usbcore pata_atiixp evdev  
> rtc_core mii ide_pci_generic rtc_lib k10temp hwmon button processor sd_mod  
> thermal thermal_sys [last unloaded: nvidia]
> Pid: 7, comm: ksoftirqd/1 Tainted: P           2.6.32-20110716 #1 MS-7388

This was built from a custom configuration; Simon can presumably provide
the configuration if required.

The proprietary module is presumably 'nvidia' and hopefully not
responsible for messing with block devices.

> RIP: 0010:[<ffffffff81128b5b>]  [<ffffffff81128b5b>] elv_queue_empty+0x1b/0x30
> RSP: 0018:ffff880028283e18  EFLAGS: 00010046
> RAX: 0000000000000000 RBX: ffff88012ccf71c0 RCX: ffff88012aafd6d0
> RDX: ffff88012a8e1900 RSI: 0000000000000246 RDI: ffff88012ccf71c0
> RBP: 0000000000000292 R08: ffff88012aafd6e0 R09: ffff88012f8c4c50
> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88012ccf71c0
> R13: ffff880028283e68 R14: ffff88012fbbe900 R15: ffff88012fa33840
> FS:  00007f429e058700(0000) GS:ffff880028280000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> CR2: 0000000000000040 CR3: 000000012e83e000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process ksoftirqd/1 (pid: 7, threadinfo ffff88012f892000, task  
> ffff88012f88f1d0)
> Stack:
>   ffff88012ccf71c0 ffffffff8112c22a ffff88012ccf71c0 ffffffff8112c438
> <0> ffff88012fa33840 ffff88012fa33800 ffff880028283e68 ffffffff811d5e6a
> <0> ffff88012fa33828 0000000000000246 ffff880028283e68 ffff880028283e68
> Call Trace:
>   <IRQ>
>   [<ffffffff8112c22a>] ? __blk_run_queue+0x1a/0x150
>   [<ffffffff8112c438>] ? blk_run_queue+0x28/0x50
>   [<ffffffff811d5e6a>] ? scsi_run_queue+0xda/0x360
>   [<ffffffff811d6e0b>] ? scsi_next_command+0x3b/0x60
>   [<ffffffff811d79cf>] ? scsi_io_completion+0x32f/0x510
>   [<ffffffff8113110d>] ? blk_done_softirq+0x6d/0x80
>   [<ffffffff8104238d>] ? __do_softirq+0x9d/0x130
>   [<ffffffff8100c27c>] ? call_softirq+0x1c/0x30
>   <EOI>
>   [<ffffffff8100e15d>] ? do_softirq+0x4d/0x80
>   [<ffffffff81041f8f>] ? ksoftirqd+0x6f/0xf0
>   [<ffffffff81041f20>] ? ksoftirqd+0x0/0xf0
>   [<ffffffff8105245e>] ? kthread+0x8e/0xa0
>   [<ffffffff8100c17a>] ? child_rip+0xa/0x20
>   [<ffffffff810523d0>] ? kthread+0x0/0xa0
>   [<ffffffff8100c170>] ? child_rip+0x0/0x20
> Code: eb 94 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec 08 31 c0 48 3b  
> 3f 48 8b 57 18 74 09 48 83 c4 08 c3 0f 1f 40 00 48 8b 02 <48> 8b 50 40 b8 01  
> 00 00 00 48 85 d2 74 e6 48 83 c4 08 ff e2 90
> RIP  [<ffffffff81128b5b>] elv_queue_empty+0x1b/0x30
>   RSP <ffff880028283e18>
> CR2: 0000000000000040
> ---[ end trace dd18fad6b2c0435a ]---
[...]

I would guess this is related to one of:

commit 3b4b7c75885a0acde5ff2e3f66eebe98471c3675
Author: James Bottomley <James.Bottomley@suse.de>
Date:   Sun May 1 09:42:07 2011 -0500

    fix oops in scsi_run_queue()
    
    commit c055f5b2614b4f758ae6cc86733f31fa4c2c5844 upstream.

commit 0ccd644ce6a803b4f7ae5b3b4da614b8a51037cc
Author: James Bottomley <James.Bottomley@suse.de>
Date:   Fri Apr 22 10:39:59 2011 -0500

    put stricter guards on queue dead checks
    
    commit 86cbfb5607d4b81b1a993ff689bbd2addd5d3a9b upstream.

Ben.

-- 
Ben Hutchings
Absolutum obsoletum. (If it works, it's out of date.) - Stafford Beer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]