Re: [CHECKER] amusing copy_from_user bug
On Tue, Apr 10, 2001 at 06:41:28AM -0400, Jakub Jelinek wrote: > some architectures don't care at all, because verify_area is a noop > (sparc64). Why (and how) is this? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CHECKER] amusing copy_from_user bug
On Tue, Apr 10, 2001 at 06:41:28AM -0400, Jakub Jelinek wrote: some architectures don't care at all, because verify_area is a noop (sparc64). Why (and how) is this? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How is high memory used ?
Hello, For 2.4 kernels, how is memory between 1G and 4G used ? Is it only for cache/buffers or it is also offered to processes ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How is high memory used ?
Hello, For 2.4 kernels, how is memory between 1G and 4G used ? Is it only for cache/buffers or it is also offered to processes ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1: TCP assertion failed
Moderately-high (couple hundred thousand hits a day) loaded web server running 2.4.1 (no other patches). I got this twice in the syslog after 15 days uptime: KERNEL: assertion (tp->lost_out == 0) failed at tcp_input.c(1202):tcp_remove_reno_sacks (between lots of "TCP: peer shrinks window :xxx:xx. Bad, what else can I say?" which I understand are harmless) Let me know if anyone needs more info/tests/etc. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.1: TCP assertion failed
Moderately-high (couple hundred thousand hits a day) loaded web server running 2.4.1 (no other patches). I got this twice in the syslog after 15 days uptime: KERNEL: assertion (tp-lost_out == 0) failed at tcp_input.c(1202):tcp_remove_reno_sacks (between lots of "TCP: peer shrinks window :xxx:xx. Bad, what else can I say?" which I understand are harmless) Let me know if anyone needs more info/tests/etc. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ECN for servers ?
Hello, What is the impact of enabling ECN on the server side ? I mean, will any clients (with broken firewalls) be affected if a SMTP/HTTP server has ECN enabled ? On the other hand, is there any advantage with ECN enabled on the server side ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ECN for servers ?
Hello, What is the impact of enabling ECN on the server side ? I mean, will any clients (with broken firewalls) be affected if a SMTP/HTTP server has ECN enabled ? On the other hand, is there any advantage with ECN enabled on the server side ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Raw devices bound to RAID arrays ?
Hello, Is it possible to bind a raw device to a software RAID 1 array ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RAID1 read balancing
Hello, For a RAID1 array built of two disks on two separate SCSI controllers, are the reads balanced between the two controllers (for higher speed) ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RAID1 read balancing
Hello, For a RAID1 array built of two disks on two separate SCSI controllers, are the reads balanced between the two controllers (for higher speed) ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Raw devices bound to RAID arrays ?
Hello, Is it possible to bind a raw device to a software RAID 1 array ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 05:21:33AM -0800, David S. Miller wrote: > Petru Paler writes: > > Got more "udp v4 hw csum failure" messages but still no "UDP packet > > with bad csum was fragmented". > > OK, last experiment :-) Add this patch, and watch to see if > the UDP "InErrors" field in /proc/net/snmp has a non-zero value after > letting it run for a while. Thanks. Ok, here it is: grey:/proc/net# uptime 12:14am up 11:01, 1 user, load average: 0.45, 0.47, 0.41 grey:/proc/net# cat snmp Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates Ip: 2 64 8340770 0 0 0 0 8 8290517 1359445 6 0 0 0 0 0 0 0 0 Icmp: InMsgs InErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps Icmp: 7370 446 3846 772 0 39 0 2708 0 0 0 0 0 9661 0 6953 0 0 0 0 0 2708 0 0 0 0 Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 0 0 0 0 16025 0 128 0 20 825925 921717 44521 189 28300 Udp: InDatagrams NoPorts InErrors OutDatagrams Udp: 7500511 6953 30 428614 -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 05:21:33AM -0800, David S. Miller wrote: > Petru Paler writes: > > Got more "udp v4 hw csum failure" messages but still no "UDP packet > > with bad csum was fragmented". > > OK, last experiment :-) Add this patch, and watch to see if > the UDP "InErrors" field in /proc/net/snmp has a non-zero value after > letting it run for a while. Thanks. Ok, will do. In the mean time, the box locked up hard. The last message in syslog was: Jan 14 10:14:45 grey kernel: Undo loss 194.67.160.18/3103 c2 l0 ss2/65535 p0 I'm not sure when it died, and I also could not check the console (the server is on the other side of the planet for me :). -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 02:10:03PM +0200, Petru Paler wrote: > On Sun, Jan 14, 2001 at 03:32:40AM -0800, David S. Miller wrote: > > Petru Paler writes: > > > > Oh, I think I know why this happens. Can you add this patch, and next > > > > time the UDP bad csum message appears, tell me if it says "UDP packet > > > > with bad csum was fragmented." in the next line of your syslog > > > > messages? Thanks. > > Jan 14 06:54:08 grey kernel: Undo loss 193.230.129.57/34342 c2 l0 ss2/2 p0 > Jan 14 06:56:40 grey kernel: udp v4 hw csum failure. > Jan 14 06:57:05 grey kernel: Undo partial loss 193.230.129.57/34342 c1 l5 ss2/3 p5 > > > So no "UDP packet with bad csum was fragmented" line. This is the first > one though, will let you know if the fragmented thing occurs. Got more "udp v4 hw csum failure" messages but still no "UDP packet with bad csum was fragmented". -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 03:32:40AM -0800, David S. Miller wrote: > Petru Paler writes: > > > Oh, I think I know why this happens. Can you add this patch, and next > > > time the UDP bad csum message appears, tell me if it says "UDP packet > > > with bad csum was fragmented." in the next line of your syslog > > > messages? Thanks. Jan 14 06:54:08 grey kernel: Undo loss 193.230.129.57/34342 c2 l0 ss2/2 p0 Jan 14 06:56:40 grey kernel: udp v4 hw csum failure. Jan 14 06:57:05 grey kernel: Undo partial loss 193.230.129.57/34342 c1 l5 ss2/3 p5 So no "UDP packet with bad csum was fragmented" line. This is the first one though, will let you know if the fragmented thing occurs. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 02:58:54AM -0800, David S. Miller wrote: > Petru Paler writes: > > Ok. Should I keep reporting new syslog messages as they appear ? > > Not the "Undo ***" and "Disorder ***" ones". Ok. > But this one is curious: > > > udp v4 hw csum failure. > > Oh, I think I know why this happens. Can you add this patch, and next > time the UDP bad csum message appears, tell me if it says "UDP packet > with bad csum was fragmented." in the next line of your syslog > messages? Thanks. Sure, but I also need the actual patch :) -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 02:33:26AM -0800, David S. Miller wrote: > Petru Paler writes: > > I get messages in syslog looking like: > > > > Undo loss 192.147.174.183/59953 c2 l0 ss2/65535 p0 > > Undo loss 63.148.232.53/4423 c2 l0 ss2/2 p0 > > Undo loss 204.253.105.63/25 c2 l0 ss2/2 p0 > > These are normal, if they annoy you please change FASTRETRANS_DEBUG > back to "1" in include/net/tcp.h > > This is just an increased debugging setting compared to Linus's > tree, the message you see is harmless. Ok. Should I keep reporting new syslog messages as they appear ? This machine has lots of traffic, both TCP (SMTP) and UDP (DNS). Since the last email I also got (minus the "Undo loss" ones, and I only included one of each message types, as they repeat): Undo partial loss 193.230.129.57/33659 c1 l5 ss2/3 p5 udp v4 hw csum failure. Disorder0 3 5 f0 s1 rr1 Undo Hoe 203.162.5.28/25 c8 l1 ss5/65535 p8 -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-pre3+zerocopy: weird messages
I get messages in syslog looking like: Undo loss 192.147.174.183/59953 c2 l0 ss2/65535 p0 Undo loss 63.148.232.53/4423 c2 l0 ss2/2 p0 Undo loss 204.253.105.63/25 c2 l0 ss2/2 p0 This is on a dual UltraSPARC box with a Happy Meal network card. I don't think either Postfix or tinydns (the main load) are using sendfile(). The machine is stable so far, but it's been up for only 15 minutes. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sparc64 compile fix
On Sun, Jan 14, 2001 at 01:19:33AM -0800, David S. Miller wrote: > Petru Paler writes: > > Trying to compile 2.4.0-ac8 resulted in an error about > > storage size of variable d not being known (I don't have the > > exact error at hand, the network connectivity to that server > > is down right now). Changing it to dqblk32 got it to compile. > > > > Am I doing something else wrong ? > > If the quota interfaces have changed, then all of the translation code > support for them in sys_sparc32.c/systbls.S/etc. need to change to > accomodate. > > Stick with non-AC kernels for no on sparc64, thanks. (But feel free to > use the zerocopy patches :-) Ok :) Actually I'm just looking for a kernel to run fast & smoothly on those servers... Will give 2.4.0-pre3 + zerocopy a try. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sparc64 compile fix
On Sun, Jan 14, 2001 at 01:19:33AM -0800, David S. Miller wrote: Petru Paler writes: Trying to compile 2.4.0-ac8 resulted in an error about storage size of variable d not being known (I don't have the exact error at hand, the network connectivity to that server is down right now). Changing it to dqblk32 got it to compile. Am I doing something else wrong ? If the quota interfaces have changed, then all of the translation code support for them in sys_sparc32.c/systbls.S/etc. need to change to accomodate. Stick with non-AC kernels for no on sparc64, thanks. (But feel free to use the zerocopy patches :-) Ok :) Actually I'm just looking for a kernel to run fast smoothly on those servers... Will give 2.4.0-pre3 + zerocopy a try. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-pre3+zerocopy: weird messages
I get messages in syslog looking like: Undo loss 192.147.174.183/59953 c2 l0 ss2/65535 p0 Undo loss 63.148.232.53/4423 c2 l0 ss2/2 p0 Undo loss 204.253.105.63/25 c2 l0 ss2/2 p0 This is on a dual UltraSPARC box with a Happy Meal network card. I don't think either Postfix or tinydns (the main load) are using sendfile(). The machine is stable so far, but it's been up for only 15 minutes. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 02:33:26AM -0800, David S. Miller wrote: Petru Paler writes: I get messages in syslog looking like: Undo loss 192.147.174.183/59953 c2 l0 ss2/65535 p0 Undo loss 63.148.232.53/4423 c2 l0 ss2/2 p0 Undo loss 204.253.105.63/25 c2 l0 ss2/2 p0 These are normal, if they annoy you please change FASTRETRANS_DEBUG back to "1" in include/net/tcp.h This is just an increased debugging setting compared to Linus's tree, the message you see is harmless. Ok. Should I keep reporting new syslog messages as they appear ? This machine has lots of traffic, both TCP (SMTP) and UDP (DNS). Since the last email I also got (minus the "Undo loss" ones, and I only included one of each message types, as they repeat): Undo partial loss 193.230.129.57/33659 c1 l5 ss2/3 p5 udp v4 hw csum failure. Disorder0 3 5 f0 s1 rr1 Undo Hoe 203.162.5.28/25 c8 l1 ss5/65535 p8 -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 02:58:54AM -0800, David S. Miller wrote: Petru Paler writes: Ok. Should I keep reporting new syslog messages as they appear ? Not the "Undo ***" and "Disorder ***" ones". Ok. But this one is curious: udp v4 hw csum failure. Oh, I think I know why this happens. Can you add this patch, and next time the UDP bad csum message appears, tell me if it says "UDP packet with bad csum was fragmented." in the next line of your syslog messages? Thanks. Sure, but I also need the actual patch :) -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 03:32:40AM -0800, David S. Miller wrote: Petru Paler writes: Oh, I think I know why this happens. Can you add this patch, and next time the UDP bad csum message appears, tell me if it says "UDP packet with bad csum was fragmented." in the next line of your syslog messages? Thanks. Jan 14 06:54:08 grey kernel: Undo loss 193.230.129.57/34342 c2 l0 ss2/2 p0 Jan 14 06:56:40 grey kernel: udp v4 hw csum failure. Jan 14 06:57:05 grey kernel: Undo partial loss 193.230.129.57/34342 c1 l5 ss2/3 p5 So no "UDP packet with bad csum was fragmented" line. This is the first one though, will let you know if the fragmented thing occurs. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 02:10:03PM +0200, Petru Paler wrote: On Sun, Jan 14, 2001 at 03:32:40AM -0800, David S. Miller wrote: Petru Paler writes: Oh, I think I know why this happens. Can you add this patch, and next time the UDP bad csum message appears, tell me if it says "UDP packet with bad csum was fragmented." in the next line of your syslog messages? Thanks. Jan 14 06:54:08 grey kernel: Undo loss 193.230.129.57/34342 c2 l0 ss2/2 p0 Jan 14 06:56:40 grey kernel: udp v4 hw csum failure. Jan 14 06:57:05 grey kernel: Undo partial loss 193.230.129.57/34342 c1 l5 ss2/3 p5 So no "UDP packet with bad csum was fragmented" line. This is the first one though, will let you know if the fragmented thing occurs. Got more "udp v4 hw csum failure" messages but still no "UDP packet with bad csum was fragmented". -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-pre3+zerocopy: weird messages
On Sun, Jan 14, 2001 at 05:21:33AM -0800, David S. Miller wrote: Petru Paler writes: Got more "udp v4 hw csum failure" messages but still no "UDP packet with bad csum was fragmented". OK, last experiment :-) Add this patch, and watch to see if the UDP "InErrors" field in /proc/net/snmp has a non-zero value after letting it run for a while. Thanks. Ok, here it is: grey:/proc/net# uptime 12:14am up 11:01, 1 user, load average: 0.45, 0.47, 0.41 grey:/proc/net# cat snmp Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates Ip: 2 64 8340770 0 0 0 0 8 8290517 1359445 6 0 0 0 0 0 0 0 0 Icmp: InMsgs InErrors InDestUnreachs InTimeExcds InParmProbs InSrcQuenchs InRedirects InEchos InEchoReps InTimestamps InTimestampReps InAddrMasks InAddrMaskReps OutMsgs OutErrors OutDestUnreachs OutTimeExcds OutParmProbs OutSrcQuenchs OutRedirects OutEchos OutEchoReps OutTimestamps OutTimestampReps OutAddrMasks OutAddrMaskReps Icmp: 7370 446 3846 772 0 39 0 2708 0 0 0 0 0 9661 0 6953 0 0 0 0 0 2708 0 0 0 0 Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 0 0 0 0 16025 0 128 0 20 825925 921717 44521 189 28300 Udp: InDatagrams NoPorts InErrors OutDatagrams Udp: 7500511 6953 30 428614 -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sparc64 compile fix
On Sat, Jan 13, 2001 at 02:55:42PM -0800, David S. Miller wrote: > Petru Paler writes: > > - struct dqblk d; > > + struct dqblk32 d; > > What does this fix? Things compile just fine without > it and looking at the code it was intended to be of > the original type. > > Please explain exactly what submitted patches fix in > the future, thanks. Sorry, my fingers slipped and I sent the mail too fast :( Trying to compile 2.4.0-ac8 resulted in an error about storage size of variable d not being known (I don't have the exact error at hand, the network connectivity to that server is down right now). Changing it to dqblk32 got it to compile. Am I doing something else wrong ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sparc64 compile fix
--- arch/sparc64/kernel/sys_sparc32.c.orig Sat Jan 13 07:59:43 2001
+++ arch/sparc64/kernel/sys_sparc32.c Sat Jan 13 08:00:23 2001
@@ -904,7 +904,7 @@
{
int cmds = cmd >> SUBCMDSHIFT;
int err;
- struct dqblk d;
+ struct dqblk32 d;
mm_segment_t old_fs;
char *spec;
--
Petru Paler, mailto:[EMAIL PROTECTED]
http://www.ppetru.net - ICQ: 41817235
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sparc64 compile fix
--- arch/sparc64/kernel/sys_sparc32.c.orig Sat Jan 13 07:59:43 2001
+++ arch/sparc64/kernel/sys_sparc32.c Sat Jan 13 08:00:23 2001
@@ -904,7 +904,7 @@
{
int cmds = cmd SUBCMDSHIFT;
int err;
- struct dqblk d;
+ struct dqblk32 d;
mm_segment_t old_fs;
char *spec;
--
Petru Paler, mailto:[EMAIL PROTECTED]
http://www.ppetru.net - ICQ: 41817235
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sparc64 compile fix
On Sat, Jan 13, 2001 at 02:55:42PM -0800, David S. Miller wrote: Petru Paler writes: - struct dqblk d; + struct dqblk32 d; What does this fix? Things compile just fine without it and looking at the code it was intended to be of the original type. Please explain exactly what submitted patches fix in the future, thanks. Sorry, my fingers slipped and I sent the mail too fast :( Trying to compile 2.4.0-ac8 resulted in an error about storage size of variable d not being known (I don't have the exact error at hand, the network connectivity to that server is down right now). Changing it to dqblk32 got it to compile. Am I doing something else wrong ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 07:13:28PM +0100, Jakob Østergaard wrote: > > > It can't scale in SMP. > > > > No one said it does, but it works nicely on UP. > > What ? Maybe you got me wrong (my english isnt that good): I said that it does not scale on SMP, but it works just fine on UP. > The TCP stack is threaded, so things like checksum calculation will > take advantage of multiple processors - right ? Wrong. "Threaded" TCP/IP stack -> fine grained locking, not "multiple threads". > Thes rest of the work is roughly copying data that isn't already > cached from the disk into memory. Well, you have one disk so threads > will buy you zero there. > > Unless you do blocking I/O on the files or on the sockets, I fail to > see how threads could possibly boost the performance on a web server > that serves *static*only* pages. They do boost performance on SMP (because you can have N (N=nr. of CPUs) threads serving data). > (The reason I'm curious is because I'm about a month away from implementing > something that would run high-bandwidth TCP transfers and I'm planning > on keeping it single-threaded - unless someone can tell me that's a bad > idea) Keep it single threaded if you run on UP only... -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 04:53:40PM +0100, Andrea Arcangeli wrote: > On Fri, Dec 29, 2000 at 09:38:40AM +0200, Petru Paler wrote: > > This is one of the main thttpd design points: run in a select() loop. Since > > it is intended for mainly static workloads, it performs quite well... > > It can't scale in SMP. No one said it does, but it works nicely on UP. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 04:53:40PM +0100, Andrea Arcangeli wrote: On Fri, Dec 29, 2000 at 09:38:40AM +0200, Petru Paler wrote: This is one of the main thttpd design points: run in a select() loop. Since it is intended for mainly static workloads, it performs quite well... It can't scale in SMP. No one said it does, but it works nicely on UP. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 07:13:28PM +0100, Jakob Østergaard wrote: It can't scale in SMP. No one said it does, but it works nicely on UP. What ? Maybe you got me wrong (my english isnt that good): I said that it does not scale on SMP, but it works just fine on UP. The TCP stack is threaded, so things like checksum calculation will take advantage of multiple processors - right ? Wrong. "Threaded" TCP/IP stack - fine grained locking, not "multiple threads". Thes rest of the work is roughly copying data that isn't already cached from the disk into memory. Well, you have one disk so threads will buy you zero there. Unless you do blocking I/O on the files or on the sockets, I fail to see how threads could possibly boost the performance on a web server that serves *static*only* pages. They do boost performance on SMP (because you can have N (N=nr. of CPUs) threads serving data). (The reason I'm curious is because I'm about a month away from implementing something that would run high-bandwidth TCP transfers and I'm planning on keeping it single-threaded - unless someone can tell me that's a bad idea) Keep it single threaded if you run on UP only... -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 03:47:12AM +0100, Andrea Arcangeli wrote: > PS. I'm very suprised thttpd isn't threaded, it should really be threaded at > least on the x86 family to run fast. This is one of the main thttpd design points: run in a select() loop. Since it is intended for mainly static workloads, it performs quite well... -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: linux 2.2.19pre and thttpd (VM-global problem?)
On Fri, Dec 29, 2000 at 03:47:12AM +0100, Andrea Arcangeli wrote: PS. I'm very suprised thttpd isn't threaded, it should really be threaded at least on the x86 family to run fast. This is one of the main thttpd design points: run in a select() loop. Since it is intended for mainly static workloads, it performs quite well... -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sparc64 network-related problems
Follow-up: in the mean time I upgraded to test13-pre3. Things look fine so far, but I got this in the kernel log: TCP: peer 203.65.190.178:25/57885 shrinks window 2375104836:0:2375106284. Bad, what else can I say? Should I be worried about it or it's ok ? On Sun, Dec 10, 2000 at 02:57:21AM -0800, David S. Miller wrote: >Date: Sun, 10 Dec 2000 13:10:33 +0200 >From: Petru Paler <[EMAIL PROTECTED]> > >So should I apply your patch ? > > Yes, this new OOPS you've sent me is in the same place. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sparc64 network-related problems
Follow-up: in the mean time I upgraded to test13-pre3. Things look fine so far, but I got this in the kernel log: TCP: peer 203.65.190.178:25/57885 shrinks window 2375104836:0:2375106284. Bad, what else can I say? Should I be worried about it or it's ok ? On Sun, Dec 10, 2000 at 02:57:21AM -0800, David S. Miller wrote: Date: Sun, 10 Dec 2000 13:10:33 +0200 From: Petru Paler [EMAIL PROTECTED] So should I apply your patch ? Yes, this new OOPS you've sent me is in the same place. -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sparc64 network-related problems
On Sun, Dec 10, 2000 at 02:57:21AM -0800, David S. Miller wrote: >Date: Sun, 10 Dec 2000 13:10:33 +0200 >From: Petru Paler <[EMAIL PROTECTED]> > >So should I apply your patch ? > > Yes, this new OOPS you've sent me is in the same place. Ok, applied. Will email again when/if something shows up in the logs. Thanks, -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sparc64 network-related problems
f8003e68f551 i7: 0044cfa8 Warning (Oops_read): Code line not seen, dumping what data is available >>PC; 00449e94<= >>O7; 00449f14 >>I7; 0044cfa8 3 warnings issued. Results may not be reliable. So should I apply your patch ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
sparc64 network-related problems
Let me know if you need additional info or testing done. Bug report (in standard format): [1.] One line summary of the problem: Repeated kernel oopses, after a while of functioning under heavy load. [2.] Full description of the problem/report: We use 4 E450 clones for DNS and mail servers. They are always under heavy load, and after a while (usually a day) of functioning, they start oopsing and eventually (after a couple more days) they lock up. [3.] Keywords (i.e., modules, networking, kernel): kernel, sparc64, networking [4.] Kernel version (from /proc/version): Linux version 2.4.0-test12 (root@grey) (gcc version egcs-2.92.11 19980921 (gcc2 ss-980609 experimental)) #2 SMP Tue Dec 5 11:27:36 EST 2000 It's actually 2.4.0-test12-pre5, with one minor patch to drivers/pci/pci.c (I added a missing declaration for "tmp" in pci_read_bases() otherwise it didn't compile). [5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt) This is only one of the repeated oopses, if you need all of them I will make the logs available. skput:over: 0053ed64:524 put:-428 dev:eth0 \|/ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ smtp(29923): Kernel bad trap CPU[2]: local_irq_count[0] irqs_running[0] TSTATE: 004411009601 TPC: 00528b50 TNPC: 00528b54 Y: 15e0 g0: 0020 g1: 20fa29bf28c5 g2: 0041 g3: 00628000 g4: f800 g5: 0001 g6: f800030e8000 g7: o0: 0032 o1: 00629eae o2: 0032 o3: o4: 00629e7b o5: 00629ead sp: f800030eb1c1 ret_pc: 00528b48 l0: 0064ec00 l1: 7ff8 l2: 8000 l3: 0800 l4: 0077 l5: 0002 l6: l7: 0062a278 i0: f80020f59b00 i1: fe54 i2: 0053ed64 i3: fe54 i4: 03b8 i5: i6: f800030eb281 i7: 0053ed68 Caller[0053ed68] Caller[0055e4e0] Caller[005255b4] Caller[00525818] Caller[0045e894] Caller[0040fc34] Caller[000228fc] Instruction DUMP: 981223a8 7ffc5ee6 901d <91d02005> 30680003 0100 0100 9de3bf40 1100167b CPU[0]: local_irq_count[0] irqs_running[0] TSTATE: 11f09602 TPC: 00448f68 TNPC: 00448f6c Y: g0: 00691800 g1: 00694800 g2: 003f g3: 738a g4: f800 g5: g6: f8003ec0c000 g7: o0: 00b9 o1: 01148e1b o2: 005a9400 o3: 001a o4: 004de180 o5: sp: f8003ec0f061 ret_pc: 00448e80 l0: 0001 l1: 005a9798 l2: 0062f400 l3: l4: f8003c2f16a0 l5: 0002 l6: 00630400 l7: 00585d30 i0: 0062e500 i1: 00694800 i2: 005a9790 i3: 0001 i4: i5: 000f i6: f8003ec0f121 i7: 00445510 After running through ksymoops: ksymoops 2.3.4 on sparc64 2.4.0-test12. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test12/ (default) -m /boot/System.map-2.4.0-test12 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod file? Reading Oops report from the terminal skput:over: 0053ed64:524 put:-428 dev:eth0 \|/ \|/ "@'/ .. \`@" /_| \__/ |_\ \__U_/ smtp(29923): Kernel bad trap CPU[2]: local_irq_count[0] irqs_running[0] TSTATE: 004411009601 TPC: 00528b50 TNPC: 00528b54 Y: 15e0 Using defaults from ksymoops -t elf32-sparc -a sparc g0: 0020 g1: 20fa29bf28c5 g2: 0041 g3: 00628000 g4: f800 g5: 0001 g6: f800030e8000 g7: o0: 0032 o1: 00629eae o2: 0032 o3: o4: 00629e7b o5: 00629ead sp:
sparc64 network-related problems
Computer Corp. PCI Bus Module Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap- 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- Latency: 64 set 02:00.0 Host bridge: Sun Microsystems Computer Corp. PCI Bus Module Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort+ SERR- PERR- Latency: 64 set 02:01.0 Bridge: Sun Microsystems Computer Corp. EBUS (rev 01) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 10 min, 25 max, 10 set, cache line size 10 Region 0: Memory at 01fff000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at 01fff100 (32-bit, non-prefetchable) [size=8M] Expansion ROM at 8300 [disabled] [size=16M] 02:01.1 Ethernet controller: Sun Microsystems Computer Corp. Happy Meal (rev 01) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 10 min, 5 max, 10 set, cache line size 10 Interrupt: pin ? routed to IRQ 6682912 Region 0: Memory at 01ff80008000 (32-bit, non-prefetchable) [size=32K] Expansion ROM at 8400 [disabled] [size=16M] 02:02.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC 215IIC [Mach64 GT IIC] (rev 3a) (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 0088 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 8 min, 8 set, cache line size 10 Interrupt: pin A routed to IRQ 6682368 Region 0: Memory at 01ff8100 (32-bit, prefetchable) [size=16M] Region 1: I/O ports at 2010500 [size=256] Region 2: [virtual] Memory at 01ff8000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at 8002 [disabled] [size=128K] Capabilities: [5c] Power Management version 1 Flags: PMEClk- AuxPwr- DSI- D1+ D2+ PME- Status: D0 PME-Enable- DSel=0 DScale=0 PME- 02:03.0 Fiber Channel: Emulex Corporation LP7000 Fibre Channel Host Adapter (rev 03) Subsystem: Emulex Corporation: Unknown device f700 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 8 min, 8 set, cache line size 10 [7.6.] SCSI information (from /proc/scsi/scsi) Attached devices: Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: SEAGATE Model: ST39236LWRev: 0010 Type: Direct-AccessANSI SCSI revision: 03 Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: SEAGATE Model: ST39103LWRev: 0002 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 02 Lun: 00 Vendor: SEAGATE Model: ST39102LWRev: 0006 Type: Direct-AccessANSI SCSI revision: 02 [7.7.] Other information that might be relevant to the problem (please look in /proc and include all information that you think to be relevant): The servers are hooked into a Cisco switch. The link up line says: eth0: Link is up using internal transceiver at 100Mb/s, Full Duplex. The default gateway is an Intel box running FreeBSD, also having a full-duplex link to the switch (but with an EtherExpress Pro card). grey:/proc# cat mdstat Personalities : [raid0] read_ahead 1024 sectors md0 : active raid0 sdc1[1] sdb1[0] 17776896 blocks 8k chunks Other kernel log errors: (only seen once): eth0: Happy Meal out of receive descriptors, packet dropped. (very often): UDP: short packet: 1/48 or UDP: short packet: 0/36 and a couple of: sending pkt_too_big to self -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sparc64 network-related problems
000 Dec 8 01:40:48 grey kernel: l4: 8823e000 l5: f8003f1a0430 l6: 0003 l7: 01ffe000 Dec 8 01:40:48 grey kernel: i0: 0080 i1: 7012c000 i2: f8505428 i3: f8003ee66000 Dec 8 01:40:48 grey kernel: i4: i5: 8823e000 i6: f8003e68f551 i7: 0044cfa8 Warning (Oops_read): Code line not seen, dumping what data is available PC; 00449e94 zap_page_range+134/280 = O7; 00449f14 zap_page_range+1b4/280 I7; 0044cfa8 do_munmap+268/300 3 warnings issued. Results may not be reliable. So should I apply your patch ? -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sparc64 network-related problems
On Sun, Dec 10, 2000 at 02:57:21AM -0800, David S. Miller wrote: Date: Sun, 10 Dec 2000 13:10:33 +0200 From: Petru Paler [EMAIL PROTECTED] So should I apply your patch ? Yes, this new OOPS you've sent me is in the same place. Ok, applied. Will email again when/if something shows up in the logs. Thanks, -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
