> I'm not aware of any changes in the qeth driver that would have affected > the HiperSockets initialization (but I'm no expert on the Linux > implementation). It sounds like you are keeping your Linux users > up-to-date. What level of CP are you running (and what Guest LAN > maintenance level is reported by Query VMLAN)?
We're running z/VM 4.4 at service level 401. We're at VMLAN maintenance level VM63397. > Is it possible that your old configuration file did not specifiy "noauto" ? > If that were the case, your old configuration might have given the channel > device layer more freedome to "guess" which devices were appropriate > network types. > > I would suggest an experiment. Add the following line to > /etc/chandev.conf: > > add_parms,0x10,0x770,0x772 > > Shutdown and restart the guest... If that does not correct the problem, > change it to: > > add_parms,0x10,0x770,0x772,portname:anything > > Shutdown and restart the guest... The portname "anything" can be just about > any string up to 8 characters. It only has to match other interfaces on > the same NIC (which is just your interface in the case of a virtual NIC). > > Those are a couple of things that might affect the way Linux initializes > the HiperSockets interface. If this works, it will give us a better idea > where things changed. If it does NOT work, I can suggest a virtual I/O > trace that we can use to figure out why the initialization failed. The exclusion of "noauto" and the inclusion of the add_parms line (both with and without a "portname" statement) seemed to have no effect. Thanks for your help, Michael Lambert Louisiana State University Office of Computing Services ---------------------------------------------------------------------- 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
