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 ||
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
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
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
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
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
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
> : 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
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
> 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
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
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
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
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
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
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
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
: 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
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 ?
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 seem
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 have 686
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
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?
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 "unsubscribe
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 believe so)
I
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
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
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?
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 from
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)
Yes, but the
36 matches
Mail list logo
