> 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
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
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
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
> > >>
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
> >> >
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
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`
>
> > 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
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 )
>
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
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
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
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
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
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
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
I'm experiencing the same thing.
OpenBSD5.8-STABLE on vmware.
The message is repeatedly spammed to the console.
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!"
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
19 matches
Mail list logo