RPi 3 extremely slow with F25. Extremely !

[linux guy]

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 !

[solarflow99]

Yes, thanks to those for bringing fedora to the PI.

On Mon, Jan 30, 2017 at 8:18 AM, linux guy  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 !

[Peter Robinson]

On Mon, Jan 30, 2017 at 4:18 PM, linux guy  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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[linux guy]

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.

[linux guy]

... though dnf list sshd still takes a LONG time.  Like minutes.

On Mon, Jan 30, 2017 at 2:17 PM, linux guy  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.

[linux guy]

dnf list was much faster after the first time.

RPI3 -workstation, didn't update with GUI

[Sean Omalley]

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

RPI3 -workstation, didn't update with GUI

[Sean Omalley]

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 
 To: "[e-mail]"  
 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

[Sean Omalley]

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 
 To: Peter Robinson  
Cc: [e-mail]
 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 -- [e-mail]
To unsubscribe send an email to [e-mail]

[linux guy]

Which image did you install ?

On Mon, Jan 30, 2017 at 9:34 PM, Sean Omalley 
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 
> *To:* Peter Robinson 
> *Cc:* [e-mail]
> *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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Sean Omalley]

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 
 To: Sean Omalley  
Cc: Peter Robinson ; "[e-mail]" 
 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  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 
 To: Peter Robinson  
Cc: [e-mail]
 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 -- [e-mail]
To unsubscribe send an email to [e-mail]. org

[marcin steć]

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

[Richard Ryniker]

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.

[marcin steć]

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 :
> 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.

[Peter Robinson]

On Mon, May 8, 2017 at 3:56 PM, marcin steć  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 :
> > 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]