fusion SAS support
cover fusion SAS support
This patch implements minimal SAS support for fusion. It needs the previous set of fusion updates and the minimal SAS transport class to work. I'll probably revisit the transport class later to introduce a rport object, but I'll need some real enclosures with extenders and SMP ports to experiment with first. So my suggestion is to put the current state of the art into scsi-misc so it gets exposure in -mm and people can start reviwing the design and send patches. (Lots of thanks to James Smart btw, I had hoped to get more of this constructive critizism).
Quoted 9 lines · Christoph Hellwig
This patch implements minimal SAS support for fusion. It needs the previous set of fusion updates and the minimal SAS transport class to work. I'll probably revisit the transport class later to introduce a rport object, but I'll need some real enclosures with extenders and SMP ports to experiment with first. So my suggestion is to put the current state of the art into scsi-misc so it gets exposure in -mm and people can start reviwing the design and send patches. (Lots of thanks to James Smart btw, I had hoped to get more of this constructive critizism).
Hi Christoph,
I applied your four (sets of) patches, and they all seem to work fine. When connected through an expander, the data is a little light, but direct connect works great. Below, targets 0 and 1 are direct connect to a 1064 chip, while targets 21-29 are through an expander.
pc-mdr5:/sys/class/sas_transport/target0:0:1 # lsscsi
[0:0:0:0] disk SEAGATE ST373454SS 0002 /dev/sda [0:0:1:0] disk SEAGATE ST3146854SS 0002 /dev/sdb [0:0:21:0] enclosu LSILOGIC SASX12 SEP v0.1 - [0:0:22:0] disk SEAGATE ST373454SS 0002 /dev/sdk [0:0:23:0] disk SEAGATE ST373454SS 0002 /dev/sdl [0:0:24:0] disk SEAGATE ST3146854SS 0002 /dev/sdm [0:0:25:0] disk SEAGATE ST3146854SS 0002 /dev/sdn [0:0:26:0] disk SEAGATE ST3146854SS 0002 /dev/sdo [0:0:27:0] disk SEAGATE ST3146854SS 0002 /dev/sdp [0:0:28:0] disk SEAGATE ST373454SS 0002 /dev/sdq [0:0:29:0] disk SEAGATE ST373454SS 0002 /dev/sdr
pc-mdr5:/sys/class/sas_transport/target0:0:1 # more /sys/class/sas_transport/target0\:0\:[01]/*
*** /sys/class/sas_transport/target0:0:0/device: directory ***
::::::::::::::
/sys/class/sas_transport/target0:0:0/device_type ::::::::::::::
end device
::::::::::::::
/sys/class/sas_transport/target0:0:0/initiator_port_protocols ::::::::::::::
none
::::::::::::::
/sys/class/sas_transport/target0:0:0/phy_identifier ::::::::::::::
1
::::::::::::::
/sys/class/sas_transport/target0:0:0/sas_address ::::::::::::::0x5000c500004015fd
::::::::::::::
/sys/class/sas_transport/target0:0:0/target_port_protocols ::::::::::::::
ssp
*** /sys/class/sas_transport/target0:0:1/device: directory ***
::::::::::::::
/sys/class/sas_transport/target0:0:1/device_type ::::::::::::::
end device
::::::::::::::
/sys/class/sas_transport/target0:0:1/initiator_port_protocols ::::::::::::::
none
::::::::::::::
/sys/class/sas_transport/target0:0:1/phy_identifier ::::::::::::::
0
::::::::::::::
/sys/class/sas_transport/target0:0:1/sas_address ::::::::::::::0x5000c50000000ef5
::::::::::::::
/sys/class/sas_transport/target0:0:1/target_port_protocols ::::::::::::::
ssp
*** /sys/class/sas_transport/target0:0:24/device: directory ***
::::::::::::::
/sys/class/sas_transport/target0:0:24/device_type ::::::::::::::
none
::::::::::::::
/sys/class/sas_transport/target0:0:24/initiator_port_protocols ::::::::::::::
none
::::::::::::::
/sys/class/sas_transport/target0:0:24/phy_identifier ::::::::::::::
0
::::::::::::::
/sys/class/sas_transport/target0:0:24/sas_address ::::::::::::::0x0
::::::::::::::
/sys/class/sas_transport/target0:0:24/target_port_protocols ::::::::::::::
none
Quoted 6 lines · Jeremy Higdon
Hi Christoph,
I applied your four (sets of) patches, and they all seem to work fine. When connected through an expander, the data is a little light, but direct connect works great. Below, targets 0 and 1 are direct connect to a 1064 chip, while targets 21-29 are through an expander.
The device_type = none for the target connected through the expander looks wrong. I'll hopefully have an enclosure with an expander soon and will fix this.
Quoted 11 lines · Christoph Hellwig
Quoted 6 lines · Jeremy Higdon
Hi Christoph,
I applied your four (sets of) patches, and they all seem to work fine. When connected through an expander, the data is a little light, but direct connect works great. Below, targets 0 and 1 are direct connect to a 1064 chip, while targets 21-29 are through an expander.
The
device_type= none for the target connected through the expander looks wrong. I'll hopefully have an enclosure with an expander soon and will fix this.
I'm also having a couple of problems problem with discovery.
One is that devices connected to the expander are not discovered at driver init time. It requires a manual probe after driver init.
The other is that there's something that the firmware doesn't like about the probe. I got these sorts of errors.
mptscsih: ioc0: >> Attempting task abort! (sc=e000003014da9c80)
mptscsih: ioc0: >> Attempting task abort! (sc=e000003014da9c80)
mptbase: Initiating ioc0 recovery
mptscsih: ioc0: >> Attempting task abort! (sc=e000003014da9c80)
mptbase: Initiating ioc0 recovery
mptscsih: ioc0: >> Attempting target reset! (sc=e000003014da9c80)
mptscsih: ioc0: >> Attempting bus reset! (sc=e000003014da9c80)
mptbase: ioc0: WARNING - IOC is in FAULT state!!!
FAULT code = 1600h
mptbase: ioc0: Recovered from IOC FAULT
However, after updating firmware on the 1064, this latter problem seems to be fixed (still doesn't discover devices on the expander at driver init).
jeremy
Quoted 3 lines · Jeremy Higdon
However, after updating firmware on the 1064, this latter problem seems to be fixed (still doesn't discover devices on the expander at driver init).
As mentioned expanders aren't tested at all yet, I'll fix it as soon as I have an expander and hopefully soon the fusion specs (still waiting for lsi to contact me about the nda)