archive mirror
 help / color / mirror / Atom feed
From: Matt Domsch <>
To: Anton Altaparmakov <>
Cc: Marcelo Tosatti <>,
	LKML <>
Subject: Re: 2.4.23-bk bogus edd changeset - Re: 2.4.23 compile error in edd
Date: Wed, 10 Dec 2003 14:48:42 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <1070987393.3447.64.camel@imp>; from on Tue, Dec 09, 2003 at 04:29:53PM +0000

> The ds segment is not pointing to the correct segment AND/OR the offsets
> into the segment used for the writes are bogus.  You write straight into
> ds and ds:si referenced memory but you never setup ds in the first
> place.  So the writes done by the EDD code corrupt the loaded compressed
> kernel and the decompression fails.

ds is set up already to point at the empty_zero_page, else none of
what I'm doing is correct.  But, it is very likely that something else
is using 0x228 in empty_zero_page but isn't marked as using it in

You've been patient, and thorough.  As another test, could you change
include/asm-i386/edd.h: DISK80_SIG_BUFFER from 0x228 to 0x2cc (the
four bytes immediately before the e820 memory buffer), and see if that
helps?  If so, I'll submit a patch to use that instead, and another
that markes 0x228 as in use by something else.

> I haven't really spent time thinking about ds and offsets and what they
> should be set to but I hope I have given you enough information to fix
> this yourself.  (-:

I'm quite certain that ds is correct, but that 0x228 may be in use by
something else.
> Please also note that you may want to consider adding this around your
> first int 0x13 call (the one to read the MBR):
> movb	$READ_SECTORS, %ah
> [snip]
> pushw	%dx		# work around buggy BIOSes
> stc			# work around buggy BIOSes
> int	$0x13
> sti			# work around buggy BIOSes
> popw	%dx
> This is what Microsoft uses apparently to work around various buggy BIOS
> implementations - ref: Ralf Brown's Interrupt list 61, which I consider
> the ultimate and definite guide to interrupts. (-:

OK, I'll look into that too.
> Further, at the Getdeviceparameters int 0x13 call, you may want to zero
> the two bytes following the EDDPARMSIZE in %ds:(%si) before doing the
> interrupt as your own company's PhoneixBIOS 4.0 Release 6.0 machines
> didn't work unless this was the case (ref: Ralf Brown's Interrupt list
> 61).

Ahh, yes.  I read that now.  OK, no harm in doing so, I'll add that.
> Finally, would it not be prudent to check the result of
> checkextensionspresent int 0x13 call before doing the
> getdeviceparameters int 0x13 call?  For example this would do just that:
> [snip]
> movw	%cx, %ds:-2(%si)		# store extensions
> [snip]                                                                                        testw	$7, %cx				# Is Function 48 supported?
> jz	edd_skip_getdevparms		# If not, skip the call...
> movb	$GETDEVICEPARAMETERS, %ah	# Function 48
> int	$0x13				# make the call
> 					# Don't check for fail return
> 					# it doesn't matter.
> edd_skip_getdevparms:

So, I thought about this for a while when I first wrote the code.  I
haven't run across *any* BIOSses yet which didn't implement function
48 for at least some version of EDD; it may not be version 0x30, but we've got
space reserved for it up to the size 0x30 could return, so it doesn't
matter.  If it returns anything in function 41, then it will return
something in function 48 too.  I could be wrong I suppose, but none of
the BIOS reports I've seen suggest otherwise.


Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions
Linux on Dell mailing lists @

  reply	other threads:[~2003-12-10 20:49 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-04 14:20 2.4.23 compile error in edd Meelis Roos
2003-12-04 14:58 ` Meelis Roos
2003-12-04 22:31 ` 2.4.23-bk bogus edd changeset - " Anton Altaparmakov
2003-12-05 15:52   ` Marcelo Tosatti
2003-12-05 17:36     ` Matt Domsch
2003-12-05 18:53       ` Matt Domsch
2003-12-05 19:07         ` Matt Domsch
2003-12-08 16:34       ` Anton Altaparmakov
2003-12-09  4:23         ` Matt Domsch
2003-12-09 16:29           ` Anton Altaparmakov
2003-12-10 20:48             ` Matt Domsch [this message]
2003-12-15 19:52               ` Anton Altaparmakov
2003-12-18 11:32       ` Meelis Roos
2003-12-18 14:02         ` Matt Domsch
2003-12-19 11:05           ` Meelis Roos
2003-12-19 14:49             ` Matt Domsch

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:

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

  git send-email \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).