2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Marcelo Tosatti]

On Wed, 4 Jun 2003, Grover, Andrew wrote:

> > From: Grzegorz Jaskiewicz [mailto:gj@pointblue.com.pl]
> > > > ACPI: Core Subsystem version [20011018]
> > >
> > > Old ACPI code, get patch from http://sf.net/projects/acpi
> > and report back
> > > if problems persist.
> > Any chance to get patch against latest -rc7 ?
>
> It's big, and deemed too risky. We are shooting for 2.4.22-pre1.

Just had a few thoughts about that and I want to have a fast 2.4.22
release (maximum two months). 2.4.21's development time was unnaceptable.

Lets do the ACPI merge in 2.4.23.

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Margit Schubert-While]

         No, I need ACPI to soft boot.
         This  MUST be in the next release.

         Margit

RE: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Grover, Andrew]

> From: Marcelo Tosatti [mailto:marcelo@conectiva.com.br] 
> > > Any chance to get patch against latest -rc7 ?
> >
> > It's big, and deemed too risky. We are shooting for 2.4.22-pre1.
> 
> Just had a few thoughts about that and I want to have a fast 2.4.22
> release (maximum two months). 2.4.21's development time was 
> unnaceptable.
> 
> Lets do the ACPI merge in 2.4.23.

I wouldn't have a problem with this, except that you've been deferring
the ACPI merge for over a year. We've been maintaining this patch
outside the mainline tree for EIGHTEEN MONTHS. Please stop leading me
along. Will you EVER merge it?

I am confident it will merge cleanly.
I am confident it will cause no problems when CONFIG_ACPI=off.
I am confident the total number of working machines will go up.
I am willing to bet $500 of MY OWN MONEY on this.

Talk to me, man. What would make you happy? A lot is riding on this.

Regards -- Andy

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Grzegorz Jaskiewicz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 09 of June 2003 22:21, you wrote:
> > From: Marcelo Tosatti [mailto:marcelo@conectiva.com.br]
> >
> > > > Any chance to get patch against latest -rc7 ?
> > >
> > > It's big, and deemed too risky. We are shooting for 2.4.22-pre1.
> >
> > Just had a few thoughts about that and I want to have a fast 2.4.22
> > release (maximum two months). 2.4.21's development time was
> > unnaceptable.
In this world there should be no rush :-)

> > Lets do the ACPI merge in 2.4.23.
>
> I wouldn't have a problem with this, except that you've been deferring
> the ACPI merge for over a year. We've been maintaining this patch
> outside the mainline tree for EIGHTEEN MONTHS. Please stop leading me
> along. Will you EVER merge it?
>
> I am confident it will merge cleanly.
> I am confident it will cause no problems when CONFIG_ACPI=off.
> I am confident the total number of working machines will go up.
> I am willing to bet $500 of MY OWN MONEY on this.

Well, Marcelo - i am happy with new ACPI, Alan does (otherwise it wouldn't be 
included into ac tree). We will welcome it in 2.4.22-pre1 :]

Anyway, still ACPI does not work fully in my PCG-C1VE Sony Vaio. I don't know 
if due to incompatibilities of this equipment ?
All other servers/desktops works perfectly fine for me :D

Thanks guys. 
- --
Grzegorz Jaskiewicz
K4 Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+5PsLqu082fCQYIgRAuaFAJ0RxLG8gj2/Lk2B+bxS7bxwcve4zgCghgzO
d7hfwJa81RyJ+ltxmBd+KIs=
=JkND
-----END PGP SIGNATURE-----

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Margit Schubert-While]

         Yes , and not onöy ACPI, put Justin's SCSI in as well !

         Margit

RE: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Marcelo Tosatti]

On Mon, 9 Jun 2003, Grover, Andrew wrote:

> > From: Marcelo Tosatti [mailto:marcelo@conectiva.com.br]
> > > > Any chance to get patch against latest -rc7 ?
> > >
> > > It's big, and deemed too risky. We are shooting for 2.4.22-pre1.
> >
> > Just had a few thoughts about that and I want to have a fast 2.4.22
> > release (maximum two months). 2.4.21's development time was
> > unnaceptable.
> >
> > Lets do the ACPI merge in 2.4.23.
>
> I wouldn't have a problem with this, except that you've been deferring
> the ACPI merge for over a year. We've been maintaining this patch
> outside the mainline tree for EIGHTEEN MONTHS.

The main reason I didnt want to merge it was due to its size. Its just too
big.

> Please stop leading me along. Will you EVER merge it?

Yes, I want to, and will merge it. In 2.4.23-pre.

> I am confident it will merge cleanly.
> I am confident it will cause no problems when CONFIG_ACPI=off.
> I am confident the total number of working machines will go up.
> I am willing to bet $500 of MY OWN MONEY on this.
>
> Talk to me, man. What would make you happy? A lot is riding on this.

Yes, we're fine. 2.4.23-pre.

2.4.22 will be a fast enough release to not piss you off on this, trust
me.

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Margit Schubert-While]

 >Yes, we're fine.
 >2.4.23-pre. 2.4.22 will be a fast enough release to not piss you off on 
this, trust me.

         -march=pentium(x) ?

         Radeon 9K ?

RE: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Grover, Andrew]

> From: Marcelo Tosatti [mailto:marcelo@conectiva.com.br] 
> The main reason I didnt want to merge it was due to its size. 
> Its just too
> big.

Maybe it's just because I am so familiar with it, but while its size is
big, I don't view it as terribly big conceptually. The patch is big
because diff doesn't handle file renames well. Plus, the great majority
of changes are in drivers/acpi. I would think you could basically ignore
all that code, and focus your review on the other bits. I'd be happy to
split that out into a much smaller, easier-to-review patch if that would
help.

> 2.4.22 will be a fast enough release to not piss you off on 
> this, trust
> me.

I'm looking forward to its swift arrival.

Regards -- Andy

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Marcelo Tosatti]

On Tue, 10 Jun 2003, Margit Schubert-While wrote:

>  >Yes, we're fine.
>  >2.4.23-pre. 2.4.22 will be a fast enough release to not piss you off on
> this, trust me.
>
>          -march=pentium(x) ?
>
>          Radeon 9K ?

Huh ?

RE: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Alan Cox]

On Llu, 2003-06-09 at 23:03, Marcelo Tosatti wrote:
> Yes, I want to, and will merge it. In 2.4.23-pre.
> 
> > I am confident it will merge cleanly.
> > I am confident it will cause no problems when CONFIG_ACPI=off.
> > I am confident the total number of working machines will go up.
> > I am willing to bet $500 of MY OWN MONEY on this.
> >
> > Talk to me, man. What would make you happy? A lot is riding on this.
> 
> Yes, we're fine. 2.4.23-pre.
> 
> 2.4.22 will be a fast enough release to not piss you off on this, trust
> me.

Its been in 2.4.21-ac for a while. I have exactly zero reports of it
causing problems in the acpi=n case, and a whole raft of "the first
Linux that runs on my toshiba/compaq/hp laptop"

Works well enough for me to have faith in it now. 

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Alan Cox]

On Llu, 2003-06-09 at 21:32, Marcelo Tosatti wrote:
> Just had a few thoughts about that and I want to have a fast 2.4.22
> release (maximum two months). 2.4.21's development time was unnaceptable.
> 
> Lets do the ACPI merge in 2.4.23.

Seems to me the two critical patches for the next 2.4.2x are acpi and the aic7*
stuff, both of which will need a little time but not a lot to bed in

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Torben Mathiasen]

On Tue, Jun 10 2003, Alan Cox wrote:
> On Llu, 2003-06-09 at 23:03, Marcelo Tosatti wrote:
> > Yes, I want to, and will merge it. In 2.4.23-pre.
> > 
> > > I am confident it will merge cleanly.
> > > I am confident it will cause no problems when CONFIG_ACPI=off.
> > > I am confident the total number of working machines will go up.
> > > I am willing to bet $500 of MY OWN MONEY on this.
> > >
> > > Talk to me, man. What would make you happy? A lot is riding on this.
> > 
> > Yes, we're fine. 2.4.23-pre.
> > 
> > 2.4.22 will be a fast enough release to not piss you off on this, trust
> > me.
> 
> Its been in 2.4.21-ac for a while. I have exactly zero reports of it
> causing problems in the acpi=n case, and a whole raft of "the first
> Linux that runs on my toshiba/compaq/hp laptop"
> 
> Works well enough for me to have faith in it now. 

We need it as well to have proper ACPI support on the Hp/cpq laptops. Without
it one may get serious overheating problems. 

We've been waiting for it for a long time now.

Thanks.

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Stephan von Krawczynski]

