Bug 473017

Same error here on FC10:

kernel: 2.6.27.5-117.fc10.i686

Output in /var/log/messages with the last two lines repeating: 
Nov 29 14:48:04 Tai-Haku kernel: usb 1-1.2: new high speed USB device using ehci
_hcd and address 11
Nov 29 14:48:04 Tai-Haku kernel: usb 1-1.2: configuration #1 chosen from 1 choic
e
Nov 29 14:48:04 Tai-Haku kernel: scsi14 : SCSI emulation for USB Mass Storage de
vices
Nov 29 14:48:04 Tai-Haku kernel: usb 1-1.2: New USB device found, idVendor=059b,
 idProduct=0177
Nov 29 14:48:04 Tai-Haku kernel: usb 1-1.2: New USB device strings: Mfr=1, Produ
ct=2, SerialNumber=3
Nov 29 14:48:04 Tai-Haku kernel: usb 1-1.2: Product: Desktop Hard Drive	
Nov 29 14:48:04 Tai-Haku kernel: usb 1-1.2: Manufacturer: IOMEGA
Nov 29 14:48:04 Tai-Haku kernel: usb 1-1.2: SerialNumber: 77000000000647D9
Nov 29 14:48:09 Tai-Haku kernel: scsi 14:0:0:0: Direct-Access     HDS72808 0PLAT
20          PF2O PQ: 0 ANSI: 0
Nov 29 14:48:09 Tai-Haku kernel: sd 14:0:0:0: [sdf] 160836481 512-byte hardware 
sectors (82348 MB)
Nov 29 14:48:09 Tai-Haku kernel: sd 14:0:0:0: [sdf] Write Protect is off
Nov 29 14:48:09 Tai-Haku kernel: sd 14:0:0:0: [sdf] Assuming drive cache: write 
through
Nov 29 14:48:09 Tai-Haku kernel: sd 14:0:0:0: [sdf] 160836481 512-byte hardware 
sectors (82348 MB)
Nov 29 14:48:09 Tai-Haku kernel: sd 14:0:0:0: [sdf] Write Protect is off
Nov 29 14:48:09 Tai-Haku kernel: sd 14:0:0:0: [sdf] Assuming drive cache: write 
through
Nov 29 14:48:09 Tai-Haku kernel: sdf: sdf1
Nov 29 14:48:09 Tai-Haku kernel: sd 14:0:0:0: [sdf] Attached SCSI disk
Nov 29 14:48:09 Tai-Haku kernel: sd 14:0:0:0: Attached scsi generic sg7 type 0
Nov 29 14:48:09 Tai-Haku kernel: sd 14:0:0:0: [sdf] Sense Key : No Sense [curren
t] 
Nov 29 14:48:09 Tai-Haku kernel: sd 14:0:0:0: [sdf] Add. Sense: No additional se
nse information


