JMicron drive 152d:{2329,2338,2339} cause USB resets on ATA smart probing

Hi Scott,

Just curious if this was working with Jaunty? (ie this is a regression). Could you also give the latest mainline kernel build a test to see if the issue remains (currently 2.6.30-rc8) - https://wiki.ubuntu.com/KernelMainlineBuilds . Please let us know your results. Thanks.

Booted into Jaunty desktop Live CD worked fine, kernel 2.6.28-11

It seems between mainline and the ubuntu kernel there is no change:

Trying Mainline kernel:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/

linux-image-2.6.30-020630-generic_2.6.30-020630_i386

  161.572012] usb 1-8: new high speed USB device using ehci_hcd and address 8
[ 161.713059] usb 1-8: configuration #1 chosen from 1 choice
[ 161.713759] scsi9 : SCSI emulation for USB Mass Storage devices
[ 161.714247] usb-storage: device found at 8
[ 161.714250] usb-storage: waiting for device to settle before scanning
[ 166.712138] usb-storage: device scan complete
[ 166.712623] scsi 9:0:0:0: Direct-Access ST375064 0NS PQ: 0 ANSI: 2 CCS
[ 166.713670] sd 9:0:0:0: Attached scsi generic sg6 type 0
[ 166.714603] sd 9:0:0:0: [sdf] 1465149168 512-byte hardware sectors: (750 GB/698 GiB)
[ 166.715348] sd 9:0:0:0: [sdf] Write Protect is off
[ 166.715353] sd 9:0:0:0: [sdf] Mode Sense: 34 00 00 00
[ 166.715356] sd 9:0:0:0: [sdf] Assuming drive cache: write through
[ 166.720468] sd 9:0:0:0: [sdf] Assuming drive cache: write through
[ 166.720474] sdf: sdf1
[ 166.740143] sd 9:0:0:0: [sdf] Attached SCSI disk
[ 166.988020] usb 1-8: reset high speed USB device using ehci_hcd and address 8
[ 167.112015] usb 1-8: device descriptor read/64, error -71
[ 167.340017] usb 1-8: device descriptor read/64, error -71
[ 167.556014] usb 1-8: reset high speed USB device using ehci_hcd and address 8
[ 167.680013] usb 1-8: device descriptor read/64, error -71
[ 167.908018] usb 1-8: device descriptor read/64, error -71
[ 168.124016] usb 1-8: reset high speed USB device using ehci_hcd and address 8
[ 168.532014] usb 1-8: device not accepting address 8, error -71
[ 168.644012] usb 1-8: reset high speed USB device using ehci_hcd and address 8
[ 169.056012] usb 1-8: device not accepting address 8, error -71
[ 169.056062] usb 1-8: USB disconnect, address 8
[ 169.168023] usb 1-8: new high speed USB device using ehci_hcd and address 9
[ 169.292012] usb 1-8: device descriptor read/64, error -71
[ 169.520013] usb 1-8: device descriptor read/64, error -71
[ 169.736017] usb 1-8: new high speed USB device using ehci_hcd and address 10
[ 169.860021] usb 1-8: device descriptor read/64, error -71
[ 170.088016] usb 1-8: device descriptor read/64, error -71
[ 170.304019] usb 1-8: new high speed USB device using ehci_hcd and address 11
[ 170.712010] usb 1-8: device not accepting address 11, error -71
[ 170.824014] usb 1-8: new high speed USB device using ehci_hcd and address 12
[ 171.240012] usb 1-8: device not accepting address 12, error -71
[ 171.240029] hub 1-0:1.0: unable to enumerate USB device on port 8
[ 171.508012] usb 5-2: new full speed USB device using uhci_hcd and address 2
[ 171.628016] usb 5-2: device descriptor read/64, error -71
[ 171.852011] usb 5-2: device descriptor read/64, error -71
[ 172.068015] usb 5-2: new full speed USB device using uhci_hcd and address 3
[ 172.188019] usb 5-2: device descriptor read/64, error -71
[ 172.412013] usb 5-2: device descriptor read/64, error -71
[ 172.628011] usb 5-2: new full speed USB device using uhci_hcd an...

I would like to confirm this bug.

I am experiencing similar problems on Ubuntu karmic with the latest updates and kernel 2.6.30.1 compiled on my own from kernel.org. I have also tried the provided 2.6.31-2-generic kernel, as well as the current Jaunty kernel (2.6.28-11-generic), but the results were the same:

Basically, I get my external USB drive detected, but I don't get the /dev files generated and therefore I cannot access my drive. There are many "device descriptor read/64, error"s and "device not accepting address %NUMBER%" errors followed by "unable to enumerate USB device on port 1" errors in dmesg:

