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

[Ben Liblit]

I had previously reported:
> get_diskinfo() calls get_diskinfo_standard(1, ...), which immediately
> returns error code 96.

Okuji replied:
> That's interesting, but I don't know what 96 means unfortunately. It
> isn't documented in the Ralf Brown's Interrupt List...

Then the 96 is probably not being returned by the BIOS.  Rather, we
are probably hitting the following code in get_diskinfo_standard():

            /* bogus BIOSes may not return an error number */
            testb       $0x3f, %cl      /* 0 sectors means no disk */
            jnz 1f              /* if non-zero, then succeed */
            /* XXX 0x60 is one of the unused error numbers */
            movb        $0x60, %ah
    1:
            movb        %ah, %bl        /* save return value in %bl */

Note that "XXX" line, which is surely where the 96 (0x60) is coming
from.  Does that give us any new insight into what's going on?

<http://savannah.gnu.org/cgi-bin/viewcvs/grub/grub/stage2/asm.S.diff?r1=1.3&r2=1.4&diff_format=h>
contains CVS information about the revision in which this code was
added to get_diskinfo_standard(), if that's any help.

Okuji also wrote:
> I don't remember why get_diskinfo_floppy is there any longer; It seems
> not only unnecessary but also harmful, I think. Remove the call and
> see if that could affect other drives as well.

If I comment out the get_diskinfo_floppy() call, then floppy disk
detection becomes sane.  GRUB consistently and correctly detects (fd0)
and no other floppy drives.  Calls to get_diskinfo_standard() continue
to return error code 96 for drive 1 and error code 1 for drives 2 - 7.

> Perhaps your BIOS is too sensitive, that is, reading a non-existing
> drive might break BIOS code.

Indeed.  It's pretty clear now that calling get_diskinfo_floppy() for
drive 1 does bad things to my BIOS.  It causes an eleven second hang
on the first call and causes an extra (fd1) drive to appear on future
get_diskinfo_standard().  Perhaps the get_diskinfo_floppy() call
should be removed.  Or perhaps it should just be skipped when
get_diskinfo_standard() returns error code 96.


Regarding hangs on access to (hd0), I had written:
> Near as I can tell, the first call rawread() never returns.

Okuji replied:
> That's quite strange, but that may be related to the floppy drive
> probing.

No such luck.  Even with the get_diskinfo_floppy() call commented out,
commands like "geometry (hd0)" hang forever.  :-(

I've traced things a bit further down the call chain:

   - command "geometry (hd0)" eventually causes a call to...

   - rawread() with drive=0x80, sector=0, byte_offset=0, byte_len=512,
     which contains three textual instances of calls to biosdisk().
     We reach the first textual instance at stage2/disk_io.c:165,
     which is...

   - biosdisk() with read=0 (BIOSDISK_READ), drive=0x80,
     geometry->flags=1, geometry->cylinders=1023, geometry->heads=255,
     geometry->sectors=63, geometry->total_sectors=17873039, sector=0,
     nsec=63, segment=0x77E0 (BUFFERSEG), which calls...

   - biosdisk_int13_extensions() with ah=0x42, drive=0x80,
     dap->length=16, dap->block=0, dap->blocks=1, dap->reserved=0,
     dap->buffer=0x77E00000 (BUFFERSEG << 16)

The call to biosdisk_int13_extensions() never returns.

Does this get us any closer to a solution?