Hi,
I have written a COM32 program which pxelinux loads it and executes when
machine is booted over network. And the COM32 program should be blocked
till it receives an instruction from deployment server in UDP packet.

I am looking for a network interrupt that will make my machine to wait for
an incoming udp packet, so that my server can send udp packet. Upon receiving the udp packet, the target machine should be able to reboot.

I have a issue with HLT instruction which is embedded inside the 'C' language in COM32 program. It looks like this. .
                  int main()
                  {
                              for(;;)
                            {
                                    asm volatile("hlt");
                                    recv packet and execute instruction that is part of UDP packet.
                            }
                            return 0;
                  }
I am executing this instruction to make the machine to halt. but this is not working.


could you please help me out with this issue?
Any help on this issue will be highly appreciated.

thank you,
Madhusudan M I
Posted on 2011-09-20 07:20:37 by Madhu
The hlt instruction only halts the CPU temporarily. Only until the next event (usually an interrupt) is triggered. On a modern system, lots of interrupts will occur, so a hlt never lasts long.
See here:
http://siyobik.info/main/reference/instruction/HLT

You shouldn't use it yourself, as there is no need. It is also not a legal instruction for regular applications, as it is a privileged instruction (You will probably get a general protection fault).
The idle thread of the OS will issue hlt instructions.
You just need to design your code so that it will become idle when waiting.
In this case, just calling a blocking recv() is enough. Inside recv(), the OS will set your thread into a waiting state, and remove it from the active scheduling list (so it is idle, idle thread gets scheduled instead, and issues hlt instructions for you).
Once something comes in on the socket belonging to your thread, the OS will wake your thread back up, and your program will continue after the recv() call.
That is what blocking calls do, in a nutshell.
Posted on 2011-09-20 08:04:01 by Scali
Thanks. I will try this out. If any issue,  I will get back to you.

Thank you,

Madhusudan M I
Posted on 2011-09-21 01:49:25 by Madhu
Hi,

1. Is there any way to wait for a network interrupt to occur in real mode? As our COM32 program is booted over network by pxelinux.

2. How  COM32 program becomes idle in real mode when waiting?  Is it through some synchronous/asynchronous interrupt such as waiting for a key store to be pressed or through NIC interrupt?

3. If there is no means of waiting for a NIC interrupt, is there any alternative way of finding NIC interrupts after HLT state is pushed out i.e. Check if NIC interrupt occurred after HLT state.?

any help on this will be highly appreciated.

Thank you,

Madhusudan M I
Posted on 2011-09-21 02:13:56 by Madhu
I don't know enough about your environment to answer the questions in detail.
I can say this though:
Interrupts are basically always asynchronous. Whenever an interrupt occurs, the current code is...well...interrupted, and the interrupt handler is invoked. After the interrupt is handled, the current code will resume. You never know when such an interrupt occurs, until it does.
In the most basic environment, you could simply create only an 'idle thread' as the current code (just a loop with hlt), and put the actual handling of the network traffic in the interrupt handler for the network card.
(That's pretty much how a basic OS works anyway... you start with just an idle thread, and a timer to periodically swap threads around. This timer also generates interrupts, so everything is done on interrupt-basis).

However, since you apparently already have some kind of environment with a network driver and a way to read packets, at least some of this is already done for you.
I mainly wonder though: why does it matter to you so much? It's just for a bit of bootup code, isn't it? Shouldn't be a big deal. Most POST/BIOS code doesn't make use of hlt either, so CPUs generally don't go into power saving modes until the OS kernel is initialized. Since this is generally only a matter of seconds, nobody cares.
Posted on 2011-09-21 02:50:00 by Scali