In linux-kernel@vger.rutgers.edu, you wrote:
>I've written a simple boot-time ioremap function, the patch is attached.
>I merged Lyle's modification to the mp table parser (allow
>mpc_spec=0x05)
I'm afraid to say it still won't boot on my boxes. Hangs at the
same old "Waiting for..." messages. That was vanilla 2.3.99pre5 with
just your patch applied. It does seem very temperamental and sometimes
will boot and othertimes will hang at that point.
2.3.99pre5+ingos smp patch-5-B2 has a couple of rejects on the
patch but does boot boot ok and got up to 14minutes of uptime under load
(the most yet) before stiffing. Coincidentally it was at almost exactly
the point where 2GB of ram had been allocated (2137740K acording to top).
2.3.99pre6-1 +ingos patch again died after 14 minutes. with 2324532KB
used of which 1987184K was cache. On yet another atempt I managed to
get an oops out of it:
ksymoops 2.3.4 on i686 2.2.15pre17. Options used
-v /usr/src/linux/vmlinux (specified)
-K (specified)
-L (specified)
-o /lib/modules/2.3.99-pre6/ (specified)
-m /usr/src/linux/System.map (specified)
No modules in ksyms, skipping objects
Unable to handle kernel NULL pointer dereference at virtual address 0000003c
c0128c01
*pde = 24d45001
Oops: 0000
CPU: 4
EIP: 0010:[<c0128c01>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 0000003c ebx: 0000001c ecx: 00104001 edx: e4cfc000
esi: e4d177a0 edi: bffffd15 ebp: 00000000 esp: e4d3ff3c
ds: 0018 es: 0018 ss: 0018
Process top (pid: 694, stackpage=e4d3f000)
Stack: e4cfc000 e4cfc000 e4cfc4dc e4c36000 00000007 c016edeb e4cfc000 bffffd15
e4c36000 00000007 00000000 e4cfc4fc c016f22e e4cfc000 e4c36000 e4c65f60
00000000 00000000 e4c65f60 e4cfc4dc 00000008 e4ecbba0 000007ff c0142c3c
Call Trace: [<c016edeb>] [<c016f22e>] [<c0142c3c>] [<c010cd30>]
Code: 39 43 20 74 2a 50 8b 43 20 50 68 e0 88 25 c0 e8 73 6b ff ff
>>EIP; c0128c01 <access_process_vm+129/170> <=====
Trace; c016edeb <proc_pid_cmdline+37/3c>
Trace; c016f22e <proc_info_read+176/2f8>
Trace; c0142c3c <sys_read+114/13c>
Trace; c010cd30 <system_call+34/38>
Code; c0128c01 <access_process_vm+129/170>
00000000 <_EIP>:
Code; c0128c01 <access_process_vm+129/170> <=====
0: 39 43 20 cmp %eax,0x20(%ebx) <=====
Code; c0128c04 <access_process_vm+12c/170>
3: 74 2a je 2f <_EIP+0x2f> c0128c30 <access_process_vm+158/170>
Code; c0128c06 <access_process_vm+12e/170>
5: 50 push %eax
Code; c0128c07 <access_process_vm+12f/170>
6: 8b 43 20 mov 0x20(%ebx),%eax
Code; c0128c0a <access_process_vm+132/170>
9: 50 push %eax
Code; c0128c0b <access_process_vm+133/170>
a: 68 e0 88 25 c0 push $0xc02588e0
Code; c0128c10 <access_process_vm+138/170>
f: e8 73 6b ff ff call ffff6b87 <_EIP+0xffff6b87> c011f788 <printk+0/1f4>
-- Chris Good - Dialog Corp. The Westbrook Centre, Milton Rd, Cambridge UK Phone: 01223 715006 Mobile: 07801 788997 http://www.dialog.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:21 EST