Date: Fri, 22 Aug 2003 03:32:20 -0700 (PDT) From: Hartmut Brandt <harti@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/dev/hfa fore_buffer.c fore_receive.c Message-ID: <200308221032.h7MAWKMB094168@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
harti 2003/08/22 03:32:20 PDT
FreeBSD src repository
Modified files: (Branch: RELENG_4)
sys/dev/hfa fore_buffer.c fore_receive.c
Log:
For some reason the hfa driver behaves differently between current and
stable when loaded with 4.X.Y firmware. This difference manifests itself
in the card returning receive buffer chains that start with a large buffer
under certain circumstances. This uncovered an inherent bug in the
mbuf handling of the atm stack: the driver prefixes 8 bytes to the mbuf
that contain a function address to dispatch this buffer to and a cookie
for this function. When the driver finds, that it has no space at the
head of the mbuf chain, it allocates a new packet header mbuf and
prepends it to the chain and moves the header to the new mbuf.
atm_intr() strips the additional 8 bytes from the mbuf chain and, if it
finds the first mbuf to become empty, removes that mbuf from the chain, but
does not care to move the header to the next mbuf. Here the packet
header is lost.
Work around:
1. Allocate all large buffers for the Fore card with a packet header.
2. When prefixing the new mbuf to the chain, don't move the packet header,
but initialize it with the correct values. This results in an mbuf
chain with two packet headers. When atm_intr strips the first mbuf,
everything is ok.
It would probably be better to fix the problem instead of working around it,
but this could break other drivers (hea and proatm).
Revision Changes Path
1.5.2.1 +10 -3 src/sys/dev/hfa/fore_buffer.c
1.5.2.3 +15 -1 src/sys/dev/hfa/fore_receive.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200308221032.h7MAWKMB094168>