Re: old style kernel configuration

[Jeremie Le Hen]

Hi!

On Thu, Nov 22, 2012 at 05:38:58PM +0100, Mateusz Guzik wrote:
> 
> # make buildkernel ... KERNFAST=1

Is it documented somewhere?  I was using NO_CLEAN=1.

-- 
Jeremie Le Hen

Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: old style kernel configuration

[Mateusz Guzik]

On Sun, Nov 25, 2012 at 11:28:48AM +0100, Jeremie Le Hen wrote:
> Hi!
> 
> On Thu, Nov 22, 2012 at 05:38:58PM +0100, Mateusz Guzik wrote:
> > 
> > # make buildkernel ... KERNFAST=1
> 
> Is it documented somewhere?  I was using NO_CLEAN=1.
> 

Yep, build(7).

-- 
Mateusz Guzik 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: stop_cpus_hard when multiple CPUs are panicking from an NMI

[Attilio Rao]

On Fri, Nov 16, 2012 at 2:47 PM, Andriy Gapon  wrote:
> on 16/11/2012 16:41 Attilio Rao said the following:
>> On Fri, Nov 16, 2012 at 1:18 PM, Andriy Gapon  wrote:
>>> on 16/11/2012 14:30 Attilio Rao said the following:
 On Fri, Nov 16, 2012 at 7:54 AM, Andriy Gapon  wrote:
> on 16/11/2012 00:58 Ryan Stone said the following:
>> At work we have some custom watchdog hardware that sends an NMI upon
>> expiry.  We've modified the kernel to panic when it receives the watchdog
>> NMI.  I've been trying the "stop_scheduler_on_panic" mode, and I've
>> discovered that when my watchdog expires, the system gets completely
>> wedged.  After some digging, I've discovered is that I have multiple CPUs
>> getting the watchdog NMI and trying to panic concurrently.  One of the 
>> CPUs
>> wins, and the rest spin forever in this code:
>>
>> /*
>>  * We don't want multiple CPU's to panic at the same time, so we
>>  * use panic_cpu as a simple spinlock.  We have to keep checking
>>  * panic_cpu if we are spinning in case the panic on the first
>>  * CPU is canceled.
>>  */
>> if (panic_cpu != PCPU_GET(cpuid))
>> while (atomic_cmpset_int(&panic_cpu, NOCPU,
>> PCPU_GET(cpuid)) == 0)
>> while (panic_cpu != NOCPU)
>> ; /* nothing */
>>
>> The system wedges when stop_cpus_hard() is called, which sends NMIs to 
>> all
>> of the other CPUs and waits for them to acknowledge that they are stopped
>> before returning.  However the CPU will not deliver an NMI to a CPU that 
>> is
>> already handling an NMI, so the other CPUs that got a watchdog NMI and 
>> are
>> spinning will never go into the NMI handler and acknowledge that they are
>> stopped.
>
> I thought about this issue and fixed (in my tree) in a different way:
> http://people.freebsd.org/~avg/cpu_stop-race.diff
>
> The need for spinlock_enter in the patch in not entirely clear.
> The main idea is that a CPU which calls cpu_stop and loses a race should
> voluntary enter cpustop_handler.
> I am also not sure about MI-cleanness of this patch.

 It is similar to what I propose but with some differences:
 - It is not clean from MI perspective
>>>
>>> OK.
>>>
 - I don't think we need to treact it specially, I would just
 unconditionally stop all the CPUs entering in the "spinlock zone",
 making the patch simpler.
>>>
>>> I couldn't understand this part.
>>
>> I'm sorry, I think I misread your patch.
>>
>> I was basically suggesting to fix Ryan case by calling
>> cpustop_handler() (or the new MI interface) into the panic() function,
>> in the case the CPU don't win the race for panic_cpu.
>> Basically doing:
>> Index: sys/kern/kern_shutdown.c
>> ===
>> --- sys/kern/kern_shutdown.c(revision 243154)
>> +++ sys/kern/kern_shutdown.c(working copy)
>> @@ -568,15 +568,11 @@ panic(const char *fmt, ...)
>>  #ifdef SMP
>> /*
>>  * We don't want multiple CPU's to panic at the same time, so we
>> -* use panic_cpu as a simple spinlock.  We have to keep checking
>> -* panic_cpu if we are spinning in case the panic on the first
>> -* CPU is canceled.
>> +* use panic_cpu as a simple lock.
>>  */
>> if (panic_cpu != PCPU_GET(cpuid))
>> -   while (atomic_cmpset_int(&panic_cpu, NOCPU,
>> -   PCPU_GET(cpuid)) == 0)
>> -   while (panic_cpu != NOCPU)
>> -   ; /* nothing */
>> +   if (atomic_cmpset_int(&panic_cpu, NOCPU, PCPU_GET(cpuid)) == 
>> 0)
>> +   cpustop_handler();
>>
>> if (stop_scheduler_on_panic) {
>> if (panicstr == NULL && !kdb_active) {
>>
>>
>> Infact it seems to me that the comment is outdated and no longer
>> represent truth.
>
> Ah, I see.  Thank you.
>
> My older plan was to get rid of stop_scheduler_on_panic, that is to make the
> behavior unconditional.  And then to use stop_cpus_hard instead of the 
> hand-rolled
> 'panic_cpu' spinlock.  This way the whichever CPU wins stop_cpus_hard would 
> be the
> only CPU to enter panic.

So, assuming we are not yet defaulting to stop cpus behaviour for
panic, I think we have 2 things to take care:
1) Handling the simultaneous panics
2) Handling deadlocks/starvation among simultaneous cpu_stops

In particular, case 2 is more tricky than it seems, it is not only
related to NMI but also to the case where you send an IPI_STOP via a
normal IPI and interrupts are disabled on one of the channels. Infact,
I think the patch you propose makes such effects even worse, because
it disables interrupts in generic_stop_cpus().
What I suggest to do, is the following:
- The CPU which wins the race for generic_stop_cpus also signals the
CPUs it is w

Re: stop_cpus_hard when multiple CPUs are panicking from an NMI

[Attilio Rao]

On Sun, Nov 25, 2012 at 12:29 PM, Attilio Rao  wrote:
> On Fri, Nov 16, 2012 at 2:47 PM, Andriy Gapon  wrote:
>> on 16/11/2012 16:41 Attilio Rao said the following:
>>> On Fri, Nov 16, 2012 at 1:18 PM, Andriy Gapon  wrote:
 on 16/11/2012 14:30 Attilio Rao said the following:
