[log in to unmask] wrote:
> Hi Troy,
> 
> On Thu, 7 Jun 2007, Troy Dawson wrote:
> 
>> Devin Bougie wrote:
> [...]
>> About the kernel, I'm very nervous about this kernel, it comes with 
>> too many "If your motherboard and/or vendor model is this ... you have 
>> to do this ... or else this will happen."
> 
> Any pointers? This kernel does fix the intel hda sound on the dell 
> precision 390 that got broken with -42.0.3. We wants it...
> 

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/release-notes/RELEASE-NOTES-U5-x86-en.html
Specifically
MCFG on AMD-based Systems

     During PCI probing, Red Hat Enterprise Linux 4 Update 5 attempts to use 
information obtained from MCFG (memory-mapped PCI configuration space). On 
AMD-systems, this type of access does not work on some buses, as the kernel 
cannot parse the MCFG table.

     To work around this, add the parameter pci=conf1 or pci=nommconf on the 
kernel boot line in /etc/grub.conf. For example:

     title Red Hat Enterprise Linux AS (2.6.9-42.0.2.EL)
             root (hd0,0)
             kernel /vmlinuz-2.6.9-42.0.2.EL ro root=/dev/VolGroup00/LogVol00 
rhgb quiet pci=conf1
             initrd /initrd-2.6.9-42.0.2.EL.img

     Doing this instructs the kernel to use PCI Conf1 access instead of 
MCFG-based access.

We also found this little tidbit
http://kbase.redhat.com/faq/FAQ_46_10460.shtm
Why did the ordering of my NIC devices change in Red Hat Enterprise Linux 4.5?
The 2.6.9-55 version of the Red Hat Enterprise Linux 4 kernel (Update 5) 
reverts to the 2.4 ordering of network interface cards (NICs) on certain 
systems. Note that if the "HWADDR=MAC ADDRESS" line is present in the 
/etc/sysconfig/network-scripts/ifcfg-ethX files, the NIC ordering will not change.

To restore the original 2.6 ordering, which is different from the 2.4 ordering, 
boot with the option pci=nobfsort


>> Since this is not technically a security kernel, I personally want to 
>> wait for 2.6.9-55.0.1 before pushing it out as a security errata.  I'm 
>> hoping by then they've fixed at least some of the bugs.  Even then 
>> we're going to have to do some major announcing about the various 
>> changes it can do to your machine.
>>
>> When will SL4.5 be released?
>> Well, if you just want the rpm's, they are in the SL40rolling area 
>> already.
>> When will it be released?  Well the anaconda xen changes that TUV put 
>> in have
> 
> I take it then that 4.5 will have this. Good news.
> 

Remember that this is just that it will install paravirtualized, not that it 
will be a host.

>> slowed us down a bit.  We expect a new beta out by this weekend.
> 
> Could we update OpenAFS in 4.5? I've put up my latest SRPM in 
> http://www-zeuthen.desy.de/~wiesand/SL4/
> 
> It's 1.4.4 plus selected patches gobbled up from CVS. Many known bugs 
> are fixed, but of course chances are there are new ones. This build has
> received some testing here on a variety of SL4 systems for the last 
> week, and it's been doing well so far.
> 

Thanks Stephan,
I was going to ask you if you had any updates.  It looks like it's compiling 
clean with all my scripts.  It should be in the next beta.
Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__________________________________________________