SUSE SolidDriver Program

Joint Support Agreements

A running kernel that has had third party kernel module loaded can not be supported by SUSE engineering without cooperation of the vendor of the kernel module code. In order to ensure supportability to SUSE Linux Enterprise customers, SUSE requires a support process agreement to be established between vendor’s of third party kernel modules and SUSE.

Process Agreement

The joint support agreement establishes a process for handling customer support of SUSE Linux Enterprise kernels running kernel modules supplied by partners. With the agreement, SUSE technical support engineers, can handle initial triage and data collection from the customer. Once it is determined that the partner’s kernel module is suspect to the customer’s problem, or if there is no way to rule out the partner’s kernel module as root cause, SUSE will involve the partner’s support contacts as outlined in the support process agreement.

Through the joint support agreement, SUSE and the partner can work together on resolving the issue while maintaining a consistent interface to the end customer.

Without a Joint Support Agreement

Without a joint support agreement in place, SUSE can’t do root-cause analysis of kernel issues when third party kernel modules have been loaded. Customers will be instructed to contact the vendor of the third party kernel module for additional support and analysis, in which case the vendor will need to either fix the issue in the kernel module code, or root cause and provide evidence of a valid bug in the SUSE Linux Enterprise kernel for SUSE for remedy.

Kernel Support Taint Flag

Modules can be built with a special flag that indicates the support status of the module. The module can be queried for the mode of support flag using the modinfo command. There are two possible modes:

  • Supported: yes = SUSE supported

  • Supported: external = supported by driver vendor and SUSE.

If neither of these modes are indicated, the supportability of the kernel module, and complete kernel, is unknown and should be assumed as unsupportable.

When loading modules The SUSE Linux Enterprise kernels will identify the supportability of the module code and set the appropriate kernel taint flag if an unsupported or externally supported module is loaded. The kernel taint flags are one mechanism to help customers and SUSE support technicians identify the supportability of a running kernel environment.

In default and recommended configuration, SUSE Linux Enterprise Server will refuse to load kernel modules that cannot be identified as supported by SUSE or an external party. Running unknown or unsupported code in kernel space invalidates any support commitments between SUSE and the end user.

Kernel Taint States and Support Levels

When the kernel issues an error message it will indicate the taint state of the kernel at that time. The information is encoded through single-character flags in the string following “Tainted:” in a kernel error message.

The descriptions below only apply to environments running official SUSE Linux Enterprise kernels.

Untainted kernel = SUSE Supported

When a kernel is not tainted with an ‘X’ or ‘N’ flag, all loaded kernel code is fully supported by SUSE and SUSE engineering has expertise to debug and fix the code. Only code that has been built, tested, and shipped by SUSE loads without tainting the kernel.

‘X’ tainted kernel = e’X’ternally Supported

Some code shipped with SUSE Linux Enterprise kernels, and all code built and shipped by SUSE partners, requires the partner’s assistance in supporting the code. If any such code is loaded by the kernel, the ‘X’ taint flag will be set indicating that partner assistance is necessary to provide support. Only official partners who have support agreements established with SUSE are allowed to identify their kernel module binaries as externally supported.

‘N’ tainted kernel = u’N’supported

If at any time, a running kernel instance loads a kernel module that cannot be identified as supported by SUSE or supported by a SUSE partner, the ‘N’ taint flag will be set. Such an environment is not considered supported by SUSE and looses guarantees of any efforts by SUSE towards resolution to customer issues encountered. To restore the SUSE support guarantees, the issue must be reproduced in an environment without the ‘N’ kernel taint flag set.

The kernel maintains list of taint flags in addition to the ones related to support. For the full list and descriptions, refer to /usr/src/linux/Documentation/sysctl/kernel.txt

Assistance from SUSE Partners

As stated above, in order to fully resolve customer issues, code built and shipped by SUSE partners as well as some code shipped with SUSE Linux Enterprise products might require assistance by SUSE partners. SUSE provides support commitments to such code based on strong partnerships and established agreements between between partners and SUSE for the specific code in question. For the SUSE Linux Enterprise customer, the support process will be transparent and all partner assistance handled behind the scenes between SUSE and the partners. In most cases, the customer will not notice the difference between support coming solely from SUSE or with the cooperation of SUSE partners.