public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [2.4] Nforce2 oops and occasional hang (tried the lockups patch, no difference)
@ 2003-12-11 16:16 Disconnect
  2003-12-11 16:38 ` Josh McKinney
  2003-12-11 17:22 ` Disconnect
  0 siblings, 2 replies; 12+ messages in thread
From: Disconnect @ 2003-12-11 16:16 UTC (permalink / raw)
  To: lkml

I've posted this a couple of times, with no response.

So long as memory pressure is kept to a minimum, the system is stable. 
Running without swap and without serious work kept it going for a couple
of weeks.

Running (currently with the nforce2-lockups patches and HZ=1000 but no
APIC/IO-APIC) results in the same oopses as every kernel I've tried,
including 2.4.22.

Suggestions? I'd really love to be able to use this thing reliably under
Linux :(

Unable to handle kernel NULL pointer dereference at virtual address 00000089
c012dff7
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c012dff7>]    Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 00000081   ebx: cff72b58   ecx: cee3a000   edx: 0000cad6
esi: 00001000   edi: cbabd9b4   ebp: 00000081   esp: cee3bf08
ds: 0018   es: 0018   ss: 0018
Process giftd (pid: 29738, stackpage=cee3b000)
Stack: c03155c0 c238b1c0 c44671c0 00000038 cee3a000 00000eea 00000000 00000000
       00000116 cbabd900 c012e6a0 cee3bf74 c2974660 c2974640 00001000 00001000
       00000000 00000000 c012e7f2 c2974640 c2974660 cee3bf74 c012e6a0 c0222e67
Call Trace:    [<c012e6a0>] [<c012e7f2>] [<c012e6a0>] [<c0222e67>] [<c013d413>]
  [<c0108fdf>]
Code: 39 78 08 74 05 8b 40 10 eb f2 39 68 0c 75 f6 85 c0 89 c6 0f
 
 
>>EIP; c012dff7 <do_generic_file_read+157/4e0>   <=====
 
>>ebx; cff72b58 <_end+fc02f6c/104a5494>
>>ecx; cee3a000 <_end+eaca414/104a5494>
>>edi; cbabd9b4 <_end+b74ddc8/104a5494>
>>esp; cee3bf08 <_end+eacc31c/104a5494>
 
Trace; c012e6a0 <file_read_actor+0/a0>
Trace; c012e7f2 <generic_file_read+b2/1a0>
Trace; c012e6a0 <file_read_actor+0/a0>
Trace; c0222e67 <sys_send+37/40>
Trace; c013d413 <sys_read+a3/110>
Trace; c0108fdf <system_call+33/38>
 
Code;  c012dff7 <do_generic_file_read+157/4e0>
00000000 <_EIP>:
Code;  c012dff7 <do_generic_file_read+157/4e0>   <=====
   0:   39 78 08                  cmp    %edi,0x8(%eax)   <=====
Code;  c012dffa <do_generic_file_read+15a/4e0>
   3:   74 05                     je     a <_EIP+0xa>
Code;  c012dffc <do_generic_file_read+15c/4e0>
   5:   8b 40 10                  mov    0x10(%eax),%eax
Code;  c012dfff <do_generic_file_read+15f/4e0>
   8:   eb f2                     jmp    fffffffc <_EIP+0xfffffffc>
Code;  c012e001 <do_generic_file_read+161/4e0>
   a:   39 68 0c                  cmp    %ebp,0xc(%eax)
Code;  c012e004 <do_generic_file_read+164/4e0>
   d:   75 f6                     jne    5 <_EIP+0x5>
Code;  c012e006 <do_generic_file_read+166/4e0>
   f:   85 c0                     test   %eax,%eax
Code;  c012e008 <do_generic_file_read+168/4e0>
  11:   89 c6                     mov    %eax,%esi
Code;  c012e00a <do_generic_file_read+16a/4e0>
  13:   0f 00 00                  sldtl  (%eax)

-- 
Disconnect <lkml@sigkill.net>


^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [2.4] Nforce2 oops and occasional hang (tried the lockups patch, no difference)
@ 2003-12-13  2:25 Ross Dickson
  2003-12-13  5:02 ` Bob
  2003-12-15 16:40 ` Disconnect
  0 siblings, 2 replies; 12+ messages in thread
From: Ross Dickson @ 2003-12-13  2:25 UTC (permalink / raw)
  To: lkml; +Cc: linux-kernel

Oh, and the modules list: 
 Module Size Used by Tainted: P 
 i2c-dev 4548 0 (unused) 
 i2c-core 13604 0 [i2c-dev]
<snip>


I am not certain your problems are nforce2 type specific.
Standard response: I don't suppose you can try a different stick of ram?

The reason I say that is that oops were very uncommon on either the 
epox 8rga+ or albatron km18G-pro MOBOS upon which I developed my
patches. Hard lockups were pretty much all I experienced prior to the 
patches except for an occasional X fail. Base OS flavour I
use is Suse 8.2 including gcc version (web updates utilised)

The udma patches are really just a cleanup on the address setup timing so
I do not think that they are a factor. 

The local apic ack delay timing patch needs athlon cpu and amd/nvidia ide on in 
kern config to kick in. If you are using it then I highly recommend uniprocessor 
ioapic config as well to go with it to route the 8254 timer irq0 through pin 0 of 
ioapic as using the apic config alone leaves a lot of ints generated on irq7 
which can cause problems. (Reason for 8259 making them spurious on irq7 
is explained in 8259A data sheet)

Also I now use a small patch to fixup proc info - only if you are using 
the 64 bit jiffies var hz patch, avail here:

http://linux.derkeiler.com/Mailing-Lists/Kernel/2003-12/0838.html

If you try acpi=off on boot and it is then not very stable then I think it has 
little to do with lockups patch as that is my fallback mode when I am 
playing with apic ioapic code. 

Another fallback I use at times is 

hdparm -Xudma3 /dev/hda

Hope this helps the confusion

Regards
Ross.

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2003-12-20 12:30 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-12-11 16:16 [2.4] Nforce2 oops and occasional hang (tried the lockups patch, no difference) Disconnect
2003-12-11 16:38 ` Josh McKinney
2003-12-11 17:19   ` Disconnect
2003-12-11 17:22 ` Disconnect
  -- strict thread matches above, loose matches on Subject: below --
2003-12-13  2:25 Ross Dickson
2003-12-13  5:02 ` Bob
2003-12-15 16:40 ` Disconnect
2003-12-18 18:52   ` Disconnect
2003-12-19 17:24     ` Disconnect
2003-12-19 20:22       ` Craig Bradney
2003-12-19 20:32         ` Disconnect
2003-12-20 12:30         ` Voicu Liviu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox