Uptime again?

Uptime again?

[Richard B. Johnson]

Uptime, when using Linux-2.4.1 doesn't seem to go past 128 days!
This is a RedHat distrubution, 7.x

These are the last three days:

 11:59am  up 128 days, 21:24,  2 users,  load average: 1.03, 1.01, 1.00
 10:06am  up 128 days, 12:31,  2 users,  load average: 1.02, 1.00, 1.00
  1:06pm  up 128 days, 22:31,  2 users,  load average: 1.00, 1.00, 1.00
Linux boneserver 2.4.1 #15 SMP Thu Aug 9 16:03:49 EDT 2001 i686
  1:10pm  up 128 days, 22:35,  2 users,  load average: 1.08, 1.02, 1.01
USER     TTY      FROM              LOGIN@  IDLE   JCPU   PCPU  WHAT
root     ttyp1    chaos.analogic.com 1:05pm  0.00s  0.12s  0.02s  w 


My Sun, which did NOT reboot several days ago, shows:

  1:11pm  up 2 day(s), 22:30,  1 user,  load average: 0.00, 0.00, 0.01

So it looks like it just 'wrapped'.
 
Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).

    I was going to compile a list of innovations that could be
    attributed to Microsoft. Once I realized that Ctrl-Alt-Del
    was handled in the BIOS, I found that there aren't any.

Re: Uptime again?

[jjs]

Just a data point, I have several Red Hat 7.1 boxes installed in various 
production environments, uptimes of 150-200 days so far with no end in 
sight... most are running the official 2.4.3-12, but I have been installing 
either the RH 2.4.9 update or 2.4.18pre2-aa2 on servers whenever there is 
occasion to reboot.

Joe

 On Fri, 25 Jan 2002, Richard B. Johnson wrote:

> 
> Uptime, when using Linux-2.4.1 doesn't seem to go past 128 days!
> This is a RedHat distrubution, 7.x
> 
> These are the last three days:
> 
>  11:59am  up 128 days, 21:24,  2 users,  load average: 1.03, 1.01, 1.00
>  10:06am  up 128 days, 12:31,  2 users,  load average: 1.02, 1.00, 1.00
>   1:06pm  up 128 days, 22:31,  2 users,  load average: 1.00, 1.00, 1.00
> Linux boneserver 2.4.1 #15 SMP Thu Aug 9 16:03:49 EDT 2001 i686
>   1:10pm  up 128 days, 22:35,  2 users,  load average: 1.08, 1.02, 1.01
> USER     TTY      FROM              LOGIN@  IDLE   JCPU   PCPU  WHAT
> root     ttyp1    chaos.analogic.com 1:05pm  0.00s  0.12s  0.02s  w 
> 
> 
> My Sun, which did NOT reboot several days ago, shows:
> 
>   1:11pm  up 2 day(s), 22:30,  1 user,  load average: 0.00, 0.00, 0.01
> 
> So it looks like it just 'wrapped'.
>  
> Cheers,
> Dick Johnson
> 
> Penguin : Linux version 2.4.1 on an i686 machine (797.90 BogoMips).
> 
>     I was going to compile a list of innovations that could be
>     attributed to Microsoft. Once I realized that Ctrl-Alt-Del
>     was handled in the BIOS, I found that there aren't any.
> 
> 
> -
> 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: Uptime again?

[Greg Boyce]

> Uptime, when using Linux-2.4.1 doesn't seem to go past 128 days!
> This is a RedHat distrubution, 7.x

Hm.

I just checked a group of machines I control, and the longest uptime I
found was also 128 days.

[root@nocc66 /root]# uptime
  4:30pm  up 128 days, 53 min,  2 users,  load average: 0.00, 0.00, 0.00

Mine is Redhat 7.1 with the 2.4.3-12 kernel.


--
Gregory Boyce

Re: Uptime again?

[Hartmut Holz]

10 to 20 Minutes. The magic application is lavrec. Kills every 2.4.x - without mercy.
I have never tested 2.2.x - would be interesting.

If am lucky I can reboot. Mostly I have to use the power switch.

Regards

Hartmut

Re: Uptime again?

[Rik van Riel]

On Sat, 26 Jan 2002, Hartmut Holz wrote:

> 10 to 20 Minutes. The magic application is lavrec. Kills every 2.4.x -
> without mercy.

Interesting. Could you test 2.4 -aa and 2.4 -rmap too if you
have the time ? ;)

(you can get -rmap and -aa from http://surriel.com/patches and
kernel.org, respectively)

regards,

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: Uptime again?

[Hartmut Holz]

Rik van Riel wrote:
 > On Sat, 26 Jan 2002, Hartmut Holz wrote:
 >

 >
 > Interesting. Could you test 2.4 -aa and 2.4 -rmap too if you
 > have the time ? ;)
 >
 > (you can get -rmap and -aa from http://surriel.com/patches and
 > kernel.org, respectively)
 >

rmap12a about 15 minutes. As far as I can remember, I tested 2.4.6, 2.4.14/15/16/17/18pre7, rmap11c

It looks like memory corruption. lavrec stops or makes a segmentation fault (With a oops).
After that every apps starts with a oops till the kernel is dead.

Xawtv works without any problems. I don't think -aa is a solution, but I will try it.


Regards

Hartmut

rmap12a:
---------

Jan 26 21:34:08 woodpecker kernel: CPU:    1
Jan 26 21:34:08 woodpecker kernel: EIP:    0010:[rmqueue+506/576]    Tainted: P
Jan 26 21:34:08 woodpecker kernel: EIP:    0010:[<c013004a>]    Tainted: P
Using defaults from ksymoops -t elf32-i386 -a i386
Jan 26 21:34:08 woodpecker kernel: EFLAGS: 00210202
Jan 26 21:34:08 woodpecker kernel: eax: 00000088   ebx: c10a68d8   ecx: 00001000   edx: 0000333f
Jan 26 21:34:08 woodpecker kernel: esi: c028c1dc   edi: 0001aff0   ebp: 0001aff0   esp: d8323ed0
Jan 26 21:34:08 woodpecker kernel: ds: 0018   es: 0018   ss: 0018
Jan 26 21:34:08 woodpecker kernel: Process lavrec (pid: 13680, stackpage=d8323000)
Jan 26 21:34:08 woodpecker kernel: Stack: 00001000 0000233f 00200282 00000000 c028c1dc 0001aff0 c028c3b8 00000000
Jan 26 21:34:08 woodpecker kernel:        00000100 c01301df 00000001 c028c3b4 000001d2 414e46c6 dbebe364 0000973a
Jan 26 21:34:08 woodpecker kernel:        c14efa4c d8323f54 dbebe364 0000973a 00000000 c0129f4a d8323f54 00001000
Jan 26 21:34:08 woodpecker kernel: Call Trace: [__alloc_pages+95/704] [generic_file_write+1066/1824] [sys_write+150/208] 
[smp_apic_timer_interrupt+239/288] [system_call+51/56]
Jan 26 21:34:08 woodpecker kernel: Call Trace: [<c01301df>] [<c0129f4a>] [<c01365a6>] [<c0111c8f>] [<c0106f3b>]
Jan 26 21:34:08 woodpecker kernel: Code: 0f 0b 8b 43 18 83 e0 20 74 02 0f 0b 89 d8 eb 22 8d b6 00 00

 >>EIP; c013004a <rmqueue+1fa/240>   <=====
Trace; c01301df <__alloc_pages+5f/2c0>
Trace; c0129f4a <generic_file_write+42a/720>
Trace; c01365a6 <sys_write+96/d0>
Trace; c0111c8f <smp_apic_timer_interrupt+ef/120>
Trace; c0106f3b <system_call+33/38>
Code;  c013004a <rmqueue+1fa/240>
00000000 <_EIP>:
Code;  c013004a <rmqueue+1fa/240>   <=====
    0:   0f 0b                     ud2a      <=====
Code;  c013004c <rmqueue+1fc/240>
    2:   8b 43 18                  mov    0x18(%ebx),%eax
Code;  c013004f <rmqueue+1ff/240>
    5:   83 e0 20                  and    $0x20,%eax
Code;  c0130052 <rmqueue+202/240>
    8:   74 02                     je     c <_EIP+0xc> c0130056 <rmqueue+206/240>
Code;  c0130054 <rmqueue+204/240>
    a:   0f 0b                     ud2a
Code;  c0130056 <rmqueue+206/240>
    c:   89 d8                     mov    %ebx,%eax
Code;  c0130058 <rmqueue+208/240>
    e:   eb 22                     jmp    32 <_EIP+0x32> c013007c <rmqueue+22c/240>
Code;  c013005a <rmqueue+20a/240>
   10:   8d b6 00 00 00 00         lea    0x0(%esi),%esi

