I've been using Fedora armv7 on my pandaboard since the F15 bootstrap,
now I'm running full F17 except for kernel. By the time I tried to
follow kernel releases in primary (even F16 ones), which have been
working perfectly until 3.2.
The last working (usable for desktop) kernel is 3.1.9-1.fc16. With this
one, I've been able to run LXDE, XFCE, KDE & also Gnome 3 fallback at
reasonable speed (I'm really using XFCE desktop right now). You can find
builds & source at http://mtoman.fedorapeople.org/arm/ - ignore dist
tag, I've rebuilt recently because I lost the original RPMs. If I
remember correctly, the only change to the original is disabled FTMAC100.
After updating to kernel 3.2, the video driver got broken. In 3.2.3, all
video output is sent to hdmi at 640x480 resolution regardless to kernel
cmdline (I'm using dvi at 1280x720). No oops messages appear.
In 3.2.6, the video does not work at all, but there is a periodically
repeating omapfb oops in syslog. The system itself still runs, can be
accessed via SSH or used as webserver, just the video is out.
After updating to 3.3, the system does not boot at all (tried all 3.3.0,
3.3.1, 3.3.2). Disabling audit doesn't help. Here are logs from two latest:
In addition, I've never seen audio working on panda, even though some
people say it used to.
Are these panda-specific issues, or are they at least known? Or am I
doing something wrong?
Note: I've only been building for omap.
As we get closer to having 100% package coverage in F17-ARM we're
running into harder build failures due to the limitations of the chips
we're building for. The problem I've noticed on many of the recent
failures is due to the lack of atomic operations (These didn't arrive
until ARMv6). How do we want to handle this? I see a few options:
1. Abandon armv5 and move to armv6 where some of the operations we need
are available. This will still support the raspberry pi- what about
2. Excludearch armv5tel from the affected packages since they'll never
3. Accept that these packages simply won't be available to 32 bit Fedora
systems (this is the result of inaction).
4. Pretend operations are atomic when they are not.
5. Create magic patch that implements atomic operations through software.
Would appreciate feedback, especially if one of these options is a
terrible idea that would impact you or the way you use Fedora adversely.
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
On Sun, Apr 22, 2012 at 12:06 PM, Mitchell Seaton <mseaton(a)ekindling.org> wrote:
> Hi all,
> Deployed os8 to XO 1 and XO 1.5 here, and fine installs, although for some
> reason on the XO 1 on first reboot, had large mem consumption on startup
> 8000k left available - on restart we're back to normal 58,000k free alloc.
> on startup. Failed to see what taking up so much there was nothing actively
> taking all the memory - I had opened the My Settings panel from the frame
> when the freeze occurred in Sugar, didn't seem to be anything of interest in
> dmesg - one-off occurrance at this stage.
Would be interested to know exactly how you measured this.
> 1.5, all seems fine did have a issue coming back up from power standby
> state, that took a long while to come back (that seems also to be one-off),
> running on battery.
This probably logged something to dmesg. If this happens again, please
capture the output.
Thanks a lot for testing!
The "I know you can be overwhelmed, and you can be underwhelmed, but
can you ever just be whelmed? " release.
THIS IS A DEVELOPMENT RELEASE
Some notable details in this release are:
* Move back to jffs to XO-1
* May be issues with WPA-Enterprise networks (F-17 final blocker):
#11750 Flickering in Browse/epiphany in os5
#11782 Sometimes two icons are shown in the frame for the network
#11721 No frame key or Journal key on os5
#11710 os4: hostname is none
#11404 support absolute input devices
#11778 libertas_sdio isn't allowed to communicate with card during suspend
#11722 No touchscreen input on XO-1.75
#11746 12.1.0 XO-1; kernel support for SDcards
#11714 GNOME fails to start if the system time is off
#11735 oprofile, perf available for/in build
#10075 long uptime with constant wakeups fills /var/log and crashes machine