Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Anbindung von FibreChannel-Geraeten
63 views
Skip to first unread message
Sebastian Suchanek
Jan 6, 2018, 6:49:29 PM1/6/18
to
Hallo NG!
Hier[tm] steht ein kleiner Heimserver mit Debian Jessie,
darin u.a. ein FibreChannel-Hostadapter Emulex LPE11002.
Daran angeschlossen ist eine Tapelibrary Overland NEO2000
(die mehrere Parallel-SCSI-Anschlüsse hat) und als "Adapter"
zusätzlich eine Atto 2390 FC/SCSI-Bridge eingebaut hat.
Wenn ich die Library einschalte, erkennt der Kernel
grundsätzlich, dass sich am FC-HA etwas tut (aus
/var/log/syslog):
| [...]
| Jan 6 23:29:18 tigersclaw kernel: [26099431.602391] lpfc 0000:03:00.1: 1:1303 Link Up Event x11 received Data: x11 x0 x10 x0 x0 x0 0
| Jan 6 23:29:18 tigersclaw kernel: [26099431.630194] lpfc 0000:03:00.1: 1:(0):0237 Pending Link Event during Discovery: State x7
| Jan 6 23:29:18 tigersclaw kernel: [26099431.630218] lpfc 0000:03:00.1: 1:(0):0237 Pending Link Event during Discovery: State x7
| Jan 6 23:29:18 tigersclaw kernel: [26099431.630223] lpfc 0000:03:00.1: 1:(0):0111 Dropping received ELS cmd Data: x0 xfffffe x0
| Jan 6 23:29:18 tigersclaw kernel: [26099431.630341] lpfc 0000:03:00.1: 1:1303 Link Up Event x13 received Data: x13 x0 x10 x0 x0 x0 0
| [...]
Die Atto Bridge behauptet in ihrem Webinterface auch, sie
habe die beiden Parallel-SCSI-Devices der Library erkannt und
würde sie auf FC mappen. Allerdings bekommt der Server davon
nichts mit, d.h., es erscheinen keine (neuen) Devices:
| # lsscsi
| [1:0:0:0] disk ATA Samsung SSD 850 2B6Q /dev/sda
| [2:0:0:0] disk ATA WDC WD40EFRX-68W 0A82 /dev/sdb
| [3:0:0:0] disk ATA WDC WD40EFRX-68W 0A82 /dev/sdc
| #
Auch ein rescan-scsi-bus aus dem scsitools-Paket ändert daran
nichts:
| # /sbin/rescan-scsi-bus
| /sbin/rescan-scsi-bus: line 592: [: 1.39: integer expression expected
| Host adapter 0 (lpfc) found.
| Host adapter 1 (ahci) found.
| Host adapter 2 (ahci) found.
| Host adapter 3 (ahci) found.
| Host adapter 4 (ahci) found.
| Host adapter 5 (ahci) found.
| Host adapter 6 (ahci) found.
| Host adapter 7 (lpfc) found.
| Scanning SCSI subsystem for new devices
| Scanning host 0 for all SCSI target IDs, all LUNs
| Scanning host 1 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
| Scanning for device 1 0 0 0 ...
| OLD: Host: scsi1 Channel: 00 Id: 00 Lun: 00
| Vendor: ATA Model: Samsung SSD 850 Rev: 2B6Q
| Type: Direct-Access ANSI SCSI revision: 05
| Scanning host 2 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
| Scanning for device 2 0 0 0 ...
| OLD: Host: scsi2 Channel: 00 Id: 00 Lun: 00
| Vendor: ATA Model: WDC WD40EFRX-68W Rev: 0A82
| Type: Direct-Access ANSI SCSI revision: 05
| Scanning host 3 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
| Scanning for device 3 0 0 0 ...
| OLD: Host: scsi3 Channel: 00 Id: 00 Lun: 00
| Vendor: ATA Model: WDC WD40EFRX-68W Rev: 0A82
| Type: Direct-Access ANSI SCSI revision: 05
| Scanning host 4 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
| Scanning host 5 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
| Scanning host 6 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
| Scanning host 7 for all SCSI target IDs, all LUNs
| 0 new device(s) found.
| 0 device(s) removed.
| #
Ich meine mich aber erinnern zu können, dass genau diese
Bridge an diesem FC-HA auf diesem System schon einmal
funktioniert hätte.
Was könnte hier schieflaufen? Wo finde ich die "gebridgten"
SCSI-Geräte bzw. wie bekomme ich die in Debian eingebunden
bzw. angesprochen?
TIA,
Sebastian
_____
XP dchm & dcoulm, f'up2 dcoulm
--
X-Post, FollowUp-To de.comp.os.unix.linux.misc
Hier[tm] steht ein kleiner Heimserver mit Debian Jessie,
darin u.a. ein FibreChannel-Hostadapter Emulex LPE11002.
Daran angeschlossen ist eine Tapelibrary Overland NEO2000
(die mehrere Parallel-SCSI-Anschlüsse hat) und als "Adapter"
zusätzlich eine Atto 2390 FC/SCSI-Bridge eingebaut hat.
Wenn ich die Library einschalte, erkennt der Kernel
grundsätzlich, dass sich am FC-HA etwas tut (aus
/var/log/syslog):
| [...]
| Jan 6 23:29:18 tigersclaw kernel: [26099431.602391] lpfc 0000:03:00.1: 1:1303 Link Up Event x11 received Data: x11 x0 x10 x0 x0 x0 0
| Jan 6 23:29:18 tigersclaw kernel: [26099431.630194] lpfc 0000:03:00.1: 1:(0):0237 Pending Link Event during Discovery: State x7
| Jan 6 23:29:18 tigersclaw kernel: [26099431.630218] lpfc 0000:03:00.1: 1:(0):0237 Pending Link Event during Discovery: State x7
| Jan 6 23:29:18 tigersclaw kernel: [26099431.630223] lpfc 0000:03:00.1: 1:(0):0111 Dropping received ELS cmd Data: x0 xfffffe x0
| Jan 6 23:29:18 tigersclaw kernel: [26099431.630341] lpfc 0000:03:00.1: 1:1303 Link Up Event x13 received Data: x13 x0 x10 x0 x0 x0 0
| [...]
Die Atto Bridge behauptet in ihrem Webinterface auch, sie
habe die beiden Parallel-SCSI-Devices der Library erkannt und
würde sie auf FC mappen. Allerdings bekommt der Server davon
nichts mit, d.h., es erscheinen keine (neuen) Devices:
| # lsscsi
| [1:0:0:0] disk ATA Samsung SSD 850 2B6Q /dev/sda
| [2:0:0:0] disk ATA WDC WD40EFRX-68W 0A82 /dev/sdb
| [3:0:0:0] disk ATA WDC WD40EFRX-68W 0A82 /dev/sdc
| #
Auch ein rescan-scsi-bus aus dem scsitools-Paket ändert daran
nichts:
| # /sbin/rescan-scsi-bus
| /sbin/rescan-scsi-bus: line 592: [: 1.39: integer expression expected
| Host adapter 0 (lpfc) found.
| Host adapter 1 (ahci) found.
| Host adapter 2 (ahci) found.
| Host adapter 3 (ahci) found.
| Host adapter 4 (ahci) found.
| Host adapter 5 (ahci) found.
| Host adapter 6 (ahci) found.
| Host adapter 7 (lpfc) found.
| Scanning SCSI subsystem for new devices
| Scanning host 0 for all SCSI target IDs, all LUNs
| Scanning host 1 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
| Scanning for device 1 0 0 0 ...
| OLD: Host: scsi1 Channel: 00 Id: 00 Lun: 00
| Vendor: ATA Model: Samsung SSD 850 Rev: 2B6Q
| Type: Direct-Access ANSI SCSI revision: 05
| Scanning host 2 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
| Scanning for device 2 0 0 0 ...
| OLD: Host: scsi2 Channel: 00 Id: 00 Lun: 00
| Vendor: ATA Model: WDC WD40EFRX-68W Rev: 0A82
| Type: Direct-Access ANSI SCSI revision: 05
| Scanning host 3 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
| Scanning for device 3 0 0 0 ...
| OLD: Host: scsi3 Channel: 00 Id: 00 Lun: 00
| Vendor: ATA Model: WDC WD40EFRX-68W Rev: 0A82
| Type: Direct-Access ANSI SCSI revision: 05
| Scanning host 4 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
| Scanning host 5 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
| Scanning host 6 for SCSI target IDs 0 1 2 3 4 5 6 7, all LUNs
| Scanning host 7 for all SCSI target IDs, all LUNs
| 0 new device(s) found.
| 0 device(s) removed.
| #
Ich meine mich aber erinnern zu können, dass genau diese
Bridge an diesem FC-HA auf diesem System schon einmal
funktioniert hätte.
Was könnte hier schieflaufen? Wo finde ich die "gebridgten"
SCSI-Geräte bzw. wie bekomme ich die in Debian eingebunden
bzw. angesprochen?
TIA,
Sebastian
_____
XP dchm & dcoulm, f'up2 dcoulm
--
X-Post, FollowUp-To de.comp.os.unix.linux.misc
Udo Tödter
Jan 9, 2018, 2:48:36 AM1/9/18
to
On 07.01.2018 00:01, Sebastian Suchanek wrote:
> Hallo NG!
>
> Hier[tm] steht ein kleiner Heimserver mit Debian Jessie,
> darin u.a. ein FibreChannel-Hostadapter Emulex LPE11002.
> Daran angeschlossen ist eine Tapelibrary Overland NEO2000
> (die mehrere Parallel-SCSI-Anschlüsse hat) und als "Adapter"
> zusätzlich eine Atto 2390 FC/SCSI-Bridge eingebaut hat.
> Wenn ich die Library einschalte, erkennt der Kernel
> grundsätzlich, dass sich am FC-HA etwas tut (aus
> /var/log/syslog):
>
> | [...]
> | Jan 6 23:29:18 tigersclaw kernel: [26099431.602391] lpfc 0000:03:00.1: 1:1303 Link Up Event x11 received Data: x11 x0 x10 x0 x0 x0 0
> | Jan 6 23:29:18 tigersclaw kernel: [26099431.630194] lpfc 0000:03:00.1: 1:(0):0237 Pending Link Event during Discovery: State x7
> | Jan 6 23:29:18 tigersclaw kernel: [26099431.630218] lpfc 0000:03:00.1: 1:(0):0237 Pending Link Event during Discovery: State x7
> | Jan 6 23:29:18 tigersclaw kernel: [26099431.630223] lpfc 0000:03:00.1: 1:(0):0111 Dropping received ELS cmd Data: x0 xfffffe x0
> | Jan 6 23:29:18 tigersclaw kernel: [26099431.630341] lpfc 0000:03:00.1: 1:1303 Link Up Event x13 received Data: x13 x0 x10 x0 x0 x0 0
> | [...]
Ist der HBA, also in diesem Fall die FC-Karte im korrekten Modus
> Hallo NG!
>
> Hier[tm] steht ein kleiner Heimserver mit Debian Jessie,
> darin u.a. ein FibreChannel-Hostadapter Emulex LPE11002.
> Daran angeschlossen ist eine Tapelibrary Overland NEO2000
> (die mehrere Parallel-SCSI-Anschlüsse hat) und als "Adapter"
> zusätzlich eine Atto 2390 FC/SCSI-Bridge eingebaut hat.
> Wenn ich die Library einschalte, erkennt der Kernel
> grundsätzlich, dass sich am FC-HA etwas tut (aus
> /var/log/syslog):
>
> | [...]
> | Jan 6 23:29:18 tigersclaw kernel: [26099431.602391] lpfc 0000:03:00.1: 1:1303 Link Up Event x11 received Data: x11 x0 x10 x0 x0 x0 0
> | Jan 6 23:29:18 tigersclaw kernel: [26099431.630194] lpfc 0000:03:00.1: 1:(0):0237 Pending Link Event during Discovery: State x7
> | Jan 6 23:29:18 tigersclaw kernel: [26099431.630218] lpfc 0000:03:00.1: 1:(0):0237 Pending Link Event during Discovery: State x7
> | Jan 6 23:29:18 tigersclaw kernel: [26099431.630223] lpfc 0000:03:00.1: 1:(0):0111 Dropping received ELS cmd Data: x0 xfffffe x0
> | Jan 6 23:29:18 tigersclaw kernel: [26099431.630341] lpfc 0000:03:00.1: 1:1303 Link Up Event x13 received Data: x13 x0 x10 x0 x0 x0 0
> | [...]
konfiguriert? Loop oder Point to Point?
Udo
Sebastian Suchanek
Jan 13, 2018, 12:55:44 PM1/13/18
to
Thus spoke Udo Tödter:
Ja, laut entsprechenden Ausgaben der Weboberfläche der Bridge
sowie des Systems sollte beides auf Point to Point und 4GB/s
laufen:
https://suchanek.de/temp/FC-bridge_status.png (151kB)
| # systool -c fc_host -v host7
| Class = "fc_host"
|
| Class Device = "host7"
| Class Device path = "/sys/devices/pci0000:00/0000:00:1c.0/0000:03:00.1/host7/fc_host/host7"
| active_fc4s = "0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 "
| dev_loss_tmo = "30"
| fabric_name = "0x0"
| issue_lip = <store method only>
| max_npiv_vports = "127"
| maxframe_size = "2048 bytes"
| node_name = "0x20000000c971147d"
| npiv_vports_inuse = "0"
| port_id = "0x000000"
| port_name = "0x10000000c971147d"
| port_state = "Online"
| port_type = "Point-To-Point (direct nport connection)"
| speed = "4 Gbit"
| supported_classes = "Class 3"
| supported_fc4s = "0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 "
| supported_speeds = "1 Gbit, 2 Gbit, 4 Gbit"
| symbolic_name = "Emulex LPe11002-M4 FV2.82A4 DV11.0.0.10. HN:(none) OS:Linux"
| tgtid_bind_type = "wwpn (World Wide Port Name)"
| uevent =
| vport_create = <store method only>
| vport_delete = <store method only>
|
| Device = "host7"
| Device path = "/sys/devices/pci0000:00/0000:00:1c.0/0000:03:00.1/host7"
| uevent = "DEVTYPE=scsi_host"
|
|
| #
Tschüs,
Sebastian
sowie des Systems sollte beides auf Point to Point und 4GB/s
laufen:
https://suchanek.de/temp/FC-bridge_status.png (151kB)
| # systool -c fc_host -v host7
| Class = "fc_host"
|
| Class Device = "host7"
| Class Device path = "/sys/devices/pci0000:00/0000:00:1c.0/0000:03:00.1/host7/fc_host/host7"
| active_fc4s = "0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 "
| dev_loss_tmo = "30"
| fabric_name = "0x0"
| issue_lip = <store method only>
| max_npiv_vports = "127"
| maxframe_size = "2048 bytes"
| node_name = "0x20000000c971147d"
| npiv_vports_inuse = "0"
| port_id = "0x000000"
| port_name = "0x10000000c971147d"
| port_state = "Online"
| port_type = "Point-To-Point (direct nport connection)"
| speed = "4 Gbit"
| supported_classes = "Class 3"
| supported_fc4s = "0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 "
| supported_speeds = "1 Gbit, 2 Gbit, 4 Gbit"
| symbolic_name = "Emulex LPe11002-M4 FV2.82A4 DV11.0.0.10. HN:(none) OS:Linux"
| tgtid_bind_type = "wwpn (World Wide Port Name)"
| uevent =
| vport_create = <store method only>
| vport_delete = <store method only>
|
| Device = "host7"
| Device path = "/sys/devices/pci0000:00/0000:00:1c.0/0000:03:00.1/host7"
| uevent = "DEVTYPE=scsi_host"
|
|
| #
Tschüs,
Sebastian
Sebastian Suchanek
Jan 13, 2018, 2:17:18 PM1/13/18
to
Sebastian Suchanek macht die Ingrid:
Nachtrag: Nachdem ich gerade nochmal einen Reset des FC-HBAs
ausgelöst habe, werden die "gebridgten" Geräte erkannt.
| # echo 1 > /sys/class/fc_host/host0/issue_lip
| # echo 1 > /sys/class/fc_host/host7/issue_lip
| # echo "- - -" > /sys/class/scsi_host/host0/scan
| # echo "- - -" > /sys/class/scsi_host/host7/scan
| #
Aus /var/log/syslog:
| [...]
| Jan 13 20:09:19 tigersclaw kernel: [26692215.132639] rport-7:0-0: blocked FC remote port time out: removing target and saving binding
| Jan 13 20:09:19 tigersclaw kernel: [26692215.132818] lpfc 0000:03:00.1: 1:(0):0203 Devloss timeout on WWPN 20:00:00:10:86:20:0b:f4 NPort x000001 Data: x0 x8 x0
| Jan 13 20:09:32 tigersclaw kernel: [26692228.101354] lpfc 0000:03:00.1: 1:1305 Link Down Event x20 received Data: x20 x20 x80011 x0 x0
| Jan 13 20:09:32 tigersclaw kernel: [26692228.536823] lpfc 0000:03:00.1: 1:1303 Link Up Event x21 received Data: x21 x0 x10 x0 x0 x0 0
| Jan 13 20:09:32 tigersclaw kernel: [26692228.578813] scsi 7:0:0:0: Medium Changer OVERLAND NEO Series 0616 PQ: 0 ANSI: 2
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580214] ch 7:0:0:0: [ch0] type #1 (mt): 0x0+1 [medium transport]
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580217] ch 7:0:0:0: [ch0] type #2 (st): 0x20+29 [storage]
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580218] ch 7:0:0:0: [ch0] type #3 (ie): 0x1c0+1 [import/export]
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580219] ch 7:0:0:0: [ch0] type #4 (dt): 0x1e0+2 [data transfer]
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580753] ch 7:0:0:0: [ch0] dt 0x1e0:
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580756] ch 7:0:0:0: [ch0] ID 10, LUN 0,
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580757] ch 7:0:0:0: [ch0] Huh? device not found!
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581211] ch 7:0:0:0: [ch0] dt 0x1e1:
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581212] ch 7:0:0:0: [ch0] ID 12, LUN 0,
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581214] ch 7:0:0:0: [ch0] Huh? device not found!
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581215] ch 7:0:0:0: [ch0] INITIALIZE ELEMENT STATUS, may take some time ...
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581520] ch 7:0:0:0: [ch0] ... finished
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581521] ch 7:0:0:0: Attached scsi changer ch0
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581679] ch 7:0:0:0: Attached scsi generic sg3 type 8
| Jan 13 20:09:32 tigersclaw kernel: [26692228.902569] scsi 7:0:0:1: Sequential-Access SEAGATE ULTRIUM06242-XXX 1603 PQ: 0 ANSI: 3
| Jan 13 20:09:32 tigersclaw kernel: [26692228.904093] st 7:0:0:1: Attached scsi tape st0
| Jan 13 20:09:32 tigersclaw kernel: [26692228.904101] st 7:0:0:1: st0: try direct i/o: yes (alignment 4 B)
| Jan 13 20:09:32 tigersclaw kernel: [26692228.905046] st 7:0:0:1: Attached scsi generic sg4 type 1
| [...]
Trotz der etwas merkwürdigen Meldungen scheinen die Geräte
aber erkannt worden zu sein:
| # lsscsi
| [1:0:0:0] disk ATA Samsung SSD 850 2B6Q /dev/sda
| [2:0:0:0] disk ATA WDC WD40EFRX-68W 0A82 /dev/sdb
| [3:0:0:0] disk ATA WDC WD40EFRX-68W 0A82 /dev/sdc
| [7:0:0:0] mediumx OVERLAND NEO Series 0616 /dev/sch0
| [7:0:0:1] tape SEAGATE ULTRIUM06242-XXX 1603 /dev/st0
| #
Wenn ich nach jedem Kaltstart[1] der Library, in der die
Bridge eingebaut ist, erst noch einmal den FC-HBA
"durchresetten" muss, wäre das zwar unelegant, aber
prinzipiell ein lösbares Problem.
Merkwürdig ist jedoch: als ich gerade beim Schreiben dieses
Postings noch einmal versehentlich die obige Reset-Sequenz
ausgelöst habe, waren die SCSI-Gerät wieder verschwunden.
Erst ein dritter Reset hat sie wieder hervorgebracht. Sowas
ist natürlich noch 'mal eine Stufe ungünstiger... :-\
Tschüs,
Sebastian
_____
[1] Aus Energiespargründen und wegen infernalisch heulender
Lüfter ist die Library normalerweise ausgeschaltet.
> Thus spoke Udo Tödter:
>> On 07.01.2018 00:01, Sebastian Suchanek wrote:
>>>
>>> Hier[tm] steht ein kleiner Heimserver mit Debian Jessie,
>>> darin u.a. ein FibreChannel-Hostadapter Emulex LPE11002.
>>> Daran angeschlossen ist eine Tapelibrary Overland NEO2000
>>> (die mehrere Parallel-SCSI-Anschlüsse hat) und als
>>> "Adapter" zusätzlich eine Atto 2390 FC/SCSI-Bridge
>>> eingebaut hat. Wenn ich die Library einschalte, erkennt
>>> der Kernel grundsätzlich, dass sich am FC-HA etwas tut
>>> (aus /var/log/syslog):
>>> [...]
>>>
>> On 07.01.2018 00:01, Sebastian Suchanek wrote:
>>>
>>> Hier[tm] steht ein kleiner Heimserver mit Debian Jessie,
>>> darin u.a. ein FibreChannel-Hostadapter Emulex LPE11002.
>>> Daran angeschlossen ist eine Tapelibrary Overland NEO2000
>>> (die mehrere Parallel-SCSI-Anschlüsse hat) und als
>>> "Adapter" zusätzlich eine Atto 2390 FC/SCSI-Bridge
>>> eingebaut hat. Wenn ich die Library einschalte, erkennt
>>> der Kernel grundsätzlich, dass sich am FC-HA etwas tut
>>> (aus /var/log/syslog):
>>> [...]
>>>
>> Ist der HBA, also in diesem Fall die FC-Karte im korrekten
>> Modus konfiguriert? Loop oder Point to Point?
>
> Ja, laut entsprechenden Ausgaben der Weboberfläche der
> Bridge sowie des Systems sollte beides auf Point to Point
> und 4GB/s laufen:
> [...]
>> Modus konfiguriert? Loop oder Point to Point?
>
> Ja, laut entsprechenden Ausgaben der Weboberfläche der
> Bridge sowie des Systems sollte beides auf Point to Point
> und 4GB/s laufen:
Nachtrag: Nachdem ich gerade nochmal einen Reset des FC-HBAs
ausgelöst habe, werden die "gebridgten" Geräte erkannt.
| # echo 1 > /sys/class/fc_host/host0/issue_lip
| # echo 1 > /sys/class/fc_host/host7/issue_lip
| # echo "- - -" > /sys/class/scsi_host/host0/scan
| # echo "- - -" > /sys/class/scsi_host/host7/scan
| #
Aus /var/log/syslog:
| [...]
| Jan 13 20:09:19 tigersclaw kernel: [26692215.132639] rport-7:0-0: blocked FC remote port time out: removing target and saving binding
| Jan 13 20:09:19 tigersclaw kernel: [26692215.132818] lpfc 0000:03:00.1: 1:(0):0203 Devloss timeout on WWPN 20:00:00:10:86:20:0b:f4 NPort x000001 Data: x0 x8 x0
| Jan 13 20:09:32 tigersclaw kernel: [26692228.101354] lpfc 0000:03:00.1: 1:1305 Link Down Event x20 received Data: x20 x20 x80011 x0 x0
| Jan 13 20:09:32 tigersclaw kernel: [26692228.536823] lpfc 0000:03:00.1: 1:1303 Link Up Event x21 received Data: x21 x0 x10 x0 x0 x0 0
| Jan 13 20:09:32 tigersclaw kernel: [26692228.578813] scsi 7:0:0:0: Medium Changer OVERLAND NEO Series 0616 PQ: 0 ANSI: 2
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580214] ch 7:0:0:0: [ch0] type #1 (mt): 0x0+1 [medium transport]
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580217] ch 7:0:0:0: [ch0] type #2 (st): 0x20+29 [storage]
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580218] ch 7:0:0:0: [ch0] type #3 (ie): 0x1c0+1 [import/export]
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580219] ch 7:0:0:0: [ch0] type #4 (dt): 0x1e0+2 [data transfer]
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580753] ch 7:0:0:0: [ch0] dt 0x1e0:
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580756] ch 7:0:0:0: [ch0] ID 10, LUN 0,
| Jan 13 20:09:32 tigersclaw kernel: [26692228.580757] ch 7:0:0:0: [ch0] Huh? device not found!
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581211] ch 7:0:0:0: [ch0] dt 0x1e1:
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581212] ch 7:0:0:0: [ch0] ID 12, LUN 0,
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581214] ch 7:0:0:0: [ch0] Huh? device not found!
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581215] ch 7:0:0:0: [ch0] INITIALIZE ELEMENT STATUS, may take some time ...
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581520] ch 7:0:0:0: [ch0] ... finished
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581521] ch 7:0:0:0: Attached scsi changer ch0
| Jan 13 20:09:32 tigersclaw kernel: [26692228.581679] ch 7:0:0:0: Attached scsi generic sg3 type 8
| Jan 13 20:09:32 tigersclaw kernel: [26692228.902569] scsi 7:0:0:1: Sequential-Access SEAGATE ULTRIUM06242-XXX 1603 PQ: 0 ANSI: 3
| Jan 13 20:09:32 tigersclaw kernel: [26692228.904093] st 7:0:0:1: Attached scsi tape st0
| Jan 13 20:09:32 tigersclaw kernel: [26692228.904101] st 7:0:0:1: st0: try direct i/o: yes (alignment 4 B)
| Jan 13 20:09:32 tigersclaw kernel: [26692228.905046] st 7:0:0:1: Attached scsi generic sg4 type 1
| [...]
Trotz der etwas merkwürdigen Meldungen scheinen die Geräte
aber erkannt worden zu sein:
| # lsscsi
| [1:0:0:0] disk ATA Samsung SSD 850 2B6Q /dev/sda
| [2:0:0:0] disk ATA WDC WD40EFRX-68W 0A82 /dev/sdb
| [3:0:0:0] disk ATA WDC WD40EFRX-68W 0A82 /dev/sdc
| [7:0:0:1] tape SEAGATE ULTRIUM06242-XXX 1603 /dev/st0
| #
Wenn ich nach jedem Kaltstart[1] der Library, in der die
Bridge eingebaut ist, erst noch einmal den FC-HBA
"durchresetten" muss, wäre das zwar unelegant, aber
prinzipiell ein lösbares Problem.
Merkwürdig ist jedoch: als ich gerade beim Schreiben dieses
Postings noch einmal versehentlich die obige Reset-Sequenz
ausgelöst habe, waren die SCSI-Gerät wieder verschwunden.
Erst ein dritter Reset hat sie wieder hervorgebracht. Sowas
ist natürlich noch 'mal eine Stufe ungünstiger... :-\
Tschüs,
Sebastian
_____
[1] Aus Energiespargründen und wegen infernalisch heulender
Lüfter ist die Library normalerweise ausgeschaltet.
Michael Bäuerle
Jan 14, 2018, 4:24:50 AM1/14/18
to
Das "Loop Initialization Protocol" (LIP) ist doch FC-spezifisch.
Du machst das aber auch auf dem parallelen Bus hinter der Bridge
(Bus 7), der kein FCAL ist.
In der Liste unten taucht die Bridge auf Bus 0 nicht als Gerät auf.
Die Frage ist daher, ob man sie überhaupt auf diese Weise separat
reseten kann (oder ob ein LIP automatisch immer auch einen Bus Reset
auf dem parallelen Bus erzeugt).
Ich hätte mit letzterem gerechnet. Allerdings ist dann die Frage,
wo der separate Adressraum des Bus 7 überhaupt herkommt ... an
einer transparenten Bridge hätte ich das Laufwerk und den Medium-
Changer auf Bus 0 erwartet (wie man unten sieht nicht der Fall).
> Aus /var/log/syslog:
>
> | [Teilweise seltsame Meldungen]
>
> Trotz der etwas merkwürdigen Meldungen scheinen die Geräte
> aber erkannt worden zu sein:
>
> | # lsscsi
> | [1:0:0:0] disk ATA Samsung SSD 850 2B6Q /dev/sda
> | [2:0:0:0] disk ATA WDC WD40EFRX-68W 0A82 /dev/sdb
> | [3:0:0:0] disk ATA WDC WD40EFRX-68W 0A82 /dev/sdc
> | [7:0:0:0] mediumx OVERLAND NEO Series 0616 /dev/sch0
> | [7:0:0:1] tape SEAGATE ULTRIUM06242-XXX 1603 /dev/st0
> | #
>
> Wenn ich nach jedem Kaltstart[1] der Library, in der die
> Bridge eingebaut ist, erst noch einmal den FC-HBA
> "durchresetten" muss, wäre das zwar unelegant, aber
> prinzipiell ein lösbares Problem.
> Merkwürdig ist jedoch: als ich gerade beim Schreiben dieses
> Postings noch einmal versehentlich die obige Reset-Sequenz
> ausgelöst habe, waren die SCSI-Gerät wieder verschwunden.
> Erst ein dritter Reset hat sie wieder hervorgebracht. Sowas
> ist natürlich noch 'mal eine Stufe ungünstiger... :-\
Lasse vielleicht testweise mal das hier weg:
> Trotz der etwas merkwürdigen Meldungen scheinen die Geräte
> aber erkannt worden zu sein:
>
> | # lsscsi
> | [1:0:0:0] disk ATA Samsung SSD 850 2B6Q /dev/sda
> | [2:0:0:0] disk ATA WDC WD40EFRX-68W 0A82 /dev/sdb
> | [3:0:0:0] disk ATA WDC WD40EFRX-68W 0A82 /dev/sdc
> | [7:0:0:0] mediumx OVERLAND NEO Series 0616 /dev/sch0
> | [7:0:0:1] tape SEAGATE ULTRIUM06242-XXX 1603 /dev/st0
> | #
>
> Wenn ich nach jedem Kaltstart[1] der Library, in der die
> Bridge eingebaut ist, erst noch einmal den FC-HBA
> "durchresetten" muss, wäre das zwar unelegant, aber
> prinzipiell ein lösbares Problem.
> Merkwürdig ist jedoch: als ich gerade beim Schreiben dieses
> Postings noch einmal versehentlich die obige Reset-Sequenz
> ausgelöst habe, waren die SCSI-Gerät wieder verschwunden.
> Erst ein dritter Reset hat sie wieder hervorgebracht. Sowas
> ist natürlich noch 'mal eine Stufe ungünstiger... :-\
|
| # echo 1 > /sys/class/fc_host/host7/issue_lip
um zu sehen ob das einen Unterschied macht.
Für einen parallelen SCSI-Bus müsste es AFAIK eigentlich heißen:
/sys/class/scsi_host/host7
FC kann aber noch andere Protokolle außer SCSI übertragen, vermutlich
gibt es deswegen noch "fc_host" separat.
Sebastian Suchanek
Jan 14, 2018, 6:28:08 AM1/14/18
to
Thus spoke Michael Bäuerle:
Gute Frage. Das basiert auf irgendeinem Netzfundstück...
> Das "Loop Initialization Protocol" (LIP) ist doch
> FC-spezifisch. Du machst das aber auch auf dem parallelen
> Bus hinter der Bridge (Bus 7), der kein FCAL ist.
Ja, dass die o.g. Befehle nur die FC-Verbindung, aber nicht den
Parallel-SCSI-Bus "hinter" der Bridge resetten, ist mir bewusst.
Wie ich ja schon geschrieben hatte, ist die Library und damit
die FC-Bridge normalerweise ausgeschaltet und soll nur bei
Gebrauch "geweckt" werden. Ich gehe davon aus, dass die Bridge -
und damit der SCSI-Bus - nach dem Kaltstart in einem sauber
initalisierten Zustand ist.
Der FC-HBA hingegen steckt im Server und läuft daher "durch". Da
könnte ich mir schon eher vorstellen, dass die FC-Verbindung,
wenn sie im laufenden Betrieb durch das Ein- und Ausschalten der
Library getrennt und wieder hergestellt wird, zunächst einmal
"unsaubere" Zustände annimmt.
> In der Liste unten taucht die Bridge auf Bus 0 nicht als
> Gerät auf. Die Frage ist daher, ob man sie überhaupt auf
> diese Weise separat reseten kann (oder ob ein LIP
> automatisch immer auch einen Bus Reset auf dem parallelen
> Bus erzeugt). Ich hätte mit letzterem gerechnet. Allerdings
> ist dann die Frage, wo der separate Adressraum des Bus 7
> überhaupt herkommt ... an einer transparenten Bridge hätte
> ich das Laufwerk und den Medium- Changer auf Bus 0 erwartet
> (wie man unten sieht nicht der Fall).
> [...]
Das ist leicht zu erklären: Der verwendete FC-HBA ist, wie schon
erwähnt, ein Emulex LPe11002. Der hat zwei voneinander
unabhängige FC-Anschlüsse, die dann auch getrennt im System
auftauchen. Ich habe allerdings keinen blassen Schimmer, warum
die von Debian mit 1 und 7 (und den diversen S-ATA-Controllern
im System dazwischen) nummeriert werden und nicht z.B. mit 1 & 2
oder 6 & 7.
Das mit den zwei Anschlüssen ist aber auch gut so, denn sehr
wahrscheinlich werde ich noch ein zweites Laufwerk in die
Library einbauen, das dann einen direkten FC-Anschluss haben
wird. Das will ich dann mit dem zweiten Kanal des FC-HBAs
verbinden.
Tschüs,
Sebastian
> Das "Loop Initialization Protocol" (LIP) ist doch
> FC-spezifisch. Du machst das aber auch auf dem parallelen
> Bus hinter der Bridge (Bus 7), der kein FCAL ist.
Parallel-SCSI-Bus "hinter" der Bridge resetten, ist mir bewusst.
Wie ich ja schon geschrieben hatte, ist die Library und damit
die FC-Bridge normalerweise ausgeschaltet und soll nur bei
Gebrauch "geweckt" werden. Ich gehe davon aus, dass die Bridge -
und damit der SCSI-Bus - nach dem Kaltstart in einem sauber
initalisierten Zustand ist.
Der FC-HBA hingegen steckt im Server und läuft daher "durch". Da
könnte ich mir schon eher vorstellen, dass die FC-Verbindung,
wenn sie im laufenden Betrieb durch das Ein- und Ausschalten der
Library getrennt und wieder hergestellt wird, zunächst einmal
"unsaubere" Zustände annimmt.
> In der Liste unten taucht die Bridge auf Bus 0 nicht als
> Gerät auf. Die Frage ist daher, ob man sie überhaupt auf
> diese Weise separat reseten kann (oder ob ein LIP
> automatisch immer auch einen Bus Reset auf dem parallelen
> Bus erzeugt). Ich hätte mit letzterem gerechnet. Allerdings
> ist dann die Frage, wo der separate Adressraum des Bus 7
> überhaupt herkommt ... an einer transparenten Bridge hätte
> ich das Laufwerk und den Medium- Changer auf Bus 0 erwartet
> (wie man unten sieht nicht der Fall).
Das ist leicht zu erklären: Der verwendete FC-HBA ist, wie schon
erwähnt, ein Emulex LPe11002. Der hat zwei voneinander
unabhängige FC-Anschlüsse, die dann auch getrennt im System
auftauchen. Ich habe allerdings keinen blassen Schimmer, warum
die von Debian mit 1 und 7 (und den diversen S-ATA-Controllern
im System dazwischen) nummeriert werden und nicht z.B. mit 1 & 2
oder 6 & 7.
Das mit den zwei Anschlüssen ist aber auch gut so, denn sehr
wahrscheinlich werde ich noch ein zweites Laufwerk in die
Library einbauen, das dann einen direkten FC-Anschluss haben
wird. Das will ich dann mit dem zweiten Kanal des FC-HBAs
verbinden.
Tschüs,
Sebastian
Michael Bäuerle
Jan 14, 2018, 9:13:06 AM1/14/18
to
Sebastian Suchanek wrote:
> Thus spoke Michael Bäuerle:
> >
> > [...]
Jezt sehe ich es auch (die "2" steht für die Version mit zwei Ports):
<https://www.cisco.com/c/dam/en/us/products/collateral/interfaces-modules/ucs-virtual-interface-card-1225/elx_ds_all_hba_lpe12000.pdf>
Dann war das ein Missverständnis meinerseits. Ich dachte der HA hätte
nur einen Port und der zweite Bus wäre der hinter der Bridge.
> Ich habe allerdings keinen blassen Schimmer, warum
> die von Debian mit 1 und 7 (und den diversen S-ATA-Controllern
> im System dazwischen) nummeriert werden und nicht z.B. mit 1 & 2
> oder 6 & 7.
Warum auch immer diese Nummerierung, Bus 0 und Bus 7 sind demnach
einfach den beiden Ports des HA zugeordnet. Damit ist mein Gedanken-
gang oben hinfällig.
> Das mit den zwei Anschlüssen ist aber auch gut so, denn sehr
> wahrscheinlich werde ich noch ein zweites Laufwerk in die
> Library einbauen, das dann einen direkten FC-Anschluss haben
> wird. Das will ich dann mit dem zweiten Kanal des FC-HBAs
> verbinden.
Gemäß diesem Manual:
<http://attotech.ru/software/files/manuals/PRMA-0362-000MD.pdf>
unterstützt die Bridge 4GBit/s auf der FC-Seite. Diese Bandbreite
müsste eigentlich auch für 2 Laufwerke auf einem FCAL-Ring ausreichen.
Aber wenn ein Port sowieso noch frei ist ...
> Thus spoke Michael Bäuerle:
> >
> > [...]
<https://www.cisco.com/c/dam/en/us/products/collateral/interfaces-modules/ucs-virtual-interface-card-1225/elx_ds_all_hba_lpe12000.pdf>
Dann war das ein Missverständnis meinerseits. Ich dachte der HA hätte
nur einen Port und der zweite Bus wäre der hinter der Bridge.
> Ich habe allerdings keinen blassen Schimmer, warum
> die von Debian mit 1 und 7 (und den diversen S-ATA-Controllern
> im System dazwischen) nummeriert werden und nicht z.B. mit 1 & 2
> oder 6 & 7.
einfach den beiden Ports des HA zugeordnet. Damit ist mein Gedanken-
gang oben hinfällig.
> Das mit den zwei Anschlüssen ist aber auch gut so, denn sehr
> wahrscheinlich werde ich noch ein zweites Laufwerk in die
> Library einbauen, das dann einen direkten FC-Anschluss haben
> wird. Das will ich dann mit dem zweiten Kanal des FC-HBAs
> verbinden.
<http://attotech.ru/software/files/manuals/PRMA-0362-000MD.pdf>
unterstützt die Bridge 4GBit/s auf der FC-Seite. Diese Bandbreite
müsste eigentlich auch für 2 Laufwerke auf einem FCAL-Ring ausreichen.
Aber wenn ein Port sowieso noch frei ist ...
Michael Bäuerle
Jan 14, 2018, 9:17:39 AM1/14/18
to
Sebastian Suchanek wrote:
> Thus spoke Michael Bäuerle:
> >
> > [...]
> Thus spoke Michael Bäuerle:
> >
> > [...]
<https://www.cisco.com/c/dam/en/us/products/collateral/interfaces-modules/ucs-virtual-interface-card-1225/elx_ds_all_hba_lpe12000.pdf>
Dann war das ein Missverständnis meinerseits. Ich dachte der HA hätte
nur einen Port und der zweite Bus wäre der hinter der Bridge.
Dann war das ein Missverständnis meinerseits. Ich dachte der HA hätte
nur einen Port und der zweite Bus wäre der hinter der Bridge.
> Ich habe allerdings keinen blassen Schimmer, warum
> die von Debian mit 1 und 7 (und den diversen S-ATA-Controllern
> im System dazwischen) nummeriert werden und nicht z.B. mit 1 & 2
> oder 6 & 7.
> die von Debian mit 1 und 7 (und den diversen S-ATA-Controllern
> im System dazwischen) nummeriert werden und nicht z.B. mit 1 & 2
> oder 6 & 7.
Warum auch immer diese Nummerierung, Bus 0 und Bus 7 sind demnach
einfach den beiden Ports des HA zugeordnet. Damit ist mein Gedanken-
gang oben hinfällig.
einfach den beiden Ports des HA zugeordnet. Damit ist mein Gedanken-
gang oben hinfällig.
> Das mit den zwei Anschlüssen ist aber auch gut so, denn sehr
> wahrscheinlich werde ich noch ein zweites Laufwerk in die
> Library einbauen, das dann einen direkten FC-Anschluss haben
> wird. Das will ich dann mit dem zweiten Kanal des FC-HBAs
> verbinden.
> wahrscheinlich werde ich noch ein zweites Laufwerk in die
> Library einbauen, das dann einen direkten FC-Anschluss haben
> wird. Das will ich dann mit dem zweiten Kanal des FC-HBAs
> verbinden.
0 new messages