On Friday 25 March 2011 11:39:21 Pandu Poluan wrote:
> On Fri, Mar 25, 2011 at 11:08, Melody Bliss <melodybliss@xxxxxxxxx> wrote:
> > On Thu, Mar 24, 2011 at 8:54 PM, Pandu Poluan <pandu@xxxxxxxxxxx> wrote:
> >> On Fri, Mar 25, 2011 at 10:50, Melody Bliss <melodybliss@xxxxxxxxx>
wrote:
> >>> Hrm. Interesting.
> >>>
> >>> I believe hvc0 is your console on this VM and it looks like a getty
> >>> is running.
> >>>
> >>> Have you tried killing the agetty on hvc0 (process 4143). It should
> >>> respawn. If it doesn't, send a -HUP signal to init. That should
> >>> force
> >>> init to re-read /etc/inittab and respawn missing processes.
> >>
> >> No joy.
> >
> > hrm
> >
> >> The console indeed shows agetty restarting by emitting a new set of
> >> lines "This is bla bla bla ... login:"
> >>
> >> But still no keyboard input.
> >>
> >>> You may need to trace the getty process and see what it's doing at
> >>> the time.
> >>
> >> Uhh... trace? You went over my head there... :-P
> >
> > You can use strace (if it's installed) to see what a running process
> > is doing. An example on my subversion server.
> >
> > (via ssh to svn)
> >
> > --- 8< cut >8 ---
> > [root@svn ~]# ps auxww | grep getty
> > root 27371 0.0 0.1 3804 544 xvc0 Ss+ 04:08 0:00
> > /sbin/agetty xvc0 9600 vt100-nav
> > root 27409 0.0 0.1 61156 716 pts/0 R+ 04:14 0:00 grep
> > getty [root@svn ~]# strace -p 27371
> > Process 27371 attached - interrupt to quit
> > read(0, "\r", 1) = 1
> > uname({sys="Linux", node="svn.home.chezbliss.com", ...}) = 0
> > write(1, "\r\n", 2) = 2
> > open("/etc/issue", O_RDONLY) = 3
> > ...
> > ...
> > uname({sys="Linux", node="svn.home.chezbliss.com", ...}) = 0
> > write(1, "svn.home.chezbliss.com", 22) = 22
> > write(1, " login: ", 8) = 8
> > --- 8< cut >8 ---
> >
> > The above was generated when I hit the enter key on the console
> >
> > --- 8< cut >8 ---
> > [root@shark ~]# xm console svn
> >
> > CentOS release 5.5 (Final)
> > Kernel 2.6.18-194.26.1.el5xen on an x86_64
> >
> > svn.home.chezbliss.com login:
> > --- 8< cut >8 ---
> >
> > This way, you can see exactly what the getty process is doing (or not
> > doing). From the sounds of it, it sounds like the device driver may
> > have a bug in it where it isn't correctly attaching to the input
> > stream. Unfortunately I don't know enough about the Xen console driver
> > internals to be able to point you to a solution to the problem, but
> > using strace may give some idea of where to start.
>
> The bad news is 'emerge strace' failed horribly on my system :(
"strace" is in portage, so it should work. Not sure why it failed on your
system. It may be related to the hardened profile you are running.
> I just tried 'emerge mingetty' and replace the hvc0 agetty with
> mingetty. Although mingetty managed to capture hvc0, still the same
> 'keyboard not responsive' problem.
>
> I strongly suspect a kernel misconfig on my part, though. dmesg does
> not indicate anything related to keyboard, while it indicates mice
> being found.
>
> I'll try mucking up the kernel config
Did you manage to test with the xen-sources to see if that has any effect?
--
Joost
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home