[RFT] BCM4312 users with DMA errors, please test!

[RFT] BCM4312 users with DMA errors, please test!

[Gábor Stefanik]

Hello Everyone!

If you are experiencing DMA errors on a BCM4312, please test the
attached patch. It implements the PCI-E SERDES workaround, which the
hybrid driver is applying during early init to LP-PHY cards, and which
is a good candidate for the cause of the DMA error.
Note that this is not a final patch & it may cause collateral damage
for non-4312 cards; if it helps the 4312 problem, I will submit a
cleaned-up version.

Thanks,
G?bor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pcie_serdes_workaround.diff
Type: application/octet-stream
Size: 3420 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20100816/3f259da2/attachment.obj>

[RFT] BCM4312 users with DMA errors, please test!

[Gábor Stefanik]

2010/8/16 Arthur Moreira <arthur.moreira@gmail.com>:
> Hi,
> I have a BCM4353 card, with the ?hybrid module ?wl work fine to find
> and conect to networks.
> But, a want to put the card in monitor mode.
>
> (my card is a 802.11bgN mini card, in a dell vostro)
>
> this path will help me? and.. how to aply the path? the comand path $#
> < file ? ????
> tks
>
>
> ? ? ? ? ? ? ? Arthur Moreira
>

No, this patch is only for BCM4312 devices, not the BCM43224 that you
have (there is no such thing as a "BCM4353" AFAIK - PCI device IDs
don't map directly to chip IDs!). Your card is an N-PHY, probably
revision 4 or 5 (you can see the revision by adding 14e4:4353 to the
list of PCI IDs in ssb, then looking for the "FOUND UNSUPPORTED PHY"
line in dmesg). We are working on N-PHYs, revisions <=2 will likely be
usable soon; rev.3 and newer will take longer, however. (It is
possible that this patch will also be needed for N-PHYs if they show
similar DMA errors to the 4312, but it is certainly not enough to get
N-PHYs to work.)

>
>
>
> 2010/8/16 G?bor Stefanik <netrolller.3d@gmail.com>:
>> Hello Everyone!
>>
>> If you are experiencing DMA errors on a BCM4312, please test the
>> attached patch. It implements the PCI-E SERDES workaround, which the
>> hybrid driver is applying during early init to LP-PHY cards, and which
>> is a good candidate for the cause of the DMA error.
>> Note that this is not a final patch & it may cause collateral damage
>> for non-4312 cards; if it helps the 4312 problem, I will submit a
>> cleaned-up version.
>>
>> Thanks,
>> G?bor
>>
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

[RFT] BCM4312 users with DMA errors, please test!

[Gábor Stefanik]

2010/8/16 Arthur Moreira <arthur.moreira@gmail.com>:
> Ok, tks G?bor
>
> i will wait, i need much of this card working in monitor mode for
> tests and demonstration and my organization. i work with security in
> my city. and i dont want to plug another card, like usb ou pciexpreess
> card than a original embedded.
>
> if you need a help to tests and beta version of driver or modules
> call me
>
>
> ? ? ? ? ? ? ? Arthur Moreira

Well, I post any testing requests on the list, so you will probably
see them here.

Also, please use the Reply to All button when replying to a list!

>
> 2010/8/16 G?bor Stefanik <netrolller.3d@gmail.com>:
>> 2010/8/16 Arthur Moreira <arthur.moreira@gmail.com>:
>>> Hi,
>>> I have a BCM4353 card, with the ?hybrid module ?wl work fine to find
>>> and conect to networks.
>>> But, a want to put the card in monitor mode.
>>>
>>> (my card is a 802.11bgN mini card, in a dell vostro)
>>>
>>> this path will help me? and.. how to aply the path? the comand path $#
>>> < file ? ????
>>> tks
>>>
>>>
>>> ? ? ? ? ? ? ? Arthur Moreira
>>>
>>
>> No, this patch is only for BCM4312 devices, not the BCM43224 that you
>> have (there is no such thing as a "BCM4353" AFAIK - PCI device IDs
>> don't map directly to chip IDs!). Your card is an N-PHY, probably
>> revision 4 or 5 (you can see the revision by adding 14e4:4353 to the
>> list of PCI IDs in ssb, then looking for the "FOUND UNSUPPORTED PHY"
>> line in dmesg). We are working on N-PHYs, revisions <=2 will likely be
>> usable soon; rev.3 and newer will take longer, however. (It is
>> possible that this patch will also be needed for N-PHYs if they show
>> similar DMA errors to the 4312, but it is certainly not enough to get
>> N-PHYs to work.)
>>
>>>
>>>
>>>
>>> 2010/8/16 G?bor Stefanik <netrolller.3d@gmail.com>:
>>>> Hello Everyone!
>>>>
>>>> If you are experiencing DMA errors on a BCM4312, please test the
>>>> attached patch. It implements the PCI-E SERDES workaround, which the
>>>> hybrid driver is applying during early init to LP-PHY cards, and which
>>>> is a good candidate for the cause of the DMA error.
>>>> Note that this is not a final patch & it may cause collateral damage
>>>> for non-4312 cards; if it helps the 4312 problem, I will submit a
>>>> cleaned-up version.
>>>>
>>>> Thanks,
>>>> G?bor
>>>>
>>>
>>
>>
>>
>> --
>> Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
>>
>



-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)

[RFT] BCM4312 users with DMA errors, please test!

[Larry Finger]

On 08/16/2010 12:59 PM, G?bor Stefanik wrote:
> Hello Everyone!
> 
> If you are experiencing DMA errors on a BCM4312, please test the
> attached patch. It implements the PCI-E SERDES workaround, which the
> hybrid driver is applying during early init to LP-PHY cards, and which
> is a good candidate for the cause of the DMA error.
> Note that this is not a final patch & it may cause collateral damage
> for non-4312 cards; if it helps the 4312 problem, I will submit a
> cleaned-up version.

The patch that you distributed had a couple of errors in compiling, namely:

  CC [M]  drivers/ssb/driver_pcicore.o
drivers/ssb/driver_pcicore.c: In function ?ssb_pcie_mdio_set_block?:
drivers/ssb/driver_pcicore.c:457:7: error: ?i? undeclared (first use in this
function)
drivers/ssb/driver_pcicore.c:457:7: note: each undeclared identifier is reported
only once for each function it appears in
drivers/ssb/driver_pcicore.c: In function ?ssb_pcie_mdio_read?:
drivers/ssb/driver_pcicore.c:503:2: error: expected ?;? before ?pcicore_write32?
make[2]: *** [drivers/ssb/driver_pcicore.o] Error 1
make[1]: *** [drivers/ssb] Error 2
make[1]: *** Waiting for unfinished jobs....

Did you forget a quilt refresh?

My machine does not have the DMA error, but I will be testing.

Larry

[RFT] BCM4312 users with DMA errors, please test!

[Gábor Stefanik]

2010/8/16 Larry Finger <Larry.Finger@lwfinger.net>:
> On 08/16/2010 12:59 PM, G?bor Stefanik wrote:
>> Hello Everyone!
>>
>> If you are experiencing DMA errors on a BCM4312, please test the
>> attached patch. It implements the PCI-E SERDES workaround, which the
>> hybrid driver is applying during early init to LP-PHY cards, and which
>> is a good candidate for the cause of the DMA error.
>> Note that this is not a final patch & it may cause collateral damage
>> for non-4312 cards; if it helps the 4312 problem, I will submit a
>> cleaned-up version.
>
> The patch that you distributed had a couple of errors in compiling, namely:
>
> ?CC [M] ?drivers/ssb/driver_pcicore.o
> drivers/ssb/driver_pcicore.c: In function ?ssb_pcie_mdio_set_block?:
> drivers/ssb/driver_pcicore.c:457:7: error: ?i? undeclared (first use in this
> function)
> drivers/ssb/driver_pcicore.c:457:7: note: each undeclared identifier is reported
> only once for each function it appears in
> drivers/ssb/driver_pcicore.c: In function ?ssb_pcie_mdio_read?:
> drivers/ssb/driver_pcicore.c:503:2: error: expected ?;? before ?pcicore_write32?
> make[2]: *** [drivers/ssb/driver_pcicore.o] Error 1
> make[1]: *** [drivers/ssb] Error 2
> make[1]: *** Waiting for unfinished jobs....
>
> Did you forget a quilt refresh?
>
> My machine does not have the DMA error, but I will be testing.
>
> Larry
>

Oops... yes, two nasty typos. I have no idea why it compiled for me...
Schr?dinbug?

With that said, here is the corrected version.

-- 
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pcie_serdes_workaround.diff
Type: application/octet-stream
Size: 3428 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20100816/f52bbc47/attachment-0001.obj>

[RFT] BCM4312 users with DMA errors, please test!

[Larry Finger]

On 08/16/2010 02:16 PM, G?bor Stefanik wrote:
> 
> Oops... yes, two nasty typos. I have no idea why it compiled for me...
> Schr?dinbug?
> 
> With that said, here is the corrected version.

Hmmm, a new application of the "Uncertainty Principle".

The patch did not break my 14e4:4315 device, which already worked.

Larry

[RFT] BCM4312 users with DMA errors, please test!

[Gábor Stefanik]

2010/8/16 Larry Finger <Larry.Finger@lwfinger.net>:
> On 08/16/2010 02:16 PM, G?bor Stefanik wrote:
>>
>> Oops... yes, two nasty typos. I have no idea why it compiled for me...
>> Schr?dinbug?
>>
>> With that said, here is the corrected version.
>
> Hmmm, a new application of the "Uncertainty Principle".
>
> The patch did not break my 14e4:4315 device, which already worked.
>
> Larry
>

That's expected, given that the hybrid driver also does this. :-) The
question is whether it fixes the DMA error.

[RFT] BCM4312 users with DMA errors, please test!

[Chris Vine]

On Mon, 16 Aug 2010 19:59:36 +0200
G?bor Stefanik <netrolller.3d@gmail.com> wrote:
> Hello Everyone!
> 
> If you are experiencing DMA errors on a BCM4312, please test the
> attached patch. It implements the PCI-E SERDES workaround, which the
> hybrid driver is applying during early init to LP-PHY cards, and which
> is a good candidate for the cause of the DMA error.
> Note that this is not a final patch & it may cause collateral damage
> for non-4312 cards; if it helps the 4312 problem, I will submit a
> cleaned-up version.

This applies to 2.6.35.2, but does not compile:

drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_set_block':
drivers/ssb/driver_pcicore.c:457: error: 'i' undeclared (first use in
this function) drivers/ssb/driver_pcicore.c:457: error: (Each
undeclared identifier is reported only once
drivers/ssb/driver_pcicore.c:457: error: for each function it appears
in.) drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_read':
drivers/ssb/driver_pcicore.c:503: error: expected ';' before
'pcicore_write32'

With the obvious fixes (providing a variable 'i' of int type as the
count variable and terminating the line which had no terminating
semi-colon), it compiled OK and the first time I booted up, booted up
OK but didn't fix the DMA error.  Subsequent attempts to boot up gave me
a slew of errors on boot up so I am not sure what is going on there.

You might want to check that the obvious fixes to the patch are
complete.

Chris

[RFT] BCM4312 users with DMA errors, please test!

[Chris Vine]

On Mon, 16 Aug 2010 20:41:54 +0100
Chris Vine <chris@cvine.freeserve.co.uk> wrote:

> On Mon, 16 Aug 2010 19:59:36 +0200
> G?bor Stefanik <netrolller.3d@gmail.com> wrote:
> > Hello Everyone!
> > 
> > If you are experiencing DMA errors on a BCM4312, please test the
> > attached patch. It implements the PCI-E SERDES workaround, which the
> > hybrid driver is applying during early init to LP-PHY cards, and
> > which is a good candidate for the cause of the DMA error.
> > Note that this is not a final patch & it may cause collateral damage
> > for non-4312 cards; if it helps the 4312 problem, I will submit a
> > cleaned-up version.
> 
> This applies to 2.6.35.2, but does not compile:
> 
> drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_set_block':
> drivers/ssb/driver_pcicore.c:457: error: 'i' undeclared (first use in
> this function) drivers/ssb/driver_pcicore.c:457: error: (Each
> undeclared identifier is reported only once
> drivers/ssb/driver_pcicore.c:457: error: for each function it appears
> in.) drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_read':
> drivers/ssb/driver_pcicore.c:503: error: expected ';' before
> 'pcicore_write32'
> 
> With the obvious fixes (providing a variable 'i' of int type as the
> count variable and terminating the line which had no terminating
> semi-colon), it compiled OK and the first time I booted up, booted up
> OK but didn't fix the DMA error.  Subsequent attempts to boot up gave
> me a slew of errors on boot up so I am not sure what is going on
> there.
> 
> You might want to check that the obvious fixes to the patch are
> complete.

I have more or less tracked down what is happening.

The first thing to report is that this does not fix the DMA error.

The second thing is that with the patch applied, and with _all_
wireless/ssb modules blacklisted (ssb, b43, wl), if the wl module is
present the kernel bizarrely still tries to load it on boot up and
shortly thereafter hangs with a number of errors reported, which differ
on different boots (there is no particular pattern to them). That in
turn causes some file system corruption which affects further boots
even if the wl module is removed.  The corruption is not that serious
and appears only to affect the kernel image and/or the wl module.
Reinstalling both solved the problem, so far.  ef2fsck -f only reported
that the time stamps were wrong, but inodes and directory structures
were reported as OK.

But caveat testor so far as the corruption is concerned.  I might have
been lucky.

Chris

[RFT] BCM4312 users with DMA errors, please test!

[Larry Finger]

On 08/16/2010 05:35 PM, Chris Vine wrote:
> On Mon, 16 Aug 2010 20:41:54 +0100
> Chris Vine <chris@cvine.freeserve.co.uk> wrote:
> 
>> On Mon, 16 Aug 2010 19:59:36 +0200
>> G?bor Stefanik <netrolller.3d@gmail.com> wrote:
>>> Hello Everyone!
>>>
>>> If you are experiencing DMA errors on a BCM4312, please test the
>>> attached patch. It implements the PCI-E SERDES workaround, which the
>>> hybrid driver is applying during early init to LP-PHY cards, and
>>> which is a good candidate for the cause of the DMA error.
>>> Note that this is not a final patch & it may cause collateral damage
>>> for non-4312 cards; if it helps the 4312 problem, I will submit a
>>> cleaned-up version.
>>
>> This applies to 2.6.35.2, but does not compile:
>>
>> drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_set_block':
>> drivers/ssb/driver_pcicore.c:457: error: 'i' undeclared (first use in
>> this function) drivers/ssb/driver_pcicore.c:457: error: (Each
>> undeclared identifier is reported only once
>> drivers/ssb/driver_pcicore.c:457: error: for each function it appears
>> in.) drivers/ssb/driver_pcicore.c: In function 'ssb_pcie_mdio_read':
>> drivers/ssb/driver_pcicore.c:503: error: expected ';' before
>> 'pcicore_write32'
>>
>> With the obvious fixes (providing a variable 'i' of int type as the
>> count variable and terminating the line which had no terminating
>> semi-colon), it compiled OK and the first time I booted up, booted up
>> OK but didn't fix the DMA error.  Subsequent attempts to boot up gave
>> me a slew of errors on boot up so I am not sure what is going on
>> there.
>>
>> You might want to check that the obvious fixes to the patch are
>> complete.
> 
> I have more or less tracked down what is happening.
> 
> The first thing to report is that this does not fix the DMA error.
> 
> The second thing is that with the patch applied, and with _all_
> wireless/ssb modules blacklisted (ssb, b43, wl), if the wl module is
> present the kernel bizarrely still tries to load it on boot up and
> shortly thereafter hangs with a number of errors reported, which differ
> on different boots (there is no particular pattern to them). That in
> turn causes some file system corruption which affects further boots
> even if the wl module is removed.  The corruption is not that serious
> and appears only to affect the kernel image and/or the wl module.
> Reinstalling both solved the problem, so far.  ef2fsck -f only reported
> that the time stamps were wrong, but inodes and directory structures
> were reported as OK.
> 
> But caveat testor so far as the corruption is concerned.  I might have
> been lucky.

I tried to duplicate your boot problems without anything unexpected happening.

I don't know what happened, but I doubt that this ssb patch was responsible.

Larry

[RFT] BCM4312 users with DMA errors, please test!

[Chris Vine]

On Mon, 16 Aug 2010 18:53:41 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> I tried to duplicate your boot problems without anything unexpected
> happening.
> 
> I don't know what happened, but I doubt that this ssb patch was
> responsible.

I have reproduced it twice.  It is definitely the patch, in the sense
that it happens with the patch included (on two separate tests that I
have conducted) and never without.

I do not doubt that you do not experience this effect.  However, you
don't experience the DMA bug either.

Chris

[RFT] BCM4312 users with DMA errors, please test!

[Chris Vine]

On Tue, 17 Aug 2010 01:09:23 +0100
Chris Vine <chris@cvine.freeserve.co.uk> wrote:

> On Mon, 16 Aug 2010 18:53:41 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > I tried to duplicate your boot problems without anything unexpected
> > happening.
> > 
> > I don't know what happened, but I doubt that this ssb patch was
> > responsible.
> 
> I have reproduced it twice.  It is definitely the patch, in the sense
> that it happens with the patch included (on two separate tests that I
> have conducted) and never without.
> 
> I do not doubt that you do not experience this effect.  However, you
> don't experience the DMA bug either.

I probably also ought to say that this is with a stock 2.6.35.2
kernel.  You may be using wireless testing, although I doubt that makes
a difference.

Chris

[RFT] BCM4312 users with DMA errors, please test!

[Chris Vine]

On Tue, 17 Aug 2010 01:09:23 +0100
Chris Vine <chris@cvine.freeserve.co.uk> wrote:

> On Mon, 16 Aug 2010 18:53:41 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > I tried to duplicate your boot problems without anything unexpected
> > happening.
> > 
> > I don't know what happened, but I doubt that this ssb patch was
> > responsible.
> 
> I have reproduced it twice.  It is definitely the patch, in the sense
> that it happens with the patch included (on two separate tests that I
> have conducted) and never without.
> 
> I do not doubt that you do not experience this effect.  However, you
> don't experience the DMA bug either.

Out of interest, which version of the wl module do you have installed,
as I wonder if that makes a difference?   (As I said in my e-mail on
this, this problem only occurs if the wl module is available to the
kernel.)

Chris

[RFT] BCM4312 users with DMA errors, please test!

[Larry Finger]

On 08/16/2010 07:14 PM, Chris Vine wrote:
>>
>> I have reproduced it twice.  It is definitely the patch, in the sense
>> that it happens with the patch included (on two separate tests that I
>> have conducted) and never without.
>>
>> I do not doubt that you do not experience this effect.  However, you
>> don't experience the DMA bug either.
> 
> Out of interest, which version of the wl module do you have installed,
> as I wonder if that makes a difference?   (As I said in my e-mail on
> this, this problem only occurs if the wl module is available to the
> kernel.)

My wl came from hybrid-portsrc-x86_32-v5.60.48.36.tar.gz. My kernel is
2.6.36-rc1 from mainline.

Very strange that a patch to ssb, which is a module that cannot even load due to
being blacklisted, can cause this kind of problem. Are you warm or cold rebooting?

Larry

[RFT] BCM4312 users with DMA errors, please test!

[Chris Vine]

On Mon, 16 Aug 2010 20:01:45 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> My wl came from hybrid-portsrc-x86_32-v5.60.48.36.tar.gz. My kernel is
> 2.6.36-rc1 from mainline.
> 
> Very strange that a patch to ssb, which is a module that cannot even
> load due to being blacklisted, can cause this kind of problem. Are
> you warm or cold rebooting?

I am using the same version of wl.

On booting up my netbook this morning, I found that I get a wholesome
set of bugs reported by dmesg, even without wl available to the
kernel and with the ssb patch reverted. I think the ssb patch is an
innocent bystander which just happened first to reveal a bug in the
2.6.35.2 kernel.  A lot seems to depend on the starting state of the
hardware - a cold boot in a stock 2.6.35.2 kernel will trigger it
(what I got this morning). A warm boot on a 2.6.35.2 kernel with the ssb
patch will also trigger it (what I got yesterday).

The fact that something tries to load a blacklisted wl module would
seem to show there is something fairly fundamentally amiss, possibly
with the ACPI code. In any event, the conclusion I have reached is that
the 2.6.35.2 kernel is hopelessly broken on my netbook hardware. I do
not now think there is any file system corruption: it just gave that
appearance because of the saving of the state of the machine between
warm boots.

Reverting to 2.6.35.1 solves this.  Probably 2.6.36-rc1 would be OK as
well.  I might later today try the ssb patch on the 2.6.35.1 kernel,
but it doesn't look as if it solves the DMA errors.  However,
yesterday's tests clearly aren't conclusive about anything.

Chris

[RFT] BCM4312 users with DMA errors, please test!

[Chris Vine]

On Tue, 17 Aug 2010 13:23:37 +0100
Chris Vine <chris@cvine.freeserve.co.uk> wrote:
> Reverting to 2.6.35.1 solves this.  Probably 2.6.36-rc1 would be OK as
> well.  I might later today try the ssb patch on the 2.6.35.1 kernel,
> but it doesn't look as if it solves the DMA errors.  However,
> yesterday's tests clearly aren't conclusive about anything.

I have applied the patch to 2.6.35.1, and it does not appear to have
any effect on the DMA errors.

Chris

[RFT] BCM4312 users with DMA errors, please test!

[Gábor Stefanik]

On Tue, Aug 17, 2010 at 10:28 PM, Chris Vine
<chris@cvine.freeserve.co.uk> wrote:
> On Tue, 17 Aug 2010 13:23:37 +0100
> Chris Vine <chris@cvine.freeserve.co.uk> wrote:
>> Reverting to 2.6.35.1 solves this. ?Probably 2.6.36-rc1 would be OK as
>> well. ?I might later today try the ssb patch on the 2.6.35.1 kernel,
>> but it doesn't look as if it solves the DMA errors. ?However,
>> yesterday's tests clearly aren't conclusive about anything.
>
> I have applied the patch to 2.6.35.1, and it does not appear to have
> any effect on the DMA errors.
>
> Chris
>
>
>

Thanks! That's what I was ultimately interested in. So, we now know
it's not the SERDES workaround. (Or maybe it needs to be performed at
a different time.)