On 12/29/2013 05:59 AM, René Kuligowski 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.
I'm pretty sure there was once an article on the German magazine c't, which you probably have heard of, which explained that the ACPI tables of most boards being released at that time were corrupt or broken. That's the reason why Linux has support to read patched ACPI tables from disk to override the one from the firmware. > 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. No, you did not. I just re-read your emails and you lack a clear list of test cases which combinations work and which don't. You wrote: > 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. You don't mention which version of the nVidia driver you tested with which version of the kernel and so on. > 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. Again, I don't understand why you are becoming huffy and impolite. I am still trying to help you and you fail to follow my instructions. You are not helping your case at all and you are not showing yourself in a good light. And I don't understand why you accuse me of derogative thinking, I never said anything in that way. You said your machine segfaults, so I assumed you are actually seeing a segfault or something with a backtrace. Don't blame me when you are using the wrong terms. Also, even if your video card crashes, there are still means of obtaining log files or backtraces through SSH or a serial console. You could hook up your machine with a serial console and have the kernel redirect everything to it. If you're lucky, you will get the necessary backtrace through the serial console. If that doesn't work either, create a list of combinations showing what kernel and nVidia version work and which doesn't. You need to make some proper error tracing in order to find the culprit. 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/52bfed41.1050...@physik.fu-berlin.de
