Following up on my previous post to this list, I have been doing some 
investigation.
Since the boot sequence seems to be dying right after the string

mxt_scan_bios enter:

is printed on the screen, I decided to do a Google Search on the phrase.
Eventually I found my way here:

http://oss.software.ibm.com/mxt/

Where I learned that MXT is a technology for somewhat magically making 
your memory size appear to be double what it actually is.  Support for 
this has been integrated into the Linux Kernel starting with early 
versions of 2.4.  However you have to have this special kind of memory 
installed for it to work.

It's supposed to be safe to include this in the kernel even if you don't 
have actual MXT memory in your machine.  But I wonder.  Could the flaky 
conditions of boot-time, combined with this whiz-bang new technology 
somehow be interacting badly?

My problem, for those readers who haven't been following my earlier 
message, have to do with a computer that can't boot, except from a 
floppy, after an upgrade to RH 7.2 (from 7.0).  I had previously been on 
the trail of partition problems, but this MXP scenario seems more likely 
to be the culprit.

Looking at the Source Code, I can see exactly where the message is 
coming from:

static int mxt_scan_bios(void)
{
    unsigned long *bp = mxt_bios_table;
    unsigned char *p;
    int nr_real;
    int nr_inhibit;
    int i;

    printk("mxt_scan_bios: enter\n");

    if( ! mxt_bios_table[0] )
        return -ENODEV;

    mxt_bios_found = 1;

    p = (unsigned char *)bp;

    /* PIC mode interrupt nr */
    mxt_irq = (unsigned int) p[_nr_interrupt_];

    /* real and inhibit regions of the memory */
    nr_real = p[_nr_real_];
    nr_inhibit = p[_nr_inhibit_];

    if ( *((unsigned long *)(p+_L3_size_)) & 0x80000000 ) {
        mxt_compression_enabled = 1;
        printk("<MC> Compression is enabled\n");
    }
    else {
        mxt_compression_enabled = 0;
        printk("<MC> Compression is disabled\n");
    }

I think it must be hitting this    

if( ! mxt_bios_table[0] )
        return -ENODEV;
and the caller is not handling this error correctly (otherwise, another 
message would be appearing on the screen a few lines later on.)

Is there anyone reading this list for whom this rings a bell?
If not, can someone suggest another list where I could take this?






_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list

Reply via email to