Linux has no support for Nvidia GeForge 9400, has it?

[DiTBho]

Code: [Select]

        Chipset = nvidia_get_chipset(pd, REGS);
        Architecture = nvidia_get_arch(Chipset);
        if (Architecture == 0)
        {
                printk(KERN_ERR PFX "unknown NV_ARCH\n");
                goto err_out;
        }


Code: [Select]

static u32 nvidia_get_arch(u32 Chipset)
{
        u32 arch = 0;

        switch (Chipset & 0x0ff0) {
        case 0x0100:            /* GeForce 256 */
        case 0x0110:            /* GeForce2 MX */
        case 0x0150:            /* GeForce2 */
        case 0x0170:            /* GeForce4 MX */
        case 0x0180:            /* GeForce4 MX (8x AGP) */
        case 0x01A0:            /* nForce */
        case 0x01F0:            /* nForce2 */
                arch = NV_ARCH_10;
                break;
        case 0x0200:            /* GeForce3 */
        case 0x0250:            /* GeForce4 Ti */
        case 0x0280:            /* GeForce4 Ti (8x AGP) */
                arch = NV_ARCH_20;
                break;
        case 0x0300:            /* GeForceFX 5800 */
        case 0x0310:            /* GeForceFX 5600 */
        case 0x0320:            /* GeForceFX 5200 */
        case 0x0330:            /* GeForceFX 5900 */
        case 0x0340:            /* GeForceFX 5700 */
                arch = NV_ARCH_30;
                break;
        case 0x0040:            /* GeForce 6800 */
        case 0x00C0:            /* GeForce 6800 */
        case 0x0120:            /* GeForce 6800 */
        case 0x0140:            /* GeForce 6600 */
        case 0x0160:            /* GeForce 6200 */
        case 0x01D0:            /* GeForce 7200, 7300, 7400 */
        case 0x0090:            /* GeForce 7800 */
        case 0x0210:            /* GeForce 6800 */
        case 0x0220:            /* GeForce 6200 */
        case 0x0240:            /* GeForce 6100 */
        case 0x0290:            /* GeForce 7900 */
        case 0x0390:            /* GeForce 7600 */
        case 0x03D0:
                arch = NV_ARCH_40;
                break;
        case 0x0020:            /* TNT, TNT2 */
                arch = NV_ARCH_04;
                break;
        default:                /* unknown architecture */
                break;
        }

        return arch;
}
(linux kernel v6.7)

umm, it's not in the list, I expect that on a Mac-Mini/intel 2009, it will only work in VESA mode or as EFI-console.

Code: [Select]

        unknown architecture
I don't care much about the framebuffer, but I would at least like to be able to use its 256Mbyte of video RAM.

Does anyone know if there are any experimental drivers? 

[Gerhard_dk4xp]

I have a very outdated NVIDIA card in this computer and earlier Linux Mint
versions tried to insist in the nouveau driver. That failed for 3D.

I downloaded the correct driver from NVIDIA myself and and installed
it by force. It worked better, give or take some complaints.
The current Linux Mint seems to have dropped the resistance.

Also, my Dell XPS13 could not do 3D with Intel graphics. VMware complained
about that. I did not find a solution, but it finally worked with last
autumn's Mint.

cheers, Gerhard

[DiTBho]

nouveau

drm/nouveau seems interesing 

Code: [Select]

CONFIG_DRM_NOUVEAU=y
CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=y
CONFIG_NOUVEAU_DEBUG=5
CONFIG_NOUVEAU_DEBUG_DEFAULT=3
(kernel 6.1.* - 6.7.*)

Code: [Select]

nouveau 0000:02:00.0: fb: 256 MiB stolen system memory
nouveau 0000:02:00.0: DRM: allocated 1280x1024 fb: 0x50000, bo (____ptrval____)
fbcon: nouveaudrmfb (fb0) is primary device
nouveau 0000:02:00.0: [drm] fb0: nouveaudrmfb frame buffer device

At least it allocates video ram correctly, which is what I'm interested in.

[radiolistener]

nouveau don't works with old nvidia cards, it just leads to system hung on boot and needs to be removed in order to avoid system hung.
Some time ago, you were able to install nvidia 390 driver and it worked great, but now it cannot be compiled due to changes in kernel.

[DiTBho]