Jan 26 21:34:08 woodpecker kernel:  invalid operand: 0000
Jan 26 21:34:08 woodpecker kernel: CPU:    0
Jan 26 21:34:08 woodpecker kernel: EIP:    0010:[rmqueue+506/576]    Tainted: P
Jan 26 21:34:08 woodpecker kernel: EIP:    0010:[<c013004a>]    Tainted: P
Jan 26 21:34:08 woodpecker kernel: EFLAGS: 00210202
Jan 26 21:34:08 woodpecker kernel: eax: 00000088   ebx: c10a68a4   ecx: 00001000   edx: 0000333e
Jan 26 21:34:08 woodpecker kernel: esi: c028c1dc   edi: 0001aff0   ebp: 0001aff0   esp: d0ec7b88
Jan 26 21:34:08 woodpecker kernel: ds: 0018   es: 0018   ss: 0018
Jan 26 21:34:08 woodpecker kernel: Process lavrec (pid: 13676, stackpage=d0ec7000)
Jan 26 21:34:08 woodpecker kernel: Stack: 00001000 0000233e 00200286 00000000 c028c1dc 0001aff0 c028c3b8 00000000
Jan 26 21:34:08 woodpecker kernel:        00000100 c01301df 00000001 c028c3b4 000001d2 d42c0000 dbef433c 00000003
Jan 26 21:34:08 woodpecker kernel:        d0ec6000 d0ec7c0c dbef433c 00000003 00000000 c0129f4a d0ec7c0c 00001000
Jan 26 21:34:08 woodpecker kernel: Call Trace: [__alloc_pages+95/704] [generic_file_write+1066/1824] [get_user_pages+252/384] 
[dump_write+26/48] [elf_core_dump+2338/2480]
Jan 26 21:34:08 woodpecker kernel: Call Trace: [<c01301df>] [<c0129f4a>] [<c0123edc>] [<c014e6aa>] [<c014f112>]
Jan 26 21:34:08 woodpecker kernel:    [<dd93f04b>] [balance_dirty_state+12/96] [do_coredump+272/336] [dequeue_signal+109/176] 
[do_signal+491/688] [sys_rt_sigsuspend+276/304]
Jan 26 21:34:08 woodpecker kernel:    [<dd93f04b>] [<c01384cc>] [<c013e8d0>] [<c011f17d>] [<c0106d8b>] [<c0106024>]
Jan 26 21:34:08 woodpecker kernel:    [<c0106f3b>]
Jan 26 21:34:08 woodpecker kernel: Code: 0f 0b 8b 43 18 83 e0 20 74 02 0f 0b 89 d8 eb 22 8d b6 00 00

 >>EIP; c013004a <rmqueue+1fa/240>   <=====
Trace; c01301df <__alloc_pages+5f/2c0>
Trace; c0129f4a <generic_file_write+42a/720>
Trace; c0123edc <get_user_pages+fc/180>
Trace; c014e6aa <dump_write+1a/30>
Trace; c014f112 <elf_core_dump+922/9b0>
Trace; dd93f04b <[bttv]bttv_call_i2c_clients+3b/50>
Trace; dd93f04b <[bttv]bttv_call_i2c_clients+3b/50>
Trace; c01384cc <balance_dirty_state+c/60>
Trace; c013e8d0 <do_coredump+110/150>
Trace; c011f17d <dequeue_signal+6d/b0>
Trace; c0106d8b <do_signal+1eb/2b0>
Trace; c0106024 <sys_rt_sigsuspend+114/130>
Trace; c0106f3b <system_call+33/38>
Code;  c013004a <rmqueue+1fa/240>
00000000 <_EIP>:
Code;  c013004a <rmqueue+1fa/240>   <=====
    0:   0f 0b                     ud2a      <=====
Code;  c013004c <rmqueue+1fc/240>
    2:   8b 43 18                  mov    0x18(%ebx),%eax
Code;  c013004f <rmqueue+1ff/240>
    5:   83 e0 20                  and    $0x20,%eax
Code;  c0130052 <rmqueue+202/240>
    8:   74 02                     je     c <_EIP+0xc> c0130056 <rmqueue+206/240>
Code;  c0130054 <rmqueue+204/240>
    a:   0f 0b                     ud2a
Code;  c0130056 <rmqueue+206/240>
    c:   89 d8                     mov    %ebx,%eax
Code;  c0130058 <rmqueue+208/240>
    e:   eb 22                     jmp    32 <_EIP+0x32> c013007c <rmqueue+22c/240>
Code;  c013005a <rmqueue+20a/240>
   10:   8d b6 00 00 00 00         lea    0x0(%esi),%esi


2.4.18.pre7:
-----------
Jan 26 17:28:40 woodpecker kernel: Unable to handle kernel paging request at virtual address 0232013d
Jan 26 17:28:40 woodpecker kernel: c0114893
Jan 26 17:28:40 woodpecker kernel: *pde = 00000000
Jan 26 17:28:40 woodpecker kernel: Oops: 0000
Jan 26 17:28:40 woodpecker kernel: CPU:    0
Jan 26 17:28:40 woodpecker kernel: EIP:    0010:[__wake_up+51/192]    Not tainted
Jan 26 17:28:40 woodpecker kernel: EIP:    0010:[<c0114893>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Jan 26 17:28:40 woodpecker kernel: EFLAGS: 00210083
Jan 26 17:28:40 woodpecker kernel: eax: d765d984   ebx: c02c60bc   ecx: 0232013d   edx: 00000001
Jan 26 17:28:40 woodpecker kernel: esi: d6001ede   edi: d765d980   ebp: d6001d68   esp: d6001d50
Jan 26 17:28:40 woodpecker kernel: ds: 0018   es: 0018   ss: 0018
Jan 26 17:28:40 woodpecker kernel: Process lavrec (pid: 1544, stackpage=d6001000)
Jan 26 17:28:40 woodpecker kernel: Stack: 00000001 00200282 00000001 d765d980 d6001ede d5d44a10 d765d000 c0185daa
Jan 26 17:28:40 woodpecker kernel:        c335da80 db6a5b60 d6001db8 00000007 00000120 00000160 0000000f 00006603
Jan 26 17:28:40 woodpecker kernel:        00000812 00001000 000d7f9d 00200202 00000000 00000812 000d7f9d 00001000
Jan 26 17:28:40 woodpecker kernel: Call Trace: [n_tty_receive_buf+2986/3040] [ext2_alloc_branch+48/576] [timer_bh+599/688] 
[ext2_get_branch+82/192] [ext2_get_block+943/1104]
Jan 26 17:28:40 woodpecker kernel: Call Trace: [<c0185daa>] [<c0158930>] [<c011f707>] [<c0158892>] [<c0158eef>]
Jan 26 17:28:40 woodpecker kernel:    [<c0158c3d>] [<c0108abf>] [<c01881be>] [<c0184d80>] [<c01869a5>] [<c01826ff>]
Jan 26 17:28:40 woodpecker kernel:    [<c0186840>] [<c01361c6>] [<c0108abf>] [<c010700b>]
Jan 26 17:28:40 woodpecker kernel: Code: 8b 01 85 45 f0 74 65 31 d2 9c 5e fa f0 fe 0d a0 38 2e c0 0f

 >>EIP; c0114893 <__wake_up+33/c0>   <=====
Trace; c0185daa <n_tty_receive_buf+baa/be0>
Trace; c0158930 <ext2_alloc_branch+30/240>
Trace; c011f707 <timer_bh+257/2b0>
Trace; c0158892 <ext2_get_branch+52/c0>
Trace; c0158eef <ext2_get_block+3af/450>
Trace; c0158c3d <ext2_get_block+fd/450>
Trace; c0108abf <do_IRQ+df/f0>
Trace; c01881be <pty_write+11e/130>
Trace; c0184d80 <opost_block+180/190>
Trace; c01869a5 <write_chan+165/1f0>
Trace; c01826ff <tty_write+20f/270>
Trace; c0186840 <write_chan+0/1f0>
Trace; c01361c6 <sys_write+96/d0>
Trace; c0108abf <do_IRQ+df/f0>
Trace; c010700b <system_call+33/38>
Code;  c0114893 <__wake_up+33/c0>
00000000 <_EIP>:
Code;  c0114893 <__wake_up+33/c0>   <=====
    0:   8b 01                     mov    (%ecx),%eax   <=====
Code;  c0114895 <__wake_up+35/c0>
    2:   85 45 f0                  test   %eax,0xfffffff0(%ebp)
Code;  c0114898 <__wake_up+38/c0>
    5:   74 65                     je     6c <_EIP+0x6c> c01148ff <__wake_up+9f/c0>
Code;  c011489a <__wake_up+3a/c0>
    7:   31 d2                     xor    %edx,%edx
Code;  c011489c <__wake_up+3c/c0>
    9:   9c                        pushf
Code;  c011489d <__wake_up+3d/c0>
    a:   5e                        pop    %esi
Code;  c011489e <__wake_up+3e/c0>
    b:   fa                        cli
Code;  c011489f <__wake_up+3f/c0>
    c:   f0 fe 0d a0 38 2e c0      lock decb 0xc02e38a0
Code;  c01148a6 <__wake_up+46/c0>
   13:   0f 00 00                  sldt   (%eax)

Re: Uptime again?

[Rik van Riel]

On Sat, 26 Jan 2002, Hartmut Holz wrote:
> Rik van Riel wrote:
>  > On Sat, 26 Jan 2002, Hartmut Holz wrote:

>  > Interesting. Could you test 2.4 -aa and 2.4 -rmap too if you
>  > have the time ? ;)
>  >
>  > (you can get -rmap and -aa from http://surriel.com/patches and
>  > kernel.org, respectively)
>
> rmap12a about 15 minutes. As far as I can remember, I tested 2.4.6,
> 2.4.14/15/16/17/18pre7, rmap11c
>
> It looks like memory corruption. lavrec stops or makes a segmentation
> fault (With a oops). After that every apps starts with a oops till the
> kernel is dead.

You're right.  While the bug is detected in the VM, chances
are it's cause is somewhere else.

The fact that lavrec crashes the machine while Xawtv works
suggests a device driver may be corrupting memory somewhere.

>  >>EIP; c013004a <rmqueue+1fa/240>   <=====
> Trace; c01301df <__alloc_pages+5f/2c0>
> Trace; c0129f4a <generic_file_write+42a/720>
> Trace; c01365a6 <sys_write+96/d0>
> Trace; c0111c8f <smp_apic_timer_interrupt+ef/120>
> Trace; c0106f3b <system_call+33/38>

Rik
-- 
"Linux holds advantages over the single-vendor commercial OS"
    -- Microsoft's "Competing with Linux" document

http://www.surriel.com/		http://distro.conectiva.com/

Re: Uptime again?

[Hartmut Holz]

Rik van Riel wrote:
> 
> The fact that lavrec crashes the machine while Xawtv works
> suggests a device driver may be corrupting memory somewhere.
> 

I got a debug patch from Manfred Spraul to debug slab.c. With this patch
the machine ran for about 3 hours. No problem. I looked into slab.c and had an
idea. What about just one CPU. So I built a new Kernel with just one CPU.
Result: 1 CPU 1 Minute - 2 CPU 20 Minutes. I aspected a different result.
In my opinion the whole thing has something to do with slab, SMP and threads.

The machine (450Mhz PII, 448 MB, Intel L440GX Mainboard, Adaptec) it self is solid.
It has run every 2.3.x and  2.4.x Kernel, Oracle and Sybase (only development).
No problem.
.

Regards

Hartmut

Re: Uptime again?

[Manfred Spraul]

From: "Hartmut Holz" <hartmut.holz@arcor.de>
> Rik van Riel wrote:
> >
> > The fact that lavrec crashes the machine while Xawtv works
> > suggests a device driver may be corrupting memory somewhere.
> >
>
> I got a debug patch from Manfred Spraul to debug slab.c.

poisoning of fields of 'struct page', slab poisoning, even of objects with constructors.
Same patch as:
http://groups.google.com/groups?selm=linux.kernel.3C3B6F65.F9226437%40colorfullife.com&rnum=1

> With this patch
> the machine ran for about 3 hours. No problem. I looked into slab.c and had an
> idea. What about just one CPU. So I built a new Kernel with just one CPU.
> Result: 1 CPU 1 Minute - 2 CPU 20 Minutes. I aspected a different result.
> In my opinion the whole thing has something to do with slab, SMP and threads.
>
Not with slab itself, probably with a slab user. Someone uses a stale pointer.

What do you means with one cpu? Did you boot a SMP kernel with "nosmp" on the command line, or did you make a kernel without
CONFIG_SMP?

--
    Manfred

Re: Uptime again?

[Hartmut Holz]

Manfred Spraul wrote:

> What do you means with one cpu? Did you boot a SMP kernel with "nosmp" on the command line, or did you make a kernel without
> CONFIG_SMP?
> 

from .config:
-------------

CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y

Of cause it was a new clean kernel tree. Tomorrow I will use your patch for this tree.
May be there are some results in the log.

Regards

Hartmut