Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Gábor Stefanik]

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

On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
<william.bourque@polymtl.ca> wrote:
> I confirm, it still crashes on my notebook as well. However the new
> "fallback to PIO" behavior introduced earlier do a fine job getting it back
> on track.
>
> Btw, you are often refering to some documentation that document the register
> for this device, where could I find it? I probably won't be able to do much,
> but I'm curious to see...
>
> - William

Thanks!

New test patch attached.

Please CC linux-wireless@vger.kernel.org on further e-mails,
bcm43xx-dev appears to be having problems.

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

[-- Attachment #2: lpphy-test.patch --]
[-- Type: application/octet-stream, Size: 2992 bytes --]

diff --git a/drivers/ssb/driver_chipcommon.c b/drivers/ssb/driver_chipcommon.c
index 9681536..a3ab04a 100644
--- a/drivers/ssb/driver_chipcommon.c
+++ b/drivers/ssb/driver_chipcommon.c
@@ -233,6 +233,12 @@ void ssb_chipcommon_init(struct ssb_chipcommon *cc)
 {
 	if (!cc->dev)
 		return; /* We don't have a ChipCommon */
+
+	if (cc->dev->id.revision >= 20) {
+		chipco_write32(cc, SSB_CHIPCO_GPIO_PULLUP, 0);
+		chipco_write32(cc, SSB_CHIPCO_GPIO_PULLDN, 0);
+	}
+
 	ssb_pmu_init(cc);
 	chipco_powercontrol_init(cc);
 	ssb_chipco_set_clockmode(cc, SSB_CLKMODE_FAST);
diff --git a/drivers/ssb/driver_chipcommon_pmu.c b/drivers/ssb/driver_chipcommon_pmu.c
index 3d55124..1fa1648 100644
--- a/drivers/ssb/driver_chipcommon_pmu.c
+++ b/drivers/ssb/driver_chipcommon_pmu.c
@@ -427,7 +427,9 @@ static void ssb_pmu_resources_init(struct ssb_chipcommon *cc)
 		/* We keep the default settings:
 		 * min_msk = 0xCBB
 		 * max_msk = 0x7FFFF
+		 * However, we need to actually write min_msk to the device.
 		 */
+		min_msk = 0xCBB;
 		break;
 	case 0x4325:
 		/* Power OTP down later. */
@@ -516,15 +518,14 @@ void ssb_pmu_init(struct ssb_chipcommon *cc)
 	ssb_dprintk(KERN_DEBUG PFX "Found rev %u PMU (capabilities 0x%08X)\n",
 		    cc->pmu.rev, pmucap);
 
-	if (cc->pmu.rev >= 1) {
-		if ((bus->chip_id == 0x4325) && (bus->chip_rev < 2)) {
-			chipco_mask32(cc, SSB_CHIPCO_PMU_CTL,
-				      ~SSB_CHIPCO_PMU_CTL_NOILPONW);
-		} else {
-			chipco_set32(cc, SSB_CHIPCO_PMU_CTL,
-				     SSB_CHIPCO_PMU_CTL_NOILPONW);
-		}
+	if (cc->pmu.rev == 1) {
+		chipco_mask32(cc, SSB_CHIPCO_PMU_CTL,
+			      ~SSB_CHIPCO_PMU_CTL_NOILPONW);
+	} else {
+		chipco_set32(cc, SSB_CHIPCO_PMU_CTL,
+			     SSB_CHIPCO_PMU_CTL_NOILPONW);
 	}
+
 	ssb_pmu_pll_init(cc);
 	ssb_pmu_resources_init(cc);
 }
diff --git a/drivers/ssb/driver_pcicore.c b/drivers/ssb/driver_pcicore.c
index f1dcd79..65923d8 100644
--- a/drivers/ssb/driver_pcicore.c
+++ b/drivers/ssb/driver_pcicore.c
@@ -441,6 +441,12 @@ static void ssb_pcicore_init_clientmode(struct ssb_pcicore *pc)
 {
 	/* Disable PCI interrupts. */
 	ssb_write32(pc->dev, SSB_INTVEC, 0);
+
+	/* PCI-E misc configuration */
+	/* HACK This looks wrong, but this is what the vendor driver does... */
+	ssb_write32(pc->dev, 0x280a, ssb_read32(pc->dev, 0x280a) | 0x8000);
+	/* And now as the specs say: */
+	ssb_write32(pc->dev, 0x80a, ssb_read32(pc->dev, 0x80a) | 0x8000);
 }
 
 void ssb_pcicore_init(struct ssb_pcicore *pc)
diff --git a/include/linux/ssb/ssb_driver_chipcommon.h b/include/linux/ssb/ssb_driver_chipcommon.h
index 4e27acf..dc46c1b 100644
--- a/include/linux/ssb/ssb_driver_chipcommon.h
+++ b/include/linux/ssb/ssb_driver_chipcommon.h
@@ -122,6 +122,8 @@
 #define SSB_CHIPCO_FLASHDATA		0x0048
 #define SSB_CHIPCO_BCAST_ADDR		0x0050
 #define SSB_CHIPCO_BCAST_DATA		0x0054
+#define SSB_CHIPCO_GPIO_PULLUP		0x0058
+#define SSB_CHIPCO_GPIO_PULLDN		0x005C
 #define SSB_CHIPCO_GPIOIN		0x0060
 #define SSB_CHIPCO_GPIOOUT		0x0064
 #define SSB_CHIPCO_GPIOOUTEN		0x0068

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Rafał Miłecki]

2010/2/28 Gábor Stefanik <netrolller.3d@gmail.com>:
> On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
> <william.bourque@polymtl.ca> wrote:
>> I confirm, it still crashes on my notebook as well. However the new
>> "fallback to PIO" behavior introduced earlier do a fine job getting it back
>> on track.
>>
>> Btw, you are often refering to some documentation that document the register
>> for this device, where could I find it? I probably won't be able to do much,
>> but I'm curious to see...
>>
> New test patch attached.

Patch adds this /incorrect/ ssb_write32 to 0x280a, right? By incorrect
I mean over range.

Would be nice to see if dumping tool generates same log about 0x280a
now (for wl and b43 patched).

-- 
Rafał

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Gábor Stefanik]

2010/2/28 Rafał Miłecki <zajec5@gmail.com>:
> 2010/2/28 Gábor Stefanik <netrolller.3d@gmail.com>:
>> On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
>> <william.bourque@polymtl.ca> wrote:
>>> I confirm, it still crashes on my notebook as well. However the new
>>> "fallback to PIO" behavior introduced earlier do a fine job getting it back
>>> on track.
>>>
>>> Btw, you are often refering to some documentation that document the register
>>> for this device, where could I find it? I probably won't be able to do much,
>>> but I'm curious to see...
>>>
>> New test patch attached.
>
> Patch adds this /incorrect/ ssb_write32 to 0x280a, right? By incorrect
> I mean over range.
>
> Would be nice to see if dumping tool generates same log about 0x280a
> now (for wl and b43 patched).

I added both the "incorrect" 0x280a and the "correct" 0x80a here - it
is possible that the 0x280a one takes advantage of an undocumented
feature in PhoenixBIOS.

>
> --
> Rafał
>



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

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Michael Buesch]

On Sunday 28 February 2010 19:52:53 Gábor Stefanik wrote:
> 2010/2/28 Rafał Miłecki <zajec5@gmail.com>:
> > 2010/2/28 Gábor Stefanik <netrolller.3d@gmail.com>:
> >> On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
> >> <william.bourque@polymtl.ca> wrote:
> >>> I confirm, it still crashes on my notebook as well. However the new
> >>> "fallback to PIO" behavior introduced earlier do a fine job getting it back
> >>> on track.
> >>>
> >>> Btw, you are often refering to some documentation that document the register
> >>> for this device, where could I find it? I probably won't be able to do much,
> >>> but I'm curious to see...
> >>>
> >> New test patch attached.
> >
> > Patch adds this /incorrect/ ssb_write32 to 0x280a, right? By incorrect
> > I mean over range.
> >
> > Would be nice to see if dumping tool generates same log about 0x280a
> > now (for wl and b43 patched).
> 
> I added both the "incorrect" 0x280a and the "correct" 0x80a here - it
> is possible that the 0x280a one takes advantage of an undocumented
> feature in PhoenixBIOS.

