> apparently not triggering, since it could be that Debian's initrd
> might cause some other uncaught recursion loop if we don't drive this
> problem determination to root cause.
Agreed - and there are all sorts of obscure and wonderful other ways to
trip this up which need the detector (AF_UNIX m
On Tue, Dec 9, 2008 at 02:09, Theodore Tso <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 08, 2008 at 04:35:20AM +0100, Kay Sievers wrote:
>> Sure, if we can make userspace behave nicely, I'm all for doing it. On
>> the other hand, I think it's a good thing to provide a sane
>> environment by the kernel
On Mon, Dec 08, 2008 at 04:35:20AM +0100, Kay Sievers wrote:
> Sure, if we can make userspace behave nicely, I'm all for doing it. On
> the other hand, I think it's a good thing to provide a sane
> environment by the kernel for any "non-initramfs-optimized" helper.
> Writing to /dev/console is a us
On Mon, Dec 08, 2008 at 04:06:46PM +0300, Evgeniy Polyakov wrote:
>
> Your patch does not apply cleanly to the latest git and missed
> rng dependency to rng2.
Right it was against cryptodev-2.6 actually. Thanks for fixing
it up and confirming. I'll submit this to Linus.
Cheers,
--
Visit Opensw
On Sun, Dec 07, 2008 at 11:55:07PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
> Having said that I think this patch should remove this particular
> trigger. Unfortunately I couldn't find a more succinct way of
> expressing this relationship: if ALGAPI is built-in because it's
> selected by an al
On Mon, Dec 8, 2008 at 04:23, <[EMAIL PROTECTED]> wrote:
> On Sun, 07 Dec 2008 19:22:41 +0100, Kay Sievers said:
>
>> We are _not_ loading a console driver that way, we try to load the
>> console device itself, not the driver. There is no driver for 5:1 in
>> any module.
[childish blurb removed]
On Mon, Dec 8, 2008 at 02:18, Theodore Tso <[EMAIL PROTECTED]> wrote:
> Let's take a step back, shall we? Fundamentally, what's going on here
> is that a particular distribution's initrd (Debian's, to be precise)
> is running into an error in response to a modprobe request for
> char-major-5-1, an
On Sun, 07 Dec 2008 19:22:41 +0100, Kay Sievers said:
> We are _not_ loading a console driver that way, we try to load the
> console device itself, not the driver. There is no driver for 5:1 in
> any module.
Semantic quibbling, trying to paper over stupidity.
It doesn't really matter if it's a "
Let's take a step back, shall we? Fundamentally, what's going on here
is that a particular distribution's initrd (Debian's, to be precise)
is running into an error in response to a modprobe request for
char-major-5-1, and it is attempting to write to the console, which is
resulting in another modp
On Sun, Dec 7, 2008 at 21:00, Alan Cox <[EMAIL PROTECTED]> wrote:
>> >max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT);
>> >atomic_inc(&kmod_concurrent);
>> >if (atomic_read(&kmod_concurrent) > max_modprobes) {
>> >/* We may be blaming an innocent here
> >max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT);
> >atomic_inc(&kmod_concurrent);
> >if (atomic_read(&kmod_concurrent) > max_modprobes) {
> >/* We may be blaming an innocent here, but unlikely */
> >if (kmod_loop_msg++ < 5)
> >
On Sun, Dec 7, 2008 at 19:31, Alan Cox <[EMAIL PROTECTED]> wrote:
>> > The loop is detected and terminated.
>>
>> No. Please back up what you are trying to talk about.
>
> Let me introduce you to.. drum roll.. the source code. Its a useful
> resource, why don't you use it for once.
>
>
>max
> > The loop is detected and terminated.
>
> No. Please back up what you are trying to talk about.
Let me introduce you to.. drum roll.. the source code. Its a useful
resource, why don't you use it for once.
max_modprobes = min(max_threads/2, MAX_KMOD_CONCURRENT);
atomic_inc(&km
On Sun, Dec 7, 2008 at 18:51, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sun, 7 Dec 2008 18:39:48 +0100
> "Kay Sievers" <[EMAIL PROTECTED]> wrote:
>
>> On Sun, Dec 7, 2008 at 18:28, Alan Cox <[EMAIL PROTECTED]> wrote:
>> >> > /dev/console is a logical mapping to a device which may well be
>> >> > dif
On Sun, Dec 7, 2008 at 19:15, Alan Cox <[EMAIL PROTECTED]> wrote:
>> Yes, log nowhere instead of running in a loop would be much better
>> than loading a 5:1 driver which will never exist as a module.
>
> The loop is detected and terminated.
No. Please back up what you are trying to talk about.
>
> Yes, log nowhere instead of running in a loop would be much better
> than loading a 5:1 driver which will never exist as a module.
The loop is detected and terminated.
>
> > Why is this useful - you now get failing module loads producing no
> > diagnostics and in many case the setup just dying
On Sun, Dec 7, 2008 at 19:03, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Sun, 7 Dec 2008 20:54:38 +0300
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
>> On Sun, Dec 07, 2008 at 05:52:45PM +, Alan Cox ([EMAIL PROTECTED]) wrote:
>> > > Alan, let's make some progress on this fingerpointing. If Her
On Sun, 7 Dec 2008 20:54:38 +0300
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 07, 2008 at 05:52:45PM +, Alan Cox ([EMAIL PROTECTED]) wrote:
> > > Alan, let's make some progress on this fingerpointing. If Herbert's
> > > patch fixes the crypto loading problem, it will find its way
On Sun, Dec 07, 2008 at 05:52:45PM +, Alan Cox ([EMAIL PROTECTED]) wrote:
> > Alan, let's make some progress on this fingerpointing. If Herbert's
> > patch fixes the crypto loading problem, it will find its way upstream
> > for the current tree, and in the merge window Kay's patch may be applie
> Alan, let's make some progress on this fingerpointing. If Herbert's
> patch fixes the crypto loading problem, it will find its way upstream
> for the current tree, and in the merge window Kay's patch may be applied
> and widely tested. Thoughts?
I have no intention of applying Kay's patch becaus
On Sun, 7 Dec 2008 18:39:48 +0100
"Kay Sievers" <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 7, 2008 at 18:28, Alan Cox <[EMAIL PROTECTED]> wrote:
> >> > /dev/console is a logical mapping to a device which may well be
> >> > different, loaded after PCI is initialised and dependant on PCI.
> >>
> >> So
On Sun, Dec 07, 2008 at 05:28:55PM +, Alan Cox ([EMAIL PROTECTED]) wrote:
> > > /dev/console is a logical mapping to a device which may well be
> > > different, loaded after PCI is initialised and dependant on PCI.
> >
> > So wrong. If no driver is associated, like early, in that case, we
> >
On Sun, Dec 7, 2008 at 18:28, Alan Cox <[EMAIL PROTECTED]> wrote:
>> > /dev/console is a logical mapping to a device which may well be
>> > different, loaded after PCI is initialised and dependant on PCI.
>>
>> So wrong. If no driver is associated, like early, in that case, we
>> must return -ENODE
On Sun, Dec 7, 2008 at 18:01, Alan Cox <[EMAIL PROTECTED]> wrote:
>> Wrong. First at least because tty/console stuff is built in.
>
> Are you two people or just two names and email addresses for
> the same ?
>
> /dev/console is a logical mapping to a device which may well be
> different, loaded aft
On Sun, Dec 07, 2008 at 05:24:47PM +, Alan Cox ([EMAIL PROTECTED]) wrote:
> > Heh, init is not allowed to write something to the console or any other
> > tty?
>
> init is not run as the helper of a modprobe.
I hope it is not another limitation for the early userspace? :)
I worked with systems
> > /dev/console is a logical mapping to a device which may well be
> > different, loaded after PCI is initialised and dependant on PCI.
>
> So wrong. If no driver is associated, like early, in that case, we
> must return -ENODEV, instead of calling modprobe in a loop. It's a
> built-in device, an
> Heh, init is not allowed to write something to the console or any other
> tty?
init is not run as the helper of a modprobe.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majo
On Sun, Dec 7, 2008 at 18:01, Alan Cox <[EMAIL PROTECTED]> wrote:
>> Wrong. First at least because tty/console stuff is built in.
>
> Are you two people or just two names and email addresses for
> the same ?
Damn, now you found that out.
I suggest you get a few more mail addresses too, to back yo
On Sun, Dec 07, 2008 at 05:01:08PM +, Alan Cox ([EMAIL PROTECTED]) wrote:
> > Wrong. First at least because tty/console stuff is built in.
>
> Are you two people or just two names and email addresses for
> the same ?
Depending on who you are asking for.
> /dev/console is a logical mapping to
On Sun, Dec 07, 2008 at 04:57:40PM +, Alan Cox ([EMAIL PROTECTED]) wrote:
> The userspace opens major 5 minor 1. The kernel has no driver mapped to
> that so the kernel asks user space to load a module of its choice for
It has. It really has it. It was not yet initialized though because,
becau
> Wrong. First at least because tty/console stuff is built in.
Are you two people or just two names and email addresses for
the same ?
/dev/console is a logical mapping to a device which may well be
different, loaded after PCI is initialised and dependant on PCI.
> But we alredy got, that you de
> > It isn't a problem. It is trying to have hotplug load a suitable driver.
> > This is what is supposed to happen.
>
> No, it's not. 5:1 is _in_ the kernel, and must not be tried to be
> loaded by the kernel. We need to make /dev/console access return
> -ENODEV if not available, not try to load
On Sun, Dec 07, 2008 at 11:55:07PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
> Having said that I think this patch should remove this particular
> trigger. Unfortunately I couldn't find a more succinct way of
> expressing this relationship: if ALGAPI is built-in because it's
> selected by an al
On Sun, Dec 07, 2008 at 04:09:21PM +, Alan Cox ([EMAIL PROTECTED]) wrote:
> > Even when this works around it, the problem that the kernel triggers
> > module loading on /dev/console access stays and needs to be fixed
> > instead.
>
> It isn't a problem. It is trying to have hotplug load a suit
On Sun, Dec 7, 2008 at 17:09, Alan Cox <[EMAIL PROTECTED]> wrote:
>> Even when this works around it, the problem that the kernel triggers
>> module loading on /dev/console access stays and needs to be fixed
>> instead.
>
> It isn't a problem. It is trying to have hotplug load a suitable driver.
> T
> Even when this works around it, the problem that the kernel triggers
> module loading on /dev/console access stays and needs to be fixed
> instead.
It isn't a problem. It is trying to have hotplug load a suitable driver.
This is what is supposed to happen.
Alan
--
To unsubscribe from this list:
On Sun, Dec 7, 2008 at 16:55, Herbert Xu <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 07, 2008 at 10:49:27PM +0800, Herbert Xu wrote:
>>
>> In any case the loop itself does not involve any crypto components
>> so I don't think making changes in the crypto layer is going to
>> make this go away forever
On Sun, Dec 07, 2008 at 10:49:27PM +0800, Herbert Xu wrote:
>
> In any case the loop itself does not involve any crypto components
> so I don't think making changes in the crypto layer is going to
> make this go away forever as anyone calling request_module early
> enough will get into this loop.
38 matches
Mail list logo
