On 12/29/2013 03:55 AM, René Kuligowski 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.
No. As I said before, if it turns out to be the wrong package, the bug report gets reassigned. >> 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… ;-) Well, no. You did neither provide any log files nor the output of lspci, dmesg and other commands/log files which will allow us to see what hardware you're using. As I mentioned before, write an installation report and all that is done automatically for your convenience. >> >> 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). Please always try to provide logs right away. Salami slicing isn't really helpful when asking people to help you. >> 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" 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. As for the kernel on Debian Squeeze, I can only guess since you haven't provided detailed logs regarding the kernel panic or oops. It might just be that the kernel in Squeeze didn't support a particular feature of your hardware which isn't really important but might be the culprit when the appropriate kernel module is loaded. > (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. Well, yes, many manufacturers just tweak their drivers to counteract broken ACPI tables. > 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" ;-) Because it's better to have software written to comply to the specifications, not make it run on every buggy hardware on the planet. > 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". Yes, and that's way too unspecific, I'm afraid. Log files and anything similar which documents the actual problem is what's needed. > 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. You did test the capacitors with an ESR meter? Because that's the proper way of testing them. You might also have an unstable power source, i.e. your power supply is failing. And, like I said, when your hardware is aging, you get the weirdest symptoms which originates in the fact that the whole combination of hard- and software in an ACPI system is extremely complex. > 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). 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. > 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. >> No, but you should do a little more research yourself. Firstly, this >> is not the "debian-user" mailing list but "debian-devel", we don't >> provide support here. And, secondly, you can't expect people here >> fixing your computer for free. Nothing indicates so far that your >> problems are related to any bugs, you are just making assumptions. > …based on a)experience, b)a bit of technical IT know-how, c)long-time > use of several OSes, d)being a former IT techie. Not every > "non-debian-developer" is a fool, you know. And yet you fail to provide a proper bug report. If you have a long time experience in the field, you should know that when you ask for help that it's pretty much impossible to debug problems when the person with the issue isn't providing enough information. I just re-read your first mail to the list and I really don't think you provided any valuable information so far that we can use to help you. Again, a proper bug report would include logs or a very clear test case in the form of "When I upgrade package XYZ from version A to version B, my hardware C stops working and crashes with the following error message." A bug report in the form of "When I upgrade my machine from Debian 6 to Debian 7, I am seeing segfaults." is simply not accurate enough, sorry. > And I didn't ask anybody to > "fix my computer", I was noting things and asking about the SIGSEGV > phenomenon I encountered and drew the most appropriate conclusions > (which *might* be conceivable if one reads everthing I wrote). A segmentation fault is a very generic symptom. It simply means that a process made a memory operation which was not allowed. The reason for that can be very broad, ranging from hardware problems through compiler bugs to bugs in the application you are running. That's why I asked for more detailed logs/backtraces. > Other > users are most of the time not likely to be of much help because most of > them are mouse twiddlers that *might* know how to open a shell and sudo > something. debian-devel is not a users list, it's for the discussions related to the discussion around Debian. > You aren't a bit biased and/or pissed in that last paragraph, are you? No, not at all. I am just trying to explain you what you did wrong in your previous bug reporting. I am very much willing to help you, but for that you really need to provide the information I am asking for and stick to the guidelines for reporting bugs. Those guidelines aren't there to annoy you, but they're necessary for people to help you when they're not sitting next to you at the computer which isn't working and for organizing all information related to the bug and documenting the process of fixing it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/52bf8886.5050...@physik.fu-berlin.de
