Re: Fwd: Re: several SIGSEGV bugs in debian 7/AMD64
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 - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: