On Wednesday, September 23, 2009, ron minnich wrote:
> not having done this before, the reference is URL:
> http://codereview.appspot.com/122046
Thanks, Ron. Fix applied.
Russ
On Wed Sep 23 14:54:47 EDT 2009, r...@swtch.com wrote:
> > how sure are we that 1 holds? couldn't there be other,
> > legitimate and transient errors? could a user-delivered
> > note sneak in and confuse the issue?
>
> no. at least not if the kernel is working properly.
> that's why i said devm
not having done this before, the reference is URL:
http://codereview.appspot.com/122046
ron
sent in via codereview but I missed a debug print I left in. Sorry. I
assume you can reject it so I'm sending the correct patch.
ron
> So just need to fix oserrstr() or fix this in devip itself? I vote
> oserrstr, lucho votes fix this little bit of
> code.
how many other errors are lurking in osstrerror()?
there are lots of assumptions about the exact
errstrs.
- erik
I think that oserrstr should be fixed.
You want "interrupted" to be the error string
for many places not just right here.
Other programs look for strstr(error, "interrupt") for example
Russ
On Wednesday, September 23, 2009, ron minnich wrote:
> OK, so what happens in 9vx.
>
> mount sources
> cd
OK, so what happens in 9vx.
mount sources
cd /n/blah/blah
grep full *.c
hit DEL
devip.c read on Qdata fails, and we do this:
if(r < 0){
oserrstr();
nexterror();
}
So just need to fix oserrstr() or fix this in devip it
> how sure are we that 1 holds? couldn't there be other,
> legitimate and transient errors? could a user-delivered
> note sneak in and confuse the issue?
no. at least not if the kernel is working properly.
that's why i said devmnt should enforce the assumption.
it's at most a couple lines of ex
> I mean that the code as written is assuming that if a read or write
> errors out, it can only happen for one of two reasons:
> 1) there was an interrupt note, in which case strcmp(error, Eintr) == 0
> 2) there has been an error on the 9P connection, in which case
>strcmp(error, Eintr) != 0 an
On Tuesday, September 22, 2009, erik quanstrom wrote:
> On Tue Sep 22 23:12:27 EDT 2009, r...@swtch.com wrote:
>> The extra tracking that has been proposed is unnecessary,
>> and waiting for the Rflush doesn't make sense. The assumption
>> is that the Rflush isn't ever going to arrive, because th
On Tue Sep 22 23:12:27 EDT 2009, r...@swtch.com wrote:
> The extra tracking that has been proposed is unnecessary,
> and waiting for the Rflush doesn't make sense. The assumption
> is that the Rflush isn't ever going to arrive, because the connection
> is dead.
what do you mean by "dead"? i/o to
The extra tracking that has been proposed is unnecessary,
and waiting for the Rflush doesn't make sense. The assumption
is that the Rflush isn't ever going to arrive, because the connection
is dead.
The problem is here:
void
mountio(Mnt *m, Mntrpc *r)
{
int n;
while(waserror())
full versions in
/n/sources/contrib/quanstro/devmnt.c
/n/sources/contrib/quanstro/vx32devmnt.c
- erik
ron,
this works for me but my symptoms were a little different than yours.
before:
mnt: proc cat 290: mismatch from #D/ssl/1/data /n/coraid/lib/unicode
rep 0x7fcd8c04e190 tag 4 fid 1603 T120 R117 rp 4
after:
WOOT! caught stale reply 6; type 117
note: the poor organization of this
On Tue, Sep 22, 2009 at 2:23 PM, erik quanstrom wrote:
> On Tue Sep 22 17:22:08 EDT 2009, rminn...@gmail.com wrote:
>> here's one last "caught in the act" scenario. I have a print in
>> mntralloc when I reuse something.
>>
>> The fid is being read and clunked. But the Tclunk goes out before the
>>
On Tue Sep 22 17:22:08 EDT 2009, rminn...@gmail.com wrote:
> here's one last "caught in the act" scenario. I have a print in
> mntralloc when I reuse something.
>
> The fid is being read and clunked. But the Tclunk goes out before the
> Rread comes in. Oops.
>
>
> Reuse 1
> Tread tag 1 fid 454 o
here's one last "caught in the act" scenario. I have a print in
mntralloc when I reuse something.
The fid is being read and clunked. But the Tclunk goes out before the
Rread comes in. Oops.
Reuse 1
Tread tag 1 fid 454 offset 0 count 8192
Reuse 1
Tclunk tag 1 fid 454
reply Rread tag 1 count 8192
here is a 9p trace of the problem. See line 43. Topen and Tclunk go
out with same tag. This is with a print in the rpc code as suggested
by Russ.
ron
y
Description: Binary data
2009/9/22 erik quanstrom :
>> if it's ambiguous, then the tag should indeed be put on hold,
>> because there's no way to get it right.
>
> how do we prevent all tags from being on hold?
> there's no way to get that right, either.
well, it's legal to send several flushes for the same tag,
and it's
On Sep 22, 2009, at 1:47 PM, ron minnich wrote:
On Tue, Sep 22, 2009 at 11:35 AM, roger peppe
wrote:
surely the correct way to go about this (caveat: i haven't looked
at the code)
is to drop the rpc struct onto the rpcfree list only when the
Rflush is
received?
you just got an Eintr.
> if it's ambiguous, then the tag should indeed be put on hold,
> because there's no way to get it right.
how do we prevent all tags from being on hold?
there's no way to get that right, either.
- erik
2009/9/22 ron minnich :
> On Tue, Sep 22, 2009 at 11:35 AM, roger peppe wrote:
>
>> surely the correct way to go about this (caveat: i haven't looked at the
>> code)
>> is to drop the rpc struct onto the rpcfree list only when the Rflush is
>> received?
>
> you just got an Eintr. Did the request
> I don't know. I am not sure the code does either. Since this is only
> seen so far in 9vx I am guess it is a 9vx thing.
i see this now than then on regular plan 9
Tue Sep 1 18:51:15: unexpected reply tag 51; type 109
Tue Sep 1 18:51:15: unexpected reply tag 16; type 109
Tue Sep 1 18:51:15: u
On Tue, Sep 22, 2009 at 11:35 AM, roger peppe wrote:
> surely the correct way to go about this (caveat: i haven't looked at the code)
> is to drop the rpc struct onto the rpcfree list only when the Rflush is
> received?
you just got an Eintr. Did the request get sent?
I don't know. I am not sur
2009/9/22 ron minnich :
> So, basically, the way I see it is, grep proc gets an interrupt,
> kernel will try to flush RPCs which we initiated, we drop the (we
> think) flushed rpc struct onto the rpcfree list, but the reply from
> the server is still in flight. We reuse the rpc from rpcfree list, w
OK, I did this in mntralloc, in the code path in which we reuse the
rpc from the mtnalloc.rpcfree: I just simply always allocated a new
tag, even if we found an old rpc which was nominally free: I always
allocated a new tag, not reusing the old tag.
That fixed the problem.
So, basically, the way
OK, a little more fooling around.
term% grep full *.c
(wait about a second, hit DEL)
grep: can't open apic.c: 'apic.c' './sys/src/9/pc/grep' does not exist
grep: can't open apm.c: 'apm.c' mount rpc error
grep: can't open archmp.c: 'archmp.c' mount rpc error
grep: can't open bios32.c: 'bios32.c' m
On Monday, September 21, 2009, ron minnich wrote:
> If I am in 9vx and have imported a file system from somewhere, and do
> an ls, and get impatient and hit del, the import dies.
>
> term% grep full *.c
> grep: can't open *.c: '*.c' mount rpc error
> term% ls
> ls: .: clone failed
> term%
>
> mnt
If I am in 9vx and have imported a file system from somewhere, and do
an ls, and get impatient and hit del, the import dies.
term% grep full *.c
grep: can't open *.c: '*.c' mount rpc error
term% ls
ls: .: clone failed
term%
mnt: proc grep 91: mismatch from /net/tcp/0/data
/n/o/usr/rminnich/9k/bg
29 matches
Mail list logo
