From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.5a) Gecko/20030811 Mozilla Firebird/0.6.1 Description of problem: devlabel has somesort of bug, when I try to mount an archos (usb mass storage), it won't mount. Version-Release number of selected component (if applicable): devlabel-0.41.01-1.1.i386.rpm How reproducible: Always Steps to Reproduce: 1.plug in archos jukebox 2.mount /dev/sda1 /mnt/archos Actual Results: scsi_unique_id and mount hang I can't kill them or anything. I have to reboot the computer Expected Results: sda1 should be mounted under /mnt/archos Additional info: I downgraded to devlabel-0.26.08-3 and everything works perfectly fine. This is from /var/log/messages Oct 2 23:51:41 x1-6-00-a0-cc-35-d1-74 kernel: hub.c: new USB device 00:07.2-1, assigned address 3 Oct 2 23:51:41 x1-6-00-a0-cc-35-d1-74 kernel: usb.c: USB device 3 (vend/prod 0xe79/0x1) is not claimed by any active driver. Oct 2 23:51:45 x1-6-00-a0-cc-35-d1-74 /etc/hotplug/usb.agent: Setup usb-storage for USB product e79/1/1 Oct 2 23:51:49 x1-6-00-a0-cc-35-d1-74 kernel: Initializing USB Mass Storage driver... Oct 2 23:51:49 x1-6-00-a0-cc-35-d1-74 kernel: usb.c: registered new driver usb-storage Oct 2 23:51:49 x1-6-00-a0-cc-35-d1-74 kernel: scsi1 : SCSI emulation for USB Mass Storage devices Oct 2 23:51:49 x1-6-00-a0-cc-35-d1-74 kernel: Vendor: HITACHI_ Model: DK23DA-20 Rev: 00J2 Oct 2 23:51:49 x1-6-00-a0-cc-35-d1-74 kernel: Type: Direct-Access ANSI SCSI revision: 02 Oct 2 23:51:49 x1-6-00-a0-cc-35-d1-74 kernel: Attached scsi disk sda at scsi1, channel 0, id 0, lun 0 Oct 2 23:51:49 x1-6-00-a0-cc-35-d1-74 kernel: SCSI device sda: 39070081 512-byte hdwr sectors (20004 MB) Oct 2 23:51:49 x1-6-00-a0-cc-35-d1-74 kernel: sda: sda1 Oct 2 23:51:49 x1-6-00-a0-cc-35-d1-74 kernel: USB Mass Storage support registered. Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: usb.c: USB disconnect on device 00:07.2-1 address 3 Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: Unable to handle kernel paging request at virtual address 6b6b6b87 Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: printing eip: Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: d2b83329 Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: *pde = 00000000 Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: Oops: 0000 Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: usb-storage tuner tvaudio bttv i2c-algo-bit i2c-core videodev nls_iso8859-1 udf binfmt_misc emu10k1 ac97_codec sound soundcore parport_pc lp parport sd_mod au Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: CPU: 0 Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: EIP: 0060:[<d2b83329>] Not tainted Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: EFLAGS: 00010202 Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: EIP is at usb_submit_urb_R57207d49 [usbcore] 0x19 (2.4.22-1.2061.nptl) Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: eax: 6b6b6b6b ebx: 000001f4 ecx: cc879ed4 edx: ccec7e0c Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: esi: cacb6384 edi: cc878000 ebp: cc879ebc esp: cc879ea4 Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: ds: 0068 es: 0068 ss: 0068 Oct 2 23:52:46 x1-6-00-a0-cc-35-d1-74 kernel: Process scsi_eh_1 (pid: 3623, stackpage=cc879000) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: Stack: d2b83408 ccec7e0c c12c70a0 00000080 ccec7e0c 00000246 cc879ed4 cc879ed4 Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: 00000000 00000000 00000000 cc878000 cc879ebc cc879ebc 00000000 cacb6384 Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: 00000000 ce209a00 d2b83553 ccec7e0c 000001f4 cc879efc ce209a00 d2b835df Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: Call Trace: [<d2b83408>] usb_start_wait_urb [usbcore] 0x78 (0xcc879ea4) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: [<d2b83553>] usb_internal_control_msg [usbcore] 0x53 (0xcc879eec) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: [<d2b835df>] usb_control_msg_Rdb72bbb9 [usbcore] 0x7f (0xcc879f00) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: [<d2b93920>] usb_address0_sem [usbcore] 0x0 (0xcc879f28) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: [<d2b84373>] usb_set_address_R986d748e [usbcore] 0x43 (0xcc879f38) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: [<d2b86e11>] usb_reset_device_R3e534e51 [usbcore] 0xa1 (0xcc879f60) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: [<d2d152a8>] bus_reset [usb-storage] 0x58 (0xcc879f7c) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: [<d2c0381d>] scsi_try_bus_reset [scsi_mod] 0x3d (0xcc879f98) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: [<d2c041fc>] scsi_unjam_host [scsi_mod] 0x5fc (0xcc879fa8) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: [<d2c04716>] scsi_error_handler [scsi_mod] 0x106 (0xcc879fcc) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: [<d2c04610>] scsi_error_handler [scsi_mod] 0x0 (0xcc879fe4) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: [<c01072dd>] kernel_thread_helper [kernel] 0x5 (0xcc879ff0) Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: Oct 2 23:52:47 x1-6-00-a0-cc-35-d1-74 kernel: Code: 8b 40 1c 85 c0 75 06 b8 ed ff ff ff c3 52 ff 50 0c 59 c3 8d
David, out of curiousity, what does your /proc/partitions look like with your archos attached? Does it happen to show erroneous partitions on it like /dev/sda2,3, etc?
Arjan, please see Issue Tracker #29593 as I believe we are seeing other instances of these system lock-ups.
OK. It seems that devlabel attempted to issue a bus reset, and that forced a disconnect. Gary can work on the spurious reset, while I'm interested in oops prevention if a reset does happen. I would like to see copies of /proc/scsi/usb-storage-0/1 or whatever is present there, and /proc/bus/usb/devices.
Devlabel does not do bus resets. However, we have seen similar behavior on an old cdrom whose device showed up in /proc/partitions and to which devlabel attempted to query for an id. We believed at that time, that the repeated requests of the device for an id caused it to issue a bus-reset which also resulted in some humorous continual ejecting of the cdrom drive when you plugged in a usb key. The latest devlabel (0.43.16) has the idea of an "ignore_list". In this file it keeps all devices and/or partitions which do not return identifiers and which should thus be left alone. The user saw his issue disappear by downgrading to an old devlabel which was not as zealous in its naming scheme. However, he could have also have upgraded to 43.16 where devlabel tempered its ways. This fixed our bus-resetting cdrom.
David, did 2.4.22-1.2140 work for you? It has my fix for the oops-on disconnect in usb-storage. Mind, it won't prevent the disconnect, but at least the box won't hang.
Created attachment 96963 [details] /proc/bus/usb/devices & transport
So, how is FC2 going for you, David?
fc1 - eol.