Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#44955 - [linux] Kernel oops on boot with USB stick connected
Attached to Project:
Arch Linux
Opened by Brian Johnson (bjthinks) - Wednesday, 13 May 2015, 19:49 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 02 October 2017, 22:17 GMT
Opened by Brian Johnson (bjthinks) - Wednesday, 13 May 2015, 19:49 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 02 October 2017, 22:17 GMT
|
DetailsDescription:
When I have a Lexar-branded 32GB USB stick inserted into my computer, I get a kernel panic on boot most (not all) of the time. With the stick removed, boots are clean. This is with stock arch kernel and modules, version 4.0.1. My pacman install is up to date as of 13 May 2014. Output of 'lsusb -vv' for the offending device is attached. Output of 'journalctl' for the failed boot is attached. Anomalous output happens just after the Lexar device is registered as sd 8:0:0:0: and starts with the sysfs_warn_dup+0x68 warning. Steps to reproduce: Buy the same USB stick, insert it into a USB port, and reboot. |
lsusb.out
This task depends upon
Closed by Eli Schwartz (eschwartz)
Monday, 02 October 2017, 22:17 GMT
Reason for closing: Upstream
Additional comments about closing: The OP no longer has the reproducing hardware and this doesn't seem to have been reported upstream, but there's nothing anyone here can do about it anymore, whether it is still valid or not.
Monday, 02 October 2017, 22:17 GMT
Reason for closing: Upstream
Additional comments about closing: The OP no longer has the reproducing hardware and this doesn't seem to have been reported upstream, but there's nothing anyone here can do about it anymore, whether it is still valid or not.
Is it fixed for you?