Bug 160652 - Kernel and installer halt with unknown symbol in ata_piix
Summary: Kernel and installer halt with unknown symbol in ata_piix
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-06-16 12:43 UTC by saul
Modified: 2015-01-04 22:20 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-07-07 23:14:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description saul 2005-06-16 12:43:17 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Description of problem:
Booting of kernel and installer both fail with unknown symbol
in kernel module ata_piix on a system using an Intel
SE7210TP1-E motherboard. This system is successfully
running FC3. 

Version-Release number of selected component (if applicable):
kernel 2.6.11-1.1369_FC4smp

How reproducible:
Always

Steps to Reproduce:
1. Boot Installer DVD - boot stops at initrd driver load
2. Download kernel onto FC3, boot into new kernel, the same result.
3.
  

Actual Results:  Boot stops. Unable to install FC4, or boot to its kernel.

Expected Results:  System should have booted.

Additional info:

Below is partial lspci -v from FC3, running kernel 2.6.11-1.27_FC3smp:

00:1f.1 IDE interface: Intel Corp. 6300ESB PATA Storage Controller (rev 02) (prog-if 8a [Master SecP PriP])
        Subsystem: Intel Corp.: Unknown device 342f
        Flags: bus master, medium devsel, latency 0, IRQ 169
        I/O ports at <unassigned>
        I/O ports at <unassigned>
        I/O ports at <unassigned>
        I/O ports at <unassigned>
        I/O ports at fc00 [size=16]
        Memory at 20000000 (32-bit, non-prefetchable) [size=1K]

00:1f.2 IDE interface: Intel Corp. 6300ESB SATA Storage Controller (rev 02) (prog-if 8f [Master SecP SecO PriP PriO])
        Subsystem: Intel Corp.: Unknown device 342f
        Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 169
        I/O ports at e400 [size=8]
        I/O ports at e000 [size=4]
        I/O ports at dc00 [size=8]
        I/O ports at d800 [size=4]
        I/O ports at d400 [size=16]

Comment 1 saul 2005-06-16 23:32:31 UTC
Based on messages from the linux kernel mailing
list, which I found archived here:

http://www.adras.com/Race-condition-in-module-load-causing-undefined-symbols.t6648-141.html

I surmised that I may be suffering from the same problem,
as the my processor is a hyper-threaded P4.

I installed the latest mkinitrd (mkinitrd-4.2.15-1)
package from FC4 (on top of FC4) and generated a 
new initrd from kernel 2.6.11-1.1369_FC4smp.

This configuration booted successfully.

I don't know what version the FC4 initrd image
was built with, but if it isn't 4.2.15-1, there
might be an issue there.



Comment 2 saul 2005-06-16 23:33:05 UTC
Based on messages from the linux kernel mailing
list, which I found archived here:

http://www.adras.com/Race-condition-in-module-load-causing-undefined-symbols.t6648-141.html

I surmised that I may be suffering from the same problem,
as the my processor is a hyper-threaded P4.

I installed the latest mkinitrd (mkinitrd-4.2.15-1)
package from FC4 (on top of FC4) and generated a 
new initrd from kernel 2.6.11-1.1369_FC4smp.

This configuration booted successfully.

I don't know what version the FC4 initrd image
was built with, but if it isn't 4.2.15-1, there
might be an issue there.

Comment 3 Dave Jones 2005-07-07 23:14:46 UTC
it's built with whatever version of mkinitrd is present on your system at the
time the kernel is installed.  You did the right thing by updating to the most
recent version.  I've bumped up the minimum requirement in the latest updates
that will be going out soon.


Comment 4 saul 2005-07-08 03:12:28 UTC
Thanks for the update and the feedback.

Note that my initial problem came from the distribution
DVD image, so that initrd was built with whatever initrd
is in the build system. Until that image is refreshed
with an initrd built with an appropriate mkinitrd,
the problem is still out there.

- Saul



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