Now I am confused. Please correct me when I am wrong. When I create guestlan of QDIO type, VM can handle it for its guests. It doesn't need real hipersocket. Guests use virtual NIC so it can work even when there are no real OSA adapters. Of course there is at least one for VM itself, but guestlan does not use it. My qdio.o is 1.145, qeth.o is 1.337.4.5. Those are the latest versions I know. During guest IPL I get qdio: loading QDIO base support version 2 ($Revision: 1.145 $/$Revision: 1.66.4.1 $)
qdio: Was not able to determine general characteristics of all Hydras aboard. qeth: loading qeth S/390 OSA-Express driver ($Revision: 1.337.4.5 $/$Revision: 1.113.4.1 $/$Revision: 1.42.4.1 $:IPv6:VLAN) qeth: allocated 0 spare buffers qeth: Trying to use card with devnos 0x700/0x701/0x702 qeth: Device 0x700/0x701/0x702 is an OSD Express card (level: 2938) with link type Gigabit Eth (no portname needed by interface) qeth: VLAN not supported on eth0 qeth: IPv6 not supported on eth0 qeth: Could not set up broadcast filtering on eth0: 0x2, continuing eth0: no IPv6 routers present guestlan with static addresses work, only DHCP fails Am I right if I say it has nothing to do with real hw errors ? That it is sw error either in VM or in qdio/qeth drivers ? I don't have VM background and I didn't get answer on VM list regarding my receive/apply, maybe someone here would answer it ( although these two mailing lists have huge intersection :)) Can anybody explain this ? PTF: UM30652 APAR: VM63172 ------------------------------ Receive status: RECEIVED.10/24/03.06:20:56.MAINT Apply status: APPLIED.07/03/03.15:37:38.MAINT Thank you Marian --- Dennis Musselwhite <[EMAIL PROTECTED]> wrote: > Hi, > > APAR VM63172 (PTF UM30652) provided or improved > support for some functions > that the Linux device drivers needed to better > support applications like > DHCP. Our focus at that time was the QDIO model > because it included the > necessary broadcast support. APAR VM63172 made it > possible for the qeth > driver to obtain the MAC address that we generated > for the virtual NIC. > > I can imagine a couple of reasons why the > HiperSockets connections might > still show MAC of zeroes: > (1) Older qeth drivers did not send the request for > MAC address to our > simulated adapters because of IPv6 capabilities. > Apparently the hardware > added this support along with IPv6 so our lack of > IPv6 capability in z/VM > 4.3.0 implied that we also could not handle the > request for MAC address. > The qeth developers released an update to fix this > before VM63172 was > released, so make sure you have recent qdio/qeth > modules. > (2) The "real" HiperSockets facility DOES NOT > provide a MAC address at all. > It is entirely possible that qeth does not bother > sending the request to a > HiperSockets adapter ("real" or simulated). > > If you define a TYPE QDIO adapter on the same guest > and bring up the > interface, the ifconfig command should report the > same MAC address that you > see with CP QUERY NIC details. That would indicate > that your drivers are > new enough to handle the request. > > Regards, > Dennis > ---------------------------------------------------------------- > Dennis Musselwhite ([EMAIL PROTECTED]) > z/VM Development -- CP Network Simulation -- IBM > Endicott NY ===== =================== Marian Gasparovic =================== "The mere thought hadn't even begun to speculate about the merest possibility of crossing my mind." __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/