Bug 231699

Summary: Problem with Adaptec AHA-2940U2/U2W module
Product: [Fedora] Fedora Reporter: Wil Harris <mosinu>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7CC: chris.brown
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-09 00:11:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Wil Harris 2007-03-10 08:24:50 UTC
Description of problem:

With core 6 when I try to boot with any of the 2.6.19-1 kernel I get the
following scsi error and the system says it cannot find my disk. This works
perfectly with the 2.6.18 kernel. This is a Dell GX 270 with a Adaptec
AHA-2940U2/U2W scsi card. The drive information is
[root@Dragon log]# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 02 Lun: 00
  Vendor: IBM-ESXS Model: DTN073C3UCDY10FN Rev: S29C
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 04 Lun: 00
  Vendor: IBM-ESXS Model: DTN073C3UCDY10FN Rev: S29C
  Type:   Direct-Access                    ANSI SCSI revision: 03
[root@Dragon log]#


Mar 10 01:05:38 dragon kernel: SCSI subsystem initialized
Mar 10 01:05:38 dragon kernel: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5
Mar 10 01:05:38 dragon kernel: ACPI: PCI Interrupt 0000:01:09.0[A] -> Link
[LNKC] -> GSI 5 (level, low) -> IRQ 5
Mar 10 01:05:38 dragon kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA
DRIVER, Rev 7.0
Mar 10 01:05:38 dragon kernel:         <Adaptec 2940 Ultra2 SCSI adapter>
Mar 10 01:05:38 dragon kernel:         aic7890/91: Ultra2 Wide Channel A, SCSI
Id=7, 32/253 SCBs
Mar 10 01:05:38 dragon kernel:
Mar 10 01:05:38 dragon kernel:   Vendor: IBM-ESXS  Model: DTN073C3UCDY10FN  Rev:
S29C
Mar 10 01:05:38 dragon kernel:   Type:   Direct-Access                      ANSI
SCSI revision: 03
Mar 10 01:05:38 dragon kernel: scsi0:A:2:0: Tagged Queuing enabled.  Depth 4
Mar 10 01:05:38 dragon kernel:  target0:0:2: Beginning Domain Validation
Mar 10 01:05:38 dragon kernel:  target0:0:2: wide asynchronous
Mar 10 01:05:38 dragon kernel: (scsi0:A:2:0): parity error detected in Data-in
phase. SEQADDR(0x1a8) SCSIRATE(0x80)
Mar 10 01:05:38 dragon kernel: (scsi0:A:2:0): parity error detected in Data-in
phase. SEQADDR(0x1a8) SCSIRATE(0x80)
Mar 10 01:05:38 dragon kernel: (scsi0:A:2:0): parity error detected in Data-in
phase. SEQADDR(0x85) SCSIRATE(0x80)
Mar 10 01:05:38 dragon kernel:  target0:0:2: Wide Transfers Fail
Mar 10 01:05:38 dragon kernel:  target0:0:2: FAST-20 SCSI 20.0 MB/s ST (50 ns,
offset 127)
Mar 10 01:05:38 dragon kernel:  target0:0:2: Domain Validation skipping write tests
Mar 10 01:05:38 dragon kernel:  target0:0:2: Ending Domain Validation
Mar 10 01:05:38 dragon kernel: SCSI device sda: 143374000 512-byte hdwr sectors
(73407 MB)
Mar 10 01:05:38 dragon kernel: sda: Write Protect is off
Mar 10 01:05:38 dragon kernel: SCSI device sda: drive cache: write through
Mar 10 01:05:38 dragon kernel: SCSI device sda: 143374000 512-byte hdwr sectors
(73407 MB)
Mar 10 01:05:38 dragon kernel: sda: Write Protect is off
Mar 10 01:05:38 dragon kernel: SCSI device sda: drive cache: write through
Mar 10 01:05:38 dragon kernel:  sda: sda1
Mar 10 01:05:38 dragon kernel: sd 0:0:2:0: Attached scsi disk sda
Mar 10 01:05:38 dragon kernel:   Vendor: IBM-ESXS  Model: DTN073C3UCDY10FN  Rev:
S29C
Mar 10 01:05:38 dragon kernel:   Type:   Direct-Access                      ANSI
SCSI revision: 03
Mar 10 01:05:38 dragon kernel: scsi0:A:4:0: Tagged Queuing enabled.  Depth 4
Mar 10 01:05:38 dragon kernel:  target0:0:4: Beginning Domain Validation
Mar 10 01:05:38 dragon kernel:  target0:0:4: wide asynchronous
Mar 10 01:05:38 dragon kernel: (scsi0:A:4:0): parity error detected in Data-in
phase. SEQADDR(0x1a8) SCSIRATE(0x80)
Mar 10 01:05:38 dragon kernel: (scsi0:A:4:0): parity error detected in Data-in
phase. SEQADDR(0x1a8) SCSIRATE(0x80)
Mar 10 01:05:38 dragon kernel: (scsi0:A:4:0): parity error detected in Data-in
phase. SEQADDR(0x85) SCSIRATE(0x80)
Mar 10 01:05:38 dragon kernel:  target0:0:4: Wide Transfers Fail
Mar 10 01:05:38 dragon kernel:  target0:0:4: FAST-20 SCSI 20.0 MB/s ST (50 ns,
offset 127)
Mar 10 01:05:38 dragon kernel:  target0:0:4: Domain Validation skipping write tests
Mar 10 01:05:38 dragon kernel:  target0:0:4: Ending Domain Validation
Mar 10 01:05:38 dragon kernel: SCSI device sdb: 143374000 512-byte hdwr sectors
(73407 MB)
Mar 10 01:05:38 dragon kernel: sdb: Write Protect is off
Mar 10 01:05:38 dragon kernel: SCSI device sdb: drive cache: write through
Mar 10 01:05:38 dragon kernel: SCSI device sdb: 143374000 512-byte hdwr sectors
(73407 MB)
Mar 10 01:05:38 dragon kernel: sdb: Write Protect is off
Mar 10 01:05:38 dragon kernel: SCSI device sdb: drive cache: write through
Mar 10 01:05:38 dragon kernel:  sdb: sdb1
Mar 10 01:05:38 dragon kernel: sd 0:0:4:0: Attached scsi disk sdb


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Wil Harris 2007-04-06 01:59:06 UTC
Problem still exists with 2.6.20(2933). Appears like aic7xxx driver isn't
creating my scsi devices on boot. Trying to mount the drives or fsck them after
the system is up and running results in an error that /dev/sda1 doesn't exist.
Still works with 2.6.18(2869).

Comment 2 Wil Harris 2007-07-30 21:45:16 UTC
Problem persists into Fedora 7. Turning off parity checks in the adapter results
in the drives showing up, but with no partition tables and not able to hold any
partition information (eg fdisk the drive, partition it, exit, fdisk -l...no
partition). Install any of the 2.6.18 kernels and reenable parity checking and
problem goes away.

Comment 3 Christopher Brown 2007-09-13 14:39:35 UTC
Hello Will,

I'm reviewing this bug as part of the kernel bug triage project.

http://fedoraproject.org/wiki/KernelBugTriage

You might want to try some of the following:

# For boot related issues we need as much info as possible, so removing quiet
from the boot flags should be the first thing to ask for.
# Slowing down the speed of text output with boot_delay=1000 (the number may
need to be tweaked higher/lower to suit) may allow the user to take a digital
camera photo of the last thing on screen.
# Booting with vga=791 (or even just vga=1 if the video card won't support 791)
will put the framebuffer into high resolution mode to get more lines of text on
screen, allowing more context for bug analysis.
# initcall_debug will allow to see the last thing the kernel tried to initialise
before it hung.
# There are numerous switches that change which at times have proven to be
useful to diagnose failures by disabling various features.

* acpi=off is a big hammer, and if that works, narrowing down by trying
pci=noacpi instead may yield clues
* nolapic and noapic are sometimes useful
* Given it's new and still seeing quite a few changes, nohz=off may be worth
testing. (Though this is F7 and above only) 

# If you get no output at all from the kernel, sometimes booting with
earlyprintk=vga can sometimes yield something of interest.
# If the kernel locks up with a 'soft lockup' report, booting with nosoftlockup
will disable this check allowing booting to continue.

Comment 4 Christopher Brown 2008-01-09 00:11:47 UTC
As indicated previously there has been no update on the progress of this bug
therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue
still occurs for you and I will try to assist in its resolution. Thank you for
taking the time to report the initial bug.