* ext3 on raid5 failure
@ 2004-01-18 10:27 Jan Dittmer
2004-01-18 18:02 ` Mike Fedyk
0 siblings, 1 reply; 24+ messages in thread
From: Jan Dittmer @ 2004-01-18 10:27 UTC (permalink / raw)
To: linux-kernel
Hello,
I've recently upgraded my fileserver to 2.6.1 and since then I had to
reboot two times because of the following errors. Afterwards the
blockdevice was set readonly, so I couldn't even remount the partition
rw. Interestingly after reboot the raid is not marked dirty. So is this
an ext3 only error?
This never happenend with 2.4.23pre6-aa3 or any other 2.4 version which
run for about a year on this system without any (linux caused) downtime.
What I can try to debug this? The first time it happened after about 3
or 4 days uptime, the second time after about 1 day. So it's pretty
reproducible.
Thanks,
Jan
EXT3-fs error (device dm-1): ext3_readdir: bad entry in directory
#9783034: rec_len % 4 != 0 - offset=0, inode=1846971784, rec_len=33046,
name_len=154
Aborting journal on device dm-1.
ext3_abort called.
EXT3-fs abort (device dm-1): ext3_journal_start: Detected aborted journal
Remounting filesystem read-only
and
EXT3-fs error (device dm-1): ext3_readdir: bad entry in directory
#8422045: rec_len % 4 != 0 - offset=0, inode=655393188, rec_len=1998,
name_len=0
Aborting journal on device dm-1.
ext3_abort called.
EXT3-fs abort (device dm-1): ext3_journal_start: Detected aborted journal
Remounting filesystem read-only
EXT3-fs error (device dm-1) in start_transaction: Journal has aborted
$ cat /proc/mdstat
Personalities : [raid5]
read_ahead 1024 sectors
md0 : active raid5 ide/host2/bus1/target1/lun0/part1[3]
ide/host2/bus1/target0/lun0/part1[1]
ide/host2/bus0/target1/lun0/part1[2]
ide/host2/bus0/target0/lun0/part1[0]
ide/host0/bus1/target0/lun0/part1[4]
468872704 blocks level 5, 4k chunk, algorithm 2 [5/5] [UUUUU]
$ vgdisplay:
--- Volume group ---
VG Name myraid
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 7
VG Access read/write
VG Status resizable
MAX LV 256
Cur LV 2
Open LV 2
Max PV 256
Cur PV 1
Act PV 1
VG Size 447.15 GB
PE Size 4.00 MB
Total PE 114470
Alloc PE / Size 114470 / 447.15 GB
Free PE / Size 0 / 0
VG UUID 0xPsvH-t204-YlD4-jVAW-mYgK-ndF5-nEVOTk
$ lvdisplay:
--- Logical volume ---
LV Name /dev/myraid/lvol0
VG Name myraid
LV UUID X47Raw-ZGgE-PZ4I-F1o3-lYX9-TVQ1-KIWqrs
LV Write Access read/write
LV Status available
# open 1
LV Size 100.00 GB
Current LE 25600
Segments 1
Allocation next free (default)
Read ahead sectors 0
Block device 254:1
--- Logical volume ---
LV Name /dev/myraid/lvol1
VG Name myraid
LV UUID LgnX1d-r3BP-3u7t-yLQb-iRke-544J-v7uBBd
LV Write Access read/write
LV Status available
# open 1
LV Size 347.15 GB
Current LE 88870
Segments 1
Allocation next free (default)
Read ahead sectors 0
Block device 254:2
$ mount -l
/dev/mapper/myraid-lvol1 on /mnt/data/1 type ext3 (rw)
/dev/mapper/myraid-lvol0 on /mnt/backup type ext3 (rw)
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: ext3 on raid5 failure
2004-01-18 10:27 ext3 on raid5 failure Jan Dittmer
@ 2004-01-18 18:02 ` Mike Fedyk
2004-01-19 15:30 ` Theodore Ts'o
0 siblings, 1 reply; 24+ messages in thread
From: Mike Fedyk @ 2004-01-18 18:02 UTC (permalink / raw)
To: Jan Dittmer; +Cc: linux-kernel
On Sun, Jan 18, 2004 at 11:27:54AM +0100, Jan Dittmer wrote:
> EXT3-fs error (device dm-1): ext3_readdir: bad entry in directory
> #9783034: rec_len % 4 != 0 - offset=0, inode=1846971784, rec_len=33046,
> name_len=154
> Aborting journal on device dm-1.
> ext3_abort called.
> EXT3-fs abort (device dm-1): ext3_journal_start: Detected aborted journal
> Remounting filesystem read-only
Run fsck on the filesystem.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-01-18 18:02 ` Mike Fedyk
@ 2004-01-19 15:30 ` Theodore Ts'o
2004-01-23 8:22 ` Jan Dittmer
2004-02-19 2:32 ` Leandro Guimarães Faria Corsetti Dutra
0 siblings, 2 replies; 24+ messages in thread
From: Theodore Ts'o @ 2004-01-19 15:30 UTC (permalink / raw)
To: Jan Dittmer, linux-kernel
On Sun, Jan 18, 2004 at 10:02:32AM -0800, Mike Fedyk wrote:
> On Sun, Jan 18, 2004 at 11:27:54AM +0100, Jan Dittmer wrote:
> > EXT3-fs error (device dm-1): ext3_readdir: bad entry in directory
> > #9783034: rec_len % 4 != 0 - offset=0, inode=1846971784, rec_len=33046,
> > name_len=154
> > Aborting journal on device dm-1.
> > ext3_abort called.
> > EXT3-fs abort (device dm-1): ext3_journal_start: Detected aborted journal
> > Remounting filesystem read-only
>
> Run fsck on the filesystem.
Jan, what distribution are you running? The superblock *should* have
been marked "filesystems has errors", and so fsck should have been
forced when you rebooted. Did fsck in fact run, and if so, did it
detect and fix any problems?
- Ted
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-01-19 15:30 ` Theodore Ts'o
@ 2004-01-23 8:22 ` Jan Dittmer
2004-01-27 19:08 ` Theodore Ts'o
2004-02-19 2:32 ` Leandro Guimarães Faria Corsetti Dutra
1 sibling, 1 reply; 24+ messages in thread
From: Jan Dittmer @ 2004-01-23 8:22 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]
Theodore Ts'o wrote:
> On Sun, Jan 18, 2004 at 10:02:32AM -0800, Mike Fedyk wrote:
>
>>On Sun, Jan 18, 2004 at 11:27:54AM +0100, Jan Dittmer wrote:
>>
>>>EXT3-fs error (device dm-1): ext3_readdir: bad entry in directory
>>>#9783034: rec_len % 4 != 0 - offset=0, inode=1846971784, rec_len=33046,
>>>name_len=154
>>>Aborting journal on device dm-1.
>>>ext3_abort called.
>>>EXT3-fs abort (device dm-1): ext3_journal_start: Detected aborted journal
>>>Remounting filesystem read-only
>>
>>Run fsck on the filesystem.
>
>
> Jan, what distribution are you running? The superblock *should* have
> been marked "filesystems has errors", and so fsck should have been
> forced when you rebooted. Did fsck in fact run, and if so, did it
> detect and fix any problems?
>
> - Ted
Okay, I fscked all filesystems in single user mode, thereby fscked up my
root filesystem, though I didn't even check it - so I restored it from
backup (grub wouldn't even load anymore).
After 2 days in my freshly setup debian (2.6.1-bk6), same error. But
this time at least I know it's because I tried to delete those files in
the lost+found directory...
So, how do I delete these and why did fsck fail? It's pretty annoying to
reboot because of this. It would be nice to just being able to
remount,rw the partition.
Thanks,
Jan
EXT3-fs error (device dm-2): ext3_readdir: directory #16370 contains a
hole at offset 8192
Aborting journal on device dm-2.
EXT3-fs error (device dm-2): ext3_readdir: directory #16370 contains a
hole at offset 24576
ext3_abort called.
EXT3-fs abort (device dm-2): ext3_journal_start: Detected aborted journal
Remounting filesystem read-only
[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-01-23 8:22 ` Jan Dittmer
@ 2004-01-27 19:08 ` Theodore Ts'o
2004-01-28 10:54 ` Jan Dittmer
2004-01-28 11:06 ` Jan Dittmer
0 siblings, 2 replies; 24+ messages in thread
From: Theodore Ts'o @ 2004-01-27 19:08 UTC (permalink / raw)
To: Jan Dittmer; +Cc: linux-kernel
On Fri, Jan 23, 2004 at 09:22:25AM +0100, Jan Dittmer wrote:
>
> Okay, I fscked all filesystems in single user mode, thereby fscked up my
> root filesystem, though I didn't even check it - so I restored it from
> backup (grub wouldn't even load anymore).
What messages were printed by e2fsck while it was running --- and was
all of the filesystems unmounted, excepted for the root filesystem,
which should have been mounted read-only?
> After 2 days in my freshly setup debian (2.6.1-bk6), same error. But
> this time at least I know it's because I tried to delete those files in
> the lost+found directory...
How did you come to that conclusion?
> So, how do I delete these and why did fsck fail? It's pretty annoying to
> reboot because of this. It would be nice to just being able to
> remount,rw the partition.
How did fsck fail? Without a transcript of the fsck output, it's hard
to say exactly what happened here.
An output of dumpe2fs of the filesystem in question would also be useful.
- Ted
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-01-27 19:08 ` Theodore Ts'o
@ 2004-01-28 10:54 ` Jan Dittmer
2004-01-29 11:44 ` Theodore Ts'o
2004-01-28 11:06 ` Jan Dittmer
1 sibling, 1 reply; 24+ messages in thread
From: Jan Dittmer @ 2004-01-28 10:54 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 4522 bytes --]
Theodore Ts'o wrote:
> On Fri, Jan 23, 2004 at 09:22:25AM +0100, Jan Dittmer wrote:
>
>>Okay, I fscked all filesystems in single user mode, thereby fscked up my
>>root filesystem, though I didn't even check it - so I restored it from
>>backup (grub wouldn't even load anymore).
>
>
> What messages were printed by e2fsck while it was running --- and was
> all of the filesystems unmounted, excepted for the root filesystem,
> which should have been mounted read-only?
>
Yep it was all unmounted. But I don't have a transcript of this session.
I was directly logged in, sorry.
>
>>After 2 days in my freshly setup debian (2.6.1-bk6), same error. But
>>this time at least I know it's because I tried to delete those files in
>>the lost+found directory...
>
>
> How did you come to that conclusion?
sfhq:/mnt/data/1/lost+found# ls -l
total 76
d-wSr----- 2 1212680233 136929556 49152 Jun 7 2008 #16370
-rwx-wx--- 1 1628702729 135220664 45056 May 4 1974 #16380
sfhq:/mnt/data/1/lost+found# rm *
rm: cannot remove `#16370': Operation not permitted
rm: cannot remove `#16380': Operation not permitted
sfhq:/mnt/data/1/lost+found# rm *
rm: cannot remove `#16370': Operation not permitted
rm: cannot remove `#16380': Operation not permitted
sfhq:/mnt/data/1/lost+found# rm *
rm: cannot remove `#16370': Operation not permitted
rm: cannot remove `#16380': Operation not permitted
sfhq:/mnt/data/1/lost+found# dmesg
EXT3-fs error (device dm-2): ext3_readdir: directory #16370 contains a
hole at offset 8192
Aborting journal on device dm-2.
EXT3-fs error (device dm-2): ext3_readdir: directory #16370 contains a
hole at offset 24576
ext3_abort called.
EXT3-fs abort (device dm-2): ext3_journal_start: Detected aborted journal
Remounting filesystem read-only
This is with 2.6.1-bk6 and no concurrent access. With 2.4.25-pre7-pac1
this does not happen.
So I rechecked the filesystem (with 2.4), hoping it won't get corrupted
and I would be able to delete the files, but:
sfhq:~# fsck /dev/myraid/lvol1
fsck 1.35-WIP (07-Dec-2003)
e2fsck 1.35-WIP (07-Dec-2003)
/dev/myraid/lvol1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 16370 has an unallocated block #2. Allocate<y>? yes
Directory inode 16370 has an unallocated block #6. Allocate<y>? yes
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/myraid/lvol1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/myraid/lvol1: 2341/45514752 files (24.0% non-contiguous),
82194611/91002880 blocks
still no luck with undeleting these files
sfhq:/mnt/data/1/lost+found# rm -rf *
rm: cannot remove directory `#16370': Operation not permitted
rm: cannot remove `#16380': Operation not permitted
sfhq:/mnt/data# dumpe2fs /dev/myraid/lvol1
dumpe2fs 1.35-WIP (07-Dec-2003)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: ba3f83cd-04c8-4c4d-82f7-990077aabb73
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal dir_index needs_recovery sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 45514752
Block count: 91002880
Reserved block count: 3640115
Free blocks: 8808269
Free inodes: 45512411
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 16384
Inode blocks per group: 512
Filesystem created: Thu Jul 3 13:57:02 2003
Last mount time: Wed Jan 28 11:48:13 2004
Last write time: Wed Jan 28 11:48:13 2004
Mount count: 2
Maximum mount count: 23
Last checked: Wed Jan 28 11:47:06 2004
Check interval: 15552000 (6 months)
Next check after: Mon Jul 26 12:47:06 2004
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: a7fd0c53-efe9-4316-9fa6-e3206623f4fe
Journal backup: inode blocks
Do you need the complete output? Btw. I have the same error on another
partition (also on raid5, dm).
Thanks,
Jan
[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-01-28 10:54 ` Jan Dittmer
@ 2004-01-29 11:44 ` Theodore Ts'o
2004-02-04 9:24 ` Bas Mevissen
0 siblings, 1 reply; 24+ messages in thread
From: Theodore Ts'o @ 2004-01-29 11:44 UTC (permalink / raw)
To: Jan Dittmer; +Cc: linux-kernel
On Wed, Jan 28, 2004 at 11:54:44AM +0100, Jan Dittmer wrote:
> >>After 2 days in my freshly setup debian (2.6.1-bk6), same error. But
> >>this time at least I know it's because I tried to delete those files in
> >>the lost+found directory...
> >
> >
> >How did you come to that conclusion?
>
> sfhq:/mnt/data/1/lost+found# ls -l
> total 76
> d-wSr----- 2 1212680233 136929556 49152 Jun 7 2008 #16370
> -rwx-wx--- 1 1628702729 135220664 45056 May 4 1974 #16380
Ok, this looks like random garbage has gotten written into inode table.
If you can make this happen consistently with 2.6 and not with 2.4,
then that would be useful to know. There may be some kind of race
condition or problem with either the raid5 code, or the combination of
raid5 plus ext3. It's unlikely this kind of error would be caused by
a flaw in the ext3 code alone, since this is indicative of complete
garbage written to the inode table, or a block intended for another
location on disk getting written to the inode table. The natural
suspect is at the block device layer and below.
- Ted
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-01-29 11:44 ` Theodore Ts'o
@ 2004-02-04 9:24 ` Bas Mevissen
2004-02-04 9:43 ` Nigel Cunningham
2004-02-06 19:18 ` Theodore Ts'o
0 siblings, 2 replies; 24+ messages in thread
From: Bas Mevissen @ 2004-02-04 9:24 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Jan Dittmer, linux-kernel
Theodore Ts'o wrote:
>
>>
>>sfhq:/mnt/data/1/lost+found# ls -l
>>total 76
>>d-wSr----- 2 1212680233 136929556 49152 Jun 7 2008 #16370
>>-rwx-wx--- 1 1628702729 135220664 45056 May 4 1974 #16380
>
>
> Ok, this looks like random garbage has gotten written into inode table.
>
> If you can make this happen consistently with 2.6 and not with 2.4,
> then that would be useful to know. There may be some kind of race
> condition or problem with either the raid5 code, or the combination of
> raid5 plus ext3. It's unlikely this kind of error would be caused by
> a flaw in the ext3 code alone, since this is indicative of complete
> garbage written to the inode table, or a block intended for another
> location on disk getting written to the inode table. The natural
> suspect is at the block device layer and below.
>
I've seen this kind of problems on my notebook too. Among others, over
600MB of a huge cache directory (from a news reader) was having "funny"
permissions. Maybe more files were affected. I used fsck.ext3 and
changed the attributes with chmod.
It may be caused by crashes of the notebook (power failure and
suspend/resume failure), but I would expect that the administration of
the fs would survive that, as it did for years. Actually, the last time
I had filesystem corruption was in kernel 1.2.xx days...
As my notebook is not using raid, I suspect something in the ext3 code.
Kernel is 2.6.1 with ACPI, acpi-dsdt and swsusp2 patches.
Regards,
Bas.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-02-04 9:24 ` Bas Mevissen
@ 2004-02-04 9:43 ` Nigel Cunningham
2004-02-04 11:38 ` Bas Mevissen
2004-02-06 19:18 ` Theodore Ts'o
1 sibling, 1 reply; 24+ messages in thread
From: Nigel Cunningham @ 2004-02-04 9:43 UTC (permalink / raw)
To: Bas Mevissen; +Cc: Theodore Ts'o, Jan Dittmer, Linux Kernel Mailing List
Hi.
Are you using a swap partition or swap file? If we're talking swap file,
I would suspect suspend2. I haven't had a chance to look yet (preparing
to move to Aussie), but Michael has told me there are problems with the
swapfile support.
If you had a crash while using suspend and swap file support, I wouldn't
be totally surprised to see an emergency sync causing this. That said,
the code has a number of safety nets aimed at stopping us syncing while
suspend is running, to avoid precisely this sort of corruption. If it
was suspend, I'd expect your superblock to have been messed too. Did
that happen?
Regards,
Nigel
On Wed, 2004-02-04 at 22:24, Bas Mevissen wrote:
> Theodore Ts'o wrote:
> >
> >>
> >>sfhq:/mnt/data/1/lost+found# ls -l
> >>total 76
> >>d-wSr----- 2 1212680233 136929556 49152 Jun 7 2008 #16370
> >>-rwx-wx--- 1 1628702729 135220664 45056 May 4 1974 #16380
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-02-04 9:43 ` Nigel Cunningham
@ 2004-02-04 11:38 ` Bas Mevissen
2004-02-04 20:49 ` Nigel Cunningham
0 siblings, 1 reply; 24+ messages in thread
From: Bas Mevissen @ 2004-02-04 11:38 UTC (permalink / raw)
To: ncunningham; +Cc: Theodore Ts'o, Jan Dittmer, Linux Kernel Mailing List
Nigel Cunningham wrote:
> Hi.
>
> Are you using a swap partition or swap file? If we're talking swap file,
> I would suspect suspend2. I haven't had a chance to look yet (preparing
> to move to Aussie), but Michael has told me there are problems with the
> swapfile support.
>
You are reading everything, I beleave :-)
Nope, only a swap partition. I read swsusp ML too :-)
I really suspect the power failure (forgot to plug in the AC adapter :-)
) was the "hard off" with the FS corruption.
> If you had a crash while using suspend and swap file support, I wouldn't
> be totally surprised to see an emergency sync causing this. That said,
> the code has a number of safety nets aimed at stopping us syncing while
> suspend is running, to avoid precisely this sort of corruption. If it
> was suspend, I'd expect your superblock to have been messed too. Did
> that happen?
>
The superblock was fine. There was just a short file system check when
booting again. I only noticed it a day later when the news reader didn't
want to start anymore.
But thanks for thinking!
Regards,
Bas.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-02-04 11:38 ` Bas Mevissen
@ 2004-02-04 20:49 ` Nigel Cunningham
2004-02-17 23:14 ` Pavel Machek
0 siblings, 1 reply; 24+ messages in thread
From: Nigel Cunningham @ 2004-02-04 20:49 UTC (permalink / raw)
To: Bas Mevissen; +Cc: Theodore Ts'o, Jan Dittmer, Linux Kernel Mailing List
On Thu, 2004-02-05 at 00:38, Bas Mevissen wrote:
> You are reading everything, I beleave :-)
Not everything! I have my email client set up to highlight messages that
mention suspend or swsusp. :>
Nigel
> The superblock was fine. There was just a short file system check when
> booting again. I only noticed it a day later when the news reader didn't
> want to start anymore.
Okay. Apparently not suspend related then.
> But thanks for thinking!
You're welcome.
Nigel
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-02-04 20:49 ` Nigel Cunningham
@ 2004-02-17 23:14 ` Pavel Machek
2004-02-17 23:58 ` Kiko Piris
0 siblings, 1 reply; 24+ messages in thread
From: Pavel Machek @ 2004-02-17 23:14 UTC (permalink / raw)
To: Nigel Cunningham
Cc: Bas Mevissen, Theodore Ts'o, Jan Dittmer,
Linux Kernel Mailing List
Hi!
> Not everything! I have my email client set up to highlight messages that
> mention suspend or swsusp. :>
Clever ;-). [How does one do that in mutt?]
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-02-17 23:14 ` Pavel Machek
@ 2004-02-17 23:58 ` Kiko Piris
0 siblings, 0 replies; 24+ messages in thread
From: Kiko Piris @ 2004-02-17 23:58 UTC (permalink / raw)
To: Pavel Machek
Cc: Nigel Cunningham, Bas Mevissen, Theodore Ts'o, Jan Dittmer,
Linux Kernel Mailing List
On 18/02/2004 at 00:14, Pavel Machek wrote:
> > Not everything! I have my email client set up to highlight messages that
> > mention suspend or swsusp. :>
>
> Clever ;-). [How does one do that in mutt?]
color index yellow black '(~b suspend | ~b swsusp)'
But if you use remote mailboxes (such as imap or pop) this sucks. So
it's better to put something like:
folder-hook . "uncolor index *"
folder-hook . "color index yellow black '(~b suspend | ~b swsusp)'"
folder-hook ^imaps?:// "uncolor index *"
folder-hook ^pops?:// "uncolor index *"
in your .muttrc to avoid downloading _all_ message bodies in the index
when reading imap(s) or pop(s) mailboxes.
--
Kiko
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-02-04 9:24 ` Bas Mevissen
2004-02-04 9:43 ` Nigel Cunningham
@ 2004-02-06 19:18 ` Theodore Ts'o
2004-02-09 8:55 ` Bas Mevissen
1 sibling, 1 reply; 24+ messages in thread
From: Theodore Ts'o @ 2004-02-06 19:18 UTC (permalink / raw)
To: Bas Mevissen; +Cc: Jan Dittmer, linux-kernel
On Wed, Feb 04, 2004 at 10:24:55AM +0100, Bas Mevissen wrote:
> I've seen this kind of problems on my notebook too. Among others, over
> 600MB of a huge cache directory (from a news reader) was having "funny"
> permissions. Maybe more files were affected. I used fsck.ext3 and
> changed the attributes with chmod.
Was it just the permissions screwy? Was the contents of these files
with the "funny" permission sane, or did they contain garbage? What
about the modtime of the files?
In the original bug report random garbage had gotten written into the
inode table. That sort of failure is generally caused at a level
below that of the filesystem (i.e., device driver or hardware).
The question is whether the problems you are seeing seem to be caused
by wholesale corruption of an entire block of the inode table, or is
some other kind of problem. For example, if only the permissions are
getting screwed up, when the rest of the inode data is correct, then
yes, it would most likely be a filesystem bug. I haven't noticed any
such problem myself, but it's possible that something like that might
be going on. On the other hand, if it is an entire block in the inode
table getting corrupted then I'd be less likely to presume it to be a
filesystem flaw.
- Ted
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-02-06 19:18 ` Theodore Ts'o
@ 2004-02-09 8:55 ` Bas Mevissen
2004-02-18 3:07 ` Bill Davidsen
0 siblings, 1 reply; 24+ messages in thread
From: Bas Mevissen @ 2004-02-09 8:55 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Jan Dittmer, linux-kernel
Theodore Ts'o wrote:
>
> Was it just the permissions screwy? Was the contents of these files
> with the "funny" permission sane, or did they contain garbage? What
> about the modtime of the files?
>
Only permissions. Something like r-Sr-S--- . File contents were OK.
> The question is whether the problems you are seeing seem to be caused
> by wholesale corruption of an entire block of the inode table, or is
> some other kind of problem. For example, if only the permissions are
> getting screwed up, when the rest of the inode data is correct, then
> yes, it would most likely be a filesystem bug. I haven't noticed any
> such problem myself, but it's possible that something like that might
> be going on. On the other hand, if it is an entire block in the inode
> table getting corrupted then I'd be less likely to presume it to be a
> filesystem flaw.
>
It looks like this only appeared once. The FS looks fine now. So I guess
I won't be able to reproduce it. Let's just go to 2.6.[23] and see if
it happens again.
Regards,
Bas.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-02-09 8:55 ` Bas Mevissen
@ 2004-02-18 3:07 ` Bill Davidsen
2004-02-19 9:27 ` Bas Mevissen
0 siblings, 1 reply; 24+ messages in thread
From: Bill Davidsen @ 2004-02-18 3:07 UTC (permalink / raw)
To: Bas Mevissen; +Cc: Theodore Ts'o, Jan Dittmer, linux-kernel
Bas Mevissen wrote:
> Theodore Ts'o wrote:
>
>>
>> Was it just the permissions screwy? Was the contents of these files
>> with the "funny" permission sane, or did they contain garbage? What
>> about the modtime of the files?
>>
>
> Only permissions. Something like r-Sr-S--- . File contents were OK.
>
>> The question is whether the problems you are seeing seem to be caused
>> by wholesale corruption of an entire block of the inode table, or is
>> some other kind of problem. For example, if only the permissions are
>> getting screwed up, when the rest of the inode data is correct, then
>> yes, it would most likely be a filesystem bug. I haven't noticed any
>> such problem myself, but it's possible that something like that might
>> be going on. On the other hand, if it is an entire block in the inode
>> table getting corrupted then I'd be less likely to presume it to be a
>> filesystem flaw.
>>
>
> It looks like this only appeared once. The FS looks fine now. So I guess
> I won't be able to reproduce it. Let's just go to 2.6.[23] and see if
> it happens again.
Did this go away on reboot, or did you have to fix it? If it went away
on reboot, it could be that the copy of the inode in memory was borked.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-02-18 3:07 ` Bill Davidsen
@ 2004-02-19 9:27 ` Bas Mevissen
2004-02-19 19:47 ` Bill Davidsen
0 siblings, 1 reply; 24+ messages in thread
From: Bas Mevissen @ 2004-02-19 9:27 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Theodore Ts'o, Jan Dittmer, linux-kernel
Bill Davidsen wrote:
>
>> It looks like this only appeared once. The FS looks fine now. So I guess
>> I won't be able to reproduce it. Let's just go to 2.6.[23] and see if
>> it happens again.
>
> Did this go away on reboot, or did you have to fix it? If it went away
> on reboot, it could be that the copy of the inode in memory was borked.
>
I really had to fix it. But, it never appeared again until now. So maybe
this was just caused by some crash while experimenting with swsusp2.
Regards,
Bas.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-02-19 9:27 ` Bas Mevissen
@ 2004-02-19 19:47 ` Bill Davidsen
0 siblings, 0 replies; 24+ messages in thread
From: Bill Davidsen @ 2004-02-19 19:47 UTC (permalink / raw)
To: Bas Mevissen; +Cc: Theodore Ts'o, Jan Dittmer, linux-kernel
On Thu, 19 Feb 2004, Bas Mevissen wrote:
> Bill Davidsen wrote:
> >
> >> It looks like this only appeared once. The FS looks fine now. So I guess
> >> I won't be able to reproduce it. Let's just go to 2.6.[23] and see if
> >> it happens again.
> >
> > Did this go away on reboot, or did you have to fix it? If it went away
> > on reboot, it could be that the copy of the inode in memory was borked.
> >
>
> I really had to fix it. But, it never appeared again until now. So maybe
> this was just caused by some crash while experimenting with swsusp2.
Another WAG bites the dust, but at least it's clear that you had damage to
the metadata on the media. Hopefully that would be useful if it comes back
to visit again.
Glad you COULD fix it!
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-01-27 19:08 ` Theodore Ts'o
2004-01-28 10:54 ` Jan Dittmer
@ 2004-01-28 11:06 ` Jan Dittmer
1 sibling, 0 replies; 24+ messages in thread
From: Jan Dittmer @ 2004-01-28 11:06 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
Theodore Ts'o wrote:
> On Fri, Jan 23, 2004 at 09:22:25AM +0100, Jan Dittmer wrote:
>
>>Okay, I fscked all filesystems in single user mode, thereby fscked up my
>>root filesystem, though I didn't even check it - so I restored it from
>>backup (grub wouldn't even load anymore).
>
>
> What messages were printed by e2fsck while it was running --- and was
> all of the filesystems unmounted, excepted for the root filesystem,
> which should have been mounted read-only?
>
>
>>After 2 days in my freshly setup debian (2.6.1-bk6), same error. But
>>this time at least I know it's because I tried to delete those files in
>>the lost+found directory...
>
>
> How did you come to that conclusion?
Argh, sorry, after chattr -aI the files could be deleted. sorry for the
noise.
Jan
[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-01-19 15:30 ` Theodore Ts'o
2004-01-23 8:22 ` Jan Dittmer
@ 2004-02-19 2:32 ` Leandro Guimarães Faria Corsetti Dutra
2004-02-19 8:07 ` Jan Dittmer
1 sibling, 1 reply; 24+ messages in thread
From: Leandro Guimarães Faria Corsetti Dutra @ 2004-02-19 2:32 UTC (permalink / raw)
To: linux-kernel
On Mon, 19 Jan 2004 10:30:05 -0500, Theodore Ts'o wrote:
>> On Sun, Jan 18, 2004 at 11:27:54AM +0100, Jan Dittmer wrote:
>> > EXT3-fs error (device dm-1): ext3_readdir: bad entry in directory
>> > #9783034: rec_len % 4 != 0 - offset=0, inode=1846971784,
>> > rec_len=33046, name_len=154
>> > Aborting journal on device dm-1.
>> > ext3_abort called.
>> > EXT3-fs abort (device dm-1): ext3_journal_start: Detected aborted
>> > journal Remounting filesystem read-only
Has this been resolved? I have a machine due to enter production, am
considering going back to 2.4 if there is no further information.
--
Leandro Guimarães Faria Corsetti Dutra +55 (11) 5685 2219
Av Sgto Geraldo Santana, 1100 6/71 +55 (11) 5686 9607
04.674-000 São Paulo, SP BRASIL
http://br.geocities.com./lgcdutra/
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-02-19 2:32 ` Leandro Guimarães Faria Corsetti Dutra
@ 2004-02-19 8:07 ` Jan Dittmer
2004-02-19 13:50 ` Leandro Guimarães Faria Corcete Dutra
0 siblings, 1 reply; 24+ messages in thread
From: Jan Dittmer @ 2004-02-19 8:07 UTC (permalink / raw)
To: �; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]
Leandro Guimarães Faria Corsetti Dutra wrote:
> On Mon, 19 Jan 2004 10:30:05 -0500, Theodore Ts'o wrote:
>
>
>>>On Sun, Jan 18, 2004 at 11:27:54AM +0100, Jan Dittmer wrote:
>>>
>>>>EXT3-fs error (device dm-1): ext3_readdir: bad entry in directory
>>>>#9783034: rec_len % 4 != 0 - offset=0, inode=1846971784,
>>>>rec_len=33046, name_len=154
>>>>Aborting journal on device dm-1.
>>>>ext3_abort called.
>>>>EXT3-fs abort (device dm-1): ext3_journal_start: Detected aborted
>>>>journal Remounting filesystem read-only
>
>
> Has this been resolved? I have a machine due to enter production, am
> considering going back to 2.4 if there is no further information.
>
>
I haven't tried it with 2.6 since this incident. But considering that
the machine in question crashed a couple of times afterwards, it may
well be, that a hardware fault caused this initially. But I simply don't
dare to put 2.6 again on this machine as I've no real backup of most of
the data, and restoring some 100 gb from cds is really annoying.
Jan
[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
2004-02-19 8:07 ` Jan Dittmer
@ 2004-02-19 13:50 ` Leandro Guimarães Faria Corcete Dutra
2004-02-19 14:58 ` Leandro Guimarães Faria Corsetti Dutra
0 siblings, 1 reply; 24+ messages in thread
From: Leandro Guimarães Faria Corcete Dutra @ 2004-02-19 13:50 UTC (permalink / raw)
To: Jan Dittmer; +Cc: linux-kernel
Em Qui, 2004-02-19 às 05:07, Jan Dittmer escreveu:
> Leandro Guimarães Faria Corsetti Dutra wrote:
> >>>On Sun, Jan 18, 2004 at 11:27:54AM +0100, Jan Dittmer wrote:
> >>>>EXT3-fs error (device dm-1): ext3_readdir: bad entry in directory
> >>>>#9783034: rec_len % 4 != 0 - offset=0, inode=1846971784,
> >>>>rec_len=33046, name_len=154
> >>>>Aborting journal on device dm-1.
> >>>>ext3_abort called.
> >>>>EXT3-fs abort (device dm-1): ext3_journal_start: Detected aborted
> >>>>journal Remounting filesystem read-only
> >
> > Has this been resolved? I have a machine due to enter production, am
> > considering going back to 2.4 if there is no further information.
>
> I haven't tried it with 2.6 since this incident. But considering that
> the machine in question crashed a couple of times afterwards, it may
> well be, that a hardware fault caused this initially.
I don't believe so, because I have already run both memtest86 (all
tests, a dozen passes) and cpuburn (burnP6, several hours). I am now
trying to figure out how to run fsx-linux, documentation seems scarce.
> But I simply don't
> dare to put 2.6 again on this machine as I've no real backup of most of
> the data, and restoring some 100 gb from cds is really annoying.
That's the position I think I will have to face. A pity, I was already
hooked into 2.6's speed and LVM2.
--
Leandro Guimarães Faria Corcete Dutra
Maringá, PR, BRASIL +55 (11) 5685 2219
http://br.geocities.com./lgcdutra/ +55 (44) 3028 7467
Soli Deo Gloria! +55 (44) 3028 8335
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ext3 on raid5 failure
@ 2004-02-25 17:45 Muhammad L.
0 siblings, 0 replies; 24+ messages in thread
From: Muhammad L. @ 2004-02-25 17:45 UTC (permalink / raw)
To: linux-kernel; +Cc: muhammad
Dear all, (please Cc: me in the answer)
Sorry to interrupt but the problem isn't fixed at all.
I get exactly the same problem with the 2.6.0 test serie and final 2.6.0
and got so sick of the problem that I downgraded back to 2.4.x.
It happens EVERYTIME I do a lot of IO (e.g. copy big files (> 600 megs
around), it is systematic. I never had this problem under 2.4.x and I am
so sad I am going to downgrade to 2.4.24/25 tonight.
I am in the mood I might reproduce the problem again and log the output
of fsck -C -y (takes ages to fsck a 270meg partition)
I have 1 gig of ram, a amd xp2500+ at 1800ghz (not overclocked),
currently my raid5 fs contains 274 gigs and the problem under 2.6 was
present from the very begining. My raid5 setup is a 4x120Gig each on a
separate controler. Again under 2.4 this machine works perfectly and I
have copied 100 gig of DV materials around without problems.
Recently when evms 2.2.2 was released I installed a 2.6.3 and tried
again.
Thanks and regards,
Muhammad
Here is the most recent dmesg and the initial bug report I prepared and
forgot to post on the kernel mailing at the time (mea culpa, mea
culpa...)
EXT3-fs error (device dm-2): ext3_readdir: bad entry in directory
#35160065: directory entry across blocks - offset=0, inode=1836597052,
rec_len=8300, name_len=118
EXT3-fs error (device dm-2) in start_transaction: Journal has aborted
EXT3-fs error (device dm-2) in start_transaction: Journal has aborted
EXT3-fs error (device dm-2) in start_transaction: Journal has aborted
EXT3-fs error (device dm-2) in start_transaction: Journal has aborted
EXT3-fs error (device dm-2) in start_transaction: Journal has aborted
EXT3-fs error (device dm-2) in start_transaction: Journal has aborted
EXT3-fs error (device dm-2) in start_transaction: Journal has aborted
EXT3-fs error (device dm-2) in start_transaction: Journal has aborted
EXT3-fs error (device dm-2): ext3_readdir: bad entry in directory
#35160065: directory entry across blocks - offset=0, inode=1836597052,
rec_len=8300, name_len=118
EXT3-fs error (device dm-2) in start_transaction: Journal has aborted
EXT3-fs error (device dm-2) in start_transaction: Journal has aborted
EXT3-fs error (device dm-2) in start_transaction: Journal has aborted
[1.] One line summary of the problem:
2.6.3-mm1 + evms 2.2.2 patches, 2.6.0-test9 + evms 2.1.1/2.2.0 patches:
Ext3 fs corruption and journal abortion when writing big files to md
device.
[2.] Full description of the problem/report:
Simple stress test (dd if=/dev/zero of=swapfile bs=1024 count=1048576 #
1Gb) will crash my raid-5 md partition
under 2.6.0-test9 + evms 2.1.1 or 2.2.0 patches (2.6.0-test9-dm4 or
2.6.0-test9-udm5). Under 2.4.22 and its
evms 2.x patches on the same machine, the same operation works perfectly
(copied 100 gig from a normal partition
to the raid-5 md. Applying linus-patch from test9-mm3 which is supposed
to fix a related problem doesn't solve
the issue and it only makes the dmesg output less verbose.
I tried running a 2.6.0-test9 with evms 2.1.1 or 2.2.0 patches, I get
ext3 corruption under fs load (e.g. creation of a
1gig file). Using 2.4.22 + evms patches works perfect.
[3.] Keywords (i.e., modules, networking, kernel):
2.6.0 test9 evms ext3 fs corruption md raid journal
__journal_remove_journal_head ext3_readdir
[4.] Kernel version (from /proc/version):
Kernel version:
(Oh by the way, yes it is a gentoo distribution but a stable branch and
no fancy CFLAGS and also it is not a gentoo kernel, just a vanilla one
straight from kernel.org)
Linux version 2.6.3 (root@dis) (gcc version 3.3.2 20031218 (Gentoo Linux
3.3.2-r5, propolice-3.3-7)) #1 Wed Feb 18 20:14:27 WIT 2004
Linux version 2.6.0-test9 (root@dis) (gcc version 3.2.3 20030422 (Gentoo
Linux 1.4 3.2.3-r2, propolice)) #4 Fri Nov
14 04:58:11 WIT 2003
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
hdb: hdb1 hdb2
hdb: hdb1 hdb2
Adding 257000k swap on /dev/evms/hdb1. Priority:-1 extents:1
EXT3-fs error (device dm-8): ext3_readdir: bad entry in directory
#35536897: rec_len is smaller than minimal - offset=0, inode=0,
rec_len=0, name_len=0
Aborting journal on device dm-8.
ext3_abort called.
EXT3-fs abort (device dm-8): ext3_journal_start: Detected aborted
journal
Remounting filesystem read-only
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in ext3_ordered_writepage: IO failure
ext3_try_to_allocate: aborting transaction: Journal has aborted in
__ext3_journal_get_undo_access<2>EXT3-fs error (device dm-8) in
ext3_new_block: Journal has aborted
EXT3-fs error (device dm-8) in ext3_prepare_write: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
Assertion failure in __journal_remove_journal_head() at
fs/jbd/journal.c:1733: "!jh->b_committed_data"
------------[ cut here ]------------
kernel BUG at fs/jbd/journal.c:1733!
invalid operand: 0000 [#1]
CPU: 0
EIP: 0060:[<c01a0d41>] Tainted: PF
EFLAGS: 00010286
EIP is at __journal_remove_journal_head+0xf5/0x1b4
eax: 0000006a ebx: dccb6528 ecx: c1bfecc0 edx: c040cdd8
esi: d7a2efc0 edi: 00000000 ebp: c1bf9d8c esp: c1bf9d70
ds: 007b es: 007b ss: 0068
Process kjournald (pid: 29, threadinfo=c1bf8000 task=c1bfecc0)
Stack: c03a5740 c038d837 c03a2731 000006c5 c03a2531 c1bf8000 dccb6528
c1bf9d9c
c01a0e1f dccb6528 c1bf8000 c1bf9db0 c019b80e dccb6528 d7a2efc0
f785c480
c1bf9f60 c019bd28 f6a44380 d7a2efc0 c1bf9e54 000017b6 f8ab8037
f6a443dc
Call Trace:
[<c01a0e1f>] journal_remove_journal_head+0x1f/0x3d
[<c019b80e>] journal_refile_buffer+0x3c/0x67
[<c019bd28>] journal_commit_transaction+0x426/0x12f6
[<f8ab8037>] __nvsym02561+0x4f/0x6c [nvidia]
[<c011f4b4>] autoremove_wake_function+0x0/0x4b
[<f8ac29aa>] __nvsym00830+0x12/0x18 [nvidia]
[<c011f4b4>] autoremove_wake_function+0x0/0x4b
[<c019ee21>] kjournald+0xc4/0x251
[<c011f4b4>] autoremove_wake_function+0x0/0x4b
[<c011f4b4>] autoremove_wake_function+0x0/0x4b
[<c010b226>] ret_from_fork+0x6/0x14
[<c019ed4c>] commit_timeout+0x0/0xc
[<c019ed5d>] kjournald+0x0/0x251
[<c01092a5>] kernel_thread_helper+0x5/0xb
Code: 0f 0b c5 06 31 27 3a c0 eb a0 c7 44 24 10 47 25 3a c0 c7 44
<6>note: kjournald[29] exited with preempt_count 2
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
EXT3-fs error (device dm-8) in start_transaction: Journal has aborted
root@dis:/#
Code disassembly:
0x80493f4 <str>: ud2a
0x80493f6 <str+2>: lds (%esi),%eax
0x80493f8 <str+4>: xor %esp,(%edi)
0x80493fa <str+6>: cmp %al,%al
0x80493fc <str+8>: jmp 0x804939e
0x80493fe <str+10>: movl $0xc03a2547,0x10(%esp,1)
0x8049406 <str+18>: movl $0x10000,0x0(%eax,%eax,1)
code disassembly from the test9 + linus.patch (mm3), it doesn't output
an oops but still fails.
0xc01a0d77 <__journal_remove_journal_head+299>: ud2a
0xc01a0d79 <__journal_remove_journal_head+301>: les (%esi),%eax
0xc01a0d7b <__journal_remove_journal_head+303>: xor %esp,(%edi)
0xc01a0d7d <__journal_remove_journal_head+305>: cmp %al,%al
0xc01a0d7f <__journal_remove_journal_head+307>: jmp 0xc01a0ce4
<__journal_remove_journal_head+152>
0xc01a0d84 <__journal_remove_journal_head+312>: movl
$0xc03a280a,0x10(%esp,1)
0xc01a0d8c <__journal_remove_journal_head+320>: movl
$0x6c1,0xc(%esp,1)
0xc01a0d94 <__journal_remove_journal_head+328>: movl
$0xc03a2731,0x8(%esp,1)
0xc01a0d9c <__journal_remove_journal_head+336>: movl
$0xc038d837,0x4(%esp,1)
0xc01a0da4 <__journal_remove_journal_head+344>: movl
$0xc03a5740,(%esp,1)
[6.] A small shell script or example program which triggers the
problem (if possible)
dd if=/dev/zero of=swapfile bs=1024 count=1048576 # 1Gb
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Gnu C 3.2.3
Gnu make 3.80
util-linux 2.11z
mount 2.11z
module-init-tools 0.9.12
e2fsprogs 1.33
jfsutils 1.1.2
PPP 2.4.1
nfs-utils 1.0.6
Linux C Library 2.3.2
Dynamic linker (ldd) 2.3.2
Procps 3.1.9
Net-tools 1.60
Kbd 1.06
Sh-utils 5.0
Modules Loaded XXX
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : AMD Athlon(tm) XP 2500+
stepping : 0
cpu MHz : 1830.150
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow
bogomips : 3643.80
7.3.] Module information (from /proc/modules):
loop 12296 0 - Live 0xf9e0e000
rfcomm 34716 3 - Live 0xf8d17000
ipt_state 1472 32 - Live 0xf8a0e000
ipt_LOG 5056 23 - Live 0xf8a63000
iptable_filter 2176 1 - Live 0xf88cf000
ipt_MASQUERADE 2816 5 - Live 0xf88d3000
iptable_nat 19500 2 ipt_MASQUERADE, Live 0xf8ca1000
ip_conntrack 27312 3 ipt_state,ipt_MASQUERADE,iptable_nat, Live
0xf8c88000
ip_tables 16064 5
ipt_state,ipt_LOG,iptable_filter,ipt_MASQUERADE,iptable_nat, Live
0xf8a5e000
ipv6 231936 842 - Live 0xf8ccc000
snd_ens1370 15076 0 - Live 0xf8a59000
snd_ak4531_codec 6848 1 snd_ens1370, Live 0xf88c6000
snd_ens1371 19940 0 - Live 0xf8a53000
snd_intel8x0 29124 0 - Live 0xf8a03000
snd_via82xx 21888 3 - Live 0xf89fc000
snd_ac97_codec 59332 3 snd_ens1371,snd_intel8x0,snd_via82xx, Live
0xf8a10000
snd_mpu401_uart 6080 2 snd_intel8x0,snd_via82xx, Live 0xf88c9000
snd_rawmidi 20768 3 snd_ens1370,snd_ens1371,snd_mpu401_uart, Live
0xf88b3000
tuner 16716 0 - Live 0xf88c0000
tvaudio 20428 0 - Live 0xf88ba000
msp3400 22100 0 - Live 0xf88a6000
bttv 142636 0 - Live 0xf88d6000
video_buf 17092 1 bttv, Live 0xf88ad000
i2c_algo_bit 8840 1 bttv, Live 0xf88a2000
v4l2_common 4928 1 bttv, Live 0xf8897000
btcx_risc 3848 1 bttv, Live 0xf8895000
i2c_core 19268 5 tuner,tvaudio,msp3400,bttv,i2c_algo_bit, Live
0xf889c000
videodev 7680 1 bttv, Live 0xf882e000
nvidia 1701484 16 - Live 0xf8a66000
via_agp 5824 1 - Live 0xf882b000
bnep 13184 2 - Live 0xf8818000
l2cap 21764 9 rfcomm,bnep, Live 0xf8848000
bridge 32788 0 - Live 0xf883e000
hci_usb 9600 0 - Live 0xf8823000
bluetooth 43684 6 rfcomm,bnep,l2cap,hci_usb, Live 0xf8832000
[7.4.] Loaded driver and hardware information (/proc/ioports,
/proc/iomem)
dis:/boot$ cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000d4000-000d7bff : Extension ROM
000d8000-000d87ff : Extension ROM
000f0000-000fffff : System ROM
00100000-3ffeffff : System RAM
00100000-003b6abb : Kernel code
003b6abc-004e8aff : Kernel data
3fff0000-3fff2fff : ACPI Non-volatile Storage
3fff3000-3fffffff : ACPI Tables
c0000000-cfffffff : 0000:00:00.0
d0000000-d7ffffff : PCI Bus #01
d0000000-d7ffffff : 0000:01:00.0
d8000000-d9ffffff : PCI Bus #01
d8000000-d8ffffff : 0000:01:00.0
db000000-db003fff : 0000:00:0d.0
db004000-db00407f : 0000:00:09.0
db005000-db005fff : 0000:00:08.0
db005000-db005fff : bttv0
db006000-db0067ff : 0000:00:0d.0
db007000-db007fff : 0000:00:08.1
db008000-db0080ff : 0000:00:0f.0
db008000-db0080ff : 8139too
db009000-db0090ff : 0000:00:10.2
db009000-db0090ff : ehci_hcd
fec00000-fec00fff : reserved
fee00000-fee00fff : reserved
ffff0000-ffffffff : reserved
is:/boot$ cat /proc/ioports
0000-001f : dma1
0020-0021 : pic1
0040-005f : timer
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
a000-a07f : 0000:00:09.0
a000-a07f : 0000:00:09.0
a400-a4ff : 0000:00:0f.0
a400-a4ff : 8139too
a800-a81f : 0000:00:10.0
a800-a81f : uhci_hcd
ac00-ac1f : 0000:00:10.1
ac00-ac1f : uhci_hcd
b000-b00f : 0000:00:11.1
b000-b007 : ide0
b008-b00f : ide1
b400-b41f : 0000:00:11.2
b400-b41f : uhci_hcd
b800-b81f : 0000:00:11.3
b800-b81f : uhci_hcd
bc00-bcff : 0000:00:11.5
bc00-bcff : VIA8233A
c000-c007 : 0000:00:13.0
c000-c007 : ide2
c400-c403 : 0000:00:13.0
c402-c402 : ide2
c800-c807 : 0000:00:13.0
c800-c807 : ide3
cc00-cc03 : 0000:00:13.0
cc02-cc02 : ide3
d000-d0ff : 0000:00:13.0
d000-d007 : ide2
d008-d00f : ide3
d400-d407 : 0000:00:13.1
d400-d407 : ide4
d800-d803 : 0000:00:13.1
d802-d802 : ide4
dc00-dc07 : 0000:00:13.1
dc00-dc07 : ide5
e000-e003 : 0000:00:13.1
e002-e002 : ide5
e400-e4ff : 0000:00:13.1
e400-e407 : ide4
e408-e40f : ide5
[7.5.] PCI information ('lspci -vvv' as root)
00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo
KT266/A/333]
Subsystem: ABIT Computer Corp.: Unknown device 7405
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR-
Latency: 0
Region 0: Memory at c0000000 (32-bit, prefetchable) [size=256M]
Capabilities: [a0] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64-
HTrans- 64bit- FW- AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit- FW-
Rate=x4
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo
KT266/A/333 AGP] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ >SERR- <PERR+
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: d8000000-d9ffffff
Prefetchable memory behind bridge: d0000000-d7ffffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B-
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:08.0 Multimedia video controller: Brooktree Corporation Bt878 Video
Capture (rev 02)
Subsystem: Hauppauge computer works Inc. WinTV Series
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (4000ns min, 10000ns max)
Interrupt: pin A routed to IRQ 7
Region 0: Memory at db005000 (32-bit, prefetchable) [size=4K]
00:08.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture
(rev 02)
Subsystem: Hauppauge computer works Inc. WinTV Series
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (1000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 7
Region 0: Memory at db007000 (32-bit, prefetchable) [size=4K]
00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado]
(rev 74)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC
Management NIC
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2500ns min, 2500ns max), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at a000 [size=128]
Region 1: Memory at db004000 (32-bit, non-prefetchable)
[size=128]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable+ DSel=0 DScale=2 PME-
00:0d.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23
IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
Subsystem: ABIT Computer Corp.: Unknown device 7405
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (500ns min, 1000ns max), cache line size 08
Interrupt: pin A routed to IRQ 7
Region 0: Memory at db006000 (32-bit, non-prefetchable)
[size=2K]
Region 1: Memory at db000000 (32-bit, non-prefetchable)
[size=16K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: ABIT Computer Corp.: Unknown device 8139
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR+
Latency: 32 (8000ns min, 16000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at a400 [size=256]
Region 1: Memory at db008000 (32-bit, non-prefetchable)
[size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 50) (prog-if 00
[UHCI])
Subsystem: ABIT Computer Corp.: Unknown device 7405
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin A routed to IRQ 3
Region 4: I/O ports at a800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 50) (prog-if 00
[UHCI])
Subsystem: ABIT Computer Corp.: Unknown device 7405
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin B routed to IRQ 7
Region 4: I/O ports at ac00 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:10.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) (prog-if
20 [EHCI])
Subsystem: ABIT Computer Corp.: Unknown device 7405
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 10
Interrupt: pin C routed to IRQ 10
Region 0: Memory at db009000 (32-bit, non-prefetchable)
[size=256]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge
Subsystem: VIA Technologies, Inc. VT8233A ISA Bridge
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:11.1 IDE interface: VIA Technologies, Inc.
VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
(prog-if 8a [Master SecP PriP])
Subsystem: VIA Technologies, Inc.
VT82C586/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32
Interrupt: pin A routed to IRQ 11
Region 4: I/O ports at b000 [size=16]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:11.2 USB Controller: VIA Technologies, Inc. USB (rev 23) (prog-if 00
[UHCI])
Subsystem: ABIT Computer Corp.: Unknown device 7405
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 3
Region 4: I/O ports at b400 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:11.3 USB Controller: VIA Technologies, Inc. USB (rev 23) (prog-if 00
[UHCI])
Subsystem: ABIT Computer Corp.: Unknown device 7405
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 32, cache line size 08
Interrupt: pin D routed to IRQ 3
Region 4: I/O ports at b800 [size=32]
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235 AC97 Audio Controller (rev 40)
Subsystem: ABIT Computer Corp.: Unknown device 7405
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 10
Region 0: I/O ports at bc00 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:13.0 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07)
Subsystem: Triones Technologies, Inc.: Unknown device 0001
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 120 (2000ns min, 2000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at c000 [size=8]
Region 1: I/O ports at c400 [size=4]
Region 2: I/O ports at c800 [size=8]
Region 3: I/O ports at cc00 [size=4]
Region 4: I/O ports at d000 [size=256]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:13.1 RAID bus controller: Triones Technologies, Inc. HPT374 (rev 07)
Subsystem: Triones Technologies, Inc.: Unknown device 0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 120 (2000ns min, 2000ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at d400 [size=8]
Region 1: I/O ports at d800 [size=4]
Region 2: I/O ports at dc00 [size=8]
Region 3: I/O ports at e000 [size=4]
Region 4: I/O ports at e400 [size=256]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2
MX/MX 400] (rev a1) (prog-if 00 [VGA])
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Latency: 248 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at d8000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA- ITACoh- GART64-
HTrans- 64bit- FW+ AGP3- Rate=x1,x2,x4
Command: RQ=32 ArqSz=0 Cal=0 SBA- AGP+ GART64- 64bit-
FW- Rate=x4
[7.6.] SCSI information (from /proc/scsi/scsi)
Attached devices:
none
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
root@dis:/proc# df
root@dis:/var/log# swapon -s
Filename Type Size Used
Priority
/.swap-a file 1048568 187972
-1
/.swap-b file 1048568 0
-2
/.swap-c file 1048568 0
-3
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/evms/raid5a 354530944 274848692 61673136 82% /
none 516736 0 516736 0% /dev/shm
root@dis:/var/log# free
total used free shared buffers
cached
Mem: 1033472 1023872 9600 0 121796
156380
-/+ buffers/cache: 745696 287776
Swap: 3145704 187972 2957732
--
Muhammad L. <muhammad@vauban.net>
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2004-02-25 17:44 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-01-18 10:27 ext3 on raid5 failure Jan Dittmer
2004-01-18 18:02 ` Mike Fedyk
2004-01-19 15:30 ` Theodore Ts'o
2004-01-23 8:22 ` Jan Dittmer
2004-01-27 19:08 ` Theodore Ts'o
2004-01-28 10:54 ` Jan Dittmer
2004-01-29 11:44 ` Theodore Ts'o
2004-02-04 9:24 ` Bas Mevissen
2004-02-04 9:43 ` Nigel Cunningham
2004-02-04 11:38 ` Bas Mevissen
2004-02-04 20:49 ` Nigel Cunningham
2004-02-17 23:14 ` Pavel Machek
2004-02-17 23:58 ` Kiko Piris
2004-02-06 19:18 ` Theodore Ts'o
2004-02-09 8:55 ` Bas Mevissen
2004-02-18 3:07 ` Bill Davidsen
2004-02-19 9:27 ` Bas Mevissen
2004-02-19 19:47 ` Bill Davidsen
2004-01-28 11:06 ` Jan Dittmer
2004-02-19 2:32 ` Leandro Guimarães Faria Corsetti Dutra
2004-02-19 8:07 ` Jan Dittmer
2004-02-19 13:50 ` Leandro Guimarães Faria Corcete Dutra
2004-02-19 14:58 ` Leandro Guimarães Faria Corsetti Dutra
-- strict thread matches above, loose matches on Subject: below --
2004-02-25 17:45 Muhammad L.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox