All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrey Borzenkov <arvidjaar@mail.ru>
To: Matt Domsch <Matt_Domsch@dell.com>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: "Ghost" devices in /sys/firmware/edd
Date: Sat, 25 Feb 2006 17:26:21 +0300	[thread overview]
Message-ID: <200602251726.23500.arvidjaar@mail.ru> (raw)
In-Reply-To: <20060225050745.GA4796@lists.us.dell.com>

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

      reply	other threads:[~2006-02-25 14:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-24 19:14 "Ghost" devices in /sys/firmware/edd Andrey Borzenkov
2006-02-25  5:07 ` Matt Domsch
2006-02-25 14:26   ` Andrey Borzenkov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200602251726.23500.arvidjaar@mail.ru \
    --to=arvidjaar@mail.ru \
    --cc=Matt_Domsch@dell.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.