Bug 47099 - Kernel 2.4.3-12 disconnect from the network autmatically
Summary: Kernel 2.4.3-12 disconnect from the network autmatically
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-07-03 07:25 UTC by Need Real Name
Modified: 2007-04-18 16:34 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-06-06 14:14:43 UTC
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.