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

Stanislav Vorobiov s.vorobiov at samsung.com
Thu Apr 24 12:47:14 GMT 2014


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
>>>
>>>>>
>>>
>>>>
>>>
>>>>
>>>
>>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-intel-hda-FIFO_READY-dirty-fix.patch
Type: text/x-patch
Size: 1072 bytes
Desc: not available
URL: <http://lists.tizen.org/pipermail/dev/attachments/20140424/2b0108ec/attachment.patch>


More information about the Dev mailing list