several SIGSEGV bugs in debian 7/AMD64
concerning: older AMD64 computers + 3.x kernel,
X11 + native NVidia drivers + FVWM or WMII,
and some other SIGSEGV'ing apps
Good morning,
the following case made me put debian 7.3 aside and keep using debian 6.0.7:
I am using an older AMD64 AthlonXP Core 2 3800+, accompanied by 8GB DDR2
RAM, on an Asus M2NPV-VM mainboard, which features a nForce4 430 chipset
with integrated NV6150 GPU, and use an additional PCIe NV9500GS GPU.
The problems are as follows:
–– I have disabled PowerNow in the mainboard's BIOS, and the 3.2 kernel
complains about missing ACPI ("try with newer BIOS"). The kernel
doesn't even recognize the power-off button. In debian 6, ACPI works
absolutely perfectly.
–– In addition, debian 7's 3.2 kernel seems to provoke diverse SIGSEGVs,
like the following:
When I use the Novula kernel module, things are extremely slow,
even in 2D mode; when I use the native NVidia modules (driver packages
304 or 295 which support both GPUS, or the recent 331, which only
supports the 9500), KDM, FVWM, WMII and a good host of other programs
just SIGSEGV or put the CPU in an endless loop and blank the screen by
using illegal video modes.
Note: this does *not* happen in the i386 port of debian 7, which runs
smoothly on my Acer AspireOne netbook with native Intel GPU drivers…
Since there seems to be no 2.6 kernel available anymore, I'll stick
with debian 6.0.7 for now (by the way, the 6.0.7 security update and the
6.0.8 have similar issues…). Please look into this issues and let me
know if you can fix it somehow.
Thanks & regards,
rekuli
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52be806a.9070...@alice-dsl.net
Fwd: Re: several SIGSEGV bugs in debian 7/AMD64
Hi Adrian,
Thanks for your quick answer,… but (sounds like a pouting little boy, I
know):
Sorry, but I cannot file a bug report against, say, nvidia-glx, because
it is most likely not the cause. The problem is far more likely kernel
3.x- and/or gcc-related, and I need somebody who knows more intimate
workings of debian 7 before I can file a bug report to the correct
topic/person:
–– newer BIOS for my machine does not exist. Current/last is from
2009. And, like I wrote, it works perfectly with debian 6 (kernel 2.6)
or winXP/win7. *without* *any* problems. And I don't exactly care if
APM/ACPI standards have changed in the meantime. Debian used to be
backward-compatible to even twenty-years-old hardware and their specs.
–– no capacitor or other hardware related issues. Cannot be, also,
because things would shred under debian 6 and winXP/win7, too, which
they don't. Things are a bit older, but tended well to.
–– with NVidia modules tailor-made and compiled for the running kernel
by the installer, the current X screen (the tty "behind" it) shows
SIGSEGV and dump notes with/from/by several system librares. I'll see
if I can find a way to send you a screendump/log-extract.
–– with kernel *2.6* on debian 6, this does not happen, while I use
exactly the same settings, libraries, modules, and X modules (well, libs
with a smaller sub-version number). With debian 6 using a 3.x kernel,
*the same* happens as I described here for debian 7. Debian 6 and 2.6
kernel run perfectly. Hence, my indirect question if there is an
official 2.6 kernel for debian 7. I don't want to experiment with the
2.6 sources on an "unknown" and differently behaving operating system
myself, and I don't know if it even would run without compiling the
whole 7 distro from scratch again.
Please do not tell me "heck, just buy a more modern gfx card or a whole
new machine, will you", because that wouldn't accomplish anything. I
need the old ones. And debian once was a distribution that ran on
everything from oldest to newest.
Regards,
rekuli
On 28.12.2013 07:56, John Paul Adrian Glaubitz wrote:
Hello Rene!
On 12/28/2013 08:40 AM, René Kuligowski wrote:
concerning: older AMD64 computers + 3.x kernel,
X11 + native NVidia drivers + FVWM or WMII,
and some other SIGSEGV'ing apps
This is too unspecific, unfortunately. You should file a bug report for
each machine and each problem you encounter.
For example, when you see crashes of the nVidia driver with one of your
machine, file a bug against the "nvidia-glx" package providing the exact
hardware configuration you have. The tool "reportbug" will allow you to
create a template to write a bug report and you can find more
information here [1].
I am using an older AMD64 AthlonXP Core 2 3800+, accompanied by 8GB DDR2
RAM, on an Asus M2NPV-VM mainboard, which features a nForce4 430 chipset
with integrated NV6150 GPU, and use an additional PCIe NV9500GS GPU.
Before looking closer at the software, have you checked the hardware
itself? The capacitors on hardware of that age are very prone to
failure, see [2].
–– I have disabled PowerNow in the mainboard's BIOS, and the 3.2 kernel
complains about missing ACPI ("try with newer BIOS"). The kernel
doesn't even recognize the power-off button. In debian 6, ACPI works
absolutely perfectly.
Well, did you actually try a newer BIOS? ACPI tables which are part of
the mainboard BIOS are very often broken or incorrect. There are tools
which are table to verify the ACPI implementation of your BIOS [3].
Newer BIOS version often fix or at least improve the ACPI tables.
When I use the Novula kernel module, things are extremely slow, even
in 2D mode;
Speed is very subjective in this regard, but nouveau is certainly slower
than the binary driver by nVidia. This is known and lies in the nature
of the way this driver has been developed.
when I use the native NVidia modules (driver packages 304 or
295 which support both GPUS, or the recent 331, which only supports the
9500), KDM, FVWM, WMII and a good host of other programs just SIGSEGV or
put the CPU in an endless loop and blank the screen by using illegal
video modes.
Then you should actually file bug reports against "nvidia-glx" providing
all necessary information like the output of "lspci", "dmesg" and so
on. You can, for example, write an installation report [4] which
will do most of that work for you. You just need to fill in the
missing information about the hardware and what worked and what not.
Note: this does *not* happen in the i386 port of debian 7, which runs
smoothly on my Acer AspireOne netbook with native Intel GPU drivers…
How is this related to any of the problems above? This is a completely
different hardware. Please file separate bug reports for e
Re: Fwd: Re: several SIGSEGV bugs in debian 7/AMD64
On 28.12.2013 19:27, John Paul Adrian Glaubitz wrote: You can still file the bug report against a particular package. If it turns out to be assigned to the wrong package, we can still change that afterwards at any time. Right, I just wanted to spare us from the trouble by getting one or the other response as to what might be the right thing. Also, you still need to be more specific. A bug report in the sense of "Debian 7 crashes on my old computer, Debian 6 didn't", isn't helpful at all. Debian comes with over 15.000 source packages and there are billions of hardware combinations out there. …I believe I *had* outlined it a slight bit more specific… ;-) Unless someone at Debian can get hold of a crystal ball, it's simply impossible to debug your problem with the information that you provided. …will provide logs etc. and file a report against, well, let's start with the kernel, since the Segsegv/dump messages are not gone with nouveau, just a reduced to a handful instead of about fifty (I just tested that). –– newer BIOS for my machine does not exist. Current/last is from 2009. And, like I wrote, it works perfectly with debian 6 (kernel 2.6) or winXP/win7. *without* *any* problems. And I don't exactly care if APM/ACPI standards have changed in the meantime. Debian used to be backward-compatible to even twenty-years-old hardware and their specs. You got me wrong. ACPI standards didn't change, I never said that. What I said is that lots of BIOS firmware has incorrect implementations of the ACPI specification and you probably need to patch your ACPI tables (there are tools for that out there). Yes, I understood that; what I tried to say was "my ACPI seems to conform to standards since no problems arise when I use debian 6, WindowsXP or Windows7" (Ok, maybe I should have written that sentence earlier). Unless, of course, those *assume* every computer has wrong ACPI and hotfix them in run-time. I still might do a check (will check them against the standard, at least). Still, why patch tables which work correctly except with deb7? just to see what happens? I remember the good old saying "never touch a running system" ;-) In any case, it's still your job to write a detailed bug report and trying to pin point your problem to a certain package, e.g. "Updating nvidia-glx from version 123.45 to 155.99 brought my graphics with my nVidia GeForce 123 graphics adapter". Again, without this information, any attempt to help you will be futile. I wrote something about that, in the line of "nouveau is too slow and doesn't offer 3D acceleration, with downloaded NVidias driver releases 295, 304, or 331 the system becomes unpredictable and KDM, FVWM, WMII and others just SIGSEGV". –– no capacitor or other hardware related issues. Cannot be, also, because things would shred under debian 6 and winXP/win7, too, which they don't. Things are a bit older, but tended well to. Bad capacitors tend to cause all kinds of problems, including those that don't make any sense at first sight. I have often seen people overlooking bad capacitors, especially since not all bad capacitors tend to bulge. Right. But still similar or the same consequences would show in the other OSes which run on the same machine if capacitors or diodes were the reason. As far as my potentiometers and tools state, everything is in order. –– with NVidia modules tailor-made and compiled for the running kernel by the installer, the current X screen (the tty "behind" it) shows SIGSEGV and dump notes with/from/by several system librares. I'll see if I can find a way to send you a screendump/log-extract. Well, if it turns out to be a bug in the proprietary nVidia driver, there is nothing Debian can actually do to fix this. This driver is closed-source, thus only nVidia can make changes to it to fix bugs. Let's assume it is an NVidia bug. Shouldn't it show in older kernels, too, like, in 2.6? The 290 and 295 releases do exactly what they ought to do on debian 6 and its predecessor, debian 5, and if I install from the very same files in debian 7 –– poof (so to say). Debian can fix bugs in the nouveau driver only which is recommended for older nVidia cards anyway unless you want to do some serious gaming. My Debian workstation sports a GeForce 210 which isn't that old but also not a gaming board and I have been using nouveau ever since without any problems. It's surely not fast enough for 3D gaming, but 2D stuff is fine. That's why I need 3D acceleration: gaming, and 3D modeling/rendering. Hence, my indirect question if there is an official 2.6 kernel for debian 7. No, there isn't and it's certainly not sensible to use older kernels. There might be important daemons like udevd which might need a more recent kernel. I don't want to experiment with the 2.6 sources on an "unknown" and differently behaving operating system myself, and I don't know if it even would run without compiling the whole 7 distro from scrat
Fwd: Re: Fwd: Re: several SIGSEGV bugs in debian 7/AMD64
Original Message Subject:Re: Fwd: Re: several SIGSEGV bugs in debian 7/AMD64 Date: Sun, 29 Dec 2013 01:57:50 -0100 From: René Kuligowski To: Ben Hutchings On 28.12.2013 23:46, Ben Hutchings wrote: On Sat, 2013-12-28 at 19:52 -0100, René Kuligowski wrote: Hi Adrian, Thanks for your quick answer,… but (sounds like a pouting little boy, I know): Sorry, but I cannot file a bug report against, say, nvidia-glx, because it is most likely not the cause. Sure it is. when I use the exactly same driver from te NVidia site as in debian 6? Unlikely. The problem is far more likely kernel 3.x- and/or gcc-related, and I need somebody who knows more intimate workings of debian 7 before I can file a bug report to the correct topic/person: But you just rejected the advice of one such person. Do you want advice or not? Sure. But advice that makes sense and doesn't assume I don't now at all what I am talking about. –– newer BIOS for my machine does not exist. Current/last is from 2009. And, like I wrote, it works perfectly with debian 6 (kernel 2.6) or winXP/win7. *without* *any* problems. And I don't exactly care if APM/ACPI standards have changed in the meantime. Debian used to be backward-compatible to even twenty-years-old hardware and their specs. I don't believe this was ever true, and it should not be a high priority for us. [...] –– with kernel *2.6* on debian 6, this does not happen, while I use exactly the same settings, libraries, modules, and X modules (well, libs with a smaller sub-version number). With debian 6 using a 3.x kernel, *the same* happens as I described here for debian 7. [...] You are also using a new version of the nvidia driver with this kernel... wrong. I use the 290, same version I use in debian 6. Ben. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52bf907a.2000...@alice-dsl.net
Re: several SIGSEGV bugs in debian 7/AMD64
OK, this is not fun when people just get pissed because they don't read –– or don't want to read –– what a person writes, and answer with thoughtless or arrogant statements. I didn't post this in debian-devel out of boredom; I wrote to you because it didn't seem to fit anywhere else. I thank you for your "help", so far. Thank you, good night. rekuli -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52bf91ae.2070...@alice-dsl.net
Re: Fwd: Re: several SIGSEGV bugs in debian 7/AMD64
On 29.12.2013 01:27, John Paul Adrian Glaubitz wrote: This is a common fallacy: Just because a piece of hardware is working properly on Windows doesn't mean anything is adherent to the specifications. The reason why your hardware is running on Windows without any problems is that the manufacturer of your hardware actually tested the combination of drivers, hardware and operating system and tweaked it long enough to get the combination running stable. Possible errors in the ACPI implementation can be fixed by additional hacks in the driver or Windows. …and since debian 6's kernel etc.pp. also were able to hotfix or whatever, so that my system runs without any issues… but this gets pointless, because I keep saying A² and you keep understanding B/µ. Let's just assume my ACPI tables are completely according to standard, because they are. (…) Not necessarily. The internal interfaces of the kernel change very often and compiling the nVidia module glue code on a 2.6 kernel is certainly quite different to compiling it on a 3.x kernel. You probably have noticed that very often you need to update the nVidia drivers to be able to use them with newer kernels. The driver might use features present in the 3.x kernels only which trigger the problems you are seeing. Did you already try the most recent version of the nVidia driver? You may also try the version from experimental or directly downloaded from nVidia if you know how to install it. I tried debian's nvidia-glx package, which didn't work. From Nvidia's site: The most recent driver which supports both of my GPUs, the 304 release, as well as the most recent one which supports the GF9, the 331 release. And the 290 release, which runs smoothly in the debian 6 installation. I already wrote that a few mails back. As you say yourself above, some things like "udev" etc. pp. would certainly have to be rebuilt to use the 2.6 features and not to try to use 3.x ones. Again we rotate to "building the distro from scratch on a 2.6 kernel". No, they don't. You don't need to rebuilt the whole distribution to use an older kernel. Linux hasn't changed it's userland ABI for over 20 years AFAIK. However, some tools which are part of the kernel's plumberland on Wheezy might complain if you're booting the system with a kernel significantly older than the one in Wheezy. Then it's worth a try to use the 2.6 sources from Squeeze and compile a kernel in Wheezy. (…) Sorry, but the rest of your reply amounts to the mail I sent to debian-devel only –– pointless bla-bla that shows a) you didn't really read my mails, b) think I am a complete idiot and c) don't even try to understand the problematic while I am gathering those logs etc you are so fanatic about, instead hiding yourself beneath a "another wannabe-idiot wants to try linux and screwed" attitude. Thanks, nonetheless, for the help. I consider this whole case closed. Regards, René -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52bfac37.8070...@alice-dsl.net
