eepro100 kernel freeze / ISDN

eepro100 kernel freeze / ISDN

[Michael Klose]

Correction:

> In 2.4.15pre5 (in my opinion one of the most stable 2.4 kernels I have tested) it "only" crashed after transferring about 2-3 GB of data via 
> my laptop SMB share over the 100MBit switch to the linux server. 2.4.17 crashes after 100-200 GB of data transfer.


That should read: 2.4.17 crashes after about 100-200 MB - megabytes or 
mibibytes or whatever you call them now whereas 2.4.15pre5 only crashed 
after half a handful of gigabytes.

eepro100 kernel freeze / ISDN

[Michael Klose]

I know there have been mails on this in this list before, the last I 
heard was a month ago and I saw many fixes going into recent kernels.

My contribution is just to say that the problem has gotten worse.

In 2.4.15pre5 (in my opinion one of the most stable 2.4 kernels I have 
tested) it "only" crashed after transferring about 2-3 GB of data via my 
laptop SMB share over the 100MBit switch to the linux server.
2.4.17 crashes after 100-200 GB of data transfer.

By crash I mean total freeze. Nothing in the logs at all. Only a reset 
or poweroff will help.
The server is running on a dual Pentium II BX board (only one PII 266 in 
it though) with 256MB RAM. Also, SMP support is currently NOT compiled in.

I have two intel eepro100 cards in there.

(2.4.17 kernel output)

