Boot problems with a PA6T board

Hi All,

The RC 1, 2, and 3 of the kernel 3.15 don't boot on my PA6T board with a Radeon HD 6870 graphics card.

Screenshot:
http://forum.hyperion-entertainment.biz/download/file.php?id=1060&mode=view

The kernel 3.14 starts without any problems. Has anyone a tip for me, please?

Quoted 10 lines · Christian Zigotzky

Hi All,

The RC 1, 2, and 3 of the kernel 3.15 don't boot on my PA6T board with a Radeon HD 6870 graphics card.

Screenshot:
http://forum.hyperion-entertainment.biz/download/file.php?id=1060&mode=view

The kernel 3.14 starts without any problems. Has anyone a tip for me, please?

The line that says "starting cpu hw idx 0... failed" looks a little worrying. Do you see that on 3.14 as well?

Otherwise bisection is probably your best bet.

cheers

Quoted 8 lines · Christian Zigotzky

Hi All,

The RC 1, 2, and 3 of the kernel 3.15 don't boot on my PA6T board with a Radeon HD 6870 graphics card.

Screenshot:
http://forum.hyperion-entertainment.biz/download/file.php?id=1060&mode=view

Quoted 2 lines

The kernel 3.14 starts without any problems. Has anyone a tip for me, please?

The line that says "starting cpu hw idx 0... failed" looks a little worrying. Do you see that on 3.14 as well?

Otherwise bisection is probably your best bet.

cheers

Quoted 14 lines · Michael Ellerman

Quoted 10 lines · Christian Zigotzky

Hi All,

The RC 1, 2, and 3 of the kernel 3.15 don't boot on my PA6T board with a Radeon HD 6870 graphics card.

Screenshot:
http://forum.hyperion-entertainment.biz/download/file.php?id=1060&mode=view

The kernel 3.14 starts without any problems. Has anyone a tip for me, please?

The line that says "starting cpu hw idx 0... failed" looks a little worrying. Do you see that on 3.14 as well?

Quoted 1 line

Otherwise bisection is probably your best bet.

Hi All,

I have found out which patch is responsible for the boot problems. It's patch 9000c17dc0f9c910267d2661225c9d33a227b27e. Link:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9000c17dc0f9c910267d2661225c9d33a227b27e

Experimental protocol:

git checkout -f 01d8885785a60ae8f4c37b0ed75bdc96d0fc6a44; git clean -fdx (from 02/04/14) -> Kernel boots
git checkout -f f1553174a207f68a4ec19d436003097e0a4dc405; git clean -fdx (from 03/04/14) -> Kernel boots
git checkout -f d40326f4b9f9617cdfd30f83a2db57d47e9c5bac; git clean -fdx (from 04/04/14) -> Kernel boots
git checkout -f 930b440cd8256f3861bdb0a59d26efaadac7941a; git clean -fdx (from 05/04/14) -> doesn't boot (rtc error)
git checkout -f 2b3a8fd735f86ebeb2b9d061054003000c36b654; git clean -fdx (from 06/04/14) -> doesn't boot (rtc error)
git checkout -f 26c12d93348f0bda0756aff83f4867d9ae58a5a6; git clean -fdx (from 07/04/14) -> doesn't boot (rtc error)
git checkout -f a6c8aff022d4d06e4b41455ae9b2a5d3d503bf76; git clean -fdx (from 08/04/14) -> Kernel boots
git checkout -f 035328c202d26a824b8632fd3b00635db5aee5a2; git clean -fdx (from 08/04/14) -> Kernel boots

git checkout -f 9000c17dc0f9c910267d2661225c9d33a227b27e; git clean -fdx (from 08/04/14) powerpc/powernv: Fix endian issues with sensor code One OPAL call and one device tree property needed byte swapping. -> doesn't boot (prom_init)
git checkout -f d3d35d957a9d0733dc51f14b5abc0bff5d3c5f3a; git clean -fdx (from 08/04/14) -> doesn't boot (prom_init)
git checkout -f c4586256f0c440bc2bdb29d2cbb915f0ca785d26; git clean -fdx (from 09/04/14) -> doesn't boot (prom_init)

I'm not a programmer but what can I do to solve this boot problem?

Hi Christian,

I'm almost certain that is not the commit which breaks your machine. Or if it is, something *really* weird is going on.

The code changed in that commit should never run on a PA6T.

Quoted 18 lines

Experimental protocol:

git checkout -f 01d8885785a60ae8f4c37b0ed75bdc96d0fc6a44; git clean -fdx (from 02/04/14) -> Kernel boots
git checkout -f f1553174a207f68a4ec19d436003097e0a4dc405; git clean -fdx (from 03/04/14) -> Kernel boots
git checkout -f d40326f4b9f9617cdfd30f83a2db57d47e9c5bac; git clean -fdx (from 04/04/14) -> Kernel boots
git checkout -f 930b440cd8256f3861bdb0a59d26efaadac7941a; git clean -fdx (from 05/04/14) -> doesn't boot (rtc error)
git checkout -f 2b3a8fd735f86ebeb2b9d061054003000c36b654; git clean -fdx (from 06/04/14) -> doesn't boot (rtc error)
git checkout -f 26c12d93348f0bda0756aff83f4867d9ae58a5a6; git clean -fdx (from 07/04/14) -> doesn't boot (rtc error)
git checkout -f a6c8aff022d4d06e4b41455ae9b2a5d3d503bf76; git clean -fdx (from 08/04/14) -> Kernel boots
git checkout -f 035328c202d26a824b8632fd3b00635db5aee5a2; git clean -fdx (from 08/04/14) -> Kernel boots

Quoted 8 lines

git checkout -f 9000c17dc0f9c910267d2661225c9d33a227b27e; git clean -fdx (from 08/04/14) powerpc/powernv: Fix endian issues with sensor code One OPAL call and one device tree property needed byte swapping. -> doesn't boot (prom_init)
git checkout -f d3d35d957a9d0733dc51f14b5abc0bff5d3c5f3a; git clean -fdx (from 08/04/14) -> doesn't boot (prom_init)
git checkout -f c4586256f0c440bc2bdb29d2cbb915f0ca785d26; git clean -fdx (from 09/04/14) -> doesn't boot (prom_init)

So it looks like you manually picked commits based on the date?

That's a good start, but if you want to find the actual problem commit you need to do a proper bisect.

Quoted 1 line

I'm not a programmer but what can I do to solve this boot problem?

To start with you can probably narrow it down a bit by testing the following commits:

18a1a7a1d862ae0794a0179473d08a414dd49234 <- It doesn't boot. Error messages: Oops: Machine check, sig: 7 [#1] CPU: 1 PID: 1 Comm: swapper/0 not tainted

d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b <- It boots. :-)

0f5a869600141a0d5575e3190af01a050c081b07 <- It boots. :-)

c7e64b9ce04aa2e3fad7396d92b5cb92056d16ac <- It boots. :-)

d3e144532703fe2454b56eddb56f30d2d620187b <- It boots. :-)

Hi Michael,

Thanks a lot for your answer.

...

18a1a7a1d862ae0794a0179473d08a414dd49234 <- It doesn't boot. Error messages: Oops: Machine check, sig: 7 [#1] CPU: 1 PID: 1 Comm: swapper/0 not tainted d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b <- It boots. :-)
0f5a869600141a0d5575e3190af01a050c081b07 <- It boots. :-)
c7e64b9ce04aa2e3fad7396d92b5cb92056d16ac <- It boots. :-)
d3e144532703fe2454b56eddb56f30d2d620187b <- It boots. :-)

I think the machine check is the problem.

Quoted 12 lines · Christian Zigotzky

Hi Michael,

Thanks a lot for your answer.

...

18a1a7a1d862ae0794a0179473d08a414dd49234 <- It doesn't boot. Error messages: Oops: Machine check, sig: 7 [#1] CPU: 1 PID: 1 Comm: swapper/0 not tainted d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b <- It boots. :-)
0f5a869600141a0d5575e3190af01a050c081b07 <- It boots. :-)
c7e64b9ce04aa2e3fad7396d92b5cb92056d16ac <- It boots. :-)
d3e144532703fe2454b56eddb56f30d2d620187b <- It boots. :-)

Quoted 1 line

I think the machine check is the problem.

Yes I think it is. Do you get any more info, or just that one line?

So I think the latest working commit we have is d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b.

I'm going to guess that cd427485357c0c4b99f69719251baacf25946e11 is BAD. Can you please confirm or deny that?

Assuming cd42748 is bad, you should do a git bisect between it and 18a1a7a. That should be a fairly quick bisect. That would be:

$ git bisect start
$ git bisect good d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b
$ git bisect bad  cd427485357c0c4b99f69719251baacf25946e11

If cd42748 is *good*, then you'll need to do a bigger bisect from d8ff9cd to 18a1a7a.

cheers

Hi Michael,

Thank you for your answer and thank you for your help. :-)

Quoted 18 lines · Michael Ellerman

Quoted 6 lines · Christian Zigotzky

Hi Michael,

Thanks a lot for your answer.

...

Quoted 7 lines

18a1a7a1d862ae0794a0179473d08a414dd49234 <- It doesn't boot. Error messages: Oops: Machine check, sig: 7 [#1] CPU: 1 PID: 1 Comm: swapper/0 not tainted d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b <- It boots. :-)
0f5a869600141a0d5575e3190af01a050c081b07 <- It boots. :-)
c7e64b9ce04aa2e3fad7396d92b5cb92056d16ac <- It boots. :-)
d3e144532703fe2454b56eddb56f30d2d620187b <- It boots. :-)

I think the machine check is the problem.

Yes I think it is. Do you get any more info, or just that one line?

So I think the latest working commit we have is d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b.

Quoted 2 lines

I'm going to guess that cd427485357c0c4b99f69719251baacf25946e11 is BAD. Can you please confirm or deny that?

It's not BAD. It boots.

Rgds,

Christian

Quoted 10 lines

Assuming cd42748 is bad, you should do a git bisect between it and 18a1a7a. That should be a fairly quick bisect. That would be:

$ git bisect start
$ git bisect good d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b
$ git bisect bad  cd427485357c0c4b99f69719251baacf25946e11

If cd42748 is *good*, then you'll need to do a bigger bisect from d8ff9cd to 18a1a7a.

Quoted 6 lines

cheers

Quoted 4 lines · Christian Zigotzky

Hi Michael,

Thank you for your answer and thank you for your help. :-)

Quoted 8 lines · Michael Ellerman

Quoted 5 lines · Christian Zigotzky

I'm going to guess that cd427485357c0c4b99f69719251baacf25946e11 is BAD. Can
you please confirm or deny that?

It's not BAD. It boots.

Quoted 3 lines

Quoted 3 lines

If cd42748 is *good*, then you'll need to do a bigger bisect from d8ff9cd to
18a1a7a.

OK :-)

-> git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux2-git -> git bisect start
-> git bisect good d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b
-> git bisect bad 18a1a7a1d862ae0794a0179473d08a414dd49234

Output:
Bisecting: 5900 revisions left to test after this (roughly 13 steps) [cb1595563880a81dab6eab9a5ecb4520d2e76077] Merge tag 'tty-3.15-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

Unfortunately it doesn't boot. :-(

Quoted 5 lines · Christian Zigotzky

Quoted 4 lines · Christian Zigotzky

Hi Michael,

Thank you for your answer and thank you for your help. :-)

Quoted 7 lines

Quoted 7 lines · Michael Ellerman

Quoted 5 lines · Christian Zigotzky

I'm going to guess that cd427485357c0c4b99f69719251baacf25946e11 is BAD. Can
you please confirm or deny that?

It's not BAD. It boots.

Hmm, interesting.

Quoted 16 lines

Quoted 3 lines

Quoted 3 lines

If cd42748 is *good*, then you'll need to do a bigger bisect from d8ff9cd to
18a1a7a.

OK :-)

-> git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux2-git -> git bisect start
-> git bisect good d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b
-> git bisect bad 18a1a7a1d862ae0794a0179473d08a414dd49234

Output:
Bisecting: 5900 revisions left to test after this (roughly 13 steps) [cb1595563880a81dab6eab9a5ecb4520d2e76077] Merge tag 'tty-3.15-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

Quoted 1 line

Unfortunately it doesn't boot. :-(

OK. So you do:

$ git bisect bad

And it will pick a new commit for you to test. Repeat that ~13 times and you should have identified the bad commit.

Quoted 31 lines · Michael Ellerman

Quoted 5 lines · Christian Zigotzky

Quoted 4 lines · Christian Zigotzky

Hi Michael,

Thank you for your answer and thank you for your help. :-)

