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 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
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
13 matches
Mail list logo
