HD messages?
by Robert Moskowitz
This is on a Cubieboard2
with Fedora-Xfce-armhfp-29-20180911.n.0-sda image on the HD and only
uboot on the uSD.
System booted up as expected. GUI setup occured and Xfce started. Then
on console I started seeing HD related messages. Are these drive
errors, and I need to get a new drive for testing or some other sort of
messages?
[ 824.049554] ata1.00: failed command: READ FPDMA QUEUED
[ 824.054798] ata1.00: cmd 60/20:60:10:ab:34/00:00:00:00:00/40 tag 12
ncq dma 16384 in
[ 824.054798] res 40/00:84:50:ab:34/00:00:00:00:00/40 Emask
0x10 (ATA bus error)
[ 824.070574] ata1.00: status: { DRDY }
[ 824.074287] ata1.00: failed command: READ FPDMA QUEUED
[ 824.079495] ata1.00: cmd 60/08:68:00:ab:34/00:00:00:00:00/40 tag 13
ncq dma 4096 in
[ 824.079495] res 40/00:84:50:ab:34/00:00:00:00:00/40 Emask
0x10 (ATA bus error)
[ 824.095220] ata1.00: status: { DRDY }
[ 824.098928] ata1.00: failed command: READ FPDMA QUEUED
[ 824.104134] ata1.00: cmd 60/10:70:e8:aa:34/00:00:00:00:00/40 tag 14
ncq dma 8192 in
[ 824.104134] res 40/00:84:50:ab:34/00:00:00:00:00/40 Emask
0x10 (ATA bus error)
[ 824.119808] ata1.00: status: { DRDY }
[ 824.123520] ata1.00: failed command: READ FPDMA QUEUED
[ 824.128725] ata1.00: cmd 60/38:78:00:32:31/00:00:00:00:00/40 tag 15
ncq dma 28672 in
[ 824.128725] res 40/00:84:50:ab:34/00:00:00:00:00/40 Emask
0x10 (ATA bus error)
[ 824.144503] ata1.00: status: { DRDY }
[ 824.148234] ata1.00: failed command: READ FPDMA QUEUED
[ 824.153440] ata1.00: cmd 60/48:80:50:ab:34/00:00:00:00:00/40 tag 16
ncq dma 36864 in
[ 824.153440] res 40/00:84:50:ab:34/00:00:00:00:00/40 Emask
0x10 (ATA bus error)
[ 824.169219] ata1.00: status: { DRDY }
[ 824.172947] ata1: hard resetting link
[ 824.486151] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 824.539710] ata1.00: configured for UDMA/33
[ 824.544114] ata1: EH complete
[ 824.577421] ata1.00: exception Emask 0x10 SAct 0x2 SErr 0x280100
action 0x6 frozen
[ 824.585177] ata1.00: irq_stat 0x08000000, interface fatal error
[ 824.591239] ata1: SError: { UnrecovData 10B8B BadCRC }
[ 824.596429] ata1.00: failed command: READ FPDMA QUEUED
[ 824.601605] ata1.00: cmd 60/48:08:50:ab:34/00:00:00:00:00/40 tag 1
ncq dma 36864 in
[ 824.601605] res 40/00:2c:10:ab:34/00:00:00:00:00/40 Emask
0x10 (ATA bus error)
[ 824.617259] ata1.00: status: { DRDY }
[ 824.620962] ata1: hard resetting link
[ 824.937794] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 824.994304] ata1.00: failed to set xfermode (err_mask=0x100)
[ 830.196474] ata1: hard resetting link
[ 830.509657] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 830.560362] ata1.00: configured for UDMA/33
[ 830.564657] ata1: EH complete
5 years, 6 months
Fedora 28 with the "grate-driver" for (older) Tegra
by Nicolas Chauvet
Hi,
FYI I've recently compiled a set of packages (1) from the grate-driver
project (2).
In short, this FLOSS driver allows to enable video acceleration with
vdpau on older tegra soc.
There is also a very basic mesa driver, but it only advertise opengl
1.4 and gles 2.0 (probably not really conformant even). At least it
doesn't crash with glxgears.
There is support up to Tegra114, Tegra K1 may comes later using the
same framework.
Please reminds that for later SOC (Tegra K1+), f29 will have a better
support. There mesa has tegra/nouveau mesa drivers that will operate.
(not tested recently).
Mini FAQ:
- Why not upstream ?
There is an ABI destaging process in progress for tegra in the Linux
kernel. Once done, it will be probably possible to have more changes
upstream. Unfortunately, this is a long process and the review queue
in Tegra is growing.
- How to enable video hw acceleration ?
Look at the grate-driver page for libvdpau-tegra for the doc
You will need the mesa libdrm libvdpau-tegra xorg-x11-drv-opentegra
packages from the (2) repos. These replace fedora ones. You can keep
the fedora kernel. Please verify to have about cma=128M.
(1) - https://repos.fedorapeople.org/kwizart/ac100/
(2) - https://github.com/grate-driver/
--
-
Nicolas (kwizart)
5 years, 6 months
Fedora 29 new U-Boot/arm-trusted-firmware and Raspberry Pi firmware heads up
by Peter Robinson
Hi All,
There's a new update headed to testing for Fedora 29. It makes some
adjustments to how we handle a few things, in particular the Raspberry
Pi firmware:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-56bc88dfb2
I don't expect anyone to see anything issues in particular especially
for the vast majority of people that just use a SD card or HDD with
their ARM device but there might be some corner cases for people with
slightly more esoteric setups when they upgrade. If anyone sees any
issues please open a bug [1] or reply to this or reach out on
#fedora-arm. The change has been in rawhide for a little while and
I've not seen any fall out there.
Also the new U-Boot will have some slight improvements for those
running AllWinner 64 bit devices as we've moved to the upstream ARM
trusted firmware. It's just a snapshot at the moment but the previous
fork was quite old and had it's issues on certain devices so I expect
this to be an overall win for people there, but again I can't test
everything so if anyone sees issues please reach out.
All please add karma to the above update when you do test it. People
can update U-Boot on a running system with the update-uboot command
with similar syntax to arm-image-installer.
Peter
[1] https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=29&compo...
5 years, 6 months
failure with vncserver on F29 Xfce
by Robert Moskowitz
This is on my patched Xfce system. Patched in the sense that a dnf
update got a good version of lightdm so that Xfce will run....
I am now working on VNCserver. I did the following:
systemctl set-default multi-user.target
yum install tigervnc-server
Went to my user id and ran vncpasswd
cp /lib/systemd/system/vncserver@.service
/etc/systemd/system/vncserver@:1.service
Then replaced all <USER> with my userid
systemctl enable vncserver@:1
firewall-cmd --add-port=5901/tcp --permanent
Then rebooted.
Tried to connecting to my IP addr, port 5901 and got connection
refused. Did some checking:
# systemctl status vncserver@:1
● vncserver@:1.service - Remote desktop service (VNC)
Loaded: loaded (/etc/systemd/system/vncserver@:1.service; enabled;
vendor pr>
Active: failed (Result: timeout) since Wed 2018-09-05 11:35:32 EDT;
6min ago
Process: 838 ExecStart=/usr/bin/vncserver -autokill :1 (code=exited,
status=0>
Process: 794 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill :1 >
/dev/null >
Jun 22 11:12:53 localhost com.redhat.imsettings[889]: [
1529680373.692927]: IMS>
Jun 22 11:12:53 localhost com.redhat.imsettings[889]: Exiting...
Jun 22 11:12:53 localhost org.gtk.vfs.Daemon[889]: A connection to the
bus can'>
Jun 22 11:12:53 localhost com.redhat.imsettings[889]: [
1529680373.721087]: GLi>
Jun 22 11:12:53 localhost com.redhat.imsettings[889]: [
1529680373.735105]: GLi>
Jun 22 11:12:53 localhost com.redhat.imsettings[889]: [
1529680373.741316]: IMS>
Jun 22 11:12:53 localhost com.redhat.imsettings[889]: [
1529680373.742310]: IMS>
Sep 05 11:35:32 localhost systemd[1]: vncserver@:1.service: Start
operation tim>
Sep 05 11:35:32 localhost systemd[1]: vncserver@:1.service: Failed with
result >
Sep 05 11:35:32 localhost systemd[1]: Failed to start Remote desktop
service (V>
and
# cat /home/rgm/.vnc/localhost\:1.log
Xvnc TigerVNC 1.9.0 - built Aug 1 2018 10:25:26
Copyright (C) 1999-2018 TigerVNC Team and many others (see README.rst)
See http://www.tigervnc.org for information on TigerVNC.
Underlying X server release 12000000, The X.Org Foundation
Fri Jun 22 11:12:45 2018
vncext: VNC extension running!
vncext: Listening for VNC connections on all interface(s), port 5901
vncext: created VNC server for screen 0
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning: Unsupported high keycode 372 for name <I372> ignored
> X11 cannot support keycodes above 255.
> This warning only shows for the first high keycode.
Errors from xkbcomp are not fatal to the X server
Failed to import environment: Process org.freedesktop.systemd1 exited
with status 1
Killing Xvnc process ID 859
Fri Jun 22 11:12:53 2018
ComparingUpdateTracker: 0 pixels in / 0 pixels out
ComparingUpdateTracker: (1:nan ratio)
What am I doing wrong? The above worked with Centos7-arm Gnome system.
thanks
5 years, 6 months
Re: Fwd: [Bug 1624972] New: No GUI desktop
by Peter Robinson
On Mon, 3 Sep 2018, 19:57 Robert Moskowitz, <rgm(a)htt-consult.com> wrote:
> OK. I see after I created the bug, there was a field called 'Blocks'
> which I entered ARMTracker into. I did not see this when I was entering
> the bug.
>
It's mostly definitely there in the new bug page
On 09/03/2018 02:51 PM, Peter Robinson wrote:
>
> Blocker field
>
> On Mon, 3 Sep 2018, 19:40 Robert Moskowitz, <rgm(a)htt-consult.com> wrote:
>
>> I don't see how to link this to ARMTracker...
>>
>>
>>
>>
>> -------- Forwarded Message --------
>> Subject: [Bug 1624972] New: No GUI desktop
>> Date: Mon, 03 Sep 2018 18:36:45 +0000
>> From: bugzilla(a)redhat.com
>> To: rgm(a)htt-consult.com
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1624972
>>
>> Bug ID: 1624972
>> Summary: No GUI desktop
>> Product: Fedora
>> Version: 29
>> Component: xfce4-session
>> Severity: high
>> Assignee: kevin(a)scrye.com
>> Reporter: rgm(a)htt-consult.com
>> QA Contact: extras-qa(a)fedoraproject.org
>> CC: kevin(a)scrye.com, nonamedotc(a)gmail.com
>>
>>
>>
>> Description of problem:
>>
>> The Xfce desktop never starts. Lighted screen only
>>
>> Version-Release number of selected component (if applicable):
>>
>> Fedora-Xfce-armhfp-29-20180903.n.0-sda on Cubieboard2
>>
>> How reproducible:
>>
>> Been this way since I started testing F29-Xfce
>>
>> Steps to Reproduce:
>> 1. Copy image to uSD card, specifying for a Cubieboard2
>> 2. Connect Cubie to HDMI monitor, Kybd, Mouse, console TTY
>> 3. Run screen on console to capture console log and login to console
>> 4. Power up Cubie
>> 5. "Started GSSAPI Proxy Daemon" is the last message on console and monitor
>> before attempt to switch to GUI mode
>>
>> Actual results:
>>
>> Lighted screen with no response to kybd or mouse
>> See:
>>
>> [ 148.658848] alloc_contig_range: [74200, 749f8) PFNs busy
>> [ 165.979868] bridge: filtering via arp/ip/ip6tables is no longer available by
>> [ 173.413278] alloc_contig_range: [74200, 74af8) PFNs busy
>> [ 430.058044] alloc_contig_range: [74200, 74500) PFNs busy
>>
>> messages on console. Console is very slow to respond.
>>
>> Expected results:
>>
>> GUI starts up and whatever system initiation process runs on the Desktop. I do
>> not know what that will be, as I have yet to get a F29 initial desktop.
>>
>> Additional info:
>>
>> The same setup with Centos Gnome:
>>
>> CentOS-Userland-7-armv7hl-generic-GNOME-1804-sda
>>
>> Brings up the Gnome desktop. I have not tried any other F29 desktop.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>>
>> _______________________________________________
>> 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
>>
>
>
5 years, 6 months
Help testing suspend on arm
by Nicolas Chauvet
Hi there,
While testing upstream kernel on some devices, I've recently
discovered that suspend was broken for "distro kernel" (not only
related to fedora kernel, but also ubuntu).
I order to debug this, I was advised to use a serial console and boot
with theses options:
no_console_suspend=1 initcall_debug
Then using systemctl suspend outputs this report for me:
https://bugzilla.redhat.com/show_bug.cgi?id=1619699
Basically, I'm running a tegra device, but a pxa driver (unrelated to
the device) lead to a crash preventing suspend.
I would like others on this list to try to report such use case, I
don't expect pxa_gpio to be the only driver to have issue in the
fedora config. Specially as it does not have problem at boot time or
shutdown so this problem might remains silent.
Please don't forget to block ARMTracker on bugzilla.redhat.com, and
mention it there if you uses upstream bug tracker.
Thx for any report.
--
-
Nicolas (kwizart)
5 years, 6 months
Fwd: [Bug 1624972] New: No GUI desktop
by Robert Moskowitz
I don't see how to link this to ARMTracker...
-------- Forwarded Message --------
Subject: [Bug 1624972] New: No GUI desktop
Date: Mon, 03 Sep 2018 18:36:45 +0000
From: bugzilla(a)redhat.com
To: rgm(a)htt-consult.com
https://bugzilla.redhat.com/show_bug.cgi?id=1624972
Bug ID: 1624972
Summary: No GUI desktop
Product: Fedora
Version: 29
Component: xfce4-session
Severity: high
Assignee: kevin(a)scrye.com
Reporter: rgm(a)htt-consult.com
QA Contact: extras-qa(a)fedoraproject.org
CC: kevin(a)scrye.com, nonamedotc(a)gmail.com
Description of problem:
The Xfce desktop never starts. Lighted screen only
Version-Release number of selected component (if applicable):
Fedora-Xfce-armhfp-29-20180903.n.0-sda on Cubieboard2
How reproducible:
Been this way since I started testing F29-Xfce
Steps to Reproduce:
1. Copy image to uSD card, specifying for a Cubieboard2
2. Connect Cubie to HDMI monitor, Kybd, Mouse, console TTY
3. Run screen on console to capture console log and login to console
4. Power up Cubie
5. "Started GSSAPI Proxy Daemon" is the last message on console and monitor
before attempt to switch to GUI mode
Actual results:
Lighted screen with no response to kybd or mouse
See:
[ 148.658848] alloc_contig_range: [74200, 749f8) PFNs busy
[ 165.979868] bridge: filtering via arp/ip/ip6tables is no longer available by
[ 173.413278] alloc_contig_range: [74200, 74af8) PFNs busy
[ 430.058044] alloc_contig_range: [74200, 74500) PFNs busy
messages on console. Console is very slow to respond.
Expected results:
GUI starts up and whatever system initiation process runs on the Desktop. I do
not know what that will be, as I have yet to get a F29 initial desktop.
Additional info:
The same setup with Centos Gnome:
CentOS-Userland-7-armv7hl-generic-GNOME-1804-sda
Brings up the Gnome desktop. I have not tried any other F29 desktop.
--
You are receiving this mail because:
You reported the bug.
5 years, 6 months