[9fans] Kernel failure - i486

[9fans] Kernel failure - i486

[Lucio De Re]

This is unrelated to a previous problem.  Captured over the serial
line.  The "pcnet" driver is the one I developed specifically for
this machine a long while back.  It may well be contributing, of
course, but the machine isn't going to work without it :-(

I may be able to live without a fix, but it would be a shame.

The lines:

cdumpstack
serialoq 1905 printed 1588
panic: invalid opcode
pu0: registers for *init* 1

probably split "cpu0".

dev A0 port 1F0 config 045A capabilities 0B00 mwdma 0103
found 9tickle.gz
.gz....................................................................537209 => 630869+621192+107172=1359233
entry: 80100020
Plan 9
cpu0: 23MHz GenuineIntel 486SX (cpuid: AX 0x0423 DX 0x0002)
#l0: err=0x8801
5424 free pages, 21696K bytes, 261696K swap
cdumpstack
serialoq 1905 printed 1588
panic: invalid opcode
pu0: registers for *init* 1
FLAGS=10216 TRAP=6 ECODE=8010040D PC=80100208 SS=EFF0 USP=8017BA00
  AX 7EFFEFF0  BX 00000010  CX 00000000  DX 7EFFEFC8
  SI 800050C0  DI 7EFFEFE8  BP 7DFFF000
  CS 0010  DS 0008  ES 0008  FS 001B  GS 001B
  CR0 80010039 CR2 7effefe0 CR3 00ad2000 CR4 00000000
  ur 8000ff2c up 8024d008
ktrace /kernel/path 80100208 8000ff70
estackx 80010150
8000fe70=80106311 8000fe80=8018ea8b 8000fe9c=8018ecbd 8000fea4=8018ef9f
8000fec4=8018f0ac 8000fee8=8018fed5 8000ff04=80190365 8000ff10=80190365
8000ff24=801003d8 8000ff60=8010040d 8000ff64=80100208 8000ff68=80170010
8000ff88=8018fed5 8000ffa8=8017cb4a 8000ffb8=8017cc8e 8000ffc0=8017cb4a
8000fff4=80174c00 80010014=8017d162 8001002c=80166f5b 80010034=80166f76
80010050=801676a1 80010054=80015930 80010058=00000000 8001005c=00000000
80010060=80010170 80010064=80179b15 80010068=80015930 8001006c=800155b0
80010070=00000004 80010074=00000000 80010078=00000001 8001007c=80014af0
80010080=8017746c 80010084=00000000 80010088=00000000 8001008c=00000000
80dumpstack
010090=00000000 80010094=00001152 80010098=800155b0 8001009c=80015930
800100a0=7fffefd1 800100a4=7fffefcc 800100a8=00000000 800100ac=80015c90
800100b0=ffffffff 800100b4=00010000 800100b8=00010000 800100bc=0000e000
800100c0=00000000 800100c4=00000083 800100c8=80106d88 800100cc=8024d260
800100d0=0000serialoq 2522 printed 1898
0023 800100d4=00000200 800100d8=7fffefc0 800100dc=0000001b
800100e0=801027ff 800100e4=00000007 800100e8=80164ad5 800100ec=00000000
800100f0=ffffffff 800100f4=7fffef9c 800100f8=00000000 800100fc=80100a1e
80010100=80010104 80010104=8024e460 80010108=00000a8e 8001010c=00002000
80010110=80010124 80010114=80104930 80010118=8000e2d0 8001011c=00000000
80010120=00000007 80010124=0000001b 80010128=0000001b 8001012c=0000001b
80010130=0000001b 80010134=00000040 80010138=80100569 8001013c=00001121
80010140=00000023 80010144=00000206 80010148=7fffef9c 8001014c=0000001b
panic: invalid opcode
ktrace /kernel/path 80106978 8000fd40
estackx 80010150
8000fce0=801067ab 8000fce8=801744de 8000fd14=8013edfb 8000fd28=80106978
8000fd3c=80106978 8000fd40=801067af 8000fd48=8013f07d 8000fd7c=80170a65
8000fda0=8016aa0a 8000fdb4=8017cb4a 8000fdc4=80106af4 8000fdd4=8017d293
8000fde8=80164ed7 8000fdf4=80164ed7 8000fe0c=8018ecbd 8000fe18=8010664b
8000fe40=80106909 8000fe70=8010633a 8000fe80=8018ea8b 8000fe9c=8018ecbd
8000fea4=8018ef9f 8000fec4=8018f0ac 8000fee8=8018fed5 8000ff04=80190365
8000ff10=80190365 8000ff24=801003d8 8000ff60=8010040d 8000ff64=80100208
8000ff68=80170010 8000ff88=8018fed5 8000ffa8=8017cb4a 8000ffb8=8017cc8e
8000ffc0=8017cb4a 8000fff4=80174c00 80010014=8017d162 8001002c=80166f5b
80010034=80166f76 80010050=801676a1 80010054=80015930 80010058=00000000
8001005c=00000000 80010060=80010170 80010064=80179b15 80010068=80015930
8001006c=800155b0 80010070=00000004 80010074=00000000 80010078=00000001
8001007c=80014af0 80010080=8017746c 80010084=00000000 80010088=00000000
8001008c=00000000 80010090=00000000 80010094=00001152 80010098=800155b0
8001009c=80015930 800100a0=7fffefd1 800100a4=7fffefcc 800100a8=00000000
800100ac=80015c90 800100b0=ffffffff 800100b4=00010000 800100b8=00010000
800100bc=0000e000 800100c0=00000000 800100c4=00000083 800100c8=80106d88
800100cc=8024d260 800100d0=00000023 800100d4=00000200 800100d8=7fffefc0
800100dc=0000001b 800100e0=801027ff 800100e4=00000007 800100e8=80164ad5
800100ec=00000000 800100f0=ffffffff 800100f4=7fffef9c 800100f8=00000000
800100fc=80100a1e 80010100=80010104 80010104=8024e460 80010108=00000a8e
8001010c=00002000 80010110=80010124 80010114=80104930 80010118=8000e2d0
8001011c=00000000 80010120=00000007 80010124=0000001b 80010128=0000001b
8001012c=0000001b 80010130=0000001b 80010134=00000040 80010138=80100569
8001013c=00001121 80010140=00000023 80010144=00000206 80010148=7fffef9c
8001014c=0000001b
cpu0: exiting

