Hi,
I just switched from an ancient installation of emgd on a vaio X11 to the mainstream gma500_gfx driver.
One issue I have on 3.4 is that suspend to ram fails in psb_save_display_registers. I could only take a picture of the oops but it's quite incomplete: http://kamineko.org/oops/2012-06-17%2018.32.17.jpg
3.5-rc2 is not quite usable, I get a pile of warnings for DRM_OBJECT_MAX_PROPERTY being too small and in the end I don't get neither a console nor X.
here's attached a 3.4 boot dmesg, I'll recompile 3.5 soon to get started with that too.
Is there anything else I can provide to help debug this?
Thanks!
On Sun, Jun 17, 2012 at 12:03 PM, Mattia Dongili malattia@linux.it wrote:
Give 3.5-rc3 a try. There is a patch that at least silences the DRM_OBJECT_MAX_PROPERTY on i915.
If possible, add drm.debug=7 to your boot line and send a dmesg of 3.5-rc3.
Patrik
On Mon, Jun 18, 2012 at 12:26:29PM +0100, Alan Cox wrote:
On Sun, 17 Jun 2012 19:03:43 +0900 Mattia Dongili malattia@linux.it wrote:
...
yeah actually the warning part was the easy one to solve ;)
On Mon, Jun 18, 2012 at 10:04:00PM +0200, Patrik Jakobsson wrote:
attached the dmesg on rc3 with drm.debug=7. In addition I have a black screen and 3 modprobe processes stuck that udev tried to kill for a bit... then the console went blank and I can't tell if it's still trying:
359 ? R 11:08 /sbin/modprobe -b pci:v00008086d00008108sv0000104Dsd0000905Fbc03sc00i00 361 ? D 0:00 /sbin/modprobe -b pci:v00008086d0000811Bsv0000104Dsd0000905Fbc04sc03i00 422 ? D 0:00 /sbin/modprobe -b pci:v00008086d00008119sv0000104Dsd0000905Fbc06sc01i00
the aliases are respectively:
pci:v00008086d00008108sv0000104Dsd0000905Fbc03sc00i00 gma500_gfx
pci:v00008086d0000811Bsv0000104Dsd0000905Fbc04sc03i00 snd_hda_intel snd_hda_intel
pci:v00008086d00008119sv0000104Dsd0000905Fbc06sc01i00 lpc_sch
Thanks!
On Tue, Jun 19, 2012 at 07:56:52PM +0900, Mattia Dongili wrote:
On Mon, Jun 18, 2012 at 10:04:00PM +0200, Patrik Jakobsson wrote:
On Sun, Jun 17, 2012 at 12:03 PM, Mattia Dongili malattia@linux.it wrote:
...
for the record, here below is where the screen flickers a bit and booting gets stuck until udev starts trying to kill the modprobe calls.
...
On Thu, Jun 21, 2012 at 06:19:25AM +0900, Mattia Dongili wrote:
I gave 3.5-rc4 a try, no significant change but by comparing 3.4 and 3.5 logs I have this difference that may mean something:
[ 0.000000] Linux version 3.5.0-rc4... [ 5.712020] gma500 0000:00:02.0: Backlight lvds set brightness 74367436
while with 3.4
[ 5.525296] gma500 0000:00:02.0: Backlight lvds set brightness 74407440
a did put some printks here and there and psb_driver_init seems to never return from gma_backlight_init.
On Mon, 2 Jul 2012 07:06:59 +0900 Mattia Dongili malattia@linux.it wrote:
Is it ok if you just comment out gma_backlight_init (at which point it should just skip backlight handling and leave the firmware configured one)
Alan
On Mon, Jul 02, 2012 at 11:43:04AM +0100, Alan Cox wrote:
On Mon, 2 Jul 2012 07:06:59 +0900 Mattia Dongili malattia@linux.it wrote:
...
ha! that gave me a good lead. The problem is not gma_backlight_init but rather psb_modeset_init that calls the errata for the chip that in turn sets the brightness before any initialization is done.
Commenting out the call to dev_priv->ops->errata in framebuffer.c makes boot get to the end like it used to on 3.4. It seems to be just an ordering problem in the end.
dri-devel@lists.freedesktop.org
-
Alan Cox -
Mattia Dongili -
Patrik Jakobsson