Hell, it is pure luck that this does not blow up the whole machine.

Please check the memory region of your wireless card with lspci -vvnn:

0001:10:12.0 Network controller [0280]: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller [14e4:4320] (rev 03)
        Subsystem: Apple Computer Inc. AirPort Extreme [106b:004e]
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 16
        Interrupt: pin A routed to IRQ 52
        Region 0: Memory at a0006000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: <access denied>
        Kernel driver in use: b43-pci-bridge
        Kernel modules: ssb

It says 8k for all of my devices there. So an MMIO write to 0x2000 and above
writes to completely random memory.

-- 
Greetings, Michael.

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Chris Vine]

On Sun, 28 Feb 2010 19:58:11 +0100
Michael Buesch <mb@bu3sch.de> wrote:
> It says 8k for all of my devices there. So an MMIO write to 0x2000
> and above writes to completely random memory.
> 
My BCM4312 device is 16K:

  Region 0: Memory at f8000000 (64-bit, non-prefetchable) [size=16K]

Chris

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Michael Buesch]

On Sunday 28 February 2010 21:30:38 Chris Vine wrote:
> On Sun, 28 Feb 2010 19:58:11 +0100
> Michael Buesch <mb@bu3sch.de> wrote:
> > It says 8k for all of my devices there. So an MMIO write to 0x2000
> > and above writes to completely random memory.
> > 
> My BCM4312 device is 16K:
> 
>   Region 0: Memory at f8000000 (64-bit, non-prefetchable) [size=16K]

Ok, then this write is _clearly_ not to be done unconditionally.

-- 
Greetings, Michael.

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[William Bourque]

Chris Vine wrote:
> On Sun, 28 Feb 2010 19:58:11 +0100
> Michael Buesch <mb@bu3sch.de> wrote:
>> It says 8k for all of my devices there. So an MMIO write to 0x2000
>> and above writes to completely random memory.
>>
> My BCM4312 device is 16K:
> 
>   Region 0: Memory at f8000000 (64-bit, non-prefetchable) [size=16K]


Now that you mention it, mine as well :

01:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)
         Subsystem: Hewlett-Packard Company Device 1507
         Flags: bus master, fast devsel, latency 0, IRQ 16
         Memory at feafc000 (64-bit, non-prefetchable) [size=16K]

Are all the failing devices have a 16k mem space?

- William

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Chris Vine]

On Sun, 28 Feb 2010 15:51:14 -0500
William Bourque <william.bourque@polymtl.ca> wrote:
> Chris Vine wrote:
> > On Sun, 28 Feb 2010 19:58:11 +0100
> > Michael Buesch <mb@bu3sch.de> wrote:
> >> It says 8k for all of my devices there. So an MMIO write to 0x2000
> >> and above writes to completely random memory.
> >>
> > My BCM4312 device is 16K:
> > 
> >   Region 0: Memory at f8000000 (64-bit, non-prefetchable) [size=16K]
> 
> 
> Now that you mention it, mine as well :
> 
> 01:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g
> (rev 01) Subsystem: Hewlett-Packard Company Device 1507
>          Flags: bus master, fast devsel, latency 0, IRQ 16
>          Memory at feafc000 (64-bit, non-prefetchable) [size=16K]
> 
> Are all the failing devices have a 16k mem space?

And with 64-bit layout?  (Michael's was 32-bit.)

Chris

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[William Bourque]

> New test patch attached.
> 
> Please CC linux-wireless@vger.kernel.org on further e-mails,
> bcm43xx-dev appears to be having problems.
> 

Hmm... I don't know if it is only coincidence, but this one seems to 
help somehow.

The driver raised the DMA error again, but instead of being as soon as I 
brought up the interface, I had to stresstest (to transfert a file at 
full speed from my LAN) to make it happens. Before that I was able to 
DMA normally (loading web page ...).

- William

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Chris Vine]

