[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 __________________________________________________