Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-08 Thread Matthew Dillon
:I agree that the use of cpu_critical_enter/exit could use cleaning up. :Can you give an example of where critical_enter is used improperly? :You mean in fork_exit? Your changes to cpu_switch solve that problem :with critical_exit almost unchanged. The savecrit stuff should really :just be

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-08 Thread Bruce Evans
On Thu, 7 Mar 2002, Jake Burkholder wrote: Apparently, On Thu, Mar 07, 2002 at 05:21:21PM -0500, Robert Watson said words to the effect of; The primary objections I've seen from Jake, and he posted them as part of the earlier thread prior to the commit, was that the API changes

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-08 Thread John Baldwin
On 08-Mar-02 Matthew Dillon wrote: :I agree that the use of cpu_critical_enter/exit could use cleaning up. :Can you give an example of where critical_enter is used improperly? :You mean in fork_exit? Your changes to cpu_switch solve that problem :with critical_exit almost unchanged. The

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-08 Thread Jake Burkholder
Apparently, On Fri, Mar 08, 2002 at 01:23:01AM -0800, Matthew Dillon said words to the effect of; :I agree that the use of cpu_critical_enter/exit could use cleaning up. :Can you give an example of where critical_enter is used improperly? :You mean in fork_exit? Your changes to

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-08 Thread Matthew Dillon
:On 08-Mar-02 Matthew Dillon wrote: : ::I agree that the use of cpu_critical_enter/exit could use cleaning up. ::Can you give an example of where critical_enter is used improperly? ::You mean in fork_exit? Your changes to cpu_switch solve that problem ::with critical_exit almost unchanged.

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-08 Thread Matthew Dillon
:The reason is that if they are in MI code they automatically apply to all :platforms and can't get out sync. When they are modified to handle preemption :the freebsd kernel will be fully preemptive. Not, it works on i386 and its :believed to work on alpha and powerpc is not preemptive at all

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread M. Warner Losh
In message: [EMAIL PROTECTED] Matthew Dillon [EMAIL PROTECTED] writes: : We have very different development models, and different priorities. : I'm not sure why you are attempting to impose your development model : and priorities on me. This is the work I want to do.

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Justin T. Gibbs
The API is intended for the stage-2 commit. The stage-1 commit is intended to do all the 'hard stuff' in as straightforward a manner as possible. The sysctl / option you talk about here existed in my patch set 2 and a half weeks ago. The API and getting it right is more

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Peter Schultz
Can someone please end this nightmare? If you've reviewed the patch and found substantive reason to contest it then speak now else the patch should be commited today so that forward progress can continue. I mean, cut the crap and state the facts you see about the code or sit in silence while

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Michael Smith
Trim your cc's. I'm sorry, but simply not liking the idea of someone else doing a particular optimization now verses later is not a good enough reason to require that 40+ hours worth of work be thrown away when that other person has stated, repeatedly, that he will support

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Julian Elischer
On Thu, 7 Mar 2002, Michael Smith wrote: Trim your cc's. I'm sorry, but simply not liking the idea of someone else doing a particular optimization now verses later is not a good enough reason to require that 40+ hours worth of work be thrown away when that other

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Bruce A. Mah
If memory serves me right, Bruce A. Mah wrote: [snip] Disregard. I hit the wrong button in my MUA. Sorry for the spammage. Bruce. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread M. Warner Losh
: those reviews object on a purely subjective manner. : : : I think this is premature : : I don't consider that to be a technical review? do you? If that's what he said, no. However, that's not all that he said. Also, Jake had several objections from a sparc64 perspective that weren't

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Matthew Dillon
:The API is intended for the stage-2 commit. The stage-1 commit :is intended to do all the 'hard stuff' in as straightforward :a manner as possible. The sysctl / option you talk about here :existed in my patch set 2 and a half weeks ago. : :The API and getting it right is more

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Jake Burkholder
Apparently, On Thu, Mar 07, 2002 at 05:21:21PM -0500, Robert Watson said words to the effect of; On Thu, 7 Mar 2002, Warner Losh wrote: In message [EMAIL PROTECTED] Julian Elischer writes: : : : On Thu, 7 Mar 2002, Justin T. Gibbs wrote: : : Then do the right

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Justin T. Gibbs
:I didn't have to read the patch to know that there were concerns and :on-going discussion about the API. In this instance, the issues are :not large and can be remedied quickly - all the more reason for the :discussion to take place before the commit. Again, bullshit. You should have read

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Matthew Dillon
: :You came to the conclusion that only *your decision* on what was :an appropriate proceedure was the one that mattered. That's not :the way this project works. You can't act unilaterally. When people :ask you to hold off (and they even asked politely!) so discussion :can take place, that is

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Julian Elischer
On Thu, 7 Mar 2002, Justin T. Gibbs wrote: The only way it will get delayed that long is if you spend all of your time stomping up and down, writing in all caps, and tell the rest of us that we have to follow the proceedures you think are appropriate. That's not how colaboration works.

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread David Greenman
No, Core has just said that he doesn't because he can over-rule any change in the kernel. And there is no requirement for him to justify it. That is definately *NOT* what core has said. Please go re-read our announcement of the SMPng tech lead appointment. We specifically indicate that the

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Julian Elischer
On Thu, 7 Mar 2002, David Greenman wrote: No, Core has just said that he doesn't because he can over-rule any change in the kernel. And there is no requirement for him to justify it. That is definately *NOT* what core has said. Please go re-read our announcement of the SMPng tech lead

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Justin T. Gibbs
: :You came to the conclusion that only *your decision* on what was :an appropriate proceedure was the one that mattered. That's not :the way this project works. You can't act unilaterally. When people :ask you to hold off (and they even asked politely!) so discussion :can take place, that is

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Justin T. Gibbs
On Thu, 7 Mar 2002, Justin T. Gibbs wrote: The only way it will get delayed that long is if you spend all of your time stomping up and down, writing in all caps, and tell the rest of us that we have to follow the proceedures you think are appropriate. That's not how colaboration works.

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Bruce A. Mah
If memory serves me right, Justin T. Gibbs wrote: : :You came to the conclusion that only *your decision* on what was :an appropriate proceedure was the one that mattered. That's not :the way this project works. You can't act unilaterally. When people :ask you to hold off (and they even

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Matthew Dillon
:Yes. What I would like and what I mentioned before is for this to be :hidden behind cpu_critical_enter/exit. Specifically, cpu_critical_enter :would be a null macro for i386, which would turn critical_enter into :just an increment, as Matt wanted. cpu_critical_exit would do all the :magic of

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Garance A Drosihn
At 7:04 PM -0800 3/7/02, Matthew Dillon wrote: :Bruce also had some comments which were shrugged off, I thought they :were important. Specifically, please do not make unnecessary changes :to the assembler code. Macros do not need to be defined before they :are used, I believe this was the

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Julian Elischer
On Thu, 7 Mar 2002, Justin T. Gibbs wrote: Then do the right things so it will. Unfortunatly that has been proven to not work. after reverting the change and silently waiting for a week 1/ no person bothered to review it. 2/ people assumed the patch had gone away. To Unsubscribe: send

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Warner Losh
In message [EMAIL PROTECTED] Julian Elischer writes: : : : On Thu, 7 Mar 2002, Justin T. Gibbs wrote: : : Then do the right things so it will. : : Unfortunatly that has been proven to not work. : : after reverting the change and silently waiting for a week : 1/ no person bothered to

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Julian Elischer
those reviews object on a purely subjective manner. I think this is premature I don't consider that to be a technical review? do you? they do not even comment on the bug-fixing aspect of the patch. On Thu, 7 Mar 2002, Warner Losh wrote: In message [EMAIL PROTECTED] Julian Elischer writes:

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread John Baldwin
On 07-Mar-02 Matthew Dillon wrote: :Search for paper John Baldwin and find link 6: : :http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=199282+204026+/usr/local/www/db/ :text/2002/freebsd-arch/20020303.freebsd-arch : :The actual paper is at: :

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Robert Watson
On Thu, 7 Mar 2002, Warner Losh wrote: In message [EMAIL PROTECTED] Julian Elischer writes: : : : On Thu, 7 Mar 2002, Justin T. Gibbs wrote: : : Then do the right things so it will. : : Unfortunatly that has been proven to not work. : : after reverting the change and silently

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Matthew Dillon
: :In otherwords. You acted unilaterally. You seem to be making my :arguments for me. Again. Thanks! No, I am not acting unilaterally, but neither do I feel it is appropriate to be told to wait indefinitely (and I am STILL waiting by the way!). When I commit something it isn't set

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Matthew Dillon
:: after reverting the change and silently waiting for a week :: 1/ no person bothered to review it. :: 2/ people assumed the patch had gone away. : :Ummm, There are reviews in the archives that object to the API as it :relates to optimization and those objections haven't been sanely :answered

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Matthew Dillon
:You seemed to have missed the entire part where we handle deferred preemptions :in MI code in critical_exit(). The critical_enter/exit stuff really exists to :support the preemption code and to get rid of the various FOO_NOSWITCH flags. :I think it is ok to remove the linkage between

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Matthew Dillon
:The primary objections I've seen from Jake, and he posted them as part of :the earlier thread prior to the commit, was that the API changes proposed :by Matt don't make sense for the sparc64 implementation, uni-processor or :multi-processor, and that while these changes might be appropriate for

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Bosko Milekic
On Thu, Mar 07, 2002 at 02:43:36PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Julian Elischer writes: : : : On Thu, 7 Mar 2002, Justin T. Gibbs wrote: : : Then do the right things so it will. : : Unfortunatly that has been proven to not work. : : after reverting the

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Greg Lehey
On Tuesday, 5 March 2002 at 9:43:29 -0800, Matthew Dillon wrote: phk wrote: you have a right to bully the only person who have consistently chugged away at the SMPng project when practically everybody else (you included) defected. This is an extreme misrepresentation of the facts. I

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Greg Lehey
On Thursday, 7 March 2002 at 14:30:47 -0800, Matthew Dillon wrote: after reverting the change and silently waiting for a week 1/ no person bothered to review it. 2/ people assumed the patch had gone away. Ummm, There are reviews in the archives that object to the API as it relates to

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Matthew Dillon
:Perhaps that part of the update could be considered cosmetic, and :thus be done as a separate update -- just so people can tell which :lines are cosmetic changes and which ones are substantive. That is :more work for you, but it makes it easier on reviewers, and it is :certainly consistent

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-07 Thread Jake Burkholder
Apparently, On Thu, Mar 07, 2002 at 07:04:49PM -0800, Matthew Dillon said words to the effect of; :Yes. What I would like and what I mentioned before is for this to be :hidden behind cpu_critical_enter/exit. Specifically, cpu_critical_enter :would be a null macro for i386, which

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-06 Thread John Baldwin
On 05-Mar-02 Matthew Dillon wrote: : It makes no sense whatsoever to me to be told not to commit something : due to stale code that may not be quite compatible sitting in P4 that : you can't make work in any reasonable time frame. You should stop : trying to screw over my work

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-06 Thread Matthew Dillon
:Have you read the paper I posted to arch? It quite clearly (I thought) :explained the role of the critical_* and the cpu_critical_* in the preemption :code. It should be rather obvious from that why I don't want the critical_* I'm sorry John, I have no idea what you are refering to here.

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-06 Thread Julian Elischer
On Wed, 6 Mar 2002, Jeroen C.van Gelderen wrote: Search for paper John Baldwin and find link 6: A good start though incomplete. Unfortunate that it took such a fight to get it to be written. Hopefully it's existance can prevent soem further bloodshed. Is it possible for other people to add

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-06 Thread Matthew Dillon
:Search for paper John Baldwin and find link 6: : :http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=199282+204026+/usr/local/www/db/ :text/2002/freebsd-arch/20020303.freebsd-arch : :The actual paper is at: : http://www.FreeBSD.org/~jhb/smpng/design/article.{ps,pdf} : :-J :-- :Jeroen C. van

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-06 Thread Justin T. Gibbs
:stuff to change from their current model. I also think that just as it :is too early to optimize to light weight ithread switches (sparc64 is :going to optimize all kthread switches, not just ithreads by using a more :general We have very different development models, and different

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-06 Thread Matthew Dillon
:This same issue came up at the BSDCon developers conference in :regard to ithreads. Is it better to optimize some bit of code :because it is the fun and interesting thing to do, or to build a simple, :yet stable and easily verified foundation, that we can later optimize :in a controlled

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-06 Thread Matthew Dillon
:My 2 cents? Work with John to get the APIs that affect this particular :code stable. That means discussion and perhaps that discussion will :take some time (if this blow-up hadn't occurred the discussion :would already be over now ;-). Once the APIs are in place, commit your :code in a format

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-05 Thread John Baldwin
On 01-Mar-02 Matthew Dillon wrote: : : :On 28-Feb-02 Matthew Dillon wrote: : Not to put too fine a point on it, but, I don't see how this can : possibly justify preventing me from committing my critical_*() stuff. : You've just stated publically that your preemption stuff is

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-05 Thread Matthew Dillon
: It makes no sense whatsoever to me to be told not to commit something : due to stale code that may not be quite compatible sitting in P4 that : you can't make work in any reasonable time frame. You should stop : trying to screw over my work and instead look to your own. You

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-05 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Matthew Dillon wri tes: That's the crux of the situation, John. I do not believe you have the right to hold this work off, at least not based on any of the explanations you have given so far. Why don't you for a change, just stop being so ego-centered

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-05 Thread Bosko Milekic
On Tue, Mar 05, 2002 at 06:30:08PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Matthew Dillon wri tes: That's the crux of the situation, John. I do not believe you have the right to hold this work off, at least not based on any of the explanations you have

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-01 Thread Terry Lambert
Matthew Dillon wrote: My patches have been tested, they work, and they ARE going to be committed as soon as I am able to do so. Tut, tut, looks like rain! -- Winnie the Pooh; A. A. Milne If you guys spent as much energy documenting your designs as you

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-03-01 Thread Julian Elischer
On Fri, 1 Mar 2002, Terry Lambert wrote: I think the right thing to do is to commit the cred changes, and stabilize them, if there's even a problem, as you expect from your comments about dangerous. John already committed a majority of all the cred changes. I never saw a commit message

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-28 Thread John Baldwin
On 26-Feb-02 Julian Elischer wrote: On Tue, 26 Feb 2002, John Baldwin wrote: My suggestion will be to back it out. I would rather not have to make said suggestion. Can you please try to fit this into the existing framework rather than ripping it all up? We need to finalize and test

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-28 Thread Julian Elischer
yes but thete are subcommits that you could go ahead with... the td_ucred stuff could have been checked in directly into -current. On Thu, 28 Feb 2002, John Baldwin wrote: On 26-Feb-02 Julian Elischer wrote: On Tue, 26 Feb 2002, John Baldwin wrote: My suggestion will be to back

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-28 Thread Matthew Dillon
Not to put too fine a point on it, but, I don't see how this can possibly justify preventing me from committing my critical_*() stuff. You've just stated publically that your preemption stuff is unusable as it currently stands. Why am I supposed to wait an arbitrary period of

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-28 Thread John Baldwin
On 28-Feb-02 Matthew Dillon wrote: Not to put too fine a point on it, but, I don't see how this can possibly justify preventing me from committing my critical_*() stuff. You've just stated publically that your preemption stuff is unusable as it currently stands. Why am I

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-28 Thread Matthew Dillon
: : :On 28-Feb-02 Matthew Dillon wrote: : Not to put too fine a point on it, but, I don't see how this can : possibly justify preventing me from committing my critical_*() stuff. : You've just stated publically that your preemption stuff is unusable : as it currently stands. Why

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-28 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Matthew Dillon wri tes: :Because the critical_* changes you are doing don't match up to the overall :design. See my mail to -arch for more on that though. At some point in the :future I think that this work can fit in rather well to the cpu_critical_foo :stuff

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-28 Thread Matthew Dillon
: :I strongly disagree. I have yet to see any technical description of :this so-called overall design that shows any incompatibility, and what :I decide to do with my time is my business. : :Matt, : :That particular protest is rather hollow, considering that you were :one of the

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-28 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Matthew Dillon wri tes: : :I strongly disagree. I have yet to see any technical description of :this so-called overall design that shows any incompatibility, and what :I decide to do with my time is my business. : :Matt, : :That particular protest is

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-28 Thread David Greenman
:John has been consistently chugging along on the job all the way. :At this point in time, until he is officially unseated John is our :designated SMPng architect and his word is pretty final. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 Oooh... so you mean that since I was

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-26 Thread John Baldwin
On 26-Feb-02 Matthew Dillon wrote: :1) I had an ugly panic testing it on the alpha. After a good deal of :sleuthing, : I've determined that we still have some preemption related bugs in : possibly : the alpha pmap, but that td_ucred isn't the problem. :2) I've been thinking about the

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-26 Thread John Baldwin
On 26-Feb-02 Bruce Evans wrote: On Tue, 26 Feb 2002, John Baldwin wrote: The critical section stuff currently in current is part of the original preemption patches I wrote at Usenix last year. They aren't in the tree because they aren't stable yet. We still have problems on the alpha and

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-26 Thread Matthew Dillon
:.. : cpu_critical_enter() to a null version to prevent spinlocks masking : interrupts doesn't work very well because it is used for other things : that really do need to mask interrupts. Having 2 levels for : cpu_critical_enter() (on that masks normal interrupts and one that : masks fast

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-26 Thread Julian Elischer
On Tue, 26 Feb 2002, John Baldwin wrote: My suggestion will be to back it out. I would rather not have to make said suggestion. Can you please try to fit this into the existing framework rather than ripping it all up? We need to finalize and test the design before we hardcode too many

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-25 Thread John Baldwin
On 26-Feb-02 Peter Wemm wrote: Matthew Dillon wrote: : :On Mon, 25 Feb 2002, Matthew Dillon wrote: : : Unless an unforseen problem arises, I am going to commit this : tomorrow : and then start working on a cleanup patch. I have decided to : :Please wait for jhb's opinion

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-25 Thread John Baldwin
On 26-Feb-02 Matthew Dillon wrote: : :On Mon, 25 Feb 2002, Matthew Dillon wrote: : : Unless an unforseen problem arises, I am going to commit this tomorrow : and then start working on a cleanup patch. I have decided to : :Please wait for jhb's opinion on it. He seems to be offline

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-25 Thread Matthew Dillon
:1) I had an ugly panic testing it on the alpha. After a good deal of sleuthing, : I've determined that we still have some preemption related bugs in possibly : the alpha pmap, but that td_ucred isn't the problem. :2) I've been thinking about the Giant instrumentation a bit. I figured out

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-25 Thread Bruce Evans
On Tue, 26 Feb 2002, John Baldwin wrote: The critical section stuff currently in current is part of the original preemption patches I wrote at Usenix last year. They aren't in the tree because they aren't stable yet. We still have problems on the alpha and problems with IPI deadlocks on

Re: Patch for critical_enter()/critical_exit() interrupt assem

2002-02-25 Thread Matthew Dillon
: The critical section stuff currently in current is part of the original : preemption patches I wrote at Usenix last year. They aren't in the tree : because they aren't stable yet. We still have problems on the alpha and : problems with IPI deadlocks on SMP machines that need to be worked