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

David & Anne-Sophie a écrit :
> Markus Rechberger a écrit :
>> On 9/13/07, David & Anne-Sophie <[email protected]> wrote:
>>  
>>> Markus Rechberger a écrit :
>>>    
>>>> On 9/13/07, David & Anne-Sophie <[email protected]> wrote:
>>>>
>>>>      
>>>>> Markus Rechberger a écrit :
>>>>>
>>>>>        
>>>>>> On 9/12/07, David & Anne-Sophie <[email protected]> wrote:
>>>>>>
>>>>>>
>>>>>>          
>>>>>>> Markus Rechberger a écrit :
>>>>>>>
>>>>>>>
>>>>>>>            
>>>>>>>> On 9/11/07, David & Anne-Sophie <[email protected]> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>              
>>>>>>>>> Markus Rechberger a écrit :
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                
>>>>>>>>>> On 9/10/07, David & Anne-Sophie <[email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                  
>>>>>>>>>>> David & Anne-Sophie a écrit :
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                    
>>>>>>>>>>>> Hello all,
>>>>>>>>>>>> I am trying to use my hybrid USB tuner on my NSLU2.
>>>>>>>>>>>> Tuner=Terratec cinergy XS
>>>>>>>>>>>> Driver=http://mcentral.de/wiki/index.php/Em2880
>>>>>>>>>>>> I plugged it directly to the DISK-2 connector. On DISK-1 
>>>>>>>>>>>> there is
>>>>>>>>>>>>                       
>>> a
>>>    
>>>>>>>>>>>>                       
>>>>>>> USB
>>>>>>>
>>>>>>>
>>>>>>>            
>>>>>>>>>>>> hard-disk that contains the filesystems.
>>>>>>>>>>>>
>>>>>>>>>>>> The driver compiles fine on the standard debian etch 
>>>>>>>>>>>> kernel, and
>>>>>>>>>>>>
>>>>>>>>>>>>                       
>>>>> loads
>>>>>
>>>>>        
>>>>>>>>>>>> perfectly.
>>>>>>>>>>>> I just did a minor patch of this driver around a 
>>>>>>>>>>>> udelay(2500); ->
>>>>>>>>>>>> udelay(2000);udelay(500); (2500 is a too big value for the ARM
>>>>>>>>>>>> architecture, see bad_udelay).
>>>>>>>>>>>>
>>>>>>>>>>>> When I try tzap to activate the dvb-t stream, I get those 
>>>>>>>>>>>> errors:
>>>>>>>>>>>> ehci_hcd 0000:00:01.2: alloc_safe_buffer: could not alloc dma
>>>>>>>>>>>>                       
>>> memory
>>>    
>>>>>>>>>>>> (size=36096)
>>>>>>>>>>>> ehci_hcd 0000:00:01.2: map_single: unable to map unsafe buffer
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                       
>>>>>>> ffc2c000!
>>>>>>>
>>>>>>>
>>>>>>>            
>>>>>>>>>>>> many times (I think one per USB packet).
>>>>>>>>>>>> And the tuner does not stream anything...
>>>>>>>>>>>>
>>>>>>>>>>>> I did not modify anything in the NSLU2 (neither RAM or 
>>>>>>>>>>>> frequency),
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                       
>>>>>>> just
>>>>>>>
>>>>>>>
>>>>>>>            
>>>>>>>>>>>> upgraded to debian etch arm architecture following the
>>>>>>>>>>>>
>>>>>>>>>>>>                       
>>>>> nslu2-linux.org
>>>>>
>>>>>        
>>>>>>>>>>>> tutorials.
>>>>>>>>>>>> Do you know what it means and how to solve the issue?
>>>>>>>>>>>> Do not hesitate to ask for specific information.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> David.
>>>>>>>>>>>> [email protected]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Em28xx mailing list
>>>>>>>>>>>> [email protected]
>>>>>>>>>>>> http://mcentral.de/mailman/listinfo/em28xx
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                       
>>>>>>>>>>> I have some informations that can help you to resolve my 
>>>>>>>>>>> problem.
>>>>>>>>>>>
>>>>>>>>>>>                     
>>>>> These
>>>>>
>>>>>        
>>>>>>>>>>> informations comes from the newlist of debian-arm :
>>>>>>>>>>> In this forum, I said that the driver works correctly on a 
>>>>>>>>>>> PC with
>>>>>>>>>>> ubuntu, and the response is :
>>>>>>>>>>> "Working on a PC does not mean the driver is correct.  On a PC
>>>>>>>>>>>
>>>>>>>>>>>                     
>>>>> physical
>>>>>
>>>>>        
>>>>>>>>>>> addresses match the kernel's point of view in general, while 
>>>>>>>>>>> on the
>>>>>>>>>>>
>>>>>>>>>>>                     
>>>>> arm
>>>>>
>>>>>        
>>>>>>>>>>> everything goes through interesting mappings, which make is
>>>>>>>>>>>                     
>>> essential
>>>    
>>>>>>>>>>> for the driver to correctly use readX/writeX calls along with
>>>>>>>>>>>                     
>>> ioremap
>>>    
>>>>>>>>>>> calls.  Any attemps to directly access anything will fail on 
>>>>>>>>>>> the
>>>>>>>>>>>                     
>>> arm
>>>    
>>>>>>>>>>> while it almost always works on a PC.  Not sure quite how that
>>>>>>>>>>>                     
>>> might
>>>    
>>>>>>>>>>> impact a USB device, but even there the driver has to do DMA 
>>>>>>>>>>> setup
>>>>>>>>>>>
>>>>>>>>>>>                     
>>>>> with
>>>>>
>>>>>        
>>>>>>>>>>> corrected addresses, which again is not necesary on a PC but 
>>>>>>>>>>> is on
>>>>>>>>>>>
>>>>>>>>>>>                     
>>>>> the
>>>>>
>>>>>        
>>>>>>>>>>> arm. "
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>                     
>>>>>>>>>> i'm at the suse conference this week there are some interesting
>>>>>>>>>>                   
>>> people
>>>    
>>>>>>>>>> around who're into the usb subsystem.
>>>>>>>>>> The em28xx driver makes use of the usb subsystem (which also
>>>>>>>>>>                   
>>> includes
>>>    
>>>>>>>>>> allocation of memory)
>>>>>>>>>> I'll try to get some answers tomorrow about this issue.
>>>>>>>>>>
>>>>>>>>>> Markus
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                   
>>>>>>>>> Hello Markus,
>>>>>>>>>
>>>>>>>>> Do you have news about my problem ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                 
>>>>>>>> in em28xx.h there's a static defined value for the number of
>>>>>>>>
>>>>>>>>               
>>>>> videopackets
>>>>>
>>>>>        
>>>>>>>> #define EM28XX_NUM_PACKETS 40
>>>>>>>>
>>>>>>>> try to lower that value by about the half or less this will 
>>>>>>>> allocate
>>>>>>>> less memory in the end. I'm not sure if that might out .. although
>>>>>>>> that was the only idea which came up after the talk yesterday. 
>>>>>>>> Let me
>>>>>>>> know if it works out otherwise I'll have a further discussion 
>>>>>>>> about it
>>>>>>>> with the usb guys.
>>>>>>>>
>>>>>>>> Markus
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>               
>>>>>>> Hello Markus,
>>>>>>>
>>>>>>> I tried your patch. I set the value to 20. Now tzap seems to work
>>>>>>> correctly (tzap -r -c channels.conf "TF1", for exemple) and I don't
>>>>>>>             
>>> have
>>>    
>>>>>>> any error with dmesg. But, when i try cat / 
>>>>>>> /dev/dvb/adapter0/dvr0 >
>>>>>>> test.ts/, the file is still empty ? and with cp 
>>>>>>> /dev/dvb/adapter0/dvr0
>>>>>>> foo, the command doesn't leave immediatly, I must break the 
>>>>>>> command to
>>>>>>> leave ?
>>>>>>> Do you have an idea ?
>>>>>>>
>>>>>>>
>>>>>>>             
>>>>>> Could you try to dump the stream with mplayer?
>>>>>> If this doesn't work out we'll add some debug for the usb packets. I
>>>>>> only have 2 days left to discuss this issue with the right guys 
>>>>>> here.
>>>>>>
>>>>>> Markus
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>           
>>>>> Sorry, but it is impossible to use mplayer on a nslu2. It doesn't 
>>>>> have a
>>>>> video card. I have only a ssh connection.
>>>>> You can see some informations about it here : 
>>>>> http://www.nslu2-linux.org/
>>>>> For information, the scan command doesn't work too.
>>>>>
>>>>>
>>>>>         
>>>> The scan command is sufficient.
>>>> Could you load the em28xx driver with reg_debug=1 and try to scan for
>>>> channels with scan -vvv <frequencymap>
>>>>
>>>> Thanks,
>>>> Markus
>>>>
>>>>
>>>>
>>>>       
>>> With the scan command, it doesn't find a valid list (I try it on ubuntu
>>> and it works) :
>>> For example :
>>>  >>> tune to:
>>> 482000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_AUTO:HIERARCHY_NONE 
>>>
>>> WARNING: filter timeout pid 0x0011
>>> WARNING: filter timeout pid 0x0000
>>> WARNING: filter timeout pid 0x0010
>>> But no result ?
>>>
>>> See dmesg informations :
>>> DIGITAL TV REQUEST
>>> scan: page allocation failure. order:4, mode:0x1
>>> Mem-info:
>>> DMA per-cpu:
>>> cpu 0 hot: high 6, batch 1 used:5
>>> cpu 0 cold: high 2, batch 1 used:0
>>> DMA32 per-cpu: empty
>>> Normal per-cpu: empty
>>> HighMem per-cpu: empty
>>> Free pages:         740kB (0kB HighMem)
>>> Active:4051 inactive:1007 dirty:279 writeback:0 unstable:0 free:185
>>> slab:913 map     ped:1468 pagetables:173
>>> DMA free:740kB min:724kB low:904kB high:1084kB active:16204kB
>>> inactive:4028kB pr     esent:32768kB pages_scanned:0 
>>> all_unreclaimable? no
>>> lowmem_reserve[]: 0 0 0 0
>>> DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB
>>> present:0kB page     s_scanned:0 all_unreclaimable? no
>>> lowmem_reserve[]: 0 0 0 0
>>> Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB
>>> present:0kB pag     es_scanned:0 all_unreclaimable? no
>>> lowmem_reserve[]: 0 0 0 0
>>> HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB
>>> present:     0kB pages_scanned:0 all_unreclaimable? no
>>> lowmem_reserve[]: 0 0 0 0
>>> DMA: 7*4kB 39*8kB 11*16kB 5*32kB 1*64kB 0*128kB 0*256kB 0*512kB 
>>> 0*1024kB
>>> 0*2048k     B 0*4096kB = 740kB
>>> DMA32: empty
>>> Normal: empty
>>> HighMem: empty
>>> Swap cache: add 2332, delete 2173, find 267/374, race 0+0
>>> Free swap  = 90764kB
>>> Total swap = 96348kB
>>> Free swap:        90764kB
>>> 8192 pages of RAM
>>> 356 free pages
>>> 753 reserved pages
>>> 913 slab pages
>>> 7013 pages shared
>>> 159 pages swap cached
>>>
>>> You have enought informations ?
>>>
>>>     
>>
>> Could you try to lower the packet number again, seems like you're out
>> of DMA'able memory?
>>
>> I added linux-usb-devel and Greg, the history of that mail can be 
>> found at:
>> http://mcentral.de/pipermail/em28xx/2007-September/000755.html
>>
>> Markus
>>
>>
>>   
> Hello,
>
> I give you results with constante set to 1 and modprobe em28xx 
> reg_debug=1
> Any idea ?
>
I retry with an attached file because the message has not be sent to 
Greg and linux-usb-devel because the size of the mail is too big.

Thanks
David

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel