> > Actually, since Miles provided separate information about the
> > controller's real address (0xc5882000) which isn't the one
> > provided through the URB (0xc5880000), it's clear that some
> > pointer in the "urb->bus->dev->hcpriv" sequence used to get
> > that pointer (hcpriv) became bogus ...
>
> Didn't Miles say in his last mail that both Addresses are equal?
> (0xc5882000)
I may have missed some e-mail, pacbell has been darn poor lately.
Actually he said to me that they weren't (in one letter) but
in the full log he sent, I see they are ... I'm thinking that
his controller address is changing between runs, just to cause
maximal confusion!!
Jun 16 08:57:14 agate kernel: usb-ohci.c: USB OHCI at membase 0xc5872000,
IRQ 11
Jun 16 08:57:14 agate kernel: usb-ohci.c: PCI device 1045:c861
...
Jun 16 08:58:28 agate kernel: usb-storage.c: *** thread sleeping.
Jun 16 08:58:50 agate kernel: usb-ohci.c: USB suspend: c5872000
Jun 16 08:58:50 agate kernel: usb-ohci.c: rh_send_irq given bogus
controller address c5872000
Jun 16 08:59:04 agate last message repeated 5 times
Jun 16 08:59:05 agate kernel: usb-ohci.c: USB resume: c5872000
Jun 16 08:59:05 agate kernel: usb-ohci.c: rh_send_irq given bogus
controller address c5872000
Jun 16 08:59:06 agate last message repeated 2 times
...
Jun 16 08:59:07 agate kernel: PCI: Enabling device 03:00.0 (0000 -> 0002)
Jun 16 08:59:07 agate kernel: PCI: Found IRQ 11 for device 03:00.0
Jun 16 08:59:07 agate kernel: PCI: The same IRQ used for device 00:04.0
Jun 16 09:01:33 agate kernel: spurious 8259A interrupt: IRQ7.
OK, so this new information suggests something else is happening.
Could the timer be getting fired while PCI address mappings
need to be re-established? (I can't see any other reason why
a timer call would cause any trouble in this sequence, since
evidently both memory and the OHCI controller retained power,
so there's no state that'd have been lost.)
I'm not sure the significance of the messages about IRQ 11,
which is used by the USB controller, except that it suggests
experiments where that IRQ isn't shared.
Miles, what does your /proc/interrupts say about irq11? In
fact, all of the irqs ... can you do something to avoid such
sharing? I boot with "pci=biosirq", maybe turning that on or
off would shuffle those assignments enough to try this.
Hmm ... OK, more info. Is this using APM, or ACPI? Is it
possible to switch to the other, and still reproduce this?
ACPI has given me no happiness whatsoever, though ymmv.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
