Re: 2.4.23-bk bogus edd changeset - Re: 2.4.23 compile error in edd

[Matt Domsch]

> 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
Documentation/i386/zero-page.txt.

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.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/