From owner-freebsd-alpha Tue Jan 22 3:46:41 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 6E08F37B402 for ; Tue, 22 Jan 2002 03:46:35 -0800 (PST) Received: from peter3.wemm.org ([12.232.27.13]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020122114635.QCQV26243.rwcrmhc51.attbi.com@peter3.wemm.org> for ; Tue, 22 Jan 2002 11:46:35 +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 g0MBkYs14344 for ; Tue, 22 Jan 2002 03:46:34 -0800 (PST) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (Postfix) with ESMTP id A907B39F1 for ; Tue, 22 Jan 2002 03:46:34 -0800 (PST) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: alpha@freebsd.org Subject: Is anybody actually able to netboot at the moment? Date: Tue, 22 Jan 2002 03:46:34 -0800 From: Peter Wemm Message-Id: <20020122114634.A907B39F1@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 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 wish I had a hub to plug these boxes into, but right now I am having to rely on tcpdump. Doing a hexdump of the packets that netboot uploads to the prom packet send code shows nothing obviously wrong. I might have to dig up a hub and go looking at the wire to see if SRM is sending but the switch is somehow deciding to filter the packets. However, If that were the case, I'd be wondering why the x86 boxes on the same switch can netboot just fine. (yes, the MAC addresses are explicitly listed). 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!) Can anybody please sanity check this for me? On several different combinations of hardware if possible. What is really bizzare is that my PC164SX at home has the same problem. I only have a cheap switch at home (no hubs anywhere... :-/ ) Both the Miatas and the AlphaPC164SX have current (albeit old) firmware. My PC164SX at home recognizes a fxp, I must try it with that instead of a 2104x, 21140A, or 21143 card. Note that I am *not* talking about PXE booting where PXE provides the file download API etc. I'm having trouble with the libstand network stack. 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