2.4.3 - Module problems?

2.4.3 - Module problems?

[Matthew W. Lowe]

I just tried to upgrade from whatever kernel comes with redhat to 2.4.3.
The build, install and such was smooth. When I got to starting up,
everything appeared to work, until it got to my NIC cards. Neither of
them loaded properly. I've built in the EXACT same module for the NICs
as I did the previous kernel. They were the NE2000 PCI module and the
3C59X module. The two NICs I have are: Realtek 8029 PCI, 3COM Etherlink
III ISA. Both are PNP, the etherlink is NOT the one with the b extention
at the end.

Any help would be greatly appriciated.

Thanks,
   Matt

Re: 2.4.3 - Module problems?

[Jeff Garzik]

"Matthew W. Lowe" wrote:
> I just tried to upgrade from whatever kernel comes with redhat to 2.4.3.
> The build, install and such was smooth. When I got to starting up,
> everything appeared to work, until it got to my NIC cards. Neither of
> them loaded properly. I've built in the EXACT same module for the NICs
> as I did the previous kernel. They were the NE2000 PCI module and the
> 3C59X module. The two NICs I have are: Realtek 8029 PCI, 3COM Etherlink
> III ISA. Both are PNP, the etherlink is NOT the one with the b extention
> at the end.

Maybe this is a typo or maybe not -- "3c509" is for Etherlink III ISA,
"3c59x" is for recent 3com PCI/EISA busmastering 10/100 NICs.

-- 
Jeff Garzik       | "Give a man a fish, and he eats for a day. Teach a
Building 1024     |  man to fish, and a US Navy submarine will make sure
MandrakeSoft      |  he's never hungry again." -- Chris Neufeld

Re: 2.4.3 - Module problems?

[Matthew W. Lowe]

Jeff Garzik wrote:

> "Matthew W. Lowe" wrote:
> > I just tried to upgrade from whatever kernel comes with redhat to 2.4.3.
> > The build, install and such was smooth. When I got to starting up,
> > everything appeared to work, until it got to my NIC cards. Neither of
> > them loaded properly. I've built in the EXACT same module for the NICs
> > as I did the previous kernel. They were the NE2000 PCI module and the
> > 3C59X module. The two NICs I have are: Realtek 8029 PCI, 3COM Etherlink
> > III ISA. Both are PNP, the etherlink is NOT the one with the b extention
> > at the end.
>
> Maybe this is a typo or maybe not -- "3c509" is for Etherlink III ISA,
> "3c59x" is for recent 3com PCI/EISA busmastering 10/100 NICs.

Errr, yea you're right it was a typo ** hits head **. I was thinking about my
friends problem with his install of linux at the time of writing, he has the
3c59x.

>
>
> --
> Jeff Garzik       | "Give a man a fish, and he eats for a day. Teach a
> Building 1024     |  man to fish, and a US Navy submarine will make sure
> MandrakeSoft      |  he's never hungry again." -- Chris Neufeld
> -
> 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/

Re: 2.4.3 - Module problems?

[Alan Cox]

> as I did the previous kernel. They were the NE2000 PCI module and the
> 3C59X module. The two NICs I have are: Realtek 8029 PCI, 3COM Etherlink
> III ISA. Both are PNP, the etherlink is NOT the one with the b extention
> at the end.

Make sure you use either the kernel or the usermode PnP and not both. (You
probably want to turn kernel PnP off)

Re: 2.4.3 - Module problems?

[ecksfantom]

