Thanks, Michael,
I will try to enable the CONSOLE_SYSLOG option and capture the debug
messages over the network. I will give you a update while successfully
capture the syslog. Thanks very much!
Regards,
Jerry
----- Original Message -----
From: "Michael Brown" <[email protected]>
To: "jerrycheng-hinet" <[email protected]>;
<[email protected]>
Cc: <[email protected]>
Sent: Friday, March 11, 2011 6:16 AM
Subject: Re: [ipxe-devel] SAN Boot Windows XP with USB-NIC.
On Thursday 10 Mar 2011 16:53:31 jerrycheng-hinet wrote:
>> Could you build with DEBUG=undinet and tell me what is shown for the
>> lines
>>
>> UNDINIC 0x<address> has type <type>, speed <speed>, flags <flags>
>> UNDINIC 0x<address> uses IRQ <irq>
I found the following 3 lines in red:
UNDINIC using UNDI 0xc0a59078
UNDINIC 0x17990 is 00:50:fc:8e:c7:8d on IRQ 11
UNDINIC 0x17990 has type DIX+802.3, speed 10000000, flags 0000cc1b
Thanks for that. It seems as though your NIC is reporting IRQ 11 but is
definitely *not* setting the IRQ_SUPPORTED bit in the flags.
Muralidhar: I applied a patch a while ago to fix interoperability with
Emulex
NICs, which (along with several others) don't provide UNDI interrupts.
What
does the Emulex stack provide as an IRQ number (via
PXENV_UNDI_GET_INFORMATION)?
I'm wondering if we can safely change the logic in undinet.c to
effectively be
undinic->irq_supported = ( ( undi_iface.ServiceFlags & SUPPORTED_IRQ ) ||
( undi_indo.IntNumber !=
0 ) );
i.e. assume that the NIC supports interrupts if *either* the ServiceFlags
indicate SUPPORTED_IRQ *or* the IRQ number is non-zero.
>> That message must be coming from NTLDR rather than iPXE. Could you
>> try
>> building with DEBUG=int13, so we can see what is happening?
There are a few lines of hex dump after "Registerd as BIOS drive
0x80/Booting from BIOS drive 0x80". Because the screen scrolled too fast,
I
can't get message of the hex dump.
I can only see the final 2 lines showed "Booting from SAN device 0x80/INT
13 drive 80 booting" after the hex dump.
As of yesterday, you can enable syslog debugging in iPXE, which will let
you
capture these messages over the network rather than via a serial port.
Simply
enable CONSOLE_SYSLOG in config/console.h, and configure the DHCP server
to hand
out a syslog server address. For example:
option log-servers 192.168.0.1;
You also need to ensure that your syslog daemon is configured to accept
messages from remote hosts. On many systems, this is done by editing
/etc/sysconfig/syslog and adding the option "-r" to the syslogd command
line.
I originally think it should be the similiar issue like "booting windows
xp
from USB device". After a few days of work, following the instructions of
http://www.ngine.de/article/id/8, I can successfully boot windows xp via
USB flash drive.
Then, I try to install all of the NB drivers to the flash drive, install
"MS iscsi initiator" and "sanboot" to the flash drive, use flash drive
to
make a image file, and used ipxe to sanboot this image file. However,
the
result remained the same. The screen hanged at "Couldn't open drive
multi(0)disk(0)rdisk(0)partition(1)/NTLDR couldn't open drive
multi(0)disk(0)rdisk(0)partition(1)".
Could you please give me some suggestion about the next step? Thanks in
advance!
I think the DEBUG=int13 output is going to be essential. Since you don't
have
a viable null-modem cable setup, could you try the CONSOLE_SYSLOG option
as
described above?
Thanks,
Michael
_______________________________________________
ipxe-devel mailing list
[email protected]
https://lists.ipxe.org/mailman/listinfo/ipxe-devel
