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
"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
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
for ioremap()
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
a, Suresh B; [EMAIL PROTECTED];
> >[EMAIL PROTECTED]; [EMAIL PROTECTED];
> >[EMAIL PROTECTED]; [EMAIL PROTECTED];
> >[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> >[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> >Barnes, Jesse; [EMAIL PROTE
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 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 at
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 followup - Incremental
]; [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
On Thu, Jan 17, 2008 at 03:04:10PM -0800, Venki Pallipadi
> 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
> >
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
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,
* 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
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
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
* 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
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
* 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
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
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
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.
* 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
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
* 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!
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
>
* 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
* 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
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
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
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:
snip
I guess the conflict for sata is
ioremap: addr c0403104, size fc
ioremap_nocache: addr c0403000, size 200
But where does the conflict for
* 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-c0404000
* 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
* 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!
but in
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. uncached in
* 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
restrictive
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 c0403000, size
* 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.
Now the
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 attached
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 cause
* 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 failing the
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
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 cached. I've changed
* 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 patch.
]; [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
On Thu, Jan 17, 2008 at 03:04:10PM -0800, Venki Pallipadi
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, Ingo Molnar wrote:
* 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 exists only
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 at
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
dmesg attached.
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 cached. I've changed
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
* 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 and just degrade
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 a warning
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 [EMAIL PROTECTED] wrote:
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
> 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
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
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
* 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
;>[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 crashes
>
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]; [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
];
[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 followup - Incremental
* 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 diff
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 follows --
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
]; [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
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
* [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
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
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
* [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
82 matches
Mail list logo
