Re: first little problem with private futexes
Ulrich Drepper a écrit : On 5/20/07, Eric Dumazet <[EMAIL PROTECTED]> wrote: > 1. do nothing, always use the shared futexes. Not very attractive IMO Why do you find this non attractive ? How is it performance critical ? You should know better than any other that the problem is not that the problem itself is the only one affected. If threads terminate all other programs and threads are affected since the global locks for the shared futexes are needed. That's the case I'm concerned about. It's not really about a single app creating many many threads over and over again. It's about many apps which do use threads (and that number will have to rise) starts and stop threads at a reasonable rate. It's just one more unnecessary point of contact between concurrently running apps. Well, current private futex code still use global locks (one common hash table were all waited futexes are queued, private or shared) 'Only' mmap_sem and inode/mm refcounter inc/dec are avoided. My proposal of having separate namespace was hold, in order to get the 'private futexes' accepted in kernel. So for the moment, I am not sure glibc should try to optimize CLEARTID operation. - 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: first little problem with private futexes
On 5/20/07, Eric Dumazet <[EMAIL PROTECTED]> wrote: > 1. do nothing, always use the shared futexes. Not very attractive IMO Why do you find this non attractive ? How is it performance critical ? You should know better than any other that the problem is not that the problem itself is the only one affected. If threads terminate all other programs and threads are affected since the global locks for the shared futexes are needed. That's the case I'm concerned about. It's not really about a single app creating many many threads over and over again. It's about many apps which do use threads (and that number will have to rise) starts and stop threads at a reasonable rate. It's just one more unnecessary point of contact between concurrently running apps. - 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: first little problem with private futexes
Ulrich Drepper a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's a first little issue with private futex I came across. But a real bug but a hole. When we use clone() with CLONE_CHILD_CLEARTID possible waiters are woken upon termination of the thread. This operation uses FUTEX_WAKE so far. But it in almost all cases local memory and I would even be in favor of setting this into stone. It wouldn't break anything I know of. The problem is we cannot just go over to using FUTEX_WAIT|FUTEX_PRIVATE_FLAG since this would break binaries using any glibc out there so far. There are three ways out of this I can see: 1. do nothing, always use the shared futexes. Not very attractive IMO Why do you find this non attractive ? How is it performance critical ? If a program is stupid enough to create/destroy many threads per second, I doubt it relies on a faster thread termination :) 2. try private futexes first, then shared one. This is even less attractive since in the many cases there is no waiter and we cannot determine whether the private futex notification succeeded and we're doing the expensive work as well 3. tell the kernel whether we want the new or the old notification. This can be done using a number of ways a) using some prctl(). Another unconditional syscall, not nice. b) using a new CLONE_* flag. We have currently 5 bits left and can recover two more (CLONE_DETACHED, CLONE_STOPPED). And we can invent ways to add more bits. I'm in favor of 3b but if somebody argues the costs are not justified because the effects of using the shared futex notification isn't high enough I can accept that, too. - 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/
first little problem with private futexes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's a first little issue with private futex I came across. But a real bug but a hole. When we use clone() with CLONE_CHILD_CLEARTID possible waiters are woken upon termination of the thread. This operation uses FUTEX_WAKE so far. But it in almost all cases local memory and I would even be in favor of setting this into stone. It wouldn't break anything I know of. The problem is we cannot just go over to using FUTEX_WAIT|FUTEX_PRIVATE_FLAG since this would break binaries using any glibc out there so far. There are three ways out of this I can see: 1. do nothing, always use the shared futexes. Not very attractive IMO 2. try private futexes first, then shared one. This is even less attractive since in the many cases there is no waiter and we cannot determine whether the private futex notification succeeded and we're doing the expensive work as well 3. tell the kernel whether we want the new or the old notification. This can be done using a number of ways a) using some prctl(). Another unconditional syscall, not nice. b) using a new CLONE_* flag. We have currently 5 bits left and can recover two more (CLONE_DETACHED, CLONE_STOPPED). And we can invent ways to add more bits. I'm in favor of 3b but if somebody argues the costs are not justified because the effects of using the shared futex notification isn't high enough I can accept that, too. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGUJXl2ijCOnn/RHQRAvkOAJsEmm+TiWlWRJvT5nbk0lXrpvpTaQCgo/5j FPWYxtgUIZwrdFk/K79dIi8= =kbfx -END PGP SIGNATURE- - 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/
first little problem with private futexes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's a first little issue with private futex I came across. But a real bug but a hole. When we use clone() with CLONE_CHILD_CLEARTID possible waiters are woken upon termination of the thread. This operation uses FUTEX_WAKE so far. But it in almost all cases local memory and I would even be in favor of setting this into stone. It wouldn't break anything I know of. The problem is we cannot just go over to using FUTEX_WAIT|FUTEX_PRIVATE_FLAG since this would break binaries using any glibc out there so far. There are three ways out of this I can see: 1. do nothing, always use the shared futexes. Not very attractive IMO 2. try private futexes first, then shared one. This is even less attractive since in the many cases there is no waiter and we cannot determine whether the private futex notification succeeded and we're doing the expensive work as well 3. tell the kernel whether we want the new or the old notification. This can be done using a number of ways a) using some prctl(). Another unconditional syscall, not nice. b) using a new CLONE_* flag. We have currently 5 bits left and can recover two more (CLONE_DETACHED, CLONE_STOPPED). And we can invent ways to add more bits. I'm in favor of 3b but if somebody argues the costs are not justified because the effects of using the shared futex notification isn't high enough I can accept that, too. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFGUJXl2ijCOnn/RHQRAvkOAJsEmm+TiWlWRJvT5nbk0lXrpvpTaQCgo/5j FPWYxtgUIZwrdFk/K79dIi8= =kbfx -END PGP SIGNATURE- - 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: first little problem with private futexes
Ulrich Drepper a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's a first little issue with private futex I came across. But a real bug but a hole. When we use clone() with CLONE_CHILD_CLEARTID possible waiters are woken upon termination of the thread. This operation uses FUTEX_WAKE so far. But it in almost all cases local memory and I would even be in favor of setting this into stone. It wouldn't break anything I know of. The problem is we cannot just go over to using FUTEX_WAIT|FUTEX_PRIVATE_FLAG since this would break binaries using any glibc out there so far. There are three ways out of this I can see: 1. do nothing, always use the shared futexes. Not very attractive IMO Why do you find this non attractive ? How is it performance critical ? If a program is stupid enough to create/destroy many threads per second, I doubt it relies on a faster thread termination :) 2. try private futexes first, then shared one. This is even less attractive since in the many cases there is no waiter and we cannot determine whether the private futex notification succeeded and we're doing the expensive work as well 3. tell the kernel whether we want the new or the old notification. This can be done using a number of ways a) using some prctl(). Another unconditional syscall, not nice. b) using a new CLONE_* flag. We have currently 5 bits left and can recover two more (CLONE_DETACHED, CLONE_STOPPED). And we can invent ways to add more bits. I'm in favor of 3b but if somebody argues the costs are not justified because the effects of using the shared futex notification isn't high enough I can accept that, too. - 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: first little problem with private futexes
On 5/20/07, Eric Dumazet [EMAIL PROTECTED] wrote: 1. do nothing, always use the shared futexes. Not very attractive IMO Why do you find this non attractive ? How is it performance critical ? You should know better than any other that the problem is not that the problem itself is the only one affected. If threads terminate all other programs and threads are affected since the global locks for the shared futexes are needed. That's the case I'm concerned about. It's not really about a single app creating many many threads over and over again. It's about many apps which do use threads (and that number will have to rise) starts and stop threads at a reasonable rate. It's just one more unnecessary point of contact between concurrently running apps. - 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: first little problem with private futexes
Ulrich Drepper a écrit : On 5/20/07, Eric Dumazet [EMAIL PROTECTED] wrote: 1. do nothing, always use the shared futexes. Not very attractive IMO Why do you find this non attractive ? How is it performance critical ? You should know better than any other that the problem is not that the problem itself is the only one affected. If threads terminate all other programs and threads are affected since the global locks for the shared futexes are needed. That's the case I'm concerned about. It's not really about a single app creating many many threads over and over again. It's about many apps which do use threads (and that number will have to rise) starts and stop threads at a reasonable rate. It's just one more unnecessary point of contact between concurrently running apps. Well, current private futex code still use global locks (one common hash table were all waited futexes are queued, private or shared) 'Only' mmap_sem and inode/mm refcounter inc/dec are avoided. My proposal of having separate namespace was hold, in order to get the 'private futexes' accepted in kernel. So for the moment, I am not sure glibc should try to optimize CLEARTID operation. - 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: Tiny little problem
Hi. This is a well-known problem; check the list archives for more info. On Thu, 26 Apr 2001 14:04:23 +0900 (JST) Tore Johansson <[EMAIL PROTECTED]> wrote: > Hi, > > I have a problem with accessing a magneto opto drive in Linux. > Since I upgraded the kernel from 2.3 to 2.4 I can mount the MO > drive but if I try to access a file on the drive the kernel oopses... > > After the kernel oops the MO can't be unmounted. > > The MO is has a SCSI-2 interface and the SCSI interface is a Symbios > NCR8xx type. > > Any ideas?? > > Cheers, > /Tore - 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: Tiny little problem
Hi. This is a well-known problem; check the list archives for more info. On Thu, 26 Apr 2001 14:04:23 +0900 (JST) Tore Johansson [EMAIL PROTECTED] wrote: Hi, I have a problem with accessing a magneto opto drive in Linux. Since I upgraded the kernel from 2.3 to 2.4 I can mount the MO drive but if I try to access a file on the drive the kernel oopses... After the kernel oops the MO can't be unmounted. The MO is has a SCSI-2 interface and the SCSI interface is a Symbios NCR8xx type. Any ideas?? Cheers, /Tore - 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/
Tiny little problem
Hi, I have a problem with accessing a magneto opto drive in Linux. Since I upgraded the kernel from 2.3 to 2.4 I can mount the MO drive but if I try to access a file on the drive the kernel oopses... After the kernel oops the MO can't be unmounted. The MO is has a SCSI-2 interface and the SCSI interface is a Symbios NCR8xx type. Any ideas?? Cheers, /Tore - 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/
Tiny little problem
Hi, I have a problem with accessing a magneto opto drive in Linux. Since I upgraded the kernel from 2.3 to 2.4 I can mount the MO drive but if I try to access a file on the drive the kernel oopses... After the kernel oops the MO can't be unmounted. The MO is has a SCSI-2 interface and the SCSI interface is a Symbios NCR8xx type. Any ideas?? Cheers, /Tore - 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: A little problem.
It is way OT here, but since Alan replied to this, I'll continue this thread a bit: The interesting bit here, that I don't understand, is - how in RedHat-7.0, that was released last year, libc is compiled against 2.4.0?... Did they include headers from one of pre / test versions? Thanks Guennadi On Thu, 19 Apr 2001, Alan Cox wrote: > > and upgrade the Linux Kerenl from their original 2.2.16 to 2.2.18. But when > > I compile some modules, it said my kernel is 2.4.0. I check the > > /usr/include/linux/version.h as follows, found that it shows I am using > > Kernel 2.4.0. > > No. It shows the headers your C compiler libraries are built againt. Which is > 2.4 - and which is correct. It has nothing to do with the kernel you are > running > > - > 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/ > ___ Dr. Guennadi V. Liakhovetski Department of Applied Mathematics University of Sheffield, U.K. email: [EMAIL PROTECTED] - 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: A little problem.
It is way OT here, but since Alan replied to this, I'll continue this thread a bit: The interesting bit here, that I don't understand, is - how in RedHat-7.0, that was released last year, libc is compiled against 2.4.0?... Did they include headers from one of pre / test versions? Thanks Guennadi On Thu, 19 Apr 2001, Alan Cox wrote: and upgrade the Linux Kerenl from their original 2.2.16 to 2.2.18. But when I compile some modules, it said my kernel is 2.4.0. I check the /usr/include/linux/version.h as follows, found that it shows I am using Kernel 2.4.0. No. It shows the headers your C compiler libraries are built againt. Which is 2.4 - and which is correct. It has nothing to do with the kernel you are running - 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/ ___ Dr. Guennadi V. Liakhovetski Department of Applied Mathematics University of Sheffield, U.K. email: [EMAIL PROTECTED] - 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: A little problem.
> and upgrade the Linux Kerenl from their original 2.2.16 to 2.2.18. But when > I compile some modules, it said my kernel is 2.4.0. I check the > /usr/include/linux/version.h as follows, found that it shows I am using > Kernel 2.4.0. No. It shows the headers your C compiler libraries are built againt. Which is 2.4 - and which is correct. It has nothing to do with the kernel you are running - 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: A little problem.
sounds to me like you have the wrong source in /usr/src/linux there is a module you can install, or you can do it as I normally would... obtain kernel source for 2.2.18 from ftp.kernel.org and put it in "/usr/src" (/pub/linux/kernel/v2.2/linux-2.2.18.tar.bz2) remove the symlink in /usr/src "rm -f /usr/src/linux" extract the new kernel source tree "cd /usr/src ; tar xfI linux-2.2.18.tar.bz2" rename the directory to kernel version and create symlink (for consistancy) "mv linux linux-2.2.18 ; ln -s linux-2.2.18 linux" Sam Bingner PACAF CSS/SCHE Contractor RSIS DSN 315 449-7889 COMM808 449-7889 -Original Message- From: Hai Xu [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 19, 2001 10:47 AM To: [EMAIL PROTECTED] Subject: A little problem.kernel Dear all, I have a question about the kernel used by the RedHat. I am using Redhat 7.0 and upgrade the Linux Kerenl from their original 2.2.16 to 2.2.18. But when I compile some modules, it said my kernel is 2.4.0. I check the /usr/include/linux/version.h as follows, found that it shows I am using Kernel 2.4.0. #include #if defined(__module__smp) #define UTS_RELEASE "2.4.0-0.26smp" #else #define UTS_RELEASE "2.4.0-0.26" #endif #define LINUX_VERSION_CODE 132096 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) But when I "cat /proc/version", it will give me: Linux version 2.2.18-rtl (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Thu Apr 5 23:10:12 EDT 2001 So I am totally confused by the RedHat. So could you please tell me how to solve this problem? I just want to use the 2.2.18 without the 2.4.0. I did not install this one, I also do not know where this one comes from. Thanks in advance. Hai Xu - 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/ - 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/
A little problem.
Dear all, I have a question about the kernel used by the RedHat. I am using Redhat 7.0 and upgrade the Linux Kerenl from their original 2.2.16 to 2.2.18. But when I compile some modules, it said my kernel is 2.4.0. I check the /usr/include/linux/version.h as follows, found that it shows I am using Kernel 2.4.0. #include #if defined(__module__smp) #define UTS_RELEASE "2.4.0-0.26smp" #else #define UTS_RELEASE "2.4.0-0.26" #endif #define LINUX_VERSION_CODE 132096 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c)) But when I "cat /proc/version", it will give me: Linux version 2.2.18-rtl (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Thu Apr 5 23:10:12 EDT 2001 So I am totally confused by the RedHat. So could you please tell me how to solve this problem? I just want to use the 2.2.18 without the 2.4.0. I did not install this one, I also do not know where this one comes from. Thanks in advance. Hai Xu - 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/
A little problem.
Dear all, I have a question about the kernel used by the RedHat. I am using Redhat 7.0 and upgrade the Linux Kerenl from their original 2.2.16 to 2.2.18. But when I compile some modules, it said my kernel is 2.4.0. I check the /usr/include/linux/version.h as follows, found that it shows I am using Kernel 2.4.0. #include linux/rhconfig.h #if defined(__module__smp) #define UTS_RELEASE "2.4.0-0.26smp" #else #define UTS_RELEASE "2.4.0-0.26" #endif #define LINUX_VERSION_CODE 132096 #define KERNEL_VERSION(a,b,c) (((a) 16) + ((b) 8) + (c)) But when I "cat /proc/version", it will give me: Linux version 2.2.18-rtl (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Thu Apr 5 23:10:12 EDT 2001 So I am totally confused by the RedHat. So could you please tell me how to solve this problem? I just want to use the 2.2.18 without the 2.4.0. I did not install this one, I also do not know where this one comes from. Thanks in advance. Hai Xu - 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: A little problem.
sounds to me like you have the wrong source in /usr/src/linux there is a module you can install, or you can do it as I normally would... obtain kernel source for 2.2.18 from ftp.kernel.org and put it in "/usr/src" (/pub/linux/kernel/v2.2/linux-2.2.18.tar.bz2) remove the symlink in /usr/src "rm -f /usr/src/linux" extract the new kernel source tree "cd /usr/src ; tar xfI linux-2.2.18.tar.bz2" rename the directory to kernel version and create symlink (for consistancy) "mv linux linux-2.2.18 ; ln -s linux-2.2.18 linux" Sam Bingner PACAF CSS/SCHE Contractor RSIS DSN 315 449-7889 COMM808 449-7889 -Original Message- From: Hai Xu [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 19, 2001 10:47 AM To: [EMAIL PROTECTED] Subject: A little problem.kernel Dear all, I have a question about the kernel used by the RedHat. I am using Redhat 7.0 and upgrade the Linux Kerenl from their original 2.2.16 to 2.2.18. But when I compile some modules, it said my kernel is 2.4.0. I check the /usr/include/linux/version.h as follows, found that it shows I am using Kernel 2.4.0. #include linux/rhconfig.h #if defined(__module__smp) #define UTS_RELEASE "2.4.0-0.26smp" #else #define UTS_RELEASE "2.4.0-0.26" #endif #define LINUX_VERSION_CODE 132096 #define KERNEL_VERSION(a,b,c) (((a) 16) + ((b) 8) + (c)) But when I "cat /proc/version", it will give me: Linux version 2.2.18-rtl (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Thu Apr 5 23:10:12 EDT 2001 So I am totally confused by the RedHat. So could you please tell me how to solve this problem? I just want to use the 2.2.18 without the 2.4.0. I did not install this one, I also do not know where this one comes from. Thanks in advance. Hai Xu - 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/ - 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: A little problem.
and upgrade the Linux Kerenl from their original 2.2.16 to 2.2.18. But when I compile some modules, it said my kernel is 2.4.0. I check the /usr/include/linux/version.h as follows, found that it shows I am using Kernel 2.4.0. No. It shows the headers your C compiler libraries are built againt. Which is 2.4 - and which is correct. It has nothing to do with the kernel you are running - 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/