On 10 Jun 2003 01:44:59 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Llu, 2003-06-09 at 23:03, Marcelo Tosatti wrote:
> > Yes, I want to, and will merge it. In 2.4.23-pre.
> > 
> > > I am confident it will merge cleanly.
> > > I am confident it will cause no problems when CONFIG_ACPI=off.
> > > I am confident the total number of working machines will go up.
> > > I am willing to bet $500 of MY OWN MONEY on this.
> > >
> > > Talk to me, man. What would make you happy? A lot is riding on this.
> > 
> > Yes, we're fine. 2.4.23-pre.
> > 
> > 2.4.22 will be a fast enough release to not piss you off on this, trust
> > me.
> 
> Its been in 2.4.21-ac for a while. I have exactly zero reports of it
> causing problems in the acpi=n case, and a whole raft of "the first
> Linux that runs on my toshiba/compaq/hp laptop"
> 
> Works well enough for me to have faith in it now. 

I can back that. In fact I have some SIS-based motherboards that do not run
without the acpi patch.

My personal opinion on the topic "what to put in 2.4.22-pre1?" is:
1) aic (because you can kick Justins' a** if it does not work out, and get rid
of any complaints for what you do yourself to the aic code)
2) acpi (because the code has already gone through some significant testing and
looks promising).

So I guess I would just do the opposite of your current statement. Remember, you
have a chance to win 500 bucks, don't let it go ;-)

Regards,
Stephan

RE: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Eric Valette]

Marcelo Tosati wrote:

 >The main reason I didnt want to merge it was due to its size. Its just 
 >too big.

 >> Please stop leading me along. Will you EVER merge it?

 >Yes, I want to, and will merge it. In 2.4.23-pre.

This kind of mails and sentence makes you lost your credibility :
	1) You said that ACPI will be merged in 2.4.22-pre,
	2) For many people ACPI (and aic7xxx) is top priority for 2.4 kernel 
(see various post including alan). The reason being that most laptop are 
unusable nowadays without ACPI,
	3) You do not explicitely says what you plan for 2.4.22...

So, for stupid people like me, could you take a little time to explains 
the dummy's what are your views about what is top priority for kernel 
and for what reasons?

I would personnally suggest that you classify the things using the 
following filter :
	a) Server (SMP, SCSI, RAID, journaling filesystems, ...),
	b) laptop (ACPI, CPUFREQ, Software suspend, IDE power save,...),
	c) desktop (File system efficiency, new hardware support,...),
	d) all systems

Or maybe you simply think that software engineering is a kind of black 
art that is too hard to understand for average people...


-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Adrian Bunk]

On Wed, Jun 11, 2003 at 01:40:54AM +0200, Eric Valette wrote:
>...
> I would personnally suggest that you classify the things using the 
> following filter :
> 	a) Server (SMP, SCSI, RAID, journaling filesystems, ...),
> 	b) laptop (ACPI, CPUFREQ, Software suspend, IDE power save,...),
> 	c) desktop (File system efficiency, new hardware support,...),
> 	d) all systems
>...

Why are journaling filesystems only for servers?
Is file system efficiency not relevant on servers?

The important sections are more likely (ordered by priority):
- bug fixes (e.g. aic7xxx)
- support for additional hardware (e.g. ACPI update)
- new features (e.g. XFS)

These groups are not mutual exclusive, e.g. the ACPI update also 
includes new features.

The important thing is that this is inside a stable kernel series and an 
update that makes things better for 100 people but makes things worse 
for one person is IMHO bad since it's a regression for one person.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Eric Valette]

Adrian Bunk wrote:
> On Wed, Jun 11, 2003 at 01:40:54AM +0200, Eric Valette wrote:
> 
>>...
>>I would personnally suggest that you classify the things using the 
>>following filter :
>>	a) Server (SMP, SCSI, RAID, journaling filesystems, ...),
>>	b) laptop (ACPI, CPUFREQ, Software suspend, IDE power save,...),
>>	c) desktop (File system efficiency, new hardware support,...),
>>	d) all systems
>>...
> 
> 
> Why are journaling filesystems only for servers?
> Is file system efficiency not relevant on servers?

I was just making suggestions after a 30s thinking. Side comments, 
readding this mailling list, I had the impression that journaling and 
filesystem performance do not seem to mix well. Also on server, you have 
probably extra backup hardware and means (e.g RAID, DAT, DLT, ...)



> The important sections are more likely (ordered by priority):
> - bug fixes (e.g. aic7xxx)
> - support for additional hardware (e.g. ACPI update)
> - new features (e.g. XFS)

Personnaly, I dislike this approach as it as resulted in 2.4 being non 
usable for servers (SMP deadlocks, IO stalls, unresponsiveness for 
several seconds, ...) and laptop (ACPI)...

> The important thing is that this is inside a stable kernel series and an 
> update that makes things better for 100 people but makes things worse 
> for one person is IMHO bad since it's a regression for one person.

If 2.4 kernel is not usable without patching, It is far worse for me...


-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Stephan von Krawczynski]

On Wed, 11 Jun 2003 23:15:06 +0200
Adrian Bunk <bunk@fs.tum.de> wrote:

> [...]
> The important thing is that this is inside a stable kernel series and an 
> update that makes things better for 100 people but makes things worse 
> for one person is IMHO bad since it's a regression for one person.

You cannot fulfill that in reality. Looking at the broad variety of software
out there you simply cannot know all the implications a simple bug fix may
have. There may well be boxes that rely on a broken code you just fixed. Only
god knows. So you sometimes simply have to do "the right thing"(tm) knowing
there will always be people who shoot you for it.

Regards,
Stephan

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Eric Valette]

Stephan von Krawczynski wrote:
> On Wed, 11 Jun 2003 23:15:06 +0200
> Adrian Bunk <bunk@fs.tum.de> wrote:
> 
> 
>>[...]
>>The important thing is that this is inside a stable kernel series and an 
>>update that makes things better for 100 people but makes things worse 
>>for one person is IMHO bad since it's a regression for one person.
> 
> 
> You cannot fulfill that in reality. Looking at the broad variety of software
> out there you simply cannot know all the implications a simple bug fix may
> have. There may well be boxes that rely on a broken code you just fixed. Only
> god knows. So you sometimes simply have to do "the right thing"(tm) knowing
> there will always be people who shoot you for it.


Just to go a little bit more in that direction, I already have seen an 
obvious one-line patch that caused a deadlock in another OS because due 
to code location change and probably an additionnal cache miss on 
specific part of the code, an existing synchronisation bug that was 
never triggered started to effectively happen...

Besides, if you please 1000 users and cause problem to 2 of them because 
they have broken hardware, I think you are going into the right direction.

 >The important sections are more likely (ordered by priority):
 > - bug fixes (e.g. aic7xxx)
 > - support for additional hardware (e.g. ACPI update)
 > - new features (e.g. XFS)


Bug fixes are meant to make the 2.4 kernel more useable right? So I do 
not reallly see the utimate difference with other things in your 
category. What I was asking is a rationnal way of chosing the 
priorities. You gave me yours without real explanation.

The purpose of the original mail was to ask for discussion/clarification 
on 2.4 development priorities (e.g something like the 2.6 todo list) and 
a proposal to set up the priorities using generic targetted hardware 
(server, laptop, desktop) as hint for requirement selection.

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

RE: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Marcelo Tosatti]

On Wed, 11 Jun 2003, Eric Valette wrote:

> Marcelo Tosati wrote:
>
>  >The main reason I didnt want to merge it was due to its size. Its just
>  >too big.
>
>  >> Please stop leading me along. Will you EVER merge it?
>
>  >Yes, I want to, and will merge it. In 2.4.23-pre.
>
> This kind of mails and sentence makes you lost your credibility :
> 	1) You said that ACPI will be merged in 2.4.22-pre,
> 	2) For many people ACPI (and aic7xxx) is top priority for 2.4 kernel
> (see various post including alan). The reason being that most laptop are
> unusable nowadays without ACPI,
> 	3) You do not explicitely says what you plan for 2.4.22...

My plan for 2.4.22 is:

 - Include the new aic7xxx driver.
 - Include ACPI. (I now realized its importance). Already discussing with
   Andrew the best way to do it.
 - Fix the latency/interactivity problems (Chris, Nick and Andrea working
on that)
 - Merge obviously correct -aa VM patches.

Those are the most important things that are needed now, I think.

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[J.A. Magallon]

On 06.18, Marcelo Tosatti wrote:
> 
> 
> On Wed, 11 Jun 2003, Eric Valette wrote:
> 
> > Marcelo Tosati wrote:
> >
> >  >The main reason I didnt want to merge it was due to its size. Its just
> >  >too big.
> >
> >  >> Please stop leading me along. Will you EVER merge it?
> >
> >  >Yes, I want to, and will merge it. In 2.4.23-pre.
> >
> > This kind of mails and sentence makes you lost your credibility :
> > 	1) You said that ACPI will be merged in 2.4.22-pre,
> > 	2) For many people ACPI (and aic7xxx) is top priority for 2.4 kernel
> > (see various post including alan). The reason being that most laptop are
> > unusable nowadays without ACPI,
> > 	3) You do not explicitely says what you plan for 2.4.22...
> 
> My plan for 2.4.22 is:
> 
>  - Include the new aic7xxx driver.
>  - Include ACPI. (I now realized its importance). Already discussing with
>    Andrew the best way to do it.
>  - Fix the latency/interactivity problems (Chris, Nick and Andrea working
> on that)
>  - Merge obviously correct -aa VM patches.
> 
> Those are the most important things that are needed now, I think.
> 

Would you accept small canges like -march (gcc_check) for x86 ?

-- 
J.A. Magallon <jamagallon@able.es>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.2 (Cooker) for i586
Linux 2.4.21-jam1 (gcc 3.3 (Mandrake Linux 9.2 3.3-1mdk))

RE: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Anders Karlsson]

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

On Wed, 2003-06-18 at 00:25, Marcelo Tosatti wrote:
> My plan for 2.4.22 is:
> 
>  - Include the new aic7xxx driver.
>  - Include ACPI. (I now realized its importance). Already discussing with
>    Andrew the best way to do it.
>  - Fix the latency/interactivity problems (Chris, Nick and Andrea working
> on that)
>  - Merge obviously correct -aa VM patches.
> 
> Those are the most important things that are needed now, I think.

How about the backported cpufreq patch from Bill Nottingham? Can that
one go in as well please? It is not a big patch as such and it is
working as far as I can tell. I have been running it since it was posted
on the list last week.

Regards,

-- 
Anders Karlsson <anders@trudheim.com>
Trudheim Technology Limited

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Eric Valette]

Marcelo Tosatti wrote:

> My plan for 2.4.22 is:
> 
>  - Include the new aic7xxx driver.
>  - Include ACPI. (I now realized its importance). Already discussing with
>    Andrew the best way to do it.
>  - Fix the latency/interactivity problems (Chris, Nick and Andrea working
> on that)
>  - Merge obviously correct -aa VM patches.
> 
> Those are the most important things that are needed now, I think.

I think many people on this list will be delighted to read this. I'm 
looking for the 22-pre to help testing them (UP)... As alan said, 
increasing the user test base may cause to find some remaining bugs but 
as many people are already forced to patch their 2.4 kernel with aic7xxx 
and ACPI just to make it useable most severe/obvious bugs have probably 
already been found...

I think SMP server users will also be happy with the rest of proposed fixes.

Side comments just to try to make 2.4 even better : I think polling the 
list to see the most annoying problems or most requested feature people 
have/want is sometime a good idea. Of course you will always get mail 
from people that what a patch to have support for their baroque hardware 
but I think you may reach a consensus rapidly as in the previous (rude) 
mail exchanges.

Hope you will manage to spend the needed time to make this in a timely 
fashion.

-- 
    __
   /  `                   	Eric Valette
  /--   __  o _.          	6 rue Paul Le Flem
(___, / (_(_(__         	35740 Pace

Tel: +33 (0)2 99 85 26 76	Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Bill Nottingham]

Anders Karlsson (anders@trudheim.com) said: 
> How about the backported cpufreq patch from Bill Nottingham? Can that
> one go in as well please? It is not a big patch as such and it is
> working as far as I can tell. I have been running it since it was posted
> on the list last week.

It requires the more substantial generic cpufreq backport first. :)

Bill

Re: 2.4.22 timeline was RE: 2.4.21-rc7 ACPI broken

[Marcelo Tosatti]

On Wed, 18 Jun 2003, J.A. Magallon wrote:

>
> On 06.18, Marcelo Tosatti wrote:
> >
> >
> > On Wed, 11 Jun 2003, Eric Valette wrote:
> >
> > > Marcelo Tosati wrote:
> > >
> > >  >The main reason I didnt want to merge it was due to its size. Its just
> > >  >too big.
> > >
> > >  >> Please stop leading me along. Will you EVER merge it?
> > >
> > >  >Yes, I want to, and will merge it. In 2.4.23-pre.
> > >
> > > This kind of mails and sentence makes you lost your credibility :
> > > 	1) You said that ACPI will be merged in 2.4.22-pre,
> > > 	2) For many people ACPI (and aic7xxx) is top priority for 2.4 kernel
> > > (see various post including alan). The reason being that most laptop are
> > > unusable nowadays without ACPI,
> > > 	3) You do not explicitely says what you plan for 2.4.22...
> >
> > My plan for 2.4.22 is:
> >
> >  - Include the new aic7xxx driver.
> >  - Include ACPI. (I now realized its importance). Already discussing with
> >    Andrew the best way to do it.
> >  - Fix the latency/interactivity problems (Chris, Nick and Andrea working
> > on that)
> >  - Merge obviously correct -aa VM patches.
> >
> > Those are the most important things that are needed now, I think.
> >
>
> Would you accept small canges like -march (gcc_check) for x86 ?

I'm not aware of this patch. I might well accecpt it.

Please submit it with a good explanation and I will consider it.