[lkml]   [2002]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Fastboot] [CFT] kexec syscall for 2.5.43 (linux booting linux)
    Andy Pfiffer <> writes:

    > > > lspci output for the system:
    > > > 00:00.0 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06)
    > > > 00:00.1 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06)
    > > > 00:01.0 VGA compatible controller: S3 Inc. Savage 4 (rev 04)
    > > > 00:09.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev
    > 08)
    > > > 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 50)
    > > > 00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller
    > > > 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04)
    > > > 01:03.0 SCSI storage controller: Adaptec AIC-7892P U160/m (rev 02)
    > > And please tell me what kexec_test-1.4 reports. I would love to find out which
    > > BIOS calls are hanging your system.
    > It's this one: call print_dasd_type

    Cool, thanks.

    This is both good, and bad.
    The Good: This BIOS call is only used to populate disk_info to get the
    disk geometry, which is only in hd.c, and further this call
    rests on a broken assumption that the both the first and the
    second BIOS disks are IDE, so it should be safe to remove
    the call from setup.S, And there is another filter in
    that makes it work.

    The Bad: That would take patching the kernel, so on some machines
    older kernels will not work...

    I have not setup the x86 pic so it may be worth setting that up and
    testing to see if that helps.

    > If I comment it out, kexec_test-1.4 runs to completion.
    > FYI: My installation is on a scsi disk. I'm beginning to wonder if
    > there is something funky with the BIOS not being able to talk to
    > the SCSI controller after the kernel has used it... Hmmm.

    I would not be surprised, if that is part of the problem.
    Did you have to edit the aic7xxx reboot notifier to get scsi reboots
    to work? The reboot notifier should be what sets the controller up
    so it can be reinitialized by Linux later.

    I am attempting to figure out where to go with the user space side to
    get a useable, and useful ability to boot new kernels.

    1) If loaded from loadlin or a sufficiently buggy BIOS is present
    we need to skip the 16bit BIOS calls already.
    2) It is ideal to requery the system BIOS in case there are enhancements
    like the EDD work that make the new kernel more useable.

    So my strategy will be:
    1) As much as is reasonable fix setup.S to work in strange hostile environments,
    there is a lot to be gained and currently it usually works as is.
    2) Query the existing kernel infrastructure and as much as possible
    fill in the table of data wants. And I will skip to the 32bit entry point,
    with that information.

    The second will take a bit more work, but having it as an option looks like
    a very healthy thing to have.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:30    [W:0.023 / U:9.272 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site