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 > > > udev. > > > > > > 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. > > > > The real solution is to have the user space tool to create these > > device nodes in advance. > > Maybe. But requiring people upgrade their userspace tools or setup for > 2.6.22 isn't a reasonable solution. > > > The original loop patch was coded such that when we open a loop device > > N, the immediate adjacent device "N + 1" is created. This will keep > > "mount -o loop" happy because it typically does a linear scan to find > > a free device. This might be somewhat hackary, but certainly will be > > backward compatible before user space solution is deployed. > > Except userspace is currently expecting 8 loop nodes upon bootup. > Creating n+1 when n is opened is good, but racy if userspace tries to > mount serveral loop devices in parallel. > > If the loop device instantiates 8 (or max_loop) upon init, then we're > compatible with how things are being done in 2.6.21 and earlier. > > > However, the code was removed by Al in this commit: > > > > commit 07002e995638b83a6987180f43722a0eb39d4932 > > Author: Al Viro <[EMAIL PROTECTED]> > > Date: Sat May 12 16:23:15 2007 -0400 > > > > fix the dynamic allocation and probe in loop.c > > No, backing that code out wasn't good enough -- the reporter tested > reverting both of Al's patches out and was still getting errors on > boot. It took reverting your original one out as well to make it work.
Yes. I reverted three in fact. Please see my latest entry in this thread to read what I did to make this work for now. > > So, a compromise? Let's start with 8 (or max_loop) populated, and then > we can move forward separately with teaching userspace new loop > tricks. Yes. Good idea! The reason why I need 2.6.22-rc2 and why I cannot work with 2.6.21.1 is that I get a kernel oops (hangup) with 2.6.21.1 about 20 seconds after login. The machine is an AMD K7 with but SiS chipsets / controllers onboard. Responsible for that kernel oops with 2.6.21.1 is supposedly the whole ide layer plus sis5513.c. In so far, pulling all ide layer changes plus the sis5513.c patch from 2.6.22-rc2 into mainline of 2.6.21 would definitely be a very good idea. Thanks for the quick help, especially to Ray. Best Regards Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
