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

Thierry Merle wrote:
> Thierry Merle a écrit :
>> Thierry Merle a écrit :
>>> Markus Rechberger a écrit :
>>>  
>>>> can you test the device with a normal PC too?
>>>> this will give you an image how it should behave in a usual 
>>>> environment..
>>>>
>>>> Markus
>>>>
>>>>       
>>> Right, tested OK in the same configuration.
>>> In fact the NSLU2 freezes only when a channel is tuned. I tried 
>>> without plugging the antenna cable and scan did not freeze the 
>>> kernel. All firmwares loaded OK.
>>> I tried to solder the serial console but my bad soldering iron made 
>>> a bad work. I stopped before breaking definitely the NSLU2.
>>>
>>>   
>> OK I succeeded in making the serial console work and got the USB 
>> problem.
>> I soldered a mobile phone data cable (containing a ark3116) on the 
>> NSLU2 serial pinouts and it worked.
>>
>> Attached is the logs before the end. It is proven that this is a 
>> memory allocation problem now...
>> minicom has truncated the lines to 80 chars in a curious way but the 
>> information is here.
>> Thierry
>>
> Hello,
> another bad news ;)
> I tested today to lower the usb allocation in em2880-dvb.c
> EM2880_DVB_NUM_PACKETS set to 8 instead of 64.
> I have an infinite loop of messages on console as soon as scan starts 
> and tries to tune a channel:
> 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 think that I have no more the memory problem, but now this is a 
> dma_free_coherent that is called in a place where IRQ are disabled 
> (like a locked section or other? just a supposition).
>
> Thierry
>
Tested with a newer kernel (2.6.22-2-ixp4xx from debian-sid), I get 
exception stacks added to the warning.
Since the dma_free_coherent is called within a watchdog timer, this 
explains why I get repetitive errors.
The error comes from ehci_hcd, there may be a robustness lack in it.


Thierry

Here is an occurrence of it:
WARNING: at arch/arm/mm/consistent.c:364 dma_free_coherent()
[<c0025d8c>] (dump_stack+0x0/0x14) from [<c0027034>] 
(dma_free_coherent+0x38/0x200)
[<c0026ffc>] (dma_free_coherent+0x0/0x200) from [<c002b5bc>] 
(dma_unmap_single+0x144/0x164)
[<c002b478>] (dma_unmap_single+0x0/0x164) from [<bf003b9c>] 
(usb_hcd_giveback_urb+0xb0/0x108 [usbcore])
 r7:c08633e0 r6:c1190800 r5:c08633e0 r4:00000001
[<bf003aec>] (usb_hcd_giveback_urb+0x0/0x108 [usbcore]) from 
[<bf02a6b4>] (ehci_urb_done+0x78/0x80 [ehci_hcd])
 r6:c11908bc r5:c11908bc r4:c08633e0
[<bf02a63c>] (ehci_urb_done+0x0/0x80 [ehci_hcd]) from [<bf02c290>] 
(ehci_work+0x474/0x79c [ehci_hcd])
 r5:c084e2a0 r4:ffc28180
[<bf02be1c>] (ehci_work+0x0/0x79c [ehci_hcd]) from [<bf02df50>] 
(ehci_watchdog+0x64/0x6c [ehci_hcd])
[<bf02deec>] (ehci_watchdog+0x0/0x6c [ehci_hcd]) from [<c003fcb0>] 
(run_timer_softirq+0x14c/0x1e0)
 r5:00000100 r4:c02914a0
[<c003fb64>] (run_timer_softirq+0x0/0x1e0) from [<c003c028>] 
(__do_softirq+0x5c/0xd0)
 r7:c02a7314 r6:0000000a r5:c0291284 r4:00000001
[<c003bfcc>] (__do_softirq+0x0/0xd0) from [<c003c3f4>] (irq_exit+0x44/0x4c)
 r6:00000000 r5:c0278144 r4:00000005
[<c003c3b0>] (irq_exit+0x0/0x4c) from [<c0021048>] 
(__exception_text_start+0x48/0x60)
[<c0021000>] (__exception_text_start+0x0/0x60) from [<c0021a24>] 
(__irq_svc+0x24/0x80)
Exception stack(0xc0271f64 to 0xc0271fac)
1f60:          c0885580 00000002 c0270000 00000000 c0022f50 c0270000 
c001ff50
1f80: c02a7314 0001e0ec 690541f1 0001dee4 c0271fc0 c0271fac c0271fac 
c0022d30
1fa0: c0022d38 60000013 
ffffffff                                             
 r6:00000020 r5:0000001f r4:ffffffff
[<c0022cf8>] (cpu_idle+0x0/0x54) from [<c01e5ad8>] (rest_init+0x48/0x58)
 r5:c028b828 r4:c029446c
[<c01e5a90>] (rest_init+0x0/0x58) from [<c0008bd8>] 
(start_kernel+0x280/0x2ec)
[<c0008958>] (start_kernel+0x0/0x2ec) from [<00008030>] (0x8030)


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel