On Fri, Mar 25, 2011 at 13:29, Joost Roeleveld <joost@xxxxxxxxxxxx> wrote:
>
> 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.
>
Possibly so. emerge managed to pull the source, but failed during
make, complaining of some 'undefined symbol' or such.
> > 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?
>
I tried to revert but the VM becomes wacky, so I re-revert the
hardened VM to the latest, and am now creating a new VM to test the
xen-sources.
> --
> Joost
--
Pandu E Poluan
~ IT Optimizer ~
Visit my Blog: http://pepoluan.posterous.com
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home