Bug 55689 - updatedb is crashing my server
updatedb is crashing my server
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i686 Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-04 18:54 EST by Michael B. Weiner
Modified: 2008-08-01 12:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:39:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
output of dmesg (11.30 KB, text/plain)
2001-11-04 22:11 EST, Michael B. Weiner
no flags Details
output of lspci (2.90 KB, text/plain)
2001-11-04 22:11 EST, Michael B. Weiner
no flags Details

  None (edit)
Description Michael B. Weiner 2001-11-04 18:54:21 EST
Description of Problem:
The daily cronjob running updatedb (i.e. slocate.cron) is crashing my
server while trying to update the slocate database.

Version-Release number of selected component (if applicable):
slocate-2.6.1 running on a redhat 7.2 linux 2.4.9-13 i686 server

How Reproducible:
ran the cron manually, ran slocate with the switches found in the cron
manually, ran updatedb manually and all three methods had the same result.

Steps to Reproduce:
1. run the /etc/cron.daily/slocate.cron (default cron job installed from RPM)
2. run slocate with the -f and -e options as found in the above cronjob
3. run updatedb with the same switches as above

Actual Results:
slocate cron begins to run and creates the /var/lib/slocate/slocate.db.tmp
file but never completes the job.

Expected Results:
slocate would complete and write a new /var/lib/slocate/slocate.db file

Additional Information:
this is a critical issue as this server is part of an active web-presence
provider's network.
Comment 1 Michael B. Weiner 2001-11-04 22:11:25 EST
Created attachment 36421 [details]
output of dmesg
Comment 2 Michael B. Weiner 2001-11-04 22:11:52 EST
Created attachment 36422 [details]
output of lspci
Comment 3 Bill Nottingham 2001-11-05 00:42:15 EST
If the server is crashing, that indicates a HW or kernel problem.
Comment 4 Arjan van de Ven 2001-11-05 04:07:45 EST
"crashes the system" -> Any more info about the crash than that ?
Also, can you give a brief overview of the hardware (motherboard, pci cards etc
etc)
Comment 5 Michael B. Weiner 2001-11-05 06:43:18 EST
i sent you the dmesg output and lspci output for your review. But in short, this
is a Intel 82440FX-based dual pentium pro 200 motherboard with 256M physical
RAM. The server uses and Intel Ethernet Pro 100, ATI 3D Rage Pro 215GP, Adaptec
AHA-2940 / AIC-7871 SCSI adapter.
 
And i disagree, this is NOT a HW issue, as this was working very well before i
upgraded to the most recent version of redhat (i.e. 7.2). This server has
performed almost flawlessly since the day it was built and put into server
(around the time redhat 4.2 came out).
Comment 6 Arjan van de Ven 2001-11-05 06:46:23 EST
I'm not saying it's a hardware issue. 
However I'd love to have more info about the crash other than "it crashes".
What are the symptoms, is anything printed on the screen ?
Comment 7 Michael B. Weiner 2001-11-05 07:33:38 EST
actually that was a response to Mr Nottingham's remark above, regarding that it
"indicates a HW or kernel problem" and i have not been able to gleam any more
information from this as the system just freezes sending NOTHING to stdout as
one might expect. By the time i get down to the server room and get to the
console, root cannot login, and the screen has been blanked due to the power
management on the monitor, but even so, running it by hand yields nothing to
stdout. I did consider running strace on it, but after crashing the system (a
production server) 3 times yesterday, i decided it was time to let it stay up so
my customers didnt get bent out of shape any more than they are already. This is
a production web-presence provider server hosting numerous residential and
commercial websites. 

I keep the sytem up2date with the latest errata and dont do much else in the way
of modifying the system away from the default configuration (i.e. running 3rd
party applications and services that are not native to or built specifically for
redhat, esp. 7.2).