On Sun, 28 Feb 2010 14:44:12 -0500
William Bourque <william.bourque@polymtl.ca> wrote:
> > New test patch attached.
> > 
> > Please CC linux-wireless@vger.kernel.org on further e-mails,
> > bcm43xx-dev appears to be having problems.
> > 
> 
> Hmm... I don't know if it is only coincidence, but this one seems to 
> help somehow.
> 
> The driver raised the DMA error again, but instead of being as soon
> as I brought up the interface, I had to stresstest (to transfert a
> file at full speed from my LAN) to make it happens. Before that I was
> able to DMA normally (loading web page ...).

I also found that it stayed up marginally longer (ie about 2 seconds
longer in my case) but I think this is probably co-incidence.

On commenting out the line setting the 0x280a memory location, and
leaving the line setting the 0x80a memory location, it failed
immediately; but these difference may just be random effects.

Chris

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Nathan Schulte]

2010/2/28 Gábor Stefanik <netrolller.3d@gmail.com>:
> OK, this dump shows the 0x280a write happening with core 3, i.e. PCIE,
> active. So, it is indeed probably the "PCIE misc configuration"
> routine. Why it's 0x280a is still a mystery to me, it should be 0x100a
> according to the specs.
Unless I'm reading the logs wrong, isn't wl setting bit 0x8000 when
core 1 is mapped (0 indexed cores, 0x18001000 mapped to space 0)?
And b43 appears to do it when core 0 is mapped (0x18000000 mapped to
space 0).  b43 also reads from 0x100a after writing to 0x280a, and it
reads as 0x8000 not set (while the 0x280a check show it is set).

This is when comparing the wl_cold and b43_cold logs.

-Nate

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Gábor Stefanik]

2010/2/28 Nathan Schulte <reklipz@gmail.com>:
> 2010/2/28 Gábor Stefanik <netrolller.3d@gmail.com>:
>> OK, this dump shows the 0x280a write happening with core 3, i.e. PCIE,
>> active. So, it is indeed probably the "PCIE misc configuration"
>> routine. Why it's 0x280a is still a mystery to me, it should be 0x100a
>> according to the specs.
> Unless I'm reading the logs wrong, isn't wl setting bit 0x8000 when
> core 1 is mapped (0 indexed cores, 0x18001000 mapped to space 0)?
> And b43 appears to do it when core 0 is mapped (0x18000000 mapped to
> space 0).  b43 also reads from 0x100a after writing to 0x280a, and it
> reads as 0x8000 not set (while the 0x280a check show it is set).
>
> This is when comparing the wl_cold and b43_cold logs.
>
> -Nate
>

The latest patch, which is a partial success according to some
testers, writes to core 1 (PCI-E) instead of core 0 (ChipCommon).

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

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Nathan Schulte]

2010/2/28 Gábor Stefanik <netrolller.3d@gmail.com>:
> The latest patch, which is a partial success according to some
> testers, writes to core 1 (PCI-E) instead of core 0 (ChipCommon).
Then either I am misinterpreting the logs, or the last patch in this
thread is not the patch you are referring to.

A successful write/read to PCI config register 0x80 indicates that any
following MMIO read/writes will be done on that core, correct?

With the lpphy-test.patch you posted earlier, I see the following
output from b43:
Wrote 0x18003000 to pos 0x80
Read 0x18003000 from pos 0x80
MAP 1 0xf4000000 0xffffc900225b8000 0x4000 0x0 0
[snip some mmio read/writes and some PCI config read/writes]
Wrote 0x18000000 to pos 0x80
Read 0x18000000 from pos 0x80
R 4 1 0xf400280a 0x6dbe 0x0 0
W 4 1 0xf400280a 0xedbe 0x0 0

This first maps core 3, does some read/writes with it, then maps core
0, and sets bit 0x8000, correct?

Also, is the address space limited to the 4k range?  wl maps core 1,
but sets bit 0x8000 at address 0x280a, which when added to 0x18001000
is 0x1800380a, right in the PCIE cores address space (for address
0x100a).

And finally, unless the linux-wireless@vger.kernel.org mailing list is
currently down as well, I think gmail may be the one causing my
messages to not be delivered to the list, as my last message isn't
showing up on the linux-wireless list either.

