Found a problem so what next?

Found a problem so what next?

[John Whitmore]

I built and installed v4.4 on my laptop but Suspend no longer worked so I set
about doing a git bisect to find the source of the problem. I've never had
cause to use bisect before so if nothing else I'll have learned something. 

Anyhow got to an end point in git bisect of:

john at bamboo:> git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[b8b2c7d845d57f7a4b9f1f941f24728165e27626] base/platform: assert that dev_pm_domain callbacks are called unconditionally

I was actually chuffed I got that far and it took a while as I was doing a
"make mrproper" each time. I sort of assumed that I could just bisect and do a
make, which would work out what it had to recompile, but then thought maybe
that was a bit of an assumption. Be a shame to do all that work and find out
you had to clean up a bit between builds.

I'm sure that this problem has been found and a patch submitted by now as it
seems to have been from months ago. But assuming neither had occured and this
was a new discovery how do you check for a reported bug? Do you search mailing
list for that commit number, or a part of that commit number?

I read BUG-HUNTING in the documentation and it does mention:

"Before you submit a bug report read REPORTING-BUGS."

but can't see that document and it's not a section of BUG_HUNTING document. 

So what would the next step be? I'm sure fixing it would be one posibility but
I've never looked at power management code so I'm not the person that should
be let lose in there ;-)

I had a look in journalctl but nothing in there suggests what the actual error
is. I'll have a look at the log files some more and see if I can't get some
sort of clue which would provide more info.

Found a problem so what next?

[Greg KH]

On Mon, Jan 18, 2016 at 05:34:32PM +0000, John Whitmore wrote:
> I built and installed v4.4 on my laptop but Suspend no longer worked so I set
> about doing a git bisect to find the source of the problem. I've never had
> cause to use bisect before so if nothing else I'll have learned something. 
> 
> Anyhow got to an end point in git bisect of:
> 
> john at bamboo:> git bisect bad
> Bisecting: 0 revisions left to test after this (roughly 0 steps)
> [b8b2c7d845d57f7a4b9f1f941f24728165e27626] base/platform: assert that dev_pm_domain callbacks are called unconditionally
> 
> I was actually chuffed I got that far and it took a while as I was doing a
> "make mrproper" each time. I sort of assumed that I could just bisect and do a
> make, which would work out what it had to recompile, but then thought maybe
> that was a bit of an assumption. Be a shame to do all that work and find out
> you had to clean up a bit between builds.

You don't have to, a simple 'make oldconfig' and 'make' should do just
fine.

> I'm sure that this problem has been found and a patch submitted by now as it
> seems to have been from months ago. But assuming neither had occured and this
> was a new discovery how do you check for a reported bug? Do you search mailing
> list for that commit number, or a part of that commit number?

Yes, this bug has been found, and a fix was submitted, I just haven't
taken it yet, sorry.  I will do so after 4.5-rc1 is out.  If you search
the linux-kernel mailing list for:
	Subject: [PATCH] base/platform: Fix platform drivers with no probe callback (ex alarmtimer)

you can find the fix.

Sorry you hit this, I'll get it merged soon.

greg k-h

Found a problem so what next?

[Bjørn Mork]

John Whitmore <arigead@gmail.com> writes:

 I'm sure that this problem has been found and a patch submitted by now as it
> seems to have been from months ago. But assuming neither had occured and this
> was a new discovery how do you check for a reported bug? Do you search mailing
> list for that commit number, or a part of that commit number?

I cannot tell you what the best practice is, but at least that's what I
do.

Googling for a fix is usually pretty accurate once the problematic
commit has been found.  Both the short title and the 12 digit commit ID
should work, because they are included in the "Fixes" tag of the fix.

Unfortunately Googling isn't as accurate before you know the buggy
commit. In an ideal world, you should be able to find the fix based on
the symptoms described in the commit message. But this doesn't work well
for symptoms which occur frequently and with varying causes. "suspend
failing" is definitely one of those...

