[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-user
Subject:    Re: [gentoo-user] downgrading gcc
From:       Mark Knecht <markknecht () gmail ! com>
Date:       2009-04-20 13:36:07
Message-ID: 5bdc1c8b0904200636s27f208fbi99288b5f3c64db95 () mail ! gmail ! com
[Download RAW message or body]

On Mon, Apr 20, 2009 at 12:48 AM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
> On Monday 20 April 2009 09:30:56 Dale wrote:
>> That said, it has worked well for me.  Everything on my rig is working
>> again.  If he has to do this downgrade of gcc, then a emerge -e world
>> and everything works again, I'm going to really wonder what the deal is
>> with gcc.  Just me running into problems is one thing but to have
>> someone else have issues as well, that's makes me wonder.  Is there
>> something funny going on that only affects certain hardware or something
>> like that?  How would one test it to see what is wrong when it is only a
>> couple or a few people?
>
> It's more likely a compatibility issue between very specific modules or bits
> of code that affect lots of systems. Take for example this elog from the
> nvidia drivers:
>
> ===
> This ebuild installs a kernel module and X driver. Both must
> match explicitly in their version. This means, if you restart
> X, you most modprobe -r nvidia before starting it back up
> ===
>
> The interfaces that these things use have never been guaranteed to be stable,
> and gcc itself is free (within reason) to lay things out in memory anyway it
> sees fit. You get the same thing with X and it's drivers too. It makes sense -
> a server and it's drivers should all be part of the same release series and be
> built together with the same toolchain for best results.
>
> You DON'T get this problem with normal packages. You can upgrade and downgrade
> cairo all day long if you want and firefox won't care - the API it uses is
> stable and doesn't change.
>
> In your case and Mark's, you tried to downgrade something critical but have no
> information about what you should be downgrading to. When you synced portage,
> you lost the information about what was the latest arch and ~arch versions.
> Upgrade is easy - "emerge latest <arch> for everything, we know it works", but
> portage doesn't offer a rollback function so downgrade is much harder. Once
> someone has figured out $LIST, you can "emerge $LIST" and life is good, but
> you don't have $LIST yet.
>
> Logic tells me you had two problems, and gcc is neither of them. Your box does
> not like latest X for whatever reason (problem 1) but you can't rollback to
> the last working version of everything involved as you don't know what it is
> (problem 2).
>
> So when all other efforts have failed, downgrade gcc and rebuild everything is
> very likely to fix those problems.
>
> --
> alan dot mckinnon at gmail dot com
>
>

Alan,
   Hi. Thanks for your inputs and help. I appreciate it.

   I think you've covered most of the issues fairly clearly. What you
cannot cover is the specifics of my hardware, so I'll try to do this
based on what I think I've learned. As best I can tell the failure I'm
seeing is a segfault in the Intel VGA driver when doing xv video.
OpenGL works fine, and other than xv the Intel driver works fine for
me. Using mplayer I can watch videos when I choose OpenGL rendering.
All applications fail when using xv, but my initial realization came
from mythfrontend which is why this has had a 'mythtv segfaults' title
in the past. None the less it's really xv. There are 1 line segfault
messages in different log files after the crash pointing at the i915
driver saying it cannot pin an xv buffer in memory. This is apparently
known at X.org as I found and posted my results in an existing bug
report - one of many on apparently the same issue.

   Note that if you, or the person who decided to mark xorg-server-1.5
and gcc-4.3.2 stable didn't have Intel hardware, then only if they
actually ran xv video apps, they wouldn't have seen this problem. This
sort of problem is (to me) a root weakness of the Gentoo package
management system. Nothing is really 'stable' as it's not tested
against a wide range of known hardware platforms with a know set of
test cases before it's marked 'stable' so this sort of thing happens
now and again. There is no reason for you to say X isn't stable, or
gcc causes problems because everything works on your system. (Or you
think it does!) ;-)

   In my case I *think* the problem showed up only after rebuilding X
with gcc-4.3.2 but at this point I've unfortunately sort of lost track
of the whole history. I *believe* that gcc got upgraded, I switched my
compiler to the newer 4.3.2 version, then an X upgrade came along, got
built and started failing.

   My first attempt at fixing this was to downgrade xorg-server back
to 1.3. This failed, but it was built with the newer compiler so it
wasn't a real downgrade in the sense of going back to what I had
before. I then tried moving to xorg-x11-7.4 which some people at X.org
said fixed the problem for them. Unfortunately for me it didn't.

   Over the years this sort of thing has happened a few times with
Gentoo so maybe once every 2 years I'll do an emerge -e system, emerge
-e world just to make sure everything is up to date. As I was having
problems I decided to do that and move the whole machine to 4.3.2. I
got started with that process a couple of days ago.

   Around that time Michael was having trouble with his USB hardware
and the thread had similarities. His solution was to downgrade gcc.
However I had already started rebuilding my machine with the new
compiler so I couldn't really do that, nor did I want to because if it
was a mismatch between something compiled with 4.1.2 and 4.3.2 then it
should have been fixed with 4.3.2. Unfortunately moving the whole
machine to 4.3.2 didn't solve the problem. xv video still segfaults.

   This leaves me with a machine that's completely up-to-date but
unfortunately doesn't work the way it did for the last 3 years so as
an experiment I'm now moving the machine back to 4.1.2. This first
pass will get done tonight and maybe by tomorrow I'll know if X-7.4
and the newer Intel driver is functional with 4.1.2. If it is, great.
If not, then I suppose I'll try going back to X-7.2/xorg-server-1.3.
Don't know.

   Anyway, I don't think I added any value with this post. Just
documentation and possibly some clarity.

Cheers,
Mark


[prev in list] [next in list] [prev in thread] [next in thread]