[lkml]   [2007]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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

    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).

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-05-29 19:45    [W:0.023 / U:15.188 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site