| Message ID | alpine.DEB.2.21.2104141244520.44318@angie.orcam.me.uk (mailing list archive) |
|---|---|
| Headers | show |
| Series | Bring the BusLogic host bus adapter driver up to Y2021 | expand |
On 4/14/21 4:38 PM, Maciej W. Rozycki wrote: > Hi, > > First of all, does anyone have a copy of: "MultiMaster UltraSCSI Host > Adapters for PCI Systems: Technical Reference Manual" (pub. 3002493-E)? > It used to live in the "Mylex Manuals and Documentation Archives" section > of the Mylex web site <http://www.mylex.com/pub/manuals/index.htm>, > specifically at: <http://www.mylex.com/pub/manuals/mmultra.pdf>. > > Another useful document might be: "Wide SCSI Host Adapters for PCI and > EISA Systems: Technical Reference Manual" (pub. 3000763-A), which used to > live at: <http://www.mylex.com/pub/manuals/widescsi.pdf>, linked from the > same place. > > Sadly I didn't get to these resources while they were still there, and > neither did archive.org, and now they not appear available from anywhere > online. I'm sure Leonard had this all, but, alas, he is long gone too. These documents were all gone by the time I started working on this driver in 2013. -- Khalid
On Fri, 16 Apr 2021, Khalid Aziz wrote: > > Sadly I didn't get to these resources while they were still there, and > > neither did archive.org, and now they not appear available from anywhere > > online. I'm sure Leonard had this all, but, alas, he is long gone too. > > These documents were all gone by the time I started working on this > driver in 2013. According to my e-mail archives I got my BT-958 directly from Mylex brand new as KT-958 back in early 1998 (the rest of the system is a bit older). It wasn't up until 2003 when I was caught by the issue with the LOG SENSE command that I got interested in the programming details of the adapter. At that time Mylex was in flux already, having been bought by LSI shortly before. Support advised me what was there at Leonard's www.dandelion.com site was all that was available (I have a personal copy of the site) and they would suggest to switch to their current products. So it was too late already ten years before you got at the driver. I'll yet double-check the contents of the KT-958 kit which I have kept, but if there was any technical documentation supplied there on a CD (which I doubt), I would have surely discovered it earlier. It's away along with the server, remotely managed, ~160km/100mi from here, so it'll be some time before I get at it though. Still, maybe one of the SCSI old-timers has that stuff stashed somewhere. I have plenty of technical documentation going back to early to mid 1990s (some in the hard copy form), not necessarily readily available nowadays. Sadly lots of such stuff goes offline or is completely lost to the mist of time. Maciej
On Friday 16 April 2021 23:25:18 Maciej W. Rozycki wrote: > On Fri, 16 Apr 2021, Khalid Aziz wrote: > > > > Sadly I didn't get to these resources while they were still there, and > > > neither did archive.org, and now they not appear available from anywhere > > > online. I'm sure Leonard had this all, but, alas, he is long gone too. > > > > These documents were all gone by the time I started working on this > > driver in 2013. > > According to my e-mail archives I got my BT-958 directly from Mylex brand > new as KT-958 back in early 1998 (the rest of the system is a bit older). > It wasn't up until 2003 when I was caught by the issue with the LOG SENSE > command that I got interested in the programming details of the adapter. > > At that time Mylex was in flux already, having been bought by LSI shortly > before. Support advised me what was there at Leonard's www.dandelion.com > site was all that was available (I have a personal copy of the site) and > they would suggest to switch to their current products. So it was too > late already ten years before you got at the driver. > > I'll yet double-check the contents of the KT-958 kit which I have kept, > but if there was any technical documentation supplied there on a CD (which > I doubt), I would have surely discovered it earlier. It's away along with > the server, remotely managed, ~160km/100mi from here, so it'll be some > time before I get at it though. > > Still, maybe one of the SCSI old-timers has that stuff stashed somewhere. > I have plenty of technical documentation going back to early to mid 1990s > (some in the hard copy form), not necessarily readily available nowadays. > Sadly lots of such stuff goes offline or is completely lost to the mist of > time. > > Maciej > Found the 3000763 document here: https://doc.lagout.org/science/0_Computer Science/0_Computer History/old-hardware/buslogic/3000763_PCI_EISA_Wide_SCSI_Tech_Ref_Dec94.pdf There's also 3002593 there: https://doc.lagout.org/science/0_Computer Science/0_Computer History/old-hardware/buslogic/
On 4/18/21 2:21 PM, Ondrej Zary wrote: > On Friday 16 April 2021 23:25:18 Maciej W. Rozycki wrote: >> On Fri, 16 Apr 2021, Khalid Aziz wrote: >> >>>> Sadly I didn't get to these resources while they were still there, and >>>> neither did archive.org, and now they not appear available from anywhere >>>> online. I'm sure Leonard had this all, but, alas, he is long gone too. >>> >>> These documents were all gone by the time I started working on this >>> driver in 2013. >> >> According to my e-mail archives I got my BT-958 directly from Mylex brand >> new as KT-958 back in early 1998 (the rest of the system is a bit older). >> It wasn't up until 2003 when I was caught by the issue with the LOG SENSE >> command that I got interested in the programming details of the adapter. >> >> At that time Mylex was in flux already, having been bought by LSI shortly >> before. Support advised me what was there at Leonard's www.dandelion.com >> site was all that was available (I have a personal copy of the site) and >> they would suggest to switch to their current products. So it was too >> late already ten years before you got at the driver. >> >> I'll yet double-check the contents of the KT-958 kit which I have kept, >> but if there was any technical documentation supplied there on a CD (which >> I doubt), I would have surely discovered it earlier. It's away along with >> the server, remotely managed, ~160km/100mi from here, so it'll be some >> time before I get at it though. >> >> Still, maybe one of the SCSI old-timers has that stuff stashed somewhere. >> I have plenty of technical documentation going back to early to mid 1990s >> (some in the hard copy form), not necessarily readily available nowadays. >> Sadly lots of such stuff goes offline or is completely lost to the mist of >> time. >> >> Maciej >> > > Found the 3000763 document here: > https://doc.lagout.org/science/0_Computer Science/0_Computer History/old-hardware/buslogic/3000763_PCI_EISA_Wide_SCSI_Tech_Ref_Dec94.pdf > > There's also 3002593 there: > https://doc.lagout.org/science/0_Computer Science/0_Computer History/old-hardware/buslogic/ > Thanks!!! -- Khalid
On Mon, 19 Apr 2021, Khalid Aziz wrote: > On 4/18/21 2:21 PM, Ondrej Zary wrote: > > > > Found the 3000763 document here: > > https://doc.lagout.org/science/0_Computer Science/0_Computer History/old-hardware/buslogic/3000763_PCI_EISA_Wide_SCSI_Tech_Ref_Dec94.pdf > > > > There's also 3002593 there: > > https://doc.lagout.org/science/0_Computer Science/0_Computer History/old-hardware/buslogic/ > > > > Thanks!!! Ondrej: Thanks a lot indeed! These documents seem to have the essential interface details all covered, except for Fast-20 SCSI adapters, which I guess are a minor modification from the software's point of view. Khalid: I have skimmed over these documents and I infer 24-bit addressing can be verified with any MultiMaster adapter, including ones that do have 32-bit addressing implemented, by using the legacy Initialize Mailbox HBA command. That could be used to stop Christoph's recent changes for older adapter support removal and replace them with proper fixes for whatever has become broken. Is that something you'd be willing as the driver's maintainer to look into, or shall I? Maciej
On 4/19/21 10:01 AM, Maciej W. Rozycki wrote: > On Mon, 19 Apr 2021, Khalid Aziz wrote: > >> On 4/18/21 2:21 PM, Ondrej Zary wrote: >>> >>> Found the 3000763 document here: >>> https://doc.lagout.org/science/0_Computer Science/0_Computer History/old-hardware/buslogic/3000763_PCI_EISA_Wide_SCSI_Tech_Ref_Dec94.pdf >>> >>> There's also 3002593 there: >>> https://doc.lagout.org/science/0_Computer Science/0_Computer History/old-hardware/buslogic/ >>> >> >> Thanks!!! > > Ondrej: Thanks a lot indeed! These documents seem to have the essential > interface details all covered, except for Fast-20 SCSI adapters, which I > guess are a minor modification from the software's point of view. > > Khalid: I have skimmed over these documents and I infer 24-bit addressing > can be verified with any MultiMaster adapter, including ones that do have > 32-bit addressing implemented, by using the legacy Initialize Mailbox HBA > command. That could be used to stop Christoph's recent changes for older > adapter support removal and replace them with proper fixes for whatever > has become broken. Is that something you'd be willing as the driver's > maintainer to look into, or shall I? > Hi Maciej, Do you mean use OpCode 01 (INITIALIZE MAILBOX) to set a 24-bit address for mailbox in place of OpCode 81? Verifying the change would be a challenge. Do you have an old adapter to test it with? If you do, go ahead and make the changes. I will be happy to review. I have only a BT-757 adapter. Thanks, Khalid
On Mon, 19 Apr 2021, Khalid Aziz wrote: > > Khalid: I have skimmed over these documents and I infer 24-bit addressing > > can be verified with any MultiMaster adapter, including ones that do have > > 32-bit addressing implemented, by using the legacy Initialize Mailbox HBA > > command. That could be used to stop Christoph's recent changes for older > > adapter support removal and replace them with proper fixes for whatever > > has become broken. Is that something you'd be willing as the driver's > > maintainer to look into, or shall I? > > Do you mean use OpCode 01 (INITIALIZE MAILBOX) to set a 24-bit address > for mailbox in place of OpCode 81? Verifying the change would be a > challenge. Do you have an old adapter to test it with? If you do, go > ahead and make the changes. I will be happy to review. I have only a > BT-757 adapter. Yes, but upon inspection it looks like our driver doesn't use that opcode and relies solely on 32-bit Mode Initialize Mailbox (0x81) even with ISA devices. That makes sense as documentation indicates the firmware has been designed to be unified so that the same binary microcontroller code runs across all BusLogic MultiMaster devices. Anyway given the unified API it should be straightforward to simulate an older adapter with a newer one, except for host bus protocol differences. So verifying the workaround for broken BT-445S adapters continues to work once modernised is not going to be a problem as it can be unconditionally activated in a debug environment. That would verify correct DMA bounce buffer operation under the new scheme. Verifying actual ISA operations (third-party DMA, etc.) cannot be made this way, but as I understand the issue there is merely with passing data structures around and that may not require too much attention beyond getting things syntactically correct, which I gather someone forgot to do with a change made a while ago. So that should be doable as well. NB as noted before I only have a BT-958 readily wired for operation. I don't expect I have any other BusLogic hardware, but I may yet have to double-check a stash of hardware I have accumulated over the years. But that is overseas, so I won't be able to get at it before we're at least somewhat closer to normality. If all else fails I could possibly buy one. I have respun the series now as promised. Does your BT-757 adapter avoid the issue with trailing allocation somehow? Maciej
On 4/20/21 12:02 PM, Maciej W. Rozycki wrote: > On Mon, 19 Apr 2021, Khalid Aziz wrote: > >>> Khalid: I have skimmed over these documents and I infer 24-bit addressing >>> can be verified with any MultiMaster adapter, including ones that do have >>> 32-bit addressing implemented, by using the legacy Initialize Mailbox HBA >>> command. That could be used to stop Christoph's recent changes for older >>> adapter support removal and replace them with proper fixes for whatever >>> has become broken. Is that something you'd be willing as the driver's >>> maintainer to look into, or shall I? >> >> Do you mean use OpCode 01 (INITIALIZE MAILBOX) to set a 24-bit address >> for mailbox in place of OpCode 81? Verifying the change would be a >> challenge. Do you have an old adapter to test it with? If you do, go >> ahead and make the changes. I will be happy to review. I have only a >> BT-757 adapter. > > Yes, but upon inspection it looks like our driver doesn't use that opcode > and relies solely on 32-bit Mode Initialize Mailbox (0x81) even with ISA > devices. That makes sense as documentation indicates the firmware has > been designed to be unified so that the same binary microcontroller code > runs across all BusLogic MultiMaster devices. > > Anyway given the unified API it should be straightforward to simulate an > older adapter with a newer one, except for host bus protocol differences. > So verifying the workaround for broken BT-445S adapters continues to work > once modernised is not going to be a problem as it can be unconditionally > activated in a debug environment. That would verify correct DMA bounce > buffer operation under the new scheme. > > Verifying actual ISA operations (third-party DMA, etc.) cannot be made > this way, but as I understand the issue there is merely with passing data > structures around and that may not require too much attention beyond > getting things syntactically correct, which I gather someone forgot to do > with a change made a while ago. So that should be doable as well. In theory this sounds reasonable, but without being able to test with a real hardware I would be concerned about making this change. > > NB as noted before I only have a BT-958 readily wired for operation. I > don't expect I have any other BusLogic hardware, but I may yet have to > double-check a stash of hardware I have accumulated over the years. But > that is overseas, so I won't be able to get at it before we're at least > somewhat closer to normality. If all else fails I could possibly buy one. > > I have respun the series now as promised. Does your BT-757 adapter avoid > the issue with trailing allocation somehow? > Well, my only test machine with a legacy PCI slot died some time back. I have been working on putting together a replacement and have now been able to get a working machine with a BT-950 adapter. I have not seen issue with trailing allocation upto 5.12-rc8. I am going to try the top of tree as well to make sure I do not run into this issue. -- Khalid
On Wed, 21 Apr 2021, Khalid Aziz wrote: > > Verifying actual ISA operations (third-party DMA, etc.) cannot be made > > this way, but as I understand the issue there is merely with passing data > > structures around and that may not require too much attention beyond > > getting things syntactically correct, which I gather someone forgot to do > > with a change made a while ago. So that should be doable as well. > > In theory this sounds reasonable, but without being able to test with a > real hardware I would be concerned about making this change. Sometimes you have little choice really and that would be less disruptive than dropping support altogether. Even if there's a small issue somewhere it's easier to fix by a competent developer who actually gets the hands on a piece of hardware than bringing back old code that has been removed and consequently not updated according to internal API evolution, etc. I had this issue with the defxx driver with which for years I didn't have a specimen of the EISA variant of the hardware handled. I did my best to maintain EISA support however and while indeed I made a few of mistakes on the way, they were easy to straighten out once I finally did get my hands on an EISA piece. > > NB as noted before I only have a BT-958 readily wired for operation. I > > don't expect I have any other BusLogic hardware, but I may yet have to > > double-check a stash of hardware I have accumulated over the years. But > > that is overseas, so I won't be able to get at it before we're at least > > somewhat closer to normality. If all else fails I could possibly buy one. > > > > I have respun the series now as promised. Does your BT-757 adapter avoid > > the issue with trailing allocation somehow? > > Well, my only test machine with a legacy PCI slot died some time back. I > have been working on putting together a replacement and have now been > able to get a working machine with a BT-950 adapter. I have not seen > issue with trailing allocation upto 5.12-rc8. I am going to try the top > of tree as well to make sure I do not run into this issue. I guess you won't see the issue with a FlashPoint adapter as they work in a different manner. I think your EISA MultiMaster device is more likely to have a problem here. And AFAICT most SCSI commands (or at least the older ones which used to be there when development was still active with the MultiMaster devices) return exactly as much data as requested, so I guess the issue may have gone unnoticed. I'll see if I can find some time to investigate this further now that we have proper documentation available, but meanwhile I do hope the workaround I have come up with 18 years ago already is good enough to keep it. Maciej
On 4/22/21 10:27 AM, Maciej W. Rozycki wrote: > On Wed, 21 Apr 2021, Khalid Aziz wrote: > >>> Verifying actual ISA operations (third-party DMA, etc.) cannot be made >>> this way, but as I understand the issue there is merely with passing data >>> structures around and that may not require too much attention beyond >>> getting things syntactically correct, which I gather someone forgot to do >>> with a change made a while ago. So that should be doable as well. >> >> In theory this sounds reasonable, but without being able to test with a >> real hardware I would be concerned about making this change. > > Sometimes you have little choice really and that would be less disruptive > than dropping support altogether. Even if there's a small issue somewhere > it's easier to fix by a competent developer who actually gets the hands on > a piece of hardware than bringing back old code that has been removed and > consequently not updated according to internal API evolution, etc. We are talking about removing support for BT-445S with firmware version older than 3.37. That is a very specific case. To continue support for this very specific case, we have to add new code to use local bounce buffer and we have no hardware to verify this new code. This will be new code whether we add it now or later after we find someone even has this very old card with old firmware. I would prefer to remove support for now and add new code to add support for firmware version older than 3.37 back only if there is a need later. For now anyone who is using a BT-445S and has updated firmware on their card will not see a change. -- Khalid
On Thu, 22 Apr 2021, Khalid Aziz wrote: > >>> Verifying actual ISA operations (third-party DMA, etc.) cannot be made > >>> this way, but as I understand the issue there is merely with passing data > >>> structures around and that may not require too much attention beyond > >>> getting things syntactically correct, which I gather someone forgot to do > >>> with a change made a while ago. So that should be doable as well. > >> > >> In theory this sounds reasonable, but without being able to test with a > >> real hardware I would be concerned about making this change. > > > > Sometimes you have little choice really and that would be less disruptive > > than dropping support altogether. Even if there's a small issue somewhere > > it's easier to fix by a competent developer who actually gets the hands on > > a piece of hardware than bringing back old code that has been removed and > > consequently not updated according to internal API evolution, etc. > > We are talking about removing support for BT-445S with firmware version > older than 3.37. Umm, no. As still quoted above I referred to ISA devices, such as the BT-545C. ISA only has 24 address lines so no firmware change can make these devices address memory beyond 16MiB (whether as a bus master or with the aid of an 8237 DMA controller). > That is a very specific case. To continue support for > this very specific case, we have to add new code to use local bounce > buffer and we have no hardware to verify this new code. This will be new > code whether we add it now or later after we find someone even has this > very old card with old firmware. I would prefer to remove support for > now and add new code to add support for firmware version older than 3.37 > back only if there is a need later. For now anyone who is using a > BT-445S and has updated firmware on their card will not see a change. As long as ISA support has been retained the BT-445S can just reuse the logic. I'm not strongly attached to ISA support though, and we continue supporting other SCSI HBAs for ISA. But we do that even though they require a dedicated driver while with the unified MultiMaster architecture it would seem support for another host bus should be low-hanging fruit. Maciej