[pvrusb2] HVR-1950 driver loading problem

[JE Geiger]

Slackware was the first Linux distro I used.  It was a gimme CD from my
brother.  Before that I ran Coherent and uucp to get e-mail with a 9600 baud
Telebit modem.  My how things have changed for the better.

I am using the Fedora 10 DVD to reformat and reload the AMD 64 X2 and will
soon be able to test if the pvrusb2/HVR-1950 comes back to life.  Fedora
does not go backward gracefully so a reload from scratch was in order.  

The Intel Pentium D was still on Fedora 10 and thus using an older gcc.  

If this fixes it, I don't know what to do other than run  older version on
the mythtv box.  At the very least we can terminate this thread.   

-----Original Message-----
From: pvrusb2-bounces at isely.net [mailto:pvrusb2-bounces at isely.net] On Behalf
Of storkus at storkus.com
Sent: Wednesday, June 17, 2009 3:38 PM
To: Communications nexus for pvrusb2 driver
Subject: Re: [pvrusb2] HVR-1950 driver loading problem

You're wrong on that: the compiler generates code for the architecture and,
if given, specific processor.

On 32 bit, there are a slew of optimizations and code generating options for
different processors from Intel, AMD, the old Cyrix processors, etc.
 Most distros have their compilations set at a generic default so the code
will run on any processor family and higher.  However, if a something
specific is being thrown in there like "-march=xxx", that could break
something when going from one processor to another.  If Fedora did something
like that, it's their fault.

On 64 bit things are much simpler (for now): as long as you specify
something like "-mcpu=x86_64" (I think this flag name may have changed),
you'll see code that should work on either Intel's EM-64T or AMD's AMD-64.
OTOH, specifying "-march=amdk8" (if I remember right) will throw in
AMD-specific optimizations that may/will break on Intel.

Finally, I've heard that using different compiler versions can break ABI's,
so be careful.

I use Slackware myself, so I can't comment on anything directly
Fedora-related.