Forgive my total ignorance, I usually never use a video card as I tend to use computers remotely from an hardware x11 terminal, so when it comes to video card support well .. the best I can remember is ATI128, and MGA{1, 2}, ... umm ... before 2004?

Happy days, unfortunately gone ...

Now they want a damn framebuffer on that bloody Mac-Mini 2009. I'll see what I can do.
However, you have already given me excellent ideas 

[golden_labels]

GeForce 9400 belongs to the NV96 family, which is the same as GeForce 9500 from which I write right now. It’s supported by nouveau (as NV50). I didn’t have to make any adjustements compared to stable kernel (witch Arch patches).

Recently I’m experiencing a single EGL issue affecting wxGlCanvas, but it’s not clear whether it’s Nouveau, libvndgl or wxWidgets to be blamed.

[Gerhard_dk4xp]

nouveau don't works with old nvidia cards, it just leads to system hung on boot and needs to be removed in order to avoid system hung.
Some time ago, you were able to install nvidia 390 driver and it worked great, but now it cannot be compiled due to changes in kernel.

As you can see in the   inxi -v7  exerpt in the screen pic above, 390.157
runs on my Linux Mint (current). And it is compiled by Nvidia, which is
why the open source fanatics try to insist in nouveau.

[DiTBho]

why the open source fanatics try to insist in nouveau.

uhm, I put 500 euros into a totally OpenSource/Hardware laptop, a sub-notepad that objectively sucks because of how badly it works, how inconvenient it is to use and how many { hardware, software , firmware } problems he has, like 500 euros to use something with keyboard and LCD like x11 and vt220 terminal, which not even works decently.

motivated by "fanaticism"...well, yes and no; what drives me to continue working on it, even if it sucks, is that the next iteration will probably be RiscV, and therefore I will already be prepared

however... talking about that bloody GeForce 9400, I need the source for two reasons
1) because I need to compile the kernel in order to include custom features and I don't like to have a video-driver that breaks
2) because I have to hack and modify the video driver itself

So, that's why I insist in Nouveau, which ... umm, I hadn't even heard of it much because I've never been interested in the "Nvidia close-source vs reverse enge" question that much, now I see that Nouveau works for what I need to do, and that's enough for me 

[radiolistener]

As you can see in the   inxi -v7  exerpt in the screen pic above, 390.157
runs on my Linux Mint (current). And it is compiled by Nvidia, which is
why the open source fanatics try to insist in nouveau.

yes, nvidia 390 driver currently works for linux mint. This why I switched to linux mint recently. Previously I was used linux arch and ubuntu, and they both were boken at some day after apt update. For linux arch I found some manal fixes in nvidia source code, but Ubuntu was broken with no way to install something and no way to fix source code.

[radiolistener]

So, that's why I insist in Nouveau, which ... umm, I hadn't even heard of it much because I've never been interested in the "Nvidia close-source vs reverse enge" question that much, now I see that Nouveau works for what I need to do, and that's enough for me 

Unfortunately nouveau leads to fatal error and deadlock at boot time for my GTX460. The system don't boot with it. The only way to boot with nouveau driver is to modify grub to boot with nomodeset option

[DiTBho]

Unfortunately nouveau leads to fatal error and deadlock at boot time for my GTX460

I don't care about any Ubuntu, Arch, Mint. etc.
Untill they have interesting patches.
Linux v6.1.* Vanilla: fouveau-fb works fine on my mac-mini intel 2009.
That's all 

[Nominal Animal]

And it is compiled by Nvidia, which is why the open source fanatics try to insist in nouveau.

No, it is not.

Nobody insists in you using Noveau, unless you're asking them to help with your problem.  Anyone you ask suggestions from, if they know enough to be worth asking, will tell you that the benefit from using open source is that the developer community can help fix bugs, whereas with closed source drivers, only the vendor can help.

It is not ideological, it is purely practical.  "Fanaticism" or "zealotry" is not involved.  The Linux kernel has no separation or isolation between modules, and most bugs left over nowadays are complex interactions.  Normal bug-finding tactics and approaches just do not work when the kernel is tainted –– which itself is just a label applied when kernel problems become much harder to resolve; loading proprietary kernel modules only being one cause among many.
That is, it does not matter whether the bug seems to be related to the closed-source driver or not.  If one has been used since last reboot, it makes debugging any kernel problem very difficult or impossible.

