'Frozen' network after resuming from sleep

[shvehlava]

Hello! I've ran into a different type of a network issue, most likely related to hardware.

I settled on an older machine to test how usable a 20 year old computer can be nowadays, and to report on tools that can make it a pleasant experience, even if one is ultimately abandoning the 'joys' of the modern web. Those most comfortable with the command prompt already know that hardware limitations are something that can still be avoided with the right bug out kit and 512MB of RAM.

Anyway, I'm running OpenBSD 6.9 i386, and the only somewhat annoying issue is that after I put the computer to sleep `zzz` or close the lid, after I wake it up, there's no way to get working ethernet connection.

The interface em0 appears in ifconfig and reports the previous connection (ie: the one before sleep). Ping and netstat appear frozen - there's nothing. Unless I `ifconfig em0 down`, then ping shows the usual 'not connected.'

I can `ifconfig em0 up` again, to no avail. ifconfig does report whether a carrier is present correctly though and the light by the port works.

Running `sh /etc/netstart/` gives me: 'no lease...sleeping'.

as for any messages, all I get is an occasional line in dmesg 'em0: watchdog: head 448 tail 0 TDH 448 TDT 448'.

Any ideas would be appreciated. I figured it might be related to some power issue, I checked IRQ in bios, as that resolved a similar issue with the wifi interface when I was trying to debug what doesn't work initially.

Thank you!

[jggimi]

To my understanding, "down" and "up" are logical states; they do not change physical status.

Clearly, your em(4) NIC is not responding as expected due to the watchdog timout message.

When an OS hardware driver sends a command to hardware where a response is expected, it sets a watchdog timer. If the hardware does not respond by the timer's expiration, the driver then performs any corrective action and logs the timeout message. https://en.wikipedia.org/wiki/Watchdog_timer

Your problem could be OS-related, BIOS-related, or hardware-related.

I'd check to see if your system has a more recent BIOS available from the vendor. I'd also double-check to see if the CPU/CPUs is/are 64-bit capable with $ dmesg | grep LONG, as the amd64 architecture may perform differently than i386.

[shvehlava]

I've updated BIOS. Unfortunately this did not solve the problem. I'll try a different OS just to see if the issue replicates, but maybe getting a different modem card could resolve the issue for OpenBSD, though I do not know if the machine won't protest, should it interface with an alien card. I've encountered such protests while replacing wifi-cards in laptops before.

Thanks for now!

[shvehlava]

I tested with debian and the issue is not present there :/

[jggimi]

Then the problem is OS-related in some way. Consider posting an informal query to the misc@ mailing list, but better would be a formal report to the bugs@ list.

http://www.openbsd.org/report.html