On Sat, Nov 14, 2009 at 12:41:49AM +, Andrew Benton wrote:
> And it seems to be working well. No errors so far. I've just downloaded
> a kernel, browsed slashdot a bit. I'll test it some more tomorrow but
> this is a BIG step in the right direction. This is the first kernel
> that's worked
On 11/13/2009 03:13 PM, Matthew Garrett wrote:
> On Fri, Nov 13, 2009 at 03:05:18PM -0600, Larry Finger wrote:
>
>> I'm in the process of creating a patch to set the latency to 200 usec. The
>> default is 2000. On my fast prosessors, it should not be anything nearly that
>> slow. If we determine t
On 11/13/2009 06:15 PM, William Bourque wrote:
>
> Larry Finger wrote:
>> Based on a suggestion by Matthew Garrett, please try the patch below.
>>
>> Thanks,
>>
>> Larry
>>
>> =
>>
>>
>> Index: wireless-testing/drivers/net/wireless/b43/main.c
>>
On 13/11/09 21:38, Larry Finger wrote:
> Based on a suggestion by Matthew Garrett, please try the patch below.
>
I've only been using it for a few minutes but this looks very good. I
compile the kernel with lots of ACPI
CONFIG_ACPI=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=
Larry Finger wrote:
> Based on a suggestion by Matthew Garrett, please try the patch below.
>
> Thanks,
>
> Larry
>
> =
>
>
> Index: wireless-testing/drivers/net/wireless/b43/main.c
> ===
> --- wireless-testing.or
Based on a suggestion by Matthew Garrett, please try the patch below.
Thanks,
Larry
=
Index: wireless-testing/drivers/net/wireless/b43/main.c
===
--- wireless-testing.orig/drivers/net/wireless/b43/main.c
+++ wirele
On 11/13/2009 03:13 PM, Matthew Garrett wrote:
> On Fri, Nov 13, 2009 at 03:05:18PM -0600, Larry Finger wrote:
>
>> I'm in the process of creating a patch to set the latency to 200 usec. The
>> default is 2000. On my fast prosessors, it should not be anything nearly that
>> slow. If we determine t
On Fri, Nov 13, 2009 at 03:05:18PM -0600, Larry Finger wrote:
> I'm in the process of creating a patch to set the latency to 200 usec. The
> default is 2000. On my fast prosessors, it should not be anything nearly that
> slow. If we determine this to be the problem, then we can try tuning.
The la
On 11/13/2009 03:02 PM, Oncaphillis wrote:
> On 11/13/2009 09:43 PM, Michael Buesch wrote:
>> On Friday 13 November 2009 21:36:31 Oncaphillis wrote:
>>> On 11/13/2009 08:20 PM, Larry Finger wrote:
>>> > On 11/13/2009 11:46 AM, Oncaphillis wrote:
>>> >
>>> >> Thanks for the tip. But it st
On 11/13/2009 02:44 PM, Michael Buesch wrote:
> On Friday 13 November 2009 21:11:12 Matthew Garrett wrote:
>> On Fri, Nov 13, 2009 at 11:21:18AM -0600, Larry Finger wrote:
>>
>>> I do not know enough about either the ACPI or DMA code to begin debugging in
>>> either of those regions. Any suggestion
On 11/13/2009 09:43 PM, Michael Buesch wrote:
> On Friday 13 November 2009 21:36:31 Oncaphillis wrote:
>> On 11/13/2009 08:20 PM, Larry Finger wrote:
>> > On 11/13/2009 11:46 AM, Oncaphillis wrote:
>> >
>> >> Thanks for the tip. But it still hangs
>> >
>> > We still need to know whe
On Friday 13 November 2009 21:11:12 Matthew Garrett wrote:
> On Fri, Nov 13, 2009 at 11:21:18AM -0600, Larry Finger wrote:
>
> > I do not know enough about either the ACPI or DMA code to begin debugging in
> > either of those regions. Any suggestions on debugging strategies, or links
> > to
> > s
On Friday 13 November 2009 21:36:31 Oncaphillis wrote:
> On 11/13/2009 08:20 PM, Larry Finger wrote:
> > On 11/13/2009 11:46 AM, Oncaphillis wrote:
> >
> >>Thanks for the tip. But it still hangs
> >
> > We still need to know where it hangs. If you boot to console mode
> (type a 3 on
> >
On 11/13/2009 08:20 PM, Larry Finger wrote:
> On 11/13/2009 11:46 AM, Oncaphillis wrote:
>
>>Thanks for the tip. But it still hangs
>
> We still need to know where it hangs. If you boot to console mode
(type a 3 on
> the option line in GRUB), does it boot? If it does not, what is the
la
On Fri, Nov 13, 2009 at 11:21:18AM -0600, Larry Finger wrote:
> I do not know enough about either the ACPI or DMA code to begin debugging in
> either of those regions. Any suggestions on debugging strategies, or links to
> similar problems would be appreciated.
Could the hardware be highly sensit
On 11/13/2009 11:36 AM, Michael Buesch wrote:
> Please test the following patch. It changes more stuff related to the
> descriptor ring handling (remove the old patch first before applying this
> one).
> http://bu3sch.de/patches/wireless-testing/20091113-1834/patches/001-b43-rewr
On 11/13/2009 11:46 AM, Oncaphillis wrote:
> Thanks for the tip. But it still hangs
We still need to know where it hangs. If you boot to console mode (type a 3 on
the option line in GRUB), does it boot? If it does not, what is the last line
shown on the console? If your distro shows a splash sc
On Friday 13 November 2009 18:46:22 Oncaphillis wrote:
> Thanks for the tip. But it still hangs
So, any chance to tell us what "hangs" means? See my other mail.
--
Greetings, Michael.
___
Bcm43xx-dev mailing list
Bcm43xx-dev@lists.berlios.de
https://
Michael Buesch wrote:
> Please test the following patch. It changes more stuff related to the
> descriptor ring handling (remove the old patch first before applying this
> one).
> http://bu3sch.de/patches/wireless-testing/20091113-1834/patches/001-b43-rewrite-dma-ring-alloc.patch
>
t; http://bu3sch.de/patches/wireless-testing/20091113-1834/patches/001-b43-rewrite-dma-ring-alloc.patch
> >
>
> Should I still apply Larry's patch as well?
Well, it doesn't really matter. Leave it out, if it doesn't apply cleanly
anymore.
--
Greetings, Michael.
_
On 13/11/09 17:36, Michael Buesch wrote:
> Please test the following patch. It changes more stuff related to the
> descriptor ring handling (remove the old patch first before applying this
> one).
> http://bu3sch.de/patches/wireless-testing/20091113-1834/patches/001-b43-rewr
On 11/13/2009 05:56 PM, William Bourque wrote:
>
> Oncaphillis wrote:
>> On 11/13/2009 05:12 PM, Larry Finger wrote:
>>> On 11/13/2009 09:33 AM, Oncaphillis wrote:
Hi,
I have a Acer One D250 which is equipped with a BCM4312 for
which on the homepage the support is marked as "in
Please test the following patch. It changes more stuff related to the
descriptor ring handling (remove the old patch first before applying this one).
http://bu3sch.de/patches/wireless-testing/20091113-1834/patches/001-b43-rewrite-dma-ring-alloc.patch
--
Greetings, Michael
A number of users are experiencing DMA descriptor or data errors using 64-bit
DMA with the Broadcom BCM4312 wireless device. After careful review and a
rewrite of the DMA code in the driver, we have not been able to fix the problem,
but we have determined the following:
(1) The problem is much mor
On Fri, Nov 13, 2009 at 5:05 PM, Larry Finger wrote:
> On 11/13/2009 05:16 AM, Michael Buesch wrote:
>> Ok, so my guess is that the DMA allocator simply returned high memory
>> that was unusable to the device. My new code explicitly checks for that (and
>> a
>> few other things) and retries with
Oncaphillis wrote:
> On 11/13/2009 05:12 PM, Larry Finger wrote:
>> On 11/13/2009 09:33 AM, Oncaphillis wrote:
>>> Hi,
>>>
>>> I have a Acer One D250 which is equipped with a BCM4312 for
>>> which on the homepage the support is marked as "in progress".
>>> Whenever the kernel tries to insert b43.k
On Friday 13 November 2009 17:41:21 Oncaphillis wrote:
> On 11/13/2009 05:12 PM, Larry Finger wrote:
> > On 11/13/2009 09:33 AM, Oncaphillis wrote:
> >> Hi,
> >>
> >> I have a Acer One D250 which is equipped with a BCM4312 for
> >> which on the homepage the support is marked as "in progress".
> >>
On 11/13/2009 05:12 PM, Larry Finger wrote:
> On 11/13/2009 09:33 AM, Oncaphillis wrote:
>> Hi,
>>
>> I have a Acer One D250 which is equipped with a BCM4312 for
>> which on the homepage the support is marked as "in progress".
>> Whenever the kernel tries to insert b43.ko it freezes. If've moved up
On Friday 13 November 2009 17:05:30 Larry Finger wrote:
> (3) When a DMA descriptor error occurs, a dump of the descriptors does not
> reveal any obvious problems.
I was going to write a patch that dumps the whole affected ring. But I think we
don't
see something suspicious there, either. So I gu
On 11/13/2009 09:33 AM, Oncaphillis wrote:
> Hi,
>
> I have a Acer One D250 which is equipped with a BCM4312 for
> which on the homepage the support is marked as "in progress".
> Whenever the kernel tries to insert b43.ko it freezes. If've moved up
> to 2.6.32-rc7, but is always stays like this.
>
On 11/13/2009 05:16 AM, Michael Buesch wrote:
> Ok, so my guess is that the DMA allocator simply returned high memory
> that was unusable to the device. My new code explicitly checks for that (and a
> few other things) and retries with GFP_DMA in case the address has illegal
> bits set.
> That's t
Hi,
I have a Acer One D250 which is equipped with a BCM4312 for
which on the homepage the support is marked as "in progress".
Whenever the kernel tries to insert b43.ko it freezes. If've moved up
to 2.6.32-rc7, but is always stays like this.
01:00.0 Network controller [0280]: Broadcom Corporatio
On 13/11/09 13:18, Andrew Benton wrote:
> Since I applied Larry's patch I've not had any error's with a kernel
> compiled with
> # CONFIG_ACPI is not set
Wouldn't you know it, as soon as I sent that I got this:-
Nov 13 13:21:22 doughnut kernel: b43-phy0 ERROR: Fatal DMA error: 0x,
0x
On 12/11/09 21:16, Michael Buesch wrote:
> Here you go:
> http://bu3sch.de/patches/wireless-testing/20091112-2213/patches/001-b43-rewrite-dma-ring-alloc.patch
> Please test this patch (also on 64bit-DMA devices that currently work).
>
> It seriously lacks some comments, but I'll add them later if
On Friday 13 November 2009 01:02:44 Larry Finger wrote:
> On 11/12/2009 05:57 PM, Michael Buesch wrote:
> > On Friday 13 November 2009 00:23:59 Larry Finger wrote:
> >> No, then was a 14e4:4311. I have now installed that same card and it seems
> >> to be
> >> working without the workaround. When I
35 matches
Mail list logo
