Friday, December 02, 2022

Re: Possible Bug - 7.1 stable - scsi_xfer pool exhausted

On Fri Dec 2, 2022 at 5:52 PM CET, Sven F. wrote:
> On Fri, Dec 2, 2022 at 11:33 AM Stuart Henderson
> <stu.lists@spacehopper.org> wrote:
> >
> > On 2022-12-02, Sven F. <sven.falempin@gmail.com> wrote:
> > > Hello,
> > >
> > > Main problem is the kernel goes into a loop and never break,
> > > so no ddb
> > > I have similar setups (same driver and stack) , and this one only
> > > is more prone to the error, even if the virt / qemu driver is partly responsible
> > > the kernel should not loop the `scsi_xfer pool exhausted`
> > > message for ever and maybe fall into ddb after a while or
> > > handle this differently.
> > >
> > > Is there's step I can do to avoid or better document the bug ?
> > > ( i would very much like not upgrading 7.2 just yet this one )
> > >
> > > * I had eye on it :
> > >
> > > load averages: 5.22, 2.50, 1.74
> > > 111 processes: 3 running, 107 idle, 1 on processor
> > > CPU states: 0.0% user, 0.0% nice, 34.3% sys, 0.0% spin, 0.0% intr,
> > > 65.7% idle
> > > Memory: Real: 1101M/1915M act/tot Free: 24K Cache: 96M Swap: 1012M/1012M
> >
> > You have run out of RAM, don't do that
> >
> >
>
> Okay i will tweak login.conf more, but what did run out of ram :'(

You can start with 'man systat' and its default screen and pool and
vmstat -m plus of course in your top(1) output you can sor on size/res
to see what is using most, but even on your output it looks like that
MariaDB and something in perl
>
> --
> --
> ---------------------------------------------------------------------------------------------------------------------
> Knowing is not enough; we must apply. Willing is not enough; we must do

No comments:

Post a Comment