Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #72701 > unrolled thread

Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye

Back to article view | Back to linux.debian.kernel

Contents

  Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye Kobus van Schoor <v.schoor.kobus@gmail.com> - 2021-08-21 16:50 +0200
    Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye Diederik de Haas <didi.debian@cknow.org> - 2021-08-21 17:10 +0200
      Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye Kobus van Schoor <v.schoor.kobus@gmail.com> - 2021-08-21 17:50 +0200
        Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye Diederik de Haas <didi.debian@cknow.org> - 2021-08-21 18:20 +0200
          Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye Kobus van Schoor <v.schoor.kobus@gmail.com> - 2021-08-21 19:00 +0200
            Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye Diederik de Haas <didi.debian@cknow.org> - 2021-08-21 20:10 +0200
              Bug#992637: Too aggressive energy savings on kernel 5.10 cause some USB devices to malfunction Diederik de Haas <didi.debian@cknow.org> - 2021-08-21 20:20 +0200
    Processed: Re: Bug#992637: Dropped packets/high latency on USB  bus when using USB oscilloscope in bullseye "Debian Bug Tracking System" <owner@bugs.debian.org> - 2021-08-21 20:10 +0200
    Processed: Re: Bug#992637: Too aggressive energy savings on  kernel 5.10 cause some USB devices to malfunction "Debian Bug Tracking System" <owner@bugs.debian.org> - 2021-08-21 20:20 +0200
    Bug#992637: same here Thomas Braun <thomas@akwgegner.de> - 2022-07-08 13:20 +0200

#72701 — Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye

Package: linux-image-amd64
Version: 5.10.46-4
Severity: important
X-Debbugs-Cc: v.schoor.kobus@gmail.com

Dear Maintainer,

   * What led up to the situation?

After installing bullseye, a specialized piece of hardware that I use
(Hantek 6022BE oscilloscope) has stopped transmitting packets reliably
over USB. This tool is used to read voltages from electronic circuits
in realtime - if there is significant latency or some packets are
dropped the signal becomes distorted and unusable. However, after
working with the maintainer of the software that I use to interact with
the scope (OpenHantek, see GitHub issue
here: https://github.com/OpenHantek/OpenHantek6022/issues/207) it seems
that the issue is specific to my laptop/USB bus. The maintainer
confirmed that if there was significant latency, or if packets were
dropped, the issue would present itself like I'm seeing it. 

The same issue is present on Fedora Workstation 34 on my laptop.

   * What exactly did you do (or not do) that was effective (or
ineffective)?

I've tried various things that didn't help:

- I tried someone else's exact same scope, the same issue occurred (so
the issue is on my laptop)
- I tried the realtime version of the kernel
- I tried all the ports on my laptop, which included USB 2 and 3 ports

Some things that I've noticed:

- My battery lasts significantly longer after upgrading to bullseye
(around 2 hours extra I would guess). I'm not sure if there is now
extra power saving features present in the kernel which might be
interfering with my USB bus. The issue is present both when connected
to AC or when running on battery
- The issue doesn't immediately occur. The device works ok for around
10 seconds before the signal becomes corrupted
- All my other USB devices still seem to work fine (mouse, external
HDD)

Installing buster's latest kernel on bullseye (I added the buster repos
and pinned it, and installed linux-image-4.19.0-17-amd64 from the
oldstable repos) resolves the problem, so it has something to do with
the kernel. Other people have reported that they are not experiencing
the issue on their side, even with the new kernel (however they have
different hardware than me).

I am not seeing any error messages in dmesg, so I presume the kernel is
not aware of the issue.

The oscilloscope’s USB controller is a Cypress CY7C68013A-100AXC (as I
understand it, a EX USB FX2 chip).

