All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Rob Herring <robh@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [GIT PULL] Devicetree updates for v6.1
Date: Sun, 9 Oct 2022 13:41:35 -0700	[thread overview]
Message-ID: <CAHk-=wjNaJWvvUKTk43H-OtdP+wnM31tw8v4oz5t1TzfO4x+TQ@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqLR=9czyHPngjKczSxK8icw1=vBFHKgiRNz2AdvVRKC2A@mail.gmail.com>

On Sun, Oct 9, 2022 at 11:32 AM Rob Herring <robh@kernel.org> wrote:
>
> Linus, Did you miss this?

No, it's still in my queue.

Right now I'm doing merges (very slowly) on my laptop, while waiting
for new ECC memory DIMMs to arrive.

I have had some instability on my main desktop the last couple of
days, with random memory corruption in user space resulting in my
allmodconfig builds randomly failing with internal compiler errors
etc.

When that happens during the merge window, it's obviously a new kernel
bug causing problems, which is never a great thing.

Except this time it wasn't - it was literally a DIMM going bad in my
machine randomly after 2.5 years of it being perfectly stable. Go
figure. Verified first by booting an old kernel, and then with
memtest86+ overnight.

My new memory is "out for delivery", so hopefully I'll be back up to
full speed by this evening, but I'll probably leave memtest86+ for
another overnight with the new DIMMs just because this wasn't the
greatest experience ever. A fair amount of wasted time blaming all the
wrong things, because _obviously_ it wasn't my hardware suddenly going
bad.

              Linus

PS. And yes, my system is all set up for ECC - except I built it
during the early days of COVID when there wasn't any ECC memory
available at any sane prices. And then I never got around to fixing
it, until I had to detect errors the hard wat. I absolutely *detest*
the crazy industry politics and bad vendors that have made ECC memory
so "special".

  reply	other threads:[~2022-10-09 20:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-03 20:31 [GIT PULL] Devicetree updates for v6.1 Rob Herring
2022-10-09 18:31 ` Rob Herring
2022-10-09 20:41   ` Linus Torvalds [this message]
2022-10-10 18:04     ` Linus Torvalds
2022-10-10 20:56 ` pr-tracker-bot

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='CAHk-=wjNaJWvvUKTk43H-OtdP+wnM31tw8v4oz5t1TzfO4x+TQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.