Issue with Intel UNDI, PXE-2.1 (build 083) @ Realtek PCIe GBE v2.31 @ Asus P7H55-M LX

[Santana]

When using undionly.kpxe, my machine gets stuck at this point:

Code:

Intel UNDI, PXE-2.1 (build 083)
Copyright (C) 1997-2000  Intel Corporation

This product is covered by one or more of the following patents:
US5,307,459, US5,434,872, US5,732,094, US6,570,884, US6,115,776 and
US6,327,625

Realtek PCIe GBE Family Controller Series v2.31 (10/12/09)

CLIENT MAC ADDR: BC AE C5 8F 89 E2  GUID: E05BD17A-8DFE-D511-9C9A-BCAEC58F89E2
CLIENT IP: 10.0.0.10  MASK: 255.255.0.0  DHCP IP: 10.0.0.1
GATEWAY IP: 10.0.0.1



PXE->EB: !PXE at 9B3A:0070, entry point at 9B3A:0109
         UNDI code segment 9B3A:2C5C, data segment 8D6C:DCE0 (565-632kB)
         UNDI devide is PCI 01:00.0, type DIX+802.3
         565kB free base memory after PXE unload
iPXE initialising devices...

All I can do at this point is hitting the reset or power button. Keyboard is dead.

Using ipxe.pxe instead works:

Code:

PXE->EB: !PXE at 9B3A:0070, entry point at 9B3A:0109
         UNDI code segment 9B3A:2C5C, data segment 8D6C:DCE0 (565-632kB)
         UNDI device is PCI 01:00.0, type DIX+802.3
         632kB free base memory after PXE unload
iPXE initialising devices...ok



iPXE 1.0.0+ -- Open Source Network Boot Firmware -- http://ipxe.org
Features: HTTP HTTPS iSCSI DNS TFTP AoE SRP bzImage ELF MBOOT PXE PXEXT Menu

Is this a known issue? Is this an issue at all?

Many thanks in advance for any hints!

[mcb30]

(2014-06-16 14:01)Santana Wrote:  When using undionly.kpxe, my machine gets stuck at this point:

Code:

PXE->EB: !PXE at 9B3A:0070, entry point at 9B3A:0109
         UNDI code segment 9B3A:2C5C, data segment 8D6C:DCE0 (565-632kB)
         UNDI devide is PCI 01:00.0, type DIX+802.3
         565kB free base memory after PXE unload
iPXE initialising devices...

All I can do at this point is hitting the reset or power button. Keyboard is dead.

Could you try building with DEBUG=undinet and let us know what messages appear?

Thanks,

Michael

[Santana]

(2014-06-17 11:48)mcb30 Wrote:  Could you try building with DEBUG=undinet and let us know what messages appear?

Here we go:

Code:

iPXE initialising devices...UNDINIC 0x19ef4 using UNDI 0x871b65d4

[mcb30]

(2014-06-17 15:02)Santana Wrote:  Here we go:

Code:

iPXE initialising devices...UNDINIC 0x19ef4 using UNDI 0x871b65d4

Thanks. That's getting stuck very early in the sequence.

Could you try using undionly.kkpxe instead of undionly.kpxe? This will bypass some of the shutdown and reinitialisation calls, which might make a difference.

Michael

[Santana]

(2014-06-17 15:38)mcb30 Wrote:  Could you try using undionly.kkpxe instead of undionly.kpxe? This will bypass some of the shutdown and reinitialisation calls, which might make a difference.

I tried and everything works fine with unidonly.kkpxe:

Code:

PXE->EB: !PXE at 9B3A:0070, entry point at 9B3A:0109
         UNDI code segment 9B3A:2C5C, data segment 8D6C:DCE0 (565-632kB)
         UNDI device is PCI 01:00.0, type DIX+802.3
         525kB free base memory after PXE unload
iPXE initialising devices...UNDINIC 0x19ef4 using UNDI 0x871b65d4
UNDINIC 0x19ef4 has MAC address bc:ae:c5:8f:89:e2 and IRQ 5
UNDINIC 0x19ef4 has type DIX+802.3, speed 10000000, flags 00001c1b
UNDINIC 0x19ef4 using interrupt mode
UNDINIC 0x19ef4 added
ok



iPXE 1.0.0+ (1639) -- Open Source Network Boot Firmware -- http://ipxe.org

I've got several of these boards and all show the same behavior.

Thank you for your time and efforts!

[Santana]

Anything else I could try to make it work with undionly.kpxe?
To me it seems like a bug in the hardware/firmware but PXE is all about dealing with buggy hardware/firmware, isn't it. Would love to the help finding a workaround.

[mcb30]

(2014-06-18 16:44)Santana Wrote:  Anything else I could try to make it work with undionly.kpxe?
To me it seems like a bug in the hardware/firmware but PXE is all about dealing with buggy hardware/firmware, isn't it. Would love to the help finding a workaround.

If you're happy hacking C code, you could try adding some extra DBG() statements to undinet_probe() in arch/i386/drivers/net/undinet.c to find out whether it's PXENV_START_UNDI, PXENV_UNDI_INITIALIZE, or PXENV_UNDI_GET_INFORMATION which is locking up.

