On Mon, 20 Sep 2010, Martin Schiller wrote: > Am 17.09.2010 18:53, schrieb Alan Stern: > > > Clearly the problem is that the controller isn't disabling the periodic > > schedule when told. The assumption in that patch is that the periodic > > schedule needs to be enabled for at least 1000 us before it can be > > disabled. Maybe the Geode needs more time, or maybe something else is > > wrong. You have to figure out what. > > > > Alan Stern > > > Ok, I tried different values for the delay. Starting with 2000 us up to > 90000 us. With this 90 ms it seems to run, but I don't know if this is a > practical solution, because I also don't know what effects on the performance > this change has. > > Can we still talk about USB 2.0 "HIGH SPEED"? > > Or do we just slow down everything so extremly, that the real problem can't happen any more? > > I also like to know where I can see that this has something to do with the > periodic schedule. Is it the "force halt; handshake" error? Because, > I think this is just an aftereffect to the "IAA watchdog ..." error. That's undoubtedly right. I didn't pay attention to the IAA watchdog messages in your log, but I should have. > With the first occurrence of the "IAA watchdog" error, my test-script stucks, > and when I then quickly kill the script, the "force halt; handshake" error > does not occur and I am able to reset everything by reloading the ehci-hcd module and > don't have to reboot the machine. This indicates that whatever went wrong, it hasn't gotten too bad. But later the controller gets totally stuck, requiring a reboot. > So, after some further test I've found out that with my real application > ( open port -> send/receive some data -> close port -> do nothing -> open port -> ... ) > the problem still resists, even with a delay of 500 ms!!! > > Since I've added a printk() to the code where the udelay is done, I can see it in the system log > when the delay is used. This is very often the case with the open/close test-script. But I can't see that > with my real application. It also stops working after this message: > > Sep 20 09:56:06 C1500 kernel: ehci_hcd 0000:00:0f.5: IAA watchdog: status 4008 cmd 10069 Yes, it seems clear that the IAA watchdog message indicates the controller has stopped working correctly. > Here are some other news: > > I changed the 3G module for my testings to an Option GTM382E. > This uses the hso.ko driver instead of the sierra.ko driver before. > > Interestingly, with this module/driver it seems that periodic scheduling > isn't used at all ( I can't see a "Periodic" status flag at any time). > Is this tuneable in the driver (sierra/hso)? I have no idea. > The application (my test script) > is absolutely the same. > > So, this module/driver combination runs quite longer, but sometime, > it stops operating too. And if it does, I can see that the "Async" flag > doesn't get cleared any more: > > IAA watchdog: status 8008 cmd 10069 > > Additionally, I observed that when the modems stops operating normally, > there are no "irq status ..." messages any more and the irq counters > in the registers file also stops increasing. > > It seems that there are no more IRQs at all from the controller. You seem to have demonstrated pretty convincingly that your Geode's EHCI controller is malfunctioning. Have you tried running the same software on a computer with a different chipset? Have you checked with the chipset manufacturer to see if they have published any silicon errata that could explain this? Alan Stern -- 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