Comment 8 borgia 2001-11-07 05:18:00 EST
The following bugs appear to me to be one and the same, at least from the symptoms:
54931, 55377 and 55689.
I had crashes happen both immediately after high disk activity and during it. Swap usage was minimal.
You might want to check if they can be linked.
Comment 9 Bill Nottingham 2001-11-08 20:43:27 EST
Did it crash this way when 2.4.7-10 was installed, or did it start with the
upgrade to 2.4.9-13?
Comment 10 borgia 2001-11-09 08:13:25 EST
Also before... and also with a custom 2.4.9 which I made. I took the i686-up config and simply added ntfs, so it's just like the original.
Comment 11 Adam Cowell 2002-04-18 18:26:54 EDT
I have a similar problem. But with my system is just takes up all the CPU time
and I have to "kill -9" the process. My system is a Athlon 1Ghz 768Megs RAM and
40Gig HDD. I am not sure if its my CPU speed and RAM size which is preventing
mine from crashing, as I seem to be one of the few who suffers a huge slowdown
instead of a full crash.
Comment 12 Craig D. Rice 2004-09-16 11:10:07 EDT
I have a similar-sounding problem with RH9.  Details are attached.  I
will probably open a new bug report on it, though, since this
particular bug is pretty old.  I'll reference this bug in my new bug
report.

----- CUT HERE -----

Subject: problems with RH9 wedging during updatedb, backups and find

When running an updatedb (when run by hand but especially when run
from cron.daily/slocate.cron), a backup or even a "find" on a stock
RedHat 9 system, the load average shoots up to 30-90 and the system
becomes unresponsive.  If we kill off the suspect process, within a
minute or two, the server starts responding again.

The problem appears to be related to processes that access lots of
files and directories.  It occurs whether we access files and
directories on a local (RAID 1) disk or on our SAN.  It happens if we
do a find in /usr (8GB filesystem) or /export/home (256GB filesystem).

With the stock RedHat 9 system, we could reproduce this problem on
demand on multiple machines (our 995 server, other servers, and
desktop systems running the same distribution).  After upgrading to
the following, we still experience the problem but can no longer
replicate it on demand (in other words, upgrading these packages
helped but did not solve the problem):

glibc-2.3.2-27.9.7.i686.rpm
glibc-common-2.3.2-27.9.7.i386.rpm
glibc-debug-2.3.2-27.9.7.i386.rpm
glibc-devel-2.3.2-27.9.7.i386.rpm
glibc-profile-2.3.2-27.9.7.i386.rpm
glibc-utils-2.3.2-27.9.7.i386.rpm
nptl-devel-2.3.2-27.9.7.i686.rpm
nscd-2.3.2-27.9.7.i386.rpm

Our machine configuration:

2x Pentium4 Xeon 2.8 GHz (hyperthreading makes this 4 processors)
8 GB RAM
LSI Logic/Symbios Megaraid (for local storage)
QLogic QLA2312 FCA (for SAN storage)

The kernel is 2.4.26, custom compiled because we needed the "probe all
LUNs" options for SCSI devices.  Other than that, it's essentially a
RedHat "bigmem" config.

A cron job to sample the load average every minute yields results like
this
when the freeze-up happens:

Tue Sep 14 01:01:00 CDT 2004   3.26, 2.95, 3.09
Tue Sep 14 01:02:01 CDT 2004   2.78, 2.84, 3.04
Tue Sep 14 01:03:46 CDT 2004   91.75, 36.30, 15.24
Tue Sep 14 01:04:29 CDT 2004   91.75, 36.30, 15.24
Tue Sep 14 01:04:59 CDT 2004   57.34, 33.30, 14.91
Tue Sep 14 01:06:01 CDT 2004   20.59, 27.14, 14.02
Tue Sep 14 01:07:00 CDT 2004   9.02, 22.82, 13.30
Tue Sep 14 01:08:01 CDT 2004   4.05, 18.65, 12.50
Tue Sep 14 01:09:00 CDT 2004   2.79, 15.83, 11.89

Here's a play-by-play of what's happening in /proc/sys/fs/dentry-state:
(the first two entries: nr_dentry, nr_unused)

Tue Sep 7 23:59:00 CDT 2004  156433   131967
Wed Sep 8 00:00:00 CDT 2004  157094   132708
Wed Sep 8 00:01:00 CDT 2004  157569   133199
Wed Sep 8 00:02:00 CDT 2004  158177   133757
Wed Sep 8 00:03:00 CDT 2004  158743   134338
Wed Sep 8 00:04:00 CDT 2004  159446   134961
Wed Sep 8 00:05:00 CDT 2004  159918   135456
Wed Sep 8 00:06:00 CDT 2004  160603   136093
Wed Sep 8 00:07:00 CDT 2004  161063   136589
Wed Sep 8 00:08:00 CDT 2004  231326   203007
Wed Sep 8 00:09:00 CDT 2004  303660   268844
Wed Sep 8 00:10:00 CDT 2004  362537   320069
Wed Sep 8 00:11:00 CDT 2004  431354   382065
Wed Sep 8 00:12:00 CDT 2004  521047   466227
Wed Sep 8 00:13:00 CDT 2004  572074   514308
Wed Sep 8 00:14:00 CDT 2004  606031   546544
Wed Sep 8 00:15:00 CDT 2004  666875   606720
Wed Sep 8 00:16:00 CDT 2004  684500   623566
Wed Sep 8 00:17:00 CDT 2004  738342   673712
Wed Sep 8 00:18:00 CDT 2004  647117   584059
Wed Sep 8 00:19:00 CDT 2004  592345   534711
Wed Sep 8 00:20:00 CDT 2004  598856   540664
Wed Sep 8 00:21:00 CDT 2004  606085   547288
Wed Sep 8 00:22:00 CDT 2004  612799   553355
Wed Sep 8 00:23:00 CDT 2004  617889   557965
Wed Sep 8 00:24:00 CDT 2004  622157   561922
Wed Sep 8 00:25:17 CDT 2004  86295    49797
Wed Sep 8 00:26:31 CDT 2004  92988    56090
Wed Sep 8 00:27:31 CDT 2004  98908    61253
Wed Sep 8 00:28:31 CDT 2004  107225   68497
Wed Sep 8 00:29:31 CDT 2004  113340   73856
Wed Sep 8 00:30:31 CDT 2004  121671   81278
Wed Sep 8 00:31:31 CDT 2004  131700   90328
Wed Sep 8 00:32:31 CDT 2004  140194   97959
Wed Sep 8 00:33:31 CDT 2004  147639   104598

Note how both nr_dentry and nr_unused take a considerable drop at 00:25.

Upgraded glibc to 2.3.2-27.9.7, which seemed to help a bit, but still
doesn't solve the problem.

Our theory is that the kernel gets starved for dentry's, as evidenced
by the sudden drop in dentry-state numbers.  Not sure what to do about
this, though.

If it helps, the output of "mount" is:

/dev/sda1 on / type ext3 (rw)
none on /proc type proc (rw)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
/dev/sda5 on /boot type ext3 (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda11 on /home type ext3 (rw)
none on /dev/shm type tmpfs (rw)
/dev/sda6 on /tmp type ext3 (rw)
/dev/sda9 on /usr type ext3 (rw)
/dev/sda7 on /var type ext3 (rw)
/dev/sda10 on /var/spool type ext3 (rw)
/dev/sdb1 on /var/spool/mail type ext3 (rw)
/dev/sdc1 on /export/home type ext3 (rw,usrquota)

Outputs of lspci and dmesg are below.

This bug looks similar to 55689
(http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55689), although
that one refers to RH7.2.

Anyone have any ideas?  (Even if the answer is "Fixed in Fedora",
that'd be helpful.)

Thanks!

Craig

-----
output of lspci

00:00.0 Host bridge: ServerWorks CMIC-HE (rev 22)
00:00.1 Host bridge: ServerWorks CMIC-HE
00:00.2 Host bridge: ServerWorks CMIC-HE
00:00.3 Host bridge: ServerWorks CMIC-HE
00:02.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
00:03.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100]
(rev 0d)
00:0f.0 ISA bridge: ServerWorks CSB5 South Bridge (rev 93)
00:0f.1 IDE interface: ServerWorks CSB5 IDE Controller (rev 93)
00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 05)
00:0f.3 Host bridge: ServerWorks GCLE Host Bridge
00:10.0 Host bridge: ServerWorks CIOB30 (rev 03)
00:10.2 Host bridge: ServerWorks CIOB30 (rev 03)
00:11.0 Host bridge: ServerWorks CIOB30 (rev 03)
00:11.2 Host bridge: ServerWorks CIOB30 (rev 03)
01:03.0 Ethernet controller: Intel Corp. 82544GC Gigabit Ethernet
Controller (LOM) (rev 02)
02:09.0 Fibre Channel: QLogic Corp. QLA2312 Fibre Channel Adapter (rev 02)
04:09.0 RAID bus controller: LSI Logic / Symbios Logic PowerEdge
Expandable RAID Controller 4 (rev 01)

-----

output of dmesg

xc9 -> IRQ 32 Mode:1 Active:1)
00:00:08[B] -> 10-0 -> IRQ 32
IOAPIC[2]: Set PCI routing entry (10-8 -> 0xd1 -> IRQ 40 Mode:1 Active:1)
00:00:08[C] -> 10-8 -> IRQ 40
IOAPIC[2]: Set PCI routing entry (10-9 -> 0xd9 -> IRQ 41 Mode:1 Active:1)
00:00:08[D] -> 10-9 -> IRQ 41
IOAPIC[1]: Set PCI routing entry (9-7 -> 0xe1 -> IRQ 23 Mode:1 Active:1)
00:00:09[A] -> 9-7 -> IRQ 23
IOAPIC[2]: Set PCI routing entry (10-1 -> 0xe9 -> IRQ 33 Mode:1 Active:1)
00:00:09[B] -> 10-1 -> IRQ 33
IOAPIC[1]: Set PCI routing entry (9-3 -> 0x32 -> IRQ 19 Mode:1 Active:1)
00:01:03[A] -> 9-3 -> IRQ 19
IOAPIC[1]: Set PCI routing entry (9-0 -> 0x3a -> IRQ 16 Mode:1 Active:1)
00:01:04[A] -> 9-0 -> IRQ 16
IOAPIC[1]: Set PCI routing entry (9-1 -> 0x42 -> IRQ 17 Mode:1 Active:1)
00:01:04[B] -> 9-1 -> IRQ 17
IOAPIC[1]: Set PCI routing entry (9-8 -> 0x4a -> IRQ 24 Mode:1 Active:1)
00:02:08[A] -> 9-8 -> IRQ 24
IOAPIC[2]: Set PCI routing entry (10-2 -> 0x52 -> IRQ 34 Mode:1 Active:1)
00:02:08[B] -> 10-2 -> IRQ 34
IOAPIC[2]: Set PCI routing entry (10-10 -> 0x5a -> IRQ 42 Mode:1 Active:1)
00:02:08[C] -> 10-10 -> IRQ 42
IOAPIC[2]: Set PCI routing entry (10-11 -> 0x62 -> IRQ 43 Mode:1 Active:1)
00:02:08[D] -> 10-11 -> IRQ 43
IOAPIC[1]: Set PCI routing entry (9-9 -> 0x6a -> IRQ 25 Mode:1 Active:1)
00:02:09[A] -> 9-9 -> IRQ 25
IOAPIC[2]: Set PCI routing entry (10-3 -> 0x72 -> IRQ 35 Mode:1 Active:1)
00:02:09[B] -> 10-3 -> IRQ 35
IOAPIC[1]: Set PCI routing entry (9-10 -> 0x7a -> IRQ 26 Mode:1 Active:1)
00:03:08[A] -> 9-10 -> IRQ 26
IOAPIC[2]: Set PCI routing entry (10-4 -> 0x82 -> IRQ 36 Mode:1 Active:1)
00:03:08[B] -> 10-4 -> IRQ 36
IOAPIC[2]: Set PCI routing entry (10-12 -> 0x8a -> IRQ 44 Mode:1 Active:1)
00:03:08[C] -> 10-12 -> IRQ 44
IOAPIC[2]: Set PCI routing entry (10-13 -> 0x92 -> IRQ 45 Mode:1 Active:1)
00:03:08[D] -> 10-13 -> IRQ 45
IOAPIC[1]: Set PCI routing entry (9-11 -> 0x9a -> IRQ 27 Mode:1 Active:1)
00:03:09[A] -> 9-11 -> IRQ 27
IOAPIC[2]: Set PCI routing entry (10-5 -> 0xa2 -> IRQ 37 Mode:1 Active:1)
00:03:09[B] -> 10-5 -> IRQ 37
IOAPIC[1]: Set PCI routing entry (9-12 -> 0xaa -> IRQ 28 Mode:1 Active:1)
00:04:08[A] -> 9-12 -> IRQ 28
IOAPIC[2]: Set PCI routing entry (10-6 -> 0xb2 -> IRQ 38 Mode:1 Active:1)
00:04:08[B] -> 10-6 -> IRQ 38
IOAPIC[2]: Set PCI routing entry (10-14 -> 0xba -> IRQ 46 Mode:1 Active:1)
00:04:08[C] -> 10-14 -> IRQ 46
IOAPIC[2]: Set PCI routing entry (10-15 -> 0xc2 -> IRQ 47 Mode:1 Active:1)
00:04:08[D] -> 10-15 -> IRQ 47
IOAPIC[1]: Set PCI routing entry (9-13 -> 0xca -> IRQ 29 Mode:1 Active:1)
00:04:09[A] -> 9-13 -> IRQ 29
IOAPIC[2]: Set PCI routing entry (10-7 -> 0xd2 -> IRQ 39 Mode:1 Active:1)
00:04:09[B] -> 10-7 -> IRQ 39
number of MP IRQ sources: 15.
number of IO-APIC #8 registers: 16.
number of IO-APIC #9 registers: 16.
number of IO-APIC #10 registers: 16.
testing the IO APIC.......................

