Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163317 - FC4 kernels oops apparently in a search for serial ports
Summary: FC4 kernels oops apparently in a search for serial ports
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-15 01:02 UTC by Michal Jaegermann
Modified: 2015-01-04 22:20 UTC (History)
2 users (show)

Fixed In Version: 2.6.12-1.1447_FC4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-08-29 18:35:01 UTC


Attachments (Terms of Use)
dmesg output from a boot sequence (deleted)
2005-07-15 01:02 UTC, Michal Jaegermann
no flags Details
dmidecode data (deleted)
2005-07-15 01:03 UTC, Michal Jaegermann
no flags Details
'lspci -tv' bus picture (deleted)
2005-07-15 01:04 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2005-07-15 01:02:35 UTC
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-15 01:02:36 UTC
Created attachment 116779 [details]
dmesg output from a boot sequence

Comment 2 Michal Jaegermann 2005-07-15 01:03:32 UTC
Created attachment 116781 [details]
dmidecode data

Comment 3 Michal Jaegermann 2005-07-15 01:04:31 UTC
Created attachment 116782 [details]
'lspci -tv' bus picture

Comment 4 Dave Jones 2005-07-15 21:38:06 UTC
[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 09:05:43 UTC
Please try the latest kernel in updates-testing, as that has an acpi update
which may help.


Comment 6 Michal Jaegermann 2005-08-29 18:32:55 UTC
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.