Bug 7862 - sony DSC-600 string display and eject issues.
sony DSC-600 string display and eject issues.
Status: REJECTED INVALID
Product: Drivers
Classification: Unclassified
Component: USB
i386 Linux
: P2 low
Assigned To: Matthew Dharm
:
Depends on:
Blocks: USB
  Show dependency treegraph
 
Reported: 2007-01-21 23:53 UTC by Patrizio Bassi
Modified: 2007-10-10 12:21 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.19.1
Tree: Mainline
Regression: ---


Attachments
last dmesg log from metalog (89.19 KB, text/plain)
2007-08-26 04:19 UTC, Patrizio Bassi
Details
normal dmesg (-n 7) log (29.92 KB, text/plain)
2007-08-26 04:19 UTC, Patrizio Bassi
Details
dmidecode output (21.57 KB, text/plain)
2007-08-26 04:20 UTC, Patrizio Bassi
Details
lsusb info (346 bytes, text/plain)
2007-08-26 04:20 UTC, Patrizio Bassi
Details

Description Patrizio Bassi 2007-01-21 23:53:26 UTC
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
Comment 1 Natalie Protasevich 2007-06-13 19:34:44 UTC
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.
Comment 2 Patrizio Bassi 2007-08-26 04:18:53 UTC
tried with 2.6.22.1 and .5 (last one has usb debug enabled) still there.

attaching some logs.
Comment 3 Patrizio Bassi 2007-08-26 04:19:31 UTC
Created attachment 12541 [details]
last dmesg log from metalog
Comment 4 Patrizio Bassi 2007-08-26 04:19:56 UTC
Created attachment 12542 [details]
normal dmesg (-n 7) log
Comment 5 Patrizio Bassi 2007-08-26 04:20:17 UTC
Created attachment 12543 [details]
dmidecode output
Comment 6 Patrizio Bassi 2007-08-26 04:20:44 UTC
Created attachment 12544 [details]
lsusb info
Comment 7 Patrizio Bassi 2007-09-30 07:51:13 UTC
is the debug info enough? no feedback and no fix in kernel :(
Comment 8 Matthew Dharm 2007-10-10 10:58:33 UTC
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.
Comment 9 Patrizio Bassi 2007-10-10 11:17:22 UTC
i plug the camera than issue

eject /dev/sdc
eject /dev/sdc1

this happens only with this camera not with other usb disks
Comment 10 Matthew Dharm 2007-10-10 11:23:32 UTC
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.
Comment 11 Patrizio Bassi 2007-10-10 11:32:08 UTC
not it normal what i see from dmesg

i see the continous scsi rescan, looking for partitions...

the sdc1 should desappear
Comment 12 Matthew Dharm 2007-10-10 11:44:12 UTC
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.
Comment 13 Patrizio Bassi 2007-10-10 11:54:13 UTC
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.
Comment 14 Matthew Dharm 2007-10-10 12:00:20 UTC
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".
Comment 15 Patrizio Bassi 2007-10-10 12:15:55 UTC
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
Comment 16 Matthew Dharm 2007-10-10 12:21:52 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.