Debian Bug report logs - #583312
KDM timeout is not sufficient for parallel boot

version graph

Package: kdm; Maintainer for kdm is Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>; Source for kdm is src:kde-workspace.

Reported by: Romane <romane@miscellanie.com>

Date: Wed, 26 May 2010 23:09:02 UTC

Severity: important

Tags: sid, squeeze

Merged with 524751, 583336, 583613, 590626, 597699

Found in versions kdebase-workspace/4:4.4.3-1, kdebase-workspace/4:4.4.4-1

Fixed in version kdebase-workspace/4:4.4.5-4

Done: Modestas Vainius <modax@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#583312; Package initscripts. (Wed, 26 May 2010 23:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Romane <romane@miscellanie.com>:
New Bug report received and forwarded. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Wed, 26 May 2010 23:09:05 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Romane <romane@miscellanie.com>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: since update to initscripts, sysv... to version 2.88.dfs-5 -- kdm "fails" to load
Date: Thu, 27 May 2010 07:52:29 +1000
Package: initscripts
Version: 2.88dsf-5
Severity: important


Immediately subsequent to update yesterday with version 2.88dsf-5 of initscripts, sysv-rc, sysvinit
and sysvinit-utils, kdm "fails" to load at boot time. System is Squeeze, complete wipe and totally
fresh install only two days ago. Prior to wipe was also running Squeeze. Using nVidia GeForce 9600 GT.
For more than a year, has run perfectly, pre and post fresh install.

Since update, new message at boot saying running boot in concurrency.

At boot now, at point when screen would normally go black, then give whirling cursor indication,
then logon screen, now goes black, then gives nVidia green logo for approx 7 to 8 seconds, then
drops to console.

Logging in as root, an attempt to manually start kdm will fail, with message that kdm is running.
Issuing restart command works like a charm, and one is brought to the logon screen. Usable workaround,
but highly inconvenient.

In the system log, we find that the nVidia kernel is being loaded, as follows:

2010-05-26 21:25:55   debian-main-pc   kernel   [    5.509244] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  256.25  Tue May 18 20:37:09 PDT 2010

Later in the boot sequence, these entries appear :

2010-05-26 21:26:12   debian-main-pc   kdm[1466]   X server startup timeout, terminating
2010-05-26 21:26:12   debian-main-pc   kdm[1466]   X server for display :0 cannot be started,
                session disabled

This occurs regardless the driver downloaded from nVidia, or the driver installed via the repositories
both version 195.36.24. Also occurs with latest beta from nVidia.

kdm will start normally if nVidia xorg.conf file is deleted. However, as issue only began with the
upgrade to these four files, it would appear that the issues lies not with kdm or the nVidia driver,
but a change made in these files.

Romane


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages initscripts depends on:
ii  coreutils                     8.5-1      GNU core utilities
ii  debianutils                   3.2.3      Miscellaneous utilities specific t
ii  libc6                         2.10.2-9   Embedded GNU C Library: Shared lib
ii  lsb-base                      3.2-23.1   Linux Standard Base 3.2 init scrip
ii  mount                         2.16.2-0   Tools for mounting and manipulatin
ii  sysv-rc                       2.88dsf-5  System-V-like runlevel change mech
ii  sysvinit-utils                2.88dsf-5  System-V-like utilities

Versions of packages initscripts recommends:
ii  e2fsprogs                     1.41.11-1  ext2/ext3/ext4 file system utiliti
ii  psmisc                        22.11-1    utilities that use the proc file s

initscripts suggests no packages.

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#583312; Package initscripts. (Thu, 27 May 2010 05:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Thu, 27 May 2010 05:48:03 GMT) Full text and rfc822 format available.

Message #10 received at 583312@bugs.debian.org (full text, mbox):

From: Petter Reinholdtsen <pere@hungry.com>
To: Romane <romane@miscellanie.com>, 583312@bugs.debian.org
Subject: Re: Bug#583312: since update to initscripts, sysv... to version 2.88.dfs-5 -- kdm "fails" to load
Date: Thu, 27 May 2010 07:45:33 +0200
[Romane]
> kdm will start normally if nVidia xorg.conf file is
> deleted. However, as issue only began with the upgrade to these four
> files, it would appear that the issues lies not with kdm or the
> nVidia driver, but a change made in these files.

With the introduction of parallel booting, stricter constraints on the
correctness of the dependency informatoin in init.d scripts is
introduced.  If all init.d scripts have correct and complete
dependency information, the boot will work as it should, and without
complete and corect dependency information, it might fail.  This is
not a bug with sysv-rc, but with the package providing the init.d
script with the incomplete or incorrect dependency information.

I do not know the packages installed on your machine, so it is hard to
guess which package is buggy.  Could it be that the nvidia script fail
to specify that it need to run before kdm starts?  Which packages are
involved?

Please provide the output from /usr/share/insserv/make-testsuite, to
make it possible to reproduce your boot sequence.  If you have an idea
what script is buggy, try using

  /usr/share/insserv/check-initd-order -g > bootgraph.dot
  dotty bootgraph.dot

to review the dependencies.

Happy hacking,
-- 
Petter Reinholdtsen




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#583312; Package initscripts. (Thu, 27 May 2010 06:42:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Romane <romane@miscellanie.com>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Thu, 27 May 2010 06:42:06 GMT) Full text and rfc822 format available.

Message #15 received at 583312@bugs.debian.org (full text, mbox):

From: Romane <romane@miscellanie.com>
To: 583312@bugs.debian.org
Cc: Petter Reinholdtsen <pere@hungry.com>
Subject: Re: Bug#583312: since update to initscripts, sysv... to version 2.88.dfs-5 -- kdm "fails" to load
Date: Thu, 27 May 2010 16:39:49 +1000
[Message part 1 (text/plain, inline)]
Good morning Peter

