It looks like ac6 (which I believe includes the patch you posted) is
still a no-go with 7892. The boot halts and it just prints this once a
second:
(SCSI0:0:3:1) Synchronous at 160 Mbyte/sec offset 31
(SCSI0:0:3:1) CRC error during data in phase
(SCSI0:0:3:1) CRC error in intermediate CRC packet
This happens also with ac5+the small patch you posted earlier. ac2 works
fine (although something did corrupt my MBR while using it. It is still
a complete mystery to me what could have done it. Now I'm unable to
boot NT; linux of course works with the boot floppy.)
ac2 dmesg's:
SCSI subsystem driver Revision: 1.00
(scsi0) <Adaptec AIC-7892 Ultra 160/m SCSI host adapter> found at PCI
3/9/0
(scsi0) Wide Channel, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 392 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
<Adaptec AIC-7892 Ultra 160/m SCSI host adapter>
(scsi0:0:3:0) Synchronous at 80.0 Mbyte/sec, offset 31.
Vendor: QUANTUM Model: ATLAS 10K 18WLS Rev: UCHK
Type: Direct-Access ANSI SCSI revision: 03
Attached scsi disk sda at scsi0, channel 0, id 3, lun 0
SCSI device sda: 35566480 512-byte hdwr sectors (18210 MB)
Partition check:
/dev/scsi/host0/bus0/target3/lun0: p1 p2 p3
cat /proc/scsi/aic7xxx/0
Adaptec AIC7xxx driver version: 5.2.1/5.2.0
Compile Options:
TCQ Enabled By Default : Enabled
AIC7XXX_PROC_STATS : Enabled
Adapter Configuration:
SCSI Adapter: Adaptec AIC-7892 Ultra 160/m SCSI host adapter
Ultra-160/m LVD/SE Wide Controller at PCI 3/9/0
PCI MMAPed I/O Base: 0xfc8ff000
Adapter SEEPROM Config: SEEPROM found and used.
Adaptec SCSI BIOS: Enabled
IRQ: 10
SCBs: Active 0, Max Active 8,
Allocated 31, HW 32, Page 255
Interrupts: 42493
BIOS Control Word: 0x58a4
Adapter Control Word: 0x1c5e
Extended Translation: Enabled
Disconnect Enable Flags: 0xffff
Ultra Enable Flags: 0x0000
Tag Queue Enable Flags: 0x0008
Ordered Queue Tag Flags: 0x0008
Default Tag Queue Depth: 8
Tagged Queue By Device array for aic7xxx host instance 0:
{0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0}
Actual queue depth per device for aic7xxx host instance 0:
{1,1,1,8,1,1,1,1,1,1,1,1,1,1,1,1}
Statistics:
(scsi0:0:3:0)
Device using Wide/Sync transfers at 80.0 MByte/sec, offset 31
Transinfo settings: current(10/31/1/0), goal(10/127/1/0),
user(9/127/1/2)
Total transfers 42420 (34614 reads and 7806 writes)
< 2K 2K+ 4K+ 8K+ 16K+ 32K+ 64K+ 128K+
Reads: 39 0 25175 3674 4257 946 433 90
Writes: 0 0 3558 1864 502 480 455 947
cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 03 Lun: 00
Vendor: QUANTUM Model: ATLAS 10K 18WLS Rev: UCHK
Type: Direct-Access ANSI SCSI revision: 03
--
Ville Herva [email protected] +358-50-5164500
Viasys Oy Hannuntie 6 FIN-02360 Espoo +358-9-2313-2160
PGP key available: http://www.iki.fi/v/pgp.html fax +358-9-2313-2250
Ville Herva wrote:
>
> It looks like ac6 (which I believe includes the patch you posted) is
> still a no-go with 7892. The boot halts and it just prints this once a
> second:
>
> (SCSI0:0:3:1) Synchronous at 160 Mbyte/sec offset 31
> (SCSI0:0:3:1) CRC error during data in phase
> (SCSI0:0:3:1) CRC error in intermediate CRC packet
Check your cables, especially the connector on the card and the drive. Look
for any possible bent pins. The message you are seeing is *usually*, but not
always, a legitimate data corruption issue. It doesn't show up under the
5.2.1 driver because it limits your Quantum drive to 80MByte/s and that
particular speed doesn't include CRC checking. On this driver you have to be
running at 160MByte/s before CRC checking is enabled.
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
On Thu, Feb 08, 2001 at 07:53:55AM -0500, you [Doug Ledford] claimed:
> Ville Herva wrote:
> >
> > It looks like ac6 (which I believe includes the patch you posted) is
> > still a no-go with 7892. The boot halts and it just prints this once a
> > second:
> >
> > (SCSI0:0:3:1) Synchronous at 160 Mbyte/sec offset 31
> > (SCSI0:0:3:1) CRC error during data in phase
> > (SCSI0:0:3:1) CRC error in intermediate CRC packet
>
> Check your cables, especially the connector on the card and the drive. Look
> for any possible bent pins. The message you are seeing is *usually*, but not
> always, a legitimate data corruption issue. It doesn't show up under the
> 5.2.1 driver because it limits your Quantum drive to 80MByte/s and that
> particular speed doesn't include CRC checking. On this driver you have to be
> running at 160MByte/s before CRC checking is enabled.
I checked the cables. I think HP didn't supply proper 160 MB/S capable
cables (aren't those the ones with wattlings?). When I forced the drive to
80MB/s from bios, not only did aic7xxx/ac6 work like charm, but the BIOS
also found the "missing" MBR. Stupid problem ;).
Thanks for your help!
--
Ville Herva [email protected] +358-50-5164500
Viasys Oy Hannuntie 6 FIN-02360 Espoo +358-9-2313-2160
PGP key available: http://www.iki.fi/v/pgp.html fax +358-9-2313-2250
On Thu, Feb 08, 2001 at 06:16:01PM +0200, you [Ville Herva] claimed:
> On Thu, Feb 08, 2001 at 07:53:55AM -0500, you [Doug Ledford] claimed:
> > Ville Herva wrote:
> > >
> > > It looks like ac6 (which I believe includes the patch you posted) is
> > > still a no-go with 7892. The boot halts and it just prints this once a
> > > second:
> > >
> > > (SCSI0:0:3:1) Synchronous at 160 Mbyte/sec offset 31
> > > (SCSI0:0:3:1) CRC error during data in phase
> > > (SCSI0:0:3:1) CRC error in intermediate CRC packet
> >
> > Check your cables, especially the connector on the card and the drive. Look
> > for any possible bent pins. The message you are seeing is *usually*, but not
> > always, a legitimate data corruption issue. It doesn't show up under the
> > 5.2.1 driver because it limits your Quantum drive to 80MByte/s and that
> > particular speed doesn't include CRC checking. On this driver you have to be
> > running at 160MByte/s before CRC checking is enabled.
>
> I checked the cables. I think HP didn't supply proper 160 MB/S capable
> cables (aren't those the ones with wattlings?). When I forced the drive to
> 80MB/s from bios, not only did aic7xxx/ac6 work like charm, but the BIOS
> also found the "missing" MBR. Stupid problem ;).
Umm, I think I said that too early. I begun to have problem even during
boot; the scsi bios did recognize the drive, but the bios didn't find the
boot record. This was completely cured by forcing the drive to 80MB/s mode.
So I think the cable wasn't Ultra160 capable.
However, the 2.4.1ac6, 2.4.1ac2 and 2.19pre6 aic7xxx.c still had trouble
with the drive. I went back to 80MB/s, 40MB/s and even 20MB/s, but that
still didn't help. 2.4.1* reported time out while waiting for a command and
would go into an endless loop resetting the bus. 2.2.19pre6 said there was
an error during the data in phase, but after some coughing it booted up and
seemed to work quite alright.
NT4 booted up without and visible problems.
The HP service guy changed the motherboard (integrated scsi) the cable (to
another (80MB/s one), and the drive logics, but that didn't help.
The problems first started after the motherboard was first changed (due to
separate problem.) The new one had newer bios and scsi bios.
Anyhow, I just compiled 2.4.1ac13 with Justin Gibbs's aic7xxx, and it does
not suffer of any problem at 80MB/s.
-- v --
[email protected]
Ville Herva wrote:
>
> On Thu, Feb 08, 2001 at 06:16:01PM +0200, you [Ville Herva] claimed:
> > On Thu, Feb 08, 2001 at 07:53:55AM -0500, you [Doug Ledford] claimed:
> > > Ville Herva wrote:
> > > >
> > > > It looks like ac6 (which I believe includes the patch you posted) is
> > > > still a no-go with 7892. The boot halts and it just prints this once a
> > > > second:
> > > >
> > > > (SCSI0:0:3:1) Synchronous at 160 Mbyte/sec offset 31
> > > > (SCSI0:0:3:1) CRC error during data in phase
> > > > (SCSI0:0:3:1) CRC error in intermediate CRC packet
> > >
> > > Check your cables, especially the connector on the card and the drive. Look
> > > for any possible bent pins. The message you are seeing is *usually*, but not
> > > always, a legitimate data corruption issue. It doesn't show up under the
> > > 5.2.1 driver because it limits your Quantum drive to 80MByte/s and that
> > > particular speed doesn't include CRC checking. On this driver you have to be
> > > running at 160MByte/s before CRC checking is enabled.
> >
> > I checked the cables. I think HP didn't supply proper 160 MB/S capable
> > cables (aren't those the ones with wattlings?). When I forced the drive to
> > 80MB/s from bios, not only did aic7xxx/ac6 work like charm, but the BIOS
> > also found the "missing" MBR. Stupid problem ;).
>
> Umm, I think I said that too early. I begun to have problem even during
> boot; the scsi bios did recognize the drive, but the bios didn't find the
> boot record. This was completely cured by forcing the drive to 80MB/s mode.
> So I think the cable wasn't Ultra160 capable.
>
> However, the 2.4.1ac6, 2.4.1ac2 and 2.19pre6 aic7xxx.c still had trouble
> with the drive. I went back to 80MB/s, 40MB/s and even 20MB/s, but that
> still didn't help. 2.4.1* reported time out while waiting for a command and
> would go into an endless loop resetting the bus. 2.2.19pre6 said there was
> an error during the data in phase, but after some coughing it booted up and
> seemed to work quite alright.
>
> NT4 booted up without and visible problems.
>
> The HP service guy changed the motherboard (integrated scsi) the cable (to
> another (80MB/s one), and the drive logics, but that didn't help.
>
> The problems first started after the motherboard was first changed (due to
> separate problem.) The new one had newer bios and scsi bios.
>
> Anyhow, I just compiled 2.4.1ac13 with Justin Gibbs's aic7xxx, and it does
> not suffer of any problem at 80MB/s.
There was a new aic7xxx driver (version 5.2.3) that went into the 2.4.1ac
kernel series around 2.4.1-ac7. I would be curious to know if it worked on
your machine properly.
--
Doug Ledford <[email protected]> http://people.redhat.com/dledford
Please check my web site for aic7xxx updates/answers before
e-mailing me about problems
On Thu, Feb 15, 2001 at 06:08:12AM -0500, you [Doug Ledford] claimed:
>
> There was a new aic7xxx driver (version 5.2.3) that went into the 2.4.1ac
> kernel series around 2.4.1-ac7. I would be curious to know if it worked on
> your machine properly.
Ok. Will try.
Are there any changes that could affect?
-- v --
[email protected]
On Thu, Feb 15, 2001 at 01:22:31PM +0200, you [Ville Herva] claimed:
> On Thu, Feb 15, 2001 at 06:08:12AM -0500, you [Doug Ledford] claimed:
> >
> > There was a new aic7xxx driver (version 5.2.3) that went into the 2.4.1ac
> > kernel series around 2.4.1-ac7. I would be curious to know if it worked on
> > your machine properly.
>
> Ok. Will try.
Tried 2.4.1ac13 vanilla. Still a no-go:
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is neing reset for host 0 channel 0
(scsi0:0:0:0) Synchronous at 40.0MBytes/s offset 31
SCSI host 0 abort (pid 0) timed out - trying harder
SCSI bus is being reset for host 0 channel 0
(scsi0:0:0:0) Synchronous at 40.0MBytes/s offset 31
scsi: aborting command due to timeout pid 0 scsi 0 channel 0 id 0 lun 0
Read (10) 00 00 00 00 00 00 00 02 00
SCSI SIGI 0x14 SEDADDR 0x77 SSTAT 0x0 SSTAT 0x2 SG_CACHEPTR 0x6 SSTAT2 0xC0 ST 0x0F0
(copied by hand, so please excuse the typos.)
Although 2.4.1ac13+Gibbs's aic7xxx seems to work perfectly, I still
wouldn't count out the possibility a hardware fault of some kind, since the
box already begun failing to find the boot record at 80MB/sec as well.
-- v --
[email protected]
On Thu, Feb 15, 2001 at 02:11:55PM +0200, you [Ville Herva] claimed:
> On Thu, Feb 15, 2001 at 01:22:31PM +0200, you [Ville Herva] claimed:
> > On Thu, Feb 15, 2001 at 06:08:12AM -0500, you [Doug Ledford] claimed:
> > >
> > > There was a new aic7xxx driver (version 5.2.3) that went into the 2.4.1ac
> > > kernel series around 2.4.1-ac7. I would be curious to know if it worked on
> > > your machine properly.
> >
> > Ok. Will try.
>
> Tried 2.4.1ac13 vanilla. Still a no-go:
Hmm. I think we finally found a fully functional cable.
2.4.1.ac13 vanilla now seems to work flawlessly, even at 160MB/s. Pretty
weird, though, that 2.4.1ac13+Gibbs's aic7xxx worked even with the previous
cable.
-- v --
[email protected]