Bug #520

em(4) on thinkpad t60

Added by belczyk over 7 years ago. Updated over 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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

if_em_diff.txt Magnifier (734 Bytes) sepherosa, 01/18/2007 01:42 AM

History

#1 Updated by belczyk over 7 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 7 years ago

Ah, yeah, please test it or the attachment (same patch)

Best Regards,
sephe

#3 Updated by belczyk over 7 years ago

That was it.

#4 Updated by dillon about 7 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 7 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 7 years ago

Workaround committed, though performance is not great:

http://leaf.dragonflybsd.org/mailarchive/commits/2007-01/msg00320.html

#7 Updated by sepherosa over 5 years ago

patch committed

Also available in: Atom PDF