linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: William Bourque <william.bourque@polymtl.ca>
To: Michael Buesch <mb@bu3sch.de>
Cc: linux-wireless@vger.kernel.org, bcm43xx-dev@lists.berlios.de
Subject: Re: LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??!
Date: Tue, 02 Mar 2010 17:25:48 -0500	[thread overview]
Message-ID: <4B8D906C.9020102@polymtl.ca> (raw)
In-Reply-To: <201003022257.51878.mb@bu3sch.de>


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

  parent reply	other threads:[~2010-03-02 22:46 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <69e28c911002260708g45d3c0f7u6abf13b1babe549f@mail.gmail.com>
     [not found] ` <201002271620.31410.mb@bu3sch.de>
     [not found] ` <201002271708.29817.mb@bu3sch.de>
     [not found]   ` <4B894A61.1070302@lwfinger.net>
     [not found]     ` <69e28c911002271145s590df31en9d2f8b2c47932451@mail.gmail.com>
     [not found]       ` <4B899DA3.4030100@lwfinger.net>
     [not found]         ` <69e28c911002271534o8cab111vf7fcc1b93b6c4b47@mail.gmail.com>
     [not found]           ` <a221c0101002271542o5d928e56n8a22602860aeb761@mail.gmail.com>
     [not found]             ` <69e28c911002271544y62c93255k8a6dbb0adb2b5928@mail.gmail.com>
     [not found]               ` <20100228001655.4c9fd9ce@boulder.homenet>
     [not found]                 ` <4B8AAF42.8000602@polymtl.ca>
2010-02-28 18:42                   ` LP-PHY Fatal DMA error 0x00000800 on non-ULV Core 2 Duo?!?!!??! Gábor Stefanik
2010-02-28 18:47                     ` Rafał Miłecki
2010-02-28 18:52                       ` Gábor Stefanik
2010-02-28 18:58                         ` Michael Buesch
2010-02-28 20:30                           ` Chris Vine
2010-02-28 20:33                             ` Michael Buesch
2010-02-28 20:51                             ` William Bourque
2010-02-28 20:54                               ` Chris Vine
2010-02-28 19:44                     ` William Bourque
2010-02-28 20:03                       ` Chris Vine
     [not found]         ` <a221c0101002271703p3f344ec4t78d5c8b77c6d1290@mail.gmail.com>
     [not found]           ` <a221c0101002271828ye265d72y774320c08a4a15da@mail.gmail.com>
     [not found]             ` <69e28c911002280814v56f2f553x847c8bae94e6aaab@mail.gmail.com>
2010-02-28 22:19               ` Nathan Schulte
2010-02-28 23:03                 ` Gábor Stefanik
2010-02-28 23:38                   ` Nathan Schulte
2010-03-01  0:22                     ` Michael Buesch
2010-03-02 21:57                       ` Michael Buesch
2010-03-02 22:11                         ` Larry Finger
2010-03-02 22:25                         ` William Bourque [this message]
2010-03-02 22:29                           ` Michael Buesch
2010-03-02 22:50                             ` William Bourque
2010-03-04  0:30                         ` Larry Finger
2010-03-04  0:47                           ` Gábor Stefanik
2010-03-04  1:32                             ` Larry Finger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B8D906C.9020102@polymtl.ca \
    --to=william.bourque@polymtl.ca \
    --cc=bcm43xx-dev@lists.berlios.de \
    --cc=linux-wireless@vger.kernel.org \
    --cc=mb@bu3sch.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).