And yes, it is common to discover what you did: The bug is already found
and fixed, but the fix hasn't propagated yet. That can be a bit
demotivating until you realize the beauty of a system where someone else
already fixed your problem and documented the fix in a public "bug
database" :)


Bj?rn

Found a problem so what next?

[John Whitmore]

On Mon, Jan 18, 2016 at 11:36:25PM -0800, Greg KH wrote:
> On Mon, Jan 18, 2016 at 05:34:32PM +0000, John Whitmore wrote:
> > I built and installed v4.4 on my laptop but Suspend no longer worked so I set
> > about doing a git bisect to find the source of the problem. I've never had
> > cause to use bisect before so if nothing else I'll have learned something. 
> > 
> > Anyhow got to an end point in git bisect of:
> > 
> > john at bamboo:> git bisect bad
> > Bisecting: 0 revisions left to test after this (roughly 0 steps)
> > [b8b2c7d845d57f7a4b9f1f941f24728165e27626] base/platform: assert that dev_pm_domain callbacks are called unconditionally
> > 
> > I was actually chuffed I got that far and it took a while as I was doing a
> > "make mrproper" each time. I sort of assumed that I could just bisect and do a
> > make, which would work out what it had to recompile, but then thought maybe
> > that was a bit of an assumption. Be a shame to do all that work and find out
> > you had to clean up a bit between builds.
> 
> You don't have to, a simple 'make oldconfig' and 'make' should do just
> fine.
> 
> > I'm sure that this problem has been found and a patch submitted by now as it
> > seems to have been from months ago. But assuming neither had occured and this
> > was a new discovery how do you check for a reported bug? Do you search mailing
> > list for that commit number, or a part of that commit number?
> 
> Yes, this bug has been found, and a fix was submitted, I just haven't
> taken it yet, sorry.  I will do so after 4.5-rc1 is out.  If you search
> the linux-kernel mailing list for:
> 	Subject: [PATCH] base/platform: Fix platform drivers with no probe callback (ex alarmtimer)
> 
> you can find the fix.
> 
> Sorry you hit this, I'll get it merged soon.
> 

Hey not at all, I'm glad I did hit the problem. I'm re-reading LDD for probably
the third time and soaking up a little bit more, before I start work on a USB
driver. I was glad of the distraction and happy to try see if I could find the
source of the problem. If I wasn't busy I might even try and see if I could
debug it and get my own fix, just for the exercise and learning. Who knows
maybe it'll be a slow weekend ;-)


> greg k-h

Found a problem so what next?

[John Whitmore]

On Tue, Jan 19, 2016 at 10:50:32AM +0100, Bj?rn Mork wrote:
> John Whitmore <arigead@gmail.com> writes:
> 
>  I'm sure that this problem has been found and a patch submitted by now as it
> > seems to have been from months ago. But assuming neither had occured and this
> > was a new discovery how do you check for a reported bug? Do you search mailing
> > list for that commit number, or a part of that commit number?
> 
> I cannot tell you what the best practice is, but at least that's what I
> do.
> 
> Googling for a fix is usually pretty accurate once the problematic
> commit has been found.  Both the short title and the 12 digit commit ID
> should work, because they are included in the "Fixes" tag of the fix.
> 

Thanks a million I just did a search for the 12 digit commit ID and found the
discussion on the mailing list. Most of it over my head but thanks for the
information. 


> Unfortunately Googling isn't as accurate before you know the buggy
> commit. In an ideal world, you should be able to find the fix based on
> the symptoms described in the commit message. But this doesn't work well
> for symptoms which occur frequently and with varying causes. "suspend
> failing" is definitely one of those...
> 
> And yes, it is common to discover what you did: The bug is already found
> and fixed, but the fix hasn't propagated yet. That can be a bit
> demotivating until you realize the beauty of a system where someone else
> already fixed your problem and documented the fix in a public "bug
> database" :)
> 
> 
> Bj?rn