It has *nothing* to do with tcflush(). As I said above, If I revert the patch that introduced the tcflush() call, I can still reproduce this problem. This is just the semantics of select(): If a fd is in an error state, then a subsequent read() or write() won't block (since they will just return an error), so select() returns right away. So what we need to figure out is why the console fd dies.
On Tue, Oct 6, 2009 at 2:26 PM, Scott James Remnant <[email protected]>wrote: > Still nothing to do with Upstart. > > I would like to know *what* X is doing with that tcflush() and why it is > apparently unable to cope with it returning an error. What is that > trying to access, why isn't there a graceful fallback for it not > existing, etc. > > Let's figure this out, rather than just trying to work around it. Our > whole fast boot plans are contingent on getting X up early - right now > you're saying that's impossible - and I want you to prove that. > I'm not saying this is impossible, but clearly there's something we need to wait for before we can start X (and not for a very long time, since we don't seem to see this problem on slower systems at all). -- [karmic] Xorg 100% CPU utilization -- only after first login https://bugs.launchpad.net/bugs/439138 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
