Date: Wed, 14 Jun 2000 00:33:33 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: hackers@freebsd.org Subject: Re: ether_output() : WIERD PROBLEM Message-ID: <Pine.BSF.4.21.0006140029410.385-100000@jehovah.technokratis.com> In-Reply-To: <Pine.BSF.4.21.0006131735350.394-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Wow, a reply to myself. I feel kind of lame. :-)
Anyway, this is just an update, with more info.
I've checked the status of my new system's lists, once the fault
occurs, and I can _guarantee_ that the management lists I wrote the
code for are actually not corrupt when this happens. I've looked at
the dump of the memory at where they are stored from DDB, and
everything looks in order. So my assumption is that this has just
uncovered a bug in ether_output(). Although I can't confirm it 100%.
I do have another bit of valuable information, though. If I move the
m_flags check to after the ENQUEUE, but prior to the call to the
interface "start" routine (see the end of ether_output()), then
things are fine. The problem only occurs if the check is moved to
_after_ the if_start call.
On Tue, 13 Jun 2000, Bosko Milekic wrote:
>
> Hello,
>
> I've been doing some mbuf-related work on my -CURRENT machine lately.
> Particularily, I've re-written the allocator and free routines, amongst
> other things. However, I've encountered a peculiar problem that surfaces
> in ether_output().
>
> What happens is that one of my daemons, for example, natd, or httpd,
> etc., performs a system call, which eventually results in a call to
> ether_output (following tcp_output, ip_output, etc.). At the bottom of
> ether_output(), after an IF_ENQUEUE, and an splx(s), there is the
> following check:
>
> if (m->m_flags & M_MCAST)
> ifp->if_omcasts++;
>
> The if () part results in a testb $0x2, 0x13(%ebx)
> IF I REMEMBER correctly.
>
> For some wierd reason, when the mbuf in question is at a location:
> 0xstuffF00 (256 bytes into a page, the second mbuf on a page), there is a
> page fault. And it's _always_ when the mbuf is at such an address.
>
> Where the wierdness begins is when I actually examine the contents of the
> mbuf... I can actually see them, no page fault, no nothing. In fact, if I
> `continue' from the debugger, things continue to work fine... until the
> next 0xstuffF00 mbuf goes through ether_output() and reaches that check.
>
> If I move the check of the m_flags to just above the splx(s), but after
> the IF_ENQUEUE, then the page fault still occurs in the same way, except
> that I even get a page fault when trying to examine the contents of the
> mbuf. In other words, I can't even `continue' in this case.
>
> If I move the m_flags check before the IF_ENQUEUE, this doesn't happen at
> all!
>
> Furthermore, if I revert my mbuf changes, I don't catch this problem.
>
> Anyone got any hints/clues?
>
> Regards,
> Bosko.
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
bmilekic@technokratis.com * http://www.technokratis.com/
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?Pine.BSF.4.21.0006140029410.385-100000>