poweroff problem
I've got a problem with my 2.4.2-2 kernel. after reaching the power down stage i get a :
1. complete listing of the cpu registers
2. a message saying sementaion fault with halt -i -p -d
i contacted the author of the poweroff script but he says that this means it must be a kernel problem
i know that the kernel is old but i dont want to update cos my modem has a low download speed
also i cant give u the complete listing of the cpu registers since it occurs at the last stage of shutdown and i cant copy it to a file and am too lazy to write it down
can anyone help me ?
Anant
_______________________________________________________________________
Odomos - the only mosquito protection outside 4 walls - Click here to know more!
http://r.rediff.com/r?http://clients.rediff.com/odomos/Odomos.htm&&odomos&&wn
Quoted 4 lines · Anant Aneja
also i cant give u the complete listing of the cpu registers since it occurs at the last stage of shutdown and i cant copy it to a file and am too lazy to write it down
We are too lazy to help you.
Goodbye
Alan
Quoted 5 lines · Anant Aneja
Quoted 4 lines
also i cant give u the complete listing of the cpu registers since it occurs at the last stage of shutdown and i cant copy it to a file and am too lazy to write it down
Documentation/serial-console.txt
... but if you're too lazy to read... :)
Quoted 2 lines · Alan Cox
We are too lazy to help you.
Goodbye
:) *grin*
Regards
Michael Buesch.
Signature · 2 lines
My homepage: http://www.8ung.at/tuxsoft fighting for peace is like fu**ing for virginity
Quoted 2 lines · Anant Aneja
i know that the kernel is old but i dont want to update cos my modem has a low download speed
you may try to get small chunks of a new one each time you connect to the net so that after several hours of nearly normal browsing, you'll get a new kernel as a bonus.
Quoted 6 lines
also i cant give u the complete listing of the cpu registers since it occurs at the last stage of shutdown and i cant copy it to a file and am too lazy to write it down
can anyone help me ?
at least, try to patch it with kmsgdump to retrieve the last kernel messages on a floppy. You'll find it easily if you're not too lazy for that ;-)
Willy
Hi,
Quoted 1 line
I've got a problem with my 2.4.2-2 kernel.
[...]
Quoted 2 lines
i know that the kernel is old but i dont want to update cos my modem has a low download speed
[...]
Quoted 1 line
can anyone help me ?
For sure! You can probably help yourself (and people on the list) by upgrading your kernel to something a bit newer. No one still have a box with such installation, anyway.
Common, your modem is that slow? Ok, let's say you have a 28.8 KBps... Should be about 2 hours to download the file; give it a try yourself:
http://internetservices.cnet.com/g/bm/dl/0001.asp?filename=Linux+Kernel+2.4.
20+(tar.bz2)&sd=26.1MB&size=27421046 . Of course, make sure to download the bzip version, not the gzip one ( ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.20.tar.bz2 ).
Once installed, make sure to keep a clean version of the kernel tree, so in the future you can regularly download incremental updates; kernel's patch are about 1 MB per development month.
Give it a try, then if it still not works, it could be useful to mention it on LKML. But then, be preapared to do testing by yourself, cause it seems like you're the only one experiencing such problems.
Quoted 4 lines
also i cant give u the complete listing of the cpu registers since it occurs at the last stage of shutdown and i cant copy it to a file and am too lazy to write it down
Sorry to say it, but i don't think Linux is a good place for laziness; actually I know about an operating system developped by lazy programmers for lazy users... Don't remember the name ;)
James
Quoted 5 lines · On 5 Apr 2003 06:08:04 -0000 "Anant Aneja" <[email protected]> wrote:
I've got a problem with my 2.4.2-2 kernel. after reaching the power down stage i get a :
1. complete listing of the cpu registers
2. a message saying sementaion fault with halt -i -p -d
Has it always done this?
Quoted 2 lines
i contacted the author of the poweroff script but he says that this means it must be a kernel problem
More likely a BIOS problem that is weel known.
Quoted 4 lines
also i cant give u the complete listing of the cpu registers since it occurs at the last stage of shutdown and i cant copy it to a file and am too lazy to write it down
Write down the first few lines at least ...
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
On Sun, 6 Apr 2003 23:33:19 +1000 Stephen Rothwell (SR) wrote:
Hello,
SR> On 5 Apr 2003 06:08:04 -0000 "Anant Aneja" <[email protected]> wrote:
SR> >
SR> > I've got a problem with my 2.4.2-2 kernel.
SR> > after reaching the power down stage i get a :
SR> > 1. complete listing of the cpu registers
SR> > 2. a message saying sementaion fault with halt -i -p -d
SR>
SR> Has it always done this?
I have the same problem with Linux-2.4.21-pre6. I don't know when this started to happen because I pretty much never halt my machine.
SR> More likely a BIOS problem that is weel known.
It's not a BIOS problem here. halt works pretty well with Linux-2.5.66 here. It's most likely an ACPI problem. What happens here is that the code to power down actually does not manage to turn the machine off, instead after a while the NMI watchdog kicks in and the kernel oopses.
-Udo.
Quoted 5 lines · On Sun, 6 Apr 2003 15:58:14 +0200 "Udo A. Steinberg"…
It's not a BIOS problem here. halt works pretty well with Linux-2.5.66 here. It's most likely an ACPI problem. What happens here is that the code to power down actually does not manage to turn the machine off, instead after a while the NMI watchdog kicks in and the kernel oopses.
I was asuming the original report was from a kernel using APM not ACPI. Did 2.4.2 have ACPI?
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/ APM Maintainer
On Mon, 7 Apr 2003 00:27:03 +1000 Stephen Rothwell (SR) wrote:
SR> I was asuming the original report was from a kernel using APM not ACPI. SR> Did 2.4.2 have ACPI?
Err no, so he must have been using APM.
2.4.2+APM has the problem, 2.4.21-pre+ACPI has the problem. Do APM and ACPI both share the same code to power off a machine? If so that seems to be the culprit.
-Udo.
Quoted 10 lines · Udo A. Steinberg
On Mon, 7 Apr 2003 00:27:03 +1000 Stephen Rothwell (SR) wrote:
SR> I was asuming the original report was from a kernel using APM not ACPI. SR> Did 2.4.2 have ACPI?
Err no, so he must have been using APM.
2.4.2+APM has the problem, 2.4.21-pre+ACPI has the problem. Do APM and ACPI both share the same code to power off a machine? If so that seems to be the culprit.
We rely on the bios for the power off sequences. Many BIOS vendors do set it up to share the bios code it seems
On 06 Apr 2003 15:24:55 +0100 Alan Cox (AC) wrote:
AC> We rely on the bios for the power off sequences. Many BIOS vendors do AC> set it up to share the bios code it seems
Ok, but this does not explain why things work with 2.5.66 on the exact same machine, unless 2.5 had workarounds for BIOS bugs or didn't use the BIOS for power off. Board is an Asus A7V, BIOS version 1011.
-Udo.
Quoted 8 lines · Udo A. Steinberg
On 06 Apr 2003 15:24:55 +0100 Alan Cox (AC) wrote:
AC> We rely on the bios for the power off sequences. Many BIOS vendors do AC> set it up to share the bios code it seems
Ok, but this does not explain why things work with 2.5.66 on the exact same machine, unless 2.5 had workarounds for BIOS bugs or didn't use the BIOS for power off. Board is an Asus A7V, BIOS version 1011.
Different options for reboot (16 v 32) perhaps, might even be something is random as which way the carry flag is when the bios code is called. If you want to be sure for the APM case stick a printk just before we drop into the BIOS and make sure we oops after and not before..
On 06 Apr 2003 16:14:42 +0100 Alan Cox (AC) wrote:
AC> Different options for reboot (16 v 32) perhaps, might even be something is AC> random as which way the carry flag is when the bios code is called. If you AC> want to be sure for the APM case stick a printk just before we drop into AC> the BIOS and make sure we oops after and not before..
I just tried with APM; machine powers down without problems. It's ACPI which doesn't power down. Last thing it prints during powerdown is:
hwsleep-0178 [-24] Acpi_enter_sleep_state: Entering S5
I can't find any specific A7V workarounds in 2.5.66 ACPI code, so I guess the ACPI code in 2.4 isn't up-to-date.
The original poster's problem is then probably indeed related to a buggy BIOS if it doesn't even powerdown with APM.
-Udo.
Quoted 10 lines · Udo A. Steinberg
On 06 Apr 2003 16:14:42 +0100 Alan Cox (AC) wrote:
AC> Different options for reboot (16 v 32) perhaps, might even be something is AC> random as which way the carry flag is when the bios code is called. If you AC> want to be sure for the APM case stick a printk just before we drop into AC> the BIOS and make sure we oops after and not before..
I just tried with APM; machine powers down without problems. It's ACPI which doesn't power down. Last thing it prints during powerdown is:
Quoted 7 lines
hwsleep-0178 [-24]
Acpi_enter_sleep_state: Entering S5I can't find any specific A7V workarounds in 2.5.66 ACPI code, so I guess the ACPI code in 2.4 isn't up-to-date.
The original poster's problem is then probably indeed related to a buggy BIOS if it doesn't even powerdown with APM.
The original poster said his kernel was 2.4.2-2, which looks like a RedHat one and could have contained ACPI...
Regards,
Carl-Daniel
Quoted 8 lines · Carl-Daniel Hailfinger
Quoted 5 lines
I can't find any specific A7V workarounds in 2.5.66 ACPI code, so I guess the ACPI code in 2.4 isn't up-to-date.
The original poster's problem is then probably indeed related to a buggy BIOS if it doesn't even powerdown with APM.
The original poster said his kernel was 2.4.2-2, which looks like a RedHat one and could have contained ACPI...
No Red Hat production kernel so far contains ACPI. As the reliability improves and the quality of BIOS ACPI code rises that may change.
2.4.2 is also obsolete, and about five erratas back including security ones.
Quoted 8 lines · Udo A. Steinberg
On 06 Apr 2003 15:24:55 +0100 Alan Cox (AC) wrote:
AC> We rely on the bios for the power off sequences. Many BIOS vendors do AC> set it up to share the bios code it seems
Ok, but this does not explain why things work with 2.5.66 on the exact same machine, unless 2.5 had workarounds for BIOS bugs or didn't use the BIOS for power off. Board is an Asus A7V, BIOS version 1011.
On A7V with BIOS 1012a01 2.5.40+ ACPI always worked flawlessly, while 2.4.x has problems. Currently (2.4.21-pre7) is better than before: it writes some panic to screen, but poweroffs immediately after that (and sorry, nearest serial console is about 5km far away, and everybody should use 2.5.x anyway), so I always suspected that problem is not in poweroff itself, but in some driver's devexit procedure (I have enabled hotplug in kernel, so __devexit is not stripped out).
And if you are talking about A7V, for some old ACPI (maybe all 2.4.x, I have
no idea) take a look at http://groups.google.com/groups?q=vandrovec+acpi+poweroff&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=linux.kernel.20020124184011.GA23785%40vana.vc.cvut.cz&rnum=1
Best regards,
Petr Vandrovec
[email protected]