qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s


From: Jan Kiszka
Subject: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s
Date: Mon, 03 Nov 2008 22:50:54 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Jan Kiszka wrote:
> Anthony Liguori wrote:
>> Jan Kiszka wrote:
>>> Anthony Liguori wrote:
>>>  
>>>> If anyone notices a slow down, I'd check this revision.  There may be
>>>> broken bits of code out there that depends on wake up rate.  I've done a
>>>> fair bit of testing and haven't found any but you never know.
>>>>     
>>> OK, here is one brokenness for you: Musicpal (qemu-arm-system) becomes
>>> unusable, sounds is stopping for seconds, even keyboard input is
>>> inpossible, including switching to the monitor console. What should I
>>> check for? Note that this board uses a ptimer to a PIT to the guest. May
>>> this make a difference here?
>>>   

I think I understood the problem:

[...]
timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0
timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xca8d90)                  = 0
select(24, [0 5 6 8 23], [], [], {0, 0}) = 0 (Timeout)
ioctl(20, 0x4122, 0xbb)                 = 0
ioctl(20, 0x4122, 0x54)                 = 0
ioctl(20, 0x4122, 0x3)                  = 0
ioctl(20, 0x4122, 0)                    = 0
ioctl(20, 0x4122, 0xac)                 = 0
ioctl(20, 0x4122, 0)                    = 0
ioctl(20, 0x4122, 0x400)                = 0
ioctl(21, USBDEVFS_IOCTL, 0xd64080)     = 0
ioctl(20, 0x4122, 0xc000000000020400)   = 0
semop(34242562, 0x7fff65de5960, 2)      = 0
semop(34242562, 0x7fff65de5970, 1)      = 0
read(19, 
"\1\0\0\0\0\201\377\377\321Z\2\0\0\0\0\0\'PO&\0\0\0\0\1\0\0\0\377\377\377\377", 
128) = 32
timer_gettime(0, {it_interval={0, 0}, it_value={0, 0}}) = 0
timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xca8d90)                  = 1
select(24, [0 5 6 8 23], [], [], {5, 0}^C <unfinished ...>


There is a race between the alarm_timer firing SIGALRM and
main_loop_wait reaching the safe harbor of select (with that infamous 5
second timeout). If the signal comes when already blocked in select, it
will properly resume the latter immediately. But if the timer fired
BEFORE that point, host_alarm_handler will only set a flag that the host
timer has fired, the actual rearming will be done AFTER return from
select. Ooops....

So, select should actually include the host timer as event. timerfd?
Unfortunately a recent Linux-only feature :-/. I don't think we can
rearm the timer from within the signal handler, at least not without
running all the pending qemu timers. And that is surely not a signal
handler job (qemu timer handler aren't thread-safe in general).

Anyone any ideas? /me is thinking a bit more about it as well.

Jan

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]