[FIXED]Last kernel update sleep/resume failure

WorMzy · 2013-10-02 19:52:51

I'm guessing that that's either a coincidence, or this behaviour doesn't exhibit itself all the time. Like I said earlier, the only difference between 3.11.1-1 and 3.11.1-2, was a patch to fix a network module regression.

https://projects.archlinux.org/svntogit … 7bfcfd8dea

dagon666 · 2013-10-04 09:09:03

does the newest systemd-208 fixes the issue ? I haven't yet checked

yetanothergeek · 2013-10-04 09:13:50

dagon666 wrote:

does the newest systemd-208 fixes the issue?

208 is still broken for me.
.

agumonkey · 2013-10-04 14:47:38

There's no report of progress since https://bugzilla.kernel.org/show_bug.cgi?id=61781#c19 but they seem close so ..

dagon666 · 2013-10-05 10:11:21

Unfortunately most recent updates, providing linux-3.11.3-1 and systemd 208 still don't bring any improvements. I just checked.

Last edited by dagon666 (2013-10-05 10:11:39)

agumonkey · 2013-10-05 11:25:48

yeah still no concrete steps for this bug. But I'm curious if services or modules aren't involved too. I recently reinstalled arch from scratch in a smaller setup and it's been many days since I had the slightest issue. Maybe we should compare what's loaded.

dagon666 · 2013-10-05 11:44:51

I noticed this error after resuming and getting dropped to the console:

[drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode .flags (expected 2, found 0)

Additionally I found a lot of backtraces in dmesg, related to the intel graphics (now don't laugh, my machine is a little bit old):

[ 5936.906208] ------------[ cut here ]------------
[ 5936.906258] WARNING: CPU: 1 PID: 340 at drivers/gpu/drm/i915/intel_display.c:8292 check_crtc_state+0x590/0xb30 [i915]()
[ 5936.906262] pipe state doesn't match!
[ 5936.906266] Modules linked in: cdc_acm fuse joydev btusb bluetooth iTCO_wdt coretemp iTCO_vendor_support uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media pcmcia snd_hda_codec_realtek i2c_i801 microcode psmouse arc4 iwl3945 iwlegacy serio_raw yenta_socket snd_hda_intel mac80211 pcmcia_rsrc of_i2c snd_hda_codec pcmcia_core toshiba_acpi snd_hwdep cfg80211 lpc_ich sparse_keymap snd_pcm r8169 snd_page_alloc snd_timer snd soundcore wmi toshiba_bluetooth mii rfkill ac battery shpchp evdev acpi_cpufreq mperf processor vboxnetflt(O) vboxnetadp(O) vboxdrv(O) loop nfs lockd sunrpc fscache ext4 crc16 mbcache jbd2 sr_mod cdrom sd_mod ata_generic pata_acpi ahci libahci ata_piix sdhci_pci libata scsi_mod sdhci mmc_core tifm_7xx1 tifm_core firewire_ohci firewire_core crc_itu_t uhci_hcd ehci_pci
[ 5936.906372]  ehci_hcd usbcore usb_common i915 video button i2c_algo_bit intel_agp intel_gtt drm_kms_helper drm agpgart i2c_core
[ 5936.906396] CPU: 1 PID: 340 Comm: X Tainted: G        W  O 3.11.3-1-ARCH #1
[ 5936.906400] Hardware name: TOSHIBA Satellite A200/ISKAA, BIOS V1.70 09/27/2007
[ 5936.906405]  00000000 00000000 f2e7d8b0 c141bcff f2e7d8f0 f2e7d8e0 c104560e f87b49b9
[ 5936.906418]  f2e7d90c 00000154 f87ac414 00002064 f87682a0 f87682a0 f5015650 f5015000
[ 5936.906430]  0000000a f2e7d8f8 c1045663 00000009 f2e7d8f0 f87b49b9 f2e7d90c f2e7db60
[ 5936.906442] Call Trace:
[ 5936.906454]  [<c141bcff>] dump_stack+0x4b/0x79
[ 5936.906465]  [<c104560e>] warn_slowpath_common+0x7e/0xa0
[ 5936.906498]  [<f87682a0>] ? check_crtc_state+0x590/0xb30 [i915]
[ 5936.906527]  [<f87682a0>] ? check_crtc_state+0x590/0xb30 [i915]
[ 5936.906535]  [<c1045663>] warn_slowpath_fmt+0x33/0x40
[ 5936.906566]  [<f87682a0>] check_crtc_state+0x590/0xb30 [i915]
[ 5936.906605]  [<f8771ee3>] intel_modeset_check_state+0x2a3/0x760 [i915]
[ 5936.906642]  [<f8772430>] intel_set_mode+0x30/0x40 [i915]
[ 5936.906671]  [<f8773540>] intel_get_load_detect_pipe+0x230/0x3a0 [i915]
[ 5936.906710]  [<f87928b7>] intel_tv_detect+0xe7/0x4a0 [i915]
[ 5936.906729]  [<f805371b>] ? drm_get_edid+0x2b/0x270 [drm]
[ 5936.906744]  [<f84d9448>] drm_helper_probe_single_connector_modes+0x1b8/0x340 [drm_kms_helper]
[ 5936.906774]  [<f804efe5>] drm_mode_getconnector+0x305/0x350 [drm]
[ 5936.906799]  [<f804ece0>] ? drm_mode_getcrtc+0xc0/0xc0 [drm]
[ 5936.906815]  [<f8041c5a>] drm_ioctl+0x49a/0x540 [drm]
[ 5936.906840]  [<f9246300>] ? ext4_file_write+0xd0/0x470 [ext4]
[ 5936.906858]  [<f804ece0>] ? drm_mode_getcrtc+0xc0/0xc0 [drm]
[ 5936.906877]  [<f80417c0>] ? drm_copy_field+0x70/0x70 [drm]
[ 5936.906886]  [<c11624e6>] do_vfs_ioctl+0x2e6/0x4e0
[ 5936.906893]  [<c1154971>] ? __sb_end_write+0x31/0x70
[ 5936.906901]  [<c1152d75>] ? vfs_write+0x185/0x1c0
[ 5936.906908]  [<c116ac8f>] ? fget_light+0x6f/0xc0
[ 5936.906915]  [<c116275f>] SyS_ioctl+0x7f/0x90
[ 5936.906924]  [<c142858d>] sysenter_do_call+0x12/0x28
[ 5936.906929] ---[ end trace 7be6bafc2ee5fdff ]---

I suspect this may be related with the recent switch from UXA to SNA.

yetanothergeek · 2013-10-05 12:05:37

dagon666 wrote:

now don't laugh, my machine is a little bit old

Don't feel too bad dagon666, since this bug only seems to affect i686, i suspect most people on this thread are in the same boat.

But I believe I'm pretty much done with systemd for a while. I've had too many problems with it so I switched over to busybox for init and pm-utils for suspend.
IMO, systemd is way too complex and has far too many inter-dependencies to be a reliable /proc/1/exe.

Using busybox instead of systemd means getting my hands a bit more dirty, but hey, that's why I switched to ArchLinux in the first place!

agumonkey · 2013-10-05 12:31:27

@yetanothergeek: but it's been said this bug is out of systemd.

@dagon666: as yetanothergeek wrote, we probably all have ~old machines. Mine is from 2006. I don't have stack traces anymore, before reinstalling I had tcp stacktraces though.

yetanothergeek · 2013-10-05 12:42:47

@agumonkey: Blame the bug on who you want - systemd crashes and won't let me do clean reboot, busybox + pm-utils doesn't have that problem.

agumonkey · 2013-10-05 14:27:46

yetanothergeek wrote:

@agumonkey: Blame the bug on who you want - systemd crashes and won't let me do clean reboot, busybox + pm-utils doesn't have that problem.

I'm just saying, busybox may just be lucky not triggering the bug. Just like the strace trick to induce different timing in systemd

yetanothergeek · 2013-10-05 14:39:53

You're right, it's entirely possible that the next kernel bug (assuming that's really what this is) might crash busybox and leave systemd alone.

But my point is that most other init/service systems (sysvinit,openrc,etc.) don't depend on some fragile "connection to D-Bus" in order to interact with the OS.

Anyway, I guess this is getting off-topic, sorry...

4javier · 2013-10-06 10:50:51

I can confirm that problem is still there with kernel 3.11.4-1, now in testing.

ott 06 12:38:10 Archbox kernel: traps: systemd[1] general protection ip:b75ba070 sp:bffd5ff0 error:0
ott 06 12:38:10 Archbox kernel:  in libc-2.18.so[b7549000+1a9000]
ott 06 12:38:10 Archbox kernel: done.
ott 06 12:38:10 Archbox systemd[1]: Caught <SEGV>, dumped core as pid 865.
ott 06 12:38:10 Archbox systemd[1]: Freezing execution.
ott 06 12:38:10 Archbox systemd-coredump[868]: Process 865 (systemd) dumped core.
ott 06 12:38:10 Archbox systemd-cgroups-agent[870]: Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused

This happened after the first suspend in session. With previous kernels I could suspend 3-4 times before issue occurs. However, I tried just once, then I don't now if this has been just by chance.

agumonkey · 2013-10-07 13:32:24

@4javier as people said earlier, it's related to concurrency so the "right" condition for the bug to happen may only happen once in a while. I now watch the archlinux kernel changelog here https://projects.archlinux.org/svntogit … ages/linux to see if anything major changes. With https://bugzilla.kernel.org/show_bug.cgi?id=61781#c19 too. So I'm not surprised the bug is still present. I guess we're lucky that the bug is still limited and that we can interact with the graphical session enough to shut the programs correctly, sync and `reboot -f`

awagner · 2013-10-07 15:13:42

anyone with some experience in kernel development can shed some light on why the bug is still on Status:NEEDINFO - is the information not sufficient yet?

WorMzy · 2013-10-07 20:23:17

awagner wrote:

anyone with some experience in kernel development can shed some light on why the bug is still on Status:NEEDINFO - is the information not sufficient yet?

Aaron Lu 2013-09-26 21:40:46 UTC
I'm on vocation from 09/27-10/07, probably no internet access so expect no response from me, sorry for the inconvenience.

Probably has something to do with it, though I couldn't say why the assignee hasn't responded yet..

awagner · 2013-10-07 21:38:24

WorMzy wrote:

Aaron Lu 2013-09-26 21:40:46 UTC
I'm on vocation from 09/27-10/07, probably no internet access so expect no response from me, sorry for the inconvenience.
Probably has something to do with it, though I couldn't say why the assignee hasn't responded yet..

Ah, right. I didn't remember this. So let's hope for the rest of the week

pepi55 · 2013-10-12 20:01:04

after hours of ferociously trying to get past the registration question, I'm finally here!!

anyway i need help with the provided standby script if anyone is willing to help:
I'm on a D620 dell laptop and can confirm the bug with the latest updates (kernel: Linux 3.11.4-1-ARCH, systemd: 208-1).
Also the script does indeed work for me too.

Now, for what i want to do: I want to use the script when closing the laptop lid. I have looked at /etc/acpi/handler.sh but im afraid that "systemctl suspend" refers to the handler.sh and will create an endless loop.

I'm quite new to linux and arch linux in general (have used ubuntu variants, mint, chakra and some other distro's before but never really got further with the terminal than with arch right now).

If it helps: Im using xmonad without any DE's or fancy stuff (I'd like to keep it minimal since this thing runs hot even with xmonad only).
the reason for this info is because my fn+esc ectivates hibernation and i have overwritten this option in xmonad.hs with the execution of the script and it standbies flawlessly (standbies is now a word ).

Now i need to get it to work as flawlessly with closing the laptop lid.

EDIT: i noticed recently that the script does not work 100% of the time....

thanks in advance

-Pepi

Last edited by pepi55 (2013-10-12 22:25:09)

mrinx · 2013-10-12 21:02:00

Oh boy... You can set HandleLidSwitch to ignore in /etc/systemd/logind.conf and then take care of it in /etc/acpi/handler.sh. I believe that systemd doesn't really care how you control closing the lid in other files.

pepi55 · 2013-10-12 22:33:33

mrinx wrote:

Oh boy... You can set HandleLidSwitch to ignore in /etc/systemd/logind.conf and then take care of it in /etc/acpi/handler.sh. I believe that systemd doesn't really care how you control closing the lid in other files.

Thanks! this is my the line right?

#HandleLidSwitch=suspend

thing is though, that it was already commented and i havent touched it.

Trilby · 2013-10-12 22:51:54

So uncomment it and set it to ignore instead of suspend. The commented values are the defaults.

pepi55 · 2013-10-13 01:53:09

Trilby wrote:

So uncomment it and set it to ignore instead of suspend. The commented values are the defaults.

thanks for the info but it doesnt work

HandleLidSwitch=ignore

doesnt disable suspend on lid closure. which it should because that means it isnt called anywhere else. i guess it has something to do with the bios.

anyway were getting quite offtopic here xD
I will look at it myself and probably create a new topic if i need any help but thanks for the help anyway!

mrinx · 2013-10-13 02:02:45

pepi55 wrote:

HandleLidSwitch=ignore
doesnt disable suspend on lid closure. which it should because that means it isnt called anywhere else. i guess it has something to do with the bios.

You have to restart some service I think.

Try "systemctl restart systemd-logind.service", or just reboot your 'puter

pepi55 · 2013-10-13 11:08:53

mrinx wrote:

You have to restart some service I think.
Try "systemctl restart systemd-logind.service", or just reboot your 'puter

well at first i tried to do it right after modifying logind but it failed so i had to restart to get systemd again. after the reboot i tried it again with no success
thanks though

Last edited by pepi55 (2013-10-13 11:09:38)

mrinx · 2013-10-13 15:43:24

pepi55 wrote:

well at first i tried to do it right after modifying logind but it failed so i had to restart to get systemd again. after the reboot i tried it again with no success
thanks though

Yeah, we are offtopic here, so maybe you should start own thread with this problem. Anyway, if your /etc/systemd/logind.conf contains line HandleLidSwitch=ignore (without # at the begining), and if the service who cares about this is respecting it (I'm guessing it's systemd-logind.service), then it should be ignored and if you close your lid, then nothing should happen. If something happens, then there is something else listening to this action and reacting accordingly, did you install acpid because that could be it?

Arch Linux

#51 2013-10-02 19:52:51

Re: [FIXED]Last kernel update sleep/resume failure

#52 2013-10-04 09:09:03

Re: [FIXED]Last kernel update sleep/resume failure

#53 2013-10-04 09:13:50

Re: [FIXED]Last kernel update sleep/resume failure

#54 2013-10-04 14:47:38

Re: [FIXED]Last kernel update sleep/resume failure

#55 2013-10-05 10:11:21

Re: [FIXED]Last kernel update sleep/resume failure

#56 2013-10-05 11:25:48

Re: [FIXED]Last kernel update sleep/resume failure

#57 2013-10-05 11:44:51

Re: [FIXED]Last kernel update sleep/resume failure

#58 2013-10-05 12:05:37

Re: [FIXED]Last kernel update sleep/resume failure

#59 2013-10-05 12:31:27

Re: [FIXED]Last kernel update sleep/resume failure

#60 2013-10-05 12:42:47

Re: [FIXED]Last kernel update sleep/resume failure

#61 2013-10-05 14:27:46

Re: [FIXED]Last kernel update sleep/resume failure

#62 2013-10-05 14:39:53

Re: [FIXED]Last kernel update sleep/resume failure

#63 2013-10-06 10:50:51

Re: [FIXED]Last kernel update sleep/resume failure

#64 2013-10-07 13:32:24

Re: [FIXED]Last kernel update sleep/resume failure

#65 2013-10-07 15:13:42

Re: [FIXED]Last kernel update sleep/resume failure

#66 2013-10-07 20:23:17

Re: [FIXED]Last kernel update sleep/resume failure

#67 2013-10-07 21:38:24

Re: [FIXED]Last kernel update sleep/resume failure

#68 2013-10-12 20:01:04

Re: [FIXED]Last kernel update sleep/resume failure

#69 2013-10-12 21:02:00

Re: [FIXED]Last kernel update sleep/resume failure

#70 2013-10-12 22:33:33

Re: [FIXED]Last kernel update sleep/resume failure

#71 2013-10-12 22:51:54

Re: [FIXED]Last kernel update sleep/resume failure

#72 2013-10-13 01:53:09

Re: [FIXED]Last kernel update sleep/resume failure

#73 2013-10-13 02:02:45

Re: [FIXED]Last kernel update sleep/resume failure

#74 2013-10-13 11:08:53

Re: [FIXED]Last kernel update sleep/resume failure

#75 2013-10-13 15:43:24

Re: [FIXED]Last kernel update sleep/resume failure

Board footer