Thanks Michal, it's good to hear g_ether/RNDIS should be working on 2.6.31. Yes I have tried that latest version of the INF file but it didn't make a difference, at this point I think there is one or two other issues. I will gather more info on the Windows side but first I wanted to bring up the first issue which might effect what it going on later during the RNDIS protocol exchange. After plugging in the USB cable we get a panic. I believe it doesn't occur until we attempt to install the driver/INF on the Windows side, but after that it always occurs when unplugging and replugging. I've added debugging and see that rndis_response_available() passes fsl_ep_queue() an ep who's container has a "struct usb_endpoint_descriptor *desc" which is NULL. This desc is set as part of enabling the ep in fsl_ep_enable() and cleared in fsl_ep_disable(). For some reason replugging in the cable causes 3 fsl_ep_disable(), 2 fsl_ep_queue() and then 3 fsl_ep_enable(). The first of the two fsl_ep_queue() is called with the ep containing the NULL desc. >From the trace below does anyone familiar with the RNDIS code have any idea why rndis_response_available() would call fsl_ep_queue() after a fsl_ep_disable()? Marc P.S. I should also point out the port is FS not HS in case that makes a difference. Unable to handle kernel NULL pointer dereference at virtual address 00000002 pgd = c0004000 [00000002] *pgd=00000000 Internal error: Oops: 17 [#1] PREEMPT Modules linked in: CPU: 0 Not tainted (2.6.31-4.1.1 #4) PC is at fsl_ep_queue+0x20/0x460 LR is at rndis_response_available+0x54/0x7c pc : [<c0303b00>] lr : [<c03056e8>] psr: a0000093 sp : c0521e50 ip : 00000018 fp : 00000000 r10: 00000000 r9 : 00000000 r8 : 00000002 r7 : 00000000 r6 : 00000001 r5 : c3b30940 r4 : c3b28740 r3 : 00000000 r2 : 00000020 r1 : c3b28740 r0 : c3b30940 Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 83264000 DAC: 00000017 Process swapper (pid: 0, stack limit = 0xc0520270) Stack: (0xc0521e50 to 0xc0522000) 1e40: c3b30940 c3b28740 00000020 c3b38560 1e60: 00000000 00000001 00000000 00000002 00000000 00000000 00000000 c03056e8 1e80: c0596dc0 c03074fc c3b38560 c3b28860 c3b28860 c3b3dae0 fde070c0 00000001 1ea0: c3b19000 c03075cc c3b30800 c3b28860 c3b28860 c3b30800 00000001 c0303904 1ec0: 00010001 c3b30800 c3b30818 00000000 00000040 00000001 00000100 c03046c0 1ee0: c48a8000 c3b19000 c3b190dc c0304a84 1d16952e c0528b88 00000001 00074138 1f00: 1d16952e 000013be 20000013 c0521f38 000f6cb8 c055b820 00000002 c3b3db20 1f20: c0520000 c3b3db20 00000025 00000001 00000000 00000000 00000000 c014a16c 1f40: c052c318 00000025 c3b3db20 00000002 00000001 c0520000 80023e08 c014bfbc 1f60: 00000025 00000000 00250000 c00fe064 80000013 ffffffff fc400000 c00fe9e8 1f80: 00000000 0005317f 0005217f 80000013 c0520000 c00f6e18 c00f6e14 c0523af8 1fa0: 80023e3c 41069264 80023e08 00000000 800000d3 c0521fc8 c00ff850 c00ff85c 1fc0: 80000013 ffffffff c00ff830 c00ffd38 c058cb40 c00088ec c0008448 00000000 1fe0: 00000000 c00f6e18 00000000 00053175 c0553e04 80008034 00000000 00000000 [<c0303b00>] (fsl_ep_queue+0x20/0x460) from [<c03056e8>] (rndis_response_available+0x54/0x7c) [<c03056e8>] (rndis_response_available+0x54/0x7c) from [<c03074fc>] (rndis_msg_parser+0x6f0/0x7a0) [<c03074fc>] (rndis_msg_parser+0x6f0/0x7a0) from [<c03075cc>] (rndis_command_complete+0x20/0x64) [<c03075cc>] (rndis_command_complete+0x20/0x64) from [<c0303904>] (done+0xdc/0xf8) [<c0303904>] (done+0xdc/0xf8) from [<c03046c0>] (T.592+0x30/0x40) [<c03046c0>] (T.592+0x30/0x40) from [<c0304a84>] (fsl_udc_irq+0x138/0x8ec) [<c0304a84>] (fsl_udc_irq+0x138/0x8ec) from [<c014a16c>] (handle_IRQ_event+0xa8/0x1e4) [<c014a16c>] (handle_IRQ_event+0xa8/0x1e4) from [<c014bfbc>] (handle_level_irq+0xc0/0x140) [<c014bfbc>] (handle_level_irq+0xc0/0x140) from [<c00fe064>] (_text+0x64/0x80) [<c00fe064>] (_text+0x64/0x80) from [<c00fe9e8>] (__irq_svc+0x48/0x88) Exception stack(0xc0521f80 to 0xc0521fc8) 1f80: 00000000 0005317f 0005217f 80000013 c0520000 c00f6e18 c00f6e14 c0523af8 1fa0: 80023e3c 41069264 80023e08 00000000 800000d3 c0521fc8 c00ff850 c00ff85c 1fc0: 80000013 ffffffff [<c00fe9e8>] (__irq_svc+0x48/0x88) from [<c00ff85c>] (default_idle+0x2c/0x30) [<c00ff85c>] (default_idle+0x2c/0x30) from [<c00ffd38>] (cpu_idle+0x60/0xb8) [<c00ffd38>] (cpu_idle+0x60/0xb8) from [<c00088ec>] (start_kernel+0x260/0x2b8) [<c00088ec>] (start_kernel+0x260/0x2b8) from [<80008034>] (0x80008034) Code: e5943000 e3530000 0a00010b e5903028 (e5d32002) Kernel panic - not syncing: Fatal exception in interrupt Rebooting in 5 seconds.. -----Original Message----- From: Michał Nazarewicz [mailto:mnazarewicz@xxxxxxxxx] On Behalf Of Michal Nazarewicz Sent: April 26, 2011 10:35 AM To: linux-usb@xxxxxxxxxxxxxxx; Marc St-Jean Subject: Re: State of g_ether/RNDIS? On Tue, 26 Apr 2011 17:55:55 +0200, Marc St-Jean <Marc.St-Jean@xxxxxxxxxx> wrote: > I'm new to the list and I wonder if I could get some help/orientation > with regards to the state of g_ether/RNDIS? > We are not trying to get a multi-function device working at this point, > simply a static configured g_ether/RNDIS. Should the existing kernel > code work without patches? Yes, g_ether should work without any additional patches. I've updated the Documentation/usb/linux.inf file in June 2010 (see 90eef5b8acb45: USB: gadget: g_ether: updated INF file) and it should work with anything starting with Windows XP SP3. Could you elaborate on the symptoms on Windows? Could you try installing <http://www.nirsoft.net/utils/usb_devices_view.html> and say what it says? (Or at least connecting the device to Linux host and issue "lsusb -vv -d 0525:".) -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal "mina86" Nazarewicz (o o) ooo +-----<email/xmpp: mnazarewicz@xxxxxxxxxx>-----ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
