linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Embedded Engineer <embed786@gmail.com>, Willy Tarreau <w@1wt.eu>,
	linux-arm-kernel@lists.infradead.org,
	Jon Hunter <jonathanh@nvidia.com>
Subject: Re: Unstable Kernel behavior on an ARM based board
Date: Mon, 4 Mar 2019 14:57:27 +0100	[thread overview]
Message-ID: <20190304135727.GA24676@ulmo> (raw)
In-Reply-To: <20190302114652.fw46qi5opy37cakv@shell.armlinux.org.uk>


[-- Attachment #1.1: Type: text/plain, Size: 2072 bytes --]

On Sat, Mar 02, 2019 at 11:46:52AM +0000, Russell King - ARM Linux admin wrote:
> On Sat, Mar 02, 2019 at 12:25:54PM +0100, Willy Tarreau wrote:
> > On Sat, Mar 02, 2019 at 04:22:48PM +0500, Embedded Engineer wrote:
> > > Thanks for response Russel and Willy, but AFIK the only available
> > > Nvidia downstream kernel for our processor is 3.10.40. I tried
> > > building the upstream kernel (4.9.x I guess) but it kept crashing even
> > > worse so I didn't invest any more time bringing it up on our board.
> > 
> > Then if you depend on a vendor kernel, you have to deal with that vendor
> > since they are the only ones who know what they secretly modified in the
> > kernel to make it magically work sometimes.
> 
> I don't see why that would be necessary - mainline has support for the
> Nvidia Jetson TK1 board, which means we have support for the SoC, so
> mainline kernels should boot fine.

We've got automated testing in place for most of the boards we support
upstream. Most stable kernels are tested, as is linux-next. Jetson TK1
is among the board tested and I'm not aware of any recent regressions,
other than maybe the occasional one in linux-next that usually end up
impacting more than just Tegra.

Adding Jon who keeps better track of the test results than I do.

I should note that there are valid reasons for people wanting to stick
with the downstream kernel. The simple truth is that we lack a certain
number of features upstream, so if customers rely on those they don't
have a lot of choice. We're actively trying to close the feature gap,
but we're not quite there yet.

That said, I agree with what Russell and Willy said. Using a 3.10 kernel
as a base for product development is a bad idea.

My suggestion is to use a recent linux-next as a baseline for testing.
That's the best bet for validating that your hardware is good. Once you
have established that we should have a brief chat about what exactly the
requirements are that you have and then we'll have to evaluate how best
to support you.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-03-04 13:57 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-02 10:44 Unstable Kernel behavior on an ARM based board Embedded Engineer
2019-03-02 11:00 ` Russell King - ARM Linux admin
2019-03-02 11:01 ` Willy Tarreau
2019-03-02 11:22   ` Embedded Engineer
2019-03-02 11:25     ` Willy Tarreau
2019-03-02 11:46       ` Russell King - ARM Linux admin
2019-03-04 13:57         ` Thierry Reding [this message]
2019-03-02 11:36     ` Russell King - ARM Linux admin
2019-03-02 11:52       ` Embedded Engineer
2019-03-02 11:57         ` Russell King - ARM Linux admin
2019-03-02 12:20           ` Embedded Engineer
2019-03-02 12:39             ` Russell King - ARM Linux admin
2019-03-02 13:10               ` Embedded Engineer
2019-03-02 15:07               ` Clemens Koller
2019-03-04  5:14                 ` Embedded Engineer
2019-03-04 10:26                   ` Vladimir Murzin
2019-03-04 12:25                     ` Embedded Engineer
2019-03-04 14:25                       ` Thierry Reding
2019-03-04 15:51                         ` Embedded Engineer
2019-03-05 10:01                         ` Embedded Engineer
2019-03-05 10:07                           ` Russell King - ARM Linux admin
2019-03-05 10:29                             ` Embedded Engineer
2019-03-05 11:20                               ` Thierry Reding
2019-03-05 11:22                               ` Russell King - ARM Linux admin
2019-03-05 11:57                                 ` Thierry Reding
2019-03-05 13:16                                   ` Embedded Engineer
2019-03-05 13:23                                     ` Russell King - ARM Linux admin
2019-03-05 13:32                                       ` Embedded Engineer
2019-03-05 14:23                                         ` Russell King - ARM Linux admin
2019-03-05 14:57                                           ` Embedded Engineer
2019-03-05 14:58                                             ` Russell King - ARM Linux admin
2019-03-05 15:11                                               ` Embedded Engineer
2019-03-05 15:31                                                 ` Russell King - ARM Linux admin
2019-03-05 15:44                                                   ` Embedded Engineer
2019-03-15  8:55                                                     ` Marcel Ziswiler
2019-03-05 16:00                                                   ` Clemens Koller
2019-03-05 16:21                                                     ` Embedded Engineer
2019-03-09  7:50                                                     ` Embedded Engineer
2019-03-05 10:32                           ` Thierry Reding
2019-03-05 11:05                             ` Embedded Engineer
2019-03-05 11:36                               ` Thierry Reding
2019-03-04 14:00                   ` Andrew Lunn
2019-03-04 14:27                     ` Thierry Reding
2019-03-04 15:27                     ` Embedded Engineer
2019-03-04 15:57                       ` Andrew Lunn
2019-03-04 16:03                         ` Embedded Engineer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190304135727.GA24676@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=embed786@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=w@1wt.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).