RE: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Ada pter

RE: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Ada pter

[SUPPORT]

[-- Attachment #1: Type: text/plain, Size: 5347 bytes --]

Hi Guys,

I've been seeing problems with various tape drives and PPR. And a SCSI 3 SE
disk is interesting as well! SE and PPR don't get on too well;) The problems
we are seeing are generally indicated by a "phase change 6-7" error. And I
know there are others who have had problems from various messages on this
list

This wouldn't be too much of a problem but rather than then reverting to
using legacy sync and wide it just keeps trying PPR - for ever as far as I
can make out. And the drives struggle on using async;(

The following may help as a temporary fix for those who are desperate. We
are using this while we get on with higher priority items and we find time
to look at it more closely.

--- 2.6.9a/drivers/scsi/scsi_scan.c	2004-10-11 03:58:24.000000000 +0100
+++ 2.6.9b/drivers/scsi/scsi_scan.c	2004-11-04 12:20:09.000000000 +0000
@@ -578,7 +578,7 @@
 	sdev->lockable = sdev->removable;
 	sdev->soft_reset = (inq_result[7] & 1) && ((inq_result[3] & 7) ==
2);
 
-	if (sdev->scsi_level >= SCSI_3 || (sdev->inquiry_len > 56 &&
+	if (/*sdev->scsi_level >= SCSI_3 ||*/ (sdev->inquiry_len > 56 &&
 		inq_result[56] & 0x04))
 		sdev->ppr = 1;
 	if (inq_result[7] & 0x60)

Using this all the drives I've tried that normally use PPR still use PPR.
The drives that do not support PPR no longer cause problems - PPR is no
longer sent to these problem drives.

Matthew - I have attached some bits of SCSI analyser traces which I hope may
be useful. An IBM SCSI 3 SE disk and a couple of LTO tape drives - IBM and
HP. The HP causes severe problems as modprobe hangs without the fix. I have
also seen drives that do unexpected disconnects if they get sent PPR.

Sorry no logs from linux/sym53c8xx - I may be can find some if you want to
see whats happening there.

I have been toying with the idea of disabling PPR capability if PPR is
rejected - forcing sdev->ppr=0 in the driver when it determines PPR has been
rejected - but I'm not sure that's right. There are drives which reject
negotiation - legacy sync and wide at least - while they are initialising
but will then accept it later on.

Question - where does the full source for the sym53c8xx_2 driver live these
days now that Gerard no long maintains it?


Regards
Richard


Richard Waltham
Bridgeworks Ltd
135 Somerford Road,
Christchurch
Dorset, BH23 3PY
England.

Tel 0870 121 0708
Fax 0870 121 0709

Email: richardw@4bridgeworks.com



> -----Original Message-----
> From: Matthew Wilcox [mailto:matthew@wil.cx]
> Sent: 05 November 2004 13:44
> To: Thomas Babut
> Cc: linux-kernel@vger.kernel.org; Linux SCSI; matthew@wil.cx;
> groudier@free.fr
> Subject: Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI
> Adapter
> 
> 
> On Fri, Nov 05, 2004 at 01:52:32PM +0100, Thomas Babut wrote:
> > Here I am again with some news. :)
> 
> Um, again?  This is the first I've heard from you.  BTW, 
> Gerard seems to
> be unreachable, which is why I took over the driver.
> 
> > I tried last night Kernel 2.6.0 and 2.6.1 (both vanilla) 
> and the system 
> > bootet up with the controller! Then I tried this:
> > 
> > 1) unpack vanilla Kernel 2.6.9
> > 2) copy drivers/scsi/sym53c8xx_comm.h, 
> drivers/scsi/sym53c8xx_defs.h and 
> > the whole directory drivers/scsi/sym53c8xx_2/* from Kernel 
> 2.6.1 into 
> > the Kernel 2.6.9 source
> > 
> > It booted, too. But on all this three 2.6 Kernels the 
> SCSI-Harddisk has 
> > got very poor performance. With Kernel 2.4.26 and 2.4.27 it 
> makes almost 
> > 30 MB/s. With all three 2.6 Kernels it makes about 5 MB/s.
> 
> Sounds like your drive isn't negotiating the correct transfer rate.
> If it's able to do 30MB/s, I guess it should be negotiating at least
> wide, 20MHz -- 5MB/s sounds like asynchronous.
> 
> > (see 
> http://marc.theaimsgroup.com/?l=linux-kernel&m=109953598029428&w=2 
> > for detailed hardware specs and other informations)
> 
> Hrm.  Domain validation is failing.  I bet what's going on is that the
> controller is U160-capable, so we're sending a PPR message to 
> the drive
> which is going haywire.  I do hope we don't have to start blacklisting
> drives as being PPR-incapable.
> 
> Can you turn on negotiation debugging and send me the result?  If you
> have 2.1.18m, that's sym53c8xx.debug=0x200 ... earlier than that, it's
> sym53c8xx=debug:0x200
> 
> Now ... you say:
> 
> > sym0: SCSI BUS reset detected.
> > sym0: SCSI BUS has been reset.
> > sym0: SCSI BUS operation completed.
> > 
> > At this point only a hard-reset helps.
> 
> Do you mean the machine freezes at this point, or you can't 
> boot because
> this drive has your root partition on it and it can't be 
> found?  If the
> former, this is another bug that needs to be fixed.
> 
> -- 
> "Next the statesmen will invent cheap lies, putting the blame upon 
> the nation that is attacked, and every man will be glad of those
> conscience-soothing falsities, and will diligently study 
> them, and refuse
> to examine any refutations of them; and thus he will by and 
> by convince 
> himself that the war is just, and will thank God for the better sleep 
> he enjoys after this process of grotesque self-deception." -- 
> Mark Twain
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


[-- Attachment #2: HP_LTO.txt --]
[-- Type: text/plain, Size: 2055 bytes --]

Protocol Phase Analysis
   File name: LINUX6.DTT
Marker range: ANCHOR(70) to CURRENT(96)
Session name: None
Session desc: None
 Session ids: iids:7 tid(lun)[devtype]:3(0)[1]
Sess filters: None
Session date: 2-Nov-04  10:38:58 - 10:41:03
NNNNN = Phase Event Number (1st event is 0)
SSS.mmm_uuu_nnn = Difference Time (Secs.milli_micro_nano)
NNNNN SSS.mmm_uuu_nnn
   70           3_300  Arb
   71           2_192  Arbwin 7
   72           0_800 +Select 7,3
   73           0_716 +Sel/Resel End
   74           4_060 +MsgOut C0 Identify
   75      14_066_128  CMD - Inquiry     
                        12 00 00 00 32 00
   76          18_660  DataIn (N)
                    0h: 01 80 03 02 2D 00 01 30 ....-..0
                    8h: 48 50 20 20 20 20 20 20 HP      
                   10h: 55 6C 74 72 69 75 6D 20 Ultrium 
                   18h: 31 2D 53 43 53 49 20 20 1-SCSI  
                   20h: 45 31 32 44 00 00 00 00 E12D....
                   28h: 00 00 00 24 44 52 2D 31 ...$DR-1
                   30h: 30 00                   0.
                       (50 Bytes)
   77       1_240_728  DEnd  50 Bytes
   78           1_460  Status 00 Good
   79           2_936  MsgIn  00 Cmd Complete
   80          67_264 Bus Free
   81           3_404  Arb
   82           2_188  Arbwin 7
   83           0_800 +Select 7,3
   84           0_708 +Sel/Resel End
   85         442_892 +MsgOut C0 Identify
                              01 06 04
                        Parallel Protocol Pw:?,off:?,Width:?,
                        flags:?
   86  20.000_481_056 +MsgIn  07 Msg Reject
   87         201_336 Bus Reset
   88  10.003_609_516 Bus Free
   89           3_504  Arb
   90           2_188  Arbwin 7
   91           0_804 +Select 7,3
   92           0_720 +Sel/Resel End
   93         249_068 +MsgOut C0 Identify
                              01 06 04
                        Parallel Protocol Pw:?,off:?,Width:?,
                        flags:?
   94  15.001_441_328 +MsgIn  07 Msg Reject
   95         201_704 Bus Reset
   96           0_000 Bus Free

[-- Attachment #3: IBM_DSK.txt --]
[-- Type: text/plain, Size: 2026 bytes --]

Protocol Phase Analysis
   File name: LINUX8.DTT
Marker range: ANCHOR(89) to CURRENT(101)
Session name: None
Session desc: None
 Session ids: iids:7 tid(lun)[devtype]:2(0)[0]
Sess filters: None
Session date: 2-Nov-04  12:56:07 - 12:58:54
NNNNN = Phase Event Number (1st event is 0)
SSS.mmm_uuu_nnn = Difference Time (Secs.milli_micro_nano)
NNNNN SSS.mmm_uuu_nnn
   89           3_304  Arb
   90           2_204  Arbwin 7
   91           1_000 +Select 7,2
   92           1_608 +Sel/Resel End
   93         268_012 +MsgOut C0 Identify
                              01 06 04 0A 00 00 01 00
                        Parallel Protocol Pw:25ns,
                        off:0,Width:16 bits,
                        IU=0 DT=0 QAS=0
   94          43_052  MsgIn  07 Msg Reject
   95         287_268  CMD - Inquiry     
                        12 00 00 00 A4 00
   96       6_890_292  DataIn (N)
                    0h: 00 00 03 02 9F 00 01 3A .......:
                    8h: 49 42 4D 20 20 20 20 20 IBM     
                   10h: 44 4E 45 53 2D 33 30 39 DNES-309
                   18h: 31 37 30 57 20 20 20 20 170W    
                   20h: 53 41 33 30 41 4A 31 33 SA30AJ13
                   28h: 4B 31 31 36 00 00 00 00 K116....
                   30h: 00 00 00 00 00 00 00 00 ........
                   38h: 00 00 00 00 00 00 00 00 ........
                   40h: 00 00 00 00 00 00 00 00 ........
                   48h: 00 00 00 00 00 00 00 00 ........
                   50h: 00 00 00 00 00 00 00 00 ........
                   58h: 00 00 00 00 00 00 00 00 ........
                   60h: 28 43 29 20 43 6F 70 79 (C) Copy
                   68h: 72 69 67 68 74 20 49 42 right IB
                   70h: 4D 20 43 6F 72 70 2E 20 M Corp. 
                   78h: 31 39 39 38 2E 20 41 6C 1998. Al
                       (128 Bytes)
   97         101_564  DEnd  164 Bytes  0.024 MB/S
   98           2_156  Status 00 Good
   99           2_520  MsgIn  00 Cmd Complete
  100          76_796 Bus Free
  101           0_000  Arb

[-- Attachment #4: IBM_LTO.txt --]
[-- Type: text/plain, Size: 1273 bytes --]

Protocol Phase Analysis
   File name: TREBER7.DTT
Marker range: ANCHOR(101) to CURRENT(113)
Session name: None
Session desc: None
 Session ids: iids:7 tid(lun)[devtype]:2(0)[1]
Sess filters: None
Session date: 18-Oct-04  15:04:24 - 15:06:33
NNNNN = Phase Event Number (1st event is 0)
SSS.mmm_uuu_nnn = Difference Time (Secs.milli_micro_nano)
NNNNN SSS.mmm_uuu_nnn
  101           3_300  Arb
  102           2_188  Arbwin 7
  103         198_808 +Select 7,2
  104          23_016 +Sel/Resel End
  105       1_752_620 +MsgOut C0 Identify
                              01 06
                        Extended Msg+Len
  106       4_837_064 +MsgIn  07 Msg Reject
  107       1_104_660  CMD - Inquiry     
                        12 00 00 00 26 00
  108           9_788  DataIn (N)
                    0h: 01 80 03 02 21 00 01 30 ....!..0
                    8h: 49 42 4D 20 20 20 20 20 IBM     
                   10h: 55 4C 54 33 35 38 30 2D ULT3580-
                   18h: 54 44 31 20 20 20 20 20 TD1     
                   20h: 31 38 4E 32 00 00       18N2..
                       (38 Bytes)
  109           4_440  DEnd  38 Bytes
  110           1_236  Status 00 Good
  111           1_736  MsgIn  00 Cmd Complete
  112          44_392 Bus Free
  113           0_000  Arb

RE: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Adapter

[Tony Battersby]

> I have also seen drives that do unexpected disconnects if they get
sent PPR.

I too have seen a single-ended Exabyte Mammoth tape drive go to
unexpected bus free right after receiving the second byte of the PPR
extended message (01 06 - bus free).  Evidently it does not expect to
receive an extended message of that length.

I submitted a patch to sym53c8xx_2 in lk 2.4.x a few days ago to avoid
PPR on a SE or HVD bus, which fixes the problem for me.

Anthony J. Battersby
Cybernetics

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Adapter

[Matthew Wilcox]

On Fri, Nov 05, 2004 at 12:01:40PM -0500, Tony Battersby wrote:
> > I have also seen drives that do unexpected disconnects if they get
> sent PPR.
> 
> I too have seen a single-ended Exabyte Mammoth tape drive go to
> unexpected bus free right after receiving the second byte of the PPR
> extended message (01 06 - bus free).  Evidently it does not expect to
> receive an extended message of that length.
> 
> I submitted a patch to sym53c8xx_2 in lk 2.4.x a few days ago to avoid
> PPR on a SE or HVD bus, which fixes the problem for me.

Yup, but that won't solve Thomas Babut's problem, because his drive is
in LVD mode.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Ada pter

[Matthew Wilcox]

On Fri, Nov 05, 2004 at 04:25:03PM -0000, SUPPORT wrote:
> I've been seeing problems with various tape drives and PPR. And a SCSI 3 SE
> disk is interesting as well! SE and PPR don't get on too well;)

... yes ...

I think we should *never* attempt PPR on a SE bus, even when the drive
supports it.  We've seen bugs in Seagate drive firmware because of this,
so let's stop doing it.

How does this patch (whitespace damaged, apply by hand) make people feel?

--- linux-2.6/drivers/scsi/sym53c8xx_2/sym_hipd.c       2004-11-02 12:59:53.0000
00000 -0700
+++ sym2-2.6/drivers/scsi/sym53c8xx_2/sym_hipd.c        2004-11-05 13:20:18.0000
00000 -0700
@@ -1455,7 +1455,7 @@
                st->options &= ~PPR_OPT_DT;
        }
 
-       if (!(np->features & FE_ULTRA3))
+       if (np->scsi_mode != SMODE_LVD || !(np->features & FE_ULTRA3))
                st->options &= ~PPR_OPT_DT;
 
        if (st->options & PPR_OPT_DT) {


> Matthew - I have attached some bits of SCSI analyser traces which I hope may
> be useful. An IBM SCSI 3 SE disk and a couple of LTO tape drives - IBM and
> HP. The HP causes severe problems as modprobe hangs without the fix. I have
> also seen drives that do unexpected disconnects if they get sent PPR.

Thanks, those are interesting.  It's good to see that we really are
spitting PPR out onto the wire when we shouldn't be.

> I have been toying with the idea of disabling PPR capability if PPR is
> rejected - forcing sdev->ppr=0 in the driver when it determines PPR has been
> rejected - but I'm not sure that's right. There are drives which reject
> negotiation - legacy sync and wide at least - while they are initialising
> but will then accept it later on.

I think disabling PPR on an SE bus should be a better fix than that.

> Question - where does the full source for the sym53c8xx_2 driver live these
> days now that Gerard no long maintains it?

My primary development for this driver lives in the parisc-linux CVS.
I publish patches on an irregular basis.  If this patch fixes a
significant number of problems (and it seems it might), I'll do a
2.1.18n release.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Ada pter

[Thomas Babut]

Matthew Wilcox wrote:
> On Fri, Nov 05, 2004 at 04:25:03PM -0000, SUPPORT wrote:
> 
>>I've been seeing problems with various tape drives and PPR. And a SCSI 3 SE
>>disk is interesting as well! SE and PPR don't get on too well;)
> 
> 
> ... yes ...
> 
> I think we should *never* attempt PPR on a SE bus, even when the drive
> supports it.  We've seen bugs in Seagate drive firmware because of this,
> so let's stop doing it.
> 
> How does this patch (whitespace damaged, apply by hand) make people feel?
> 
> --- linux-2.6/drivers/scsi/sym53c8xx_2/sym_hipd.c       2004-11-02 12:59:53.0000
> 00000 -0700
> +++ sym2-2.6/drivers/scsi/sym53c8xx_2/sym_hipd.c        2004-11-05 13:20:18.0000
> 00000 -0700
> @@ -1455,7 +1455,7 @@
>                 st->options &= ~PPR_OPT_DT;
>         }
>  
> -       if (!(np->features & FE_ULTRA3))
> +       if (np->scsi_mode != SMODE_LVD || !(np->features & FE_ULTRA3))
>                 st->options &= ~PPR_OPT_DT;
>  
>         if (st->options & PPR_OPT_DT) {
> 
> 
> 
>>Matthew - I have attached some bits of SCSI analyser traces which I hope may
>>be useful. An IBM SCSI 3 SE disk and a couple of LTO tape drives - IBM and
>>HP. The HP causes severe problems as modprobe hangs without the fix. I have
>>also seen drives that do unexpected disconnects if they get sent PPR.
> 
> 
> Thanks, those are interesting.  It's good to see that we really are
> spitting PPR out onto the wire when we shouldn't be.
> 
> 
>>I have been toying with the idea of disabling PPR capability if PPR is
>>rejected - forcing sdev->ppr=0 in the driver when it determines PPR has been
>>rejected - but I'm not sure that's right. There are drives which reject
>>negotiation - legacy sync and wide at least - while they are initialising
>>but will then accept it later on.
> 
> 
> I think disabling PPR on an SE bus should be a better fix than that.
> 
> 
>>Question - where does the full source for the sym53c8xx_2 driver live these
>>days now that Gerard no long maintains it?
> 
> 
> My primary development for this driver lives in the parisc-linux CVS.
> I publish patches on an irregular basis.  If this patch fixes a
> significant number of problems (and it seems it might), I'll do a
> 2.1.18n release.
> 

None of the patches you posted solved my problems. I'm loosing hope... ;)

Regards,
Thomas Babut

RE: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Ada pter

[Richard Waltham]

 

> -----Original Message-----
> From: willy@www.linux.org.uk [mailto:willy@www.linux.org.uk] 
> 
> On Fri, Nov 05, 2004 at 04:25:03PM -0000, SUPPORT wrote:
> > I've been seeing problems with various tape drives and PPR. 
> And a SCSI 
> > 3 SE disk is interesting as well! SE and PPR don't get on too well;)
> 
> ... yes ...
> 
> I think we should *never* attempt PPR on a SE bus, even when 
> the drive supports it.  We've seen bugs in Seagate drive 
> firmware because of this, so let's stop doing it.
> 
> How does this patch (whitespace damaged, apply by hand) make 
> people feel?
> 

Good as a backup but the original PPR capability is defined in
scan_scsi.c. Shouldn't scan_scsi.c take note of the bus mode and enable
PPR capabilities accordingly? This would then cover this issue for all
relevant LLDDs wouldn't it?

> 
> > Matthew - I have attached some bits of SCSI analyser traces which I 
> > hope may be useful. An IBM SCSI 3 SE disk and a couple of LTO tape 
> > drives - IBM and HP. The HP causes severe problems as 
> modprobe hangs 
> > without the fix. I have also seen drives that do unexpected 
> disconnects if they get sent PPR.
> 
> Thanks, those are interesting.  It's good to see that we 
> really are spitting PPR out onto the wire when we shouldn't be.

And from what I've seen is the PPR negotiation keeps on being retied on
all subsequent commands. So performance really is killed by this.

> 
> > I have been toying with the idea of disabling PPR 
> capability if PPR is 
> > rejected - forcing sdev->ppr=0 in the driver when it determines PPR 
> > has been rejected - but I'm not sure that's right. There are drives 
> > which reject negotiation - legacy sync and wide at least - 
> while they 
> > are initialising but will then accept it later on.
> 
> I think disabling PPR on an SE bus should be a better fix than that.
> 

And don't forget HVD as well;)   

My main concern with my patch to scan_scsi.c was to handle SCSI 3 LVD
devices that caused problems. Scan_scsi.c sets all SCSI 3 devices as PPR
capable - SE, HVD as well as LVD. I have no issue with explicitly
disallowing PPR for SE and HVD devices. But what about SCSI 3 and LVD
devices that don't handle PPR - OK they may be broken but... For now the
patch for scan_scsi.c is a temp fix for us while we dream up something
better. It will only allow PPR with devices that advertise that they
handle DT transfers.

There is an issue that needs resolving where a drive appears to indicate
it is capable of PPR, i.e. says it is SCSI 3 + LVD, but does not
actually support PPR. Then when it receives at PPR message it causes
problems in the driver because it terminates the PPR MSG OUT early with
an unexpected phase change.

Exactly what happens then seems dependent on when the message is
aborted. You can see the differences in the analyser traces. The IBM LTO
is handled reasonably well although the driver spits out an unexpected
phase change msg, but the HP LTO really causes problems. And the disk
accepts the whole message and again causes no problems.

However currently the problem in these cases is that the PPR
capabilities bit (sdev->ppr) remains set so the next time negotiation is
attempted PPR is used again etc, etc. so the drives never negotiate to
what they are really capable of running at. This is why I mentioned
clearing sdev->ppr above. Because the capabilities determined in
scan_scsi.c indicate ppr, sync and wide and sdev->ppr remains set after
the negotiation is aborted the drives never ever successfully complete
negotiation no matter how many commands are sent as far as I can see.

Guess this boils down to three problems. 1. Make sure only drives on bus
modes capable of supporting PPR can be flagged as PPR capable. 2. Drives
that appear to support PPR (SCSI 3 + LVD) but _may be_ broken in some
way are handled by the driver without the unexpected phase changes
causing issues. And 3. What to do with drives that abort negotiation
messages, wide, sync or ppr?

1. is straight forward although there could be disagreement about where
the fix should really be. Personally, I think, this should really be
classified a general SCSI problem rather than specific to just this
driver.
2. requires modification to the handling of extended messages (or all
multi-byte messages?) so an aborted message doesn't break the driver.
This is driver specific.
3. this may be the nasty one. What do we do with negotiations that fail?
Do we keep trying the same negotiation time after time - i.e. leave it
as it is - not at all satisfactory, although I'm pretty certain I've
seen a trace from a drive that aborts negotiation until it is ready and
then accepts it later on - I really need to check this out when I'm back
in the office. Do we drop back from PPR to WIDE/SYNC? Is this better?
May be. Anything else? This again, I believe, can be classified as a
general issue rather than driver specific but may be easier to handle
within the driver. 


Richard


Richard Waltham
Bridgeworks Ltd
135 Somerford Road,
Christchurch
Dorset, BH23 3PY
England.

Tel 0870 121 0708
Fax 0870 121 0709

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Ada pter

[Matthew Wilcox]

On Sat, Nov 06, 2004 at 12:02:32AM -0000, Richard Waltham wrote:
> Good as a backup but the original PPR capability is defined in
> scan_scsi.c. Shouldn't scan_scsi.c take note of the bus mode and enable
> PPR capabilities accordingly? This would then cover this issue for all
> relevant LLDDs wouldn't it?

scan_scsi.c doesn't know what mode the bus is in.  scan_scsi.c doesn't
even know whether the bus is SPI, FC, iSCSI, SAS or SATA.

> > Thanks, those are interesting.  It's good to see that we 
> > really are spitting PPR out onto the wire when we shouldn't be.
> 
> And from what I've seen is the PPR negotiation keeps on being retied on
> all subsequent commands. So performance really is killed by this.

Yes, we'll do that as long as the device target parameters differ from
the achieved parameters.

> > I think disabling PPR on an SE bus should be a better fix than that.
> 
> And don't forget HVD as well;)   

Yes, I thought about HVD and decided that I wanted to code the check
against LVD rather than against SE ;-)

> My main concern with my patch to scan_scsi.c was to handle SCSI 3 LVD
> devices that caused problems. Scan_scsi.c sets all SCSI 3 devices as PPR
> capable - SE, HVD as well as LVD. I have no issue with explicitly
> disallowing PPR for SE and HVD devices. But what about SCSI 3 and LVD
> devices that don't handle PPR - OK they may be broken but...

I've got some devices that fail PPR when the bus is in SE mode but
work fine when the bus is in LVD mode.  So this patch certainly fixes
those problems.  THe question is whether there exist devices that:

 - Claim to be SCSI3 compliant
 - Fail PPR when on an LVD bus

> There is an issue that needs resolving where a drive appears to indicate
> it is capable of PPR, i.e. says it is SCSI 3 + LVD, but does not
> actually support PPR. Then when it receives at PPR message it causes
> problems in the driver because it terminates the PPR MSG OUT early with
> an unexpected phase change.

I think those devices need blacklisting.  Either that, or we need to do
DV in non-approved ways.  Perhaps start with SDTR+WDTR.  If we get up
to Fast-40, then try PPR.  I suspect James has Opinions on this though ;-)

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Ada pter

[Doug Ledford]

On Sat, 2004-11-06 at 00:44 +0100, Thomas Babut wrote:

> None of the patches you posted solved my problems. I'm loosing hope... ;)

Well, having "been there, done that" many years ago when PPR messages
were first defined, here's the logic I found that worked in all cases:

OK, in the INQUIRY snoop area of the completion handler, I did the
appropriate card/device checks to determine if we should enable PPR:

if (bus_mode == LVD && sdev->scsi_level >= 3 &&
	host->user_transfer_settings >= MIN_DT_SPEED)
	use_ppr = 1;
else if (bus_mode == LVD && sdev->scsi_level < 3 && 
	(inquiry_len >= 57 && inq_data[56] & INQUIRY_DT_BIT) &&
	host->user_transfer_settings >= MIN_DT_SPEED)
	use_ppr = 1;
else
	use_sdtr_wdtr = 1;

In the event we set ppr on a device that can't handle it, I had to go
into the interrupt handler routine and in both the case of BUSFREE and
MSG_REJECT, if we were in the process of sending a ppr message and we
get either one of these in return, then turn off ppr messages for the
device (otherwise, we can get into an infinite loop were we accidentally
turned PPR on for a device that won't tolerate it for whatever reason,
and in fact once I know the ppr message has been rejected, the interrupt
handler would rewrite the ppr message into the closest possible
WDTR/SDTR message pair, assert ATNO on the bus to get us back in message
out phase, and proceed to go ahead and send the WDTR message, then wait
for a WDTR return, then assert ATNO again so we have a chance to do the
SDTR, then wait for the SDTR return, then proceed with the other
phases).

Finally, there are devices out there that do target initiated speed
negotiations.  If we get an incoming PPR message from a device, then you
are free to skip all those other checks in the INQUIRY snoop area and
just immediately set PPR on this device.  Now, you still need to do the
things like check that the bus is LVD before actually enabling LVD
speeds, but an unsolicited incoming PPR message is a dead giveaway that
the device supports PPR messages.  So, in the incoming message handling
portion of the interrupt handler, if we get an unsolicited PPR message
from a device, then we override any other settings we may have on the
device in terms of whether or not it supports PPR messages and we
disable the whole INQUIRY snoop operation for this device because we
don't want the INQUIRY snoop to disable PPR now that we know for a fact
that it's supported on this device.

Implement that, and you won't have these problems any more.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc.
         1801 Varsity Dr.
         Raleigh, NC 27606

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Ada pter

[Doug Ledford]

On Sat, 2004-11-06 at 03:59 +0000, Matthew Wilcox wrote:

> I think those devices need blacklisting.  Either that, or we need to do
> DV in non-approved ways.  Perhaps start with SDTR+WDTR.  If we get up
> to Fast-40, then try PPR.  I suspect James has Opinions on this though ;-)

Bleah.  I have opinions on this whether James does or not.  If you are
going to control device negotiation at the mid layer level, then you
need these things:

     1. Current bus state, as pointed out there are devices that reject
        PPR unless on an LVD bus, and whether or not you can get at the
        current bus mode and how is hardware dependent and changes from
        driver to driver, so now you have to add a new entry into the
        low level driver for all SPI class drivers hostt->bus_is_lvd()
        in order to be able to do proper checks at the mid layer level.
        This needs to be a call in function, not a static element.  Bus
        mode can change, especially from something as simple as hot
        plugging a new drive into an existing LVD JBOD, but the drive
        accidentally has the FORCE_SE jumper enabled.  This will force
        the whole bus to switch to SE instantly, and all drives will
        have to renegotiate.  So, given hotplug issues, the bus state
        needs to be checked at each negotiation, not based upon some
        previous state.
     2. Drivers *should*, when possible, honor user settings stored in
        NVRAM on the cards.  So, add another entry point so that the low
        level drivers with NVRAM can pass up the user specified max
        speed, width, cache settings, etc.  Oh, and if it isn't obvious,
        there are devices out there that reject attempted PPR messages
        if the speed/width/mode that you are requesting can be
        represented by a SDTR/WDTR pairs instead.  In other words, if
        you aren't requesting a DT + possible options settings, then
        don't use PPR.
     3. Recovery operations in the LLDD interrupt handler need to change
        the way commands are handled.  Given an attempt to send PPR
        messages, both BUSFREE and subsequent MSG_REJECT situations need
        to cancel the attempted and all future PPR messages, so now you
        need a hook in the scsi layer for the driver to tell the mid
        layer "Quit telling me to do PPR, it doesn't work you moron"
     4. In the event that a device doesn't advertise in any given way
        that it is capable of PPR, but does in fact send an unsolicited
        PPR message to the driver, we now need a hook in the mid layer
        so the driver can say "Well, would you look at that...it's a PPR
        device hiding in the corner"

That's the level of API you'll need to properly do this from the mid
level.

Of course, you could genericize this a bit.  You could have a callin for
current bus state in the LLDD.  Something like hostt->get_bus_type() and
have it return an or'ed bitmask of state bits, BUS_WIDE | BUS_SYNC |
BUS_{LVD,SE,HVD}, something like that, then it could possibly do more
than just PPR/LVD negotiation, but personally this is one of those
things that I think is card specific enough that it ought to just stay
in the LLDD.  My $.02.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc.
         1801 Varsity Dr.
         Raleigh, NC 27606

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Ada pter

[Christoph Hellwig]

On Sat, Nov 06, 2004 at 03:59:51AM +0000, Matthew Wilcox wrote:
> On Sat, Nov 06, 2004 at 12:02:32AM -0000, Richard Waltham wrote:
> > Good as a backup but the original PPR capability is defined in
> > scan_scsi.c. Shouldn't scan_scsi.c take note of the bus mode and enable
> > PPR capabilities accordingly? This would then cover this issue for all
> > relevant LLDDs wouldn't it?
> 
> scan_scsi.c doesn't know what mode the bus is in.  scan_scsi.c doesn't
> even know whether the bus is SPI, FC, iSCSI, SAS or SATA.

And PPR only makes sense for SPI anyway.  An good argument why this
should move to the SPI transport class, which does know about SE vs HVD
vs LVD.

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Ada pter

[Matthew Wilcox]

On Sat, Nov 06, 2004 at 12:03:58PM +0000, Christoph Hellwig wrote:
> On Sat, Nov 06, 2004 at 03:59:51AM +0000, Matthew Wilcox wrote:
> > On Sat, Nov 06, 2004 at 12:02:32AM -0000, Richard Waltham wrote:
> > > Good as a backup but the original PPR capability is defined in
> > > scan_scsi.c. Shouldn't scan_scsi.c take note of the bus mode and enable
> > > PPR capabilities accordingly? This would then cover this issue for all
> > > relevant LLDDs wouldn't it?
> > 
> > scan_scsi.c doesn't know what mode the bus is in.  scan_scsi.c doesn't
> > even know whether the bus is SPI, FC, iSCSI, SAS or SATA.
> 
> And PPR only makes sense for SPI anyway.  An good argument why this
> should move to the SPI transport class, which does know about SE vs HVD
> vs LVD.

That would make sense if more of this were done at a higher level.
As it is right now, the decision whether to use PPR, SDTR or WDTR is
entirely up to the driver.  I think there's a lot more consolidation
that could be done into the midlayer, but we should probably see what
other drivers requirements are before making it perfect for sym2.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Ada pter

[Thomas Babut]

Hi,

Matthew, you wanted a debug output from the server. An local 
Administrator send me a photo after I bootet the following Kernel:

2.6.10-rc1-bk15, sym-2.1.18m, with sym53c8xx.debug=0x200

Here it is: http://tomek.tueddeln.de/screenshot3.jpg

(Scrolling up was not possible he told me.)

But I hope it can help you in some way.

Thanks.

Regards,
Thomas Babut

RE: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Adapter

[Tony Battersby]

> Finally, there are devices out there that do target initiated speed
> negotiations.  If we get an incoming PPR message from a device

The spec says:

"PPR may be originated by SCSI initiator ports but shall not be
originated by SCSI target ports."

"WDTR and SDTR may be originated by either SCSI target ports or SCSI
initiator ports."

Unless someone has seen a counter-example, the case of target-originated
PPR negotiations can probably be ignored.

Anthony J. Battersby
Cybernetics

RE: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Adapter

[Doug Ledford]

On Mon, 2004-11-08 at 09:44 -0500, Tony Battersby wrote:
> > Finally, there are devices out there that do target initiated speed
> > negotiations.  If we get an incoming PPR message from a device
> 
> The spec says:
> 
> "PPR may be originated by SCSI initiator ports but shall not be
> originated by SCSI target ports."

Yeah, what the spec says and what devices do are not always one and the
same thing.

> "WDTR and SDTR may be originated by either SCSI target ports or SCSI
> initiator ports."
> 
> Unless someone has seen a counter-example, the case of target-originated
> PPR negotiations can probably be ignored.

DEC SCSI-2 hard disks that were installed with modified firmware.
Specifically, the Vaxen class computers they were hooked up to A) didn't
expect and handle SCSI-3 devices properly, B) didn't handle the DT bit
in the INQUIRY data properly, C) but DEC still wanted the devices to
talk 160MByte/s transfer rates, so the firmware was modified to send
preemptive PPR messages.  Problem solved something like 4 years ago, but
it existed at the time and physical devices may still exist in the
field.  In any case, yeah, the spec says otherwise, but I wouldn't rely
on that since getting this wrong leads to an infinite speed negotiation
loop.  Infinite loops suck...better safe than sorry on this issue IMO.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc.
         1801 Varsity Dr.
         Raleigh, NC 27606

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Adapter

[Thomas Babut]

Hi all,

yesterday I tried some new Kernels...

2.4.28-bk1 with sym53c8xx: works with normal Performance
Bootlog:
Nov 19 01:31:39 srv kernel: SCSI subsystem driver Revision: 1.00
Nov 19 01:31:39 srv kernel: sym53c8xx: at PCI bus 0, device 8, function 0
Nov 19 01:31:39 srv kernel: sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
Nov 19 01:31:39 srv kernel: sym53c8xx: 53c1010-33 detected with Symbios 
NVRAM
Nov 19 01:31:39 srv kernel: sym53c8xx: at PCI bus 0, device 8, function 1
Nov 19 01:31:39 srv kernel: sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
Nov 19 01:31:39 srv kernel: sym53c8xx: 53c1010-33 detected with Symbios 
NVRAM
Nov 19 01:31:39 srv kernel: sym53c1010-33-0: rev 0x1 on pci bus 0 device 
8 function 0 irq 9
Nov 19 01:31:39 srv kernel: sym53c1010-33-0: Symbios format NVRAM, ID 7, 
Fast-80, Parity Checking
Nov 19 01:31:39 srv kernel: sym53c1010-33-0: on-chip RAM at 0xf9000000
Nov 19 01:31:39 srv kernel: sym53c1010-33-0: restart (scsi reset).
Nov 19 01:31:39 srv kernel: sym53c1010-33-0: handling phase mismatch 
from SCRIPTS.
Nov 19 01:31:39 srv kernel: sym53c1010-33-0: Downloading SCSI SCRIPTS.
Nov 19 01:31:39 srv kernel: sym53c1010-33-1: rev 0x1 on pci bus 0 device 
8 function 1 irq 11
Nov 19 01:31:39 srv kernel: sym53c1010-33-1: Symbios format NVRAM, ID 7, 
Fast-80, Parity Checking
Nov 19 01:31:39 srv kernel: sym53c1010-33-1: on-chip RAM at 0xf8000000
Nov 19 01:31:39 srv kernel: sym53c1010-33-1: restart (scsi reset).
Nov 19 01:31:39 srv kernel: sym53c1010-33-1: handling phase mismatch 
from SCRIPTS.
Nov 19 01:31:39 srv kernel: sym53c1010-33-1: Downloading SCSI SCRIPTS.
Nov 19 01:31:39 srv kernel: scsi0 : sym53c8xx-1.7.3c-20010512
Nov 19 01:31:39 srv kernel: scsi1 : sym53c8xx-1.7.3c-20010512
Nov 19 01:31:39 srv kernel: blk: queue f7e9a018, I/O limit 1048575Mb 
(mask 0xffffffffff)
Nov 19 01:31:39 srv kernel:   Vendor: QUANTUM   Model: ATLAS10K2-TY367J 
  Rev: DDD6
Nov 19 01:31:39 srv kernel:   Type:   Direct-Access 
  ANSI SCSI revision: 03
Nov 19 01:31:39 srv kernel: blk: queue f7e67e18, I/O limit 1048575Mb 
(mask 0xffffffffff)
Nov 19 01:31:39 srv kernel: sym53c1010-33-0-<2,0>: tagged command queue 
depth set to 8
Nov 19 01:31:39 srv kernel: Attached scsi disk sda at scsi0, channel 0, 
id 2, lun 0
Nov 19 01:31:39 srv kernel: sym53c1010-33-0-<2,*>: FAST-40 SCSI 40.0 
MB/s (25.0 ns, offset 31)
Nov 19 01:31:39 srv kernel: SCSI device sda: 71721820 512-byte hdwr 
sectors (36722 MB)
Nov 19 01:31:39 srv kernel: Partition check:
Nov 19 01:31:39 srv kernel:  sda: sda1 sda2

2.4.28-bk1 with sym53c8xx2: works, but poor performance (max. 5 MByte/s)
Bootlog:
Nov 19 01:27:19 srv kernel: SCSI subsystem driver Revision: 1.00
Nov 19 01:27:19 srv kernel: sym.0.8.0: setting PCI_COMMAND_PARITY...
Nov 19 01:27:19 srv kernel: sym.0.8.1: setting PCI_COMMAND_PARITY...
Nov 19 01:27:19 srv kernel: sym0: <1010-33> rev 0x1 on pci bus 0 device 
8 function 0 irq 9
Nov 19 01:27:19 srv kernel: sym0: using 64 bit DMA addressing
Nov 19 01:27:19 srv kernel: sym0: Symbios NVRAM, ID 7, Fast-80, LVD, 
parity checking
Nov 19 01:27:19 srv kernel: sym0: open drain IRQ line driver, using 
on-chip SRAM
Nov 19 01:27:19 srv kernel: sym0: using LOAD/STORE-based firmware.
Nov 19 01:27:19 srv kernel: sym0: handling phase mismatch from SCRIPTS.
Nov 19 01:27:19 srv kernel: sym0: SCSI BUS has been reset.
Nov 19 01:27:19 srv kernel: sym1: <1010-33> rev 0x1 on pci bus 0 device 
8 function 1 irq 11
Nov 19 01:27:19 srv kernel: sym1: using 64 bit DMA addressing
Nov 19 01:27:19 srv kernel: sym1: Symbios NVRAM, ID 7, Fast-80, LVD, 
parity checking
Nov 19 01:27:19 srv kernel: sym1: open drain IRQ line driver, using 
on-chip SRAM
Nov 19 01:27:19 srv kernel: sym1: using LOAD/STORE-based firmware.
Nov 19 01:27:19 srv kernel: sym1: handling phase mismatch from SCRIPTS.
Nov 19 01:27:19 srv kernel: sym1: SCSI BUS has been reset.
Nov 19 01:27:19 srv kernel: scsi0 : sym-2.1.17a
Nov 19 01:27:19 srv kernel: scsi1 : sym-2.1.17a
Nov 19 01:27:19 srv kernel: blk: queue f7e9a018, I/O limit 1048575Mb 
(mask 0xffffffffff)
Nov 19 01:27:19 srv kernel:   Vendor: QUANTUM   Model: ATLAS10K2-TY367J 
  Rev: DDD6
Nov 19 01:27:19 srv kernel:   Type:   Direct-Access 
  ANSI SCSI revision: 03
Nov 19 01:27:19 srv kernel: blk: queue f7e64e18, I/O limit 1048575Mb 
(mask 0xffffffffff)
Nov 19 01:27:19 srv kernel: sym0:2:0: tagged command queuing enabled, 
command queue depth 16.
Nov 19 01:27:19 srv kernel: Attached scsi disk sda at scsi0, channel 0, 
id 2, lun 0
Nov 19 01:27:19 srv kernel: sym0:2:0:M_REJECT to send for : 1-3-1-9-1f.
Nov 19 01:27:19 srv kernel: SCSI device sda: 71721820 512-byte hdwr 
sectors (36722 MB)
Nov 19 01:27:19 srv kernel: Partition check:
Nov 19 01:27:19 srv kernel:  sda: sda1 sda2

2.6.10-rc2-bk3 with sym53c8xx2: System doesn't come up, same errors as 
before
No bootlog because of the lack of physical access to the machine.

I still would like to run Kernel 2.6. :)

Regards,
Thomas Babut

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Adapter

[Thomas Babut]

Would it be possible to integrate the sym53c8xx (1, not sym53c8xx_2) 
driver from Kernel 2.4.28 in 2.6? For me it would be the working 
solution to use my SCSI-Controller with Kernel 2.6.

Perhaps someone could make a patch for Kernel 2.6 which adds the old driver.

Thanks.

Regards,
Thomas Babut

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Adapter

[Matthew Wilcox]

On Tue, Nov 23, 2004 at 02:39:17AM +0100, Thomas Babut wrote:
> Would it be possible to integrate the sym53c8xx (1, not sym53c8xx_2) 
> driver from Kernel 2.4.28 in 2.6? For me it would be the working 
> solution to use my SCSI-Controller with Kernel 2.6.
> 
> Perhaps someone could make a patch for Kernel 2.6 which adds the old driver.

No.  Don't do this.  Help make sym2 work for your system.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: Kernel 2.6.x hangs with Symbios Logic 53c1010 Ultra3 SCSI Adapter

[Ingo Korb]

Matthew Wilcox <matthew@wil.cx> writes:

> On Tue, Nov 23, 2004 at 02:39:17AM +0100, Thomas Babut wrote:
>> Perhaps someone could make a patch for Kernel 2.6 which adds the old driver.
>
> No.  Don't do this.  Help make sym2 work for your system.

So what can one do? My Alphastation 200 has a 53C810 rev. 02 that only works
with the ncr53c8xx-driver from 2.4, sym53c8xx_2 just hangs. Details were
posted here about two weeks ago, without any replies.

-ik