> On Fri, Nov 16, 2012 at 7:54 AM, Andriy Gapon  wrote:
>> on 16/11/2012 00:58 Ryan Stone said the following:
>>> At work we have some custom watchdog hardware that sends an NMI upon
>>> expiry.  We've modified the kernel to panic when it receives the 
>>> watchdog
>>> NMI.  I've been trying the "stop_scheduler_on_panic" mode, and I've
>>> discovered that when my watchdog expires, the system gets completely
>>> wedged.  After some digging, I've discovered is that I have multiple 
>>> CPUs
>>> getting the watchdog NMI and trying to panic concurrently.  One of the 
>>> CPUs
>>> wins, and the rest spin forever in this code:
>>>
>>> /*
>>>  * We don't want multiple CPU's to panic at the same time, so we
>>>  * use panic_cpu as a simple spinlock.  We have to keep checking
>>>  * panic_cpu if we are spinning in case the panic on the first
>>>  * CPU is canceled.
>>>  */
>>> if (panic_cpu != PCPU_GET(cpuid))
>>> while (atomic_cmpset_int(&panic_cpu, NOCPU,
>>> PCPU_GET(cpuid)) == 0)
>>> while (panic_cpu != NOCPU)
>>> ; /* nothing */
>>>
>>> The system wedges when stop_cpus_hard() is called, which sends NMIs to 
>>> all
>>> of the other CPUs and waits for them to acknowledge that they are 
>>> stopped
>>> before returning.  However the CPU will not deliver an NMI to a CPU 
>>> that is
>>> already handling an NMI, so the other CPUs that got a watchdog NMI and 
>>> are
>>> spinning will never go into the NMI handler and acknowledge that they 
>>> are
>>> stopped.
>>
>> I thought about this issue and fixed (in my tree) in a different way:
>> http://people.freebsd.org/~avg/cpu_stop-race.diff
>>
>> The need for spinlock_enter in the patch in not entirely clear.
>> The main idea is that a CPU which calls cpu_stop and loses a race should
>> voluntary enter cpustop_handler.
>> I am also not sure about MI-cleanness of this patch.
>
> It is similar to what I propose but with some differences:
> - It is not clean from MI perspective

 OK.

> - I don't think we need to treact it specially, I would just
> unconditionally stop all the CPUs entering in the "spinlock zone",
> making the patch simpler.

 I couldn't understand this part.
>>>
>>> I'm sorry, I think I misread your patch.
>>>
>>> I was basically suggesting to fix Ryan case by calling
>>> cpustop_handler() (or the new MI interface) into the panic() function,
>>> in the case the CPU don't win the race for panic_cpu.
>>> Basically doing:
>>> Index: sys/kern/kern_shutdown.c
>>> ===
>>> --- sys/kern/kern_shutdown.c(revision 243154)
>>> +++ sys/kern/kern_shutdown.c(working copy)
>>> @@ -568,15 +568,11 @@ panic(const char *fmt, ...)
>>>  #ifdef SMP
>>> /*
>>>  * We don't want multiple CPU's to panic at the same time, so we
>>> -* use panic_cpu as a simple spinlock.  We have to keep checking
>>> -* panic_cpu if we are spinning in case the panic on the first
>>> -* CPU is canceled.
>>> +* use panic_cpu as a simple lock.
>>>  */
>>> if (panic_cpu != PCPU_GET(cpuid))
>>> -   while (atomic_cmpset_int(&panic_cpu, NOCPU,
>>> -   PCPU_GET(cpuid)) == 0)
>>> -   while (panic_cpu != NOCPU)
>>> -   ; /* nothing */
>>> +   if (atomic_cmpset_int(&panic_cpu, NOCPU, PCPU_GET(cpuid)) 
>>> == 0)
>>> +   cpustop_handler();
>>>
>>> if (stop_scheduler_on_panic) {
>>> if (panicstr == NULL && !kdb_active) {
>>>
>>>
>>> Infact it seems to me that the comment is outdated and no longer
>>> represent truth.
>>
>> Ah, I see.  Thank you.
>>
>> My older plan was to get rid of stop_scheduler_on_panic, that is to make the
>> behavior unconditional.  And then to use stop_cpus_hard instead of the 
>> hand-rolled
>> 'panic_cpu' spinlock.  This way the whichever CPU wins stop_cpus_hard would 
>> be the
>> only CPU to enter panic.
>
> So, assuming we are not yet defaulting to stop cpus behaviour for
> panic, I think we have 2 things to take care:
> 1) Handling the simultaneous panics
> 2) Handling deadlocks/starvation among simultaneous cpu_stops
>
> In particular, case 2 is more tricky than it seems, it is not only
> related to NMI but also to the case where you send an IPI_STOP via a
> normal IPI and interrupts are disabled on one of the channels. Infact,
> I think the patch you propose

Re: [RFQ] make witness panic an option

[Pawel Jakub Dawidek]

On Thu, Nov 15, 2012 at 04:39:55PM +, Attilio Rao wrote:
> On 11/15/12, Adrian Chadd  wrote:
> > On 15 November 2012 05:27, Giovanni Trematerra
> >  wrote:
> >
> >> I really do think that is a very bad idea.
> >> When a locking assertion fails you have just to stop your mind and
> >> think what's wrong,
> >> no way to postpone on this.
> >
> > Not all witness panics are actually fatal. For a developer who is
> > sufficiently cluey in their area, they are quite likely able to just
> > stare at the code paths for a while to figure out why the
> > incorrectness occured.
> 
> The problem is that such mechanism can be abused, just like the
> BLESSING one and that's why this is disabled by default.

WITNESS is a development tool. We don't ship production kernels with
WITNESS even compiled in. What is more efficient use of developer time:
going through full reboot cycle every time or reading the warning from
console, unloading a module, fixing the bug and loading it again?

And if this option is turned off by default what is the problem?

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl


pgpqNuuWS6QFO.pgp
Description: PGP signature

Re: [RFQ] make witness panic an option

[Attilio Rao]

On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek  wrote:
> On Thu, Nov 15, 2012 at 04:39:55PM +, Attilio Rao wrote:
>> On 11/15/12, Adrian Chadd  wrote:
>> > On 15 November 2012 05:27, Giovanni Trematerra
>> >  wrote:
>> >
>> >> I really do think that is a very bad idea.
>> >> When a locking assertion fails you have just to stop your mind and
>> >> think what's wrong,
>> >> no way to postpone on this.
>> >
>> > Not all witness panics are actually fatal. For a developer who is
>> > sufficiently cluey in their area, they are quite likely able to just
>> > stare at the code paths for a while to figure out why the
>> > incorrectness occured.
>>
>> The problem is that such mechanism can be abused, just like the
>> BLESSING one and that's why this is disabled by default.
>
> WITNESS is a development tool. We don't ship production kernels with
> WITNESS even compiled in. What is more efficient use of developer time:
> going through full reboot cycle every time or reading the warning from
> console, unloading a module, fixing the bug and loading it again?
>
> And if this option is turned off by default what is the problem?

Yes, so, why do you write here?
Go ahead and fix BLESSED, make it the default, etc.

I have enough of your (not referred to you particulary but to the
people which contributed to this and other thread) to not be able to
respect others opinion.
As I said I cannot forbid you guys from doing anything, just go ahead,
write the code and commit it, albeit completely bypassing other
people's opinion.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: stop_cpus_hard when multiple CPUs are panicking from an NMI

[Andriy Gapon]

on 25/11/2012 14:29 Attilio Rao said the following:
> I think the patch you propose makes such effects even worse, because
> it disables interrupts in generic_stop_cpus().
> What I suggest to do, is the following:
> - The CPU which wins the race for generic_stop_cpus also signals the
> CPUs it is willing to stop on a global mask
> - Another CPU entering generic_stop_cpus() and loosing the race,
> checks the mask of cpus which might be stopped and stops itself if
> necessary (ie. not yet done). We must be careful with races here, but
> I'm confindent this can be done easily enough.

