External HD (USB 3.0) with btrfs not recognized by device manager of KDE

English Install/Boot/Login
1

I use an external 2.5’’ HD for backups, filesystem is btrfs. System: openSuse 12.3, but the bug ocurred earlier, at least it was present in 12.2:

If I connect the cable to the USB 3.0 port of my notebook (Thinkpad T 420s), up and running KDE, the HD (as well capable of USB 3.0) is not recognized by KDE. The device manager shows no device. But there is something wrong, e.g. s2ram no longer works.

My solution for a long time was to suspend the notebook, connect the cable, wake it up and then the device manager found the HD.

But as this bug persists, I need your help to become able to create a usefull bugreport. Any suggestions?

I put this here, because the description of the forum mentioned file systems.

2

:shame:

Anybody? Ideas? Is my question that annoying, stupid or childish?

3

I don’t have the hardware to test/confirm this, but from what I see this is a bug. Provide the info you provide here and report it.

A couple of things that could help finding out what the bug is about:

Connect the USB device to the 3.0 port. Immediately after, open a terminal and do:


dmesg | tail -20

and


su -c 'tail /var/log/messages'
4

Please do not interpret the radio-silence in response to your question as others thinking it is annoying or stupid. The
likelihood is that it’s difficult for others to see readily how to help you. I suspect part of the problem is that
you’ve given an anecdotal narrative of what happened with the underlying problem to remain mysterious to the user.

For example:

On 2013-04-25, cookie170 <cookie170@no-mx.forums.opensuse.org> wrote:
> I use an external 2.5’’ HD for backups, filesystem is btrfs. System:
> openSuse 12.3, but the bug ocurred earlier, at least it was present in
> 12.2:

At this point you should specify whether 32-bit or 64-bit and which DE you are using (although we can work it’s KDE
later on). The obvious question I have is why use BTRFS for backup purposes when it’s experimental and known to be
buggy?

> If I connect the cable to the USB 3.0 port of my notebook (Thinkpad T
> 420s), up and running KDE, the HD (as well capable of USB 3.0) is not
> recognized by KDE. The device manager shows no device.

I have used KDE for some time, and I don’t know you mean by the device manager'. Are you referring to the output of lsusb’?

> But there is something wrong, e.g. s2ram no longer works.