-Nate

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Michael Buesch]

On Monday 01 March 2010 00:38:16 Nathan Schulte wrote:
> 2010/2/28 Gábor Stefanik <netrolller.3d@gmail.com>:
> > The latest patch, which is a partial success according to some
> > testers, writes to core 1 (PCI-E) instead of core 0 (ChipCommon).
> Then either I am misinterpreting the logs, or the last patch in this
> thread is not the patch you are referring to.
> 
> A successful write/read to PCI config register 0x80 indicates that any
> following MMIO read/writes will be done on that core, correct?
> 
> With the lpphy-test.patch you posted earlier, I see the following
> output from b43:
> Wrote 0x18003000 to pos 0x80
> Read 0x18003000 from pos 0x80
> MAP 1 0xf4000000 0xffffc900225b8000 0x4000 0x0 0
> [snip some mmio read/writes and some PCI config read/writes]
> Wrote 0x18000000 to pos 0x80
> Read 0x18000000 from pos 0x80
> R 4 1 0xf400280a 0x6dbe 0x0 0
> W 4 1 0xf400280a 0xedbe 0x0 0
> 
> This first maps core 3, does some read/writes with it, then maps core
> 0, and sets bit 0x8000, correct?
> 
> Also, is the address space limited to the 4k range?  wl maps core 1,
> but sets bit 0x8000 at address 0x280a, which when added to 0x18001000
> is 0x1800380a, right in the PCIE cores address space (for address
> 0x100a).

Well, you are confusing address spaces here.

On a PCI based SSB device all host-side MMIO transfers go into
the PCI device's address space first. The core-switching moves the window of
the SSB address space that is mapped into 0-0xFFF of the PCI address space.
So if you write to anything above 0xFFF on the PCI device, the write will
not (directly) map to the SSB bus or any device on it.
On the PCI device there is more stuff mapped on top of the SSB sliding
window. For example the SPROM is mapped right on top of it.

So it might be the case that on a PCI-E device the PCI-E-core's registers
are permanently mapped into 0x2000 of the PCI address apace. This is to
avoid sliding the SSB address space window when accessing the PCI-E core.
This can have several reasons: For one speed (unlikely) and for another
to avoid concurrency and ugly races when we need to access the PCI-E core
while the wireless core is already running and generating interrupts.
Note that this is a GUESS, but it would make sense to me.
It would be cool if somebody could compare more registers of the PCI-E
core using the sliding window and the 0x2000 + reg method to check my theory.

-- 
Greetings, Michael.

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Michael Buesch]

On Monday 01 March 2010 01:22:50 Michael Buesch wrote:
> Well, you are confusing address spaces here.
>
> On a PCI based SSB device all host-side MMIO transfers go into
> the PCI device's address space first. The core-switching moves the window of
> the SSB address space that is mapped into 0-0xFFF of the PCI address space.
> So if you write to anything above 0xFFF on the PCI device, the write will
> not (directly) map to the SSB bus or any device on it.
> On the PCI device there is more stuff mapped on top of the SSB sliding
> window. For example the SPROM is mapped right on top of it.
> 
> So it might be the case that on a PCI-E device the PCI-E-core's registers
> are permanently mapped into 0x2000 of the PCI address apace. This is to
> avoid sliding the SSB address space window when accessing the PCI-E core.
> This can have several reasons: For one speed (unlikely) and for another
> to avoid concurrency and ugly races when we need to access the PCI-E core
> while the wireless core is already running and generating interrupts.
> Note that this is a GUESS, but it would make sense to me.
> It would be cool if somebody could compare more registers of the PCI-E
> core using the sliding window and the 0x2000 + reg method to check my theory.
> 

So what's the status on this? I think the fact that the testing patch showed some
improvement is a clear indicator that something in the PCI-E core init is wrong.
It's also not surprising that something is going wrong there. The whole PCI-E core
code basically is undebugged. I wrote most of it long time ago, but I still
don't have a device that tests it (and probably won't get one anytime soon).
So I'm really not surprised that there are bugs. There also are missing parts.