With what you have said, my first suspicion now would be the script for 
nvidia-glx. If the positioning of the script is determined by the script 
creator, and the nVidia scripts will have been created by nVidia (that 
is an assumption - please correct me if I am wrong), then they need make 
their adjustments to place it earlier in the sequence (as per my last 
email). nvidia is run before kdm, but it appears not early enough. Which 
would suggest the problem is not the initscript teams. Will follow up 
more on that after a much-needed snooze, but being new to this aspect of 
Linux, if am advised differently, will follow said advice.

Couple of utilities in your emaiI knew nothing of. Just for now, have 
attached the output from /usr/share/insserv/make-testsuite, as 
requested. Two of, actually. One with nvidia-glx sitting in S17, where 
was having the problem, and one where I changed the S17 to S7, and the 
system boots OK (for now, at least).

Will explore more with /usr/share/insserv/check-init-order later today 
after snooze, compare the output with nvidia-glx at both S17 and S7 
positions. If copies are of any use to you, let me know, will send.

With greetings

Romane



On 27/05/10 15:45, Petter Reinholdtsen wrote:
> [Romane]
>    
>> kdm will start normally if nVidia xorg.conf file is
>> deleted. However, as issue only began with the upgrade to these four
>> files, it would appear that the issues lies not with kdm or the
>> nVidia driver, but a change made in these files.
>>      
> With the introduction of parallel booting, stricter constraints on the
> correctness of the dependency informatoin in init.d scripts is
> introduced.  If all init.d scripts have correct and complete
> dependency information, the boot will work as it should, and without
> complete and corect dependency information, it might fail.  This is
> not a bug with sysv-rc, but with the package providing the init.d
> script with the incomplete or incorrect dependency information.
>
> I do not know the packages installed on your machine, so it is hard to
> guess which package is buggy.  Could it be that the nvidia script fail
> to specify that it need to run before kdm starts?  Which packages are
> involved?
>
> Please provide the output from /usr/share/insserv/make-testsuite, to
> make it possible to reproduce your boot sequence.  If you have an idea
> what script is buggy, try using
>
>    /usr/share/insserv/check-initd-order -g>  bootgraph.dot
>    dotty bootgraph.dot
>
> to review the dependencies.
>
> Happy hacking,
>    
[atS17nvidia-glx (text/plain, attachment)]
[atS7nvidia-glx (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#583312; Package initscripts. (Thu, 27 May 2010 07:06:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Thu, 27 May 2010 07:06:09 GMT) Full text and rfc822 format available.

Message #20 received at 583312@bugs.debian.org (full text, mbox):

From: Petter Reinholdtsen <pere@hungry.com>
To: Romane <romane@miscellanie.com>, 583312@bugs.debian.org
Subject: Re: Bug#583312: since update to initscripts, sysv... to version 2.88.dfs-5 -- kdm "fails" to load
Date: Thu, 27 May 2010 09:03:45 +0200
[Romane]
> Just for now, have attached the output from
> /usr/share/insserv/make-testsuite, as requested. Two of,
> actually. One with nvidia-glx sitting in S17, where was having the
> problem, and one where I changed the S17 to S7, and the system boots
> OK (for now, at least).

Try changing the nvidia-glx script header to look like this, and run
'update-rc.d /etc/init.d/nvidia-glx defaults' (ignore the warning) to
reorder the boot:

### BEGIN INIT INFO
# Provides:          nvidia-glx
# Required-Start:    $remote_fs
# Required-Stop:     $remote_fs
# Should-Start:      nvidia-kernel
# X-Start-Before:    kdm
# Default-Start:     2 3 4 5
# Default-Stop:      
# Short-Description: messing around with the libGL.so symlink
# Description:       messing around with the libGL.so symlink
### END INIT INFO

This change will make sure the nvidia-glx script run after the
nvidia-kernel script and before kdm also with parallel boot.

Happy hacking,
-- 
Petter Reinholdtsen




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#583312; Package initscripts. (Thu, 27 May 2010 08:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Romane <romane@miscellanie.com>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Thu, 27 May 2010 08:09:03 GMT) Full text and rfc822 format available.

Message #25 received at 583312@bugs.debian.org (full text, mbox):

From: Romane <romane@miscellanie.com>
To: 583312@bugs.debian.org
Subject: possible fix
Date: Thu, 27 May 2010 15:35:38 +1000
Good morning

Further hunting around, and may have found a solution. A little background :

Adding the line "ServerTimeout=120" to the [X-*-Core] section of 
/etc/kde4/kdm/kdmrc enabled the system to boot to a normal login screen. 
In comparison to while having the problem, where was counting 7 to 8 
seconds, give or take, and then being dropped from the green nVidia logo 
back to the console, adding that line I was counting 12 to 15 seconds, 
and then being presented with the logon screen.

 Wanting to test boot order, I deleted the line from kdmrc, and went to 
/etc/rc2.d. The order of the scripts was :

S01nvidia-kernel
S01quemu-kvm
S01speech-despatcher
S14portmap
S15nfs-common
S17nvidia-glx

Changed the S17nvidia-glx to S7nvidia-glx, and the beastie booted up to 
a login screen no problems, and at about the same speed (give or take) 
as before the installation of the initscripts and sysv... stuff yesterday.

Now, this is not optimal - some update at some time in the future will 
again reorder the scripts, and the problem is very likely to repeat itself.

If I could suggest a change to the way that the scripts that do the 
ordering of scripts in rc2.d to be altered so as to action nvidia-glx 
earlier in the boot sequence. Though the problem may not affect 
everyone, doing so may reduce or even eliminate the incidences of this 
issue in the future.

With greetings

Romane




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#583312; Package initscripts. (Thu, 27 May 2010 08:27:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Thu, 27 May 2010 08:27:12 GMT) Full text and rfc822 format available.

Message #30 received at 583312@bugs.debian.org (full text, mbox):

From: Petter Reinholdtsen <pere@hungry.com>
To: Romane <romane@miscellanie.com>, 583312@bugs.debian.org
Subject: Re: [Pkg-sysvinit-devel] Bug#583312: possible fix
Date: Thu, 27 May 2010 10:23:59 +0200
[Romane]
> Changed the S17nvidia-glx to S7nvidia-glx, and the beastie booted up to 
> a login screen no problems, and at about the same speed (give or take) 
> as before the installation of the initscripts and sysv... stuff yesterday.

As far as I know, changing the sequence number of a script will not
affect parallel booting.  Did you use S7nvidia-glx or S07nvidia-glx?
If the former, I suspect this caused the script to not run at all
during boot.  I suspect there is some race issue causing some but not
all boots to fail.

Btw, what is the name of the package providing /etc/init.d/nvidia-glx
on your machine (dpkg -S /etc/init.d/nvidia-glx).

> Now, this is not optimal - some update at some time in the future
> will again reorder the scripts, and the problem is very likely to
> repeat itself.

Please try the adjusted header for nvidia-glx I posted earlier, and
let me know if it helps.

Happy hacking,
-- 
Petter Reinholdtsen




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#583312; Package initscripts. (Thu, 27 May 2010 11:09:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Romane <romane@miscellanie.com>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Thu, 27 May 2010 11:09:12 GMT) Full text and rfc822 format available.

Message #35 received at 583312@bugs.debian.org (full text, mbox):

From: Romane <romane@miscellanie.com>
To: 583312@bugs.debian.org
Cc: Petter Reinholdtsen <pere@hungry.com>
Subject: Re: [Pkg-sysvinit-devel] Bug#583312: possible fix
Date: Thu, 27 May 2010 21:07:11 +1000
Good morning Petter

I must thank you for your patience.
> As far as I know, changing the sequence number of a script will not
> affect parallel booting.  Did you use S7nvidia-glx or S07nvidia-glx?
> If the former, I suspect this caused the script to not run at all
> during boot.  I suspect there is some race issue causing some but not
> all boots to fail.
>    
Time has proven you correct, and my approach a failure anyways (hangs 
head). I had used S7, but even changing it to S07 made no difference. 
Back now to what it started at - S17nvidia-glx. Basically, whatever went 
right earlier on is now not going right; back to being dropped to the 
console.
> Btw, what is the name of the package providing /etc/init.d/nvidia-glx
> on your machine (dpkg -S /etc/init.d/nvidia-glx).
$ dpkg -S /etc/init.d/nvidia-glx
nvidia-glx: /etc/init.d/nvidia-glx

Installed from the repositories, but drivers downloaded from nVidia are 
affected also.
> Please try the adjusted header for nvidia-glx I posted earlier, and
> let me know if it helps.
Made that change, and no change to the boot issue. Rebooted a number of 
times, to make sure not a one-off.

So far, only thing that seems to get me through is to make that change 
mentioned in my earlier email to /etc/kde4/kdm/kdmrc with a timeout 
value of 120. After my earlier overconfident assurance that had possibly 
found a solution, won't say that have it fixed, but over the test boots 
just now done, each boot was successful at getting to the login screen. 
The time from when the screen goes blank to when am presented with the 
logon screen varies from 15 to 18 seconds (give or take). Before, it was 
tossing me to the console after about 12 to 15 seconds (give or take). 
On those grounds, at least things seem to be working, even if not as 
they should :) I have read in my searches that making this change is not 
the preferred method, but ... - I can also make a coffee while I wait 
(laughing).

Have another machine which have been holding off making this update to. 
Took the plunge a little earlier, and it came up on the first boot. Also 
an nVidia card. My 3 machines are always set up identically - can hop 
from one to the other without having to remember which machine am 
sitting at - different hardware, but same system otherwise. So, not a 
consistent issue, as you suggested in your reply to me. The third 
machine is not affected - ATI, not using proprietary drivers.

I have reached the end of my own options and limited knowledge (getting 
old and forgetful :)), but am most happy to use this machine to debug 
the issue with you if that will help improve further an already supurb 
distribution. Crashing it is not an issue - worst comes to worst, can 
reformat, reinstall (grinning).

Have babbled sufficient for now

> Happy hacking,
>    
With greetings

Romane




Information forwarded to debian-bugs-dist@lists.debian.org, Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>:
Bug#583312; Package initscripts. (Thu, 27 May 2010 12:21:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian sysvinit maintainers <pkg-sysvinit-devel@lists.alioth.debian.org>. (Thu, 27 May 2010 12:21:03 GMT) Full text and rfc822 format available.

Message #40 received at 583312@bugs.debian.org (full text, mbox):

From: Petter Reinholdtsen <pere@hungry.com>
To: Romane <romane@miscellanie.com>, 583312@bugs.debian.org
Subject: Re: [Pkg-sysvinit-devel] Bug#583312: possible fix
Date: Thu, 27 May 2010 14:17:56 +0200
reassign 583312 nvidia-glx
severity 583312 serious
thanks

[Romane]
> I have reached the end of my own options and limited knowledge
> (getting old and forgetful :)), but am most happy to use this
> machine to debug the issue with you if that will help improve
> further an already supurb distribution. Crashing it is not an issue
> - worst comes to worst, can reformat, reinstall (grinning).

I had a look at the open bugs against nvidia-glx, and came across
#521699 which seem similar to your problem.  Reassigning to the
nvidia-glx package to get input from the maintainers of that package,
and because I believe the problem is in that package.  Setting
serverity to serious, based on the assumtion that this problem will
affect all users with parallel booting now enabled by default.

Does it work to add for example 'sleep 5' at the end of the start
section in /etc/init.d/nvidia-glx?  Perhaps something need more time
before X is started?

Happy hacking,
-- 
Petter Reinholdtsen




Bug reassigned from package 'initscripts' to 'nvidia-glx'. Request was from Petter Reinholdtsen <pere@hungry.com> to control@bugs.debian.org. (Thu, 27 May 2010 12:21:06 GMT) Full text and rfc822 format available.

Bug No longer marked as found in versions sysvinit/2.88dsf-5. Request was from Petter Reinholdtsen <pere@hungry.com> to control@bugs.debian.org. (Thu, 27 May 2010 12:21:07 GMT) Full text and rfc822 format available.

Severity set to 'serious' from 'important' Request was from Petter Reinholdtsen <pere@hungry.com> to control@bugs.debian.org. (Thu, 27 May 2010 12:21:08 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Thu, 27 May 2010 13:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Romane <romane@miscellanie.com>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Thu, 27 May 2010 13:12:03 GMT) Full text and rfc822 format available.

Message #51 received at 583312@bugs.debian.org (full text, mbox):

From: Romane <romane@miscellanie.com>
To: Petter Reinholdtsen <pere@hungry.com>, 583312@bugs.debian.org
Subject: Re: [Pkg-sysvinit-devel] Bug#583312: possible fix
Date: Thu, 27 May 2010 23:09:31 +1000
[Message part 1 (text/plain, inline)]
Good morning Petter
> reassign 583312 nvidia-glx
> severity 583312 serious
> thanks
Thanks for passing it on. Even if not all users, a sufficient portion 
probably. Have replied all in this email.
> I had a look at the open bugs against nvidia-glx, and came across
> #521699 which seem similar to your problem.  Reassigning to the
> nvidia-glx package to get input from the maintainers of that package,
> and because I believe the problem is in that package.  Setting
> serverity to serious, based on the assumtion that this problem will
> affect all users with parallel booting now enabled by default.
>
> Does it work to add for example 'sleep 5' at the end of the start
> section in /etc/init.d/nvidia-glx?  Perhaps something need more time
> before X is started?
>    
You seem to have hit the nail on the head. Added that line to the script 
nvidia-glx, commented out the delay I had added in /etc/kde4/kdm/kdmrc, 
rebooted, and it came up to a normal logon screen without even 
displaying the green nVidia logo. I then went in and made sure 
everything was set back to what it was when this issue started for me - 
took out those two lines from the nvidia-glx script that were tried 
earlier, ensured that numbering was still S17nvidia-glx in rc2.d. 
Rebooted. 6 times. Each time without any errors, without seeing the 
nVidia logo, and boot was acceptably and perceptibly quicker than what 
was before even the update of the initscripts yesterday. Only things 
couldn't change was whatever changes running update-rc.d made earlier in 
the day (see history of problem).

Checked the various logs, and was unable to see anything that may help.

Anything that I can do that can help to isolate this further?

Ran /usr/share/insserv/make-testsuite again, and have attached the 
output in case of any use.

After the to and fro'ing during the course of the day, am inclined to 
accept your view now that the problem is in the nvidia package.
> Happy hacking,
>    
With greetings

Romane
[S17nvidia-glx (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Thu, 27 May 2010 14:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Thu, 27 May 2010 14:12:04 GMT) Full text and rfc822 format available.

Message #56 received at 583312@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Romane <romane@miscellanie.com>
Cc: 583312@bugs.debian.org, Petter Reinholdtsen <pere@hungry.com>
Subject: Re: Bug#583312: possible fix
Date: Thu, 27 May 2010 07:09:43 -0700
Romane <romane@miscellanie.com> writes:

>> I had a look at the open bugs against nvidia-glx, and came across
>> #521699 which seem similar to your problem.  Reassigning to the
>> nvidia-glx package to get input from the maintainers of that package,
>> and because I believe the problem is in that package.  Setting
>> serverity to serious, based on the assumtion that this problem will
>> affect all users with parallel booting now enabled by default.

I think parallel booting is a red herring.  The init script for nvidia-glx
has nothing to do with the operation of the X server (take a look at what
it does).

> You seem to have hit the nail on the head. Added that line to the script
> nvidia-glx, commented out the delay I had added in /etc/kde4/kdm/kdmrc,
> rebooted, and it came up to a normal logon screen without even
> displaying the green nVidia logo. I then went in and made sure
> everything was set back to what it was when this issue started for me -
> took out those two lines from the nvidia-glx script that were tried
> earlier, ensured that numbering was still S17nvidia-glx in
> rc2.d. Rebooted. 6 times. Each time without any errors, without seeing
> the nVidia logo, and boot was acceptably and perceptibly quicker than
> what was before even the update of the initscripts yesterday. Only
> things couldn't change was whatever changes running update-rc.d made
> earlier in the day (see history of problem).

If you're experiencing a variant of #521699, then the problem is that the
timeout in KDM is too fast.  You need to tell KDM to wait longer; it takes
the NVIDIA driver longer to initialize the card than it's willing to wait
for.  I suspect that the only thing that parallel booting is doing is
starting kdm sooner and hence giving the NVIDIA module even less time to
initialize the hardware.

See #568969 for the timeout fix that worked for GDM.  It appears to no
longer be a problem with GDM 3 (or at least it's not reproducible for us).

However, it's possible that my understanding here is not complete.

I don't see any obvious way that we can fix this on the NVIDIA side if I'm
understanding the problem correctly.  It takes as long as it takes to
initialize the video card, and the nvidia-glx init script is superfluous
and is going away, so adding delays to it won't work (and I'm skeptical
that's a reliable solution anyway).

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Thu, 27 May 2010 14:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Thu, 27 May 2010 14:33:05 GMT) Full text and rfc822 format available.

Message #61 received at 583312@bugs.debian.org (full text, mbox):

From: Petter Reinholdtsen <pere@hungry.com>
To: 583312@bugs.debian.org
Cc: Romane <romane@miscellanie.com>
Subject: Re: Bug#583312: possible fix
Date: Thu, 27 May 2010 16:31:50 +0200
[Russ Allbery]
> If you're experiencing a variant of #521699, then the problem is
> that the timeout in KDM is too fast.  You need to tell KDM to wait
> longer; it takes the NVIDIA driver longer to initialize the card
> than it's willing to wait for.  I suspect that the only thing that
> parallel booting is doing is starting kdm sooner and hence giving
> the NVIDIA module even less time to initialize the hardware.

What is loading the nvidia driver?  When is it done?  If it is done by
some init.d script, the init.d script should not exit until the
initialization is done to make sure those scripts depending on it will
work.

Happy hacking,
-- 
Petter Reinholdtsen




Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Thu, 27 May 2010 15:06:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Thu, 27 May 2010 15:06:05 GMT) Full text and rfc822 format available.

Message #66 received at 583312@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Petter Reinholdtsen <pere@hungry.com>
Cc: 583312@bugs.debian.org, Romane <romane@miscellanie.com>
Subject: Re: [pkg-nvidia-devel] Bug#583312: possible fix
Date: Thu, 27 May 2010 08:03:24 -0700
Petter Reinholdtsen <pere@hungry.com> writes:
> [Russ Allbery]

>> If you're experiencing a variant of #521699, then the problem is
>> that the timeout in KDM is too fast.  You need to tell KDM to wait
>> longer; it takes the NVIDIA driver longer to initialize the card
>> than it's willing to wait for.  I suspect that the only thing that
>> parallel booting is doing is starting kdm sooner and hence giving
>> the NVIDIA module even less time to initialize the hardware.

> What is loading the nvidia driver?  When is it done?

It's loaded dynamically by the X server when it starts.  These days, I
believe that's done via the device mappings provided in the
nvidia-kernel-common package, which alias char-major-195* to the nvidia
kernel module, although I'm not deeply familiar with the details of how
dynamic hardware initialization is handled.  But the kernel module is not
loaded until the X server is started, and it's loaded automatically at
that point.

> If it is done by some init.d script,

It's not, unless the mknod commands in the nvidia-kernel init script are
doing some sort of deep magic that I'm fairly sure they're not.  There's
definitely no explicit call to modprobe anywhere in an init script
provided by NVIDIA packages.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Fri, 28 May 2010 07:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to thomas@koch.ro:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Fri, 28 May 2010 07:51:03 GMT) Full text and rfc822 format available.

Message #71 received at 583312@bugs.debian.org (full text, mbox):

From: Thomas Koch <thomas@koch.ro>
To: 583312@bugs.debian.org, 583336@bugs.debian.org
Subject: Same issue with nouveau driver
Date: Fri, 28 May 2010 09:46:48 +0200
Hi,

I think bugs 583312 and 583336 are related. Boths are about kdm timing out 
while the nvidia card is initializing regardless whether the binary nvidia or 
the nouveau driver is used.
In the case of nouveau there even isn't any init.d script AFAIK.

Best regards,

Thomas Koch, http://www.koch.ro




Forcibly Merged 583312 583613. Request was from Julien Cristau <jcristau@debian.org> to control@bugs.debian.org. (Fri, 28 May 2010 21:21:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Tue, 01 Jun 2010 10:33:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Beckmann <debian@abeckmann.de>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Tue, 01 Jun 2010 10:33:05 GMT) Full text and rfc822 format available.

Message #78 received at 583312@bugs.debian.org (full text, mbox):

From: Andreas Beckmann <debian@abeckmann.de>
To: 583312@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: since update to initscripts, sysv... to version 2.88.dfs-5 -- kdm "fails" to load
Date: Tue, 01 Jun 2010 12:29:50 +0200
severity 583312 important
thanks

Downgrading the severity because we can't do really anything about
problems in the non-free driver itself and a workaround (increase
timeout) exists.
There was already another bug about kde startup timeout problems even
before parallel startup was introduced: http://bugs.debian.org/524751


Andreas




Severity set to 'important' from 'serious' Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Tue, 01 Jun 2010 10:33:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Tue, 01 Jun 2010 17:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to thomas@koch.ro:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Tue, 01 Jun 2010 17:09:05 GMT) Full text and rfc822 format available.

Message #85 received at 583312@bugs.debian.org (full text, mbox):

From: Thomas Koch <thomas@koch.ro>
To: pere@hungry.com, control@bugs.debian.org, 583312@bugs.debian.org
Subject: nvidia bug also with nouveau driver
Date: Tue, 1 Jun 2010 19:04:09 +0200
severity 583312 serious
thanks

As noted in Message #71 to this bug, I believe to have observed the very same 
issue with the free nouveau driver. In conclusion I believe that the change in 
severity is not justified by your rationale.

Therefor please also consider bug #583336 and decide, if the bug can still be 
reduced in severity.

Thank you,

Thomas Koch, http://www.koch.ro




Severity set to 'serious' from 'important' Request was from Thomas Koch <thomas@koch.ro> to control@bugs.debian.org. (Tue, 01 Jun 2010 17:09:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Tue, 01 Jun 2010 18:03:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Tue, 01 Jun 2010 18:03:08 GMT) Full text and rfc822 format available.

Message #92 received at 583312@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: thomas@koch.ro
Cc: 583312@bugs.debian.org, pere@hungry.com
Subject: Re: [pkg-nvidia-devel] Bug#583312: nvidia bug also with nouveau driver
Date: Tue, 01 Jun 2010 11:01:33 -0700
Thomas Koch <thomas@koch.ro> writes:

> As noted in Message #71 to this bug, I believe to have observed the very
> same issue with the free nouveau driver. In conclusion I believe that
> the change in severity is not justified by your rationale.

> Therefor please also consider bug #583336 and decide, if the bug can
> still be reduced in severity.

The only purpose served by making this bug against the non-free NVIDIA
drivers RC is that Debian squeeze would just not ship with the non-free
drivers *at all*, since so far as I can tell there isn't much we can do in
the packages to solve this problem.  That the bug also happens with
nouveau indicates to me that the hardware just takes a while to initialize
and there may not be very much we can do about it.

In the meantime, I don't see any reason to block migration of the packages
to testing or release with squeeze for this bug.  It's very annoying, but
it doesn't render them unusable.  Of course if we can find a solution, we
will absolutely fix it as soon as possible, but giving it a higher
severity isn't going to make that process any faster and is just going to
make life harder for testing users who are also going to be experiencing
the same bug.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Severity set to 'important' from 'serious' Request was from Russ Allbery <rra@debian.org> to control@bugs.debian.org. (Tue, 01 Jun 2010 18:03:11 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Tue, 01 Jun 2010 18:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Petter Reinholdtsen <pere@hungry.com>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Tue, 01 Jun 2010 18:39:03 GMT) Full text and rfc822 format available.

Message #99 received at 583312@bugs.debian.org (full text, mbox):

From: Petter Reinholdtsen <pere@hungry.com>
To: 583312@bugs.debian.org
Cc: thomas@koch.ro
Subject: Re: Bug#583312: nvidia bug also with nouveau driver
Date: Tue, 1 Jun 2010 20:35:27 +0200
[Russ Allbery]
> The only purpose served by making this bug against the non-free
> NVIDIA drivers RC is that Debian squeeze would just not ship with
> the non-free drivers *at all*, since so far as I can tell there
> isn't much we can do in the packages to solve this problem.

Well, another purpose might be to document the severity of the issue,
independent of the effect it has on the package currenty having the
bug assosiated with it.

If you really believe this issue can't be fixed in the nvidia driver,
and also believe the issue need to be fixed before squeeze is
released, you could clone and reassign it to all the display manager
packages to get them to increase their timeout to a value you believe
make sense, while keeping the severity RC.  After all, if the issue
should be fixed and the nvidia driver isn't the place to fix it, the
issue should be passed on to those that you believe should fix it. :)

> In the meantime, I don't see any reason to block migration of the
> packages to testing or release with squeeze for this bug.

RC bugs do not block propagation to testing if they are found in the
version in testing as well as the one in unstable.  If you want to
avoid this blockage, you could indicate that the issue is also found
in testing (which I believe it is according to the comments in this
bug :).

RC bugs might cause the package to be thrown out of testing, of
course.  But if the nvidia drivers and kdm fail to get a working X
desktop out of the box in Debian/Squeeze, perhaps it is better to
delay the release or drop support for nvidia than to release with the
problem in place. :)

Happy hacking,
-- 
Petter Reinholdtsen




Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Tue, 01 Jun 2010 19:36:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Russ Allbery <rra@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Tue, 01 Jun 2010 19:36:03 GMT) Full text and rfc822 format available.

Message #104 received at 583312@bugs.debian.org (full text, mbox):

From: Russ Allbery <rra@debian.org>
To: Petter Reinholdtsen <pere@hungry.com>
Cc: 583312@bugs.debian.org, thomas@koch.ro
Subject: Re: [pkg-nvidia-devel] Bug#583312: nvidia bug also with nouveau driver
Date: Tue, 01 Jun 2010 12:31:54 -0700
Petter Reinholdtsen <pere@hungry.com> writes:

> RC bugs might cause the package to be thrown out of testing, of course.
> But if the nvidia drivers and kdm fail to get a working X desktop out of
> the box in Debian/Squeeze, perhaps it is better to delay the release or
> drop support for nvidia than to release with the problem in place. :)

The primary reason why this is not severity: serious from my perspective
is that it's not reproducible for the NVIDIA maintainers with gdm and
isn't affecting all users of kdm and gdm.  Sorry, I should have also said
that explicitly.

There's some variable involved here that we haven't figured out yet.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>




Forcibly Merged 524751 583312 583613. Request was from Andreas Beckmann <andreas@abeckmann.de> to control@bugs.debian.org. (Sun, 06 Jun 2010 11:12:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Wed, 21 Jul 2010 21:06:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Hans-J. Ullrich" <hans.ullrich@loop.de>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Wed, 21 Jul 2010 21:06:10 GMT) Full text and rfc822 format available.

Message #111 received at 583312@bugs.debian.org (full text, mbox):

From: "Hans-J. Ullrich" <hans.ullrich@loop.de>
To: 583312@bugs.debian.org
Subject: Re: since update to initscripts, sysv... to version 2.88.dfs-5 -- kdm "fails" to load
Date: Wed, 21 Jul 2010 23:02:46 +0200
Dear maintainers,

I do not think, the problem is caused by by nvidia-glx-driver. I checked it 
out, and got the same results by using gdm, xdm or kdm, and as well as with 
the vesa driver and xserver-xorg-nv. In all cases I got the same efect: the 
login-manager did not start, the x-server did not start, exactly as the first 
bugreport described this behaviour. 

Maybe to look at the proprietrary nvidia driver is the wrong way and we are 
all looking at the wrong direction!

Best regards

Hans-J. Ullrich





Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Thu, 22 Jul 2010 13:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Andreas Beckmann <debian@abeckmann.de>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Thu, 22 Jul 2010 13:09:04 GMT) Full text and rfc822 format available.

