On Tue, Nov 01, 2005 at 09:35:35AM +0100, Marco d'Itri wrote:
> On Nov 01, Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> > Hmm, if the root filesystem is read-only, then the locking will fail
> > (you need to open a file read/write to get an exclusive fcntl lock).
> > Perhaps this is happening to y
On Nov 01, Rusty Russell <[EMAIL PROTECTED]> wrote:
> Hmm, if the root filesystem is read-only, then the locking will fail
> (you need to open a file read/write to get an exclusive fcntl lock).
> Perhaps this is happening to you? If not, please check again that you
Sure, all of this happens when
On Mon, 2005-10-31 at 19:53 +0100, Marco d'Itri wrote:
> On Oct 29, Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> > Please send complete log.
> Here it is. I can reproduce the bug even with a script like:
>
> while read m; do
> /sbin/modprobe.real $m &
> done < LIST
>
>
> (Each command was log
On Oct 29, Rusty Russell <[EMAIL PROTECTED]> wrote:
> Please send complete log.
Here it is. I can reproduce the bug even with a script like:
while read m; do
/sbin/modprobe.real $m &
done < LIST
(Each command was logged to different files which have been sorted by
PID and reassembled.)
=[ pi
On Fri, 2005-10-28 at 15:08 +0200, Marco d'Itri wrote:
> On Oct 28, Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> > The latter is the simplest option. Please try this patch (it will be in
> > the next release, too). If it seems to work, please ack.
> No luck.
Please send complete log.
I might n
On Oct 28, Rusty Russell <[EMAIL PROTECTED]> wrote:
> The latter is the simplest option. Please try this patch (it will be in
> the next release, too). If it seems to work, please ack.
No luck.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Fri, Oct 28, 2005 at 05:24:44PM +1000, Rusty Russell wrote:
> On Thu, 2005-10-27 at 10:10 +0200, Marco d'Itri wrote:
> > And then it fails for ehci-hcd too (which is not loaded at all).
> > Rusty, do you have other ideas for debugging?
>
> I have reread the bug reports, and meditated on this is
On Thu, 2005-10-27 at 10:10 +0200, Marco d'Itri wrote:
> And then it fails for ehci-hcd too (which is not loaded at all).
> Rusty, do you have other ideas for debugging?
I have reread the bug reports, and meditated on this issue some more.
This is a possibility I was aware of when I changed to cod
On Oct 27, Horms <[EMAIL PROTECTED]> wrote:
> > There is no serialization, only some throttling (IIRC it tries to run up
> > to 10 child processes in parallel).
> Ok, but it runs modprobe, not ismod, right?
Yes.
> > As Rusty suggested I wrapped /sbin/modprobe in a logger script, but so
> > far I
On Wed, Oct 26, 2005 at 09:37:54AM +0200, Marco d'Itri wrote:
> On Oct 26, Horms <[EMAIL PROTECTED]> wrote:
>
> > Just to clarify, udevd gets a bunch of events and tries to
> > serialise them into modprobe calls, right? Do you think there
> There is no serialization, only some throttling (IIRC it
On Oct 26, Horms <[EMAIL PROTECTED]> wrote:
> Just to clarify, udevd gets a bunch of events and tries to
> serialise them into modprobe calls, right? Do you think there
There is no serialization, only some throttling (IIRC it tries to run up
to 10 child processes in parallel).
> is any chance it
On Fri, Oct 21, 2005 at 04:54:35PM +0200, Marco d'Itri wrote:
> On Oct 21, Horms <[EMAIL PROTECTED]> wrote:
>
> > I did a bit of a poke around this symbols problem.
> > I puzzeled over it for a while. I began to wonder
> > if it might be caused byudevsynthesize[1] which seems
> > to be the major c
On Oct 21, Horms <[EMAIL PROTECTED]> wrote:
> I did a bit of a poke around this symbols problem.
> I puzzeled over it for a while. I began to wonder
> if it might be caused byudevsynthesize[1] which seems
> to be the major change between -2 and -4, and I completely
> failed in all my attempts to r
I did a bit of a poke around this symbols problem.
I puzzeled over it for a while. I began to wonder
if it might be caused byudevsynthesize[1] which seems
to be the major change between -2 and -4, and I completely
failed in all my attempts to reproduce the problem.
[1] http://marc.theaimsgroup.com
On Thu, Oct 20, 2005 at 09:44:07AM +0200, Marco d'Itri wrote:
> On Oct 20, Horms <[EMAIL PROTECTED]> wrote:
>
> > Could you please point me to the part of the code where udevd calls
> > modprobe and handles the subsequent SIGCHLD? That will be a good starting
> > poing
> > for further investigati
On Oct 20, Horms <[EMAIL PROTECTED]> wrote:
> Could you please point me to the part of the code where udevd calls
> modprobe and handles the subsequent SIGCHLD? That will be a good starting
> poing
> for further investigation.
run_program() in udev_utils_run.c, called from main in udev.c.
On Wed, Oct 19, 2005 at 03:14:53PM +0200, Marco d'Itri wrote:
> reassign 333522 linux-2.6
> thank
>
> On Oct 19, Rusty Russell <[EMAIL PROTECTED]> wrote:
>
> > Right. It's not a modprobe bug then. Thanks, that makes sense.
> Oops... I did not read correctly Rusty's answer.
> If it's not a modpr
reassign 333522 linux-2.6
thank
On Oct 19, Rusty Russell <[EMAIL PROTECTED]> wrote:
> Right. It's not a modprobe bug then. Thanks, that makes sense.
Oops... I did not read correctly Rusty's answer.
If it's not a modprobe bug and not an udev bug (I checked udevd and it
looks fine to me) then loo
On Oct 19, Horms <[EMAIL PROTECTED]> wrote:
> So, can someone remind me what is calling modprobe?
> The seems certain to be there.
In this case udevd does.
I have reassigned the bug to m-i-t.
--
ciao,
Marco
signature.asc
Description: Digital signature
On Tue, Oct 18, 2005 at 03:38:55PM +0200, Martin Wilck wrote:
> Rusty Russell wrote:
>
> >Martin Wilck <[EMAIL PROTECTED]> wrote:
> >
> >>0. the module loading tool runs during boot with PID 1.
> >
> >I do not understand how this can happen. request_module() cannot occur
> >until usermodehelper_i
On Tue, 2005-10-18 at 15:38 +0200, Martin Wilck wrote:
> Rusty Russell wrote:
>
> > Martin Wilck <[EMAIL PROTECTED]> wrote:
> >
> >>0. the module loading tool runs during boot with PID 1.
> >
> > I do not understand how this can happen. request_module() cannot occur
> > until usermodehelper_ini
Rusty Russell wrote:
Martin Wilck <[EMAIL PROTECTED]> wrote:
0. the module loading tool runs during boot with PID 1.
I do not understand how this can happen. request_module() cannot occur
until usermodehelper_init() is called. This is only done once the init
thread is spawned, which should
On Thu, 2005-10-13 at 23:07 +0200, Marco d'Itri wrote:
> Any comments?
Martin Wilck <[EMAIL PROTECTED]> wrote:
> 0. the module loading tool runs during boot with PID 1.
I do not understand how this can happen. request_module() cannot occur
until usermodehelper_init() is called. This is only don
I had a very simliar problem on Red Hat a while ago.
The scenario was as follows:
0. the module loading tool runs during boot with PID 1.
1. tool calls insmod for several stacked modules.
2. forks insmod for module 1
3. waits for insmod's completion with wait4(-1).
4. Some other process (e.g. /s
24 matches
Mail list logo
