Ralph Metzler wrote: >Petr Nejedly writes: > > I was trying to make CinergyT2 working on on two embeded boxes, > > LinkSys NSLU2 and Asus WL500gx (both have USB2.0 HCD, one from > > VIA, other one from NEC), but it oopsed kernel on both of them as soon > > as it started transfer of the TS data. > >Is this on a 2.6 or a 2.4 kernel? >Or my question rather is, is there a 2.6 port for those devices yet? > > It is 2.4. At least for the NSLU2, there seems to be a 2.6 port but without reliable eth0 (and I can't live without eth0 of course ;-) > > After several sleepless nights, I've hacked together a simplified driver > > (mimicking the original one) that doesn't oops and is able to provide > > full TS stream > > on these devices. The only important difference is that I allocate the > > URB buffers > > using kmalloc, while the original driver does pci_alloc_consistent. > > If I use pci_alloc_consistent, my driver starts to oops the kernel as well, > > although the memory region seems to be allocated right. > >Hmm, is this somehow broken on MIPS? Which kernel? > > It was 2.4.25 for MIPS (wl500gx, based on BCRM4702) and 2.4.22 for ARM (NSLU2, based on XScale-IXP425) The crash was very similar on those devices although I have (partially decoded) oops from one of them: kernel BUG at ehci-mem.c:129! Unable to handle kernel paging request at virtual address 00000000, epc == c00b1acc, ra == c00b1acc Oops in fault.c::do_page_fault, line 192: $0 : 00000000 1000fc00 0000001e 00000001 81cd2000 00000000 00000001 00000000 $8 : 00002043 801dc31c 00000000 00000000 fffffff9 ffffffff 0000000a 00000002 $16: a1c70000 00000000 800d5f80 81deaa00 8106a000 8106a000 94ef7751 94c77dd0 $24: 8106bd3a 00000002 8106a000 8106be70 00000000 c00b1acc Hi : 00000000 Lo : 00000026 epc : c00b1acc Not tainted Status: 1000fc03 Cause : 0000000c Process keventd (pid: 2, stackpage=8106a000) Stack: c00b66a0 c00b66b8 00000081 1000fc00 81deaa00 81deaa64 0000000a 801afa70 c00b1c44 00000000 c00970b8 c0097078 81deaa00 81deaa64 81deaa00 c00b5a74 00000000 00000000 81596ff1 8106bee4 c01161d4 801afa70 8106a000 8106a000 8106bed8 94c77dd0 8106bee4 00000064 00000363 c01160e0 81596000 81596ff1 81596200 00000000 c01173fc c01173a4 800032e4 00010001 81c1fe30 8106bf48 ... Call Trace: [<c00b66a0>] [<c00b66b8>] [<c00b1c44>] ehci_mem_cleanup [<c00970b8>] [<c0097078>] [<c00b5a74>] ehci_stop [<c01161d4>] [<c01160e0>] [<c01173fc>] [<c01173a4>] [<800032e4>] kernel_thread [<c00a3618>] usb_hcd_pci_remove-usb_hcd_giveback_urb [<8001f700>] exec_usermodehelper / call_usermodehelper [<8001684c>] __run_task_queue~ [<8001684c>] __run_task_queue~ [<8001ff28>] schedule_task~ [<8001fefc>] schedule_task~ [<8001fd6c>] schedule_task [<800032f4>] kernel_thread [<800200d0>] flush_scheduled_tasks [<800032e4>] kernel_thread > > > Does the original driver really need to allocate the buffers this way? I > > haven't seen > > any other USB driver doing so (except ttusb-budget from the same author, > > which > > fails in such embeded enviroment as well, although w/o crash, just > > getting zeroed > > buffers from ISOC instead of real data). > > > > I haven't tried using kmalloc instead of pci_alloc_consistent on my x86 > > desktop > > yet but should it work, wouldn't it be better to rewrite the driver to > > use kmalloc? > >No, it should use usb_buffer_alloc, which does the right thing for >each platform and controller (either kmalloc or dma_alloc_coherent). >I think if you use kmalloc for all platforms you might run into >trouble with cache inconsistencies on some of them. > > That's what I wanted to know, thanks. Nenik
