Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Jan 2002 15:40:07 -0800
From:      Peter Wemm <peter@wemm.org>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Andrew Gallatin <gallatin@cs.duke.edu>, alpha@FreeBSD.ORG
Subject:   Re: Is anybody actually able to netboot at the moment? 
Message-ID:  <20020122234007.1983E3BAD@overcee.wemm.org>
In-Reply-To: <3C4DEB7A.59E87BD3@mindspring.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
> Andrew Gallatin wrote:
> > 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.
> 
> Actually, there's a bug in the one's complement case on the
> FreeBSD checksum calculation, sometimes.  I was able to see
> incorrect checksums on a number of packets.  I think it's in
> the incremental update code, but since it doesn't seem to
> stop things from working, I never tracked down the source of
> the ethreal traces where I saw this.

Terry, what crack are you smoking this time?  We dont do incremental
checksums in the libstand code.  That stuff is as simple and as unoptimized
as it gets.

> >  > 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)
> 
> There was a problem with the static declaration of the buffer
> and the alignment thereof on the x86; he may need to update
> his loader code again to make sure that it's working (it was
> broken last week).  This seems unlikely on the Alpha (it made
> a BIOS error when loading from floppy on the PC), but it's a
> difference between old and new code, and, as they say, "no
> stone unturned"...

The alpha problems were in boot1 (the 7.5K loader) and that shares no
code with netboot at all.

I have experimented with alignment in the ethernet frame send code.. it
seems that we are trying to send with 2-byte alignment for the bootp case.
Fixing it doesn't seem to make much difference.  However, I wonder if SRM
is doing some length rounding or something because the lengths are not 4 or
8 byte multiples for the bootp queries but are for the working rarp
queries.  However, even that doesn't make sense because it sometimes works.
I'm more suspicious of interactions between the tulip cards when being
driven by SRM and the switch at the moment.

> -- Terry
> 

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020122234007.1983E3BAD>