The only error I get (The only place I see the word "ERROR") is this;
which as far as I know, is because the nvidia driver does not properly/fully support XRandR.

What errors are you seeing?

I run two I identical cards and this driver un! like the last one with the other kernel only picks up one. And all the other times it automatically resrves an IRQ setting for it. Not on this kernel and driver.
I could configure all I want but if the driver is not reading bios could be the problem.
I am a hardware person and I know my systems. this is becoming a resource issue.
From my point of view.

I read about this on some older cards where we had to manual load the second driver.
I did not realize this on this computer because only one monitor.

going to check so low level stuff and reboot BRB to append this message

append I am sure you have. but check. this is strange.

I don't really understand what you're asking above, but, if Xorg works one version, and NOT the next version, while the hardware & BIOS remain the same, then chances are good that my BIOS is not affecting anything.

And: both my monitors (both my PCI-E cards) turn on when I start X -- so I know the card is activated. My log clearly shows events from BOTH nvidia driver instances, one per card.

The problem, to be very concise is: X starts (more slowly than usual); both monitors come to life. Both have wallpaper on them. My WM is readying itself for usage (more slowly than usual); and then-- it all comes grinding to a halt, like still-life photography. That's it; both monitors are still on; wallpaper is still there. But the machine is hung.

Forgive me if I miss the point, but I don't think there's a BIOS setting I should be looking for. Do you agree?

Sasha :)

This might be a useless tidbit, but when I upgraded to 2.6.32.x kernels my NVIDIA 8800gts went to pot. I can't remember exactly what the issue was at this point, but what I do remember is that setting the PCIE frequency in the bios to 100 (above 100 was "not guaranteed to work") instead of auto was the answer. Probably useless info, but seemed worth mentioning.

@ damgar -- not necessarily useless info, all tidbits are appreciated, and since nothing else is working, new suggestions are good.

I *do* recall having some PCIE frequency settings in my BIOS, but haven't messed with them in a long long time. For the record, all the 2.6.32.x series kernels worked fine though for me, with Xorg-1.6.3; I didn't have to change anything in my BIOS for ages now, like maybe even more than a year.

My cards are "identical" 7200/7300 units, which are not really identical, but they are if you just read the box they came in ;) -- they're not too fancy: usually ~ $60 around here in the shops (canada)

Next time I reboot, I'll havva look in the BIOS and see if there's anything interesting in there worth fiddling with, particularly re: the PCIE slots.

Thanks,
Sasha

Checked BIOS -- there's no AUTO setting for the PCIE frequency, but I already had it set to 100.

Sorry took so long to get back.
kde4 according to KDE at this point No support for Xinerama . use xfce4 this is a kde init issue. second the nouvea driver will handle Xinerama but not in KDE4. KDE4 is only good for dual head. right now Gnome will some times crash with Xinerama.
This is a fast moving pace development and changing everyday.
Red Hat needs a open nvidia driver. they package for Big Blue (IBM) IBM wants it.
One huge driver does all.
Red hat has done some serious tweaks to the kernel with the nouvea driver Linus wants it in the kernel HE Got It. So Linus is happy Redhat is happy and So is Big Blue.
But of course 30 years ago big blue thought DOS was good stuff.
You can wait for Nvidia to leak more info to the big boys or go back a few steps.
I believe Pat is still updating Slackware 9
In my business new is not good and sometimes it takes 30 years for them to get back to were we started.

Hang in there
http://www.linuxforums.org/forum/lin...et-issues.html
http://www.nvnews.net/vbulletin/showthread.php?t=106517

Is the solution to this problem beyond the Slackware developer abilities?
 

I'm just wondering how many people are experiencing this issue, and whether this has been formally acknowledged by the Slackware developers as something that needs to be addressed? Granted, there's always the excuse given that we shouldn't be using Current in the first place. But then again, how is Slackware to be developed if no one ever runs Current?

Since I upgraded Xorg, I have not been able to run my system. After switching back to the earlier 1.6.3 version or Xorg, it has prevented me from even booting my system. All I get is the Black Screen Of Death. So how was this NOT caught before it was released? Does it only affect a relatively small number of users running Current? This is really odd. Since you can't run the X window without Xorg, and there are only two major video card distributors, how is it that no one tested the nVidia nouveau driver against the latest version of Xorg? Is the standard for developing Slackware packages simply that you can get them to completely compile and be packaged, without regard for whether or not they actually work?

I'm just wondering...
Xavian-Anderson Macpherson
Shingoshi

Well... I'm sure Pat does not have access to every possible combination of hardware, nor the time and inclination to try hundreds or thousands of 'rare' configurations to see if it works. Also, I think you're selecting small pieces of this thread, and jumping to conclusions based on your selections.

