Date: Mon, 1 May 2006 00:04:50 -0700 (PDT) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= <mbsd@pacbell.net> To: Mike Silbersack <silby@silby.com> Cc: mobile@freebsd.org Subject: Re: if_bfe and > 1 GB of ram is now fixed (fwd) Message-ID: <20060430234832.A19669@antec.home> In-Reply-To: <20060501012306.G731@odysseus.silby.com> References: <20060429102214.V9858@odysseus.silby.com> <20060430134609.U4092@antec.home> <20060430163316.B724@odysseus.silby.com> <20060430151724.N4092@antec.home> <20060501012306.G731@odysseus.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-1168761760-1146467090=:19669
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
On Mon, 1 May 2006, Mike Silbersack wrote:
> On Sun, 30 Apr 2006, Mikko Työläjärvi wrote:
>
>> Verfied that limiting RAM still works. I guess the code path that
>> needs the locking isn't being triggered, as it seems to deal with
>> bounce buffers.
>>
>> Actually, even with 2G I can get an address via DHCP, do DNS lookups,
>> ping some hosts and even have a short telnet session without problems.
>>
>> But starting a web browser or running cvsup instantly results in the
>> above panic.
>>
>> /Mikko
>
> Ok, I talked to Scott Long about the problem and he explained to me why it's
> happening. Subsequently, I was able to cause it to happen to me if I told
> the system that my bfe card could only accept buffers from under the 128MB
> mark.
>
> Basically, what's happening is that there are not enough bounce buffers to go
> around, but the driver is assuming that there are - so when we hit the limit,
> it doesn't handle the error properly, and it panics.
>
> Attached is my WIP patch - it stops the panics, but acts flakey at times - in
> other words, it needs more work. I don't think I'll have a chance to get
> back to it until Thursday. In the meantime, see if it helps you at all.
Well, it stops the panics but acts flakey at times :-)
To be more precise, a few minutes of testing with assorted network
activity worked fine until cvsup got stuck. Tcpdump on the server (not
the bfe box) showed acivity on the cvsup connection. Then I got a
bunch of somewhat alarming error messages and made an executive
decision to abort the experiment:
Memory modified after free 0xc5e79800(2048) val=8000076 @ 0xc5e79800
Memory modified after free 0xc5ea6500(256) val=46c0de @ 0xc5ea6530
Memory modified after free 0xc5e6ee00(256) val=76c0de @ 0xc5e6ee30
Memory modified after free 0xc5ea9200(256) val=46c0de @ 0xc5ea9230
It is beginning to dawn on me why my feeble attempts at fixing this
driver were in vain, with only basic understanding of DMA but without
complete Mastery of the Black Art of Busdma :-P
Thanks for the good work. There's no hurry. NDIS has worked
sufficiently well for months; it can continue to do service yet a
while longer.
Cheers,
/Mikko
--0-1168761760-1146467090=:19669--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060430234832.A19669>