Re: [SSI-devel] Re: 1.9 rmtfb assert bug solved?

[Roger T. <rog...@gm...>]

Alright I'll add a SSI_XXX comment.

I don't see any immediate fixes besides rewriting rmtfb that would
alleviate the problem of client/server having different ino's.=20
Changing rmtfb_gethandle() might help, but will involve
reop_export_path().

-Roger


On 8/24/05, Brian J. Watson <Bri...@hp...> wrote:
> Hi Roger,
>=20
> The rmtfb_tryagain_handle() function is fine as a short-term hack to get
> things working. You should also add an SSI_XXX comment that the
> underlying bug should be fixed sometime, which is that the inos should
> not be allowed to be different on the rmtfb client and server nodes.
>=20
> Thanks,
>=20
> Brian
>=20
>=20
> John Byrne wrote:
> > Roger Tsang wrote:
> >
> >> The problem is the rmtfb server stores the local inode when opening
> >> /dev/tty.  It is the controlling tty as understood.  The client works
> >> with it's own /dev/tty inode without realizing that the server has
> >> opened the controlling tty instead.  So rmtfb_get_cmn() tests fail
> >> because the server is trying to find the rfb_id for the client's
> >> inode.  For some reason, perhaps when the force is strong, some
> >> applications ignore the -ERFB_TRYAGAIN errors and are able to
> >> continue.  This bug started to surface when we upgraded to a more
> >> modern kernel (2.4 -> 2.6).  There seems to be a pattern.  The
> >> problem, if not fixed, is even more pronounced after porting OpenSSI
> >> to kernel-2.6.11.
> >>
> >> This patch fixes three main things.  Time to check into the trunk?  I
> >> also wonder if this patch should be backported.
> >>
> >> 1. remote /dev/tty
> >> 2. local open /dev/pts
> >> 3. false as_do_vma() assert failures
> >>
> >> -Roger
> >>
> >
> > Brian will have to comment on the rmtfb changes; the other changes
> > appear to be okay.
> >
> > John
> >
> >
> >
>=20
>