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 1659 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

  • Morgaine what image are you working with ?

     

    I experienced some network issues with Debian (not the beta), and running a quick test sending a ping flood test from another unix machine, the R-pi gives a kernel panic after few minutes, sometimes even less than a minute.

     

    I didn't track it down in the kernel, but it looked like there is some issue with the USB driver and interrrupt management.

     

    I was not able to replicate the problem with the Debian Wheezy beta or with Arch Linux

     

    My .02

    -J

  • in reply to jamodio

    Just standard Squeeze debian6-19-04-2012.zip that's on their download page here, augmented with a few tools for testing, no major changes as I don't want to introduce new variables at this stage.

     

    I also installed IceWM to check it works on ARM because I'll be using it later by preference.  Interestingly, I see it has signficantly less overhead than OpenBox, so players start up cleaner than with the standard desktop (no ALSA grating during buffer preload).  But during tests I'm still using OpenBox, because that's the reference.

     

    Another interesting observation:  the MOC player's CPU usage of around 30% when playing my Oggs drops to 7% when playing mp3 files, so a tentative guess is that MP3 is decoded by the SoC and Ogg is not.  mpg123 has the same CPU usage as MOC on MP3 files, but of course can't handle Ogg.

     

    Using the Pi over ssh from various boxes overcomes the mouse click loss, and is significantly more responsive as the Pi's sluggish CPU doesn't matter then.

     

    I also installed Synergy on Pi, which gives me yet another way of avoiding the USB mouse problems.  I use Synergy quite a lot at home anyway to avoid keyboard/mouse proliferation, and it'll be the preferred way of using Model A without needing a powered hub, just dedicating the single USB to a wifi dongle.

     

    Morgaine.

Reply
  • in reply to jamodio

    Just standard Squeeze debian6-19-04-2012.zip that's on their download page here, augmented with a few tools for testing, no major changes as I don't want to introduce new variables at this stage.

     

    I also installed IceWM to check it works on ARM because I'll be using it later by preference.  Interestingly, I see it has signficantly less overhead than OpenBox, so players start up cleaner than with the standard desktop (no ALSA grating during buffer preload).  But during tests I'm still using OpenBox, because that's the reference.

     

    Another interesting observation:  the MOC player's CPU usage of around 30% when playing my Oggs drops to 7% when playing mp3 files, so a tentative guess is that MP3 is decoded by the SoC and Ogg is not.  mpg123 has the same CPU usage as MOC on MP3 files, but of course can't handle Ogg.

     

    Using the Pi over ssh from various boxes overcomes the mouse click loss, and is significantly more responsive as the Pi's sluggish CPU doesn't matter then.

     

    I also installed Synergy on Pi, which gives me yet another way of avoiding the USB mouse problems.  I use Synergy quite a lot at home anyway to avoid keyboard/mouse proliferation, and it'll be the preferred way of using Model A without needing a powered hub, just dedicating the single USB to a wifi dongle.

     

    Morgaine.

Children