2003-11-28 15:14:18

by Ross Alexander

[permalink] [raw]
Subject: NForce2 pseudoscience stability testing (2.6.0-test11)

Brendan et al,

I have been test various kernel parameter combinations to test stability.

Basic scenario is default IDE driver, AIC7xxx PCI SCSI connected to HP
externel DVD.
Using grip (CDDA ripper) to test if system locks up. Unstable systems
will normally lock up
around track two or three. Stable systems are those which haven't locked
up after half
a dozen different CDs have been ripped.

MB: ASUS A7N8X
CPU: Athlon XP 2700+
Memory: 1.5GB (3 x 512MB DIMMs)
Disk: Internal 80GB IDE

COMPILE SMP ACPI PCI LAPIC APIC RESULT NOTE
SMP,PREM ON F
SMP,PREM ON NOACPI F
SMP,PREM OFF F
SMP,PREM OFF NO NO S
SMP,PREM OFF NO F
SMP,PREM OFF NO S
SMP,PREM ON NO NO F 1
SMP ON NO F 2
SMP F 3
APIC,LAPIC S
PREM,APIC,LAPIC S

* SMP = On (if compiled it) unless nosmp set. Using nosmp with smp kernel
causes very odd results.
* ACPI = Compiled by default. Set off using kernel paramter acpi=off.
* PCI = Kernel parameter. Only used to turn APCI routing off.
* LAPIC = Kernel paramter to turn it off (nolapic).
* APIC = Kernel paramter to turn it off (noapic).

1. Using APCI PCI routing and nolapic gives very odd results. As soon as
the network tries
to configure itself it simple hangs (but C-Alt-Del will reboot it).

2. Using the nolapic kernel parameter without disabling ACPI does nothing.

3. Using kernel parameter nosmp on and SMP kernel causes all the lower 16
IRQs to work in XT-PIC
mode and the PCI network card to use IRQ 21 with IO-APIC-level. Trying to
modprobe aic7xxx hung
modprobe but not system.

The conclusion to this is the problem is in Local APIC with SMP. I'm not
saying this is actually true
only that is what the data suggests. If anybody wants me to try some
other stuff feel free to suggest
ideas.

Cheers,

Ross

---------------------------------------------------------------------------------
Ross Alexander "We demand clearly defined
MIS - NEC Europe Limited boundaries of uncertainty and
Work ph: +44 20 8752 3394 doubt."


2003-11-28 16:43:30

by Alistair John Strachan

[permalink] [raw]
Subject: Re: NForce2 pseudoscience stability testing (2.6.0-test11)

On Friday 28 November 2003 15:13, [email protected] wrote:
[snip]
>
> The conclusion to this is the problem is in Local APIC with SMP. I'm not
> saying this is actually true
> only that is what the data suggests. If anybody wants me to try some
> other stuff feel free to suggest
> ideas.
>
> Cheers,
>
> Ross
>

It's evidently a configuration problem, albeit BIOS, mainboard revision,
memory quality, etc. because I and many others like me are able to run Linux
2.4/2.6 with all the options you tested and still achieve absolute stability,
on the nForce 2 platform.

My system is an EPOX 8RDA+, with an Athlon 2500+ (Barton) overclocked to
2.2Ghz, and 2x256MB TwinMOS PC3200 dimms. FSB is at 400Mhz, and the ram
timings are 4,2,2,2. One might expect such a configuration to be unstable,
but it is not.

I'm currently running 2.6.0-test10-mm1 with full ACPI (+ routing), APIC and
local APIC, no preempt, UP, and everything has been rock-solid, despite the
machine being under constant 100% CPU load and fairly active IO load.

Also, many others have found that just disabling local apic (and the MPS
setting in the BIOS) as well as ACPI solves their problem, so I'm skeptical
that SMP really causes *nForce 2 specific* instability.

--
Cheers,
Alistair.

personal: alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student: CS/AI Undergraduate
contact: 7/10 Darroch Court,
University of Edinburgh.

2003-11-28 18:00:11