Quoted 7 lines

Quoted 7 lines · Michael Ellerman

Quoted 5 lines · Christian Zigotzky

I'm going to guess that cd427485357c0c4b99f69719251baacf25946e11 is BAD. Can
you please confirm or deny that?

It's not BAD. It boots.

Hmm, interesting.

Quoted 16 lines

Quoted 3 lines

Quoted 3 lines

If cd42748 is *good*, then you'll need to do a bigger bisect from d8ff9cd to
18a1a7a.

OK :-)

-> git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux2-git -> git bisect start
-> git bisect good d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b
-> git bisect bad 18a1a7a1d862ae0794a0179473d08a414dd49234

Output:
Bisecting: 5900 revisions left to test after this (roughly 13 steps) [cb1595563880a81dab6eab9a5ecb4520d2e76077] Merge tag 'tty-3.15-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

Quoted 7 lines

Quoted 1 line

Unfortunately it doesn't boot. :-(

OK. So you do:

$ git bisect bad

And it will pick a new commit for you to test. Repeat that ~13 times and you should have identified the bad commit.

OK :-)

git bisect bad
Bisecting: 2902 revisions left to test after this (roughly 12 steps) [b22f136071b1a797e96b3ee6fb0dc32625bd152e] staging: rtl8821ae: Fix quoted string split across lines <- Kernel boots :-)

What shall I do next?

Quoted 41 lines · Christian Zigotzky

Quoted 31 lines · Michael Ellerman

Quoted 5 lines · Christian Zigotzky

Quoted 4 lines · Christian Zigotzky

Hi Michael,

Thank you for your answer and thank you for your help. :-)

Quoted 7 lines

Quoted 7 lines · Michael Ellerman

Quoted 5 lines · Christian Zigotzky

I'm going to guess that cd427485357c0c4b99f69719251baacf25946e11 is BAD. Can
you please confirm or deny that?

It's not BAD. It boots.

Hmm, interesting.

Quoted 16 lines

Quoted 3 lines

Quoted 3 lines

If cd42748 is *good*, then you'll need to do a bigger bisect from d8ff9cd to
18a1a7a.

OK :-)

-> git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux2-git -> git bisect start
-> git bisect good d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b
-> git bisect bad 18a1a7a1d862ae0794a0179473d08a414dd49234

Output:
Bisecting: 5900 revisions left to test after this (roughly 13 steps) [cb1595563880a81dab6eab9a5ecb4520d2e76077] Merge tag 'tty-3.15-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

Quoted 7 lines

Quoted 1 line

Unfortunately it doesn't boot. :-(

OK. So you do:

$ git bisect bad

And it will pick a new commit for you to test. Repeat that ~13 times and you should have identified the bad commit.

OK :-)

Quoted 5 lines

git bisect bad
Bisecting: 2902 revisions left to test after this (roughly 12 steps) [b22f136071b1a797e96b3ee6fb0dc32625bd152e] staging: rtl8821ae: Fix quoted string split across lines <- Kernel boots :-)

What shall I do next?

OK, I know it: git bisect good

-- Christian

Quoted 42 lines · Christian Zigotzky

Quoted 41 lines · Michael Ellerman

Quoted 31 lines · Christian Zigotzky

Quoted 5 lines · Christian Zigotzky

Quoted 4 lines

Hi Michael,

Thank you for your answer and thank you for your help. :-)

Quoted 7 lines

Quoted 7 lines · Michael Ellerman

Quoted 5 lines · Christian Zigotzky

I'm going to guess that cd427485357c0c4b99f69719251baacf25946e11 is BAD. Can
you please confirm or deny that?

It's not BAD. It boots.

Hmm, interesting.

Quoted 16 lines

Quoted 3 lines

Quoted 3 lines

If cd42748 is *good*, then you'll need to do a bigger bisect from d8ff9cd to
18a1a7a.

OK :-)

-> git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux2-git -> git bisect start
-> git bisect good d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b
-> git bisect bad 18a1a7a1d862ae0794a0179473d08a414dd49234

Output:
Bisecting: 5900 revisions left to test after this (roughly 13 steps) [cb1595563880a81dab6eab9a5ecb4520d2e76077] Merge tag 'tty-3.15-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

Quoted 7 lines

Quoted 1 line

Unfortunately it doesn't boot. :-(

OK. So you do:

$ git bisect bad

And it will pick a new commit for you to test. Repeat that ~13 times and you should have identified the bad commit.

OK :-)

Quoted 9 lines

Quoted 5 lines

git bisect bad
Bisecting: 2902 revisions left to test after this (roughly 12 steps) [b22f136071b1a797e96b3ee6fb0dc32625bd152e] staging: rtl8821ae: Fix quoted string split across lines <- Kernel boots :-)

What shall I do next?

OK, I know it: git bisect good

-- Christian

git bisect good
Bisecting: 1494 revisions left to test after this (roughly 11 steps)
[3786075b5ebc8c4eaefd9e3ebf72883934fb64b3] Merge tag 'regulator-v3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator <- Kernel boots

git bisect good
Bisecting: 797 revisions left to test after this (roughly 10 steps)
[69dd89fd2b9406603d218cab8996cfb232d5b8b9] Merge tag 'asoc-v3.15-4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus <- Kernel boots

git bisect good
Bisecting: 372 revisions left to test after this (roughly 9 steps)
[4b1779c2cf030c68aefe939d946475e4136c1895] Merge tag 'pci-v3.15-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci <- Doesn't boot

git bisect bad
Bisecting: 212 revisions left to test after this (roughly 8 steps)
[45b15d98a96ffdb3c608bdad952f51930c151420] Merge remote-tracking branches 'spi/topic/xilinx' and 'spi/topic/xtfpga' into spi-next <- Kernel boots

git bisect good
Bisecting: 118 revisions left to test after this (roughly 7 steps) [91b4adc983d8e9975bc677c2b8395631edf7b92d] Merge branch 'pci/misc' into next <- Kernel boots

git bisect good
Bisecting: 41 revisions left to test after this (roughly 6 steps)
[26f31fb936042459d481557a83bda7a3f4d61906] Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging <- Kernel boots

git bisect good
Bisecting: 20 revisions left to test after this (roughly 4 steps) [e20fa6609a0076def469aeb799b1c25558e70042] PCI: Don't check resource_size() in pci_bus_alloc_resource() <- Doesn't boot

git bisect bad
Bisecting: 10 revisions left to test after this (roughly 3 steps) [cd8a4d3657c3f2cf9ce3780707be1debb8fea6e2] PCI: Check IORESOURCE_UNSET before updating BAR <- Doesn't boot

git bisect bad
Bisecting: 4 revisions left to test after this (roughly 2 steps) [5edb93b89f6cc3089ee283656555e7a9ad36a8a0] resource: Add resource_contains() <- Kernel boots

git bisect good
Bisecting: 2 revisions left to test after this (roughly 1 step) [f44116ae881868ab72274df1eff48fdbde9898af] PCI: Remove pci_find_parent_resource() use for allocation <- Doesn't boot

git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps) [d19cb803a2ff85d1b64b9628e1aec2aa76a9260b] vsprintf: Add support for IORESOURCE_UNSET in %pR <- Kernel boots

git bisect good f44116ae881868ab72274df1eff48fdbde9898af is the first bad commit commit f44116ae881868ab72274df1eff48fdbde9898af

Author: Bjorn Helgaas <[email protected]>
Date:   Wed Feb 26 11:25:58 2014 -0700

PCI: Remove pci_find_parent_resource() use for allocation

If the resource hasn't been allocated yet,
pci_find_parent_resource() is
documented as returning the region "where it should be allocated
from."
This is impossible in general because there may be several
candidates: a
prefetchable BAR can be put in either a prefetchable or
non-prefetchable
window, a transparent bridge may have overlapping positively- and subtractively-decoded windows, and a root bus may have several
windows of
the same type.

Allocation should be done by pci_bus_alloc_resource(), which iterates through all bus resources and looks for the best match, e.g., one
with the
desired prefetchability attributes, and falls back to less-desired possibilities.

The only valid use of pci_find_parent_resource() is to find the
parent of
an already-allocated resource so we can claim it via
request_resource(),
and all we need for that is a bus region of the correct type that
contains
the resource.

