--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: kernel-2.6.18-4-686: Adaptec 7xxx driver not respecting BIOS restrictions
- From: Hans-Joachim Zierke <Usenetspam010@Zierke.com>
- Date: Wed, 18 Apr 2007 02:47:58 +0200
- Message-id: <20070418004758.10479.28407.reportbug@odysseus.Zierke.com>
Package: kernel-2.6.18-4-686
Severity: normal
On 50 pin part of SCSI system, local system uses long cable, and is restricted
to 5 MB/s for reliability (does not matter for my slow bus users on 50 pin).
Adaptec Driver in Sarge respected Adaptec BIOS user settings and negotiated
5 MB/s with these devices. Never any problem.
Adaptec Driver in Etch ... see yourself:
===============================
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
<Adaptec aic7890/91 Ultra2 SCSI adapter>
aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs
Vendor: IBM Model: DDRS-34560D Rev: DC1B
Type: Direct-Access ANSI SCSI revision: 02
scsi0:A:0:0: Tagged Queuing enabled. Depth 32
target0:0:0: Beginning Domain Validation
target0:0:0: wide asynchronous
target0:0:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25 ns, offset 15)
target0:0:0: Domain Validation skipping write tests
target0:0:0: Ending Domain Validation
<...skip...>
Vendor: TEAC Model: CD-R58S Rev: 1.0P
Type: CD-ROM ANSI SCSI revision: 02
target0:0:2: Beginning Domain Validation
target0:0:2: FAST-10 SCSI 10.0 MB/s ST (100 ns, offset 15)
scsi 0:0:2:0: Attempting to queue an ABORT message
CDB: 0x12 0x0 0x0 0x0 0x24 0x0
scsi0: At time of recovery, card was not paused
>>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
scsi0: Dumping Card State in Data-in phase, at SEQADDR 0x55
Card was paused
ACCUM = 0x40, SINDEX = 0xa, DINDEX = 0xe4, ARG_2 = 0x0
HCNT = 0x24 SCBPTR = 0x0
SCSISIGI[0x44]:(BSYI|IOI) ERROR[0x0] SCSIBUSL[0x2d]
LASTPHASE[0x40]:(IOI) SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI)
SBLKCTL[0xa]:(SELWIDE|SELBUSB) SCSIRATE[0x18]:(SINGLE_EDGE)
SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0x20]:(DPHASE)
SSTAT0[0x0] SSTAT1[0x2]:(PHASECHG) SSTAT2[0x50]:(EXP_ACTIVE|SHVALID)
SSTAT3[0x0] SIMODE0[0x8]:(ENSWRAP) SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO)
SXFRCTL0[0x80]:(DFON) DFCNTRL[0x28]:(HDMAEN|SCSIEN)
DFSTATUS[0x80]:(PRELOAD_AVAIL)
STACK: 0x84 0x0 0x167 0x17d
SCB count = 4
Kernel NEXTQSCB = 2
Card NEXTQSCB = 2
QINFIFO entries:
Waiting Queue entries:
Disconnected Queue entries:
QOUTFIFO entries:
Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Sequencer SCB Info:
0 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x27] SCB_LUN[0x0]
SCB_TAG[0x3]
1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
<...skip...>
31 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
Pending list:
3 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0x27] SCB_LUN[0x0]
Kernel Free SCB list: 1 0
Untagged Q(2): 3
<<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>>
scsi 0:0:2:0: Device is active, asserting ATN
Recovery code sleeping
Timer Expired
Recovery code awake
aic7xxx_abort returns 0x2003
scsi 0:0:2:0: Attempting to queue a TARGET RESET message
CDB: 0x12 0x0 0x0 0x0 0x24 0x0
aic7xxx_dev_reset returns 0x2003
Recovery SCB completes
target0:0:2: Domain Validation detected failure, dropping back
===============================
At this point, the system locks up for Ctrl-Alt-Del with a chance of
4 out of 5. With a little luck, there is no lockup, but a successful
fallback
===============================
target0:0:2: FAST-10 SCSI 6.8 MB/s ST (148 ns, offset 15)
target0:0:2: Domain Validation skipping write tests
target0:0:2: Ending Domain Validation
Vendor: DK-TANDB Model: TDC 3800 Rev: =05:
Type: Sequential-Access ANSI SCSI revision: 02
target0:0:3: Beginning Domain Validation
target0:0:3: Ending Domain Validation
Vendor: UMAX Model: Astra 1200S Rev: V3.1
Type: Scanner ANSI SCSI revision: 02
<...skip...>
===============================
and after this, the system boots flawlessly.
Since a 1 out of 5 chance for a successful boot didn't please me, I have
compiled a new kernel with an old driver, which does not have this problem.
Ciao
Hans-Joachim
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
--- End Message ---
--- Begin Message ---
- To: 419805-done@bugs.debian.org
- Subject: Re: kernel-2.6.18-4-686: Adaptec 7xxx driver not respecting BIOS restrictions
- From: Moritz Muehlenhoff <jmm@inutil.org>
- Date: Sat, 18 Jul 2009 00:38:04 +0200
- Message-id: <20090717223804.GA31164@galadriel.inutil.org>
- In-reply-to: <20081110231049.GA6122@galadriel.inutil.org>
- References: <20070418004758.10479.28407.reportbug@odysseus.Zierke.com> <20081110231049.GA6122@galadriel.inutil.org>
On Tue, Nov 11, 2008 at 12:10:49AM +0100, Moritz Muehlenhoff wrote:
> On Wed, Apr 18, 2007 at 02:47:58AM +0200, Hans-Joachim Zierke wrote:
> > Package: kernel-2.6.18-4-686
> > Severity: normal
> >
> >
> > On 50 pin part of SCSI system, local system uses long cable, and is restricted
> > to 5 MB/s for reliability (does not matter for my slow bus users on 50 pin).
> >
> > Adaptec Driver in Sarge respected Adaptec BIOS user settings and negotiated
> > 5 MB/s with these devices. Never any problem.
> >
> > Adaptec Driver in Etch ... see yourself:
>
> Does this error still occur with more recent kernel versions?
>
> If you're running Etch, could you try to reproduce this bug
> with the 2.6.24 based kernel added in 4.0r4?
> http://packages.qa.debian.org/l/linux-2.6.24.html
No further feedback, closing the bug.
If anyone reencounters the problem, please reopen this bug.
Cheers,
Moritz
--- End Message ---