The nouveau driver DRM (though that isn't really the topic of this thread) is still only in the "Staging" area within the kernel, and based on the nouveau wiki, the kernel mailing list, and info in a few links provided within this thread, it is *definitely* not ready for production inclusion IMHO in anything but "testing" environments, or in environments where the system hardware configurations are known to be compatible, and not overly complex. It's under heavy development. I'm not surprised that there are problems with it, but that's why we need to be testing it and reporting what doesn't work. This has nothing to do with Slackware.

For all I know, I am the only person around, who is running Slackware -current, has two nvidia cards each separately running a single display, using Xinerama, and running i3 window manager. If I'm the only one, or one of a very small number of people running into trouble, it's not quite a Slackware issue IMO. Pat can only go with what X.org says is stable, for the most part. Sure, he might tweak something(s) but basically, unless X.org says the version x.y.z is fscked, we should probably be able to assume it's stable. And if X.org discovers that Xorg-a.b.c doesn't work on a setup like mine, but works for everyone else, they'll probably fix it (hopefully) OR I'll have to wait till there's some workaround.

Surely if enough people with "common" setups, are reporting that bloop, bleep, or blargh in Slackware, is not working right for them, then chances are good that Pat will fix or downgrade bloop, bleep, or blargh to a version that does work.

I'm not sure what exactly might have happened to your system when you upgraded to -current :) but it sounds like it wasn't a perfect upgrade. Mine was not either, but I have it fixed now. Maybe your upgrade is still borked a bit? :)

Sasha

Come on now.. stop being so level headed and reasonable about it. ;)

How is Shingoshi going to stir up trouble if you keep coming up with logical explanations for things?

Hello Shingoshi,

IMNSHO there is nothing in the present situation of -current which allow you to doubt of Slackware developers' abilities.

We only see a transient integration problem of Linux kernel including nouveau with xorg7.5 and libdrm-2.4.18.

But first I propose you an easy workaround which works with up-to-date -current fully installed "as is":
- blacklist nouveau
- cp /etc/X11/xorg.conf-vesa /etc/X11/xorg.conf

Not fancy of course but at least that will give you a working desktop under X.

I have posted an analysis of the problem we encounter now and possible workarounds, including using "nouveau" in Slackware-current here.

Here is a summary of the situation as far as I understand it.

1) The "nouveau" kernel driver is modularized in 2.6.33 as it should.

Thus during boot, as soon as the kernel recognize a nVidia chipset it tries to load the "nouveau" module.

This fail, because no firmware for the driver is available: none is shipped in -current for now (probably because it is not considered stable, which seems reasonable to my eyes) and even if it would, it's requested too early in the boot process.

That's why you get a black screen, unless you blacklist nouveau.

2) Now for the integration problem.

As Sasha pointed out, nouveau is under heavy development.

Thus the code for nouveau included in the 2.6.33 tree is already too old to work with libdrm-2.4.18, shipped with -current.

But you don't expect Slackware developers to ship a patched kernel including a git version of nouveau, do you ?

The X driver for nouveau is not included either in Slackware, probably because it's not considered enough stable to be included in Xorg7.5 release, which seems reasonable as well, at least to my eyes.

Ah, and don't complain to Slackware developers that nouveau be included in 2.6.33 tree, that's Linus' responsibility - but please note that it's among "staging" drivers for a reason.

A last word: in case you forgot, one of -current's purpose is to test doodads ;)

Best regards,

My apologies!
 

Simply put...

Xavian-Anderson Macpherson
Shingoshi

Look the Whole post was about getting Xinerama to work GrapefruiTgirl would love to have the monitors up and running. Kde4 is not able to handle Xinerama extensions. So your stuck with twin view. This has been going on a long time. We thought it was an xorg problem but it is not.
thought it was a nouvea but not.
Xorg 1.7.5 handle the extensions fine. It is kde4 init that has been a problem.
One of the major reasons why it took years for people to go over to kde4. Slackware took it on and has done the best as far as I am concerned.
If any one has Xinerama running with the kde4 and the 2.6.33 kernel and the propriety nvidia. Please go step by step how you did it. Then this post would be solved and global warming.
Right Al

:scratch:

I'm a bit confused, and maybe someone else is too, so just to clarify:

This thread hasn't much at all to do with KDE. I do not use KDE.

Nor does it have much to do with Nouveau, directly: Nouveau was proposed in this thread as a possible solution/workaround for what I/we thought may have been a problem with the nVidia blob driver + Xorg-1.7.5+Xinerama. As it turned out, Nouveau did not solve the problem.

I do not use TwinView. I use Xinerama. TwinView does not work for me, because I have my monitors connected each to a separate video card. I have to use Xinerama for this reason, as well as because no nVidia driver supports RandR well enough, if at all, to drive my cards+monitors properly.

Xorg-1.7.5 may or may not handle the extensions properly (AFAIK it works fine with NON-nVidia drivers, and with NON-multiple video cards+monitors).

I'm pretty sure Slackware developers are doing their work just fine, with what they have to work with, and for MOST people, this is just peachy. However, because of my hardware configuration, I'm having problems.

For the record:

The Hardware + Software (currently):
--2 nVidia cards.
--two monitors, one per card.
--i3 window manager.
--nVidia blob driver.
--Xinerama.
--Xorg-1.6.3 (because 1.7.5 does not work for me)
--No KDE.

The Problem:
When I upgrade to Xorg-1.7.5, X no longer works, with all other details remaining identical.

Cheers!
Sasha