[Dev] [SDK/Emulator] Emulator kernel upgrade is postponed and other issues...

SeokYeon Hwang syeon.hwang at samsung.com
Fri Apr 25 08:43:47 GMT 2014


Thank you for your explanation.

If your patch works well, we can continue testing new kernel.
I would apply new kernel 5 May, if there are no critical issues until next
weekend.

On other track, we should start testing QEMU 2.0 based emulator.
I think it can be merged to tizen branch 5 May, too.

Thanks.


-----Original Message-----
From: Stanislav Vorobiov [mailto:s.vorobiov at samsung.com] 
Sent: Thursday, April 24, 2014 10:21 PM
To: SeokYeon Hwang; dev at lists.tizen.org; 'Ji, John'; ritu.sood at intel.com
Subject: Re: [Dev] [SDK/Emulator] Emulator kernel upgrade is postponed and
other issues...

Hi, SeokYeon

Regarding VT disabled on windows - m.b. because hardware vmexits are much
more expensive than software vmexits (i.e. TCG), in case of TCG these 5000 *
4 (or how many pcm streams are there...) are just function calls, but it
makes all the difference with VT

Regarding linux/KVM - that puzzles me too, but my guess is that now KVM
vmexits are more optimized than HAXMs. e.g.
I know for sure that HAXM synchronizes all CPU state each mmio vmexit unlike
KVM which does this only on demand. But I'm not an expert in HAXM, it may be
other reasons...

On 04/24/2014 05:06 PM, SeokYeon Hwang wrote:
> Hi, stanislav.
> 
> It works for me. :)
> 
> I have a question about this. 
> (sorry, I'm not study about your patch yet.) Why is it works normally 
> on the Linux and the VT disabled Windows ??
> 
> 
> 
> -----Original Message-----
> From: Stanislav Vorobiov [mailto:s.vorobiov at samsung.com]
> Sent: Thursday, April 24, 2014 9:47 PM
> To: SeokYeon Hwang; dev at lists.tizen.org; 'Ji, John'; 
> ritu.sood at intel.com
> Subject: Re: [Dev] [SDK/Emulator] Emulator kernel upgrade is postponed 
> and other issues...
> 
> Hi,
> 
> So the problem was introduced with this commit in kernel:
> 
> 172d3b209622785ce7c4f4104319df06d9814b62 ALSA: hda - force use of 
> SSYNC bits
> 
> The loop at hda_intel.c:2297:
> 
> if (start) {
>     /* wait until all FIFOs get ready */
>     ...
> }
> 
> Was never executed before because it had this in it:
> 
> if (nsync == 1) { return 0; }
> 
> This commit removed it, thus, intel-hda now always uses FIFO_READY 
> bit, but it's not implemented on QEMU side.
> 
> I'm attaching dirty fix first, please check that it helps, I'll then 
> implement FIFO_READY support in QEMU's intel-hda, it'll have to be 
> sent upstream too I guess...
> 
> On 04/24/2014 01:34 PM, Stanislav Vorobiov wrote:
>> Hi,
>>
>> Ok, so guest kernel debugging shows this on hang:
>>
>> (gdb) target remote :1234
>> Remote debugging using :1234
>> azx_pcm_trigger (substream=0xc0014600, cmd=1) at
> sound/pci/hda/hda_intel.c:2297
>> 2297    sound/pci/hda/hda_intel.c: No such file or directory.
>> (gdb) bt
>> #0  azx_pcm_trigger (substream=0xc0014600, cmd=1) at
>> sound/pci/hda/hda_intel.c:2297
>> #1  0xc143f0a9 in snd_pcm_do_start (substream=<optimized out>, 
>> state=<optimized out>) at sound/core/pcm_native.c:866
>> #2  0xc143f016 in snd_pcm_action_single (ops=0xc18c6848
> <snd_pcm_action_start>, substream=0xc0014600, state=3)
>>     at sound/core/pcm_native.c:774
>> #3  0xc14406f5 in snd_pcm_action_lock_irq (ops=0xc18c6848
> <snd_pcm_action_start>, substream=0xc0014600, state=3)
>>     at sound/core/pcm_native.c:823
>> #4  0xc1441730 in snd_pcm_common_ioctl1 (file=0xdd359640,
> substream=0xc0014600, cmd=<optimized out>, arg=0xb1f17218)
>>     at sound/core/pcm_native.c:2576
>> #5  0xc144263b in snd_pcm_playback_ioctl1 (file=<optimized out>,
> substream=0xc0014600, cmd=<optimized out>, arg=0xb1f17218)
>>     at sound/core/pcm_native.c:2691
>> #6  0xc1442668 in snd_pcm_playback_ioctl (file=<optimized out>,
> cmd=<optimized out>, arg=<optimized out>)
>>     at sound/core/pcm_native.c:2784
>> #7  0xc10d2587 in vfs_ioctl (arg=2985390616, cmd=<optimized out>,
>> filp=0xdd359640) at fs/ioctl.c:43
>> #8  do_vfs_ioctl (filp=0xdd359640, fd=<optimized out>, cmd=<optimized
>> out>, arg=2985390616) at fs/ioctl.c:598
>> #9  0xc10d2604 in SYSC_ioctl (arg=2985390616, cmd=16706, fd=29) at
>> fs/ioctl.c:613
>> #10 SyS_ioctl (fd=29, cmd=16706, arg=-1309576680) at fs/ioctl.c:604
>>
>> and hda_intel.c:2297 is:
>>
>> 	if (start) {
>> 		/* wait until all FIFOs get ready */
>> 		for (timeout = 5000; timeout; timeout--) {
>> 			nwait = 0;
>> 			snd_pcm_group_for_each_entry(s, substream) {
>> 				if (s->pcm->card != substream->pcm->card)
>> 					continue;
>> 				azx_dev = get_azx_dev(s);
>> 				if (!(azx_sd_readb(azx_dev, SD_STS) &
>> 				      SD_STS_FIFO_READY))
>> 					nwait++;
>> 			}
>> 			if (!nwait)
>> 				break;
>> 			cpu_relax();
>> 		}
>> 	} else {
>>
>> the problematic part is:
>>
>> if (!(azx_sd_readb(azx_dev, SD_STS) &
>> SD_STS_FIFO_READY))
>>
>> So I guess this is indeed related to audio, I hope to provide fix soon...
>>
>> On 04/23/2014 03:26 PM, Stanislav Vorobiov wrote:
>>> Hi, SeokYeon
>>>
>>> I think I found the cause of this problem, try removing "-soundhw all"
> from your qemu command line, it should work.
>>> It turned out I had it removed all along, but when I put it back I 
>>> get a
> kernel hang.
>>>
>>> There must be some problems handling sound with new kernel, I'll try 
>>> to
> find out what they are...
>>>
>>> On 04/23/2014 06:12 AM, SeokYeon Hwang wrote:
>>>> Sorry for my late reply.
>>>>
>>>> A mail server was malfunction till yesterday.
>>>>
>>>> Thekernel load time I meantwas"afterkernel loading->before init start"
> time.
>>>>
>>>> [    0.000000] Initializing cgroup subsys cpuset[    0.000000]
> Initializing cgroup subsys cpu...
>>>>
>>>> ...
>>>>
>>>> ...
>>>>
>>>> Image mount[   12.729651] kjournald starting.  Commit interval 5
> seconds[   12.731320] EXT3-fs (vda): using internal journal[   12.732636]
> EXT3-fs (vda): recovery complete[   12.733517] EXT3-fs (vda): mounted
> filesystem with writeback data mode***[
>>>> 12.734886]*mount used greatest stack depth: 6132 bytes leftcreate 
>>>> device filesystemSwitching root
>>>>
>>>> I meant"12.734886"seconds.
>>>>
>>>> Itmightbenot related with 3.12 kernel hang-up issue.
>>>>
>>>> But I'mcuriouswhy"HAX enabled"is much slowerthan"HAX disabled".
>>>>
>>>> Back to the hang-up issue, it is notpermanenthang-up.
>>>>
>>>> It proceedsafter 5 minutes ~ 15 minutes.
>>>>
>>>> But kernel time is passingonlyfew milliseconds.
>>>>
>>>> It might bea potential critical problemwhateverkernel version is, 
>>>> so I
> hope to figure out cause of this, ASAP.
>>>>
>>>> Thanks.
>>>>
>>>> -----Original Message-----
>>>> From:Stanislav Vorobiov [mailto:s.vorobiov at samsung.com] 
>>>> Sent:Friday, April 18, 2014 4:07 PM To:SeokYeon Hwang; 
>>>> dev at lists.tizen.org; 'Ji, John'; ritu.sood at intel.com
>>>> Subject:Re: [Dev] [SDK/Emulator] Emulator kernel upgrade is 
>>>> postponed
> and other issues...
>>>>
>>>> Hi,
>>>>
>>>>> How long kernel load time (after kernel loading -> before "init" 
>>>>
>>>>> starts) at your Windows PC with HAX enabled and HAX disabled ??
>>>>
>>>> How do you measure the time between kernel loading and init start ? 
>>>> Do
> you modify guest filesystem somehow ?
>>>>
>>>> I've measured time from emulator startup to UI, it's 20-22secs with 
>>>> HAX and about 2m 20secs without HAX
>>>>
>>>> On 04/18/2014 10:41 AM, SeokYeon Hwang wrote:
>>>>
>>>>> Yes, It can reproduce even with g_poll patch.
>>>>
>>>>> We can reproduce it on most of Windows PCs. It may be timing 
>>>>> issues
>>>>
>>>>> depend on PC's performance, ...
>>>>
>>>>>
>>>>
>>>>> How long kernel load time (after kernel loading -> before "init" 
>>>>
>>>>> starts) at your Windows PC with HAX enabled and HAX disabled ??
>>>>
>>>>>
>>>>
>>>>> -----Original Message-----
>>>>
>>>>> From: Stanislav Vorobiov [mailto:s.vorobiov at samsung.com]
>>>>
>>>>> Sent: Friday, April 18, 2014 2:59 PM
>>>>
>>>>> To: SeokYeon 
>>>>> Hwang;dev at lists.tizen.org<mailto:dev at lists.tizen.org>;
>>>>> 'Ji, John';
>>>>
>>>>> ritu.sood at intel.com<mailto:ritu.sood at intel.com>
>>>>
>>>>> Subject: Re: [Dev] [SDK/Emulator] Emulator kernel upgrade is 
>>>>> postponed
>>>>
>>>>> and other issues...
>>>>
>>>>>
>>>>
>>>>> Hi, SeokYeon
>>>>
>>>>>
>>>>
>>>>> This happens even withhttps://review.tizen.org/gerrit/#/c/19414/right
?
>>>>
>>>>>
>>>>
>>>>> Before that patch kernel 3.12 didn't boot at all, but now it boots
>>>>
>>>>> every time (fast) and I can't reproduce this hang...
>>>>
>>>>>
>>>>
>>>>> Also, regarding boot delays with HAX, I do experience them on mac 
>>>>> os
>>>>
>>>>> x, I'm not sure if it's related though...
>>>>
>>>>>
>>>>
>>>>> On 04/18/2014 08:11 AM, SeokYeon Hwang wrote:
>>>>
>>>>>> I'll postpone to apply 3.12 linux kernel to tizen because of a 
>>>>>> big
>>>>
>>>>> problem.
>>>>
>>>>>>
>>>>
>>>>>> The problem is that the hang happens for a certain period of time
>>>>
>>>>>> (several
>>>>
>>>>> minutes) when booting in many Windows PC.
>>>>
>>>>>>
>>>>
>>>>>> Until resolving the problem, I'll postpone it.
>>>>
>>>>>>
>>>>
>>>>>>  
>>>>
>>>>>>
>>>>
>>>>>> We need a help to resolve it, especially from HAX developers. 
>>>>
>>>>>>
>>>>
>>>>>> Because it happens when running with turned on VT acceleration 
>>>>>> with
> HAX.
>>>>
>>>>>>
>>>>
>>>>>> The other fact is that guest kernel time is stopped.
>>>>
>>>>>>
>>>>
>>>>>> Please treat this with a higher priority.
>>>>
>>>>>>
>>>>
>>>>>> The HAX may not be the cause of the problem. However, it will be 
>>>>>> very
>>>>
>>>>> helpful if HAX developers help me.
>>>>
>>>>>>
>>>>
>>>>>>  
>>>>
>>>>>>
>>>>
>>>>>> Also, I have a question about HAX.
>>>>
>>>>>>
>>>>
>>>>>> Why does the running with disabled HAX be the faster than the 
>>>>>> running
>>>>
>>>>>> with
>>>>
>>>>> enabled HAX for the time (loading kernel -> starting init) in Windows?
>>>>
>>>>>>
>>>>
>>>>>> It can affect the overall performance in Windows, so please check
>>>>
>>>>>> this
>>>>
>>>>> performance issue.
>>>>
>>>>>>
>>>>
>>>>>>  
>>>>
>>>>>>
>>>>
>>>>>> Thanks.
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>>
>>>>
>>>>>> _______________________________________________
>>>>
>>>>>> Dev mailing list
>>>>
>>>>>> Dev at lists.tizen.org<mailto:Dev at lists.tizen.org>
>>>>
>>>>>> https://lists.tizen.org/listinfo/dev
>>>>
>>>>>>
>>>>
>>>>>
>>>>
>>>>>
>>>>
>>>
>>
> 
> 
> 



More information about the Dev mailing list