Hi Matt,
it seems the edd=off patch has caused some problems with
some machines I have access to. They simply don't boot
anymore unless I specify edd=foo. foo can be {off,skip,bar}
so it seems the hang on boot is related to the parser
not finding the parameter it is looking for.
I looked through the code some days ago and it seemed to
me that the register used to iterate through the command
line buffer only got its lower 16 bit reset before calling
into the BIOS. I don't have the code handy right now,
but I can look later if the hints I gave are insufficient.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
On Thu, Feb 10, 2005 at 03:11:52PM +0100, Carl-Daniel Hailfinger wrote:
> Hi Matt,
>
> it seems the edd=off patch has caused some problems with
> some machines I have access to. They simply don't boot
> anymore unless I specify edd=foo. foo can be {off,skip,bar}
> so it seems the hang on boot is related to the parser
> not finding the parameter it is looking for.
> I looked through the code some days ago and it seemed to
> me that the register used to iterate through the command
> line buffer only got its lower 16 bit reset before calling
> into the BIOS. I don't have the code handy right now,
> but I can look later if the hints I gave are insufficient.
Yes, please. I'm reading the code, and %ecx gets set to
(COMMAND_LINE_SIZE-7) which is 256-7=249. So the upper 24 bits of
%ecx are going to always be zero, and if "edd=" isn't seen, then %ecx
will be zero when dropping into edd_mbr_sig_start. The only other
register touched is %esi, but it's pushed at the beginning, and pop'd
on all exit cases, so that should be unchanged.
ZF is the only other bit I can picture. On the "no edd= option" path,
ZF=0 on exit. With "edd=of" or "edd=sk", ZF=1. But with "edd=bar",
ZF=0, which you say works too. So that's not it...
CF is taken care of around the int13 calls already, so that's not
it...
Thanks,
Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
Matt Domsch schrieb:
> On Thu, Feb 10, 2005 at 03:11:52PM +0100, Carl-Daniel Hailfinger wrote:
>
>>Hi Matt,
>>
>>it seems the edd=off patch has caused some problems with
>>some machines I have access to. They simply don't boot
>>anymore unless I specify edd=foo. foo can be {off,skip,bar}
>>so it seems the hang on boot is related to the parser
>>not finding the parameter it is looking for.
>>I looked through the code some days ago and it seemed to
>>me that the register used to iterate through the command
>>line buffer only got its lower 16 bit reset before calling
>>into the BIOS. I don't have the code handy right now,
>>but I can look later if the hints I gave are insufficient.
>
>
> Yes, please. I'm reading the code, and %ecx gets set to
> (COMMAND_LINE_SIZE-7) which is 256-7=249. So the upper 24 bits of
> %ecx are going to always be zero, and if "edd=" isn't seen, then %ecx
> will be zero when dropping into edd_mbr_sig_start. The only other
> register touched is %esi, but it's pushed at the beginning, and pop'd
> on all exit cases, so that should be unchanged.
>
> ZF is the only other bit I can picture. On the "no edd= option" path,
> ZF=0 on exit. With "edd=of" or "edd=sk", ZF=1. But with "edd=bar",
> ZF=0, which you say works too. So that's not it...
>
> CF is taken care of around the int13 calls already, so that's not
> it...
It all boils down to the question: When do the flags set by INCL
differ from those set by CMPW? We have already ruled out CF and ZF,
so only OF, SF, AF, PF can be the culprit.
Looking again, I think it will hang with edd=zz, but I have to verify
that.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/