Bug 218833 - hald forgets about wifi device after suspend
hald forgets about wifi device after suspend
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
Depends On:
  Show dependency treegraph
Reported: 2006-12-07 13:54 EST by Jeff Laughlin
Modified: 2013-03-05 22:48 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-06 13:08:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
NetworkManager --no-daemon output for normal start and post-resume (5.45 KB, text/plain)
2006-12-07 15:53 EST, Jeff Laughlin
no flags Details
output of syslog with hald running in verbose mode from execution through a system suspend/resume cycle (322.60 KB, text/plain)
2006-12-07 18:56 EST, Jeff Laughlin
no flags Details

  None (edit)
Description Jeff Laughlin 2006-12-07 13:54:19 EST
Description of problem:
After suspending (ACPI suspend to RAM), NetworkManager no longer recognizes my
wireless adapter. When NetworkManager starts at boot, in /var/log/messages it
reports that it is managing network interface ath0 (as well as eth0, my wired
interface) and succesfully connects to the wlan no prob. After suspend/resume,
NetworkManager reports in the log that it is managing eth0, but doesn't mention

I cannot be certain but I do not think it's a problem with the wifi driver
(madwifi, I tried the latest stable and snapshot releases) since I can still
manipulate the device with ifconfig and iwconfig and I can see the list of APs
with iwlist, even after resuming.

I've tried various quick fixes like unloading and reloading the drivers for the
card, restarting NetworkManager & the dispatcher, dhcdbd, etc. So far the only
solution is a reboot.

I had a similar problem in FC5 but restarting NetworkManager after resuming
would fix it.

Version-Release number of selected component (if applicable):

How reproducible:

Normal syslog output:
Dec  7 02:15:55 vm-fc6 NetworkManager: <information>    Now managing wired
Ethernet (802.3) device 'eth0'. 
Dec  7 02:15:55 vm-fc6 NetworkManager: <information>    Now managing wireless
(802.11) device 'ath0'. 

Syslog output after resume:
Dec  6 10:06:10 vm-fc6 NetworkManager: <information>    Now managing wired
Ethernet (802.3) device 'eth0'.
Comment 1 Jeff Laughlin 2006-12-07 15:53:38 EST
Created attachment 143089 [details]
NetworkManager --no-daemon output for normal start and post-resume
Comment 2 Jeff Laughlin 2006-12-07 18:51:29 EST
It now appears that this is in fact a bug in hald. lshal shows my ath0 adapter
after boot but not after resume. NetworkManager gets it's interface list from
hal and hal isn't reporting this interface as present. I restarted hald and now
ath0 shows up in lshal again and NetworkManager immediately resumes my wifi
connection so at least I have a workaround now (and there was much rejoicing (yay)).
Comment 3 Jeff Laughlin 2006-12-07 18:56:15 EST
Created attachment 143105 [details]
output of syslog with hald running in verbose mode from execution through a system suspend/resume cycle
Comment 4 Jeff Laughlin 2006-12-07 20:09:51 EST
I submitted this a bug on the hal bugzilla
Comment 5 Tim Niemueller 2007-01-06 07:07:32 EST
Just restarting hald with /etc/init.d/haldaemon restart fixes the problem
temporarily. But then programs like gnome-power-manager seem to loose contact
and status changes (like unplugging the laptop) are no longer recognized. Also
the battery status is no longer updated. Restarting g-p-m fixes this particular
problem. This seems also to wedge the support for USB storage devices, my
external crypto drives are no longer added or removed (no auto mount, still
visible after detaching in Nautilus/Computer). So after all it seems that
restarting hald is not a good idea. This should also be fixed to avoid having to
reboot after hal has been updated so that it can just be restarted. Having "You
should reboot your system" screens after such an upgrade is unacceptable, this
should be handle dynamically. Create new bug with this bad update behavior and
broken apps?
Comment 6 Tim Niemueller 2007-02-07 18:10:31 EST
Has there been any investigation on this or is there anything that could be done
to help to get this solved? I have also posted log output to the fdo bugzilla.
Comment 7 Kyrre Ness Sjøbæk 2007-02-18 17:02:24 EST
Hello, i am also seeing this bug. FC6, madwifi from livna. Restarting haldaemon
makes it come back. But gnome-power-manager seems to work (it disapears and then
reappears) and nautilus usb mounting are still mounting - so there are no "bad"
effects on running /etc/init.d/haldaemon restart on my system.

However, i'm having trouble with the card (or madwifi) crashing on resume. This
is easily fixable by rmmod'ing ath_pci, ath_rate_sample and ath_hal, and then
modprobing ath_pci.

But on my machine, its this unloading/loading of modules that makes hal loose
the card, not the suspend resume. After suspend/resume networkmanager tries to
reconnect, but runs trough all nettworks without sucess (as the card has
crashed). But the networks are still there (at least the ones that where there
on suspend). After unload/reload of modules and restart of NetworkManager, all
networks and any mention of wireless are gone!

Or not.

Strange - i just tried to unload/reload the modules this (after having played
with restarting hal a couple of times) - and it "just worked" - perfectly. Even
after retracting and folding out again my XJACK antenna, it said "disconnected"
and then, after folding it back out, the ligth came on, started flashing, i
select network, and *pof* everything is back-on-line.

Strange! Strange! Strange!

I'm saving, bookmarking, suspending, and coming back with more info...
Comment 8 Kyrre Ness Sjøbæk 2007-02-18 17:08:28 EST
Ok, this is what happened:

- Pushed suspend. NetworkManager disconnected, machine suspended.
- Waited a few secounds, and then hit suspend button. Machine resumed,
NetworkManager tries to reconnect. Doesn't work.
- Restarting hal. No difference.
- rmmod'ing madwifi. System modprobes it back autmatically.
- Cant connect
- Restarting hal. Everything works 100%, including retractable antenna.
Comment 9 Kyrre Ness Sjøbæk 2007-02-18 17:39:01 EST
Hmm - i found this on the bottom of
which looks to be the script that is actually handling the suspend (that is,
calling pm-suspend. And SOMEBODY should make pm-suspend not suspend when called
with the --help flag in order to get it to identify itself! Or at least add a

#Refresh devices as a resume can do funny things
for type in button battery ac_adapter
        devices=`hal-find-by-capability --capability $type`
        for device in $devices
                dbus-send --system --print-reply --dest=org.freedesktop.Hal \
                          $device org.freedesktop.Hal.Device.Rescan

Now for something even stranger: After accidentaly suspending by calling
pm-suspend, i didn't have to restart hal - now all i needed was to reload the
modules (that is: unload them so that they could be autoreloaded).

Now, what do i do? In ze old days, this was easy - adding a couple of lines in
the appropriate /etc/acpid/actions script, but now? Do i edit that script i
posted about higher up? I could try uncommenting those lines about batterys
etc., and i should definatly add that rmmod line - perhaps even before
pm-suspend gets called... Or just do it before the hal refresh. How do i get hal
to refresh networkcards as well (what to add to $devices)?
Comment 10 Kyrre Ness Sjøbæk 2007-02-19 03:46:34 EST
I "fixed" the problem by placing the line
rmmod ath_pci ath_rate_sample ath_hal
just above the code quoted in the last comment.

It now works pretty well, with the exception that i tries to reconnect before
the device is ready, so you have to manually reconnect.
Comment 11 Christopher Aillon 2007-03-05 09:47:31 EST
If you're going to want this fixed, please make sure you assign it to the right
Comment 12 Bug Zapper 2008-04-04 01:08:42 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 13 Bug Zapper 2008-05-06 13:08:07 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.