>>> On 07.03.16 at 15:41, wrote:
> On Mon, Mar 7, 2016 at 5:44 AM, Jan Beulich wrote:
> On 04.03.16 at 21:55, wrote:
+case XEN_SYSCTL_LOGLVL_set:
+if ( (op->host.lower_thresh >= 0 && op->host.upper_thresh >= 0 &&
+ op->host.lower_thresh > op->host.uppe
On Mon, Mar 7, 2016 at 5:44 AM, Jan Beulich wrote:
On 04.03.16 at 21:55, wrote:
>>> +case XEN_SYSCTL_LOGLVL_set:
>>> +if ( (op->host.lower_thresh >= 0 && op->host.upper_thresh >= 0 &&
>>> + op->host.lower_thresh > op->host.upper_thresh) ||
>>> + (op->gues
>>> On 04.03.16 at 21:55, wrote:
>> +case XEN_SYSCTL_LOGLVL_set:
>> +if ( (op->host.lower_thresh >= 0 && op->host.upper_thresh >= 0 &&
>> + op->host.lower_thresh > op->host.upper_thresh) ||
>> + (op->guest.lower_thresh >= 0 && op->guest.upper_thresh >= 0 &&
>>
> +static void do_inc_thresh(unsigned char key, struct cpu_user_regs *regs)
> +{
> +++*lower_thresh_adj;
> +do_adj_thresh(key);
> +}
> +
> +static void do_dec_thresh(unsigned char key, struct cpu_user_regs *regs)
> +{
> +if ( *lower_thresh_adj )
> +--*lower_thresh_adj;
> +do
... from serial console and via sysctl so that one doesn't always need
to reboot to see more / less messages.
Note that upper thresholds driven from the serial console are sticky,
i.e. while they get adjusted upwards when the lower threshold would
otherwise end up above the upper one, they don't g
