On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger larry.fin...@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
On 03/03/2010 06:47 PM, Gábor Stefanik wrote:
On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger larry.fin...@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
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
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
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 :)
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
2010/2/28 Nathan Schulte rekl...@gmail.com:
On Sat, Feb 27, 2010 at 7:03 PM, Nathan Schulte rekl...@gmail.com wrote:
2010/2/27 Larry Finger larry.fin...@lwfinger.net:
The printk's I sent yesterday can have timing info, but the timestamps
would not
be exactly coordinated - printk values seem
Chris Vine wrote:
On Sun, 28 Feb 2010 00:44:58 +0100
Gábor Stefanik netrolller...@gmail.com wrote:
2010/2/28 Nathan Schulte rekl...@gmail.com:
2010/2/27 Gábor Stefanik netrolller...@gmail.com:
OK, I whipped up a quick test patch with changes found so far
implemented. Please test if this
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
william.bour...@polymtl.ca wrote:
Chris Vine wrote:
This doesn't help on my netbook, I am afraid.
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
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
william.bour...@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
2010/2/28 Gábor Stefanik netrolller...@gmail.com:
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
william.bour...@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,
On Sunday 28 February 2010 19:52:53 Gábor Stefanik wrote:
2010/2/28 Rafał Miłecki zaj...@gmail.com:
2010/2/28 Gábor Stefanik netrolller...@gmail.com:
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
william.bour...@polymtl.ca wrote:
I confirm, it still crashes on my notebook as well.
New test patch attached.
Please CC linux-wirel...@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
On Sun, 28 Feb 2010 14:44:12 -0500
William Bourque william.bour...@polymtl.ca wrote:
New test patch attached.
Please CC linux-wirel...@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
On Sunday 28 February 2010 21:30:38 Chris Vine wrote:
On Sun, 28 Feb 2010 19:58:11 +0100
Michael Buesch m...@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
Chris Vine wrote:
On Sun, 28 Feb 2010 19:58:11 +0100
Michael Buesch m...@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 f800 (64-bit, non-prefetchable)
On Sun, 28 Feb 2010 15:51:14 -0500
William Bourque william.bour...@polymtl.ca wrote:
Chris Vine wrote:
On Sun, 28 Feb 2010 19:58:11 +0100
Michael Buesch m...@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.
2010/2/28 Nathan Schulte rekl...@gmail.com:
2010/2/28 Gábor Stefanik netrolller...@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
On Monday 01 March 2010 00:38:16 Nathan Schulte wrote:
2010/2/28 Gábor Stefanik netrolller...@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
On Sat, 27 Feb 2010 02:41:48 +0100
Gábor Stefanik netrolller...@gmail.com wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312. (This is not the correct
way to fix this, but should be enough for a test. The correct fix
On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote:
BTW there is an interesting difference in the early init between wl
and b43: b43 sets bit 0x200 in core register 0x600, while wl sets
0x8000 in register 0x280a - an undocumented register.
Well, it is not only undocumented, it's also far
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312.
Uh, wait a second. Do _all_ cards that show the behavior have a PMU on the SSB?
If so, you should really make
On 02/27/2010 09:16 AM, Michael Buesch wrote:
On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote:
BTW there is an interesting difference in the early init between wl
and b43: b43 sets bit 0x200 in core register 0x600, while wl sets
0x8000 in register 0x280a - an undocumented register.
On 02/27/2010 09:20 AM, Michael Buesch wrote:
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312.
Uh, wait a second. Do _all_ cards that show the behavior have
On Saturday 27 February 2010 16:55:09 Larry Finger wrote:
On 02/27/2010 09:16 AM, Michael Buesch wrote:
On Friday 26 February 2010 23:03:28 Gábor Stefanik wrote:
BTW there is an interesting difference in the early init between wl
and b43: b43 sets bit 0x200 in core register 0x600, while wl
On Saturday 27 February 2010 17:05:41 Larry Finger wrote:
On 02/27/2010 09:20 AM, Michael Buesch wrote:
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312.
On 02/27/2010 10:08 AM, Michael Buesch wrote:
On Saturday 27 February 2010 17:05:41 Larry Finger wrote:
On 02/27/2010 09:20 AM, Michael Buesch wrote:
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In
On Sat, Feb 27, 2010 at 5:37 PM, Larry Finger larry.fin...@lwfinger.net wrote:
On 02/27/2010 10:08 AM, Michael Buesch wrote:
On Saturday 27 February 2010 17:05:41 Larry Finger wrote:
On 02/27/2010 09:20 AM, Michael Buesch wrote:
On Saturday 27 February 2010 02:41:48 Gábor Stefanik wrote:
2010/2/27 Nathan Schulte rekl...@gmail.com:
I've been following along with the linux-wireless thread, and wanted
to bring up a few points.
1) If the report in reference by Gábor: Well, we have a report from
someone with an Intel T7250, ... is mine, note that my processor is
actually a T5670
On Saturday 27 February 2010 20:45:50 Gábor Stefanik wrote:
2. Just before the SPROM readout, we are missing a Set 0x8000 in
MMIO offset 0x280a. This looks curiously like PCI-E Miscellaneous
Configuration, from http://bcm-v4.sipsolutions.net/PCI-E - and
indeed, the value read out from
On 02/27/2010 01:45 PM, Gábor Stefanik wrote:
So, a quick status update, from what I've found yesterday:
1. We get the PMU setup wrong. Bit 0x200 is being set, despite the
PMU being rev1. Also, PMU setup is done too early - at least wl reads
the SPROM before setting up the PMU. A write
2010/2/28 Nathan Schulte rekl...@gmail.com:
2010/2/27 Gábor Stefanik netrolller...@gmail.com:
OK, I whipped up a quick test patch with changes found so far
implemented. Please test if this improves the situation.
Where can I find this patch?
-Nate
Oops... yes, I forgot it. Here it is!
--
2010/2/28 Nathan Schulte rekl...@gmail.com:
2010/2/27 Gábor Stefanik netrolller...@gmail.com:
Oops... yes, I forgot it. Here it is!
No luck from me either.
And by the way, Lucas and I have the exact same hardware, so his is
indeed a T5670 as well.
-Nate
Are you sure it is exactly the
On Fri, Feb 26, 2010 at 8:33 AM, Nathan Schulte rekl...@gmail.com wrote:
2010/1/25 Gábor Stefanik netrolller...@gmail.com
A few things to check:
-Is this on PhoenixBios?
I have the same laptop as Lucas, a Dell Vostro 1510. As Lucas has
mentioned, this is indeed a PhoenixBIOS
-Does
On Fri, Feb 26, 2010 at 12:12 PM, rekl...@gmail.com wrote:
On Feb 26, 2010 3:23am, Gábor Stefanik netrolller...@gmail.com wrote:
The firmware version included in 4.174.64.19 is 478.104 (notice that
is is not 4178.104, but 478.104 - the driver and firmware versions are
not related!).
Ah yes,
2010/2/26 Nathan Schulte rekl...@gmail.com:
I apologize for so many messages. I wanted to note that the reasoning
for lsmod only showing the ntfs module, is due the fact that ntfs (and
b43 and ssb) are the only drivers compiled as modules.
When loading b43 without mmiotrace running, I receive
On Fri, Feb 26, 2010 at 4:04 PM, rekl...@gmail.com wrote:
On Feb 26, 2010 8:49am, Gábor Stefanik netrolller...@gmail.com wrote:
However, you did not do what I requested - before the 2nd mmiotrace,
load and unload wl (the hybrid driver), not b43 - it is wl that
appears to make the card work.
On 02/26/2010 09:27 AM, Gábor Stefanik wrote:
On Fri, Feb 26, 2010 at 4:13 PM, rekl...@gmail.com wrote:
On Feb 26, 2010 9:08am, Gábor Stefanik netrolller...@gmail.com wrote:
That's odd... the error only occurs when you stop the mmiotrace?!
Yes, the error only occurs when I stop the mmiotrace
2010/2/26 Larry Finger larry.fin...@lwfinger.net:
On 02/26/2010 09:27 AM, Gábor Stefanik wrote:
On Fri, Feb 26, 2010 at 4:13 PM, rekl...@gmail.com wrote:
On Feb 26, 2010 9:08am, Gábor Stefanik netrolller...@gmail.com wrote:
That's odd... the error only occurs when you stop the mmiotrace?!
2010/2/26 Chris Vine ch...@cvine.freeserve.co.uk:
On Fri, 26 Feb 2010 18:22:26 +0100
Gábor Stefanik netrolller...@gmail.com wrote:
Note that enabling MMIO trace touches quite a few areas of the kernel
rather hard - for example, it AFAIK disables SMP. I wonder if acpi=off
or blacklisting
On Fri, 26 Feb 2010 23:03:28 +0100
Gábor Stefanik netrolller...@gmail.com wrote:
I suspect that timing is not the true reason for the problem, rather,
there is a race condition between PhoenixBIOS and b43, for which wl
probably uses a (firmware?) workaround.
I meant that it is the reason for
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312. (This is not the correct
way to fix this, but should be enough for a test. The correct fix
would be special-casing for both 4312 and 4325, at least according to
the MMIO trace
On 02/26/2010 07:41 PM, Gábor Stefanik wrote:
Someone should test the following:
-Open drivers/ssb/driver_chipcommon_pmu.c
-In ssb_pmu_init, replace 0x4325 with 0x4312. (This is not the correct
way to fix this, but should be enough for a test. The correct fix
would be special-casing for both
On Mon, Jan 25, 2010 at 9:15 PM, Lucas Thode ljth...@gmail.com wrote:
---start dmesg snippet---
[17189.121003] b43-pci-bridge :06:00.0: PCI INT A disabled
[17192.494272] cfg80211: Using static regulatory domain info
[17192.494279] cfg80211: Regulatory domain: US
[17192.494283]
On 01/25/2010 02:15 PM, Lucas Thode wrote:
As you can tell, this processor is neither an Atom nor a ULV Core 2
Duo. The WLAN card is the Dell Wireless 1395 that came with the laptop
(a Vostro 1510). I can build a custom kernel based on the Debian kernel
sources if need be; just tell me what
Sorry, hit Reply instead of Reply All *d'oh*
-- Forwarded message --
From: Lucas Thode ljth...@gmail.com
Date: 2010/1/25
Subject: Re: LP-PHY Fatal DMA error 0x0800 on non-ULV Core 2 Duo?!?!!??!
To: Gábor Stefanik netrolller...@gmail.com
2010/1/25 Gábor Stefanik netrolller
2010/1/25 Lucas Thode ljth...@gmail.com
2010/1/25 Gábor Stefanik netrolller...@gmail.com
A few things to check:
-Is this on PhoenixBios?
Indeed, the Vostro 1510 uses a (Dell branded) PhoenixBIOS.
-Does loading wl, doing a warm reboot and loading b43 make b43 work?
-Try updating the
2010/1/25 Lucas Thode ljth...@gmail.com
2010/1/25 Lucas Thode ljth...@gmail.com
2010/1/25 Gábor Stefanik netrolller...@gmail.com
A few things to check:
-Is this on PhoenixBios?
Indeed, the Vostro 1510 uses a (Dell branded) PhoenixBIOS.
-Does loading wl, doing a warm reboot and
48 matches
Mail list logo
