Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1199839 > unrolled thread

Re: [PATCH 4/4] watchdog: use suspend/resume interface in fixup_ht_bug()

Started byMichal Hocko <mhocko@kernel.org>
First post2015-08-04 15:40 +0200
Last post2015-08-04 17:10 +0200
Articles 4 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 4/4] watchdog: use suspend/resume interface in  fixup_ht_bug() Michal Hocko <mhocko@kernel.org> - 2015-08-04 15:40 +0200
    Re: [PATCH 4/4] watchdog: use suspend/resume interface in  fixup_ht_bug() Don Zickus <dzickus@redhat.com> - 2015-08-04 16:30 +0200
      Re: [PATCH 4/4] watchdog: use suspend/resume interface in  fixup_ht_bug() Michal Hocko <mhocko@kernel.org> - 2015-08-04 16:50 +0200
      Re: [PATCH 4/4] watchdog: use suspend/resume interface in  fixup_ht_bug() Ulrich Obergfell <uobergfe@redhat.com> - 2015-08-04 17:10 +0200

#1199839 — Re: [PATCH 4/4] watchdog: use suspend/resume interface in fixup_ht_bug()

FromMichal Hocko <mhocko@kernel.org>
Date2015-08-04 15:40 +0200
SubjectRe: [PATCH 4/4] watchdog: use suspend/resume interface in fixup_ht_bug()
Message-ID<pTKBH-3xf-9@gated-at.bofh.it>
On Sat 01-08-15 14:49:25, Ulrich Obergfell wrote:
[...]
> @@ -3368,7 +3368,10 @@ static __init int fixup_ht_bug(void)
>  		return 0;
>  	}
>  
> -	watchdog_nmi_disable_all();
> +	if (watchdog_suspend() != 0) {
> +		pr_info("failed to disable PMU erratum BJ122, BV98, HSD29 workaround\n");
> +		return 0;
> +	}

Is this really worth reporting to the log? What is an admin supposed to
do about it?
<looking into the code>
Ok, so kthread_park fails only when the kernel thread has already
exited. Can this ever happen during this call path?
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1199908

FromDon Zickus <dzickus@redhat.com>
Date2015-08-04 16:30 +0200
Message-ID<pTLo6-4If-15@gated-at.bofh.it>
In reply to#1199839
On Tue, Aug 04, 2015 at 03:31:30PM +0200, Michal Hocko wrote:
> On Sat 01-08-15 14:49:25, Ulrich Obergfell wrote:
> [...]
> > @@ -3368,7 +3368,10 @@ static __init int fixup_ht_bug(void)
> >  		return 0;
> >  	}
> >  
> > -	watchdog_nmi_disable_all();
> > +	if (watchdog_suspend() != 0) {
> > +		pr_info("failed to disable PMU erratum BJ122, BV98, HSD29 workaround\n");
> > +		return 0;
> > +	}
> 
> Is this really worth reporting to the log? What is an admin supposed to
> do about it?

I think it was more for developers to aid in debugging a strange behaviour
of the performance counters.

> <looking into the code>
> Ok, so kthread_park fails only when the kernel thread has already
> exited. Can this ever happen during this call path?

It might be overkill, but it is just a harmless informational failure
message.

Cheers,
Don
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1199925

FromMichal Hocko <mhocko@kernel.org>
Date2015-08-04 16:50 +0200
Message-ID<pTLHs-552-29@gated-at.bofh.it>
In reply to#1199908
On Tue 04-08-15 10:27:50, Don Zickus wrote:
> On Tue, Aug 04, 2015 at 03:31:30PM +0200, Michal Hocko wrote:
> > On Sat 01-08-15 14:49:25, Ulrich Obergfell wrote:
> > [...]
> > > @@ -3368,7 +3368,10 @@ static __init int fixup_ht_bug(void)
> > >  		return 0;
> > >  	}
> > >  
> > > -	watchdog_nmi_disable_all();
> > > +	if (watchdog_suspend() != 0) {
> > > +		pr_info("failed to disable PMU erratum BJ122, BV98, HSD29 workaround\n");
> > > +		return 0;
> > > +	}
> > 
> > Is this really worth reporting to the log? What is an admin supposed to
> > do about it?
> 
> I think it was more for developers to aid in debugging a strange behaviour
> of the performance counters.

pr_debug then?

> > <looking into the code>
> > Ok, so kthread_park fails only when the kernel thread has already
> > exited. Can this ever happen during this call path?
> 
> It might be overkill, but it is just a harmless informational failure
> message.

Maybe we have way too many of those harmless informational failure
admins scratch their heads about...
-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1200014

FromUlrich Obergfell <uobergfe@redhat.com>
Date2015-08-04 17:10 +0200
Message-ID<pTM0R-5Ik-85@gated-at.bofh.it>
In reply to#1199908
> ----- Original Message -----
> From: "Don Zickus" <dzickus@redhat.com>
...
> On Tue, Aug 04, 2015 at 03:31:30PM +0200, Michal Hocko wrote:
>> On Sat 01-08-15 14:49:25, Ulrich Obergfell wrote:
>> [...]
>> > @@ -3368,7 +3368,10 @@ static __init int fixup_ht_bug(void)
>> >  		return 0;
>> >  	}
>> >  
>> > -	watchdog_nmi_disable_all();
>> > +	if (watchdog_suspend() != 0) {
>> > +		pr_info("failed to disable PMU erratum BJ122, BV98, HSD29 workaround\n");
>> > +		return 0;
>> > +	}
>> 
>> Is this really worth reporting to the log? What is an admin supposed to
>> do about it?
>
> I think it was more for developers to aid in debugging a strange behaviour
> of the performance counters.
>
>> <looking into the code>
>> Ok, so kthread_park fails only when the kernel thread has already
>> exited. Can this ever happen during this call path?
>
> It might be overkill, but it is just a harmless informational failure
> message.

Don, Michal,

the module prints a message if the workaround is enabled and if the
workaround is disabled. Hence, I think we should keep the messages
consistent and thus inform the user also if we fail to disable the
workaround. Even though at the moment this seems to be an unlikely
failure case, I agree with Don that the message could be useful in
debugging.

Regards,

Uli
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web