Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

bad DMAR interaction with iwlagn and SATA

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


andres at anarazel

Sep 25, 2008, 6:11 AM

Post #1 of 17 (5645 views)
Permalink
bad DMAR interaction with iwlagn and SATA

Hi,

in some accident caused by wanting to create the .config/compile the kernel
for my new laptop (thinkpad t500) before the desperately needed sleeping I
activated DMAR...

I don't know if this is relevant, but I though i better report it.


This was on fb478da5ba69ecf40729ae8ab37ca406b1e5be48 - sometime after 2.6.27-
rc7

I stumbled over two buglets:
First:
[ 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.
[ 4186.646000] psmouse.c: TouchPad at isa0060/serio1/input0 lost
synchronization, throwing 1 bytes away.
[ 4186.683034] Registered led device: iwl-phy0:radio
[ 4186.683478] Registered led device: iwl-phy0:assoc
[ 4186.683793] Registered led device: iwl-phy0:RX
[ 4186.684094] Registered led device: iwl-phy0:TX
[ 4186.689749] wlan0: authenticate with AP 00:1d:7e:42:fe:42
[ 4186.691691] wlan0: authenticated
[ 4186.691705] wlan0: associate with AP 00:1d:7e:42:fe:42
[ 4186.696380] wlan0: RX ReassocResp from 00:1d:7e:42:fe:42 (capab=0x411
status=0 aid=2)
[ 4186.696392] wlan0: associated

Most of the time when this happened, the machine wasnt reacting for 1-3
seconds and had audio buffer underruns, but I also had a hard lockup which I
couldnt diagnose so far.

Second:
[ 2937.484251] DMAR:[DMA Read] Request device [00:1f.2] fault addr fffbf000
[ 2937.484255] DMAR:[fault reason 06] PTE Read access is not set
[ 2937.484297] ata1.00: exception Emask 0x60 SAct 0x1 SErr 0x800 action 0x6
frozen
[ 2937.484303] ata1.00: irq_stat 0x20000000, host bus error
[ 2937.484309] ata1: SError: { HostInt }
[ 2937.484319] ata1.00: cmd 61/08:00:c0:1d:6b/00:00:07:00:00/40 tag 0 ncq 4096
out
[ 2937.484321] res 40/00:00:c0:1d:6b/00:00:07:00:00/40 Emask 0x60
(host bus error)
[ 2937.484327] ata1.00: status: { DRDY }
[ 2937.484338] ata1: hard resetting link
[ 2937.803070] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 2937.844250] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 succeeded
[ 2937.844255] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
[ 2937.845315] ata1.00: ACPI cmd ef/5f:00:00:00:00:a0 succeeded
[ 2937.845319] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
[ 2937.855347] ata1.00: ACPI cmd ef/02:00:00:00:00:a0 succeeded
[ 2937.855353] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
[ 2937.855436] ata1.00: ACPI cmd ef/5f:00:00:00:00:a0 succeeded
[ 2937.855438] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
[ 2937.856146] ata1.00: configured for UDMA/100
[ 2937.857754] ata1.00: configured for UDMA/100
[ 2937.857764] ata1: EH complete
[ 2937.857868] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042
MB)
[ 2937.857885] sd 0:0:0:0: [sda] Write Protect is off
[ 2937.857887] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 2937.857911] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[ 2937.857934] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042
MB)
[ 2937.857946] sd 0:0:0:0: [sda] Write Protect is off
[ 2937.857948] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 2937.857971] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA

System worked without propblems afterwards.

I think I had also some wierd interaction with ext3 - but I couldnt diagnose
this as the machine crashed - there was some filesystem damage afterwards. But
I wasnt able to diagnose it properly.


Andres

If you need dmesg or so, I will happily provide it - but I can't reboot just
now, waiting for some long running work stuff.
Attachments: lspci-v (9.06 KB)
  config-2.6.27-rc7.old (77.1 KB)
  signature.asc (0.19 KB)


jeff at garzik

Sep 25, 2008, 7:11 PM

Post #2 of 17 (5563 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