I think that you either misunderstood my patch or I misunderstand your
suggestion, because my patch does exactly what you wrote above.

-- 
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RFQ] make witness panic an option

[Pawel Jakub Dawidek]

On Sun, Nov 25, 2012 at 12:42:16PM +, Attilio Rao wrote:
> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek  
> wrote:
> > WITNESS is a development tool. We don't ship production kernels with
> > WITNESS even compiled in. What is more efficient use of developer time:
> > going through full reboot cycle every time or reading the warning from
> > console, unloading a module, fixing the bug and loading it again?
> >
> > And if this option is turned off by default what is the problem?
> 
> Yes, so, why do you write here?

I'm trying to understand why do you object. Until now the only concern
you have that I found is that you are afraid of it being abused. I don't
see how this can be abused if it is turned off by default. If someone
will commit a change that will turn it on by default, believe me, I'll
unleash hell personally.

As I said, WITNESS is development tool, a very handy one. This doesn't
mean we can't make it even more handy. It is there to help find bugs
faster, right? Adrian is proposing a change that will make it help to
find and fix bugs maybe even faster.

> Go ahead and fix BLESSED, make it the default, etc.

This is another story, but BLESSED is much less controversial to me.
It is turned off by default in assumption that all the code that runs in
our kernel is developed for FreeBSD, which is not true. For example ZFS
is, I think, the biggest locking consumer in our kernel (around 120
locks), which wasn't originally developed for FreeBSD and locking order
was verified using different tools. Now on FreeBSD it triggers massive
LOR warnings from WITNESS, eventhough those are not bugs. At some point
I verified many of them and they were all false-positives, so I simply
turned off WITNESS warnings for ZFS locks. Why? Because BLESSED is
turned off in fear of abuse, and this is turn is the cause of mentioned
hack in ZFS.

> I have enough of your (not referred to you particulary but to the
> people which contributed to this and other thread) to not be able to
> respect others opinion.
> As I said I cannot forbid you guys from doing anything, just go ahead,
> write the code and commit it, albeit completely bypassing other
> people's opinion.

I'm sorry, I wasn't aware that your opinions are set in stone. I hoped
that with some new arguments you may want to reconsider:)

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl


pgpnNWcx8GwNH.pgp
Description: PGP signature

Re: [RFQ] make witness panic an option

[Attilio Rao]

On Sun, Nov 25, 2012 at 1:12 PM, Pawel Jakub Dawidek  wrote:
> On Sun, Nov 25, 2012 at 12:42:16PM +, Attilio Rao wrote:
>> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek  
>> wrote:
>> > WITNESS is a development tool. We don't ship production kernels with
>> > WITNESS even compiled in. What is more efficient use of developer time:
>> > going through full reboot cycle every time or reading the warning from
>> > console, unloading a module, fixing the bug and loading it again?
>> >
>> > And if this option is turned off by default what is the problem?
>>
>> Yes, so, why do you write here?
>
> I'm trying to understand why do you object. Until now the only concern
> you have that I found is that you are afraid of it being abused. I don't
> see how this can be abused if it is turned off by default. If someone
> will commit a change that will turn it on by default, believe me, I'll
> unleash hell personally.

So I don't understand what are you proposing.
You are not proposing to switch BLESSING on and you are not proposing
to import Adrian's patches in, if I get it correctly. I don't
understand then.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RFQ] make witness panic an option

[Pawel Jakub Dawidek]

On Sun, Nov 25, 2012 at 01:37:19PM +, Attilio Rao wrote:
> On Sun, Nov 25, 2012 at 1:12 PM, Pawel Jakub Dawidek  wrote:
> > On Sun, Nov 25, 2012 at 12:42:16PM +, Attilio Rao wrote:
> >> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek  
> >> wrote:
> >> > WITNESS is a development tool. We don't ship production kernels with
> >> > WITNESS even compiled in. What is more efficient use of developer time:
> >> > going through full reboot cycle every time or reading the warning from
> >> > console, unloading a module, fixing the bug and loading it again?
> >> >
> >> > And if this option is turned off by default what is the problem?
> >>
> >> Yes, so, why do you write here?
> >
> > I'm trying to understand why do you object. Until now the only concern
> > you have that I found is that you are afraid of it being abused. I don't
> > see how this can be abused if it is turned off by default. If someone
> > will commit a change that will turn it on by default, believe me, I'll
> > unleash hell personally.
> 
> So I don't understand what are you proposing.
> You are not proposing to switch BLESSING on and you are not proposing
> to import Adrian's patches in, if I get it correctly. I don't
> understand then.

I propose to get Adrian's patches in, just leave current behaviour as
the default.

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl


pgprDLu11pa5N.pgp
Description: PGP signature

Re: [RFQ] make witness panic an option

[Attilio Rao]

On Sun, Nov 25, 2012 at 1:47 PM, Pawel Jakub Dawidek  wrote:
> On Sun, Nov 25, 2012 at 01:37:19PM +, Attilio Rao wrote:
>> On Sun, Nov 25, 2012 at 1:12 PM, Pawel Jakub Dawidek  
>> wrote:
>> > On Sun, Nov 25, 2012 at 12:42:16PM +, Attilio Rao wrote:
>> >> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek  
>> >> wrote:
>> >> > WITNESS is a development tool. We don't ship production kernels with
>> >> > WITNESS even compiled in. What is more efficient use of developer time:
>> >> > going through full reboot cycle every time or reading the warning from
>> >> > console, unloading a module, fixing the bug and loading it again?
>> >> >
>> >> > And if this option is turned off by default what is the problem?
>> >>
>> >> Yes, so, why do you write here?
>> >
>> > I'm trying to understand why do you object. Until now the only concern
>> > you have that I found is that you are afraid of it being abused. I don't
>> > see how this can be abused if it is turned off by default. If someone
>> > will commit a change that will turn it on by default, believe me, I'll
>> > unleash hell personally.
>>
>> So I don't understand what are you proposing.
>> You are not proposing to switch BLESSING on and you are not proposing
>> to import Adrian's patches in, if I get it correctly. I don't
>> understand then.
>
> I propose to get Adrian's patches in, just leave current behaviour as
> the default.

So if I tell that I'm afraid this mechanism will be abused (and
believe me, I really wanted to trimm out BLESSING stuff also for the
same reason) and you say "you can't see how" there is not much we can
discuss.

You know how I think, there is no need to wait for me to reconsider,
because I don't believe this will happen with arguments like "I don't
think", "I don't agree", etc.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: old style kernel configuration

[Wojciech Puchar]

and
- what are the man differences between the old and new ways.

and it is starting to turn into a flame/bikeshed.
i just don't see what's wrong in SIMPLE procedure that just use existing C 
compiler and just sys sources






Thanks for the information. I'll restore the documentation with
updated information shortly.


--
Eitan Adler
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"


___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: stop_cpus_hard when multiple CPUs are panicking from an NMI

[Attilio Rao]

