QsNetII Interconnect

Possible Conflict with Use of SIGUSR2

The Quadrics QsNet^II software internally uses SIGUSR2 to manage the interconnect. This can conflict with any user applications that use SIGUSR2, including for debugger use.

To work around this conflict, set the environment variable LIBELAN4_TRAPSIG for the application to a different signal number other than the default value 12 that corresponds to SIGUSR2. Doing this instructs the Quadrics software to use the new signal number, and SIGUSR2 can be once again used by the application. Signal numbers are define in the /usr/include/asm/signal.h file.

The qsnet Database May Contain Entries to Nonexistent Switch Modules

Depending on the system topology, the qsnet diagnostics database may contain entries to nonexistent switches.

This issue is manifested as errors reported by the /usr/bin/qsctrl utility similar to the following:

# qsctrl
qsctrl: failed to initialise module QR0N03: no such module (-7)
.
.
.

In the previous example, the switch_modules table in the qsnet database is populated with QR0N03 even though the QR0N03 module is not physically present. This problem has been reported to Quadrics, Ltd.

To work around this problem, delete the QR0N03 entry (and any other nonexistent switch entries) from the switch_modules table, and restart the swmlogger service:

# mysql -u root -p qsnet
mysql> delete from switch_modules where name="QR0N03";
mysql> quit
# service swm restart

In addition to the previous problem, the IP address of a switch module may be incorrectly populated in the switch_modules table, and you might see the following message:

# qsctrl
qsctrl: failed to parse module name 172.20.66.2
.
.
.

Resolve this issue by deleting the IP address from the switch_modules table and restarting the swmlogger service:

# mysql -u root -p qsnet
mysql> delete from switch_modules where name="172.20.66.2";
mysql> quit
# service swm restart

	NOTE: You must repeat the previous procedure if you invoke the cluster_config utility again and you choose to re-create the qsnet database during the cluster_config operation.