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 Mon, Dec 08, 2008 at 08:24:35AM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
> > > + u64 *W = get_cpu_var(msg_schedule);
> >
> > This should be protected by preempt_disable(), shouldn't it?
>
> get_cpu_var does it implicitly.
Yeah, that simple!
--
Evgeniy Polyakov
--
To unsubscribe
On Mon, Dec 08, 2008 at 03:09:19AM +0300, Evgeniy Polyakov wrote:
>
> > static void
> > -sha512_transform(u64 *state, u64 *W, const u8 *input)
> > +sha512_transform(u64 *state, const u8 *input)
> > {
> > u64 a, b, c, d, e, f, g, h, t1, t2;
> >
> > int i;
> > + u64 *W = get_cpu_var(msg
Hi.
On Sun, Dec 07, 2008 at 11:17:28PM +0100, Adrian-Ken Rueegsegger ([EMAIL
PROTECTED]) wrote:
> The message schedule W (u64[80]) is too big for the stack. In order
> for this algorithm to be used with shash it is moved to a static
> percpu area.
>
> Signed-off-by: Adrian-Ken Rueegsegger <[EMAI
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
This patch changes sha512 and sha384 to the new shash interface.
Signed-off-by: Adrian-Ken Rueegsegger <[EMAIL PROTECTED]>
---
crypto/Kconfig |2 +-
crypto/sha512_generic.c | 112 +--
2 files changed, 60 insertions(+), 54 deletions(-)
dif
This resend contains the fixed up sha512 patches to switch the last
remaining algorithm to shash.
The first patch is now correct also in the case of preemption. The
second patch remains unchanged.
Adrian
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a m
The message schedule W (u64[80]) is too big for the stack. In order
for this algorithm to be used with shash it is moved to a static
percpu area.
Signed-off-by: Adrian-Ken Rueegsegger <[EMAIL PROTECTED]>
---
crypto/sha512_generic.c | 17 +
1 files changed, 9 insertions(+), 8 del
> >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.
On Sat, Dec 06, 2008 at 12:39:38AM -0500, Jarod Wilson wrote:
>
> v3: set more appropriate RES flag, also per Herbert.
BTW, please maintain the patch description as you would in the
first submission. This makes it much easier for me to apply the
patch. Feel free to summarise changes elsewhere in
On Thu, Dec 04, 2008 at 11:43:44PM +0100, Adrian-Ken Rueegsegger wrote:
> This series contains the fixed up patches to convert the remaining hash
> algorithms to use shash.
I've applied patches 3-4.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTEC
On Thu, Dec 04, 2008 at 11:43:45PM +0100, Adrian-Ken Rueegsegger wrote:
>
> int i;
> + u64 *W = __get_cpu_var(msg_schedule);
That should be get_cpu_var unless you've already disabled preemption
somewhere.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~
Evgeniy Polyakov wrote:
On Sat, Dec 06, 2008 at 10:09:55PM +0800, Lingbo Tang (SINA) ([EMAIL
PROTECTED]) wrote:
In some cases the non-debug version can work with "mkfs.xfs", but it
could not in most case.
I tried to disable most services in the system, but it seems have no
related to the system
43 matches
Mail list logo
