Re: v2.6 vs v3.0

Re: v2.6 vs v3.0

[walt]

james wrote:

> ...If I was a marketing person I would call it linux 3.0.0 
> enterprize edition, if we can get LVM2, raid and break the 2 terabyte 
> filesystem limit...

If you were a marketing person you wouldn't know what any of those
words mean.

Re: v2.6 vs v3.0

[Mikael Pettersson]

On 01 Oct 2002 12:31:10 +0100, Alan Cox wrote:
>On Tue, 2002-10-01 at 08:54, Mikael Pettersson wrote:
>> - I have several boxes with decent PCI chipsets (BX, HX) but old disks.
>>   With 2.5.39, they tend to spew a couple of ..._intr errors on boot.
>>   (Sorry, can't be more specific right now. I won't be near those
>>   boxes until Saturday.)
>
>Thats fine. Its issuing commands the drives reject. Right now we dont do
>it quietly that is all.

Ok, thanks. I won't worry about those then.

>> - My Intel AL440LX box (440LX chipset, 20G Quantum Fireball) worked
>>   brilliantly up to 2.5.36, but hangs *hard* with 2.5.39 as soon
>>   as I tar zxf the kernel source tarball.
>>   (May or may not be IDE. I'll try a minimal 2.5.39 tonight.)
>
>Thats PIIX, which should be the most boringly stable configuration of
>the lot 8(

The bug turned out to be in INITRD not IDE or PIIX. If and only if
I boot with an initrd the kernel hangs really hard somewhere in the
middle of a tar zxf of the kernel tarball (which is why I suspected IDE).
It seems like INITRD clobbers some critical data structure. (Neither the
NMI watchdog nor SysRQ would bring it out of the hang.)

/Mikael

Re: v2.6 vs v3.0

[John L. Males]

[-- Attachment #1: Type: text/plain, Size: 9455 bytes --]

Linus,

***** Please BCC me in on any reply, not CC me.
Two reasons, I am not on the Mailing List,
and second I am suffering BIG time with SPAM
from posting to mailing lists/Newsgroups.
Instructions on real address at bottom.
Thanks in advance. *****

> From: Linus Torvalds
> Subject: Re: v2.6 vs v3.0
> Date: 	Sat, 28 Sep 2002 18:31:45 -0700 (PDT)
> 
> On Sat, 28 Sep 2002, Ingo Molnar wrote:
> > 
> > i consider the VM and IO improvements one of the most important
> > things that happened in the past 5 years - and it's definitely
> > something that users will notice. Finally we have a top-notch VM
> > and IO subsystem (in addition to the already world-class
> > networking subsystem) giving significant improvements both on the
> > desktop and the server - the jump from 2.4 to 2.5 is much larger
> > than from eg. 2.0 to 2.4.
> 
> Hey, _if_ people actually are universally happy with the VM in the
> current 2.5.x tree, I'll happily call the dang thing 5.0 or whatever
> (just kidding, but yeah, that would be a good enough reason to bump
> the major number).

Just a comment, I suggest the version should stay in the 2.x domain. 
Being called a 2.6 makes sense as it follows the established version
naming.  If there is a trend to do a version 2.42.x or 2.62.x I
suggest that the respective development versions would be 2.32.x and
2.52.x. 

> 
> However, I'll believe that when I see it. Usually people don't
> complain during a development kernel, because they think they
> shouldn't, and then when it becomes stable (ie when the version
> number changes) they are surprised that the behabviour didn't
> magically improve, and _then_ we get tons of complaints about how
> bad the VM is under their load.

The reason is simple why this happens.  People and organizations do
not have time to do such testing, let alone create a parallel test
system.  This means real and serious effort needs to be taken in
developing well focused test cases for the various elements of the
Kernel, run each RC and final of Kernel through these battery of
tests, then releae the Kernel RC for evaluation by the community to
find the type of bugs that cannot be found in formal QA/Testing due to
obvious nature of limited hardware combinations that can be tested. 
Point is, people can be really shy of testing something that is
"development" based and not been formally tested.  I know from first
hand experience, I have gone back to the 2.2.x kernel simply because
the 2.4.x kernel has had too many stability issues for my modest day
to day workstation use as much as I wanted some of the improvements in
the 2.4.x kernel.

Even when the Kernel is released as "production" level many sit on
fence to see what others experience and flush out.  This happens to
greater degree as there is no formal Kernel testing.  This has to
change.  It cannot be started overnight, but in steps it can and grow
to base.  I know there are projects and efforts to do formal Kernel
testing, but it needs to be part of the process and fully supported by
the community.  Otherwise the Kernel (the heart and soul of the
system) is just not taken as serious as fast as it should and deserves
from all the fine effort and talent that gives the Kernel its life.

> 
> Am I hapyy with current 2.5.x?  Sure. Are others? Apparently. But
> does that mean that we have a top-notch VM and we should bump the
> major number? I wish.
> 
> The block IO cleanups are important, and that was the major thing
> _I_ personally wanted from the 2.5.x tree when it was opened. I
> agree with you there. But I don't think they are
> major-number-material.

Agreeded.

> 
> Anyway, people who are having VM trouble with the current 2.5.x
> series, please _complain_, and tell what your workload is. Don't sit
> silent and make us think we're good to go.. And if Ingo is right,
> I'll do the 3.0.x thing.

Linus, I have not been able to get my system in state to do the
testing of the VM subsystem due mostly to other issues.  If there is
someone in Toronto that can allow me access to one system that has
both IDE and SCSI on it and at least 256MB of RAM I have lots of
special testing I can do on the VM subsystem.  CPU wise it would be
good to have a uniprocessor as well as SMP system, where CPU is at
least in the 400Mz or above range.  I reatehr have a slower level CPU
system that too fast.  If both a fast and slow CPU system can be made
available that is great.  If only SMP system can be provided or meets
other requirements, that is ok, I will just disable SMP and compile a
kernels without SMP to do tests.  Do not think this is all a strange
and trivial request, as there are several combination even in the very
very basic sense that should be done.  If the system can have more RAM
to validate the corner that seems to exist with larger memory
configurations that would be great.  It would be most helpful to have
a tape backup to allow easy save and restore of test images without
having to rebuild them each time.  A capacity of at least 4 MB
uncompressed per tape would be most helpful.  A DVD writer would be an
ok alternative to tape.

I am not fussy what is availavle as backup as long as it does job, so
long as there is one and not hard drive based.  Some of this testing
could uncover some file system issues at stress levels based on past
experience.  I therefore need backups to be able to shorten time to
restore and retest for any issues found and also to always start with
"exact" same reference point in case there is an additive element of
bugs to the testing that will distort the testing.

A native network connection of at least 10 mbits to allow FTP installs
would be most helpful, as well as a CDWriter.

I have created various programs and test cases, but still need to
refine them in terms of making them more automated.  For not I can
easily create a number of test cases, but has much duplicate effort on
coding until I can distill the elements and then ayutomate many of the
elements.  I honestly believe what I have developed more effectively
isolates the VM subsystem so that other kernel functions and demands
do not cloud the ability to evaluate a VM subsystem.

The tests I would conduct would at a minimum test and compare the VM
behaviour of Linux Kernel versions 2.2.22, 2.4.18, 2.4.19, 2.4.20,
current 2.5.x, FreeBSD 4.6, 4.6.2, 4.5.  All the Linux versions would
be compiled done on the same base distribution and configuration. 
Side effects of VM testing would require more variables to be tested
in combination to ensure no ill effects of system VM stress affect the
other elements of the Kernel, i.e. to ensure Web Servers, Database
servers, etc can be stable under peak stress conditions with respect
to file systems and no accumulating loss of system performance as
function of time and system stress. 
 
> 
> 		Linus

Regards,

John L. Males
Software I.Q. Consulting
Toronto, Ontario
Canada
30 September 2002 14:20


==================================================================


According to Steve McConnell in:
After the Gold Rush: Creating a True Profession of
Software Engineering
About 50% of the current software engineering body of knowledge
is stable and will still be relevant 30 years from now.


***** Please BCC me in on any reply, not CC me.
Two reasons, I am not on the Mailing List,
and second I am suffering BIG time with SPAM
from posting to mailing lists/Newsgroups.
Instructions on real address at bottom.
Thanks in advance. *****


Please BCC me by replacing after the "@" as follows:
TLD =         The last three letters of the word "internet"
Domain name = The first three letters of the word "theory",
              followed by the first three letters of the word
              "offsite", followed by the first three letters
              of the country "Iceland".
My appologies in advance for the jumbled eMail address
and request to BCC me, but SPAM has become a very serious
problem.  The eMail address in my header information is
not a valid eMail address for me.  I needed to use a valid
domain due to ISP SMTP screen rules.

Please note: You may experience delays in my replies.  I will
             reply.

             This is due to major restoration activity to my riser
             section of the building.

             My internet access will be limited to a couple weekday
             evenings.  Weekend access will be a bit better but
             limited as an indirect consequence of the restoration
             work.

             If for any reason you need a more immediate reply or
             fail to receive a reply, please phone and leave a
             message.  If you do leave a phone message, please note
             that I may not be able to hear the message and/or
             reply until the evening.  This will be due to the
             extensive noise levels of the restoration work
             activity drowning out most other volume levels of
             sound.

             The work starts 22 July 2002.  Based on similar
             experience to other sections of the building I would
             estimate the major noise element of the work to be
             about 4+ weeks for my riser.  There will be secondary
             instances once other ajacent riser sections are done
             that will have a similar impact, but for lessor
             periods of time.

             My appologies in advance, but this is mandated work
             that must be done.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: v2.6 vs v3.0

[John L. Males]

[-- Attachment #1: Type: text/plain, Size: 5602 bytes --]

John,

***** Please BCC me in on any reply, not CC me.
Two reasons, I am not on the Mailing List,
and second I am suffering BIG time with SPAM
from posting to mailing lists/Newsgroups.
Instructions on real address at bottom.
Thanks in advance. *****

I am serious.  If you cannot respect that wish then so be it.  Do you
think anyone willing to make an offer of time and effort such as I
have would make light of this?  The fact you have made the effort to
decompose the eMail address demonstrates the fact it can be done and
not that much effort.  It is not like I am posting with no valid eMail
address or without indicating what my real eMail address is.  What I
have done is not that much different that other people have done when
posting to the LKML.  I have just made it difficult for eMail bots to
harvest my eMail address but deleting/changing the .at., at, NOSPAM,
extra levels in domain addresses, etc items that others use to effect
the same result. 

If it was not for the experiences I have already had with SPAM to the
LKML I be more than happy to include my real eMail address in my eMail
headers.  It was in fact that I did that has me being hit by all sorts
of SPAM.  Please do not tell me all about the tools to delete SPAM.  I
know of some, and many I cannot use for various reasons, mostly to do
with turning back eMail I need to receive.

I was not aware you spoke on behalf of Linus. 

If you feel I am sending "junk mail" then I kindly suggest you report
that to your ISP, my ISP and other reporting authorities.  Let them
determine if my posting is against AUP of internet and providers.  Oh
yes, of course people who send "junk mail" have and use a GPG key,
that is on the keyserver as well!


Regards,

John L. Males
Software I.Q Consulting
Toronto, Ontario
Canada
30 September 2002 18:02

 
********** Reply Seperator **********

On (Mon) 2002-09-30 21:59:26 +0100 
jbradford@dial.pipex.com wrote in Message-ID:
200209302059.g8UKxQEh007769@darkstar.example.net

To: software_iq@theoffice.net
From: jbradford@dial.pipex.com
Subject: Re: v2.6 vs v3.0
Date: Mon, 30 Sep 2002 21:59:26 +0100 (BST)

> Hi,
> 
> > Please BCC me by replacing after the "@" as follows:
> > TLD =         The last three letters of the word "internet"
> > Domain name = The first three letters of the word "theory",
> >               followed by the first three letters of the word
> >               "offsite", followed by the first three letters
> >               of the country "Iceland".
> > My appologies in advance for the jumbled eMail address
> > and request to BCC me, but SPAM has become a very serious
> > problem.  The eMail address in my header information is
> > not a valid eMail address for me.  I needed to use a valid
> > domain due to ISP SMTP screen rules.
> 
> Are you serious?
> 
> Please don't waste the time of 100+ developers, especially Linus who
> you cc'ed your message to.
> 
> If you are not prepared to include a real return-address, please
> don't post to the kernel dev list, otherwise *you are sending junk
> mail yourself*.
> 
> John.


==================================================================


According to Steve McConnell in:
After the Gold Rush: Creating a True Profession of
Software Engineering
About 50% of the current software engineering body of knowledge
is stable and will still be relevant 30 years from now.


***** Please BCC me in on any reply, not CC me.
Two reasons, I am not on the Mailing List,
and second I am suffering BIG time with SPAM
from posting to mailing lists/Newsgroups.
Instructions on real address at bottom.
Thanks in advance. *****


Please BCC me by replacing after the "@" as follows:
TLD =         The last three letters of the word "internet"
Domain name = The first three letters of the word "theory",
              followed by the first three letters of the word
              "offsite", followed by the first three letters
              of the country "Iceland".
My appologies in advance for the jumbled eMail address
and request to BCC me, but SPAM has become a very serious
problem.  The eMail address in my header information is
not a valid eMail address for me.  I needed to use a valid
domain due to ISP SMTP screen rules.

Please note: You may experience delays in my replies.  I will
             reply.

             This is due to major restoration activity to my riser
             section of the building.

             My internet access will be limited to a couple weekday
             evenings.  Weekend access will be a bit better but
             limited as an indirect consequence of the restoration
             work.

             If for any reason you need a more immediate reply or
             fail to receive a reply, please phone and leave a
             message.  If you do leave a phone message, please note
             that I may not be able to hear the message and/or
             reply until the evening.  This will be due to the
             extensive noise levels of the restoration work
             activity drowning out most other volume levels of
             sound.

             The work starts 22 July 2002.  Based on similar
             experience to other sections of the building I would
             estimate the major noise element of the work to be
             about 4+ weeks for my riser.  There will be secondary
             instances once other ajacent riser sections are done
             that will have a similar impact, but for lessor
             periods of time.

             My appologies in advance, but this is mandated work
             that must be done.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: v2.6 vs v3.0

[Nick Piggin]

Whoops! Looks like you just blew your cover... ;)
Nick

*BCC'ed to software_iq@theoffice.net*

John L. Males wrote:

>[snip] 
>********** Reply Seperator **********
>
>On (Mon) 2002-09-30 21:59:26 +0100 
>jbradford@dial.pipex.com wrote in Message-ID:
>200209302059.g8UKxQEh007769@darkstar.example.net
>
>To: software_iq@theoffice.net
>From: jbradford@dial.pipex.com
>Subject: Re: v2.6 vs v3.0
>Date: Mon, 30 Sep 2002 21:59:26 +0100 (BST)
>[snip]
>

Re: v2.6 vs v3.0

[Christoph Hellwig]

On Mon, Sep 30, 2002 at 06:02:44PM -0400, John L. Males wrote:
> John,
> 
> ***** Please BCC me in on any reply, not CC me.
> Two reasons, I am not on the Mailing List,
> and second I am suffering BIG time with SPAM
> from posting to mailing lists/Newsgroups.
> Instructions on real address at bottom.
> Thanks in advance. *****
> 

Then don't post to public lists.

Re: [PATCH-RFC] 4 of 4 - New problem logging macros, SCSI RAIDdevice driver

[Ingo Molnar]

On Thu, 26 Sep 2002, Linus Torvalds wrote:
> On Thu, 26 Sep 2002, Jeff Garzik wrote:
> > Tangent question, is it definitely to be named 2.6?
> 
> I see no real reason to call it 3.0.
> 
> The order-of-magnitude threading improvements might just come closest to
> being a "new thing", but yeah, I still consider it 2.6.x. We don't have
> new architectures or other really fundamental stuff. In many ways the
> jump from 2.2 -> 2.4 was bigger than the 2.4 -> 2.6 thing will be, I
> suspect.

i consider the VM and IO improvements one of the most important things
that happened in the past 5 years - and it's definitely something that
users will notice. Finally we have a top-notch VM and IO subsystem (in
addition to the already world-class networking subsystem) giving
significant improvements both on the desktop and the server - the jump
from 2.4 to 2.5 is much larger than from eg. 2.0 to 2.4.

I think due to these improvements if we dont call the next kernel 3.0 then
probably no Linux kernel in the future will deserve a major number. In 2-4
years we'll only jump to 3.0 because there's no better number available
after 2.8. That i consider to be ... boring :) [while kernel releases are
supposed to be a bit boring, i dont think they should be _that_ boring.]

	Ingo

Re: v2.6 vs v3.0

[Linus Torvalds]

On Sat, 28 Sep 2002, Ingo Molnar wrote:
> 
> i consider the VM and IO improvements one of the most important things
> that happened in the past 5 years - and it's definitely something that
> users will notice. Finally we have a top-notch VM and IO subsystem (in
> addition to the already world-class networking subsystem) giving
> significant improvements both on the desktop and the server - the jump
> from 2.4 to 2.5 is much larger than from eg. 2.0 to 2.4.

Hey, _if_ people actually are universally happy with the VM in the current
2.5.x tree, I'll happily call the dang thing 5.0 or whatever (just
kidding, but yeah, that would be a good enough reason to bump the major
number).

