tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]


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 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.
>> - 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
>>  of DEBUG - it is at least clearly a "heavier check". :)
>> - There MUST be a very clear indication to users - a warning in a visible
>>  place that the kernel has diagnostic options enabled, and performance
>>  is significantly degraded.
>> - 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.
> - 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 not very useful reports, when
>  backtrace is missing.

I like this we should definitely set DDB_COMMANDONENTER to something like above.



Home | Main Index | Thread Index | Old Index