bos.net.tcp.client 5.3.0.5X - Aix

This is a discussion on bos.net.tcp.client 5.3.0.5X - Aix ; Is anybody else having problems with upgrading to 5.3 TL5 in regards to bos.net.tcp.client? First I thought it was a configuration problem on my part, because after the update, my server would hang with 0581 for almost 2 hours. Last ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: bos.net.tcp.client 5.3.0.5X

  1. bos.net.tcp.client 5.3.0.5X

    Is anybody else having problems with upgrading to 5.3 TL5 in regards to
    bos.net.tcp.client? First I thought it was a configuration problem on
    my part, because after the update, my server would hang with 0581 for
    almost 2 hours. Last week I had a IBM Professional Services person on
    site and we built 2 fresh VIO servers. Once I defined more than one
    network card on the VIO server, smitty or mktcpip would hang on the
    cfgif portion, which would probably last 2 hours if I let it. These
    were fresh installs of VIO 1.3, which so happens to be based on TL5. On
    my non-VIO server, I deconfigured all but 1 network card, and now it
    boots just fine.

    Yes, I do have a PMR open with IBM, but I was wondering if anybody else
    has been seeing this? I am a one-man show, so my time is a premium. My
    IBMer even agreed it looks like a bug in bos.net.tcp.client.

    Just wondering,

    SG

  2. Re: bos.net.tcp.client 5.3.0.5X

    0xDEADABE wrote:
    > Is anybody else having problems with upgrading to 5.3 TL5 in regards to
    > bos.net.tcp.client? First I thought it was a configuration problem on
    > my part, because after the update, my server would hang with 0581 for
    > almost 2 hours.


    We've seen this as well at 5.3 TL5 SP1 recently.
    This AIX LPAR configuration uses dual-port SX ethernet fast failover.
    Partition startup hangs at 0581 for a long time, alog -f bootlog
    shows long delays in the cfgif step. Seems to be APAR IY89481:

    IY89481: IFCONFIG HANGS DURING BOOTUP ON CALL TO GETHOSTBYNAME

    Still in OPEN status, no fix yet. We managed to work around it
    by changing our fast-failover configuration for now.



    > Last week I had a IBM Professional Services person on
    > site and we built 2 fresh VIO servers. Once I defined more than one
    > network card on the VIO server, smitty or mktcpip would hang on the
    > cfgif portion, which would probably last 2 hours if I let it.


    This is probably the same thing, but I don't know if IBM has another
    APAR for the VIOS packaging. If you are using multiple SEAs, you also
    may want to look out for IY90554..

    IY90554: SEA INTERFACE MISSING AFTER REBOOT

    Basically, if 2 or more SEAs are created, at least one interface can
    be missing from ODM after reboot. Same if you delete any SEA IFs.
    We had to drop back to a single SEA for now, while waiting for a fix.


    HTH, Eric

  3. Re: bos.net.tcp.client 5.3.0.5X

    Eric.Jones wrote:
    > 0xDEADABE wrote:
    >
    >> Is anybody else having problems with upgrading to 5.3 TL5 in regards
    >> to bos.net.tcp.client? First I thought it was a configuration problem
    >> on my part, because after the update, my server would hang with 0581
    >> for almost 2 hours.

    >
    >
    > We've seen this as well at 5.3 TL5 SP1 recently.
    > This AIX LPAR configuration uses dual-port SX ethernet fast failover.
    > Partition startup hangs at 0581 for a long time, alog -f bootlog
    > shows long delays in the cfgif step. Seems to be APAR IY89481:
    >
    > IY89481: IFCONFIG HANGS DURING BOOTUP ON CALL TO GETHOSTBYNAME
    >
    > Still in OPEN status, no fix yet. We managed to work around it
    > by changing our fast-failover configuration for now.
    >
    >
    >
    >> Last week I had a IBM Professional Services person on site and we
    >> built 2 fresh VIO servers. Once I defined more than one network card
    >> on the VIO server, smitty or mktcpip would hang on the cfgif portion,
    >> which would probably last 2 hours if I let it.

    >
    >
    > This is probably the same thing, but I don't know if IBM has another
    > APAR for the VIOS packaging. If you are using multiple SEAs, you also
    > may want to look out for IY90554..
    >
    > IY90554: SEA INTERFACE MISSING AFTER REBOOT
    >
    > Basically, if 2 or more SEAs are created, at least one interface can
    > be missing from ODM after reboot. Same if you delete any SEA IFs.
    > We had to drop back to a single SEA for now, while waiting for a fix.
    >
    >
    > HTH, Eric


    Strange, though, I am seeing it on a system with more than one card, not
    utilizing any type of fast failover. They are just on separate
    networks. I do have my VIO servers set up for that, but I just went
    back to FP 74 on those and all is good. I already had dual VIO servers
    before my IBMer arrived. He wanted to start from scratch, which
    involved installing VIO 1.3 on two more LPARs. This is where we found
    the issue to be related to that level of AIX than my configuration,
    because both freshly installed systems exhibited the same behavior. We
    wasted an entire day trying to figure this out.

    For my workarounds, I went back to using one NIC my TL5 system, and
    went back to FP 74 on the VIOs. BEWARE of VIO 1.3 for this reason, and
    TL5, of course. ;-)


  4. Re: bos.net.tcp.client 5.3.0.5X

    0xDEADABE wrote:
    > Eric.Jones wrote:
    >> 0xDEADABE wrote:
    >>

    > snipped..
    >>
    >> IY89481: IFCONFIG HANGS DURING BOOTUP ON CALL TO GETHOSTBYNAME
    >>

    > snipped



    > We wasted an entire day trying to figure this out.


    Hehe.. I know the feeling.
    We were testing mksysb LPAR restores from bootable DVD-RAM when we
    first saw the hang problem. Spent a lot of time puzzling over slight
    bosinst.data tweaks before we recognized the IY89481 symptoms.

    >
    > For my workarounds, I went back to using one NIC my TL5 system, and went
    > back to FP 74 on the VIOs. BEWARE of VIO 1.3 for this reason, and TL5,
    > of course. ;-)
    >


    Looks like we will soon have the FP-8.1 for VIOS, IY90950 was closed on
    Friday.
    Hopefully the fixes will allow us to resume our normal configurations.


+ Reply to Thread