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

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

[Gábor Stefanik]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

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

[-- Attachment #2: pcie_serdes_workaround.diff --]
[-- Type: application/octet-stream, Size: 3421 bytes --]

diff --git a/drivers/ssb/driver_pcicore.c b/drivers/ssb/driver_pcicore.c
index 0e8d352..9f5c5e2 100644
--- a/drivers/ssb/driver_pcicore.c
+++ b/drivers/ssb/driver_pcicore.c
@@ -446,13 +446,71 @@ static void ssb_pcie_write(struct ssb_pcicore *pc, u32 address, u32 data)
 	pcicore_write32(pc, 0x134, data);
 }
 
+static bool ssb_pcie_mdio_set_block(struct ssb_pcicore *pc, u8 device)
+{
+	const u16 mdio_control = 0x128;
+	const u16 mdio_data = 0x12C;
+
+	pcicore_write32(pc, mdio_data, 0x57C20000 | (device << 4));
+	udelay(10);
+
+	for (i = 0; i < 200; i++) {
+		if (pcicore_read32(pc, mdio_control) & 0x100)
+			return true;
+		msleep(1);
+	}
+
+	return false;
+}
+
+static u16 ssb_pcie_mdio_read(struct ssb_pcicore *pc, u8 device,
+				u8 address)
+{
+	const u16 mdio_control = 0x128;
+	const u16 mdio_data = 0x12C;
+	u32 v;
+	int i, imax;
+	u16 data;
+
+	v = 0x80; /* Enable Preamble Sequence */
+	v |= 0x2; /* MDIO Clock Divisor */
+	pcicore_write32(pc, mdio_control, v);
+
+	v = (1 << 30); /* Start of Transaction */
+	v |= (1 << 29); /* Read Transaction */
+	v |= (1 << 17); /* Turnaround */
+
+	if (pc->dev->id.revision >= 10) {
+		if (!ssb_pcie_mdio_set_block(pc, device))
+			return 0;
+		imax = 200;
+	} else {
+		v |= (u32)device << 22;
+		imax = 10;
+	}
+	v |= (u32)address << 18;
+	pcicore_write32(pc, mdio_data, v);
+	/* Wait for the device to complete the transaction */
+	udelay(10);
+	for (i = 0; i < imax; i++) {
+		v = pcicore_read32(pc, mdio_control);
+		if (v & 0x100 /* Trans complete */)
+			break;
+		msleep(1);
+	}
+	udelay(10);
+	data = pcicore_read32(pc, mdio_data) & 0xFFFF
+	pcicore_write32(pc, mdio_control, 0);
+	return data;
+}
+
 static void ssb_pcie_mdio_write(struct ssb_pcicore *pc, u8 device,
 				u8 address, u16 data)
 {
 	const u16 mdio_control = 0x128;
 	const u16 mdio_data = 0x12C;
 	u32 v;
-	int i;
+	int i, imax;
 
 	v = 0x80; /* Enable Preamble Sequence */
 	v |= 0x2; /* MDIO Clock Divisor */
@@ -461,13 +519,21 @@ static void ssb_pcie_mdio_write(struct ssb_pcicore *pc, u8 device,
 	v = (1 << 30); /* Start of Transaction */
 	v |= (1 << 28); /* Write Transaction */
 	v |= (1 << 17); /* Turnaround */
-	v |= (u32)device << 22;
+	
+	if (pc->dev->id.revision >= 10) {
+		if (!ssb_pcie_mdio_set_block(pc, device))
+			return;
+		imax = 200;
+	} else {
+		v |= (u32)device << 22;
+		imax = 10;
+	}
 	v |= (u32)address << 18;
 	v |= data;
 	pcicore_write32(pc, mdio_data, v);
 	/* Wait for the device to complete the transaction */
 	udelay(10);
-	for (i = 0; i < 10; i++) {
+	for (i = 0; i < imax; i++) {
 		v = pcicore_read32(pc, mdio_control);
 		if (v & 0x100 /* Trans complete */)
 			break;
@@ -591,6 +657,20 @@ int ssb_pcicore_dev_irqvecs_enable(struct ssb_pcicore *pc,
 			tmp = ssb_pcie_read(pc, 0x100);
 			tmp |= 0x40;
 			ssb_pcie_write(pc, 0x100, tmp);
+		} else {
+			const u8 serdes_pll_device = 0x1D;
+			const u8 serdes_rx_device = 0x1F;
+
+			/* PCI-E PHY Status register */
+			if (ssb_pcie_read(pc, 0x204) & 0x10)
+				ssb_pcie_mdio_write(pc, serdes_rx_device,
+						    1 /* Control */, 0xC0);
+			else
+				ssb_pcie_mdio_write(pc, serdes_rx_device,
+						    1 /* Control */, 0x80);
+			ssb_pcie_mdio_write(pc, serdes_pll_device, 1,
+				ssb_pcie_mdio_read(pc, serdes_pll_device, 1) &
+				~0x4000);
 		}
 	}
 	pc->setup_done = 1;

Re: [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. :-)

Re: [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. :-)

Re: [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

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

[Gábor Stefanik]

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]

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. :-)

[-- Attachment #2: pcie_serdes_workaround.diff --]
[-- Type: application/octet-stream, Size: 3429 bytes --]

diff --git a/drivers/ssb/driver_pcicore.c b/drivers/ssb/driver_pcicore.c
index 0e8d352..9f5c5e2 100644
--- a/drivers/ssb/driver_pcicore.c
+++ b/drivers/ssb/driver_pcicore.c
@@ -446,13 +446,71 @@ static void ssb_pcie_write(struct ssb_pcicore *pc, u32 address, u32 data)
 	pcicore_write32(pc, 0x134, data);
 }
 
+static bool ssb_pcie_mdio_set_block(struct ssb_pcicore *pc, u8 device)
+{
+	const u16 mdio_control = 0x128;
+	const u16 mdio_data = 0x12C;
+
+	pcicore_write32(pc, mdio_data, 0x57C20000 | (device << 4));
+	udelay(10);
+	int i;
+	for (i = 0; i < 200; i++) {
+		if (pcicore_read32(pc, mdio_control) & 0x100)
+			return true;
+		msleep(1);
+	}
+
+	return false;
+}
+
+static u16 ssb_pcie_mdio_read(struct ssb_pcicore *pc, u8 device,
+				u8 address)
+{
+	const u16 mdio_control = 0x128;
+	const u16 mdio_data = 0x12C;
+	u32 v;
+	int i, imax;
+	u16 data;
+
+	v = 0x80; /* Enable Preamble Sequence */
+	v |= 0x2; /* MDIO Clock Divisor */
+	pcicore_write32(pc, mdio_control, v);
+
+	v = (1 << 30); /* Start of Transaction */
+	v |= (1 << 29); /* Read Transaction */
+	v |= (1 << 17); /* Turnaround */
+
+	if (pc->dev->id.revision >= 10) {
+		if (!ssb_pcie_mdio_set_block(pc, device))
+			return 0;
+		imax = 200;
+	} else {
+		v |= (u32)device << 22;
+		imax = 10;
+	}
+	v |= (u32)address << 18;
+	pcicore_write32(pc, mdio_data, v);
+	/* Wait for the device to complete the transaction */
+	udelay(10);
+	for (i = 0; i < imax; i++) {
+		v = pcicore_read32(pc, mdio_control);
+		if (v & 0x100 /* Trans complete */)
+			break;
+		msleep(1);
+	}
+	udelay(10);
+	data = pcicore_read32(pc, mdio_data) & 0xFFFF;
+	pcicore_write32(pc, mdio_control, 0);
+	return data;
+}
+
 static void ssb_pcie_mdio_write(struct ssb_pcicore *pc, u8 device,
 				u8 address, u16 data)
 {
 	const u16 mdio_control = 0x128;
 	const u16 mdio_data = 0x12C;
 	u32 v;
-	int i;
+	int i, imax;
 
 	v = 0x80; /* Enable Preamble Sequence */
 	v |= 0x2; /* MDIO Clock Divisor */
@@ -461,13 +519,21 @@ static void ssb_pcie_mdio_write(struct ssb_pcicore *pc, u8 device,
 	v = (1 << 30); /* Start of Transaction */
 	v |= (1 << 28); /* Write Transaction */
 	v |= (1 << 17); /* Turnaround */
-	v |= (u32)device << 22;
+	
+	if (pc->dev->id.revision >= 10) {
+		if (!ssb_pcie_mdio_set_block(pc, device))
+			return;
+		imax = 200;
+	} else {
+		v |= (u32)device << 22;
+		imax = 10;
+	}
 	v |= (u32)address << 18;
 	v |= data;
 	pcicore_write32(pc, mdio_data, v);
 	/* Wait for the device to complete the transaction */
 	udelay(10);
-	for (i = 0; i < 10; i++) {
+	for (i = 0; i < imax; i++) {
 		v = pcicore_read32(pc, mdio_control);
 		if (v & 0x100 /* Trans complete */)
 			break;
@@ -591,6 +657,20 @@ int ssb_pcicore_dev_irqvecs_enable(struct ssb_pcicore *pc,
 			tmp = ssb_pcie_read(pc, 0x100);
 			tmp |= 0x40;
 			ssb_pcie_write(pc, 0x100, tmp);
+		} else {
+			const u8 serdes_pll_device = 0x1D;
+			const u8 serdes_rx_device = 0x1F;
+
+			/* PCI-E PHY Status register */
+			if (ssb_pcie_read(pc, 0x204) & 0x10)
+				ssb_pcie_mdio_write(pc, serdes_rx_device,
+						    1 /* Control */, 0xC0);
+			else
+				ssb_pcie_mdio_write(pc, serdes_rx_device,
+						    1 /* Control */, 0x80);
+			ssb_pcie_mdio_write(pc, serdes_pll_device, 1,
+				ssb_pcie_mdio_read(pc, serdes_pll_device, 1) &
+				~0x4000);
 		}
 	}
 	pc->setup_done = 1;

Re: [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

Re: [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.

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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

Re: [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

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

[Arthur Moreira]

all right
but i try to test with pacience, but i am newer in module compilation and paths
if you create a topic only for the device 4353 is better.

and obvios, ever... sorry for the bad english, but a talk from brazil.

if you can, try to post the step by step for the path aplication..
for the diff file and the path file... i know to aply the path for the
path comand (path <# file)
but i dont know the essencial.

if you send me modules for test. tks.
and the steps



              Arthur Moreira




2010/8/16 Gábor Stefanik <netrolller.3d@gmail.com>:
> 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. :-)
>

Re: [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

Re: [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.)