public inbox for linux-scsi@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Missel <peter.missel@onlinehome.de>
To: Matthew Wilcox <matthew@wil.cx>
Cc: linux-scsi@vger.kernel.org
Subject: Re: SYM8xx_2 driver ignores certain EEPROM settings
Date: Sat, 26 Feb 2005 20:34:09 +0100	[thread overview]
Message-ID: <200502262034.09406.peter.missel@onlinehome.de> (raw)
In-Reply-To: <20041231145306.GB18080@parcelfarce.linux.theplanet.co.uk>

Greetings!

Now that producing another pair of coasters reminded me that this here system 
has a problem on SCSI branch 1, I'd like to inquire about the current state 
of affairs regarding this topic. (Also, I've encountered another machine I'd 
like to upgrade to a newer Linux kernel but can't since it's using this very 
feature-that-went-missing.)

Is there a patch I can install and try out, or anything else I can do?

best regards,
Peter Missel

On Friday 31 December 2004 15:53, Matthew Wilcox wrote:
> On Fri, Dec 31, 2004 at 01:43:42PM +0100, Peter Missel wrote:
> > Hello Matthew!
> >
> > I hope I'm turning to the right person with my report.
>
> Yep, that's me.  Best to keep linux-scsi in the loop too.  That way
> other people prod me when I've been inattentive ;-)
>
> > After updating to SuSE
> > Linux 9.2, kernel 2.6.8, which brought rev. 2.1.18j of the LSI SCSI
> > driver, I see that the driver's speed/width negotiation no longer
> > considers any limitations configured in the adapter's BIOS. My previous
> > installation, using kernel 2.4.20 and its included LSI SCSI driver, did
> > that perfectly fine.
>
> Yes, that's right.  I'm not a big fan of dealing with distro kernels
> because they make changes without informing me.  An earlier SuSE kernel
> commented out the domain validation calls from the sym2 driver -- without
> putting the previous code back in.  However, that problem doesn't seem to
> be present in this kernel.
>
> > For example (and that's why I noticed), if in SCSI BIOS a certain SCSI
> > channel (or a single device) has been limited by the user to 10 MT/s, the
> > Linux SCSI driver nonetheless negotiates to 20 MT/s.
> >
> > It is necessary to stick to the settings from BIOS (as read from EEPROM),
> > simply because there might be a good reason why the user did that. In my
> > particular case, I need to restrict the sym0 channel from doing Ultra (20
> > MT/s) altogether because the total cable length doesn't allow me to,
>
> The Domain Validation code is supposed to catch problems like this, and
> automatically fall back to a setting that works without requiring the
> user to set magic bits in their NVRAM.  Are you actually experiencing
> problems due to the faster speed, or is it just that you know the cable
> is out of spec?
>
> Hm, I see we skip the write tests, presumably because the drive doesn't
> support a write buffer.  Drat.
>
> > and I
> > have one device restricted further to 5 MT/s because I own a buggy
> > Fujitsu MO that claims 10 MT/s capability but (according to Fujitsu's
> > support answer back when I bought it) has a SCSI interface chip on that
> > can't actually do that.
>
> Buggy drive firmware keeps on biting us ;-(  It does seem worth honouring
> the NVRAM settings, but the thing is that we then have to support such
> fixes in each driver.
>
> > Below please see a snippet from /var/log/boot.msg; the external branch
> > (including the MO) is disconnected so I can use the system at all. You
> > can still see from dev 0.0.1.0 that 20 MT/s are being set up although the
> > adapter's EEPROM settings mandate a maximum of 10 MT/s for the entire
> > sym0 channel. Also, in line 5 of the snippet, you see the sym0 host is
> > being logged as "Fast-40 SE" which should read lower. The "SCAN AT BOOT"
> > parameter from the same EEPROM is read correctly.
> >
> > Being a system BIOS developper, I have the means to do an EEPROM dump of
> > my SCSI adapter. So in case this is helpful to you, I'll do that as soon
> > as I'm back to work on Jan 10.
>
> I don't need you to do that -- I know the ability has been removed from the
> driver.  I bet I can put it back without disturbing things too much.
>
> > <5>SCSI subsystem initialized
> > <6>ACPI: PCI interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 169
> > <6>sym0: <896> rev 0x5 at pci 0000:00:0a.0 irq 169
> > <6>sym0: using 64 bit DMA addressing
> > <4>sym0: Symbios NVRAM, ID 7, Fast-40, SE, parity checking
> > <4>sym0: SCAN AT BOOT disabled for targets 2 3 8 9 10 11 12 13 14 15.
> > <5>sym0: SCSI BUS has been reset.
> > <6>scsi0 : sym-2.1.18j
> > <5>  Vendor: NAKAMICH  Model: MJ-5.16S          Rev: 1.02
> > <5>  Type:   CD-ROM                             ANSI SCSI revision: 02
> > <6>scsi(0:0:0:0): Beginning Domain Validation
> > <6>sym0:0: FAST-10 SCSI 10.0 MB/s ST (100.0 ns, offset 15)
> > <6>scsi(0:0:0:0): Domain Validation skipping write tests
> > <6>scsi(0:0:0:0): Ending Domain Validation
> > <5>  Vendor: NAKAMICH  Model: MJ-5.16S          Rev: 1.02
> > <5>  Type:   CD-ROM                             ANSI SCSI revision: 02
> > <6>scsi(0:0:0:1): Beginning Domain Validation
> > <6>sym0:0: asynchronous.
> > <6>sym0:0: FAST-10 SCSI 10.0 MB/s ST (100.0 ns, offset 15)
> > <6>scsi(0:0:0:1): Domain Validation skipping write tests
> > <6>scsi(0:0:0:1): Ending Domain Validation
> > <5>  Vendor: NAKAMICH  Model: MJ-5.16S          Rev: 1.02
> > <5>  Type:   CD-ROM                             ANSI SCSI revision: 02
> > <6>scsi(0:0:0:2): Beginning Domain Validation
> > <6>sym0:0: asynchronous.
> > <6>sym0:0: FAST-10 SCSI 10.0 MB/s ST (100.0 ns, offset 15)
> > <6>scsi(0:0:0:2): Domain Validation skipping write tests
> > <6>scsi(0:0:0:2): Ending Domain Validation
> > <5>  Vendor: NAKAMICH  Model: MJ-5.16S          Rev: 1.02
> > <5>  Type:   CD-ROM                             ANSI SCSI revision: 02
> > <6>scsi(0:0:0:3): Beginning Domain Validation
> > <6>sym0:0: asynchronous.
> > <6>sym0:0: FAST-10 SCSI 10.0 MB/s ST (100.0 ns, offset 15)
> > <6>scsi(0:0:0:3): Domain Validation skipping write tests
> > <6>scsi(0:0:0:3): Ending Domain Validation
> > <5>  Vendor: NAKAMICH  Model: MJ-5.16S          Rev: 1.02
> > <5>  Type:   CD-ROM                             ANSI SCSI revision: 02
> > <6>scsi(0:0:0:4): Beginning Domain Validation
> > <6>sym0:0: asynchronous.
> > <6>sym0:0: FAST-10 SCSI 10.0 MB/s ST (100.0 ns, offset 15)
> > <6>scsi(0:0:0:4): Domain Validation skipping write tests
> > <6>scsi(0:0:0:4): Ending Domain Validation
> > <5>  Vendor: YAMAHA    Model: CRW2100S          Rev: 1.0N
> > <5>  Type:   CD-ROM                             ANSI SCSI revision: 02
> > <6>scsi(0:0:1:0): Beginning Domain Validation
> > <6>sym0:1: FAST-20 SCSI 20.0 MB/s ST (50.0 ns, offset 7)
> > <6>scsi(0:0:1:0): Domain Validation skipping write tests
> > <6>scsi(0:0:1:0): Ending Domain Validation
> > <5>  Vendor: OnStream  Model: SC-30             Rev: 1.09
> > <5>  Type:   Sequential-Access                  ANSI SCSI revision: 02
> > <6>scsi(0:0:4:0): Beginning Domain Validation
> > <6>sym0:4: FAST-10 SCSI 10.0 MB/s ST (100.0 ns, offset 7)
> > <6>scsi(0:0:4:0): Domain Validation skipping write tests
> > <6>scsi(0:0:4:0): Ending Domain Validation
> > <6>ACPI: PCI interrupt 0000:00:0a.1[B] -> GSI 19 (level, low) -> IRQ 209
> > <6>sym1: <896> rev 0x5 at pci 0000:00:0a.1 irq 209
> > <6>sym1: using 64 bit DMA addressing
> > <4>sym1: Symbios NVRAM, ID 7, Fast-40, LVD, parity checking
> > <4>sym1: SCAN AT BOOT disabled for targets 1 2 3 4 5 6 8 9 10 11 12 13 14
> > 15. <5>sym1: SCSI BUS has been reset.
> > <6>scsi1 : sym-2.1.18j
> > <5>  Vendor: QUANTUM   Model: ATLAS IV 9 WLS    Rev: 0909
> > <5>  Type:   Direct-Access                      ANSI SCSI revision: 03
> > <6>sym1:0:0: tagged command queuing enabled, command queue depth 16.
> > <6>scsi(1:0:0:0): Beginning Domain Validation
> > <6>sym1:0: wide asynchronous.
> > <6>sym1:0: FAST-40 WIDE SCSI 80.0 MB/s ST (25.0 ns, offset 31)
> > <6>scsi(1:0:0:0): Domain Validation skipping write tests
> > <6>scsi(1:0:0:0): Ending Domain Validation
> > <5>SCSI device sda: 17942584 512-byte hdwr sectors (9187 MB)
> > <5>SCSI device sda: drive cache: write back
> > <6> sda: sda1 sda2
> > <5>Attached scsi disk sda at scsi1, channel 0, id 0, lun 0

  parent reply	other threads:[~2005-02-26 19:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200412311343.42484.peter.missel@onlinehome.de>
2004-12-31 14:53 ` SYM8xx_2 driver ignores certain EEPROM settings Matthew Wilcox
2004-12-31 15:01   ` James Bottomley
2004-12-31 15:20   ` Peter Missel
2005-01-01 22:16     ` Matthias Andree
2005-01-02  0:28       ` Peter Missel
2005-01-02  0:40         ` Matthias Andree
2005-01-02  1:03           ` Matthew Wilcox
2005-01-02  9:58             ` Peter Missel
2005-02-26 19:34   ` Peter Missel [this message]
2005-04-08 22:57     ` Peter Missel
2005-04-09 14:02       ` Matthew Wilcox
2005-04-09 21:44         ` Peter Missel
2005-04-18 17:55           ` Peter Missel
2005-05-04 21:47           ` SYM8xx_2 sync speed negotiation Peter Missel
2005-06-18 21:52             ` Peter Missel
2005-06-19 10:45               ` endless loop problem with SYM8xx_2: unexpected disconnect Christian Werner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200502262034.09406.peter.missel@onlinehome.de \
    --to=peter.missel@onlinehome.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=matthew@wil.cx \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox