Hi,
Please have a look at upstream bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799
I was asked to test GCC 4.8 and found this issue go away with
locally-recompiled GCC 4.8.2 (upstream source, as ia64 is no more
supported by Debian).
Whether this was expected or not, I don't know.
This has nothing to do with kernel version, but with gcc version, as
alluded to nearly two years ago by Stephan Schreiber [1]...
Upstream bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61799
Émeric
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691576#10
--
To UNSUBSCRIB
Émeric
2014-01-19 20:55 GMT+01:00 Kurt Roeckx :
> On Sun, Jan 19, 2014 at 08:40:27PM +0100, Émeric MASCHINO wrote:
>>
>> [1] https://lists.debian.org/debian-68k/2013/05/msg00065.html <===
>> BTW, why is it archived on debian-68k?
>
> Because it was send to debian-port
Package: iceweasel
Version: 24.2.0esr-1
Severity: important
With today's Jessie updates, iceweasel was upgraded from 17 to 24.
Firefox 17 never worked on ia64 because of upstream bug #910845 [1].
Despite of Stephan Schreiber's hard work, his patches failed to be
merged in time for Firefox 17 rele
2014/1/12 Ben Hutchings :
>
> If you have space to install wheezy on a separate partition, please can
> you try that.
>
> (Of course, that crash ought to be fixed in 3.2.y. But I don't know
> that anyone will have the time and knowledge to do so. And it's not
> part of this bug.)
No more empty p
2014/1/12 Ben Hutchings :
>
> Sorry, I'm being silly. udev is built as part of systemd now, so this
> is independent of whether you use systemd as init. And systemd doesn't
> currently run as init in the initramfs.
Uh, OK.
How can I help further?
Emeric
--
To UNSUBSCRIBE, email to debi
2014/1/12 Ben Hutchings :
>
> You can have sysvinit and systemd installed in parallel and then use the
> 'init' kernel parameter to switch between them. Only systemd-sysv
> conflicts/replaces sysvinit.
So, I've reinstalled sysvinit and sysvinit-core that purged
systemd-sysv. I can't however remov
2014/1/12 Ben Hutchings :
>
> So this is a crash, not an incompatibility with the newer systemd.
[...]
> Can you test the 3.2 kernel with sysvinit, in case this is a bug that's
> specifically provoked by systemd?
That's why I was saying "too old for my current Debian install" on Jan 6th.
Since
2014/1/7 Ben Hutchings :
> On Mon, 2014-01-06 at 10:15 +0100, Émeric MASCHINO wrote:
>
> I don't understand that - I still have 3.2 installed on this unstable
> (i386) system and can still boot it. How does it go wrong?
It seems to crash with something wrong with systemd.
You&#
Hi,
And happy new year!
2013/12/20 Ben Hutchings :
>> > I actually tried building the kernel like that, so you could try the
>> > packages in:
>> >
>> > http://people.debian.org/~benh/packages/wheezy-ia64-kernel-O1/
>>
>> Was your O1-compiled kernel working fine?
>
> I have no idea as no-one has
2013/12/12 Ben Hutchings :
> So far as I know, there is no longer any commercial development of
> Linux on Itanium. Some old 'enterprise' distributions might
> continue to be supported for a few years but mainline isn't
> supported.
It seems that Intel must provide hp with Itanium CPUs till 2017
finitely working fine then or just being lucky because of a
working kernel configuration?
Émeric
[1] http://marc.info/?l=linux-ia64&m=134858659916369&w=2
[2] http://marc.info/?l=linux-ia64&m=133124040906499&w=2
[3] http://lists.debian.org/debian-ia64/2013/09/msg00024.html
2013/12/11 Ben
FYI, linux-image-3.11-2-mckinley 3.11.10-1 in today's Jessie updates
didn't change anything w.r.t. gdb problem.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
FYI, linux-image-3.11-2-mckinley 3.11.8-1 in today's Jessie updates
breaks gdb again.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hello,
Latest GNOME 3.8 packages hit Testing today and I'm now experiencing
the same issue than you on an ia64 workstation (FireGL1 X1 AGP
graphics adapter with 256MB VRAM, r300g driver). I'm however less
lucky than you as I'm not able to set a wallpaper bigger than
2560x1440 pixels (always get so
FYI, linux-image-3.10-3-mckinley 3.10.11-1 in today's Jessie updates
brought back gdb to life.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Thanks Stephan, I'll test your patches.
And I bet that the same will have to be done for Firefox ESR 21?
BTW, I don't understand how upstream code is versioned. Shouldn't your
original patches have been ported to the new JS engine by upstream
when they released > Firefox ESR 10 versions?
Otherwise
Hi,
With the switch from WebKit 1.8.1 to 2.0.4, instability is back on
IA-64: Epiphany simply can't open any URL without crashing (cf. the
attached gdb output when trying to go to http://www.gnome.org).
Émeric
Starting program: /usr/bin/epiphany-browser
warning: Could not load shared librar
Package: iceweasel
Version: 17.0.8esr-2
Today's "Jessie" Testing updates upgraded Iceweasel ESR from 10 to 17.
Unfortunately, Iceweasel 17 simply fails to start. Please find in
attached the gdb output.
If helpful, I'm getting the following error if Iceweasel is started
from a terminal, just befo
Hi and happy new year,
I've tested latest patchset from Stephan.
Epiphany runs as great as with the v2 patchset.
I'm however still getting the curious Google homepage crash I was
talking about previously.
Uninstalling gnash didn't help.
But overall, Stephan work is a _huge_ improvement w.r.t. wha
Hi,
I've applied Stephan patches and recompiled Iceweasel. I used it for
one week now without any problem. I even ran WebGL conformance test
suite successfully whereas vanilla Iceweasel isn't able to complete it
after a few tests. Notice however that, when I say "successfully", I
mean the process
d.
Émeric
2012/12/7 Stephan Schreiber :
> Émeric Maschino wrote:
>
>> Indeed, even with your updated packages, Epiphany still crashes with
>> the scenario I described in this bug report
>
>
> I looked for anything that is different on a release build and on a debug
Thanks Stephan for your hard work.
I just tested Epiphany with the updated packages that you provided in
[1]. Are they self-contained or is yet another updated package
missing?
Indeed, even with your updated packages, Epiphany still crashes with
the scenario I described in this bug report, albeit
forwarded 659186 https://bugzilla.mozilla.org/show_bug.cgi?id=808512
thanks
Hi,
2012/10/25 Michael Biebl :
>
> TBH, I don't know who maintains the mozjs185 branch/fork and where the
> upstream bug tracker for that is.
> Unfortunately, mozjs185 looks pretty much unmaintained :-/
>
> Michael
I nev
Package: iceweasel
Version: 10.0~b2-1
Severity: important
Hello,
As reported in the debian-ia64 list back in March [1], Iceweasel 10.0
randomly stops responding, eating 100% CPU. There's no really a simple
scenario to reproduce this issue: normal web browsing activity
eventually ends up with Ice
tags 642750 - moreinfo
thanks
Hi,
Please find attached an updated gdb stacktrace for libwebkitgtk-3.0.0
1.8.1-3.3 and epiphany-browser 3.4.2-2 currently in Debian "Wheezy"
Testing when following steps described in Message #5
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642750#5).
Stacktrace
Nice :-)
Will this be forwarded upstream too? I think that "generic" (i.e. not
"Debian-packaged") mozjs185 is affected. This is at least also the
case with Gentoo ia64.
Best regards,
Emeric
2012/10/25 Michael Biebl :
>
> Thanks a lot Stefan for the patches and thanks Emeric for testing.
>
Hi,
Bill MacCoskley, author of commit 3c429287dfbe [1] is not convinced
that this commit is responsible for the present ia64 JS engine
problems, even if Mike thinks so [2] ;-)
I too mistakenly thought this was the case [3]. Indeed, when Stephan
noticed that "the pages_map() function in memory/jem
Hi,
JS engine is once again completely broken on ia64 since, at least,
commit 3c429287dfbe [1] that reverted changes allowing to turn off
static strings allocation [2]. Mike Hommey already pointed out this
issue for more than a year [3], but nobody seems to care about ia64
since then. That's for t
Sorry for the late answer, I completely missed this request!
Patched libmozjs185 [1] didn't solve the issue, though GNOME Shell
crashes in a slightly different way. As I no more have my Debian
development HDD available (currently evaluating Gentoo on it), I can't
give an updated stacktrace at the
Hello,
To pass parameters to kernel, add an append= line in your elilo.conf
file, just below the initrd= line. In the present case:
append="debug=vc"
Please find attached the log that I've just recorded on a serial
console passing debug=vc to kernel.
Well, I don't see anything useful or dif
Hi,
Tony Luck proposed a patch to fix this issue in
https://bugzilla.kernel.org/show_bug.cgi?id=42757.
Current Debian Testing kernel 3.2-14 locally rebuilt including this
patch works as expected :-)
Many thanks,
Emeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.o
Package: linux-image-3.2.0-1-mckinley
Version: 3.2.4-1
Severity: important
As reported first in
http://lists.debian.org/debian-ia64/2012/01/msg00016.html, I'm getting
stability issues with kernel > 2.6.38.
I've bisected the problem to commit
37a9d912b24f96a0591773e6e6c3642991ae5a70 (futex: Saniti
OK.
BTW, was Mike on IRC referring to this issue?
https://bugzilla.mozilla.org/show_bug.cgi?id=589735
Emeric
Le 9 février 2012 10:16, Michael Biebl a écrit :
> On 09.02.2012 10:03, Émeric Maschino wrote:
>> Thank you for pointing this out.
>>
>> Just a questio
On 09.02.2012 00:10, Émeric Maschino wrote:
>> Package: gnome-shell
>> Version: 3.2.2.1-1
>> Severity: important
>>
>> Hello,
>>
>> Gnome Shell cannot be started at all on ia64/IA-64/IPF (Itanium)
>> platform. It instantly crashes at startup, receiving
Package: gnome-shell
Version: 3.2.2.1-1
Severity: important
Hello,
Gnome Shell cannot be started at all on ia64/IA-64/IPF (Itanium)
platform. It instantly crashes at startup, receiving SIGSGEV from
/usr/lib/libmozjs185.so.1.0. Gnome Classic starts up fine.
Please find in attached the gdb output.
Hi,
Just to let you know that Qt 4.7.4-2 in today's Debian Testing
"Wheezy" updates didn't solve the problem.
Émeric
Le 20 septembre 2011 02:28, Adam Majer a écrit :
> On Tue, Sep 20, 2011 at 12:17:00AM +0200, Émeric Maschino wrote:
>> Thanks to snapshot.d
Hi,
Unfortunately, still the same issue. Please have a look at the attached gdb.txt.
This is with epiphany 3.2.1-2 and webkit 1.6.1-5+b1 currently in Debian Testing.
Hope this helps and let me know if you need more information.
Émeric
Le 17 janvier 2012 01:46, Michael Gilbert
a écrit :
Le 15 janvier 2012 19:08, maximilian attems a écrit :
>> Nice detective work. So the next question is: why does klibc-utils on
>> ia64 provide /usr/lib/klibc/bin/sh instead of sh.shared like other
>> architectures?
>
> #439181 ia64 works only static
Thanks for pointing this out.
>> I'd also be
Hi,
I've identified the root cause of this issue: busybox hook is called
_before_ klibc one. This ends up with /bin/sh binary in the generated
initrd.img being a copy of (or a symlink to) system
/usr/lib/klibc/bin/sh binary whereas it is expected to be a copy of
(or a symlink to) system /bin/busyb
Le 14 novembre 2011 23:51, Jonathan Nieder a écrit :
>> So, to summarize, only libgconf.so and libsmartcard.so didn't need to
>> be replaced by recompiled versions without -z defs flag. I don't know
>> if it'll help further, but they can even be removed from
>> /usr/lib/gnome-settings-daemon-3.0 a
2011/11/13 Émeric Maschino :
> I'm not sure if the lock up during the WebGL tests still appears on
> the same test. If yes, I imagine it will help understand what's going
> on. I'll try to have a reproduceable error.
Unfortunately, WebGL test suite not always locks up
2011/11/13 Josselin Mouette :
> I find this dubious. The point of keeping metacity for the fallback mode
> is that it still does everything in software, or only with RENDER
> acceleration; it does not use OpenGL.
Could it thus be possible that RENDER acceleration "globally
struggles" the GPU so th
Package: metacity
Version: 2.34.1-2
Severity: important
Hello,
With the delivery of GNOME 3 into Testing, Metacity was upgraded from
version 2.30.1-3 to version 2.34.1-2.
Since then, I'm experiencing stability issue when running
"OpenGL-intensive" applications (e.g. ioQuake3-based applications o
Patrice,
The "Loading please wait..." issue you're experiencing isn't due to
udev, but to initramfs-tools 0.99.
See my bug report
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=638068) and feel
free to add comment.
> Hi,
>
> I have got the same trouble after restarting a IA64 server running a
From: Émeric Maschino
Subject: ia64: Add accept4() syscall
While debugging udev > 170 failure on Debian Wheezy
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648325), it appears
that the issue was in fact due to missing accept4() in ia64.
This patch simply adds accept4() to ia64. The
a
2011/11/11 Ben Hutchings :
> On Fri, Nov 11, 2011 at 07:48:24PM +0100, Émeric Maschino wrote:
>> 2011/11/11 Ben Hutchings :
>> Isn't Wheezy eglibc 2.13-21 supposed to already implement accept4()?
>
> That is a little difficult when the system call is not even defined
>
2011/11/11 Ben Hutchings :
> That version just calls the libc implementation of accept4(), which
> won't work until libc is rebuilt. You need to define __NR_accept4 and
> call syscall(__NR_accept4, ...) in the test program instead.
Isn't Wheezy eglibc 2.13-21 supposed to already implement accept4
2011/11/11 Ben Hutchings :
>> --- a/arch/ia64/include/asm/unistd.h 2011-03-15 02:20:32.0 +0100
>> +++ b/arch/ia64/include/asm/unistd.h 2011-11-10 21:27:31.0 +0100
>> @@ -315,11 +315,12 @@
>> #define __NR_fanotify_init 1323
>> #define __NR_fanotify_mark
2011/11/10 Ben Hutchings :
>> > But I do not understand why nobody else noticed this, unless you are the
>> > first person to install wheezy on ia64.
>>
>> That seems entirely plausible.
Definitely since:
- netinst Wheezy CD-ROM is unbootable on ia64 (although Squeeze was fine)
- initramfs-tools 0
2011/11/10 Jonathan Nieder :
> Thanks. What would be really useful is a linker command line and the
> collection of object files (.o, .a, and .so, including relevant system
> libraries from /usr/lib/) that it refers to, as described in
> /usr/share/bug/binutils/presubj. Feel free to send these to
accept4() isn't implemented,
right?
Is it thus a kernel-related issued rather than an udev one?
Émeric
2011/11/7 Marco d'Itri :
> On Nov 07, Émeric Maschino wrote:
>
>> It seems that SOCK_CLOEXEC is thus correctly defined, don't you think so?
> Yes, but t
Hello Marco,
2011/11/6 Marco d'Itri :
> On Nov 06, Émeric Maschino wrote:
>
>> Starting with udev 170 (well, IIRC!), console is flooded at startup with:
>> udevd[XXX]: unable to receive ctrl connection: Function not implemented
> Your lacks support for SOCK_CLO
Package: udev
Version: 172-1
Severity: important
Hello,
Starting with udev 170 (well, IIRC!), console is flooded at startup with:
udevd[XXX]: unable to receive ctrl connection: Function not implemented
where XXX is a number (PID?).
And system takes ~3 min. to get login prompt.
Last udev v
Hi,
Any progress on this? How can I help further?
It's still impossible to either install Wheezy on ia64 from Debian
netinst CD or upgrade from a running Lenny system as kernel > 2.6.38
need initramfs-tools 0.99 that produces unbootable initrd images.
Best regards,
Émeric
--
To UNSUBSCR
Hello Mike,
2011/10/6 Mike Hommey :
> That would waste a 64-bits word. The usual way to do it is to use
> unions:
> union {
> PRUint64 dummy;
> struct {
> PRUint32 m0;
> PRUint16 m1;
> PRUint16 m2;
> };
> };
>
> Mike
nsID 64-bit alignment issue was already tracked down:
https://bugzil
2011/10/6 Mike Hommey :
> On Thu, Oct 06, 2011 at 12:21:29AM +0200,
>
> That would waste a 64-bits word. The usual way to do it is to use
> unions:
> union {
> PRUint64 dummy;
> struct {
> PRUint32 m0;
> PRUint16 m1;
> PRUint16 m2;
> };
> };
Thanks for pointing this out. I've never see
OK, reading http://www.osronline.com/ddkx/kmarch/64bitamd_20iv.htm
helped me understand structure alignment (well, I think!): "The
alignment of the beginning of a structure or a union is the maximum
alignment of any individual member."
> 2011/10/5 Mike Hommey :
> On Wed, Oct 05, 2011 at 10:50:56AM
2011/10/5 Mike Hommey :
> On Wed, Oct 05, 2011 at 10:50:56AM +0200,
>
> The problem is not the alignment of m2, the problem is the alignment of
> the whole struct, which has a requirement of 32-bits. Which means a
> struct nsID can end up at 0x0, 0x4, 0x8, or 0xc. When it's at 0x4 or
> 0xc, it can'
2011/10/4 Mike Hommey :
> On Tue, Oct 04, 2011 at 10:20:16PM +0200, >
> m0 is a 32-bit value, it needs 32-bits alignment. m1 is 16-bits, 16-bits
> alignment, etc. Overall, the struct only requires 32-bits alignment.
Reading http://en.wikipedia.org/wiki/Data_structure_alignment, I
thought that gcc
I don't understand. What prevent nsID from being 64-bit aligned? Don't
m0, m1 and m2 fit in a 64-bit word and m3 in yet another one?
Émeric
2011/10/4 Mike Hommey :
> On Tue, Oct 04, 2011 at 08:11:17PM +0200, Émeric Maschino wrote:
>>
>> struct nsID {
>>
Sorry for the late reply.
2011/9/28 Mike Hommey :
> On Tue, Sep 27, 2011 at 10:32:17PM +0200, Émeric Maschino wrote:
>
> Thanks so in fact the error is on the next line, and is due to this
> code:
> inline PRBool Equals(const nsID& other) const {
> return
>
2011/9/27 Mike Hommey :
> Could you add the output for "disassemble" and "info registers" ?
>
> Mike
Sure! Please find the attached gdb.txt.
Émeric
(gdb) run
Starting program: /usr/lib/iceweasel/firefox-bin
[Thread debugging using libthread_db enabled]
[New Thread 0x700088cb1e0 (LWP 5714)]
[
Mike,
2011/9/25 Mike Hommey :
> nsISupportsImpl.cpp:44 is:
> while (entries->iid) {
>
> entries is 0x70004008fb8, and its type is a pointer to:
>
> struct QITableEntry
> {
> const nsIID *iid;
> PROffset32 offset;
> };
>
> I fail to see how this can be unaligned...
>
> What is the correspond
Mike,
2011/9/25 Mike Hommey :
> nsISupportsImpl.cpp:44 is:
> while (entries->iid) {
>
> entries is 0x70004008fb8, and its type is a pointer to:
>
> struct QITableEntry
> {
> const nsIID *iid;
> PROffset32 offset;
> };
>
> I fail to see how this can be unaligned...
>
> What is the correspond
Package: xulrunner-6.0
Version: 6.0.2-1
Severity: normal
As Iceweasel 6.0 (more precisely the JS engine as I understand it
correctly) is currently being (actively?) debugged on ia64 (and
probably other platforms too), I think it may be useful to report the
various unaligned access messages reporte
Package: epiphany-browser
Version: 3.0.4-1
Severity: important
Epiphany is barely usable on ia64 platform (crashes *VERY* frequently).
Steps to reproduce:
- start up Epiphany; default page is http://www.debian.org
- go to http://www.google.fr and search for Debian
- click on the second Google hit
2011/9/20 Mike Hommey :
> Not at all, it's the js engine that doesn't work on ia64, and the
> patches to make it moslty work have been applied to 6.0.2-1
https://bugzilla.mozilla.org/show_bug.cgi?id=589735 seems a good candidate.
>> Is it worth reporting further issues against Iceweasel 5.0-6 or
Is this related to build problem with gcc 4.6:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635153 (g++-4.6: ICE
on ia64 when building iceweasel 5.0-4)?
Is it worth reporting further issues against Iceweasel 5.0-6 or is it
better to play and report bugs against Iceweasel 6.0-2 right now?
Epip
Thanks to snapshot.debian.org, I can confirm that qtcreator 1.3.1-3
currently in Debian "Wheezy" Testing can be run successfully with Qt
packages up to 4.7.1-2. Starting with Qt packages 4.7.2-1, Qt Creator
crashes with a bus error.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.deb
Package: qtcreator
Version: 1.3.1-3
Severity: important
Qt Creator crashes at startup with a bus error. I can briefly see the
main window being drawn (completely empty, just the Qt Creator title
window, with Qt Creator icon and system buttons are shown).
I don't know if it will help, but console
Hi,
> FWIW amid the reports merged with this one, there is one person using
> i386 and another using mipsel.
I don't know for i386 and mipsel, but here are my investigations for ia64.
> From the point of view of fixing this in binutils, it would be _very_
> helpful to have a collection of object
Hi,
I've looked at the source package: the debian/build script still
passes -z defs flags to ld, thus producing a broken binary, as
expected :-(
Regards,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
Hi,
> does initramfs-tools boot with BUSYBOX=no in initramfs.conf?
Well, I don't know! Indeed, with BUSYBOX=no in initramfs.conf,
initrd.img generation fails:
root@longspeak:/# dpkg-reconfigure linux-image-3.0.0-1-mckinley
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /et
Package: initramfs-tools
Version: 0.99
Severity: grave
As stated in this thread
http://lists.debian.org/debian-ia64/2011/08/msg1.html, Debian
"Wheezy" Testing cannot be booted at all on IA-64 (current
linux-image-3.0.0-1-mckinley in Testing depends on initramfs-tools
0.99, so initramfs-tools c
Hi,
I've looked at the source package: the debian/build script still
passes -z defs flags to ld, thus producing a broken binary, as
expected :-(
Regards,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas
Sorry for the delay,
>> > Anyway, it would be great if you could report this upstream at
>> > http://bugs.freedesktop.org/enter_bug.cgi?product=Mesa , component
>> > Drivers/Gallium/r300. The main upstream r300g developer (Marek Olšák) is
>> > usually quite responsive to bug reports.
Done. See ht
Hello Michel,
> If you pass --with-dri-drivers=r300 to configure, the classic driver
>
Allright, this time it worked :-)
I probably misunderstood that the "How to build mesa" page was only
dealing with the Gallium driver.
So, back to your initial question
Hello Michel,
> If you pass --with-dri-drivers=r300 to configure, the classic driver
> should end up in lib/r300_dri.so, as opposed to r300g in
> lib/gallium/r300_dri.so . You can override libGL's search path with the
> LIBGL_DRIVERS_PATH environment variable, and if you also set
> LIBGL_DEBUG=ver
Le 14 avril 2011 10:29, Michel Dänzer a écrit :
> Does the classic driver still work?
Well, now that I've rebuilt Mesa Git with Gallium support, how do I
switch GL rendering back to Mesa classic?
I tried recompiling the whole thing, removing --enable-gallium-radeon
from ./configure options befor
Hi,
Just finished recompiling mesa git following this guide
http://pkg-xorg.alioth.debian.org/howto/build-mesa.html. Everything
ran as described, except for the last section (I'm getting no libEGL
debug messages with glxgears).
Still the same issue however :-(
Émeric
--
To UNSUBSCRIBE, em
Hi Michel,
> The r300g driver shipped in current libgl1-mesa-dri only works with KMS,
> so with that disabled, you're probably getting software rendering.
I should have noticed it earlier!
You're right, GL rendering with libgl1-mesa-dri 7.7.1-4 is done
through r300c driver, whereas it's done thr
Hi,
Version 7.10.2-1 is currently not available for IA-64. However version
7.10.1-1 is, so tested with it (also upgrading related packages). Same
issue unfortunately :-(
Émeric
2011/4/12 Cyril Brulebois :
> severity 622299 important
> thanks
>
> Hi,
>
> Émeric Mas
Hello again,
> Thanks for your hard work tracking this down, and thanks for bringing
> it to our attention. I'm going to merge this with the existing
> gnome-settings-daemon bug, so the problem is tracked in one place.
>
> Of course it is possible there is a binutils involved here somewhere.
> If
Hi,
> -z defs means to disallow undefined symbols in object files. Are you
> sure that there is not some undefined symbol in an object file and
> this is not build system/runtime behavior fallout from that?
I know nothing about gnome-settings-daemon code and related software,
so can't make any a
Hi,
As explained here
(http://lists.debian.org/debian-ia64/2011/03/msg00017.html), this
issue isn't due to a code change in gnome-settings-daemon, but to a
change in the flags passed to ld by the debian/rules build script of
the gnome-settings-daemon source package.
Simply removing -Wl,-z,defs fr
Package: binutils
Version: 2.20.1-16
Severity: critical
As explained in this post
(http://lists.debian.org/debian-ia64/2011/03/msg00017.html),
gnome-settings-daemon is broken on IA-64 (Itanium) since release
2.24.1-1 dated 2008-12-30, not because of a source code change, but
because of a change in
Hi,
FYI, manually installing apt 0.8.13.1 (dated 2011-04-03) using dpkg -i
made apt happy again.
Regards,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi,
I don't know if the root cause is the same, but here's the stack trace
I'm recording with current epiphany-browser in Debian Squeeze on an
Itanium workstation.
emeric@longspeak:~$ gdb epiphany-browser
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+:
FYI,
gnome-settings-daemon 2.30.2-2 available in yesterday's Debian Squeeze
updates didn't solve the problem.
Cheers,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
FYI,
gnome-settings-daemon 2.30.2-1 available in Debian Squeeze updates
didn't solve the problem.
Cheers,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
FYI,
gnome-settings-daemon 2.30.1-1 available in yesterday's Debian Squeeze
updates didn't solve the problem.
Cheers,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hi,
Thanks to the new snapshot.debian.org service (great feature!), I've
performed regression testing and have the strong impression that this
issue isn't due to D-BUS or GLib at all, but to gnome-settings-daemon.
Indeed, starting from my current Squeeze installation and downgrading
gnome-setting
FYI,
gnome-settings-daemon 2.28.1-3 available in today's Debian Squeeze
updates didn't solve the problem.
Cheers,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
FYI,
D-BUS 1.2.24-1 available in today's Debian Squeeze updates didn't
solve the problem.
Cheers,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
2010/2/2 maximilian attems :
>> I've bisected this problem to commit
>> f1a2a9b6189f9f5c27672d4d32fec9492c6486b2 (drm: Preserve SHMLBA bits in
>> hash key for _DRM_SHM mappings), during kernel 2.6.30 development cycle.
>
> please report upstream on bugzilla.kernel.org and let us know
> the bug nr s
2009/11/6 Julien Cristau :
> My guess would be the kernel, but the best place to find developers who
> might be able to help you is likely to be the dri-de...@lists.sf.net
> mailing list (you're probably one of the only people to use graphics on
> ia64 though).
>
> (I asked Dave Airlie on irc when
FYI,
Today's Debian Squeeze gnome-settings-daemon 2.28.1-1+b1 update didn't
solve the problem.
Regards,
Émeric
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Hello,
OK, I'll try the dri-devel list.
Thank you for your time anyway.
Émeric
My guess would be the kernel, but the best place to find developers who
> might be able to help you is likely to be the dri-de...@lists.sf.net
> mailing list (you're probably one of the only people to use graphi
Hello,
I don't know where exactly this problem resides, but just to let you know
that Debian Squeeze libdrm2 2.4.13-1 update didn't help.
Regards,
Émeric
1 - 100 of 106 matches
Mail list logo
