lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 9 Apr 2019 12:38:29 -0700
From:   Rajat Jain <>
To:     Andy Shevchenko <>
Cc:     Rajneesh Bhardwaj <>,
        Vishwanath Somayaji <>,
        Darren Hart <>,
        Andy Shevchenko <>,
        Platform Driver <>,
        Linux Kernel Mailing List <>,
        Rafael J <>,
        Srinivas Pandruvada <>,
        Furquan Shaikh <>,
        Evan Green <>,
        Rajat Jain <>
Subject: Re: [PATCH v3 2/3] platform/x86: intel_pmc_core: Allow to dump debug
 registers on S0ix failure

On Mon, Apr 8, 2019 at 12:34 PM Andy Shevchenko
<> wrote:
> On Mon, Apr 8, 2019 at 9:58 PM Rajat Jain <> wrote:
> > On Mon, Apr 8, 2019 at 11:41 AM Andy Shevchenko
> > <> wrote:
> > > On Mon, Apr 8, 2019 at 9:36 PM Rajat Jain <> wrote:
> > > Instead of adding module parameter and doing these prints, perhaps
> > > introduce another debugfs node.
> >
> > Uh, I actually did wanted to print them at the resume time in kernel
> > logs, because I think this is something kernel developers would be
> > responsible for debugging and thus would be great to have this
> > included within the kernel logs. User space tools may differ on
> > different distros and may or may not be looking for S0ix failures, and
> > particularly may not dump this new debugfs attribute.
> >
> > The other thing is that seemingly this could also help in situations
> > where debugfs is not configured?
> The keywords above "developers", "debugging",  so, the concept of this
> driver is almost all about debugging, debugfs is not for users or esp.
> user space tools.
> So, I don't see any issue here with creating another node and use it
> for *debugging* whenever it's needed.

Hi Andy,

In the past, we did see random suspend (S0ix) failures after the
devices were released to users (S0ix failures reasons can be a lot so
was not possible to catch all in lab testing). Rajneesh (@Intel) is
aware of the context. In most of these cases, it was very difficult to
reproduce the issue in developer environment, so really difficult to
arrive at what component was causing those failures without these
logs. So I'd still like to make one last request to allow to these
debugs in the kernel at resume time, to make this feature very useful
(it still doesn't change anything for anyone not enabling the module
parameter). However if you still have a strong opinion against this,
I'll add it as a new debugfs attribute in the new re-spin of the

Thanks & Best Regards,


> --
> With Best Regards,
> Andy Shevchenko

Powered by blists - more mailing lists