USB SCSI limited to 7 devices?

I encountered this during testing of (many) CD/DVD/BD writers. It looks like only seven mass storage devices at the same time are currently supported. Is there any specific reason why IDs up to 31 are not used? After all, even the old RPC could do that with the help of 4 Power-tec cards. Not sure if any software other than CDVDBurn scans SCSI IDs beyond 7 (and yes, this was added on demand of a customer who had 4 Power-tec cards!), but anyway…

Up to 7 devices (8, including the controller) was pretty much standard with SCSI 1 and 2. With many controllers it was possible to connect up to 16 (15) devices, mostly 7 intern and 7 extern, depending to the operating system. So it is not surprising that an USB to SCSI converter, which was made to use some old devices which cannot be replaced by 21st century technology, only supports 7 devices.
It is unlikely that many people ever need more than 7 SCSI-devices at an USB-converter. If you have more modern UW-SCSI or SCSI 3 harddisks, you would not like to speed them down with USB.
Look here: http://en.wikipedia.org/wiki/SCSI

Hi Volker, I am not talking about an USB-SCSI-Adapter, I am talking about the RISC OS SCSI stack (SCSIdriver, SCSIFS and SCSISoftUSB) – in RISC OS, all USB mass storage devices are internally handled as SCSI devices, so we are currently limited to seven USB mass storage devices. A typical setup might include a card reader, a boot stick, a harddisc and a DVD writer. In my setup, I had an additional harddisc added (filecore to transfer data fast from one BeagleBoard to another) and a FAT32 USB stick to exchange data with a PC. So only one device left.

Even if I talk about SCSI in the RISC OS 5 context, I don’t mean true SCSI devices, if you know what I mean. Anyway, Wide SCSI added support for IDs up to 15.

Some/most of the SCSI APIs identify devices by packing the bus, device and LUN IDs into a single byte. Migrating away from that is likely to cause problems.

SCSISoftUSB uses the SCSI_Register SWI to get new bus/dev/LUN IDs for each mass storage device it detects. This SWI should be capable of using multiple busses if one bus becomes full. However it can only make use of busses which haven’t been claimed for use by real SCSI hardware drivers, and there are only four bus IDs available, so if you’ve got three SCSI cards fitted then that could be the cause of the problem.

Do the missing devices show up on *devices at all? If they show up there but aren’t seen by CDFS then that would suggest that the problem is caused by the way (non-SCSI) CD drivers hijack SCSI device IDs. I “fixed” this in CDFS 2.50 by inverting the order in which CDFS scans for drives (so fake SCSI drivers will now claim SCSI IDs from card 3 instead of from card 0), so if you’re using an older/alternative version then that could be the problem.

The devices don’t show up in *devices. I have never seen (on the Beagle) a device ID above 7.

I agree that we should keep the “one byte” encoding for bus/dev/lun. Since there is little chance that a real SCSI bus suddenly pops up long after boot (this is theoretically possible by using one of the SCSI-USB-adapters available, but their standard operation mode is “convert one SCSI device to one USB device”, the bus mode is proprietory), I would just keep allocating SCSI IDs for USB devices (and therefore buses if one bus is full).

Which USB port are you using on the beagle? If you’re using the OTG port you may have run into a limit in MUSBDriver.

I think I’ve got at least 9 mass storage devices at home, so when I get a chance I’ll have to try reproducing this issue myself.

Hmmm, I think the internal devices (stick, harddisc, dvd writer, card reader) are connected via USB OTG, the rest was connected via a hub and one of the four USB ports of the xM.