Bug 178731 - Call Trace on Boot 3w-9xxx
Summary: Call Trace on Boot 3w-9xxx
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 4
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2006-01-23 20:29 UTC by Erik A. Espinoza
Modified: 2015-01-04 22:24 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-03 19:17:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Erik A. Espinoza 2006-01-23 20:29:45 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Description of problem:
I get a "Call Trace" on boot with 3w-9xxx module. This did not happen with kernel-smp-2.6.14-1.1653_FC4. I have not noticed any issues aside from the message on boot.

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

How reproducible:

Steps to Reproduce:
1. Install FC4
2. Boot
3. Call Trace

Actual Results:  I get the Call Trace provided below

Expected Results:  I should not get a call trace

Additional info:

3w-9xxx: scsi0: Found a 3ware 9000 Storage Controller at 0xfe9ffc00, IRQ: 169.
3w-9xxx: scsi0: Firmware FE9X, BIOS BE9X, Ports: 4.
  Vendor: AMCC      Model: 9500S-4LP  DISK   Rev: 2.06
  Type:   Direct-Access                      ANSI SCSI revision: 03
SCSI device sda: 1464778752 512-byte hdwr sectors (749967 MB)
SCSI device sda: drive cache: write back, no read (daft)
SCSI device sda: 1464778752 512-byte hdwr sectors (749967 MB)
SCSI device sda: drive cache: write back, no read (daft)
 sda: sda1 sda2 sda3 sda4 < sda5 >
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Debug: sleeping function called from invalid context at include/asm/semaphore.h:
in_atomic():1, irqs_disabled():0

Call Trace: <IRQ> <ffffffff8026dec6>{device_pm_remove+26} <ffffffff802698f4>{dev
       <ffffffff880094ba>{:scsi_mod:scsi_target_reap+142} <ffffffff8800c07f>{:sc
       <ffffffff801fc01d>{kobject_cleanup+83} <ffffffff801fc04f>{kobject_release
       <ffffffff801fc78e>{kref_put+106} <ffffffff8800863a>{:scsi_mod:scsi_end_re
       <ffffffff8800303a>{:scsi_mod:scsi_softirq+363} <ffffffff8013a48d>{__do_so
       <ffffffff8010eea7>{call_softirq+31} <ffffffff8011020c>{do_softirq+44}
       <ffffffff801104a6>{do_IRQ+52} <ffffffff8010df32>{ret_from_intr+0}
        <EOI> <ffffffff8023b5c3>{acpi_processor_idle+303} <ffffffff8010c4d5>{cpu

Comment 1 Dave Jones 2006-01-24 06:27:41 UTC
can you try the 2.6.15 kernel from updates-testing please ?

Comment 2 Erik A. Espinoza 2006-01-24 18:45:14 UTC
I will try and let you know.

Comment 3 Erik A. Espinoza 2006-01-25 20:32:28 UTC
Hello Dave,

I have not tried 2.6.15 beta as of yet. Last night I did an elevator change to
deadline, for higher performance with nfs.

The call trace received was from the following type of machine:
2x Dual Core AMD Opteron 275 2.2GHz
Supermicro H8DAR-T with IPMI (AOC-1UIPMI-B)
4GB PC3200 Reg ECC
4x250GB Seagate SATA (ST3250823AS
3Ware 9000 Series SATA Raid Controller
Raid 5 across all disks

As per my report of https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173535
I changed the elevator to deadline on our machines for better performance and
noticed that the Call Trace issue was gone. I guess this goes to support your
suspicion on 173535 that the 3ware driver does have an issue.

Regardless I will test a machine running the 2.6.15 sometime early next week to
report back.

Comment 4 Erik A. Espinoza 2006-01-25 22:05:57 UTC
Actually I was incorrect. The elevator setting made it less consistent. Out of
five reboots, only the first two did not show the call trace.

I have tried 2.6.15-1.1824_FC4smp, and this does not appear to show the call
trace on boot. However performance for nfs serving is still abysmal unless
'elevator=deadline' is set, as per my report on

Feel free to close this bug with 'errata'

Comment 5 Dave Jones 2006-01-26 03:27:13 UTC
I'm still really surprised at the performance issue, but we'll track that elsewhere.

the .15 update will move to updates-proper some time next week, after the
release of upstream.

Comment 6 Erik A. Espinoza 2006-01-26 03:49:39 UTC
We have a mix of Xeon's running FC4-i386 w/ the default elevator & some Opterons
running FC4-x86_64. The Xeon's just run on standard IDE, the Opterons run on
3ware raid.

The Xeons perform just fine with the default elevator. The Opterons require the
deadline, this leaves me to believe that it's either an arch bug or a 3ware raid
controller bug.

Anyways thanks for the response.

Comment 7 Dave Jones 2006-02-03 05:25:56 UTC
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.

Comment 8 Erik A. Espinoza 2006-02-03 19:14:11 UTC
Current kernel version, 2.6.15-1.1830_FC4, still requires elevator change to
deadline for decent nfs performance.

Comment 9 Erik A. Espinoza 2006-02-03 19:16:52 UTC
Confused the bugs, this one works just fine.

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