Bug #520
closedem(4) on thinkpad t60
0%
Description
Hello,
after replacing my workstation (R40e) with T60 I noticed the following
problems regarding em(4) device:
1. If {em0, pcib2} interrupts are set to X in the bios and {pcib1, pci1(ATI),
uhci0, cbb0} interrupts are set to Y, then I get livelock from interrupt Y
after bringing em0 up. When they're set to the same value it works fine.
2. The em0 interface can't be configured unless the cable is plugged in
(probably a known issue).
3. Network connections work very slowly unless polling(4) is enabled for em0:
ping from another machine in my home lan (100Mbps):
envy# ping c 5 grazer
PING grazer.bsd.krakow.pl (10.0.0.5): 56 data bytes
64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=818.905 ms
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=693.269 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=793.187 ms
64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=783.224 ms
64 bytes from 10.0.0.5: icmp_seq=4 ttl=64 time=773.265 ms
-- grazer.bsd.krakow.pl ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 693.269/772.370/818.905/42.366 ms
other way round is better:
grazer# ping c 5 envy
PING envy.bsd.krakow.pl (10.0.0.100): 56 data bytes
64 bytes from 10.0.0.100: icmp_seq=0 ttl=64 time=0.535 ms
64 bytes from 10.0.0.100: icmp_seq=1 ttl=64 time=0.490 ms
64 bytes from 10.0.0.100: icmp_seq=2 ttl=64 time=0.459 ms
64 bytes from 10.0.0.100: icmp_seq=3 ttl=64 time=0.426 ms
64 bytes from 10.0.0.100: icmp_seq=4 ttl=64 time=0.397 ms
-- envy.bsd.krakow.pl ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.397/0.461/0.535/0.048 ms
With polling enabled I get:
envy# ping c 5 grazer
PING grazer.bsd.krakow.pl (10.0.0.5): 56 data bytes
64 bytes from 10.0.0.5: icmp_seq=0 ttl=64 time=2.030 ms
64 bytes from 10.0.0.5: icmp_seq=1 ttl=64 time=7.755 ms
64 bytes from 10.0.0.5: icmp_seq=2 ttl=64 time=7.914 ms
64 bytes from 10.0.0.5: icmp_seq=3 ttl=64 time=8.072 ms
64 bytes from 10.0.0.5: icmp_seq=4 ttl=64 time=8.227 ms
-- grazer.bsd.krakow.pl ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.030/6.800/8.227/2.390 ms
and the other way round:
grazer# ping c 5 envy
PING envy.bsd.krakow.pl (10.0.0.100): 56 data bytes
64 bytes from 10.0.0.100: icmp_seq=0 ttl=64 time=0.233 ms
64 bytes from 10.0.0.100: icmp_seq=1 ttl=64 time=0.398 ms
64 bytes from 10.0.0.100: icmp_seq=2 ttl=64 time=0.501 ms
64 bytes from 10.0.0.100: icmp_seq=3 ttl=64 time=0.620 ms
64 bytes from 10.0.0.100: icmp_seq=4 ttl=64 time=0.233 ms
-- envy.bsd.krakow.pl ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.233/0.397/0.620/0.151 ms
Tested on both UP and SMP kernels (on SMP+APIC_IO em0 doesn't work and reports
watchdog timeouts). My dmesg and kernel config are at
http://www.bsd.krakow.pl/grazer/
If you need more information I'm ready to help.
4. Setting
kern.polling.enable=1 in /etc/sysctl.conf and
ifconfig_em0="inet ... polling" in /etc/rc.conf
doesn't seem to have any effect after reboot and I have to manually do that
via "ifconfig em0 polling".
Now I'm going to test the intel wireless device :-)
TIA
Files
Updated by belczyk almost 18 years ago
[...]
I wonder if it's the same hardware bug as on X60 -- I'll test the workaround
posted to freebsd-current few minutes ago and let you know.
Updated by sepherosa almost 18 years ago
Ah, yeah, please test it or the attachment (same patch)
Best Regards,
sephe
Updated by dillon almost 18 years ago
We aren't going to be able to address the interrupt routing issues
this release... and in fact it will probably be a thorn in our sides
for a very long time. But fortunately we have a number of workarounds
that will make those laptops useable.
The network interface polling and/or the emergency interrupt polling
feature will just have to be used. I know it isn't an optimal solution,
I know, but it isn't a bad one either.
-Matt
Updated by belczyk almost 18 years ago
I haven't noticed any side effects caused by this patch, so I think it can be
committed.
Updated by justin almost 18 years ago
Workaround committed, though performance is not great:
http://leaf.dragonflybsd.org/mailarchive/commits/2007-01/msg00320.html