[ipxe-devel] SAN Boot Windows XP with USB-NIC.

jerrycheng-hinet jaspers.cheng at msa.hinet.net
Fri Mar 11 18:03:57 UTC 2011


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" <mbrown at fensystems.co.uk>
To: "jerrycheng-hinet" <jaspers.cheng at msa.hinet.net>; 
<Muralidhar.Appalla at emulex.com>
Cc: <ipxe-devel at ipxe.org>
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 




More information about the ipxe-devel mailing list