Wolfgang Rohdewald wrote:
: On Tuesday 17 April 2001 22:36, Jan Kasprzak wrote:
: > + if (len == -1 || len > 0 && len < count) {
:
: are you sure there are no missing () ?
:
: if ((len == -1) || (len > 0) && (len < count)) {
:
: assumig that && has precedence over || (I believe so)
On Tue, 17 Apr 2001, Wolfgang Rohdewald wrote:
> On Tuesday 17 April 2001 22:36, Jan Kasprzak wrote:
> > + if (len == -1 || len > 0 && len < count) {
>
> are you sure there are no missing () ?
>
> if ((len == -1) || (len > 0) && (len < count)) {
>
> assumig that && has precedence over || (I
On Tuesday 17 April 2001 22:36, Jan Kasprzak wrote:
> + if (len == -1 || len > 0 && len < count) {
are you sure there are no missing () ?
if ((len == -1) || (len > 0) && (len < count)) {
assumig that && has precedence over || (I believe so)
-
To unsubscribe from this list: send the line "uns
Jesse S Sipprell writes:
> On error, -1 is returned in the usual fashion and offset is purported to be
> updated to point to the next byte following the last one sent.
>
> Will the zerocopy patches break this?
No, they should not.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe f
On Tue, Apr 17, 2001 at 01:23:07PM -0700, David S. Miller wrote:
> One more subtle note, for the case of error handling. There is a
> change to sendfile() in the zerocopy patches which causes sendfile()
> to act more like sendmsg() when errors occur.
How is this likely to affect applications?
Jesse S Sipprell wrote:
: After cursory examination of proftpd, it appears that there is a misuse of the
: sendfile() call under Linux, which may be responsible for the corruption. The
: code was originally based on BSD semantics. Under Linux, the offset argument
: is not being used correctly to
Jesse S Sipprell writes:
> A patch will be coming out soon, as it is a fairly trivial fix.
Thank you for tracking this down.
One more subtle note, for the case of error handling. There is a
change to sendfile() in the zerocopy patches which causes sendfile()
to act more like sendmsg() when er
On Tue, Apr 17, 2001 at 06:15:24PM +0200, Jan Kasprzak wrote:
> Alan Cox wrote:
> : > : but once a fixed BIOS is out for your board that would be a good first step.
> : > : If it still does it then, its worth digging for kernel naughties
> : > :
> : > I don't think I have 686b southbridge. I ha
On Tue, Apr 17, 2001 at 06:15:24PM +0200, Jan Kasprzak wrote:
> Some more progress: I now downgraded to proftpd without sendfile().
> The CPU usage is now nearly 100% (with ~170 FTP users; with sendfile()
> it was under 50% with >320 FTP users). But nevertheless, the downloaded
> images now
Jan Kasprzak wrote:
: $ cmp -cl seawolf-sendfile.iso seawolf-i386-SRPMS.iso
[...]
:
: Which simply means, that at 160628609 it started to send
: the CD image from the beginning.
Well, I did strace of proftpd, and it _may_ be a mis-interpretation
of the sendfile(2) semantics on the
Andi Kleen wrote:
: I guess to debug this problem it would be useful to get some idea about the
: nature of the corruption. Could you enable sendfile() again, and when a
: user complains ask to download it again and provide a
: cmp -cl fileA fileB | head -500 listing of their differences?
Alan Cox wrote:
: > : but once a fixed BIOS is out for your board that would be a good first step.
: > : If it still does it then, its worth digging for kernel naughties
: > :
: > I don't think I have 686b southbridge. I have 686 (without "b"):
:
: Ok. What revision of 3c90x card do you have
> : but once a fixed BIOS is out for your board that would be a good first step.
> : If it still does it then, its worth digging for kernel naughties
> :
> I don't think I have 686b southbridge. I have 686 (without "b"):
Ok. What revision of 3c90x card do you have ?
-
To unsubscribe from
Andi Kleen wrote:
: On Tue, Apr 17, 2001 at 03:10:07PM +0200, Jan Kasprzak wrote:
: > 00:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74)
:
: IIRC the problem came up earlier. Some versions of 3com NICs seem to make
: problems with the hardware checksum. There were s
Alan Cox wrote:
: > The long story: My server is Athlon 850 on ASUS A7V, 256M RAM.
: > Seven IDE discs, one SCSI disc. The controllers and NIC are as follows
: > (output of lspci):
:
: See the VIA chipset report on www.theregister.co.uk about corruption problems
: with VIA chipsets. The cases
> The long story: My server is Athlon 850 on ASUS A7V, 256M RAM.
> Seven IDE discs, one SCSI disc. The controllers and NIC are as follows
> (output of lspci):
See the VIA chipset report on www.theregister.co.uk about corruption problems
with VIA chipsets. The cases seen on Linux included sh
On Tue, Apr 17, 2001 at 03:10:07PM +0200, Jan Kasprzak wrote:
> 00:0c.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74)
IIRC the problem came up earlier. Some versions of 3com NICs seem to make
problems with the hardware checksum. There were some fixes in the driver
la
Hello,
I have discovered a possible problem on my host. The short
story is: When downloading ISO images from this host (which
runs 2.4.3 + zerocopy and ProFTPd with sendfile()), the image is
sometimes corrupted (MD5 checksum of the downloaded file does not match).
The lon
18 matches
Mail list logo