Carlos, We have changed the device addresses from E50 to E60 since my first note. I
did a cat /proc/chandev and got the following:
Before the echo commands --
chan_type key bitfield ctc=0x01, escon=0x2, lcs=0x4, osad=0x8, qeth=0x10,claw=0x20
*'s for cu/dev tpe/models indicate don't cares
cautious_auto_detect: on
persist=0x00
use_devno_names: off
Channels enabled for detection
chan cu cu dev dev max checksum use hw auto
recovery
type type model type movel port_no received stats type
=========================================================
0x20 0x3088 0x61 * * 0 no no
not operational, no_path, reavalidate,device_gone
0x08 0x3088 0x62 * * 0 no no
not operational, no_path, reavalidate,device_gone
0x10 0x1731 0x05 0x1732 0x05 0 no no not
operational, no_path, reavalidate,device_gone
0x10 0x1731 0x01 0x1732 0x01 0 no no not
operational, no_path, reavalidate,device_gone
0x04 0x3088 0x60 * * 1 no no
not operational, no_path, reavalidate,device_gone
0x06 0x3088 0x1f * * 15 no no
not operational, no_path, reavalidate,device_gone
0x05 0x3088 0x08 * * 15 no no
not operational, no_path, reavalidate,device_gone
0x04 0x3088 0x01 * * 15 no no
not operational, no_path, reavalidate,device_gone
Channels detected
chan cu cu dev dev
in chandev
irq devno type type model type model pim
chipids use reg
0x0305 0x0fe2 0x06 0x3088 0x1f 0x0000 0x02 0x80 0x13 no
no
0x0306 0x0fe3 0x06 0x3088 0x1f 0x0000 0x02 0x80 0x13 no
no
0x05cd 0x0e60 0x10 0x1731 0x01 0x1732 0x01 0x80 0x00 no
no
0x05cd 0x0e61 0x10 0x1731 0x01 0x1732 0x01 0x80 0x00 no
no
0x05cd 0x0e62 0x10 0x1731 0x01 0x1732 0x01 0x80 0x00 no
no
0x05cd 0x0e63 0x10 0x1731 0x01 0x1732 0x01 0x80 0x00 no
no
0x05cd 0x0e64 0x10 0x1731 0x01 0x1732 0x01 0x80 0x00 no
no
0x05cd 0x0e65 0x10 0x1731 0x01 0x1732 0x01 0x80 0x00 no
no
After the echo commands--
chan_type key bitfield ctc=0x01, escon=0x2, lcs=0x4, osad=0x8, qeth=0x10,claw=0x20
*'s for cu/dev tpe/models indicate don't cares
cautious_auto_detect: on
persist=0x00
use_devno_names: off
Channels enabled for detection
chan cu cu dev dev max checksum use hw auto
recovery
type type model type movel port_no received stats type
=========================================================
0x20 0x3088 0x61 * * 0 no no
not operational, no_path, reavalidate,device_gone
0x08 0x3088 0x62 * * 0 no no
not operational, no_path, reavalidate,device_gone
0x10 0x1731 0x05 0x1732 0x05 0 no no not
operational, no_path, reavalidate,device_gone
0x10 0x1731 0x01 0x1732 0x01 0 no no not
operational, no_path, reavalidate,device_gone
0x04 0x3088 0x60 * * 1 no no
not operational, no_path, reavalidate,device_gone
0x06 0x3088 0x1f * * 15 no no
not operational, no_path, reavalidate,device_gone
0x05 0x3088 0x08 * * 15 no no
not operational, no_path, reavalidate,device_gone
0x04 0x3088 0x01 * * 15 no no
not operational, no_path, reavalidate,device_gone
No auto devno ranges
From To
================
0x0000 0xffff
Forced devices
chan defif write data memory port IP
hw host adaptor api
type num devno devno devno usage(k) protocol no chksum
stats name name
0x10 0 0x0e60 0x0e61 0x0e62 default 0 0
0
Channels detected
chan cu cu dev
dev in chandev
irq devno type type model type model pim
chipids use reg
0x0305 0x0fe2 0x06 0x3088 0x1f 0x0000 0x02 0x80
0x1300000000000000 no no
0x0306 0x0fe3 0x06 0x3088 0x1f 0x0000 0x02 0x80
0x1300000000000000 no no
0x05cd 0x0e60 0x10 0x1731 0x01 0x1732 0x01 0x80 0x00ffffffffffffff
no no
0x05cd 0x0e61 0x10 0x1731 0x01 0x1732 0x01 0x80 0x00ffffffffffffff
no no
0x05cd 0x0e62 0x10 0x1731 0x01 0x1732 0x01 0x80 0x00ffffffffffffff
no no
0x05cd 0x0e63 0x10 0x1731 0x01 0x1732 0x01 0x80 0x00ffffffffffffff
no no
0x05cd 0x0e64 0x10 0x1731 0x01 0x1732 0x01 0x80 0x00ffffffffffffff
no no
0x05cd 0x0e65 0x10 0x1731 0x01 0x1732 0x01 0x80 0x00ffffffffffffff
no no
Driver specific parameters
chan lo hi driver
type devno devno parameters
===========================
0x10 0x0e60 0x0e62 portname:OSAGD00
Sue Sivets
Carlos Ordonez wrote:
> Sue, it seems as if it is having problems with the device. Can you do a
> display of /proc/chandev before you issue the "echo" commands and also one
> after. Carlos :-)
>
> Saying goes: Great minds think alike - I say: Great minds think for
> themselves!
>
> Carlos A. Ordonez
> IBM Corporation
> Server Consolidation
>
> |---------+--------------------------->
> | | Sue Sivets |
> | | <ssivets@fdrinno|
> | | vation.com> |
> | | Sent by: Linux |
> | | on 390 Port |
> | | <[EMAIL PROTECTED]|
> | | RIST.EDU> |
> | | |
> | | |
> | | 06/19/2002 01:54|
> | | AM |
> | | Please respond |
> | | to Linux on 390 |
> | | Port |
> | | |
> |---------+--------------------------->
>
>>-------------------------------------------------------------------------------------------------------------------------------|
> |
> |
> | To: [EMAIL PROTECTED]
> |
> | cc:
> |
> | From:
> |
> | Subject: Suse & OSA gigabit problem
> |
> |
> |
>
>>-------------------------------------------------------------------------------------------------------------------------------|
>
> I'm having a problem with Suse Linux 2.4.7 (sles7) and the OSA Gigabit
> card. I have read the Linux (and MVS) chapters in the IBM z800
> Technical Introduction redbook and several chapters along with the one
> on OSA in the Linux Device Drivers manual. I'm installing the Suse
> installation system from cdrom into an lpar on a z800, and I selected
> option 0 (no network) from the network install menu. The error message
> I'm getting seems to be a little different than the one I've seen in
> most of the messages on the list. I'm getting an IDX ACTIVATE timeout,
> instead of an IDX TERMINATE error code 22. I've double checked the
> portname parameter,and it matches.
> Can anyone help me get this up and running?
>
> I issued the following commands and the system displayed these
> messages:
>
> echo 'noauto' >/proc/chandev
> echo 'qeth0,0x0e50,0x0e51,0x0e52,0,0' >/proc/chandev
> echo 'add_parms,0x10,0x0e50,0x0e52,portname:OSAGD00' >/proc/chandev
> insmod qdio
> Using /lib/modules/2.4.7 - Suse - SMP/misc/qdio.o
> qdio: Loading QDIO base support version 2 ($revision:1.79
> $/$revision: 1.44 $)
> 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.135
> $/$revision: 1.53 $/$revision: 1.18 $)
> qeth: allocaated 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 tu sue card with devnos 0xE%0/0xE51/0xE52
> qeth: IDX_ACTIVATE (rd) on read channel irq 0x5bd: timeout
> qeth: there were problems in hard setting up the card
> debug unregistering qeth_setup
> debug unregistering qeth_misc
> debug unregistering qeth_data
> debug unregistering qeth_control
> debug unregistering qeth_sense
> debug unregistering qeth_qerr
> 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 parameters
> including invalid io or irq parameters
>
> Sue Sivets
>
> --
> Suzanne Sivets
> Systems Programmer
> Innovation Data Processing
> 973-890-7300
> Fax 973-890-7147
> [EMAIL PROTECTED]
--
Suzanne Sivets
Systems Programmer
Innovation Data Processing
973-890-7300
Fax 973-890-7147
[EMAIL PROTECTED]