by Julien Oster

[permalink] [raw]
Subject: Re: NForce2 pseudoscience stability testing (2.6.0-test11)

[email protected] writes:

Hello Ross,

> I have been test various kernel parameter combinations to test stability.

Thanks, that's quite a nice overview.

But something seems strange:

> APIC,LAPIC S
> PREM,APIC,LAPIC S

Does those two lines mean, that using ACPI, APIC and local APIC
enabled is stable, as long as your kernel is not an SMP kernel? If
yes, then I can't confirm this. I run strictly non-SMP kernels and
they always crash if APIC (or local APIC?) is enabled.

BTW, I use a very quick test to see if the system is stable, that also
can be performed when booting with a "read-only init=/bin/bash" LILO
command line (so that no filesystem will need to fsck after a crash):
just type hdparm -t /dev/hd<someharddrive> several times.

Regards,
Julien

2003-11-28 18:18:24

by Prakash K. Cheemplavam

[permalink] [raw]
Subject: Re: NForce2 pseudoscience stability testing (2.6.0-test11)

Julien Oster wrote:
> [email protected] writes:
>>I have been test various kernel parameter combinations to test stability.
>
>
> Thanks, that's quite a nice overview.
>
> But something seems strange:
>
>
>>APIC,LAPIC S
>>PREM,APIC,LAPIC S
>
>
> Does those two lines mean, that using ACPI, APIC and local APIC
> enabled is stable, as long as your kernel is not an SMP kernel? If
> yes, then I can't confirm this. I run strictly non-SMP kernels and
> they always crash if APIC (or local APIC?) is enabled.

I also have the same problem on an Abit NF7-S V2.0: I think I tested
(non-SMP always) with kernel 2.6-test8 last: With Apic (and/or local
apic) system locks up. Without it is now rock-solid with ACPI. But it
seems to be a BIOS issue, as Windows locks up with APIC use, as well.
Well I am using latest BIOS and hope that Abit gets this fixed...

BTW, why would someone want an SMP kernel for a 1-CPU system?

Prakash

2003-11-28 18:13:27

by Julien Oster

[permalink] [raw]
Subject: Re: NForce2 pseudoscience stability testing (2.6.0-test11)

Alistair John Strachan <[email protected]> writes:

Hello Alistair,

> It's evidently a configuration problem, albeit BIOS, mainboard revision,
> memory quality, etc. because I and many others like me are able to run Linux
> 2.4/2.6 with all the options you tested and still achieve absolute stability,
> on the nForce 2 platform.

No, it's most evidently a mainboard problem, as everybody using an
ASUS A7N8X (Deluxe) reported so far that the mainboard will lock up
completely unless you turn of ACPI, APIC and local APIC. There is no
other possibility to work this lockup madness around, as many users of
that mainboard including me really tried *everything*.

We know that other NForce2 Mainboards don't have this kind of problem,
but sadly that isn't of any help whatsoever for us A7N8X users.

Unfortunately, my onboard SATA controller is significantly slower when
using XT-PIC interrupts (and I don't have many of them which aren't
crowded anyway). I can verify this by booting with ACPI and APIC
enabled and doing a simple hdparm -t multiple times on my SATA
softraid. I won't have much time to do this, though, since the
mainboard loves locking up very soon especially by doing hdparm -t.

HOWEVER, I tested it several times under Windows 2000 (I installed it
solely for this purpose, my machine used to be completely Redmond
free), and although Windows 2000 also routes the PCI interrupts via
APIC and ACPI, there's no such lockup occuring.

So, somehow, Linux should be able to allow the Asus A7N8X operate with
APIC and ACPI and any help in finally getting it in an usable state
would be strongly appreciated. I would have hacked the kernel myself,
but unfortunately I have no clue of the ACPI and APIC/local APIC stuff
in the kernel source.

Regards,
Julien

2003-11-28 18:24:21

by Prakash K. Cheemplavam

[permalink] [raw]
Subject: Re: NForce2 pseudoscience stability testing (2.6.0-test11)

Julien Oster wrote:
> Alistair John Strachan <[email protected]> writes:
>
> Hello Alistair,
>
>
>>It's evidently a configuration problem, albeit BIOS, mainboard revision,
>>memory quality, etc. because I and many others like me are able to run Linux
>>2.4/2.6 with all the options you tested and still achieve absolute stability,
>>on the nForce 2 platform.
> No, it's most evidently a mainboard problem, as everybody using an
> ASUS A7N8X (Deluxe) reported so far that the mainboard will lock up
> completely unless you turn of ACPI, APIC and local APIC. There is no
> other possibility to work this lockup madness around, as many users of
> that mainboard including me really tried *everything*.

At least since kernel 2.6-test8, I thin,k ACPI works with my Abit
nforce2 mobo. Before it crapped out.


> Unfortunately, my onboard SATA controller is significantly slower when

> HOWEVER, I tested it several times under Windows 2000 (I installed it
> solely for this purpose, my machine used to be completely Redmond
> free), and although Windows 2000 also routes the PCI interrupts via
> APIC and ACPI, there's no such lockup occuring.


Intersting. My Windows locks up, as written in the other post, though
this seldomly occurs. Sometimes the system runs for days (using s3 and
s4). Then it could lock-up within minutes after boot-up.

kernel26 though locks up pretty fast when apic is enbled.

What kind of SATA Adapter hat the Asus? I have a Silicon image Si3112A.
Maybe this is the root of all evil. It?s driver sucks hard, as doing a
hdparm -d1 /dev/hde craps my drive up. (Though hdparm claims the drive
is already running in DMA mode.)

What kind of SATA controller do the Epox users have? Or don't they have
SATA onbaord?

I know that SiI Image produced corruption with early bioses, so maybe
this really is the weak spot.


Prakash

2003-11-29 02:57:24

by Josh McKinney

[permalink] [raw]
Subject: Re: NForce2 pseudoscience stability testing (2.6.0-test11)

On approximately Fri, Nov 28, 2003 at 07:13:23PM +0100, Julien Oster wrote:
> Alistair John Strachan <[email protected]> writes:
>
> Hello Alistair,
>
> > It's evidently a configuration problem, albeit BIOS, mainboard revision,
> > memory quality, etc. because I and many others like me are able to run Linux
> > 2.4/2.6 with all the options you tested and still achieve absolute stability,
> > on the nForce 2 platform.
>
> No, it's most evidently a mainboard problem, as everybody using an
> ASUS A7N8X (Deluxe) reported so far that the mainboard will lock up
> completely unless you turn of ACPI, APIC and local APIC. There is no
> other possibility to work this lockup madness around, as many users of
> that mainboard including me really tried *everything*.
>
> We know that other NForce2 Mainboards don't have this kind of problem,
> but sadly that isn't of any help whatsoever for us A7N8X users.
>
<snip>

I have also been using a A7N8X deluxe and saw lockups when I first
recieved the board. Booting with noapic nolapic solved the problems.
Later after reading some threads about it I decided to add some stuff to
a bugzilla that someone else already filed. After doing this I decided
to try to crash it like it used to to with apic and lapic but it DID NOT
CRASH! This may be due to an updated BIOS, I am using the 1007 Uber
BIOS, or some updates with the kernel, but I am running 2.6.0-test9-mm3
rock solid with ACPI, APIC, and local APIC.

Here is dmesg and /proc/interrupts

