Date: Tue, 21 Nov 2000 10:06:44 -0800 (PST) From: Richard Hodges <rh@matriplex.com> To: Adam Obszynski <awo@freebsd.pl> Cc: freebsd-atm@FreeBSD.ORG Subject: Re: FORE PCA-200e (oc3 and UTP) Message-ID: <Pine.BSF.4.10.10011210904110.55855-100000@mail.matriplex.com> In-Reply-To: <00Nov21.155619met.14339@gateway.hq.atm.com.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21 Nov 2000, Adam Obszynski wrote:
> Hello freebsd-atm,
>
> I spend next day testing ATM on hfa driver on FreeBSD 4.x tree.
> Trying a firmware form OS2 drivers and firmware from WinNT zip files.
>
> I'm sure that i do all what is needed to run ATM on FreeBSD. It don't work
> for me.
>
> So i'm again do simple thing
>
> change in fore.h line:
>
> #define BUF1_SM_DOFF ((BUF1_SM_HOFF + SIZEOF_Buf_handle) - BUF1_SM_HDR)
>
> to:
>
> #define BUF1_SM_DOFF 16
>
> it work... for a while.... until kernel.. panic 8-)
May I ramble for a few moments? Thanks :-)
The file fore.h contains these #defines when compiling on FreeBSD:
#define SIZEOF_Buf_handle 16 /* XXX sizeof(Buf_handle) */
#define BUF1_SM_HOFF (sizeof(struct m_hdr))
#define BUF1_SM_HDR (sizeof(struct m_hdr) + sizeof(struct pkthdr))
#define BUF1_SM_LEN (MHLEN)
#define BUF1_LG_HOFF (sizeof(struct m_hdr) + sizeof(struct pkthdr) \
+ sizeof(M_ext)) /* Buffer-to-handle offset */
#define BUF1_SM_DOFF ((BUF1_SM_HOFF + SIZEOF_Buf_handle) - BUF1_SM_HDR)
#define BUF1_SM_SIZE (BUF1_SM_LEN - BUF1_SM_DOFF)
Some quick calculations give us:
#define BUF1_SM_HOFF 20
#define BUF1_SM_HDR 44
#define BUF1_LG_HOFF 60
#define BUF1_SM_DOFF (20 + 16) - 44 == -8 (ouch!)
The term BUF1_SM_DOFF is used in two places:
fore_buffer.c: KB_HEADSET(m, BUF1_SM_DOFF);
fore_receive.c: KB_HEADSET(m, BUF1_SM_DOFF);
In both cases, these follow KB_ALLOCPKT, a wrapper for MGETHDR.
In fore_receive.c, there is also KB_LINKHEAD, which copies the
packet header to the new buffer. This should not affect the
size or offset calculations.
The macro KB_HEADSET(bfr, n) sets the data pointer to n bytes
after the packet header in this case:
(bfr)->m_data = (bfr)->m_pktdat + (n);
So if we change BUF1_SM_DOFF to 16 (or SIZEOF_Buf_handle), the new
data pointer will be mbuf+60, and BUF1_SM_SIZE will be MHLEN-16 (196).
It looks fine to me...
Now here is the part I really don't understand... The driver uses
a "buffer handle" structure to keep track of interesting things,
and places it at mbuf + BUF1_SM_HOFF, right on top of the m_pkthdr
structure. As far as I can tell, the driver leaves the m_pkthdr
in a possibly corrupted state, except for setting the length,
(fore_receive.c) right after dequeuing a PDU:
KB_PLENSET(mhead, pdulen);
My hypothesis is that the driver is handing over an mbuf chain to
the HARP core with possibly corrupt m_pkthdr data... Could it be
that the driver "buffer handle" structure *just happened* to be
compatible with the previous m_pkthdr structure?
I will need some time to test this idea, but maybe these ramblings
will help someone else find the truth. My first impression is that
maybe changing the offset to "buffer handle" (bhp) from BUF1_SM_HOFF
to BUF1_SM_HDR will do the trick. It almost looks like that was the
author's intention from the way that BUF1_SM_DOFF is calculated.
As always, helpful flames cheerfully accepted.
-Richard
-------------------------------------------
Richard Hodges | Matriplex, inc.
<title> | 769 Basque Way
rh@matriplex.com | Carson City, NV 89706
775-886-6477 | www.matriplex.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-atm" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10011210904110.55855-100000>