[ 87.256073] usb 1-1: new high speed USB device using ehci_hcd and address 5
[ 87.389479] usb 1-1: New USB device found, idVendor=152d, idProduct=2329
[ 87.389489] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[ 87.389496] usb 1-1: Product: USB to ATA/ATAPI Bridge
[ 87.389502] usb 1-1: Manufacturer: JMicron
[ 87.389506] usb 1-1: SerialNumber: 13D107568FFF
[ 87.389712] usb 1-1: configuration #1 chosen from 1 choice
[ 87.650345] Initializing USB Mass Storage driver...
[ 87.650566] scsi0 : SCSI emulation for USB Mass Storage devices
[ 87.651035] usbcore: registered new interface driver usb-storage
[ 87.653675] USB Mass Storage support registered.
[ 87.681510] usb-storage: device found at 5
[ 87.681518] usb-storage: waiting for device to settle before scanning
[ 92.682146] scsi 0:0:0:0: Direct-Access SAMSUNG HD502IJ PQ: 0 ANSI: 2 CCS
[ 92.682401] usb-storage: device scan complete
[ 92.689322] sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors: (500 GB/465 GiB)
[ 92.692523] sd 0:0:0:0: [sda] Write Protect is off
[ 92.692529] sd 0:0:0:0: [sda] Mode Sense: 34 00 00 00
[ 92.692532] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 92.696598] sd 0:0:0:0: [sda] Assuming drive cache: write through
[ 92.696605] sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 sda9 sda10 >
[ 92.780431] sd 0:0:0:0: [sda] Attached SCSI disk
[ 93.528106] usb 1-1: reset high speed USB device using ehci_hcd and address 5
[ 93.732111] usb 1-1: device descriptor read/64, error -71
[ 94.040092] usb 1-1: device descriptor read/64, error -71
[ 94.256086] usb 1-1: reset high speed USB device using ehci_hcd and address 5
[ 94.460062] usb 1-1: device descriptor read/64, error -71
[ 94.768115] usb 1-1: device descriptor read/64, error -71
[ 94.984117] usb 1-1: reset high speed USB device using ehci_hcd and address 5
[ 95.448078] usb 1-1: device not accepting address 5, error -71
[ 95.560070] usb 1-1: reset high speed USB device using ehci_hcd and address 5
[ 96.024100] usb 1-1: device not accepting address 5, error -71
[ 96.027749] usb 1-1: USB disconnect, address 5
[ 96.144302] usb 1-1: new high speed USB device using ehci_hcd and address 6
[ 96.374593] usb 1-1: device descriptor read/64, error -71
[ 96.680062] usb 1-1: device descriptor read/64, error -71
[ 96.896104] usb 1-1: new high speed USB device using ehci_hcd and address 7
[ 97.100072] usb 1-1: device descriptor read/64, error -71
[ 97.408095] usb 1-1: device descriptor read/64, error -71
[ 97.6...

I can confirm this bug too,
for me was the same things, with the latests kernels I have the similar output with dmesg:

[ 1348.290418] scsi7 : SCSI emulation for USB Mass Storage devices
[ 1348.290711] usb-storage: device found at 19
[ 1348.290716] usb-storage: waiting for device to settle before scanning
[ 1353.289243] usb-storage: device scan complete
[ 1353.291343] scsi 7:0:0:0: Direct-Access WDC WD10 EAVS-00D7B0 PQ: 0 ANSI: 2 CCS
[ 1353.310715] sd 7:0:0:0: Attached scsi generic sg4 type 0
[ 1353.366547] sd 7:0:0:0: [sdd] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
[ 1353.375379] sd 7:0:0:0: [sdd] Write Protect is off
[ 1353.375392] sd 7:0:0:0: [sdd] Mode Sense: 34 00 00 00
[ 1353.375400] sd 7:0:0:0: [sdd] Assuming drive cache: write through
[ 1353.385208] sd 7:0:0:0: [sdd] Assuming drive cache: write through
[ 1353.385227] sdd: sdd1 sdd2
[ 1353.438247] sd 7:0:0:0: [sdd] Assuming drive cache: write through
[ 1353.438265] sd 7:0:0:0: [sdd] Attached SCSI disk
[ 1353.808064] usb 1-4: reset high speed USB device using ehci_hcd and address 19
[ 1354.016068] usb 1-4: device descriptor read/64, error -71
[ 1354.328070] usb 1-4: device descriptor read/64, error -71
[ 1354.544093] usb 1-4: reset high speed USB device using ehci_hcd and address 19
[ 1354.752074] usb 1-4: device descriptor read/64, error -71
[ 1355.064081] usb 1-4: device descriptor read/64, error -71
[ 1355.280061] usb 1-4: reset high speed USB device using ehci_hcd and address 19
[ 1355.752052] usb 1-4: device not accepting address 19, error -71
[ 1355.864049] usb 1-4: reset high speed USB device using ehci_hcd and address 19
[ 1356.336046] usb 1-4: device not accepting address 19, error -71
[ 1356.336145] usb 1-4: USB disconnect, address 19
[ 1356.448053] usb 1-4: new high speed USB device using ehci_hcd and address 20
[ 1356.656087] usb 1-4: device descriptor read/64, error -71
[ 1356.968047] usb 1-4: device descriptor read/64, error -71
[ 1357.184052] usb 1-4: new high speed USB device using ehci_hcd and address 21
[ 1357.392045] usb 1-4: device descriptor read/64, error -71
[ 1357.704046] usb 1-4: device descriptor read/64, error -71
[ 1357.920067] usb 1-4: new high speed USB device using ehci_hcd and address 22
[ 1358.392044] usb 1-4: device not accepting address 22, error -71
[ 1358.504064] usb 1-4: new high speed USB device using ehci_hcd and address 23
[ 1358.976052] usb 1-4: device not accepting address 23, error -71
[ 1358.976100] hub 1-0:1.0: unable to enumerate USB device on port 4
[ 1359.432052] usb 2-4: new full speed USB device using ohci_hcd and address 16
[ 1359.612064] usb 2-4: device descriptor read/64, error -62
[ 1359.896046] usb 2-4: device descriptor read/64, error -62
[ 1360.176079] usb 2-4: new full speed USB device using ohci_hcd and address 17
[ 1360.356063] usb 2-4: device descriptor read/64, error -62
[ 1360.640052] usb 2-4: device des...

Hello,

I would like to let you know that I have, with a great amount of luck, managed to make Ubuntu recognize USB hard drives correctly.

In my case, the problem dissolved when I downgraded the package gvfs to the jaunty version.
I have also uninstalled the devicekit-disks package, which does not have the jaunty version. And suddenly, even without restarting, my USB hard drive just started working again. It is now recognized correctly and actually works.

It is strange. It was quite tricky to find out which packages had been the cause. But fortunately, it was as easy as downgrading and uninstalling them to make my USB hard drive working again.

I hope you will have at least as much succes as I had.

Have a nice day!

Thanks for the information, I did a quick remove without downgrading gvfs and my drive also worked right away.

Looks like devicekit-disks is our problem.

I would just like to confirm that this works for me as well :-)). I did apt-get uninstall devicekit-disks package, then reconnected my USB drive (Argosy enclosure - Western Digital 2.0 TB drive) and it was recognised.

A virtual beer to Mr Peter Basista!!

Can you please open a Terminal and do

  sudo killall devkit-disks-daemon
  sudo /usr/lib/devicekit-disks/devkit-disks-daemon 2>&1 | tee /tmp/devkit-disks.log

and then reproduce the error (i. e. plug in the device, try to mount it). After that, please press Control-C, and attach /tmp/devkit-disks.log here. Thanks!

Yes, no problem. Here it is:

