From owner-freebsd-alpha Tue Jan 22 16:45:38 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 268A537B405 for ; Tue, 22 Jan 2002 16:45:13 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020123004511.CXJZ10199.rwcrmhc53.attbi.com@peter3.wemm.org> for ; Wed, 23 Jan 2002 00:45:11 +0000 Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by peter3.wemm.org (8.11.0/8.11.0) with ESMTP id g0N0jBs16939 for ; Tue, 22 Jan 2002 16:45:11 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id 8321D39F1; Tue, 22 Jan 2002 16:45:11 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Andrew Gallatin Cc: alpha@FreeBSD.ORG Subject: Re: Is anybody actually able to netboot at the moment? In-Reply-To: <15437.31085.698208.990497@grasshopper.cs.duke.edu> Date: Tue, 22 Jan 2002 16:45:11 -0800 From: Peter Wemm Message-Id: <20020123004511.8321D39F1@overcee.wemm.org> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Andrew Gallatin wrote: > > Anyway.. the final straw is that when it finally does get up to a loader > > 'ok' prompt, doing a "load kernel" causes a 'kernel stack not valid' > > trap back to SRM. (doh!) > > That's a new one! Does it actually start loading the kernel? (as > verified by tcpdump) > > Doug sent me a patch which helps to debug loader crashes last year. > I posted it to the list & its archived here: > > http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=18451+0+archive/2001/freebsd-alp ha/20010603.freebsd-alpha Hmm. Well, this is as far as I got.. mostly as a FYI: sendrecv: called sendudp: d=20036ca8 called. saddr: 216.136.204.65:1013 daddr: 216.136.204.64:2049 sendudp: dest ethernet addr = 00:00:f8:75:92:0b sendether: called, len 132 prom0: netif_put prom_write: len=0x92, pkt=0x2003573a, hate@0x20034dc0 ret.bits = 0x0000000000000092 ret.u.retval = 0x92 ret.u.unit = 0x0 ret.u.mbz = 0x0 ret.u.error = 0x0 ret.u.status = 0x0 prom0: netif_put returning 146 sendudp: sendether returned 132 readudp: called readether: called, len 156, tleft 1 prom0: netif_get ret.bits = 0x00000000000000ae ret.u.retval = 0xae ret.u.unit = 0x0 ret.u.mbz = 0x0 ret.u.error = 0x0 ret.u.status = 0x0 cc = 174 prom0: netif_get returning 174 readether: got len 174 0000: 00 00 f8 75 67 16 00 00 f8 75 92 0b 08 00 45 00 0010: 00 9c 40 e5 00 00 40 11 ef d8 d8 88 cc 40 d8 88 0020: cc 41 08 01 03 f5 00 88 da 3d 00 00 00 18 00 00 0030: 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040: 00 00 00 00 00 00 68 4f 3e 3c 4e c8 d1 1d 0c 00 0050: 00 00 05 49 1d 00 90 20 37 4f 00 00 00 00 00 00 0060: 00 00 00 00 00 00 00 00 00 01 00 00 81 6d 00 00 0070: 00 01 00 00 00 00 00 00 00 00 00 34 2d 29 00 00 0080: 40 00 00 91 13 b8 00 00 1a 40 00 00 4a 02 00 1d 0090: 49 05 3c 4d 3c f8 00 00 00 00 3c 4d 38 3c 00 00 00a0: 00 00 3c 4d 38 3c 00 00 00 00 halted CPU 0 halt code = 5 HALT instruction executed PC = 20000160 boot failure >>>e sp gpr: 1E ( R30) 0000000020036150 >>>e -n 6 20036150 >>>e -virtual -n 6 20036150 vmem: 20E150 0000000000000007 (PS) vmem: 20E158 000000000B7797EC (PC) vmem: 20E160 00000000200381E8 (GP) vmem: 20E168 0000000020033708 (A0) vmem: 20E170 0000000020050E20 (A1) vmem: 20E178 0000000000000020 (A2) vmem: 20E180 000000002000CB68 >>> That PC doesn't look too good. 16:33:00.982129 0:0:f8:75:67:16 0:0:f8:75:92:b 0800 126: 216.136.204.65.1013 > 216.136.204.64.1018: [no cksum] udp 84 (ttl 4, id 0, len 112) 16:33:00.982457 0:0:f8:75:92:b 0:0:f8:75:67:16 0800 102: 216.136.204.64.1018 > 216.136.204.65.1013: [udp sum ok] udp 60 (ttl 64, id 16610, len 88) 16:33:02.208398 0:0:f8:75:67:16 0:0:f8:75:92:b 0800 146: 216.136.204.65.24 > 216.136.204.64.2049: 104 lookup fh 963,937832/1919234 "kernel" (ttl 4, id 0, len 132) 16:33:02.208556 0:0:f8:75:92:b 0:0:f8:75:67:16 0800 170: 216.136.204.64.2049 > 216.136.204.65.24: reply ok 128 lookup fh 963,937832/1919237 REG 100555 ids 0/0 sz 3419433 nlink 1 rdev 9113b8 fsid 4a02 nodeid 1d4905 a/m/ctime 1011694840.000000 1011693628.000000 1011693628.000000 (ttl 64, id 16613, len 156) The last packet recieved is the one in the hex dump above Oh wait. I just saw something above.. readether() was called with a buffer size of 156, and we returned a 174 byte packet in it.. That doesn't sound too good if that's right.. The NFS server is a 4.5-RC alpha box in case that is significant.. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message