After upgrading my HP MicroServer with Remote Access Card from Fedora 17 to Fedora 18 (kernel-3.8.3-203.fc18) the RAC KVM console (remote and VGA) stopped to work with ‘out-of-range’ signal after:
[ 4.072580] [drm] Initialized drm 1.1.0 20060810
[ 4.104362] [drm] AST 1100 detected
[ 4.104500] [drm] dram 816000000 1 16 04000000
[ 4.104785] [TTM] Zone kernel: Available graphics memory: 2024944 kiB
[ 4.104913] [TTM] Initializing pool allocator
[ 4.105035] [TTM] Initializing DMA pool allocator
[ 10.522147] [sched_delayed] sched: RT throttling activated
The MicroServer RAC has an AST1100 video controller that currently doesn’t work very well with the Linux KMS (Kernel Mode Setting).
So, to fix this issue you need to disable the KMS for the ast module:
- Edit /etc/sysconfig/grub and at the end of the GRUB_CMDLINE_LINUX line add “ast.modeset=0 nomodeset”
GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=latarcyrheb-sun16 rd.luks=0 KEYTABLE=it LANG=en_US.UTF-8 ast.modeset=0 nomodeset quiet"
- Update the grub2 configuration
grub2-mkconfig -o /boot/grub2/grub.cfg
- Create /etc/modprobe.d/ast.conf with
- Update the initramfs with dracut
The bug has been reported at RedHat Bugzilla bug #926064.
license: GPL and additional rights
author: Dave Airlie
vermagic: 3.8.3-203.fc18.x86_64 SMP mod_unload
parm: modeset:Disable/Enable modesetting (int)
Last week I started working on the @GEMwrld HPC cluster at the Eidgenössische Technische Hochschule Zürich (ETH). The first task was to implement a kind of system monitoring and resource profiling. We already have a centralized graphical web console, built upon Observium, that collect resources statistics from all of our servers; usually we use SNMP v2c and, just for a few cases, the munin-node daemon (more on this will be in the part 2).
On the ETH cluster we have full access to every node, but the only incoming connections allowed by the ETH firewall are the SSH sessions (on port 22), so there’s a first problem: how can we transport SNMP data from the agent to the poller?
The answer is easy: SSH tunnel! But: usually SNMP uses UDP protocol; making an UDP SSH tunnel is a bit painful. To workaround this issue we had simply used the TCP protocol for SNMP.
First of all you need an SSH tunnel. In this case the tunnel is made by the monitoring server:
ssh -N monitoring@serverip -L 16000:localhost:161
The 161 is the remote TCP port to be forwarded and 16000 is the local port.
To use SNMP on TCP you have to modify the net-snmp daemon (snmpd) command line parameters (and not the snmpd config file); just edit /etc/default/snmpd (on ubuntu/debian, for RHEL the path is /etc/sysconfig/snmpd) as following:
SNMPDOPTS='-LF 6 /var/log/snmpd.log -u snmp -g snmp -I -smux -p /var/run/snmpd.pid TCP:161'
The important part is ‘TCP:161’. This will bind snmpd on every interface and on the TCP port 161 (the default SNMP port).
On the poller side you will need to configure your monitoring system to poll localhost:16000 with tcp protocol. For Observium you can add the host with:
./addhost.php localhost community v2c 16000 tcp
Now there’s another problem. The Zurich GEM cluster is made by eight nodes and I do not want to start an SSH tunnel on every node. Then my idea was to use a kind of proxy on the control node:
net-snmp helped me with the snmpd proxy capabilities: http://www.net-snmp.org/wiki/index.php/Snmpd_proxy