i210 Intel Gigabit Card

[gharig]

Hi,

I am trying to get the intel Gigabit connection to work. I have loaded Tinycore 11.1 on to a Winsystems PC-104 card - C412 . It has a one fast ethernet port and one Intel I210 32-bit PCIe Gigabit Ethernet controller chip. The fast ethernet port works, I can ping and see data being transferred using Wireshark.

However the Gigabit port does not.   I have loaded the i2c-5.4.3-tinycore.tcz and i2c-tools.tcz
The output from the dmesg shows that the driver is loaded, it finds the card. But when Try to ping another machine I see an Warning entry in the dmesg

I have attached the full dmesg.
I also noticed an error:
         igb: Unknown symbol i2c_bit_add_bus (err -2)
Not sure if this is related.

Any help would be appreciated.

Thank you
gharig

Code: [Select]

------------[ cut here ]------------
NETDEV WATCHDOG: eth1 (igb): transmit queue 0 timed out
WARNING: CPU: 1 PID: 0 at 0xc05e717e
Modules linked in: cpufreq_conservative cpufreq_userspace cpufreq_powersave igb i2c_algo_bit squashfs zstd_decompress ptp pps_core serio_raw ac pcspkr r6040 loop
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.4.3-tinycore #2020
Hardware name: WinSystems, Inc. PPM-C412/PPM-C412, BIOS 41216246 08/01/18
EIP: 0xc05e717e
Code: 80 3d 10 bd 88 c0 00 75 30 89 f0 c6 05 10 bd 88 c0 01 e8 d1 2e fd ff 57 50 8d 83 58 fd ff ff 50 68 9d 99 7c c0 e8 ec fe b5 ff <0f> 0b 83 c4 10 eb 08 47 05 00 01 00 00 eb a7 8b 83 80 fe ff ff 8b
EAX: 00000037 EBX: f03862a8 ECX: 00000001 EDX: f1097e8c
ESI: f0386000 EDI: 00000000 EBP: f1097f6c ESP: f1097f4c
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00200296
CR0: 80050033 CR2: b7e7c794 CR3: 30367000 CR4: 00000690
Call Trace:
 <SOFTIRQ>
 ? 0xc05e70c1
 0xc018bf62
 0xc018c101
 ? 0xc05e70c1
 0xc018c140
 0xc06a70cd
 ? 0xc06a7030
 0xc01152e6
 </SOFTIRQ>
 ? 0xc014a422
 ? 0xc06a6e5a
 ? 0xc06a56fd
 ? 0xc06a39b8
 ? 0xc06a39c2
 ? 0xc06a0068
 ? 0xc06a39c2
 ? 0xc011ac39
 ? 0xc06a3b21
 ? 0xc0162724
 ? 0xc0162678
 ? 0xc0162934
 ? 0xc0133d7a
 ? 0xc0100224
---[ end trace 780411748bea9e6d ]---
igb 0000:01:00.0 eth1: Reset adapter
igb 0000:01:00.0 eth1: igb: eth1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
igb 0000:01:00.0 eth1: Reset adapter
igb 0000:01:00.0 eth1: igb: eth1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
igb 0000:01:00.0 eth1: Reset adapter
igb 0000:01:00.0 eth1: igb: eth1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
igb 0000:01:00.0 eth1: Reset adapter
igb 0000:01:00.0 eth1: igb: eth1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
    [EDIT]: Added code tags.  Rich

[curaga]

This one "igb: Unknown symbol i2c_bit_add_bus (err -2)" was solved by you loading the i2c extension, as the following lines show igb was later loaded fine. The warning and resets point to a bug in the driver. Please try TC 12.

[Rich]

Hi gharig
Please use  Code Tags  when posting commands and responses seen in a terminal. To use  Code Tags  click on the  #  icon
above the reply box and paste your text between the  Code Tags  as shown in this example:

[code][   36.176529] pcm512x 1-004d: Failed to get supply 'AVDD': -517
[   36.176536] pcm512x 1-004d: Failed to get supplies: -517
[   36.191753] pcm512x 1-004d: Failed to get supply 'AVDD': -517[/code]

It will appear like this in your post:

Code: [Select]

[   36.176529] pcm512x 1-004d: Failed to get supply 'AVDD': -517
[   36.176536] pcm512x 1-004d: Failed to get supplies: -517
[   36.191753] pcm512x 1-004d: Failed to get supply 'AVDD': -517
Code Tags  serve as visual markers between what you are trying to say and the information you are posting. They also preserve
spacing so column aligned data displays properly. Code tags also automatically add horizontal and or vertical scrollbars
to accommodate long lines and listings.

[gharig]

Thank you very much curaga, I will try TC 12 and get back to you with the results.

And Sorry Rich, I will use code tags next time...


Thanks for for such a great product......

~Best
gharig

[gharig]

Hello Tinycore,

So I'm still having problems getting my Intel I210 PCIe Controller Chip to work, and what I mean by work is to have it reply to a ping.

