Description of Problem: Installing on a K7 with RH 7.2. Everything goes fine until you reboot. The kernel that is installed does a rdmsr on MSRs that do not exist on the K7. The PIII, for non-existent MSRs, will actually return a bad value, contrary to what the PII did and what the PIII should do. The K7, on the other hand, will take a GPF. The result is that a user can install RH 7.2 on a K7 box, will watch it all work, will reboot, and see his kernel come up and get a GPF and die horribly. We have worked around this at LANL but I was reminded of it by a user from another site just today. David Woodhouse told me to report it. Version-Release number of selected component (if applicable): RH 7.2 How Reproducible: Buy an off-the-shelf system with a (e.g.) PCCHIPS M810LMR motherboard and install with RH 7.2. Wait for the reboot after install. BOOM! Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information:
Ron, this is not the way to report it, I am sorry to say. Surely, as LinuxBIOS leader you understand that we'd like to see the oops trace. The approved way to capture it is to use a serial console, but some people do get creative. I saw them attaching JPEGs of screen images...
Actually, cancel that - the description is good, but I am not sufficiently familar with that part of the code to cook up a fix right away. And I still like to see the trace so that I know what file to open in vi :) Did you try to poke linux-kernel on your own with this problem?
Sorry for the lack of an oops trace. I don't have serial console (this is the first boot after an install) and it never occured to me to take a picture. Usually that text is borderline-readable. I think the issue is that you are shipping a PIII kernel with the PIII serial # feature enabled in .config. When the K7 hits that code, you get the GPF as there is no such MSR in the K7. I'll have to see if this is fixed in 7.3 when I get time. ron