FreeBSD 11.4 OS: RAID/HBA controller is not showing in camcontrol devlist when it has BTL address 2:0:1 which assigned by the driver.

srikanth

srikanth

RAID/HBA controller is not showing in camcontrol devlist when it has BTL address 2:0:1 which assigned by the driver, the issue is seeing in one of the SuperMicro x11 machine.

I've been observed that the SCSI CAM layer is not sending INQUIRY commands to the BTL address 2:0:1 and it's look like the controller is not probed/registered.

We've tried on similar supermicro server but the issue we're not seeing(Issue seeing in only one machine). we debugged the issue by changing BTL address to 2:0:0 then the controller is listing in camcontrol devlist.

Here I've few questions.
Why the issue is seeing in particular server set and not in all the machines?
 
Back up a moment. An HBA or RAID controller, in and of itself, is not a SCSI device or block storage device. It is a thing that connects to, or creates SCSI or block storage devices. In SCSI terminology, an HBA is not a target, but an initiator. Logically, it should not show up in camcontrol devlist. It should show up in "camcontrol devlist -v", which also lists the HBAs.

Are you sure you are talking about the RAID/HBA controller? Maybe you mean the enclosure controller? Those are typically SCSI targets, of type SES (scsi enclosure services).

I think, as SirDice already said, we need more details. Also please explain what you mean exactly by "BTL address", and how you set it. I'm suspecting that you mean bus/target/LU address, in which case you're missing the controller part of that.
 
SirDice said:
What type/brand card using which driver?
Click to expand...
Hello SirDice & ralphbsz ,

I'm talking about Adaptec RAID/HBA storage controller and the driver is smartpqi. Usually we're exposing RAID controller as a scsi device by assigning Bus/Target/Lun address as 2:0:1. But one of the supermicro server is not showing RAID controller in camcontrol devlist/camcontrol devlist -v.

If i assign Bus/Target/Lun address 2:0:0 in driver then it will show in camcontrol output in the failure server set.

I've been observed the SCSI CAM layer is sending scsi commands in the following sequence if we assign Bus/target/LUN address 2:0:0 in driver.
1) INQUIRY (0x12)
2 )REPORTLUN (0xA0)
3) TUR (0x0)
4) Mode sense. (0x1A)

But in the case of Bus/target/LUN address 2:0:1, the driver is not seeing above sequence of commands. It seems the BTL:2:0:1 itself not probed.
 
OK, I'm beginning to understand, and I have a hunch of what is wrong.

In some fashion, you tell your RAID controller to expose itself as a target (it is also the initiator), which would make it visible as a device. I wonder what device type it would be (typical device types include disk, tape, printer, enclosure...), but that's sort of an academic question. And you change the bus / target / LUN of that device, with the only change being the LU number 0 or 1. (By the way, LUN is the abbreviation for Logical Unit Number, and LU for Logical Unit, so the LUN is the number of the LU, and the word LUN number makes no sense.)

When you tell the controller to be LUN 0, things work.

When you tell the controller to be LUN 1, they don't. My hunch is this: Every SCSI device has to have a LUN 0. That's because there has to be a well-known LUN, so initiators can enumerate all LUNs. They do that by sending a REPORT LUNS command to the LUN0, and they get back a list of all LUNs. My hunch is: If you tell the Adaptec to be at 2:0:1, it does't create a LUN at zero, the computer doesn't find anything at 2:0:0, doesn't send a REPORT LUNS to 2:0:0, and will never find out that 2:0:1 even exists. That would be a bug in the Adaptec: every device has to have LUN 0.
 
Thanks for the info. But in that case why i'm not seeing the issue in all servers when it has BTL address 2:0:1( controller is exposing in all the servers with BTL:2:0:1 but seeing issue in only one server. )
ralphbsz said:
OK, I'm beginning to understand, and I have a hunch of what is wrong.

In some fashion, you tell your RAID controller to expose itself as a target (it is also the initiator), which would make it visible as a device. I wonder what device type it would be (typical device types include disk, tape, printer, enclosure...), but that's sort of an academic question. And you change the bus / target / LUN of that device, with the only change being the LU number 0 or 1. (By the way, LUN is the abbreviation for Logical Unit Number, and LU for Logical Unit, so the LUN is the number of the LU, and the word LUN number makes no sense.)

When you tell the controller to be LUN 0, things work.

When you tell the controller to be LUN 1, they don't. My hunch is this: Every SCSI device has to have a LUN 0. That's because there has to be a well-known LUN, so initiators can enumerate all LUNs. They do that by sending a REPORT LUNS command to the LUN0, and they get back a list of all LUNs. My hunch is: If you tell the Adaptec to be at 2:0:1, it does't create a LUN at zero, the computer doesn't find anything at 2:0:0, doesn't send a REPORT LUNS to 2:0:0, and will never find out that 2:0:1 even exists. That would be a bug in the Adaptec: every device has to have LUN 0.
Click to expand...
 
Good question. Sadly, bad answer: I have no idea.

My standard suggestion in such cases is: check (and update) firmware and software versions on everything.
 
ralphbsz said:
Good question. Sadly, bad answer: I have no idea.

My standard suggestion in such cases is: check (and update) firmware and software versions on everything.
Click to expand...
Sorry to trouble you again;
I've ran into a similar problem, The Logical volume address has 0:0:1(Bus:Target:Lun) which is assigned by driver. As usually the volume is not exposing in camcontrol devlist, If the system goes for reboot then the volumes will expose to the system/it will show in camcontrol devlist.

Still not understanding this behaviour, how the system reboot is effecting here.
 
Are you saying that the ***ONLY*** logical unit gets number 0:0:1 (LUN=1)? That's broken. Every target must have a LUN=0 unit. The standard says so. Now, it if has a logical unit #0 and also one that is #1, that's OK (and should not give any problems in camcontrol, unless camcontrol or all of the FreeBSD SCSI stack has bugs).

Now, shouting at the Adaptec "you are doing it wrong, the standard says so" is unlikely to help any. And I have no idea how to convince an Adaptec to work correctly. I think the last time I used an Adaptec RAID controller was ... probably in the 1990s or so.
 
You must log in or register to reply here.
Back
Top