banned from #gentoo since sept 2017Neddyseagoon wrote:The problem with leaving is that you can only do it once and it reduces your influence.
Yup, well it crashes after a few hours (as described by pretty much all users here - mouse moves, no other activities possible, X uses 100% CPU cycles, ssh'ing in and killing X is the solution, blah blah). I just recompiled my kernel without ACPI and enabled APM instead. I'll post back on the status of the system in a bit.jannis wrote:korngerd your system keeps crashing? what about disabling ACPI and enabling APM? (just a try).
Code: Select all
Jan 7 09:51:01 [kernel] NVRM: Xid: 6, PE0000 030c 00b8bbc6 00000000 00b8bbc6 00b8bbc6Code: Select all
--- SIGIO (I/O possible) @ 0 (0) ---
select(13, [12], NULL, NULL, {0, 0}) = 1 (in [12], left {0, 0})
rt_sigprocmask(SIG_BLOCK, [IO], [IO], 8) = 0
read(12, "\30\377\0\0", 64) = 4
gettimeofday({1105109891, 958570}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, [], [IO], 8) = 0
select(1024, [12], NULL, NULL, {0, 0}) = 0 (Timeout)
sigreturn() = ? (mask now [])I edited my kernel config to mimic yours. I haven't checked my xorg config against yours, but just wanted to do it step-by-step. If this works well, it might be something in our kernel configs. If not, I'll check my xorg config against yoursbeugh wrote:Hey guys, is it possible for someone to test this combination (or most of it)?

Ok, cool. What I'm just doing is trying to solve this using a process of elimination. It might be chipset specific for some, but I think that there is an overall issue that needs to be addressed that-at least in my case-is power management related and it appears that ACPI doesn't affect my Dell as much as APM does, and for some this is different.korngerd wrote:I'm on a full ACPI kernel:yaneurabeya wrote:I'm seriously curious what the Nvidia chipset users have for their power settings. Please list them and let's compare this.Code: Select all
CONFIG_PM=y CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION="" CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=yI'm on a udev system running:yaneurabeya wrote: I don't think that anything weird with cold/hotplug was occurring but just as a point of question, how many people are still running devfs, what kernel version, and who's running udev?Code: Select all
$ uname -a Linux nyamochan 2.6.9-gentoo-r13 #3 Wed Dec 29 21:00:04 EST 2004 i686 AMD Athlon(tm) Processor AuthenticAMD GNU/Linux
The kernel config alone didn't fix it. It crashed after about 2 hours again. I'll try to see how different my xorg config is from yours, and try it out with both kernel + xorg config changes.beugh wrote:Hey guys, is it possible for someone to test this combination (or most of it)?
2.6.9-gentoo-r6 config
banned from #gentoo since sept 2017Neddyseagoon wrote:The problem with leaving is that you can only do it once and it reduces your influence.

Will check as soon as I return to my desktop computer (in a few days). I'm quite sure it was one of the infamous NVRM messages.yaneurabeya wrote:Can anyone possibly take a look at their /var/log/messages file prior to the crash? I will be sure to do that as well once I return to school.
I'm testing in another computer with Fedora Core 3 and X.org 6.8.1.yaneurabeya wrote: Has anybody tried with an 6.8.1.x version of X.org?
Running xorg-x11-6.8.0-r3 and nvidia-kernel-1.0.6629-r1 with nvidia-glx-1.0.6629-r1, I get the following RIGHT before it crashes:yaneurabeya wrote:Can anyone possibly take a look at their /var/log/messages file prior to the crash? I will be sure to do that as well once I return to school.
Code: Select all
NVRM: Xid: 13, 0000 02005f00 0000009f 00000300 0010c300 00000002