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 19 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 19 years ago
      
    
    Ah, yeah, please test it or the attachment (same patch)
Best Regards,
sephe
      
      Updated by dillon almost 19 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 19 years ago
      
    
    I haven't noticed any side effects caused by this patch, so I think it can be
committed.
      
      Updated by justin almost 19 years ago
      
    
    Workaround committed, though performance is not great:
http://leaf.dragonflybsd.org/mailarchive/commits/2007-01/msg00320.html