Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 14 replies
  • Subscribers 677 subscribers
  • Views 1663 views
  • Users 0 members are here
Related

USB data loss and ALSA problems

morgaine

The USB data loss on my Pi is worrying me so I'm starting a new thread for it.

 

I started reporting on this issue over in post #7 of this other thread which was about graphics -- http://www.element14.com/community/message/55209#55209 .  The graphics issue is fixed, but problems of USB data loss started appearing after I connected up the Pi to my NFS servers which are core infrastructure here, used by several machines over a mostly gigabit LAN.

 

Although I hadn't noticed any glitches in audio playback on the Pi yesterday while playing music from the NFS servers (and I still haven't), after stopping playback overnight, this morning I found the MOC player hung in kernel, non-interruptible, with one mocp process hung on a futex() call and the other hung in a recv() call.  The NFS servers were still accessible from other processes on the board (only the player was hung).


Given that Pi's networking is implemented over USB by the LAN9512, it's clear that USB errors could interact with networking on this board.

 

Although networking seemed to be working fine, I've since tested NFS robustness on Pi by pulling out the Ethernet cable during audio playback of an ogg file held on an NFS server, waiting for the player's buffering to drain and playback to freeze waiting for network data, then replugging the Ethernet --- all is fine, playback continues perfectly after reconnection from where it left off, despite Debian taking the interface down and back up.  Networking looks good and solid.

 

What's much worse is that the hung mocp wasn't hung on networking but on audio playback, as I discovered by killing it and starting a fresh player.  Restarting the ALSA system through "/etc/init.d/alsa-utils restart" didn't fix it either, although that may not have reloaded the snd_bcm2835 module --- I'll have to check and/or reload it manually if it hangs again.  So, that's another potential problem for future resolution, there might be hiccups in ALSA on Pi.

 

So, back to my main worry, which is loss of USB device events, mostly mouse clicks.  (I have noticed key presses going astray too, but I haven't quantified this yet, and it's not as frequent as lost mouse clicks).  As I mentioned in the other thread, this is happening regularly while networking is active.  My networking is all wired, fortunately, which eliminates one potential source of problems.

 

I've eliminated a few variables to try to understand the problem better:

 

  • The mouse and keyboard are fine (a Logitech Wireless Combo MK320) --- I moved them over to another Linux machine and they worked perfectly, no lost mouse clicks.  Admittedly, it was an Intel machine, and the problem could be at ARM driver level.
  • I borrowed a different RF mouse (Sandstrom Laser Mouse SMWLL11) which is working perfectly on my laptop and plugged it into the Pi --- same problem of lost mouse clicks as before.
  • Stopping the music playback and hence the Pi's NFS traffic doesn't make the problem go away, so it's not simply a USB bandwidth issue,

 

I still have a few ideas to test, documenting the results here as I go.  Any input would be welcome. image

 

Morgaine.

Parents

  • Bringing in some text from the other thread to make this one self-contained ...

     

    The way I'm testing the loss of mouse clicks is simply by putting two xterm windows side by side and left-clicking them alternately while the music is playing, and counting the clicks.  If a click is missed then the window doesn't gain focus and that's immediately visible.  So far I always get a missed click before reaching a count of 30.  The average interval between lost clicks is much less though, maybe around 12-15 clicks, and sometimes two clicks are lost in succession.

     

    Also, the keyboard sometimes goes into autorepeat on pressing a character, which suggests that the key release event is being lost and hence autorepeat gets activated.

     

    And I'm not sure if this is related or not, but sometimes I type a whole commandline in without looking, hit return, and see nothing typed on the xterm at all ... then a few seconds later it appears, along with the command output.  That's pretty bizarre, becaused the characters typed should be displayed by interrupt routines and have nothing to do with user process scheduling, on normal machines at least.

Reply

  • Bringing in some text from the other thread to make this one self-contained ...

     

    The way I'm testing the loss of mouse clicks is simply by putting two xterm windows side by side and left-clicking them alternately while the music is playing, and counting the clicks.  If a click is missed then the window doesn't gain focus and that's immediately visible.  So far I always get a missed click before reaching a count of 30.  The average interval between lost clicks is much less though, maybe around 12-15 clicks, and sometimes two clicks are lost in succession.

     

    Also, the keyboard sometimes goes into autorepeat on pressing a character, which suggests that the key release event is being lost and hence autorepeat gets activated.

     

    And I'm not sure if this is related or not, but sometimes I type a whole commandline in without looking, hit return, and see nothing typed on the xterm at all ... then a few seconds later it appears, along with the command output.  That's pretty bizarre, becaused the characters typed should be displayed by interrupt routines and have nothing to do with user process scheduling, on normal machines at least.

Children
No Data