kovar@popvax.harvard.edu (115800@David C. Kovar) (07/21/89)
We've upgraded one 8200 to version 3.0 and our Emulex board stopped dropping the DSR lines to our Micom, leaving them hanging 'til they time out. A DEC consultant claims that 3.0 checks to see if the card is a DEC card. If not, it doesn't do anything with DSR. Has anyone else experienced this and, if so, do you have any suggested fixes for it? TIA. -David C. Kovar Technical Consultant ARPA: kovar@popvax.harvard.edu Office of Information Technology BITNET: corwin@harvarda.bitnet Harvard University MacNET: DKovar Ma Bell: 617-732-1778 "It is easier to get forgiveness than permission."
grr@cbmvax.UUCP (George Robbins) (07/21/89)
In article <2249@husc6.harvard.edu> kovar@popvax.harvard.edu (David C. Kovar) writes: > > We've upgraded one 8200 to version 3.0 and our Emulex board stopped > dropping the DSR lines to our Micom, leaving them hanging 'til they > time out. A DEC consultant claims that 3.0 checks to see if the card > is a DEC card. If not, it doesn't do anything with DSR. Has anyone > else experienced this and, if so, do you have any suggested fixes > for it? TIA. Which emulex card, and what is it emulating? The 3.0 release broke all DSR support in a way that hasn't been clearly explained. A large set of patches available on the 3.0 patch tape from the support center is supposed to fix what broke for the supported drivers. It didn't patch the unsupported DH11 driver, and I am having DSR/DTR type problems with modems on the DH11. An explict check for a "DEC" board seems fairly unlikely, however it is possible they have done something that depends on both CD and DSR and your emulation only supports CD, with DSR always asserted, then it may break whatever rituals DEC has implemented. Note that each of the drivers has a global (patchable) variable that has some effect on the handling of DSR... If your Emulex board emulates a supported device, then the first step would be to either obtain/install the patch tape or install the 3.1 upgrade. If the emulated device is unsupported, maybe it's fixed in 3.1 or patching the global variable will help. Disclaimer: This is largely theoretical, but should give you a more productive starting point than DEC consultants assertions. Example: /sys/data/dhu_data.c:int dhudsr = 0; /* A "0" here means ignore DSR */ /sys/data/dhu_data.c:int dhudsr = 1; /* A "1" here means drop line if DSR drops */ /sys/data/dmb_data.c:int dmbdsr = 0; /* A "0" here means ignore DSR */ /sys/data/dmb_data.c:int dmbdsr = 1; /* A "1" here means follow DS52 DSR signals */ /sys/data/dmf_data.c:int dmfdsr = 0; /* "1" = follow DECSTD52, 0 = no DS52 */ /sys/data/dmf_data.c:int dmfdsr = 1; /* "1" = follow DECSTD52, 0 = no DS52 */ /sys/data/dmz_data.c:int dmzdsr = 0; /* "0"=Don't follow DECSTD52 */ /sys/data/dmz_data.c:int dmzdsr = 1; /* "1"=Do follow DECSTD52 */ -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)