Re: current state of sid (unstable)
On 4/08/2010, at 1:48 AM, Bob Tracy wrote:
(1) DRI is broken again.
That may've happened when much of the DRI was shifted into the kernel.
(2) KMS works at the console level but breaks when X is started.
But I wouldn't be too worried about that as we are in good company.
KMS is reported to be only working well on x86/amd64 and powerpc, and
there is a recent report someone did have it running on Sparc "once".
Actually, when I think about, I think KMS is broken at console level
on the Debian Alpha kernel. Strange as every kernel I have built
myself always worked but the Debian kernel leaves the display blanked
(i.e. no signal). But I hardly ever run a Debian kernel (I usually
have some new piece of hardware or want some feature that requires
running a near leading edge kernel) so took little notice of that
problem.
(4) The Radeon driver is working for at least one person with UMS.
Yeah, that's me. I have a rv610 card in my XP1000 running Debian
Unstable. The only problem I've noted (other than that DRI is broken)
is the hardware cursor is often partially corrupted. I also have
r100, rv280, and rv710 cards and I think they all work OK (though I
haven't done thorough testing but can do so if it is deemed necessary).
(5) Some long-standing compiler and libc issues have been fixed
upstream and in Debian, but recently, a build of libc in Debian
Unstable failed.
I see the memchr seg fault bug (521737) is still open. I have a hunch
that it may be a false-positive, i.e., the testing software (electric
fence and a test script in m4) may be imposing conditions that are not
correct for Alpha. It's a standard ldq_u for loading a byte within a
quadword that is failing. If the correct quadword is being loaded
then that shouldn't trip a seg fault no matter what byte in it is
being loaded, even if the byte is pass the end of the string, right?
I do mean to take a closer look at this one to work out exactly what
is going on.
(6) gnome-settings-daemon is *still* plagued by segfaults, which makes
it difficult/impossible to set up any desktop preferences other
than
the default. mcree is attempting to debug the problem, and found a
"dodgy" machine instruction on disassemble. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=525031 for more
info if anyone wants to lend a hand.
If someone who knows Alpha assembler and the workings of the dynamic
linker could take a look at that one and give me advice on how to
proceed debugging it that would be great! I consider this the most
annoying bug!
iceweasel on Alpha has historically
been "barely useful" at best.
Yeah, iceweasel in unstable had been quite broken for some time. The
latest version is better, it starts up and I can browse quite a few
web pages. But it crashes as soon as I click the history menu item.
That's why I've typically built my own firefox from the
standard mozilla source tree (monolithic build with libxul.so, no
wrapped
xulrunner). Unfortunately, firefox-3.6.8 built with an up-to-date
lenny
environment suffers from the same persistent segfault issues,
Due to the iceweasel problems I have been running icecat from the 3.6
series in a "monolithic build" for quite some time without any
problems. I am still running 3.6.7 but since you say firefox 3.6.8 is
segfaulting I am now compiling icecat 3.6.8 and will let you know how
it goes.
Comments welcome. I've received one strong recommendation to give
Gentoo a try,
Matt, no doubt :-/ He's a great evangelist for Gentoo.
presumably because the Alpha platform is still supported
by Gentoo.
Well, to note, the Alpha platform is not completely unsupported by
Debian. That Alpha is still in Debian Unstable attests to that fact.
I tried installing Gentoo about a year ago on a PWS600au but had such
a bad experience that I have never looked at Gentoo again. It took a
whole weekend to just get the machine to boot to the point that I
could actually log in to the shell on the console. There were quite a
number of boots into a machine for which all of the keyboard, the
serial port and networking didn't work so I couldn't get access,
rebooting with the rescue disk and manually running every step of the
boot process to get the gentoo system up to a useable state and then
recompiling the kernel. Bah, humbug, I like to spend my weekends
doing more useful things than that.
Cheers
Michael.
Reply to: