Slave buffer problem

Slave buffer problem

[philw]

"8 1/2: slave buffer: no free mount rpc buffer" is
generated by the mount driver when trying to malloc
a new RPC buffer. I suspect you are running out of
kernel memory at a bad time. try increasing kernelpercent.

phil.

Slave buffer problem

[forsyth]

>>I've started seeing that too, after applying the latest boddle plus the
>>devvga.c:/gscreen.ldepth patch that someone posted to the list (Is it a
>>correct fix?).  ^t^tx reports that there are very few bytes free, like
>>22K (16M machine with kernerlpercent=40, vgasize=1280x1024x8).  If it

the gscreen.ldepth change causes the pc implementation to behave
more like the other terminals, preallocating 3  $vgasize sized screens worth of bitmap space
(if possible) in devbit.c.   this reduces the chances of being unable to create a
window (or move/reshape/hide an existing one) owing to fragmentation
of the kernel heap.  kernelpercent might well need to be increased to
compensate, esp. with a screen size of 1280x1024.  at home, i use kernelpercent=40
with a screen size of 1152x900x8 without much trouble.

Slave buffer problem

[Boyd]

    From: Luther Huffman <lutherh@infinet.com>

    I have a little information on the problems I've been having of applications
    mysteriously freezing up my system console and displaying the message "8
    1/2: slave buffer: no free mount rpc buffer".

    check: "/386/lib/perl/": qid out of range 12f8e

there's your problem.  kfs has barfed on perl.

Slave buffer problem

[Luther]

At 08:37 PM 7/14/96 -0400, you wrote:
>is bad. Try changing line 91 of chk.c to
>
>	sizqbits = ((1<<18) + 7) / 8;		/* botch */
>

Thanks, Phil! That does indeed stop disk/kfs from reporting bad qids. I
still get the messages during system startup after an OS failure, but I
believe that's caused by the fact fs check is called at that point. I
imagine there is a magic variable similar to sizqbits in fs.
     The whole thing does make me believe that any link between the bad qid
message and the slave buffer failure is at best indirect. There may,
however, be another system constant that I exceeded the same time as the qid
variable.
     Does anyone know from where the "8 1/2: slave buffer: no free mount rpc
buffer" message originates? I've grepped up the usual suspects, but haven't
found the message's source yet. And I don't have enough system resources to
do a global grep/awk.
---
Luther Huffman		lutherh@stratcom.com
Strategic Computer Solutions, Inc.
http://www.stratcom.com/

Slave buffer problem

[philw]

qid out of range seems to happen because an
array (qbits in disk/kfs/chk.c) is too small -
it does not necessarily mean the file system
is bad. Try changing line 91 of chk.c to

	sizqbits = ((1<<18) + 7) / 8;		/* botch */

phil.

Slave buffer problem

[David]

Luther Huffman <lutherh@stratcom.com> writes:
> [...]
> check: "/386/lib/perl/5.00301/CORE/": qid out of range 12f91
> [...]
> I've noticed, as an example, if a perl script of mine loads a module from
> /386/lib/perl I get the failure. If the perl script loads a module from
> /sys/lib/perl everything proceeds normally. Similar things appear to occur
> for other programs doing some kind of access in these directories as well.
> The normal file and directory commands (ls, cat, etc.) seem to work just
> fine with these directories.
>      Does this give rise to any new ideas, anyone?

Sounds to me like you're dealing with some sort of fundamental
incompatibility/exclusion principle ;-)

Reminds me a lot of the phenomenon of organ rejection.

Perhaps a marriage guidance counsellor would be able to help...
(oops, wrong thread!)

Slave buffer problem

[Luther]

I have a little information on the problems I've been having of applications
mysteriously freezing up my system console and displaying the message "8
1/2: slave buffer: no free mount rpc buffer". There really does appear to be
a link between this problem and the error messages which a file system check
produces. Here's sample output from disk/kfs:

