Bug 218833

Created attachment 143089 [details]
NetworkManager --no-daemon output for normal start and post-resume

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)).

Created attachment 143105 [details]
output of syslog with hald running in verbose mode from execution through a system suspend/resume cycle

I submitted this a bug on the hal bugzilla
https://bugs.freedesktop.org/show_bug.cgi?id=9281

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?

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.

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...

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.

Hmm - i found this on the bottom of
/usr/lib/hal/scripts/linux/hal-system-power-suspend-linux
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
manpage):

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

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)?

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.

If you're going to want this fixed, please make sure you assign it to the right
person.

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.
http://fedoraproject.org/wiki/LifeCycle/EOL

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:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

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

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.