On 3 Jan 01 at 13:08, Udo A. Steinberg wrote:
> Alexander Viro wrote:
> >
> > In principle, it might be that d_find_alias() is broken. I don't see where
> > it could happen, but then I'm half-asleep right now... While we are at it,
> > do you have
>
> > * autofs
>
> Yes.
>
> >
Hi,
Alexander Viro wrote:
>
> In principle, it might be that d_find_alias() is broken. I don't see where
> it could happen, but then I'm half-asleep right now... While we are at it,
> do you have
> * autofs
Yes.
> * knfsd
> * ncpfs
No, neither of these two.
-Udo.
-
T
On Wed, 3 Jan 2001, Udo A. Steinberg wrote:
> Dan Aloni wrote:
> >
> > After a bit of few code reviewing, it looks like the only code that
> > assigns stuff to ->d_op in a nonstandard way is in fs/vfat/namei.c.
> >
> > Udo, are you using vfat?
>
> Yes.
In principle, it might be that d_find_
Dan Aloni wrote:
>
> After a bit of few code reviewing, it looks like the only code that
> assigns stuff to ->d_op in a nonstandard way is in fs/vfat/namei.c.
>
> Udo, are you using vfat?
Yes.
-Udo.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
On Wed, 3 Jan 2001, Dan Aloni wrote:
> After a bit of few code reviewing, it looks like the only code that
> assigns stuff to ->d_op in a nonstandard way is in fs/vfat/namei.c.
>
> Udo, are you using vfat?
If it was assigned by something that was supposed to set ->d_op
it would not g
On Tue, 2 Jan 2001, Linus Torvalds wrote:
> On Wed, 3 Jan 2001, Udo A. Steinberg wrote:
> >
> > While under massive disk and cpu load, 2.4.0-prerelease produced
> > the following oops (decode see below)
[..]
> Now, I assume this machine has been historically stable, with no history
> of memory
Hi,
Linus Torvalds wrote:
>
> The strange thing is that 0x0100 value, which almost certainly should
> just be NULL. A one-bit error.
>
> Now, I assume this machine has been historically stable, with no history
> of memory corruption problems.. It's entirely possible (and likely) that
> the
On Wed, 3 Jan 2001, Udo A. Steinberg wrote:
>
> Hi Linus et. all
>
> While under massive disk and cpu load, 2.4.0-prerelease produced
> the following oops (decode see below)
> Unable to handle kernel paging request at virtual address 0114
> Code; c01419cc<=
>0: 8b 40 14
On Wed, 3 Jan 2001, Udo A. Steinberg wrote:
>
> While under massive disk and cpu load, 2.4.0-prerelease produced
> the following oops (decode see below)
Hmm.. If I'm not mistaken, this is in dentry_iput() (inline function
called by prune_one_dentry(), which is _also_ an inline function, which
9 matches
Mail list logo