Supported NIC chipsets?

[Davesworld]

I know that a ppp_async problem that caused my pppd during bittorent upload, to crash the kernel has been fixed. I submitted that patch and the usbserial patch that made it's way into IPCop 1.4.18. That is now a part of the 2.4.36 kernel. Orange crashes red during torrent upload? Regardless of which kind of Red connection?

BTW, the flashrom in a Cobalt as of current rom, lies to the system about how much memory the system can have, it really has 16MB less ram available than your system thinks it has. A new flashrom is right around the corner that fixes a lot of issues as well as allows booting from a usb drive. This will greatly simplify installation. It is also based on the 2.6.20 kernel. Basically, it will extend the useful life of a Raq for years to come.

[ceelight]

Hi Dave, in the german forum you ask me about the type of Dual-NIC I'm running in my Raq4i. Here's what wintermutes sysinfo tells me about:

Code:

02:04.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 05)
        Class 0200: 8086:1229 (rev 05)
Subsystem: 0e11:b01f
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (2000ns min  14000ns max)  cache line size 08
Interrupt: pin A routed to IRQ 9
Region 0: Memory at f7eef000 (32-bit  prefetchable) [size=4K]
Region 1: I/O ports at ffc0 [size=32]
Region 2: Memory at feb00000 (32-bit  non-prefetchable) [size=1M]
Expansion ROM at <unassigned> [disabled] [size=1M]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+ D1+ D2+ D3hot+ D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

02:05.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 05)
        Class 0200: 8086:1229 (rev 05)
Subsystem: 0e11:b01f
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (2000ns min  14000ns max)  cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at f7eee000 (32-bit  prefetchable) [size=4K]
Region 1: I/O ports at ffa0 [size=32]
Region 2: Memory at fea00000 (32-bit  non-prefetchable) [size=1M]
Expansion ROM at <unassigned> [disabled] [size=1M]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+ D1+ D2+ D3hot+ D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Any idea?

As you know, I've updated to 1.4.20 with your patches and to 1.4.21 with the original file. Above you mentioned:

I know that a ppp_async problem that caused my pppd during bittorent upload, to crash the kernel has been fixed. I submitted that patch and the usbserial patch that made it's way into IPCop 1.4.18. That is now a part of the 2.4.36 kernel.

This fix, could it maybe help? Well, I'll see. I'll give it a "stress test" again and will let you know.

[Davesworld]

The ppp_async fix is native to the 2.4.36 kernel but the problem it fixed was that the whole kernel would crash under certain kinds of ppp traffic which varied by situation. In my case, it would crash doing torrent uploads with an Option GT Max and the Nozomi driver compiled into IPCop. I was not using a Cobalt back then. When I went to the Novatel XU870 and started using the usbserial driver, it would crash in certain irc chatrooms so I started using the ppp_async patch again and that problem went away and my move to the Cobalt didn't change any of that at all. Now I'm on DSL but it's dhcp dsl

The card you have looks quite similar to the dual nics I have here.

[ceelight]

The ppp_async fix is native to the 2.4.36 kernel but the problem it fixed was that the whole kernel would crash under certain kinds of ppp traffic which varied by situation. In my case, it would crash doing torrent uploads with an Option GT Max and the Nozomi driver compiled into IPCop. I was not using a Cobalt back then. When I went to the Novatel XU870 and started using the usbserial driver, it would crash in certain irc chatrooms so I started using the ppp_async patch again and that problem went away and my move to the Cobalt didn't change any of that at all. Now I'm on DSL but it's dhcp dsl

The card you have looks quite similar to the dual nics I have here.

OK, I'm writing this with productive Raqcop now. All Interfaces (red, green, orange and blue) are connected and on orange (one port of the Dual NIC) is traffic since my last post. No crash. If you need some logs, let me know...

The only thing I did was to update to 1.4.21 so it seems that the kernel patched you mentioned was the point. Let's see what the (cop)time brings. I've seen the daveworld Raqcop in the list. 