My laptop is an HP Probook 450 G5. lspci gives the following output:

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core
Processor Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620
(rev 07)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 08)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-
LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-
LP Serial IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-
LP Serial IO I2C Controller #1 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP
CSME HECI #1 (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA
Controller [AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root
Port #5 (rev f1)
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root
Port #6 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Device 9d1b (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point LPC Controller/eSPI
Controller (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev
21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev
21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev
78)
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
RTS522A PCI Express Card Reader (rev 01)


Please let me know if I can give any more information.

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (1,
'oldstable-updates'), (1, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_ZA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-amd64 depends on:
ii  linux-image-5.10.0-8-amd64  5.10.46-4

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#72702

[Multipart message — attachments visible in raw view] — view raw

On zaterdag 21 augustus 2021 16:42:21 CEST Kobus van Schoor wrote:
> - My battery lasts significantly longer after upgrading to bullseye
> (around 2 hours extra I would guess). I'm not sure if there is now
> extra power saving features present in the kernel which might be
> interfering with my USB bus.

With 'powertop' there's a screen named 'Tunables' and there you can enable or 
disable various power related settings.
Where there previously was a whole list of settings I had to manually enable, 
since recently they're all enabled by default. In my case I disable a setting 
wrt my mouse otherwise it responds poorly.

With 'lsusb [-t]' you should be able to detect where your device is connected 
to and find a matching tunable in powertop and see whether that helps.

[toc] | [prev] | [next] | [standalone]

#72703

Thank you for the suggestion, I booted the old kernel and the new
kernel and compared their tuneables screen to check for differences -
on the new kernel there is a setting "Autosuspend for USB device DSO-
6022BE [OpenHantek]" (which is the device in question) which wasn't
present on the old kernel. Enabling/disabling it however has no effect
(it was set to "Bad" anyway). The only other difference between the
kernels is the runtime pm for my audio controller (which also didn't
make a difference).

On Sat, 2021-08-21 at 16:57 +0200, Diederik de Haas wrote:
> On zaterdag 21 augustus 2021 16:42:21 CEST Kobus van Schoor wrote:
> > - My battery lasts significantly longer after upgrading to bullseye
> > (around 2 hours extra I would guess). I'm not sure if there is now
> > extra power saving features present in the kernel which might be
> > interfering with my USB bus.
> 
> With 'powertop' there's a screen named 'Tunables' and there you can
> enable or 
> disable various power related settings.
> Where there previously was a whole list of settings I had to manually
> enable, 
> since recently they're all enabled by default. In my case I disable a
> setting 
> wrt my mouse otherwise it responds poorly.
> 
> With 'lsusb [-t]' you should be able to detect where your device is
> connected 
> to and find a matching tunable in powertop and see whether that
> helps.

[toc] | [prev] | [next] | [standalone]

#72704

[Multipart message — attachments visible in raw view] — view raw

On zaterdag 21 augustus 2021 17:38:51 CEST Kobus van Schoor wrote:
> Enabling/disabling it however has no effect

It was worth a shot ;-)

> (it was set to "Bad" anyway).

I don't expect much from it, but you could set them all to "Bad". If that 
still doesn't make a difference, then you can fully rule out energy savings.
With 'lsusb -t' you can see that a/your device has a parent and it may be that 
power savings on a/the parent has an effect.
I don't expect it to make a difference, but otoh it's easy to try out.

[toc] | [prev] | [next] | [standalone]

#72705

Thanks Diederik, that did the trick! After setting "Runtime PM for PCI
Device Intel Corporation Sunrise Point-LP CSME HECI #1" to "Bad" the
issue went away :) I can just set it to "Bad", but it was running fine
on "Good" on the previous kernels, so I guess there is still some
regression here (and I don't know what this effect will now have on
battery life). How should I proceed, as the bug's nature has now
changed?

On Sat, 2021-08-21 at 18:08 +0200, Diederik de Haas wrote:
> On zaterdag 21 augustus 2021 17:38:51 CEST Kobus van Schoor wrote:
> > Enabling/disabling it however has no effect
> 
> It was worth a shot ;-)
> 
> > (it was set to "Bad" anyway).
> 
> I don't expect much from it, but you could set them all to "Bad". If
> that 
> still doesn't make a difference, then you can fully rule out energy
> savings.
> With 'lsusb -t' you can see that a/your device has a parent and it
> may be that 
> power savings on a/the parent has an effect.
> I don't expect it to make a difference, but otoh it's easy to try
> out.

[toc] | [prev] | [next] | [standalone]

#72707

[Multipart message — attachments visible in raw view] — view raw

Control: retitle -1 Too aggressive energy savings on kernel 5.10 cause some devices to malfunction

On zaterdag 21 augustus 2021 18:48:31 CEST Kobus van Schoor wrote:
> Thanks Diederik, that did the trick!
> After setting "Runtime PM for PCI Device Intel Corporation Sunrise
> Point-LP CSME HECI #1" to "Bad" the issue went away :)

Great! Now you've narrowed down the issue and have a workaround.

> I can just set it to "Bad", but it was running fine on "Good" on the
> previous kernels, so I guess there is still some regression here

Agreed, this is (or seems like) a regression.

> (and I don't know what this effect will now have on battery life). 

"Bad" should consume a bit more energy, but you can still keep most on "Good",
so you should still have improved battery life.

> How should I proceed, as the bug's nature has now changed?

I don't know that, hopefully more knowledgeable people will chime in.
I have retitled this bug so it better reflects the problem.
AFAICT, it's still a kernel issue. If not, someone else will probably reassign.

Cheers,
  Diederik

[toc] | [prev] | [next] | [standalone]

#72710 — Bug#992637: Too aggressive energy savings on kernel 5.10 cause some USB devices to malfunction

[Multipart message — attachments visible in raw view] — view raw

Control: retitle -1 Too aggressive energy savings on kernel 5.10 cause some USB devices to malfunction

[toc] | [prev] | [next] | [standalone]

#72708 — Processed: Re: Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye

Processing control commands:

> retitle -1 Too aggressive energy savings on kernel 5.10 cause some devices to malfunction
Bug #992637 [linux-image-amd64] Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye
Changed Bug title to 'Too aggressive energy savings on kernel 5.10 cause some devices to malfunction' from 'Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye'.

-- 
992637: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992637
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#72709 — Processed: Re: Bug#992637: Too aggressive energy savings on kernel 5.10 cause some USB devices to malfunction

Processing control commands:

> retitle -1 Too aggressive energy savings on kernel 5.10 cause some USB devices to malfunction
Bug #992637 [linux-image-amd64] Too aggressive energy savings on kernel 5.10 cause some devices to malfunction
Changed Bug title to 'Too aggressive energy savings on kernel 5.10 cause some USB devices to malfunction' from 'Too aggressive energy savings on kernel 5.10 cause some devices to malfunction'.

-- 
992637: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992637
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#75865 — Bug#992637: same here

I've experienced a similiar issue. After an upgrade to debian bullseye most of the USB ports stopped working. Whenever I used a USB device the PC crashed. As they work on Windows it is not a hardware issue.

Removing the power saving with powertop did the trick!

Thanks for posting that!

Mainboard: Asus P9X79

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web