(2015-09-07 12:05)soongin Wrote:  Hello, I'm trying to set up Windows 8.1 diskless PC environment by using iPXE, ietd on Ubuntu 12.04. Everything works fine except slow speed at Windows logo display stage.

(2015-09-07 12:49)mcb30 Wrote:  

(2015-09-07 12:05)soongin Wrote:  Hello, I'm trying to set up Windows 8.1 diskless PC environment by using iPXE, ietd on Ubuntu 12.04. Everything works fine except slow speed at Windows logo display stage.

How long does it take from the time that iPXE displays the "Booting from SAN device 0x80" message until the time that the Windows logo starts to fade in?

Michael

(2015-09-07 13:10)soongin Wrote:  One more thing, I changed iscsi target to LIO and built rom for 10ec8168(kpxe, kkpxe) but same result.

(2015-09-07 13:22)mcb30 Wrote:  Which iPXE binary are you using? The .kpxe and .kkpxe suffixes are for use only with the "undionly" driver.

Try using bin/realtek.pxe, and build without DEBUG=iscsi:3 (since that level of debug output will slow it down quite substantially, especially since you're using syslog debug).

If that is still slow, please capture a packet trace and upload it to cloudshark.org.

Thanks,

Michael

(2015-09-08 01:39)soongin Wrote:  I tried realtek.pxe(no debug level set) but same result. Since pcacp file is too big (about 10M)to upload to cloudshark, I zipped and linked at here

(2015-09-08 08:19)mcb30 Wrote:  

(2015-09-08 01:39)soongin Wrote:  I tried realtek.pxe(no debug level set) but same result. Since pcacp file is too big (about 10M)to upload to cloudshark, I zipped and linked at ** deleted **

Thanks. The packet capture is incomplete, since it shows only the packets sent by iPXE (and not the packets sent by the iSCSI target). Could you capture the whole sequence? You can limit the size by capturing only the packet headers, e.g.

Code:

tcpdump -s 128 -w sanboot.pcap -i eth0

Also, which version of iPXE are you using? (Type "show version" at the shell prompt if you aren't sure.)

Thanks,

Michael

(2015-09-08 09:32)soongin Wrote:  I recaptured ** deleted **

(2015-09-10 10:43)mcb30 Wrote:  The link seems to be broken. Could you repost the same capture file?

Also, could you check the link speed indicator on the switch during the iPXE stage? Is it showing a gigabit link?

Thanks,

Michael

(2015-09-10 20:53)soongin Wrote:  You can download at here.

Quote:Also, could you check the link speed indicator on the switch during the iPXE stage? Is it showing a gigabit link?

Quote:Also, could you check the link speed indicator on the switch during the iPXE stage? Is it showing a gigabit link?

(2015-09-13 05:55)soongin Wrote:  I checked and it shows orange led color. (both ipxe and gpxe are same.)

(2015-09-14 14:17)mcb30 Wrote:  Could you also please try the hack at http://fpaste.org/266946/, which will continue to poll the NIC for received packets even if the NIC's interrupt register reports that there are no new received packets.

(2015-09-14 14:17)mcb30 Wrote:  

(2015-09-13 05:55)soongin Wrote:  I checked and it shows orange led color. (both ipxe and gpxe are same.)

Thank you. I've checked the packet capture, and we are seeing ~12us between ACKs for full-sized frames, which does imply a 1Gbps link.

There are some odd-looking TCP retransmissions. These seem to always happen for the last packet transmitted by the server in a read request. Since it's always the last packet that gets dropped, fast retransmit doesn't happen and so nothing happens until the server's retransmission timer expires around 200ms later.

It's very suspicious that the drops seem to always affect the last packet in a request. If the link were bad, then we would expect all packets to be affected equally.

Is there anything else running on this machine which could potentially be accessing the network card (e.g. BIOS remote management or network console redirection)?

Could you also please try the hack at http://fpaste.org/266946/, which will continue to poll the NIC for received packets even if the NIC's interrupt register reports that there are no new received packets.

Thanks,

Michael

(2015-09-15 06:42)soongin Wrote:  

(2015-09-14 14:17)mcb30 Wrote:  Could you also please try the hack at http://fpaste.org/266946/, which will continue to poll the NIC for received packets even if the NIC's interrupt register reports that there are no new received packets.

I patched (just comment on 2 lines) and it boots up in 20 secs. No delay on Windows logo. Is this issue only affects to Realtek NIC?

(2015-09-15 14:52)nobluesky Wrote:  

Quote:Could you also please try the hack at http://fpaste.org/266946/, which will continue to poll the NIC for received packets even if the NIC's interrupt register reports that there are no new received packets.

I'd like to check your patch but it's expired. could you upload the patch again?

(2015-09-16 11:06)mcb30 Wrote:  OK, we have progress!

Do you know precisely which Realtek chip you have? You'll have to look at the number printed on the chip itself: the PCI device ID is not quite enough detail.

(2015-09-16 11:21)mcb30 Wrote:  

(2015-09-16 11:06)mcb30 Wrote:  OK, we have progress!

Do you know precisely which Realtek chip you have? You'll have to look at the number printed on the chip itself: the PCI device ID is not quite enough detail.

It would be good to know if this patch also fixes the problem:

Code:

--- a/src/drivers/net/realtek.c
+++ b/src/drivers/net/realtek.c
@@ -997,7 +997,7 @@ static void realtek_poll ( struct net_device *netdev ) {
                realtek_poll_tx ( netdev );

        /* Poll for RX completionsm, if applicable */
-       if ( isr & ( RTL_IRQ_RER | RTL_IRQ_ROK ) )
+       //      if ( isr & ( RTL_IRQ_RER | RTL_IRQ_ROK ) )
                realtek_poll_rx ( netdev );

        /* Check link state, if applicable */

i.e. commenting out the check for IRQ_RER|IRQ_ROK but leaving in place the "if(!isr) return;" near the start of realtek_poll().

If this patch does work to fix the problem, then it means that the chip is reporting some kind of interrupt that we need to add to the list in the IRQ_RER|IRQ_ROK line.

If this patch does not work to fix the problem, then it means that the chip is not reporting any interrupt, i.e. that the chip is broken.

Michael

(2015-09-18 05:40)soongin Wrote:  Sorry about late.
It's not possible to open up the pc case.
From the lshw, it says RTL 8111/8168/9411 PCI Express.
From the Windows device manager(in INF section), it says RTL8168G so I guess it's 8168 chipset.

Also I have interesting results from quick patch.
- w/o patch, it slows to display Windows logo(black screen after sanboot command) and result in slow boot. (boot over 1 min)
- by removing "if ( isr & ( RTL_IRQ_RER | RTL_IRQ_ROK ) )", fast to display windows logo but slow to fade out. (boot about 40 secs)
- by removing "if ( ! isr ) return;" and "if ( isr & ( RTL_IRQ_RER | RTL_IRQ_ROK ) )", fast to display and fast to fade out logo. (boot about 20 secs)