A bug in the PCI-E core code is able to show such behavior, because all memory
transfers (MMIO and DMA) from the PCI device to the wireless core are translated
by the PCI-E core.
I think the whole PCI-E core code has to be audited (also the specs, probably).

-- 
Greetings, Michael.

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Larry Finger]

On 03/02/2010 03:57 PM, Michael Buesch wrote:
> 
> So what's the status on this? I think the fact that the testing patch showed some
> improvement is a clear indicator that something in the PCI-E core init is wrong.
> It's also not surprising that something is going wrong there. The whole PCI-E core
> code basically is undebugged. I wrote most of it long time ago, but I still
> don't have a device that tests it (and probably won't get one anytime soon).
> So I'm really not surprised that there are bugs. There also are missing parts.
> 
> A bug in the PCI-E core code is able to show such behavior, because all memory
> transfers (MMIO and DMA) from the PCI device to the wireless core are translated
> by the PCI-E core.
> I think the whole PCI-E core code has to be audited (also the specs, probably).

You are right about the audit of the PCIe code and specs. Some of the MMIO
sequences found for wl and missing in b43 come from the code described in
http://bcm-v4.sipsolutions.net/PCI-E; however, that code needs to be checked as
at least one routine is missing, I have not yet had a chance to go through it,
but I hope to soon.

Larry

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[William Bourque]

Michael Buesch wrote:
> On Monday 01 March 2010 01:22:50 Michael Buesch wrote:
>> Well, you are confusing address spaces here.
>>
>> On a PCI based SSB device all host-side MMIO transfers go into
>> the PCI device's address space first. The core-switching moves the window of
>> the SSB address space that is mapped into 0-0xFFF of the PCI address space.
>> So if you write to anything above 0xFFF on the PCI device, the write will
>> not (directly) map to the SSB bus or any device on it.
>> On the PCI device there is more stuff mapped on top of the SSB sliding
>> window. For example the SPROM is mapped right on top of it.
>>
>> So it might be the case that on a PCI-E device the PCI-E-core's registers
>> are permanently mapped into 0x2000 of the PCI address apace. This is to
>> avoid sliding the SSB address space window when accessing the PCI-E core.
>> This can have several reasons: For one speed (unlikely) and for another
>> to avoid concurrency and ugly races when we need to access the PCI-E core
>> while the wireless core is already running and generating interrupts.
>> Note that this is a GUESS, but it would make sense to me.
>> It would be cool if somebody could compare more registers of the PCI-E
>> core using the sliding window and the 0x2000 + reg method to check my theory.
>>
> 
> So what's the status on this? I think the fact that the testing patch showed some
> improvement is a clear indicator that something in the PCI-E core init is wrong.
> It's also not surprising that something is going wrong there. The whole PCI-E core
> code basically is undebugged. I wrote most of it long time ago, but I still
> don't have a device that tests it (and probably won't get one anytime soon).
> So I'm really not surprised that there are bugs. There also are missing parts.
> 
> A bug in the PCI-E core code is able to show such behavior, because all memory
> transfers (MMIO and DMA) from the PCI device to the wireless core are translated
> by the PCI-E core.
> I think the whole PCI-E core code has to be audited (also the specs, probably).
> 

So if I get this right, this code is responsible of handling the b43
devices, as well as several other PCI-E devices, correct?

Because now that you mention this, the wired network card (Marvel Yukon,
with sky2 drivers) on this netbook also have a tons of issue (doesn't
show in lspci on a clean boot, oops the kernel if network cable is
unplugged while in use, fails to load if the module is ever unloaded, ... )
I thought it was unrelated but from your comment, I feel like this could
be linked to the same PCI-E bugs as well.

- William

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Michael Buesch]

On Tuesday 02 March 2010 23:25:48 William Bourque wrote:
> So if I get this right, this code is responsible of handling the b43
> devices, as well as several other PCI-E devices, correct?

Nah, this is a broadcom specific thing of the on-chip SSB bus.

