[9fans] Alpha bootloader "kernel stack not valid"
cbl...@uiuc.edu
a roadblock in my efforts. I've successfully compiled the binaries,
kernel, and bootloader on another machine, and found a network card that
works with the SRM bootp/tftp bootloader (Intel 82559, oddly enough).
Bootp works great, the loader loads, the loader loads its configuration
perfectly, but as soon as it gets the first block of the kernel, the
process gets a "kernel stack not valid halt". I've got the latest SRM
console, V5.8-1, and the Plan 9 sources are from the Plan 9 ISO image I
pulled down several days ago.
I've traced it down to the memmove() call on line 532 of
/sys/src/boot/alphapc/bootp.c (or at least I think that's where it is, I
mangled the file a bit in the process of debugging). Apparently any
access to 0x80400020 (The hard-coded load address in the Alpha kernel)
results in this error. I'm aware that the Intel 8255x isn't known to
work with Plan 9 on Alpha, but that shouldn't make a difference before
the kernel is actually loaded, should it? Any idea at which bits I
should begin poking?
~chip
ge...@collyer.net
line and some surrounding context?
"kernel stack not valid halt" is coming from SRM, right?
I'm surprised that your alpha didn't come with a 2114x, and that SRM's
bootp/tftp loader can drive any other kind of ethernet card. Does
your 82559 have PXE enabled or have the additional chip added with
bootp and tftp boot burned into it (there's a socket for it on most
ethernet cards)?
cbl...@uiuc.edu
> There are several memmoves in that vicinity; could you show us the
> line and some surrounding context?
Sure. From /sys/src/boot/alphapc/bootp.c, in bootp(), near the bottom:
addr = (uchar*)entry;
p = tftpb.data+sizeof(Exec);
dlen -= sizeof(Exec);
segsize = text;
for(;;){
if(dlen == 0){
if((dlen = tftpread(fd, &server, &tftpb, sizeof(tftpb.data))) < 0)
return -1;
p = tftpb.data;
}
if(segsize <= dlen)
i = segsize;
else
i = dlen;
//print("addr: %lux p: %lux i: %d\n", addr, p, i);
//print("addr[0]: ");
//print("%x\n",addr[0]);
memmove(addr, p, i);
That last one is the offending memmove. With those print()'s
uncommented, the first two show up, but the third doesn't.
> "kernel stack not valid halt" is coming from SRM, right?
Yep. Looks like this:
yomiko (10.0.0.12!67): /alpha/conf/10.0.0.14.../alpha/9apc
659416
halted CPU 0
halt code = 2
kernel stack not valid halt
PC = 283bebeb8dfb08cc
>>>
Yomiko is running the tftp server, and I've successfully used tftp to
start up the netbsd net loader and the debian install image.
> I'm surprised that your alpha didn't come with a 2114x, and that SRM's
> bootp/tftp loader can drive any other kind of ethernet card. Does
> your 82559 have PXE enabled or have the additional chip added with
> bootp and tftp boot burned into it (there's a socket for it on most
> ethernet cards)?
Well, it wasn't actually an alpha *machine*. I found the mobo/CPU in a
box of other dilapidated hardware a few years ago, and recently came
upon some RAM that works with it. Much to my surprise, it booted. I was
completely surprised that the Intel card worked with it, too. I'm not
sure about the PXE or netboot rom; I'm not sure I've ever tried this
card elsewhere. It has no socket, but does have an Atmel chip soldered
to it. (None of that would work with SRM, anyway, would it?) It shows up
as eia0 instead of ewa0, but works the same. It looks like this:
http://www.pluto.ai.kyutech.ac.jp/plt/matumoto/bench/oldpc/fxp.jpg
~chip
ge...@collyer.net
complete systems (as were Vaxen) than as the grab-bag of components
that PCs tend be. I did a little work at getting the 83815 and 82557
ether drivers to run before my Alpha died, and eventually I realised
that SRM probably wouldn't be able to tftp boot through them.
I'd start by replacing the 82559 with a 2114x. Mine is a DE-500 but
you might be able to find Netgear FA310s (not 311s), which should work
too.
What's in your /alpha/conf file? Mine was:
bootfile=/alpha/9apccpu
ether0=type=2114x 100BASE-TXFD
scsi0=type=ata
What's your /lib/ndb entry for the alpha? Mine was:
ip=216.240.55.174 sys=alpha sys=α dom=alpha.collyer.net
ether=0000f81fb442 # de-500ba (21143); original ether card
bootf=/alpha/bootalphapc
It might be revealing to install and boot a BSD or Linux and see if it
runs correctly.
cbl...@uiuc.edu
> I'd start by replacing the 82559 with a 2114x. Mine is a DE-500 but
> you might be able to find Netgear FA310s (not 311s), which should work
> too.
Alright, I'll see if I can scrounge one of those.
> What's in your /alpha/conf file?
bootfile=/alpha/9apc
bootargs=tcp
ether0=type=8255x
fs=10.0.0.12
> What's your /lib/ndb entry for the alpha?
There are actually two machines doing this, neither of them plan9 (the
"other computer" that compiled the binaries was actually running in
qemu). My router serves the bootp request, and another linux machine
does tftp. I've looked at packet dumps of the bootp/tftp traffic, and
I'm pretty sure it's all working as it should.
> It might be revealing to install and boot a BSD or Linux and see if it
> runs correctly.
Well, I can boot the debian install image just fine, including bringing
up the network interface and pulling down things via HTTP. I am getting
a bunch of machine checks for ECC errors that I hadn't noticed before.
I'll put in a hard drive and see if I can get a working system out of
it.
ge...@collyer.net
Unless you've modified ether82557.c, that should read
ether0=type=i82557
> I am getting a bunch of machine checks for ECC errors that I hadn't
> noticed before.
Bad memory could cause all sorts of problems. I'd get that sorted out
first.
cbl...@uiuc.edu
> Unless you've modified ether82557.c, that should read
>
> ether0=type=i82557
Oh, right. That's what I had, but for some reason I thought it didn't
look right and changed it.
> > I am getting a bunch of machine checks for ECC errors that I hadn't
> > noticed before.
>
> Bad memory could cause all sorts of problems. I'd get that sorted out
> first.
Yeah, I'm starting to think that that may have something to do with the
reason I found this lying in a box of old computer parts.
~chip