kernel 2.6.39.1-1 issues: reboot no longer working

stripwax · 2011-06-14 23:37:11

I recently upgraded from kernel 2.6.38.7-1 to 2.6.39.1-1 , and have observed that this has caused reboot to no longer work. Specifically, issuing "reboot -n" kicks off the shutdown process ok, and I see the shutdown procedure getting broadcast to the interactive users, but this then hangs at the very last step, where it says Restarting.

This used to work fine, and I have confirmed that a downgrade back to 2.6.38.7-1 fixes this for me. All other packages from core and extra are up-to-date as of the time of this post.

The hardware is a fit-pc2 (i.e. intel atom-based). Is this a known upstream bug?

Last edited by stripwax (2011-06-16 20:35:25)

stlarch · 2011-06-15 03:22:14

Did you try "shutdown -r now" ?

stripwax · 2011-06-15 12:11:41

Yes, I tried that too, but that should behave identically to "reboot" since (as I understand it) reboot invokes shutdown. Do you know of a difference in the new kernel, that would make "shutdown -r now" more likely to work than "reboot"?

stlarch · 2011-06-15 16:51:48

I think it should do the same thing, I was just curious. Maybe give some more info so someone can help you better, like what DE or wm your using, did you install anything else or make any other changes around that time that might have something to do with it, and maybe check your logs for clues.

brebs · 2011-06-15 17:36:24

There's different reboot= kernel options.

See /usr/src/linux-2.6.39/arch/x86/kernel/reboot.c

/* reboot=b[ios] | s[mp] | t[riple] | k[bd] | e[fi] [, [w]arm | [c]old] | p[ci]
   warm   Don't set the cold reboot flag
   cold   Set the cold reboot flag
   bios   Reboot by jumping through the BIOS (only for X86_32)
   smp    Reboot by executing reset on BSP or other CPU (only for X86_32)
   triple Force a triple fault (init)
   kbd    Use the keyboard controller. cold reset (default)
   acpi   Use the RESET_REG in the FADT
   efi    Use efi reset_system runtime service
   pci    Use the so-called "PCI reset register", CF9
   force  Avoid anything that could hang.

stripwax · 2011-06-15 21:08:13

Thanks for replies.

@stlarch : what information would be most useful? Happy to provide whatever might be relevant. Hopefully the below helps
1. I use laptop-mode-tools with everything enabled even for AC power and acpi-cpufreq.
2. both "shutdown -r now" and "reboot" work fine if I downgrade just the kernel back to 2.6.38.7-1 . They both don't work (i.e. hang instead of reboot) if I upgrade just the kernel to 2.6.39.1-1
3. It's all worked out of the box for me for the last 6 months or so, and only the latest 2.6.39.1-1 kernel has this problem, hence why I suspect it's a regression.
4. Assuming wm means window manager: none. I don't even have X installed. This is purely a headless server, run unattended and rebooted (when necessary) remotely via ssh.
5. My dmesg reports "Selecting BIOS-method for reboots." - regardless of kernel version (i.e. when running both versions mentioned)
6. No clues in the logs unfortunately leap out to me. Let me know if there's a specific logfile that might have clues. With both a successful reboot (on older kernel) and failed reboot (on the newer kernel) the last few lines of everything.log say the same thing:

Jun 11 16:30:33 Xxxx shutdown[1600]: shutting down for system reboot
Jun 11 16:30:33 Xxxx init: Switching to runlevel: 6
Jun 11 16:30:34 Xxxx nmbd[1060]: [2011/06/11 16:30:34.651659, 0] nmbd/nmbd.c:71(terminate)
Jun 11 16:30:34 Xxxx nmbd[1060]: Got SIGTERM: going down...
Jun 11 16:30:35 Xxxx laptop-mode: Laptop mode
Jun 11 16:30:35 Xxxx laptop-mode: disabled, not active
Jun 11 16:30:36 Xxxx kernel: [ 1605.732274] r8169 0000:02:00.0: PME# enabled
Jun 11 16:30:36 Xxxx syslog-ng[522]: Termination requested via signal, terminating;
Jun 11 16:30:36 Xxxx syslog-ng[522]: syslog-ng shutting down; version='3.2.4'

@brebs: As above, this works/doesn't work dependent solely on version of kernel26 package. Is there a kernel change between those two versions that would require me changing my kernel options? I'd like to understand what caused the regression and see if there's an upstream fix (or raise it as an upstream issue if not), rather than just a reconfiguration/workaround.

stripwax · 2011-06-15 21:43:51

Some differences found comparing boot messages between the two kernels. Unfortunately I have no idea if (or which of) these messages might be clues.. Ignoring things that look simply like changed memory addresses/sizes:

New kernel logs " Base memory trampoline at [c008c000] 8c000 size 16384" message, old kernel does not.

With old kernel I get:

Jun 15 00:38:31 Xxxx kernel: [ 0.000000] PERCPU: Embedded 12 pages/cpu @f6800000 s27392 r0 d21760 u4194304
Jun 15 00:38:31 Xxxx kernel: [ 0.000000] pcpu-alloc: s27392 r0 d21760 u4194304 alloc=1*4194304
[...]
Jun 15 00:38:31 Xxxx kernel: [ 0.015793] ACPI: Core revision 20110112
[...]
Jun 15 00:38:31 Xxxx kernel: [ 0.210916] pci0000:00: Requesting ACPI _OSC control (0x1d)
Jun 15 00:38:31 Xxxx kernel: [ 0.220376] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 *7 10 12 14 15)
[...]

versus

Jun 15 00:09:53 Xxxx kernel: [ 0.000000] PERCPU: Embedded 12 pages/cpu @f6800000 s27648 r0 d21504 u4194304
Jun 15 00:09:53 Xxxx kernel: [ 0.000000] pcpu-alloc: s27648 r0 d21504 u4194304 alloc=1*4194304
[...]
Jun 15 00:09:53 Xxxx kernel: [ 0.016185] ACPI: Core revision 20110316
Jun 15 00:09:53 Xxxx kernel: [ 0.024900] ftrace: allocating 15225 entries in 30 pages
[...]
Jun 15 00:09:53 Xxxx kernel: [ 0.091934] PM: Registering ACPI NVS region at 3f6bd000 (12288 bytes)
[...]
Jun 15 00:09:53 Xxxx kernel: [ 0.096910] print_constraints: dummy:
[...]
Jun 15 00:09:53 Xxxx kernel: [ 0.237555] pci0000:00: Requesting ACPI _OSC control (0x1d)
Jun 15 00:09:53 Xxxx kernel: [ 0.237668] Unable to assume _OSC PCIe control. Disabling ASPM
Jun 15 00:09:53 Xxxx kernel: [ 0.246871] ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 *7 10 12 14 15)
[...]

After that it gets pretty difficult to track real differences but nothing obviously jumps out at me.

Out of the above I'm guessing "unable to assume _OSC PCIe control. Disabling ASPM" might be relevant ; since it looks like something unexpected being logged and only appears on the new kernel?

stlarch · 2011-06-16 03:37:35

I'm just stabbing in the dark, but if you haven't done so already, did you check for .pacnew files when you upgraded? There have been some recent changes, notably to rc.conf concerning network and modules. Otherwise, I'm not really sure. There is more info on the home page in the latest news section. I'm using the same kernel(2.6.39.1-1) and I haven't had any problems rebooting.

stripwax · 2011-06-16 09:17:12

Not helpful unfortunately. I'll double check the .pacnew files but I'm pretty certain the network and modules changes are unrelated (given that the behaviour can be triggered by *only* changing the kernel26 package).

Maybe this is the wrong place to have posted my question (maybe it's a "kernel issue" rather than a "kernel26 package issue"?). I've reposted this in the "kernel and hardware" forums, where I saw a similar (so possibly related) issue.

skodabenz · 2011-06-16 11:37:23

@stripwax: Are you using an UEFI system?

stripwax · 2011-06-16 11:41:40

No.

stripwax · 2011-06-16 19:59:51

I also commented on the following: https://bbs.archlinux.org/viewtopic.php?id=120965 but thinking some more I think that issue is unrelated to mine. kernel.org bug 33302 sounds *exactly* like my issue - other than 33302 reportedly 'fixed'. Significantly:

2.6.38.7-1 : "shutdown -r now" and "shutdown -h now" both work as expected. shutdown -h powers down.
2.6.39.1-1 : "shutdown -r now" hangs. "shutdown -h now" actually works fine for me and powers down fine.

.. just like #33302.

[Edit] opened a kernel issue: https://bugzilla.kernel.org/show_bug.cgi?id=37712

Last edited by stripwax (2011-06-16 20:52:30)

remote · 2011-06-17 22:38:39

I also have this issue which is no fun when the systems are remote.
Perhaps it's Atom related? 2.6.39-ARCH #1 SMP PREEMPT Mon Jun 6 22:37:55 CEST 2011 x86_64 Intel(R) Atom(TM) CPU D525 @ 1.80GHz GenuineIntel GNU/Linux

Last edited by remote (2011-06-17 22:43:38)

stlarch · 2011-06-18 03:56:42

I should have said that I too have an Atom. It's an older one though, N270, on a MSI Wind U100, and I haven't had any problems.

stripwax · 2011-06-18 07:49:46

@Remote: check your dmesg. Does it say using BIOS method for reboot?
@stlarch: check yours too. I suspect yours is NOT using bios method for reboot.

Interesting that Remote's system is x64. The original kernel issue (fixed during 2.6:39 rc5 or thereabouts) was x86 only i think. So maybe we're seeing a new/different bug albeit with same symptoms

remote · 2011-06-18 19:39:47

@stripwax: I did not see anything saying such, yet dmesg is rather long for manual search. Did you have a particular syntax for me to use other than the following?

[root@b ~]# dmesg |less
[root@b ~]# dmesg |grep reboot
[root@b ~]# dmesg |grep method
[root@b ~]# dmesg |grep BIOS
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000008f000 (usable)
[ 0.000000] BIOS-e820: 000000000008f000 - 0000000000090000 (reserved)
[ 0.000000] BIOS-e820: 0000000000090000 - 000000000009ec00 (usable)
[ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000cee98000 (usable)
[ 0.000000] BIOS-e820: 00000000cee98000 - 00000000ceebf000 (reserved)
[ 0.000000] BIOS-e820: 00000000ceebf000 - 00000000cef47000 (usable)
[ 0.000000] BIOS-e820: 00000000cef47000 - 00000000cefbf000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000cefbf000 - 00000000ceff1000 (usable)
[ 0.000000] BIOS-e820: 00000000ceff1000 - 00000000cefff000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000cefff000 - 00000000cf000000 (usable)
[ 0.000000] BIOS-e820: 00000000cf000000 - 00000000d0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000f8000000 - 00000000fc000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
[ 0.000000] DMI: /D525MW, BIOS MWPNT10N.86A.0069.2010.0913.1432 09/13/2010
[ 0.000000] Calgary: detecting Calgary via BIOS EBDA area
[ 0.472644] mtrr: probably your BIOS does not setup all CPUs.
[ 0.496736] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored

stripwax · 2011-06-22 20:27:27

I can confirm my reboot issue persists even when using kernel26-2.6.39-1-vanilla (i.e. rebuilt without ARCH patches). So, definitely a kernel bug (not ArchLinux-specific), as far as I can tell so far.

@remote - it may well be a different problem in your case. Or, maybe, we both are seeing the same problem, that happens to have the same symptoms as kernel bug 33302, but different underlying cause (since kernel bug 33302 was specific to reboot thru BIOS).
When yours hangs, is there anything in any of the logfiles, or, even, on-screen? For what it's worth, mine has no log output or on-screen output.

gregor · 2011-06-22 21:44:17

try rebuilding the package "oblogout" from ABS.... maybe it helps.

Last edited by gregor (2011-06-22 21:45:30)

stripwax · 2011-06-22 22:03:26

gregor wrote:

try rebuilding the package "oblogout" from ABS.... maybe it helps.

As you can tell from reading the above (in particular post #6), I am not using any desktop environment. oblogout is not even installed. I cannot see how/why rebuilding it would help?

Last edited by stripwax (2011-06-22 22:04:11)

gregor · 2011-06-23 18:43:29

sorry i didn't read the whole story

mips1 · 2011-07-26 16:32:39

*wrong place*

Last edited by mips1 (2011-07-27 01:18:58)

stripwax · 2011-12-05 21:52:49

With bugzilla.kernel.org down, I don't know if/how upstream kernel maintainers would actually be able to see the kernel bug report. It seems to have still not been fixed / has been ignored.

I found this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536537 Interesting then that the fix only worked for a handful of kernel versions before breaking again.

Would anyone familiar with linux hierarchy/maintenance be able to suggest how to get someone to reinstate the fix that was originally working, and put it back into the current kernels?

stripwax · 2011-12-22 09:45:48

The following seems to be the same bug:
https://bbs.archlinux.org/viewtopic.php?id=124136

Given that there's no response on this thread, and quite a lot of commentry on that other thread, I think it's probably safe to assume that my thread is dead..

Arch Linux

#1 2011-06-14 23:37:11

kernel 2.6.39.1-1 issues: reboot no longer working

#2 2011-06-15 03:22:14

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#3 2011-06-15 12:11:41

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#4 2011-06-15 16:51:48

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#5 2011-06-15 17:36:24

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#6 2011-06-15 21:08:13

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#7 2011-06-15 21:43:51

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#8 2011-06-16 03:37:35

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#9 2011-06-16 09:17:12

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#10 2011-06-16 11:37:23

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#11 2011-06-16 11:41:40

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#12 2011-06-16 19:59:51

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#13 2011-06-17 22:38:39

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#14 2011-06-18 03:56:42

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#15 2011-06-18 07:49:46

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#16 2011-06-18 19:39:47

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#17 2011-06-22 20:27:27

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#18 2011-06-22 21:44:17

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#19 2011-06-22 22:03:26

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#20 2011-06-23 18:43:29

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#21 2011-07-26 16:32:39

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#22 2011-12-05 21:52:49

Re: kernel 2.6.39.1-1 issues: reboot no longer working

#23 2011-12-22 09:45:48

Re: kernel 2.6.39.1-1 issues: reboot no longer working

Board footer