On 2020-06-27 19:29:31, Bob Beck <b...@obtuse.com> wrote:
> 
> No. 
> 
> I know *exactly* what needbuf is but to attempt to diagnose what your
> problem is we need exact details. especially:
> 
> 1) The configuration of your system including all the details of the 
> filesystems
> you have mounted, all options used, etc. 
> 
> 2) The script you are using to generate the problem (Not a paraphrasing of 
> what
> you think the script does) What filesystems it is using. 
> 

Not the OP, but this problem sounds almost exactly like the bug I
reported last year.

There is a detailed list of steps I used to reproduce the bug in
the following bug report.

        https://marc.info/?l=openbsd-bugs&m=156412299418191

I was even able to bisect and identify the commit which first
caused the breakage for me.


---8<---

CVSROOT:        /cvs
Module name:    src
Changes by:     b...@cvs.openbsd.org    2019/05/08 06:40:57

Modified files:
        sys/kern       : vfs_bio.c vfs_biomem.c

Log message:
Modify the buffer cache to always flip recovered DMA buffers high.

This also modifies the backoff logic to only back off what is requested
and not a "mimimum" amount. Tested by me, benno@, tedu@ anda ports build
by naddy@.

ok tedu@

---8<---

However, I have since migrated away from using vnd(4)s since I was
able to find other solutions that worked for my use cases.  So I 
may not be able to provide much additional information other than
what is contained in the above bug report.

-- 
Bryan

> 
> 
> On Sat, Jun 27, 2020 at 08:09:18PM -0400, sven falempin wrote:
> > On Fri, Jun 26, 2020 at 7:35 PM sven falempin <sven.falem...@gmail.com>
> > wrote:
> > 
> > >
> > >
> > > On Fri, Jun 26, 2020 at 5:22 PM Stuart Henderson <s...@spacehopper.org>
> > > wrote:
> > >
> > >> On 2020/06/26 15:30, sven falempin wrote:
> > >> > behavior confirmed on current.
> > >> >
> > >> > Once the process stalls,  ( could be anything writing to the vnconfig
> > >> disk,
> > >> > cp , umount )
> > >> > a few other calls like df , or ps, etc may hang, never the same
> > >> > sp or mp kernel, reproduced on today's snapshots.
> > >>
> > >> vnconfig is used as part of "make release", many builds are done every
> > >> week using this so it's not a general problem with vnconfig.
> > >>
> > >> Can you show some commands or a script to trigger the behaviour?
> > >>
> > >
> > > the perl script use the system to call :
> > >
> > > vnconfig.
> > > mount.
> > > umount. <- saw hanged
> > > cp.<- saw hanged
> > > tar.<- saw hanged
> > > svn up.<- saw hanged
> > > and dd.
> > > newfs.
> > >
> > > really nothing fancy, only stuff writing to disk got stuck.
> > >
> > > At one point it does a chroot but it never hangs near that , most of the
> > > time it hangs before.
> > >
> > > The script has been used like 1000 times on 6.0 and maybe twice more on
> > > 6.4.
> > >
> > > I have absolutely no idea what the 'needbuf' of top is .
> > >
> > > the script hangs at random position , always writing into vnconfig.
> > >
> > > I have no idea how to reproduce outside the perl script , so maybe it is
> > > related
> > > to some devious perl stdin/stdout buffer .
> > >
> > > Nevertheless there's like a 5% chance that's the script will work( slowly 
> > > )
> > >
> > > Most of the system call are inside a routine to log
> > >
> > > sub debug_system {
> > >   $logger->debug('running: '.join(' ', @_));
> > >   return system(@_);
> > > }
> > >
> > > so i can easily put things inside to try to understand the issue.
> > >
> > > It is really a strange behavior, and the device must be shut down
> > > electrically.
> > > Something really odd, i run syslogd on a buffer, and syslogc buffer is
> > > stuck too
> > > when the device stuck (but it supposed to be mostly already allocated
> > > memory ).
> > >
> > > It's really like the vm does not want to give anymore bucket (<- i
> > > don't know what i m talking about here,
> > > but i looks like that anything that doesn't malloc is ok , computer reply
> > > to ping , can do a few things for a while , and then complete
> > > hang )
> > >
> > > I ran the 6.7 release on a VM somewhere and another device with many perl
> > > script and they work.
> > >
> > > Only this fails 95% of the time and is VERY VERY slow when ok.
> > > compared to what i saw in /usr/src the vnconfig is big ,  ( forgot to copy
> > > df -h  ),
> > > like 2GB
> > >
> > 
> > 
> > i put ktrace in front of the perl system call
> > 
> > An di was able to recover a 800MB trace
> > 
> > $ kdump -f ./trace.out | tail -20
> > kdump: realloc: Cannot allocate memory
> >  25955         UNKNOWN(1634890859)
> >  72466 ?????????     CALL  syscall()
> > 
> > 
> > could that be of some use ?
> > 
> > 
> > -- 
> > --
> > ---------------------------------------------------------------------------------------------------------------------
> > Knowing is not enough; we must apply. Willing is not enough; we must do
> 
> 

Reply via email to