From owner-freebsd-alpha Tue Jan 22 6:39:39 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 1CB3737B41D for ; Tue, 22 Jan 2002 06:39:34 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA08564; Tue, 22 Jan 2002 09:39:07 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g0MEcbC40329; Tue, 22 Jan 2002 09:38:37 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15437.31085.698208.990497@grasshopper.cs.duke.edu> Date: Tue, 22 Jan 2002 09:38:37 -0500 (EST) To: Peter Wemm Cc: alpha@FreeBSD.ORG Subject: Re: Is anybody actually able to netboot at the moment? In-Reply-To: <20020122114634.A907B39F1@overcee.wemm.org> References: <20020122114634.A907B39F1@overcee.wemm.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid 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 Peter Wemm writes: > By netboot, I mean having something like ewa0_protocols = BOOTP and > 'boot ewa0' (or ewb0 in some of my cases).. ? > > And if so, how are you doing it? I've been fighting with a group of > cranky PWS 500au's (MIATAs) on a (fairly high powered) switch. > > If I run a tcpdump on the machine running dhcpd, I see about (maybe) one in > 50 broadcast bootp (or dhcp discover) packets actually arriving. However, > when net_open() switches to RARP, I see every single one of those arrive. > Sometimes even SRM fails to have its bootp broadcasts seen and has to > retry. Most of the times when the server actually sees the query and > replies, the reply isn't seen by the client. However, the tftp downloads > and rarp/arp broadcasts seem 100% reliable. > > Eventually, if I am lucky, the client will actually get a response to the > packets it sends and will magically snap into life, and fire up the NFS > root mount etc. > > The only holdup seems to be the dhcp query.. :-( <..> I seem to remember finding a problem in libstand quite some time ago, but never having time to track it down. I think that it had to do with checksum calculations for recv'ed packets. Try turning off UDP checksums on the dhcp server & see if that improves matters. > 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-alpha/20010603.freebsd-alpha > Can anybody please sanity check this for me? On several different > combinations of hardware if possible. Unfortunately, I'm no longer in a position to play with this... I wish you'd been interested a year ago :-( Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message