Hi Folks, I am having the exact problem as Michael is. I did the kernel (-266) maintenance to one of my guests this morning that previously had a working connection to my hipersockets and VSWITCH through qeth. The VSWITCH connection works fine but the hipersockets connection is toast - same 0x03 return as was previously reported. I did shut the guest completely down and brought it back up with the same failed results. I'm initializing eth0 (virtual qdio interface) first then hsi1. I have addparms and the portname listed in chandev.conf and have verified ifcfg-hsi1 and modules.conf, they are correct. Looking at 'q lan det' in maint I can see the hipersockets network and the connection for the failing guest (no address assignment, of course, since SLES doesn't seem to recognize a "valid interface name"). The hsi1 guest interface worked without error before I applied SuSE's maintenance this morning.
Steve -----Original Message----- From: Dennis Musselwhite [mailto:[EMAIL PROTECTED] Sent: Thursday, December 23, 2004 9:40 AM To: [email protected] Subject: Re: SUSE kernel 2.4.21-266 qeth driver problem Hi Michael, 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)? You mentioned that your /etc/chandev.conf file includes: noauto;qeth0,0x770,0x771,0x772 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. Regards, Dennis ---------------------------------------------------------------- Dennis Musselwhite ([EMAIL PROTECTED]) z/VM Development -- CP Network Simulation -- IBM Endicott NY ---------------------------------------------------------------------- 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
