1002:9488 [iMac11,2] 12.10 quantal boots to black screen on iMac

The same behaviour is observed on my iMac system when I boot archlinux (kernel 3.4.4) on another partition.
In that case I needed to set 'radeon mode=0' in the modules.conf file to allow me to see anything on the main screen, even text. The default setting was mode=1.

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.5kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-rc6-quantal/

Actually, v3.5-rc7 is available, it would be great if you could test that version:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-rc7-quantal/

It just happens I can do this now...
Am running kernel 3.5.0-030500rc7-generic now but it behaves just like the other kernels I have tried. Earlier today I raised a kernel bug report #44851 at bugzilla.kernel.org - pointing at suspend/resume, but I think its the same thing.
I will do the documentation you specified.

I'd like to perform a kernel bisect to identify the commit that caused this regression. Would it be possible for you to assist by testing some kernels? If so, we need to first identify the kernel version that introduce the regression, then we can bisect down to the actual commit.

Can you start by testing the following kernels:

v3.4 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-quantal/
v3.5-rc1: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-rc1-quantal/

I can do the testing you requested over the next few days.
Can I suggest I start with kernels 3.2.0.10 vs 3.4, since I know that
some time during kernel 3.2 development suspend/resume started working
properly (see bug#863969, comment on 25 Jan 2012, kernel 3.2.0.10.10).
Kernel 3.4.4, in archlinux at the moment, doesn't work, so it might be
good to work backwards from there.
Or to work forwards from early 3.2 kernels to see what happened to fix it?
regards
Peter Hayward

On 16 July 2012 19:04, Joseph Salisbury <email address hidden> wrote:
> I'd like to perform a kernel bisect to identify the commit that caused
> this regression. Would it be possible for you to assist by testing some
> kernels? If so, we need to first identify the kernel version that
> introduce the regression, then we can bisect down to the actual commit.
>
> Can you start by testing the following kernels:
>
> v3.4 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.4-quantal/
> v3.5-rc1: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5-rc1-quantal/
>
> ** Bug watch added: Linux Kernel Bug Tracker #44851
> http://bugzilla.kernel.org/show_bug.cgi?id=44851
>
> ** Also affects: linux via
> http://bugzilla.kernel.org/show_bug.cgi?id=44851
> Importance: Unknown
> Status: Unknown
>
> ** Tags added: performing-bisect
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1024507
>
> Title:
> 12.10 quantal boots to black screen on iMac
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linux/+bug/1024507/+subscriptions

Results so far (using grub2, with manual edits to boot params to load these kernels):
### kernel 3.2.0-030200rc6-generic (16 Dec 2011)
Used nomodeset as boot param.
suspend from menu does not stop system - black screen with blinking cursor on vt1, white screen on vt7 until mouse click, then could use desktop. Network non-functional.

### kernel 3.4.0-030400-generic (22 May 2012)
nomodeset at boot.
supend from menu does not stop system - black screen. Press of space and get blinking cursor on vt1, desktop on vt7. Network down and not recoverable using menu. Could bring up wlan0 manually but wpa_supplicant command failed to run - no conf file - so abandoned attempt.
Tried to suspend a second time. Nothing happened. dmesg reported
'...
gnome-control-c .... general protection ip:...
error in libglib-2.0.so.0....
...'
Suspect something due to upgrade of glibc since this kernel.

### kernel 3.5.0-030500rc1-generic (22 June 2012)
nomodeset at boot.
suspend from menu stops system. Screen goes black and disk stops.
Press space and disk restarts. Screen stays black. Tried blind restart using shutdown command and using Ctl-Alt-Del. No response from either. Power button to restart. I think latest kernel can be restarted using Ctl-Alt-Del.

Problems still present on latest kernel, 3.5.0-16-generic.
- nomodeset kernel param is necessary to get a boot screen.
- xorg.conf must have Device as fbdev or get black screen when X starts.
-- However, fbdev gives quite good enough performance for me.
- Suspend works but resume is always to black screen (wrong display).
-- this last means I cannot use suspend

Still no resolution of this problem. I have used kernel 3.8.0 under ubuntu 13.04 and am now using kernel 3.7.9 under archlinux.
Can boot both OK, using 'nomodeset'. But both still resume to the wrong screen. The log tells me that the kernel, when it starts to sleep, tries to save state with 'vbetool'. That shows an error, no card detected. On resume I suppose there is no info available to allow radeon module to set correct screen; it defaults to wrong video screen and all terminals are black. However, the terms do accept keyboard input.
I believe this is a kernel module problem; not an xorg module problem. It affects terminals not running X (and those running X as well).

Peter T Hayward, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please just make a comment to this.

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc3

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Necrobumping this thing as I've been battling the same issue on an iMac 10,1 (Radeon Mobility 4670) with the most recent LTS releases. Booting normally on 14.04 OR the most recent 16.04 nightly results in a black screen when using the radeon driver. Interestingly, I can get display if I plug in an external screen on the external miniDP connector (but only on one display at a time. It will NOT display to both monitors simultaneously).

Looking at Xorg.0.log, it can detect both DisplayPort-0 (assuming this to be the internal DP connector for the built in panel) and eDP (assuming this to be external DP connector), retrieves EDID, DISCONNECTS DisplayPort-0 and then loads up using eDP. No error state reported by X, just blank screen on the built-in panel. xrandr -d :0 -q results in DisplayPort-0 disconnected, edP as the primary and a long list of modes retrieved from the internal panel's EDID. It almost seems like X's wires are crossed with these two outputs, trying to load on the external displayport using EDID gained by initially connecting to DP0.

System is otherwise running and usable - can SSH in and fool around with things while it's running / restart LightDM / play with xrandr to try and fail to make the thing work.

Listed workaround booting with nomodeset allows the system to load graphics (slowly) over LLVMPipe on the internal display.

Other fixes tried: wily-lts kernel (4.2) , latest 4.5rc kernel available in kernel.ubuntu.com/~kernel-ppa/mainline, updated driver/X stack for 14.04 . No effect.

Ray Perigo, it will help immensely if you filed a new report with Ubuntu by ensuring you have the package xdiagnose installed, and that you click the Yes button for attaching additional debugging information running the following from a terminal:
ubuntu-bug xorg

Also, please feel free to subscribe me to it.

For more on why this is helpful, please see https://wiki.ubuntu.com/ReportingBugs.