On Mon, 2004-01-19 at 16:53, Alan Stern wrote: > It's possible those interrupts were generated by another device sharing > the IRQ line. If that happens when the controller is suspended, I'm not > sure if the status should be 0 or 32. I'll have to recheck the > specification.
Meanwhile I found that in suspended state I get these status = 32 reads when I use my soundcard for playback. > > 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. > > This could be a result of different (or lack of) interrupt activity from > the hypothetical other device on the same IRQ. Your are right. As soon as I press the play button on my xmms I get the status = 32 reads. It is interesting how uncapable my brain seemed to be to make that connection: "hearing music <-> using sound card <-> generating interrupts on the shared irq". > > 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. Can anyone reproduce this malfunction? I mean the absence of this one interrupt call. I have two "standard" VIA Technologies UHCI controllers (rev 1a and rev 23). I would expect this behavior to be reproducible somewhere else. > Maybe on one machine the soundcard shares the IRQ and on the other machine > something else does. On the "buggy" machine both uhci controllers share the same interrupt. On the "working" machine the soundcard and one or both uhci controllers share the same interrupt. The BIOS additionally states that the video controller uses that interrupt, int contrast to /proc/interrupts. > > > 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. > > Sorry, that should have been /proc/driver/uhci... My mistake. This works, sort of... I get _two_ calls of uhci_irq, both on the "working" machine with only one controller enabled and on the "buggy" machine with two controllers enabled. The latter still prints one status = 32 call for every other uhci_irq call. Summary: - My desktop machine sort of works, as long as I listen to music :-). - None of my machines show any interrupt calls after the controller's suspension. - The set_next_interrupt mechanism generally works on both machines. 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
