Re: "grub" command works, but GRUB boot loader hangs

[Ben Liblit]

A little while back, I had reported:
> The call to biosdisk_int13_extensions() never returns.

Okuji said that this points at either a bug in GRUB or broken LBA
support in my BIOS.  Thus:
> First, I'd recommend investigating if GRUB could work with your
> BIOS, when the LBA support of your BIOS is disabled.  If that allows
> GRUB to work with your BIOS, then your BIOS must be buggy.

I'm dealing with two BIOSes here: my motherboard's BIOS and my SCSI
controller's BIOS.  I found and disabled LBA support in my motherboard
BIOS, and that had no effect.  No big surprise there, I guess, since
the disk I'm trying to boot hangs off the SCSI controller.

I couldn't really find anything in the SCSI BIOS setup that sounded
like it corresponded to LBA support.  I toggled a "Extended BIOS
Translation For DOS Drives > 1 GByte" option, but that had no effect.

I'm kind of absent minded, and by this time I'd forgotten what I was
even looking for.  :-)  The next time I went into my SCSI BIOS setup,
I saw a "BIOS Support for Int13 Extensions" option, and I convinced
myself that this is what I had been looking for, and I turned it off.
Presto: GRUB now works!  Disabling int13 extensions was the key.

Let me review what we know so far:

  - Issue #1: eleven second hang and detection of bogus floppy disk.
    We eventually attributed this to the get_diskinfo_floppy() call in
    get_diskinfo(), on line 220 of stage2/bios.c.  Both the hang and
    the bogus floppy disk are fixed by commenting out this call.

    What happens next?  In an earlier message, Okuji wrote "I don't
    remember why get_diskinfo_floppy is there any longer; It seems not
    only unnecessary but also harmful, I think."  Should we officially
    remove that call?  I know that would help my machine.  Perhaps we
    should make that change and see if it breaks things for anyone
    else...?  I defer to the better judgment of Okuji and the other
    core developers on how to proceed.

  - Issue #2: permanent hang on access to hard drives.  Fixed by
    disabling int13 extensions in SCSI controller BIOS.

    Okuji had asked me to try disabling LBA support, not int13
    extensions.  Are those two different terms for the same thing?  Or
    are they unrelated and somehow I just got lucky?

    Presumably, this latest experiment reveals that my SCSI
    controller's BIOS is buggy.  I guess we have three options:

       1. I keep int13 extensions disabled in my BIOS.  Has no
          development impact on GRUB, but anyone else with the same
          controller will have to re-discover the same issue.

       2. GRUB gains the ability to detect this specific BIOS and
          avoids using the buggy int13 calls.  Such a workaround would
          require additional development, but will proactively avoid
          future bug reports from other users with similar hardware.

       3. GRUB gains a new command which lets users tell it not to use
          int13 extensions on specific devices.  Future users will
          still have to re-discover this issue, but the workaround is
          ready and waiting, and could be recommended as a thing to
          try in the GRUB FAQ.

    To be honest, I find it surprising that my SCSI BIOS turned out to
    be buggy, since this is such a mainstream controller.  The Adaptec
    AHA-2940UW might be a bit dated now, but in its day it was an
    extremely widespread piece of hardware.  I would have thought that
    any bugs in its BIOS would have been found and fixed long ago.
    Apparently not.  :-(

    Does anyone else have a 2940 controller?  Does GRUB work for you?
    If at least one person can state that GRUB works correctly on
    their AHA-2940UW, then we have a more interesting scenario,
    because that would suggest that the problem is not simply with the
    SCSI controller, but is with some interaction between the
    controller and other components of my system.