login
Search
Con Kolivas has released a new high-performance patchset [story] for the 2.4.19 stable kernel. This new patchset, -ck9, adds ALSA, XFS [story] and compressed caching. Unfortunately, the compressed caching patch is not compatible with symmetric multiprocessing systems, nor is it compatible with the latest -aa or -rmap VM. Fortunately an average uniprocessor system that does occasionally swap should still notice quite an improvement going from -ck7 to -ck9, as noted in a followup email Con posted with a comparison using his contest benchmarking tool [story]. Full details follow.
From: Con Kolivas To: linux-kernel mailing list Subject: performance patchset (-ck) update for 2.4.19 Date: Mon, 14 Oct 2002 20:07:25 +1000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've updated the patchset I've put together. - -ck9 contains: O(1) Scheduler (with batch scheduling) Preemptible Low Latency Compressed Caching XFS Supermount ALSA The choice of patches to add was based on requests and feedback. The -aa and - -rmap vms are not compatible with this release; but the performance of -ck9 outperforms both of them. XFS compiles without problems but is untested. Get it here: http://kernel.kolivas.net Cheers, enjoy! Con. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9qpdfF6dfvkL3i1gRAjEhAJ4mvihaYL619QvM/RW6ljuS4f7OMQCghfQd PvrBdFoRJI7FFu9l9Lbe6To= =bRzj -----END PGP SIGNATURE-----
From: Con Kolivas Subject: ck9/7 v 2.4.19 performance with contest Date: Mon, 14 Oct 2002 23:29:57 +1000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've run some benchmarks with contest (http://contest.kolivas.net) and my latest patchset (http://kernel.kolivas.net/) for public consumption. These are to explain why I've included compressed caching and removed the added vm work. CAVEAT: ck9 will only be advantageous over ck7 on uniprocessor machines with a normal or small amount of memory. If you have heaps of memory and almost never get into swap then the compressed caching will offer you no advantage. Worse yet, SMP machines no longer benefit from the added vm changes in ck7 - these were not compatible with compressed caching. noload: Kernel [runs] Time CPU% Loads LCPU% Ratio 2.4.19 [3] 67.7 98 0 0 1.01 2.4.19-ck7 [3] 73.8 96 0 0 1.10 2.4.19-ck9 [2] 68.8 97 0 0 1.02 You can see a slight difference here. ck7 and the 2.5 kernels show this unusual feature of taking longer to get started on a noload kernel compile after the memory and swap is all flushed. ck9 seems to have tamed this problem. process_load: Kernel [runs] Time CPU% Loads LCPU% Ratio 2.4.19 [3] 106.5 59 112 43 1.59 2.4.19-ck7 [3] 93.4 76 68 27 1.39 2.4.19-ck9 [2] 94.3 70 83 32 1.40 Minimal difference from ck7 in time taken, but during that time the background process has accomplished more work. ctar_load: Kernel [runs] Time CPU% Loads LCPU% Ratio 2.4.19 [2] 106.5 70 1 8 1.59 2.4.19-ck7 [3] 142.3 57 2 10 2.12 2.4.19-ck9 [2] 110.5 71 1 9 1.65 ck7 exhibited quite aggressive work in the background load at the expense of the foreground process in tar creation. ck9 tames this a lot. xtar_load: Kernel [runs] Time CPU% Loads LCPU% Ratio 2.4.19 [1] 132.4 55 2 9 1.97 2.4.19-ck7 [3] 238.3 33 5 11 3.55 2.4.19-ck9 [2] 138.6 58 2 11 2.06 Even more background work done by ck7 here; tamed by ck9. io_load: Kernel [runs] Time CPU% Loads LCPU% Ratio 2.4.19 [3] 492.6 14 38 10 7.33 2.4.19-ck7 [2] 174.6 41 8 8 2.60 2.4.19-ck9 [2] 140.6 49 5 5 2.09 Now under heavy file writing ck9 has relaxed even more than ck7 has. read_load: Kernel [runs] Time CPU% Loads LCPU% Ratio 2.4.19 [2] 134.1 54 14 5 2.00 2.4.19-ck7 [2] 119.4 66 12 5 1.78 2.4.19-ck9 [2] 77.4 85 11 9 1.15 This overstates the advantage of ck9 over ck7 because the file read would be easy to compress. Nonetheless it is faster. list_load: Kernel [runs] Time CPU% Loads LCPU% Ratio 2.4.19 [1] 89.8 77 1 20 1.34 2.4.19-ck7 [2] 104.0 70 1 21 1.55 2.4.19-ck9 [2] 85.2 79 1 22 1.27 Not sure why ck7 was slower than vanilla here, but ck9 improves on it. The resolution of loads performed cannot show less than 1 to show if ck7 or ck9 did more work. mem_load: Kernel [runs] Time CPU% Loads LCPU% Ratio 2.4.19 [3] 100.0 72 33 3 1.49 2.4.19-cc [3] 92.7 76 146 21 1.38 2.4.19-ck7 [2] 116.0 69 35 3 1.73 2.4.19-ck9 [2] 78.3 88 31 8 1.17 This is the most interesting. I've included 2.4.19 with just cc added to show the difference. With cc heaps more work is done by the background load and only a modest improvement occurs in the kernel compilation time. ck9 on the other hand does about the same amount of background work as vanilla, but is significantly faster on kernel compilation time - a preferable balance I believe. Once again the advantage is overstated because the data would compress well but is present. Cheers, Con -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9qsbVF6dfvkL3i1gRAuZ6AJwMDozAY7Bvujh8csCStlC5mWFUHwCfdSg0 2MNWYIRedppbyWh7P18uJN8= =qWgv -----END PGP SIGNATURE-----
Defining normal
What's considered the "normal" amount of ram - I guessing 256MB or something like that.
Con posted this previously
Con posted his machine specs previously in the article on shared pagetables. I assume he's using this machine for his testing. From his comments, it seems to be the machine he considers a "normal desktop":
The machine used for the testing is static. As the aim of contest originally was to not forget desktop performance the machine chosen is about average for a recent machine - single cpu, 1133Mhz P3 with 256Mb Ram, 5400 rpm ATA100 drive.
I wonder where my machine fits on that curve. I have a Pentium II 300MHz and 128MB RAM (split 64MB EDO, 64MB Fast-page-mode DRAM). I have two 40GB ATA-100 drives, and two 4GB SCSI-II drives... I'm going to guess significantly behind it, with one toe on it. ;-)
Recent
He didn't say the normal desktop, rather average recent machine. This is more like low-end recent machine. Anyway his tests are really about VM performance and the amount of RAM is the most important variable here.
RAM
For what most desktop machines are used for, and the current level of memory suckage that occurs with linux desktops, anything with less than 512Mb ram will benefit. The lower the ram, the greater the benefit. Even with any amount of ram, the more you get into swap, the more you'll benefit from cc.
Re: Defining normal
After reading ''with small amount of ram'' i thought about my little machine - Am5k86-pr75 with 32 MiBs of ram. But computation overhead would probably nivelate speedup in swapping (less to swap => faster swapping).
--
BLUG member no. 30
Try it
Actually as your machine gets slower, the swap performance also gets slower, so the benefits of compressed caching are still there. Compressing and decompressing pages with a fast algorithm will still be faster than disk access even on a pr75. Reading a page from disk is 100000 times slower than from ram, so compressing/decompressing it from ram takes less time even with low cpu speeds.
Probably not worth it, but who knows.
Chances are, unless you have a really slow drive, the compressed caching will be at best a wash, even with only 32MB of RAM. I guess it all really depends on what you're doing.
I have an AMD 5x86-133 (I believe about the same CPU -- it was equivalent speedwise to a Pentium 75) and a Pentium 60. On both of those machines, compression/decompression isn't the speediest thing in the world. You'll generate a lot of system load that you can't hide.
Another drawback (and I'm not sure how much it will affect you) is that compressed caching does require RAM to store the compressed pages before they go to disk. If I understand their design correctly, pages identified as swap candidates are compressed, and then eventually pushed to disk if there is no room in the compressed swap cache. (Interestingly, the pages are decompressed prior to writing to disk, by default.) The compressed swap cache lives in main memory, and is non-zero in size. In fact, in the current design, it is a fixed size chosen at boot time.
So, basically, if your total real RAM is too small, you won't be able to allocate a compressed cache that's large enough to be worthwhile. At 32MB you may be large enough, but your CPU will be a bottleneck. At 8MB, I'd guess it's definitely not worth it unless you're truly swapless.
Swap writing
The latest version allows pages to be written to swap compressed or decompressed. A little algorithm detects the cpu usage at the time and decides whether to do one or the other. I guess the only thing to do is try it. The compressed swap cache size is now liquid. It starts at zero and only starts being recruited when swap is called on.
Ah, ok. It sounds like the c
Ah, ok. It sounds like the current 'state of the universe' is a bit improved over the design document on the website. I'm guessing that document reflects an older version of the compressed cache patch?
Outdated info
Yeah I guess the "Current Design (outdated)" heading on the linuxcompressed website should have given that away.
d'oh!
Didn't notice that. Heh. I guess that's what happens when my eyes go straight for the links. I tend to not notice headings. (Could just be a case of "banner blindness.")
I got confused the first time I went to the LXR page, since the big, blue "Browse the Code" link at the top didn't catch my attention. I was looking for a more normal-style link in the body of the page to take me to the cross-reference. I couldn't find any.
Does anyone know
if the compressed swap cache patch will be included in the official kernels ?
Thanks.
cc in kernels
No. The author of cc has not even tried to submit it, let alone it be approved. It is too big a change to go into stable kernels (2.4) and has not made it into the 2.5 development. Unless he submits it in the next two weeks which I doubt since he has no 2.5 version, then it wont even make it into 2.6. Perhaps by 2.7 to go into 2.8. Shame really, but he wants it to be perfect before submitting it.
well
Well,
Maybe I'll still try it on my dual p3 800 mhz system with 1 gig of ram... Might make a little difference... Heh.
SMP why bother
No point. You cant enable compressed caching with SMP. Just use ck7 instead, it will still make a difference even to your machine.
Wow
Well, I just compiled this kernel..and my 128mb vaio became much more responsive when using mozilla & konq..instead of being 10-20mb into swap its only 1mb right now. The slow seeks on the hd make any sort of swapping painful on this.
Very very nice.
Thanks for mentioning this patchset
can't compile it
my compilation dies with:
kdbmain.c: In function `kdb_ps`
kdbmain.c:2415: warning: implicit declaration of function `task_has_cpu'
kdbmain.c:2415: structure has no member named `processor`
make[2]: *** [kdbmain.o] Error 1
make[2]: Leaving directory `/usr/src/linux/kdb`
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux/kdb`
make: *** [_dir_kdb] Error 2
I have Debian 3.0 (Woody). Anyone has some sugestions what should I do to buil it without errors. This -ck patches are amazing, I was using it previously, I I'd like to use also this patch.
Somebody could help me ?
kdb support
The kdb support comes with the XFS patch, but is not required for XFS to work. I didn't test this to see if it works, and unless you need it you should just disable it. If you were using -ck patches before, then you weren't using it and dont need it.
kdb fix
Thanks to MCP I have a patch posted on my website that should fix this.
benchmarks - ck7 vs ck9 - LONG but interesting
I noticed actually MORE swapping with ck9 than with ck7 in my tests. Maybe has to do with no AA or RMAP being included.
I used bonnie and postmark. Not the most ideal benchmarks but for what I need, they are good indicators of performance.
ck7 and ck9 without CC perform pretty close to the vanilla RedHat 8 kernel in those benchmarks (usually very slightly faster).
XFS seems to work fine so far in ck9.
I realize Bonnie was running almost entirely in memory but that was my intention...
Informal tests were run, consisting of kernel compilation while trying to use Openoffice and several other programs (the same procedure in this case). Ck9 with CC seemed not to offer good interactive response in this case.
In summary, I think interactive performance may suffer somewhat from compressed caching and swap, at least on slower machines.
Machine: 400MHz PII, 128MB RAM, RedHat 8 + 2.4.19-ck9, 3xSCSI AMI Megaraid RAID0, 4MB cache, writeback, 16K stripe
all tests done in the same partition.
ck7 rmap, no XFS:
ReiserFS noatime, notail
Bonnie
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 5198 99.3 10170 25.4 4251 7.0 3878 66.4 18572 13.8 307.0 5.8
Postmark
Time:
103 seconds total
23 seconds of transactions (43 per second)
Files:
10515 created (102 per second)
Creation alone: 10000 files (129 per second)
Mixed with transactions: 515 files (22 per second)
479 read (20 per second)
521 appended (22 per second)
10515 deleted (102 per second)
Deletion alone: 10030 files (3343 per second)
Mixed with transactions: 485 files (21 per second)
Data:
23.29 megabytes read (231.57 kilobytes per second)
516.72 megabytes written (5.02 megabytes per second)
Ext3, data=writeback, noatime
Bonnie
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 4300 77.1 14876 22.2 4570 7.2 4024 68.1 36545 21.1 537.4 7.7
Postmark
Time:
134 seconds total
23 seconds of transactions (43 per second)
Files:
10515 created (78 per second)
Creation alone: 10000 files (104 per second)
Mixed with transactions: 515 files (22 per second)
479 read (20 per second)
521 appended (22 per second)
10515 deleted (78 per second)
Deletion alone: 10030 files (668 per second)
Mixed with transactions: 485 files (21 per second)
Data:
23.29 megabytes read (178.00 kilobytes per second)
516.72 megabytes written (3.86 megabytes per second)
ck9 no CC:
XFS, noatime, made with /mkfs.xfs -f -l internal,size=8000b /dev/sda4
Bonnie
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 5422 94.2 24321 23.8 4611 7.2 3786 64.5 11986 9.8 738.4 8.9
Postmark
Time:
120 seconds total
24 seconds of transactions (41 per second)
Files:
10515 created (87 per second)
Creation alone: 10000 files (119 per second)
Mixed with transactions: 515 files (21 per second)
479 read (19 per second)
521 appended (21 per second)
10515 deleted (87 per second)
Deletion alone: 10030 files (835 per second)
Mixed with transactions: 485 files (20 per second)
Data:
23.29 megabytes read (198.77 kilobytes per second)
516.72 megabytes written (4.31 megabytes per second)
ReiserFS noatime, notail
Bonnie
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 4162 78.6 8208 19.6 3805 5.9 5778 98.7 9883 8.1 1767.3 19.9
Postmark
Time:
104 seconds total
32 seconds of transactions (31 per second)
Files:
10515 created (101 per second)
Creation alone: 10000 files (144 per second)
Mixed with transactions: 515 files (16 per second)
479 read (14 per second)
521 appended (16 per second)
10515 deleted (101 per second)
Deletion alone: 10030 files (3343 per second)
Mixed with transactions: 485 files (15 per second)
Data:
23.29 megabytes read (229.35 kilobytes per second)
516.72 megabytes written (4.97 megabytes per second)
Ext3, data=writeback, noatime
Bonnie
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 4481 80.6 22837 35.0 4882 7.8 3909 66.5 10046 7.3 1084.2 11.7
Postmark
Time:
133 seconds total
25 seconds of transactions (40 per second)
Files:
10515 created (79 per second)
Creation alone: 10000 files (111 per second)
Mixed with transactions: 515 files (20 per second)
479 read (19 per second)
521 appended (20 per second)
10515 deleted (79 per second)
Deletion alone: 10030 files (557 per second)
Mixed with transactions: 485 files (19 per second)
Data:
23.29 megabytes read (179.34 kilobytes per second)
516.72 megabytes written (3.89 megabytes per second)
ck9 CC, no compressed swap, exact same options as previous test:
XFS, noatime, made with /mkfs.xfs -f -l internal,size=8000b /dev/sda4
Bonnie
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 5422 94.3 26796 26.4 10591 13.4 5877 99.5 179409 99.9 9520.0 100
Postmark
Time:
193 seconds total
35 seconds of transactions (28 per second)
Files:
10515 created (54 per second)
Creation alone: 10000 files (68 per second)
Mixed with transactions: 515 files (14 per second)
479 read (13 per second)
521 appended (14 per second)
10515 deleted (54 per second)
Deletion alone: 10030 files (835 per second)
Mixed with transactions: 485 files (13 per second)
Data:
23.29 megabytes read (123.58 kilobytes per second)
516.72 megabytes written (2.68 megabytes per second)
ReiserFS noatime, notail
Bonnie
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 4159 79.0 29218 71.3 6847 13.3 5267 93.2 39931 46.4 9176.5 96.4
Postmark
Time:
156 seconds total
23 seconds of transactions (43 per second)
Files:
10515 created (67 per second)
Creation alone: 10000 files (76 per second)
Mixed with transactions: 515 files (22 per second)
479 read (20 per second)
521 appended (22 per second)
10515 deleted (67 per second)
Deletion alone: 10030 files (3343 per second)
Mixed with transactions: 485 files (21 per second)
Data:
23.29 megabytes read (152.90 kilobytes per second)
516.72 megabytes written (3.31 megabytes per second)
Ext3, data=writeback, noatime
Bonnie
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 4494 81.0 20624 31.4 13911 18.7 5909 99.9 181013 100.8 9504.1 99
postmark
Time:
190 seconds total
30 seconds of transactions (33 per second)
Files:
10515 created (55 per second)
Creation alone: 10000 files (71 per second)
Mixed with transactions: 515 files (17 per second)
479 read (15 per second)
521 appended (17 per second)
10515 deleted (55 per second)
Deletion alone: 10030 files (501 per second)
Mixed with transactions: 485 files (16 per second)
Data:
23.29 megabytes read (125.54 kilobytes per second)
516.72 megabytes written (2.72 megabytes per second)
ck9 all CC options on (includes compressed swap), exact same options as previous test:
XFS, noatime, made with /mkfs.xfs -f -l internal,size=8000b /dev/sda4
Bonnie
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 5103 89.1 26559 27.0 12419 15.6 5865 99.7 179123 99.7 9447.4 99.
Postmark
Time:
204 seconds total
27 seconds of transactions (37 per second)
Files:
10515 created (51 per second)
Creation alone: 10000 files (60 per second)
Mixed with transactions: 515 files (19 per second)
479 read (17 per second)
521 appended (19 per second)
10515 deleted (51 per second)
Deletion alone: 10030 files (835 per second)
Mixed with transactions: 485 files (17 per second)
Data:
23.29 megabytes read (116.92 kilobytes per second)
516.72 megabytes written (2.53 megabytes per second)
ReiserFS noatime, notail
Bonnie
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 4194 79.5 29347 71.4 9759 14.2 5896 99.7 180668 98.8 9276.7 97.
Postmark
Time:
187 seconds total
25 seconds of transactions (40 per second)
Files:
10515 created (56 per second)
Creation alone: 10000 files (62 per second)
Mixed with transactions: 515 files (20 per second)
479 read (19 per second)
521 appended (20 per second)
10515 deleted (56 per second)
Deletion alone: 10030 files (3343 per second)
Mixed with transactions: 485 files (19 per second)
Data:
23.29 megabytes read (127.55 kilobytes per second)
516.72 megabytes written (2.76 megabytes per second)
Ext3, data=writeback, noatime
Bonnie
-------Sequential Output-------- ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 4508 81.2 19469 31.2 8110 21.1 5213 91.1 38364 46.8 4449.0 92.3
Postmark
Time:
206 seconds total
31 seconds of transactions (32 per second)
Files:
10515 created (51 per second)
Creation alone: 10000 files (64 per second)
Mixed with transactions: 515 files (16 per second)
479 read (15 per second)
521 appended (16 per second)
10515 deleted (51 per second)
Deletion alone: 10030 files (527 per second)
Mixed with transactions: 485 files (15 per second)
Data:
23.29 megabytes read (115.79 kilobytes per second)
516.72 megabytes written (2.51 megabytes per second)
Forgot to add my name to the test...
All tests done by Dimitris Krekoukias, dikrek@hotmail.com
Trying now the jp patch from http://infolinux.de/jp
I will let everyone know how that goes.
D
The benchmark effect
Here we go again. System responsiveness != throughput. Compressed caching uses more cpu than non cc so these benchmarks will show a drop in performance. Preemptible and low latency will also slightly lower throughput. None of this means anything for system responsiveness. Your results are interesting but tell us nothing about system responsiveness. All they tell me is ck9 with cc is not suited to a server - I thought I made that clear anyway.
CC parameters
Yes after discussion with RdeCastro, most of the real benefits of cc have only shown up since the new features in 0.24pre4. These are the double sized pages, compressed swap cache, page cache compression, LZO algorithm and variable sized compressed cache. I specifically selected LZO in my patch (in the source), the variable size is included in .24pre4 by default, but the other options all need to be specified. On my website I suggest to enable everything with compressed caching, and thats what my tested (and used) ck9 has.
I have 3 different trunks of ck patches (ck5, ck7 and ck9) and two of these have two branches (ck5-rl/ll and ck7/rmap). I know well that one tool is not ideal in all settings, and that is why I offer so much choice. ck9 is the best for an ordinary desktop. ck7 for high performance machines. ck5-ll is for pure low latency setups, and ck7-rmap and ck5-rl are for those interested in trying the rmap VM.
CK10 update
I've just updated my patchset to ck10. This is the same as ck9 but separated out into optional addons (cc,aavm, xfs,alsa,supermount). This makes ck10 suitable for smp as the aa-vm can be subsituted for cc. Also for those who are using ck9 and are not using xfs I recommend upgrading to ck10 and not adding the xfs patch.
where can i get patch for freebsd 4.7
Hello There
Can anyone suggest me the links or pages where i can download the patch for freebsd 4.7.
Its xwindow86 doesnot work at all. It shows the message , that a config file not found.
I have installed it 5 times and added all the packages for xwindows, but it didn't seem to work.
Please Someone help me.
mail me at:kamal_aitin@yahoo.co.in
or jaggs83@yahoo.com
thanx