I had the same problem when i upgraded to 2.4.2. 
Upgrading to the latest modutils
(ftp://ftp.kernel.org/pub/linux/utils/modutils/v2.4/modutils-2.4.5.tar.gz)
should get you going again.

~Jarrod

On Sun, 15 Apr 2001, Matthew W. Lowe wrote:

> I just tried to upgrade from whatever kernel comes with redhat to 2.4.3.
> The build, install and such was smooth. When I got to starting up,
> everything appeared to work, until it got to my NIC cards. Neither of
> them loaded properly. I've built in the EXACT same module for the NICs
> as I did the previous kernel. They were the NE2000 PCI module and the
> 3C59X module. The two NICs I have are: Realtek 8029 PCI, 3COM Etherlink
> III ISA. Both are PNP, the etherlink is NOT the one with the b extention
> at the end.
> 
> Any help would be greatly appriciated.
> 
> Thanks,
>    Matt
> 
> 
> -
> 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/
> 

Re: 2.4.3 - Module problems?

[Matthew W. Lowe]

I installed that, it fixed my one NIC... The 3COM. Or I assume it did, because
it shows up in ifconfig now, unlike the other one Unfortunately I still can't
ping the local host (destination net unreachable). I think that might just be a
byproduct of my main external card not working. Anyway, I double checked the
settings in both config files for the old kernel and the new one, the realtek
should be covered under the ne2000 pci mod. I built this directly into the
kernel and it still doesn't seem to be working. Anyone have any ideas?
Thanks,
  Matt
ecksfantom@home.com wrote:

> I had the same problem when i upgraded to 2.4.2.
> Upgrading to the latest modutils
> (ftp://ftp.kernel.org/pub/linux/utils/modutils/v2.4/modutils-2.4.5.tar.gz)
> should get you going again.
>
> ~Jarrod
>
> On Sun, 15 Apr 2001, Matthew W. Lowe wrote:
>
> > I just tried to upgrade from whatever kernel comes with redhat to 2.4.3.
> > The build, install and such was smooth. When I got to starting up,
> > everything appeared to work, until it got to my NIC cards. Neither of
> > them loaded properly. I've built in the EXACT same module for the NICs
> > as I did the previous kernel. They were the NE2000 PCI module and the
> > 3C59X module. The two NICs I have are: Realtek 8029 PCI, 3COM Etherlink
> > III ISA. Both are PNP, the etherlink is NOT the one with the b extention
> > at the end.
> >
> > Any help would be greatly appriciated.
> >
> > Thanks,
> >    Matt
> >
> >
> > -
> > 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/
> >
>
> -
> 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/

How to tune TCP for heavily loaded sendmail box

[Andrew Chan]

Greetings,

I am running a relaying sendmail box and I would like it to be able to
handle up to 600 or so concurrent (incoming or outgoing) connections.

I tried that and discovered that TONS of incoming connections are stuck at
SYNC_RECV state. It is like the sendmail box received these port 25
connection attempts and then didn't know what to do with them.

I suspect I need to tune some of the TCP parameters so that the system can
handle many short lived TCP connections in an efficent manner. Any pointer
to this specific issue or general TCP tunning under Linux (2.4.2-ac28
kernel) will be most appreciated.

Thanks.

Andrew

Re: How to tune TCP for heavily loaded sendmail box

[Matti Aarnio]

On Thu, Apr 19, 2001 at 07:49:45AM +0800, Andrew Chan wrote:
> Greetings,
> 
> I am running a relaying sendmail box and I would like it to be able to
> handle up to 600 or so concurrent (incoming or outgoing) connections.
> 
> I tried that and discovered that TONS of incoming connections are stuck at
> SYNC_RECV state. It is like the sendmail box received these port 25
> connection attempts and then didn't know what to do with them.

	Such sockets don't make it to accept() -- the TCP connection
	setup is a three-way handshake, and SYN_RECV is just indication
	of the reception of the first part of it:

	1)  local  <-------  SYN ----------  remote
	2)  local  --------  ACK,SYN ----->  remote
	3)  local  <-------  ACk,ACK ------  remote

	Each of those  SYN_RECV  sockets have done 2, but have never
	heard back.   In normal case the state 3 is reached by 1.5
	times the roundtrip time between the two systems. (Presuming
	symmetric delays.)

	There is finite size queue of sockets that can sit in this
	particular state waiting for full open (3), after which the
	user programs can then get the sockets with  accept().

	It may be so called 'SYN-attack', although it might just as
	well be routing blackhole somewhere.

	Look for documents regarding SYN-Cookies, and how to enable them.
	( I.e. what values mean what at:
		/proc/sys/net/ipv4/tcp_syncookies )

> I suspect I need to tune some of the TCP parameters so that the system can
> handle many short lived TCP connections in an efficent manner. Any pointer
> to this specific issue or general TCP tunning under Linux (2.4.2-ac28
> kernel) will be most appreciated.
> 
> Thanks.
> 
> Andrew

/Matti Aarnio