Red Hat Bugzilla – Bug 163317
FC4 kernels oops apparently in a search for serial ports
Last modified: 2015-01-04 17:20:59 EST
Description of problem:
While booting a dual processor x86_64 board from RIOWORKS the following
Unable to handle kernel paging request at 0000000f804f0c54 RIP:
Full dmesg output attached.
So far there are two known ways to prevent that. One is to boot with acpi=off
(and options like pci=noacpi, or pci=routeirq, or noapi, or anything else
I tried do not help). The other one is not to start cups. When cups is
turned off and later started manualy once everything else is up, then starting
cups is causing immediately the same oops. cups is actually starting ok
but doing so apparently it looks for serial ports, which happen do not exist
on the said board and are turned off in BIOS, and this is causing the problem.
Switching on serial ports in BIOS does not make any difference.
All of that would be less of a bother if not that detail that a kernel used
by anaconda is oopsing too, apparently when anaconda checks for an existing
hardware, and anaconda bails out refusing to continue with an installation
unless 'acpi=off' boot option is added. This also appears to cause troubles
to the firstboot, even if acpi=off is in use, which does not even really
starts although later 'system-config-display' works ok.
As the further data point - installation with a boot media from FC3 does not
present any troubles on that hardware and does not require extra options.
At the bottom of the attached dmesg output there are "mtrr: type mismatch ..."
complaints. I am not sure what this is about. In further boots with
and without 'acpi=off' these seemed to vanish and what is in /proc/mtrr always
appears to be that:
reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg01: base=0x100000000 (4096MB), size= 64MB: write-back, count=1
reg02: base=0xfc000000 (4032MB), size= 64MB: uncachable, count=1
Attached is also an output from 'dmidecode' and 'lspci -tv' for the board
Version-Release number of selected component (if applicable):
kernel-2.6.12-1.1390_FC4smp but really all kernels used in FC4
always if 'acpi=off' is not given
Created attachment 116779 [details]
dmesg output from a boot sequence
Created attachment 116781 [details]
Created attachment 116782 [details]
'lspci -tv' bus picture
[This comment has been added as a mass update for all FC4 kernel bugs.
If you have migrated this bug from an FC3 bug today, ignore this comment.]
Please retest your problem with todays 2.6.12-1.1398_FC4 update.
If your problem involved being unable to boot, or some hardware not being
detected correctly, please make sure your /etc/modprobe.conf is correct *BEFORE*
installing any kernel updates.
If in doubt, you can recreate this file using..
mv /etc/sysconfig/hwconf /etc/sysconfig/hwconf.bak
mv /etc/modprobe.conf /etc/modprobe.conf.bak
Please try the latest kernel in updates-testing, as that has an acpi update
which may help.
This board boots now with current kernels and without any extra parameters; but
it also got in the meantime a BIOS update and it is hard to tell if this was
the main contributing factor, or new kernels, or both.