[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140529190455.GC18230@amd.pavel.ucw.cz>
Date: Thu, 29 May 2014 21:04:55 +0200
From: Pavel Machek <pavel@....cz>
To: Ken Moffat <zarniwhoop@...world.com>
Cc: David Hagood <david.hagood@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: Bug? Older 32 bit program (CivCTP) no longer works under 64
bit kernel
On Fri 2014-05-16 04:36:32, Ken Moffat wrote:
> On Thu, May 15, 2014 at 08:24:05PM -0500, David Hagood wrote:
> > I have an old native Linux 32 bit copy of Civilization: Call to Power. It
> > used to work under a 64 bit environment back in the 3.0.x days. However,
> > under recent versions (>3.5) it no longer runs - it complains that it cannot
> > find certain files in the directory. The exact same code will run just fine
> > under a 32 bit version of 3.11. I have a Pentium II as well as the Core 2
> > Duo, both running Ubuntu 14.04, same version of the kernel other than one is
> > 32 bit and one is 64 bit. I've copied the files over from the 32 bit
> > machine, where it runs, to the 64 bit machine, where it does not. I've even
> > gone so far as to copy all the system 32 bit libraries into the CivCTP
> > directory, and forced the program to use them (including using the
> > ld-linux.so loader from that directory) - so in theory it's all the same
> > user space libraries running - the only difference that I can see is that
> > one kernel is 64 bit and one is 32 bit.
> >
> > Running strace on the program shows that the directories being searched for
> > game assets are corrupted:
> >
> > 16218 stat64("/home/wowbaggr/CivCTP/ctdata/englisish/uidata/keymap.txt",
> > <unfinished ...>
> >
> > Note the "englisish" rather than "english".
> >
> > I'm looking for any suggestions on where to look for what might cause such
> > an issue - what can I do to start tracking this down.
>
> I've no ideas about what part of the kernel is causing this, so
> I'll just offer you some thoughts on how to track it down. At a
> guess, you will have to run 'git bisect' to nail which change broke
> this (or alternatively which change exposed a latent problem).
>
> Bisection is fairly well covered on google, for example it finds
> http://landley.net/writing/git-bisect-howto.html
>
> The corrupt filename looks (to me, with no experience) like
> something which might be in the filesystem area. It probably isn't,
> but I don't recall anything at all like this, so I'd better ask - are
> you using an uncommon filesystem for this data ? This looks like
> such a grievous fault that I would expect someone to have noticed it
> between 3.5.0 and now.
>
> And, have you tried any recent kernels (e.g. 3.14.4) to confirm
> that the problem still exists ? If it turns out that somebody
> already fixed it, that would save you a lot of effort.
And you can probably limit bisection to stat() compat code...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists