All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Khalid Aziz <khalid@gonehiking.org>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Christoph Hellwig <hch@lst.de>, Nix <nix@esperi.org.uk>,
	linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/3] Bring the BusLogic host bus adapter driver up to Y2021
Date: Sun, 2 Jan 2022 23:23:36 +0000 (GMT)	[thread overview]
Message-ID: <alpine.DEB.2.21.2201020010540.56863@angie.orcam.me.uk> (raw)

Hi,

 Or was it Y2022?

 Anyway, here's v3 of the series, with original patches 1/5 and 2/5 
removed as they have since gone in (thanks!).  No code or description 
change with the remaining patches, just a mechanical regeneration, except 
for Nick's Tested-by annotation for 3/3 (thanks!).  Parts of the original 
cover letter follow that are still relevant, for reference.

 So we are here owing to Christoph's recent ISA bounce buffering sweep: 
<https://lore.kernel.org/linux-scsi/20210331073001.46776-1-hch@lst.de/T/#m981284e74e93216626a0728ce1601ca18fca92e8> 
which has prompted me to verify the current version of Linux with my old 
server, which has been long equipped with venerable Linux 2.6.18 and which 
I now have available for general experimenting, and the BusLogic BT-958 
PCI SCSI host bus adapter the server has used for 20-something years now. 
This revealed an issue with the BusLogic driver.

 It has become obvious the BusLogic driver would have been non-functional, 
should I have upgraded the kernel, at least with this configuration for 
some 8 years now, and the underlying cause has been a long-known issue 
with the MultiMaster firmware I have dealt with already, back in 2003.  
To put it short the firmware cannot cope with commands that request an 
allocation length exceeding the length of actual data returned.

 I have originally observed it with a LOG SENSE command in the course of 
investigating why smartmontools bring the system to a death, and worked it 
around: <https://sourceforge.net/p/smartmontools/mailman/message/4993087/> 
by issuing the command twice, first just to obtain the allocation length 
required.  As it turns out we need a similar workaround in the kernel now.

 But in the course of investigating this issue I have discovered there is 
a second bottom to it and hence I have prepared follow-up changes to 
address problems with our handling of Vital Product Data INQUIRY pages.

 See individual change descriptions for further details.

 Any questions, comments, concerns still?  Otherwise please apply.

  Maciej

             reply	other threads:[~2022-01-02 23:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-02 23:23 Maciej W. Rozycki [this message]
2022-01-02 23:23 ` [PATCH v3 1/3] scsi: Provide for avoiding trailing allocation length with VPD inquiries Maciej W. Rozycki
2022-01-03  8:23   ` Christoph Hellwig
2022-01-04 16:39     ` Khalid Aziz and Shuah Khan
2022-01-04 17:20     ` Maciej W. Rozycki
2022-01-02 23:23 ` [PATCH v3 2/3] scsi: Avoid using reserved length byte " Maciej W. Rozycki
2022-01-02 23:23 ` [PATCH v3 3/3] scsi: Set allocation length to 255 for ATA Information VPD page Maciej W. Rozycki
2022-01-03  4:09   ` Douglas Gilbert
2022-01-03 21:06     ` Maciej W. Rozycki
2022-01-03 21:28       ` Martin K. Petersen
2022-01-04 13:52         ` Maciej W. Rozycki
2022-01-04 17:57           ` Martin K. Petersen
2022-01-06  4:13             ` Martin K. Petersen
2022-01-06  5:21               ` Damien Le Moal
2022-01-07 14:07                 ` Martin K. Petersen
2022-01-07 10:36               ` Maciej W. Rozycki
2022-01-07 14:03                 ` Martin K. Petersen
2022-01-10 12:00                   ` Maciej W. Rozycki
2022-01-10 15:48                     ` Martin K. Petersen
2022-01-03 21:37     ` Martin K. Petersen

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=alpine.DEB.2.21.2201020010540.56863@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=hch@lst.de \
    --cc=jejb@linux.ibm.com \
    --cc=khalid@gonehiking.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=nix@esperi.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.