Message #116 received at 583312@bugs.debian.org (full text, mbox):

From: Andreas Beckmann <debian@abeckmann.de>
To: "Hans-J. Ullrich" <hans.ullrich@loop.de>, 583312@bugs.debian.org
Subject: Re: Bug#583312: since update to initscripts, sysv... to version 2.88.dfs-5 -- kdm "fails" to load
Date: Thu, 22 Jul 2010 15:06:43 +0200
Hi Hans,

On 2010-07-21 23:02, Hans-J. Ullrich wrote:
> I do not think, the problem is caused by by nvidia-glx-driver. I checked it 
> out, and got the same results by using gdm, xdm or kdm, and as well as with 
> the vesa driver and xserver-xorg-nv. In all cases I got the same efect: the 
> login-manager did not start, the x-server did not start, exactly as the first 
> bugreport described this behaviour. 

since you can reproduce the problem without the proprietary nvidia
driver, can you "solve" it by increasing the timeouts used by
kdm/gdm/xdm? What values do you need for reliable operation?
What about gdm3?

Can you give a short list of the components in your system (CPU, RAM,
disks, ...), eventually someone can identify something particular "slow"
in your machine - the reason why this problem is so hard to reproduce on
other systems. Do you use anything "exotic" in hard- or software?


Andreas

PS, the timeout variables for gdm/kdm are here (from
nvidia-graphics-drivers NEWS.Debian):

 For 'kdm' edit /etc/kde4/kdm/kdmrc and set  (see #583312)
    [X-*-Core]
    ServerTimeout=120

  For 'gdm' edit /etc/gdm/gdm.conf and set  (see #521699)
    [daemon]
    GdmXserverTimeout=30

  For 'gdm3' the default timeout setting seems to be sufficient.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Sat, 24 Jul 2010 06:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Hans-J. Ullrich" <hans.ullrich@loop.de>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Sat, 24 Jul 2010 06:33:03 GMT) Full text and rfc822 format available.

Message #121 received at 583312@bugs.debian.org (full text, mbox):

From: "Hans-J. Ullrich" <hans.ullrich@loop.de>
To: 583312@bugs.debian.org
Subject: Re: Bug#583312: since update to initscripts, sysv... to version 2.88.dfs-5 -- kdm "fails" to load!
Date: Sat, 24 Jul 2010 08:28:45 +0200
[Message part 1 (text/plain, inline)]
Am Donnerstag, 22. Juli 2010 schrieben Sie:

Hello Andreas,
> Hi Hans,
> 
> On 2010-07-21 23:02, Hans-J. Ullrich wrote:
> > I do not think, the problem is caused by by nvidia-glx-driver. I checked
> > it out, and got the same results by using gdm, xdm or kdm, and as well
> > as with the vesa driver and xserver-xorg-nv. In all cases I got the same
> > efect: the login-manager did not start, the x-server did not start,
> > exactly as the first bugreport described this behaviour.
> 
> since you can reproduce the problem without the proprietary nvidia
> driver, can you "solve" it by increasing the timeouts used by
> kdm/gdm/xdm? What values do you need for reliable operation?
> What about gdm3?
> 
Changing the timings in kdmrc works for me. But maybe I can help, too. What 
did I do?

First of all, I made sure, the bug is still reproducable. So I changed the 
entry in /etc/X11/xorg.conf  from "nvidia" to "vesa". Result: same as I 
described in bug #583613. So I could verify, nvidia-driver is not involved.

Then I increased /etc/kde4/kdm/kdmrc
[X-*-Core]
 to ServerTimeout=120

It was formerly commented out, so that the default parameter was set (which is 
"15"). After I did this, I restarted several times (reboot, halt, with power 
on, with power complete unplugged) and every time it started correctly.

After this, I reactivated "nvidia" in xorg.conf again, and did the same tests 
again. Now everything is working fine (with ServerTimeout set to 120).

At last I stepped back to the original of "15", to seee, if the bug is 
returned back. Yes, it is! 

It is as well using vesa or nvidia. Please see #583613. During my testings, I 
could exclude gdm, kdm and xdm, nvidia, vesa, xserver-xorg-nv. The only thing, 
which stayed, is the xserver-xorg driver. I think, here might be the main 
problem.




> Can you give a short list of the components in your system (CPU, RAM,
> disks, ...), eventually someone can identify something particular "slow"
> in your machine - the reason why this problem is so hard to reproduce on
> other systems. Do you use anything "exotic" in hard- or software?
> 

Yeah, no problem. I am using an Acer Aspire 7520G, 2GB RAM (677MHz), dual-core 
AMD64 X2 (with 2 x 2.4 GHz clock). Graphics card is a Nvidia GeForce 8600GS 
with 512MB RAM. Drives are 2 x sata , each 160 GB, whilst /home, /var, /usr 
are encrypted (dm-crypt). keys are loaded at boot from usb-stick.

I have a good friend, which uses the same package configuration like mine, but 
she has NO problems at boot. She owns two notebboks, one with a nvidia G-210 
graphics card (and no problems), the other one with an ATI graphics card 
(using xserver-xorg-ati) which she reports of similar problems we are 
discussing.


I am using a second computer (packages identically to my notebook) with the 
same behaviour. On both computers (the other one is a little bit older, AMD 
Athlon single cpu 2GHz, 512MB RAM (266MHz), Nvidia GeForce 7300 Ultra) I could 
reproduce and solve our problem.
 
Last but not least, here is the output of lspci:

00:00.0 RAM memory: nVidia Corporation MCP67 Memory Controller (rev a2)
00:01.0 ISA bridge: nVidia Corporation MCP67 ISA Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP67 SMBus (rev a2)
00:01.2 RAM memory: nVidia Corporation MCP67 Memory Controller (rev a2)
00:01.3 Co-processor: nVidia Corporation MCP67 Co-processor (rev a2)
00:02.0 USB Controller: nVidia Corporation MCP67 OHCI USB 1.1 Controller (rev 
a2)
00:02.1 USB Controller: nVidia Corporation MCP67 EHCI USB 2.0 Controller (rev 
a2)
00:04.0 USB Controller: nVidia Corporation MCP67 OHCI USB 1.1 Controller (rev 
a2)
00:04.1 USB Controller: nVidia Corporation MCP67 EHCI USB 2.0 Controller (rev 
a2)
00:06.0 IDE interface: nVidia Corporation MCP67 IDE Controller (rev a1)
00:07.0 Audio device: nVidia Corporation MCP67 High Definition Audio (rev a1)
00:08.0 PCI bridge: nVidia Corporation MCP67 PCI Bridge (rev a2)
00:09.0 IDE interface: nVidia Corporation MCP67 AHCI Controller (rev a2)
00:0a.0 Ethernet controller: nVidia Corporation MCP67 Ethernet (rev a2)
00:0b.0 PCI bridge: nVidia Corporation MCP67 PCI Express Bridge (rev a2)
00:0c.0 PCI bridge: nVidia Corporation MCP67 PCI Express Bridge (rev a2)
00:0d.0 PCI bridge: nVidia Corporation MCP67 PCI Express Bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
01:04.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 
05)
01:04.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host 
Adapter (rev 22)
01:04.2 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller (rev 12)
01:04.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter 
(rev 12)
01:04.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev ff)
02:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce 8600M GS] 
(rev a1)
05:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless 
Network Adapter (rev 01)


