Hi,
> I've installed Fedora 40 Rawhide on my Rock 5
>
> Short howto:
>
> What you need:
> 1) https://github.com/edk2-porting/edk2-rk3588/releases/download/v0.9.1/rock-5b_UEFI_Release_v0.9.1.img
> dd this Image on a SD-Card
>
> 2) https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/iso/Fedora-Everything-netinst-aarch64-Rawhide-20231113.n.0.iso
>
> dd this Image on a USB stick
>
> Put both in your Rock 5B and boot. I've done the Net-install installation with KDE Wayland. The SD-Card with UEFI is needed for booting.
>
>
> Questions:
>
> 1. GPU:
> root@rockpi5:~# inxi -Gx
> Graphics:
> Message: No PCI device data found.
> Display: server: X.Org v: 23.2.2 with: Xwayland v: 23.2.2 driver: X:
> loaded: modesetting dri: swrast gpu: N/A resolution: 1920x1080~60Hz
> API: EGL v: 1.5 drivers: kms_swrast,swrast platforms:
> active: gbm,x11,surfaceless,device inactive: wayland
> API: OpenGL v: 4.5 vendor: mesa v: 23.3.0 glx-v: 1.4 direct-render: yes
> renderer: llvmpipe (LLVM 17.0.4 128 bits)
> API: Vulkan v: 1.3.268 drivers: llvmpipe surfaces: xcb,xlib devices: 1
> root@rockpi5:~#
>
> How can I improve GPU Performance ? Mali / Panfrost Driver are available but not loaded /used
>
> root@rockpi5:~# rpm -ql mesa-dri-drivers-23.3.0-1.fc40.aarch64 | grep -i pan
> /usr/lib64/dri/panfrost_dri.so
> root@rockpi5:~# rpm -ql mesa-dri-drivers-23.3.0-1.fc40.aarch64 | grep -i mali
> /usr/lib64/dri/mali-dp_dri.so
> root@rockpi5:~#
>
> Creating a custom xorg.conf doesn't make sense while using Wayland ?
That won't make any difference.
The support for accelerated graphics isn't upstream yet. There's a few
series of patches that would need to land, at least this one [1], and
one to support HDMI, possibly more. Looking at [1] I doubt that will
now land for 6.8, the rule of thumb is usually it has to be accepted
by rc5 of the previous cycle, so we'd be looking at 6.9 at the
earliest assuming any other patch series also land, it'll also need
patches for device tree. You could collect the patch series together
and build a kernel if you want it before then.
> 2. Boot
>
> Is there any way to boot Fedora direct from NVME instead using rock-5b_UEFI_Release_v0.9.1.img on SD-Card ?
You need to put the FW on the SPI flash, not sure if the firmware
supports that yet, but there's confirmation it'll work at some point
in their FAQ:
https://wiki.radxa.com/Rock5/FAQs#Q:_Without_eMMC_and_TF_card.2C_can_ROCK_5B_boot_from_PCIe_M.2_NVME_SSD.3F
[1] https://lists.freedesktop.org/archives/dri-devel/2023-December/434211.html
--
_______________________________________________
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Saturday, December 9, 2023
Friday, December 8, 2023
[fedora-arm] Fedora on ROCK 5 Model B
Hello,
I've installed Fedora 40 Rawhide on my Rock 5
Short howto:
What you need:
1) https://github.com/edk2-porting/edk2-rk3588/releases/download/v0.9.1/rock-5b_UEFI_Release_v0.9.1.img
dd this Image on a SD-Card
dd this Image on a USB stick
Put both in your Rock 5B and boot. I've done the Net-install installation with KDE Wayland. The SD-Card with UEFI is needed for booting.
Questions:
1. GPU:
root@rockpi5:~# inxi -Gx
Graphics:
Message: No PCI device data found.
Display: server: X.Org v: 23.2.2 with: Xwayland v: 23.2.2 driver: X:
loaded: modesetting dri: swrast gpu: N/A resolution: 1920x1080~60Hz
API: EGL v: 1.5 drivers: kms_swrast,swrast platforms:
active: gbm,x11,surfaceless,device inactive: wayland
API: OpenGL v: 4.5 vendor: mesa v: 23.3.0 glx-v: 1.4 direct-render: yes
renderer: llvmpipe (LLVM 17.0.4 128 bits)
API: Vulkan v: 1.3.268 drivers: llvmpipe surfaces: xcb,xlib devices: 1
root@rockpi5:~#
How can I improve GPU Performance ? Mali / Panfrost Driver are available but not loaded /used
root@rockpi5:~# rpm -ql mesa-dri-drivers-23.3.0-1.fc40.aarch64 | grep -i pan
/usr/lib64/dri/panfrost_dri.so
root@rockpi5:~# rpm -ql mesa-dri-drivers-23.3.0-1.fc40.aarch64 | grep -i mali
/usr/lib64/dri/mali-dp_dri.so
root@rockpi5:~#
Creating a custom xorg.conf doesn't make sense while using Wayland ?
2. Boot
Is there any way to boot Fedora direct from NVME instead using rock-5b_UEFI_Release_v0.9.1.img on SD-Card ?
Thanks
Andreas
[389-users] Re: 389-ds-base name log pipe problems
Hi,
I see two possible reasons why 389ds could intermittently stop listening on 389 port:
[1] nearly all connections are exhausted.
[2] the server is blocked (probably trying to write in the pipe)
[1] is possible if most of the connections did not get released when the external system was stopped. (It can happen if the ip connection gets silently broken (typically by rebooting a switch) )
In that case it is the fact of restarting 389ds that solved the issue.
[2] Would mean that the application that read the pipe was not able to read the data fast enough. (Either too much data were logged or there was an issue on that application)
Regards,
Pierre
I see two possible reasons why 389ds could intermittently stop listening on 389 port:
[1] nearly all connections are exhausted.
[2] the server is blocked (probably trying to write in the pipe)
[1] is possible if most of the connections did not get released when the external system was stopped. (It can happen if the ip connection gets silently broken (typically by rebooting a switch) )
In that case it is the fact of restarting 389ds that solved the issue.
[2] Would mean that the application that read the pipe was not able to read the data fast enough. (Either too much data were logged or there was an issue on that application)
Regards,
Pierre
On Thu, Dec 7, 2023 at 11:25 AM Nyquist <dongminic@gmail.com> wrote:
1. Stop directory server and remove access log file.
2. Run logpipe.py. Python create access.pipe (pipe)
3. Change directory server settings
nsslapd-accesslog-maxlogsperdir: 1
nsslapd-accesslog-logexpirationtime: -1
nsslapd-accesslog-logrotationtime: -1
nsslapd-accesslog: /var/log/dirsrv/slapd-localhost/access.pipe
nsslapd-accesslog-logbuffering: off
4. Run directory server
=> Check normal execution, logpipe.py and custom.py are operating normally.
The problem arises after this. This server has consumed all connections. A forced shutdown of the external system returned the connection, and we expected it to work normally. However, port 389 health check failed intermittently. Joining and removing from the L4 switch is repeated. Could this be caused by my logging settings to pipe?
Or should I think it's a problem with the Linux file system?
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
389 Directory Server Development Team
389 Directory Server Development Team
Thursday, December 7, 2023
[389-users] Re: 389-ds-base name log pipe problems
1. Stop directory server and remove access log file.
2. Run logpipe.py. Python create access.pipe (pipe)
3. Change directory server settings
nsslapd-accesslog-maxlogsperdir: 1
nsslapd-accesslog-logexpirationtime: -1
nsslapd-accesslog-logrotationtime: -1
nsslapd-accesslog: /var/log/dirsrv/slapd-localhost/access.pipe
nsslapd-accesslog-logbuffering: off
4. Run directory server
=> Check normal execution, logpipe.py and custom.py are operating normally.
The problem arises after this. This server has consumed all connections. A forced shutdown of the external system returned the connection, and we expected it to work normally. However, port 389 health check failed intermittently. Joining and removing from the L4 switch is repeated. Could this be caused by my logging settings to pipe?
Or should I think it's a problem with the Linux file system?
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
2. Run logpipe.py. Python create access.pipe (pipe)
3. Change directory server settings
nsslapd-accesslog-maxlogsperdir: 1
nsslapd-accesslog-logexpirationtime: -1
nsslapd-accesslog-logrotationtime: -1
nsslapd-accesslog: /var/log/dirsrv/slapd-localhost/access.pipe
nsslapd-accesslog-logbuffering: off
4. Run directory server
=> Check normal execution, logpipe.py and custom.py are operating normally.
The problem arises after this. This server has consumed all connections. A forced shutdown of the external system returned the connection, and we expected it to work normally. However, port 389 health check failed intermittently. Joining and removing from the L4 switch is repeated. Could this be caused by my logging settings to pipe?
Or should I think it's a problem with the Linux file system?
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[389-users] Re: 389-ds-base name log pipe problems
Hi,
It would be helpful to have some details how you configured the log pipe
and did the tests. I wonder if it could be related to
https://github.com/389ds/389-ds-base/issues/198.
regards
thierry
On 12/7/23 09:06, Nyquist wrote:
> Hello
>
>
>
> We are using 18 389-ds-base-1.3.10.2,
>
> Recently, one server (A) was set up to log to a pipe.
>
>
>
> Afterwards, a phenomenon occurs where all server connections are occupied by an external system.
>
> The external system has stopped.
>
>
>
> After this incident, the servers returned to normal condition, but
>
> Only server A had intermittent port 389 inaccessibility and delays.
>
> After this, we determined that the problem on server A was due to logging in the pipe.
>
> After changing the pipe to a file, I restarted the server.
>
> After that the problem went away.
>
>
>
> We want to know the exact cause of the delay and inaccessibility that occurred on server A.
>
> How can logging to pipe affect directory server port 389 access?
>
> Could it be a file descriptor related issue? Why were the other 17 servers able to recover to normal?
>
>
>
> Thanks
> --
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
It would be helpful to have some details how you configured the log pipe
and did the tests. I wonder if it could be related to
https://github.com/389ds/389-ds-base/issues/198.
regards
thierry
On 12/7/23 09:06, Nyquist wrote:
> Hello
>
>
>
> We are using 18 389-ds-base-1.3.10.2,
>
> Recently, one server (A) was set up to log to a pipe.
>
>
>
> Afterwards, a phenomenon occurs where all server connections are occupied by an external system.
>
> The external system has stopped.
>
>
>
> After this incident, the servers returned to normal condition, but
>
> Only server A had intermittent port 389 inaccessibility and delays.
>
> After this, we determined that the problem on server A was due to logging in the pipe.
>
> After changing the pipe to a file, I restarted the server.
>
> After that the problem went away.
>
>
>
> We want to know the exact cause of the delay and inaccessibility that occurred on server A.
>
> How can logging to pipe affect directory server port 389 access?
>
> Could it be a file descriptor related issue? Why were the other 17 servers able to recover to normal?
>
>
>
> Thanks
> --
> _______________________________________________
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[389-users] 389-ds-base name log pipe problems
Hello
We are using 18 389-ds-base-1.3.10.2,
Recently, one server (A) was set up to log to a pipe.
Afterwards, a phenomenon occurs where all server connections are occupied by an external system.
The external system has stopped.
After this incident, the servers returned to normal condition, but
Only server A had intermittent port 389 inaccessibility and delays.
After this, we determined that the problem on server A was due to logging in the pipe.
After changing the pipe to a file, I restarted the server.
After that the problem went away.
We want to know the exact cause of the delay and inaccessibility that occurred on server A.
How can logging to pipe affect directory server port 389 access?
Could it be a file descriptor related issue? Why were the other 17 servers able to recover to normal?
Thanks
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
We are using 18 389-ds-base-1.3.10.2,
Recently, one server (A) was set up to log to a pipe.
Afterwards, a phenomenon occurs where all server connections are occupied by an external system.
The external system has stopped.
After this incident, the servers returned to normal condition, but
Only server A had intermittent port 389 inaccessibility and delays.
After this, we determined that the problem on server A was due to logging in the pipe.
After changing the pipe to a file, I restarted the server.
After that the problem went away.
We want to know the exact cause of the delay and inaccessibility that occurred on server A.
How can logging to pipe affect directory server port 389 access?
Could it be a file descriptor related issue? Why were the other 17 servers able to recover to normal?
Thanks
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Wednesday, December 6, 2023
[389-users] Re: Question about @389ds/389-directory-server copr repository
Thanks a lot Viktor, I was able to downgrade to 2.2.9 and now my server is running fine.
I'll be waiting for the issue to be fixed in a future release.
Maybe it's not worth to keep 2.3.7 rpms in the official copr repo as this release doesn't seem to be very stable, don't you think so ?
Cheers, Rosario
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
I'll be waiting for the issue to be fixed in a future release.
Maybe it's not worth to keep 2.3.7 rpms in the official copr repo as this release doesn't seem to be very stable, don't you think so ?
Cheers, Rosario
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Subscribe to:
Posts (Atom)