But now that I think about it (see source code below) it seems that mxt_scan_bios is probably not the culprit at all.
I think the routine just returns that error code and the caller records that there is no mxt memory and goes on with its next task. Which is, from the looks of my listings when I successfully boot from the floppy, the Swap file. That might bear some relation to my earlier thoughts on the matter - namely disk partitioning anomalies. If this is correct, then the actual crap-out point is either in the routine that calls mxt_scan_bios, or in the swap routine, before it has a chance to print out its message. Anyone following me, here? Steve Cohen wrote: > 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 > _______________________________________________ Redhat-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
