Bug 114423 - Problem with 3w-xxxx module during installation
Problem with 3w-xxxx module during installation
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Depends On:
  Show dependency treegraph
Reported: 2004-01-27 17:11 EST by Jorge
Modified: 2015-01-04 17:04 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-08 00:32:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jorge 2004-01-27 17:11:54 EST
Description of problem:

  The installation crashes when loading the 3w-xxxx module.

Version-Release number of selected component (if applicable):

  Fedora Core 1 for AMD64 test1

How reproducible:


Steps to Reproduce:
1. Try to install Fedora on a machine with a 3ware RAID card.
2. Machine starts booting, then says "loading 3w-xxxx"
3. Error occurs. Installation aborted.
Actual results:

  Installation fails. Can't get Fedora installed on this machine.

Expected results:

  I expected installation to succeed...

Additional info:

  The old "taroon" installation works fine. This seems limited to the
x86_64 version of Fedora Test1.
Comment 1 Jorge 2004-01-27 18:10:01 EST
Some more details:
The installation is done over PXE. The ISOs have been copied to a
directory called /x86_64-test1/disc. The vmlinuz and initrd.img from
images/pxeboot have been compied to the right place and renamed. The
pxeboot file has:
  default vmlinuz.x86_64-test1
  append load_ramdisk=1 prompt_ramdisk=0 ramdisk_size=8192 \
    initrd=initrd.img.x86_64-test1 root=/dev/ram rw \
    ks=nfs: ksdevice=eth0
(I added the "\" for readability)
A similar setup works fine with the "taroon" release, where the
pxeboot file has:
  default vmlinuz.taroon
  append load_ramdisk=1 prompt_ramdisk=0 initrd=initrd.img.taroon \
    root=/dev/ram rw \
    ks=nfs: ksdevice=eth0
Comment 2 Ken Snider 2004-02-02 19:29:17 EST
I had an annoying problem where this build would *not* use the ISO's
when I tried to use NFS.. it wanted a "Fedora" installation tree.

Is that maybe what you're seeing here?

(I too have a 3ware card, and was able to install fine once I moved to
an http-based install method.)
Comment 3 Jorge 2004-02-04 17:26:51 EST
Actually, I'm using a Fedora installation tree. I created the
installation tree from the ISO's. I'm sorry I wasn't clear about this
in my original post. 

Do you have your root directory going to the 3ware card? My
installation goes fine until it shows the message that it is loading
the 3w-xxxx driver, then it dumps a lot of error messages on the
screen. Oddly enough, it later puts up another boxed message about
"Requesting an IP address", but then more error messages get dumped on
the screen, and eventually it ends up looking like a "blue screen of
death". The final screen mentions something about "scsi" and "3w-xxxx"
which makes me suspect the 3Ware card. If it would be helpful, I can
try to transcribe the numbers and messages from the final screen, but
it will be a pain because I will have to type it all by hand (it is
mostly trace info and hex numbers)...
Comment 4 Ken Snider 2004-02-04 19:00:14 EST
I've used Red Hat 9, RHEL WS (x86) and Fedora Core test1 x86_64 on
this system.

In all cases, it had *no* problem detecting the 3ware card (7506-12).

The only problem, as listed above, was that the NFS install wanted a
"Fedora" directory tree, and would *not* accept the ISO's to install from.

3ware support has been rock-solid for me. *shrug*
Comment 5 Jorge 2004-02-04 20:46:49 EST
We have many 3ware cards on our systems, and they have all worked
wonderfully until now. In fact, I thought maybe the problem was
related to a bad card, but I have tried different systems (we have 8
of these AMD based systems [Dual AMD opterons with 8 Gb of RAM on a
HDAMA board] with  with 8 different 7506-4LP 3ware cards). They all
fail the same way during install of fedora core test1 for AMD. I have
now also tried Fedora Core 1 (i386), Redhat 9 (i386) and taroon
(x86_64). These all install and work fine. I even tried installing the
taroon distribution and then upgrading all the RPMs using the fedora
distribution. That didn't work.  

Can you tell me the boot options you use when you install? I'm not
sure what else to try...
Comment 6 Ken Snider 2004-02-05 10:55:17 EST
Sure. Specifically for fc1-amd64, we used:

default linux
  kernel vmlinuz-fc1-amd64
  append text expert initrd=initrd-fc1-amd64.img devfs=nomount \

This doesn't use a kickstart (because it's a one-off), and we manually
specifiy the media options for this one box because, for whatever
reason, if I try an NFS install, it wants a directory tree, NOT the isos.

