Re: Bugs in xhci-hcd isochronous support
On Thu, 8 May 2014, Russel Hughes wrote: > Hi, > >Some more information from someone who has the same DAC as me and > has got it working on USB3.0 under Linux. I dont know if this helps > with a workround or just points to some fundamental problem with the > Intel hardware. > > "I was right in that MDAC works for me on USB3.0 (detected as NEC > uPD720200, Asus P8Z68 Deluxe motherboard), using xhci_hcd on a > more-or-less vanilla 3.12.3 kernel (yeah, I should upgrade soon): Have you also tried 3.12.3, to verify that the very same kernel gives different results on different hardware, and that the changes between 3.12 and 3.14 aren't responsible for the problem? > Code: > > # lsusb -t > ... > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M > |__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 12M > |__ Port 1: Dev 3, If 1, Class=audio, Driver=snd-usb-audio, 12M > |__ Port 1: Dev 3, If 2, Class=audio, Driver=snd-usb-audio, 12M > ... > > Manually watching /proc/interrupts confirms that it's not going > through ehci_hcd. > > I can even play 24/96k without any problems (unlike unpatched ehci_hcd). > > Therfore your issue is either not xhci_hcd related, or is > hardware-specific. Make sure to mention your USB3 xhci controller in > that lkml thread." This does seem to point to an incompatibility between the driver and the Intel xHCI hardware. Figuring out what that incompability is may not be easy, though... Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bugs in xhci-hcd isochronous support
> Does your computer have any USB-2 ports? Or is it possible to disable > the USB-3 controllers in the BIOS? It would be worthwhile to see if > the audio works when the device is attached to a non-USB-3 controller. > Hi, Some more information from someone who has the same DAC as me and has got it working on USB3.0 under Linux. I dont know if this helps with a workround or just points to some fundamental problem with the Intel hardware. "I was right in that MDAC works for me on USB3.0 (detected as NEC uPD720200, Asus P8Z68 Deluxe motherboard), using xhci_hcd on a more-or-less vanilla 3.12.3 kernel (yeah, I should upgrade soon): Code: # lsusb -t ... /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M |__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 12M |__ Port 1: Dev 3, If 1, Class=audio, Driver=snd-usb-audio, 12M |__ Port 1: Dev 3, If 2, Class=audio, Driver=snd-usb-audio, 12M ... Manually watching /proc/interrupts confirms that it's not going through ehci_hcd. I can even play 24/96k without any problems (unlike unpatched ehci_hcd). Therfore your issue is either not xhci_hcd related, or is hardware-specific. Make sure to mention your USB3 xhci controller in that lkml thread." My output is: lsusb -t /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M |__ Port 3: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 2, If 1, Class=Audio, Driver=snd-usb-audio, 12M |__ Port 3: Dev 2, If 2, Class=Audio, Driver=snd-usb-audio, 12M |__ Port 4: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 4: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bugs in xhci-hcd isochronous support
> > I got it. There doesn't seem to be anything wrong with the data in the > file. This means whatever the problem is, there's a good chance we > can't find it through software. > > Does your computer have any USB-2 ports? Or is it possible to disable > the USB-3 controllers in the BIOS? It would be worthwhile to see if > the audio works when the device is attached to a non-USB-3 controller. > > Alan Stern Particular Attention ***Intel*** people The audio device does work correctly on USB2.0 ports on another computer. The NUC does have USB 2.0 port headers on the PCB which I can try but as Intel have neglected to document anywhere on what the connections are it will take a bit of time to figure them out, they also look non standard header spacing at 2mm instead of 2.54mm, 0.1", so I need to source 2mm header connectors. Its not possible to disable USB 3.0 controllers in Bios, I would be happy if Intel could provide that as a workround. I have posted this previously, https://forums.presonus.com/posts/list/33427.page , where people are complaining about USB 3.0 Isochronous audio and rightly or wrongly are blaming Intel. From Intels perspective they might not care about the hi-fi market, its not that big, but the pro audio market is significant. I will try the onboard USB ports at some point and report the results back but it seems a bit of a backward step if I have to drill a hole in the box to get the USB audio running correctly. I am happy if someone from Intel want to contact me to try non Unix workarounds like different Bios software. BR Russel > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bugs in xhci-hcd isochronous support
On Mon, 5 May 2014, Russel Hughes wrote: > > > > Can you put the entire file some place where I can download it? > > > Hi, > > You should have a link now to the file. I got it. There doesn't seem to be anything wrong with the data in the file. This means whatever the problem is, there's a good chance we can't find it through software. Does your computer have any USB-2 ports? Or is it possible to disable the USB-3 controllers in the BIOS? It would be worthwhile to see if the audio works when the device is attached to a non-USB-3 controller. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bugs in xhci-hcd isochronous support
On Sun, 4 May 2014, Russel Hughes wrote: > > The audio data is contained in the lines that have a 'Z'. Just search > > for the first such line and then go back twenty or so lines before that > > to provide some context. > > > > Alan Stern > > This OK? Yep, that's what I wanted. However, this snippet doesn't show any sign of problems. Can you put the entire file some place where I can download it? If you want to look through it yourself, here some some of the things to check for: Look at the lines containing "C Zo:2:002:1". In the part you posted, they are 8801fe291c00 2991536017 C Zo:2:002:1 0:1:1406:0 6 0:0:264 8801fe291000 2991542017 C Zo:2:002:1 0:1:1412:0 6 0:0:264 8801fe290c00 2991548012 C Zo:2:002:1 0:1:1418:0 6 0:0:264 8801fe291c00 2991554012 C Zo:2:002:1 0:1:1424:0 6 0:0:264 8801fe291000 2991560016 C Zo:2:002:1 0:1:1430:0 6 0:0:264 8801fe290c00 2991566013 C Zo:2:002:1 0:1:1436:0 6 0:0:264 8801fe291c00 2991572016 C Zo:2:002:1 0:1:1442:0 6 0:0:264 || | ---AB---C In each line, the B value plus the C value should be equal to B in the next line. Also, the A value plus C * 1000 should be close to A in the next line. (The same is true for the lines containing "C Zi:2:002:1", although in those lines the C value will always be 1.) Your email wrapped the "C Zo:2:002:1" lines because they are longer than 80 columns. But if you look at the original file, they appear like this: 8801fe291c00 2991536017 C Zo:2:002:1 0:1:1406:0 6 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1584 > | | | | | | --D--E1--E2E3E4E5 The D value and all the E's should all be 0. In particular, a -18 value for any of the E's is a big red flag. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bugs in xhci-hcd isochronous support
> The audio data is contained in the lines that have a 'Z'. Just search
> for the first such line and then go back twenty or so lines before that
> to provide some context.
>
> Alan Stern
This OK?
BR
Russel
fff880211c1e000 2991052997 S Ii:2:002:3 -115:32 2 <
880036d09480 2991060964 C Ii:2:003:2 0:8 7 = 02f0 ff
880036d09480 2991060996 S Ii:2:003:2 -115:8 20 <
880211c1e000 2991084868 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991084875 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991116869 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991116886 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991148920 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991148934 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991180881 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991180891 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991212916 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991212930 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991244869 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991244882 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991276888 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991276896 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991308916 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991308929 S Ii:2:002:3 -115:32 2 <
880036d09480 2991333025 C Ii:2:003:2 0:8 7 = 0201 00
880036d09480 2991333061 S Ii:2:003:2 -115:8 20 <
880211c1e000 2991340916 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991340929 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991372916 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991372929 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991404885 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991404894 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991436915 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991436928 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991468853 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991468862 S Ii:2:002:3 -115:32 2 <
880211c1e000 2991500915 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991500929 S Ii:2:002:3 -115:32 2 <
880036d09480 2991524964 C Ii:2:003:2 0:8 7 = 0200 00
880036d09480 2991524999 S Ii:2:003:2 -115:8 20 <
8800c5551300 2991527066 S Co:2:002:0 s 01 0b 0001 0002 0
8800c5551300 2991527480 C Co:2:002:0 0 0
8800c5551540 2991527571 S Co:2:002:0 s 22 01 0100 0001 0003 3 = 44ac00
8800c5551540 2991527939 C Co:2:002:0 0 3 >
8800c5551540 2991527947 S Ci:2:002:0 s a2 81 0100 0001 0003 3 <
8800c5551540 2991530030 C Ci:2:002:0 -32 0
8801fe291c00 2991530052 S Zo:2:002:1 -115:1:0 6 -18:0:264
-18:264:264 -18:528:264 -18:792:264 -18:1056:264 1584 =
8801fe291000 2991530059 S Zo:2:002:1 -115:1:0 6 -18:0:264
-18:264:264 -18:528:264 -18:792:270 -18:1062:264 1590 =
8801fe290c00 2991530061 S Zo:2:002:1 -115:1:0 6 -18:0:264
-18:264:264 -18:528:264 -18:792:264 -18:1056:264 1584 =
880211833700 2991530062 S Zi:2:002:1 -115:32:0 1 -18:0:3 4 <
88020360b000 2991530065 S Zi:2:002:1 -115:32:0 1 -18:0:3 4 <
88020360be00 2991530066 S Zi:2:002:1 -115:32:0 1 -18:0:3 4 <
8802010e4f00 2991530067 S Zi:2:002:1 -115:32:0 1 -18:0:3 4 <
8800c5551540 2991530074 S Co:2:002:0 s 22 01 0100 0001 0003 3 = 44ac00
8800c5551540 2991530618 C Co:2:002:0 0 3 >
8800c5551540 2991530626 S Ci:2:002:0 s a2 81 0100 0001 0003 3 <
880211833700 2991531065 C Zi:2:002:1 0:1:1406:0 1 0:0:3 4 = 00030b00
880211833700 2991531069 S Zi:2:002:1 -115:1:1406 1 -18:0:3 4 <
88020360b000 2991532030 C Zi:2:002:1 0:1:1407:0 1 0:0:3 4 = 00030b00
88020360b000 2991532033 S Zi:2:002:1 -115:1:1407 1 -18:0:3 4 <
8800c5551540 2991532523 C Ci:2:002:0 -32 0
88020360be00 2991533035 C Zi:2:002:1 0:1:1408:0 1 0:0:3 4 = 00030b00
88020360be00 2991533040 S Zi:2:002:1 -115:1:1408 1 -18:0:3 4 <
880211c1e000 2991533045 C Ii:2:002:3 0:32 2 = 8002
880211c1e000 2991533047 S Ii:2:002:3 -115:32 2 <
8802010e4f00 2991534022 C Zi:2:002:1 0:1:1409:0 1 0:0:3 4 = 00030b00
8802010e4f00 2991534026 S Zi:2:002:1 -115:1:1409 1 -18:0:3 4 <
880211833700 2991535024 C Zi:2:002:1 0:1:1410:0 1 0:0:3 4 = 00030b00
880211833700 2991535029 S Zi:2:002:1 -115:1:1410 1 -18:0:3 4 <
8801fe291c00 2991536017 C Zo:2:002:1 0:1:1406:0 6 0:0:264
0:264:264 0:528:264 0:792:264 0:1056:264 1584 >
8801fe291c00 2991536026 S Zo:2:002:1 -115:1:1406 6 -18:0:264
-18:264:264 -18:528:264 -18:792:264 -18:1056:270 1590 = 8dedd084
ecd387b1 d29165cf 7058daa1 2cca618d dfb1d6c4 6cc3dbbb 5bc17a4a
88020360b000 2991536031 C Zi:2:002:1 0:1:1411:0 1 0:0:3 4 = 00030b00
88020360b000 2991536032 S Zi:2:002:1 -115:1:1411 1 -18:0:3 4 <
88020360be00 2991537025 C Zi:2:002:1 0:1:1412:0 1 0:0:3 4 = 00030b00
88020360be00 2991537029 S Zi:2:002:1 -115:1:1412 1 -18:0:3 4 <
8802010e4f00 2991538033 C Zi:2:002:1 0:1:1413:0 1 0:0:3 4
Re: Bugs in xhci-hcd isochronous support
On Sun, 4 May 2014, Russel Hughes wrote: > > It looks like you started the usbmon trace after the audio data > > transfer was running. I need to see what happens when the audio data > > transfer begins. > > > > Also, is there any way you can turn off the audio-in channel while > > running the test, so that only the audio-out is active? > > > > Alan Stern > The NUC does not have anything connected to the audio input but for > this test the input volume is muted, I do not know how to disable it, > I will have a look. Here is the data, its a few thousand lines long as > I was not sure when the audio data started. I can send the full file > if you wish, its 4.7Mbyte The audio data is contained in the lines that have a 'Z'. Just search for the first such line and then go back twenty or so lines before that to provide some context. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bugs in xhci-hcd isochronous support
On Sat, 3 May 2014, Russel Hughes wrote: > sudo cat /sys/kernel/debug/usb/usbmon/2u > /tmp/1.mon.out > > first few hundred lines > > 880200adef00 2596394321 C Zi:2:004:1 0:1:1833:0 1 0:0:3 4 = 00030b00 > 880200adef00 2596394330 S Zi:2:004:1 -115:1:1833 1 -18:0:3 4 < > 8801f3c8e600 2596395313 C Zo:2:004:1 0:1:1830:0 5 0:0:264 It looks like you started the usbmon trace after the audio data transfer was running. I need to see what happens when the audio data transfer begins. Also, is there any way you can turn off the audio-in channel while running the test, so that only the audio-out is active? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bugs in xhci-hcd isochronous support
> The patch was made against 3.15-rc2, which is no longer the latest > kernel version. > > However, the nature of those error messages suggests that the patch > file you tried to apply was messed up somehow, probably by your email > client. You can get the unmodified original here: > > http://marc.info/?l=linux-usb&m=139906101630351&q=raw > > Alan Stern > Hi, Thanks, yes I don't know what is going on in gmail, plain text is selected and indicated, it has worked but now no longer seems to. No noticeable difference in buffer level performance visually, still all over the place compared to USB2.0, audio everyone is asleep so I cannot really test but I think it still drops out, will say tomorrow. HDMI audio still works, which it didn't last time I swapped kernels, so some good news! Patch went as follows. Hunk #1 succeeded at 3148 (offset -5 lines). Hunk #2 succeeded at 3159 (offset -5 lines). Hunk #3 succeeded at 3402 (offset -5 lines). Hunk #4 succeeded at 3541 (offset -5 lines). Hunk #5 succeeded at 3658 (offset -5 lines). Hunk #6 succeeded at 3738 (offset -5 lines). Hunk #7 succeeded at 3754 (offset -5 lines). Hunk #8 succeeded at 3766 (offset -5 lines). Hunk #9 succeeded at 3829 (offset -5 lines). Hunk #10 succeeded at 3894 (offset -5 lines). Hunk #11 succeeded at 3978 (offset -5 lines). Hunk #12 succeeded at 4000 (offset -5 lines). Hunk #13 succeeded at 4015 (offset -5 lines). patching file drivers/usb/host/xhci.h Hunk #2 succeeded at 887 (offset -2 lines). Hunk #3 succeeded at 1169 (offset -2 lines). built the kernel and placed it in, I can rebuild it with rc2 as I forgot you had used rc2 if you wish uname -r 3.15.0-rc3 T: Bus=02 Lev=01 Prnt=01 Port=02 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0451 ProdID=adac Rev= a.09 S: Manufacturer=Lakewest Audio S: Product=Audiolab M-DAC C:* #Ifs= 3 Cfg#= 1 Atr=c0 MxPwr= 0mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid E: Ad=82(I) Atr=03(Int.) MxPS= 64 Ivl=1ms E: Ad=02(O) Atr=03(Int.) MxPS= 64 Ivl=1ms I:* If#= 1 Alt= 0 #EPs= 1 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio E: Ad=83(I) Atr=03(Int.) MxPS= 2 Ivl=32ms I: If#= 2 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio I:* If#= 2 Alt= 1 #EPs= 2 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio E: Ad=01(O) Atr=05(Isoc) MxPS= 582 Ivl=1ms E: Ad=81(I) Atr=11(Isoc) MxPS= 3 Ivl=1ms sudo cat /sys/kernel/debug/usb/usbmon/2u > /tmp/1.mon.out first few hundred lines 880200adef00 2596394321 C Zi:2:004:1 0:1:1833:0 1 0:0:3 4 = 00030b00 880200adef00 2596394330 S Zi:2:004:1 -115:1:1833 1 -18:0:3 4 < 8801f3c8e600 2596395313 C Zo:2:004:1 0:1:1830:0 5 0:0:264 0:264:264 0:528:264 0:792:270 0:1062:264 1326 > 8801f3c8e600 2596395324 S Zo:2:004:1 -115:1:1830 5 -18:0:264 -18:264:264 -18:528:264 -18:792:264 -18:1056:264 1320 = 023dff06 fffdfdc4 0003bafe fdbf0003 c0fe00ad ff06eefd 0496fe07 57fd0843 8800d14aba00 2596395327 C Zi:2:004:1 0:1:1834:0 1 0:0:3 4 = 00030b00 8800d14aba00 2596395328 S Zi:2:004:1 -115:1:1834 1 -18:0:3 4 < 8800d058e700 2596396343 C Zi:2:004:1 0:1:1835:0 1 0:0:3 4 = 00030b00 8800d058e700 2596396346 S Zi:2:004:1 -115:1:1835 1 -18:0:3 4 < 8801f3564300 2596397329 C Zi:2:004:1 0:1:1836:0 1 0:0:3 4 = 00030b00 8801f3564300 2596397341 S Zi:2:004:1 -115:1:1836 1 -18:0:3 4 < 880200adef00 2596398321 C Zi:2:004:1 0:1:1837:0 1 0:0:3 4 = 00030b00 880200adef00 2596398323 S Zi:2:004:1 -115:1:1837 1 -18:0:3 4 < 8800d14aba00 2596399319 C Zi:2:004:1 0:1:1838:0 1 0:0:3 4 = 00030b00 8800d14aba00 2596399323 S Zi:2:004:1 -115:1:1838 1 -18:0:3 4 < 8800d058e700 2596400323 C Zi:2:004:1 0:1:1839:0 1 0:0:3 4 = 00030b00 8800d058e700 2596400327 S Zi:2:004:1 -115:1:1839 1 -18:0:3 4 < 8801f3c8fa00 2596401328 C Zo:2:004:1 0:1:1835:0 6 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1584 > 8801f3c8fa00 2596401335 S Zo:2:004:1 -115:1:1835 5 -18:0:264 -18:264:264 -18:528:264 -18:792:270 -18:1062:264 1326 = f7e502f3 4f04f89a 02f89e02 fe7e0001 56fffc0f 0100e3ff f30604f1 b204f1b2 8801f3564300 2596401338 C Zi:2:004:1 0:1:1840:0 1 0:0:3 4 = 00030b00 8801f3564300 2596401338 S Zi:2:004:1 -115:1:1840 1 -18:0:3 4 < 880200adef00 2596402340 C Zi:2:004:1 0:1:1841:0 1 0:0:3 4 = 00030b00 880200adef00 2596402342 S Zi:2:004:1 -115:1:1841 1 -18:0:3 4 < 8800d14aba00 2596403345 C Zi:2:004:1 0:1:1842:0 1 0:0:3 4 = 00030b00 8800d14aba00 2596403350 S Zi:2:004:1 -115:1:1842 1 -18:0:3 4 < 8800d058e700 2596404352 C Zi:2:004:1 0:1:1843:0 1 0:0:3 4 = 00030b00 8800d058e700 2596404356 S Zi:2:004:1 -115:1:1843 1 -18:0:3 4 < 8801f3564300 2596405351 C Zi:2:004:1 0:1:1844:0 1 0:0:3 4 = 00030b00 8801f3564300 2596405355 S Zi:2:004:1 -115:1:1844 1 -18:0:3 4 < 8801f3c8f000 2596406339 C Zo:2:004:1 0:1:1841:0 5 0:0:264 0:264:264 0:528:264 0:792:264 0:1056:264 1320 > 8801f3c8f000 2596406347 S Zo:2:004:1 -115:1:1841 5 -18
Re: Bugs in xhci-hcd isochronous support
On Sat, 3 May 2014, Russel Hughes wrote: > Hi, > > We tried downloading the latest kernel 3.15 and got this when > applying the patch > > File to patch: ^C > :~/linux kernel/usb-3.15.orig$ patch -p1 < patch.dif > patching file drivers/usb/host/xhci-ring.c > Hunk #1 FAILED at 3153. > Hunk #2 FAILED at 3164. > Hunk #3 FAILED at 3406. > Hunk #4 FAILED at 3545. > Hunk #5 FAILED at 3662. > Hunk #6 FAILED at 3742. > Hunk #7 FAILED at 3756. > Hunk #8 FAILED at 3765. > Hunk #9 FAILED at 3826. > Hunk #10 FAILED at 3895. > Hunk #11 FAILED at 3935. > Hunk #12 FAILED at 3958. > Hunk #13 FAILED at 3982. > 13 out of 13 hunks FAILED -- saving rejects to file > drivers/usb/host/xhci-ring.c.rej > patching file drivers/usb/host/xhci.h > Reversed (or previously applied) patch detected! Assume -R? [n] > > I was told that the lines in the source file were not in the place > that they were expected, are we using the right kernel? Thanks in > advance! The patch was made against 3.15-rc2, which is no longer the latest kernel version. However, the nature of those error messages suggests that the patch file you tried to apply was messed up somehow, probably by your email client. You can get the unmodified original here: http://marc.info/?l=linux-usb&m=139906101630351&q=raw Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bugs in xhci-hcd isochronous support
> > Russel, here's a patch you can test. It's only a partial fix for the > problem, because it doesn't handle over/underruns. Still, it would be > nice to see if the patch makes any difference in normal operation. > > Even if it doesn't fix the problem, please post a short stretch (a few > hundred lines) from a usbmon trace with the patch installed. > > Alan Stern > Hi, We tried downloading the latest kernel 3.15 and got this when applying the patch File to patch: ^C :~/linux kernel/usb-3.15.orig$ patch -p1 < patch.dif patching file drivers/usb/host/xhci-ring.c Hunk #1 FAILED at 3153. Hunk #2 FAILED at 3164. Hunk #3 FAILED at 3406. Hunk #4 FAILED at 3545. Hunk #5 FAILED at 3662. Hunk #6 FAILED at 3742. Hunk #7 FAILED at 3756. Hunk #8 FAILED at 3765. Hunk #9 FAILED at 3826. Hunk #10 FAILED at 3895. Hunk #11 FAILED at 3935. Hunk #12 FAILED at 3958. Hunk #13 FAILED at 3982. 13 out of 13 hunks FAILED -- saving rejects to file drivers/usb/host/xhci-ring.c.rej patching file drivers/usb/host/xhci.h Reversed (or previously applied) patch detected! Assume -R? [n] I was told that the lines in the source file were not in the place that they were expected, are we using the right kernel? Thanks in advance! BR Russel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bugs in xhci-hcd isochronous support
On Tue, 22 Apr 2014, Russel Hughes wrote:
> > More importantly, the routine sets urb->start_frame to the current
> > value of the frame counter. This is completely wrong; urb->start_frame
> > is supposed to be the (micro-)frame number for when the transfer
> > begins, not when the transfer was submitted.
> >
> > As far as I can tell, the only way to do this correctly is to set the
> > Frame ID field (with SIA = 0) in the first TD of an isochronous stream,
> > and then set SIA = 1 in all the following TDs (see 4.11.2.5). That
> > way, xhci-hcd will know exactly when the stream begins, so it can keep
> > track of the frame in which each URB starts. Dealing with underruns is
> > left as an exercise for the implementer...
> >
>
> Let me know if you want any changes tested using my DAC that reliably
> shows the problem.
Russel, here's a patch you can test. It's only a partial fix for the
problem, because it doesn't handle over/underruns. Still, it would be
nice to see if the patch makes any difference in normal operation.
Even if it doesn't fix the problem, please post a short stretch (a few
hundred lines) from a usbmon trace with the patch installed.
Alan Stern
Index: usb-3.15/drivers/usb/host/xhci-ring.c
===
--- usb-3.15.orig/drivers/usb/host/xhci-ring.c
+++ usb-3.15/drivers/usb/host/xhci-ring.c
@@ -3153,7 +3153,7 @@ static void check_trb_math(struct urb *u
static void giveback_first_trb(struct xhci_hcd *xhci, int slot_id,
unsigned int ep_index, unsigned int stream_id, int start_cycle,
- struct xhci_generic_trb *start_trb)
+ struct xhci_generic_trb *start_trb, bool ring_doorbell)
{
/*
* Pass all the TRBs to the hardware at once and make sure this write
@@ -3164,7 +3164,8 @@ static void giveback_first_trb(struct xh
start_trb->field[3] |= cpu_to_le32(start_cycle);
else
start_trb->field[3] &= cpu_to_le32(~TRB_CYCLE);
- xhci_ring_ep_doorbell(xhci, slot_id, ep_index, stream_id);
+ if (ring_doorbell)
+ xhci_ring_ep_doorbell(xhci, slot_id, ep_index, stream_id);
}
/*
@@ -3406,7 +3407,7 @@ static int queue_bulk_sg_tx(struct xhci_
check_trb_math(urb, num_trbs, running_total);
giveback_first_trb(xhci, slot_id, ep_index, urb->stream_id,
- start_cycle, start_trb);
+ start_cycle, start_trb, true);
return 0;
}
@@ -3545,7 +3546,7 @@ int xhci_queue_bulk_tx(struct xhci_hcd *
check_trb_math(urb, num_trbs, running_total);
giveback_first_trb(xhci, slot_id, ep_index, urb->stream_id,
- start_cycle, start_trb);
+ start_cycle, start_trb, true);
return 0;
}
@@ -3662,7 +3663,7 @@ int xhci_queue_ctrl_tx(struct xhci_hcd *
field | TRB_IOC | TRB_TYPE(TRB_STATUS) |
ep_ring->cycle_state);
giveback_first_trb(xhci, slot_id, ep_index, 0,
- start_cycle, start_trb);
+ start_cycle, start_trb, true);
return 0;
}
@@ -3742,8 +3743,10 @@ static unsigned int xhci_get_last_burst_
/* This is for isoc transfer */
static int xhci_queue_isoc_tx(struct xhci_hcd *xhci, gfp_t mem_flags,
- struct urb *urb, int slot_id, unsigned int ep_index)
+ struct urb *urb, int slot_id, unsigned int ep_index,
+ unsigned esit)
{
+ struct xhci_virt_ep *ep;
struct xhci_ring *ep_ring;
struct urb_priv *urb_priv;
struct xhci_td *td;
@@ -3756,8 +3759,11 @@ static int xhci_queue_isoc_tx(struct xhc
u64 start_addr, addr;
int i, j;
bool more_trbs_coming;
+ bool new_isoc_stream;
+ unsigned start_uframe;
- ep_ring = xhci->devs[slot_id]->eps[ep_index].ring;
+ ep = &xhci->devs[slot_id]->eps[ep_index];
+ ep_ring = ep->ring;
num_tds = urb->number_of_packets;
if (num_tds < 1) {
@@ -3765,6 +3771,8 @@ static int xhci_queue_isoc_tx(struct xhc
return -EINVAL;
}
+ new_isoc_stream = list_empty(&urb->ep->urb_list);
+
start_addr = (u64) urb->transfer_dma;
start_trb = &ep_ring->enqueue->generic;
start_cycle = ep_ring->cycle_state;
@@ -3826,10 +3834,6 @@ static int xhci_queue_isoc_tx(struct xhc
field |= ep_ring->cycle_state;
}
- /* Only set interrupt on short packet for IN EPs */
- if (usb_urb_dir_in(urb))
- field |= TRB_ISP;
-
/* Chain all the TRBs together; clear the chain bit in
* the last TRB to indicate it's the last TRB in the
* chain.
@@ -3895,8 +3899,52 @@ static int xhci_queue_isoc_tx(struct xhc
}
xhci_to_hcd(xhci)->self.bandwidth
Re: Bugs in xhci-hcd isochronous support
On 04/21/2014 11:49 PM, Alan Stern wrote: Mathias: I noticed a couple of things wrong in xhci_queue_isoc_tx_prepare(). One of them isn't too serious: The code checks in several places whether the device is running at low speed. This is useless, because USB does not support isochronous transfers at low speed. More importantly, the routine sets urb->start_frame to the current value of the frame counter. This is completely wrong; urb->start_frame is supposed to be the (micro-)frame number for when the transfer begins, not when the transfer was submitted. As far as I can tell, the only way to do this correctly is to set the Frame ID field (with SIA = 0) in the first TD of an isochronous stream, and then set SIA = 1 in all the following TDs (see 4.11.2.5). That way, xhci-hcd will know exactly when the stream begins, so it can keep track of the frame in which each URB starts. Dealing with underruns is left as an exercise for the implementer... Alan Stern Ok, thanks for the info, so this is probably why the usbmon ouput had weird frame numbers in the isochronous audio case. I'll add it to my TODO list. (or if anyone else want's to take a shot at it feel free) -Mathias -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bugs in xhci-hcd isochronous support
> More importantly, the routine sets urb->start_frame to the current > value of the frame counter. This is completely wrong; urb->start_frame > is supposed to be the (micro-)frame number for when the transfer > begins, not when the transfer was submitted. > > As far as I can tell, the only way to do this correctly is to set the > Frame ID field (with SIA = 0) in the first TD of an isochronous stream, > and then set SIA = 1 in all the following TDs (see 4.11.2.5). That > way, xhci-hcd will know exactly when the stream begins, so it can keep > track of the frame in which each URB starts. Dealing with underruns is > left as an exercise for the implementer... > Let me know if you want any changes tested using my DAC that reliably shows the problem. BR Russel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bugs in xhci-hcd isochronous support
Mathias: I noticed a couple of things wrong in xhci_queue_isoc_tx_prepare(). One of them isn't too serious: The code checks in several places whether the device is running at low speed. This is useless, because USB does not support isochronous transfers at low speed. More importantly, the routine sets urb->start_frame to the current value of the frame counter. This is completely wrong; urb->start_frame is supposed to be the (micro-)frame number for when the transfer begins, not when the transfer was submitted. As far as I can tell, the only way to do this correctly is to set the Frame ID field (with SIA = 0) in the first TD of an isochronous stream, and then set SIA = 1 in all the following TDs (see 4.11.2.5). That way, xhci-hcd will know exactly when the stream begins, so it can keep track of the frame in which each URB starts. Dealing with underruns is left as an exercise for the implementer... Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
