Re: SYM8xx_2 driver ignores certain EEPROM settings

Re: SYM8xx_2 driver ignores certain EEPROM settings

[Matthew Wilcox]

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

-- 
"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: SYM8xx_2 driver ignores certain EEPROM settings

[James Bottomley]

On Fri, 2004-12-31 at 14:53 +0000, Matthew Wilcox wrote:
> 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.

There are two ways of doing this:

1) one would be to have the hard coded limits in the sym2 driver (like
they were previously) and make sure we don't allow setting or
negotiating over them or

2) have the limits stored in the SPI transport class and make it enforce
them.

1) Is probably easier (less code since you just put back a modification
of what was taken out) 2) would be more globally useful, though ...

James

Re: SYM8xx_2 driver ignores certain EEPROM settings

[Peter Missel]

Greetings!

Thanks for the quick reply.

> 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.

I'm fine with the additional safety from the Domain Validation. Nonetheless, 
the driver shouldn't validate speeds and/or transfer widths that have been 
forbidden by the user.
Another example (which I can't verify right now) is negotiation width. 
External HDD enclosures might be connected through a Narrow cable but 
actually contain a Wide drive. That'll be one thing where the user would use 
the SCSI BIOS to limit the particular unit to Narrow. This however would 
possibly be caught by the DM failing.

> > 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?
>
I do actually see failures when using the one drive that supports Ultra (it's 
a CDRW). They're gone as soon as I either disconnect the external branch, or 
when using only Fast-10 transfers.
Same for the old Fujitsu MO (an early revision 2513, btw). Running it at 10 
MT/s causes SCSI hangs and resets galore, it's fine at 5.

> Hm, I see we skip the write tests, presumably because the drive doesn't
> support a write buffer.  Drat.

Domain validation on the CDRW drive comes out OK even with the external branch 
connected, but in actual usage, operation fails pretty quickly.

> 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.

Honouring the NVRAM settings should do for the individual user, although some 
method of blacklisting known-bad devices wouldn't be bad either. It's been a 
while since I've been digging around in Linux SCSI driver architecture, but 
didn't we once have a device blacklist in the SCSI core?

> > 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.

Ah. Go on then ;)

Please let me know when there's something I can give a test run.

regards,
Peter

Re: SYM8xx_2 driver ignores certain EEPROM settings

[Matthias Andree]

Peter Missel <peter.missel@onlinehome.de> writes:

> I'm fine with the additional safety from the Domain Validation. Nonetheless, 
> the driver shouldn't validate speeds and/or transfer widths that have been 
> forbidden by the user.
> Another example (which I can't verify right now) is negotiation width. 
> External HDD enclosures might be connected through a Narrow cable but 
> actually contain a Wide drive. That'll be one thing where the user would use 
> the SCSI BIOS to limit the particular unit to Narrow. This however would 
> possibly be caught by the DM failing.

No external enclosure necessary. There are also wide chips with only
narrow connectors, for instance, on the Tekram DC-310U, DC-390U boards -
they use a SYM53C860 or SYM53C875, a wide capable chip, but provide only
narrow (50-pin) connectors. I last tried some 2.4.X kernel on such a
setup, and haven't used the DC-390U in a long time (I replaced it by a
DC-390F) - so I cannot test at this time.

-- 
Matthias Andree

Re: SYM8xx_2 driver ignores certain EEPROM settings

[Peter Missel]

Hi again!

