Re: VM Requirement Document - v0.0
On Tue, Jun 26, 2001 at 08:43:33PM -0400, Dan Maas wrote:
> (hrm, maybe I could hack up my own manual read-ahead/drop-behind with mmap()
> and memory locking...)
Just to argue portability for a moment (portability on the expected
results, that is, vs APIs).
Would this technique work across a variety of OSes?
Would the recent caching difficulties of the 2.4.* series have handled such
a technique in a reasonable fashion?
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: VM Requirement Document - v0.0
On Tue, Jun 26, 2001 at 03:48:09PM -0700, Jeffrey W. Baker wrote:
> These flags would be really handy. We already have the raw device for
> sequential reading of e.g. CDROM and DVD devices.
Not going to help 99% of the applications out there.
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: VM Requirement Document - v0.0
On Tue, Jun 26, 2001 at 03:48:09PM -0700, Jeffrey W. Baker wrote: These flags would be really handy. We already have the raw device for sequential reading of e.g. CDROM and DVD devices. Not going to help 99% of the applications out there. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: VM Requirement Document - v0.0
On Tue, Jun 26, 2001 at 08:43:33PM -0400, Dan Maas wrote: (hrm, maybe I could hack up my own manual read-ahead/drop-behind with mmap() and memory locking...) Just to argue portability for a moment (portability on the expected results, that is, vs APIs). Would this technique work across a variety of OSes? Would the recent caching difficulties of the 2.4.* series have handled such a technique in a reasonable fashion? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: Microsoft and Xenix.
On Sat, Jun 23, 2001 at 09:41:29PM -0500, [EMAIL PROTECTED] wrote:
> Ah, yes, the RT/PC. That brings back some fond memories. My first exposure to
> Unix was with AIX on the RT. I still have some of those weird-sized RT AIX
> manuals around somewhere...
We always ran AOS on RT's. Actually, the server was the only RT, the rest
were some other model that was basically a PS/2 (286) that booted DOS, then
booted the other same chip that the RT used that was on a daughter card.
AOS was basically IBM's version of BSD. Academic Operating System.
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: Microsoft and Xenix.
On Sat, Jun 23, 2001 at 09:41:29PM -0500, [EMAIL PROTECTED] wrote: Ah, yes, the RT/PC. That brings back some fond memories. My first exposure to Unix was with AIX on the RT. I still have some of those weird-sized RT AIX manuals around somewhere... We always ran AOS on RT's. Actually, the server was the only RT, the rest were some other model that was basically a PS/2 (286) that booted DOS, then booted the other same chip that the RT used that was on a daughter card. AOS was basically IBM's version of BSD. Academic Operating System. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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 use threads ( was: Alan Cox quote?)
On Wed, Jun 20, 2001 at 03:18:58PM -0700, David Schwartz wrote:
> As I said, you don't want to use one thread for each client. You use, say,
> 10 threads for the 16,000 clients. That way, if an occasional client
> ambushes a thread (say by reading a file off an NFS server or by using some
> infrequently used code that was swapped to a busy disk), your server will
> keep on humming.
This same approach can easily be used by multiple processes.
I don't see what is gained by using threads over processes for such an
architecture.
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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 use threads ( was: Alan Cox quote?)
On Wed, Jun 20, 2001 at 03:18:58PM -0700, David Schwartz wrote: As I said, you don't want to use one thread for each client. You use, say, 10 threads for the 16,000 clients. That way, if an occasional client ambushes a thread (say by reading a file off an NFS server or by using some infrequently used code that was swapped to a busy disk), your server will keep on humming. This same approach can easily be used by multiple processes. I don't see what is gained by using threads over processes for such an architecture. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: How to compile on one machine and install on another?
On Tue, Jun 19, 2001 at 10:23:47PM -0400, John Weber wrote:
> On a related note... is System.map also necessary? Anyone care to explain
Debugging. ksymoops and klogd can both make use of it.
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 06:30:54PM -0700, Ben Greear wrote:
> Yeah, and we are young and prolific too, so you better watch out! :)
Prolific != competent.
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 04:56:16PM -0700, Jonathan Lundell wrote:
> But so what? That's $16 worth of DRAM (I just checked). Not so bad
> *if* threads are otherwise a great solution. I grant that one might
> have a pretty tough time making the case, but again, for the right
> application, say some app with a dedicated server, 73MB isn't the end
> of the world (though I suppose it was at the time...).
How much would 73MB of cache cost? How much would it cost to get that much
on the CPU?
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: How to compile on one machine and install on another?
On Tue, Jun 19, 2001 at 04:45:24PM -0500, Eli Carter wrote:
> Gabriel Rocha wrote:
> > you could always compile on one machine and nfs mount the /usr/src/linux
> > and do a make modules_install from the nfs mounted directory...
>
> Which would require exporting that filesystem with root permissions
> enabled...any security bells going off?
Why would you need to have nfs root access?
You're reading from the nfs mount, not writing to it.
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 10:37:12AM -0700, Larry McVoy wrote:
> On Tue, Jun 19, 2001 at 10:20:37AM -0700, Mike Castle wrote:
> > Also, I could never actually find the "too fat" quote anywhere.
>
> I can personally vouch for the too fat comment, I've heard him say it in
> person.
What about the "UNIX is starting to smell bad" comment? :->
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote:
> Another one that I can't believe I forgot is from Rob Pike:
>
> "If you think you need threads then your processes are too fat"
Pike also to have said, "Not only is UNIX dead, it's starting to smell bad."
Also, I could never actually find the "too fat" quote anywhere. Best I
could find was one of Pike's papers on the plan9 site. Best that I can
tell is that both of these quotes are Urban Legends.
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 09:09:56AM -0700, Larry McVoy wrote: Another one that I can't believe I forgot is from Rob Pike: If you think you need threads then your processes are too fat Pike also to have said, Not only is UNIX dead, it's starting to smell bad. Also, I could never actually find the too fat quote anywhere. Best I could find was one of Pike's papers on the plan9 site. Best that I can tell is that both of these quotes are Urban Legends. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 10:37:12AM -0700, Larry McVoy wrote: On Tue, Jun 19, 2001 at 10:20:37AM -0700, Mike Castle wrote: Also, I could never actually find the too fat quote anywhere. I can personally vouch for the too fat comment, I've heard him say it in person. What about the UNIX is starting to smell bad comment? :- mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: How to compile on one machine and install on another?
On Tue, Jun 19, 2001 at 04:45:24PM -0500, Eli Carter wrote: Gabriel Rocha wrote: you could always compile on one machine and nfs mount the /usr/src/linux and do a make modules_install from the nfs mounted directory... Which would require exporting that filesystem with root permissions enabled...any security bells going off? Why would you need to have nfs root access? You're reading from the nfs mount, not writing to it. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 04:56:16PM -0700, Jonathan Lundell wrote: But so what? That's $16 worth of DRAM (I just checked). Not so bad *if* threads are otherwise a great solution. I grant that one might have a pretty tough time making the case, but again, for the right application, say some app with a dedicated server, 73MB isn't the end of the world (though I suppose it was at the time...). How much would 73MB of cache cost? How much would it cost to get that much on the CPU? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: Alan Cox quote? (was: Re: accounting for threads)
On Tue, Jun 19, 2001 at 06:30:54PM -0700, Ben Greear wrote: Yeah, and we are young and prolific too, so you better watch out! :) Prolific != competent. -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: How to compile on one machine and install on another?
On Tue, Jun 19, 2001 at 10:23:47PM -0400, John Weber wrote: On a related note... is System.map also necessary? Anyone care to explain Debugging. ksymoops and klogd can both make use of it. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: threading question (results after thread pooling)
On Thu, Jun 14, 2001 at 04:42:29PM -0600, [EMAIL PROTECTED] wrote:
> 2. The main thread sets up the data (which are global) and then signals
> that there is work to be done on the same condition variable. The first
> thread to get awaken takes the work. the remaining threads keep waiting.
For curiosities sake, at what point would this technique result in a
thundering herd issue? Does it happen near the level at which the number of
schedulable entities equal the number of processors or does it have to be
much greater than that?
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: threading question (results after thread pooling)
On Thu, Jun 14, 2001 at 04:42:29PM -0600, [EMAIL PROTECTED] wrote: 2. The main thread sets up the data (which are global) and then signals that there is work to be done on the same condition variable. The first thread to get awaken takes the work. the remaining threads keep waiting. For curiosities sake, at what point would this technique result in a thundering herd issue? Does it happen near the level at which the number of schedulable entities equal the number of processors or does it have to be much greater than that? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: threading question
On Tue, Jun 12, 2001 at 03:25:54PM -0400, Russell Leighton wrote:
> Any recommendations for alternate threading packages?
Does NSPR use native methods (ie, clone), or just ride on top of pthreads?
What about the gnu threading package?
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: threading question
On Tue, Jun 12, 2001 at 03:25:54PM -0400, Russell Leighton wrote: Any recommendations for alternate threading packages? Does NSPR use native methods (ie, clone), or just ride on top of pthreads? What about the gnu threading package? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: select() - Linux vs. BSD
On Sat, Jun 02, 2001 at 10:47:49PM -0400, John Chris Wren wrote:
> I would have said just the opposite. That if it you have a large number of
> handles you're waiting on, and you have to go back through and set the bits
> everytime you timeout that you would incur a larger overhead. From the
Use a temp fd_set and assignment.
fd_set readset;
readset=set_to_watch
select(n, readset, NULL, NULL, timeout);
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: select() - Linux vs. BSD
On Sat, Jun 02, 2001 at 10:47:49PM -0400, John Chris Wren wrote: I would have said just the opposite. That if it you have a large number of handles you're waiting on, and you have to go back through and set the bits everytime you timeout that you would incur a larger overhead. From the Use a temp fd_set and assignment. fd_set readset; readset=set_to_watch select(n, readset, NULL, NULL, timeout); mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: How to know HZ from userspace?
On Wed, May 30, 2001 at 05:44:39PM -0700, Jonathan Lundell wrote:
> Lots. Maybe we oughta have /proc/sysconf/... (there's no reason
> sysconf() can't be a library reading /proc).
You don't mount proc?
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: ln -s broken on 2.4.5
On Wed, May 30, 2001 at 11:30:05PM +0200, Marcus Meissner wrote:
> The problem is only there if you specify a directory for the linked to
> component.
>
> [marcus@wine /tmp]$ strace -f ln -s fupp/berk xxx
Is it only a directory, or the length?
ln -s fupp_berk xxx
for instance.
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
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: ln -s broken on 2.4.5
On Wed, May 30, 2001 at 11:30:05PM +0200, Marcus Meissner wrote: The problem is only there if you specify a directory for the linked to component. [marcus@wine /tmp]$ strace -f ln -s fupp/berk xxx Is it only a directory, or the length? ln -s fupp_berk xxx for instance. -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: How to know HZ from userspace?
On Wed, May 30, 2001 at 05:44:39PM -0700, Jonathan Lundell wrote: Lots. Maybe we oughta have /proc/sysconf/... (there's no reason sysconf() can't be a library reading /proc). You don't mount proc? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc - 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: select() - Linux vs. BSD
On Tue, May 29, 2001 at 11:55:24AM -0400, John Chris Wren wrote:
> select will not be altered. In Linux, which claims BSD compliancy for this
> in the man page (but does not state either way what will happen to the
> bits), zeros the users bit masks when a timeout occurs. I have written a
Where in the man page does it state this? I just read it and couldn't find
any such statement.
I do, however, find the following:
exceptfds will be watched for exceptions. On exit, the
sets are modified in place to indicate which descriptors
actually changed status.
If there is a time out, it makes sense that no descriptors changed state,
and so everything would be zeroed out.
And actually, the example seems to support this:
if (retval)
printf("Data is available now.\n");
/* FD_ISSET(0, ) will be true. */
The comment seems to indicate that if retval is 0, then FD_ISSET will be
false.
mrc
--
Mike Castle Life is like a clock: You can work constantly
[EMAIL PROTECTED] and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
-
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: select() - Linux vs. BSD
On Tue, May 29, 2001 at 11:55:24AM -0400, John Chris Wren wrote: select will not be altered. In Linux, which claims BSD compliancy for this in the man page (but does not state either way what will happen to the bits), zeros the users bit masks when a timeout occurs. I have written a Where in the man page does it state this? I just read it and couldn't find any such statement. I do, however, find the following: exceptfds will be watched for exceptions. On exit, the sets are modified in place to indicate which descriptors actually changed status. If there is a time out, it makes sense that no descriptors changed state, and so everything would be zeroed out. And actually, the example seems to support this: if (retval) printf(Data is available now.\n); /* FD_ISSET(0, rfds) will be true. */ The comment seems to indicate that if retval is 0, then FD_ISSET will be false. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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.5] buz.c won't compile
On Mon, May 28, 2001 at 03:15:04PM -0400, Ricky Beam wrote: > PS: I really hate it when people break "functional" things in the "stable" > tree. (functional and stable are both open to debate.) I was under the impression that it really wasn't functional. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: File read.
On Mon, May 28, 2001 at 11:26:31AM -0700, Davide Libenzi wrote: > > On 28-Jun-2001 Anil Kumar wrote: > > hi, > > How do i read file within the kernel modules. I hope we can't use the FS > > open... calls within kernel. > > You can access fs methods directly. But generally you don't want to. Use a user mode application to feed you the data instead. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: File read.
On Mon, May 28, 2001 at 11:26:31AM -0700, Davide Libenzi wrote: On 28-Jun-2001 Anil Kumar wrote: hi, How do i read file within the kernel modules. I hope we can't use the FS open... calls within kernel. You can access fs methods directly. But generally you don't want to. Use a user mode application to feed you the data instead. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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.5] buz.c won't compile
On Mon, May 28, 2001 at 03:15:04PM -0400, Ricky Beam wrote: PS: I really hate it when people break functional things in the stable tree. (functional and stable are both open to debate.) I was under the impression that it really wasn't functional. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote: > Not only that, but Alan said that somebody is rewriting it in C. I'll believe it when I see it. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Sun, May 20, 2001 at 11:33:20PM -0700, Ben Ford wrote: Not only that, but Alan said that somebody is rewriting it in C. I'll believe it when I see it. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: > distributions). 18 months is more realistic for it to be deployed > widely enough. People who are going to be savvy enough to install a development 2.5.* kernel that is defining a new configuration utility are going to be savvy enough to install python. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Mon, May 21, 2001 at 02:29:17AM +0200, Jes Sorensen wrote: distributions). 18 months is more realistic for it to be deployed widely enough. People who are going to be savvy enough to install a development 2.5.* kernel that is defining a new configuration utility are going to be savvy enough to install python. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac10
On Fri, May 18, 2001 at 11:12:32PM -0300, Rik van Riel wrote: > Basic rule for VM: once you start swapping, you cannot > win; All you can do is make sure no situation loses > really badly and most situations perform reasonably. Do you mean paging in general or thrashing? I always thought: paging good, thrashing bad. A good effecient paging system, always moving data between memory and disk, is great. It's when you have the greater than physical memory working set that things go to hell in a hand basket. Did Linux ever do the old trick of "We've too much going on! You! (randomly points to a process) take a seat! You're not running for a while!" and the process gets totatlly swapped out for a "while," not even scheduled? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote: > 1. Some of us are perfectly satisfied with the existing tools and don't want > them to be yanked out from under us. Then stay with 2.4.x > 2. Some of us have no interest in Python and don't like being forced to deal > with installing/upgrading it just for CML2. Some don't like installing/upgrading the following just for a kernel: gcc binutils modutils mount Not to mention netfilter. -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote: > Christoph Hellwig wrote: > Yes, I should have limited myself to pre-egcs versions. Huh? It's been possible to have multiple versions of gcc installed for a very long time. At least since 2.0 came out. Thu Dec 19 15:54:29 1991 K. Richard Pixley (rich at cygnus.com) * configure: added -V for version number option. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 12:00:59PM -0400, John Cowan wrote: Christoph Hellwig wrote: Yes, I should have limited myself to pre-egcs versions. Huh? It's been possible to have multiple versions of gcc installed for a very long time. At least since 2.0 came out. Thu Dec 19 15:54:29 1991 K. Richard Pixley (rich at cygnus.com) * configure: added -V for version number option. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Fri, May 18, 2001 at 03:04:43PM -0500, [EMAIL PROTECTED] wrote: 1. Some of us are perfectly satisfied with the existing tools and don't want them to be yanked out from under us. Then stay with 2.4.x 2. Some of us have no interest in Python and don't like being forced to deal with installing/upgrading it just for CML2. Some don't like installing/upgrading the following just for a kernel: gcc binutils modutils mount Not to mention netfilter. -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.4-ac10
On Fri, May 18, 2001 at 11:12:32PM -0300, Rik van Riel wrote: Basic rule for VM: once you start swapping, you cannot win; All you can do is make sure no situation loses really badly and most situations perform reasonably. Do you mean paging in general or thrashing? I always thought: paging good, thrashing bad. A good effecient paging system, always moving data between memory and disk, is great. It's when you have the greater than physical memory working set that things go to hell in a hand basket. Did Linux ever do the old trick of We've too much going on! You! (randomly points to a process) take a seat! You're not running for a while! and the process gets totatlly swapped out for a while, not even scheduled? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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 add suffix for uname -r
On Sun, May 06, 2001 at 10:12:17AM +0200, Lars Marowsky-Bree wrote: > You assign a new EXTRAVERSION to the new kernel you are building, and keep the > old kernel at the old name. Except that some patches (ie, RAID, -ac) use EXTRAVERSION. There needs to be a new variable, say USERVERSION, that will *ONLY* be set during make USERVERSION=foo. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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 add suffix for uname -r
On Sun, May 06, 2001 at 10:12:17AM +0200, Lars Marowsky-Bree wrote: You assign a new EXTRAVERSION to the new kernel you are building, and keep the old kernel at the old name. Except that some patches (ie, RAID, -ac) use EXTRAVERSION. There needs to be a new variable, say USERVERSION, that will *ONLY* be set during make USERVERSION=foo. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: Hierarchy doesn't solve the problem
On Thu, May 03, 2001 at 03:46:20AM -0400, Eric S. Raymond wrote: > What's to prefer? You get essentially the same behavior unless you start > with a broken config. What's going to happen when this interconnected behavior results in a previously acceptable config becomes broken (by definition) with a later kernel version? We're going to have hundreds of people complaining about this. Not just one or two. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: Hierarchy doesn't solve the problem
On Thu, May 03, 2001 at 03:46:20AM -0400, Eric S. Raymond wrote: What's to prefer? You get essentially the same behavior unless you start with a broken config. What's going to happen when this interconnected behavior results in a previously acceptable config becomes broken (by definition) with a later kernel version? We're going to have hundreds of people complaining about this. Not just one or two. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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.3+ sound distortion
On Sat, Apr 21, 2001 at 06:04:47PM +0200, Victor Julien wrote: > I have a problem with kernels higher than 2.4.2, the sound distorts when > playing a song with xmms while the seti@home client runs. 2.4.2 did not have Would this be the same issue as describe in these threads: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0104.0/0233.html http://www.uwsg.indiana.edu/hypermail/linux/kernel/0104.1/0231.html That is, the change in how nice is recalculated. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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.3+ sound distortion
On Sat, Apr 21, 2001 at 06:04:47PM +0200, Victor Julien wrote: I have a problem with kernels higher than 2.4.2, the sound distorts when playing a song with xmms while the seti@home client runs. 2.4.2 did not have Would this be the same issue as describe in these threads: http://www.uwsg.indiana.edu/hypermail/linux/kernel/0104.0/0233.html http://www.uwsg.indiana.edu/hypermail/linux/kernel/0104.1/0231.html That is, the change in how nice is recalculated. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: Cross-referencing frenzy
On Wed, Apr 18, 2001 at 10:49:01PM -0600, Andreas Dilger wrote: > However, I'm not sure that your reasoning for removing these is correct. > For example, one symbol that I saw was CONFIG_EXT2_CHECK, which is code > that used to be enabled in the kernel, but is currently #ifdef'd out with > the above symbol. When Ted changed this, he wasn't sure whether we would How about something besides CONFIG_ then? Like maybe DEV_CONFIG_ or DEV_. The CONFIG_ name space should be reserved for things that can be configured via the config mechanism. Things that only developers or special testers might want should use something other than the CONFIG_ namespace. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: Cross-referencing frenzy
On Wed, Apr 18, 2001 at 10:49:01PM -0600, Andreas Dilger wrote: However, I'm not sure that your reasoning for removing these is correct. For example, one symbol that I saw was CONFIG_EXT2_CHECK, which is code that used to be enabled in the kernel, but is currently #ifdef'd out with the above symbol. When Ted changed this, he wasn't sure whether we would How about something besides CONFIG_ then? Like maybe DEV_CONFIG_ or DEV_. The CONFIG_ name space should be reserved for things that can be configured via the config mechanism. Things that only developers or special testers might want should use something other than the CONFIG_ namespace. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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/
PS2 mouse data point
Just an interesting data point here. A while back (8-10 months ago), I'd thought I'd blown my ps2 mouse port on my motherboard and was using a serial mouse. Having just moved and reconnecting everything, I decided to give it a try again. Built kernel 2.4.2. Basically, I got the problem down to this: cat /dev/psaux Hit keyboard... instant lockup. (well, if I had the network up yet, I might have been able to telnet in, I'm not certain at this time) It turns out the ps2 mouse port was disabled in the BIOS and one of the two ethernet cards (dsl+homenetwork) was getting IRQ 12. Things weren't too happy (actually, fact that a network card was causing the conflict could have prevented network from working. Have to try that sometime). Anyway, I simply enabled the stupid thing in the BIOS and everything is working great. I just find it odd that if I had that disabled in the BIOS that catting /dev/psaux would cause any problems what so ever. I'm not sure what would happen if I tried to cat /dev/psaux with no mouse attached and disabled in BIOS. But I could see where some system might try to auto detect mice and the system "lock up." Also, I'd seen several posts about similar issues in the linux-kernel archive, but no documented solution. Certainly nothing so simple as "enable the stupid thing in BIOS." So for archival sake... here it is. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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/
PS2 mouse data point
Just an interesting data point here. A while back (8-10 months ago), I'd thought I'd blown my ps2 mouse port on my motherboard and was using a serial mouse. Having just moved and reconnecting everything, I decided to give it a try again. Built kernel 2.4.2. Basically, I got the problem down to this: cat /dev/psaux Hit keyboard... instant lockup. (well, if I had the network up yet, I might have been able to telnet in, I'm not certain at this time) It turns out the ps2 mouse port was disabled in the BIOS and one of the two ethernet cards (dsl+homenetwork) was getting IRQ 12. Things weren't too happy (actually, fact that a network card was causing the conflict could have prevented network from working. Have to try that sometime). Anyway, I simply enabled the stupid thing in the BIOS and everything is working great. I just find it odd that if I had that disabled in the BIOS that catting /dev/psaux would cause any problems what so ever. I'm not sure what would happen if I tried to cat /dev/psaux with no mouse attached and disabled in BIOS. But I could see where some system might try to auto detect mice and the system "lock up." Also, I'd seen several posts about similar issues in the linux-kernel archive, but no documented solution. Certainly nothing so simple as "enable the stupid thing in BIOS." So for archival sake... here it is. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: bizarre TCP behavior
On Wed, Apr 11, 2001 at 02:21:42AM +0200, Andi Kleen wrote: > Try echo 0 > /proc/sys/net/ipv4/tcp_ecn > If it helps complain to the sites that their firewall is broken. It's certain that this refers only to the site firewall? I had to do this to get to www.ibm.com. :-< mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: Let init know user wants to shutdown
On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Pavel Machek <[EMAIL PROTECTED]> wrote:
> >Init should get to know that user pressed power button (so it can do
> >shutdown and poweroff). Plus, it is nice to let user know that we can
>
> Not so hasty ;)
>
> >+printk ("acpi: Power button pressed!\n");
> >+kill_proc (1, SIGTERM, 1);
[reasons deleted]
Is using a signal the appropriate thing to do anyway?
Wouldn't there be better solutions?
Perhaps a mechanism a user space program can use to communicate to the kernel
(ala arpd/kerneld message queues, or something like klogd). Then a more
general user space tool could be used that would do policy appropriate
stuff, ending with init 0.
mrc
--
Mike Castle Life is like a clock: You can work constantly
[EMAIL PROTECTED] and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
-
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: Let init know user wants to shutdown
On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
In article [EMAIL PROTECTED],
Pavel Machek [EMAIL PROTECTED] wrote:
Init should get to know that user pressed power button (so it can do
shutdown and poweroff). Plus, it is nice to let user know that we can
Not so hasty ;)
+printk ("acpi: Power button pressed!\n");
+kill_proc (1, SIGTERM, 1);
[reasons deleted]
Is using a signal the appropriate thing to do anyway?
Wouldn't there be better solutions?
Perhaps a mechanism a user space program can use to communicate to the kernel
(ala arpd/kerneld message queues, or something like klogd). Then a more
general user space tool could be used that would do policy appropriate
stuff, ending with init 0.
mrc
--
Mike Castle Life is like a clock: You can work constantly
[EMAIL PROTECTED] and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
-
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: bizarre TCP behavior
On Wed, Apr 11, 2001 at 02:21:42AM +0200, Andi Kleen wrote: Try echo 0 /proc/sys/net/ipv4/tcp_ecn If it helps complain to the sites that their firewall is broken. It's certain that this refers only to the site firewall? I had to do this to get to www.ibm.com. :- mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: gcc-2.95.3
On Fri, Apr 06, 2001 at 08:49:51AM +0800, Jeff Chua wrote: > > Does anybody have bad experience with gcc-2.95.3? > > I'm using gcc-2.95.2 with linux 2.4.3 and have no problem with it. I've built and using 2.4.2 with 2.95.3 with no issues. [I should say, with no more issues than I have normally with this cheesey motherboard :-]. At least the long long computation bug on non i686 compilations is fixed with 2.95.3. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: gcc-2.95.3
On Fri, Apr 06, 2001 at 08:49:51AM +0800, Jeff Chua wrote: Does anybody have bad experience with gcc-2.95.3? I'm using gcc-2.95.2 with linux 2.4.3 and have no problem with it. I've built and using 2.4.2 with 2.95.3 with no issues. [I should say, with no more issues than I have normally with this cheesey motherboard :-]. At least the long long computation bug on non i686 compilations is fixed with 2.95.3. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: /proc/config idea
On Tue, Apr 03, 2001 at 09:12:18PM +0200, J . A . Magallon wrote: > Just like the Alan Cox for 2.4 or Andrea Arcangeli for 2.2. Lets say you > have 2.4.2-ac27. For each of your compiles, set EXTRAVERSION to -ac27-bf1, > -ac27-bf2, etc. Your files will be: Some patches, such as the RAID patches, sets up EXTRAVERSION to a specific value. I do with the make file also had a USERVERSION that would be hands off for anyone but the builder. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: /proc/config idea
On Tue, Apr 03, 2001 at 09:12:18PM +0200, J . A . Magallon wrote: Just like the Alan Cox for 2.4 or Andrea Arcangeli for 2.2. Lets say you have 2.4.2-ac27. For each of your compiles, set EXTRAVERSION to -ac27-bf1, -ac27-bf2, etc. Your files will be: Some patches, such as the RAID patches, sets up EXTRAVERSION to a specific value. I do with the make file also had a USERVERSION that would be hands off for anyone but the builder. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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/
2.4.2 IDE data point
=m CONFIG_USB_KBD=m CONFIG_USB_MOUSE=m CONFIG_USB_WACOM=m # # USB Imaging devices # CONFIG_USB_DC2XX=m CONFIG_USB_MDC800=m CONFIG_USB_SCANNER=m CONFIG_USB_MICROTEK=m # # USB Multimedia devices # CONFIG_USB_IBMCAM=m CONFIG_USB_OV511=m CONFIG_USB_DSBR=m CONFIG_USB_DABUSB=m # # USB Network adaptors # CONFIG_USB_PLUSB=m CONFIG_USB_PEGASUS=m CONFIG_USB_NET1080=m # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m # CONFIG_USB_SERIAL_DEBUG is not set CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_OMNINET=m # # USB misc drivers # CONFIG_USB_RIO500=m # # Kernel hacking # CONFIG_MAGIC_SYSRQ=y -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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/
2.4.2 IDE data point
OUSE=m CONFIG_USB_WACOM=m # # USB Imaging devices # CONFIG_USB_DC2XX=m CONFIG_USB_MDC800=m CONFIG_USB_SCANNER=m CONFIG_USB_MICROTEK=m # # USB Multimedia devices # CONFIG_USB_IBMCAM=m CONFIG_USB_OV511=m CONFIG_USB_DSBR=m CONFIG_USB_DABUSB=m # # USB Network adaptors # CONFIG_USB_PLUSB=m CONFIG_USB_PEGASUS=m CONFIG_USB_NET1080=m # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m # CONFIG_USB_SERIAL_DEBUG is not set CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_OMNINET=m # # USB misc drivers # CONFIG_USB_RIO500=m # # Kernel hacking # CONFIG_MAGIC_SYSRQ=y -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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] use correct include dir for build tools
On Thu, Feb 22, 2001 at 02:40:55PM -0800, Robert Read wrote: > Ok, my bad, I forgot about cross-compiles. The problem was > scripts/split-include.c includes errno.h, which requires linux/errno.h > to exist, and I thought it would be better to use the current kernel's > version, rather than the system version. I guess not. Oh no. Definitely not. Linus went on a tirade not too long ago about that. You can search the kernel archives for the details and long heated threads. But it comes down to this: For user space compiling, the kernel include files should be those that libc was built against. For kernel space compiling, the kernel include files should be those that the components will link against (static or modules). So, theoretically, a package that has both components should take care to do the proper includes. But that's it. (libc does usually take care to be able to build against a later kernel version than you're running on, and determine at run time what features may or may not be there, so one could have a 2.4.2 kernel handy to build libc against while still running a 2.2.18 kernel. Theoretically.) mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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] use correct include dir for build tools
On Thu, Feb 22, 2001 at 02:40:55PM -0800, Robert Read wrote: Ok, my bad, I forgot about cross-compiles. The problem was scripts/split-include.c includes errno.h, which requires linux/errno.h to exist, and I thought it would be better to use the current kernel's version, rather than the system version. I guess not. Oh no. Definitely not. Linus went on a tirade not too long ago about that. You can search the kernel archives for the details and long heated threads. But it comes down to this: For user space compiling, the kernel include files should be those that libc was built against. For kernel space compiling, the kernel include files should be those that the components will link against (static or modules). So, theoretically, a package that has both components should take care to do the proper includes. But that's it. (libc does usually take care to be able to build against a later kernel version than you're running on, and determine at run time what features may or may not be there, so one could have a 2.4.2 kernel handy to build libc against while still running a 2.2.18 kernel. Theoretically.) mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: gzipped executables
On Mon, Feb 12, 2001 at 11:09:39PM -0600, Matt Stegman wrote: > Is there any kernel patch that would allow Linux to properly recognize, > and execute gzipped executables? What's wrong with using gzexe? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: gzipped executables
On Mon, Feb 12, 2001 at 11:09:39PM -0600, Matt Stegman wrote: Is there any kernel patch that would allow Linux to properly recognize, and execute gzipped executables? What's wrong with using gzexe? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - 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: spelling of disc (disk) in /devfs
On Thu, Feb 01, 2001 at 12:19:56AM +, Alan Chandler wrote: > I now find myself confused with the new approach. try "man -k disc" and compare the output with "man -k disk" Since nearly all of the utilities refer to "disk" rather than "disc," it would make more since to be consistent with that. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: spelling of disc (disk) in /devfs
On Thu, Feb 01, 2001 at 12:19:56AM +, Alan Chandler wrote: I now find myself confused with the new approach. try "man -k disc" and compare the output with "man -k disk" Since nearly all of the utilities refer to "disk" rather than "disc," it would make more since to be consistent with that. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Recommended swap for 2.4.x.
On Mon, Jan 29, 2001 at 03:23:35PM -0800, [EMAIL PROTECTED] wrote: > On Mon, Jan 29, 2001 at 02:57:44PM -0800, Alan Olsen wrote: > > The standard rule is usually memory x 2. (But that is more a Solaris > > superstition than anything else.) > > This always struck me as the most stupid rule of thumb I'd ever heard of. > With this metric, systems which precisely need swap the most (low-RAM systems) > get the least of it, and those that need it the least (those with gigs of RAM) > get tons of swap they don't need. I don't know how this keeps perpetuating, > as it should be plainly brain damaged to anybody who thinks about it for a > couple of seconds, but somehow it does. Because it used to be necessary. Early VM systems *required* at least one page of swap for every page of physical ram. In theory, the entire contents of physical ram would be copied at any time onto swap, and whenever it was necessary to free up a page to bring in a new one, it would already be on backing store and could easily be freed up. This was prior to things like being able to page in binaries from file systems on demand, so your programs had to be swapped back out as well. So, basically, your totally usable paging area was the sum of swap space. Not the sum of swap space + physical memory. Now, granted, this is no longer the case for most (all?) VM based systems, the rule of thumb has such strong momentum behind it that it's difficult to stop. Now, personally, I tend to throw on a few meg of swap onto each disk and stripe swap across them for performance. If I find I ever run out of memory under normal use, I'll up it. But I've never had that happen. Swap space depends on how you use it. Set up some stuff, and monitor with free every once in a while. If you never hit swap, then reduce it or eliminate it. If you are constantly running over 1/3 of it or so, might consider upping it a little bit. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Recommended swap for 2.4.x.
On Mon, Jan 29, 2001 at 03:23:35PM -0800, [EMAIL PROTECTED] wrote: On Mon, Jan 29, 2001 at 02:57:44PM -0800, Alan Olsen wrote: The standard rule is usually memory x 2. (But that is more a Solaris superstition than anything else.) This always struck me as the most stupid rule of thumb I'd ever heard of. With this metric, systems which precisely need swap the most (low-RAM systems) get the least of it, and those that need it the least (those with gigs of RAM) get tons of swap they don't need. I don't know how this keeps perpetuating, as it should be plainly brain damaged to anybody who thinks about it for a couple of seconds, but somehow it does. Because it used to be necessary. Early VM systems *required* at least one page of swap for every page of physical ram. In theory, the entire contents of physical ram would be copied at any time onto swap, and whenever it was necessary to free up a page to bring in a new one, it would already be on backing store and could easily be freed up. This was prior to things like being able to page in binaries from file systems on demand, so your programs had to be swapped back out as well. So, basically, your totally usable paging area was the sum of swap space. Not the sum of swap space + physical memory. Now, granted, this is no longer the case for most (all?) VM based systems, the rule of thumb has such strong momentum behind it that it's difficult to stop. Now, personally, I tend to throw on a few meg of swap onto each disk and stripe swap across them for performance. If I find I ever run out of memory under normal use, I'll up it. But I've never had that happen. Swap space depends on how you use it. Set up some stuff, and monitor with free every once in a while. If you never hit swap, then reduce it or eliminate it. If you are constantly running over 1/3 of it or so, might consider upping it a little bit. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting stat(2)
On Thu, Jan 18, 2001 at 09:52:02PM +0100, Igmar Palsenberg wrote: > I use lstat to check if a config file is a symlink, and if it is, it > refuses to open it. Nice race condition. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Documenting stat(2)
On Thu, Jan 18, 2001 at 09:52:02PM +0100, Igmar Palsenberg wrote: I use lstat to check if a config file is a symlink, and if it is, it refuses to open it. Nice race condition. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ORBit speed measure
On Thu, Dec 14, 2000 at 11:10:24AM -0600, Chris Lattner wrote: > There are many other optimizations that one can make the transport faster > that ORBit doesn't implement. For example, you could mmap (shared) data > buffers between the two processes communicating (of course, you still need > to wake processes up, which is why it hasn't been done yet), or you could This is not necessarily faster. I recently came across some discussions on the web from Jim Gettys that discussed similar issues for X (unix sockets vs shared memory). I seem to remember that the over head of synchronizing stuff to keep the shared memory in a sane state ate away at any gains one had with using shared memory. It works ok for large chunks of data (say, things on the order of sizes of pixmaps), but not for smaller pieces, like say, function call arguments. Then again, isn't Jim some how involved in ORBit and GNOME? Or just a big supporter? :-> mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ORBit speed measure
On Thu, Dec 14, 2000 at 11:10:24AM -0600, Chris Lattner wrote: There are many other optimizations that one can make the transport faster that ORBit doesn't implement. For example, you could mmap (shared) data buffers between the two processes communicating (of course, you still need to wake processes up, which is why it hasn't been done yet), or you could This is not necessarily faster. I recently came across some discussions on the web from Jim Gettys that discussed similar issues for X (unix sockets vs shared memory). I seem to remember that the over head of synchronizing stuff to keep the shared memory in a sane state ate away at any gains one had with using shared memory. It works ok for large chunks of data (say, things on the order of sizes of pixmaps), but not for smaller pieces, like say, function call arguments. Then again, isn't Jim some how involved in ORBit and GNOME? Or just a big supporter? :- mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: gcc-2.95.2-51 is buggy
On Sun, Nov 26, 2000 at 04:33:25PM +0100, Olaf Dietsche wrote: > A simple `gcc -march=i686' or `gcc -mpentiumpro' does fix it as > well. So, if you configure your kernel with `CONFIG_M686=y' the problem > should be gone. Btw, was this ever tested on other arch's? I don't remember seeing anything come across this list. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: gcc-2.95.2-51 is buggy
On Sun, Nov 26, 2000 at 04:33:25PM +0100, Olaf Dietsche wrote: A simple `gcc -march=i686' or `gcc -mpentiumpro' does fix it as well. So, if you configure your kernel with `CONFIG_M686=y' the problem should be gone. Btw, was this ever tested on other arch's? I don't remember seeing anything come across this list. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
On Mon, Oct 16, 2000 at 04:47:09PM -0400, Alexander Viro wrote: > tmp = *p++; > *q = f(tmp, *p++); > return p; > > is equivalent to more idiomatic > > *q = f(p[0], p[1]); > return p+2; Which gets better assembler out of various versions of gcc? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Patch to remove undefined C code
On Mon, Oct 16, 2000 at 04:47:09PM -0400, Alexander Viro wrote: tmp = *p++; *q = f(tmp, *p++); return p; is equivalent to more idiomatic *q = f(p[0], p[1]); return p+2; Which gets better assembler out of various versions of gcc? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (OT -- Partition Magic for Linux?) Re: Newer motherboards / CPU's / hardware with Linux
On Mon, Oct 09, 2000 at 02:08:55AM -0700, Miles Lane wrote: > like Partition Magic? It sure would be nice to have a native > version of Partition Magic or an Open Source work-alike. > Is anyone aware of a project to implement such an Open Source > alternative? ftp://ftp.gnu.org/gnu/parted -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (OT -- Partition Magic for Linux?) Re: Newer motherboards / CPU's / hardware with Linux
On Mon, Oct 09, 2000 at 02:08:55AM -0700, Miles Lane wrote: like Partition Magic? It sure would be nice to have a native version of Partition Magic or an Open Source work-alike. Is anyone aware of a project to implement such an Open Source alternative? ftp://ftp.gnu.org/gnu/parted -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2 Backport Terminated ...
On Tue, Sep 12, 2000 at 04:31:07PM -0700, Andre Hedrick wrote:
> Do to limits in personal bandwidth and other projects that need to get
> done, I can no longer keep up the back port of the ATA code.
Bummer.
The 2.2.17 ide code doesn't work for me.
I used to use 2.2.15pre15 with ide. With 2.2.17+ide, I have problems.
2.2.17 standard works however (if a little slower, I think).
I haven't had time to work out all of the specifics, but this is what I
saw.
The motherboard I'm using is a Spacewalker/Shuttle HOT-557 v1.5 with
latest BIOS. This motherboard is 430VX chipset based (not the best, but
hey, it was free). I've also just recently added an old SoundBlaster AWE32
as a 3rd ide to throw on an old cdrom and another harddrive:
I'm currently running 2.2.17+raid, though not using the raid yet (just
starting to play with it, which is why the upgrade from 2.2.15pre15 to
2.2.17 anyway). So the follow collections of information (dmesg output and
find /proc/pci -type f | xargs pr) is for both 2.2.17+raid and
2.2.17+ide+raid. If need it without raid, I can do it. Just will take a
while.
===
Linux version 2.2.17raid (root@thune) (gcc version 2.95.2 19991024 (release)) #4 Wed
Sep 6 13:56:49 CDT 2000
Detected 233226 kHz processor.
Console: colour VGA+ 80x28
Calibrating delay loop... 465.31 BogoMIPS
Memory: 79668k/81920k available (760k kernel code, 412k reserved, 1028k data, 52k init)
Dentry hash table entries: 16384 (order 5, 128k)
Buffer cache hash table entries: 131072 (order 7, 512k)
Page cache hash table entries: 32768 (order 5, 128k)
CPU: Intel Pentium MMX stepping 03
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
Intel Pentium with F0 0F bug - workaround enabled.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfb000
PCI: Using configuration type 1
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 131072 bhash 65536)
Initializing RT netlink socket
Starting kswapd v 1.5
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.09
PIIX3: IDE controller on PCI bus 00 dev 39
PIIX3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hda: Maxtor 91303D6, ATA DISK drive
hdb: Maxtor 53073U6, ATA DISK drive
hdc: Maxtor 93652U8, ATA DISK drive
hdd: Maxtor 92048U8, ATA DISK drive
hdg: probing with STATUS(0x00) instead of ALTSTATUS(0x80)
hdg: HITACHI CDR-7930, ATAPI CDROM drive
hdh: probing with STATUS(0x50) instead of ALTSTATUS(0xd0)
hdh: Maxtor 53073H6, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide3 at 0x168-0x16f,0x36e on irq 10
hda: Maxtor 91303D6, 12427MB w/512kB Cache, CHS=12624/32/63, (U)DMA
hdb: Maxtor 53073U6, 29311MB w/2048kB Cache, CHS=59554/16/63, (U)DMA
hdc: Maxtor 93652U8, 34837MB w/2048kB Cache, CHS=4441/255/63, (U)DMA
hdd: Maxtor 92048U8, 19470MB w/2048kB Cache, CHS=39560/16/63, (U)DMA
hdh: Maxtor 53073H6, 29311MB w/2048kB Cache, CHS=59554/16/63
md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12
raid5: measuring checksumming speed
raid5: MMX detected, trying high-speed MMX checksum routines
pII_mmx : 342.900 MB/sec
p5_mmx: 393.573 MB/sec
8regs : 244.602 MB/sec
32regs: 195.453 MB/sec
using fastest function: p5_mmx (393.573 MB/sec)
md.c: sizeof(mdp_super_t) = 4096
Partition check:
hda: hda1 hda2 hda3 hda4
hdb: hdb1 hdb2 hdb3
hdc: hdc1 hdc2 hdc3
hdd: hdd1 hdd2 hdd3 hdd4
hdh: hdh1 hdh2 hdh3
autodetecting RAID arrays
autorun ...
... autorun DONE.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 52k freed
NET4: Unix domain sockets 1.0 for Linux NET4.0.
Adding Swap: 66016k swap-space (priority 1)
Adding Swap: 131504k swap-space (priority 1)
Adding Swap: 65988k swap-space (priority 1)
hdc: timeout waiting for DMA
hdc: irq timeout: status=0xd0 { Busy }
hdc: DMA disabled
hdd: DMA disabled
ide1: reset: success
hdb: timeout waiting for DMA
hdb: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hda: status timeout: status=0xd0 { Busy }
hda: DMA disabled
hdb: DMA disabled
hda: drive not ready for command
ide0: reset: success
(read) hdh3's sb offset: 131456 [events: ]
md: invalid raid superblock magic on hdh3
md: hdh3 has invalid sb, not importing!
could not import hdh3!
autostart hdh3 failed!
tulip.c:v0.91g-ppc 7/16/99 [EMAIL PROTECTED]
eth0: Lite-On 82c168 PNIC rev 32 at 0x6400, 00:A0:CC:26:67:40, IRQ 11.
eth0: MII transceiver #1 config 3100 status 7829 advertising 01e1.
eth1: Lite-On PNIC-II rev 37 at 0x6800, 00:A0:CC:E4:8C:F6, IRQ 12.
Serial driver version 4.27 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at
Re: 2.2 Backport Terminated ...
On Tue, Sep 12, 2000 at 04:31:07PM -0700, Andre Hedrick wrote:
Do to limits in personal bandwidth and other projects that need to get
done, I can no longer keep up the back port of the ATA code.
Bummer.
The 2.2.17 ide code doesn't work for me.
I used to use 2.2.15pre15 with ide. With 2.2.17+ide, I have problems.
2.2.17 standard works however (if a little slower, I think).
I haven't had time to work out all of the specifics, but this is what I
saw.
The motherboard I'm using is a Spacewalker/Shuttle HOT-557 v1.5 with
latest BIOS. This motherboard is 430VX chipset based (not the best, but
hey, it was free). I've also just recently added an old SoundBlaster AWE32
as a 3rd ide to throw on an old cdrom and another harddrive:
I'm currently running 2.2.17+raid, though not using the raid yet (just
starting to play with it, which is why the upgrade from 2.2.15pre15 to
2.2.17 anyway). So the follow collections of information (dmesg output and
find /proc/pci -type f | xargs pr) is for both 2.2.17+raid and
2.2.17+ide+raid. If need it without raid, I can do it. Just will take a
while.
===
Linux version 2.2.17raid (root@thune) (gcc version 2.95.2 19991024 (release)) #4 Wed
Sep 6 13:56:49 CDT 2000
Detected 233226 kHz processor.
Console: colour VGA+ 80x28
Calibrating delay loop... 465.31 BogoMIPS
Memory: 79668k/81920k available (760k kernel code, 412k reserved, 1028k data, 52k init)
Dentry hash table entries: 16384 (order 5, 128k)
Buffer cache hash table entries: 131072 (order 7, 512k)
Page cache hash table entries: 32768 (order 5, 128k)
CPU: Intel Pentium MMX stepping 03
Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
Intel Pentium with F0 0F bug - workaround enabled.
POSIX conformance testing by UNIFIX
PCI: PCI BIOS revision 2.10 entry at 0xfb000
PCI: Using configuration type 1
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
TCP: Hash tables configured (ehash 131072 bhash 65536)
Initializing RT netlink socket
Starting kswapd v 1.5
Detected PS/2 Mouse Port.
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.09
PIIX3: IDE controller on PCI bus 00 dev 39
PIIX3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hda: Maxtor 91303D6, ATA DISK drive
hdb: Maxtor 53073U6, ATA DISK drive
hdc: Maxtor 93652U8, ATA DISK drive
hdd: Maxtor 92048U8, ATA DISK drive
hdg: probing with STATUS(0x00) instead of ALTSTATUS(0x80)
hdg: HITACHI CDR-7930, ATAPI CDROM drive
hdh: probing with STATUS(0x50) instead of ALTSTATUS(0xd0)
hdh: Maxtor 53073H6, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide3 at 0x168-0x16f,0x36e on irq 10
hda: Maxtor 91303D6, 12427MB w/512kB Cache, CHS=12624/32/63, (U)DMA
hdb: Maxtor 53073U6, 29311MB w/2048kB Cache, CHS=59554/16/63, (U)DMA
hdc: Maxtor 93652U8, 34837MB w/2048kB Cache, CHS=4441/255/63, (U)DMA
hdd: Maxtor 92048U8, 19470MB w/2048kB Cache, CHS=39560/16/63, (U)DMA
hdh: Maxtor 53073H6, 29311MB w/2048kB Cache, CHS=59554/16/63
md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12
raid5: measuring checksumming speed
raid5: MMX detected, trying high-speed MMX checksum routines
pII_mmx : 342.900 MB/sec
p5_mmx: 393.573 MB/sec
8regs : 244.602 MB/sec
32regs: 195.453 MB/sec
using fastest function: p5_mmx (393.573 MB/sec)
md.c: sizeof(mdp_super_t) = 4096
Partition check:
hda: hda1 hda2 hda3 hda4
hdb: hdb1 hdb2 hdb3
hdc: hdc1 hdc2 hdc3
hdd: hdd1 hdd2 hdd3 hdd4
hdh: hdh1 hdh2 hdh3
autodetecting RAID arrays
autorun ...
... autorun DONE.
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 52k freed
NET4: Unix domain sockets 1.0 for Linux NET4.0.
Adding Swap: 66016k swap-space (priority 1)
Adding Swap: 131504k swap-space (priority 1)
Adding Swap: 65988k swap-space (priority 1)
hdc: timeout waiting for DMA
hdc: irq timeout: status=0xd0 { Busy }
hdc: DMA disabled
hdd: DMA disabled
ide1: reset: success
hdb: timeout waiting for DMA
hdb: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hda: status timeout: status=0xd0 { Busy }
hda: DMA disabled
hdb: DMA disabled
hda: drive not ready for command
ide0: reset: success
(read) hdh3's sb offset: 131456 [events: ]
md: invalid raid superblock magic on hdh3
md: hdh3 has invalid sb, not importing!
could not import hdh3!
autostart hdh3 failed!
tulip.c:v0.91g-ppc 7/16/99 [EMAIL PROTECTED]
eth0: Lite-On 82c168 PNIC rev 32 at 0x6400, 00:A0:CC:26:67:40, IRQ 11.
eth0: MII transceiver #1 config 3100 status 7829 advertising 01e1.
eth1: Lite-On PNIC-II rev 37 at 0x6800, 00:A0:CC:E4:8C:F6, IRQ 12.
Serial driver version 4.27 with no serial options enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at
Re: Linux 2.2.18pre4
On Sun, Sep 10, 2000 at 07:57:38PM -0700, David S. Miller wrote: > So basically the situation is that people prefer to switch the whole > OS as opposed to applying a kernel patch? Or multiple kernel patches. NFS. RAID. IDE. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, Sep 10, 2000 at 07:57:38PM -0700, David S. Miller wrote: So basically the situation is that people prefer to switch the whole OS as opposed to applying a kernel patch? Or multiple kernel patches. NFS. RAID. IDE. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
