I have a new dual Opteron 248 system here with an MSI K8T Master2-FAR
mainboard that isn't happy with 2.6.0-test. In fact, it's not altogether
happy with any SMP kernel so far, but will boot RedHat's 2.4.21EL single
processor kernel and appears to function normally.
I'm having problems compiling 2.6.0-test9 through bk22 on this box,
erroring here:
CC arch/x86_64/kernel/head64.o
CC arch/x86_64/kernel/init_task.o
CPP arch/x86_64/kernel/vmlinux.lds.s
CC [M] arch/x86_64/kernel/msr.o
make[1]: *** No rule to make target `arch/x86_64/kernel/cpuid.c', needed
by `arch/x86_64/kernel/cpuid.o'. Stop.
make: *** [arch/x86_64/kernel] Error 2
I've tried various -mm patches, but error elsewhere:
CC arch/x86_64/kernel/nmi.o
arch/x86_64/kernel/nmi.c: In function `nmi_watchdog_tick':
arch/x86_64/kernel/nmi.c:317: warning: ISO C90 forbids mixed
declarations and code
CC arch/x86_64/kernel/io_apic.o
arch/x86_64/kernel/io_apic.c:1215: redefinition of
`disable_edge_ioapic_irq'
include/asm/io_apic.h:178: `disable_edge_ioapic_irq' previously defined
here
arch/x86_64/kernel/io_apic.c:1259: redefinition of `end_edge_ioapic_irq'
include/asm/io_apic.h:180: `end_edge_ioapic_irq' previously defined here
arch/x86_64/kernel/io_apic.c:1346: redefinition of
`mask_and_ack_level_ioapic_irq'
include/asm/io_apic.h:179: `mask_and_ack_level_ioapic_irq' previously
defined here
include/asm/io_apic.h:178: warning: `disable_edge_ioapic_irq' defined
but not used
include/asm/io_apic.h:179: warning: `mask_and_ack_level_ioapic_irq'
defined but not used
include/asm/io_apic.h:180: warning: `end_edge_ioapic_irq' defined but
not used
make[1]: *** [arch/x86_64/kernel/io_apic.o] Error 1
make: *** [arch/x86_64/kernel] Error 2
2.4.22 vanilla compile breaks at
gcc -D__KERNEL__ -I/usr/src/linux-2.4.22/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fomit-frame-pointer -mno-red-zone -mcmodel=kernel -pipe
-fno-reorder-blocks -finline-limit=2000 -fno-strength-reduce
-Wno-sign-compare -fno-asynchronous-unwind-tables -nostdinc
-iwithprefix include -DKBUILD_BASENAME=mpparse -c -o mpparse.o
mpparse.c
mpparse.c: In function `mp_register_ioapic':
mpparse.c:763: warning: long unsigned int format, different type arg
(arg 5)
mpparse.c:763: warning: long unsigned int format, different type arg
(arg 5)
mpparse.c: In function `mp_parse_prt':
mpparse.c:952: too few arguments to function `acpi_pci_link_get_irq'
make[1]: *** [mpparse.o] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.22/arch/x86_64/kernel'
make: *** [_dir_arch/x86_64/kernel] Error 2
I removed ACPI support and the kernel built and booted, seeing both
processors, but the tg3 driver wouldn't load, not finding the hardware,;
the 2.4.21EL kernel has no issues with this module. Is there a patch I'm
missing?
There was significant oddness with this kernel, however, as top would
show CPU stats oscillating between 33.3% irq, softirq, and iowait per
CPU, and 0.0% every odd second. This was on a quiescent system.
I can compile 2.6.0-test9-bk22 from Arjan's source RPM successfully. I'm
obviously missing a patch. Regardless, an attempt to boot any 2.6.0
kernel, single or SMP fails on load with a
slab: error in check_poison_obj(): "biovec-#" object was modified after
freeing
then a slew of acpi-related errors rapidly scroll ad infinitum.
A SMP boot of RedHat's 2.4.21-4.1EL kernel gives back:
Code: bad RIP value
then a call trace to stop_this_cpu.
A straight install of SuSE SLES 64 simply won't boot, as the kernel
2.4.19 kernel is SMP, and panics with the same error as above.
I don't have an older Opteron box, so I can't tell if this is related to
the new CPUs or not.
-Paul
I meant to include more complete traces in my previous post, but I'm
having some odd problem with serial consoles on this box so I only get
partial clean output. Here's what I can gather at the moment:
2.6.0-test9 (snip):
Call Trace:<ffffffff8014aed4>{__kmalloc+186}
<ffffffff80186f64>{proc_create+100}
<ffffffff801870f2>{create_proc_entry+96}
<ffffffff801321ce>{register_proc_table+176}
<ffffffff801321ff>{register_proc_table+225}
<ffffffff801321ff>{register_proc_table+225}
<ffffffff803f0688>{sysctl_init+20}
<ffffffff803e56ec>{do_basic_setup+11}
<ffffffff8010b05b>{init+32} <ffffffff8010b03b>{init+0}
<ffffffff80110acf>{child_rip+8} <ffffffff8010b03b>{init+0}
<ffffffff80110ac7>{child_rip+0}
Slab corruption: start=0000010037f08748, expend=0000010037f08807,
problemat=0000010037f0874c
Last user: [<0000000000000000>](0x0)
Data: ....00 00 00 00 ....00 00 00 00 ....00 00 00 00 ....00 00 00 00
....00 00 00 00 ....00 00 00 00 ....00 00 00 00 ....00 00 00 00 ....00
00 00 Next: 71 F0 2C .00 00 00 00 00 00 00 00 00 00 00 00 A5 C2 0F 17 00
00 00 00 84 10 0C 00 00 00 00 00
slab error in check_poison_obj(): cache `size-192': object was modified
after freeing
2.4.21EL-4.0smp:
RIP: 0010:[<000000008010de3e>]
RSP: 0018:00000100077cbfc8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffffff8010de20 RCX: 00000000ffffffff
RDX: 00000100077ca000 RSI: 0000000000000001 RDI: ffffffff806031c0
RBP: ffffffff8010de20 R08: 00000000ffffffff R09: 0000000000000003
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffffff805fb580(0000)
knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 000000008010de3e CR3: 00000000079b9000 CR4: 00000000000006e0
Call Trace: [<ffffffff8010de20>]{default_idle+0}
[<ffffffff8010dec9>]{cpu_idle+73}
Process swapper (pid: 0, stackpage=100077cb000)
Stack: 00000100077cbfc8 0000000000000018 ffffffff8010de20
ffffffff8010dec9
0000000000000010 0000000000000405 0000000000000001
ffffffff8063abef
0000000000000000 0000000000000002
Call Trace: [<ffffffff8010de20>]{default_idle+0}
[<ffffffff8010dec9>]{cpu_idle+73}
Code: Bad RIP value.
Kernel panic: Fatal exception
In idle task - not syncing
On Fri, 2003-11-21 at 23:32, Paul Venezia wrote:
> I meant to include more complete traces in my previous post, but I'm
> having some odd problem with serial consoles on this box so I only get
> partial clean output. Here's what I can gather at the moment:
>
this may be a case of "the" bios bug; could you try passing "idle=poll"
to the kernel ?
If that helps you need a newer bios....
On Sat, 2003-11-22 at 05:30, Arjan van de Ven wrote:
> On Fri, 2003-11-21 at 23:32, Paul Venezia wrote:
> > I meant to include more complete traces in my previous post, but I'm
> > having some odd problem with serial consoles on this box so I only get
> > partial clean output. Here's what I can gather at the moment:
> >
>
> this may be a case of "the" bios bug; could you try passing "idle=poll"
> to the kernel ?
> If that helps you need a newer bios....
>
I had checked for a newer BIOS for this board, but there isn't a newer
version available. Passing idle=poll permits the RH 2.4.21EL-smp kernel
to boot, and mysql is now functional. 2.6.0-test9, test9-smp, test10,
and test10-smp still will not boot.
-Paul