trap in netbind using R8169.OS2

[ecs273]

MB asus M5A 78L MLX. In addition to onboard nic I have 1gig Intel nic using your latest driver.

Works fine using this:
DEVICE=C:\IBMCOM\MACS\E1000E.OS2
DEVICE=C:\IBMCOM\MACS\R8110.OS2

Traps when using this:
DEVICE=C:\IBMCOM\MACS\E1000E.OS2
DEVICE=C:\IBMCOM\MACS\R8169.OS2 /V

From Pdump:
Current slot number: 000d

Slot Pid Ppid Csid Ord Sta Pri pTSD pPTDA pTCB Disp SG Name

*000d# 0004 0001 0004 0001 run 0300 f8c0c000 fe226020 f931114c 0f40 00 NETBIND

eax=00000081 ebx=00000049 ecx=00000000 edx=00000657 esi=000003f0 edi=000003f0
eip=00000158 esp=0000151e ebp=00001542 iopl=0 -- -- -- nv up ei pl zr na pe nc
cs=000f ss=001f ds=001f es=001f fs=150b gs=0000 cr2=00000000 cr3=00000000 p=00
000f:00000158 a11408 mov ax,word ptr [0814] ds:0814=0000
#

=========
Nic & driver details:

[C:\ibmcom\macs]bldlevel r8169.os2
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature: @#D Azarewicz:1.0.0#@##1## 16 Feb 2014 10:12:40 DAZAR1 :
:::0::SVN27@@Realtek 8169/1Gb PCIe MAC Driver
Vendor: D Azarewicz
Revision: 1.00.0
Date/Time?: 16 Feb 2014 10:12:40
Build Machine: DAZAR1
FixPak? Version: SVN27
File Version: 1.0
Description: Realtek 8169/1Gb PCIe MAC Driver

---

Bus 2 (PCI Express), Device Number 0, Device Function 0

Vendor 10ECh Realtek Semiconductor Co., Ltd.
Device 8168h RTL8111/8168B PCI Express Gigabit Ethernet controller
Command 0107h (I/O Access, Memory Access, BusMaster?, System Errors)
Status 0010h (Has Capabilities List, Fast Timing)
Revision 09h, Header Type 00h, Bus Latency Timer 00h
Self test 00h (Self test not supported)
Cache line size 64 Bytes (16 DWords)
PCI Class Network, type Ethernet
Subsystem ID 85051043h A6J-Q008 (Guess Only!)
Subsystem Vendor 1043h ASUSTeK Computer Inc.
Address 0 is an I/O Port : D800h..D8FFh
Address 1 is not present or not configured!
Address 2 is a Memory Address (64-bit, Prefetchable) : FDFFF000h
Address 4 is a Memory Address (64-bit, Prefetchable) : FDFF8000h
System IRQ 10, INT# A

===========

[C:\ibmcom\macs]bldlevel e1000e.os2
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature: @#D Azarewicz:0.2.5#@##1## 26 Jan 2014 21:49:21 DAZAR1 :
:::5::SVN266@@Intel PRO/1000 PCIe MAC Driver
Vendor: D Azarewicz
Revision: 0.02.5
Date/Time?: 26 Jan 2014 21:49:21
Build Machine: DAZAR1
FixPak? Version: SVN266
File Version: 0.2.5
Description: Intel PRO/1000 PCIe MAC Driver

---

Bus 3 (PCI Express), Device Number 0, Device Function 0
Vendor 8086h Intel Corporation
Device 10D3h 82574L Gigabit Network Connection
Command 0107h (I/O Access, Memory Access, BusMaster?, System Errors)
Status 0010h (Has Capabilities List, Fast Timing)
Revision 00h, Header Type 00h, Bus Latency Timer 00h
Self test 00h (Self test not supported)
Cache line size 64 Bytes (16 DWords)
PCI Class Network, type Ethernet
Subsystem ID A01F8086h Gigabit CT Desktop Adapter
Subsystem Vendor 8086h Intel Corporation
Address 0 is a Memory Address (0-4GiB) : FEBE0000h..FEBFFFFFh
Address 1 is a Memory Address (0-4GiB) : FEB00000h..FEB7FFFFh
Address 2 is an I/O Port : EC00h..EC1Fh
Address 3 is a Memory Address (0-4GiB) : FEBDC000h..FEBDFFFFh
System IRQ 11, INT# A

