Seen in context of libpthread, but probably not directly related to it.

IRC, freenode, #hurd, 2012-08-30

<gnu_srs> Do you also experience a frozen hurd console?
<braunr> yes
<braunr> i didn't check but i'm almost certain it's a bug in my branch
<braunr> the replacement of condition_implies was a bit hasty in some
  places
<braunr> this is why i want to rework it separately

IRC, freenode, #hurd, 2012-09-03

<gnu_srs> braunr: Did you find the cause of the Hurd console freeze for
  your libpthread branch?
<braunr> gnu_srs: like i said, a bug
<braunr> probably in the replacement of condition_implies
<braunr> i rewrote that part in libpipe and it no works
<braunr> now*

<braunr> gnu_srs: the packages have been updated
<braunr> and these apparently fix the hurd console issue correctly

IRC, freenode, #hurd, 2012-09-04

<braunr> gnu_srs: this hurd console problem isn't fixed
<braunr> it seems to be due to a race condition that only affects the first
  console
<braunr> and by reading the code i can't see how it can even work oO
<gnu_srs> braunr: just rebooted, tty1 is still locked, tty2-6 works. And
  the floppy error stays (maybe a kvm bug??) 
<braunr> the floppy error is probably a kvm bug as we discussed
<braunr> the tty1 locked isn't
<braunr> i have it too
<braunr> it seems to be a bug in the hurd console server
<braunr> which is started by tty1, but for some reason, doesn't return a
  valid answer at init time
<braunr> if you kill the term handling tty1, you'll see your first tty
  starts working
<braunr> for now i'll try a hack that starts the hurd console server before
  the clients
<braunr> doesn't work eh
<braunr> tty1 is the only one started before runttys
<braunr> indeed, fixing /etc/hurd/runsystem.gnu so that it doesn't touch
  tty1 fixes the problem
<gnu_srs> do you have an explanation?
<braunr> not really no
<braunr> but it will do for now
<pinotree> samuel added that with the comment above, apparently to
  workaround some other issue of the hurd console
<braunr> i'm pretty sure the bug is already visible with cthreads
<braunr> the first console always seems weird compared to the others
<braunr> with a login: at the bottom of the screen
<braunr> didn't you notice ?
<pinotree> sometimes, but not often
<braunr> typical of a race
<pinotree> (at least for me)
<braunr> pthreads being slightly slower exposes it
<gnu_srs> confirmed, it works by commenting out touch /dev/tty1
<gnu_srs> yes, the login is at the bottom of the screen, sometimes one in
  the upper part too:-/
<braunr> so we have a new open issue
<braunr> hm
<braunr> exiting the first tty doesn't work
<braunr> which makes me think of the issue we have with screen
<gnu_srs> confirmed!
<braunr> also, i don't understand why we have getty on tty1, but nothing on
  the other terminals
<braunr> something is really wrong with terminals on hurd *sigh*
<braunr> ah, the problem looks like it happens when getty attempts to
  handle a terminal !
<braunr> gnu_srs: anyway, i don't think it should be blocking for the
  conversion to pthreads
<braunr> but it would be better if someone could assign himself that bug
<braunr> :)

IRC, freenode, #hurd, 2012-09-05

<antrik> braunr: the login at the bottom of the screen if from the Mach
  console I believe
<braunr> antrik: well maybe, but it shouldn't be there anyway
<antrik> braunr: why not?
<antrik> it's confusing, but perfectly correct as far as I can tell
<braunr> antrik: two login: on the same screen ?
<braunr> antrik: it's even more confusing when comparing with other ttys
<antrik> I mean it's correct from a techincal point of view... I'm not
  saying it's helpful for the user ;-)
<braunr> i'm not even sure it's correct
<braunr> i've double checked the pthreads patch and didn't see anything
  wrong there
<antrik> perhaps the startup of the Hurd console could be delayed a bit to
  make sure it happens after the Mach console login is done printing
  stuff...
<braunr> why are our gettys stubs ?
<antrik> I never understood the point of a getty TBH...
<braunr> well you need to communicate to something behind your terminal,
  don't you ?
<braunr> with*
<antrik> why not just launch the login program or login shell right away?
<braunr> what if you want something else than a login program ?
<antrik> like what?
<antrik> and how would a getty help with that?
<braunr> an ascii-art version of star wars
<braunr> it would be configured to start something else
<antrik> and why does that need a getty? why not just start something else
  directly?
<braunr> well getty is about the serial line parameters actually
<antrik> yeah, I had a vague understanding that it has something to do with
  serial lines (or real TTY lines)... but we hardly need that on local
  cosoles :-)
<antrik> consoles
<braunr> right
<braunr> but then why even bother with something like runttys
<antrik> well, something has to start the terminal servers?...
<antrik> I might be confused though
<braunr> what i don't understand is
<braunr> why is there no getty at startup, whereas they are spawned when
  logging off ?
<antrik> they are? that's fascinating indeed ;-)
<braunr> does it behave like this on your old version ?
<antrik> I don't remember ever having seen a "getty" process on my Hurd
  systems...
<braunr> can you log on e.g. tty2 and then log out, and see ?
<antrik> OTOH, I'm hardly ever using consoles...
<antrik> hm... I think that should be possible remotely using the console
  client with ncurses driver? never tried that...
<braunr> ncurses driver ?
<braunr> hum i don't know, never tried either
<braunr> and it may add other bugs :p
<braunr> better wait to be close to the machine
<antrik> hehe
<antrik> well, it's a good excuse for trying the ncurses driver ;-)
<antrik> hrm
<antrik> alien:~# console -d ncursesw
<antrik> console: loading driver `ncursesw' failed: Gratuitous error
<antrik> I guess nobody tested that stuff in years