Dear all, consider this an update to [1]. [1]: https://lore.kernel.org/linux-ia64/cb4faf4f-1efc-5ae7-c8f7-7aad9c2a4d73@xxxxxx/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@xxxxxx/ [3]: https://lore.kernel.org/linux-ia64/E1qgnh2-007ZRZ-WD@xxxxxxxxxxxxxxxxxxxxxx/ **** 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
|