The MPT SCSI driver is only able to scan up to 8 LUNs (0-7) per SCSI device, which is far too few for some SCSI disks enclosures. This issue had already been discussed in http://osdir.com/ml/os.freebsd.devel.scsi/2008-03/msg00015.html about a year ago, but it seems not to have been fixed even though the fix is easy. Fix: The highest LUN number that MPT will scan is hardcoded in dev/mpt/mpt_cam.c around line 3605 : cpi->max_lun = 7; Replacing this "7" with the number you want solves the issue (I used 32 for my needs). But this necessitates the sysadmin to patch and recompile the kernel... Would be nice if this could default to a more sensible value than "8"...
Responsible Changed From-To: freebsd-bugs->freebsd-scsi Over to maintainer(s).
Increasing the max_lun number in the code is not the solution. Which arbitrary number should be chosen? If it's increased to 32, what about those who want 64? What about the problems created for those with older hardware that can't handle high lun scanning? The correct action requires a significant amount of code to be written and tested; if it were trivial it would have been done already. I know this response is unsatisfying and slightly aloof, and I apologize for that, but right now it's easier to ask that admins recompile for this situation than it is to tear up the core SCSI scanning code. Scott
On mar, 2009-05-12 at 22:59 -0600, Scott Long wrote: > Increasing the max_lun number in the code is not the solution. Which > arbitrary number should be chosen? If it's increased to 32, what about > those who want 64? Well, 8 is as much arbitrary than 32 would be, but 32 would cover a wider use spectrum. SCSI disks enclosures holding 16 to 20 disks are quite commonplace, and some show each disk as a LUN on the same SCSI device (i.e. some SCSI to SATA enclosures, or some RAID bays with RAID turned off to use ZFS RAID instead). > What about the problems created for those with older > hardware that can't handle high lun scanning? I'm not sure whether this exists. Possibly. My own SCSI card BIOS (LSILogic 1030 Ultra4 Adapter) only scans LUNs 0-7 when the system boots, *but* that doesn't prevent FreeBSD to use much higher LUN numbers when dev/mpt/mpt_cam.c is patched and recompiled for allowing so. > The correct action requires a significant amount of code to be written > and tested; if it were trivial it would have been done already. Maybe guessing the highest LUN number to scan according to HW type would be difficult, but would it be also very difficult to make this a parameter that could default to 8 and be set to higher values with an entry i.e. in /boot/loader.conf ? Would be easier than having to recompile the kernel...
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped