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

[Muralidhar.Appalla at Emulex.Com]

Michael,

Yes, our device supports IRQ. This information that is populated from UNDI is directly read from PCI Configuration space and populated. But we do not enable interrupts in our UNDI stack but rather do polling. Our OS drivers definitely use this IRQ. 

The statement to check whether IRQ is zero seems to me also very safe to do.


Thanks
Murali

-----Original Message-----
From: Michael Brown [mailto:mbrown at fensystems.co.uk] 
Sent: Thursday, March 10, 2011 2:17 PM
To: jerrycheng-hinet; Appalla, Muralidhar
Cc: ipxe-devel at ipxe.org
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