On Sun, 2004-01-18 at 23:38, Alan Stern wrote: > You can selectively ignore that controller in your debugging messages > simply by checking the value of io_addr (or uhci->io_addr).
Isn't it possible to somehow really disable it, as if I disabled it in the BIOS. Or tell the uhci-hcd module to just not manage this device? > I don't know about the relation between your two controllers. They > _should_ be completely independent. > > Anyway, the controller generates a single interrupt at the time it is > suspended. That's the status = 32 and state = -10 you see. But then > while it is suspended it won't generate any interrupts at all until > you plug in a device. Even if you call set_next_interrupt. I have to disagree with you on this. (I guess what you stated is the way it should work). I observed some new and completely wired behavior: Since I added these printk's to the uhci_irq() function I saw these status = 32 calls for my second controller and if the first was suspended it generated the same. This resulted in about 30-50 interrupts per second. After I disabled the second controller I rerun my test and the single enabled controller had the same behavior, continuous calls of uhci_irq with status = 32 after it was suspended. Now the wired thing is, about an hour or two later, after I received this message from you, I wanted to reproduce this behavior in a simpler test-scenario: load uhci-hcd, no device attached, wait a second and see the interrupts. BUT there was not a single one of them after the suspend of the controller. Since that time my "working" machine behaves exactly like the "buggy" one, even if I reenable the second controller. This includes the kernel panic when I replug the device. I tried it several times, I can not reproduce neither the "old" nor the "intermediary" behavior. I just have two crashing machines now. Maybe the good thing is, that I have found a scenario where the problem occurres without any device attached. I simply load uhci-hcd with no attached device and wait for the interrupt after the suspend. A few thoughts about that from my point of few: - the only changes I made during all that time were some printk's I added. Maybe they influenced some time critical mechanisms? - Maybe the problem with the missing interrupts is not a specific usb problem but something "deeper", related to interrupt sharing or BIOS interrupt assignment? - I don't think I have two completely independent machines both with the same hardware defect. - Since I always saw the state = 32 call after a "usual" one (meaning state = 0, 1, 2, 3) it might me that the uhci controller did not really generate these interrupts but the soundcard did, wich seemed to share the interrupt with both controllers. So that uhci_irq was called for whatever reason and then saw that the controller is disabled. This would also explain the difference to the "buggy" machine, that does not have this additional card. It does not, however, explain why I can not reproduce the "old" behavior. > It looks like set_next_interrupt isn't working on your systems. You can > test that by patching uhci_proc_open() in uhci_debug.c. Add a call to > set_next_interrupt, say right before the "ret = 0" line. Then each time > you open the /proc/devices/uhci... file you should cause an interrupt. > Just make sure a device is plugged in (so the controller isn't suspended) > and is idle (so you aren't confused by unrelated interrupts). I'd like to try that but don't know what you mean with the /proc/devices/uhci... file. /proc/devices is a file not a directory on my system and if I cat that nothing happens. Thanks, Axel. ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
