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:[email protected]] Sent: Thursday, April 24, 2014 9:47 PM To: SeokYeon Hwang; [email protected]; 'Ji, John'; [email protected] 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:[email protected]] Sent:Friday, >>> April 18, 2014 4:07 PM To:SeokYeon Hwang; [email protected]; 'Ji, >>> John'; [email protected] >>> 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:[email protected]] >>> >>>> Sent: Friday, April 18, 2014 2:59 PM >>> >>>> To: SeokYeon Hwang;[email protected]<mailto:[email protected]>; >>>> 'Ji, John'; >>> >>>> [email protected]<mailto:[email protected]> >>> >>>> 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 >>> >>>>> [email protected]<mailto:[email protected]> >>> >>>>> https://lists.tizen.org/listinfo/dev >>> >>>>> >>> >>>> >>> >>>> >>> >> > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
