Bug 83968 - blk: queue error loading aic7xxx driver
blk: queue error loading aic7xxx driver
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-10 10:56 EST by Mark Levitt
Modified: 2007-04-18 12:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-06-05 11:00:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of lspci -vv (7.52 KB, text/plain)
2003-02-10 10:58 EST, Mark Levitt
no flags Details

  None (edit)
Description Mark Levitt 2003-02-10 10:56:58 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
I ugraded to Redhat errate kernel 2.4.18-24.8.0.

Booting with the new kernel, I get the following message when the aic7xxx driver
loads:
blk: queue c24ee414, I/O limit 4095Mb (mask 0xffffffff)

This is the full driver initialization message:
SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
PCI: Found IRQ 11 for device 02:04.0
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
        <Adaptec 2940 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

blk: queue c24ee414, I/O limit 4095Mb (mask 0xffffffff)
  Vendor: HP        Model: C1537A            Rev: L111
  Type:   Sequential-Access                  ANSI SCSI revision: 02
blk: queue c24eec14, I/O limit 4095Mb (mask 0xffffffff)


I did not get this message with the previous kernel, 2.4.18-19.8.0.



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


How reproducible:
Always

Steps to Reproduce:
1. Boot with the new 2.4.18-24.8.0 kernel
2. scsi driver loads
3.
    

Actual Results:  blk: queue c24ee414, I/O limit 4095Mb (mask 0xffffffff)error
message

Expected Results:  No error message should be produced.

Additional info:
Comment 1 Mark Levitt 2003-02-10 10:58:11 EST
Created attachment 89972 [details]
Output of lspci -vv
Comment 2 acount closed by user 2003-03-01 00:10:59 EST
bug duplicate of #67201:
------- Additional Comment #3 From Arjan van de Ven on 2002-07-10 08:16 -------

This is a harmless printk; the kernel tries to autoload something that doesn't
work; that's ok because the initrd is about to load that anyway
Comment 3 Mark Levitt 2003-03-02 05:49:31 EST
No this is *not* a duplicate of #67201

#67201 seems to be refering to the message:
"kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2"

That's not the issue with this bug. 
The issue with this bug is the message:
"blk: queue c24eec14, I/O limit 4095Mb (mask 0xffffffff)"




Comment 4 Arjan van de Ven 2003-03-02 06:13:33 EST
"blk: queue c24eec14, I/O limit 4095Mb (mask 0xffffffff)"

means "this driver has advertised a PCI capability of 32 bits (0xffffffff)" and
is no error
Comment 5 omali 2003-03-07 05:22:17 EST
Motherboard is intel L440GX+
Hot swap Controller is Adaptec AIC-7896N
This is an intel U2 Rack mount server Model ISP 2150 hotswap hard drives.
I can get 8.0 to install on Hard but
when it tries to boot up. I get hard drive errors.
/sbin/modprobe -s -k SCSI_hostadapter err-number 2

Anyone have a clue on whats wrong?????
Please help!!!!!!!!!

Booting with the new kernel, I get the following message when the aic7xxx driver
loads:
blk: queue c24ee414, I/O limit 4095Mb (mask 0xffffffff)


This is the full driver initialization message:
SCSI subsystem driver Revision: 1.00
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
PCI: Found IRQ 11 for device 02:04.0
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8

<4>scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 1, lun 
0 0x12 00 00 00 ff 00
<4>scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 1, lun 
0 0x12 00 00 00 ff 00
<4>scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 2, lun 
0 0x12 00 00 00 ff 00
<4>scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 2, lun 
0 0x12 00 00 00 ff 00
<4>scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 3, lun 
0 0x12 00 00 00 ff 00

so on.. until id 15 then switches to the second scsi chaing scsi1 id0 and so on 
until id15
then 
<4>attached scsi disk sda at scsi0, channel 0, id 0, lun 0
<4>scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun0 
0x00 00 00 00 00 00
<6>(scsi0:0:0:0) SCSISIGI 0xa4, SEQADDR 0x162, SSTAT0 0x0, SSTAT1 0x2
<6>(scsi0:0:0:0) SG_CACHEPTR 0x2, SSTAT2 0x0, STCNT 0x0
<4>SCSI host 0 abort (pid 0) timed out - resetting
<4>SCSI bus is being reset for host 0 channel 0.
<4>SCSI host 0 abort (pid 0) timed out - resetting
<4>SCSI bus is being reset for host 0 channel 0.
<4>(scsi0:0:0:0) Device reset, Message buffer in use
<4>SCSI host 0 channel 0 reset (pid 0) timed out - trying harder...

and so on.. keeps looping.

        <Adaptec 2940 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

blk: queue c24ee414, I/O limit 4095Mb (mask 0xffffffff)
  Vendor: HP        Model: C1537A            Rev: L111
  Type:   Sequential-Access                  ANSI SCSI revision: 02
blk: queue c24eec14, I/O limit 4095Mb (mask 0xffffffff)
Comment 6 Arjan van de Ven 2003-03-07 06:05:27 EST
 omali : you have a totally different issue (440GX chipsets aren't supported in
8.0 and aren't working properly)
Comment 7 omali 2003-03-07 16:53:22 EST
sorry but i don't now how i can solve my problem
can you tell me how i can install redhat on my hardware
works another version of RedHat ?
Help me please 
Comment 8 Arjan van de Ven 2003-03-07 16:56:49 EST
omali: you can start by not using an unrelated bug number but open a new one....
Comment 9 Alan Cox 2003-06-05 11:00:46 EDT
The blk queue message is not a bug.

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