-----BEGIN PGP SIGNED MESSAGE-----
On Fri, 4 Jan 2002 03:00, Andreas Dilger wrote:
> Maybe yes. This is very strange. Are you testing all of these filesystems
> on the same LV in order? Can you try just doing XFS by itself on a clean
> reboot? I assume that you are rebooting after every oops, because if you
> don't there is junk in the kernel memory that will screw up further tests.
Each test is done on its own LV and there is always a reboot and recovery
before every test after an Oops. More information about the vg's and lv's as
well as the test procedure can be found halfway down:
> > * Can create xfs snapshot? | Oops
> > btp 1234 (lvcreate)
> > journal_start
> > ext3_dirty_inode
> ^^^^^^^^^^^^^^^^ yes, very strange.
> > __mark_inode_dirty
> > update_atime
> > do_generic_file_read
> > generic_file_read
> > sys_read
> > system_call
I have been thinking - the VFS-lock patch tries to get all (not sure - at
least ext3 & resierfs) to flush everything to disk. Maybe its actually an
interaction problem between ext3 and LVM? but why XFS? I'm only guessing
here at the moment.
> Note that it appears most of the ext3 fixes went into 2.4.17, so this may
> be a new bug. As I said, let's try first with XFS snapshots only, and if
> that doesn't have a problem, try to re-create the above problem and send
> a full oops report to ext2-devel.
This is what I'm having trouble with at the moment. When the kernel Oops
occurs it drops me into kdb (kernel debugger). From here I can look at
current process status, do back traces on anything thats running etc.. but it
never shows me the full Kernel Oops and there is no record of it in the logs
either. I expect that a couple of backtraces, list of processes, register
values would be equivalent to a Kernel Oops report?
(Public Key available on request.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----