Rafal Boni wrote: > Adding DIAGNOSTIC to the kernel (and rebuilding from scratch), I see > a bunch of 'uhci_device_icoc_enter: overflow!' messages if I run > mplayer as: > > $ mplayer /dev/video0 > > The interesting thing is it didn't crash (at least not for a few mins; > pre-DIAGNOSTIC it didn't last nearly that long), and I was able to kill > mplayer and repeat the experiment a few times without crashing. I will > file the first (non-DIAGNOSTIC) crash as a new PR unless you already have > one open, Jeremy.. Great - I don't believe there's a PR about this, do file one, essentially it's "Uvideo queues too many xfers to uhci/ohci". In the meantime, if you look in src/sys/dev/usb/uhcivar.h and update "UHCI_VFRAMELIST_COUNT" from 128 to 1024, this problem should be eliminated (or at least improved). There's absolutely no documentation for most of usb, but the vframelist is some memory-saving method. > Interestingly enough, having noticed another email about a uvideo crash > on the list today (http://mail-index.netbsd.org/tech-multimedia/2009/01/ > 31/msg000033.html), I ran mplayer as: > > $ mplayer -tv fps=25 tv:// > > and was actually rewarded with video (ok, the first time on the console; > I didn't know that mplayer did cheesy ASCII interpolation... scary!). On > the second try I ran it from within X and while the video is broken up and > mplayer complains about 'frame too small' and 'select timeout's I do get > video output -- though it's broken up as one might expect if frames were > being read partially and/or chopped -- and everything runs without crashing. Possibly isn't panicing by choosing a smaller resolution and so not hitting that frame limit. However I wouldn't trust kernel memory integrity after running that. I'm suprised mplayer coped with all the rubbish being spewed at it! -- Thanks, Jeremy
Attachment:
signature.asc
Description: OpenPGP digital signature