Re: NFS + coredump OOPS

On Wed, Sep 19, 2007 at 02:07:13PM -0400, Trond Myklebust wrote: > On Wed, 2007-09-19 at 12:53 +0200, NetArt - Grzegorz Nosek wrote: > > [16249868.626066] [ cut here ] > > [16249868.684345] kernel BUG at mm/readahead.c:314! > > That bug should have bee

Re: NFS + coredump OOPS

On Wed, Sep 19, 2007 at 02:07:13PM -0400, Trond Myklebust wrote: On Wed, 2007-09-19 at 12:53 +0200, NetArt - Grzegorz Nosek wrote: [16249868.626066] [ cut here ] [16249868.684345] kernel BUG at mm/readahead.c:314! That bug should have been fixed in 2.6.19-rc5. See

NFS + coredump OOPS

Hello all, [please keep CC'd] This oops report comes from 2.6.18.5, so it may have been fixed in a newer release, but I'm reporting nevertheless. OTOH, the (possibly) relevant code looks unchanged. The background is _probably_ attempting a core dump of a process, whose backing binary file is

NFS + coredump OOPS

Hello all, [please keep CC'd] This oops report comes from 2.6.18.5, so it may have been fixed in a newer release, but I'm reporting nevertheless. OTOH, the (possibly) relevant code looks unchanged. The background is _probably_ attempting a core dump of a process, whose backing binary file is

Very slow routing table modification if RTA_FLOW is set

Hello all, I have noticed that using realm patch for quagga causes the kernel to spend a lot more time processing rtnetlink messages. If routes added to the kernel are not tagged with a realm number, the time from sending a netlink cmd to receiving

Very slow routing table modification if RTA_FLOW is set

Hello all, I have noticed that using realm patch for quagga http://vcalinus.gemenii.ro/quaggarealms.html causes the kernel to spend a lot more time processing rtnetlink messages. If routes added to the kernel are not tagged with a realm number, the time from sending a netlink cmd to receiving an