Date: Mon, 16 Jul 2001 17:09:48 -0700 (PDT) From: wpaul@FreeBSD.ORG (Bill Paul) To: rh@matriplex.com (Richard Hodges) Cc: hackers@freebsd.org Subject: Re: NatSemi DP83820 gigE driver kit for 4.2 and 4.3 Message-ID: <20010717000948.3A9A437B405@hub.freebsd.org> In-Reply-To: <Pine.BSF.4.10.10107161645130.38762-100000@mail.matriplex.com> from Richard Hodges at "Jul 16, 2001 04:54:32 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > The OS wants the _payload_ to be aligned on a 32-bit boundary. It tries
> > to do 32-bit accesses to the IP header, and the NFS code also does 32-bit
> > accesses when trying to un-XDR NFS requests.
>
> Oh... I see... I guess you could grab an mbuf and copy just the IP
> header for that, no? (Just curious at this point :-)
That doesn't work for the NFS case: an XDR-encoded packet may contain
lots of different fields separated by 32-bit length markers.
Also, there's a religious issue, namely a violation of protocol
boundaries. This is an ethernet driver: it's not supposed to have
any really intimate knowledge of IP or TCP or UDP, so you really
don't want to go mucking about with the frame payload if you can
avoid it.
(Lastly, my goal here is to make the card work, not re-write the
innards of the networking stack or NFS. I really don't want intimate
knowledge of IP, TCP or UDP either. :)
> > But on other CPUs such as the alpha, SPARC, PPC and (I suspect) the
> > IA-64, unaligned accesses in the kernel generate a fatal trap and a
> > panic. In user space, an unaligned access may result in a bus error,
> > unless the OS is kind enough to handle the trap, which I believe
> > FreeBSD/alpha does.
>
> I don't think that is the case. I seem to remember FreeBSD Alpha 4.3
> sysinstall croaking on me once with an alignment error.
No no: an unaligned access trap in the kernel is fatal, but an unaligned
access trap in a *user-space* process is not. Once in a while you
will see messages on the console about unaligned access traps generated
by user programs, but these don't panic the system. In the case of
FreeBSD/alpha, we fake it up so know about the problem but the process
keeps running. Some OSes (e.g. Solaris) clobber the process with a
SIGBUS. Some would argue the latter behavior is better since it makes
it easier to find and fix what is probably a bug in the first place.
-Bill
--
=============================================================================
-Bill Paul (925) 691-2800 | Senior Engineer, Master of Unix-Fu
wpaul@osd.bsdi.com | Wind River Systems
=============================================================================
"I like zees guys. Zey are fonny guys. Just keel one of zem." -- The 3 Amigos
=============================================================================
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010717000948.3A9A437B405>