[9fans] Re: Kernel failure - i486

[Lucio De Re]

Hum!

On Thu, Jan 22, 2004 at 01:47:21PM +0200, Lucio De Re wrote:
>
> dev A0 port 1F0 config 045A capabilities 0B00 mwdma 0103
> found 9tickle.gz
> .gz....................................................................537209 => 630869+621192+107172=1359233
> entry: 80100020
> Plan 9
> cpu0: 23MHz GenuineIntel 486SX (cpuid: AX 0x0423 DX 0x0002)
> #l0: err=0x8801

I forgot that Plan 9 isn't ever happy _without_ an ethernet adapter
when trying to access its fileserver over a network.  Seems to me this
time the PCNet adapter didn't load at all.

I'll have to get digging...

++L

Re: [9fans] Re: Kernel failure - i486

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

it's blowing up on RDTSC in l.s:/^cycles

cycles works only if m->havetsc is non-zero, and thus it's used in /sys/src/9/pc
with
	if(m->havetsc)
		cycles(...);
but now it's used in port (which is the call i think is failing)

../port/sysproc.c:	cycles((uvlong*)&tos->pcycles);

without the check.  could make port code check m->havetsc and require
all Mach to include that too, but i wonder whether it wouldn't be simpler to have
void (*cycles)(uvlong*) in pc/fns.h and have x86 processors that don't support it set
cycles to point to  a function zero the uvlong, and x86 processors that do support
it point to the existing code.  architectures where they manage to make their processors largely
the same can just define void cycles(uvlong*), and be done with it.
i'd have thought that zero'ing the vlong might be good anyway to avoid
calculating using rubbish on the stack when the processor doesn't support it.

