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 w
: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 wi
On Wed, 6 Mar 2002, Seth Hettich wrote:
> I have both:
> options SMBFS
> options NETSMB
>
>
> in my config.
>
> Perhaps someone could give a little explanation, and add it to NOTES?
Thanks for pointing to it. For some reason LINT from -stable have
this explanation and
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 ju
Garance A Drosihn <[EMAIL PROTECTED]> writes:
> At 9:25 PM +0300 3/7/02, Andrey A. Chernov wrote:
> > fix is incomplete because 'u_int32_t' is not defined
> >(but must be) for standalone . Please add some includes
> >for u_int32_t definition too, probably
Perhaps subconsciously I was trying to k
: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 u
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
On Thursday, 7 March 2002 at 16:43:40 -0800, David Greenman wrote:
>> On Thursday, 7 March 2002 at 13:19:05 -0800, Julian Elischer wrote:
>>>
>>>
>>> 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
>On Thursday, 7 March 2002 at 13:19:05 -0800, Julian Elischer wrote:
>>
>>
>> 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 defi
On Thursday, 7 March 2002 at 13:19:05 -0800, Julian Elischer wrote:
>
>
> 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 *N
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
>>
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 fa
I have an updated copy of my kernel memory allocator available for general
testing. If you aren't familiar with this allocator you may want to look
at the arch@ archives under "Slab allocator".
This patch has been tested on SMP alpha and single proc x86. It depends
on recent current changes, so
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
: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
: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 critical_
At 5:43 PM +0200 3/7/02, Maxim Sobolev wrote:
>"Michael D. Harnois" wrote:
> > Could this have anything to do with the fact that, since I built
> > world yesterday, I can't log in as root?
>
>Bah, just completed `make world' after doing `make includes' and
>found that I can't login as *any* user
:: 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 wi
At 9:25 PM +0300 3/7/02, Andrey A. Chernov wrote:
> fix is incomplete because 'u_int32_t' is not defined
>(but must be) for standalone . Please add some includes
>for u_int32_t definition too, probably
As a minor side question, should we also have that defined as
uint32_t instead of u_int32_t ?
: 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 answe
:
: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
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
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:
>: http://www.FreeBSD.org/~jhb/smpng/design/art
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 wr
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
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
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
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 (
>
>
>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 colabora
>
>:
>: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, t
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
> >
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 tec
>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 t
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 work
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 suppor
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
:
: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
>: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
fix is incomplete because 'u_int32_t' is not defined (but must be)
for standalone . Please add some includes for u_int32_t definition
too, probably
To see it, try to compile following program:
#include
main ()
{}
and get:
/usr/include/grp.h:53: syntax error before `gid_t'
/usr/include/grp.
:>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 mo
> Mark Murray <[EMAIL PROTECTED]> writes:
> > > Umm, IIRC 'make world' starts by doing a 'make includes' into
> > > /usr/obj, which should take care of this.
> > That is 'make world'. It was broken for "make obj && make depend && make",
> > [...]
> > IMO, the repo-copy is the cleanest, because it
> > That is _my_ fault, not DES'. It was a crypt() problem which I have fixed.
>
> Ok, I see now. Could we please make a rule to send a heads-up in such
> cases (i.e. in the cases when some serious misbehaviour was introduced
> and then fixed shortly). This would save me (and probably others)
> r
Mark Murray <[EMAIL PROTECTED]> writes:
> > Umm, IIRC 'make world' starts by doing a 'make includes' into
> > /usr/obj, which should take care of this.
> That is 'make world'. It was broken for "make obj && make depend && make",
> [...]
> IMO, the repo-copy is the cleanest, because it solves te ab
Dag-Erling Smorgrav wrote:
>
> Maxim Sobolev <[EMAIL PROTECTED]> writes:
> > Bah, just completed `make world' after doing `make includes' and found
> > that I can't login as *any* user, not only root!!! Login just
> > hangs after entering password and nothing goes on. DES! PLEASE FIX
> > THAT
> Mark Murray <[EMAIL PROTECTED]> writes:
> > The problem is in the headers; you changed #include "pam_mod_misc.h"
> > to #include without ensuring that a (correct)
> > pam_mod_misc.h was in an appropriate secure/ dir.
>
> Umm, IIRC 'make world' starts by doing a 'make includes' into
> /usr/obj,
Mark Murray wrote:
>
> > Bah, just completed `make world' after doing `make includes' and found
> > that I can't login as *any* user, not only root!!! Login just
> > hangs after entering password and nothing goes on. DES! PLEASE FIX
> > THAT FSKING PAM - within a very short timeframe it's the
Maxim Sobolev <[EMAIL PROTECTED]> writes:
> Shit Happens[tm]. BTW, why you are ignoring system CFLAGS settings
> (optimisations and such) for pam_unix? Please consider attached patch.
*I* am not. Learn how to use 'cvs annotate'
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: se
Dag-Erling Smorgrav wrote:
>
> Maxim Sobolev <[EMAIL PROTECTED]> writes:
> > Dag-Erling Smorgrav wrote:
> > > Maxim Sobolev <[EMAIL PROTECTED]> writes:
> > > > Looks like source upgrade path is broken due to PAM. My system is -CURRENT
> > > > compiled on 19 February. Please fix.
> > > Please use
Maxim Sobolev <[EMAIL PROTECTED]> writes:
> Bah, just completed `make world' after doing `make includes' and found
> that I can't login as *any* user, not only root!!! Login just
> hangs after entering password and nothing goes on. DES! PLEASE FIX
> THAT FSKING PAM - within a very short timefr
Mark Murray <[EMAIL PROTECTED]> writes:
> The problem is in the headers; you changed #include "pam_mod_misc.h"
> to #include without ensuring that a (correct)
> pam_mod_misc.h was in an appropriate secure/ dir.
Umm, IIRC 'make world' starts by doing a 'make includes' into
/usr/obj, which should
> OK; markm said it was a crypt() problem (that he caused & fixed); I'm
> not going to belabor that. (I will, however, express appreciation for
> Mark "taking the heat": thanks, Mark!)
*blush*
> But on the point of folks being unable to login, I'm not seeing the
> failure here.
You'll only se
Maxim Sobolev <[EMAIL PROTECTED]> writes:
> Dag-Erling Smorgrav wrote:
> > Maxim Sobolev <[EMAIL PROTECTED]> writes:
> > > Looks like source upgrade path is broken due to PAM. My system is -CURRENT
> > > compiled on 19 February. Please fix.
> > Please use 'make world' to upgrade your system.
> I'm
>Date: Thu, 07 Mar 2002 17:43:26 +0200
>From: Maxim Sobolev <[EMAIL PROTECTED]>
>"Michael D. Harnois" wrote:
>> On Thu, 7 Mar 2002 13:30:44 +0200 (EET), Maxim Sobolev <[EMAIL PROTECTED]> said:
>> Maxim> Hi, Looks like source upgrade path is broken due to PAM. My
>> Maxim> system is -CUR
In message: <[EMAIL PROTECTED]>
Yuri Khotyaintsev <[EMAIL PROTECTED]> writes:
: Hi!
:
: I have xl0: watchdog timeout on my 3Com cardbus card after updating kernel
: recently. Everything seems to be OK during boot,
: but xl0: watchdog timeout starts directly after ifconfig, and makes
> I can't login as root either, I can only gain root access if I boot into
> single-user.
>
> The login process just eats up all cpu-ressources and the login times out
> after 300 seconds. A su doesn't work either, of course.
Not a PAM problem, a crypt(3) problem. My fault, and fixed.
M
--
o
> Bah, just completed `make world' after doing `make includes' and found
> that I can't login as *any* user, not only root!!! Login just
> hangs after entering password and nothing goes on. DES! PLEASE FIX
> THAT FSKING PAM - within a very short timeframe it's the second time
> I'm having prob
> Maxim Sobolev <[EMAIL PROTECTED]> writes:
> > Looks like source upgrade path is broken due to PAM. My system is -CURRENT
> > compiled on 19 February. Please fix.
>
> Please use 'make world' to upgrade your system.
Its more broken than that. I have a fix.
The problem is in the headers; you cha
On 7 Mar 2002, Michael D. Harnois wrote:
> On Thu, 7 Mar 2002 13:30:44 +0200 (EET), Maxim Sobolev <[EMAIL PROTECTED]> said:
>
> Maxim> Hi, Looks like source upgrade path is broken due to PAM. My
> Maxim> system is -CURRENT compiled on 19 February. Please fix.
>
> Could this have anything
"Michael D. Harnois" wrote:
>
> On Thu, 7 Mar 2002 13:30:44 +0200 (EET), Maxim Sobolev <[EMAIL PROTECTED]> said:
>
> Maxim> Hi, Looks like source upgrade path is broken due to PAM. My
> Maxim> system is -CURRENT compiled on 19 February. Please fix.
>
> Could this have anything to do wit
>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 impo
On Thu, 7 Mar 2002 13:30:44 +0200 (EET), Maxim Sobolev <[EMAIL PROTECTED]> said:
Maxim> Hi, Looks like source upgrade path is broken due to PAM. My
Maxim> system is -CURRENT compiled on 19 February. Please fix.
Could this have anything to do with the fact that, since I built world
yester
Maxim Sobolev wrote:
>
> Dag-Erling Smorgrav wrote:
> >
> > Maxim Sobolev <[EMAIL PROTECTED]> writes:
> > > Looks like source upgrade path is broken due to PAM. My system is -CURRENT
> > > compiled on 19 February. Please fix.
> >
> > Please use 'make world' to upgrade your system.
>
> I'm using
Dag-Erling Smorgrav wrote:
>
> Maxim Sobolev <[EMAIL PROTECTED]> writes:
> > Looks like source upgrade path is broken due to PAM. My system is -CURRENT
> > compiled on 19 February. Please fix.
>
> Please use 'make world' to upgrade your system.
I'm using `make world' (well buildworld, but it sh
Maxim Sobolev <[EMAIL PROTECTED]> writes:
> Looks like source upgrade path is broken due to PAM. My system is -CURRENT
> compiled on 19 February. Please fix.
Please use 'make world' to upgrade your system.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTE
Hi,
Looks like source upgrade path is broken due to PAM. My system is -CURRENT
compiled on 19 February. Please fix.
-Maxim
===> libpam/modules/pam_ftp
cc -pipe -O -mpreferred-stack-boundary=2 -march=pentium -I/usr/src/lib/libpam/mo
dules/pam_ftp/../../../../contrib/openpam/libpam/include -I/usr
I mentioned something similar for a different reason. Go look at the last
part of the following message in the recent -hackers archives:
> Subject: ptrace bug?
> MessageId: <[EMAIL PROTECTED]>
(this was for -stable, BTW)
Having the suspend for the ptrace()ing parent done in issignal is a pain
> This comment is false. On my -CURRENT system with
> this commit in place 'passwd' and 'login'/'su' commands
> loops forever computing MD5 password.
>
> After reverting crypt-md5.c to rev. 1.8 all thouse
> commands work as always.
It was a signed/unsiged issue. Fixed!
M
--
o
Just a quick note to let people know that the 3ware driver twe(4) driver
has been updated to deal with 3ware's latest firmware releases.
These changes have been tested for a couple of weeks now.
One other important note for owners of 7xxx series controllers; the 7.4
firmware update is due out
Hi!
I have xl0: watchdog timeout on my 3Com cardbus card after updating kernel
recently. Everything seems to be OK during boot,
but xl0: watchdog timeout starts directly after ifconfig, and makes network
incredibly slow.
boot -v will not boot at all, it stops somewhere around cardbus_attach_ca
In article <[EMAIL PROTECTED]>
Mark Murray <[EMAIL PROTECTED]> wrote:
> markm 2002/03/06 09:18:09 PST
>
> Modified files:
>lib/libcrypt crypt-md5.c crypt.c crypt.h misc.c
>secure/lib/libcrypt blowfish.c blowfish.h crypt-blowfish.c
> crypt-des.c
>
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.
In message: <[EMAIL PROTECTED]>
FUJITA Kazutoshi <[EMAIL PROTECTED]> writes:
: Hi there,
:
: I installed -CURRENT on my old PC(ThinkPad235 aka Chandra2),
: but its USB device doesn't work.
: (it works on Windows environment)
:
: [boot message]
: ohci0: irq 10 at device 5.0 on pci0
:
Hi there,
I installed -CURRENT on my old PC(ThinkPad235 aka Chandra2),
but its USB device doesn't work.
(it works on Windows environment)
[boot message]
ohci0: irq 10 at device 5.0 on pci0
ohci0: Could not map memory
device_probe_and_attach: ohci0 attach returned 6
in source code, sys/pci/ohc
73 matches
Mail list logo