On Saturday 01 January 2005 23:16, Matthias Andree wrote:
> Peter Missel <peter.missel@onlinehome.de> writes:
> > I'm fine with the additional safety from the Domain Validation.
> > Nonetheless, the driver shouldn't validate speeds and/or transfer widths
> > that have been forbidden by the user.
> > Another example (which I can't verify right now) is negotiation width.
> > External HDD enclosures might be connected through a Narrow cable but
> > actually contain a Wide drive. That'll be one thing where the user would
> > use the SCSI BIOS to limit the particular unit to Narrow. This however
> > would possibly be caught by the DM failing.
>
> No external enclosure necessary. There are also wide chips with only
> narrow connectors, for instance, on the Tekram DC-310U, DC-390U boards -
> they use a SYM53C860 or SYM53C875, a wide capable chip, but provide only
> narrow (50-pin) connectors. I last tried some 2.4.X kernel on such a
> setup, and haven't used the DC-390U in a long time (I replaced it by a
> DC-390F) - so I cannot test at this time.

Yes of course ... LSI (NCR back then) had one of those themselves, IIRC it was 
the "8250" and "8750" controller card. These used the 52C825 Fast-Wide and 
53C875 UW controller chips respectively, but had only Narrow connectors.

This possibly is because with the exception of the 815 chip, LSI's Narrow 
chips don't have a BIOS ROM interface, while the Wide chips do. So if you 
were to build a controller card w/ boot ROM support, you had to use a Wide 
chip even if the card was to be Narrow-only.

Tekram's 310U, IIRC, was a ROM-less card that used the 860 Narrow chip, wasn't 
it?

