1:20 a.m.
Hi folks,
I've put together a script to create up-to-date F17 snapshot images and
am storing the result on my people page. These are based on Peter's F17
alpha1 images with the following changes:
There is a tarball without any kernels included.
There is a tarball with uBoot-wrapped kernels included (should have
everything you need without messy mkimage commands). The armhfp version
includes tegra, omap and imx kernels. The arm version includes kirkwood.
There are bzcat+dd images for Tegra and OMAP- no partitioning necessary
to get started. These decompress to 8GB- if you have a larger storage
device resize2fs is your friend.
The files are currently uploading and will be entirely there in a few
more minutes. You can get the latest at:
http://blc.fedorapeople.org/fedora-arm/f17/
This is very much a work in progress, completely unofficial, largely
untested, but hopefully useful. Feel free to send me feedback. Enjoy,
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
9:09 a.m.
On 03/29/2012 11:20 PM, Brendan Conoboy wrote:
There is a tarball with uBoot-wrapped kernels included (should have
everything you need without messy mkimage commands). The armhfp version
includes tegra, omap and imx kernels. The arm version includes kirkwood.
Oh, and the kernels are 2.6.4x.fc15 kernels which are known to work.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
7:35 p.m.
On 03/30/2012 02:20 PM, Somebody in the thread at some point said:
Hi folks,
I've put together a script to create up-to-date F17 snapshot images and
am storing the result on my people page. These are based on Peter's F17
alpha1 images with the following changes:
There is a tarball without any kernels included.
There is a tarball with uBoot-wrapped kernels included (should have
everything you need without messy mkimage commands). The armhfp version
includes tegra, omap and imx kernels. The arm version includes kirkwood.
There are bzcat+dd images for Tegra and OMAP- no partitioning necessary
to get started. These decompress to 8GB- if you have a larger storage
device resize2fs is your friend.
It's great that you're doing this, but I don't think dding partition +
filesystems is a good idea.
We found that various "8GB" SD cards have different absolute numbers of
available sectors, it can lead to eventual filesystem corruption if your
image is slightly large than someone else's card.
If someone's going to try this they're probably OK running fdisk and
using tarballs.
The files are currently uploading and will be entirely there in a
few
more minutes. You can get the latest at:
http://blc.fedorapeople.org/fedora-arm/f17/
This is very much a work in progress, completely unofficial, largely
untested, but hopefully useful. Feel free to send me feedback. Enjoy,
I've been using Peter's F17 alpha1 image and following progress with
updates, it's been very good. It's stuck as of last week with
gnome-shell problems though. But generally package completeness has
been increasing really well last few weeks, great job.
-Andy
8:20 p.m.
On 03/30/2012 05:35 PM, "Andy Green (林安廸)" wrote:
It's great that you're doing this, but I don't think
dding partition +
filesystems is a good idea.
It's definitely tricky to get right. The number of possible
configurations makes it tricky to do an efficient selection of images.
I may end up doing a combination tegra+omap+etc image to cut down the waste.
We found that various "8GB" SD cards have different
absolute numbers of
available sectors, it can lead to eventual filesystem corruption if your
image is slightly large than someone else's card.
Well, the image is being created out of a sparse file with 8000 1048576
byte sectors. If that proves too many it would be little trouble to
drop it down to 7900 or something. We'll see how it goes in practice.
If someone's going to try this they're probably OK running
fdisk and
using tarballs.
Yeah, the uboot enabled kernel tarball will probably be the most
universally useful. I personally had plenty of trouble marking working
uboot files so leveraging David Marlin's work on grubby will hopefully
spare others that trouble. Meanwhile, a number of people have asked for
images they can dd, so I'm trying to fulfill both needs.
I've been using Peter's F17 alpha1 image and following
progress with
updates, it's been very good. It's stuck as of last week with
gnome-shell problems though. But generally package completeness has
been increasing really well last few weeks, great job.
What are the gnome-shell problems? Perhaps they're well known but I'm
not acquainted with them. If we're missing a package that will help
things out let me know and I'll put it in the next snapshot.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
3:48 a.m.
On Sat, Mar 31, 2012 at 2:20 AM, Brendan Conoboy <blc(a)redhat.com> wrote:
On 03/30/2012 05:35 PM, "Andy Green (林安廸)" wrote:
>
> It's great that you're doing this, but I don't think dding partition +
> filesystems is a good idea.
It's definitely tricky to get right. The number of possible configurations
makes it tricky to do an efficient selection of images. I may end up doing a
combination tegra+omap+etc image to cut down the waste.
> We found that various "8GB" SD cards have different absolute numbers of
> available sectors, it can lead to eventual filesystem corruption if your
> image is slightly large than someone else's card.
Well, the image is being created out of a sparse file with 8000 1048576 byte
sectors. If that proves too many it would be little trouble to drop it down
to 7900 or something. We'll see how it goes in practice.
> If someone's going to try this they're probably OK running fdisk and
> using tarballs.
Yeah, the uboot enabled kernel tarball will probably be the most universally
useful. I personally had plenty of trouble marking working uboot files so
leveraging David Marlin's work on grubby will hopefully spare others that
trouble. Meanwhile, a number of people have asked for images they can dd,
so I'm trying to fulfill both needs.
> I've been using Peter's F17 alpha1 image and following progress with
> updates, it's been very good. It's stuck as of last week with
> gnome-shell problems though. But generally package completeness has
> been increasing really well last few weeks, great job.
What are the gnome-shell problems? Perhaps they're well known but I'm not
acquainted with them. If we're missing a package that will help things out
let me know and I'll put it in the next snapshot.
It'll be dep issues, I'm awaiting the reopening of mainline so we'll
get updates.
Peter
8:28 a.m.
On 03/31/2012 09:20 AM, Somebody in the thread at some point said:
On 03/30/2012 05:35 PM, "Andy Green (林安廸)" wrote:
> It's great that you're doing this, but I don't think dding partition +
> filesystems is a good idea.
It's definitely tricky to get right. The number of possible
configurations makes it tricky to do an efficient selection of images. I
may end up doing a combination tegra+omap+etc image to cut down the waste.
> We found that various "8GB" SD cards have different absolute numbers of
> available sectors, it can lead to eventual filesystem corruption if your
> image is slightly large than someone else's card.
Well, the image is being created out of a sparse file with 8000 1048576
byte sectors. If that proves too many it would be little trouble to
drop it down to 7900 or something. We'll see how it goes in practice.
Just saying if the filesystem in there at the end doesn't all make it on
the device, it will work for a while and die corrupted. It won't hurt
to pare it back 100MB.
> If someone's going to try this they're probably OK
running fdisk and
> using tarballs.
Yeah, the uboot enabled kernel tarball will probably be the most
universally useful. I personally had plenty of trouble marking working
uboot files so leveraging David Marlin's work on grubby will hopefully
spare others that trouble. Meanwhile, a number of people have asked for
images they can dd, so I'm trying to fulfill both needs.
Yes working with U-Boot isn't pretty.
> I've been using Peter's F17 alpha1 image and following
progress with
> updates, it's been very good. It's stuck as of last week with
> gnome-shell problems though. But generally package completeness has
> been increasing really well last few weeks, great job.
What are the gnome-shell problems? Perhaps they're well known but I'm
not acquainted with them. If we're missing a package that will help
things out let me know and I'll put it in the next snapshot.
It's not deps afaict, a couple of weeks ago pieces were missing, but
there now is enough to yum install @gnome-desktop sanely with
--skip-broken; abrt, elfutils, gdb, libreport and xmlrpc-c are skipped.
Here anyway the resulting gdm / gnome ends up showing "Oh no! Something
has gone wrong." before gdm login.
Poking around in gdm logs shows a segfault after not being able to find
org.gnome.SessionManager |not provided by any .service files". I had to
mess with a javascript file in gnome to get that info, it was otherwise
complaining that there were too many args sent to the logging api.
-Andy
9:52 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 30 Mar 2012 18:20:17 -0700
Brendan Conoboy <blc(a)redhat.com> wrote:
On 03/30/2012 05:35 PM, "Andy Green (林安廸)" wrote:
> It's great that you're doing this, but I don't think dding
> partition + filesystems is a good idea.
It's definitely tricky to get right. The number of possible
configurations makes it tricky to do an efficient selection of
images. I may end up doing a combination tegra+omap+etc image to cut
down the waste.
> We found that various "8GB" SD cards have different absolute
> numbers of available sectors, it can lead to eventual filesystem
> corruption if your image is slightly large than someone else's card.
Well, the image is being created out of a sparse file with 8000
1048576 byte sectors. If that proves too many it would be little
trouble to drop it down to 7900 or something. We'll see how it goes
in practice.
i think we should only make the image 2 gb using domething like "dd
if=/dev/zero of/raw/disk bs=1M count=2048" cound could be 2000 also
then it should work everywhere.
> If someone's going to try this they're probably OK
running fdisk and
> using tarballs.
the idea is to get to a point where its simple to deploy lower the
barrier of entry.
Yeah, the uboot enabled kernel tarball will probably be the most
universally useful. I personally had plenty of trouble marking
working uboot files so leveraging David Marlin's work on grubby will
hopefully spare others that trouble. Meanwhile, a number of people
have asked for images they can dd, so I'm trying to fulfill both
needs.
> I've been using Peter's F17 alpha1 image and following progress with
> updates, it's been very good. It's stuck as of last week with
> gnome-shell problems though. But generally package completeness has
> been increasing really well last few weeks, great job.
What are the gnome-shell problems? Perhaps they're well known but
I'm not acquainted with them. If we're missing a package that will
help things out let me know and I'll put it in the next snapshot.
there is gnome 3.4.0 in testing on primary now there is a change it
will get pushed to stable for beta on monday if not its probably 2
weeks away. What we need to do is come up with a set of F17 beta
deliverables and work really hard in the next 2 weeks to deliver a F17
Beta.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk93GjwACgkQkSxm47BaWffvhwCgg3VtFwVUF2FVBWPL0tMMA6Ik
yJ4AoJEKuHTrJCBlyv7JZgGf5LAqYxWE
=MCFP
-----END PGP SIGNATURE-----
10:10 a.m.
On Sat, 2012-03-31 at 09:52 -0500, Dennis Gilmore wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 30 Mar 2012 18:20:17 -0700
Brendan Conoboy <blc(a)redhat.com> wrote:
> On 03/30/2012 05:35 PM, "Andy Green (林安廸)" wrote:
> > It's great that you're doing this, but I don't think dding
> > partition + filesystems is a good idea.
>
> It's definitely tricky to get right. The number of possible
> configurations makes it tricky to do an efficient selection of
> images. I may end up doing a combination tegra+omap+etc image to cut
> down the waste.
>
> > We found that various "8GB" SD cards have different absolute
> > numbers of available sectors, it can lead to eventual filesystem
> > corruption if your image is slightly large than someone else's card.
>
> Well, the image is being created out of a sparse file with 8000
> 1048576 byte sectors. If that proves too many it would be little
> trouble to drop it down to 7900 or something. We'll see how it goes
> in practice.
i think we should only make the image 2 gb using domething like "dd
if=/dev/zero of/raw/disk bs=1M count=2048" cound could be 2000 also
then it should work everywhere.
On the Raspberry Pi Fedora Remix I'm shrinking the image as much as
possible by shortening the last (root) partition. The partition is
resized to fill the SD card on first boot (fdisk, reboot, resize2fs).
This results in a small image size, minimizes unnecessary writes to the
SD card, works on any card size, and lets you take full advantage of the
space on the card.
Perhaps we should adopt that approach for the images?
-Chris
8:34 p.m.
On 03/31/2012 08:10 AM, Chris Tyler wrote:
On the Raspberry Pi Fedora Remix I'm shrinking the image as much
as
possible by shortening the last (root) partition. The partition is
resized to fill the SD card on first boot (fdisk, reboot, resize2fs).
This results in a small image size, minimizes unnecessary writes to the
SD card, works on any card size, and lets you take full advantage of the
space on the card.
Perhaps we should adopt that approach for the images?
Would be happy to add this- with that sort of functionality I'd have no
reservation about creating a 1.990GB image. Send me a pointer to how
you're doing this during the first boot and I'll integrate it into the
rootfs image generator.
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
7:05 p.m.
Hi everybody,
Based on the feedback on these images I've gone through a few more
iterations of the build scripts and they've had some testing (thanks
dmarlin, pbrobinson and smooge!).
There are now images for:
Trimslice (hard float, mmc and sda)
Panda (hard float, mmc, and sda)
Beagle (hard/soft, mmc)
To install the image a command just use a command like:
xzcat f17arm-latest-armhfp-trimslice-mmcblk0.img.xz > /dev/device
For reasons I'm not acquainted with using dd with a large bs value
sometimes results in bad writes, so if you use dd keep bs small.
Each image decompresses to 1900MB. Upon first boot it will begin the
process of auto-resize the / partition to its full capacity. A second
boot will complete the process (This is done using a modified version of
Chris Tyler's raspberry pi remix resize script).
All scripts used to generate the images is included in the same
directory. Next up will likely be a unified trimslice/panda image. Fun!
--
Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com
10:06 p.m.
New subject: F17 snapshot / LLVM on framebuffer Xorg
On 03/31/2012 09:28 PM, Somebody in the thread at some point said:
> What are the gnome-shell problems? Perhaps they're well
known but I'm
> not acquainted with them. If we're missing a package that will help
> things out let me know and I'll put it in the next snapshot.
It's not deps afaict, a couple of weeks ago pieces were missing, but
there now is enough to yum install @gnome-desktop sanely with
--skip-broken; abrt, elfutils, gdb, libreport and xmlrpc-c are skipped.
Here anyway the resulting gdm / gnome ends up showing "Oh no! Something
has gone wrong." before gdm login.
Poking around in gdm logs shows a segfault after not being able to find
org.gnome.SessionManager |not provided by any .service files". I had to
mess with a javascript file in gnome to get that info, it was otherwise
complaining that there were too many args sent to the logging api.
Now that gdb is available I can see the issue boils down to segfault in
llvm. I installed the 1GB (installed size) of debuginfos and got this
backtrace
#0 emitInstruction (MI=..., this=0x1394f8) at ARMCodeEmitter.cpp:576
#1 (anonymous namespace)::ARMCodeEmitter::runOnMachineFunction
(this=0x1394f8, MF=...) at ARMCodeEmitter.cpp:391
#2 0xb3881960 in runOnFunction (this=0x1394f8, F=...) at
MachineFunctionPass.cpp:33
#3 llvm::MachineFunctionPass::runOnFunction (this=0x1394f8, F=...) at
MachineFunctionPass.cpp:26
#4 0xb366a204 in llvm::FPPassManager::runOnFunction (this=0x107620,
F=...) at PassManager.cpp:1512
#5 0xb366a378 in llvm::FunctionPassManagerImpl::run (this=0x107468,
F=...) at PassManager.cpp:1462
#6 0xb366a45c in llvm::FunctionPassManager::run (this=0x116340, F=...)
at PassManager.cpp:1391
#7 0xb3b1fc88 in llvm::JIT::jitTheFunction (this=this@entry=0x105cb0,
F=F@entry=0xc1ef30, locked=...) at JIT.cpp:639
#8 0xb3b1ff90 in llvm::JIT::runJITOnFunctionUnlocked
(this=this@entry=0x105cb0, F=F@entry=0xc1ef30, locked=...) at JIT.cpp:618
#9 0xb3b200b4 in llvm::JIT::getPointerToFunction (this=0x105cb0,
F=0xc1ef30) at JIT.cpp:675
#10 0xb359ef20 in llvm::ExecutionEngine::getPointerToGlobal
(this=0x105cb0, GV=0xc1ef30) at ExecutionEngine.cpp:505
#11 0xb42daa5c in generate_fragment (lp=0xb455f3d4, lp@entry=0x235680,
shader=0xc60744, shader@entry=0xc1c7c8, variant=0xc1c7c8,
variant@entry=0xb93440, partial_mask=3025531860, partial_mask@entry=1)
at lp_state_fs.c:812
#12 0xb42db410 in generate_variant (key=0xbeffd6ac, shader=0xc1c7c8,
lp=0x235680) at lp_state_fs.c:968
#13 llvmpipe_update_fs (lp=lp@entry=0x235680) at lp_state_fs.c:1399
#14 0xb42d9258 in llvmpipe_update_derived (e=e@entry=0x235680) at
lp_state_derived.c:155
#15 0xb42cb9d0 in llvmpipe_draw_vbo (pipe=0x235680, info=0xbeffd880) at
lp_draw_arrays.c:64
#16 0xb4382874 in st_draw_vbo (ctx=0x0, arrays=<optimized out>,
prims=<optimized out>, nr_prims=0, ib=0x0, index_bounds_valid=1 '\001',
min_index=0, max_index=1, tfb_vertcount=0x0) at state_tracker/st_draw.c:1112
#17 0xb437be0c in vbo_draw_arrays (ctx=ctx@entry=0x1d50f8,
mode=mode@entry=7, start=start@entry=0, count=count@entry=4,
numInstances=numInstances@entry=1) at vbo/vbo_exec_array.c:600
#18 0xb437bef8 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at
vbo/vbo_exec_array.c:632
#19 0xb543585c in shared_dispatch_stub_310 (mode=7, first=<optimized
out>, count=<optimized out>) at
../../../src/mapi/shared-glapi/glapi_mapi_tmp.h:14992
#20 0xb62f11ac in ?? () from /lib/libcogl.so.8
#21 0xb62ed198 in ?? () from /lib/libcogl.so.8
#22 0xb62ec3ac in ?? () from /lib/libcogl.so.8
#23 0xb62ecf4c in ?? () from /lib/libcogl.so.8
#24 0xb62ec3ac in ?? () from /lib/libcogl.so.8
#25 0xb62ecd00 in ?? () from /lib/libcogl.so.8
#26 0xb62ec3ac in ?? () from /lib/libcogl.so.8
#27 0xb62ec8f4 in ?? () from /lib/libcogl.so.8
#28 0xb62ec3ac in ?? () from /lib/libcogl.so.8
#29 0xb62ede70 in ?? () from /lib/libcogl.so.8
#30 0xb62c166c in cogl_flush () from /lib/libcogl.so.8
#31 0xb62ea9c0 in ?? () from /lib/libcogl.so.8
#32 0xb5760b00 in g_hook_list_invoke () from /lib/libglib-2.0.so.0
#33 0xb62e9bfc in _cogl_atlas_reserve_space () from /lib/libcogl.so.8
#34 0xb62ead50 in _cogl_atlas_texture_new_with_size () from
/lib/libcogl.so.8
#35 0xb62eafc4 in ?? () from /lib/libcogl.so.8
#36 0xb62e40f0 in cogl_texture_new_from_bitmap () from /lib/libcogl.so.8
#37 0xb62e4190 in cogl_texture_new_from_data () from /lib/libcogl.so.8
#38 0xb6fac9c8 in st_theme_node_paint () from
/usr/lib/gnome-shell/libgnome-shell.so
#39 0xb6fb19ac in st_widget_paint_background () from
/usr/lib/gnome-shell/libgnome-shell.so
#40 0xb6fb19cc in ?? () from /usr/lib/gnome-shell/libgnome-shell.so
#41 0xb5846488 in g_cclosure_marshal_VOID__VOIDv () from
/lib/libgobject-2.0.so.0
#42 0xb5842658 in ?? () from /lib/libgobject-2.0.so.0
#43 0xb58445cc in ?? () from /lib/libgobject-2.0.so.0
#44 0xb585f3f4 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#45 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0
#46 0xb6378d0c in clutter_actor_continue_paint () from
/lib/libclutter-1.0.so.0
#47 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0
#48 0xb6f8f84c in ?? () from /usr/lib/gnome-shell/libgnome-shell.so
#49 0xb5846488 in g_cclosure_marshal_VOID__VOIDv () from
/lib/libgobject-2.0.so.0
#50 0xb5842658 in ?? () from /lib/libgobject-2.0.so.0
#51 0xb58445cc in ?? () from /lib/libgobject-2.0.so.0
#52 0xb585f3f4 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#53 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0
#54 0xb6378d0c in clutter_actor_continue_paint () from
/lib/libclutter-1.0.so.0
#55 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0
#56 0xb6f7c428 in ?? () from /usr/lib/gnome-shell/libgnome-shell.so
#57 0xb5846488 in g_cclosure_marshal_VOID__VOIDv () from
/lib/libgobject-2.0.so.0
#58 0xb5842658 in ?? () from /lib/libgobject-2.0.so.0
#59 0xb58445cc in ?? () from /lib/libgobject-2.0.so.0
#60 0xb585f3f4 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#61 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0
#62 0xb6378d0c in clutter_actor_continue_paint () from
/lib/libclutter-1.0.so.0
#63 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0
#64 0xb63d456c in ?? () from /lib/libclutter-1.0.so.0
#65 0xb5846434 in g_cclosure_marshal_VOID__VOID () from
/lib/libgobject-2.0.so.0
#66 0xb5842db8 in ?? () from /lib/libgobject-2.0.so.0
#67 0xb58443d4 in g_closure_invoke () from /lib/libgobject-2.0.so.0
#68 0xb5856bec in ?? () from /lib/libgobject-2.0.so.0
#69 0xb585f878 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#70 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0
#71 0xb6378d0c in clutter_actor_continue_paint () from
/lib/libclutter-1.0.so.0
#72 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0
#73 0xb63d8764 in ?? () from /lib/libclutter-1.0.so.0
#74 0xb63732f8 in ?? () from /lib/libclutter-1.0.so.0
#75 0xb63da48c in ?? () from /lib/libclutter-1.0.so.0
#76 0xb63d7160 in ?? () from /lib/libclutter-1.0.so.0
#77 0xb63bf884 in ?? () from /lib/libclutter-1.0.so.0
#78 0xb576f68c in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#79 0xb576fad0 in ?? () from /lib/libglib-2.0.so.0
#80 0xb576fef4 in g_main_loop_run () from /lib/libglib-2.0.so.0
#81 0xb6e4cd38 in meta_run () from /lib/libmutter.so.0
#82 0x000098a8 in main ()
Is llvm / gnome-shell expected to give a good result with framebuffer X
driver at the moment (on hardfloat)? Or is it a problem with my
background image (not sure what that is right now).
-Andy
10:52 a.m.
New subject: F17 snapshot / LLVM on framebuffer Xorg
On Sat, Apr 7, 2012 at 4:06 AM, "Andy Green (林安廸)" <andy(a)warmcat.com>
wrote:
On 03/31/2012 09:28 PM, Somebody in the thread at some point said:
>> What are the gnome-shell problems? Perhaps they're well known but I'm
>> not acquainted with them. If we're missing a package that will help
>> things out let me know and I'll put it in the next snapshot.
>
> It's not deps afaict, a couple of weeks ago pieces were missing, but
> there now is enough to yum install @gnome-desktop sanely with
> --skip-broken; abrt, elfutils, gdb, libreport and xmlrpc-c are skipped.
> Here anyway the resulting gdm / gnome ends up showing "Oh no! Something
> has gone wrong." before gdm login.
>
> Poking around in gdm logs shows a segfault after not being able to find
> org.gnome.SessionManager |not provided by any .service files". I had to
> mess with a javascript file in gnome to get that info, it was otherwise
> complaining that there were too many args sent to the logging api.
Now that gdb is available I can see the issue boils down to segfault in
llvm. I installed the 1GB (installed size) of debuginfos and got this
backtrace
#0 emitInstruction (MI=..., this=0x1394f8) at ARMCodeEmitter.cpp:576
#1 (anonymous namespace)::ARMCodeEmitter::runOnMachineFunction
(this=0x1394f8, MF=...) at ARMCodeEmitter.cpp:391
#2 0xb3881960 in runOnFunction (this=0x1394f8, F=...) at
MachineFunctionPass.cpp:33
#3 llvm::MachineFunctionPass::runOnFunction (this=0x1394f8, F=...) at
MachineFunctionPass.cpp:26
#4 0xb366a204 in llvm::FPPassManager::runOnFunction (this=0x107620,
F=...) at PassManager.cpp:1512
#5 0xb366a378 in llvm::FunctionPassManagerImpl::run (this=0x107468,
F=...) at PassManager.cpp:1462
#6 0xb366a45c in llvm::FunctionPassManager::run (this=0x116340, F=...)
at PassManager.cpp:1391
#7 0xb3b1fc88 in llvm::JIT::jitTheFunction (this=this@entry=0x105cb0,
F=F@entry=0xc1ef30, locked=...) at JIT.cpp:639
#8 0xb3b1ff90 in llvm::JIT::runJITOnFunctionUnlocked
(this=this@entry=0x105cb0, F=F@entry=0xc1ef30, locked=...) at JIT.cpp:618
#9 0xb3b200b4 in llvm::JIT::getPointerToFunction (this=0x105cb0,
F=0xc1ef30) at JIT.cpp:675
#10 0xb359ef20 in llvm::ExecutionEngine::getPointerToGlobal
(this=0x105cb0, GV=0xc1ef30) at ExecutionEngine.cpp:505
#11 0xb42daa5c in generate_fragment (lp=0xb455f3d4, lp@entry=0x235680,
shader=0xc60744, shader@entry=0xc1c7c8, variant=0xc1c7c8,
variant@entry=0xb93440, partial_mask=3025531860, partial_mask@entry=1)
at lp_state_fs.c:812
#12 0xb42db410 in generate_variant (key=0xbeffd6ac, shader=0xc1c7c8,
lp=0x235680) at lp_state_fs.c:968
#13 llvmpipe_update_fs (lp=lp@entry=0x235680) at lp_state_fs.c:1399
#14 0xb42d9258 in llvmpipe_update_derived (e=e@entry=0x235680) at
lp_state_derived.c:155
#15 0xb42cb9d0 in llvmpipe_draw_vbo (pipe=0x235680, info=0xbeffd880) at
lp_draw_arrays.c:64
#16 0xb4382874 in st_draw_vbo (ctx=0x0, arrays=<optimized out>,
prims=<optimized out>, nr_prims=0, ib=0x0, index_bounds_valid=1 '\001',
min_index=0, max_index=1, tfb_vertcount=0x0) at state_tracker/st_draw.c:1112
#17 0xb437be0c in vbo_draw_arrays (ctx=ctx@entry=0x1d50f8,
mode=mode@entry=7, start=start@entry=0, count=count@entry=4,
numInstances=numInstances@entry=1) at vbo/vbo_exec_array.c:600
#18 0xb437bef8 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at
vbo/vbo_exec_array.c:632
#19 0xb543585c in shared_dispatch_stub_310 (mode=7, first=<optimized
out>, count=<optimized out>) at
../../../src/mapi/shared-glapi/glapi_mapi_tmp.h:14992
#20 0xb62f11ac in ?? () from /lib/libcogl.so.8
#21 0xb62ed198 in ?? () from /lib/libcogl.so.8
#22 0xb62ec3ac in ?? () from /lib/libcogl.so.8
#23 0xb62ecf4c in ?? () from /lib/libcogl.so.8
#24 0xb62ec3ac in ?? () from /lib/libcogl.so.8
#25 0xb62ecd00 in ?? () from /lib/libcogl.so.8
#26 0xb62ec3ac in ?? () from /lib/libcogl.so.8
#27 0xb62ec8f4 in ?? () from /lib/libcogl.so.8
#28 0xb62ec3ac in ?? () from /lib/libcogl.so.8
#29 0xb62ede70 in ?? () from /lib/libcogl.so.8
#30 0xb62c166c in cogl_flush () from /lib/libcogl.so.8
#31 0xb62ea9c0 in ?? () from /lib/libcogl.so.8
#32 0xb5760b00 in g_hook_list_invoke () from /lib/libglib-2.0.so.0
#33 0xb62e9bfc in _cogl_atlas_reserve_space () from /lib/libcogl.so.8
#34 0xb62ead50 in _cogl_atlas_texture_new_with_size () from
/lib/libcogl.so.8
#35 0xb62eafc4 in ?? () from /lib/libcogl.so.8
#36 0xb62e40f0 in cogl_texture_new_from_bitmap () from /lib/libcogl.so.8
#37 0xb62e4190 in cogl_texture_new_from_data () from /lib/libcogl.so.8
#38 0xb6fac9c8 in st_theme_node_paint () from
/usr/lib/gnome-shell/libgnome-shell.so
#39 0xb6fb19ac in st_widget_paint_background () from
/usr/lib/gnome-shell/libgnome-shell.so
#40 0xb6fb19cc in ?? () from /usr/lib/gnome-shell/libgnome-shell.so
#41 0xb5846488 in g_cclosure_marshal_VOID__VOIDv () from
/lib/libgobject-2.0.so.0
#42 0xb5842658 in ?? () from /lib/libgobject-2.0.so.0
#43 0xb58445cc in ?? () from /lib/libgobject-2.0.so.0
#44 0xb585f3f4 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#45 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0
#46 0xb6378d0c in clutter_actor_continue_paint () from
/lib/libclutter-1.0.so.0
#47 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0
#48 0xb6f8f84c in ?? () from /usr/lib/gnome-shell/libgnome-shell.so
#49 0xb5846488 in g_cclosure_marshal_VOID__VOIDv () from
/lib/libgobject-2.0.so.0
#50 0xb5842658 in ?? () from /lib/libgobject-2.0.so.0
#51 0xb58445cc in ?? () from /lib/libgobject-2.0.so.0
#52 0xb585f3f4 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#53 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0
#54 0xb6378d0c in clutter_actor_continue_paint () from
/lib/libclutter-1.0.so.0
#55 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0
#56 0xb6f7c428 in ?? () from /usr/lib/gnome-shell/libgnome-shell.so
#57 0xb5846488 in g_cclosure_marshal_VOID__VOIDv () from
/lib/libgobject-2.0.so.0
#58 0xb5842658 in ?? () from /lib/libgobject-2.0.so.0
#59 0xb58445cc in ?? () from /lib/libgobject-2.0.so.0
#60 0xb585f3f4 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#61 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0
#62 0xb6378d0c in clutter_actor_continue_paint () from
/lib/libclutter-1.0.so.0
#63 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0
#64 0xb63d456c in ?? () from /lib/libclutter-1.0.so.0
#65 0xb5846434 in g_cclosure_marshal_VOID__VOID () from
/lib/libgobject-2.0.so.0
#66 0xb5842db8 in ?? () from /lib/libgobject-2.0.so.0
#67 0xb58443d4 in g_closure_invoke () from /lib/libgobject-2.0.so.0
#68 0xb5856bec in ?? () from /lib/libgobject-2.0.so.0
#69 0xb585f878 in g_signal_emit_valist () from /lib/libgobject-2.0.so.0
#70 0xb585fa64 in g_signal_emit () from /lib/libgobject-2.0.so.0
#71 0xb6378d0c in clutter_actor_continue_paint () from
/lib/libclutter-1.0.so.0
#72 0xb638a25c in ?? () from /lib/libclutter-1.0.so.0
#73 0xb63d8764 in ?? () from /lib/libclutter-1.0.so.0
#74 0xb63732f8 in ?? () from /lib/libclutter-1.0.so.0
#75 0xb63da48c in ?? () from /lib/libclutter-1.0.so.0
#76 0xb63d7160 in ?? () from /lib/libclutter-1.0.so.0
#77 0xb63bf884 in ?? () from /lib/libclutter-1.0.so.0
#78 0xb576f68c in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#79 0xb576fad0 in ?? () from /lib/libglib-2.0.so.0
#80 0xb576fef4 in g_main_loop_run () from /lib/libglib-2.0.so.0
#81 0xb6e4cd38 in meta_run () from /lib/libmutter.so.0
#82 0x000098a8 in main ()
Is llvm / gnome-shell expected to give a good result with framebuffer X
driver at the moment (on hardfloat)? Or is it a problem with my
background image (not sure what that is right now).
I very much doubt gnome-shell will give a good result on any fbdev
device as it needs 3D.
Peter
7:15 p.m.
New subject: F17 snapshot / LLVM on framebuffer Xorg
On 04/07/2012 11:52 PM, Somebody in the thread at some point said:
> Is llvm / gnome-shell expected to give a good result with
framebuffer X
> driver at the moment (on hardfloat)? Or is it a problem with my
> background image (not sure what that is right now).
I very much doubt gnome-shell will give a good result on any fbdev
device as it needs 3D.
It does need to draw in 3D but AIUI that doesn't mean it needs
3D-capable device --->
http://lists.fedoraproject.org/pipermail/devel/2011-November/158976.html
-Andy
4394
days inactive
4403
days old
12 comments
5 participants
participants (5)
-
Andy Green -
Brendan Conoboy -
Chris Tyler -
Dennis Gilmore -
Peter Robinson