wul@sco.COM (Wu Liu) (06/05/91)
/--dhiraj@bohra.cpg.oz.au (Dhiraj Sharma) said... | I am having a problem with ODT-View: | | [ descriptive text deleted... ] | | If after step 3 I do not switch screens and just wait, say 5-10mins, for ping | to produce some output, ping still produces nothing, but then in other | multiscreens (the ones not running X) I receive the message "Out of stream | resources". After which contact with all machines on the net is lost. | | This problem does not only occur with ping, but also with other network | commands as rlogin, with rlogin hanging until I switch to another screen | and then come back to the one running X. Another example is df which | just shows the local filesystems and none of the NFS remote mounted ones. | | THESE PROBLEMS *DO NOT* OCCUR WHEN PING OR ANY OF THE OTHER COMMANDS ARE | ISSUED FROM ONE OF THE SCREENS WHICH IS NOT RUNNING X. | | [ hardware configuration and config.h contents deleted... ] \-- You're running out of streams buffers or queues. Since ODT-VIEW uses streams buffers for local X client/server communication (faster that way) and TCP/IP (and NFS, through TCP) uses streams as well, it's quite possible to run out, especially if you're using one or both heavily. The solution is to determine which streams resource or resources are maxed out and increase them. The crash(ADM) utility has a command (strstat) to tell you the state of your streams resources. You should make the change in streams resources by running the configure(ADM) tool as root. You'll need to relink your kernel. The process it somewhat painful (if you don't guess right, you'll have to reconfigure, relink, and reboot until you do), but worth the effort. If you use NFS heavily, you'll want to increase the number of 4k, 2k, and 1k buffers. TCP and Xsight tend to want use the 16-512 byte buffer sizes. Each system configuration will vary, so it's very much a trial and error process. Good luck.
knguyen@cs.toronto.edu ("T. Kim Nguyen") (06/05/91)
Actually it's not that hard to configure the kernel parameters -- just boost things by about 50% to start with. If you find your system slowing down and churning and thrashing enormously, then you know you pumped the params too high. :-) You can also just run sysadmsh to set these kernel params. When I was getting Sybase to work on our machine I had to ignore a lot of warnings I was getting from the configuration program, but the machine still works fine now (some of those warning messages sounded pretty ominous). Kim
belal@sco.com (Bela Lubkin) (06/11/91)
Dhiraj Sharma wrote that, essentially, his network access only works when he is NOT displaying an X server on his console screen. Several replies have suggested that he is running out of streams buffers. The behavior he described does not suggest streams problems. Streams problems would be more erratic. This problem sounds more like a hardware conflict between the video board and the ethernet board. VGA display memory is usually mapped into the A0000-BFFFF range of memory. Most VGA boards also have ROM BIOS code in the Cxxxx or Dxxxx ranges. I don't think SCO's 3C503 driver actually uses shared memory, but if it does, there could be a conflict there. >serial 0x02f8-0x02ff 03 -1 unit=1 type=Standard nports=1 >serial 0x03f8-0x03ff 04 -1 unit=0 type=Standard nports=1 >tape 0x0338-0x033c 05 01 type=wangtek >floppy 0x03f2-0x03f7 06 02 unit=0 type=96ds15 >parallel 0x03bc-0x03be 07 -1 unit=1 >e3B 0x0300-0x0310 11 -1 type=3c503 addr=02:60:8c:0f:99:a5 >adapter 0x0330-0x0332 13 05 type=ad ha=0 id=7 >fpu 0x0000-0x0000 15 -1 type=80387 A more likely cause is that the ethernet board is on interrupt 2. [Vector 2 gets chained to the 2nd interrupt controller, coming in as interrupt 9. The driver then displays it in octal, i.e. 11, or interrupt 1 on PIC 1. You will also see it as interrupt 25 or 31 (interrupt 1 on PIC 3, decimal or octal)]. Some VGA boards take over interrupt 2 for their own purposes, only when in graphics mode. If the VGA is driving the INT2 bus line low, the ethernet board probably won't be able to generate interrupts. So, Dhiraj, I suggest setting your 3C503 to a different interrupt. The 3C503's interrupt is configured at boot time by the e3B driver. You need only change the number, relink the kernel and reboot. Unfortunately, your system is already using all of the possible interrupts for the 3C503. You could put the tape drive on 2, in which case you could only access tapes from a text screen -- that might be a less annoying limitation. Or you could disable one of the serial or parallel ports and use its interrupt (3, 4 or 7). Bela Lubkin * * // filbo@deeptht.santa-cruz.ca.us Not speaking for SCO... @ * * // belal@sco.com ...ucbvax!ucscc!{deeptht!filbo,sco!belal} R Pentomino * \X/ Filbo @ Pyrzqxgl +1 408-476-4633 and XBBS +1 408-476-4945