| Message ID | CANMBJr7PKy-eCcB3HiBajpApHS_BYPa7xfKjTqV4o8Z1hwY99A@mail.gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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@gmail.com> 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
On Wed, 2015-08-19 at 11:14 +0200, Thierry Reding wrote: > On Tue, Aug 18, 2015 at 03:30:41PM -0700, Tyler Baker wrote: > > Hi Theirry, > > > > > > 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). Our 2015.01-00231-gab77f24-dirty is 2015.01-00231-gab77f24 + changes which got merged as 053b86e6d8e50359412e626c33bae3f7bafd74dd in upstream u-boot. Fwiw: $ git show 2015.01-00231-gab77f24 commit ab77f24119e80257de4ab017b877f92f96980562 Merge: d928664 fa58b10 Author: Tom Rini <trini@ti.com> Date: Thu Jan 15 14:05:31 2015 -0500 Merge branch 'master' of git://git.denx.de/u-boot-ti Which is definately a commit you should hae in your upstream u-boot tree. > 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. Probably worth for tyler to test that u-boot commit on his jetson to see if that solves the issue he's having...
On Wed, Aug 19, 2015 at 11:48:44AM +0200, Sjoerd Simons wrote: > On Wed, 2015-08-19 at 11:14 +0200, Thierry Reding wrote: > > On Tue, Aug 18, 2015 at 03:30:41PM -0700, Tyler Baker wrote: > > > Hi Theirry, > > > > > > > > > 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). > > Our 2015.01-00231-gab77f24-dirty is 2015.01-00231-gab77f24 + changes > which got merged as 053b86e6d8e50359412e626c33bae3f7bafd74dd in > upstream u-boot. > > Fwiw: > $ git show 2015.01-00231-gab77f24 > commit ab77f24119e80257de4ab017b877f92f96980562 > Merge: d928664 fa58b10 > Author: Tom Rini <trini@ti.com> > Date: Thu Jan 15 14:05:31 2015 -0500 > > Merge branch 'master' of git://git.denx.de/u-boot-ti > > Which is definately a commit you should hae in your upstream u-boot > tree. Yeah, I suck. I was running: $ git show gab77f24 I didn't know git could parse the full output from git describe. > > 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. > > Probably worth for tyler to test that u-boot commit on his jetson to > see if that solves the issue he's having... I've tried reconstructing the version that Tyler is running by checking out 2015.01-00231-gab77f24 and applying 053b86e6d8e5 ("pci: tegra: Fix port information parsing") on top, but that also leaves me with a bootable system, so no way of reproducing. I agree that upgrading to a more recent U-Boot version sounds like the best way forward because it has already proven to work on at least two setups. Thierry
Please try disabling TEGRA124_EMC and seeing if that makes any difference. Mikko On 08/19/2015 01:30 AM, Tyler Baker wrote: > Hi Theirry, > > On 14 August 2015 at 07:48, Thierry Reding <thierry.reding@gmail.com> 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. > > 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 > > 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'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 > > 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. :) > > Anyways, let me know if you can reproduce this issue, and/or can think > of a reason this might may be causing trouble. > > Cheers, > > Tyler > > [1] http://kernelci.org/boot/all/job/next/kernel/next-20150818/ > [2] http://storage.kernelci.org/next/next-20150818/arm-multi_v7_defconfig/lab-tbaker/boot-tegra124-jetson-tk1.html > [3] http://hastebin.com/bixofozaji.vhdl > [4] http://storage.kernelci.org/next/next-20150818/arm-multi_v7_defconfig/lab-collabora/boot-tegra124-jetson-tk1.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-tegra" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
On 19 August 2015 at 03:33, Thierry Reding <thierry.reding@gmail.com> wrote: > On Wed, Aug 19, 2015 at 11:48:44AM +0200, Sjoerd Simons wrote: >> On Wed, 2015-08-19 at 11:14 +0200, Thierry Reding wrote: >> > On Tue, Aug 18, 2015 at 03:30:41PM -0700, Tyler Baker wrote: >> > > Hi Theirry, >> > > >> > > >> > > 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). >> >> Our 2015.01-00231-gab77f24-dirty is 2015.01-00231-gab77f24 + changes >> which got merged as 053b86e6d8e50359412e626c33bae3f7bafd74dd in >> upstream u-boot. >> >> Fwiw: >> $ git show 2015.01-00231-gab77f24 >> commit ab77f24119e80257de4ab017b877f92f96980562 >> Merge: d928664 fa58b10 >> Author: Tom Rini <trini@ti.com> >> Date: Thu Jan 15 14:05:31 2015 -0500 >> >> Merge branch 'master' of git://git.denx.de/u-boot-ti >> >> Which is definately a commit you should hae in your upstream u-boot >> tree. > > Yeah, I suck. I was running: > > $ git show gab77f24 > > I didn't know git could parse the full output from git describe. > >> > 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. >> >> Probably worth for tyler to test that u-boot commit on his jetson to >> see if that solves the issue he's having... > > I've tried reconstructing the version that Tyler is running by checking > out 2015.01-00231-gab77f24 and applying 053b86e6d8e5 ("pci: tegra: Fix > port information parsing") on top, but that also leaves me with a > bootable system, so no way of reproducing. I agree that upgrading to a > more recent U-Boot version sounds like the best way forward because it > has already proven to work on at least two setups. Thanks for looking into this issue guys. I'll upgrade u-boot when I return from Plumbers this week and report back. Cheers, Tyler
Hi Mikko,
On 19 August 2015 at 04:15, Mikko Perttunen <mikko.perttunen@kapsi.fi> wrote:
> Please try disabling TEGRA124_EMC and seeing if that makes any difference.
I disabled CONFIG_TEGRA124_EMC and the problem on my end still exists.
Thanks for the suggestion.
Cheers,
Tyler
On Wed, Aug 19, 2015 at 2:14 AM, Thierry Reding <thierry.reding@gmail.com> wrote: > 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@gmail.com> 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. FWIW, my jetson has been booting fine as well, with U-Boot 2014.07-rc1-00095-gd7782d0 and Debian userspace. (Glad to confirm that it's a good thing we've got variety in how systems are configured and setup so we get more coverage). -Olof
Hi Thierry, On 19 August 2015 at 03:33, Thierry Reding <thierry.reding@gmail.com> wrote: > On Wed, Aug 19, 2015 at 11:48:44AM +0200, Sjoerd Simons wrote: >> On Wed, 2015-08-19 at 11:14 +0200, Thierry Reding wrote: >> > On Tue, Aug 18, 2015 at 03:30:41PM -0700, Tyler Baker wrote: >> > > Hi Theirry, >> > > >> > > >> > > 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). >> >> Our 2015.01-00231-gab77f24-dirty is 2015.01-00231-gab77f24 + changes >> which got merged as 053b86e6d8e50359412e626c33bae3f7bafd74dd in >> upstream u-boot. >> >> Fwiw: >> $ git show 2015.01-00231-gab77f24 >> commit ab77f24119e80257de4ab017b877f92f96980562 >> Merge: d928664 fa58b10 >> Author: Tom Rini <trini@ti.com> >> Date: Thu Jan 15 14:05:31 2015 -0500 >> >> Merge branch 'master' of git://git.denx.de/u-boot-ti >> >> Which is definately a commit you should hae in your upstream u-boot >> tree. > > Yeah, I suck. I was running: > > $ git show gab77f24 > > I didn't know git could parse the full output from git describe. > >> > 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. >> >> Probably worth for tyler to test that u-boot commit on his jetson to >> see if that solves the issue he's having... > > I've tried reconstructing the version that Tyler is running by checking > out 2015.01-00231-gab77f24 and applying 053b86e6d8e5 ("pci: tegra: Fix > port information parsing") on top, but that also leaves me with a > bootable system, so no way of reproducing. I agree that upgrading to a > more recent U-Boot version sounds like the best way forward because it > has already proven to work on at least two setups. Sorry for the delay. I've upgraded u-boot to U-Boot 2015.10-rc2-00439-g03d8714 using the tegra u-boot flashing scripts. FWIW, I did have to revert 620776d734e4 ("tftp: adjust settings to be suitable for 100Mbit ethernet") to get TFTP working again. Anyways, it hangs at the exact same spot[1] with the newer version of u-boot. If remove the modules from the initrd or just disable CONFIG_SND_HDA_TEGRA it boots fine. This weekend I'll try to debug this module manually and see if I draw any conclusions. Cheers, Tyler [1] http://lava.kernelci.org/scheduler/job/180894/log_file
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