Bug#845942: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later
On Sun, 2016-11-27 at 08:27 +0100, Salvatore Bonaccorso wrote: > This was an intentional change in 4.8.4-1~exp1 afaict, from the > changelog entry: I wonder if this should be promoted to a NEWS.Debian entry? -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#845942: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later
Control: close -1 On Sun, 2016-11-27 at 08:27 +0100, Salvatore Bonaccorso wrote: > This was an intentional change in 4.8.4-1~exp1 afaict, from the > changelog entry: > > * [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE. > This breaks (e)glibc 2.13 and earlier, and can be reverted using the > kernel > parameter: vsyscall=emulate Hmm, I guess we are going to have to run the buildds with that parameter, at least until wheezy LTS runs out. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#845942: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later
Processing control commands: > close -1 Bug #845942 [src:linux] Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later Marked Bug as done -- 845942: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845942 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#845942: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later
Hi Paul, On Sun, Nov 27, 2016 at 03:12:05PM +0800, Paul Wise wrote: > Package: src:linux > Version: 4.8.5-1 > Severity: important > Control: found -1 linux/4.8.7-1 > > After upgrading and rebooting to Linux 4.8.5-1 (now running 4.8.7-1), > I can no longer create wheezy chroots because dpkg inside the chroot > segfaults. In addition, for existing chroots, bash segfaults and so > does the apt-get http helper and a variety of other executables. > Confusingly, not every binary crashes, just a few important ones. > This does not happen with jessie/stretch/sid chroots and does not > happen with wheezy i386 chroots. > > pabs@chianamo ~ $ sudo debootstrap --include=apt --variant=buildd > --force-check-gpg wheezy $(pwd)/tmp-test-debootstrap > http://deb.debian.org/debian > I: Retrieving InRelease > I: Retrieving Release > I: Retrieving Release.gpg > I: Checking Release signature > I: Valid Release signature (key id ED6D65271AACF0FF15D123036FB2A1C265FFB764) > I: Retrieving Packages > I: Validating Packages > I: Resolving dependencies of required packages... > I: Resolving dependencies of base packages... > I: Found additional required dependencies: insserv libbz2-1.0 libdb5.1 > libsemanage-common libsemanage1 libslang2 libustr-1.0-1 > I: Found additional base dependencies: binutils bzip2 cpp cpp-4.7 > debian-archive-keyring dpkg-dev g++ g++-4.7 gcc gcc-4.7 gnupg gpgv > libapt-pkg4.12 libc-dev-bin libc6-dev libclass-isa-perl libdpkg-perl libgdbm3 > libgmp10 libgomp1 libitm1 libmpc2 libmpfr4 libquadmath0 libreadline6 > libstdc++6 libstdc++6-4.7-dev libswitch-perl libtimedate-perl libusb-0.1-4 > linux-libc-dev make patch perl perl-modules readline-common > I: Checking component main on http://deb.debian.org/debian... > I: Retrieving libacl1 2.2.51-8 > I: Validating libacl1 2.2.51-8 > ... > I: Chosen extractor for .deb packages: dpkg-deb > I: Extracting libacl1... > ... > I: Installing core packages... > W: Failure trying to run: chroot /home/pabs/tmp-test-debootstrap dpkg > --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb > W: See /home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log for details > pabs@chianamo ~ $ less > /home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log > pabs@chianamo ~ $ cat > /home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log > gpgv: Signature made Sat Jun 4 19:51:09 2016 AWST > gpgv:using RSA key 8B48AD6246925553 > gpgv: Good signature from "Debian Archive Automatic Signing Key (7.0/wheezy) > " > gpgv: Signature made Sat Jun 4 19:51:09 2016 AWST > gpgv:using RSA key 7638D0442B90D010 > gpgv: Good signature from "Debian Archive Automatic Signing Key (8/jessie) > " > gpgv: Signature made Sat Jun 4 19:56:53 2016 AWST > gpgv:using RSA key 6FB2A1C265FFB764 > gpgv: Good signature from "Wheezy Stable Release Key > " > dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg': > missing description > dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg': > missing architecture > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy bash > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy apt-get > update > E: Method http has died unexpectedly! > E: Sub-process http received a segmentation fault. > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ > dnsdomainname > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ gunzip > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ gzexe > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ login > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ rbash > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ su > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ uncompress > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zcat > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zcmp > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zdiff > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zegrep > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zfgrep > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zforce > Segmentation fault (core dumped) > pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zgrep > Segmentation fault (core dumped) > pabs@chianamo
Bug#845942: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later
Package: src:linux Version: 4.8.5-1 Severity: important Control: found -1 linux/4.8.7-1 After upgrading and rebooting to Linux 4.8.5-1 (now running 4.8.7-1), I can no longer create wheezy chroots because dpkg inside the chroot segfaults. In addition, for existing chroots, bash segfaults and so does the apt-get http helper and a variety of other executables. Confusingly, not every binary crashes, just a few important ones. This does not happen with jessie/stretch/sid chroots and does not happen with wheezy i386 chroots. pabs@chianamo ~ $ sudo debootstrap --include=apt --variant=buildd --force-check-gpg wheezy $(pwd)/tmp-test-debootstrap http://deb.debian.org/debian I: Retrieving InRelease I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id ED6D65271AACF0FF15D123036FB2A1C265FFB764) I: Retrieving Packages I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Found additional required dependencies: insserv libbz2-1.0 libdb5.1 libsemanage-common libsemanage1 libslang2 libustr-1.0-1 I: Found additional base dependencies: binutils bzip2 cpp cpp-4.7 debian-archive-keyring dpkg-dev g++ g++-4.7 gcc gcc-4.7 gnupg gpgv libapt-pkg4.12 libc-dev-bin libc6-dev libclass-isa-perl libdpkg-perl libgdbm3 libgmp10 libgomp1 libitm1 libmpc2 libmpfr4 libquadmath0 libreadline6 libstdc++6 libstdc++6-4.7-dev libswitch-perl libtimedate-perl libusb-0.1-4 linux-libc-dev make patch perl perl-modules readline-common I: Checking component main on http://deb.debian.org/debian... I: Retrieving libacl1 2.2.51-8 I: Validating libacl1 2.2.51-8 ... I: Chosen extractor for .deb packages: dpkg-deb I: Extracting libacl1... ... I: Installing core packages... W: Failure trying to run: chroot /home/pabs/tmp-test-debootstrap dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.26_amd64.deb W: See /home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log for details pabs@chianamo ~ $ less /home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log pabs@chianamo ~ $ cat /home/pabs/tmp-test-debootstrap/debootstrap/debootstrap.log gpgv: Signature made Sat Jun 4 19:51:09 2016 AWST gpgv:using RSA key 8B48AD6246925553 gpgv: Good signature from "Debian Archive Automatic Signing Key (7.0/wheezy) " gpgv: Signature made Sat Jun 4 19:51:09 2016 AWST gpgv:using RSA key 7638D0442B90D010 gpgv: Good signature from "Debian Archive Automatic Signing Key (8/jessie) " gpgv: Signature made Sat Jun 4 19:56:53 2016 AWST gpgv:using RSA key 6FB2A1C265FFB764 gpgv: Good signature from "Wheezy Stable Release Key " dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg': missing description dpkg: warning: parsing file '/var/lib/dpkg/status' near line 5 package 'dpkg': missing architecture Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy bash Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy apt-get update E: Method http has died unexpectedly! E: Sub-process http received a segmentation fault. pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ dnsdomainname Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ gunzip Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ gzexe Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ login Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ rbash Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ su Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ uncompress Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zcat Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zcmp Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zdiff Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zegrep Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zfgrep Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zforce Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zgrep Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zless Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ zmore Segmentation fault (core dumped) pabs@chianamo ~ $ sudo chroot /var/cache/pbuilder/base.cow.wheezy/ znew Seg
Processed: Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later
Processing control commands: > found -1 linux/4.8.7-1 Bug #845942 [src:linux] Linux: regression: cannot create wheezy amd64 chroots under 4.8.5-1 and later Marked as found in versions linux/4.8.7-1. -- 845942: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845942 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)
On Sun, Nov 27, 2016 at 7:50 AM, Ryan Tandy wrote: > Control: tag -1 patch > > On Sat, Nov 26, 2016 at 12:59:21PM -0800, Ryan Tandy wrote: >> >> Unfortunately dmesg and kern.log are flooded with messages like: >> >> [ 161.781360] Bad eraseblock 32764 at 0x0001fff0 >> [ 161.786261] Bad eraseblock 32765 at 0x0001fff4 >> [ 161.791159] Bad eraseblock 32766 at 0x0001fff8 >> [ 161.796058] Bad eraseblock 32767 at 0x0001fffc >> >> and boot takes a very long time due to logging all these messages. I >> suppose that's a side-effect of using the kurobox-pro dtb - guessing it has >> a different flash layout? Glad to hear it works for you. Actually there's less flash on Linkstation GL or Pro/Live than on KuroBox Pro. So using kurobox-pro dtb is just a tentative solution for test purpose. > On Sun, Nov 27, 2016 at 01:20:10AM +0900, Roger Shimizu wrote: >> >> - start your device by kernel 4.3 first. >> - confirm your have flash-kernel and linux-image-4.8.0-1-marvell >> installed. >> - cp /usr/lib/linux-image-4.8.0-1-marvell/orion5x-kuroboxpro.dtb >> /etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb >> - flash-kernel --force 4.8.0-1-marvell Sorry, I forgot to mention after steps above, when you want to switch to another kernel version, and run like - flash-kernel --force The flash-kernel will treat the device as Kurobox Pro. So you need the following command to tell flash-kernel that your device is Linkstation Pro/Live: # echo -n "Buffalo Linkstation Pro/Live" > /etc/flash-kernel/machine After that, you can switch back to kernel 4.3 or 4.4, which use the device file instead of device tree, if you still installed on your system: # flash-kernel --force 4.3.0-1-orion5x - or - # flash-kernel --force 4.4.0-1-marvell Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)
Control: tag -1 patch On Sat, Nov 26, 2016 at 12:59:21PM -0800, Ryan Tandy wrote: Unfortunately dmesg and kern.log are flooded with messages like: [ 161.781360] Bad eraseblock 32764 at 0x0001fff0 [ 161.786261] Bad eraseblock 32765 at 0x0001fff4 [ 161.791159] Bad eraseblock 32766 at 0x0001fff8 [ 161.796058] Bad eraseblock 32767 at 0x0001fffc and boot takes a very long time due to logging all these messages. I suppose that's a side-effect of using the kurobox-pro dtb - guessing it has a different flash layout? Looks like that was the case. I applied your patch to orion5x-linkstation-lsgl.dts, rebuilt the dtb, dropped it into /etc/flash-kernel/dtbs, and ran flash-kernel again. Much better: [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 4.8.0-1-marvell (debian-kernel@lists.debian.org) (gcc version 5.4.1 20161019 (Debian 5.4.1-3) ) #1 Debian 4.8.5-1 (2016-10-28) [0.00] CPU: Feroceon [41069260] revision 0 (ARMv5TEJ), cr=a005317f [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] OF: fdt:Machine model: Buffalo Linkstation Pro/Live [...] [3.297636] sata_mv sata_mv.0: version 1.28 [3.297844] sata_mv sata_mv.0: cannot get optional clkdev [3.320803] sata_mv sata_mv.0: slots 32 ports 2 [3.386495] scsi host0: sata_mv [3.403996] scsi host1: sata_mv [3.411527] ata1: SATA max UDMA/133 irq 28 [3.415723] ata2: SATA max UDMA/133 irq 28 [3.733937] ata1: SATA link down (SStatus 0 SControl 300) [4.212767] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [4.241078] ata2.00: ATA-7: SAMSUNG SP2504C, VT100-41, max UDMA7 [4.247154] ata2.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 31/32) [4.293102] ata2.00: configured for UDMA/133 [4.298609] scsi 1:0:0:0: Direct-Access ATA SAMSUNG SP2504C 0-41 PQ: 0 ANSI: 5 [4.402529] sd 1:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/233 GiB) [4.416368] sd 1:0:0:0: [sda] Write Protect is off [4.421270] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 [4.421705] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [4.474159] sda: sda1 sda2 sda3 < sda5 > [4.493519] sd 1:0:0:0: [sda] Attached SCSI disk
Processed: Re: Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)
Processing control commands: > tag -1 patch Bug #845611 [linux-image-4.8.0-1-marvell] linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL) Added tag(s) patch. -- 845611: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845611 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)
On Sun, Nov 27, 2016 at 01:20:10AM +0900, Roger Shimizu wrote: - start your device by kernel 4.3 first. - confirm your have flash-kernel and linux-image-4.8.0-1-marvell installed. - cp /usr/lib/linux-image-4.8.0-1-marvell/orion5x-kuroboxpro.dtb /etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb - flash-kernel --force 4.8.0-1-marvell ~ # chroot /target flash-kernel --force 4.8.0-1-marvell DTB: orion5x-linkstation-lsgl.dtb Installing /etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb into /boot/dtbs/4.8.0-1-marvell/orion5x-linkstation-lsgl.dtb Taking backup of orion5x-linkstation-lsgl.dtb. Installing new orion5x-linkstation-lsgl.dtb. Installing /etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb into /boot/dtbs/4.8.0-1-marvell/orion5x-linkstation-lsgl.dtb Taking backup of orion5x-linkstation-lsgl.dtb. Installing new orion5x-linkstation-lsgl.dtb. flash-kernel: installing version 4.8.0-1-marvell flash-kernel: appending /etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb to kernel Generating kernel u-boot image... done. Taking backup of uImage.buffalo. Installing new uImage.buffalo. Generating initramfs u-boot image... done. Taking backup of initrd.buffalo. Installing new initrd.buffalo. - check the log of above command, it should use /etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb for building uImage.buffalo, the kernel image for booting - reboot and see the result If the above steps works for you, I can submit the above patch to kernel upstream, and include it into Stretch release. So I'm looking forward to your result. Thank you! It booted! :) Linux xenon 4.8.0-1-marvell #1 Debian 4.8.5-1 (2016-10-28) armv5tel GNU/Linux Unfortunately dmesg and kern.log are flooded with messages like: [ 161.781360] Bad eraseblock 32764 at 0x0001fff0 [ 161.786261] Bad eraseblock 32765 at 0x0001fff4 [ 161.791159] Bad eraseblock 32766 at 0x0001fff8 [ 161.796058] Bad eraseblock 32767 at 0x0001fffc and boot takes a very long time due to logging all these messages. I suppose that's a side-effect of using the kurobox-pro dtb - guessing it has a different flash layout? Anyway, the change to nr-ports=2 looks good! Tested-by: Ryan Tandy Thanks!
Re: make -f debian/rules build - does not correctly rebuild files- why?
On Sat, 2016-11-26 at 17:26 +1100, Andrew Worsley wrote: > I found that rebuilding the kernel package does NOT rebuild the .o > files which I found very surprising. [...] You should not expect this to work in a Debian package, in general. Many source packages create stamp files to record what has already been built and to avoid invoking the upstream build system unncessarily. For the linux source package, you can remove those stamps by running: rm debian/stamps/build* Unless you also modify files under debian/config, you should not remove the other stamp files as that will result in a complete rebuild. Ben. -- Ben Hutchings Beware of programmers who carry screwdrivers. - Leonard Brandwein signature.asc Description: This is a digitally signed message part
Bug#845658: linux: Bad(?) USB device crashes USB system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Paul, On Sat, 2016-11-26 at 17:28 +0100, Paul Menzel wrote: > > > I've had similar issues on my box. I worked with the USB folks but really > > couldn't come up with a convincing resolution. > > Is that discussion public? Could you please give me the thread subject > or URL? > Yes. Part of it we root caused. But not what was bothering me. The conclusion was that I have a broken device. I'm not convinced, given that under Windows it works perfect, but then I don't have the resource to challenge the statement. You can access the thread at: https://www.mail-archive.com/linux-usb@vger.kernel.org/msg79514.html It should lead you to the rest of the thread. > > Nov 25 18:46:54 learner kernel: usb 2-4: Product: USB2.0-CRW > > Nov 25 18:46:54 learner kernel: usb 2-4: Manufacturer: Generic > > Are you able to reproduce the crash? > I guess you mean the erratic USB disconnects. Yes. And once they trigger, the erratic USB device vanishes from the `lsusb` listing. > > But what do you mean by "crashed" ? The particular USB port becomes > > inaccessible. > > Indeed, it does not crash the Linux kernel, but the USB port is not > usable anymore. > Yes. IN my case, it is not the port which is reflecting the disconnects, but rather one of the USB devices (SDCard Reader). But I do very very occasionally get other devices also to reset, so it could be a much more severe problem, yet to root cause. > > The kernel still works, maybe inefficient, but it does not crash > > the kernel. > > Indeed. What do you mean by inefficient? > Well. The USB device resets very frequently, like every 10 seconds. This overall has the side-effect of drawing too much power on my laptop. > I noticed, that `uptime`, `top`, or `htop` display a high usage. For > each `lsusb` I started (for debugging) it looks like one CPU core gets > used 100 %? > > ``` > $ uptime > 17:17:37 up x days, 9:34, x users, load average: 7,29, 7,64, 7,82 > ``` > I haven't monitored this aspect, but it is possible that this too may be happening, though for a small amount of time. > I can find no processes in `htop` or `top` using that much CPU. I have > no idea how to find out what is causing this, but I’d guess it’s > something in the Linux kernel. > Yes. Because it is in the kernel. If it were related to I/O, you may have noticed per-BDI threads, but in this case, these are device resets and disconnects. So there's not much to capture in process listings. You could gather some additional information from udev, because your USB disconnects are equivalent to physical device plug/unplug, which triggers in the hotplug mechanism. At least, it may tell you how frequent your disconnect errors are happening. And if you have heavy (USB) rules processing, then it could be the cause of your sudden load increase. I hope this information helps you. - -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEQCVDstmIVAB/Yn02pjpYo/LhdWkFAlg5wAQACgkQpjpYo/Lh dWkNeA/7BNaIkRnobzGPzLjKnbw5X5uEt/MHmRRakDsgDB6232elJC/8ON0BkGYv zYp4vGVkr+hyx6WSBoB/3bH4DijOuZmWJNN5YPrL/dBBGmWCDTeptmj9adSyO1C5 chX+wLMnqV07dz55GAkz2y1CiClUp/bxO1Qtx5eBJNod94i0KVWbrK4bYSP0vRuv 6R0JOVjOJHqKK0RpHmNqHKroFXVDsJ0hugCRVCz9ksrSPQ6NWrFn/cphmX3KNXLC kpEyhwIb3x4G/31OrTRL7HErb2CabIvdX6NCyNm2c6QA+7aLBIJxaos0nuH8hKQ0 MmS+KbCLtL600+zitIO16av7Ercd3P49PTcnqjGWiUaASD2uYcdvl6UiIn45b2dL aAWf3ZeuFRKt6coFl0bgvDoMoJ1hOqS3daY3itlnkXhRNb7+gXXBqw3rat3RpQOz oFaKgExJqvvzYPwmQyAuwopsWezsTTEJCDfBXNsbM7y77uAUzoeuRNry16dbk7gF BI0F5YB2BbJYHoNzyhzFkEKEEjEud9YX6SpnzeuIuWwx7zqvr24PRnQfZm0N5Db2 61ycsFOZDYxgoG2928qo/TE6jZIfqtZ3S25FSs1qSVZYiy/oDSguU85bzSBSue1o 2ZGDsCir8N4jtx1TOFVrsZP2k9cNqZwWO/wIKn7t1XozkxXPTPw= =1aXQ -END PGP SIGNATURE-
Bug#845658: linux: Bad(?) USB device crashes USB system
n another USB device it’s not detected anymore. > > > > As this is in a remote server data center, and this is a production > > system, I am unsure how to debug that. I think the Linux kernel USB > > subsystem shouldn’t be crashed by a bad USB device. > > I've had similar issues on my box. I worked with the USB folks but really > couldn't come up with a convincing resolution. Is that discussion public? Could you please give me the thread subject or URL? > There are logs from my machine: > > Nov 25 18:42:18 learner kernel: usb 2-4: new high-speed USB device number 29 > using xhci_hcd > Nov 25 18:42:24 learner kernel: usb 2-4: new high-speed USB device number 31 > using xhci_hcd > Nov 25 18:42:29 learner kernel: usb 2-4: new high-speed USB device number 32 > using xhci_hcd > Nov 25 18:42:38 learner kernel: usb 2-4: new high-speed USB device number 48 > using xhci_hcd > Nov 25 18:42:44 learner kernel: usb 2-4: new high-speed USB device number 50 > using xhci_hcd > Nov 25 18:42:59 learner kernel: usb 2-4: new high-speed USB device number 93 > using xhci_hcd > Nov 25 18:43:05 learner kernel: usb 2-4: new high-speed USB device number 97 > using xhci_hcd > Nov 25 18:43:11 learner kernel: usb 2-4: new high-speed USB device number 100 > using xhci_hcd > Nov 25 18:43:18 learner kernel: usb 2-4: new high-speed USB device number 109 > using xhci_hcd > Nov 25 18:43:24 learner kernel: usb 2-4: new high-speed USB device number 110 > using xhci_hcd > Nov 25 18:43:30 learner kernel: usb 2-4: new high-speed USB device number 113 > using xhci_hcd > Nov 25 18:43:35 learner kernel: usb 2-4: new high-speed USB device number 114 > using xhci_hcd > Nov 25 18:43:41 learner kernel: usb 2-4: new high-speed USB device number 115 > using xhci_hcd > Nov 25 18:43:46 learner kernel: usb 2-4: new high-speed USB device number 116 > using xhci_hcd > Nov 25 18:43:47 learner kernel: usb 2-4: new high-speed USB device number 118 > using xhci_hcd > Nov 25 18:43:47 learner kernel: usb 2-4: new high-speed USB device number 119 > using xhci_hcd > Nov 25 18:43:53 learner kernel: usb 2-4: new high-speed USB device number 121 > using xhci_hcd > Nov 25 18:43:59 learner kernel: usb 2-4: new high-speed USB device number 124 > using xhci_hcd > Nov 25 18:44:04 learner kernel: usb 2-4: new high-speed USB device number 126 > using xhci_hcd > Nov 25 18:44:11 learner kernel: usb 2-4: new high-speed USB device number 10 > using xhci_hcd > Nov 25 18:44:17 learner kernel: usb 2-4: new high-speed USB device number 12 > using xhci_hcd > Nov 25 18:44:17 learner kernel: usb 2-4: new high-speed USB device number 14 > using xhci_hcd > Nov 25 18:44:17 learner kernel: usb 2-4: Device not responding to setup > address. > Nov 25 18:44:18 learner kernel: usb 2-4: Device not responding to setup > address. > Nov 25 18:44:18 learner kernel: usb 2-4: device not accepting address 14, > error -71 > Nov 25 18:44:18 learner kernel: usb 2-4: new high-speed USB device number 16 > using xhci_hcd > Nov 25 18:44:18 learner kernel: usb 2-4: Device not responding to setup > address. > Nov 25 18:44:18 learner kernel: usb 2-4: Device not responding to setup > address. > Nov 25 18:44:19 learner kernel: usb 2-4: device not accepting address 16, > error -71 > Nov 25 18:44:19 learner kernel: usb 2-4: new high-speed USB device number 18 > using xhci_hcd > Nov 25 18:44:24 learner kernel: usb 2-4: new high-speed USB device number 19 > using xhci_hcd > Nov 25 18:44:25 learner kernel: usb 2-4: New USB device found, idVendor=0bda, > idProduct=0129 > Nov 25 18:44:25 learner kernel: usb 2-4: New USB device strings: Mfr=1, > Product=2, SerialNumber=3 > Nov 25 18:44:25 learner kernel: usb 2-4: Product: USB2.0-CRW > Nov 25 18:44:25 learner kernel: usb 2-4: Manufacturer: Generic > Nov 25 18:44:25 learner kernel: usb 2-4: SerialNumber: 2010020139600 > Nov 25 18:46:53 learner kernel: usb 2-4: USB disconnect, device number 19 > Nov 25 18:46:54 learner kernel: usb 2-4: new high-speed USB device number 20 > using xhci_hcd > Nov 25 18:46:54 learner kernel: usb 2-4: New USB device found, idVendor=0bda, > idProduct=0129 > Nov 25 18:46:54 learner kernel: usb 2-4: New USB device strings: Mfr=1, > Product=2, SerialNumber=3 > Nov 25 18:46:54 learner kernel: usb 2-4: Product: USB2.0-CRW > Nov 25 18:46:54 learner kernel: usb 2-4: Manufacturer: Generic Are you able to reproduce the crash? > But what do you mean by "crashed" ? The particular USB port becomes > inaccessible. Indeed, it does not crash the Linux kernel, but the USB port is not usable anymore. > The kernel still works, maybe inefficient, but it does not crash > the kernel. Indeed. What do you mean by ineffici
Bug#845611: linux-image-4.8.0-1-marvell: hard drive not detected on LinkStation Pro (LS-GL)
Dear Ryan,
On Fri, Nov 25, 2016 at 4:24 PM, Ryan Tandy wrote:
>
> [ 611.971107] scsi host0: sata_mv
> [ 611.984111] scsi host1: sata_mv
> [ 611.984881] ata1: SATA max UDMA/133 irq 30
> [ 611.984916] ata2: SATA max UDMA/133 irq 30
> [ 612.302763] ata1: SATA link down (SStatus 0 SControl 300)
> [ 612.778697] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [ 612.787074] ata2.00: ATA-7: SAMSUNG SP2504C, VT100-41, max UDMA7
> [ 612.787118] ata2.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 31/32)
> [ 612.819082] ata2.00: configured for UDMA/133
Looks like your LS-GL really uses the 2nd SATA port.
Though my LS-GL works fine with current DTS.
So it need the following patch to be applied.
diff --git a/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
b/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
index 1cf644b..51dc734 100644
--- a/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
+++ b/arch/arm/boot/dts/orion5x-linkstation-lsgl.dts
@@ -82,6 +82,10 @@
gpios = <&gpio0 9 GPIO_ACTIVE_HIGH>;
};
+&sata {
+nr-ports = <2>;
+};
+
&ehci1 {
status = "okay";
};
On Sat, Nov 26, 2016 at 1:10 AM, Ryan Tandy wrote:
>
> kurobox_pro-setup.c, AFAIK, used to be used on several related platforms.
> The kurobox pro and LS-GL are nearly identical.
Yes. So maybe the easiest way for you is:
- start your device by kernel 4.3 first.
- confirm your have flash-kernel and linux-image-4.8.0-1-marvell installed.
- cp /usr/lib/linux-image-4.8.0-1-marvell/orion5x-kuroboxpro.dtb
/etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb
- flash-kernel --force 4.8.0-1-marvell
- check the log of above command, it should use
/etc/flash-kernel/dtbs/orion5x-linkstation-lsgl.dtb for building
uImage.buffalo, the kernel image for booting
- reboot and see the result
If the above steps works for you, I can submit the above patch to
kernel upstream, and include it into Stretch release.
So I'm looking forward to your result. Thank you!
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#787326: Toshiba NB500 is also affected.
Today after a reboot the builtin WiFi works (identified as wlan2). 2016-11-25 16:08 GMT+01:00 Roberto Ríos Gallardo : > If I plug in a USB WiFi stick with a different brand of chip (Atheros) it > (the Atheros) works. > > [ 1288.500070] usb 3-5: new high-speed USB device number 8 using ehci-pci > [ 1288.648969] usb 3-5: New USB device found, idVendor=0cf3, idProduct=9271 > [ 1288.648984] usb 3-5: New USB device strings: Mfr=16, Product=32, > SerialNumber=48 > [ 1288.648995] usb 3-5: Product: USB2.0 WLAN > [ 1288.649003] usb 3-5: Manufacturer: ATHEROS > [ 1288.649011] usb 3-5: SerialNumber: 12345 > [ 1288.649994] usb 3-5: ath9k_htc: Firmware htc_9271.fw requested > [ 1288.650254] usb 3-5: firmware: direct-loading firmware htc_9271.fw > [ 1288.930988] usb 3-5: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272 > [ 1289.168861] ath9k_htc 3-5:1.0: ath9k_htc: HTC initialized with 33 > credits > [ 1289.437866] ath9k_htc 3-5:1.0: ath9k_htc: FW Version: 1.3 > [ 1289.437879] ath: EEPROM regdomain: 0x809c > [ 1289.437886] ath: EEPROM indicates we should expect a country code > [ 1289.437892] ath: doing EEPROM country->regdmn map search > [ 1289.437898] ath: country maps to regdmn code: 0x52 > [ 1289.437910] ath: Country alpha2 being used: CN > [ 1289.437913] ath: Regpair used: 0x52 > [ 1289.467835] ieee80211 phy0: Atheros AR9271 Rev:1 > [ 1289.467927] cfg80211: Calling CRDA for country: CN > [ 1289.477069] cfg80211: Regulatory domain changed to country: CN > [ 1289.477079] cfg80211: DFS Master region: FCC > [ 1289.477083] cfg80211: (start_freq - end_freq @ bandwidth), > (max_antenna_gain, max_eirp), (dfs_cac_time) > [ 1289.477090] cfg80211: (2402000 KHz - 2482000 KHz @ 4 KHz), (N/A, > 2000 mBm), (N/A) > [ 1289.477096] cfg80211: (517 KHz - 525 KHz @ 8 KHz, 16 > KHz AUTO), (N/A, 2300 mBm), (N/A) > [ 1289.477102] cfg80211: (525 KHz - 533 KHz @ 8 KHz, 16 > KHz AUTO), (N/A, 2300 mBm), (0 s) > [ 1289.477107] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, > 3000 mBm), (N/A) > [ 1289.477112] cfg80211: (5724 KHz - 5940 KHz @ 216 KHz), > (N/A, 2800 mBm), (N/A) > [ 1289.477118] cfg80211: (5940 KHz - 6372 KHz @ 216 KHz), > (N/A, 4400 mBm), (N/A) > [ 1289.477123] cfg80211: (6372 KHz - 6588 KHz @ 216 KHz), > (N/A, 2800 mBm), (N/A) > [ 1289.816610] systemd-udevd[1542]: renamed network interface wlan0 to > wlan1 > [ 1290.143509] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready > > > 2016-11-24 18:21 GMT+01:00 Roberto Ríos Gallardo : > >> It also happens on Toshiba NB500 on a fresh install performed today with >> the stable netinstall iso. >> Previously it was working, on the same version of debian, last upgraded >> about a month ago. >> >> I am using the latest version on stable, obviously, it was just installed >> from the repos after apt-get update. >> >> root@libroverde:/home/usuario# lsusb >> Bus 005 Device 002: ID 04f2:b1d6 Chicony Electronics Co., Ltd CNF9055 >> Toshiba Webcam >> Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 004 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 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> root@libroverde:/home/usuario# >> >> root@libroverde:/home/usuario# rfkill list >> root@libroverde:/home/usuario# >> >> >> Output of dmesg: >> [0.00] Initializing cgroup subsys cpuset >> [0.00] Initializing cgroup subsys cpu >> [0.00] Initializing cgroup subsys cpuacct >> [0.00] Linux version 3.16.0-4-amd64 ( >> debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 >> SMP Debian 3.16.36-1+deb8u2 (2016-10-19) >> [0.00] Command line: BOOT_IMAGE=/vmlinuz-3.16.0-4-amd64 >> root=/dev/mapper/libroverde--vg-root ro quiet >> [0.00] e820: BIOS-provided physical RAM map: >> [0.00] BIOS-e820: [mem 0x-0x0009dbff] >> usable >> [0.00] BIOS-e820: [mem 0x0009dc00-0x0009] >> reserved >> [0.00] BIOS-e820: [mem 0x000dc000-0x000d] >> reserved >> [0.00] BIOS-e820: [mem 0x000e4000-0x000f] >> reserved >> [0.00] BIOS-e820: [mem 0x0010-0x7f5c] >> usable >> [0.00] BIOS-e820: [mem 0x7f5d-0x7f5d] >> ACPI data >> [0.00] BIOS-e820: [mem 0x7f5e-0x7f5e2fff] >> ACPI NVS >> [0.00] BIOS-e820: [mem 0x7f5e3000-0x7fff] >> reserved >> [0.00] BIOS-e820: [mem 0xe000-0xefff] >> reserved >> [0.00] BIOS-e820: [mem 0xfec0-0xfec0] >> reserved >> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] >> reserved >> [0.00] BIOS-e820: [mem 0xff00-0x] >> reserved
Bug#845422: [PATCH] Please add BCM2835 MMC driver for Raspberry Pi 3
On Sat, Nov 26, 2016 at 12:05 AM, Aurelien Jarno
wrote:
> On 2016-11-23 09:43, Michael Stapelberg wrote:
> > Source: linux
> > Severity: wishlist
> > Tags: patch
> >
> > Thank you for your work on maintaining the Linux kernel in Debian, I
> really
> > appreciate it!
> >
> > I am interested in running Debian on the Raspberry Pi 3.
> >
> > As per https://github.com/anholt/linux/wiki/Raspberry-Pi-3, the
> mainline Linux
> > kernel in version 4.8 includes support for the Raspberry Pi 3, so we are
> in
> > pretty good shape already.
> >
> > However, when trying to boot linux-image-4.8.0-1-arm64 version 4.8.5-1, I
> > noticed that the kernel can’t find any block devices (and hence no root
> file
> > system). This is because the bcm2835-sdhost MMC driver has not actually
> made it
> > into Linux 4.8; it is still under review:
> > https://www.spinics.net/lists/arm-kernel/msg513433.html
>
> While this is correct, please note that the BCM2835 has two sdhost
> controller, one that can be used for the wireless card and one for the
> sdcard. The 4.8 kernel already has support for the other sdhost
> controller, namely the iProc one. You can use this one for your root
> filesystem as it is built in the Debian kernel.
>
> I guess you have a problem somewhere, maybe in the device tree that
> causes the wrong SD controller to be used. I use the device tree that is
> provided by the kernel:
>
Thanks for pointing this out! I must have indeed messed up the DTB while
testing. I just installed linux-image-4.8.0-1-arm64 without any
modifications and could indeed still boot successfully. So, this bug is no
longer a blocker for Raspberry Pi 3 support, but would still be good to get
fixed to enable us to make progress on the WiFi card support.
>
> |sdhci: sdhci@7e30 {
> |compatible = "brcm,bcm2835-sdhci";
> |reg = <0x7e30 0x100>;
> |interrupts = <2 30>;
> |clocks = <&clocks BCM2835_CLOCK_EMMC>;
> |status = "disabled";
> |};
>
> This work since at least kernel 4.8.4-1~exp1.
>
> Aurelien
>
> --
> Aurelien Jarno GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net
>
--
Best regards,
Michael
Bug#845658: linux: Bad(?) USB device crashes USB system
Hi, On Fri, 2016-11-25 at 17:53 +0100, Paul Menzel wrote: > > Nov 23 05:31:36 hamburg01 kernel: usb 3-1: new high-speed USB device number > 5 using xhci_hcd > > Nov 23 05:31:36 hamburg01 kernel: usb 3-1: New USB device found, > idVendor=05e3, idProduct=0608 > > Nov 23 05:31:36 hamburg01 kernel: usb 3-1: New USB device strings: Mfr=0, > Product=1, SerialNumber=0 > > Nov 23 05:31:36 hamburg01 kernel: usb 3-1: Product: USB2.0 Hub > > Nov 23 05:31:36 hamburg01 kernel: hub 3-1:1.0: USB hub found > > Nov 23 05:31:36 hamburg01 kernel: hub 3-1:1.0: 4 ports detected > > Nov 23 05:31:36 hamburg01 kernel: usb 3-1.2: new low-speed USB device number > 6 using xhci_hcd > > Nov 23 05:31:36 hamburg01 kernel: usb 3-1.2: New USB device found, > idVendor=0a81, idProduct=0205 > > Nov 23 05:31:36 hamburg01 kernel: usb 3-1.2: New USB device strings: Mfr=1, > Product=2, SerialNumber=0 > > Nov 23 05:31:36 hamburg01 kernel: usb 3-1.2: Product: PS2 to USB Converter > > Nov 23 05:31:36 hamburg01 kernel: usb 3-1.2: Manufacturer: CHESEN > > Nov 23 05:31:36 hamburg01 kernel: usb 3-1.2: ep 0x81 - rounding interval to > 64 microframes, ep desc says 80 microframes > > Nov 23 05:31:36 hamburg01 kernel: usb 3-1.2: ep 0x82 - rounding interval to > 64 microframes, ep desc says 80 microframes > > Nov 23 05:31:36 hamburg01 kernel: input: CHESEN PS2 to USB Converter as > /devices/pci:00/:00:14.0/usb3/3-1/3-1.2/3- > 1.2:1.0/0003:0A81:0205.0005/input/input8 > > Nov 23 05:31:36 hamburg01 kernel: hid-generic 0003:0A81:0205.0005: > input,hidraw4: USB HID v1.10 Keyboard [CHESEN PS2 to USB Converter] on usb- > :00:14.0-1.2/input0 > > Nov 23 05:31:36 hamburg01 kernel: input: CHESEN PS2 to USB Converter as > /devices/pci:00/:00:14.0/usb3/3-1/3-1.2/3- > 1.2:1.1/0003:0A81:0205.0006/input/input9 > > Nov 23 05:31:36 hamburg01 kernel: hid-generic 0003:0A81:0205.0006: > input,hidraw5: USB HID v1.10 Mouse [CHESEN PS2 to USB Converter] on usb- > :00:14.0-1.2/input1 > > Nov 23 05:31:38 hamburg01 kernel: usb 3-1: USB disconnect, device number 5 > > Nov 23 05:31:38 hamburg01 kernel: usb 3-1.2: USB disconnect, device number 6 > > Nov 23 05:31:38 hamburg01 kernel: usb 3-1: new high-speed USB device number > 7 using xhci_hcd > > Nov 23 05:31:38 hamburg01 kernel: usb 3-1: New USB device found, > idVendor=05e3, idProduct=0608 > > Nov 23 05:31:38 hamburg01 kernel: usb 3-1: New USB device strings: Mfr=0, > Product=1, SerialNumber=0 > > Nov 23 05:31:38 hamburg01 kernel: usb 3-1: Product: USB2.0 Hub > > Nov 23 05:31:38 hamburg01 kernel: hub 3-1:1.0: USB hub found > > Nov 23 05:31:38 hamburg01 kernel: hub 3-1:1.0: 4 ports detected > > Nov 23 05:31:39 hamburg01 kernel: usb 3-1.2: new low-speed USB device number > 8 using xhci_hcd > > Nov 23 05:31:39 hamburg01 kernel: usb 3-1.2: New USB device found, > idVendor=0a81, idProduct=0205 > > Nov 23 05:31:39 hamburg01 kernel: usb 3-1.2: New USB device strings: Mfr=1, > Product=2, SerialNumber=0 > > Nov 23 05:31:39 hamburg01 kernel: usb 3-1.2: Product: PS2 to USB Converter > > Nov 23 05:31:39 hamburg01 kernel: usb 3-1.2: Manufacturer: CHESEN > > Nov 23 05:31:39 hamburg01 kernel: usb 3-1.2: ep 0x81 - rounding interval to > 64 microframes, ep desc says 80 microframes > > Nov 23 05:31:39 hamburg01 kernel: usb 3-1.2: ep 0x82 - rounding interval to > 64 microframes, ep desc says 80 microframes > > Nov 23 05:31:39 hamburg01 kernel: input: CHESEN PS2 to USB Converter as > /devices/pci:00/:00:14.0/usb3/3-1/3-1.2/3- > 1.2:1.0/0003:0A81:0205.0007/input/input10 > > Nov 23 05:31:39 hamburg01 kernel: hid-generic 0003:0A81:0205.0007: > input,hidraw4: USB HID v1.10 Keyboard [CHESEN PS2 to USB Converter] on usb- > :00:14.0-1.2/input0 > > Nov 23 05:31:39 hamburg01 kernel: input: CHESEN PS2 to USB Converter as > /devices/pci:00/:00:14.0/usb3/3-1/3-1.2/3- > 1.2:1.1/0003:0A81:0205.0008/input/input11 > > Nov 23 05:31:39 hamburg01 kernel: hid-generic 0003:0A81:0205.0008: > input,hidraw5: USB HID v1.10 Mouse .snipped. > > > Plugging in another USB device it’s not detected anymore. > > As this is in a remote server data center, and this is a production > system, I am unsure how to debug that. I think the Linux kernel USB > subsystem shouldn’t be crashed by a bad USB device. I've had similar issues on my box. I worked with the USB folks but really couldn't come up with a convincing resolution. There are logs from my machine: Nov 25 18:42:18 learner kernel: usb 2-4: new high-speed USB device number 29 using xhci_hcd Nov 25 18:42:24 learner kernel: usb 2-4: new high-speed USB device number 31 using xhci_hcd Nov 25 18:42:29 learner kernel: usb 2-4: new high-speed USB device number 32 using xhci_hcd Nov 25 18:42:38 learner kernel: usb 2-4: new high-speed USB device number 48 using xhci_hcd Nov 25 18:42:44 learner kernel: usb 2-4: new high-speed USB device number 50 using xhci_hcd Nov 25 18:42:59 learner kernel: usb 2-4: new high-speed USB device number 93 using xhci_hcd
