Port-amd64 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Is amd64 ready for the desktop?



I' using it on a dual, dual-core Xeon (4 cores) system every day. As a desktop, it works fine for me. OS version is NetBSD 4.99.54.

I do nothing with music or other audio.

The system did not work reliably for me until I updated the BIOS to correct for a CPU firmware bug.

D'Arcy J.M. Cain wrote:
My experience is no but before I switch back to i386 I thought I would
see what others' experiences are.

First of all, the NetBSD system itself seems to be extremely stable.
As a server system I suspect it is just fine.  All of my problems seem
to be with add-on packages and only a handful at that.  Unfortunately
those few packages are the ones that I need on the desktop.

I assume that the problems stem from apps not being as 64 bit careful
as NetBSD itself is.  I have tried to investigate some of these but I
haven't been able to track things down.  Here are a few programs I am
having trouble with;

Although mplayer works it seems to fail on some certain files.  Under
i386 I never had any problems.  In fact when I have problems I simply
switch to my wife's i386 machine and play them there.  Music files are
mostly fine.  It is video that seems to have problems.

I use gramofile which is a curses or ncurses based app.  The screen is
messed up by strings that look like this:
    "bad format `p'ooooooooooooooooooooooooooooooooooooo..."

Audacity won't run at all.  It dumps core.  I tried building everything
with symbols but I don't get full information on the backtrace:

Program terminated with signal 11, Segmentation fault.
#0 0x00007f7ff9e2c887 in type_node_check_conformities_UorL (node=0xf644d4e0, iface_node=0x7f7ff6447940, support_interfaces=1,
support_prerequisites=1, have_lock=0) at gtype.c:2719
2719      if (/* support_inheritance && */
(gdb) bt
#0 0x00007f7ff9e2c887 in type_node_check_conformities_UorL (node=0xf644d4e0, iface_node=0x7f7ff6447940, support_interfaces=1,
support_prerequisites=1, have_lock=0) at gtype.c:2719
#1 0x00007f7ff9e2cb5b in type_node_conforms_to_U (node=0xf644d4e0, iface_node=0x7f7ff6447940, support_interfaces=1,
support_prerequisites=1) at gtype.c:2753
#2 0x00007f7ff9e2cb0d in IA__g_type_is_a (type=4131706080, iface_type=140187569256768) at gtype.c:2765
#3  0x00007f7ffc4f056a in IA__gtk_type_new (type=4131706080)
    at gtktypeutils.c:102
#4  0x00007f7ffcb03f2d in gtk_pizza_new () from /usr/pkg/lib/libwx_gtk2.so.0
#5  0x00007f7ffcb01430 in wxTopLevelWindowGTK::Create ()
   from /usr/pkg/lib/libwx_gtk2.so.0
#6  0x00007f7ffcadafe0 in wxFrame::Create () from /usr/pkg/lib/libwx_gtk2.so.0
#7  0x00007f7ffcadbf0a in wxFrame::wxFrame () from /usr/pkg/lib/libwx_gtk2.so.0
#8  0x000000000042b538 in AudacityApp::OnInit (this=0x7f7ff649a1e0)
    at AudacityApp.cpp:462
#9  0x00007f7ffcab98b3 in wxEntry () from /usr/pkg/lib/libwx_gtk2.so.0
#10 0x000000000042cac1 in main (argc=1, argv=0x7f7fffffd2f0)
    at AudacityApp.cpp:196
Current language:  auto; currently c

I suspect that the problem is in the gtk2 libraries but it is difficult
to follow without full symbols.

So, are there any recent changes that fix some of these issues?  Am I
just going to find other problems later?  I would be happy to keep the
system in amd64 for a little while longer if I can help debug things
but since it seems to be third party problems I don't see what we can
do in the short term.



--
John R. Shannon


Home | Main Index | Thread Index | Old Index