Re: peculiar problem with 2.6, 8139too + ACPI
From: Robert Fendt
Date: Sat May 15 2004 - 18:36:09 EST
> It is possible that the system is getting into a high power saving
> mode on idle. Device bus master activity or interrupts will wake
> it up -- but the latency to return from power savings mode may be
> so high that the device experiences receive buffer overruns.
Yes, I also thought in that direction, since the main difference between
the processor module loaded or not seems to be the idle handler.
> Some devices handle this latency better than others,
> and with a network, dropping RX packets can cause the
> connection to thrash, and it seems that is what you see.
> If the 8139too has statistics counters showing if it gets
> RX buffer over-runs, that would be interseting to observe.
I seem to be unable to reproduce the problem on my home network. It is a
small (switched) 100BaseT network which is connected to the outside via an
asynchronous dsl line (128/768kbit). Maybe the different LAN topology or
the slow external link make the difference. I will retry on monday on the
corporate network. The latter is a large university net, with our section
consisting of 100BaseT-to-100BaseFX tranceiver switches. I do not have
information on the rest of the network.
> Also, to see what idle power saving states you have, their
> latency and their usage, please do this:
> cat /proc/acpi/processor/CPU0/power
betazed:~# cat /proc/acpi/processor/CPU1/power
active state: C2
default state: C1
bus master activity: ffffffff
C1: promotion[C2] demotion[--] latency usage
*C2: promotion[C3] demotion[C1] latency usage
C3: promotion[--] demotion[C2] latency usage
> It would also be interesting to know if you see the problem
> more frequently when running on battery power, since some
> systems have higher c-state exit latency when on battery.
I cannot say at this moment, since I cannot reproduce the problem at home
(see above). I will try to get some info on this matter on monday. Stay
> It would also be interesting to know if you see the same
> frequency of the problem on 2.4, since it has 100HZ clock
> vs 1000HZ clock on 2.6 -- and this can have a significant
> effect on the effectivness of idle c-states.
Will try to install a 2.4 kernel on the box and see what happens.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/