Bug 55650
| Summary: | updfstab pegs when digital camera is added or removed | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <mjinks> |
| Component: | kudzu | Assignee: | Bill Nottingham <notting> |
| Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.1 | CC: | rvokal |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-11-05 18:18:22 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Need Real Name
2001-11-04 01:28:15 UTC
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. |