Norbert Preining wrote:
But: I cannot load b44 module, I always get this treadfull error, see other thread about b44: Error, poll already scheduled
Right now this looks like a driver issue, since the driver isn't claiming the interrupt after resume. (From your /proc/interrupts in your previous email.)
Somebody needs to check if there is some code path that could prevent b44 from calling request_irq()...
Oops, never mind that. That's just because you hadn't ifup'd the device yet. But I still suspect a driver issue; your IRQ routing looks like it should be OK, but somebody is sending repeated interrupts. You could test with "acpi=noirq", but I don't think that will help.
What seems to be happening is the b44 hardware (or somebody else on irq5, maybe usb) is posting interrupts and the b44's status bit is never getting cleared.
This could be happening because the PCI card's I/O space hasn't been mapped. When I/O space is not mapped, you tend to read 0xFF from the I/O space, which would cause our IRQ handler to behave like this. I guess it wouldn't be mapped because the machine has just booted (resume from disk.) I'm not sure why the kernel doesn't seem to remap the I/O space when we call pci_enable_device(), but I have seen and fixed similar issues in 3c59x. See http://marc.theaimsgroup.com/?l=linux-net&m=109228179320361&w=2
Maybe what's happening here is the kernel believes I/O is already mapped, because it has loaded the memory image from before suspend.
I think the first step is to fix the b44 driver's suspend and resume callbacks. They are definitely missing some critical PCI calls.
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
