search

erichelgeson / BlueSCSI

A small SCSI device based on stm32
Other
389 stars 61 forks source link

LUN greater than 0 ignored #214

Closed netmgr closed 1 year ago

netmgr commented 1 year ago

LUN greater than 0 causes the file to be ignored as though it wasn't there HD11 - test.hda - this is ignored, led flashes 3 times HD10 - test.hda - this works fine

VER: 1.1-20221203-USB

Am I misunderstanding the naming convention or is there a bug?

netmgr commented 1 year ago

Having re-read the statement 'y - LUN ID - Optional but always 0.' I assumed that meant it would default to 0 if omitted, however I now suspect that you just cant have anything other than 0. If this is the case why is it there?

erichelgeson commented 1 year ago

What machine are you? Computer such as Macintosh's do not support LUN's. I actually dont own any machines that do so it's not well tested. We do support them in a special case for the Mega STE.

netmgr commented 1 year ago

Hi Eric This is for the RM Nimbus 80186 - the BlueSCSI works to an extent. The hard drives are arranged with 2 drives per controller so I can only access the primary drive using the SCSI ID/LUN 0. If I want to gain the full compliment then 2 of the drives need to be set to SCSI ID/LUN 1 Looking at the Mega ST mode then that changes the LUN ID but leaves the SCSI ID at 0. The ability looks to be there but would need some re-jigging at the code. I could perhaps have a go, unless you think this is a quick fix yourself?

erichelgeson commented 1 year ago

Please take a look and feel free to open a PR! I don't have any way to test LUN's so will have to rely on you and @mynameistroy (he's done some with LUN's lately)

mynameistroy commented 1 year ago

So the BlueSCSI has such a limited amount of RAM and as a result the LUNs are generally disabled in order to save on that. At some point when some slimming can be done the adding them back could be a thing. Otherwise modifying the MegaSTE mode or simply enabling access to LUN1 as well isn't too hard.

However doing a little digging shows that it doesn't use LUNs but IDs for each device at least based on what I'm reading here https://www.thenimbus.co.uk/upgrades-and-maintenance/scsi2sd

netmgr commented 1 year ago

I've just gone with upping the number of enabled LUNs in the code and recompiled: #define NUM_SCSILUN 2 // Number of enabled LUNs

That works perfectly. Was it dropped to a single LUN for memory reasons? Any problems I might expect with this arrangement?

I'm running the following setup, as you can see two of them are on LUN address 1:

@mynameistroy The link you have given indicates an issue with addressing the 2nd drive, its now clear that this is due to the need to address LUN 1 - I don't think SCSI2SD (as used in the example) has this flexibility whilst retaining control of the SCSI ID like bluescsi does (once enabled in the code). _Link quote: Unfortunately the way in which the device adds drives, it does so on a 'per controller, 1st drive' basis The Nimbus has it hard coded that the 2nd external drive must be on the 2nd drive of Controller 1. This renders the 2nd external drive (E:) unusable, you do however get C: D: & F:__

mynameistroy commented 1 year ago

Indeed it was lowered for memory reasons and just general lack of need. Rare cases such as this one aren't very common so saving the memory at the time considered the way to go.

It uses about 2% more RAM and average RAM usage depending on platform is around 64% so still lots of room really even if debugging is enabled.

I don't expect you'll have any issues and it's very likely LUNs will come back at some point by default.

netmgr commented 1 year ago

Thanks getting this resolved