I found the relating Issue (https://bugzilla.redhat.com/show_bug.cgi?id=473035) but the mentioned udev rule does not exist in /etc/udev/rules.d. A manually copied rule from /lib/udev/rules.d/60-persistent-storage.rules to /etc/udev/rules.d/60-persistent-storage.rules could not solve the problem. The replacement of the line mentioned in #473035 could not be performed as it doesn't exist.

I followed the suggestion of Oleg Aprotskiy (oleg) Bug 473035:

edit: /etc/udev/rules.d/60-persistent-storage.rules

change: IMPORT{program}="vol_id --export $tempnode"
to: ENV{DEVTYPE}=="partition", IMPORT{program}="vol_id --export $tempnode"

and it worked for me. I can now access my multi-partition external USB drive with kernel 2.6.27.5-41.fc9.i686.

Thanks. Martin

Ok, my mistake. I tried it out another time and yes it works.

In FC10 you have to:

sudo cp /lib/udev/rules.d/60-persistent-storage.rules /etc/udev/rules.d/60-persistent-storage.rules

edit: /etc/udev/rules.d/60-persistent-storage.rules

change line 62 from: KERNEL!="sr*", IMPORT{program}="vol_id --export $tempnode"
to: KERNEL!="sr*", ENV{DEVTYPE}=="partition", IMPORT{program}="vol_id --export $tempnode"

So it works with kernel 2.6.27.5-117.fc10.i686.

Thanks, Roman

Confirmed the problem and the workaround with kernel-2.6.27.5-117.fc10.i686 and an iomega HD

seems to be caused by this commit 
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=41677cf51fb2c14aa512ecf9410e43eb35560408

But as pointed out in http://bugzilla.kernel.org/show_bug.cgi?id=11843 the main problem might be the USB drives and the kernel.

(In reply to comment #5)
> seems to be caused by this commit 

Yes, but we need to do that. We need to detect raid setups.

(In reply to comment #6)
> But as pointed out in http://bugzilla.kernel.org/show_bug.cgi?id=11843 the main
> problem might be the USB drives and the kernel.

This should fix the loop, and make it working again for most devices, yes.

In general, it's a real problem if we do not probe the disk for raid metadata, because we might risk data corruption by mounting filesystems from raid _members_, and not raid _volumes_.

Some USB devices advertise a wrong size, and cause trouble if we try to access the last sector. So far, unfortunately, we have no convincing idea how not to probe for metadata, or probe in a way to avoid the problem.

reassigning back to kernel

*** Bug 473035 has been marked as a duplicate of this bug. ***

At F10 there is no such problem.

I encountered the same problem with a Blackberry 8130 and an installed SD flash card. I tried the FC10 workaround from Roman and it fixed the issue.  

I had the same issue with the Blackberry (log below) on a Dell Latitude D620 and a MSI K8N motherboard desktop using kernel 2.6.27.5-117.fc10.i686. 

usb 4-1: new full speed USB device using uhci_hcd and address 2
usb 4-1: configuration #1 chosen from 1 choice
scsi4 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usb 4-1: New USB device found, idVendor=0fca, idProduct=0006
usb 4-1: New USB device strings: Mfr=1, Product=4, SerialNumber=3
usb 4-1: Product: RIM Mass Storage Device
usb 4-1: Manufacturer: Research In Motion
usb 4-1: SerialNumber: 38D597D70D946834674656E557FF5596897882D0
usb-storage: device scan complete
scsi 4:0:0:0: Direct-Access     RIM      BlackBerry SD    0001 PQ: 0 ANSI: 4 CCS
sd 4:0:0:0: [sdc] Attached SCSI removable disk
sd 4:0:0:0: Attached scsi generic sg3 type 0
sd 4:0:0:0: [sdc] 3970048 512-byte hardware sectors (2033 MB)
sd 4:0:0:0: [sdc] Write Protect is off
sd 4:0:0:0: [sdc] Mode Sense: 43 00 00 53
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdc] 3970048 512-byte hardware sectors (2033 MB)
sd 4:0:0:0: [sdc] Write Protect is off
sd 4:0:0:0: [sdc] Mode Sense: 43 00 00 53
sd 4:0:0:0: [sdc] Assuming drive cache: write through
 sdc: sdc1
sd 4:0:0:0: [sdc] Sense Key : No Sense [current] 
sd 4:0:0:0: [sdc] Add. Sense: No additional sense information
sd 4:0:0:0: [sdc] Sense Key : No Sense [current] 
sd 4:0:0:0: [sdc] Add. Sense: No additional sense information
sd 4:0:0:0: [sdc] Sense Key : No Sense [current] 
sd 4:0:0:0: [sdc] Add. Sense: No additional sense information
sd 4:0:0:0: [sdc] Sense Key : No Sense [current] 
sd 4:0:0:0: [sdc] Add. Sense: No additional sense information
sd 4:0:0:0: [sdc] Sense Key : No Sense [current] 
sd 4:0:0:0: [sdc] Add. Sense: No additional sense information
sd 4:0:0:0: [sdc] Sense Key : No Sense [current]

Nothing new to add to the diagnosis as this seems complete.

Just logging that the same issue occurs with the Sony Ericsson w595.
The workaround works for this also.

Confirmed the problem and the workaround for kernel 2.6.27.9-159.fc10.i686

Me too -- kernel 2.6.27.10-168.fc10.i686 and Nokia 3110 Classic. Workaround helped.

Sorry one more thing -- it is weird but on the identical model (but two years older) the same computer, with the same kernel, cabel, etc. works reliably without a problem.

Actually, it's not surprising, the root issue is what the device does when
a non-existing sector is read. So a firmware change that either a) reports
correct device size or b) reports correct sense would help. Well, in this
case they made it worse on new phones, apparently, but the same principle
applies.

I can confirm this bug for a Sony Ericsson C902 and Martins workaround also works.

I have this problem on 2.6.27.12-170.2.5.fc10.i686 with Nokia 3120 classic

I have this issue too, I have 2 Nokia 5310 Xpress Music mobilephones, with identical SD chips, both being 1.8GB.
OS is Fedora 10 - 2.6.27.12-170.2.5.fc10.x86_64

With the old one and the old and the new SD chip, there are no problems, when I connect the USB cable /var/log/messages shows:

kernel: usb 2-5: new full speed USB device using ohci_hcd and address 32
kernel: usb 2-5: configuration #1 chosen from 1 choice
kernel: scsi24 : SCSI emulation for USB Mass Storage devices
kernel: usb 2-5: New USB device found, idVendor=0421, idProduct=006a
kernel: usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: usb 2-5: Product: Nokia 5310 XpressMusic
kernel: usb 2-5: Manufacturer: Nokia
kernel: usb 2-5: SerialNumber: 354196020580542
kernel: scsi 24:0:0:0: Direct-Access     Nokia    Nokia 5310 Xpres 0000 PQ: 0 ANSI: 4
kernel: sd 24:0:0:0: [sdc] 3842048 512-byte hardware sectors (1967 MB)
kernel: sd 24:0:0:0: [sdc] Write Protect is off
kernel: sd 24:0:0:0: [sdc] Assuming drive cache: write through
kernel: sd 24:0:0:0: [sdc] 3842048 512-byte hardware sectors (1967 MB)
kernel: sd 24:0:0:0: [sdc] Write Protect is off
kernel: sd 24:0:0:0: [sdc] Assuming drive cache: write through
kernel: sdc: sdc1
kernel: sd 24:0:0:0: [sdc] Attached SCSI removable disk
kernel: sd 24:0:0:0: Attached scsi generic sg4 type 0

And I can mount the phone/chip fine with mount -t vfat /dev/sdc1 /media/Nokia
Then /var/log/messages shows "gnome-keyring-daemon[3104]: adding removable location: volume_uuid_1234_5678 at /media/Nokia"


But with the new phone with old or new SD chip and /var/log/messages show:
kernel: usb 2-5: new full speed USB device using ohci_hcd and address 34
kernel: usb 2-5: configuration #1 chosen from 1 choice                  
kernel: scsi26 : SCSI emulation for USB Mass Storage devices            
kernel: usb 2-5: New USB device found, idVendor=0421, idProduct=006a    
kernel: usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: usb 2-5: Product: Nokia 5310 XpressMusic                         
kernel: usb 2-5: Manufacturer: Nokia                                     
kernel: usb 2-5: SerialNumber: 351934032863644                           
kernel: scsi 26:0:0:0: Direct-Access     Nokia    Nokia 5310 Xpres 0000 PQ: 0 ANSI: 4
kernel: sd 26:0:0:0: [sdc] 3932161 512-byte hardware sectors (2013 MB)               
kernel: sd 26:0:0:0: [sdc] Write Protect is off                                      
kernel: sd 26:0:0:0: [sdc] Assuming drive cache: write through                       
kernel: sd 26:0:0:0: [sdc] 3932161 512-byte hardware sectors (2013 MB)               
kernel: sd 26:0:0:0: [sdc] Write Protect is off                                      
kernel: sd 26:0:0:0: [sdc] Assuming drive cache: write through                       
kernel: sdc:                                                                         
kernel: sd 26:0:0:0: [sdc] Attached SCSI removable disk                              
kernel: sd 26:0:0:0: Attached scsi generic sg4 type 0                                
kernel: sd 26:0:0:0: [sdc] Sense Key : No Sense [current]                            
kernel: sd 26:0:0:0: [sdc] Add. Sense: No additional sense information

Now repeat the last 2 lines indefinitely, and the phone just shows "Transferring Data", and it doesn't stop, I have tried let it run for 20 minutes and it just keeps on going, until I press cancel on the phone, then /var/log/messages shows:
kernel: end_request: I/O error, dev sdc, sector 3932160
kernel: Buffer I/O error on device sdc, logical block 3932160
kernel: usb 2-5: USB disconnect, address 34
kernel: usb 2-5: new full speed USB device using ohci_hcd and address 35
kernel: usb 2-5: configuration #1 chosen from 1 choice
kernel: cdc_acm 2-5:1.1: ttyACM0: USB ACM device
kernel: usb 2-5: bad CDC descriptors
kernel: usb 2-5: bad CDC descriptors
kernel: usb 2-5: New USB device found, idVendor=0421, idProduct=006b
kernel: usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: usb 2-5: Product: Nokia 5310 XpressMusic
kernel: usb 2-5: Manufacturer: Nokia

And mount /dev/sdc(1) -t vfat /media/Nokia fails as there are no /dev/sdc devices present.

Now I know that the new SD chip could be corrupt, but I know for sure the old one isn't, plus the new SD chip works fine in the old phone.

There is 6 months between the purchase of the 2 phones. Aug 13th 2008 and Feb 16th 2009

