>> Sounds like something funny is happening with respect to the card/driver, >> almost as if you might be losing interrupts ? >> Find out what IRQ each card has after your resume ( cat >> /proc/interrupts ) >Hmm, >alright then ... > > grep ^209 ints?.txt >ints1.txt:209: 170 IO-APIC-level eth0, Intel 82801DB-ICH4, >Intel 82801DB-ICH4 Modem >ints2.txt:209: 184 IO-APIC-level eth0, Intel 82801DB-ICH4, >Intel 82801DB-ICH4 Modem >ints3.txt:209: 184 IO-APIC-level Intel 82801DB-ICH4, Intel >82801DB-ICH4 Modem, eth0 >ints1.txt is my start config ... >ints2.txt is after a ping >ints3.txt is after the resume, a manual unload/reload of the modules, a >manual ifconfig (since dhclient won't work) and an attempt to ping >apparently the interrupt 209 is shared among the NIC and the sound >device/winmodem and since I unloaded the driver, eth0 gets appended to >the end of the list. Also, apparently no interrupt gets counted. I've never heard of a system with interrupt '209'. I expect that is to do with you using APIC interrupts apparently. I'm more acustomed to values like:- 10: 960766 XT-PIC PCnet/PCI II 79C970A I.e. IRQ 10, has gone off 960766 times. Though, the APIC support on a dual-CPU card results in large interrupts, etc. >But what does that tell me? Is that a cause or an effect, and can I do >anything about it? I appreciate what you're saying, but I'm not sure really... You MAY be just having lost interrupts and hence getting the errors and not-working, or you MAY just be having no interrupts going off on the network card because something else is more fundamentally broken in card//driver, so never gets to stage of causing interrupts. I *do* know that 'the eth0: watchdog: transmit timed out' *DOES* happen when the network card interrupt is not working (e.g. software set for one IRQ, card set for another, etc.), so that is an area of suspect but it MAY not be your problem. I'm not sure what you can/can't disable in an ACPI system (if you are using ACPI).... I'm not sure if you are using an ACPI 'style' suspend or not! I'd be tempted to try turning off/on the 'APIC' interrupt support assuming you are on a uniprocessor system (assuming that doesn't break the kind of 'suspend' you are doing). I'd be tempted to experiment with using the 'rtl8139' driver in place of the '8139too' driver... Note: the rtl8139 is a cheap-nasty sort of network chipset, which has various bugs/problems, which '8139too' driver tries to work around better than the 'rtl8139' driver, I think, iirc... I'd be tempted to try a different type of network card/device (e.g. intel eepro100 or 3com 3c905 or something else... just not a (horrible!) via-rhine or sis900. >Thanks for your help, [not a problem]. I'd be interested to hear how you get on with this problem, etc. >Karl. -S Iremonger <exxsi@xxxxxxxxxx> - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