However, I'll believe that when I see it. Usually people don't complain 
during a development kernel, because they think they shouldn't, and then 
when it becomes stable (ie when the version number changes) they are 
surprised that the behabviour didn't magically improve, and _then_ we get 
tons of complaints about how bad the VM is under their load.

Am I hapyy with current 2.5.x?  Sure. Are others? Apparently. But does 
that mean that we have a top-notch VM and we should bump the major number? 
I wish.

The block IO cleanups are important, and that was the major thing _I_ 
personally wanted from the 2.5.x tree when it was opened. I agree with you 
there. But I don't think they are major-number-material.

Anyway, people who are having VM trouble with the current 2.5.x series, 
please _complain_, and tell what your workload is. Don't sit silent and 
make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x 
thing.

		Linus

Re: v2.6 vs v3.0

[james]

On Saturday 28 September 2002 08:31 pm, Linus Torvalds wrote:
> On Sat, 28 Sep 2002, Ingo Molnar wrote:
> > i consider the VM and IO improvements one of the most important things
> > that happened in the past 5 years - and it's definitely something that
> > users will notice. Finally we have a top-notch VM and IO subsystem (in
> > addition to the already world-class networking subsystem) giving
> > significant improvements both on the desktop and the server - the jump
> > from 2.4 to 2.5 is much larger than from eg. 2.0 to 2.4.
>
> Hey, _if_ people actually are universally happy with the VM in the current
> 2.5.x tree, I'll happily call the dang thing 5.0 or whatever (just
> kidding, but yeah, that would be a good enough reason to bump the major
> number).
>
> However, I'll believe that when I see it. Usually people don't complain
> during a development kernel, because they think they shouldn't, and then
> when it becomes stable (ie when the version number changes) they are
> surprised that the behabviour didn't magically improve, and _then_ we get
> tons of complaints about how bad the VM is under their load.
>
> Am I hapyy with current 2.5.x?  Sure. Are others? Apparently. But does
> that mean that we have a top-notch VM and we should bump the major number?
> I wish.
>
> The block IO cleanups are important, and that was the major thing _I_
> personally wanted from the 2.5.x tree when it was opened. I agree with you
> there. But I don't think they are major-number-material.
>
> Anyway, people who are having VM trouble with the current 2.5.x series,
> please _complain_, and tell what your workload is. Don't sit silent and
> make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x
> thing.
>
How many people are sitting on the sidelines waiting for guarantee that ide is 
not going to blow up on our filesystems and take our data with it. Guarantee 
that ide is working and not dangerous to our data, then I bet a lot more 
people will come back and bang on 2.5. 

I know this whole ide mess have taken me away from the devolemental series. 
And I bet a lot of others. 

My vote for reason to advance to v3.0 would be more based on our filesystems 
surport. .i.e. XFS and the latest Reiserfs and redoing our middle layer, 
.i.e. treating a cdrw as another drive instead of an ide-scsi device and 
ridding us of  /dev/[hs][dg][a=z] and replacing it with a lot saner 
replacement (I know this talked about it, don't know if it has been or will 
be implemented.)   Along with the changes others have mentioned, but I really 
can't judge those because I have not used 2.5 lately for reasons stated 
above. 

Sincerly 
 
James




> 		Linus
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: v2.6 vs v3.0

[Andre Hedrick]

On Sun, 29 Sep 2002, james wrote:

> How many people are sitting on the sidelines waiting for guarantee that ide is 
> not going to blow up on our filesystems and take our data with it. Guarantee 
> that ide is working and not dangerous to our data, then I bet a lot more 
> people will come back and bang on 2.5. 
> 
> I know this whole ide mess have taken me away from the devolemental series. 
> And I bet a lot of others. 

Your points are noted and taken, and once AC and I bang out the details in
2.4-ac series they are easily brought forward.  I am staying off 2.5
until I can ramp back up the learning curve on the changing API's.

I really do not want to go in and change what Jens has port forwarded
until I have a complete grasp again.  There are no more major changes at
this point and only delta's as needed to constrain concerns.

The only change could be the addition of SATA II support as soon as I
receive the WG's documents.

Cheers,

Andre Hedrick
Linux Serial ATA Solutions
LAD Storage Consulting Group

Re: v2.6 vs v3.0

[Gerhard Mack]

nOn Sun, 29 Sep 2002, james wrote:

> How many people are sitting on the sidelines waiting for guarantee that ide is
> not going to blow up on our filesystems and take our data with it. Guarantee
> that ide is working and not dangerous to our data, then I bet a lot more
> people will come back and bang on 2.5.
> James

Some of us are waiting until it actually compiles for us ;) (see previous
bug report)

	Gerhard

--
Gerhard Mack

gmack@innerfire.net

<>< As a computer I find your faith in technology amusing.

Re: v2.6 vs v3.0

[Dr. David Alan Gilbert]

In my case I gave 2.5.x an attempt at building on my x86 box a few weeks
ago but had to give up because of the lack of LVM which I rely on.

I fancy having a go on some of my non-x86 boxen; does anyone know the
state of 2.5.x for non-x86?

(Does anyone other than some marketing bods really care if it is 2.6 or
3.0 - I definitly don't).

Dave
 ---------------- Have a happy GNU millennium! ----------------------   
/ Dr. David Alan Gilbert    | Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM, SPARC and HP-PA | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

Re: v2.6 vs v3.0

[Wakko Warner]

> In my case I gave 2.5.x an attempt at building on my x86 box a few weeks
> ago but had to give up because of the lack of LVM which I rely on.
> 
> I fancy having a go on some of my non-x86 boxen; does anyone know the
> state of 2.5.x for non-x86?
> 
> (Does anyone other than some marketing bods really care if it is 2.6 or
> 3.0 - I definitly don't).

I thought 2.4 should be 3.0 since 1.3 went to 2.0 =)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: v2.6 vs v3.0

[Jens Axboe]

On Sun, Sep 29 2002, Dr. David Alan Gilbert wrote:
> 
> In my case I gave 2.5.x an attempt at building on my x86 box a few weeks
> ago but had to give up because of the lack of LVM which I rely on.

This is a good point. Noone has cared enough about LVM to work on it,
looking at the code in the kernel I cannot blame them. Sistina have
abandoned 2.5 LVM.

Has anyone actually sent patches to Linus removing LVM completely from
2.5 and adding the LVM2 device mapper? If I used LVM, I would have done
exactly that long ago. Linus, what's your oppinion on this?

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Alan Cox]

On Sun, 2002-09-29 at 16:42, Jens Axboe wrote:
> Has anyone actually sent patches to Linus removing LVM completely from
> 2.5 and adding the LVM2 device mapper? If I used LVM, I would have done
> exactly that long ago. Linus, what's your oppinion on this?

I added LVM2 a while ago for my 2.4-ac tree and haven't looked back, its
much nicer code and its clean and easy to understand. I wouldnt
guarantee its bug free but its the kind of code where you can *find* a
bug if one turns up

Re: v2.6 vs v3.0

[Jens Axboe]

On Sun, Sep 29 2002, Alan Cox wrote:
> On Sun, 2002-09-29 at 16:42, Jens Axboe wrote:
> > Has anyone actually sent patches to Linus removing LVM completely from
> > 2.5 and adding the LVM2 device mapper? If I used LVM, I would have done
> > exactly that long ago. Linus, what's your oppinion on this?
> 
> I added LVM2 a while ago for my 2.4-ac tree and haven't looked back, its
> much nicer code and its clean and easy to understand. I wouldnt
> guarantee its bug free but its the kind of code where you can *find* a
> bug if one turns up

As far as I'm concerned that settles it for me. I'll check up on 2.5
lvm2 status tomorrow.

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Jeff Chua]

On 29 Sep 2002, Alan Cox wrote:

> On Sun, 2002-09-29 at 16:42, Jens Axboe wrote:
> > Has anyone actually sent patches to Linus removing LVM completely from
> > 2.5 and adding the LVM2 device mapper? If I used LVM, I would have done
> > exactly that long ago. Linus, what's your oppinion on this?
>
> I added LVM2 a while ago for my 2.4-ac tree and haven't looked back, its
> much nicer code and its clean and easy to understand. I wouldnt
> guarantee its bug free but its the kind of code where you can *find* a
> bug if one turns up

I can't even get past "make apply-patches" with device-mapper.0.96.04 on
2.5.39.

Anyone running lvm2 on 2.5.3x ?

Thanks,
Jeff

Re: v2.6 vs v3.0

[Dave Jones]

On Sun, Sep 29, 2002 at 05:42:54PM +0200, Jens Axboe wrote:

 > Has anyone actually sent patches to Linus removing LVM completely from
 > 2.5 and adding the LVM2 device mapper? If I used LVM, I would have done
 > exactly that long ago. Linus, what's your oppinion on this?

Joe Thornber sent a patch removing LVM1, but LVM2 has yet to
make an appearance in 2.5.x patchform afair.  LVM is in one of
those sneaky positions where they could theoretically cheat
the feature freeze, as whats in the tree right now is fubar,
and we need /something/ before going 2.6/3.0.

It'd be nice to get /something/ in before the feature freeze so
people can bang on this after halloween when we ramp up stability
testing instead of waiting until the last minute.

There are some patches in -dj which make the existing LVM1 code
compile and 'sort of' work, but they're not fit for inclusion imo.

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: v2.6 vs v3.0

[Jens Axboe]

On Sun, Sep 29 2002, Dave Jones wrote:
> On Sun, Sep 29, 2002 at 05:42:54PM +0200, Jens Axboe wrote:
> 
>  > Has anyone actually sent patches to Linus removing LVM completely from
>  > 2.5 and adding the LVM2 device mapper? If I used LVM, I would have done
>  > exactly that long ago. Linus, what's your oppinion on this?
> 
> Joe Thornber sent a patch removing LVM1, but LVM2 has yet to
> make an appearance in 2.5.x patchform afair.  LVM is in one of
> those sneaky positions where they could theoretically cheat
> the feature freeze, as whats in the tree right now is fubar,
> and we need /something/ before going 2.6/3.0.

Indeed. Joe, what's the status on dm2 for 2.5? I seem to recall seeing
patches for 2.5, maybe even as long as 6 months ago.

> It'd be nice to get /something/ in before the feature freeze so
> people can bang on this after halloween when we ramp up stability
> testing instead of waiting until the last minute.

Yep, as far as I'm concerned, if a 2.5 dm2 is in decent shape then I'd
glady kill lvm1 immediately.

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Matthias Andree]

On Sun, 29 Sep 2002, Dave Jones wrote:

> Joe Thornber sent a patch removing LVM1, but LVM2 has yet to
> make an appearance in 2.5.x patchform afair.  LVM is in one of
> those sneaky positions where they could theoretically cheat
> the feature freeze, as whats in the tree right now is fubar,
> and we need /something/ before going 2.6/3.0.

Is not EVMS ready for the show? Is Linux >=2.6 going to have LVM2 and
EVMS? Or just LVM2? I'm not aware of the current status, but I do recall
having seen EVMS stable announcements (but not sure about 2.5 status).

> It'd be nice to get /something/ in before the feature freeze so
> people can bang on this after halloween when we ramp up stability
> testing instead of waiting until the last minute.

Indeed.

Re: v2.6 vs v3.0

[Michael Clark]

On 09/30/02 05:46, Matthias Andree wrote:
> On Sun, 29 Sep 2002, Dave Jones wrote:
> 
> 
>>Joe Thornber sent a patch removing LVM1, but LVM2 has yet to
>>make an appearance in 2.5.x patchform afair.  LVM is in one of
>>those sneaky positions where they could theoretically cheat
>>the feature freeze, as whats in the tree right now is fubar,
>>and we need /something/ before going 2.6/3.0.
> 
> 
> Is not EVMS ready for the show? Is Linux >=2.6 going to have LVM2 and
> EVMS? Or just LVM2? I'm not aware of the current status, but I do recall
> having seen EVMS stable announcements (but not sure about 2.5 status).

 From reading the EVMS list, it was working with 2.5.36 a couple weeks
