From: Frank Scheiner <frank.scheiner@web.de>
To: linux-ia64@vger.kernel.org
Cc: "Tomáš Glozar" <tglozar@gmail.com>,
"Linus Torvalds" <torvalds@linux-foundation.org>,
aurel32@debian.org, debian-ia64 <debian-ia64@lists.debian.org>,
ia64@gentoo.org
Subject: Linux/ia64: An update
Date: Tue, 17 Oct 2023 17:21:24 +0200 [thread overview]
Message-ID: <87cbede6-a1fe-4d66-9156-df92c51e132f@web.de> (raw)
Dear all,
consider this an update to [1].
[1]:
https://lore.kernel.org/linux-ia64/cb4faf4f-1efc-5ae7-c8f7-7aad9c2a4d73@web.de/T/#u
So about two weeks later and another two v6.6 release candidates (5 and
6) tested successfully on the following machines:
* rx2620 (w/2 x Montecito)
* rx4640 (w/2 x Madison)
* 2 x rx2660 (w/2 x Montecito, w/1 x Montvale)
* rx6600 (w/4 x Montvale)*
* rx2800 i2 (w/1 x Tukwila)
This doesn't look like a broken architecture, does it?
*) As I haven't yet found out why exactly the breakage (mentioned in
[1]) happens for the rx6600, I just reverted the problematic commit
(61167ad) to check if anything else could hinder its operation. And that
is not the case. As 61167ad seems to not break any other systems or
architectures, I want to give it a little more time and sprinkle some
printks around where it breaks, before giving up on this and contact the
author for help.
In addition I'm looking into testing patches dropped for ia64, e.g. [2]
- which worked for me - and with v6.6-rc6 also [3] - which was merged
with ddf2085 and which also worked for me (see above).
[2]:
https://lore.kernel.org/linux-ia64/d43037ee-bb7f-0cdc-a14d-8cddca8bb373@web.de/
[3]:
https://lore.kernel.org/linux-ia64/E1qgnh2-007ZRZ-WD@rmk-PC.armlinux.org.uk/
****
Outside of the kernel - but still relevant for distributions - work was
done for the glibc, too: Tomas discovered a seemingly long forgotten
patch for ia64 by Aurelien Jarno that was adapted to the current state
of the glibc sources and extended with own changes. In total this
enabled 50 unsupported tests, lowered the number of failed tests by 30,
and increased the total number of passing tests by 83 - don't ask me how
`make check` calculates the last number ;-). See [4] for details, since
then we could increase the number of passing tests further.
[4]: https://sourceware.org/bugzilla/show_bug.cgi?id=10163#c6
Considering that math "errors" like those (e.g. for `tanf(INFINITY)`)
are there in the glibc for more than 10 years, our progress in just
three weeks into it is not bad. We are working on getting the remaining
errors fixed, too.
Cheers,
Frank
reply other threads:[~2023-10-17 15:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=87cbede6-a1fe-4d66-9156-df92c51e132f@web.de \
--to=frank.scheiner@web.de \
--cc=aurel32@debian.org \
--cc=debian-ia64@lists.debian.org \
--cc=ia64@gentoo.org \
--cc=linux-ia64@vger.kernel.org \
--cc=tglozar@gmail.com \
--cc=torvalds@linux-foundation.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).