nformation
Building zonelist for node : 0
Kernel command line: vga=0x31A video=vesafb:mttr,pmipal,pro,ywrap root=/dev/hdc5 ro
current: c02f3a60
current->thread_info: c035c000
Initializing CPU#0
PID hash table entries: 2048 (order 11: 16384 bytes)
Detected 2205.273 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Memory: 515516k/524224k available (1712k kernel code, 7964k reserved, 701k data, 144k init, 0k highmem)
zapping low mappings.
Calibrating delay loop... 4358.14 BogoMIPS
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: After vendor identify, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: After all inits, caps: 0383fbff c1c3fbff 00000000 00000020
CPU: AMD Athlon(tm) XP 3200+ stepping 00
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
ENABLING IO-APIC IRQs
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ... failed.
...trying to set up timer as Virtual Wire IRQ... failed.
...trying to set up timer as ExtINT IRQ... works.
number of MP IRQ sources: 15.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
....... : Delivery Type: 0
....... : LTS : 0
.... register #01: 00170011
....... : max redirection entries: 0017
....... : PRQ implemented: 0
....... : IO APIC version: 0011
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 001 01 0 0 0 0 0 1 1 39
02 000 00 1 0 0 0 0 0 0 00
03 001 01 0 0 0 0 0 1 1 41
04 001 01 0 0 0 0 0 1 1 49
05 001 01 0 0 0 0 0 1 1 51
06 001 01 0 0 0 0 0 1 1 59
07 001 01 1 0 0 0 0 1 1 61
08 001 01 0 0 0 0 0 1 1 69
09 001 01 1 1 0 0 0 1 1 71
0a 001 01 0 0 0 0 0 1 1 79
0b 001 01 0 0 0 0 0 1 1 81
0c 001 01 0 0 0 0 0 1 1 89
0d 001 01 0 0 0 0 0 1 1 91
0e 001 01 0 0 0 0 0 1 1 99
0f 001 01 0 0 0 0 0 1 1 A1
10 000 00 1 0 0 0 0 0 0 00
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 2204.0700 MHz.
..... host bus clock speed is 400.0854 MHz.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb490, last bus=3
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20031002
IOAPIC[0]: Set PCI routing entry (2-9 -> 0x71 -> IRQ 9 Mode:1 Active:0)
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGPB._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB1._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUBA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LUBB] (IRQs 3 4 5 6 7 10 11 *12 14 15)
ACPI: PCI Interrupt Link [LMAC] (IRQs 3 4 5 6 7 10 11 *12 14 15)
ACPI: PCI Interrupt Link [LAPU] (IRQs 3 4 5 6 7 10 11 *12 14 15)
ACPI: PCI Interrupt Link [LACI] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LMCI] (IRQs 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LSMB] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LUB2] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LFIR] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [L3CM] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LIDE] (IRQs 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [APC1] (IRQs 16)
ACPI: PCI Interrupt Link [APC2] (IRQs 17)
ACPI: PCI Interrupt Link [APC3] (IRQs 18)
ACPI: PCI Interrupt Link [APC4] (IRQs *19)
ACPI: PCI Interrupt Link [APC5] (IRQs 16)
ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCG] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCI] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCJ] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCK] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCS] (IRQs *23)
ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [AP3C] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22)
ACPI: PCI Interrupt Link [APCS] enabled at IRQ 23
IOAPIC[0]: Set PCI routing entry (2-23 -> 0xa9 -> IRQ 23 Mode:1 Active:0)
00:00:01[A] -> 2-23 -> IRQ 23
Pin 2-23 already programmed
ACPI: PCI Interrupt Link [APCF] enabled at IRQ 20
IOAPIC[0]: Set PCI routing entry (2-20 -> 0xb1 -> IRQ 20 Mode:1 Active:0)
00:00:02[A] -> 2-20 -> IRQ 20
ACPI: PCI Interrupt Link [APCG] enabled at IRQ 22
IOAPIC[0]: Set PCI routing entry (2-22 -> 0xb9 -> IRQ 22 Mode:1 Active:0)
00:00:02[B] -> 2-22 -> IRQ 22
ACPI: PCI Interrupt Link [APCL] enabled at IRQ 21
IOAPIC[0]: Set PCI routing entry (2-21 -> 0xc1 -> IRQ 21 Mode:1 Active:0)
00:00:02[C] -> 2-21 -> IRQ 21
ACPI: PCI Interrupt Link [APCH] enabled at IRQ 20
Pin 2-20 already programmed
ACPI: PCI Interrupt Link [APCI] enabled at IRQ 22
Pin 2-22 already programmed
ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 21
Pin 2-21 already programmed
ACPI: PCI Interrupt Link [APCK] enabled at IRQ 20
Pin 2-20 already programmed
ACPI: PCI Interrupt Link [APCM] enabled at IRQ 22
Pin 2-22 already programmed
ACPI: PCI Interrupt Link [AP3C] enabled at IRQ 21
Pin 2-21 already programmed
ACPI: PCI Interrupt Link [APCZ] enabled at IRQ 20
Pin 2-20 already programmed
ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
IOAPIC[0]: Set PCI routing entry (2-16 -> 0xc9 -> IRQ 16 Mode:1 Active:0)
00:01:06[A] -> 2-16 -> IRQ 16
ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17
IOAPIC[0]: Set PCI routing entry (2-17 -> 0xd1 -> IRQ 17 Mode:1 Active:0)
00:01:06[B] -> 2-17 -> IRQ 17
ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
IOAPIC[0]: Set PCI routing entry (2-18 -> 0xd9 -> IRQ 18 Mode:1 Active:0)
00:01:06[C] -> 2-18 -> IRQ 18
ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
IOAPIC[0]: Set PCI routing entry (2-19 -> 0xe1 -> IRQ 19 Mode:1 Active:0)
00:01:06[D] -> 2-19 -> IRQ 19
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-16 already programmed
Pin 2-16 already programmed
Pin 2-17 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-18 already programmed
Pin 2-18 already programmed
Pin 2-18 already programmed
Pin 2-18 already programmed
Pin 2-19 already programmed
Pin 2-21 already programmed
Pin 2-21 already programmed
Pin 2-21 already programmed
Pin 2-21 already programmed
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
vesafb: framebuffer at 0xd8000000, mapped to 0xe080c000, size 16384k
vesafb: mode is 1280x1024x16, linelength=2560, pages=1
vesafb: protected mode interface info at c000:e710
vesafb: pmi: set display start = c00ce755, set palette = c00ce7da
vesafb: pmi: ports = b4c3 b503 ba03 c003 c103 c403 c503 c603 c703 c803 c903 cc03 ce03 cf03 d003 d103 d203 d303 d403 d503 da03 ff03
vesafb: scrolling: ywrap using protected mode interface, yres_virtual=6553
vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
fb0: VESA VGA frame buffer device
ikconfig 0.7 with /proc/config*
Initializing Cryptographic API
Console: switching to colour frame buffer device 160x64
pty: 256 Unix98 ptys configured
Linux agpgart interface v0.100 (c) Dave Jones
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Using anticipatory io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE2: IDE controller at PCI slot 0000:00:09.0
NFORCE2: chipset revision 162
NFORCE2: not 100% native mode: will probe irqs later
NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround.
NFORCE2: BIOS didn't set cable bits correctly. Enabling workaround.
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE2: 0000:00:09.0 (rev a2) UDMA133 controller
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: IBM-DTLA-307015, ATA DISK drive
hdb: CD-ROM 45X, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: WDC WD600BB-32CXA0, ATA DISK drive
hdd: AOPEN CRW1232, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 30003120 sectors (15361 MB) w/1916KiB Cache, CHS=31749/15/63, UDMA(100)
hda: hda1
hdc: max request size: 128KiB
hdc: 117231408 sectors (60022 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdc: hdc1 hdc2 hdc3 < hdc5 hdc6 hdc7 hdc8 hdc9 hdc10 hdc11 > hdc4
hdb: ATAPI 45X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
hdd: ATAPI 32X CD-ROM CD-R/RW drive, 4096kB Cache, DMA
ide-floppy driver 0.99.newide
Console: switching to colour frame buffer device 160x64
mice: PS/2 mouse device common for all mice
input: PC Speaker
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Translated Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
ACPI: (supports S0 S1 S4 S4bios S5)
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 144k freed
Adding 497972k swap on /dev/hdc11. Priority:-1 extents:1
EXT3 FS on hdc5, internal journal
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.18.
PCI: Setting latency timer of device 0000:00:04.0 to 64
eth0: forcedeth.c: subsystem: 01043:80a7
i2c /dev entries driver
nvidia: module license 'NVIDIA' taints kernel.
0: nvidia: loading NVIDIA Linux x86 nvidia.o Kernel Module 1.0-4496 Wed Jul 16 19:03:09 PDT 2003
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdc6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdc1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdc7, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdc8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdc9, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdc2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
ehci_hcd 0000:00:02.2: EHCI Host Controller
PCI: Setting latency timer of device 0000:00:02.2 to 64
ehci_hcd 0000:00:02.2: irq 21, pci mem e1854000
ehci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 1
PCI: cache line size of 64 is not supported by device 0000:00:02.2
ehci_hcd 0000:00:02.2: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-13
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
ohci_hcd: 2003 Oct 13 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd: block sizes: ed 64 td 64
ohci_hcd 0000:00:02.0: OHCI Host Controller
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.0: irq 20, pci mem e1856000
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 2
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
ohci_hcd 0000:00:02.1: OHCI Host Controller
PCI: Setting latency timer of device 0000:00:02.1 to 64
ohci_hcd 0000:00:02.1: irq 22, pci mem e1858000
ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 3
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 3 ports detected
hub 3-0:1.0: new USB device on port 1, assigned address 2
Real Time Clock Driver v1.12
drivers/usb/core/usb.c: registered new driver hiddev
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:02.1-1
drivers/usb/core/usb.c: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
PCI: Setting latency timer of device 0000:00:06.0 to 64
intel8x0_measure_ac97_clock: measured 50436 usecs
intel8x0: clocking to 47469
NET: Registered protocol family 10

CPU0
0: 26210201 XT-PIC timer
1: 13262 IO-APIC-edge i8042
2: 0 XT-PIC cascade
8: 1 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
14: 54 IO-APIC-edge ide0
15: 55490 IO-APIC-edge ide1
19: 1970612 IO-APIC-level nvidia
20: 24241 IO-APIC-level ohci_hcd, eth0
21: 172362 IO-APIC-level ehci_hcd, NVidia nForce2
22: 17657 IO-APIC-level ohci_hcd
NMI: 0
LOC: 26209970
ERR: 0
MIS: 0





--
Josh McKinney | Webmaster: http://joshandangie.org
--------------------------------------------------------------------------
| They that can give up essential liberty
Linux, the choice -o) | to obtain a little temporary safety deserve
of the GNU generation /\ | neither liberty or safety.
_\_v | -Benjamin Franklin

