On Tue, Aug 18, 2015 at 03:30:41PM -0700, Tyler Baker wrote: > Hi Theirry, > > On 14 August 2015 at 07:48, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > > Hi ARM SoC maintainers, > > > > The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754: > > > > Linux 4.2-rc1 (2015-07-05 11:01:52 -0700) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git tags/tegra-for-4.3-defconfig > > > > for you to fetch changes up to 258d9bc5e77fa40e290a0bd480d5349224374480: > > > > ARM: tegra: Update multi_v7_defconfig (2015-08-14 16:26:00 +0200) > > > > Thanks, > > Thierry > > > > ---------------------------------------------------------------- > > ARM: tegra: Default configuration updates for v4.3-rc1 > > > > Enable the GK20A GPU (via the Nouveau driver) and CPU frequency scaling > > on Tegra124. > > > > ---------------------------------------------------------------- > > Thierry Reding (1): > > ARM: tegra: Update multi_v7_defconfig > > The kernelci.org bot recently reported jetson-tk1 boot failures[1][2] > in next-20150818, only when booting the mult_v7_defconfig kernels. I > bisected[3] these boot failure down to this commit, it didn't cleanly > revert, so I manually removed that options this patch added, and my > jetson-tk1 booted again. Digging a bit further, if I apply the patch > below to next-20150818, my jetson-tk1 boots. I'm not able to reproduce this here. Building next-20150818 with multi_v7_config and booting the resulting kernel works just fine. > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig > index b2facab..a285afe 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -468,7 +468,6 @@ CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y > CONFIG_SOUND=m > CONFIG_SND=m > CONFIG_SND_DYNAMIC_MINORS=y > -CONFIG_SND_HDA_TEGRA=m > CONFIG_SND_HDA_INPUT_BEEP=y > CONFIG_SND_HDA_PATCH_LOADER=y > CONFIG_SND_HDA_CODEC_REALTEK=m lsmod output confirms that snd-hda-tegra.ko was loaded: # lsmod Module Size Used by snd_soc_tegra30_i2s 5591 2 snd_soc_tegra_pcm 1184 1 snd_soc_tegra30_i2s snd_hda_tegra 4771 0 snd_soc_rt5640 56972 1 snd_soc_tegra_rt5640 3960 0 snd_hda_codec 76398 1 snd_hda_tegra snd_soc_rl6231 1897 1 snd_soc_rt5640 snd_soc_tegra_utils 2825 1 snd_soc_tegra_rt5640 snd_hda_core 26151 2 snd_hda_codec,snd_hda_tegra snd_soc_core 119213 4 snd_soc_tegra_pcm,snd_soc_rt5640,snd_soc_tegra_rt5640,snd_soc_tegra30_i2s snd_compress 7114 1 snd_soc_core snd_pcm_dmaengine 2943 1 snd_soc_core snd_pcm 67835 6 snd_soc_rt5640,snd_soc_core,snd_hda_codec,snd_hda_tegra,snd_pcm_dmaengine,snd_hda_core snd_timer 16881 1 snd_pcm snd 41480 6 snd_soc_core,snd_timer,snd_pcm,snd_hda_codec,snd_hda_tegra,snd_compress soundcore 858 1 snd snd_soc_tegra30_ahub 8747 1 snd_soc_tegra30_i2s nouveau 1217903 0 tegra_devfreq 5389 0 ttm 65073 1 nouveau > This isn't where the story ends unfortunately. The collabora lab also > has a jetson-tk1, booted in the same manner, which boots next-20150818 > fine[4]. The only differences I can spot in the two boot logs is that > the collabora board is using an older version of u-boot, where as my > board is using a newer version. U-Boot 2015.01-00231-gab77f24-dirty > (Good) vs U-Boot 2015.07-00130-gb217c89 (Bad). I don't have either of those commits in any of the U-Boot trees I have. Perhaps whatever tree this comes from has local patches that cause the breakage? The version that I use a recent upstream U-Boot with some local patches, none of which should impact Jetson TK1 in any way. Just to make sure I tried running latest origin/master, which identifies thusly: U-Boot 2015.10-rc2-00040-g0f9258228e2b And that boots next-20150818 fine. If you can point me at the source for the version that you use I may be able to find something that could cause this. > I've also noticed some > angry udev messages after the modules probe in userspace present in > both boot logs that look suspicious. > > [ 70.469914] udevd[108]: worker [113] /devices/soc0/70030000.hda is > taking a long time > [ 70.479849] udevd[108]: worker [115] /devices/soc0/70300000.ahub is > taking a long time > [ 70.490769] udevd[108]: worker [117] /devices/soc0/sound is taking > a long time These look suspicious indeed. Unfortunately I don't see those in the boot log on my setup either. Then again, you seem to be using Eudev 2.1.1, whereas I use the one shipped with systemd 219, so this could also be some sort of weird userspace issue. From the logs it further seems like you've configured the root to be on NFS, but the logs never show NFS to be mounted. Perhaps that's because you're booting into a ramdisk rather than a full root file- system. > FWIW, When I went searching for this patch, I couldn't find it on any > of the mailing lists. The only reference to this patch was from this > pull request, thus why I'm reporting the issue here. :) That's because it's merely sync'ing up the multi_v7_defconfig changes with tegra_defconfig that I forgot to submit for v4.2. I didn't think it necessary to send out a separate patch for that. > Anyways, let me know if you can reproduce this issue, and/or can think > of a reason this might may be causing trouble. Like I said, if you can point me at the U-Boot sources I can take a look if anything jumps out. I've also noticed that the initial ramdisks in both boot logs that you linked to have a slightly different size. But they use the same Eudev version, so I suspect that that's unrelated. Thierry
Attachment:
signature.asc
Description: PGP signature