ago but needs some small bio and gendisk changes to work in 2.5.39.

http://sourceforge.net/mailarchive/forum.php?thread_id=1105826&forum_id=2003

CVS version may be up-to-date quite soon from reading the thread.
It seems to be further along in 2.5 support than LVM2 - also including
the fact that EVMS supports LVM1 metadata (which the 2.5 version of LVM2
may not do so quite so soon from mentions on the lvm list).

I haven't tried EVMS but certainly from looking at the feature set,
it looks more comprehensive and modular than LVM (with its support
for multiple metadata personalities).

I too have LVM on quite a few of my machines, including my desktop,
and if I wanted to test 2.5 right now - i'd probably have to do it
using EVMS.

~mc

Re: v2.6 vs v3.0

[Andrew Morton]

Michael Clark wrote:
> 
> On 09/30/02 05:46, Matthias Andree wrote:
> > On Sun, 29 Sep 2002, Dave Jones wrote:
> >
> >
> >>Joe Thornber sent a patch removing LVM1, but LVM2 has yet to
> >>make an appearance in 2.5.x patchform afair.  LVM is in one of
> >>those sneaky positions where they could theoretically cheat
> >>the feature freeze, as whats in the tree right now is fubar,
> >>and we need /something/ before going 2.6/3.0.
> >
> >
> > Is not EVMS ready for the show? Is Linux >=2.6 going to have LVM2 and
> > EVMS? Or just LVM2? I'm not aware of the current status, but I do recall
> > having seen EVMS stable announcements (but not sure about 2.5 status).
> 
>  From reading the EVMS list, it was working with 2.5.36 a couple weeks
> ago but needs some small bio and gendisk changes to work in 2.5.39.
> 

It's going to break bigtime if someone ups and removes all the
kiobuf code.....

Re: v2.6 vs v3.0

[Kevin Corry]

On Monday 30 September 2002 02:22, Andrew Morton wrote:
> Michael Clark wrote:
> >  From reading the EVMS list, it was working with 2.5.36 a couple weeks
> > ago but needs some small bio and gendisk changes to work in 2.5.39.
>
> It's going to break bigtime if someone ups and removes all the
> kiobuf code.....

I don't think that would be the case, since EVMS doesn't use kiobuf's.

Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/

Re: v2.6 vs v3.0

[Kevin Corry]

On Monday 30 September 2002 02:05, Michael Clark wrote:
> On 09/30/02 05:46, Matthias Andree wrote:
> >
> > Is not EVMS ready for the show? Is Linux >=2.6 going to have LVM2 and
> > EVMS? Or just LVM2? I'm not aware of the current status, but I do recall
> > having seen EVMS stable announcements (but not sure about 2.5 status).
>
>  From reading the EVMS list, it was working with 2.5.36 a couple weeks
> ago but needs some small bio and gendisk changes to work in 2.5.39.
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=1105826&forum_id=2003
>
> CVS version may be up-to-date quite soon from reading the thread.
> It seems to be further along in 2.5 support than LVM2 - also including
> the fact that EVMS supports LVM1 metadata (which the 2.5 version of LVM2
> may not do so quite so soon from mentions on the lvm list).
>
> I haven't tried EVMS but certainly from looking at the feature set,
> it looks more comprehensive and modular than LVM (with its support
> for multiple metadata personalities).
>
> I too have LVM on quite a few of my machines, including my desktop,
> and if I wanted to test 2.5 right now - i'd probably have to do it
> using EVMS.

EVMS is now up-to-date and running on 2.5.39. You can get the latest kernel 
code from CVS (http://sourceforge.net/cvs/?group_id=25076) or Bitkeepr 
(http://evms.bkbits.net/). There will be a new, full release (1.2) coming out 
this week.

Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/

Re: v2.6 vs v3.0

[Michael Clark]

On 09/30/02 21:05, Kevin Corry wrote:
> On Monday 30 September 2002 02:05, Michael Clark wrote:
> 
>>On 09/30/02 05:46, Matthias Andree wrote:
>>
>>>Is not EVMS ready for the show? Is Linux >=2.6 going to have LVM2 and
>>>EVMS? Or just LVM2? I'm not aware of the current status, but I do recall
>>>having seen EVMS stable announcements (but not sure about 2.5 status).
>>
>> From reading the EVMS list, it was working with 2.5.36 a couple weeks
>>ago but needs some small bio and gendisk changes to work in 2.5.39.
>>
>>http://sourceforge.net/mailarchive/forum.php?thread_id=1105826&forum_id=2003
>>
>>CVS version may be up-to-date quite soon from reading the thread.
>>It seems to be further along in 2.5 support than LVM2 - also including
>>the fact that EVMS supports LVM1 metadata (which the 2.5 version of LVM2
>>may not do so quite so soon from mentions on the lvm list).
>>
>>I haven't tried EVMS but certainly from looking at the feature set,
>>it looks more comprehensive and modular than LVM (with its support
>>for multiple metadata personalities).
>>
>>I too have LVM on quite a few of my machines, including my desktop,
>>and if I wanted to test 2.5 right now - i'd probably have to do it
>>using EVMS.
> 
> 
> EVMS is now up-to-date and running on 2.5.39. You can get the latest kernel 
> code from CVS (http://sourceforge.net/cvs/?group_id=25076) or Bitkeepr 
> (http://evms.bkbits.net/). There will be a new, full release (1.2) coming out 
> this week.

Yes, i just booted up with EVMS CVS on 2.5.39. Detected all my LVM LV's fine.
After cautious tests with them mounted ro, i then preceded to mount them rw
and continued boot up. Working fine so far. Great work.

All i needed to do was change my vgscan to evms_vgscan and adjust my mount
points to the new style ( /dev/evms/lvm/<vg></<lv> ).

~mc

Re: v2.6 vs v3.0

[Kevin Corry]

On Monday 30 September 2002 08:49, Michael Clark wrote:
> On 09/30/02 21:05, Kevin Corry wrote:
> > EVMS is now up-to-date and running on 2.5.39. You can get the latest
> > kernel code from CVS (http://sourceforge.net/cvs/?group_id=25076) or
> > Bitkeepr (http://evms.bkbits.net/). There will be a new, full release
> > (1.2) coming out this week.
>
> Yes, i just booted up with EVMS CVS on 2.5.39. Detected all my LVM LV's
> fine. After cautious tests with them mounted ro, i then preceded to mount
> them rw and continued boot up. Working fine so far. Great work.
>
> All i needed to do was change my vgscan to evms_vgscan and adjust my mount
> points to the new style ( /dev/evms/lvm/<vg></<lv> ).

Instead of using "evms_vgscan", you should probably run "evms_rediscover". 
But you really only need that if you've compiled EVMS as modules in your 
kernel.

For volume admin tasks, I would recommend using "evmsgui" if you have X 
available, or "evmsn" if you need text-mode.

The LVM-style commands (like evms_vgscan) were originally written as testing 
tools before we had the fully-functional UIs. They were left around as kind 
of a proof-of-concept that the EVMS engine library API can be used to emulate 
existing volume management tools.

-- 
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/

Re: v2.6 vs v3.0

[Michael Clark]

Hi Kevin,

On 09/30/02 21:05, Kevin Corry wrote:
> EVMS is now up-to-date and running on 2.5.39. You can get the latest kernel 
> code from CVS (http://sourceforge.net/cvs/?group_id=25076) or Bitkeepr 
> (http://evms.bkbits.net/). There will be a new, full release (1.2) coming out 
> this week.

Seems you guys are the furthest ahead for a working logical volume manager
in 2.5. Does the EVMS team plan to send patches for 2.5 before the freeze?

It would be great to have EVMS in 2.5 (assuming the community approves of
EVMS going in). Seems to be very non-invasive touching almost no common code.

How far along are you with the clustering support (distributed locking of
cluster metadata and update notification, etc)? This is what i'm really after.

~mc

Re: v2.6 vs v3.0

[Kevin Corry]

On Monday 30 September 2002 08:59, Michael Clark wrote:
> Hi Kevin,
>
> On 09/30/02 21:05, Kevin Corry wrote:
> > EVMS is now up-to-date and running on 2.5.39. You can get the latest
> > kernel code from CVS (http://sourceforge.net/cvs/?group_id=25076) or
> > Bitkeepr (http://evms.bkbits.net/). There will be a new, full release
> > (1.2) coming out this week.
>
> Seems you guys are the furthest ahead for a working logical volume manager
> in 2.5. Does the EVMS team plan to send patches for 2.5 before the freeze?

Yes. We may send something in for review this week.

> It would be great to have EVMS in 2.5 (assuming the community approves of
> EVMS going in). Seems to be very non-invasive touching almost no common
> code.
>
> How far along are you with the clustering support (distributed locking of
> cluster metadata and update notification, etc)? This is what i'm really
> after.

Right now we are talking about ways to use EVMS in a fail-over cluster 
environment. E.g.: You have four nodes in a cluster each attached to a large 
SAN device. EVMS will provide software fencing of the shared storage so each 
node in the cluster will have a private portion of the SAN. EVMS will allow 
reassigning of storage to other nodes in the cluster in the event of a node 
failure. This approach involves the smallest hit to the existing code and 
very little extra kernel code.

More general cluster support, with support for fully-shared storage (and all 
of the necessary distributed locking and such) will come in 2003. This will 
obviously involve more in-depth code changes.

-- 
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/

Re: v2.6 vs v3.0

[Jochen Friedrich]

Hi Gerhard,

> Some of us are waiting until it actually compiles for us ;) (see previous
> bug report)

Ack (on Alpha), and waiting that after compiling, it also boots :-)

My Avanti (currently running 2.5.18):

cat /proc/cpuinfo
cpu                     : Alpha
cpu model               : EV4
cpu variation           : 0
cpu revision            : 0
cpu serial number       : Linux_is_Great!
system type             : Avanti
system variation        : 0
system revision         : 0
system serial number    : MILO-2.2-18
cycle frequency [Hz]    : 166521620
timer frequency [Hz]    : 1024.00
page size [bytes]       : 8192
phys. address bits      : 34
max. addr. space #      : 63
BogoMIPS                : 326.08
kernel unaligned acc    : 7671003
(pc=fffffc0000954730,va=fffffc00052da056)
user unaligned acc      : 252 (pc=120011758,va=12006c7e4)
platform string         : N/A
cpus detected           : 0

with

CONFIG_FB_ATY=y
CONFIG_FB_ATY_GX=y
CONFIG_FB_ATY_CT=y

i just get a black screen with a wild jumping cursor and than a hang. With
"normal" console, the boot dies with an zero-pointer exception.

I'll try to compile 2.5.39 and send more details about the compile
failures and boot exceptions...

--jochen

Re: v2.6 vs v3.0

[Trever L. Adams]

On Sun, 2002-09-29 at 02:14, james wrote:
> How many people are sitting on the sidelines waiting for guarantee that ide is 
> not going to blow up on our filesystems and take our data with it. Guarantee 
> that ide is working and not dangerous to our data, then I bet a lot more 
> people will come back and bang on 2.5. 

I can tell you right now that I am one of these.  I usually would have
been involved in testing it for my situations/needs several months ago,
but I have been very leary of the IDE and block changes.  I have one
machine (a router) that I could test it on if I knew that the dangers of
IDE and block were at least low and that the IPv4 and associated
networking connection tracking and NAT stuff worked.

Trever

Re: v2.6 vs v3.0

[Jens Axboe]

On Sun, Sep 29 2002, Trever L. Adams wrote:
> On Sun, 2002-09-29 at 02:14, james wrote:
> > How many people are sitting on the sidelines waiting for guarantee
> > that ide is not going to blow up on our filesystems and take our
> > data with it. Guarantee that ide is working and not dangerous to our
> > data, then I bet a lot more people will come back and bang on 2.5. 
> 
> I can tell you right now that I am one of these.  I usually would have
> been involved in testing it for my situations/needs several months
> ago, but I have been very leary of the IDE and block changes.  I have
> one machine (a router) that I could test it on if I knew that the
> dangers of IDE and block were at least low and that the IPv4 and
> associated networking connection tracking and NAT stuff worked.

How many accounts of the new block layer corrupting data have you been
aware of? Since 2.5.1-preX when bio was introduced, I know of one such
bug: floppy, due to the partial completion changes. Hardly critical.

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Trever L. Adams]

On Sun, 2002-09-29 at 11:45, Jens Axboe wrote:
> How many accounts of the new block layer corrupting data have you been
> aware of? Since 2.5.1-preX when bio was introduced, I know of one such
> bug: floppy, due to the partial completion changes. Hardly critical.
> 
> -- 
> Jens Axboe

Sorry Jens, I never meant to imply I had heard of any since that floppy
bug.  I just understand there were some problems at the beginning. 
Also, I haven't been able to follow LKM as well as I would have liked
lately, but a few months ago, in one of the many IDE bash sessions that
have happened in 2.5.x I read a few people blaiming some of the problems
on interactions between the new block layer and the IDE layer.

Sorry about the worries.  I am just trying to be cautious.  I am
guessing you are saying that the block layer is now solid?   If this is
the case, it sure knocks a few of my worries out of the ball park and I
will be that much closer to trying out 2.5.x myself.

Trever ADams

Re: v2.6 vs v3.0

[Jens Axboe]

On Sun, Sep 29 2002, Trever L. Adams wrote:
> On Sun, 2002-09-29 at 11:45, Jens Axboe wrote:
> > How many accounts of the new block layer corrupting data have you been
> > aware of? Since 2.5.1-preX when bio was introduced, I know of one such
> > bug: floppy, due to the partial completion changes. Hardly critical.
> > 
> > -- 
> > Jens Axboe
> 
> Sorry Jens, I never meant to imply I had heard of any since that floppy
> bug.  I just understand there were some problems at the beginning. 
> Also, I haven't been able to follow LKM as well as I would have liked
> lately, but a few months ago, in one of the many IDE bash sessions that
> have happened in 2.5.x I read a few people blaiming some of the problems
> on interactions between the new block layer and the IDE layer.

No worries. I can understand how people would be weary of block layer
changes, as they have the potential to corrupt your data.

> Sorry about the worries.  I am just trying to be cautious.  I am
> guessing you are saying that the block layer is now solid?   If this is

Nah I'm saying that it's always been solid. Why would I suddenly
destabilize it now? :-)

> the case, it sure knocks a few of my worries out of the ball park and I
> will be that much closer to trying out 2.5.x myself.

As always, it's untested territory so a backup may be in order. But I
don't view testing 2.5 as any more dangerous as testing 2.4-ac.

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Trever L. Adams]

On Sun, 2002-09-29 at 12:06, Jens Axboe wrote:
> Nah I'm saying that it's always been solid. Why would I suddenly
> destabilize it now? :-)
> 

Close enough.  Thank you.

> > the case, it sure knocks a few of my worries out of the ball park and I
> > will be that much closer to trying out 2.5.x myself.
> 
> As always, it's untested territory so a backup may be in order. But I
> don't view testing 2.5 as any more dangerous as testing 2.4-ac.
> 
> -- 
> Jens Axboe

I used to religiously test out ac kernels (in the 2.2, 2.3.x and early
2.4.x days).  I don't anymore, so the comparison may not be valid here. 
Anyway, I will try to either test 2.5.x on my router or else find a box
I can play with that doesnt' have so much important data on it.  (I hate
to say it, but I haven't been able to afford, $$ wise, backup for a few
years... I know... I can't afford not to either).

Trever

Re: v2.6 vs v3.0

[Kai Henningsen]

tadams-lists@myrealbox.com (Trever L. Adams)  wrote on 29.09.02 in <1033316012.1326.17.camel@aurora.localdomain>:

> I can play with that doesnt' have so much important data on it.  (I hate
> to say it, but I haven't been able to afford, $$ wise, backup for a few
> years... I know... I can't afford not to either).

Tape drive cost?

One idea we've come up (and surely we're not the only ones) is to use  
cheap IDE disks for backup, possibly in a cold-swappable insert. As long  
as you can keep several backups per disk (say using some of those 100GB  
disks), preferrably even on a different machine, that's fairly cheap.

If you want to keep daily backups for a week, weekly for a year, and all  
on separate media, of course, that's *not* cheap with this method, and  
even DLT or similar prices become acceptable in comparision. But it  
certainly beats *no* backup!

MfG Kai

Re: v2.6 vs v3.0

[Bill Davidsen]

On 30 Sep 2002, Kai Henningsen wrote:

> One idea we've come up (and surely we're not the only ones) is to use  
> cheap IDE disks for backup, possibly in a cold-swappable insert. As long  
> as you can keep several backups per disk (say using some of those 100GB  
> disks), preferrably even on a different machine, that's fairly cheap.
> 
> If you want to keep daily backups for a week, weekly for a year, and all  
> on separate media, of course, that's *not* cheap with this method, and  
> even DLT or similar prices become acceptable in comparision. But it  
> certainly beats *no* backup!

I do that, but it doesn't make for a storage medium I can easily use on
another system. The cost of DVD writers is coming down, and non-magnetic
media may have some advantages as well. Still, thay're small compared to
disk sizes.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: v2.6 vs v3.0

[Matthias Andree]

On Mon, 30 Sep 2002, Bill Davidsen wrote:

> I do that, but it doesn't make for a storage medium I can easily use on
> another system. The cost of DVD writers is coming down, and non-magnetic
> media may have some advantages as well. Still, thay're small compared to
> disk sizes.

There are big drives available if you really want one (and can afford
one, which is the bigger problem usually).

Tandberg has some big SLR drives (50 GB native data, maybe even more,
didn't check for some months), many companies have DLT and SuperDLT that
store several dozen GB each, then there's Ultrium, and if you're after
cheap stuff, there's also ADR (but there are some that require the osst
driver, which is not helpful if you need to support other OSs beyond
Windows and Linux). This list is not complete, and it deliberately omits
helical scan technologies such as DDS.

Re: v2.6 vs v3.0

[Bill Davidsen]

On Tue, 1 Oct 2002, Matthias Andree wrote:

> On Mon, 30 Sep 2002, Bill Davidsen wrote:
> 
> > I do that, but it doesn't make for a storage medium I can easily use on
> > another system. The cost of DVD writers is coming down, and non-magnetic
> > media may have some advantages as well. Still, thay're small compared to
> > disk sizes.
> 
> There are big drives available if you really want one (and can afford
> one, which is the bigger problem usually).

The real problem is that the media is expensive. DVD media is <$10 and
encourages taking backups fairly often. In the long run that's most
important, not the initial cost. Trying to get a client to take an
incremental and store it off-site daily is easier at $5-8 than $50+.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: v2.6 vs v3.0

[Linus Torvalds]

On Sun, 29 Sep 2002, james wrote:
>
> How many people are sitting on the sidelines waiting for guarantee that ide is 
> not going to blow up on our filesystems and take our data with it. Guarantee 
> that ide is working and not dangerous to our data, then I bet a lot more 
> people will come back and bang on 2.5. 

How the hell can I _guarantee_ anything like that?

I can say that the IDE code is the same code that is in 2.4.x, so if 
you're comfortable with 2.4.x wrt IDE, then you should be comfy with 
2.5.x too.

		Linus

Re: v2.6 vs v3.0

[Rik van Riel]

On Sun, 29 Sep 2002, Linus Torvalds wrote:

> How the hell can I _guarantee_ anything like that?

"Quality IDE code, or your disk space back"

No wait, that didn't come out quite right...

Rik
-- 
Bravely reimplemented by the knights who say "NIH".

http://www.surriel.com/		http://distro.conectiva.com/

Spamtraps of the month:  september@surriel.com trac@trac.org

Re: v2.6 vs v3.0

[Alan Cox]

On Sun, 2002-09-29 at 18:42, Linus Torvalds wrote:
> I can say that the IDE code is the same code that is in 2.4.x, so if 
> you're comfortable with 2.4.x wrt IDE, then you should be comfy with 
> 2.5.x too.

*NO*

The IDE code is the experimental code in 2.4-ac. It is _NOT_ the IDE
code in 2.4 and its a lot less tested. I don't think it has any
corruption bugs but it is most definitely not the base 2.4 code and has
plenty of non corruption bugs (PCMCIA hang, taskfile write hang, irq
blocking performance problems)

I use the 2.4-ac version of that code for day to day work. Thats about
as good a guarantee as I can give.

Alan

Re: v2.6 vs v3.0

[Jens Axboe]

On Sun, Sep 29 2002, Alan Cox wrote:
> On Sun, 2002-09-29 at 18:42, Linus Torvalds wrote:
> > I can say that the IDE code is the same code that is in 2.4.x, so if 
> > you're comfortable with 2.4.x wrt IDE, then you should be comfy with 
> > 2.5.x too.
> 
> *NO*
> 
> The IDE code is the experimental code in 2.4-ac. It is _NOT_ the IDE
> code in 2.4 and its a lot less tested. I don't think it has any
> corruption bugs but it is most definitely not the base 2.4 code and has
> plenty of non corruption bugs (PCMCIA hang, taskfile write hang, irq
> blocking performance problems)

2.5 at least does not have the taskfile hang, because I killed taskfile
io.

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Andre Hedrick]

On Mon, 30 Sep 2002, Jens Axboe wrote:

> On Sun, Sep 29 2002, Alan Cox wrote:
> > On Sun, 2002-09-29 at 18:42, Linus Torvalds wrote:
> > > I can say that the IDE code is the same code that is in 2.4.x, so if 
> > > you're comfortable with 2.4.x wrt IDE, then you should be comfy with 
> > > 2.5.x too.
> > 
> > *NO*
> > 
> > The IDE code is the experimental code in 2.4-ac. It is _NOT_ the IDE
> > code in 2.4 and its a lot less tested. I don't think it has any
> > corruption bugs but it is most definitely not the base 2.4 code and has
> > plenty of non corruption bugs (PCMCIA hang, taskfile write hang, irq
> > blocking performance problems)
> 
> 2.5 at least does not have the taskfile hang, because I killed taskfile
> io.

Great :-/  Now that you have restored the "rq->wrq" aka working copy of
the request which in its past life under PIO only updated to block when
the entire request was completed.  So there are no partial completions
possible given the old method in the legacy path.

One of the issues Linus kick my can over was the "requirement" of partial
completeions.  What I need rom block is a way to know how much is
completed of the original total request.  So whatever value is the
original rq->nr_sectors assigned to "TF.2/HF.2" or nsector_offset(s),
needs to be carried in block and updated to reflect how much more is
remaining of this CDB task.

I do not care if you call it "rq->dumbass_accounting_for_andre", but
provide this dummy accounting variable in "struct request" and I will be
happy.  This has nothing to do with bio or bh segments from the kernel.
It is everything about device side accounting carried by block; whereas,
the ll_driver can use it to determine what or if there is to be another
interrupt.

Why are we getting lost interrupts?

Because there is a beautiful "data-block completion" v/s "immediate
interrupt assertion" race between the device and the kernel.  So please
provide a counter which can be used to determine where the interrupt
driven partial completion model the driver is wrt the device/request.

Jens, not asking for much.

Otherwise the ADMA/VDMA is not doable period.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

Re: v2.6 vs v3.0

[Jens Axboe]

On Mon, Sep 30 2002, Andre Hedrick wrote:
> On Mon, 30 Sep 2002, Jens Axboe wrote:
> 
> > On Sun, Sep 29 2002, Alan Cox wrote:
> > > On Sun, 2002-09-29 at 18:42, Linus Torvalds wrote:
> > > > I can say that the IDE code is the same code that is in 2.4.x, so if 
> > > > you're comfortable with 2.4.x wrt IDE, then you should be comfy with 
> > > > 2.5.x too.
> > > 
> > > *NO*
> > > 
> > > The IDE code is the experimental code in 2.4-ac. It is _NOT_ the IDE
> > > code in 2.4 and its a lot less tested. I don't think it has any
> > > corruption bugs but it is most definitely not the base 2.4 code and has
> > > plenty of non corruption bugs (PCMCIA hang, taskfile write hang, irq
> > > blocking performance problems)
> > 
> > 2.5 at least does not have the taskfile hang, because I killed taskfile
> > io.
> 
> Great :-/  Now that you have restored the "rq->wrq" aka working copy of

Make taskfile io work 2.4-ac, and it will work in 2.5 as well. The only
sensible thing to do right now was to disable it in 2.5, imo, and so I
did.

> the request which in its past life under PIO only updated to block when
> the entire request was completed.  So there are no partial completions
> possible given the old method in the legacy path.

I haven't restored anything. 2.4-ac (your base) uses ->wrq copy, so does
2.5.

> One of the issues Linus kick my can over was the "requirement" of partial
> completeions.  What I need rom block is a way to know how much is
> completed of the original total request.  So whatever value is the
> original rq->nr_sectors assigned to "TF.2/HF.2" or nsector_offset(s),
> needs to be carried in block and updated to reflect how much more is
> remaining of this CDB task.

Now that the block layer really can do partial completions properly, I
patched ide-disk to do just that. It's not very well tested, just did it
last week as proof-of-concept.

This breaks the typical offset rules, ie

current_segment_offset = rq->hard_cur_sectors - rq->current_nr_sectors;
total_offset = rq->hard_nr_sectors - rq->nr_sectors;

Haven't though too much about that yet.

> I do not care if you call it "rq->dumbass_accounting_for_andre", but
> provide this dummy accounting variable in "struct request" and I will be
> happy.  This has nothing to do with bio or bh segments from the kernel.
> It is everything about device side accounting carried by block; whereas,
> the ll_driver can use it to determine what or if there is to be another
> interrupt.

What you ask for is already there, but requires that you massage
current_nr_sectors and nr_sectors like ide has always done.

> Why are we getting lost interrupts?
> 
> Because there is a beautiful "data-block completion" v/s "immediate
> interrupt assertion" race between the device and the kernel.  So please
> provide a counter which can be used to determine where the interrupt
> driven partial completion model the driver is wrt the device/request.
> 
> Jens, not asking for much.

Indeed, you are asking for stuff we've had for years.

===== drivers/ide/ide-disk.c 1.16 vs edited =====
--- 1.16/drivers/ide/ide-disk.c	Sat Sep 21 02:32:22 2002
+++ edited/drivers/ide/ide-disk.c	Mon Sep 23 17:18:48 2002
@@ -139,8 +139,8 @@
  */
 static ide_startstop_t read_intr (ide_drive_t *drive)
 {
-	ide_hwif_t *hwif	= HWIF(drive);
-	int i = 0, nsect	= 0, msect = drive->mult_count;
+	ide_hwif_t *hwif = HWIF(drive);
+	int nsect = 0, msect = drive->mult_count;
 	struct request *rq;
 	unsigned long flags;
 	u8 stat;
@@ -174,25 +174,24 @@
 		(unsigned long) rq->buffer+(nsect<<9), rq->nr_sectors-nsect);
 #endif
 	ide_unmap_buffer(rq, to, &flags);
-	rq->sector += nsect;
-	rq->errors = 0;
-	i = (rq->nr_sectors -= nsect);
-	if (((long)(rq->current_nr_sectors -= nsect)) <= 0)
-		ide_end_request(drive, 1, rq->hard_cur_sectors);
+
+	/*
+	 * all done
+	 */
+	if (!ide_end_request(drive, 1, nsect))
+		return ide_stopped;
+
 	/*
 	 * Another BH Page walker and DATA INTERGRITY Questioned on ERROR.
 	 * If passed back up on multimode read, BAD DATA could be ACKED
 	 * to FILE SYSTEMS above ...
 	 */
-	if (i > 0) {
-		if (msect)
-			goto read_next;
-		if (HWGROUP(drive)->handler != NULL)
-			BUG();
-		ide_set_handler(drive, &read_intr, WAIT_CMD, NULL);
-                return ide_started;
-	}
-        return ide_stopped;
+	if (msect)
+		goto read_next;
+	if (HWGROUP(drive)->handler != NULL)
+		BUG();
+	ide_set_handler(drive, &read_intr, WAIT_CMD, NULL);
+	return ide_started;
 }
 
 /*
@@ -203,7 +202,6 @@
 	ide_hwgroup_t *hwgroup	= HWGROUP(drive);
 	ide_hwif_t *hwif	= HWIF(drive);
 	struct request *rq	= hwgroup->rq;
-	int i = 0;
 	u8 stat;
 
 	if (!OK_STAT(stat = hwif->INB(IDE_STATUS_REG),
@@ -217,23 +215,19 @@
 			rq->nr_sectors-1);
 #endif
 		if ((rq->nr_sectors == 1) ^ ((stat & DRQ_STAT) != 0)) {
-			rq->sector++;
-			rq->errors = 0;
-			i = --rq->nr_sectors;
-			--rq->current_nr_sectors;
-			if (((long)rq->current_nr_sectors) <= 0)
-				ide_end_request(drive, 1, rq->hard_cur_sectors);
-			if (i > 0) {
-				unsigned long flags;
-				char *to = ide_map_buffer(rq, &flags);
-				taskfile_output_data(drive, to, SECTOR_WORDS);
-				ide_unmap_buffer(rq, to, &flags);
-				if (HWGROUP(drive)->handler != NULL)
-					BUG();
-				ide_set_handler(drive, &write_intr, WAIT_CMD, NULL);
-                                return ide_started;
-			}
-                        return ide_stopped;
+			unsigned long flags;
+			char *to;
+
+			if (!ide_end_request(drive, 1, 1))
+				return ide_stopped;
+
+			to = ide_map_buffer(rq, &flags);
+			taskfile_output_data(drive, to, SECTOR_WORDS);
+			ide_unmap_buffer(rq, to, &flags);
+			if (HWGROUP(drive)->handler != NULL)
+				BUG();
+			ide_set_handler(drive, &write_intr, WAIT_CMD, NULL);
+			return ide_started;
 		}
 		/* the original code did this here (?) */
 		return ide_stopped;
===== drivers/ide/ide-taskfile.c 1.4 vs edited =====
--- 1.4/drivers/ide/ide-taskfile.c	Fri Sep 20 00:13:51 2002
+++ edited/drivers/ide/ide-taskfile.c	Mon Sep 23 17:04:47 2002
@@ -611,9 +611,8 @@
 	 * BH walking or segment can only be updated after we have a good
 	 * hwif->INB(IDE_STATUS_REG); return.
 	 */
-	if (--rq->current_nr_sectors <= 0)
-		if (!DRIVER(drive)->end_request(drive, 1, 0))
-			return ide_stopped;
+	if (!DRIVER(drive)->end_request(drive, 1, 1))
+		return ide_stopped;
 	/*
 	 * ERM, it is techincally legal to leave/exit here but it makes
 	 * a mess of the code ...
@@ -669,7 +668,6 @@
 		taskfile_input_data(drive, pBuf, nsect * SECTOR_WORDS);
 		task_unmap_rq(rq, pBuf, &flags);
 		rq->errors = 0;
-		rq->current_nr_sectors -= nsect;
 		msect -= nsect;
 		/*
 		 * FIXME :: We really can not legally get a new page/bh
@@ -677,10 +675,8 @@
 		 * BH walking or segment can only be updated after we have a
 		 * good hwif->INB(IDE_STATUS_REG); return.
 		 */
-		if (!rq->current_nr_sectors) {
-			if (!DRIVER(drive)->end_request(drive, 1, 0))
-				return ide_stopped;
-		}
+		if (!DRIVER(drive)->end_request(drive, 1, 1))
+			return ide_stopped;
 	} while (msect);
 	if (HWGROUP(drive)->handler == NULL)
 		ide_set_handler(drive, &task_mulin_intr, WAIT_WORSTCASE, NULL);
@@ -740,9 +736,9 @@
 	 * Safe to update request for partial completions.
 	 * We have a good STATUS CHECK!!!
 	 */
-	if (!rq->current_nr_sectors)
-		if (!DRIVER(drive)->end_request(drive, 1, 0))
-			return ide_stopped;
+	if (!DRIVER(drive)->end_request(drive, 1, 1))
+		return ide_stopped;
+
 	if ((rq->current_nr_sectors==1) ^ (stat & DRQ_STAT)) {
 		rq = HWGROUP(drive)->rq;
 		pBuf = task_map_rq(rq, &flags);
@@ -802,13 +798,10 @@
 		msect -= nsect;
 		taskfile_output_data(drive, pBuf, nsect * SECTOR_WORDS);
 		task_unmap_rq(rq, pBuf, &flags);
-		rq->current_nr_sectors -= nsect;
-		if (!rq->current_nr_sectors) {
-			if (!DRIVER(drive)->end_request(drive, 1, 0))
-				if (!rq->bio) {
-					stat = hwif->INB(IDE_STATUS_REG);
-					return ide_stopped;
-				}
+		if (!DRIVER(drive)->end_request(drive, 1, 1)) {
+			/* stat for...? */
+			stat = hwif->INB(IDE_STATUS_REG);
+			return ide_stopped;
 		}
 	} while (msect);
 	rq->errors = 0;
@@ -922,18 +915,14 @@
 		msect -= nsect;
 		taskfile_output_data(drive, pBuf, nsect * SECTOR_WORDS);
 		task_unmap_rq(rq, pBuf, &flags);
-		rq->current_nr_sectors -= nsect;
 		/*
 		 * FIXME :: We really can not legally get a new page/bh
 		 * regardless, if this is the end of our segment.
 		 * BH walking or segment can only be updated after we
 		 * have a good  hwif->INB(IDE_STATUS_REG); return.
 		 */
-		if (!rq->current_nr_sectors) {
-			if (!DRIVER(drive)->end_request(drive, 1, 0))
-				if (!rq->bio)
-					return ide_stopped;
-		}
+		if (!DRIVER(drive)->end_request(drive, 1, 1))
+			return ide_stopped;
 	} while (msect);
 	rq->errors = 0;
 	if (HWGROUP(drive)->handler == NULL)

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Alan Cox]

On Mon, 2002-09-30 at 08:56, Jens Axboe wrote:
> 2.5 at least does not have the taskfile hang, because I killed taskfile
> io.

Thats not exactly a fix 8). 2.5 certainly has the others. Taskfile I/O
is pretty low on my fix list. The fix isnt trivial because we set the
IRQ handler late - so the IRQ can beat us setting the handler, but
equally if we set it early we get to worry about all the old races in
2.3.x

Re: v2.6 vs v3.0

[Jens Axboe]

On Mon, Sep 30 2002, Alan Cox wrote:
> On Mon, 2002-09-30 at 08:56, Jens Axboe wrote:
> > 2.5 at least does not have the taskfile hang, because I killed taskfile
> > io.
> 
> Thats not exactly a fix 8). 2.5 certainly has the others. Taskfile I/O

I didn't claim it was, I just don't want a user setting taskfile io to
'y' because he thinks its cool when we know its broken.

> is pretty low on my fix list. The fix isnt trivial because we set the
> IRQ handler late - so the IRQ can beat us setting the handler, but
> equally if we set it early we get to worry about all the old races in
> 2.3.x

Where exactly is the race?

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Andre Hedrick]

First an apology to Russell for bring him into this thread.

On Mon, 30 Sep 2002, Jens Axboe wrote:

> On Mon, Sep 30 2002, Alan Cox wrote:
> > On Mon, 2002-09-30 at 08:56, Jens Axboe wrote:
> > > 2.5 at least does not have the taskfile hang, because I killed taskfile
> > > io.
> > 
> > Thats not exactly a fix 8). 2.5 certainly has the others. Taskfile I/O
> 
> I didn't claim it was, I just don't want a user setting taskfile io to
> 'y' because he thinks its cool when we know its broken.
> 
> > is pretty low on my fix list. The fix isnt trivial because we set the
> > IRQ handler late - so the IRQ can beat us setting the handler, but
> > equally if we set it early we get to worry about all the old races in
> > 2.3.x
> 
> Where exactly is the race?

As soon as you complete read or writing the final byte in a pio state
diagram, the device can interrupt instantly!  I do mean instantly.


ide_startstop_t task_out_intr (ide_drive_t *drive)
{
        ide_hwif_t *hwif        = HWIF(drive);
        struct request *rq      = HWGROUP(drive)->rq;
        char *pBuf              = NULL;
        unsigned long flags;
        u8 stat;

        if (!OK_STAT(stat = hwif->INB(IDE_STATUS_REG),
                     DRIVE_READY, drive->bad_wstat)) {
                DTF("%s: WRITE attempting to recover last " \
                        "sector counter status=0x%02x\n",
                        drive->name, stat);
                rq->current_nr_sectors++;
                return DRIVER(drive)->error(drive, "task_out_intr", stat);
        }
        /*
         * Safe to update request for partial completions.
         * We have a good STATUS CHECK!!!
         */
        if (!rq->current_nr_sectors)
                if (!DRIVER(drive)->end_request(drive, 1))
                        return ide_stopped;
        if ((rq->current_nr_sectors==1) ^ (stat & DRQ_STAT)) {
                 rq = HWGROUP(drive)->rq;
                pBuf = task_map_rq(rq, &flags);
                DTF("write: %p, rq->current_nr_sectors: %d\n",
                        pBuf, (int) rq->current_nr_sectors);
                taskfile_output_data(drive, pBuf, SECTOR_WORDS);
KABOOM! The RACE is on! (The handler start point)
                task_unmap_rq(rq, pBuf, &flags);
                rq->errors = 0;
                rq->current_nr_sectors--;
        }
        if (HWGROUP(drive)->handler == NULL)
                ide_set_handler(drive, &task_out_intr, WAIT_WORSTCASE, NULL);
Driver WINS!
        return ide_started;
}

If the device issues an interrupt to the host controller before we can arm
the handler we are dead.

void taskfile_output_data (ide_drive_t *drive, void *buffer, u32 wcount)
{
        if (drive->bswap) {
                ata_bswap_data(buffer, wcount);
                HWIF(drive)->ata_output_data(drive, buffer, wcount);
KABOOM! The RACE is on! (The Second fake start point)
                ata_bswap_data(buffer, wcount);
        } else {
                HWIF(drive)->ata_output_data(drive, buffer, wcount);
KABOOM! The RACE is on! (The Second fake start point)
        }
}

void ata_output_data (ide_drive_t *drive, void *buffer, u32 wcount)
{
        ide_hwif_t *hwif        = HWIF(drive);
        u8 io_32bit             = drive->io_32bit;

        if (io_32bit) {
                if (io_32bit & 2) {
                        unsigned long flags;
                        local_irq_save(flags);
                        ata_vlb_sync(drive, IDE_NSECTOR_REG);
                        hwif->OUTSL(IDE_DATA_REG, buffer, wcount);
                        local_irq_restore(flags);
                } else
                        hwif->OUTSL(IDE_DATA_REG, buffer, wcount);
        } else {
                hwif->OUTSW(IDE_DATA_REG, buffer, wcount<<1);
        }
KABOOM! The RACE is on! (The Real start point)
}


If we are having to lollygag in the kernel for a byteswap or a bounce
buffer (aka memcpy/free) we can/will loose the interrupt.  The old code
would push the handler early resulting in timeouts and double handlers
added.

Now the question is how to addresss the race.

At this point we have two paths each with bugs.
The old legacy path can allow for the wrong handler to be executed for a
given interrupt.  The old path can with the above bug can potentially crap
data.  Specifically wrong handle execution.

The new path can miss setting the handler in time.

It can be fixed and maybe the account process stuff is already present,
and we are at another communication delay but it shall be worked through
calmly, not like the past where nothing gets done and people just become
offended.

Cheers,


Andre Hedrick
LAD Storage Consulting Group

Re: v2.6 vs v3.0

[jbradford]

> > How many people are sitting on the sidelines waiting for guarantee that ide is 
> > not going to blow up on our filesystems and take our data with it. Guarantee 
> > that ide is working and not dangerous to our data, then I bet a lot more 
> > people will come back and bang on 2.5. 
> 
> How the hell can I _guarantee_ anything like that?

You don't need to - just post "2.5.x ide is working, and not dangerous to your data", and loads of people will start using it.  That way, we get it tested a decent amount.

Of course when somebody's root fs get fsck'ed, (pun intended), the list is bound to get a flamewar^Whelpfully worded bug report.

The false rumors that IDE was fubar for a long time in 2.5.x, coupled with the fact that a lot of recent 2.5.x kernels don't compile, seem to have scared off people which is rediculous.

John.

Re: v2.6 vs v3.0

[Pau Aliagas]

On Sun, 29 Sep 2002, james wrote:

> I know this whole ide mess have taken me away from the devolemental series. 
> And I bet a lot of others. 

That is precisely what has kept me out of 2.5. I do not want to risk my 
data due to the IDE problems; otherwise I'd be happy testing 2.5 all 
around in all kind of machines I had available.

Pau

Re: v2.6 vs v3.0

[jbradford]

> The block IO cleanups are important, and that was the major thing _I_ 
> personally wanted from the 2.5.x tree when it was opened. I agree with you 
> there. But I don't think they are major-number-material.

I'd definitely have voted for stable IPV6 being a 3.0.x requirement, but I guess it's a bit late now :-/

> Anyway, people who are having VM trouble with the current 2.5.x series, 
> please _complain_, and tell what your workload is. Don't sit silent and 
> make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x 
> thing.

I think the broken IDE in 2.5.x has meant that it got seriously less testing overall than previous development trees :-(.  Maybe after halloween when it stabilises a bit more we'll get more reports in.

John

Re: v2.6 vs v3.0

[Jeff Garzik]

jbradford@dial.pipex.com wrote:
>>The block IO cleanups are important, and that was the major thing _I_ 
>>personally wanted from the 2.5.x tree when it was opened. I agree with you 
>>there. But I don't think they are major-number-material.
> 
> 
> I'd definitely have voted for stable IPV6 being a 3.0.x requirement, but I guess it's a bit late now :-/

The USAGI guys have just started sending patches in, so there is already 
progress on this front.  And remember that stabilizing and bug fixing 
can continue after Oct 31st... that's just the feature freeze date.


>>Anyway, people who are having VM trouble with the current 2.5.x series, 
>>please _complain_, and tell what your workload is. Don't sit silent and 
>>make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x 
>>thing.
> 
> 
> I think the broken IDE in 2.5.x has meant that it got seriously less testing overall than previous development trees :-(.


I think this is true, but hopefully recent progress on all fronts will 
start encouraging testers to jump back in...   I have not seen any 
IDE-related corruption reports lately [but then maybe I missed them...]

BTW you should fix your word wrap :)

	Jeff

Re: v2.6 vs v3.0

[David S. Miller]

   From: jbradford@dial.pipex.com
   Date: Sun, 29 Sep 2002 08:16:23 +0100 (BST)

   I'd definitely have voted for stable IPV6 being a 3.0.x
   requirement, but I guess it's a bit late now :-/

Not at all, the goal is to get a full USAGI merge at a minimum
by the end of October.

Re: v2.6 vs v3.0

[Jens Axboe]

On Sun, Sep 29 2002, jbradford@dial.pipex.com wrote:
> > Anyway, people who are having VM trouble with the current 2.5.x series, 
> > please _complain_, and tell what your workload is. Don't sit silent and 
> > make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x 
> > thing.
> 
> I think the broken IDE in 2.5.x has meant that it got seriously less
> testing overall than previous development trees :-(.  Maybe after
> halloween when it stabilises a bit more we'll get more reports in.

2.5 is definitely desktop stable, so please test it if you can. Until
recently there was a personal show stopper for me, the tasklist
deadline. Now 2.5 is happily running on my desktop as well.

2.5 IDE stability should be just as good as 2.4-ac.

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Murray J. Root]

On Sun, Sep 29, 2002 at 11:12:29AM +0200, Jens Axboe wrote:
> On Sun, Sep 29 2002, jbradford@dial.pipex.com wrote:
> > > Anyway, people who are having VM trouble with the current 2.5.x series, 
> > > please _complain_, and tell what your workload is. Don't sit silent and 
> > > make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x 
> > > thing.
> > 
> > I think the broken IDE in 2.5.x has meant that it got seriously less
> > testing overall than previous development trees :-(.  Maybe after
> > halloween when it stabilises a bit more we'll get more reports in.
> 
> 2.5 is definitely desktop stable, so please test it if you can. Until
> recently there was a personal show stopper for me, the tasklist
> deadline. Now 2.5 is happily running on my desktop as well.
> 
> 2.5 IDE stability should be just as good as 2.4-ac.
> 
Hmm - our definitions must be different.

ASUS P4S533 (SiS645DX chipset)
P4 2Ghz
1G PC2700 RAM

Disable SMP, enable APIC & IO APIC
Get "WARNING - Unexpected IO APIC found"
system freezes

Disable IO APIC, enable ACPI
system detects ACPI, builds table, freezes.

Disable ACPI, enable ide-scsi in the kernel
kernel panic analyzing hdc

None of these have been reported because I haven't had time to do all the
work involved in making a report that anyone on the team will read.

-- 
Murray J. Root
------------------------------------------------
DISCLAIMER: http://www.goldmark.org/jeff/stupid-disclaimers/
------------------------------------------------
Mandrake on irc.openprojects.net:
  #mandrake & #mandrake-linux = help for newbies 
  #mdk-cooker = Mandrake Cooker 

Re: v2.6 vs v3.0

[Jens Axboe]

On Sun, Sep 29 2002, Murray J. Root wrote:
> On Sun, Sep 29, 2002 at 11:12:29AM +0200, Jens Axboe wrote:
> > On Sun, Sep 29 2002, jbradford@dial.pipex.com wrote:
> > > > Anyway, people who are having VM trouble with the current 2.5.x series, 
> > > > please _complain_, and tell what your workload is. Don't sit silent and 
> > > > make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x 
> > > > thing.
> > > 
> > > I think the broken IDE in 2.5.x has meant that it got seriously less
> > > testing overall than previous development trees :-(.  Maybe after
> > > halloween when it stabilises a bit more we'll get more reports in.
> > 
> > 2.5 is definitely desktop stable, so please test it if you can. Until
> > recently there was a personal show stopper for me, the tasklist
> > deadline. Now 2.5 is happily running on my desktop as well.
> > 
> > 2.5 IDE stability should be just as good as 2.4-ac.
> > 
> Hmm - our definitions must be different.

Not necessarily, you may just have worse luck than me.

> ASUS P4S533 (SiS645DX chipset)
> P4 2Ghz
> 1G PC2700 RAM
> 
> Disable SMP, enable APIC & IO APIC
> Get "WARNING - Unexpected IO APIC found"
> system freezes
> 
> Disable IO APIC, enable ACPI
> system detects ACPI, builds table, freezes.
> 
> Disable ACPI, enable ide-scsi in the kernel
> kernel panic analyzing hdc
> 
> None of these have been reported because I haven't had time to do all the
> work involved in making a report that anyone on the team will read.

But you have time to write this email and complain that it doesn't work?
-> /dev/null, until you send proper reports.

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Kai Henningsen]

axboe@suse.de (Jens Axboe)  wrote on 29.09.02 in <20020929155051.GF1014@suse.de>:

> On Sun, Sep 29 2002, Murray J. Root wrote:

> > None of these have been reported because I haven't had time to do all the
> > work involved in making a report that anyone on the team will read.
>
> But you have time to write this email and complain that it doesn't work?
> -> /dev/null, until you send proper reports.

That was precisely the point, no?

For some people, this goes "bake kernel, make sure nobody is doing  
something critical, reboot, hang, curse, reboot to old kernel, apologize  
for delay, stop fiddling with this thing for today" as the machine in  
question needs to do other stuff.

That's certainly the reason why I haven't figured out yet why our damn  
"new" central server doesn't boot bloody 2.4 without hanging - I certainly  
don't *want* to run 2.2 on that thing. Probably config options.

MfG Kai

Re: v2.6 vs v3.0

[Zwane Mwaikambo]

On Sun, 29 Sep 2002, Murray J. Root wrote:

> ASUS P4S533 (SiS645DX chipset)
> P4 2Ghz
> 1G PC2700 RAM
> 
> Disable SMP, enable APIC & IO APIC
> Get "WARNING - Unexpected IO APIC found"
> system freezes

Send the subsequent messages (iirc it prints some verbose info about the 
IOAPIC in question).

> Disable IO APIC, enable ACPI
> system detects ACPI, builds table, freezes.

Send messages, motherboard/chipset info..

> Disable ACPI, enable ide-scsi in the kernel
> kernel panic analyzing hdc

ditto.

> None of these have been reported because I haven't had time to do all the
> work involved in making a report that anyone on the team will read.

Shouldn't take too long, most time would be spent writing them down if you 
can't retrieve via serial console.

	Zwane
-- 
function.linuxpower.ca

Re: v2.6 vs v3.0

[Alan Cox]

On Sun, 2002-09-29 at 10:12, Jens Axboe wrote:
> 2.5 is definitely desktop stable, so please test it if you can. Until
> recently there was a personal show stopper for me, the tasklist
> deadline. Now 2.5 is happily running on my desktop as well.

Its very hard to make that assessment when the audio layer still doesnt
work, most scsi drivers havent been ported, most other drivers are full
of 2.4 fixed problems and so on.

Most of my boxes won't even run a 2.5 tree yet. I'm sure its hardly
unique. Middle of November we may begin to find out how solid the core
code actually is, as drivers get fixed up and also in the other
direction as we eliminate numerous crashes caused by "fixed in 2.4" bugs

Re: v2.6 vs v3.0

[Jens Axboe]

On Sun, Sep 29 2002, Alan Cox wrote:
> On Sun, 2002-09-29 at 10:12, Jens Axboe wrote:
> > 2.5 is definitely desktop stable, so please test it if you can. Until
> > recently there was a personal show stopper for me, the tasklist
> > deadlock. Now 2.5 is happily running on my desktop as well.
> 
> Its very hard to make that assessment when the audio layer still doesnt
> work, most scsi drivers havent been ported, most other drivers are full
> of 2.4 fixed problems and so on.

I can only talk for myself, 2.5 works fine here on my boxes. Dunno what
you mean about audio layer, emu10k works for me.

SCSI drivers can be a real problem. Not the porting of them, most of
that is _trivial_ and can be done as we enter 3.0-pre and people show up
running that on hardware that actually needs to be ported. The worst bit
is error handling, this I view as the only problem.

Update of drivers to 2.4 level is mainly a matter of Dave (or someone
else) resyncing his -dj tree and feeding it back to Linus.

> Most of my boxes won't even run a 2.5 tree yet. I'm sure its hardly
> unique. Middle of November we may begin to find out how solid the core
> code actually is, as drivers get fixed up and also in the other
> direction as we eliminate numerous crashes caused by "fixed in 2.4" bugs

Well why don't they run with 2.5?

Alan, I think you are a pessimist painting a much bleaker picture of 2.5
than it deserves. Sure lots of drivers may be broken still, I would be
naive if I thought that this is all changed in time for oct 31. Most of
these will not be fixed until people actually _use_ 2.5 (or 3.0-pre, or
whatever it will be called), and that will not happen until Linus
actually releases a -rc or similar. And so the fsck what? Noone expects
2.6-pre/3.0-pre to be perfect.

I'm not worried.

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Dave Jones]

On Sun, Sep 29, 2002 at 05:38:17PM +0200, Jens Axboe wrote:

 > Update of drivers to 2.4 level is mainly a matter of Dave (or someone
 > else) resyncing his -dj tree and feeding it back to Linus.

Theres still boatloads of bits in my tree (around 4MB worth),
last night I spent some time banging on it trying to get things
into a usable, testable state again. The fact it doesn't boot
on my testboxes right now is somewhat limiting, as is being
buried alive in non-2.5 work.
 
 > > Most of my boxes won't even run a 2.5 tree yet. I'm sure its hardly
 > > unique. Middle of November we may begin to find out how solid the core
 > > code actually is, as drivers get fixed up and also in the other
 > > direction as we eliminate numerous crashes caused by "fixed in 2.4" bugs
 > Well why don't they run with 2.5?

Probably numerous reasons (as me). My laptop hangs on boot (no idea why),
my VIA C3 box dies with preemption, some other boxes are still unusable
due to broken SCSI drivers afair.

 > Alan, I think you are a pessimist painting a much bleaker picture of 2.5
 > than it deserves. Sure lots of drivers may be broken still, I would be
 > naive if I thought that this is all changed in time for oct 31.

There's mountains of silly one liner fixes for various problems
(from compile fixes to stability to security issues) in my tree
that need pushing to Linus, the hard part right now is finding
time to do so, but lots of it can even wait until after the feature freeze.
What's important right now is getting everything in that we *need*
included, (biggest absense imo is probably a replacement LVM right now)
 
 > Most of
 > these will not be fixed until people actually _use_ 2.5 (or 3.0-pre, or
 > whatever it will be called), and that will not happen until Linus
 > actually releases a -rc or similar. And so the fsck what? Noone expects
 > 2.6-pre/3.0-pre to be perfect.

*nods*, and with the addition of the various debugging aids that have
popped up in the last week or so, I've no doubt we're on track to nail
down a lot more hard-to-find bugs than we ever have been before long
before hitting a x.x.0 release

		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: v2.6 vs v3.0

[Bjoern A. Zeeb]

On Sun, 29 Sep 2002, Jens Axboe wrote:

Hi,

> On Sun, Sep 29 2002, Alan Cox wrote:
> > On Sun, 2002-09-29 at 10:12, Jens Axboe wrote:
> > > 2.5 is definitely desktop stable, so please test it if you can. Until
> > > recently there was a personal show stopper for me, the tasklist
> > > deadlock. Now 2.5 is happily running on my desktop as well.
> >
> > Its very hard to make that assessment when the audio layer still doesnt
> > work, most scsi drivers havent been ported, most other drivers are full
> > of 2.4 fixed problems and so on.
>
> I can only talk for myself, 2.5 works fine here on my boxes. Dunno what
> you mean about audio layer, emu10k works for me.
>
> SCSI drivers can be a real problem. Not the porting of them, most of
[snip]

simply replying to one of you all ...

Most important problem I currently see is that one of two kernels
do not boot on my MP machine I use as a workstation.

Apart from that and after early 2.5.3x probs were sorted out
I already had 2.5-bk-kernels running and did the following on that
MP machine:

- compiled linux-2.5-bks
- compiled X (runs with multi head)
- listend to music (emu10k)
- watched TV (bttv)
- burned CDs (SCSI)
- ran amanda: dumped multiple input streams from network to IDE disks
  before writing to SCSI tape
- ran vmware (after patchwork to compile ;-)
- started looking at sym53c416 cli() removal and had the scanner
  doing his work (started to debug some pnp things there too, results
  to be posted)
- changed to devfs
- printing and serial are fine too
- the new input stuff now behaves properly too

often did multiple things in parallel (watching tv while compiling
a new kernel, ...)

had really few crashes (~4-6 since 2.5.34)
had some compilation probs with modules and MP but they got either
fixed too fast or patches went into bk within 1-2 days :-)

Going to check JFS (and XFS) in the near future...

So I think I am either one almost happy person with a lotta luck or
you all (did) do a very excellent job!!! ... but please get those
MP (boot) probs sorted out ;-)

Before you start asking what probs: this time it's around ACPI init.

--- snipp ---
PCI: PCI BIOS revision 2.10 entry at 0xfdb91, last bus=1
PCI: Using configuration type 1
ACPI: Subsystem revision 20020918
 tbxface-0099 [03] Acpi_load_tables      : ACPI Tables successfully loaded
Parsing Methods:......................................................................................................
Table [DSDT] - 309 Objects with 22 Devices 102 Methods 19 Regions
ACPI Namespace successfully loaded at root c03a741c
--- dead end where no keyboard or serial console sysreqs are answered ---


so it must be around ... and I assume it's mp_config_ioapic_for_sci()
but still have to trace ...

--- drivers/acpi/bus.c:606 ---
        /*
         * Get a separate copy of the FADT for use by other drivers.
         */
        status = acpi_get_table(ACPI_TABLE_FADT, 1, &buffer);
        if (ACPI_FAILURE(status)) {
                printk(KERN_ERR PREFIX "Unable to get the FADT\n");
                goto error1;
        }

#ifdef CONFIG_X86
        /* Ensure the SCI is set to level-triggered, active-low */
        if (acpi_ioapic)
                mp_config_ioapic_for_sci(acpi_fadt.sci_int);
        else
                eisa_set_level_irq(acpi_fadt.sci_int);
#endif

        status = acpi_enable_subsystem(ACPI_FULL_INITIALIZATION);
        if (ACPI_FAILURE(status)) {
                printk(KERN_ERR PREFIX "Unable to start the ACPI Interpreter\n");
                goto error1;
        }
--- end ---

-- 
Greetings

Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/

Re: v2.6 vs v3.0

[Russell King]

On Sun, Sep 29, 2002 at 05:38:17PM +0200, Jens Axboe wrote:
> SCSI drivers can be a real problem. Not the porting of them, most of
> that is _trivial_ and can be done as we enter 3.0-pre and people show up
> running that on hardware that actually needs to be ported. The worst bit
> is error handling, this I view as the only problem.

2.4.19 SCSI error handling leaves a lot to be desired currently.  I have
a growing pile of patches that fix up that mess.  They are/have been having
an airing on linux-scsi.

Unfortunately, Alan seems to be ignoring those which linux-scsi is happy
with for unknown reasons currently, so I haven't sent them to Marcelo
(even the ones linux-scsi have said should go to Marcelo; I'd prefer them
to get an airing and some feedback from elsewhere first.)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: v2.6 vs v3.0

[Alan Cox]

On Sun, 2002-09-29 at 22:16, Russell King wrote:
> Unfortunately, Alan seems to be ignoring those which linux-scsi is happy
> with for unknown reasons currently,

Because I've been in Finland 

Re: v2.6 vs v3.0

[steve]

We did catch flak on stability issues on 2.4 for whatever the 
reasons. The way I see it we should not move to 3.0 until it's been 
running stable under at least 2.6. The less technical the person 
the more valuable perception becomes. By only moving to 3.0 when 
2.x is seen as totally stable, more new (corporate) people will 
consider it as the foundation for their infrastructure. Look at the 
views of 2.2...

Besides, stability must be more important than features!

-- 

Steve Szmidt
______________________________________________________

Re: v2.6 vs v3.0

[Matthias Andree]

On Sun, 29 Sep 2002, Jens Axboe wrote:

> SCSI drivers can be a real problem. Not the porting of them, most of
> that is _trivial_ and can be done as we enter 3.0-pre and people show up
> running that on hardware that actually needs to be ported. The worst bit
> is error handling, this I view as the only problem.

And a long-standing one. This should have been fixed in 2.2, it has not
been fixed in 2.4, it's much desired for 2.6 -- and people are going to
point away from Linux (and expect Jörg Schilling speaking up again
should 2.6 be released with what he considers broken API -- I cannot
tell if all his items are right, but if a third of what he says is true,
Linux SCSI is not in good shape).

Re: v2.6 vs v3.0

[Tomas Szepe]

> > SCSI drivers can be a real problem. Not the porting of them, most of
> > that is _trivial_ and can be done as we enter 3.0-pre and people show up
> > running that on hardware that actually needs to be ported. The worst bit
> > is error handling, this I view as the only problem.
> 
> And a long-standing one. This should have been fixed in 2.2, it has not
> been fixed in 2.4, it's much desired for 2.6 -- and people are going to
> point away from Linux (and expect Jörg Schilling speaking up again
> should 2.6 be released with what he considers broken API -- I cannot
> tell if all his items are right, but if a third of what he says is true,
> Linux SCSI is not in good shape).

As long as most of that bloke's argumentation strips down to "you don't do
it like everyone else [solaris/irix/whatever] implies you're bound to suck,"
nobody with a bit of sense is going to take him seriously regardless of how
much blah blah he posts on l-k.

T.

Re: v2.6 vs v3.0

[Jan Harkes]

On Sun, Sep 29, 2002 at 05:38:17PM +0200, Jens Axboe wrote:
> On Sun, Sep 29 2002, Alan Cox wrote:
> > Most of my boxes won't even run a 2.5 tree yet. I'm sure its hardly
> > unique. Middle of November we may begin to find out how solid the core
> > code actually is, as drivers get fixed up and also in the other
> > direction as we eliminate numerous crashes caused by "fixed in 2.4" bugs
> 
> Well why don't they run with 2.5?
> 
> Alan, I think you are a pessimist painting a much bleaker picture of 2.5
> than it deserves. Sure lots of drivers may be broken still, I would be
> naive if I thought that this is all changed in time for oct 31. Most of
> these will not be fixed until people actually _use_ 2.5 (or 3.0-pre, or
> whatever it will be called), and that will not happen until Linus
> actually releases a -rc or similar. And so the fsck what? Noone expects
> 2.6-pre/3.0-pre to be perfect.

Ok, after losing a disk in the early 2.5 series, and not being able to
compile pretty much any kernel since 2.5.33, I decided to give 2.5.39 a
try last weekend.

Built kernel, rebooted, almost seems to get stuch during the ide-probing
(10 seconds wait is a conservative estimate), but it came up in single
user. Checking for errors in /proc/kmsg, nothing. Great reboot
multiuser start X open a window lose all access to my keyboard. Completely
log in remotely with ssh, hmm kernel errors about unknown scancodes.

Reboot, just don't use X for the moment, maybe I can catch an oops,
lockup during boot while loading the uhci usb driver. Alt-sysrq works,
another fsck later (these seem to take a lot longer, but that could be
subjective). Disable hotplug/usb during startup, reboot, within 2
minutes orinoco_cs driver locks up and starts throwing debugging goo
about transmit timeouts and resetting card. Nice, except for the fact
that interrupts seem to be disabled and this time magic-sysrq doesn't
work.

Pull the battery out to be able to reboot the laptop, and went back to
2.4.20-latest for now. 2.5.33 did work mostly (after fixing up a bunch
of compile fixes and the oss cs4281 driver), but seems to last only
about 1 hour on battery life vs. the solid 3 1/2 hours with a 2.4 kernel.
All of this is on a Thinkpad X20, which doesn't have a serial console.

Using APM, not ACPI. But this is not a bugreport, because I haven't even
got a chance to isolate any single problem in a way that I can create a
useful report.

> I'm not worried.

I am a bit worried, at least as far as Coda is concerned, there is a lot
of unmerged stuff, and as long as I can't do any testing of the changes
it is a bit useless to send them off to Linus. I hope things stabilize
before the feature freeze.

Jan

Re: v2.6 vs v3.0

[Jeff Willis]

> > Most of my boxes won't even run a 2.5 tree yet. I'm sure its hardly
> > unique. Middle of November we may begin to find out how solid the core
> > code actually is, as drivers get fixed up and also in the other
> > direction as we eliminate numerous crashes caused by "fixed in 2.4" bugs

You're right, it's not unique.  Will they run 2.4?  I've got about a dozen
boxes that have had over a year uptime with 2.0 or 2.2, but won't boot with
the 2.4 or the recent 2.5 I tried.

> Well why don't they run with 2.5?

Good question.  With the 2.4 kernels I've tried zImages worked fine but
bzImages wouldn't boot.   Unfortunately, with the options I need, the kernel
won't fit in a zImage.  The servers were all originally AMI motherboards,
but after replacing a few due to failures, there's a few Abit, Tyans and
Gigabyte replacements.  The Gigabyte (model GA-8IRXP, I think) will boot
bzImages, but I hate to replace motherboards that have worked fine for years
just to boot the new 2.6/3.0.

Re: v2.6 vs v3.0

[Linus Torvalds]

On 29 Sep 2002, Alan Cox wrote:
> 
> Its very hard to make that assessment when the audio layer still doesnt
> work,

Which reminds me: it would be good to have somebody try to merge stuff
from the ALSA tree.

ALSA never got out of their CVS mentality, and apparently nobody bothers 
to do incrementeal merges. Is anybody interested and listening?

		Linus

Re: v2.6 vs v3.0

[Jaroslav Kysela]

On Sun, 29 Sep 2002, Linus Torvalds wrote:

> 
> On 29 Sep 2002, Alan Cox wrote:
> > 
> > Its very hard to make that assessment when the audio layer still doesnt
> > work,
> 
> Which reminds me: it would be good to have somebody try to merge stuff
> from the ALSA tree.
> 
> ALSA never got out of their CVS mentality, and apparently nobody bothers 
> to do incrementeal merges. Is anybody interested and listening?

I am doing that. It seems that you have rejected my big patch, so I am 
trying to split our changed to small chunks. I have about 10 patches, I will
send them to you and lkml. All patches are in BK style with imported 
comments from CVS.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com

Re: v2.6 vs v3.0

[Bill Davidsen]

On Sun, 29 Sep 2002, Jens Axboe wrote:

> On Sun, Sep 29 2002, jbradford@dial.pipex.com wrote:
> > > Anyway, people who are having VM trouble with the current 2.5.x series, 
> > > please _complain_, and tell what your workload is. Don't sit silent and 
> > > make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x 
> > > thing.
> > 
> > I think the broken IDE in 2.5.x has meant that it got seriously less
> > testing overall than previous development trees :-(.  Maybe after
> > halloween when it stabilises a bit more we'll get more reports in.
> 
> 2.5 is definitely desktop stable, so please test it if you can. Until
> recently there was a personal show stopper for me, the tasklist
> deadline. Now 2.5 is happily running on my desktop as well.

2.5.38-mm2 has been stable for me on uni, what is the status of SMP? I had
what looked like logical to physical mapping problems on a BP6 and Abit
dual P5C-166, resulting in syslog data on every drive including those with
no Linux partition. That was somewhere around 2.5.22 to 2.5.26.
 
> 2.5 IDE stability should be just as good as 2.4-ac.

A laudable goal.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: v2.6 vs v3.0

[Jens Axboe]

On Mon, Sep 30 2002, Bill Davidsen wrote:
> On Sun, 29 Sep 2002, Jens Axboe wrote:
> 
> > On Sun, Sep 29 2002, jbradford@dial.pipex.com wrote:
> > > > Anyway, people who are having VM trouble with the current 2.5.x series, 
> > > > please _complain_, and tell what your workload is. Don't sit silent and 
> > > > make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x 
> > > > thing.
> > > 
> > > I think the broken IDE in 2.5.x has meant that it got seriously less
> > > testing overall than previous development trees :-(.  Maybe after
> > > halloween when it stabilises a bit more we'll get more reports in.
> > 
> > 2.5 is definitely desktop stable, so please test it if you can. Until
> > recently there was a personal show stopper for me, the tasklist
> > deadline. Now 2.5 is happily running on my desktop as well.
> 
> 2.5.38-mm2 has been stable for me on uni, what is the status of SMP? I had
> what looked like logical to physical mapping problems on a BP6 and Abit
> dual P5C-166, resulting in syslog data on every drive including those with
> no Linux partition. That was somewhere around 2.5.22 to 2.5.26.

Well I do all my 2.5 testing on SMP, I don't even remember when I last
compiled a UP 2.5 kernel. Well works for me as I wrote earlier, I don't
keep the deskop up more than a few days at the time though. Then I boot
a newer 2.5 on it.

> > 2.5 IDE stability should be just as good as 2.4-ac.
> 
> A laudable goal.

If you know of any points where this is currently not true, I'd like to
hear about it. I'm considering this goal reached. Whether 2.4-ac is at
the level we want is a different story.

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Mikael Pettersson]

Jens Axboe writes:
 > On Mon, Sep 30 2002, Bill Davidsen wrote:
 > > On Sun, 29 Sep 2002, Jens Axboe wrote:
 > > > 2.5 IDE stability should be just as good as 2.4-ac.
 > > 
 > > A laudable goal.
 > 
 > If you know of any points where this is currently not true, I'd like to
 > hear about it. I'm considering this goal reached. Whether 2.4-ac is at
 > the level we want is a different story.

2.5.39 IDE is nowhere near as stable as 2.4.20-pre8:

- I have several boxes with decent PCI chipsets (BX, HX) but old disks.
  With 2.5.39, they tend to spew a couple of ..._intr errors on boot.
  (Sorry, can't be more specific right now. I won't be near those
  boxes until Saturday.)

- Same ..._intr errors on my 486 with a qd6580 VLB controller.
  It also has, in post-2.5.36 kernels, an instant-reboot problem which
  occurs whenever I pass the ide0=qd65xx kernel option required to
  activate its chipset support. (I _believe_ this is because the code
  does something, like a kmalloc, which is illegal at the early
  point IDE's __setup runs.) With 2.5.3x kernels, this box also sees
  a steady stream of spurious interrupts while doing a kernel recompile,
  something it doesn't see in older kernels.

- My Intel AL440LX box (440LX chipset, 20G Quantum Fireball) worked
  brilliantly up to 2.5.36, but hangs *hard* with 2.5.39 as soon
  as I tar zxf the kernel source tarball.
  (May or may not be IDE. I'll try a minimal 2.5.39 tonight.)

All of these work perfectly with 2.4.20-pre8, indeed all previous 2.4
standard kernels, 2.2 + Andre's ide-patch, and with the exception of
the ..._intr errors, 2.5.36.

OTOH, I have three boxes which do appear to work fine with 2.5.39.

/Mikael

Re: v2.6 vs v3.0

[Jens Axboe]

On Tue, Oct 01 2002, Mikael Pettersson wrote:
> Jens Axboe writes:
>  > On Mon, Sep 30 2002, Bill Davidsen wrote:
>  > > On Sun, 29 Sep 2002, Jens Axboe wrote:
>  > > > 2.5 IDE stability should be just as good as 2.4-ac.
>  > > 
>  > > A laudable goal.
>  > 
>  > If you know of any points where this is currently not true, I'd like to
>  > hear about it. I'm considering this goal reached. Whether 2.4-ac is at
>  > the level we want is a different story.
> 
> 2.5.39 IDE is nowhere near as stable as 2.4.20-pre8:

Common misconception. I wrote 2.4-ac, not 2.4 vanilla tre. 2.4-ac is in
flux, 2.5 is too. There are some quirks, most of the 'doesnt work'
nature and not the 'corrupting data' kind.

> - I have several boxes with decent PCI chipsets (BX, HX) but old disks.
>   With 2.5.39, they tend to spew a couple of ..._intr errors on boot.
>   (Sorry, can't be more specific right now. I won't be near those
>   boxes until Saturday.)

But they come up?

> - Same ..._intr errors on my 486 with a qd6580 VLB controller.
>   It also has, in post-2.5.36 kernels, an instant-reboot problem which
>   occurs whenever I pass the ide0=qd65xx kernel option required to
>   activate its chipset support. (I _believe_ this is because the code
>   does something, like a kmalloc, which is illegal at the early
>   point IDE's __setup runs.) With 2.5.3x kernels, this box also sees
>   a steady stream of spurious interrupts while doing a kernel recompile,
>   something it doesn't see in older kernels.

Ok this is a new one, at least to me

> - My Intel AL440LX box (440LX chipset, 20G Quantum Fireball) worked
>   brilliantly up to 2.5.36, but hangs *hard* with 2.5.39 as soon
>   as I tar zxf the kernel source tarball.
>   (May or may not be IDE. I'll try a minimal 2.5.39 tonight.)

Probably not ide, no important changes in there in between 2.6.36 and
present.

> All of these work perfectly with 2.4.20-pre8, indeed all previous 2.4
> standard kernels, 2.2 + Andre's ide-patch, and with the exception of
> the ..._intr errors, 2.5.36.

If you (or anyone else for that matter) come across ide oddities in 2.5,
please try 2.4.20-pre-ac kernels and see if you can reproduce.

-- 
Jens Axboe

Re: v2.6 vs v3.0

[jbradford]

> > - My Intel AL440LX box (440LX chipset, 20G Quantum Fireball) worked
> >   brilliantly up to 2.5.36, but hangs *hard* with 2.5.39 as soon
> >   as I tar zxf the kernel source tarball.
> >   (May or may not be IDE. I'll try a minimal 2.5.39 tonight.)
> 
> Probably not ide, no important changes in there in between 2.6.36 and
> present.

Where can I get the 2.6.x tree, then?  :-)

John.

Re: v2.6 vs v3.0

[Alan Cox]

On Tue, 2002-10-01 at 08:54, Mikael Pettersson wrote:
> - I have several boxes with decent PCI chipsets (BX, HX) but old disks.
>   With 2.5.39, they tend to spew a couple of ..._intr errors on boot.
>   (Sorry, can't be more specific right now. I won't be near those
>   boxes until Saturday.)

Thats fine. Its issuing commands the drives reject. Right now we dont do
it quietly that is all.

> - Same ..._intr errors on my 486 with a qd6580 VLB controller.
>   It also has, in post-2.5.36 kernels, an instant-reboot problem which
>   occurs whenever I pass the ide0=qd65xx kernel option required to

Seems to be specific to the 2.5.x version of the new ide so I guess its
a port error (or just bad luck it now breaks and was iffy before)

> - My Intel AL440LX box (440LX chipset, 20G Quantum Fireball) worked
>   brilliantly up to 2.5.36, but hangs *hard* with 2.5.39 as soon
>   as I tar zxf the kernel source tarball.
>   (May or may not be IDE. I'll try a minimal 2.5.39 tonight.)

Thats PIIX, which should be the most boringly stable configuration of
the lot 8(

Re: v2.6 vs v3.0

[Jens Axboe]

On Tue, Oct 01 2002, Alan Cox wrote:
> > - Same ..._intr errors on my 486 with a qd6580 VLB controller.
> >   It also has, in post-2.5.36 kernels, an instant-reboot problem which
> >   occurs whenever I pass the ide0=qd65xx kernel option required to
> 
> Seems to be specific to the 2.5.x version of the new ide so I guess its
> a port error (or just bad luck it now breaks and was iffy before)

ok, I'll try it in 2.5 then

> > - My Intel AL440LX box (440LX chipset, 20G Quantum Fireball) worked
> >   brilliantly up to 2.5.36, but hangs *hard* with 2.5.39 as soon
> >   as I tar zxf the kernel source tarball.
> >   (May or may not be IDE. I'll try a minimal 2.5.39 tonight.)
> 
> Thats PIIX, which should be the most boringly stable configuration of
> the lot 8(

There's no evidence that this is an ide error yet. I'd like to see some
serial console or similar on that beast. I have no LX board here, but
piix is rock solid.

-- 
Jens Axboe

Re: v2.6 vs v3.0

[Andi Kleen]

jbradford@dial.pipex.com writes:

> > The block IO cleanups are important, and that was the major thing _I_ 
> > personally wanted from the 2.5.x tree when it was opened. I agree with you 
> > there. But I don't think they are major-number-material.
> 
> I'd definitely have voted for stable IPV6 being a 3.0.x requirement, but I guess it's a bit late now :-/

Actually current IPv6 is stable and has been for a long time, it's just not 
completely standards compliant (but still quite usable for a lot of people)

If you mean stable implies the latest whizbang features you have a different
meaning of stable than me.

-Andi

Re: v2.6 vs v3.0

[Jochen Friedrich]

Hi Andi,

> Actually current IPv6 is stable and has been for a long time, it's just not
> completely standards compliant (but still quite usable for a lot of people)

For end systems (no router) with static IPv6 definitions this seems to be
true. However, for machines which use autoconfiguration (stateless as
there isn't a usable IPv6 capable DHCP server AFAIK) or act as routers,
the current state of the implementation of the default route can best be
described as buggy. (Autoconfigured machines seem to loose their default
route after some time, e.g.).

Also, there could be a better communication between the kernel and the
resolver to check if if IPv6 is available, at all. Currently, on IPv4 only
kernels, we often see dialogs like this:

ssh -v mail.scram.de
OpenSSH_3.4p1 Debian 1:3.4p1-2.1, SSH protocols 1.5/2.0, OpenSSL
0x0090607f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to mail.scram.de [3ffe:400:470:1::1:1] port 22.
socket: Address family not supported by protocol
debug1: Connecting to mail.scram.de [195.226.127.117] port 22.
debug1: Connection established.

So IPv6 is returned by the resolver even though IPv6 isn't available in
the kernel. The default of the resolver options should be dependent
on the presence or absence of IPv6 in the currently running kernel IMHO.

Finally, IPv6 sockets which also communicate over IPv4 using mapped
addresses are considered bad nowadays ;-)

Cheers,
--jochen

Re: v2.6 vs v3.0

[Jeff Garzik]

Jochen Friedrich wrote:
> So IPv6 is returned by the resolver even though IPv6 isn't available in
> the kernel. The default of the resolver options should be dependent
> on the presence or absence of IPv6 in the currently running kernel IMHO.


That sounds like glibc's problem...

glibc also has really stupid and annoying /etc/hosts behavior which 
needs fixing, and IIRC it is related to IPv6...

	Jeff

Re: v2.6 vs v3.0

[Andi Kleen]

Jochen Friedrich <jochen@scram.de> writes:

> Hi Andi,
> 
> > Actually current IPv6 is stable and has been for a long time, it's just not
> > completely standards compliant (but still quite usable for a lot of people)
> 
> For end systems (no router) with static IPv6 definitions this seems to be
> true. However, for machines which use autoconfiguration (stateless as
> there isn't a usable IPv6 capable DHCP server AFAIK) or act as routers,
> the current state of the implementation of the default route can best be
> described as buggy. (Autoconfigured machines seem to loose their default
> route after some time, e.g.).

Are you sure this is not related to the routing daemon or rdisc daemon you 
use ? In the past when I had problems with lost default routes always such
a daemon was to blame.

> So IPv6 is returned by the resolver even though IPv6 isn't available in
> the kernel. The default of the resolver options should be dependent
> on the presence or absence of IPv6 in the currently running kernel IMHO.

Sounds more like an glibc issue. I would file a glibc gnats bug on this,
then it may even get fixed. The kernel has nothing to do with this at least.
 
> Finally, IPv6 sockets which also communicate over IPv4 using mapped
> addresses are considered bad nowadays ;-)

Hmm? 

-Andi

Re: v2.6 vs v3.0

[Jens Axboe]

On Sat, Sep 28 2002, Linus Torvalds wrote:
> 
> On Sat, 28 Sep 2002, Ingo Molnar wrote:
> > 
> > i consider the VM and IO improvements one of the most important things
> > that happened in the past 5 years - and it's definitely something that
> > users will notice. Finally we have a top-notch VM and IO subsystem (in
> > addition to the already world-class networking subsystem) giving
> > significant improvements both on the desktop and the server - the jump
> > from 2.4 to 2.5 is much larger than from eg. 2.0 to 2.4.
> 
> Hey, _if_ people actually are universally happy with the VM in the current
> 2.5.x tree, I'll happily call the dang thing 5.0 or whatever (just
> kidding, but yeah, that would be a good enough reason to bump the major
> number).

Works For Me, at _least_ as well as 2.4.20-pre kernels. On my desktop
machine it feels better. After a few days of uptime it's fairly easy to
feel how well a kernel performs for that workload. And 2.5.39 is just
smoother than current 2.4.

> The block IO cleanups are important, and that was the major thing _I_ 
> personally wanted from the 2.5.x tree when it was opened. I agree with you 
> there. But I don't think they are major-number-material.

Dang :-)

--
Jens Axboe, rooting for 3.x

Re: v2.6 vs v3.0

[james]

Upon thinking about 2.6 v3.0 argument, I think we may be  looking at this 
version comparison in the wrong light, it is not wether we have come far 
enough from 2.4.x to make it 3.0 it is wether we have change enough from 
version 2.0.x. 

When I compare running linux 2.0.x to running what will be the next version we 
are looking at a completely different system. For example in v2.0 the only 
file system choices were ext2 or DOS, with a few others that wern't in wide 
spread use.  where you created small partitions to keep fsck's fast, even if 
you had battery backup, you were still basicly limited to 8 gig file systems. 
Today we have ext2, ext3, reiserfs, JFS, XFS, in the last four,  journaling 
capabilities. it is possible and expected  have huge filesystems and patches 
exist to break the 2 terabyte file systems  exist in various stages of 
testing. Not to mention we have LVM, and raid file systems, being used on 
desktop as well server systems. 

Networking has changed as well, we went from mostly 10mbit eternet cards and a 
few 100 mbit cards, to now having 100mbit ethernet as the base of home 
networking, not to mention gigabit ethernet, and ATM gaining popularity in 
the server market, while they are just drivers, the real shift of thinking 
comes in zero copy file transfer and a mature state of the art 
firewalling/routing/bridging etc. in NAT and iptables 

For video we changed from base VGA video text and X, to acellerated video 
processors not just in X, but in framebuffers  used as consoles.

We also have support for diverse set of buses, that change the way we think 
about our system, multiple bridges on PCI, USB v1 and v2, to firewire. 

I will let others more in the know in memory management, discuss the finer 
points of this one, but it is a major change, in 2.0 we just killed random 
programs when out of memory.  today we make a slightly more educated guess as 
what to kill when we are out of memory, not to mention a just one base mix of 
address support, I think it was 2gig user and 2gig, Today we can choose, 1. 
2, or 3 gig of kernel space.  Large memory support in the Kernel , supporting  
36bit memory accessing, That support more memory than I will ever see in the 
near future. 

we have changed from a System that barely supported smp with 2 processors with 
basicly one big kernel lock to a system with finely grained locks and 
semaphores and subsystem spinlocks,  that has decent performance on 8+ cpu 
systems. Numa system surport also appeared since version 2.0.x 

In 2.0.0 we had a 15bit pid with a maximum of 1000 active ( i beleve it is 
less than this) today we have a 32+bit pid on the table with support of many 
more active processes. of couse we have numourous internal file systems that 
did not exist, tmpfs, devfs, etc.....  and changed the way we all think about 
our systems. 

A prempted kernel, need I say more. 


well that is just a small list of the globals systems that change the way we 
think of linux. 

If we continue to justify major version changes based on change in minor 
version to minor version, can we expect linux 2.98,x in the future?  In each 
minor version we rewrite one or two subsytems. And these take many months to 
plan, complete and test, so big enough change in a single minor version 
number to minor version may not be possible at the current size of this 
devolement effort, So yes we have come far enougth from v2.0.x to justify a 
version 3.0.x. If I was a marketing person I would call it linux 3.0.0 
enterprize edition, if we can get LVM2, raid and break the 2 terabyte 
filesystem limit along with what we allready have accomplised. 

Just my opionion 

James

 

Re: v2.6 vs v3.0

[Matthias Andree]

On Sat, 28 Sep 2002, Linus Torvalds wrote:

> Am I hapyy with current 2.5.x?  Sure. Are others? Apparently. But does 
> that mean that we have a top-notch VM and we should bump the major number? 
> I wish.
> 
> The block IO cleanups are important, and that was the major thing _I_ 
> personally wanted from the 2.5.x tree when it was opened. I agree with you 
> there. But I don't think they are major-number-material.
> 
> Anyway, people who are having VM trouble with the current 2.5.x series, 
> please _complain_, and tell what your workload is. Don't sit silent and 
> make us think we're good to go.. And if Ingo is right, I'll do the 3.0.x 
> thing.

I personally have the feeling that 2.2.x performed better than 2.4.x
does, but I cannot go figure because I'm using ReiserFS 3.6 file
systems. I'd also really like to give Linux 2.5.39 or whatever is
current a whirl, but I'm currently using LVM and I'd need anything to
read that. Which one (EVMS or LVM2) is an ignorant-proof install and
reliable enough to read old LVM1 partitions and volumes?

Re: v2.6 vs v3.0

[Alan Cox]

On Sun, 2002-09-29 at 16:26, Matthias Andree wrote:
> I personally have the feeling that 2.2.x performed better than 2.4.x
> does, but I cannot go figure because I'm using ReiserFS 3.6 file

On low end boxes the benchmarks I did show later 2.4-rmap beats 2.2. 2.0
worked suprisingly well (better than pre-rmap 2.4) and as Stephen
claimed the best code was about 2.1.100, 2.2 then dropped badly from
that point.

Low memory is of course where rmap does best, so the 2.4-rmap v 2.4
parts of such testing are not actually that useful

Re: v2.6 vs v3.0

[Matthias Andree]

On Sun, 29 Sep 2002, Alan Cox wrote:

> On Sun, 2002-09-29 at 16:26, Matthias Andree wrote:
> > I personally have the feeling that 2.2.x performed better than 2.4.x
> > does, but I cannot go figure because I'm using ReiserFS 3.6 file
> 
> On low end boxes the benchmarks I did show later 2.4-rmap beats 2.2. 2.0
> worked suprisingly well (better than pre-rmap 2.4) and as Stephen
> claimed the best code was about 2.1.100, 2.2 then dropped badly from
> that point.

Granted, but I don't expect any roll-back to happen. If Stephen can dig
up the best version VM-wise, then if somebody could benchmark 2.6pre
against 2.1.BEST, that might be a good competition to 2.6pre -- modulo
different application profile, of course.

My major concern is usability: VM can be so bad it freezes hell or so
good it brings instant world peace: It won't buy me anything if I cannot
get to my data because LVM1 is unusable and neither EVMS nor LVM2 is in.
I'd like to test-drive 2.5, but booting my kernel and mounting a small
root partition from ext3 (non-LVM) and going without /usr and /opt
(because these are in LVM) is not terribly helpful to give it a try.

It's some big things that must be fixed before the tuning (towards
stability, fixes, performance) can take place. You really can't do the
tasting before you've put the meat in.

Re: v2.6 vs v3.0

[Bill Davidsen]

On 29 Sep 2002, Alan Cox wrote:

> On Sun, 2002-09-29 at 16:26, Matthias Andree wrote:
> > I personally have the feeling that 2.2.x performed better than 2.4.x
> > does, but I cannot go figure because I'm using ReiserFS 3.6 file
> 
> On low end boxes the benchmarks I did show later 2.4-rmap beats 2.2. 2.0
> worked suprisingly well (better than pre-rmap 2.4) and as Stephen
> claimed the best code was about 2.1.100, 2.2 then dropped badly from
> that point.

I might have said 2.1.106 (I'm still running that on one box), but that's
the general sweet spot.
 
> Low memory is of course where rmap does best, so the 2.4-rmap v 2.4
> parts of such testing are not actually that useful

In the 2.4-ac vs. 2.4-aa tests I did in the spring, rmap was better on
small memory, -aa was better with large memory and heavy write load. I
expect ioscheduling to address this, and when I get a totally expendable
large machine I'll try 2.5 again.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: v2.6 vs v3.0

[Bill Davidsen]

On Sat, 28 Sep 2002, Linus Torvalds wrote:

> However, I'll believe that when I see it. Usually people don't complain 
> during a development kernel, because they think they shouldn't, and then 
> when it becomes stable (ie when the version number changes) they are 
> surprised that the behabviour didn't magically improve, and _then_ we get 
> tons of complaints about how bad the VM is under their load.

Part of this is because people who complain often get answers which sound
a lot like "what do you expect, it's a test kernel," or "you have the
source, go fix it," or even "if you don't like go run Windows." This list
is FAR more cordial than newsgroups, but I have seen people who suggested
an improvement get invited to submit a patch.

The other reason is the "it must be me" effect, if something doesn't work
for the user there is a general reaction that something must be configured
wrong.

Anyway that's my impression of why the complaints come as you say, I think
it's going to happen regardless of the version number. 

For what it's worth the changes feel more like 2.2 to 2.4 than 1.2.13 to
2.0, but as long as you don't call it Windows I don't really care;-) 

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.