> 
> Because now that you mention this, the wired network card (Marvel Yukon,
> with sky2 drivers) on this netbook also have a tons of issue (doesn't
> show in lspci on a clean boot, oops the kernel if network cable is
> unplugged while in use, fails to load if the module is ever unloaded, ... )
> I thought it was unrelated but from your comment, I feel like this could
> be linked to the same PCI-E bugs as well.

Uh, well. Are you sure your hardware is OK then?

-- 
Greetings, Michael.

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[William Bourque]

Michael Buesch wrote:
> On Tuesday 02 March 2010 23:25:48 William Bourque wrote:
>> So if I get this right, this code is responsible of handling the b43
>> devices, as well as several other PCI-E devices, correct?
> 
> Nah, this is a broadcom specific thing of the on-chip SSB bus.
> 
Ok, sorry then :)

>> Because now that you mention this, the wired network card (Marvel Yukon,
>> with sky2 drivers) on this netbook also have a tons of issue (doesn't
>> show in lspci on a clean boot, oops the kernel if network cable is
>> unplugged while in use, fails to load if the module is ever unloaded, ... )
>> I thought it was unrelated but from your comment, I feel like this could
>> be linked to the same PCI-E bugs as well.
> 
> Uh, well. Are you sure your hardware is OK then?
> 
I sure hope so. The laptop is very new and I never had trouble with it,
but to tell the truth, it is a refurbished model so can't say for sure.

I think the hardware is fine but there is _very weird_ stuff about the
laptop... I feel like their ACPI implemention is nowhere near standard
and that might cause the problems. It's like everything on this laptop
is under a very agressive power management that bypass the OS and
confuse drivers. But again, it's just a feeling, I don't really have
much facts that back up this theory ;)

- William

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Larry Finger]

On 03/02/2010 03:57 PM, Michael Buesch wrote:

> A bug in the PCI-E core code is able to show such behavior, because all memory
> transfers (MMIO and DMA) from the PCI device to the wireless core are translated
> by the PCI-E core.
> I think the whole PCI-E core code has to be audited (also the specs, probably).

I have nearly finished the update on the code section of the specs page at
http://bcm-v4.sipsolutions.net/PCI-E. The part that is not done involves the
sections that read an address from the SPROM and perform operations on that address.

I found that the chip common registers are mapped at 12K for newer cores on
PCIe. This explains the 0x3XXX addresses. Similarly, the PCIe registers are
mapped at 8K - the 0x2XXX addresses. The SPROM is shadowed at 4K or 0x1XXX.

Larry

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Gábor Stefanik]

On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 03/02/2010 03:57 PM, Michael Buesch wrote:
>
>> A bug in the PCI-E core code is able to show such behavior, because all memory
>> transfers (MMIO and DMA) from the PCI device to the wireless core are translated
>> by the PCI-E core.
>> I think the whole PCI-E core code has to be audited (also the specs, probably).
>
> I have nearly finished the update on the code section of the specs page at
> http://bcm-v4.sipsolutions.net/PCI-E. The part that is not done involves the
> sections that read an address from the SPROM and perform operations on that address.
>
> I found that the chip common registers

Do you mean the ChipCommon registers or the Backplane common registers?

> are mapped at 12K for newer cores on
> PCIe. This explains the 0x3XXX addresses. Similarly, the PCIe registers are
> mapped at 8K - the 0x2XXX addresses. The SPROM is shadowed at 4K or 0x1XXX.
>
> Larry
>
>



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

Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!

[Larry Finger]

On 03/03/2010 06:47 PM, Gábor Stefanik wrote:
> On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> On 03/02/2010 03:57 PM, Michael Buesch wrote:
>>
>>> A bug in the PCI-E core code is able to show such behavior, because all memory
>>> transfers (MMIO and DMA) from the PCI device to the wireless core are translated
>>> by the PCI-E core.
>>> I think the whole PCI-E core code has to be audited (also the specs, probably).
>>
>> I have nearly finished the update on the code section of the specs page at
>> http://bcm-v4.sipsolutions.net/PCI-E. The part that is not done involves the
>> sections that read an address from the SPROM and perform operations on that address.
>>
>> I found that the chip common registers
> 
> Do you mean the ChipCommon registers or the Backplane common registers?

Definitely, it is the chipcommon registers.