On Fri, 2008-09-26 at 17:47 +0300, Muli Ben-Yehuda wrote:
> The way to debug this is to figure out why device 00:1f.2 is trying to
> read from DMA address fffbf000 and does not have permission to do
> so. This could be indicative of a driver bug where it is programming
> the device to read from some buffer that has not been allocated
> through the DMA API and thus does not have a valid IOMMU mapping, or a
> hardware quirk where the device tries to read from memory without host
> involvement. The former is much more likely.
The same is probably true for the iwlagn case which was
> [ 4184.617392] DMAR:[DMA Read] Request device [03:00.0] fault addr fa946000
> [ 4184.617393] DMAR:[fault reason 06] PTE Read access is not set
> [ 4184.644081] iwlagn: Microcode HW error detected. Restarting.
and indeed matches experience from myself and Marcel that DMA bugs seem
to lurk.
johannes
On Fri, Sep 26, 2008 at 6:12 PM, Johannes Berg
<[email protected]> wrote:
> On Fri, 2008-09-26 at 17:47 +0300, Muli Ben-Yehuda wrote:
>
>> The way to debug this is to figure out why device 00:1f.2 is trying to
>> read from DMA address fffbf000 and does not have permission to do
>> so. This could be indicative of a driver bug where it is programming
>> the device to read from some buffer that has not been allocated
>> through the DMA API and thus does not have a valid IOMMU mapping, or a
>> hardware quirk where the device tries to read from memory without host
>> involvement. The former is much more likely.
>
> The same is probably true for the iwlagn case which was
>
>> [ 4184.617392] DMAR:[DMA Read] Request device [03:00.0] fault addr fa946000
>> [ 4184.617393] DMAR:[fault reason 06] PTE Read access is not set
>> [ 4184.644081] iwlagn: Microcode HW error detected. Restarting.
>
> and indeed matches experience from myself and Marcel that DMA bugs seem
> to lurk.
Meanwhile it all reported bugs in this case points to 64 bit
installations, I'll give it more testing
Thnaks.
Tomas
Hi,
On Saturday 27 September 2008, Tomas Winkler wrote in "Re: bad DMAR
interaction with iwlagn and SATA":
> Meanwhile it all reported bugs in this case points to 64 bit
> installations, I'll give it more testing
Would it help to test on 32bit? I have some dissk with 32bit system installed
lying around somewhere...
Any other patches to try?
Andres
On Mon, Sep 29, 2008 at 11:27 AM, Andres Freund <[email protected]> wrote:
> Hi,
>
> On Saturday 27 September 2008, Tomas Winkler wrote in "Re: bad DMAR
> interaction with iwlagn and SATA":
>> Meanwhile it all reported bugs in this case points to 64 bit
>> installations, I'll give it more testing
> Would it help to test on 32bit? I have some dissk with 32bit system installed
> lying around somewhere...
It would help to try to isolate this as 64 bit issue
> Any other patches to try?
I've posted few patches lately to address some RX buffers issues you
may to try those. Not sure it will help though.
http://marc.info/?l=linux-wireless&m=122241327108723&w=2
http://marc.info/?l=linux-wireless&m=122241327208729&w=2
Thanks
Tomas
On Mon, 2008-09-29 at 11:40 +0300, Tomas Winkler wrote:
> On Mon, Sep 29, 2008 at 11:27 AM, Andres Freund <[email protected]> wrote:
> > Hi,
> >
> > On Saturday 27 September 2008, Tomas Winkler wrote in "Re: bad DMAR
> > interaction with iwlagn and SATA":
> >> Meanwhile it all reported bugs in this case points to 64 bit
> >> installations, I'll give it more testing
> > Would it help to test on 32bit? I have some dissk with 32bit system installed
> > lying around somewhere...
>
> It would help to try to isolate this as 64 bit issue
Andres, can you post your config?
johannes
Hi,
On Monday 06 October 2008, Johannes Berg wrote in "Re: bad DMAR interaction
with iwlagn and SATA":
> > > Would it help to test on 32bit? I have some dissk with 32bit system
> > > installed lying around somewhere...
> > It would help to try to isolate this as 64 bit issue
Btw, will do so later this evening having access to the older harddisk (with
32bit install) again.
> Andres, can you post your config?
Sure, my current running one is attached.
The config I had the error with was exactly the same just with CONFIG_DMAR and
e1000e enabled (but is overwritten now)...
Its no problem trying another branch more debugging options or so if needed.
Andres
On Tue, 2008-10-07 at 13:04 -0400, Kyle McMartin wrote:
> 2MB pages (and 4MB pages) are dependent on PSE/PAE, there's no configurable
> page size on x86 like there is on other platforms.
>
> PSE gives you 4MB pages, PAE reduces your 4MB pages to 2MB pages (for
> extra flag and address bits.)
>
> About the only useful places for these are large mappings like ioremap
> and whatnot.
Thanks for the explanation. Can you explain too why iwlwifi crashes when
I enable 64k pages? ;)
johannes
On Mon, 2008-10-06 at 16:32 +0200, Andres Freund wrote:
> > Andres, can you post your config?
> Sure, my current running one is attached.
> The config I had the error with was exactly the same just with CONFIG_DMAR and
> e1000e enabled (but is overwritten now)...
>
> Its no problem trying another branch more debugging options or so if needed.
No, I was just wondering whether x86-64 had something like powerpc's
CONFIG_64K_PAGES, but it doesn't seem to. 2M-page support seems to be
used always dependent on the CPU, but I have no idea you can tell
whether or not your CPU supports that.
johannes
On Tue, Oct 07, 2008 at 10:37:16AM +0200, Johannes Berg wrote:
> On Mon, 2008-10-06 at 16:32 +0200, Andres Freund wrote:
>
> > > Andres, can you post your config?
> > Sure, my current running one is attached.
> > The config I had the error with was exactly the same just with CONFIG_DMAR and
> > e1000e enabled (but is overwritten now)...
> >
> > Its no problem trying another branch more debugging options or so if needed.
>
> No, I was just wondering whether x86-64 had something like powerpc's
> CONFIG_64K_PAGES, but it doesn't seem to. 2M-page support seems to be
> used always dependent on the CPU, but I have no idea you can tell
> whether or not your CPU supports that.
>
2MB pages (and 4MB pages) are dependent on PSE/PAE, there's no configurable
page size on x86 like there is on other platforms.
PSE gives you 4MB pages, PAE reduces your 4MB pages to 2MB pages (for
extra flag and address bits.)
About the only useful places for these are large mappings like ioremap
and whatnot.
regards, Kyle