Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Oleg Verych 
On Sun, Jun 17, 2007 at 10:44:39AM -0700, [EMAIL PROTECTED] wrote:
> On Sun, 17 Jun 2007, Oleg Verych wrote:
[]
> >That's wrong if developers are tending to reply only one thing --
> >git-bisect.
> >
> >If things are going to be that bad, then better to start dealing with the
> >cause, not consequences. In this situation requesting test-cases is a
> >better way, as it's going to influence developer as cause of potential
> >problems. If tests will show *hardware* side of problem, then, well some
> >parts may be not obvious, thus bisecting is a way to continue.
> 
> most people who report bugs don't know enough about what's actually going 
> wrong to be able to write a test case (those that do can probably just 
> write a patch to fix it). Along similar lines a debugger wouldn't be of 
> much use either.

Sorry for my English. Requesting test cases from the developers of
course. Or at least results of some kind of testing, so people may run
and check them as well, if something is suspected. And this from my POV
leads again to organized way of filtering noise and collecting structured
information easily (yea, i think it's BTS with reportbug in Debian).{0}

> the fact that git-bisect doesn't require any knowledge other then 
> knowledge the reporter has demonstrated that they already have (the 
> ability to compile and install their own kernel) puts it within the reach 
> of testers.
> 
> unfortunantly, as good as it is it can take a lot of effort, especially if 
> the bug takes time to show up. it's not perfect, but it's a huge help.

I think, positive feedback from {0} to the LTP may improve that.
Especially, if things are in parts and easy to choose for testing.

> and developers aren't always responding with 'do a bisect', sometimes they 
> respond with 'yes, we know about that'

> or 'that sounds like X',

That two are _exactly_ what reportbug tool is doing. That's why i'm
talking about it. And i'm *no* wonder why developers are boring -- at
some points they might not handle the *noise*.

> so it's still worthwhile for people to report the problem first before
> going to the ffort of doing a bisect.
> 
> David Lang
__

Bits for Adrian.

*ML*

I *use* Gmane. I'm not subscribed (receiving e-mail to my mbox) to any ML,
except <[EMAIL PROTECTED]>.

Nearly every my e-mail here is with Gmane links. You seem ignored all of
them. As for me it's result of *your personal*, rather than technical
activity.

*offense*

I'm not talking about personal offense, you are seem thinking about, but
technical one. I.e. when possible benefit might be even more, than NOHZ
on x86 and a like[0], with much less effort. I still think, unless i will
develop or fail, that reducing traffic on one or two order of magnitude
is possible as well as improving kbuild/kconfig to reduce of the noise of
mis-configurations/tester's .config length. Discouraging that effort is
my source of offense.

(FYI Until Linus checked in my _RFT_ kbuild patches, i realized how
*many* people are willing to understand and try to test kbuild stuff.)

[0] I bet VGA, DRAM, HDD are far more power hungry room-heaters. Unless
you can substantially lower frequency, you might have no benefit at
all. Whana know how it's done in perfectly designed embedded
MCU/CPU? Please, see for instance MSP430 from TI (i know, it uses
SRAM, but i've asked to look on processor core design).

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread david 

On Sun, 17 Jun 2007, Oleg Verych wrote:


On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:

On 17/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski
<[EMAIL PROTECTED]> wrote:


+If the patch introduces a new regression and this regression was not

fixed

+in seven days, then the patch will be reverted.


Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think.  How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?



Here lays the problem.

git-bisect is a killer app, people should start using it.


It's OK _only_ in case of unknown, hard to find *hardware* bugs.

If you think it's "a good thing" for bad, untested by developer
code, then something is completely wrong.

And if there's no debugger in the mainline kernel, which is developer's
tool, then why do you think testers must stick with git-bisect, as their
debugger-like tool (bandwidth in most and time consuming in some cases)?

That's wrong if developers are tending to reply only one thing --
git-bisect.

If things are going to be that bad, then better to start dealing with the
cause, not consequences. In this situation requesting test-cases is a
better way, as it's going to influence developer as cause of potential
problems. If tests will show *hardware* side of problem, then, well some
parts may be not obvious, thus bisecting is a way to continue.


most people who report bugs don't know enough about what's actually going 
wrong to be able to write a test case (those that do can probably just 
write a patch to fix it). Along similar lines a debugger wouldn't be of 
much use either.


the fact that git-bisect doesn't require any knowledge other then 
knowledge the reporter has demonstrated that they already have (the 
ability to compile and install their own kernel) puts it within the reach 
of testers.


unfortunantly, as good as it is it can take a lot of effort, especially if 
the bug takes time to show up. it's not perfect, but it's a huge help.


and developers aren't always responding with 'do a bisect', sometimes they 
respond with 'yes, we know about that' or 'that sounds like X', so it's 
still worthwhile for people to report the problem first before going to 
the ffort of doing a bisect.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Adrian Bunk 
On Sun, Jun 17, 2007 at 04:24:30PM +0200, Oleg Verych wrote:
> On Sun, Jun 17, 2007 at 02:13:39PM +0200, Rafael J. Wysocki wrote:
> > On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
> []
> > > It's OK _only_ in case of unknown, hard to find *hardware* bugs.
> > > 
> > > If you think it's "a good thing" for bad, untested by developer
> > > code, then something is completely wrong.
> > 
> > Oh, I've just fixed two purely software bugs pointed out by binary searching
> > in the code that I'm sure has been tested, not only by its developers, but 
> > the
> > bugs only showed up in my configuration (on one out of four test boxes).
> > 
> > There are so many different kernel configurations possible that there's no 
> > way
> > a developer can test them all.
> 
> With current state of affairs it's not only hard for developers, but
> and for users: <[EMAIL PROTECTED]>,
>   <[EMAIL PROTECTED]>

Uwe has an attitude that made many people (including Linus himself) 
set their mail filters to deliver his emails directly to /dev/null.

Parts of the contents of his emails were usable including usable 
regression reports - but the way he treats people simply disqualified 
him.

> I'm trying to re-do some kbuild stuff, but i'm getting rather offensive
> answers :( <[EMAIL PROTECTED]>
>...

I'm not seeing anything in Thomas' email that could be considered 
offensive. He told you in a technical way why he disagrees with you.

If you call this email "rather offensive", you should _really_ 
unsubscribe from lkml (or even any Debian mailing lists). And this is 
not meant against you, it's simply that for the standards of lkml there 
is nothing offensive in this email.

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

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Oleg Verych 
On Sun, Jun 17, 2007 at 02:13:39PM +0200, Rafael J. Wysocki wrote:
> On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
[]
> > It's OK _only_ in case of unknown, hard to find *hardware* bugs.
> > 
> > If you think it's "a good thing" for bad, untested by developer
> > code, then something is completely wrong.
> 
> Oh, I've just fixed two purely software bugs pointed out by binary searching
> in the code that I'm sure has been tested, not only by its developers, but the
> bugs only showed up in my configuration (on one out of four test boxes).
> 
> There are so many different kernel configurations possible that there's no way
> a developer can test them all.

With current state of affairs it's not only hard for developers, but
and for users: <[EMAIL PROTECTED]>,
  <[EMAIL PROTECTED]>

I'm trying to re-do some kbuild stuff, but i'm getting rather offensive
answers :( <[EMAIL PROTECTED]>

(Even if i'm academic with free Internet, i doubt i even tried to
think to improve something, if i didn't have one, because i wouldn't knew
huge lkml traffic, problems, etc.)

Maybe i'm wrong. But reducing amount of traffic/files and ease of
(re-)configuration are not last things to be done for better testing.
All for speed of getting and compiling kernel. Latter for avoiding
bugs and noise due to inconsistent build configuration.

Finally again, bug-reporting and tracking tools, i've tried to discuss
are major problems out there I think it's plain easy and deal with. One
more example:

<[EMAIL PROTECTED]>
Xref: news.gmane.org gmane.linux.debian.devel.kernel:28095


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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Stefan Richter 
Michal Piotrowski wrote:
> "choose minor evil to prevent a greater one"

The measurement of "evil" is subjective.  That's why there are releases
with known regressions.
-- 
Stefan Richter
-=-=-=== -==- =---=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Michal Piotrowski 

On 17/06/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:

On Sun, Jun 17, 2007 at 11:41:36AM +0200, Michal Piotrowski wrote:
> Hi all,
>
> Adrian Bunk pisze:
>> On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:
>>> ...
>>> [Adrian, I'm not saying "too few users run -rc kernels", I'm saying "too
>>> few FireWire driver users run -rc kernels".]
>> Getting more people testing -rc kernels might be possible, and I don't
>> think it would be too hard. And not only FireWire would benefit from this,
>> remember e.g. that at least 2 out of the last 5 kernels Linus released
>> contained filesystem corruption regressions.
>> The problem is that we aren't able to handle the many regression reports
>> we get today, so asking for more testing and regression reports today
>> would attack it at the wrong part of the chain.
>> Additionally, every reported and unhandled regression will frustrate the
>> reporter - never forget that we have _many_ unhandled bug reports
>> (including but not limited to regression reports) where the submitter
>> spent much time and energy in writing a good bug report.
>> If we somehow gain the missing manpower for debugging regressions we can
>> actively ask for more testing. Missing manpower (of people knowing some
>> part of the kernel well) for debugging bug reports is IMHO the one big
>> source of quality problems in the Linux kernel. If we get this solved,
>> things like getting more testers for -rc kernels will become low hanging
>> fruits.
>
> Adrian, I agree with _all_ your points.
>
> I bet that developers will hate me for this.
>
> Please consider for 2.6.23

Fine with me, but:

There are not so simple cases like big infrastructure patches with
20 other patches in the tree depending on it causing a regression, or
even worse, a big infrastructure patch exposing a latent old bug in some
completely different area of the kernel.


It is different case.

"If the patch introduces a new regression"

introduces != exposes an old bug

Removal of 20 patches will be painful, but sometimes you need to
"choose minor evil to prevent a greater one" [1].


And we should be aware that reverting is only a workaround for the real
problem which lies in our bug handling.

> Regards,
> Michal
>...

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




Regards,
Michal

[1] the quote from "The Last Wish/Minor Evil" by Andrzej Sapkowski :)

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Adrian Bunk 
On Sun, Jun 17, 2007 at 11:41:36AM +0200, Michal Piotrowski wrote:
> Hi all,
>
> Adrian Bunk pisze:
>> On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:
>>> ...
>>> [Adrian, I'm not saying "too few users run -rc kernels", I'm saying "too
>>> few FireWire driver users run -rc kernels".]
>> Getting more people testing -rc kernels might be possible, and I don't 
>> think it would be too hard. And not only FireWire would benefit from this, 
>> remember e.g. that at least 2 out of the last 5 kernels Linus released 
>> contained filesystem corruption regressions.
>> The problem is that we aren't able to handle the many regression reports 
>> we get today, so asking for more testing and regression reports today 
>> would attack it at the wrong part of the chain.
>> Additionally, every reported and unhandled regression will frustrate the 
>> reporter - never forget that we have _many_ unhandled bug reports 
>> (including but not limited to regression reports) where the submitter 
>> spent much time and energy in writing a good bug report.
>> If we somehow gain the missing manpower for debugging regressions we can 
>> actively ask for more testing. Missing manpower (of people knowing some 
>> part of the kernel well) for debugging bug reports is IMHO the one big 
>> source of quality problems in the Linux kernel. If we get this solved, 
>> things like getting more testers for -rc kernels will become low hanging 
>> fruits.
>
> Adrian, I agree with _all_ your points.
>
> I bet that developers will hate me for this.
>
> Please consider for 2.6.23

Fine with me, but:

There are not so simple cases like big infrastructure patches with
20 other patches in the tree depending on it causing a regression, or 
even worse, a big infrastructure patch exposing a latent old bug in some 
completely different area of the kernel.

And we should be aware that reverting is only a workaround for the real 
problem which lies in our bug handling.

> Regards,
> Michal
>...

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

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Rafael J. Wysocki 
On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
> On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:
> > On 17/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski 
> > ><[EMAIL PROTECTED]> wrote:
> > >
> > >> +If the patch introduces a new regression and this regression was not 
> > >fixed
> > >> +in seven days, then the patch will be reverted.
> > >
> > >Those regressions where we know which patch caused them are the easy ones.
> > >Often we don't know which patch (or even which subsystem merge) is at
> > >fault.
> > >
> > >I think.  How many of the present 2.6.22-rc regressions which you're
> > >presently tracking have such a well-identified cause?
> > >
> > 
> > Here lays the problem.
> > 
> > git-bisect is a killer app, people should start using it.
> 
> It's OK _only_ in case of unknown, hard to find *hardware* bugs.
> 
> If you think it's "a good thing" for bad, untested by developer
> code, then something is completely wrong.

Oh, I've just fixed two purely software bugs pointed out by binary searching
in the code that I'm sure has been tested, not only by its developers, but the
bugs only showed up in my configuration (on one out of four test boxes).

There are so many different kernel configurations possible that there's no way
a developer can test them all.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Rafael J. Wysocki 
On Sunday, 17 June 2007 12:22, Michal Piotrowski wrote:
> On 17/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski <[EMAIL PROTECTED]> 
> > wrote:
> >
> > > +If the patch introduces a new regression and this regression was not 
> > > fixed
> > > +in seven days, then the patch will be reverted.
> >
> > Those regressions where we know which patch caused them are the easy ones.

Except when the bisection points us to a patch exposing a bug that is present
regardless (see http://lkml.org/lkml/2007/6/13/273 for example).

Besides, if a patch is merged before -rc1 as a bugfix, there are several
patches depending on it and only after -rc5 has been released we find out
that it breaks someone's system, then reverting it is not a solution, IMO.

> > Often we don't know which patch (or even which subsystem merge) is at
> > fault.
> >
> > I think.  How many of the present 2.6.22-rc regressions which you're
> > presently tracking have such a well-identified cause?
> >
> 
> Here lays the problem.
> 
> git-bisect is a killer app, people should start using it.

People should test _all_ of the -rc kernels and report problems.  Otherwise, we
may assume that there are no problems and go on.

Greetings,
Rafael


-- 
"Premature optimization is the root of all evil." - Donald Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Oleg Verych 
On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:
> On 17/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski 
> ><[EMAIL PROTECTED]> wrote:
> >
> >> +If the patch introduces a new regression and this regression was not 
> >fixed
> >> +in seven days, then the patch will be reverted.
> >
> >Those regressions where we know which patch caused them are the easy ones.
> >Often we don't know which patch (or even which subsystem merge) is at
> >fault.
> >
> >I think.  How many of the present 2.6.22-rc regressions which you're
> >presently tracking have such a well-identified cause?
> >
> 
> Here lays the problem.
> 
> git-bisect is a killer app, people should start using it.

It's OK _only_ in case of unknown, hard to find *hardware* bugs.

If you think it's "a good thing" for bad, untested by developer
code, then something is completely wrong.

And if there's no debugger in the mainline kernel, which is developer's
tool, then why do you think testers must stick with git-bisect, as their
debugger-like tool (bandwidth in most and time consuming in some cases)?

That's wrong if developers are tending to reply only one thing --
git-bisect.

If things are going to be that bad, then better to start dealing with the
cause, not consequences. In this situation requesting test-cases is a
better way, as it's going to influence developer as cause of potential
problems. If tests will show *hardware* side of problem, then, well some
parts may be not obvious, thus bisecting is a way to continue.

Sorry if i'm from the abnormally different side yet one more time.

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Michal Piotrowski 

On 17/06/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> +If the patch introduces a new regression and this regression was not fixed
> +in seven days, then the patch will be reverted.

Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think.  How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?



Here lays the problem.

git-bisect is a killer app, people should start using it.

Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Andrew Morton 
On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> +If the patch introduces a new regression and this regression was not fixed
> +in seven days, then the patch will be reverted.

Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think.  How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Michal Piotrowski 

Hi all,

Adrian Bunk pisze:

On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:

...
[Adrian, I'm not saying "too few users run -rc kernels", I'm saying "too
few FireWire driver users run -rc kernels".]


Getting more people testing -rc kernels might be possible, and I don't 
think it would be too hard. And not only FireWire would benefit from 
this, remember e.g. that at least 2 out of the last 5 kernels Linus 
released contained filesystem corruption regressions.


The problem is that we aren't able to handle the many regression reports 
we get today, so asking for more testing and regression reports today 
would attack it at the wrong part of the chain.


Additionally, every reported and unhandled regression will frustrate the 
reporter - never forget that we have _many_ unhandled bug reports 
(including but not limited to regression reports) where the submitter 
spent much time and energy in writing a good bug report.


If we somehow gain the missing manpower for debugging regressions we can 
actively ask for more testing. Missing manpower (of people knowing some 
part of the kernel well) for debugging bug reports is IMHO the one big 
source of quality problems in the Linux kernel. If we get this solved, 
things like getting more testers for -rc kernels will become low hanging 
fruits.


Adrian, I agree with _all_ your points.

I bet that developers will hate me for this.

Please consider for 2.6.23

Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/

Signed-off-by: Michal Piotrowski <[EMAIL PROTECTED]>

--- linux-work-clean/Documentation/SubmitChecklist  2007-06-17 
11:18:37.0 +0200
+++ linux-work/Documentation/SubmitChecklist2007-06-17 11:29:26.0 
+0200
@@ -90,3 +90,8 @@ kernel patches.
patch style checker prior to submission (scripts/checkpatch.pl).
You should be able to justify all violations that remain in
your patch.
+
+
+
+If the patch introduces a new regression and this regression was not fixed
+in seven days, then the patch will be reverted.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Michal Piotrowski 

Hi all,

Adrian Bunk pisze:

On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:

...
[Adrian, I'm not saying too few users run -rc kernels, I'm saying too
few FireWire driver users run -rc kernels.]


Getting more people testing -rc kernels might be possible, and I don't 
think it would be too hard. And not only FireWire would benefit from 
this, remember e.g. that at least 2 out of the last 5 kernels Linus 
released contained filesystem corruption regressions.


The problem is that we aren't able to handle the many regression reports 
we get today, so asking for more testing and regression reports today 
would attack it at the wrong part of the chain.


Additionally, every reported and unhandled regression will frustrate the 
reporter - never forget that we have _many_ unhandled bug reports 
(including but not limited to regression reports) where the submitter 
spent much time and energy in writing a good bug report.


If we somehow gain the missing manpower for debugging regressions we can 
actively ask for more testing. Missing manpower (of people knowing some 
part of the kernel well) for debugging bug reports is IMHO the one big 
source of quality problems in the Linux kernel. If we get this solved, 
things like getting more testers for -rc kernels will become low hanging 
fruits.


Adrian, I agree with _all_ your points.

I bet that developers will hate me for this.

Please consider for 2.6.23

Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/

Signed-off-by: Michal Piotrowski [EMAIL PROTECTED]

--- linux-work-clean/Documentation/SubmitChecklist  2007-06-17 
11:18:37.0 +0200
+++ linux-work/Documentation/SubmitChecklist2007-06-17 11:29:26.0 
+0200
@@ -90,3 +90,8 @@ kernel patches.
patch style checker prior to submission (scripts/checkpatch.pl).
You should be able to justify all violations that remain in
your patch.
+
+
+
+If the patch introduces a new regression and this regression was not fixed
+in seven days, then the patch will be reverted.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Andrew Morton 
On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski [EMAIL PROTECTED] wrote:

 +If the patch introduces a new regression and this regression was not fixed
 +in seven days, then the patch will be reverted.

Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think.  How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Michal Piotrowski 

On 17/06/07, Andrew Morton [EMAIL PROTECTED] wrote:

On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski [EMAIL PROTECTED] wrote:

 +If the patch introduces a new regression and this regression was not fixed
 +in seven days, then the patch will be reverted.

Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think.  How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?



Here lays the problem.

git-bisect is a killer app, people should start using it.

Regards,
Michal

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Oleg Verych 
On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:
 On 17/06/07, Andrew Morton [EMAIL PROTECTED] wrote:
 On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski 
 [EMAIL PROTECTED] wrote:
 
  +If the patch introduces a new regression and this regression was not 
 fixed
  +in seven days, then the patch will be reverted.
 
 Those regressions where we know which patch caused them are the easy ones.
 Often we don't know which patch (or even which subsystem merge) is at
 fault.
 
 I think.  How many of the present 2.6.22-rc regressions which you're
 presently tracking have such a well-identified cause?
 
 
 Here lays the problem.
 
 git-bisect is a killer app, people should start using it.

It's OK _only_ in case of unknown, hard to find *hardware* bugs.

If you think it's a good thing for bad, untested by developer
code, then something is completely wrong.

And if there's no debugger in the mainline kernel, which is developer's
tool, then why do you think testers must stick with git-bisect, as their
debugger-like tool (bandwidth in most and time consuming in some cases)?

That's wrong if developers are tending to reply only one thing --
git-bisect.

If things are going to be that bad, then better to start dealing with the
cause, not consequences. In this situation requesting test-cases is a
better way, as it's going to influence developer as cause of potential
problems. If tests will show *hardware* side of problem, then, well some
parts may be not obvious, thus bisecting is a way to continue.

Sorry if i'm from the abnormally different side yet one more time.

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Rafael J. Wysocki 
On Sunday, 17 June 2007 12:22, Michal Piotrowski wrote:
 On 17/06/07, Andrew Morton [EMAIL PROTECTED] wrote:
  On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski [EMAIL PROTECTED] 
  wrote:
 
   +If the patch introduces a new regression and this regression was not 
   fixed
   +in seven days, then the patch will be reverted.
 
  Those regressions where we know which patch caused them are the easy ones.

Except when the bisection points us to a patch exposing a bug that is present
regardless (see http://lkml.org/lkml/2007/6/13/273 for example).

Besides, if a patch is merged before -rc1 as a bugfix, there are several
patches depending on it and only after -rc5 has been released we find out
that it breaks someone's system, then reverting it is not a solution, IMO.

  Often we don't know which patch (or even which subsystem merge) is at
  fault.
 
  I think.  How many of the present 2.6.22-rc regressions which you're
  presently tracking have such a well-identified cause?
 
 
 Here lays the problem.
 
 git-bisect is a killer app, people should start using it.

People should test _all_ of the -rc kernels and report problems.  Otherwise, we
may assume that there are no problems and go on.

Greetings,
Rafael


-- 
Premature optimization is the root of all evil. - Donald Knuth
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Rafael J. Wysocki 
On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
 On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:
  On 17/06/07, Andrew Morton [EMAIL PROTECTED] wrote:
  On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski 
  [EMAIL PROTECTED] wrote:
  
   +If the patch introduces a new regression and this regression was not 
  fixed
   +in seven days, then the patch will be reverted.
  
  Those regressions where we know which patch caused them are the easy ones.
  Often we don't know which patch (or even which subsystem merge) is at
  fault.
  
  I think.  How many of the present 2.6.22-rc regressions which you're
  presently tracking have such a well-identified cause?
  
  
  Here lays the problem.
  
  git-bisect is a killer app, people should start using it.
 
 It's OK _only_ in case of unknown, hard to find *hardware* bugs.
 
 If you think it's a good thing for bad, untested by developer
 code, then something is completely wrong.

Oh, I've just fixed two purely software bugs pointed out by binary searching
in the code that I'm sure has been tested, not only by its developers, but the
bugs only showed up in my configuration (on one out of four test boxes).

There are so many different kernel configurations possible that there's no way
a developer can test them all.

Greetings,
Rafael


-- 
Premature optimization is the root of all evil. - Donald Knuth
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Adrian Bunk 
On Sun, Jun 17, 2007 at 11:41:36AM +0200, Michal Piotrowski wrote:
 Hi all,

 Adrian Bunk pisze:
 On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:
 ...
 [Adrian, I'm not saying too few users run -rc kernels, I'm saying too
 few FireWire driver users run -rc kernels.]
 Getting more people testing -rc kernels might be possible, and I don't 
 think it would be too hard. And not only FireWire would benefit from this, 
 remember e.g. that at least 2 out of the last 5 kernels Linus released 
 contained filesystem corruption regressions.
 The problem is that we aren't able to handle the many regression reports 
 we get today, so asking for more testing and regression reports today 
 would attack it at the wrong part of the chain.
 Additionally, every reported and unhandled regression will frustrate the 
 reporter - never forget that we have _many_ unhandled bug reports 
 (including but not limited to regression reports) where the submitter 
 spent much time and energy in writing a good bug report.
 If we somehow gain the missing manpower for debugging regressions we can 
 actively ask for more testing. Missing manpower (of people knowing some 
 part of the kernel well) for debugging bug reports is IMHO the one big 
 source of quality problems in the Linux kernel. If we get this solved, 
 things like getting more testers for -rc kernels will become low hanging 
 fruits.

 Adrian, I agree with _all_ your points.

 I bet that developers will hate me for this.

 Please consider for 2.6.23

Fine with me, but:

There are not so simple cases like big infrastructure patches with
20 other patches in the tree depending on it causing a regression, or 
even worse, a big infrastructure patch exposing a latent old bug in some 
completely different area of the kernel.

And we should be aware that reverting is only a workaround for the real 
problem which lies in our bug handling.

 Regards,
 Michal
...

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

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Michal Piotrowski 

On 17/06/07, Adrian Bunk [EMAIL PROTECTED] wrote:

On Sun, Jun 17, 2007 at 11:41:36AM +0200, Michal Piotrowski wrote:
 Hi all,

 Adrian Bunk pisze:
 On Sat, Jun 16, 2007 at 02:23:25PM +0200, Stefan Richter wrote:
 ...
 [Adrian, I'm not saying too few users run -rc kernels, I'm saying too
 few FireWire driver users run -rc kernels.]
 Getting more people testing -rc kernels might be possible, and I don't
 think it would be too hard. And not only FireWire would benefit from this,
 remember e.g. that at least 2 out of the last 5 kernels Linus released
 contained filesystem corruption regressions.
 The problem is that we aren't able to handle the many regression reports
 we get today, so asking for more testing and regression reports today
 would attack it at the wrong part of the chain.
 Additionally, every reported and unhandled regression will frustrate the
 reporter - never forget that we have _many_ unhandled bug reports
 (including but not limited to regression reports) where the submitter
 spent much time and energy in writing a good bug report.
 If we somehow gain the missing manpower for debugging regressions we can
 actively ask for more testing. Missing manpower (of people knowing some
 part of the kernel well) for debugging bug reports is IMHO the one big
 source of quality problems in the Linux kernel. If we get this solved,
 things like getting more testers for -rc kernels will become low hanging
 fruits.

 Adrian, I agree with _all_ your points.

 I bet that developers will hate me for this.

 Please consider for 2.6.23

Fine with me, but:

There are not so simple cases like big infrastructure patches with
20 other patches in the tree depending on it causing a regression, or
even worse, a big infrastructure patch exposing a latent old bug in some
completely different area of the kernel.


It is different case.

If the patch introduces a new regression

introduces != exposes an old bug

Removal of 20 patches will be painful, but sometimes you need to
choose minor evil to prevent a greater one [1].


And we should be aware that reverting is only a workaround for the real
problem which lies in our bug handling.

 Regards,
 Michal
...

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




Regards,
Michal

[1] the quote from The Last Wish/Minor Evil by Andrzej Sapkowski :)

--
LOG
http://www.stardust.webpages.pl/log/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Stefan Richter 
Michal Piotrowski wrote:
 choose minor evil to prevent a greater one

The measurement of evil is subjective.  That's why there are releases
with known regressions.
-- 
Stefan Richter
-=-=-=== -==- =---=
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Oleg Verych 
On Sun, Jun 17, 2007 at 02:13:39PM +0200, Rafael J. Wysocki wrote:
 On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
[]
  It's OK _only_ in case of unknown, hard to find *hardware* bugs.
  
  If you think it's a good thing for bad, untested by developer
  code, then something is completely wrong.
 
 Oh, I've just fixed two purely software bugs pointed out by binary searching
 in the code that I'm sure has been tested, not only by its developers, but the
 bugs only showed up in my configuration (on one out of four test boxes).
 
 There are so many different kernel configurations possible that there's no way
 a developer can test them all.

With current state of affairs it's not only hard for developers, but
and for users: [EMAIL PROTECTED],
  [EMAIL PROTECTED]

I'm trying to re-do some kbuild stuff, but i'm getting rather offensive
answers :( [EMAIL PROTECTED]

(Even if i'm academic with free Internet, i doubt i even tried to
think to improve something, if i didn't have one, because i wouldn't knew
huge lkml traffic, problems, etc.)

Maybe i'm wrong. But reducing amount of traffic/files and ease of
(re-)configuration are not last things to be done for better testing.
All for speed of getting and compiling kernel. Latter for avoiding
bugs and noise due to inconsistent build configuration.

Finally again, bug-reporting and tracking tools, i've tried to discuss
are major problems out there I think it's plain easy and deal with. One
more example:

[EMAIL PROTECTED]
Xref: news.gmane.org gmane.linux.debian.devel.kernel:28095
http://permalink.gmane.org/gmane.linux.debian.devel.kernel/28095

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Adrian Bunk 
On Sun, Jun 17, 2007 at 04:24:30PM +0200, Oleg Verych wrote:
 On Sun, Jun 17, 2007 at 02:13:39PM +0200, Rafael J. Wysocki wrote:
  On Sunday, 17 June 2007 13:47, Oleg Verych wrote:
 []
   It's OK _only_ in case of unknown, hard to find *hardware* bugs.
   
   If you think it's a good thing for bad, untested by developer
   code, then something is completely wrong.
  
  Oh, I've just fixed two purely software bugs pointed out by binary searching
  in the code that I'm sure has been tested, not only by its developers, but 
  the
  bugs only showed up in my configuration (on one out of four test boxes).
  
  There are so many different kernel configurations possible that there's no 
  way
  a developer can test them all.
 
 With current state of affairs it's not only hard for developers, but
 and for users: [EMAIL PROTECTED],
   [EMAIL PROTECTED]

Uwe has an attitude that made many people (including Linus himself) 
set their mail filters to deliver his emails directly to /dev/null.

Parts of the contents of his emails were usable including usable 
regression reports - but the way he treats people simply disqualified 
him.

 I'm trying to re-do some kbuild stuff, but i'm getting rather offensive
 answers :( [EMAIL PROTECTED]
...

I'm not seeing anything in Thomas' email that could be considered 
offensive. He told you in a technical way why he disagrees with you.

If you call this email rather offensive, you should _really_ 
unsubscribe from lkml (or even any Debian mailing lists). And this is 
not meant against you, it's simply that for the standards of lkml there 
is nothing offensive in this email.

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

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

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread david 

On Sun, 17 Jun 2007, Oleg Verych wrote:


On Sun, Jun 17, 2007 at 12:22:26PM +0200, Michal Piotrowski wrote:

On 17/06/07, Andrew Morton [EMAIL PROTECTED] wrote:

On Sun, 17 Jun 2007 11:41:36 +0200 Michal Piotrowski
[EMAIL PROTECTED] wrote:


+If the patch introduces a new regression and this regression was not

fixed

+in seven days, then the patch will be reverted.


Those regressions where we know which patch caused them are the easy ones.
Often we don't know which patch (or even which subsystem merge) is at
fault.

I think.  How many of the present 2.6.22-rc regressions which you're
presently tracking have such a well-identified cause?



Here lays the problem.

git-bisect is a killer app, people should start using it.


It's OK _only_ in case of unknown, hard to find *hardware* bugs.

If you think it's a good thing for bad, untested by developer
code, then something is completely wrong.

And if there's no debugger in the mainline kernel, which is developer's
tool, then why do you think testers must stick with git-bisect, as their
debugger-like tool (bandwidth in most and time consuming in some cases)?

That's wrong if developers are tending to reply only one thing --
git-bisect.

If things are going to be that bad, then better to start dealing with the
cause, not consequences. In this situation requesting test-cases is a
better way, as it's going to influence developer as cause of potential
problems. If tests will show *hardware* side of problem, then, well some
parts may be not obvious, thus bisecting is a way to continue.


most people who report bugs don't know enough about what's actually going 
wrong to be able to write a test case (those that do can probably just 
write a patch to fix it). Along similar lines a debugger wouldn't be of 
much use either.


the fact that git-bisect doesn't require any knowledge other then 
knowledge the reporter has demonstrated that they already have (the 
ability to compile and install their own kernel) puts it within the reach 
of testers.


unfortunantly, as good as it is it can take a lot of effort, especially if 
the bug takes time to show up. it's not perfect, but it's a huge help.


and developers aren't always responding with 'do a bisect', sometimes they 
respond with 'yes, we know about that' or 'that sounds like X', so it's 
still worthwhile for people to report the problem first before going to 
the ffort of doing a bisect.


David Lang
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))

2007-06-17 Thread Oleg Verych 
On Sun, Jun 17, 2007 at 10:44:39AM -0700, [EMAIL PROTECTED] wrote:
 On Sun, 17 Jun 2007, Oleg Verych wrote:
[]
 That's wrong if developers are tending to reply only one thing --
 git-bisect.
 
 If things are going to be that bad, then better to start dealing with the
 cause, not consequences. In this situation requesting test-cases is a
 better way, as it's going to influence developer as cause of potential
 problems. If tests will show *hardware* side of problem, then, well some
 parts may be not obvious, thus bisecting is a way to continue.
 
 most people who report bugs don't know enough about what's actually going 
 wrong to be able to write a test case (those that do can probably just 
 write a patch to fix it). Along similar lines a debugger wouldn't be of 
 much use either.

Sorry for my English. Requesting test cases from the developers of
course. Or at least results of some kind of testing, so people may run
and check them as well, if something is suspected. And this from my POV
leads again to organized way of filtering noise and collecting structured
information easily (yea, i think it's BTS with reportbug in Debian).{0}

 the fact that git-bisect doesn't require any knowledge other then 
 knowledge the reporter has demonstrated that they already have (the 
 ability to compile and install their own kernel) puts it within the reach 
 of testers.
 
 unfortunantly, as good as it is it can take a lot of effort, especially if 
 the bug takes time to show up. it's not perfect, but it's a huge help.

I think, positive feedback from {0} to the LTP may improve that.
Especially, if things are in parts and easy to choose for testing.

 and developers aren't always responding with 'do a bisect', sometimes they 
 respond with 'yes, we know about that'

 or 'that sounds like X',

That two are _exactly_ what reportbug tool is doing. That's why i'm
talking about it. And i'm *no* wonder why developers are boring -- at
some points they might not handle the *noise*.

 so it's still worthwhile for people to report the problem first before
 going to the ffort of doing a bisect.
 
 David Lang
__

Bits for Adrian.

*ML*

I *use* Gmane. I'm not subscribed (receiving e-mail to my mbox) to any ML,
except [EMAIL PROTECTED].

Nearly every my e-mail here is with Gmane links. You seem ignored all of
them. As for me it's result of *your personal*, rather than technical
activity.

*offense*

I'm not talking about personal offense, you are seem thinking about, but
technical one. I.e. when possible benefit might be even more, than NOHZ
on x86 and a like[0], with much less effort. I still think, unless i will
develop or fail, that reducing traffic on one or two order of magnitude
is possible as well as improving kbuild/kconfig to reduce of the noise of
mis-configurations/tester's .config length. Discouraging that effort is
my source of offense.

(FYI Until Linus checked in my _RFT_ kbuild patches, i realized how
*many* people are willing to understand and try to test kbuild stuff.)

[0] I bet VGA, DRAM, HDD are far more power hungry room-heaters. Unless
you can substantially lower frequency, you might have no benefit at
all. Whana know how it's done in perfectly designed embedded
MCU/CPU? Please, see for instance MSP430 from TI (i know, it uses
SRAM, but i've asked to look on processor core design).

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