This isn’t really sufficiently furnished with detail to constitute a proper bug report. Put yourself in the position of
an openSUSE developer who’s confronted with the statement `but there is something wrong e.g. s2ram no longer works’ -
I know nothing obliges you to report bugs, but you have to give more than that if you want the bug report to be useful!

My solution for a long time was to suspend the notebook, connect the
cable, wake it up and then the device manager found the HD.

OK, this is not a solution but a workaround. There’s nothing wrong with that, but I suspect more diagnostic tests are
necessary to identify the problem areas before establishing the presence of a bug.

But as this bug persists, I need your help to become able to create a
usefull bugreport. Any suggestions?

Start from the beginning. Connect your HD and before looking to see if your device manager' can see it, open a console and post the results of lsusb’ inside code tags (indicated by the octothorpe icons in the forum toolbar).

> I put this here, because the description of the forum mentioned file
> systems.

I would have put in hardware because we have not yet established that the problem is BTRFS, but it may just be a
mounting issue.

5

As a typical heavy laptop user with limited internal storage, I use USB external storage quite a bit (and I use the KDE Desktop).

  1. Yes, I’ve also observed some disks “disconnect” and become unrecognised from time to time. Usually it’s easily fixed by simply powering off, physically disconnecting, powering back on and re-connecting (not in strict order). The act of poweroff/on in particular seems to trigger recognition.

  2. I’ve found this tends to happen more often with generic drives installed in external cases. Rarely if ever happens to a branded complete drive from the manufacturer. A while back I submitted a bug possibly related to what you’ve observed about transferring data over an unreliable USB connections… The branded drives rarely lost data while the generic drives often lost data. As far as I could tell, it’s likely related to the fact that branded drives are recognized differently than generic drives. As branded drives, the OS <knows> that the drive is external and applies various policies to better support external attached storage. On the other hand, if the drive is generic, then the OS doesn’t know if it’s a USB connection to primary storage or external removable storage, so it’s treated differently (maybe even as internal primary by default). Also, depending on whether the previous disconnection was “dirty” (data in transit), it can be helpful to change USB ports.

  3. Yes, it’s not your imagination. The KDE Desktop does recognize and manage devices differently and possibly better than the base OS (which of course means that lsusb and similar won’t necessarily be helpful). I haven’t investigated in depth but the evidence is often… eg connecting Android devices as modem or storage modes.

Although I never saw a direct response to my bug report, perhaps co-incidentally or due to someone’s efforts I saw the problem less often. Today, I see storage device recognition problems a lot less frequently.

And, of course once I determined that there is an advantage to using branded storage devices, that’s the direction I’ve been purchasing despite the benefits of upgradeable cases.

HTH,
TSU

6

Thank you all for your answers! So I put the plug of the 2.5’ HD into the USB 3.0 port and ask, being root:

dmesg | tail -50
...

 7402.732517] usb 3-1: new high-speed USB device number 2 using xhci_hcd
 7407.720250] xhci_hcd 0000:0d:00.0: Timeout while waiting for address device command
 7423.926379] xhci_hcd 0000:0d:00.0: Stopped the command ring failed, maybe the host is dead
 7423.978212] xhci_hcd 0000:0d:00.0: Host not halted after 16000 microseconds.
 7423.978217] xhci_hcd 0000:0d:00.0: Abort command ring failed
 7423.979085] [sched_delayed] sched: RT throttling activated
 7423.980776] xhci_hcd 0000:0d:00.0: HC died; cleaning up
 7429.168320] xhci_hcd 0000:0d:00.0: Timeout while waiting for address device command
 7429.168337] xhci_hcd 0000:0d:00.0: Abort the command ring, but the xHCI is dead.
 7429.368829] usb 3-1: device not accepting address 2, error -108
 7429.368852] hub 3-0:1.0: cannot disable port 1 (err = -19)
 7434.356530] xhci_hcd 0000:0d:00.0: Timeout while waiting for a slot
 7434.356547] xhci_hcd 0000:0d:00.0: Abort the command ring, but the xHCI is dead.
 7434.356575] hub 3-0:1.0: cannot reset port 1 (err = -19)
 7434.356588] hub 3-0:1.0: cannot disable port 1 (err = -19)
 7434.356597] xHCI xhci_free_dev called with unaddressed device
 7439.344340] xhci_hcd 0000:0d:00.0: Timeout while waiting for a slot
 7439.344353] xhci_hcd 0000:0d:00.0: Abort the command ring, but the xHCI is dead.
 7439.344376] hub 3-0:1.0: cannot reset port 1 (err = -19)
 7439.344384] hub 3-0:1.0: cannot disable port 1 (err = -19)
 7439.344390] xHCI xhci_free_dev called with unaddressed device
 7444.331946] xhci_hcd 0000:0d:00.0: Timeout while waiting for a slot
 7444.331960] xhci_hcd 0000:0d:00.0: Abort the command ring, but the xHCI is dead.
 7444.331982] hub 3-0:1.0: cannot reset port 1 (err = -19)
 7444.331990] hub 3-0:1.0: cannot disable port 1 (err = -19)
 7444.331997] xHCI xhci_free_dev called with unaddressed device
 7444.332005] hub 3-0:1.0: unable to enumerate USB device on port 1
 7444.332010] hub 3-0:1.0: cannot disable port 1 (err = -19)


tail /var/log/messages
2013-04-29T10:36:52.150008+02:00 linux-ik7b rtkit-daemon[2840]: Successfully demoted thread 2847 of process 2839 (/usr/bin/pulseaudio).
2013-04-29T10:36:52.150916+02:00 linux-ik7b rtkit-daemon[2840]: Successfully demoted thread 2846 of process 2839 (/usr/bin/pulseaudio).
2013-04-29T10:36:52.151957+02:00 linux-ik7b rtkit-daemon[2840]: Successfully demoted thread 2839 of process 2839 (/usr/bin/pulseaudio).
2013-04-29T10:36:52.152877+02:00 linux-ik7b rtkit-daemon[2840]: Demoted 3 threads.
2013-04-29T10:37:01.621692+02:00 linux-ik7b kernel:  7407.720250] xhci_hcd 0000:0d:00.0: Timeout while waiting for address device command
2013-04-29T10:37:01.621720+02:00 linux-ik7b kernel:  7423.926379] xhci_hcd 0000:0d:00.0: Stopped the command ring failed, maybe the host is dead
2013-04-29T10:37:01.621723+02:00 linux-ik7b kernel:  7423.978212] xhci_hcd 0000:0d:00.0: Host not halted after 16000 microseconds.
2013-04-29T10:37:01.621725+02:00 linux-ik7b kernel:  7423.978217] xhci_hcd 0000:0d:00.0: Abort command ring failed
2013-04-29T10:37:01.624254+02:00 linux-ik7b kernel:  7423.979085] [sched_delayed] sched: RT throttling activated
2013-04-29T10:37:01.624266+02:00 linux-ik7b kernel:  7423.980776] xhci_hcd 0000:0d:00.0: HC died; cleaning up

Some secondes later:

tail /var/log/messages
2013-04-29T10:37:17.026654+02:00 linux-ik7b kernel:  7439.344376] hub 3-0:1.0: cannot reset port 1 (err = -19)
2013-04-29T10:37:17.026659+02:00 linux-ik7b kernel:  7439.344384] hub 3-0:1.0: cannot disable port 1 (err = -19)
2013-04-29T10:37:17.026665+02:00 linux-ik7b kernel:  7439.344390] xHCI xhci_free_dev called with unaddressed device
2013-04-29T10:37:22.026625+02:00 linux-ik7b kernel:  7444.331946] xhci_hcd 0000:0d:00.0: Timeout while waiting for a slot
2013-04-29T10:37:22.026661+02:00 linux-ik7b kernel:  7444.331960] xhci_hcd 0000:0d:00.0: Abort the command ring, but the xHCI is dead.
2013-04-29T10:37:22.026666+02:00 linux-ik7b kernel:  7444.331982] hub 3-0:1.0: cannot reset port 1 (err = -19)
2013-04-29T10:37:22.026670+02:00 linux-ik7b kernel:  7444.331990] hub 3-0:1.0: cannot disable port 1 (err = -19)
2013-04-29T10:37:22.026676+02:00 linux-ik7b kernel:  7444.331997] xHCI xhci_free_dev called with unaddressed device
2013-04-29T10:37:22.026681+02:00 linux-ik7b kernel:  7444.332005] hub 3-0:1.0: unable to enumerate USB device on port 1
2013-04-29T10:37:22.026684+02:00 linux-ik7b kernel:  7444.332010] hub 3-0:1.0: cannot disable port 1 (err = -19)

And lsusb (some minutes later):

lsusb
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 147e:2016 Upek Biometric Touchchip/Touchstrip Fingerprint Sensor
Bus 001 Device 013: ID 0a5c:217f Broadcom Corp. Bluetooth Controller
Bus 001 Device 012: ID 04f2:b221 Chicony Electronics Co., Ltd integrated camera
Bus 002 Device 005: ID 0bdb:1911 Ericsson Business Mobile Networks BV

Over the weekend it happened that I had to copy from a SD-card (the Thinkpad got a sd-card-reader), same result: not being recognized. And another external hard disk, 3.5’’ with its own power supply, wasn’t either.

By the way, before connecting the HD, the log revealed another error:

tail /var/log/messages
2013-04-29T10:21:35.447957+02:00 linux-ik7b dhclient[10491]: bound to 192.168.0.13 -- renewal in 308804 seconds.
2013-04-29T10:21:36.473018+02:00 linux-ik7b dbus-daemon[1330]: dbus[1330]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
2013-04-29T10:21:36.473038+02:00 linux-ik7b dbus[1330]: [system] Activating service name='org.freedesktop.nm_dispatcher' (using servicehelper)
2013-04-29T10:21:36.486832+02:00 linux-ik7b dbus-daemon[1330]: dbus[1330]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2013-04-29T10:21:36.487530+02:00 linux-ik7b dbus[1330]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2013-04-29T10:22:55.380839+02:00 linux-ik7b systemd[1]: Job dev-disk-by\x2did-usb\x2dWD_My_Book_1130_5743415A4137373131313238\x2d0:0\x2dpart2.device/start timed out.
2013-04-29T10:22:55.383067+02:00 linux-ik7b systemd[1]: Timed out waiting for device dev-disk-by\x2did-usb\x2dWD_My_Book_1130_5743415A4137373131313238\x2d0:0\x2dpart2.device.
2013-04-29T10:22:55.384429+02:00 linux-ik7b systemd[1]: Dependency failed for /media/AW-t420.
2013-04-29T10:22:55.386066+02:00 linux-ik7b systemd[1]: Job media-AW\x2dt420.mount/start failed with result 'dependency'.
2013-04-29T10:22:55.387172+02:00 linux-ik7b systemd[1]: Job dev-disk-by\x2did-usb\x2dWD_My_Book_1130_5743415A4137373131313238\x2d0:0\x2dpart2.device/start failed with result 'timeout'.

So the system waited for other HDs I earlier connected.

Any ideas? The notebook is connected to the grid, so no powersave option should cause this. But who knows?

7

64-bit, KDE 4.10. I’m using BTRFS for one reason: snapshots are really cheap. I sync /home/ME to the external HD (let’s say to … /origin) and then snapshot /origin. This is fast, not much effort, and the HD has space for really a lot of snapshots, so I can go back to any week during the last year.

> If I connect the cable to the USB 3.0 port of my notebook (Thinkpad T
> 420s), up and running KDE, the HD (as well capable of USB 3.0) is not
> recognized by KDE. The device manager shows no device.

I have used KDE for some time, and I don’t know you mean by the device manager'. Are you referring to the output of lsusb’?

No, there is a tray icon called »Geräteüberwachung« in German, the english term seems to be »device notifier«. Sorry for the wrong translation.

> But there is something wrong, e.g. s2ram no longer works.

This isn’t really sufficiently furnished with detail to constitute a proper bug report. Put yourself in the position of
an openSUSE developer who’s confronted with the statement `but there is something wrong e.g. s2ram no longer works’ -
I know nothing obliges you to report bugs, but you have to give more than that if you want the bug report to be useful!

Ahm, yes. Thinkpad does not go to s2ram, just locks the screen and asks for user password.

…

> I put this here, because the description of the forum mentioned file
> systems.

I would have put in hardware because we have not yet established that the problem is BTRFS, but it may just be a
mounting issue.

Difficult to say for a user like me. But thank you for your time and effort.

8

On 04/29/2013 04:06 AM, cookie170 wrote:

The log dump from your previous post shows a problem with the USB 3.0
port/driver combination. It is a kernel problem, not the file system.

Not a lot of people have USB 3.0 hardware, and when its characteristics deviate
from the published specs, the driver fails. That is the problem with early
adopters. It was the same situation when USB 2.0 was new.

Your best bet is to use the latest kernel that you can. If you need an openSUSE
build, that will be 3.8. If you build your own, then try 3.9.

9

On 2013-04-26 23:16, tsu2 wrote:
> And, of course once I determined that there is an advantage to using
> branded storage devices, that’s the direction I’ve been purchasing
> despite the benefits of upgradeable cases.

Well, I always buy the case and the hard disk separately, and they work
fine. There are reliable brand names in the cases, too.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

10

Well, initially it used to work. Some day, during the days of 12.2, I run into trouble. I’ll test with the SD-Card, which is something completly different, and post the logs. In the meantime,

  1. thank you for your help
  2. could you elaborate a little bit on the idea of a kernel bug? I’d send a bugreport to kernel.org.

Regards,

Alexander

11

Well it is not really a bug, your hardware deviates from the spec so the OS driver does not work with it. ie it is an exception to the rule.The bug is in the hardware. You can report it but be sure that you give full specs on the USB chips etc.