Comment 8 for bug 267779

On Sat, 2009-02-28 at 08:01 +0000, Jeff Trull wrote:
> I filed bug 281089 on two resume issues: one network (I have this same
> via rhine driver) and one USB mouse. My network issue appears to be the
> same as this bug, judging from the dmesg backtrace. I'm not sure I
> would agree that this is a firmware issue, though - for me this is a
> regression from Hardy, where suspend worked properly on the identical
> hardware.

>From the research I'd done so far and the irqfixup solution that always
seems to work, it seems it works because irqfixup tries to find a
matching IRQ handler for unhandled IRQs - the implication being that the
firmware in the device has 'forgotten' which IRQ has been assigned to it
due to the power-off, and doesn't accept the assignment given at resume.

*However*, thanks to Jeff's comment I examined the dmesg log here and in
Jeff's bug #281089 and noticed that at start-up we see the device has
bus ID 0:12.0:

00:12.0 Ethernet controller [0200]: VIA Technologies, Inc. VT6102
[Rhine-II] [1106:3065] (rev 78)

and has an interrupt assigned:

[ 5.208228] via-rhine 0000:00:12.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[ 5.208558] eth0: VIA Rhine II at 0xfbb00000, 00:17:31:19:04:36, IRQ 23.

But after resume there is no sign of the IRQ being reassigned.

So, thanks Jeff for prodding me to look closer.

The revised explanation for why irqfixup works is that after resume the
firmware will use a default IRQ since it doesn't get reprogrammed by the
PCI sub-system, and will likely be different to the IRQ the driver is
expecting. irqfixup will match the two together.

As Jeff points out that Hardy doesn't have the issue I've got a
reasonably small window of potential changes to look at to figure out
what changed to cause this.