[driverloader] Re: [LinuxR3000] Broadcom 54g + FC3 + 1.5 G = 100% CPU usage?

Prarit Bhargava prarit at sgi.com
Mon Mar 28 10:50:45 EST 2005

Gus and Jonathan (at Linuxant support),

Linuxant does suffer from this problem.   The issue is NOT in Linux or 
in the wrapper SW, but is in the Broadcom driver/hardware (I can't be 
sure which) .  Either the driver or the hardware is restricted to < 1G 

IMO the only way to determine whether the driver or the hardware is the 
problem, and move forward with any investigation is to get out a PCI bus 
analyzer (not likely :) ) or to find a Broadcom HW Spec.  I've been 
looking for the spec but haven't found one ...

There are other options (as I indicated below in my email this 
morning).  However, after thinking about that solution I realize that 
forcing DMA under 1 G is a signifigant performance hit... which pretty 
much eradicates the whole point of 54g.

I suppose that the wrapper could enforce the restriction but I'm 
obviously unsure of how that code is archetected ...


Constantine 'Gus' Fantanas wrote:

> What about the Linuxant driver?  Does it suffer from the same bug?
> Gus Fantanas
> On Monday 28 March 2005 07:54 am, Prarit Bhargava wrote:
> Hi everyone,
> Larry wrote:
> >Another interesting side note:  After testing with a single 1GB stick, I
> >found ndiswrapper worked properly, then I bumped it back up to 2GB.  
> With
> >the 2GB back in place, I decided to test ndiswrapper again, and 
> amazingly
> >it worked perfectly.  I rebooted again, and it stopped working.  Weird.
> Please read on -- I know why this works/doesn't work ;)
> A little kernel hacking, and I discovered the following:
> Anytime the Broadcom hardware makes a DMA transaction ABOVE the 1 G
> boundary I end up with the system hang we're all experiencing.*  The
> driver appears to initialize properly, setup up PCI IO/MEM allocs, etc.,
> without any issues.  It's only when the driver
> starts negotiating do I run into a problem.  The driver negotiation, as
> with many PCI requests, requires a DMA transaction.
> Obviously, I don't have access to the Broadcom Windoze sources otherwise
> hackery would have already ensued :) .. and this list would be in
> possession of a functional driver :)
> The 1 G boundary means one of two things:
> 1.  The driver is built around a 1 G DMA limit.  ... .... but why would
> Broadcom ever do such a thing?
> 2.  The hardware is built around a 1 G address limit ... .... but why
> would Broadcom ever release a brain-dead device like that?  And more
> importantly, why would HP/Compaq sell it?  IMO, if it is the hardware,
> I'm going to be returning my laptop.
> Back to the case Larry raises above where the card seems to work and
> then after a reboot it doesn't.  It seems to depend on whether or not
> you're DMAing to a physical memory address above the 1 G boundary.  If
> you do -- you're going to hang.  If you don't (ie, you get lucky) you
> should be alright.
> Hope this helps,
> P.
> * I did come up with an obvious work around -- add "mem=1024M" to the
> boot command line (grub, lilo... whatever you're using).   Of course,
> this does limit your memory to 1 G.  Also, if I have the time this week
> I may hack the FC3 kernel to handle DMA from the Wireless such that it
> only DMAs to addresses below 1 G.  Yes, this is a very ugly brute-force
> attempt to get it working ... no promises that it will be this week
> though ... 

More information about the driverloader mailing list