Re: chainlint test failing on Linux sparc64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 20, 2024 at 5:36 AM Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
> My suspicion is that "actual" will have size 0 for you. If that's the
> case, I'd suggest running the commands from the "check-chainlint"
> target in t/Makefile manually one at a time to see if you can figure
> out which is failing. For instance:
>
>     % ./chainlint.pl --emit-all chainlinttmp/tests

This reminded me of an earlier report in which chainlint.pl was
producing no output for "actual" on Linux for s390x processors. That
was due to /proc/cpuinfo producing results which the script wasn't
expecting. It was fixed by 1f51b77f4f (chainlint.pl: fix /proc/cpuinfo
regexp, 2022-11-22)[1]. At the time of that patch, I noted[2]:

    A separate problem is that chainlint.pl doesn't fall back to a
    sensible non-zero value if ncores() returns 0 (or some other
    nonsense value). That is, of course, outside the scope of the
    well-focused problem fix which this standalone patch addresses. I
    may end up submitting a fix separately to make it fall back
    sensibly.

which probably explains the behavior you're experiencing. To fix it,
we'll need to see the output you get from:

    cat /proc/cpuinfo

[1]: https://lore.kernel.org/git/pull.1385.git.git.1669148861635.gitgitgadget@xxxxxxxxx/
[2]: https://lore.kernel.org/git/CAPig+cQ6_7wf6C280Rqi7mcTCiQp-n5GiLWTPazfcUcGFeZi0g@xxxxxxxxxxxxxx/





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux