Executing (as root) any one of `mlxcontrol status mlxd0', `mlxcontrol status mlxd1', or `mlxcontrol status mlxd2' hangs with no output. Executing the above commands with the "-v" flag also hangs with no output. Executing `mlxcontrol status -v' produces the following output and then hangs: --------------------------------------------------------------- [root@szamoca:29] mlxcontrol status -v mlx0: DAC1100PVX, 3 channels, firmware 5.08-W-48, 32MB RAM Hardware ID 0x03020320 Firmware ID 0x30570805 Configured/Actual channels 3/3 Max Targets 16 Max Tags 236 Max System Drives 32 Max Arms 8 Max Spans 4 DRAM/cache/flash/NVRAM size 33554432/31481856/1048576/32768 DRAM type 10 Clock Speed 40ns Hardware Speed 360ns Max Commands 128 Max SG Entries 33 Max DP 472 Max IOD 1024 Max Comb 256 Latency 12s SCSI Timeout 18s Min Free Lines 72 Rate Constant 50 MAXBLK 128 Blocking Factor 1 sectors Cache Line Size 16 blocks SCSI Capability 40MHz, 16 bit Firmware Build Number 0 Fault Management Type 0 disk0001 (online) 'FUJITSU ' 'MAB3091S SUN9.0G' '1705' 8637MB fast20 wide sync tag-enabled disk0002 (online) 'FUJITSU ' 'MAE3182LP ' '0112' 17430MB fast20 wide sync tag-enabled disk0003 (online) 'FUJITSU ' 'MAB3091S SUN9.0G' '1705' 8637MB fast20 wide sync tag-enabled disk0004 (online) 'SEAGATE ' 'SX118202LS ' 'B808' 17366MB fast20 wide sync tag-enabled --------------------------------------------------------------------- Running `truss mlxcontrol status mlxd0' produces the following output: --------------------------------------------------------------------- mmap(0x0,2048,0x3,0x1000,-1,0x0) = 671490048 (0x28062000) munmap(0x28062000,0x800) = 0 (0x0) __sysctl(0xbfbff740,0x2,0x28060f88,0xbfbff73c,0x0,0x0) = 0 (0x0) mmap(0x0,32768,0x3,0x1002,-1,0x0) = 671490048 (0x28062000) geteuid() = 0 (0x0) getuid() = 0 (0x0) getegid() = 0 (0x0) getgid() = 0 (0x0) open("/etc/libmap.conf",0x0,0666) = 3 (0x3) fstat(3,0xbfbfeec8) = 0 (0x0) munmap(0x28066000,0x4000) = 0 (0x0) mmap(0x0,53248,0x3,0x1002,-1,0x0) = 671506432 (0x28066000) read(0x3,0x28067000,0x4000) = 579 (0x243) read(0x3,0x28067000,0x4000) = 0 (0x0) close(3) = 0 (0x0) open("/var/run/ld-elf.so.hints",0x0,00) = 3 (0x3) read(0x3,0xbfbff720,0x80) = 128 (0x80) lseek(3,0x80,0) = 128 (0x80) read(0x3,0x2806d000,0x4d) = 77 (0x4d) close(3) = 0 (0x0) access("/usr/lib/libc.so.4",0) = 0 (0x0) open("/usr/lib/libc.so.4",0x0,05001222053) = 3 (0x3) fstat(3,0xbfbff768) = 0 (0x0) read(0x3,0xbfbfe738,0x1000) = 4096 (0x1000) mmap(0x0,626688,0x5,0x20002,3,0x0) = 671559680 (0x28073000) mprotect(0x280f4000,0x1000,0x7) = 0 (0x0) mprotect(0x280f4000,0x1000,0x5) = 0 (0x0) mmap(0x280f5000,20480,0x3,0x12,3,0x81000) = 672092160 (0x280f5000) mmap(0x280fa000,73728,0x3,0x1012,-1,0x0) = 672112640 (0x280fa000) close(3) = 0 (0x0) mmap(0x0,248,0x3,0x1000,-1,0x0) = 672186368 (0x2810c000) munmap(0x2810c000,0xf8) = 0 (0x0) mmap(0x0,13360,0x3,0x1000,-1,0x0) = 672186368 (0x2810c000) munmap(0x2810c000,0x3430) = 0 (0x0) sigaction(SIGILL,0xbfbff7c0,0xbfbff7a8) = 0 (0x0) sigprocmask(0x1,0x0,0x28060ebc) = 0 (0x0) sigaction(SIGILL,0xbfbff7a8,0x0) = 0 (0x0) sigprocmask(0x1,0x28060e80,0xbfbff7e8) = 0 (0x0) sigprocmask(0x3,0x28060e90,0x0) = 0 (0x0) open("/dev/mlx0",0x0,05001165773) = 3 (0x3) close(3) = 0 (0x0) open("/dev/mlx0",0x0,05001162605) = 3 (0x3) ioctl(3,0xc0044d00,0xbfbff73c) = 0 (0x0) ioctl(3,0xc0044d07,0xbfbff73c) = 0 (0x0) ioctl(3,0xc0044d00,0xbfbff73c) = 0 (0x0) ioctl(3,0xc0044d07,0xbfbff73c) = 0 (0x0) ioctl(3,0xc0044d00,0xbfbff73c) = 0 (0x0) ioctl(3,0xc0044d07,0xbfbff73c) = 0 (0x0) ioctl(3,0xc0044d00,0xbfbff73c) = 0 (0x0) ioctl(3,0xc0044d07,0xbfbff73c) = 0 (0x0) ioctl(3,0xc0044d00,0xbfbff73c) = 0 (0x0) ioctl(3,0xc0044d07,0xbfbff73c) = 0 (0x0) ... this last line repeats ad-infinitum... ---------------------------------------------------------------------------- Fix: None known. How-To-Repeat: Simply execute mlxcontrol. The problem appears 100% of the time.
Here is a patch for this problem report. The bug is in the subr's `mlxd_foreach_ctrlr' and `mlxd_find_ctrlr_search', both in interface.c. Both of these subroutines use `ioctl(fd, MLX_NEXT_CHILD, &i)' to iterate over the configured mlxd(4) devices. However, in FreeBSD 4.10-RELEASE, this simply sets i to 0. I have replaced this code with a simple-minded loop from i=0 to 63, which is a large enough loop to find any devices on the RAID controllers supported by mlxd(4). It is likely that there is a more clever fix, but this does the job for me. If anybody has a better fix, I would be happy to test it. Attached is a patch file for /usr/src/usr.sbin/mlxcontrol/interface.c in FreeBSD 4.10-RELEASE. ...Sandy
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