There will be some people who can help out in our IRC channel (#ipxe on Freenode), if you want to talk in real time.

Michael

[mastacontrola]

Hi everybody,

One again we (the FOG Community) are having similar issues, particularly dealing with Realtek 8111/8168, and one particular case is specific to the version 2.45 firmware.

I will run through some more of my debugging, so long as the person that's having this issue is free to test, and report back any findings I may come up with as well.

Thanks you for the great product overall though!

[cottsay]

I have reproduced this same behavior. Hang with undionly.kpxe, works with undionly.kkpxe.

I have traced this through undinet to the call to profile_start [1] during the call pxeparent_call for PXENV_UNDI_STARTUP (I believe).

I tried hopping back many commits [2] to before the gcc workarounds, and I get the same behavior.

I just updated the BIOS on the machine for good measure, as well.

Let me know what I can do to help resolve this.

--scott

[1] https://git.ipxe.org/ipxe.git/blob/HEAD:...ent.c#l224
[2] https://git.ipxe.org/ipxe.git/commit/37c...e998f66c6a

[robinsmidsrod]

cottsay: Did you try disabling the profiling code paths to see if that made any difference?

[cottsay]

I disabled profiling and looked a little bit closer, and it is actually the asm code right after the profile_start [1].

Profiling has nothing to do with it.

I was also wrong when I said that I had the same behavior before the gcc workarounds...the compilation fails there. I must have missed the error.

However, I can rewind to just where the gcc workarounds were introduced [2], and I DO get the same behavior there.

[1] https://git.ipxe.org/ipxe.git/blob/HEAD:...ent.c#l225
[2] https://git.ipxe.org/ipxe.git/commit/cba...3925687af0

[Richard_Compal]

I also find an issue with Realtek PCIe GBE v2.6 with unidonly.kpxe/undionly.kkpxe, when i run DHCP, it got error message"Configuring (net0 d0:bf:9c:63:a1:b1).............. Error 0x040ee119"

[harryc]

A new update to an old problem. Machine details below.

When using ipxe.ipxe and undionly.kpxe sanbooting windows takes over an hour. Seemingly randomly it can take 'only' about ten minutes.
However, using 10ec8168.kpxe it takes around 3 minutes. Variables uninitialized before use?

More interesting is: When windows does finally boot and the vendor provided net driver takes over: Full speed and normal operations occur.

Notice that the routine realtek_detect makes no use of the pci device id, rather it writes and then reads back device control registers trying to deduce the info the vendor, product and rev info already makes clear. My guess is these read/write cycles set reserved bits on chips not designed to have them written, leading them into the weeds, or possibly corrupting device data structures such as bytes/transfer or latency settings.

There was observations on other threads that the device line speed was corrupted by this driver leading to 10 mb operations. I don't see that here, at least to the extent the switch reports a steady line speed of 1GB/s

FYI at https://pci-ids.ucw.cz/read/PC/10ec/8168 we have:
The exact name depends on the revision ID. The rev id + name are shown below:
01 8168B (driver known as 8168)
02 8168C
03 8168D
04 8168DP
06 8168E
07 8168F (same driver as 8168E?), succesors: 0B 0C 0D 0E 0F 10
08 8168ES
09 8168FB (same driver as 8168E?)
0A 8411 (same driver as 8168E?)

Source: Netrtle.inf from a Realtek PCIe LAN driver at http://download.gigabyte.eu/FileList/Dri...k_8111.exe

And: RTL8111GR has same 10ec:8168 but its revision is 11
Source is lspci and eyes (chip name is also written in motherboard specification)
sudo lspci -nnkvv -s 03:00.0
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 11)
Subsystem: ASUSTeK Computer Inc. Device [1043:859e]

The machine, an old: Gigabyte Technology Co., Ltd. P35-DQ6/P35-DQ6, BIOS F9 06/22/2009
with an onboard: 04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 01)
Subsystem: Gigabyte Technology Co., Ltd Motherboard [1458:e000]
Flags: bus master, fast devsel, latency 0, IRQ 45
I/O ports at c000 [size=256]
Memory at f0000000 (64-bit, non-prefetchable) [size=4K]
[virtual] Expansion ROM at f8400000 [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Capabilities: [48] Vital Product Data
Capabilities: [50] MSI: Enable+ Count=1/2 Maskable- 64bit+
Capabilities: [60] Express Endpoint, MSI 00
Capabilities: [84] Vendor Specific Information: Len=4c <?>
Capabilities: [100] Advanced Error Reporting
Capabilities: [12c] Virtual Channel
Capabilities: [148] Device Serial Number 25-00-00-00-10-ec-81-68
Capabilities: [154] Power Budgeting <?>
Kernel driver in use: r8169

[MultimediaMan]

I've been booting to pxelinux.0 (v4.02) then booting ipxe.pxe as a workaround. This workaround requires a (tedious) DHCP reservation, and a full MAC entry under pxelinux.cfg in the tftp directory.