I've noticed that the omshell as shipped in the package is doing bad
things memory access wise...
$ valgrind /usr/bin/omshell
==735304== Memcheck, a memory error detector
==735304== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==735304== Using Valgrind-3.15.0 and LibVEX; rerun
Ah, of course - I should have noticed comment #8 myself, sorry...
Just booted with:
$ uname -a
Linux macchiatobin 5.0.0-25-generic #26-Ubuntu SMP Thu Aug 1 12:05:25 UTC 2019
aarch64 aarch64 aarch64 GNU/Linux
$ dpkg -S /boot/vmlinuz-5.0.0-25-generic
linux-image-5.0.0-25-generic:
Update and good news:
I've been reminded that the firmware I have can boot the platform with
either ACPI and Device Tree tables. I've been in ACPI mode and now,
after flipping to DT, the platform boots fine and all 4 interfaces (one
thing I haven't noticed that only one was completely missing
Good news:
The module is *definitely* built and loads fine. Thanks!
Bad news:
The driver has some issues... Full boot log attached, but first of all,
spot the delay:
...
[2.849454] mvpp2 MRVL0110:00 eth0: Using random mac address
ee:ad:f4:3c:ad:cf
...
[2.932894] mvpp2 MRVL0110:01
Can't really provide logs here... One thing I figured out in the
meantime is that the source package seems to be building it for armhf:
debian.master/config/config.common.ubuntu:CONFIG_MVPP2=m
debian.master/config/annotations:CONFIG_MVPP2
policy<{'armhf': 'm'}>
Public bug reported:
At least in Ubuntu 19.04, the arm64 kernel (linux-image-5.0.0) is not
building CONFIG_MVPP2 (depends on CONFIG_ARCH_MVEBU) - a driver for
network controllers(s) in Marvell SOCs, particularly Armada 8040 -
neither as a model or a built-in:
$ uname -m
aarch64
$ grep MVPP2
> [This is an automated message. I apologize if it reached you
> inappropriately; please just reply to this message indicating so.]
As far as I can say (even after reviewing the wiki page) there's no
relevant source package for that issue, not even the debian-installer
one, as the ISO images are
Public bug reported:
After downloading a 17.04 ubuntu-server image for ARM64:
http://cdimage.ubuntu.com/releases/17.04/release/ubuntu-17.04-server-
arm64.iso
and using it to create a USB drive with /usr/bin/usb-creator-gtk, I
can't boot the installer on my EFI-powered ARM64 machine, because the
Just checked and glad to see that http://ports.ubuntu.com/dists/xenial-
updates/main/installer-arm64/current/images/MANIFEST.udebs now shows
kernel-image-4.4.0-62-generic-di 4.4.0-62.83 with the driver in question
built.
--
You received this bug notification because you are a member of Ubuntu
** Description changed:
After upgrading from 14.04 LTS to 16.04 LTS, we noticed that LDAP-based
sudo roles stopped working, meaning users that were able to use sudo in
the past, are rejected now.
After investigation, it turned out to be a known upstream bug:
** Description changed:
After upgrading from 14.04 LTS to 16.04 LTS, we noticed that LDAP-based
sudo roles stopped working, meaning users that were able to use sudo in
the past, are rejected now.
After investigation, it turned out to be a known upstream bug:
Public bug reported:
After upgrading from 14.04 LTS to 16.04 LTS, we noticed that LDAP-based
sudo roles stopped working, meaning users that were able to use sudo in
the past, are rejected now.
After investigation, it turned out to be a known upstream bug:
Allow me to ask a polite and friendly question - can I count on the
installer being refreshed any time soon?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1643922
Title:
Network installer fails to
Apologies about the delay - I was away from the hardware for a couple of
days.
Just tested the netboot images from http://cdimage.ubuntu.com/ubuntu-
server/daily/current/zesty-server-arm64.iso and it works perfectly fine.
Glad to hear that the fix has been propagated into the new releases, but
I
** Description changed:
Kernel 4.4.0-31.50 used in the newest version of the network installer
for Xenial:
http://ports.ubuntu.com/dists/xenial-proposed/main/installer-
arm64/current/images/MANIFEST.udebs
does not contain amd-xgbe module. In result the installer fails to
Public bug reported:
Kernel 4.4.0-31.50 used in the newest version of the network installer
for Xenial:
http://ports.ubuntu.com/dists/xenial-proposed/main/installer-
arm64/current/images/MANIFEST.udebs
does not contain amd-xgbe module. In result the installer fails to
initialize eth0 and can
It may be the same issue as https://bugs.launchpad.net/linaro-landing-
team-freescale/+bug/893653/comments/6
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/843628
Title:
perf failure on panda
I'd just like to point out that the mentioned script:
1. Is missing esac at the end of the file
2. Must be made executable (sudo chmod +x 50_custom)
I'll do some testing during the next few days and report.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
This entry in syslog seems relevant (full suspend and resume log
attached):
Oct 29 18:55:01 rojo gnome-session[9054]: Gdk-WARNING: The program
'gnome-session' received an X Window System error.#012This probably
reflects a bug in the program.#012The error was 'XI_BadDevice (invalid
Device
** Description changed:
Could we have basic profiling tracing options enabled in Linaro
- vexpress kernel? I'd suggest:
+ kernel? I'd suggest:
+ CONFIG_HIGH_RES_TIMERS=y (for using hrtimers as a sampling clock)
+ CONFIG_LOCAL_TIMERS=y (for A9 targets, otherwise hrtimers don't work)
I just had a look at all the different kernels in https://launchpad.net
/~linaro-maintainers/+archive/kernel and the configurations are still
very different:
lt-mx5 mx5 vexpress omap lt-omap
HIGH_RES_TIMERS + + - + +
LOCAL_TIMERS
** Also affects: linaro-landing-team-ti
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/764796
Title:
Enable basic profiling tracing options in kernel
Ok, we have managed to fix the problem at the IO FPGA level. The updated
bitfile will be release on the next VE CD (end of this year), in the
meantime interested parties may contact ARM Support in order to get the
fix.
--
You received this bug notification because you are a member of Ubuntu
The lock up was caused by SMSC RX FIFO underruns caused by maginal
timing issue between SMSC and USB host controller. The hack is enforcing
additional wait cycle between accesses. Unfortunately it affects all
peripherals, thus the performance penalty.
What you observe is, I guess, situation when
Comments! and/or proper symbolic names for those magic numbers would
be good for a final patch, of course :)
I thought I made this clear - there will be no final patch :-)
The entity responsible for SMC configuration is Boot Monitor. This
patch is just a hack to confirm (or deny) my theory.
Could anyone give this patch a go? It's just a hack (if I'm right this
will have to go to Boot Monitor, not kernel), but it may improve
Ethernet stability, potentially at some cost of performance loss. Anyway
- let me know.
** Patch added: ve-eth.patch
I'm not aware of any problems like that. There used to be some problems
with FTRACE and some userspace tools, but it was mostly about symbol de-
mangling, so in other words it doesn't break anything else.
I've just spoken to Will Deacon and he has similar opinion, so yes - I'd
say let's enable
Public bug reported:
Could we have basic profiling tracing options enabled in Linaro
vexpress kernel? I'd suggest:
CONFIG_PROFILING=y
CONFIG_PERF_EVENTS=y
CONFIG_HW_PERF_EVENTS=y
CONFIG_FTRACE=y
CONFIG_ENABLE_DEFAULT_TRACERS=y
CONFIG_HIGH_RES_TIMERS=y
(the last one allows using hrtimers as a
As said above it rather looks like the SMP problems in the smsc driver.
Now, frankly speaking, I totally forgot about this issue, and it looks
that I won't have chance to look into it in the nearest time. But, as we
have ARM Landing Team now (allegedly ;-) maybe this bug should be
assigned to
The problem will be worked around by extending the MMC FIFO size. This
will be available in the coming VE CD release. A patch will be required
on non-mainline kernels to support it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This patch adds support for MMCI with extended FIFO size. Kernels prior
to 2.6.37 will also need backported commit
8301bb68c6bb9836889641a47443aeb97b763f6c ARM: 6310/1: mmci: support
different FIFO sizes (will attach it to this bug).
** Patch added: [PATCH] arm: mmci: Add ARM variant with
This is a backport of 8301bb68c6bb9836889641a47443aeb97b763f6c commit
in the main line tree.
** Patch added: ARM: 6310/1: mmci: support different FIFO sizes
Have a look at this patch...
** Patch added: 0001-arm-Improve-MMC-performance-on-Versatile-Express.patch
https://bugs.launchpad.net/ubuntu/+source/linux-linaro/+bug/632798/+attachment/1801527/+files/0001-arm-Improve-MMC-performance-on-Versatile-Express.patch
--
You received this bug
Hack it is, without doubts ;-) I've already sent it upstream anyway,
we'll see...
Now, a word of comment:
At least some of the Linaro file system images are running irqbalance
daemon, which will most likely play with MMC and USB interrupts
affiliation in runtime. To prevent it from doing so,
Well, I feel it will end on my desk anyway ;-)
I can't commit to any dates right now, but I've put this on my list and
let you keep you informed. Of course I'll have to reproduce it here...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
It may be even worse - I have some reports that with recent changes in
L2 handling, all hell breaks loose during MMC operations. I'll start
investigating this next week.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I did some further investigations...
1. MMC access are generally terribly slow - 45-50 kB/s writes, 60-65
kB/s reads. Expected value at least in hundreds kB/s - normal cards have
maximum throughput at least 1 MB/s, premium cards up to 5-10 MB/s!
2. USB accesses performed at the same time as MMC
Public bug reported:
Ubuntu 7.10, file /usr/share/i18n/locales/pl_PL, line 215:
d_fmt
U0025U002DU0064U0020U0025U0062U0020U0025U0059
This data format definition gives:
$ LC_ALL=pl_PL.UTF8 locale -k d_fmt
d_fmt=%-d %b %Y
Minus sign is wrong here, isn't it? A symptom of this problem is (among
Sorry, I have misspelled... My laptop is Asus A2H (more precisely
A2500H)
--
Wrong events for ASUS L3000D
https://launchpad.net/bugs/25784
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
39 matches
Mail list logo
