Re: RES: TP-LINK USB no carrier after speed test
On 26.09.2022 17:29, Hans Petter Selasky wrote: I've got a supposedly "broken" if_ure dongle from Alexander, but I'm unable to reproduce the if_ure hang on two different pieces of XHCI hardware, Intel based and AMD based, which I've got. This leads me to believe there is a bug in the XHCI driver or hardware on your system. Can you share the pciconfig -lv output for your XHCI controllers? I have two laptops of different generations reproducing this problem, but both are having Thunderbolt on the USB-C ports: This is one (7th Gen Core i7): xhci1@pci0:56:0:0: class=0x0c0330 rev=0x02 hdr=0x00 vendor=0x8086 device=0x15d4 subvendor=0x subdevice=0x vendor = 'Intel Corporation' device = 'JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016]' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xc3f0, size 65536, enabled cap 01[80] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 message cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS max read 512 link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1) ClockPM disabled ecap 0003[100] = Serial 1 20ff910876f10c00 ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected ecap 0002[300] = VC 1 max VC0 ecap 0004[400] = Power Budgeting 1 ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216 ecap 0018[600] = LTR 1 ecap 0019[700] = PCIe Sec 1 lane errors 0 This is another (11th Gen Core i7); xhci0@pci0:0:13:0: class=0x0c0330 rev=0x01 hdr=0x00 vendor=0x8086 device=0x9a13 subvendor=0x1028 subdevice=0x0991 vendor = 'Intel Corporation' device = 'Tiger Lake-LP Thunderbolt 4 USB Controller' class = serial bus subclass = USB bar [10] = type Memory, range 64, base 0x60552c, size 65536, enabled cap 01[70] = powerspec 2 supports D0 D3 current D0 cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message cap 09[90] = vendor (length 20) Intel cap 15 version 0 cap 09[b0] = vendor (length 0) Intel cap 0 version 1 Does the system you also has Thunderbolt chip, or you use native Intel chipet's XHCI? Also, when running the stress test and you see the traffic stops, what happens if you run this command as root on the ugen which the if_ure belongs to: usbconfig -d ugenX.Y dump_string 0 Does the traffic resume? Nope. Out of 4 times when traffic stopped 2 times it reported error> and 2 times it completed successfully, but it neither case it recovered traffic. Only reset recovered it. -- Alexander Motin
Re: RES: TP-LINK USB no carrier after speed test
On Mon, 26 Sep 2022, Hans Petter Selasky wrote: On 9/26/22 21:28, Alexander Motin wrote: Ivan, On 26.09.2022 13:11, Ivan Quitschal wrote: bad news im afraid, problem occurred at the first attempt on speedtest.net. and I'm really trying to help you analizying this code here myself, but problem is: im far from expert on network protocol business. if it is a network problem at all. seems to me more like a USB protocol limit issue or something .. just FYI , limiting that first constant to 2048 still limits my upload to 90mbps , and also still solves the issue .. there has to be something about it obviously On my tests I found that reduction of URE_MAX_TX from 4 to 1 actually help a lot more without so dramatic performance decrease. Though it is likely only a workaround and does not explain the cause, so I hope Hans more ideas for us to test. ;) Hi, I've got a supposedly "broken" if_ure dongle from Alexander, but I'm unable to reproduce the if_ure hang on two different pieces of XHCI hardware, Intel based and AMD based, which I've got. This leads me to believe there is a bug in the XHCI driver or hardware on your system. Can you share the pciconfig -lv output for your XHCI controllers? Also, when running the stress test and you see the traffic stops, what happens if you run this command as root on the ugen which the if_ure belongs to: usbconfig -d ugenX.Y dump_string 0 Does the traffic resume? --HPS hi Hans without any patch , the actual code on repository pciconf -lv xhci0@pci0:0:20:0: class=0x0c0330 rev=0x20 hdr=0x00 vendor=0x8086 device=0xa0ed subvendor=0x1028 subdevice=0x0ab0 vendor = 'Intel Corporation' device = 'Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller' class = serial bus subclass = USB did the stress test, got the problem, then i tried the below [root@tzk-inspiron ~ ]# usbconfig -d ugen0.6 dump_string 0 STRING_0x00 = 0x04, 0x03, 0x09, 0x04 [root@tzk-inspiron ~ ]# nothing happened, still no carrier. in order to get back the internet i had to [root@tzk-inspiron ~ ]# usbconfig -d ugen0.6 reset --tzk
RES: RES: TP-LINK USB no carrier after speed test
> -Mensagem original- > De: Hans Petter Selasky > Enviada em: segunda-feira, 26 de setembro de 2022 18:29 > Para: Alexander Motin ; Ivan Quitschal > > Cc: freebsd-current@freebsd.org; freebsd-...@freebsd.org > Assunto: Re: RES: TP-LINK USB no carrier after speed test > > On 9/26/22 21:28, Alexander Motin wrote: > > Ivan, > > > > On 26.09.2022 13:11, Ivan Quitschal wrote: > >> bad news im afraid, problem occurred at the first attempt on > >> speedtest.net. > >> and I'm really trying to help you analizying this code here myself, > >> but problem is: im far from expert on network protocol business. if > >> it is a network problem at all. seems to me more like a USB protocol > >> limit issue or something .. just FYI , limiting that first constant > >> to 2048 still limits my upload to 90mbps , and also still solves the > >> issue .. there has to be something about it obviously > > > > On my tests I found that reduction of URE_MAX_TX from 4 to 1 actually > > help a lot more without so dramatic performance decrease. Though it > > is likely only a workaround and does not explain the cause, so I hope > > Hans more ideas for us to test. ;) > > > > Hi, > > I've got a supposedly "broken" if_ure dongle from Alexander, but I'm unable to > reproduce the if_ure hang on two different pieces of XHCI hardware, Intel > based > and AMD based, which I've got. > > This leads me to believe there is a bug in the XHCI driver or hardware on your > system. > > Can you share the pciconfig -lv output for your XHCI controllers? > > Also, when running the stress test and you see the traffic stops, what > happens if > you run this command as root on the ugen which the if_ure belongs to: > > usbconfig -d ugenX.Y dump_string 0 > > Does the traffic resume? > > --HPS Hi Hans, how do you want me to do those tests for you ? with or without any of your patches? With the actual code on git ? hi Alexander, I did what you suggested, and what happened was the inverse, the upload got back to 300mbps , and what dropped to a half was the download, dropped to 200 instead of 600 hehe --tzk
Re: RES: TP-LINK USB no carrier after speed test
On 9/26/22 21:28, Alexander Motin wrote: Ivan, On 26.09.2022 13:11, Ivan Quitschal wrote: bad news im afraid, problem occurred at the first attempt on speedtest.net. and I'm really trying to help you analizying this code here myself, but problem is: im far from expert on network protocol business. if it is a network problem at all. seems to me more like a USB protocol limit issue or something .. just FYI , limiting that first constant to 2048 still limits my upload to 90mbps , and also still solves the issue .. there has to be something about it obviously On my tests I found that reduction of URE_MAX_TX from 4 to 1 actually help a lot more without so dramatic performance decrease. Though it is likely only a workaround and does not explain the cause, so I hope Hans more ideas for us to test. ;) Hi, I've got a supposedly "broken" if_ure dongle from Alexander, but I'm unable to reproduce the if_ure hang on two different pieces of XHCI hardware, Intel based and AMD based, which I've got. This leads me to believe there is a bug in the XHCI driver or hardware on your system. Can you share the pciconfig -lv output for your XHCI controllers? Also, when running the stress test and you see the traffic stops, what happens if you run this command as root on the ugen which the if_ure belongs to: usbconfig -d ugenX.Y dump_string 0 Does the traffic resume? --HPS
Re: RES: TP-LINK USB no carrier after speed test
Ivan, On 26.09.2022 13:11, Ivan Quitschal wrote: bad news im afraid, problem occurred at the first attempt on speedtest.net. and I'm really trying to help you analizying this code here myself, but problem is: im far from expert on network protocol business. if it is a network problem at all. seems to me more like a USB protocol limit issue or something .. just FYI , limiting that first constant to 2048 still limits my upload to 90mbps , and also still solves the issue .. there has to be something about it obviously On my tests I found that reduction of URE_MAX_TX from 4 to 1 actually help a lot more without so dramatic performance decrease. Though it is likely only a workaround and does not explain the cause, so I hope Hans more ideas for us to test. ;) -- Alexander Motin
Re: RES: TP-LINK USB no carrier after speed test
On Mon, 26 Sep 2022, Hans Petter Selasky wrote: Hi Ivan, Can you revert all if_ure patches, and try this one instead. --HPS hi Hans bad news im afraid, problem occurred at the first attempt on speedtest.net. and I'm really trying to help you analizying this code here myself, but problem is: im far from expert on network protocol business. if it is a network problem at all. seems to me more like a USB protocol limit issue or something .. just FYI , limiting that first constant to 2048 still limits my upload to 90mbps , and also still solves the issue .. there has to be something about it obviously dont remember if i told you that but the tp-link adapter is currently plugged in a USB 3.2 port anyway anything i could do to help you on something here? just let me know thanks --tzk
Re: usbhid panic when switching vt-s (invariants+witness enabled)
On 9/23/22 23:43, Hans Petter Selasky wrote: vpanic() at 0x808f4c84 = vpanic+0x184/frame 0xfe003590e900 panic() at 0x808f4a33 = panic+0x43/frame 0xfe003590e960 sleepq_add() at 0x809521ab = sleepq_add+0x37b/frame 0xfe003590e9b0 _sleep() at 0x80902118 = _sleep+0x238/frame 0xfe003590ea40 usbhid_sync_xfer() at 0x8532e071 = usbhid_sync_xfer+0x171/frame 0xfe003590eaa0 usbhid_set_report() at 0x8532db26 = usbhid_set_report+0x96/frame 0xfe003590eae0 hid_set_report() at 0x80686caa = hid_set_report+0x6a/frame 0xfe003590eb20 hidbus_write() at 0x85335a7c = hidbus_write+0x5c/frame 0xfe003590eb50 hid_write() at 0x80686b98 = hid_write+0x58/frame 0xfe003590eb80 hkbd_set_leds() at 0x85c1cfe6 = hkbd_set_leds+0x206/frame 0xfe003590ebc0 hkbd_ioctl_locked() at 0x85c1cd6b = hkbd_ioctl_locked+0x33b/frame 0xfe003590ec20 hkbd_ioctl_locked() at 0x85c1caff = hkbd_ioctl_locked+0xcf/frame 0xfe003590ec80 hkbd_ioctl() at 0x85c1ba5a = hkbd_ioctl+0xba/frame 0xfe003590ecc0 kbdmux_ioctl() at 0x80695d3b = kbdmux_ioctl+0x12b/frame 0xfe003590ed00 vt_window_switch() at 0x8079d969 = vt_window_switch+0x229/frame 0xfe003590ed40 vt_switch_timer() at 0x807a15a1 = vt_switch_timer+0x21/frame 0xfe003590ed60 Can you test this patch: https://reviews.freebsd.org/D36715 --HPS
Re: Did clang 14 lose some intrinsics support?
On Mon, Sep 26, 2022, 7:54 AM Lev Serebryakov wrote: > On 26.09.2022 13:03, Dimitry Andric wrote: > > > Sure, but if you are compiling without -mavx, why would you want the AVX > > intrinsics? You cannot use AVX intrinsics anyway, if AVX is not enabled. >Because autovectorization (generation of SSE or AVX instructions by > compiler itself, without intrinsics) can pessimize code. > >Sometimes it is valuable to know exactly where AVX is used. I don't > have examples on hands, but I've seen situations, when autovectorized code > was much slower than scalar code. > The detection method that dim@ outline will work just fine for the autodetect script. It just replaces the internal, charging undocumented names for standard ones. How you later compile individual bits of code is orthogonal. Warner >
Re: RES: TP-LINK USB no carrier after speed test
Hi Ivan,
Can you revert all if_ure patches, and try this one instead.
--HPSdiff --git a/sys/dev/usb/controller/xhci.c b/sys/dev/usb/controller/xhci.c
index 045be9a40b99..09aefb02687d 100644
--- a/sys/dev/usb/controller/xhci.c
+++ b/sys/dev/usb/controller/xhci.c
@@ -2848,8 +2848,16 @@ xhci_transfer_insert(struct usb_xfer *xfer)
/* check if already inserted */
if (xfer->flags_int.bandwidth_reclaimed) {
- DPRINTFN(8, "Already in schedule\n");
- return (0);
+ DPRINTFN(8, "Already in schedule (ringin doorbell only)\n");
+
+ /*
+ * Apparently there may be a race with multi
+ * buffering, that the hardware doesn't see the new
+ * chain bit value and stops the endpoint
+ * execution. Fix this by ringing the doorbell after
+ * each and every job that has been completed.
+ */
+ goto ring_doorbell;
}
pepext = xhci_get_endpoint_ext(xfer->xroot->udev,
@@ -2966,6 +2974,7 @@ xhci_transfer_insert(struct usb_xfer *xfer)
xfer->flags_int.bandwidth_reclaimed = 1;
+ring_doorbell:
xhci_endpoint_doorbell(xfer);
return (0);
Re: Did clang 14 lose some intrinsics support?
On 26.09.2022 13:03, Dimitry Andric wrote: Sure, but if you are compiling without -mavx, why would you want the AVX intrinsics? You cannot use AVX intrinsics anyway, if AVX is not enabled. Because autovectorization (generation of SSE or AVX instructions by compiler itself, without intrinsics) can pessimize code. Sometimes it is valuable to know exactly where AVX is used. I don't have examples on hands, but I've seen situations, when autovectorized code was much slower than scalar code. -- // Lev Serebryakov
Re: Did clang 14 lose some intrinsics support?
Quoting Dimitry Andric (from Mon, 26 Sep 2022 12:03:03 +0200): Sure, but if you are compiling without -mavx, why would you want the AVX intrinsics? You cannot use AVX intrinsics anyway, if AVX is not enabled. So I don't fully understand the problem this configure scripting is supposed to solve? Think about run time check of available CPU features and then using this code for performance critical sections only. Allows to generate programs which are generic to all CPUs in the main code paths, and able to switch to high performance implementations of critical code paths depending on the feature of the CPU. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpjLRXsPlQVc.pgp Description: Digitale PGP-Signatur
Re: Did clang 14 lose some intrinsics support?
On 25 Sep 2022, at 23:38, Christian Weisgerber wrote: > > Dimitry Andric: > >>> See https://github.com/llvm/llvm-project/commit/e5147f82e1cb >>> >>> - Instead of __builtin_ia32_pabsd128 maybe use _mm_abs_epi32 >>> - Instead of __builtin_ia32_pabsd256 maybe use _mm256_abs_epi32 >> >> I'm wondering why this rather fragile method is chosen? If you want to >> know whether SSE is supported, you check for __SSE__, and similarly >> __SSE2__, __AVX__ and a bunch of others. That is also portable to gcc. > > __AVX__, for instance, is not defined unless you compile with -mavx, > which also allows the compiler to issue AVX instructions during > normal code generation. Sure, but if you are compiling without -mavx, why would you want the AVX intrinsics? You cannot use AVX intrinsics anyway, if AVX is not enabled. So I don't fully understand the problem this configure scripting is supposed to solve? In my opinion, if you would want to know whether the compiler supports AVX in any mode, you would first attempt to run "$CC -mavx" and if that succeeds, run a test case which checks for the __AVX__ define. If both succeed, then AVX intrinsics work, otherwise they don't. Rinse and repeat for any other particular extension you would want to check. And should work for both clang and gcc. -Dimitry signature.asc Description: Message signed with OpenPGP
