[DragonFlyBSD - Bug #933] (Feedback) em(4) hardware error after ACPI suspend

[Antonio M. Huete Jimenez via Redmine]

Issue #933 has been updated by tuxillo.

Description updated
Status changed from New to Feedback
Assignee set to sepherosa

Hi Sephe,

I've assigned it to you (as per your last comment).
I would suppose this is not relevant anymore since em(4) has been updated several times in the last 4 years.

Cheers,
Antonio Huete
----------------------------------------
Bug #933: em(4) hardware error after ACPI suspend
http://bugs.dragonflybsd.org/issues/933

Author: matthias
Status: Feedback
Priority: Normal
Assignee: sepherosa
Category: 
Target version: 


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.

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

ath0 at pci2:2:0:  class=0x020000 card=0x833117ab chip=0x1014168c rev=0x01
hdr=0x00
    vendor   = 'Atheros Communications Inc.'
    device   = 'AR5212 Atheros AR5212 802.11abg wireless

em0 at pci2:1:0:   class=0x020000 card=0x05491014 chip=0x101e8086 rev=0x03
hdr=0x00
    vendor   = 'Intel Corporation'
    device   = '82540EP Gigabit Ethernet Controller (Mobile)'

Regards

	Matthias


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account