Call for beta testers: FIQ_FSM USB driver rewrite

FLYFISH TECHNOLOGIES · Tue Apr 22, 2014 4:13 pm

Hi,

jdb wrote:Found the cause of this: Interrupt OUT packets were always sent with a DATA0 PID, instead of alternating DATA0/DATA1. The odd thing is that the PIC's USB engine always responds with ACK, i.e. accepted the packet, despite the evidence being that it discards it if it's wrong.

Isn't this behavior proper & expected ? It covers cases when ACK response got corrupted, causing the host to send a retry (having un-altered DATA0/DATA1 flag). A device then suppose to ignore the content and just respond with ACK.

jdb wrote:Patch inbound should fix this

Good news, thanks.

Best wishes, Ivan Zilic.

GrayShade · Tue Apr 22, 2014 5:05 pm

jdb wrote:Patch inbound should fix this and the Concept rowing machine monitor, which uses the same transport.

I can't boot this version either (Arch, no external devices connected). This seems to have been caused by the 3.12 kernel merge. As someone else had the same problem on Arch, I'll try with Raspbian to see if there's any difference.

I think the kernel ignores unknown command-line arguments, but this might still be caused by something in my cmdline.txt or config.txt.

EDIT: Okay, it seems that Arch's CMA settings no longer work. As it seems that CMA isn't really supported, Arch users should probably remove them from config.txt before installing this version.

ioudas · Tue Apr 22, 2014 5:32 pm

Trying to launch this just gives me a syntax error on line 2 of rpi update

syntax error near unexpeected token newline.

GrayShade · Tue Apr 22, 2014 5:35 pm

ioudas wrote:Trying to launch this just gives me a syntax error on line 2 of rpi update

syntax error near unexpeected token newline.

That's because rpi-update auto-updated itself to an error page:

Code: Select all

Error 503 backend read error

backend read error

Guru Meditation:

XID: 85362404
-------------------------------------------------------------------------------
Varnish cache server

You can manually download rpi-update from https://raw.github.com/Hexxeh/rpi-updat ... rpi-update, but downloading the firmware will result in the same error.

Tue Apr 22, 2014 6:03 pm

FLYFISH TECHNOLOGIES wrote:Hi,

Isn't this behavior proper & expected ? It covers cases when ACK response got corrupted, causing the host to send a retry (having un-altered DATA0/DATA1 flag). A device then suppose to ignore the content and just respond with ACK.

Best wishes, Ivan Zilic.

Yes, you're right - the device should issue an ACK and ignore the DATA0, in doing so assuming it was a smashed dev->host ACK. Problem was that DATA0 contained the next set of valid data and the host driver was unaware that anything was wrong.

There also appears to be a bug in my USB analyzer's software when looking at this sequence - it only picks up data toggle errors by apparently keeping internal state and not following what the transaction does. Fun to know.

Edit: BRANCH=next firmware is updated with the fix for this issue.

ioudas · Tue Apr 22, 2014 6:05 pm

GrayShade wrote:
ioudas wrote:Trying to launch this just gives me a syntax error on line 2 of rpi update

syntax error near unexpeected token newline.
That's because rpi-update auto-updated itself to an error page:
Code: Select all
Error 503 backend read error

backend read error

Guru Meditation:

XID: 85362404
-------------------------------------------------------------------------------
Varnish cache server
You can manually download rpi-update from https://raw.github.com/Hexxeh/rpi-updat ... rpi-update, but downloading the firmware will result in the same error.

Sounds like updating to this branch is not possible then....

Tue Apr 22, 2014 6:08 pm

GrayShade wrote:You can manually download rpi-update from https://raw.github.com/Hexxeh/rpi-updat ... rpi-update, but downloading the firmware will result in the same error.

I've just ran "sudo BRANCH=next rpi-update" successfully, so I don't think it is broken for everyone. May be a temporary github issue.
Anyone else succeeding or failing to update?

Tue Apr 22, 2014 6:11 pm

It appears Github is having a bad hair day:

<html><body><h1>502 Bad Gateway</h1>
The server returned an invalid or incomplete response.
</body></html>

redhawk · Tue Apr 22, 2014 6:28 pm

~~It's broken~~ working now.

Richard S.

GrayShade · Tue Apr 22, 2014 6:35 pm

It's working now

and I can confirm that Arch is booting if I remove the CMA options.

GrayShade · Tue Apr 22, 2014 7:02 pm

On the other hand, audio playback is now a mess (dropouts, probably) even with dwc_otg.fiq_fsm_mask=0x3, starting with 31a8f3f12cce94e3d35bb520bb8f6f2f9119c6d5 (April 17th).

redhawk · Tue Apr 22, 2014 7:33 pm

That's odd because my RTL2832U DVB-T dongle with rtl_fm radio playback has greatly improved with this update.

Richard S.

Tue Apr 22, 2014 7:53 pm

GrayShade wrote:On the other hand, audio playback is now a mess (dropouts, probably) even with dwc_otg.fiq_fsm_mask=0x3, starting with 31a8f3f12cce94e3d35bb520bb8f6f2f9119c6d5 (April 17th).

redhawk wrote:That's odd because my RTL2832U DVB-T dongle with rtl_fm radio playback has greatly improved with this update.

Richard S.

Marvellous. The changes between 31a8f3 and 5788f0 should have absolutely no bearing on either of these devices.

GrayShade · Tue Apr 22, 2014 7:54 pm

jdb wrote:Marvellous. The changes between 31a8f3 and 5788f0 should have absolutely no bearing on either of these devices.

No, 31a8f3 is the first broken one.

Chris_Reynolds · Wed Apr 23, 2014 11:53 am

jdb wrote:Patch inbound should fix this and the Concept rowing machine monitor, which uses the same transport.

Excellent news - I'll give it a try tonight - thanks for all the work that has gone into this.

ioudas · Wed Apr 23, 2014 5:27 pm

Still have repeating issues with a symbol scanner and keyboards.

Wed Apr 23, 2014 5:57 pm

Are you sure you're using the latest driver? can you just do

dmesg | grep fiq

Just to check that the fiq_fsm is properly enabled?

Thanks

Gordon

Wed Apr 23, 2014 6:09 pm

Addendum: FIQ should be capitalised

I.e.:

Code: Select all

[email protected]:~$ dmesg | grep FIQ
[    1.872499] WARN::dwc_otg_hcd_init:1040: FIQ DMA bounce buffers: virt = 0xdcc20000 dma = 0x5b9d0000 len=9024
[    1.884933] FIQ FSM acceleration enabled for :
[    1.901340] WARN::hcd_init:473: FIQ at 0xc0307258
[    1.907403] WARN::hcd_init:474: FIQ ASM at 0xc03074d4 length 36
[    2.001139] dwc_otg: FIQ enabled
[    2.001167] dwc_otg: FIQ split-transaction FSM enabled
[email protected]:~$

Note that you also need to have the following in /boot/cmdline.txt. By default, fiq_fsm is disabled unless explicitly enabled. The mask parameter is also necessary.

Code: Select all

dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x7

Chris_Reynolds · Wed Apr 23, 2014 6:44 pm

Chris_Reynolds wrote:
jdb wrote:Patch inbound should fix this and the Concept rowing machine monitor, which uses the same transport.
Excellent news - I'll give it a try tonight - thanks for all the work that has gone into this.

And it is looking superb! I have an idea for a Concept 2 rower/Minecraft bit of fun to test some ideas out. Thanks again.

GrayShade · Wed Apr 23, 2014 7:19 pm

I come with bad news. To restate my use case, I stream raw audio over the network and play it over USB.

For me, listed in chronological order:

e8d2ad3c20 works fine
af4ff92ff9 network stops working after a few minutes or so and doesn't come back again; nothing in dmesg (I wrote a script to log dmesg | tail, but it doesn't keep running) -- this was the 3.12.17 merge.
be210cc45f same as above
31a8f3f12c choppy audio, network ok (!)
5788f069c6 choppy audio, network ok (!)

I use smsc95xx.turbo_mode=N, so this shouldn't be related to the "kevent 2 may have been dropped" issue.

Wed Apr 23, 2014 7:41 pm

GrayShade wrote:I come with bad news. To restate my use case, I stream raw audio over the network and play it over USB.

For me, listed in chronological order:
e8d2ad3c20 works fine

af4ff92ff9 network stops working after a few minutes or so and doesn't come back again; nothing in dmesg (I wrote a script to log dmesg | tail, but it doesn't keep running) -- this was the 3.12.17 merge.

be210cc45f same as above

31a8f3f12c choppy audio, network ok (!)

5788f069c6 choppy audio, network ok (!)
I use smsc95xx.turbo_mode=N, so this shouldn't be related to the "kevent 2 may have been dropped" issue.

Thanks for the bisect.

"kevent 2 may have been dropped" is a result of the usbnet driver framework failing to allocate memory when requested by the smsc95xx driver. turbo_mode was an initiator for this behaviour because it increased pressure on kernel memory allocation: multiple packets could be transferred in each USB bulk transfer which would subsequently require separate processing.

Getting kevent 2 spam is orthogonal to dropped audio packets.

GrayShade · Wed Apr 23, 2014 7:57 pm

jdb wrote:Getting kevent 2 spam is orthogonal to dropped audio packets.

