Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Nouveau - works in Stretch, not in Buster

Graphical Environments, Managers, Multimedia & Desktop questions.
Message
Author
dajames
Posts: 6
Joined: 2012-10-01 07:47

Nouveau - works in Stretch, not in Buster

#1 Post by dajames »

I have an older PC that I use partly for testing. I have a Debian 9 (Stretch) system for that PC that works fine and that -- as far as I can recall -- required no special messing around to get it to work.

The machine has nVidia onboard graphics using the GeForce 6150 chipset (partnered with the nForce 430 CPU chipset). The monitor is a Dell U2410 whose native resolution is 1920x1200 at 60Hz. The monitor is connected via analogue VGA (through a 4-way switch box I don't want to replace, so switching to DVI isn't feasible). I'm using the Nouveau drivers.

inxi says this:

Code: Select all

daniel@welly-stretch:~$ inxi -G
Graphics:  Card: NVIDIA C51PV [GeForce 6150]
           Display Server: X.Org 1.19.2 drivers: nouveau (unloaded: modesetting,fbdev,vesa)
           Resolution: 1920x1200@59.95hz
           GLX Renderer: Gallium 0.4 on NV4E GLX Version: 2.1 Mesa 13.0.6
I've recently carried out a fresh installation of Debain 10 (Buster) on that machine (on a new hard drive, I still have the Stretch installation). That worked -- once I'd added "noapic" to the kernel commandline, which wasn't necessary under stretch (under Stretch I got an error message about it the sync'ing a timer every time I booted, under Buster it doesn't boot) -- but I've been have been having difficulties with the graphics.

At first, I was able to boot to a full-screen graphical login screen, but after logging in, when the screen attempted to diisplay the desktop, the monitor appeared to lose sync (?) and the image became garbled. The software appeared to be working but the screen wasn't readable (right-clicking produced a streak on the display that was probably an attempt to display a context menu, and hitting ESC made that go away again).

I overcame that problem by adding a nomodeset parameter to the kernel commandline. That gave me a 1280x1024 login screen (leaving the sides of the screen blank) and when I logged in I got a 1280x1024 desktop, which is usable but not full-screen, and not the native resolution of the monitor.

On Stretch, xrandr lists all the display modes I'd expect:

Code: Select all

daniel@welly-stretch:~$ xrandr -q
Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 4096 x 4096
VGA-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200     59.95*+
   1600x1200     60.00  
   1280x1024     75.02    60.02  
   1152x864      75.00  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   640x480       75.00    59.94  
   720x400       70.08  
DVI-D-1 disconnected (normal left inverted right x axis y axis)
TV-1 disconnected (normal left inverted right x axis y axis)
I've tried to use xrandr to set the modeline for the mode I want to use, as follows:

Code: Select all

daniel@welly-buster:~$ xrandr -q
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 320 x 400, current 1280 x 1024, maximum 1280 x 1024
default connected primary 1280x1024+0+0 0mm x 0mm
   1280x1024      0.00* 
   1024x768       0.00  
   800x600        0.00  
   640x480        0.00  
   640x400        0.00  
   320x400        0.00  
daniel@welly-buster:~$ cvt 1920 1200
# 1920x1200 59.88 Hz (CVT 2.30MA) hsync: 74.56 kHz; pclk: 193.25 MHz
Modeline "1920x1200_60.00"  193.25  1920 2056 2256 2592  1200 1203 1209 1245 -hsync +vsync
daniel@welly-buster:~$ xrandr --newmode "1920x1200_60.00"  193.25  1920 2056 2256 2592  1200 1203 1209 1245 -hsync +vsync
xrandr: Failed to get size of gamma for output default
daniel@welly-buster:~$ xrandr -q
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 320 x 400, current 1280 x 1024, maximum 1280 x 1024
default connected primary 1280x1024+0+0 0mm x 0mm
   1280x1024      0.00* 
   1024x768       0.00  
   800x600        0.00  
   640x480        0.00  
   640x400        0.00  
   320x400        0.00  
  1920x1200_60.00 (0x3ae) 193.250MHz -HSync +VSync
        h: width  1920 start 2056 end 2256 total 2592 skew    0 clock  74.56KHz
        v: height 1200 start 1203 end 1209 total 1245           clock  59.88Hz
daniel@welly-buster:~$ xrandr --addmode default "1920x1200_60.00"
xrandr: Failed to get size of gamma for output default
daniel@welly-buster:~$ xrandr --output default --mode "1920x1200_60.00"
xrandr: Failed to get size of gamma for output default
xrandr: Configure crtc 0 failed
daniel@welly-buster:~$ 
The display flickers on the last call to xrandr, but stays in 1280x1024 mode.