Comment 7 Jorge 2004-02-05 13:58:12 EST
Thanks. I have changed my options to:

  default vmlinuz.x86_64-test1
  append text expert initrd=initrd.img.x86_64-test1 devfs=nomount \ 

The system starts booting, then it stops and asks me if I have a
driver disk. Do you use a different driver disk for the 3ware card
than what comes with Fedora? At this point, I say "no", and then the
system starts loading the 3w-xxxx driver that comes with Fedora, and
the same dump screen message happens. 

Thanks for all your help, but the problem is still happening. Just to
make sure I'm doing exactly the same as you are (as far as I can
tell), could you answer these questions:

1. Where do you get the boot kernel you use (vmlinuz-fc1-amd64)? I get
the kernel from the first CD, under images/pxeboot/vmlinuz
2. Where do you get the initrd file you use (initrd-fc1-amd64.img)? I
get the image file from the first CD, under images/pxeboot/initrd.img
3. Do you use a different driver disk? If so, where did you get the
driver? I use the 3w-xxxx driver that comes with the distribution.

Once again, thanks for your help!
Comment 8 Ken Snider 2004-02-05 14:09:38 EST
Yep I get both from the same place, from the fc1-test1 isos.

Have you tried the obvious things (Motherboard/3ware card firmware)
etc.? I'm using a Tyan s2880 as the motherboard, I'm wondering if
perhaps there's an incompatibility somewhere.

3ware recently released both a new firmware rev and motherboard
compatibility list, as well.
Comment 9 Jorge 2004-02-05 19:09:15 EST
I would think that, since I have no problems with RH Taroon or other
distros, the issue is not Mobo/firmware related... I guess I will just
run the Taroon distro until Fedora gets fixed. Thanks for your help...
Comment 10 Justin M. Forbes 2004-02-24 14:55:19 EST
I believe this is a trigger of the IOMMU flush bug for 3Ware.  Does
this problem exist with the 2174 kernel as well?
Comment 11 Judd Taylor 2004-03-03 17:04:24 EST
I'm having the same problem installing from the CD's on a Tyan S2882  system with 2x 8506-12 cards. I've got bigger problems right now,  however (sii SATA driver doesn't work...). I will try an update of the firmware and see what happens... 
Comment 12 Ken Snider 2004-03-11 09:45:08 EST
Anyone try this with the FC1 Final for x86_64?
Comment 13 Jorge 2004-03-12 17:19:56 EST
Just tried FC1 x86_64 final. Problem is still there for me. Back to
Comment 14 Jorge 2004-03-24 13:08:47 EST
New information found. First, the problem is not with the 3w-xxxx
driver! At the suggestion of the 3ware people, I took the card out and
attached a drive directly to the onboard controller. Still couldn't
get it to work. But after long searches on the web, I think the
problem is specific to this motherboard (HDAMA), and maybe to my
configuration (8Gb RAM). 

Here's the way I finally got the installation to work:

1st problem - Machine crashes during installation.
Solution to 1st problem - add "mem=2048M" to boot line. For some
reason, this fixes the problem.
Thanks to Joshua Baker-LePain, who posted this solution in

2nd problem - Machine would then crash when booting.
Solution to 2nd problem - add "nomce" to grub.conf boot line. For some
reason, this fixes the problem.
Thanks to Jeff Thomas, who posted this solution in

Now the systems are happily running FC1, but this was a very obscure,
roundabout way of getting it to work...
Comment 15 Dave Jones 2004-12-08 00:32:10 EST
fc1 - eol

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