[OOPS] LVM and (I think) devfs

[OOPS] LVM and (I think) devfs

[Matt]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

Just started playing with LVM, (with devfs), and I've found I can reproduce
the attached oops consistently doing the following:

# vgchange -a y
# vgchange -a n
# vgchange -a y

Once this happens, the lvm becomes unreponsive and requires a reboot to
activate it again.

It looks like the oops happens in devfs_open().

I'm using 2.4.17-pre8 with LVM 1.0.1, and the kernel driver from that package.

Matt
-- 
"Phase plasma rifle in a forty-watt range?"
"Only what you see on the shelves, buddy"

[-- Attachment #2: lvm-devfs-oops --]
[-- Type: text/plain, Size: 2606 bytes --]

ksymoops 2.4.3 on i686 2.4.17-pre8.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.17-pre8/ (default)
     -m /usr/src/linux/System.map (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Unable to handle kernel NULL pointer dereference at virtual address 00000018
*pde = 00000000
Oops: 0002
CPU:    0
EIP:    0010:[<c0181226>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010286
eax: 00000000   ebx: f7e63320   ecx: f79f29a0   edx: c02b1788
esi: f7b22060   edi: f7e63328   ebp: f79f29a0   esp: f7981f40
ds: 0018   es: 0018   ss: 0018
Process vgchange (pid: 137, stackpage=f7981000)
Stack: f79f29a0 f7b22060 ffffffe9 c200eea0 c02a1f20 c0133159 f7b22060 f79f29a0
       40052500 f79bb000 00000000 bffff91c c013306e f7b24920 c200eea0 00000000
       00000004 f79bb000 bffffa6c f7b24920 c200eea0 bffffa6c bffff91c 00000000
Call Trace: [<c0133159>] [<c013306e>] [<c01333be>] [<c0106d7b>]
Code: 89 50 18 eb 2b 90 8d 74 26 00 8b 43 08 85 c0 74 1a 8b 00 85

>>EIP; c0181226 <devfs_open+76/168>   <=====
Trace; c0133158 <dentry_open+e0/188>
Trace; c013306e <filp_open+52/5c>
Trace; c01333be <sys_open+36/cc>
Trace; c0106d7a <system_call+32/38>
Code;  c0181226 <devfs_open+76/168>
0000000000000000 <_EIP>:
Code;  c0181226 <devfs_open+76/168>   <=====
   0:   89 50 18                  mov    %edx,0x18(%eax)   <=====
Code;  c0181228 <devfs_open+78/168>
   3:   eb 2b                     jmp    30 <_EIP+0x30> c0181256 <devfs_open+a6/168>
Code;  c018122a <devfs_open+7a/168>
   5:   90                        nop    
Code;  c018122c <devfs_open+7c/168>
   6:   8d 74 26 00               lea    0x0(%esi,1),%esi
Code;  c0181230 <devfs_open+80/168>
   a:   8b 43 08                  mov    0x8(%ebx),%eax
Code;  c0181232 <devfs_open+82/168>
   d:   85 c0                     test   %eax,%eax
Code;  c0181234 <devfs_open+84/168>
   f:   74 1a                     je     2b <_EIP+0x2b> c0181250 <devfs_open+a0/168>
Code;  c0181236 <devfs_open+86/168>
  11:   8b 00                     mov    (%eax),%eax
Code;  c0181238 <devfs_open+88/168>
  13:   85 00                     test   %eax,(%eax)


1 warning issued.  Results may not be reliable.

Re: [OOPS] LVM and (I think) devfs

[Richard Gooch]

matt@bodgit-n-scarper.com writes:
> Just started playing with LVM, (with devfs), and I've found I can reproduce
> the attached oops consistently doing the following:
> 
> # vgchange -a y
> # vgchange -a n
> # vgchange -a y
> 
> Once this happens, the lvm becomes unreponsive and requires a reboot to
> activate it again.
> 
> It looks like the oops happens in devfs_open().
> 
> I'm using 2.4.17-pre8 with LVM 1.0.1, and the kernel driver from
> that package.

Please try kernel 2.4.16 and see if the problem persists. There were
devfs and minor LVM changes since then. Make sure you at least Cc: me.

				Regards,

					Richard....
Permanent: rgooch@atnf.csiro.au
Current:   rgooch@ras.ucalgary.ca

Re: [OOPS] LVM and (I think) devfs

[Matt]

On Wed, Dec 12, 2001 at 10:26:32AM -0700, Richard Gooch wrote:
> 
> Please try kernel 2.4.16 and see if the problem persists. There were
> devfs and minor LVM changes since then. Make sure you at least Cc: me.

Ah, a slight problem there. The LVM volume happens to reside on an AACRAID
controller, which won't get passed fsck'ing with 2.4.16. 2.4.17-pre8 seems
to have fixed that problem for reasons unknown.

The .17-preX LVM code should be based on, if not the same as the .16 code
shouldn't it? The log suggests only changes on the devfs side. If I just
stuck to the LVM code in the kernel, instead of using the code provided in
the LVM 1.0.1 package, would that be a fair test?

Cheers

Matt
-- 
"Phase plasma rifle in a forty-watt range?"
"Only what you see on the shelves, buddy"

Re: [OOPS] LVM and (I think) devfs

[Matt]

On Wed, Dec 12, 2001 at 10:26:32AM -0700, Richard Gooch wrote:
> matt@bodgit-n-scarper.com writes:
> > Just started playing with LVM, (with devfs), and I've found I can reproduce
> > the attached oops consistently doing the following:
> > 
> > # vgchange -a y
> > # vgchange -a n
> > # vgchange -a y
> > 
> > Once this happens, the lvm becomes unreponsive and requires a reboot to
> > activate it again.
> > 
> > It looks like the oops happens in devfs_open().
> > 
> > I'm using 2.4.17-pre8 with LVM 1.0.1, and the kernel driver from
> > that package.
> 
> Please try kernel 2.4.16 and see if the problem persists. There were
> devfs and minor LVM changes since then. Make sure you at least Cc: me.

I've tried just 2.4.17-pre8, without upgrading the LVM code, and the oops has
gone, I've tried a few repetitions of the above commands and it doesn't fall
over. There might be something iffy in the newer LVM code then...

Cheers

Matt
-- 
"Phase plasma rifle in a forty-watt range?"
"Only what you see on the shelves, buddy"