Re: segmentation fault with NVIDIA 32bit part
On Tue, Oct 06, 2009 at 09:45:58AM +0200, thveillon.debian wrote:
> I currently have 185.18.36-2 from Sid installed, my package list look like :
>
> aptitude search ~S~i~nnvidia
>
> i nvidia-glx
> i nvidia-glx-ia32
> i nvidia-kernel-2.6.31.2-vanilla64 << this is the kernel module built
> with "module-assistant", you won't find this one in your package manager
> i nvidia-kernel-common
> i nvidia-kernel-source
> i nvidia-libvdpau1
> i nvidia-libvdpau1-ia32
> i nvidia-settings
> i nvidia-xconfig
Thanks!
How did you figure out which packages you need? When I look at the
description for nvidia-glx, it says "binary drivers" and leaves it
totally unclear which kernel versions it supports. Besides, the
version in testing doesn't even support my graphics card. It must be a
couple years old ...
Then look at the description for nvidia-glx-ia32:
"These XFree86 4.0 binary drivers provide optimized hardware
acceleration of OpenGL applications via a direct-rendering X Server."
I'm not on ia32, I'm on amd64. That can't be the right package, and
when you look at the description, nvidia-glx does the same as
nvidia-glx-ia32.
And nvidia-kernel-common:
"This package contains files shared between NVIDIA module packages."
For which kernel???? For which driver version???????
nvidia-kernel-source:
"This package builds the NVIDIA Xorg binary kernel module needed by
nvidia-glx."
For which kernel???? For which driver version???????
I don't know about vdpaul --- is that included in the nvidia
installer?
You see why I don't want to mess with all that? I've been downloading
the installer from nvidias website and used that ever since I got my
first nvidia card 10 years or so ago. Until now, it has been working
just fine.
Why are the package descriptions so poor, and why can't there just be
one package you install?
> Off course if you want the Sid version you need Sid "main" and
Since my card isn't even supported in testing, I'd have to get those
packages from unstable. I've tried using packages from unstable a
couple times, but the results haven't been good.
> "non-free" in your sources.list, and do package (or rather level)
> pinning to prevent a global switch to Sid. In simple words, create a
> /etc/apt/apt.conf file (or in /etc/apt/apt.conf.d/), and put in it :
>
> APT::Default-Release "testing";
>
> You can also do more fine-grained "pinning" in /etc/apt/preferences (to
> be created) OR /etc/apt/apt.conf.d/00preferences (to be created).
> Something like :
>
> Package: *
> Pin: release a=unstable
> Pin-Priority: 101
>
> Should give you manual control over what's installed from Sid/unstable.
> Just google around for "apt package pinning"
Well, that reminds me of getting an ATI mach32 to work with OS/2
(especially 3.0), and I really don't want to go back to that. That's
why I keep buying nvidia: No problems to get them to work (until now).
Really, it's funny: The ATI mach32 worked with OS/2 3.0 only for so
long, then the driver suddenly quit working for no reason, and you had
to go back and try to install it again. About 60% of the time you
could; when you couldn't, you had to install OS/2 again. Now nvidia
and Debian are almost the same.
And if you ever tried OS/2 with an ATI mach32, you might understand
how tired I am of this.
> > Why can't I just use the nvidia installer? What's the difference?
> >
> >> If you do that directly it will build the default testing version, if
> >> you install Sid packages first, you can use m-a to build the Sid
> >> version, that's what I am using now on my Squeeze amd64 box.
> >
> > But I'm not using a Debian kernel.
>
> Neither am I, 2.6.31.2 here.
There doesn't seem to be a newer version of the nvidia driver
available than 190.32. So what's the difference?
> Nvidia installer complains, then goes on spreading bogus links all over
> the place, then the program tries to use 64bits libs in place of 32bits
> compat ones and fails. I am not a specialist in Nvidia driver internals,
> but it looks like it's seriously out of sync with Debian amd64
> development right now.
Maybe that is because you mixed testing with unstable?
> >> I am afraid it's more a problem with the proprietary nature of the
> >> Nvidia driver. If it sucks big time it will always be in last resort
> >> Nvidia's fault... Debian doesn't have to be tailored around proprietary
> >> programs just to meet their needs.
> >
> > It doesn't help users when things suddenly quit working.
>
> Sure it's frustrating, I hate when Skype or GoogleEarth go "boom" after
> an upgrade, but you've got to put the blame where it belongs. And all
> the more when running Testing or Sid, development and testing are what
> they are meant for.
So who is to blame? Obviously Debian changed something that made the
nvidia driver stop working. That is very much like the kernel
developers (or Debian developers, if you want to) making a change that
makes 50% of the harddisks suddenly stop working, and your comment
would be that the kernel (Debian) doesn't have to be tailored around
proprietary hardware just to meet the hardware manufacturers needs.
That still doesn't help the users. And is there no Debian debian
developer involved who has an nvida card? If there was, the problem
would never have entered into testing.
> Iceape is available in Sid only for now :
>
> apt-cache policy iceape
> iceape:
> Installed : (none)
> Candidat : 1.1.17-2
> Table de version :
> 1.1.17-2 0
> 500 http://ftp.fr.debian.org sid/main Packages
>
> It has been deprecated for a while in Testing, should reenter anytime
> (by popular demand as I understand ?).
If that's mozilla, the other browsers just can't replace it. They
don't even work right.
> If you don't feel like doing full-blown bug reports, open a specific
> topic on the relevant list (here for instance) for each problem you
> encounter (one per program), give as much specifics as you can so that
> others can try to reproduce the problem, or confirm the exact same
> setting is working for them (then you know it's probably a local
> configuration problem). Most of the time you will find help and be able
> to solve the problem. Otherwise you'll have material for your bug
> report, or if a more experienced user is able to reproduce the problem
> he might file the bug himself.
As if I didn't have other things to do ...
> Take a look at the "reportbug" program, it helps. IMHO testing or sid
> users should be (at least a bit) familiar with bug reports, that's the
> way to go with free opensource software.
Yeah, take a look at that:
"
*** Please submit non packaging issue (e.g. feature requests) bugs to
the Debian BTS and the upstream bugzilla
(https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox) and put a
reference to the bugzilla bug in the Debian bug report to ease bug
triage for the maintainers. You may need to reproduce this with
upstream's Firefox for upstream to take you seriously. Thank you. ***
Iceweasel extensions being a big source of problems, please either try
to reproduce your bug with a clean user or with your current user in
safe mode, with the "iceweasel -safe-mode" command line before filing
any bugs. If your bug disappears with a clean user or in safe mode,
you might want to find which extension is responsible for it and file
a bug to the appropriate package, bug tracking system, or author.
If your previous Iceweasel installation pre-dates 3.0, you might have
had problems since upgrading from one release to another can lack clean
support for some features. Please try moving your ~/.mozilla/firefox
directory out of the way to see if it helps with your issue.
Iceweasel requires the loopback interface (lo) to be up and unfiltered
to accept keyboard input and function correctly. Please make sure this
is the case before filing any bugs.
If you get crashes and none of the above hints helped, please also
try to run "MOZILLA_DISABLE_PLUGINS=1 iceweasel".
If Iceweasel still crashes, please install the iceweasel-dbg package
and run gdb with the "iceweasel -g" command line. At the gdb prompt,
type the following commands:
set pagination off
run
bt full
And attach the resulting backtrace to your bug report.
If you see XML parsing errors, please make sure you kill all running
Iceweasels and reload before filing any bugs.
"
So I'm supposed to spend a day or two messing around with it before
sending a bug report because the browser keeps printing
"(firefox-bin:17068): Gdk-WARNING **: XID collision, trouble ahead"
(whatever that's supposed to mean) and eventually crashes.
Great. I'm not willing to go to all these lengths. I take it this
browser just still sucks and we might have to be without a working web
browser forever or until mozilla eventually comes back. How long is
this situation going on now? About a year?
Galeon doesn't even start anymore. Konqueror for a web browser is more
a bad joke, and it draws all the KDE crap with it that then continues
to run in the background so that I have to go and kill it manually.
> I use Iceweasel mostly, I have Konqueror and Opera installed too,
> mostly for decoration purpose ;-), I don't feel restrained in my
> choice. They all work well mostly, most crashes I encountered by the
> past where linked to bad behaving extensions, or proprietary flash
> plug-in.
It doesn't matter to me if they crash because they can't deal with an
extension or because there is another problem. I haven't tried opera
in a very long time, but the other browsers currently available for
Debian only sort-of work since quite a long time now.
If the developers are at the point where they can't figure out if the
browser crashes because of an extension or because of something else,
maybe there is a need to develop some sort of interface or standard
for browser extensions that protect the browser against
extensions. Consider the extension as a program running under an OS:
The program shouldn't be able to crash the OS. And why are meaningful
error messages out of fashion?
> > Things used to just work in Debian, but they do that less and
> > less. That isn't good.
> >
> >
>
> Well, if stable doesn't meet your needs and other levels "bugs" you,
One problem with stable was that it took way too long before a new
release came out because when it finally came out, it could be a
rather big leap to upgrade, causing problems. The other problem was
that I sometimes needed more recent versions of some software or the
kernel which then wasn't available in/possible with stable. This might
have become better since they changed the release schedule, though.
But testing used to be stable. Now it's unstable.
> you can always try another Debian famous derivative where
> semi-automatic bug reporting is well integrated... (there's no
> bitter irony here, freedom of choice is what free software is
> about).
Yeah, but I'm not (yet) inclined to get a couple more disks and change
them around to try out different distributions. And are they so much
different? They do some things differently, but basically, they're all
using the same software.
And if other distributions have working web browsers, then why doesn't
Debian?
> If you want to carry on you can find help, and documentation
> too. But ranting about Debian's quality going down is just the way
> to attract flames, not helping hands...
Why should pointing out that the quality seems to continue to go down
since quite a while now attract flames? I've said it before, and it
didn't change. Perhaps that is something that needs to be discussed
and then can be improved upon, and it would be much better than
forcing users to seek more help and make seeking help and sending bug
reports more complicated and more time consuming.
But it is not something I could discuss, I can only point it out.
Hm, interesting. Try google for "debian quality statistic": There
doesn't seem be any.
Reply to: