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"
[email protected] 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: [email protected]
Current: [email protected]
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"
On Wed, Dec 12, 2001 at 10:26:32AM -0700, Richard Gooch wrote:
> [email protected] 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"