[Qemu-devel] Re: [SOLUTION] "i8042.c: No controller found" -> OS sees no keyboard if I type "in BIOS"

[Dinesh Subhraveti]

Marcelo Tosatti <mtosatti <at> redhat.com> writes:

> 
> On Wed, May 20, 2009 at 03:30:09PM +0200, Tomasz Chmielewski wrote:
> > Tomasz Chmielewski schrieb:
> >
> >>> When I boot the guest and type (just hit any keys) in the VNC window  
> >>> before the operating system boots, sometimes, the system loads with 
> >>> no keyboard present - as signified in dmesg on guest:
> >>>
> >>> i8042.c: No controller found
> >>>
> >>> As a result, I can't use the keyboard in the VNC window.
> >
> >> drivers/input/serio/i8042.c in the Linux kerne has this:
> >>
> >> static int i8042_controller_check(void)
> >> {
> >>         if (i8042_flush() == I8042_BUFFER_SIZE) {
> >>                 printk(KERN_ERR "i8042.c: No controller found.\n");
> >>                 return -ENODEV;
> >>         }
> >>
> >>         return 0;
> >> }
> >>
> >>
> >> So, can it be that if we type anything on keyboard (or move mouse) 
> >> while Qemu's BIOS is still booting or later in the bootloader (GRUB, 
> >> lilo), some buffer is not flushed and Linux gets confused? And as a 
> >> result, decides there is no keyboard?
> >
> > Yes, this is what seems to happen - Qemu's keyboard buffer seems to be 
infinite
> > or at least very big; normal 8042 devices have buffer of 16 bytes only.
> >
> > If we add "i8042.debug" parameter to kernel command line,
> > we will see how many characters were flushed during boot, i.e.:
> >
> >
> > drivers/input/serio/i8042.c: ff <- i8042 (flush, aux) [0]
> > drivers/input/serio/i8042.c: 18 <- i8042 (flush, aux) [0]
> > drivers/input/serio/i8042.c: 92 <- i8042 (flush, aux) [0]
> > drivers/input/serio/i8042.c: 00 <- i8042 (flush, aux) [0]
> > (...)
> >
> >
> > With this 16 byte buffer in drivers/input/serio/i8042.h (before 2.6.11 it 
was
> > 32 bytes I think):
> >
> > #define I8042_BUFFER_SIZE       16
> >
> >
> > and this piece of code in drivers/input/serio/i8042.c:
> >
> >
> > /*
> > * i8042_flush() flushes all data that may be in the keyboard and mouse 
buffers
> > * of the i8042 down the toilet.
> > */
> >
> > static int i8042_flush(void)
> > {
> >        unsigned long flags;
> >        unsigned char data, str;
> >        int i = 0;
> >
> >        spin_lock_irqsave(&i8042_lock, flags);
> >
> >        while (((str = i8042_read_status()) & I8042_STR_OBF) && (i < 
I8042_BUFFER_SIZE)) {
> >                udelay(50);
> >                data = i8042_read_data();
> >                i++;
> >                dbg("%02x <- i8042 (flush, %s)", data,
> >                        str & I8042_STR_AUXDATA ? "aux" : "kbd");
> >        }
> >
> >        spin_unlock_irqrestore(&i8042_lock, flags);
> >
> >        return i;
> > }
> >
> >
> >
> > Linux kernel thinks there is no controller:
> >
> >
> > (...)
> > drivers/input/serio/i8042.c: 28 <- i8042 (flush, aux) [0]
> > drivers/input/serio/i8042.c: 00 <- i8042 (flush, aux) [0]
> > i8042.c: No controller found.
> >
> >
> > If we increase "I8042_BUFFER_SIZE" to 256 or more, we have a much better 
> > chance that a booted Linux will have a keyboard present.
> >
> > So, who's to be blamed?
> >
> > Linux kernel for having its i8042 buffer to small (16 bytes), fixable with:
> >
> >
> > --- i8042.h.orig        2009-05-20 15:26:32.000000000 +0200
> > +++ i8042.h     2009-05-20 15:26:32.000000000 +0200
> > @@ -73,7 +73,7 @@
> >  * the i8042 buffers.
> >  */
> >
> > -#define I8042_BUFFER_SIZE      16
> > +#define I8042_BUFFER_SIZE      256
> >
> > /*
> >  * Number of AUX ports on controllers supporting active multiplexing
> >
> >
> >
> > Or Qemu, for having its keyboard buffer too large (I'm not sure, but 
probably 256 bytes)?
> 
> All references (*) i could find mention 16 bytes of output buffer
> (including the Linux source as you mentioned, which was reduced from 32
> to 16 somewhere in the 2.6.10 era).
> 
> http://www.computer-engineering.org/ps2protocol/
> 
> http://linux.bkbits.net:8080/linux-2.6.28-stable/drivers/input/serio/i8042.h?
PAGE=diffs&REV=4203735dp_doSExYU6ido8KnczbjzQ
> 
> Reducing PS2_QUEUE_SIZE to 16 also makes the Linux detection loop happy.
> 
> If QEMU claims to emulate i8042, it should be similar to real hardware.
> 

Some new findings on this old issue:

Reducing PS2_QUEUE_SIZE to 16 prevents the PS2 mouse event handler 
(ps2_mouse_event()) from queuing any mouse events.  It checks if there is at 
least 16 bytes of space left in the queue, if not, the event is dropped.

The side effect of this is that, the buffer will not become full, and 
i8042_controller_check() in guest Linux is happy and keyboard works normally 
after reboot.  However, mouse remains inactive throughout, because its events 
are always dropped.

Two questions:

- Does it make sense to reduce the size of reserved space (currently 16 bytes) 
checked by ps2_mouse_event()?  It will probably break other things since the 
reserved space is tied to the length of mouse movement.  If the distance moved 
can fit in 1 byte (+/- 128), it is queued as 1 event.  For longer distances, 
it is queued as multiple events requiring more buffer space.  16 bytes is 
probably a conservative estimate of the longest distance moved.

- Why does the guest kernel (i8042_controller_check()) conclude that there is 
no i8042 controller if it finds the queue to be full?  Reducing PS2_QUEUE_SIZE 
to 16 is still not enough.  It need to be something less than 16 for the 
guest kernel to successfully detect the controller.

Interesetingly, the problem is not seen on RHEL 5.3.  It leaves the mouse 
disabled on shutdown via AUX_DISABLE_DEV mouse command.  AUX_DISABLE_DEV 
command resets MOUSE_STATUS_ENABLED flag in PS2MouseState->mouse_status, which 
makes mouse 
events to be dropped by ps2_mouse_event().

On SLES 11, however, mouse is disabled first but then it is again re-enabled 
(via AUX_ENABLE_DEV) prior to resetting the processor, leaving the mouse 
enabled during BIOS.  Not clear what makes the guest re-enable the mouse on 
shutdown.

Folks have some clues on the right way to address this?

Dinesh Subhraveti