All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.