Thanks a lot for your efforts! Again - great job.

The next days I'll get a small 19" rack where my RaQ1/2/4 will have their new home. When everything is sorted I'll make some pics for the ipcop-forum.de gallery.

[lleo19]

As I was reading through this thread realized that I have exactly the same symptoms.
I have been using IPCop on my raq prior to RaQCop times and never had a problem.
Then when kernel was updated from 2.4.31 to 2.4.34, something has changed in that high traffic locks up the PCI nic. As for all this time I always had my GREEN zone on the PCI nic, when it locked up, my only choice was to restart the machine from the serial console. From this thread got the idea to move the zones around and test the lock-ups.
It always locks up the PCI nic, thus I loose traffic to and from that zone, however, others that go through the e100 ports on the RAQ keep working fine.

I tested the following configurations:

RED+GREEN+ORANGE with Intel PRO 1000MT where each of the three zones were assigned to be on the e1000 nic. After some time ranging from minutes to hours traffic to and from the zone that was actually on the e1000 nic was locked up. The nic was not pingable from even the serial console.

RED+GREEN+ORANGE+BLUE with Intel PRO Dual 1000MT where one by one each zone was assigned to the one of two e1000 ports, again with random lock-ups under traffic.

My RED connects to DSL modem via PPPOE, and this may be just a coincidence or part of the problem.

The RAQ and nics are working fine as if I start my IPCop 1.4.12 install it runs stable for months, and steady dial-up connection as well, so I do not think it is a power-issue.

Not sure if this should be reported as an IPCop bug, but without any error message or sign of error, it may be hard to find a solution.
It will be also a showstopper for me at least as I need more than just two ports, unless it is fixed soon.
Cheers, Lorant

[ceelight]

Sorry lleo19, I can't help you, but I have to come back with my problem here.

Dave,
It's kind of jinxed. I can't get it working and I'm working with IPCop since more then 5 years now. But I have to admit, that I'm not such a big hardware guru...  After my last post the raqcop was working during the next night and then crashed again. The I switched it of and wait some weeks. This weekend I decided to change red from one of the dual-NIC-ports to eth1 (onboard NIC). Then my pppoe connection was quite stable. Tonight at 2:00am the connection crashed and the connectioncheck script tried to reconnect. Without success. At 4:30 Olafs ConnScheduler-AddOn also tried to reconnect. "Cannot connect when red is still active..." The only way was a reboot to bring the network up and running. After the reboot the connection stand until - and now the nice part - I want to access the WebGUI. In that moment the ppp0 is down. 

I finally decided to leave it for now. If you need any logs or anything else, let me know, I will provide that. But I'm a bit frustrated

[Davesworld]

As I was reading through this thread realized that I have exactly the same symptoms.
I have been using IPCop on my raq prior to RaQCop times and never had a problem.
Then when kernel was updated from 2.4.31 to 2.4.34, something has changed in that high traffic locks up the PCI nic. As for all this time I always had my GREEN zone on the PCI nic, when it locked up, my only choice was to restart the machine from the serial console. From this thread got the idea to move the zones around and test the lock-ups.
It always locks up the PCI nic, thus I loose traffic to and from that zone, however, others that go through the e100 ports on the RAQ keep working fine.

I tested the following configurations:

RED+GREEN+ORANGE with Intel PRO 1000MT where each of the three zones were assigned to be on the e1000 nic. After some time ranging from minutes to hours traffic to and from the zone that was actually on the e1000 nic was locked up. The nic was not pingable from even the serial console.

RED+GREEN+ORANGE+BLUE with Intel PRO Dual 1000MT where one by one each zone was assigned to the one of two e1000 ports, again with random lock-ups under traffic.

My RED connects to DSL modem via PPPOE, and this may be just a coincidence or part of the problem.

