[Note that there is quite a list of things below to look at, but do look at the bugzilla entry at the very bottom and try that, possibly even first.] On Monday, January 24, 2011 02:09:52 pm Ashley M. Kirchner wrote: > What I don't get is how this dies with FC14 but not with CentOS 5 > ... did they figure out something that the FC developers haven't? No. The Fedora kernel is much newer than the C5 kernel, in terms of kernel version and IDE/ATA driver stack. CentOS 5, and Red Hat Enterprise Linux 5, are somewhat akin to Fedora *6* in terms of the versioning of the kernel. This does not mean security fixes since that kernel version have not been applied; they have been backported by Red Hat. What it does mean is that 17 versions of the 2.6 kernel (half of the versions to date) have passed, and the IDE/ATA drive handling has gone from the older IDE/ATA driver stack to the new libata driver stack, which makes the IDE/ATA drives be handled in the SCSI layer (and thus they become /dev/sdX# instead of /dev/hdX#). I find in the file "/usr/share/doc/kernel-doc-2.6.35.10/Documentation/i2c/busses/i2c-piix4" the statements: +++++++++++++++ If you own Force CPCI735 motherboard or other OSB4 based systems you may need to change the SMBus Interrupt Select register so the SMBus controller uses the SMI mode. 1) Use lspci command and locate the PCI device with the SMBus controller: 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f) The line may vary for different chipsets. Please consult the driver source for all possible PCI ids (and lspci -n to match them). Lets assume the device is located at 00:0f.0. 2) Now you just need to change the value in 0xD2 register. Get it first with command: lspci -xxx -s 00:0f.0 If the value is 0x3 then you need to change it to 0x1 setpci -s 00:0f.0 d2.b=1 Please note that you don't need to do that in all cases, just when the SMBus is not working properly. ++++++++++++++++ Don't know if you're hitting this or not. Although I think I actually have one of those Force Computers CompactPCI boards; I'll have to check, if so I can test this there, at some point (not this week; too busy). Your dmesg shows you do, in fact, have an OSB4-based system, so this might be a part of the problem. Check to see if RHEL6 support is available for this system; if so, there might be a workaround for RHEL6 that might apply to the kernel in F14. Hmmm, looking closer at you C5 dmesg, I find: [snip] type=1404 audit(1295620090.833:2): selinux=0 auid=4294967295 ses=4294967295 hdb: ATAPI 48X CD-ROM drive, 128kB Cache, (U)DMA Uniform CD-ROM driver Revision: 3.20 piix4_smbus 0000:00:0f.0: Found 0000:00:0f.0 device 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html [snip] Yeah, the line right after the CD-ROM line, which is where F14 is hanging, is a callout for the piix4_smbus init. Doesn't mean that's the culprit.... Another possibility is tracked in the thread, and kernel bugzilla, started here: http://kerneltrap.org/mailarchive/linux-kernel/2010/8/13/4606665 Can you see if F13 will boot up? F14 shipped with 2.6.35.6; F13 with 2.6.33.3. You might be hitting a variant of https://bugzilla.redhat.com/show_bug.cgi?id=665109 There is some specific advice in that Bugzilla entry to try. It seems some of these machines with this chipset actually have ACPI, but it's not exactly 'all there' and a workaround has to be used. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
