quack75

Well I did a parity check yesterday and for the first time in many years it found 23 parity errors... It may be unrelated to the tg3 bug but it's very unlikely... After the parity was repaired, I xfs checked the 6 disks of my array. I'm not sure of the result because the output of xfs_repair is unclear to me. All I can say is that no lost+found directory was created on the drives so I hope I'm fine with my data and suffered no loss...

as the issue seems to be related to shared memory, could the type & amount of RAM in the server play some role ? I have 16GB of ECC memory in my G8. Another question, could the bug be triggered by some specific usage in Unraid ? I'm using xfs filesystem on all my drives except the cache which uses btrfs. And I'm using docker containers but no VM at all (and thus no pass through of devices)

My BIOS is : HP ProLiant MicroServer Gen8, BIOS J06 11/02/2015 I use the onboard NIC too, but not bonding the 2 ports. I have 1 ILO dedicated port and the other one is dedicated to Unraid. For HBA I'm using an add-on IBM M1015 card (aka LSI SAS9220-8i) for all drives except for one SSD (Cache drive) which is plugged on the CDROM port.

Hi JorgeB, I do have a HP Microserver Gen8 with a E3-1265L V2 processor, VT-D enabled and have no such stability issues nor the errors you describe in syslog with the 6.10 release. Just to be sure, I followed your advice and just disabled the VT-D feature but I'm pretty sure I'm not affected at all (many days of uptime) Can you explain how you came to the conclusion that the issue is caused by the new linux kernel, and only affecting broadcom tg3 nics on systems with VT-D enabled ?

Happy Birthday Unraid! Keep up the good work!

Hi, I know the topic has been discussed many times here but I read all posts about this and cannot find anything useful to solve my problem. On top of my array, I'm using 2 unassigned drives, one is a spare drive, unmounted, the other one is mounted and shared over the network (SMB). Both drives are identical (Western Digital 8TB WD80EFZX). Now my issue is that I would like so spin down both of these drives when they are not used. The spare one is spinning down normally. The second one (mounted and shared) does not spin down. My questions are: - is that the standard behaviour ? - if I check the power management setting on the drive using hdparm -I /dev/sdg |grep level I get the following: Advanced power management level: 164 Where does this 164 value comes from ? Unassigned devices is supposed to set this value to 180 (180 * 5s = 30 minutes) I checked this value on the other drive (the spare drive), and it's configured the same to 164 - Last info, if I use hdparm -y /dev/sdg then the drive spins down properly and remains in sleep mode until I access it over SMB. So I don't get why the hell the drive does not go to sleep on its own when unused ? Can I change that ? Thank you for your help