Hm, nothing helpful there, I'm afraid. It just shows that udev and devkit-disks mirror all the add/reset/remove pingpong.

So the next step that comes to my mind is to do

  sudo killall devkit-disks-daemon
  sudo strace -vftt -s 1024 -o /tmp/dk-disks.trace /usr/lib/devicekit-disks/devkit-disks-daemon

then reproduce the situation, and attach /tmp/dk-disks.trace. Warning, this could become quite huge, so perhaps do a

  bzip2 -9 /tmp/dk-disks.trace

before and attach /tmp/dk-disks.trace.bz2 instead

Thanks!

Another thing worth trying is

  echo "blacklist ehci_hcd" | sudo tee /etc/modprobe.d/blacklist-ehci
  sudo update-initramfs -u

then reboot, and try again. This will use the slower USB 1.1 drivers. Does this work?

After this, please clean up again with

  sudo rm /etc/modprobe.d/blacklist-ehci
  sudo update-initramfs -u

and reboot. Thanks!

Sorry, please ignore the blacklisting exercise. All the USB drivers are built in now.

Hello,

I think that the problem is not caused by the executable /usr/lib/devicekit-disks/devkit-disks-daemon. Here is why:

I am now using jaunty, but I tried to generate the trace like Martin Pitt suggested. So I temporarily added the karmic repositories to sources.list and installed these packages:
[INSTALL, DEPENDENCIES] libatasmart0
[INSTALL, DEPENDENCIES] libeggdbus-1-0
[INSTALL, DEPENDENCIES] libgudev-1.0-0
[INSTALL, DEPENDENCIES] libparted1.8-12
[INSTALL, DEPENDENCIES] libpolkit-backend-1-0
[INSTALL, DEPENDENCIES] libpolkit-gobject-1-0
[INSTALL, DEPENDENCIES] libsgutils2-2
[INSTALL] devicekit-disks

And I tried to run /usr/lib/devicekit-disks/devkit-disks-daemon, but there was this error:

/usr/lib/devicekit-disks/devkit-disks-daemon: symbol lookup error: /usr/lib/libgudev-1.0.so.0: undefined symbol: udev_monitor_filter_add_match_subsystem_devtype

So, if I understand correctly, something prevents this application from start and it is not possible to start it until the problem is resolved.

But when I tried to connect my USB hard drive, there were again the same errors as there were with karmic and working devkit-disks-daemon.

So, I assume that this means that this executable is not the cause of the errors - just because it was not running when the problem appeared.

And I am sorry for no trace. The 'undefined symbol' error might be a problem with library versions or something like that. But I don't know which library to look at and to eventually upgrade / downgrade in order to make it working. And I am not that concerned to install karmic again, I am really sorry.

Have a nice day!

I can confirm the bug and the workaround:

Made a fresh install of Alpha 3: USB PATA drives work, but USB SATA does not.

Workaround:
dpkg -r --force-all devicekit-disks

Then USB SATA works fine.

hi i also have the same problem
i bought an SATA to USB case and put my old sata disk in.
and it don't work on karmic ...

i did
sudo killall devkit-disks-daemon
  sudo strace -vftt -s 1024 -o /tmp/dk-disks.trace /usr/lib/devicekit-disks/devkit-disks-daemon
saw some text on screen
put the usb drive in
saw some other text on screen
wait a little, then did a CTRL + C

here is the bzip2 version, hope this will help

Thanks! I looked at the strace and found some oddities:

1274 11:37:08.712674 readlink("/sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda1", 0xbfdd92cc, 1024) = -1 EINVAL (Invalid argument)

(lots of those); this is probably because the device disappears underneath.

I filtered out the "harmless" syscalls with

  egrep -v 'open|read|write|readlink|lstat|fstat|statfs|stat64|socket|close|gettimeofday|poll|access|getdent' dk-disks.trace |less

and couldn't really find anything weird which would cause the device to disappear/disconnect. No ioctl etc. at all. I also checked the source, the daemon does not do any ioctls.

So let's look at the timestamps. Everything until line 2368 is initialization, which isn't an issue here since the drive isn't even plugged in at this point. 2369 is the poll on the udev socket to wait for events.

20 seconds later (11:37:30.797517) there's the recvmsg() to read the uevent for adding sdb, followed by a lot of open() and readlink() on the new node in sysfs, to probe device attributes. Reading sysfs should be a valid operation.

The first non-read call is at 11:37:30.804971, but this is just a writev() to the udev socket, announcing the ADDED signal.

After that there's a similar uevent-probe-signal block for sdb1. This ends at line 2464, timestamp 11:37:30.855906.

Then there's another poll() for uevents, which immediately receives a removal signal from udev. So there is no syscall in between which could trigger this removal event. I suspected as much, but the strace confirms it.

I think a more likely candidate for this behaviour is the callouts in devkit's udev rules. Can folks please all re-install devicekit-disks, do

  sudo mv /lib/udev/rules.d/95-devkit-disks.rules{,.disabled}
  devkit-disks --dump # this will make sure that the daemon is running

then unplug and re-plug the drive, and check if the USB resets still happen then?

Thanks!

If it turns out that moving away the udev rules file helps, please keep the drive plugged in, then do the following commands, and check dmesg after each one for the USB resets. Please note down which command triggers this error.

  sudo /lib/udev/devkit-disks-part-id /dev/sdb
  sudo /lib/udev/devkit-disks-part-id /dev/sdb1
  /lib/udev/devkit-disks-probe-ata-smart /dev/sdb

i did as you asked (as root i did)

reinstall devicekit :
apt-get install --reinstall devicekit-disks
mv /lib/udev/rules.d/95-devkit-disks.rules{,.disabled}

pluged in the drive, and it worked ^^

/lib/udev/devkit-disks-part-id /dev/sdb
DKD_MEDIA_AVAILABLE=1
Entering MS-DOS parser (offset=0, size=160041885696)
MSDOS_MAGIC found
looking at part 0 (offset 32256, size 116511058944, type 0x0b)
new part entry
looking at part 1 (offset 116511091200, size 43528181760, type 0x83)
new part entry
looking at part 2 (offset 0, size 0, type 0x00)
new part entry
looking at part 3 (offset 0, size 0, type 0x00)
new part entry
Exiting MS-DOS parser
MSDOS partition table detected
DKD_PARTITION_TABLE=1
DKD_PARTITION_TABLE_SCHEME=mbr

