From 5bd36fdff16871eb7d06fc26cac07e7f2703432b Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 29 Nov 2012 01:33:22 +0100 Subject: IRC. --- open_issues/console_tty1.mdwn | 151 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 open_issues/console_tty1.mdwn (limited to 'open_issues/console_tty1.mdwn') diff --git a/open_issues/console_tty1.mdwn b/open_issues/console_tty1.mdwn new file mode 100644 index 00000000..614c02c9 --- /dev/null +++ b/open_issues/console_tty1.mdwn @@ -0,0 +1,151 @@ +[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +Seen in context of [[libpthread]], but probably not directly related to it. + + +# IRC, freenode, #hurd, 2012-08-30 + + Do you also experience a frozen hurd console? + yes + i didn't check but i'm almost certain it's a bug in my branch + the replacement of condition_implies was a bit hasty in some + places + this is why i want to rework it separately + + +## IRC, freenode, #hurd, 2012-09-03 + + braunr: Did you find the cause of the Hurd console freeze for + your libpthread branch? + gnu_srs: like i said, a bug + probably in the replacement of condition_implies + i rewrote that part in libpipe and it no works + now* + + gnu_srs: the packages have been updated + and these apparently fix the hurd console issue correctly + +## IRC, freenode, #hurd, 2012-09-04 + + gnu_srs: this hurd console problem isn't fixed + it seems to be due to a race condition that only affects the first + console + and by reading the code i can't see how it can even work oO + braunr: just rebooted, tty1 is still locked, tty2-6 works. And + the floppy error stays (maybe a kvm bug??) + the floppy error is probably a kvm bug as we discussed + the tty1 locked isn't + i have it too + it seems to be a bug in the hurd console server + which is started by tty1, but for some reason, doesn't return a + valid answer at init time + if you kill the term handling tty1, you'll see your first tty + starts working + for now i'll try a hack that starts the hurd console server before + the clients + doesn't work eh + tty1 is the only one started before runttys + indeed, fixing /etc/hurd/runsystem.gnu so that it doesn't touch + tty1 fixes the problem + do you have an explanation? + not really no + but it will do for now + samuel added that with the comment above, apparently to + workaround some other issue of the hurd console + i'm pretty sure the bug is already visible with cthreads + the first console always seems weird compared to the others + with a login: at the bottom of the screen + didn't you notice ? + sometimes, but not often + typical of a race + (at least for me) + pthreads being slightly slower exposes it + confirmed, it works by commenting out touch /dev/tty1 + yes, the login is at the bottom of the screen, sometimes one in + the upper part too:-/ + so we have a new open issue + hm + exiting the first tty doesn't work + which makes me think of the issue we have with screen + confirmed! + also, i don't understand why we have getty on tty1, but nothing on + the other terminals + something is really wrong with terminals on hurd *sigh* + ah, the problem looks like it happens when getty attempts to + handle a terminal ! + gnu_srs: anyway, i don't think it should be blocking for the + conversion to pthreads + but it would be better if someone could assign himself that bug + :) + + +## IRC, freenode, #hurd, 2012-09-05 + + braunr: the login at the bottom of the screen if from the Mach + console I believe + antrik: well maybe, but it shouldn't be there anyway + braunr: why not? + it's confusing, but perfectly correct as far as I can tell + antrik: two login: on the same screen ? + antrik: it's even more confusing when comparing with other ttys + I mean it's correct from a techincal point of view... I'm not + saying it's helpful for the user ;-) + i'm not even sure it's correct + i've double checked the pthreads patch and didn't see anything + wrong there + 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... + why are our gettys stubs ? + I never understood the point of a getty TBH... + well you need to communicate to something behind your terminal, + don't you ? + with* + why not just launch the login program or login shell right away? + what if you want something else than a login program ? + like what? + and how would a getty help with that? + an ascii-art version of star wars + it would be configured to start something else + and why does that need a getty? why not just start something else + directly? + well getty is about the serial line parameters actually + 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 :-) + consoles + right + but then why even bother with something like runttys + well, something has to start the terminal servers?... + I might be confused though + what i don't understand is + why is there no getty at startup, whereas they are spawned when + logging off ? + they are? that's fascinating indeed ;-) + does it behave like this on your old version ? + I don't remember ever having seen a "getty" process on my Hurd + systems... + can you log on e.g. tty2 and then log out, and see ? + OTOH, I'm hardly ever using consoles... + hm... I think that should be possible remotely using the console + client with ncurses driver? never tried that... + ncurses driver ? + hum i don't know, never tried either + and it may add other bugs :p + better wait to be close to the machine + hehe + well, it's a good excuse for trying the ncurses driver ;-) + hrm + alien:~# console -d ncursesw + console: loading driver `ncursesw' failed: Gratuitous error + I guess nobody tested that stuff in years -- cgit v1.2.3