* Hänel-Baas, Alexander | 2013-10-14 14:26:51 [+0000]: >Hello Sebastian, Hello Alexander, >nice to hear from you. > >Yes I have disable ehci & ohci with no changes. > >But the following dmesg shows the problem: > >[ 335.682365] gen_ndis_query_resp: RNDIS_OID_GEN_RCV_NO_BUFFER -> normal read >[ 335.693595] g_ether gadget: rndis reqa1.01 v0000 i0000 l4096 >[ 335.700148] g_ether gadget: rndis req21.00 v0000 i0000 l36 >[ 335.713727] g_ether gadget: rndis reqa1.01 v0000 i0000 l4096 >[ 335.720236] g_ether gadget: rndis req21.00 v0000 i0000 l36 >[ 335.733730] g_ether gadget: rndis reqa1.01 v0000 i0000 l4096 >[ 335.740482] g_ether gadget: rndis req21.00 v0000 i0000 l36 >[ 335.746520] gen_ndis_query_resp: RNDIS_OID_GEN_RCV_NO_BUFFER -> normal read >[ 335.757582] g_ether gadget: rndis reqa1.01 v0000 i0000 l4096 >[ 335.764220] g_ether gadget: rndis req21.00 v0000 i0000 l36 >[ 335.777721] g_ether gadget: rndis reqa1.01 v0000 i0000 l4096 >[ 335.784467] g_ether gadget: rndis req21.00 v0000 i0000 l36 >[ 335.797842] g_ether gadget: rndis reqa1.01 v0000 i0000 l4096 >[ 335.804473] g_ether gadget: rndis req21.00 v0000 i0000 l36 >[ 335.810456] gen_ndis_query_resp: RNDIS_OID_GEN_RCV_NO_BUFFER -> normal read >[ 335.821753] g_ether gadget: rndis reqa1.01 v0000 i0000 l4096 >[ 348.741461] g_ether gadget: rndis req21.00 v0000 i0000 l12 >[ 348.766563] pch_udc 0000:05:02.4: ES -> !!! not normal what is ES!!! This is specific to the pch_udc you are using. The manual of your SoC should describe this. But looking at the time stamps "348 - 335", there were 13 seconds of nothing. The following packet might be a reminder of the host… >[ 348.770744] rndis_msg_parser: unknown RNDIS message 0x80000004 len 28 >[ 348.777492] rndis_msg_parser00000000: 04 00 00 80 1c 00 00 00 d2 33 00 00 00 00 00 00 .........3...... >[ 348.787334] rndis_msg_parser00000010: 04 00 00 00 10 00 00 00 41 00 00 00 ........A... >[ 348.796795] RNDIS command error -524, 0/12 -> result of ES is a read error !? >[ 348.801379] g_ether gadget: reset config >[ 348.805549] g_ether gadget: rndis deactivated >[ 348.810159] usb0: gether_disconnect >[ 348.822880] pch_udc 0000:05:02.4: USB_RESET >[ 348.910541] pch_udc 0000:05:02.4: pch_udc_ep_clear_nak: RxFIFO not Empty >[ 348.917637] pch_udc 0000:05:02.4: USB_ENUM >[ 354.814204] pch_udc 0000:05:02.4: ES -> my new friend is here and he never leaves. Maybe it is an error condition which is not processed and the error remains. So if this interrupt source remains active then it would explain your busy loop. But back to rndis: ES does not mean read error. The message your host sent can not be processed by the gadget because it does not understand it. You see this by "unknown RNDIS message" in the output and the command err -524 aka -ENOTSUPP. As a result the gadget NAKs that requests and the hosts does not like it, resets the USB bus and starts over. >Ok. The pch_udc.c code tells me: > >/* ES interrupt, IDLE > 3ms on the USB */ > if (dev_intr & UDC_DEVINT_ES) > dev_dbg(&dev->pdev->dev, "ES\n"); > >Sebastian, can you tell my more about ES interrupt? It is pch_udc specific. The manual should know more about it but seems it shows up if the usb bus is idle. I have no idea why this should be an error condition. If I remember RNDIS correctly, then the host sends a "few" ep0 requests to query some informations. The UDC just waits for ep0 packets to arrive and us prcessing the requests. This is probably what the | rndis req21.00 v0000 i0000 l12 output is showing you. The ep0 communication is usually a little more compilcated compared to ep1+ because you have only one endpoint in both direction and you need know when you read and when you are allowed to write / send data. There might be a timming related bug in the driver. Since you control both sides, you should be able see which message the hosts sends, which message the gadget recevies (is it the same) and the other way around. Based on this you could atleast understand why the hosts sends the "0x80000004" which the gadget does not understand. It should not do so in non-RT case. Once you see the messages exchanged in RT and non-RT case you should see a difference which should help you to track the bug. > >When I change the rt-config to low-latency-desktop (not RT) my ES friend comes never up an the gadget works well. > > >Greetings > >Alexander Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
