Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Thu, 14 Dec 2000, josef [iso-8859-1] höök wrote: > Chip Salzenberg wrote: > > > According to Alexander Viro: > > > 9P is quite simple and unlike CORBA it had been designed for taking > > > kernel stuff to userland. Besides, authors definitely understand > > > UNIX... > > > > As nice as 9P is, it'll need some tweaks to work with Linux. > > For example, it limits filenames to 30 characters; that's not OK. > > -- > > Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> > >"Give me immortality, or give me death!" // Firesign Theatre > > > > Another thing in mind that if we would want to use 9P we would also need to > port IL . It can live atop of TCP, it can live atop of AF_UNIX. IL would be nice for more than one reason, though... - 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: Signal 11 - the continuing saga
On Wed, 13 Dec 2000, Linus Torvalds wrote: > On Wed, 13 Dec 2000, Linus Torvalds wrote: > > > > Hint: "ptep_mkdirty()". rather obvious oopsie.. once spotted. > In case you wonder why the bug was so insidious, what this caused was two > separate problems, both of them able to cause SIGSGV's. > > One: we didn't mark the page table entry dirty like we were supposed to. > > Two: by making it writable, we also made the page shared, even if it > wasn't supposed to be shared (so when the next process wrote to the page, > if the swap page was shared with somebody else, the changes would show up > even in the process that _didn't_ write to it). > > And "ptep_mkdirty()" is only used by swapoff, so nothing else would show > this. Which was why it hadn't been immediately obvious that anything was > broken. The terminal OOM problem is now gone and I haven't seen a SIGSEGV yet running virgin source. IOU 5 bogo$$ -Mike (I still see something with IKD that _could_ be timing related troubles. There are a couple of grubby fingerprints I need to wipe off, and some churn/burn hours to be sure) - 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: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Thu, 14 Dec 2000, Chris Lattner wrote: > > Oh, great. So we don't have to care about formatting changes. We just > > have to care about the data changes. IOW, we are shielded from the > > results of changes that should never happen in the first place. And the > > benefit being...? > > What the hell are you talking about? Did you even read my example? I was > giving an example of extending an API, adding new functionality to it. Yes, I did. What I don't understand is how kernel mechanism for marshalling would make your life easier wrt changes. > > Notice that we could equally well add /dev/floatymouse and everything that > > worked with old API would keep working. The only programs that would need > > to know about floats would be ones that would... need to know about floats > > since they want to work with them. > > Wonderful solution. This is exactly what you would _have_ to do. Are you > aware of why devfs came into existence? It is because there are already > so damn many device nodes in /dev. Lets keep adding more. And? The only _wrong_ thing here is storing that stuff on a physical disk. Let the driver export the filesystem and union-mount it on /dev. End of story. Or mount it anywhere else, whatever place makes you happy. It's not like we were eating majors/minors that way... > > Notice also that I can say ls /dev/*mouse* and get some idea of the files > > there. I can't do that for your interfaces. > > And you know what? I can't do ls /dev/*net* and get all the network > devices either. Actually, one of the very cool things about CORBA is that > you can BROWSE/LIST/SEARCH all objects currently instantiated. Being > able to browse all in kernel objects would be very cool. So what's to stop you from letting readdir() do the work? WTF do we need one more API for returning the list of objects? > > The point being: if your program spends efforts on marshalling it would > > better _do_ something with the obtained data. And then we are back to > > the square 1. > > Uh huh, go ahead and read the example I sent to you. Did that. > > Returning to your example, I could not tee(1) the stream into file for > > later analysis. Not unless I write a special-case program for intercepting > > that stuff. I don't see why it is a good thing. > > On the contrary, it would be pretty easy to do something like that with > CORBA. No you wouldn't be able to use tee, but why would you want to tee > a binary data file? The only reason that tee works in this situation is For the same reasons why I use tar, gzip, whatever. I don't _want_ to invent a new utility every time when Joe Doe adds a new piece of interface. Data is data is data. I can uuencode it and send to somebody who would care to analize the bloody thing. Do you mean that I need to write a special tool for that? For _every_ member of every interface somebody decided to add? I don't think so. I really don't. > because it's agnostic to the format of the data coming off the Exactly. > line... your analysis program would have to have special purpose code to > parse the file. EVERY consumer of "mouse data" would have to parse the Or I would look at the size. Or I would say od and look at the result. Don't tell me what to do with the data, when I'll need to parse it I will. And if you expect me to bother with writing more stuff when generic tools would work fine - too bad, I've been there, done that and I'm not coming back. BTW, you cared about size of /dev, didn't you? /usr/bin choke-full of tee-foo, tee-bar, yodda, yodda would be better? > file. That seems pretty silly to me. Difference between good program and bad one: the former gets used in ways its authors never thought about... > > I also don't see where the need in new system calls (or ioctls, same shit) > > comes from. Notice that your way is much closer to new system call than > > read()/write() of the right stuff. > > A new syscall was one example. It would be very simple to implement this > by making _yet_another_ device node in /dev and issue reads and writes to > it. That's more of a syntactic issue than a symantic one. No, it isn't. The difference being: letting driver to define a filesystem and mounting/exporting it/whatever means that you get to use _all_ _normal_ _data-agnostic_ _tools_. And believe me, it matters. If you don't understand that - no offense, but you don't understand UNIX. To get this stuff working without excessive PITA you'll need to teach userland about the new mechanism. Shells, mailers, archivers, backup, you name it. It might be an interesting OS, but it sure as hell wouldn't be UNIX and what's worse, it doesn't exist. Mix of that CORBA_OS and UNIX would be extremely nasty. I have a serious suspicion that CORBA_OS in itself would be a wonderful illustration to "Why Pascal is Not My Favorite Programming Language", but that's another story (BTW, that paper may make an interesting reading - check
Re: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit
> > NO. You want leagacy program to "just get" rounded ints, and new programs > > to get the "full precision" of the floating point #'s. > What rounded ints? Rounded to zero? To nearest integer? To plus or minus > infinity? Does program have something to say here? The exact same thing that older mouse drivers did. In this particular case, it doesn't matter anyways, because it's a simple example. If you REALLY care about rounding those coordinates a certain way, it's trivial to add an extra component to the interface. > ... > My mouse example > ... > Oh, great. So we don't have to care about formatting changes. We just > have to care about the data changes. IOW, we are shielded from the > results of changes that should never happen in the first place. And the > benefit being...? What the hell are you talking about? Did you even read my example? I was giving an example of extending an API, adding new functionality to it. > Notice that we could equally well add /dev/floatymouse and everything that > worked with old API would keep working. The only programs that would need > to know about floats would be ones that would... need to know about floats > since they want to work with them. Wonderful solution. This is exactly what you would _have_ to do. Are you aware of why devfs came into existence? It is because there are already so damn many device nodes in /dev. Lets keep adding more. Why is it (for example) that on my machine (mandrake 7 install, no devfs), I automatically get inodes for ISDN & PPP!?! Well, because ISDN has a slightly different interface, and you're talking to a different driver that is not transparently hidden to the user. Why can't I just open /dev/net0 and get the first network device? Because we have so many inconsistent, poorly design, inextensible interfaces laying around, thats why. > Notice also that I can say ls /dev/*mouse* and get some idea of the files > there. I can't do that for your interfaces. And you know what? I can't do ls /dev/*net* and get all the network devices either. Actually, one of the very cool things about CORBA is that you can BROWSE/LIST/SEARCH all objects currently instantiated. Being able to browse all in kernel objects would be very cool. > The point being: if your program spends efforts on marshalling it would > better _do_ something with the obtained data. And then we are back to > the square 1. Uh huh, go ahead and read the example I sent to you. > Returning to your example, I could not tee(1) the stream into file for > later analysis. Not unless I write a special-case program for intercepting > that stuff. I don't see why it is a good thing. On the contrary, it would be pretty easy to do something like that with CORBA. No you wouldn't be able to use tee, but why would you want to tee a binary data file? The only reason that tee works in this situation is because it's agnostic to the format of the data coming off the line... your analysis program would have to have special purpose code to parse the file. EVERY consumer of "mouse data" would have to parse the file. That seems pretty silly to me. > I also don't see where the need in new system calls (or ioctls, same shit) > comes from. Notice that your way is much closer to new system call than > read()/write() of the right stuff. A new syscall was one example. It would be very simple to implement this by making _yet_another_ device node in /dev and issue reads and writes to it. That's more of a syntactic issue than a symantic one. > As for the proc/meminfo... What would you do to a userland programmer who > had defined a structure like that? Let's see: way too large, ugly as hell, > many fields are almost guaranteed to become meaningless at later point... > It was not designed, it got accreted. And that's very mild description - > judging by results it might as well be s/ac/ex/. There is no provision in CORBA that prevents the creation of ugly interfaces. There is no provision in C that prevents them either, as witnessed by this example. At least with CORBA, I can extend the interface to actually return meaningful results while still maintaining backwards compatibility with programs that don't actually look at that field (as is done now by sticking the 0 in there). The trick is having enough foresight to design robust interfaces. I'm not saying that I'm an expert at that, and obviously nobody can be. What I _am_ saying is that CORBA/kORBit gives you flexibility in how you do interfaces, and it lets you "future proof" them (obviously only within reason). Adding a new device node everytime an API gets changed is like defining a different API for every hard disk that exists. Seems kinda silly. -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/MagicStats/ http://korbit.sourceforge.net/ - 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
Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Wed, 13 Dec 2000, Chris Lattner wrote:
> > OK, now I'm completely confused.
> > * which complex data structures do you want to export from the kernel
> > in non-opaque way?
> > * which of those structures are guaranteed to remain unchanged?
> > * if you have userland-to-userland RPC in mind - why put anything
> > marshalling-related into the kernel?
>
> Okay, I think I did my best to completely confuse you. :) #1: CORBA
> objects _are_ opaque. #2 is irrelevant due to #1. #3: userland->userland
> is not the interesting part. We want kernel->userland or user->kernel, as
> the common (ie fast) case, but we also want to do client->client or
> kernel->kernel without anything breaking.
> > ints and received a bunch of doubles... You either need to decide on
> > rounding (and it's a non-obvious question) or you need to change quite a
> > bit of code in your program. It goes way past the demarshalling, no
> > matter whether you use CORBA, 9P or printf/scanf.
>
> NO. You want leagacy program to "just get" rounded ints, and new programs
> to get the "full precision" of the floating point #'s.
What rounded ints? Rounded to zero? To nearest integer? To plus or minus
infinity? Does program have something to say here?
> Original interface for the mouse:
>
> interface mouse {
> void getPosition(out long X, out long Y);
> };
>
> So if you get the mouse interface in CORBA (which is an opaque object),
> you get back something that you can make requests to, and, for example,
> get the coordinate the mouse is currently at. Okay, that's fine, 15 years
> later and after much legacy software has been developed, company X
> develops a new high precions floating point mouse. Well crap, don't want
> to change the interface. Now instead of getting that, you get the
> "mouse2" or "floaty mouse" interface (for sake of argument suppose that
> we actually did want to use FP arithmetic in the kernel, that's an
> artifact of a bad example, not a bad point :):
>
> interface floatymouse : extends mouse {
> void getFloatyPosition(out float X, out float Y);
> }
>
> Now people that get the "/dev/mouse" interface get a floatymouse. Does
> this break all that leagacy mouse wielding code? No, because we used
> inheritance, the floatymouse is a superset of the mouse, and the original
> interface still works. The server/kernel side of the floaty mouse just
> chops off the decimal places when you use the getPosition method.
Oh, great. So we don't have to care about formatting changes. We just
have to care about the data changes. IOW, we are shielded from the
results of changes that should never happen in the first place. And the
benefit being...?
Notice that we could equally well add /dev/floatymouse and everything that
worked with old API would keep working. The only programs that would need
to know about floats would be ones that would... need to know about floats
since they want to work with them.
Notice also that I can say ls /dev/*mouse* and get some idea of the files
there. I can't do that for your interfaces.
The point being: if your program spends efforts on marshalling it would
better _do_ something with the obtained data. And then we are back to
the square 1.
Returning to your example, I could not tee(1) the stream into file for
later analysis. Not unless I write a special-case program for intercepting
that stuff. I don't see why it is a good thing.
I also don't see where the need in new system calls (or ioctls, same shit)
comes from. Notice that your way is much closer to new system call than
read()/write() of the right stuff.
As for the proc/meminfo... What would you do to a userland programmer who
had defined a structure like that? Let's see: way too large, ugly as hell,
many fields are almost guaranteed to become meaningless at later point...
It was not designed, it got accreted. And that's very mild description -
judging by results it might as well be s/ac/ex/.
-
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: ANNOUNCE: Linux Kernel ORB: kORBit
At 12:15 AM 12/14/2000 -0500, you wrote: >Hmm... Cutoff seems to sit somewhere around 45 - above that there are only >apt-get droppings and they definitely are over the top. Dunno, you may be >right, but looks like I never had a need to create anything that long. It's always good to be able to include at least two date-time pairs in a filename... especially for scientific stuff. -- This message has been brought to you by the letter alpha and the number pi. Open Source: Think locally; act globally. David Feuer [EMAIL PROTECTED] - 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: ANNOUNCE: Linux Kernel ORB: kORBit
On Wed, 13 Dec 2000, Chip Salzenberg wrote: > As long as names are to be created, or at least understood, by humans, > there will be some limit on *usable* length. In my experience, 255 is > above that limit, but 30 is below it. And I cut my teeth on a system > that had exactly that length limitation (UNOS). Maybe... I definitely agree that 14 is below the limit, but 30... Hell knows, from what I see on the box I'm using right now it seems to fall into several cathegories: * Very-Long-And-Verbose-Named-HOWTO.html * manpages for X and Tcl functions with obscenely long names * *.deb and corresponding *.diff.gz and *.dsc * var/state/apt/lists/* * ghostscript maps Hmm... Cutoff seems to sit somewhere around 45 - above that there are only apt-get droppings and they definitely are over the top. Dunno, you may be right, but looks like I never had a need to create anything that long. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12 randomly hangs up
Byron Stanoszek wrote: > > On Wed, 13 Dec 2000, Lukasz Trabinski wrote: > > > In article <[EMAIL PROTECTED]> you wrote: > > > > > I can (re)confirm that. I work several hours on console without any > > > problem ... then I start X session and after several minutes system > > > hangs. > > > > I can confirm that, too. > > Todaye, crashed two difference machines > > One: AMD-K6 3D, 300 MHz, RH 7.0 + updates, 64MB RAM > > Second one: AMD Athlon 600, 600MHz with, 128MB RAM, RH 7.0+updates > > > > > Red Hat 7.0, XFree-3.3.6 (SVGA server), S3Virge/G2 (4MB) > > I've been running 2.4.0-test12 patched with only the O_SYNC bug fix and I have > _not_ experienced any lockups on this machine. > > Classic Athlon 825(750) MHz, 128MB Ram, > RH 7.0 based w/glibc 2.2, XFree-3.3.6 (S3 Trio 64 accel server), gcc 2.95.2 > > Not sure what the problem is yet... keep trying folks. :) > Maybe it's the 3.3.6. RH 7.0 comes with 4.0.1, and a newer glibc. Perhaps try recompiling XFree86 against the latest RH 7.0 glibc (2.1.94) and see what happens, or upgrade your XFree86 to the standard RH 7.0 XFree86 4.0.1. -- Matthew Vanecek perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... - 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: CORBA vs 9P
I think that I addressed most if not all of this email in my previous one... let me know if I missed something. -Chris btw, thanks for putting up with me, I know I can be obstinate sometimes. :) On Wed, 13 Dec 2000, Alexander Viro wrote: > > > On Wed, 13 Dec 2000, Chris Lattner wrote: > > > > > Okay, so there are _stubs_ for these platforms. How many languages are > > > > there bindings for? > > > Grr... Let's define the terms, OK? What is available: kernel code that > > > represents the client side of RPC as a filesystem. Userland clients do > > > not know (or care) about the mechanisms involved. > > > > But they DO CARE about the format of the data. > > And how would CORBA help here? Because format changes are usually coming > from the _contents_ changes. And if you don't care about the contents - > why the hell do you retrieve the object int the first place? > > > > And files with structure are things of dreadful past. BTDT. > > > You really need to... work with an OS that would have and enforce > > > "structured files" to appreciate the beauty of ASCII streams. > > > > Ahhh, so ASCII streams are a wonderful thing. Are you an XML fan? :) > > No, thanks. > > > > However, that's a different story. What I _really_ don't understand > > > is the need to export anything structured from kernel to userland. > > > > Okay, how about a few examples. How about /proc/meminfo? How about the > > "stat" structure? How about /proc/stat? You seem to be indicating that > > ASCII files are fine for general exportation of kernel information. The > > Yes, _if_ you take care to think what you are exporting. /proc/meminfo is > a shi..ning example of _not_ doing that over many years. > > > /proc filesystem begs to differ. One specific example is the > > /proc/meminfo file. Why is it that one field is 0 now? Ouch we can't > > change the format of the file because we'll break some program. Crap, you > > want to add a field, well, tough luck. > > Oh, cool. So CORBA would magically change the definition of the structure in > your (C/Modula-3/APL/COBOL) programs. How? And what would happen with the > code that used to access the field in question? > > > The struct stat example is one _trivial_ example of "the need to export > > anything structured from kernel to userland". > > It's a trivial example of "why you need to think before deciding what to > export". > > > > IOW, I would really like to see a description of use of your > > > mechanism. If it's something along the lines of "let's take a network > > > card driver, implement it in userland and preserve the current API" - > > > see the comment about layering violations. You've taken an internal > ^ > > > API and exposed it to userland in all gory details. See also your own > > > comment about internal APIs being not convenient for such operations. > > > > I'm not trying to dictate interfaces. I'm not trying to tell people what > > to use this stuff for. I'm arguing that it's useful and that you can do > > very interesting things with it. > > And when interface changes, you do what, exactly? > > > > If it's something else - I wonder what kind of objects you are talking > > > about and why opaque stuff (== file descriptors) would not be sufficient. > > > > Opaque stuff is fine. I have no problem with file descriptors. They > > effectively solve the exact same class of problems that CORBA does, except > > that they add significant _API BLOAT_ because every little "method" that > > implements them gets a syscall. > > Huh? Could you elaborate, please? > > -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/MagicStats/ http://korbit.sourceforge.net/ - 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: ANNOUNCE: Linux Kernel ORB: kORBit
> OK, now I'm completely confused.
> * which complex data structures do you want to export from the kernel
> in non-opaque way?
> * which of those structures are guaranteed to remain unchanged?
> * if you have userland-to-userland RPC in mind - why put anything
> marshalling-related into the kernel?
Okay, I think I did my best to completely confuse you. :) #1: CORBA
objects _are_ opaque. #2 is irrelevant due to #1. #3: userland->userland
is not the interesting part. We want kernel->userland or user->kernel, as
the common (ie fast) case, but we also want to do client->client or
kernel->kernel without anything breaking.
> > /dev/mouse for example. Combine that with the problem that /dev/mouse
> > might change format in the future (okay stupid example, but you get the
> > idea) to use floating point coordinates, and things certainly get hairy.
> HUH? OK, suppose it had happened. Do you really expect that you will not
> need to change your applications? I mean, if you expected a bunch of
YES. You should not have to change your apps at all.
> ints and received a bunch of doubles... You either need to decide on
> rounding (and it's a non-obvious question) or you need to change quite a
> bit of code in your program. It goes way past the demarshalling, no
> matter whether you use CORBA, 9P or printf/scanf.
NO. You want leagacy program to "just get" rounded ints, and new programs
to get the "full precision" of the floating point #'s.
> OK, suppose you have a CORBA-based system and mouse drivers' API had been
> changed - they really want to return floating point coordinates. How will
> CORBA help you? Aside of making your programs scream aloud, that is.
Okay, maybe this isn't a terrible example afterall. :) Consider this
theoretical API for a mouse, that I'm certainly not saying is wonderful or
perfect, just consider it to be an example (on the fly), and no it
doesn't let you poll for mouse activity, this is just off the cuff:
Original interface for the mouse:
interface mouse {
void getPosition(out long X, out long Y);
};
So if you get the mouse interface in CORBA (which is an opaque object),
you get back something that you can make requests to, and, for example,
get the coordinate the mouse is currently at. Okay, that's fine, 15 years
later and after much legacy software has been developed, company X
develops a new high precions floating point mouse. Well crap, don't want
to change the interface. Now instead of getting that, you get the
"mouse2" or "floaty mouse" interface (for sake of argument suppose that
we actually did want to use FP arithmetic in the kernel, that's an
artifact of a bad example, not a bad point :):
interface floatymouse : extends mouse {
void getFloatyPosition(out float X, out float Y);
}
Now people that get the "/dev/mouse" interface get a floatymouse. Does
this break all that leagacy mouse wielding code? No, because we used
inheritance, the floatymouse is a superset of the mouse, and the original
interface still works. The server/kernel side of the floaty mouse just
chops off the decimal places when you use the getPosition method.
This is the kind of stuff that I'm talking about. The concept that a
mouse is more than a byte stream... that there is actual structure that
must be understood before a datastream can be used.
Yes, I am very aware that there are other ways of doing this, but CORBA is
a very general & powerful system that is also quite mature (unlike
kORBit. ;)
I hope this helps clarify what the heck I'm talking about. :)
-Chris
btw, just imagine how much cleaner the mount interface could be... ;)
http://www.nondot.org/~sabre/os/
http://www.nondot.org/MagicStats/
http://korbit.sourceforge.net/
-
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: Adaptec AIC7XXX v 6.0.6 BETA Released
> Date: Wed, 13 Dec 2000 20:56:08 -0700 > From: "Justin T. Gibbs" <[EMAIL PROTECTED]> > > None-the-less, it seems to me that spamming the kernel namespace > with "current" in at least the way that the 2.2 kernels do (does > this occur in later kernels?) should be corrected. > >Justin, "current" is a pointer to the current thread executing on the >current processor under Linux. It has existed since day one of the >Linux kernel and probably will exist till the end of it's life. > >I'm sure the BSD kernel has some similar bogosity :-) BSD has curproc, but that is considerably less likely to be used in "inoccent code" than "current". I mean, "current what?". It could be anything, current privledges, current process, current thread, the current time... -- Justin - 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: ANNOUNCE: Linux Kernel ORB: kORBit
According to Alexander Viro: > On Wed, 13 Dec 2000, Chip Salzenberg wrote: > > According to Alexander Viro: > > > On Wed, 13 Dec 2000, Chip Salzenberg wrote: > > > > According to Alexander Viro: > > > > > 9P is quite simple and unlike CORBA it had been designed for taking > > > > > kernel stuff to userland. Besides, authors definitely understand > > > > > UNIX... > > > > > > > > As nice as 9P is, it'll need some tweaks to work with Linux. > > > > For example, it limits filenames to 30 characters; that's not OK. > > > > > > For RPC-style uses? Why? > > > > For the same reason C compilers recognize more than eight significant > > characters in externals, even though ANSI doesn't require them to. > > s/30/255/ and you've got a big problem with ext2... As long as names are to be created, or at least understood, by humans, there will be some limit on *usable* length. In my experience, 255 is above that limit, but 30 is below it. And I cut my teeth on a system that had exactly that length limitation (UNOS). -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> "Give me immortality, or give me death!" // Firesign Theatre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12 randomly hangs up
On Wed, 13 Dec 2000, Lukasz Trabinski wrote: > In article <[EMAIL PROTECTED]> you wrote: > > > I can (re)confirm that. I work several hours on console without any > > problem ... then I start X session and after several minutes system > > hangs. > > I can confirm that, too. > Todaye, crashed two difference machines > One: AMD-K6 3D, 300 MHz, RH 7.0 + updates, 64MB RAM > Second one: AMD Athlon 600, 600MHz with, 128MB RAM, RH 7.0+updates > > > Red Hat 7.0, XFree-3.3.6 (SVGA server), S3Virge/G2 (4MB) > > > (no problems with -test11 and 2.2.x before ...) > > Exactly Not here. I've been seeing occasional hard freezes since test10. Mostly after a period of idle cpu (reading kernel code.. reader enters catatonic state with smoke pouring out ears;) X isn't running. -Mike - 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: ANNOUNCE: Linux Kernel ORB: kORBit
On Wed, 13 Dec 2000, Chip Salzenberg wrote: > According to Alexander Viro: > > On Wed, 13 Dec 2000, Chip Salzenberg wrote: > > > According to Alexander Viro: > > > > 9P is quite simple and unlike CORBA it had been designed for taking > > > > kernel stuff to userland. Besides, authors definitely understand > > > > UNIX... > > > > > > As nice as 9P is, it'll need some tweaks to work with Linux. > > > For example, it limits filenames to 30 characters; that's not OK. > > > > For RPC-style uses? Why? > > For the same reason C compilers recognize more than eight significant > characters in externals, even though ANSI doesn't require them to. s/30/255/ and you've got a big problem with ext2... - 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: ANNOUNCE: Linux Kernel ORB: kORBit
On Wed, 13 Dec 2000, Chris Lattner wrote: > Which is exactly why it doesn't work well for many applications. The > problem is this: how do you get from a byte stream to a structured data > stream? There are many answers: > > 1. Keep your data structures so simple, that it's obvious. Not a good > choice. :) > 2. Defined interfaces to the bytestream for every interface that you > define. > 3. Define a standard for inflating/deflating "things" into > bytestreams. Oh wait, that's what corba does. :) OK, now I'm completely confused. * which complex data structures do you want to export from the kernel in non-opaque way? * which of those structures are guaranteed to remain unchanged? * if you have userland-to-userland RPC in mind - why put anything marshalling-related into the kernel? > The 9P way of doing things is not fundementally new, they just applied the > idea that "everything is a file" more broadly. What annoys me is that it > is not immediately obvious how to "demarshall" the data that comes out of > /dev/mouse for example. Combine that with the problem that /dev/mouse > might change format in the future (okay stupid example, but you get the > idea) to use floating point coordinates, and things certainly get hairy. HUH? OK, suppose it had happened. Do you really expect that you will not need to change your applications? I mean, if you expected a bunch of ints and received a bunch of doubles... You either need to decide on rounding (and it's a non-obvious question) or you need to change quite a bit of code in your program. It goes way past the demarshalling, no matter whether you use CORBA, 9P or printf/scanf. OK, suppose you have a CORBA-based system and mouse drivers' API had been changed - they really want to return floating point coordinates. How will CORBA help you? Aside of making your programs scream aloud, that is. - 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/
Source address selection
Hi,
In 2.2.x and/or 2.4.x, is there any way of preventing IP address[es]
attached to interface aliases being selected as a source address when
userland code creates a socket without binding to a particular address ?
>From Documentation/proc.txt:
/proc/sys/net/ipv4/conf/hidden
Hide addresses attached to this device from another devices. Such
addresses will never be selected by source address autoselection
mechanism, host does not answer broadcast ARP requests for them, does
not announce it as source address of ARP requests, but they are still
reachable via IP. This flag is activated only if it is enabled both in
specific device section and in "all" section.
The part about "Such addresses will never be selected by source address
autoselection" seems to be exactly what I want. I'm not so sure
about the "does not answer broadcast ARP requests" part. Does this mean
that an interface marked as 'hidden' can't accept incoming connections ?
However the proc entry applies per real interface and there doesn't seem
to be a way of applying it per alias interface.
The situation is...
I have a host ("gw") currently running 2.2.16, connected via a single
physical interface to a switch. Also on the switch are several upstream
providers, and a bunch of other devices: hosts, access servers etc. The
switch is VLANed so that there is no direct traffic between the
upstreams and the other devices, it's all routed by gw. Gw is running
BGP (Zebra) to the upstreams. To establish the BGP sessions, gw has
several interface aliases with IP addresses as assigned by the
upstreams.
With the interface aliases configured, "gw" is sending packets into our
network with source addresses of the interface aliases. This causes
issues with firewalling etc., but also causes problems for protocols
that require forward and reverse name lookups to match (e.g. kerberos),
as we are not in control of these IPs. I'd like to prevent the box from
using the IPs on the aliases as source addresses, except of course when
an application binds to that address.
Is there a way to do this ?
Or is there a better way of dealing with the problem ?
Cheers,
Chris.
-
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: CORBA vs 9P
> > Okay, so there are _stubs_ for these platforms. How many languages are > > there bindings for? > Grr... Let's define the terms, OK? What is available: kernel code that > represents the client side of RPC as a filesystem. Userland clients do > not know (or care) about the mechanisms involved. But they DO CARE about the format of the data. > And files with structure are things of dreadful past. BTDT. > You really need to... work with an OS that would have and enforce > "structured files" to appreciate the beauty of ASCII streams. Ahhh, so ASCII streams are a wonderful thing. Are you an XML fan? :) > However, that's a different story. What I _really_ don't understand > is the need to export anything structured from kernel to userland. Okay, how about a few examples. How about /proc/meminfo? How about the "stat" structure? How about /proc/stat? You seem to be indicating that ASCII files are fine for general exportation of kernel information. The /proc filesystem begs to differ. One specific example is the /proc/meminfo file. Why is it that one field is 0 now? Ouch we can't change the format of the file because we'll break some program. Crap, you want to add a field, well, tough luck. The struct stat example is one _trivial_ example of "the need to export anything structured from kernel to userland". > IOW, I would really like to see a description of use of your > mechanism. If it's something along the lines of "let's take a network > card driver, implement it in userland and preserve the current API" - > see the comment about layering violations. You've taken an internal > API and exposed it to userland in all gory details. See also your own > comment about internal APIs being not convenient for such operations. I'm not trying to dictate interfaces. I'm not trying to tell people what to use this stuff for. I'm arguing that it's useful and that you can do very interesting things with it. > If it's something else - I wonder what kind of objects you are talking > about and why opaque stuff (== file descriptors) would not be sufficient. Opaque stuff is fine. I have no problem with file descriptors. They effectively solve the exact same class of problems that CORBA does, except that they add significant _API BLOAT_ because every little "method" that implements them gets a syscall. Oh yeah, they you get ioctl too. Funness. :) -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/MagicStats/ http://korbit.sourceforge.net/ - 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: Adaptec AIC7XXX v 6.0.6 BETA Released
Date:Wed, 13 Dec 2000 20:56:08 -0700 From: "Justin T. Gibbs" <[EMAIL PROTECTED]> None-the-less, it seems to me that spamming the kernel namespace with "current" in at least the way that the 2.2 kernels do (does this occur in later kernels?) should be corrected. Justin, "current" is a pointer to the current thread executing on the current processor under Linux. It has existed since day one of the Linux kernel and probably will exist till the end of it's life. I'm sure the BSD kernel has some similar bogosity :-) Later, David S. Miller [EMAIL PROTECTED] - 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: swapoff/on leak test12-pre7
On Sat, 9 Dec 2000, Mike Galbraith wrote: > Hi, > > Stumbled over a small leak.. and some funny looking numbers. Numbers aren't funny looking.. bad eyeballs. > while true; do swapoff -a; swapon -a; done Leak is because the page allocated in swapon has buffers. Since it's not on any list, they never get scrubbed off and the page is leaked. (I killed it here with try_to_free_buffers().. works) -Mike - 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: ANNOUNCE: Linux Kernel ORB: kORBit
On Wed, 13 Dec 2000, Chip Salzenberg wrote: > According to Alexander Viro: > > 9P is quite simple and unlike CORBA it had been designed for taking > > kernel stuff to userland. Besides, authors definitely understand > > UNIX... > > As nice as 9P is, it'll need some tweaks to work with Linux. > For example, it limits filenames to 30 characters; that's not OK. For RPC-style uses? Why? - 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: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Wed, 13 Dec 2000, Chris Lattner wrote: > > > > either. Oops, wasn't interoperability an important part of the Linux > > > kernel design? Didn't we want to use and follow and define _real_ > > > standards? > > Erm... 9P stub exists for Linux. It exists for FreeBSD. I suspect that > > it exists for other *BSD too - never checked that. > > Okay, so there are _stubs_ for these platforms. How many languages are > there bindings for? Grr... Let's define the terms, OK? What is available: kernel code that represents the client side of RPC as a filesystem. Userland clients do not know (or care) about the mechanisms involved. > > You mentioned OOP, didn't you? Encapsulation is a good thing and what you > > are talking about is "layering violations made Real Easy(tm)". > > I simply don't see why _that_ is a good goal. > > I completely fail to see how I'm breaking encapsulation or making layering > violations easy. Why I'm talking about is the fact that CORBA doesn't > care how you ship bytes around: it's a higher level protocol that cares > about shipping "things" around. Bytes are old school, "stuff" is the wave > of the future. ;) heh. And files with structure are things of dreadful past. BTDT. You really need to... work with an OS that would have and enforce "structured files" to appreciate the beauty of ASCII streams. However, that's a different story. What I _really_ don't understand is the need to export anything structured from kernel to userland. IOW, I would really like to see a description of use of your mechanism. If it's something along the lines of "let's take a network card driver, implement it in userland and preserve the current API" - see the comment about layering violations. You've taken an internal API and exposed it to userland in all gory details. See also your own comment about internal APIs being not convenient for such operations. If it's something else - I wonder what kind of objects you are talking about and why opaque stuff (== file descriptors) would not be sufficient. - 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: ANNOUNCE: Linux Kernel ORB: kORBit
According to Alexander Viro: > 9P is quite simple and unlike CORBA it had been designed for taking > kernel stuff to userland. Besides, authors definitely understand > UNIX... As nice as 9P is, it'll need some tweaks to work with Linux. For example, it limits filenames to 30 characters; that's not OK. -- Chip Salzenberg- a.k.a. -<[EMAIL PROTECTED]> "Give me immortality, or give me death!" // Firesign Theatre - 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: ANNOUNCE: Linux Kernel ORB: kORBit
> > > plan-9.bell-labs.com/sys/man/ > Arrgh. s/plan-9/plan9/. My apologies. Cool, thanks, will read. :) > IDGI. What 9P gives is an RPC mechanism that uses normal (as in "named streams > of characters") representation on the client side and very light-weight > library on the server side. It looks like you are trying to do a mechanism > that would export arbitrary _internal_ kernel APIs. I really don't see > what you would want it for. Which is exactly why it doesn't work well for many applications. The problem is this: how do you get from a byte stream to a structured data stream? There are many answers: 1. Keep your data structures so simple, that it's obvious. Not a good choice. :) 2. Defined interfaces to the bytestream for every interface that you define. 3. Define a standard for inflating/deflating "things" into bytestreams. Oh wait, that's what corba does. :) The point of the matter is that CORBA gives you a nice, clean, well supported method of not having to write marshalling/demarshalling code every time you want to use an interface. Not only that, it lets you define "fast paths" for special cases (ie, with user level corba, if you are communicating between two objects in the same processes, you can do direct calls and do no marshalling). These fast paths do not interfere with the generality of the system at all. The 9P way of doing things is not fundementally new, they just applied the idea that "everything is a file" more broadly. What annoys me is that it is not immediately obvious how to "demarshall" the data that comes out of /dev/mouse for example. Combine that with the problem that /dev/mouse might change format in the future (okay stupid example, but you get the idea) to use floating point coordinates, and things certainly get hairy. Why reinvent the wheel countless times? -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/MagicStats/ http://korbit.sourceforge.net/ - 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: ANNOUNCE: Linux Kernel ORB: kORBit
On Wed, 13 Dec 2000, Chris Lattner wrote: > > plan-9.bell-labs.com/sys/man/ Arrgh. s/plan-9/plan9/. My apologies. > Err... yeah, so you're effectively mapping UNIX/POSIX across 9P. That's > not very creative, and you could do the same thing with CORBA. I ask > again, "How much development infrastructure is there for 9P?". If you say > "just use unix", then what is the point of 9P at all? (on linux). Linux > already has most of posix (and some would claim all of the "good > stuff" in posix.). IDGI. What 9P gives is an RPC mechanism that uses normal (as in "named streams of characters") representation on the client side and very light-weight library on the server side. It looks like you are trying to do a mechanism that would export arbitrary _internal_ kernel APIs. I really don't see what you would want it for. Notice that exporting a kernel API is possible right now and you don't need _any_ RPC for that. Check procfs/devfs/shmfs/etc. RPC comes into the game when you want to export the piece of namespace to other box or when userland server wants to export its stuff into namespace. IOW, you don't export internal interfaces via RPC, you publish them as a filesystem and then use RPC if you want to access it from another box. Where it looks like filesystem, again. _Another_ issue is with the stuff like plumber when you want to talk with userland program via filesystem, but you seem to be talking about something that looks like the first kind of situation... - 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] bsd-style cursor
Lennert Buytenhek wrote: > On Wed, 13 Dec 2000, James Simmons wrote: > > How about placing > > echo '\033[?17;120c' > > In one of your startup scripts. This will give you this nice BSD > > cursor you like. > > [ buytenh@mara buytenh]$ tail -1 ~/.bash_profile > echo -e -n '\033[?17;127c' > [buytenh@mara buytenh]$ > > This has Issues though: try entering vi for example. My /etc/inittab has lines that look like this: 1:2345:respawn:/sbin/getty 38400 tty1 -I '^[c^[[?17;55;248c' This gives me a nice red non-blinking cursor. No problems with vi whatsoever. Of course, this only works on the console, but for my terminal windows, I can set these values in resource or configuration files. So, all of this is a user-space problem. No need to complicate the kernel code. Markus -- Markus GutschkeResonate, Inc. 3637 Fillmore Street #106 385 Moffett Park Drive San Francisco, CA 94123-1600 Sunnyvale, CA 94089 +1-415-567-8449+1-408-548-5528 [EMAIL PROTECTED][EMAIL PROTECTED] - 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: Signal 11 - the continuing saga
On Wed, 13 Dec 2000, Linus Torvalds wrote: > On Wed, 13 Dec 2000, Mike Galbraith wrote: > > > > Not in my test tree. Same fault, and same trace leading up to it. no > > Ok. > > It definitely looks like a swapoff() problem. > > Have you ever seen the behaviour without running swapoff? No. > Also, can you re-create it without running swapon() (if it's something > like a lost dirty bit, it should be possible to trigger even without the > swapon, and I'd like to hear if that can happen - if it only happens with > swapon() and you can't trigger it with just a swapoff() it might be a > question of re-using some swap file stuff and delaying the writeout or > whatever). I'll try loading up swap, swapoff and then doing jobs that fit in ram. (hmm.. what about inactive_clean list when you do swapoff.. might there be pages sitting there that are [were] swap cache? reclaim_page=kaboom?) -Mike - 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: Adaptec AIC7XXX v 6.0.6 BETA Released
>Thanks for posting this. Unfortunately, the kernel won't build unless you >restore this macro to the namespace after aic7xxx_linux.h blows it away: > >--- linux-2.2.18/drivers/scsi/hosts.c.orig Wed Dec 13 20:27:34 2000 >+++ linux-2.2.18/drivers/scsi/hosts.c Wed Dec 13 20:26:22 2000 >@@ -137,6 +137,7 @@ > > #ifdef CONFIG_SCSI_AIC7XXX > #include "aic7xxx/aic7xxx_linux.h" >+#define current get_current() > #endif > > #ifdef CONFIG_SCSI_IPS > > >Steve I take it you had other controllers enabled? I tested this against 2.2.18-pre24 and didn't see any problems. I didn't enable anything other than the aic7xxx driver. Luckily, in newer kernels, the per-controller includes are no longer required in hosts.c. None-the-less, it seems to me that spamming the kernel namespace with "current" in at least the way that the 2.2 kernels do (does this occur in later kernels?) should be corrected. As you can see from my comment in aic7xxx_linux.h, I was very surprised to see this occur. I'll update my patch tomorrow to restore the definition of current. I do fear, however, that this will perpetuate the polution of the namespace should "current" ever get cleaned up. -- Justin - 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: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit
> > either. Oops, wasn't interoperability an important part of the Linux > > kernel design? Didn't we want to use and follow and define _real_ > > standards? > Erm... 9P stub exists for Linux. It exists for FreeBSD. I suspect that > it exists for other *BSD too - never checked that. Okay, so there are _stubs_ for these platforms. How many languages are there bindings for? What about Win32 (gross I know, but at least for now, it is important)? What about OS/2 what about Amiga and palm? CORBA is very popular for certain things... even inferno isn't nearly as big... > > Heh, that's interesting. _getting_ the data isn't hard in 9P, actually > > using it or displaying it in a meaningful way commonly requires something > > more than cat. :) > Same for any other RPC mechanism. Of course. Which is why CORBA is about putting STRUCTURE in that stream of random bytes coming over the wire. Why should I have to rewrite my marshalling and demarshalling code every time I want to write a server. read and write are fine. But sometimes I want a structure. Sometimes, my structures aren't laid out like C struct's either. What then? What if I want to send an "object" to you? > > nothing enforces it. 9P works wonderfully for Plan9 because they had the > > luxery of redefining/rewriting the whole OS, and the whole interaction > > with user space processes. We, unfortunately, don't have that > > possibility. :) > Notice that they _don't_ export random internal APIs to userland. And neither do we. Beautiful isn't it? :) > > Please don't get me wrong. I'm not opposed to other ideas, and 9P may in > > fact turn out to be a very nice protocol that would be able to support > > much kORBit level functionality). I do maintain that by writing a custom > > user->kernel marshalling library, you could obtain better peformance than > > 9P though, because you could take advantage of lots of machine specific > > optimizations. Hell you could even pass things in register if you'd have > > <= 4 args. :) > > You mentioned OOP, didn't you? Encapsulation is a good thing and what you > are talking about is "layering violations made Real Easy(tm)". > I simply don't see why _that_ is a good goal. I completely fail to see how I'm breaking encapsulation or making layering violations easy. Why I'm talking about is the fact that CORBA doesn't care how you ship bytes around: it's a higher level protocol that cares about shipping "things" around. Bytes are old school, "stuff" is the wave of the future. ;) heh. -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/MagicStats/ http://korbit.sourceforge.net/ - 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: test12 lockups -- need feedback
Here we go folks. I hope I got everything right. The only place I have a doubt is the 0010: part of EIP. I couldn't read what I wrote there. Looks like it's ip fragment related? ksymoops 0.7c on i686 2.4.0-test11. Options used -V (default) -K (specified) -L (specified) -o /lib/modules/2.4.0-test12 (specified) -m /usr/src/linux/System.map (default) No modules in ksyms, skipping objects invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: ebx: d15c83e0 ecx: d1f4aa60 edx: d1f4aa60 esi: 03d8 edi: d15c8660 ebp: 03d8 esp: c0303c1c ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0303000) Stack: d1f4aa60 625b d957accf 0014 c01e6493 d1f4aa60 d15c8660 d3fc9680 d15c8660 0008 c0303d28 011e51be d58ce1bf d15c8660 d58d0008 c0303018 0003 d58cd3ed d15c8660 d58d0d08 c0303018 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 3c 89 41 3c 8b 47 5c c7 47 18 00 00 00 00 01 41 18 8b >>EIP; c01e610e<= Trace; d957accf Trace; c01e6493 Trace; d58ce1bf Trace; d588 Trace; d58cd3ed Trace; d588 Trace; c012e146 <__alloc_pages+de/2d0> Trace; d58cf370 Trace; c01e88a4 Trace; c01d925c Trace; c01e88a4 Trace; c01e88a4 Trace; c01d94b7 Trace; c01e88a4 Trace; d58d0d08 Trace; c01e7faf Trace; c01e88a4 Trace; c01fdf2c Trace; c01e80be Trace; c01fdf2c Trace; c01fe122 Trace; c01fdf2c Trace; d957accf Trace; d957accf Trace; c01fe64b Trace; d58cc945 Trace; d58d0d38 Trace; d58cf2bf Trace; c01fe89a Trace; c01e59f3 Trace; c01e5a68 Trace; c01d94fa Trace; c01e5845 Trace; c01e5970 Trace; c01e5c0f Trace; c01e5a68 Trace; c01d94fa Trace; c01e593d Trace; c01e5a68 Trace; c01dce3d Trace; c011ef4f Trace; c010c891 Trace; c0109420 Trace; c0109420 Trace; c010b128 Trace; c0109420 Trace; c0109420 Trace; c0100018 Trace; c0109443 Trace; c01094a9 Trace; c0105000 Trace; c0100191 Code; c01e610e <_EIP>: Code; c01e610e<= 0: 8b 40 3c mov0x3c(%eax),%eax <= Code; c01e6111 3: 89 41 3c mov%eax,0x3c(%ecx) Code; c01e6114 6: 8b 47 5c mov0x5c(%edi),%eax Code; c01e6117 9: c7 47 18 00 00 00 00 movl $0x0,0x18(%edi) Code; c01e611e 10: 01 41 18 add%eax,0x18(%ecx) Code; c01e6121 13: 8b 00 mov(%eax),%eax On Wed, 13 Dec 2000, Mohammad A. Haque wrote: > Ok, got locked up. Dropped me into kdb and I was able to write down the > oops after doing a ss on btp 0. > > I'll try to have something posted in an hour. > -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - 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: ANNOUNCE: Linux Kernel ORB: kORBit
> > Err shame on you, don't forget about lcall and exceptions, and interrupts, > > and... That is technically more than _o_n_e_ "entry point". :) Oh wait, > > what about sysenter/exit too? :) > OK, you got me on lcall (however, that's iBCS-only, IIRC), but the rest... > what the hell does userland to interrupts? OK, make it 2 - pagefault > can be arguably used in that way. The reason that I considered exceptions and interrupts is that often, exceptions get reflected as signals to the running processes (SIGSEGV, SIGFPE, SIGILL, others?), and interrupts can wake up processes (from sys_poll among others). I was considering more of the user->kernel and kernel->user transitions... anyways, that's really besides the point. :) > > this wonderful design we get all kinds of stuff like sys_oldumount vs > > sys_umount and others... > Check how often anything uses the majority of that stuff... Correct, it's for backwards compatibility with old programs (for example libc5 uses a lot of those "old" syscalls). > > > Yes, standard RPC mechanism would be nice. No, CORBA is not a good > candidate - > > too baroque and actually known to lead to extremely > tasteless APIs being > > implemented over it. Yes, I mean GNOME. So > Check 9P and compare. Really. Section 5 of Plan 9 manpages. Available on > plan-9.bell-labs.com/sys/man/ That's fine. Since the server is down (or the URL is bad), can you please give me an example of how 9P is better than CORBA? I freely admit to not knowing much about 9P... how much do you know about CORBA (aside from your opinion that GNOME uses it, and therefore it is bad. ;)? > > without breaking backwards compatibility). Please don't tell me that OOP > > is bad... or else we will have the eviscerate the VFS layer from the > > kernel (amount other subsystems)... :) > OOP is a nice tool. However, it's a tool that has incredible potential of > shooting one's foot. It's wonderful if you have sane set of methods. And > that's a _big_ if. "Easily extensible" is not an absolutely good thing - > C++ wankers all over the world are busily proving it every day. Heck, they > make a living out of that. IOW, the problem with interface changes is _not_ > in converting the old code. It's in choosing the right changes. And that > part of the game can't be simplified. Oif. That's like telling someone that C is evil because it has for loops, and for loops can be used to write nasty code. "just write in assembler" he says. :) I would claim that someone could write a bad program (or shoot themselves in the foot) with any turing complete language. C++ definately give you more rope to do that with, but used wisely, it can also be nice. The trick is to just not have to work with other peoples C++ code. :) Hey, did I mention that kORBit and all its extensions are written in C? :) > > Like I mentioned in a previous email, CORBA does not preclude 9P. What > > it does buy you though, is compatibility with LOTS of preexisting CORBA > > tools. How much development infrastructure is there for 9P? I thought > > so. :) > All UNIX userland on the client side. lib9p on the server side (23Kb of sparse > C). Examples of use in servers - see the aforementioned site. Err... yeah, so you're effectively mapping UNIX/POSIX across 9P. That's not very creative, and you could do the same thing with CORBA. I ask again, "How much development infrastructure is there for 9P?". If you say "just use unix", then what is the point of 9P at all? (on linux). Linux already has most of posix (and some would claim all of the "good stuff" in posix.). > > For one of our demos, we ran a file server on a remote linux box (that we > > just had a user account on), mounted it on a kORBit'ized box, and ran > > programs on SPARC Solaris that accessed the kORBit'ized linux box's file > > syscalls. If nothing else, it's pretty nifty what you can do in little > > code... > Duh. And what's new about that? The "new" part is that our servers were < 100 lines of code each. Compare that to kNFS. :) -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/MagicStats/ http://korbit.sourceforge.net/ - 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: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Wed, 13 Dec 2000, Chris Lattner wrote: > > /me trims down CC list... > > > Local? Funny. It lives atop of TCP or IL quite fine. What's > > even funnier, I can use it to export /proc from CPU server to workstation > > and use _that_ for remote debugging. Ditto for window system. Ditto for > > DNS. Ditto for plumber. No, not on Linux... > > No not on linux. No definately not on Windows, no not on the BSD's > either. Oops, wasn't interoperability an important part of the Linux > kernel design? Didn't we want to use and follow and define _real_ > standards? Erm... 9P stub exists for Linux. It exists for FreeBSD. I suspect that it exists for other *BSD too - never checked that. > > What you do is mapping your RPC to hierarchical namespace. After > > that... What extensibility do you need? You can use every utility written > > for core UNIX API (open()/read()/write()/close()) as a client. No need > > to reinvent the wheel... > > Heh, that's interesting. _getting_ the data isn't hard in 9P, actually > using it or displaying it in a meaningful way commonly requires something > more than cat. :) Same for any other RPC mechanism. > The overriding problem with a simplistic 9P port is that linux kernel > functionality is not very well modularized. In fact, this prevents > wonderful CORBA integration as well: An agressive filesystem (for > example) often likes to touch the buffer cache or even the VM layer > (*cough*) directly. Some don't use the prescribed interfaces, because > nothing enforces it. 9P works wonderfully for Plan9 because they had the > luxery of redefining/rewriting the whole OS, and the whole interaction > with user space processes. We, unfortunately, don't have that > possibility. :) Notice that they _don't_ export random internal APIs to userland. > Please don't get me wrong. I'm not opposed to other ideas, and 9P may in > fact turn out to be a very nice protocol that would be able to support > much kORBit level functionality). I do maintain that by writing a custom > user->kernel marshalling library, you could obtain better peformance than > 9P though, because you could take advantage of lots of machine specific > optimizations. Hell you could even pass things in register if you'd have > <= 4 args. :) You mentioned OOP, didn't you? Encapsulation is a good thing and what you are talking about is "layering violations made Real Easy(tm)". I simply don't see why _that_ is a good goal. - 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: ANNOUNCE: Linux Kernel ORB: kORBit
> Also, 9P is a general communications framework only in the context of > Plan9 itself. In reality it only applys directly/well to filesystem > related issues... the reason it works well in Plan9 is that _everything_ > is a file (part of the beauty of plan9). So... in a 9P-enabled system, you write a regular server program that uses read(), write(), etc. to use the local (or another, remote) 9P system and exports some interface over the network protocol and encapsulation format of your choice. In your case, CORBA over IIOP or something. :) -M - 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: IP ID == 0 ?!
Hello, On Thu, 14 Dec 2000, Ivan Vadovic wrote: > Hi, [snip] > help here. Did I forget to configure something? Did you configure IP: TCP Explicit Congestion Notification support? If so, this breaks some older firewalls, which probably won't be updated any time soon. Regards, Adrian - 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: ANNOUNCE: Linux Kernel ORB: kORBit
On Wed, 13 Dec 2000, Chris Lattner wrote: > > > Err... how about this: Give me two or three kORBit syscalls and I can get > > > rid of all the other 100+ syscalls! :) > > > Like it ioctl() does it? Number of entry points is _not_ an issue. Diversity > > of the API is. Technically, kernel has 1 (_o_n_e_) entry point as far as > > userland is concerned. int 0x80 on x86. Can't beat that, can you? > > Err shame on you, don't forget about lcall and exceptions, and interrupts, > and... That is technically more than _o_n_e_ "entry point". :) Oh wait, > what about sysenter/exit too? :) OK, you got me on lcall (however, that's iBCS-only, IIRC), but the rest... what the hell does userland to interrupts? OK, make it 2 - pagefault can be arguably used in that way. > No I can't beat that. But if you look at the hack job of a system call > table we have, you can see that there is no _really_ standard way of > passing parameters. Oh sure, most of the time, stuff is passed in > registers. Sometimes we get a pointer to an argument struct. Because of > this wonderful design we get all kinds of stuff like sys_oldumount vs > sys_umount and others... Check how often anything uses the majority of that stuff... > > Yes, standard RPC mechanism would be nice. No, CORBA is not a good candidate - > > too baroque and actually known to lead to extremely tasteless APIs being > > implemented over it. Yes, I mean GNOME. So sue me. > > Hrm... because I'm stupid, please explain how CORBA is too baroque... I Check 9P and compare. Really. Section 5 of Plan 9 manpages. Available on plan-9.bell-labs.com/sys/man/ > have no problem with you not liking GNOME... you're a kernel hacker, so > you're not supposed to like GUI's. :) [just kidding!!!] CORBA doesn't > preclude nasty APIs any more than C does. It also doesn't preclude *nice* > APIs that are upgradable and extensible in the future (and that means > without breaking backwards compatibility). Please don't tell me that OOP > is bad... or else we will have the eviscerate the VFS layer from the > kernel (amount other subsystems)... :) OOP is a nice tool. However, it's a tool that has incredible potential of shooting one's foot. It's wonderful if you have sane set of methods. And that's a _big_ if. "Easily extensible" is not an absolutely good thing - C++ wankers all over the world are busily proving it every day. Heck, they make a living out of that. IOW, the problem with interface changes is _not_ in converting the old code. It's in choosing the right changes. And that part of the game can't be simplified. > > I would take 9P over that any day, thank you very much. > > Like I mentioned in a previous email, CORBA does not preclude 9P. What > it does buy you though, is compatibility with LOTS of preexisting CORBA > tools. How much development infrastructure is there for 9P? I thought > so. :) All UNIX userland on the client side. lib9p on the server side (23Kb of sparse C). Examples of use in servers - see the aforementioned site. > For one of our demos, we ran a file server on a remote linux box (that we > just had a user account on), mounted it on a kORBit'ized box, and ran > programs on SPARC Solaris that accessed the kORBit'ized linux box's file > syscalls. If nothing else, it's pretty nifty what you can do in little > code... Duh. And what's new about that? - 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: IP ID == 0 ?!
Date:Thu, 14 Dec 2000 04:11:09 +0100 From: Ivan Vadovic <[EMAIL PROTECTED]> I've been having weird problems with 2.4 kernels ip networking. I can't connect to several sites ( hotmail.com,intel.com... ). After some investigation with tcpdump I figured that the IDentification field of every outgoing ip packet is set to zero and then it doesn't get through some few firewalls. I'm surprised I haven't found anything about it in the list archives, so I'm trying to get help here. Did I forget to configure something? No, the sites have firewalls erroneously blocking ECN, try: echo "0" >/proc/sys/net/ipv4/tcp_ecn Later, David S. Miller [EMAIL PROTECTED] - 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: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit
/me trims down CC list... > Local? Funny. It lives atop of TCP or IL quite fine. What's > even funnier, I can use it to export /proc from CPU server to workstation > and use _that_ for remote debugging. Ditto for window system. Ditto for > DNS. Ditto for plumber. No, not on Linux... No not on linux. No definately not on Windows, no not on the BSD's either. Oops, wasn't interoperability an important part of the Linux kernel design? Didn't we want to use and follow and define _real_ standards? > What you do is mapping your RPC to hierarchical namespace. After > that... What extensibility do you need? You can use every utility written > for core UNIX API (open()/read()/write()/close()) as a client. No need > to reinvent the wheel... Heh, that's interesting. _getting_ the data isn't hard in 9P, actually using it or displaying it in a meaningful way commonly requires something more than cat. :) The overriding problem with a simplistic 9P port is that linux kernel functionality is not very well modularized. In fact, this prevents wonderful CORBA integration as well: An agressive filesystem (for example) often likes to touch the buffer cache or even the VM layer (*cough*) directly. Some don't use the prescribed interfaces, because nothing enforces it. 9P works wonderfully for Plan9 because they had the luxery of redefining/rewriting the whole OS, and the whole interaction with user space processes. We, unfortunately, don't have that possibility. :) Please don't get me wrong. I'm not opposed to other ideas, and 9P may in fact turn out to be a very nice protocol that would be able to support much kORBit level functionality). I do maintain that by writing a custom user->kernel marshalling library, you could obtain better peformance than 9P though, because you could take advantage of lots of machine specific optimizations. Hell you could even pass things in register if you'd have <= 4 args. :) -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/MagicStats/ http://korbit.sourceforge.net/ - 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/
IP ID == 0 ?!
Hi, I've been having weird problems with 2.4 kernels ip networking. I can't connect to several sites ( hotmail.com,intel.com... ). After some investigation with tcpdump I figured that the IDentification field of every outgoing ip packet is set to zero and then it doesn't get through some few firewalls. I'm surprised I haven't found anything about it in the list archives, so I'm trying to get help here. Did I forget to configure something? Ivan Vadovic - 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: ANNOUNCE: Linux Kernel ORB: kORBit
> > I do have one sensible question. Given that corba is while flexible a > > relatively expensive encoding system, wouldn't it be better to keep corba > > out of kernel space and talk something which is a simple and cleaner encoding > p9fs exists. I didn't see these patches since August, but probably I can poke > Roman into porting it to the current tree. 9P is quite simple and unlike > CORBA it had been designed for taking kernel stuff to userland. Besides, > authors definitely understand UNIX... One thing that you might want to mention Alexander: 9P is not a general communications protocol. In fact, it doesn't work very well across the internet at all. To get decent performance, the Plan9 group (which, is a very cool group. :) has to specify a new protocol that competes with TCP on the level of complexity (IL: http://plan9.bell-labs.com/sys/doc/il/il.html) Also, 9P is a general communications framework only in the context of Plan9 itself. In reality it only applys directly/well to filesystem related issues... the reason it works well in Plan9 is that _everything_ is a file (part of the beauty of plan9). With some elbow grease, 9P could probably be made to work in the kORBit framework. It's not even that big of a deal: it just takes time. Believe me when I say that IIOP is not a very good user->kernel communications mechanism. :) -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/MagicStats/ http://korbit.sourceforge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12 randomly hangs up
On Wed, 13 Dec 2000, Lukasz Trabinski wrote: > In article <[EMAIL PROTECTED]> you wrote: > > > I can (re)confirm that. I work several hours on console without any > > problem ... then I start X session and after several minutes system > > hangs. > > I can confirm that, too. > Todaye, crashed two difference machines > One: AMD-K6 3D, 300 MHz, RH 7.0 + updates, 64MB RAM > Second one: AMD Athlon 600, 600MHz with, 128MB RAM, RH 7.0+updates > > > Red Hat 7.0, XFree-3.3.6 (SVGA server), S3Virge/G2 (4MB) I've been running 2.4.0-test12 patched with only the O_SYNC bug fix and I have _not_ experienced any lockups on this machine. Classic Athlon 825(750) MHz, 128MB Ram, RH 7.0 based w/glibc 2.2, XFree-3.3.6 (S3 Trio 64 accel server), gcc 2.95.2 Not sure what the problem is yet... keep trying folks. :) -Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - 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: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit
On Wed, 13 Dec 2000, Chris Lattner wrote: > CORBA, today, gives us superior interoperability (through IIOP), with > extensibility for the future. As Alexander Viro mentions, 9P may be a > better protocol for local communications... Local? Funny. It lives atop of TCP or IL quite fine. What's even funnier, I can use it to export /proc from CPU server to workstation and use _that_ for remote debugging. Ditto for window system. Ditto for DNS. Ditto for plumber. No, not on Linux... What you do is mapping your RPC to hierarchical namespace. After that... What extensibility do you need? You can use every utility written for core UNIX API (open()/read()/write()/close()) as a client. No need to reinvent the wheel... - 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: test12 lockups -- need feedback
Ok, got locked up. Dropped me into kdb and I was able to write down the oops after doing a ss on btp 0. I'll try to have something posted in an hour. On Wed, 13 Dec 2000, Mohammad A. Haque wrote: > At first I thought it was just me when I reported the lockups I was > having with test12 earlier this week. Now the reports are flooding. Of > course, now my machine isn't locking up anymore after recompiling from a > clean source tree (test5 w/ patches through test12) > > Now, I'm trying to determine what the common element is. > > Those of you who are having lockups, was test12 compiled from a patched > tree that you've previously compiled? > > Those that are locking up in X. Do you have a second machine you can > hook up via serial port to grab Oops output? > > I've got KDB compiled in my current kernel. I'll compile a fresh kernel > without KDB and see how long I last when I get a chance. > -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - 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: ANNOUNCE: Linux Kernel ORB: kORBit
Alexander Viro wrote: > p9fs exists. I didn't see these patches since August, but probably I can poke > Roman into porting it to the current tree. 9P is quite simple and unlike > CORBA it had been designed for taking kernel stuff to userland. Besides, > authors definitely understand UNIX... I would side with Viro here. Just as we would all cringe if MSFT added COM/ActiveX support to the NT kernel, us Unix folks cringe at the thought of adding CORBA to the kernel. However, that doesn't mean that we dislike the idea of exporting kernel services and interfaces for use in userland. And Plan9 seems to have some rather elegant and efficient methods for doing that. In Plan9, everything really is a file! It's as if they got a chance to do Unix again, and they did it consistently this time. - 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: ANNOUNCE: Linux Kernel ORB: kORBit
> > Err... how about this: Give me two or three kORBit syscalls and I can get > > rid of all the other 100+ syscalls! :) > Like it ioctl() does it? Number of entry points is _not_ an issue. Diversity > of the API is. Technically, kernel has 1 (_o_n_e_) entry point as far as > userland is concerned. int 0x80 on x86. Can't beat that, can you? Err shame on you, don't forget about lcall and exceptions, and interrupts, and... That is technically more than _o_n_e_ "entry point". :) Oh wait, what about sysenter/exit too? :) No I can't beat that. But if you look at the hack job of a system call table we have, you can see that there is no _really_ standard way of passing parameters. Oh sure, most of the time, stuff is passed in registers. Sometimes we get a pointer to an argument struct. Because of this wonderful design we get all kinds of stuff like sys_oldumount vs sys_umount and others... > Yes, standard RPC mechanism would be nice. No, CORBA is not a good candidate - > too baroque and actually known to lead to extremely tasteless APIs being > implemented over it. Yes, I mean GNOME. So sue me. Hrm... because I'm stupid, please explain how CORBA is too baroque... I have no problem with you not liking GNOME... you're a kernel hacker, so you're not supposed to like GUI's. :) [just kidding!!!] CORBA doesn't preclude nasty APIs any more than C does. It also doesn't preclude *nice* APIs that are upgradable and extensible in the future (and that means without breaking backwards compatibility). Please don't tell me that OOP is bad... or else we will have the eviscerate the VFS layer from the kernel (amount other subsystems)... :) > I would take 9P over that any day, thank you very much. Like I mentioned in a previous email, CORBA does not preclude 9P. What it does buy you though, is compatibility with LOTS of preexisting CORBA tools. How much development infrastructure is there for 9P? I thought so. :) For one of our demos, we ran a file server on a remote linux box (that we just had a user account on), mounted it on a kORBit'ized box, and ran programs on SPARC Solaris that accessed the kORBit'ized linux box's file syscalls. If nothing else, it's pretty nifty what you can do in little code... -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/MagicStats/ http://korbit.sourceforge.net/ - 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: [Korbit-cvs] Re: ANNOUNCE: Linux Kernel ORB: kORBit
> > Don't worry about kORBit. Like most open source projects, it will simply > > die out after a while, because people don't find it interesting and there > > is really no place for it. If it becomes useful, mature, and refined, > > however, it could be a very powerful tool for a large class of problems > > (like moving code OUT of the kernel). > > I do have one sensible question. Given that corba is while flexible a > relatively expensive encoding system, wouldn't it be better to keep corba > out of kernel space and talk something which is a simple and cleaner encoding Very good point. I think this distills down to common misconception of CORBA: that it must be slow. Actually, a LOT of research has been done to improve CORBA performance, but you have to keep in mind one very IMPORTANT THING: CORBA does NOT dictate a transport or data format for the data going out "over the wire". CORBA does specify one "standard" used for interoperability: GIOP. It also specifies one important incarnation of GIOP: IIOP (GIOP over IP). kORBit currently uses this to communicate from user space to kernel space... obviously this is not ideal. :) There is absolutely NOTHING that prevents us from defining our own "data marshalling" protocol/algorithm that is lighter weight than IIOP. In fact, we had planned to implement that for our project, but of course, ran out of time. It would be relatively straight forward to define this extension in the ORBit code base, and in fact "ORBit 2" is striving to make this much much easier than it is now (basically sorting out IIOP specific code from the main code base better, and generally cleaning things up). Currently, ORBit supports IIOP and its own proprietary (as far as I know) Unix domain socket protocol (obviously only works intramachine). There is a large perception of CORBA being slow, but for the most part it is unjustified. I believe that the act of _designing_ a completely new protocol, standardizing it, and making it actually work would be a huge process that would basically reinvent CORBA (obviously some of the design decisions could be made differently, but all the same issues would have be dealt with). CORBA, today, gives us superior interoperability (through IIOP), with extensibility for the future. As Alexander Viro mentions, 9P may be a better protocol for local communications... so CORBA gives us a framework to try that out with. Even IIOP is smart enough to, for example, only do endian swapping of data if the two machines actually differ... so at least it doesn't specify a "network" byte order. CORBA isn't ideal for all applications, it certainly isn't the ideal IPC or RPC mechanism (the L4 designers would have a laughing fit if you tried to use it for _general_ IPC), but it is very useful for a lot of things. kORBit is very pre-alpha code, it works, but has lots of room for enhancements, experiementation, and toying around with. That's what makes it cool. :) -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/MagicStats/ http://korbit.sourceforge.net/ - 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/
VM problems still in 2.2.18
Hi, I upgraded from 2.2.14 to 2.2.16 after the security bug was discovered. Ever since, I have two boxes here that keep falling over. Box A will randomly lock without warning and box B will die and start printing this message repeatedly on the screen until I physically hit reset: VM: do_try_to_free_pages failed for cron... ...or something similar (could be apache etc.) I tried upgrading to 2.2.17 for a week and the problem didn't go away, installed 2.2.18 last night and the problem is still there. Don't know what to do since anything > 2.2.14 is very unstable on these machines, and anything < 2.2.14 has the security bug. Both machines have lots of these in the logs, just as others have reported it happens in spurts: Dec 13 08:00:12 symonds kernel: VM: do_try_to_free_pages failed for kupdate... Dec 13 08:00:12 symonds kernel: VM: do_try_to_free_pages failed for eggdrop... Dec 13 08:00:12 symonds kernel: VM: do_try_to_free_pages failed for mysqld... Dec 13 08:00:12 symonds kernel: VM: do_try_to_free_pages failed for apache... Dec 13 08:00:12 symonds kernel: VM: do_try_to_free_pages failed for eggdrop... Dec 13 08:00:12 symonds kernel: VM: do_try_to_free_pages failed for klogd... Dec 13 08:00:12 symonds kernel: VM: do_try_to_free_pages failed for eggdrop... Dec 13 08:00:12 symonds kernel: VM: do_try_to_free_pages failed for init... Dec 13 08:00:12 symonds kernel: VM: do_try_to_free_pages failed for traceroute... ...etc. Sometimes this will happen 10 minutes after a reboot, or 45 mins, but neither machine will stay up for more than 30 hours or so (usually *much* less). Something else I noticed is that the Load average is usually around 0.08, but when I let it idle for a few mins, just tapping the spacebar in a terminal will cause it to stop responding for 10 or so seconds with the load average skyrocketing to over 6. After that the system sometimes recovers and starts responding normally, other times it will die. Is there a patch out there that I can apply to 2.2.14 against the security bug? The machines were very stable on that kernel. Anything I can do from userland to help, let me know. -- Mark grep me no patterns and I'll tell you no lines. - 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.18-25 DELL Laptop Video Problems
On Wed, Dec 13, 2000 at 01:34:46AM +0100, Dominik Kubla wrote: > On Mon, Dec 11, 2000 at 11:11:41AM -0700, Jeff V. Merkey wrote: > ... > > Then this is the vga=271 stuff? > > > > Jeff > > No, that's just selecting the VGA resolution. I am referring to the > video parameter: > > video=:[,,...] > > Look at linux/Dokumentation/fb/modedb.txt. > It's not in my tree (2.2.18), the only documentation I could find was the source code. Anyway, it seems that atyfb gets a precendence over vesafb and screws up the LCD. Right now I use the following kernel params: video=atyfb:off video=vesa:mtrr vga=795 For reference this is Dell Inspiron 5000, lspci -vv says this: 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage P/M Mobility AGP 2x (rev 64) (prog-if 00 [VGA]) Subsystem: Dell Computer Corporation: Unknown device 009f Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [5c] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Regards, Petr -- Snow Day -- stay home. - 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: Pthreads, linux, gdb, oh my! (and ptrace must die!)
Mike Coleman wrote: >My limited mental abilities notwithstanding, I think this is one more reason >to ditch ptrace for a better method of process tracing/control. It's served >up to this point, but ptrace has a fundamental flaw, which is that it tries to >do a lot of interprocess signalling and interlocking in an in-band way, doing >process reparenting to try to take advantage of existing code. In the end >this seems to be resulting in an inscrutable, flaky mess. Yes! Overloading signals and the process parent tree is a kludgy hack with many unanticipated, painful effects (like this bug mentioned here, or the way ptrace breaks the semantics of wait(), etc.). >What would a better process tracing facility be like? Like the Solaris /proc tracing facility. Take a look at it -- I think it would make an excellent starting point. It is truly well done, at least in every way that has ever affected my use of tracing (my experience is in the area of sandboxing for security). /proc is transparent. It doesn't overload some existing mechanism, so it doesn't have all the pain of changing the semantics of various corner cases. /proc uses fd's as the mechanism for communicating events from the kernel to user-land, which gives a cleaner architecture. /proc allows to trap on both syscalls and syscall-exits, and to specify which events the user-land process is interested in (greatly lowers the cost of tracing, if you only care about some subset of the events). ptrace() doesn't let you specify (more than one bit of) per-process tracing state, which makes this very difficult to do. /proc is extensible: whenever it allows one tracer, it allows many tracers. /proc allows any-to-any tracing. ptrace() only allows a traced app to have at most one tracer at any time. This limitation of ptrace() makes it hard to securely (atomically) hand off tracing of an app from one tracer to another. /proc fixes this. /proc handles fork() more cleanly. In /proc, the tracer receives a tracing event when the fork returns in the newly created child process, as well as when it returns in the parent; in ptrace(), you only see an event when the fork() returns in the parent, which makes it harder to follow the process tree while tracing apps that call fork(). Go read strace code to see how it works around this problem, and you'll see what a disgusting hack strace is forced to use (blech!). Much of the ptrace() code in the kernel isn't architecture-independent. I find this amazing. IMHO, it would be much cleaner to have all syscalls immediately call some arch-independent function with the appropriate arguments, and interpose on the set of arch-independent functions. I'm not saying you should duplicate the Solaris /proc facility, but it would be very useful to learn from what Solaris got right and ptrace() got wrong. An even better process tracing facility might allow interposition on other interfaces in the kernel: Rather than just receiving events on syscalls and signals, how about on the VFS filesystem interface or the network layer interface? Just a thought. - 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: ANNOUNCE: Linux Kernel ORB: kORBit
On Wed, 13 Dec 2000, Chris Lattner wrote: > Err... how about this: Give me two or three kORBit syscalls and I can get > rid of all the other 100+ syscalls! :) Like it ioctl() does it? Number of entry points is _not_ an issue. Diversity of the API is. Technically, kernel has 1 (_o_n_e_) entry point as far as userland is concerned. int 0x80 on x86. Can't beat that, can you? Yes, standard RPC mechanism would be nice. No, CORBA is not a good candidate - too baroque and actually known to lead to extremely tasteless APIs being implemented over it. Yes, I mean GNOME. So sue me. I would take 9P over that any day, thank you very much. - 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: test12: eth0 trasmit timed out after one hour uptime
Hi i may have also had some problems with this when i was connected to the net though ppp (most of the night) so far in about 6 hours it has stoped transmitting 2 times but still recives it is fine after i disconnect and reconnect i will try and get it to stop working with heavry disk io BTW this is all under 2.2.18 and never had any problem with the isp over the past month or so. In local.linux-kernel-list, you wrote: >At first I thought my lockups were HD i/o related also but then the last >lockup I had happened a while after I trashed my disk but while grabbing >email (ppp link). > >Joseph Cheek wrote: >> >> 00:0e.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] >> (rev 30) >> >> i've been doing a ton of compiling which has thrashed the [IDE] HD, >> perhaps it is related. other than that, just normal web surfing... > >-- > > -- - Check Out: http://stev.org E-Mail: [EMAIL PROTECTED] 1:50am up 1 day, 11:05, 7 users, load average: 0.11, 0.09, 0.03 - 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: ANNOUNCE: Linux Kernel ORB: kORBit
On Thu, 14 Dec 2000, Alan Cox wrote: > > Don't worry about kORBit. Like most open source projects, it will simply > > die out after a while, because people don't find it interesting and there > > is really no place for it. If it becomes useful, mature, and refined, > > however, it could be a very powerful tool for a large class of problems > > (like moving code OUT of the kernel). > > I do have one sensible question. Given that corba is while flexible a > relatively expensive encoding system, wouldn't it be better to keep corba > out of kernel space and talk something which is a simple and cleaner encoding p9fs exists. I didn't see these patches since August, but probably I can poke Roman into porting it to the current tree. 9P is quite simple and unlike CORBA it had been designed for taking kernel stuff to userland. Besides, authors definitely understand UNIX... - 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] bsd-style cursor
On Wed, 13 Dec 2000, James Simmons wrote: > > included a patch against 2.4.0-test9 (should apply against latest but > > haven't checked) which adds the config option to have a bsd-style cursor > > in VT's by default. I was hoping it might be considered for inclusion so > > that I don't have to patch it in myself every time :-) > > How about placing > >echo '\033[?17;120c' > > In one of your startup scripts. This will give you this nice BSD > cursor you like. [buytenh@mara buytenh]$ tail -1 ~/.bash_profile echo -e -n '\033[?17;127c' [buytenh@mara buytenh]$ This has Issues though: try entering vi for example. I'd just like a way of altering CUR_DEFAULT (which is hardcoded here and there); sysctl would be fine too for that matter. cheers, Lennert - 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] bsd-style cursor
> included a patch against 2.4.0-test9 (should apply against latest but > haven't checked) which adds the config option to have a bsd-style cursor > in VT's by default. I was hoping it might be considered for inclusion so > that I don't have to patch it in myself every time :-) How about placing echo '\033[?17;120c' In one of your startup scripts. This will give you this nice BSD cursor you like. - 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: test12: eth0 trasmit timed out after one hour uptime
well, it seems to be working fine now, so i guess it was a fluke. Michael Peddemors wrote: > On Wed, 13 Dec 2000, Joseph Cheek wrote: > > 00:0e.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] > > (rev 30) > > Hmm, maybe I thru it out too fast.. 3Com905B -TXNM XL PCI SN=6xb1b85caf thanks! joe -- Joseph Cheek, Sr Linux Consultant, Linuxcare | http://www.linuxcare.com/ Linuxcare. Support for the Revolution. | [EMAIL PROTECTED] CTO / Acting PM, Redmond Linux Project | [EMAIL PROTECTED] 425 990-1072 vox [1074 fax] 206 679-6838 pcs | [EMAIL PROTECTED] - 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: Adaptec AIC7XXX v 6.0.6 BETA Released
On Wed, 13 Dec 2000, Justin T. Gibbs wrote: > Subject: Adaptec AIC7XXX v6.0.6 BETA Released > --- > After several months of testing and refinement, the Adaptec > sponsored aic7xxx driver is now entering Beta testing. Although > still missing domain validation and the last bits of cardbus > support, there are no known issues with the driver. I would > encourage all users of card supported by this driver to try the > new code and submit feedback. Patches for late 2.2.X, 2.3.99 > and 2.4.0 are provided in the driver distribution. For those > of you building the driver as a module, take note that the module > name is now "aic7xxx_mod" rather than "aic7xxx". > > As always, the most recent distribution is available here: > > http://people.FreeBSD.org/~gibbs/linux/ Justin, Thanks for posting this. Unfortunately, the kernel won't build unless you restore this macro to the namespace after aic7xxx_linux.h blows it away: --- linux-2.2.18/drivers/scsi/hosts.c.orig Wed Dec 13 20:27:34 2000 +++ linux-2.2.18/drivers/scsi/hosts.c Wed Dec 13 20:26:22 2000 @@ -137,6 +137,7 @@ #ifdef CONFIG_SCSI_AIC7XXX #include "aic7xxx/aic7xxx_linux.h" +#define current get_current() #endif #ifdef CONFIG_SCSI_IPS Steve - 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: test12: eth0 trasmit timed out after one hour uptime
On Wed, 13 Dec 2000, Joseph Cheek wrote: > 00:0e.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] > (rev 30) Hmm, maybe I thru it out too fast.. 3Com905B -TXNM XL PCI SN=6xb1b85caf -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - 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: test12: eth0 trasmit timed out after one hour uptime
I wasted time trying to track something similar down, replaced the card instead :> My first clue was when smacking the box, it started working again... (j/k) You didna' mention the card type ... On Wed, 13 Dec 2000, Joseph Cheek wrote: > hi all, > > after about an hour of uptime [and heavy HD usage] my ethernet just > died. couldn't ping a thing. syslog showed: > > Dec 13 14:51:46 sanfrancisco kernel: NETDEV WATCHDOG: eth0: transmit > timed out > Dec 13 14:51:46 sanfrancisco kernel: eth0: transmit timed out, tx_status > 00 status e680. -- Michael Peddemors - Senior Consultant Unix Administration - WebSite Hosting Network Services - Programming Wizard Internet Services http://www.wizard.ca Linux Support Specialist - http://www.linuxmagic.com (604) 589-0037 Beautiful British Columbia, Canada - 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: test12 lockups -- need feedback
On Wednesday 13 December 2000 19:29, Mikael Djurfeldt wrote: | > I downloaded the full test12 and have lockups after using X | > (upstream version 4.0.1Z) 15-45 mins. For me, SysRq+u works, but | > if I then press SysRq+b, nothing happens. There are no signs in | > the syslog. | | I should add that I didn't have these lockups in test12-pre8. just for statistical purposes, test12 has been running problem-free here on a k6-2-550 (running at 500), glibc-2.2, built with gcc-2.95-2, since about an hour after it was announced. no anomalies at all, and the cd reader has become reliable again. in X the entire time, and heavy system activity with a wide variety of applications. -- dep -- bipartisanship: an illogical construct not unlike the idea that if half the people like red and half the people like blue, the country's favorite color is purple. - 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: ANNOUNCE: Linux Kernel ORB: kORBit
> Don't worry about kORBit. Like most open source projects, it will simply > die out after a while, because people don't find it interesting and there > is really no place for it. If it becomes useful, mature, and refined, > however, it could be a very powerful tool for a large class of problems > (like moving code OUT of the kernel). I do have one sensible question. Given that corba is while flexible a relatively expensive encoding system, wouldn't it be better to keep corba out of kernel space and talk something which is a simple and cleaner encoding Alan - 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: ANNOUNCE: Linux Kernel ORB: kORBit
> > > It was just an example. Basically, you'd be able to do in with just > > > about any language that has ORBit bindings. > Agree. I remember a big complaint about Windows was the huge APIs, > compared with Unix' tiny list of syscalls. And then I saw the GNOME > docs... ew! Err... how about this: Give me two or three kORBit syscalls and I can get rid of all the other 100+ syscalls! :) We're not trying to port GNOME to the kernel. We're not trying to bloat the kernel API, actually we're trying to do the opposite. Consider this: 1. kORBit adds about 150k of code to the 2.4t10 kernel. 2. kNFS adds about 100k of code to the 2.4t10 kernel. 3. kORBit can do everything kNFS does, plus a WHOLE lot more: For example implement an NFS like server that uses SSL to send files and requests... so it is really actually "secure". > > Yeah... "Infinitely extendable API" and all such. Roughly translated > > as "we can't live without API bloat". Frankly, judging by the GNOME Whoa, you are so right... a well defined API is a terrible thing! Instead, lets try doing the following: 1. Define our API to be a bizarre and poorly documented collection of inline functions, macros, and normal functions. 2. Lets make this API have all kinds of subtle side effects, and lets not document these! 3. Lets raise the level that people have to be at to even TOUCH our APIs. Only uber-hackers that have worked with the system for 1+ years should be able to comprehend what's going on in the big picture... 4. Nobody that is "allowed" to work on this thing is dumb enough to produce any bugs. Because of that, debuggers are outlawed and anyone who attempts to debug code is shunned from existance... 5. Lets duplicate code all over the place that does mostly the same thing, but has subtle differences. 6. Lets structure the file layout such that files are in poorly grouped catagories, often with ambiguous locations, and lets drop HUNDREDS of .c files into individual directories. After all that's much easier than actually sorting them out. oh wait, we have this, the Linux kernel. Yes yes, this was definately a pot shot at the kernel tree, and I'm not at all serious about this. The fact of the matter, however, is that there are a lot of cool things that a well defined interface for kernel programming can buy you. Yes, there is an overhead, but do you really care about how performant your parrellel port scanner driver is? I'm not advocating that people write their fibre channel drivers with kORBit. :) Actually, if you really want to get technical about this thing, I never said anyone should use this at all. :) I just mentioned that it is out there and if people feel like it they can use it or play with it. I happen to think it addresses a point that is currently poorly addressed in the Linux kernel: you can't do RPCs to the kernel in a well defined manner. Linux is facing a crisis that is growing every day, and that is that there is no well defined interface for drivers to use... so compatibilty across releases it almost impossible. Don't worry about kORBit. Like most open source projects, it will simply die out after a while, because people don't find it interesting and there is really no place for it. If it becomes useful, mature, and refined, however, it could be a very powerful tool for a large class of problems (like moving code OUT of the kernel). -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/MagicStats/ http://korbit.sourceforge.net/ - 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: insmod problem after modutils upgrading
> Well, if it is going to take that long to fix 2.2 ... modutils 2.3.23 It may do. 2.2.18 took a long time. > will make this a semi-warning. modules with invalid MODULE_PARM for > options that are not used will load, but the module will not support > persistent data. If somebody actually tries to use one of the invalid > options then insmod will fail, it already does this. That sounds fine. Warning is sensible, not supporting persistent data is obvious enough and 2.2 doesnt do that yet so it isnt a problem. Alan - 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: test12 lockups -- need feedback
Mikael Djurfeldt <[EMAIL PROTECTED]> writes: > "Mohammad A. Haque" <[EMAIL PROTECTED]> writes: > > > Those of you who are having lockups, was test12 compiled from a patched > > tree that you've previously compiled? > > I downloaded the full test12 and have lockups after using X (upstream > version 4.0.1Z) 15-45 mins. For me, SysRq+u works, but if I then > press SysRq+b, nothing happens. There are no signs in the syslog. I should add that I didn't have these lockups in test12-pre8. - 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/
[PATCH] Maestro 2 sound driver update.
The attached patch, against 2.4.0-test12, makes some changes to the Maestro 2 sound driver for Linux. The main changes are: * allow multiple opens of /dev/dsp * support persistent DMA buffer allocation * default number of channels at compile time * support kernel command line arguments The multiple open of /dev/dsp is the most interesting change. Now, multiple processes can open the device at the same time. Previously the driver would export one dsp device per channel. This is an incompatible change so, if you use the patch, be aware of that. This needs more testing before being ready to submit for inclusion in the kernel proper. If you do try it, could you please send me reports (by private mail) about your success or failure? Thanks, Daniel diff -u --recursive linux/Documentation/Configure.help linux.dp/Documentation/Configure.help --- linux/Documentation/Configure.help Tue Dec 12 15:17:13 2000 +++ linux.dp/Documentation/Configure.help Tue Dec 12 14:42:08 2000 @@ -14464,6 +14464,22 @@ of PCI sound chips. These include the Maestro 1, Maestro 2, and Maestro 2E. See Documentation/sound/Maestro for more details. +The number of DSP device to create. +CONFIG_MAESTRO_CHANNELS + The number of DSP devices to allocate. Each device functions as + a fully independent sound system. The more devices allocated, + however, the larger the memory requirement for the driver. + You can allocate up to four DSP devices, but only in multiples + of two. This allows one, two or four devices. + +Allocate memory for DSP devices persistently +CONFIG_MAESTRO_PERSIST + If you say Y to this, the memory for the DSP devices provided + by the Maestro device will be retained even when the sound + system is not in use. + This is beneficial if you find that sound cannot be used after + doing other things on the machine for a while. + Are you using a crosscompiler CONFIG_CROSSCOMPILE Say Y here if you are compiling the kernel on a different Only in linux.dp/Documentation: Configure.help~ diff -u --recursive linux/Documentation/sound/Maestro linux.dp/Documentation/sound/Maestro --- linux/Documentation/sound/Maestro Sat Jul 29 05:50:52 2000 +++ linux.dp/Documentation/sound/Maestro Tue Dec 12 14:42:08 2000 @@ -80,16 +80,32 @@ an IRQ. This operation is incredibly system specific, so you're on your own. Sometimes the magic lies in 'PNP Capable Operating System' settings. -There are very few options to the driver. One is 'debug' which will -tell the driver to print minimal debugging information as it runs. This -can be collected with 'dmesg' or through the klogd daemon. - -The other, more interesting option, is 'dsps_order'. Typically at -install time the driver will only register one available /dev/dsp device -for its use. The 'dsps_order' module parameter allows for more devices -to be allocated, as a power of two. Up to 4 devices can be registered -( dsps_order=2 ). These devices act as fully distinct units and use -separate channels in the maestro. +There are very few options to the driver. Options can be specified as either +module options or on the kernel command line. Command line arguments are in +the form 'maestro=:,:'. + +One is 'debug' which will tell the driver to print minimal debugging +information as it runs. This can be collected with 'dmesg' or through the +klogd daemon. Setting this to one will cause debug information to be dumped. + +The other, more interesting option, is 'channels'. At install time the driver +will register /dev/dsp and makes a number of channels available through this +device. Multiple programs can open /dev/dsp, until all channels are used. + +The 'channels' parameter specifies the number of channels to be specified. Up +to 4 channels can be allocated, but only in powers of two. Thus, you can have +one, two or four devices. The default value is to allocate one channel. + +When multiple channels are open, they act as distinct sound devices. This +allows multiple applications to generate sound simultaneously without blocking +each other. + +At compile time you may also select to use persistent dsp buffers. Because of +some oddities of the hardware, a large number of channels requires a large +slab of contiguous memory. The persistent buffers option allocates this memory +when the cards are detected and holds it all the time, preventing memory +fragmentation from preventing the sound device from working. + Power Management diff -u --recursive linux/drivers/sound/Config.in linux.dp/drivers/sound/Config.in --- linux/drivers/sound/Config.in Tue Dec 12 15:17:43 2000 +++ linux.dp/drivers/sound/Config.in Tue Dec 12 14:42:08 2000 @@ -21,6 +21,10 @@ dep_tristate ' Creative Ensoniq AudioPCI 97 (ES1371)' CONFIG_SOUND_ES1371 $CONFIG_SOUND dep_tristate ' ESS Technology Solo1' CONFIG_SOUND_ESSSOLO1 $CONFIG_SOUND dep_tristate ' ESS Maestro, Maestro2, Maestro2E driver' CONFIG_SOUND_MAESTRO $CONFIG_SOUND +if [ "$CONFIG_SOUND_MAESTRO" = "y" -o
Re: test12 lockups -- need feedback
"Mohammad A. Haque" <[EMAIL PROTECTED]> writes: > Those of you who are having lockups, was test12 compiled from a patched > tree that you've previously compiled? I downloaded the full test12 and have lockups after using X (upstream version 4.0.1Z) 15-45 mins. For me, SysRq+u works, but if I then press SysRq+b, nothing happens. There are no signs in the syslog. I'm using the latest Debian packages from the Woody release on an Mobile Pentium II, 333 MHz, 160 Mb ram. - 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/
[PATCH] ver_linux+kgcc
Hello.
In short: scripts/ver_linux can lie about the cc version used to build
kernel. With recent add for the detection of gcc727, kgcc anc cc, kernel
can be compiled with one cc and ver_linux report one other.
This can help people reporting hangs or bugs, because usually give the
output of ver_linux and it usually is wrong about gcc used for kernel.
BTW, I have added the GNU make version info present in 2.4 but not in 2.2.
NOTE: the cc misversioning also happens in 2.4
== patch-ver_linux
--- linux/scripts/ver_linux.org Thu Dec 14 00:52:16 2000
+++ linux/scripts/ver_linux Thu Dec 14 01:07:15 2000
@@ -9,7 +9,13 @@
echo '-- unusual then possibly you have very old versions)'
uname -a
insmod -V 2>&1 | awk 'NR==1 {print "Kernel modules",$NF}'
-echo "Gnu C " `gcc --version`
+echo "Gnu C " \
+ `gcc272 --version 2>/dev/null || \
+kgcc --version 2>/dev/null || \
+gcc --version 2>/dev/null || \
+cc --version`
+make --version 2>&1 | awk -F, '{print $1}' | awk \
+ '/GNU Make/{print "Gnu Make ",$NF}'
ld -v 2>&1 | awk -F\) '{print $1}' | awk \
'/BFD/{print "Binutils ",$NF}'
ls -l `ldd /bin/sh | awk '/libc/{print $3}'` | sed -e 's/\.so$//' \
== patch-ver_linux
--
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[EMAIL PROTECTED] #> more beer
Linux werewolf 2.2.18-aa1 #1 SMP Mon Dec 11 21:26:28 CET 2000 i686
-
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: insmod problem after modutils upgrading
On Wed, 13 Dec 2000 22:13:29 + (GMT), Alan Cox <[EMAIL PROTECTED]> wrote: >> previously because nobody used those options. Since these are bugs in >> the modules and only a few modules are affected (less than 5 reported), >> the fix is to correct the modules that have coding errors. > >That wont be happening in 2.2 until 2.2.19 which probably means 6 months. >If this is your decision please make it abundantly clear that the new >modutils are a 2.4 only package. Well, if it is going to take that long to fix 2.2 ... modutils 2.3.23 will make this a semi-warning. modules with invalid MODULE_PARM for options that are not used will load, but the module will not support persistent data. If somebody actually tries to use one of the invalid options then insmod will fail, it already does this. - 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: test1[12] + sparc + bind 9.1.0b1 == bad things
On Wed, 13 Dec 2000, Pete Zaitcev wrote:
> > Is this the first OOPS it prints out? I don't think so. I am
> > very sure it printed out messages from die_if_kernel first and
> > we need that initial OOPS to diagnose this bug and fix it.
> >
> > All the rest of the OOPS messages are useless and won't tell
> > us what the real problem is.
>
> > Later,
> > David S. Miller
no, you're right. here's the first oops:
named(465): Oops
TSTATE: f0f09603 TPC: 0043f730 TNPC: 0043f734 Y: 0c00
g0: 70029eb470029ea0 g1: 003d g2: 0002 g3:
g4: f800 g5: 0004 g6: f8001318c000 g7: 003d
o0: 0068dd00 o1: 0001 o2: o3: 0071
o4: o5: sp: f8001318ed91 ret_pc: 0042d5c0
l0: l1: 70188270 l2: f8001398b8f0 l3: 005b4400
l4: 0068fc00 l5: 005b45c0 l6: 000f l7:
i0: i1: f80010528908 i2: 0001 i3: 0001
i4: i5: 0003 i6: f8001318ee51 i7: 004b2878
Caller[004b2878]
Caller[004b2b3c]
Caller[004e205c]
Caller[004ef3d8]
Caller[004e3e5c]
Caller[0041b154]
Caller[00408874]
Caller[0042d5c0]
Caller[0042da28]
Caller[004100b4]
Caller[7005ccd4]
Instruction DUMP: a4063ff0 d85ca008 f05e 900f4008 80a22000 0247fff8
80a60019 02f6ffcc
Aiee, killing interrupt handler
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 05c9
tsk->{mm,active_mm}->pgd = f80013789000
..and here's its ksymoops output:
ksymoops 2.3.5 on sparc64 2.4.0-test12-1. Options used
-V (default)
-K (specified)
-L (specified)
-O (specified)
-m /usr/src/linux/System.map (default)
named(465): Oops
TSTATE: f0f09603 TPC: 0043f730 TNPC: 0043f734 Y:0c00
Using defaults from ksymoops -t elf32-sparc -a sparc
g0: 70029eb470029ea0 g1: 003d g2: 0002 g3:
g4: f800 g5: 0004 g6: f8001318c000 g7: 003d
o0: 0068dd00 o1: 0001 o2: o3: 0071
o4: o5: sp: f8001318ed91 ret_pc: 0042d5c0
l0: l1: 70188270 l2: f8001398b8f0 l3: 005b4400
l4: 0068fc00 l5: 005b45c0 l6: 000f l7:
i0: i1: f80010528908 i2: 0001 i3: 0001
i4: i5: 0003 i6: f8001318ee51 i7: 004b2878
Caller[004b2878]
Caller[004b2b3c]
Caller[004e205c]
Caller[004ef3d8]
Caller[004e3e5c]
Caller[0041b154]
Caller[00408874]
Caller[0042d5c0]
Caller[0042da28]
Caller[004100b4]
Caller[7005ccd4]
Instruction DUMP: a4063ff0 d85ca008 f05e 900f4008 80a22000 0247fff8
80a60019 02f6ffcc
>>PC; 0043f730 <__wake_up+110/220> <=
>>O7; 0042d5c0
>>I7; 004b2878
Trace; 004b2878
Trace; 004b2b3c
Trace; 004e205c
Trace; 004ef3d8
Trace; 004e3e5c
Trace; 0041b154
Trace; 00408874
Trace; 0042d5c0
Trace; 0042da28
Trace; 004100b4
Trace; 7005ccd4
Code; 0043f724 <__wake_up+104/220>
<_PC>:
Code; 0043f724 <__wake_up+104/220>
0: a4 06 3f f0 add %i0, -16, %l2
Code; 0043f728 <__wake_up+108/220>
4: d8 5c a0 08 unknown
Code; 0043f72c <__wake_up+10c/220>
8: f0 5e 00 00 unknown
Code; 0043f730 <__wake_up+110/220> <=
c: d0 5b 00 00 unknown <=
Code; 0043f734 <__wake_up+114/220>
10: 90 0f 40 08 and %i5, %o0, %o0
Code; 0043f738 <__wake_up+118/220>
14: 80 a2 20 00 cmp %o0, 0
Code; 0043f73c <__wake_up+11c/220>
18: 02 47 ff f8 unknown
Code; 0043f740 <__wake_up+120/220>
1c: 80 a6 00 19 cmp %i0, %i1
Code; 0043f744 <__wake_up+124/220>
20: 02 f6 ff cc unknown
Aiee, killing interrupt handler
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 05c9
tsk->{mm,active_mm}->pgd = f80013789000
thanks,
pete
--
Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED]
GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736
PGP signature
Re: test12 + initrd = swapper at 99.8% CPU time
On Wed, 13 Dec 2000, Joseph Cheek wrote: > hi all, > > i'm using test12 to perform a clean linux install. as soon as i get to > a command prompt, ps axufw shows swapper at 99.8% CPU usage. this > didn't repro with test11, and doesn't repro if i don't use an initrd. > > my load avg stays above 1 even if nothing [a couple gettys and a shell] > is running. > > what can i do to debug this? any ideas? Boot with "profile=2" kernel option and read readprofile (1) man page to know how to use it. - 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 ipv6 questions. bugs?
ugh, bad form, i know, but i forgot this little dollop of information: it looks like the incorrectly mac addressed n.s. packets are being fed right back into the linux box's ip stack (as it sees an ethernet packet with the destination set to its own mac address): [root@nsv6 /root]# ping6 X:Y::1 PING X:Y::1(X:Y::1) from X:Y::4 : 56 data bytes From ::1: Destination unreachable: Address unreachable From ::1: Destination unreachable: Address unreachable . . . From ::1: Destination unreachable: Address unreachable 64 bytes from X:Y::1: icmp_seq=16 hops=64 time=433 usec 64 bytes from X:Y::1: icmp_seq=15 hops=64 time=1.000 sec the pings start working when i put the X:Y::1 box's ethernet card into promsc mode and it sees an ipv6 packet destined for one of its multicast addresses. (i guess promsc mode tells the eth to just ignore all link-level addressing info.) pete On Wed, 13 Dec 2000, Pete Toscano wrote: > > On Wed, 13 Dec 2000, [EMAIL PROTECTED] wrote: > > > Hello! > > > > > 0. whenever i ping6 the loopback interface (::1/128), all echo requests > > > seem to be dropped and i get no echo replies. is this correct? > > > Your guess? 8) Of course, it is incorrect. I even have no idea > > how it is possible to put system into such sad state. > > well, just power it on, it seems. but then again, this is just a guess. > =;] > > > Though... probably, you forgot to up loopback. > > doesn't look it: > > [root@nsv6 /root]# ifconfig lo > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > inet6 addr: ::1/128 Scope:Host > UP LOOPBACK RUNNING MTU:7952 Metric:1 > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > [root@nsv6 /root]# ping6 ::1 > PING ::1(::1) from ::1 : 56 data bytes > > --- ::1 ping statistics --- > 156 packets transmitted, 0 packets received, 100% packet loss > > ...and this is right after boot. > > > > the destination mac address is set to the linux box's mac address and > > > the source mac address is set to 0:0:0:0:0:0. > > > > I think it is consequence of above. When loopback interface is missing, > > networking does not work. > > > > > > > other way around? this would explain why the openbsd box doesn't > > > respond to the linux box's n.s. until it starts looking at all the > > > packets in promisc mode, right? > > > > Rather it means that openbsd is buggy, its stack accepts packets > > not destined to it. It cannot react to those strange packets, which > > you have just described. > > that may very well be, but shouldn't the neighbor solisitation packets > from the linux box have the source mac address set to its mac address > and the destination mac address set to 0:0:0:0:0:0 and not the other way > around? > > thanks, > pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]
On Tuesday December 12, [EMAIL PROTECTED] wrote: > > > On Wed, 13 Dec 2000, Neil Brown wrote: > > > > Yes... you are right. Alright, I can't escape it any other way so I > > guess I must admit that it is a raid5 bug. > > > > But how can raid5 be calling b_end_io on a buffer_head that was never > > passed to generic_make_request? > > Answer, it snoops on the buffer cache to try to do complete stripe > > writes. > > Ahh, yes. It seems to just do a "get_hash_table()", and put that bh into > the queues. Bad. > > > The following patch disabled that code. > > If this fix makes the oops go away, then the proper fix for the problem is > not the #if 0, but do add something like > > bh->b_end_io = buffer_end_io_sync; > > to just before the "add_stripe_bh(sh, bh, i, WRITE);" > > We've already locked the thing, so that should be ok. Yes, that should work, except that end_buffer_io_sync is static in ll_rw_blk.c :-) However I don't think there is a lot of point in maintaining this piece of code. It was a useful optimisation in 2.2, but it is substantially less effective in 2.4. In 2.2 filesystems kept allcache data - file content, meta data, etc, in the physically addressed buffer cache. As it was physically addressed, raid5 could go looking for other data in the same stripe as the stripe that it was writing, and thereby improve performance. But in 2.4, filesystems (well, ext2 at least) keep only the metadata in the buffer cache, and if you are using something like LVM or RAID0 on top of the RAID5 array, there wont be anything in the buffer cache for the raid5 device. I think I can get similar performance improvements by "plugging" the raid5 device appropriately, but I haven't quite figured out all the issues in making that work completely. > > I wonder about that "md_test_and_set_bit(BH_Lock ...);" thing there, > though. If the buffer we find was dirty but already locked, we won't be > using that buffer at all (because the md_test_and_set_bit() will fail), > which probably means that the RAID5 checksum won't be right. Hmm.. > > Why is there an dirty aliased buffer head anyway? That sounds like a > recipe for disaster - maybe we should have synched all the stripe devices > before we set up the raid? Is that a raid5 rebuild issue? What's going on > here? I we find a dirty, locked buffer, then it means that some other thread has got through ll_rw_block with that buffer, but is blocked, or is about to be blocked, in raid5_make_request (calling get_lock_stripe probably). When the current write phase completes, that dirty block will come through and cause another write phase on this stripe. Each time the parity will be correct. This is completely separate from parity re-syncing. The resync code doesn't use buffers in the buffer cache at all. It just uses the buffers in the raid5 stripe cache. NeilBrown > > Linus - 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] 2.4.0-test12:
On Wed, Dec 13, 2000 at 11:11:55PM +0100, Andi Kleen wrote: > Perhaps it should mention that the guaranteed useful range of atomic_t > is only 24bit ? Documentation without source would rather useless if it > didn't mention such pitfalls. Does ftp://people.redhat.com/twaugh/patches/linux24/linux-macrodoc.patch> look better? Tim. */ - 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/
IDE bugs for intel 440LX chipset in Test12?
All I can say right now is that enabling DMA on a 440LX chipset with 2.4.0-test12 or any other kernel I can remember has caused DMA timeout and ide-reset problems. Disabling dma on the harddrives doesn't help that much either, I still get ide resets. What I'm looking for right now is some information on how to log what the kernel recieves from the harddrive and possibly what it sends so I can give rik some better information on what's going on in this chipset. Thanks. - 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: cramfs filesystem patch
Daniel, > Have you done a comparison of LZO against zlib (decompression > speed/size vs. compression ratio)? It uses less RAM/CPU to decompress > at the cost of wasting storage space, but it's hard to make a decision > without real numbers. I can't do a test on speed because I haven't had time to get it to work in the kernel. But it does take no memory during decompression. The resulting size of the romdisk is increased by 5% over zlib's lightest compression. So it does create a larger cramfs partition, but the lower (read none) memory overhead is a big plus, and decompression speed is a big plus. > Actually, my most major concern is that LZO may not be legally > unencumbered. There's no mention of any patent search in the LZO > site. zlib has been very well researched in this regard. Yes..., this is my major concern as well. It's why I sort of opted not to pour tons more time on it when I was working on it. (I was having a byte alignment problem) > Do you want to implement more than one type of compression per cramfs > filesystem or are the compression flags in the inode only needed to > distinguish between uncompressed (XIP) and compressed data? I assume > you wouldn't use both LZO and zlib code, except perhaps for backward > compatibility with your own products. > > If you're using XIP and uncompressed binaries, you may want to think > about using romfs for them. Yes, that's where it's being implemented right now is in romfs. But I want to cross it over into cramfs to be able to support more than one type of file compression type..., one being zlib, the other being not compressed and aligned for XIP usage. > Also regarding leaving binaries/libraries uncompressed, they tend to > be about 50% of a small (uncompressed) filesystem in my experience. > Is the ratio much different in the Agenda? More like 72% :-). But we're not planning on having all the libraries and executables running XIP, just a few key ones..., X, Xlibs, etc. That's why integration with cramfs is sort of key, one other reason too being that we want their to be only one flash to put all our s/w on. If we pull them out as seperate pieces, then we've got three seperate flashes for our users to deal with when they do a full upgrade. (Kernel, cramfs, romfs) We'd like to avoid that if possible. > I want to be careful about increasing the size of the inode. > Increasing it a small amount may have some benefits, but I've been > trying really hard to avoid it. I have been considering a version 2 > inode that would change the allocation of bits in the inode (to allow > larger files at the expense of uid/gid space). > > I think it would be better to put the type of compression at the > beginning of each data block. zlib has flags for this sort of thing > and there's already a header on each zlib data block in cramfs. Hmm..., maybe. But that's a little hacky probably..., I don't know, it seems like that info should go into the inode to me. I suppose we could pull it out and put it in a header, or make our own version of cramfs that does less gids/uids and use some of those bits as flags for filetypes. But I'd rather not fork things up like that. > BTW, how many uids/gids do you need cramfs to support? My belief is > that 16 (or 256 at most) uids/gids is more than enough embedded system. In the cramfs partition..., we probably only need 4 really. The users can create their own accounts, etc., but they exist on another partition type (JFFS) which can support as many gids, uids, etc. as ext2fs. Thanks, Shane. - 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: Pthreads, linux, gdb, oh my! (and ptrace must die!)
Mark Kettenis <[EMAIL PROTECTED]> writes: > However, the "zombie problem" is caused by the way ptrace() interacts > with clone()/exit()/wait(), which I consider to be a kernel bug. [insightful analysis omitted] I think you've hit the nail on the head, and I'm a bit frustrated that I never noticed this problem even though I've spent quite a bit of time poring over the code that makes ptrace work. My limited mental abilities notwithstanding, I think this is one more reason to ditch ptrace for a better method of process tracing/control. It's served up to this point, but ptrace has a fundamental flaw, which is that it tries to do a lot of interprocess signalling and interlocking in an in-band way, doing process reparenting to try to take advantage of existing code. In the end this seems to be resulting in an inscrutable, flaky mess. What would a better process tracing facility be like? One key feature is utter transparency. That is, it should be impossible for traced processes or other processes that interact with them to be aware of whether or not tracing is going on. This means that there should be no difference between the way a process behaves under tracing versus how it would behave if it weren't being traced, which is a key to faithful tracing/debugging and avoiding the Heisenbug effect. (There does need to be some interface via which information about tracing itself can be observed, but it should be hidden from the target processes.) It would also be nice to have something accessible via devices in the proc filesystem. Maybe something like Solaris' "proc" debugging interface would be a starting point: http://docs.sun.com:80/ab2/coll.40.6/REFMAN4/@Ab2PageView/42351?DwebQuery=proc=C=iso-8859-1 --Mike -- [O]ne of the features of the Internet [...] is that small groups of people can greatly disturb large organizations. --Charles C. Mann - 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: parport1 gone in 2.2.18
On Wed, Dec 13, 2000 at 09:01:56PM +0100, Peter Bornemann wrote: > I have a second parport installed as a PCI-card. In earlier Linux-versions > this would lock the machine completely if parport & Co where compiled as > modules (2.2.16 and 2.2.17). Compiled into the kernel however, everything > worked fine. I wrote about that to LK, but no solution was found. Now in > 2.2.18 it is the other way round, modules work with the proper > initialization in modules.conf, but if compiled into the kernel, the > second parport vanishes completely. The problem was that there are many more Timedia cards than I realised, and they are only distinguishable from each other by their subdevice ID (vendor and device isn't enough). So we were probably using the wrong BARs, which probably caused the freezes you saw. The 2.4.x parport_pc card table can deal with this; the 2.2.x parport_pc card table can't. So rather than leave a potential freeze in I pulled those cards from the table altogether. Sorry if I didn't tell you this. For 2.2.19 I'm hoping to backport the 2.4.x parport_pc card table structure if Alan doesn't think that's too big a change. The reason it works for you with modules is probably because you have an options line in /etc/modules.conf that tells parport_pc which addresses your PCI card is using at the moment. Tim. */ PGP signature
[PATCH] VIA82C694X based SMP board...
Hi,
after couple of hours of hacking I finally got my VIA82C694X based
SMP board (Gigabyte GA-6VXD7) to work. I had to add 'udelay(300);'
after sending startup ipi, before we print something to screen.
Without this udelay it died at the beginning of second printk
(that is, Startup point 1. was printed, there was one empty line at
the end of screen, but Waiting for send to finish was not visible.
And cursor was sometime at the beginning of last line, sometime
at the end of last line, and sometime invisible :-( ) in couple
of spectacular ways - almost always hard lock, but four times it
except hardlocking also powered down both CPU fans and did not react
even to hard reset (well, it reacted, but BIOS was not able to
initialize machine).
I have no idea whether memory r-m-w cycle killed it, or whether
PCI outb cycle (vgacon cursor move) killed it, or what-where-why...
But it must be something in our secondary CPU kernel initialization,
as if I add some loop into trampoline.S, I must increase delay.
If somebody has access to VIA specs (I asked them, but no answer
yet) and can confirm this in their errata, or if someone sees something
like that in Intel PIII errata (Pentium III Coppermine, BIOS says
CPU ID: 0683, Patch ID: 0010)...
Anyway, without either of two patches below my machine does not
boot. Is there any reason why we cannot add 'udelay(300);' after
sending startup IPI, as first patch does? Both patches are for
2.4.0-test12. I did not tried 2.2.18 yet (should I?).
And another question, is there anybody successfully using
Gigabyte 6VXD7 board with two CPUs under Linux 2.4.0-test12 (Netware
worked without any patch, just FYI) ?
Thanks,
Petr Vandrovec
[EMAIL PROTECTED]
Variant #1:
diff -urdN linux/arch/i386/kernel/smpboot.c linux/arch/i386/kernel/smpboot.c
--- linux/arch/i386/kernel/smpboot.cMon Dec 4 01:48:19 2000
+++ linux/arch/i386/kernel/smpboot.cWed Dec 13 22:30:47 2000
@@ -694,9 +694,22 @@
apic_write_around(APIC_ICR, APIC_DM_STARTUP
| (start_eip >> 12));
+ /*
+* Petr Vandrovec:
+*
+* We must not do I/O operations for at least
+* 300us... printk does (probably acquiring spinlock
+* kills it)... Kills VT82C694X based
+* SMP board. At least mine GA-6VXD7.
+* 100us is not enough, 200us is enough,
+* so I use 300us for additional safety.
+*/
+
+ udelay(300);
+
Dprintk("Startup point 1.\n");
Dprintk("Waiting for send to finish...\n");
timeout = 0;
do {
Dprintk("+");
Variant #2:
--- linux/arch/i386/kernel/smpboot.cMon Dec 4 02:48:19 2000
+++ linux/arch/i386/kernel/smpboot.cWed Dec 13 23:29:11 2000
@@ -694,9 +694,19 @@
apic_write_around(APIC_ICR, APIC_DM_STARTUP
| (start_eip >> 12));
+ /*
+* Petr Vandrovec:
+*
+* We must not do I/O operations for at least
+* 300 us... printk does (probably acquiring spinlock
+* kills it)... Kills VT82C694X based
+* SMP board. At least mine GA-6VXD7.
+
Dprintk("Startup point 1.\n");
Dprintk("Waiting for send to finish...\n");
+*/
+
timeout = 0;
do {
Dprintk("+");
-
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/
test12: eth0 trasmit timed out after one hour uptime
hi all, after about an hour of uptime [and heavy HD usage] my ethernet just died. couldn't ping a thing. syslog showed: Dec 13 14:51:46 sanfrancisco kernel: NETDEV WATCHDOG: eth0: transmit timed out Dec 13 14:51:46 sanfrancisco kernel: eth0: transmit timed out, tx_status 00 status e680. Dec 13 14:51:46 sanfrancisco kernel: Flags; bus-master 1, full 1; dirty 3306(10) current 3322(10). Dec 13 14:51:46 sanfrancisco kernel: Transmit list vs. c7c732a0. Dec 13 14:51:46 sanfrancisco kernel: 0: @c7c73200 length 802a status 0001002a Dec 13 14:51:46 sanfrancisco kernel: 1: @c7c73210 length 802a status 0001002a Dec 13 14:51:46 sanfrancisco kernel: 2: @c7c73220 length 802a status 0001002a Dec 13 14:51:46 sanfrancisco kernel: 3: @c7c73230 length 802a status 0001002a Dec 13 14:51:46 sanfrancisco kernel: 4: @c7c73240 length 802a status 0001002a Dec 13 14:51:46 sanfrancisco kernel: 5: @c7c73250 length 802a status 0001002a Dec 13 14:51:46 sanfrancisco kernel: 6: @c7c73260 length 802a status 0001002a Dec 13 14:51:46 sanfrancisco kernel: 7: @c7c73270 length 802a status 0001002a Dec 13 14:51:46 sanfrancisco kernel: 8: @c7c73280 length 802a status 8001002a Dec 13 14:51:46 sanfrancisco kernel: 9: @c7c73290 length 802a status 8001002a Dec 13 14:51:46 sanfrancisco kernel: 10: @c7c732a0 length 804b status 0001004b Dec 13 14:51:46 sanfrancisco kernel: 11: @c7c732b0 length 804b status 0001004b Dec 13 14:51:46 sanfrancisco kernel: 12: @c7c732c0 length 802a status 0001002a Dec 13 14:51:46 sanfrancisco kernel: 13: @c7c732d0 length 802a status 0001002a Dec 13 14:51:46 sanfrancisco kernel: 14: @c7c732e0 length 802a status 0001002a Dec 13 14:51:46 sanfrancisco kernel: 15: @c7c732f0 length 802a status 0001002a after reboot it works fine again [i'll give it an hour...] test12-pre8 and before worked fine. any ideas? -- thanks! joe -- Joseph Cheek, Sr Linux Consultant, Linuxcare | http://www.linuxcare.com/ Linuxcare. Support for the Revolution. | [EMAIL PROTECTED] CTO / Acting PM, Redmond Linux Project | [EMAIL PROTECTED] 425 990-1072 vox [1074 fax] 206 679-6838 pcs | [EMAIL PROTECTED] - 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: test12: innd bug came back?
And the problem started with pre8 not final. currently investigating difference pre7-pre8 Albert Linus Torvalds wrote: > > In article <[EMAIL PROTECTED]>, > Alexander Viro <[EMAIL PROTECTED]> wrote: > > > > > >On 13 Dec 2000, Henrik [ISO-8859-1] Størner wrote: > > > >> Just to add a "me too" on this. I didn't report when I saw it last week, > >> because I was uncertain of exactly what might have caused it - I was > >> booting several different kernels at the time, including one from a > >> rescue disk (I was trying to salvage bits of a Win9x disk at the time - > >> don't ask for details!) > >> > >> Alas, I lost the test program someone wrote to test for the truncate > >> problem, and due to moving I will not be able to test anything until > >> next Monday. But if needed, I can do some testing then. Something > >> definitely went wrong with innd during the test12 pre-patches. > > > >It may be a side effect of removing partial_clear() in test12-final. > > No. If you read the code, partial_clear() has been a no-op for the > longest time (the "start & ~PAGE_MASK" thing could never trigger, as > "start" has been page-aligned for a long long while now. > > So it must be something else. > > Linus > - > 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/ -- Albert Cranford Deerfield Beach FL USA [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12 randomly hangs up
In article <[EMAIL PROTECTED]> you wrote: > I can (re)confirm that. I work several hours on console without any > problem ... then I start X session and after several minutes system > hangs. I can confirm that, too. Todaye, crashed two difference machines One: AMD-K6 3D, 300 MHz, RH 7.0 + updates, 64MB RAM Second one: AMD Athlon 600, 600MHz with, 128MB RAM, RH 7.0+updates > Red Hat 7.0, XFree-3.3.6 (SVGA server), S3Virge/G2 (4MB) > (no problems with -test11 and 2.2.x before ...) Exactly -- *[ ukasz Trbiski ]* SysAdmin @wsisiz.edu.pl - 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: Signal 11 - the continuing saga
Err, for those of us who aren't up to our elbows in the kernel code, is there a patch for this? Presumeably this will be rolled into 2.4.0test13 but I'd like to try it out? Also, can someone summarize the fix in English along with the expected, improved behavior (e.g. Linux will never have a signal 11 again and will never, ever crash ;-) Finally, as soon as there is a patch, can other people who have seen this problem test it. My problem is so random that I'd need at least a few days to gain some confidence this is fixed. Thanks all. --Rainer > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Linus Torvalds > Sent: Thursday, December 14, 2000 5:19 AM > To: Mike Galbraith > Cc: Kernel Mailing List > Subject: Re: Signal 11 - the continuing saga > > > On Wed, 13 Dec 2000, Linus Torvalds wrote: > > > > Hint: "ptep_mkdirty()". > > In case you wonder why the bug was so insidious, what this caused was two > separate problems, both of them able to cause SIGSGV's. > > One: we didn't mark the page table entry dirty like we were supposed to. > > Two: by making it writable, we also made the page shared, even if it > wasn't supposed to be shared (so when the next process wrote to the page, > if the swap page was shared with somebody else, the changes would show up > even in the process that _didn't_ write to it). > > And "ptep_mkdirty()" is only used by swapoff, so nothing else would show > this. Which was why it hadn't been immediately obvious that anything was > broken. > > Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12 randomly hangs up
Martin Macok wrote: > > Hi, > after 1-3 hours with -test12 system hangs up with > - no response from mouse > - no response from keyboard (no sysrq, only sysrq+'b' works ...) > - no response from network (ICMP, TCP) > - nothing on console, nothing in logs (ie. nothing interesting or relevant >to crash). > > System was not under load (1 user, X, no swapping ...) > > ( -test11 was up for 3 weeks with no problems and so do 2.2.17 ... ) > > slightly modified Red Hat 7.0: > > Linux sarah.x 2.4.0-test11 #4 Sat Dec 9 14:24:20 CET > 2000 i586 unknown > Kernel modules 2.3.21 > Gnu C 2.96 > Gnu Make 3.79.1 > Binutils 2.10.0.18 > Linux C Library> libc.2.2 > Dynamic linker ldd (GNU libc) 2.2 > Procps 2.0.7 > Mount 2.10m > Net-tools 1.56 > Console-tools 0.3.3 > Sh-utils 2.0 > Modules Loaded nls_iso8859-2 nls_cp852 vfat mad16 ad1848 sb_lib > uart401 > > DMESG: http://kocour.ms.mff.cuni.cz/~macok/kernel/dmesg > (Abit PX5, P166 (ovrclckd to 166), 128MB RAM, 2x IDE HDD, 3com509b ISA, Opti931) Overclocking is a guaranteed way to get random hangups. Put it back to its recommended clock and it might work fine. Keep in mind that while this may not have shown up before, overclocking gradually degrades a processor's stability (trust me, I ran several 486 and pentiums and even a k6-2 down to where they wouldn't even work at the normal clock). Try sticking it back to normal. - 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: via82cxxx_audio - bad latency
Paul Jakma wrote: > > hi, > > i think somethings gone wrong with via82cxxx_audio. Playing anything > through it seems to cause massive latency in apps like xmms, esd, > asmixer, etc.. anything to do with playing or mixer levels suddenly > takes a minute or more to respond. > > It didn't always do this, and when it started happening i assumed it > was either something bad in esd or xmms (which i tend to upgrade a > lot). However it still happens when esd is disabled. eg, i use mpg123 > to play an mp3 file, and asmixer doesn't change the volume till a > minute or two after i moused it. > > if i SIGSTOP mpg123, asmixer immediately becomes responsive again and > implements the pending volume change, as soon i SIGCONT mpg123, > asmixer becomes very unresponsive again. > > same thing with esd, if i STOP mpg123, other apps like esd and > non-esd mixers become responsive, soon as i start playing again they > go unresponsive. > > same thing with playing from esd applications, everything inlcuding > the playing app itself (eg xmms) is unresponsive, if i STOP it, the > mixers instantly become responsive, soon as i CONT the playing app > everything is "dead" again. > > kernel is test12-final. AMD K7, Asus K7M board > > the via is sharing an interrupt, though normally the buslogic is not > being used. (the interrupt sharing has been there a lot longer than > this problem) I ran into the same problems with the same driver. Sharing an interrupt isn't the problem, it's just a really young driver. The ALSA driver works fine, but I switched to an Ensoniq/Creative PCI card because I found that the chipset just clipped like mad anyway (just cheapness, I suppose, or maybe I'm doing something wrong) when mixing sounds together (as in Quake3 or esd). If you want to use it, though, I'd suggest using ALSA. It works. Alternatively, you could fix the OSS driver. - 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/
Adaptec AIC7XXX v 6.0.6 BETA Released
daptec SCSI HBA device driver for the Linux Operating System To: [EMAIL PROTECTED] cc: Fcc: +outbox Subject: Adaptec AIC7XXX v6.0.6 BETA Released --- After several months of testing and refinement, the Adaptec sponsored aic7xxx driver is now entering Beta testing. Although still missing domain validation and the last bits of cardbus support, there are no known issues with the driver. I would encourage all users of card supported by this driver to try the new code and submit feedback. Patches for late 2.2.X, 2.3.99 and 2.4.0 are provided in the driver distribution. For those of you building the driver as a module, take note that the module name is now "aic7xxx_mod" rather than "aic7xxx". As always, the most recent distribution is available here: http://people.FreeBSD.org/~gibbs/linux/ -- Justin - 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: insmod problem after modutils upgrading
> previously because nobody used those options. Since these are bugs in > the modules and only a few modules are affected (less than 5 reported), > the fix is to correct the modules that have coding errors. That wont be happening in 2.2 until 2.2.19 which probably means 6 months. If this is your decision please make it abundantly clear that the new modutils are a 2.4 only package. - 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] 2.4.0-test12:
On Wed, Dec 13, 2000 at 07:23:52PM +, Tim Waugh wrote: > + * atomic_add - add integer to atomic variable > + * @i: integer value to add > + * @v: pointer of type atomic_t > + * > + * Atomically adds @i to @v. Perhaps it should mention that the guaranteed useful range of atomic_t is only 24bit ? Documentation without source would rather useless if it didn't mention such pitfalls. -Andi - 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: insmod problem after modutils upgrading
On Wed, 13 Dec 2000 21:10:54 + (GMT), Alan Cox <[EMAIL PROTECTED]> wrote: >It is modutils. Their behaviour changed in a non back compatible way. Do not >use modutils 2.3.22 with Linux 2.2.* is the simple answer. Perhaps Keith can >make this a warning in 2.3.23 Adding persistent module data to modutils meant that insmod had to be a lot more picky about MODULE_PARM() entries. There were a few modules that had invalid MODULE_PARM() entries, nobody had spotted them previously because nobody used those options. Since these are bugs in the modules and only a few modules are affected (less than 5 reported), the fix is to correct the modules that have coding errors. - 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: test12: innd bug came back?
In article <[EMAIL PROTECTED]>, Alexander Viro <[EMAIL PROTECTED]> wrote: > > >On 13 Dec 2000, Henrik [ISO-8859-1] Størner wrote: > >> Just to add a "me too" on this. I didn't report when I saw it last week, >> because I was uncertain of exactly what might have caused it - I was >> booting several different kernels at the time, including one from a >> rescue disk (I was trying to salvage bits of a Win9x disk at the time - >> don't ask for details!) >> >> Alas, I lost the test program someone wrote to test for the truncate >> problem, and due to moving I will not be able to test anything until >> next Monday. But if needed, I can do some testing then. Something >> definitely went wrong with innd during the test12 pre-patches. > >It may be a side effect of removing partial_clear() in test12-final. No. If you read the code, partial_clear() has been a no-op for the longest time (the "start & ~PAGE_MASK" thing could never trigger, as "start" has been page-aligned for a long long while now. So it must be something else. Linus - 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: test12: innd bug came back?
On 13 Dec 2000, Henrik [ISO-8859-1] Størner wrote:
> Just to add a "me too" on this. I didn't report when I saw it last week,
> because I was uncertain of exactly what might have caused it - I was
> booting several different kernels at the time, including one from a
> rescue disk (I was trying to salvage bits of a Win9x disk at the time -
> don't ask for details!)
>
> Alas, I lost the test program someone wrote to test for the truncate
> problem, and due to moving I will not be able to test anything until
> next Monday. But if needed, I can do some testing then. Something
> definitely went wrong with innd during the test12 pre-patches.
It may be a side effect of removing partial_clear() in test12-final.
Relevant chunk (in mm/memory.c):
@@ -953,10 +914,6 @@
/* Ok, partially affected.. */
start += diff << PAGE_SHIFT;
len = (len - diff) << PAGE_SHIFT;
- if (start & ~PAGE_MASK) {
- partial_clear(mpnt, start);
- start = (start + ~PAGE_MASK) & PAGE_MASK;
- }
flush_cache_range(mm, start, end);
zap_page_range(mm, start, len);
flush_tlb_range(mm, start, end);
should actually be
@@ -954,7 +915,6 @@
start += diff << PAGE_SHIFT;
len = (len - diff) << PAGE_SHIFT;
if (start & ~PAGE_MASK) {
- partial_clear(mpnt, start);
start = (start + ~PAGE_MASK) & PAGE_MASK;
}
flush_cache_range(mm, start, end);
IOW, we have off-by-one when calling zap_page_range() and friends.
Cheers,
Al
-
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: test12: innd bug came back?
In <[EMAIL PROTECTED]> Anton Petrusevich <[EMAIL PROTECTED]> writes: >Today I saw well-known "innd bug"(truncate(tm)), and my brother said >he had seen it with -test12-pre7. I don't know about -test12-pre3, >neither I nor my brother hadn't noticed it since -test10. But we could >miss it with -test12-pre3, and I didn't try any -test11 kernels. Thus >possibly that was introduced changes between -test12-pre3 and >-test12-pre7, but I can definitly say it present in -test12-final. Just to add a "me too" on this. I didn't report when I saw it last week, because I was uncertain of exactly what might have caused it - I was booting several different kernels at the time, including one from a rescue disk (I was trying to salvage bits of a Win9x disk at the time - don't ask for details!) Alas, I lost the test program someone wrote to test for the truncate problem, and due to moving I will not be able to test anything until next Monday. But if needed, I can do some testing then. Something definitely went wrong with innd during the test12 pre-patches. -- Henrik Storner | "Crackers thrive on code secrecy. Cockcroaches breed <[EMAIL PROTECTED]> | in the dark. It's time to let the sunlight in." | | Eric S. Raymond, re. the Frontpage backdoor - 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 ipv6 questions. bugs?
On Wed, 13 Dec 2000, [EMAIL PROTECTED] wrote: > Hello! > > > 0. whenever i ping6 the loopback interface (::1/128), all echo requests > > seem to be dropped and i get no echo replies. is this correct? > Your guess? 8) Of course, it is incorrect. I even have no idea > how it is possible to put system into such sad state. well, just power it on, it seems. but then again, this is just a guess. =;] > Though... probably, you forgot to up loopback. doesn't look it: [root@nsv6 /root]# ifconfig lo loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:7952 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 [root@nsv6 /root]# ping6 ::1 PING ::1(::1) from ::1 : 56 data bytes --- ::1 ping statistics --- 156 packets transmitted, 0 packets received, 100% packet loss ...and this is right after boot. > > the destination mac address is set to the linux box's mac address and > > the source mac address is set to 0:0:0:0:0:0. > > I think it is consequence of above. When loopback interface is missing, > networking does not work. > > > > other way around? this would explain why the openbsd box doesn't > > respond to the linux box's n.s. until it starts looking at all the > > packets in promisc mode, right? > > Rather it means that openbsd is buggy, its stack accepts packets > not destined to it. It cannot react to those strange packets, which > you have just described. that may very well be, but shouldn't the neighbor solisitation packets from the linux box have the source mac address set to its mac address and the destination mac address set to 0:0:0:0:0:0 and not the other way around? thanks, pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: insmod problem after modutils upgrading
Alan Cox wrote: > > > > how can i make insmod load the network module again pls? > > > > I "fixed" the same problem in 2.2.18 by commenting out the line > > > > MODULE_PARM (debug, "i"); > > > > near the end of drivers/net/8139too.c. Since I run modutils 2.3.22 > > as well, it can't be related to the modutils. > > It is modutils. Their behaviour changed in a non back compatible way. Do not > use modutils 2.3.22 with Linux 2.2.* is the simple answer. Perhaps Keith can > make this a warning in 2.3.23 That, and/or allow "insmod -f" to load the module. '-f' has become pretty useless lately... :) Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - 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: insmod problem after modutils upgrading
> > how can i make insmod load the network module again pls? > > I "fixed" the same problem in 2.2.18 by commenting out the line > > MODULE_PARM (debug, "i"); > > near the end of drivers/net/8139too.c. Since I run modutils 2.3.22 > as well, it can't be related to the modutils. It is modutils. Their behaviour changed in a non back compatible way. Do not use modutils 2.3.22 with Linux 2.2.* is the simple answer. Perhaps Keith can make this a warning in 2.3.23 - 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: insmod problem after modutils upgrading
Christian Ullrich wrote: > > * Corisen schrieb am Donnerstag, 14.12.2000: > > > executing "insmod 8139too" at the command prompt shows the following error > > message: > > using /lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o > > /lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o: symbol for > > parameter debug not found. > > > how can i make insmod load the network module again pls? > > I "fixed" the same problem in 2.2.18 by commenting out the line > > MODULE_PARM (debug, "i"); > > near the end of drivers/net/8139too.c. Since I run modutils 2.3.22 > as well, it can't be related to the modutils. Yep, that's the correct fix -- remove that line. My apologies to Keith Owens for originally saying the opposite (I deal with so many net drivers they all get jumbled up in my mind) Jeff -- Jeff Garzik | Building 1024 | These are not the J's you're lookin' for. MandrakeSoft| It's an old Jedi mind trick. - 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: insmod problem after modutils upgrading
* Corisen schrieb am Donnerstag, 14.12.2000: > executing "insmod 8139too" at the command prompt shows the following error > message: > using /lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o > /lib/modules/2.4.0-test12/kernel/drivers/net/8139too.o: symbol for > parameter debug not found. > how can i make insmod load the network module again pls? I "fixed" the same problem in 2.2.18 by commenting out the line MODULE_PARM (debug, "i"); near the end of drivers/net/8139too.c. Since I run modutils 2.3.22 as well, it can't be related to the modutils. -- Christian UllrichRegistrierter Linux-User #125183 "Sie können nach R'ed'mond fliegen -- aber Sie werden sterben" - 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: Signal 11 - the continuing saga
On Wed, 13 Dec 2000, Linus Torvalds wrote: > > > Ehh, I think I found it. > > Hint: "ptep_mkdirty()". > > Oops. > > I'll bet you $5 USD (and these days, that's about a gadzillion Euros) that Poor European Gérard as slim as 1.84 meter - 78 Kg these days. What about old days poor European Linus versus these days American Linus on these points ? ;-) > this explains it. Really ? :o) > Linus Gérard. - 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/
[hch@caldera.de: [PATCH] fix 2.4.0-test12 scsi makefile]
- Forwarded message from Christoph Hellwig <[EMAIL PROTECTED]> - Date: Wed, 13 Dec 2000 21:52:21 +0100 From: Christoph Hellwig <[EMAIL PROTECTED]> To: Linus Torvalds <[EMAIL PROTECTED]> Subject: [PATCH] fix 2.4.0-test12 scsi makefile X-Mailer: Mutt 1.0i Hi Linus, this patch makes scsi usable not in the common case where scsi itself is built into the kernel and some drivers are modules - the patch in 2.4.0-test12 made it work for modules only on parisc64 - now it should work everywhere. The comment in the patch explains how it works. Please apply. Christoph -- Whip me. Beat me. Make me maintain AIX. diff -uNr --exclude-from=dontdiff linux-2.4.0-test12/drivers/scsi/Makefile linux/drivers/scsi/Makefile --- linux-2.4.0-test12/drivers/scsi/MakefileTue Dec 12 22:41:34 2000 +++ linux/drivers/scsi/Makefile Wed Dec 13 22:12:02 2000 @@ -140,6 +140,9 @@ obj-m := $(filter-out $(obj-y), $(obj-m)) int-m := $(filter-out $(int-y), $(int-m)) +# Take multi-part drivers out of obj-y and put components in. +obj-y := $(filter-out $(list-multi), $(obj-y)) $(int-y) + O_OBJS := $(filter-out $(export-objs), $(obj-y)) OX_OBJS:= $(filter $(export-objs), $(obj-y)) M_OBJS := $(sort $(filter-out $(export-objs), $(obj-m))) - End forwarded message - -- Of course it doesn't work. We've performed a software upgrade. Whip me. Beat me. Make me maintain AIX. - 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: Signal 11 - the continuing saga
On Wed, Dec 13, 2000 at 11:35:57AM -0800, Linus Torvalds wrote: > > > Ehh, I think I found it. > > Hint: "ptep_mkdirty()". > > Oops. > > I'll bet you $5 USD (and these days, that's about a gadzillion Euros) that > this explains it. > > Linus Good. Sounds like you guys have a handle on it now. :-) Jeff > > - > 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/ - 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/
Slow NFS mounting with 2.2.18
Hello!
After changing kernels from 2.2.17 to 2.2.18 I found that NFS
mounts now take ages. (Well, 15 seconds.) With 2.2.17, they went
through in about half a second. Once the mount is done, all
operations seem to run with the usual speed.
The client is vanilla 2.2.18, the server is vanilla 2.2.17.
The fs to mount from the server is reiserfs, as is the mount
point on the client. Both machines are connected to each other
and nothing else.
I tried 2.2.18's nfs module both with and without NFSv3 support.
syslog on the client:
Dec 13 21:26:22 christian automount[9814]: attempting to mount entry /mnt/mp3
Dec 13 21:26:22 christian automount[9964]: lookup(file): looking up mp3
Dec 13 21:26:22 christian automount[9964]: lookup(file): mp3 -> -ro,rsize=8192^I
Dec 13 21:26:22 christian automount[9964]: parse(sun): expanded entry: -ro,rsize
Dec 13 21:26:22 christian automount[9964]: parse(sun): dequote("ro,rsize=8192^I^
Dec 13 21:26:22 christian automount[9964]: parse(sun): gathered options: ro,rsiz
Dec 13 21:26:22 christian automount[9964]: parse(sun): dequote("ser1:/mnt/mp3")
Dec 13 21:26:22 christian automount[9964]: parse(sun): core of entry: options=ro
Dec 13 21:26:22 christian automount[9964]: parse(sun): mounting root /mnt, mount
Dec 13 21:26:22 christian automount[9964]: mount(nfs): root=/mnt name=mp3/ what
Dec 13 21:26:22 christian automount[9964]: mount(nfs): nfs options="ro,rsize=819
Dec 13 21:26:22 christian automount[9964]: mount(nfs): calling mkdir_path /mnt/m
Dec 13 21:26:22 christian automount[9964]: mount(nfs): calling mount -t nfs -s -
Dec 13 21:26:22 christian kernel: nfs warning: mount version older than kernel
Dec 13 21:26:27 christian kernel: portmap: too small RPC reply size (0 bytes)
Dec 13 21:26:37 christian automount[9964]: mount(nfs): mounted ser1:/mnt/mp3 on
Dec 13 21:26:37 christian kernel: portmap: too small RPC reply size (0 bytes)
syslog on the server:
Dec 13 21:26:23 ser1 mountd[153]: NFS mount of /mnt/mp3 attempted from 192.168.0.2
Dec 13 21:26:23 ser1 mountd[153]: /mnt/mp3 has been mounted by 192.168.0.2
The server's clock is about one second ahead, so it looks as if the
server completed the job in the same second, and the client slept
for a while. The mount process stayed in D state all the time.
--
Christian UllrichRegistrierter Linux-User #125183
"Sie können nach R'ed'mond fliegen -- aber Sie werden sterben"
-
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] I-Opener fix (again)
On Wed, Dec 13, 2000 at 01:20:02PM -0700, Tim Riker wrote: > Andre, > > What are the "laptops that have CFA devices that do not come on channels > in a pair" systems you refer to? I assume he's referring to flash devices which show up as an IDE bus with only a master and no slave, and don't handle slave accesses well (right?). It should be noted that my patch does _not_ break these cases at all. -alex - 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 ipv6 questions. bugs?
Hello! > 0. whenever i ping6 the loopback interface (::1/128), all echo requests > seem to be dropped and i get no echo replies. is this correct? Your guess? 8) Of course, it is incorrect. I even have no idea how it is possible to put system into such sad state. Though... probably, you forgot to up loopback. > the destination mac address is set to the linux box's mac address and > the source mac address is set to 0:0:0:0:0:0. I think it is consequence of above. When loopback interface is missing, networking does not work. > other way around? this would explain why the openbsd box doesn't > respond to the linux box's n.s. until it starts looking at all the > packets in promisc mode, right? Rather it means that openbsd is buggy, its stack accepts packets not destined to it. It cannot react to those strange packets, which you have just described. Alexey - 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] Bug in date converting functions DOS<=>UNIX in FAT,NCPFS and SMBFS drivers [second attempt]
On Wed, 13 Dec 2000, Igor Yu. Zhbanov wrote: > I think your testprogram is broken (or else my testprogram is broken :). Yes, you were right. Mine must have been broken (possibly caused by trying to make it readable :). Thanks. Alan, if you still have the patch please apply it to smbfs in 2.2 (and possibly fat too, I assume it is the same). If you don't I'll send it again for 2.2.19pre2 or so. /Urban - 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/
