From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011013 Description of problem: I have a Sony DSC-S50 "CyberShot" digital camera. Whenever the camera is plugged in or removed from my system, an instance of "updfstab" appears and pegs the processor. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Plug in or remove camera; make sure relevant USB modules are loaded Actual Results: "updfstab" goes to town. "kill -15" sends it away until the next time. Expected Results: the device should be allowed to come and go in peace. ;) Additional info: from /var/log/messages (everything looks normal to me): Nov 3 19:22:40 gaea kernel: hub.c: USB new device connect on bus1/1, assigned device number 3 Nov 3 19:22:40 gaea kernel: Manufacturer: Sony Nov 3 19:22:40 gaea kernel: Product: Sony DSC Nov 3 19:22:40 gaea /sbin/hotplug: arguments (usb) env (PWD=/etc/hotplug HOSTNAME=gaea DEVICE=/proc/bus/usb/001/003 INTERFACE=8/255/1 ACTION=add DEBUG=kernel MACHTYPE=i386-redhat-linux-gnu OLDPWD=/ DEVFS=/proc/bus/usb TYPE=0/0/0 SHLVL=1 SHELL=/bin/bash HOSTTYPE=i386 OSTYPE=linux-gnu HOME=/ TERM=dumb PATH=/bin:/sbin:/usr/sbin:/usr/bin PRODUCT=54c/10/210 _=/usr/bin/env) Nov 3 19:22:40 gaea /sbin/hotplug: invoke /etc/hotplug/usb.agent Nov 3 19:22:40 gaea /etc/hotplug/usb.agent: Modprobe and setup usb-storage for USB product 54c/10/210 Nov 3 19:22:55 gaea kernel: usb.c: USB disconnect on device 3 Nov 3 19:22:55 gaea /sbin/hotplug: arguments (usb) env (PWD=/etc/hotplug HOSTNAME=gaea DEVICE=/proc/bus/usb/001/003 INTERFACE=8/255/1 ACTION=remove DEBUG=kernel MACHTYPE=i386-redhat-linux-gnu OLDPWD=/ DEVFS=/proc/bus/usb TYPE=0/0/0 SHLVL=1 SHELL=/bin/bash HOSTTYPE=i386 OSTYPE=linux-gnu HOME=/ TERM=dumb PATH=/bin:/sbin:/usr/sbin:/usr/bin PRODUCT=54c/10/210 _=/usr/bin/env) Nov 3 19:22:55 gaea /sbin/hotplug: invoke /etc/hotplug/usb.agent Additional system info: [mjinks@gaea mjinks]$ uname -a Linux gaea 2.4.10-xfs-3 #1 SMP Sun Oct 28 10:16:03 CST 2001 i686 unknown (that's a 2.4.10 kernel with the XFS patches applied on a 2-CPU P-III, intel 440-GX chipset)
failed to include my kudzu version number: [mjinks@gaea mjinks]$ rpm -q kudzu kudzu-0.98.10-1
Can you attach /proc/scsi/scsi from your system?
(The camera was not attached when this file was recorded, but it still appears in the devices list -- significant? normal?) [mjinks@gaea mjinks]$ cat /proc/scsi/scsi Attached devices: Host: scsi0 Channel: 00 Id: 05 Lun: 00 Vendor: QUANTUM Model: ATLAS_V_36_WLS Rev: 0210 Type: Direct-Access ANSI SCSI revision: 03 Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: MATSHITA Model: CD-R CW-7503 Rev: 1.09 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: Sony Model: Sony DSC Rev: 2.10 Type: Direct-Access ANSI SCSI revision: 02
What does 'dmesg' say while it's spinning?
Here's an example from the camera being plugged in: hub.c: port 1 enable change, status 100 hub.c: port 1 connection change hub.c: port 1, portstatus 101, change 1, 12 Mb/s hub.c: port 1, portstatus 103, change 0, 12 Mb/s hub.c: USB new device connect on bus1/1, assigned device number 5 usb.c: kmalloc IF e5b4d440, numif 1 usb.c: new device strings: Mfr=1, Product=2, SerialNumber=0 usb.c: USB device number 5 default language ID 0x409 Manufacturer: Sony Product: Sony DSC usb-storage: act_altsettting is 0 usb-storage: id_index calculated to be: 17 usb-storage: Array length appears to be: 54 usb-storage: Vendor: Sony usb-storage: Product: DSC-S30/S70/S75/505V/F505 usb-storage: USB Mass Storage device detected usb-storage: Endpoints: In: 0xd93be3f4 Out: 0xd93be3e0 Int: 0xd93be408 (Period 255) usb-storage: Found existing GUID 054c00100000000000000000 WARNING: USB Mass Storage data integrity not assured USB Mass Storage device found at 5 usb.c: usb-storage driver claimed interface e5b4d440 usb.c: kusbd: /sbin/hotplug add 5 ...and here's a removal: hub.c: port 1 connection change hub.c: port 1, portstatus 100, change 3, 12 Mb/s usb.c: USB disconnect on device 5 usb-storage: storage_disconnect() called usb-storage: -- releasing main URB usb-storage: -- usb_unlink_urb() returned -19 usb.c: kusbd: /sbin/hotplug remove 5 hub.c: port 1 enable change, status 100 During spin, dmesg isn't changing. strace on the updfstab process shows lots of lines like this: mremap(0x40165000, 323584, 323584, MREMAP_MAYMOVE) = 0x40165000 mremap(0x40165000, 323584, 323584, MREMAP_MAYMOVE) = 0x40165000 mremap(0x40165000, 323584, 323584, MREMAP_MAYMOVE) = 0x40165000 mremap(0x40165000, 323584, 323584, MREMAP_MAYMOVE) = 0x40165000 ...with a few exceptions scattered among the mremap lines; here are some examples from my last removal of the camera: read(0, "\n 8 17 63340 sdb1\n 8"..., 4096) = 4096 ... brk(0x8101000) = 0x8101000 ... read(0, " 1 sda2\n 8 5 3462807"..., 4096) = 4096 ... read(0, " 0 35861388 sda\n 8 1"..., 4096) = 4096 ... brk(0x8102000) = 0x8102000 ... (The "..." lines are in place of maybe 20-70 of the mremap() lines. Just in case any of this helps.)
Slight clarification: today I noticed that after the camera hasn't been used for a while, even with the usb modules still loaded in the kernel, just plugging it in isn't enough to elicit the behavior. I also have to send some traffic over the wire, the spin starts as soon as I mount the camera as a filesystem. Afterward, turning on or off starts the spin. Again, just in case it helps.
Exactly which kernel are you using? What happens if you run 'cat /proc/partitions'?
Whoah! Infinite loop. Had to run script in order to catch the top of the output. [mjinks@gaea mjinks]$ cat /proc/partitions major minor #blocks name 8 0 35861388 sda 8 1 1228941 sda1 8 2 1 sda2 8 5 34628076 sda5 8 16 63424 sdb 8 17 63340 sdb1 8 0 35861388 sda 8 1 1228941 sda1 8 2 1 sda2 8 5 34628076 sda5 8 16 63424 sdb 8 17 63340 sdb1 8 0 35861388 sda 8 1 1228941 sda1 8 2 1 sda2 8 5 34628076 sda5 8 16 63424 sdb 8 17 63340 sdb1 ...and this continues on until I interrupt it. FYI, sdb is the camera. which is not currently turned on.
kernel version is 2.4.10 (Linus tree), with the XFS extensions added but no XFS filesystems currently in use.
kernel bug in the scsi disk code (which causes the infinite loop, which confuses kudzu). I believe it's fixed in a later Linus kernel, or in the Red Hat kernels.