Am Dienstag, 22. Mai 2007 22:18 schrieben Sie:
> On May 20 2007 07:28, Al Viro wrote:
> >On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> >> Ken? Ball's in your court. As the patch isn't providing a killer
> >> feature for 2.6.22, I'd suggest just reverting it for now until the
> >> issue
On May 20 2007 07:28, Al Viro wrote:
>On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
>> Ken? Ball's in your court. As the patch isn't providing a killer
>> feature for 2.6.22, I'd suggest just reverting it for now until the
>> issues are ironed out.
>
>Hold it. The real question here is
On Tue, May 22, 2007 at 01:10:38AM +0100, Al Viro wrote:
> On Mon, May 21, 2007 at 09:11:02AM -0700, Linus Torvalds wrote:
> >
> >
> > On Sun, 20 May 2007, Kay Sievers wrote:
> > >
> > > Right, providing "preallocated" devices, 8 or the number given in
> > > max_loop, sounds like the best option
On Mon, May 21, 2007 at 09:11:02AM -0700, Linus Torvalds wrote:
>
>
> On Sun, 20 May 2007, Kay Sievers wrote:
> >
> > Right, providing "preallocated" devices, 8 or the number given in
> > max_loop, sounds like the best option until the tools can handle that.
>
> Yes. Can somebody who actually _
On Mon, 21 May 2007 23:20:54 +0200
Uwe Bugla <[EMAIL PROTECTED]> wrote:
> I meanwhile tried to find out why my AMD K7 machine oopses with 2.6.21.1.
> I first suspected sis5513 ide module, reverted all its dependencies, even
> changed a Makefile, but the Oops is still there after 10 modules revert
Am Montag, 21. Mai 2007 22:48 schrieben Sie:
> On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
> > The easiest way is to reinstate max_loop and create "max_loop" device
> > up front at module load time. However, that will lose all the "fancy
> > on-demand device instantiation feature".
> >
> > So
On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
The easiest way is to reinstate max_loop and create "max_loop" device
up front at module load time. However, that will lose all the "fancy
on-demand device instantiation feature".
So I propose we do the following:
1. have the module honor "max_lo
On Monday 21 May 2007, Kay Sievers wrote:
> On Mon, 2007-05-21 at 18:50 +0200, Uwe Bugla wrote:
> > Am Montag, 21. Mai 2007 18:37 schrieben Sie:
> > > On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
> > > > yes and no. in that commit, I automatically create n+1 device when
> > > > loop device n is
On Mon, 2007-05-21 at 18:50 +0200, Uwe Bugla wrote:
> Am Montag, 21. Mai 2007 18:37 schrieben Sie:
> > On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
> > > yes and no. in that commit, I automatically create n+1 device when
> > > loop device n is created, allergically was tested to be fine with
> >
On Mon, 21 May 2007, Ken Chen wrote:
>
> So I propose we do the following:
>
> 1. have the module honor "max_loop" parameter and create that many
> device upfront on module load (max_loop will also be a hard max) iff
> user specify the parameter.
> 2. if max_loop is not specified, default creat
Am Montag, 21. Mai 2007 18:37 schrieben Sie:
> On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
> > yes and no. in that commit, I automatically create n+1 device when
> > loop device n is created, allergically was tested to be fine with
> > casual usage of "losetup" and "mount -o loop". However, th
On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
yes and no. in that commit, I automatically create n+1 device when
loop device n is created, allergically was tested to be fine with
casual usage of "losetup" and "mount -o loop". However, there is a
bug in that commit when loop.c was compiled as a
On 5/21/07, Ken Chen <[EMAIL PROTECTED]> wrote:
On 5/21/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I don't have much choice. I assume it is
>
>commit 73285082 "remove artificial software max_loop limit"
>
> that introduced the new behaviour. Ken?
yes and no. in that commit, I automatica
On 5/21/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
Yes. Can somebody who actually _uses_ loop send a tested patch, please?
We're not going to break existing user space over something idiotic like
this. Not acceptable.
The alternative is to just revert all the loop.c patches. Which I'll do
un
On Sun, 20 May 2007, Kay Sievers wrote:
>
> Right, providing "preallocated" devices, 8 or the number given in
> max_loop, sounds like the best option until the tools can handle that.
Yes. Can somebody who actually _uses_ loop send a tested patch, please?
We're not going to break existing user
Am Montag, 21. Mai 2007 08:40 schrieben Sie:
> On 5/20/07, Ken Chen <[EMAIL PROTECTED]> wrote:
> > On 5/19/07, Ray Lee <[EMAIL PROTECTED]> wrote:
> > > Yeah, that's the only one left. I was hoping it wasn't that one, as it
> > > claimed to have been tested extensively. Guess it wasn't tested with
>
On 5/20/07, Ken Chen <[EMAIL PROTECTED]> wrote:
On 5/19/07, Ray Lee <[EMAIL PROTECTED]> wrote:
> Yeah, that's the only one left. I was hoping it wasn't that one, as it
> claimed to have been tested extensively. Guess it wasn't tested with
> udev.
>
> Ken? Ball's in your court. As the patch isn't
On 5/19/07, Ray Lee <[EMAIL PROTECTED]> wrote:
Yeah, that's the only one left. I was hoping it wasn't that one, as it
claimed to have been tested extensively. Guess it wasn't tested with
udev.
Ken? Ball's in your court. As the patch isn't providing a killer
feature for 2.6.22, I'd suggest just r
Uwe Bugla wrote:
> Andrey's path however (i. e. copying his attached version of loop.c into the
> 2.6.22-rc2 kernel tree) led to:
>
> a. an incompilable kernel
> b. endless messages trying to compile loop.c going like this (just a part of
> them - not complete anyway!):
>
> drivers/block/loop.
Am Sonntag, 20. Mai 2007 18:16 schrieben Sie:
> On Sun, 2007-05-20 at 09:10 -0700, Ray Lee wrote:
> > On 5/20/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
> > > On 5/20/07, Ray Lee <[EMAIL PROTECTED]> wrote:
> > > > On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
> > > > > On Sat, May 19, 2007 at 11:1
Andrey Borzenkov <[EMAIL PROTECTED]> writes:
> On Sunday 20 May 2007, Kay Sievers wrote:
>>
>> Until the tools can request dynamic loop device allocation from the
>> kernel before they want to use the device, you can create as many as
>> needed "static" loop* nodes in /lib/udev/devices/, which wil
On Sun, 2007-05-20 at 09:10 -0700, Ray Lee wrote:
> On 5/20/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
> > On 5/20/07, Ray Lee <[EMAIL PROTECTED]> wrote:
> > > On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
> > > > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > > > > Ken? Ball's in yo
On 5/20/07, Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
On Sunday 20 May 2007, Ray Lee wrote:
> The when part is what looks to make it racy. I'm guessing that we're
> relying on udev to create those loop nodes. If so, I think any scheme
> that creates more on demand would give transient mount err
On 5/20/07, Kay Sievers <[EMAIL PROTECTED]> wrote:
On 5/20/07, Ray Lee <[EMAIL PROTECTED]> wrote:
> On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
> > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > > Ken? Ball's in your court. As the patch isn't providing a killer
> > > feature for
On Sunday 20 May 2007, Ray Lee wrote:
> On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
> > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > > Ken? Ball's in your court. As the patch isn't providing a killer
> > > feature for 2.6.22, I'd suggest just reverting it for now until the
> > >
On Sunday 20 May 2007, Kay Sievers wrote:
> On 5/20/07, Ray Lee <[EMAIL PROTECTED]> wrote:
> > On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
> > > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > > > Ken? Ball's in your court. As the patch isn't providing a killer
> > > > feature for 2
On 5/20/07, Ray Lee <[EMAIL PROTECTED]> wrote:
On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
> On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > Ken? Ball's in your court. As the patch isn't providing a killer
> > feature for 2.6.22, I'd suggest just reverting it for now until the
> >
On 5/20/07, Uwe Bugla <[EMAIL PROTECTED]> wrote:
My question / proposal for now would be:
Could anybody of you please be kind enough and write / provide me a counter
patch supplying me:
a. a compilable 2.6.22-rc2 kernel
b. a loop device that can mount up to 8 iso-images
If you revert all thre
On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote:
On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> Ken? Ball's in your court. As the patch isn't providing a killer
> feature for 2.6.22, I'd suggest just reverting it for now until the
> issues are ironed out.
Hold it. The real question he
Am Sonntag, 20. Mai 2007 08:58 schrieben Sie:
> On Sunday 20 May 2007, Al Viro wrote:
> > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > > Ken? Ball's in your court. As the patch isn't providing a killer
> > > feature for 2.6.22, I'd suggest just reverting it for now until the
> > > i
On Sunday 20 May 2007, Al Viro wrote:
> On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> > Ken? Ball's in your court. As the patch isn't providing a killer
> > feature for 2.6.22, I'd suggest just reverting it for now until the
> > issues are ironed out.
>
> Hold it. The real question he
On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote:
> Ken? Ball's in your court. As the patch isn't providing a killer
> feature for 2.6.22, I'd suggest just reverting it for now until the
> issues are ironed out.
Hold it. The real question here is which logics do we want there.
IOW, and how
On 5/19/07, Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
On Sunday 20 May 2007, Uwe Bugla wrote:
> unfortunately it does not make any difference if I simply rip out the
> changes of patch-2.6.22-rc2 or patch-2.6.21 in connection with patch
> 2.6.22-rc2 regarding module loop.c.
because they are ju
On Sunday 20 May 2007, Uwe Bugla wrote:
> Am Samstag, 19. Mai 2007 21:17 schrieben Sie:
> > Ray Lee wrote:
> > > Hey there,
> > >
> > > On 5/19/07, Uwe Bugla <[EMAIL PROTECTED]> wrote:
> > > > I am running Debian Etch 4.0 stable in connection with udev.
> > > >
> > > > In kernel 2.6.22-rc2 the n
Ray Lee wrote:
> Hey there,
>
> On 5/19/07, Uwe Bugla <[EMAIL PROTECTED]> wrote:
> > I am running Debian Etch 4.0 stable in connection with udev.
> >
> > In kernel 2.6.22-rc2 the number of available loop mounts is reduced
> > from 8 (conventional standard of preceding 2.6 kernels) to 1.
> >
Hey there,
On 5/19/07, Uwe Bugla <[EMAIL PROTECTED]> wrote:
> I am running Debian Etch 4.0 stable in connection with udev.
>
> In kernel 2.6.22-rc2 the number of available loop mounts is reduced from
> 8 (conventional standard of preceding 2.6 kernels) to 1.
>
> Symptom: If you try to mount more
Hi,
I am running Debian Etch 4.0 stable in connection with udev.
In kernel 2.6.22-rc2 the number of available loop mounts is reduced from 8
(conventional standard of preceding 2.6 kernels) to 1.
Symptom: If you try to mount more than one single iso-image with
the loop parameter you are receivin
37 matches
Mail list logo