On Sun, Nov 25, 2012 at 12:55 PM, Andriy Gapon  wrote:
> on 25/11/2012 14:29 Attilio Rao said the following:
>> I think the patch you propose makes such effects even worse, because
>> it disables interrupts in generic_stop_cpus().
>> What I suggest to do, is the following:
>> - The CPU which wins the race for generic_stop_cpus also signals the
>> CPUs it is willing to stop on a global mask
>> - Another CPU entering generic_stop_cpus() and loosing the race,
>> checks the mask of cpus which might be stopped and stops itself if
>> necessary (ie. not yet done). We must be careful with races here, but
>> I'm confindent this can be done easily enough.
>
> I think that you either misunderstood my patch or I misunderstand your
> suggestion, because my patch does exactly what you wrote above.

The patch is someway incomplete:
- I don't think that we need specific checks in cpustop_handler() (and
if you have added them to prevent races, I don't think they are
enough, see below)
- setting of "stopping_cpus" map must happen atomically/before the
stopper_cpu cpuid setting, otherwise some CPUs may end up using a NULL
mask in the check
- Did you consider the races about when a stop and restart request
happen just after the CPU_ISSET() check? I think CPUs can deadlock
there.
- I'm very doubious about the spinlock_enter() stuff, I think I can
just make the problem worse atm.

However you are right, the concept of your patch is the same I really
wanted to get, we maybe need to just lift it up a bit.

In the while I also double-checked suspended_cpus and I don't think
there are real showstoppers to have it in stopped_cpus map.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RFQ] make witness panic an option

[Pawel Jakub Dawidek]

On Sun, Nov 25, 2012 at 01:48:23PM +, Attilio Rao wrote:
> On Sun, Nov 25, 2012 at 1:47 PM, Pawel Jakub Dawidek  wrote:
> > On Sun, Nov 25, 2012 at 01:37:19PM +, Attilio Rao wrote:
> >> On Sun, Nov 25, 2012 at 1:12 PM, Pawel Jakub Dawidek  
> >> wrote:
> >> > On Sun, Nov 25, 2012 at 12:42:16PM +, Attilio Rao wrote:
> >> >> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek 
> >> >>  wrote:
> >> >> > WITNESS is a development tool. We don't ship production kernels with
> >> >> > WITNESS even compiled in. What is more efficient use of developer 
> >> >> > time:
> >> >> > going through full reboot cycle every time or reading the warning from
> >> >> > console, unloading a module, fixing the bug and loading it again?
> >> >> >
> >> >> > And if this option is turned off by default what is the problem?
> >> >>
> >> >> Yes, so, why do you write here?
> >> >
> >> > I'm trying to understand why do you object. Until now the only concern
> >> > you have that I found is that you are afraid of it being abused. I don't
> >> > see how this can be abused if it is turned off by default. If someone
> >> > will commit a change that will turn it on by default, believe me, I'll
> >> > unleash hell personally.
> >>
> >> So I don't understand what are you proposing.
> >> You are not proposing to switch BLESSING on and you are not proposing
> >> to import Adrian's patches in, if I get it correctly. I don't
> >> understand then.
> >
> > I propose to get Adrian's patches in, just leave current behaviour as
> > the default.
> 
> So if I tell that I'm afraid this mechanism will be abused (and
> believe me, I really wanted to trimm out BLESSING stuff also for the
> same reason) and you say "you can't see how" there is not much we can
> discuss.

This is not what I said. I would see it as abuse if someone will
suddenly decided to turn off locking assertions by default in FreeBSD
base.

If he will turn that off on his private machine be it to speed up his
development (a good thing) or to shut up important lock assertion (a bad
thing) this is entirely his decision. He can already do that having all
the source code, its just more complex. Make tools, not policies.

BLESSING is totally different subject. You were afraid that people will
start to silence LORs they don't understand by committing blessed pairs
to FreeBSD base. And this situation is abuse and I fully agree, but I
also still think BLESSING is useful, although I recognize it might be
hard to prevent mentioned abuse.

In case of Adrian's patch nothing will change in how we enforce locking
assertions in FreeBSD base.

> You know how I think, there is no need to wait for me to reconsider,
> because I don't believe this will happen with arguments like "I don't
> think", "I don't agree", etc.

I provide valid arguments with I hope proper explanation, you choose not
to address them or ignore them and I hope this will change:)

-- 
Pawel Jakub Dawidek   http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl


pgpaSF1ixWska.pgp
Description: PGP signature

Re: [RFQ] make witness panic an option

[Attilio Rao]

On Sun, Nov 25, 2012 at 2:06 PM, Pawel Jakub Dawidek  wrote:
> On Sun, Nov 25, 2012 at 01:48:23PM +, Attilio Rao wrote:
>> On Sun, Nov 25, 2012 at 1:47 PM, Pawel Jakub Dawidek  
>> wrote:
>> > On Sun, Nov 25, 2012 at 01:37:19PM +, Attilio Rao wrote:
>> >> On Sun, Nov 25, 2012 at 1:12 PM, Pawel Jakub Dawidek  
>> >> wrote:
>> >> > On Sun, Nov 25, 2012 at 12:42:16PM +, Attilio Rao wrote:
>> >> >> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek 
>> >> >>  wrote:
>> >> >> > WITNESS is a development tool. We don't ship production kernels with
>> >> >> > WITNESS even compiled in. What is more efficient use of developer 
>> >> >> > time:
>> >> >> > going through full reboot cycle every time or reading the warning 
>> >> >> > from
>> >> >> > console, unloading a module, fixing the bug and loading it again?
>> >> >> >
>> >> >> > And if this option is turned off by default what is the problem?
>> >> >>
>> >> >> Yes, so, why do you write here?
>> >> >
>> >> > I'm trying to understand why do you object. Until now the only concern
>> >> > you have that I found is that you are afraid of it being abused. I don't
>> >> > see how this can be abused if it is turned off by default. If someone
>> >> > will commit a change that will turn it on by default, believe me, I'll
>> >> > unleash hell personally.
>> >>
>> >> So I don't understand what are you proposing.
>> >> You are not proposing to switch BLESSING on and you are not proposing
>> >> to import Adrian's patches in, if I get it correctly. I don't
>> >> understand then.
>> >
>> > I propose to get Adrian's patches in, just leave current behaviour as
>> > the default.
>>
>> So if I tell that I'm afraid this mechanism will be abused (and
>> believe me, I really wanted to trimm out BLESSING stuff also for the
>> same reason) and you say "you can't see how" there is not much we can
>> discuss.
>
> This is not what I said. I would see it as abuse if someone will
> suddenly decided to turn off locking assertions by default in FreeBSD
> base.
>
> If he will turn that off on his private machine be it to speed up his
> development (a good thing) or to shut up important lock assertion (a bad
> thing) this is entirely his decision. He can already do that having all
> the source code, its just more complex. Make tools, not policies.
>
> BLESSING is totally different subject. You were afraid that people will
> start to silence LORs they don't understand by committing blessed pairs
> to FreeBSD base. And this situation is abuse and I fully agree, but I
> also still think BLESSING is useful, although I recognize it might be
> hard to prevent mentioned abuse.
>
> In case of Adrian's patch nothing will change in how we enforce locking
> assertions in FreeBSD base.
>
>> You know how I think, there is no need to wait for me to reconsider,
>> because I don't believe this will happen with arguments like "I don't
>> think", "I don't agree", etc.
>
> I provide valid arguments with I hope proper explanation, you choose not
> to address them or ignore them and I hope this will change:)

