Re: 2.4.4-ac6 compile error in plip.c
On Fri, May 11, 2001 at 02:53:09PM +1000, Keith Owens wrote: > The first __initdata is marked as const, the second is not, a section > cannot contain both const and non-const data. Against 2.4.4-ac6. So we should also update the documentation to reflect this. --- linux-2.4.4/include/linux/init.h.orig Wed May 9 21:33:38 2001 +++ linux-2.4.4/include/linux/init.hFri May 11 09:53:57 2001 @@ -34,6 +34,8 @@ * Don't forget to initialize data not at file scope, i.e. within a function, * as gcc otherwise puts the data into the bss section and not into the init * section. + * + * Also note, that this data cannot be "const". */ #ifndef MODULE --- linux-2.4.4/Documentation/DocBook/kernel-hacking.tmpl.orig Fri Apr 6 19:42:55 2001 +++ linux-2.4.4/Documentation/DocBook/kernel-hacking.tmpl Fri May 11 09:58:45 +2001 @@ -713,7 +713,8 @@ Static data structures marked as __initdata must be initialised - (as opposed to ordinary static data which is zeroed BSS). + (as opposed to ordinary static data which is zeroed BSS) and cannot be + const. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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.4-ac6 compile error in plip.c
On Fri, May 11, 2001 at 02:53:09PM +1000, Keith Owens wrote: The first __initdata is marked as const, the second is not, a section cannot contain both const and non-const data. Against 2.4.4-ac6. So we should also update the documentation to reflect this. --- linux-2.4.4/include/linux/init.h.orig Wed May 9 21:33:38 2001 +++ linux-2.4.4/include/linux/init.hFri May 11 09:53:57 2001 @@ -34,6 +34,8 @@ * Don't forget to initialize data not at file scope, i.e. within a function, * as gcc otherwise puts the data into the bss section and not into the init * section. + * + * Also note, that this data cannot be const. */ #ifndef MODULE --- linux-2.4.4/Documentation/DocBook/kernel-hacking.tmpl.orig Fri Apr 6 19:42:55 2001 +++ linux-2.4.4/Documentation/DocBook/kernel-hacking.tmpl Fri May 11 09:58:45 +2001 @@ -713,7 +713,8 @@ /para para Static data structures marked as type__initdata/type must be initialised - (as opposed to ordinary static data which is zeroed BSS). + (as opposed to ordinary static data which is zeroed BSS) and cannot be + typeconst/type. /para /sect1 Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: page_launder() bug
On Tue, May 08, 2001 at 09:52:15AM +0200, Helge Hafting wrote:
> > Isn't this asking for trouble with the optimizer ? It could kill both
> > !!. Using that is like trusting on a certain struct padding-alignment.
>
> No, this won't cause trouble with the optimizer, because the
> optimizer isn't supposed to do _wrong_ things.
Right. The optimizer proves equivalence of terms and exchange the
one that are bad for the optimization goal (e.g performance,
speed, size) against the one that works more towards this goal.
Everything else is an optimizer BUG, which should be reported and
fixed.
The C{89,99} standard now defines the syntax and semantics of
theses terms.
Relevant for the optimizer: possible values of terms, assumptions
made on the static and dynamic behavior of these terms (add
anything I forgot).
So the optimizer should NEVER cause trouble if you write
completely valid C{89,99} and the compiler and environment
implement 100% of the semantics of it.
Compiler specific features should be seen as an addition to the
standard on this compiler. They follow the same rules stated
above.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< been there and had much fun >>>>>>>>>>>>
-
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: [PATCH] make distclean tries to delete dirs in tmpfs
On Wed, May 09, 2001 at 03:29:28PM -0700, H. Peter Anvin wrote: > By author: Ingo Oeser <[EMAIL PROTECTED]> > > make distclean deletes anything with size 0. This includes > > directories, while making the kernel in tmpfs or ramfs. > Wouldn't it be better to fix tmpfs/ramfs to report something sensible, > even if it's artificial? No, because it gives it as arguments to "rm" (which only deletes files by defintion) and not to "rm -rf" (which also deletes directories). Not excluding directories from the arguments to "rm" is the BUG. All my scripts always do that, just the kernel Makefile doesn't. And it might even be faster, because we don't have to do all the other tests, if it's not an directory ;-) > N.B.: X/KDE will not run on a ramfs, because it reports as a size-zero > filesystem in "df". Switching to tmpfs solved that for me. This is partially a ramfs BUG, because filesystems are supposed to do accounting ;-) OTOH, querying the available space before transfers says NOTHING about the sucess of an operation. kfm is not the only application running and the fs might do delayed allocation. Applications should not check for free space, they should try to allocate it (and maybe touch it, if we are not IO bound) and watch for ENOSPC instead. Then we truncate all written stuff to the extend, where it made sense, delete the whole file if it has become size 0 and emit an error telling the user, that we had not enough disk space at this time to succeed. We don't check for available memory either, so why do it on disk? It made sense in DOS times, but doesn't do anymore. It's only relevant to the administrator to tell him, that we need a bigger disk ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: [PATCH] make distclean tries to delete dirs in tmpfs
On Wed, May 09, 2001 at 03:29:28PM -0700, H. Peter Anvin wrote: By author:Ingo Oeser [EMAIL PROTECTED] make distclean deletes anything with size 0. This includes directories, while making the kernel in tmpfs or ramfs. Wouldn't it be better to fix tmpfs/ramfs to report something sensible, even if it's artificial? No, because it gives it as arguments to rm (which only deletes files by defintion) and not to rm -rf (which also deletes directories). Not excluding directories from the arguments to rm is the BUG. All my scripts always do that, just the kernel Makefile doesn't. And it might even be faster, because we don't have to do all the other tests, if it's not an directory ;-) N.B.: X/KDE will not run on a ramfs, because it reports as a size-zero filesystem in df. Switching to tmpfs solved that for me. This is partially a ramfs BUG, because filesystems are supposed to do accounting ;-) OTOH, querying the available space before transfers says NOTHING about the sucess of an operation. kfm is not the only application running and the fs might do delayed allocation. Applications should not check for free space, they should try to allocate it (and maybe touch it, if we are not IO bound) and watch for ENOSPC instead. Then we truncate all written stuff to the extend, where it made sense, delete the whole file if it has become size 0 and emit an error telling the user, that we had not enough disk space at this time to succeed. We don't check for available memory either, so why do it on disk? It made sense in DOS times, but doesn't do anymore. It's only relevant to the administrator to tell him, that we need a bigger disk ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: page_launder() bug
On Tue, May 08, 2001 at 09:52:15AM +0200, Helge Hafting wrote:
Isn't this asking for trouble with the optimizer ? It could kill both
!!. Using that is like trusting on a certain struct padding-alignment.
No, this won't cause trouble with the optimizer, because the
optimizer isn't supposed to do _wrong_ things.
Right. The optimizer proves equivalence of terms and exchange the
one that are bad for the optimization goal (e.g performance,
speed, size) against the one that works more towards this goal.
Everything else is an optimizer BUG, which should be reported and
fixed.
The C{89,99} standard now defines the syntax and semantics of
theses terms.
Relevant for the optimizer: possible values of terms, assumptions
made on the static and dynamic behavior of these terms (add
anything I forgot).
So the optimizer should NEVER cause trouble if you write
completely valid C{89,99} and the compiler and environment
implement 100% of the semantics of it.
Compiler specific features should be seen as an addition to the
standard on this compiler. They follow the same rules stated
above.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
been there and had much fun
-
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/
[PATCH] make distclean tries to delete dirs in tmpfs
Hi there, make distclean deletes anything with size 0. This includes directories, while making the kernel in tmpfs or ramfs. This patch solves it, by not deleting directories in this rule. Patch applies to any official kernel and with offsets even to recent ac series. --- linux-2.4.2-ac19/Makefile.orig Wed May 9 10:47:04 2001 +++ linux-2.4.2-ac19/Makefile Wed May 9 10:51:04 2001 @@ -415,7 +415,8 @@ $(MAKE) -C Documentation/DocBook mrproper distclean: mrproper - rm -f core `find . \( -name '*.orig' -o -name '*.rej' -o -name '*~' \ + rm -f core `find . \( -not -type d \) -and \ + \( -name '*.orig' -o -name '*.rej' -o -name '*~' \ -o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \ -o -name '.*.rej' -o -name '.SUMS' -o -size 0 \) -print` TAGS tags Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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/
[PATCH] make distclean tries to delete dirs in tmpfs
Hi there, make distclean deletes anything with size 0. This includes directories, while making the kernel in tmpfs or ramfs. This patch solves it, by not deleting directories in this rule. Patch applies to any official kernel and with offsets even to recent ac series. --- linux-2.4.2-ac19/Makefile.orig Wed May 9 10:47:04 2001 +++ linux-2.4.2-ac19/Makefile Wed May 9 10:51:04 2001 @@ -415,7 +415,8 @@ $(MAKE) -C Documentation/DocBook mrproper distclean: mrproper - rm -f core `find . \( -name '*.orig' -o -name '*.rej' -o -name '*~' \ + rm -f core `find . \( -not -type d \) -and \ + \( -name '*.orig' -o -name '*.rej' -o -name '*~' \ -o -name '*.bak' -o -name '#*#' -o -name '.*.orig' \ -o -name '.*.rej' -o -name '.SUMS' -o -size 0 \) -print` TAGS tags Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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/
Initio maintainer?
[please CC me for replies on linux-scsi, since I'm only subscribed to linux-kernel] Hi there, Who considers himself a maintainer of the ini9100u.[ch] ? The driver has not been maintained since 1999, according to the sources. A friend of mine uses this controller for daily production on his workstation and would like to switch to 2.4.x due to several reasons, but the 2.4 version of this driver doesn't even detect the controller :-( Where do I start to get it working? Any good reference about the linux-scsi subsystem? For drivers? Thanks for any help Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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/
Initio maintainer?
[please CC me for replies on linux-scsi, since I'm only subscribed to linux-kernel] Hi there, Who considers himself a maintainer of the ini9100u.[ch] ? The driver has not been maintained since 1999, according to the sources. A friend of mine uses this controller for daily production on his workstation and would like to switch to 2.4.x due to several reasons, but the 2.4 version of this driver doesn't even detect the controller :-( Where do I start to get it working? Any good reference about the linux-scsi subsystem? For drivers? Thanks for any help Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: Next compile time problem ...
On Sat, May 05, 2001 at 09:20:09PM +0200, Frank Klemm wrote: > > Compiling of kernel 2.4.3 stops: Try compiling a RECENT kernel. > Messages and .config are appended. > buz.c:188: `KMALLOC_MAXSIZE' undeclared (first use in this function) buz.c will die soon. It will be integrated into the zoran driver. Read the archives for details. > dscc4.c:1745: `PCI_VENDOR_ID_SIEMENS' undeclared here (not in a function) > dscc4.c:1745: initializer element is not constant > dscc4.c:1745: (near initialization for `dscc4_pci_tbl[0].vendor') > dscc4.c:1745: `PCI_DEVICE_ID_SIEMENS_DSCC4' undeclared here (not in a function) Fixed in 2.4.4 and later. Try compiling a recent kernel. I'm running 2.4.5-pre1 now with SMP and highmem support enabled and used. Hope that helps Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: Next compile time problem ...
On Sat, May 05, 2001 at 09:20:09PM +0200, Frank Klemm wrote: Compiling of kernel 2.4.3 stops: Try compiling a RECENT kernel. Messages and .config are appended. buz.c:188: `KMALLOC_MAXSIZE' undeclared (first use in this function) buz.c will die soon. It will be integrated into the zoran driver. Read the archives for details. dscc4.c:1745: `PCI_VENDOR_ID_SIEMENS' undeclared here (not in a function) dscc4.c:1745: initializer element is not constant dscc4.c:1745: (near initialization for `dscc4_pci_tbl[0].vendor') dscc4.c:1745: `PCI_DEVICE_ID_SIEMENS_DSCC4' undeclared here (not in a function) Fixed in 2.4.4 and later. Try compiling a recent kernel. I'm running 2.4.5-pre1 now with SMP and highmem support enabled and used. Hope that helps Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Thu, May 03, 2001 at 05:44:36PM +1000, Keith Owens wrote: > >2. How do you do it today, and why wouldn't that work? > > LD_PRELOAD on a library that overrides gettimeofday(). I can see no > reason why that would not continue to work. Static linkage? > What would stop working > are timewarp modules that intercepted the syscall at the kernel level > instead of user space level. That's what the poster talked about ;-) Think subterfuge (sp?) and friends. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: Why recovering from broken configs is too hard
On Thu, May 03, 2001 at 03:47:55AM -0400, Eric S. Raymond wrote: > OK, so you want CML2's "make oldconfig" to do something more graceful than > simply say "Foo! You violated this constraint! Go fix it!" Yes, that would be nice. > The obvious thing to try is to start with the configuration you have > and try mutating the variables that occur in the broken constraint(s). No, that is not the obvious way for me. > Have I got the point across yet? There are *no* good solutions > to this problem. There aren't even any clean ways to separate > easy cases from hard ones. There might be. If the current dependencies of the symbols can be represented as a tree (or can be topologically sorted, to be CS-correct), then I would only care about the "leaves" of that tree. Most added symbols in newer configs are added as leaves. So this should suffice in most situations. We also have defaults for all new values in our arch/$ARCH/defconfig. So we read all symbols from .config and from defconfig into 2 flat tables (no constraints applied here!) together with their values. If we miss a symbol from .config, we ask the user, using the one from defconfig as default, if we cannot derive its value from our constraints. If we have a symbol in .config, that we don't know about, we simply ignore it (and tell the user that it's "obsolete or renamed"). If the value for a symbol is there, but doesn't fit our constraints: Ask the user or use the opposite (if it is boolean). That was the 99% case: "leaves". They are easy. Now the nodes. We can try fixing the config by changing the symbols from leaves, to root (to save derives). But we only give this solution a certain amount of "tries" and give up (or tell the user, that we have a hard time here and aks for continue or abort and fixing by hand), if we either tried to often or a certain amount of time has passed (30secs maximum until next prompt). This is no "perfect" solution, but it covers the common cases well enough. Eric, what do you think about that "dirty hack" variant? ;-) And will the derivation be in nearly constant time, if I change one symbol? Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Thu, May 03, 2001 at 05:44:36PM +1000, Keith Owens wrote: 2. How do you do it today, and why wouldn't that work? LD_PRELOAD on a library that overrides gettimeofday(). I can see no reason why that would not continue to work. Static linkage? What would stop working are timewarp modules that intercepted the syscall at the kernel level instead of user space level. That's what the poster talked about ;-) Think subterfuge (sp?) and friends. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: Why recovering from broken configs is too hard
On Thu, May 03, 2001 at 03:47:55AM -0400, Eric S. Raymond wrote: OK, so you want CML2's make oldconfig to do something more graceful than simply say Foo! You violated this constraint! Go fix it! Yes, that would be nice. The obvious thing to try is to start with the configuration you have and try mutating the variables that occur in the broken constraint(s). No, that is not the obvious way for me. Have I got the point across yet? There are *no* good solutions to this problem. There aren't even any clean ways to separate easy cases from hard ones. There might be. If the current dependencies of the symbols can be represented as a tree (or can be topologically sorted, to be CS-correct), then I would only care about the leaves of that tree. Most added symbols in newer configs are added as leaves. So this should suffice in most situations. We also have defaults for all new values in our arch/$ARCH/defconfig. So we read all symbols from .config and from defconfig into 2 flat tables (no constraints applied here!) together with their values. If we miss a symbol from .config, we ask the user, using the one from defconfig as default, if we cannot derive its value from our constraints. If we have a symbol in .config, that we don't know about, we simply ignore it (and tell the user that it's obsolete or renamed). If the value for a symbol is there, but doesn't fit our constraints: Ask the user or use the opposite (if it is boolean). That was the 99% case: leaves. They are easy. Now the nodes. We can try fixing the config by changing the symbols from leaves, to root (to save derives). But we only give this solution a certain amount of tries and give up (or tell the user, that we have a hard time here and aks for continue or abort and fixing by hand), if we either tried to often or a certain amount of time has passed (30secs maximum until next prompt). This is no perfect solution, but it covers the common cases well enough. Eric, what do you think about that dirty hack variant? ;-) And will the derivation be in nearly constant time, if I change one symbol? Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: [PATCH] adding PCI bus information to SCSI layer
On Tue, May 01, 2001 at 09:32:41PM +0100, Alan Cox wrote:
> Having thought over the issues I plan to maintain a 32bit dev_t kernel with
> conventional mknod behaviour, even if Linus won't. One very interesting item
> that Peter Anvin noted is that its not clear in POSIX that
>
> mknod /dev/ttyF00 c 100 100
>
> open("/dev/ttyF00/speed=9600,clocal");
>
> is illegal. That may be a nice way to get much of the desired
> behaviour without totally breaking compatibility
Ouch!
How is that supposed to work with the dcache?
1. Does POSIX state, that "/" is the directory/entry[1] separator?
2. Can a device node be an directory?
If 1. and not 2., there is no way to implement it like that.
I don't know how people call this, if they call sth. like DevFS
"crappy", but I would be very surprised, if they call it "clean".
Just think of:
test -r /dev/ttyF00/speed=9600,clocal && cat /dev/ttyF00/speed=9600,clocal
Or the equivalent in C in most of the programs, which read sth.
POSIX might not forbid this, because common sense already does ;-)
Regards
Ingo Oeser
[1] entry := directory | file
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< been there and had much fun >>>>>>>>>>>>
-
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 Kernel Debuggers, KDB or KGDB?
On Tue, May 01, 2001 at 10:22:14AM -0500, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > Basically you could add support for ALL generic subsystems, that > > support dummy hardware, like SCSI and ISDN for example. > > Is that planned or do I suggest sth. stupid here? ;-) > > Neither. I know squat about hardware, so I had no idea that SCSI and ISDN > would be easy to do from UML. > > If the SCSI and ISDN people want to produce appropriate UML drivers, I take > patches :-) Everything is there. SCSI and ISDN have the equivalent devices of the "lo" driver for the networking layer. Or the equivalent of tun/tap devices for the ethernet layer. It just have to be an config.in option in UML and every other adapters switched off. The problem is: I still do not really get how UML really works. Many of the mapping rules (Kernel machanism on normal arch -> UML) are not quite clear to me. Is there a paper or sth. like that describing the design a bit more in detail? I only found usage papers on the user-mode-linux home page. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: Maximum files per Directory
On Tue, May 01, 2001 at 03:03:44PM -0700, H. Peter Anvin wrote: > > Bit of both. You exceeded the max link count, and your > > performance would have been abominable too. cyrus should be > > using heirarchies of directories for very large amounts of > > stuff. Right. > But also showing, once again, that this particular scalability problem > really is a headache for some people. If you do ls on that directory as an admin, you'll see, what the REAL cause of this headache is: The application doing such stupid thing! People (writing applications) building up such large directories should be forced to read every entry of it aloud. Then they'll learn[1] and the problem is solved. Regards Ingo Oeser [1] If not, let them repeat until they do. -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: Unknown HZ value! (2000) Assume 1024.
On Wed, May 02, 2001 at 02:42:58AM -0400, Albert D. Cahalan wrote: > > In .../fs/proc/proc_misc.c:kstat_read_proc(), the cpu line is being > > computed by: > > > > len = sprintf(page, "cpu %u %u %u %lu\n", user, nice, system, > > jif * smp_num_cpus - (user + nice + system)); > > This is pretty bogus. The idle time can run _backwards_ on an SMP > system. What is "top" supposed to do with that, print a negative > number for %idle time? (some versions do, while others truncate > at zero or wrap around to 4 billion -- pick your poison) Just a "me too". I've seen this with one or two days uptime already. An idle of more than 40.000%. May be this means, that the machine was _very_ bored and needs my attention ;-) cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 851.987 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1697.38 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 851.987 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1697.38 Just FYI. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: Unknown HZ value! (2000) Assume 1024.
On Wed, May 02, 2001 at 02:42:58AM -0400, Albert D. Cahalan wrote: In .../fs/proc/proc_misc.c:kstat_read_proc(), the cpu line is being computed by: len = sprintf(page, cpu %u %u %u %lu\n, user, nice, system, jif * smp_num_cpus - (user + nice + system)); This is pretty bogus. The idle time can run _backwards_ on an SMP system. What is top supposed to do with that, print a negative number for %idle time? (some versions do, while others truncate at zero or wrap around to 4 billion -- pick your poison) Just a me too. I've seen this with one or two days uptime already. An idle of more than 40.000%. May be this means, that the machine was _very_ bored and needs my attention ;-) cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 851.987 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1697.38 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping: 6 cpu MHz : 851.987 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1697.38 Just FYI. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: Maximum files per Directory
On Tue, May 01, 2001 at 03:03:44PM -0700, H. Peter Anvin wrote: Bit of both. You exceeded the max link count, and your performance would have been abominable too. cyrus should be using heirarchies of directories for very large amounts of stuff. Right. But also showing, once again, that this particular scalability problem really is a headache for some people. If you do ls on that directory as an admin, you'll see, what the REAL cause of this headache is: The application doing such stupid thing! People (writing applications) building up such large directories should be forced to read every entry of it aloud. Then they'll learn[1] and the problem is solved. Regards Ingo Oeser [1] If not, let them repeat until they do. -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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 Kernel Debuggers, KDB or KGDB?
On Tue, May 01, 2001 at 10:22:14AM -0500, Jeff Dike wrote: [EMAIL PROTECTED] said: Basically you could add support for ALL generic subsystems, that support dummy hardware, like SCSI and ISDN for example. Is that planned or do I suggest sth. stupid here? ;-) Neither. I know squat about hardware, so I had no idea that SCSI and ISDN would be easy to do from UML. If the SCSI and ISDN people want to produce appropriate UML drivers, I take patches :-) Everything is there. SCSI and ISDN have the equivalent devices of the lo driver for the networking layer. Or the equivalent of tun/tap devices for the ethernet layer. It just have to be an config.in option in UML and every other adapters switched off. The problem is: I still do not really get how UML really works. Many of the mapping rules (Kernel machanism on normal arch - UML) are not quite clear to me. Is there a paper or sth. like that describing the design a bit more in detail? I only found usage papers on the user-mode-linux home page. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: [PATCH] adding PCI bus information to SCSI layer
On Tue, May 01, 2001 at 09:32:41PM +0100, Alan Cox wrote: Having thought over the issues I plan to maintain a 32bit dev_t kernel with conventional mknod behaviour, even if Linus won't. One very interesting item that Peter Anvin noted is that its not clear in POSIX that mknod /dev/ttyF00 c 100 100 open(/dev/ttyF00/speed=9600,clocal); is illegal. That may be a nice way to get much of the desired behaviour without totally breaking compatibility Ouch! How is that supposed to work with the dcache? 1. Does POSIX state, that / is the directory/entry[1] separator? 2. Can a device node be an directory? If 1. and not 2., there is no way to implement it like that. I don't know how people call this, if they call sth. like DevFS crappy, but I would be very surprised, if they call it clean. Just think of: test -r /dev/ttyF00/speed=9600,clocal cat /dev/ttyF00/speed=9600,clocal Or the equivalent in C in most of the programs, which read sth. POSIX might not forbid this, because common sense already does ;-) Regards Ingo Oeser [1] entry := directory | file -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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 Kernel Debuggers, KDB or KGDB?
On Mon, Apr 30, 2001 at 07:11:35PM -0500, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > Where can I find an analysis of the relative strengths and weaknesses > > of KDB and KGDB for kernel debug? Has the linux community come to any > > consensus regarding the utility one or the other? > > You ought to add UML to the list, since it is useful for > debugging any part of the kernel that's not arch code or a > hardware device driver (except that there's now USB support for > UML). Basically you could add support for ALL generic subsystems, that support dummy hardware, like SCSI and ISDN for example. Is that planned or do I suggest sth. stupid here? ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: [PATCH] adding PCI bus information to SCSI layer
On Mon, Apr 30, 2001 at 07:27:13PM -0600, Richard Gooch wrote: > Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0 What about /dev/bus/pci/0 or /dev/bus/pci/pci0 instead? That way we could hook roots of busses (which are "." nodes, like if they where mounted independently) better into /dev/bus. And even implement the thing as a mount point later, if we go the way Al Viro suggested and have independent "device filesystems" for the subsystems themselves. Just an idea... Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: [PATCH] adding PCI bus information to SCSI layer
On Mon, Apr 30, 2001 at 07:27:13PM -0600, Richard Gooch wrote: Then, vendors provide their own PCI fixups, which turn /dev/bus/pci0 What about /dev/bus/pci/0 or /dev/bus/pci/pci0 instead? That way we could hook roots of busses (which are . nodes, like if they where mounted independently) better into /dev/bus. And even implement the thing as a mount point later, if we go the way Al Viro suggested and have independent device filesystems for the subsystems themselves. Just an idea... Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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 Kernel Debuggers, KDB or KGDB?
On Mon, Apr 30, 2001 at 07:11:35PM -0500, Jeff Dike wrote: [EMAIL PROTECTED] said: Where can I find an analysis of the relative strengths and weaknesses of KDB and KGDB for kernel debug? Has the linux community come to any consensus regarding the utility one or the other? You ought to add UML to the list, since it is useful for debugging any part of the kernel that's not arch code or a hardware device driver (except that there's now USB support for UML). Basically you could add support for ALL generic subsystems, that support dummy hardware, like SCSI and ISDN for example. Is that planned or do I suggest sth. stupid here? ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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.4: Kernel crash, possibly tcp related
On Mon, Apr 30, 2001 at 06:46:33PM +0200, Andrea Arcangeli wrote: > On Sun, Apr 29, 2001 at 11:58:20PM -0700, David S. Miller wrote: > > Andrew Morton writes: > > > "David S. Miller" wrote: > > Anyways, I just tried to reproduce Ralf's problem on two of my > > machines. One was an SMP sparc64 system, and the other was my > > uniprocessor Athlon. > > > > What kind of machine are you reproducing this on Ralf? I'm not > > JFYI: I reproduced too on my UP athlon. I run: > > tcpblast -d0 -s 40481 another_host 9000 > > two times and after the second it locked hard. I didn't had any fork > bomb at the same time but there was an high computing load in the > background. I tried sth. else with 2.4.3-ac13, which could be related: Machine: 1GB RAM, Dual PIII, ServerWorks LE chipset (Asus CUR-DLS board). NIC: [Ethernet Pro 100] (rev 08) (driven by eepro100) 0. Run several kernel compiles and the like to fill up caches. 1. copy an complete iso image into /tmp (which is tmpfs) 2. ftp that over 100Mbit network to an machine. I got a lot of spikes and a message "mm: critical shortage of bounce buffers", while doing 1. And I get a LOT of that messages, while doing 2. But I have a lot of memory in pagecache and only 100MB allocated for other processes. And I still have swap free (I have 2GB of swap as recommended). So could we please check, double check and triple check the allocations in the net layer? Another machine of mine needs now 128MB with the new kernel and will lock up hard otherwise on full saturated 100Mbit network load[1] with TCP, but needed only 32MB before. sth. has to be wrong here... More info on request. I have both machines at hand and they are both ready for testing as long, as my file systems stay repairable by fsck.ext2 ;-) Both machines are not running X, frame buffers and no fancy multi media stuff. Regards Ingo Oeser [1] Tested cards: RTL 8139, Intel Etherexpress Pro 100, 3com 3c509TX, so I guess it's NOT the NIC ;-) -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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.4: Kernel crash, possibly tcp related
On Mon, Apr 30, 2001 at 06:46:33PM +0200, Andrea Arcangeli wrote: On Sun, Apr 29, 2001 at 11:58:20PM -0700, David S. Miller wrote: Andrew Morton writes: David S. Miller wrote: Anyways, I just tried to reproduce Ralf's problem on two of my machines. One was an SMP sparc64 system, and the other was my uniprocessor Athlon. What kind of machine are you reproducing this on Ralf? I'm not JFYI: I reproduced too on my UP athlon. I run: tcpblast -d0 -s 40481 another_host 9000 two times and after the second it locked hard. I didn't had any fork bomb at the same time but there was an high computing load in the background. I tried sth. else with 2.4.3-ac13, which could be related: Machine: 1GB RAM, Dual PIII, ServerWorks LE chipset (Asus CUR-DLS board). NIC: [Ethernet Pro 100] (rev 08) (driven by eepro100) 0. Run several kernel compiles and the like to fill up caches. 1. copy an complete iso image into /tmp (which is tmpfs) 2. ftp that over 100Mbit network to an machine. I got a lot of spikes and a message mm: critical shortage of bounce buffers, while doing 1. And I get a LOT of that messages, while doing 2. But I have a lot of memory in pagecache and only 100MB allocated for other processes. And I still have swap free (I have 2GB of swap as recommended). So could we please check, double check and triple check the allocations in the net layer? Another machine of mine needs now 128MB with the new kernel and will lock up hard otherwise on full saturated 100Mbit network load[1] with TCP, but needed only 32MB before. sth. has to be wrong here... More info on request. I have both machines at hand and they are both ready for testing as long, as my file systems stay repairable by fsck.ext2 ;-) Both machines are not running X, frame buffers and no fancy multi media stuff. Regards Ingo Oeser [1] Tested cards: RTL 8139, Intel Etherexpress Pro 100, 3com 3c509TX, so I guess it's NOT the NIC ;-) -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote: > Ingo Oeser writes: > > There we have 10x faster memmove/memcpy/bzero for 1K blocks > > granularity (== alignment is 1K and size is multiple of 1K), that > > is done by the memory controller. > This sounds different to me. Using the memory controller is (should > be!) a privileged operation, thus it requires a system call. This is > quite different from code in a magic page, which is excuted entirely > in user-space. The point of the magic page is to avoid the syscall > overhead. Yes, but we currently have more than 10K cycles for doing memset of a page. If we do an syscall, we have around 600-900 (don't know exactly), which is still less. The point is: The code in that "magic page" that considers the tradeoff is KERNEL code, which is designed to care about such trade-offs for that machine. Glibc never knows this stuff and shouldn't, because it is already bloated. We get the full win here, for our "compile the kernel for THIS machine to get maximum performance"-strategy. People tend to compile the kernel, but not the glibc. Just let the benchmarks, Linus and Ulrich decide ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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 and 2GB swap partition limit
On Fri, Apr 27, 2001 at 11:40:40PM +0100, Hugh Dickins wrote: > > > An interesting option (though with less-than-stellar performance > > > characteristics) would be a dynamically expanding swapfile. If you're > > > going to be hit with swap penalties, it may be useful to not have to > > > pre-reserve something you only hit once in a great while. > > This makes amazingly little sense since you'd still need to > > pre-reserve the disk space the swapfile grows into. > It makes roughly the same sense as over-committing memory. > Both are useful, both are unreliable. And we have the one, so we should also implement the other one to be totally unreliable. *gd* Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote: > The idea is that the one thing one tends to optimize for new cpus > is the memcpy/memset implementation. What better way to shield > libc from having to be updated for new cpus but to put it into > the kernel in this magic page? Hehe, you have read this MXT patch on linux-mm, too? ;-) There we have 10x faster memmove/memcpy/bzero for 1K blocks granularity (== alignment is 1K and size is multiple of 1K), that is done by the memory controller. This can only be done in the kernel, because it is critical we access here. Good idea. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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.4 breaks dhcpcd with Realtek 8139
On Sat, Apr 28, 2001 at 11:11:51PM +0100, Michael F Gordon wrote: > On Sat, Apr 28, 2001 at 11:29:15AM -0700, David Lang wrote: > > what sort of switch are you plugged into? some Cisco switches have a > > 'feature' that ignores all traffic from a port for X seconds after a > > machine is plugged in / powered on on a port (they claim somehting about > > preventing loops) it may be that the new kernel now boots up faster then > > the old one so that the DHCP request is lost in the switch, a few seconds > > later when you do it by hand the swich has enabled your port and > > everything works. > > I'm plugged in to a cable modem, with the DHCP server at the ISP. The > server requires the MAC address to be registered, so sending the DHCP > request with a different MAC address could cause the symptoms. I doubt > it's a timing problem - replacing the 8139 driver with the 2.4.3 version > but otherwise using the distributed 2.4.4 makes DHCP work as expected. The Windows drivers distributed along with that Realtek cards have this problem[1] any many users of the CSN[2] run into the "secure mode" on our hubs/switches, causing their port to be disabled. So we have just ported a BUG from Windows to Linux, if you are right ;-) BTW: CC'ed the maintainer. He might be interested, as maintainers usally are on BUGs ;-) Regards Ingo Oeser [1] Sometimes forgetting their MAC and sending either random or zero MAC out. This depends on whatever. [2] Chemnitz Students Network - large LAN with >1000 computers -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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.4 breaks dhcpcd with Realtek 8139
On Sat, Apr 28, 2001 at 11:11:51PM +0100, Michael F Gordon wrote: On Sat, Apr 28, 2001 at 11:29:15AM -0700, David Lang wrote: what sort of switch are you plugged into? some Cisco switches have a 'feature' that ignores all traffic from a port for X seconds after a machine is plugged in / powered on on a port (they claim somehting about preventing loops) it may be that the new kernel now boots up faster then the old one so that the DHCP request is lost in the switch, a few seconds later when you do it by hand the swich has enabled your port and everything works. I'm plugged in to a cable modem, with the DHCP server at the ISP. The server requires the MAC address to be registered, so sending the DHCP request with a different MAC address could cause the symptoms. I doubt it's a timing problem - replacing the 8139 driver with the 2.4.3 version but otherwise using the distributed 2.4.4 makes DHCP work as expected. The Windows drivers distributed along with that Realtek cards have this problem[1] any many users of the CSN[2] run into the secure mode on our hubs/switches, causing their port to be disabled. So we have just ported a BUG from Windows to Linux, if you are right ;-) BTW: CC'ed the maintainer. He might be interested, as maintainers usally are on BUGs ;-) Regards Ingo Oeser [1] Sometimes forgetting their MAC and sending either random or zero MAC out. This depends on whatever. [2] Chemnitz Students Network - large LAN with 1000 computers -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote: The idea is that the one thing one tends to optimize for new cpus is the memcpy/memset implementation. What better way to shield libc from having to be updated for new cpus but to put it into the kernel in this magic page? Hehe, you have read this MXT patch on linux-mm, too? ;-) There we have 10x faster memmove/memcpy/bzero for 1K blocks granularity (== alignment is 1K and size is multiple of 1K), that is done by the memory controller. This can only be done in the kernel, because it is critical we access here. Good idea. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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 and 2GB swap partition limit
On Fri, Apr 27, 2001 at 11:40:40PM +0100, Hugh Dickins wrote: An interesting option (though with less-than-stellar performance characteristics) would be a dynamically expanding swapfile. If you're going to be hit with swap penalties, it may be useful to not have to pre-reserve something you only hit once in a great while. This makes amazingly little sense since you'd still need to pre-reserve the disk space the swapfile grows into. It makes roughly the same sense as over-committing memory. Both are useful, both are unreliable. And we have the one, so we should also implement the other one to be totally unreliable. *gdr* Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: X15 alpha release: as fast as TUX but in user space (fwd)
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote: Ingo Oeser writes: There we have 10x faster memmove/memcpy/bzero for 1K blocks granularity (== alignment is 1K and size is multiple of 1K), that is done by the memory controller. This sounds different to me. Using the memory controller is (should be!) a privileged operation, thus it requires a system call. This is quite different from code in a magic page, which is excuted entirely in user-space. The point of the magic page is to avoid the syscall overhead. Yes, but we currently have more than 10K cycles for doing memset of a page. If we do an syscall, we have around 600-900 (don't know exactly), which is still less. The point is: The code in that magic page that considers the tradeoff is KERNEL code, which is designed to care about such trade-offs for that machine. Glibc never knows this stuff and shouldn't, because it is already bloated. We get the full win here, for our compile the kernel for THIS machine to get maximum performance-strategy. People tend to compile the kernel, but not the glibc. Just let the benchmarks, Linus and Ulrich decide ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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/
Negative values of cat /proc/sys/fs/inode-nr
Hi Alan, Hi linux-kernel, I just saw, that cat /proc/sys/fs/inode-nr gives negative values for the second part. 559 -211555 or 174805 -3 I'm using 2.4.3-ac13. I see this both on SMP and non-SMP, HIGHMEM and non-HIGHMEM, if that matters. The first value for the second example (SMP+HIGHMEM machine) also seems a bit large... exact .config or more data available, if needed. Otherwise this kernel is very stable for me, and it feels really good in interactive performance. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: Suggestion for module .init.{text,data} sections
On Thu, Apr 26, 2001 at 09:49:05PM -0700, Adam J. Richter wrote:
> A while ago, on linux-kernel, we had a discussion about
> adding support for __initdata and __init in modules. Somebody
> (whose name escapes me) had implemented it by essentially adding
> a vmrealloc() facility in the kernel. I think I've thought of a
> simpler way, that would require almost no kernel changes.
>
[implementation details snipped]
While you are at this, you could make the .exit.{text,data}
sections swappable for modules (by allocating swappable pages fro
them?) and only mark them unswappable, while the module is
exiting.
Rationale: A device needed for swaping will never call exit
stuff, because it is still in use. So I see no obvious race here.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< been there and had much fun >>>>>>>>>>>>
-
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: Suggestion for module .init.{text,data} sections
On Thu, Apr 26, 2001 at 09:49:05PM -0700, Adam J. Richter wrote:
A while ago, on linux-kernel, we had a discussion about
adding support for __initdata and __init in modules. Somebody
(whose name escapes me) had implemented it by essentially adding
a vmrealloc() facility in the kernel. I think I've thought of a
simpler way, that would require almost no kernel changes.
[implementation details snipped]
While you are at this, you could make the .exit.{text,data}
sections swappable for modules (by allocating swappable pages fro
them?) and only mark them unswappable, while the module is
exiting.
Rationale: A device needed for swaping will never call exit
stuff, because it is still in use. So I see no obvious race here.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
been there and had much fun
-
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/
Negative values of cat /proc/sys/fs/inode-nr
Hi Alan, Hi linux-kernel, I just saw, that cat /proc/sys/fs/inode-nr gives negative values for the second part. 559 -211555 or 174805 -3 I'm using 2.4.3-ac13. I see this both on SMP and non-SMP, HIGHMEM and non-HIGHMEM, if that matters. The first value for the second example (SMP+HIGHMEM machine) also seems a bit large... exact .config or more data available, if needed. Otherwise this kernel is very stable for me, and it feels really good in interactive performance. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: ramdisk/tmpfs/ramfs/memfs ?
On Thu, Apr 26, 2001 at 01:49:05PM -0700, H. Peter Anvin wrote: > > > 5. Can you set size limits on ramfs/tmpfs/memfs? Yes, there is a patch for this. > > i don't think you can set a limit in the current ramfs implementation but > > it would not be particularly difficult to make it work I think > It's a little more painful than you'd think for the simple reason that > ramfs currently contains no space accounting whatsoever, which > probably is a bad thing. It definitely gave me some serious pause > when I was working on SuperRescue 1.3, since I had no way of > reasonably judging how big my ramfs actually was. The only way I > could get a reasonable idea was rebooting with various mem= > parameters. The patched variant gives to all of it. Even several kinds of limits (inodes, dentries, ram pages). I use this patch in production. The ac-Kernels all have this patch included, which are sometimes more stable anyway these day. ;-) HTH Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: PATCH: 2.4.3 tinny module interface cleanum
On Thu, Apr 26, 2001 at 10:58:46AM +0200, Martin Dalecki wrote: > 1. Help making the module interface cleaner by a tinny margin :-). You only help changing the API during a stable[1] series. Wait until 2.5 for this. API cannot change during stable series. (ABI can, BTW) So lets just forget about this, ok ;-) Regards Ingo Oeser [1] By stable I mean "marked as the stable branch" not the actual behavior >;) -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: PATCH: 2.4.3 tinny module interface cleanum
On Thu, Apr 26, 2001 at 10:58:46AM +0200, Martin Dalecki wrote: 1. Help making the module interface cleaner by a tinny margin :-). You only help changing the API during a stable[1] series. Wait until 2.5 for this. API cannot change during stable series. (ABI can, BTW) So lets just forget about this, ok ;-) Regards Ingo Oeser [1] By stable I mean marked as the stable branch not the actual behavior ;) -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: ramdisk/tmpfs/ramfs/memfs ?
On Thu, Apr 26, 2001 at 01:49:05PM -0700, H. Peter Anvin wrote: 5. Can you set size limits on ramfs/tmpfs/memfs? Yes, there is a patch for this. i don't think you can set a limit in the current ramfs implementation but it would not be particularly difficult to make it work I think It's a little more painful than you'd think for the simple reason that ramfs currently contains no space accounting whatsoever, which probably is a bad thing. It definitely gave me some serious pause when I was working on SuperRescue 1.3, since I had no way of reasonably judging how big my ramfs actually was. The only way I could get a reasonable idea was rebooting with various mem= parameters. The patched variant gives to all of it. Even several kinds of limits (inodes, dentries, ram pages). I use this patch in production. The ac-Kernels all have this patch included, which are sometimes more stable anyway these day. ;-) HTH Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: down_timeout
On Wed, Apr 25, 2001 at 04:21:22PM -0700, Grover, Andrew wrote:
> It seems like we need to implement down_timeout (and
> down_timeout_interruptible) to fully flesh out the semaphore implementation.
> It is difficult and inefficient to emulate this using wrapper functions, as
> far as I can see.
>
> Seems like this is a fairly standard interface to have for OS semaphores. We
> have a prototype implementation, and could contribute this, if desired.
>
> Thoughts?
Sure you can't implement this via waitqueues? semaphores use them
internally anyway.
I use this for interrupt or polling based waiting:
/* IO polling waits */
/* Timeout after this amount of jiffies */
#define IO_POLL_TIMEOUT (HZ)
/* Split timeout while polling into chunks of that many jiffies */
#define IO_POLL_SPLIT 2
/* generic interrupt based wait with timeouts! */
#define __wait_event_timeout_int(wq, condition, timeout, ret) \
do { \
struct wait_queue __wait; \
signed long __expire=timeout; \
__wait.task=current; \
add_wait_queue(wq, &__wait); \
for (;;) { \
current->state=TASK_UNINTERRUPTIBLE; \
mb(); \
if (condition) break; \
__expire=schedule_timeout(__expire); \
if (__expire == 0) { \
ret=-ETIMEDOUT; \
break; \
} \
} \
current->state = TASK_RUNNING; \
remove_wait_queue(wq, &__wait); \
} while (0)
/* polling wait, if we shouldn't use interrupts for this */
#define __wait_event_timeout_poll(wq, condition, timeout, ret) \
do { \
unsigned int __tries=0; \
unsigned int __maxtry=timeout / IO_POLL_SPLIT; \
do { \
schedule_timeout(IO_POLL_SPLIT); \
if (condition) \
break; \
} while (++__tries < __maxtry); \
if (__tries == __maxtry && !condition) \
ret=-ETIMEDOUT; \
} while (0)
#ifdef INTS_ARE_CHEAP
#define __wait_event_timeout(wq, condition, timeout, ret) \
__wait_event_timeout_int(wq, condition, timeout, ret)
#else /* INTS_ARE_CHEAP */
#define __wait_event_timeout(wq, condition, timeout, ret) \
__wait_event_timeout_poll(wq, condition, timeout, ret)
#endif /* INTS_ARE_CHEAP */
#define wait_event_timeout(wq, condition, timeout, ret) \
do { \
if (condition) \
break; \
__wait_event_timeout(wq, condition, timeout, ret); \
} while (0)
What about that?
Use it just as you use wait_event() but check for -ETIMEDOUT as
value in ret.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< been there and had much fun >>>>>>>>>>>>
-
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: Problem with DHCP when using tokenring on 2.4.x
On Tue, Apr 24, 2001 at 06:30:59PM +0530, [EMAIL PROTECTED] wrote: >I have a problem with DHCP when using tokenring card on 2.4.x > kernel . When I am using IBM tokenring adapter( all) and trying to hook on > to the lan n/w using DHCP ,I get an error message "operation failed " from > the dhcp client . The dhcp server is getting the broadcast message when the > dhcp client is run. I am using pump that comes with 6.2 redhat > distribution . Try at least stracing pump and find out _which_ operation fails. Then find out where in the source there are messages "operation failed" and whatever messages are around that message and compare these positions with the call trace you get from strace and an static analysis of the code paths leading to this message. As a last resort try to run a debugger over pump (you have to rebuild it without optimization and with debugging symbols). This sounds like an user space problem until now, but once you tried all this, we can decide whether it is a kernel bug or a bug in pump, which got triggered by more correct behavior of the lastest kernels. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: Problem with DHCP when using tokenring on 2.4.x
On Tue, Apr 24, 2001 at 06:30:59PM +0530, [EMAIL PROTECTED] wrote: I have a problem with DHCP when using tokenring card on 2.4.x kernel . When I am using IBM tokenring adapter( all) and trying to hook on to the lan n/w using DHCP ,I get an error message operation failed from the dhcp client . The dhcp server is getting the broadcast message when the dhcp client is run. I am using pump that comes with 6.2 redhat distribution . Try at least stracing pump and find out _which_ operation fails. Then find out where in the source there are messages operation failed and whatever messages are around that message and compare these positions with the call trace you get from strace and an static analysis of the code paths leading to this message. As a last resort try to run a debugger over pump (you have to rebuild it without optimization and with debugging symbols). This sounds like an user space problem until now, but once you tried all this, we can decide whether it is a kernel bug or a bug in pump, which got triggered by more correct behavior of the lastest kernels. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: down_timeout
On Wed, Apr 25, 2001 at 04:21:22PM -0700, Grover, Andrew wrote:
It seems like we need to implement down_timeout (and
down_timeout_interruptible) to fully flesh out the semaphore implementation.
It is difficult and inefficient to emulate this using wrapper functions, as
far as I can see.
Seems like this is a fairly standard interface to have for OS semaphores. We
have a prototype implementation, and could contribute this, if desired.
Thoughts?
Sure you can't implement this via waitqueues? semaphores use them
internally anyway.
I use this for interrupt or polling based waiting:
/* IO polling waits */
/* Timeout after this amount of jiffies */
#define IO_POLL_TIMEOUT (HZ)
/* Split timeout while polling into chunks of that many jiffies */
#define IO_POLL_SPLIT 2
/* generic interrupt based wait with timeouts! */
#define __wait_event_timeout_int(wq, condition, timeout, ret) \
do { \
struct wait_queue __wait; \
signed long __expire=timeout; \
__wait.task=current; \
add_wait_queue(wq, __wait); \
for (;;) { \
current-state=TASK_UNINTERRUPTIBLE; \
mb(); \
if (condition) break; \
__expire=schedule_timeout(__expire); \
if (__expire == 0) { \
ret=-ETIMEDOUT; \
break; \
} \
} \
current-state = TASK_RUNNING; \
remove_wait_queue(wq, __wait); \
} while (0)
/* polling wait, if we shouldn't use interrupts for this */
#define __wait_event_timeout_poll(wq, condition, timeout, ret) \
do { \
unsigned int __tries=0; \
unsigned int __maxtry=timeout / IO_POLL_SPLIT; \
do { \
schedule_timeout(IO_POLL_SPLIT); \
if (condition) \
break; \
} while (++__tries __maxtry); \
if (__tries == __maxtry !condition) \
ret=-ETIMEDOUT; \
} while (0)
#ifdef INTS_ARE_CHEAP
#define __wait_event_timeout(wq, condition, timeout, ret) \
__wait_event_timeout_int(wq, condition, timeout, ret)
#else /* INTS_ARE_CHEAP */
#define __wait_event_timeout(wq, condition, timeout, ret) \
__wait_event_timeout_poll(wq, condition, timeout, ret)
#endif /* INTS_ARE_CHEAP */
#define wait_event_timeout(wq, condition, timeout, ret) \
do { \
if (condition) \
break; \
__wait_event_timeout(wq, condition, timeout, ret); \
} while (0)
What about that?
Use it just as you use wait_event() but check for -ETIMEDOUT as
value in ret.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
been there and had much fun
-
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: hundreds of mount --bind mountpoints?
On Tue, Apr 24, 2001 at 02:49:23PM -0400, Alexander Viro wrote: > On Tue, 24 Apr 2001, Andreas Dilger wrote: > > One thing to watch out for is that the current code zeros the u. struct > > for us (as you pointed out to me previously), but allocating from the > > slab cache will not... This could be an interesting source of bugs for > > some filesystems that assume zero'd inode_info structs. > True, but easy to catch. Jepp. Just request SLAB_ZERO (still to be implemented) instead of SLAB_POISON or provide an constructor. A nice set of macros for this would make it quite easy. The ctor is the way to handle it. May be we could even put all the fs specific initalizers into it (e.g. magics, zeroes). Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: hundreds of mount --bind mountpoints?
On Tue, Apr 24, 2001 at 02:49:23PM -0400, Alexander Viro wrote: On Tue, 24 Apr 2001, Andreas Dilger wrote: One thing to watch out for is that the current code zeros the u. struct for us (as you pointed out to me previously), but allocating from the slab cache will not... This could be an interesting source of bugs for some filesystems that assume zero'd inode_info structs. True, but easy to catch. Jepp. Just request SLAB_ZERO (still to be implemented) instead of SLAB_POISON or provide an constructor. A nice set of macros for this would make it quite easy. The ctor is the way to handle it. May be we could even put all the fs specific initalizers into it (e.g. magics, zeroes). Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: hundreds of mount --bind mountpoints?
On Mon, Apr 23, 2001 at 10:56:16PM +0200, Christoph Hellwig wrote: > In article <[EMAIL PROTECTED]> you wrote: > > Last time we suggested this, people ended up with some OS trying > > it and getting worse performance. > > Which OS? Neither BSD nor SVR4/SVR5 (or even SVR3) do that. Don't remember. I think Larry McVoy told the story, so I cc'ed him ;-) > Because having an union in generic code that includes filesystem-specific > memebers is ugly? It's one of those a little more performance for a lot of > bad style optimizations. We have this kind of stuff all over the place. If we allocate some small amount of memory and and need some small amount associated with this memory, there is no problem with a little waste. Waste is better than fragmentation. This is the lesson people learned from segments in the ia32. Objects are easier to manage, if they are the same size. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: ioctl arg passing
On Mon, Apr 23, 2001 at 08:58:54PM +0100, Matt wrote: > Matt aka Doofus festures mentioned the following: > > | struct instruction_t local; > | __s16 *temp; > | > | copy_from_user( , ( struct instruction_t * ) arg, sizeof( struct >instruction_t ) ); > | temp = kmalloc( sizeof( __s16 ) * local.rxlen, GFP_KERNEL ); > | copy_from_user( temp, arg, sizeof( __s16 ) * local.rxlen ); > > I meant that last line to be: > > copy_from_user( temp, local.rxbuf, sizeof( __s16 ) * local.rxlen ); > ^^^ > That's the main crux of my query, can I retrieve the value of a pointer > in some struct passed via ioctl? In this case, the struct/chunk of memory > referenced by local.rxbuf, (which is rxlen x 2 bytes big). Yes, that works (with the obvious note on checking argument sizes and not kmallocing too much memory). All "read" functions do the same. As you were clever enough to copy the pointer itself into kernel space, too (which many driver writes forget!), you have done the right thing here. Congratulations! ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: hundreds of mount --bind mountpoints?
On Mon, Apr 23, 2001 at 11:36:24AM -0400, Alexander Viro wrote: > > Great idea. We allocate this space anyway. And we don't have to > > care about the internals of this union, because never have to use > > it outside the kernel ;-) > > > > I like it. ext2fs does the same, so there should be no VFS > > hassles involved. Al? > > We should get ext2 and friends to move the sucker _out_ of struct inode. > As it is, sizeof(struct inode) is way too large. This is 2.5 stuff, but > it really has to be done. More filesystems adding stuff into the union > is a Bad Thing(tm). If you want to allocates space - allocate if yourself; > ->clear_inode() is the right place for freeing it. You need an inode anyway. So why not using the space in it? tmpfs would only use sizeof(*inode.u)-sizeof(struct shmem_inode_info) for this kind of symlinks. Last time we suggested this, people ended up with some OS trying it and getting worse performance. Why? You need to allocate the VFS-inode (vnode in other OSs) and the on-disk-inode anyway at the same time. You get better performance and less fragmentation, if you allocate them both together[1]. So that struct inode around is ok. BTW: Is it still less than one page? Then it doesn't make me nervous. Why? Guess what granularity we allocate at, if we just store pointers instead of the inode.u. Or do you like every FS creating his own slab cache? Regards Ingo Oeser [1] Which is true for other allocations, too. -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: light weight user level semaphores
On Thu, Apr 19, 2001 at 09:46:17AM -0700, Linus Torvalds wrote: > > libc is entitled to, and most definitely does exactly that. Take a look at > > things like gethostent, getpwent etc etc. > > Ehh.. I will bet you $10 USD that if libc allocates the next file > descriptor on the first "malloc()" in user space (in order to use the > semaphores for mm protection), programs _will_ break. But we would not open the semaphore on malloc() but instead in the init functions of the libc. So the semaphore will be already allocated. May be dup2()ed to some very high range (INT_MAX-__GLIBC_MALLOC_SEM_FD) and the original fd closed. So this will be no real problem. That's why I don't like lazy init: May be you cannot init anymore, if you come to and condition, where you would need it. Also init/fini are usally very slow operations and as many things as possible are burdend onto their shoulders. Semaphores tend to be structures living very long (at least in all code I've written and seen so far) so I see no point in defering their initialization. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: Can't compile 2.4.3 with agcc
On Mon, Apr 23, 2001 at 04:52:53PM +0100, David Woodhouse wrote:
> RCS file: /inst/cvs/linux/include/asm-i386/bugs.h,v
> retrieving revision 1.2.2.16
> diff -u -r1.2.2.16 bugs.h
> --- include/asm/bugs.h2001/01/18 13:56:53 1.2.2.16
> +++ include/asm/bugs.h2001/04/23 15:45:28
> @@ -80,8 +80,10 @@
>* Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
>*/
> if (offsetof(struct task_struct, thread.i387.fxsave) & 15) {
> - extern void __buggy_fxsr_alignment(void);
> - __buggy_fxsr_alignment();
> + printk(KERN_EMERG "ERROR: FXSAVE data are not 16-byte aligned in
>task_struct.\n");
> + printk(KERN_EMERG "This is usually caused by a buggy compiler (perhaps
>pgcc?)\n");
> + printk(KERN_EMERG "Cannot continue.\n");
> + for (;;) ;
replace this with panic() please. Even machines, which reboot on
panic will reboot over and over again here, which surely someone
will notice ;-)
> }
> if (cpu_has_fxsr) {
> printk(KERN_INFO "Enabling fast FPU save and restore... ");
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< been there and had much fun >>>>>>>>>>>>
-
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: ioctl arg passing
On Mon, Apr 23, 2001 at 05:06:48PM +0100, Matt wrote:
> I'm writing a char device driver for a dsp card that drives a motion
> platform.
Can you elaborate on the dsp card? Is it freely programmable? I'm
working on a project to support this kind of stuff via a
dedicated subsystem for Linux.
The problem is, that it's hard to get access to such cards. So
development is moving very slow :-(
> To pass the instructions I'm using a generic ioctl which passes the data
> between user & kernel-space using a struct which is basically like:
>
> struct instruction_t {
> __s16 code;
> __s16 rxlen;
> __s16 *rxbuf;
> __s16 txlen;
> __s16 *txbuf;
> };
Such stuff is handled already by my subsystem. You just have to
provide some function to do some checks on memory buffers
(readable, writeable, executable, unreachable, properly aligned
and sized transfer unit and so on) and functions for transfers
(which can be sych/asych), ioctls and and debugging interface for
special purposes.
> (rx|tx)len is the length of the extra data that is provided/requested
> in/to be in (rx|tx)buf. Got me so far?
>
> Am I allowed to do this across the ioctl interface? In my ioctl
> "handler" I'm attempting to do:
>
> --8<--
>
> struct instruction_t local;
> __s16 *temp;
>
> copy_from_user( , ( struct instruction_t * ) arg, sizeof( struct instruction_t
>) );
> temp = kmalloc( sizeof( __s16 ) * local.rxlen, GFP_KERNEL );
> copy_from_user( temp, arg, sizeof( __s16 ) * local.rxlen );
> local.rxbuf = temp;
> temp = kmalloc( sizeof( __s16 ) * local.txlen, GFP_KERNEL );
>
>
> --8<--
>
> Is this going to work as expected? Or am I gonna generate oops-a-plenty?
What do you want to do with the buffers? If you plan to expose
them to user space, this is just plain wrong.
If you use it only inside the kernel, please check that you avoid
using more than PAGE_SIZE as rxlen/txlen. Do scatter-gather
instead and vmalloc(). Either in the driver or by hardware
features.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< been there and had much fun >>>>>>>>>>>>
-
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: hundreds of mount --bind mountpoints?
Hi Chris, On Mon, Apr 23, 2001 at 04:54:02PM +0200, Christoph Rohland wrote: > > The question is: How? If you do it like ramfs, you cannot swap > > these symlinks and this is effectively a mlock(symlink) operation > > allowed for normal users. -> BAD! > > How about storing it into the inode structure if it fits into the > fs-private union? If it is too big we allocate the page as we do it > now. The union has 192 bytes. This should be sufficient for most > cases. Great idea. We allocate this space anyway. And we don't have to care about the internals of this union, because never have to use it outside the kernel ;-) I like it. ext2fs does the same, so there should be no VFS hassles involved. Al? Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: hundreds of mount --bind mountpoints?
On Mon, Apr 23, 2001 at 01:43:27PM +0200, Christoph Rohland wrote: > On Sun, 22 Apr 2001, David L. Parsley wrote: > > attach packages inside it. Since symlinks in a tmpfs filesystem > > cost 4k each (ouch!), I'm considering using mount --bind for > > everything. > > What about fixing tmpfs instead? The question is: How? If you do it like ramfs, you cannot swap these symlinks and this is effectively a mlock(symlink) operation allowed for normal users. -> BAD! One idea is to only use a page, if the entry will be pushed into swap and thus only wasting swap, not memory (where we have more of it). But allocating a page on memory pressure is also not a bright idea. OTOH we could force this entry to swap immedately, after we copied it from the dentry. So we can do an GFP_ATOMIC allocation and do not too much harm to memory pressure and only make the IO a bit stormier. I think there are a lot of races, which I don't see now. So please don't beat me too much, if this is a completly stupid idea, ok? ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: disable_ide_dma gcc-3.0 warn
On Mon, Apr 23, 2001 at 11:07:53AM +0200, J . A . Magallon wrote:
> In dmi_scan.c there is the func:
> static __init int disable_ide_dma(struct dmi_blacklist *d)
>
> But now it is unused (intentionally ?):
>
> static __initdata struct dmi_blacklist dmi_blacklist[]={
> #if 0<==
> { disable_ide_dma, "KT7", { /* Overbroad right now - kill DMA on problem KT7
> boards */
> MATCH(DMI_PRODUCT_NAME, "KT7-RAID"),
> NO_MATCH, NO_MATCH, NO_MATCH
> } },
> #endif
I guess this is a leftover from the VIA buggy southbridge workaround hunt.
Code marked with "#if 0" and "#if 1" is usally under
development and subject to changes.
Or left intentionally in "#if 0" to show the reader that we had
an wrong idea once, which seemed to be obviously correct (may be
from the docs) and we solved it with a different method, which is
not obvious or even not stated in the docs, but is the right one.
So we avoid stupid patches by leaving such things for reference.
In short: Don't care about new dead code too much, if it will be
needed by a "#if 0" marked code section.
BTW: Which revision of gcc 3.0 do you use? I had no luck compiling
it yet. Please answer in private to gcc issues.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< been there and had much fun >>>>>>>>>>>>
-
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: disable_ide_dma gcc-3.0 warn
On Mon, Apr 23, 2001 at 11:07:53AM +0200, J . A . Magallon wrote:
In dmi_scan.c there is the func:
static __init int disable_ide_dma(struct dmi_blacklist *d)
But now it is unused (intentionally ?):
static __initdata struct dmi_blacklist dmi_blacklist[]={
#if 0==
{ disable_ide_dma, KT7, { /* Overbroad right now - kill DMA on problem KT7
boards */
MATCH(DMI_PRODUCT_NAME, KT7-RAID),
NO_MATCH, NO_MATCH, NO_MATCH
} },
#endif
I guess this is a leftover from the VIA buggy southbridge workaround hunt.
Code marked with #if 0 and #if 1 is usally under
development and subject to changes.
Or left intentionally in #if 0 to show the reader that we had
an wrong idea once, which seemed to be obviously correct (may be
from the docs) and we solved it with a different method, which is
not obvious or even not stated in the docs, but is the right one.
So we avoid stupid patches by leaving such things for reference.
In short: Don't care about new dead code too much, if it will be
needed by a #if 0 marked code section.
BTW: Which revision of gcc 3.0 do you use? I had no luck compiling
it yet. Please answer in private to gcc issues.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
been there and had much fun
-
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: hundreds of mount --bind mountpoints?
Hi Chris, On Mon, Apr 23, 2001 at 04:54:02PM +0200, Christoph Rohland wrote: The question is: How? If you do it like ramfs, you cannot swap these symlinks and this is effectively a mlock(symlink) operation allowed for normal users. - BAD! How about storing it into the inode structure if it fits into the fs-private union? If it is too big we allocate the page as we do it now. The union has 192 bytes. This should be sufficient for most cases. Great idea. We allocate this space anyway. And we don't have to care about the internals of this union, because never have to use it outside the kernel ;-) I like it. ext2fs does the same, so there should be no VFS hassles involved. Al? Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: ioctl arg passing
On Mon, Apr 23, 2001 at 05:06:48PM +0100, Matt wrote:
I'm writing a char device driver for a dsp card that drives a motion
platform.
Can you elaborate on the dsp card? Is it freely programmable? I'm
working on a project to support this kind of stuff via a
dedicated subsystem for Linux.
The problem is, that it's hard to get access to such cards. So
development is moving very slow :-(
To pass the instructions I'm using a generic ioctl which passes the data
between user kernel-space using a struct which is basically like:
struct instruction_t {
__s16 code;
__s16 rxlen;
__s16 *rxbuf;
__s16 txlen;
__s16 *txbuf;
};
Such stuff is handled already by my subsystem. You just have to
provide some function to do some checks on memory buffers
(readable, writeable, executable, unreachable, properly aligned
and sized transfer unit and so on) and functions for transfers
(which can be sych/asych), ioctls and and debugging interface for
special purposes.
(rx|tx)len is the length of the extra data that is provided/requested
in/to be in (rx|tx)buf. Got me so far?
Am I allowed to do this across the ioctl interface? In my ioctl
handler I'm attempting to do:
--8--
struct instruction_t local;
__s16 *temp;
copy_from_user( local, ( struct instruction_t * ) arg, sizeof( struct instruction_t
) );
temp = kmalloc( sizeof( __s16 ) * local.rxlen, GFP_KERNEL );
copy_from_user( temp, arg, sizeof( __s16 ) * local.rxlen );
local.rxbuf = temp;
temp = kmalloc( sizeof( __s16 ) * local.txlen, GFP_KERNEL );
--8--
Is this going to work as expected? Or am I gonna generate oops-a-plenty?
What do you want to do with the buffers? If you plan to expose
them to user space, this is just plain wrong.
If you use it only inside the kernel, please check that you avoid
using more than PAGE_SIZE as rxlen/txlen. Do scatter-gather
instead and vmalloc(). Either in the driver or by hardware
features.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
been there and had much fun
-
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: Can't compile 2.4.3 with agcc
On Mon, Apr 23, 2001 at 04:52:53PM +0100, David Woodhouse wrote:
RCS file: /inst/cvs/linux/include/asm-i386/bugs.h,v
retrieving revision 1.2.2.16
diff -u -r1.2.2.16 bugs.h
--- include/asm/bugs.h2001/01/18 13:56:53 1.2.2.16
+++ include/asm/bugs.h2001/04/23 15:45:28
@@ -80,8 +80,10 @@
* Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
*/
if (offsetof(struct task_struct, thread.i387.fxsave) 15) {
- extern void __buggy_fxsr_alignment(void);
- __buggy_fxsr_alignment();
+ printk(KERN_EMERG ERROR: FXSAVE data are not 16-byte aligned in
task_struct.\n);
+ printk(KERN_EMERG This is usually caused by a buggy compiler (perhaps
pgcc?)\n);
+ printk(KERN_EMERG Cannot continue.\n);
+ for (;;) ;
replace this with panic() please. Even machines, which reboot on
panic will reboot over and over again here, which surely someone
will notice ;-)
}
if (cpu_has_fxsr) {
printk(KERN_INFO Enabling fast FPU save and restore... );
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
been there and had much fun
-
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: hundreds of mount --bind mountpoints?
On Mon, Apr 23, 2001 at 11:36:24AM -0400, Alexander Viro wrote: Great idea. We allocate this space anyway. And we don't have to care about the internals of this union, because never have to use it outside the kernel ;-) I like it. ext2fs does the same, so there should be no VFS hassles involved. Al? We should get ext2 and friends to move the sucker _out_ of struct inode. As it is, sizeof(struct inode) is way too large. This is 2.5 stuff, but it really has to be done. More filesystems adding stuff into the union is a Bad Thing(tm). If you want to allocates space - allocate if yourself; -clear_inode() is the right place for freeing it. You need an inode anyway. So why not using the space in it? tmpfs would only use sizeof(*inode.u)-sizeof(struct shmem_inode_info) for this kind of symlinks. Last time we suggested this, people ended up with some OS trying it and getting worse performance. Why? You need to allocate the VFS-inode (vnode in other OSs) and the on-disk-inode anyway at the same time. You get better performance and less fragmentation, if you allocate them both together[1]. So that struct inode around is ok. BTW: Is it still less than one page? Then it doesn't make me nervous. Why? Guess what granularity we allocate at, if we just store pointers instead of the inode.u. Or do you like every FS creating his own slab cache? Regards Ingo Oeser [1] Which is true for other allocations, too. -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: ioctl arg passing
On Mon, Apr 23, 2001 at 08:58:54PM +0100, Matt wrote: Matt aka Doofus festures mentioned the following: | struct instruction_t local; | __s16 *temp; | | copy_from_user( local, ( struct instruction_t * ) arg, sizeof( struct instruction_t ) ); | temp = kmalloc( sizeof( __s16 ) * local.rxlen, GFP_KERNEL ); | copy_from_user( temp, arg, sizeof( __s16 ) * local.rxlen ); I meant that last line to be: copy_from_user( temp, local.rxbuf, sizeof( __s16 ) * local.rxlen ); ^^^ That's the main crux of my query, can I retrieve the value of a pointer in some struct passed via ioctl? In this case, the struct/chunk of memory referenced by local.rxbuf, (which is rxlen x 2 bytes big). Yes, that works (with the obvious note on checking argument sizes and not kmallocing too much memory). All read functions do the same. As you were clever enough to copy the pointer itself into kernel space, too (which many driver writes forget!), you have done the right thing here. Congratulations! ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: hundreds of mount --bind mountpoints?
On Mon, Apr 23, 2001 at 10:56:16PM +0200, Christoph Hellwig wrote: In article [EMAIL PROTECTED] you wrote: Last time we suggested this, people ended up with some OS trying it and getting worse performance. Which OS? Neither BSD nor SVR4/SVR5 (or even SVR3) do that. Don't remember. I think Larry McVoy told the story, so I cc'ed him ;-) Because having an union in generic code that includes filesystem-specific memebers is ugly? It's one of those a little more performance for a lot of bad style optimizations. We have this kind of stuff all over the place. If we allocate some small amount of memory and and need some small amount associated with this memory, there is no problem with a little waste. Waste is better than fragmentation. This is the lesson people learned from segments in the ia32. Objects are easier to manage, if they are the same size. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: APIC-Errors+Crashes on GA 586DX, 2.2.17/2.4.3
On Sun, Apr 22, 2001 at 11:22:24AM +0200, Hermann Himmelbauer wrote: > Karsten Keil wrote: > > > > I have here the same board with 2*233 MMX and don't see this kind of ISDN > > error on recent 2.2 kernels, but got also lot of APIC errors with the > > 2.3/2.4, because the APIC errors are only reported in 2.3/4. > > Right - same behavior here, no APIC errors with 2.2 (as they are not > reported). The ISDN error happens very seldom (4 times last year) and is > not reproducable - which is not so with the eth0 errors (as eth0 locks > at around 500-1000MB while copying data). I had a similar problem, but with less RAM than you have, I think. And it hung the whole machine that heavy, that not even SysRq was responding. On that machine I had no swap installed and only 64MB of RAM. Adding just another 64MB of RAM made it go away. This might be an VM-skb-interaction-issue, but I saw no solution so far. The problem persistent with several processor (Cyrix III, Intel Pentium (MXX), AMD Duron), several Chipsets (VIA-598, Intel BX) and 3 different NICs (Realtek 8139, 3c509TX, Ether Express Pro) and only under 100MBit. I could copy MANY files (smb, scp, ftp), but ONE single file with about 60MB or more (I tried to receive ISO images) killed the machine. The behavior was also very random. Twice I got a panic, but had problems writing it down due to the screen darkening because of APM or setting "reboot on panic" :-( Just FYI. I don't know, why adding 64MB made it go away. I tried very hard to reproduce it with 128MB, but really couldn't :-( Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: APIC-Errors+Crashes on GA 586DX, 2.2.17/2.4.3
On Sun, Apr 22, 2001 at 11:22:24AM +0200, Hermann Himmelbauer wrote: Karsten Keil wrote: I have here the same board with 2*233 MMX and don't see this kind of ISDN error on recent 2.2 kernels, but got also lot of APIC errors with the 2.3/2.4, because the APIC errors are only reported in 2.3/4. Right - same behavior here, no APIC errors with 2.2 (as they are not reported). The ISDN error happens very seldom (4 times last year) and is not reproducable - which is not so with the eth0 errors (as eth0 locks at around 500-1000MB while copying data). I had a similar problem, but with less RAM than you have, I think. And it hung the whole machine that heavy, that not even SysRq was responding. On that machine I had no swap installed and only 64MB of RAM. Adding just another 64MB of RAM made it go away. This might be an VM-skb-interaction-issue, but I saw no solution so far. The problem persistent with several processor (Cyrix III, Intel Pentium (MXX), AMD Duron), several Chipsets (VIA-598, Intel BX) and 3 different NICs (Realtek 8139, 3c509TX, Ether Express Pro) and only under 100MBit. I could copy MANY files (smb, scp, ftp), but ONE single file with about 60MB or more (I tried to receive ISO images) killed the machine. The behavior was also very random. Twice I got a panic, but had problems writing it down due to the screen darkening because of APM or setting "reboot on panic" :-( Just FYI. I don't know, why adding 64MB made it go away. I tried very hard to reproduce it with 128MB, but really couldn't :-( Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: cdrom driver dependency problem (and a workaround patch)
On Sat, Apr 21, 2001 at 08:33:05PM +0300, Dan Aloni wrote: > On Sat, 21 Apr 2001, Ingo Oeser wrote: > > The link order is wrong. So why not changing the link order then? > > I remember doing what the patch below does. > It didn't help. Hmm, maybe you had a typo? > Did you try this patch? Yes, just booted an SMP machine with 2.4.3-ac11 and this patch. I booted remote, so it was some kind of dangerous, if it wouldn't work ;-) We also have SCSI enabled there. So it really works ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: rwsem.o listed twice as export-objs
On Sat, Apr 21, 2001 at 06:06:34PM +0200, Christoph Hellwig wrote: > In article <[EMAIL PROTECTED]> you wrote: > > please remove rwsem.o from the list of exported objects, if it is > > not used. > > No! The whole point of 'export-objs' is to _always_ list the objects there > to make the makefiles smaller and cleaner. Ok, so this patch is better? --- linux/lib/Makefile.orig Sat Apr 21 20:15:00 2001 +++ linux/lib/MakefileSat Apr 21 20:14:37 2001 @@ -8,12 +8,11 @@ L_TARGET := lib.a export-objs := cmdline.o rwsem.o obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o bust_spinlocks.o ifneq ($(CONFIG_RWSEM_GENERIC_SPINLOCK)$(CONFIG_RWSEM_XCHGADD_ALGORITHM),nn) -export-objs += rwsem.o obj-y += rwsem.o endif Because any of the solutions should be applied, because rwsem.o is listed twice currently, which gives a warning at compile time. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: cdrom driver dependency problem (and a workaround patch)
On Sat, Apr 21, 2001 at 02:17:18AM +0300, Dan Aloni wrote: > One reason for this misdependency is that the IDE is initialized before > the cdrom driver, register_cdrom() gets called from inside the IDE > initialization functions. (ide_init() -> ide_init_builtin_drivers() -> > ide_cdrom_init() -> ide_cdrom_setup() -> ide_cdrom_register() -> > register_cdrom()) > > In order to get my kernel to boot, I've made the following temporary > workaround patch. I'd be glad to hear about other ways of solving this. The link order is wrong. So why not changing the link order then? --- Makefile.orig Sat Apr 21 12:34:34 2001 +++ MakefileSat Apr 21 12:35:12 2001 @@ -149,15 +149,15 @@ DRIVERS-$(CONFIG_WAN) += drivers/net/wan/wan.o DRIVERS-$(CONFIG_ARCNET) += drivers/net/arcnet/arcnetdrv.o DRIVERS-$(CONFIG_ATM) += drivers/atm/atm.o -DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o -DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o -DRIVERS-$(CONFIG_FUSION_BOOT) += drivers/message/fusion/fusion.o -DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394drv.o ifneq ($(CONFIG_CD_NO_IDESCSI)$(CONFIG_BLK_DEV_IDECD)$(CONFIG_BLK_DEV_SR)$(CONFIG_PARIDE_PCD),) DRIVERS-y += drivers/cdrom/driver.o endif +DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o +DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o +DRIVERS-$(CONFIG_FUSION_BOOT) += drivers/message/fusion/fusion.o +DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394drv.o DRIVERS-$(CONFIG_SOUND) += drivers/sound/sounddrivers.o DRIVERS-$(CONFIG_PCI) += drivers/pci/driver.o DRIVERS-$(CONFIG_MTD) += drivers/mtd/mtdlink.o Would be my idea of solving this issue. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: cdrom driver dependency problem (and a workaround patch)
On Sat, Apr 21, 2001 at 02:17:18AM +0300, Dan Aloni wrote: One reason for this misdependency is that the IDE is initialized before the cdrom driver, register_cdrom() gets called from inside the IDE initialization functions. (ide_init() - ide_init_builtin_drivers() - ide_cdrom_init() - ide_cdrom_setup() - ide_cdrom_register() - register_cdrom()) In order to get my kernel to boot, I've made the following temporary workaround patch. I'd be glad to hear about other ways of solving this. The link order is wrong. So why not changing the link order then? --- Makefile.orig Sat Apr 21 12:34:34 2001 +++ MakefileSat Apr 21 12:35:12 2001 @@ -149,15 +149,15 @@ DRIVERS-$(CONFIG_WAN) += drivers/net/wan/wan.o DRIVERS-$(CONFIG_ARCNET) += drivers/net/arcnet/arcnetdrv.o DRIVERS-$(CONFIG_ATM) += drivers/atm/atm.o -DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o -DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o -DRIVERS-$(CONFIG_FUSION_BOOT) += drivers/message/fusion/fusion.o -DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394drv.o ifneq ($(CONFIG_CD_NO_IDESCSI)$(CONFIG_BLK_DEV_IDECD)$(CONFIG_BLK_DEV_SR)$(CONFIG_PARIDE_PCD),) DRIVERS-y += drivers/cdrom/driver.o endif +DRIVERS-$(CONFIG_IDE) += drivers/ide/idedriver.o +DRIVERS-$(CONFIG_SCSI) += drivers/scsi/scsidrv.o +DRIVERS-$(CONFIG_FUSION_BOOT) += drivers/message/fusion/fusion.o +DRIVERS-$(CONFIG_IEEE1394) += drivers/ieee1394/ieee1394drv.o DRIVERS-$(CONFIG_SOUND) += drivers/sound/sounddrivers.o DRIVERS-$(CONFIG_PCI) += drivers/pci/driver.o DRIVERS-$(CONFIG_MTD) += drivers/mtd/mtdlink.o Would be my idea of solving this issue. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: rwsem.o listed twice as export-objs
On Sat, Apr 21, 2001 at 06:06:34PM +0200, Christoph Hellwig wrote: In article [EMAIL PROTECTED] you wrote: please remove rwsem.o from the list of exported objects, if it is not used. No! The whole point of 'export-objs' is to _always_ list the objects there to make the makefiles smaller and cleaner. Ok, so this patch is better? --- linux/lib/Makefile.orig Sat Apr 21 20:15:00 2001 +++ linux/lib/MakefileSat Apr 21 20:14:37 2001 @@ -8,12 +8,11 @@ L_TARGET := lib.a export-objs := cmdline.o rwsem.o obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o bust_spinlocks.o ifneq ($(CONFIG_RWSEM_GENERIC_SPINLOCK)$(CONFIG_RWSEM_XCHGADD_ALGORITHM),nn) -export-objs += rwsem.o obj-y += rwsem.o endif Because any of the solutions should be applied, because rwsem.o is listed twice currently, which gives a warning at compile time. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: cdrom driver dependency problem (and a workaround patch)
On Sat, Apr 21, 2001 at 08:33:05PM +0300, Dan Aloni wrote: On Sat, 21 Apr 2001, Ingo Oeser wrote: The link order is wrong. So why not changing the link order then? I remember doing what the patch below does. It didn't help. Hmm, maybe you had a typo? Did you try this patch? Yes, just booted an SMP machine with 2.4.3-ac11 and this patch. I booted remote, so it was some kind of dangerous, if it wouldn't work ;-) We also have SCSI enabled there. So it really works ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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/
rwsem.o listed twice as export-objs
Hi David, please remove rwsem.o from the list of exported objects, if it is not used. Regards Ingo Oeser patch is as follows --- lib/Makefile.orig Fri Apr 20 21:51:12 2001 +++ lib/MakefileFri Apr 20 21:51:19 2001 @@ -8,7 +8,7 @@ L_TARGET := lib.a -export-objs := cmdline.o rwsem.o +export-objs := cmdline.o obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o bust_spinlocks.o -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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/
rwsem.o listed twice as export-objs
Hi David, please remove rwsem.o from the list of exported objects, if it is not used. Regards Ingo Oeser patch is as follows --- lib/Makefile.orig Fri Apr 20 21:51:12 2001 +++ lib/MakefileFri Apr 20 21:51:19 2001 @@ -8,7 +8,7 @@ L_TARGET := lib.a -export-objs := cmdline.o rwsem.o +export-objs := cmdline.o obj-y := errno.o ctype.o string.o vsprintf.o brlock.o cmdline.o bust_spinlocks.o -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: light weight user level semaphores
On Thu, Apr 19, 2001 at 09:11:56AM -0700, Linus Torvalds wrote:
> No, this is NOT what the UNIX dogmas are all about.
>
> When UNIX says "everything is a file", it really means that "everything is
> a stream of bytes". Things like magic operations on file desciptors are
> _anathema_ to UNIX. ioctl() is the worst wart of UNIX. Having magic
> semantics of file descriptors is NOT Unix dogma at all, it is a horrible
> corruption of the original UNIX cleanlyness.
Right. And on semaphores, this stream is exactly 0 bytes long.
This is perfectly normal and can be handled by all applications
I'm aware of.
My idea violates nothing here.
> Please don't excuse "semaphore file descriptors" with the "everything is a
> file" mantra. It is not at ALL applicable.
>
> The "everything is a file" mantra is to make pipe etc meaningful -
> processes don't have to worry about whether the fd they have is from a
> file open, a pipe() system call, opening a special block device, or a
> socket()+connect() thing. They can just read and write. THAT is what UNIX
> is all about.
Right. And with my approach read() and write() with a buffer
pointer != NULL would either yield an return value of "0" or
-1 and set errno=EINVAL ("object not suitable for reading/writing").
Anyway they should return IMMIDIATELY in these cases.
We already have these special semantics with devices. Look at
/dev/sgX for an example how we pass even structured data via
normal read/write (instead of "stream of bytes").
> And this is obviously NOT true of a "magic file descriptors for
> semaphores". You can't pass it off as stdin to another process and expect
> anything useful from it unless the other process _knows_ it is a special
> semaphore thing and does mmap magic or something.
see above. NOTHING special about this idea. No magic handling
involved, unless the user of the fd knows what it is. For other
users it will be just a normal fd with normal operations, since
the special case is hidden well enough.
This is even WAY simpler as all that tty-crap and similar
devices, which read/write very dependend on their actual ioctl
configuration.
But since stupid POSIX forbids using fds for semaphores
(according to Ulrich Drepper), this nice, simple and
non-intrusive solution is out.
Instead we should go with several new syscalls, user space
dependencies, strange error handling and yet-to-discuss
semantics.
Everybody else byt you would have been kicked out by the core
people for suggesting this ;-)
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< been there and had much fun >>>>>>>>>>>>
-
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: light weight user level semaphores
On Thu, Apr 19, 2001 at 12:26:03PM -0700, Ulrich Drepper wrote: > In any case all kinds of user-level operations are possible as well > and all the schemes suggested for dealing with the common case without > syscalls can be applied here as well. Are you sure, you can implement SMP-safe, atomic operations (which you need for all up()/down() in user space) WITHOUT using privileged instructions on ALL archs Linux supports? How do we do this on nccNUMA machines later? How on clusters[1]? On what I can see in asm-*/atomic.h this is not possible, but I probably miss sth. here ;-) I didn't know that POSIX forbids using fds to implement a semaphore. That's VERY bad. Learning new APIs always means making a lot of mistakes and doing this while we write production code, since nobody likes to pay for experiments. And I still see no point on speeding of creation and contention, since these should be rare cases and the application overusing these should be punished HARD. Maybe someone can enlighten my on these aspects. Regards Ingo Oeser [1] Ok, people already use other than Unix mechanisms for this stuff on massive parallel computing. So this might not be an issue. Only for libc internal sema4s -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: light weight user level semaphores
On Thu, Apr 19, 2001 at 10:20:48AM +0200, Alon Ziv wrote:
> My lightweight-semaphores were actually even simpler in userspace:
> * the userspace struct was just a signed count and a file handle.
> * Uncontended case is exactly like Linus' version (i.e., down() is decl +
> js, up() is incl()).
> * The contention syscall was (in my implementation) an ioctl on the FH; the
> FH was a special one, from a private syscall (although with the new VFS I'd
> have written it as just another specialized FS, or even referred into the
> SysVsem FS).
This is roughly the way I would prefer it.
But I would dedicate a whole page to this struct, since this is
the granularity we can decide sharing on. This also has the
advantage, that we can include a lot of debugging info into this
page, too. Some people would like to know current contenders,
up/down ratio per second and contender etc.
Why? We have the infrastructure and all the semantics already in
place and it is well known to the programmers. We know how we
inherit this stuff, what will happen on process termination and
so on.
I thought about this myself a lot, but just didn't like the idea
to trust user space for up/down. I thought about abusing read() and
write() for down() and up(). Just doing it partially in user
space would be an significant speedup, once you got it right.
Maybe we can even combine both of it like this:
Then user space can do:
/* open or create sema4 with normal open semantics */
fd=open("/dev/sema4/myone");
sema4=mmap(NULL,getpagesize(),,,fd,0);
/* up */
atomic_inc_and_test_for_zero(sema4) && ioctl(fd,WAKE_SLEEPERS,NULL);
/* down */
atomic_dec_and_test_negative(sema4) && ioctl(fd,SLEEP_NOW,NULL);
or
/* open or create sema4 with normal open semantics */
fd=open("/dev/sema4/myone");
/* up */
write(fd, NULL,0); /* do the atomic stuff and wakeup in kernel */
/* this might be stupid, but COULD be implemented */
/* add 4 items to counter */
write(fd, NULL, 4);
/* down */
read(sama4, NULL, 0);
We could even do trylock() by default, if we open O_NONBLOCK. Or
we could do trylock sometimes using select() and poll(). This
also makes it easy to add it to existing select() loops like
Motif.
This differences could even be hidden by the libc. IIRC there are
some archs, which cannot do atomic operations without privileged
instructions, which is not acceptable in user space. Also there
are archs, which are not cache coherent (think NUMA) and where
flushing these caches to the other CPUs is privileged. Last but
not least there are clusters with process migration.
My twofold approach would solve all these problems rather simply.
It would be a libc decision on what to use now. And the libc
knows enough about the application to handle all these cases.
The only thing we still need, is what we do if a contender or
waiter ist killed. Should we send SIGPIPE? Should we simply wake
all the waiters?
And we are not creating a new namespace again, but just use the
standard UN*X one: File name space.
Hopes this "fit into namespace" solution will be considered,
because I don't like to have a new linux-only API with completely
new semantics and things to care in wrappers, even if you don't
use this stuff.
I also don't like the "kill me if I do a mistake"
that Linus proposed in the "bad_sem" label.
Comments? Flames? Overengineered?
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
<<<<<<<<<<<< been there and had much fun >>>>>>>>>>>>
-
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: light weight user level semaphores
On Thu, Apr 19, 2001 at 10:20:48AM +0200, Alon Ziv wrote:
My lightweight-semaphores were actually even simpler in userspace:
* the userspace struct was just a signed count and a file handle.
* Uncontended case is exactly like Linus' version (i.e., down() is decl +
js, up() is incl()).
* The contention syscall was (in my implementation) an ioctl on the FH; the
FH was a special one, from a private syscall (although with the new VFS I'd
have written it as just another specialized FS, or even referred into the
SysVsem FS).
This is roughly the way I would prefer it.
But I would dedicate a whole page to this struct, since this is
the granularity we can decide sharing on. This also has the
advantage, that we can include a lot of debugging info into this
page, too. Some people would like to know current contenders,
up/down ratio per second and contender etc.
Why? We have the infrastructure and all the semantics already in
place and it is well known to the programmers. We know how we
inherit this stuff, what will happen on process termination and
so on.
I thought about this myself a lot, but just didn't like the idea
to trust user space for up/down. I thought about abusing read() and
write() for down() and up(). Just doing it partially in user
space would be an significant speedup, once you got it right.
Maybe we can even combine both of it like this:
Then user space can do:
/* open or create sema4 with normal open semantics */
fd=open("/dev/sema4/myone");
sema4=mmap(NULL,getpagesize(),,,fd,0);
/* up */
atomic_inc_and_test_for_zero(sema4) ioctl(fd,WAKE_SLEEPERS,NULL);
/* down */
atomic_dec_and_test_negative(sema4) ioctl(fd,SLEEP_NOW,NULL);
or
/* open or create sema4 with normal open semantics */
fd=open("/dev/sema4/myone");
/* up */
write(fd, NULL,0); /* do the atomic stuff and wakeup in kernel */
/* this might be stupid, but COULD be implemented */
/* add 4 items to counter */
write(fd, NULL, 4);
/* down */
read(sama4, NULL, 0);
We could even do trylock() by default, if we open O_NONBLOCK. Or
we could do trylock sometimes using select() and poll(). This
also makes it easy to add it to existing select() loops like
Motif.
This differences could even be hidden by the libc. IIRC there are
some archs, which cannot do atomic operations without privileged
instructions, which is not acceptable in user space. Also there
are archs, which are not cache coherent (think NUMA) and where
flushing these caches to the other CPUs is privileged. Last but
not least there are clusters with process migration.
My twofold approach would solve all these problems rather simply.
It would be a libc decision on what to use now. And the libc
knows enough about the application to handle all these cases.
The only thing we still need, is what we do if a contender or
waiter ist killed. Should we send SIGPIPE? Should we simply wake
all the waiters?
And we are not creating a new namespace again, but just use the
standard UN*X one: File name space.
Hopes this "fit into namespace" solution will be considered,
because I don't like to have a new linux-only API with completely
new semantics and things to care in wrappers, even if you don't
use this stuff.
I also don't like the "kill me if I do a mistake"
that Linus proposed in the "bad_sem" label.
Comments? Flames? Overengineered?
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
been there and had much fun
-
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: light weight user level semaphores
On Thu, Apr 19, 2001 at 12:26:03PM -0700, Ulrich Drepper wrote: In any case all kinds of user-level operations are possible as well and all the schemes suggested for dealing with the common case without syscalls can be applied here as well. Are you sure, you can implement SMP-safe, atomic operations (which you need for all up()/down() in user space) WITHOUT using privileged instructions on ALL archs Linux supports? How do we do this on nccNUMA machines later? How on clusters[1]? On what I can see in asm-*/atomic.h this is not possible, but I probably miss sth. here ;-) I didn't know that POSIX forbids using fds to implement a semaphore. That's VERY bad. Learning new APIs always means making a lot of mistakes and doing this while we write production code, since nobody likes to pay for experiments. And I still see no point on speeding of creation and contention, since these should be rare cases and the application overusing these should be punished HARD. Maybe someone can enlighten my on these aspects. Regards Ingo Oeser [1] Ok, people already use other than Unix mechanisms for this stuff on massive parallel computing. So this might not be an issue. Only for libc internal sema4s -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: light weight user level semaphores
On Thu, Apr 19, 2001 at 09:11:56AM -0700, Linus Torvalds wrote:
No, this is NOT what the UNIX dogmas are all about.
When UNIX says "everything is a file", it really means that "everything is
a stream of bytes". Things like magic operations on file desciptors are
_anathema_ to UNIX. ioctl() is the worst wart of UNIX. Having magic
semantics of file descriptors is NOT Unix dogma at all, it is a horrible
corruption of the original UNIX cleanlyness.
Right. And on semaphores, this stream is exactly 0 bytes long.
This is perfectly normal and can be handled by all applications
I'm aware of.
My idea violates nothing here.
Please don't excuse "semaphore file descriptors" with the "everything is a
file" mantra. It is not at ALL applicable.
The "everything is a file" mantra is to make pipe etc meaningful -
processes don't have to worry about whether the fd they have is from a
file open, a pipe() system call, opening a special block device, or a
socket()+connect() thing. They can just read and write. THAT is what UNIX
is all about.
Right. And with my approach read() and write() with a buffer
pointer != NULL would either yield an return value of "0" or
-1 and set errno=EINVAL ("object not suitable for reading/writing").
Anyway they should return IMMIDIATELY in these cases.
We already have these special semantics with devices. Look at
/dev/sgX for an example how we pass even structured data via
normal read/write (instead of "stream of bytes").
And this is obviously NOT true of a "magic file descriptors for
semaphores". You can't pass it off as stdin to another process and expect
anything useful from it unless the other process _knows_ it is a special
semaphore thing and does mmap magic or something.
see above. NOTHING special about this idea. No magic handling
involved, unless the user of the fd knows what it is. For other
users it will be just a normal fd with normal operations, since
the special case is hidden well enough.
This is even WAY simpler as all that tty-crap and similar
devices, which read/write very dependend on their actual ioctl
configuration.
But since stupid POSIX forbids using fds for semaphores
(according to Ulrich Drepper), this nice, simple and
non-intrusive solution is out.
Instead we should go with several new syscalls, user space
dependencies, strange error handling and yet-to-discuss
semantics.
Everybody else byt you would have been kicked out by the core
people for suggesting this ;-)
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
been there and had much fun
-
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: Data-corruption bug in VIA chipsets
On Fri, Apr 13, 2001 at 10:00:32AM +0200, Dennis Bjorklund wrote: > Here might be one of the resons for the trouble with VIA chipsets: > > http://www.theregister.co.uk/content/3/18267.html > > Some DMA error corrupting data, sounds like a really nasty bug. The > information is minimal on that page. These are the things, that one of the German links[1] suggest (translated only, because I'm not the IDE guy ;-)): - PCI Delay Transaction = 0 (off) (Register 0x70, Bit 1) - PCI Master Read Caching = 0 (off) (Register 0x70, Bit 2) - PCI Latency = 0 (values between 0 and 32 *seem* to be safe, everything above seems to be *not* !) Note: This also fixes some related USB issues according to [1]. Some hassles of setting the "PCI Latency" are described and one of their reader found out, that it is "PCI Bus Master Time-Out" on his board. Register 0x75, Bits 0-3 are at 0001, which means 32 as latency value. He set it to and it helps. This setting also does no harm according to the magazine. The observations are valid for the VT82C686B. One of their readers also observed it at VT82C686A too and reported, that the workaround helps. So we might want to enable these workarounds for this southbridge, too. Hope this translation helps our maintainers a little ;-) Regards Ingo Oeser [1] http://home.tiscalinet.de/au-ja/review-kt133a-4.html -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: union mounting?
On Thu, Apr 12, 2001 at 01:31:46PM -0400, David L. Parsley wrote: > real pretty. If you've got union mounting patches for testing, I'd be > interested. ;-) /me is interested, too. And yes, I have nearly the same problem ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: union mounting?
On Thu, Apr 12, 2001 at 01:31:46PM -0400, David L. Parsley wrote: real pretty. If you've got union mounting patches for testing, I'd be interested. ;-) /me is interested, too. And yes, I have nearly the same problem ;-) Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: Data-corruption bug in VIA chipsets
On Fri, Apr 13, 2001 at 10:00:32AM +0200, Dennis Bjorklund wrote: Here might be one of the resons for the trouble with VIA chipsets: http://www.theregister.co.uk/content/3/18267.html Some DMA error corrupting data, sounds like a really nasty bug. The information is minimal on that page. These are the things, that one of the German links[1] suggest (translated only, because I'm not the IDE guy ;-)): - PCI Delay Transaction = 0 (off) (Register 0x70, Bit 1) - PCI Master Read Caching = 0 (off) (Register 0x70, Bit 2) - PCI Latency = 0 (values between 0 and 32 *seem* to be safe, everything above seems to be *not* !) Note: This also fixes some related USB issues according to [1]. Some hassles of setting the "PCI Latency" are described and one of their reader found out, that it is "PCI Bus Master Time-Out" on his board. Register 0x75, Bits 0-3 are at 0001, which means 32 as latency value. He set it to and it helps. This setting also does no harm according to the magazine. The observations are valid for the VT82C686B. One of their readers also observed it at VT82C686A too and reported, that the workaround helps. So we might want to enable these workarounds for this southbridge, too. Hope this translation helps our maintainers a little ;-) Regards Ingo Oeser [1] http://home.tiscalinet.de/au-ja/review-kt133a-4.html -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: CML2 1.0.0 doesn't remember configuration changes
On Wed, Apr 11, 2001 at 10:06:46PM -0400, [EMAIL PROTECTED] wrote: > Editconfig was a mistake. OK, I think I understand the rules now. Is it: > > (1) First, try to read from .config > (2) If .config doesn't exist, read from $(ARCH)/defconfig > > ? Right. But with the following constraints: make oldconfig takes _any_ .config from _any_ kernel and builds a new one for _this_ kernel asking any remaining questions make xconfig, make menuconfig, make config take a .config from _this_ kernel and configure for _this_ kernel if they don't find and .config, then they fall back to $(ARCH)/defconfig Would be nice, if CML2 works like this too, because it's not nice to go through all the options again, if I install a new kernel or just want to change my current kernel config add a module. But your CML2 is sure great work. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: CML2 1.0.0 doesn't remember configuration changes
On Wed, Apr 11, 2001 at 10:06:46PM -0400, [EMAIL PROTECTED] wrote: Editconfig was a mistake. OK, I think I understand the rules now. Is it: (1) First, try to read from .config (2) If .config doesn't exist, read from $(ARCH)/defconfig ? Right. But with the following constraints: make oldconfig takes _any_ .config from _any_ kernel and builds a new one for _this_ kernel asking any remaining questions make xconfig, make menuconfig, make config take a .config from _this_ kernel and configure for _this_ kernel if they don't find and .config, then they fall back to $(ARCH)/defconfig Would be nice, if CML2 works like this too, because it's not nice to go through all the options again, if I install a new kernel or just want to change my current kernel config add a module. But your CML2 is sure great work. Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: Larger dev_t
On Tue, Apr 03, 2001 at 01:06:33PM +0100, Alan Cox wrote: > Device numbers/names have to be constant in order to detect > disk layout changes across boots. Names stay constant, but why the NUMBERS? The names should stay constant and represent the actual layout on each busses (say: sane hierachic enumeration) of course. But /dev/ide/host0/bus0/target0/lun0/part1 could get a new device number on every reboot, right? I'm sure, I'm missing some important usage of device of device numers here (not counting the ones listed already), but I don't know what ;-) Otherwise it would be too easy to remove static major/minors and all the fun allocating them. And LANANA would have one thing less to worry about ;-) One thing I certainly miss: DevFS is not mandatory (yet). Thanks & Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: Larger dev_t
On Mon, Apr 02, 2001 at 10:17:02PM +0200, [EMAIL PROTECTED] wrote: > What is dev_t used for? It is a communication channel from > filesystem to user space (via the stat() system call) > and from user space to filesystem (via the mknod() system call). The question is WHAT do we communicate (and don't answer "major minor" here, since this is only numbers) and WHY do we need this communication. Devfs aims to associate device names with dynamic, flat device numbers. So we have a scalable solution for the kernel -> user space communication. What we DON't have, is a similar simple way to tell it the other way around. The reasons, why we need to know where a file is located on are: - to only include files from one media - to run certain optimizations like fsck does with disk spindles - ... So instead of just shifting the problems into the future and making the same mistake again, we should better think of interfaces, that give us the information we need and let this error prone (ever had a typo on mknod?) and never large enough static interface die. Maybe there should be a way to translate a dynamic associated device number into a real device name, like the devfs name of it. May be a reverse mapping in devfs (/dev/by_dev_no/[0-9]+) would work. If these are symlinks, a readlink() would suffice. Very simple solution. For comparing inode1.media == inode2.media (one of the most important uses for device numbers) we don't need to change anything. For getting the device number of the spindle, the block devices which support partitions or are remapping a (set of) block device(s) could get IOCTLs (where this information belongs into and is as reliable as the driver). For all these things, we can have a flat and dynamic device number namespace. Device numbers have to be uniqe only during one power on -> run -> power off cycle. For the rest applications should store device names instead anyway. The applications, that don't are buggy by defintion. Note: I certainly overlooked sth., so please flame me ;-) > The current discussion is almost entirely about mknod.] Yes: Let "mknod /dev/foo [bc] x y" die! Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: Larger dev_t
On Mon, Apr 02, 2001 at 10:17:02PM +0200, [EMAIL PROTECTED] wrote: What is dev_t used for? It is a communication channel from filesystem to user space (via the stat() system call) and from user space to filesystem (via the mknod() system call). The question is WHAT do we communicate (and don't answer "major minor" here, since this is only numbers) and WHY do we need this communication. Devfs aims to associate device names with dynamic, flat device numbers. So we have a scalable solution for the kernel - user space communication. What we DON't have, is a similar simple way to tell it the other way around. The reasons, why we need to know where a file is located on are: - to only include files from one media - to run certain optimizations like fsck does with disk spindles - ... So instead of just shifting the problems into the future and making the same mistake again, we should better think of interfaces, that give us the information we need and let this error prone (ever had a typo on mknod?) and never large enough static interface die. Maybe there should be a way to translate a dynamic associated device number into a real device name, like the devfs name of it. May be a reverse mapping in devfs (/dev/by_dev_no/[0-9]+) would work. If these are symlinks, a readlink() would suffice. Very simple solution. For comparing inode1.media == inode2.media (one of the most important uses for device numbers) we don't need to change anything. For getting the device number of the spindle, the block devices which support partitions or are remapping a (set of) block device(s) could get IOCTLs (where this information belongs into and is as reliable as the driver). For all these things, we can have a flat and dynamic device number namespace. Device numbers have to be uniqe only during one power on - run - power off cycle. For the rest applications should store device names instead anyway. The applications, that don't are buggy by defintion. Note: I certainly overlooked sth., so please flame me ;-) The current discussion is almost entirely about mknod.] Yes: Let "mknod /dev/foo [bc] x y" die! Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: Larger dev_t
On Tue, Apr 03, 2001 at 01:06:33PM +0100, Alan Cox wrote: Device numbers/names have to be constant in order to detect disk layout changes across boots. Names stay constant, but why the NUMBERS? The names should stay constant and represent the actual layout on each busses (say: sane hierachic enumeration) of course. But /dev/ide/host0/bus0/target0/lun0/part1 could get a new device number on every reboot, right? I'm sure, I'm missing some important usage of device of device numers here (not counting the ones listed already), but I don't know what ;-) Otherwise it would be too easy to remove static major/minors and all the fun allocating them. And LANANA would have one thing less to worry about ;-) One thing I certainly miss: DevFS is not mandatory (yet). Thanks Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: OOM killer???
On Tue, Mar 27, 2001 at 03:24:16PM +0200, Martin Dalecki wrote: > > @@ -93,6 +95,10 @@ > > p->uid == 0 || p->euid == 0) > > points /= 4; > > > > + /* Much the same goes for processes with low UIDs */ > > + if(p->uid < 100 || p->euid < 100) > > + points /= 2; > > + > > Plase change to 100 to 500 - this would make it consistant with > the useradd command, which starts adding new users at the UID 500 No, useradd reads usally the /etc/login.defs to select the range. The oom-killer should have configurables for that, to allow the policy decisions in USER space -- where it belongs -- not in KERNEL space If we use my OOM killer API, this patch would be a module and could have module parameters to select that. Johnathan: I URGE you to apply my patch before adding OOM killer stuff. What's wrong with it, that you cannot use it? ;-) It is easy to add configurables to a module and play with them WITHOUT recompiling. Dynamic sysctl tables would also be possible, IF we had an value that is DEFINED to be invalid for sysctrl(2) and only valid for /proc. It is also better to include the egid into the decision. There are deamons, that I defintely want to be killed on a workstation, but not on a server. e.g. My important matlab calculation, which runs in user mode should not be killed. But killing a local webserver, which serves my help system is ok (because I will not loose work, and might get it over the net, if there is a problem). So as Rik stated: The OOM killer cannot suit all people, so it has to be configurable, to be OOM kill, not overkill ;-) Thanks & Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: OOM killer???
On Tue, Mar 27, 2001 at 03:24:16PM +0200, Martin Dalecki wrote: @@ -93,6 +95,10 @@ p-uid == 0 || p-euid == 0) points /= 4; + /* Much the same goes for processes with low UIDs */ + if(p-uid 100 || p-euid 100) + points /= 2; + Plase change to 100 to 500 - this would make it consistant with the useradd command, which starts adding new users at the UID 500 No, useradd reads usally the /etc/login.defs to select the range. The oom-killer should have configurables for that, to allow the policy decisions in USER space -- where it belongs -- not in KERNEL space If we use my OOM killer API, this patch would be a module and could have module parameters to select that. Johnathan: I URGE you to apply my patch before adding OOM killer stuff. What's wrong with it, that you cannot use it? ;-) It is easy to add configurables to a module and play with them WITHOUT recompiling. Dynamic sysctl tables would also be possible, IF we had an value that is DEFINED to be invalid for sysctrl(2) and only valid for /proc. It is also better to include the egid into the decision. There are deamons, that I defintely want to be killed on a workstation, but not on a server. e.g. My important matlab calculation, which runs in user mode should not be killed. But killing a local webserver, which serves my help system is ok (because I will not loose work, and might get it over the net, if there is a problem). So as Rik stated: The OOM killer cannot suit all people, so it has to be configurable, to be OOM kill, not overkill ;-) Thanks Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: [PATCH] OOM handling
On Sun, Mar 25, 2001 at 09:13:20PM -0500, Matthew Chappee wrote: > The point being, my database shouldn't be selected for > termination. Nobody ever got fired for kill -9'ing netscape, > but Oracle is a different story. I urge you, consider the > patch. No, you got fired for not setting ulimits. Your boss is right then! ulimit -d 65536 ulimit -v 81920 and my netscape is very happy most of the time. And my system is not disturbed. 64MB RAM + 256MB swap. In a school I had the same setup on a 256MB server (256MB swap) serving apps (StarOffice and Netscape) to ~16 X clients. I never had OOM there. I think this is the amount of memory an oracle server at least have to have, right? What are your ulimits? What are your amounts of RAM+SWAP? Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: [PATCH] OOM handling
On Sun, Mar 25, 2001 at 09:13:20PM -0500, Matthew Chappee wrote: The point being, my database shouldn't be selected for termination. Nobody ever got fired for kill -9'ing netscape, but Oracle is a different story. I urge you, consider the patch. No, you got fired for not setting ulimits. Your boss is right then! ulimit -d 65536 ulimit -v 81920 and my netscape is very happy most of the time. And my system is not disturbed. 64MB RAM + 256MB swap. In a school I had the same setup on a 256MB server (256MB swap) serving apps (StarOffice and Netscape) to ~16 X clients. I never had OOM there. I think this is the amount of memory an oracle server at least have to have, right? What are your ulimits? What are your amounts of RAM+SWAP? Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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: ACPI power-off doesn't work on Asus CUV4X (VIA Apollo 133)
On Sat, Mar 24, 2001 at 10:53:08PM +0100, Ingo Oeser wrote: > On Sat, Mar 24, 2001 at 06:25:16PM +0100, Alex Riesen wrote: > > As i recompiled 2.4.2-ac20 with ACPI support > > the system cannot switch itself off. > > I get a message "Couldn't switch to S5" if > > try to call reboot(2). > > At load it shows that the mode is supported. > > Same with AMR P6BAP-AP and P6VAP-AP () mainboards. > > Firmware supports C2 C3 S0 S1 S4 S5. > > All options for acpi tried. > > #define APCI_DEBUG 1 has NO effect on verbosity of messages :-( > > What should I do to get more debug info? Just left it in FYI, Andrew. > I'll try backing out all changes between 2.4.0 and 2.4.2-ac20, > because there it worked ;-) Ok, that worked. Backing out all the changes made it shutdown again. Since this shouldn't by the right way to fix this problem, what else can I do Andrew? The BIG Problem is: This is an embedded machine, so I cannot attach all the funny debug tools. The most thing I can do is printk and evtl. ikdb. I have only 16MB flash disk on this machine and it is full already :-( Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag> <<<<<<<<<<<< been there and had much fun >>>>>>>>>>>> - 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: ACPI power-off doesn't work on Asus CUV4X (VIA Apollo 133)
On Sat, Mar 24, 2001 at 10:53:08PM +0100, Ingo Oeser wrote: On Sat, Mar 24, 2001 at 06:25:16PM +0100, Alex Riesen wrote: As i recompiled 2.4.2-ac20 with ACPI support the system cannot switch itself off. I get a message "Couldn't switch to S5" if try to call reboot(2). At load it shows that the mode is supported. Same with AMR P6BAP-AP and P6VAP-AP () mainboards. Firmware supports C2 C3 S0 S1 S4 S5. All options for acpi tried. #define APCI_DEBUG 1 has NO effect on verbosity of messages :-( What should I do to get more debug info? Just left it in FYI, Andrew. I'll try backing out all changes between 2.4.0 and 2.4.2-ac20, because there it worked ;-) Ok, that worked. Backing out all the changes made it shutdown again. Since this shouldn't by the right way to fix this problem, what else can I do Andrew? The BIG Problem is: This is an embedded machine, so I cannot attach all the funny debug tools. The most thing I can do is printk and evtl. ikdb. I have only 16MB flash disk on this machine and it is full already :-( Regards Ingo Oeser -- 10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag been there and had much fun - 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/