Note that like 8c8def26bfaa ("PCI: allow matching of prefetchable
resources
to non-prefetchable windows"), this depends on
pci_bus_for_each_resource()
iterating through positively-decoded regions before
subtractively-decoded
ones. We prefer not to return a subtractively-decoded region because requesting from it will likely conflict with the overlapping
positively-
decoded window (see Launchpad report below).

Link https://bugs.launchpad.net/ubuntu/+source/linux/+bug/424142

Signed-off-by Bjorn Helgaas <[email protected]>

CC Linus Torvalds <[email protected]>

:040000 040000 d9f2e04d3a635126a3c42406400b156aea3d2e30 43278454117307fa7e155fb241b16b1863ea45d0 M drivers

Hi Michael,

I have two times bisected with git. It seems the commit "PCI: Remove pci_find_parent_resource() use for allocation" is the problem. I have removed this patch from the kernel source code but unfortunately the kernel doesn't boot. Have you another tip for me, please?

Cheers,

Christian

Am 01.06.14 00:33, schrieb Christian Zigotzky:

Quoted 151 lines · Christian Zigotzky

Quoted 42 lines · Christian Zigotzky

Quoted 41 lines · Michael Ellerman

Quoted 31 lines · Christian Zigotzky

Quoted 5 lines · Christian Zigotzky

Quoted 4 lines

Hi Michael,

Thank you for your answer and thank you for your help. :-)

Quoted 7 lines

Quoted 7 lines · Michael Ellerman

Quoted 5 lines · Christian Zigotzky

I'm going to guess that cd427485357c0c4b99f69719251baacf25946e11 is BAD. Can
you please confirm or deny that?

It's not BAD. It boots.

Hmm, interesting.

Quoted 16 lines

Quoted 3 lines

Quoted 3 lines

If cd42748 is *good*, then you'll need to do a bigger bisect from d8ff9cd to
18a1a7a.

OK :-)

-> git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux2-git -> git bisect start
-> git bisect good d8ff9cdf68fd119d491f3de90e1a612afc2f3b2b
-> git bisect bad 18a1a7a1d862ae0794a0179473d08a414dd49234

Output:
Bisecting: 5900 revisions left to test after this (roughly 13 steps) [cb1595563880a81dab6eab9a5ecb4520d2e76077] Merge tag 'tty-3.15-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

Quoted 7 lines

Quoted 1 line

Unfortunately it doesn't boot. :-(

OK. So you do:

$ git bisect bad

And it will pick a new commit for you to test. Repeat that ~13 times and you should have identified the bad commit.

OK :-)

Quoted 9 lines

Quoted 5 lines

git bisect bad
Bisecting: 2902 revisions left to test after this (roughly 12 steps) [b22f136071b1a797e96b3ee6fb0dc32625bd152e] staging: rtl8821ae: Fix quoted string split across lines <- Kernel boots :-)

What shall I do next?

OK, I know it: git bisect good

-- Christian

git bisect good
Bisecting: 1494 revisions left to test after this (roughly 11 steps)
[3786075b5ebc8c4eaefd9e3ebf72883934fb64b3] Merge tag 'regulator-v3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator <- Kernel boots

git bisect good
Bisecting: 797 revisions left to test after this (roughly 10 steps)
[69dd89fd2b9406603d218cab8996cfb232d5b8b9] Merge tag 'asoc-v3.15-4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus <- Kernel boots

git bisect good
Bisecting: 372 revisions left to test after this (roughly 9 steps)
[4b1779c2cf030c68aefe939d946475e4136c1895] Merge tag 'pci-v3.15-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci <- Doesn't boot

git bisect bad
Bisecting: 212 revisions left to test after this (roughly 8 steps)
[45b15d98a96ffdb3c608bdad952f51930c151420] Merge remote-tracking branches 'spi/topic/xilinx' and 'spi/topic/xtfpga' into spi-next <- Kernel boots

git bisect good
Bisecting: 118 revisions left to test after this (roughly 7 steps) [91b4adc983d8e9975bc677c2b8395631edf7b92d] Merge branch 'pci/misc' into next <- Kernel boots

git bisect good
Bisecting: 41 revisions left to test after this (roughly 6 steps)
[26f31fb936042459d481557a83bda7a3f4d61906] Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging <- Kernel boots

git bisect good
Bisecting: 20 revisions left to test after this (roughly 4 steps) [e20fa6609a0076def469aeb799b1c25558e70042] PCI: Don't check resource_size() in pci_bus_alloc_resource() <- Doesn't boot

