-
Notifications
You must be signed in to change notification settings - Fork 0
Conversation
Announcements and change-logs are available online [1][2]. [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1582315.html [2] https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.14.13
Hi Paul, |
Dear Thomas,
Am 10.01.2018 um 15:50 schrieb Thomas Kreitler:
further testing of the stock aacraid-driver yielded some deficits in the sys-fs representation. Aparently it doesn't link the disk devices to enclosure slots, a thing that the off-tree microsemi driver does (and the LSI driver also, so i deem it's 'good-practice' in modern HBA drivers). Indeed it doesn't affect the functionality, but it hampers maintenance and client-tools a bit more than just a bit.
Thank you for the feedback.
Could you please send the differences to our internal dvteam list or
open an issues and mention it there? Even better, report it to the Linux
kernel folks.
So my proposal is to discuss the reinsertion of the off-tree aacraid module in the office (i.e. IRL:).
Understood. In my opinion that’s orthogonal to this pull request though
as the 4.14.13 series never included the out of tree driver.
|
@donald asked me to select |
The default changed between 4.9 and 4.14. As Donald needs `/dev/kmem` for debugging, enable it again.
@pmenzel
and indeed the function call before the zfs thingy
|
Here is the location info of the missing sys-fs parts
The true location would be:
|
Thomas reports the problem below [1]. > further testing of the stock aacraid-driver yielded some deficits in > the sys-fs representation. Aparently it doesn't link the disk devices > to enclosure slots, a thing that the off-tree microsemi driver does > (and the LSI driver also, so i deem it's 'good-practice' in modern HBA > drivers). Indeed it doesn't affect the functionality, but it hampers > maintenance and client-tools a bit more than just a bit. > Here is the location info of the missing sys-fs parts > short way, where as the `device` part is missing: > ``` > #ls -la /sys/class/enclosure/7:0:80:0/Disk001 > drwxr-xr-x 3 root system 0 Jan 10 13:08 . > drwxr-xr-x 19 root system 0 Jan 10 13:07 .. > -rw-r--r-- 1 root system 4096 Jan 11 12:56 active > lrwxrwxrwx 1 root system 0 Jan 10 13:08 device -> > ../../../../../../../port-7:1/end_device-7:1/target7:0:65/7:0:65:0 > -rw-r--r-- 1 root system 4096 Jan 11 12:56 fault > -rw-r--r-- 1 root system 4096 Jan 11 12:56 locate > drwxr-xr-x 2 root system 0 Jan 11 12:56 power > -rw-r--r-- 1 root system 4096 Jan 11 12:56 power_status > -r--r--r-- 1 root system 4096 Jan 11 12:56 slot > -rw-r--r-- 1 root system 4096 Jan 11 12:56 status > -r--r--r-- 1 root system 4096 Jan 11 12:56 type > -rw-r--r-- 1 root system 4096 Jan 11 12:56 uevent > ``` > The true location would be: > ``` > /sys/devices/pci0000:00/0000:00:03.0/0000:04:00.0/host7/port-7:16/end_device-7:16/target7:0:80/7:0:80:0/enclosure/7:0:80:0/Disk001 > ``` [1] #571
99cc79c
to
c8ef8f9
Compare
tested on sigusr2 (it boots, gdm comes up, can log in, meltdown fixed, /dev/kmem tools work...) |
Test on mrtorgue : |
tested on claptrap (nfs server. no problem with browser on nfs client after nfs server reboot this time) |
Tested on keineahnung and sigusr2.