On Tuesday 11 April 2006 07:49, you wrote:
From: Benjamin Herrenschmidt [EMAIL PROTECTED]
Date: Tue, 11 Apr 2006 11:46:12 +1000
But ppc64 hits the problem and at this point, there is nothing
I can do other than either implementing a split zone allocation mecanism
in the ppc64
On Tuesday 11 April 2006 08:39, Johannes Berg wrote:
On Mon, 2006-04-10 at 02:16 +0200, Michael Buesch wrote:
Does kbuild perhaps have some magic to handle that?
This needs to be solved soon, but I have no idea how.
You want to have bcm43xx and bcm43xx-dscape conflict anyway, since
On Tuesday 11 April 2006 18:42, Johannes Berg wrote:
On Tue, 2006-04-11 at 18:35 +0200, Michael Buesch wrote:
Sure. I would probably say that both m should conflict, too.
Nah, you probably want both m for testing.
I am OK with this, but it fucks up module autoloading.
But that is probably
I have had intermittent success using my PowerMac G5's Airport Extreme card,
and it turns out it is because I've switched up how much RAM my system uses
between installs (specifically from 512MB to 1.5GB).
When I type ifconfig up, I get this message in my xterm: SIOCSIFFLAGS:
CANNOT ALLOCATE
I have had intermittent success using my PowerMac G5's Airport Extreme card,
and it turns out it is because I've switched up how much RAM my system uses
between installs (specifically from 512MB to 1.5GB).
When I type ifconfig up, I get this message in my xterm: SIOCSIFFLAGS:
CANNOT ALLOCATE
I think allowing DMA mask range limiting in the IOMMU layer is going
to set a very bad precedence, just don't do it.
It's 2006, we should be way past the era of not putting the full 32
PCI DMA address bits in devices. In this day and age it is simply
inexscusable.
Maybe we could
Apparently it's a DMA issue specific to Broadcom and the PPC Linux kernel
people don't
want to mess with the purity of the kernel just to fix it.
Heh... where did you get that from ? :)
Any chance you guys could
give it a whirl or know how I can resolve this? Forgive my inexperience.
On Tue, 2006-04-11 at 14:34 -0700, David S. Miller wrote:
I still think we shouldn't reward shit hardware by complicating
up our DMA mappings internals. :-)
Heh, it's a good point but in that specific case, it's a bit difficult
to tell that to users who don't have a choice of what card to put
On Wed, 2006-04-12 at 00:30 +0200, Benoit Boissinot wrote:
On Wed, Apr 12, 2006 at 08:21:17AM +1000, Benjamin Herrenschmidt wrote:
I still think we shouldn't reward shit hardware by complicating
up our DMA mappings internals. :-)
BTW. In the meantime, can't that driver work in PIO
On Wednesday 12 April 2006 00:21, you wrote:
I still think we shouldn't reward shit hardware by complicating
up our DMA mappings internals. :-)
BTW. In the meantime, can't that driver work in PIO only mode ?
No, because I did not finish debugging that, yet. ;)
And a second half-no,
There isn't much the driver folks can do there except maybe allowing for
a PIO only mode.
Unfortunately, on newer cards, the hardware doesn't support PIO mode.
The queue lengths are reported as 0, so we can't use them. :p
-Joe
___
Bcm43xx-dev mailing
On Tue, Apr 11, 2006 at 01:16:26PM -0400, [EMAIL PROTECTED] wrote:
I have had intermittent success using my PowerMac G5's Airport Extreme
card, and it turns out it is because I've switched up how much RAM my
system uses between installs (specifically from 512MB to 1.5GB).
Yup. Care to give
12 matches
Mail list logo