For non-developer users, it is often impossible to grasp the fact that even though the end user vehemently believes the problem has nothing to do with the proprietary kernel driver they're using, because of the structure of the Linux kernel, having had one loaded at any point since the last bootup/reboot makes kernel debugging/problem solving futile.

It is even more difficult to understand that the number of end users affected are completely irrelevant to the open source developer community, because they do not contribute anything.  Open source communities operate under free market rules, with useful contributions being the main currency.  It is also why the number of desktop users is absolutely irrelevant to open source Linux developers: they bring nothing to the table, and are thus irrelevant.

Similarly, having stable interfaces for out-of-kernel modules would bring nothing positive to the kernel developers, only lots of extra work and restrictions on developments.

I have fixed Linux kernel bugs.  I have also had to decline even trying, because the person struggling with the bug was using a proprietary driver, making it likely that any investigation I would do would be stopped at the proprietary driver black box, and thus not only make the investigation fruitless, but also annoying the heck out of me, because when I start an investigation, I want to see it through.  Being stopped by a black box is incredibly frustrating.
I have also had users call me a "open source zealot" and "fanatic" behind my back because of this, and I do not appreciate it, because I'm nothing of the sort.  I often work with closed source and proprietary stuff, with Tux being my mascot, not my idol.  Even RMS, the most vocal open source advocate there is, has logical and reasonable reasons why everyone should prefer open source, and is thus, by definition, not a "zealot" or "fanatic".

[golden_labels]

The reason I dropped Nvidia’s proprietary module was the Nvidia Zombie Apocalypse. The module somehow managed to mess up signals handling at kernel level, leading to processed becoming unreclaimable zombies.

The funniest part? Signals delivery being broken also interfered with debuggers, making it hard even for Nvidia to pinpoint and fix the issue. Own poison has been tasted. I guess that was a week in which the entire dictionary of English profanity must have been used at Nvidia’s offices. And TBH I feel bad for the devs, as they’re not to blame — they only work there.

[Nominal Animal]

The module somehow managed to mess up signals handling at kernel level, leading to processed becoming unreclaimable zombies.

Yep.  These bugs show up as complex interactions, even when the original cause in the source code is just a simple typo.
Anything that exhibits simple and repeatable problem behaviour is caught in automated testing, linux-next, or by the developers' own users (the test victims, as I call them).

hard even for Nvidia to pinpoint and fix the issue.

At least they have the source code to work from.  Just think how it would be to try and debug that with only the runtime binaries.  I think I'd rather chew off one of my toes before trying to solve that kind of a bug using the binaries only; it is that hard and frustrating.

That is all there is to the "rejection" of closed-source drivers.  What bugs me, is the way the end users call us 'fanatics' and 'zealots' for "refusing" to fix their bugs related to closed-source kernel modules.  They themselves refuse to believe it is not a choice on our part, just a consequence of not having the sources to work from.  It is unfair, lazy, dishonest, and fucking annoying.

[SiliconWizard]

I think NVidia just don't give a shit, and with all their shenanigans, including the latest fricking pile-of-shit NVidia's communication about how people should just stop learning how to program because this is obsolete and their AI will do it all, they just deserve a painful slow d*th in their own vo*it.
 

[Nominal Animal]

It's not that bad, actually.  Nvidia has lived by two things, and two things only: game performance and CUDA.  Game performance is their desktop business, and CUDA their server/HPC side business.  They cannot open source either one, because a lot of the former is licensed, and open sourcing the latter would destroy their market capture mechanism.  I suspect that if Nvidia tried, the executives would be sued by the shareholders.

NPU units integrated to ARM Cortex and RISC-V system-on-chips (like the 0.8 TOPS Rockchip NPU on RK3568, a quad-core Cortex-A55) are challenging Nvidia on the AI front when power consumption is taken into account.  This means Nvidia has to minimize the cost of supporting already sold chips, if it intends to grab a significant part of that market long-term, like CUDA did for HPC acceleration.

Unfortunately, the only one who can provide Nvidia drivers to different kernel versions is Nvidia themselves.  The Linux kernel cannot have stable driver interfaces and stay as nimble as it now is (with entire subsystems rewritten/refactored when something better is invented/discovered/implemented), so proprietary Nvidia drivers are wholly dependent on Nvidia for driver updates/backports; no open source developer can help with that.  And it just does not make business sense for Nvidia to do that for more than a few kernel versions per graphics chipset.

If you want to be angry about something Nvidia, be angry at them locking themselves to a monopoly-reliant product scheme.  They cannot move from CUDA to OpenCL, for example, because that would eradicate their customer lock-in, and only open themselves for competition and likely long-term loss.
And of course to end users who call open source developers 'fanatics' and 'zealots' simply because those end users believe they refuse to help with their closed-source driver problems out of spite, even though the facts have been stated time and time again, that it is a practical limitation, not an ideological one.

I'm just happy that neither Intel nor AMD got stuck trying to keep their driver code proprietary, and that so many Mali OpenGL ES GPUs are supported by the Panfrost open source driver.  These suffice for my current needs, without closed-source kernel drivers, letting me do kernel hacking whenever I want.  (The current laptop I use uses integrated Intel HD Graphics 620 via the i915 driver, and works quite well for my needs.)  In virtual machines, the VirGL Mesa 3D driver passes OpenGL (including shaders) primitives to the host machine for rendering, which lets Linux VMs using that driver use the host OpenGL implementation for rendering the VM display(s); it too is open source.

Nvidia GeForce 9400 variants belong to the Tesla ("NV50") family, like golden_labels already mentioned.  The Nouveau driver support matrix indicates it should work.  Power management hasn't been fully implemented, and that impacts performance.  HDMI Audio won't work, suspend should work, kernel mode set and basic 2D and 3D acceleration should work.  Based on the matrix, I'd expect the open source driver on 9400 to work for desktop use, matching what golden_labels reported for the close relative, GeForce 9500.

[golden_labels]

Another issue Nvidia is facing with their business model is that they’re almost entirely an intellectual property mogul. Unlike Intel and AMD,⁽¹⁾ Nvidia doesn’t produce anything. Instead, they are based on licensing and offering services to actual producers/providers. Having absolute control over every aspect of their environment is crucial for making money. Any freedom is sawing off the branch on which they are sitting.

⁽¹⁾ AMD separated their fabrication process into another company, but this is an organisational change. It’s more like outsorcing than independent manufacturing.

[Nominal Animal]

Yep.

What really matters, is understanding the limitations of each licensing model, and whether the hardware is worth the effort/price/tradeoffs.  These are just tools, not a religious book to follow for life guidance.

GeForce 9400 was introduced around 2008 or so, and having any driver support for it today is kinda special.

Even open source code suffers from 'bitrot' (tools and interfaces progressing beyond the assumptions at the time it was still actively maintained): it doesn't just "stay" useful as-is, unless you use an entire system, snapshot-like, from the relevant era.  It is also why contributions are so crucial in an open source ecosystem, as without them everything will just wither and die, even if it had a billion active end users.

The AMD-NVidia merger planned a couple of years back was really scary, because if it had happened, it might have forced AMD to adopt a similar closed-source business approach, and I believe that would have been devastating for the entire industry, not helping anyone, even NVidia.  There is a reason why most servers and all Top 500 HPC clusters run Linux, and that reason is not zero cost.  Open source has a lot to do with it all.

[radiolistener]

As you can see in the   inxi -v7  exerpt in the screen pic above, 390.157
runs on my Linux Mint (current). And it is compiled by Nvidia, which is
why the open source fanatics try to insist in nouveau.

After your message, I tried to install Linux Mint with nvidia 390.157 driver and it was installed and worked ok for my GTX460.
The only issue is that it didn't had support for OpenCL (which worked ok for Linux Arch with driver 390.157). This is serious issue.

A week ago, I tried to boot it again and it hung at boot time with some issue related to video card initialization. 

Both Linux Mint and Ubuntu has a very bad support for old nvidia videocard drivers.
I will try to install Linux Arch again and see if there is fix for the nvidia 390.157 driver.

Can someone suggest - is there any working Debian-based distro which supports Nvidia GTX460 cards (include OpenCL) just out of the box with no issues?

[Karel]

Linus Torvalds Gives Nvidia the Finger. Literally

nVidia: "the single worst company"

https://www.wired.com/2012/06/torvalds-nvidia-linux/