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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox