Fotoloading632

• Drivers Mpp Port Devices Replicator
• Drivers Mpp Port Devices Download
• Drivers Mpp Port Devices Usb

Download the latest drivers, software, firmware, and diagnostics for your HP products from the official HP Support website. However, if you want to use a 3rd-party bus controller, or develop your own to use with your Windows pen device, you can do that. If you want your pen device to connect via an alternate bus, then a 3rd-party HID mini-port driver might be required, and would be allowed according to the Windows 10 HLK requirements.

The Sun StorageTek Redundant Dual Active Controller (RDAC) failover drivers support the following Linux OS distributions for the 2.6 kernel:

• SuSE SLES 10 SP1 and SLES 9 (x86, x86_64, IA64)
• SuSE Linux Enterprise Server 10 SP1 and 9 for IBM eServer pSeries
• Architectures (ppc64)
• Red Hat RHEL 5 (x86, x86_64, IA64)
• Red Hat Advanced Server 4 (x86, x86_64, IA64)

About RDAC Multipath Drivers

Redundant Dual Active Controller (RDAC) is the failover driver for the Sun Storage 6180 array, StorageTek 6000 array series (includes Sun Storage 6580 and 6780 arrays) and Sun StorageTek 2500 array series. The RDAC failover driver includes these features:

• On-the-fly path validation.
• Cluster support.
• Automatic detection of path failure. The RDAC failover driver automatically routes I/O to another path in the same controller or to an alternate controller, in case all paths to a particular controller fail.
• Improved I/O retries. The RDAC driver handles vendor-specific SCSI error codes from the array controllers.
• Automatic rebalancing. When the failed controller obtains optimal status, storage array rebalance is performed automatically without user intervention.

Prerequisites

Before you install the RDAC driver, be sure the following requirements are met:

1. The HBAs connected to the host on which you are installing the RDAC driver are supported. The driver supports QLogic, LSI, and Emulex HBAs. (For supported HBA model numbers, see the README file included in the RDAC driver package, as described in Downloading the RDAC Driver.)

2. The compiler and kernel source for the appropriate OS are installed.

3. The HBAs connected to a single storage array are the same model. Use your HBA utilities, such as HBAanywhere (Emulex) or scli (QLogic) to ensure that your storage area network (SAN) is configured properly for this requirement.

4. The base HBA driver is installed and built. The following base and host drivers are supported:

5. To verify the driver is installed, use the following command:

The following sample output shows QLogic drivers (in bold text):

Downloading the RDAC Driver

The Linux OS RDAC driver is available for the following storage products:

• Sun Storage 6180 array
• Sun Storage 6580 and 6780 arrays
• Sun StorageTek 6000 array series
• Sun StorageTek 2500 array series

The Linux OS RDAC driver is compatible with array controller firmware version 06.19.25.16 (minimum). Array firmware is bundled with Sun StorageTek Common Array Manager (CAM) and is also available at the Sun Download Center (see the URL in Step 1 of the following procedure).

RDAC drivers are available from the Sun Download Center.

1. To download the RDAC driver, go to:

http://www.sun.com/download/index.jsp?tab=2#S

2. Select the package for the Linux OS platform.

3. Place the download in a non-volatile location on the system to be installed.

4. Load the standard HBA non-failover driver.

5. On the SuSE operating system, check the base HBA drivers are included in INITRD_MODULES in /etc/sysconfig/kernel for one of the following HBAs:

6. Make sure the kernel source tree is installed for the kernel version to be built against.

Installing the RDAC Driver

The following procedure describes how to install the RDAC driver for Red Hat RHEL 5, Red Hat Advanced Server 4, and Red Hat SuSE.

• Red Hat RHEL 5 package: rdac-LINUX-09.03.0B05.0042-source.tar.gz
• Red Hat Advanced Server 4 package: rdac-LINUX-09.03.0C02.0042-source.tar.gz

1. Unpack the source code using the tar command:

where xx.xx.xxxx.xxxx is the RDAC version you downloaded.

The files are copied to the linuxrdac-xx.xx.xx.xx directory.

2. Change to the directory containing the unpacked files. For example,

3. Remove any earlier version drivers that are in this directory by running the makeclean command:

4. Compile all driver modules and utilities by running the make command:

5. Uninstall any existing RDAC drivers using the makeuninstall command:

6. Install the new RDAC driver using the makeinstall command. This command:

• Copies the driver modules to the kernel module tree.
• Builds the new RAMdisk image (mpp-‘uname -r‘.img) which includes the RDAC driver modules and all driver modules that are needed at boot time.

7. Type yes when you are prompted to continue:

8. Follow the on-screen instructions to modify the grub.conf file. Change the module and initrd names as follows:

The content of the grub.conf file looks similar to the following. (The revised module and initrd names are shown in bold text.)

9. Reboot the Linux server.

10. After the server is rebooted, log in and verify the driver stack is properly loaded using the lsmod command. The driver stack for Red Hat and SuSE platforms are as follows:

• Red Hat platforms--scsi_mod, sd_mod, sg, mppUpper, mppVhba, and base level HBA drivers (for example, qla2xxx, qla2300) are loaded.
• SuSE platforms--sg, mppUpper, mppVhba, and base level HBA drivers (for example, qla2xxx, qla2300) are loaded.

11. Verify the content of the modprobe.conf.mppappend file:

12. Verify the RDAC driver discovered the available physical LUNs and created virtual LUNs by typing the following command:

13. Verify all drivers are running.

14. Verify RDAC is configured with the MPP drivers.

15. Verify the disk devices are mapped from the array to the host, as follows:

• Check the array mappings in Common Array Manager, to ensure that you have mapped a volume on the array to the Linux host.
• Use the /usr/sbin/mppUtil-a<array_name_in_CAM> command to get a report on how many devices can be seen by the MPP driver (see Multipath Failover Driver Utilities).
• View the /proc/scsi/mpp file for array devices.
• View /proc/scsi/<base_hba_driver_name>/[0-9|a-z], for information about what devices can be seen.

See TABLE 1 for a list of HBA base driver names. The files in this directory are labeled 0 through 9 or A through Z. Each file represents a port on the HBA, which includes World Wide Names of storage devices and LUNs reported.

Multipath Failover Driver Utilities

The MPP RDAC driver installation creates three utilities for your use:

• mppUtil
• lsvdev
• mppSupport

mppUtil Utility

The mppUtil utility is a general purpose command-line driven utility that works only with MPP-based RDAC solutions. The utility instructs RDAC to perform various maintenance tasks, but you can also use the utility to troubleshoot failover problems.

To use the mppUtil utility, type this command and press enter.

mppUtil [-a target_name] [-c wwn_file_name] [-d debug_level] [-e error_level] [-g virtual_target_id] [-I host_num] [-o feature_action_name
[=value][, SaveSettings]][-s 'failback' | 'avt' | 'busscan' | 'forcerebalance'] [-S] [-U][-V]

The mppUtil utility is a cross-platform tool. Some parameters might not have a meaning in a particular operating system environment. A description of each parameter follows.

lsdev Utility

The lsdev utility provides a map of your array LUNs to their Linux block devices. To use the lsdev utility, type this command and press enter.

# /opt/mpp/lsdev

For example:

/usr/sbin # /opt/mpp/lsvdev

mppSupport Utility

The mppSupport utility provides information about your system, array connection, and configuration for Sun Services to assist you with any problems you might have.

To use the mppSupport utility, type this command and press enter.

# /opt/mppSupport

The collected support data is saved in the file:

/tmp/mppSupportdata_myhost_<RDACversion>_<dateandtime>.tar.gz

Linux RDAC Configuration Settings

The RDAC driver contains configuration settings that can modify the behavior of the driver. Any changes to the settings take effect on the next reboot of the host. The default values listed here are the platform-independent settings. Many of these values are overridden by the failover installer for Linux. For Linux, the configuration settings are located in the /etc/mpp.conf file.

After you change a configuration value, you must run the mppUpdate utility and reboot your Linux server for the change to take effect.

Wait Time Settings

When the failover driver receives an I/O request for the first time, the failover driver logs timestamp information for the request. If a request returns an error and the failover driver decides to retry the request, the current time is compared with the original timestamp information. Depending on the error and the amount of time that has elapsed, the request is retried to the current owning controller for the LUN or a failover is performed and the request sent to the alternate controller. This process is known as a 'Wait Time.'

The configuration settings can be found in the /etc/mpp.conf file.

Updating the initrd Image

1. After you change a configuration value, run the mppUpdate utility and reboot the Linux server for the change to take effect. An MPP initrd image is created, as shown in the following example:

2. Reboot the host server:

Troubleshooting Linux RDAC Drivers

How do I get logs from RDAC in the Linux OS?

Use the mppSupport command to obtain several logs related to RDAC. The mppSupport command is found in the /opt/mpp/mppSupport directory. The command creates a file named mppSupportdata_hostname_RDAC version_datetime.tar.gz in the /tmp directory.

How does persistent naming work?

The Linux OS SCSI device names can change when the host system restarts. Use a utility, such as devlabel, to create user-defined device names that will map devices based on a unique identifier. The udev method is the preferred method for SLES10 and RHEL 5.

What must I do after applying a kernel update?

After you apply the kernel update and start the new kernel, perform these steps to build the RDAC Initial Ram Disk image (initrd image) for the new kernel:

1. Change the directory to the Linux RDAC source code directory.

2. Type the following command, and press Enter.

make uninstall

3. Reinstall RDAC.

What is the Initial Ram Disk Image (initrd image), and how do I create a new initrd image?

The initrd image is automatically created when the driver is installed by using the make install command. The boot loader configuration file must have an entry for this newly created image.

The initrd image is located in the boot partition. The file is named mpp-uname -r.img.

For a driver update, if the system already has a previous entry for RDAC, the system administrator must modify the existing RDAC entry in the boot loader configuration file. In most of the cases, no change is required if the kernel version is the same.

To create a new initrd image, type the following command and press Enter.

# mppUpdate

The old image file is overwritten with the new image file.

If third-party drivers are needed to be added to the initrd image, change the /etc/sysconfig/kernel file (SuSE) with the third-party driver entries. Run the mppUpdate command again to create a new initrd image.

How can I see if volumes have been added?

Run hot_add -s or hot_add to add the newly mapped volumes.

How do I remove unmapped or disconnected devices from the existing host?

Run hot_add -d to remove all unmapped or disconnected devices.

What if I remap a LUN from the storage array?

Run hot_add -u to update the host with the changed LUN mapping.

What if I change the size of the LUN on the storage array?

Run hot_add -c to change the size of the LUN on the host.

How do I make sure that RDAC finds the available storage arrays?

To make sure that the RDAC driver has found the available storage arrays and created virtual storage arrays for them, type the following commands, and press Enter after each command.

# ls -lR /proc/mpp

# mppUtil -a

# /opt/mpp/lsvdev

To show all attached and discovered volumes, type the following command and press Enter.

# cat /proc/scsi/scsi

What must I do if I receive this message?

Drivers Mpp Port Devices Replicator

The path failover drivers that cause this warning are the RDAC drivers on Linux. The storage array user label is used for storage system-to-virtual target ID binding in the RDAC driver. For the Linux OS, change the following file to add the storage array user label and its virtual target ID.

Determining if a Path Failed

With the failover driver, two cases determine if a path has failed:

• A path to a controller has failed, but the driver has other paths to the same controller that it can use. This situation causes a degraded condition and must be corrected before the controller can switch to an alternate path.

An entry is made in the OS system log that shows that the failover driver has detected a path failure. CAM does not generate an alarm because no internal problems exist for the array.

• All of the paths to a controller have failed, or the controller itself has failed, and the other controller is now used to service the I/O.

CAM generates the “Volume Not on Preferred Path' alarm for all volumes affected by this scenario. If the array administrator has configured notifications in CAM, the administrator will receive email from CAM or a configured SNMP server. You also have the option of opening a service request using the Auto Service Request (ASR) feature of CAM. The resultant message and alarm will provide information about the fault, along with possible recovery instructions.

Error Levels

The failover driver has five error levels for messages that are logged to the Linux OS error log:

• Fatal errors
• Controller failover events
• Path failover events
• Retry errors
• Recovered errors

Fatal Errors

TABLE 5 lists the possible Linux OS fatal driver errors.

Controller and Path Failover Events

The following items are examples of failover driver controller events and path failover events:

• Change of AVT setting detected
• Failover command issued
• AVT failover invoked
• Path failure detected

Copyright © 2009 Sun Microsystems, Inc. All rights reserved.

Non-WeMo device extension app for Automation Manager.

