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

Neil Brown wrote:
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.

Away from that machine now, so that I can't test anything till thursday.

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).

FC6 with latest updates.

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

I do have. md1 md2 md3 -- raid0, 1, 0. But there is no md0 (removed in the past)
and 'raidautorun /dev/md0 | nash' causes the troubles.

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

Yup. Monolithic as much as possible (md is in the kernel and so dm is). / on the
lvm2 on the /dev/md1 with no initrd. All are sata disks, so sd_mod, sata_promise
and ata_piix are in the kernel.

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

Hm, I have never seen FC6 installation process, so I can't say what special
option I have turned on -- it's 'yum upgrade'd from FC5, FC4...

regards,
--
http://www.fi.muni.cz/~xslaby/ Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
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: oops in 2.6.13-rc6-git5
    ... > Can you reproduce the crash with a non-tainted kernel? ... I've tried several times now to reproduce the oops, ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • Re: oops on 2.6.19-rc6-mm2: deref of 0x28 at permission+0x7
    ... the oops is fully reproducible. ... It is a bit of a long-shot, but this patch might change ... would either of both of you see if you can reproduce the bug with ... And you compile your own kernel. ...
    (Linux-Kernel)
  • [PATCH-2.4] range checking for sleep states sent to /proc/acpi/sleep
    ... A range checking is missing in acpi_system_write_sleepin kernel ... and writing a large integer value to /proc/acpi/sleep will cause ... an oops. ... I could reproduce one this way: ...
    (Linux-Kernel)
  • Re: oops in 2.6.13-rc6-git5
    ... > for capturing Oops data. ... >> kernel event redirected to a different file. ... > I've tried to reproduce the Oops here with your config, ... As for doing it using a network or serial console - I don't have the equipment ...
    (Linux-Kernel)
  • Re: Oops while modprobing phy fixed module
    ... bug didn't get triggered on that particular test. ... 3007e997de91ec59af39a3f9c91595b31ae6e08b is first bad commit ... Hmm, I don't see why this one could introduce an oops in SLUB, ... I will enable DEBUG option and reproduce in a bit. ...
    (Linux-Kernel)