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-----
prev parent 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.