Results with gcc-2.7.2.3 and a clean 2.1.98+irq.c were fairly weird.
--------------------------
First attempt: Optimistically going into runlevel 5, and stupidly forgetting
to add "mem=64M" on the command line to avoid the uncached RAM.
Lots of "eth0: Re-entering the interrupt handler" followed by
"Ugh at c0111acc" just after attempting to start xntpd, and then nothing more.
Hard lock.
--------------------------
Second attempt: Try again in runlevel 2, which I thought didn't do NTP
Again lots of whinging from eth0. Followed by an oops:
(Yes, it says CPU 18. It's not a typo. Last time it said CPU 66513.)
Unable to handle kernel NULL pointer dereference at virtual address 000004a4
current->tss.cr3 = 0265b000, %cr3 = 0265b000
*pde = 00000000
Oops: 0002
CPU: 18
EIP: 0010:[<c0113e36>]
EFLAGS: 00010286
eax: ffffffff ebx: c29a8000 ecx: c347a000 edx: c0106000
esi: 00000000 edi: fffffc18 ebp: c29a9f40 esp: c29a9f0c
ds: 0018 es: 0018 ss: 0018
Process ntpdate (pid: 230, process nr: 14, stackpage=c29a9000)
Stack: c263b000 00000008 00000004 c0106000 00000008 00000012 ffffffff 00000001
c2745ae0 c34c9f8c c29a9f68 c263b000 c0134455 00000000 c01344d9 c263b280
00000001 c263b284 c263b000 c0168534 c29a8000 c29a8000 00000000 00000001
Call Trace: [<c0106000>] [<c0134455>] [<c01344d9>] [<c0168534>] [<c013486d>] [<c0109219>] [<c0109ea0>]
Code: c7 86 a4 04 00 00 01 00 00 00 8b 4d e0 89 8e a8 04 00 00 39
Using `../System.map' to map addresses to symbols.
>>EIP: c0113e36 <schedule+26e/368>
Trace: c0106000 <this_must_match_init_task>
Trace: c0134455 <do_select+181/268>
Trace: c01344d9 <do_select+205/268>
Trace: c0168534 <sock_poll>
Trace: c013486d <sys_select+331/4b4>
Trace: c0109219 <sys_sigreturn+f9/178>
Trace: c0109ea0 <system_call+38/3c>
Code: c0113e36 <schedule+26e/368>
Code: c0113e36 <schedule+26e/368> c7 86 a4 04 00 movl $0x1,0x4a4(%esi)
Code: c0113e3b <schedule+273/368> 00 01 00 00 00
Code: c0113e46 <schedule+27e/368> 8b 4d e0 movl 0xffffffe0(%ebp),%ecx
Code: c0113e49 <schedule+281/368> 89 8e a8 04 00 movl %ecx,0x4a8(%esi)
Code: c0113e4f <schedule+287/368> 39 00 cmpl %eax,(%eax)
Code: c0113e57 <schedule+28f/368> 90 nop
Code: c0113e58 <schedule+290/368> 90 nop
Code: c0113e59 <schedule+291/368> 90 nop
OK, so runlevel 2 still does attempt to run NTP. It still shouldn't crash
though.
--------------------------
Third attempt: init=/bin/bash, followed by rm /etc/rc.d/rc2.d/S*ntp* ;
exec /sbin/init 2
Here it got surreal. It got a bit further through the boot that it had before,
albeit with eth0 still complaining all the time. Then there was another bloody
great string of oopsen, with lots of "/" appearing where there should be
digits. I didn't bother to copy much down, because it was obviously bollocks,
but here's an example:
Call Trace: [<c/1/////>] [<c/11a934>] [<c/1///c/>] [<c/1/2/18>] [<c/1/2/
18>] [<c/1/a3ab>] [<c/1//////>]
As a final data point - because I'd upgraded the tulip driver in the kernel I
described as "utterly buggered", I reverted your changes to irq.c and
recompiled it. It's working fine here, and there were only two object files
changed: irq.o and init/version.o
Boot messages from this kernel are at
http://dwmw2.robinson.cam.ac.uk/cgi-bin/dmesghtml
---- ---- ----
David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355
Dave@imladris.demon.co.uk http://www.imladris.demon.co.uk
finger pgp@dwmw2.robinson.cam.ac.uk for PGP key.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu