Re: oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7

On Monday December 11, jikos@xxxxxxxx wrote:
On Mon, 11 Dec 2006, Neil Brown wrote:

this nash thing is exactly the command which triggers a bit different
oops in my case. On my side, the oops is fully reproducible. If you
manage to make your case also reproducible, could you please try to
revert md-change-lifetime-rules-for-md-devices.patch? This made the
oops vanish in my case. I think Neil is working on it.
Trying to work on it - not making a lot of progress. I find it hard to
see how anything in md can cause the inode for a block-device file to
disappear... It is a bit of a long-shot, but this patch might change
things. It changes the order in which things are de-allocated. Jiri and
Jiri: would either of both of you see if you can reproduce the bug with
this patch on 2.6.19-rc6-mm2 ???

Hi Neil,

sorry to say that, but it's still there after applying your patch.

Not a big surprise, but thanks a lot for testing. I think I'm going
to have to try harder to duplicate it myself.

If I remember rightly you are using FC - which version exactly? (I've
never installed FC before so this is going to be learning experience).

And you have no MD arrays at all - is that correct?

And you compile your own kernel. Is it monolithic, or are you using
modules? Do you boot with an initrd or just the kernel?

I'd like to duplicate your installation as closely as possible, so any
relevant details or recipes would be greatly appreciated.

Thanks,

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [RFC PATCH] block: Fix bio merge induced high I/O latency
    ... On a 2.6.29-rc3 kernel. ... I get the following OOPS just after I start ... that the type of request (sync vs!sync) changes would not be taken care ... Just ignore the patch for now, I'm not going to be spending more time on ...
    (Linux-Kernel)
  • Re: unmount oops in log_do_checkpoint
    ... I was not able to reproduce the problem even with those debug ... > Attached is the patch that fixes two minor possible problems I've ... Neither of them should be causing your oops but one never knows ... I have also attached a full jbd debug output and oops for the vanilla ...
    (Linux-Kernel)
  • Re: 2.6.0-test8-mm1
    ... > Btw. a similar Oops at the same place occours when the uhci-hcd module is ... > The attached patch prevents the kernel from Oopsing, ... WARN_ONso we'd get a stack trace in addition to the printk). ... Unable to handle kernel NULL pointer dereference at virtual address ...
    (Linux-Kernel)
  • Re: oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7
    ... the oops is fully reproducible. ... I think Neil is working on it. ... would either of both of you see if you can reproduce the bug with ... Monolithic as much as possible (md is in the kernel and so dm is). ...
    (Linux-Kernel)
  • Re: 2.6.24 regression: pan hanging unkilleable and un-straceable
    ... The attached patch is something really simple that can sometimes ... Or if it is very easy to reproduce with ... a particular kernel version, then it is probably a memory scribble from ...
    (Linux-Kernel)