Re: Raspberry Pi 3 B+ dmesg errors
by Peter Robinson
Hi Felix,
Sorry for the late delay, some how this message hit my spam box.
> I managed to get Fedora 30 AARCH64 installed on a RPI 3B+ and it mostly runs great but I'm hitting a couple issues that I'm just not sure where to start looking.
>
> In order to make sure it's not the set of packages I'm installing, I brought up a second RPI 3B+ that runs the official minimal image. I installed all the same packages on the kicked system, that the minimal version has, so I don't have differences.
What doe you mean by "official minimal image"? Do you mean Fedora or Rasbian?
> 1. The NIC LED doesn't work after the installation. It works normally during kickstart. Connectivity is not affected. NIC LED works fine with the official image.
> 2. I get these messages in dmesg on a kicked system that are not poping up on the minimal image system:
> ...
> [ 0.000000] CPU features: detected: Kernel page table isolation (KPTI)
> ...
> [ 0.011655] arch_timer: WARNING: Invalid trigger for IRQ75, assuming level low
> [ 0.011658] arch_timer: WARNING: Please fix your firmware
> ...
> [ 1.887602] kvm [1]: Invalid trigger for vtimer IRQ76, assuming level low
Most of those can be ignored. In part it might depend on the answer to
the question above.
> 3. Looks like the model that is being detected is different for both systems (where does that come from? Does that have effects somewhere?):
> Minimal image:
> [ 0.000000] Machine model: Raspberry Pi 3 Model B+
>
> Kickstart:
> [ 0.000000] Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
That message comes from the DT if it's provided by the firmware, which
would also explain some of the differences above.
> 4. The kickstarted system has an additional CPU feature that the minimal image system doesn't have (They should have the same CPU?)
> [ 0.000000] CPU features: detected: Kernel page table isolation (KPTI)
Is there a kernel version difference?
> 5. There is a couple more differences like hci initialization and other things. Isn't this part of the kernel support? And the kernel is the same on both systems.
What does "uname -a" report? I suspect the difference here is the use
of the firmware provided DT vs kernel provided.
Do you have a symlink if you do a "ls -al /boot/dtb/" in both systems?
> Is there documentation around the generation of the RPI image? I replicated the kickstart file that can be found under /root on the minimal image but that alone didn't help above issues. Maybe there is something special about the environment this image is generated in?
>
> Thanks
> _______________________________________________
> arm mailing list -- arm(a)lists.fedoraproject.org
> To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
4 years, 11 months
Re: F-30 Raspberry Pi 3B+ MMC/MicroSD sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware interrupt.
by Peter Robinson
On Fri, Jun 21, 2019 at 12:48 PM Jan Kratochvil
<jan.kratochvil(a)redhat.com> wrote:
>
> Hi,
>
> just copying from:
> https://bugzilla.redhat.com/show_bug.cgi?id=1607872#c8
>
> On Raspberry Pi 3B+ when I boot from MicroSD from USB adapter all works fine.
> When I use the same MicroSD into the MicroSD slot of Raspberry it boots fine
> and when it should be display text login prompt it prints:
>
> [ 70.246299] sdhost-bcm2835 3f202000.mmc: timeout waiting for hardware interrupt.
>
> And it is mostly dead (it pings but no sshd works anymore, NumLock works but no login prompt etc.).
> Raspbian boots fine there even directly from MicroSD.
What make/model of mSD card are you using, I've seen it reported but
never seen it myseld.
> kernel-5.1.11-300.fc30.aarch64
> kernel-5.2.0-0.rc3.git3.1.fc31.aarch64
>
> I see nowhere on this list mentioned this problem, really nobody is using
> MicroSD directly?
I primarily use mSD cards directly, I currently have 12 RPi of
different models from the RPi2, original 3 (a couple of gens), the
3B+, 3A+ and even a CM3 based device running various Fedora images on
both aarch64 and ARMv7 with no issues. I use two types of card, either
Sandisk Ultra or Samsung EVO.
Also it's possible under powered PSUs might cause something like this,
I've had reports of issues with SD cards that have gone away with
different PSUs, what is the rating of your PSU?
4 years, 11 months
Re: Fedora 29 64 bit - Raspberry Pi 3 - rngd
by Peter Robinson
Hi,
Comments below.
> Using Fedora 29 on Raspberry Pi 3 I seem to have a problem using rndg:
>
> uname -a
> Linux replica.blabla.bla 4.18.16-300.fc29.aarch64 #1 SMP Sat Oct 20 23:12:22 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux
> cat /etc/redhat-release
> Fedora release 29 (Twenty Nine)
>
> rngd is running:
> ps -ef | grep rng
> root 4710 4409 13 10:57 pts/1 00:00:47 rngd -f -r /dev/hwrng -o /dev/random
>
> The module to support bcm2835 hardware is loaded:
> lsmod | grep rng
> bcm2835_rng 16384 0
>
> However, rng is painfully slow:
>
> time rngtest -c 10 < /dev/random
> rngtest 6
> Copyright (c) 2004 by Henrique de Moraes Holschuh
> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 200032
> rngtest: FIPS 140-2 successes: 10
> rngtest: FIPS 140-2 failures: 0
> rngtest: FIPS 140-2(2001-10-10) Monobit: 0
> rngtest: FIPS 140-2(2001-10-10) Poker: 0
> rngtest: FIPS 140-2(2001-10-10) Runs: 0
> rngtest: FIPS 140-2(2001-10-10) Long run: 0
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=2.201; avg=5.458; max=380.585)Kibits/s
> rngtest: FIPS tests speed: (min=28.132; avg=28.328; max=28.468)Mibits/s
> rngtest: Program run time: 35792670 microseconds
>
> real 0m35.801s
> user 0m0.001s
> sys 0m0.071s
>
>
> Running CentOS 7.5 on an older Raspberry Pi 2 will do much much faster:
>
> ps -ef | grep rngd
> root 14024 1 1 10:54 ? 00:00:14 /sbin/rngd -f -r /dev/hwrng -o /dev/random
>
>
> time rngtest -c 10 < /dev/random
> rngtest 5
> Copyright (c) 2004 by Henrique de Moraes Holschuh
> This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 200032
> rngtest: FIPS 140-2 successes: 10
> rngtest: FIPS 140-2 failures: 0
> rngtest: FIPS 140-2(2001-10-10) Monobit: 0
> rngtest: FIPS 140-2(2001-10-10) Poker: 0
> rngtest: FIPS 140-2(2001-10-10) Runs: 0
> rngtest: FIPS 140-2(2001-10-10) Long run: 0
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=135.793; avg=166.586; max=191.200)Kibits/s
> rngtest: FIPS tests speed: (min=22.076; avg=22.243; max=22.334)Mibits/s
> rngtest: Program run time: 1181718 microseconds
>
> real 0m1.192s
> user 0m0.002s
> sys 0m0.141s
>
> Whatś happening here? It seems like the bcm2835_rng is not picked up; despite the module is loaded.
So running the above test on my RPi3 with ARMv7 (so 32 bit mode) I see
the following output that it detects and is using the HW RNG:
# rngd -l
Entropy sources that are available but disabled
4: NIST Network Entropy Beacon
Available and enabled entropy sources:
0: Hardware RNG Device
5: JITTER Entropy generator
And the test is running faster for me than your one on CentOS:
# time rngtest -c 10 < /dev/random
rngtest 6
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. There
is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
rngtest: starting FIPS tests...
rngtest: bits received from input: 200032
rngtest: FIPS 140-2 successes: 10
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.430; avg=6.029; max=444.518)Kibits/s
rngtest: FIPS tests speed: (min=51.690; avg=53.941; max=54.967)Mibits/s
rngtest: Program run time: 32397649 microseconds
real 0m32.408s
user 0m0.004s
sys 0m0.056s
I wonder if this is an issue with aarch64, the CentOS image on the
RPi2 is obviously ARMv7, could you test a Fedora 29 ARMv7 image on the
Raspberry Pi 3 to see if that might be the issue?
Peter
5 years, 6 months
Re: Wiki claims RPi 4 is not supported
by Peter Robinson
>> I just restarted my fedora-arm system on raspberry pi 4 after days of using another system and found that the sound does in fact work (I shut off all devices but my bluetooth speaker in the pavucontrol configuration window -- misconfiguration in pavucontrol likely was the reason I could not get audio to work before).
>>
>> So I would say that the mainline fedora-ARM aarch64 kernel is functioning pretty well on my system: video works well as does audio, all usb ports work (usb 2 and 3) and I am able to start up on an SSD with no problem. Wifi and bluetooth have been functional out of the box.
Well bluetooth is an interesting choice as it definitely has issues
because there's not an upstream firmware so it sort of works but has a
lot of issues. If it works for you great
>> The system does take about two minute to boot up. I am using openbox with full xorg capability.
Well I'm not sure what you mean by "full xorg capability" in this
context as it will be non accelerated which is probably OK for
something as basic as openbox but for the desktops that the other
99.9% use such as GNOME/KDE/XFCE it's really not a great experience.
>> It seems that there is a good case for stating that raspberry pi 4B is supported by the fedora-ARM 64 bit kernel (aarch64) on the Fedora-ARM wiki. Now perhaps things don't work as well on a Fedora Workstation which is very bloated -- I don't know but I do know that on a less demanding system (like openbox), everything seems to be running well.
I completely disagree, you don't provide a strong case at all, it's
not even on a mainstream desktop environment, it's one that's probably
0.1% of the Fedora RPi user community.
For starters there's no accelerated graphics upstream, as stated a
number of times before. The person who was working on that stopped
because the device would lock up randomly due to power state
transitions and the details of that isn't public so needs someone from
the RPi foundation to provide the right information. I think that
request is outstanding 6+ months now.
We have a regression upstream with booting systems headless[1]
probably one of the biggest RPi usecases in Fedora.
And we've even has issues with booting them in the lead up to F-35
Beta and while we now have a work around the RPi foundation team can't
even agree whether their firmware works or regresses [2].
And that just 3 examples of why I, as the maintainer of the Raspberry
Pi in Fedora, don't think it's not in a state where we can state
support for the Raspberry Pi 4 in Fedora. Frankly with some of the
recent regressions and the lack of interest from RPi to actually
support general purpose distributions I am strongly reconsidering the
support status of all generations of the Raspberry Pi.
I've been the maintainer of the RPi since we started supporting it in
Fedora 25, and was involved in the entire process right from the
outset and having hate actual hate mail and actual physical threats
over this device I am well aware of what state we need the device to
be in before I make that change in the wiki or anywhere else.
If you wish to take over the maintainer-ship I will gladly step aside!
Peter
[1] https://www.spinics.net/lists/arm-kernel/msg922125.html
[2] https://github.com/raspberrypi/firmware/issues/1619#issuecomment-925982112
2 years, 8 months
Re: Booting Fedora 25 from USB attached disk on Raspberry Pi
by Peter Robinson
On Fri, Dec 16, 2016 at 11:02 AM, <peter(a)pindsle.com> wrote:
> Hi,
>
> As I've finally managed to get Fedora 25 booting from a USB attached HDD on a Raspberry Pi (2B) and I wasn't really able to it documented anywhere I'd like to document some of the things I found before I forget.
>
> As the official Fedora support is so new, I haven't seen much discussion, so not really sure who to tell ... The Raspberry Pi page on the Fedora Wiki pointed me here.
>
> The steps I used were very much the same as any of the guides for booting Raspbian from a USB HDD, but a couple of things I had to learn the hard way with Fedora:
>
> 1. The boot menu is extlinux and is configured from /boot/extlinux/extlinux.conf. This is where you need to set your root partition to point to the USB HDD partition. This may seem obvious, but considering there is cmdline.txt, /boot/grub/grub.conf and this to choose from it took a little time to figure.
>
> 2. The USB controller requires the dwc2 kernel module. This is not included in the default dracut image. It took me many hours to find this but once I rebuilt the image to include this module everything sprung to life.
> For reference I used the following configuration:
> /etc/dracut.conf.d/add-dwc2.conf
> add_drivers+="dwc2"
>
> I hope this is useful to someone and if anyone has suggestions for where to post it, fire away.
>
> Lastly, it seems like a good idea to include the dwc2 module in dracut by default. Considering there are a bunch of other USB modules included (which I think can't do anything useful without the controller being initialised), it seems like an oversight not to include it. What would be the best place to request this?
We already include all usb host drivers, it seems though that dwc2
(and 3) sit elsewhere in the tree because they obviously feel they're
a precious snowflake. Already on my list to review.
7 years, 4 months
Re: Possible Hangups on Raspberry Pi with FC25 Server
by Peter Robinson
> Am 31. Januar 2017 00:19:01 MEZ schrieb Peter Robinson
> <pbrobinson(a)gmail.com>:
>>On Mon, Jan 30, 2017 at 9:03 PM, Alexander Petrenz
>><petrenz.a(a)gmail.com> wrote:
>>> Hi all,
>>>
>>> since I wasn´t able to find out what´s causing those crashes I moved
>>to
>>> raspian and since then the Pi (it was a Gen 3, Model B) is running
>>without
>>> any hickups. So in the end I´m sure, the issue was software related.
>>
>>Yes little surprise there, unless it's PSU and we're not as power
>>optimised as Raspbian yet.
>>
>>In terms of software, other than the fact they're both Linux distros,
>>that link Raspbian and Fedora 25. Kernel, toolchain, their binary
>>display drivers etc are all different. We're all upstream and open,
>>it's not yet perfect but it's all open but we're not yet the most
>>power efficient.
>>
>
> Fedora might not be perfect if your doing client stuff and need display
> drivers. However it is really great if you need a small server, because it
> is the only maintained distro for the Raspian shipping SELinux by default!
In the case of the small server stuff I would be using the Fedora
Server (awesome web management UX) or minimal editions and not any
spin with a GUI as it'll give more resources to the server bits as GUI
desktops reserve memory for GPU processing. :-)
> Thanks for anything your doing Peter ;)
I knew F-25 wasn't perfect and that there would be teething issues but
then if the world waited on perfect there wouldn't be a release (or a
RPi). We've already shipped a number of perf improvements in the F-25
cycle with more to come and F-26 should be a decent bump up in all
respects there too.
Peter
>>> Alex
>>>
>>> On Fri, Jan 27, 2017 at 8:39 AM, Winfried de Heiden <wdh(a)dds.nl>
>>wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Since a couple of days I'm hit by hangups as well :( Hard to trace
>>since
>>>> the Raspberry Pi 3 does nit react to keyboard, network etc. anymore
>>and the
>>>> HDMI monitor goes black.... However, yesterday I was able to take a
>>photo
>>>> before the screen goes black: Kernel Panic ... Fatal exception in
>>interrupt;
>>>> screen shot attached!
>>>>
>>>> This raspberry Pi has been running for weeks without problems on
>>Fedora 25
>>>> using the same power.
>>>>
>>>> Hmmm, any sugestions on this?
>>>>
>>>> Winfried
>>>>
>>>>
>>>> -----Oorspronkelijke bericht-----
>>>>
>>>> Datum: Thu, 26 Jan 2017 15:13:26 +0100
>>>> Onderwerp: [fedora-arm] Re: Possible Hangups on Raspberry Pi with
>>FC25
>>>> Server
>>>> Aan: arm(a)lists.fedoraproject.org
>>>> Van: Alexander Petrenz <petrenz.a(a)gmail.com>
>>>>
>>>> _______________________________________________
>>>> arm mailing list -- arm(a)lists.fedoraproject.org
>>>> To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
>>>
>>>
>>>
>>> _______________________________________________
>>> arm mailing list -- arm(a)lists.fedoraproject.org
>>> To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
>>>
>>_______________________________________________
>>arm mailing list -- arm(a)lists.fedoraproject.org
>>To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
>
> --
> Mit freundlichen Grüßen
> Daniel Laczi
> _______________________________________________
> arm mailing list -- arm(a)lists.fedoraproject.org
> To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
>
7 years, 4 months
Re: Unable to see 'Initial setup wizard' on Raspberry PI 3 using aarch64 images
by Ashwin Rao
On Wed, Nov 22, 2017 at 11:46 AM, Peter Robinson <pbrobinson(a)gmail.com>
wrote:
> On Wed, Nov 22, 2017 at 9:37 AM, Ashwin Rao <ashwin.shirvanthe(a)gmail.com>
> wrote:
> > Hi,
> >
> > When running the aarch64 Workstation, Server, and Minimal images I am
> not able to see the initial setup wizard. I can see the messages shown
> during boot but after some time the screen either starts to flicker or
> just blanks out. I tried this on 3 different raspberry Pis with different
> cards and the result is always the same.
> > The steps I followed are
> > 1. I downloaded the aarch64 images from [ https://fedoraproject.org/
> wiki/Architectures/ARM/Raspberry_Pi#Raspberry_Pi_3_aarch64_support ] and
> followed the instructions mentioned on the same web page to prepare the
> images using xzcat.
> > 2. I connect the HDMI cable of my monitor, and connect the keyboard and
> mouse. I am not connecting an Ethernet cable.
> > 3. I can see the boot screen, and the messages showing that the device
> is booting.
> > 4. After some time the screen either blanks out or starts to flicker. I
> have tried it with different monitors and different power supplies as well
> but the result is the same. I noticed that the red LED of the Raspberry Pi
> also starts to blink abruptly.
> >
> > I am able to use Raspbian and OpenSuse using the same Raspberry Pis so I
> doubt there is an issue with the card, the power supply, or with the Pis.
> >
> > It would be nice if someone suggests the things I need to do, or if
> someone was able to troubleshoot similar issues.
>
> The problem is with either the monitor or the HDMI cable, the VC4 open
> driver (which neither of the other distros use yet) can be a bit
> fragile with some EDID responses from some monitors or cables (yes
> we've had people with issues that were fixed when they swapped the
> HDMI cable). It's improved a lot since F-25 when we first started
> supporting the RPi but it's not perfect yet.
>
> On the case of Server and Minimal if you never want to use a graphical
> interface and are happy with just the text console you can add a
> blacklist so the GPU driver isn't laoded on boot. This can be done by
> adding blacklist=vc4 to the kernel command line or creating a file
> /etc/modprobe.conf/vc4.conf with the line "blacklist vc4"
>
> Thank you for the suggestion. I currently do not need the graphical
interface, so I tried again with the Server image.
Adding module_blacklist=vc4 instead of blacklist=vc4 to the kernel command
line allowed me to get to the login prompt.
-- Ashwin
6 years, 6 months
Re: Possible Hangups on Raspberry Pi with FC25 Server
by petrenz.a＠gmail.com
Hi,
the Pi is a 3 Model B. The output of the PSU says 5.1V and 2.5A. Is that
enough? Also I don't have any further storage connected. For sharing I'm
using some space of the 15G card where the OS is installed on.
On Thu, Jan 26, 2017 at 9:26 AM, Peter Robinson <pbrobinson(a)gmail.com>
wrote:
> On Wed, Jan 25, 2017 at 9:39 PM, <petrenz.a(a)gmail.com> wrote:
> > Hello,
> >
> > I recently bought a Raspberry Pi and I want to use it as a small server.
> I installed FC25 on it. The only additional piece of hardware is a
> bluetooth keyboard/mouse device, which is connected via usb dongle. On the
> software side I only installed a samba server and opened the related ports
> with a firewall command.
> > This installation is working and I can access the shared folder. However
> after a while - it differs - the server isn't available anymore. No ping is
> possible, also there is no HDMI signal anymore - the only thing I can do is
> restart it. I'm keeping the software up to date, but that doesn't solve the
> problem.
> > So what I would like to ask is, if there are known stability issues? Or
> is there something I can check and maybe fix? Maybe I could provide some
> details (not sure what - log doesn't tell anything usefull) to track down
> any issue.
>
> There's no known issues I've seen running it from a Server PoV but
> there's some common issues. Do you have the storage for the share on a
> USB HDD or is it just sharing space on the SD card? What model of RPi
> is it and what is the amp rating on the power supply. The most common
> issue is caused by a PSU that's not strong enough.
>
7 years, 4 months
Re: Prevent Raspberry Pi U-Boot from listening to UART?
by Jeffrey Ollie
On Mon, Jul 23, 2018 at 2:50 AM, Peter Robinson <pbrobinson(a)gmail.com>
wrote:
> On Mon, Jul 23, 2018 at 4:44 AM, Eric Smith <spacewar(a)gmail.com> wrote:
> > I'm trying to use Fedora 28 Minimal on a Raspberry Pi 3 to set up an NTP
> > server using a GPS hat, specifically intended for this purpose:
> >
>
> Yes, so it seems like the GPS is probably trying to send data which is
> in turn interrupting the boot process.
>
I had the same problem (except I was using the Adafruit version), and my
only solution at the time was to switch back to Raspbian. The GPS starts
sending data over the UART as soon as it is powered up so there's really no
chance for the user to do anything. Barring some sort of hardware/software
changes on the GPS HAT that would prevent it from sending data over the
UART until it got a signal from the Pi I think that U-Boot will need to be
changed so that it ignores the UART.
--
Jeff Ollie
The majestik møøse is one of the mäni interesting furry animals in Sweden.
5 years, 10 months