From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <56180b256fc8cc8d05e5b24091071cbf@terzarima.net> To: 9fans@cse.psu.edu Subject: Re: [9fans] Re: Kernel failure - i486 From: Charles Forsyth In-Reply-To: <20040122135242.B28365@cackle.proxima.alt.za> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-mubbctixzusfjddhhzvyvilsob" Date: Thu, 22 Jan 2004 12:52:26 +0000 Topicbox-Message-UUID: bd6d0e2e-eacc-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-mubbctixzusfjddhhzvyvilsob Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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. --upas-mubbctixzusfjddhhzvyvilsob Content-Type: message/rfc822 Content-Disposition: inline Received: from mail.cse.psu.edu ([130.203.4.6]) by lavoro; Thu Jan 22 11:55:05 GMT 2004 Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id AFEF719DC3; Thu, 22 Jan 2004 06:54:21 -0500 (EST) Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.4.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 56D1A19DBD; Thu, 22 Jan 2004 06:54:08 -0500 (EST) X-Original-To: 9fans@cse.psu.edu Delivered-To: 9fans@cse.psu.edu Received: by mail.cse.psu.edu (CSE Mail Server, from userid 60001) id EC8BF19DBD; Thu, 22 Jan 2004 06:53:06 -0500 (EST) Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.30.44.141]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id BEBC119CDF for <9fans@cse.psu.edu>; Thu, 22 Jan 2004 06:52:52 -0500 (EST) Received: from cackle.proxima.alt.za (localhost [127.0.0.1]) by cackle.proxima.alt.za (8.12.8/8.12.3) with ESMTP id i0MBqhER010512 for <9fans@cse.psu.edu>; Thu, 22 Jan 2004 13:52:45 +0200 (SAST) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.12.8/8.12.3/Submit) id i0MBqhgJ010511 for 9fans@cse.psu.edu; Thu, 22 Jan 2004 13:52:43 +0200 (SAST) From: Lucio De Re To: 9fans mailing list <9fans@cse.psu.edu> Message-ID: <20040122135242.B28365@cackle.proxima.alt.za> Mail-Followup-To: 9fans mailing list <9fans@cse.psu.edu> References: <20040122134721.A28365@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us In-Reply-To: <20040122134721.A28365@cackle.proxima.alt.za>; from Lucio De Re on Thu, Jan 22, 2004 at 01:47:21PM +0200 Organization: Proxima Research & Development Subject: [9fans] Re: Kernel failure - i486 Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.11 Precedence: bulk Reply-To: 9fans@cse.psu.edu X-Reply-To: lucio@proxima.alt.za List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Thu, 22 Jan 2004 13:52:42 +0200 X-Spam-Status: No, hits=-2.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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 --upas-mubbctixzusfjddhhzvyvilsob--