On Sun, Jul 03, 2011 at 08:31:00PM +0300, Jukka Ruohonen wrote:
> On Sun, Jul 03, 2011 at 07:27:00PM +0200, Manuel Bouyer wrote:
> > it's not only about Xen, it's about all kernels for any port which
> > already have DIAGNOSTIC and want to keep it even for release
> > (e.g. i386 ALL).
>
> As far a
On Sun, Jul 03, 2011 at 07:27:00PM +0200, Manuel Bouyer wrote:
> it's not only about Xen, it's about all kernels for any port which
> already have DIAGNOSTIC and want to keep it even for release
> (e.g. i386 ALL).
As far as I understand, i386/ALL is just for testing the compilation of
various opti
On Sun, Jul 03, 2011 at 06:23:49PM +0100, Mindaugas Rasiukevicius wrote:
> Manuel Bouyer wrote:
> > On Sun, Jul 03, 2011 at 04:17:02PM +0100, Mindaugas Rasiukevicius wrote:
> > > Manuel Bouyer wrote:
> > > > >
> > > > > - Obviously, defined policy/responsibility to disable these options
> > > >
Manuel Bouyer wrote:
> On Sun, Jul 03, 2011 at 04:17:02PM +0100, Mindaugas Rasiukevicius wrote:
> > Manuel Bouyer wrote:
> > > >
> > > > - Obviously, defined policy/responsibility to disable these options
> > > > for release kernels. In fact, if we go this way - then options
> > > > should be r
On Sun, Jul 03, 2011 at 04:17:02PM +0100, Mindaugas Rasiukevicius wrote:
> Manuel Bouyer wrote:
> > >
> > > - Obviously, defined policy/responsibility to disable these options for
> > > release kernels. In fact, if we go this way - then options should be
> > > removed from all MD kernel conf
Manuel Bouyer wrote:
> >
> > - Obviously, defined policy/responsibility to disable these options for
> > release kernels. In fact, if we go this way - then options should be
> > removed from all MD kernel configs and managed in MI src/sys/conf/std.
>
> I'm not sure this is doable: some port
On Wed, Jun 22, 2011 at 02:06:34AM +, David Holland wrote:
> On Thu, Jun 16, 2011 at 07:49:43PM +0200, Manuel Bouyer wrote:
> > > I'm not in favor of LOCKDEBUG by default, for reasons already stated
> here.
> >
> > Also, could LOCKDEBUG have ABI issues with modules ?
> > I've only ever us
FWIW, i much prefer using DDB_ONPANIC=2 than setting the enter command
to "bt". unfortunately only options(4) meantions this, not sysctl(4)
or ddb(4).
.mrg.
On Thu, Jun 16, 2011 at 07:49:43PM +0200, Manuel Bouyer wrote:
> > I'm not in favor of LOCKDEBUG by default, for reasons already stated here.
>
> Also, could LOCKDEBUG have ABI issues with modules ?
> I've only ever used LOCKDEBUG with non-MODULAR kernels ...
The whole reason LOCKDEBUG is aby
On Fri, Jun 17, 2011 at 12:34:53PM +0200, Manuel Bouyer wrote:
> On Fri, Jun 17, 2011 at 12:24:13PM +0200, Adam Hamsik wrote:
> >
> > On Jun,Thursday 16 2011, at 5:30 PM, Mindaugas Rasiukevicius wrote:
> > > - DDB_ONPANIC=1 and DDB_COMMANDONENTER="bt;show regsisters" and perhaps
> > > also "call
On Fri, Jun 17, 2011 at 12:24:13PM +0200, Adam Hamsik wrote:
>
> On Jun,Thursday 16 2011, at 5:30 PM, Mindaugas Rasiukevicius wrote:
>
> > Mindaugas Rasiukevicius wrote:
> >> I have few concerns:
> >>
> >> - If we enable DIAGNOSTIC, then we should also enable DEBUG, as it also
> >> covers many
On Jun,Thursday 16 2011, at 5:30 PM, Mindaugas Rasiukevicius wrote:
> Mindaugas Rasiukevicius wrote:
>> I have few concerns:
>>
>> - If we enable DIAGNOSTIC, then we should also enable DEBUG, as it also
>> covers many relevant diagnostic checks.
>>
>> - Alternatively, it should be clearly def
On Jun 16, 2011, at 3:29 36AM, Manuel Bouyer wrote:
> Hello,
> for the second time (at last) a kernel issue raised the question of
> adding back 'options DIAGNOSTIC' to GENERIC/INSTALL kernels in HEAD.
> Several people agreed tha this would be a good thing.
>
Good idea. (I'm reminded of a comm
On Fri, Jun 17, 2011 at 12:42:34AM +0400, Aleksej Saushev wrote:
> I'd say that at least "call ddb_vgapost" should enter default sysctl.conf,
> at least commented out. It isn't trivial to learn that the functionality
> exists, and it is the only way to get to debugger on modern machines
> without s
Mindaugas Rasiukevicius writes:
> - DDB_ONPANIC=1 and DDB_COMMANDONENTER="bt;show regsisters" and perhaps
> also "call ddb_vgapost" in the beginning (not sure if there are any
> potential side effects?). Otherwise, not getting information from DDB
> is just counter-productive, plus we get
On Thu, Jun 16, 2011 at 05:50:56PM +0200, Manuel Bouyer wrote:
> >
> > - Alternatively, it should be clearly defined what goes under DEBUG,
> > i.e. what is considered a "heavier check". I think code diverged in
> > a way that the difference between DEBUG and DIAGNOSTIC is small.
> >
> > - S
On Thu, Jun 16, 2011 at 04:30:18PM +0100, Mindaugas Rasiukevicius wrote:
> Mindaugas Rasiukevicius wrote:
> > I have few concerns:
> >
> > - If we enable DIAGNOSTIC, then we should also enable DEBUG, as it also
> > covers many relevant diagnostic checks.
> >
> > - Alternatively, it should be c
On Thu, Jun 16, 2011 at 04:20:06PM +0100, Mindaugas Rasiukevicius wrote:
> I have few concerns:
>
> - If we enable DIAGNOSTIC, then we should also enable DEBUG, as it also
> covers many relevant diagnostic checks.
Historically, DIAGNOSTIC was enabled and DEBUG was not. Usually (but maybe
my vie
rmind@ wrote:
> Otherwise, not getting information from DDB
> is just counter-productive, plus we get not very useful reports, when
> backtrace is missing.
FYI, OpenBSD puts the following message on entering ddb:
---
db_printf("RUN AT LEAST 'trace' AND 'ps' AND INCLUDE "
On Thu, Jun 16, 2011 at 04:30:18PM +0100, Mindaugas Rasiukevicius wrote:
> > - Since performance is degraded and -current users concerned about it
> > will need to compile their own kernels anyway - I believe LOCKDEBUG
> > should be enabled as well. Perhaps LOCKDEBUG should become a part
> >
Mindaugas Rasiukevicius wrote:
> I have few concerns:
>
> - If we enable DIAGNOSTIC, then we should also enable DEBUG, as it also
> covers many relevant diagnostic checks.
>
> - Alternatively, it should be clearly defined what goes under DEBUG,
> i.e. what is considered a "heavier check". I
Manuel Bouyer wrote:
> for the second time (at last) a kernel issue raised the question of
> adding back 'options DIAGNOSTIC' to GENERIC/INSTALL kernels in HEAD.
> Several people agreed tha this would be a good thing.
>
> So here's the formal question: would someone object if I add back
> 'option
On Thu, Jun 16, 2011 at 03:20:42PM +0100, Julio Merino wrote:
> On 6/16/11 9:54 AM, Martin Husemann wrote:
> > On Thu, Jun 16, 2011 at 09:29:36AM +0200, Manuel Bouyer wrote:
> >> So here's the formal question: would someone object if I add back
> >> 'options DIAGNOSTIC' to i386 and amd64 GENERIC an
On 6/16/11 9:54 AM, Martin Husemann wrote:
> On Thu, Jun 16, 2011 at 09:29:36AM +0200, Manuel Bouyer wrote:
>> So here's the formal question: would someone object if I add back
>> 'options DIAGNOSTIC' to i386 and amd64 GENERIC and INSTALL kernels,
>> with a comment saying this should be disabled on
On Thu, Jun 16, 2011 at 09:29:36AM +0200, Manuel Bouyer wrote:
> So here's the formal question: would someone object if I add back
> 'options DIAGNOSTIC' to i386 and amd64 GENERIC and INSTALL kernels,
> with a comment saying this should be disabled on release branch
> (it would be up to releng to c
25 matches
Mail list logo
