On Wednesday, 08/27/2003 at 08:32 EST, Rich Smrcina <[EMAIL PROTECTED]> wrote: > When re-booting a normally working Linux machine that has an LCS interface, I > was greeted with these messages: > > Aug 26 19:00:51 wasprd kernel: Starting lcs module $Revision: 1.132 $ $Date: > 20 > 02/04/30 19:13:38 $ > Aug 26 19:00:51 wasprd kernel: with chandev support,with multicast support, > with ethernet support, with token ring support. > Aug 26 19:00:51 wasprd kernel: debug: lcs: new level 0 > Aug 26 19:00:51 wasprd kernel: lcs_sleepon network card taking time responding > irq=0001 devno=0600, > Aug 26 19:00:51 wasprd kernel: please be patient, ctrl-c will exit if shell > prompt is available. > Aug 26 19:00:51 wasprd kernel: No lcs capable cards found > Aug 26 19:00:51 wasprd kernel: Terminating lcs module. > > And access to the LCS interface was not functioning. Just rebooting it > started the interface fine. With the LCS addresses dedicated in the > directory entry, what would cause the interface to not initialize?
I see that LCS.C has changed in 2.6; it does not contain the lcs_sleepon_func(). There are comments in the 2.4 source which indicate that there are exposed race conditions. I'm guessing the response from the card came in faster than expected and the needed reply was lost. The question is whether the 2.6 changes will be retrofit to 2.4. (I don't know.) The only time I've legitimately seen an LCS initialization timeout is due to a casters-up card (OSA or 3172 in need of IML). On VM TCP/IP, the same condition (delay between device start and card ready) is seen when you get a message "cannot process ARP packet ... don't know home hardware address". Then, eventually, you see a "PCCA reports home hardware address ...." and everything begins running. Alan Altmark Sr. Software Engineer IBM z/VM Development
