Red Hat Bugzilla – Bug 178870
aic79xx panics on boot with "Adaptec AIC-7902B U320"
Last modified: 2015-01-04 17:24:37 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.10) Gecko/20050909 Fedora/1.7.10-1.3.2
Description of problem:
The aic79xx driver in kernel-2.6.15-1.1871_FC5.x86_64 panics when booting with messages about "bad locking" or something like that. kernel-2.6.15-1.1826.2.10_FC5.x86_64 from FC5T2 has same problem. 2.6.9-22.0.1.ELsmp boots okey.
This problem puts me in a quandary (sp?): 2.6.9-22.0.1.ELsmp has working SCSI and 2.6.15-1.x has working SATA (sata_mv for Marvell MV88SX5081 8-port SATA), but neither kernel can access both disks and scsi tapes at the same time. Ouch!
Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175309 may be the same or related.
The lspci entries are:
02:03.0 SCSI storage controller: Adaptec AIC-7902B U320 (rev 10)
02:03.1 SCSI storage controller: Adaptec AIC-7902B U320 (rev 10)
The dmesg entries are (2.6.9-22.0.1.ELsmp):
SCSI subsystem initialized
scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.11
<Adaptec AIC7902 Ultra320 SCSI adapter>
aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 50-66Mhz, 512 SCBs
scsi1 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.11
<Adaptec AIC7902 Ultra320 SCSI adapter>
aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 50-66Mhz, 512 SCBs
More info available on request.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Somehow my U320 ones are working with kernel-2.6.15-1.1826.2.10_FC5.x86_64
(did not try the newer kernels). My dmesg lines are identical to yours. My
lspci lines are a bit different:
05:04.0 RAID bus controller: Adaptec ASC-39320(B) U320 w/HostRAID (rev 10)
05:04.1 RAID bus controller: Adaptec ASC-39320(B) U320 w/HostRAID (rev 10)
can you capture those bad locking messages ? even a digital camera photo would
be better than nothing. (Booting with vga=791 [or vga=1 if your monitor wont do
791] will also get more lines of text onscreen).
To answer your question (can you ...?) about capture of panic data, in the stone
age of Silicon Graphics IRIX machines circa 1992, there was a command to email
you (SGI support) the report from the last panic (after a panic(), all the RAM
contents was dumped to disk, then you gdb them like a normal core dump). Now, in
the modern day of digital cameras, I will type in the stack trace from the
little screen of my digital camera. Definitely better than pencil and paper.
on boot, messages about first scsi channel (no devices there)
then messages about the second scsi channel (SDLT tape robot, two scsi devices:
robot and tape drive)
(so far, same as the messages in my report above)
then, where the good kernel reports speed negotiations (after some haggling, the
tape drive eventually negotiates 40 Mbytes/sec (20 MHz, 16bit) and the robot
settles on 10 (or 20???) Mbytes/sec),
the bad one spews a bunch of scsi card state dump (too fast to capture)
then after a short delay there is a panic() with a stack trace like this:
panic ...: bad locking
... (I am tired of typing: boring kevent stuff follows)
I have the digital image trapped in the camera, will get it out at home and
attach to this bug report.
Is this still happening with the latest kernel ? (There's an even newer one
than the one in rawhide at http://people.redhat.com/davej/kernels/Fedora/devel/)
Thanks for the pointer. I will try kernel-2.6.15-1.2016_FC5.x86_64.rpm tomorrow.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
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 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.
In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed. See bug 207474 for further details.
If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.
If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.
This bug has been mass-closed along with all other bugs that
have been in NEEDINFO state for several months.
Due to the large volume of inactive bugs in bugzilla, this
is the only method we have of cleaning out stale bug reports
where the reporter has disappeared.
If you can reproduce this bug after installing all the
current updates, please reopen this bug.
If you are not the reporter, you can add a comment requesting
it be reopened, and someone will get to it asap.