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 03/03/2010 06:47 PM, Gábor Stefanik wrote:
> On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger
> 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
On Thu, Mar 4, 2010 at 1:30 AM, Larry Finger 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.
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
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 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 wi
On Monday 01 March 2010 00:38:16 Nathan Schulte wrote:
> 2010/2/28 Gábor Stefanik :
> > 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
> threa
2010/2/28 Nathan Schulte :
> 2010/2/28 Gábor Stefanik :
>> 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.
>
On Sun, 28 Feb 2010 15:51:14 -0500
William Bourque wrote:
> Chris Vine wrote:
> > On Sun, 28 Feb 2010 19:58:11 +0100
> > Michael Buesch 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 1
Chris Vine wrote:
On Sun, 28 Feb 2010 19:58:11 +0100
Michael Buesch 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) [size=16K]
Now th
On Sunday 28 February 2010 21:30:38 Chris Vine wrote:
> On Sun, 28 Feb 2010 19:58:11 +0100
> Michael Buesch 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 f8
On Sun, 28 Feb 2010 19:58:11 +0100
Michael Buesch 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) [size=16K]
Chris
On Sun, 28 Feb 2010 14:44:12 -0500
William Bourque 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
> help somehow
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
bro
On Sunday 28 February 2010 19:52:53 Gábor Stefanik wrote:
> 2010/2/28 Rafał Miłecki :
> > 2010/2/28 Gábor Stefanik :
> >> On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
> >> wrote:
> >>> I confirm, it still crashes on my notebook as well. However the new
> >>> "fallback to PIO" behavior introduc
2010/2/28 Rafał Miłecki :
> 2010/2/28 Gábor Stefanik :
>> On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
>> 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, yo
2010/2/28 Gábor Stefanik :
> On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
> 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 docume
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
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
>
On Sun, Feb 28, 2010 at 7:00 PM, William Bourque
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 track.
>
> Btw, y
Chris Vine wrote:
On Sun, 28 Feb 2010 00:44:58 +0100
Gábor Stefanik wrote:
2010/2/28 Nathan Schulte :
2010/2/27 Gábor Stefanik :
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
2010/2/28 Nathan Schulte :
> On Sat, Feb 27, 2010 at 7:03 PM, Nathan Schulte wrote:
>> 2010/2/27 Larry Finger :
>>> The printk's I sent yesterday can have timing info, but the timestamps
>>> would not
>>> be exactly coordinated - printk values seem to be generated when logged, not
>>> when reques
2010/2/28 Gábor Stefanik :
> 2010/2/28 Nathan Schulte :
>> 2010/2/27 Gábor Stefanik :
>>> Are you sure it is exactly the same? There are usually multiple
>>> configurations of the same laptop model available, e.g. I have an Acer
>>> 5720ZG with Pentium E2330, but it is also available with e.g. Pent
2010/2/28 Nathan Schulte :
> 2010/2/27 Gábor Stefanik :
>> Are you sure it is exactly the same? There are usually multiple
>> configurations of the same laptop model available, e.g. I have an Acer
>> 5720ZG with Pentium E2330, but it is also available with e.g. Pentium
>> E2370.
> Yes, I am 100% ce
2010/2/28 Nathan Schulte :
> 2010/2/27 Gábor Stefanik :
>> 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 same? There are usually multiple
c
On Sun, 28 Feb 2010 00:44:58 +0100
Gábor Stefanik wrote:
> 2010/2/28 Nathan Schulte :
> > 2010/2/27 Gábor Stefanik :
> >> 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
> >
>
2010/2/28 Nathan Schulte :
> 2010/2/27 Gábor Stefanik :
>> 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!
--
Vista: [V]iruses, [I]ntruders,
2010/2/27 Larry Finger :
>
>> 3. Right after the SPROM is read, wl writes zeros to MMIO offsets
>> 0x58 and 0x5c (32-bit), then does the PMU setup. These are not valid
>> registers for ChipCommon and PCIE, but for 802.11, they fall directly
>> into the DMA area! So, if these writes happened wit
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
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 fr
2010/2/27 Nathan Schulte :
> 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 @ 1.8GHz,
On Sat, Feb 27, 2010 at 5:37 PM, Larry Finger 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:
> Someone should
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
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
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, w
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 behavi
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 regist
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 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 f
On Sat, 27 Feb 2010 02:41:48 +0100
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-
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 b
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 Fri, 26 Feb 2010 23:03:28 +0100
Gábor Stefanik 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 the masking of the DMA
On Fri, 26 Feb 2010 18:22:26 +0100
Gábor Stefanik 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 "processor" would have an effect here...
I have reported previously (some mon
2010/2/26 Chris Vine :
> On Fri, 26 Feb 2010 18:22:26 +0100
> Gábor Stefanik 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 "processor" would have an effect here...
>
> I h
2010/2/26 Larry Finger :
> On 02/26/2010 09:27 AM, Gábor Stefanik wrote:
>> On Fri, Feb 26, 2010 at 4:13 PM, wrote:
>>> On Feb 26, 2010 9:08am, Gábor Stefanik wrote:
That's odd... the error only occurs when you stop the mmiotrace?!
>>> Yes, the error only occurs when I stop the mmiotrace wi
On 02/26/2010 09:27 AM, Gábor Stefanik wrote:
> On Fri, Feb 26, 2010 at 4:13 PM, wrote:
>> On Feb 26, 2010 9:08am, Gábor Stefanik wrote:
>>> That's odd... the error only occurs when you stop the mmiotrace?!
>> Yes, the error only occurs when I stop the mmiotrace with b43 loaded, or if
>> I load
On Fri, Feb 26, 2010 at 4:13 PM, wrote:
> On Feb 26, 2010 9:08am, Gábor Stefanik wrote:
>> That's odd... the error only occurs when you stop the mmiotrace?!
> Yes, the error only occurs when I stop the mmiotrace with b43 loaded, or if
> I load b43 outside of an mmiotrace.
>
>> BTW no need to loa
On Fri, Feb 26, 2010 at 4:04 PM, wrote:
> On Feb 26, 2010 8:49am, Gábor Stefanik 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.
> Correct, I did not do this. This
2010/2/26 Nathan Schulte :
> 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 a Fatal DMA
On Fri, Feb 26, 2010 at 12:12 PM, wrote:
> On Feb 26, 2010 3:23am, Gábor Stefanik 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, sorry for my confusion.
>
>> H
On Fri, Feb 26, 2010 at 8:33 AM, Nathan Schulte wrote:
> 2010/1/25 Gábor Stefanik
>
>> 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 loading wl, doing a warm reboot an
2010/1/25 Lucas Thode
>
>
> 2010/1/25 Lucas Thode
>
>
>>
>> 2010/1/25 Gábor Stefanik
>>
>>
>>>
>>> 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
2010/1/25 Lucas Thode
>
>
> 2010/1/25 Gábor Stefanik
>
>
>>
>> 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 firmware to v478. (A
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 wh
On Mon, Jan 25, 2010 at 9:15 PM, Lucas Thode 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] (start_freq - end_freq
55 matches
Mail list logo
