Justin P. Mattock justinmatt...@gmail.com 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,
On 02/21/2010 01:42 PM, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32. Please verify if
On 02/07/10 16:28, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32. Please verify if it
On Monday 08 February 2010, Justin P. Mattock wrote:
On 02/07/10 16:28, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
On 02/04/10 01:57, Jan Beulich wrote:
Justin P. Mattockjustinmatt...@gmail.com 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
On 02/04/10 00:54, Jan Beulich wrote:
Justin P. Mattockjustinmatt...@gmail.com 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]
Justin P. Mattock justinmatt...@gmail.com 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() -
On 02/04/10 01:11, Jan Beulich wrote:
Justin P. Mattockjustinmatt...@gmail.com 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() -
Justin P. Mattock justinmatt...@gmail.com 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
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
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 jbeul...@novell.com
Date: Tue Jun 30 11:52:23 2009 +0100
x86: Fix
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
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,
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
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
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}
(without -m
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
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
On 01/24/10 14:22, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32. Please verify if it
On 01/10/10 14:56, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
introduced between 2.6.31 and 2.6.32. Please verify if it
On Monday 11 January 2010, Justin P. Mattock wrote:
On 01/10/10 14:56, Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of regressions introduced between 2.6.31 and 2.6.32.
The following bug entry is on the current list of known regressions
Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry :
On Tuesday 17 November 2009, Justin P. Mattock wrote:
Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.31. Please verify if it still should be
Rafael J. Wysocki wrote:
This message has been generated automatically as a part of a report
of recent regressions.
The following bug entry is on the current list of known regressions
from 2.6.31. Please verify if it still should be listed and let me know
(either way).
Bug-Entry :
24 matches
Mail list logo
