Re: segmentation fault with NVIDIA 32bit part
lee schreef: > On Fri, Oct 09, 2009 at 08:45:02AM +0200, Sjoerd Hardeman wrote: > >> My quake3 copy is running fine with the 64-bit nvidia drivers. Without having the 32bit compatibility libraries installed? I have quake4 and don't know about quake3, but all games that aren't 64bit seem to need the 32bit drivers. > The nivida driver seems to provide it's own libraries that replace the > ones that come from somewhere else (with xorg, I guess). > > What's quake3 using? SDL? You could check the quake3 executable to see > what it is (like: file quake3). /usr/local/games/quake3/quake3.x86: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.0.0, stripped > > Quake4 uses SDL and tries to load libGL.so.1, which it currently can't > because it needs the 32bit version of that. I have a /usr/lib32/libGL.so.1 from the ia32-libs package apt-file search libGL.so.1 ia32-libs: /usr/lib32/libGL.so.1 ia32-libs: /usr/lib32/libGL.so.1.2 Yet, installing nvidia-glx-ia32 might also provide you with the necessary file: nvidia-glx-ia32: /emul/ia32-linux/usr/lib/libGL.so.1 nvidia-glx-ia32: /emul/ia32-linux/usr/lib/libGL.so.173.14.09 My understanding, though is that nvidia-glx-ia32 is for 32-bit xserver environments (eg. xfree86). I do not notice any problem with the version of libGL.so.1 I use. quake3 does something like 90 fps at the highest quality on my laptop. Openarena doesn't do much better.. > Anyway, I've seen a forum post on the nvidia website saying that > you're supposed to use the nvidia driver that comes in your > distribution because it's supposed to be better integrated than the > installer provided by nvidia. > > So how do I solve the dependency problems with that? Just install nvidia-kernel-source, nvidia-kernel-common and nvidia-glx. Ignore the dependency problem of nvidia-glx for now. Continue doing a module-assistant prepare, m-a auto-install nvidia. That gives you a compiled kernel module, which will be automatically installed. At this moment the dependencies for nvidia-glx will be met so it will automatically be configured as well. Use "nvidia" as your graphics card driver in xorg (or use nvidia-settings as a tool to create an xorg for you) and everything should work. At least, for me that's the case ;) Sjoerd signature.asc Description: OpenPGP digital signature
Re: segmentation fault with NVIDIA 32bit part
> today I updated my testing installation. Now the 32bit part of the > NVIDIA drivers doesn't work anymore I don't have 64bit strong hardware but it sounds like the problem I have after a Linux Kernel is upgraded. For Squeeze/Sid I'm showing: 2.6.30-2 (686) After the upgrade I can expect the 'nvidia' driver to fail. I edit the /etc/X11/xorg.conf file replacing 'nvidia' with xorg's 'nv' driver. This will return the 'desktop' minus 3D capabilities. As of 10-12 22:52 UTC, the nvidia-kernel-source is at 185.18.36.-2 When the n-v-source is upgraded, compile it with: # m-a -t clean,a-i nvidia-kernel-source Run another apt-get update for the new glx versions and other apt-get dist-upgrade to install them. Change the 'xorg.conf file back to 'nvidia' and all is well once more. Whether any of the above applies to your situation, I cannot say. -- CK -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
On Fri, Oct 09, 2009 at 08:45:02AM +0200, Sjoerd Hardeman wrote: > >> >> My quake3 copy is running fine with the 64-bit nvidia drivers. > > > > > > Without having the 32bit compatibility libraries installed? I have > > > quake4 and don't know about quake3, but all games that aren't 64bit > > > seem to need the 32bit drivers. > Well, yes. This is what I've installed: > i nvidia-glx > i nvidia-kernel-2.6.31 > i A nvidia-kernel-common > i nvidia-kernel-source > And looking at the frame rate I must have *some* hardware acceleration. > Yet, I thought that the opengl support is in separate libraries, and > that nvidia is just a driver. A program does not use drivers as > libraries, is it? Don't you need 32 bit versions of either > libgl1-mesa-dri or libgl1-mesa-glx? Using apt-file, quake3 need a > libGL.so. I have /usr/lib32/libGL.so from the ia32-libs package. Well, I don't know exactly how it works. You need a kernel module for the card, eventually another module for AGP or DRI (or what it was) depending on your mainboard (I think I have something compiled into the kernel to support the card) --- but I'm not sure if you still need that when you have the card in an extended-PCI slot rather than in an AGP slot. Besides that, you need some libraries that seem to provide OpenGL functions --- and that's probably the part relevant for the games: If they need that, I guess they need those libraries to be 32bit when they are 32bit and 64bit when they are 64bit because 32bit libraries don't go together with 64bit applications. The nivida driver seems to provide it's own libraries that replace the ones that come from somewhere else (with xorg, I guess). What's quake3 using? SDL? You could check the quake3 executable to see what it is (like: file quake3). Quake4 uses SDL and tries to load libGL.so.1, which it currently can't because it needs the 32bit version of that. Anyway, I've seen a forum post on the nvidia website saying that you're supposed to use the nvidia driver that comes in your distribution because it's supposed to be better integrated than the installer provided by nvidia. So how do I solve the dependency problems with that? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
lee schreef: > > On Wed, Oct 07, 2009 at 01:36:58PM +0200, Sjoerd Hardeman wrote: >> >> lee schreef: >>> >>> On Tue, Oct 06, 2009 at 08:00:52PM -0700, David Fox wrote: More to the point, since you have an amd64 system, why bother with ia32 components? I don't recall any need for ia32 for nvidia. >>> >>> Where do you get a 64bit version of X3? Or X2? Quake? Doom? Tribal >>> >>> Trouble? And so on ... >> >> My quake3 copy is running fine with the 64-bit nvidia drivers. > > > > Without having the 32bit compatibility libraries installed? I have > > quake4 and don't know about quake3, but all games that aren't 64bit > > seem to need the 32bit drivers. Well, yes. This is what I've installed: i nvidia-glx i nvidia-kernel-2.6.31 i A nvidia-kernel-common i nvidia-kernel-source And looking at the frame rate I must have *some* hardware acceleration. Yet, I thought that the opengl support is in separate libraries, and that nvidia is just a driver. A program does not use drivers as libraries, is it? Don't you need 32 bit versions of either libgl1-mesa-dri or libgl1-mesa-glx? Using apt-file, quake3 need a libGL.so. I have /usr/lib32/libGL.so from the ia32-libs package. Sjoerd signature.asc Description: OpenPGP digital signature
Re: segmentation fault with NVIDIA 32bit part
On Tue, Oct 6, 2009 at 9:46 PM, lee wrote: > Then there would need to be only two packages: vdpau for those who > need it, and the rest (which could suggest vdpau which could tell you > which cards can use it). Doing that would probably not be possible, given the nature of this particular component. nvidia's drivers have always had a kernel-space component and a user-space component (the user-space component is nvidia-glx, the kernel is nvidia-kernel-source or variations thereof). Not having nvidia's drivers completely opem makes the process more complicated, since other drivers (intel, for example) have begun to put some of their code in the kernel proper, but essentially from the user's perspective it's a unified driver that exists totally in userspace. What complicates the matter further is that the kernel space part of the driver has to match the kernel you run. If you're on stable or testing then you might not have new versions of the kernel just popping up, but if you change the kernel, you have to rebuild the module. In some respect ubuntu automates this process - and perhaps debian does as well; I've not actively used nvidia since switching to intel back in December. But for instance, my virtualbox has a kernel space part and that gets automatically updated as part of the upgrade process any time the kernel changes. (And on karmic, new revs of the kernel are somewhat frequent.) But in general, separation of components is not uncommon. Sometimes documentation is separated from the executable, or a development set is separated from the libraries. That's to save on space, and not everyone who has a particular library needs the development component automatically installed. -- thanks for letting me change the magnetic patterns on your hard disk. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
On Wed, Oct 07, 2009 at 07:57:52AM -0700, David Fox wrote: > I think I meant that you didn't need ia32 for nvidia. You'll of course > need it for things that aren't available as 64-bit executables, or not > available as source. Over here, that is a pretty short list, since I'm > not into games much :). Indeed --- it's fine without the 32bit things, but without, the games won't work. I can wait because the game I want to play (X3) doesn't work anyway and they need to fix it first. But it bothers me having things working only 1/2 way. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
On Wed, Oct 07, 2009 at 01:36:58PM +0200, Sjoerd Hardeman wrote: > lee schreef: > >On Tue, Oct 06, 2009 at 08:00:52PM -0700, David Fox wrote: > >>More to the point, since you have an amd64 system, why bother with > >>ia32 components? I don't recall any need for ia32 for nvidia. > > > >Where do you get a 64bit version of X3? Or X2? Quake? Doom? Tribal > >Trouble? And so on ... > > My quake3 copy is running fine with the 64-bit nvidia drivers. Without having the 32bit compatibility libraries installed? I have quake4 and don't know about quake3, but all games that aren't 64bit seem to need the 32bit drivers. > Good to know. Thanks X2 is working great, though (but I haven't played it on amd64, only x86)--- if you're interested in X3, you might want to start with X2. Maybe they get X3 fixed at some time. Both games are _very_ similar, which is a good thing. I didn't get very far with X3 yet because of the crashes and because it's running in slow motion, but it seems to be a very good successor. After having played X2, I was waiting like 2-1/2 years for X3 to find out how the story goes on. I hope they'll also port the others ... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
On Wed, Oct 07, 2009 at 08:01:47AM -0700, David Fox wrote: > On Tue, Oct 6, 2009 at 9:46 PM, lee wrote: > > > > Link where? :) I have a 9800GT. > > Oops, I forgot the link. > > http://en.wikipedia.org/wiki/VDPAU Thanks! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
On Tue, Oct 6, 2009 at 9:46 PM, lee wrote: > > Link where? :) I have a 9800GT. Oops, I forgot the link. http://en.wikipedia.org/wiki/VDPAU > Unfortunately, there's no roll-back option in aptitude ... or is > there? If there was, there won't be any need to decide between stable, That would be nice. Installing the previous version (kept in /var/cache/apt/archives) did it for me. But rollbacks would be good. -- thanks for letting me change the magnetic patterns on your hard disk. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
On Tue, Oct 6, 2009 at 9:33 PM, lee wrote: > On Tue, Oct 06, 2009 at 08:00:52PM -0700, David Fox wrote: > >> More to the point, since you have an amd64 system, why bother with >> ia32 components? I don't recall any need for ia32 for nvidia. > > Where do you get a 64bit version of X3? Or X2? Quake? Doom? Tribal > Trouble? And so on ... I think I meant that you didn't need ia32 for nvidia. You'll of course need it for things that aren't available as 64-bit executables, or not available as source. Over here, that is a pretty short list, since I'm not into games much :). -- thanks for letting me change the magnetic patterns on your hard disk. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
lee schreef: On Tue, Oct 06, 2009 at 08:00:52PM -0700, David Fox wrote: More to the point, since you have an amd64 system, why bother with ia32 components? I don't recall any need for ia32 for nvidia. Where do you get a 64bit version of X3? Or X2? Quake? Doom? Tribal Trouble? And so on ... My quake3 copy is running fine with the 64-bit nvidia drivers. I got those from sid, by the way, and compiled them for a non-Debian kernel using 'm-a a-i nvidia' as suggested in the other thread. It also runs openarena which is a far superior opensource clone of quake3. I already told LGP a couple times that they need to make a 64bit version of X3 (even before it came out), but they refused and claim the 32bit version works just fine. But it doesn't work at all, it's running in slow motion and keeps crashing. For anyone who plans on buying that game, just don't. It's a nice game, but before they fixed these problems, it's a waste of money. If they don't fix it soon, they should take it back ... Good to know. Thanks Sjoerd signature.asc Description: OpenPGP digital signature
Re: segmentation fault with NVIDIA 32bit part
On Tue, Oct 06, 2009 at 08:13:57PM -0700, David Fox wrote: > On Tue, Oct 6, 2009 at 6:59 PM, lee wrote: > > > > And nvidia-kernel-common: > > > > > > "This package contains files shared between NVIDIA module packages." > > Common refers essentially to support files., You should install the > package, but it's not dependent on the driver or the version of the > kernel. Then why doesn't the description say so? > > nvidia-kernel-source: > > > > > > "This package builds the NVIDIA Xorg binary kernel module needed by > > nvidia-glx." > > For whatever kernel you have. It's tied to the specific release of the > driver version, whatever that may be from testing/unstable. Since it > is source, after you do a module-assistant auto-install, it'll compile > that driver for the kernel you have. Since you have a non-standard > kernel, there might be problems, but then again there may not be. Then the description should say so ... > > I don't know about vdpaul --- is that included in the nvidia > > installer? > > vdpau is something that's special to some higher-end nvidia cards. You > may not need that, depending on what card you have. > > The link here [1] itemizes supported cards. Link where? :) I have a 9800GT. > > Why are the package descriptions so poor, and why can't there just be > > one package you install? > > It would be nice, but essentially you need three components, > nvidia-glx, nvidia-common and nvidia-kernel-source. Then there would need to be only two packages: vdpau for those who need it, and the rest (which could suggest vdpau which could tell you which cards can use it). > > 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. > > Using pinning and judicious use of aptitude install -t > unstable when only necessary should make things easier. They _should_: That doesn't mean that they do. Aptitude has a nasty tendency to do things I don't want it to do. Now imagine what would happen if I tried to install the nvidia packages from unstable, given that in testing, they already break another package upon which 95 other packages depend. I might end up having to upgrade to unstable to solve all the dependency problems. Unfortunately, there's no roll-back option in aptitude ... or is there? If there was, there won't be any need to decide between stable, testing, unstable and experimental and you could try whatever combination might work. Just tell aptitude "save this current stage", then try to find something that works, and if it doesn't just tell aptitude "go back to the saved state". Are they at least working on that? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
On Tue, Oct 06, 2009 at 08:00:52PM -0700, David Fox wrote: > On Mon, Oct 5, 2009 at 10:27 AM, lee wrote: > > > cat:/home/lee# /emul/ia32-linux/usr/lib/libGLcore.so.1 > > Segmentation fault > > cat:/home/lee# > > You can't "run" a library directly. Oh. I thought you could --- some time ago, I was reading an article somewhere saying that they made it so that libs can be executed so that the lib would print some version information. But you're right, other libs report segfaults as well when I try. That means that there must be some other problem. Maybe I can figure it out tomorrow. > More to the point, since you have an amd64 system, why bother with > ia32 components? I don't recall any need for ia32 for nvidia. Where do you get a 64bit version of X3? Or X2? Quake? Doom? Tribal Trouble? And so on ... I already told LGP a couple times that they need to make a 64bit version of X3 (even before it came out), but they refused and claim the 32bit version works just fine. But it doesn't work at all, it's running in slow motion and keeps crashing. For anyone who plans on buying that game, just don't. It's a nice game, but before they fixed these problems, it's a waste of money. If they don't fix it soon, they should take it back ... Sure I'd like to turn off 32bit support in the kernel. The nvidia drivers work without, but drivers alone don't get you very far. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
On Tue, Oct 6, 2009 at 6:59 PM, lee wrote: > > And nvidia-kernel-common: > > > "This package contains files shared between NVIDIA module packages." Common refers essentially to support files., You should install the package, but it's not dependent on the driver or the version of the kernel. > nvidia-kernel-source: > > > "This package builds the NVIDIA Xorg binary kernel module needed by > nvidia-glx." For whatever kernel you have. It's tied to the specific release of the driver version, whatever that may be from testing/unstable. Since it is source, after you do a module-assistant auto-install, it'll compile that driver for the kernel you have. Since you have a non-standard kernel, there might be problems, but then again there may not be. > I don't know about vdpaul --- is that included in the nvidia > installer? vdpau is something that's special to some higher-end nvidia cards. You may not need that, depending on what card you have. The link here [1] itemizes supported cards. > Why are the package descriptions so poor, and why can't there just be > one package you install? It would be nice, but essentially you need three components, nvidia-glx, nvidia-common and nvidia-kernel-source. The first and third have to match as far as the driver revision, otherwise you get nasty messages from X. One of these should autoinstall nvidia-common since it may be dependent on the other two. But it's been sometime since I messed with nvidia (now using on board Intel graphics). > 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. Using pinning and judicious use of aptitude install -t unstable when only necessary should make things easier. There have been occasions when I needed the nvidia driver from (then) unstable. This was over a year ago when I was using an nvidia card on an old 32 bit system. Once it worked like a charm, the other time I found that the driver update had (wrongly) decided to include support for instructions that my processor did not support (movaps/movups). Turns out that the driver was compiled this way, and the only recourse to get it to work was to downgrade the package to the prior version. Since I now have an amd64 I can put such frustration behind me, but it's bitten me before several times. (My prior cpu was an Athlon Tbird/1000 which had some support for mmx/3dnow, but assumptions were made occasionally that said basically any modern 386 based system would support these instructions, and support for them only arrived in later versions of the AMD platform.) And it was with some other distributions at well. -- thanks for letting me change the magnetic patterns on your hard disk. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
On Mon, Oct 5, 2009 at 10:27 AM, lee wrote: > cat:/home/lee# /emul/ia32-linux/usr/lib/libGLcore.so.1 > Segmentation fault > cat:/home/lee# You can't "run" a library directly. More to the point, since you have an amd64 system, why bother with ia32 components? I don't recall any need for ia32 for nvidia. Later you make a reference to nvidia-glx, and nvidia-glx-ia32 - they say they have the same functionality, but one is amd64 and the other one is ia32, for mixed 32 & 64 bit compatible systems. It's been a while since I ran debian, but I ran ubuntu 64 bit with their nvidia drivers (coming from Debian) and I don't recall any dependency on 32 bit stuff. There was some, but it was basically for things like googleearth etc. -- thanks for letting me change the magnetic patterns on your hard disk. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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 So I wanted to give this a try, with the packages that are in testing. But nvidia-glx-ia32 conflicts with libc6-ia32, and 95 packages depend on that. Using packages from unstable probably makes it worse. How did you solve that? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
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 co
Re: segmentation fault with NVIDIA 32bit part
lee a wrote : > On Tue, Oct 06, 2009 at 12:17:53AM +0200, thveillon.debian wrote: >> lee a wrote: >>> On Mon, Oct 05, 2009 at 07:41:47PM +0200, thveillon.debian wrote: >>> > cat:/home/lee# /emul/ia32-linux/usr/lib/libGLcore.so.1 > Segmentation fault > cat:/home/lee# the ia32-libs got seriously reworked has I understand, you can use the Sid version of nvidia's packages, and install the "Debian way" using "module-assistant". >>> You mean to install an older Debian package that has the nvidia >>> drivers? I looked for nvidia packages, but there doesn't seem to be >>> one that would compile things for the kernel I'm using. And I don't >>> know what "module-assistant" is. >> No, you said you are using testing (Squeeze), just like I do, so I am >> not advising to install an older package but the current unstable (Sid) >> nvidia packages set that suit your hardware. > > Yeah, sorry, I don't keep track of the release names and get confused > with them. I'm just using testing, it doesn't matter what its current > name is ... > >> The minimum you should have would be nvidia-kernel-common, >> nvidia-kernel-source (to build the kernel module with module-assistant), >> and after the module is built install also nvidia-glx[-ia32]. > > Which version of the driver do these contain? Would this compile the > right things for the kernel I'm using? > 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 Off course if you want the Sid version you need Sid "main" and "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" > 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. > It's working here, I tried the Nvidia (beta) script and it fails even in expert mode where you can choose install paths. >>> Yeah, the nvidia installer seems to work just fine and puts the >>> libraries into the right place. But the libraries are not executable >>> anymore without yielding a segmentation fault. >> How do you test this, so that I can reproduce the tests here ? > > Well, just run the nvidia installer, it will say that some libraries > cannot be found. When you look them up, they are available where they > are supposed to be, but when you execute them, you get segmentation > faults. > > Then run the nvidia installer again, but choose to not install the > 32bit libs this time. That goes through without errors, and the libs > that caused the problem before are gone. 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. >> 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. > >>> The web browsers don't work right anymore either and tend to crash now >>> :( Instead of being improved, they got worse. What happened to the >>> mozilla that included the email client and irc? >>> >> Well, that's another problem, iceweasel works mostly OK here, maybe >> clean up your extensions/plugins ? > > There are way too many to do that --- or is there a list of all the > packages I'd have to remove for that while somehow keeping the things > I might want to keep installed and not have them removed due to > dependencies? I'm not
Re: segmentation fault with NVIDIA 32bit part
On Tue, Oct 06, 2009 at 12:17:53AM +0200, thveillon.debian wrote: > lee a wrote: > > On Mon, Oct 05, 2009 at 07:41:47PM +0200, thveillon.debian wrote: > > > >>> cat:/home/lee# /emul/ia32-linux/usr/lib/libGLcore.so.1 > >>> Segmentation fault > >>> cat:/home/lee# > >> the ia32-libs got seriously reworked has I understand, you can use the > >> Sid version of nvidia's packages, and install the "Debian way" using > >> "module-assistant". > > > > You mean to install an older Debian package that has the nvidia > > drivers? I looked for nvidia packages, but there doesn't seem to be > > one that would compile things for the kernel I'm using. And I don't > > know what "module-assistant" is. > > No, you said you are using testing (Squeeze), just like I do, so I am > not advising to install an older package but the current unstable (Sid) > nvidia packages set that suit your hardware. Yeah, sorry, I don't keep track of the release names and get confused with them. I'm just using testing, it doesn't matter what its current name is ... > The minimum you should have would be nvidia-kernel-common, > nvidia-kernel-source (to build the kernel module with module-assistant), > and after the module is built install also nvidia-glx[-ia32]. Which version of the driver do these contain? Would this compile the right things for the kernel I'm using? 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. > >> It's working here, I tried the Nvidia (beta) script and it fails even in > >> expert mode where you can choose install paths. > > > > Yeah, the nvidia installer seems to work just fine and puts the > > libraries into the right place. But the libraries are not executable > > anymore without yielding a segmentation fault. > > How do you test this, so that I can reproduce the tests here ? Well, just run the nvidia installer, it will say that some libraries cannot be found. When you look them up, they are available where they are supposed to be, but when you execute them, you get segmentation faults. Then run the nvidia installer again, but choose to not install the 32bit libs this time. That goes through without errors, and the libs that caused the problem before are gone. > 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. > > The web browsers don't work right anymore either and tend to crash now > > :( Instead of being improved, they got worse. What happened to the > > mozilla that included the email client and irc? > > > > Well, that's another problem, iceweasel works mostly OK here, maybe > clean up your extensions/plugins ? There are way too many to do that --- or is there a list of all the packages I'd have to remove for that while somehow keeping the things I might want to keep installed and not have them removed due to dependencies? I'm not so sure if this is actually "another problem" rather than another symptom of the quality of Debian going down: First there isn't a web browser that works right anymore (since quite a while), then things that used to work just fine for like a decade (nvidia drivers) suddenly quit working and the web browsers got even worse at the same time. > I think what you are looking for is the "iceape" program in Debian > jargon, not sure about this since I have never used it. There doesn't seem to be an iceape package in testing. Perhaps the developers making mozilla stopped making it, but that leaves Debian without a working web browser. Neither galeon, nor iceweasel or firefox (which seems to be the same), let alone konqeror really work. And when you try to file a bug report, you're told not do it but to go to ridiculous lengths to figure out what's wrong yourself. Things used to just work in Debian, but they do that less and less. That isn't good. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
lee a wrote: > On Mon, Oct 05, 2009 at 07:41:47PM +0200, thveillon.debian wrote: > >>> cat:/home/lee# /emul/ia32-linux/usr/lib/libGLcore.so.1 >>> Segmentation fault >>> cat:/home/lee# >> the ia32-libs got seriously reworked has I understand, you can use the >> Sid version of nvidia's packages, and install the "Debian way" using >> "module-assistant". > > You mean to install an older Debian package that has the nvidia > drivers? I looked for nvidia packages, but there doesn't seem to be > one that would compile things for the kernel I'm using. And I don't > know what "module-assistant" is. No, you said you are using testing (Squeeze), just like I do, so I am not advising to install an older package but the current unstable (Sid) nvidia packages set that suit your hardware. The minimum you should have would be nvidia-kernel-common, nvidia-kernel-source (to build the kernel module with module-assistant), and after the module is built install also nvidia-glx[-ia32]. "module-assistant" (abbreviated m-a) is an helper package that can take care of the module build (and most thinks implied by it). Just use (after installing the package "module-assistant" of course) : m-a a-i nvidia-kernel as root, or just launch the ncurse interface with: m-a Of course "man m-a" is the place to start. 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. >> It's working here, I tried the Nvidia (beta) script and it fails even in >> expert mode where you can choose install paths. > > Yeah, the nvidia installer seems to work just fine and puts the > libraries into the right place. But the libraries are not executable > anymore without yielding a segmentation fault. How do you test this, so that I can reproduce the tests here ? > Since it worked before, there must have been some change made in > Debian packages --- but against which one(s) would I file a bug > report? 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. > > The web browsers don't work right anymore either and tend to crash now > :( Instead of being improved, they got worse. What happened to the > mozilla that included the email client and irc? > Well, that's another problem, iceweasel works mostly OK here, maybe clean up your extensions/plugins ? I think what you are looking for is the "iceape" program in Debian jargon, not sure about this since I have never used it. Tom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
On Mon, Oct 05, 2009 at 07:41:47PM +0200, thveillon.debian wrote: > > cat:/home/lee# /emul/ia32-linux/usr/lib/libGLcore.so.1 > > Segmentation fault > > cat:/home/lee# > > the ia32-libs got seriously reworked has I understand, you can use the > Sid version of nvidia's packages, and install the "Debian way" using > "module-assistant". You mean to install an older Debian package that has the nvidia drivers? I looked for nvidia packages, but there doesn't seem to be one that would compile things for the kernel I'm using. And I don't know what "module-assistant" is. > It's working here, I tried the Nvidia (beta) script and it fails even in > expert mode where you can choose install paths. Yeah, the nvidia installer seems to work just fine and puts the libraries into the right place. But the libraries are not executable anymore without yielding a segmentation fault. Since it worked before, there must have been some change made in Debian packages --- but against which one(s) would I file a bug report? The web browsers don't work right anymore either and tend to crash now :( Instead of being improved, they got worse. What happened to the mozilla that included the email client and irc? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: segmentation fault with NVIDIA 32bit part
lee wrote: > Hi, > > today I updated my testing installation. Now the 32bit part of the > NVIDIA drivers doesn't work anymore: The installer says it cannot find > the libraries that are supposed to be in > /emul/ia32-linux/usr/lib/. However, the libraries are there, but when > I try to run them, I'm getting a segmentation fault: > > > cat:/home/lee# /emul/ia32-linux/usr/lib/libGLcore.so.1 > Segmentation fault > cat:/home/lee# > > > I'm using kernel 2.6.30 and have tried: > > > NVIDIA-Linux-x86_64-185.18.36-pkg2.run > NVIDIA-Linux-x86_64-190.32-pkg2.run > > > The 64bit part seems to work fine, i. e. I can start the X server and > everything is working, except 32bit software that needs the 32bit > stuff. > > What could be causing this problem? It was working just fine before > the update today. > > Hi, the ia32-libs got seriously reworked has I understand, you can use the Sid version of nvidia's packages, and install the "Debian way" using "module-assistant". It's working here, I tried the Nvidia (beta) script and it fails even in expert mode where you can choose install paths. Hope it helps, Tom -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
segmentation fault with NVIDIA 32bit part
Hi, today I updated my testing installation. Now the 32bit part of the NVIDIA drivers doesn't work anymore: The installer says it cannot find the libraries that are supposed to be in /emul/ia32-linux/usr/lib/. However, the libraries are there, but when I try to run them, I'm getting a segmentation fault: cat:/home/lee# /emul/ia32-linux/usr/lib/libGLcore.so.1 Segmentation fault cat:/home/lee# I'm using kernel 2.6.30 and have tried: NVIDIA-Linux-x86_64-185.18.36-pkg2.run NVIDIA-Linux-x86_64-190.32-pkg2.run The 64bit part seems to work fine, i. e. I can start the X server and everything is working, except 32bit software that needs the 32bit stuff. What could be causing this problem? It was working just fine before the update today. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