Jan  4 17:27:34 linux kernel: eth0: OEM i82557/i82558 10/100 Ethernet, 
00:50:8B:04:6F:CD, IRQ 12.
Jan  4 17:27:34 linux kernel:   Receiver lock-up bug exists -- enabling 
work-around.
Jan  4 17:27:34 linux kernel:   Board assembly 702536-008, Physical 
connectors present: RJ45
Jan  4 17:27:34 linux kernel:   Primary interface chip i82555 PHY #1.
Jan  4 17:27:34 linux kernel:   General self-test: passed.
Jan  4 17:27:34 linux kernel:   Serial sub-system self-test: passed.
Jan  4 17:27:34 linux kernel:   Internal registers self-test: passed.
Jan  4 17:27:34 linux kernel:   ROM checksum self-test: passed (0x24c9f043).
Jan  4 17:27:34 linux kernel:   Receiver lock-up workaround activated.
Jan  4 17:27:34 linux kernel: PCI: Found IRQ 10 for device 00:12.0
Jan  4 17:27:34 linux kernel: eth1: Intel Corp. 82557 [Ethernet Pro 100] 
(#2), 00:A0:C9:B5:0C:E6, IRQ 10.
Jan  4 17:27:34 linux kernel:   Receiver lock-up bug exists -- enabling 
work-around.
Jan  4 17:27:34 linux kernel:   Board assembly 682704-002, Physical 
connectors present: RJ45
Jan  4 17:27:34 linux kernel:   Primary interface chip i82555 PHY #1.
Jan  4 17:27:34 linux kernel:   General self-test: passed.
Jan  4 17:27:35 linux kernel:   Serial sub-system self-test: passed.
Jan  4 17:27:35 linux kernel:   Internal registers self-test: passed.
Jan  4 17:27:35 linux kernel:   ROM checksum self-test: passed Jan  4 
17:26:20 linux fsck: reiserfsprogs 3.x.0j
Jan  4 17:27:35 linux kernel:   Receiver lock-up workaround activated.

In between rc.sysinit was running, setting up the clock, atd and 
starting to check filesystems, but I took out those bits of the log.

eth0 is connected to the 100MBit switch which connects to the LAN.
eth1 is just connected to a DSL modem (10 MBit link).

I have tried switching around the cards, doesn't work.

Apart from that the system runs stable. A two day run of constantly 
compiling kernels while copying several gigabytes between hard disks 
over and over again at the same time did not seem to crash it.

It crashed immediately though as soon as you have HIGH network traffic. 
By that I mean copying several hundred Megabyte to the server. As soon 
as you do this, it crashes every time.

On 2.4.15pre5 it required a lot more data to be transferred to be 
crashed, usually in the 1-2 gigabyte range.

I have an unrelated problem with an ISDN card USR sportster in the 
latest release. It no longer works. It has been working happily for 
years on a 2.0.36 until I upgraded to the new server. It has been 
running fine sinde 2.4.5 (I didn't try earlier kernels on that machine) 
and it still worked fine in 2.4.15pre5. I am not much interested in ISDN 
anymore since I have DSL since a week now. I just wanted to mention it:

Jan  4 17:12:06 linux kernel: ISDN subsystem Rev: 
1.1.4.1/1.1.4.1/1.1.4.1/1.1.4.1/none/1.1.4.1 loaded
Jan  4 17:12:06 linux kernel: HiSax: Linux Driver for passive ISDN cards
Jan  4 17:12:06 linux kernel: HiSax: Version 3.5 (module)
Jan  4 17:12:06 linux kernel: HiSax: Layer1 Revision 1.1.4.1
Jan  4 17:12:06 linux kernel: HiSax: Layer2 Revision 1.1.4.1
Jan  4 17:12:06 linux kernel: HiSax: TeiMgr Revision 1.1.4.1
Jan  4 17:12:06 linux kernel: HiSax: Layer3 Revision 1.1.4.1
Jan  4 17:12:06 linux kernel: HiSax: LinkLayer Revision 1.1.4.1
Jan  4 17:12:06 linux kernel: HiSax: Approval certification failed 
because of
Jan  4 17:12:06 linux kernel: HiSax: unauthorized source code changes
Jan  4 17:12:06 linux kernel: HiSax: Card 1 Protocol EDSS1 Id=HiSax (0)
Jan  4 17:12:06 linux kernel: HiSax: USR Sportster driver Rev. 1.1.4.1
Jan  4 17:12:06 linux kernel: HiSax: USR Sportster config irq:10 cfg:0x258
Jan  4 17:12:06 linux kernel: Sportster: ISAC version (0): 2086/2186 V1.1
Jan  4 17:12:06 linux kernel: Sportster: HSCX version A: V2.1  B: V2.1
Jan  4 17:12:06 linux kernel: USR Sportster: IRQ 10 count 0
Jan  4 17:12:06 linux kernel: USR Sportster: IRQ 10 count 0
Jan  4 17:12:06 linux kernel: USR Sportster: IRQ(10) getting no 
interrupts during init 1
Jan  4 17:12:06 linux kernel: USR Sportster: IRQ 10 count 0
Jan  4 17:12:06 linux isdn: Loading ISDN modules succeeded
Jan  4 17:12:06 linux kernel: USR Sportster: IRQ(10) getting no 
interrupts during init 2
Jan  4 17:12:06 linux kernel: USR Sportster: IRQ 10 count 0
Jan  4 17:12:06 linux kernel: USR Sportster: IRQ(10) getting no 
interrupts during init 3
Jan  4 17:12:06 linux kernel: HiSax: Card USR Sportster not installed !


If the ISDN thing is a RTFM  thing that I just need to upograde some 
userland tools, then don't worry about it. I no longer need it so I 
doidn't put much research into it. It was just working fine till the new 
driver version came in in 2.4.17.

I am concerned about the eepro issue. I normally love intel network 
cards, they are damn fast and give excellent throughput on Windows NT 
servers and Windows desktop machines. But constantly crashing my server 
is not a good thing.

Re: eepro100 kernel freeze / ISDN

[Ben Greear]

The problem is probably the eepro connected to the 10bt device.  10bt
seems to lock things up much more often than a 100bt network connection.

Unfortunately, the only work-around I found for this problem so far
is to change the hardware to a non intel NIC, or to use the e100 module
from Intel...

Ben

Michael Klose wrote:

> I know there have been mails on this in this list before, the last I 
> heard was a month ago and I saw many fixes going into recent kernels.
> 
> My contribution is just to say that the problem has gotten worse.
> 
> In 2.4.15pre5 (in my opinion one of the most stable 2.4 kernels I have 
> tested) it "only" crashed after transferring about 2-3 GB of data via my 
> laptop SMB share over the 100MBit switch to the linux server.
> 2.4.17 crashes after 100-200 GB of data transfer.
> 
> By crash I mean total freeze. Nothing in the logs at all. Only a reset 
> or poweroff will help.
> The server is running on a dual Pentium II BX board (only one PII 266 in 
> it though) with 256MB RAM. Also, SMP support is currently NOT compiled in.
> 
> I have two intel eepro100 cards in there.
> 
> (2.4.17 kernel output)
> 
> Jan  4 17:27:34 linux kernel: eth0: OEM i82557/i82558 10/100 Ethernet, 
> 00:50:8B:04:6F:CD, IRQ 12.
> Jan  4 17:27:34 linux kernel:   Receiver lock-up bug exists -- enabling 
> work-around.
> Jan  4 17:27:34 linux kernel:   Board assembly 702536-008, Physical 
> connectors present: RJ45
> Jan  4 17:27:34 linux kernel:   Primary interface chip i82555 PHY #1.
> Jan  4 17:27:34 linux kernel:   General self-test: passed.
> Jan  4 17:27:34 linux kernel:   Serial sub-system self-test: passed.
> Jan  4 17:27:34 linux kernel:   Internal registers self-test: passed.
> Jan  4 17:27:34 linux kernel:   ROM checksum self-test: passed 
> (0x24c9f043).
> Jan  4 17:27:34 linux kernel:   Receiver lock-up workaround activated.
> Jan  4 17:27:34 linux kernel: PCI: Found IRQ 10 for device 00:12.0
> Jan  4 17:27:34 linux kernel: eth1: Intel Corp. 82557 [Ethernet Pro 100] 
> (#2), 00:A0:C9:B5:0C:E6, IRQ 10.
> Jan  4 17:27:34 linux kernel:   Receiver lock-up bug exists -- enabling 
> work-around.
> Jan  4 17:27:34 linux kernel:   Board assembly 682704-002, Physical 
> connectors present: RJ45
> Jan  4 17:27:34 linux kernel:   Primary interface chip i82555 PHY #1.
> Jan  4 17:27:34 linux kernel:   General self-test: passed.
> Jan  4 17:27:35 linux kernel:   Serial sub-system self-test: passed.
> Jan  4 17:27:35 linux kernel:   Internal registers self-test: passed.
> Jan  4 17:27:35 linux kernel:   ROM checksum self-test: passed Jan  4 
> 17:26:20 linux fsck: reiserfsprogs 3.x.0j
> Jan  4 17:27:35 linux kernel:   Receiver lock-up workaround activated.
> 
> In between rc.sysinit was running, setting up the clock, atd and 
> starting to check filesystems, but I took out those bits of the log.
> 
> eth0 is connected to the 100MBit switch which connects to the LAN.
> eth1 is just connected to a DSL modem (10 MBit link).
> 
> I have tried switching around the cards, doesn't work.
> 
> Apart from that the system runs stable. A two day run of constantly 
> compiling kernels while copying several gigabytes between hard disks 
> over and over again at the same time did not seem to crash it.
> 
> It crashed immediately though as soon as you have HIGH network traffic. 
> By that I mean copying several hundred Megabyte to the server. As soon 
> as you do this, it crashes every time.
> 
> On 2.4.15pre5 it required a lot more data to be transferred to be 
> crashed, usually in the 1-2 gigabyte range.
> 
> I have an unrelated problem with an ISDN card USR sportster in the 
> latest release. It no longer works. It has been working happily for 
> years on a 2.0.36 until I upgraded to the new server. It has been 
> running fine sinde 2.4.5 (I didn't try earlier kernels on that machine) 
> and it still worked fine in 2.4.15pre5. I am not much interested in ISDN 
> anymore since I have DSL since a week now. I just wanted to mention it:
> 
> Jan  4 17:12:06 linux kernel: ISDN subsystem Rev: 
> 1.1.4.1/1.1.4.1/1.1.4.1/1.1.4.1/none/1.1.4.1 loaded
> Jan  4 17:12:06 linux kernel: HiSax: Linux Driver for passive ISDN cards
> Jan  4 17:12:06 linux kernel: HiSax: Version 3.5 (module)
> Jan  4 17:12:06 linux kernel: HiSax: Layer1 Revision 1.1.4.1
> Jan  4 17:12:06 linux kernel: HiSax: Layer2 Revision 1.1.4.1
> Jan  4 17:12:06 linux kernel: HiSax: TeiMgr Revision 1.1.4.1
> Jan  4 17:12:06 linux kernel: HiSax: Layer3 Revision 1.1.4.1
> Jan  4 17:12:06 linux kernel: HiSax: LinkLayer Revision 1.1.4.1
> Jan  4 17:12:06 linux kernel: HiSax: Approval certification failed 
> because of
> Jan  4 17:12:06 linux kernel: HiSax: unauthorized source code changes
> Jan  4 17:12:06 linux kernel: HiSax: Card 1 Protocol EDSS1 Id=HiSax (0)
> Jan  4 17:12:06 linux kernel: HiSax: USR Sportster driver Rev. 1.1.4.1
> Jan  4 17:12:06 linux kernel: HiSax: USR Sportster config irq:10 cfg:0x258
> Jan  4 17:12:06 linux kernel: Sportster: ISAC version (0): 2086/2186 V1.1
> Jan  4 17:12:06 linux kernel: Sportster: HSCX version A: V2.1  B: V2.1
> Jan  4 17:12:06 linux kernel: USR Sportster: IRQ 10 count 0
> Jan  4 17:12:06 linux kernel: USR Sportster: IRQ 10 count 0
> Jan  4 17:12:06 linux kernel: USR Sportster: IRQ(10) getting no 
> interrupts during init 1
> Jan  4 17:12:06 linux kernel: USR Sportster: IRQ 10 count 0
> Jan  4 17:12:06 linux isdn: Loading ISDN modules succeeded
> Jan  4 17:12:06 linux kernel: USR Sportster: IRQ(10) getting no 
> interrupts during init 2
> Jan  4 17:12:06 linux kernel: USR Sportster: IRQ 10 count 0
> Jan  4 17:12:06 linux kernel: USR Sportster: IRQ(10) getting no 
> interrupts during init 3
> Jan  4 17:12:06 linux kernel: HiSax: Card USR Sportster not installed !
> 
> 
> If the ISDN thing is a RTFM  thing that I just need to upograde some 
> userland tools, then don't worry about it. I no longer need it so I 
> doidn't put much research into it. It was just working fine till the new 
> driver version came in in 2.4.17.
> 
> I am concerned about the eepro issue. I normally love intel network 
> cards, they are damn fast and give excellent throughput on Windows NT 
> servers and Windows desktop machines. But constantly crashing my server 
> is not a good thing.
> 
> 
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: eepro100 kernel freeze / ISDN

[Michael Klose]

Ben Greear wrote:

> The problem is probably the eepro connected to the 10bt device.  10bt
> seems to lock things up much more often than a 100bt network connection.


What I think is happenening is when data is being generated and sent to 
the NIC faster than the NIC can handle. Since this is the case much 
easier with 10 MBit than 100MBit it locks up much more.

But not in my case.

The eepro100 which is directly connected to the DSL modem (10 MBut link) 
is running a maximum speed of 768kbit inwards (from Modem to Kernel) and 
128kbut outwards, which even for 10MBit is absolutely nothing. There is 
no other traffic on that link.

But the LAN side, connected to the switch (100 MBit) runs fine as long 
as the server is serving Mp3s or something or is just using the internet 
(low traffic). But as soon as you copy a few hundred megabytes in one go 
from another 100 MBit machine in the network to the linux server in one 
go  and which would normally only take a few seconds (mainly from my 
laptop via SMB as I am trying to free up the disk) the kernel goes 
Kaboom at once. Big kababoom, borrowing the expression from the 5th Element.
If I wanted the kernel to crash now, all I would have to do is copy for 
example a CD Image to the SMB share on the linux server. It happens 
every time.
Like I said, 2.4.15pre5 requires half a handful of gigabytes at once to 
make this happen. 2.4.17 looks up after half a handful of 100 megabytes 
(say half way through a cd image).


> Unfortunately, the only work-around I found for this problem so far
> is to change the hardware to a non intel NIC, or to use the e100 module
> 
>> from Intel...


I found tht out last night. Thanks. I hven't tried it yet, but I will 
tomorrow. I have just downloaded the source from intel. The source I 
downloaded from intel says it may work with "older" eepro100 models 
(which I have) but they don't guarantee it.

If I don't get it to work by monday, I have arranged a swap against some 
3Com cards.

I hope you don't mind me ccing this back to the lkml as that is where 
you picked up my mail to reply in the first place. By the way, I am not 
subscribed, but do read it regularly via nntp or via the archives for 
the week, so I can be reached over the list.