Bug #520
em(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
History
#1
Updated by belczyk over 11 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.
#2
Updated by sepherosa over 11 years ago
Ah, yeah, please test it or the attachment (same patch)
Best Regards,
sephe
#3
Updated by belczyk over 11 years ago
That was it.
#4
Updated by dillon about 11 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
#5
Updated by belczyk about 11 years ago
I haven't noticed any side effects caused by this patch, so I think it can be
committed.
#6
Updated by justin about 11 years ago
Workaround committed, though performance is not great:
http://leaf.dragonflybsd.org/mailarchive/commits/2007-01/msg00320.html
#7
Updated by sepherosa over 9 years ago
patch committed