[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
Hi,
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); \
} \
EXPORT_SYMBOL(name)
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.
Regards,
Hans
More information about the vbox-dev
mailing list