Various issues after rebooting

[Olivier Fourdan]

Hi all,

I'm facing some various odd issues with a AMD64 based laptop (Compaq
R3480EA) I bought recently.

On first boot, everything is all right. The laptop runs flawlessly. But
if I shutdown the laptop and restart it, I can see all kind of strange
things happening.

1) the system clock runs 3 times faster,
2) the system is unable to mount cdroms,
3) modprobing nidswrapper cause a whole system freeze with the following
message:

CPU 0: Machine Check Exception: 0000000000000004
Bank 4: b200000000070f0f
Kernel panic - not syncing: CPU context corrupt

I've tried with various kernels and distributions in 32bit and 64bit
modes but that make no differences.

I also tried disable ACPI, setting clock=[tsc|pmtmr|pti], diabling APIC,
etc. No luck. No matter how many reboots I do, the problem remains. The
only way to fix the problem is to keep the laptop off for a couple of
hours.

I thought of a hardware issue, but in WinXP, everything is fine. And in
the case of a hardware issue, I guess the problem would always show, not
just in Linux after a reboot.

My guess is that the BIOS doesn't re-initialize the hardware correctly
in case of a quick shutdown/reboot but WinXP might be initializing the
things by itself (it's a guess, I'm probably completely wrong).

Does that make any sense so someone? How could I help tracking down this
issue?

Thanks in advance,

Best regards,
Olivier.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Willy Tarreau]

Hi,

On Mon, Mar 28, 2005 at 09:56:39PM +0200, Olivier Fourdan wrote:
(...)

Post by Olivier Fourdan
I thought of a hardware issue, but in WinXP, everything is fine. And in
the case of a hardware issue, I guess the problem would always show, not
just in Linux after a reboot.
My guess is that the BIOS doesn't re-initialize the hardware correctly
in case of a quick shutdown/reboot but WinXP might be initializing the
things by itself (it's a guess, I'm probably completely wrong).

I had same sort of problems with my crappy VAIO (which, fortunately, is
dead now). The bios did not initialize anything, and there were many
situations where it would not recover after a reboot. The most common one
was the local APIC. It was guaranteed that if I rebooted while I had used
local APIC, the BIOS would not detect the hard disk at next boot ! And if
I booted 2.6 and used the frame buffer, then I would have no screen at
next boot, which was not really a problem since it would also timeout on
the disk 10 seconds later...

Post by Olivier Fourdan
Does that make any sense so someone? How could I help tracking down this
issue?

Now I have a compaq (nc8000) which does not exhibit such buggy behaviour,
but you can try disabling the APIC too just in case it's a similar problem
(at least in 32 bits, I don't know if you can disable it in 64 bits mode).

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Olivier Fourdan]

Hi Willy

Post by Willy Tarreau
Now I have a compaq (nc8000) which does not exhibit such buggy behaviour,
but you can try disabling the APIC too just in case it's a similar problem
(at least in 32 bits, I don't know if you can disable it in 64 bits mode).

Thanks for the hint, but unfortunately, it's one of the first things I
tried, and that makes no difference.

Regards,
Olivier.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Willy Tarreau]

Post by Olivier Fourdan
Hi Willy

Post by Willy Tarreau
Now I have a compaq (nc8000) which does not exhibit such buggy behaviour,
but you can try disabling the APIC too just in case it's a similar problem
(at least in 32 bits, I don't know if you can disable it in 64 bits mode).

Thanks for the hint, but unfortunately, it's one of the first things I
tried, and that makes no difference.

Sorry, at first I only noticed ACPI in your mail, but after reading it
again, I also noticed APIC. So now, you can only try not to initialize
some peripherals (IDE, network, display, etc...) by removing their drivers
from the kernel. You may end up with a kernel panic, but that does not
matter is you boot it with "panic=5" so that it automatically reboots
5 seconds after the panic. You should then finally identify the subsystem
which is responsible for your problems. Perhaps you'll even need to remove
PCI support :-(

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------

[Olivier Fourdan]

Hi Willy,

Post by Willy Tarreau
Sorry, at first I only noticed ACPI in your mail, but after reading it
again, I also noticed APIC. So now, you can only try not to initialize
some peripherals (IDE, network, display, etc...) by removing their drivers
from the kernel. You may end up with a kernel panic, but that does not
matter is you boot it with "panic=5" so that it automatically reboots
5 seconds after the panic. You should then finally identify the subsystem
which is responsible for your problems. Perhaps you'll even need to remove
PCI support :-(

Well, actually, the system runs (at least) unless I try to load
"ndiswrapper" which leads to a kernel panic.

I tried to bring the issue to the ndiswrapper ML but I doubt that
ndiswrapper is faulty.

I can reliably predict the crash. If the clock (and all other time based
events) are too fast, then modprobing ndiswrapper will lead to a system
crash, just like mounting a CDROM will fail.

I think the clock speed and other effects are just signs, not the cause
of the problem. What I'd like to determine is what would need to be done
to avoid the root cause, or maybe if there is anything that can be done
in Linux to avoid that?

I just tried "acpi_fake_ecdt" but that leads to a immediate kernel
panic.

Ps: Given the crash (Machine check exception), the sleep option seems to
have no effect.

Thanks,
Olivier.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



-------------------------------------------------------------------------------
Achtung: diese Newsgruppe ist eine unidirektional gegatete Mailingliste.
Antworten nur per Mail an die im Reply-To-Header angegebene Adresse.
Fragen zum Gateway -> ***@inka.de.
-------------------------------------------------------------------------------