My xorg.conf will be sent below.
 

Please feel free, to ask for more information, like logfiles, strace output or 
similar.

Best regards!

Hans

[xorg.conf (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Mon, 02 Aug 2010 13:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Dominique Dumont <dominique.dumont@hp.com>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>. (Mon, 02 Aug 2010 13:39:03 GMT) Full text and rfc822 format available.

Message #126 received at 583312@bugs.debian.org (full text, mbox):

From: Dominique Dumont <dominique.dumont@hp.com>
To: "Hans-J. Ullrich" <hans.ullrich@loop.de>, 583312@bugs.debian.org
Subject: Re: Bug#583312: since update to initscripts, sysv... to version 2.88.dfs-5 -- kdm "fails" to load!
Date: Mon, 2 Aug 2010 15:37:51 +0200
On Saturday 24 July 2010 08:28:45 Hans-J. Ullrich wrote:
> Then I increased /etc/kde4/kdm/kdmrc
> [X-*-Core]
>  to ServerTimeout=120

Hmm, on my machine (Debian/sid) the ServerTimeout parameter that has a "15" 
default value is located in local display section "[X-:*-Core]", not in [X-*-
Core].

Setting ServerTimeout to 120 in [X-*-Core] did not fix the problem on my 
machine. Only changing ServerTimeout to 30 in [X-:*-Core] did resolve the 
issue.

Thanks for the tip anyway.

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont




Merged 524751 583312 583613. Request was from Holger Levsen <holger@layer-acht.org> to control@bugs.debian.org. (Wed, 08 Sep 2010 18:10:48 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>:
Bug#583312; Package nvidia-glx. (Wed, 06 Oct 2010 01:27:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Eckhart Wörner <ewoerner@kde.org>:
Extra info received and forwarded to list. Copy sent to Debian NVIDIA Maintainers <pkg-nvidia-devel@lists.alioth.debian.org>.

Your message did not contain a Subject field. They are recommended and useful because the title of a $gBug is determined using this field. Please remember to include a Subject field in your messages in future.

(Wed, 06 Oct 2010 01:27:05 GMT) Full text and rfc822 format available.


Message #133 received at 583312@bugs.debian.org (full text, mbox):

From: Eckhart Wörner <ewoerner@kde.org>
To: 583336@bugs.debian.org, 590626@bugs.debian.org, 597699@bugs.debian.org, 583312@bugs.debian.org, 524751@bugs.debian.org, 583613@bugs.debian.org
Date: Wed, 06 Oct 2010 03:25:28 +0200
reassign 597699 kdm
reassign 583312 kdm
forcemerge 590626 583336 597699 583312
retitle 590626 KDM timeout is not sufficient for parallel boot
tags 597699 + pending
thanks

KDM timeout will be increased in the next upload of kdebase-workspace.




Bug reassigned from package 'nvidia-glx' to 'kdm'. Request was from Eckhart Wörner <ewoerner@kde.org> to control@bugs.debian.org. (Wed, 06 Oct 2010 01:27:17 GMT) Full text and rfc822 format available.

Forcibly Merged 524751 583312 583336 583613 590626 597699. Request was from Eckhart Wörner <ewoerner@kde.org> to control@bugs.debian.org. (Wed, 06 Oct 2010 01:27:19 GMT) Full text and rfc822 format available.

Changed Bug title to 'KDM timeout is not sufficient for parallel boot' from 'since update to initscripts, sysv... to version 2.88.dfs-5 -- kdm "fails" to load' Request was from Eckhart Wörner <ewoerner@kde.org> to control@bugs.debian.org. (Wed, 06 Oct 2010 01:27:23 GMT) Full text and rfc822 format available.

Added tag(s) pending. Request was from Eckhart Wörner <ewoerner@kde.org> to control@bugs.debian.org. (Wed, 06 Oct 2010 01:27:27 GMT) Full text and rfc822 format available.

Removed tag(s) moreinfo. Request was from Eckhart Wörner <ewoerner@kde.org> to control@bugs.debian.org. (Wed, 06 Oct 2010 01:39:07 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sun, 28 Nov 2010 07:29:14 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Thu Apr 24 23:08:14 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.