Eric W. Biederman wrote:
| WB WT WC UC
---+---
WB | WB WT WC UC
WT | WT WT UC UC
WC | WC UC WC UC
UC | UC UC UC UC
With the current PAT encoding:
WB = 00
WT = 01
WC = 10
UC = 11
... this is simply a bitwise OR. This makes sense, since one of the bits denies
dela
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Siddha, Suresh B wrote:
>>
>> But then, this will cause an attribute conflicit. Old one was specifying
>> WB in PAT (ioremap with noflags) and the new ioremap specifies UC.
>>
>> As Linus mentioned, main problem is to figure out the correct attribute
CTED]; linux-kernel@vger.kernel.org
> >Subject: Re: [patch 0/4] x86: PAT followup - Incremental
> >changes and bug fixes
> >
> >On Thu, Jan 17, 2008 at 03:04:10PM -0800, Venki Pallipadi wrote:
> >>
> >> Below is another potential fix for the prob
PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>Barnes, Jesse; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
>Subject: Re: [patch 0/4] x86: PAT followup - Incremental
>changes and bug fixes
>
&g
On Thu, Jan 17, 2008 at 03:04:10PM -0800, Venki Pallipadi wrote:
>
> Below is another potential fix for the problem here. Going through ACPI
> ioremap usages, we found at one place the mapping is cached for possible
> optimization reason and not unmapped later. Patch below always unmaps
> ioremap a
> As Linus mentioned, main problem is to figure out the correct attribute
> for ioremap() which doesn't specify the actual attribute to be used.
In this case the correct attribute is the one of the underlying MTRR.
And if it conflicts with some other mapping that overrides an MTRR
the driver was
PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>Barnes, Jesse; [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
>Subject: Re: [patch 0/4] x86: PAT followup - Incremental
>changes and bug fixes
>
&g
On Thu, Jan 17, 2008 at 03:04:10PM -0800, Venki Pallipadi wrote:
>
> Below is another potential fix for the problem here. Going through ACPI
> ioremap usages, we found at one place the mapping is cached for possible
> optimization reason and not unmapped later. Patch below always unmaps
> ioremap
On Thu, Jan 17, 2008 at 11:35:51PM +0100, Ingo Molnar wrote:
>
> * Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
>
> > > I'll check this asap
> >
> > So, now that I've avoided this tiny NULL-pointer-dereference, the
> > system boots fine as well with your (slightly modified) patch. See
> > dmes
On Thu, Jan 17, 2008 at 11:52:43PM +0100, Andreas Herrmann3 wrote:
> On Thu, Jan 17, 2008 at 11:15:05PM +0100, Ingo Molnar wrote:
> >
> > * Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, Jan 17, 2008 at 10:42:09PM +0100, Ingo Molnar wrote:
> > > >
> > > > * Siddha, Suresh B <[EMA
On Thu, Jan 17, 2008 at 11:15:05PM +0100, Ingo Molnar wrote:
>
> * Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jan 17, 2008 at 10:42:09PM +0100, Ingo Molnar wrote:
> > >
> > > * Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Thu, Jan 17, 2008 at 10:13:08PM +0100, In
* Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
> > I'll check this asap
>
> So, now that I've avoided this tiny NULL-pointer-dereference, the
> system boots fine as well with your (slightly modified) patch. See
> dmesg attached.
for now i applied your ioremap_uncached() patch and removed my p
On Thu, Jan 17, 2008 at 10:42:28PM +0100, Andreas Herrmann3 wrote:
> On Thu, Jan 17, 2008 at 10:13:08PM +0100, Ingo Molnar wrote:
> >
> > * Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
> >
> > > Yes.
> > >
> > > Meanwhile I have figured out that it is some ACPI stuff that maps the
> > > page ca
On Thu, Jan 17, 2008 at 10:42:28PM +0100, Andreas Herrmann3 wrote:
> On Thu, Jan 17, 2008 at 10:13:08PM +0100, Ingo Molnar wrote:
> >
> > * Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
> >
> > > Yes.
> > >
> > > Meanwhile I have figured out that it is some ACPI stuff that maps the
> > > page ca
* Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 17, 2008 at 10:42:09PM +0100, Ingo Molnar wrote:
> >
> > * Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> >
> > > On Thu, Jan 17, 2008 at 10:13:08PM +0100, Ingo Molnar wrote:
> > > > but in general we must be robust enough in this case
Andreas Herrmann3 wrote:
Yes, we must fix all aliases or reject the conflicting mapping.
But fixing all aliases might not be that easy.
(I've just seen a panic when using your patch ;-(
Avoiding inconsistent aliases is definitely fundamental to supporting PAT.
-hpa
--
To unsubscribe
* Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
> > but i have not seen this message in your boot log. Could you boot
> > with early_ioremap_debug and send us the dmesg - i'm curious which
> > ACPI tables are actively mapped while those devices are initialized.
>
> Hmm, early_ioremap_debug exis
On Thu, Jan 17, 2008 at 10:42:09PM +0100, Ingo Molnar wrote:
>
> * Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jan 17, 2008 at 10:13:08PM +0100, Ingo Molnar wrote:
> > > but in general we must be robust enough in this case and just degrade
> > > any overlapping page to UC (and emit
Siddha, Suresh B wrote:
But then, this will cause an attribute conflicit. Old one was specifying
WB in PAT (ioremap with noflags) and the new ioremap specifies UC.
As Linus mentioned, main problem is to figure out the correct attribute
for ioremap() which doesn't specify the actual attribute to
On Thu, Jan 17, 2008 at 10:13:08PM +0100, Ingo Molnar wrote:
>
> * Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
>
> > Yes.
> >
> > Meanwhile I have figured out that it is some ACPI stuff that maps the
> > page cached. I've changed the ioremap's in drivers/acpi/osl.c to
> > ioremap_nocache. See
* Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 17, 2008 at 10:13:08PM +0100, Ingo Molnar wrote:
> > but in general we must be robust enough in this case and just degrade
> > any overlapping page to UC (and emit a warning perhaps) - instead of
> > failing the ioremap and thus failin
On Thu, Jan 17, 2008 at 10:13:08PM +0100, Ingo Molnar wrote:
> but in general we must be robust enough in this case and just degrade
> any overlapping page to UC (and emit a warning perhaps) - instead of
> failing the ioremap and thus failing the driver (and the bootup).
But then, this will caus
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> * Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
>
> > Yes.
> >
> > Meanwhile I have figured out that it is some ACPI stuff that maps the
> > page cached. I've changed the ioremap's in drivers/acpi/osl.c to
> > ioremap_nocache. See attached patch.
> >
* Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
> Yes.
>
> Meanwhile I have figured out that it is some ACPI stuff that maps the
> page cached. I've changed the ioremap's in drivers/acpi/osl.c to
> ioremap_nocache. See attached patch.
>
> Now the machine boots without conflicts.
ah, nice!
bu
On Thu, Jan 17, 2008 at 09:36:00PM +0100, Ingo Molnar wrote:
>
> * Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
>
> > For the failed devices I get:
> >
> > sata_sil :00:12.0: version 2.3
> > ACPI: PCI Interrupt :00:12.0[A] -> GSI 22 (level, low) -> IRQ 22
> > ioremap_nocache: addr
On Thu, 17 Jan 2008, H. Peter Anvin wrote:
> > > swapper:1 conflicting cache attribute c0403000-c0404000
> > > uncached<->default
> > > ACPI: PCI interrupt for device :00:12.0 disabled
>
> The correct behaviour probably would be to go with the most restrictive
> caching behaviour, i.e.
* H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>> as an intermediate fix, how about following the attribute of the
>> already existing mapping, instead of rejecting the ioremap due to the
>> conflict? I.e. something like below?
>
> The correct behaviour probably would be to go with the most
> res
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> I.e. something like below?
or the one below. (it even builds)
Ingo
---
arch/x86/mm/pat.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
Index: linux-x86.q/arch/x86/mm/pat.c
Ingo Molnar wrote:
* Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
For the failed devices I get:
sata_sil :00:12.0: version 2.3
ACPI: PCI Interrupt :00:12.0[A] -> GSI 22 (level, low) -> IRQ 22
ioremap_nocache: addr c0403000, size 200
swapper:1 conflicting cache attribute c040300
* Andreas Herrmann3 <[EMAIL PROTECTED]> wrote:
> For the failed devices I get:
>
> sata_sil :00:12.0: version 2.3
> ACPI: PCI Interrupt :00:12.0[A] -> GSI 22 (level, low) -> IRQ 22
> ioremap_nocache: addr c0403000, size 200
> swapper:1 conflicting cache attribute c0403000-c040400
On Thu, Jan 17, 2008 at 08:12:11PM +0100, Andreas Herrmann3 wrote:
> On Wed, Jan 16, 2008 at 12:33:28PM -0800, Venki Pallipadi wrote:
>
> I guess the conflict for sata is
> ioremap: addr c0403104, size fc
> ioremap_nocache: addr c0403000, size 200
>
> But where does the conflict for
On Wed, Jan 16, 2008 at 12:33:28PM -0800, Venki Pallipadi wrote:
> This ioremap failing seems to be the real problem. This can be due to
> new tracking of ioremaps introduced by PAT patches. We do not allow
> conflicting ioremaps to same region. Probably that is happening
> in both Sound and sata i
> Yes. Printks are there. But are with KERN_DEBUG now. We should change
> them to WARNING atleast.
I'm pretty sure they were without KERN_* originally. Another reason
why the checkpatch.pl KERN_* warnings suck -- the original state would
have been better and I bet you changed it just to shut up t
PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; Barnes, Jesse;
>[EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Siddha, Suresh B
>Subject: Re: [patch 0/4] x86: PAT followup - Incremental
>changes and bug fixes
>
>&
> This ioremap failing seems to be the real problem. This can be due to
> new tracking of ioremaps introduced by PAT patches. We do not allow
> conflicting ioremaps to same region. Probably that is happening
Normally if there is a conflict there should be a printk (or at least it was
so in the ori
On Wed, Jan 16, 2008 at 07:57:48PM +0100, Andreas Herrmann wrote:
> Hi,
>
> I just want to report that the PAT support in x86/mm causes crashes
> on two of my test machines. On both boxes the SATA detection does
> not work when the PAT support is patched into the kernel.
>
> Symptoms are as follo
* Andreas Herrmann <[EMAIL PROTECTED]> wrote:
> I just want to report that the PAT support in x86/mm causes crashes on
> two of my test machines. On both boxes the SATA detection does not
> work when the PAT support is patched into the kernel.
>
> Symptoms are as follows -- best described by a
TED];
>>[EMAIL PROTECTED]; Barnes, Jesse; [EMAIL PROTECTED];
>>linux-kernel@vger.kernel.org
>>Subject: Re: [patch 0/4] x86: PAT followup - Incremental
>>changes and bug fixes
>>
>>Hi,
>>
>>I just want to report that the PAT support in x86/mm causes c
CTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
>[EMAIL PROTECTED]; Barnes, Jesse; [EMAIL PROTECTED];
>linux-kernel@vger.kernel.org
>Subject: Re: [patch 0/4] x86: PAT
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Some incremental changes and bug fixes for PAT patchset. The changes
> are from the feedback we received earlier. There are few more pending
> changes that will follow soon.
thanks, applied them to x86.git.
Note that PAT is still hardcoded to d
Some incremental changes and bug fixes for PAT patchset. The changes are from
the feedback we received earlier. There are few more pending changes that will
follow soon.
Thanks,
Venki
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
41 matches
Mail list logo
