Bug 133908 - Preload prevenst earlykdm from working propery when hardware changes between boots.
Summary: Preload prevenst earlykdm from working propery when hardware changes between ...
Status: RESOLVED WONTFIX
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Other (show other bugs)
Version: Final
Hardware: x86-64 SuSE Linux 10.0
: P5 - None : Normal
Target Milestone: ---
Assignee: Stephan Kulow
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-15 20:25 UTC by Patrick Hernandez
Modified: 2006-02-04 18:41 UTC (History)
1 user (show)

See Also:
Found By: Customer
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Output of strace in earlykdm (281.97 KB, text/plain)
2005-12-01 19:36 UTC, Patrick Hernandez
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Hernandez 2005-11-15 20:25:36 UTC
I have noticed an bug in the way preload interacts with the system.  I am running SUSE 10.0 Retail on a HP ZV5410US Athlon64 laptop computer which I sometimes place in a docking station.  The bug seemed to appear after the following sequence of events. 

1. I performed a fresh install and all the current updates through YOU.
2. I placed the laptop in the dock which has a USB keyboard and mouse attached. The dock also has volume controls, a serial port, additional audio ports (line out, SPDIF, etc.) USB hubs and power.
3. I ran the system for a few days in the dock.
4. When I removed the laptop from the dock, the system seemed to boot normally except KDM (XDM) didn't start with out any errors in the log except the statement that kdm timed out.

I was able to reproduce the bug consistently whenever the hardware seemed to change between boots.  After digging around the system configs and trying different things, I believe the problem is with preload.  I de-installed preload and the bug seemed to disappear.  I then found that another annoying bug appeared: the network configs didn't get activated at every boot on a random basis.  I re-installed preload and the network config problem went away and the first bug reappeared.  After digging some more, I found that earlykdm depends on preload.  I disabled earlykdm, and the problems seem to have disappeared and KDM comes up at every boot now.  I scanned all of the logs and couldn't find any errors being reported except the one mentioned above.
Comment 1 Michael Gross 2005-11-17 14:03:20 UTC
Stephan? Something for you?
Comment 2 Stephan Kulow 2005-11-17 14:15:33 UTC
this has nothing to do with preload exactly. This is a timing problem that is triggered depending on preload being there. I'm clueless how to debug this remotely ;(
Comment 3 Dr. Werner Fink 2005-11-17 14:21:29 UTC
Maybe this is related to bug #130451.  Please apply the YOU update
for insserv and execute as root the command insserv. After this
please redo you checks and report if the problem(s) stay around.
Comment 4 Patrick Hernandez 2005-11-17 18:25:23 UTC
I have already installed all relevant patches before this problem occured and I looked to see if insserv was included and it was.  I don't know if it occurred before the patches as I didn't start using the system until everything was installed.  I noticed in bug #130451 that there is mention of third party init scripts being a possible issue.  I do have the flexlm license manager for MATLAB set to start at boot and I did have to edit it to add the lines to make it work with innserv properly as just creating a link to it in the rc directory didn't work.  I'll try running the innserv command after re-enabling earykdm as you suggest and if the problem re-occurs, I will try disabling flexlm in init to see if that might be it.
Comment 5 Patrick Hernandez 2005-11-17 19:33:59 UTC
The suggestions didn't work as removing flexlm from init didn't either.  The only thing that seems to work around the problem is disabling earlykdm in init.  I have deduced that it may be related to using an external USB mouse as that is the hardware that seems to make the problem appear.  It isn't brand specific as I tried a couple of different mice and had the same problem.  The system will also come up normally after rebooting once or twice until the mouse changes again between boots.  The mice also work fine with no apparent problems or errors in the logs while the system is running.
Comment 6 Stephan Kulow 2005-11-30 13:38:47 UTC
I suggest you try adding a "strace -f -p $$ -o /tmp/somewhere &" in earlykdm - so far my only fix would be to trigger a sdb article as you seem to be the only one with such a problem.
Comment 7 Patrick Hernandez 2005-11-30 17:04:41 UTC
Should I place it at the beginning of the process or at the beginning of the start portion?
Comment 8 Stephan Kulow 2005-11-30 17:27:15 UTC
shouldn't matter
Comment 9 Patrick Hernandez 2005-12-01 19:36:52 UTC
Created attachment 59610 [details]
Output of strace in earlykdm
Comment 10 Patrick Hernandez 2005-12-01 19:39:28 UTC
The attachment was captured when the problem occurred after re-enabling earlykdm.  It seemed to occur at random this time.
Comment 11 Stephan Kulow 2006-02-04 18:41:41 UTC
ok, I have no idea what this is about and the workaround is simple (chkconfig earlykdm off) - and you're the only one reporting similiar problems.