Is your mailer screwed up? We're getting duplicates (a few
days later).
On Mon, 29 Sep 2003, Dan Langille wrote:
> On 18 Sep 2003 at 7:50, Daniel Eischen wrote:
>
> > On Wed, 17 Sep 2003, Dan Langille wrote:
> >
> > > On 16 Sep 2003 at 20:49, Daniel Eischen wrote:
> > >
> > > > On Tue, 16 Sep 2003, Dan Langille wrote:
> > > >
> > > > > I've had preliminary success with this patch. More testing needs
> > > > > to be done, but in the meantime, I would appreciate reviews and
> > > > > comments. The patched code is available from
> > > > > http://beta.freebsddiary.org/tmp/uthread_write.c and the patch
> > > > > appears below.
> > > > >
> > > > > In short, the logic has been changed to ensure that if __sys_write
> > > > > returns zero, this value is returned by _write.
> > > >
> > > > I think this is not quite correct. Since libc_r is looping
> > > > and some data may have been read, then the partial byte count
> > > > should be returned, not zero. It is possible the partial byte
> > > > count could also be zero in some cases, so it would result
> > > > in zero being returned in those instances.
> > >
> > > I see what you mean. Please have a look at
> > > http://beta.freebsddiary.org/tmp/uthread_write.c2
> > > The patch appears at the end of this message.
> >
> > Right, this seems correct to me.
>
> All our testing on this patch has been successful. I'm going to do a
> few more tests on different hardware under 4.8-stable.
>
> What's the next step? Commit it? Get others to test with it first?
>
> > > > I think the problem lies with the SCSI tape device. It should
> > > > either return 0 or -1 with errno=ENOSPC on a write that detects
> > > > an EOT, not partial byte count.
> > >
> > > You are referring to sa(4)?
> >
> > Yes.
> >
> > > > If you are using libkse or
> > > > libthr, you will get a partial byte count and not zero because
> > > > the tape driver returns the (partial) bytes written. So exiting
> > > > the loop in libc_r and returning 0 would only seem to correct
> > > > the "problem" for libc_r.
> >
> > If there is a difference, it could be because libc_r is using non-blocking
> > IO behind the scenes, and sa(4) may be returning partial byte count
> > in the non-blocking case and 0 (or -1 and ENOSPC) in the blocking case
> > (which is what you'd get using libkse/libthr).
> >
> > > The problem found when running under pthreads on 4.8-stable [i.e.
> > > EOT is not returned to the application code] is not found with libkse
> > > on 5.1-current.
>
> FWIW: our regression tests are failing under 5.1 and we suspect that
> MTIOCERRSTAT ioctl() has changed since 4.8. We're getting:
>
> btape: dev.c:1119 Doing MTIOCERRSTAT errno=22 ERR=Invalid argument
>
> We'll continue with our 5.1 work, but we'd like to finish up with 4.8
> ASAP.
> --
> Dan Langille : http://www.langille.org/
>
> _______________________________________________
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
--
"Some folks are into open source, but me, I'm into open bar."
-- Spencer F. Katt
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
