[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ehci_hcd map_single: unable to map unsafe buffer on a standard NSLU2



Lennart Sorensen a écrit :
On Tue, Sep 11, 2007 at 04:53:41AM -0700, Thierry Merle wrote:
I am using a Terratec Cinergy T2 USB tuner on my 266MHz NSLU2.
When I am recording a DVB-T stream, it takes around 33% CPU (zapdvb process,
the tool I use to record) but surprisingly, my NSLU2 is much less responsive
for other tasks (big latencies for ssh, fetchmail, imap and other things
that run on my box).
Nevertheless, the recorded file contains the entire stream (video is fluid).
Do you think this is a CPU related problem?

Isn't DVB-T mpeg?  That would be a lot less work than a raw captured tv
signal (the driver in question mentioned needing 170MBit per second on
the USB port per tuner, which sounds like an awful lot more data than an
mpeg stream would generate).  That would need much more bandwidth from
the cpu, and if the cpu now has to compress the video it would take
quite a lot of cpu.  Even the disk access to write 170MBit/s starts to
add up, especially since the disk is almost certainly on another USB
port.  I am assuming your tuner has hardware encoding to mpeg or that it
is receiving an existing mpeg stream from some other DVB device.

So yes I could see it being simply a CPU issue.

--
Len Sorensen


Right, DVB-T mpeg-2 TS for both cinergyT2 and em28xx based tuners.
To inform you the current state of the investigation:
- I wired a serial-to-usb cable to get the serial console (I used a
DKU-5 data cable containing a ark3116 chip, works perfectly for this
usage, and very cheap).
- by lowering the number of URB allocated in em28xx, I succeeded in
going further... to another bug :)
I have now the following error on console, so frequently that the NSLU2
cannot respond to any sollicitation (need to hard-shutdown it) :
BUG: warning at arch/arm/mm/consistent.c:363/dma_free_coherent()
BUG: warning at arch/arm/mm/consistent.c:363/dma_free_coherent()
BUG: warning at arch/arm/mm/consistent.c:363/dma_free_coherent()
[...]
This warning is caused by: WARN_ON(irqs_disabled()); in dma_free_coherent.
The function comment says:  * Must not be called with IRQs disabled.
I suggested that a dma_free_coherent has been indirectly called in a
critical section...
So we need to analyze that with the em28xx maintainer that does his best
to help me with the poor information I can give to him.

Thierry




Reply to: