On Jan 27, 2008 3:38 AM, Matthias Schmidt <[EMAIL PROTECTED]> wrote: > He, > > since today I have an IBM Thinkpad T42 here. The machine is equipped > with a em(4) NIC and a ath(4) wireless NIC. After testing ACPI suspend > to RAM (state 3) which works flawlessly, I noticed some errors right > after the resume: > > device_probe_and_attach: em0 attach returned 5 > em0: <Intel(R) PRO/1000 Network Connection, Version - 6.2.9> port > 0x8000-0x803f mem 0xc0200000-0xc020ffff,0xc0220000-0xc023ffff irq 11 at > device 1.0 on pci2 > can't re-use a leaf (debug_info)! > can't re-use a leaf (stats)! > can't re-use a leaf (rx_int_delay)! > can't re-use a leaf (tx_int_delay)! > can't re-use a leaf (rx_abs_int_delay)! > can't re-use a leaf (tx_abs_int_delay)! > can't re-use a leaf (int_throttle_ceil)! > can't re-use a leaf (rxd)! > can't re-use a leaf (txd)! > em0: The EEPROM Checksum Is Not Valid > em0: Unable to initialize the hardware > device_probe_and_attach: em0 attach returned 5 > > Why does the EEPROM checksum changes during a suspend/resume cycle? Is > it possible to suspend with this card? This error also happens if I > unload the modules right before the suspend and load it again after > resume.
Intel does only one eeprom checksum upon em_attach() in their new driver, but I don't think that will solve your problem; I suspect all of the devices' BAR is complete trashed after suspend/resume. Could you apply following patch and post the debug prints? http://leaf.dragonflybsd.org/~sephe/em_test.diff The read back value should not be 0xffffffff > > An error also happens with the ath(4). If I don't unload the driver, > the card no longer gets an IP address from the DHCP server. > Loading/Unloading etc won't help. > > A third error happens with USB stuff. If I don't unload the USB module > I see a continuously stream of the following messages: > > Jan 26 19:44:26 jupiter acpi: resumed at 20080126 19:44:26 > Jan 26 19:44:27 jupiter kernel: uhub0: port 1 reset failed > Jan 26 19:44:27 jupiter kernel: uhub1: port 1 reset failed > Jan 26 19:44:27 jupiter kernel: uhub2: port 1 reset failed > Jan 26 19:44:28 jupiter kernel: uhub0: port 2 reset failed > Jan 26 19:44:28 jupiter kernel: uhub1: port 2 reset failed > Jan 26 19:44:28 jupiter kernel: uhub2: port 2 reset failed > Jan 26 19:44:30 jupiter kernel: uhub0: port 1 reset failed > Jan 26 19:44:30 jupiter kernel: uhub1: port 1 reset failed > Jan 26 19:44:30 jupiter kernel: uhub2: port 1 reset failed > [...] > > Only rebooting the machine helps. Append the relevant information: > > > DragonFly jupiter 1.11.0-DEVELOPMENT DragonFly 1.11.0-DEVELOPMENT #1: > Sat Jan 26 20:05:28 CET 2008 > > [EMAIL PROTECTED]:2:0: class=0x020000 card=0x833117ab chip=0x1014168c > rev=0x01 > hdr=0x00 > vendor = 'Atheros Communications Inc.' > device = 'AR5212 Atheros AR5212 802.11abg wireless > > [EMAIL PROTECTED]:1:0: class=0x020000 card=0x05491014 chip=0x101e8086 > rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82540EP Gigabit Ethernet Controller (Mobile)' -- Live Free or Die