I know; I actually increased vm.min_free_kbytes enough so that I keep turbo_mode set. However, that problem causes the network to temporarily stop functioning, so I wanted to point out that I'm encountering a different issue. I don't have a display, so it's not always easy for me to distinguish between a freeze and a network driver that's no longer working.

I'm less worried about the audio dropouts than about the "hard" freezes I'm seeing. That they no longer seem to happen in the latter versions of the driver, but perhaps they just take longer to reproduce.

GrayShade · Fri Apr 25, 2014 5:09 pm

For the record, I still get dropouts in d02c615ea7. Network and other USB devices seem to work fine and the Pi doesn't crash as in the first versions after the 3.12 merge. If it helps, they are periodic (a few times a second) and not related to network activity. I've also unbound the HID endpoint of my DAC, so it shouldn't come into play. My stream is 16-bit at 44.1 kHz and vmstat doesn't report unusually high values:

Code: Select all

root ~ # vmstat 2
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0  52068   5028 389632    0    0   122     1  888  199  4  4 91  1  0
 1  0      0  51920   5036 389632    0    0     0     8  344   84 26  2 70  2  0
 0  0      0  50896   5036 389632    0    0     0     0  345   97 36  4 60  0  0
 0  0      0  50896   5036 389632    0    0     0     0  320   78  1  1 99  0  0
 0  0      0  50896   5044 389632    0    0     0    10  317   68  0  1 99  0  0
 0  0      0  50896   5044 389632    0    0     0     0  292   28  0  0 100  0  0
 0  0      0  50748   5044 389632    0    0     0     0 1770  112  1  2 97  0  0
 0  0      0  50748   5044 389632    0    0     0     0 2157  117  0  8 93  0  0
 0  0      0  50748   5044 389632    0    0     0     0 2162  126  0 14 86  0  0
 0  0      0  50748   5044 389632    0    0     0     0 2162  126  0 14 86  0  0
 1  0      0  50748   5044 389632    0    0     0     0 2154  117  0 11 89  0  0
 0  0      0  50748   5044 389632    0    0     0     0 2160  129  0 14 86  0  0
 0  0      0  50716   5044 389632    0    0     0     0 2163  132  0 15 85  0  0
 0  0      0  50748   5044 389632    0    0     0     0 2156  119  0 12 88  0  0
 0  0      0  50748   5044 389632    0    0     0     0 2159  126  0 11 89  0  0
 0  0      0  50748   5044 389632    0    0     0     0 2164  123  1  0 99  0  0
 0  0      0  50748   5044 389632    0    0     0    56 2224  160  0  3 97  0  0
 0  0      0  50748   5044 389632    0    0     0     0 2165  125  0  0 100  0  0
 0  0      0  50748   5044 389632    0    0     0     0 2164  116  0  0 100  0  0
 0  0      0  50748   5052 389632    0    0     0    10 2181  139  0  1 97  3  0
 0  0      0  50748   5052 389632    0    0     0     0 2165  117  1  0 99  0  0
 0  0      0  50748   5052 389632    0    0     0     0 2161  112  0  0 100  0  0
 0  0      0  50748   5052 389632    0    0     0     0 2177  134  0  0 100  0  0
 0  0      0  50748   5052 389632    0    0     0     0 2177  129  0  0 100  0  0
 0  0      0  50748   5052 389632    0    0     0     0 2161  118  0  0 100  0  0
 0  0      0  50716   5052 389632    0    0     0     0 2158  112  1  0 99  0  0
 0  0      0  50748   5052 389632    0    0     0     0 2162  117  0  1 99  0  0
 0  0      0  50772   5052 389632    0    0     0     0 1482  100  1  0 99  0  0
 0  0      0  50772   5052 389632    0    0     0     0  296   35  0  1 99  0  0
 0  0      0  50772   5052 389632    0    0     0     0  286   27  0  0 100  0  0
 0  0      0  50772   5052 389632    0    0     0     0  285   28  1  0 100  0  0

Fri Apr 25, 2014 5:22 pm

GrayShade wrote:For the record, I still get dropouts in d02c615ea7.

What is the output of vmstat 2 when the network drops?

Can you dump a copy of your sdcard image on a PC and post a link to dropbox?

I suggest running cat /dev/zero > zeros.bin && rm zeros.bin on the Pi, then shutting down, then reading off the card on a PC and compressing the resulting image.

GrayShade · Fri Apr 25, 2014 5:36 pm

jdb wrote:What is the output of vmstat 2 when the network drops?

Can you dump a copy of your sdcard image on a PC and post a link to dropbox?

Please see my updated post above. I can try to test with the standard Raspbian image, if you think it's something specific to my installation. However my sound problem only started a few driver versions ago (31a8f3f12c), so I doubt there would be any difference.

Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite

Re: Call for beta testers: FIQ_FSM USB driver rewrite