[TriLUG] Red Hat kernel challenge

[Joey O'Doherty]

I happen to have the nvidia driver (1.0-2960) running like a champ on an 
SMP AMD box running kernel 2.4.19, so it would appear any SMP problems 
were fixed with 2.4.19.

But, I'm running debian, so YMMV.

/joeyo


nroskam at rr.nc.com wrote:
> I was having similar problems with the nvidia driver and my laptop.  The
> redhat install for some reason chose the smp kernel.  I would check the
> forums at nvidia they have a linux specific section.  I remember reading
> something about problems with the smp kernel in their forums which why I
> moved to Mandrake.  
> 
> Rock Roskam
> Manager
> Eclectic LAN
> 9113 Leesville Road Suite 105
> Raleigh, NC 27613
> (919) 845-7407
> rock at eclecticlan.com
> www.eclecticlan.com
> 
> 
> -----Original Message-----
> From: trilug-admin at trilug.org [mailto:trilug-admin at trilug.org] On Behalf
> Of Jeremy Katz
> Sent: Wednesday, February 26, 2003 6:12 PM
> To: trilug at trilug.org
> Subject: Re: [TriLUG] Red Hat kernel challenge
> 
> On Wed, 2003-02-26 at 17:21, Matt Matthews wrote:
> 
>>NVIDIA does have a kernel package designed for use with the previous
> 
> two Red 
> 
>>Hat kernels, 2.4.18-14 and 2.4.18-18.8.0. However, the SRPMs for these
> 
> two
> 
>>kernels REFUSE to rebuild on a Red Hat 8.0.94 system, as far as I can
> 
> tell.
> 
>>They both bomb out late in the process with:
>>Processing files: kernel-debuginfo-2.4.18-14
>>error: Could not open %files file
> 
> /usr/src/redhat/BUILD/kernel-2.4.18/debugfiles.list: No such file or
> directory
> 
> Add --define "debug_package %{nil}" to your rpmbuild command line (or
> change the spec file to have "%define debug_package %{nil}" or add that
> to your ~/.rpmmacros)
> 
> 
>>Given that these are standard Red Hat kernel SRPMs, I was very
> 
> surprised to 
> 
>>find that neither would build on the newer system.
> 
> 
> There have been some features added to the RPM build process that don't
> get along with the kernel (basically, packages are built with -g and
> then debugging information is stripped out and put into a separate
> package.  This is *really* handy for debugging those crashes that
> someone else can see all the time but you can't reproduce -- tell them
> to get the -debuginfo package and you get a backtrace from gdb with full
> symbols.  Woo-frickin-hoo! :)
> 
> Cheers,
> 
> Jeremy
> 

-- 
pub  1024D/B663781B 2001-11-13 Joey O'Doherty <joey(at)odoherty(dot)net>
Key fingerprint = F76B 9ACA 4197 C707 6E4D  2B78 E430 101A B663 781B