Ok, the picture is getting a bit clearer... I did some further
investigation. The explanation for the "strange" part (traffic only when
moving mouse) is probably the shared interrupt 5 between the USB device
2 and the ethernet device eth0 (b44):
cat /proc/interrupts
CPU0
0: 112153 XT-PIC-XT timer
1: 912 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
3: 3 XT-PIC-XT
4: 4 XT-PIC-XT
5: 11999 XT-PIC-XT uhci_hcd:usb2, eth0
7: 1 XT-PIC-XT parport0
8: 3 XT-PIC-XT rtc
9: 9895 XT-PIC-XT acpi
10: 16636 XT-PIC-XT uhci_hcd:usb1, uhci_hcd:usb3,
ehci_hcd:usb4, ohci1394, yenta, yenta, Intel 82801DB-ICH4, [EMAIL
PROTECTED]:0000:01:00.0
11: 32895 XT-PIC-XT eth1
12: 609 XT-PIC-XT i8042
14: 42575 XT-PIC-XT libata
15: 6204 XT-PIC-XT libata
NMI: 0 Non-maskable interrupts
LOC: 0 Local timer interrupts
RES: 0 Rescheduling interrupts
CAL: 0 function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0if
MIS: 0
So when interrupt 5 is triggered by moving the mouse, it's also handled
by the ethernet driver, thus network traffic is handled. For the case
where the ethernet didn't work at all, I probably had the mouse simply
plugged into a different port (IRQ 10).
Also the problem does not happen when doing suspend to RAM, only suspend
to disk.
So the remaining question probably is: Why does the ethernet driver get
no interrupts on it's own after a resume from suspend to disk?
I'll see that I find the time in the next days to have a closer look a
the DebuggingKernelSuspend page. Does it apply also to suspend to disk?
I read it that it only applies to suspend to RAM...?
--
Network traffic only when moving mouse
https://bugs.launchpad.net/bugs/287600
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
