> 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 ki
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 co
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
> > >>
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
> >> > th
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
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`
> > > mess
; > 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'
t; 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
gt; 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 for
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 system.
>> >
>>
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 "
y apu2c2 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
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
* x
19 matches
Mail list logo
