mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mark Lord <lkml@rtr.ca>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	Greg KH <gregkh@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: Regression: USB is nfg after suspend/resume(RAM) cycle on Intel chipset
Date: Tue, 29 May 2007 10:42:25 -0700 (PDT)	[thread overview]
Message-ID: <alpine.LFD.0.98.0705291030390.26602@woody.linux-foundation.org> (raw)
In-Reply-To: <465C5C16.7020001@rtr.ca>



On Tue, 29 May 2007, Mark Lord wrote:
> 
> Ugh.  Is there a way to tell bisect to only work around the USB updates?

Well, you _can_ actually give "git bisect" a pathspec (the same way you 
git "git log" and friends), and tell it to only care about stuff that 
changed that pathspec.

However, that was broken in some older git versions, and in general hasn't 
had a huge amount of testing even in new ones, so I'm a tad nervous about 
recommending people do it. But yes, you should be able to say

	git bisect start drivers/usb/
	git bisect good v2.6.21
	git bisect bad v2.6.22-rc3

and off you go. However, if you do this, you need to make sure that you 
have at LEAST git-1.5.1.

The other downside of path limiting is that if it turns out that the bug 
was really introduced by something else, and just happened to _look_ like 
it's USB-related, the path limiting will then cause "git bisect" to blame 
a commit that just happens to be the next commit after the _real_ bug was 
introduced.

In this case, I don't think it's likely to be an issue, but it *could* 
obviously be something else.

(In contrast, the non-path-limited "git bisect" should work in pretty much 
any situation and with any git version)

> Still, that'll take a few hours, and frankly I'm getting sick of having
> to re-debug the USB layer with each new kernel rev.

Yeah, I'm not surprised. USB is probably the worst possible case for 
suspend/resume (at least if you ignore ACPI-related problems). It's nasty.

> Got a pointer to the "bisect how-to" ?

It's so disgustingly simple that I don't think we've ever done any 
specific bisection tutorial, but the "git-bisect" man-page does exist, and 
it talks about the only half-way interesting case, namely the case where 
the automatic selection of a half-way point causes git to pick a point 
that doesn't work for some other reason (ie stupid compile problem or 
whatever). In which case you have to pick another one manually.

So that kind of gotcha is at least _mentioned_ in the git-bisect man-page, 
even if it doesn't get much further than that.

There's also the git users manual, but I think the man-page is more 
detailed. But for future reference, just do

	git user manual

in google, and press "I'm feeling lucky". It finds the right thing at 
least for me (and at least right now).

			Linus

  parent reply	other threads:[~2007-05-29 17:42 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-29 16:35 Mark Lord
2007-05-29 16:46 ` Linus Torvalds
2007-05-29 17:00   ` Mark Lord
2007-05-29 17:04     ` Mark Lord
2007-05-29 17:07       ` Nish Aravamudan
2007-05-30  7:02         ` Regression: USB is nfg after suspend/resume(RAM) cycle onIntel chipset Romano Giannetti
2007-05-29 17:06     ` Regression: USB is nfg after suspend/resume(RAM) cycle on Intel chipset Nish Aravamudan
2007-05-29 17:47       ` Linus Torvalds
2007-05-29 19:32         ` J. Bruce Fields
2007-05-29 17:42     ` Linus Torvalds [this message]
2007-05-29 17:19   ` Mark Lord
2007-05-29 17:37     ` Mark Lord
2007-05-29 17:54       ` Linus Torvalds
2007-05-29 18:19         ` Mark Lord
2007-05-29 18:28           ` Mark Lord
2007-05-29 18:41       ` Alan Stern
2007-05-29 19:11         ` Mark Lord
2007-05-29 19:22           ` Linus Torvalds
2007-05-29 20:34             ` [PATCH] USB: replace flush_workqueue with cancel_sync_work Alan Stern
2007-05-29 21:19               ` Mark Lord
2007-05-29 20:12           ` Regression: USB is nfg after suspend/resume(RAM) cycle on Intel chipset Alan Stern
2007-05-29 17:03 ` Nish Aravamudan
2007-05-29 17:06   ` Mark Lord

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.0.98.0705291030390.26602@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@rtr.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®