I've seen a fair bit of traffic recently about gigabit ethernet and hipersocket problems (and eventual solutions). After having great success on our 2064 we've recently updated drivers and microcode. Now the successes have been replaced by abject failures. We're attempting to get a hipersocket connection going. The VM TCP/IP stack is able to start its device without a problem but the Linux (2.4.7) is having a bit of a problem. Apart from the usual bitch about no source code from which to trace the problem or any messages manual that can help us deciper: "There were problems in hard-setting up the card", here's the log:
> insmod qdio Using /lib/modules/2.4.7-SuSE-SMP/misc/qdio.o qdio: loading QDIO base support version 2 ($Revision: 1.78.2.4 $/$Revision: 1.44 .2.1 $) debug: qdio_setup: new level 2 debug: qdio_labs: new level 2 debug: qdio_sense: new level 2 debug: qdio_trace: new level 2 > insmod qeth Using /lib/modules/2.4.7-SuSE-SMP/net/qeth.o qeth: loading qeth S/390 OSA-Express driver ($Revision: 1.136.2.3 $/$Revision: 1 .53.2.2 $/$Revision: 1.18 $) qeth: allocated 0 spare buffers debug: qeth_setup: new level 3 debug: qeth_misc: new level 2 debug: qeth_data: new level 2 debug: qeth_control: new level 2 debug: qeth_sense: new level 2 debug: qeth_qerr: new level 2 debug: qeth_trace: new level 2 qeth: Trying to use card with devnos 0x1000/0x1001/0x1002 qeth: There were problems in hard-setting up the card. debug: unregistering qeth_setup debug: unregistering qeth_qerr debug: unregistering qeth_sense debug: unregistering qeth_misc debug: unregistering qeth_data debug: unregistering qeth_control debug: unregistering qeth_trace /lib/modules/2.4.7-SuSE-SMP/net/qeth.o: init_module: No such device Hint: insmod errors can be caused by incorrect module parameters, including invlid IO or IRQ parameters Here's the /etc/chandev.conf: noauto ctc0,0xe000,0xe001,0,0 qeth-1,0x1000,0x1001,0x1002,0,0 add_parms,0x10,0x1000,0x1002,portname:IUTIQDD0 And here's the /etc/modules.conf: alias hsi0 qeth
