Bug 163317 - FC4 kernels oops apparently in a search for serial ports
FC4 kernels oops apparently in a search for serial ports
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
4
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-14 21:02 EDT by Michal Jaegermann
Modified: 2015-01-04 17:20 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.6.12-1.1447_FC4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-29 14:35:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg output from a boot sequence (18.55 KB, text/plain)
2005-07-14 21:02 EDT, Michal Jaegermann
no flags Details
dmidecode data (12.23 KB, text/plain)
2005-07-14 21:03 EDT, Michal Jaegermann
no flags Details
'lspci -tv' bus picture (1.57 KB, text/plain)
2005-07-14 21:04 EDT, Michal Jaegermann
no flags Details

  None (edit)
Description Michal Jaegermann 2005-07-14 21:02:35 EDT
Description of problem:

While booting a dual processor x86_64 board from RIOWORKS the following
shows up:

Unable to handle kernel paging request at 0000000f804f0c54 RIP: 
<ffffffff8035ba35>{_spin_lock_irq+5}

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
in question,

Version-Release number of selected component (if applicable):
kernel-2.6.12-1.1390_FC4smp but really all kernels used in FC4

How reproducible:
always if 'acpi=off' is not given
Comment 1 Michal Jaegermann 2005-07-14 21:02:36 EDT
Created attachment 116779 [details]
dmesg output from a boot sequence
Comment 2 Michal Jaegermann 2005-07-14 21:03:32 EDT
Created attachment 116781 [details]
dmidecode data
Comment 3 Michal Jaegermann 2005-07-14 21:04:31 EDT
Created attachment 116782 [details]
'lspci -tv' bus picture
Comment 4 Dave Jones 2005-07-15 17:38:06 EDT
[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
kudzu


Thank you.
Comment 5 Dave Jones 2005-08-26 05:05:43 EDT
Please try the latest kernel in updates-testing, as that has an acpi update
which may help.
Comment 6 Michal Jaegermann 2005-08-29 14:32:55 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.