Created attachment 85048 [details] dmesg output: system boot + a couple of S3 suspensions + a S4 hibernation Opening this as suggested in bug #67161 comment #6. Running Fedora 19 with a live USB on an old system with Creative Labs Graphics Blaster Riva TNT: Linux localhost 3.9.5-301.fc19.i686 #1 SMP Tue Jun 11 20:01:50 UTC 2013 i686 i686 i386 GNU/Linux If I run dmesg I see some errors like: [ 5.213896] nouveau E[ VBIOS][0000:01:00.0] 0x012e[ ]: unknown opcode 0x43 or: [ 99.820645] nouveau E[ PGRAPH][0000:01:00.0] NOTIFY nsource: PROTECTION_ERROR nstatus: PROTECTION_FAULT [ 99.820677] nouveau E[ PGRAPH][0000:01:00.0] ch 1 [X[666]] subc 2 class 0x0042 mthd 0x0180 data 0x00003a04 [ 99.820697] nouveau E[ PGRAPH][0000:01:00.0] NOTIFY nsource: PROTECTION_ERROR nstatus: PROTECTION_FAULT [ 99.820714] nouveau E[ PGRAPH][0000:01:00.0] ch 1 [X[666]] subc 6 class 0x0044 mthd 0x0180 data 0x00003a04 [ 99.820732] nouveau E[ PGRAPH][0000:01:00.0] NOTIFY nsource: PROTECTION_ERROR nstatus: PROTECTION_FAULT [ 99.820749] nouveau E[ PGRAPH][0000:01:00.0] ch 1 [X[666]] subc 6 class 0x0043 mthd 0x0180 data 0x00003a04 [ 99.821101] nouveau E[ PGRAPH][0000:01:00.0] NOTIFY nsource: PROTECTION_ERROR nstatus: PROTECTION_FAULT [ 99.821121] nouveau E[ PGRAPH][0000:01:00.0] ch 1 [X[666]] subc 6 class 0x0019 mthd 0x0180 data 0x00003a04 The "unknown opcode" error appears at boot and waking up from S3/S4. Regarding the protection fault lines, it seems like they appeared on boot and on one of the wakeups from S3.
Created attachment 85049 [details] BIOS dump obtained from /sys/kernel/debug/dri/0/vbios.rom
Created attachment 85050 [details] BIOS dump obtained with vbtracetool I'm also attaching the BIOS dump obtained from vbtracetool, as requested, although it seems to be equal to the one from /sys/kernel/debug/dri/0/vbios.rom (just a single character differs). Let me know if you also need the POST trace.
The POST trace is what I had in mind as the vtracetool output. As for the protection faults, they're yet another issue from the bios. Would be good to figure out what causes them to get printed, and file another bug. (Really best to keep it to one issue per... issue.)
Created attachment 85078 [details] POST trace (In reply to comment #3) > The POST trace is what I had in mind as the vtracetool output. Sorry, I didn't understand. Here it is. > As for the protection faults, they're yet another issue from the bios. Would > be good to figure out what causes them to get printed, and file another bug. > (Really best to keep it to one issue per... issue.) Ok, so let's keep this bug for the unknown opcode thing. I'm opening a new bug for that.
I've opened Bug 68854 for the protection fault problem. Let me know what can I do to try to figure out what it is causing it.
Created attachment 91533 [details] [review] Change heuristic for choosing script offset location for old bioses Please try this patch, should get rid of the unknown opcode error, and also may help with suspend/resume if there were problems before.
Hi Ilia, is there a guide anywhere on how to apply a patch, build the patched driver and use it for testing? I'm not a Linux kernel expert...
(In reply to comment #7) > Hi Ilia, > is there a guide anywhere on how to apply a patch, build the patched driver > and use it for testing? I'm not a Linux kernel expert... Grab a copy of the kernel (the patch is against 3.13-rc7, but it should apply cleanly to just about any 3.7+ version), apply the patch (patch -p1 < thepatch), and then build as usual. Here's a (fairly complex) guide to building kernels on Fedora: https://fedoraproject.org/wiki/Building_a_custom_kernel Although that is for generating rpm's... you can probably do something much simpler for just a local install, but I can't help with that (these distros tend to expect initrd's, etc, which I know fairly little about and thus avoid). Let me know if you don't plan on testing this out in the next week or so; I think the patch is fairly safe to just check in anyways, so you'd be able to test it out eventually in a future release.
Hi Ilia, honestly I don't know if I could test this within a week or so, because I would need to make a Fedora installation on a new disk/partition, sort out how to build a custom kernel with patched nouveau and test it (I've never done this before, maybe something like that ages ago on a Slackware 4 distribution... :-P). In fact, the tests I made were on a live Fedore 19, because the actual installed distribution I'm currently using on this system is an OpenMediaVault (based on Debian Squeeze), which is too old to try this. I can afford this, but I can't bet on the time I will need. If you feel safe to check it in anyway, I will surely test a live distribution with the new kernel as soon as it will become available (or, in the mean time, I may be able to do all the steps needed to test this patch on Fedora 19...). By the way, if you check it in now, which new Linux kernel version do you expect to inherit the fix?
The fix is now upstream, should appear in 3.13-rc8 (as well as the final 3.13 release which should happen in a few weeks). If you test it out, and everything works (including suspend/resume/hibernate), I'll ask for it to be included in "stable" kernels.
The fix should be in 3.13.0 and later. I'm going to mark this bug as fixed, but do test it out when you get a chance and let us know whether it fixes your issue (and/or breaks anything, like suspend, since vbios scripts are found now).
(In reply to comment #11) > The fix should be in 3.13.0 and later. I'm going to mark this bug as fixed, > but do test it out when you get a chance and let us know whether it fixes > your issue (and/or breaks anything, like suspend, since vbios scripts are > found now). Hi Ilia, just to let you know that I got to install Fedora 19 on a new hard disk and that I'm following the procedure you pointed me to build a patched custom 3.12 kernel with your patch applied. It's currently compiling (it takes a lot of time on this old Pentium 3...). When I've completed my testings, I'll let you know. On the other hand, I have another small glitch: the maximum resolution proposed by the monitor configuration utility of Fedora is 1024x768@60Hz, while my monitor preferred resolution is 1280x1024 and it can support up to 75Hz resolution. I see that the xrandr output is not consistent with what I get using monitor-get-edid+monitor-parse-edid, which returns the correct data. Is this something related to the nouveau driver?
(In reply to comment #12) > (In reply to comment #11) > > The fix should be in 3.13.0 and later. I'm going to mark this bug as fixed, > > but do test it out when you get a chance and let us know whether it fixes > > your issue (and/or breaks anything, like suspend, since vbios scripts are > > found now). > > Hi Ilia, > just to let you know that I got to install Fedora 19 on a new hard disk and > that I'm following the procedure you pointed me to build a patched custom > 3.12 kernel with your patch applied. It's currently compiling (it takes a > lot of time on this old Pentium 3...). When I've completed my testings, I'll > let you know. Great! You could also have grabbed a pre-compiled 3.13 kernel off of rawhide, if that's availble. I'm really not sure what the Fedora situation is though, so I can't give specific advice. > > On the other hand, I have another small glitch: the maximum resolution > proposed by the monitor configuration utility of Fedora is 1024x768@60Hz, > while my monitor preferred resolution is 1280x1024 and it can support up to > 75Hz resolution. I see that the xrandr output is not consistent with what I > get using monitor-get-edid+monitor-parse-edid, which returns the correct > data. Is this something related to the nouveau driver? I believe you have a different bug already open about this, yes?
(In reply to comment #13) > Great! You could also have grabbed a pre-compiled 3.13 kernel off of > rawhide, if that's availble. I'm really not sure what the Fedora situation > is though, so I can't give specific advice. Hmmm... I will seek for further information, however applying the patch to 3.12 was easy, it's just so slow to compile. I left the PC running over night and this morning it's still there... It's building all the flavors of the kernel, so I should better try to just make one flavor next time, but I'm not sure about what to choose (the above page talks about xen, smp, up, pae, kdump, debug and debuginfo... and I'm not sure what would be the best in my case). > I believe you have a different bug already open about this, yes? Not yet. I already talked about it in a comment in bug #68854, but you didn't give me an ok to open a new bug! :-) Should I?
Hi Ilia, good news! After almost two days of hard work, the kernel compilation ended with success! With the new patched kernel, I don't find "unknown opcode 0x43" anymore in dmesg output (I'm going to attach it). Suspend and resume work ok! So, I think this is definitely fixed! Thank you! Unfortunately, the PROTECTION_ERRORs are still there (bug #68854). I'm also going to open a new bug for the resolution issue.
Created attachment 92960 [details] New dmesg output got after patching the 3.12 kernel
I created bug #74164 for the resolution issue.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.