linux-kernel - Re: Regression: USB is nfg after suspend/resume(RAM) cycle on Intel chipset

lists.openwall.net		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, 29 May 2007 10:42:25 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Mark Lord <lkml@....ca>
cc:	Linux Kernel <linux-kernel@...r.kernel.org>,
	Greg KH <gregkh@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Regression: USB is nfg after suspend/resume(RAM) cycle on Intel
 chipset

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