similar to: EXT3 'kernel BUG' in 0.05e?

Hi, just had an oops while spool uucp mails via uuxqt->postfix->procmail to multiple mailboxes on an UDMA IDE drive on my Laptop. All filesystems are ext3 and i am running 2.2.19 + ext3 + ide udma patches. When rebooting the system hang - After another reboot everything went smooth. invalid operand: 0000 CPU: 0 EIP: 0010:[<c014ca15>] Using defaults from ksymoops -t elf32-i386

Hi, just got this oops on one of my production servers (4way smp + highmem). Is it fixed in newer kernels or is it something new? Load is steadily growing and i cant even do a 'ps ax'... invalid operand: 0000 CPU: 0 EIP: 0010:[<c0170396>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 0000001d ebx: 00000000 ecx: c02d5f88 edx:

Red Hat 2.2.19-6.2.12 + 0.0.7a + https://listman.redhat.com/pipermail/ext3-users/2001-November/002258.html (not tuned in /proc yet) + journal 4MB on each fs + 6 ext3 fs on raid1 (hda+hdc) + 1 ext3 fs on another disk not on raid1 (hdd) While untarring (tar zxf) a file that was on a ext3/raid1 onto hdd I got: ksymoops 2.3.4 on i686 2.2.19-6.2.12.g1. Options used -V (default) -k

Hello All, I am running Linux 2.4.7-10, 2.4.18-4 and 2.4.19-pre9, I see the following oops quite often (mainly on 2.4.19-pre9 with kdb). All the kernels I use have the kdb patch installed. 1 kmem_cache_alloc (offset 0x125) get_unused_buffer_head journal_write_metadata_buffer journal_commit_transaction kjournald kernel_thread kmem_cache_alloc dis xchg %eax, (%ebx) cmp $0x5a2cf071, %eax (where

I have seen this error in many postings, but the solutions seem not to apply in this case. This error happens during a small file transfer (gif image) and after 75% of a 165G rsync job (the building file list portion is complete.) Most solutions I saw were related to not having enough RAM or running out of disk space. Check out the machine specs below the error. rsync: writefd_unbuffered

Back again with another oops, which looks suspiciously similiar to the one i posted some days ago (https://listman.redhat.com/pipermail/ext3-users/2002-May/003587.html). Jun 11 12:11:30 castor kernel: Assertion failure in journal_write_metadata_buffer() at journal.c:406: "buffer_jdirty(jh2bh(jh_in))" ksymoops 0.7c on i686 2.4.18-4custom. Options used -V (default) -k

> On Wed, Sep 03, 2003 at 03:49:12PM -0400, Matt Miller wrote: >> I have seen this error in many postings, but the solutions seem not to >> apply in this case. This error happens during a small file transfer >> (gif image) and after 75% of a 165G rsync job (the building file list >> portion is complete.) Most solutions I saw were related to not having >>

Right now I'm building a 2.4.17 kernel on an HPPA Linux system. The kernel it ships with supports ext2 only. Has anybody tried ext3 on HPPA? -- Ralf Hildebrandt (Im Auftrag des Referat V A) Ralf.Hildebrandt@charite.de Charite Campus Virchow-Klinikum Tel. +49 (0)30-450 570-155 Referat V A - Kommunikationsnetze - Fax. +49 (0)30-450 570-916 "A man who

All, I know that there is no official port to Kernel 2.4.4, thus I may not get any help, however I am hoping someone could point me in the right direction for my problem. I am currently forced to use kernel 2.4.4 for reasons out of my control (embedded board). Here are the exact versions of everything I'm running: ExT3 Version: ext3-2.4-0.9.6-248 Util Version: util-linux-2.11f.tar.bz2 e2fs

Hi gluster users, I've spent several months trying to get any kind of high performance out of gluster. The current XFS/samba array is used for video editing and 300-400MB/s for at least 4 clients is minimum (currently a single windows client gets at least 700/700 for a single client over samba, peaking to 950 at times using blackmagic speed test). Gluster has been getting me as low as

Hi Brandon, Can you please turn OFF client-io-threads as we have seen degradation of performance with io-threads ON on sequential read/writes, random read/writes. Server event threads is 1 and client event threads are 2 by default. Thanks & Regards On Fri, Oct 27, 2017 at 12:17 PM, Brandon Bates <brandon at brandonbates.com> wrote: > Hi gluster users, > I've spent several

Why don?t you set LSI to passtrough mode and set one brick per HDD? Regards, Bartosz > Wiadomo?? napisana przez Brandon Bates <brandon at brandonbates.com> w dniu 27.10.2017, o godz. 08:47: > > Hi gluster users, > I've spent several months trying to get any kind of high performance out of gluster. The current XFS/samba array is used for video editing and 300-400MB/s for

I''m installing Xen with the OpenSUSE 10.2 distro and the bigsmp-2.6.18.8-0.13.i586 kernel. However, I occasionally get insane amounts of slowdown (almost 100x) in dom0. On bootup, performance is normal. After an undeterministic period of time, I get this crazy amount of slowdown. I''m not sure why this is the case and I have spent a long time trying to figure it out.

The following 6 patches cleanup the jbd code and kill about 200 lines. First of 4 patches can apply to 2.6.13-git8 and 2.6.13-mm2. The rest of them can apply to 2.6.13-mm2. fs/jbd/checkpoint.c | 179 +++++++++++-------------------------------- fs/jbd/commit.c | 101 ++++++++++-------------- fs/jbd/journal.c | 11 +- fs/jbd/revoke.c | 158

(The list appears to have eaten my previous attempt to send this. Apologies if you receive multiple copies.) The attached patches allow you to use paravirtualised network and block interfaces from fully virtualised domains, based on Intel''s patches from a few months ago. These are significantly faster than the equivalent ioemu devices, sometimes by more than an order of magnitude.