From owner-freebsd-alpha Tue Jan 22 8:39:11 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id EEB8E37B400 for ; Tue, 22 Jan 2002 08:39:00 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.6/8.11.6) with UUCP id g0MGcuI15154; Tue, 22 Jan 2002 17:38:56 +0100 (CET) (envelope-from ticso@cicely8.cicely.de) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g0MGdwZ9074592; Tue, 22 Jan 2002 17:39:58 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.2.10]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id g0MGdvW16817; Tue, 22 Jan 2002 17:39:57 +0100 (CET) Received: (from ticso@localhost) by cicely8.cicely.de (8.11.6/8.11.6) id g0MGdsn74307; Tue, 22 Jan 2002 17:39:54 +0100 (CET) (envelope-from ticso) Date: Tue, 22 Jan 2002 17:39:53 +0100 From: Bernd Walter To: Peter Wemm Cc: alpha@FreeBSD.ORG Subject: Re: Is anybody actually able to netboot at the moment? Message-ID: <20020122173953.K71841@cicely8.cicely.de> References: <20020122114634.A907B39F1@overcee.wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020122114634.A907B39F1@overcee.wemm.org> User-Agent: Mutt/1.3.23i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 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 On Tue, Jan 22, 2002 at 03:46:34AM -0800, Peter Wemm wrote: > By netboot, I mean having something like ewa0_protocols = BOOTP and > 'boot ewa0' (or ewb0 in some of my cases).. ? At least 4.5-RC doesn't behave that badly: >>>boot ewa0 (boot ewa0.0.0.11.0 -flags 0) Trying BOOTP boot. Broadcasting BOOTP Request... Received BOOTP Packet File Name is: netboot local inet address: 10.1.1.128 remote inet address: 10.1.7.11 TFTP Read File Name: netboot netmask = 255.255.255.0 Server is NOT on same subnet as client... Router used = 10.1.1.8 .... bootstrap code read in base = 110000, image_start = 0, image_bytes = 33520 initializing HWRPB at 2000 initializing page table at 102000 initializing machine state setting affinity to the primary CPU jumping to bootstrap code Console: SRM firmware console VMS PAL rev: 0x1000400010538 OSF PAL rev: 0x100090002012d Switch to OSF PAL code succeeded. FreeBSD/alpha SRM net boot, Revision 0.1 (root@ds10.wbnet, Wed Jan 9 11:06:27 GMT 2002) Memory: 32768 k boot: ethernet address: 00:00:92:90:7f:26 net_open: server addr: 10.1.7.11 net_open: server path: /var/d7/testroot/ Loader version 0.3+ required Aborted! start not found Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... /kernel data=0x406088+0x2acb8 syms=[0x8+0x4e318+0x8+0x388fe] Entering kernel at 0xfffffc0000331400... Unrecognized boot flag '0'. Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD RC1 #0: Wed Jan 9 12:02:14 GMT 2002 root@ds10.wbnet:/usr/src/sys/compile/GENERIC DEC AXPpci Alpha PC AXPpci33, 166MHz 8192 byte page size, 1 processor. CPU: LCA Family major=4 minor=2 OSF PAL rev: 0x100090002012d real memory = 31481856 (30744K bytes) avail memory = 23363584 (22816K bytes) Preloaded elf kernel "kernel" at 0xfffffc00007ba000. md0: Malloc disk dec_axppci_33_intr_map: bad interrupt pin 92 pci0: on pcib0 sym0: <810> port 0x10000-0x100ff mem 0x81000000-0x810000ff irq 11 at device 6.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking sym0: interrupting at ISA irq 11 isab0: at device 7.0 on pci0 isa0: on isab0 de0: port 0x10100-0x1017f mem 0x81000100-0x8100017f irq 5 at device 11.0 on pci0 de0: interrupting at ISA irq 5 de0: Cogent 21040 [10Mb/s] pass 2.3 de0: address 00:00:92:90:7f:26 pci0: at 14.0 irq 53 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: interrupting at ISA irq 6 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 atkbd0: interrupting telnet> send break at ISA irq 1 mcclock0: at port 0x70-0x71 on isa0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A, console sio0: interrupting at ISA irq 4 sio1: reserved for low-level i/o ppc0: at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: cannot reserve interrupt, failed. lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 ppc0: interrupting at ISA irq 7 Timecounter "alpha" frequency 167357958 Hz Waiting 15 seconds for SCSI devices to settle de0: enabling 10baseT port (probe0:sym0:0:0:0): phase change 6-7 6@41dd8998 resid=4. sa0 at sym0 bus 0 target 0 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 3.300MB/s transfers da0 at sym0 bus 0 target 1 lun 0 da0: Fixed Direct Access SCSI-CCS device da0: 314MB (644868 512 byte sectors: 64H 32S/T 314C) da1 at sym0 bus 0 target 4 lun 0 da1: Fixed Direct Access SCSI-CCS device da1: 3.300MB/s transfers da1: 584MB (1196190 512 byte sectors: 64H 32S/T 584C) Mounting root from ufs:da0a Root mount failed: 22 Manual root filesystem specification: : Mount using filesystem eg. ufs:/dev/da0s1a ? List valid disk boot devices Abort manual input mountroot> The testroot is plain from the 4.5-RC iso. the netboot tftp file is also from there. I can hardly remember there is need for a different kernel. Would be nice for installing to have them build with release. > 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... :-/ ) I have one switch a hub and a FreeBSD router in between. > 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. I will try -current next. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message