/lib/udev/devkit-disks-part-id /dev/sdb1
Entering MS-DOS parser (offset=0, size=160041885696)
MSDOS_MAGIC found
looking at part 0 (offset 32256, size 116511058944, type 0x0b)
new part entry
looking at part 1 (offset 116511091200, size 43528181760, type 0x83)
new part entry
looking at part 2 (offset 0, size 0, type 0x00)
new part entry
looking at part 3 (offset 0, size 0, type 0x00)
new part entry
Exiting MS-DOS parser
MSDOS partition table detected
DKD_PARTITION=1
DKD_PARTITION_SCHEME=mbr
DKD_PARTITION_NUMBER=1
DKD_PARTITION_TYPE=0x0b
DKD_PARTITION_SIZE=116511058944
DKD_PARTITION_LABEL=
DKD_PARTITION_UUID=
DKD_PARTITION_FLAGS=

/lib/udev/devkit-disks-probe-ata-smart /dev/sdb
DKD_ATA_SMART_IS_AVAILABLE=1

i attach my 3 dmesg result in case you need them all
but the only command that create the errors is the last one

devkit-disks-probe-ata-smart just calls sk_disk_open() and sk_disk_smart_is_available(), so something in those will most probably trigger the problem. It's not clear to me yet whether libatasmart does an invalid operation, or whether a valid operation triggers a kernel bug, so I keep both tasks open for now. The weird thing is that the calls actually succeed and it detects the SMART capability just fine.

sk_disk_smart_is_available() just checks a bit in a struct, and does not actually do any calls. All the magic is done by sk_disk_open(). What would be required now is someone going through devkit-disks-probe-ata-smart and sk_disk_open() with gdb singlestepping and find out which particular call/ioctl causes the USB resets.

What by and large happens is:

  - readonly open() of the device
  - fstat() and checks if it's a block device
  - BLKGETSIZE64 ioctl
  - some calls to libudev to get vendor, product, and bus type properties from sysfs
  - some SK_ATA_COMMAND_IDENTIFY_DEVICE ATA commands
  - call SK_SMART_COMMAND_ENABLE_OPERATIONS to enable smart if available

Anyone on this bug who understands gdb and can reproduce the problem?

If not, another possible test would be to add lots of sleep() statements to the sk_disk_open() function in a PPA version of libatasmart and compare kernel logs against strace logs to check where the problem happens.

