Hi,
there is a problem with post install first boot process on some boards.
For example on board pcDuino3 Nano and based on [1] probably on
Cubieboard too.
After installing latest Fedora 25 nightly image(*.sda.raw.xz) on sd card
using fedora-arm-image-installer, system "hangs" during last boot phase
when it runs initial-setup service.
What really happens is that on attached monitor, there is nothing
indicating what is happening and no login prompt, because initial-setup
is actually running, but it is not attached to tty1. With serial-usb
cable from other computer, I've verified that it is in fact running on
ttyS0 console.
I'm not sure what is proper solution and what is the problem exactly.
I've file a bug [2] and discussed this with initial-setup
maintainer(CCed), yet did not come up with good solution. initial-setup
can be forced to run on tty1, but it's probably not the correct
solution, because I guess that boards with no GPU won't have tty1,
right? initial-setup.service uses tty which as systemd default is set to
/dev/console. Seems that /dev/console is set to ttyS0, which is probably
beneficial for debugging purposes, but causes this invisible initial-setup.
Cheers
Michal Hlavinka
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1344942
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1387742
Is there a way to stop the Ethernet controller from monopolizing the
upstream USB channel, while in high usage, in detriment of other USB
devices on LAN9514 (Raspberry Pi 2 USB-Hub/Ethernet chip)?
Basically, if you have a USB-attached storage device and start writing
data that comes from the Ethernet into this USB disk, the Ethernet chip
will always have priority on the USB bus and the kernel will never have
the chance to use it to write on the storage device.
As a result, the data incoming from the Ethernet gets stored in the
kernel IO buffer until memory runs out, and then the transfer stops for
a while (as the kernel starting dropping TCP packets and the TCP flow
control algorithm kicks in). On the other hand, if you stop the network
transfer before the buffer is filled, the content on it is immediately
flushed to disk.
This would not be a huge problem if the USB-attached storage devices
didn't have a timeout: after not receiving some keepalive packets from
the system it's attached to, it dies. With my USB disk, at least, you
have to unplug its USB cable and plug it again to convince its
controller that the system is back up.
Of course, this is a even bigger issue on Raspberry if the system's root
is installed on this USB disk.
I'm not sure that this is fixed in the Raspberry Pi Foundation's remix
of Debian, but I'm definitely hitting this bug on Fedora 25 beta with
Linux 4.8.0-0.rc7.git0.1.fc25.armv7hl.
How to reproduce, considering /dev/sda is some USB-attached storage on
the rasp2:
desktop$ dd if=some_big_file bs=8M | ssh root@rasp2 dd of=/dev/sda bs=8M
Meanwhile, you may watch the kernel buffer's filling up on the rasp2
with htop or free. You may also notice that if you cancel the SSH
transfer before the rasp2 kernel buffer is filled (and also before your
USB disk gives up waiting on the keepalive packet), the content stored
on the buffer is almost immediately flushed to the disk.
How can we fix this?
--
Bernardo Donadio
DevOps Engineer at Alligo Tecnologia
https://bcdonadio.com/
First, can you please send this to the list next time, queries about
general things can help others, and others can answer other than me.
I've cc:ed the list on my response for reference of others.
> I just saw your article in Fedora Magazine. Brilliant to have Fedora 25 on
> Raspberry PI 2 and 3 !!! Thanks a lot !!!
>
> I hope we will see a Raspberry Pi 4 with more RAM(2 GB or 4 GB) and
> Ethernet 10/100/1000, to make a cluster !!!
It won't happen, adds too much cost and it doesn't further their
cause. Even just usb3 probably adds $3-4 to the cost. If you want that
go and buy any one of numerous other devices out there. There's quite
a few devices out there that are much better than the Pi for
clustering, even some of the Orange Pi devices have more RAM,
dedicated gb ethernet and 3 independent usb buses while costing
similar price.
> Not so many Linux boards supported by Fedora. Can we hope to see a Fedora
We support well over 100 different ARM devices, not sure you're
definition of "not so many" but maybe that's different to mine.
> 25 release for the Odroid C2 board, a nice cheap board with 2GB of RAM and Ethernet 10/100/1000 ? see
> http://rglinuxtech.com/ for some tries/tests.
No, we support devices when they're upstream in the upstream kernel.
There's a lot of basic support on this board that's no where near
upstream like MMC, there might be enough in the 4.10 kernel which
means we should be able to support it in Fedora 26.
Peter
Hello Everyone,
I have successfully installed Fedora 24 with onto a RPI3 with Kraxel's kit. I also installed X and tried to set the default state of the machine to graphical.target using systemd. I also have xrdp installed. I can easily and successfully RDP across to the machine and use LXDE.
When I try to use it at the machine itself, there is not X environment firing up. I have the following errors in dmesg:
[ 24.367279] vc4-drm soc:gpu: failed to allocate buffer with size 9216000
[ 24.374196] vc4-drm soc:gpu: failed to allocate buffer with size 9216000
[ 24.384452] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[ 24.391416] [drm] num bos allocated: 4
[ 24.395243] [drm] size bos allocated: 18320kb
[ 24.399678] [drm] num bos used: 3
[ 24.403056] [drm] size bos used: 9320kb
[ 24.406966] [drm] num bos cached: 1
[ 24.410509] [drm] size bos cached: 9000kb
[ 29.921963] vc4-drm soc:gpu: failed to allocate buffer with size 9216000
[ 29.928816] vc4-drm soc:gpu: failed to allocate buffer with size 9216000
[ 29.943051] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[ 29.950043] [drm] num bos allocated: 4
[ 29.953873] [drm] size bos allocated: 18320kb
[ 29.964561] [drm] num bos used: 3
[ 29.967904] [drm] size bos used: 9320kb
[ 29.971816] [drm] num bos cached: 1
[ 29.975355] [drm] size bos cached: 9000kb
[ 35.616982] vc4-drm soc:gpu: failed to allocate buffer with size 9216000
[ 35.623766] vc4-drm soc:gpu: failed to allocate buffer with size 9216000
[ 35.630569] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[ 35.637485] [drm] num bos allocated: 4
[ 35.641260] [drm] size bos allocated: 18320kb
[ 35.645636] [drm] num bos used: 3
[ 35.648967] [drm] size bos used: 9320kb
[ 35.652810] [drm] num bos cached: 1
[ 35.656310] [drm] size bos cached: 9000kb
[ 41.741442] vc4-drm soc:gpu: failed to allocate buffer with size 9216000
[ 41.750538] vc4-drm soc:gpu: failed to allocate buffer with size 9216000
[ 41.764316] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[ 41.777405] [drm] num bos allocated: 4
[ 41.787267] [drm] size bos allocated: 18320kb
[ 41.796928] [drm] num bos used: 3
[ 41.806312] [drm] size bos used: 9320kb
[ 41.815661] [drm] num bos cached: 1
[ 41.822454] [drm] size bos cached: 9000kb
[ 47.842983] vc4-drm soc:gpu: failed to allocate buffer with size 9216000
[ 47.849963] vc4-drm soc:gpu: failed to allocate buffer with size 9216000
[ 47.856894] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[ 47.864245] [drm] num bos allocated: 4
[ 47.868063] [drm] size bos allocated: 18320kb
[ 47.872487] [drm] num bos used: 3
[ 47.875855] [drm] size bos used: 9320kb
[ 47.879709] [drm] num bos cached: 1
[ 47.883285] [drm] size bos cached: 9000kb
[ 53.606989] vc4-drm soc:gpu: failed to allocate buffer with size 9216000
[ 53.613819] vc4-drm soc:gpu: failed to allocate buffer with size 9216000
[ 53.620666] [drm:vc4_bo_create [vc4]] *ERROR* Failed to allocate from CMA:
[ 53.627631] [drm] num bos allocated: 4
[ 53.631427] [drm] size bos allocated: 18320kb
[ 53.635826] [drm] num bos used: 3
[ 53.639176] [drm] size bos used: 9320kb
[ 53.643048] [drm] num bos cached: 1
[ 53.646566] [drm] size bos cached: 9000kb
My config.txt looks as follows:
arm_freq=1200
core_freq=400
sdram_freq=500
over_voltage=6
gpu_mem=256
max_usb_current=1
arm_control=0x200
# NOOBS Auto-generated Settings
hdmi_force_hotplug=1
config_hdmi_boost=4
overscan_left=24
overscan_right=24
overscan_top=16
overscan_bottom=16
disable_overscan=0
# workaround firmware issue for rpi3
# u-boot doesn't work without this
enable_uart=1
Would anybody have any thoughts on solving this issue. I know it may not be completely a Fedora problem especially since its not a Fedora team built kernel. But would still appreciate the help. Thanks/
Cheers,
ASD.
[https://ci3.googleusercontent.com/proxy/yRaxhwVs0q3BQNi_a1Q1V4QtzkrbV_dNQxB…]
Aly S Dharshi B.Sc. Computer Science, RHCE
Technology Strategist
m. 780 722 3461 t. 780 428 5226
e. aly(a)dharshi.ca<mailto:aly@dharshi.ca> w. alydharshi.com<https://esig.ly/links/170277>
[https://ci4.googleusercontent.com/proxy/bNQnZ_OAzT2pM5qYP8TRGjDT8kihT8yW500…]<https://esig.ly/links/170280> [https://ci3.googleusercontent.com/proxy/38s1JmBP0z2F4DpdEo85jKKdYRFGVDOxx9a…] <https://esig.ly/links/170282> [https://ci3.googleusercontent.com/proxy/xy6cM64ACsoEy6ESDSUswSl4Lc6JXIM6cRc…] <https://esig.ly/links/170304>
If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
[https://ci3.googleusercontent.com/proxy/u2GEyjAjMD9fAwfkyZGW5MsTRszpn0m46ih… before you print.
Hi,
I've tried to install Fedora on a few boards. As I've never did that
before, RTFM seemed like a good idea. Unfortunately, documentation seems
a little bit outdated.
1) arm-image-installer does not support --list-targets option, as
mentioned on the wiki
https://fedoraproject.org/wiki/Architectures/ARM/F25/Installation
I've fixed this one.
2) arm-image-installer points to wrong home
I was wandering if --list-targets was removed or a new thing that will
be present with next release, so I was curious about AII's home. From
rpm url I got to http://fedoraproject.org/wiki/Fedora_ARM_Installer
It is either different tool, or it was heavily modified. That page
mentions only Fedora 18 - 20. Sources should be on github which seems to
be old sources (last commit 3 years ago) and different than rpm uses. I
was finally able to find AII's sources at
https://pagure.io/arm-image-installer/
I guess wiki page should mention that it is about an abandonware of same
name and AII's url in rpm should point somewhere else
OR
That page should be updated to mention correct AII.
3) there should be SUPPORTED-BOARDS doc file as it is mentioned on some
places, but it's not included in the rpm, only rawhide has it
4) trac for Fedora ARM issues seems abandoned
Fedora ARM page https://fedoraproject.org/wiki/Architectures/ARM
in section Get involved with Fedora ARM mentions trac for arm issues at
https://fedorahosted.org/arm/ It seems abandoned as it has last visible
activity around 12/2014.
5) no meeting minutes recorded/archived
Wiki mentions meetins and has a link to meeting archive. On the archive
page https://fedoraproject.org/wiki/Architectures/ARM/Meetings/Archive/
, there are only meetings from 2012 and 2013.
Cheers
Michal Hlavinka