=======

Further info:
Realtek is onboard nic & assigned interface 1 - static IP.
Intel is PCIe assigned interface 0 - dhcp IP.
Even though I have set up the Realtek I have not plugged in a cable (this will be done when ready to replace old machine). I don't think this matters (and R8110 drivers doesn't trap w/ this setup) but thought it should be mentioned. The assigned IP for lan1 in setup.cmd is rem'd out.

bldlevel netbind:
Vendor: IBM
Revision: 60.58
Date/Time?: Fri May 21 14:12:49 2004
Build Machine: BWBLD254
ASD Feature ID:
FixPak? Version: WR_8708
File Version: 60.58
Description: Copyright (c) IBM, 2004

I tried the suggestions at the end of ticket #36 without success.

Rgds, jon

[David Azarewicz]

Problems with NETBIND can be caused by errors in PROTOCOL.INI, or by improper network setup in CONFIG.SYS. I suggest you check your PROTOCOL.INI. You can attach your PROTOCOL.INI to this ticket and I'll have a look at it.

Also you said you got a trap, but you didn't attach a picture of the trap screen.

[ecs273]

Thank you for these suggestions and information.

The 'trap' did not give me a screen and that is why there is not picture. It gave me 2 beeps and stopped the machine. My apologies if I am using the wrong terminology by calling it a trap. I waited about 5 minutes to make sure it was stopped. The pasted info above is from a pdump of that event.

I wondered about the command order in config.sys however I have placed R8169 in the same place where R8110 was located. I have not tried booting with it at the bottom of the config.sys which is where it gets placed when mpts is modified.

Apparently there is no backup of protocol.ini created when mtps is run. I'll have to reconfigure mpts, boot into the trap (to make sure it really traps again), and reboot to cmdline so I can copy it to another comment to follow.

Jon

[ecs273]

R8169 trap on bootup

[ecs273]

Nic Driver@ line 53, traps at line 54, and works at EOF

[ecs273]

Attached is protocol.ini and I am confident there are no errors in it. Or at least, it was created by mpts so there *should* be no errors.

This time I got a trap screen, it is attached. Don't know why it happened this time and not earlier.

Also, I am posting my config.sys because I now know that R8169 placement is important. The trap occurred when I placed the driver in the same physical location as the prior R8110 driver. However....booting with the driver placed as the last statement in the config.sys (where mpts writes it) then the boot completes successfully! And the lantran.log confirms bindings.

This brings another question. Given programs that sort the config.sys (mine was sorted during install) what would happen when a user sorts the config.sys and it moves R8169? I don't want to leave R8169 at it's current location but of course will, if necessary. If you can give me a suggestion based on my config.sys I'd appreciate it but also understand if you wish to decline that extra effort.

I must thank you for not only the suggestion in acpi ticket to update my usb stack - it improved my boot time by reducing it almost in half. And with R8169 replacing R8110, now that it works at the end of the config.sys, has reduced my boot time another significant amount. It's an amazing thing to experience an improvement from nearly 2 min to about 30 sec.

Thanks,
jon

[David Azarewicz]

No, the placement of the MAC drivers is not important. They just need to go after the protocol driver. I will have to look at the data to see what is going on.

[David Azarewicz]

Ok, I have completed my analysis. There is no defect in the R8169 driver. It seems that the order of things in the CONFIG.SYS is somewhat important. The MAC drivers must come after all protocol drivers and after all IFS drivers.