Re: GPL only modules
On Sunday 17 December 2006 14:54, Alexandre Oliva wrote: > > The whole reason the LGPL exists is that people realized that if they > > don't do something like that, the GPL would have been tried in court, and > > the FSF's position that anything that touches GPL'd code would probably > > have been shown to be bogus. > > Or that people would feel uncomfortable about the gray area and avoid > using the GPLed code in cases in which this would be perfectly legal > and advantageous to Free Software. Sure enough, when people create > and distribute proprietary code by taking advantage of Free Software, > that's something to be avoided, but since there are other Free > Software licenses that are not compatible with the GNU GPL, it made > sense to enable software licensed under them to be combined with these > few libraries. Letting concerns about copyright infringement, be such > acts permissible by law or not, scare Free Software developers away > from Free Software was not good for Free Software. LGPL somehow fixes this gray area to allow a wider and clear "fair use" by allowing people to easily[*] run proprietary programs in a free operating system. [*] In the sense they don't need to compile/link the program themselves, which is clearly legal under the GPL and the FSF intentions (freedom #0). So, people that just worries about "fair use" could interpret it --besides the "official" arguments- as a message that makes clear FSF is not trying to push his agenda into the gray areas of copyright laws. But the very same evidence is used to loudly support an opposite interpretation of FSF [evil] intentions, to weaken the legal strength of the GPL, and to accuse FSF of pushing some hidden and insane arguments. Presumptuous, to say the least. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ - 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: GPL only modules
On Sunday 17 December 2006 14:54, Alexandre Oliva wrote: The whole reason the LGPL exists is that people realized that if they don't do something like that, the GPL would have been tried in court, and the FSF's position that anything that touches GPL'd code would probably have been shown to be bogus. Or that people would feel uncomfortable about the gray area and avoid using the GPLed code in cases in which this would be perfectly legal and advantageous to Free Software. Sure enough, when people create and distribute proprietary code by taking advantage of Free Software, that's something to be avoided, but since there are other Free Software licenses that are not compatible with the GNU GPL, it made sense to enable software licensed under them to be combined with these few libraries. Letting concerns about copyright infringement, be such acts permissible by law or not, scare Free Software developers away from Free Software was not good for Free Software. LGPL somehow fixes this gray area to allow a wider and clear fair use by allowing people to easily[*] run proprietary programs in a free operating system. [*] In the sense they don't need to compile/link the program themselves, which is clearly legal under the GPL and the FSF intentions (freedom #0). So, people that just worries about fair use could interpret it --besides the official arguments- as a message that makes clear FSF is not trying to push his agenda into the gray areas of copyright laws. But the very same evidence is used to loudly support an opposite interpretation of FSF [evil] intentions, to weaken the legal strength of the GPL, and to accuse FSF of pushing some hidden and insane arguments. Presumptuous, to say the least. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Saturday 16 December 2006 22:01, Linus Torvalds wrote: > On Sat, 16 Dec 2006, Ricardo Galli wrote: > > As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never > > tried to change or restrict "fair use". GPL[23] covers only to > > "distibution" of the covered program. The freedom #0 says explicitly: > > "right to use the program for any purpose". > > I'm sorry, but you're just rewriting history. > > The FSF very much _has_ tried to make "fair use" a very restricted issue. > The whole reason the LGPL exists is that people realized that if they > don't do something like that, the GPL would have been tried in court, and > the FSF's position that anything that touches GPL'd code would probably > have been shown to be bogus. > > In reality, if the FSF actually believed in "fair use", they would just > have admitted that GNU libc could have continued to be under the GPL, and > that any programs that link against it are obviously not "derived" from > it. > > But no. The FSF has very much tried to confuse and muddle the issue, and > instead have claimed that projects like glibc should be done under the > "Lesser" GPL. OK, let assume your perspective of the history is the valid and real one, then, ¿where are all lawsits against other big GPL only projects? For example libqt/kdelibs. You can hardly provide any example where the GPL wasn't hold in court. > The fact is, if you accept fair use, you have to accept it for other > people to take advantage of too. Fair use really isn't just a one-way > street. "Fair use: The right set forth in Section 107 of the United States Copyright Act, to use copyrighted materials for certain purposes, such as criticism, comment, news reporting, teaching, scholarship, and research. The Copyright Act does not define fair use. Instead, whether a use is fair use is determined by balancing these factors: ..." According to the law, I don't see how FSF tries to avoid or to reject the fair use rights. It seems to me you provides us with a copyright law interpretation supported only by the very [narrow] exceptions of the copyright law, a logical fallacy. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
> I think it would be a hell of a lot better idea if people just realized > that they have "fair use" rights whether the authors give them or not, and ^ > that the authors copyrights NEVER extend to anything but a "derived work" ... > I find the RIAA's position and the DMCA distasteful, and in that I > probably have a lot of things in common with a lot of people on this list. > But by _exactly_ the same token, I also find the FSF's position and a lot > of GPL zealots' position on this matter very distasteful. ... > Because "fair use" is NOT somethng that should be specified in the ^ > license. As you probably know, the GPL, the FSF, RMS or even GPL "zealots" never tried to change or restrict "fair use". GPL[23] covers only to "distibution" of the covered program. The freedom #0 says explicitly: "right to use the program for any purpose". So, I don't see any clash here between GPL/FSF/RMS with "fair use" And you probably know that any GPLed code can be linked and executed with any other program, whatever is its license if it's for personal use (is that worse than "fair use"?). And even if there is a function in linux that disables loading of non GPL modules, it's still allowed under the GPL to distribute a kernel with those functions removed. Any user can load any other module in this kernel without worrying about "fair use" or "derived work", GPL allows her to do it. So, where's the freaking relationship between GPL (or its "zealots") and "fair use"? Who is trying to re-define it? FUD, FUD, FUD. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
I think it would be a hell of a lot better idea if people just realized that they have fair use rights whether the authors give them or not, and ^ that the authors copyrights NEVER extend to anything but a derived work ... I find the RIAA's position and the DMCA distasteful, and in that I probably have a lot of things in common with a lot of people on this list. But by _exactly_ the same token, I also find the FSF's position and a lot of GPL zealots' position on this matter very distasteful. ... Because fair use is NOT somethng that should be specified in the ^ license. As you probably know, the GPL, the FSF, RMS or even GPL zealots never tried to change or restrict fair use. GPL[23] covers only to distibution of the covered program. The freedom #0 says explicitly: right to use the program for any purpose. So, I don't see any clash here between GPL/FSF/RMS with fair use And you probably know that any GPLed code can be linked and executed with any other program, whatever is its license if it's for personal use (is that worse than fair use?). And even if there is a function in linux that disables loading of non GPL modules, it's still allowed under the GPL to distribute a kernel with those functions removed. Any user can load any other module in this kernel without worrying about fair use or derived work, GPL allows her to do it. So, where's the freaking relationship between GPL (or its zealots) and fair use? Who is trying to re-define it? FUD, FUD, FUD. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ - 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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]
On Saturday 16 December 2006 22:01, Linus Torvalds wrote: On Sat, 16 Dec 2006, Ricardo Galli wrote: As you probably know, the GPL, the FSF, RMS or even GPL zealots never tried to change or restrict fair use. GPL[23] covers only to distibution of the covered program. The freedom #0 says explicitly: right to use the program for any purpose. I'm sorry, but you're just rewriting history. The FSF very much _has_ tried to make fair use a very restricted issue. The whole reason the LGPL exists is that people realized that if they don't do something like that, the GPL would have been tried in court, and the FSF's position that anything that touches GPL'd code would probably have been shown to be bogus. In reality, if the FSF actually believed in fair use, they would just have admitted that GNU libc could have continued to be under the GPL, and that any programs that link against it are obviously not derived from it. But no. The FSF has very much tried to confuse and muddle the issue, and instead have claimed that projects like glibc should be done under the Lesser GPL. OK, let assume your perspective of the history is the valid and real one, then, ¿where are all lawsits against other big GPL only projects? For example libqt/kdelibs. You can hardly provide any example where the GPL wasn't hold in court. The fact is, if you accept fair use, you have to accept it for other people to take advantage of too. Fair use really isn't just a one-way street. Fair use: The right set forth in Section 107 of the United States Copyright Act, to use copyrighted materials for certain purposes, such as criticism, comment, news reporting, teaching, scholarship, and research. The Copyright Act does not define fair use. Instead, whether a use is fair use is determined by balancing these factors: ... According to the law, I don't see how FSF tries to avoid or to reject the fair use rights. It seems to me you provides us with a copyright law interpretation supported only by the very [narrow] exceptions of the copyright law, a logical fallacy. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ - 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.6.13
> There it is. 2.6.13 does not boot in my PPC (iBook, 500 MHz), it hangs just at the very begining and the machines is automatically rebooted after a couple of minutes. The on-screen messages finishes with a few "openpic" messages: http://mnm.uib.es/gallir/tmp/linux-13-ppc.jpg I used the same 2.5.12's .config that works fine (http://mnm.uib.es/gallir/tmp/config-2.6.13-ppc.txt). During "make oldconfig" I selected the default options, with the exception of the "hardware monitor" which I first enabled and then disabled because was the first suspicious. Can I do any further test? Or is it a stupid mistake? Cheers. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ - 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.6.13
There it is. 2.6.13 does not boot in my PPC (iBook, 500 MHz), it hangs just at the very begining and the machines is automatically rebooted after a couple of minutes. The on-screen messages finishes with a few openpic messages: http://mnm.uib.es/gallir/tmp/linux-13-ppc.jpg I used the same 2.5.12's .config that works fine (http://mnm.uib.es/gallir/tmp/config-2.6.13-ppc.txt). During make oldconfig I selected the default options, with the exception of the hardware monitor which I first enabled and then disabled because was the first suspicious. Can I do any further test? Or is it a stupid mistake? Cheers. -- ricardo galli GPG id C8114D34 http://mnm.uib.es/gallir/ - 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: [reiserfs-dev] Re: New XFS, ReiserFS and Ext2 benchmarks
> > was _just_ copied from another file system (still in buffer/cache). > You might consider rebooting to flush the cache. > Is it possible to achieve the same by umounting/mounting the file system? --ricardo - 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: [reiserfs-dev] Re: New XFS, ReiserFS and Ext2 benchmarks
> My apologies, I meant that the make is probably compiler bound (I said CPU > bound) not FS bound. We undertood ;-) > > cp -ar, and I would like Yura to try to reproduce the cp -ar as > > it seems too > > good to be true. > We find that one must use cp and similar utilities (not The cp -a figures are somehow interesting, I had to repeat it for evey file system because the cache has to be populated before copying, to avoid the influence of the file system where the kernel is copied from. I did it by doing several cps before mesurements. Despite my "efforts", variances were much higher en XFS than in ReiserFS and Ext2. The ReiserFS individual times were closer to the average than the other. Why? have no idea, I didn't do any analysis of the samples because I am not an expert in Statistics. > compilers) to become FS > bound when using a Linux FS (unlike the older Unixes for which > compiles were > considered excellent benchmarks). I was equally suprised, not only due to the wall-clock time but also to the CPU. So, I think the cache is the major player when compiling a kernel that was _just_ copied from another file system (still in buffer/cache). > > Thanks for investing the time into this Ricardo. It's just for fun --ricardo - 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: [reiserfs-dev] Re: New XFS, ReiserFS and Ext2 benchmarks
My apologies, I meant that the make is probably compiler bound (I said CPU bound) not FS bound. We undertood ;-) cp -ar, and I would like Yura to try to reproduce the cp -ar as it seems too good to be true. We find that one must use cp and similar utilities (not The cp -a figures are somehow interesting, I had to repeat it for evey file system because the cache has to be populated before copying, to avoid the influence of the file system where the kernel is copied from. I did it by doing several cps before mesurements. Despite my efforts, variances were much higher en XFS than in ReiserFS and Ext2. The ReiserFS individual times were closer to the average than the other. Why? have no idea, I didn't do any analysis of the samples because I am not an expert in Statistics. compilers) to become FS bound when using a Linux FS (unlike the older Unixes for which compiles were considered excellent benchmarks). I was equally suprised, not only due to the wall-clock time but also to the CPU. So, I think the cache is the major player when compiling a kernel that was _just_ copied from another file system (still in buffer/cache). Thanks for investing the time into this Ricardo. It's just for fun --ricardo - 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: [reiserfs-dev] Re: New XFS, ReiserFS and Ext2 benchmarks
was _just_ copied from another file system (still in buffer/cache). You might consider rebooting to flush the cache. Is it possible to achieve the same by umounting/mounting the file system? --ricardo - 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/
New XFS, ReiserFS and Ext2 benchmarks
Hi, you can find at http://bulma.lug.net/static/ a few new benchmarks among Reiser, XFS and Ext2 (also one with JFS). This time there is a comprehensive Hans' Mongo benchmarks (http://bulma.lug.net/static/mongo/ )and a couple of kernel compilations and read/write/fsync operations tests (I was very careful of populating the cache before the measures for the last two cases). Regards, --ricardo http://m3d.uib.es/~gallir/ - 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/
New XFS, ReiserFS and Ext2 benchmarks
Hi, you can find at http://bulma.lug.net/static/ a few new benchmarks among Reiser, XFS and Ext2 (also one with JFS). This time there is a comprehensive Hans' Mongo benchmarks (http://bulma.lug.net/static/mongo/ )and a couple of kernel compilations and read/write/fsync operations tests (I was very careful of populating the cache before the measures for the last two cases). Regards, --ricardo http://m3d.uib.es/~gallir/ - 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/
Reiserfs, Mongo and CPU question
Hans and reiserfs developers, the same student of my university (http://www.cs.helsinki.fi/linux/linux-kernel/2001-18/0654.html) was carrying up the mongo benchmarks against reiser, xfs, jfs and ext2 for different base sizes. For example, for the base size of 10.000 (the average of a clean distribution is about 16.000 bytes) ReiserFS is even slower than ext2. I've realised the bottleneck may be the CPU, a Cyrix MII 233MHz. FSYS=ext2 FSYS=reiserfs (time in sec.) Create32.72 / 56.90 = 0.58 Fragm.1.49 / 2.22 = 0.67 Copy98.53 / 131.81 = 0.75 Fragm.1.49 / 2.26 = 0.66 Slinks4.82 / 5.08 = 0.95 Read187.90 / 299.23 = 0.63 Stats1.01 / 0.99 = 1.02 Rename2.40 / 2.23 = 1.08 Delete6.55 / 4.82 = 1.36 Can you confirm it? We are going to do the same benchmarks on a PIII if you think it's due to the cpu. I don't post the URL of the benchmarks to the list because last time we were slashdotted ;-) and we aren't convinced they are valueable, but I can send it to you directly if you are interested. Regards, -- ricardo galli - 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/
Reiserfs, Mongo and CPU question
Hans and reiserfs developers, the same student of my university (http://www.cs.helsinki.fi/linux/linux-kernel/2001-18/0654.html) was carrying up the mongo benchmarks against reiser, xfs, jfs and ext2 for different base sizes. For example, for the base size of 10.000 (the average of a clean distribution is about 16.000 bytes) ReiserFS is even slower than ext2. I've realised the bottleneck may be the CPU, a Cyrix MII 233MHz. FSYS=ext2 FSYS=reiserfs (time in sec.) Create32.72 / 56.90 = 0.58 Fragm.1.49 / 2.22 = 0.67 Copy98.53 / 131.81 = 0.75 Fragm.1.49 / 2.26 = 0.66 Slinks4.82 / 5.08 = 0.95 Read187.90 / 299.23 = 0.63 Stats1.01 / 0.99 = 1.02 Rename2.40 / 2.23 = 1.08 Delete6.55 / 4.82 = 1.36 Can you confirm it? We are going to do the same benchmarks on a PIII if you think it's due to the cpu. I don't post the URL of the benchmarks to the list because last time we were slashdotted ;-) and we aren't convinced they are valueable, but I can send it to you directly if you are interested. Regards, -- ricardo galli - 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: reiserfs, xfs, ext2, ext3 (simple benchmarks)
> It would be great to see a table of ReiserFS/XFS/Ext2+index performance > results. Well, to make it really fair it should be Ext3+index so I'd > better add 'backport the patch to 2.2' or 'bug Stephen and friends to > hurry up' to my to-do list. You can find a simple benchmark (an average of three samples) among reiser, ext2, xfs and fat32 under Linux: http://bulma.lug.net/body.phtml?nIdNoticia=626 Although is Spanish, the tables are easy to understand. The benchmark was carried up by Guillem Cantallops, student of the University of Balearics Islands and member or the local LUG... BASIC WORDS ;-) Escritura: Writing Lectura:Reading Borrado:Deletion Copia: Copy Extracción: Extraction Regards, --ricardo http://m3d.uib.es/~gallir/ - 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: reiserfs, xfs, ext2, ext3 (simple benchmarks)
It would be great to see a table of ReiserFS/XFS/Ext2+index performance results. Well, to make it really fair it should be Ext3+index so I'd better add 'backport the patch to 2.2' or 'bug Stephen and friends to hurry up' to my to-do list. You can find a simple benchmark (an average of three samples) among reiser, ext2, xfs and fat32 under Linux: http://bulma.lug.net/body.phtml?nIdNoticia=626 Although is Spanish, the tables are easy to understand. The benchmark was carried up by Guillem Cantallops, student of the University of Balearics Islands and member or the local LUG... BASIC WORDS ;-) Escritura: Writing Lectura:Reading Borrado:Deletion Copia: Copy Extracción: Extraction Regards, --ricardo http://m3d.uib.es/~gallir/ - 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: what causes Machine Check exception? revisited (2.2.18)
>> Definitely not caused by: >> Bad Rams, mb-chipset. > > Erm, it was bad RAM everytime it happened to me. On standard PCs, you > don't see those because you don't have ECC and the error is simply not > detected. I did have the same problem with an SMP Intel 440LX which run without any problem since 1998. When I installed 2.2.18 it could run for more than 5 minutes (Alan suggested me it was . I am not sure it's a RAM poblem, because it never gave/gives a SEGFAULT compiling the kernel. I brought it back to 2.2.16 and it's running happy. Could be some SMP/BIOS related problem? If it's the RAM or chipset, I am scared how we could use it for three years and suddenly it hangs with a new version of the kernel... Blame to Intel? --ricardo http://m3d.uib.es/~gallir/ - 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: what causes Machine Check exception? revisited (2.2.18)
Definitely not caused by: Bad Rams, mb-chipset. Erm, it was bad RAM everytime it happened to me. On standard PCs, you don't see those because you don't have ECC and the error is simply not detected. I did have the same problem with an SMP Intel 440LX which run without any problem since 1998. When I installed 2.2.18 it could run for more than 5 minutes (Alan suggested me it was . I am not sure it's a RAM poblem, because it never gave/gives a SEGFAULT compiling the kernel. I brought it back to 2.2.16 and it's running happy. Could be some SMP/BIOS related problem? If it's the RAM or chipset, I am scared how we could use it for three years and suddenly it hangs with a new version of the kernel... Blame to Intel? --ricardo http://m3d.uib.es/~gallir/ - 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/
Kernel panic in 2.2.18 and SMP
I just upgraded from 2.2.16 to 2.2.18 in a production machine. The machine dies after few minutes with the following error message (it's not complete, the machine was rebooted by a colleague of mine): Kernel panic Exception. Context corruption at bank 0 The motherboard is a RD440LX DP, with adapted 2940, 3com905, mtrr enabled, ioapic enabled. We've tried several times with the same kernel and we've got the same problem after a couple of minutes. Sometimes the machine was completely blocked, even ping didn't work, others ping was ok but everythng else was down. Sysrq couldn't sync nor unmount disks. We went down to 2.2.16 and everything it's ok. Hope this helps. Regards, --ricardo http://m3d.uib.es/~gallir/ - 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/
Kernel panic in 2.2.18 and SMP
I just upgraded from 2.2.16 to 2.2.18 in a production machine. The machine dies after few minutes with the following error message (it's not complete, the machine was rebooted by a colleague of mine): Kernel panic Exception. Context corruption at bank 0 The motherboard is a RD440LX DP, with adapted 2940, 3com905, mtrr enabled, ioapic enabled. We've tried several times with the same kernel and we've got the same problem after a couple of minutes. Sometimes the machine was completely blocked, even ping didn't work, others ping was ok but everythng else was down. Sysrq couldn't sync nor unmount disks. We went down to 2.2.16 and everything it's ok. Hope this helps. Regards, --ricardo http://m3d.uib.es/~gallir/ - 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: Via UDMA5 3/4/5 is not functional!
> Then I tried kernel 2.4.1. I issued exactly the same hdparm command. > i got in syslog the message: "ide0: Speed warnings UDMA 3/4/5 is not > functional"! I had the same problem. Add append="ide0=ata66 ide1=ata66 ide0=autotune ide1=autotune hda=autotune hdb=autotune hdc=autotune" to lilo.conf. BTW, I am having now CRC errors in IDE1 on the VIA, IDE0 it's ok at udma5 and 30MB/sec. Regards, --ricardo http://m3d.uib.es/~gallir/ - 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: Via UDMA5 3/4/5 is not functional!
Then I tried kernel 2.4.1. I issued exactly the same hdparm command. i got in syslog the message: "ide0: Speed warnings UDMA 3/4/5 is not functional"! I had the same problem. Add append="ide0=ata66 ide1=ata66 ide0=autotune ide1=autotune hda=autotune hdb=autotune hdc=autotune" to lilo.conf. BTW, I am having now CRC errors in IDE1 on the VIA, IDE0 it's ok at udma5 and 30MB/sec. Regards, --ricardo http://m3d.uib.es/~gallir/ - 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: 2.4.1 eats RAM or /proc/meminfo bug
> you should give up thinking there's any real relation between 2.2 > and 2.4. yes, they're both Linux, but their behaviors are essentially > unrelated. > > > total used free sharedbuffers >cached > > Mem:255340 232444 22896 0 16988 > 93212 > > -/+ buffers/cache: 122244 133096 > > Swap: 208804 0 208804 > > no swap in use, so there's no problem. except that 22MB is free/wasted. Then, who is using those 122,244 KB of RAM than cannot be otherwise used for buffers/cache? Perhaps I am wrong and that number is the sum of procs memory plus buffer/caches, but then it should have more free RAM than show in free/meminfo. And altough cache and buffers are more or less stable, the reported "used" memory" is still increasing. What I understand is (no accounting for swap): cache+buffers == active+inact_dirty+inact_clean. userland mem == total - (kernel + cache + buffers) but my reported numbers don't match. I am doing against the maths with the current situation, and they still worse, buffers/cache have increased in ~4MB but free memory has decreased in ~14MB (with the same workload and processes): [gallir@m3d gallir]$ free total used free sharedbuffers cached Mem:255340 246816 8524 0 4048 110736 -/+ buffers/cache: 132032 123308 Swap: 208804 0 208804 It's preferable to use all available RAM for buffers/cache, but this isn't the case... Sorry if I am wrong, I couldn't find more related docs about these changes. --ricardo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.1 eats RAM or /proc/meminfo bug
I noticed in my server that the memory consumption with 2.4.1 it much higher
than 2.2.18 and it gets worse over time.
Free was reporting up to 140MB of RAM with no user/X session (50-60MB with
2.2.18, same software). I've upgraded to procps 2.0.7, but the problem
persists. After few minutes of rebooting the server, the memory usage was
40-50MB, but after 24 hours the used memory grew to 120MB. I though it could
be Apache or Postgres servers, so I've stopped them but the memory decreased
just few megabytes.
I did then another check, I summed the RSS of all processes (which should
give more than free) and it is reporting _less_ that free.
Find the figures and sys info below. Please note that the used memory it's
about 120MB, with 2.2.x it never passed 60MB with the same conf.
[root@m3d /root]# uname -a
Linux m3d.uib.es 2.4.1 #2 Thu Feb 1 12:22:17 MET 2001 i686 unknown
[root@m3d /root]# free -V
procps version 2.0.7
[root@m3d /root]# free
total used free sharedbuffers cached
Mem:255340 232444 22896 0 16988 93212
-/+ buffers/cache: 122244 133096
Swap: 208804 0 208804
[root@m3d /root]# cat /proc/meminfo
total:used:free: shared: buffers: cached:
Mem: 261468160 238030848 234373120 17395712 95453184
Swap: 2138152960 213815296
MemTotal: 255340 kB
MemFree: 22888 kB
MemShared: 0 kB
Buffers: 16988 kB
Cached: 93216 kB
Active: 15424 kB
Inact_dirty: 92172 kB
Inact_clean: 2608 kB
Inact_target: 60 kB
HighTotal: 0 kB
HighFree:0 kB
LowTotal: 255340 kB
LowFree: 22888 kB
SwapTotal: 208804 kB
SwapFree: 208804 kB
[root@m3d /proc]# modprobe -l
/lib/modules/2.4.1/kernel/drivers/net/dummy.o
/lib/modules/2.4.1/kernel/drivers/net/eepro100.o
/lib/modules/2.4.1/kernel/drivers/parport/parport.o
/lib/modules/2.4.1/kernel/drivers/parport/parport_pc.o
/lib/modules/2.4.1/kernel/drivers/sound/ac97_codec.o
/lib/modules/2.4.1/kernel/drivers/sound/ad1848.o
/lib/modules/2.4.1/kernel/drivers/sound/es1370.o
/lib/modules/2.4.1/kernel/drivers/sound/es1371.o
/lib/modules/2.4.1/kernel/drivers/sound/esssolo1.o
/lib/modules/2.4.1/kernel/drivers/sound/maestro.o
/lib/modules/2.4.1/kernel/drivers/sound/mpu401.o
/lib/modules/2.4.1/kernel/drivers/sound/sound.o
/lib/modules/2.4.1/kernel/drivers/sound/soundcore.o
/lib/modules/2.4.1/kernel/drivers/sound/sscape.o
/lib/modules/2.4.1/kernel/fs/msdos/msdos.o
/lib/modules/2.4.1/kernel/fs/vfat/vfat.o
[root@m3d /root]# ps axlh | awk '{i+=$7; j+=$8}; END{ print i, j }'
254592 99748
Note in the last command that the total RSS is lower thet the used memory
reported by free/meminfo. The machine is a plain PIII with IDE disks adn
3Com905 etherboard.
Just tell me if you need for info or reports.
Regards.
--ricardo
http://m3d.uib.es/~gallir/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
2.4.1 eats RAM or /proc/meminfo bug
I noticed in my server that the memory consumption with 2.4.1 it much higher
than 2.2.18 and it gets worse over time.
Free was reporting up to 140MB of RAM with no user/X session (50-60MB with
2.2.18, same software). I've upgraded to procps 2.0.7, but the problem
persists. After few minutes of rebooting the server, the memory usage was
40-50MB, but after 24 hours the used memory grew to 120MB. I though it could
be Apache or Postgres servers, so I've stopped them but the memory decreased
just few megabytes.
I did then another check, I summed the RSS of all processes (which should
give more than free) and it is reporting _less_ that free.
Find the figures and sys info below. Please note that the used memory it's
about 120MB, with 2.2.x it never passed 60MB with the same conf.
[root@m3d /root]# uname -a
Linux m3d.uib.es 2.4.1 #2 Thu Feb 1 12:22:17 MET 2001 i686 unknown
[root@m3d /root]# free -V
procps version 2.0.7
[root@m3d /root]# free
total used free sharedbuffers cached
Mem:255340 232444 22896 0 16988 93212
-/+ buffers/cache: 122244 133096
Swap: 208804 0 208804
[root@m3d /root]# cat /proc/meminfo
total:used:free: shared: buffers: cached:
Mem: 261468160 238030848 234373120 17395712 95453184
Swap: 2138152960 213815296
MemTotal: 255340 kB
MemFree: 22888 kB
MemShared: 0 kB
Buffers: 16988 kB
Cached: 93216 kB
Active: 15424 kB
Inact_dirty: 92172 kB
Inact_clean: 2608 kB
Inact_target: 60 kB
HighTotal: 0 kB
HighFree:0 kB
LowTotal: 255340 kB
LowFree: 22888 kB
SwapTotal: 208804 kB
SwapFree: 208804 kB
[root@m3d /proc]# modprobe -l
/lib/modules/2.4.1/kernel/drivers/net/dummy.o
/lib/modules/2.4.1/kernel/drivers/net/eepro100.o
/lib/modules/2.4.1/kernel/drivers/parport/parport.o
/lib/modules/2.4.1/kernel/drivers/parport/parport_pc.o
/lib/modules/2.4.1/kernel/drivers/sound/ac97_codec.o
/lib/modules/2.4.1/kernel/drivers/sound/ad1848.o
/lib/modules/2.4.1/kernel/drivers/sound/es1370.o
/lib/modules/2.4.1/kernel/drivers/sound/es1371.o
/lib/modules/2.4.1/kernel/drivers/sound/esssolo1.o
/lib/modules/2.4.1/kernel/drivers/sound/maestro.o
/lib/modules/2.4.1/kernel/drivers/sound/mpu401.o
/lib/modules/2.4.1/kernel/drivers/sound/sound.o
/lib/modules/2.4.1/kernel/drivers/sound/soundcore.o
/lib/modules/2.4.1/kernel/drivers/sound/sscape.o
/lib/modules/2.4.1/kernel/fs/msdos/msdos.o
/lib/modules/2.4.1/kernel/fs/vfat/vfat.o
[root@m3d /root]# ps axlh | awk '{i+=$7; j+=$8}; END{ print i, j }'
254592 99748
Note in the last command that the total RSS is lower thet the used memory
reported by free/meminfo. The machine is a plain PIII with IDE disks adn
3Com905 etherboard.
Just tell me if you need for info or reports.
Regards.
--ricardo
http://m3d.uib.es/~gallir/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.4.1 eats RAM or /proc/meminfo bug
you should give up thinking there's any real relation between 2.2 and 2.4. yes, they're both Linux, but their behaviors are essentially unrelated. total used free sharedbuffers cached Mem:255340 232444 22896 0 16988 93212 -/+ buffers/cache: 122244 133096 Swap: 208804 0 208804 no swap in use, so there's no problem. except that 22MB is free/wasted. Then, who is using those 122,244 KB of RAM than cannot be otherwise used for buffers/cache? Perhaps I am wrong and that number is the sum of procs memory plus buffer/caches, but then it should have more free RAM than show in free/meminfo. And altough cache and buffers are more or less stable, the reported "used" memory" is still increasing. What I understand is (no accounting for swap): cache+buffers == active+inact_dirty+inact_clean. userland mem == total - (kernel + cache + buffers) but my reported numbers don't match. I am doing against the maths with the current situation, and they still worse, buffers/cache have increased in ~4MB but free memory has decreased in ~14MB (with the same workload and processes): [gallir@m3d gallir]$ free total used free sharedbuffers cached Mem:255340 246816 8524 0 4048 110736 -/+ buffers/cache: 132032 123308 Swap: 208804 0 208804 It's preferable to use all available RAM for buffers/cache, but this isn't the case... Sorry if I am wrong, I couldn't find more related docs about these changes. --ricardo - 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/
