Mailing List Archive

I now see that
Int 22h AX=15h Get feature flags

defines bit 0 as:
Local boot (AX=0014h) supported

This seems to indicate that this localboot API function is not supported
on some systems.

I am in the process of having this tested on the Dell 1435.

Q: Why is it that a "modern" system would not support this?

Q: Is there an alternate mechanism/workaround for localbooting from the
hard disk?

I suppose I could load in the MBR and fire off the boot process manually,
using AX=0012h, but I was trying to use localboot AX=0014h in order to
avoid having to do that work ...

Q: Is there a library call to boot from disk 0x81?

.OR.

Q: Is there sample code that shows the steps I would need to go through to
do this?


Thanks,
Miguel

> I have a Dell 1435 system that will not respond correctly to a com32 call
> to Local boot
>
> Int 22h
> AX=14h
> DX = 0
>
> This call should not return. It should unload the PXE+UNDI stacks and
> continue the boot process with the next boot device.
>
> This call is working fine for me on an HP DL360G2 and on a Dell PE 850.
>
> But, on this Dell 1435 the call is returning from the Int 22h.
>
> I am using syslinux 3.51
>
> Q: Any suggestions?
>
> Q: Is there any info/data that I can collect that will help identify what
> is causing this problem?
>
> Thanks in advance,
> Miguel
>
>
>
>
>
>
> _______________________________________________
> SYSLINUX mailing list
> Submissions to SYSLINUX@zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
> Please do not send private replies to mailing list traffic.
>
>



_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Miguel wrote:
> I have a Dell 1435 system that will not respond correctly to a com32 call
> to Local boot
>
> Int 22h
> AX=14h
> DX = 0
>
> This call should not return. It should unload the PXE+UNDI stacks and
> continue the boot process with the next boot device.
>
> This call is working fine for me on an HP DL360G2 and on a Dell PE 850.
>
> But, on this Dell 1435 the call is returning from the Int 22h.
>
> I am using syslinux 3.51
>
> Q: Any suggestions?
>
> Q: Is there any info/data that I can collect that will help identify what
> is causing this problem?

Start by trying the latest version, 3.54.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

>> But, on this Dell 1435 the call is returning from the Int 22h.
>>
>> I am using syslinux 3.51
>>
>> Q: Any suggestions?
>>
>> Q: Is there any info/data that I can collect that will help identify
>> what
>> is causing this problem?
>
> Start by trying the latest version, 3.54.

Upgrade to 3.54 did not solve the problem ... same behavior ... Dell 1435
still returns from Int 22h AX=0014.

I'll try to collect more data.


Miguel

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

Miguel wrote:
>>> But, on this Dell 1435 the call is returning from the Int 22h.
>>>
>>> I am using syslinux 3.51
>>>
>>> Q: Any suggestions?
>>>
>>> Q: Is there any info/data that I can collect that will help identify
>>> what
>>> is causing this problem?
>> Start by trying the latest version, 3.54.
>
> Upgrade to 3.54 did not solve the problem ... same behavior ... Dell 1435
> still returns from Int 22h AX=0014.
>
> I'll try to collect more data.
>

That is very odd indeed. The code to do it shouldn't even have a way to
return... I traced through the execution and there doesn't seem any
possibility. It would be useful to know what values are returned by
INT 22h, AX=000Ah.

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

>> Upgrade to 3.54 did not solve the problem ...
>> same behavior ... Dell 1435
>> still returns from Int 22h AX=0014.
>> I'll try to collect more data.
>
> That is very odd indeed.

Agreed

> The code to do it shouldn't even have a way to
> return... I traced through the execution and there
> doesn't seem any possibility. It would be useful to
> know what values are returned by INT 22h, AX=000Ah.

In addition to AX=000Ah, I also did AX=0015h.

I have attached a screen shot ... don't know if it will make it to the
mailing list.

Int22h AX=000Ah -> AL=32h DX=0201h

Int22h AX=0015h -> CX=0000h :

Note that the flag byte count is 0 ... based upon comboot.doc I expected a
value of 1.

To make things more confuzing/puzzling, if I put 'localboot 0' in the
pxelinux.cfg/MACADDR file then it successfully exits and boots from the
local hard drive.

I took a look at the code in com32/modules/menumain.c ... which looks like
the code that processes pxelinux.cfg/MACADDR files. I observe that it
calls Int22h AX=0014h, exactly as I am doing. It works from the boot:
prompt but does not work from my code ... very strange.

Screen shot is attached.
Source code is below.

Miguel

----


void syslinux_localboot(int localboottype) {
static com32sys_t regs;
int i;

for (i = 0; i < 25; ++i) // clear screen
printf("\n");
printf("initiating localboot\n");

localboottype = localboottype; // stop complaining about unused variable

memset(&regs, 0, sizeof regs);
regs.eax.w[0] = 0x000A;
__intcall(0x22, &regs, &regs);
printf("Int22h AX=000Ah -> AL=%02Xh DX=%04Xh\n\n",
regs.eax.b[0], regs.edx.w[0]);

memset(&regs, 0, sizeof regs);
regs.eax.w[0] = 0x0015;
__intcall(0x22, &regs, &regs);
printf("Int22h AX=0015h -> CX=%04Xh :", regs.ecx.w[0]);
{
unsigned count = regs.ecx.w[0];
unsigned char * flags_ptr = MK_PTR(regs.es, regs.ebx.w[0]);
unsigned i;
for (i = 0; i < count; ++i)
printf(" %02Xh", flags_ptr[i]);
printf("\n\n");
}


memset(&regs, 0, sizeof regs);
regs.eax.w[0] = 0x0014;
regs.edx.w[0] = (unsigned short) localboottype;
printf("calling Int22h AX=%04Xh DX=%04Xh\n\n",
regs.eax.w[0], regs.edx.w[0]);
__intcall(0x22, &regs, NULL);

// alternate method ... but requires the label 'localboot' in the
// pxelinux.cfg file
//
// char * bounce = __com32.cs_bounce;
// strcpy(bounce, "localboot");
//
// regs.eax.w[0] = 0x0003;
// regs.es = SEG(bounce);
// regs.ebx.w[0] = OFFS(bounce);
// __intcall(0x22, &regs, NULL);

printf("Why am I here?\n");
syslinux_sleep(5);
exit(0);
}

Miguel wrote:
>>> Upgrade to 3.54 did not solve the problem ...
>>> same behavior ... Dell 1435
>>> still returns from Int 22h AX=0014.
>>> I'll try to collect more data.
>> That is very odd indeed.
>
> Agreed
>
>> The code to do it shouldn't even have a way to
>> return... I traced through the execution and there
>> doesn't seem any possibility. It would be useful to
>> know what values are returned by INT 22h, AX=000Ah.
>
> In addition to AX=000Ah, I also did AX=0015h.
>
> I have attached a screen shot ... don't know if it will make it to the
> mailing list.
>
> Int22h AX=000Ah -> AL=32h DX=0201h
>

What about the other information, especially FS:SI?

-hpa

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.

>>> Upgrade to 3.54 did not solve the problem ...
>>> same behavior ... Dell 1435
>>> still returns from Int 22h AX=0014.
>>> I'll try to collect more data.
>>
>> That is very odd indeed.
>
> Agreed

Just to bring some closure to this issue ...

This problem was completely mine.

While I successfully upgraded to syslinux-3.54 in my development
environment, I failed to upgrade pxelinux.0 on the QA test system where
this machine was failing to localboot. This outdated pxelinux.0 on that
system did not support the Int22h AX=0014h localboot API.

I came to this embarrassing realization as HPA was making debugging
recommendations via IRC.

Summary: When upgrading syslinux versions, remember that pxelinux.0 in
your deployment environment must be upgraded along with your com32
programs.


Miguel

_______________________________________________
SYSLINUX mailing list
Submissions to SYSLINUX@zytor.com
Unsubscribe or set options at:
http://www.zytor.com/mailman/listinfo/syslinux
Please do not send private replies to mailing list traffic.