[vbox-dev] New virtualbox vboxvideo mainline kernel broken in Ubuntu

Hans de Goede hdegoede at redhat.com
Thu Oct 12 12:44:22 UTC 2017


On 12-10-17 11:17, Michael Thayer wrote:
> Hello Both,
> 11.10.2017 17:41, Hans de Goede wrote:
>> Hi,
>> On 11-10-17 07:26, Michael Thayer wrote:
>>> Hello Gianfranco,
>>> 02.10.2017 12:11, Gianfranco Costamagna wrote:
>>>>> Thanks for the heads-up.  I am gradually adjusting our in-tree code to
>>>>> match vboxvideo in staging, so at some point, when things stop turning
>>>>> up to stop me, I will probably hit the crucial difference.  Gianfranco,
>>>>> if you have time could you please give the Additions from the next beta
>>>>> release a try, when it is available, since I have already started the
>>>>> process?  I would be very grateful if you could.  I will too of course
>>>>> when I find a moment, moments are just in short supply.
>>>> RC1 is now broken too
>>> I haven't taken a look at the in-kernel version, but in RC1 the reason
>>> was that the arguments to out*() calls got swapped: the Linux kernel
>>> reverses them compared to everyone else I know of, and I failed to do
>>> that during clean-up to match kernel style.  Will be committing soon.
>> Ok, so I double checked and this is not the same problem as people using
>> the driver from the upstream kernel's driver/staging are seeing, the
>> outl/w/b operands there are all in the right order.
> That does not surprise me greatly.  The question is who if anyone will
> instrument the staging version with printk commands to see what is going
> wrong.  Hans, if you can answer without wasting time researching, can
> you think of a simple way to send printk output straight to the
> VirtualBox debug I/O port?  That could be simpler than setting up a
> virtual serial port.  (I wonder how much work it would be to send
> virtual serial port output straight to the log file...)  I do not
> immediately plan to do the instrumentation - it is lower priority for me
> than getting our code in a state to be submitted to the kernel, and that
> is already going slowly enough.

Adding this code from the vboxguest driver I'm upstreaming:

To some .h file:

  * vboxguest logging functions, these log both to the backdoor and call
  * the equivalent kernel pr_foo function.
__printf(1, 2) void vbg_info(const char *fmt, ...);
__printf(1, 2) void vbg_warn(const char *fmt, ...);
__printf(1, 2) void vbg_err(const char *fmt, ...);

To a .c file:

#define VBG_LOG(name, pr_func) \
void name(const char *fmt, ...)                                         \
{                                                                       \
         unsigned long flags;                                            \
         va_list args;                                                   \
         int i, count;                                                   \
         va_start(args, fmt);                                            \
         spin_lock_irqsave(&vbg_log_lock, flags);                        \
         count = vscnprintf(vbg_log_buf, sizeof(vbg_log_buf), fmt, args);\
         for (i = 0; i < count; i++)                                     \
                 outb(vbg_log_buf[i], VBG_DEBUG_PORT);                   \
         pr_func("%s", vbg_log_buf);                                     \
         spin_unlock_irqrestore(&vbg_log_lock, flags);                   \
         va_end(args);                                                   \
}                                                                       \

VBG_LOG(vbg_info, pr_info);
VBG_LOG(vbg_warn, pr_warn);
VBG_LOG(vbg_err, pr_err);

And then calling vbg_info / whatever to log should do the trick.

But I've just managed to reproduce this using F27 / gnome-shell 3.26,
so I'm looking into a fix now.



More information about the vbox-dev mailing list