* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
[not found] ` <1010072497.12080.42.camel@jen.americas.sgi.com>
@ 2002-01-03 18:13 ` Adrian Head
0 siblings, 0 replies; 27+ messages in thread
From: Adrian Head @ 2002-01-03 18:13 UTC (permalink / raw)
To: Steve Lord, Andreas Dilger; +Cc: Linux XFS, linux-lvm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 4 Jan 2002 01:41, Steve Lord wrote:
> > There are however, may subtle (unhappy) interactions between XFS, LVM and
> > other kernel areas when you try to do snapshots for example.
>
> Yes, I have seen the thread, I have just not had the time to look into
> it yet. Your last message said that the xfs snapshot creation was
> failing, but with an ext3 stack trace.....
>
> You also mention out of space problems in the snapshot.
>
> Can you summarize where your kernel came from - I see you have lots of
> stuff in there. Do you still need special lvm patches to turn on
> snapshotting support - it has been a while.
>
> Also, send me a quick rundown of the commands you need to use to setup
> a volume for snapshotting - it will save me the research.
Thats fine Steve, all I was doing at the time was just saying that running
XFS on a straight LVM seems to be very happy as far as I can tell. However,
since you have asked the questions I will answer now before I forget about
it. ;-)
The problem I have encountered is just as strange (ext3 stack trace) as the
file corruption during compile problem that you are dealing with now.
What I was going to do was fall back to ext2 and remove ext3 from the kernel
and rerun the tests. Hopefully by doing this it will shed more light onto
the problem.
Not sure what you mean by have lots of stuff in the kernel but to summarise
where it came from.
The recent kernel - the one I did the last series of tests with was from the
SGI CVS and was:
2.4.17-xfs 20011226
Previous kernels also from SGI CVS that I have tried were:
2.4.16-xfs 20011218
2.4.16-xfs 20011223
The system is a minimal install of RH7.2 and all compiles have used the
default compile flags using the default RH7.2 compiler.
gcc version 2.96 20000731 (Re Hat Linux 7.1 2.96-89)
A more indepth of the make-up of my system can be found here: from the
thread "XFS dying when many processes copy many files/directories"
http://marc.theaimsgroup.com/?l=linux-xfs&m=100942550316126&w=2
The only other things added to the kernel are the LVM patches of which there
are two that the LVM people recommend.
* The LVM-1.0.1 upgrade patch and
* The VFS-lock patch
(in that order)
- From my understanding the LVM-1.0.1 patch is recommended as it has many
bugfixes from the LVM-1.0.1rc4(ish) that is currently in the linus & SGI
2.4.17 kernel. Unfortunately I don't have handy a URL to the changlog -
sorry.
The VFS-lock patch from my understanding is required for creating snapshots
on journaling filesystems like ext3, resierfs and maybe XFS. (AFAIK XFS is a
special case as you can also use xfs_freeze). The VFS-lock patch locks the
VFS layer and forces all filesystems to sync to disk dumping all dirty
buffers/pages etc... If this doesn't happen; although you can create a
snapshot you will never be able to mount it as the journals of at least ext3
& resierfs will need to be replayed - which cannot happen as the snapshot is
read-only. Maybe some of the LVM developers may be able to give you more
information than that.
There are 3rd party patches to make the snapshot writable but I don't see the
advantage for my situation as yet and I'm having enough trouble getting the
basics running. Therefore, I have not applied these patches. ;-)
Now with regards to the out of space problems I have been referring to:
What I was wanting was to not only use LVM snapshots for backups but to also
hold a known disk state for a while ie. 24hrs. This has the advantage that I
as a sysadmin can snapshot a volume before I start volume maintance and have
a backout strategy if I accidently do something I should not have. And I was
wanting to have the same concept for staff - if they accidently delete a file
off the server they can go to the mounted snapshot and get it back without
running to me for the backup. Under normal office operations I can guess how
much space the snapshot needs; however, there will always be a time/situation
where someone will dump data way in excess of what the snapshot size can
handle. Under this situation the snapshot should just be taken offline
automatically without killing the system. This is what I was reffering to
with overflowing the snapshot. It was the Oops generated when an XFS
snapshot overflowed during one of my many pre-production tests that started
me on this quest ;-)
This was how the HDD was divided up on my test system:
=======================================================================
- - - hda1 - /boot 20M ext3
- - - hda2 - / 512M ext3
- - - hda3 - /usr 512M ext3
- - - hda4 - {extended}
- - - hda5 - /var 512M ext3
- - - hda6 - swap 768M
- - - hda7 - {LVM volume group HDA} 36941M - Remaining Space (36G)
- /dev/HDA/TMP /tmp 128M reiserfs
- /dev/HDA/CACHE /cache 512M reiserfs
- /dev/HDA/CHROOT /chroot 512M ext3
- /dev/HDA/SRC /usr/src 4096M reiserfs
- /dev/HDA/SRC_SNAP /usr/src/snapshot/admin 1024M
(30G Unallocated)
=======================================================================
The test procedure was:
1) Unpack a clean SGI CVS kernel and patch LVM as required.
2) Compile, install and reboot.
3) For a mounted ext3 logical volume
a) create a snapshot
lvcreate -L50M -s -n SNAP /dev/HDA/CHROOT
b) mount the snapshot
mount /dev/HDA/SNAP /mnt/snapshot
c) copy more than the snapshot size onto the original logical volume to see
what happens.
cp -fr /usr/src/<dir1> /chroot
4) Repeat for resierfs
5) Repeat for XFS
Note: becareful when mounting an XFS snaphot without using "mount -t xfs"
otherwise i have found it will mount the snapshot as resierfs.
See http://marc.theaimsgroup.com/?l=linux-xfs&m=100994490716530&w=2 for more
info on this.
If there was a Kernel Oops there would be a reboot and recovery inbetween 3,
4 &/or 5.
The exact results from the tests can be found here:
http://marc.theaimsgroup.com/?l=linux-xfs&m=100994356415003&w=2
A quick summary of commands:
To initialise a partition for LVM usage:
pvcreate /dev/hda7
To create a volume group (the container for the logical volumes)
vgcreate -s32M HDA /dev/hda7
Note: -s32M is optional; default is 4M.
To create a logical volume (the volume that will contain the filesystem)
lvcreate -L4G -n CHROOT /dev/HDA
Then put the filesystem on top:
eg:
mkfs -t ext2 -j /dev/HDA/CHROOT
or
mkfs -t xfs /dev/HDA/TEST
or
mkfs -t resierfs /dev/HDA/SRC
Then mount logical volume:
eg:
mount /dev/HDA/SRC /usr/src
A good quick tutorial on LVM can be found here:
http://www.sistina.com/lvm_howtos/lvm_howto/
and the basic lvm commands here:
http://www.sistina.com/lvm_howtos/lvm_howto/Common_tasks.html
I hope this has answered your questions. My next move is to remove ext3 from
the kernel and rerun the tests to see what happens.
If I have left out anything please contact me.
- --
Adrian Head
(Public Key available on request.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8NPQs8ZJI8OvSkAcRApMRAJ9qkytpP8RXUHuD2dgFp9CV/sQSJACfeo6F
SM6pTcPryGjyHAMn3QIdQ2o=
=f+ak
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
[not found] <200201040015.RAA00441@cthulhu.turbolabs.com>
@ 2002-01-03 18:36 ` Andreas Dilger
0 siblings, 0 replies; 27+ messages in thread
From: Andreas Dilger @ 2002-01-03 18:36 UTC (permalink / raw)
To: Adrian Head; +Cc: Steve Lord, Linux XFS, linux-lvm
On Jan 04, 2002 10:15 +1000, Adrian Head wrote:
> Note: becareful when mounting an XFS snaphot without using "mount -t xfs"
> otherwise i have found it will mount the snapshot as resierfs.
> See http://marc.theaimsgroup.com/?l=linux-xfs&m=100994490716530&w=2 for more
> info on this.
This is because the reiserfs superblock is 64kB into the filesystem, and it
appears that the mkfs.xfs does not overwrite this part of the disk. I have
heard of another person with this same problem. It would probably behoove
the XFS folks to zero the first and last 128kB of a partition when doing
mkfs.xfs to avoid this sort of problem.
For mkfs.ext2, it will zero the first 4kB, overwrite the next tens of kB,
and also zero the last 128kB. I should probably make sure that it will
_always_ overwrite at least the first 68kB, but with the default parameters
it will at least do so except on the smallest of filesystems (i.e. floppies).
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
[not found] <200201020451.g024pPg00867@oss.sgi.com>
@ 2002-01-04 13:49 ` Eric Sandeen
2002-01-04 16:47 ` Adrian Head
[not found] ` <200201042349.g04Nnag26320@oss.sgi.com>
2002-01-09 16:25 ` Eric Sandeen
1 sibling, 2 replies; 27+ messages in thread
From: Eric Sandeen @ 2002-01-04 13:49 UTC (permalink / raw)
To: Adrian Head; +Cc: Linux XFS Mailing List, linux-lvm
Ok, I have 2.4.17-xfs (cvs checkout today) with patches from lvm-1.0.1,
applied lvm-1.0.1-2.4.17-xfs.patch then linux-2.4.11-VFS-lock.patch.
I tried creating lvm volumes & snapshots w/ an xfs filesystem.
I did run into problems (creating snapshot against my "test" volume
while it was mounted caused an oops; creating snapshot volume then
mounting test oopsed....) but eventually I got a volume mounted, and had
a snapshot volume against it.
Overflowing the snapshot behaved well:
lvm -- giving up to snapshot /dev/test/foo on /dev/test/snap: out of
space
I'll check out the oopses to see if I can figure out what's going on.
-Eric
On Tue, 2002-01-01 at 21:51, Adrian Head wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hope everyone had a happy new year :-)
>
> I'm starting to play around with LVM with the goal of having XFS, ext3,
> reiserfs and LVM coexist nicely together.
>
> Has anyone been able to get , ext3, reiserfs, XFS and LVM running nicely
> together?
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@sgi.com SGI, Inc.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-04 13:49 ` [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Eric Sandeen
@ 2002-01-04 16:47 ` Adrian Head
2002-01-04 17:37 ` Andreas Dilger
[not found] ` <200201042349.g04Nnag26320@oss.sgi.com>
1 sibling, 1 reply; 27+ messages in thread
From: Adrian Head @ 2002-01-04 16:47 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Linux XFS Mailing List, linux-lvm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 5 Jan 2002 05:52, Eric Sandeen wrote:
> Ok, I have 2.4.17-xfs (cvs checkout today) with patches from lvm-1.0.1,
> applied lvm-1.0.1-2.4.17-xfs.patch then linux-2.4.11-VFS-lock.patch.
>
> I tried creating lvm volumes & snapshots w/ an xfs filesystem.
>
> I did run into problems (creating snapshot against my "test" volume
> while it was mounted caused an oops; creating snapshot volume then
> mounting test oopsed....) but eventually I got a volume mounted, and had
> a snapshot volume against it.
>
> Overflowing the snapshot behaved well:
>
> lvm -- giving up to snapshot /dev/test/foo on /dev/test/snap: out of
> space
>
> I'll check out the oopses to see if I can figure out what's going on.
>
> -Eric
Well this seems consistant with what I'm seeing:
2.4.17-xfs
While source volume mounted:
+ lvm-1.0.1 upgrade
+ VFS-lock
(In that order)
* Can create ext3 snapshot? | yes
* Can mount a ext3 snapshot? | yes
* Can create resierfs snapshot? | yes
* Can mount a resierfs snapshot? | yes
* Can create xfs snapshot? | Oops
btp 1234 (lvcreate)
journal_start
ext3_dirty_inode
__mark_inode_dirty
update_atime
do_generic_file_read
generic_file_read
sys_read
system_call
Running processes (lvcreate)
* Can mount a xfs snapshot? | Cannot test
When source & snapshot mounted:
* Cause oops when snapshot overflows? |
- ext3 | OK - Stable
- resierfs | OK - Stable
- xfs | Cannot test
What does your backtrace look like? Its the ext3_dirt_inode in my backtrace
thats got me. I have compiled a kernel without ext3 so will also give it a
run later.
I now have a serial cable and once I work out how to use kdb with it I'll be
able to capture the full kdb output.. I was wanting to be in this position
now; but ran into an issue with the Linux kernel which killed a lot of time..
OT: There is an option in the linux kernel config that allows extra debugging
info to be compled into the kernel. Don't use it as it stops all modules
from being loaded. It took me a couple of hours to realise what was
happening :-(
- --
Adrian Head
(Public Key available on request.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8NjF18ZJI8OvSkAcRAiFHAJ9oHz9ntOT+pNatBj3SxTMqw0je1gCfasWm
8zvETAseafRuSEpOaAFQkuE=
=+BBG
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
[not found] ` <200201042349.g04Nnag26320@oss.sgi.com>
@ 2002-01-04 17:12 ` Eric Sandeen
2002-01-04 20:44 ` Adrian Head
[not found] ` <200201050346.g053kmg29738@oss.sgi.com>
0 siblings, 2 replies; 27+ messages in thread
From: Eric Sandeen @ 2002-01-04 17:12 UTC (permalink / raw)
To: Adrian Head; +Cc: Linux XFS Mailing List, linux-lvm
On Fri, 2002-01-04 at 16:49, Adrian Head wrote:
> What does your backtrace look like? Its the ext3_dirt_inode in my backtrace
> thats got me. I have compiled a kernel without ext3 so will also give it a
> run later.
No, ext3 functions do not show up for me when it oopses on snapshot
creation:
kdb> bt
EBP EIP Function(args)
0xc1c2bf78 0xc013649e path_init+0x36 (0xc1c2a000)
kernel .text 0xc0100000 0xc0136468 0xc013659c
0xc1c2bf90 0xc01366cf __user_walk+0x2f (0xc1c2a000, 0x804f1bc)
kernel .text 0xc0100000 0xc01366a0 0xc01366f8
0xc1c2bfbc 0xc013381e sys_stat64+0x1a (0x8052474, 0xbfffe980, 0x40196154, 0x804f1bc, 0x3)
kernel .text 0xc0100000 0xc0133804 0xc0133874
0xc0106c5b system_call+0x33
kernel .text 0xc0100000 0xc0106c28 0xc0106c60
It's trying to stat64 /dev/sda2, one of my lvm partitions. I dunno why
this blows up. :/
The code has some fastcalls & inlines around here, though, so this may
not be the most accurate.
Still looking...
-Eric
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@sgi.com SGI, Inc.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-04 16:47 ` Adrian Head
@ 2002-01-04 17:37 ` Andreas Dilger
2002-01-04 20:10 ` Adrian Head
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Andreas Dilger @ 2002-01-04 17:37 UTC (permalink / raw)
To: Adrian Head; +Cc: Eric Sandeen, Linux XFS Mailing List, linux-lvm
On Jan 05, 2002 08:49 +1000, Adrian Head wrote:
> Well this seems consistant with what I'm seeing:
> 2.4.17-xfs
> While source volume mounted:
> + lvm-1.0.1 upgrade
> + VFS-lock
> (In that order)
> * Can create ext3 snapshot? | yes
> * Can mount a ext3 snapshot? | yes
> * Can create resierfs snapshot? | yes
> * Can mount a resierfs snapshot? | yes
> * Can create xfs snapshot? | Oops
> btp 1234 (lvcreate)
> journal_start
> ext3_dirty_inode
> __mark_inode_dirty
> update_atime
> do_generic_file_read
> generic_file_read
> sys_read
> system_call
Can you repeat this test, but skip the ext3 snapshot creation part of it
entirely (i.e. create a reiserfs snapshot and an XFS snapshot, without
changing the kernel)? I'm wondering if XFS is getting an old inode that
ext3 was using, but either ext3 or XFS is not clearing it, so that is why
it is calling into ext3. Also, are you using ext3 on other filesystems in
this computer?
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-04 17:37 ` Andreas Dilger
@ 2002-01-04 20:10 ` Adrian Head
2002-01-04 21:35 ` Adrian Head
[not found] ` <200201050212.TAA16774@cthulhu.turbolabs.com>
2 siblings, 0 replies; 27+ messages in thread
From: Adrian Head @ 2002-01-04 20:10 UTC (permalink / raw)
To: Andreas Dilger; +Cc: Eric Sandeen, Linux XFS Mailing List, linux-lvm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 5 Jan 2002 09:39, Andreas Dilger wrote:
> Can you repeat this test, but skip the ext3 snapshot creation part of it
> entirely (i.e. create a reiserfs snapshot and an XFS snapshot, without
> changing the kernel)? I'm wondering if XFS is getting an old inode that
> ext3 was using, but either ext3 or XFS is not clearing it, so that is why
> it is calling into ext3. Also, are you using ext3 on other filesystems in
> this computer?
>
> Cheers, Andreas
Yes there are other volumes using ext3.
/boot 20M ext3
/ 512M ext3
/usr 512M ext3
/var 512M ext3
swap 768M
/tmp 128M reiserfs LVM
/cache 512M reiserfs LVM
/chroot 512M ext3 LVM
/usr/src 4096Mreiserfs LVM
/data ~30G xfs LVM
the tests are done on /chroot for ext3,
/usr/src for resierfs & /data for xfs.
I can skip the ext3 snapshot creation part - each test is done on its own
logical volume; however, in the dark dim past any of these could have had
other filesystems on them.
Does this sound sensible?
1) Run tests without doing the ext3 snapshot creation, then
2) dd the entire lv that is giving problems and try again?
Thanks for your time & effort.
- --
Adrian Head
(Public Key available on request.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8NmEb8ZJI8OvSkAcRAiJGAJ9SeL5O399a56EQc2hOu3KbAlTsngCgksF+
y/yKm/SxB7lji0XMLXaAQXo=
=DRn3
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-04 17:12 ` Eric Sandeen
@ 2002-01-04 20:44 ` Adrian Head
2002-01-05 17:06 ` Andreas Dilger
[not found] ` <200201050346.g053kmg29738@oss.sgi.com>
1 sibling, 1 reply; 27+ messages in thread
From: Adrian Head @ 2002-01-04 20:44 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Linux XFS Mailing List, linux-lvm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is the full output from kdb when trying to create a snapshot on an XFS
volume for me.
What I was going to do next was follow Andreas Dilger's sugestion and try
again.
Entering kdb (current=0xc7228000, pid 1435) Oops: Oops
due to oops @ 0xc015c446
eax = 0x748b5356 ebx = 0xc01a1550 ecx = 0xd7894040 edx = 0x00000000
esi = 0xc7228000 edi = 0xd7894040 esp = 0xc7229eac eip = 0xc015c446
ebp = 0xd7ed4800 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc7229e78
kdb> bt
EBP EIP Function(args)
0xd7ed4800 0xc015c446 journal_start+0x36 (0xd7ed4800, 0x1, 0x40018000,
0xc7229f5c, 0x2)
kernel .text 0xc0100000 0xc015c410 0xc015c4f0
0xc01571a8 ext3_dirty_inode+0x58 (0xd7894040)
kernel .text 0xc0100000 0xc0157150 0xc0157250
0xc0141b1e __mark_inode_dirty+0x2e (0xd7894040, 0x1)
kernel .text 0xc0100000 0xc0141af0 0xc0141b70
0xc0143001 update_atime+0x51 (0xd7894040, 0x6d6, 0x1, 0x0, 0x6d6)
kernel .text 0xc0100000 0xc0142fb0 0xc0143010
0xc01254ac do_generic_file_read+0x40c (0xd5fc7740, 0xd5fc7760,
0xc7229f5c, 0xc0125690, 0x6d6)
kernel .text 0xc0100000 0xc01250a0 0xc01254c0
0xc012576a generic_file_read+0x7a (0xd5fc7740, 0x40018000, 0x1000,
0xd5fc7760, 0x0)
kernel .text 0xc0100000 0xc01256f0 0xc0125810
0xc0130cf5 sys_read+0x95 (0x4, 0x40018000, 0x1000, 0x8086ab0,
0x40018000)
kernel .text 0xc0100000 0xc0130c60 0xc0130d30
0xc0106d1b system_call+0x33
kernel .text 0xc0100000 0xc0106ce8 0xc0106d20
kdb> btp 1435
EBP EIP Function(args)
0xc01a1550 0xc015c446 journal_start+0x36 (0xd7ed4800, 0x1, 0x40018000,
0xc7229f5c, 0x2)
kernel .text 0xc0100000 0xc015c410 0xc015c4f0
0xc01571a8 ext3_dirty_inode+0x58 (0xd7894040)
kernel .text 0xc0100000 0xc0157150 0xc0157250
0xc0141b1e __mark_inode_dirty+0x2e (0xd7894040, 0x1)
kernel .text 0xc0100000 0xc0141af0 0xc0141b70
0xc0143001 update_atime+0x51 (0xd7894040, 0x6d6, 0x1, 0x0, 0x6d6)
kernel .text 0xc0100000 0xc0142fb0 0xc0143010
0xc01254ac do_generic_file_read+0x40c (0xd5fc7740, 0xd5fc7760,
0xc7229f5c, 0xc0125690, 0x6d6)
kernel .text 0xc0100000 0xc01250a0 0xc01254c0
0xc012576a generic_file_read+0x7a (0xd5fc7740, 0x40018000, 0x1000,
0xd5fc7760, 0x0)
kernel .text 0xc0100000 0xc01256f0 0xc0125810
0xc0130cf5 sys_read+0x95 (0x4, 0x40018000, 0x1000, 0x8086ab0,
0x40018000)
kernel .text 0xc0100000 0xc0130c60 0xc0130d30
0xc0106d1b system_call+0x33
kernel .text 0xc0100000 0xc0106ce8 0xc0106d20
kdb> ps
Task Addr Pid Parent [*] cpu State Thread Command
0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270 init
0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd
0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0
0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd
0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush
0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated
0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd
0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d
0xd7b32000 00000009 00000001 1 000 stop 0xd7b32270 kjournald
0xd72a6000 00000153 00000001 1 000 stop 0xd72a6270 kjournald
0xd729c000 00000154 00000001 1 000 stop 0xd729c270 kjournald
0xd7292000 00000155 00000001 1 000 stop 0xd7292270 kjournald
0xd7174000 00000157 00000001 1 000 stop 0xd7174270 kreiserfsd
0xd70ac000 00000158 00000001 1 000 stop 0xd70ac270 kjournald
0xd6f68000 00000160 00000001 1 000 stop 0xd6f68270 pagebuf_daemon
0xd6250000 00000525 00000001 1 000 stop 0xd6250270 dhcpcd
0xd6c56000 00000661 00000001 1 000 stop 0xd6c56270 syslogd
0xd623a000 00000666 00000001 1 000 stop 0xd623a270 klogd
0xd619e000 00000686 00000001 1 000 stop 0xd619e270 portmap
0xd60ac000 00000714 00000001 1 000 stop 0xd60ac270 rpc.statd
0xd62d6000 00000827 00000001 1 000 stop 0xd62d6270 crond
more>
0xd5f3a000 00000863 00000001 1 000 stop 0xd5f3a270 atd
0xd6a80000 00000870 00000001 1 000 stop 0xd6a80270 login
0xd5f5a000 00000871 00000001 1 000 stop 0xd5f5a270 login
0xd5f56000 00000872 00000001 1 000 stop 0xd5f56270 mingetty
0xd6c9c000 00000873 00000001 1 000 stop 0xd6c9c270 mingetty
0xd5f6a000 00000874 00000001 1 000 stop 0xd5f6a270 mingetty
0xd6c9a000 00000875 00000001 1 000 stop 0xd6c9a270 mingetty
0xd6338000 00000876 00000001 1 000 stop 0xd6338270 login
0xd739c000 00000879 00000876 1 000 stop 0xd739c270 bash
0xd5d86000 00000925 00000870 1 000 stop 0xd5d86270 bash
0xd580c000 00000977 00000871 1 000 stop 0xd580c270 bash
0xc7228000 00001435 00000925 1 000 run 0xc7228270*lvcreate
kdb> id %eip
0xc015c446 journal_start+0x36: cmp %ebp,(%eax)
0xc015c448 journal_start+0x38: je 0xc015c46d journal_start+0x5d:
0xc015c44a journal_start+0x3a: push $0xc02309e0
0xc015c44f journal_start+0x3f: push $0xe1
0xc015c454 journal_start+0x44: push $0xc022becf
0xc015c459 journal_start+0x49: push $0xc022b6a0
0xc015c45e journal_start+0x4e: push $0xc022e6a0
0xc015c463 journal_start+0x53: call 0xc0115380 printk:
0xc015c468 journal_start+0x58: ud2a
0xc015c46a journal_start+0x5a: add $0x14,%esp
0xc015c46d journal_start+0x5d: incl 0x8(%ebx)
0xc015c470 journal_start+0x60: jmp 0xc015c4e0 journal_start+0xd0:
0xc015c472 journal_start+0x62: push $0x1
0xc015c474 journal_start+0x64: push $0xf0
0xc015c479 journal_start+0x69: push $0x14
0xc015c47b journal_start+0x6b: push $0xc022b6a0
kdb> go
Oops: 0000
CPU: 0
EIP: 0010:[<c015c446>] Not tainted
EFLAGS: 00010286
eax: 748b5356 ebx: c01a1550 ecx: d7894040 edx: 00000000
esi: c7228000 edi: d7894040 ebp: d7ed4800 esp: c7229eac
ds: 0018 es: 0018 ss: 0018
Process lvcreate (pid: 1435, stackpage=c7229000)
Stack: c01a1550 c01a1550 ffffffe2 d7894040 00000000 c01571a8 d7ed4800 00000001
40018000 c7229f5c 00000002 00000018 d7894040 d7b41000 00000001 c0141b1e
d7894040 3c36dd6f d5fc7760 d78940f0 c0143001 d7894040 00000001 00000000
Call Trace: [<c01a1550>] [<c01a1550>] [<c01571a8>] [<c0141b1e>] [<c0143001>]
[<c01254ac>] [<c012576a>] [<c0125690>] [<c0130cf5>] [<c0106d1b>]
Code: 39 28 74 23 68 e0 09 23 c0 68 e1 00 00 00 68 cf be 22 c0 68
On Sat, 5 Jan 2002 09:14, Eric Sandeen wrote:
> On Fri, 2002-01-04 at 16:49, Adrian Head wrote:
> > What does your backtrace look like? Its the ext3_dirt_inode in my
> > backtrace thats got me. I have compiled a kernel without ext3 so will
> > also give it a run later.
>
> No, ext3 functions do not show up for me when it oopses on snapshot
> creation:
>
> kdb> bt
> EBP EIP Function(args)
> 0xc1c2bf78 0xc013649e path_init+0x36 (0xc1c2a000)
> kernel .text 0xc0100000 0xc0136468
> 0xc013659c 0xc1c2bf90 0xc01366cf __user_walk+0x2f (0xc1c2a000, 0x804f1bc)
> kernel .text 0xc0100000 0xc01366a0
> 0xc01366f8 0xc1c2bfbc 0xc013381e sys_stat64+0x1a (0x8052474, 0xbfffe980,
> 0x40196154, 0x804f1bc, 0x3) kernel .text 0xc0100000 0xc0133804 0xc0133874
> 0xc0106c5b system_call+0x33
> kernel .text 0xc0100000 0xc0106c28
> 0xc0106c60
>
>
> It's trying to stat64 /dev/sda2, one of my lvm partitions. I dunno why
> this blows up. :/
>
> The code has some fastcalls & inlines around here, though, so this may
> not be the most accurate.
>
> Still looking...
>
> -Eric
- --
Adrian Head
(Public Key available on request.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8NmkN8ZJI8OvSkAcRAk6FAJ0SKQPujP4BQbjs0tZprVhAyDwehQCfcjxA
lONpZIiIHSojcBPRkyNFfvA=
=k23i
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
[not found] ` <200201050346.g053kmg29738@oss.sgi.com>
@ 2002-01-04 21:08 ` Eric Sandeen
2002-01-07 8:05 ` Adrian Head
2002-01-07 12:58 ` Eric Sandeen
2002-01-06 0:20 ` Adrian Head
1 sibling, 2 replies; 27+ messages in thread
From: Eric Sandeen @ 2002-01-04 21:08 UTC (permalink / raw)
To: Adrian Head; +Cc: Linux XFS Mailing List, linux-lvm
Ok, I've done a bit of kdb sleuthing over here... it looks like it's
blowing up shortly after lvm_snapshot_COW, although for some reason kdb
says the backtrace is from sys_stat64 after the oops. On the other
hand, setting a breakpoint at
lvm_snapshot_COW, it oopses just a couple steps later. Here's the
backtrace out of lvm_snapshot_COW. It gets there from lvm_do_lv_creat
via unlockfs; does this make sense? I didn't expect to get into
lvm_snapshot_COW until after the snapshot volume was created...
kdb> bp lvm_snapshot_COW
Instruction(i) BP #0 at 0xc8848ab4 ([lvm-mod]lvm_snapshot_COW)
is enabled globally adjust 1
kdb> go
Instruction(i) breakpoint #0 at 0xc8848ab4 (adjusted)
0xc8848ab4 lvm_snapshot_COW: int3
Entering kdb (current=0xc5ca0000, pid 1063) due to Breakpoint @ 0xc8848ab4
kdb> bt
EBP EIP Function(args)
0xc5ca1718 0xc8848ab4 [lvm-mod]lvm_snapshot_COW (0x802, 0x10178, 0x10178,
0x10178, 0xc5e8f000)
lvm-mod .text 0xc8844060 0xc8848ab4
0xc8848fc0
0xc884538b [lvm-mod]__remap_snapshot+0x5b (0x802, 0x10178,
0x10178, 0xc5b10a00, 0xc5e8f000)
lvm-mod .text 0xc8844060 0xc8845330
0xc88453b8
0xc5ca179c 0xc8845760 [lvm-mod]lvm_map+0x3a8 (0xc5777900, 0x1)
lvm-mod .text 0xc8844060 0xc88453b8
0xc88457e8
0xc5ca17ac 0xc88457f8 [lvm-mod]lvm_make_request_fn+0x10 (0xc039e028, 0x1,
0xc5777900)
lvm-mod .text 0xc8844060 0xc88457e8
0xc8845808
0xc5ca17d0 0xc01a004b generic_make_request+0xa7 (0x1, 0xc5777900)
kernel .text 0xc0100000 0xc019ffa4
0xc01a00d0
0xc5ca182c 0xc882caa2 [pagebuf]_pagebuf_page_io+0x24a (0xc116c400,
0xc5caa080, 0x1, 0x0, 0x3a00)
pagebuf .text 0xc882b060 0xc882c858
0xc882cb1c
0xc5ca1888 0xc882cc6b [pagebuf]_page_buf_page_apply+0x14f (0xc5caa080,
0x0, 0x0, 0xc116c400, 0x600)
pagebuf .text 0xc882b060 0xc882cb1c
0xc882cc78
0xc5ca18c8 0xc882d0a8 [pagebuf]pagebuf_segment_apply+0x98 (0xc882cb1c,
0xc5caa080)
pagebuf .text 0xc882b060 0xc882d010
0xc882d0f0
0xc5ca1908 0xc882cd64 [pagebuf]pagebuf_iorequest+0xec (0xc5caa080)
pagebuf .text 0xc882b060 0xc882cc78
0xc882cdb8
0xc5ca1914 0xc88c977a [xfs]xfsbdstrat+0x2a (0xc13cfc00, 0xc5caa080)
xfs .text 0xc8866060 0xc88c9750 0xc88c978c
0xc5ca1934 0xc88b20a8 [xfs]xfs_unmountfs_writesb+0xc4 (0xc13cfc00)
more>
xfs .text 0xc8866060 0xc88b1fe4 0xc88b2108
0xc5ca1944 0xc889ef4d [xfs]xfs_fs_thaw+0xd (0xc13cfc00)
xfs .text 0xc8866060 0xc889ef40 0xc889ef60
0xc5ca1ce0 0xc88c55b0 [xfs]xfs_ioctl+0x1684 (0xc5ca6058, 0xc5b11440, 0x0,
0xc0045878, 0x0)
xfs .text 0xc8866060 0xc88c3f2c 0xc88c5660
0xc5ca1d08 0xc88caabd [xfs]linvfs_unfreeze_fs+0x41 (0xc13cf400)
xfs .text 0xc8866060 0xc88caa7c 0xc88caacc
0xc5ca1d18 0xc0131469 unlockfs+0x31 (0x3a00)
kernel .text 0xc0100000 0xc0131438
0xc013148c
0xc5ca1da8 0xc8847174 [lvm-mod]lvm_do_lv_create+0x7fc (0x0, 0xc884ce60,
0xc5ca1dec, 0xc6482cc0)
lvm-mod .text 0xc8844060 0xc8846978
0xc88471ac
0xc5ca1f90 0xc8844900 [lvm-mod]lvm_chr_ioctl+0x644 (0xc5b11800,
0xc6482cc0, 0x4004fe20, 0xbfffec60, 0xc5ca0000)
lvm-mod .text 0xc8844060 0xc88442bc
0xc8844a0c
0xc5ca1fbc 0xc01393f4 sys_ioctl+0x174 (0x4, 0x4004fe20, 0xbfffec60,
0x804f1bc, 0xbffff940)
kernel .text 0xc0100000 0xc0139280
0xc0139410
0xc0106c5b system_call+0x33
kernel .text 0xc0100000 0xc0106c28
0xc0106c60
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-04 17:37 ` Andreas Dilger
2002-01-04 20:10 ` Adrian Head
@ 2002-01-04 21:35 ` Adrian Head
2002-01-06 0:05 ` [linux-lvm] lvm-1.0.1rc4(ish) more robust on startup than lvm-1.0.1 Adrian Head
[not found] ` <200201050212.TAA16774@cthulhu.turbolabs.com>
2 siblings, 1 reply; 27+ messages in thread
From: Adrian Head @ 2002-01-04 21:35 UTC (permalink / raw)
To: Andreas Dilger; +Cc: Eric Sandeen, Linux XFS Mailing List, linux-lvm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andreas or any other LVM gurus,
This is related to but not imeadiately concerned with the problem we have
been discussing.
When lvcreate dies when creating an XFS snapshot it doesn't finish the
snapshot creation and although lvdisplay shows that the XFS lv has an active
snapshot (shows even its name) lvdisplay tells me that the snapshot doesn't
exist and therefore, cannot be removed.
During the reboot the machine fails to run through the startup scripts and
dies somewhere within mount.
I have found that kernels without the lvm-1.0.1 upgrade patch are able to
carry on and even fix the half created snapshot whereas kernels with the
lvm-1.0.1 upgrade patch are unable to deal with the problem snapshot and just
die.
Are you aware of what this might be?
And if this is going to be the default behaviour in future versions of LVM
how would I recover using a lvm-1.0.1 patched kernel?
Just interested
Thanks
- --
Adrian Head
(Public Key available on request.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8NnUR8ZJI8OvSkAcRAnegAJ9rayag2AQ7AMKufbL0d7PlxB3jxwCdGaQz
UKinrM4ZVskDCt13J+3HAs0=
=UDmt
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
[not found] ` <200201050212.TAA16774@cthulhu.turbolabs.com>
@ 2002-01-05 15:29 ` Andreas Dilger
2002-01-10 9:22 ` Adrian Head
[not found] ` <200201101521.IAA17651@cthulhu.turbolabs.com>
0 siblings, 2 replies; 27+ messages in thread
From: Andreas Dilger @ 2002-01-05 15:29 UTC (permalink / raw)
To: Adrian Head; +Cc: Eric Sandeen, Linux XFS Mailing List, linux-lvm
On Jan 05, 2002 12:12 +1000, Adrian Head wrote:
> On Sat, 5 Jan 2002 09:39, Andreas Dilger wrote:
> > Can you repeat this test, but skip the ext3 snapshot creation part of it
> > entirely (i.e. create a reiserfs snapshot and an XFS snapshot, without
> > changing the kernel)? I'm wondering if XFS is getting an old inode that
> > ext3 was using, but either ext3 or XFS is not clearing it, so that is why
> > it is calling into ext3. Also, are you using ext3 on other filesystems in
> > this computer?
>
> Yes there are other volumes using ext3.
> /boot 20M ext3
> / 512M ext3
> /usr 512M ext3
> /var 512M ext3
> swap 768M
> /tmp 128M reiserfs LVM
> /cache 512M reiserfs LVM
> /chroot 512M ext3 LVM
> /usr/src 4096Mreiserfs LVM
> /data ~30G xfs LVM
>
> the tests are done on /chroot for ext3,
> /usr/src for resierfs & /data for xfs.
>
> I can skip the ext3 snapshot creation part - each test is done on its own
> logical volume; however, in the dark dim past any of these could have had
> other filesystems on them.
> Does this sound sensible?
> 1) Run tests without doing the ext3 snapshot creation, then
> 2) dd the entire lv that is giving problems and try again?
Hmm, no I'm not worried about old filesystems on the disk. I thought
maybe you were running the tests on the same LV, and creating new
filesystems on a single LV between the tests. What I'm worried about
is old inodes being kept in memory between the tests. If the tests are
being run on separate LVs, then that is not a possibility.
I guess what is needed is a real oops report from the ext3 problem.
Maybe Andrew or Stephen can figure it out.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-04 20:44 ` Adrian Head
@ 2002-01-05 17:06 ` Andreas Dilger
0 siblings, 0 replies; 27+ messages in thread
From: Andreas Dilger @ 2002-01-05 17:06 UTC (permalink / raw)
To: Adrian Head; +Cc: Eric Sandeen, Linux XFS Mailing List, linux-lvm
On Jan 05, 2002 12:46 +1000, Adrian Head wrote:
> This is the full output from kdb when trying to create a snapshot on an XFS
> volume for me.
I've forwarded this to ext2-devel so the ext3 folks see it.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] lvm-1.0.1rc4(ish) more robust on startup than lvm-1.0.1
2002-01-04 21:35 ` Adrian Head
@ 2002-01-06 0:05 ` Adrian Head
0 siblings, 0 replies; 27+ messages in thread
From: Adrian Head @ 2002-01-06 0:05 UTC (permalink / raw)
To: linux-lvm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is some more info for those that are interested.
On Sat, 5 Jan 2002 13:37, Adrian Head wrote:
> Andreas or any other LVM gurus,
>
> When lvcreate dies when creating an XFS snapshot it doesn't finish the
> snapshot creation and although lvdisplay shows that the XFS lv has an
> active snapshot (shows even its name) lvdisplay tells me that the snapshot
> doesn't exist and therefore, cannot be removed.
>
> During the reboot the machine fails to run through the startup scripts and
> dies somewhere within mount.
>
> I have found that kernels without the lvm-1.0.1 upgrade patch are able to
> carry on and even fix the half created snapshot whereas kernels with the
> lvm-1.0.1 upgrade patch are unable to deal with the problem snapshot and
> just die.
>
> Are you aware of what this might be?
>
> how would I recover using a lvm-1.0.1 patched kernel?
>
> Just interested
>
> Thanks
What interests me here is that the lvm-1.0.1rc4(ish) seems to be more robust
then lvm-1.0.1 when dealing with a failed LV creation.
What seems to happen is that the snapshot is partially registered in the
kernel. The snapshot appears in the "/proc/lvm/global" as well as in the
"/proc/lvm/VGs/HDA/LVs/". However, "/dev/HDA/SNAP" is missing and I can
generate it by doing a vgscan and a lvscan. However, this does not fix the
kernel from dying upon a reboot.
The only way I have found to recover from this situation is to use an old
kernel that has only lvm-1.0.1rc4(ish) - this kernel does not Oops upon boot
and fixes the failed snapshot so that either it can be used later or removed
correctly.
The procedure goes something like this:
1) create snapshot on an XFS partition - it fails with an Oops.
at this point I can not view or remove the failed snapshot although it
appears in the correct places in /proc. The /dev/vg/lv entries are missing.
2) During the startup after a boot the machine dies after multiple Oopses and
dies finally with a Kernel panic. The kdb ouput from the start-up is
appended below.
3) Reboot using an old kernel with lvm-1.0.1rc4(ish) and everything starts
fine. You can then lvremove without a problem.
4) I can then reboot into a kernel that has been upgraded to lvm-1.0.1
without a problem.
The system is based on a minimal install of RH7.2 using a SGI XFS CVS kernel.
2.4.17-xfs
+ lvm-1.0.1 upgrade (from LVM CVS)
+ VFS-lock patch
Is there any other info people need?
Once the XFS snapshot creation has failed this is what happens during the boot
process after the reboot.
Unable to handle kernel NULL pointer dereference at virtual address 00000098
*pde = 00000000
Entering kdb (current=0xd75a4000, pid 152) Oops: Oops
due to oops @ 0xc0144e9e
eax = 0x00000080 ebx = 0xd8f69720 ecx = 0xc1606340 edx = 0xd75a4000
esi = 0xd6b7a000 edi = 0xd75a5f64 esp = 0xd75a5f08 eip = 0xc0144e9e
ebp = 0xc1606600 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd75a5ed4
kdb> bt
EBP EIP Function(args)
0xc1606600 0xc0144e9e do_add_mount+0xfe (0xd75a5f64, 0xd6b7b000, 0x0, 0x0,
0xd6b7a000)
kernel .text 0xc0100000 0xc0144da0 0xc0144f60
0xc0145137 do_mount+0x137 (0xd6b7a000, 0xd7972000, 0xd6b7b000,
0xc0ed0000, 0xd6b79000)
kernel .text 0xc0100000 0xc0145000 0xc0145160
0xc01451d4 sys_mount+0x74 (0x807f730, 0x807f748, 0x807f758,
0xc0ed0000, 0x807f788)
kernel .text 0xc0100000 0xc0145160 0xc0145210
0xc0106d1b system_call+0x33
kernel .text 0xc0100000 0xc0106ce8 0xc0106d20
kdb> btp 152
EBP EIP Function(args)
0xc0139b4e 0xc0144e9e do_add_mount+0xfe (0xd75a5f64, 0xd6b7b000, 0x0, 0x0,
0xd6b7a000)
kernel .text 0xc0100000 0xc0144da0 0xc0144f60
0xc0145137 do_mount+0x137 (0xd6b7a000, 0xd7972000, 0xd6b7b000,
0xc0ed0000, 0xd6b79000)
kernel .text 0xc0100000 0xc0145000 0xc0145160
0xc01451d4 sys_mount+0x74 (0x807f730, 0x807f748, 0x807f758,
0xc0ed0000, 0x807f788)
kernel .text 0xc0100000 0xc0145160 0xc0145210
0xc0106d1b system_call+0x33
kernel .text 0xc0100000 0xc0106ce8 0xc0106d20
kdb> ps
Task Addr Pid Parent [*] cpu State Thread Command
0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270 init
0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd
0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0
0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd
0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush
0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated
0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd
0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d
0xd7b32000 00000009 00000001 1 000 stop 0xd7b32270 kjournald
0xd7982000 00000010 00000001 1 000 stop 0xd7982270 init
0xd796e000 00000011 00000010 1 000 stop 0xd796e270 rc.sysinit
0xd7838000 00000012 00000011 1 000 stop 0xd7838270 initlog
0xd74ba000 00000111 00000001 1 000 stop 0xd74ba270 minilogd
0xd74da000 00000151 00000011 1 000 stop 0xd74da270 initlog
0xd75a4000 00000152 00000151 1 000 run 0xd75a4270*mount
0xd6e54000 00000153 00000152 1 000 stop 0xd6e54270 kjournald
0xd6e48000 00000154 00000152 1 000 stop 0xd6e48270 kjournald
0xd6e40000 00000155 00000152 1 000 stop 0xd6e40270 kjournald
0xd6d22000 00000157 00000152 1 000 run 0xd6d22270 kreiserfsd
0xd6c5c000 00000158 00000152 1 000 stop 0xd6c5c270 kjournald
0xd6b16000 00000160 00000001 1 000 stop 0xd6b16270 pagebuf_daemon
more>
kdb> id %eip
0xc0144e9e do_add_mount+0xfe: mov 0x18(%eax),%esi
0xc0144ea1 do_add_mount+0x101: test %esi,%esi
0xc0144ea3 do_add_mount+0x103: je 0xc0144eae do_add_mount+0x10e:
0xc0144ea5 do_add_mount+0x105: incl 0x28(%esi)
0xc0144ea8 do_add_mount+0x108: mov 0x550(%edx),%eax
0xc0144eae do_add_mount+0x10e: mov 0xc(%eax),%ebx
0xc0144eb1 do_add_mount+0x111: mov %esi,%edi
0xc0144eb3 do_add_mount+0x113: test %ebx,%ebx
0xc0144eb5 do_add_mount+0x115: je 0xc0144ec1 do_add_mount+0x121:
0xc0144eb7 do_add_mount+0x117: mov (%ebx),%eax
0xc0144eb9 do_add_mount+0x119: test %eax,%eax
0xc0144ebb do_add_mount+0x11b: jne 0xc0144ebf do_add_mount+0x11f:
0xc0144ebd do_add_mount+0x11d: ud2a
0xc0144ebf do_add_mount+0x11f: incl (%ebx)
0xc0144ec1 do_add_mount+0x121: push $0x1000
0xc0144ec6 do_add_mount+0x126: pushl 0xc(%esp,1)
kdb> go
Oops: 0000
CPU: 0
EIP: 0010:[<c0144e9e>] Not tainted
EFLAGS: 00010286
eax: 00000080 ebx: d8f69720 ecx: c1606340 edx: d75a4000
esi: d6b7a000 edi: d75a5f64 ebp: c1606600 esp: d75a5f08
ds: 0018 es: 0018 ss: 0018
Process mount (pid: 152, stackpage=d75a5000)
Stack: c0139b4e d76741c0 d6674000 d797200a d76741c0 00000000 d7b30700 d75a4000
00000000 c0111e10 00000000 00000000 d7972000 d75a5f64 00000000 c0145137
d75a5f64 d6b7b000 00000000 00000000 d6b7a000 d6b79000 00000000 d76741c0
Call Trace: [<c0139b4e>] [<c0111e10>] [<c0145137>] [<c0144fac>] [<c01451d4>]
[<c0106d1b>]
Code: 8b 70 18 85 f6 74 09 ff 46 28 8b 82 50 05 00 00 8b 58 0c 89
<1>Unable to handle kernel NULL pointer dereference at virtual address
00000080 printing eip:
c0117c74
*pde = 00000000
Entering kdb (current=0xd75a4000, pid 152) Oops: Oops
due to oops @ 0xc0117c74
eax = 0x00000000 ebx = 0x00000080 ecx = 0x00000032 edx = 0xd75a4264
esi = 0xd75a4000 edi = 0x0000000b esp = 0xd75a5da4 eip = 0xc0117c74
ebp = 0xc0227590 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010202
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd75a5d70
kdb> go
Oops: 0002
CPU: 0
EIP: 0010:[<c0117c74>] Not tainted
EFLAGS: 00010202
eax: 00000000 ebx: 00000080 ecx: 00000032 edx: d75a4264
esi: d75a4000 edi: 0000000b ebp: c0227590 esp: d75a5da4
ds: 0018 es: 0018 ss: 0018
Process mount (pid: 152, stackpage=d75a5000)
Stack: 00000000 c0227590 c010a478 00000001 c02350fa c02c63e8 c02c4da0 00000000
c0227590 00000001 00000018 00000018 00000001 c02c4da0 00000000 c0107411
0000000b 000036ff 00000282 c0322e53 00000202 c0115484 00000000 c0144e9e
Call Trace: [<c010a478>] [<c0107411>] [<c0115484>] [<c0144e9e>] [<c0144e9e>]
[<c0112176>] [<c01392ff>] [<c0135605>] [<d8f6f028>] [<c014412b>]
[<c0111e10>]
[<c0106e0c>] [<d8f69720>] [<c0144e9e>] [<c0139b4e>] [<c0111e10>]
[<c0145137>]
[<c0144fac>] [<c01451d4>] [<c0106d1b>]
Code: ff 0b 0f 94 c0 84 c0 74 76 ff 73 0c e8 9b 8d 02 00 8b 53 18
<1>Unable to handle kernel NULL pointer dereference at virtual address
0000000c printing eip:
c0129cb9
*pde = 00000000
Entering kdb (current=0xd75a4000, pid 152) Oops: Oops
due to oops @ 0xc0129cb9
eax = 0x00632840 ebx = 0xc1607360 ecx = 0x00000000 edx = 0x00000000
esi = 0x00000096 edi = 0xd8ca1000 esp = 0xd75a5c0c eip = 0xc0129cb9
ebp = 0xc0227590 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010046
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd75a5bd8
kdb> go
Oops: 0000
CPU: 0
EIP: 0010:[<c0129cb9>] Not tainted
EFLAGS: 00010046
eax: 00632840 ebx: c1607360 ecx: 00000000 edx: 00000000
esi: 00000096 edi: d8ca1000 ebp: c0227590 esp: d75a5c0c
ds: 0018 es: 0018 ss: 0018
Process mount (pid: 152, stackpage=d75a5000)
Stack: 00000000 00000400 d75a4000 0000000b c011cc0e c1607360 d8ca1000 d75a4000
c011cc84 d75a4568 00000000 c0117cf9 d75a4000 00000002 c0227590 c010a478
00000001 c02350fa c02c63e8 c02c4da0 00000002 c0227590 00000001 00000018
Call Trace: [<c011cc0e>] [<c011cc84>] [<c0117cf9>] [<c010a478>] [<c0107411>]
[<c0115484>] [<c0117c74>] [<c0111e10>] [<c0117c74>] [<c0111e10>]
[<c0112176>]
[<c0121ba8>] [<c0121821>] [<c0111e10>] [<c0106e0c>] [<c0117c74>]
[<c010a478>]
[<c0107411>] [<c0115484>] [<c0144e9e>] [<c0144e9e>] [<c0112176>]
[<c01392ff>]
[<c0135605>] [<d8f6f028>] [<c014412b>] [<c0111e10>] [<c0106e0c>]
[<d8f69720>]
[<c0144e9e>] [<c0139b4e>] [<c0111e10>] [<c0145137>] [<c0144fac>]
[<c01451d4>]
[<c0106d1b>]
Code: 2b 79 0c 89 f8 f7 73 18 89 c7 8b 41 14 89 44 b9 18 89 79 14
<1>Unable to handle kernel paging request at virtual address 002aad20
printing eip:
c012b40e
*pde = 00000000
Entering kdb (current=0xd74da000, pid 182) Oops: Oops
due to oops @ 0xc012b40e
eax = 0x00002bea ebx = 0xc15bd500 ecx = 0x00000003 edx = 0x002aa7a4
esi = 0xc02c7698 edi = 0x00000002 esp = 0xd74dbe3c eip = 0xc012b40e
ebp = 0x00015f54 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010013
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd74dbe08
kdb> bt
EBP EIP Function(args)
0x00015f54 0xc012b40e rmqueue+0x8e
kernel .text 0xc0100000 0xc012b380 0xc012b540
0xc012b73f __alloc_pages+0x3f
kernel .text 0xc0100000 0xc012b700 0xc012b880
kdb> btp 182
EBP EIP Function(args)
0xd6af1cc0 0xc012b40e rmqueue+0x8e
kernel .text 0xc0100000 0xc012b380 0xc012b540
0xc012b73f __alloc_pages+0x3f
kernel .text 0xc0100000 0xc012b700 0xc012b880
kdb> ps
Task Addr Pid Parent [*] cpu State Thread Command
0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270 init
0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd
0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0
0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd
0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush
0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated
0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd
0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d
0xd7b32000 00000009 00000001 1 000 stop 0xd7b32270 kjournald
0xd7982000 00000010 00000001 1 000 stop 0xd7982270 init
0xd796e000 00000011 00000010 1 000 stop 0xd796e270 rc.sysinit
0xd7838000 00000012 00000011 1 000 stop 0xd7838270 initlog
0xd74ba000 00000111 00000001 1 000 stop 0xd74ba270 minilogd
0xd6e54000 00000153 00000001 1 000 stop 0xd6e54270 kjournald
0xd6e48000 00000154 00000001 1 000 stop 0xd6e48270 kjournald
0xd6e40000 00000155 00000001 1 000 stop 0xd6e40270 kjournald
0xd6d22000 00000157 00000001 1 000 stop 0xd6d22270 kreiserfsd
0xd6c5c000 00000158 00000001 1 000 stop 0xd6c5c270 kjournald
0xd6b16000 00000160 00000001 1 000 stop 0xd6b16270 pagebuf_daemon
0xd74da000 00000182 00000011 1 000 run 0xd74da270*pam_console_app
kdb> id %eip
0xc012b40e rmqueue+0x8e: btc %eax,(%edx)
0xc012b411 rmqueue+0x91: movzbl 0x8(%esp,1),%ecx
0xc012b416 rmqueue+0x96: mov 0xc(%esp,1),%edx
0xc012b41a rmqueue+0x9a: mov $0x1,%eax
0xc012b41f rmqueue+0x9f: shl %cl,%eax
0xc012b421 rmqueue+0xa1: sub %eax,0x4(%edx)
0xc012b424 rmqueue+0xa4: mov %ebp,(%esp,1)
0xc012b427 rmqueue+0xa7: mov %edi,%ebp
0xc012b429 rmqueue+0xa9: mov %ebp,%ecx
0xc012b42b rmqueue+0xab: mov $0x1,%edi
0xc012b430 rmqueue+0xb0: shl %cl,%edi
0xc012b432 rmqueue+0xb2: cmp 0x8(%esp,1),%ebp
0xc012b436 rmqueue+0xb6: jle 0xc012b49e rmqueue+0x11e:
0xc012b438 rmqueue+0xb8: nop
0xc012b439 rmqueue+0xb9: lea 0x0(%esi,1),%esi
0xc012b440 rmqueue+0xc0: mov 0xc(%esp,1),%eax
kdb> go
Oops: 0002
CPU: 0
EIP: 0010:[<c012b40e>] Not tainted
EFLAGS: 00010013
eax: 00002bea ebx: c15bd500 ecx: 00000003 edx: 002aa7a4
esi: c02c7698 edi: 00000002 ebp: 00015f54 esp: d74dbe3c
ds: 0018 es: 0018 ss: 0018
Process pam_console_app (pid: 182, stackpage=d74db000)
Stack: d6af1cc0 00000286 00000000 c02c7668 c02c77bc 000001ff 00000000 00000000
c012b73f c02c7668 c02c77b8 000001f0 d7720680 00000202 c1607130 000001f0
00000000 c012b890 c0129996 00000001 000001f0 d7ed4874 00000000 d7720680
Call Trace: [<c012b73f>] [<c012b890>] [<c0129996>] [<c015cec5>] [<c0129b89>]
[<c0157012>] [<c0141087>] [<c01393a5>] [<c01399f0>] [<c013910d>]
[<c0139f83>]
[<c01371c4>] [<c0123b92>] [<c0106d1b>]
Code: 0f bb 02 0f b6 4c 24 08 8b 54 24 0c b8 01 00 00 00 d3 e0 29
<1>Unable to handle kernel paging request at virtual address 002aad1c
printing eip:
c012b40e
*pde = 00000000
Entering kdb (current=0xd796e000, pid 11) Oops: Oops
due to oops @ 0xc012b40e
eax = 0x00002bcc ebx = 0xc15b9800 ecx = 0x00000003 edx = 0x002aa7a4
esi = 0xc02c7698 edi = 0x00000002 esp = 0xd796fe54 eip = 0xc012b40e
ebp = 0x00015e60 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd796fe20
kdb> bt
EBP EIP Function(args)
0x00015e60 0xc012b40e rmqueue+0x8e (0xc02c7668, 0xc02c77d8, 0x1d2,
0xc0208f4f, 0x0)
kernel .text 0xc0100000 0xc012b380 0xc012b540
0xc012b73f __alloc_pages+0x3f (0xd796ffc4, 0x7, 0xcf, 0x80e498c,
0x13)
kernel .text 0xc0100000 0xc012b700 0xc012b880
0xc0106e0c error_code+0x34
kernel .text 0xc0100000 0xc0106dd8 0xc0106e14
Interrupt registers:
eax = 0x080e4980 ebx = 0xd796ffc4 ecx = 0x00000007 edx = 0x000000cf
esi = 0x080e498c edi = 0x00000013 esp = 0x00000023 eip = 0x0000002b
ebp = 0x080e498c xss = 0x00010202 xcs = 0xffffffff eflags = 0x080ac410
xds = 0xbffff838 xes = 0x080e498c origeax = 0x0000002b ®s = 0xd796ffbc
Interrupt from user space, end of kernel trace
kdb> btp 11
EBP EIP Function(args)
0x00015810 0xc012b40e rmqueue+0x8e (0xc02c7668, 0xc02c77d8, 0x1d2,
0xc0208f4f, 0x0)
kernel .text 0xc0100000 0xc012b380 0xc012b540
0xc012b73f __alloc_pages+0x3f (0xd796ffc4, 0x7, 0xcf, 0x80e498c,
0x13)
kernel .text 0xc0100000 0xc012b700 0xc012b880
0xc0106e0c error_code+0x34
kernel .text 0xc0100000 0xc0106dd8 0xc0106e14
Interrupt registers:
eax = 0x080e4980 ebx = 0xd796ffc4 ecx = 0x00000007 edx = 0x000000cf
esi = 0x080e498c edi = 0x00000013 esp = 0x00000023 eip = 0x0000002b
ebp = 0x080e498c xss = 0x00010202 xcs = 0xffffffff eflags = 0x080ac410
xds = 0xbffff838 xes = 0x080e498c origeax = 0x0000002b ®s = 0xd796ffbc
Interrupt from user space, end of kernel trace
kdb> ps
Task Addr Pid Parent [*] cpu State Thread Command
0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270 init
0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd
0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0
0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd
0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush
0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated
0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd
0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d
0xd7b32000 00000009 00000001 1 000 stop 0xd7b32270 kjournald
0xd7982000 00000010 00000001 1 000 stop 0xd7982270 init
0xd796e000 00000011 00000010 1 000 run 0xd796e270*rc.sysinit
0xd7838000 00000012 00000011 1 000 stop 0xd7838270 initlog
0xd74ba000 00000111 00000001 1 000 stop 0xd74ba270 minilogd
0xd6e54000 00000153 00000001 1 000 stop 0xd6e54270 kjournald
0xd6e48000 00000154 00000001 1 000 stop 0xd6e48270 kjournald
0xd6e40000 00000155 00000001 1 000 stop 0xd6e40270 kjournald
0xd6d22000 00000157 00000001 1 000 stop 0xd6d22270 kreiserfsd
0xd6c5c000 00000158 00000001 1 000 stop 0xd6c5c270 kjournald
0xd6b16000 00000160 00000001 1 000 stop 0xd6b16270 pagebuf_daemon
0xd74da000 00000183 00000011 1 000 run 0xd74da270 rc.sysinit
kdb> id %eip
0xc012b40e rmqueue+0x8e: btc %eax,(%edx)
0xc012b411 rmqueue+0x91: movzbl 0x8(%esp,1),%ecx
0xc012b416 rmqueue+0x96: mov 0xc(%esp,1),%edx
0xc012b41a rmqueue+0x9a: mov $0x1,%eax
0xc012b41f rmqueue+0x9f: shl %cl,%eax
0xc012b421 rmqueue+0xa1: sub %eax,0x4(%edx)
0xc012b424 rmqueue+0xa4: mov %ebp,(%esp,1)
0xc012b427 rmqueue+0xa7: mov %edi,%ebp
0xc012b429 rmqueue+0xa9: mov %ebp,%ecx
0xc012b42b rmqueue+0xab: mov $0x1,%edi
0xc012b430 rmqueue+0xb0: shl %cl,%edi
0xc012b432 rmqueue+0xb2: cmp 0x8(%esp,1),%ebp
0xc012b436 rmqueue+0xb6: jle 0xc012b49e rmqueue+0x11e:
0xc012b438 rmqueue+0xb8: nop
0xc012b439 rmqueue+0xb9: lea 0x0(%esi,1),%esi
0xc012b440 rmqueue+0xc0: mov 0xc(%esp,1),%eax
kdb> go
Oops: 0002
CPU: 0
EIP: 0010:[<c012b40e>] Not tainted
EFLAGS: 00010016
eax: 00002bcc ebx: c15b9800 ecx: 00000003 edx: 002aa7a4
esi: c02c7698 edi: 00000002 ebp: 00015e60 esp: d796fe54
ds: 0018 es: 0018 ss: 0018
Process rc.sysinit (pid: 11, stackpage=d796f000)
Stack: 00015810 00000282 00000000 c02c7668 c02c77dc 000001ff 00000000 080e498c
c012b73f c02c7668 c02c77d8 000001d2 c0208f4f 00000000 c15950c0 16543065
080e498c c0122505 c02c7668 c02c77bc 000001ff 00000000 080e498c 00000001
Call Trace: [<c012b73f>] [<c0208f4f>] [<c0122505>] [<c0122ae6>] [<c0122b7a>]
[<c020a341>] [<c0111f8e>] [<c012b73f>] [<c01148b7>] [<c01309c0>]
[<c0111e10>]
[<c0106e0c>]
Code: 0f bb 02 0f b6 4c 24 08 8b 54 24 0c b8 01 00 00 00 d3 e0 29
<1>Unable to handle kernel paging request at virtual address 002aad48
printing eip:
c012b2fe
*pde = 00000000
Entering kdb (current=0xd7982000, pid 10) Oops: Oops
due to oops @ 0xc012b2fe
eax = 0xc02c76f8 ebx = 0xc02c7668 ecx = 0xc02c7698 edx = 0x002aa7a4
esi = 0x0001696c edi = 0x00002d2d esp = 0xd7983f68 eip = 0xc012b2fe
ebp = 0xc15e5b80 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010087
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd7983f34
kdb> bt
EBP EIP Function(args)
0xc15e5b80 0xc012b2fe __free_pages_ok+0x16e
kernel .text 0xc0100000 0xc012b190 0xc012b380
kdb> btp 10
EBP EIP Function(args)
0xc1040000 0xc012b2fe __free_pages_ok+0x16e
kernel .text 0xc0100000 0xc012b190 0xc012b380
kdb> ps
Task Addr Pid Parent [*] cpu State Thread Command
0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270 init
0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd
0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0
0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd
0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush
0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated
0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd
0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d
0xd7b32000 00000009 00000001 1 000 stop 0xd7b32270 kjournald
0xd7982000 00000010 00000001 1 000 stop 0xd7982270*init
0xd7838000 00000012 00000001 1 000 stop 0xd7838270 initlog
0xd74ba000 00000111 00000001 1 000 stop 0xd74ba270 minilogd
0xd6e54000 00000153 00000001 1 000 stop 0xd6e54270 kjournald
0xd6e48000 00000154 00000001 1 000 stop 0xd6e48270 kjournald
0xd6e40000 00000155 00000001 1 000 stop 0xd6e40270 kjournald
0xd6d22000 00000157 00000001 1 000 stop 0xd6d22270 kreiserfsd
0xd6c5c000 00000158 00000001 1 000 stop 0xd6c5c270 kjournald
0xd6b16000 00000160 00000001 1 000 stop 0xd6b16270 pagebuf_daemon
0xd74da000 00000183 00000001 1 000 run 0xd74da270 rc.sysinit
kdb> id %eip
0xc012b2fe __free_pages_ok+0x16e: btc %edi,(%edx)
0xc012b301 __free_pages_ok+0x171: sbb %eax,%eax
0xc012b303 __free_pages_ok+0x173: test %eax,%eax
0xc012b305 __free_pages_ok+0x175: jne 0xc012b260
__free_pages_ok+0xd0: 0xc012b30b __free_pages_ok+0x17b: mov
(%esp,1),%edx
0xc012b30e __free_pages_ok+0x17e: mov 0x4(%esp,1),%ecx
0xc012b312 __free_pages_ok+0x182: shl $0x6,%esi
0xc012b315 __free_pages_ok+0x185: lea (%edx,%esi,1),%eax
0xc012b318 __free_pages_ok+0x188: mov (%ecx),%edx
0xc012b31a __free_pages_ok+0x18a: mov %eax,0x4(%edx)
0xc012b31d __free_pages_ok+0x18d: mov %edx,(%eax)
0xc012b31f __free_pages_ok+0x18f: mov %ecx,0x4(%eax)
0xc012b322 __free_pages_ok+0x192: mov %eax,(%ecx)
0xc012b324 __free_pages_ok+0x194: pushl 0x8(%esp,1)
0xc012b328 __free_pages_ok+0x198: popf
0xc012b329 __free_pages_ok+0x199: jmp 0xc012b36c
__free_pages_ok+0x1dc:kdb> go
Oops: 0002
CPU: 0
EIP: 0010:[<c012b2fe>] Not tainted
EFLAGS: 00010087
eax: c02c76f8 ebx: c02c7668 ecx: c02c7698 edx: 002aa7a4
esi: 0001696c edi: 00002d2d ebp: c15e5b80 esp: d7983f68
ds: 0018 es: 0018 ss: 0018
Process init (pid: 10, stackpage=d7983000)
Stack: c1040000 c02c7698 00000213 fffffffc d796e000 d7982000 0000000b 0000000b
c01180c6 d796e000 00000000 d7982000 00000000 00000000 00000000 d7982000
d79820bc d79820bc d7982000 00000000 00000000 bffff7f8 c0106d1b 0000000b
Call Trace: [<c01180c6>] [<c0106d1b>]
Code: 0f bb 3a 19 c0 85 c0 0f 85 55 ff ff ff 8b 14 24 8b 4c 24 04
<1>Unable to handle kernel paging request at virtual address 002aad48
printing eip:
c012b2fe
*pde = 00000000
Entering kdb (current=0xd7fe2000, pid 1) Oops: Oops
due to oops @ 0xc012b2fe
eax = 0xc02c76f8 ebx = 0xc02c7668 ecx = 0xc02c7698 edx = 0x002aa7a4
esi = 0x00016980 edi = 0x00002d30 esp = 0xd7fe3f68 eip = 0xc012b2fe
ebp = 0xc15e6080 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010087
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd7fe3f34
kdb> bt
EBP EIP Function(args)
0xc15e6080 0xc012b2fe __free_pages_ok+0x16e
kernel .text 0xc0100000 0xc012b190 0xc012b380
kdb> btp 1
EBP EIP Function(args)
0xc1040000 0xc012b2fe __free_pages_ok+0x16e
kernel .text 0xc0100000 0xc012b190 0xc012b380
kdb> ps
Task Addr Pid Parent [*] cpu State Thread Command
0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270*init
0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd
0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0
0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd
0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush
0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated
0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd
0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d
0xd7b32000 00000009 00000001 1 000 stop 0xd7b32270 kjournald
0xd7838000 00000012 00000001 1 000 run 0xd7838270 initlog
0xd74ba000 00000111 00000001 1 000 stop 0xd74ba270 minilogd
0xd6e54000 00000153 00000001 1 000 stop 0xd6e54270 kjournald
0xd6e48000 00000154 00000001 1 000 stop 0xd6e48270 kjournald
0xd6e40000 00000155 00000001 1 000 stop 0xd6e40270 kjournald
0xd6d22000 00000157 00000001 1 000 stop 0xd6d22270 kreiserfsd
0xd6c5c000 00000158 00000001 1 000 stop 0xd6c5c270 kjournald
0xd6b16000 00000160 00000001 1 000 stop 0xd6b16270 pagebuf_daemon
0xd74da000 00000183 00000001 1 000 run 0xd74da270 rc.sysinit
kdb> id %eip
0xc012b2fe __free_pages_ok+0x16e: btc %edi,(%edx)
0xc012b301 __free_pages_ok+0x171: sbb %eax,%eax
0xc012b303 __free_pages_ok+0x173: test %eax,%eax
0xc012b305 __free_pages_ok+0x175: jne 0xc012b260
__free_pages_ok+0xd0: 0xc012b30b __free_pages_ok+0x17b: mov
(%esp,1),%edx
0xc012b30e __free_pages_ok+0x17e: mov 0x4(%esp,1),%ecx
0xc012b312 __free_pages_ok+0x182: shl $0x6,%esi
0xc012b315 __free_pages_ok+0x185: lea (%edx,%esi,1),%eax
0xc012b318 __free_pages_ok+0x188: mov (%ecx),%edx
0xc012b31a __free_pages_ok+0x18a: mov %eax,0x4(%edx)
0xc012b31d __free_pages_ok+0x18d: mov %edx,(%eax)
0xc012b31f __free_pages_ok+0x18f: mov %ecx,0x4(%eax)
0xc012b322 __free_pages_ok+0x192: mov %eax,(%ecx)
0xc012b324 __free_pages_ok+0x194: pushl 0x8(%esp,1)
0xc012b328 __free_pages_ok+0x198: popf
0xc012b329 __free_pages_ok+0x199: jmp 0xc012b36c
__free_pages_ok+0x1dc:kdb> go
Oops: 0002
CPU: 0
EIP: 0010:[<c012b2fe>] Not tainted
EFLAGS: 00010087
eax: c02c76f8 ebx: c02c7668 ecx: c02c7698 edx: 002aa7a4
esi: 00016980 edi: 00002d30 ebp: c15e6080 esp: d7fe3f68
ds: 0018 es: 0018 ss: 0018
Process init (pid: 1, stackpage=d7fe3000)
Stack: c1040000 c02c7698 00000217 fffffffc d7982000 d7fe2000 0000000a ffffffff
c01180c6 d7982000 00000000 d7fe2000 00000000 00000000 00000000 d7fe2000
d7fe20bc d7fe20bc d7fe2000 00000000 bffff52c bffff50c c0106d1b ffffffff
Call Trace: [<c01180c6>] [<c0106d1b>]
Code: 0f bb 3a 19 c0 85 c0 0f 85 55 ff ff ff 8b 14 24 8b 4c 24 04
<0>Kernel panic: Attempted to kill init!
Entering kdb (current=0xd7fe2000, pid 1) due to panic
kdb> bt
Stack is not in kernel space, backtrace not available
kdb>
- --
Adrian Head
(Public Key available on request.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8N+mN8ZJI8OvSkAcRAoKyAJ952XozB1v8dSS8A8k8sdW/4iYDIQCfZjBR
Nizi+BpBBeeAzCty9RSQo5g=
=jW02
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
[not found] ` <200201050346.g053kmg29738@oss.sgi.com>
2002-01-04 21:08 ` Eric Sandeen
@ 2002-01-06 0:20 ` Adrian Head
1 sibling, 0 replies; 27+ messages in thread
From: Adrian Head @ 2002-01-06 0:20 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Linux XFS Mailing List, linux-lvm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have upgraded the lvm in the kernel to the CVS version from the sistina
site. The lvm-1.0.1 upgrade patch it generates is different from the
previous one used. The kdb output is pretty much identical though.
What I will do next is to remove ext3 from the kernel and see what happens as
well as upgrade to the ext3 CVS and see what happens.
This is the full Oops output when trying to create an XFS snapshot.
2.4.17-xfs
+ lvm-1.0.1 upgrade (from LVM CVS)
+ VFS-lock
Entering kdb (current=0xd5db2000, pid 934) Oops: Oops
due to oops @ 0xc015bc06
eax = 0x748b5356 ebx = 0xc019fdf0 ecx = 0xd7894040 edx = 0x00000000
esi = 0xd5db2000 edi = 0xd7894040 esp = 0xd5db3eac eip = 0xc015bc06
ebp = 0xd7ed4800 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd5db3e78
kdb> bt
EBP EIP Function(args)
0xd7ed4800 0xc015bc06 journal_start+0x36 (0xd7ed4800, 0x1, 0x40018000,
0xd5db3f5c, 0x2)
kernel .text 0xc0100000 0xc015bbd0 0xc015bcb0
0xc0156fd8 ext3_dirty_inode+0x58 (0xd7894040)
kernel .text 0xc0100000 0xc0156f80 0xc0157050
0xc0141b1e __mark_inode_dirty+0x2e (0xd7894040, 0x1)
kernel .text 0xc0100000 0xc0141af0 0xc0141b70
0xc0143001 update_atime+0x51 (0xd7894040, 0x6d6, 0x1, 0x0, 0x6d6)
kernel .text 0xc0100000 0xc0142fb0 0xc0143010
0xc01254ac do_generic_file_read+0x40c (0xd7757840, 0xd7757860,
0xd5db3f5c, 0xc0125690, 0x6d6)
kernel .text 0xc0100000 0xc01250a0 0xc01254c0
0xc012576a generic_file_read+0x7a (0xd7757840, 0x40018000, 0x1000,
0xd7757860, 0x0)
kernel .text 0xc0100000 0xc01256f0 0xc0125810
0xc0130cf5 sys_read+0x95 (0x4, 0x40018000, 0x1000, 0x8086ab0,
0x40018000)
kernel .text 0xc0100000 0xc0130c60 0xc0130d30
0xc0106d1b system_call+0x33
kernel .text 0xc0100000 0xc0106ce8 0xc0106d20
kdb> btp 934
EBP EIP Function(args)
0xc019fdf0 0xc015bc06 journal_start+0x36 (0xd7ed4800, 0x1, 0x40018000,
0xd5db3f5c, 0x2)
kernel .text 0xc0100000 0xc015bbd0 0xc015bcb0
0xc0156fd8 ext3_dirty_inode+0x58 (0xd7894040)
kernel .text 0xc0100000 0xc0156f80 0xc0157050
0xc0141b1e __mark_inode_dirty+0x2e (0xd7894040, 0x1)
kernel .text 0xc0100000 0xc0141af0 0xc0141b70
0xc0143001 update_atime+0x51 (0xd7894040, 0x6d6, 0x1, 0x0, 0x6d6)
kernel .text 0xc0100000 0xc0142fb0 0xc0143010
0xc01254ac do_generic_file_read+0x40c (0xd7757840, 0xd7757860,
0xd5db3f5c, 0xc0125690, 0x6d6)
kernel .text 0xc0100000 0xc01250a0 0xc01254c0
0xc012576a generic_file_read+0x7a (0xd7757840, 0x40018000, 0x1000,
0xd7757860, 0x0)
kernel .text 0xc0100000 0xc01256f0 0xc0125810
0xc0130cf5 sys_read+0x95 (0x4, 0x40018000, 0x1000, 0x8086ab0,
0x40018000)
kernel .text 0xc0100000 0xc0130c60 0xc0130d30
0xc0106d1b system_call+0x33
kernel .text 0xc0100000 0xc0106ce8 0xc0106d20
kdb> ps
Task Addr Pid Parent [*] cpu State Thread Command
0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270 init
0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd
0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0
0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd
0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush
0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated
0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd
0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d
0xd7b32000 00000009 00000001 1 000 stop 0xd7b32270 kjournald
0xd72a6000 00000153 00000001 1 000 stop 0xd72a6270 kjournald
0xd729a000 00000154 00000001 1 000 stop 0xd729a270 kjournald
0xd7292000 00000155 00000001 1 000 stop 0xd7292270 kjournald
0xd7172000 00000157 00000001 1 000 stop 0xd7172270 kreiserfsd
0xd70ac000 00000158 00000001 1 000 stop 0xd70ac270 kjournald
0xd6f68000 00000160 00000001 1 000 stop 0xd6f68270 pagebuf_daemon
0xd6256000 00000523 00000001 1 000 stop 0xd6256270 dhcpcd
0xd77e0000 00000659 00000001 1 000 stop 0xd77e0270 syslogd
0xd6212000 00000664 00000001 1 000 stop 0xd6212270 klogd
0xd61a2000 00000684 00000001 1 000 stop 0xd61a2270 portmap
0xd60aa000 00000712 00000001 1 000 stop 0xd60aa270 rpc.statd
0xd5f74000 00000825 00000001 1 000 stop 0xd5f74270 crond
more>
0xd5f5e000 00000861 00000001 1 000 stop 0xd5f5e270 atd
0xd602c000 00000868 00000001 1 000 stop 0xd602c270 login
0xd5f48000 00000869 00000001 1 000 stop 0xd5f48270 mingetty
0xd5fa2000 00000870 00000001 1 000 stop 0xd5fa2270 mingetty
0xd5f5a000 00000871 00000001 1 000 stop 0xd5f5a270 mingetty
0xd63a8000 00000872 00000001 1 000 stop 0xd63a8270 mingetty
0xd6008000 00000873 00000001 1 000 stop 0xd6008270 mingetty
0xd5f76000 00000874 00000001 1 000 stop 0xd5f76270 mgetty
0xd74aa000 00000877 00000868 1 000 stop 0xd74aa270 bash
0xd5db2000 00000934 00000877 1 000 run 0xd5db2270*lvcreate
kdb> id %eip
0xc015bc06 journal_start+0x36: cmp %ebp,(%eax)
0xc015bc08 journal_start+0x38: je 0xc015bc2d journal_start+0x5d:
0xc015bc0a journal_start+0x3a: push $0xc022e920
0xc015bc0f journal_start+0x3f: push $0xe1
0xc015bc14 journal_start+0x44: push $0xc022a62b
0xc015bc19 journal_start+0x49: push $0xc0229f00
0xc015bc1e journal_start+0x4e: push $0xc022c9e0
0xc015bc23 journal_start+0x53: call 0xc0115380 printk:
0xc015bc28 journal_start+0x58: ud2a
0xc015bc2a journal_start+0x5a: add $0x14,%esp
0xc015bc2d journal_start+0x5d: incl 0x8(%ebx)
0xc015bc30 journal_start+0x60: jmp 0xc015bca0 journal_start+0xd0:
0xc015bc32 journal_start+0x62: push $0x1
0xc015bc34 journal_start+0x64: push $0xf0
0xc015bc39 journal_start+0x69: push $0x14
0xc015bc3b journal_start+0x6b: push $0xc0229f00
kdb> go
Oops: 0000
CPU: 0
EIP: 0010:[<c015bc06>] Not tainted
EFLAGS: 00010286
eax: 748b5356 ebx: c019fdf0 ecx: d7894040 edx: 00000000
esi: d5db2000 edi: d7894040 ebp: d7ed4800 esp: d5db3eac
ds: 0018 es: 0018 ss: 0018
Process lvcreate (pid: 934, stackpage=d5db3000)
Stack: c019fdf0 c019fdf0 ffffffe2 d7894040 00000000 c0156fd8 d7ed4800 00000001
40018000 d5db3f5c 00000002 00000018 d7894040 d7b41000 00000001 c0141b1e
d7894040 3c385279 d7757860 d78940f0 c0143001 d7894040 00000001 00000000
Call Trace: [<c019fdf0>] [<c019fdf0>] [<c0156fd8>] [<c0141b1e>] [<c0143001>]
[<c01254ac>] [<c012576a>] [<c0125690>] [<c0130cf5>] [<c0106d1b>]
Code: 39 28 74 23 68 20 e9 22 c0 68 e1 00 00 00 68 2b a6 22 c0 68
On Sat, 5 Jan 2002 12:46, Adrian Head wrote:
> This is the full output from kdb when trying to create a snapshot on an XFS
> volume for me.
>
> What I was going to do next was follow Andreas Dilger's sugestion and try
> again.
>
> Entering kdb (current=0xc7228000, pid 1435) Oops: Oops
> due to oops @ 0xc015c446
> eax = 0x748b5356 ebx = 0xc01a1550 ecx = 0xd7894040 edx = 0x00000000
> esi = 0xc7228000 edi = 0xd7894040 esp = 0xc7229eac eip = 0xc015c446
> ebp = 0xd7ed4800 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286
> xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xc7229e78
> kdb> bt
> EBP EIP Function(args)
> 0xd7ed4800 0xc015c446 journal_start+0x36 (0xd7ed4800, 0x1, 0x40018000,
> 0xc7229f5c, 0x2)
> kernel .text 0xc0100000 0xc015c410
> 0xc015c4f0 0xc01571a8 ext3_dirty_inode+0x58 (0xd7894040)
> kernel .text 0xc0100000 0xc0157150
> 0xc0157250 0xc0141b1e __mark_inode_dirty+0x2e (0xd7894040, 0x1)
> kernel .text 0xc0100000 0xc0141af0
> 0xc0141b70 0xc0143001 update_atime+0x51 (0xd7894040, 0x6d6, 0x1, 0x0,
> 0x6d6) kernel .text 0xc0100000 0xc0142fb0 0xc0143010 0xc01254ac
> do_generic_file_read+0x40c (0xd5fc7740, 0xd5fc7760, 0xc7229f5c, 0xc0125690,
> 0x6d6)
> kernel .text 0xc0100000 0xc01250a0
> 0xc01254c0 0xc012576a generic_file_read+0x7a (0xd5fc7740, 0x40018000,
> 0x1000, 0xd5fc7760, 0x0)
> kernel .text 0xc0100000 0xc01256f0
> 0xc0125810 0xc0130cf5 sys_read+0x95 (0x4, 0x40018000, 0x1000, 0x8086ab0,
> 0x40018000)
> kernel .text 0xc0100000 0xc0130c60
> 0xc0130d30 0xc0106d1b system_call+0x33
> kernel .text 0xc0100000 0xc0106ce8
> 0xc0106d20 kdb> btp 1435
> EBP EIP Function(args)
> 0xc01a1550 0xc015c446 journal_start+0x36 (0xd7ed4800, 0x1, 0x40018000,
> 0xc7229f5c, 0x2)
> kernel .text 0xc0100000 0xc015c410
> 0xc015c4f0 0xc01571a8 ext3_dirty_inode+0x58 (0xd7894040)
> kernel .text 0xc0100000 0xc0157150
> 0xc0157250 0xc0141b1e __mark_inode_dirty+0x2e (0xd7894040, 0x1)
> kernel .text 0xc0100000 0xc0141af0
> 0xc0141b70 0xc0143001 update_atime+0x51 (0xd7894040, 0x6d6, 0x1, 0x0,
> 0x6d6) kernel .text 0xc0100000 0xc0142fb0 0xc0143010 0xc01254ac
> do_generic_file_read+0x40c (0xd5fc7740, 0xd5fc7760, 0xc7229f5c, 0xc0125690,
> 0x6d6)
> kernel .text 0xc0100000 0xc01250a0
> 0xc01254c0 0xc012576a generic_file_read+0x7a (0xd5fc7740, 0x40018000,
> 0x1000, 0xd5fc7760, 0x0)
> kernel .text 0xc0100000 0xc01256f0
> 0xc0125810 0xc0130cf5 sys_read+0x95 (0x4, 0x40018000, 0x1000, 0x8086ab0,
> 0x40018000)
> kernel .text 0xc0100000 0xc0130c60
> 0xc0130d30 0xc0106d1b system_call+0x33
> kernel .text 0xc0100000 0xc0106ce8
> 0xc0106d20 kdb> ps
> Task Addr Pid Parent [*] cpu State Thread Command
> 0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270 init
> 0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd
> 0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0
> 0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd
> 0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush
> 0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated
> 0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd
> 0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d
> 0xd7b32000 00000009 00000001 1 000 stop 0xd7b32270 kjournald
> 0xd72a6000 00000153 00000001 1 000 stop 0xd72a6270 kjournald
> 0xd729c000 00000154 00000001 1 000 stop 0xd729c270 kjournald
> 0xd7292000 00000155 00000001 1 000 stop 0xd7292270 kjournald
> 0xd7174000 00000157 00000001 1 000 stop 0xd7174270 kreiserfsd
> 0xd70ac000 00000158 00000001 1 000 stop 0xd70ac270 kjournald
> 0xd6f68000 00000160 00000001 1 000 stop 0xd6f68270 pagebuf_daemon
> 0xd6250000 00000525 00000001 1 000 stop 0xd6250270 dhcpcd
> 0xd6c56000 00000661 00000001 1 000 stop 0xd6c56270 syslogd
> 0xd623a000 00000666 00000001 1 000 stop 0xd623a270 klogd
> 0xd619e000 00000686 00000001 1 000 stop 0xd619e270 portmap
> 0xd60ac000 00000714 00000001 1 000 stop 0xd60ac270 rpc.statd
> 0xd62d6000 00000827 00000001 1 000 stop 0xd62d6270 crond
> more>
> 0xd5f3a000 00000863 00000001 1 000 stop 0xd5f3a270 atd
> 0xd6a80000 00000870 00000001 1 000 stop 0xd6a80270 login
> 0xd5f5a000 00000871 00000001 1 000 stop 0xd5f5a270 login
> 0xd5f56000 00000872 00000001 1 000 stop 0xd5f56270 mingetty
> 0xd6c9c000 00000873 00000001 1 000 stop 0xd6c9c270 mingetty
> 0xd5f6a000 00000874 00000001 1 000 stop 0xd5f6a270 mingetty
> 0xd6c9a000 00000875 00000001 1 000 stop 0xd6c9a270 mingetty
> 0xd6338000 00000876 00000001 1 000 stop 0xd6338270 login
> 0xd739c000 00000879 00000876 1 000 stop 0xd739c270 bash
> 0xd5d86000 00000925 00000870 1 000 stop 0xd5d86270 bash
> 0xd580c000 00000977 00000871 1 000 stop 0xd580c270 bash
> 0xc7228000 00001435 00000925 1 000 run 0xc7228270*lvcreate
> kdb> id %eip
> 0xc015c446 journal_start+0x36: cmp %ebp,(%eax)
> 0xc015c448 journal_start+0x38: je 0xc015c46d journal_start+0x5d:
> 0xc015c44a journal_start+0x3a: push $0xc02309e0
> 0xc015c44f journal_start+0x3f: push $0xe1
> 0xc015c454 journal_start+0x44: push $0xc022becf
> 0xc015c459 journal_start+0x49: push $0xc022b6a0
> 0xc015c45e journal_start+0x4e: push $0xc022e6a0
> 0xc015c463 journal_start+0x53: call 0xc0115380 printk:
> 0xc015c468 journal_start+0x58: ud2a
> 0xc015c46a journal_start+0x5a: add $0x14,%esp
> 0xc015c46d journal_start+0x5d: incl 0x8(%ebx)
> 0xc015c470 journal_start+0x60: jmp 0xc015c4e0 journal_start+0xd0:
> 0xc015c472 journal_start+0x62: push $0x1
> 0xc015c474 journal_start+0x64: push $0xf0
> 0xc015c479 journal_start+0x69: push $0x14
> 0xc015c47b journal_start+0x6b: push $0xc022b6a0
> kdb> go
> Oops: 0000
> CPU: 0
> EIP: 0010:[<c015c446>] Not tainted
> EFLAGS: 00010286
> eax: 748b5356 ebx: c01a1550 ecx: d7894040 edx: 00000000
> esi: c7228000 edi: d7894040 ebp: d7ed4800 esp: c7229eac
> ds: 0018 es: 0018 ss: 0018
> Process lvcreate (pid: 1435, stackpage=c7229000)
> Stack: c01a1550 c01a1550 ffffffe2 d7894040 00000000 c01571a8 d7ed4800
> 00000001 40018000 c7229f5c 00000002 00000018 d7894040 d7b41000 00000001
> c0141b1e d7894040 3c36dd6f d5fc7760 d78940f0 c0143001 d7894040 00000001
> 00000000 Call Trace: [<c01a1550>] [<c01a1550>] [<c01571a8>] [<c0141b1e>]
> [<c0143001>] [<c01254ac>] [<c012576a>] [<c0125690>] [<c0130cf5>]
> [<c0106d1b>]
>
> Code: 39 28 74 23 68 e0 09 23 c0 68 e1 00 00 00 68 cf be 22 c0 68
>
> On Sat, 5 Jan 2002 09:14, Eric Sandeen wrote:
> > On Fri, 2002-01-04 at 16:49, Adrian Head wrote:
> > > What does your backtrace look like? Its the ext3_dirt_inode in my
> > > backtrace thats got me. I have compiled a kernel without ext3 so will
> > > also give it a run later.
> >
> > No, ext3 functions do not show up for me when it oopses on snapshot
> > creation:
> >
> > kdb> bt
> > EBP EIP Function(args)
> > 0xc1c2bf78 0xc013649e path_init+0x36 (0xc1c2a000)
> > kernel .text 0xc0100000 0xc0136468
> > 0xc013659c 0xc1c2bf90 0xc01366cf __user_walk+0x2f (0xc1c2a000, 0x804f1bc)
> > kernel .text 0xc0100000 0xc01366a0
> > 0xc01366f8 0xc1c2bfbc 0xc013381e sys_stat64+0x1a (0x8052474, 0xbfffe980,
> > 0x40196154, 0x804f1bc, 0x3) kernel .text 0xc0100000 0xc0133804 0xc0133874
> > 0xc0106c5b system_call+0x33
> > kernel .text 0xc0100000 0xc0106c28
> > 0xc0106c60
> >
> >
> > It's trying to stat64 /dev/sda2, one of my lvm partitions. I dunno why
> > this blows up. :/
> >
> > The code has some fastcalls & inlines around here, though, so this may
> > not be the most accurate.
> >
> > Still looking...
> >
> > -Eric
- --
Adrian Head
(Public Key available on request.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8N+0o8ZJI8OvSkAcRAgk+AJ4/0P4qg1A2UnABK5O+0kM9jYlYfgCgn+fv
GRJHFM6+Mt9CJNg9n13XoEI=
=ZVhu
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-04 21:08 ` Eric Sandeen
@ 2002-01-07 8:05 ` Adrian Head
2002-01-07 12:58 ` Eric Sandeen
1 sibling, 0 replies; 27+ messages in thread
From: Adrian Head @ 2002-01-07 8:05 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Linux XFS Mailing List, linux-lvm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This is the kdb output from trying to create a snapshot of an XFS volume when
I have removed ext3 from my kernel. (For clarifcation - in all my previous
tests ext3 was compiled into my kernel - in this test I did not select ext3
at all in menuconfig)
The only other thing I have noticed is that when the original XFS logical
volume is unmounted snapshot creation is fine. I'm not sure if this works on
the other tests I have tried so I will go back and redo them.
id %eip is weird. What does this really mean? looks like the instructions
point nowhere. Am I correct?
Entering kdb (current=0xd600e000, pid 940) Oops: Oops
due to oops @ 0xb800
eax = 0xffffffff ebx = 0xd600e000 ecx = 0x0000b800 edx = 0xc018fd25
esi = 0x00000008 edi = 0xd600e000 esp = 0xd600ff0c eip = 0x0000b800
ebp = 0xd600ff30 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086
xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd600fed8
kdb> bt
EBP EIP Function(args)
0xd600ff30 0x0000b800 <unknown>+0xb800 (0x1)
kernel <unknown> 0x0 0x0 0x0
0xc011ce83 dequeue_signal+0x43 (0xd600e560, 0xd600ff30,
0xd600e560, 0xd600ffc4, 0xc01392ff)
kernel .text 0xc0100000 0xc011ce40 0xc011cef0
0xc01069b9 do_signal+0x59 (0x11, 0xbfffec40, 0xbfffebb0, 0x8, 0x11)
kernel .text 0xc0100000 0xc0106960 0xc0106c00
0xc0106d54 signal_return+0x14
kernel .text 0xc0100000 0xc0106d40 0xc0106d58
kdb> btp 940
EBP EIP Function(args)
0xc011ce83 0x0000b800 <unknown>+0xb800 (0x1)
kernel <unknown> 0x0 0x0 0x0
0xc011ce83 dequeue_signal+0x43 (0xd600e560, 0xd600ff30,
0xd600e560, 0xd600ffc4, 0xc01392ff)
kernel .text 0xc0100000 0xc011ce40 0xc011cef0
0xc01069b9 do_signal+0x59 (0x11, 0xbfffec40, 0xbfffebb0, 0x8, 0x11)
kernel .text 0xc0100000 0xc0106960 0xc0106c00
0xc0106d54 signal_return+0x14
kernel .text 0xc0100000 0xc0106d40 0xc0106d58
kdb> ps
Task Addr Pid Parent [*] cpu State Thread Command
0xd7fe2000 00000001 00000000 1 000 stop 0xd7fe2270 init
0xc163c000 00000002 00000001 1 000 stop 0xc163c270 keventd
0xc1638000 00000003 00000000 1 000 stop 0xc1638270 ksoftirqd_CPU0
0xc1636000 00000004 00000000 1 000 stop 0xc1636270 kswapd
0xc1634000 00000005 00000000 1 000 stop 0xc1634270 bdflush
0xc1632000 00000006 00000000 1 000 stop 0xc1632270 kupdated
0xd7ec4000 00000007 00000001 1 000 stop 0xd7ec4270 mdrecoveryd
0xd7eae000 00000008 00000001 1 000 stop 0xd7eae270 raid5d
0xd7228000 00000156 00000001 1 000 stop 0xd7228270 kreiserfsd
0xd7022000 00000159 00000001 1 000 stop 0xd7022270 pagebuf_daemon
0xd630c000 00000522 00000001 1 000 stop 0xd630c270 dhcpcd
0xd6fce000 00000658 00000001 1 000 stop 0xd6fce270 syslogd
0xd630a000 00000663 00000001 1 000 stop 0xd630a270 klogd
0xd61a2000 00000683 00000001 1 000 stop 0xd61a2270 portmap
0xd617c000 00000711 00000001 1 000 stop 0xd617c270 rpc.statd
0xd6108000 00000823 00000001 1 000 stop 0xd6108270 crond
0xd651c000 00000860 00000001 1 000 stop 0xd651c270 atd
0xd7986000 00000867 00000001 1 000 stop 0xd7986270 login
0xd627a000 00000868 00000001 1 000 stop 0xd627a270 mingetty
0xd6194000 00000869 00000001 1 000 stop 0xd6194270 mingetty
0xd613e000 00000870 00000001 1 000 stop 0xd613e270 mingetty
more>
0xd6400000 00000871 00000001 1 000 stop 0xd6400270 mingetty
0xd60e4000 00000872 00000001 1 000 stop 0xd60e4270 mingetty
0xd6284000 00000873 00000001 1 000 stop 0xd6284270 mgetty
0xd67f2000 00000876 00000867 1 000 stop 0xd67f2270 bash
0xd600e000 00000940 00000876 1 000 run 0xd600e270*lvcreate
kdb> id %eip
0xb800: kdb: Bad user address 0xb800
add %al,(%eax)
0xb802: add %al,(%eax)
0xb804: add %al,(%eax)
0xb806: add %al,(%eax)
0xb808: add %al,(%eax)
0xb80a: add %al,(%eax)
0xb80c: add %al,(%eax)
0xb80e: add %al,(%eax)
0xb810: add %al,(%eax)
0xb812: add %al,(%eax)
0xb814: add %al,(%eax)
0xb816: add %al,(%eax)
0xb818: add %al,(%eax)
0xb81a: add %al,(%eax)
0xb81c: add %al,(%eax)
0xb81e: add %al,(%eax)
kdb> go
Oops: 0000
CPU: 0
EIP: 0010:[<0000b800>] Not tainted
EFLAGS: 00010086
eax: ffffffff ebx: d600e000 ecx: 0000b800 edx: c018fd25
esi: 00000008 edi: d600e000 ebp: d600ff30 esp: d600ff0c
ds: 0018 es: 0018 ss: 0018
Process lvcreate (pid: 940, stackpage=d600f000)
Stack: c011ce83 00000001 00000000 00000008 c01069b9 d600e560 d600ff30 d600e560
d600ffc4 c01392ff 00000282 d604ab40 d600e000 00000011 c1672144 c011de97
00000011 d600e568 00000000 d600ff70 d600ffa4 c011e252 00000011 d600ff90
Call Trace: [<c011ce83>] [<c01069b9>] [<c01392ff>] [<c011de97>] [<c011e252>]
[<c0106d54>]
Code: Bad EIP value.
- --
Adrian Head
(Public Key available on request.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8OavO8ZJI8OvSkAcRAlktAJ0Uyq3AyRtrrBDkxe5oszt+wrbjAwCfU+wC
w9VQ0Hb8tpt8qmCTsM+gJDk=
=5Vw0
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
[not found] <200201071508.g07F8Pg14938@oss.sgi.com>
@ 2002-01-07 8:39 ` Keith Owens
2002-01-07 10:48 ` Adrian Head
0 siblings, 1 reply; 27+ messages in thread
From: Keith Owens @ 2002-01-07 8:39 UTC (permalink / raw)
To: Adrian Head; +Cc: Linux XFS Mailing List, linux-lvm
On Tue, 8 Jan 2002 00:08:11 +1000,
Adrian Head <ahead@bigpond.net.au> wrote:
>This is the kdb output from trying to create a snapshot of an XFS volume when
>I have removed ext3 from my kernel. (For clarifcation - in all my previous
>tests ext3 was compiled into my kernel - in this test I did not select ext3
>at all in menuconfig)
>
>The only other thing I have noticed is that when the original XFS logical
>volume is unmounted snapshot creation is fine. I'm not sure if this works on
>the other tests I have tried so I will go back and redo them.
>
>id %eip is weird. What does this really mean? looks like the instructions
>point nowhere. Am I correct?
>
>Entering kdb (current=0xd600e000, pid 940) Oops: Oops
>due to oops @ 0xb800
>eax = 0xffffffff ebx = 0xd600e000 ecx = 0x0000b800 edx = 0xc018fd25
>esi = 0x00000008 edi = 0xd600e000 esp = 0xd600ff0c eip = 0x0000b800
>ebp = 0xd600ff30 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086
>xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd600fed8
>kdb> bt
> EBP EIP Function(args)
>0xd600ff30 0x0000b800 <unknown>+0xb800 (0x1)
> kernel <unknown> 0x0 0x0 0x0
> 0xc011ce83 dequeue_signal+0x43 (0xd600e560, 0xd600ff30,
>0xd600e560, 0xd600ffc4, 0xc01392ff)
> kernel .text 0xc0100000 0xc011ce40 0xc011cef0
> 0xc01069b9 do_signal+0x59 (0x11, 0xbfffec40, 0xbfffebb0, 0x8, 0x11)
> kernel .text 0xc0100000 0xc0106960 0xc0106c00
> 0xc0106d54 signal_return+0x14
> kernel .text 0xc0100000 0xc0106d40 0xc0106d58
kdb is correctly reporting the current eip, but the kernel has taken a
swan dive into nowhere. It looks like the chunk of code below. To
confirm, run
objdump --start-addr=0xc011ce40 --stop-address=0xc011ce90 vmlinux
I expect to see a call instruction just before 0xc011ce83, probably an
indirect call via ecx.
dequeue_signal(sigset_t *mask, siginfo_t *info)
{
int sig = 0;
#if DEBUG_SIG
printk("SIG dequeue (%s:%d): %d ", current->comm, current->pid,
signal_pending(current));
#endif
sig = next_signal(current, mask);
if (sig) {
if (current->notifier) {
if (sigismember(current->notifier_mask, sig)) {
if (!(current->notifier)(current->notifier_data)) { <=== probably failing here
current->sigpending = 0;
return 0;
}
Without seeing the objdump output, I am assuming that it is failing on
the call to current->notifier which means that notifier is corrupt.
The only place that notifier is set is in block_all_signals() so we
need to find who is calling that routine with bad data. With any luck,
this (untested) debug patch will catch the offender. Then we start
finding out why it is passing a bad pointer.
--- kernel/signal.c.orig Wed Dec 5 13:15:50 2001
+++ kernel/signal.c Tue Jan 8 01:28:12 2002
@@ -155,6 +155,8 @@ block_all_signals(int (*notifier)(void *
{
unsigned long flags;
+ if (notifier && (unsigned long)notifier < 0xc0000000)
+ BUG();
spin_lock_irqsave(¤t->sigmask_lock, flags);
current->notifier_mask = mask;
current->notifier_data = priv;
A quick scan through the kernel found only DRM code using
block_all_signals. If the bug is a bad notifier then the oops will be
timing dependent, the notifier routine is only called if a signal trips
between block_all_signals() and unblock_all_signals() and that does not
always occur.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-07 8:39 ` Keith Owens
@ 2002-01-07 10:48 ` Adrian Head
0 siblings, 0 replies; 27+ messages in thread
From: Adrian Head @ 2002-01-07 10:48 UTC (permalink / raw)
To: Keith Owens; +Cc: Linux XFS Mailing List, linux-lvm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Keith - just a couple of questions...
On Tue, 8 Jan 2002 00:41, Keith Owens wrote:
> On Tue, 8 Jan 2002 00:08:11 +1000,
>
> Adrian Head <ahead@bigpond.net.au> wrote:
> >
> >Entering kdb (current=0xd600e000, pid 940) Oops: Oops
> >due to oops @ 0xb800
> >eax = 0xffffffff ebx = 0xd600e000 ecx = 0x0000b800 edx = 0xc018fd25
> >esi = 0x00000008 edi = 0xd600e000 esp = 0xd600ff0c eip = 0x0000b800
> >ebp = 0xd600ff30 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086
> >xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd600fed8
> >kdb> bt
> > EBP EIP Function(args)
> >0xd600ff30 0x0000b800 <unknown>+0xb800 (0x1)
> > kernel <unknown> 0x0 0x0 0x0
> > 0xc011ce83 dequeue_signal+0x43 (0xd600e560, 0xd600ff30,
> >0xd600e560, 0xd600ffc4, 0xc01392ff)
> > kernel .text 0xc0100000 0xc011ce40
> > 0xc011cef0 0xc01069b9 do_signal+0x59 (0x11, 0xbfffec40, 0xbfffebb0, 0x8,
> > 0x11) kernel .text 0xc0100000 0xc0106960 0xc0106c00 0xc0106d54
> > signal_return+0x14
> > kernel .text 0xc0100000 0xc0106d40
> > 0xc0106d58
>
> kdb is correctly reporting the current eip, but the kernel has taken a
> swan dive into nowhere. It looks like the chunk of code below. To
> confirm, run
>
> objdump --start-addr=0xc011ce40 --stop-address=0xc011ce90 vmlinux
How did you get 0xc011ce40 and 0xc011ce90? Do they come from above? How are
they derived? Just interested.
vmlinux - where does that come from? I assume it is not the compressed
kernel found in /boot.
>
> I expect to see a call instruction just before 0xc011ce83, probably an
> indirect call via ecx.
As soon as I can get a sucessful objdump I'll send it on.
>
> dequeue_signal(sigset_t *mask, siginfo_t *info)
> {
> int sig = 0;
>
> #if DEBUG_SIG
> printk("SIG dequeue (%s:%d): %d ", current->comm, current->pid,
> signal_pending(current));
> #endif
>
> sig = next_signal(current, mask);
> if (sig) {
> if (current->notifier) {
> if (sigismember(current->notifier_mask, sig)) {
> if
> (!(current->notifier)(current->notifier_data)) { <=== probably failing
> here current->sigpending = 0;
> return 0;
> }
>
> Without seeing the objdump output, I am assuming that it is failing on
> the call to current->notifier which means that notifier is corrupt.
> The only place that notifier is set is in block_all_signals() so we
> need to find who is calling that routine with bad data. With any luck,
> this (untested) debug patch will catch the offender. Then we start
> finding out why it is passing a bad pointer.
While I wait for more info about objdump I'll do this and see what happens.
> --- kernel/signal.c.orig Wed Dec 5 13:15:50 2001
> +++ kernel/signal.c Tue Jan 8 01:28:12 2002
> @@ -155,6 +155,8 @@ block_all_signals(int (*notifier)(void *
> {
> unsigned long flags;
>
> + if (notifier && (unsigned long)notifier < 0xc0000000)
> + BUG();
> spin_lock_irqsave(¤t->sigmask_lock, flags);
> current->notifier_mask = mask;
> current->notifier_data = priv;
>
> A quick scan through the kernel found only DRM code using
> block_all_signals. If the bug is a bad notifier then the oops will be
> timing dependent, the notifier routine is only called if a signal trips
> between block_all_signals() and unblock_all_signals() and that does not
> always occur.
- --
Adrian Head
(Public Key available on request.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8OdHW8ZJI8OvSkAcRAmpQAKCaoO4JuZO+teCW8cUEnDzrNvkjeACeOk9B
eZT4hJWVk3xh1BOZnC0o14A=
=YOrk
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-04 21:08 ` Eric Sandeen
2002-01-07 8:05 ` Adrian Head
@ 2002-01-07 12:58 ` Eric Sandeen
1 sibling, 0 replies; 27+ messages in thread
From: Eric Sandeen @ 2002-01-07 12:58 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Adrian Head, Linux XFS Mailing List, linux-lvm
On Fri, 2002-01-04 at 21:10, Eric Sandeen wrote:
> Ok, I've done a bit of kdb sleuthing over here... it looks like it's
> blowing up shortly after lvm_snapshot_COW, although for some reason kdb
> says the backtrace is from sys_stat64 after the oops. On the other
> hand, setting a breakpoint at
> lvm_snapshot_COW, it oopses just a couple steps later. Here's the
> backtrace out of lvm_snapshot_COW. It gets there from lvm_do_lv_create
> via unlockfs; does this make sense? I didn't expect to get into
> lvm_snapshot_COW until after the snapshot volume was created...
Ok, it looks like that was the problem. XFS wrote the superblock when
unfreezing (unlocking) the filesystem, apparently LVM wasn't happy with
this I/O on the snapshotted volume before the volume had been created.
Something goes quite haywire as a result, but I'm not sure what.
We really don't need the superblock write at this point (it was the last
thing done prior to the freeze, no need to do it again), and removing it
allows the snapshot to be created without error.
I was curious, though, to see if reversing the order of unlockfs() &
lvm_fs_create_lv() at the end of lvm_do_lv_create() might alleviate
this problem (i.e. create the lv, THEN unlock the snapshotted volume)
but that didn't work, either. Perhaps the LVM folks can comment on
this...
Adrian says there's still a problem with overflows; I'll look into that.
-Eric
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@sgi.com SGI, Inc.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
[not found] <200201071648.IAA08511@sgi.com>
@ 2002-01-07 14:34 ` Keith Owens
0 siblings, 0 replies; 27+ messages in thread
From: Keith Owens @ 2002-01-07 14:34 UTC (permalink / raw)
To: Adrian Head; +Cc: Linux XFS Mailing List, linux-lvm
On Tue, 8 Jan 2002 02:50:27 +1000,
Adrian Head <ahead@bigpond.net.au> wrote:
>On Tue, 8 Jan 2002 00:41, Keith Owens wrote:
>> On Tue, 8 Jan 2002 00:08:11 +1000,
>> Adrian Head <ahead@bigpond.net.au> wrote:
>> >
>> >Entering kdb (current=0xd600e000, pid 940) Oops: Oops
>> >due to oops @ 0xb800
>> >eax = 0xffffffff ebx = 0xd600e000 ecx = 0x0000b800 edx = 0xc018fd25
>> >esi = 0x00000008 edi = 0xd600e000 esp = 0xd600ff0c eip = 0x0000b800
>> >ebp = 0xd600ff30 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010086
>> >xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xd600fed8
>> >kdb> bt
>> > EBP EIP Function(args)
>> >0xd600ff30 0x0000b800 <unknown>+0xb800 (0x1)
>> > kernel <unknown> 0x0 0x0 0x0
>> > 0xc011ce83 dequeue_signal+0x43 (0xd600e560, 0xd600ff30,
>> >0xd600e560, 0xd600ffc4, 0xc01392ff)
>> > kernel .text 0xc0100000 0xc011ce40
>> > 0xc011cef0 0xc01069b9 do_signal+0x59 (0x11, 0xbfffec40, 0xbfffebb0, 0x8,
>> > 0x11) kernel .text 0xc0100000 0xc0106960 0xc0106c00 0xc0106d54
>> > signal_return+0x14
>> > kernel .text 0xc0100000 0xc0106d40
>> > 0xc0106d58
>>
>> kdb is correctly reporting the current eip, but the kernel has taken a
>> swan dive into nowhere. It looks like the chunk of code below. To
>> confirm, run
>>
>> objdump --start-addr=0xc011ce40 --stop-address=0xc011ce90 vmlinux
>
>How did you get 0xc011ce40 and 0xc011ce90? Do they come from above? How are
>they derived? Just interested.
The backtrace shows a branch out of the kernel, the last good address
is the starting point to find out why we branched to an invalid
address. Back trace is listed as 0xc011ce83 dequeue_signal+0x43,
subtract 0x43 so dequeue_signal starts at 0xc011ce40. Stop address is
the backtrace entry plus a bit to bracket the probable call
instruction.
>vmlinux - where does that come from? I assume it is not the compressed
>kernel found in /boot.
The kernel build creates vmlinux under /usr/src/linux or wherever you
build your kernel. All architectures build vmlinux then modify it as
required for booting. Binutils tools like objdump do not understand
bzImage, they need the original ELF kernel, i.e. vmlinux.
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
[not found] <200201020451.g024pPg00867@oss.sgi.com>
2002-01-04 13:49 ` [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Eric Sandeen
@ 2002-01-09 16:25 ` Eric Sandeen
2002-01-09 16:40 ` Eric Sandeen
1 sibling, 1 reply; 27+ messages in thread
From: Eric Sandeen @ 2002-01-09 16:25 UTC (permalink / raw)
To: Adrian Head; +Cc: Linux XFS Mailing List, linux-lvm
[-- Attachment #1: Type: text/plain, Size: 878 bytes --]
On Tue, 2002-01-01 at 21:51, Adrian Head wrote:
> I'm starting to play around with LVM with the goal of having XFS, ext3,
> reiserfs and LVM coexist nicely together.
>
> Has anyone been able to get , ext3, reiserfs, XFS and LVM running nicely
> together?
This patch, on top of xfs cvs (2.4.17-xfs), with the LVM 1.0.1 upgrade
patch applied, then the VFS lock patch, works for me. Note that this is
stolen from the 1.0.1rc4(ish) version of LVM in Linus' kernel. It uses
the built-in blocks from lv_snap->lv_iobuf->blocks rather than declaring
a new chunk of blocks.
I tested snapshot creation & overflow with ext2, ext3, reiser, and xfs.
I have not looked closely enough to see why xfs breaks w/o this patch,
and why it works with it, but... give it a shot.
-Eric
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@sgi.com SGI, Inc.
[-- Attachment #2: lvm-1.0.1-xfs-fix.patch --]
[-- Type: text/plain, Size: 1247 bytes --]
--- lvm-snap.c Wed Jan 9 16:10:01 2002
+++ /localhome/eric/lvm-1.0.1-works/lvm-snap.c Wed Jan 9 16:07:52 2002
@@ -349,7 +349,6 @@
unsigned long phys_start;
int idx = lv_snap->lv_remap_ptr, chunk_size = lv_snap->lv_chunk_size;
struct kiobuf * iobuf;
- unsigned long blocks[KIO_MAX_SECTORS];
int blksize_snap, blksize_org, min_blksize, max_blksize;
int max_sectors, nr_sectors;
@@ -400,19 +399,19 @@
iobuf->length = nr_sectors << 9;
- if (!lvm_snapshot_prepare_blocks(blocks, phys_start,
+ if (!lvm_snapshot_prepare_blocks(iobuf->blocks, phys_start,
nr_sectors, blksize_org))
goto fail_prepare;
- if (__brw_kiovec(READ, 1, &iobuf, org_phys_dev, blocks,
+ if (__brw_kiovec(READ, 1, &iobuf, org_phys_dev, iobuf->blocks,
blksize_org, lv_snap) != (nr_sectors<<9))
goto fail_raw_read;
- if (!lvm_snapshot_prepare_blocks(blocks, snap_start,
+ if (!lvm_snapshot_prepare_blocks(iobuf->blocks, snap_start,
nr_sectors, blksize_snap))
goto fail_prepare;
- if (__brw_kiovec(WRITE, 1, &iobuf, snap_phys_dev, blocks,
+ if (__brw_kiovec(WRITE, 1, &iobuf, snap_phys_dev, iobuf->blocks,
blksize_snap, lv_snap) != (nr_sectors<<9))
goto fail_raw_write;
^ permalink raw reply [flat|nested] 27+ messages in thread
* [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-09 16:25 ` Eric Sandeen
@ 2002-01-09 16:40 ` Eric Sandeen
0 siblings, 0 replies; 27+ messages in thread
From: Eric Sandeen @ 2002-01-09 16:40 UTC (permalink / raw)
To: Eric Sandeen; +Cc: Adrian Head, Linux XFS Mailing List, linux-lvm
On Wed, 2002-01-09 at 16:23, Eric Sandeen wrote:
> I tested snapshot creation & overflow with ext2, ext3, reiser, and xfs.
> I have not looked closely enough to see why xfs breaks w/o this patch,
> and why it works with it, but... give it a shot.
Ah, ok. Steve pointed out that in the stock LVM version,
unsigned long blocks[KIO_MAX_SECTORS];
plops 4k down on the stack; xfs's stack must be a bit bigger than other
filesystems, and it overflows... that's why xfs was failing with that
code, and other filesystems survived.
-Eric
--
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@sgi.com SGI, Inc.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-05 15:29 ` [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Andreas Dilger
@ 2002-01-10 9:22 ` Adrian Head
2002-01-10 9:28 ` Patrick Caulfield
2002-01-11 2:40 ` Luca Berra
[not found] ` <200201101521.IAA17651@cthulhu.turbolabs.com>
1 sibling, 2 replies; 27+ messages in thread
From: Adrian Head @ 2002-01-10 9:22 UTC (permalink / raw)
To: Andreas Dilger, Eric Sandeen
Cc: Linux XFS Mailing List, linux-lvm, ext2-devel
In the process of trying to fix this issue I have been playing around with a
patch from the great SGI XFS developers. It certainly fixes the problems I
was having but I'm now trying to help clean the patch up.
The problem now is that when I try to mount a ext3 snapshot using:
mount /dev/HDA/SNAP /mnt/snapshot
The kernel mounts the snapshot as ext2. Is was not happening before the
patch and I was wondering if anyone thinks this is a problem. As ext3 is
backward compatible with ext2 there doesn't seem to be any problems during my
testing with respect to standard file operations. I can mount the snapshot
as ext3 if I use:
mount -t ext3 /dev/HDA/SNAP /mnt/snapshot
The next problem is that when the ext3 snapshot (mounted as ext3) overflows
lvm generates an error in the logs:
lvm -- giving up to snapshot /dev/HDA/XFS on /dev/HDA/SNAP: out of space
lvm - lvm_map: ll_rw_blk for inactive LV /dev/HDA/SNAP
The 1st line I understand but the 2nd I don't. I was hoping that some LVM
guru/developer could explain the 2nd line and what it means.
The last problem is that in only some of my tests when I "ls" the overflowed
snapshot "ls" complains about missing directories and files, "echo *" shows
what use to be there and ext3 generates errors in the logs:
EXT3-fs error (device lvm(58,5)): ext3_readdir" directory #2 contains a hole
at offset 0
I was hoping that a ext2/3 guru/developer could explain this error and what
it means.
Thanks for everybodies time and effort.
--
Adrian Head
(Public Key available on request.)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-10 9:22 ` Adrian Head
@ 2002-01-10 9:28 ` Patrick Caulfield
2002-01-10 15:21 ` Adrian Head
2002-01-11 2:40 ` Luca Berra
1 sibling, 1 reply; 27+ messages in thread
From: Patrick Caulfield @ 2002-01-10 9:28 UTC (permalink / raw)
To: linux-lvm
On Fri, Jan 11, 2002 at 01:21:26AM +1000, Adrian Head wrote:
> In the process of trying to fix this issue I have been playing around with a
> patch from the great SGI XFS developers. It certainly fixes the problems I
> was having but I'm now trying to help clean the patch up.
>
> The problem now is that when I try to mount a ext3 snapshot using:
> mount /dev/HDA/SNAP /mnt/snapshot
> The kernel mounts the snapshot as ext2. Is was not happening before the
> patch and I was wondering if anyone thinks this is a problem. As ext3 is
> backward compatible with ext2 there doesn't seem to be any problems during my
> testing with respect to standard file operations. I can mount the snapshot
> as ext3 if I use:
> mount -t ext3 /dev/HDA/SNAP /mnt/snapshot
>
> The next problem is that when the ext3 snapshot (mounted as ext3) overflows
> lvm generates an error in the logs:
> lvm -- giving up to snapshot /dev/HDA/XFS on /dev/HDA/SNAP: out of space
> lvm - lvm_map: ll_rw_blk for inactive LV /dev/HDA/SNAP
>
> The 1st line I understand but the 2nd I don't. I was hoping that some LVM
> guru/developer could explain the 2nd line and what it means.
When a snapshot gets full it can no longer be valid so LVM makes it inactive and
fails any further I/O to it.
Because there's no more space for copy-on-write operations into the snapshot
there's no way the filesystem can be consistent. OK this isn't that nice but
it's arguably better than returning corrupted data.
patrick
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
[not found] ` <200201101521.IAA17651@cthulhu.turbolabs.com>
@ 2002-01-10 14:14 ` Andreas Dilger
2002-01-10 15:02 ` Adrian Head
0 siblings, 1 reply; 27+ messages in thread
From: Andreas Dilger @ 2002-01-10 14:14 UTC (permalink / raw)
To: Adrian Head; +Cc: Eric Sandeen, Linux XFS Mailing List, linux-lvm, ext2-devel
On Jan 11, 2002 01:21 +1000, Adrian Head wrote:
> The last problem is that in only some of my tests when I "ls" the overflowed
> snapshot "ls" complains about missing directories and files, "echo *" shows
> what use to be there and ext3 generates errors in the logs:
> EXT3-fs error (device lvm(58,5)): ext3_readdir" directory #2 contains a hole
> at offset 0
Well, given that the snapshot is now broken and LVM is refusing I/O on it,
what do you expect the filesystem to do? This is what LVM _intends_ to
happen, because the snapshot can no longer hold all of the data to keep
it consistent.
The ext3 error is reporting that it tried to read the directory (root = #2)
and it got nothing back. The reason you see some files and not others is
because those blocks happen to still be in the cache, and it does not go
to LVM to try and re-read them. Eventually, as the memory is needed for
other things, you will no longer be able to read anything.
I suppose it would be possible to have LVM do an "unmount" of any fs
using a bad snapshot device from within the kernel, but whether people
actually want that to happen is another question entirely.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-10 14:14 ` Andreas Dilger
@ 2002-01-10 15:02 ` Adrian Head
0 siblings, 0 replies; 27+ messages in thread
From: Adrian Head @ 2002-01-10 15:02 UTC (permalink / raw)
To: Andreas Dilger
Cc: Eric Sandeen, Linux XFS Mailing List, linux-lvm, ext2-devel
On Fri, 11 Jan 2002 06:12, Andreas Dilger wrote:
>
> Well, given that the snapshot is now broken and LVM is refusing I/O on it,
> what do you expect the filesystem to do? This is what LVM _intends_ to
> happen, because the snapshot can no longer hold all of the data to keep
> it consistent.
>
> The ext3 error is reporting that it tried to read the directory (root = #2)
> and it got nothing back. The reason you see some files and not others is
> because those blocks happen to still be in the cache, and it does not go
> to LVM to try and re-read them. Eventually, as the memory is needed for
> other things, you will no longer be able to read anything.
>
> I suppose it would be possible to have LVM do an "unmount" of any fs
> using a bad snapshot device from within the kernel, but whether people
> actually want that to happen is another question entirely.
If this is what is considered normal operation then everything is fine.
Thats why I decided to ask - to find out :-).
From my previous tests the behaviour I was observing was that once the
snapshot had overflowed a "ls" on the snapshot showed nothing. This still
appears to be the behaviour of resierfs.
Cool - if this is standard behaviour then everything seems fixed :-)
--
Adrian Head
(Public Key available on request.)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-10 9:28 ` Patrick Caulfield
@ 2002-01-10 15:21 ` Adrian Head
0 siblings, 0 replies; 27+ messages in thread
From: Adrian Head @ 2002-01-10 15:21 UTC (permalink / raw)
To: linux-lvm, Patrick Caulfield
On Fri, 11 Jan 2002 01:27, Patrick Caulfield wrote:
>
> When a snapshot gets full it can no longer be valid so LVM makes it
> inactive and fails any further I/O to it.
>
> Because there's no more space for copy-on-write operations into the
> snapshot there's no way the filesystem can be consistent. OK this isn't
> that nice but it's arguably better than returning corrupted data.
Thanks Patrick for you response. If this is the correct behaviour then
everything is fine. I just asked so I could find out. :-)
Everything looks mighty fine. Thanks everyone for your time and effort.
--
Adrian Head
(Public Key available on request.)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily
2002-01-10 9:22 ` Adrian Head
2002-01-10 9:28 ` Patrick Caulfield
@ 2002-01-11 2:40 ` Luca Berra
1 sibling, 0 replies; 27+ messages in thread
From: Luca Berra @ 2002-01-11 2:40 UTC (permalink / raw)
To: linux-lvm
On Fri, Jan 11, 2002 at 01:21:26AM +1000, Adrian Head wrote:
> The problem now is that when I try to mount a ext3 snapshot using:
> mount /dev/HDA/SNAP /mnt/snapshot
> The kernel mounts the snapshot as ext2. Is was not happening before the
> patch and I was wondering if anyone thinks this is a problem. As ext3 is
> backward compatible with ext2 there doesn't seem to be any problems during my
> testing with respect to standard file operations. I can mount the snapshot
> as ext3 if I use:
> mount -t ext3 /dev/HDA/SNAP /mnt/snapshot
this depends on the order the mount porgram tries to autodetect a filesystem
if the luser does not specify it. I don't have mount sources at hand
but AFAIR it reads /etc/filesystems, /proc/filesystems and then tries
an hardcoded list. you can modify /etc/filesystems to change the probe
order.
[you already got answers to the other issues]
L.
--
Luca Berra -- bluca@comedia.it
Communication Media & Services S.r.l.
/"\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2002-01-11 2:40 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <200201020451.g024pPg00867@oss.sgi.com>
2002-01-04 13:49 ` [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Eric Sandeen
2002-01-04 16:47 ` Adrian Head
2002-01-04 17:37 ` Andreas Dilger
2002-01-04 20:10 ` Adrian Head
2002-01-04 21:35 ` Adrian Head
2002-01-06 0:05 ` [linux-lvm] lvm-1.0.1rc4(ish) more robust on startup than lvm-1.0.1 Adrian Head
[not found] ` <200201050212.TAA16774@cthulhu.turbolabs.com>
2002-01-05 15:29 ` [linux-lvm] Re: Unable to get XFS, ext3, reiserfs & LVM to coexist happily Andreas Dilger
2002-01-10 9:22 ` Adrian Head
2002-01-10 9:28 ` Patrick Caulfield
2002-01-10 15:21 ` Adrian Head
2002-01-11 2:40 ` Luca Berra
[not found] ` <200201101521.IAA17651@cthulhu.turbolabs.com>
2002-01-10 14:14 ` Andreas Dilger
2002-01-10 15:02 ` Adrian Head
[not found] ` <200201042349.g04Nnag26320@oss.sgi.com>
2002-01-04 17:12 ` Eric Sandeen
2002-01-04 20:44 ` Adrian Head
2002-01-05 17:06 ` Andreas Dilger
[not found] ` <200201050346.g053kmg29738@oss.sgi.com>
2002-01-04 21:08 ` Eric Sandeen
2002-01-07 8:05 ` Adrian Head
2002-01-07 12:58 ` Eric Sandeen
2002-01-06 0:20 ` Adrian Head
2002-01-09 16:25 ` Eric Sandeen
2002-01-09 16:40 ` Eric Sandeen
[not found] <200201071648.IAA08511@sgi.com>
2002-01-07 14:34 ` Keith Owens
[not found] <200201071508.g07F8Pg14938@oss.sgi.com>
2002-01-07 8:39 ` Keith Owens
2002-01-07 10:48 ` Adrian Head
[not found] <200201040015.RAA00441@cthulhu.turbolabs.com>
2002-01-03 18:36 ` Andreas Dilger
[not found] <6u4rm4r53e.fsf@zork.zork.net>
[not found] ` <200201031638.g03GcJg20734@oss.sgi.com>
[not found] ` <1010072497.12080.42.camel@jen.americas.sgi.com>
2002-01-03 18:13 ` Adrian Head
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox