Ariyala

I have been asking about this plugin not working with my board, the ASRockRack X470D4U, in this thread before. After putting it aside for a while I started to look into the issue again. This is what I found: It worked with the original bios, but stopped after I updated to the latest. This pointed towards the ipmi-raw commands having changed. The now working command to change fan speeds is: 00 3a d6, not 00 3a 01 This command also expects 16 fan speed values now, not 8, or it will fail. The highest value is still 64, but the command seems to fail for me if less than 14 is specified. This is a working json config for me, however fan speed minimum cannot be lower than ~25% or the value this tool generates will drop below 14 and fail. This is with 6 fans connected. If your number is different, you may have to adjust this: { "ASRockRack": { "raw": "00 3a d6", "auto": "00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00", "full": "64 64 64 64 64 64 64 64 64 64 64 64 64 64 64 64", "fans": { "FAN1": "01", "FAN2": "01", "FAN3": "01", "FAN4": "01", "FAN5": "01", "FAN6": "01", "FAN_POS7": "01", "FAN_POS8": "01", "FAN_POS9": "01", "FAN_POS10": "01", "FAN_POS11": "01", "FAN_POS12": "01", "FAN_POS13": "01", "FAN_POS14": "01", "FAN_POS15": "01", "FAN_POS16": "01" } } } Additionally, I had to make a small change in the code of the ipmifan command itself. This is necessary since the ipmifan tool tries to set a fan speed of 0 for any non-connected fan. But, since the Asrock IPMI won't allow fan speeds below 20% the command will therefore fail. So to fix this you have to SSH into your unraid server, and edit this file: nano /usr/sbin/ipmifan Then in line #482 change this: }else{ $pwm ='0'; } to this: }else{ $pwm ='64'; } Save the changes (if you used nano, Ctrl+O and then Ctrl+X) and restart the IPMI Fan Control via the Web Interface.

Yes, readings are working as expected, just fan control is not working.

This is the content of my board.json file: #> cat /boot/config/plugins/ipmi/board.json { "ASRockRack": { "raw": "00 3a 01", "auto": "00 00 00 00 00 00 00 00", "full": "64 64 64 64 64 64 64 64", "fans": { "FAN_POS1": "01", "FAN_POS2": "01", "FAN_POS3": "01", "FAN_POS4": "01", "FAN_POS5": "01", "FAN_POS6": "01", "FAN_POS7": "01", "FAN_POS8": "01" } } } It used to work fine, but ever since we updated the bios of our board to version P4.20 it stopped working

Hey, is there any chance to get fan control working again for ASRockRack X470D4U? I had the previous plugin by dmacias working on the bios the board came with, but updated it to the latest bios about a year ago. After the update the previous plugin could still read the sensors, but not control the fans anymore. It looks like this version has the same issue. It can read all sensors, but when I try to configure the fans I only get the following: Checking IPMI fan Locations... Location 0-1: none Location 0-2: none Location 0-3: none Location 0-4: none Location 0-5: none Location 0-6: none Location 0-7: none Location 0-8: none Saving board configuration... My old fan config is still found somehow even though I uninstalled dmacias' version. I don't think that is causing this though.

I have disabled EPC and low current spin up in the drive firmware and so far the timeout has not appeared in the log again. Unfortunate that these two drive features are not usable, but better than rebuilding the array every few days. If anyone has any idea where to increase the drive timeout I would still be happy to get that information and try out if at least low current spin up is usable. Thank you @JorgeB for linking the other thread, as far as I can tell it is a good workaround for my issue.

Thank you for linking this thread, I will look into the firmware. However is anyone working on UNRAID looking into this? The features suggested to disable seem like something a NAS would benefit from. Especially low current spin up when you have many drives. I understand the thread suggests this is a Seagate / LSI problem, but if UNRAID is the only system running into issues with that hardware configuration it seems unlikely. Is there any way to increase the 15second timeout for spin up? Low current spin up takes longer, so just giving the drives more time might solve it without having to disable beneficial drive features.

Hey, I'm usually getting these log entries during disk spin up: kernel: sd 14:0:3:0: attempting task abort!scmd(0x00000000155105fb), outstanding for 15511 ms & timeout 15000 ms kernel: sd 14:0:3:0: [sdg] tag#4740 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 kernel: scsi target14:0:3: handle(0x000b), sas_address(0x4433221104000000), phy(4) kernel: scsi target14:0:3: enclosure logical id(0x500605b00a071021), slot(7) kernel: scsi target14:0:3: enclosure level(0x0000), connector name( ) kernel: sd 14:0:3:0: task abort: SUCCESS scmd(0x00000000155105fb) If there is an immediate read or write attempt I also get a disk read or write error. I'm using seagate iron wolf drives. These drives apparently have an average spin up time of 20+ seconds. So I'm assuming the 15 second timeout is the problem here not giving the disks enough time to spin up. Is that timeout coming from the controller or unraid? If it is unraid where can this value be set? So far I have replaced all SAS cables, and the controller card. I also have moved the disks around in the drive cages. Behavior is exactly the same, nothing changed. So increasing the timeout is probably the next logical step. Thanks in advance.

Hi, we are running an Unraid server since a few months and every once in a while there are some read-errors showing up in the System Log. These are the errors: Nov 22 13:57:40 Tower kernel: blk_update_request: I/O error, dev sdb, sector 2147483808 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Nov 22 13:57:40 Tower kernel: blk_update_request: I/O error, dev sdb, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 Those have happened since a while, and every time we have to rebuild the disk it seems. Now today we noticed that it may be due to the TimeMachine backup my Mac is running. I turned on my Mac at around 13:55 and just a few minutes later the errors show up. Here's the relevant full log for that time frame, the read-errors are near the end: Nov 22 13:56:44 Tower nginx: 2021/11/22 13:56:44 [alert] 3104#3104: worker process 4602 exited on signal 6 Nov 22 13:57:17 Tower kernel: sd 11:0:4:0: attempting task abort!scmd(0x0000000068b914ff), outstanding for 15487 ms & timeout 15000 ms Nov 22 13:57:17 Tower kernel: sd 11:0:4:0: [sdf] tag#1344 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Nov 22 13:57:17 Tower kernel: scsi target11:0:4: handle(0x000c), sas_address(0x4433221106000000), phy(6) Nov 22 13:57:17 Tower kernel: scsi target11:0:4: enclosure logical id(0x500605b009d32e70), slot(5) Nov 22 13:57:20 Tower kernel: sd 11:0:4:0: task abort: SUCCESS scmd(0x0000000068b914ff) Nov 22 13:57:20 Tower kernel: sd 11:0:4:0: Power-on or device reset occurred Nov 22 13:57:20 Tower emhttpd: read SMART /dev/sdf Nov 22 13:57:21 Tower kernel: sd 11:0:4:0: Power-on or device reset occurred Nov 22 13:57:37 Tower kernel: sd 11:0:0:0: attempting task abort!scmd(0x000000003808a1b1), outstanding for 15029 ms & timeout 15000 ms Nov 22 13:57:37 Tower kernel: sd 11:0:0:0: [sdb] tag#1421 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 Nov 22 13:57:37 Tower kernel: scsi target11:0:0: handle(0x000d), sas_address(0x4433221107000000), phy(7) Nov 22 13:57:37 Tower kernel: scsi target11:0:0: enclosure logical id(0x500605b009d32e70), slot(4) Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: task abort: SUCCESS scmd(0x000000003808a1b1) Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: [sdb] tag#1388 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=16s Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: [sdb] tag#1389 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=18s Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: [sdb] tag#1388 Sense Key : 0x2 [current] Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: [sdb] tag#1388 ASC=0x4 ASCQ=0x0 Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: [sdb] tag#1389 Sense Key : 0x2 [current] Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: [sdb] tag#1389 ASC=0x4 ASCQ=0x0 Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: [sdb] tag#1388 CDB: opcode=0x35 35 00 00 00 00 00 00 00 00 00 Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: [sdb] tag#1389 CDB: opcode=0x88 88 00 00 00 00 00 80 00 00 a0 00 00 00 08 00 00 Nov 22 13:57:40 Tower kernel: blk_update_request: I/O error, dev sdb, sector 2147483808 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Nov 22 13:57:40 Tower kernel: blk_update_request: I/O error, dev sdb, sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0 Nov 22 13:57:40 Tower kernel: md: disk0 read error, sector=2147483744 Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: [sdb] tag#1390 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: [sdb] tag#1390 Sense Key : 0x2 [current] Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: [sdb] tag#1390 ASC=0x4 ASCQ=0x0 Nov 22 13:57:40 Tower kernel: sd 11:0:0:0: [sdb] tag#1390 CDB: opcode=0x88 88 00 00 00 00 02 00 3a 67 88 00 00 00 08 00 00 Nov 22 13:57:40 Tower kernel: blk_update_request: I/O error, dev sdb, sector 8593762184 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Nov 22 13:57:40 Tower kernel: md: disk0 read error, sector=8593762120 Nov 22 13:57:40 Tower emhttpd: read SMART /dev/sdb Nov 22 13:57:40 Tower emhttpd: read SMART /dev/sdc Time Machine backup is on /dev/sdf, the disk where the read error occurs on (/dev/sdb) is one of the two parity drives. sdb, sdc = Parity drives sdd, sde, sdf = Storage drives Does anyone have an idea what the cause and solution for this problem is? Any more information I can provide to help figure out the issue? Any help would be much appreciated!