I'm not ignoring them, I'm saying that your arguments are not enough
convincing to me.
And really, giving the possibility to turn off assertions in witness
is already a dangerous tool I want to avoid (not only related to
BLESSING). If there are some cases that deserve a panic, we might just
get it, not matter how sysctls are setup.

However it seems to me I'm just saying the same thing since 20
e-mails, please drop me from CC in your next follow up. As I said, you
can commit all the changes you want (assuming they are technically
correct) even if I would appreciate my disagreement is expressed in
the commit message.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RFQ] make witness panic an option

[Attilio Rao]

On Sun, Nov 25, 2012 at 1:12 PM, Pawel Jakub Dawidek  wrote:
> On Sun, Nov 25, 2012 at 12:42:16PM +, Attilio Rao wrote:
>> On Sun, Nov 25, 2012 at 12:39 PM, Pawel Jakub Dawidek  
>> wrote:
>> > WITNESS is a development tool. We don't ship production kernels with
>> > WITNESS even compiled in. What is more efficient use of developer time:
>> > going through full reboot cycle every time or reading the warning from
>> > console, unloading a module, fixing the bug and loading it again?
>> >
>> > And if this option is turned off by default what is the problem?
>>
>> Yes, so, why do you write here?
>
> I'm trying to understand why do you object. Until now the only concern
> you have that I found is that you are afraid of it being abused. I don't
> see how this can be abused if it is turned off by default. If someone
> will commit a change that will turn it on by default, believe me, I'll
> unleash hell personally.
>
> As I said, WITNESS is development tool, a very handy one. This doesn't
> mean we can't make it even more handy. It is there to help find bugs
> faster, right? Adrian is proposing a change that will make it help to
> find and fix bugs maybe even faster.
>
>> Go ahead and fix BLESSED, make it the default, etc.
>
> This is another story, but BLESSED is much less controversial to me.
> It is turned off by default in assumption that all the code that runs in
> our kernel is developed for FreeBSD, which is not true. For example ZFS
> is, I think, the biggest locking consumer in our kernel (around 120
> locks), which wasn't originally developed for FreeBSD and locking order
> was verified using different tools. Now on FreeBSD it triggers massive
> LOR warnings from WITNESS, eventhough those are not bugs. At some point
> I verified many of them and they were all false-positives, so I simply
> turned off WITNESS warnings for ZFS locks. Why? Because BLESSED is
> turned off in fear of abuse, and this is turn is the cause of mentioned
> hack in ZFS.

Just a few notes about this: to my knowledge you never discussed
publically this. WITNESS is not a perfect tool and it has several
issues (I tried to summarize them a bit at the beginning of this
thread), where the biggest problem is that its file/line approach
doesn't help when willing to shutdown specific LOR without shutting
down all of them involving the lock pair, etc.

I have no idea what are the problems you are facing here with WITNESS
and ZFS but if you could summarize them we can work on getting
something which is useful also with ZFS.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: stop_cpus_hard when multiple CPUs are panicking from an NMI

[Andriy Gapon]

on 25/11/2012 16:01 Attilio Rao said the following:
> On Sun, Nov 25, 2012 at 12:55 PM, Andriy Gapon  wrote:
>> on 25/11/2012 14:29 Attilio Rao said the following:
>>> I think the patch you propose makes such effects even worse, because
>>> it disables interrupts in generic_stop_cpus().
>>> What I suggest to do, is the following:
>>> - The CPU which wins the race for generic_stop_cpus also signals the
>>> CPUs it is willing to stop on a global mask
>>> - Another CPU entering generic_stop_cpus() and loosing the race,
>>> checks the mask of cpus which might be stopped and stops itself if
>>> necessary (ie. not yet done). We must be careful with races here, but
>>> I'm confindent this can be done easily enough.
>>
>> I think that you either misunderstood my patch or I misunderstand your
>> suggestion, because my patch does exactly what you wrote above.
> 
> The patch is someway incomplete:
> - I don't think that we need specific checks in cpustop_handler() (and
> if you have added them to prevent races, I don't think they are
> enough, see below)

The check is to cover the following scenario:
- two CPUs race in hard-stop scenario, and both are in NMI contexts
- one CPU wins and the other does spinning right in generic_stop_cpus
- NMI for the spinning CPU is blocked and remains pending
- the winning CPU releases all other CPUs
- the spinning CPU exits the NMI context and get the NMI which was pending

> - setting of "stopping_cpus" map must happen atomically/before the
> stopper_cpu cpuid setting, otherwise some CPUs may end up using a NULL
> mask in the check

Not NULL, but empty or stale.  But a very good point, I agree.
The logic must be redone.

> - Did you consider the races about when a stop and restart request
> happen just after the CPU_ISSET() check? I think CPUs can deadlock
> there.

Yeah, good point again.  This seems to be a different side of the issue above.
stopping_cpus is probably a bad idea.

> - I'm very doubious about the spinlock_enter() stuff, I think I can
> just make the problem worse atm.

Well, this is where I disagree.  I think that cpu_stop must already be called in
context which effectively disable pre-emption and interrupts.
The added spinlock_enter() stuff is kind of a safety belt to make things more
explicit, but it could be changed into some sort of an assert if that's 
possible.

> However you are right, the concept of your patch is the same I really
> wanted to get, we maybe need to just lift it up a bit.

I agree.

To add some gas to the fire.  Do you recall my wish to drop the mask parameter
from the stop calls?  If that was done then it would be simpler to handle these
things.  In that case only "stopper_cpu" ID (master/winner) would be needed.

> In the while I also double-checked suspended_cpus and I don't think
> there are real showstoppers to have it in stopped_cpus map.

-- 
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD on RaspberryPi

[Tim Kientzle]

On Nov 24, 2012, at 8:01 PM, Oleksandr Tymoshenko wrote:

> 
> On 2012-11-24, at 4:47 PM, Tim Kientzle  wrote:
> 
>> 
>> On Nov 24, 2012, at 11:13 AM, Alexander Yerenkow wrote:
>> 
>>> 
>>> 
>>> 2012/11/24 Tim Kientzle 
>>> On Nov 7, 2012, at 8:09 AM, Alexander Yerenkow wrote:
>>> 
> Such experiments was tried by me and others in August; I got framebuffer 
> worked in rca/hdmi; …
>>> 
>>> On Nov 8, 2012, at 11:12 PM, Alexander Yerenkow wrote:
>>> 
 It was plain current with plain RPIB kernel config, and for graphic you 
 should uncomment there partition about sysconsole; serial then disabled;
 Also, if you want ethernet - it's ue device, which also worked, but 
 produced hangs for me in past (Hans IIRC already fixed.this).
 I'll have some time this weekend, feel free to contact me by gtalk or 
 else, I will play around with my rpi with both serials and vide modes.
