[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#603767: gdm: starts on v8 instead of vt7

On Thu, Nov 18, 2010 at 11:41:37AM +1100, dave b wrote:
> So what's kind of why i asked about how you were trying to find the bug.
> Don't tell me to search through lots of C code point it out!
> I don't have time for that and you seemed to know more!

Please calm down and don't shout at me. I'm not willing to be treated
this way. I don't have time for that.

I never told you to search through lots of C code, neither do I know
Besides my ability to successfully reproduce this on 2 systems with
different hardware all I have are dark memories and wild guesses.
I know the issue exists, I know it's nothing really new, and I know that
all I have to do to work around it is to avoid GDM restarts.
I never tried really hard to track it down, I just never wanted to spend
the time it would take. This thread showed up on debian-devel@ and I
just added my 2 cents in the hope that somebody probably could gain some
ideas from it.

Regarding the wild guesses: I personally somehow believe that any of
the Gnome daemons transparently started in the background of Gnome
applications causes this permanent VT allocation. As I said - it's
nothing more than a wild guess - a gut instinct if you like. I cannot
prove it. Of course, I already tried to find processes lingering around
after stopping GDM - with no success.

An idea to trace this down would be to track the processes which
increase/decrease the tty usage count in the kernel. I have no idea if
this is already possible with the current kernel infrastructure or how,
but I'd be willing to run patched kernels to track it.

> We so then the question is what happens if it is 'busy' and we attempt
> to use it anyways ;) ?

I don't think this should be the way to choose. I would personally
prefer solving the cause over working around the result.

If you think technology can solve your problems you don't understand
technology and you don't understand your problems.
                                -- Bruce Schneier

Attachment: signature.asc
Description: Digital signature

Reply to: