"Ghost" devices in /sys/firmware/edd

"Ghost" devices in /sys/firmware/edd

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
0x7fca3a0a
0x7fca3a0a
0x7fca3a0a
0x7fca3a0a
0x7fca3a0a
0x7fca3a0a
0x7fca3a0a
0x7fca3a0a
0x7fca3a0a
0x7fca3a0a
0x7fca3a0a
0x7fca3a0a
0x7fca3a0a

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.

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

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.

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFD/1smR6LMutpd94wRAncjAJ0b9wLmKK9V2bc93ghAIUa7dY5VWQCfZ8BP
aiT8y5TX3DE05ZN8wfnfg7E=
=uB1I
-----END PGP SIGNATURE-----

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

[Matt Domsch]

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

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

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 25 February 2006 08:07, Matt Domsch wrote:
[...]
> 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?
>

This is Toshiba Portege 4000, BIOS 2.10 dated 15 Dec 2003. I'll try to find 
how to submit a bug report but I do not hold my breath.

[...]
>
> 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.
>

More simple solution may be the patch below. I am not sure if INT13 succeeded 
is always the same as status == 0; there appears to be at least one corner 
case 11h == "data ECC corrected". 

The patch fixed the issue here.

regards

- -andrey

Subject: [PATCH] Fix EDD to properly ignore signature of non-existing drives

From: Andrey Borzenkov <arvidjaar@mail.ru>

Some BIOSes do not always set CF on error before return from int13.
The patch adds additional check for status being zero (AH == 0).

Signed-off-by: Andrey Borzenkov <arvidjaar@mail.ru>

- ---

 arch/i386/boot/edd.S |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/i386/boot/edd.S b/arch/i386/boot/edd.S
index d8d69f2..4b84ea2 100644
- --- a/arch/i386/boot/edd.S
+++ b/arch/i386/boot/edd.S
@@ -76,6 +76,8 @@ edd_mbr_sig_read:
 	popw	%es
 	popw	%bx
 	jc	edd_mbr_sig_done		# on failure, we're done.
+	cmpb	$0, %ah		# some BIOSes do not set CF
+	jne	edd_mbr_sig_done		# on failure, we're done.
 	movl	(EDDBUF+EDD_MBR_SIG_OFFSET), %eax # read sig out of the MBR
 	movl	%eax, (%bx)			# store success
 	incb	(EDD_MBR_SIG_NR_BUF)		# note that we stored something
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEAGkPR6LMutpd94wRAocYAJ4mRhgW0UOoK2+0bfQsh0+s1nUyIgCdGRrF
UCJpkIEPVEuUE2Gnfe7mG/Q=
=ij5i
-----END PGP SIGNATURE-----