[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::fddi

Title:	FDDI - The Next Generation

Moderator:	NETCAD::STEFANI

Created:	Thu Apr 27 1989
Last Modified:	Thu Jun 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2259
Total number of notes:	8590

2243.0. "slow UNIX boot if cables not plugged in FDDI board" by 49022::DORNANO () Thu Mar 20 1997 09:57

Hello,

Customer runs UNIX V32.C or UNIX V4.0A on alphastations 255/300
with DEFTA-DA (but maybe it is DEFPA ?).

This is not so important (I think), because my question deals more
with implementation of the FDDI protocol, rather than with the type of board.

Customer noticed that UNIX boot is 25 seconds slower than usual if the cables
are deconnected from the FDDI interface. At the kernel level the interface
is seen as potentialy usable, as there is an IP address on it.

He looks surprised, as he thought that quickly a kind of timeout would raise
and make the boot faster than if there were really a ring to enter.

I told him I guess this could be normal behaviour, as the protocol would try and
retry (maybe *quite* a long time) before giving up.

Is this true ? Customer wants a strong response from us on this issue.

I have no more infos (boot sequence, log files, etc..), but some clues would be
appreciated to begin my search.

Thanks

Pascal d'ORNANO

T.R	Title	User	Personal Name	Date	Lines
2243.1		NETCAD::STEFANI	FDDI Adapters R Us	`Thu Mar 20 1997 12:32`	14
	>>Customer runs UNIX V32.C or UNIX V4.0A on alphastations 255/300 >>with DEFTA-DA (but maybe it is DEFPA ?). It would be a DEFPA-DA. >>Customer noticed that UNIX boot is 25 seconds slower than usual if the cables >>are deconnected from the FDDI interface. At the kernel level the interface >>is seen as potentialy usable, as there is an IP address on it. I believe the console firmware tries to go out on the network device during boot. I don't know if the UNIX driver does the same thing. Anyway, I would tell the customer not to be concerned over this. /l
2243.2	some more info please	49022::DORNANO		`Mon Mar 24 1997 05:39`	27
	Thank you very much for your input >I believe the console firmware tries to go out on the network device during >boot. should I ask the platform specific notesfile to have a definitive answer, or do you mean this is it ? I understand that low level FDDI operations (LCT, Recovery, Framing error, etc..) is done directly by the hardware (board), so even before UNIX starts, it could already try several times itself. >I don't know if the UNIX driver does the same thing. I think so. UNIX would say in this case something like "No link" >Anyway, I would tell the customer not to be concerned over this. Unfortunately, they request a written answer. Regards
2243.3		NETCAD::STEFANI	FDDI Adapters R Us	`Mon Mar 24 1997 09:50`	28
	>>>I believe the console firmware tries to go out on the network device during >>>boot. >> >>should I ask the platform specific notesfile to have a definitive answer, >>or do you mean this is it ? You should check the platform specific notesfile. Perhaps the console engineers could tell you what happens if they detect a DEFPA, but the link isn't up. Perhaps their timeout rate is long, but configurable. I don't know. >>I understand that low level FDDI operations (LCT, Recovery, Framing error, >>etc..) is done directly by the hardware (board), so even before UNIX starts, >>it could already try several times itself. The board powers up in DMA_UNAVAILABLE state. In this state it doesn't do much of anything. Some host-based driver must configure a number of registers and issue a series of commands to get the adapter into the LINK_UNAVAILABLE/LINK_AVAILABLE states. It is in these states that the green LED comes on and if the cable is disconnected, the constant blinking green LED occurs. Note that I said "some host-based driver". The console firmware certainly has a DEFPA driver to support network boots. The DIGITAL UNIX kernel contains a different DEFPA driver to support normal network operations under UNIX. It's possible that either or both environments are timing out trying to perform some network connection that isn't happening. -Larry
2243.4		49022::DORNANO		`Mon Mar 24 1997 11:09`	4
	Thank you for these clear explanations ! Pascal