Patch posted upstream which should hopefully fix this:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00118.html
--
[armel] unrecognizable insn with -mthumb
https://bugs.launchpad.net/bugs/490466
You received this bug notification because you are a member of Ubuntu
Server Team, which is
Appears fixed in fixed in 4.4.2-5ubuntu1
--
[armel] unrecognizable insn with -mthumb
https://bugs.launchpad.net/bugs/490466
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to mysql-dfsg-5.1 in ubuntu.
--
Ubuntu-server-bugs mailing list
The initramfs image is an optionally gzipped cpio archive (which must
have been built with cpio --format=newc in order for the kernel to
recognise it --- note this is not the default behaviour for cpio). The
filesystem is unpacked into a ramfs or similar, so there is no special
size restriction.
This bug either wasn't fixed or there has been a recent regression.
Ubuntu lucid
openssh-server 1:5.3p1-3ubuntu1
/etc/default/ssh: SSHD_OOM_ADJUST=-17
As well as causing kernel panics, a malicious user can use this
technique to kill off trusted root daemons and (if they use a port =
1024)
To confirm, sshd's child processes do indeed inherit the oom_adjust
setting.
--
hardy: openssh-server oom_adj can lead to denial of service
https://bugs.launchpad.net/bugs/293000
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openssh in
By the way, arm-ports-ubuntu is a mirror of ports.ubuntu.com. I have checked
that this is up to date.
In any case, the problem described in this bug report has been happening for
some time.
--
xterm (actually all Xt clients) does not run
https://bugs.launchpad.net/bugs/343574
You received
This happens within GDM, in a raw X server, and also over remote X to a
Cygwin/X server.
So it looks more like some issue with the X clients or Xt, rather than
an X-server specific issue or an issue specific to running a particular
kind of session...
--
xterm (actually all Xt clients) does not
Public bug reported:
Binary package hint: xterm
The traditional X clients do not run, probably due to a configuration
issue, but I haven't managed to identify why. The applications print an
error message and terminate, they do not crash, but are nonetheless
unusable. These days, xterm is
Sample X session errors attached.
At least one other guy on my side has seen the problem... it would be
interesting to know whether anyone else can reproduce it.
** Attachment added: X session errors (note, there is some extra spam in the
log due to the limited functionality of the Xnest I ran
I enabled IPv6 support in the kernel just to see whether there's a difference...
This removes the ICE errors from the log, but otherwise there no change. Oh
well, it was a long shot :(
--
xterm (actually all Xt clients) does not run
https://bugs.launchpad.net/bugs/343574
You received this bug
Found a possibly relevant thread - sounds like there could be issues between
some Xt functionality and shared libraries.
However, I don't understand the detail, and it's possible these issues do not
apply to ELF platforms.
http://www.cygwin.com/ml/cygwin-xfree/2003-10/msg0.html
--
xterm
Public bug reported:
The current description (in linux-meta_2.6.28.11.11) is Versatile-based
systems systems Linux kernel image.
It should probably read Linux kernel image for version 2.6.28 on i.MX51-based
systems (matching the linux-image-2.6*-imx51 package).
Also, the one-line description
Public bug reported:
Binary package hint: upstart
I don't have a way to reliably reproduce this behaviour, but it seems to
happen on average once every 1-2 days of uptime. Once respawning stops,
I have not found a way to restart it except by running telinit (either
specifying the same runlevel
Hmmm, on closer inspection you seem to be right. Apologies for the
confusion.
$ cat /proc/1/wchan
do_select
I assumed that this was evidence that pselect was being used, since on
ARM, select is currently used to implement pselect. However, now I've
taken a look at the upstart source code, it
Could there be an atomic update problem with signals_caught? Just a
thought... it looks like a signal could come in in the middle of
checking/clearing signals_caught. I'm not sure whether this problem
really exists though, without spending longer trying to understand the
code.
Thinking about it, you're right... signals_caught[signum]++ is not
atomic, but it probably does not matter because no code other than the
handler for another signal (i.e., different signum) can run in the
middle of a signal handler.
[ Aside: just to clarify why the increment is not atomic:
Note that epoll_pwait is also affected (fairly easy to spot in
asm/unistd.h)
I may have now experienced an occurrence of this race bug: namely, init
stopped respawning terminal logins for no obvious reason. init was
definitely waiting in select, but unfortunately I accidentally rebooted
the
** Attachment added: CoreDump.gz
http://launchpadlibrarian.net/23725043/CoreDump.gz
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/23725044/Dependencies.txt
** Attachment added: Disassembly.txt
http://launchpadlibrarian.net/23725045/Disassembly.txt
** Attachment
I've been taking a look at package lists and the dependencies of key
apps and libraries. The following look worth investigating with respect
to VFP optimisations:
I haven't tidied this list up fully, so there is a mix of binary and
source package names... I've done no benchmarking or profiling
Argh, tabs get entered in the thread as nbsp; --- if anyone finds that
last post hard to read, let me know and I'll repost it in a more
readable way.
--
armel gcc default optimisations
https://bugs.launchpad.net/bugs/303232
You received this bug notification because you are a member of Ubuntu
I was also having a chat with Catalin about an alternative way of making
VFP optimisations available.
I observed that Handhelds Mojo addresses architecture variants by having
special package servers which are placed at the start of the apt sources
list. See
Public bug reported:
Binary package hint: ubiquity
If the install bootloader option is cleared (in the advanced options
on the last page of the Ubiquity installer dialogs), it appears that no
/etc/flash-kernel.conf configuration file is generated for flash-kernel
to use.
However, the linux
** Attachment added: Verbose installer output (using ubiquity --debug)
http://launchpadlibrarian.net/25847608/installer-logs.tar.bz2
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/25847609/Dependencies.txt
** Attachment added: UbiquitySyslog.gz
** Attachment added: kernel-img.conf and flash-kernel.conf from default
install (bootloader installation enabled)
http://launchpadlibrarian.net/25872625/kernel-img-conf-bootloader-installed.tar.gz
--
On armel (Babbage platform), kernel image upgrading breaks if Ubiquity is
instructed not
Perhaps do_initrd should be no when not installing the bootloader?
** Attachment added: kernel-img.conf (bootloader installation not enabled in
ubiquity; no flash-kernel.conf is generated in this configuration)
I see; yes, that sounds plausible.
So it might make sense to remove the Recommends from linux-image-imx51
and install flash-kernel explicitly if the bootloader installation
option is enabled in ubiquity?
--
On armel (Babbage platform), kernel image upgrading breaks if Ubiquity is
instructed
Public bug reported:
Binary package hint: gcc-4.3
When building for the Thumb-2 instruction set, GCC appears to generate
Thumb2 loads and stores with invalid address offsets and base register
writeback. The Thumb-2 instruction set does not support the full offset
range for these instructions,
** Attachment added: Preprocessed C++ source which demonstrates the compiler
bug
http://launchpadlibrarian.net/24304416/asbug.c%2B%2B
--
GCC generates invalid instructions when building for Thumb-2 on armel
https://bugs.launchpad.net/bugs/347864
You received this bug notification because
Ed, what tools did you try again?
Cheers
---Dave
-Original Message-
From: boun...@canonical.com [mailto:boun...@canonical.com] On
Behalf Of Matthias Klose
Sent: 24 March 2009 12:43
To: Dave P Martin
Subject: [Bug 347864] Re: GCC generates invalid instructions
when building
Oops, disregard that last comment.
I will check up on what tools we've tried...
--
GCC generates invalid instructions when building for Thumb-2 on armel
https://bugs.launchpad.net/bugs/347864
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
It's a GCC bug, so we can disregard binutils (the assembler is correct in
rejecting the problem instruction).
It looks like the problem is that GCC is making bad assumptions about operand
ranges for some instructions passed to the assembler. Note that the generated
instruction would be OK when
Indeed... I've added some debug hacks to make sure that all signals are
masked except inside select(). But as you suggest, this doesn't resolve
the problem.
I also added some printfs, and I've managed to observe that when the
problem occurs, init wakes up out of select OK (suggesting a signal
Useful to know, thanks.
gcc-snapshot (4.4.0 20090225) appears not to produce the error.
It looks like the difference may be connected with the code GCC
generates for doubleword memory accesses in Thumb-2 code:
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00659.html
gcc-snapshot certainly makes
[See asbug_gcc-4.3.3-5ubuntu4.s and asbug_gcc-
snapshot_20090225-0ubuntu1.s]
** Attachment added: asbug_gcc-snapshot_20090225-0ubuntu1.s
http://launchpadlibrarian.net/24326841/asbug_gcc-snapshot_20090225-0ubuntu1.s
--
GCC generates invalid instructions when building for Thumb-2 on armel
Good spot...
Hmmm, yes it seems likely that this is the same issue... telinit u or kill 1
(same thing, I think) certainly causes the symptom to appear, and since I am
usually logging in via gdm or ssh (not getty) it is quite plausible that I may
not notice for many hours after a libc upgrade.
sidtant = distant (oops)
--
No further respawns after a telinit u
https://bugs.launchpad.net/bugs/348346
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Upgrading should only be necessary between nearby versions, so it
doesn't seem a problem to change/break the dump format now and again.
But I agree that it's significant work to set up such a dump/reload
mechanism if it doesn't exist yet.
When upgrading to a version of upstart which is too
I think it should always be possible to remount / read-only unless init or
other required processes hold some files open for write access.
I can't see why re-exec'ing init or not would make a difference to this; it
only affects when the inodes of the old libc are harvested; that's down to
I've tested the modified libc from http://people.ubuntu.com/~lool/glibc-
neon/, on kernels both with and without the CONFIG_NEON enabled.
The libc hwcap setup for NEON appears to work fine.
I put some dummy libraries in /lib and /lib/neon and wrote a simple test
program:
* using a kernel with
Ah, right.
I had a prod, and I understand what's going on a bit better now---
you're right, upgrading libc (or indeed any libs) will prevent read-only
remount of the affected filesystems until the processes using the old
libraries die or re-exec.
I couldn't work out why this happened, but is
Public bug reported:
Binary package hint: xubuntu-artwork
With no accelerated SVG implementation for ARM at present, this is
causing a delay of about 1 minute between gdm startup and displaying a
login box on an 800 MHz ARMv7 platform. This at least doubles the time
from boot to a login prompt
Sounds OK as a solution--- the time taken to resample a large PNG down
seems much less of an issue than the time taken to render SVG.
--
Use of SVG backdrop by default causes extremely slow gdm startup on armel
https://bugs.launchpad.net/bugs/351588
You received this bug notification because you
** Tags added: armv7
--
fails to build on armel/lucid
https://bugs.launchpad.net/bugs/503185
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Hi
[...] It would seem that ARMv7 no longer includes swp/swpne
instructions. It's relatively trivial to conditionally
replace this with appropriate ldrex/strex instructions
See https://wiki.ubuntu.com/ARM/Thumb2 for a bit more background on
this. ARMv7 still supports SWP, but it's
** Changed in: gcc-4.4 (Ubuntu)
Status: Fix Released = Confirmed
--
[armel] Atomic intrinsics are not implemented correctly
https://bugs.launchpad.net/bugs/491872
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
Unfortunately, the __sync_synchronize() bug appears still to be present in the
updated GCC.
A call to this intrinsic still disappears in the compiler's output.
The __sync_lock_test_and_set() bug may still be present; however it is
also possible that the __sync_synchronize() bug is masking the
-mimplicit-it=thumb does now seem to be passed correctly to the
assembler, though:
$ echo 'void f(void) { asm volatile(moveq r0, #1); }' | gcc -c -o
tmp.o -xc - objdump -d tmp.o
f:
...
4: bf08it eq
6: 2001moveq r0, #1
--
[armel] Atomic
Public bug reported:
Binary package hint: squashfs-tools
mksquashfs.c currently accesses the following structures through
misaligned pointers: at least the following:
squashfs_base_inode_header *
squashfs_dir_entry *
squashfs_dir_header *
squashfs_dir_inode_header *
squashfs_ldir_inode_header *
Public bug reported:
Some inline assembler in libmad uses some instruction operand
combinations (specifically the RSB isntruction) which are not permitted
in Thumb-2, causing a build failure.
See the following:
http://linux.onarm.com/bugzilla/show_bug?id=36
patch:
Note that the referenced patch should be upstreamed in the meantime, but
it is not upstream yet.
--
Inline assembler fix needed for libmad in Lucid on armel
https://bugs.launchpad.net/bugs/489242
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Looks like a patch was already done for the ARM Linux Internet Platform
(see http://linux.onarm.com/bugzilla/show_bug?id=36)
patch: http://linux.onarm.com/bugzilla/attachment.cgi?id=5
I'm currently trying to do a build with this patch.
Generally, I'm also assuming that
Note: the above patch is not upstream yet, but should get upstreamed in
the meantime.
It would be good to pull this into Ubuntu now though, if possible.
--
NS_InvokeByIndex in xptcinvoke_arm.cpp is not Thumb-2 safe for Lucid
https://bugs.launchpad.net/bugs/488354
You received this bug
** Description changed:
Binary package hint: xulrunner-1.9.1
Either this file should be built individually as ARM code using -marm,
or the code needs to be reviewed and modified to be Thumb-2 safe.
Specifically, calling a function using:
- mov lr, pc
-
Got a build and tested it against lucid firefox-3.5.
I didn't appear to get any problems (I'm reporting this bug using the Thumb-2
xulrunner library).
Attached is a gdb session transcript, where I set a breakpoint on the
NS_InvokeByIndex implementation: the code is definitely Thumb-2, as can be
See also the following spec from UDS:
https://wiki.ubuntu.com/Mobile/ARMv7AndThumb
--
Pass -mimplicit-it=thumb to as by default on in lucid armel
https://bugs.launchpad.net/bugs/488302
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Public bug reported:
Problem noted in: qt4-x11_4.6.0~rc1-1ubuntu1 (lucid)
There are two problems here:
1) in configure, the build architecture baseline is detected using
`uname -r`: this just gives armel, which does not work for determining
whether the baseline is armv6 or armv7 or whatever.
** Changed in: xulrunner-1.9.1 (Ubuntu)
Assignee: (unassigned) = Alexander Sack (asac)
--
NS_InvokeByIndex in xptcinvoke_arm.cpp is not Thumb-2 safe for Lucid
https://bugs.launchpad.net/bugs/488354
You received this bug notification because you are a member of Ubuntu
Bugs, which is
** Attachment added: qt4-x11.tar.gz
http://launchpadlibrarian.net/36261080/qt4-x11.tar.gz
--
GCC internal error (unrecognizable insn ...) building qt4-x11 for Thumb-2 on
armel
https://bugs.launchpad.net/bugs/490391
You received this bug notification because you are a member of Ubuntu
Bugs,
Public bug reported:
Binary package hint: gcc-4.4
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu lucid (development branch)
Release:10.04
Codename: lucid
$ uname -r
2.6.31-105-imx51
Architecture: armel
gcc-4.4 4.4.2-3ubuntu1 (lucid)
This might be a duplicate of https://bugs.launchpad.net/bugs/490466
--
GCC internal error (unrecognizable insn ...) building qt4-x11 for Thumb-2 on
armel
https://bugs.launchpad.net/bugs/490391
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Public bug reported:
Binary package hint: xulrunner-1.9.1
The problem here is that the nanojit output tries to call functions in
xulrunner using plain BL instructions, causing the CPU to interpret the
called (Thumb-2) code as ARM... which doesn't work.
The symptoms are random SIGILLs and
** Changed in: xulrunner-1.9.1 (Ubuntu)
Assignee: (unassigned) = Alexander Sack (asac)
--
ARM/Thumb interworking support missing from nanojit
https://bugs.launchpad.net/bugs/490792
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
** Description changed:
Binary package hint: xulrunner-1.9.1
- Either this file should be built individually as ARM code using -marm,
- or the code needs to be reviewed and modified to be Thumb-2 safe.
+ Two issues:
+
+ 1) Either this file should be built individually as ARM code using
+
** Tags added: armv7
--
boehm-gc build failure on armel with -mthumb
https://bugs.launchpad.net/bugs/475644
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
** Tags added: armel armv7
--
assembly fails to build on armel/lucid
https://bugs.launchpad.net/bugs/491342
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
[Added the armv7 tag to help track ARMv7 migration issues.]
Agreed, the best way to solve cases like this is to use the GCC
intrinsics instead of inline asm.
The attached patch should hopefully work for this; but I haven't been
able to build or test it just yet.
I've tried to modify configure
Patch posted upstream which should hopefully fix this:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00118.html
--
[armel] unrecognizable insn with -mthumb
https://bugs.launchpad.net/bugs/490466
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Patch posted upstream which should hopefully fix this:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00118.html
--
GCC internal error (unrecognizable insn ...) building qt4-x11 for Thumb-2 on
armel
https://bugs.launchpad.net/bugs/490391
You received this bug notification because you are a
util-linux 2.16-1ubuntu5 seems to have a similar problem, using gcc-4.4
4.4.2-3ubuntu1. See the attached patch and script to reproduce.
** Attachment added: preprocessed source and compile command to reproduce
duplicate label bug in util-linux-2.16
As with with Matthias' bug, -marm causes the problem to disappear.
-O1 also causes the problem to disappear.
--
[armel] duplicate label created with current gcc-4.4
https://bugs.launchpad.net/bugs/490440
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I got a good build, but it's not quite right... the __sync_synchronize()
calls compile away to nothing, which is not what's intended.
For now, the package builds and should run fine on uniprocessor
platforms, so this should unblock you, but I'll provide an additional
patch shortly once I've
Public bug reported:
Binary package hint: gcc-4.4
Observed in gcc 4.4.2-3ubuntu1
Believed to affect all versions
__sync_synchronnize() should perform a memory barrier, but is a noop (at least
with -O2)
__sync_lock_release() should place a memory barrier before the compare-exchange
operation,
** Description changed:
latest glib upload failed to build in lucid:
12:52 asac
https://edge.launchpad.net/ubuntu/+source/glib2.0/2.23.0-1ubuntu1/+build/1374402
- 12:53 asac libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I/build/buildd/glib2.0-2.23.0/glib -I..
I expect to be able to post a patch soon; it may be simplest to leave
this unfixed until then.
--
[armel] Atomic intrinsics are not implemented correctly
https://bugs.launchpad.net/bugs/491872
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This patch should fix the issue with __sync_lock_release():
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00198.html
The __sync_synchronize() is not fixed by this— another patch should
follow soon.
--
[armel] Atomic intrinsics are not implemented correctly
https://bugs.launchpad.net/bugs/491872
This patch should fix the __sync_synchronize() issue, by making sure GCC does
not optimise away the call to the libgcc function which implements this:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00600.html
These should now be fixed on the GCC trunk and await backporting to the
upstream 4.4
This patch converts to a cleaner and slightly more efficient
implementation, avoiding the need for the explcit __sync_synchronize()
in atomic_spinlock_release()
This patch should apply on top of the patch stack in debian/patches,
assuming that patch attached above has already been merged.
Note
Thanks for this.
My build failed, but I think this may be due to some autoconf version
mismatch or similar, or incorrect versions of some build dependency.
However, a .so was build successfully and looks correct (notwithstanding
the missing __sync_synchronize() calls resulting from
What about mvl? Could there be a kernel version issue here?
--
tst-eintr1 test failure, when built with current gcc-4.4 4.4.2-3ubuntu1
defaulting to -mthumb
https://bugs.launchpad.net/bugs/492336
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
FIx confirmed in fixed in 4.4.2-5ubuntu1
--
[armel] Atomic intrinsics are not implemented correctly
https://bugs.launchpad.net/bugs/491872
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Thanks!
--
[armel] Atomic intrinsics are not implemented correctly
https://bugs.launchpad.net/bugs/491872
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Appears fixed in fixed in 4.4.2-5ubuntu1
--
[armel] unrecognizable insn with -mthumb
https://bugs.launchpad.net/bugs/490466
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
Can you send me a coredump?
Checking the kernel sources for mvl, the required alignment fixup support
appears to be present, so it looks like the problem is not caused by missing
patches:
linux/arch/arm/mm/alignment.c:639:
/*
* Convert Thumb-2 32 bit LDM, STM, LDRD, STRD to equivalent
^ Note, that was 2.6.31-701.2
--
Alignment trap/Unhandled fault errors on boot
https://bugs.launchpad.net/bugs/494831
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
The most recent relevant change now appears to be from 11 Nov:
http://git.videolan.org/?p=x264.git;a=commit;h=b28d98bbc3174e6f38caea49a7c545204e3930d3
(Fix 10l in weightp on ARM)
Can the relevant updates be pulled in for lucid?
Note that x264 doesn't appear to have any runtime detection for
** Description changed:
Binary package hint: squashfs-tools
mksquashfs.c currently accesses the following structures through
misaligned pointers: at least the following:
squashfs_base_inode_header *
squashfs_dir_entry *
squashfs_dir_header *
squashfs_dir_inode_header *
I tried experimentally buiding this package for -marm, and this seems to
solve the SIGILLs on 2.6.28 kernels.
Running mksquash and unsquash on /etc now works without SIGILL, for
example.
--
[armel] non-ISO-C misaligned pointer punning causes slowness and SIGILLs
For individual packages which are already hand-optimised, we would not
expect much improvement from re-doing the code in Thumb-2, so switching
to -marm makes sense here--- I suggest to go ahead and change it.
--
ffmpeg should be built with -marm for lucid on armel
See this bug for details of our current understanding on these SIGILLs:
https://bugs.launchpad.net/ubuntu/+source/squashfs/+bug/494667
What is the kernel version currently in use on the Marvell boards? If
it's already 2.6.31 I would not expect to be having this problem— the
imx51 buildds
This adds a conditional in the Makefile to use -marm when
DEB_BUILD_ARCH_CPU is arm, which does for arm as suggested by
David Martin. The lucid version of squashfs was still debian
upstream. I am not sure if we wish to push this back to
debian at all, or even if we later want to address this
In my case, I did not do anything explicit to provoke this error -- it
happened by itself after the desktop session started when booting a live
image.
I'll try to provide some more information if I see it again, but I don't
know how to reproduce the problem reliably.
--
jockey crashed during
I had to to a reinstall, since I had fixed the problem in the meantime
:/
Anyway, after reinstalling, here are the results I get:
$ grep ^X /etc/default/console-setup
XKBMODEL=pc105
XKBLAYOUT=gb
XKBVARIANT=
XKBOPTINOS=
$ gconftool -R /desktop/gnome/peripherals/keyboard/kbd
layouts = [us]
Unfortunately, Valgrind is not available for armel at this time.
--
gnome-panel crashed with SIGSEGV in gdk_window_impl_x11_get_colormap()
https://bugs.launchpad.net/bugs/461912
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
This is using auto-login. I didn't select anything explicitly, so I was
expecting the system default to be used.
Maybe there is something wrong with the initial user's preferences are
initialised during installation?
I currently have a reinstall under way; I'll try to answer the other
points
When logging in explicitly though GDM on the first boot after
installation, the keyboard layout option at the login screen defaults
correctly to UK, and I get UK keyboard layout after login.
If I then restart gdm so that auto-login happens again, I get UK layout
in the desktop session again, so
I did a brief test of your build, Loïc— seems to work OK on a NEON-enabled
platform.
I didn't test exhaustively, but at least MPEG2 and H.264 (mp4) appear to work
well. I couldn't test audio because there's some other problem with my test
platform.
I haven't successfully played any
I did a brief test of your build, Loïc— seems to work OK on a NEON-enabled
platform.
I didn't test exhaustively, but at least MPEG2 and H.264 (mp4) appear to work
well. I couldn't test audio because there's some other problem with my test
platform.
I haven't successfully played any
Extra note: I do get a good speedup when playing video using ffplay,
when using the NEON libraries versus the standard (VFP) libraries.
I don't have quantative benchmarks right now.
--
Integrate and enable ARMv5TE/v6/VFP and NEON optimisations from ffmpeg trunk
for armel
** Attachment added: Dependencies.txt
http://launchpadlibrarian.net/33654515/Dependencies.txt
--
If pam policy requires the default user's password to be changed, gdm hangs,
never reaching a login box or the desktop
https://bugs.launchpad.net/bugs/451285
You received this bug notification
Public bug reported:
Binary package hint: gdm
If pam policy requires the default user's password to be changed when
gdm starts up, gdm hangs... never reaching a login box or the desktop
This issue was observed in http://cdimages.ubuntu.com/ports/daily-
1 - 100 of 522 matches
Mail list logo
