Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#27320 - [linux] kernel crash, null pointer dereference (3.1.2-1: scsi_execute)

Attached to Project: Arch Linux
Opened by Vedant Kumar (vsk) - Tuesday, 29 November 2011, 05:10 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 22 February 2012, 16:37 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

linux 3.1.2-1 crashes when I remove a usb device incorrectly. The trace reports a NULL dereference bug.

I've looked at the logs in  FS#26221  (https://bugs.archlinux.org/task/26221). It points to issues in scsi/sdb as well, but I don't think this is a duplicate.

Steps to reproduce:
* My ipod was fully powered off when I connected it to my laptop.
* The ipod didn't turn on, so I did this;

6265:Nov 27 00:24:33 vk sudo: vk : TTY=pts/0 ; PWD=/dev ; USER=root ; COMMAND=/bin/mount /dev/sdb
6283:Nov 27 00:33:22 vk sudo: vk : TTY=pts/1 ; PWD=/home/vk ; USER=root ; COMMAND=/sbin/hdparm -i /dev/sdb
138829:Nov 27 00:07:05 vk udevd[1831]: timeout '/sbin/blkid -o udev -p /dev/sdb'

* That hung, so I did this;

139181:Nov 27 00:12:57 vk udevd[1831]: timeout: killing '/sbin/blkid -o udev -p /dev/sdb' [1928]
139182:Nov 27 00:12:57 vk udevd[1831]: '/sbin/blkid -o udev -p /dev/sdb' [1928] terminated by signal 9 (Killed)
139183:Nov 27 00:12:57 vk udevd[1831]: timeout 'udisks-part-id /dev/sdb'
139184:Nov 27 00:12:58 vk udevd[1831]: timeout: killing 'udisks-part-id /dev/sdb' [2169]
218756:Nov 27 00:34:10 vk udevd[2365]: timeout: killing '/sbin/blkid -o udev -p /dev/sdb' [2505]

* That hung again, so I tried killing it several times (see logs). Then the device showed signs of life;

218757:Nov 27 00:34:11 vk udevd[2365]: '/sbin/blkid -o udev -p /dev/sdb' [2505] terminated by signal 9 (Killed)
817818:Nov 27 00:03:48 vk kernel: [ 340.492484] sd 6:0:0:0: [sdb] Spinning up disk...scsi: killing requests for dead queue
817852:Nov 27 00:06:04 vk kernel: [ 476.212298] sd 6:0:0:0: [sdb] READ CAPACITY failed
817853:Nov 27 00:06:04 vk kernel: [ 476.212305] sd 6:0:0:0: [sdb] Result: hostbyte=0x00 driverbyte=0x08
817854:Nov 27 00:06:04 vk kernel: [ 476.212311] sd 6:0:0:0: [sdb] Sense Key : 0x2 [current]
817855:Nov 27 00:06:04 vk kernel: [ 476.212317] sd 6:0:0:0: [sdb] ASC=0x4 ASCQ=0x1
817856:Nov 27 00:06:04 vk kernel: [ 476.213411] sd 6:0:0:0: [sdb] Write Protect is off
817857:Nov 27 00:06:04 vk kernel: [ 476.213417] sd 6:0:0:0: [sdb] Mode Sense: 68 00 00 08
817858:Nov 27 00:06:04 vk kernel: [ 476.214538] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
817865:Nov 27 00:06:45 vk kernel: [ 517.063917] sd 6:0:0:0: [sdb] Spinning up disk...

* The "Spinning up disk...", "READ CAPACITY failed" messages repeated for a while.. finally, the kernel crashed when I removed the device in frustration;

819600:Nov 27 00:34:10 vk kernel: [ 2163.013320] BUG: unable to handle kernel NULL pointer dereference at 0000000000000398
819601:Nov 27 00:34:10 vk kernel: [ 2163.013403] IP: [<ffffffff8120e3e9>] blk_get_request+0x19/0xb0
819625:Nov 27 00:34:10 vk kernel: [ 2163.015754] Call Trace:
819626:Nov 27 00:34:10 vk kernel: [ 2163.015793] [<ffffffffa014b25f>] scsi_execute+0x4f/0x180 [scsi_mod]
819627:Nov 27 00:34:10 vk kernel: [ 2163.015858] [<ffffffffa014b43a>] scsi_execute_req+0xaa/0x120 [scsi_mod]
819628:Nov 27 00:34:10 vk kernel: [ 2163.015922] [<ffffffffa005b18e>] sd_revalidate_disk+0xde/0x1c90 [sd_mod]
819629:Nov 27 00:34:10 vk kernel: [ 2163.015980] [<ffffffff81192b30>] ? bdev_test+0x20/0x20
819630:Nov 27 00:34:10 vk kernel: [ 2163.016027] [<ffffffff811c5f1a>] rescan_partitions+0xaa/0x4d0
819631:Nov 27 00:34:10 vk kernel: [ 2163.016081] [<ffffffff8119449e>] __blkdev_get+0x2ce/0x430
819632:Nov 27 00:34:10 vk kernel: [ 2163.016132] [<ffffffff81194653>] blkdev_get+0x53/0x310
819633:Nov 27 00:34:10 vk kernel: [ 2163.016177] [<ffffffff81176956>] ? unlock_new_inode+0x56/0x80
819634:Nov 27 00:34:10 vk kernel: [ 2163.016229] [<ffffffff8119350f>] ? bdget+0x11f/0x140
819635:Nov 27 00:34:10 vk kernel: [ 2163.016274] [<ffffffff8119496d>] blkdev_open+0x5d/0x80
819636:Nov 27 00:34:10 vk kernel: [ 2163.016320] [<ffffffff8115b48c>] __dentry_open+0x21c/0x3f0
819637:Nov 27 00:34:10 vk kernel: [ 2163.016369] [<ffffffff81194910>] ? blkdev_get+0x310/0x310
819638:Nov 27 00:34:10 vk kernel: [ 2163.016418] [<ffffffff8115c891>] nameidata_to_filp+0x71/0x80
819639:Nov 27 00:34:10 vk kernel: [ 2163.016468] [<ffffffff8116cb3c>] do_last+0x32c/0x9d0
819640:Nov 27 00:34:10 vk kernel: [ 2163.016512] [<ffffffff8116d2f2>] path_openat+0xd2/0x3c0
819641:Nov 27 00:34:10 vk kernel: [ 2163.016560] [<ffffffff81124ce4>] ? handle_mm_fault+0x1b4/0x350
819642:Nov 27 00:34:10 vk kernel: [ 2163.016560] [<ffffffff8122b190>] ? rb_insert_color+0x110/0x150
819643:Nov 27 00:34:10 vk kernel: [ 2163.016560] [<ffffffff8116d702>] do_filp_open+0x42/0xa0
819644:Nov 27 00:34:10 vk kernel: [ 2163.016560] [<ffffffff81179ccc>] ? alloc_fd+0xec/0x140
819645:Nov 27 00:34:10 vk kernel: [ 2163.016560] [<ffffffff8115c997>] do_sys_open+0xf7/0x1d0
819646:Nov 27 00:34:10 vk kernel: [ 2163.016560] [<ffffffff8115ca90>] sys_open+0x20/0x30
819647:Nov 27 00:34:10 vk kernel: [ 2163.016560] [<ffffffff8140a442>] system_call_fastpath+0x16/0x1b
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Wednesday, 22 February 2012, 16:37 GMT
Reason for closing:  Upstream
Comment by Vedant Kumar (vsk) - Tuesday, 29 November 2011, 05:12 GMT
I forgot to attach the logs:

Loading...