[-- Attachment #2: Type: message/rfc822, Size: 2898 bytes --]

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Subject: [9fans] Re: Kernel failure - i486
Date: Thu, 22 Jan 2004 13:52:42 +0200
Message-ID: <20040122135242.B28365@cackle.proxima.alt.za>

Hum!

On Thu, Jan 22, 2004 at 01:47:21PM +0200, Lucio De Re wrote:
>
> dev A0 port 1F0 config 045A capabilities 0B00 mwdma 0103
> found 9tickle.gz
> .gz....................................................................537209 => 630869+621192+107172=1359233
> entry: 80100020
> Plan 9
> cpu0: 23MHz GenuineIntel 486SX (cpuid: AX 0x0423 DX 0x0002)
> #l0: err=0x8801

I forgot that Plan 9 isn't ever happy _without_ an ethernet adapter
when trying to access its fileserver over a network.  Seems to me this
time the PCNet adapter didn't load at all.

I'll have to get digging...

++L

Re: [9fans] Re: Kernel failure - i486

[Charles Forsyth]

>>but now it's used in port (which is the call i think is failing)

and indeed it was that call that was failing

Re: [9fans] Re: Kernel failure - i486

[Lucio De Re]

On Thu, Jan 22, 2004 at 12:52:26PM +0000, Charles Forsyth wrote:
>
> without the check.  could make port code check m->havetsc and require
> all Mach to include that too, but i wonder whether it wouldn't be simpler to have
> void (*cycles)(uvlong*) in pc/fns.h and have x86 processors that don't support it set
> cycles to point to  a function zero the uvlong, and x86 processors that do support
>
Thank you, Charles, you're right on the button.

This is the version that works for me, based on some changes jmk put
into devarch.c to get the SiS 550 to work:

diff -n /n/dump/2004/0122/sys/src/9/pc/fns.h /sys/src/9/pc/fns.h
/n/dump/2004/0122/sys/src/9/pc/fns.h:16 c /sys/src/9/pc/fns.h:16,18
< void	cycles(uvlong*);
---
> void	(*cycles)(uvlong*);
> void	tsccycles(uvlong*);
> void	nocycles(uvlong*);
diff -n /n/dump/2004/0122/sys/src/9/pc/devarch.c /sys/src/9/pc/devarch.c
/n/dump/2004/0122/sys/src/9/pc/devarch.c:59 a /sys/src/9/pc/devarch.c:60,64
> void
> nocycles (uvlong *uvl) {
> 	*uvl = 0;
> }
>
/n/dump/2004/0122/sys/src/9/pc/devarch.c:663 c /sys/src/9/pc/devarch.c:668
< 	else if(strncmp(m->cpuidid, "SiS SiS SiS ", 12) == 0)
---
> 	else if(strncmp(m->cpuidid, "SiS SiS SiS", 11) == 0)
/n/dump/2004/0122/sys/src/9/pc/devarch.c:680 a /sys/src/9/pc/devarch.c:686
> 	cycles = nocycles;
/n/dump/2004/0122/sys/src/9/pc/devarch.c:682 a /sys/src/9/pc/devarch.c:689
> 		cycles = tsccycles;
diff -n /n/dump/2004/0122/sys/src/9/pc/l.s /sys/src/9/pc/l.s
/n/dump/2004/0122/sys/src/9/pc/l.s:332 c /sys/src/9/pc/l.s:332
< TEXT cycles(SB), $0				/* time stamp counter; cycles since power up */
---
> TEXT tsccycles(SB), $0			/* time stamp counter; cycles since power up */
/n/dump/2004/0122/sys/src/9/pc/l.s:334 c /sys/src/9/pc/l.s:334
< 	MOVL	vlong+0(FP), CX			/* &vlong */
---
> 	MOVL	vlong+0(FP), CX		/* &vlong */

Unless jmk has already released these, here are what I use:

cpu% diff /n/dump/2004/0122/sys/src/9/pc/devarch.c /n/dump/2004/0117/sys/src/9/pc/devarch.c
613,620d612
< /*
<  * SiS 55x
<  */
< static X86type x86sis[] =
< {
< 	{5,	0,	23,	"SiS 55x",},	/* guesswork */
< 	{ -1,	-1,	23,	"unknown", },	/* total default */
< };
663,664d654
< 	else if(strncmp(m->cpuidid, "SiS SiS SiS ", 12) == 0)
< 		tab = x86sis;
681,685c671,673
< 	if(m->cpuiddx & 0x10){
< 		m->havetsc = 1;
< 		if(m->cpuiddx & 0x20)
< 			wrmsr(0x10, 0);
< 	}
---
> 	m->havetsc = t->family >= 5;
> 	if(m->havetsc)
> 		wrmsr(0x10, 0);

This is all perfectly unreadable, of course :-)  It does look right,
to the best of my recollection.

++L