Bug 7862

Summary:	sony DSC-600 string display and eject issues.
Product:	Drivers	Reporter:	Patrizio Bassi (patrizio.bassi)
Component:	USB	Assignee:	Matthew Dharm (mdharm-usb)
Status:	REJECTED INVALID
Severity:	low	CC:	kristen.c.accardi, mchehab, mdharm-usb, protasnb
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6.19.1	Subsystem:
Regression:	---	Bisected commit-id:
Bug Depends on:
Bug Blocks:	5089
Attachments:	last dmesg log from metalog normal dmesg (-n 7) log dmidecode output lsusb info

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.