The RAQ and nics are working fine as if I start my IPCop 1.4.12 install it runs stable for months, and steady dial-up connection as well, so I do not think it is a power-issue.

Not sure if this should be reported as an IPCop bug, but without any error message or sign of error, it may be hard to find a solution.
It will be also a showstopper for me at least as I need more than just two ports, unless it is fixed soon.
Cheers, Lorant

I definitely recognize your name. Weren't you the one who originally ran IPCop on Raqs and showed others how to do it? I use Gmane like a news server and have the entire ipcop-devel mailing list usable as if it were a newsgroup and saw some activity back in 2006. I could have saved myself some work if I had done this back when I started. I found the 2.4 kernel patch for Cobalt and did it on my own and wound up in the same place except that I have spent some time with the lcd part of it.

There are other kernel issues that were created in the 2.4.35 as far as breaking the ability to compile the kernel with no keyboard and VT support. I have a patch from Willy to try on the 2.4.36 kernel but I wound up regression patching the keyboard driver to restore the ability to compile for a headless device. If his patch works he will merge upstream but I really don't see IPCop 1.4.x going to a newer kernel anytime soon.

A Cobalt also does not need a buttload of ide drivers embedded in the kernel nor a floppy driver so I pruned out a bunch. Networking drivers I did not touch except the e100 patch which I know you used as well and I made a patch for the 3.5.17 e100 driver which is renamed to e100new in IPCop to ignore the checksum but that driver behaves much like the e1000 driver you describe, even with the onboard 82559er chips.  Gilles recommended I file a bug report to the Sourceforge e1000/e100 project but I'm not sure there is any kind of dump to send them much like you mentioned.

Did this problem occur when you did your own Cobalt installs once the IPCop kernel was upgraded to 2.4.34?

[Davesworld]

Sorry lleo19, I can't help you, but I have to come back with my problem here.

Dave,
It's kind of jinxed. I can't get it working and I'm working with IPCop since more then 5 years now. But I have to admit, that I'm not such a big hardware guru...  After my last post the raqcop was working during the next night and then crashed again. The I switched it of and wait some weeks. This weekend I decided to change red from one of the dual-NIC-ports to eth1 (onboard NIC). Then my pppoe connection was quite stable. Tonight at 2:00am the connection crashed and the connectioncheck script tried to reconnect. Without success. At 4:30 Olafs ConnScheduler-AddOn also tried to reconnect. "Cannot connect when red is still active..." The only way was a reboot to bring the network up and running. After the reboot the connection stand until - and now the nice part - I want to access the WebGUI. In that moment the ppp0 is down. 

I finally decided to leave it for now. If you need any logs or anything else, let me know, I will provide that. But I'm a bit frustrated

Sorry about your frustration. I'm curious as to what impact the new 2.6 kernel based rom will have on some of this. I came to find out that the Cobalt roms actually do not release the full amount of ram to the machine once it hands off to OUR kernel but lies about it. It's somewhere around 22MB that is really not available. I know the person who is fixing the rom errors finally and adding the ability to boot from a usb drive mainly for ease of installation. The two current methods, drive swapping and nfs installs are not practical even if you make a Cobalt style bootable cd which still requires a supported nic and a machine to be taken down. Not everyone has an nfs server handy either. He (Chris) is working on an automated rom upgrade to the new rom as well where I think you plug a usb stick in a running Cobalt and it does it's thing, then you have the new rom to boot from usb installs. This should extend the life of these blue units for years to come.

[ceelight]

OK, after moving to our new house I also changed my provider. I've got a 32MBit cable-connection now. So red is DHCP and I gave Raqcop another chance with same config as above (dual-NIC) and new installation (10GB image). I've got red-green-blue-orange, but blue and orange are not active by now.

Well, it works!


I need some advice by getting new fans for the RaQ4. The ones I have are really damaged I think. Strange sound. What would shipping to Germany cost me if I would order them in your online store?