Date: Tue, 22 Jan 2002 17:39:53 +0100 From: Bernd Walter <ticso@cicely8.cicely.de> To: Peter Wemm <peter@wemm.org> Cc: alpha@FreeBSD.ORG Subject: Re: Is anybody actually able to netboot at the moment? Message-ID: <20020122173953.K71841@cicely8.cicely.de> In-Reply-To: <20020122114634.A907B39F1@overcee.wemm.org> References: <20020122114634.A907B39F1@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: <PCI bus> 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: <Intel 82378ZB PCI to ISA bridge> at device 7.0 on pci0
isa0: <ISA bus> on isab0
de0: <Digital 21040 Ethernet> 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: <VGA-compatible display device> at 14.0 irq 53
fdc0: <NEC 72065B or clone> 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: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
atkbd0: interrupting
telnet> send break
at ISA irq 1
mcclock0: <MC146818A real time clock> 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: <Parallel port> at port 0x3bc-0x3c3 irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
plip0: cannot reserve interrupt, failed.
lpt0: <Printer> on ppbus0
lpt0: Polled port
ppi0: <Parallel I/O> 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: <TANDBERG IBM 4100 I07Y> Removable Sequential Access SCSI-2 device
sa0: 3.300MB/s transfers
da0 at sym0 bus 0 target 1 lun 0
da0: <FUJITSU M2622F-512 0405> 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: <CDC 94181-15 2197> 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:
<fstype>:<device> Mount <device> using filesystem <fstype>
eg. ufs:/dev/da0s1a
? List valid disk boot devices
<empty line> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020122173953.K71841>