CentOS - Jan 2006 - CentOS 4.2 x86_64

I have a couple of 64-Bit Xeon's with CentOS 4.2 x86_64 installed on
them.  They don't all have the same motherboards.

I've having a difficult time getting CentOS 4.2 x86_64 to boot on some
of them in SMP mode (UP works fine).  After the installation of CD, it
boots up but kernel panics with the following error:

Badness in i8042_panic_blink at drivers/input/serio/i8042.c:992

This is the call trace:

apic_timer_interrupt+133
vgacon_cursor+0
oops_end+64
release_console_sem+369
error_exit+0
:scsi_mod:scsi_delete_timer+19
:3w_9xxx:twa_interrupt+1323
do_IRQ+197
mwait_idle+86
cpu_idle+26


The Uni processor works fine.

I tried the SMP kernel from Fedora Core 4 x86_64 which works fine as
well.  Any idea what's going on here?  I've already tried disabling as
many things from the BIOS as possible.

Thanks for any help.

I am running a multithreaded test program that calls the
Berkeley DB library. This test runs on many platforms.
Lately I have been trying it under CentOS on an Intel x86_64
which is hyperthreaded.
I get a variety of failures.  Mostly they appear to be because
of addressing errors.  For instance:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1178638688 (LWP 7957)]
0x0000002a956225af in __db_cursor_int (dbp=0x2f2f388, txn=0x0,
     dbtype=DB_BTREE, root=0, is_opd=0, lockerid=0, dbcp=0x46408c20)
     at ../dist/../db/db_am.c:68
68                      if (dbtype == dbc->dbtype) {
(gdb) p dbc
$6 = (DBC *) 0x2f3ae5800000000

Note all the zeros.  Now if we shift the
address down:

(gdb) p *(DBC*)  0x2f3ae58
$7 = {dbp = 0x2f2f388, txn = 0x0, links = {tqe_next = 0x2f47ef8,
     tqe_prev = 0x2f3d4c8}, rskey = 0x2f3ae90, rkey = 0x2f3aeb0,
   rdata = 0x2f3aed0, my_rskey = {data = 0x0, size = 0, ulen = 0,  
dlen = 0,
     doff = 0, flags = 0}, my_rkey = {data = 0x0, size = 0, ulen = 0,  
dlen = 0,
     doff = 0, flags = 0}, my_rdata = {data = 0x0, size = 0, ulen = 0,
     dlen = 0, doff = 0, flags = 0}, lref = 0x2f2a290, locker = 19,  
lock_dbt = {
     data = 0x2f3af20, size = 28, ulen = 0, dlen = 0, doff = 0, flags  
= 0},
   lock = {pgno = 925,
     fileid = "X@\203\000\000?\000\000?\224E\205?\036\000\000\000 
\000\000",
     type = 3}, mylock = {off = 0, ndx = 0, gen = 0, mode = DB_LOCK_NG},
   cl_id = 0, dbtype = DB_BTREE, internal = 0x2f39228,
   c_close = 0x2a956388a3 <__db_c_close_pp>,
   c_count = 0x2a95638a63 <__db_c_count_pp>,
   c_del = 0x2a95638ba7 <__db_c_del_pp>, c_dup = 0x2a95638ea3  
<__db_c_dup_pp>,
   c_get = 0x2a95638fce <__db_c_get_pp>,
   c_pget = 0x2a95639746 <__db_c_pget_pp>,
   c_put = 0x2a956399f6 <__db_c_put_pp>, c_am_bulk = 0x2a9557fdd2  
<__bam_bulk>,
   c_am_close = 0x2a9557dcc4 <__bam_c_close>,
   c_am_del = 0x2a9557ebd3 <__bam_c_del>,
   c_am_destroy = 0x2a9557e50e <__bam_c_destroy>,
   c_am_get = 0x2a9557f10a <__bam_c_get>,
   c_am_put = 0x2a95582040 <__bam_c_put>,
   c_am_writelock = 0x2a9558314f <__bam_c_writelock>, flags = 288}

This is the right address.

Sometimes this part of the code executes correctly and it fails
elsewhere.  Often appearing that an address has been shifted
by 32 bits.

Any ideas?

You might want to try and build a CentOS 4.3beta kernel and see if
that fixes the problem.

The SRPM is at:

http://beta.centos.org/centos/4.3beta/os/SRPMS/kernel-2.6.9-27.EL.src.rpm

No idea if it will help or not.

James Pearson

On 14/01/06, Fong Vang <sudoyang at gmail.com>
wrote:
> I have a couple of 64-Bit Xeon's with CentOS 4.2 x86_64 installed on
> them.  They don't all have the same motherboards.
>
> I've having a difficult time getting CentOS 4.2 x86_64 to boot on some
> of them in SMP mode (UP works fine).  After the installation of CD, it
> boots up but kernel panics with the following error:
>
> Badness in i8042_panic_blink at drivers/input/serio/i8042.c:992
>
> This is the call trace:
>
> apic_timer_interrupt+133
> vgacon_cursor+0
> oops_end+64
> release_console_sem+369
> error_exit+0
> :scsi_mod:scsi_delete_timer+19
> :3w_9xxx:twa_interrupt+1323
> do_IRQ+197
> mwait_idle+86
> cpu_idle+26
>
>
> The Uni processor works fine.
>
> I tried the SMP kernel from Fedora Core 4 x86_64 which works fine as
> well.  Any idea what's going on here?  I've already tried disabling
as
> many things from the BIOS as possible.