MppDevices is an adapter (proxy) that would run on your WemoServer device, adapting devices other than WeMos to work with WemoManager. It can also be used on your phone if you don't use the WemoServer.

Available on play for a small charge to avoid non-AutomationManager customers from trying it and leaving a bad review when it doesn't work for them, and to help fund new device integration.

The downloadable version on this page can be used to test with Web, Tasker, and Automagic integration before purchasing a license for the maintained version.

Security Advice!!! There are many new and inexpensive IoT automation devices available. Note that these devices only connect to a 'cloud' server to give you easy setup and remote access.

Do you know where these cloud servers are located or who can access them? Neither do I...

But you can use MppDevices to control them rather than the cloud enabled apps, and you can automation them and provide remote access using YOUR OWN server using AutomationManager. Then for complete security you can disable remote access and lock them out with your router firewall.

Currently supported device types are:

• Orvibo Smart Switches
• When using the Orvibo devices they must be on the same network segment as MppDevices or you will need to route multicast 255.255.255.255 between segments.
• TP-Link switches and bulbs are now supported natively in AutomationManager/WemoHome.
• Usr Iot/Lonhand devices available on ebay for about 1/2 the cost of a Wemo socket.They are available for multiple country power standards including Europe. I wouldn't want to access them through a cloud based in Asia, but you can deny the devices access to the internet and control them using WemoManager and WemoServer.
• TinyOS based Lazybones relay switches from TinySine. Don't bother. There are cheaper and easier to use devices available.
• Custom devices built using Tasker or Automagic
  • Intercept MppDevices standard android intents and implement the interface in Tasker. Use the 'Copy Intents' menu for the device to copy/paste the MppDevice intents to your Tasker/Automagic implementation.
  • Extras as needed: state (boolean), value (float), udn (string), name (string), time (int)
• Custom devices built using a web (REST-like) interface
  • NOTE: you can now use the MppDevices REST interface for native AutomationManager support rather than using this interface through the MppDevices app.
  • Customize the HTTP calls made by MppDevices to your mini-web server running your device. Details are provided in app. Specify a GET url for MppServer to fetch the current state or value (for analog devices) and a PUT url (for switch state changes). On the GET return a JSON body with state or a float value (for analog sensors).
  • Optionally report state changes back to the MppDevices web server with a PUT to ..:8898/report/udnString?state=xxxx or ?value=fffff
  • with either
  • state is true or false
  • value is a float
• DTMF devices - plays a tone. Currently handy for testing but will be more useful in the future.
• Phone information, for use with battery minders
  • BatteryLevel (analog sensor, value - battery charge level)
  • BatteryHealth (sensor, 'on' if battery is healthy)
  • ChargingWireless, ChargingAC, ChargingUSB (sensor)
  • Charged (sensor, on when battery fully charged)
• Notification - display a notification to your phone
• Custom (low end) android phones driving relays. Some assembly required. The phones adapt them to wifi/AutomationManager via MppDevices for a very low cost

The 'Discoverable' checkbox controls whether each device will be visible to your WemoManager/WemoServer.

Drivers Mpp Port Devices Download

AutomationServer

Typically you will install MppDevices on the same android device you use for running your AutomationServer. You need at least one device defined before MppDevices will respond. Use a DTMF device (on/off sounds a tone on the phone/tablet) as it's handy for testing.

When installed on the same device as your WemoServer use the 'search' menu button and select 'Find new Wemos' whenever you add a new MppDevice, though usually they will be discovered automatically by the WemoServer with no search action.

The AutomationServer uses its REST port for incoming notifications of state changes from MppDevices. The WemoServer REST server must be enabled and operating on the default port 4030 (confirm that the indicator on the AutomationServer widget is green).

AutomationManager

When you are not using the AutomationServer at all you need to install MppDevices on each handset using AutomationManager, and you will need to add the custom devices to each instance. Discovery of your configured devices should be automatic.

If the MppDevices server is installed on a different (dedicated) device, use the 'search' menu 'Find MppDevices' action in WemoServer to find it. Point it to your MppServer IP on port 8898.

AutomationRemote

Drivers Mpp Port Devices Usb

When you're using AutomationRemote with a AutomationServer your custom MppDevices will show up automatically in AutomationRemote once you have configured the AutomationServer/MppDevices pair.