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
17 matches
Mail list logo