>>> 
>>> Alexander,
>>> 
>>> I tried uncommenting the 'sc' entries in the RPI-B kernel
>>> config that's in -CURRENT right now.
>>> 
>>> All entries, right?
>> 
>> Yes, I uncommented all entries.
>> 
>>> And how do you booting, via usb-flash, or via SD card?
>> 
>> Via SD-card.  I'm using the image from here:
>> http://people.freebsd.org/~kientzle/FreeBSD-RPI-B-r242362-2012-10-30.img.xz
>> and swapping out the kernel.
>> 
>>> I'll build now CURRENT, will look if I got same. 
>> 
>> Thanks.  I'd appreciate knowing whether it works for you.
>> 
>> If you can get it to work, I'd appreciate any details you can give.
> 
> Tim,
> 
> I'm almost done with getting kernel working with latest raspberry Pi 
> firmware. Just need
> to figure out how to make ubldr pass FDT pointer from u-boot to kernel and 
> handle 
> /reserve/ information in ARM machdep code. 

Let me know if you need help with this.  I've worked with
the ubldr FDT code recently.

> Meanwhile I suggest editing .dts file manually. Fill out "display" node 
> properties with proper
> display resolution and depth. Also add ukbd driver. That should get you 
> working console.

I'll try that.

I'm curious:  why is this information coming from the DTS?
That seems pretty complex; I thought that the
console code would query this information via the mailbox
interface.

Tim
 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: stop_cpus_hard when multiple CPUs are panicking from an NMI

[Attilio Rao]

On Sun, Nov 25, 2012 at 3:39 PM, Andriy Gapon  wrote:
> on 25/11/2012 16:01 Attilio Rao said the following:
>> On Sun, Nov 25, 2012 at 12:55 PM, Andriy Gapon  wrote:
>>> on 25/11/2012 14:29 Attilio Rao said the following:
 I think the patch you propose makes such effects even worse, because
 it disables interrupts in generic_stop_cpus().
 What I suggest to do, is the following:
 - The CPU which wins the race for generic_stop_cpus also signals the
 CPUs it is willing to stop on a global mask
 - Another CPU entering generic_stop_cpus() and loosing the race,
 checks the mask of cpus which might be stopped and stops itself if
 necessary (ie. not yet done). We must be careful with races here, but
 I'm confindent this can be done easily enough.
>>>
>>> I think that you either misunderstood my patch or I misunderstand your
>>> suggestion, because my patch does exactly what you wrote above.
>>
>> The patch is someway incomplete:
>> - I don't think that we need specific checks in cpustop_handler() (and
>> if you have added them to prevent races, I don't think they are
>> enough, see below)
>
> The check is to cover the following scenario:
> - two CPUs race in hard-stop scenario, and both are in NMI contexts

Please consider also another type of (similar race): two CPUs race in
(normal) stop scenario and the loser is with interrupt disabled. I
don't this will be completely fatal, but I'm sure it can lead to
issues (double stop, etc.).

> - one CPU wins and the other does spinning right in generic_stop_cpus
> - NMI for the spinning CPU is blocked and remains pending
> - the winning CPU releases all other CPUs
> - the spinning CPU exits the NMI context and get the NMI which was pending
>
>> - setting of "stopping_cpus" map must happen atomically/before the
>> stopper_cpu cpuid setting, otherwise some CPUs may end up using a NULL
>> mask in the check
>
> Not NULL, but empty or stale.  But a very good point, I agree.
> The logic must be redone.
>
>> - Did you consider the races about when a stop and restart request
>> happen just after the CPU_ISSET() check? I think CPUs can deadlock
>> there.
>
> Yeah, good point again.  This seems to be a different side of the issue above.
> stopping_cpus is probably a bad idea.
>
>> - I'm very doubious about the spinlock_enter() stuff, I think I can
>> just make the problem worse atm.
>
> Well, this is where I disagree.  I think that cpu_stop must already be called 
> in
> context which effectively disable pre-emption and interrupts.
> The added spinlock_enter() stuff is kind of a safety belt to make things more
> explicit, but it could be changed into some sort of an assert if that's 
> possible.

Maybe it can be come really safe once we take care of all the races
involved and reported above. I reserve to suspend my judgement until
we don't care of the other races.

>
>> However you are right, the concept of your patch is the same I really
>> wanted to get, we maybe need to just lift it up a bit.
>
> I agree.
>
> To add some gas to the fire.  Do you recall my wish to drop the mask parameter
> from the stop calls?  If that was done then it would be simpler to handle 
> these
> things.  In that case only "stopper_cpu" ID (master/winner) would be needed.

If you really want to do something like that please rename
s/generic_stop_cpus/generic_stop_butself() or similar convention and I
may be not opposed to it.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: stop_cpus_hard when multiple CPUs are panicking from an NMI

[Andriy Gapon]

on 25/11/2012 20:05 Attilio Rao said the following:
> If you really want to do something like that please rename
> s/generic_stop_cpus/generic_stop_butself() or similar convention and I
> may be not opposed to it.

As we discussed before, anything else besides "all but self" does not make
sense.  So I am not sure what's the point of being that verbose in the naming.

-- 
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: postfix mail server infected ?

[trafdev]

Hi. Can you please point me to some discussions and solutions related 
to this problem? Thanks.


On Sun Nov 25 02:43:10 2012, Kim Culhan wrote:

On Sat, November 24, 2012 1:08 pm, trafdev wrote:
> Hi. I've a dedicated stand-alone FreeBSD server:
>  > uname -a
> FreeBSD trafd-website-freebsd 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0:
> Tue Jun 12 02:52:29 UTC 2012
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC

amd64
>
> Server has one external interface (re0) with IP 206.239.112.241 and
> postfix service installed on 25 port.
>
> Yesterday I've noticed huge amount of emails sending out:
>
> Nov 24 00:00:37 trafd-website-freebsd postfix/smtpd[37230]: connect from
> f116.sd.com [206.239.112.241]
> Nov 24 00:00:37 trafd-website-freebsd postfix/qmgr[40324]: 73F7D1365D:
> from=mailto:wkk...@f116.sd.com>>, size=1211,
nrcpt=10 (queue active)
> Nov 24 00:00:37 trafd-website-freebsd postfix/error[37366]: 75ECA134F2:
> to=mailto:reco.mo...@yahoo.com.br>>,
relay=none, delay=25715,
> delays=25715/0.02/0/0.12, dsn=4.7.0, status=deferred (delivery
> temporarily suspended: host mta7.am0.yahoodns.net
[66.94.236.34] refused
> to talk to me: 421 4.7.0 [TS01] Messages from 206.239.112.241
> temporarily deferred due to user complaints - 4.16.55.1; see
> http://postmaster.yahoo.com/421-ts01.html)
> Nov 24 00:00:37 trafd-website-freebsd postfix/error[37368]: 794A911711:
> to=mailto:t...@yahoo.com.br>>, relay=none,
delay=29716,
> delays=29716/0.05/0/0.05, dsn=4.7.0, status=deferred (delivery
> temporarily suspended: host mta7.am0.yahoodns.net
[66.94.236.34] refused
> to talk to me: 421 4.7.0 [TS01] Messages from 206.239.112.241
> temporarily deferred due to user complaints - 4.16.55.1; see
> http://postmaster.yahoo.com/421-ts01.html)
> Nov 24 00:00:37 trafd-website-freebsd postfix/smtp[36699]: E559512F49:
> to=mailto:luziarodrigues...@terra.com.br>>,
> relay=vip-us-br-mx.terra.com
[208.84.244.133]:25, delay=26077,
> delays=26075/1/0.59/0.31, dsn=4.7.1, status=deferred (host
> vip-us-br-mx.terra.com
[208.84.244.133] said: 450 4.7.1 You've
exceeded
> your sending limit to this domain. (in reply to end of DATA command))
> Nov 24 00:00:37 trafd-website-freebsd postfix/error[37370]: 7C45D18E5D:
> to=mailto:a92...@yahoo.com.br>>, relay=none,
delay=6984,
> delays=6984/0.02/0/0.04, dsn=4.7.0, status=deferred (delivery
> temporarily suspended: host mta7.am0.yahoodns.net
[66.94.236.34] refused
> to talk to me: 421 4.7.0 [TS01] Messages from 206.239.112.241
> temporarily deferred due to user complaints - 4.16.55.1; see
> http://postmaster.yahoo.com/421-ts01.html)
> Nov 24 00:00:37 trafd-website-freebsd postfix/qmgr[40324]: 73E8118E53:
> from=mailto:t9...@f116.sd.com>>, size=1143,
nrcpt=10 (queue active)
> Nov 24 00:00:37 trafd-website-freebsd postfix/smtpd[37153]: 93E1020413:
> client=f116.sd.com [206.239.112.241]
> Nov 24 00:00:37 trafd-website-freebsd postfix/error[37367]: 74A511A5BF:
> to=mailto:duscher...@yahoo.com.br>>,
relay=none, delay=5587,
> delays=5587/0/0/0.18, dsn=4.7.0, status=deferred (delivery temporarily
> suspended: host mta7.am0.yahoodns.net
[66.94.236.34] refused to talk to
> me: 421 4.7.0 [TS01] Messages from 206.239.112.241 temporarily deferred
> due to user complaints - 4.16.55.1; see
> http://postmaster.yahoo.com/421-ts01.html)
> Nov 24 00:00:37 trafd-website-freebsd postfix/smtp[36698]: E7898134D0:
> to=mailto:g...@terra.com.br>>,
relay=vip-us-br-mx.terra.com
[208.84.244.133]:25,
> conn_use=4, delay=25728, delays=25726/1.1/0.06/0.4, dsn=4.7.1,
> status=deferred (host vip-us-br-mx.terra.com
[208.84.244.133] said: 450
> 4.7.1 You've exceeded your sending limit to this domain. (in reply to
> end of DATA command))
> Nov 24 00:00:37 trafd-website-freebsd postfix/smtp[36226]: 7BE421F989:
> to=mailto:elc.mo...@bol.com.br>>,
relay=mx3.bol.com.br [200.147.36.13]:25,
> delay=339, delays=339/0/0.49/0.24, dsn=4.7.1, status=deferred (host
> mx3.bol.com.br [200.147.36.13] said: 450
4.7.1 mailto:elc.mo...@bol.com.br>>:
> Recipient address rejected: MX-BOL-04 - Too many messages, try again
> later. (in reply to RCPT TO command))
>
> Where f116.sd.com [206.239.112.241] is an IP and
host assigned for
> external interface (re0).
>
> Due to "permit_mynetworks" policy enabled in postfix conf mail was
> sending out without authentication. However all externally connected
> clients were rejected which is proper and expected behavior:
>
> Nov 24 19:31:04 trafd-website-freebsd postfix/smtpd[65618]: connect from
> a2-starfury4.uol.com.br [200.147.33.227]
> Nov 24 19:31:05 trafd

Re: FreeBSD on RaspberryPi

[Tim Kientzle]

On Nov 11, 2012, at 12:46 PM, Adrian Chadd wrote:

> On 11 November 2012 12:39, Oleksandr Tymoshenko  wrote:
> 
>> At the moment HDMI output works only in a sense of video output for simple
>> frame buffer. I'm trying to get GPU support ported but not sure how much time
>> it will take. Eventually we'd like to get audio support too.
> 
> How's the general, non-video support working out? Are there any random
> crashes or panics that people are seeing on R-PI right now?


So far, I haven't done very much, but it is stable enough to
natively build a bootable kernel; note the build machine on
my RPi boot message:

FreeBSD 10.0-CURRENT #2: Sun Nov 25 14:23:57 UTC 2012
root@raspberry-pi:/usr/src/sys/arm/compile/RPI-B arm

The two biggest obstacles right now are:
* Memory.  There's a missing piece in the current boot sequence
   that causes it to always default to 128MB memory.  That makes
   it hard to do much on a generic -CURRENT build.  (The native kernel
   above took a long time; swapping to SDHC is a little slow. ;-)

   Related:  Shipping RPis now have 512MB RAM; I'm pretty excited about that.

* Video console.  You've probably noticed the exchanges on the list.


Apart from that, it's pretty promising.  I'm optimistic that we're
no more than a couple of weeks from having a FreeBSD image
that a lot of folks can just download and use.

Tim

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: [RFQ] make witness panic an option

[Adrian Chadd]

The reason I haven't yet committed it is I'd like to sit down with
Attilio one-on-one and figure out the _right_ way to do this.

There's a time for shit-stirring and a time for getting stuff done;
this is neither of those times. I don't mind taking my time on this
one.



Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: stop_cpus_hard when multiple CPUs are panicking from an NMI

[Attilio Rao]

On Sun, Nov 25, 2012 at 7:20 PM, Andriy Gapon  wrote:
> on 25/11/2012 20:05 Attilio Rao said the following:
>> If you really want to do something like that please rename
>> s/generic_stop_cpus/generic_stop_butself() or similar convention and I
>> may be not opposed to it.
>
> As we discussed before, anything else besides "all but self" does not make
> sense.  So I am not sure what's the point of being that verbose in the naming.

Avoid POLA violation and show there is a change in the KPI?

I'd personally prefer a new name, but I'm open on not getting it.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD needs Git to ensure repo integrity

[Dag-Erling Smørgrav]

grarpamp  writes:
> Any of hundreds of committer and admin accounts could be compromised
> with the attacker silently editing the repo.

FUD.  Committer accounts don't have direct access to the repo.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Incorrect use of posix_memalign() (was: Re: svn commit: r243405 - in stable/9: include lib/libc/stdlib)

[Jilles Tjoelker]

On Thu, Nov 22, 2012 at 03:19:53PM +, Ed Schouten wrote:
> Author: ed
> Date: Thu Nov 22 15:19:53 2012
> New Revision: 243405
> URL: http://svnweb.freebsd.org/changeset/base/243405

> Log:
>   MFC r229848:

> Add aligned_alloc(3).

> The C11 folks reinvented the wheel by introducing an aligned version of
> malloc(3) called aligned_alloc(3), instead of posix_memalign(3). Instead
> of returning the allocation by reference, it returns the address, just
> like malloc(3).

>   I'm MFCing this now, as it seems aligned_alloc(3) is needed to make the
>   new version of libc++ work, which was merged back to FreeBSD 9 in r243376.

The C11 committee knew about posix_memalign() and had several reasons
for creating a new function; see for example
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1397.htm .

In particular, posix_memalign() is a little annoying to use correctly,
often requiring a temporary variable of type void *. It is tempting to
do something like
  error = posix_memalign((void **)&some_ptr, aln, sz);
and some FreeBSD code does this, but it violates strict-aliasing. A
further mostly theoretical objection is that assumes that the
representation of some_ptr and void * are compatible which C does not
guarantee.

The problem can be fixed by adding the temporary pointer variable like
  void *tmp_ptr;
  error = posix_memalign(&tmp_ptr, aln, sz);
  some_ptr = tmp_ptr;
or by using aligned_alloc() instead of posix_memalign()
  some_ptr = aligned_alloc(aln, sz);
with error checking against some_ptr instead of error.

-- 
Jilles Tjoelker
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

"not" user display in top

[Nikos Vassiliadis]

Hi,

 The attached patch adds 'not' functionality to the interactive u command
in top so one can select all processes not owned by a user. This happens
when the username is prefixed with a minus. Example display for -root:


CPU:  0.0% user,  0.0% nice,  0.1% system,  0.0% interrupt, 99.9% idle
Mem: 16M Active, 108M Inact, 150M Wired, 3760K Cache, 112M Buf, 1210M Free
Swap: 288M Total, 288M Free

  PID USERNAME  THR PRI NICE   SIZERES STATE   C   TIME   WCPU COMMAND
  794 smmsp   1  200 12812K  4284K pause   1   0:00  0.00% sendmail
  566 _dhcp   1  390 10136K  1848K select  0   0:00  0.00% dhclient



Thanks, Nikos

Index: contrib/top/machine.h
===
--- contrib/top/machine.h   (revision 243514)
+++ contrib/top/machine.h   (working copy)
@@ -65,6 +65,7 @@
 int system;/* show system processes */
 int thread;/* show threads */
 int uid;   /* only this uid (unless uid == -1) */
+int buid;  /* all but this uid (unless buid == -1) */
 int wcpu;  /* show weighted cpu */
 int jail;  /* show jail ID */
 int kidle; /* show per-CPU idle threads */
Index: contrib/top/top.X
===
--- contrib/top/top.X   (revision 243514)
+++ contrib/top/top.X   (working copy)
@@ -286,8 +286,10 @@
 .TP
 .B u
 Display only processes owned by a specific username (prompt for username).
-If the username specified is simply \*(lq+\*(rq, then processes belonging
-to all users will be displayed.
+If the username specified is simply \*(lq+\*(rq or \*(lq-\*(rq, then processes
+belonging to all users will be displayed.
+If the username is prefixed by a \*(lq-\*(rq, then only processes not owned
+by the username will be displayed.
 .TP
 .B o
 Change the order in which the display is sorted.  This command is not
Index: contrib/top/top.c
===
--- contrib/top/top.c   (revision 243514)
+++ contrib/top/top.c   (working copy)
@@ -259,6 +259,7 @@
 ps.self= -1;
 ps.system  = No;
 ps.uid = -1;
+ps.buid= -1;
 ps.thread  = No;
 ps.wcpu= 1;
 ps.jail= No;
@@ -997,20 +998,32 @@
"Username to show: ");
if (readline(tempbuf2, sizeof(tempbuf2), No) > 
0)
{
-   if (tempbuf2[0] == '+' &&
+   if ((tempbuf2[0] == '+' || tempbuf2[0] == 
'-') &&
tempbuf2[1] == '\0')
{
ps.uid = -1;
+   ps.buid = -1;
}
+   else if (tempbuf2[0] == '-')
+   {
+   if ((i = userid(tempbuf2 + 1)) == -1)
+   {
+   new_message(MT_standout,
+   " %s: unknown user", tempbuf2 + 
1);
+   no_command = Yes;
+   } else {
+   ps.uid = -1;
+   ps.buid = i;
+   }
+   }
else if ((i = userid(tempbuf2)) == -1)
{
new_message(MT_standout,
" %s: unknown user", tempbuf2);
no_command = Yes;
-   }
-   else
-   {
+   } else {
ps.uid = i;
+   ps.buid = -1;
}
putchar('\r');
}
Index: usr.bin/top/machine.c
===
--- usr.bin/top/machine.c   (revision 243514)
+++ usr.bin/top/machine.c   (working copy)
@@ -671,6 +671,7 @@
int show_self;
int show_system;
int show_uid;
+   int show_buid;
int show_command;
int show_kidle;
 
@@ -713,6 +714,7 @@
show_self = sel->self == -1;
show_system = sel->system;
show_uid = sel->uid != -1;
+   show_buid = sel->buid != -1;
show_command = sel->command != NULL;
show_kidle = sel->kidle;
 
@@ -768,6 +770,10 @@
/* skip proc. that don't belong to the selected UID */
   

Running kgdb in batch mode.

[Sushanth Rai]

Basically I would like to get kernel backtrace of a bunch of threads from the 
live kernel under some conditions. When the condition is seen I would like to 
run kgdb, collect kernel backtrace of specific threads and exit. Is there a way 
run kgdb in batch mode ? Or any other way to get the stack trace.

Thanks,
Sushanth
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: FreeBSD on RaspberryPi

[Oleksandr Tymoshenko]

On 2012-11-25, at 9:32 AM, Tim Kientzle  wrote:

> 
> On Nov 24, 2012, at 8:01 PM, Oleksandr Tymoshenko wrote:
> 
>> 
>> On 2012-11-24, at 4:47 PM, Tim Kientzle  wrote:
>> 
>> 

.. skipped ..

>> Tim,
>> 
>> I'm almost done with getting kernel working with latest raspberry Pi 
>> firmware. Just need
>> to figure out how to make ubldr pass FDT pointer from u-boot to kernel and 
>> handle 
>> /reserve/ information in ARM machdep code. 
> 
> Let me know if you need help with this.  I've worked with
> the ubldr FDT code recently.
> 
>> Meanwhile I suggest editing .dts file manually. Fill out "display" node 
>> properties with proper
>> display resolution and depth. Also add ukbd driver. That should get you 
>> working console.
> 
> I'll try that.
> 
> I'm curious:  why is this information coming from the DTS?
> That seems pretty complex; I thought that the
> console code would query this information via the mailbox
> interface.


It's either FDT blob or message box interface. Implementation complexity is 
about the same.
But since we're getting other variables (like MAC address, memory size) from 
FDT I decided
to be consistent and get all of them from there. The issue I'm facing is that 
ubldr gets FDT blob
either from file directly or from ELF kernel itself. While on Raspberry Pi to 
works as follows:

- Firmware loads .dtb file from SD card to specified address
- Fixes up values like amount of memory, reserved regions, UART and clock 
frequencies, 
   MAC address, display resolution.
- Passes control to next link in boot chain (e.g. U-Boot)

I'm thinking about adding compile-time constant FDT_BLOB_ADDRESS and arrange 
possible
FDT sources in following priority:

- Check FDT_BLOB_ADDRESS (if defined)
- Check dtb file
- Check ELF kernel

Does it sound sane enough? 
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"