Bug 59789 - Heavy load during backup causes oops using kernel 2.4.7-10
Heavy load during backup causes oops using kernel 2.4.7-10
Status: CLOSED ERRATA
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i586 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-13 06:55 EST by Lars Olofsson
Modified: 2007-04-18 12:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-13 08:57:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Entire oops dump (69.11 KB, text/plain)
2002-02-13 07:00 EST, Lars Olofsson
no flags Details

  None (edit)
Description Lars Olofsson 2002-02-13 06:55:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
Every night when running backups, creating a series of tarballs in /opt/backup 
for later burning to a CD-RW, an oops occurs when creating the largest file, 
size about 400Mb, compressing about 1GB of data. This is fully reproducable by 
running the same backup script again, and occurs during a gzip action, when 
gzip is called by running tar -cvzf home.tar /home/*

This causes a series of kernel oops.

First oops always looks very similar to this:

Feb 12 20:03:38 culture kernel: Unable to handle kernel NULL pointer dereference
 at virtual address 00000020
Feb 12 20:03:38 culture kernel:  printing eip:
Feb 12 20:03:38 culture kernel: c01120ba
Feb 12 20:03:38 culture kernel: *pde = 00000000
Feb 12 20:03:38 culture kernel: Oops: 0000
Feb 12 20:03:38 culture kernel: CPU:    0
Feb 12 20:03:38 culture kernel: EIP:    0010:[schedule+654/908]
Feb 12 20:03:38 culture kernel: EIP:    0010:[<c01120ba>]
Feb 12 20:03:38 culture kernel: EFLAGS: 00010207
Feb 12 20:03:38 culture kernel: eax: 00000014   ebx: 00000014   ecx: 00000000
edx: 0000000b
Feb 12 20:03:38 culture kernel: esi: 00000000   edi: c4290000   ebp: c4291fbc
esp: c4291f9c
Feb 12 20:03:38 culture kernel: ds: 0018   es: 0018   ss: 0018
Feb 12 20:03:38 culture kernel: Process gzip (pid: 1201, stackpage=c4291000)
Feb 12 20:03:38 culture kernel: Stack: c5292400 c4290000 00000000 c4290000 c0292
520 c4290000 00009bb4 080a419f
Feb 12 20:03:38 culture kernel:        bffff958 c0106e89 00000002 080a409d 080a0
784 00009bb4 080a419f bffff958
Feb 12 20:03:38 culture kernel:        00002e04 0000002b 0000002b ffffff00 08049
4d0 00000023 00000202 bffff940
Feb 12 20:03:38 culture kernel: Call Trace: [reschedule+5/12]
Feb 12 20:03:38 culture kernel: Call Trace: [<c0106e89>]
Feb 12 20:03:38 culture kernel:
Feb 12 20:03:38 culture kernel: Code: 8b 51 20 2b 41 24 d1 fa c1 f8 02 8d 54 10
01 89 51 20 8b 49

The following oops, caused by the one above kills lots of applications, usually 
squid and nfsd, which is bad since this machine is a server.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Start running the backup manually using tar -cvzf home.tar /home/*
2. After a few minutes the oops occurs about halfway through the backup.

	

Actual Results:  The attached oops, or something similar. Always gzip in the 
first oops.

Expected Results:  The file home.tar should have been created properly without 
any oops oocuring

Additional info:

Standard 2.4.7-10 kernel supplied on the RedHat 7.2 CD. All applications 
involved (tar and gzip) are also supplied on the CD.

The machine is a Dell XPS using a Pentium 200 MMX and has 96Mb of memory.
Comment 1 Lars Olofsson 2002-02-13 07:00:27 EST
Created attachment 45503 [details]
Entire oops dump
Comment 2 Lars Olofsson 2002-02-13 08:52:44 EST
Also, this bug wasn't present during backups running under RH 6.1 up until the 
last week, when I reinstalled the system to RH 7.2.
Comment 3 Arjan van de Ven 2002-02-13 08:57:41 EST
I would really recommend upgrading to the latest errata kernel; there's lots of
stuff fixed (not that I can point to a fix for your bug)

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