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

  • Not wanting to try to teach you how to suck eggs, but... image

     

    You have tried:

    power through gpio header from a decent bench psu ?

    all usb stuff on an externally powered USB hub ?

    bridging polyfuses and/or running a pi-pass ?

    larger cap across usb power ?

    wired, not wireless keyboard/mouse ?

    different kernels ?

    cut-down install - something that doesn't have 101 unnecessary daemons running ?  (my feeling here is that the Pi likely isn't suited to a full-blown desktop distro that was designed with a quad core 3Ghz x86_64 and 16Gb of Ram in mind)

     

    I have occasionally seen the repeating key problem, but it's not been something I can reliably reproduce and as such impossible to get a handle on what's causing it.

  • in reply to Former Member

    selsinork:  I haven't tried most of those because I don't see a causal path that would connect them with the problem.  Pi power is a bit ropey, sure, but my TP1 is at 4.89V and the only USB port that is being used is for the Logitech receiver which is taking less than 3mA and hence running totally cold.  That doesn't make me suspect power issues in the first instance, although noise on the power line still needs to be eliminated.

     

    I haven't tried wired keyboard and mouse yet because mine are mostly old and power-hungry (which is why I bought the modern Logitech with the combined receiver).  It's a good thing to try though, because EMC problems might be the culprit.  I have one similar test lined up, which is to put the Logitech receiver on a long USB lead so that its RF near-field can't affect the Pi nor vice versa.

     

    I haven't tried any new drivers or kernels or blobs yet, and I'll have to migrate to a bigger SD card before I can rebuild the kernel as I'm right up against the ceiling currently.  Is there anything that isn't in the recommended Debian image which might improve matters?

     

    The 300Hz mod sounds like a disaster, but I guess I should try it just in case.

     

    Morgaine.

  • in reply to morgaine

    Power issues are a tricky one. Too many reports of problems that go away with a better PSU or micro usb cable to rule them out without trying it. Also TP1 voltage isn't necessarily the whole story, have seen several reports of the polyfuses between TP1 and the usb ports having oddly high resistances, so test voltage on the usb port itself rather than TP1.  No way 3mA should be a problem, but for the sake of a couple of minutes what do you have to lose ?

    Others have had luck with either replacing the polyfuses with a wire link or bypassing the whole thing with a heavy wire direct from micro usb to the usb ports - although this seems to leave the bottom usb port unuseable..

     

    Obviously YMMV with any of the power mods as it'll depend a lot on your Pi and whatever devices you plug into it.. In my case it was the micro-usb power cables that were the biggest problem 0.5v+ drop across the cable regardless of the actual power source.

     

    I don't believe there's anything missing from the Debian image, newer kernel/blob just rules out an existing bug that may have been fixed.

     

    Compiling the kernel on the Pi is slow, around 3-4 hours for me with the kernel source on NFS and that's with most of the junk stripped out.  If you have another linux machine available I'd recommend using crosstool-ng to build a cross compiler and reduce the time.

  • in reply to Former Member

    selsinork wrote:

     

    No way 3mA should be a problem, but for the sake of a couple of minutes what do you have to lose ?

     

    Agreed. image

     

    I did  test F1 and F2 even before I had USB power available --- http://www.element14.com/community/message/54970#54970 --- but wierd things do happen, and you can't measure too often. image

     

    Others have had luck with either replacing the polyfuses with a wire link or bypassing the whole thing with a heavy wire direct from micro usb to the usb ports - although this seems to leave the bottom usb port unuseable.

     

    I won't be doing any hardware hacking until Pi boards are ex-stock.  This ordering and waiting process isn't for me, and I only put up with it once. image

Reply
  • in reply to Former Member

    selsinork wrote:

     

    No way 3mA should be a problem, but for the sake of a couple of minutes what do you have to lose ?

     

    Agreed. image

     

    I did  test F1 and F2 even before I had USB power available --- http://www.element14.com/community/message/54970#54970 --- but wierd things do happen, and you can't measure too often. image

     

    Others have had luck with either replacing the polyfuses with a wire link or bypassing the whole thing with a heavy wire direct from micro usb to the usb ports - although this seems to leave the bottom usb port unuseable.

     

    I won't be doing any hardware hacking until Pi boards are ex-stock.  This ordering and waiting process isn't for me, and I only put up with it once. image

Children
No Data