2003-11-29 16:33:17

by Julien Oster

[permalink] [raw]
Subject: Re: NForce2 pseudoscience stability testing (2.6.0-test11)

Josh McKinney <[email protected]> writes:

Hello Josh,

> I have also been using a A7N8X deluxe and saw lockups when I first
> recieved the board. Booting with noapic nolapic solved the problems.
> Later after reading some threads about it I decided to add some stuff to
> a bugzilla that someone else already filed. After doing this I decided
> to try to crash it like it used to to with apic and lapic but it DID NOT
> CRASH! This may be due to an updated BIOS, I am using the 1007 Uber
> BIOS, or some updates with the kernel, but I am running 2.6.0-test9-mm3
> rock solid with ACPI, APIC, and local APIC.

Oh! That sounds nice. I also run the latest 1007 BIOS, but that
doesn't help at all. In crontrary, I almost have the impression that
the lockups got worse, but that may be just subjective. But what do
you mean with "1007 Uber BIOS"? What is this "Uber"? Is that a special
BIOS Version?

However, 2.6.0-test9-mm3 might be the key. I'll test this immediately.

Thanks,
Julien

2003-11-29 16:54:07

by Craig Bradney

[permalink] [raw]
Subject: Re: NForce2 pseudoscience stability testing (2.6.0-test11)



On Sat, 2003-11-29 at 17:47, Craig Bradney wrote:
> Hi Julien
>
> > > I am also using a 2 week old A7N8X Deluxe, v2 with the latest 1007 BIOS.
> > > I AM able to run 2.6 Test 11 with APIC, Local APIC and ACPI support
> > > turned on (SMP off, Preemptible Kernel off).
> >
> > Unfortunately, I have the exact same configuration, with massive
> > lockups. Could you try executing "hdparm -t /dev/<someharddisk>"
> > several times and see if it lockups?
> >
>
> I just ran it 20 times non stop, also compiling in the background.. +
> evolution, apache2, mysql, xchat, mozilla.. gkrellm.. etc No hassles.
> Uptime is now over 18 hours.
>
> Spec is:
> a7n8x deluxe
> 2600+ 333mhz (not overclocked)
> 2x256ddr 400mhz running in dual ddr mode
> 80gb 8mb cache maxtor (hda) and a dvd rw (hdc) and cd rom (hdd)
> radeon 9000 pro
>

I have the SATA controller disabled by jumper on the motherboard if that
could be one of the differences as I notice you are posting about SATA
too.

Craig

2003-11-29 17:16:39

by Josh McKinney

[permalink] [raw]
Subject: Re: NForce2 pseudoscience stability testing (2.6.0-test11)

On approximately Sat, Nov 29, 2003 at 05:33:08PM +0100, Julien Oster wrote:
> Josh McKinney <[email protected]> writes:
>
> Hello Josh,
>
> > I have also been using a A7N8X deluxe and saw lockups when I first
> > recieved the board. Booting with noapic nolapic solved the problems.
> > Later after reading some threads about it I decided to add some stuff to
> > a bugzilla that someone else already filed. After doing this I decided
> > to try to crash it like it used to to with apic and lapic but it DID NOT
> > CRASH! This may be due to an updated BIOS, I am using the 1007 Uber
> > BIOS, or some updates with the kernel, but I am running 2.6.0-test9-mm3
> > rock solid with ACPI, APIC, and local APIC.
>
> Oh! That sounds nice. I also run the latest 1007 BIOS, but that
> doesn't help at all. In crontrary, I almost have the impression that
> the lockups got worse, but that may be just subjective. But what do
> you mean with "1007 Uber BIOS"? What is this "Uber"? Is that a special
> BIOS Version?
>

I should have given more info. It is a custom made BIOS made by a guy
at nforcershq.com

http://homepage.ntlworld.com/michael.mcclay/

It is strange to me that it doesn't crash anymore either. I am going to
boot test11 when I get the chance later today and will see if it still works.

--
Josh McKinney | Webmaster: http://joshandangie.org
--------------------------------------------------------------------------
| They that can give up essential liberty
Linux, the choice -o) | to obtain a little temporary safety deserve
of the GNU generation /\ | neither liberty or safety.
_\_v | -Benjamin Franklin

2003-11-30 13:06:38

by Lenar

[permalink] [raw]
Subject: Re: NForce2 pseudoscience stability testing (2.6.0-test11)

Hello,

Julien Oster wrote:

> No, it's most evidently a mainboard problem, as everybody using an
> ASUS A7N8X (Deluxe) reported so far that the mainboard will lock up
> completely unless you turn of ACPI, APIC and local APIC. There is no
> other possibility to work this lockup madness around, as many users of
> that mainboard including me really tried *everything*.
>
> We know that other NForce2 Mainboards don't have this kind of problem,
> but sadly that isn't of any help whatsoever for us A7N8X users.

I can't agree. I've had experiences with two Epox mobos - 8RDA+ running
2.6-test kernels and 8RDA3+ running 2.4.22 kernel.

Both of them locked completely up sometimes (that was after week or so
without reboot). It seems that compiling Local-APIC out of kernel has
stopped this behaviour. It's been about a month without lockups for 2.4
machine. 2.6 hasn't locked up either but it gets a new kernel and a reboot
every week anyway.

Actually the machine with 2.4 kernel run initially 1.5 months without a
glitch (and Local-APIC compiled in) before it started to lock up weekly. I
don't know why. Anyway as I said disabling Local-APIC has stopped all those
lockups.

Lenar