LSI also had a rather quirky special interpretation of certain bits in the 
subsystem ID field (I'm serious!), flagging "halved" interface speed and a 
couple of other aspects. I have the ancient application note at work if 
you're interested - LSI confirmed to me somewhat recently that this is still 
valid. I don't know whether and how this might be relevant to OS driver 
behavior, but it's certainly worth a look while we're working on the topic.

regards,
Peter

Re: SYM8xx_2 driver ignores certain EEPROM settings

[Matthias Andree]

Peter Missel schrieb am 2005-01-02:

> This possibly is because with the exception of the 815 chip, LSI's Narrow 
> chips don't have a BIOS ROM interface, while the Wide chips do. So if you 
> were to build a controller card w/ boot ROM support, you had to use a Wide 
> chip even if the card was to be Narrow-only.
> 
> Tekram's 310U, IIRC, was a ROM-less card that used the 860 Narrow
> chip, wasn't it?

On the DC-310U, they used a SYM53C860, I'm not sure about the specs of
the chip now that you write narrow.

-- 
Matthias Andree

Re: SYM8xx_2 driver ignores certain EEPROM settings

[Matthew Wilcox]

On Sun, Jan 02, 2005 at 01:40:04AM +0100, Matthias Andree wrote:
> Peter Missel schrieb am 2005-01-02:
> 
> > This possibly is because with the exception of the 815 chip, LSI's Narrow 
> > chips don't have a BIOS ROM interface, while the Wide chips do. So if you 
> > were to build a controller card w/ boot ROM support, you had to use a Wide 
> > chip even if the card was to be Narrow-only.
> > 
> > Tekram's 310U, IIRC, was a ROM-less card that used the 860 Narrow
> > chip, wasn't it?
> 
> On the DC-310U, they used a SYM53C860, I'm not sure about the specs of
> the chip now that you write narrow.

This is documented in Documentation/scsi/sym53c8xx_2.txt:

       On board                                   LOAD/STORE   HARDWARE
Chip   SDMS BIOS   Wide   SCSI std.   Max. sync   SCRIPTS      PHASE MISMATCH
----   ---------   ----   ---------   ----------  ----------   --------------
[...]
860        N         N      FAST20    20 MB/s        Y             N

-- 
"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: SYM8xx_2 driver ignores certain EEPROM settings

[Peter Missel]

On Sunday 02 January 2005 02:03, Matthew Wilcox wrote:
> On Sun, Jan 02, 2005 at 01:40:04AM +0100, Matthias Andree wrote:
> > Peter Missel schrieb am 2005-01-02:
> > > This possibly is because with the exception of the 815 chip, LSI's
> > > Narrow chips don't have a BIOS ROM interface, while the Wide chips do.
> > > So if you were to build a controller card w/ boot ROM support, you had
> > > to use a Wide chip even if the card was to be Narrow-only.
> > >
> > > Tekram's 310U, IIRC, was a ROM-less card that used the 860 Narrow
> > > chip, wasn't it?
> >
> > On the DC-310U, they used a SYM53C860, I'm not sure about the specs of
> > the chip now that you write narrow.
>
> This is documented in Documentation/scsi/sym53c8xx_2.txt:
>
>        On board                                   LOAD/STORE   HARDWARE
> Chip   SDMS BIOS   Wide   SCSI std.   Max. sync   SCRIPTS      PHASE
> MISMATCH ----   ---------   ----   ---------   ----------  ----------  
> -------------- [...]
> 860        N         N      FAST20    20 MB/s        Y             N

Having used the 860 in various mainboard designs at work, I confirm this to be 
correct - 20 MT/s (from an 80 MHz clock!), narrow, no ROM interface, no SSID.

Re: SYM8xx_2 driver ignores certain EEPROM settings

[Peter Missel]

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

Re: SYM8xx_2 driver ignores certain EEPROM settings

[Peter Missel]

Help! Help! I'm being ignored!

I just found out that this problem (the driver no longer reading the user's 
adjustments from the SCSI BIOS EEPROM configuration data) not only removes 
the possibility to limit transfer speed and width for single devices or 
entire channels.

It also makes the driver ignore the adapter ordering in multiple-channel 
setups. This machine here has an LSI 21002, where the LVD channel is on 
device function 1 and the UW channel is on 0. Naturally the user will set the 
adapter order in BIOS such that the system HDD (on the LVD channel) 
becomes /dev/sda regardless of other drives on the UW channel. Now, with the 
latest driver releases ignoring this BIOS adjustment, the channels are 
scanned in order of appearance on the PCI bus rather than in the order the 
user wants ... in this case, the LVD channel ends up becoming sym1, which 
means that whenever I connect my external MO drive to the U/UW channel, I get 
a kernel panic because Linux can't find its system volume. 

Not good.

Please talk to me ... thanks!

regards,
Peter

On Saturday 26 February 2005 20:34, Peter Missel wrote:
> 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

Re: SYM8xx_2 driver ignores certain EEPROM settings

[Matthew Wilcox]

On Sat, Apr 09, 2005 at 12:57:22AM +0200, Peter Missel wrote:
> It also makes the driver ignore the adapter ordering in multiple-channel 
> setups. This machine here has an LSI 21002, where the LVD channel is on 
> device function 1 and the UW channel is on 0. Naturally the user will set the 
> adapter order in BIOS such that the system HDD (on the LVD channel) 
> becomes /dev/sda regardless of other drives on the UW channel. Now, with the 
> latest driver releases ignoring this BIOS adjustment, the channels are 
> scanned in order of appearance on the PCI bus rather than in the order the 
> user wants ... in this case, the LVD channel ends up becoming sym1, which 
> means that whenever I connect my external MO drive to the U/UW channel, I get 
> a kernel panic because Linux can't find its system volume. 

This is an inevitable consequence of conversion to the pci_driver model.
So it's a choice: either support this or support hotplug.  I chose to
support hotplug.  This isn't a problem specific to sym2, it's something
that all scsi systems face.  The intended way to solve this is to use
a UUID or label to mount your root fs.  Unfortunately, this means you
have to use an initrd.

Yes, this sucks and isn't nearly as easy to configure as it needs to be.
But there really is no way around it -- I can't control what order the
devices are discovered in.

-- 
"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: SYM8xx_2 driver ignores certain EEPROM settings

[Peter Missel]

Hi Matthew!

I see ... so there is an alternate method for the kernel to find its system 
volume by not using the dynamically built /dev/sdX names? I'll dig into that, 
thanks for the pointer!

Back to the original topic ... do you have any news with regard to putting the 
code back into the sym8xx driver that reads the user configured 
channel/device negotiation settings (transfer speed and width limits, 
timeouts, disconnect, etc. etc.) from the EEPROM? This is really causing 
headaches here with those setups that use external devices, slightly buggy 
devices, long cables and similar stuff where the auto-detected defaults 
aren't working.

Many thanks!

regards,
Peter

On Saturday 09 April 2005 16:02, Matthew Wilcox wrote:
> On Sat, Apr 09, 2005 at 12:57:22AM +0200, Peter Missel wrote:
> > It also makes the driver ignore the adapter ordering in multiple-channel
> > setups. This machine here has an LSI 21002, where the LVD channel is on
> > device function 1 and the UW channel is on 0. Naturally the user will set
> > the adapter order in BIOS such that the system HDD (on the LVD channel)
> > becomes /dev/sda regardless of other drives on the UW channel. Now, with
> > the latest driver releases ignoring this BIOS adjustment, the channels
> > are scanned in order of appearance on the PCI bus rather than in the
> > order the user wants ... in this case, the LVD channel ends up becoming
> > sym1, which means that whenever I connect my external MO drive to the
> > U/UW channel, I get a kernel panic because Linux can't find its system
> > volume.
>
> This is an inevitable consequence of conversion to the pci_driver model.
> So it's a choice: either support this or support hotplug.  I chose to
> support hotplug.  This isn't a problem specific to sym2, it's something
> that all scsi systems face.  The intended way to solve this is to use
> a UUID or label to mount your root fs.  Unfortunately, this means you
> have to use an initrd.
>
> Yes, this sucks and isn't nearly as easy to configure as it needs to be.
> But there really is no way around it -- I can't control what order the
> devices are discovered in.

Re: SYM8xx_2 driver ignores certain EEPROM settings

[Peter Missel]

Hello?

> Back to the original topic ... do you have any news with regard to putting
> the code back into the sym8xx driver that reads the user configured
> channel/device negotiation settings (transfer speed and width limits,
> timeouts, disconnect, etc. etc.) from the EEPROM? This is really causing
> headaches here with those setups that use external devices, slightly buggy
> devices, long cables and similar stuff where the auto-detected defaults
> aren't working.
>
> Many thanks!
>
> regards,
> Peter
>

SYM8xx_2 sync speed negotiation

[Peter Missel]

... is getting worse.

Having just tried kernel 2.6.12-rc3 for unrelated reasons, I have found that 
this cannot run my 2nd SCSI chain AT ALL. The driver is stuck in an endless 
loop of resets:

May  4 23:23:28 Earth kernel: sym0: PCI STATUS = 0x2000
May  4 23:23:28 Earth kernel: sym0: SCSI BUS reset detected.
May  4 23:23:28 Earth kernel: sym0: SCSI BUS has been reset.
May  4 23:23:31 Earth kernel: sym0:1: ERROR (20:0) (0-a3-0) (0/7/0) @ (mem 
f000e810:00000000).
May  4 23:23:31 Earth kernel: sym0: regdump: da 10 c0 07 47 00 01 02 70 00 00 
a3 80 01 0b 00 00 c8 94 1f 08 00
 00 00.
May  4 23:23:31 Earth kernel: sym0: PCI STATUS = 0x2000
May  4 23:23:31 Earth kernel: sym0: SCSI BUS reset detected.
May  4 23:23:31 Earth kernel: sym0: SCSI BUS has been reset.
May  4 23:23:35 Earth kernel: sym0:1: ERROR (20:0) (0-a3-0) (0/7/0) @ (mem 
f000e810:00000000).
May  4 23:23:35 Earth kernel: sym0: regdump: da 10 c0 07 47 00 01 02 70 00 00 
a3 80 01 0b 00 00 30 b8 0e 08 00
 00 00.
May  4 23:23:35 Earth kernel: sym0: PCI STATUS = 0x2000
May  4 23:23:35 Earth kernel: sym0: SCSI BUS reset detected.
May  4 23:23:35 Earth kernel: sym0: SCSI BUS has been reset.
May  4 23:23:38 Earth kernel: sym0:1: ERROR (20:0) (0-a3-0) (0/7/0) @ (mem 
f000e810:00000000).
May  4 23:23:38 Earth kernel: sym0: regdump: da 10 c0 07 47 00 01 02 70 00 00 
a3 80 01 0b 00 00 c0 94 1f 08 00
 00 00.
May  4 23:23:38 Earth kernel: sym0: PCI STATUS = 0x2000
May  4 23:23:38 Earth kernel: sym0: SCSI BUS reset detected.
May  4 23:23:38 Earth kernel: sym0: SCSI BUS has been reset.
May  4 23:23:42 Earth kernel: sym0:1: ERROR (20:0) (0-a3-0) (0/7/0) @ (mem 
f000e810:00000000).
May  4 23:23:42 Earth kernel: sym0: regdump: da 10 c0 07 47 00 01 02 70 00 00 
a3 80 01 0b 00 00 c8 94 1f 08 00
 00 00.

... ad infinitum.

The root cause of course still is that the driver does its sync negotiation 
without considering that the user might have set a speed limit. The driver 
could (and has been) reading this from the configuration parameters from SCSI 
BIOS (in the controller's I2C EEPROM) - before someone decided the feature is 
nothing but clutter and deleted it.

Given the plethora of single-ended SCSI setups with long cables and/or buggy 
drives, I do not share this opinion.

Domain-validate and negotiate as much as you please, but never, ever, set up a 
sync speed higher than the limit set in SCSI BIOS (for the device or the 
entire channel).

best regards,
Peter

On Saturday 09 April 2005 23:44, Peter Missel wrote:
> Hi Matthew!
>
> I see ... so there is an alternate method for the kernel to find its system
> volume by not using the dynamically built /dev/sdX names? I'll dig into
> that, thanks for the pointer!
>
> Back to the original topic ... do you have any news with regard to putting
> the code back into the sym8xx driver that reads the user configured
> channel/device negotiation settings (transfer speed and width limits,
> timeouts, disconnect, etc. etc.) from the EEPROM? This is really causing
> headaches here with those setups that use external devices, slightly buggy
> devices, long cables and similar stuff where the auto-detected defaults
> aren't working.
>
> Many thanks!
>
> regards,
> Peter
>
> On Saturday 09 April 2005 16:02, Matthew Wilcox wrote:
> > On Sat, Apr 09, 2005 at 12:57:22AM +0200, Peter Missel wrote:
> > > It also makes the driver ignore the adapter ordering in
> > > multiple-channel setups. This machine here has an LSI 21002, where the
> > > LVD channel is on device function 1 and the UW channel is on 0.
> > > Naturally the user will set the adapter order in BIOS such that the
> > > system HDD (on the LVD channel) becomes /dev/sda regardless of other
> > > drives on the UW channel. Now, with the latest driver releases ignoring
> > > this BIOS adjustment, the channels are scanned in order of appearance
> > > on the PCI bus rather than in the order the user wants ... in this
> > > case, the LVD channel ends up becoming sym1, which means that whenever
> > > I connect my external MO drive to the U/UW channel, I get a kernel
> > > panic because Linux can't find its system volume.
> >
> > This is an inevitable consequence of conversion to the pci_driver model.
> > So it's a choice: either support this or support hotplug.  I chose to
> > support hotplug.  This isn't a problem specific to sym2, it's something
> > that all scsi systems face.  The intended way to solve this is to use
> > a UUID or label to mount your root fs.  Unfortunately, this means you
> > have to use an initrd.
> >
> > Yes, this sucks and isn't nearly as easy to configure as it needs to be.
> > But there really is no way around it -- I can't control what order the
> > devices are discovered in.

Re: SYM8xx_2 sync speed negotiation

[Peter Missel]

Greetings!

Following up on this: With released 2.6.12 kernel, the problem remains.

I'd like to emphasize again that this particular SCSI chain has been working 
perfectly with sym8xx drivers before 2.1.18. The culprit is the later 
drivers' inability to honor the sync period negotiation limits set in the 
adapter's NVRAM. (sym0:1 is the only Ultra capable device on a chain that 
can't run Ultra due to cable length. NVRAM is set to limit the entire chain 
to 10 MB/s).

2.1.18 forced me to disconnect the external branch because this driver would 
run this device in Ultra mode despite NVRAM forbidding it. Now, with 2.2.0, 
even with just the internal chain, this channel has become entirely 
inoperable, as shown below.

I understand how the reading of sync/wide negotiation limits disappeared from 
the low level driver with the introduction of the "transport" layer - but now 
that a mechanism for doing exactly that has been implemented into the 
latter ...

http://marc.theaimsgroup.com/?l=linux-scsi&m=111540278825762&w=2

... wouldn't it be time to finally bring this important feature back into the 
sym8xx driver's interaction with the transport layer?

I'll close with a self-quote:

> Domain-validate and negotiate as much as you please, but never, ever, set
> up a sync speed higher than the limit set in SCSI BIOS (for the device or
> the entire channel).

best regards,
Peter Missel

On Wednesday 04 May 2005 23:47, Peter Missel wrote:
> ... is getting worse.
>
> Having just tried kernel 2.6.12-rc3 for unrelated reasons, I have found
> that this cannot run my 2nd SCSI chain AT ALL. The driver is stuck in an
> endless loop of resets:
>
> May  4 23:23:28 Earth kernel: sym0: PCI STATUS = 0x2000
> May  4 23:23:28 Earth kernel: sym0: SCSI BUS reset detected.
> May  4 23:23:28 Earth kernel: sym0: SCSI BUS has been reset.
> May  4 23:23:31 Earth kernel: sym0:1: ERROR (20:0) (0-a3-0) (0/7/0) @ (mem
> f000e810:00000000).
> May  4 23:23:31 Earth kernel: sym0: regdump: da 10 c0 07 47 00 01 02 70 00
> 00 a3 80 01 0b 00 00 c8 94 1f 08 00
>  00 00.
> May  4 23:23:31 Earth kernel: sym0: PCI STATUS = 0x2000
> May  4 23:23:31 Earth kernel: sym0: SCSI BUS reset detected.
> May  4 23:23:31 Earth kernel: sym0: SCSI BUS has been reset.
> May  4 23:23:35 Earth kernel: sym0:1: ERROR (20:0) (0-a3-0) (0/7/0) @ (mem
> f000e810:00000000).
> May  4 23:23:35 Earth kernel: sym0: regdump: da 10 c0 07 47 00 01 02 70 00
> 00 a3 80 01 0b 00 00 30 b8 0e 08 00
>  00 00.
> May  4 23:23:35 Earth kernel: sym0: PCI STATUS = 0x2000
> May  4 23:23:35 Earth kernel: sym0: SCSI BUS reset detected.
> May  4 23:23:35 Earth kernel: sym0: SCSI BUS has been reset.
> May  4 23:23:38 Earth kernel: sym0:1: ERROR (20:0) (0-a3-0) (0/7/0) @ (mem
> f000e810:00000000).
> May  4 23:23:38 Earth kernel: sym0: regdump: da 10 c0 07 47 00 01 02 70 00
> 00 a3 80 01 0b 00 00 c0 94 1f 08 00
>  00 00.
> May  4 23:23:38 Earth kernel: sym0: PCI STATUS = 0x2000
> May  4 23:23:38 Earth kernel: sym0: SCSI BUS reset detected.
> May  4 23:23:38 Earth kernel: sym0: SCSI BUS has been reset.
> May  4 23:23:42 Earth kernel: sym0:1: ERROR (20:0) (0-a3-0) (0/7/0) @ (mem
> f000e810:00000000).
> May  4 23:23:42 Earth kernel: sym0: regdump: da 10 c0 07 47 00 01 02 70 00
> 00 a3 80 01 0b 00 00 c8 94 1f 08 00
>  00 00.
>

endless loop problem with SYM8xx_2: unexpected disconnect

[Christian Werner]

Hi,

recently we've tried to use our DawiControl DC-29160 (LSI 53C1010) with 
kernel 2.6.11, but loading the SYM8xx_2 driver ended up in an endless 
loop. With kernel 2.6.4 everything is working fine and with 2.6.8 the 
error is the same. So obviously something's got broken between 2.6.4 and 
2.6.8.

We didn't do any tests with kernel 2.6.12 yet, because this machine is 
in productive use and we have to think twice before booting a new 
kernel. When the error occured we unfortunately had no verbose SCSI 
error reporting enabled. We also didn't do any more tests, because we 
had to get this machine working again fast. Hopefully our error report 
is helpful anyway.

With Kernel 2.6.4. everything is ok:

Jun  4 16:36:29 itm01 kernel: sym0: <1010-66> rev 0x1 at pci 
0000:00:06.0 irq 10
Jun  4 16:36:29 itm01 kernel: sym0: using 64 bit DMA addressing
Jun  4 16:36:29 itm01 kernel: sym0: No NVRAM, ID 7, Fast-80, LVD, parity 
checking
Jun  4 16:36:29 itm01 kernel: sym0: SCSI BUS has been reset.
Jun  4 16:36:29 itm01 kernel: scsi1 : sym-2.1.18f
Jun  4 16:36:29 itm01 kernel:   Vendor: transtec  Model:  
T5008R           Rev: 0001
Jun  4 16:36:29 itm01 kernel:   Type:   
Direct-Access                      ANSI SCSI revision: 03
Jun  4 16:36:29 itm01 kernel: sym0:0:0: tagged command queuing enabled, 
command queue depth 16.
Jun  4 16:36:29 itm01 kernel: sym0:0: FAST-80 WIDE SCSI 160.0 MB/s DT 
(12.5 ns, offset 31)
Jun  4 16:36:29 itm01 kernel: SCSI device sda: 3431579648 512-byte hdwr 
sectors (1756969 MB)
Jun  4 16:36:29 itm01 kernel: SCSI device sda: drive cache: write back
Jun  4 16:36:29 itm01 kernel:  sda: sda1
Jun  4 16:36:29 itm01 kernel: Attached scsi disk sda at scsi1, channel 
0, id 0, lun 0

*******************************************************************

Same hardware configuration but with kernel 2.6.11:

Jun  4 15:59:01 itm01 kernel: sym0: <1010-66> rev 0x1 at pci 
0000:00:06.0 irq 10
Jun  4 15:59:01 itm01 kernel: sym0: using 64 bit DMA addressing
Jun  4 15:59:01 itm01 kernel: sym0: No NVRAM, ID 7, Fast-80, LVD, parity 
checking
Jun  4 15:59:01 itm01 kernel: sym0: SCSI BUS has been reset.
Jun  4 15:59:01 itm01 kernel: scsi3 : sym-2.1.18j
Jun  4 15:59:01 itm01 kernel:   Vendor: transtec  Model:  
T5008R           Rev: 0001
Jun  4 15:59:01 itm01 kernel:   Type:   
Direct-Access                      ANSI SCSI revision: 03
Jun  4 15:59:01 itm01 kernel: sym0:0:0: tagged command queuing enabled, 
command queue depth 16.
Jun  4 15:59:01 itm01 kernel: scsi(3:0:0:0): Beginning Domain Validation
Jun  4 15:59:01 itm01 kernel: sym0: unexpected disconnect
Jun  4 15:59:01 itm01 kernel: scsi(3:0:0:0): Ending Domain Validation
Jun  4 15:59:01 itm01 kernel: sdb: Unit Not Ready, error = 0x100ff
Jun  4 15:59:01 itm01 kernel: sdb : READ CAPACITY failed.
Jun  4 15:59:01 itm01 kernel: sdb : status=1f, message=00, host=1, driver=00
Jun  4 15:59:01 itm01 kernel: sdb : sense not available.
Jun  4 15:59:01 itm01 kernel:  /dev/scsi/host3/bus0/target0/lun0:SCSI 
error : <3 0 0 0> return code = 0x100ff
Jun  4 15:59:01 itm01 kernel: end_request: I/O error, dev sdb, sector 0
Jun  4 15:59:01 itm01 kernel: SCSI error : <3 0 0 0> return code = 0x100ff
Jun  4 15:59:01 itm01 kernel: end_request: I/O error, dev sdb, sector 0
Jun  4 15:59:01 itm01 kernel:  unable to read partition table
Jun  4 15:59:01 itm01 kernel: Attached scsi disk sdb at scsi3, channel 
0, id 0, lun 0
Jun  4 15:59:01 itm01 kernel: sym0: unexpected disconnect
Jun  4 15:59:01 itm01 kernel: sym0: unexpected disconnect
Jun  4 16:00:05 itm01 kernel: sym0: unexpected disconnect
Jun  4 16:00:06 itm01 kernel: SCSI error : <3 0 0 0> return code = 0x100ff
Jun  4 16:00:06 itm01 kernel: end_request: I/O error, dev sdb, sector 0
Jun  4 16:00:06 itm01 kernel: SCSI error : <3 0 0 0> return code = 0x100ff
Jun  4 16:00:06 itm01 kernel: end_request: I/O error, dev sdb, sector 8
Jun  4 16:00:06 itm01 kernel: sym0: unexpected disconnect
Jun  4 16:00:07 itm01 kernel: SCSI error : <3 0 0 0> return code = 0x100ff
Jun  4 16:00:07 itm01 kernel: end_request: I/O error, dev sdb, sector 16
Jun  4 16:00:07 itm01 kernel: SCSI error : <3 0 0 0> return code = 0x100ff
Jun  4 16:00:07 itm01 kernel: end_request: I/O error, dev sdb, sector 24
Jun  4 16:00:07 itm01 kernel: sym0: unexpected disconnect
Jun  4 16:00:07 itm01 kernel: SCSI error : <3 0 0 0> return code = 0x100ff
Jun  4 16:00:07 itm01 kernel: end_request: I/O error, dev sdb, sector 32
Jun  4 16:00:08 itm01 kernel: SCSI error : <3 0 0 0> return code = 0x100ff
Jun  4 16:00:08 itm01 kernel: end_request: I/O error, dev sdb, sector 40
Jun  4 16:00:08 itm01 kernel: sym0: unexpected disconnect
Jun  4 16:00:08 itm01 kernel: SCSI error : <3 0 0 0> return code = 0x100ff
Jun  4 16:00:08 itm01 kernel: end_request: I/O error, dev sdb, sector 48
Jun  4 16:00:09 itm01 kernel: SCSI error : <3 0 0 0> return code = 0x100ff
Jun  4 16:00:09 itm01 kernel: end_request: I/O error, dev sdb, sector 56
[continuing in endless loop ...]

*******************************************************************

Some details about our hardware configuration:
- The max. SCSI speed is set to 160MB/sec in the adapter's NVRAM. Cable 
length is about 3 meters.
- There is only one device attached to the bus. It is an 
ATA-to-SCSI-RAID with 1.6 TBytes capacity.
- The adapter is a 64-Bit PCI card (mounted in a 32-Bit PCI slot).

Is this particular problem already known (We couldn't find any matching 
bug report)?

Thanks for your help!

Dariush and Christian