|Summary:||[NV86] PDISP evo flush (?) errors, broken modesetting|
|Product:||xorg||Reporter:||Dominik George <nik>|
|Component:||Driver/nouveau||Assignee:||Nouveau Project <nouveau>|
|Status:||RESOLVED MOVED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
Description Dominik George 2013-10-30 08:01:00 UTC
Created attachment 88342 [details] dmesg output ** Slightly modified version from Debian Bug #728278 ** The nouveau driver fails on this hardware. A talk in #nouveau on Freenode turned up that the failure is related to the EVO engine responsible for modesetting. Here are the relevant parts of that chat, more explanations follow below: 08:02 < imirkin> nouveau E[ PDISP][0000:01:00.0] chid 0 mthd 0x0080 data 0x00000000 0x000d5080 08:02 < Natureshadow> that means? 08:02 < imirkin> that's a bit unfortunate 08:02 < imirkin> dunno, gimme a min 08:02 < Natureshadow> sorry, I am not a kernel hacker ;) ... 08:03 < imirkin> oh, that's the EVO flush 08:03 < imirkin> and the d5080 is probably the fifo position or something 08:03 < imirkin> uhm, silly question... do you have any indication that this hardware actually works? 08:05 < imirkin> (e.g. on windows, or using the nvidia blob or using the nv driver) 08:08 < Natureshadow> imirkin: it works with the nvidia driver 08:08 < imirkin> hm, ok 08:09 < Natureshadow> And GRUB can set the 1440x900 mode 08:09 < Natureshadow> So I assume VESA works as well 08:09 < imirkin> right, but that's a different mechanism 08:09 < Natureshadow> ok 08:09 < imirkin> what makes you say that edid is broken? is it broken with nvidia driver as well? 08:09 < Natureshadow> In any case, installing the nvidia-glx driver and loading the EDID file with X.org rather than at boot (nvidia does not support modesetting) works 08:10 < Natureshadow> imirkin: Yes, it is. 08:10 < imirkin> k 08:10 < Natureshadow> The display EDID is corrupted, I have been loading that EDID file forever with the nvidia driver 08:10 < Natureshadow> But as nouveau works great on all other hardware I have, I wanted to get rid of that unnecessary binary blob ;) 08:11 < imirkin> yeah, for some reason the EVO commands just aren't working 08:11 < Natureshadow> Is that something I can fix ;)? 08:11 < imirkin> (these are commands used to control the display engine, which controls the mode/etc) 08:11 < imirkin> well, if the nvidia driver works, it must be fixable 08:11 < Natureshadow> ok :D 08:11 < imirkin> the question is... how 08:12 < Natureshadow> I'm sure that question is a lot easier for you than for me ;) 08:12 < Natureshadow> I'm ready for any debugging, may it be as crazy as you like .) 08:14 < imirkin> well, the command likely comes from evo_sync() in nv50_display.c 08:14 < imirkin> or perhaps nv50_display_flip_stop 08:15 < imirkin> but why does it error out? who knows. i don't know much about the evo bits. 08:16 < Natureshadow> imirkin: hmm. so, seeing that the nvidia driver works, is this a bug in nouveau I should report, or is it due to my broken hardware? 08:16 < imirkin> given that the nvidia driver can work, it seems likely that it's a bug in nouveau [...] 08:33 < imirkin> it kinda feels like the evo engine isn't being turned on at all 08:34 < imirkin> probably some missed register write somewhere 08:34 < imirkin> (whereby it normally starts out as 'on' for everone except you) I must add two things: 1. The display EDID of this device is corrupted, but I have worked around that by ... 2. ... loading a corrected version of the EDID binary from a file. That worked (see dmesg), so I think it is irrelevant for the bug. The effect of this issue is that when modesetting, some garbage is written to the screen, the scrollback buffer is scrolled up a bit, but modesetting never really happens.
Comment 1 Dominik George 2013-10-30 08:02:54 UTC
Created attachment 88343 [details] VBIOS from graphics card
Comment 2 Martin Peres 2019-12-04 08:39:35 UTC
-- 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/xorg/driver/xf86-video-nouveau/issues/69.