On 07/15/2001 09:09:31 PM ZE2 Manuel Bouyer wrote:
>
>On Sun, Jul 15, 2001 at 06:44:18PM +0200, Christian Groessler wrote:
>> On 07/14/2001 12:29:58 PM ZE2 Manuel Bouyer wrote:
>> >
>> >On Sat, Jul 14, 2001 at 12:28:25AM +0200, Christian Groessler wrote:
>> >> On 07/13/2001 11:44:34 PM ZE2 Manuel Bouyer wrote:
>> >> >
>> >> >On Fri, Jul 13, 2001 at 11:05:13PM +0200, Christian Groessler wrote:
>> >> >>
>> >> >> About every 3 seconds the vmware machine freezes for about 3
>> >> >> seconds.
>> >> >> While this happens one of the vmware processes is in a function
>> >> >> "xscmd".
>> >> >> Here's the ps axl line:
>> >> >>
>> >> >>    0 363  360   0  -6 -19  3092   1992 xscmd    D<L  ?? 0:00.13
>> >> >>    /emul/linux/usr/local/bin/vmware -q notesnt/vm-nt.cfg
>> >> >>
>> >> >> I cannot find this xscmd function, a nm /netbsd | grep xscmd reveils
>> >> >> nothing.
>> >> >
>> >> >This is in the scsipi code. Your process is waiting for a SCSI or ATAPI
>> >> >command to complete.
>> >>
>> >> But why didn't I find the name in /netbsd? I'm still curious where ps
>> >> got it from.
>> >
>> >This isn't a symbol but a string:
>> >scsipi_base.c:1901:             (void) tsleep(xs, PRIBIO, "xscmd",
>> >0);
>>
>> Hmm, I see. But wouldn't it be better, given that this is the only
>> tsleep in this function, to use the function name as string, instead
>> of xscmd (which might mean something like "transfer sync. command")?
>>
>> Or how am I supposed to find the place where the process sleeps short
>> of a grep over the whole source archive?
>
>This string has to be short, I think

Maybe use only the first xxx chars of the function name. This will
still give a better hint to the function as currently.

>>
>>
>> >>
>> >> But, I'm sorry to say, there still seems to be a problem/quirk in NetBSD
>> >> VMWare. The drive wasn't empty (but the drive is really cheap). It
>> >> takes this delay when accessing it (mounting and reading data) on both
>> >> Linux and NetBSD native.
>> >
>> >But this doesn't hang the machine, rigth ?
>>
>> No, only a temporary freeze (~ 3s).
>
>Ok, on the wmware side. But on the NetBSD side, do the machine freeze ?

The NetBSD side seems mostly OK. The mouse always moves. But I have
the impression that fs access is blocked during this freeze. I noticed
it a few times in the past doing a ls in a shell terminal, but now
cannot reproduce it.

regards,
chris