Re: [PATCH] ncpfs bug
Michael Tross (mtross@compu-shack.com)
Wed, 02 Jun 1999 13:36:20 +0200
"Petr Vandrovec Ing. VTEI" wrote:
>
> On 1 Jun 99 at 10:42, Michael Tross wrote:
> > Absolute, you're definitely right. But as I read file.c (v2.2.9), if
> > ncp_read() returns without error and read_this_time is ==0, then
> > ncp_file_read() breaks out of the loop cause of (read_this_time <
> > to_read); but the point is that ncp_file_read() then exits with the
> > return code 0. My patch changed this to return an error in this case.
> > The ncpfs misbehaviour I described occured in all kernels I have tested
> > in the last year, 2.0.32, 2.0.36, 2.2.0 and now 2.2.9. I have LANalyzer
> Hi,
> maybe that it is more problem with ncpfs_nopage. It is legal for
> *_read filesystem procedure to return with 0 at the end of file (I think,
> it is normal behavior for read syscall).
Again I can reproduce the bug I described last week. I downloaded
netperf from HP, extracted it on a mounted ncpfs volume, typed make and
- the linker hangs. I analyzed the network traffic with a packet sniffer
and found:
- my workstation sends about 2500 requests/sec to the NetWare server,
all these requests are identical packets with incrementing sequence
number
- the request is: ncp read file, offset 0xfc00, length 1236
- the server replies with: ncp return code success, data length 0
I running 2.2.10-pre1. Again I will apply my patch.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/