** Attachment added: "Render of http://www.yahoo.com/";
http://launchpadlibrarian.net/33031408/firefox-1.png
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/33031409/Dependencies.txt
--
Firefox inappropriately adds scroll bars to many frames and images
https://bugs.l
** Tags removed: armel
--
Boot does not continue after exiting maintenance shell after mountall failure
https://bugs.launchpad.net/bugs/440709
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
Public bug reported:
Binary package hint: usplash
When upstart drops to a maintenance shell after a mountall failure,
usplash just sits on the screen, preventing proper interaction with the
maintenance shell. From the user's POV, the platform appears to hang.
usplash should probably disappear in
** Attachment added: "karmic-desktop-armel+imx51_daily-live_20090930.log.gz"
http://launchpadlibrarian.net/32871403/karmic-desktop-armel%2Bimx51_daily-live_20090930.log.gz
--
Boot does not continue after exiting maintenance shell after mountall failure
https://bugs.launchpad.net/bugs/440709
Public bug reported:
Binary package hint: upstart
This might be related to https://bugs.launchpad.net/bugs/121585
I hit this problem on armel; I don't know whether it is platform
specific.
Boot logs and the output of init -v are attached. (At the end of the
log, the platform is just hanging, w
Also note: the above problems were observed on armel.
The problems could be armel-specific, but this is not obviously the case
from the symptoms above.
--
/sbin/reload service management binary missing?
https://bugs.launchpad.net/bugs/435252
You received this bug notification because you are a m
Note: the above results were observed trying to install ubuntu-minimal
on a filesystem created with debootstrap --variant=minbase.
However, installing ubuntu-minimal doesn't seem to add the missing
binaries either (or create links etc.)
If I symlink /sbin/reload and /sbin/force-reload to /sbin/re
Public bug reported:
Binary package hint: upstart
On Karmic, it looks like there is supposed to be a /sbin/reload binary
to reload daemon configuration, but it doesn't seem to exist. Other
similar binaries /sbin/{start,stop,restart} do exist:
# dpkg -S /sbin/{start,stop,restart}
> #34Oliver Grawert wrote 7 minutes ago:
>
> @dave: the original breakage sadly predates the switch to VFP by default
Shame :( I'll flag up the toolchain patches when I have them anyway,
but I guess they may not solve this problem with OOo.
> #35Loïc Minier wrote 40 se
I just heard about a possibly relevant issue. Although I don't have any
direct evidence that this is the cause, could this be related to the
interaction between exception handling and the switch to VFP? :
> > Codesourcery found and fixed a couple of bugs in glibc's longjmp
> > implementation whi
Thanks for having a go!
Did you apply the extra changes suggested by Mans too? I've not tried
applying those myself yet, but I'd expect them to apply cleanly.
FFT/[I]MDCT optimisations are likely to benefit a lot of codecs.
--
Integrate and enable ARMv5TE/v6/VFP and NEON optimisations from ffmp
Is any progress expected on merging these changes for Karmic?
--
Integrate and enable ARMv5TE/v6/VFP and NEON optimisations from ffmpeg trunk
for armel
https://bugs.launchpad.net/bugs/383240
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu
OK; I misunderstood your kernel maintenance process a bit here.
The wiki could be a good place to track things like this. Can you
advise me offline where to put it?
In the meantime, feel free to reject this bug.
--
On ARM platforms with write-allocate caches, I-cache may be populated with
gar
OK, that sounds reasonable; it's not an urgent issue anyway, just a
niggle.
--
conf: rc-sysinit requires mounted /proc
https://bugs.launchpad.net/bugs/426263
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ub
N.B., I meant: http://www.linux-arm.org/git/
(It's not so obvious how to find that from the front page...)
--
On ARM platforms with write-allocate caches, I-cache may be populated with
garbage after copy-on-write page duplication
https://bugs.launchpad.net/bugs/426280
You received this bug notif
We're currently working with ARM's kernel tree, see:
http://www.linux-arm.org/
To clarify my expectation: there's no direct benefit to your applying
this to your tree right now, since you don't support the affected
platforms yet; but it seemed worth flagging the issue up to you so
you're aware. It
** Description changed:
- This can affect systems with write-allocate caches. At the time of
- writing, this includes the following ARM implementations:
+ This can affect systems with write-allocate caches, causing random
+ segfaults etc. in user processes. At the time of writing, this includes
Public bug reported:
This can affect systems with write-allocate caches. At the time of
writing, this includes the following ARM implementations:
* ARM11MPCore
* ARM Cortex-A9
It may affect other vendors' implementations, but I have no information
on this.
The problem occurs typically o
Public bug reported:
Binary package hint: upstart
...so you get an error message, and booting into single-user mode won't work.
Of course, if Karmic filesystems are strictly not intended to work without an
initrd, this might not be considered a problem.
I believe that Jaunty may not be affected
** Description changed:
Binary package hint: x264
- This bug report is just a placeholder for now, since the relevant
- changes are net yet merged with x264 mainline.
+ The NEON optimisation work done by David Conrad is now committed to mainline:
+ git://git.videolan.org/x264.git
- The opt
Note: there still seem to be some outstanding concerns about the
robustness of the NEON code in 0.15.19, so we might want to wait for a
later version before turning it on. I don't have any further details on
this for now, but I'll add extra details if I get some useful
information.
--
Integrate
I've noticed that gnome-language-selector also fails if the initial
content of /etc/default/locale is
LANG="C"
That can happen in a manual install, since some people prefer to avoid
the heavyweight locales by default, but I don't think it would ever
affect a live image style install.
/usr/lib/py
Public bug reported:
Binary package hint: swfdec-mozilla
Specifically, I experience a problem playing video from YouTube;
however, I haven't seen video work from any site. I tried both
firefox-3.0 and firefox-3.5.
As a consequence, there doesn't seem to be any working flash video
support out of
Hi again,
I think I now have a stable build, by pulling the following revisions
from svn://svn.ffmpeg.org/ffmpeg/trunk:
r18332
r18333
r18535
r18600
r18601
r18712
r18713
r18916
r18917
r18972
r19216
r19308
r19345
The attached patch enables the NEON build flavour and applicable build
options in deb
I've tried out your rebuilt package; there are a couple of minor
slowdowns against the current karmic pixman, but most things are a bit
faster and it looks like a general improvement. Some of these
differences are likely due to general modifications to pixman between
0.13.x and 0.15.19. Some things
Public bug reported:
Binary package hint: gdb
There is now an upstream patch available to support stepping in Thumb-2
code:
http://sourceware.org/ml/gdb-patches/2009-07/msg00683.html
This is a new patch and appears not to have been merged in Ubuntu yet
(as of 6.8.50.20090628-1ubuntu3)
Although
Public bug reported:
Binary package hint: binutils
We observed a serious problem in ld which inserted branches to incorrect
locations during link. This may be related to the Cortex-A8 thumb-2
branch alignment workaround. The problem occurred when building for
Thumb-2 (-march=armv7-a -mthumb) ---
Public bug reported:
Binary package hint: binutils
Affects: 2.19.51.20090622-0ubuntu1 (karmic)
Does not affect: 2.19.1-0ubuntu3 (jaunty)
An input file consisting of a single "b" character (with or without
newline) is sufficient to reproduce the error. However, "beq" also
works.
I haven't been
This bug may affect upstream, but I've not been able to check yet.
--
Branch instruction with no operand causes gas to segfault on armel
https://bugs.launchpad.net/bugs/396049
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bu
Will do— I think I now have a good patch set, but I want to check it
works. I'm currently doing a fresh build.
One other question Mans:
Because the baseline architecture used by the toolchain is
-march=armv5t, many of the NEON sources fail to build even with
-mfpu=neon, because of the presence o
The upstream configure script doesn't currently seem to work this way
for any of the ARM extensions. Instead, you seem need to build with the
right --extra-cflags as well as enabling the extension(s) you want, such
as --enable-armvfp or --enable-neon.
The configure script has the facilities to ad
Having played a bit, --extra-cflags="-mfpu=neon -mfloat-abi=softfp"
seems to be _required_ for the neon flavour in order for the NEON
optimisations to get built.
-ftree-vectorize probably isn't needed explicitly, because the build
seems to default to -O3.
--
Integrate and enable ARMv5TE/v6/VFP a
I discussed this with Måns, and on his advice I pulled across the
following patches from the ffmpeg trunk (revision numbers shown are
relative to svn://svn.ffmpeg.org/ffmpeg/trunk).
r18332 (ARM: NEON optimised add_pixels_clamped)
r18333 (ARM: NEON optimized put_signed_pixels_clamped)
r18535 (Add g
Thanks.
Hmmm, here's mine from mono-jit 2.0.1-4 (Jaunty). It does look like
there has been a change to the way mono makes syscalls: the svc 0x9f0002
calls have gone, and svc 0 has appeared: this looks like a transition
from the old syscall ABI to the new one.
This still doesn't explain the probl
I can't see any mono-jit binary package on ports.ubuntu.com for 2.4;
this might be due to packaging changes between the versions.
Can someone who has a build of 2.4 please do
$ objdump -d /usr/bin/mono | grep svc
It would be interesting to see whether the 'svc 0x009f0002' instructions
present in
Looking in /usr/bin/f-spot, there seems to be a --gdb option which I could
try.
I was using mono-2.0.x (Jaunty) though --- sorry for the confusion there; it
may not be useful to debug this after all.
--
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may a
em2.0-cil
- libmono-system-data2.0-cil
- libmono-system-web2.0-cil
- libndesk-dbus1.0-cil
- libndesk-dbus-glib1.0-cil
- mono-2.0-gac
+ [ dave-martin-arm removed his original incorrect description text; see
+ the original description for details. ]
--
mono segfaults on ARM
https://bugs.launchpad
** Attachment added: "Debug output from f-spot, with backtrace"
http://launchpadlibrarian.net/28247662/f-spot-debug_jaunty_armel.txt
--
mono segfaults on ARM
https://bugs.launchpad.net/bugs/390591
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
I rebuilt the Jaunty imx51 kernel with CONFIG_OABI_COMPAT enabled: _now_
I think I may now be seeing the same bug that everyone else is seeing.
Now, I get the following behaviour:
* f-spot and mono appear to install without segfaults or other problems.
* Running f-spot now causes a segfault (
Can you check whether CONFIG_OABI_COMPAT is enabled in the vendor
kernel? The verndor kernel configs have historically not been the same
as the stock Ubuntu kernel.
--
mono segfaults on ARM
https://bugs.launchpad.net/bugs/390591
You received this bug notification because you are a member of Ubun
Note: for the reasons given above, this issue should not be assumed to
be fixed for Karmic unless someone has tried to reproduce it on a
Babbage board.
--
mono segfaults on ARM
https://bugs.launchpad.net/bugs/390591
You received this bug notification because you are a member of Ubuntu
Bugs, which
This is interesting --- I definitely get SIGILL, not SIGSEGV, in the
mono binary. I did try installing f-spot-dbgsym, but this didn't seem
to give me any debug symbols even when explicitly attempting to load
them with "symbol-file /usr/lib/debug/usr/bin/mono" in GDB.
The instruction at PC is pop
> David: Its not clear if you've not used mono or C# before,
I haven't.
> but mono uses the PE format for its executables, but instead
> of using i386 or other assembly code, its CIL byte code.
> Wikipedia has a fairly good writeup of how .NET (and thus
> mono) applications work
> http://e
*** This bug is a duplicate of bug 390591 ***
https://bugs.launchpad.net/bugs/390591
This bug seems totally unrelated to
https://bugs.launchpad.net/bugs/390591 (which is about an
architecture/build problem in f-spot/mono and has nothing to do with
text rendering).
Should the duplicate status
Note: the above issue applies to the following source package versions,
on Jaunty:
f-spot 0.5.0.3-1ubuntu6
mono 2.0.1-4
I haven't investigated whether Karmic is affected.
--
f-spot seems wrongly packaged / unusable for armel
https://bugs.launchpad.net/bugs/390591
You received this bug notificat
Public bug reported:
Binary package hint: mono
This bug is just a placeholder to link to a related bug I've raised on
f-spot.
It looks like mono may be wrongly tagged as working on armel, or the
build configuration could be packaging binaries for the wrong
architecture.
https://bugs.launchpad.n
Public bug reported:
Binary package hint: f-spot
Installing f-spot on armel installs a load of Win32 PE executables
(.exe, .dll) and seems to rely on executing these to work.
dpkg prints out a load of "illegal instruction" errors when trying to
configure the package, but the package is erroneous
The patch has now been posted to the binutils list:
http://sourceware.org/ml/binutils/2009-06/msg00289.html
It looks pretty simple.
--
Binutils does not support 64-byte alignment for armel
https://bugs.launchpad.net/bugs/385501
You received this bug notification because you are a member of Ubun
Public bug reported:
Binary package hint: x264
This bug report is just a placeholder for now, since the relevant
changes are net yet merged with x264 mainline.
The optimisations are currently maintained by David Conrad, here:
git://gitorious.org/x264-arm/mainline.git
** Affects: x264 (Ubuntu)
MOZILLA_FIVE_HOME=.
LD_LIBRARY_PATH=.:./plugins:.
DISPLAY=:0.0
DYLD_LIBRARY_PATH=.:.
LIBRARY_PATH=.:./components:.
SHLIB_PATH=.:.
LIBPATH=.:.
ADDON_PATH=.
MOZ_PROGRAM=/usr/lib/thunderbird/thunderbird-bin
MOZ_TOOLKIT=
moz_debug=1
moz_debugger=g
Doesn't seem to work for me, I'm afraid. Thunderbird (2.0.0.21
+nobinonly-0ubuntu1.9.04.1) still segfaults with the same symptoms.
--
[armel] thunderbird-bin crashed with SIGSEGVI
https://bugs.launchpad.net/bugs/385325
You received this bug notification because you are a member of Ubuntu
Bugs, w
If tb2 can't easily be fixed, will tb3 be made available in jaunty as a
backport or update?
I'd be concerned if there will not be any working version of tb at all
in jaunty.
--
[armel] thunderbird-bin crashed with SIGSEGVI
https://bugs.launchpad.net/bugs/385325
You received this bug notification
A clarification in relation to my historical comments on this thread
(https://bugs.launchpad.net/ubuntu/+source/linux/+bug/319729/comments/11),
the problem I observed where init sometimes stops respawning terminal
logins is _not_ caused by a pselect-style race. It's a separate issue
to do with hot
An additional clarification here:
It seems the the pixman trunk is still stabilising, but there is likely
to be a stable version in time for the Karmic feature freeze; preferably
alpha4.
Assuming a stable version exists in the right timescale, is it feasible
to switch the packaged libpixman versi
Public bug reported:
There are upstream optimisations in pixman, based on the ARM NEON
extensions in Cortex-A8 etc.
http://cgit.freedesktop.org/pixman/
The current Karmic version of pixman is based on upstream 0.14.0, which
does not have the NEON support.
It's highly desirable to bring the opti
Public bug reported:
Binary package hint: binutils
Binutils does not support 64-byte alignment for armel platforms using
the .p2align directive; this is required in order for GCC to use this
alignment (wiether via -falign-functions= etc. or __attribute__ ((
__aligned__ (64) )). This may be affect
To clarify from my POV:
* For Karmic, we expect there to be additional ARM hardware supported by the
Ubuntu release, fully supporting NEON (though this is yet to be confirmed). It
will be nice if we can backport the new packages for Jaunty, but that's a
secondary concern.
* I don't expect t
Note that this issue isn't really ARM-specific. It's a generic C/C++
issue.
--
[ARM] Invalid use of assert() around expressions with required side-effects
(i.e., getcontext())
https://bugs.launchpad.net/bugs/383974
You received this bug notification because you are a member of Ubuntu
Bugs, whic
OK, so far so good.
The confflags definitions for NEON look OK, but it's still disabled.
It should be safe to uncomment the FLAVORS += neon line now, because we
deliberately disable NEON in the kernel for Jaunty to avoid applications
and libraries accidentally believing it works. (This also mean
Public bug reported:
To work around this, wvstreams should be ported to use another mechanism
such as setjmp/longjmp (I haven't investigated the feasibility of this),
or the affected functions (primarily setcontext and getcontext) need to
be implemented in glibc.
The affected code is in utils/wvt
Public bug reported:
When called, getcontext() returns -1 and sets errno = ENOSYS.
Some packages, such as wvstreams (a wvdial backend package), currently
rely on the ucontext functions in order to work correctly; currently
such packages are broken on armel.
See also http://bugs.debian.org/cgi-bi
** Attachment added: "Patch to prevent setcontext calls from being compiled out
if assertions are removed during build."
http://launchpadlibrarian.net/27530609/wvstreams-4.4.1_ucontext-wrapper.diff
--
Invalid use of assert() around expressions with required side-effects (i.e.,
getcontext())
Public bug reported:
If the assertions are compiled out, the calls to getcontext will be compiled
out also...
This probably doesn't affect Ubuntu builds, since the package is never built
with -DNDEBUG by default (I think).
But strictly speaking it's not correct and it will probably only be a
ma
I haven't done any source debugging of this yet, but here is a more detailed
backtrace.
Is there any other specific information which would be useful?
$ /usr/lib/thunderbird/run-mozilla.sh -g /usr/lib/thunderbird/thunderbird-bin
-d gdb
MOZILLA_FIVE_HOME=/usr/lib/thunderbird
LD_LIBRARY_PATH=
Public bug reported:
Binary package hint: ffmpeg
Since quite a lot of ARM architecture optimisations are now integrated
in the ffmpeg trunk, ideally Ubuntu should enable them for Karmic
onwards.
The related changes have been committed to the ffmpeg trunk at
svn://svn.ffmpeg.org/ffmpeg/trunk from
Probably anyone with a working platform can reproduce this; it seemed to
happen consistently.
Could the backtrace be obtained using the relevant debug packages and
the core dump attached to this report?
I'll try and install relevant ddebs and get some more direct
information, but this isn't going
Public bug reported:
Binary package hint: binutils
A patch has been implemented to support this, and has been posted to the
binutils mailing list, here:
http://sourceware.org/ml/binutils/2009-05/msg00132.html
This enables the automatic generation of if-then (IT) blocks in the
instruction stream
Public bug reported:
Binary package hint: binutils
Details of the issue, and a patch providing a workaround have been posted to
the binutils mailing list here:
http://sourceware.org/ml/binutils/2009-05/msg00297.html
This patch is needed in order for Thumb-2 code built by the tools to
work corre
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/27009927/Dependencies.txt
--
gpartedbin and Xorg starve mkfs of CPU time.
https://bugs.launchpad.net/bugs/378990
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Public bug reported:
Binary package hint: gparted
There is no graphics acceleration on this board, so the rendering of the
progress bar is done entirely on the CPU.
Note that renice can be used to increase the priority of mkfs; this
improves things significantly.
ProblemType: Bug
Architecture:
** Attachment added: "Dependencies.txt"
http://launchpadlibrarian.net/26435258/Dependencies.txt
--
Volume labels containing "/" are confusingly mangled
https://bugs.launchpad.net/bugs/373282
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
Public bug reported:
Binary package hint: hal
/ seems to be mangled to % when mounting media.
This may not be a bug, but some people may find it confusing, though I don't
expect manu users will be affected. I have some alternate root filesystems on
various devices, and it is common to label th
I will try and reproduce the issue when possible (I don't have a working
platform just at the moment).
Do I need to do anything extra, or can this be looked at with the
information currently submitted?
--
thunderbird-bin failed to start: burned lots of CPU crashed with SIGSEGV
https://bugs.launc
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 not
** 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)"
http://launchpadlibrarian.net/25872629/kernel-img-conf-bootloader-not-installe
** 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"
http://launchpa
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 ima
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
Got the update – much better now, thanks
--
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 are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubu
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
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 on
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 look
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
files
"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
https://lists.ubuntu
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 sidtant
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.
I
[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
ht
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
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 wa
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 g
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 Ubunt
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 buildin
** 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 y
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, ca
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:
SUSv3
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.
signals_caught[si
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 lo
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 as
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 descriptio
401 - 500 of 517 matches
Mail list logo
