From: James Bottomley <jejb@steeleye.com>
To: bugme-daemon@bugzilla.kernel.org
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [Bug 5847] aic7xxx detection fails on x86_64/SMP (IRQ/ACPI problem?)
Date: Sun, 08 Jan 2006 10:08:15 -0600 [thread overview]
Message-ID: <1136736495.3377.13.camel@mulgrave> (raw)
In-Reply-To: <200601072139.k07Ld5Sj031690@fire-2.osdl.org>
> Machine was problem free using 2.6.11 (FC3, both i386 and 64bit kernels), 2.6.12
> and 2.6.14 kernels.
> Fails to boot with 2.6.14 and 2.6.15 kernels. Both vanilla and FC4 builds.
> When the machine tries to boot using a 14/15 kernel, the aic7xxx module is
> loaded, but does not detect any device. (No output is printed after the initial
> module load. See attached logs)
> I tried building a 2.6.15 vanilla kernel with all aic7xxxx debug options turned
> on, but saw nothing.
> I tried using both normal and PCI=routeirq both both failed.
> [root@gilboa-home-dev ~]# lspci -vvxx -s 0a:09.0
> 0a:09.0 SCSI storage controller: Adaptec AIC-7892A U160/m (rev 02)
> Subsystem: Adaptec 29160 Ultra160 SCSI Controller
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
> Stepping- SERR+ FastB2B-
> Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 72 (10000ns min, 6250ns max), Cache Line Size 10
> Interrupt: pin A routed to IRQ 177
> BIST result: 00
> Region 0: I/O ports at 3000 [disabled] [size=256]
> Region 1: Memory at c0500000 (64-bit, non-prefetchable) [size=4K]
> [virtual] Expansion ROM at 80000000 [disabled] [size=128K]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 00: 05 90 80 00 16 01 b0 02 02 00 00 01 10 48 00 80
> 10: 01 30 00 00 04 00 50 c0 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 05 90 a0 e2
> 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0b 01 28 19
It could be that the driver is being overly fussy and that there's a
mismatch in the PCI ID table. Someone with better PCI knowledge might
like to comment, but I think that's
vendor 0x9005 (VENDOR_ID_ADAPTEC2)
Device 0x0080 (DEVICE_ID_ADAPTEC2_7892A)
Subvendor 0x0116
Subdevice 0x02b0
The subvendor and subdevice are ones that don't exist in the adaptec PCI
tables; we have four possible 0080 devices, all with either aic or cpq
subvendors, so it's not matching in the subdevice/subvendor. The
curiosity is that I don't think this code has changed for ages, so I
don't see why it would previously have matched.
James
parent reply other threads:[~2006-01-08 16:11 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <200601072139.k07Ld5Sj031690@fire-2.osdl.org>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1136736495.3377.13.camel@mulgrave \
--to=jejb@steeleye.com \
--cc=James.Bottomley@steeleye.com \
--cc=bugme-daemon@bugzilla.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox