please add support for Sony DSC-S600 after plugging my Sony DSC-S600 photocamera i have: Bus 001 Device 003: ID 054c:0010 Sony Corp. DSC-S30/S70/S75/F505V/F505/FD92 Cybershot/Mavica Digital Camera i think S600 should be added to the list. minor issue, just cosmetic Apart the name the other issue seems the "eject" command is not working. using usb-storage module: eject /dev/sdc eject /dev/sdc1 even if i repeat several times the sdc1 device doesn't desappear as for other usb devices such as an usb pen or ipod. i have to manually turn off the camera. on windows (!!) i can shutdown the usb link
Could you please provide some information such as: compile kernel with DEBUG_USB and increase the logging level with "dmesg -n 7", then you can get /var/log/messages with debug information. And please provide more information on your system, such as dmidecode output. Thanks.
tried with 2.6.22.1 and .5 (last one has usb debug enabled) still there. attaching some logs.
Created attachment 12541 [details] last dmesg log from metalog
Created attachment 12542 [details] normal dmesg (-n 7) log
Created attachment 12543 [details] dmidecode output
Created attachment 12544 [details] lsusb info
is the debug info enough? no feedback and no fix in kernel :(
It is difficult to interpret your logs without knowing what you did (exact steps) to produce them. However, given a quick examination, I do not see any usb-storage error here. You might try turning off USB Autosuspend, as that has been known to cause problems for many USB devices.
i plug the camera than issue eject /dev/sdc eject /dev/sdc1 this happens only with this camera not with other usb disks
So? I see nothing wrong. You issue the eject commands, and I see no errors. The /dev/sdc should not disappear unless the camera chooses to disconnect from the USB bus, which would be unusual.
not it normal what i see from dmesg i see the continous scsi rescan, looking for partitions... the sdc1 should desappear
No, sdc1 should not necessarily disappear. That behavior is implementation-dependent on the device, not on Linux. As for the rescan, that is probably HALD or somesuch noticing a media-change pending on the 'ejected' camera, and thus normal. This is not a bug. I'm closing this issue.
no this is an issue. i don't have hald nor any other daemon, only udev. no other devices behave like this, only this camera. This is definetively an issue.
No, it's not an issue. The vast majority of devices do not disappear when you issue and eject. Imagine a device with actuall removeable media (CF, Zip, CD-ROM, etc. etc.) -- it would make no sense for these devices to disappear when "ejected".
again...for me the device not desappearing is not the issue. the issue is that after the eject command there is a rescan of the device. this doesn't happen with other devices. why? i show what i mean...i did 4 times eject /dec/sdc...i got: usb 1-1: new high speed USB device using ehci_hcd and address 2 usb 1-1: configuration #1 chosen from 2 choices Initializing USB Mass Storage driver... scsi10 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning usbcore: registered new interface driver usb-storage USB Mass Storage support registered. usb-storage: device scan complete scsi 10:0:0:0: Direct-Access Sony Sony DSC 6.00 PQ: 0 ANSI: 0 CCS sd 10:0:0:0: [sdc] 2007040 512-byte hardware sectors (1028 MB) sd 10:0:0:0: [sdc] Write Protect is off sd 10:0:0:0: [sdc] Mode Sense: 00 00 00 00 sd 10:0:0:0: [sdc] Assuming drive cache: write through sd 10:0:0:0: [sdc] 2007040 512-byte hardware sectors (1028 MB) sd 10:0:0:0: [sdc] Write Protect is off sd 10:0:0:0: [sdc] Mode Sense: 00 00 00 00 sd 10:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 sd 10:0:0:0: [sdc] Attached SCSI removable disk sd 10:0:0:0: [sdc] 2007040 512-byte hardware sectors (1028 MB) sd 10:0:0:0: [sdc] Write Protect is off sd 10:0:0:0: [sdc] Mode Sense: 00 00 00 00 sd 10:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 sd 10:0:0:0: [sdc] 2007040 512-byte hardware sectors (1028 MB) sd 10:0:0:0: [sdc] Write Protect is off sd 10:0:0:0: [sdc] Mode Sense: 00 00 00 00 sd 10:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 sd 10:0:0:0: [sdc] 2007040 512-byte hardware sectors (1028 MB) sd 10:0:0:0: [sdc] Write Protect is off sd 10:0:0:0: [sdc] Mode Sense: 00 00 00 00 sd 10:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 this is not normal
This is unusual, but not unheard of. The 'eject' command actually issues several commands to the device in the eject sequence. If one of them returns with a "Unit attention: Not ready to ready transition" or similar error code, then it will trigger a "revalidation", which will cause the rescan. It's completely harmless, and not fixable. The device is almost certainly sending a ASC/ASCQ which requires revalidation. It probably shouldn't do that, but it does. There is no fix for this, as we cannot ignore such needs to perform revalidation.