lkml.org 
[lkml]   [1999]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] ncpfs bug
"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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.026 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site