Re: [gentoo-user] Re: nvidia update problems
On Tuesday 04 January 2011 21:51:37 Alan McKinnon wrote: Do you have rc_parallel=YES in /etc/rc.conf? Nope. These are the only values set in that file; everything else is comment: rc_interactive=YES rc_shell=/sbin/sulogin rc_hotplug=!* rc_logger=YES rc_start_wait=100 unicode=YES rc_tty_number=12 Try setting it to NO. If stuff then works right, we know your start order is incorrect and I would be suspecting you declined an update in /etc/init.d/ that you should have accepted. I don't think I've ever challenged any update in /etc/init.d/. As I haven't changed anything in that directory I've no reason not to accept any new version. Dunno how you would fix that easily apart from re-emerging everything related that creates an init script. Hmm. I'm wondering about that rc_hotplug line. I'll try removing it. I put it there because I'm a control freak when it comes to computers, and I prefer an orderly startup sequence that I can follow. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] Re: nvidia update problems
On Wednesday 05 January 2011 12:43:43 Peter Humphrey wrote: These are the only values set in [/etc/rc.conf]; everything else is comment: rc_interactive=YES rc_shell=/sbin/sulogin rc_hotplug=!* rc_logger=YES rc_start_wait=100 unicode=YES rc_tty_number=12 [...] Hmm. I'm wondering about that rc_hotplug line. I'll try removing it. I put it there because I'm a control freak when it comes to computers, and I prefer an orderly startup sequence that I can follow. That fixed it. Thanks all for the ideas. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] Re: nvidia update problems
Apparently, though unproven, at 16:44 on Wednesday 05 January 2011, Peter Humphrey did opine thusly: On Wednesday 05 January 2011 12:43:43 Peter Humphrey wrote: These are the only values set in [/etc/rc.conf]; everything else is comment: rc_interactive=YES rc_shell=/sbin/sulogin rc_hotplug=!* rc_logger=YES rc_start_wait=100 unicode=YES rc_tty_number=12 [...] Hmm. I'm wondering about that rc_hotplug line. I'll try removing it. I put it there because I'm a control freak when it comes to computers, and I prefer an orderly startup sequence that I can follow. That fixed it. Thanks all for the ideas. Interesting. Now we need to figure out *why* it was causing your problems -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: nvidia update problems
On Wednesday 05 January 2011 15:32:29 Alan McKinnon wrote: Now we need to figure out *why* it was causing your problems I could just hand it over to the devs via a bug report, but I ought to do some detective work first, if only to decide which subsystem to log it against. The trouble with that idea is that it implies that I must think. Not altogether a good idea. ;-( -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] Re: nvidia update problems
Apparently, though unproven, at 17:54 on Wednesday 05 January 2011, Peter Humphrey did opine thusly: On Wednesday 05 January 2011 15:32:29 Alan McKinnon wrote: Now we need to figure out *why* it was causing your problems I could just hand it over to the devs via a bug report, but I ought to do some detective work first, if only to decide which subsystem to log it against. I think the system worked by design and the bug is in your config i.e you had a not particularly valid one by any reasonable definition of valid: # rc_hotplug is a list of services that we allow to be hotplugged. # By default we do not allow hotplugging. # A hotplugged service is one started by a dynamic dev manager when a matching # hardware device is found. # This service is intrinsically included in the boot runlevel. # To disable services, prefix with a ! # Example - rc_hotplug=net.wlan !net.* # This allows net.wlan and any service not matching net.* to be plugged. # Example - rc_hotplug=* # This allows all services to be hotplugged #rc_hotplug=* Setting it to !* implies that the dev manager will do nothing. I imagine that if you have nvidia hardware and drivers, then you *do* want the kernel to find it and do the right thing for that hardware. This is a case where you must be pedantic about letting the kernel create only those things it needs to create, nothing more and nothing less. You cannot possibly improve on the kernel's own knowledge of the hardware :-) The trouble with that idea is that it implies that I must think. Not altogether a good idea. ;-( Ooh dear. Sleeping dogs lying and all that, hey? ;-) -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: nvidia update problems
On Monday 03 January 2011 14:40:41 walt wrote: I'm wondering if you have some mixture of baselayout versions on that machine from previous updates. Unlikely: this box has been ~amd64 since before it had a complete system. Could your machine be trying to start something other than kdm by mistake? I.e., maybe you are starting kdm for the first time from the VT instead of re-starting it? Also unlikely. I tried taking xdm out of the default run-level and calling both it and xdm-setup in /etc/conf.d/local. It started up ok then. -- just a SWAG :) Eh? Don't know that one. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
[gentoo-user] Re: nvidia update problems
On 01/04/2011 02:50 AM, Peter Humphrey wrote: On Monday 03 January 2011 14:40:41 walt wrote: I'm wondering if you have some mixture of baselayout versions on that machine from previous updates. Unlikely: this box has been ~amd64 since before it had a complete system. Could your machine be trying to start something other than kdm by mistake? I.e., maybe you are starting kdm for the first time from the VT instead of re-starting it? Also unlikely. I tried taking xdm out of the default run-level and calling both it and xdm-setup in /etc/conf.d/local. It started up ok then. That experiment still makes me suspect something in /etc is wrong. I'm out of ideas except to search through /etc for files with old dates. -- just a SWAG :) Eh? Don't know that one. Scientific Wild-Ass Guess.
Re: [gentoo-user] Re: nvidia update problems
Apparently, though unproven, at 12:50 on Tuesday 04 January 2011, Peter Humphrey did opine thusly: On Monday 03 January 2011 14:40:41 walt wrote: I'm wondering if you have some mixture of baselayout versions on that machine from previous updates. Unlikely: this box has been ~amd64 since before it had a complete system. Could your machine be trying to start something other than kdm by mistake? I.e., maybe you are starting kdm for the first time from the VT instead of re-starting it? Also unlikely. I tried taking xdm out of the default run-level and calling both it and xdm-setup in /etc/conf.d/local. It started up ok then. Do you have rc_parallel=YES in /etc/rc.conf? Try setting it to NO. If stuff then works right, we know your start order is incorrect and I would be suspecting you declined an update in /etc/init.d/ that you should have accepted. Dunno how you would fix that easily apart from re-emerging everything related that creates an init script. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: nvidia update problems
On Sunday 02 January 2011 15:51:24 walt wrote: On 01/02/2011 03:51 AM, Peter Humphrey wrote: It looks as though the boot sequence is going wrong somehow, because when I get my initial blank screen, if I then switch to a VT and restart xdm, everything works as expected. Just for clarification, are you saying that you can do that even without re-emerging nvidia-drivers? Exactly so - without doing anything other than restarting KDM. This is an ~amd64 box, by the way. So, when you first switch to the VT, the nvidia module is already loaded? Yes; without it I wouldn't see a blinking cursor. I think the raster would be absent too if nothing were driving the hardware. The boot sequence is complete. Is there an X session already running before you restart kdm? (I don't use any of *dm, so I don't know if they are X apps that require X to be running before they can write to the screen.) As far as I know, KDM starts X itself. At VT4 (which I use habitually for root logins) I issue the command: $ /etc/init.d/xdm restart logout which starts the KDM session as normal. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
[gentoo-user] Re: nvidia update problems
On 01/03/2011 02:11 AM, Peter Humphrey wrote: On Sunday 02 January 2011 15:51:24 walt wrote: On 01/02/2011 03:51 AM, Peter Humphrey wrote: It looks as though the boot sequence is going wrong somehow, because when I get my initial blank screen, if I then switch to a VT and restart xdm, everything works as expected. Just for clarification, are you saying that you can do that even without re-emerging nvidia-drivers? Exactly so - without doing anything other than restarting KDM. This is an ~amd64 box, by the way. So nvidia.ko is not the problem then.(Unless it's being loaded too late in the boot sequence.) Is there an X session already running before you restart kdm? (I don't use any of *dm, so I don't know if they are X apps that require X to be running before they can write to the screen.) As far as I know, KDM starts X itself. At VT4 (which I use habitually for root logins) I issue the command: $ /etc/init.d/xdm restart logout which starts the KDM session as normal. I'm wondering if you have some mixture of baselayout versions on that machine from previous updates. A glance through the many relevant files in /etc/env.d/, /etc/conf.d/, /etc/X11*, /etc/rc.conf, /etc/init.d leaves me confused about what happens during xdm startup. Could your machine be trying to start something other than kdm by mistake? I.e., maybe you are starting kdm for the first time from the VT instead of re-starting it? I'd try touch /etc/.noxdm and reboot, then log in and do /etc/init.d/xdm start again. If that also works perfectly then I'd guess there is something in the list of directories above that is mis-configured -- my guess would be that the bootscripts are trying to start the wrong xdm -- just a SWAG :)
[gentoo-user] Re: nvidia update problems
On 01/02/2011 03:51 AM, Peter Humphrey wrote: On Friday 31 December 2010 12:52:08 Peter Humphrey wrote: When I start the system, instead of the kdm login screen I get a blinking cursor in the top-[left] of a blank screen. An emerge of nvidia-drivers enables me to restart kdm and get a proper screen. This is in spite of not having been able to unload the old nvidia module because it was in use. It looks as though the boot sequence is going wrong somehow, because when I get my initial blank screen, if I then switch to a VT and restart xdm, everything works as expected. Just for clarification, are you saying that you can do that even without re-emerging nvidia-drivers? So, when you first switch to the VT, the nvidia module is already loaded? Is there an X session already running before you restart kdm? (I don't use any of *dm, so I don't know if they are X apps that require X to be running before they can write to the screen.)
Re: [gentoo-user] Re: nvidia update problems
On Friday 31 December 2010 21:00:57 Alan McKinnon wrote: Apparently, though unproven, at 20:54 on Friday 31 December 2010, walt did opine thusly: So, if you've ever run the NVIDIA install program manually, you probably have two different nvidia.ko files in /lib/modules, and the wrong one gets loaded automatically at boot time. Re-emerging nvidia-drivers will build *and* load the correct kernel module each time you do it. May not be your problem but it's easy to check, at least. I didn't think I'd ever run the nVidia installation program, and on checking I see one nvidia.ko for each kernel version I have installed, so that isn't the problem. module-rebuild takes care of all that nicely. And it wants to rebuild the module again, even though I only remerged it yesterday. Something is messing about with the nVidia module. Thanks for the ideas, gents. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] Re: nvidia update problems
Apparently, though unproven, at 12:36 on Saturday 01 January 2011, Peter Humphrey did opine thusly: On Friday 31 December 2010 21:00:57 Alan McKinnon wrote: Apparently, though unproven, at 20:54 on Friday 31 December 2010, walt did opine thusly: So, if you've ever run the NVIDIA install program manually, you probably have two different nvidia.ko files in /lib/modules, and the wrong one gets loaded automatically at boot time. Re-emerging nvidia-drivers will build *and* load the correct kernel module each time you do it. May not be your problem but it's easy to check, at least. I didn't think I'd ever run the nVidia installation program, and on checking I see one nvidia.ko for each kernel version I have installed, so that isn't the problem. module-rebuild takes care of all that nicely. And it wants to rebuild the module again, even though I only remerged it yesterday. Something is messing about with the nVidia module. That's how module-rebuild works, it's not broken. It *will* rebuild everything. It can't rely on the normal version numbers and USE flags to know if something needs updating, as the problem it is designed to solve is when you do a kernel upgrade and leave yourself without the out-of-tree modules you need in that new kernel version. If you use nvidia version X, then you need the version X kernel modules in every /lib/modules/kernel/ you use. So it just rebuilds everything every time. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: nvidia update problems
On Saturday 01 January 2011 20:26:11 Alan McKinnon wrote: Apparently, though unproven, at 12:36 on Saturday 01 January 2011, Peter Humphrey did opine thusly: Something is messing about with the nVidia module. That's how module-rebuild works, it's not broken. It *will* rebuild everything. Yes, I wasn't impugning module-rebuild. All the same, something does appear to be messing about with the nVidia module. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
[gentoo-user] Re: nvidia update problems
On 12/31/2010 04:52 AM, Peter Humphrey wrote: This is weird. When I start the system, instead of the kdm login screen I get a blinking cursor in the top-right of a blank screen. An emerge of nvidia-drivers enables me to restart kdm and get a proper screen. This is in spite of not having been able to unload the old nvidia module because it was in use. I've noticed that running the NVIDIA installation program manually puts the resulting nvidia.ko in a different directory than when using emerge to do the install. So, if you've ever run the NVIDIA install program manually, you probably have two different nvidia.ko files in /lib/modules, and the wrong one gets loaded automatically at boot time. Re-emerging nvidia-drivers will build *and* load the correct kernel module each time you do it. May not be your problem but it's easy to check, at least.
Re: [gentoo-user] Re: nvidia update problems
Apparently, though unproven, at 20:54 on Friday 31 December 2010, walt did opine thusly: On 12/31/2010 04:52 AM, Peter Humphrey wrote: This is weird. When I start the system, instead of the kdm login screen I get a blinking cursor in the top-right of a blank screen. An emerge of nvidia-drivers enables me to restart kdm and get a proper screen. This is in spite of not having been able to unload the old nvidia module because it was in use. I've noticed that running the NVIDIA installation program manually puts the resulting nvidia.ko in a different directory than when using emerge to do the install. So, if you've ever run the NVIDIA install program manually, you probably have two different nvidia.ko files in /lib/modules, and the wrong one gets loaded automatically at boot time. Re-emerging nvidia-drivers will build *and* load the correct kernel module each time you do it. May not be your problem but it's easy to check, at least. module-rebuild takes care of all that niceyl. You only have to remember to run that one command, not all the individual out- of-mainline modules you have installed. -- alan dot mckinnon at gmail dot com
