The lsusb listing attached by apport above seems to not list the card reader at all. This did happen on some sessions, IIRC there were no panics or ”disabled ep” messages then either but naturally, the reader also wouldn’t read any cards, it was as if disconnected.
I’m attaching output of `sudo lsusb -v` here, with the card reader (004:002) detected and showing.
There’s a definite pattern here, and it’s definitely tied to xhci_hcd, usb-storage and the Akasa/Genesys card reader. Here’s what I’ve done since reporting this:
1) Set ”Legacy USB 3.0” in the BIOS from ”Enabled” to ”Disabled”, and ”Intel xHCI Mode” from ”Smart Auto” to ”Enabled”. I tested briefly with latter set to ”Disabled” and Legacy 3.0 ”Enabled”, but then the card reader wasn’t detected at all and I’d prefer a working XHCI anyway.
2) Switched to mainline kernel 3.8.0-030800rc2-generic #201301022235. With the earlier kernels (3.5 and 3.2 from Precise repo) things have seemed similar to my findings below with mainline, but data with 3.2 and 3.5 are too few to say conclusively there’s no difference at all. I’ve concentrated my testing to mainline just to keep things simpler.
Here’s the pattern with mainline:
1) Cold boot. Early in the boot, the card reader in USB #4 is asked to reset. This results in a flood of ”xHCI xhci_drop_endpoint called with disabled ep ffff880403c8d500”:
Jan 8 10:32:12 saegusa kernel: [ 721.015249] usb 4-4: reset SuperSpeed USB device number 2 using xhci_hcd
Jan 8 10:32:12 saegusa kernel: [ 721.032596] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff880403c8d500
Jan 8 10:32:12 saegusa kernel: [ 721.032599] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff880403c8d540
When these messages are there, the session will crash (panic/freeze) at some point; using the card reader isn’t necessary (panics without it eventually too), but it’s easy enough to trigger just by sticking an SD card into the reader. The reader reports buffer errors on the card and then boom.
Jan 8 10:32:13 saegusa kernel: [ 721.713295] sd 8:0:0:2: [sdf] Unhandled error code
Jan 8 10:32:13 saegusa kernel: [ 721.713299] sd 8:0:0:2: [sdf]
Jan 8 10:32:13 saegusa kernel: [ 721.713300] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
Jan 8 10:32:13 saegusa kernel: [ 721.713303] sd 8:0:0:2: [sdf] CDB:
Jan 8 10:32:13 saegusa kernel: [ 721.713304] Read(10): 28 00 00 00 20 00 00 00 08 00
Jan 8 10:32:13 saegusa kernel: [ 721.713314] end_request: I/O error, dev sdf, sector 8192
Jan 8 10:32:13 saegusa kernel: [ 721.713318] Buffer I/O error on device sdf1, logical block 0
Another USB #4 -related message often preceding a panic in syslog is this:
Jan 8 17:38:21 saegusa kernel: [ 148.282256] usb 4-4: Disable of device-initiated U1 failed.
Jan 8 17:38:21 saegusa kernel: [ 148.285747] usb 4-4: Disable of device-initiated U2 failed.
The panics, when visible, are always in Pid: usb-storage, and mostly of the ”ring_doorbell_for_active_rings” type (above), but I did have at least one ”warn_slowpath_common” too (will attach a picture if requested).
2) Reboot after the panic, USB #4 doesn’t get reset and no ”disabled ep” or ”Disable of device-initiated …” messages appear in syslog. The card reader works perfectly (i.e. SD card can be inserted and read/written without problems).
3) The panic isn’t necessary to get the card reader working: it’s enough to reboot after one cold boot and the reset signal being sent in that session. Just don’t stay in that cold boot session, because it’ll panic eventually.
I’ll attach a complete syslog from yesterday and today to give context to what I’ve quoted above.
I don’t see the syslog I mentioned attached above, so I’m attaching it here. Also, the USB-related stuff just preceding the panic starts slightly earlier than what I claimed above, with this reset attempt:
Jan 7 10:45:01 saegusa kernel: [ 413.991127] usb 4-4: reset SuperSpeed USB device number 2 using xhci_hcd
Last week I replaced the internals of my desktop computer with a new ASUS P8H77-M PRO, Intel G2120 and 16 GB RAM. With one round of Memtest passed, I booted into my old Precise install and got bit hard by what appears to be Bug #993187: frequent hard lockups (multiple within a few hours of use). I installed linux-image-generic-lts-quantal (currently 3.5.0.22.29) and that seemed to resolve the lockups: I got more than two days of uptime (ending with an intended shutdown), half of which I was actively using the computer.
This morning, soon (half an hour?) after login, the kernel paniced with a reference to usb-storage (I’ll attach a picture). This was different from the lockups with the stock Precise (3.2) kernel: with them I never had any panics shown (only the frozen desktop) and the system had to be powered off to reboot, whereas with the panic here I could reboot using the chassis reset button.
There’s some USB activity in syslog just prior to the panic (Jan 7 at around 10:50), but I wasn’t using any USB devices at the time. I have used them with this kernel previously though, without issues, and currently am too (to transfer the panic picture from my phone). There’s a memory card reader/USB port panel (Akasa AK-ICR-17) permanently plugged into internal USB 2 and 3.
Rolling release oli muistaakseni… juu, Arch kuten muistelinkin.
From a similar question on ServerFault (and particularly one response there), one possible explanation for the disparity is that there are processes hanging on to files they’ve accessed on /tmp that have since been deleted.
# lsof | grep deleted will list such files along with the processes still attached to them.
Ahem. It now looks like non-pae + wistron doesn’t work either. But this looks more like a configuration issue on my part, I’ll have to investigate it further. It still doesn’t freeze or anything, it’s just that the wireless doesn’t go online.
Luis, there actually was a BIOS upgrade available from Fujitsu [1], thanks for prompting me to look! I flashed the latest revision S0Z in (it was S0U until now), but unfortunately this didn’t change the behavior at issue here. (There was no mention of the wireless in manufacturer’s changelog either, but those are often incomplete anyway.)
*[1] http://download.ts.fujitsu.com/download/ShowDescription.asp?SoftwareGUID=1968BB6F-7819-4C8C-A488-BAA44C111F7C
Thanks for commenting, Luis. I booted with noexec=off a couple of times with 3.2.0-24-pae, but it didn’t seem to change anything, i.e. the boot still (seemingly) froze when wistron_btns was enabled.
I was unaware of fsam7400 prior to this, so I tried that too, instead of wistron_btns. With fsam7400, the -pae kernel boots fine here even without noexec=off, apart from a ”Waiting for network” , and the wireless network never coming up (can’t bring it up from the desktop either). So here, at least, the noexec=off workaround isn’t needed with fsam7400, though it isn’t much good wrt the wireless either.
To reiterate: the only way currently to have this system boot with the wireless working is to have wistron_btns enabled and to use a non-pae kernel.
I should mention that I’ve upgraded the laptop to Quantal.
I should also mention that Precise’s mainstream installation media refused to boot on the laptop. I believe the message was ”This kernel requires the following features not present on the CPU: pae”. This despite the fact that the -pae kernels, once a system has been installed, *do* boot and work just fine, albeit not with wistron_btns loaded. So currently I’m unsure whether the CPU actually supports pae or not.
I’ve just hit the Oops (__ticket_spin_lock+0x9/0x30) with apw’s kernel. I’ll attach the syslog from after reboot to this comment. Had been running the apw build since Monday this week (7 days now) without problems.
Just to note here also that I’ve today switched to apw’s build of 3.2.0-23 [1] linked to from bug 922906. I had been running the upstream 3.3 for more than 7 weeks without hitting this (#917668). The GPU lockup I mentioned in #13 also never reoccurred since that one time.
I’ll report back, should #917668 resurface with the kernel I’m currently running.
* [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/922906/comments/11