term% disk/kfs -f /dev/hd1fs
check: "/386/bin/aux/mapd": qid out of range 113bb
check: "/386/bin/fb/twb": qid out of range 115b8
check: "/386/bin/fb/bit2enc": qid out of range 115c7
check: "/386/bin/fb/enc2bit": qid out of range 115e4
check: "/386/bin/fb/ikon": qid out of range 115fb
check: "/386/bin/fb/mugs": qid out of range 11614
check: "/386/bin/fb/paint": qid out of range 1161b
check: "/386/bin/fb/scale": qid out of range 1163a
check: "/386/lib/perl/": qid out of range 12f8e
check: "/386/lib/perl/5.00301/": qid out of range 12f8f
check: "/386/lib/perl/5.00301/CORE/": qid out of range 12f91
check: "/386/lib/perl/5.00301/CORE/arpa/": qid out of range 12f92
check: "/386/lib/perl/5.00301/CORE/arpa/inet.h": qid out of range 12fae
check: "/386/lib/perl/5.00301/CORE/EXTERN.h": qid out of range 12f93
check: "/386/lib/perl/5.00301/CORE/INTERN.h": qid out of range 12f94
check: "/386/lib/perl/5.00301/CORE/XSUB.h": qid out of range 12f95
check: "/386/lib/perl/5.00301/CORE/av.h": qid out of range 12f96
check: "/386/lib/perl/5.00301/CORE/cop.h": qid out of range 12f97
check: "/386/lib/perl/5.00301/CORE/cv.h": qid out of range 12f98
    6051 bad qids
term% 

I've noticed, as an example, if a perl script of mine loads a module from
/386/lib/perl I get the failure. If the perl script loads a module from
/sys/lib/perl everything proceeds normally. Similar things appear to occur
for other programs doing some kind of access in these directories as well.
The normal file and directory commands (ls, cat, etc.) seem to work just
fine with these directories.
     Does this give rise to any new ideas, anyone?
---
Luther Huffman		lutherh@stratcom.com
Strategic Computer Solutions, Inc.
http://www.stratcom.com/

Slave buffer problem

[Luther]

I don't believe I used the gscreen patch. It could, however, be one of the
other boddles. For the record, your system is nearly identical to mine --
16M, vgasize 1280x1024x8.

At 12:33 PM 7/12/96 -0400, our favorite Scott wrote:
>Luther Huffman <lutherh@infinet.com> writes:
>|      I'm running Plan 9 as term on a Pentium machine. A few days ago, I
>| began to have some of my applications crash mysteriously, freezing the
>| windows on the system. A message is displayed: "8 1/2: slave buffer: no free
>| mount rpc buffer". 
>
>I've started seeing that too, after applying the latest boddle plus the
>devvga.c:/gscreen.ldepth patch that someone posted to the list (Is it a
>correct fix?).  ^t^tx reports that there are very few bytes free, like
>22K (16M machine with kernerlpercent=40, vgasize=1280x1024x8).  If it
>gets really low, things start to hang, with processes Queueing or
>Scheding in Malloc or New.
>
>
---
Luther Huffman		lutherh@stratcom.com
Strategic Computer Solutions, Inc.
http://www.stratcom.com/

Slave buffer problem

[Scott]

Luther Huffman <lutherh@infinet.com> writes:
|      I'm running Plan 9 as term on a Pentium machine. A few days ago, I
| began to have some of my applications crash mysteriously, freezing the
| windows on the system. A message is displayed: "8 1/2: slave buffer: no free
| mount rpc buffer". 

I've started seeing that too, after applying the latest boddle plus the
devvga.c:/gscreen.ldepth patch that someone posted to the list (Is it a
correct fix?).  ^t^tx reports that there are very few bytes free, like
22K (16M machine with kernerlpercent=40, vgasize=1280x1024x8).  If it
gets really low, things start to hang, with processes Queueing or
Scheding in Malloc or New.

Slave buffer problem

[Luther]

Hello, all.
     I'm running Plan 9 as term on a Pentium machine. A few days ago, I
began to have some of my applications crash mysteriously, freezing the
windows on the system. A message is displayed: "8 1/2: slave buffer: no free
mount rpc buffer". 
     I've also begun to notice that upon rebooting after a crash, during the
system's automatic post-crash disk/kfscmd check, many files (mostly in
/sys/lib) are listed as having "bad qid"s. Without exception, these are all
files and directories I've added or patched in the past few months. I
suspect these two problems are related, as it appears to me that all of the
programs which crash are doing file and directory stats on these suspect files. 
     I've tried, to no avail, running the bad block repair options to
disk/kfscmd check. That doesn't appear to fix the problem
     Can someone out there read the entrails of my system and tell me what's
wrong, how to fix it, and how to keep it from happening again?
---
Luther Huffman		lutherh@stratcom.com
Strategic Computer Solutions, Inc.
http://www.stratcom.com/