| Message ID | 1391890927.1882.5.camel@x41 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle <pebolle@tiscali.nl> wrote: > Daniel Vetter schreef op za 08-02-2014 om 20:59 [+0100]: >> Hm, if this is really a regression between 3.13 and 3.14-rc1 then I >> don't see any quick candidates - relevant functions in intel-gtt.c >> seem unchanged. >> >> So probably a bisect is what we need here. Note that this could also >> be due to resource handling changes in the driver/pci core, so you >> can't restrict the bisect really. > > The last bisect on this machine took over 20 builds to pinpoint the > offending commit. So that's bad news ... Somehow we can't allocate the flush page resource any more, but I don't have any idea what. There's nothing occupying the old spot (the usual reason why resource management goes boom), so dunno why this doesn't work any more. I think bisecting is the most fruitful avenue here. -Daniel > >> But before going down this route it >> would be worth to check out the resource allocations of both kernels. >> Can you please attach /proc/iomem for both 3.13 and 3.14-rc1 > > The diff between /proc/iomem on v3.13.2 and v3.14-rc1 is: > --- iomem-3.13.2 2014-02-08 21:14:30.214030591 +0100 > +++ iomem-3.14-rc1 2014-02-08 21:07:22.041189158 +0100 > @@ -11,16 +11,13 @@ > 000e0000-000effff : Extension ROM > 000f0000-000fffff : System ROM > 00100000-7f6dffff : System RAM > - 00400000-009af63a : Kernel code > - 009af63b-00c932ff : Kernel data > - 00d4f000-00e4dfff : Kernel bss > + 00400000-009c57bf : Kernel code > + 009c57c0-00cb6aff : Kernel data > + 00d78000-00e74fff : Kernel bss > 7f6e0000-7f6f4fff : ACPI Tables > 7f6f5000-7f6fffff : ACPI Non-volatile Storage > 7f700000-7fffffff : reserved > 7f800000-7fffffff : Graphics Stolen Memory > -80000000-801fffff : PCI Bus 0000:02 > -80200000-8027ffff : 0000:00:02.1 > -80280000-80280fff : Intel Flush Page > a0000000-a003ffff : 0000:00:02.0 > a0040000-a00403ff : 0000:00:1d.7 > a0040000-a00403ff : ehci_hcd > > /proc/iomem for v3.13.2: > 00000000-00000fff : reserved > 00001000-0009efff : System RAM > 0009f000-0009ffff : reserved > 000a0000-000bffff : Video RAM area > 000c0000-000c7fff : Video ROM > 000c8000-000cbfff : pnp 00:00 > 000cf800-000d3fff : reserved > 000cf800-000d0dff : Adapter ROM > 000d1000-000d1fff : Adapter ROM > 000dc000-000fffff : reserved > 000e0000-000effff : Extension ROM > 000f0000-000fffff : System ROM > 00100000-7f6dffff : System RAM > 00400000-009af63a : Kernel code > 009af63b-00c932ff : Kernel data > 00d4f000-00e4dfff : Kernel bss > 7f6e0000-7f6f4fff : ACPI Tables > 7f6f5000-7f6fffff : ACPI Non-volatile Storage > 7f700000-7fffffff : reserved > 7f800000-7fffffff : Graphics Stolen Memory > 80000000-801fffff : PCI Bus 0000:02 > 80200000-8027ffff : 0000:00:02.1 > 80280000-80280fff : Intel Flush Page > a0000000-a003ffff : 0000:00:02.0 > a0040000-a00403ff : 0000:00:1d.7 > a0040000-a00403ff : ehci_hcd > a0040400-a00404ff : 0000:00:1e.2 > a0040400-a00404ff : Intel ICH6 > a0040800-a00409ff : 0000:00:1e.2 > a0040800-a00409ff : Intel ICH6 > a0080000-a00fffff : 0000:00:02.0 > a0100000-a01fffff : PCI Bus 0000:02 > a0100000-a010ffff : 0000:02:00.0 > a0100000-a010ffff : tg3 > a0200000-afffffff : PCI Bus 0000:04 > a0200000-a0200fff : 0000:04:00.0 > a0200000-a0200fff : yenta_socket > a0201000-a02010ff : 0000:04:00.1 > a0201000-a02010ff : mmc0 > a0202000-a0202fff : 0000:04:02.0 > a0202000-a0202fff : ipw2200 > a4000000-a7ffffff : PCI CardBus 0000:05 > c0000000-cfffffff : 0000:00:02.0 > d0000000-d7ffffff : PCI Bus 0000:04 > d0000000-d3ffffff : PCI CardBus 0000:05 > e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff] > e0000000-efffffff : reserved > e0000000-efffffff : pnp 00:01 > f0008000-f000bfff : reserved > f0008000-f000bfff : pnp 00:01 > f000b410-f000b414 : iTCO_wdt > f000b410-f000b414 : iTCO_wdt > fec00000-fec0ffff : reserved > fec00000-fec003ff : IOAPIC 0 > fed14000-fed19fff : reserved > fed14000-fed17fff : pnp 00:01 > fed18000-fed18fff : pnp 00:01 > fed19000-fed19fff : pnp 00:01 > fed20000-fed8ffff : reserved > fee00000-fee00fff : Local APIC > fee00000-fee00fff : reserved > ff000000-ffffffff : reserved > > /proc/iomem for v3.14-rc1: > 00000000-00000fff : reserved > 00001000-0009efff : System RAM > 0009f000-0009ffff : reserved > 000a0000-000bffff : Video RAM area > 000c0000-000c7fff : Video ROM > 000c8000-000cbfff : pnp 00:00 > 000cf800-000d3fff : reserved > 000cf800-000d0dff : Adapter ROM > 000d1000-000d1fff : Adapter ROM > 000dc000-000fffff : reserved > 000e0000-000effff : Extension ROM > 000f0000-000fffff : System ROM > 00100000-7f6dffff : System RAM > 00400000-009c57bf : Kernel code > 009c57c0-00cb6aff : Kernel data > 00d78000-00e74fff : Kernel bss > 7f6e0000-7f6f4fff : ACPI Tables > 7f6f5000-7f6fffff : ACPI Non-volatile Storage > 7f700000-7fffffff : reserved > 7f800000-7fffffff : Graphics Stolen Memory > a0000000-a003ffff : 0000:00:02.0 > a0040000-a00403ff : 0000:00:1d.7 > a0040000-a00403ff : ehci_hcd > a0040400-a00404ff : 0000:00:1e.2 > a0040400-a00404ff : Intel ICH6 > a0040800-a00409ff : 0000:00:1e.2 > a0040800-a00409ff : Intel ICH6 > a0080000-a00fffff : 0000:00:02.0 > a0100000-a01fffff : PCI Bus 0000:02 > a0100000-a010ffff : 0000:02:00.0 > a0100000-a010ffff : tg3 > a0200000-afffffff : PCI Bus 0000:04 > a0200000-a0200fff : 0000:04:00.0 > a0200000-a0200fff : yenta_socket > a0201000-a02010ff : 0000:04:00.1 > a0201000-a02010ff : mmc0 > a0202000-a0202fff : 0000:04:02.0 > a0202000-a0202fff : ipw2200 > a4000000-a7ffffff : PCI CardBus 0000:05 > c0000000-cfffffff : 0000:00:02.0 > d0000000-d7ffffff : PCI Bus 0000:04 > d0000000-d3ffffff : PCI CardBus 0000:05 > e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff] > e0000000-efffffff : reserved > e0000000-efffffff : pnp 00:01 > f0008000-f000bfff : reserved > f0008000-f000bfff : pnp 00:01 > f000b410-f000b414 : iTCO_wdt > f000b410-f000b414 : iTCO_wdt > fec00000-fec0ffff : reserved > fec00000-fec003ff : IOAPIC 0 > fed14000-fed19fff : reserved > fed14000-fed17fff : pnp 00:01 > fed18000-fed18fff : pnp 00:01 > fed19000-fed19fff : pnp 00:01 > fed20000-fed8ffff : reserved > fee00000-fee00fff : Local APIC > fee00000-fee00fff : reserved > ff000000-ffffffff : reserved > > Thanks, > > > Paul Bolle >
On Sun, 2014-02-09 at 01:02 +0100, Daniel Vetter wrote: > On Sat, Feb 8, 2014 at 9:22 PM, Paul Bolle <pebolle@tiscali.nl> wrote: > > Daniel Vetter schreef op za 08-02-2014 om 20:59 [+0100]: > >> Hm, if this is really a regression between 3.13 and 3.14-rc1 then I > >> don't see any quick candidates - relevant functions in intel-gtt.c > >> seem unchanged. > >> > >> So probably a bisect is what we need here. Note that this could also > >> be due to resource handling changes in the driver/pci core, so you > >> can't restrict the bisect really. > > > > The last bisect on this machine took over 20 builds to pinpoint the > > offending commit. So that's bad news ... > > Somehow we can't allocate the flush page resource any more, but I > don't have any idea what. There's nothing occupying the old spot (the > usual reason why resource management goes boom), so dunno why this > doesn't work any more. I think bisecting is the most fruitful avenue > here. > -Daniel > > > > > >> But before going down this route it > >> would be worth to check out the resource allocations of both kernels. > >> Can you please attach /proc/iomem for both 3.13 and 3.14-rc1 > > > > The diff between /proc/iomem on v3.13.2 and v3.14-rc1 is: > > --- iomem-3.13.2 2014-02-08 21:14:30.214030591 +0100 > > +++ iomem-3.14-rc1 2014-02-08 21:07:22.041189158 +0100 > > @@ -11,16 +11,13 @@ > > 000e0000-000effff : Extension ROM > > 000f0000-000fffff : System ROM > > 00100000-7f6dffff : System RAM > > - 00400000-009af63a : Kernel code > > - 009af63b-00c932ff : Kernel data > > - 00d4f000-00e4dfff : Kernel bss > > + 00400000-009c57bf : Kernel code > > + 009c57c0-00cb6aff : Kernel data > > + 00d78000-00e74fff : Kernel bss > > 7f6e0000-7f6f4fff : ACPI Tables > > 7f6f5000-7f6fffff : ACPI Non-volatile Storage > > 7f700000-7fffffff : reserved > > 7f800000-7fffffff : Graphics Stolen Memory > > -80000000-801fffff : PCI Bus 0000:02 > > -80200000-8027ffff : 0000:00:02.1 > > -80280000-80280fff : Intel Flush Page > > a0000000-a003ffff : 0000:00:02.0 > > a0040000-a00403ff : 0000:00:1d.7 > > a0040000-a00403ff : ehci_hcd > > > > /proc/iomem for v3.13.2: > > 00000000-00000fff : reserved > > 00001000-0009efff : System RAM > > 0009f000-0009ffff : reserved > > 000a0000-000bffff : Video RAM area > > 000c0000-000c7fff : Video ROM > > 000c8000-000cbfff : pnp 00:00 > > 000cf800-000d3fff : reserved > > 000cf800-000d0dff : Adapter ROM > > 000d1000-000d1fff : Adapter ROM > > 000dc000-000fffff : reserved > > 000e0000-000effff : Extension ROM > > 000f0000-000fffff : System ROM > > 00100000-7f6dffff : System RAM > > 00400000-009af63a : Kernel code > > 009af63b-00c932ff : Kernel data > > 00d4f000-00e4dfff : Kernel bss > > 7f6e0000-7f6f4fff : ACPI Tables > > 7f6f5000-7f6fffff : ACPI Non-volatile Storage > > 7f700000-7fffffff : reserved > > 7f800000-7fffffff : Graphics Stolen Memory > > 80000000-801fffff : PCI Bus 0000:02 > > 80200000-8027ffff : 0000:00:02.1 > > 80280000-80280fff : Intel Flush Page > > a0000000-a003ffff : 0000:00:02.0 > > a0040000-a00403ff : 0000:00:1d.7 > > a0040000-a00403ff : ehci_hcd > > a0040400-a00404ff : 0000:00:1e.2 > > a0040400-a00404ff : Intel ICH6 > > a0040800-a00409ff : 0000:00:1e.2 > > a0040800-a00409ff : Intel ICH6 > > a0080000-a00fffff : 0000:00:02.0 > > a0100000-a01fffff : PCI Bus 0000:02 > > a0100000-a010ffff : 0000:02:00.0 > > a0100000-a010ffff : tg3 > > a0200000-afffffff : PCI Bus 0000:04 > > a0200000-a0200fff : 0000:04:00.0 > > a0200000-a0200fff : yenta_socket > > a0201000-a02010ff : 0000:04:00.1 > > a0201000-a02010ff : mmc0 > > a0202000-a0202fff : 0000:04:02.0 > > a0202000-a0202fff : ipw2200 > > a4000000-a7ffffff : PCI CardBus 0000:05 > > c0000000-cfffffff : 0000:00:02.0 > > d0000000-d7ffffff : PCI Bus 0000:04 > > d0000000-d3ffffff : PCI CardBus 0000:05 > > e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff] > > e0000000-efffffff : reserved > > e0000000-efffffff : pnp 00:01 > > f0008000-f000bfff : reserved > > f0008000-f000bfff : pnp 00:01 > > f000b410-f000b414 : iTCO_wdt > > f000b410-f000b414 : iTCO_wdt > > fec00000-fec0ffff : reserved > > fec00000-fec003ff : IOAPIC 0 > > fed14000-fed19fff : reserved > > fed14000-fed17fff : pnp 00:01 > > fed18000-fed18fff : pnp 00:01 > > fed19000-fed19fff : pnp 00:01 > > fed20000-fed8ffff : reserved > > fee00000-fee00fff : Local APIC > > fee00000-fee00fff : reserved > > ff000000-ffffffff : reserved > > > > /proc/iomem for v3.14-rc1: > > 00000000-00000fff : reserved > > 00001000-0009efff : System RAM > > 0009f000-0009ffff : reserved > > 000a0000-000bffff : Video RAM area > > 000c0000-000c7fff : Video ROM > > 000c8000-000cbfff : pnp 00:00 > > 000cf800-000d3fff : reserved > > 000cf800-000d0dff : Adapter ROM > > 000d1000-000d1fff : Adapter ROM > > 000dc000-000fffff : reserved > > 000e0000-000effff : Extension ROM > > 000f0000-000fffff : System ROM > > 00100000-7f6dffff : System RAM > > 00400000-009c57bf : Kernel code > > 009c57c0-00cb6aff : Kernel data > > 00d78000-00e74fff : Kernel bss > > 7f6e0000-7f6f4fff : ACPI Tables > > 7f6f5000-7f6fffff : ACPI Non-volatile Storage > > 7f700000-7fffffff : reserved > > 7f800000-7fffffff : Graphics Stolen Memory > > a0000000-a003ffff : 0000:00:02.0 > > a0040000-a00403ff : 0000:00:1d.7 > > a0040000-a00403ff : ehci_hcd > > a0040400-a00404ff : 0000:00:1e.2 > > a0040400-a00404ff : Intel ICH6 > > a0040800-a00409ff : 0000:00:1e.2 > > a0040800-a00409ff : Intel ICH6 > > a0080000-a00fffff : 0000:00:02.0 > > a0100000-a01fffff : PCI Bus 0000:02 > > a0100000-a010ffff : 0000:02:00.0 > > a0100000-a010ffff : tg3 > > a0200000-afffffff : PCI Bus 0000:04 > > a0200000-a0200fff : 0000:04:00.0 > > a0200000-a0200fff : yenta_socket > > a0201000-a02010ff : 0000:04:00.1 > > a0201000-a02010ff : mmc0 > > a0202000-a0202fff : 0000:04:02.0 > > a0202000-a0202fff : ipw2200 > > a4000000-a7ffffff : PCI CardBus 0000:05 > > c0000000-cfffffff : 0000:00:02.0 > > d0000000-d7ffffff : PCI Bus 0000:04 > > d0000000-d3ffffff : PCI CardBus 0000:05 > > e0000000-efffffff : PCI MMCONFIG 0000 [bus 00-ff] > > e0000000-efffffff : reserved > > e0000000-efffffff : pnp 00:01 > > f0008000-f000bfff : reserved > > f0008000-f000bfff : pnp 00:01 > > f000b410-f000b414 : iTCO_wdt > > f000b410-f000b414 : iTCO_wdt > > fec00000-fec0ffff : reserved > > fec00000-fec003ff : IOAPIC 0 > > fed14000-fed19fff : reserved > > fed14000-fed17fff : pnp 00:01 > > fed18000-fed18fff : pnp 00:01 > > fed19000-fed19fff : pnp 00:01 > > fed20000-fed8ffff : reserved > > fee00000-fee00fff : Local APIC > > fee00000-fee00fff : reserved > > ff000000-ffffffff : reserved > > > > Thanks, > > > > > > Paul Bolle > > > > > PCI resource allocation is undergoing some changes at the moment, it's definitely a bug if the Flush Page isn't getting allocated. I'm looking forward to hopefully getting pci_bus_alloc_resource_fit() behaviour in mainline, it will provide much better resource allocation in the 32 bit PCI address space, and prevent problems like this from cropping up. See Yinghai Lu's for-pci-res-alloc branch. I've been carrying the changes in my local tree, but right now the upstream PCI changes are quite extensive. He's planning on rebasing the branch soon.
On Sun, 2014-02-09 at 13:15 +0000, Steven Newbury wrote: > PCI resource allocation is undergoing some changes at the moment, it's > definitely a bug if the Flush Page isn't getting allocated. I'm looking > forward to hopefully getting pci_bus_alloc_resource_fit() behaviour in > mainline, it will provide much better resource allocation in the 32 bit > PCI address space, and prevent problems like this from cropping up. > > See Yinghai Lu's for-pci-res-alloc branch. > > I've been carrying the changes in my local tree, but right now the > upstream PCI changes are quite extensive. He's planning on rebasing the > branch soon. Does this mean I might be better of not bisecting this just yet? Or are these changes targeted at v3.15 (or later)? Paul Bolle
On Sun, 2014-02-09 at 14:25 +0100, Paul Bolle wrote: > On Sun, 2014-02-09 at 13:15 +0000, Steven Newbury wrote: > > PCI resource allocation is undergoing some changes at the moment, it's > > definitely a bug if the Flush Page isn't getting allocated. I'm looking > > forward to hopefully getting pci_bus_alloc_resource_fit() behaviour in > > mainline, it will provide much better resource allocation in the 32 bit > > PCI address space, and prevent problems like this from cropping up. > > > > See Yinghai Lu's for-pci-res-alloc branch. > > > > I've been carrying the changes in my local tree, but right now the > > upstream PCI changes are quite extensive. He's planning on rebasing the > > branch soon. > > Does this mean I might be better of not bisecting this just yet? Or are > these changes targeted at v3.15 (or later)? > > > Paul Bolle > It's an aside really for now. The bug has probably been introduced by the recent pci allocation changes so it should be easier for you to bisect, hopefully.
On Sun, Feb 9, 2014 at 6:25 AM, Paul Bolle <pebolle@tiscali.nl> wrote: > On Sun, 2014-02-09 at 13:15 +0000, Steven Newbury wrote: >> PCI resource allocation is undergoing some changes at the moment, it's >> definitely a bug if the Flush Page isn't getting allocated. I'm looking >> forward to hopefully getting pci_bus_alloc_resource_fit() behaviour in >> mainline, it will provide much better resource allocation in the 32 bit >> PCI address space, and prevent problems like this from cropping up. >> >> See Yinghai Lu's for-pci-res-alloc branch. >> >> I've been carrying the changes in my local tree, but right now the >> upstream PCI changes are quite extensive. He's planning on rebasing the >> branch soon. > > Does this mean I might be better of not bisecting this just yet? Or are > these changes targeted at v3.15 (or later)? Yinghai's changes would probably be in v3.15 or later. Can you open a kernel.org bugzilla report and attach complete dmesg logs of the working and broken kernels to it? There might be more useful resource-related messages from the PCI core. I wouldn't start bisecting yet, but if you're in the mood, this commit: 96702be56037 "Merge branch 'pci/resource' into next" looks like a good place to start, so you could try the pre-merge commit: 04f982beb900 "Merge branch 'pci/msi' into next". If 04f982beb900 is good, there are only about 15 commits on the pci/resource branch to look at. Thanks for the report! Bjorn
Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]: > Can you open a kernel.org bugzilla report and attach complete dmesg > logs of the working and broken kernels to it? There might be more > useful resource-related messages from the PCI core. That took me quite a bit longer than I hoped, but I finally opened a report at https://bugzilla.kernel.org/show_bug.cgi?id=71611 . Note that the dmesg's are identical (up to that error). Are you still interested? > I wouldn't start bisecting yet, but if you're in the mood, this > commit: 96702be56037 "Merge branch 'pci/resource' into next" looks > like a good place to start, so you could try the pre-merge commit: > 04f982beb900 "Merge branch 'pci/msi' into next". If 04f982beb900 is > good, there are only about 15 commits on the pci/resource branch to > look at. I hope to do a bisect in the next few days. If that bisect pinpoints an interesting commit that might just be in time for v3.14. Paul Bolle
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle <pebolle@tiscali.nl> wrote: > Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]: >> Can you open a kernel.org bugzilla report and attach complete dmesg >> logs of the working and broken kernels to it? There might be more >> useful resource-related messages from the PCI core. > > That took me quite a bit longer than I hoped, but I finally opened a > report at > https://bugzilla.kernel.org/show_bug.cgi?id=71611 . > > Note that the dmesg's are identical (up to that error). Are you still > interested? Yep, I wouldn't mind seeing the dmesg log to compare with the /proc/iomem contents you posted earlier. Since they're identical, there might not be a clue, but you never know, and it would be really great to squash this regression before v3.14. >> I wouldn't start bisecting yet, but if you're in the mood, this >> commit: 96702be56037 "Merge branch 'pci/resource' into next" looks >> like a good place to start, so you could try the pre-merge commit: >> 04f982beb900 "Merge branch 'pci/msi' into next". If 04f982beb900 is >> good, there are only about 15 commits on the pci/resource branch to >> look at. > > I hope to do a bisect in the next few days. If that bisect pinpoints an > interesting commit that might just be in time for v3.14. > > > Paul Bolle >
Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]: > I wouldn't start bisecting yet, but if you're in the mood, this > commit: 96702be56037 "Merge branch 'pci/resource' into next" looks > like a good place to start, so you could try the pre-merge commit: > 04f982beb900 "Merge branch 'pci/msi' into next". If 04f982beb900 is > good, there are only about 15 commits on the pci/resource branch to > look at. 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 - how can I use the list of those hashes to limit the range of commits to do a git bisect? Paul Bolle
On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle <pebolle@tiscali.nl> wrote: > Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]: >> I wouldn't start bisecting yet, but if you're in the mood, this >> commit: 96702be56037 "Merge branch 'pci/resource' into next" looks >> like a good place to start, so you could try the pre-merge commit: >> 04f982beb900 "Merge branch 'pci/msi' into next". If 04f982beb900 is >> good, there are only about 15 commits on the pci/resource branch to >> look at. > > 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. > - 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. Bjorn
Bjorn Helgaas schreef op vr 07-03-2014 om 09:55 [-0700]: > On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle <pebolle@tiscali.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
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle <pebolle@tiscali.nl> wrote: > Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]: >> Can you open a kernel.org bugzilla report and attach complete dmesg >> logs of the working and broken kernels to it? There might be more >> useful resource-related messages from the PCI core. > > That took me quite a bit longer than I hoped, but I finally opened a > report at > https://bugzilla.kernel.org/show_bug.cgi?id=71611 . > > Note that the dmesg's are identical (up to that error). Are you still > interested? Thanks for attaching the dmesg log. I also attached the iomem contents you previously posted. This is likely a tangent from the AGP issue, but I don't understand this iomem diff between v3.13.2 and v3.14-rc1: -80000000-801fffff : PCI Bus 0000:02 -80200000-8027ffff : 0000:00:02.1 The first line is a bridge window to [bus 02], and the second is an MMIO region for one of your AGP devices (00:02.0 is VGA and 00:02.1 seems to be some related device). The bridge to [bus 02] is 00:1c.0, and your dmesg shows: pci 0000:00:1c.0: PCI bridge to [bus 02] pci 0000:00:1c.0: bridge window [io 0x6000-0x6fff] pci 0000:00:1c.0: bridge window [mem 0xa0100000-0xa01fffff] The [mem 0xa0100000-0xa01fffff] window appears in the dmesg log and in both iomem captures; that makes good sense. The 80000000-801fffff window is in only the v3.13.2 iomem, and it *should* appear in the v3.13.2 dmesg log but apparently doesn't? Likewise, the 00:02.1 resource appears only in the v3.13.2 iomem, and it should also be mentioned in the v3.13.2 dmesg log. The v3.14-rc5 dmesg log shows an unassigned resource there: pci 0000:00:02.1: reg 0x10: [mem 0x00000000-0x0007ffff] and says we were unable to assign anything. But apparently v3.13.2 *did* assign something, and the dmesg log should show that. Bjorn
--- iomem-3.13.2 2014-02-08 21:14:30.214030591 +0100 +++ iomem-3.14-rc1 2014-02-08 21:07:22.041189158 +0100 @@ -11,16 +11,13 @@ 000e0000-000effff : Extension ROM 000f0000-000fffff : System ROM 00100000-7f6dffff : System RAM - 00400000-009af63a : Kernel code - 009af63b-00c932ff : Kernel data - 00d4f000-00e4dfff : Kernel bss + 00400000-009c57bf : Kernel code + 009c57c0-00cb6aff : Kernel data + 00d78000-00e74fff : Kernel bss 7f6e0000-7f6f4fff : ACPI Tables 7f6f5000-7f6fffff : ACPI Non-volatile Storage 7f700000-7fffffff : reserved 7f800000-7fffffff : Graphics Stolen Memory -80000000-801fffff : PCI Bus 0000:02 -80200000-8027ffff : 0000:00:02.1 -80280000-80280fff : Intel Flush Page a0000000-a003ffff : 0000:00:02.0 a0040000-a00403ff : 0000:00:1d.7 a0040000-a00403ff : ehci_hcd