Re: [OT] gcc 2.95.2 vs. 3.0 (fwd)
On Mon, 25 Jun 2001, J . A . Magallon wrote: > Sure it is opendivx ? I think you are just using gcc compiled code for > the 'interface' and 'glue' to windows divx decoders (/usr/lib/win32/*.dll) > that do the real hard work. Have a look at mplayer.sourceforge.net. MPlayer besides DLL loading also features native Opendivx en/decoding, and native MPEG1/2 decoding. Actually the tests were performed by the leader of the development of mplayer, and he did compile the whole opendivx encore/decore code used in this player, taken from the original sources. > Redo the tests with am MPEG2 movie. Actually since the original posting, on the mplayer-devel list the maintainer of mpeg2play (the portable parts of mplayer as a separate player, w/o the dll stuff) also tested how well MPEG1/2 decoding works if compiled w/ gcc 2.95.2 vs 3.0, and he was disappointed too, because there was a slight decrease in the performanceof the generated code... If you want proof of these, grab the C sources from the mentioned sourceforge project site, and repeat the test yourself. -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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/
[OT] gcc 2.95.2 vs. 3.0 (fwd)
first of all, if you are not interested in compiler comparision, just skip. I though posting a little demonstration of how well performing code gcc 2.95.2 generates (vs. gcc 3.0) won't hurt. Also shown, that further optimatizations are anything but impossible (using Intel's commercial c compiler). I know opendivx code is not like kernel code at all, but on the other hand it is well suited for benchmark testing. Maybe this will cool down thoose a bit, who were to move to gcc 3.0 as fast as possible, for the _way_ better generated code... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ -- Forwarded message -- Date: Sun, 24 Jun 2001 04:31:56 +0200 (CEST) From: Arpi <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Mplayer-users] gcc 2.95.2 vs. 3.0 Hi, Just compiled and try gcc 3.0 stable. And the results is very big surprise! It makes *SLOWER* code! test file: (opendivx with postprocessing, this stuff is written in C) # mplayer -osdlevel 0 -nosound -benchmark 1800.avi -vo null -pp 15 VIDEO: [divx] 640x352 24bpp 23.98 fps 1865.1 kbps (227.7 kbyte/s) hardware: celeron-2 600 @ 900MHz (100MHz FSB), 256MB RAM (PC133, at 2/2/2) (sse,mmx,mmxext enabled) gcc 2.95.2 result: (flags: -O4 -march=i686 -mcpu=i686 -pipe -ffast-math) BENCHMARKs: V: 5.087s VO: 0.001s A: 0.000s Sys: 0.013s =5.101s BENCHMARK%: V: 99.7160% VO: 0.0258% A: 0.% Sys: 0.2582% = 100.% gcc 3.0 result: (flags: -O4 -march=i686 -mcpu=i686 -pipe -ffast-math) BENCHMARKs: V: 5.194s VO: 0.001s A: 0.000s Sys: 0.013s =5.208s BENCHMARK%: V: 99.7309% VO: 0.0221% A: 0.% Sys: 0.2471% = 100.% yes, speed diff isn't big, but i was prepared for big speed boost by 3.0, and then i got speed loss! :( if i recompile C-only parts of decore with intel's commercial C compiler (free beta available for linux), it's about 15% faster: icc result: (optim. flags: -O2 -fp -rcd -tpp6 -xiMK) BENCHMARKs: V: 4.415s VO: 0.001s A: 0.000s Sys: 0.013s =4.429s BENCHMARK%: V: 99.6676% VO: 0.0290% A: 0.% Sys: 0.3034% = 100.% A'rpi / Astral & ESP-team -- mailto:[EMAIL PROTECTED] http://esp-team.scene.hu ___ Mplayer-users mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/mplayer-users - 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/
[OT] gcc 2.95.2 vs. 3.0 (fwd)
first of all, if you are not interested in compiler comparision, just skip. I though posting a little demonstration of how well performing code gcc 2.95.2 generates (vs. gcc 3.0) won't hurt. Also shown, that further optimatizations are anything but impossible (using Intel's commercial c compiler). I know opendivx code is not like kernel code at all, but on the other hand it is well suited for benchmark testing. Maybe this will cool down thoose a bit, who were to move to gcc 3.0 as fast as possible, for the _way_ better generated code... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ -- Forwarded message -- Date: Sun, 24 Jun 2001 04:31:56 +0200 (CEST) From: Arpi [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Mplayer-users] gcc 2.95.2 vs. 3.0 Hi, Just compiled and try gcc 3.0 stable. And the results is very big surprise! It makes *SLOWER* code! test file: (opendivx with postprocessing, this stuff is written in C) # mplayer -osdlevel 0 -nosound -benchmark 1800.avi -vo null -pp 15 VIDEO: [divx] 640x352 24bpp 23.98 fps 1865.1 kbps (227.7 kbyte/s) hardware: celeron-2 600 @ 900MHz (100MHz FSB), 256MB RAM (PC133, at 2/2/2) (sse,mmx,mmxext enabled) gcc 2.95.2 result: (flags: -O4 -march=i686 -mcpu=i686 -pipe -ffast-math) BENCHMARKs: V: 5.087s VO: 0.001s A: 0.000s Sys: 0.013s =5.101s BENCHMARK%: V: 99.7160% VO: 0.0258% A: 0.% Sys: 0.2582% = 100.% gcc 3.0 result: (flags: -O4 -march=i686 -mcpu=i686 -pipe -ffast-math) BENCHMARKs: V: 5.194s VO: 0.001s A: 0.000s Sys: 0.013s =5.208s BENCHMARK%: V: 99.7309% VO: 0.0221% A: 0.% Sys: 0.2471% = 100.% yes, speed diff isn't big, but i was prepared for big speed boost by 3.0, and then i got speed loss! :( if i recompile C-only parts of decore with intel's commercial C compiler (free beta available for linux), it's about 15% faster: icc result: (optim. flags: -O2 -fp -rcd -tpp6 -xiMK) BENCHMARKs: V: 4.415s VO: 0.001s A: 0.000s Sys: 0.013s =4.429s BENCHMARK%: V: 99.6676% VO: 0.0290% A: 0.% Sys: 0.3034% = 100.% A'rpi / Astral ESP-team -- mailto:[EMAIL PROTECTED] http://esp-team.scene.hu ___ Mplayer-users mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/mplayer-users - 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: [OT] gcc 2.95.2 vs. 3.0 (fwd)
On Mon, 25 Jun 2001, J . A . Magallon wrote: Sure it is opendivx ? I think you are just using gcc compiled code for the 'interface' and 'glue' to windows divx decoders (/usr/lib/win32/*.dll) that do the real hard work. Have a look at mplayer.sourceforge.net. MPlayer besides DLL loading also features native Opendivx en/decoding, and native MPEG1/2 decoding. Actually the tests were performed by the leader of the development of mplayer, and he did compile the whole opendivx encore/decore code used in this player, taken from the original sources. Redo the tests with am MPEG2 movie. Actually since the original posting, on the mplayer-devel list the maintainer of mpeg2play (the portable parts of mplayer as a separate player, w/o the dll stuff) also tested how well MPEG1/2 decoding works if compiled w/ gcc 2.95.2 vs 3.0, and he was disappointed too, because there was a slight decrease in the performanceof the generated code... If you want proof of these, grab the C sources from the mentioned sourceforge project site, and repeat the test yourself. -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Kernel 2.4.x TODO
> Check out the kernel janitor project at > http://bazar.conectiva.com.br/~acme/TODO (original) Is this information up2date? If it is, sad to see we have this many bugs... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Kernel 2.4.x TODO
Check out the kernel janitor project at http://bazar.conectiva.com.br/~acme/TODO (original) Is this information up2date? If it is, sad to see we have this many bugs... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Linux scalability?
On Fri, 18 May 2001, Sean Hunter wrote: > Why would you want to run a web server with 8 processors rather than four > webservers with 2 each? As you might already know, after the interviews to Mingo I assumed, that a major portion of the achievements was enabled by the 2.4 scalability enhacements. That is why I wrote to LKML, to ask about the 2.4 scalability, if anybody out there could tell us about the linux kernel's scalability possibily compared to W2k scalability... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Linux scalability?
On 18 May 2001, reiser.angus wrote: > not really the same box > look at the disk subsystem > 7 x 9GB 10KRPM Drives and 1 x 18GB 15KRPM (html+log & os) for Win2000 > 5 x 9GB 10KRPM Drives (html+log+os) for TUX 2.0 > this is sufficient for a such difference Don't you think that all the really needed stuff could just fit in the enormous ram of the boxes? -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Linux scalability?
On 18 May 2001, reiser.angus wrote: not really the same box look at the disk subsystem 7 x 9GB 10KRPM Drives and 1 x 18GB 15KRPM (html+log os) for Win2000 5 x 9GB 10KRPM Drives (html+log+os) for TUX 2.0 this is sufficient for a such difference Don't you think that all the really needed stuff could just fit in the enormous ram of the boxes? -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Linux scalability?
On Fri, 18 May 2001, Sean Hunter wrote: Why would you want to run a web server with 8 processors rather than four webservers with 2 each? As you might already know, after the interviews to Mingo I assumed, that a major portion of the achievements was enabled by the 2.4 scalability enhacements. That is why I wrote to LKML, to ask about the 2.4 scalability, if anybody out there could tell us about the linux kernel's scalability possibily compared to W2k scalability... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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/
Linux scalability?
Hi! I am just writing an essay, an have mentioned TUX as a performance and scalability linearity recort holder with TUX, referencing the specweb99 website summary page: http://www.spec.org/osg/web99/results/web99.html However, taking a closer look, it turns out, that the above statement holds true only for 1 and 2 processor machines. Scalability already suffers at 4 processors, and at 8 processors, TUX 2.0 (7500) gets beaten by IIS 5.0 (8001), and these were measured on the same kind of box! How come, TUX is s good at the lowend (1 and 2 CPUs), and scales this bad? -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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/
Linux scalability?
Hi! I am just writing an essay, an have mentioned TUX as a performance and scalability linearity recort holder with TUX, referencing the specweb99 website summary page: http://www.spec.org/osg/web99/results/web99.html However, taking a closer look, it turns out, that the above statement holds true only for 1 and 2 processor machines. Scalability already suffers at 4 processors, and at 8 processors, TUX 2.0 (7500) gets beaten by IIS 5.0 (8001), and these were measured on the same kind of box! How come, TUX is s good at the lowend (1 and 2 CPUs), and scales this bad? -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Linux 2.4.4-ac10
On Thu, 17 May 2001, Rik van Riel wrote: > Or are you just comparing with 2.2 and you'd rather > have 2.2 performance? ;) Actually, yes. Doing fileserving with Samba, and also using the box interactively feels better with 2.2, and also the average TCP througput (measured by iptraf) seems higher. -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Linux 2.4.4-ac10
On Thu, 17 May 2001, Rik van Riel wrote: Or are you just comparing with 2.2 and you'd rather have 2.2 performance? ;) Actually, yes. Doing fileserving with Samba, and also using the box interactively feels better with 2.2, and also the average TCP througput (measured by iptraf) seems higher. -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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/
Small es1371 documentation fix (joyport) (fwd)
Same patch should be applied for the es1370 also. (at least the joystick part.) -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ -- Forwarded message -- Date: Wed, 09 May 2001 15:36:21 -0400 From: David Riley <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Small es1371 documentation fix (joyport) The documentation for the es1371 driver doesn't mention how to activate/specify the joystick port's base address (I had to look in the code). This patch fixes it. The same probably applies to the es1370 as well as other cards, but lacking said cards, I couldn't say for sure. You may wish to re-word this, as it is not very concise, nor does it read well (not that that's ever mattered in documentation before ;-). If you have any replies, please CC me directly (I'm no longer subscribed to the list). Thanks, David --- es1371 Fri Jul 10 17:03:35 1998 +++ es1371 Wed May 9 15:20:56 2001 @@ -1,3 +1,11 @@ +/proc/sound, /dev/sndstat +- + +/proc/sound and /dev/sndstat is not supported by the +driver. To find out whether the driver succeeded loading, +check the kernel log (dmesg). + + ALaw/uLaw sample formats @@ -51,6 +59,16 @@ See http://www.cgs.fi/~tt/timidity/. +Joystick Port +- + +To enable the joystick port, enter "es1371=[port addr]" on the +kernel command line. Alternatively, if running as a module, +enter "joystick=[port addr]" on the module's option line. +Accepatble values for "port addr" are 0x200, 0x208, 0x210, and +0x218. + + Thomas Sailer [EMAIL PROTECTED] [EMAIL PROTECTED]
Small es1371 documentation fix (joyport) (fwd)
Same patch should be applied for the es1370 also. (at least the joystick part.) -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ -- Forwarded message -- Date: Wed, 09 May 2001 15:36:21 -0400 From: David Riley [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Small es1371 documentation fix (joyport) The documentation for the es1371 driver doesn't mention how to activate/specify the joystick port's base address (I had to look in the code). This patch fixes it. The same probably applies to the es1370 as well as other cards, but lacking said cards, I couldn't say for sure. You may wish to re-word this, as it is not very concise, nor does it read well (not that that's ever mattered in documentation before ;-). If you have any replies, please CC me directly (I'm no longer subscribed to the list). Thanks, David --- es1371 Fri Jul 10 17:03:35 1998 +++ es1371 Wed May 9 15:20:56 2001 @@ -1,3 +1,11 @@ +/proc/sound, /dev/sndstat +- + +/proc/sound and /dev/sndstat is not supported by the +driver. To find out whether the driver succeeded loading, +check the kernel log (dmesg). + + ALaw/uLaw sample formats @@ -51,6 +59,16 @@ See http://www.cgs.fi/~tt/timidity/. +Joystick Port +- + +To enable the joystick port, enter es1371=[port addr] on the +kernel command line. Alternatively, if running as a module, +enter joystick=[port addr] on the module's option line. +Accepatble values for port addr are 0x200, 0x208, 0x210, and +0x218. + + Thomas Sailer [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Is sendfile all that sexy?
On Thu, 25 Jan 2001, Anton Blanchard wrote: > I have patches for samba to do sendfile. Making a tux module does not make > sense to me, especially since we are nowhere near the limits of samba in > userspace. Once userspace samba can run no faster, then we should think > about other options. Do you have it at a URL? -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Is sendfile all that sexy?
On Thu, 25 Jan 2001, Anton Blanchard wrote: I have patches for samba to do sendfile. Making a tux module does not make sense to me, especially since we are nowhere near the limits of samba in userspace. Once userspace samba can run no faster, then we should think about other options. Do you have it at a URL? -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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.2.19pre6aa1 USB - Why do I get these?
Previously unseen. What could be the cause of these messages? (Abit BH6 (Intel BX), Logitech Mouseman+ USB) Jan 24 21:39:15 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 21:39:16 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 21:44:22 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 21:44:24 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 21:48:53 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 21:48:55 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 21:51:06 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 21:51:06 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 21:51:38 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 21:51:38 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 22:07:45 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 22:07:47 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 22:10:24 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 22:10:25 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 22:11:32 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 22:11:33 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 22:11:57 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 22:11:59 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 22:13:50 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 22:13:52 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 23:13:48 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 23:13:50 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 23:16:35 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 23:16:37 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Is sendfile all that sexy?
> AIUI, Jeff Merkey was working on loading "userspace" apps into the kernel > to tackle this sort of problem generically. I don't know if he's tried it > with Samba - the forking would probably be a problem... I think, that is not what we need. Once Ingo wrote, that since HTTP serving can also be viewed as a kind of fileserving, it should be possible to create a TUX like module for the same framwork, that serves using the SMB protocol instead of HTTP... -- SaPE / Sasi Péter / mailto: [EMAIL PROTECTED] / http://sape.iq.rulez.org/ - 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: Ingo's RAID patch for 2.2.18 final?
> > (30+ high speed streams from 4 disks does really need some caching). > This isn't obvious. Your working may not fit in cache and so the kernel > understand it's worthless to swapout stuff to make space to a polluted cache. But your understanding agrees on that the larger chunks for each stream we read into cache, the more efficient for this kind of RAID disk structure the read is, thus basically the more cache we have, the more bandwidth we can serve. (disks give more data in the same time with fewer long reads than with several shorter ones) So might it have been an accidental behaviour of the previous kernels to swap out pages in favor of caching under high I/O pressure, but it was certainly a benefical behaviour. > > Can't say, of these many daemons nothing can be swapped out (and should > > under I/O load)! > If you run `cp /dev/zero .` on a smart VM nothing must be swapped out even if > it generated nearly the maximal I/O flood possible. It's worthless to let a > polluted cache to grow. It won't help anyways and you'll run slower the next > time you'll have to pagein from swap. > It _enterely_ depends on the I/O load pattern if it worth to swapout or not > to make space for filesystem cache. Ok (possibily incorrect, but simple) definition of I/O pressure of mine is when the _real_ _physical_ disks are working all the time, pushing data out of the box (in this case through the network). "cp /dev/zero ." is a somewhat different from my case: - mine is an IRL case (don't know how often a pattern like the "cp" case show up IRL) - Mine is about _reading_ from disks > > Be this, if this is the price for stability. > As said we can add bits of page aging (that can't destabilize anything and it > will only affect performance behaviour), but I'd prefer to be sure you really > get a slowdown due the new VM behaviour (because more aging if done without > multiqueue O(1) approch can introduces waste of CPU and cachelines in kernel > space), so could you try to kill notes and squid and the other unused stuff and > to see if you return to deliver performance as with the older kernels? I still It might and it should, but actually I gotta have these started in case someone drops in for using them. As I understand the only thing this is worth trying out for is that maybe even with more cache I will have less performance, than before, because in this case to or not to swap out dows not really matter. Is this correct? Beacuse I will have to have these running anyways... > miss this important information (last thing you said me was that with 100mbyte > in cache it swapouts, and without knowing the details of the I/O pattern it like when decreasing constantly, at reaching that only 100MB cache we have left do we start swapping to have more cache, or at least have the 100MB not less. > looked sane). After that I'd also like to know what happens with 2.4.0 that > uses multiqueue and that is also able to detect pollution and to avoid swapping > out in such case. What should I test with? (2.4.0/1pre?) -- SaPE / Sasi Péter / mailto: [EMAIL PROTECTED] / http://sape.iq.rulez.org/ - 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: Ingo's RAID patch for 2.2.18 final?
(30+ high speed streams from 4 disks does really need some caching). This isn't obvious. Your working may not fit in cache and so the kernel understand it's worthless to swapout stuff to make space to a polluted cache. But your understanding agrees on that the larger chunks for each stream we read into cache, the more efficient for this kind of RAID disk structure the read is, thus basically the more cache we have, the more bandwidth we can serve. (disks give more data in the same time with fewer long reads than with several shorter ones) So might it have been an accidental behaviour of the previous kernels to swap out pages in favor of caching under high I/O pressure, but it was certainly a benefical behaviour. Can't say, of these many daemons nothing can be swapped out (and should under I/O load)! If you run `cp /dev/zero .` on a smart VM nothing must be swapped out even if it generated nearly the maximal I/O flood possible. It's worthless to let a polluted cache to grow. It won't help anyways and you'll run slower the next time you'll have to pagein from swap. It _enterely_ depends on the I/O load pattern if it worth to swapout or not to make space for filesystem cache. Ok (possibily incorrect, but simple) definition of I/O pressure of mine is when the _real_ _physical_ disks are working all the time, pushing data out of the box (in this case through the network). "cp /dev/zero ." is a somewhat different from my case: - mine is an IRL case (don't know how often a pattern like the "cp" case show up IRL) - Mine is about _reading_ from disks Be this, if this is the price for stability. As said we can add bits of page aging (that can't destabilize anything and it will only affect performance behaviour), but I'd prefer to be sure you really get a slowdown due the new VM behaviour (because more aging if done without multiqueue O(1) approch can introduces waste of CPU and cachelines in kernel space), so could you try to kill notes and squid and the other unused stuff and to see if you return to deliver performance as with the older kernels? I still It might and it should, but actually I gotta have these started in case someone drops in for using them. As I understand the only thing this is worth trying out for is that maybe even with more cache I will have less performance, than before, because in this case to or not to swap out dows not really matter. Is this correct? Beacuse I will have to have these running anyways... miss this important information (last thing you said me was that with 100mbyte in cache it swapouts, and without knowing the details of the I/O pattern it like when decreasing constantly, at reaching that only 100MB cache we have left do we start swapping to have more cache, or at least have the 100MB not less. looked sane). After that I'd also like to know what happens with 2.4.0 that uses multiqueue and that is also able to detect pollution and to avoid swapping out in such case. What should I test with? (2.4.0/1pre?) -- SaPE / Sasi Pter / mailto: [EMAIL PROTECTED] / http://sape.iq.rulez.org/ - 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: Is sendfile all that sexy?
AIUI, Jeff Merkey was working on loading "userspace" apps into the kernel to tackle this sort of problem generically. I don't know if he's tried it with Samba - the forking would probably be a problem... I think, that is not what we need. Once Ingo wrote, that since HTTP serving can also be viewed as a kind of fileserving, it should be possible to create a TUX like module for the same framwork, that serves using the SMB protocol instead of HTTP... -- SaPE / Sasi Pter / mailto: [EMAIL PROTECTED] / http://sape.iq.rulez.org/ - 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.2.19pre6aa1 USB - Why do I get these?
Previously unseen. What could be the cause of these messages? (Abit BH6 (Intel BX), Logitech Mouseman+ USB) Jan 24 21:39:15 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 21:39:16 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 21:44:22 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 21:44:24 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 21:48:53 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 21:48:55 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 21:51:06 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 21:51:06 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 21:51:38 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 21:51:38 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 22:07:45 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 22:07:47 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 22:10:24 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 22:10:25 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 22:11:32 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 22:11:33 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 22:11:57 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 22:11:59 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 22:13:50 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 22:13:52 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 23:13:48 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 23:13:50 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters Jan 24 23:16:35 iq kernel: usb.c: bw_alloc reduced by 118 to 0 for 0 requesters Jan 24 23:16:37 iq kernel: usb.c: bw_alloc increased by 118 to 118 for 1 requesters -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Is sendfile all that sexy?
On 14 Jan 2001, Linus Torvalds wrote: > The only obvious use for it is file serving, and as high-performance > file serving tends to end up as a kernel module in the end anyway (the > only hold-out is samba, and that's been discussed too), "sendfile()" > really is more a proof of concept than anything else. No plans for samba to use sendfile? Even better make it a tux-like module? (that would enable Netware-Linux like performance with the standard kernel... would be cool afterall ;) -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Ingo's RAID patch for 2.2.18 final?
On Wed, 24 Jan 2001, Andrea Arcangeli wrote: > > 2.2.19preXaaX Virtually disabled I/O cache extention-by-swapout, working > > on previous (semi)stock kernels (raid+ide patched) :( > Can you measure a performance degradation because of that? Previous kernels was > certainly not a good example because they was swapping out stuff even with > `cp /dev/zero .`. Still produced an overall average extra 30+% more serviced bandwidth for fileserving. (large files, we can call them high BW streaming...) > You said me your machine start to swapout when the filesystem cache reaches > 100mbytes (on your 384Mbyte box). That seems sane behaviour on a misc load. We Nope. > could add some additional bit of page aging to swapout more when it worth > indeed, but current balance looks just quite sane. Ok let's see: the box does a lot of this fileserving. 3MB/s+ Sometimes I use it interactivelly (pine, X, netscape). Sometimes others log in remotely, pine, etc. Sometimes they read their mail (apache, neomail) bind runs for one (1) zone. Sshd is listening. Sendmail is listening. Infrequently friends use squid proxy on it. Notes runs, currently is being tested, buteven more infrequently. => So, basically, a lot of stuff is runing, but they are rarely used. Compared to the gain which could result swapping out the more or less inactive processes' pages, freeing ram for the all time fileservings cache (30+ high speed streams from 4 disks does really need some caching). I do not say the case is "nothing is active please store everything on swap, get back only what is needed", but the actual situation is on the contrary: 0 (zero) bytes swapped out! Can't say, of these many daemons nothing can be swapped out (and should under I/O load)! And even if I don't think this zero swapping is ok, I do use it, because I do not get a single "VM: do_try_to_free_pages failed for ..." no more... The performance just used to be better, but the whole more instable. Be this, if this is the price for stability. -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Ingo's RAID patch for 2.2.18 final?
On Sun, 14 Jan 2001, Godfrey Livingstone wrote: > You MUST apply this patch before the two raid patches. The VM patch stablises > the 2.2.18 virtual memory system and if you don't apply my two repackaged > patches will fail. The above VM patch has been accepted into 2.2.19pre3 and > many people are using it so is not untested. 2.2.19preXaaX Virtually disabled I/O cache extention-by-swapout, working on previous (semi)stock kernels (raid+ide patched) :( Thus I wouldn't advise VM global till it gets somewhatbalanced to non-swapless configs... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Ingo's RAID patch for 2.2.18 final?
On Sun, 14 Jan 2001, Godfrey Livingstone wrote: You MUST apply this patch before the two raid patches. The VM patch stablises the 2.2.18 virtual memory system and if you don't apply my two repackaged patches will fail. The above VM patch has been accepted into 2.2.19pre3 and many people are using it so is not untested. 2.2.19preXaaX Virtually disabled I/O cache extention-by-swapout, working on previous (semi)stock kernels (raid+ide patched) :( Thus I wouldn't advise VM global till it gets somewhatbalanced to non-swapless configs... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Ingo's RAID patch for 2.2.18 final?
On Wed, 24 Jan 2001, Andrea Arcangeli wrote: 2.2.19preXaaX Virtually disabled I/O cache extention-by-swapout, working on previous (semi)stock kernels (raid+ide patched) :( Can you measure a performance degradation because of that? Previous kernels was certainly not a good example because they was swapping out stuff even with `cp /dev/zero .`. Still produced an overall average extra 30+% more serviced bandwidth for fileserving. (large files, we can call them high BW streaming...) You said me your machine start to swapout when the filesystem cache reaches 100mbytes (on your 384Mbyte box). That seems sane behaviour on a misc load. We Nope. could add some additional bit of page aging to swapout more when it worth indeed, but current balance looks just quite sane. Ok let's see: the box does a lot of this fileserving. 3MB/s+ Sometimes I use it interactivelly (pine, X, netscape). Sometimes others log in remotely, pine, etc. Sometimes they read their mail (apache, neomail) bind runs for one (1) zone. Sshd is listening. Sendmail is listening. Infrequently friends use squid proxy on it. Notes runs, currently is being tested, buteven more infrequently. = So, basically, a lot of stuff is runing, but they are rarely used. Compared to the gain which could result swapping out the more or less inactive processes' pages, freeing ram for the all time fileservings cache (30+ high speed streams from 4 disks does really need some caching). I do not say the case is "nothing is active please store everything on swap, get back only what is needed", but the actual situation is on the contrary: 0 (zero) bytes swapped out! Can't say, of these many daemons nothing can be swapped out (and should under I/O load)! And even if I don't think this zero swapping is ok, I do use it, because I do not get a single "VM: do_try_to_free_pages failed for ..." no more... The performance just used to be better, but the whole more instable. Be this, if this is the price for stability. -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Is sendfile all that sexy?
On 14 Jan 2001, Linus Torvalds wrote: The only obvious use for it is file serving, and as high-performance file serving tends to end up as a kernel module in the end anyway (the only hold-out is samba, and that's been discussed too), "sendfile()" really is more a proof of concept than anything else. No plans for samba to use sendfile? Even better make it a tux-like module? (that would enable Netware-Linux like performance with the standard kernel... would be cool afterall ;) -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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.2.19pre6aa1 weird error
Jan 13 01:58:17 iq kernel: probable hardware bug: clock timer configuration lost - probably a VIA686a. Jan 13 01:58:17 iq kernel: probable hardware bug: restoring chip configuration. I get these, do not know why. MB is abit BH6, IDE controllers are the onboard and a WinFast CMD648. Have never seen such before (2.0.x and 2.2.x up till now). Bug rather in SW maybe? SaPE - 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.2.19pre6aa1 weird error
Jan 13 01:58:17 iq kernel: probable hardware bug: clock timer configuration lost - probably a VIA686a. Jan 13 01:58:17 iq kernel: probable hardware bug: restoring chip configuration. I get these, do not know why. MB is abit BH6, IDE controllers are the onboard and a WinFast CMD648. Have never seen such before (2.0.x and 2.2.x up till now). Bug rather in SW maybe? SaPE - 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.2.19pre6aa1 degraded performance for me...
On Tue, 9 Jan 2001, Sasi Peter wrote: > On Tue, 9 Jan 2001, Andrea Arcangeli wrote: > > On Mon, Jan 08, 2001 at 10:46:29PM +0100, Sasi Peter wrote: > > > What I had w/2.2.18pre19 (+raid+ide): > > > ~80MB more in cache and ~80MB swapped out (eg. currently unused notes > > > server and squid) There is enough of swap over 3 disks (like the > > > raid), so I did not bother disabling squid and notes, since - I thought - > > > they would only take up some swap unused. > > There are many variables. However I guess the slowdown is because your idle > > apps didn't got swapped out in favour of cache as you noticed. An aggressive > > aging algorithm would probably fix that but it then would hurt other cases > > (after you don't need a frequenty accessed part of filesystem cache anymore it > > would take ages before it gets collected potentially causing an unnecessary > > swapout storms because the kernel doesn't know you don't need such cache > > anymore). Furthmore if notes and squid are rarely running but they provides > > critical services if they would go totally into swap in favour of fs cache you > > would get very bad latencies the first time somebody connects to the server. So > > the fix I suggest you is to buy more ram or to shutdown squid and notes. Than > Oh well I thought 384MB should be enought for everyone aiming at this > performance (almost TM ;). At least it would up till now :( > > you may as well see a performance improvement compared to 2.2.18pre19 > > (+raid+ide). Otherwise you can push the machine low on memory a bit until they > > both goes totally into swap (check with `ps v`). Hope this helps. > I'll try this, thanks. (so no echo '1 23 456' >/proc/sys/vm/...?) I thought it over again. I still have to say it is a nonsense for a kernel not to have _anything_ (zero pages) currently unused swapped out under such an I/O load! -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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.2.19pre6aa1 degraded performance for me...
On Tue, 9 Jan 2001, Sasi Peter wrote: On Tue, 9 Jan 2001, Andrea Arcangeli wrote: On Mon, Jan 08, 2001 at 10:46:29PM +0100, Sasi Peter wrote: What I had w/2.2.18pre19 (+raid+ide): ~80MB more in cache and ~80MB swapped out (eg. currently unused notes server and squid) There is enough of swap over 3 disks (like the raid), so I did not bother disabling squid and notes, since - I thought - they would only take up some swap unused. There are many variables. However I guess the slowdown is because your idle apps didn't got swapped out in favour of cache as you noticed. An aggressive aging algorithm would probably fix that but it then would hurt other cases (after you don't need a frequenty accessed part of filesystem cache anymore it would take ages before it gets collected potentially causing an unnecessary swapout storms because the kernel doesn't know you don't need such cache anymore). Furthmore if notes and squid are rarely running but they provides critical services if they would go totally into swap in favour of fs cache you would get very bad latencies the first time somebody connects to the server. So the fix I suggest you is to buy more ram or to shutdown squid and notes. Than Oh well I thought 384MB should be enought for everyone aiming at this performance (almost TM ;). At least it would up till now :( you may as well see a performance improvement compared to 2.2.18pre19 (+raid+ide). Otherwise you can push the machine low on memory a bit until they both goes totally into swap (check with `ps v`). Hope this helps. I'll try this, thanks. (so no echo '1 23 456' /proc/sys/vm/...?) I thought it over again. I still have to say it is a nonsense for a kernel not to have _anything_ (zero pages) currently unused swapped out under such an I/O load! -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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.2.19pre6aa1 degraded performance for me...
On Tue, 9 Jan 2001, Andrea Arcangeli wrote: > On Mon, Jan 08, 2001 at 10:46:29PM +0100, Sasi Peter wrote: > > What I had w/2.2.18pre19 (+raid+ide): > > ~80MB more in cache and ~80MB swapped out (eg. currently unused notes > > server and squid) There is enough of swap over 3 disks (like the > > raid), so I did not bother disabling squid and notes, since - I thought - > > they would only take up some swap unused. > > There are many variables. However I guess the slowdown is because your idle > apps didn't got swapped out in favour of cache as you noticed. An aggressive > aging algorithm would probably fix that but it then would hurt other cases > (after you don't need a frequenty accessed part of filesystem cache anymore it > would take ages before it gets collected potentially causing an unnecessary > swapout storms because the kernel doesn't know you don't need such cache > anymore). Furthmore if notes and squid are rarely running but they provides > critical services if they would go totally into swap in favour of fs cache you > would get very bad latencies the first time somebody connects to the server. So > the fix I suggest you is to buy more ram or to shutdown squid and notes. Than Oh well I thought 384MB should be enought for everyone aiming at this performance (almost TM ;). At least it would up till now :( > you may as well see a performance improvement compared to 2.2.18pre19 > (+raid+ide). Otherwise you can push the machine low on memory a bit until they > both goes totally into swap (check with `ps v`). Hope this helps. I'll try this, thanks. (so no echo '1 23 456' >/proc/sys/vm/...?) -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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.2.19pre6aa1 degraded performance for me...
...compared to 2.2.18pre19. I use the IDE patch for my CMD648 card, and also 0.90 RAID. What I have now (2.2.19pre6aa1+ide-1221): [root@iq /root]# hdparm /dev/hd[aceg] /dev/hda: multcount= 16 (on) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 1 (on) nowerr = 0 (off) readonly = 0 (off) readahead= 16 (on) geometry = 13240/16/63, sectors = 13345920, start = 0 /dev/hdc: multcount= 16 (on) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 1 (on) nowerr = 0 (off) readonly = 0 (off) readahead= 16 (on) geometry = 35324/16/63, sectors = 35606592, start = 0 /dev/hde: multcount= 16 (on) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 1 (on) nowerr = 0 (off) readonly = 0 (off) readahead= 16 (on) geometry = 39560/16/63, sectors = 39876480, start = 0 /dev/hdg: multcount= 16 (on) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 1 (on) nowerr = 0 (off) readonly = 0 (off) readahead= 16 (on) geometry = 39560/16/63, sectors = 39876480, start = 0 [root@iq /root]# free -o total used free sharedbuffers cached Mem:392808 389948 2860 0 15732 177004 Swap: 308432 0 308432 [root@iq /root]# cat /proc/swaps FilenameTypeSizeUsedPriority /dev/hda2 partition 102812 0 0 /dev/hde2 partition 102812 0 0 /dev/hdg2 partition 102808 0 0 [root@iq /root]# smbstatus|grep -E ' [[:digit:]]+.[[:digit:]]+.[[:digit:]]+.[[:digit:]]+'|cut -c 30-39|sort|uniq|wc -l 41 [root@iq /root]# ifspeed 1 1.578717MB/s 00> 1.758066MB/s 0> 1.526362MB/s 0> 1.530314MB/s 0> 1.659107MB/s 000> 1.722287MB/s > 1.542517MB/s 00> 1.585877MB/s 00> 1.417126MB/s > 1.496284MB/s 0> 1.442938MB/s > 1.743159MB/s 0> 1.716102MB/s > 1.765166MB/s 0> 1.509863MB/s 0> 1.638345MB/s 000> 1.953884MB/s > 1.723031MB/s > 1.917233MB/s 000> 1.474753MB/s 0> (I have just sent ifspeed to this list) So sustained througput on eth0 (Digital DE500) below 2MBytes/s currently. used to be >5MBytes/s with this many users (they are either changing and reading dirs, or reading or writing >500MBytes files, so speed, bandwidth, throughput would be essential) What I had w/2.2.18pre19 (+raid+ide): ~80MB more in cache and ~80MB swapped out (eg. currently unused notes server and squid) There is enough of swap over 3 disks (like the raid), so I did not bother disabling squid and notes, since - I thought - they would only take up some swap unused. Unfortunatelly not so. Anybody has ideas of some /proc tuning maybe able to help my situation? ( currently I use: # Enable more files and inodes to be used echo '65536' > /proc/sys/fs/file-max echo '262144' > /proc/sys/fs/inode-max echo "10240 61000" > /proc/sys/net/ipv4/ip_local_port_range echo "134217728" > /proc/sys/kernel/shmmax echo "300" > /proc/sys/net/ipv4/tcp_keepalive_time ) -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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.2.19pre6aa1 degraded performance for me...
...compared to 2.2.18pre19. I use the IDE patch for my CMD648 card, and also 0.90 RAID. What I have now (2.2.19pre6aa1+ide-1221): [root@iq /root]# hdparm /dev/hd[aceg] /dev/hda: multcount= 16 (on) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 1 (on) nowerr = 0 (off) readonly = 0 (off) readahead= 16 (on) geometry = 13240/16/63, sectors = 13345920, start = 0 /dev/hdc: multcount= 16 (on) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 1 (on) nowerr = 0 (off) readonly = 0 (off) readahead= 16 (on) geometry = 35324/16/63, sectors = 35606592, start = 0 /dev/hde: multcount= 16 (on) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 1 (on) nowerr = 0 (off) readonly = 0 (off) readahead= 16 (on) geometry = 39560/16/63, sectors = 39876480, start = 0 /dev/hdg: multcount= 16 (on) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 1 (on) nowerr = 0 (off) readonly = 0 (off) readahead= 16 (on) geometry = 39560/16/63, sectors = 39876480, start = 0 [root@iq /root]# free -o total used free sharedbuffers cached Mem:392808 389948 2860 0 15732 177004 Swap: 308432 0 308432 [root@iq /root]# cat /proc/swaps FilenameTypeSizeUsedPriority /dev/hda2 partition 102812 0 0 /dev/hde2 partition 102812 0 0 /dev/hdg2 partition 102808 0 0 [root@iq /root]# smbstatus|grep -E ' [[:digit:]]+.[[:digit:]]+.[[:digit:]]+.[[:digit:]]+'|cut -c 30-39|sort|uniq|wc -l 41 [root@iq /root]# ifspeed 1 1.578717MB/s 00 1.758066MB/s 0 1.526362MB/s 0 1.530314MB/s 0 1.659107MB/s 000 1.722287MB/s 1.542517MB/s 00 1.585877MB/s 00 1.417126MB/s 1.496284MB/s 0 1.442938MB/s 1.743159MB/s 0 1.716102MB/s 1.765166MB/s 0 1.509863MB/s 0 1.638345MB/s 000 1.953884MB/s 1.723031MB/s 1.917233MB/s 000 1.474753MB/s 0 (I have just sent ifspeed to this list) So sustained througput on eth0 (Digital DE500) below 2MBytes/s currently. used to be 5MBytes/s with this many users (they are either changing and reading dirs, or reading or writing 500MBytes files, so speed, bandwidth, throughput would be essential) What I had w/2.2.18pre19 (+raid+ide): ~80MB more in cache and ~80MB swapped out (eg. currently unused notes server and squid) There is enough of swap over 3 disks (like the raid), so I did not bother disabling squid and notes, since - I thought - they would only take up some swap unused. Unfortunatelly not so. Anybody has ideas of some /proc tuning maybe able to help my situation? ( currently I use: # Enable more files and inodes to be used echo '65536' /proc/sys/fs/file-max echo '262144' /proc/sys/fs/inode-max echo "10240 61000" /proc/sys/net/ipv4/ip_local_port_range echo "134217728" /proc/sys/kernel/shmmax echo "300" /proc/sys/net/ipv4/tcp_keepalive_time ) -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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.2.19pre6aa1 degraded performance for me...
On Tue, 9 Jan 2001, Andrea Arcangeli wrote: On Mon, Jan 08, 2001 at 10:46:29PM +0100, Sasi Peter wrote: What I had w/2.2.18pre19 (+raid+ide): ~80MB more in cache and ~80MB swapped out (eg. currently unused notes server and squid) There is enough of swap over 3 disks (like the raid), so I did not bother disabling squid and notes, since - I thought - they would only take up some swap unused. There are many variables. However I guess the slowdown is because your idle apps didn't got swapped out in favour of cache as you noticed. An aggressive aging algorithm would probably fix that but it then would hurt other cases (after you don't need a frequenty accessed part of filesystem cache anymore it would take ages before it gets collected potentially causing an unnecessary swapout storms because the kernel doesn't know you don't need such cache anymore). Furthmore if notes and squid are rarely running but they provides critical services if they would go totally into swap in favour of fs cache you would get very bad latencies the first time somebody connects to the server. So the fix I suggest you is to buy more ram or to shutdown squid and notes. Than Oh well I thought 384MB should be enought for everyone aiming at this performance (almost TM ;). At least it would up till now :( you may as well see a performance improvement compared to 2.2.18pre19 (+raid+ide). Otherwise you can push the machine low on memory a bit until they both goes totally into swap (check with `ps v`). Hope this helps. I'll try this, thanks. (so no echo '1 23 456' /proc/sys/vm/...?) -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Speed of the network card
On Mon, 8 Jan 2001, Chris Wedgwood wrote:
> I would like to determine the banwidth the card is getting from
> the network.
> /proc/net/dev exports counters; you can monitor those -- I'm sure
> there are perfomance program that do exactly this.
I have this little script for monitoring interfaces' speed on 132
wide textmode console w/ niche histogram. It is not perfect but 'it
works for me' (tm).
--> cut here
if [ "$1" = "" ]
then
echo "Please specify the sampling rate."
exit
fi
while true
do
cat /proc/net/ip_fwnames &
sleep $1
done |
awk '
BEGIN {
s=0
d='$1'*1024*1024
wd=d/15
}
/^input / {o=s
s=$7}
/^output / {s+=$7
w=(s-o)/wd
if(w>130)w=0
printf "%fMB/s %0*c\n",(s-o)/d,w,">"}
'
--> cut here
--
SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/
-
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: Speed of the network card
On Mon, 8 Jan 2001, Chris Wedgwood wrote:
I would like to determine the banwidth the card is getting from
the network.
/proc/net/dev exports counters; you can monitor those -- I'm sure
there are perfomance program that do exactly this.
I have this little script for monitoring interfaces' speed on 132
wide textmode console w/ niche histogram. It is not perfect but 'it
works for me' (tm).
-- cut here
if [ "$1" = "" ]
then
echo "Please specify the sampling rate."
exit
fi
while true
do
cat /proc/net/ip_fwnames
sleep $1
done |
awk '
BEGIN {
s=0
d='$1'*1024*1024
wd=d/15
}
/^input / {o=s
s=$7}
/^output / {s+=$7
w=(s-o)/wd
if(w130)w=0
printf "%fMB/s %0*c\n",(s-o)/d,w,""}
'
-- cut here
--
SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/
-
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: Multi-Chanel ATA, was: Re: ATA-4, ATA-5 TCQ status
On Tue, 28 Nov 2000, Uwe Bonnes wrote: > I bought the 2 channel thing for 400 DM (~160$). I guess the 8 chanel You can buy one for under $30 with two channels. So even is the 8 channel one is $200 and not $120 (4x30) I would still prefer this one. > thing is about 1000DM. That's not too much I think. Even single two > chanel PCI adapter is around 100 DM. And as your ideal card propably > isn't produced in big numbers, it will be more expensive per chanel > than the commodity products... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Multi-Chanel ATA, was: Re: ATA-4, ATA-5 TCQ status
On Tue, 28 Nov 2000, Uwe Bonnes wrote: I bought the 2 channel thing for 400 DM (~160$). I guess the 8 chanel You can buy one for under $30 with two channels. So even is the 8 channel one is $200 and not $120 (4x30) I would still prefer this one. thing is about 1000DM. That's not too much I think. Even single two chanel PCI adapter is around 100 DM. And as your ideal card propably isn't produced in big numbers, it will be more expensive per chanel than the commodity products... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Multi-Chanel ATA, was: Re: ATA-4, ATA-5 TCQ status
On Mon, 27 Nov 2000, Uwe Bonnes wrote: > the 3Ware Controllers have up to 8 channels. However I think you can > only use one drive per chanel. Hi! I'm afraid they have only one with intel RISC on board for hardware raid, which amkes these card rather exensive for me wanting multilple channels, nota higher quality of service. It's like I do not want GB Ethernet, I only wanta single card with 4 Fast Ethernet ports. Just for storage: a single ATA-4/5 host adapter PCI card with as many channels as possible... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: ATA-4, ATA-5 TCQ status
On Mon, 27 Nov 2000, Jens Axboe wrote: > On Mon, Nov 27 2000, Sasi Peter wrote: > > > implementation listed in the specs Linux might as well not support it :) > > > It's simply not worth it. > > But seriously, how come? > > I thought they just somewhat like copied the SCSI implementation... > I wish they would have, and based it on atapi. But they didn't... > Basically it requires you to poll for completion of tags with a > service command. On Sun, 26 Nov 2000, Andre Hedrick wrote: > On Mon, 27 Nov 2000, Jens Axboe wrote: > > On Mon, Nov 27 2000, Sasi Peter wrote: > > > I would like to ask if the tagged command queueing capability in the > > > decent ATA standards is utilized in the linux IDE driver (2.2 2.2ide > > ^^ > > > patches, or 2.4 maybe...)? Ok, so anybody knows a multichannel adapter? At least 4 channels? Andre? Where do I get one? Where does the ATA revolution start? -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Multi-Chanel ATA, was: Re: ATA-4, ATA-5 TCQ status
On Mon, 27 Nov 2000, Uwe Bonnes wrote: the 3Ware Controllers have up to 8 channels. However I think you can only use one drive per chanel. Hi! I'm afraid they have only one with intel RISC on board for hardware raid, which amkes these card rather exensive for me wanting multilple channels, nota higher quality of service. It's like I do not want GB Ethernet, I only wanta single card with 4 Fast Ethernet ports. Just for storage: a single ATA-4/5 host adapter PCI card with as many channels as possible... -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: ATA-4, ATA-5 TCQ status
On Mon, 27 Nov 2000, Jens Axboe wrote: > > I would like to ask if the tagged command queueing capability in the > > decent ATA standards is utilized in the linux IDE driver (2.2 2.2ide > ^^ > > patches, or 2.4 maybe...)? > I hope that is supposed to be 'recent', because with the current TCQ If you think I should have... > implementation listed in the specs Linux might as well not support it :) > It's simply not worth it. But seriously, how come? I thought they just somewhat like copied the SCSI implementation... PS: Anybody knowing about a multi (>2) channel UATA host adapter? -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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/
ATA-4, ATA-5 TCQ status
Hi! I would like to ask if the tagged command queueing capability in the decent ATA standards is utilized in the linux IDE driver (2.2 2.2ide patches, or 2.4 maybe...)? Another question, a little bit offtopic is if anybody on this list is able to point me to some pci UltraATA controller card, which has more than 2 channels (more than 4 drives w/o cascade magic) (preferrably 6 or 8 channels)? If the exists one, I do not need no HW RAID or anything like that... I only need a lot of channels, in only one PCI slot. There have been a lot of rant around here, and why I am addressing Andre personally too is that in that debate his stated, that because such cards exist, IDE can fall into line with SCSI in drives possible / PCI slot. Your help is very much appreciated, -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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/
ATA-4, ATA-5 TCQ status
Hi! I would like to ask if the tagged command queueing capability in the decent ATA standards is utilized in the linux IDE driver (2.2 2.2ide patches, or 2.4 maybe...)? Another question, a little bit offtopic is if anybody on this list is able to point me to some pci UltraATA controller card, which has more than 2 channels (more than 4 drives w/o cascade magic) (preferrably 6 or 8 channels)? If the exists one, I do not need no HW RAID or anything like that... I only need a lot of channels, in only one PCI slot. There have been a lot of rant around here, and why I am addressing Andre personally too is that in that debate his stated, that because such cards exist, IDE can fall into line with SCSI in drives possible / PCI slot. Your help is very much appreciated, -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: ATA-4, ATA-5 TCQ status
On Mon, 27 Nov 2000, Jens Axboe wrote: I would like to ask if the tagged command queueing capability in the decent ATA standards is utilized in the linux IDE driver (2.2 2.2ide ^^ patches, or 2.4 maybe...)? I hope that is supposed to be 'recent', because with the current TCQ If you think I should have... implementation listed in the specs Linux might as well not support it :) It's simply not worth it. But seriously, how come? I thought they just somewhat like copied the SCSI implementation... PS: Anybody knowing about a multi (2) channel UATA host adapter? -- SaPE - Peter, Sasi - mailto:[EMAIL PROTECTED] - http://sape.iq.rulez.org/ - 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: Stange NFS messages - 2.2.18pre19
On Wed, 8 Nov 2000, Scott McDermott wrote: > Sasi Peter on Tue 7/11 23:28 +0100: > > I'm getting this under moderate NFS load: > > Nov 6 17:39:56 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) > > Nov 6 17:40:08 iq kernel: svc: unknown program 100227 (me 13) > > Nov 6 19:06:11 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) > > Nov 6 19:38:48 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) > > What do these means? Is this a kernel bug? > Your Suns are using TCP mounts, this got introduced into 2.2.18 > somewhere and is a bit broken, do a patch -R with > ftp://oss.sgi.com/www.projects/nfs3/download/nfs_tcp-2.2.17.dif and > these go away. Suns try TCP mounts first. Be careful to unmount them > first or they will hang waiting for the TCP server to come back up. Broken link: [root@iq patches]# wget ftp://oss.sgi.com/www.projects/nfs3/download/nfs_tcp-2.2.17.dif --08:31:28-- ftp://oss.sgi.com:21/www.projects/nfs3/download/nfs_tcp-2.2.17.dif => `nfs_tcp-2.2.17.dif' Connecting to oss.sgi.com:21... connected! Logging in as anonymous ... Logged in! ==> TYPE I ... done. ==> CWD www.projects/nfs3/download ... No such directory `www.projects/nfs3/download'. -- SaPE Peter, Sasi <[EMAIL PROTECTED]> - 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: Stange NFS messages - 2.2.18pre19
On Wed, 8 Nov 2000, Scott McDermott wrote: Sasi Peter on Tue 7/11 23:28 +0100: I'm getting this under moderate NFS load: Nov 6 17:39:56 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 6 17:40:08 iq kernel: svc: unknown program 100227 (me 13) Nov 6 19:06:11 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 6 19:38:48 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) What do these means? Is this a kernel bug? Your Suns are using TCP mounts, this got introduced into 2.2.18 somewhere and is a bit broken, do a patch -R with ftp://oss.sgi.com/www.projects/nfs3/download/nfs_tcp-2.2.17.dif and these go away. Suns try TCP mounts first. Be careful to unmount them first or they will hang waiting for the TCP server to come back up. Broken link: [root@iq patches]# wget ftp://oss.sgi.com/www.projects/nfs3/download/nfs_tcp-2.2.17.dif --08:31:28-- ftp://oss.sgi.com:21/www.projects/nfs3/download/nfs_tcp-2.2.17.dif = `nfs_tcp-2.2.17.dif' Connecting to oss.sgi.com:21... connected! Logging in as anonymous ... Logged in! == TYPE I ... done. == CWD www.projects/nfs3/download ... No such directory `www.projects/nfs3/download'. -- SaPE Peter, Sasi [EMAIL PROTECTED] - 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/
Stange NFS messages - 2.2.18pre19
Hi! I'm getting this under moderate NFS load: Nov 6 17:39:56 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 6 17:40:08 iq kernel: svc: unknown program 100227 (me 13) Nov 6 19:06:11 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 6 19:38:48 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 6 19:54:51 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 6 20:08:53 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 6 20:53:23 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 09:03:28 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 09:15:18 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 11:12:51 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 18:01:17 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 19:34:59 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 19:40:59 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 21:43:48 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) What do these means? Is this a kernel bug? -- SaPE Peter, Sasi <[EMAIL PROTECTED]> - 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/
Stange NFS messages - 2.2.18pre19
Hi! I'm getting this under moderate NFS load: Nov 6 17:39:56 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 6 17:40:08 iq kernel: svc: unknown program 100227 (me 13) Nov 6 19:06:11 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 6 19:38:48 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 6 19:54:51 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 6 20:08:53 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 6 20:53:23 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 09:03:28 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 09:15:18 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 11:12:51 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 18:01:17 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 19:34:59 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 19:40:59 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) Nov 7 21:43:48 iq kernel: svc: server socket destroy delayed (sk_inuse: 1) What do these means? Is this a kernel bug? -- SaPE Peter, Sasi [EMAIL PROTECTED] - 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/
[SUCCESS] Re: 2.2.18pre19
Short answer UHCI JE does work for me, no more strange errors... The weird thig is that I have used 2.2 USB backports since the begining, but I have always used the other UHCI, and up till now it used to work for me, except for now, but now it seems to be ok w/ the JE variant. Thanks for the help. by, SaPE On Thu, 2 Nov 2000, Greg KH wrote: > On Fri, Nov 03, 2000 at 02:08:53AM +0100, Sasi Peter wrote: > > On Thu, 2 Nov 2000, Greg KH wrote: > > > > > Could you send the result of /proc/interrupts and 'lspci -v'? > > > Also, have you tried the alternate UHCI controller driver? > > > Or tried USB as modules, instead of compiled in? > > > > Here you go. I did work w/ the very same hw with pre15. > > Looks like USB and your sound card is on the same interrupt. Is there > any BIOS settings you can make to move these around? > > > I have never really knew what the UHCI JE was all about... So it can be > > used in place of the original UHCI? I will make a try. (and why JE?) > > Long story, short answer: 2 different developers working on support for > the same device. Both drivers work better for some people on different > devices. JE is the author's initials (Johannes Erdfelt). > > Personally for some devices I have I like one version, for others, I > like the other one. Now if Johannes would ever fix the QUEUE_BULK bug, > I would be back to using only one driver :) > > Let me know if moving the IRQs helps out. > > greg k-h > > > -- > greg@(kroah|wirex).com > http://immunix.org/~greg > On Thu, 2 Nov 2000, Johannes Erdfelt wrote: > On Fri, Nov 03, 2000, Sasi Peter <[EMAIL PROTECTED]> wrote: > > On Thu, 2 Nov 2000, Greg KH wrote: > > > > > Could you send the result of /proc/interrupts and 'lspci -v'? > > > Also, have you tried the alternate UHCI controller driver? > > > Or tried USB as modules, instead of compiled in? > > > > Here you go. I did work w/ the very same hw with pre15. > > > > I have never really knew what the UHCI JE was all about... So it can be > > used in place of the original UHCI? I will make a try. (and why JE?) > > Yes, it's a drop in replacement. Choose one or the other. > > "JE" because it's my initials. > > JE > -- SaPE Peter, Sasi <[EMAIL PROTECTED]> - 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.2.18pre19
On Thu, 2 Nov 2000, Greg KH wrote: > Could you send the result of /proc/interrupts and 'lspci -v'? > Also, have you tried the alternate UHCI controller driver? > Or tried USB as modules, instead of compiled in? Here you go. I did work w/ the very same hw with pre15. I have never really knew what the UHCI JE was all about... So it can be used in place of the original UHCI? I will make a try. (and why JE?) -- SaPE Peter, Sasi <[EMAIL PROTECTED]> 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 02) Flags: bus master, medium devsel, latency 32 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 1.0 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 64 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d8ff 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) Flags: bus master, medium devsel, latency 0 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) (prog-if 80 [Master]) Flags: bus master, medium devsel, latency 32 I/O ports at f000 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) (prog-if 00 [UHCI]) Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at d000 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) Flags: medium devsel 00:0b.0 RAID bus controller: CMD Technology Inc PCI0648 (rev 01) Subsystem: Unknown device 78c6:f774 Flags: bus master, medium devsel, latency 64, IRQ 12 I/O ports at d400 I/O ports at d800 I/O ports at dc00 I/O ports at e000 I/O ports at e400 Capabilities: [60] Power Management version 1 00:0f.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 20) Subsystem: Digital Equipment Corporation: Unknown device 500a Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at e800 Memory at da00 (32-bit, non-prefetchable) 00:11.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] Subsystem: Unknown device 4942:4c4c Flags: bus master, slow devsel, latency 32, IRQ 11 I/O ports at ec00 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 03) (prog-if 00 [VGA]) Subsystem: Matrox Graphics, Inc. Millennium G200 AGP Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at d800 (32-bit, prefetchable) Memory at d400 (32-bit, non-prefetchable) Memory at d500 (32-bit, non-prefetchable) Capabilities: [dc] Power Management version 1 Capabilities: [f0] AGP version 1.0 CPU0 0:8031621 XT-PIC timer 1: 89153 XT-PIC keyboard 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 10: 43325833 XT-PIC eth0 11: 11003411 XT-PIC usb-uhci, es1370 12:1346533 XT-PIC ide2, ide3 13: 1 XT-PIC fpu 14: 238935 XT-PIC ide0 15: 513841 XT-PIC ide1 NMI: 0
Re: 2.2.18pre19
On Thu, 2 Nov 2000, Sasi Peter wrote: > Seems like something in USB went wrong from pre15, I get something like > what is in the attachment. In now. > I have tried using HID + mouse, HID BP, disabling event interface, > disabling hot-plug support, disabling preliminary USB fs, disabling > bandwidth allocation, the effect are still the same even is leaving there > only the basic stuff: > > # > # USB support > # > CONFIG_USB=y > CONFIG_USB_DEBUG=y > # CONFIG_USB_DEVICEFS is not set > # CONFIG_HOTPLUG is not set > # CONFIG_USB_BANDWIDTH is not set > CONFIG_USB_UHCI=y > # CONFIG_USB_OHCI is not set > # CONFIG_USB_PRINTER is not set > # CONFIG_USB_SCANNER is not set > # CONFIG_USB_AUDIO is not set > # CONFIG_USB_ACM is not set > # CONFIG_USB_SERIAL is not set > # CONFIG_USB_IBMCAM is not set > # CONFIG_USB_OV511 is not set > # CONFIG_USB_DC2XX is not set > # CONFIG_USB_MDC800 is not set > # CONFIG_USB_STORAGE is not set > # CONFIG_USB_DABUSB is not set > # CONFIG_USB_PLUSB is not set > # CONFIG_USB_PEGASUS is not set > # CONFIG_USB_RIO500 is not set > # CONFIG_USB_DSBR is not set > # CONFIG_USB_BLUETOOTH is not set > # CONFIG_USB_KAWETH is not set > # CONFIG_USB_HID is not set > # CONFIG_USB_KBD is not set > CONFIG_USB_MOUSE=y > # CONFIG_USB_WACOM is not set > # CONFIG_USB_WMFORCE is not set > # CONFIG_INPUT_KEYBDEV is not set > CONFIG_INPUT_MOUSEDEV=y > CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280 > CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024 > # CONFIG_INPUT_JOYDEV is not set > # CONFIG_INPUT_EVDEV is not set > > Any more info, I could send? > > Fixing this would be very much appreciated, because this would be my first > 2.2 kernel with all ide, raid, usb and nfs patches working properly at the > same time. Maybe even VM beheaves now... ;) (I used to have the > do_try_to_free_page for XXX hang even w/ pre15). -- SaPE Peter, Sasi <[EMAIL PROTECTED]> Nov 2 04:04:14 iq kernel: Manufacturer: Logitech Nov 2 04:04:14 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:14 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:14 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:15 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:15 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:15 iq kernel: Manufacturer: Logitech Nov 2 04:04:15 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:15 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:15 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:15 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:15 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:15 iq kernel: Manufacturer: Logitech Nov 2 04:04:15 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:15 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:15 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:16 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:16 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:16 iq kernel: Manufacturer: Logitech Nov 2 04:04:16 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:16 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:16 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:16 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:16 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:16 iq kernel: Manufacturer: Logitech Nov 2 04:04:16 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:16 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:16 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:17 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:17 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:17 iq kernel: Manufacturer: Logitech Nov 2 04:04:17 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:17 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:17 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:18 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:18 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:18 iq kernel: Manufacturer: Logitech Nov 2 04:04:18 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:18 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:18 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:18 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:18 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:18 iq kernel: Manufacturer: Logitech Nov 2 04:04:18 iq kernel: Product: USB-PS/2 Mouse M-BA47 No
2.2.18pre19
Hi! Seems like something in USB went wrong from pre15, I get something like what is in the attachment. I have tried using HID + mouse, HID BP, disabling event interface, disabling hot-plug support, disabling preliminary USB fs, disabling bandwidth allocation, the effect are still the same even is leaving there only the basic stuff: # # USB support # CONFIG_USB=y CONFIG_USB_DEBUG=y # CONFIG_USB_DEVICEFS is not set # CONFIG_HOTPLUG is not set # CONFIG_USB_BANDWIDTH is not set CONFIG_USB_UHCI=y # CONFIG_USB_OHCI is not set # CONFIG_USB_PRINTER is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_AUDIO is not set # CONFIG_USB_ACM is not set # CONFIG_USB_SERIAL is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_DC2XX is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_DABUSB is not set # CONFIG_USB_PLUSB is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_HID is not set # CONFIG_USB_KBD is not set CONFIG_USB_MOUSE=y # CONFIG_USB_WACOM is not set # CONFIG_USB_WMFORCE is not set # CONFIG_INPUT_KEYBDEV is not set CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set Any more info, I could send? Fixing this would be very much appreciated, because this would be my first 2.2 kernel with all ide, raid, usb and nfs patches working properly at the same time. Maybe even VM beheaves now... ;) (I used to have the do_try_to_free_page for XXX hang even w/ pre15). -- SaPE Peter, Sasi <[EMAIL PROTECTED]> - 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.2.18pre19
On Thu, 2 Nov 2000, Sasi Peter wrote: Seems like something in USB went wrong from pre15, I get something like what is in the attachment. In now. I have tried using HID + mouse, HID BP, disabling event interface, disabling hot-plug support, disabling preliminary USB fs, disabling bandwidth allocation, the effect are still the same even is leaving there only the basic stuff: # # USB support # CONFIG_USB=y CONFIG_USB_DEBUG=y # CONFIG_USB_DEVICEFS is not set # CONFIG_HOTPLUG is not set # CONFIG_USB_BANDWIDTH is not set CONFIG_USB_UHCI=y # CONFIG_USB_OHCI is not set # CONFIG_USB_PRINTER is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_AUDIO is not set # CONFIG_USB_ACM is not set # CONFIG_USB_SERIAL is not set # CONFIG_USB_IBMCAM is not set # CONFIG_USB_OV511 is not set # CONFIG_USB_DC2XX is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_STORAGE is not set # CONFIG_USB_DABUSB is not set # CONFIG_USB_PLUSB is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_DSBR is not set # CONFIG_USB_BLUETOOTH is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_HID is not set # CONFIG_USB_KBD is not set CONFIG_USB_MOUSE=y # CONFIG_USB_WACOM is not set # CONFIG_USB_WMFORCE is not set # CONFIG_INPUT_KEYBDEV is not set CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set Any more info, I could send? Fixing this would be very much appreciated, because this would be my first 2.2 kernel with all ide, raid, usb and nfs patches working properly at the same time. Maybe even VM beheaves now... ;) (I used to have the do_try_to_free_page for XXX hang even w/ pre15). -- SaPE Peter, Sasi [EMAIL PROTECTED] Nov 2 04:04:14 iq kernel: Manufacturer: Logitech Nov 2 04:04:14 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:14 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:14 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:15 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:15 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:15 iq kernel: Manufacturer: Logitech Nov 2 04:04:15 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:15 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:15 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:15 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:15 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:15 iq kernel: Manufacturer: Logitech Nov 2 04:04:15 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:15 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:15 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:16 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:16 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:16 iq kernel: Manufacturer: Logitech Nov 2 04:04:16 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:16 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:16 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:16 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:16 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:16 iq kernel: Manufacturer: Logitech Nov 2 04:04:16 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:16 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:16 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:17 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:17 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:17 iq kernel: Manufacturer: Logitech Nov 2 04:04:17 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:17 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:17 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:18 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:18 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:18 iq kernel: Manufacturer: Logitech Nov 2 04:04:18 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:18 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:18 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:18 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:18 iq kernel: usb.c: USB new device connect, assigned device number 2 Nov 2 04:04:18 iq kernel: Manufacturer: Logitech Nov 2 04:04:18 iq kernel: Product: USB-PS/2 Mouse M-BA47 Nov 2 04:04:18 iq kernel: mouse0: PS/2 mouse device for input0 Nov 2 04:04:18 iq kernel: input0: Logitech USB-PS/2 Mouse M-BA47 on usb1:2.0 Nov 2 04:04:18 iq kernel: usb.c: USB disconnect on device 2 Nov 2 04:04:19
[SUCCESS] Re: 2.2.18pre19
Short answer UHCI JE does work for me, no more strange errors... The weird thig is that I have used 2.2 USB backports since the begining, but I have always used the other UHCI, and up till now it used to work for me, except for now, but now it seems to be ok w/ the JE variant. Thanks for the help. by, SaPE On Thu, 2 Nov 2000, Greg KH wrote: On Fri, Nov 03, 2000 at 02:08:53AM +0100, Sasi Peter wrote: On Thu, 2 Nov 2000, Greg KH wrote: Could you send the result of /proc/interrupts and 'lspci -v'? Also, have you tried the alternate UHCI controller driver? Or tried USB as modules, instead of compiled in? Here you go. I did work w/ the very same hw with pre15. Looks like USB and your sound card is on the same interrupt. Is there any BIOS settings you can make to move these around? I have never really knew what the UHCI JE was all about... So it can be used in place of the original UHCI? I will make a try. (and why JE?) Long story, short answer: 2 different developers working on support for the same device. Both drivers work better for some people on different devices. JE is the author's initials (Johannes Erdfelt). Personally for some devices I have I like one version, for others, I like the other one. Now if Johannes would ever fix the QUEUE_BULK bug, I would be back to using only one driver :) Let me know if moving the IRQs helps out. greg k-h -- greg@(kroah|wirex).com http://immunix.org/~greg On Thu, 2 Nov 2000, Johannes Erdfelt wrote: On Fri, Nov 03, 2000, Sasi Peter [EMAIL PROTECTED] wrote: On Thu, 2 Nov 2000, Greg KH wrote: Could you send the result of /proc/interrupts and 'lspci -v'? Also, have you tried the alternate UHCI controller driver? Or tried USB as modules, instead of compiled in? Here you go. I did work w/ the very same hw with pre15. I have never really knew what the UHCI JE was all about... So it can be used in place of the original UHCI? I will make a try. (and why JE?) Yes, it's a drop in replacement. Choose one or the other. "JE" because it's my initials. JE -- SaPE Peter, Sasi [EMAIL PROTECTED] - 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.2.18pre15 and do_try_to_free_page for ... w/ Andrea's patch
Hi! Unfortunatelly I couldn't apply it: [root@iq src]# bzcat VM-global-2.2.18pre9-6.bz2 |patch -p0 patching file `VM/drivers/block/rd.c' patching file `VM/fs/binfmt_aout.c' patching file `VM/fs/binfmt_elf.c' patching file `VM/fs/buffer.c' patching file `VM/fs/coda/file.c' patching file `VM/fs/dcache.c' patching file `VM/fs/open.c' patching file `VM/fs/read_write.c' patching file `VM/include/linux/fs.h' Hunk #1 FAILED at 185. Hunk #2 FAILED at 771. Hunk #3 succeeded at 782 (offset 2 lines). Hunk #4 succeeded at 980 (offset 41 lines). 2 out of 4 hunks FAILED -- saving rejects to VM/include/linux/fs.h.rej patching file `VM/include/linux/locks.h' patching file `VM/include/linux/sched.h' patching file `VM/init/main.c' Hunk #1 succeeded at 77 (offset 1 line). Hunk #2 succeeded at 1582 (offset 17 lines). patching file `VM/ipc/shm.c' patching file `VM/kernel/fork.c' patching file `VM/mm/filemap.c' patching file `VM/mm/page_alloc.c' patching file `VM/mm/swap_state.c' patching file `VM/mm/vmscan.c' I will look into the .rej to try to fix it... -- SaPE Peter, Sasi <[EMAIL PROTECTED]> - 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: VM: do_try_to_free_memory failed for XXXX, 2.2.17, 2.2.18pre3
On Thu, 12 Oct 2000, Krzysztof Sierota wrote: > Our 3 machines went unresponsive, just the way you describe it. The error > was the same. We had this on 2.2.17 and on 2.2.18pre3 , didn't try 2.2.18pre15. > Marcelo Tosati assembled a kernel for us that had Andrea Arcangeli patches > applied and some other stuff that we needed, and the machines are stable > since then. All our machines run under very _heavy_ disk IO operations. > Loads between 15-30 most of the time. If this is true, I am very much interested in the resultant patch (to vanilla 2.2.17 or 2.2.18pre15) since I have the same load, and the same errors. Could you please send it? On 12 Oct 2000, Per Andreas Buer wrote: > Krzysztof Sierota <[EMAIL PROTECTED]> writes: > > I recently changed the kernel from 2.2.15 to 2.2.17 and added new promise 100 > > card. During 3 days 2 production servers crashed 4 times and had several > > lockups when there was zillion messages like > > VM: do_try_to_free_memmory failed for XXX > Are you using gcc 2.95? We had a lot of trouble (fatal vm-errors) with > gcc 2.95 until we started building kernels with egcs-2.91. Unfortunatelly this is not to blame gcc for: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) -- SaPE Peter, Sasi <[EMAIL PROTECTED]> - 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.18pre15
On Wed, 11 Oct 2000, Alan Cox wrote: The was an error reported for 2.2.17: Oct 12 14:55:46 iq kernel: VM: do_try_to_free_pages failed for kupdate... ... Oct 12 00:50:49 iq kernel: VM: do_try_to_free_pages failed for smbd... Oct 12 00:50:51 iq last message repeated 226 times ... Oct 12 00:50:47 iq kernel: VM: do_try_to_free_pages failed for smbd... Oct 12 00:50:48 iq last message repeated 120 times ... It's the same for me w/ 2.2.18pre15. The box is a 256MB RAM 400Mhz Celeron doing fileserving w/ ~40 active connections, 5MBytes/s sustained traffic on eth0, having 4 UDMA used IDE disks w/ sw RAID. Some other fonctions are also there (Lotus Notes 5.0, squid), might this be a problem w/ too many processes and fs load, or what? -- SaPE Peter, Sasi <[EMAIL PROTECTED]> - 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.18pre15
On Wed, 11 Oct 2000, Alan Cox wrote: The was an error reported for 2.2.17: Oct 12 14:55:46 iq kernel: VM: do_try_to_free_pages failed for kupdate... ... Oct 12 00:50:49 iq kernel: VM: do_try_to_free_pages failed for smbd... Oct 12 00:50:51 iq last message repeated 226 times ... Oct 12 00:50:47 iq kernel: VM: do_try_to_free_pages failed for smbd... Oct 12 00:50:48 iq last message repeated 120 times ... It's the same for me w/ 2.2.18pre15. The box is a 256MB RAM 400Mhz Celeron doing fileserving w/ ~40 active connections, 5MBytes/s sustained traffic on eth0, having 4 UDMA used IDE disks w/ sw RAID. Some other fonctions are also there (Lotus Notes 5.0, squid), might this be a problem w/ too many processes and fs load, or what? -- SaPE Peter, Sasi [EMAIL PROTECTED] - 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: VM: do_try_to_free_memory failed for XXXX, 2.2.17, 2.2.18pre3
On Thu, 12 Oct 2000, Krzysztof Sierota wrote: Our 3 machines went unresponsive, just the way you describe it. The error was the same. We had this on 2.2.17 and on 2.2.18pre3 , didn't try 2.2.18pre15. Marcelo Tosati assembled a kernel for us that had Andrea Arcangeli patches applied and some other stuff that we needed, and the machines are stable since then. All our machines run under very _heavy_ disk IO operations. Loads between 15-30 most of the time. If this is true, I am very much interested in the resultant patch (to vanilla 2.2.17 or 2.2.18pre15) since I have the same load, and the same errors. Could you please send it? On 12 Oct 2000, Per Andreas Buer wrote: Krzysztof Sierota [EMAIL PROTECTED] writes: I recently changed the kernel from 2.2.15 to 2.2.17 and added new promise 100 card. During 3 days 2 production servers crashed 4 times and had several lockups when there was zillion messages like VM: do_try_to_free_memmory failed for XXX Are you using gcc 2.95? We had a lot of trouble (fatal vm-errors) with gcc 2.95 until we started building kernels with egcs-2.91. Unfortunatelly this is not to blame gcc for: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) -- SaPE Peter, Sasi [EMAIL PROTECTED] - 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.2.18pre15 and do_try_to_free_page for ... w/ Andrea's patch
Hi! Unfortunatelly I couldn't apply it: [root@iq src]# bzcat VM-global-2.2.18pre9-6.bz2 |patch -p0 patching file `VM/drivers/block/rd.c' patching file `VM/fs/binfmt_aout.c' patching file `VM/fs/binfmt_elf.c' patching file `VM/fs/buffer.c' patching file `VM/fs/coda/file.c' patching file `VM/fs/dcache.c' patching file `VM/fs/open.c' patching file `VM/fs/read_write.c' patching file `VM/include/linux/fs.h' Hunk #1 FAILED at 185. Hunk #2 FAILED at 771. Hunk #3 succeeded at 782 (offset 2 lines). Hunk #4 succeeded at 980 (offset 41 lines). 2 out of 4 hunks FAILED -- saving rejects to VM/include/linux/fs.h.rej patching file `VM/include/linux/locks.h' patching file `VM/include/linux/sched.h' patching file `VM/init/main.c' Hunk #1 succeeded at 77 (offset 1 line). Hunk #2 succeeded at 1582 (offset 17 lines). patching file `VM/ipc/shm.c' patching file `VM/kernel/fork.c' patching file `VM/mm/filemap.c' patching file `VM/mm/page_alloc.c' patching file `VM/mm/swap_state.c' patching file `VM/mm/vmscan.c' I will look into the .rej to try to fix it... -- SaPE Peter, Sasi [EMAIL PROTECTED] - 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.2.18pre* + raid +ide patches ??
On Mon, 9 Oct 2000, Darron Froese wrote: > Patch the 2.2.17 kernel with ide and raid and then apply 18pre patches to > that. > If you get rejected pieces you may have to hand merge some but that's how > I've done it in the past. At least Ingo has made a raid patch for 2.2.18pre13, which patches for pre15 also, w/ 1 reject (makefile - EXTRAVERSION = pre13 + ... pre13-RAID). Patch is named: raid-2.2.18-A1 Actually I also use the ide patch w/ this kernel, the latest from bkz: http://www.republika.pl/bkz/ide.2.2.17pre15.all.2722.patch.bz2 This one patches w/ ~6 rejects, I run through them, the changes do not affect my setup (1 in the arm-asm subtree, two ALi chipset, one rz1000 etc.) The right order to patch: 2.2.17 + ide + pre-patch + raid (I also use USB, but finally it's merged ;) The really important question is if pre-patch-2.2.18-15.bz2 contains any pieces to stop 'VM: try_to_free_memory_failed for XXX messages' coming, and temporarily freezing the box? (whilst they are coming, nothing else works) -- SaPE Peter, Sasi <[EMAIL PROTECTED]> - 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.2.18pre* + raid +ide patches ??
On Mon, 9 Oct 2000, Darron Froese wrote: Patch the 2.2.17 kernel with ide and raid and then apply 18pre patches to that. If you get rejected pieces you may have to hand merge some but that's how I've done it in the past. At least Ingo has made a raid patch for 2.2.18pre13, which patches for pre15 also, w/ 1 reject (makefile - EXTRAVERSION = pre13 + ... pre13-RAID). Patch is named: raid-2.2.18-A1 Actually I also use the ide patch w/ this kernel, the latest from bkz: http://www.republika.pl/bkz/ide.2.2.17pre15.all.2722.patch.bz2 This one patches w/ ~6 rejects, I run through them, the changes do not affect my setup (1 in the arm-asm subtree, two ALi chipset, one rz1000 etc.) The right order to patch: 2.2.17 + ide + pre-patch + raid (I also use USB, but finally it's merged ;) The really important question is if pre-patch-2.2.18-15.bz2 contains any pieces to stop 'VM: try_to_free_memory_failed for XXX messages' coming, and temporarily freezing the box? (whilst they are coming, nothing else works) -- SaPE Peter, Sasi [EMAIL PROTECTED] - 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/
