Re: "Ghost" devices in /sys/firmware/edd

[Matt Domsch <Matt_Domsch@dell.com>]

On Fri, Feb 24, 2006 at 10:14:34PM +0300, Andrey Borzenkov wrote:
> I have single drive hda; still EDD shows valid and the _same_ MBR signature 
> for all possible 16 drives:
> 
> {pts/0}% cat /sys/firmware/edd/*/mbr_*
> 0x7fca3a0a
> 0x7fca3a0a
> 0x7fca3a0a
[snip]
> 
> other attributes are correctly present for the drive 0x80 only.
> 
> Not being expert in x86 assembly, but comparing main loops for signature and 
> other info:
> 
> signature:
>         int     $0x13
>         sti                     # work around buggy BIOSes
>         popw    %dx
>         popw    %es
>         popw    %bx
>         jc      edd_mbr_sig_done                # on failure, we're done.

The code here is fine.  Immediately before the int13 is an stc
instruction, so the carry flag is set.  sti and popw don't change CF.
What this means is that your BIOS cleared CF in the int13 to a
nonexistant disk, rather than setting CF (or leaving it unchanged).
CF being clear means the command succeeded.  In your case, the BIOS
cleared it, but shouldn't have.

Care to share your system type / BIOS version, and if it's at all
recent, file an bug with their support department?


> extended EDD info:
> 
> edd_check_ext:
>         movb    $CHECKEXTENSIONSPRESENT, %ah    # Function 41
>         movw    $EDDMAGIC1, %bx                 # magic
>         int     $0x13                           # make the call
>         jc      edd_done                        # no more BIOS devices
> 

Yet, it does properly set CF on int13 AH=41h to a nonexistant disk.
How annoying.


> Is it possible that carry flag is cleared between return from int 0x13 and 
> querying for it in the former case? This would perfectly explain that EDD 
> does not notice failure of reading sector and simply copies the same 
> signature from the very first drive.

I'll look more next week, but what isn't ever happening is an int13
AH=15h GET DISK TYPE probe to see if the disk is there.  The edd.S
code just issue a READ SECTORS and expects that to fail (to set CF) if
it's not there.  This has been working fine for most people.  In your
case, it's not reporting a failure (CF is cleared by the int13).  Now,
there's no guarantee your BIOS would respond properly to the GET DISK
TYPE command either.  There are also notes that BIOS should set
0040h:0075h to the number of drives present, and the code isn't
reading that value now either.  Either of these tests, if the BIOS
isn't buggy for them, could result in reporting the right number of
disks.

Thanks much for the report and for digging to find where the mistake
could be.

Thanks,
Matt

-- 
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/