Description of problem:
I have a disk array with a more than 128 luns. Since the maximum number of disk
luns that sd driver can see is 128, i expected to see atleast 128. But i
noticed that i was not able to access any lun at all.
I investigated further and saw that sd_init() in sd.c was returning a
failure. This was because the code where memory is alloc'd for 'hd_struct'
structures was failing. The code snippet is below
* FIXME: should unregister blksize_size, hardsect_size and max_sectors
* the module is unloaded.
sd = kmalloc((sd_template.dev_max << 4) *
The reason is if dev_max is 128, then the total mem size being malloc'd
becomes 139264. The highest value in the cache_size table is 131072 and
apparently this seems to be causing the kmalloc to fail. In fact the kmalloc
fails for any dev_max value greater than 120
Also, the SD_EXTRA_DEVS by default is 2 but if i rebuild my kernel with
CONFIG_SD_EXTRA_DEVS set to 128, then no matter how many devices i have
connected to my host, sd_init() will always fail.
I did not have this problem with kernel 2.4.2-2, where in i notice that
the check to see if 'sd' kmalloc was successful, was absent.
Iam not sure what the fix needs to be (whether to include the next size
262144 in the cache_sizes table or whether to remove the check like in 2.4.2-2).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Rebuild the kernel with the CONFIG_SD_EXTRA_DEVS set to 128, then no matter
how many devices i have connected to my host, sd_init() will always fail.
No scsi disk device connected to the host will be accessible
The disk should be accessible
This looks like a potential kernel bug, mm is a userland component used mostly
by apache and php.
Changing component to kernel.
This problem was fixed in one of the early AS 2.1 x86 errata.
We currently set CONFIG_SD_EXTRA_DEVS=128.
If there is still a problem, pleaase re-open this bug with more
specific version information.