IO APIC #8......
.... register #00: 08000000
.......    : physical APIC id: 08
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 000F0011
.......     : max redirection entries: 000F
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 08000000
.......     : arbitration: 08
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 00 000 00  1    0    0   0   0    0    0    00
 01 00F 0F  0    0    0   0   0    1    1    39
 02 000 00  1    0    0   0   0    0    0    00
 03 00F 0F  0    0    0   0   0    1    1    41
 04 00F 0F  0    0    0   0   0    1    1    49
 05 00F 0F  0    0    0   0   0    1    1    51
 06 00F 0F  0    0    0   0   0    1    1    59
 07 00F 0F  0    0    0   0   0    1    1    61
 08 00F 0F  0    0    0   0   0    1    1    69
 09 00F 0F  0    1    0   1   0    1    1    71
 0a 00F 0F  1    1    0   1   0    1    1    79
 0b 00F 0F  0    0    0   0   0    1    1    81
 0c 00F 0F  0    0    0   0   0    1    1    89
 0d 00F 0F  0    0    0   0   0    1    1    91
 0e 00F 0F  0    0    0   0   0    1    1    99
 0f 00F 0F  0    0    0   0   0    1    1    A1

IO APIC #9......
.... register #00: 09000000
.......    : physical APIC id: 09
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 000F0011
.......     : max redirection entries: 000F
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 09000000
.......     : arbitration: 09
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 00 00F 0F  1    1    0   1   0    1    1    3A
 01 00F 0F  1    1    0   1   0    1    1    42
 02 00F 0F  1    1    0   1   0    1    1    B1
 03 00F 0F  1    1    0   1   0    1    1    32
 04 00F 0F  1    1    0   1   0    1    1    A9
 05 00F 0F  1    1    0   1   0    1    1    B9
 06 00F 0F  1    1    0   1   0    1    1    C1
 07 00F 0F  1    1    0   1   0    1    1    E1
 08 00F 0F  1    1    0   1   0    1    1    4A
 09 00F 0F  1    1    0   1   0    1    1    6A
 0a 00F 0F  1    1    0   1   0    1    1    7A
 0b 00F 0F  1    1    0   1   0    1    1    9A
 0c 00F 0F  1    1    0   1   0    1    1    AA
 0d 00F 0F  1    1    0   1   0    1    1    CA
 0e 000 00  1    0    0   0   0    0    0    00
 0f 000 00  1    0    0   0   0    0    0    00

IO APIC #10......
.... register #00: 0A000000
.......    : physical APIC id: 0A
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 000F0011
.......     : max redirection entries: 000F
.......     : PRQ implemented: 0
.......     : IO APIC version: 0011
.... register #02: 0A000000
.......     : arbitration: 0A
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
 00 00F 0F  1    1    0   1   0    1    1    C9
 01 00F 0F  1    1    0   1   0    1    1    E9
 02 00F 0F  1    1    0   1   0    1    1    52
 03 00F 0F  1    1    0   1   0    1    1    72
 04 00F 0F  1    1    0   1   0    1    1    82
 05 00F 0F  1    1    0   1   0    1    1    A2
 06 00F 0F  1    1    0   1   0    1    1    B2
 07 00F 0F  1    1    0   1   0    1    1    D2
 08 00F 0F  1    1    0   1   0    1    1    D1
 09 00F 0F  1    1    0   1   0    1    1    D9
 0a 00F 0F  1    1    0   1   0    1    1    5A
 0b 00F 0F  1    1    0   1   0    1    1    62
 0c 00F 0F  1    1    0   1   0    1    1    8A
 0d 00F 0F  1    1    0   1   0    1    1    92
 0e 00F 0F  1    1    0   1   0    1    1    BA
 0f 00F 0F  1    1    0   1   0    1    1    C2
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 1:0
IRQ17 -> 1:1
IRQ18 -> 1:2
IRQ19 -> 1:3
IRQ20 -> 1:4
IRQ21 -> 1:5
IRQ22 -> 1:6
IRQ23 -> 1:7
IRQ24 -> 1:8
IRQ25 -> 1:9
IRQ26 -> 1:10
IRQ27 -> 1:11
IRQ28 -> 1:12
IRQ29 -> 1:13
IRQ32 -> 2:0
IRQ33 -> 2:1
IRQ34 -> 2:2
IRQ35 -> 2:3
IRQ36 -> 2:4
IRQ37 -> 2:5
IRQ38 -> 2:6
IRQ39 -> 2:7
IRQ40 -> 2:8
IRQ41 -> 2:9
IRQ42 -> 2:10
IRQ43 -> 2:11
IRQ44 -> 2:12
IRQ45 -> 2:13
IRQ46 -> 2:14
IRQ47 -> 2:15
.................................... done.
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even
'acpi=off'
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
apm: BIOS not found.
Starting kswapd
allocated 32 pages and 32 bhs reserved for the highmem bounces
VFS: Disk quotas vdquot_6.5.1
pty: 2048 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT
SHARE_IRQ SERIAL_PCI ISAPNP enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10f
Floppy drive(s): fd0 is 1.44M
FDC 0 is a National Semiconductor PC87306
NET4: Frame Diverter 0.46
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
SvrWks CSB5: IDE controller at PCI slot 00:0f.1
SvrWks CSB5: chipset revision 147
SvrWks CSB5: not 100% native mode: will probe irqs later
SvrWks CSB5: simplex device: DMA forced
    ide0: BM-DMA at 0x2440-0x2447, BIOS settings: hda:DMA, hdb:pio
SvrWks CSB5: simplex device: DMA forced
    ide1: BM-DMA at 0x2448-0x244f, BIOS settings: hdc:pio, hdd:pio
hda: CD-224E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide: late registration of driver.
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Initializing Cryptographic API
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 65536 buckets, 512Kbytes
TCP: Hash tables configured (established 262144 bind 65536)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 559k freed
VFS: Mounted root (ext2 filesystem).
SCSI subsystem driver Revision: 1.00
megaraid: v1.18k (Release Date: Thu Aug 28 10:05:11 EDT 2003)
megaraid: found 0x1000:0x1960:idx 0:bus 4:slot 9:func 0
scsi0 : Found a MegaRAID controller at 0xf8847000, IRQ: 29
scsi0 : Enabling 64 bit support
megaraid: [1L24:G110] detected 1 logical drives
megaraid: supports extended CDBs.
megaraid: channel[1] is raid.
scsi0 : LSI Logic MegaRAID 1L24 254 commands 15 targs 4 chans 7 luns
blk: queue c71a6218, I/O limit 4095Mb (mask 0xffffffff)
scsi0: scanning virtual channel 0 for logical drives.
  Vendor: MegaRAID  Model: LD0 RAID1 35002R  Rev: 1L24
  Type:   Direct-Access                      ANSI SCSI revision: 02
blk: queue c71a6018, I/O limit 4095Mb (mask 0xffffffff)
scsi0: scanning virtual channel 1 for logical drives.
scsi0: scanning virtual channel 2 for logical drives.
scsi0: scanning physical channel 0 for devices.
  Vendor: ESG-SHV   Model: SCA HSBP M15      Rev: 0.10
  Type:   Processor                          ANSI SCSI revision: 02
blk: queue f6fb7e18, I/O limit 4095Mb (mask 0xffffffff)
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 71684096 512-byte hdwr sectors (36702 MB)
Partition check:
 sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 >
qla2x00_set_info starts at address = f8849060
qla2x00: Found  VID=1077 DID=2312 SSVID=1077 SSDID=100
scsi(1): Found a QLA2312  @ bus 2, device 0x9, irq 25, iobase 0x00002800
scsi(1): Allocated 4096 SRB(s).
scsi(1): Configure NVRAM parameters...
scsi(1): 64 Bit PCI Addressing Enabled.
scsi(1): Scatter/Gather entries= 32
scsi(1): Verifying loaded RISC code...
scsi(1): Verifying chip...
scsi(1): Waiting for LIP to complete...
scsi(1): LOOP UP detected.
scsi(1): Port database changed.
scsi(1): Topology - (F_Port), Host Loop address 0xffff
scsi-qla0-adapter-node=200000e08b0f5cc3\;
scsi-qla0-adapter-port=210000e08b0f5cc3\;
scsi-qla0-tgt-0-di-0-port=200300a0b80c3455\;
scsi1 : QLogic QLA2312 PCI to Fibre Channel Host Adapter: bus 2 device
9 irq 25
        Firmware version:  3.02.16, Driver version 6.06.10

blk: queue c7138e18, I/O limit 4294967295Mb (mask 0xffffffffffffffff)
  Vendor: STK       Model: OPENstorage 9176  Rev: 0530
  Type:   Direct-Access                      ANSI SCSI revision: 03
blk: queue c7138c18, I/O limit 4294967295Mb (mask 0xffffffffffffffff)
  Vendor: STK       Model: OPENstorage 9176  Rev: 0530
  Type:   Direct-Access                      ANSI SCSI revision: 03
blk: queue c7138a18, I/O limit 4294967295Mb (mask 0xffffffffffffffff)
scsi(1:0:0:0): Enabled tagged queuing, queue depth 32.
scsi(1:0:0:1): Enabled tagged queuing, queue depth 32.
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
Attached scsi disk sdc at scsi1, channel 0, id 0, lun 1
SCSI device sdb: 268435456 512-byte hdwr sectors (137439 MB)
 sdb: sdb1
SCSI device sdc: 536870912 512-byte hdwr sectors (274878 MB)
 sdc: sdc1
Journalled Block Device driver loaded
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
Freeing unused kernel memory: 164k freed
scsi(1) qla2x00_isr MBA_PORT_UPDATE ignored
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
usb-ohci.c: USB OHCI at membase 0xf88d4000, IRQ 10
usb-ohci.c: usb-00:0f.2, ServerWorks OSB4/CSB5 OHCI USB Controller
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 4 ports detected
usb.c: registered new driver hid
hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik <vojtech@suse.cz>
hid-core.c: USB HID support drivers
mice: PS/2 mouse device common for all mice
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,1), internal journal
Adding Swap: 4008176k swap-space (priority -1)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,5), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,11), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,6), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,9), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,7), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,10), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,17), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on sd(8,33), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
IA-32 Microcode Update Driver: v1.14 <tigran@veritas.com>
microcode: No suitable data for cpu 3
microcode: No suitable data for cpu 1
microcode: No suitable data for cpu 2
microcode: No suitable data for cpu 0
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
ip_tables: (C) 2000-2002 Netfilter core team
Intel(R) PRO/1000 Network Driver - version 5.2.30.1-k1
Copyright (c) 1999-2004 Intel Corporation.
divert: allocating divert_blk for eth0
eth0: Intel(R) PRO/1000 Network Connection
ip_tables: (C) 2000-2002 Netfilter core team
Intel(R) PRO/100 Network Driver - version 2.3.38-k1
Copyright (c) 2004 Intel Corporation

divert: allocating divert_blk for eth1
e100: selftest OK.
e100: eth1: Intel(R) PRO/100 Network Connection
  Hardware receive checksums enabled
  cpu cycle saver enabled

ip_tables: (C) 2000-2002 Netfilter core team
e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex
e100: eth1 NIC Link is Up 100 Mbps Full duplex
ip_tables: (C) 2000-2002 Netfilter core team
Comment 13 Bugzilla owner 2004-09-30 11:39:14 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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