Just a note to say that I installed the Fedora KDE arm image on my RPi 3 from the link below using a Kingston class 10 SD card and it is running extremely slow. https://muug.ca/mirror/fedora/linux/releases/25/Spins/armhfp/images/Fedora-K...
After the second boot, I opened a console and did a 'dnf update'. With a fast ethernet connection, it has taken nearly 12 hours to complete. It is currently in the 'top' shows nothing CPU usage to be 2.3% for the top process and nothing much for anthing else. The dnf process occasionally pops up in the top list, using less than 1% of the cpu, though about 18% of memory.
Is there a zombie thread running somewhere ?
I'll investigate further once the update process is complete.
BTW: kudos for bringing Fedora to the RPi platform. I'm so happy not to be building custom kernels and to be running the same distribution I use on my other computers. Keep up the good work !
Yes, thanks to those for bringing fedora to the PI.
On Mon, Jan 30, 2017 at 8:18 AM, linux guy linuxguy123@gmail.com wrote:
BTW: kudos for bringing Fedora to the RPi platform. I'm so happy not to be building custom kernels and to be running the same distribution I use on my other computers. Keep up the good work !
On Mon, Jan 30, 2017 at 4:18 PM, linux guy linuxguy123@gmail.com wrote:
Just a note to say that I installed the Fedora KDE arm image on my RPi 3 from the link below using a Kingston class 10 SD card and it is running extremely slow. https://muug.ca/mirror/fedora/linux/releases/25/Spins/armhfp/images/Fedora-K...
I use solely Samsung EVO or Sandisk Ultra and while not fast (it is afterall a $35 computer) it's not bad.
After the second boot, I opened a console and did a 'dnf update'. With a fast ethernet connection, it has taken nearly 12 hours to complete. It is currently in the 'top' shows nothing CPU usage to be 2.3% for the top process and nothing much for anthing else. The dnf process occasionally pops up in the top list, using less than 1% of the cpu, though about 18% of memory.
Never seen it that bad, not even in Australia running over satellite. The 4.9 kernel has some patches to improve MMC performance.
Is there a zombie thread running somewhere ?
Your system only you can tell that.
I'll investigate further once the update process is complete.
If you'd run it in screen you could have just forked another console to investigate while it was running
BTW: kudos for bringing Fedora to the RPi platform. I'm so happy not to be building custom kernels and to be running the same distribution I use on my other computers. Keep up the good work !
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org
I did open another console. I couldn't see anything obvious. What are the tricks to finding a zombie process ?
I let dnf update complete and it did, successfully. When I rebooted the main console wasn't completing to a login, so I knew something was up ! However I was able to get a login at a second console, so I did.
The graphical session never did boot for me, so I had no idea what login was being used, so I tried a few things.
systemctl disable plymouth.service --force systemctl disable graphical.target --force systemctl disable lightdm.service --force systemctl disable kdm.service --force
Then I did a bit of investigating
ls -l /etc/systemd/system/display-manager.service
This told me it was running sddm.
so: systemctl- disable sddm.service followed by shutdown -r now
Now it boots to a command line and runs at a reasonable speed !
I don't need a GUI right now anyway. I'll investigate further when I get some time.
... though dnf list sshd still takes a LONG time. Like minutes.
On Mon, Jan 30, 2017 at 2:17 PM, linux guy linuxguy123@gmail.com wrote:
I did open another console. I couldn't see anything obvious. What are the tricks to finding a zombie process ?
I let dnf update complete and it did, successfully. When I rebooted the main console wasn't completing to a login, so I knew something was up ! However I was able to get a login at a second console, so I did.
The graphical session never did boot for me, so I had no idea what login was being used, so I tried a few things.
systemctl disable plymouth.service --force systemctl disable graphical.target --force systemctl disable lightdm.service --force systemctl disable kdm.service --force
Then I did a bit of investigating
ls -l /etc/systemd/system/display-manager.service
This told me it was running sddm.
so: systemctl- disable sddm.service followed by shutdown -r now
Now it boots to a command line and runs at a reasonable speed !
I don't need a GUI right now anyway. I'll investigate further when I get some time.
I got the RPI3. Grabbed the F25 1-3 workstation image.
I am having issues with the logitech k400 keyboard not working working inside gui applications I tried terminal and firefox. I can log in fine, but I open up terminal, and it wont take any keystrokes. The mouse part still works. I clicked the software update hoping the previously mentioned issue would be fixed. It didn't update. I tried twice, I was able to login via ssh, and I am upgrading 483 packages.
I am using an external usb wireless device since according to the docs the internal wireless doesn't work.
What are the issues with the internal wireless and the gpio pins? is it solvable or is there a page (or information) on what needs to be done to get it to work?
ThanksSean
heh, possibly software update didn't like me because I forgot to resize the root partition. :) I don't know if it does a free space check prior to downloading or not.
From: Sean Omalley omalley_s@rocketmail.com To: "arm@lists.fedoraproject.org" arm@lists.fedoraproject.org Sent: Monday, January 30, 2017 6:06 PM Subject: RPI3 -workstation, didn't update with GUI
I got the RPI3. Grabbed the F25 1-3 workstation image.
I am having issues with the logitech k400 keyboard not working working inside gui applications I tried terminal and firefox. I can log in fine, but I open up terminal, and it wont take any keystrokes. The mouse part still works. I clicked the software update hoping the previously mentioned issue would be fixed. It didn't update. I tried twice, I was able to login via ssh, and I am upgrading 483 packages.
I am using an external usb wireless device since according to the docs the internal wireless doesn't work.
What are the issues with the internal wireless and the gpio pins? is it solvable or is there a page (or information) on what needs to be done to get it to work?
ThanksSean
It is acting super slow for me too. I don't know how fast my media is, but the update is stlll going (319/999) and it has been around 5 hours so far. I don't see any zombies but top shows almost nothing. uptime is showing a load of like 3.x and the gui is hung with a black screen. Apparently sshd just stopped responding as I was typing this before I could poke through the logs. free was still showing a lot of free memory. Btw I am also thankful F25 is out and I can match my desktop.
From: linux guy linuxguy123@gmail.com To: Peter Robinson pbrobinson@gmail.com Cc: arm@lists.fedoraproject.org Sent: Monday, January 30, 2017 5:12 PM Subject: [fedora-arm] Re: RPi 3 extremely slow with F25. Extremely !
dnf list was much faster after the first time.
_______________________________________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org
Which image did you install ?
On Mon, Jan 30, 2017 at 9:34 PM, Sean Omalley omalley_s@rocketmail.com wrote:
It is acting super slow for me too. I don't know how fast my media is, but the update is stlll going (319/999) and it has been around 5 hours so far. I don't see any zombies but top shows almost nothing. uptime is showing a load of like 3.x and the gui is hung with a black screen. Apparently sshd just stopped responding as I was typing this before I could poke through the logs. free was still showing a lot of free memory.
Btw I am also thankful F25 is out and I can match my desktop.
*From:* linux guy linuxguy123@gmail.com *To:* Peter Robinson pbrobinson@gmail.com *Cc:* arm@lists.fedoraproject.org *Sent:* Monday, January 30, 2017 5:12 PM *Subject:* [fedora-arm] Re: RPi 3 extremely slow with F25. Extremely !
dnf list was much faster after the first time.
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org
It was the F25 1-3 workstation image. It never did finish. The network interface changed IPs so possibly sshd didn't actually crash. I assume it was dropping packets or something. Now I can't finish the update. I am getting "Error: Failed to synchronize cache for repo 'updates'" which sounds like a network error of some sort. I did do a 'dnf clean all' but that didn't work either. I might just reinstall. the video had already crashed because I was playing around with the setting trying to get the top bar of the screen to show up so you could click on the menu easier, and after about the 5th profile I tried, it just went black and never came back. :)
From: linux guy linuxguy123@gmail.com To: Sean Omalley omalley_s@rocketmail.com Cc: Peter Robinson pbrobinson@gmail.com; "arm@lists.fedoraproject.org" arm@lists.fedoraproject.org Sent: Tuesday, January 31, 2017 2:55 PM Subject: Re: [fedora-arm] Re: RPi 3 extremely slow with F25. Extremely !
Which image did you install ?
On Mon, Jan 30, 2017 at 9:34 PM, Sean Omalley omalley_s@rocketmail.com wrote:
It is acting super slow for me too. I don't know how fast my media is, but the update is stlll going (319/999) and it has been around 5 hours so far. I don't see any zombies but top shows almost nothing. uptime is showing a load of like 3.x and the gui is hung with a black screen. Apparently sshd just stopped responding as I was typing this before I could poke through the logs. free was still showing a lot of free memory. Btw I am also thankful F25 is out and I can match my desktop.
From: linux guy linuxguy123@gmail.com To: Peter Robinson pbrobinson@gmail.com Cc: arm@lists.fedoraproject.org Sent: Monday, January 30, 2017 5:12 PM Subject: [fedora-arm] Re: RPi 3 extremely slow with F25. Extremely !
dnf list was much faster after the first time.
______________________________ _________________ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject. org
Hi, I'd like to report that latest F25 Server on RPi 3B is slooooow too. It came with 4.8 kernel known for some issues on ARM, but after dnf update (it took ages to complete) 4.10.13-200.fc25.armv7hl is no better. I've found that anything that's writing to mmcblk0, gets blocked on maximum write speed of 64 kb/s. Main guilty is... systemd, perhaps updating journal. I've been playing with /sys/block/mmcblk0/queue/scheduler to change scheduler from cfq to something else but no spectacular results. The card is Class 10 Sandisk which performed very well under latest Raspbian ( where latest means kernel 3.something ).
I have tested IO performance on budget Sandisk Criuser USB 2.0 stick (it acts as my squid chache directory) and performance is roughly the same as on regular PC, so it seems that the problem is inside the mmc driver.
BTW: Let me join your kudos for those bringing Fedora to RPi !
marcinek
If the slowdown is due to log writes, what is written into your journal?
It may be awkward to access the journal using the RPi, but move the SD card to another Fedora system (many laptops have flash card readers built in, or use a USB device) and a "smoking gun" may be obvious. The journal format does not depend on machine architecture. Use the --directory= argument for journalctl.
Journal is not the reason. It's just the first one to hit the bottleneck. It's not logging anything unusual, just normal trafiic. But following your suggestion I checked this card in my Lenovo W541 running F25. I've got average write speed of around 7MB/s. When I sent the same file (2.4 GiB zip) to my PI, and it nearly killed it - 1.5 core constantly occupied by system, rest is blocked by IO waits. But write speed wasn't so much worse: 4.1 MiB/s. Just for curiosity, I wrote the same file onto USB stick attached to my PI - this time it was slower (3.2 MiB/s), but system seemed to be more responsive. So writing is CPU intensive and that makes me wonder what is use_spi_crc option responsible for in mmc_core kernel module and how to check it's current value.
After quick look into module's code I see it is supposed to do some data validation with crc which I think may lead to lots of CPU intensive operations in kernel mode ? How do I check "use_spi_crc" current value? I couldn't find any obvious files in /proc or /sys filesystems. If it's value is "true" than how do I set it to false? Is proper /etc/modprobe.d file entry sufficient or should I play with kernel parameters at startup since it is responsible for accessing root filesystem ?
regards, marcinek
2017-05-08 14:55 GMT+02:00 Richard Ryniker ryniker@alum.mit.edu:
If the slowdown is due to log writes, what is written into your journal?
It may be awkward to access the journal using the RPi, but move the SD card to another Fedora system (many laptops have flash card readers built in, or use a USB device) and a "smoking gun" may be obvious. The journal format does not depend on machine architecture. Use the --directory= argument for journalctl.
On Mon, May 8, 2017 at 3:56 PM, marcin steć stecenator@gmail.com wrote:
Journal is not the reason. It's just the first one to hit the bottleneck.
You are correct, it's primarily a kernel issue.
The good news this has improved with Fedora 26, and should improve some more for F-26 goes GA.
I was getting around 8 MBps on F-25, on F-26 with the same SD card I can get around 22-24.
Most of these changes won't be coming to F-25 as it's very fiddly and time consuming to ensure a clean upgrade path so I'll be focusing on F-26 in that regard.
Peter
It's not logging anything unusual, just normal trafiic. But following your suggestion I checked this card in my Lenovo W541 running F25. I've got average write speed of around 7MB/s. When I sent the same file (2.4 GiB zip) to my PI, and it nearly killed it - 1.5 core constantly occupied by system, rest is blocked by IO waits. But write speed wasn't so much worse: 4.1 MiB/s. Just for curiosity, I wrote the same file onto USB stick attached to my PI - this time it was slower (3.2 MiB/s), but system seemed to be more responsive. So writing is CPU intensive and that makes me wonder what is use_spi_crc option responsible for in mmc_core kernel module and how to check it's current value.
After quick look into module's code I see it is supposed to do some data validation with crc which I think may lead to lots of CPU intensive operations in kernel mode ? How do I check "use_spi_crc" current value? I couldn't find any obvious files in /proc or /sys filesystems. If it's value is "true" than how do I set it to false? Is proper /etc/modprobe.d file entry sufficient or should I play with kernel parameters at startup since it is responsible for accessing root filesystem ?
regards, marcinek
2017-05-08 14:55 GMT+02:00 Richard Ryniker ryniker@alum.mit.edu:
If the slowdown is due to log writes, what is written into your journal?
It may be awkward to access the journal using the RPi, but move the SD card to another Fedora system (many laptops have flash card readers built in, or use a USB device) and a "smoking gun" may be obvious. The journal format does not depend on machine architecture. Use the --directory= argument for journalctl.
arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-leave@lists.fedoraproject.org
-
linux guy -
marcin steć -
Peter Robinson -
Richard Ryniker -
Sean Omalley -
solarflow99