Andres Freund wrote:
> Hi,
>
> in some accident caused by wanting to create the .config/compile the kernel
> for my new laptop (thinkpad t500) before the desperately needed sleeping I
> activated DMAR...
>
> I don't know if this is relevant, but I though i better report it.
>
>
> This was on fb478da5ba69ecf40729ae8ab37ca406b1e5be48 - sometime after 2.6.27-
> rc7
>
> I stumbled over two buglets:
> First:
> [ 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.
> [ 4186.646000] psmouse.c: TouchPad at isa0060/serio1/input0 lost
> synchronization, throwing 1 bytes away.
> [ 4186.683034] Registered led device: iwl-phy0:radio
> [ 4186.683478] Registered led device: iwl-phy0:assoc
> [ 4186.683793] Registered led device: iwl-phy0:RX
> [ 4186.684094] Registered led device: iwl-phy0:TX
> [ 4186.689749] wlan0: authenticate with AP 00:1d:7e:42:fe:42
> [ 4186.691691] wlan0: authenticated
> [ 4186.691705] wlan0: associate with AP 00:1d:7e:42:fe:42
> [ 4186.696380] wlan0: RX ReassocResp from 00:1d:7e:42:fe:42 (capab=0x411
> status=0 aid=2)
> [ 4186.696392] wlan0: associated
>
> Most of the time when this happened, the machine wasnt reacting for 1-3
> seconds and had audio buffer underruns, but I also had a hard lockup which I
> couldnt diagnose so far.
>
> Second:
> [ 2937.484251] DMAR:[DMA Read] Request device [00:1f.2] fault addr fffbf000
> [ 2937.484255] DMAR:[fault reason 06] PTE Read access is not set
> [ 2937.484297] ata1.00: exception Emask 0x60 SAct 0x1 SErr 0x800 action 0x6
> frozen
> [ 2937.484303] ata1.00: irq_stat 0x20000000, host bus error
> [ 2937.484309] ata1: SError: { HostInt }
> [ 2937.484319] ata1.00: cmd 61/08:00:c0:1d:6b/00:00:07:00:00/40 tag 0 ncq 4096
> out
> [ 2937.484321] res 40/00:00:c0:1d:6b/00:00:07:00:00/40 Emask 0x60
> (host bus error)

Ouch, a host bus error is serious nastiness...

http://ata.wiki.kernel.org/index.php/Libata_error_messages#Error_classes

That's the ATA controller falling over after some serious machine hiccups.

Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andres at anarazel

Sep 25, 2008, 7:18 PM

Post #3 of 17 (5559 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

Hi Jeff,

On Friday 26 September 2008, you wrote in "Re: bad DMAR interaction with
iwlagn and SATA":
> Andres Freund wrote:
> > sleeping I activated DMAR...
> > ..
> > Second:
> > [ 2937.484251] DMAR:[DMA Read] Request device [00:1f.2] fault addr
> > fffbf000 [ 2937.484255] DMAR:[fault reason 06] PTE Read access is not set
> > [ 2937.484297] ata1.00: exception Emask 0x60 SAct 0x1 SErr 0x800 action
> > 0x6 frozen
> > [ 2937.484303] ata1.00: irq_stat 0x20000000, host bus error
> > [ 2937.484309] ata1: SError: { HostInt }
> > [ 2937.484319] ata1.00: cmd 61/08:00:c0:1d:6b/00:00:07:00:00/40 tag 0 ncq
> > 4096 out
> > [ 2937.484321] res 40/00:00:c0:1d:6b/00:00:07:00:00/40 Emask
> > 0x60 (host bus error)
> Ouch, a host bus error is serious nastiness...
I only hit that with DMAR activated (hit it twice, different boots), so it
seems to be related to that. Is there anything I can help to debug that?

Andres
Attachments: signature.asc (0.19 KB)


jeff at garzik

Sep 25, 2008, 7:41 PM

Post #4 of 17 (5558 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

Andres Freund wrote:
> Hi Jeff,
>
> On Friday 26 September 2008, you wrote in "Re: bad DMAR interaction with
> iwlagn and SATA":
>> Andres Freund wrote:
>>> sleeping I activated DMAR...
>>> ..
>>> Second:
>>> [ 2937.484251] DMAR:[DMA Read] Request device [00:1f.2] fault addr
>>> fffbf000 [ 2937.484255] DMAR:[fault reason 06] PTE Read access is not set
>>> [ 2937.484297] ata1.00: exception Emask 0x60 SAct 0x1 SErr 0x800 action
>>> 0x6 frozen
>>> [ 2937.484303] ata1.00: irq_stat 0x20000000, host bus error
>>> [ 2937.484309] ata1: SError: { HostInt }
>>> [ 2937.484319] ata1.00: cmd 61/08:00:c0:1d:6b/00:00:07:00:00/40 tag 0 ncq
>>> 4096 out
>>> [ 2937.484321] res 40/00:00:c0:1d:6b/00:00:07:00:00/40 Emask
>>> 0x60 (host bus error)
>> Ouch, a host bus error is serious nastiness...
> I only hit that with DMAR activated (hit it twice, different boots), so it
> seems to be related to that. Is there anything I can help to debug that?

No idea about DMAR. On the ATA side, it pretty diagnoses itself as you
see here. Unfortunately, ATA controller is behaving exactly as it
should, when a major system error is thrown its way.

Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


muli at il

Sep 26, 2008, 7:47 AM

Post #5 of 17 (5554 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

On Thu, Sep 25, 2008 at 10:41:04PM -0400, Jeff Garzik wrote:
> Andres Freund wrote:
>> Hi Jeff,
>> On Friday 26 September 2008, you wrote in "Re: bad DMAR interaction with
>> iwlagn and SATA":
>>> Andres Freund wrote:
>>>> sleeping I activated DMAR...
>>>> ..
>>>> Second:
>>>> [ 2937.484251] DMAR:[DMA Read] Request device [00:1f.2] fault addr
>>>> fffbf000 [ 2937.484255] DMAR:[fault reason 06] PTE Read access is not
>>>> set
>>>> [ 2937.484297] ata1.00: exception Emask 0x60 SAct 0x1 SErr 0x800 action
>>>> 0x6 frozen
>>>> [ 2937.484303] ata1.00: irq_stat 0x20000000, host bus error
>>>> [ 2937.484309] ata1: SError: { HostInt }
>>>> [ 2937.484319] ata1.00: cmd 61/08:00:c0:1d:6b/00:00:07:00:00/40 tag 0
>>>> ncq
>>>> 4096 out
>>>> [ 2937.484321] res 40/00:00:c0:1d:6b/00:00:07:00:00/40 Emask
>>>> 0x60 (host bus error)
>>> Ouch, a host bus error is serious nastiness...
>> I only hit that with DMAR activated (hit it twice, different boots), so it
>> seems to be related to that. Is there anything I can help to debug that?
>
> No idea about DMAR. On the ATA side, it pretty diagnoses itself as
> you see here. Unfortunately, ATA controller is behaving exactly as
> it should, when a major system error is thrown its way.

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.

Cheers,
Muli
--
The First Workshop on I/O Virtualization (WIOV '08)
Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/
xxx
SYSTOR 2009---The Israeli Experimental Systems Conference
http://www.haifa.il.ibm.com/conferences/systor2009/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


johannes at sipsolutions

Sep 26, 2008, 8:10 AM

Post #6 of 17 (5535 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

On Thu, 2008-09-25 at 15:11 +0200, Andres Freund wrote:

> I don't know if this is relevant, but I though i better report it.

Thanks. I've also been chasing a DMA corruption issue with iwlagn (on
powerpc).

> This was on fb478da5ba69ecf40729ae8ab37ca406b1e5be48 - sometime after 2.6.27-
> rc7
>
> I stumbled over two buglets:
> First:
> [ 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.
> [ 4186.646000] psmouse.c: TouchPad at isa0060/serio1/input0 lost synchronization, throwing 1 bytes away.
> [ 4186.683034] Registered led device: iwl-phy0:radio
> [ 4186.683478] Registered led device: iwl-phy0:assoc
> [ 4186.683793] Registered led device: iwl-phy0:RX
> [ 4186.684094] Registered led device: iwl-phy0:TX
> [ 4186.689749] wlan0: authenticate with AP 00:1d:7e:42:fe:42
> [ 4186.691691] wlan0: authenticated
> [ 4186.691705] wlan0: associate with AP 00:1d:7e:42:fe:42
> [ 4186.696380] wlan0: RX ReassocResp from 00:1d:7e:42:fe:42 (capab=0x411 status=0 aid=2)
> [ 4186.696392] wlan0: associated
>
> Most of the time when this happened, the machine wasnt reacting for 1-3
> seconds and had audio buffer underruns, but I also had a hard lockup which I
> couldnt diagnose so far.

I suspect the hard lockup was due to a BUG_ON in the iwlagn driver, if
you can reproduce this either try applying the patch here [1] or going
to a VC to see if it crashes there. It's a BUG_ON in iwl-tx.c.

johannes

[1] http://article.gmane.org/gmane.linux.kernel.wireless.general/21226
Attachments: signature.asc (0.82 KB)


johannes at sipsolutions

Sep 26, 2008, 8:12 AM

Post #7 of 17 (5550 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

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
Attachments: signature.asc (0.82 KB)


tomasw at gmail

Sep 26, 2008, 4:30 PM

Post #8 of 17 (5535 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

On Fri, Sep 26, 2008 at 6:12 PM, Johannes Berg
<johannes [at] sipsolutions> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


andres at anarazel

Sep 29, 2008, 1:26 AM

Post #9 of 17 (5510 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

Hi,

On Friday 26 September 2008, you wrote in "Re: bad DMAR interaction with
iwlagn and SATA":
> > [ 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. [
> > 4186.646000] psmouse.c: TouchPad at isa0060/serio1/input0 lost
> > synchronization, throwing 1 bytes away. [ 4186.683034] Registered led
> > device: iwl-phy0:radio
> > [ 4186.683478] Registered led device: iwl-phy0:assoc
> > [ 4186.683793] Registered led device: iwl-phy0:RX
> > [ 4186.684094] Registered led device: iwl-phy0:TX
> > [ 4186.689749] wlan0: authenticate with AP 00:1d:7e:42:fe:42
> > [ 4186.691691] wlan0: authenticated
> > [ 4186.691705] wlan0: associate with AP 00:1d:7e:42:fe:42
> > [ 4186.696380] wlan0: RX ReassocResp from 00:1d:7e:42:fe:42 (capab=0x411
> > status=0 aid=2) [ 4186.696392] wlan0: associated

> > Most of the time when this happened, the machine wasnt reacting for 1-3
> > seconds and had audio buffer underruns, but I also had a hard lockup
> > which I couldnt diagnose so far.
> I suspect the hard lockup was due to a BUG_ON in the iwlagn driver, if
> you can reproduce this either try applying the patch here [1] or going
> to a VC to see if it crashes there. It's a BUG_ON in iwl-tx.c.
Could not reproduce so far - it is rather hard working on the machine with
DMAR enabled because I get 1-5s lockups all the time like described above...

Andres
Attachments: signature.asc (0.19 KB)


andres at anarazel

Sep 29, 2008, 1:27 AM

Post #10 of 17 (5512 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

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
Attachments: signature.asc (0.19 KB)


tomasw at gmail

Sep 29, 2008, 1:40 AM

Post #11 of 17 (5531 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

On Mon, Sep 29, 2008 at 11:27 AM, Andres Freund <andres [at] anarazel> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


johannes at sipsolutions

Oct 6, 2008, 5:26 AM

Post #12 of 17 (5405 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

On Mon, 2008-09-29 at 11:40 +0300, Tomas Winkler wrote:
> On Mon, Sep 29, 2008 at 11:27 AM, Andres Freund <andres [at] anarazel> 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
Attachments: signature.asc (0.82 KB)


andres at anarazel

Oct 6, 2008, 7:32 AM

Post #13 of 17 (5407 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

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
Attachments: config-2.6.27-rc7 (73.2 KB)
  signature.asc (0.19 KB)


kernel.sensei at gmail

Oct 6, 2008, 3:11 PM

Post #14 of 17 (5400 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

Hi,

I just subscribed to the mailing list, I can't quote the previous
messages. I'm answering to this thread :
http://www.gossamer-threads.com/lists/linux/kernel/976913

I've the same problem here with my Lenovo T400.

I tried 2.6.26 kernels and the 2.6.27-rc8.

The bug occurs with the e1000e module while running the 2.6.26 kernel
and with iwlagn while running the 2.6.27-rc8 (I didn't build the
2.6.27 e1000e module, because of the nvram bug)

Here is some dmesg output, the last one is from the 2.6.27 kernel :
http://boris.geekjide.com/messages0.txt

I'm running a 64bits Gentoo system

regards,

Boris Fersing

--
$ ruby -e'puts " .:@BFegiklnorst".unpack("x4ax7aaX6ax5aX15ax4aax6aaX7ax2 \
aX5aX8axaX3ax8aX4ax6aX3aX6ax3ax3aX9ax4ax2aX9axaX6ax3aX2ax4 \
ax3aX4aXaX12ax10aaX7a").join'
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


johannes at sipsolutions

Oct 7, 2008, 1:37 AM

Post #15 of 17 (5396 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

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
Attachments: signature.asc (0.82 KB)


kyle at infradead

Oct 7, 2008, 10:04 AM

Post #16 of 17 (5398 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


johannes at sipsolutions

Oct 7, 2008, 10:08 AM

Post #17 of 17 (5402 views)
Permalink
Re: bad DMAR interaction with iwlagn and SATA [In reply to]

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
Attachments: signature.asc (0.82 KB)

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.