Bug 59431

Can you try booting with i915.i915_enable_ppgtt=0? Also, running addr2line on the i915.ko driver module with the address (i915_gem_init_ppgtt+0x74) and then pasting the relevant source code lines could be interesting ...

Hello Daniel,

thank you for your quick response.

when booting with the option i915.i915_enable_ppgtt=0 and adding video=efifb:i20 then the systems boots without issues. Without the efifb:i20 i only get a black screen but the system does startup.

when trying the addr2line i get:
addr2line -a 'i915_gem_init_ppgtt+0x74' -e lib/modules/3.5.0-21-generic/kernel/drivers/gpu/drm/i915/i915.ko 
0x00000000
??:0

I guess i have to rebuild the kernel with debugging symbols?
The build is almost running. If thats incorrect please let me know so i can investigate this further else i will post my results in a hour maybe 2.

Please do your testing with at least 3.6, for this bug looks exactly like

commit 9a0f938bde74bf9e50bd75c8de9e38c1787398cd
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 24 09:12:22 2012 +0100

    drm/i915: Use the correct size of the GTT for placing the per-process entries

Hi Chris,

i'm testing with kernel:
linux-image-3.8.0-0-generic          3.8.0-0.3                                i386         Linux kernel image for version 3.8.0 on 32 bit x86 SMP

When starting a amd64 bit kernel this is not a problem, only when booting a 32bit kernel on a 64bit efi firmware then it gets triggered.


Regards,

William

i'm feeling stupid.

i have a script which builds my environment but i did not clean it up right so it took the old 3.5 kernel instead of the 3.8 which i thought the system was running. It still does not work the way i'm hoping but that could be something else then this one. (black screen)

I'll have another look and will file a new bug if necessary.

I'm very sorry for bugging you guys with this.

Thank you Daniel and Chris for your time.

Best regards,
William

So can we close this one as invalid?

If you can attach the drm.debug=6 dmesg from a 3.8 kernel, that should hopefully give us enough info to see where the likely culprit is. Does the screen start to work when X starts? Maybe worth attaching the Xorg.log as well.

I'll get back to that tomorrow.

regards.
William

Ok i have been testing with the 3.8 kernel both architectures with different results.

When starting the amd64 kernel without options i get no console. When starting the amd64 kernel with i915.disable=1 i do get a console.

When starting the i386 kernel without options i get no console. When starting the i386 kernel with i915.disable=1 i get no console.

I have attached both logs from the amd64 dmesg with drm.debug=6 and i386 with and without the option i915.disable=1

I have not yet looked into Xorg log (i have to install X first) will attach those later.

Created attachment 73141 [details]
dmesg amd64 drm.debug=6

Created attachment 73142 [details]
dmesg amd64 drm.debug=6 i915.disable=1

Created attachment 73143 [details]
dmesg i386 drm.debug=6

Created attachment 73144 [details]
dmesg i386 drm.debug=6 i915.disable=1

I can be short for the xorg log because it cannot find any screens.

I do get a display when using the fglrx drivers from amd.

Ok, this is the apple gmux. The display is connected to the discrete radeon GPU and you need to manually switch it over to the igfx (using the mux). That it is blank upon booting is because not only is the video muxed, so are the control lines which are still being reversed engineered as to how to setup the gmux.

But how can the amd64 give a console while the i386 kernel cannot?

I could provide remote access if that could be helpful?

(In reply to comment #15)
> Ok, this is the apple gmux. The display is connected to the discrete radeon
> GPU and you need to manually switch it over to the igfx (using the mux).
> That it is blank upon booting is because not only is the video muxed, so are
> the control lines which are still being reversed engineered as to how to
> setup the gmux.

I got pointed at this bug since the gmux came up.

Chris: I don't really understand this comment. I can't see that anything is trying to switch gpus. There are likely problems getting i915 to correctly detect which outputs are attached since the display is muxed to the radeon at boot and macs have a bad habit of not supplying VBTs, but i915 still shouldn't oops (but it sounds like this is fixed?), and radeon should still be able to drive the panel.

William: I don't think I have a clear handle on the current state of this problem. Am I correct in understanding that you no longer get the stack trace on the screen when you boot an i386 kernel, but get a blank screen instead? Does the behavior change at all in 3.8 based on whether or not you pass i915.disable=1?

Hi Seth,

i have been testing with raring using 3.8 kernel.

On 64 bit kernel i get a console screen using the i915.disable=1 but not on the 32bit kernel. see also the dmesg files attached.

When using the 3.5 kernel from quantal i get an oops with a 32bit kernel but not when i use the option i915.i915_enable_ppgtt=0 but then i still have a blank screen.

Okay, thanks.

I suspect at least part of the problem may be related to efifb. I don't see that it's being used on your machine, and I note that it has a bunch of quirks for making it work with various Mac hardware. If we add a quirk for your machine efifb should then be able to identify the radeon as the default vga device and use it for the console framebuffer. I'm guessing this won't fix the problem with the 32-bit builds, but it should at least remove the need for i915.disable=1 with the 64-bit build.

To make a patch I'll need some DMI information for your machine. Could you send me the output from the following commands?

 dmidecode -s bios-vendor
 dmidecode -s system-product-name

Hi Seth,

the output is:
bios vendor: Apple Inc.
system product name: iMac12,1

Could that also explain why X is not working?

(In reply to comment #21)
> Hi Seth,
> 
> the output is:
> bios vendor: Apple Inc.
> system product name: iMac12,1

Rats, it turns out there's more information required. If you can boot into OS X and run the following command in a terminal, it's supposed to give all the required information.

sudo ioreg -lw0 |grep manufacturer|cut -b25-80;sudo ioreg -lw0|grep "product-name"|cut -b 25-80;sudo dtrace -qn 'BEGIN{boot_args=((struct boot_args*)(`PE_state).bootArgs);printf("FrameBuff erBase: 0x%08x\nPixelsPerScanLine: %d\nHorizontalResolution: %d\nVerticalResolution: %d", boot_args->Video.v_baseAddr, boot_args->Video.v_rowBytes/4, boot_args->Video.v_width, boot_args->Video.v_height);exit(0)} '
 
> Could that also explain why X is not working?

I don't know much at all about X, but I suspect it might be at least contributing. Maybe X is also trying to use the Intel graphics based on the same information.

Here the information from the output:

 <"Apple Inc.">
 <"iMac12,1">
FrameBuff erBase: 0x90010000
PixelsPerScanLine: 1920
HorizontalResolution: 1920
VerticalResolution: 1080

Created attachment 73542 [details] [review]
Add quirk to efifb for iMac 12,1

Here's a patch to try. But after some more poking around I'm wondering why this is needed. The kernel seems to get the information about the GOP framebuffer for most recent Macs without quirking, so it makes me wonder why it doesn't work on this machine.

Just to check one obvious point, are you either running with the stock Ubuntu kernels or else with CONFIG_FB_EFI=y? An easy way to verify this is to boot the machine and run 'grep CONFIG_FB_EFI /boot/config-$(uname -r)'. This should output 'CONFIG_FB_EFI=y' if your kernel is configured to include the EFI framebuffer support.

I only use the stock ubuntu kernel.

First results:
i have built the amd64 with the patch and the system boots with framebuffer console without kernel options. I even can start X :)

I'm now rebuilding an 32 bit kernel with the patch to see if that makes any difference.

Created attachment 73563 [details]
dmesg i386

Created attachment 73564 [details]
dmesg amd64

Created attachment 73565 [details]
picture distorted screen

Hi,

some progress.

The 64bit kernel with the patch can now be booted without any options.

the 32bit kernel is a little bit different.

When i start this kernel i do see some kernel output before the screen flashes black, then after some seconds i see the login prompt. on the 64bit kernel i also see the output from the init scripts but not on the 32bit kernel. The screen is also distorted because the screen starts almost in the middle and the output on the most right side is displayed at the left side of the screen. I attached a picture which shows this. 

X can be started but has the same issue. a part of the right side of the display is showed on the left side.

If your grub config has gfxpayload=keep, try removing that.  That causes problems for lots of people.

When removing the gfxpayload=keep option the 64bit kernel boots fine but the 32bit kernel does not give me a console.

(In reply to comment #29)
> 
> When i start this kernel i do see some kernel output before the screen
> flashes black, then after some seconds i see the login prompt. on the 64bit
> kernel i also see the output from the init scripts but not on the 32bit
> kernel. The screen is also distorted because the screen starts almost in the
> middle and the output on the most right side is displayed at the left side
> of the screen. I attached a picture which shows this. 
> 
> X can be started but has the same issue. a part of the right side of the
> display is showed on the left side.

Which kernel exhibits the shifted display?


(In reply to comment #31)
> When removing the gfxpayload=keep option the 64bit kernel boots fine but the
> 32bit kernel does not give me a console.

Does removing that option fix the shifted display?

(In reply to comment #32)
> (In reply to comment #29)
> > 
> > When i start this kernel i do see some kernel output before the screen
> > flashes black, then after some seconds i see the login prompt. on the 64bit
> > kernel i also see the output from the init scripts but not on the 32bit
> > kernel. The screen is also distorted because the screen starts almost in the
> > middle and the output on the most right side is displayed at the left side
> > of the screen. I attached a picture which shows this. 
> > 
> > X can be started but has the same issue. a part of the right side of the
> > display is showed on the left side.
> 
> Which kernel exhibits the shifted display?
With the 32bit kernel i get the shifted display.
> 
> 
> (In reply to comment #31)
> > When removing the gfxpayload=keep option the 64bit kernel boots fine but the
> > 32bit kernel does not give me a console.
> 
> Does removing that option fix the shifted display?
Not really fix it. The screen turns black no console at all. With the patch with the gfxpayload=keep option i atleast get a console but shifted.

(In reply to comment #33)
> > Does removing that option fix the shifted display?
> Not really fix it. The screen turns black no console at all. With the patch
> with the gfxpayload=keep option i atleast get a console but shifted.

Have you tested with the patch and without gfxpayload=keep?

(In reply to comment #34)
> (In reply to comment #33)
> > > Does removing that option fix the shifted display?
> > Not really fix it. The screen turns black no console at all. With the patch
> > with the gfxpayload=keep option i atleast get a console but shifted.
> 
> Have you tested with the patch and without gfxpayload=keep?

this is with the patched kernel.
so:
64bit kernel with patch works fine with and without gfxpayload=keep
32bit kernel with patch works but with shifted display.
32bit kernel with patch without option gfxpayload=keep no console display.

William: Regarding the issue with efifb not working without the patch I supplied, it seems the information efifb requires normally either comes from the bootloader, or else the kernel can discover the information itself if booted using the EFI stub or EFI handover protocol. The failure to work on your system without the quirk could be due to either a bug in the EFI firmware or a problem with how the kernel is being booted.

Do you have working graphics in your bootloader? If so the problem is probably with how the kernel is booted. Are you using the standard Ubuntu boot setup (i.e. grub2), and are you modifying it in any way?

(In reply to comment #36)
> William: Regarding the issue with efifb not working without the patch I
> supplied, it seems the information efifb requires normally either comes from
> the bootloader, or else the kernel can discover the information itself if
> booted using the EFI stub or EFI handover protocol. The failure to work on
> your system without the quirk could be due to either a bug in the EFI
> firmware or a problem with how the kernel is being booted.
> 
> Do you have working graphics in your bootloader? If so the problem is
> probably with how the kernel is booted. Are you using the standard Ubuntu
> boot setup (i.e. grub2), and are you modifying it in any way?

I have no graphics setup or at least not that i am aware off.
I get a ncurses based menu where i can choose the different kernels i have installed.

Right now i cannot seem to get a console even with or without the gfxpayload=keep option on the 32bit kernel. When starting the same usb stick on a macbook air it works with both the 32bit kernel and the 64bit kernel.

We don't use the default ubuntu grub install because we setup a small efiboot environment  using grub-mkimage.
grub-mkimage -O x86_64-efi -o bootx64.efi  search_fs_uuid fat ext2 normal boot configfile linux

We then install this onto a small fat partition 8 MB.
I will attach the efiboot with the grub options.

I think the main problem is that we are starting a 32bit kernel from a 64bit firmware. I had earlier issues with that even on the standard macbook air see also: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1082059

But this has been addressed.

I think something else is going wrong with setting up efifb with a 32bit kernel booted from 64 bit firmware and that that is the reason i don't get a console. From the dmesg log i see connector 4 is vga-1 on 64bit kernel and vga-2 on the 32bit kernel, not sure if that could mean anything.

Created attachment 73590 [details]
efiboot files

(In reply to comment #37)
> I have no graphics setup or at least not that i am aware off.
> I get a ncurses based menu where i can choose the different kernels i have
> installed.

By "graphics" I just mean that grub can display something on the screen, which seems to be the case. Typically on a Mac grub will use GOP for this, which is the interface supported by efifb.

> Right now i cannot seem to get a console even with or without the
> gfxpayload=keep option on the 32bit kernel. When starting the same usb stick
> on a macbook air it works with both the 32bit kernel and the 64bit kernel.

There's only one graphics card in the airs. Part of your current problems seems to be confusion over which card should be used.

> We don't use the default ubuntu grub install because we setup a small
> efiboot environment  using grub-mkimage.
> grub-mkimage -O x86_64-efi -o bootx64.efi  search_fs_uuid fat ext2 normal
> boot configfile linux

What I'm trying to figure out here is whether or not the patch I wrote is actually needed. If it's a problem with how the kernel is being booted then patching efifb probably isn't appropriate.

Please try booting a standard 64-bit Ubuntu image (either 12.10 or the 13.04 daily builds) and see if you experience any of the same problems. If not then you've got a problem with your boot environment. I'm no grub expert, but your list of modules is rather small. In particular I notice that there's a efi_gop module that isn't included.

There's still obviously a problem with the graphics when you boot a 32-bit kernel, but getting the kernel to identify the correct graphics device to use is a prerequisite to fixing the other problem.

The latest Ubuntu 13.04 iso 64 bit works ok. Console and X. So I'm looking into my grub-mkimage command to see what I have forgotten. Will post that in a few hours.

Some more results.

I thought i could insmod my new modules but thats not the case. Now i have included efi_gop and efi_uga and now the default amd64 kernel from raring boots without issue. But no change for the 32bit kernel still no console.

So the quirk patch is not required when you load efi_gop.

Thanks for checking. In that case I don't think it's appropriate to apply the quirk. As for the remaining issues in the 32-bit build, I suspect Alex is the best person to help you with those.

I'm not sure how much more help I can be.  I'm not really familiar with macs at all other than the fact they they are always a lot of trouble ;)  Now that the efi gop stuff is sorted out, you might try removing the gfxpayload=keep from your grub config and see if that helps.

(In reply to comment #43)
> I'm not sure how much more help I can be.  I'm not really familiar with macs
> at all other than the fact they they are always a lot of trouble ;)  Now
> that the efi gop stuff is sorted out, you might try removing the
> gfxpayload=keep from your grub config and see if that helps.
Thank you Seth and Alex for helping me out here.

Ok, i have removed the gfxpayload=keep option but the console on a 32bit kernel stays black.
So there seems to be some differences between 64bit kernel and the 32bit kernel when initializing the graphics hardware.

Could i turn on some debugging for both the intel and the readeon drm driver which could help identify these initialization issues?

Ok, after some more investigating it seems plymouth is giving me issues while setting up the framebuffer console.
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1107642

I have reported this issue on launchpad and i will report here if this bug can be closed.

Thank you all for helping.

I found the exact commit that causes this bug

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-quantal.git;a=commit;h=8f53b5444a25b5be3bfe0164316f9bc7845279c9

drm/radeon: properly handle mc_stop/mc_resume on evergreen+ (v2)

BugLink: http://bugs.launchpad.net/bugs/1091251

commit 62444b7462a2b98bc78d68736c03a7c4e66ba7e2 upstream.

- Stop the displays from accessing the FB
- Block CPU access
- Turn off MC client access

This should fix issues some users have seen, especially
with UEFI, when changing the MC FB location that result
in hangs or display corruption.

v2: fix crtc enabled check noticed by Luca Tettamanti

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[ herton: adjust context ]
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>

Hope you guys can fix it

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/321.