git bisect bad
Bisecting: 10 revisions left to test after this (roughly 3 steps) [cd8a4d3657c3f2cf9ce3780707be1debb8fea6e2] PCI: Check IORESOURCE_UNSET before updating BAR <- Doesn't boot

git bisect bad
Bisecting: 4 revisions left to test after this (roughly 2 steps) [5edb93b89f6cc3089ee283656555e7a9ad36a8a0] resource: Add resource_contains() <- Kernel boots

git bisect good
Bisecting: 2 revisions left to test after this (roughly 1 step) [f44116ae881868ab72274df1eff48fdbde9898af] PCI: Remove pci_find_parent_resource() use for allocation <- Doesn't boot

git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps) [d19cb803a2ff85d1b64b9628e1aec2aa76a9260b] vsprintf: Add support for IORESOURCE_UNSET in %pR <- Kernel boots

git bisect good f44116ae881868ab72274df1eff48fdbde9898af is the first bad commit commit f44116ae881868ab72274df1eff48fdbde9898af

Author: Bjorn Helgaas <[email protected]>
Date:   Wed Feb 26 11:25:58 2014 -0700

PCI: Remove pci_find_parent_resource() use for allocation

If the resource hasn't been allocated yet,
pci_find_parent_resource() is
documented as returning the region "where it should be allocated
from."
This is impossible in general because there may be several
candidates: a
prefetchable BAR can be put in either a prefetchable or
non-prefetchable
window, a transparent bridge may have overlapping positively- and subtractively-decoded windows, and a root bus may have several
windows of
the same type.

Allocation should be done by pci_bus_alloc_resource(), which
iterates
through all bus resources and looks for the best match, e.g., one
with the
desired prefetchability attributes, and falls back to less-desired possibilities.

The only valid use of pci_find_parent_resource() is to find the
parent of
an already-allocated resource so we can claim it via
request_resource(),
and all we need for that is a bus region of the correct type that
contains
the resource.

Note that like 8c8def26bfaa ("PCI: allow matching of prefetchable
resources
to non-prefetchable windows"), this depends on
pci_bus_for_each_resource()
iterating through positively-decoded regions before
subtractively-decoded
ones. We prefer not to return a subtractively-decoded region
because
requesting from it will likely conflict with the overlapping
positively-
decoded window (see Launchpad report below).

Link https://bugs.launchpad.net/ubuntu/+source/linux/+bug/424142

Signed-off-by Bjorn Helgaas <[email protected]>

CC Linus Torvalds <[email protected]>

:040000 040000 d9f2e04d3a635126a3c42406400b156aea3d2e30 43278454117307fa7e155fb241b16b1863ea45d0 M drivers

Hi All,

Could you help me to remove the changes of the PCI code, please? Or which patches shall I remove to get the old PCI code?

Quoted 4 lines

Hi All,

Could you help me to remove the changes of the PCI code, please? Or which patches shall I remove to get the old PCI code?

Hi Christian,

Thanks for doing the bisect. It wasn't clear why that change was causing your issue, so I guess we're a bit stuck.

Olof (on CC), was going to try and look at it when he got some spare time. Please keep him on CC.

cheers

Am 18.06.14 08:51, schrieb Michael Ellerman:

Quoted 7 lines · Christian Zigotzky

Quoted 4 lines

Hi All,

Could you help me to remove the changes of the PCI code, please? Or which patches shall I remove to get the old PCI code?

Hi Christian,

Quoted 10 lines

Thanks for doing the bisect. It wasn't clear why that change was causing your issue, so I guess we're a bit stuck.

Olof (on CC), was going to try and look at it when he got some spare time. Please keep him on CC.

cheers

Hi Michael,

Thank you for your answer. Adrian told me the reason about this issue.

Quote Adrian:

As I recall, PCI resource allocation on Nemo was always a little strange due to using an AMD south bridge together with the PA6T north bridge. The south bridge does not behave as a standard PCIe device, but instead presents itself as multiple devices on the PCIe root bus. This is not compliant with the PCIe specification. We modified the core powerpc PCI code so that Nemo could boot, but the changes to PCI code in 3.15 have broken the old workaround. I don't understand the PCI changes in 3.15 enough to comment further at this point.

Regards,
Adrian

Quote end

Cheers,

Christian