compile 2.2.14.
Then
# modprobe -a loop
/lib/modules/2.4.14/kernel/drivers/block/loop.o: unresolved symbol
deactivate_page
/lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod
/lib/modules/2.4.14/kernel/drivers/block/loop.o failed
/lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod loop failed
do recursive grep through kernel tree:
# rgrep -rl deactivate_page *
drivers/block/loop.c
drivers/block/loop.o
Is there a fix for this?
Joe
Joe wrote:
> compile 2.2.14.
>
> Then
>
> # modprobe -a loop
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: unresolved symbol
> deactivate_page
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod
> /lib/modules/2.4.14/kernel/drivers/block/loop.o failed
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod loop failed
>
> do recursive grep through kernel tree:
>
> # rgrep -rl deactivate_page *
> drivers/block/loop.c
> drivers/block/loop.o
>
> Is there a fix for this?
yes, see 2.4.15pre1
warning, the iptables code in 2.4.15pre1 and pre2 seems broken.
Fran?ois
On Sunday 11 November 2001 22:27, Joe wrote:
> compile 2.2.14.
>
> Then
>
> # modprobe -a loop
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: unresolved symbol
> deactivate_page
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod
> /lib/modules/2.4.14/kernel/drivers/block/loop.o failed
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod loop failed
>
> do recursive grep through kernel tree:
>
> # rgrep -rl deactivate_page *
> drivers/block/loop.c
> drivers/block/loop.o
>
> Is there a fix for this?
2.4.15-pre1 fixed this and there are also some patches on lkml-archives..
--
ElkOS: 10:35pm up 2:26, 3 users, load average: 0.05, 0.25, 0.30
bofhX: The data on your hard drive is out of balance.
Fran?ois Cami wrote:
>
> Joe wrote:
>
> > compile 2.2.14.
> >
> > Then
> >
> > # modprobe -a loop
> > /lib/modules/2.4.14/kernel/drivers/block/loop.o: unresolved symbol
> > deactivate_page
> > /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod
> > /lib/modules/2.4.14/kernel/drivers/block/loop.o failed
> > /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod loop failed
> >
> > do recursive grep through kernel tree:
> >
> > # rgrep -rl deactivate_page *
> > drivers/block/loop.c
> > drivers/block/loop.o
> >
> > Is there a fix for this?
>
> yes, see 2.4.15pre1
> warning, the iptables code in 2.4.15pre1 and pre2 seems broken.
and further it is likely that pre3 fixes iptables code :)
(it looks like the patch got reverted)
--
Jeff Garzik | Only so many songs can be sung
Building 1024 | with two lips, two lungs, and one tongue.
MandrakeSoft | - nomeansno
On Sun, 11 Nov 2001, Joe wrote:
> compile 2.2.14.
>
> Then
>
> # modprobe -a loop
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: unresolved symbol
> deactivate_page
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod
> /lib/modules/2.4.14/kernel/drivers/block/loop.o failed
> /lib/modules/2.4.14/kernel/drivers/block/loop.o: insmod loop failed
>
> do recursive grep through kernel tree:
>
> # rgrep -rl deactivate_page *
> drivers/block/loop.c
> drivers/block/loop.o
>
> Is there a fix for this?
This is a known bug.
The following patch fixes it:
--- linux-2.4.14-broken/drivers/block/loop.c Thu Oct 25 13:58:34 2001
+++ linux-2.4.14/drivers/block/loop.c Mon Nov 5 17:06:08 2001
@@ -207,7 +207,6 @@
index++;
pos += size;
UnlockPage(page);
- deactivate_page(page);
page_cache_release(page);
}
return 0;
@@ -218,7 +217,6 @@
kunmap(page);
unlock:
UnlockPage(page);
- deactivate_page(page);
page_cache_release(page);
fail:
return -1;
> Joe
cu
Adrian
--
Get my GPG key: finger [email protected] | gpg --import
Fingerprint: B29C E71E FE19 6755 5C8A 84D4 99FC EA98 4F12 B400
Jeff Garzik wrote:
> Fran?ois Cami wrote:
>
> > yes, see 2.4.15pre1
> > warning, the iptables code in 2.4.15pre1 and pre2 seems broken.
>
> and further it is likely that pre3 fixes iptables code :)
> (it looks like the patch got reverted)
Actually it doesn't seem to be reverted,
just reworked -
I'll be testing it out -
cu
jjs
J Sloan wrote:
> Jeff Garzik wrote:
>
> > Fran?ois Cami wrote:
> >
> > > yes, see 2.4.15pre1
> > > warning, the iptables code in 2.4.15pre1 and pre2 seems broken.
> >
> > and further it is likely that pre3 fixes iptables code :)
> > (it looks like the patch got reverted)
>
> Actually it doesn't seem to be reverted,
> just reworked -
hmm, spoke too soon -
looks like they were reverted after all...
cu
jjs
Okay, I can delete out those two lines to get loop working.
Is 2.4.x really a stable tree? Or should I wait for 2.4.25 before I consider it really stable?
> > Fran?ois Cami wrote:
> >
> > > yes, see 2.4.15pre1
> > > warning, the iptables code in 2.4.15pre1 and pre2 seems broken.
> >
> > and further it is likely that pre3 fixes iptables code :)
> > (it looks like the patch got reverted)
>
> Actually it doesn't seem to be reverted,
> just reworked -
hmm, spoke too soon -
looks like they were reverted after all...
cu
jjs
I thought that the -pre would be the developer kernels, and that an actual release (2.4.14) would have been somewhat tested. I fully understand that a 'runtime' bug in the vm or some other system could arrise and that is one thing. I also understand when a 'less used' driver like NTFS or VFAT breaks, but to see bugs in the loop device in a 'stabilizing' kernel is something that I thought I'd never see.
Hmm anyone working on a regression testing tool for the kernel compilation options??
Also new features DO go into stable trees, there are many times when 2.3.x was open that stuff was backported to 2.2.x. I also heard that ext3 might end up in 2.4.15, which I'd love to see happen (that and lm_sensors)
I DO think that there needs to be a better way of handling some of these small bugs. Like maybe where the kernel is posted (in my case obtaining from ftp.kernel.org) there should be a readme.first.2.4.14 for every version of the kernel and in there things like this could be stated. Simple one line in loop.c commment out the two lines or remove the two lines with deactivate_page.
I don't mind 'testing', but how can you test what wont compile or what compiles but does not run?
Joe
John Alvord <[email protected]> wrote:
> In developer-speak, stable == stablizing, which means that fixes go in
but no new features. That can include monstrous fixes like the VM
cleanup.
When you are running developer kernels, you are on the kernel test
team whether you know it or not, whether you think thats OK or hate
it.
For "stable" kernels, wait for the distributors like red hat/suse/etc.
There is no way around serious testing which they perform.
john
On Mon, 12 Nov 2001 12:40:43 -0500, [email protected] wrote:
>Okay, I can delete out those two lines to get loop working.
>
>Is 2.4.x really a stable tree? Or should I wait for 2.4.25 before I consider it really stable?
>
>> > François Cami wrote:
>> >
>> > > yes, see 2.4.15pre1
>> > > warning, the iptables code in 2.4.15pre1 and pre2 seems broken.
>> >
>> > and further it is likely that pre3 fixes iptables code :)
>> > (it looks like the patch got reverted)
>>
>> Actually it doesn't seem to be reverted,
>> just reworked -
>
>hmm, spoke too soon -
>
>looks like they were reverted after all...
>
>cu
>
>jjs
>
>
>-
>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/
[email protected] wrote:
> Okay, I can delete out those two lines to get loop working.
>
> Is 2.4.x really a stable tree? Or should I wait for 2.4.25 before I consider it really stable?
If by stable you mean "unchanging", of course not -
much development is still happening.
If however by stable you mean "does not crash",
it has been very stable here, with a few known
needed patches applied. 2.4.14 is stable for me
on all systems, but compaq smart controllers do
need a small patch - I am also running the low
latency and/or preempt patches with excellent
stability.
cu
jjs
Something definitely should be done to help "stabilize" the tree; it's not
really a big deal for most of us if something is broken, as you know there
will be a fix posted very soon after the release, _but_ bugs like these
don't exactly make Linux "look good" to the rest of the UNIX community. A
FreeBSD advocate might say "well, FreeBSD never does _that_". My suggestion
to help fix the problem would be to do what SGI does; have two seperate
trees that strive to stay as close to each other as possible, but one
becomes part of the "maintaince stream", where only bug fixes and the such
are added, and a "features stream", where actual new features are added in.
Take a look at some of the IRIX web pages at http://www.sgi.com/ for a
better idea of how that works, but believe me, it works. This would be in
addition to some sort of testing suite that each official kernel must pass
before it is released. With the growing number of (important/big) Linux
users, we must make sure each kernel is rock-solid before being released.
This is definitely more of a political topic than a technical one, but it
has to be addressed nonetheless.
-----------------------------------------------
Sean P. Elble
Editor, Writer, Co-Webmaster
ReactiveLinux.com (Formerly MaximumLinux.org)
http://www.reactivelinux.com/
[email protected]
-----------------------------------------------
----- Original Message -----
From: <[email protected]>
To: "John Alvord" <[email protected]>
Cc: <[email protected]>
Sent: Monday, November 12, 2001 3:27 PM
Subject: Re: Re: loop back broken in 2.2.14
> I thought that the -pre would be the developer kernels, and that an actual
release (2.4.14) would have been somewhat tested. I fully understand that a
'runtime' bug in the vm or some other system could arrise and that is one
thing. I also understand when a 'less used' driver like NTFS or VFAT breaks,
but to see bugs in the loop device in a 'stabilizing' kernel is something
that I thought I'd never see.
>
> Hmm anyone working on a regression testing tool for the kernel compilation
options??
>
> Also new features DO go into stable trees, there are many times when 2.3.x
was open that stuff was backported to 2.2.x. I also heard that ext3 might
end up in 2.4.15, which I'd love to see happen (that and lm_sensors)
>
> I DO think that there needs to be a better way of handling some of these
small bugs. Like maybe where the kernel is posted (in my case obtaining
from ftp.kernel.org) there should be a readme.first.2.4.14 for every version
of the kernel and in there things like this could be stated. Simple one
line in loop.c commment out the two lines or remove the two lines with
deactivate_page.
>
> I don't mind 'testing', but how can you test what wont compile or what
compiles but does not run?
>
> Joe
> John Alvord <[email protected]> wrote:
> > In developer-speak, stable == stablizing, which means that fixes go in
> but no new features. That can include monstrous fixes like the VM
> cleanup.
>
> When you are running developer kernels, you are on the kernel test
> team whether you know it or not, whether you think thats OK or hate
> it.
>
> For "stable" kernels, wait for the distributors like red hat/suse/etc.
> There is no way around serious testing which they perform.
>
> john
>
>
> On Mon, 12 Nov 2001 12:40:43 -0500, [email protected] wrote:
>
> >Okay, I can delete out those two lines to get loop working.
> >
> >Is 2.4.x really a stable tree? Or should I wait for 2.4.25 before I
consider it really stable?
> >
> >> > François Cami wrote:
> >> >
> >> > > yes, see 2.4.15pre1
> >> > > warning, the iptables code in 2.4.15pre1 and pre2 seems broken.
> >> >
> >> > and further it is likely that pre3 fixes iptables code :)
> >> > (it looks like the patch got reverted)
> >>
> >> Actually it doesn't seem to be reverted,
> >> just reworked -
> >
> >hmm, spoke too soon -
> >
> >looks like they were reverted after all...
> >
> >cu
> >
> >jjs
> >
> >
> >-
> >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/
>
>
> -
> 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/
I guess the way I'd do it would be to actually freeze [in which I mean
no more 'testing' patch are applied] a pre something, say 2.4.XpreY for
example, see if there are any obvious bugs in it (like the loopback in
2.4.14), correct them, test again, and if it's okay,
release 2.4.X.
Of course, I've never done much kernel work except testing, so I'm not
exactly the one who should talk about it.
Still, I think that from the user point of view (and there was a post in
LKML yesterday, about Linux being used by UN*X experienced sysadmins
only... or going mainstream instead) the releases should be tested a bit
more thoroughly and actually *frozen* for some time (a day or two should
suffice I guess) before being labelled 2.4.X.
Just the two cents from a newbie - I hope/mean to offense noone with that
Fran?ois Cami
Sean Elble wrote:
> Something definitely should be done to help "stabilize" the tree; it's not
> really a big deal for most of us if something is broken, as you know there
> will be a fix posted very soon after the release, _but_ bugs like these
> don't exactly make Linux "look good" to the rest of the UNIX community. A
> FreeBSD advocate might say "well, FreeBSD never does _that_". My suggestion
> to help fix the problem would be to do what SGI does; have two seperate
> trees that strive to stay as close to each other as possible, but one
> becomes part of the "maintaince stream", where only bug fixes and the such
> are added, and a "features stream", where actual new features are added in.
> Take a look at some of the IRIX web pages at http://www.sgi.com/ for a
> better idea of how that works, but believe me, it works. This would be in
> addition to some sort of testing suite that each official kernel must pass
> before it is released. With the growing number of (important/big) Linux
> users, we must make sure each kernel is rock-solid before being released.
> This is definitely more of a political topic than a technical one, but it
> has to be addressed nonetheless.
>
> -----------------------------------------------
> Sean P. Elble
> Editor, Writer, Co-Webmaster
> ReactiveLinux.com (Formerly MaximumLinux.org)
> http://www.reactivelinux.com/
> [email protected]
> -----------------------------------------------
>
> ----- Original Message -----
> From: <[email protected]>
> To: "John Alvord" <[email protected]>
> Cc: <[email protected]>
> Sent: Monday, November 12, 2001 3:27 PM
> Subject: Re: Re: loop back broken in 2.2.14
>
>
>
>>I thought that the -pre would be the developer kernels, and that an actual
>>
> release (2.4.14) would have been somewhat tested. I fully understand that a
> 'runtime' bug in the vm or some other system could arrise and that is one
> thing. I also understand when a 'less used' driver like NTFS or VFAT breaks,
> but to see bugs in the loop device in a 'stabilizing' kernel is something
> that I thought I'd never see.
>
>>Hmm anyone working on a regression testing tool for the kernel compilation
>>
> options??
>
>>Also new features DO go into stable trees, there are many times when 2.3.x
>>
> was open that stuff was backported to 2.2.x. I also heard that ext3 might
> end up in 2.4.15, which I'd love to see happen (that and lm_sensors)
>
>>I DO think that there needs to be a better way of handling some of these
>>
> small bugs. Like maybe where the kernel is posted (in my case obtaining
> from ftp.kernel.org) there should be a readme.first.2.4.14 for every version
> of the kernel and in there things like this could be stated. Simple one
> line in loop.c commment out the two lines or remove the two lines with
> deactivate_page.
>
>>I don't mind 'testing', but how can you test what wont compile or what
>>
> compiles but does not run?
>
>>Joe
>>John Alvord <[email protected]> wrote:
>>
>>>In developer-speak, stable == stablizing, which means that fixes go in
>>>
>>but no new features. That can include monstrous fixes like the VM
>>cleanup.
>>
>>When you are running developer kernels, you are on the kernel test
>>team whether you know it or not, whether you think thats OK or hate
>>it.
>>
>>For "stable" kernels, wait for the distributors like red hat/suse/etc.
>>There is no way around serious testing which they perform.
>>
>>john
>>
>>
>>On Mon, 12 Nov 2001 12:40:43 -0500, [email protected] wrote:
>>
>>
>>>Okay, I can delete out those two lines to get loop working.
>>>
>>>Is 2.4.x really a stable tree? Or should I wait for 2.4.25 before I
>>>
> consider it really stable?
>
>>>>>François Cami wrote:
>>>>>
>>>>>
>>>>>>yes, see 2.4.15pre1
>>>>>>warning, the iptables code in 2.4.15pre1 and pre2 seems broken.
>>>>>>
>>>>>and further it is likely that pre3 fixes iptables code :)
>>>>>(it looks like the patch got reverted)
>>>>>
>>>>Actually it doesn't seem to be reverted,
>>>>just reworked -
>>>>
>>>hmm, spoke too soon -
>>>
>>>looks like they were reverted after all...
>>>
>>>cu
>>>
>>>jjs
>>>
>>>
>>>-
Can't argue with you on the respect that kernels should be tested, but I
_can_ argue with you on your method. :-) The main problem that I see there
is that you are then limiting yourself (well not you, but just making things
hypothetical) to a certain number of test kernels. What if another problem
is found after the freeze? Testing should be done any time Linus gets ready
to release a kernel, though a feature freeze wouldn't be a bad idea. I'm
still wondering what the best solution is though . . .
-----------------------------------------------
Sean P. Elble
Editor, Writer, Co-Webmaster
ReactiveLinux.com (Formerly MaximumLinux.org)
http://www.reactivelinux.com/
[email protected]
-----------------------------------------------
----- Original Message -----
From: "Fran?ois Cami" <[email protected]>
To: "Sean Elble" <[email protected]>
Cc: <[email protected]>; "John Alvord" <[email protected]>;
<[email protected]>
Sent: Monday, November 12, 2001 7:37 PM
Subject: Re: Testing Kernel Releases Before Being Released (Was Re: Re: loop
back broken in 2.2.14)
I guess the way I'd do it would be to actually freeze [in which I mean
no more 'testing' patch are applied] a pre something, say 2.4.XpreY for
example, see if there are any obvious bugs in it (like the loopback in
2.4.14), correct them, test again, and if it's okay,
release 2.4.X.
Of course, I've never done much kernel work except testing, so I'm not
exactly the one who should talk about it.
Still, I think that from the user point of view (and there was a post in
LKML yesterday, about Linux being used by UN*X experienced sysadmins
only... or going mainstream instead) the releases should be tested a bit
more thoroughly and actually *frozen* for some time (a day or two should
suffice I guess) before being labelled 2.4.X.
Just the two cents from a newbie - I hope/mean to offense noone with that
Fran?ois Cami
Sean Elble wrote:
> Something definitely should be done to help "stabilize" the tree; it's not
> really a big deal for most of us if something is broken, as you know there
> will be a fix posted very soon after the release, _but_ bugs like these
> don't exactly make Linux "look good" to the rest of the UNIX community. A
> FreeBSD advocate might say "well, FreeBSD never does _that_". My
suggestion
> to help fix the problem would be to do what SGI does; have two seperate
> trees that strive to stay as close to each other as possible, but one
> becomes part of the "maintaince stream", where only bug fixes and the such
> are added, and a "features stream", where actual new features are added
in.
> Take a look at some of the IRIX web pages at http://www.sgi.com/ for a
> better idea of how that works, but believe me, it works. This would be in
> addition to some sort of testing suite that each official kernel must pass
> before it is released. With the growing number of (important/big) Linux
> users, we must make sure each kernel is rock-solid before being released.
> This is definitely more of a political topic than a technical one, but it
> has to be addressed nonetheless.
>
> -----------------------------------------------
> Sean P. Elble
> Editor, Writer, Co-Webmaster
> ReactiveLinux.com (Formerly MaximumLinux.org)
> http://www.reactivelinux.com/
> [email protected]
> -----------------------------------------------
>
> ----- Original Message -----
> From: <[email protected]>
> To: "John Alvord" <[email protected]>
> Cc: <[email protected]>
> Sent: Monday, November 12, 2001 3:27 PM
> Subject: Re: Re: loop back broken in 2.2.14
>
>
>
>>I thought that the -pre would be the developer kernels, and that an actual
>>
> release (2.4.14) would have been somewhat tested. I fully understand that
a
> 'runtime' bug in the vm or some other system could arrise and that is one
> thing. I also understand when a 'less used' driver like NTFS or VFAT
breaks,
> but to see bugs in the loop device in a 'stabilizing' kernel is something
> that I thought I'd never see.
>
>>Hmm anyone working on a regression testing tool for the kernel compilation
>>
> options??
>
>>Also new features DO go into stable trees, there are many times when 2.3.x
>>
> was open that stuff was backported to 2.2.x. I also heard that ext3 might
> end up in 2.4.15, which I'd love to see happen (that and lm_sensors)
>
>>I DO think that there needs to be a better way of handling some of these
>>
> small bugs. Like maybe where the kernel is posted (in my case obtaining
> from ftp.kernel.org) there should be a readme.first.2.4.14 for every
version
> of the kernel and in there things like this could be stated. Simple one
> line in loop.c commment out the two lines or remove the two lines with
> deactivate_page.
>
>>I don't mind 'testing', but how can you test what wont compile or what
>>
> compiles but does not run?
>
>>Joe
>>John Alvord <[email protected]> wrote:
>>
>>>In developer-speak, stable == stablizing, which means that fixes go in
>>>
>>but no new features. That can include monstrous fixes like the VM
>>cleanup.
>>
>>When you are running developer kernels, you are on the kernel test
>>team whether you know it or not, whether you think thats OK or hate
>>it.
>>
>>For "stable" kernels, wait for the distributors like red hat/suse/etc.
>>There is no way around serious testing which they perform.
>>
>>john
>>
>>
>>On Mon, 12 Nov 2001 12:40:43 -0500, [email protected] wrote:
>>
>>
>>>Okay, I can delete out those two lines to get loop working.
>>>
>>>Is 2.4.x really a stable tree? Or should I wait for 2.4.25 before I
>>>
> consider it really stable?
>
>>>>>François Cami wrote:
>>>>>
>>>>>
>>>>>>yes, see 2.4.15pre1
>>>>>>warning, the iptables code in 2.4.15pre1 and pre2 seems broken.
>>>>>>
>>>>>and further it is likely that pre3 fixes iptables code :)
>>>>>(it looks like the patch got reverted)
>>>>>
>>>>Actually it doesn't seem to be reverted,
>>>>just reworked -
>>>>
>>>hmm, spoke too soon -
>>>
>>>looks like they were reverted after all...
>>>
>>>cu
>>>
>>>jjs
>>>
>>>
>>>-
I am wondering too... Anyone got ideas on this ?
I would like to avoid some specific problems... especially
bugs that show up when compiling a certain module / feature
of the kernel, like the loopback in 2.4.14.
Those should be very easy to get rid of
[it only takes some kernel testers to debug that early, if only
there actually were a feature freeze that last for one day...].
Fran?ois
Sean Elble wrote:
> Can't argue with you on the respect that kernels should be tested, but I
> _can_ argue with you on your method. :-) The main problem that I see there
> is that you are then limiting yourself (well not you, but just making things
> hypothetical) to a certain number of test kernels. What if another problem
> is found after the freeze? Testing should be done any time Linus gets ready
> to release a kernel, though a feature freeze wouldn't be a bad idea. I'm
> still wondering what the best solution is though . . .
>
> -----------------------------------------------
> Sean P. Elble
> Editor, Writer, Co-Webmaster
> ReactiveLinux.com (Formerly MaximumLinux.org)
> http://www.reactivelinux.com/
> [email protected]
> -----------------------------------------------
>
> ----- Original Message -----
> From: "Fran?ois Cami" <[email protected]>
> To: "Sean Elble" <[email protected]>
> Cc: <[email protected]>; "John Alvord" <[email protected]>;
> <[email protected]>
> Sent: Monday, November 12, 2001 7:37 PM
> Subject: Re: Testing Kernel Releases Before Being Released (Was Re: Re: loop
> back broken in 2.2.14)
>
>
>
> I guess the way I'd do it would be to actually freeze [in which I mean
> no more 'testing' patch are applied] a pre something, say 2.4.XpreY for
> example, see if there are any obvious bugs in it (like the loopback in
> 2.4.14), correct them, test again, and if it's okay,
> release 2.4.X.
>
> Of course, I've never done much kernel work except testing, so I'm not
> exactly the one who should talk about it.
>
> Still, I think that from the user point of view (and there was a post in
> LKML yesterday, about Linux being used by UN*X experienced sysadmins
> only... or going mainstream instead) the releases should be tested a bit
> more thoroughly and actually *frozen* for some time (a day or two should
> suffice I guess) before being labelled 2.4.X.
>
> Just the two cents from a newbie - I hope/mean to offense noone with that
>
> Fran?ois Cami
>
>
>
> Sean Elble wrote:
>
>
>>Something definitely should be done to help "stabilize" the tree; it's not
>>really a big deal for most of us if something is broken, as you know there
>>will be a fix posted very soon after the release, _but_ bugs like these
>>don't exactly make Linux "look good" to the rest of the UNIX community. A
>>FreeBSD advocate might say "well, FreeBSD never does _that_". My
>>
> suggestion
>
>>to help fix the problem would be to do what SGI does; have two seperate
>>trees that strive to stay as close to each other as possible, but one
>>becomes part of the "maintaince stream", where only bug fixes and the such
>>are added, and a "features stream", where actual new features are added
>>
> in.
>
>>Take a look at some of the IRIX web pages at http://www.sgi.com/ for a
>>better idea of how that works, but believe me, it works. This would be in
>>addition to some sort of testing suite that each official kernel must pass
>>before it is released. With the growing number of (important/big) Linux
>>users, we must make sure each kernel is rock-solid before being released.
>>This is definitely more of a political topic than a technical one, but it
>>has to be addressed nonetheless.
>>
>>-----------------------------------------------
>>Sean P. Elble
>>Editor, Writer, Co-Webmaster
>>ReactiveLinux.com (Formerly MaximumLinux.org)
>>http://www.reactivelinux.com/
>>[email protected]
>>-----------------------------------------------
>>
Umm... Linus, when are you going to open the 2.5.x development cycle? That
is how we used to catch this kind of thing.
Matthew D. Pitts
Pitts Computer Services
[email protected]
----- Original Message -----
From: "Fran?ois Cami" <[email protected]>
To: "Sean Elble" <[email protected]>
Cc: <[email protected]>; "John Alvord" <[email protected]>;
<[email protected]>
Sent: Monday, November 12, 2001 8:03 PM
Subject: Re: Testing Kernel Releases Before Being Released (Was Re: Re: loop
back broken in 2.2.14)
>
> I am wondering too... Anyone got ideas on this ?
>
> I would like to avoid some specific problems... especially
> bugs that show up when compiling a certain module / feature
> of the kernel, like the loopback in 2.4.14.
>
> Those should be very easy to get rid of
> [it only takes some kernel testers to debug that early, if only
> there actually were a feature freeze that last for one day...].
>
> Fran?ois
Matthew D. Pitts wrote:
> Umm... Linus, when are you going to open the 2.5.x development cycle? That
> is how we used to catch this kind of thing.
*eager to test 2.5* I guess that's one good idea, yes... less 'beta' in
the current 'stable' tree means that there actually is a dev tree.
And we're back at what Sean Elble wrote about SGI having two
trees for IRIX.
Fran?ois
> Matthew D. Pitts
> Pitts Computer Services
> [email protected]
> ----- Original Message -----
> From: "Fran?ois Cami" <[email protected]>
> To: "Sean Elble" <[email protected]>
> Cc: <[email protected]>; "John Alvord" <[email protected]>;
> <[email protected]>
> Sent: Monday, November 12, 2001 8:03 PM
> Subject: Re: Testing Kernel Releases Before Being Released (Was Re: Re: loop
> back broken in 2.2.14)
>
>
>
>>I am wondering too... Anyone got ideas on this ?
>>
>>I would like to avoid some specific problems... especially
>>bugs that show up when compiling a certain module / feature
>>of the kernel, like the loopback in 2.4.14.
>>
>>Those should be very easy to get rid of
>>[it only takes some kernel testers to debug that early, if only
>>there actually were a feature freeze that last for one day...].
>>
>>Fran?ois
>>
>
>
> -
> 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/
>
>
The feature freeze certainly seems to be an important part of things . . .
now we just need to determine what we want to happen during and after the
feature freeze. :-) I certainly think Linus' Linux should be in a CVS tree,
and he should patch to that; in addition, other developers, like Alan Cox,
should have commit access to the tree, but Linus has already shown that he
doesn't want that. Either way, I say "testing, testing, testing!". :-)
-----------------------------------------------
Sean P. Elble
Editor, Writer, Co-Webmaster
ReactiveLinux.com (Formerly MaximumLinux.org)
http://www.reactivelinux.com/
[email protected]
-----------------------------------------------
----- Original Message -----
From: "Fran?ois Cami" <[email protected]>
To: "Sean Elble" <[email protected]>
Cc: <[email protected]>; "John Alvord" <[email protected]>;
<[email protected]>
Sent: Monday, November 12, 2001 8:03 PM
> I am wondering too... Anyone got ideas on this ?
>
> I would like to avoid some specific problems... especially
> bugs that show up when compiling a certain module / feature
> of the kernel, like the loopback in 2.4.14.
Why not introduce a linux-2.4.xx-rc?
If there is no compile error or huge problem it will become linux-2.4.xx
__without__ any change after 1 day.
If there is a problem, only a patch for this problem is applied.
Just an idea
greetings
Christian
The real solution I think is for Linus to open up 2.5.
If I remember correclty by the time that 2.2 was at 14, 2.3 was open.
Joe
Christian =?iso-8859-15?q?Borntr=E4ger?= <[email protected]> wrote:
> > I am wondering too... Anyone got ideas on this ?
>
> I would like to avoid some specific problems... especially
> bugs that show up when compiling a certain module / feature
> of the kernel, like the loopback in 2.4.14.
Why not introduce a linux-2.4.xx-rc?
If there is no compile error or huge problem it will become linux-2.4.xx
__without__ any change after 1 day.
If there is a problem, only a patch for this problem is applied.
Just an idea
greetings
Christian
Well, the loopback bug is a pain.. but we have had these pains on quite
a few releases in the 2.4.x series...
I wonder if maybe a new method of distributing kernels should happen..
2.4.14 should become 2.4.14-stable meaning that it never ever changes
after release, and 2.4.14-fixed means that these tiny typos, gotchas,
and backport driver fixes can get into 2.4.14-fixed which may change
from day to day, but not get any enhancements, only minor fixes..
People could try 2.4.14-stable, and if they have a problem, they could
just try the 2.4.14-fixed to see if their problem is already
addressed...
The idea is that at least every major release kernel should compile, and
it would reduce the noise levels from people trying out *stable* kernel
versions..
Just a thought..
On Mon, 2001-11-12 at 12:27, [email protected] wrote:
> I thought that the -pre would be the developer kernels, and that an actual release (2.4.14) would have been somewhat tested. I fully understand that a 'runtime' bug in the vm or some other system could arrise and that is one thing. I also understand when a 'less used' driver like NTFS or VFAT breaks, but to see bugs in the loop device in a 'stabilizing' kernel is something that I thought I'd never see.
>
--
"Catch the Magic of Linux..."
--------------------------------------------------------
Michael Peddemors - Senior Consultant
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
Wizard IT Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604)589-0037 Beautiful British Columbia, Canada
I think that was suggested a while ago, in the 2.2 days. It didn't fly! There was however a general consensus that for small bugs that are found in a 'stable' release there should be fixes for just the bug as the next release. I.E. 2.2.15 should be released with just the one fix. Linus didn't seem to go for that as well as some other developers .
If 2.5 was open this kind of thing would probably not happen, but that is not to say that there would not be other issues in 2.4
If someone has the web space, they could as you say, post these 2.4.14.fixme kernels and then also maintain the patches between the official Linus kernel and the fixme kernels.
J
Michael Peddemors <[email protected]> wrote:
> Well, the loopback bug is a pain.. but we have had these pains on quite
a few releases in the 2.4.x series...
I wonder if maybe a new method of distributing kernels should happen..
2.4.14 should become 2.4.14-stable meaning that it never ever changes
after release, and 2.4.14-fixed means that these tiny typos, gotchas,
and backport driver fixes can get into 2.4.14-fixed which may change
from day to day, but not get any enhancements, only minor fixes..
People could try 2.4.14-stable, and if they have a problem, they could
just try the 2.4.14-fixed to see if their problem is already
addressed...
The idea is that at least every major release kernel should compile, and
it would reduce the noise levels from people trying out *stable* kernel
versions..
Just a thought..
On Mon, 2001-11-12 at 12:27, [email protected] wrote:
> I thought that the -pre would be the developer kernels, and that an actual release (2.4.14) would have been somewhat tested. I fully understand that a 'runtime' bug in the vm or some other system could arrise and that is one thing. I also understand when a 'less used' driver like NTFS or VFAT breaks, but to see bugs in the loop device in a 'stabilizing' kernel is something that I thought I'd never see.
>
--
"Catch the Magic of Linux..."
--------------------------------------------------------
Michael Peddemors - Senior Consultant
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
Wizard IT Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604)589-0037 Beautiful British Columbia, Canada
Yes, I seriously considered the feasibility of having 2.4.14-fixed
kernels around, but I could just imagine trying to deal with millions of
people trying to download known good kernels on our bandwidth...
It would be good to be able to point people to a stable kernel.. instead
of having to recommend kernels in the pre-series..
But for now, fixing the 2.4.14. loopback bug has given us a kernel we
are most comfortable with..
Just wish that 2.4.14 was that kernel..
On Wed, 2001-11-14 at 10:17, [email protected] wrote:
> I think that was suggested a while ago, in the 2.2 days. It didn't fly! There was however a general consensus that for small bugs that are found in a 'stable' release there should be fixes for just the bug as the next release. I.E. 2.2.15 should be released with just the one fix. Linus didn't seem to go for that as well as some other developers .
>
> If 2.5 was open this kind of thing would probably not happen, but that is not to say that there would not be other issues in 2.4
>
> If someone has the web space, they could as you say, post these 2.4.14.fixme kernels and then also maintain the patches between the official Linus kernel and the fixme kernels.
--
"Catch the Magic of Linux..."
--------------------------------------------------------
Michael Peddemors - Senior Consultant
LinuxAdministration - Internet Services
NetworkServices - Programming - Security
Wizard IT Services http://www.wizard.ca
Linux Support Specialist - http://www.linuxmagic.com
--------------------------------------------------------
(604)589-0037 Beautiful British Columbia, Canada
On 20011115 Michael Peddemors wrote:
>Yes, I seriously considered the feasibility of having 2.4.14-fixed
>kernels around, but I could just imagine trying to deal with millions of
>people trying to download known good kernels on our bandwidth...
>
>It would be good to be able to point people to a stable kernel.. instead
>of having to recommend kernels in the pre-series..
>
...
>On Wed, 2001-11-14 at 10:17, [email protected] wrote:
>> I think that was suggested a while ago, in the 2.2 days. It didn't fly! There was however a general consensus that for small bugs that are found in a 'stable' release there should be fixes for just the bug as the next release. I.E. 2.2.15 should be released with just the one fix. Linus didn't seem to go for that as well as some other developers .
>>
Well, Linus could post a 'errata' patch...
Layout now in ftp space is (reverse date order):
test-kernels
ChangeLog-2.4.14
LATEST-IS-2.4.14
linux-2.4.14.tar.bz2
A couple files could be posted, named Errata-2.4.14 and linux-2.4.14-errata.bz2,
first being a description of what the second (the patchs) cures...with names like
that so the listing gets them visible near the main tarball...
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.15-pre4-beo-2 #1 SMP Thu Nov 15 13:02:43 CET 2001 i686
Michael Peddemors wrote:
> Yes, I seriously considered the feasibility of having 2.4.14-fixed
> kernels around, but I could just imagine trying to deal with millions of
> people trying to download known good kernels on our bandwidth...
As has been mentioned before I think that the best way to avoid little
problems like this is to have a 2.4.x-rc1 kernel around for a day, if no
problems are found then that tree becomes 2.4.x if a problem is found
then is becomes 2.4.x-rc2 etc...
Cheers
Adam
Well I think it is a good idea to do this and have errata patches or something. I don't think Linus wants the extra work. I'd do it myself, but I don't have the ftp storage space, the time or the bandwidth. I am now keeping seperate trees on my box. One that is the default kernel and then my tree which has fixes to that tree. I'll be working out a
system of testing and migration now ..................
> Well, Linus could post a 'errata' patch...
> Layout now in ftp space is (reverse date order):
>
> test-kernels
> ChangeLog-2.4.14
> LATEST-IS-2.4.14
> linux-2.4.14.tar.bz2