Re: Possible Bug - 7.1 stable - scsi_xfer pool exhausted

> On Dec 3, 2022, at 09:06, Stuart Henderson wrote: > AFAIK the main options available at that point are: > > deadlocks waiting for resources > detect the problem and randomly kill processes (e.g. linux oom killer) > detect the problem and panic I recall a long time ago reading on LKML that

Re: Possible Bug - 7.1 stable - scsi_xfer pool exhausted

On Sat, Dec 3, 2022 at 12:08 PM Stuart Henderson wrote: > > On 2022-12-03, Sven F. wrote: > > Bit sad the kernel stopped working thought. > > AFAIK the main options available at that point are: > > deadlocks waiting for resources > detect the problem and randomly kill processes (e.g. linux oom

Re: Possible Bug - 7.1 stable - scsi_xfer pool exhausted

On 2022-12-03, Sven F. wrote: > Bit sad the kernel stopped working thought. AFAIK the main options available at that point are: deadlocks waiting for resources detect the problem and randomly kill processes (e.g. linux oom killer) detect the problem and panic There isn't really a lot else it

Re: Possible Bug - 7.1 stable - scsi_xfer pool exhausted

2, Sven F. 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 > > >>

Re: Possible Bug - 7.1 stable - scsi_xfer pool exhausted

ain 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 > >> >

Re: Possible Bug - 7.1 stable - scsi_xfer pool exhausted

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 a

Re: Possible Bug - 7.1 stable - scsi_xfer pool exhausted

gt; 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` >

Re: Possible Bug - 7.1 stable - scsi_xfer pool exhausted

> > 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 st

Re: Possible Bug - 7.1 stable - scsi_xfer pool exhausted

e > 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 ) >

Re: Possible Bug - 7.1 stable - scsi_xfer pool exhausted

tly > 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

Possible Bug - 7.1 stable - scsi_xfer pool exhausted

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

Re: scsi_xfer pool exhausted

On Wed, Mar 14 2018, Tor Houghton wrote: > On Wed, Mar 14, 2018 at 05:56:19PM +0100, Tor Houghton wrote: >> On Tue, Mar 13, 2018 at 11:23:12PM -0700, Peter van Oord v/d Vlies wrote: >> > Hello Martijn, >> > >> > Did you ever found an solution ? >> > I have the same at a customer

Re: scsi_xfer pool exhausted

On Wed, Mar 14, 2018 at 05:56:19PM +0100, Tor Houghton wrote: > On Tue, Mar 13, 2018 at 11:23:12PM -0700, Peter van Oord v/d Vlies wrote: > > Hello Martijn, > > > > Did you ever found an solution ? > > I have the same at a customer system. > > > > I'd like to chip in with a "me too" here. It's

Re: scsi_xfer pool exhausted

2 device. I say "suddenly" because it started happening after I did syspatch on a default 6.2 amd64 install. I reverted all the patches (syspatch -r a few times), but it seems it has not helped. Usually ends up dumping "scsi_xfer pool exhausted!" repeatedly on the console af

Re: scsi_xfer pool exhausted

Hello Martijn, Did you ever found an solution ? I have the same at a customer system. -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-user-misc-f3.html

scsi_xfer pool exhausted

Hello misc@, A customer system of mine has problems with the system since this morning (happened 3 times so far). The dmesg shows a large number "scsi_xfer pool exhausted" messages. Right now I have no idea on how to debug this any further. Cluestick more than welcome $ dmesg O

Re: Computer hangup : scsi_xfer pool exhausted!

I'm experiencing the same thing. OpenBSD5.8-STABLE on vmware. The message is repeatedly spammed to the console.

Re: Computer hangup : scsi_xfer pool exhausted!

On Wed, Jan 27, 2016 at 10:31:28AM +, Sébastien Morand wrote: Hello Sébastien, > I have a computer hanging up every 4/5 days. It's no more accessible by > network and keyboard is not responding. The only message displayed in > console log is "scsi_xfer pool exhausted!"

Computer hangup : scsi_xfer pool exhausted!

Hi, I have a computer hanging up every 4/5 days. It's no more accessible by network and keyboard is not responding. The only message displayed in console log is "scsi_xfer pool exhausted!" which is documented by : /* * in this situation we should queue things waiting for an * xs and