Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: Sam James <sam@gentoo.org>, John David Anglin <dave.anglin@bell.net>
Cc: linux-parisc@vger.kernel.org, hppa@gentoo.org
Subject: Re: Recurring INEQUIVALENT ALIASES issues and userland corruption/crashes
Date: Tue, 22 Mar 2022 20:52:56 +0100	[thread overview]
Message-ID: <a8756bee-e149-c03c-36cd-6842eb12d2de@gmx.de> (raw)
In-Reply-To: <309C1399-6AA2-44BD-8EB9-FDB66F5D972E@gentoo.org>

On 3/22/22 20:37, Sam James wrote:
>> On 22 Mar 2022, at 18:19, John David Anglin <dave.anglin@bell.net> wrote:
>>
>> On 2022-03-22 1:52 p.m., Sam James wrote:
>>> Hi all,
>>>
>>> In Gentoo, we've just got our hands on an RP3440 (PA8800) which seems to quite easily hit inequivalent aliasing issues.
>>>
>>> We've found that under some workloads, the machine copes fine, none of that appears in dmesg, and all is well - even for
>>> over a week. But as soon as we start other workloads (the problematic one is building "stages" -- release media for Gentoo),
>>> within 30m or so, the machine is in a broken state, with these messages flooding dmesg:
>>> ```
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x42994000 and 0x426e1000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x426e1000 and 0x41b56000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x41b56000 and 0x41aae000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x41aae000 and 0x42774000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x42774000 and 0x41202000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x41202000 and 0x428dd000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x41e2c000 and 0x418f6000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x418f6000 and 0x42980000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x42980000 and 0x426cd000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x426cd000 and 0x41b42000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x41b42000 and 0x41a9a000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x41a9a000 and 0x42760000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x42760000 and 0x411ee000 in file bash
>>> Mar 22 04:19:55 muta.hppa.dev.gentoo.org kernel: INEQUIVALENT ALIASES 0x411ee000 and 0x428c9000 in file bash
>> I don't think this is new.  There are no changes to the code that detects INEQUIVALENT ALIASES in the latest pull.
>>
>
> Sorry, to be clear: I wasn't trying to suggest the issue is new -- just saying that we've been trying 5.10, 5.15+ to
> see if latest changes helped at all, but they haven't.
>
> In our experience so far, there has been no good kernel version for us on this hardware.

One of the debian buildd servers I mentioned earlier is a 4-way rp3440, and 5.10 runs stable on it for me.
Did you tried plain 5.10.0, or including all patches from the stable branches?
This is the kernel config I used:
http://backup.parisc-linux.org/kernel/STABLE/debian-config

>> I've seen this before but it's not occurring in my current builds for rp3440 and c8000.  I've been running for-next
>> changes on c8000 for several weeks.
>>
>
> Yeah, I haven't seen this at all on my C8000 (or Gentoo's other HW, a C3600).
>
>> I suspect a problem with shmat but I'm not sure.

I suspected that as well, because I had the impression we still carry a patch in
debian's glibc. But I checked debian glibc sources again, and I think all such
relevant patches are now upstreamed.

Helge

  reply	other threads:[~2022-03-22 19:53 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22 17:52 Recurring INEQUIVALENT ALIASES issues and userland corruption/crashes Sam James
2022-03-22 18:14 ` Helge Deller
2022-03-22 18:30   ` John David Anglin
2022-03-22 19:47   ` Sam James
2022-03-22 18:19 ` John David Anglin
2022-03-22 19:37   ` Sam James
2022-03-22 19:52     ` Helge Deller [this message]
2022-03-22 20:42       ` Sam James
2022-03-22 21:04         ` John David Anglin
     [not found]     ` <73bf3336-9207-ba0e-1950-8cb1b7d6adc3@bell.net>
2022-03-22 20:29       ` John David Anglin
2022-03-22 20:43         ` Sam James
2022-03-22 23:59           ` John David Anglin
2022-04-05 21:13 ` John David Anglin
2022-04-12  5:18   ` Sam James
2022-04-12 12:27     ` John David Anglin
2022-04-12 13:20       ` John David Anglin
2022-04-12 23:45         ` Sam James
2022-04-19 19:52           ` Sam James
2022-04-19 21:29             ` John David Anglin
2022-04-19 21:52               ` James Bottomley
2022-04-20  0:11                 ` John David Anglin
2022-04-23 20:33   ` John David Anglin

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=a8756bee-e149-c03c-36cd-6842eb12d2de@gmx.de \
    --to=deller@gmx.de \
    --cc=dave.anglin@bell.net \
    --cc=hppa@gentoo.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=sam@gentoo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox