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

[Charles Forsyth <forsyth@terzarima.net>]

[-- 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