2003-08-23 12:20:58

by Mikael Pettersson

[permalink] [raw]
Subject: Re: nforce2 lockups

On Sat, 23 Aug 2003 10:41:46 +0900, [email protected] wrote:
>I had done this before but without the nolapic option. That appears to have been the solution. Ran a whole day without one lockup where before 10 minutes was rarely achieved.
...
>It looks like the nolapic kernel parameter was just recently introduced. I tried it in both the 2.4.22-rc2 kernel and the 2.6.0-test3 kernel with success in both.
>
>Would still like apic to be completely fixed in the nforce2 chipsets, but I am just happy to have a working system again.

"nolapic" does not exist in standard 2.4.22-rc2 or 2.6.0-test3 kernels.
The patch which added nolapic support was included in 2.6.0-test3-bk8,
and 2.6.0-test<2or3>-mm<something> before that.

Passing nolapic to a kernel which doesn't recognise it causes it to
simply be passed through to init, with no error message.
So either you used non-standard versions of 2.4.22-rc2/2.6.0-test3,
or nolapic wasn't the thing that fixed your nforce2 board.

"noapic" (note: no "l") might very well fix your board, but that's
a completely different animal: it disables the I/O-APIC, which
handles board-level interrupt routing. In a kernel that supports it,
"nolapic" effectively also disables the I/O-APIC.

acpi=off or pci=noacpi might also fix the board, if ACPI is busted.

/Mikael


2003-08-23 12:48:22

by Patrick Dreker

[permalink] [raw]
Subject: Re: nforce2 lockups

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Samstag, 23. August 2003 14:20 schrieb Mikael Pettersson <[email protected]>
zum Thema Re: nforce2 lockups:
> On Sat, 23 Aug 2003 10:41:46 +0900, [email protected] wrote:
> Passing nolapic to a kernel which doesn't recognise it causes it to
> simply be passed through to init, with no error message.
> So either you used non-standard versions of 2.4.22-rc2/2.6.0-test3,
> or nolapic wasn't the thing that fixed your nforce2 board.
It probably was a combination of the other measures mentioned in my mail then.
I have (had) the same problems, and one has to completely avoid the local
APIC it seems. Passing noapic and disabling APIC Mode in the BIOS did not do
that (2.6.0-test3 + acpi20030730).

> "noapic" (note: no "l") might very well fix your board, but that's
see above. noapic had no effect on the freezes. On boot it still said "found
and enabling local APIC" and the system freezes within minutes when I push
data across the network. Just after compiling a kernel with absolutely no
APIC stuff compiled in, it worked... Note that the nmi_watchdog was not
triggered by the freezes, and that seems to run via the APIC, too.

> acpi=off or pci=noacpi might also fix the board, if ACPI is busted.
ACPI works fine, when using at least acpi20030730. Without ACPI the interrupts
are not assigned OK, as e.g. the onboard 3com NIC does not work (at least
here).

- --
Patrick Dreker

GPG KeyID : 0xFCC2F7A7 (Patrick Dreker)
Fingerprint: 7A21 FC7F 707A C498 F370 1008 7044 66DA FCC2 F7A7
Key available from keyservers or http://www.dreker.de/pubkey.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/R2KMcERm2vzC96cRAstLAJ9ontoUXT7DS3Nij6rvHdEs7lN7kwCfRlFt
9rGbg6ebuFgAVpXReX4MXuY=
=u10b
-----END PGP SIGNATURE-----