HEADS UP: More CAM fixes.
Eugene Mitrofanov
eugene at imedia.ru
Tue Feb 17 22:21:39 PST 2009
Hi Scott
Unfortunately, it did not.
On Tuesday 17 February 2009, Scott Long wrote:
> Did the patch help?
>
> Scott
>
>
> Eugene Mitrofanov wrote:
> > 7.1-STABLE FreeBSD 7.1-STABLE #3: Tue Feb 17 14:58:42
> > asr0 at pci0:3:3:0: class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01
> > hdr=0x00
> > vendor = 'Adaptec (Formerly: Distributed Processing Technology
> > (DPT))'
> > device = 'Raptor SmartRAID Controller'
> > class = mass storage
> > subclass = RAID
> >
> > root:# camcontrol tags da0
> > (pass0:asr0:0:0:0): device openings: 1
> >
> > ---------
> >
> > 6.2-STABLE FreeBSD 6.2-STABLE #1: Mon Oct 15 16:53:04
> >
> > asr0 at pci3:3:0: class=0x010400 card=0xc0341044 chip=0xa5111044 rev=0x01
> > hdr=0x00
> > vendor = 'Adaptec (Formerly: Distributed Processing Technology
> > (DPT))'
> > device = 'Raptor SmartRAID Controller'
> > class = mass storage
> > subclass = RAID
> >
> > root:# camcontrol tags da0
> > (pass0:asr0:0:0:0): device openings: 255
> >
> >
> > On Monday 16 February 2009, Scott Long wrote:
> >> FWI. I need lots of testing on this. Only real SCSI controllers,
> >> please, not RAID controllers (except for MPT-SCSI with integrated
> >> mirroring). So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc,
> >> users, please try this and get back to me. The patch should apply
> >> to FreeBSD 7 as well. FreeBSD 6 is only affected by this problem
> >> when CAM_NEW_TRAN_CODE is enabled.
> >>
> >> Scott
> >>
> >>
> >> -------- Original Message --------
> >> Subject: svn commit: r188671 - head/sys/cam
> >> Date: Mon, 16 Feb 2009 14:57:15 +0000 (UTC)
> >> From: Scott Long <scottl at FreeBSD.org>
> >> To: src-committers at FreeBSD.org, svn-src-all at FreeBSD.org,
> >> svn-src-head at FreeBSD.org
> >>
> >> Author: scottl
> >> Date: Mon Feb 16 14:57:15 2009
> >> New Revision: 188671
> >> URL: http://svn.freebsd.org/changeset/base/188671
> >>
> >> Log:
> >> Fix parallel SCSI negotiation in the CAM_NEW_TRAN_CODE world order.
> >> Overzealous sanity checks were locking the sync_rate and offset
values
> > to
> >> zero, thanks to a twisty maze of recursive code.
> >>
> >> Modified:
> >> head/sys/cam/cam_xpt.c
> >>
> >> Modified: head/sys/cam/cam_xpt.c
> >>
> >
==============================================================================
> >> --- head/sys/cam/cam_xpt.c Mon Feb 16 14:38:52 2009 (r188670)
> >> +++ head/sys/cam/cam_xpt.c Mon Feb 16 14:57:15 2009 (r188671)
> >> @@ -6679,9 +6679,7 @@ xpt_set_transfer_settings(struct ccb_tra
> >> if (((device->flags & CAM_DEV_INQUIRY_DATA_VALID) != 0
> >> && (inq_data->flags & SID_Sync) == 0
> >> && cts->type == CTS_TYPE_CURRENT_SETTINGS)
> >> - || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)
> >> - || (spi->sync_offset == 0)
> >> - || (spi->sync_period == 0)) {
> >> + || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)) {
> >> /* Force async */
> >> spi->sync_period = 0;
> >> spi->sync_offset = 0;
> >> @@ -6729,7 +6727,8 @@ xpt_set_transfer_settings(struct ccb_tra
> >> if (spi->bus_width == 0)
> >> spi->ppr_options = 0;
> >>
> >> - if ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0) {
> >> + if ((spi->valid & CTS_SPI_VALID_DISC)
> >> + && ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0)) {
> >> /*
> >> * Can't tag queue without disconnection.
> >> */
> >> _______________________________________________
> >> freebsd-stable at freebsd.org mailing list
> >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> >> To unsubscribe, send any mail
to "freebsd-stable-unsubscribe at freebsd.org"
> >>
> >>
> >
> >
> >
>
>
--
EMIT-RIPN, EVM7-RIPE
More information about the freebsd-stable
mailing list