Bug 13422 - Commit 295f83e7aaa87d52b8d16077225a90dab61df45a breaks framebuffer on PowerMac12.1
Summary: Commit 295f83e7aaa87d52b8d16077225a90dab61df45a breaks framebuffer on PowerMa...
Status: CLOSED OBSOLETE
Alias: None
Product: Platform Specific/Hardware
Classification: Unclassified
Component: PPC-64 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Anton Blanchard
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-01 14:18 UTC by Tomas "Supp" Kindl
Modified: 2012-06-08 11:30 UTC (History)
4 users (show)

See Also:
Kernel Version: >2.6.24 up to current git
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
lspci -vvv (14.49 KB, application/octet-stream)
2009-06-01 14:18 UTC, Tomas "Supp" Kindl
Details
dmesg (16.09 KB, application/octet-stream)
2009-06-01 14:18 UTC, Tomas "Supp" Kindl
Details
Requested dumps from vanilla kernel (28.52 KB, application/x-bzip)
2009-06-07 15:38 UTC, Tomas "Supp" Kindl
Details
Requested dumps from kernel w/ reverted commit (28.02 KB, application/x-bzip)
2009-06-07 15:39 UTC, Tomas "Supp" Kindl
Details

Description Tomas "Supp" Kindl 2009-06-01 14:18:16 UTC
Created attachment 21683 [details]
lspci -vvv

I acquired PowerMac12,1 and installed gentoo on it, using vanilla kernel from kernel.org

No matter if you use radeonfb or ofonly  FB screen hangs shortly after start (machine is working though and can be accessed via ssh). Screen is just plain dead.

Bisecting current git lead to commit 295f83e7aaa87d52b8d16077225a90dab61df45a by Benjamin Herrenschmidt, named [PATCH 13/13] [POWERPC] Clear pci_probe_only on 64 bits PowerMac.

After this commit FB was always dead no matter what.

Reverting this commit lead to fully functioning FB with all affected kernels, eg. everything >=2.6.25-rc1.

It should be noted that dmesg is same with and w/o this error. 

If needed I can do more tests.
Comment 1 Tomas "Supp" Kindl 2009-06-01 14:18:44 UTC
Created attachment 21684 [details]
dmesg
Comment 2 Andrew Morton 2009-06-02 05:23:59 UTC
Ben made a regression.  tsk.
Comment 3 Tony Breeds 2009-06-02 05:34:30 UTC
Hi Tomas,
   We're going need you to provide a bunch of data, sorry about the volume,
to try and narrow down what is going on here.

Firstly can you crate a new config based on your current config with:
CONFIG_BOOTX_TEXT=n
CONFIG_FB=n
CONFIG_DEBUG=y

Using that config boot upstream (please add "debug" to your kernel args)
and provide:
/proc/iomem
/proc/ioports
lspci -vvv
dmesg 
tarball of /proc/device-tree

Then apply your revert and supply the same details.  Hopefully that should give
us enough info to work with.
Comment 4 Benjamin Herrenschmidt 2009-06-02 06:59:05 UTC
BTW. You don't need to send 2 different tarballs of /proc/device-tree,
it will not change between the two boots.
Comment 5 Benjamin Herrenschmidt 2009-06-02 07:08:27 UTC
From what I see of the original logs, what happens is that something in the way the PCI bridges are setup by the firmware upsets the kernel, which re-allocates everything. That causes the framebuffer to move around, thus breaking offb.

Hopefully, with the new logs, I'll have a better idea about why it's unhappy and what kind of fixup can be done to avoid the problem.

BTW. If anybody reads this bug report and has such a machine around Canberra, I wouldn't mind putting my hands on it to try to fix radeonfb as well :-)
Comment 6 Tomas "Supp" Kindl 2009-06-07 15:38:43 UTC
Created attachment 21791 [details]
Requested dumps from vanilla kernel
Comment 7 Tomas "Supp" Kindl 2009-06-07 15:39:08 UTC
Created attachment 21792 [details]
Requested dumps from kernel w/ reverted commit

Note You need to log in before you can comment on or make changes to this bug.