46
Operating Systems and Porting / Re: Fedora 38 (Workstation Edition Prerelease) on Talos II works just fine
« on: January 09, 2023, 05:14:38 pm »
No, full monitor resolution 1600x1200 works fine.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
47
Operating Systems and Porting / Fedora 38 (Workstation Edition Prerelease) on Talos II works just fine
« on: January 06, 2023, 01:16:21 pm »
Today I had a day off and decided to install Fedora Rawhide from 2022/12./23, which I had downloaded two days earlier,
on a trial basis. The installation from the usb key went without any major problems, remembering my previous problems
with XFS this time I chose ext2 for the /boot directory and ext4 for the rest.
After the installation I was positively surprised, GDM booted by default with Wayland enabled and ran desktop on both cards:
ASPEED and Radeon Pro WX7100. I have two monitors connected to the Radeon with resolutions of 5120x2160 and 1920x1200.
To the ASPEED card I have a monitor connected with a resolution of 1600x1200. Wayland ran at maximum resolution on the two
smaller monitors and at 2560x1080 on the largest monitor. Gnome 43.1 ran quite smoothly on this virtual screen. Even moving
windows from tab to tab caused no noticeable problems. I tried to increase the resolution on the largest monitor from within Gnome
but was unsuccessful. Unfortunately, due to Wayland's serious shortcomings when it comes to the ability to configure details,
gnome-tweaks, xset, etc., I went back to the standard X11 installation with two monitors.
From my point of view, the most interesting new features in Fedora 38 are:
on a trial basis. The installation from the usb key went without any major problems, remembering my previous problems
with XFS this time I chose ext2 for the /boot directory and ext4 for the rest.
After the installation I was positively surprised, GDM booted by default with Wayland enabled and ran desktop on both cards:
ASPEED and Radeon Pro WX7100. I have two monitors connected to the Radeon with resolutions of 5120x2160 and 1920x1200.
To the ASPEED card I have a monitor connected with a resolution of 1600x1200. Wayland ran at maximum resolution on the two
smaller monitors and at 2560x1080 on the largest monitor. Gnome 43.1 ran quite smoothly on this virtual screen. Even moving
windows from tab to tab caused no noticeable problems. I tried to increase the resolution on the largest monitor from within Gnome
but was unsuccessful. Unfortunately, due to Wayland's serious shortcomings when it comes to the ability to configure details,
gnome-tweaks, xset, etc., I went back to the standard X11 installation with two monitors.
From my point of view, the most interesting new features in Fedora 38 are:
- kernel 6.2.0 series, in this case 0.rc2.20230103;
- very good support for Samsung SSDs, reding above 6.2 GB/s;
- Gnome 43.1, which, despite the developers' efforts, can be personalized with extensions such as WhiteSur ;-)
- NetBeans 16 and Java 17 work flawlessly.
48
Operating Systems and Porting / Re: [NEWS] Fedora 37 has arrived!
« on: December 20, 2022, 04:43:43 am »
This script gets the Petitboot version number from a file like this:
Code: [Select]
cat /sys/firmware/devicetree/base/ibm,firmware-versions/petitboot
and expects this string to be of the form, for example, 1.8.0 and gets something like this:Code: [Select]
cat /sys/firmware/devicetree/base/ibm,firmware-versions/petitboot
0ed84c0-p94177c1
49
Operating Systems and Porting / Re: [NEWS] Fedora 37 has arrived!
« on: December 19, 2022, 10:35:17 am »
In order for petitboot to see the new kernels you must run the following commands after the update:
This situation is due to an error in the /usr/lib/kernel.d/99-grub-mkconfig.install script on lines 28 and 29.
The script expects the Pettitboot version in Num1.Num2.Num3 format and reads the values in CRC1-CRC2 format.
Code: [Select]
$ sudo grub2-mkconfig > /boot/grub2/grub.cfg
This situation is due to an error in the /usr/lib/kernel.d/99-grub-mkconfig.install script on lines 28 and 29.
The script expects the Pettitboot version in Num1.Num2.Num3 format and reads the values in CRC1-CRC2 format.
50
Talos II / Re: Unsatisfactory performance of SSD drives
« on: December 01, 2022, 07:22:41 am »
Good news, Fedora 36 has experienced an amazing progression in this subject over the past month.
Kernel 6.0.9: ~30% increase in read performance over the 6.0.5 version.
Kernel 6.0.10: ~425% increase in read performance over the 6.0.9 version
Kernel 6.0.9: ~30% increase in read performance over the 6.0.5 version.
Kernel 6.0.10: ~425% increase in read performance over the 6.0.9 version
51
Talos II / Re: Unsatisfactory performance of SSD drives
« on: November 08, 2022, 12:34:13 pm »Code: [Select]
# lspci -s 0001:01:00.0 -vv
0001:01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller PM9A1/PM9A3/980PRO (prog-if 02 [NVM Express])
Subsystem: Samsung Electronics Co Ltd Device a801
Device tree node: /sys/firmware/devicetree/base/pciex@600c3c0100000/pci@0/mass-storage@0
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 33
NUMA node: 0
IOMMU group: 1
Region 0: Memory at 600c080000000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s unlimited, L1 unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset+ SlotPowerLimit 0.000W
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ FLReset-
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend-
LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <64us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 16GT/s (ok), Width x4 (ok)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+ NROPrPrP- LTR+
10BitTagComp+ 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix-
EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit-
FRS- TPHComp- ExtTPHComp-
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+ LTR- OBFF Disabled,
AtomicOpsCtl: ReqEn-
LnkCap2: Supported Link Speeds: 2.5-16GT/s, Crosslink- Retimer+ 2Retimers+ DRS-
LnkCtl2: Target Link Speed: 16GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete+ EqualizationPhase1+
EqualizationPhase2+ EqualizationPhase3+ LinkEqualizationRequest-
Retimer- 2Retimers- CrosslinkRes: Upstream Port
Capabilities: [b0] MSI-X: Enable+ Count=130 Masked-
Vector table: BAR=0 offset=00003000
PBA: BAR=0 offset=00002000
Capabilities: [100 v2] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP+ BadDLLP+ Rollover- Timeout+ AdvNonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn+ ECRCChkCap+ ECRCChkEn+
MultHdrRecCap+ MultHdrRecEn- TLPPfxPres- HdrLogCap-
HeaderLog: 00000000 00000000 00000000 00000000
Capabilities: [168 v1] Alternative Routing-ID Interpretation (ARI)
ARICap: MFVC- ACS-, Next Function: 0
ARICtl: MFVC- ACS-, Function Group: 0
Capabilities: [178 v1] Secondary PCI Express
LnkCtl3: LnkEquIntrruptEn- PerformEqu-
LaneErrStat: 0
Capabilities: [198 v1] Physical Layer 16.0 GT/s <?>
Capabilities: [1bc v1] Lane Margining at the Receiver <?>
Capabilities: [214 v1] Latency Tolerance Reporting
Max snoop latency: 0ns
Max no snoop latency: 0ns
Capabilities: [21c v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+
PortCommonModeRestoreTime=10us PortTPowerOnTime=10us
L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
T_CommonMode=0us LTR1.2_Threshold=0ns
L1SubCtl2: T_PwrOn=10us
Capabilities: [3a0 v1] Data Link Feature <?>
Kernel driver in use: nvme
Kernel modules: nvme
hdparm gives better results but it is a single reading:
Code: [Select]
# hdparm -t /dev/nvme0n1
/dev/nvme0n1:
Timing buffered disk reads: 12676 MB in 3.00 seconds = 4225.32 MB/sec
52
Applications and Porting / Re: Problem with std::numeric_limits<char>::max()
« on: November 04, 2022, 02:43:14 am »
53
Applications and Porting / Re: Problem with std::numeric_limits<char>::max()
« on: November 04, 2022, 01:52:25 am »
I checked it out at https://en.cppreference.com/w/cpp/types/climits. Actually in the example it says that these are "possible values". Nevertheless, I am very surprised that C++ defines its portability so poorly.
The same algorithm implemented in Java works equally on both platforms.
The test code:
Thanks for the hint, I am implementing a workaround.
The same algorithm implemented in Java works equally on both platforms.
The test code:
Code: [Select]
import java.lang.*;
public class JLimits
{
public static void main(String[] args)
{
System.out.printf("byte.MAX_VALUE == %d.\n", Byte.MAX_VALUE);
}
}
Thanks for the hint, I am implementing a workaround.
54
Applications and Porting / Re: Problem with std::numeric_limits<char>::max()
« on: November 03, 2022, 03:02:15 pm »
On FreeBSD 14.0 ppc64 with clang 14.0.5 has the same thing.
55
Applications and Porting / Problem with std::numeric_limits<char>::max()
« on: November 03, 2022, 02:37:51 pm »
I'm porting my software to ppc64le and ran into a problem in the std::numeric_limits<char>::max() function. According to
the documentation, this operation should return the value CHAR_MAX which is 127. This is the case on x86_64 with gcc 11.3.1
compiler. Unfortunately on ppc64le the code compiled with gcc 12.2.1 returns the value UCHAR_MAX which is 255.
Test code:
Clang 14.0.5 and IBM xlc 16.01.0001.0003 return the same value.
Have any of you encountered such a problem on distributions other than Fedora 36?
the documentation, this operation should return the value CHAR_MAX which is 127. This is the case on x86_64 with gcc 11.3.1
compiler. Unfortunately on ppc64le the code compiled with gcc 12.2.1 returns the value UCHAR_MAX which is 255.
Test code:
Code: [Select]
printf("std::numeric_limits<char>::max() == %d\n", static_cast<int>(std::numeric_limits<char>::max()));
Clang 14.0.5 and IBM xlc 16.01.0001.0003 return the same value.
Have any of you encountered such a problem on distributions other than Fedora 36?
56
Operating Systems and Porting / Re: Trying out Chimera Linux
« on: November 03, 2022, 04:03:11 am »
I haven't used KDE in a long time, about 15 years ;-) I installed KDE on Talos II but I wasn't satisfied,
the graphics handling is somehow weird. When resizing the window, rendering runs terribly slow. But
I will try to play with it again. Configuring KDE to a usable state, I want KDE to look like my macOS
on my laptop, is tedious.
the graphics handling is somehow weird. When resizing the window, rendering runs terribly slow. But
I will try to play with it again. Configuring KDE to a usable state, I want KDE to look like my macOS
on my laptop, is tedious.
57
Talos II / Unsatisfactory performance of SSD drives
« on: November 01, 2022, 08:57:16 am »
I switched to the Talos II machine from a Dell Precision 7730 laptop. In the laptop I had an older-generation Samsung SSD,
a 970 Pro, connected via an M.2 connector to PCI 3.0. In the Talos II I used a 980 Pro connected to PCI 4.0 via an ICY BOX
PCIe 4.0 x4 - M.2 PCIe NVMe controller (up to 64 Gbit/s). I expected a read transfer of 5-6 GB/s and got 0.9 GB/s.
That's more than three times slower than on a laptop. Screenshots attached.
Is there any way to improve this?
a 970 Pro, connected via an M.2 connector to PCI 3.0. In the Talos II I used a 980 Pro connected to PCI 4.0 via an ICY BOX
PCIe 4.0 x4 - M.2 PCIe NVMe controller (up to 64 Gbit/s). I expected a read transfer of 5-6 GB/s and got 0.9 GB/s.
That's more than three times slower than on a laptop. Screenshots attached.
Is there any way to improve this?
58
Operating Systems and Porting / Re: Trying out Chimera Linux
« on: November 01, 2022, 05:12:06 am »
I tested this distribution some time ago on my Talos II. From my perspective, the most discouraging part is Gnome.
I've been using this DE for more than a decade and with each release it gets worse and worse. Features that I care
about and that were good are disappearing. The stability of add-ons that bring back old functionality is unsatisfactory.
Before they work properly, the version of Gnome changes and the adjustment process starts from the beginning.
This takes more and more work and is frustrating. Add-ons such as DING Gtk4, for example, do not work properly
with an add-on such as Dash-to-Dock. GJS crashes every now and then, normal work becomes an ordeal.
I'm more comfortable with the concept as presented by ravynOS, I'm rooting for this project,
unfortunately at this moment there is no version for ppc64/ppc64le.
I've been using this DE for more than a decade and with each release it gets worse and worse. Features that I care
about and that were good are disappearing. The stability of add-ons that bring back old functionality is unsatisfactory.
Before they work properly, the version of Gnome changes and the adjustment process starts from the beginning.
This takes more and more work and is frustrating. Add-ons such as DING Gtk4, for example, do not work properly
with an add-on such as Dash-to-Dock. GJS crashes every now and then, normal work becomes an ordeal.
I'm more comfortable with the concept as presented by ravynOS, I'm rooting for this project,
unfortunately at this moment there is no version for ppc64/ppc64le.
59
Operating Systems and Porting / Re: I am looking for a dnetc to count OGR-28 on PPC64LE
« on: October 24, 2022, 02:51:12 pm »
Some time ago I compiled a version downloaded from https://github.com/dcti/dnetc-client-base.git.
The PPC target compiles without problems but it's a 32 bit version and is nightmarishly slow.
For OGR28 it is about 10 times slower than the one for x86 on Intel i9-8950HK.
The PPC target compiles without problems but it's a 32 bit version and is nightmarishly slow.
For OGR28 it is about 10 times slower than the one for x86 on Intel i9-8950HK.
60
Operating Systems and Porting / Re: News, discussions and problems, about the new Kernels on Power
« on: October 14, 2022, 04:58:43 am »
If you can then test the operation of XFS. I mean such a case when root directory is on XFS partition and during normal system operation we will turn off the power by pulling the cable. Won't Petitboot hang on startup when reading this partition. Version 5.12.17+ leaves the XFS partition in such a state that Petitboot is unable to read it properly, the kernel module crashes.
