On 02/24/2010 06:37 AM, Jan Beulich wrote:
"Justin P. Mattock" 03.02.10 02:43>>>
Could you try this simple patch (against plain 2.6.33-rc8)?
Thanks, Jan
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -82,6 +82,9 @@ enum fixed_addresses {
#endif
FIX_DBGP_B
>>> "Justin P. Mattock" 03.02.10 02:43 >>>
Could you try this simple patch (against plain 2.6.33-rc8)?
Thanks, Jan
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -82,6 +82,9 @@ enum fixed_addresses {
#endif
FIX_DBGP_BASE,
FIX_EARLYCON_MEM_BASE,
+#ifde
On 02/04/10 01:57, Jan Beulich wrote:
"Justin P. Mattock" 04.02.10 10:48>>>
I see:
ohci.registers = (void *)fix_to_virt(FIX_OHCI1394_BASE);
then I think it calls:
set_fixmap_nocache(FIX_OHCI1394_BASE, ohci_base);
I'm guessing somewhere with the fix_to_virt might be something
(but could be w
On 02/04/10 01:57, Jan Beulich wrote:
"Justin P. Mattock" 04.02.10 10:48>>>
I see:
ohci.registers = (void *)fix_to_virt(FIX_OHCI1394_BASE);
then I think it calls:
set_fixmap_nocache(FIX_OHCI1394_BASE, ohci_base);
I'm guessing somewhere with the fix_to_virt might be something
(but could be w
>>> "Justin P. Mattock" 04.02.10 10:48 >>>
>I see:
>
>ohci.registers = (void *)fix_to_virt(FIX_OHCI1394_BASE);
>
>then I think it calls:
>
>set_fixmap_nocache(FIX_OHCI1394_BASE, ohci_base);
>
>I'm guessing somewhere with the fix_to_virt might be something
>(but could be wrong);
No, it ought to be
On 02/04/10 01:35, Jan Beulich wrote:
"Justin P. Mattock" 04.02.10 10:17>>>
so something is using __native_set_fixmap
that's hitting some memory address then
set_fixmap_nocache(ohci1394_dma=early)
fires off hitting the same?
No, afaict it is the ohci1394_dma=early code itself hitting that pat
>>> "Justin P. Mattock" 04.02.10 10:17 >>>
>so something is using __native_set_fixmap
>that's hitting some memory address then
>set_fixmap_nocache(ohci1394_dma=early)
>fires off hitting the same?
No, afaict it is the ohci1394_dma=early code itself hitting that path.
Jan
--
To unsubscribe from t
On 02/04/10 01:11, Jan Beulich wrote:
"Justin P. Mattock" 04.02.10 10:04>>>
a quick google on this showed somewhere
at bootmem.c any ideas on this or where
this might be caused besides fixmap?
(or is fixmap the main location?);
__native_set_fixmap() -> set_pte_vaddr() -> set_pte_vaddr_pud()
>>> "Justin P. Mattock" 04.02.10 10:04 >>>
>a quick google on this showed somewhere
>at bootmem.c any ideas on this or where
>this might be caused besides fixmap?
>(or is fixmap the main location?);
__native_set_fixmap() -> set_pte_vaddr() -> set_pte_vaddr_pud() ->
fill_pte() -> spp_getpage() ->
On 02/04/10 00:54, Jan Beulich wrote:
"Justin P. Mattock" 04.02.10 00:05>>>
[ 0.00] 01 - 014000 page 2M
[ 0.00] kernel direct mapping tables up to 14000 @ b000-11000
[ 0.00] init_ohci1394_dma: initializing OHCI-1394 at 05:00.0
[ 0.00] bootmem alloc of 409
>>> "Justin P. Mattock" 04.02.10 00:05 >>>
>[ 0.00] 01 - 014000 page 2M
>[ 0.00] kernel direct mapping tables up to 14000 @ b000-11000
>[ 0.00] init_ohci1394_dma: initializing OHCI-1394 at 05:00.0
>[ 0.00] bootmem alloc of 4096 bytes failed!
>[ 0.00] K
o.k. while looking into grub2
I had noticed during compile time
and reading posts, that -m32 is always
being called(no matter how much I tweaked the
Makefile). seeing this made me think well
if this thing is being built with -m32 maybe that might
be it i.g. 32bit to 64bit might cause some issues,
jan,
Thanks for that info, after looking at
arch/x86/kernel/head_64.S
I'm thinking this is a grub2 issue.
From what I remember while building this system
I used ubuntu as the host, built grub2 from git
then once being able to boot, figured it was all good.
Just to see, I'll go and leave the ker
On 02/03/10 01:18, Jan Beulich wrote:
"Justin P. Mattock" 03.02.10 02:43>>>
The only thing I can think of at this point
is maybe the CFLAGS I used to build this system.
(as for the x86_32 working and x86_64 failing not sure);
I'm curious to see if anybody else is hitting this?
I think it is
>>> "Justin P. Mattock" 03.02.10 02:43 >>>
>The only thing I can think of at this point
>is maybe the CFLAGS I used to build this system.
>(as for the x86_32 working and x86_64 failing not sure);
>
>I'm curious to see if anybody else is hitting this?
I think it is pretty clear how a page fault ca
o.k. finally finished with the bisect:
reverting this gets things going on 2.6.33-rc5
789d03f584484af85dbdc64935270c8e45f36ef7 is the first bad commit
commit 789d03f584484af85dbdc64935270c8e45f36ef7
Author: Jan Beulich
Date: Tue Jun 30 11:52:23 2009 +0100
x86: Fix fixmap ordering
Th
On 02/01/10 22:57, Stefan Richter wrote:
Stefan Richter wrote:
Do I understand correctly that at this moment it is only known that the
bug could be
- *either* a 2.6.31 -> 2.6.32 regression
- *or* an x86-64 specific bug that does not occur on x86-32,
right?
(OK, according to your other p
On 02/01/10 22:55, Stefan Richter wrote:
Justin P. Mattock wrote:
As for anything changed in the kernel
(2.6.31 - present), tough to say
from what I remember I had created a new fresh
lfs system using these CFLAGS:
CFLAGS="-mtune=core2 -march=core2 -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CF
Stefan Richter wrote:
> Do I understand correctly that at this moment it is only known that the
> bug could be
> - *either* a 2.6.31 -> 2.6.32 regression
> - *or* an x86-64 specific bug that does not occur on x86-32,
> right?
(OK, according to your other post it /is/ a regression, at least on
Justin P. Mattock wrote:
> As for anything changed in the kernel
> (2.6.31 - present), tough to say
> from what I remember I had created a new fresh
> lfs system using these CFLAGS:
>
> CFLAGS="-mtune=core2 -march=core2 -O2 -pipe -fomit-frame-pointer"
> CXXFLAGS="${CFLAGS}" MAKEOPTS="{-j3}"
> (wit
o.k. I feel really stupid right now.
after starring at this for some time I didn't even
think to do a git revert to test other
kernel versions(duh!!).
so doing a git revert to v2.6.27 ohci1394_dma
boots up fine.
a bit late now to do a bisect, but in the morning
I'll start this and see what I get
On 02/01/10 21:45, Stefan Richter wrote:
Justin P. Mattock wrote:
So(correct me if I'm wrong), I'm generating a 64 bit register
and the kernel is looking for a 32 bit register causing the crash.
No, the class = read_pci_config(); if (class == ...) ... parts of the
code are entirely innocent as
Justin P. Mattock wrote:
> So(correct me if I'm wrong), I'm generating a 64 bit register
> and the kernel is looking for a 32 bit register causing the crash.
No, the class = read_pci_config(); if (class == ...) ... parts of the
code are entirely innocent as far as I can tell. This is just the
Fir
On 02/01/10 14:27, Stefan Richter wrote:
Justin P. Mattock wrote:
(as for yesterdays 0x(just experimenting)Google gives me
no info on the differences between 8f's to 16f's, I was under the
impression that it's x86_32 and x86_64 for the pci address).
As Dan noted,
(class
Justin P. Mattock wrote:
> (as for yesterdays 0x(just experimenting)Google gives me
> no info on the differences between 8f's to 16f's, I was under the
> impression that it's x86_32 and x86_64 for the pci address).
As Dan noted,
(class == 0x || 0x)
i
On 02/01/10 11:57, Stefan Richter wrote:
Justin P. Mattock wrote:
On 02/01/10 04:54, Dan Carpenter wrote:
On Sun, Jan 31, 2010 at 05:39:22PM -0800, Justin P. Mattock wrote:
On 01/31/10 16:43, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of regre
Justin P. Mattock wrote:
> On 02/01/10 04:54, Dan Carpenter wrote:
>> On Sun, Jan 31, 2010 at 05:39:22PM -0800, Justin P. Mattock wrote:
>>> On 01/31/10 16:43, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of regressions introduced between 2.
27 matches
Mail list logo
