linux-kernel - Re: [Intel-gfx] agp/intel: can't ioremap flush page

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:	Fri, 07 Mar 2014 18:16:49 +0100
From:	Paul Bolle <pebolle@...cali.nl>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Steven Newbury <steve@...wbury.org.uk>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	David Airlie <airlied@...ux.ie>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Yinghai Lu <yinghai@...nel.org>
Subject: Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset
 flushing

Bjorn Helgaas schreef op vr 07-03-2014 om 09:55 [-0700]:
> On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle <pebolle@...cali.nl> wrote:
> > This might end up not being relevant. And this is surely documented
> > somewhere, but anyhow:
> > - what git magic returns the hashes of the 15 commits that merge commit
> >   96702be56037 added to the tree; and
> 
> "git show 96702be56037" gives:
> 
>     commit 96702be560374ee7e7139a34cab03554129abbb4
>     Merge: 04f982beb900 d56dbf5bab8c
>     ...
> 
> 04f982beb900 is the previous HEAD, d56dbf5bab8c is the head of the
> branch merged by this commit.  "git log 04f982beb900..96702be56037"
> shows the commits merged.

Thanks. Fairly obvious, actually. Not sure why I didn't think of this
myself.

> > - how can I use the list of those hashes to limit the range of commits
> >   to do a git bisect?
> 
> I'm not a git bisect expert, but I *think* you should be able to do
> something like this:
> 
>     git bisect start
>     git bisect bad 96702be56037
>     git bisect good 04f982beb900
> 
> (assuming you've verified that 96702be56037 really *is* bad and
> 04f982beb900 really *is* good), and git should checkout something in
> the middle and you can build and test it, then use "git bisect good"
> or "git bisect bad" depending on the result.

Makes sense. Thanks again. 04f982beb900 appears to be good. So if
96702be56037 turns out to be bad bisecting might not turn into the
ordeal it usually is. (On this machine, with my workflow, bisecting an
v3.x..v3.x+1-rcy range takes a few days.)


Paul Bolle

--
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/