 |
≫ |
|
|
|
| HUBの Linkランプが点灯し続けるが？ |
|
|
| |
サーバ本体の電源を落としても ACケーブルが接続されていれば Ethernetコントローラが
WOL(wakeup-on LAN)機能を搭載している場合、Ethernet HUBの Link LEDは点灯し続けます。 |
|
| 25-MAY-2000 |
| チーミング切替えが遅いが？ |
|
|
| |
チーミングドライバに bondingを利用、Ethernet I/Fを 3本利用、且つ集線先が switching HUB/bridgeの場合、クライアントから見た場合の切り替え時間が数十秒掛かる場合があります。下記の例の様にオプションを付与することで bridgeが保持する MAC addressをクリアさせ再接続時間の短縮化が可能です。
|
#vi /etc/modules.conf
alias bond0 bonding
options bond0 miimon=100 mode=1 arp_interval=1000 arp_ip_target=192.168.1.73
⇒ 共に単位は ms |
HUB/repeaterを利用する場合、もしくは baspドライバを利用する場合、本現象は発生しません。
[30-MAY-03] bonding v1.0.2-6HPでは miimonと arp_intervalが同時に利用できなくなったため、この方法は利用できなくなりました。HUB/bridge側の table expiration等のタイミング調整を行ってください。 |
|
| revised 30-MAY-2003 |
| ビルドに失敗するが？ |
|
|
| |
Red Hat, Miracleの場合、#make oldconfig, #make depを行っただけの状態だと、kernel環境と NICドライバの組み合わせによっては正常にビルドできない場合があります。この場合、`KERNELRELEASE`を指定してください。
|
cd /usr/src/linux-2.4
#make mrproper
#make -e KERNELRELEASE=`uname -r` oldconfig
#make -e KERNELRELEASE=`uname -r` dep |
|
|
| 24-JUN-2003 |
| チーミング時 gatewayが設定されないが？ |
|
|
| |
bondingが MAC addressの設定に失敗しているために発生しています。/etc/sysconfig/network-scripts/ifcfg-bond0に
'MACADDR'として直接 eth0のものを指定することで回避できます。
|
DEVICE=bond0
USERCTL=no
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.1.10
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
GATEWAY=192.168.1.254
MACADDR=xx:xx:xx:xx:xx:xx |
技術的には、ifenslaveが master deviceへ slave deviceを attachする時、master deviceの MAC addressを見て
"00:00:00:00:00:00"(ifcfg-bind0へMACADDRを指定していない場合)であれば、一度、master deviceを
downさせ、slave deviceから MAC addressを取得したあと、master deviceを upさせます。
master deviceが downすると、ルーティングテーブルが flushされ、ifup bond0で設定された default gatewayが消えてしまいます。その後、ifup
ethX(ifenslave bond0 ethX)で slave deviceが upされても default gatewayを設定する処理が skipされる(これは
ifupスクリプトの仕様)ため、結果的に default gatewayが消えているということになります。
従って、回避方法としては MACADDRを設定するか、最後に default gatewayを設定するスクリプトを作成する方法を取る必要があります。
なお、この現象は bonding driver moduleが kernelへ 最初にロードされた時にのみ発生します。いったん ifenslaveで master
deviceへ slave deviceの MAC addressが設定されてしまうと、kernel内の NIC情報として設定された MAC addressを保持してしまう(ifcfg-bond0でMACADDRが設定されている状態になる)ため、bonding
driver moduleをリロードするまで現象は発生しません。詳細は、 Ethernetについての技術情報をご覧ください。
この問題は、利用する NIC driverの種類に関係なく bondingの v1.0.4m-1迄の全てのバージョンで発生することを確認しています。但し、bonding
v1.0.4o-1では、bondingドライバ自体の機能修正により、default gatewayが設定される様になりました。
|
|
| revised 22-NOV-2004 |
| バッククォートが打てないが？ |
|
|
| |
昨今の Red Hat等で Ethernetモジュールをビルドする際に必要な作業、#make -e KERNELRELEASE=`uname -r` oldconfig(もしくは dep)の `の入力を間違っても oldconfigや depは通ってしまいます(もちろん NICモジュールの buildは失敗します)。
ここでの `はクォートではなく、バッククォートです。日本語キーボードの場合、[Shift]+[@]で入力できます。インストール時やリカバリー時で、キーマップが合致していない等の状況で入力が困難な場合には、`uname -r`の部分には #uname -rで表示される値をそのまま入力してください。これは、Ethernetのモジュールがビルドに失敗するものの内で、一番陥りやすいミスです。 |
|
| 20-AUG-2003 |
| bondingで primaryオプションを指定するとシステムが起動しなくなるが？ |
|
|
| |
bonding v1.0.3-3と bcm5700 v6.0.2dの組み合わせにおいて primaryオプションを指定した場合にシステムが起動できなくなる可能性があります。bonding v1.0.3-12HPと bcm5700 v6.2.11a以降をお使いください。 |
|
| 07-NOV-2003 |
| bondingの各モードの特徴は？ |
|
|
| |
| round-robin: |
|
送信に関してはslave deviceの中で有効なデバイスの中の１つから送信されます。
受信に関しては負荷分散が行われます。 |
| active-backup: |
|
slave deviceの中から１つだけが有効になります。
一般的にこのモードは２つのハブを使いhigh availabilityを実現するときに使用されます。 |
| balance-xor: |
|
転送先のMACアドレスに対して一定のslave deviceが割り当てられます。 |
| broadcast: |
|
すべてのslave device上で転送を行います。 |
|
|
| 11-NOV-2003 |
| bondingで NIC障害後も ＭＡＣアドレスを同じにしたいが？ |
|
|
| |
/etc/sysconfig/network-script/ifcfg-bond0のファイルの中で下記の様に staticに MACアドレスを指定してください。
|
MACADDR=00:11:22:33:44:55 |
|
|
| 28-NOV-2003 revised 11-OCT-2007 |
| bondingの active-backupモードで障害発生時の動作は？ |
|
|
| |
active-backupモードで運用中に activeの NICに障害が発生すると backupの slave deviceが activeになりますが、障害が復旧してもモードは切り替わりません。すなわち、最初 backupだった salve deviceが activeのまま運用が続きます。
但し、 primaryオプションを指定されている場合には primaryオプションが指定された slave deviceが復旧した時にその slave deviceが activeとなります。 |
|
| 01-DEC-2003 |
| bonding利用時にNICモジュールのロード順序が入れ替わってしまうが？ |
|
|
| |
master deviceが複数の異なるNICのslave deviceで構成されている時、NICモジュールのロード順序が入れ替わってしまう場合があります。これは、インターフェイスを適切な順序でアップ(およびenslave)することで回避可能です。詳細は異なる複数のNICドライバでbondingドライバを利用する例をご覧ください。 |
|
| 11-MAY-2004 |
| initscriptsのバージョンによってネットワークの動きが異なるが？ |
|
|
| |
ネットワーク環境は initscriptsの機能に大きく影響を受けます。initscriptsのバージョン
によっては bonding利用時に gatewayを設定するには MACADDRを指定する必要があったり、ifupスクリプトが再起的にコールされる事が原因で
bondingの slave deviceへ IPが設定されない等の問題が発生します。これらの問題は一見 bondingドライバの問題に見えます。
HPでは適時 NICドライバと付随する他のドライバを組み合わせた問題をレポートしていきます。詳細は、Ethernetについての技術情報をご覧ください。 |
|
| revised 22-NOV-2004 |
| bondingの設定が反映されないが？ |
|
|
| |
bonding driverのオプション(/etc/modules.conf)を変更した場合、単にネットワークを再起動(/etc/init.d/network restart等)しただけではロードされているbonding driverに設定が反映されず、以前の設定のままでbonding driverが動作し続けます。このような事態を防止するため、/etc/modules.confを変更したら、必ずrebootするか、bonding driverと下位 driver一式をアンロード(#/etc/init.d/network stop;rmmod bonding;rmmod bcm5700(もしくは e100/e1000); /etc/init.d/network start)して最新の設定を反映させてください。 |
|
| 01-SEP-2004 |
| NICの割当てを固定したいが？ |
|
|
| |
/etc/mactabでの指定、ifcfg-ethxでの HWADDR指定、#nameifでの指定等を行う事で、特定の NICを
eth0等へ固定する方法があります。但し、これらの方法を利用した場合、ネットワーク環境への影響が及ぶ場合がありますので利用される場合には慎重に動作確認を行う必要があります。特に、複数の
NICドライバを利用する環境で bondingを利用する場合には、インターフェースの消失等の影響が発生します。ちなみに /etc/mactabで記述しただけでは
Red Hat EL2.1, EL3(initscriptが更新されている U3でも)等では実際に配置を固定する事はできません。
[22-AUG-2007] 昨今の状況として、SLES10等では積極的に MAC addressを利用したデバイスの固定化を行っているディストリもあります。また、bonding等でのインターフェースの消失は昨今発生しなくなっています。 |
|
| 08-DEC-2004, revised 22-AUG-2007 |
| e1000と bondingを組み合わせると
linkが up/downを繰り返すが？ |
|
|
| |
/var/log/messagesには下記のメッセージが交互に繰り返して記録される事があります。このメッセージが対になって連続で現れる場合、実際には linkは消失せずにメッセージが誤って表示されているだけですので無視してください。
|
kernel: bonding: bond0:
link status definitely down for interface eth0, disabling it
kernel: bonding: bond0: link status definitely up for interface eth0 |
この問題は e1000と bondingの MII監視モードを組み合わせた状況で、下記の動作のどちらかがあった場合に発生します。
- ethtoolのような ioctl()を発行するアプリケーションが e1000 driverから情報を取得する
- /proc/net/devを連続で readする
この問題は将来の e1000ドライバで解決される予定です。現時点では bondingを MII監視モードではなく arp監視モードにする事で防げます。
また bondingの use_carrierオプションを '1'にする事でも回避が可能ですが、hpが提供する bondingに於いては(現時点で v1.0.4t)この機能は装備されていません。ディストリビューションに標準搭載されている
bondingを利用される場合にのみこの方法での回避が有効です。
[11-OCT-2005] この問題は e1000 v6.1.10b-1にて解決しています。 |
|
| 07-JUN-2005, revised 13-DEC-2005 |
| サーバー直結のARP監視 bonding interface(active-backup)は必ず
degradeになるが？ |
|
|
| |
active-backupモードで動作する bonding interfaceを図のようにサーバー直結(クロスケーブルで接続)で構成した場合、ARP監視モードでは、link
upする slave interafceは必ず1つだけになる(他の slave interfaceは必ず link down)ので、Insight Management
Agentでの bonding interface statusは必ず"劣化(degrade)" になってしまいます。但し、MII監視モードでは、全ての
slave interfaceが link upするので "劣化(degrade)" になりません。
ARP監視モードでの link up/downは slave interfaceの"最後のpacket受信時刻"で判定します。ARP監視
active-backupモードでは、active slave interfaceが送信する arp request packetを slave interfaceが受信することで
link upとみなします。サーバー直結の場合、active interfaceが送信した arp request packetが相手側の1つの slave
interafceにしか届かないため、残りの slave interface が全て link downになってしまいます。なお、switchに全ての slave
interafceが接続されている場合、switchが arp request packetを activeな全 portへ broadcastするため問題ありません。
基本的に active-backupモードは slave interfaceを switching HUBに接続する構成をお勧めしますが、サーバー直結で使う場合は、bonding
interfaceを MII監視モードにするか、active-backupモードではなく round-robinモードで構成してください。 |
|
| 05-JUL-2005 |
| EL3で
bonding, vlanドライバはどれを使えばいいのか？ |
|
|
| |
HPは EL3上で bonding, vlanドライバを安定利用させるために、これらのドライバを提供してきましたが、最近のドライバ安定状況を鑑みて PSP7.51以降では kernel 2.4.21-37.0.1以降の環境に於いては、導入しない形態に変更しました。また、kernel環境に関係なく
bondingと vlanドライバを併用する場合には EL3標準搭載のドライバを利用する必要が生じます。詳細はbondingドライバとvlanドライバの構成例をご覧ください。
|
|
| 30-AUG-2006 |
| 起動ログで ethXの link upが遅いがハードウェアの問題か？ |
|
|
| |
これはハードウェアの問題ではなく、Linuxの仕様になります。/var/log/messagesに記録される
Bringin...表示から Link is Upまで 30秒程度の差が出る場合がありますが、これは processや kernelからの logに記録される迄の時間差によるもので、実際には
30秒よりも早い段階(数秒程度)で link upしています。Bringing...メッセージは、/etc/rc.d/init.d/networkから直接
syslogdに渡されますが、kernel landから発行される NICドライバからのメッセージは一旦 ring bufferに入り、klogdが syslogdに引き渡した後
/var/log/messagesに記録され、記録される時刻は実際にイベントが発生した時刻ではなく、syslogdが klogdから受け取ったものとなります。このため、システムの起動等の様に多重の処理が行われている場合、ログ上での時刻の遅延が見られる事になります。試しに
klogdのサービスを停止した状態でシステムを起動し、起動が終わってから klogdを起動すると /var/log/messages上に記録される kernel
landからのメッセージは全て klogdを手動起動した時刻になる事が分かります。 |
|
| 19-MAR-2007 |
| eth1が
eth0より 2割程遅いが？ |
|
|
| |
bcm5700ドライバを利用した場合 2ポート目以降の controllerに対しての初期設定で TSO(TCP segmentation offload)機能を有効にします。この機能が有効になっている場合
iperfツール等を利用して計測すると eth0が 930Mbps程度の速度が出るのに対して eth1では 800Mbps程度の値になります。ethtoolを利用して
eth1側の TSO機能を無効にする事でこの現象は回避可能です。TSOの状況確認と設定変更は下記で行えます。
|
#cat /proc/net/nicinfo/eth1.info
| grep TSO
TSO on
#vi /etc/modprobe.conf
alias eth0 bcm5700
alias eth1 bcm5700
options bcm5700 enable_tso=0,0
#cat /proc/net/nicinfo/eth1.info
| grep TSO
TSO off
|
この現象は RHEL4/U4(x86)と bcm5700 v8.3.17bの組み合わせで確認しておりますが、他の環境でも発生すると思われます。
なお、初期化時に全てのポートの
TSOを無効にする tg3ドライバの場合、この問題は発生しません。また、現在 bcm5700は既にメンテナンスが終了しており、後継ドライバとして tg3がリリースされていますのでこちらを利用される事を推奨いたします。 |
|
| 30-MAR-2007 |
| NICポートが逆転しているが？ |
|
|
| |
Ethernetの NICポートが逆転する原因としては、firmware側での MAC addressの配置と ACPI table上での配置の違い、x86 kernelと x86_64 kernelでの違い(RHEL3)、kernelのスキャン方法自体のアルゴリズム変更(RHEL4/U5)、インストーラの問題(beta版インストーラ等で eth0が eth12になったり)等と、多岐に渡りますので、このシステムではこの配置になる…等、予め NICポートがどこに割り当てられるかを特定するのはかなり困難です。
このためインストール後にどの NIC portが eth0にアサインされるのかは実際の環境で試さなければならない事になります。これを避けるには /etc/sysconfig/network-scripts/ifcfg-eth0等で HWADDR=として直接インターフェースの固定化を行うのが有効です。 |
|
| 22-AUG-2007 |
| NAPIとは？ |
|
|
| |
ネットワークの処理速度向上のための仕組みで New APIから NAPIと呼ばれます。Ethernetの速度向上に伴い、割り込み処理を行うためのシステム負荷が非常に高くなってきています。従来システムはネットワーク関連の処理は NIC側からのハードウェア割り込みを受けて、都度優先的に処理を行ってきました。例えば 10Gigabit Ethernet用ドライバが 1500byteのパケット毎に割り込みを発生させる場合、一秒間の割り込み回数は 80万回を超える事となり、この処理だけで CPUは殆どの時間を費やしてしまう事になります。これを改善するために割り込み処理が高い状況においては 10ms程度の割り込みを停止し、後から CPU側から NIC上の DMA ring buffer上のパケットをまとめて取りにいきます。 |
|
| 16-JAN-2008 |
| DHCPで IPが取れない場合があるが？ |
|
|
| |
DHCPを利用している場合、システム起動時に IPの取得に失敗する場合があります。この現象を防ぐには /etc/sysconfig/network-scripts/ifcfg-eth0の最後に下記のどちらかを追加し、link downしていると認識させない事で防げます。但し、LINKDELAY patch(それも本問題に関する)の適用が行われているのを確認できたのは RHEL5.0以降だけです。RHEL4.6等の patch未適用のディストリビューションでは、check_link_downの方法を利用してください。 ちなみに、LINKDELAY=で指定する値の単位は、秒になります。この値は適時調整してください。
|
check_link_down ( ) {
return 1;
} |
|
LINKDELAY=30 |
この現象は NICの初期化スクリプトに起因する問題で、ProLiantや特定のディストリビューションに特化したものではなく広く発生する可能性があります。 |
|
| 27-MAR-2008, revised 02-MAY-2008 |
| ethtoolで速度が Unknownになるが？ |
|
|
| |
ethtoolが version 6未満の場合、#ethtoll eth0等で表示される速度表示は 1Gbpsを超える速度は表示に Unknownが付与されます。また、3.4Gbps等の様な c-Classの Flex10による速度分割をした速度の場合にも `Speed: Unknown! (3400)`と云う表示となります。 |
|
| 01-DEC-2008 |
| Virtual Connectだと bondingが切り替わらないが？ |
|
|
| |
c-Classブレード用 Virtual Connectと e1000ドライバを組み合わせた構成の場合、NICの link up/downが正常検知できないため、bondingが正常に切り替わりません。この問題は bondingの mode=6を利用しても回避できません。現状に於いては Broadcom系 NICを利用してください。状況が変わりましたら、本サイトの What's Newで案内させて頂きます。
[10-DEC-2008] e1000 v7.6.14a-1で修正されました。 |
|
| 10-DEC-2008, revised 30-JUN-2010 |
| bnx2xドライバで ethXはいくつまで作成可能か？ |
|
|
| |
通常、vmallocメモリの関係で x86環境の場合、パーティション数は 11迄しか作成できません。HPはパフォーマンスの観点から x86, x86_64共に 8ヶ迄の利用を推奨します。8を超えて利用される場合は `vmalloc=512M uppermem=512M`等として kernelパラメータを引き渡す事で利用が可能となります。詳細は bnx2xドライバの技術情報をご覧ください。 |
|
| 03-JUL-2009 |
| e1000と e1000eドライバの違いは？ |
|
|
| |
PCI-Express対応 NIC用ドライバが e1000eで、PCI-X対応 NIC用ドライバが e1000になります。但し、HPから提供していた e1000ドライバは互換性のためにしばらくの間 e1000ドライバで PCI-Expressデバイスのサポートを行っていました。PSPでは v8.20から e1000e v0.4.1.12-1が同梱され始めています。 |
|
| 08-OCT-2009 |
| NICの持つ offload機能を確認する方法は？ |
|
|
| |
#ethtool -k eth0とする事で、Ethernetコントローラがハードウェア的に処理を行う機能の状況が表示されます。 |
|
| 13-NOV-2009 |
| 最近の NICドライバのビルドが難しいが？ |
|
|
| |
最近は NICドライバの制限事項(必ず xen kernelであっても kernel-develが必要だったり、--target, --defineの指定が必要等)が多岐に渡る事が多くなり、単純に #rpmbuild -bbだけではビルドが出来ない事が少なくありません。ドライバに添付されている readme等に詳細なビルド方法や特定のディストリビューションでの制限事項等が記載されています。これらをもとに PSPの SUMインストーラがビルド方法の手順をディストリビューション毎に記載しているファイルがあります。これは PSP8.40以降に添付される RPMBuildInstructions.xml(PSP8.41より)となります。例えば、RHEL5/x86-PAE上で e1000eドライバをビルドする方法としては、208行目を参考とする事で、下記のコマンドでビルドできる事がわかります。
|
#rpmbuild -bb /usr/src/redhat/SPECS/hp-e1000e.spec --target=i686╲
--define "KVER=2.6.18-194.el5PAE"
|
ちなみにこの環境では PAE kernelであっても UNI/SMP用 alternative kernel用の kernel-develが導入されている必要があります(e1000eの readmeの CAVEATSセクションに記載されています)。この様に個別の制限事項を考慮する必要がありますので、readmeファイルには目を通す必要がありますが、RPMBuildInstructions.xmlは分かりやすいのでこちらも参考になる筈です。
|
|
| 13-JUL-2010, revised 25-MAY-2012 |
| nx_nicドライバーがロードされないが？ |
|
PSPで提供される nx_nicドライバーパッケージをインストールしても、ディストリビューション標準の netxen_nicドライバから nx_nicに切り替えが正常に行われない場合があります。PSP8.20以降で確認されている環境、現象及び対処方法は下記の通りです。
|
|
| <RHEL5の場合> |
|
・PSP8.40及び 8.41で提供される nx_nicドライバーパッケージ |
|
| 現象：nx_nicドライバーパッケージをインストールしても、RHEL5標準の netxen_nicドライバーが使用される。 |
| 対処方法：/etc/modprobe.d/blacklistに「blacklist netxen_nic」を追加 |
|
|
| <RHEL4の場合> |
|
・PSP8.20、8.25及び 8.26で提供される nx_nicドライバーパッケージ |
|
| 現象：nx_nicドライバーパッケージをインストールしても、RHEL4標準の netxen_nicドライバーが使用される |
| 対処方法：/etc/modproe.confの aliasを「netxen_nic」から「nx_nic」に変更 |
|
|
| <SLES10の場合> |
|
・PSP8.20、8.25及び 8.40で提供される nx_nicドライバーパッケージ |
|
| 現象：nx_nicドライバーパッケージをインストールしても、SLES10標準の netxen_nicドライバーが使用される |
| 対処方法：YaST2で NICに割り当てるドライバーを「netxen_nic」から「nx_nic」に変更 |
|
|
|
・PSP8.30、8.31、8.50、8.60、8.70及び8.71で提供される nx_nicドライバーパッケージ |
|
| 現象：nx_nicドライバーパッケージをインストールすると、ドライバーがロードされなくなる |
| 対処方法：YaST2で NICに割り当てるドライバーを「netxen_nic」から「nx_nic」に変更 |
|
|
| <SLES11の場合> |
|
・PSP 8.40で提供されるnx_nicドライバーパッケージ |
|
| 現象：nx_nicドライバーパッケージをインストールしても、SLES11標準のnetxen_nicドライバーが使用される |
| 対処方法：YaST2で NICに割り当てるドライバーを「netxen_nic」から「nx_nic」に変更 |
|
|
|
| 30-JUL-2010, revised 24-MAY-2011 |
| HP提供の bnx2iドライバはいつから単体パッケージではなくなったか？ |
|
|
| |
HPが提供する bnx2iドライバは PSPの v8.40から hp-netxtreme2パッケージに統合されました。ちなみに、パッケージ内には SLES11用の別バージョンが同梱されています。 |
|
| 04-OCT-2010 |
| HP提供の bnx2, bnx2xのドライババージョンをインスト前に知るには？ |
|
|
| |
HPが提供する bnx2, bnx2xドライバはかつて、それぞれ個別の RPMパッケージでしたので、そのファイル名等からドライババージョンを知る事が可能でした。PSPの v8.20を境にこれらのドライバは 1つの RPMパッケージとして統一され netxtreme2パッケージとなり、PSP v8.40で hp-netxtreme2パッケージとなりました(RHEL4のみ netxtreme2パッケージのまま)。この netxtreme2パッケージ自体のバージョンや、添付されている .txtからは bnx2, bnx2xドライバのバージョンを知る事はできません。この不便さを解消するために、当サイトでは PSPの技術ページの `個別パッケージ - 全ディストリ共通`セクションにドライバのバージョンを記載しておりますのでご参照ください。 |
|
| 05-OCT-2010, revised 13-OCT-2010 |
| bnx2xは MIIに対応している筈なのに mii-toolでは確認できないが？ |
|
|
| |
MIIは Fast Ethernet(100Mbps)の規格に対応したものです。このため 10/100Mbpsをサポートしない bnx2xは mii-toolを利用して MIIの対応を確認しても No MII transceiver Presentと表示(no MII interfaces foundではなく)され MIIの有無の判断はできません。ethtoolコマンドを利用してください。 |
|
| 09-AUG-2011 |
| KMOD対応なのに errataに追従しないが？ |
|
|
| |
HPが提供する NICドライバ等は KMP(KMOD)対応している旨が記載されています(PSP v9.10用 psp-9_10_rhel5_linux.txt)が、この KMODへの対応だけでは errata kernelへの追従は行えません。ディストリ標準の(inbox)ドライバよりも KMOD形態となる link先のドライバを優先利用する指定(override)が別途必要となります。この linkを利用したドライバ更新の仕組みが DUP(driver update program)となります。基本 NICドライバにはこの DUPの override指定が行われていないため、errata kernelへの追従は行えません。詳細はKMOD/overrideとは何か？をご覧ください。 |
|
| 05-JUN-2012, revised 18-OCT-2012 |
| FlexLOMは biosdevname的には何で認識されるのか？ |
|
|
| |
ProLiant Gen8シリーズで利用可能な、FlexLOM対応 NICは物理的には取り外し可能な NICカード形式ですが、RHEL6.2の biosdevnameでは embedded(LOM: Lan on Motherboard)扱いの emXインターフェースとしてアサインされます。LOM 331を搭載した DL380p Gen8に CN1000Q PCI-Eカードを追加した構成での lspciの結果はこちら(biosdev有効, biosdev無効)となります。 |
|
| 20-JUN-2012 |
| KMOD対応 NICドライバが想定しない場所にインストされるが？ |
|
|
KMOD対応 NICドライバはインストールされている kernel-develの一番新しいバージョンを利用してビルドされます。このため kernel関連パッケージの導入状況によっては、インストールしたい kernelに対応した /lib/modules配下に導入されない場合があります。例えば、RHEL6の 2.6.32-220.17.1で稼働しているシステムがあり、近い将来利用する事を踏まえて 2.6.32-220.23.1の kernelと kernel-develも導入している環境の場合、最新の kernel-develである kernel-devel-2.6.32-220.23.1を利用してドライバがビルドされます。ビルドされた RPMパッケージを導入した場合、/lib/modulesの 2.6.32-220.23.1の extra配下にドライバが導入されます。2.6.32-220.17.1に対しては weak-updates配下に先ほどの extra配下のドライバへの linkが貼られます。この場合、RPMパッケージには inboxドライバよりも追加導入したドライバを優先的にロードする override設定ファイルが提供されていないため、2.6.32-220.17.1環境では、inboxドライバがロードされてしまいます。この場合には、kernel-develの一番新しいものが 2.6.32-220.17.1である様にする必要がありますので、2.6.32-220.23.1を一時的にアンインストールする必要があります。
ちなみに、rpmコマンドでのドライバのビルドと導入を行うのではなく、SUMを利用する場合には別のルールもあります。詳細はSUMを使うと NICドライバが errataにあたらないが？を参照してください。 |
|
| 20-AUG-2012, revised 18-OCT-2012 |
| OCSD/AHS Agentとは何か？ |
|
|
Option Card Sensor Data(OCSD)は AHS(Active Health System)エージェントとして、NICの温度情報を取得するためのエージェントです。HPが提供する igbと igbxeドライバ(inboxドライバではなく)では /sys/bus/pci/drivers/igb/0000\:02\:00.0/net/eth0/info/sensor_0/temp等として温度情報が表示されます。OCSDはこの情報を iLO4の WEB I/Fに転送します。詳細は #man ocsbbdをご覧ください。
[09-MAY-2013] manが存在するのは SPP2012.06の RHEL6用サプリメント, SPP2012.08, SPP2012.10に内包された igb v3.4.7.1-1と ixgbe v3.9.17-1だけです。また、SPP2013.02以降は NICドライバから分離され単独パッケージとして提供されています。 |
|
| 04-OCT-2012, revised 13-MAY-2013 |
|
印刷用画面へ
