On Fri, Sep 11, 2015 at 11:39:01AM +0100, Jon Hunter wrote: > Hi Kevin, > > On 10/09/15 22:29, Kevin Hilman wrote: > > [snip] > > > Since there is no movement on this, and jetson hasn't been boot for > > multi_v7_defconfig for a while[1], I think it's time to undo the > > option causing this problem[2] so that v4.3 will actually boot on the > > jetson. > > > > Unless I hear a good reason otherwise, I'll be posting a patch to > > disable the HDA related options in multi_v7_defconfig. > > So curiosity got the better of this cat, as to why we are not seeing > this ;-) > > The main difference I see between the tegra_defconfig and > multi_v7_defconfig is all the sound drivers are modules (including > this one). > > So trying a quick modprobe of the hda-tegra driver I do see it hang ... > > / # modprobe snd-hda-tegra > [ 625.213864] snd_hda_tegra: Unknown symbol azx_probe_codecs (err 0) > [ 625.220215] snd_hda_tegra: Unknown symbol azx_init_streams (err 0) > [ 625.226480] snd_hda_tegra: Unknown symbol azx_stop_all_streams (err 0) > [ 625.233168] snd_hda_tegra: Unknown symbol azx_bus_init (err 0) > [ 625.239062] snd_hda_tegra: Unknown symbol azx_free_streams (err 0) > [ 625.245314] snd_hda_tegra: Unknown symbol azx_init_chip (err 0) > [ 625.251321] snd_hda_tegra: Unknown symbol snd_hda_set_power_save (err 0) > [ 625.258081] snd_hda_tegra: Unknown symbol azx_stop_chip (err 0) > [ 625.264078] snd_hda_tegra: Unknown symbol azx_codec_configure (err 0) > [ 625.270607] snd_hda_tegra: Unknown symbol azx_interrupt (err 0) > [ 840.117528] INFO: task modprobe:137 blocked for more than 120 seconds. > [ 840.124192] Not tainted 4.2.0-next-20150909-40826-gb799053 #1 > [ 840.130584] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 840.138540] modprobe D c09ac3a4 0 137 82 0x00000000 > [ 840.145123] [<c09ac3a4>] (__schedule) from [<c09ac838>] (schedule+0x34/0x98) > [ 840.152310] [<c09ac838>] (schedule) from [<c09acaac>] (schedule_preempt_disabled+0xc/0x10) > [ 840.160734] [<c09acaac>] (schedule_preempt_disabled) from [<c09adeec>] (__mutex_lock_slowpath+0x9c/0x150) > [ 840.170458] [<c09adeec>] (__mutex_lock_slowpath) from [<c09adfec>] (mutex_lock+0x4c/0x50) > [ 840.178807] [<c09adfec>] (mutex_lock) from [<c062999c>] (__driver_attach+0x44/0x90) > [ 840.186627] [<c062999c>] (__driver_attach) from [<c0627fcc>] (bus_for_each_dev+0x54/0x88) > [ 840.194966] [<c0627fcc>] (bus_for_each_dev) from [<c0628f88>] (bus_add_driver+0xe4/0x1f0) > [ 840.203305] [<c0628f88>] (bus_add_driver) from [<c062a1d0>] (driver_register+0x78/0xf4) > [ 840.211475] [<c062a1d0>] (driver_register) from [<c020ac04>] (do_one_initcall+0x80/0x1d0) > [ 840.219818] [<c020ac04>] (do_one_initcall) from [<c02c8abc>] (do_init_module+0x58/0x354) > [ 840.228081] [<c02c8abc>] (do_init_module) from [<c02afae8>] (load_module+0x17e0/0x1d8c) > [ 840.236258] [<c02afae8>] (load_module) from [<c02b016c>] (SyS_init_module+0xd8/0x138) > [ 840.244260] [<c02b016c>] (SyS_init_module) from [<c0210b00>] (ret_fast_syscall+0x0/0x3c) > > Adding some debug it appears to hang on snd-hda-codec-hdmi (the following show > the order in which modules are being loaded) ... > > / # modprobe snd-hda-tegra > [ 22.450276] snd_hda_tegra: err = -2 > [ 22.484535] soundcore: err = 0 > [ 22.488964] snd: err = 0 > [ 22.493242] snd_timer: err = 0 > [ 22.498380] snd_pcm: err = 0 > [ 22.502479] snd_hda_core: err = 0 > [ 22.508337] snd_hda_codec: err = 0 > [ 22.513386] snd_hda_tegra: err = 0 > [ 22.740216] snd_hda_codec_hdmi: err = 0 > > [hangs here] > > However, if I do the following, this works ... > > / # modprobe snd-hda-codec-hdmi > / # modprobe snd-hda-tegra > > So it implies that snd-hda-codec-hdmi needs to be loaded first otherwise it hangs. > > Thierry, any thoughts? I can't reproduce this. Booting multi_v7_defconfig on my setup works just fine. I don't ever see snd-hda-codec-hdmi being probed, but then probing it manually works fine. No hangs. What I do see is that after a little while network stops working. I noticed primarily because I boot with an NFS root, so the kernel started complaining about the NFS server not responding. Being on an NFS root could be one reason why this works for me, not sure what the kernelci labs are running. I don't see the network issues with tegra_defconfig. I've also tried a tegra_defconfig with all of sound support built as modules and that all works perfectly. I'll investigate the multi_v7_defconfig network issues, perhaps that'll give me some clues, or perhaps even allow me to reproduce the original issue. Thierry
Attachment:
signature.asc
Description: PGP signature