sorry i can not help :(
my gdb knowlegdes are basics

i mean
adding ddebs.ubuntu... to source list
running a programm with gdb
and taking backtrace

obviously this won't help here, because devkit-disks-probe-ata-smart shut down without errors :(
i really wisch i could help more

OK, let's do the good old print/sleep method then. I prepared a debugging version of libatasmart in my PPA which should help us track down the operation which causes trouble. Please go to

  http://ppa.launchpad.net/pitti/ppa/ubuntu/pool/main/liba/libatasmart/

and click on libatasmart0_0.13-1debug1_i386.deb or libatasmart0_0.13-1debug1_amd64.deb, depending on which architecture you installed (if unsure, run "dpkg --print-architecture"). This will spawn gdebi, please allow it to install the new version.

Then please do

  sudo strace -ttvvfs1024 -o /tmp/trace /lib/udev/devkit-disks-probe-ata-smart /dev/sdb

(assuming that the USB SATA disk is still /dev/sdb, and that it's plugged in, etc.). Then attach /var/log/kern.log and /tmp/trace here.

Afterwards, restore the original libatasmart package again to not drag your system to a crawl in other situations:

  sudo apt-get install libatasmart/karmic

(agree to the downgrade).

Thanks for your help!

Sorry, the last command should read

  sudo apt-get install libatasmart0/karmic

ok here they are

Unfortunately klogd seems to lag badly, and the timestamps didn't match up at all. So I uploaded an improved version to my PPA which drops the 2 seconds of sleep and does the logging to the kernel directly.

Can you please do the same exercise again, with 0.13-1debug2 from my PPA? Thanks!

here is the output from debug2 version

holly crap ... i downloaded the wrong deb, please ignore the last submitted file ...
I will do the test again

sorry

here the version with the good debug2 deb

So, I discussed this with upstream:

<mezcalero> if we encounter an USB disk we try to find out if it speaks SAT
<mezcalero> we do that the hard way:
<mezcalero> by sending it some commands
<mezcalero> some shitty bridges tend to hang themselves up due to that
<mezcalero> or reset themselves
<mezcalero> there is not much we can do about that
<mezcalero> we had similar reports regarding usb sticks
<pitti> reportedly the drives pretty much stop working entirely, though
<mezcalero> because an usb stick does not look any different from a HDD drive to libatasmart
<mezcalero> so if you look into the udev rules of dk-disks
<mezcalero> there is now a check based on the disk *size* which disables ata smart
<mezcalero> this catches most of the broken usb sticks
<mezcalero> however, of coruse bridges for HDDs are not covered
<mezcalero> and we need to blacklist them all seperetely
<pitti> mezcalero: interestingly, though, the calls eventually succeed and report that the drive is smart capabl
<mezcalero> pitti: hmm, so yes, i am suggesting you add blacklist rules for this

Not a kernel bug

So these devices need to be blacklisted in /lib//udev/rules.d/95-devkit-disks.rules . Can you please give me the output of

   udevadm info --attribute-walk --name=/dev/sdb

?

Also, can you please install libatasmart-bin, then do

  sudo skdump jmicron:/dev/sdb

and then check if

  sudo /lib/udev/devkit-disks-probe-ata-smart /dev/sdb

still fails?

Sorry, the previous comment was wrong. Please just do

  sudo skdump jmicron:/dev/sdb

and check if that triggers the reset as well? (No probe-ata-smart afterwards).

Please copy&paste the skdump output here in any case.

here the output of udevadm info --attribute-walk --name=/dev/sdb

i can't do what you told me in comment 36

root@ubuntu:/home/alain# apt-get install libatasmart-bin
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
libatasmart-bin est déjà la plus récente version disponible.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.

this mean its already installed (sorry i have a french env)

root@ubuntu:/home/alain# skdump jmicron:/dev/sdb
Failed to open disk jmicron:/dev/sdb: No such file or directory

of course the disk is plugged in and recognized

i tried
root@ubuntu:/home/alain# skdump /dev/sdb
Device: /dev/sdb
Type: JMicron SCSI ATA Passthru
Size: 152627 MiB
Model: [FUJITSU MHZ2160BH G2]
Serial: [K62TT8A27KMF]
Firmware: [00000009]
SMART Available: yes
Quirks:
Awake: Invalid argument
SMART Disk Health Good: Invalid argument
Failed to dump disk data: Invalid argument

and the disk i one more time disconnected
root@ubuntu:/home/alain# ls /dev/sd*
/dev/sda /dev/sda2 /dev/sda5 /dev/sda7 /dev/sda9
/dev/sda1 /dev/sda3 /dev/sda6 /dev/sda8

Everyone else who is affected by this, please also give the output of

  sudo skdump /dev/sd...

and

  sudo skdump jmicron:/dev/sd...

The latest upload of libatasmart fixes the issue for me.
Currently it's in the NEW queue and after it entered the archive you have
to install it manually because of the new library soname libatasmart0 -> libatasmart4

libatasmart 0.14 uploaded and accepted through NEW. I also uploaded a new devicekit-disks which uses the new libatasmart.

Can you please upgrade to devicekit-disks version 005-0ubuntu6 (will be available in some two hours), move back the rules (well, the package upgrade will reinstate them automatically) and check if that fixes the problem for you as well?

If you still have the resets, please include the output of

  sudo skdump /dev/sdb
  sudo skdump jmicron:/dev/sdb

(assuming that sdb is the drive in question), and check if either or both of those commands cause USB resets. Thanks!

Hi ,
 I'm using Ubuntu 9.04 up-to-date and I have this problem when I'm resuming from a previous suspension from RAM.
 I've attach the kernel log that happens after the resume.
 I've read all the thread and I can say that I don't have installed:
   * devicekit-disk (isn't in the repo)
   * libatasmart (isn't in the repo)

I'm using this kernel:
 * Linux XXXXXX 2.6.28-15-generic #48-Ubuntu SMP Wed Jul 29 08:53:35 UTC 2009 x86_64 GNU/Linux

I'm using hibernate-tools (Tuxonice) to hibernate, but I can report the same problem wieht uswsusp and pm-utils.

This problem dosen't happens with kernel 2.6.28-13-generic.

The main problem is that the USB are unsuable after resume, idem the wifi (rtl8187b card plugged into usb).

Thanks!

Andrix [2009-08-07 13:37 -0000]:
> I'm using Ubuntu 9.04 up-to-date and I have this problem

No, I'm afraid you have an entirely different problem. Can you please
open a new bug against the kernel? (with "ubuntu-bug linux"). Thanks!

Oh! thought the problem was similiar! sorry, I will do it!

As I said upgrading libatasmart fixed the issue for me and of course
I also upgraded devicekit-disks and moved back the rules files and unfortunately
the bug is still present. The USB-harddisk is not recognized and dmesg shows me
again all this -71 errors.

I also can't these commands since my harddrive is not present in /dev

so there is no fix ...
i thought that i was crazy, but in fact you were wrong :( (i'm up to date with new versions and bug is still present)

any news about this bug ?

If you still have the issue with version 0.14, please move the udev rules away again with

  sudo mv /lib/udev/rules.d/95-devkit-disks.rules{,.disabled}
  devkit-disks --dump # this will make sure that the daemon is running

and supply the information requested in comment 42.

Ok, moving away the rules files leads the Harddrive to show up.
It appears in /media under the name "4777707B117F74F2".

Running

a) sudo skdump /dev/sdb ejects the harddrive and tells me: Failed to open disk /dev/sdb: Invalid argument
b) sudo skdump jmicron:/dev/sdb ejects the harddrive and tells me: Failed to open disk jmicron:/dev/sdb: No such device

Dmesg log after the eject is attached.

Stefan Ebner [2009-08-25 11:24 -0000]:
> a) sudo skdump /dev/sdb ejects the harddrive and tells me: Failed to open disk /dev/sdb: Invalid argument

Hm, it seems you have a very different problem than other people, the
symtoms are so much different. Can you please open a new bug against
libatasmart and provide the output of

  sudo strace -vv -s 1024 -o /tmp/trace skdump /dev/sdb

after a clean plug in of the drive?

> b) sudo skdump jmicron:/dev/sdb ejects the harddrive and tells me:
> Failed to open disk jmicron:/dev/sdb: No such device

You have to do that after unplugging/replugging the drive, to undo the
effect of the first command's eject.

Can other people who experience this bug please do these commands as
well on current Karmic?

Thanks, Martin

I have the same problem here.
After renaming the udev rules file the disk will show up.
If I then rename the udev file to its old name and invoke one of the skdump commands the disk is unmounted.
The attached file contains both trace dumps and the output of the udevadm command together with some lines denoting what is what.

I've got libatasmart-bin-0.14-1 and devicekit-disks-006-ubuntu1.

Regards
Uli

Even with the rules removed I still need to be quick to do the skdump outputs because my drive still gives the error -71
I wasn't able to get the skdump jmicron output but for sudo skdump /dev/sdf

Device: jmicron:/dev/sdf
Type: JMicron SCSI ATA Passthru
Size: 715404 MiB
Model: [ST3750640NS]
Serial: [3QD136WL]
Firmware: [3.CNQ]
SMART Available: yes
Quirks:
Awake: Invalid argument
SMART Disk Health Good: Invalid argument

oddly now when I remove devicekit-disks I still don't get my disk back where as before this worked.

I reported a duplicate bug: https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/417508

Removing the udev file helps, I'm able to use the disk, when either skdump command is run the resets happen and i need to reconnect the drives.

I've also noticed, but maybe unrelated, that the device notifier of KDE sees:

* Both partition on my disk (FAT/ext3)
* Only FAT partition
* Only ext3 partition

In all cases I'm able to mount the partitions.

@Scott Zawalski:
> I wasn't able to get the skdump jmicron output

You should be able to do that right after pluggin in the drive. After an skdump invocation you need to unplug/replug the drive to reinitialize it.

@Wesley: Can you please also provide the skdump outputs, as described in comment 42?

Thanks!

I forwarded your comments upstream. For those of you who want to bypass me as a bug data relay and talk to upstream directly, please feel free to post/subscribe directly to https://bugzilla.redhat.com/show_bug.cgi?id=515881 .

Sure, I made a mistake with the tarball, here it is.

Device: jmicron:/dev/sdb
ize: 953869 MiB
Model: [WDC WD10EAVS-00D7B0]
Serial: [WD-WCAU42028877]
Firmware: [01.01A01]
SMART Available: yes
Quirks:
Awake: No such device
SMART Disk Health Good: No such device
Failed to dump disk data: No such device

Device: jmicron:/dev/sdb
Type: JMicron SCSI ATA Passthru
Size: 953869 MiB
Model: [WDC WD10EAVS-00D7B0]
Serial: [WD-WCAU42028877]
Firmware: [01.01A01]
SMART Available: yes
Quirks:
Awake: No such device
SMART Disk Health Good: No such device
Failed to dump disk data: No such device

Type: JMicron SCSI ATA Passthru
Size: 953869 MiB
Model: [WDC WD10EAVS-00D7B0]
Serial: [WD-WCAU42028877]
Firmware: [01.01A01]
SMART Available: yes
Quirks:
Awake: Invalid argument
SMART Disk Health Good: Invalid argument

I have the same problem with my external hdd.I use the newest daily version of karmic.

same here..
I tried some blacklisting in /lib/udev/rules.d/95-devkit-disks.rules .

# Check if a disk is ATA SMART capable
#

# USB ATA enclosures with a SAT layer
ATTRS{idVendor}=="152d", ATTRS{idProduct}=="2329", GOTO="check_sat_end"
KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="usb", ENV{DEVTYPE}=="disk", IMPORT{program}="devkit-disks-probe-ata-smart $tempnode"

LABEL="check_sat_end"

Upstream response:

----------------
Unless someone has the hardware in question and wants to fix this for good I
think the only option is to blacklist this device for SMART. DK-disks won't be
able to use the SMART data of these USB bridges then.

Could someone please do the following for me:

Check the results of the following commands on the hdds in question. I'd assume
that they either trigger the reset problem or won't produce any SMART data.

skdump sat16:/dev/sdXXX
skdump sat12:/dev/sdXXX
skdump sunplus:/dev/sdXXX
skdump jmicron:/dev/sdXXX

Then, please include the lsusb -v data for this drive, so that I know what to
check against in the blacklist.
-----------------

Please do the four skdump commands (prefixed with sudo) and copy&paste their outputs. Then do "lsusb -v > /tmp/lsusb.txt" and attach /tmp/lsusb.txt. After each skdump command, please unplug and replug the drive, so that they all start from a defined state and aren't affected by the previous command.

Preferably you could send the results directly to https://bugzilla.redhat.com/show_bug.cgi?id=515881, but sending them here is fine as well, I'll forward them.

Thanks everyone!

my blacklisting works fine ;)
"ATA SMART not supported" from skdump

Robert Willert [2009-09-15 23:02 -0000]:
> my blacklisting works fine ;)
> "ATA SMART not supported" from skdump

From which one? Please try all four.

> ** Attachment added: "lsusb.log"
> http://launchpadlibrarian.net/31857174/lsusb.log

Thanks!

No SMART with sat12, sat16, sunplus.
HDD reset with jmicron.
"Failed to open disk jmicron:/dev/sdb: No such file or directory"

I submitted my results to https://bugzilla.redhat.com/show_bug.cgi?id=515881.

I checked all the comments and duplicate bugs, and I saw several other occurrendes of 152d:2329. I did not see any of the other JMicron product IDs.

However, there are a fair number of reporters who didn't submit lsusb -v, thus were I can't say for sure whether it's the same piece of hardware. I have the feeling that there is another affected controller here, since Scott's original report didn't mention a JMicron controller anywhere.

To keep things in a manageable state, I dedicate this bug to the 152d:2329 device, where we have clear evidence and confirmation. Robert mentioned a workaround in comment 59 (blacklisting the controller in /lib/udev/rules.d/95-devkit-disks.rules and adding a check_sat_end label).

If you still have the resets even with that blacklisting (which will soon be the default), please open a new bug and include the output of "lsusb -vv". Thanks!

I also have this device 152d:2329 so here are my information:

sebner@ubuntu:~$ sudo skdump sat16:/dev/sdb1
Device: sat16:/dev/sdb1
Type: 16 Byte SCSI ATA SAT Passthru
Size: 953867 MiB
Awake: Operation not supported
ATA SMART not supported.

sebner@ubuntu:~$ sudo skdump sat12:/dev/sdb1
Device: sat12:/dev/sdb1
Type: 12 Byte SCSI ATA SAT Passthru
Size: 953867 MiB
Awake: Operation not supported
ATA SMART not supported.

sebner@ubuntu:~$ sudo skdump sunplus:/dev/sdb1
Device: sunplus:/dev/sdb1
Type: Sunplus SCSI ATA Passthru
Size: 953867 MiB
Awake: Operation not supported
ATA SMART not supported.

sebner@ubuntu:~$ sudo skdump jmicron:/dev/sdb1
Failed to open disk jmicron:/dev/sdb1: No such device

This bug was fixed in the package libatasmart - 0.14-1ubuntu1

---------------
libatasmart (0.14-1ubuntu1) karmic; urgency=low

  * atasmart.c: Blacklist JMicron SATA bridge 152d:2329, since it causes USB
    resets when being probed for SMART. Patch cherrypicked from upstream git.
    (LP: #387161)

 -- Martin Pitt <email address hidden> Thu, 17 Sep 2009 22:56:56 +0200

Lennart committed the blacklisting of this controller to upstream now and asked me to test this. I uploaded a new version to Karmic with this fix cherrypicked.

Can you please confirm that this works for you? (At least the people who confirmed to have this particular JMicron bridge). Thanks!

The blacklisting works for me.

this fix works here too

This blacklist dont work for me.

This drive mount in Jaunty and anothers computers (the same machinne jaunty/windows)

root@alex-pczao:~# lsusb
Bus 001 Device 026: ID 152d:2339 JMicron Technology Corp. / JMicron USA Technology Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 041e:401c Creative Technology, Ltd WebCam NX [PD1110]
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 004: ID 2222:0013 MacAlly
Bus 004 Device 003: ID 04f3:0212 Elan Microelectronics Corp. Laser Mouse
Bus 004 Device 002: ID 058f:9254 Alcor Micro Corp. Hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

[ 1496.541563] scsi6 : SCSI emulation for USB Mass Storage devices
[ 1496.541743] usb-storage: device found at 21
[ 1496.541746] usb-storage: waiting for device to settle before scanning
[ 1501.540203] usb-storage: device scan complete
[ 1523.100523] usb 1-3: reset high speed USB device using ehci_hcd and address 21
[ 1533.344015] usb 1-3: reset high speed USB device using ehci_hcd and address 21
[ 1538.588021] usb 1-3: reset high speed USB device using ehci_hcd and address 21
[ 1538.712012] usb 1-3: device descriptor read/64, error -71
[ 1538.940014] usb 1-3: device descriptor read/64, error -71
[ 1539.156014] usb 1-3: reset high speed USB device using ehci_hcd and address 21
[ 1539.280010] usb 1-3: device descriptor read/64, error -71
[ 1539.508010] usb 1-3: device descriptor read/64, error -71
[ 1539.724016] usb 1-3: reset high speed USB device using ehci_hcd and address 21
[ 1540.132010] usb 1-3: device not accepting address 21, error -71
[ 1540.244013] usb 1-3: reset high speed USB device using ehci_hcd and address 21
[ 1540.652015] usb 1-3: device not accepting address 21, error -71
[ 1540.652033] scsi 6:0:0:0: Device offlined - not ready after error recovery
[ 1540.652039] usb 1-3: USB disconnect, address 21
[ 1540.764017] usb 1-3: new high speed USB device using ehci_hcd and address 22
[ 1540.888011] usb 1-3: device descriptor read/64, error -71
[ 1541.116014] usb 1-3: device descriptor read/64, error -71
[ 1541.332016] usb 1-3: new high speed USB device using ehci_hcd and address 23
[ 1541.456018] usb 1-3: device descriptor read/64, error -71
[ 1541.684015] usb 1-3: device descriptor read/64, error -71
[ 1541.900017] usb 1-3: new high speed USB device using ehci_hcd and address 24
[ 1542.308008] usb 1-3: device not accepting address 24, error -71
[ 1542.420018] usb 1-3: new high speed USB device using ehci_hcd and address 25
[ 1542.832009] usb 1-3: device not accepting address 25, error -71
[ 1542.832020] hub 1-0:1.0: unable to enumerate USB device on port 3
[ 1543.100016] usb 3-1: new full speed USB device using uhci_hcd and address 14
[ 1543.224026] usb 3-1: device descriptor read/64, error -71
[ 1543.504511] usb 3-1: device descriptor read/64, error -71
[ 1543.720520] usb 3-1: new full speed USB device using uhci_hcd and address 15
[ 1543.844522] usb 3-1: device descriptor read/64, error -71
[ 1544.068014] usb 3-1: device descriptor read/64, err...

> This blacklist dont work for me.
> Bus 001 Device 026: ID 152d:2339 JMicron Technology Corp. / JMicron USA Technology Corp.

OK, seems we need to blacklist this as well.

Here is another JMicron-chip that gives the symtoms listed above and which are fixed by disabling devicekit-disks:

Bus 001 Device 005: ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge

Additionally it seems to fix the similar problem I've had for a long time with my external flash-disk reader:

Bus 001 Device 015: ID 058f:6366 Alcor Micro Corp.

 -- K

Seems I was a bit too trigger-happy about the Alcor chip. More testing shows that it's still causing resets, so it's probably another bug. The JMicron is still positive.

 -- K

This bug was fixed in the package libatasmart - 0.15-3

---------------
libatasmart (0.15-3) unstable; urgency=low

  * atasmart.c: Blacklist JMicron drives 152d:233[89] as well, since they were
    also confirmed to cause USB resets on SMART probing. (LP: #387161,
    https://bugzilla.redhat.com/show_bug.cgi?id=515881)

 -- Martin Pitt <email address hidden> Thu, 24 Sep 2009 11:26:24 +0200

I'm still seeing this problem in Karmic:

Linux bauer 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux

[14860.672099] hub 4-0:1.0: unable to enumerate USB device on port 1
[14880.196291] usb 1-3: new high speed USB device using ehci_hcd and address 3
[14880.331612] usb 1-3: configuration #1 chosen from 1 choice
[14880.378332] Initializing USB Mass Storage driver...
[14880.379177] scsi6 : SCSI emulation for USB Mass Storage devices
[14880.379300] usb-storage: device found at 3
[14880.379303] usb-storage: waiting for device to settle before scanning
[14880.379316] usbcore: registered new interface driver usb-storage
[14880.379320] USB Mass Storage support registered.
[14885.376735] usb-storage: device scan complete
[14885.377219] scsi 6:0:0:0: Direct-Access MicroNet Volume Set # 00 0100 PQ: 0 ANSI: 4
[14885.377753] sd 6:0:0:0: Attached scsi generic sg3 type 0
[14885.383209] sd 6:0:0:0: [sdc] 3906248704 512-byte logical blocks: (1.99 TB/1.81 TiB)
[14885.385147] sd 6:0:0:0: [sdc] Write Protect is off
[14885.385151] sd 6:0:0:0: [sdc] Mode Sense: 11 00 00 00
[14885.385154] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[14885.386264] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[14885.386268] sdc: sdc1
[14885.403639] sd 6:0:0:0: [sdc] Assuming drive cache: write through
[14885.403644] sd 6:0:0:0: [sdc] Attached SCSI disk
[14888.620032] usb 1-3: reset high speed USB device using ehci_hcd and address 3
[14903.732041] usb 1-3: device descriptor read/64, error -110
[14918.948030] usb 1-3: device descriptor read/64, error -110
[14919.164040] usb 1-3: reset high speed USB device using ehci_hcd and address 3
[14934.276037] usb 1-3: device descriptor read/64, error -110
[14949.492061] usb 1-3: device descriptor read/64, error -110
[14949.708059] usb 1-3: reset high speed USB device using ehci_hcd and address 3
[14954.729058] usb 1-3: device descriptor read/8, error -110
[14959.848367] usb 1-3: device descriptor read/8, error -110
[14960.064037] usb 1-3: reset high speed USB device using ehci_hcd and address 3
[14965.084165] usb 1-3: device descriptor read/8, error -110
[14970.204099] usb 1-3: device descriptor read/8, error -110
[14970.308065] usb 1-3: USB disconnect, address 3
[14970.308828] scsi 6:0:0:0: Device offlined - not ready after error recovery
[14970.420039] usb 1-3: new high speed USB device using ehci_hcd and address 4
[14985.532041] usb 1-3: device descriptor read/64, error -110
[15000.748815] usb 1-3: device descriptor read/64, error -110
[15000.964037] usb 1-3: new high speed USB device using ehci_hcd and address 5
[15016.076036] usb 1-3: device descriptor read/64, error -110
[15031.292059] usb 1-3: device descriptor read/64, error -110
[15031.508043] usb 1-3: new high speed USB device using ehci_hcd and address 6
[15036.528103] usb 1-3: device descriptor read/8, error -110
[15041.648491] usb 1-3: device descriptor read/8, error -110
[15041.864057] usb 1-3: new high speed USB device using ehci_hcd and address 7
[15046.884090] usb 1-3: device descriptor read/8, error -110
[15052.004394] usb 1-3: device descriptor read/8, error -110
[15052.108045] hub 1-0:1.0: unable to enumerate USB device o...

Farris Goldstein [2009-11-03 4:09 -0000]:
> I'm still seeing this problem in Karmic:

Please file a new bug report and include the output of

  sudo skdump /dev/sdb

check dmesg if you get resets here; if so, unplug/replug)

  sudo skdump jmicron:/dev/sdb

and finally

  lsusb -v

Thanks,

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin,

/dev/sdb is an internal drive. The one give me the errors only enumerates briefly, then gets reset and no longer shows up in lsusb. Are you saying I should show the output for a working, internal drive?

Is there some other useful information I can generate for a bug report on the device that will not enumerate?

-J

Right, I meant the USB drive which causes trouble, which was /dev/sdc in comment 75.

To debug the drive properly (for running skdump on it), please do

  sudo gedit /lib/udev/rules.d/95-devkit-disks.rules

and comment out the lines which have "devkit-disks-probe-ata-smart". There are three:

KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="usb", ENV{DEVTYPE}=="disk", IMPORT{program}="devkit-disks-probe-ata-smart $tempnode"

# ATA disks driven by libata
KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="ata", ENV{DEVTYPE}=="disk", IMPORT{program}="devkit-disks-probe-ata-smart $tempnode"

# ATA disks connected via SAS (not driven by libata)
KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="scsi", ENV{DEVTYPE}=="disk", ENV{ID_VENDOR}=="ATA", IMPORT{program}="devkit-disks-probe-ata-smart $tempnode"

Please put a "#" in front of all of them.

Thanks, Martin. Filed bug #474988

Hi,
my western digital usb hard disk is not recognized at all after upgrading to karmic, doesn't show up in fdisk -l or lsusb. Don't want to remove devicekit-disks because 78 other packages also will be removed then. I don't know if this is the same bug as posted here but don't want to file a duplicate. Running 2.6.31-15-generic x86_64.
havhest

Same here with a Western Digital 2.5" usb. Even with devicekit-disks uninstalled, the device won't show up..

Hi,

with commenting out the three lines Martin Pitt recommended, automounting external drives worked no longer.
I tried to comment just the first suggested line:

#KERNEL=="sd*[!0-9]", ATTR{removable}=="0", ENV{ID_BUS}=="usb", ENV{DEVTYPE}=="disk", IMPORT{program}="devkit-disks-probe-ata-smart $tempnode"

and both of my external drives are automounted again:
Device 010: ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp.
Device 009: ID 04b4:6830 Cypress Semiconductor Corp. CY7C68300A EZ-USB AT2 USB 2.0 to ATA/ATAPI

But so far I don't know if there are any side-effects.
best regards - Joe

Duplicated LP bug #530227 ?

No, I don't think it's a duplicate, it was reported for recent lucid.

I filled in bug #540599 about the issue with extern Western Digital USB hard drives.

I just ran into this situation too:

Feb 5 02:48:28 terrorbite kernel: [ 1478.220053] usb 2-1: new full speed USB device using ohci_hcd and address 32
Feb 5 02:48:28 terrorbite kernel: [ 1478.400385] usb 2-1: device descriptor read/64, error -62
Feb 5 02:48:29 terrorbite kernel: [ 1478.690035] usb 2-1: device descriptor read/64, error -62
Feb 5 02:48:29 terrorbite kernel: [ 1478.980039] usb 2-1: new full speed USB device using ohci_hcd and address 33
Feb 5 02:48:29 terrorbite kernel: [ 1479.160866] usb 2-1: device descriptor read/64, error -62
Feb 5 02:48:30 terrorbite kernel: [ 1479.450878] usb 2-1: device descriptor read/64, error -62
Feb 5 02:48:30 terrorbite kernel: [ 1479.740931] usb 2-1: new full speed USB device using ohci_hcd and address 34
Feb 5 02:48:30 terrorbite kernel: [ 1480.160031] usb 2-1: device not accepting address 34, error -62
Feb 5 02:48:30 terrorbite kernel: [ 1480.340098] usb 2-1: new full speed USB device using ohci_hcd and address 35
Feb 5 02:48:31 terrorbite kernel: [ 1480.760017] usb 2-1: device not accepting address 35, error -62
Feb 5 02:48:31 terrorbite kernel: [ 1480.760030] hub 2-0:1.0: unable to enumerate USB device on port 1

It turned out that the plug was not pushed fully home at the computer home.

I assume that one or both of the data lines were not making contact.

Sooo ... check your cables and connections before getting too keen on hacking at your system.

There would probably be some value in the drivers checking for the possibility of broken data lines and reporting them to the user. Something like "Data error on USB device. Check your cables and connections."

it keeps it from booting up all the way