16.10.2014 01:41, Anatol Pomozov wrote:
True. module name should be enough. In this case to debug the issue user needs:
- disable failing udev rule (or blacklist module?)
- reboot, it will let the user get into shell
- modprobe the failing module
- use sysrq-trigger to get more informatio
Hi
On Fri, Oct 10, 2014 at 3:45 PM, Tom Gundersen wrote:
> On Fri, Oct 10, 2014 at 11:54 PM, Anatol Pomozov
> wrote:
>> 1) Why not to make the timeout configurable through config file? There
>> is already udev.conf you can put config option there. Thus people with
>> modprobe issues can easily "
On Fri, Oct 10, 2014 at 11:54 PM, Anatol Pomozov
wrote:
> 1) Why not to make the timeout configurable through config file? There
> is already udev.conf you can put config option there. Thus people with
> modprobe issues can easily "fix" the problem. And then decrease
> default timeout back to 30 s
Hi
On Fri, Sep 12, 2014 at 1:09 PM, Luis R. Rodriguez
wrote:
> On Thu, Sep 11, 2014 at 10:48 PM, Tom Gundersen wrote:
>> On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez
>> wrote:
>>> On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen wrote:
How about simply introducing a new flag to finit
On Tue, Sep 30, 2014 at 11:06:34PM +0200, Pavel Machek wrote:
>
> On Mon 2014-09-22 13:23:54, Dmitry Torokhov wrote:
> > On Monday, September 22, 2014 09:49:06 PM Pavel Machek wrote:
> > > On Thu 2014-09-11 13:23:54, Dmitry Torokhov wrote:
> > > > On Thu, Sep 11, 2014 at 12:59:25PM -0700, James Bo
On Mon 2014-09-22 13:23:54, Dmitry Torokhov wrote:
> On Monday, September 22, 2014 09:49:06 PM Pavel Machek wrote:
> > On Thu 2014-09-11 13:23:54, Dmitry Torokhov wrote:
> > > On Thu, Sep 11, 2014 at 12:59:25PM -0700, James Bottomley wrote:
> > > > Yes, but we mostly do this anyway. SCSI for ins
On Monday, September 22, 2014 09:49:06 PM Pavel Machek wrote:
> On Thu 2014-09-11 13:23:54, Dmitry Torokhov wrote:
> > On Thu, Sep 11, 2014 at 12:59:25PM -0700, James Bottomley wrote:
> > > On Tue, 2014-09-09 at 16:01 -0700, Dmitry Torokhov wrote:
> > > > On Tuesday, September 09, 2014 03:46:23 PM
On Thu 2014-09-11 13:23:54, Dmitry Torokhov wrote:
> On Thu, Sep 11, 2014 at 12:59:25PM -0700, James Bottomley wrote:
> >
> > On Tue, 2014-09-09 at 16:01 -0700, Dmitry Torokhov wrote:
> > > On Tuesday, September 09, 2014 03:46:23 PM James Bottomley wrote:
> > > > On Wed, 2014-09-10 at 07:41 +0900,
On Mon, Sep 8, 2014 at 7:57 PM, Luis R. Rodriguez
wrote:
>> Why do we care about the priority of probing tasks? Does that
>> actually make any meaningful difference? If so, how?
>
> As I noted before -- I have yet to provide clear metrics but at least
> changing both init paths + probe from fini
On Tue, Sep 9, 2014 at 4:03 PM, Tejun Heo wrote:
> On Tue, Sep 09, 2014 at 12:25:29PM +0900, Tejun Heo wrote:
>> Hello,
>>
>> On Mon, Sep 08, 2014 at 08:19:12PM -0700, Luis R. Rodriguez wrote:
>> > On the systemd side of things it should enable this sysctl and for
>> > older kernels what should it
On Thu, Sep 11, 2014 at 10:48 PM, Tom Gundersen wrote:
> On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez
> wrote:
>> On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen wrote:
>>> How about simply introducing a new flag to finit_module() to indicate
>>> that the caller does not care about asynchr
On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez
wrote:
> On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen wrote:
>> How about simply introducing a new flag to finit_module() to indicate
>> that the caller does not care about asynchronicity. We could then pass
>> this from udev, but existing scr
On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen wrote:
> On Wed, Sep 10, 2014 at 11:10 PM, Luis R. Rodriguez
> wrote:
More than two years
have gone by on growing design and assumptions on top of that original
commit. I'm not sure if *systemd folks* yet believe its was a design
On Wed, Sep 10, 2014 at 11:10 PM, Luis R. Rodriguez
wrote:
>>> More than two years
>>> have gone by on growing design and assumptions on top of that original
>>> commit. I'm not sure if *systemd folks* yet believe its was a design
>>> regression?
>>
>> I don't think so. udev should not allow its w
On Thu, Sep 11, 2014 at 1:53 PM, Dmitry Torokhov
wrote:
> On Thu, Sep 11, 2014 at 01:42:20PM -0700, Luis R. Rodriguez wrote:
>> On Thu, Sep 11, 2014 at 1:23 PM, Dmitry Torokhov
>> wrote:
>> >
>> >> There are elements in common, but by and
>> >> large the biggest headaches at least in large devic
On Thu, Sep 11, 2014 at 01:42:20PM -0700, Luis R. Rodriguez wrote:
> On Thu, Sep 11, 2014 at 1:23 PM, Dmitry Torokhov
> wrote:
> >
> >> There are elements in common, but by and
> >> large the biggest headaches at least in large device number boots have
> >> already been tackled by the enterprise
On Thu, Sep 11, 2014 at 1:23 PM, Dmitry Torokhov
wrote:
>
>> There are elements in common, but by and
>> large the biggest headaches at least in large device number boots have
>> already been tackled by the enterprise crowd (they don't like their
>> S390's or 1024 core NUMA systems taking half an
On Thu, Sep 11, 2014 at 12:59:25PM -0700, James Bottomley wrote:
>
> On Tue, 2014-09-09 at 16:01 -0700, Dmitry Torokhov wrote:
> > On Tuesday, September 09, 2014 03:46:23 PM James Bottomley wrote:
> > > On Wed, 2014-09-10 at 07:41 +0900, Tejun Heo wrote:
> > > >
> > > > The thing is that we have
On Tue, 2014-09-09 at 16:01 -0700, Dmitry Torokhov wrote:
> On Tuesday, September 09, 2014 03:46:23 PM James Bottomley wrote:
> > On Wed, 2014-09-10 at 07:41 +0900, Tejun Heo wrote:
> > >
> > > The thing is that we have to have dynamic mechanism to listen for
> > > device attachments no matter wh
11.09.2014 03:10, Luis R. Rodriguez wrote:
Tom, thanks for reviewing this! My reply below!
On Tue, Sep 9, 2014 at 11:46 PM, Tom Gundersen wrote:
On Tue, Sep 9, 2014 at 10:45 PM, Luis R. Rodriguez
wrote:
On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley
wrote:
On Tue, 2014-09-09 at 12:16 -07
Tom, thanks for reviewing this! My reply below!
On Tue, Sep 9, 2014 at 11:46 PM, Tom Gundersen wrote:
> On Tue, Sep 9, 2014 at 10:45 PM, Luis R. Rodriguez
> wrote:
>> On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley
>> wrote:
>>> On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote:
On Wed, 2014-09-10 at 12:07 +0200, Ceriel Jacobs wrote:
> Tom Gundersen schreef op 10-09-14 om 08:46:
> >> >Indeed. What I proposed with a multiplier for the timeout for the
> >> >different types of built in commands was deemed complex but saw no
> >> >alternatives proposed despite my interest to w
Tom Gundersen schreef op 10-09-14 om 08:46:
>Indeed. What I proposed with a multiplier for the timeout for the
>different types of built in commands was deemed complex but saw no
>alternatives proposed despite my interest to work on one and
>clarifications noted that this was a design regression.
On Tue, Sep 9, 2014 at 10:45 PM, Luis R. Rodriguez
wrote:
> On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley
> wrote:
>> On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote:
>>> On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
>>> wrote:
>>> > If we want to sort out some sync/async mechan
On Tue, Sep 9, 2014 at 3:26 AM, Luis R. Rodriguez
wrote:
> On Mon, Sep 8, 2014 at 6:22 PM, Tejun Heo wrote:
>> On Tue, Sep 09, 2014 at 10:10:59AM +0900, Tejun Heo wrote:
>>> I'm not too convinced this is such a difficult problem to figure out.
>>> We already have most of logic in place and the on
On Tue, Sep 09, 2014 at 12:25:29PM +0900, Tejun Heo wrote:
> Hello,
>
> On Mon, Sep 08, 2014 at 08:19:12PM -0700, Luis R. Rodriguez wrote:
> > On the systemd side of things it should enable this sysctl and for
> > older kernels what should it do?
>
> Supposing the change is backported via -stable
On Tuesday, September 09, 2014 03:46:23 PM James Bottomley wrote:
> On Wed, 2014-09-10 at 07:41 +0900, Tejun Heo wrote:
> >
> > The thing is that we have to have dynamic mechanism to listen for
> > device attachments no matter what and such mechanism has been in place
> > for a long time at this p
Hello, James.
On Tue, Sep 09, 2014 at 03:46:23PM -0700, James Bottomley wrote:
> If you want the return of an individual device probe a log scraper gives
> it to you ... and nothing else does currently. The advantage of the
> prink in dd.c is that it's standard for everything and can be scanned
>
On Wed, 2014-09-10 at 07:41 +0900, Tejun Heo wrote:
> Hello,
>
> On Tue, Sep 09, 2014 at 03:26:02PM -0700, James Bottomley wrote:
> > > We no longer report back error on probe failure on module load.
> >
> > Yes, we do; for every probe failure of a device on a driver we'll print
> > a warning (se
Hello,
On Tue, Sep 09, 2014 at 03:26:02PM -0700, James Bottomley wrote:
> > We no longer report back error on probe failure on module load.
>
> Yes, we do; for every probe failure of a device on a driver we'll print
> a warning (see drivers/base/dd.c). Now if someone is proposing we
> should rep
On Wed, 2014-09-10 at 06:42 +0900, Tejun Heo wrote:
> Hey, James.
>
> On Tue, Sep 09, 2014 at 12:35:46PM -0700, James Bottomley wrote:
> > I don't have very strong views on this one. However, I've got to say
> > from a systems point of view that if the desire is to flag when the
> > module is hav
On Tue, 9 Sep 2014, Luis R. Rodriguez wrote:
> By design it seems systemd should not allow worker processes to block
> indefinitely and in fact it currently uses the same timeout for all
> types of worker processes.
And I whole-heartedly believe this is something that fundamentally needs
to be
Hey, James.
On Tue, Sep 09, 2014 at 12:35:46PM -0700, James Bottomley wrote:
> I don't have very strong views on this one. However, I've got to say
> from a systems point of view that if the desire is to flag when the
> module is having problems, probing and initializing synchronously in a
> thre
On Tue, Sep 9, 2014 at 12:35 PM, James Bottomley
wrote:
> On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote:
>> On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
>> wrote:
>> > If we want to sort out some sync/async mechanism for probing devices, as
>> > an agreement between the init syst
On Tue, 2014-09-09 at 12:16 -0700, Luis R. Rodriguez wrote:
> On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
> wrote:
> > If we want to sort out some sync/async mechanism for probing devices, as
> > an agreement between the init systems and the kernel, that's fine, but
> > its a to-be negotiated
On Mon, Sep 8, 2014 at 10:38 PM, James Bottomley
wrote:
> On Tue, 2014-09-09 at 10:10 +0900, Tejun Heo wrote:
>> Hello, Luis.
>>
>> On Mon, Sep 08, 2014 at 06:04:23PM -0700, Luis R. Rodriguez wrote:
>> > > I have no idea how the selection should be. It could be per-insmod or
>> > > maybe just a s
On Tue, 2014-09-09 at 10:10 +0900, Tejun Heo wrote:
> Hello, Luis.
>
> On Mon, Sep 08, 2014 at 06:04:23PM -0700, Luis R. Rodriguez wrote:
> > > I have no idea how the selection should be. It could be per-insmod or
> > > maybe just a system-wide flag with explicit exceptions marked on
> > > driver
Hello,
On Mon, Sep 08, 2014 at 08:19:12PM -0700, Luis R. Rodriguez wrote:
> On the systemd side of things it should enable this sysctl and for
> older kernels what should it do?
Supposing the change is backported via -stable, it can try to set the
sysctl on all kernels. If the knob doesn't exist
On Mon, Sep 8, 2014 at 8:03 PM, Tejun Heo wrote:
> On Mon, Sep 08, 2014 at 07:57:28PM -0700, Luis R. Rodriguez wrote:
>> > I think we
>> > just should make exceptions sensible so that it works fine in practice
>> > for now (and I don't think that'd be too hard). So, the only
>> > cooperation nece
On Mon, Sep 08, 2014 at 07:57:28PM -0700, Luis R. Rodriguez wrote:
> > I think we
> > just should make exceptions sensible so that it works fine in practice
> > for now (and I don't think that'd be too hard). So, the only
> > cooperation necessary from userland would be just saying "I don't
> > wa
On Mon, Sep 8, 2014 at 7:39 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Sep 08, 2014 at 07:28:58PM -0700, Luis R. Rodriguez wrote:
>> > Given that the behvaior change is from driver core and that device
>> > probing can happen post-loading anyway,
>>
>> Ah but lets not forget Dmitry's requirement wh
Hello,
On Mon, Sep 08, 2014 at 07:28:58PM -0700, Luis R. Rodriguez wrote:
> > Given that the behvaior change is from driver core and that device
> > probing can happen post-loading anyway,
>
> Ah but lets not forget Dmitry's requirement which is for in-kernel
> drivers. We'd need to deal with bot
On Mon, Sep 8, 2014 at 6:47 PM, Tejun Heo wrote:
> Hello,
>
> On Mon, Sep 08, 2014 at 06:38:34PM -0700, Luis R. Rodriguez wrote:
>> OK then one only concern I would have with this is that the presence
>> of such a flag doesn't necessarily mean that all drivers on a system
>> have been tested for a
Hello,
On Mon, Sep 08, 2014 at 06:38:34PM -0700, Luis R. Rodriguez wrote:
> OK then one only concern I would have with this is that the presence
> of such a flag doesn't necessarily mean that all drivers on a system
> have been tested for asynch probe yet. I'd feel much more comfortable
Given tha
On Mon, Sep 8, 2014 at 6:29 PM, Tejun Heo wrote:
> On Mon, Sep 08, 2014 at 06:26:04PM -0700, Luis R. Rodriguez wrote:
>> > Alternatively, add a module-generic param "async_probe" or whatever
>> > and use that to switch the behavior should work too. I don't know
>> > which way is better but either
On Mon, Sep 08, 2014 at 06:26:04PM -0700, Luis R. Rodriguez wrote:
> > Alternatively, add a module-generic param "async_probe" or whatever
> > and use that to switch the behavior should work too. I don't know
> > which way is better but either should work fine.
>
> I take it by this you meant a g
On Mon, Sep 8, 2014 at 6:22 PM, Tejun Heo wrote:
> On Tue, Sep 09, 2014 at 10:10:59AM +0900, Tejun Heo wrote:
>> I'm not too convinced this is such a difficult problem to figure out.
>> We already have most of logic in place and the only thing missing is
>> how to switch it. Wouldn't something li
On Tue, Sep 09, 2014 at 10:10:59AM +0900, Tejun Heo wrote:
> I'm not too convinced this is such a difficult problem to figure out.
> We already have most of logic in place and the only thing missing is
> how to switch it. Wouldn't something like the following work?
>
> * Add a sysctl knob to enab
On Tue, Sep 09, 2014 at 10:10:59AM +0900, Tejun Heo wrote:
> * Identify cases which can't be asynchronous and make them
> synchronous. e.g. keep who's doing request_module() and avoid
> asynchronous probing if current is probing one of those.
That wouldn't work as we don't know what's gonna h
Hello, Luis.
On Mon, Sep 08, 2014 at 06:04:23PM -0700, Luis R. Rodriguez wrote:
> > I have no idea how the selection should be. It could be per-insmod or
> > maybe just a system-wide flag with explicit exceptions marked on
> > drivers is good enough. I don't know.
>
> Its perfectly understandab
On Fri, Sep 5, 2014 at 3:40 PM, Tejun Heo wrote:
> Hello, Luis.
>
> On Fri, Sep 05, 2014 at 11:12:17AM -0700, Luis R. Rodriguez wrote:
>> Meanwhile we are allowing a major design consideration such as a 30
>> second timeout for both init + probe all of a sudden become a hard
>> requirement for dev
Hey,
On Fri, Sep 05, 2014 at 04:22:42PM -0700, Dmitry Torokhov wrote:
> > I don't get it. This is a behavior userland already depends on for
> > boots. What's there to agree or disagree? This is just a fact that
> > we can't do this w/o disturbing some userlands in a major way.
>
> I am just e
Hi Tejun,
On Sat, Sep 06, 2014 at 07:55:33AM +0900, Tejun Heo wrote:
> Hello, Dmitry.
>
> On Fri, Sep 05, 2014 at 03:49:17PM -0700, Dmitry Torokhov wrote:
> > On Sat, Sep 06, 2014 at 07:31:39AM +0900, Tejun Heo wrote:
> > > On Sat, Sep 06, 2014 at 07:29:56AM +0900, Tejun Heo wrote:
> > > > It is
On Fri, Sep 05, 2014 at 04:05:30PM -0700, Arjan van de Ven wrote:
> On 9/5/2014 3:52 PM, Dmitry Torokhov wrote:
> >On Fri, Sep 05, 2014 at 03:45:08PM -0700, Arjan van de Ven wrote:
> >>On 9/5/2014 3:29 PM, Tejun Heo wrote:
> >>>Hello, Dmitry.
> >>>
> >>>On Fri, Sep 05, 2014 at 11:10:03AM -0700, Dmi
On 9/5/2014 3:52 PM, Dmitry Torokhov wrote:
On Fri, Sep 05, 2014 at 03:45:08PM -0700, Arjan van de Ven wrote:
On 9/5/2014 3:29 PM, Tejun Heo wrote:
Hello, Dmitry.
On Fri, Sep 05, 2014 at 11:10:03AM -0700, Dmitry Torokhov wrote:
I do not agree that it is actually user-visible change: generally
Hello,
On Fri, Sep 05, 2014 at 03:52:48PM -0700, Dmitry Torokhov wrote:
> Ahem... and they sure it works reliably with large storage arrays? With
> SCSI doing probing asynchronously already?
I believe this has been mentioned before too but, yes, SCSI device
probing is asynchronous and parallelize
Hello, Dmitry.
On Fri, Sep 05, 2014 at 03:49:17PM -0700, Dmitry Torokhov wrote:
> On Sat, Sep 06, 2014 at 07:31:39AM +0900, Tejun Heo wrote:
> > On Sat, Sep 06, 2014 at 07:29:56AM +0900, Tejun Heo wrote:
> > > It is for storage devices which always have guaranteed synchronous
> > > probing on modu
On Fri, Sep 05, 2014 at 03:45:08PM -0700, Arjan van de Ven wrote:
> On 9/5/2014 3:29 PM, Tejun Heo wrote:
> >Hello, Dmitry.
> >
> >On Fri, Sep 05, 2014 at 11:10:03AM -0700, Dmitry Torokhov wrote:
> >>I do not agree that it is actually user-visible change: generally speaking
> >>you
> >>do not real
On 9/5/2014 3:29 PM, Tejun Heo wrote:
Hello, Dmitry.
On Fri, Sep 05, 2014 at 11:10:03AM -0700, Dmitry Torokhov wrote:
I do not agree that it is actually user-visible change: generally speaking you
do not really know if device is there or not. They come and go. Like I said,
consider all permutat
Hello, Luis.
On Fri, Sep 05, 2014 at 11:12:17AM -0700, Luis R. Rodriguez wrote:
> Meanwhile we are allowing a major design consideration such as a 30
> second timeout for both init + probe all of a sudden become a hard
> requirement for device drivers. I see your point but can't also be
> introduc
On Sat, Sep 06, 2014 at 07:29:56AM +0900, Tejun Heo wrote:
> It is for storage devices which always have guaranteed synchronous
> probing on module load and well-defined probing order. Sure, modern
> setups are a lot more dynamic but I'm quite certain that there are
> setups in the wild which depe
Hello, Dmitry.
On Fri, Sep 05, 2014 at 11:10:03AM -0700, Dmitry Torokhov wrote:
> I do not agree that it is actually user-visible change: generally speaking you
> do not really know if device is there or not. They come and go. Like I said,
> consider all permutations, with hot-pluggable buses, def
On Fri, Sep 05, 2014 at 11:12:17AM -0700, Luis R. Rodriguez wrote:
> On Fri, Sep 5, 2014 at 10:49 AM, Tejun Heo wrote:
> > Hello,
> >
> > On Fri, Sep 05, 2014 at 09:44:05AM -0700, Dmitry Torokhov wrote:
> >> Which problem are we talking about here though? It does solve the slow
> >> device
> >> s
On Fri, Sep 5, 2014 at 10:49 AM, Tejun Heo wrote:
> Hello,
>
> On Fri, Sep 05, 2014 at 09:44:05AM -0700, Dmitry Torokhov wrote:
>> Which problem are we talking about here though? It does solve the slow device
>> stalling the rest if the kernel booting (non-module case) for me.
>
> The other one.
On Sat, Sep 06, 2014 at 02:49:25AM +0900, Tejun Heo wrote:
> Hello,
>
> On Fri, Sep 05, 2014 at 09:44:05AM -0700, Dmitry Torokhov wrote:
> > Which problem are we talking about here though? It does solve the slow
> > device
> > stalling the rest if the kernel booting (non-module case) for me.
>
>
Hello,
On Fri, Sep 05, 2014 at 09:44:05AM -0700, Dmitry Torokhov wrote:
> Which problem are we talking about here though? It does solve the slow device
> stalling the rest if the kernel booting (non-module case) for me.
The other one. The one with timeout. Neither cxgb4 or pata_marvell
has slow
On Fri, Sep 05, 2014 at 12:59:49PM +0200, Oleg Nesterov wrote:
> On 09/04, Luis R. Rodriguez wrote:
> >
> > From: "Luis R. Rodriguez"
> >
> > The new umh kill option has allowed kthreads to receive
> > kill signals but they are generally accepting all sources
> > of kill signals
>
> And I think t
On Friday, September 05, 2014 11:12:41 PM Tejun Heo wrote:
> On Fri, Sep 05, 2014 at 12:47:16AM -0700, Luis R. Rodriguez wrote:
> > Ah -- well without it the way we "find" drivers that need this new
> > "async feature" is by a bug report and folks saying their system can't
> > boot, or they say the
On Fri, Sep 05, 2014 at 12:47:16AM -0700, Luis R. Rodriguez wrote:
> Ah -- well without it the way we "find" drivers that need this new
> "async feature" is by a bug report and folks saying their system can't
> boot, or they say their device doesn't come up. That's all. Tracing
> this to systemd an
On 09/04, Luis R. Rodriguez wrote:
>
> From: "Luis R. Rodriguez"
>
> The new umh kill option has allowed kthreads to receive
> kill signals but they are generally accepting all sources
> of kill signals
And I think this is right,
> while the original motivation was to enable
> through the OOM fr
On Fri, 2014-09-05 at 00:47 -0700, Luis R. Rodriguez wrote:
> On Fri, Sep 5, 2014 at 12:19 AM, Tejun Heo wrote:
> > On Thu, Sep 04, 2014 at 11:37:24PM -0700, Luis R. Rodriguez wrote:
> > ...
> >> + /*
> >> + * I got SIGKILL, but wait for 60 more seconds for completion
> >
On Fri, Sep 5, 2014 at 12:19 AM, Tejun Heo wrote:
> On Thu, Sep 04, 2014 at 11:37:24PM -0700, Luis R. Rodriguez wrote:
> ...
>> + /*
>> + * I got SIGKILL, but wait for 60 more seconds for completion
>> + * unless chosen by the OOM killer. This delay is there a
On Thu, Sep 04, 2014 at 11:37:24PM -0700, Luis R. Rodriguez wrote:
...
> + /*
> + * I got SIGKILL, but wait for 60 more seconds for completion
> + * unless chosen by the OOM killer. This delay is there as a
> + * workaround for boot failure caused
From: "Luis R. Rodriguez"
The new umh kill option has allowed kthreads to receive
kill signals but they are generally accepting all sources
of kill signals while the original motivation was to enable
through the OOM from sending the kill. One particular user
which has been found to send kill sign
74 matches
Mail list logo
