Bug 47099

Summary:	Kernel 2.4.3-12 disconnect from the network autmatically
Product:	[Retired] Red Hat Linux	Reporter:	Need Real Name <ted>
Component:	kernel	Assignee:	Arjan van de Ven <arjanv>
Status:	CLOSED NOTABUG	QA Contact:	Brock Organ <borgan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-06-06 14:14:43 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Need Real Name 2001-07-03 07:25:41 UTC

Hi!

I have upgraded the kernel for my RedHat 7.1 machines. One of them has a
strange problem: The network is unplugged automatically:

Jul  2 14:46:16 toulon network: Shutting down interface eth0:  succeeded
Jul  3 11:12:33 toulon sysctl: net.ipv4.ip_forward = 0
Jul  3 11:12:33 toulon sysctl: net.ipv4.conf.all.rp_filter = 1
Jul  3 11:12:33 toulon sysctl: kernel.sysrq = 0
Jul  3 11:12:33 toulon network: Setting network parameters:  succeeded
Jul  3 11:12:34 toulon network: Bringing up interface lo:  succeeded
Jul  3 11:12:35 toulon network: Bringing up interface eth0:  succeeded
Jul  3 11:12:35 toulon netfs: Mounting other filesystems:  succeeded

To get things back to normal I have to "wake up" the machine, that is to
say, to move the mouse for instance. Moreover, I have not done it at 11:12
but at 9:12 AM... As soon as the machine is awake again, the clock is set
to its normal value

Here are the references of the network card. The other machine has a
different network card and I don't have this problem. I did not have this
problem with 2.4.2-2.


PCI: Found IRQ 9 for device 00:0a.0
eth0: PCnet/PCI II 79C970A at 0xd000, 00 00 f4 af 95 d9
pcnet32: pcnet32_private lp=cbb26000 lp_dma_addr=0xbb26000 assigned IRQ 9.
pcnet32.c:v1.25kf 26.9.1999 tsbogend.de

Comment 1 Arjan van de Ven 2001-07-03 08:09:20 UTC

Since the messages come from a script and not the kernel, I think this might
be a initscripts issue (those were updated 2 days after the kernel).

Comment 2 Need Real Name 2001-07-03 08:16:19 UTC

Well, if you are refering to SysVint, I also upgraded the machine to
SysVinit-2.78-17.i386.rpm just before I upgraded the machine.

To boot the machine, I use a diskette that I generated with mkbootdisk after the
new kernel has been installed. It boots on the right kernel.

Daniel

Comment 3 Bill Nottingham 2001-07-06 03:28:00 UTC

initscripts was *not* updated; sysvinit has no scripts.

assigning back to kernel. :) perhaps an APM suspend/resume problem?

Comment 4 Need Real Name 2001-07-06 08:20:10 UTC

I have noticed something strange also. When I type "top", I see that the machine
has been on for 1 day and few hours, HOWEVER, I know that the machine has not
been rebooted for about a week...
It seems that somehow, this machine does not know how long it has been on. This
appeared also with the new kernel.

Daniel

Comment 5 Arjan van de Ven 2001-07-06 09:42:27 UTC

Could you try disabling powermanagement in the bios?
(and with "noapm" on the lilo commandline)

Comment 6 Need Real Name 2001-07-06 10:30:07 UTC

Power management?
What does it habe to do with the network connection and the "top" function?
Besides I don't use Lilo. The machine has Win NT 2000 installed and the redhat
installer does not recognize NTFS partitions. I have NT on one Hard drive and
Linux on the other. I decided to use a boot diskette instead of Lilo (I needed
the machine, no time or will to play with Lilo and fight against L, LI or
LIL...).
When I updated the kernel I regenerated the boot diskette by using mkbootdisk

Daniel

Comment 7 Arjan van de Ven 2001-07-06 10:33:32 UTC

If powermanagement stops the clock, that could explain the wrong uptime.

Comment 8 Need Real Name 2001-07-06 10:42:58 UTC

Well, the clock was still at the right value.
I checked the BIOS, I switched from: user define, PM Timer, Suspend mode : 30mn
to disabled, suspend mode: disabled. We will see...

What about the network problem which is really the one bothering me?

Daniel

Comment 9 Need Real Name 2001-07-09 08:00:17 UTC

Hi!

It seems that the source of the problem was the powermanagement option in the
BIOS. This is very strange. I don't know what it has to do with the network and
the "top" function but... OK... It works now...

Thanks for your help

Daniel