Created attachment 822646 [details]
lsmod   >  lsmod.txt

*** Bug 1028801 has been marked as a duplicate of this bug. ***

Thanks for the uploads.  Make things easier.

I see that the ath5k module is loaded. Kernel is 3.11.
[   11.069256] ath5k: phy0: Atheros AR5414 chip found (MAC: 0xa3, PHY: 0x61)

Appears you got associated prior to shutdown
[   10.071026] ath5k 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[   10.071798] ath5k 0000:03:00.0: registered as 'phy0'
...
[   11.017750] ath: EEPROM regdomain: 0x62
[   11.017755] ath: EEPROM indicates we should expect a direct regpair map
[   11.017759] ath: Country alpha2 being used: 00
[   11.017761] ath: Regpair used: 0x62
[   11.068167] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   11.069256] ath5k: phy0: Atheros AR5414 chip found (MAC: 0xa3, PHY: 0x61)
[   11.110356] systemd-udevd[701]: renamed network interface wlan0 to wls3
...

[  106.589727] wls3: authenticate with c8:6c:87:fe:d5:38
[  106.592851] wls3: send auth to c8:6c:87:fe:d5:38 (try 1/3)
[  106.595856] wls3: authenticated
[  106.597070] wls3: associate with c8:6c:87:fe:d5:38 (try 1/3)
[  106.599800] wls3: RX AssocResp from c8:6c:87:fe:d5:38 (capab=0x411 status=0 aid=1)
[  106.600424] wls3: associated
[  106.600473] IPv6: ADDRCONF(NETDEV_CHANGE): wls3: link becomes ready
[  139.390440] wls3: deauthenticating from c8:6c:87:fe:d5:38 by local choice (reason=3)
[  139.392470] cfg80211: Calling CRDA to update world regulatory domain
[  139.410550] cfg80211: World regulatory domain updated:
[  139.410556] cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[  139.410559] cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[  139.410562] cfg80211:   (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[  139.410565] cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[  139.410568] cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[  139.410571] cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)

Shutdown begins..
[  140.300469] PM: Syncing filesystems ... done.
[  140.343370] PM: Preparing system for mem sleep
[  141.155614] Freezing user space processes ... (elapsed 0.001 seconds) done.

Upon resume, it appears the systemd that would be involved bringing up things has an app crash:
[  144.050461] PM: Finishing wakeup.
[  144.050464] Restarting tasks ... 
[  144.050758] traps: systemd[1] general protection ip:b738e3c0 sp:bffd2d0c error:0
[  144.050772]  in libc-2.18.so[b7377000+1b8000]

Suggest you update your version of systemd package and see if you can get past the general protection issue, and then see what that will buy you.  System services won't get restored as a consequence, but no idea where it dies and what remains to restore.  If that doesn't help the crash, I'd kick this BZ over to systemd folks to help you out.  I don't see the wifi get brought back at the end of the log, expect it may be part of the work items that remain to be completed.

There was a suspend/resume issue on i686 that was causing systemd to segfault like that.  It should be fixed in the 3.11.6-302 or 3.11.7-300 kernels.  Try updating to those first.

ok with
kernel-3.11.7-100.fc18.i686
in F18

I do not konw how to test in F20.  I am not yet ready to install F29 on my laptop.

(In reply to Flóki Pálsson from comment #5)
> ok with
> kernel-3.11.7-100.fc18.i686
> in F18
> 
> I do not konw how to test in F20.  I am not yet ready to install F29 on my
> laptop.

So I understand this:  your dmesg shows the kernel is 3.11.6-301.fc20.i686.
"Ok with  kernel-3.11.7-100.fc18.i686"  means you don't see the issue on a f18 system with a higher level kernel, but you do see the issue with f20 on 3.11.6-301.fc20.i686 in live CD?  It would appear the issue is fix from a kernel standpoint.  Can you confirm I understand correctly?

If you wish to stay on f18 and just reported the issue, we appreciate the report and will tend to it, if it's not already fixed in next minor kernel release.


It would appear that the next logical step would be (when you are ready) to got to f20, to begin with at least 3.11.7 kernel.

John, Flóki originally opened this bug against F18, which suffered from the same bug that was crashing systemd.  That F18 bug was duped to this one when he opened it after trying F20.  I believe the bug is fixed in both F18 and F20 now with the same kernel fix (and F19 for that matter.

Closing this out as fixed since 3.11.7 in all versions should resolve the issue.  Flóki, if you see this with a kernel newer than 3.11.7, please reopen.

This is ok now.