I have also tried the "workaround" posted above, but with no such luck.


_
Jesper

(In reply to comment #3)

> In FC10 you have to:
> 
> sudo cp /lib/udev/rules.d/60-persistent-storage.rules
> /etc/udev/rules.d/60-persistent-storage.rules
> 
> edit: /etc/udev/rules.d/60-persistent-storage.rules
> 
> change line 62 from: KERNEL!="sr*", IMPORT{program}="vol_id --export $tempnode"
> to: KERNEL!="sr*", ENV{DEVTYPE}=="partition", IMPORT{program}="vol_id --export
> $tempnode"

Thank you Roman. On my 2.6.27.12-170.2.5.fc10.i686 works fine.

(In reply to comment #20)
The honour goes to you Oleg ;) I only followed your suggestion and made it a bit clearer I think. ;)

Although the workaround works in general, the problem may appear again while updating the kernel in case a usb storage is connected in that moment.

The system gets heavy load and the messages appear again so the updater seems to hang while installing the new kernel.

Solution: Disconnect the usb storage to finish the update, then reboot the system.

The udev rule from the "workaround" above will be loaded after reboot so the problem doesn't appear.

As I didn't seek deeper to the heart of the problem I guess when upgrading the kernel the rule in /etc/udev/rules.d will be ignored and the original one in /lib/udev/rules.d will be used instead. But, it's only a guess.

(Problem appeared while updating from kernel 2.6.27.12-170.2.5.fc10.i686 to 2.6.27.12-170.2.24.fc10.i686.)

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I have changed the version number From fc9 to fc10 since this bug affects fc10 as well as fc9. (I am now on fc10)

Thanks to Oleg and Roman for finding work-arounds to the bug for fc9 and fc10.

I just got this issue right now on a kernel-2.6.30.8-64.fc11.x86_64. I have connected an old IBM Deskstar via an USB/PATA adaptor. The workaround from Comment #3 did NOT help.

The cause seems to be the USB to PATA adapter that was used. I tried it with a Fedora 8 Live CD, and got a few "Sense Key : No Sense [current]" messages there too, but eventually the devices were added. When using fdisk, I found out that there were no partitions detected and the drive parameters were all wrong (it's a 160GB drive, but was reported as a 760ish GB drive).

When trying an USB to PATA adapter of another brand on the same machine, the drive and its partitions were detected correctly.

The adapter that caused the trouble here is reported by lsusb as "ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge". The harddisk is a Samsung SP1604N.

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 10 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

The bug still appears with Fedora 12 (kernel 2.6.31.5-127.fc12.x86_64). The dmesg output looks different now:

usb 1-3: new high speed USB device using ehci_hcd and address 9
usb 1-3: New USB device found, idVendor=152d, idProduct=2338
usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=5
usb 1-3: Product: USB to ATA/ATAPI Bridge
usb 1-3: Manufacturer: JMicron
usb 1-3: SerialNumber: 303341295971
usb 1-3: configuration #1 chosen from 1 choice
Initializing USB Mass Storage driver...
scsi5 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 9
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 5:0:0:0: Direct-Access     SAMSUNG  SPq6p4N ` ` ` `  p-s0 PQ: 0 ANSI: 2 CCS
sd 5:0:0:0: Attached scsi generic sg2 type 0
sd 5:0:0:0: [sdb] 1386340016 512-byte logical blocks: (709 GB/661 GiB)
sd 5:0:0:0: [sdb] Write Protect is off
sd 5:0:0:0: [sdb] Mode Sense: 00 38 00 00
sd 5:0:0:0: [sdb] Assuming drive cache: write through
sd 5:0:0:0: [sdb] Assuming drive cache: write through
 sdb: unknown partition table
sd 5:0:0:0: [sdb] Assuming drive cache: write through
sd 5:0:0:0: [sdb] Attached SCSI disk

(Note that it is still the 160GB Samsung SP1604N I mentioned in comment #25.)

Then repeatedly this message until I unplug the USB adapter:

sd 5:0:0:0: [sdb] Unhandled sense code
sd 5:0:0:0: [sdb] Result: hostbyte=DID_ERROR driverbyte=DRIVER_SENSE
sd 5:0:0:0: [sdb] Sense Key : Hardware Error [current] 
sd 5:0:0:0: [sdb] Add. Sense: No additional sense information
end_request: I/O error, dev sdb, sector 1386339840
Buffer I/O error on device sdb, logical block 173292480

Please change the 'version' to '12', as I am not allowed to do so.

I have changed the version number to 12 as there still see to be problems here.

I will be changing to ferdora 12 myself very soon.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.