There are a number of issues, here:
  • Screen 0 is called "Default" rather than "VGA-1", which suggests that it hasn't been recognized correctly.
  • Each invocation of xrandr produces an error about getting the gamma for the output device.
  • The final call to xrandr produces the "Configure crtc 0 failed" error message. I've been unable to learn exactly what that means or what causes it.
Nevertheless, xrandr seems to accept the --addmode call, but fails to set the resolution using the new modeline (I can use xrandr to switch to a lower resolution and back again).

Comparing the Xorg.0.log files from the two machines I see very few differences until, on Buster, I see this:

Code: Select all

[    40.151] (EE) NOUVEAU(0): Error creating GPU channel: -19
[    40.151] (EE) NOUVEAU(0): Error initialising acceleration.  Falling back to NoAccel
[    40.151] (**) NOUVEAU(0): [COPY] acceleration disabled
I've been unable to learn what might cause an error creating a GPU channel, or what error -19 means.

I'm avoiding posting the whole of either Xorg.0.log as they're pretty big, but I can if necessary. In particular I do see, on both systems, that the monitor is recognized and that its EDID code is reported, along with all the modes (including 1920x1200) that I expect to see.

Neither machine has any xorg.conf file, nor any files in /usr/share/X11/xorg/conf.d beyond those that are installed by default.

As I said, I'm using the Nouveau drivers. I'm happy with those if they work. I don't use 3D or require more video acceleration than I'm getting. I did look at the possibility of using proprietary drivers. but nvidia-detect says that I need the 304 legacy drivers, and that they are not supported under Buster?

Code: Select all

daniel@welly-buster:~$ nvidia-detect 
Detected NVIDIA GPUs:
00:05.0 VGA compatible controller [0300]: NVIDIA Corporation C51PV [GeForce 6150] [10de:0240] (rev a2)

Checking card:  NVIDIA Corporation C51PV [GeForce 6150] (rev a2)
Your card is only supported by the 304 legacy drivers series, which is only available up to stretch.
What else can I try?

User avatar
stevepusser
Posts: 12930
Joined: 2009-10-06 05:53
Has thanked: 41 times
Been thanked: 71 times

Re: Nouveau - works in Stretch, not in Buster

#2 Post by stevepusser »

Some Nvidia cards require firmware-misc-nonfree, even with the nouveau driver. You could install that to see if it makes any difference after a reboot, and remove it if it doesn't.
MX Linux packager and developer

User avatar
phenest
Posts: 1702
Joined: 2010-03-09 09:38
Location: The Matrix

Re: Nouveau - works in Stretch, not in Buster

#3 Post by phenest »

Would you need firmware for such an old card?

I have an nVidia 6600 and 7600 with similar problems.
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D

dajames
Posts: 6
Joined: 2012-10-01 07:47

Re: Nouveau - works in Stretch, not in Buster

#4 Post by dajames »

stevepusser wrote:Some Nvidia cards require firmware-misc-nonfree, even with the nouveau driver.
Ah, yes, sorry.

I should have remembered to say that I have already installed the firmware-misc-nonfree package in the Buster installation, and it made no difference.

neodeb
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

#5 Post by neodeb »

DO NOT UPGRADE to Debian 10 Buster stable on your main systems; If you want the proprietary Nvidia 304 driver. Not compatible xorg etc..
(Where were the NVIDIA GPU warnings or 'time shift', Deb 9 restore abilities? Now, I have to migrate, many years, out of my fully upgraded Debian 10 non-working system.)
(And the complicated, separate /home folder debate for changing distros continues, as well)

I'm reporting: I can NOT get Nouveau to work in Buster stable Debian 10 either. I have a 304 nvidia GPU device built in. firmware-misc-nonfree installed

I spent days trying workarounds for some method of the faster nvidia 304 (foolishly not open sourced by EVIL nvidia and now stopped updating the Linux driver.)

I have seen Nouveau work on other systems ALMOST as good playing videos; but still stutters full screen 1080p. Great if Nouveau comes along but it's worse and they are saying newer Nvidia cards are locked out due to signing issues. Also I have seen Nvidia GPU chips fail a lot (unsolder etc and re-baked in my oven to prove it); far worse than other manufactures.

Plus; you need to keep the thermal paste fresh after several years (5 to 8?); which I do. if you start having overheat issues. Also you can add a fan to the GPU's without a fan.

Commentary:

So the thing is i have seen the darn thing work well without stuttering at 1080p and also play mid level 3D games. Last noted on stretch and older Linux Mint w/Mate. This required using the right software player for the popular compressed formats, their updated codex, and all planets aligned. Meaning some upgraded for Debian 9 started video stuttering; that no player setting (buffer etc.) could fix.

Politics: I'm well aware nvidia is an pain and no one should ever buy any product containing them. Countless hours wasted when the proprietary driver COULD be hacked to work well. And I know Debian (devs) is not responsible for Nvidia monopolistic Microsoft promoting lack of openness. So I spent days researching the following...

Debian 10 does conflict with Xorg 1.20 and ABI libraries; so nvidia 304 CAN NOT WORK WITH DEBIAN 10. Downgrading xorg is to complicated/unfeasible and Debian 9 (sadly) is the answer with a 304 nvidia GPU! I even tried the manual patched Nvidia 304 manual install (no PPA worked) that only partly worked in Mint 19.2! Though mint 19.2 has xorg 1.29 and matched; it has other problems and does not play video files. It only works with you-tube. So while I thought mint 19 was the answer it is also too new (due to the ABI's it says and this somehow kills playing vids. I have not determined if mint 18, 17 or 16 is best for 304 nvidia (if anyone knows). We have the problem of one of them working and then not working and then working again. So when matters.

So I hope you can see how this Nvidia driver issue is taking me away from my beloved Debian. Maybe a few more years for this GPU in Mint of some version. It just feels like Debian 9 is going back. Because it is. A Mint release (18? 17?) is like a MORE upgraded Debian 9 at this point. But it's a choice.

Of course a donated, under $30 used, or $50 sale AMD GPU is the answer if you have a slot. And don't play heavy games. Or Intel open GPU; but slower. Because these fine working old computers (including built in Nvidia devices) are not worth spending even that much or even any amount; when those funds can go into a new matched system. This is why we just need them to do the best they can and live-on UNTIL they are really obsoleted. Because now you get Nvidia refusal; and now the latest distro releases moving on.

While no distro should be held back and eliminating Nvidia is my goal (and should be yours); we should still have a way for the newest upgraded distro releases to WORK, as best they did; and we know they can.

Sadly, with a 304 card you have to use an older release distros. Old stable gets old. After 2019 (about 3 more months to this date) the next newer legacy Nvidia GPU has the same problem. You know those are even more capable GPU's. Which for now, some OLDER distro releases are kept up; but soon (a year?) they will be garnering to little attention. Thus more instability.

My question is why does the lack of highest end gaming mean xorg can't have a diversion for old cards that work perfectly fine. I have recently seen the thing play 1080 just fine; why digress and let nvidia win? This is fixed for other old proprietary devices. Because stuff just has to work; even though it's not fair what nvidia does. I'm concerned we are helping Nvidia obsolete devices; because we know they should not fail to release the development to open coders; if they will not do it. I do not think xorg locking (or whatever) locking older legacy cards out with the new Debian 10 is the way to go. We can retain our principles and FORK IT. So as not to lose all the work put into Debian 10. AND this will of course will filter-out badly otherwise, to Ubuntu/mint in time.

Because Debian just got harder. That's not a good principle we're protecting. Old Nvidia card are out there and smart people are not buying ANY more Nvidia. We need to support what is. Not what we hope is. I don't think we are helping Nvidia by forking Deb 10 to work with legacy cards. Too many people still use. The definition of planned obsolescence.

So if we don't make a work around are we partners in crime? I think so. We then help obsolescence before its time! And if we make it automatic have we helped nvidia get away with anything? I think not.

But should we tell all; that Nvidia has had there chance and never to buy from them. Heck yes! It's to late for Nvidia! It's ridicules. 1. poor support. 2. Not open. 3. Obsolete drivers. 4. Failing chips and build quality. 5. Close hardware/OS bias.

But why also through the baby out with the pixelated GPU bathwater? They are not unable. That's what's most egregious. Like a car, that mandates premium fuel; but then stop selling premium fuel and pretend it's obsolete, so you will buy a new model. Not going to happen! Hacks aplenty. It's what we do!
Open is freedom.

neodeb
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

#6 Post by neodeb »

TESTING BELOW INSTRUCTIONS:

The damn thing will not boot to GUI. Just tried 6 times. Didn't change anything. Ugly graphics and now waiting long periods of time often does nothing, or just shows a cursor. The two times I did get it to boot it ran video well. But then EVERYTHING but the cursor movement locks-up. What the hell is going on with nouveau?

Update: Put an old 6000 series AMD card and Mint 19.2 just works(fixes the patched manual Nvidia driver that play web vids yet not video for the hard drive(missing abi's?). Debian (Dual booted) will not even boot to recovery console and allow Internet to change drivers. I've seen this problem off and on. I had every intention of staying with Debian 10 on that Nvidia box. Oh well. Actually; I have Debian 10 upgraded on another that worked with a older AMD built in GPU.

======================================================================
I'm just getting Nouveau to work with Debian 10 Buster and video is NOT stuttering! There was an apt upgrade that might have helped. I used smxi and sgfxi helper scripts. Google them and click to install them on your system if you wish. Note these require Internet to run and self upgrade. I do not know which made the difference; but here's what I finally did.

[Edit your grub line with "e" and remove splash, and add BOTH: nomodeset single (then press F10 to boot text and....]

[For wired network]:

Code: Select all

dhclient

[For wireless] Example: nmcli c up wifishare

Code: Select all

nmcli c up <YOUR_ssid>

Code: Select all

apt update && apt upgrade
For just sgfxi:

Code: Select all

cd /usr/local/bin
wget -O sgfxi smxi.org/sgfxi
chmod +x sgfxi
Probe for devices and write an xorg.conf file:

Code: Select all

X -configure
This will fall back low graphics, then reboot, test it or edit your grub line again for booting to login/recovery:

Code: Select all

sgfxi -N vesa
This says it cleans up and leaves Nouveau.

Code: Select all

sgfxi -!32
Reboot without editing your grub line this time *and*....
It may go funky video lines for a minute; WAIT FOR IT. Bam! Nouveau works. (but didn't stay working)

At least this will help you will a saner way to test different drivers, GPU,s and releases; via sgfxi.
Last edited by neodeb on 2019-09-08 02:38, edited 17 times in total.
Open is freedom.

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Nouveau - works in Stretch, not in Buster

#7 Post by CwF »

Just the other day I decided to make a backup image of my recently cleaned main hypervisor, a stretch with 2 nvidia gpu's. I used a competing hypervisor image that I just backed up after finishing working on it in another machine, an amd 3x gpu buster. It has booted the nvidia box before, has the info to configure to it, and a user tailored for it, and it stalled....
Before the luks passphrase it returned 4-5 lines of nouveau gooblygook so I gave it a minute. It did figure whatever out and finally gave me a luks prompt after a few minutes. From there, all seemed normal. I had other things to do so I didn't investigate the new errors, I'll look for that once it's back in it's machine. About 6 months ago I did the same procedure and the hybrid stretch/buster of that moment didn't have the issue. I suppose this was before the last xorg update. Now, as I type out the issue I realize the nouveau complaint occurs before xorg enters, so I don't know? It was an iomem region error of some kind, oh well...

Overall, my recent experience does favor AMD again, for linux. Another vote is I run (ran) quadros for windows vm's, but on that competing amd box I use firepro sky gpu's and finally those drivers work for XP, so I'm set. So, with the new OS settled and bigger builds to come, I'll have a batch of nvidia's for sale...

I'll note the real first vote, over the last 2 years that stretch hypervisor has locked about 5 times, XFCE lost the host keyboard, sometimes the mouse too. Each time fully recoverable with mostly to totally clean shutdowns. Each time traceable to nouveau freaking out.

There is news that nvidia has released some helpful info recently and nouveau may improve soon? Or are we now at the point progress will be divided into wayland OR xorg?

neodeb
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

#8 Post by neodeb »

Thanks. So low mem error and freaky? Who know what's going on and how to fix it?
Open is freedom.

neodeb
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

#9 Post by neodeb »

I've followed this out to Debian dropped the 304 driver now at Debian 10; meaning it will never work (nvidia non-free) in Debian 10 Buster, due to xorg 1.20 leaving it behind.

Thoughts of switching to OLDER Mint or it's pattern OLDER Ubuntu (after their Debian sid derived past) is actually having the same problem.

Meaning LinuxMint 17.something (now all LTS versions) release would be the newest (yet to old for Mint to offer any more), to try for the Nvidia.304 class driver as it puts that in the Debian 9 originally derived class.

Also; the Ubuntu LTS version to try would be all the way back to 14.04 LTS.
https://askubuntu.com/questions/1164849 ... -04-failed
As folks are having the 304 proprietary driver issue/fail with 16.04 LTS and newer 18.04 LTS.

So Mint 17 or Ubuntu 14.04 is too old. You'd be better backing up and reinstalling Debian 9. So don't update past that with a 304 card.

The darn Nouveau driver is a great try; but it ALWAYS sucks. I thought it works, like for a second. I've just tired of it. Best wishes. It does not work.

All this ALSO starts going wrong for the next level (340?), less old Nvidia "legacy" GPU's by 2019's end! Nvidia 8000 model series I think.

1. Get a card (or system) that's not Nvidia. Beg, bargain or trade?
2. With 304 then you're stuck with Debian oldstable, 9 stretch, for stability. Which is fine now; but soon left out.
3. Good luck with Mint 19.2. I recommend Mate.
4. See if Mint makes it possible with their click to install driver manager.

Going back or waiting on Nouveau doesn't work well. But thank you for trying.

Conclusion is Debian 9 for the 304 driver to work. Where sgfxi helps get you there with relative ease. It's all about total system stability.

Of course I will NEVER buy a closed GPU. But we get stuff in trade and the darn thing CAN work. So you can say it's old and you can say Nvidia stopped; but that doesn't matter. Because it has NOT really become obsoleted just because new cards have improved. It's being cut down early, against owners choice, from poor support, closed hardware locking you and development out, and the newest OS's with xorg writing it off.

Now there's one possible, yet probably buggy solution I discovered; but did not finish:

I installed (in spare HD space, made into a new partition via gparted) Mint 19.2 (19.1 USB then upgraded to 19.2); like 5 days old Mint (Mate) 19.2. And it has xorg 1.19 yet; so that isn't the problem with 304. I think ABI's still are. The only PPA I found did not work on installing it. Is Mint working on a new one for their convenient hardware manager? In Debian that's sgfxi, for me. I don't know but it's blank in Mint 19.2 (all Mint is now LTS) now. Word on the street is the Nouveau driver in Mint 19.2 is still unreliable too. Try it. Perhaps it's least bad in mint. But anyway; I found a patch for the manual nvidia driver and installed all that. It WORKED, and felt like 304 did in Debian 9 Stretch(now old stable). But it would not play videos on your hard drive! Low end gaming was the same poor resolution(for speed); but for older, non demanding games only. NOW, I read there's a package you just need to reinstall; that the Nvidia installer messes up and then the video players should work. So you might try that; and so still be moving forward (cutting edge) and never back. I suspect that's not a perfect solution. It's going to be interesting to see; if Ubuntu and Mint come up with a NEW 304 solution, ongoing.

Mint versions vs. Debian's chart: https://askubuntu.com/questions/445487/ ... s-based-on

Mint to Ubuntu numbers here: https://en.wikipedia.org/wiki/Linux_Min ... on_history

And then there trying newer than 304 Nvidia drivers on 304 GPU's. I haven't tried that lately. I'm not sure that can work. Anyone?

NOTE:

Code: Select all

sudo apt --reinstall install libvdpau1
...Is the command after doing the patched Nvidia manual 304 install on Mint 19.2, for everything to work.
See: https://ubuntu-mate.community/t/nvidia- ... 4/16787/43

I PAINSTAKINGLY tried that patch on Debian (so you don't have to) and it definitely does not work. Xorg 1.20 locks out Nvidia 304 in Debian 10. Probably forever.

My replacing nvidia with an old AMD just worked automatically (I uninstalled nvidia drivers before switching cards) on Mint 19.2. I can't even get back to the working recovery console in Debian 10. Recovery only works sometimes??? When ever I get in; I'll try sgfxi for the AMD GPU. Preferring the open drivers.

This is what happens when AMD works with open devs and Nvidia is a monopolistic, closed off, asinine bunch of robbers. Justice is bigger than all suffering, ever.
Open is freedom.

User avatar
phenest
Posts: 1702
Joined: 2010-03-09 09:38
Location: The Matrix

Re: Nouveau - works in Stretch, not in Buster

#10 Post by phenest »

@dajames:
Is your video card an nVidia GeForce 6150. Is that AGP based or PCI-Express? It sounds old to me, so I'm guessing AGP.
AGP based cards are no longer supported by nVidia nor ATI/AMD.
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D

User avatar
sunrat
Administrator
Administrator
Posts: 6412
Joined: 2006-08-29 09:12
Location: Melbourne, Australia
Has thanked: 116 times
Been thanked: 462 times

Re: Nouveau - works in Stretch, not in Buster

#11 Post by sunrat »

phenest wrote:@dajames:
Is your video card an nVidia GeForce 6150. Is that AGP based or PCI-Express? It sounds old to me, so I'm guessing AGP.
AGP based cards are no longer supported by nVidia nor ATI/AMD.
It's 15 years old and built in to the motherboard from what I can ascertain. I would recommend an older distro or a newer motherboard. If the mobo has a PCIe slot you could try a new graphics card.
As you say it works in Stretch, use Stretch.
“ computer users can be divided into 2 categories:
Those who have lost data
...and those who have not lost data YET ”
Remember to BACKUP!

neodeb
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

#12 Post by neodeb »

My main system had a Nividia built-in (used for years) and I had a similar "304" class PCI-E Nvidia used instead in the slot, for it's DVI out adapted to TV with only HDMI.

Now I find an old AMD HD6670 (TURKS XT) with HDMI, and is not bad after-all; automagically in only Mint 19.2. (I made a 15GB partition in my Deb system HD space to test/compare it, installed). Both Buster based.

I thought my spare AMD GPU card was bad, as it would not (recent past, Deb 9) do anything; but black text flickering screen. Still doesn't in Debian 10.

So, it's fabulous on Mint 19.2 and I have done every trick in the book(via nomodeset in GRUB; to repair) to make it also work in Debian. It does not.

HD6670 (replacement) Debian 10:
1. Blacklisted Nouveau. Several ways and rechecked it.
2. Removed all drivers and installed AMD packages required.
3. Tweaked all configs and nothing but a boot to black (after initial text) as lightdm loops; and requires power switch off, without nomodeset.

What could be the reason?

And I do have the BIOS set for PCI-E only.
Last edited by neodeb on 2019-09-09 20:39, edited 1 time in total.
Open is freedom.

User avatar
phenest
Posts: 1702
Joined: 2010-03-09 09:38
Location: The Matrix

Re: Nouveau - works in Stretch, not in Buster

#13 Post by phenest »

What driver is Mint using? Can you be sure it's the correct one? It might be using VESA.
ASRock H77 Pro4-M i7 3770K - 32GB RAM - Pioneer BDR-209D

neodeb
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

#14 Post by neodeb »

Thanks; but oh no. I compare heavily; but to be sure then what is the best way to verify it's not trying VESA (because VESA worked at low res, fallback).

It (Mint 19.2) does not have a xorg.conf file.

It has radeonfb blacklisted, and I tried (deb 10) as not blacklisted.

I also tried the normally allowed vesafb blacklisted. Framebuffer isn't the issue. Just checked it; in case.

Mint uses the Radeon open driver (and parts) and was automatic.

I compared all blacklisted and loaded drivers and tried them in Deb 10; to no Lightdm starting solution.

Yes; I made sure the ati and radeon open drivers were installed and reconfigured. I even broke my system completely removing the video driver as it removed half my system without asking/showing me first.
READ THIS if you delete half your system tryng to fix it...
I fixed that well, from deep geek methods of finding what got deleted in /var/log/apt/history.log

Code: Select all

awk '!/^Start|^Commandl|^End|^Upgrade:|^Error:/ { gsub( /\([^()]*\)/ ,"" );gsub(/ ,/," ");sub(/^Install:/,""); print}' /var/log/apt/history.log
...Is the diddy that saved me. I devised and way to reinstall the numerous deleted packages; made from 3 different ways found online (THANK YOU).

You still have to edit the resulting file to pick out the session/packages that caused the deletions. And you want to get this file on a GUI system for easily doing that. Start after the Removed: section, in your session at or near the end of the packages extracted to the file. Name the edited/reduced file "packs" Then I came up with...

Code: Select all

apt install (cat packs) 
Your files of just removed (and edited) packages "packs"; being in the director path. I just used /root folder.
And it WORKS; after you run it, go back and edit it a few more times, for any packages no longer available. Even in the console

Code: Select all

nano packs 
and then using Ctrl+W to find each outdated pack to remove, can be done fast. (remember I still have no GUI with Debian 10 + AMD card). Then with your Internet up it reinstalls everything apt deleted. I still don't know how I missed a wall of packages to be removed. I tell you; it didn't show me. SO this is not relevant unless you delete half your system; but if you do then it's REALLY relevant.
Commandline: apt-get purge firmware-linux-nonfree libgl1-mesa-dri xserver-xorg-video-ati

...Did it. (Don't do that)

Commandline: apt-get install firmware-linux-nonfree libgl1-mesa-dri xserver-xorg-video-at

...Did NOT fix it.
So yes I made sure all the related firmware files are also installed. Mesa utilities also.

My solution here was to use a AMD card in place of Nvidia-304. It only works in Mint though.

Tally:
Nouveau does not work.
Nvidia-304 is not supported by Debian 10.
AMD HD6670 (open drivers!) in my Debian 10 does not work. (Mint does)

Why not the AMD open drivers Debian 10?
Last edited by neodeb on 2019-09-10 03:35, edited 2 times in total.
Open is freedom.

User avatar
sunrat
Administrator
Administrator
Posts: 6412
Joined: 2006-08-29 09:12
Location: Melbourne, Australia
Has thanked: 116 times
Been thanked: 462 times

Re: Nouveau - works in Stretch, not in Buster

#15 Post by sunrat »

neodeb wrote:what is the best way to verify it's not trying VESA (because VESA worked at low res, fallback).
To check what driver your GPU is using:

Code: Select all

$ lspci -k |grep -A 3 VGA
or if you have inxi:

Code: Select all

$ inxi -G
“ computer users can be divided into 2 categories:
Those who have lost data
...and those who have not lost data YET ”
Remember to BACKUP!

neodeb
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

#16 Post by neodeb »

Thanks very much. It says...

Kernel modules: radeon.

The microcode TURKS is also in /lib/firmware/Radeon

Code: Select all

24 -rw-r--r-- 1 root root 24096 Aug 22 21:04 TURKS_mc.bin
 8 -rw-r--r-- 1 root root  5504 Aug 22 21:04 TURKS_me.bin
 8 -rw-r--r-- 1 root root  4480 Aug 22 21:04 TURKS_pfp.bin
28 -rw-r--r-- 1 root root 24668 Aug 22 21:04 TURKS_smc.bin
Same size microcode files as in Mint 19.2.

(That's Deb 10 not working, Mint 19.2 working with no setup)

What in the world????
Open is freedom.

neodeb
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

#17 Post by neodeb »

But I can not verify the microcode is loading. I do not think they loaded. How do I fix that????

Mint 19.2 =

Code: Select all

dmesg | grep -E 'drm|radeon' | grep -iE 'firmware|microcode'
Shows:
[ 1.660912] [drm] Loading TURKS Microcode

Debian 10 =

Code: Select all

dmesg | grep -E 'drm|radeon' | grep -iE 'firmware|microcode'
Shows: <Nothing>.

Why not? What to check?
Is this a Debian 10 bug or oversight?

I tried linux 5 with backported firmware too, so it wasn't likely the kernel build.

I tried the buster-backport firmware. Didn't work.
Last edited by neodeb on 2019-09-14 19:39, edited 4 times in total.
Open is freedom.

neodeb
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

#18 Post by neodeb »

1. Thanks for those trying to help. In the end I could not find why my Radeon (I replaced the Debian 10 unsupported Nvidia-304 driver, nor Nouveau working card with AMD HD 6670 w/OPEN DRIVERS) yet the microcode didn't load (TURKS) in Debian 10, on MY MAIN WORK STATION (Since 2012, Debian 6 on this one). I have other working Debian installs and wanted to keep all on the same Debian release. As noted; another crappy built-in, worse performing AMD 300 series GPU system did work with Debian 10.

2. Only being left left with my test install of Linuxmint Mate 19.2 working the switched-out AMD GPU, by booting into a new test Mint install, on a 15GB /dev/sda3 partition, separate from full-upgraded Debian 10 (no X; but vesa for me) on Deb10 /dev/sda1 and mixed with my Deb10 /home user data; now I had some tough choices to make. Remember: BACKUP FIRST! I could have done another test (with another partition in free space) and a clean install of Debian 10 (from live mate); but wanted to KNOW the situation with my GPU's, with Debian 10 and LinuxMint.

3. While it would have been nice to have a separate /home partition or drive(and REMEMBER not to format it on clean installs); but that wastes a little space, making sure the system has enough for trying new things. I always said; I'd deal with my integrated /home data and this how I did it. While I've preached; that one can make Debian polished, like Mint, if you will; I like the polish LinuxMint Mate 19.2 (LTS Buster based) is doing, it works and it is very time saving for me.

4. Without reinstalling anything, again cleanly; I went radical and replaced my Debian 10 SYSTEM(only) in sda1 with the LinuxMint system *and also* its sda3(Mint) /home hidden configuration files; by deleting the Debian system (using sudo caja in mint; for convenience) and leaving only my data in /home/user on sda1 there, and then deleted ONLY the hidden Debian configuration files in Debian, old /home/user folder. This is tricky; because I manually searched all Debian "system" folders for any forgotten data outside its /home. In my case; I only kept my user login icon and historical upgrade notes in my sources list. I also went through all the old configuration folders and files (of apps I forgot about trying; as I always purge deleted apps configuration files) and looking for any setting I might have need to remember, for apps I've not yet installed on my new Mint system install. Double checked; before deleting old system AND hidden configuration folders and files. In the old (Deb 10 sda1) system, I ran across a special file that couldn't be deleted; until I looked up how. Then I just made sure everything in my test, sda3 install of Mint was what I wanted to keep and had no duplicate data that could ever write over my old /home/user data. Mint's test /home/user was basically empty of my data.

5. Now the whole Mint source was ready to copy the system (using the same /home/*user* name on the destination data partition), including the /home/user/ hidden config folders and files, onto the target/destination of the old sda1 drive, with my data as the only thing left in /home/use. You can't copy a live booted system, so I booted a live one from a USB made install stick, must be root (console) and you can't do a regular copy due to SPECIAL (they work with RAM) files. So both mounted in a live USB boot then you ALSO have to be very careful with command line syntax as follows...

Code: Select all

  $ sudo cp -afv /path/to/source/* /path/to/destination
Don’t forget the asterisk after the source path.
-a Archive copy
-f Force copy
-v Verbose info displayed

Note: The system copy over is MUCH smaller than my data in place. Much faster transition. And this is an SSD drive; but even on platters, the first place for the system was deleted, so new system would go back there, on the faster part of the spinning drives.

6. Now edit your /etc/fstab and replace (sda3's / in this example) UUID with the (sda1) UUID now instead. Issue blkid to see all UUID's.

NOTE: Don't make a "new" swap disk partition now or you will have to edit the UUID for swap in /etc/fstab *and also* for sleep resume /etc/initramfs-tools/conf.d/resume or you'll get errors on the next steps. You could just clone/reset the old UUID for any newly made swap partition; however.

7. Reinstall GRUB from the live boot method: https://howtoubuntu.org/how-to-repair-r ... tu-live-cd

DANGER! DO NOT USE ANY NUMBER LIKE 1, JUST A LETTER (like /dev/sda ONLY), FOR THE MBR OF THE DRIVE, WITH THE grub-install /dev/sdX COMMAND; else it will write over the first part of your partition(like sda1, DON'T use here), rendering data lost and system not bootable.

8. Then after testing, boot again from live USB and use gparted (install it live if you have to) to CAREFULLY remove the test partition /dev/sda3 (in my case) and resize /dev/sda1 to full space. Apply changes in gparted.

9. You may need to issue a

Code: Select all

sudo update-initramfs -u
, you can edit out the wrong UUID in the GRUB menu with "e" and CTRL-X to run it. And secondary kernels would need this too. You might just remove and reinstall your backup kernel(s).

10. It works!

I used Debian stable for everything, on many systems for constancy; due to excellent security upgrades, stability, stable upgrades within the release tier (for about two years before new stable) all mainly to save time (once installed and built-up) and I used to think Debian was the only one (two months after new stable) where a clean install was not always better. Now, a backup and clean install is always better. Separate /home is purely optional. And we ALWAYS need a backup anyway (I recently watched an EVO SSD die and have my backup). Therefore every two years I would spend some time upping Debian. This time sucked. Even after waiting over two months, after new stable to be cautious. If you're wisely still on Debian 9 as your MAIN system then stay there! Back up your data first.

This (no separate /home) method could be adapted for any distro or release, installed as a test(first), in spare HD space such as /dev/sda3 made by gparted, from live booted USB. You could even go back to Debian 9 Stretch oldstable. Just backup FIRST and be careful.
Last edited by neodeb on 2019-09-16 20:05, edited 1 time in total.
Open is freedom.

dajames
Posts: 6
Joined: 2012-10-01 07:47

Re: Nouveau - works in Stretch, not in Buster

#19 Post by dajames »

phenest wrote:Is your video card an nVidia GeForce 6150. Is that AGP based or PCI-Express? It sounds old to me, so I'm guessing AGP.
AGP based cards are no longer supported by nVidia nor ATI/AMD.
Neither. I have an Asus M2NPV-VM motherboard which uses the nForce430 chipset with integrated GeForce6150 graphics. It's a Socket AM2 board, and I'm using an Athlon64 X2.

It's far newer than AGP! The board would support a PCIe x16 external card, but I don't need any more power than the integrated nVidia chip provides.

neodeb
Posts: 120
Joined: 2007-08-09 02:49

Re: Nouveau - works in Stretch, not in Buster

#20 Post by neodeb »

@dajames Well you could go back to Debian 9 stretch, with the nvidia-304 proprietary driver (made easy by sgfxi) but oldstable and lack of Nvidia-304 driver upgrades will get old fast. And Nouveau is worse.

Open driver GPU is the way to go. And with low needs perhaps an AMD giveaway card (under $50 or $10 used or free) needs to find it's way into your PCI-E slot. Make sure you get the monitor connections you need. I'm enjoying HDMI out with no adapter needed.

Since Debian 10 buster stable cut-off the Nvidia unmaintained nvidia-304 via xorg >1.20, then I was starting to have some hacking success by patching the nvidia installer for nvidia-304 as working in LinuxMint newest buster based Mate 19.2; but still had video player error. Though, there was a fix for that too; that I didn't test. That might work for you; but if Mint's xorg goes to 1.20 then 304 is forever unsupported. Linuxmint 19.2 support runs out 2023, I think. You could test it; but it's not an easy fix like open driver cards. Linuxmint 19.2 + patched, manual Nvidia-304 (at every kernel upgrade) + video player fix. And then it might have bugs. Less then Nouveau probably. Let me know if this works well for somebody; but it's only a matter time (on current, upgraded, stable-ish software).

And there was mention of using a newer Nvidia proprietary driver number from Nvidia on an older card. I would be surprised if that worked and did not try it.

Side Note: You probably need the change the thermal paste under your CPU chip too. MIne is Athlon X2 with (not used) Nvidia 6150E built in also.

I hope for all open drivers; but we can't force this. Even when Nvidia cuts their proprietary support *and* adds more hindrance to reverse engineering (Nouveau) on newer GPU's; by their new closed source hardware "signing" requirements.

Please don't support Nvidia. Nvidia has had more chip failures too. But let's also not help Nvidia obsolete it's old cards. It just looks bad for open distributions compatibility; that we know did work well (built-in, low needs) on them. And we know open drivers (with manufacture collaboration) are a dream come true!

I think we should stop telling folks to try Nouveau, just to see. Before it works on most cards. Or at least a definite list.

It would be best to code in user friendly error messages (perhaps after rebooting into text), about the known GPU situations. And a nomodest activating GRUB selection (GPU recovery?), or at least a quick pasted command to add it with a descriptive (login to text only) user friendly title.

How about a maintained Debian GPU script (at failure) similar to sgfxi, easily apt upgradable to the latest solutions, options, links and text explanations; including sane selectable options and/or advice?

It's all about open hardware too! Please be patient educating many folks about this; but do tell people to buy open.
Open is freedom.

Post Reply