Hi, > Notice that VM shows that the triple of device numbers 963,964,965 > have been switched around to the order 964,965,963 in order for the > first even number to become the CTL-READ device. The error message > from your Linux guest was
> > qeth: Trying to use card with devnos 0x963/0x964/0x965 > > qeth: received an IDX TERMINATE on irq 0x14/0x15 with cause code 0x08 > > qeth: IDX_ACTIVATE on read channel irq 0x14: negative reply > > qeth: There were problems in hard-setting up the card. > and it may be worth checking whether Linux has decided to switch > around the device numbers in the same way, perhaps by checking in > /proc/subchannels or /proc/chandev whether subchannel 0x14 really > is the control read device. On the other hand, it may be simpler > just to enforce the "even boundary" constraint, if only to avoid > having those permuted device numbers appearing. qeth tries to re-order the devices presented by chandev so that they match the odd-even restriction (just juggling the devices around until we have something reasonable). Maybe we should adapt the messages... Btw.: Which oco-Level is this? (dmesg | grep Revis) We don't do the reordering for HiperSockets in recent levels since they seem to be fine for odd addresses. > I guess that there may even be other differences since this time > you're using a hipersockets device instead of a qdio one and it'll > have a different portname and so on (which is case sensitive and so > may be worth checking too: even if your OS/390 people see/quote it > in upper case it's possible that the underlying portname could be > lower case). Afaik HiperSockets don't require a portname (not sure about GuestLan, though) - but it shouldn't hurt to specify one. Portnames are always upper case. Mit freundlichen Grüßen/Regards Cornelia Huck Linux for zSeries Development IBM Deutschland Entwicklung GmbH Email: [EMAIL PROTECTED] Phone: ext. +49(0)7031/16-4837, int. *120-4837