I did as curaga suggested, I upgraded from TC-11.1 to TC-12.0. 
The nice thing about TC-12.0 is that it recognized the two Ethernet cards with out loading the i2c-KERNEL.tcz, basicallyit noticed it right away. 
The second thing I notices is the the error "igb: Unknown symbol i2c_bit_add_bus (err -2)" in dmesg no longer appeared. 
How ever I'm not able to ping to or from the second nic card, and when I try to ping out from the TC-12.0 machine, I notice that every ping causes a Reset Adapter message to be entered into dmesg, as shown in the code below #DMESG RESULTS#.

My setup is very simple, I loaded TC-12.0 and assigned the network as follows, actually I used the network tool that come built in to with Tinycore to setup the network, (very cool)....

Code: [Select]

eth0 to ipaddress 192.198.200.6 netmask 255.255.0.0
 eth1 to ipaddress 10.10.9.10 netmask 255.255.255.0

Now on my laptop running windows 10 which has an ipaddress of 10.10.9.12 and plugged into the switch.
I'm also running Wireshark to see if I could capture anything.
I also ran an Arp -a command on the windows10 to make sure that there was no entry for 10.10.9.10(TC-12.0 eth1) in the arp tables.

After pining the windows10 laptop form the TC-12.0 machine, I notice that the dmesg has a Watchdog Entry and an Adapter Reset Entry. In fact every time I try to ping I notice a new Adapter Reset Entry in dmesg.
On the windows10 machine which is running Wireshark I notice two Arp Messages, the first on is from 10.10.9.10(TC-12.0 eth1) with a destination 10.10.9.12(Windows10) with a who is message,
and the second message is from  10.10.9.12(Windows10) to 10.10.9.10(TC-12.0 eth1) giving the mac address of the windows10 machine. 
Now after doing another Arp -a command on the windows10 machine a see an entry in the arp table for 10.10.9.10 the TC-12.0 machine.

When I go to the TC-12.0 machine and run the arp -a command I do not see any entry from the windows10 machine for eth1.

So because Wireshark and and the arp table entry on the windos10 machine, I have to come to the conclusion that the TC-12.0 did successfully send the arp message, however it did not receive a reply, now is this because of a Adapter reset???

Is there something special I must do to get it working?

Is there some process you would like me to run for further troubleshooting?

Any and all help is appreciated.

Also Incase it could be the switch, I replaced the cisco switch with an HP switch and had the same results..




#DMESG RESULTS#

Code: [Select]

------------[ cut here ]------------
NETDEV WATCHDOG: eth1 (igb): transmit queue 0 timed out
WARNING: CPU: 0 PID: 0 at 0xc0630552
Modules linked in: cpufreq_userspace cpufreq_conservative cpufreq_powersave igb ac ptp pps_core pcspkr serio_raw r6040 squashfs loop
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.3-tinycore #2021
Hardware name: WinSystems, Inc. PPM-C412/PPM-C412, BIOS 41216246 08/01/18
EIP: 0xc0630552
Code: 3d 96 e7 96 c0 00 75 31 8b 45 f0 c6 05 96 e7 96 c0 01 e8 46 22 fd ff 56 50 8d 83 58 fd ff ff 50 68 2c db 83 c0 e8 a3 6e 0c 00 <0f> 0b 83 c4 10 eb 08 46 05 00 01 00 00 eb a9 8b 83 7c fe ff ff 89
EAX: 00000037 EBX: f6b3a2a8 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: ffffba40 EBP: c1015f70 ESP: c1015f50
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00200296
CR0: 80050033 CR2: 08ecddb4 CR3: 0199b000 CR4: 00000690
Call Trace:
 <SOFTIRQ>
 ? 0xc063049a
 0xc018f089
 0xc018f678
 ? 0xc063049a
 ? 0xc018a582
 0xc018f6ac
 0xc0708af3
 ? 0xc0708a58
 0xc011690e
 </SOFTIRQ>
 ? 0xc014ae4d
 ? 0xc014b08b
 ? 0xc07031f0
 ? 0xc07086cc
 ? 0xc01600d8
 ? 0xc07031c8
 ? 0xc070741e
 ? 0xc01600d8
 ? 0xc07031c8
 ? 0xc070741e
 ? 0xc04219c5
 ? 0xc0421946
 ? 0xc05b9f41
 ? 0xc05ba0c7
 ? 0xc016395f
 ? 0xc0163ab1
 ? 0xc0703c39
 ? 0xc09826fe
 ? 0xc0982acc
 ? 0xc098220c
 ? 0xc01001e4
---[ end trace 2119e3d4def84d0b ]---
igb 0000:01:00.0 eth1: Reset adapter
igb 0000:01:00.0 eth1: igb: eth1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
igb 0000:01:00.0 eth1: Reset adapter
igb 0000:01:00.0 eth1: igb: eth1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
igb 0000:01:00.0 eth1: Reset adapter
igb 0000:01:00.0 eth1: igb: eth1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
usb 1-3: new high-speed USB device number 5 using ehci-pci


[curaga]

We can't really help any more, nor is there much you can do. It appears the driver for your card is still buggy in TC 12's kernel version.

You could try newer kernels yourself (building them manually) and if it still happens in latest, report the bug upstream.

[Rich]

