Hi Steve,
>From your note:
> def nic 3909 type qdio
> 01: NIC 3909 is created; devices 3909-390B defined
> Ready; T=0.01/0.01 22:31:41
You are caught between two definitions of even and odd. The older OSA
microcode that we emulated with Guest LAN defines even and odd based on the
OFFSET from the control unit. Guest LAN sees your device 0x3909 as an
EVEN-numbered device. The chandev.conf entry listing 0x3909,0x390a,0x390b
would have worked with an older qeth driver because your odd-numbered
virtual device is really (from our definition) an even-numbered device on
the card.
If this had been a real OSA starting at 0x3900 (or a DEFINE NIC 3900 with
DEVICES 16) your device 0x3909 would have been considered an ODD numbered
device and initialization would have failed (with an older qeth driver).
So why didn't this work? I believe the latest qeth drivers are trying to
correct a common configuration problem by looking at the virtual device
address and re-assigning the role of each device. However, the driver
defines the odd-numbered device based on the virtual device address
(instead of the unit offset). In your case, 0x3909 looks "odd" so qeth
probably assumes you really want to use 0x390a as the read-control device.
CP sees this as unit 001 and refuses to accept the read-control device
assignment.
How can you fix this? Define NIC 3908 (or some other suitable EVEN
numbered device address) and adjust your chandev.conf entry to use
0x3908,0x3909,0x390a. IF you were using 3909 because it maps to a real
device that you expect to use part-time, just define a larger NIC (e.,g. cp
def nic 3908 type qdio devices 4) so all parties are in agreement about the
odd-numbered devices.
Finally... The real OSA Express no longer requires the even/odd polarity
for read/write control devices, so I hope we will be able to lift that
restriction for Guest LAN at some point in the future.
Regards,
Dennis
----------------------------------------------------------------
Dennis Musselwhite ([EMAIL PROTECTED]) +1(607)429-3831
z/VM Development -- CP Network Simulation -- IBM Endicott NY
[EMAIL PROTECTED]
STATE.OR.US To: [EMAIL PROTECTED]
Sent by: Linux on cc:
390 Port Subject: Re: [LINUX-390] VSWITCH
Connections
<[EMAIL PROTECTED]
ST.EDU>
04/16/2004 02:12
AM
Please respond to
Linux on 390 Port
Mark/Alan
My apologies, I misunderstood the request.
Yes, the NIC does couple to the switch successfully and I changed to
VSWITCH
CONTROLLER statement, from VSWITCH CONTROLLER ON 0206 0208, after reading
Alan's suggestions. Here are the snips from VM 4.40:
def nic 3909 type qdio
01: NIC 3909 is created; devices 3909-390B defined
Ready; T=0.01/0.01 22:31:41
couple 3909 to system vss3000
01: NIC 3909 is connected to VSWITCH SYSTEM VSS3000
Ready; T=0.01/0.01 22:32:10
q lan det
01: LAN SYSTEM HSI3000 Type: HIPERS Active: 1 MAXCONN: INFINITE
01: PERSISTENT UNRESTRICTED MFS: 16384 ACCOUNTING: OFF
01: Adapter Owner: REL3001 NIC: 3009 Name: UNASSIGNED
01: VSWITCH SYSTEM VSS3000 Type: VSWITCH Active: 1 MAXCONN: INFINITE
01: PERSISTENT RESTRICTED NONROUTER MFS: 8192 ACCOUNTING: OFF
01: State: Ready
01: CONTROLLER: TCPIP IPTIMEOUT: 5 QUEUESTORAGE: 8
01: PORTNAME: UNASSIGNED RDEV: 0206 VDEV: 0206
01: Authorized userids:
01: REL3001 VLAN: ANY
01: SYSTEM VLAN: ANY
01: Adapter Owner: REL3001 NIC: 3909 Name: UNASSIGNED
Ready; T=0.01/0.01 22:32:49
q nic det
01: Adapter 3009 Type: HIPERS Name: UNASSIGNED Devices: 3
01: Port 0 MAC: 02-00-00-00-00-00 LAN: SYSTEM HSI3000 MFS: 16384
01: RX Packets: 0 Discarded: 0 Errors: 0
01: TX Packets: 0 Discarded: 0 Errors: 0
01: RX Bytes: 0 TX Bytes: 0
01: Unassigned Devices:
01: Device: 3009 Unit: 000 Role: Unassigned
01: Device: 300A Unit: 001 Role: Unassigned
01: Device: 300B Unit: 002 Role: Unassigned
01: Adapter 3909 Type: QDIO Name: UNASSIGNED Devices: 3
01: Port 0 MAC: 02-00-00-00-00-01 VSWITCH: SYSTEM VSS3000 MFS: 8192
01: RX Packets: 0 Discarded: 0 Errors: 0
01: TX Packets: 0 Discarded: 0 Errors: 0
01: RX Bytes: 0 TX Bytes: 0
01: Unassigned Devices:
01: Device: 3909 Unit: 000 Role: Unassigned
01: Device: 390A Unit: 001 Role: Unassigned
01: Device: 390B Unit: 002 Role: Unassigned
Ready; T=0.01/0.01 22:33:31
And here are the snips from the running Linux guest:
Bringing up interface eth0: qeth device eth0 does not seem to be present,
delay
ing initialization.
cat /etc/chandev.conf
noauto
qeth0,0x3909,0x390A,0x390B,0,0
add_parms,0x10,0x3909,0x390B,portname:VSI3000
qeth1,0x3009,0x300A,0x300B,0,0
add_parms,0x10,0x3009,0x300B,portname:HSI3000
[EMAIL PROTECTED] root�#
ifconfig -a
hsi1 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:10.0.128.1 Bcast:10.0.143.255 Mask:255.255.240.0
UP BROADCAST RUNNING NOARP MULTICAST MTU:8192 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:14
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:588 (588.0 b) TX bytes:588 (588.0 b)
lsmod
Module Size Used by Not tainted
autofs 18376 0 (autoclean) (unused)
iptable_filter 3604 0 (autoclean) (unused)
qeth 219632 1
qdio 52608 1 �qeth�
af_packet 22912 0 (autoclean)
iptable_nat 30416 1 (autoclean)
ip_conntrack 40392 1 (autoclean) �iptable_nat�
ip_tables 22044 4 �iptable_filter iptable_nat�
ext3 119896 4
jbd 72952 4 �ext3�
dasd_fba_mod 8752 0 (unused)
dasd_eckd_mod 76756 5
dasd_mod 82072 7 �dasd_fba_mod dasd_eckd_mod�
I just realized that I'm probably chasing my tail. Seems that as soon as I
disconnect from REL3001 and attempt any other operation (like q lan det
from
maint) on VM4.40, the VM system dumps. Since we are in the process of
migrating, this VM image is running as a guest OS of VM4.30 still. I'll go
off to troubleshooting land and see if I can't stabilize 4.40 before going
any further on this problem (since it's likely that my problem is
elsewhere).
Thanks so much for everyone's help and if you see anything that looks odd
in
the information posted above please let me know.
Thanks again,
Steve
-----Original Message-----
From: Post, Mark K [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 15, 2004 4:03 PM
To: [EMAIL PROTECTED]
Subject: Re: VSWITCH Connections
Steve,
I didn't mean the VM operator's console, I meant the virtual console for
the
guest. Is the NIC defined properly and coupled to the VSWITCH?
#cp q nic details
#cp q lan details
Mark Post
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