Hi gharig
Just a shot in the dark:

Add the following boot codes to your boot loader:

Code: [Select]

module_blacklist=igb blacklist=igbReboot your machine.

Make sure  i2c-5.10.3-tinycore  is installed:

Code: [Select]

tce-status -i | grep i2c-5.10.3-tinycoreThat command will return nothing if  i2c-5.10.3-tinycore  is not installed.

Load the  igb  driver:

Code: [Select]

sudo modprobe igb debug=16
Initialize the network card

Code: [Select]

sudo pkill udhcpc

Code: [Select]

sudo ifconfig eth1 10.10.9.10 netmask 255.255.255.0 broadcast 10.10.9.255 up
See whether or not it works now. Either way, attach another  dmesg.txt  to your next post. The driver might now print
out some useful debugging messages.

[gharig]

Hi Every One,

So I did as Rich Suggested, I blacklisted the igb module on boot, loaded the i2c-KERNEL.tcz for TC12.0.
After blacklisting I was not able to load the igb module as tc user nor as root.  Not sure if blacklisting a module cause it to never be loaded?
So I removed the blacklisting from the boot codes. When Tinycore booted, I then unloaded the igb module using

Code: [Select]

modprobe -r igb
Then I manually loaded the i2c-KERNEL.tcz using the App tool for local tcz (love that tool).
Then loaded the igb module in debug mode.

Code: [Select]

modprobe  igb debug=16
Similar results from before after trying to ping on eth1. Just so you know eth0 has no problem.

Attached are the documents, one when the system boots up and one with the error.

So the hardware I'm using is Winsystems C412, datasheets can be found at https://www.winsystems.com/product/ppm-c412/.

So then I am now questioning the hardware, so I come up with a brilliant idea, I will load another linux OS and test. So I load Lubuntu 16.04, and I was hoping for failure, but it worked. And believe me the last thing I want is to use lubuntu, its bloated and runs very slow and takes for ever to boot up on the Winsystems C412 hardware. 

So I noticed a couple of things, first is that lubuntu 16.04 uses linux kernel 4.4 (i think). Next I noticed that the one of the modules that loaded was i2c_algo_bit and that it was dependent on igb module (or vice versa).

So my next thought is that I would go load an older version of Tinycore.
I loaded Tinycore 10.0 with the same results as Tinycore 12.0 and Tinycore 11.1

I loaded Tinycore 9.0, still failed but I believe  I noticed that it had the i2c_algo_bit module loaded too.
So I figure I would try to load even an older version, Tinycore 8 and 7.2, But I'm having problem getting them loaded at the moment.

Curaga has stated that maybe I should try to rebuild with a newer version of the igb module from Intel. 
I found found version igb-5.5.2.tar.gz. Is that version later that the one Tinycore 12.0 uses? I was not able to see the igb version when I did a

Code: [Select]

modinfo igb.

Anyway I think that your product is really great, It boots very fast, and all the other digital IO and serial communication I have done so far work great.
Just this one small glitch. 

I have also attached the results of modinfo of both Tinycore Lubuntu, along with a lubuntu dmesg result. Not sure if it is helpful?

The other thing is that I would switch hardware but I have a lot of these C412 cards to use.

Thanks
gharig

[Rich]

Hi gharig
Try adding the following 2 boot codes:

Code: [Select]

pci=nomsi pci=pcie_scan_allRemove the  blacklist  boot codes.

Also, since you are still trying to troubleshoot the same interface, there's no reason to keep starting new threads.

[Rich]

Hi gharig
I merged your 3  i210 Intel Gigabit Card  threads.

[gharig]

Hi Rich,

Thanks for merging the threads, and yes I'm trying to troubleshoot the same network interface, its the i210 Intel PCIe Network Controller Chip on the Winsystems C412.  I will try your suggestion over the weekend and get back to you.

Thanks
gharig

[gharig]

Hi Rich,

You are a pure genius.......

After putting in those boot codes it started pinging, and there are no errors in the dmesg as before.

Now what you guys need here is a tip bucket.  Yes How do I give money to the cause.

I will do more testing next week to make sure everything is good to go.

Thank you so very very much.
gharig

[Rich]

Hi gharig

You are a pure genius.......

Oh I wouldn't go that far. You provided the answer with the Lubuntu dmesg listing.

This caught my eye in Lubuntu:

igb 0000:01:00.0: Using legacy interrupts. 1 rx queue(s), 1 tx queue(s)

Compared to the Tinycore version:

igb 0000:01:00.0: Using MSI-X interrupts. 2 rx queue(s), 2 tx queue(s)
 ----- Snip -----
NETDEV WATCHDOG: eth1 (igb): transmit queue 0 timed out

Checking the  Kernel command line  in the Lubuntu dmesg listing revealed this:

Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.4.6 root=UUID=769cdaa5-e3c0-4dde-89bd-fe5e76a113d0 ro quiet splash pci=nomsi pci=pcie_scan_all vt.handoff=7

[curaga]

https://sourceforge.net/p/e1000/bugs/689/

Upstream is asking about bios settings. @gharig, if you have a SF account, please post there.