date:20070217


On second thought, let's not deconstruct this.  It's too much work,
and it's a waste of time.  Because if you can't read "anything other
people wrote is fair game, but what we write is sacred; our strategy
is to cajole when we can and strong-arm when we can't, and the law be
damned" into that, no amount of verbiage from me is going to change
your mind.


Er, that would be, "cajole when we must and strong-arm whenever we
can".  That didn't stay on the floor long enough to pick up any germs;
doesn't count.  :-)

Cheers,
- Michael
-
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/

[git pull] Input patches for 2.6.20

2007-02-17 Thread Dmitry Torokhov

Hi Linus,

Please consider pulling from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for input subsystem.

Changelog:
--

Cyrill V. Gorcunov (1):
  Input: HIL - fix improper call to release_region()

Dmitry Torokhov (5):
  Input: psmouse - properly reset mouse on shutdown/suspend
  Input: i8042 - let serio bus suspend ports
  Input: do not lock device when showing name, phys and uniq
  Input: hid-lgff - treat devices as joysticks unless told otherwise
  Input: remove obsolete setup parameters from input drivers

Philipp Zabel (1):
  Input: gpio-keys - switch to common GPIO API

Valentin Zagura (1):
  Input: HID - add support for Logitech Formula Force EX

Diffstat:
-

 b/drivers/input/input.c   |   17 +-
 b/drivers/input/joystick/amijoy.c |2 -
 b/drivers/input/joystick/analog.c |2 -
 b/drivers/input/joystick/db9.c|4 --
 b/drivers/input/joystick/gamecon.c|6 ---
 b/drivers/input/joystick/turbografx.c |4 --
 b/drivers/input/keyboard/Kconfig  |6 +--
 b/drivers/input/keyboard/atkbd.c  |4 --
 b/drivers/input/keyboard/gpio_keys.c  |   15 -
 b/drivers/input/keyboard/hilkbd.c |2 +
 b/drivers/input/mouse/inport.c|2 -
 b/drivers/input/mouse/logibm.c|2 -
 b/drivers/input/mouse/psmouse-base.c  |6 ---
 b/drivers/input/mouse/psmouse.h   |1 
 b/drivers/input/mouse/synaptics.c |1 
 b/drivers/input/serio/i8042.c |7 
 b/drivers/input/serio/serio.c |   36 +
 b/drivers/usb/input/Kconfig   |6 +++
 b/drivers/usb/input/hid-ff.c  |3 +
 b/drivers/usb/input/hid-lgff.c|   10 +++---
 b/include/linux/serio.h   |6 ---
 drivers/input/mouse/psmouse-base.c|   28 +
 drivers/input/serio/i8042.c   |   56 +-
 drivers/usb/input/hid-lgff.c  |2 +
 24 files changed, 124 insertions(+), 104 deletions(-)

-- 
Dmitry
-
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: GPL vs non-GPL device drivers

This screed is the last that I am going to pollute LKML with, at least
for a while.  I'll write again if and when I have source code to
contribute, and if my off-topic vitriol renders my technical
contributions (if and when) unwelcome, I'll understand.  FSF
skulduggery is not very relevant to the _engineering_ of the kernel,
but it is (or ought to be) relevant to people's beliefs about whether
EXPORT_SYMBOL_GPL is the right thing to do.

On 2/17/07, Trent Waddington <[EMAIL PROTECTED]> wrote:

On 2/18/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> If you can
> read that and still tolerate the stench of the FSF's argument that
> linking against readline means they 0wn your source code, you have a
> stronger stomach than I.

Such a strange attitude.. to go to all this effort to quote carefully
and correctly one set of people and to then total misconstrue the
words of another.

Dammit, the world at large has been far too nice to these people for
far too long.  There's no sin in people getting rich and/or famous,
but how they did it deserves some scrutiny.  The FSF is leading
thousands of idealistic young people all over the world up the garden
path by bullshitting about the nature of US law, and if Moglen at
least isn't making bank doing it, it isn't for lack of trying.  For
starters, read http://lists.debian.org/debian-legal/2005/07/msg00531.html
(another self-reference that doesn't need flowing in).  Google around
for his letters of opinion (not pro bono, I assure you) to Fluendo and
Vidomi.  How do they smell to you?

The GPL is big money, folks; the FSF General Counsel's designing "GPL
circumvention" schemes for other people's software -- and estopping
away his ability to contest them in court, one letter of opinion (and
one hefty lump-sum fee) at a time -- isn't a tenth of it.  Ask the
OSDL, who (I am very sorry to report) funneled $4M of certain hardware
makers' money to the SFLC to bankroll the expansion of Moglen's
protection racket.  Yes, protection racket.  What other phrase could
possibly describe the Software Freedom Conservancy?

Speaking of protection rackets, how about Moglen's plaintive comments,
back in the day, to the effect of (not a direct quote):  "The
conditions of the GPL can't touch Red Hat's new trademark policy,
subscription agreement, and ISV support lock-ins because they aren't
about copyright.  The GPL, as we all know, is a creature of copyright
law.  Even though the GPL says plainly, 'You must cause any work that
you distribute or publish, that in whole or in part contains or is
derived from the Program or any part thereof, to be licensed as a
whole at no charge to all third parties under the terms of this
License', that can't possibly be taken as an 'entire agreement'
clause, because the GPL isn't an offer of contract.  Don't like having
to pay per seat for RHEL?  Sorry, we can't help you."

This would be the same Red Hat that bought Cygnus Solutions in 1999 at
an estimated price of 674 MILLION dollars (in stock, of course).  That
made some individual Cygnus stockholders rich; see
http://www.salon.com/tech/feature/1999/11/18/red_hat/print.html.  Want
to bet Moglen held a Cygnus share or two, along with (via the FSF)
control over all the source code Cygnus had ever produced?  How does
it smell now?

There's yet more money in the toolchain oligopoly that Moglen and
Redmond tacitly share, and in embedded targets generally.  (Have you
ever asked yourself how the XCode and Tornado IDEs happened?  Have you
ever tried to obtain their source code?  Now do you understand why the
FSF fetishizes the fork/exec boundary?)  Redmond is not the FSF's
enemy; the phantom menace called "software patents" is, because they
protect other software makers from the FSF's volunteer army of reverse
engineers.  All those crocodile tears over TiVo, just because they
forked GCC, put the lower layers of MPEG into silicon, and wrote their
own damn DRM in RTL, instead of toeing Moglen's line on "give me naked
ripped media or give me death".  (No, I don't have first-hand
knowledge of any of these dealings; do your own research if you want
the sordid details.)

The FSF doesn't bother with kernels.  The HURD (nee Alix) is RMS's pet
project, and there are some charming young fellows who truly believe
it's going to win time trials and cure cancer someday, but I doubt
anyone in the know ever put cash money into it.  Some kernels are
better than others but once they work they're pretty interchangeable
for desktop and low-grade network server workloads.  They do, however,
take more engineering skill than the world's most prolific cloner of
other people's interfaces (RMS, in case that isn't blindingly obvious)
has ever been able to muster.  (RMS's skill exceeds mine, or used to;
but not by the light-years that Linus's, or even Theo's, does.)

However, the FSF is very careful not to let kernel authors' peanut
butter into _their_ chocolate, because the money is in supporting
toolchains for _proprietary_ kernels

Re: [mmc] incorrect behavior on resume

2007-02-17 Thread Russell King

On Sat, Feb 17, 2007 at 05:46:35PM -0800, Alex Dubov wrote:
> The problem here is that mmc_block's device is a child of real device
> (tifm_dev here), so it gets resumed right after it.

The host driver is supposed to call mmc_resume_host from it's resume
callback.  This should be called before the child's resume callback.

> However, it correct functioning depends on mmc_core, which must be
> manually resumed (mmc_resume_host). Therefore, I think this is
> purely mmc's problem.

I don't see that - as I say above, the correct sequence is:

 - host device resume
 - calls mmc_resume_host()
 - child's device resume (mmc_blk_resume)
 - mmc_queue_resume()

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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: 2.6.20-mm2

On Sun, 18 Feb 2007 17:18:14 +1100 "Dave Airlie" <[EMAIL PROTECTED]> wrote:

> > - git-drm.patch is still in disgrace
> >
> 
> Okay I think I've fixed it up, some of the locking code from the DRM
> git devel repo was completely integrated..
> 

yep, my X server is happy now.
-
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: [RFC] killing the NR_IRQS arrays.

2007-02-17 Thread Eric W. Biederman

Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:

> On Sat, 2007-02-17 at 02:06 -0700, Eric W. Biederman wrote:

> However, PowerPC is a good example because it has such a diversity of
> very different hardware setups to deal with, ranging from the multiple
> layers of cascading controllers all over the place, to interrupts
> packets encoding vector/target etc... a bit like x86 on cell, to
> hypervisors providing a single giant number space etc etc etc...
>
> Thus, it is extremely likely that something that works well for PowerPC
> (or for ARM for that matter as it's probably as a "colorful" environment
> as PowerPC is) will end up being useful for others.

Sure I agree.  Part of what I'm trying to say is that it appears
that basic interrupt handling assumptions seem to be inherent to the
architectures.  And as much as it surprises me because of basic
assumptions I don't think there is any architecture with every flavor
of color.

>> I have a version of the x86 code with a partial conversion done and
>> I didn't need a reverse mapping.  What you call the hardware interrupt
>> number never happens to be interesting to me after the system is setup.
>
> Because you have the ability to tell your PIC to give you your "linux"
> interrupt number when actually sending the interrupt to the processor ?
> You need a way to get to the irq_desc * when getting an IRQ, either you
> have a way to map HW numbers back to irq_desc * in sofrware, or your HW
> allows you to do it.

I don't think is totally foreign, but in essence I have two kinds of
hardware number.  An (apic, pin) pair that I need when talking to
the hardware itself and a (cpu, vector) pair that I use when handling
an interrupt.  The vector number has never been the linux irq number
but at times it has only needed a simple offset adjustment.  Now that
we are having to handle bigger cases only the (apic, pin) pairs that
are actually used get a (cpumask_t, vector) assigned to them.

It may be that the only difference from the cell is that I have a very
small vector number I have to cope with instead of being able to tell
the irq controller to give me something immediately useful.

> I'm saying that if we're going to change the IRQ stuff that deeply, it
> would be nice if we looked into some of that stuff I've done that I
> beleive would be of use for other archs.

Reasonable. 

For the first pass when I do the genirq conversion passing struct
irq_desc *irq instead of unsigned int irq, I should be able to
do something stupid and correct on all of the architectures.  When
the start taking advantage of the new freedom though generic helpers
can be good.

> I found it overall very useful to have a generic remapping core and have
> cascaded PIC setups have a numbering domain local to a given PIC (pretty
> much, a domain != an irq_chip) and I'm convinced it would make life
> easier for archs with similar setups. The remapping core also shows its
> usefulness on archs with very big interrupt numbers, like sparc or
> pSeries ppc, and possibly others.

Except for the what appears to be instability of the irq numbers on
simpler configurations I don't have a problem with it.

> Now, I -do- have a problem with one aspect of your proposed design which
> is to keep the "linux" interrupt number in the generic irq_desc, which I
> think defeats most of the purpose of moving away from those linux irq
> numbers. If you do so, then I'll have to keep a separate remapping layer
> and keep a mecanism for virtualizing linux numbers.

Until we find a solution for the user space side of things we seem to
need the unsigned int irq number for user space.  Now I don't want
people mapping back and forth which is why I don't intend to provide a
reverse function.

But of course there will be a for_each_irq in the genirq layer so if
people really want to they will be able to go from the linux irq to 
an irq_desc.  But we don't have to export that generically (except
possibly something for the isa irqs).

Eric
-
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: [ck] Re: 2.6.20-ck1

2007-02-17 Thread Rodney Gordon II

On Sun, 2007-02-18 at 00:15 -0600, Rodney Gordon II wrote:
> On Sun, 2007-02-18 at 13:38 +1100, Con Kolivas wrote:
> > mdew . writes:
> > 
> > > On 2/16/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
> > >> This patchset is designed to improve system responsiveness and 
> > >> interactivity.
> > >> It is configurable to any workload but the default -ck patch is aimed at 
> > >> the
> > >> desktop and -cks is available with more emphasis on serverspace.
> > >>
> > >> Apply to 2.6.20
> > > 
> > > any benchmarks for 2.6.20-ck vs 2.6.20?
> > 
> > Would some -ck user on the mailing list like to perform a set of interbench 
> > benchmarks? They're pretty straight forward to do; see:
> > 
> > http://interbench.kolivas.org
> > 
> > --
> > -ck
> 
> Here are some benches comparing 2.6.18-4-686 (Debian sid stock) and
> 2.6.20-ck1-mt1 (2.6.20-ck1 + sched-idleprio-1.11-2.0.patch)
> 
> I know it's not what was asked for, but it might be useful for review of
> anyone using Debian kernels considering ck patches :)
> 
> Take a look.
> 
> -r

System specs by the way:
Pentium-D 830 3.0GHz Dualcore, 1.5GB RAM, 7200RPM 16MB Cache SATA3 using
AHCI w/ NCQ on.

-- 
Rodney "meff" Gordon II -*- [EMAIL PROTECTED]
Systems Administrator / Coder Geek -*- Open yourself to OpenSource

-
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: [ck] Re: 2.6.20-ck1

2007-02-17 Thread Rodney Gordon II

On Sun, 2007-02-18 at 13:38 +1100, Con Kolivas wrote:
> mdew . writes:
> 
> > On 2/16/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
> >> This patchset is designed to improve system responsiveness and 
> >> interactivity.
> >> It is configurable to any workload but the default -ck patch is aimed at 
> >> the
> >> desktop and -cks is available with more emphasis on serverspace.
> >>
> >> Apply to 2.6.20
> > 
> > any benchmarks for 2.6.20-ck vs 2.6.20?
> 
> Would some -ck user on the mailing list like to perform a set of interbench 
> benchmarks? They're pretty straight forward to do; see:
> 
> http://interbench.kolivas.org
> 
> --
> -ck

Here are some benches comparing 2.6.18-4-686 (Debian sid stock) and
2.6.20-ck1-mt1 (2.6.20-ck1 + sched-idleprio-1.11-2.0.patch)

I know it's not what was asked for, but it might be useful for review of
anyone using Debian kernels considering ck patches :)

Take a look.

-r
-- 
Rodney "meff" Gordon II -*- [EMAIL PROTECTED]
Systems Administrator / Coder Geek -*- Open yourself to OpenSource

Using 1816966 loops per ms, running every load for 30 seconds
Benchmarking kernel 2.6.18-4-686 at datestamp 200702172244

--- Benchmarking simulated cpu of Audio in the presence of simulated ---
Load	Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None	  0.005 +/- 0.005450.008		 100	100
Video	  0.086 +/- 0.6616.7		 100	100
X	   0.03 +/- 0.272   5.32		 100	100
Burn	  0.005 +/- 0.00565 0.01		 100	100
Write	  0.043 +/- 0.281   5.28		 100	100
Read	   0.01 +/- 0.0293 0.537		 100	100
Compile	  0.013 +/- 0.119   2.91		 100	100
Memload	  0.033 +/- 0.2896.2		 100	100

--- Benchmarking simulated cpu of Video in the presence of simulated ---
Load	Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None	  0.024 +/- 0.556   16.7		 100	   99.9
X	  0.874 +/- 3.7816.7		 100	   94.9
Burn	  0.005 +/- 0.005590.008		 100	100
Write	  0.128 +/- 1.3624.6		 100	   99.6
Read	  0.524 +/- 2.9316.7		 100	   96.9
Compile	  0.136 +/- 1.4317.3		 100	   99.3
Memload	  0.751 +/- 3.4817.3		 100	   95.7

--- Benchmarking simulated cpu of X in the presence of simulated ---
Load	Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None	  0.293 +/- 1.34  10		92.3	   89.2
Video	  0.606 +/- 2.32  18		89.8	   84.6
Burn	  0.526 +/- 1.93  10		90.6	   85.1
Write	   1.35 +/- 7.79  92		87.4	 84
Read	2.3 +/- 7.4   44		78.8	 72
Compile	   2.09 +/- 7.75  72		78.5	   72.9
Memload	  0.767 +/- 2.82  24		87.5	   82.2

--- Benchmarking simulated cpu of Gaming in the presence of simulated ---
Load	Latency +/- SD (ms)  Max Latency   % Desired CPU
None	   2.64 +/- 9.3150.6		97.4
Video	  0.063 +/- 0.297   5.07		99.9
X	  0.061 +/- 0.377   6.48		99.9
Burn	183 +/- 194  400		35.3
Write	   1.32 +/- 6.2180.9		98.7
Read	   4.98 +/- 7   34.5		95.3
Compile	210 +/- 228  449		32.3
Memload	   4.57 +/- 11.2  83		95.6



Using 1816966 loops per ms, running every load for 30 seconds
Benchmarking kernel 2.6.20-ck1-mt1 at datestamp 200702172307

--- Benchmarking simulated cpu of Audio in the presence of simulated ---
Load	Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None	  0.005 +/- 0.005170.009		 100	100
Video	  0.016 +/- 0.017  0.022		 100	100
X	  0.018 +/- 0.133.17		 100	100
Burn	  0.005 +/- 0.005510.013		 100	100
Write	  0.016 +/- 0.0489  1.07		 100	100
Read	  0.016 +/- 0.102   2.48		 100	100
Compile	  0.051 +/- 0.421  7		 100	100
Memload	  0.012 +/- 0.081.55		 100	100

--- Benchmarking simulated cpu of Video in the presence of simulated ---
Load	Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None	  0.088 +/- 1.1816.7		 100	   99.5
X	  0.014 +/- 0.0153 0.026		 100	100
Burn	  0.005 +/- 0.005530.016		 100	100
Write	  0.057 +/- 0.734   16.7		 100	   99.8
Read	  0.016 +/- 0.0187  0.21		 100	100
Compile	  0.042 +/- 0.328   5.59		 100	100
Memload	  0.014 +/- 0.0883  1.93		 100	100

--- Benchmarking simulated cpu of X in the presence of simulated ---
Load	Latency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None	  0.033 +/- 0.258  2		98.7	   97.7
Video	  0.033 +/- 0.258  2		98.7	   97.7
Burn	  0.046 +/- 0.337  3		98.4	 97
Write	  0.129 +/- 0.777  7		96.5	   94.4
Read	  0.292 +/- 1.75  18		94.4	   91.6
Compile	  0.473 +/- 2.66  28		  92	 89
Memload	  0.178 +/- 0.98   8		96.8	   93.8

--- Benchmarking simulated cpu of Gaming in the presence of simulated ---
Load

Re: 2.6.20-mm2

2007-02-17 Thread Dave Airlie


- git-drm.patch is still in disgrace



Okay I think I've fixed it up, some of the locking code from the DRM
git devel repo was completely integrated..

Dave.
-
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: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

2007-02-17 Thread Jörn Engel

On Sat, 17 February 2007 15:47:01 -0500, Sorin Faibish wrote:
>
> DualFS can probably get around this corner case as it is up to the user
> to select the size of the MD device size. If you want to prevent this
> corner case you can always use a device bigger than 10% of the data device
> which is exagerate for any FS assuming that the directory files are so
> large (this is when you have billions of files with long names).
> In general the problem you mention is mainly due to the data blocks
> filling the file system. In DualFS case you have the choice of selecting
> different sizes for the MD and Data volume. When Data volume gets full
> the GC will have a problem but the MD device will not have a problem.
> It is my understanding that most of the GC problem you mention is
> due to the filling of the FS with data and the result is a MD operation
> being disrupted by the filling of the FS with data blocks. As about the
> performance impact on solving this problem, as you mentioned all
> journal FSs will have this problem, I am sure that DualFS performance
> impact will be less than others at least due to using only one MD
> write instead of 2.

You seem to make the usual mistakes when people start to think about
this problem.  But I could misinterpret you, so let me paraphrase your
mail in questions and answer what I believe you said.

Q: Are journaling filesystems identical to log-structured filesystems?

Not quite.  Journaling filesystems usually have a very small journal (or
log, same thing) and only store the information necessary for atomic
transactions in the journal.  Not sure what a "journal FS" is, but the
name seems closer to a journaling filesystem.

Q: DualFS seperates Data and Metadata.  Does that make a difference?

Not really.  What I called "data" in my previous mail is a
log-structured filesystems view of data.  DualFS stored file content
seperately, so from an lfs view, that doesn't even exist.  But directory
content exists and behaves just like file content wrt. the deadlock
problem.  Any data or metadata that cannot be GC'd by simply copying but
requires writing further information like indirect blocks, B-Tree nodes,
etc. will cause the problem.

Q: If the user simply reserves some extra space, does the problem go
away?

Definitely not.  It will be harder to hit, but a rare deadlock is still
a deadlock.  Again, this is only concerned with the log-structured part
of DualFS, so we can ignore the Data volume.

When data is spread perfectly across all segments, the best segment one
can pick for GC is just as bad as the worst.  So let us take some
examples.  If 50% of the lfs is free, you can pick a 50% segment for GC.
Writing every single block in it may require writing one additional
indirect block, so GC is required to write out a 100% segment.  It
doesn't make any progress at 50% (in a worst case scenario) and could
deadlock if less than 50% were free.

If, however, GC has to write out a singly and a doubly indirect block,
67% of the lfs need to be free.  In general, if the maximum height of
your tree is N, you need (N-1)/N * 100% free space.  Most people refer
to that as "too much".

If you have less free space, the filesystem will work just fine "most of
the time".  That is nice and cool, but it won't help your rare user that
happens to hit the rare deadlock.  Any lfs needs a strategy to prevent
this deadlock for good, not just make it mildly unlikely.

Jörn

-- 
"Error protection by error detection and correction."
-- from a university class
-
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: [ck] Re: 2.6.20-ck1

On Sunday 18 February 2007 13:38, Con Kolivas wrote:
> mdew . writes:
> > On 2/16/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
> >> This patchset is designed to improve system responsiveness and
> >> interactivity. It is configurable to any workload but the default -ck
> >> patch is aimed at the desktop and -cks is available with more emphasis
> >> on serverspace.
> >>
> >> Apply to 2.6.20
> >
> > any benchmarks for 2.6.20-ck vs 2.6.20?
>
> Would some -ck user on the mailing list like to perform a set of interbench
> benchmarks? They're pretty straight forward to do; see:
>
> http://interbench.kolivas.org

I couldn't take down any lower power machine for these benchmarks... A lower 
power single cpu machine would be better for this. Feel free to throw any 
other benchmarks at it.

This core2 duo 2.4 GHz with 2GB ram and 7200 rpm 16MB cache hard drive is not 
too discrimanatory, but here are the results (use fixed font to see):

Using 2392573 loops per ms, running every load for 30 seconds
Benchmarking kernel 2.6.20 at datestamp 200702181608

--- Benchmarking simulated cpu of Audio in the presence of simulated ---
LoadLatency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.002 +/- 0.003290.006 100100
Video 0.002 +/- 0.00356 0.01 100100
X 0.007 +/- 0.0819 2 100100
Burn  0.002 +/- 0.003350.005 100100
Write 0.105 +/- 1.5535.5 100100
Read  0.006 +/- 0.007070.014 100100
Compile   0.312 +/- 5.61 13599.8   99.8
Memload0.01 +/- 0.037   0.72 100100

--- Benchmarking simulated cpu of Video in the presence of simulated ---
LoadLatency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.004 +/- 0.004310.017 100100
X 0.006 +/- 0.006080.013 100100
Burn  0.003 +/- 0.003920.012 100100
Write 0.097 +/- 3.44 14499.8   99.8
Read  0.005 +/- 0.005230.013 100100
Compile   0.059 +/- 1.2 36.799.8   99.8
Memload0.01 +/- 0.0767  1.85 100100

--- Benchmarking simulated cpu of X in the presence of simulated ---
LoadLatency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.056 +/- 0.379  398.4   96.7
Video 0.033 +/- 0.258  298.7   97.7
Burn  0 +/- 0  0 100100
Write 0.051 +/- 0.6711.299.3 99
Read  0.053 +/- 0.384  3  98   96.7
Compile   0.139 +/- 2.29  39  99   98.6
Memload   0.166 +/- 2.25  3998.1   97.1

--- Benchmarking simulated cpu of Gaming in the presence of simulated ---
LoadLatency +/- SD (ms)  Max Latency   % Desired CPU
None  0.551 +/- 0.553  0.66599.5
Video 0.594 +/- 0.596  0.65699.4
X 0.019 +/- 0.317   5.49 100
Burn179 +/- 186  19335.9
Write  1.16 +/- 5.8769.298.9
Read  0.876 +/- 0.884   1.3199.1
Compile 193 +/- 209  49934.1
Memload1.11 +/- 1.5915.398.9


Using 2392573 loops per ms, running every load for 30 seconds
Benchmarking kernel 2.6.20-ck1 at datestamp 200702181542

--- Benchmarking simulated cpu of Audio in the presence of simulated ---
LoadLatency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.002 +/- 0.003330.005 100100
Video 0.004 +/- 0.0309 0.717 100100
X 0.008 +/- 0.124   2.99 100100
Burn  0.002 +/- 0.003390.005 100100
Write  0.03 +/- 0.228   2.99 100100
Read  0.005 +/- 0.006360.017 100100
Compile   0.041 +/- 0.268   3.06 100100
Memload0.31 +/- 4.83 6.3 100100

--- Benchmarking simulated cpu of Video in the presence of simulated ---
LoadLatency +/- SD (ms)  Max Latency   % Desired CPU  % Deadlines Met
None  0.003 +/- 0.003830.014 100100
X 0.008 +/- 0.143   5.99 100100
Burn  0.003 +/- 0.003830.009 100100
Write 0.023 +/- 0.219   4.57 100100
Read  0.004 +/- 0.0047 0.017 100100
Compile   0.027 +/- 0.214   3.73 100100
Memload   0.015 +/- 0.113  3 100100

---

Re: 2.6.20: libata PATA ATAPI CDROM weirdness on ALI

2007-02-17 Thread Andrey Borzenkov

Brandon Low wrote:

> I'm having some weirdness during boot with my optical drives on 2.6.20.
> 
> ata2.00: ATAPI, max UDMA/33
> ata2.01: ATAPI, max UDMA/33
> ata2.00: qc timeout (cmd 0xef)
> ata2.00: failed to set xfermode (err_mask=0x4)
> ata2.00: limiting speed to UDMA/25
> ata2: failed to recover some devices, retrying in 5 secs
> ata2.00: configured for UDMA/25
> ata2.01: configured for UDMA/33
> 
> the 4 lines starting with qc timeout _would_ repeat with lower speeds
> until the drive was finally disabled and then do the same for 2.01,
> except that on this particular attempt, I had the thought to eject both
> optical drives while it sat there.  Boot then proceeded normally and the
> drives appear to work.
> 
> Intuitively this seems to indicate that the drives aren't being sent
> some kind of wake-up call before their transfer modes are set.
> 
> The motherboard is an ASRock 939 Dual SATA II.
> 

In my case of relatively old ALi chipset CD-ROM was never detected if DMA is
allowed. Unfortunately this remained mystery for quite some time. Legacy
IDE drivers are working just fine; it is only pata_ali that failes :(

See e.g. http://marc.theaimsgroup.com/?l=linux-kernel=116500554505311=2
(2.6.19: ALi M5229 - CD-ROM not found with pata_ali)

if you have any idea how to debug it ...

-andrey


> Let me know if there is any more information that I can provide.
> 
> Thanks,
> 
> Brandon Low


-
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/

2.6.20-mm2


Temporarily at

  http://userweb.kernel.org/~akpm/2.6.20-mm2/

Will appear later at

 
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/


- There are IDE- and Xen-related module linkage errors during allmodconfig
  builds.  These have been reported.

- Quite a lot of less-popular architectures are broken by the utrace merge. 
  They will stay that way while the maintainers ponder
  http://people.redhat.com/roland/utrace/utrace-arch-porting-howto.txt

- Added the LED development tree to the -mm lineup as git-leds.patch
  (Richard Purdie <[EMAIL PROTECTED]>)

- git-parisc.patch is back for a while

- git-audit.patch is back for a while

- git-drm.patch is still in disgrace

- Added Xen domain-U support

- Judging by the number of times I get asked "is there a git tree for -mm",
  nobody is reading the boilerplate.  Here it is again:



Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- To fetch an -mm tree using git, use (for example)

  git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git 
tag v2.6.16-rc2-mm1
  git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1

- -mm kernel commit activity can be reviewed by subscribing to the
  mm-commits mailing list.

echo "subscribe mm-commits" | mail [EMAIL PROTECTED]

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
  most valuable if you can perform a bisection search to identify which patch
  introduced the bug.  Instructions for this process are at

http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

  But beware that this process takes some time (around ten rebuilds and
  reboots), so consider reporting the bug first and if we cannot immediately
  identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
  list on any email.

- When reporting bugs in this kernel via email, please also rewrite the
  email Subject: in some manner to reflect the nature of the bug.  Some
  developers filter by Subject: when looking for messages to read.

- Occasional snapshots of the -mm lineup are uploaded to
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
  the mm-commits list.




Changes since 2.6.20-mm1:


 origin.patch
 git-acpi.patch
 git-alsa.patch
 git-arm.patch
 git-audit-master.patch
 git-avr32.patch
 git-cifs.patch
 git-powerpc.patch
 git-dvb.patch
 git-hid.patch
 git-ia64.patch
 git-ieee1394.patch
 git-infiniband.patch
 git-input.patch
 git-jfs.patch
 git-leds.patch
 git-libata-all.patch
 git-ide.patch
 git-lxdialog.patch
 git-md-accel.patch
 git-mips.patch
 git-mmc.patch
 git-mtd.patch
 git-ubi.patch
 git-netdev-all.patch
 git-backlight.patch
 git-bluetooth.patch
 git-ioat.patch
 git-ocfs2.patch
 git-parisc.patch
 git-pciseg.patch
 git-s390.patch
 git-sh.patch
 git-scsi-misc.patch
 git-block.patch
 git-unionfs.patch
 git-v9fs.patch
 git-wireless.patch
 git-ipwireless_cs.patch
 git-gccbug.patch

 git trees

-gpio-core-documentation.patch
-build-errors-uevent-with-config_sysfs=n.patch
-mincore-config_swap=n-fix.patch
-mincore-fill-in-results-properly.patch
-mincore-vma-crossing-fix.patch
-acpi-i686-x86_64-fix-laptop-bootup-hang-in-init_acpi.patch
-ifdef-acpi_future_usage-acpi_os_readable.patch
-at91-correct-value-for-at91_rstc_key.patch
-powerpc-rtas-msi-support-fix.patch
-fix-cut-and-paste-breakage-in-arch-powerpc-platforms-pseries-pseriesh.patch
-powerpc-export-of_find_property.patch
-libata-add-a-host-flag-to-indicate-lack-of-iordy.patch
-add-delay-around-sl82c105_reset_engine-calls.patch
-sata_nv-add-back-some-verbosity-into-adma-error_handler-tidy.patch
-sata_nv-handle-serror-status-indication.patch
-ata-convert-gsi-to-irq-on-ia64.patch
-git-md-accel-fixes.patch
-git-md-accel-warning-fixes.patch
-git-md-accel-fix.patch
-revert-drivers-net-tulip-dmfe-support-basic-carrier-detection.patch
-fix-atl1-braino.patch
-net-wan-pc300tooc-pci_module_init-to-pci_register_driver.patch
-atl1-drop-net_pci-from-kconfig.patch
-atl1-read-mac-address-from-register.patch
-atl1-remove-unused-define.patch
-atl1-add-l1-device-id-to-pci_ids-then-use-it.patch
-atl1-bump-version-number.patch
-atm-use-array_size-macro-when-appropriate.patch
-bugfixes-and-new-hardware-support-for-arcnet-driver.patch
-git-backlight-sony-fix.patch
-parisc-fix-module_param-iommu-permission.patch
-pa-risc-fix-bogus-warnings-from-modpost.patch
-use-__u64-rather-than-u64-in-parisc-statfs-structs.patch
-pci-add-systems-for-automatic-breadth-first-device-sorting-update.patch
-x86-fix-dev_to_node-for-x86-and-x86_64.patch
-remove-extra-newline-from-info-message.patch
-fix-scsi-scsi_transporth-compile-error.patch
-pci_module_init-convertion-in-the-legacy-megaraid-driver.patch
-scsi-handle-bad-inquiry-responses.patch
-scsi-megaraid_sas-donot-process-cmds-if-hw_crit_error-is-set.patch
-scsi-megaraid_sas-added-bios_param-in-scsi_host_template.patch

Which architectures need to sync vmalloc mappings between processes?

2007-02-17 Thread Jeremy Fitzhardinge

Hi,

I'm looking at making all architectures export a vmalloc_sync_all()
function, so that generic code can be sure that a particular vmalloc
mapping is present in all address spaces.   I need this to implement a
function to reserve a chunk of vmalloc address space complete with
constructed pagetables, but without allocating any actual data pages.

On i386 with PAE, this is not necessary because the kernel's mappings
are shared between all processes anyway, so it would be a no-op.  
However, non-PAE i386 has a separate kernel mapping for each process,
and so needs to sync them - typically lazily on faults, but
vmalloc_sync_all exists to allow mass syncing when required.

What other architectures would require syncing of vmalloc mappings, and
what architectures would implement it as a no-op?

Thanks,
J
-
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/

2.6.20: libata PATA ATAPI CDROM weirdness on ALI

2007-02-17 Thread Brandon Low

I'm having some weirdness during boot with my optical drives on 2.6.20.

ata2.00: ATAPI, max UDMA/33 
ata2.01: ATAPI, max UDMA/33 
ata2.00: qc timeout (cmd 0xef)
ata2.00: failed to set xfermode (err_mask=0x4)
ata2.00: limiting speed to UDMA/25
ata2: failed to recover some devices, retrying in 5 secs
ata2.00: configured for UDMA/25
ata2.01: configured for UDMA/33

the 4 lines starting with qc timeout _would_ repeat with lower speeds
until the drive was finally disabled and then do the same for 2.01,
except that on this particular attempt, I had the thought to eject both
optical drives while it sat there.  Boot then proceeded normally and the
drives appear to work.

Intuitively this seems to indicate that the drives aren't being sent
some kind of wake-up call before their transfer modes are set.

The motherboard is an ASRock 939 Dual SATA II.

Let me know if there is any more information that I can provide.

Thanks,

Brandon Low
-
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: Kbuild problem

2007-02-17 Thread Kai Germaschewski

On Sat, 17 Feb 2007, Tilman Schmidt wrote:

> Alright, then so be it. But that raises another question:
> asyncdata.o is only needed for M105 and M101, not for the base
> driver. How do I express in Kbuild that asyncdata.o is to be added
> to gigaset-y only if CONFIG_GIGASET_M105 and CONFIG_GIGASET_M101
> are not both 'n'?

The way this is typically done is via Kconfig. Add a config option 
ASYNCDATA (actually something more descriptive/specific would be better), 
add a "select ASYNCDATA" to the config options for m101 and m105, and then 
you can use CONFIG_ASYNCDATA to decide whether to add asyncdata.o in the 
Makefile.

--Kai

-
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: GPL vs non-GPL device drivers

2007-02-17 Thread Alexandre Oliva

On Feb 17, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

>> On Saturday 17 February 2007 03:42, David Schwartz wrote:
>> 
>> > Again, see Lexmark v. Static Controls. If "make a toner cartridge
>> > that works with a particular Lexmark printer" is a functional
>> > idea, why is "make a graphics driver that works with a particular
>> > Linux kernel" not? What is the difference you think matters?

>> That you cannot build such modules without integrating parts of
>> actual Linux kernel code (via #includes etc), whereas you can build
>> compatible toner cartridges without using any original component.

> Static Controls actually put a copy of Lexmark's 'Toner Loading Program' on
> each compatible cartridge they made. The printer actually copies the TLP off
> the cartridge. In other words, to make a compatible catridge, you do have to
> use an original component. (Or at least, it's much more difficult not to.)

Besides, you *can* build a module for Linux without using any kernel
code.  It just takes a lot of work to implement all you'd otherwise
need from the kernel in a clean-room fashion.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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: Recent and not-so problems with tifm_sd driver

2007-02-17 Thread Alex Dubov

> I don't actually think that is what happening. The block errors tend to trail 
> a
> bit behind, so the errors you are seeing are probably the result of the queue
> being flushed out as you remove the card. I don't see any mmc debug messages
> that indicate that is trying to send more mmc requests.

Yes, indeed - it does not issue new requests after remove. However, 
mmc_remove_host does not wait
for all issued requests to complete and it is a problem.
Here's my remove procedure:
1. cut off interrupt signaling call back - no tasklets will be coming from here
2. kill request completion tasklet
3. check if there's still an unfinished request - if yes, schedule a completion 
tasklet
3a. if I'll sleep here, just scheduled tasklet will have a chance to complete
3b. This is what happens if I don't sleep:
(this line is printed by completion tasklet: tifm_sd0:3: num_bl 7, b_s 512, bsh 
443)
--
Feb 18 15:22:40 mortug tifm_sd0:3 : card failed to respond for a long period of 
time (12, 1)
Feb 18 15:22:40 mortug tifm_7xx1 :06:09.3: checking media set 8
Feb 18 15:22:40 mortug tifm0 : demand removing card from socket 0:3
Feb 18 15:22:40 mortug mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0
Feb 18 15:22:40 mortug tifm_sd tifm_sd0:3: ios: clock = 0, vdd = 0, bus_mode = 
1, chip_select = 0,
power_mode = 0, bus_width = 0
Feb 18 15:22:40 mortug tifm_sd tifm_sd0:3: after remove
Feb 18 15:22:40 mortug tifm_sd tifm_sd0:3: num_bl 7, b_s 512, bsh 443
Feb 18 15:22:40 mortug mmc0: req done (CMD18): 1/0/1: 0900  
 
Feb 18 15:22:40 mortug mmcblk0: error 1 sending read/write command
Feb 18 15:22:40 mortug end_request: I/O error, dev mmcblk0, sector 0
Feb 18 15:22:40 mortug printk: 79 messages suppressed.
Feb 18 15:22:40 mortug Buffer I/O error on device mmcblk0, logical block 0
Feb 18 15:22:40 mortug divide error:  [1] SMP 
Feb 18 15:22:40 mortug CPU 0 
..
Feb 18 15:22:40 mortug Call Trace:
Feb 18 15:22:40 mortug [] 
:mmc_block:mmc_blk_issue_rq+0xf0/0x600
Feb 18 15:22:40 mortug [] __alloc_pages+0x69/0x2f0
Feb 18 15:22:40 mortug [] do_wp_page+0x4b1/0x510
Feb 18 15:22:40 mortug [] task_rq_lock+0x50/0x90
Feb 18 15:22:40 mortug [] __activate_task+0x38/0x50
Feb 18 15:22:40 mortug [] try_to_wake_up+0x42b/0x440
Feb 18 15:22:40 mortug [] elv_rb_del+0x2d/0x50
Feb 18 15:22:40 mortug [] elv_next_request+0x15d/0x1e0
Feb 18 15:22:40 mortug [] 
:mmc_core:mmc_queue_thread+0xd8/0x110
Feb 18 15:22:40 mortug [] :mmc_core:mmc_queue_thread+0x0/0x110
Feb 18 15:22:40 mortug [] keventd_create_kthread+0x0/0x90
Feb 18 15:22:40 mortug [] kthread+0xd9/0x120
Feb 18 15:22:40 mortug [] child_rip+0xa/0x12
Feb 18 15:22:40 mortug [] keventd_create_kthread+0x0/0x90
Feb 18 15:22:40 mortug [] kthread+0x0/0x120
Feb 18 15:22:40 mortug [] child_rip+0x0/0x12
Feb 18 15:22:40 mortug 
Feb 18 15:22:40 mortug 
Feb 18 15:22:40 mortug Code: f7 f6 41 01 c1 41 83 f8 01 19 c0 25 10 b6 fd ff 05 
90 d0 03 
Feb 18 15:22:40 mortug RIP  [] 
:mmc_core:mmc_set_data_timeout+0x7c/0xb0
Feb 18 15:22:40 mortug RSP 



 

Don't get soaked.  Take a quick peak at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather
-
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: [RFC] killing the NR_IRQS arrays.

2007-02-17 Thread Eric W. Biederman

Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:

>> The only time it really makes sense to me to let the irq number vary
>> arbitrary are when things are truly dynamic, like with MSI, a
>> hypervisor, or hot plug interrupt controllers.
>
> I don't understand why you would go to all that lenght to replace irq
> numbers with irq_desc * and ... keep then numbers :-)

Because I don't have something better to replace them with.

We need names for irqs, currently the kernel/user space interface
is a unsigned number.

Printing out a pointer where we currently have an integer in:
/proc/interrupts
/proc/irq/N/...
/sys/devices/pci:00/:00:0e.0/irq
is a bad practice, and if  I don't retain the number that is 
my only choice.

I similar problem exists in all of the initialization messages from
device drivers that display their irq number.

Plus I think there are also a few ioctls that return the linux
irq number.

Now it may make sense to replace my irq_nr() with irq_name(), and
return a string that can be used instead, but fixing the kernel
user space interface is a third step that is a lot more delicate
and will require more thinking.  So I would prefer to put that
off until all of the internal users are using a pointer.  Then
we can grep for irq_nr and see how many places we actually export
the irq number to user space.

The fact that the user space has been put in charge of when to
migrate an irq from cpu to another makes this double delicate.

>> Sure, and I have the same issue with a big "DESIGNED FOR ppc" in the middle,
>> or "DESIGNED FOR arch/x".   However the unfortunate truth is that the x86
>> has enough volume that frequently other architectures use some x86
>> hardware and thus get some of x86's warts.   So anything that doesn't
>> cope with the x86's warts is frequently doomed to failure.
>
> I fait to see how what I described would not apply nicely to x86 ..

The model can be made to work if you force it but it isn't really
a good fit.

I can't really use the (cpu#, vector#) tuple as hw number as it
varies at runtime, and a single interrupt can  send different (cpu#,
vector#) tuples from one interrupt message to the next without being
reprogrammed.   At least I don't have the impression that you support
multiple hardware numbers going to the same linux irq.  But this
really is the layer where I need the reverse mapping.  However I can
optimize the reverse mapping by taking advantage of the per cpu
nature.

Currently the hardware number that I use is the pin number on
the ioapic.  And to form the linux irq I just add the number
of pins of all previous ioapics together and then add my pin number.
Fairly simple.

Doing the above gives me stable names that are the same from one boot
to the next if someone doesn't change how the hardware is put
together.  It looks to me that if I adapt the ppc scheme my irq
numbers will change from one boot to the next one kernel to the next,
almost at random.  Depending on driver initialization order and
similar things.  Having names that change all of the time is confusing
and not very useful.  The fact that in the process of making my names
stable it actually happens to reflect part of the irq hardware
topology is incidental.

Giving up stable names is not something I want to do.

Eric
-
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: GPL vs non-GPL device drivers

2007-02-17 Thread Alexandre Oliva

On Feb 17, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> Interestingly, if you are right, then what online translation services like
> babelfish [...]
> but much harder to argue that it gives them the right to create a derivative
> work. (Of course, you could argue fair use.)

One could try to argue it's an accessibility issue, if local fair use
has provisions for it.  Even for manual translations.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.org}
-
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] sysctl: move init_irq_proc into init/main where it belongs

2007-02-17 Thread Dave Jones

On Wed, Feb 14, 2007 at 05:00:19PM +, Linux Kernel wrote:
 > Gitweb: 
 > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b04c3afb2b6e2f902b41bb62b73684d92d7e6c34
 > Commit: b04c3afb2b6e2f902b41bb62b73684d92d7e6c34
 > Parent: 0e03036c97b70b2602f7dedaa3a223ed7563c2c9
 > Author: Eric W. Biederman <[EMAIL PROTECTED]>
 > AuthorDate: Wed Feb 14 00:33:57 2007 -0800
 > Committer:  Linus Torvalds <[EMAIL PROTECTED]>
 > CommitDate: Wed Feb 14 08:09:58 2007 -0800
 > 
 > [PATCH] sysctl: move init_irq_proc into init/main where it belongs
 > 
 > Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
 > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
 > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>

This causes an implicit declaration which broke ppc32 builds for me..
(my builds use -Werror-implicit to catch this flaw early)

init/main.c: In function 'do_basic_setup':
init/main.c:744: error: implicit declaration of function 'init_irq_proc'

Dave

-- 
http://www.codemonkey.org.uk
-
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/

[GIT PULL] audit patches

2007-02-17 Thread Al Viro

Misc audit patches (resend again...); the most intrusive one is AUDIT_FD_PAIR,
allowing to log descriptor numbers from syscalls that do not return them in
usual way (i.e. pipe() and socketpair()).  It took some massage of
the failure exits in sys_socketpair(); the rest is absolutely trivial.
Please, pull from
git.kernel.org/pub/scm/linux/kernel/git/viro/audit-current.git/ audit.b37

Al Viro (1):
  AUDIT_FD_PAIR

Steve Grubb (2):
  minor update to rule add/delete messages (ver 2)
  audit config lockdown

 fs/pipe.c |7 ++
 include/linux/audit.h |9 ++
 kernel/audit.c|  216 +++-
 kernel/auditfilter.c  |9 +-
 kernel/auditsc.c  |   40 +
 net/socket.c  |   52 +---
 6 files changed, 257 insertions(+), 76 deletions(-)
-
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: [RFC] killing the NR_IRQS arrays.

2007-02-17 Thread Eric W. Biederman

Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:

>
>> We might need this.  But I don't think we need reference counting in
>> the traditional sense.  For all practical purpose we already have
>> dynamic irq allocation and it hasn't proven necessary.  I would
>> prefer to go to lengths to avoid having to expose that kind of
>> an issue to driver code.
>
> I think we do need proper refcounting, but I also think that most
> drivers will not need to see it.
>
> For example, a PCI driver will most probably just do something along the
> lines of the existing request_irq(pdev->irq), the liftime of pdev->irq
> is managed by the PCI core.
>
> Same goes with MSIs imho, the MSI core can manage the lifetime
> transparently.

Yes.  I'm optimistic that we won't find a case where refcounting will
be needed.

Eric
-
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: exporting LANG=C (Re: [PATCH] override build timestamp)

2007-02-17 Thread Oleg Verych

On Sun, Feb 18, 2007 at 02:57:26AM +0100, Roman Zippel wrote:
> Hi,

Hallo, Roman.

> On Sat, 17 Feb 2007, Oleg Verych wrote:
> 
> > could you make separate patch with exporting 'LANG=C' on the very
> > beginning and delete all other occurrences of it? It's a C header file
> > generation and afaik, it must be ASCII.
> 
> Bad idea, most user output should be localized (even if it's only utf-8) 
> and some kconfig targets have explicit locale support.

Ok, then maybe this one



can be fixed as well? I used same reasoning to comment on it (that
particular patch was dropped).

-
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] Block layer: separate out queue-oriented ioctls

2007-02-17 Thread Douglas Gilbert

Jens Axboe wrote:
> On Fri, Feb 16 2007, Alan Stern wrote:
>> From: James Bottomley <[EMAIL PROTECTED]>
>>
>> This patch (as854) separates out the two queue-oriented ioctls from
>> the rest of the block-layer ioctls.  The idea is that they should
>> apply to any driver using a request_queue, even if the driver doesn't
>> implement a block-device interface.  The prototypical example is the
>> sg driver, to which the patch adds the new interface.
>>
>> This will make it possible for cdrecord and related programs to
>> retrieve reliably the max_sectors value, regardless of whether the
>> user points it to an sr or an sg device.  In particular, this will
>> resolve Bugzilla entry #7026.
> 
> The block bits are fine with me, the sg calling point is a bit of a sore
> thumb (a char driver calling into block layer ioctls) though. So the
> block layer bits are certainly ok with me, if Doug acks the sg bit I'll
> merge everything up.
> 
> (patch left below)

Does this need to be in the sg driver?

What is the hardware sector size of a SES or OSD device?

As for the max_sector variable, wouldn't it be better
to generate a new ioctl that yielded the limit in bytes?
Making a driver variable that implicitly assumes sectors
are 512 bytes in length more visible to the user space
seems like a step in the wrong direction.

Alternatively the SG_GET_RESERVED_SIZE ioctl could be
modified to yield no more than max_sectors*512 .

Doug Gilbert


P.S. See comment below

>> Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
>>
>> ---
>>
>> Jens:
>>
>> James said that he feels you should be be the person to accept this
>> patch, since it affects the block layer.  Please merge it and send it
>> on up the hierarchy.
>>
>> Alan Stern
>>
>>
>>
>> diff --git a/block/ioctl.c b/block/ioctl.c
>> index 58aab63..8444d0c 100644
>> --- a/block/ioctl.c
>> +++ b/block/ioctl.c
>> @@ -135,6 +135,31 @@ static int put_u64(unsigned long arg, u6
>>  return put_user(val, (u64 __user *)arg);
>>  }
>>  
>> +static int blk_queue_locked_ioctl(struct request_queue *queue,
>> +  unsigned cmd, unsigned long arg)
>> +{
>> +switch (cmd) {
>> +case BLKSSZGET: /* get block device hardware sector size */
>> +return put_int(arg, queue_hardsect_size(queue));
>> +case BLKSECTGET:
>> +return put_ushort(arg, queue->max_sectors);
>> +}
>> +return -ENOIOCTLCMD;
>> +}
>> +
>> +int blk_queue_ioctl(struct request_queue *queue, unsigned cmd,
>> +unsigned long arg)
>> +{
>> +int ret;
>> +
>> +lock_kernel();
>> +ret = blk_queue_locked_ioctl(queue, cmd, arg);
>> +unlock_kernel();
>> +
>> +return ret;
>> +}
>> +EXPORT_SYMBOL(blk_queue_ioctl);
>> +
>>  static int blkdev_locked_ioctl(struct file *file, struct block_device *bdev,
>>  unsigned cmd, unsigned long arg)
>>  {
>> @@ -154,10 +179,6 @@ static int blkdev_locked_ioctl(struct fi
>>  return put_int(arg, bdev_read_only(bdev) != 0);
>>  case BLKBSZGET: /* get the logical block size (cf. BLKSSZGET) */
>>  return put_int(arg, block_size(bdev));
>> -case BLKSSZGET: /* get block device hardware sector size */
>> -return put_int(arg, bdev_hardsect_size(bdev));
>> -case BLKSECTGET:
>> -return put_ushort(arg, bdev_get_queue(bdev)->max_sectors);
>>  case BLKRASET:
>>  case BLKFRASET:
>>  if(!capable(CAP_SYS_ADMIN))
>> @@ -278,6 +299,8 @@ int blkdev_ioctl(struct inode *inode, st
>>  
>>  lock_kernel();
>>  ret = blkdev_locked_ioctl(file, bdev, cmd, arg);
>> +if (ret == -ENOIOCTLCMD)
>> +ret = blk_queue_locked_ioctl(bdev_get_queue(bdev), cmd, arg);
>>  unlock_kernel();
>>  if (ret != -ENOIOCTLCMD)
>>  return ret;
>> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
>> index 81e3bc7..d97244b 100644
>> --- a/drivers/scsi/sg.c
>> +++ b/drivers/scsi/sg.c
>> @@ -786,6 +786,11 @@ sg_ioctl(struct inode *inode, struct fil
>> sdp->disk->disk_name, (int) cmd_in));
>>  read_only = (O_RDWR != (filp->f_flags & O_ACCMODE));
>>  
>> +/* block ioctls first */

Why first??
That would allow the block layer to overtake any currently
defined and working sg ioctl.
Surely, if it was put in, it should be in the default case.

>> +result = blk_queue_ioctl(sdp->device->request_queue, cmd_in, arg);
>> +if (result != -ENOIOCTLCMD)
>> +return result;
>> +
>>  switch (cmd_in) {
>>  case SG_IO:
>>  {
>> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
>> index e1c7286..550b04a 100644
>> --- a/include/linux/blkdev.h
>> +++ b/include/linux/blkdev.h
>> @@ -754,6 +754,8 @@ extern void blk_queue_prep_rq(request_qu
>>  extern void blk_queue_merge_bvec(request_queue_t *, merge_bvec_fn *);
>>  extern void blk_queue_dma_alignment(request_queue_t *, int);
>>  extern void blk_queue_softirq_done(request_queue_t *, softirq_done_fn *);

Re: GPL vs non-GPL device drivers

2007-02-17 Thread Trent Waddington


On 2/18/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote:

If you can
read that and still tolerate the stench of the FSF's argument that
linking against readline means they 0wn your source code, you have a
stronger stomach than I.


Such a strange attitude.. to go to all this effort to quote carefully
and correctly one set of people and to then total misconstrue the
words of another.

The FSF's argument in regards to readline is that you may not
distribute readline with proprietary software linked to it.  They
don't claim they "0wn" your source code.

Trent
-
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] Kwatch: kernel watchpoints using CPU debug registers

2007-02-17 Thread Roland McGrath

> How do you suggest this be handled?  Maybe we should just keep track of a
> maximum user priority level for each slot, allowing it to go up but not
> down until all user processes have given up the slot.  (I.e., in the
> example above the later kwatch requests would still fail because we would
> continue to remember the high user priority level so long as the first
> process maintained its allocation.)  That would be overly pessimistic, but
> it would at least be safe.

I think that is certainly fine to start with.  Like I said before, we can
start conservative and then worry about more complexity as the concrete
needs arise.  I don't think it will really be any trouble to change some of
these low-level interfaces later to accomodate more sophisticated callers
and implementations.  

When the issue does arise, scanning all the necessary tasks may not really
need to be so costly.  That is, if rather than scanning all tasks in the
system, it's a list of debugreg allocations.  The callers doing fancy
allocation can be responsible for passing in storage for a struct
containing the list structure.  That would naturally embed in struct
kwatch.  Having the debugreg allocation routines pass in such a structure
would also be useful for another kind of flexibility I'd like to have
eventually.  That is, "local" allocations that are local to a group of
tasks rather than just one.  For example, a debugger most often actually
wants to share watchpoints among all the threads sharing an address space.
If identical settings are in fact shared, the storage requirements for
using watchpoints in many-threaded processes scale that much better.

I think we have a while before we have to actually figure any of that out
in detail.  The simple starting point covers all our immediate concrete
concerns.


Thanks,
Roland

-
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 41/44 take 2] [UBI] gluebi unit header

On Sun, Feb 18, 2007 at 03:15:23AM +0100, Arnd Bergmann wrote:
> On Sunday 18 February 2007 03:04, Josh Boyer wrote:
> > No, the MTD interface isn't flawed.  gluebi is present to make things like
> > JFFS2 work on top of UBI volumes with very little adaptations.  If you go
> > changing _every_ MTD user to now use either an MTD device or a native UBI
> > device, then the code for those users just gets bloated.
> 
> Right, that was my point. If the MTD API in the kernel is not flawed, why
> do we need the 'native' UBI interface? Just merge gluebi into UBI and
> get rid of the extra abstraction.

That suggestion came up several times.  gluebi represents a compromise
between the two groups.  IIRC, the issue was that representing UBI volumes
as MTD devices only makes sense in the dynamic volume case.  Static UBI
volumes require special write/update handling and so there was a need for
a native interface anyway.

> 
> > Assuming your SD card isn't doing wear-leveling itself within the device,
> > yes that is what you would get.  
> 
> While probably all modern SD cards have some amount of wear leveling
> built in, I wouldn't want to rely on that for anything but the simple
> large-file-on-fatfs (jpeg or mp3) case. Using UBI on top of the
> native wear-leveling sounds like the right solution.

Yeah.  Unfortunately, SD/USB/CF cards are all in sort of an awkward spot
when it comes to things like that.  They don't expose the raw flash
underneath, and they don't provide any indication of how robust the
built in wear-leveling is.  Ugh.

> > Or you could do something slightly more sane 
> > and use:
> > 
> > 1. MMC
> > 2. block2mtd
> > 3. JFFS2
> 
> Not on a 4GB SD medium, with the current jffs2 version. The problem
> is that jffs2 doesn't scale that well, so you want a different fs.

Oh, believe me I know. :)

> Since logfs isn't stable yet, you end up with something like ext3,
> which in turn means that you need a UBI-like concept to avoid
> wearing out the blocks that store your metadata.

That just sounds like we need Jörn to get off his butt and finish logfs ;)
Seriously, until something like that is done we'll be stuck with some not
so pleasant solutions for these kind of devices.

josh
-
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: GPL vs non-GPL device drivers


On 2/17/07, Neil Brown <[EMAIL PROTECTED]> wrote:

Suppose someone created a work of fiction titled - for example -
"Picnic at Hanging Rock".  And suppose further that this someone left
some issues unresolved at the end of the story, leaving many readers
feeling that they wanted one more chapter to complete the story and
give them a sense of closure.

Suppose that a number of independent individuals wrote such a chapter
that in very different ways completed the story.

[snip]

They are derived works because they borrow the characters, the setting,
the theme, etc of the original work, and build on it.


Very well put.  That doctrine is sometimes known as "mise en scene",
and is every bit as applicable to software as to any other sort of
creative work.  When, that is, the software has characters, setting,
theme, etc.  See Micro Star v. Formgen (available anywhere Google hits
are sold).


In a similar way, people claim that any driver written for Linux will
inevitably borrow some creative content that is in Linux, via the
various interfaces that are used (and it is the nature of kernel
modules that the interface between the module and the kernel is quite
intimate).  And so, they claim that any driver written for Linux will
ipso-facto be a derived work.  The interface that ties the kernel and
the module together is certainly more intimate than the interface
between the Printer and the Toner in the Lexmark case.


Yes, people claim these things.  It's just that they're wrong.  Read
Lexmark.  Read the First Circuit opinion in Lotus v. Borland.  For
some really eye-opening dialogue, read the transcript of oral argument
before the Supreme Court in the Lotus v. Borland certioriari
proceeding.  For some long-winded but cogent discourse, read the
amicus curiae brief of the League for Programming Freedom in Lotus v.
Borland, submitted to the Supremes by one Eben Moglen.  If you can
read that and still tolerate the stench of the FSF's argument that
linking against readline means they 0wn your source code, you have a
stronger stomach than I.


Also, the "every practical way" point doesn't entirely apply.  In a
growing number of cases, it is possible to write a driver in
user-space.  This is apparently true for USB and is becoming true for
PCI.  And writing drivers as user-space programs is explicitly not a
derived work for the purposes of the Linux kernel license.


"Possible" doesn't mean "practical".  Compare Galoob and Micro Star,
Atari v. Nintendo and Sega v. Accolade.  There's a fine line, and
Judge Sutton walked up one side of it and down the other, and his
fellow panelists ably advocated drawing it either to the left or to
the right of where he had.  When the Supremes denied cert. -- in a
case where the appellate court had vacated and remanded to the
district court, meaning that they had to demonstrate that the lower
court had erred _as_a_matter_of_law_ -- they endorsed Judge Sutton's
reading of the record.  Lexmark is now settled law.
MODULE_LICENSE("GPL") on a binary-only turd is -- insofar as you can
demonstrate to the court of fact that it resembles the Lexmark fact
pattern, anywhere in the US -- as legal as an 8.5" x 14" pad of yellow
paper.  IANAL, TINLA.


So while that case sets an interesting precedent, I don't think it can
apply to the general issue of Linux kernel modules.


I mean this in the nicest possible way:  Think again.

Cheers,
- Michael
-
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: 2.6.20-ck1


mdew . writes:


On 2/16/07, Con Kolivas <[EMAIL PROTECTED]> wrote:

This patchset is designed to improve system responsiveness and interactivity.
It is configurable to any workload but the default -ck patch is aimed at the
desktop and -cks is available with more emphasis on serverspace.

Apply to 2.6.20


any benchmarks for 2.6.20-ck vs 2.6.20?


Would some -ck user on the mailing list like to perform a set of interbench 
benchmarks? They're pretty straight forward to do; see:


http://interbench.kolivas.org

--
-ck

-
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: utrace regressions (was: -mm merge plans for 2.6.21)

2007-02-17 Thread Roland McGrath

> Looking at mainline x86_64 ptrace code I think hole for u_debugreg[4]
> and [5] is also needed.

It's not.  The utrace_regset for the debugregs already has that behavior
for those two words, so mapping all 8 uarea words to the regset is fine.


Thanks,
Roland
-
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 41/44 take 2] [UBI] gluebi unit header

On Sunday 18 February 2007 03:04, Josh Boyer wrote:
> No, the MTD interface isn't flawed.  gluebi is present to make things like
> JFFS2 work on top of UBI volumes with very little adaptations.  If you go
> changing _every_ MTD user to now use either an MTD device or a native UBI
> device, then the code for those users just gets bloated.

Right, that was my point. If the MTD API in the kernel is not flawed, why
do we need the 'native' UBI interface? Just merge gluebi into UBI and
get rid of the extra abstraction.

> Assuming your SD card isn't doing wear-leveling itself within the device,
> yes that is what you would get.  

While probably all modern SD cards have some amount of wear leveling
built in, I wouldn't want to rely on that for anything but the simple
large-file-on-fatfs (jpeg or mp3) case. Using UBI on top of the
native wear-leveling sounds like the right solution.

> Or you could do something slightly more sane 
> and use:
> 
> 1. MMC
> 2. block2mtd
> 3. JFFS2

Not on a 4GB SD medium, with the current jffs2 version. The problem
is that jffs2 doesn't scale that well, so you want a different fs.
Since logfs isn't stable yet, you end up with something like ext3,
which in turn means that you need a UBI-like concept to avoid
wearing out the blocks that store your metadata.

Arnd <><
-
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: 2.6.20-ck1

2007-02-17 Thread mdew .


On 2/16/07, Con Kolivas <[EMAIL PROTECTED]> wrote:

This patchset is designed to improve system responsiveness and interactivity.
It is configurable to any workload but the default -ck patch is aimed at the
desktop and -cks is available with more emphasis on serverspace.

Apply to 2.6.20


any benchmarks for 2.6.20-ck vs 2.6.20?
-
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 15/44 take 2] [UBI] scanning unit header

On Sat, Feb 17, 2007 at 06:07:46PM -0500, Theodore Tso wrote:
> 
> This is a general comment that applies across your entire patchset.
> It would be a lot easier to review the patchset if you put the Docbook
> description of the function with the .c file instead of the .h file.
> This will also make it much more likely that when you or other people
> update the code function, that the documentation will get updated as
> well.
> 
> I'd recommend doing this along with combining all of your *.h files
> into a ubi_private.h and ubi.h file.

I agree.  Thanks for the suggestions Ted.

josh
-
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: [BUG] PATA_PCMCIA does not work

2007-02-17 Thread Komuro


Hi,

I tried the kernel 2.6.20-git14,
the pata_pcmcia drive works properly.Thanks!

But I do the "pccardctl eject"
NULL-pointer-dereference error happens.


[dmesg]
pcmcia: registering new device pcmcia1.0
SCSI subsystem initialized
libata version 2.10 loaded.
ata1: PATA max PIO0 cmd 0x0001d100 ctl 0x0001d10e bmdma 0x irq 3
scsi0 : pata_pcmcia
ata1.00: CFA: Hitachi XXM2.3.0, Rev 3.00, max PIO1
ata1.00: 62592 sectors, multi 0: LBA 
ata1.00: configured for PIO0
scsi 0:0:0:0: Direct-Access ATA  Hitachi XXM2.3.0 Rev  PQ: 0 ANSI: 5
scsi 0:0:0:0: Attached scsi generic sg0 type 0
SCSI device sda: 62592 512-byte hdwr sectors (32 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: disabled, read cache: enabled, doesn't support 
DPO or FUA
SCSI device sda: 62592 512-byte hdwr sectors (32 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: disabled, read cache: enabled, doesn't support 
DPO or FUA
 sda: sda1
sd 0:0:0:0: Attached scsi removable disk sda
pccard: card ejected from slot 1
ata1.00: disabled
BUG: unable to handle kernel NULL pointer dereference at virtual address 
0020
 printing eip:
d89f7f3e
*pde = 
Oops:  [#1]
Modules linked in: nls_ascii vfat fat sd_mod sg pata_pcmcia libata scsi_mod 
dm_mirror dm_multipath dm_mod pcmcia yenta_socket rsrc_nonstatic pcmcia_core
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246   (2.6.20-git14 #1)
EIP is at ata_host_release+0x2e/0x48 [libata]
eax: d7981884   ebx: d545b8c0   ecx: d7f6f180   edx: d545b8cc
esi:    edi:    ebp:    esp: d5bfde58
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process pccardctl (pid: 1711, ti=d5bfc000 task=c13d1540 task.ti=d5bfc000)
Stack: d545b8c0 d5ac4700 d7981a24 c0220120 d7981a24 d7981884 0006 d5ac4720 
   d5ac4660 d7981884 d887c278 d71c8dbc d7c53c48 c02201e9 0286 d7981884 
   c021d363 d7981884 d7981884 c021d7ae d798192c c021cd84 d7981884 d7981884 
Call Trace:
 [] release_nodes+0x10f/0x12f
 [] devres_release_all+0x27/0x2a
 [] __device_release_driver+0x78/0x8e
 [] device_release_driver+0x31/0x46
 [] bus_remove_device+0x6d/0x7d
 [] device_del+0x162/0x1bf
 [] device_unregister+0x8/0x10
 [] pcmcia_card_remove+0x66/0x81 [pcmcia]
 [] ds_event+0x4a/0x6d [pcmcia]
 [] kobject_get+0xf/0x13
 [] send_event+0x31/0x49 [pcmcia_core]
 [] socket_shutdown+0xc/0xb3 [pcmcia_core]
 [] socket_remove+0x1c/0x26 [pcmcia_core]
 [] pcmcia_eject_card+0x3f/0x4c [pcmcia_core]
 [] pccard_store_eject+0x1b/0x22 [pcmcia_core]
 [] pccard_store_eject+0x0/0x22 [pcmcia_core]
 [] dev_attr_store+0x27/0x2c
 [] sysfs_write_file+0xbc/0xe5
 [] sysfs_write_file+0x0/0xe5
 [] vfs_write+0x8a/0x10c
 [] sys_write+0x41/0x67
 [] sysenter_past_esp+0x5f/0x85
 [] wait_for_completion+0x33/0xaf
 ===
Code: 56 53 8b b0 50 01 00 00 eb 21 8b 5c be 34 85 db 74 18 8b 43 04 8b 90 88 
00 00 00 85 d2 74 04 89 d8 ff d2 8b 03 e8 fa 0d e6 ff 47 <3b> 7e 20 72 da 8b 46 
28 8b 90 8c 00 00 00 85 d2 74 04 89 f0 ff 
EIP: [] ata_host_release+0x2e/0x48 [libata] SS:ESP 0068:d5bfde58

Best Regards
Komuro

-
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] override build timestamp

2007-02-17 Thread Roman Zippel

Hi,

On Fri, 16 Feb 2007, Olaf Hering wrote:

> Pass a timestamp to kbuild via an enviroment variable.
> 
> TZ=UTC BUILD_TIMESTAMP=2007-01-01 make -kj O=../O vmlinux
> 
> This can be used when the kernel source is in a SCM and uname -v
> is supposed to give the commit date and not the package build time.

Is this really necessary? I don't really see the point of this.

bye, Roman
-
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 04/44 take 2] [UBI] kernel-spce API header

On Sat, Feb 17, 2007 at 05:32:19PM -0800, Greg KH wrote:
> On Sat, Feb 17, 2007 at 06:54:44PM +0200, Artem Bityutskiy wrote:
> > diff -auNrp tmp-from/include/linux/mtd/ubi.h tmp-to/include/linux/mtd/ubi.h
> > --- tmp-from/include/linux/mtd/ubi.h1970-01-01 02:00:00.0 
> > +0200
> > +++ tmp-to/include/linux/mtd/ubi.h  2007-02-17 18:07:26.0 +0200
> > @@ -0,0 +1,391 @@
> > +/*
> > + * Copyright (c) International Business Machines Corp., 2006
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> 
> Are you sure this is the proper license for new kernel code coming from
> IBM these days?  You might want to go verify that the "or any later
> version" is allowed right now...

The code was actually released to the community a while ago.  But point noted
and we'll look into it.  Thanks for pointing it out Greg.

josh
-
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 41/44 take 2] [UBI] gluebi unit header

On Sat, Feb 17, 2007 at 10:14:54PM +0100, Arnd Bergmann wrote:
> On Saturday 17 February 2007 17:57, Artem Bityutskiy wrote:
> > + * This unit is responsible for emulating MTD devices on top of UBI 
> > devices.
> > + * This sounds strange, but it is in fact quite useful to make legacy 
> > software
> > + * work on top of UBI. New software should use native UBI API instead.
> > + *
> > + * Gluebi emulated MTD devices of "MTD_UBIVOLUME" type. Their minimal I/O 
> > unit
> > + * size (mtd->writesize) is equivalent to the underlying flash minimal I/O
> > + * unit. The eraseblock size is equivalent to the logical UBI volume 
> > eraseblock
> > + * size.
> 
> This approach doesn't seem to make sense at all. If the MTD device interface
> is flawed, the right approach should be to fix that instead. After all,
> there are not many users of the MTD interface, so you should be able to
> adapt them.

No, the MTD interface isn't flawed.  gluebi is present to make things like
JFFS2 work on top of UBI volumes with very little adaptations.  If you go
changing _every_ MTD user to now use either an MTD device or a native UBI
device, then the code for those users just gets bloated.

> In fact, I would expect that there is much more reason to merge the existing
> MTD interface with the block interface in the kernel, but you now introduce
> a third interface that is unrelated to the first two, and make another
> conversion to convert it back?
> 
> Let's assume I want to use the wear levelling capabilities of UBI on top
> of an SD card, and use the ext3 file system on top of it. I get a stack of
> 
> 1. MMC
> 2. block2mtd
> 3. UBI
> 4. gluebi
> 5. mtdblock
> 6. VFS

Assuming your SD card isn't doing wear-leveling itself within the device,
yes that is what you would get.  Or you could do something slightly more sane
and use:

1. MMC
2. block2mtd
3. JFFS2

> when in an ideal world, it should just be
> 
> 1. MMC
> 2. UBI
> 3. VFS

This could perhaps still be done.  UBI has a general concept of an io_unit
so theoretically it could be adapted to work with the block layer in the
kernel.

josh
-
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: exporting LANG=C (Re: [PATCH] override build timestamp)

2007-02-17 Thread Roman Zippel

Hi,

On Sat, 17 Feb 2007, Oleg Verych wrote:

> could you make separate patch with exporting 'LANG=C' on the very
> beginning and delete all other occurrences of it? It's a C header file
> generation and afaik, it must be ASCII.

Bad idea, most user output should be localized (even if it's only utf-8) 
and some kconfig targets have explicit locale support.

bye, Roman
-
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: GPL vs non-GPL device drivers

2007-02-17 Thread Trent Waddington


On 2/18/07, David Lang <[EMAIL PROTECTED]> wrote:

by this same logic the EULA's that various commercial vendors use are
completely valid,

it doesn't matter what the intent is if it's not a legal thing to require.


Yes, it does matter.. the author of the work has defined the terms
under which you may use it.. if you don't like it, don't use the work.

There's a name for people who look at everything in terms of "you
can't make me".

Trent
-
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: [mmc] incorrect behavior on resume

2007-02-17 Thread Alex Dubov

--- Pavel Machek <[EMAIL PROTECTED]> wrote:

> On Sun 2007-02-18 00:35:33, Pierre Ossman wrote:
> > Alex Dubov wrote:
> > > And today: yet another problem with mmc.
> > > It so happens that after resume mmc layer issues requests to the device 
> > > before
> mmc_resume_host is
> > > called at all. Moreover, this prevents the machine from resuming, unless 
> > > worked around,
> because
> > > software timer does not work at this stage of the resume and interrupts 
> > > may not be delivered
> (if
> > > card was removed, for example).
> > 
> > Now this sounds incredibly broken. A child device should never be resumed 
> > before
> > its parent. Pavel, can you comment?
> 
> No, child devices should not be resumed before their parents. Is it
> true child?
> 
> What bus is mmc on? Timer should be resumed fairly early...?
> 
> Can you confirm that rmmod/insmod of mmc around suspend fixes the issue?
> 
> But this is greg's area.
It sure does - if I'll do "rmmod mmc" I'd be forced to remove my driver as well 
(symbol
dependency) and the problem will magically disappear.

The problem here is that mmc_block's device is a child of real device (tifm_dev 
here), so it gets
resumed right after it. However, it correct functioning depends on mmc_core, 
which must be
manually resumed (mmc_resume_host). Therefore, I think this is purely mmc's 
problem.

Bored stiff? Loosen up... 
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front
-
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: GPL vs non-GPL device drivers

2007-02-17 Thread David Lang

On Sun, 18 Feb 2007, Trent Waddington wrote:

Despite which, legal bullshit is best left for lawyers.. the *intent*
of the GPL is that if you distribute *any* changes, extensions or
plugins for a GPL work, you do so under the GPL. The law may not
allow for this to be enforced, but it shouldn't need to.. one should
read the GPL as 100% enforceable and follow it without looking for
"loop holes" as it is the stated desire of how the author of the code
wants you to use his work. Looking for loop holes, and worse yet,
discussing those loop holes in a public place, is just insulting.

by this same logic the EULA's that various commercial vendors use are completely
valid, and the e-mail sigs that make you liable for reading e-mail are also
valid.

it doesn't matter what the intent is if it's not a legal thing to require.

in the case of the GPL the key is the border of being a drivitive work or not.

some people would like to interpret this so broadly as to make it impossible to
run userspace code on a GPL OS, however everyone who is sane recognises that
this is beyond the boundry.

in the case of kernel modules, this is very murky territory, and it's one that
nobody has felt compelled (and confident enough in the outcome) to litigate.

I've heard many people express their opinion on what it takes to be a derivitive
work, but very few lawyers

one of the few that I have seen is from IBM's lawyers in the SCO case

quote:
Second, SCO's claim that Dynix/ptx is a "derivative work" within the meaning of SCO's definition is likewise unhelpful
to its motion. As an initial matter, the assertion is untenable because it is based on a definition of "derivative works
based on such SOFTWARE PRODUCT" that is unsupported and in dispute (as stated above). Moreover, SCO fails even to identify
the versions and components of the SOFTWARE PRODUCT and Dynix/ptx to which SCO refers. It is impossible to determine whether one
product is a derivative work of another product without specific reference to what is at issue. See Gates Rubber Co. v. Bando
Chem. Indus., 9 F.3d 823, 834 (10th Cir. 1993) (indicating that, in determining whether one work is a derivative of another, a
court should "dissect", "examine", and "compare" the two specific works in question).

To support the proposition that Dynix/ptx is a derivative work of UNIX System V, SCO relies entirely on the testimony of its
experts, Mr. Marc Rochkind and Dr. Thomas Cargill. However, as SCO admits, Mr. Rochkind's testimony is based solely on a
"computer-science perspective". (SCO Br. at 14.) There is no basis for importing into the Agreement the perspective of
a single computer scientist offered two decades after the Agreement was signed and providing no objective standard for his
testimony. 4 See Fed. R. Evid. 702 (requiring that expert testimony be "the product of reliable principles and
methods"). The term "derivative work" is a term of art under copyright law and is explicitly defined in the
Copyright Act as "a work that is based on (or derived from) one or more already existing works. . . in which the editorial
revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship". 17
U.S.C.A. ? 101 (West 2006). In the absence of a provision in the Agreement to the contrary, the term "derivative work"
should be understood to have the meaning that it has under federal law. One of IBM's experts, Professor Randall Davis, has
provided unrebutted testimony that the portions of Dynix specifically challenged by SCO are not derivative works of UNIX System
V. (Ex. 181 ?50.)

this seems to be saying that the boundries of derivitive work as far as
copyright goes are much more limited then just about anyone in computer science
would define the term

David Lang

Re: [PATCH 04/44 take 2] [UBI] kernel-spce API header

2007-02-17 Thread Greg KH

On Sat, Feb 17, 2007 at 06:54:44PM +0200, Artem Bityutskiy wrote:
> diff -auNrp tmp-from/include/linux/mtd/ubi.h tmp-to/include/linux/mtd/ubi.h
> --- tmp-from/include/linux/mtd/ubi.h  1970-01-01 02:00:00.0 +0200
> +++ tmp-to/include/linux/mtd/ubi.h2007-02-17 18:07:26.0 +0200
> @@ -0,0 +1,391 @@
> +/*
> + * Copyright (c) International Business Machines Corp., 2006
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.

Are you sure this is the proper license for new kernel code coming from
IBM these days?  You might want to go verify that the "or any later
version" is allowed right now...

thanks,

greg k-h
-
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: GPL vs non-GPL device drivers

2007-02-17 Thread Trent Waddington


On 2/17/07, David Schwartz <[EMAIL PROTECTED]> wrote:

I don't think that's grey at all. I think it's perfectly clear that linking
cannot create a derivative work. No automated process can -- it takes
creativity to create a derivative work. (That doesn't mean that just because
you can link A to B, a cannot be a derivative work of B or vice verse, of
course. It just means that if A is not a derivative work of B, linking A to
B cannot make it so, nor can the result be a derivative work.)


Sigh.  VJ is distributing the linux kernel with proprietary
extensions.  If you want to argue that the proprietary extensions in
isolation are not derivative works of the kernel, fine, you might have
a case, but the combined work, which VJ is distributing is *clearly* a
derivative work and must be distributed under the terms of the GPL.

Despite which, legal bullshit is best left for lawyers.. the *intent*
of the GPL is that if you distribute *any* changes, extensions or
plugins for a GPL work, you do so under the GPL.  The law may not
allow for this to be enforced, but it shouldn't need to.. one should
read the GPL as 100% enforceable and follow it without looking for
"loop holes" as it is the stated desire of how the author of the code
wants you to use his work.  Looking for loop holes, and worse yet,
discussing those loop holes in a public place, is just insulting.

Trent
-
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/

Linux 2.6.16.41

2007-02-17 Thread Adrian Bunk

Location:
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/

git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git


Changes since 2.6.16.40:

Adrian Bunk (4):
  Revert "[Bluetooth] Fix compat ioctl for BNEP, CMTP and HIDP"
  [ALSA] echo3g_dsp.c shouldn't include #include 
  Linux 2.6.16.41-rc1
  Linux 2.6.16.41

Al Viro (1):
  [TCP]: struct tcp_sack_block annotations

Baruch Even (1):
  TCP: Fix sorting of SACK blocks.

Bob Breuer (1):
  SPARC32: Fix over-optimization by GCC near ip_fast_csum.

Daniel Walker (1):
  [ATM]: Fix for crash in adummy_init()

David S. Miller (1):
  AF_PACKET: Check device down state before hard header callbacks.

Eric W. Biederman (1):
  DECNET: Handle a failure in neigh_parms_alloc (take 2)

Herbert Xu (1):
  [NETFILTER]: Clear GSO bits for TCP reset packet

Hugh Dickins (1):
  fix umask when noACL kernel meets extN tuned for ACLs

Jeff Dike (1):
  uml: fix signal frame alignment

Jiri Bohac (1):
  [IPX]: Fix NULL pointer dereference on ipx unload

John Heffner (1):
  [TCP]: Don't apply FIN exception to full TSO segments.

Linus Torvalds (1):
  Fix up CIFS for "test_clear_page_dirty()" removal

Masayuki Nakagawa (1):
  TCP: skb is unexpectedly freed.


 Makefile   |2 
 arch/um/sys-i386/signal.c  |2 
 arch/um/sys-x86_64/signal.c|5 +
 fs/cifs/file.c |   26 -
 fs/ext2/super.c|4 +
 fs/ext3/super.c|4 +
 include/asm-sparc/checksum.h   |2 
 include/linux/tcp.h|5 +
 net/atm/common.c   |3 -
 net/bluetooth/bnep/sock.c  |   67 ++--
 net/bluetooth/cmtp/sock.c  |   33 
 net/bluetooth/hidp/sock.c  |   78 -
 net/decnet/dn_dev.c|   11 +++-
 net/ipv4/netfilter/ip_nat_helper.c |2 
 net/ipv4/netfilter/ipt_REJECT.c|3 +
 net/ipv4/tcp_input.c   |   17 +++---
 net/ipv4/tcp_output.c  |3 -
 net/ipx/af_ipx.c   |   24 +---
 net/packet/af_packet.c |   16 ++---
 sound/pci/echoaudio/echo3g_dsp.c   |2 
 20 files changed, 111 insertions(+), 198 deletions(-)


-
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/

please pull from the trivial tree

2007-02-17 Thread Adrian Bunk

Linus, please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial.git


This tree contains the following:

Adrian Bunk (1):
  correct a dead URL in the IP_MULTICAST help text

Erik Hovland (1):
  trivial documentation patch for platform.txt

James Nelson (1):
  Documentation/kernel-docs.txt update.

Jesper Juhl (2):
  Remove duplicate listing of Cris arch from README
  update I/O sched Kconfig help texts - CFQ is now default, not AS.

John Daiker (1):
  add a help text for BLK_DEV_GENERIC

Matthew Wilcox (1):
  fix SCSI_SCAN_ASYNC help text

Nicolas Kaiser (1):
  arch/cris: typo in KERN_INFO

Patrick Pletscher (1):
  kernel/printk.c: comment fix

Randy Dunlap (2):
  doc: make doc. for maxcpus= more visible
  kbuild: more doc. cleanups

Robert P. J. Day (9):
  kbuild: Replace remaining "depends" with "depends on"
  Various typo fixes.
  Use ARRAY_SIZE() macro in i386 relocs.c file
  Replace remaining references to "driverfs" with "sysfs".
  Remove useless FIND_FIRST_BIT() macro from cardbus.c.
  Correct trivial typo in log2.h.
  drivers/scsi/a100u2w.c: trivial typo patch
  Fix misspellings of "agressive".
  Fix comment typo "spin_lock_irqrestore".

Shane Shrybman (1):
  drivers/net/eexpress.c: remove duplicate comment

Simon Depiets (1):
  fix the BAYCOM_SER_HDX help text

Tobias Klauser (1):
  Storage class should be before const qualifier

Uwe Kleine-König (1):
  Fix typos concerning hierarchy

Willy Tarreau (1):
  rio: typo in bitwise AND expression.


 Documentation/driver-model/platform.txt   |4 
 Documentation/filesystems/sysfs-pci.txt   |2 
 Documentation/kbuild/makefiles.txt|   28 -
 Documentation/kernel-docs.txt |  257 ++
 Documentation/kernel-parameters.txt   |9 
 Documentation/sh/new-machine.txt  |4 
 Documentation/video4linux/bttv/Insmod-options |2 
 README|2 
 arch/arm/Kconfig  |2 
 arch/arm/mm/Kconfig   |2 
 arch/cris/arch-v10/drivers/pcf8563.c  |2 
 arch/cris/arch-v32/drivers/pcf8563.c  |2 
 arch/i386/boot/compressed/relocs.c|9 
 arch/i386/kernel/topology.c   |2 
 arch/i386/oprofile/nmi_int.c  |   14 
 arch/ia64/kernel/perfmon.c|2 
 arch/m32r/lib/usercopy.c  |4 
 arch/m68knommu/platform/5307/timers.c |2 
 arch/mips/kernel/machine_kexec.c  |4 
 arch/parisc/kernel/topology.c |2 
 arch/powerpc/kernel/rtas.c|2 
 arch/powerpc/mm/numa.c|2 
 arch/sh/kernel/cpu/sh2/clock-sh7619.c |4 
 arch/sh/kernel/cpu/sh2a/clock-sh7206.c|4 
 arch/v850/Kconfig |2 
 arch/x86_64/kernel/time.c |2 
 block/Kconfig.iosched |9 
 drivers/base/cpu.c|2 
 drivers/base/node.c   |2 
 drivers/char/rio/rio_linux.c  |2 
 drivers/i2c/busses/i2c-ali1535.c  |2 
 drivers/i2c/busses/i2c-ali15x3.c  |2 
 drivers/i2c/busses/i2c-amd756.c   |2 
 drivers/i2c/busses/i2c-amd8111.c  |2 
 drivers/i2c/busses/i2c-i801.c |2 
 drivers/i2c/busses/i2c-piix4.c|2 
 drivers/i2c/busses/i2c-sis5595.c  |2 
 drivers/i2c/busses/i2c-sis630.c   |2 
 drivers/i2c/busses/i2c-sis96x.c   |2 
 drivers/i2c/busses/i2c-via.c  |2 
 drivers/ide/Kconfig   |3 
 drivers/ieee1394/ohci1394.c   |2 
 drivers/infiniband/hw/ipath/ipath_iba6110.c   |2 
 drivers/infiniband/hw/ipath/ipath_iba6120.c   |2 
 drivers/input/serio/libps2.c  |2 
 drivers/isdn/i4l/isdn_ppp.c   |2 
 drivers/media/dvb/dvb-core/dvb_frontend.c |2 
 drivers/media/dvb/frontends/dib3000mb.c   |2 
 drivers/media/video/pvrusb2/pvrusb2-audio.c   |2 
 drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.c |2 
 drivers/media/video/pvrusb2/pvrusb2-std.c |4 
 drivers/media/video/pvrusb2/pvrusb2-tuner.c   |2 
 drivers/media/video/pvrusb2/pvrusb2-video-v4l.c   |2 
 drivers/media/video/pvrusb2/pvrusb2-wm8775.c  |2 
 drivers/net/e1000/e1000_hw.h  |2 
 drivers/net/eexpress.c|7 
 drivers/net/hamradio/Kconfig  |3

Re: mm snapshot broken-out-2007-02-17-03-25.tar.gz uploaded

On Sun, 18 Feb 2007 01:53:16 +0100 Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> > I wonder why.  I can't make it happen on two machines, scsi, sata and IDE. 
> > And afaict git-block isn't changed from 2.6.20-mm1.
> > 
> > Are you sure?
> > 
> 
> Absolutely? No.
> 
> Do you believe in statistic?

devoutly.

We don't have much to go on, alas.  Could you please provide the .config
and a description of your setup?  What sort of disk controller, what sort
of disks, which IO scheduler, etc?

-
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: mm snapshot broken-out-2007-02-17-03-25.tar.gz uploaded

2007-02-17 Thread Michal Piotrowski

Andrew Morton napisał(a):
> On Sat, 17 Feb 2007 23:23:17 +0100 "Michal Piotrowski" <[EMAIL PROTECTED]> 
> wrote:
> 
>> On 17/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
>>> On Sat, 17 Feb 2007 20:58:55 +0100 "Michal Piotrowski" <[EMAIL PROTECTED]> 
>>> wrote:
>>>
 On 17/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sat, 17 Feb 2007 19:36:39 +0100 Michal Piotrowski <[EMAIL PROTECTED]> 
> wrote:
>
>> [EMAIL PROTECTED] napisał(a):
>>> The mm snapshot broken-out-2007-02-17-03-25.tar.gz has been uploaded to
>>>
>>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-02-17-03-25.tar.gz
>>>
>> BUG: unable to handle kernel paging request at virtual address 6b6b6b6f
> hm, how did you make that happen?
>
 I don't know. I can reproduce this bug.

>>> Could you bisect it please?  The patches to suspect are
>> [..]
>>> For git-block, do
>>>
>>> quilt pop 
>>> scsi-megaraid_sas-return-sync-cache-call-with-success.patch
>>>
>>> and retest.  If that doesn't fail, do
>>>
>>> quilt push git-block-xfs-barriers-broke.patch
>>>
>>> and retest.
>>>
>> Ok, this must be a git-block-* stuff.
>>
>> Jens, can you take a look at this bug?
>> http://www.ussg.iu.edu/hypermail/linux/kernel/0702.2/0646.html
>>
> 
> I wonder why.  I can't make it happen on two machines, scsi, sata and IDE. 
> And afaict git-block isn't changed from 2.6.20-mm1.
> 
> Are you sure?
> 

Absolutely? No.

Do you believe in statistic?

10 clean boots
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-02-17-03-25/10_clean_boots_without_git_block_stuff.txt

10 boots with git-block-*
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/broken-out-2007-02-17-03-25/10_boots_with_git_bloack_stuff.txt

cat 10_boots_with_git_bloack_stuff.txt | grep "BUG: unable to handle kernel 
paging request at virtual address 6b6b6b6f" | wc -l
1

cat 10_boots_with_git_bloack_stuff.txt | grep "EIP"
EIP:0060:[]Not tainted VLI
EIP is at blk_unplug_current+0x4d/0x132
EIP: [] blk_unplug_current+0x4d/0x132 SS:ESP 0068:f6eabd54
EIP:0060:[]Not tainted VLI
EIP is at blk_unplug_current+0x4d/0x132
EIP: [] blk_unplug_current+0x4d/0x132 SS:ESP 0068:f6eabaf8
EIP:0060:[]Not tainted VLI
EIP is at __make_request+0xeb/0x2e6
EIP: [] __make_request+0xeb/0x2e6 SS:ESP 0068:f7e35cc0
EIP:0060:[]Not tainted VLI
EIP is at bio_attempt_back_merge+0x1b/0xb2
EIP: [] bio_attempt_back_merge+0x1b/0xb2 SS:ESP 0068:f6f31b88




BUG: unable to handle kernel NULL pointer dereference at virtual address 
0108
 printing eip:
c01df352
*pde = 
Oops:  [#1]
PREEMPT SMP
last sysfs file: /block/sda/removable
Modules linked in: snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy 
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss 
snd_pcm evdev intel_agp snd_timer snd soundcore agpgart skge sk98lin 
snd_page_alloc i2c_i801 8139too mii ide_cd cdrom rtc unix
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202   (2.6.20 #8)
EIP is at blk_unplug_current+0x4d/0x132
eax: f7c2bce8   ebx: 0001   ecx: f6eab000   edx: c56deae0
esi: f7c2bcd4   edi:    ebp: f6eabd90   esp: f6eabd54
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process vol_id (pid: 1313, ti=f6eab000 task=f6f800b0 task.ti=f6eab000)
Stack:  f6f800b0 c03159e5  f6eabd84 c013ca75 c6004fb0 f7c2bce8
   0046 c6004fb0 c6004fb0 0282 0001 c044bda0 05bd5d80 f6eabda4
   c031377a f6eabdd0 f6eabdd0 c6004fb0 f6eabdac c01554d6 f6eabdc4 c03138d6
Call Trace:
 [] show_trace_log_lvl+0x1a/0x2f
 [] show_stack_log_lvl+0x9d/0xa5
 [] show_registers+0x1ed/0x32c
 [] die+0x11d/0x234
 [] do_page_fault+0x43a/0x50d
 [] error_code+0x7c/0x84
 [] io_schedule+0x3d/0x9a
 [] sleep_on_page+0x8/0xc
 [] __wait_on_bit_lock+0x30/0x59
 [] __lock_page+0x53/0x5a
 [] do_generic_mapping_read+0x1cd/0x41e
 [] generic_file_aio_read+0x16a/0x197
 [] do_sync_read+0xc2/0xff
 [] vfs_read+0xad/0x136
 [] sys_read+0x3d/0x61
 [] syscall_call+0x7/0xb
 ===
Code: 75 04 0f 0b eb fe 48 89 46 0c 85 c0 0f 85 f6 00 00 00 8b 7e <4>AC'97 0 
analog subsections not ready
1c c7 46 1c 00 00 00 00 8d 46 14 89 45 e0 39 46 14 0f 84 c3 00 00 00 <8b> 87 08 
01 00 00 e8 c8 62 13 00 c7 45 e4 00 00 00 00 8b 5e 14
EIP: [] blk_unplug_current+0x4d/0x132 SS:ESP 0068:f6eabd54
BUG: unable to handle kernel NULL pointer dereference at virtual address 
0108
 printing eip:
c01df352
*pde = 
Oops:  [#2]
PREEMPT SMP
last sysfs file: /block/sdb/dev
Modules linked in: snd_intel8x0 snd_ac97_codec ac97_bus snd_seq_dummy 
snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss 
snd_pcm evdev intel_agp snd_timer snd soundcore agpgart skge sk98lin 
snd_page_alloc i2c_i801 8139too mii ide_cd cdrom rtc unix
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202   (2.6.20 #8)
EIP is at blk_unplug_current+0x4d/0x132
eax:

Re: [PATCH 2.6.21-rc1] powerpc: Make of_device_uevent() compatible with ibmebus

On Sat, 2007-02-17 at 19:21 -0500, Joachim Fenkes wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote on 17.02.2007 
> 16:56:39:
> 
> > On Sat, 2007-02-17 at 17:28 +0100, Hoang-Nam Nguyen wrote:
> > > ibmebus has a fake root device that's not associated with an ofdt 
> node.
> > > Filter out any such devices in of_device_uevent().
> > 
> > Doh ! You are creating an of_device with no attached device-node ? That
> > is totally evil ! Why do you need that ?
> 
> The driver creates a fake "ibmebus" device so all ibmebus based devices 
> have
> a common parent device -- the vio bus does the same.
> 
> What do you think about linking this device to the device tree "/" node? 
> All
> ibmebus-based devices are linked to dt nodes residing directly beneath 
> "/",
> so the mapping would fit.

No. If you do that, it shouldn't be an of_device based device.

If you want then to be below a common parent, then create that parent of
a basic struct device type, that sort of thing. You should never
instanciate an of_device that has a NULL device node.

vio is different since it's not a "subclass" of of_device though I tend
to also disagree with the way it does things.

It's a generic problem with sysfs, I agree it somewhat sucks.

Ben.


-
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 15/44 take 2] [UBI] scanning unit header

On Sat, Feb 17, 2007 at 06:55:40PM +0200, Artem Bityutskiy wrote:
> +/**
> + * ubi_scan_erase_peb - erase a physical eraseblock.
> + *
> + * @ubi: the UBI device description object
> + * @si: a pointer to the scanning information
> + * @pnum: physical eraseblock number to erase;
> + * @ec: erase counter value to write (%NAND_SCAN_UNKNOWN_EC if it is unknown)
> + *
> + * This function erases physical eraseblock 'pnum', and writes the erase
> + * counter header to it. This function should only be used on UBI device
> + * initialization stages, when the EBA unit had not been yet initialized. 
> This
> + * function returns zero in case of success and a negative error code in case
> + * of failure.
> + */

This is a general comment that applies across your entire patchset.
It would be a lot easier to review the patchset if you put the Docbook
description of the function with the .c file instead of the .h file.
This will also make it much more likely that when you or other people
update the code function, that the documentation will get updated as
well.

I'd recommend doing this along with combining all of your *.h files
into a ubi_private.h and ubi.h file.

Regards,

- Ted
-
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 00/44 take 2] [UBI] Unsorted Block Images

On Sat, Feb 17, 2007 at 06:54:24PM +0200, Artem Bityutskiy wrote:
> The structure of the UBI code is very simple. Whole UBI consists of units.
> Each unit has one .c file which implements it and one .h file which defines
> the interface of this unit. So I've split the UBI code so that there is
> a distinct patch for each unit header and implementations. Plus there are
> several patches like JFFS2 support, user-space-visible headers, etc.
> To realize what is the unit responsible for, glance at its header - there
> is a short description.

Artem,

This patch introduces the Makefile before any of the source
files, which means it will break "git bisect" operations.  Could you
please refactor your patches so that the tree will build after any
point in your patch series?  

BTW, I'm not personally found of having a separate .h file for
every .c file; in my mind a much better division is a public and
private header file.

- Ted
-
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: serial and tty driver

On Sat, Feb 17, 2007 at 12:24:22PM -0600, Paul Fulghum wrote:
> Mockern wrote:
> >I have a question, what is really difference between serial and tty
> >drivers?
> >
> >As I understand tty is high level and communicates with user space. 
> 
> The serial core implements many of the details of a tty
> driver in a common place so that individual hardware drivers
> (serial drivers) only need implement the hardware specific code.
> 
> This prevents duplicating tty logic in many drivers,
> with the possibility of mistakes/inconsistency in the
> different tty drivers.
> 
> The stand alone tty drivers are mostly legacy code from
> the time before serial core that have not been ported
> to be a serial drivers.

Not necessarily; there are a number of tty drivers, such as the
console drivers and pseudo-tty drivers that have absolutely nothing to
do with an RS-232 port.

On the other side of the argument, another factorization of the layers
that might have made sense was to move the functionality to the
high-level tty layer (or in the case of hangup code, all the way up to
the VFS layer as a generic sys_revoke functionality), but the reason
why it didn't is largely historical.

- Ted
-
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 07/44 take 2] [UBI] misc unit header

On Sat, Feb 17, 2007 at 06:54:59PM +0200, Artem Bityutskiy wrote:
> diff -auNrp tmp-from/drivers/mtd/ubi/misc.h tmp-to/drivers/mtd/ubi/misc.h
> --- tmp-from/drivers/mtd/ubi/misc.h   1970-01-01 02:00:00.0 +0200
> +++ tmp-to/drivers/mtd/ubi/misc.h 2007-02-17 18:07:26.0 +0200
> @@ -0,0 +1,146 @@
> +#define xquotise(s) #s
> +#define quotise(s) xquotise(s)

Nothing in your patch series uses this, and it's identical to
stringify().   Please remove?

> +/**
> + * rb_for_each_entry - walk an RB-tree.
> + *
> + * @rb: a pointer to type 'struct rb_node' to to use as a loop counter
> + * @pos: a pointer to RB-tree entry type to use as a loop counter
> + * @root: RB-tree's root
> + * @member: the name of the 'struct rb_node' within the RB-tree entry
> + */
> +#define rb_for_each_entry(rb, pos, root, member)...

Shouldn't this be added to include/linux/rbtree.h?

> +/**
> + * strdup_len - duplicate a string with known length.
> + *
> + * @str: original string
> + * @len: the length of the string
> + */
> +char *strdup_len(const char *str, int len);

I'm not sure this should be polluting the kernel symbol namespace,
especially since the implementation calls ubi_assert()

It's not clear the assertion is all that useful, but if you must have
it, why not do the check as an inline (with the assertion normally
turned off), and then call out to kmemdup()?

- Ted
-
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: 2.6.20-ck1


Radoslaw Szkodzinski writes:


On 2/18/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

Generally, the penalties for getting this stuff wrong are very very high:
orders of magnitude slowdowns in the right situations.  Which I suspect
will make any system-wide knob ultimately unsuccessful.



Yes, they were. Now, it's an extremely light and well-tuned patch.
kprefetchd should only run on a totally idle system now.


The ideal way of getting this *right* is to change every application in the
world to get smart about using sync_page_range() and/or posix_fadvise(),
then to add a set of command-line options to each application in the world
so the user can control its pagecache handling.


We don't live in a perfect world. :-)


Obviously that isn't practical.  But what _could_ be done is to put these
pagecache smarts into glibc's read() and write() code.  So the user can do:

MAX_PAGECACHE=4M MAX_DIRTY_PAGECACHE=2M rsync foo bar

This will provide pagecache control for pretty much every application.  It
has limitations (fork+exec behaviour??) but will be useful.


Not too useful for interactive applications with unpredictable memory
consumption behaviour, where swap-prefetch still helps.


Hey Radoslaw, your points are valid but Andrew was referring to the tail 
large files patch in this email.


--
-ck

-
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: [ck] Re: 2.6.20-ck1

2007-02-17 Thread Radoslaw Szkodzinski


On 2/18/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

Generally, the penalties for getting this stuff wrong are very very high:
orders of magnitude slowdowns in the right situations.  Which I suspect
will make any system-wide knob ultimately unsuccessful.



Yes, they were. Now, it's an extremely light and well-tuned patch.
kprefetchd should only run on a totally idle system now.


The ideal way of getting this *right* is to change every application in the
world to get smart about using sync_page_range() and/or posix_fadvise(),
then to add a set of command-line options to each application in the world
so the user can control its pagecache handling.


We don't live in a perfect world. :-)


Obviously that isn't practical.  But what _could_ be done is to put these
pagecache smarts into glibc's read() and write() code.  So the user can do:

MAX_PAGECACHE=4M MAX_DIRTY_PAGECACHE=2M rsync foo bar

This will provide pagecache control for pretty much every application.  It
has limitations (fork+exec behaviour??) but will be useful.


Not too useful for interactive applications with unpredictable memory
consumption behaviour, where swap-prefetch still helps.


A kernel-based solution might use new rlimits, but would not be as flexible
or successful as a libc-based one, I suspect.

-
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: 2.6.20-ck1


Andrew Morton writes:


On Sun, 18 Feb 2007 08:00:06 +1100 Con Kolivas <[EMAIL PROTECTED]> wrote:


On Sunday 18 February 2007 05:45, Chuck Ebbert wrote:
...
> But the one I like, mm-filesize_dependant_lru_cache_add.patch,
> has an on-off switch.
>

...

Do you still want this patch for mainline?... 


Don't think so.  The problems I see are:

- It's a system-wide knob.  In many situations this will do the wrong
  thing.  Controlling pagecache should be per-process.

- Its heuristics for working out when to invalidate the pagecache will be
  too much for some situations and too little for others.

- Whatever we do, there will be some applications in some situations
  which are hurt badly by changes like this: they'll do heaps of extra IO.


Generally, the penalties for getting this stuff wrong are very very high:
orders of magnitude slowdowns in the right situations.  Which I suspect
will make any system-wide knob ultimately unsuccessful.


Rest assured I wasn't interested in pushing this patch for mainline anyway.

-ck users can also rest assured about this patch for the following reasons:

- The usage pattern on a desktop will guarantee that this patch helps 99.9% 
of the time rather than hurts. Therefore, this feature is enabled by default 
on -ck.


- With the usage pattern on a server of any sort, it will be unknown whether 
this patch helps or harms. Therefore, this feature is disabled by default on 
-cks.


--
-ck

-
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: [mmc] incorrect behavior on resume

2007-02-17 Thread Pavel Machek

On Sun 2007-02-18 00:35:33, Pierre Ossman wrote:
> Alex Dubov wrote:
> > And today: yet another problem with mmc.
> > It so happens that after resume mmc layer issues requests to the device 
> > before mmc_resume_host is
> > called at all. Moreover, this prevents the machine from resuming, unless 
> > worked around, because
> > software timer does not work at this stage of the resume and interrupts may 
> > not be delivered (if
> > card was removed, for example).
> 
> Now this sounds incredibly broken. A child device should never be resumed 
> before
> its parent. Pavel, can you comment?

No, child devices should not be resumed before their parents. Is it
true child?

What bus is mmc on? Timer should be resumed fairly early...?

Can you confirm that rmmod/insmod of mmc around suspend fixes the issue?

But this is greg's area.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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 2.6.21-rc1] powerpc: Make of_device_uevent() compatible with ibmebus

2007-02-17 Thread Joachim Fenkes

Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote on 17.02.2007 
16:56:39:

> On Sat, 2007-02-17 at 17:28 +0100, Hoang-Nam Nguyen wrote:
> > ibmebus has a fake root device that's not associated with an ofdt 
node.
> > Filter out any such devices in of_device_uevent().
> 
> Doh ! You are creating an of_device with no attached device-node ? That
> is totally evil ! Why do you need that ?

The driver creates a fake "ibmebus" device so all ibmebus based devices 
have
a common parent device -- the vio bus does the same.

What do you think about linking this device to the device tree "/" node? 
All
ibmebus-based devices are linked to dt nodes residing directly beneath 
"/",
so the mapping would fit.

Cheers,
  Joachim

---
Joachim Fenkes  --  eHCA Linux Driver Developer and Hardware Tamer 
extraordinaire
IBM Deutschland Entwicklung GmbH  --  Dept. 3627 (I/O Firmware Development 
2)
Schoenaicher Strasse 220  --  71032 Boeblingen  --  Germany
eMail: [EMAIL PROTECTED]  --  Phone: +49 7031 16 1239 

Vorsitzender des Aufsichtsrats: Johann Weihen  --  Geschäftsführung: 
Herbert Kircher
Sitz der Gesellschaft: Böblingen  --  Registergericht: Amtsgericht 
Stuttgart, HRB 243294

-
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: ADC driver with I2C interface

2007-02-17 Thread Marc Dietrich



did you tried www.comedi.org ?

Am Sunday 18 February 2007 00:18 schrieb Mockern:
> Hello,
>
> Where I can grab an example of ADC driver with I2C interface?
> -
> 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/

-- 
"It is a noble cause that we defend and not particular interests."
 Lord Arthur Ponsonby, "Falsehood in Wartime: Propaganda Lies 
of the First 
World War", 1928
-
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: GPL vs non-GPL device drivers


On 2/17/07, Giuseppe Bilotta <[EMAIL PROTECTED]> wrote:

Which shows how that case is different from writing Linux drivers. For
example, looking at the example the OP was himself proposing a few
alternative approaches to work around the limitation they were hitting:
could just switch to static major/minors instead of dynamics ones, they
could skip sysfs, or they could even reimplement something like sysfs
themselves, or whatever other interface they deem useful for the purpose of
plopping in their own binary blob on top of it, sort of like what nVidia
and ATi do for their stuff.


Or they could run:
   find . -type f -exec perl -i.bak -pe 's/EXPORT_SYMBOL_GPL/EXPORT_SYMBOL/g'
and be done with it.  Or even just MODULE_LICENSE("GPL") in their
module -- that's not "lying about the module license", it's "doing the
minimum necessary in order to interoperate efficiently with the
kernel".  Atari v. Nintendo is still good law, but _only_ to the
extent that it does not conflict with Lexmark, which now has the seal
of Supreme Court approval.  And (IMHO, IANAL) if writing
MODULE_LICENSE("GPL") is obviously the only remotely efficient way to
achieve the goal of interoperation with the kernels that people
already have on their systems, through the documented, tested,
currently recommended APIs (like sysfs), then you have a Sega / Altai
/ Lexmark fact pattern, not an Atari v. Nintendo fact pattern.

So what's the penalty for MODULE_LICENSE("GPL") on code that is not
actually offered under the GPL?  Being shunned by the kernel
community.  Maintaining a fork.  Getting to keep both halves when it
breaks.  Friends don't let friends write non-GPL drivers.  But friends
also don't let friends go off into delusional spasms of denial.
nVidia and ATI do what they do so that their code has more than a
snowball's chance in hell of running on people's desktops, not out of
fear that the Big Bad LKML Wolf will come blow down their houses.
Their hardware is doubtless so fiddly and buggy and crash-prone that
four out of five attempts to compile a driver for it reorder the
instructions enough to slag the GPU, under Windows or Linux.  _That's_
why they ship binary drivers.  Capisce?

Cheers,
- Michael
-
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: Recent and not-so problems with tifm_sd driver

2007-02-17 Thread Pierre Ossman

Alex Dubov wrote:
> I removed that line altogether (it does not really needed as mmc host will 
> not be accessed
> anymore). The problem is more elaborate. Here, the card fails, 
> mmc_host_remove is called without
> sleep beforehand, and "after remove" message is printed immediately after it. 
> Only then, mmc_block
> remembers to finish its business. If I leave the sleep in place, mmc_block's 
> stuff will get
> scheduled before the mmc_remove_host and everything will be all right.
> You may also notice that host is already powered off ("Setting ... power 0" 
> message) and still
> mmc_block continues to make requests like nothing happened.
> 

I don't actually think that is what happening. The block errors tend to trail a
bit behind, so the errors you are seeing are probably the result of the queue
being flushed out as you remove the card. I don't see any mmc debug messages
that indicate that is trying to send more mmc requests.

You could add a printk to the queue thread in mmc_queue.c. That will allow you
to see exactly when it exits (which should be before mmc_remove_host() returns).

Rgds
-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org
-
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: [ck] Re: 2.6.20-ck1

On Sun, 18 Feb 2007 08:00:06 +1100 Con Kolivas <[EMAIL PROTECTED]> wrote:

> On Sunday 18 February 2007 05:45, Chuck Ebbert wrote:
> ...
> > But the one I like, mm-filesize_dependant_lru_cache_add.patch,
> > has an on-off switch.
> >
>
> ...
>
> Do you still want this patch for mainline?... 

Don't think so.  The problems I see are:

- It's a system-wide knob.  In many situations this will do the wrong
  thing.  Controlling pagecache should be per-process.

- Its heuristics for working out when to invalidate the pagecache will be
  too much for some situations and too little for others.

- Whatever we do, there will be some applications in some situations
  which are hurt badly by changes like this: they'll do heaps of extra IO.

Generally, the penalties for getting this stuff wrong are very very high:
orders of magnitude slowdowns in the right situations.  Which I suspect
will make any system-wide knob ultimately unsuccessful.

The ideal way of getting this *right* is to change every application in the
world to get smart about using sync_page_range() and/or posix_fadvise(),
then to add a set of command-line options to each application in the world
so the user can control its pagecache handling.

Obviously that isn't practical.  But what _could_ be done is to put these
pagecache smarts into glibc's read() and write() code.  So the user can do:

MAX_PAGECACHE=4M MAX_DIRTY_PAGECACHE=2M rsync foo bar

This will provide pagecache control for pretty much every application.  It
has limitations (fork+exec behaviour??) but will be useful.

A kernel-based solution might use new rlimits, but would not be as flexible
or successful as a libc-based one, I suspect.

-
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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug

On 02/18, Oleg Nesterov wrote:
>
> On 02/17, Rafael J. Wysocki wrote:
> >
> > Alternatively, we can move the check into refrigerator(), like this:
> > 
> > --- linux-2.6.20-git13.orig/kernel/power/process.c
> > +++ linux-2.6.20-git13/kernel/power/process.c
> > @@ -39,6 +39,11 @@ void refrigerator(void)
> > /* Hmm, should we be allowed to suspend when there are realtime
> >processes around? */
> > long save;
> > +
> > +   /* Freeze the task unless there is a vfork completion pending */
> > +   if (current->vfork_done)
> > +   return;
> > +
> 
> This means that "current" returns to user space (get_signal_to_deliver
> will clear TIF_SIGPENDING) and runs. While try_to_freeze_tasks() thinks
> it is frozen.

Ah, sorry. I am wrong, current has no PF_FROZEN yet.

However, this means that sys_vfork() makes impossible to freeze processes
until child exits/execs. Not good.

Oleg.

-
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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug

On 02/17, Rafael J. Wysocki wrote:
>
> On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
> > 
> > static inline int is_user_space(struct task_struct *p)
> > {
> > return p->mm && !(p->flags & PF_BORROWED_MM);
> > }
> > 
> > This doesn't look right. First, an exiting task has ->mm == NULL after
> > do_exit()->exit_mm(). Probably not a problem. However, PF_BORROWED_MM
> > check is racy without task_lock(), so we can have a false positive as
> > well. Is it ok? We can freeze aio_wq prematurely.
> 
> Right now aio_wq is not freezeable (PF_NOFREEZE).

Right now yes, but we are going to change this?

> > cancel_freezing(p);
> > continue;
> > 
> > Is it right? Shouldn't we increment "todo" counter?
> 
> No.  It would be wrong to do that, because TASK_TRACED tasks with frozen
> parents cannot be frozen any further.

TASK_TRACED task could be woken by SIGKILL. cancel_freezing() clears TIF_FREEZE.
The task may start do_exit() when try_to_freeze_tasks() returns "success".
Probably not a problem.

> > if (!p->vfork_done)
> > freeze_process(p);
> > 
> > 
> > Racy. do_fork(CLONE_VFORK) first does copy_process() which puts 'p' on
> > the task list and unlocks tasklist_lock. This means that 'p' is visible
> > to try_to_freeze_tasks(), and p->vfork_done == NULL. try_to_freeze_tasks()
> > sets TIF_FREEZE.
> > 
> > Now, do_fork() continues, sets ->vfork_done, p goes to user space, notices
> > the fake signal and goes to refrigerator while its parent is blocked on
> > "struct completion vfork". Freezing failed.
> 
> You are right, but this has never happened, AFAICS.
> 
> > So, shouldn't we do
> > 
> > if (p->vfork_done)
> > cancel_freezing(p);
> > 
> > instead?
> 
> I don't think so.  If p hasn't got TIF_FREEZE set yet or it has already been
> frozen, cancel_freezing(p) is a noop.

Yes, I misread cancel_freezing(), it doesn't wake up the task if it is frozen.

> Alternatively, we can move the check into refrigerator(), like this:
> 
> --- linux-2.6.20-git13.orig/kernel/power/process.c
> +++ linux-2.6.20-git13/kernel/power/process.c
> @@ -39,6 +39,11 @@ void refrigerator(void)
>   /* Hmm, should we be allowed to suspend when there are realtime
>  processes around? */
>   long save;
> +
> + /* Freeze the task unless there is a vfork completion pending */
> + if (current->vfork_done)
> + return;
> +

This means that "current" returns to user space (get_signal_to_deliver
will clear TIF_SIGPENDING) and runs. While try_to_freeze_tasks() thinks
it is frozen.

Oleg.

-
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: [mmc] incorrect behavior on resume

2007-02-17 Thread Pierre Ossman

Alex Dubov wrote:
> And today: yet another problem with mmc.
> It so happens that after resume mmc layer issues requests to the device 
> before mmc_resume_host is
> called at all. Moreover, this prevents the machine from resuming, unless 
> worked around, because
> software timer does not work at this stage of the resume and interrupts may 
> not be delivered (if
> card was removed, for example).

Now this sounds incredibly broken. A child device should never be resumed before
its parent. Pavel, can you comment?

Rgds
-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org
-
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: GPL vs non-GPL device drivers

2007-02-17 Thread Giuseppe Bilotta

On Saturday 17 February 2007 15:19, David Schwartz wrote:

> Static Controls argued that taking the TLP was the only practical way to
> make a cartridge that would work with that printer.

Which shows how that case is different from writing Linux drivers. For
example, looking at the example the OP was himself proposing a few
alternative approaches to work around the limitation they were hitting:
could just switch to static major/minors instead of dynamics ones, they
could skip sysfs, or they could even reimplement something like sysfs
themselves, or whatever other interface they deem useful for the purpose of
plopping in their own binary blob on top of it, sort of like what nVidia
and ATi do for their stuff.

-- 
Giuseppe "Oblomov" Bilotta

-
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/

ADC driver with I2C interface

2007-02-17 Thread Mockern


Hello,

Where I can grab an example of ADC driver with I2C interface?
-
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: Recent and not-so problems with tifm_sd driver

2007-02-17 Thread Pierre Ossman

Alex Dubov wrote:
> If we are already on the topic, I would like to report two additional issues 
> with mmc_block:
> 
> 1. If, for some reason, device driver cannot return the requested data 
> amount, but does not sets
> any error, mmc_block would retry indefinitely. Of course, its always a device 
> driver's fault, but
> may be we can set some limit on retry count (this can help a lot with 
> debugging).

Well, we could add a check that data requests get fully satisfied.

> 
> And the more serious:
> 2. There was a write corruption problem with tifm_sd caused by missing wait 
> cycle (card busy/card
> not busy) after stop command. It should not had been a problem (the mmc layer 
> was spinning around
> with CMD13 untill the card become not-busy), but for some reason it was. We 
> are currently testing
> this. The intersting part, however, is behavior of mmc_block given this 
> situation:
> 
> It appears that mmc_block's instance manages to get stuck because of this. 
> The symptoms: module
> usage count is not decremented when low level driver is unloaded and 
> partition block devices do
> not get created afterwards. The fun part: the main block device gets created 
> and deleted on card
> insertion/removal and its dump is correct (dd if=/dev/mmcblk0 ...); yet 
> partition detection does
> not happens. To fix this, one have to reboot the machine or to wait about 30 
> minutes for mmc_block
> to regain its senses (then it becomes rmmod'able again).
> 
> On the other hand, it may be some sort of generic block layer problem.
> 

The block layer can get a bit fuzzy when you start yanking device out from under
it. That said, the mmc block driver should be forgiving. So if you can figure
out what it is up to (and more exactly how it is provoked), I'll try to fix it.

-- 
 -- Pierre Ossman

  Linux kernel, MMC maintainerhttp://www.kernel.org
  PulseAudio, core developer  http://pulseaudio.org
  rdesktop, core developer  http://www.rdesktop.org
-
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: mm snapshot broken-out-2007-02-17-03-25.tar.gz uploaded

On Sat, 17 Feb 2007 23:23:17 +0100 "Michal Piotrowski" <[EMAIL PROTECTED]> 
wrote:

> On 17/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Sat, 17 Feb 2007 20:58:55 +0100 "Michal Piotrowski" <[EMAIL PROTECTED]> 
> > wrote:
> >
> > > On 17/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > > On Sat, 17 Feb 2007 19:36:39 +0100 Michal Piotrowski <[EMAIL 
> > > > PROTECTED]> wrote:
> > > >
> > > > >
> > > > > [EMAIL PROTECTED] napisał(a):
> > > > > > The mm snapshot broken-out-2007-02-17-03-25.tar.gz has been 
> > > > > > uploaded to
> > > > > >
> > > > > >
> > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-02-17-03-25.tar.gz
> > > > > >
> > > > >
> > > > > BUG: unable to handle kernel paging request at virtual address 
> > > > > 6b6b6b6f
> > > >
> > > > hm, how did you make that happen?
> > > >
> > >
> > > I don't know. I can reproduce this bug.
> > >
> >
> > Could you bisect it please?  The patches to suspect are
> [..]
> > For git-block, do
> >
> > quilt pop 
> > scsi-megaraid_sas-return-sync-cache-call-with-success.patch
> >
> > and retest.  If that doesn't fail, do
> >
> > quilt push git-block-xfs-barriers-broke.patch
> >
> > and retest.
> >
> 
> Ok, this must be a git-block-* stuff.
> 
> Jens, can you take a look at this bug?
> http://www.ussg.iu.edu/hypermail/linux/kernel/0702.2/0646.html
> 

I wonder why.  I can't make it happen on two machines, scsi, sata and IDE. 
And afaict git-block isn't changed from 2.6.20-mm1.

Are you sure?
-
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: 2.6.20-git14 rtl8139 possible circular locking dependency detected

2007-02-17 Thread Michal Piotrowski


On 17/02/07, Francois Romieu <[EMAIL PROTECTED]> wrote:

Michal Piotrowski <[EMAIL PROTECTED]> :
[...]

Did you enable RTL8139_DEBUG ?

If so you can try the patch below.



I enabled debugging
#define RTL8139_DEBUG 3

Here is a full log
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20-git14/bug.txt
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.20-git14/git-config

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
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: GPL vs non-GPL device drivers


On 2/17/07, Dave Neuer <[EMAIL PROTECTED]> wrote:

I think you are reading Lexmark wrong. First off, Lexmark ruled that
scenes a faire applied to the toner-level calculation, not "make a
toner cartridge that works with a particular Lexmark printer." It was
the toner-calculation algorithm that could't be done any other sane
way, which made the TLP unprotectable via copyright. The opinion says,
"Both prongs of the infringement test, in other words, consider
'copyrightability,' which at its heart turns on the principle that
copyright protection extends to expression, not to ideas."


David S. is reading Lexmark right (IMHO, IANAL).  The byte-for-byte
content of the TLP had to be copied in order to interoperate with the
printer, because the printer checksummed it (apparently using SHA-1,
but possibly truncating the result to 8 bits, which is rather comical;
it is not 100% clear to me based on the appellate decision, which also
seems to say that the printer cartridge contains the SHA-1 algorithm,
which is probably just an error).  That rendered it a "lock-out code"
within the sense of Sega v. Accolade, and ultimately that's why the
circuit court vacated the district court's decision in Lexmark's
favor.

In order to vacate and remand, the appellate court had to demonstrate
that the district court's grant of preliminary injunction to Lexmark
was wrong _as_a_matter_of_law_.  So they had to construe the facts of
the case in a light as favorable to Lexmark as humanly possible.  They
concluded that, _even_ if the TLP contained copyrightable expression,
and _even_ if all of the district court's reasoning about the other
prongs of a preliminary injunction test (potential for irreparable
harm, balance of harms, the public interest) were correct, neither the
Copyright Act nor the DMCA could be used to establish the fourth
prong: likelihood of success on the merits.

Cloners rejoice:  the US Supreme Court has, by denying certioriari on
Judge Sutton's opinion, given you carte blanche to copy and distribute
freely any software or firmware whose author has been so stupid as to
cryptographically checksum it as an anti-interoperability measure.
Using copyrighted software as a "lock-out code" to create a cause of
action against reverse engineers has the paradoxical effect of
rendering it uncopyrightable _as_a_matter_of_law_ in the US, unless
and until Congress or a later Supreme Court creates new law to the
contrary.  I am not a lawyer, this is not legal advice, on your own
head be it.


You're saying that there's no other way to interface device drivers to
an operating system than the current Linux driver model? That's
strange, since it's a different driver model than Linux had
previously, and it's also different from the BeOS driver interface,
etc. If the Linux driver interface is protectable, it doesn't seem
like scenes a faire applies.


The Linux driver interface is, as a matter of law, not copyrightable
in the U. S. of A., no matter how many EXPORT_SYMBOL_GPLs and dactylic
hexameters you adorn it with.  That was already true under Baker v.
Selden, and didn't get any less so as a result of Lotus v. Borland,
and is now inescapable (IMHO) under Lexmark, and it's not likely to
get any less true unless RMS is elected president and appoints Eben
Moglen to the Supreme Court.  Sorry, folks; I'm just the messenger.

Cheers,
- Michael
-
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: GPL vs non-GPL device drivers

2007-02-17 Thread David Schwartz


> You're saying that there's no other way to interface device drivers to
> an operating system than the current Linux driver model?

Interfacing an X1900 graphics card to FreeBSD and interfacing an X1900
graphics card to Linux are two different ideas. They are *not* two
expressions of the same idea.

> That's
> strange, since it's a different driver model than Linux had
> previously, and it's also different from the BeOS driver interface,
> etc. If the Linux driver interface is protectable, it doesn't seem
> like scenes a faire applies.

These are all diferent ideas. Scenes a faire applies to how you express a
given idea, not other ideas you could possibly express. (This is explicitly
addressed in the decision.)

Otherwise, there would be no scenes a faire. Perhaps you cannot make a
western without a shootout at high noon, but you can make a romance.

DS


-
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/

netpoll again ? (was: Re: 2.6.20-git14 rtl8139 possible circular locking dependency detected)

2007-02-17 Thread Francois Romieu

Francois Romieu <[EMAIL PROTECTED]> :
> Michal Piotrowski <[EMAIL PROTECTED]> :
> [...]
> 
> Did you enable RTL8139_DEBUG ?
> 
> If so you can try the patch below.

It's buggy there too but you are not experiencing this one.

1 - netpoll() calls the poll() handler of the device through netpoll_poll()
2 - The poll handler of the device tries to acquire dev->_xmit_lock
through dev_mc_add during the Rx protocol processing
3 - netpoll() holds dev->_xmit_lock to avoid recursion in netpoll_poll()

#2 and #3 have opposite requirements.

-- 
Ueimor
-
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: Subject: [PATCH 2.6.20 004/005] dmfe: Add support for suspend/resume

2007-02-17 Thread Pavel Machek

Hi!
> 
> Hello ,  I am sorry that I missed some parts of coding style. I need to 
> reread it :-)
> 
> There is a updated patch :

It looks better.

> + /* Disable Interrupt */
> + outl (0, dev->base_addr + DCR7);
> + outl (inl(dev->base_addr + DCR5), dev->base_addr + DCR5);

I'd kill space after outl...

> + /* Free RX buffers */
> + dmfe_free_rxbuffer(db);
> +
> + /* Power down device*/

and add space before */.

Congratulation, you passed coding-style-police-check ;-).
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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: Analog-to-Digital Converter (ADC) driver

2007-02-17 Thread Mockern

AD7994 4 Channel, 12-Bit ADC with I2C Compatible Interface in 16-Lead
TSSOP, 

I think it could be I2C driver 


>On 2/17/07, Mockern <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> Where I can find any ADC driver example?
>>
>
>Depending on what kind of ADC and what you want to do with it,
>anything from a simple char device to an ALSA driver could be
>appropriate.  Can you provide more information?
>
>Lee
>-
>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/


-- 
Сегодня удачный день, чтобы завести почту на Яндексе http://mail.yandex.ru
-
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: Analog-to-Digital Converter (ADC) driver

2007-02-17 Thread Mockern

AD7994 4 Channel, 12-Bit ADC with I2C Compatible Interface in 16-Lead TSSOP, 


I think it could be I2C driver 

>>On 2/17/07, Mockern <[EMAIL PROTECTED]> wrote:
>>> Hello,
>>>
>>> Where I can find any ADC driver example?
>>>
>>
>>Depending on what kind of ADC and what you want to do with it,
>>anything from a simple char device to an ALSA driver could be
>>appropriate.  Can you provide more information?
>>
>>Lee
>>-
>>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/
>


-- 
Яндекс.Почта: объем почтового ящика не ограничен! 
http://mail.yandex.ru/monitoring/
-
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: 2.6.20-git13 kernel BUG at /mnt/md0/devel/linux-git/kernel/time/tick-sched.c:168

2007-02-17 Thread Michal Piotrowski


On 17/02/07, Alex Riesen <[EMAIL PROTECTED]> wrote:

Thomas Gleixner, Sat, Feb 17, 2007 16:14:17 +0100:
> On Sat, 2007-02-17 at 15:47 +0100, Alex Riesen wrote:
> > > > 164 if (need_resched())
> > > > 165 goto end;
> > > > 166
> > > > 167 cpu = smp_processor_id();
> > > > 168 BUG_ON(local_softirq_pending());
> > >
> > > Hmm, the BUG_ON is inside of an interrupt disabled region, so we should
> > > have bailed out early in the need_resched() check above (because we are
> > > in the idle task context according to the stack trace).
> > >
> > > Is this reproducible ?
> >
> > Seen this too (Ubuntu, P4/ht-SMT, SATA, typed from screen):
>
> Can you please apply the patch below, so we can at least see, which
> softirq is pending. This should trigger independently of hrtimers and
> dynticks. You can keep it compiled in and disable it at the kernel
> commandline with "nohz=off" and / or "highres=off"

It did, only one time:

Idle: local softirq pending: 0020<6>USB Universal Host Controller Interface 
driver v3.0



sudo cat /var/log/messages | grep Idle
Feb 17 17:35:34 bitis-gabonica kernel: Idle: local softirq pending:
0020<6>hdd: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache,
UDMA(33)
Feb 17 19:20:01 bitis-gabonica kernel: Idle: local softirq pending:
0020<3>Idle: local softirq pending: 0020<3>Idle: local softirq
pending: 0020<7>PM: Removing info for No Bus:vcs7

cat /proc/interrupts
  CPU0   CPU1
 0: 232838  0   IO-APIC-edge  timer
 1:401  0   IO-APIC-edge  i8042
 7:  0  0   IO-APIC-edge  parport0
 8:  1  0   IO-APIC-edge  rtc
 9:  1  0   IO-APIC-fasteoi   acpi
 12:  4  0   IO-APIC-edge  i8042
 14:319  0   IO-APIC-edge  ide0
 15:   1612  0   IO-APIC-edge  ide1
 16:  16494  0   IO-APIC-fasteoi   uhci_hcd:usb3, libata
 17:   4670  0   IO-APIC-fasteoi   uhci_hcd:usb1, uhci_hcd:usb4
 18:  0  0   IO-APIC-fasteoi   uhci_hcd:usb2
 19:  2  0   IO-APIC-fasteoi   ehci_hcd:usb5
 20:   2822  0   IO-APIC-fasteoi   Intel ICH5
 21:   2881  0   IO-APIC-fasteoi   eth1
 22: 58  0   IO-APIC-fasteoi   eth0
NMI:  0  0
LOC: 232562 232846
ERR:  0
MIS:  0

I can confirm that this is ICH5 SATA controller problem.

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
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: Subject: [PATCH 2.6.20 004/005] dmfe: Add support for suspend/resume

2007-02-17 Thread Maxim

On Saturday 17 February 2007 13:50:29 Pavel Machek wrote:
> Hi!
> 
> > @@ -2050,11 +2047,56 @@ static struct pci_device_id dmfe_pci_tbl
> >  MODULE_DEVICE_TABLE(pci, dmfe_pci_tbl);
> >  
> >  
> > +
> > +static int dmfe_suspend(struct pci_dev *pci_dev, pm_message_t state)
> > +{
> > +   struct net_device *dev = pci_get_drvdata(pci_dev);
> > +   struct dmfe_board_info *db = netdev_priv(dev);
> > +
> > +   /* Disable upper layer interface */
> > +   netif_device_detach (dev);
> > +
> > +   /* Disable Tx/Rx */
> > +   db->cr6_data &= ~(CR6_RXSC | CR6_TXSC);
> > +   update_cr6(db->cr6_data, dev->base_addr);
> > +
> > +   /* Disable Interrupt */
> > +   outl (0, dev->base_addr + DCR7);
> > +   outl (inl (dev->base_addr + DCR5), dev->base_addr + DCR5);
> 
> Please no space between function and "(".

I missed that part of coding style about no space after function name
> 
> > +   /* Fre RX buffers */
> 
> Free?

Of course  :-)
> 
> > +   dmfe_free_rxbuffer (db);
> 
> > +   /* Power down device*/
> 
> " */"
> 
> > +   pci_set_power_state (pci_dev, pci_choose_state (pci_dev,state));
> 
> Let it be ", state", and delete spaces between function and "(".

Sure
> 
> 
> > +static int dmfe_resume (struct pci_dev *pci_dev)
> 
> delete spaces between function and "(".
> 
> > +   pci_restore_state(pci_dev);
> > +   pci_set_power_state(pci_dev ,PCI_D0);
> > +
> 
> ", "
> 
> Otherwise looks ok to me.
> 

Hello ,  I am sorry that I missed some parts of coding style. I need to reread 
it :-)

There is a updated patch :

--- linux-2.6.20-mod/drivers/net/tulip/dmfe.c   2007-02-15 18:24:47.0 
+0200
+++ linux-2.6.20-test/drivers/net/tulip/dmfe.c  2007-02-15 18:26:34.0 
+0200
@@ -55,9 +55,6 @@
 
 TODO
 
-Implement pci_driver::suspend() and pci_driver::resume()
-power management methods.
-
 Check on 64 bit boxes.
 Check and fix on big endian boxes.
 
@@ -2050,11 +2047,56 @@ static struct pci_device_id dmfe_pci_tbl
 MODULE_DEVICE_TABLE(pci, dmfe_pci_tbl);
 
 
+
+static int dmfe_suspend(struct pci_dev *pci_dev, pm_message_t state)
+{
+   struct net_device *dev = pci_get_drvdata(pci_dev);
+   struct dmfe_board_info *db = netdev_priv(dev);
+
+   /* Disable upper layer interface */
+   netif_device_detach(dev);
+
+   /* Disable Tx/Rx */
+   db->cr6_data &= ~(CR6_RXSC | CR6_TXSC);
+   update_cr6(db->cr6_data, dev->base_addr);
+
+   /* Disable Interrupt */
+   outl (0, dev->base_addr + DCR7);
+   outl (inl(dev->base_addr + DCR5), dev->base_addr + DCR5);
+
+   /* Free RX buffers */
+   dmfe_free_rxbuffer(db);
+
+   /* Power down device*/
+   pci_set_power_state(pci_dev, pci_choose_state(pci_dev, state));
+   pci_save_state(pci_dev);
+
+   return 0;
+}
+
+static int dmfe_resume(struct pci_dev *pci_dev)
+{
+   struct net_device *dev = pci_get_drvdata(pci_dev);
+
+   pci_restore_state(pci_dev);
+   pci_set_power_state(pci_dev, PCI_D0);
+
+   /* Re-initialize DM910X board */
+   dmfe_init_dm910x(dev);
+
+   /* Restart upper layer interface */
+   netif_device_attach(dev);
+
+   return 0;
+}
+
 static struct pci_driver dmfe_driver = {
.name   = "dmfe",
.id_table   = dmfe_pci_tbl,
.probe  = dmfe_init_one,
.remove = __devexit_p(dmfe_remove_one),
+   .suspend= dmfe_suspend,
+   .resume = dmfe_resume
 };
 
 MODULE_AUTHOR("Sten Wang, [EMAIL PROTECTED]");
-
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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug

2007-02-17 Thread Rafael J. Wysocki

On Saturday, 17 February 2007 22:34, Oleg Nesterov wrote:
> Rafael, I am trying to understand try_to_freeze_tasks(), and I have a
> couple of questions.
> 
>   static inline int is_user_space(struct task_struct *p)
>   {
>   return p->mm && !(p->flags & PF_BORROWED_MM);
>   }
> 
> This doesn't look right. First, an exiting task has ->mm == NULL after
> do_exit()->exit_mm(). Probably not a problem. However, PF_BORROWED_MM
> check is racy without task_lock(), so we can have a false positive as
> well. Is it ok? We can freeze aio_wq prematurely.

Right now aio_wq is not freezeable (PF_NOFREEZE).

> 
> 
>   try_to_freeze_tasks:
> 
>   do_each_thread(g, p) {
> 
>   if (p->state == TASK_TRACED && frozen(p->parent)) {
> 
> Why we are doing this check outside of "if (is_user_space(p))" ?
> Not a bug of course, but looks strange.

For no particular reason.

> 
>   cancel_freezing(p);
>   continue;
> 
> Is it right? Shouldn't we increment "todo" counter?

No.  It would be wrong to do that, because TASK_TRACED tasks with frozen
parents cannot be frozen any further.

> 
>   }
>   if (is_user_space(p)) {
>   if (!freeze_user_space)
>   continue;
> 
>   /* Freeze the task unless there is a vfork
>* completion pending
>*/
>   if (!p->vfork_done)
>   freeze_process(p);
> 
> 
> Racy. do_fork(CLONE_VFORK) first does copy_process() which puts 'p' on
> the task list and unlocks tasklist_lock. This means that 'p' is visible
> to try_to_freeze_tasks(), and p->vfork_done == NULL. try_to_freeze_tasks()
> sets TIF_FREEZE.
> 
> Now, do_fork() continues, sets ->vfork_done, p goes to user space, notices
> the fake signal and goes to refrigerator while its parent is blocked on
> "struct completion vfork". Freezing failed.

You are right, but this has never happened, AFAICS.

> So, shouldn't we do
> 
>   if (p->vfork_done)
>   cancel_freezing(p);
> 
> instead?

I don't think so.  If p hasn't got TIF_FREEZE set yet or it has already been
frozen, cancel_freezing(p) is a noop.

Alternatively, we can move the check into refrigerator(), like this:

---
 kernel/power/process.c |   21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

Index: linux-2.6.20-git13/kernel/power/process.c
===
--- linux-2.6.20-git13.orig/kernel/power/process.c
+++ linux-2.6.20-git13/kernel/power/process.c
@@ -39,6 +39,11 @@ void refrigerator(void)
/* Hmm, should we be allowed to suspend when there are realtime
   processes around? */
long save;
+
+   /* Freeze the task unless there is a vfork completion pending */
+   if (current->vfork_done)
+   return;
+
save = current->state;
pr_debug("%s entered refrigerator\n", current->comm);
 
@@ -112,22 +117,10 @@ static unsigned int try_to_freeze_tasks(
cancel_freezing(p);
continue;
}
-   if (is_user_space(p)) {
-   if (!freeze_user_space)
-   continue;
-
-   /* Freeze the task unless there is a vfork
-* completion pending
-*/
-   if (!p->vfork_done)
-   freeze_process(p);
-   } else {
-   if (freeze_user_space)
-   continue;
-
+   if (is_user_space(p) == !!freeze_user_space) {
freeze_process(p);
+   todo++;
}
-   todo++;
} while_each_thread(g, p);
read_unlock(_lock);
yield();/* Yield is okay here */


-
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/

[git patch, resend] remove JFFS v1

2007-02-17 Thread Jeff Garzik


[just sent this upstream; obvious file-removal patch snipped for size]

(resend) 

Why:Unmaintained for years, superceded by JFFS2 for years.

Please pull from 'kill-jffs' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git kill-jffs

to receive the following updates:

 Documentation/feature-removal-schedule.txt |7 -
 fs/Kconfig |   26 -
 fs/Makefile|1 -
 fs/jffs/Makefile   |   11 -
 fs/jffs/inode-v23.c| 1847 ---
 fs/jffs/intrep.c   | 3449 
 fs/jffs/intrep.h   |   58 -
 fs/jffs/jffs_fm.c  |  798 ---
 fs/jffs/jffs_fm.h  |  149 --
 fs/jffs/jffs_proc.c|  261 ---
 fs/jffs/jffs_proc.h|   28 -
 include/linux/jffs.h   |  224 --
 12 files changed, 0 insertions(+), 6859 deletions(-)
 delete mode 100644 fs/jffs/Makefile
 delete mode 100644 fs/jffs/inode-v23.c
 delete mode 100644 fs/jffs/intrep.c
 delete mode 100644 fs/jffs/intrep.h
 delete mode 100644 fs/jffs/jffs_fm.c
 delete mode 100644 fs/jffs/jffs_fm.h
 delete mode 100644 fs/jffs/jffs_proc.c
 delete mode 100644 fs/jffs/jffs_proc.h
 delete mode 100644 include/linux/jffs.h

Jeff Garzik (1):
  Remove JFFS (version 1), as scheduled.

diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index c585aa8..e1bc0c5 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -306,13 +306,6 @@ Who:   Len Brown <[EMAIL PROTECTED]>
 
 ---
 
-What:  JFFS (version 1)
-When:  2.6.21
-Why:   Unmaintained for years, superceded by JFFS2 for years.
-Who:   Jeff Garzik <[EMAIL PROTECTED]>
-

-
 What:   sk98lin network driver
 When:   July 2007
 Why:In kernel tree version of driver is unmaintained. Sk98lin driver
diff --git a/fs/Kconfig b/fs/Kconfig
index a722b5a..3c4886b 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -1189,32 +1189,6 @@ config EFS_FS
  To compile the EFS file system support as a module, choose M here: the
  module will be called efs.
 
-config JFFS_FS
-   tristate "Journalling Flash File System (JFFS) support"
-   depends on MTD && BLOCK && BROKEN
-   help
- JFFS is the Journalling Flash File System developed by Axis
- Communications in Sweden, aimed at providing a crash/powerdown-safe
- file system for disk-less embedded devices. Further information is
- available at ().
-
- NOTE: This filesystem is deprecated and is scheduled for removal in
- 2.6.21.  See Documentation/feature-removal-schedule.txt
-
-config JFFS_FS_VERBOSE
-   int "JFFS debugging verbosity (0 = quiet, 3 = noisy)"
-   depends on JFFS_FS
-   default "0"
-   help
- Determines the verbosity level of the JFFS debugging messages.
-
-config JFFS_PROC_FS
-   bool "JFFS stats available in /proc filesystem"
-   depends on JFFS_FS && PROC_FS
-   help
- Enabling this option will cause statistics from mounted JFFS file 
systems
- to be made available to the user in the /proc/fs/jffs/ directory.
-
 config JFFS2_FS
tristate "Journalling Flash File System v2 (JFFS2) support"
select CRC32
diff --git a/fs/Makefile b/fs/Makefile
index b9ffa63..9edf411 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -94,7 +94,6 @@ obj-$(CONFIG_HPFS_FS) += hpfs/
 obj-$(CONFIG_NTFS_FS)  += ntfs/
 obj-$(CONFIG_UFS_FS)   += ufs/
 obj-$(CONFIG_EFS_FS)   += efs/
-obj-$(CONFIG_JFFS_FS)  += jffs/
 obj-$(CONFIG_JFFS2_FS) += jffs2/
 obj-$(CONFIG_AFFS_FS)  += affs/
 obj-$(CONFIG_ROMFS_FS) += romfs/
[snip file deletion patch]
-
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: GPL vs non-GPL device drivers

2007-02-17 Thread Dave Neuer

On 2/16/07, David Schwartz <[EMAIL PROTECTED]> wrote:

> On 2/16/07, David Schwartz <[EMAIL PROTECTED]> wrote:

> > (See, among other cases, Lexmark. v. Static
> > Controls.) A copyright is not a patent, you can only own
> > something if there
> > are multiple equally good ways to do it and you claim *one* of them.

> Only in a world where "write a Linux module" is a "functional idea." I
> don't think that the legal world in the US is an example of such a
> world, though you clearly do.

I'm not arguing "write a Linux module" is a functional idea. But "write code
so that a graphics card with a X1950 chipset works with a Linux kernel"
certainly is.

Again, see Lexmark v. Static Controls. If "make a toner cartridge that works
with a particular Lexmark printer" is a functional idea, why is "make a
graphics driver that works with a particular Linux kernel" not? What is the
difference you think matters?

I think you are reading Lexmark wrong. First off, Lexmark ruled that
scenes a faire applied to the toner-level calculation, not "make a
toner cartridge that works with a particular Lexmark printer." It was
the toner-calculation algorithm that could't be done any other sane
way, which made the TLP unprotectable via copyright. The opinion says,
"Both prongs of the infringement test, in other words, consider
'copyrightability,' which at its heart turns on the principle that
copyright protection extends to expression, not to ideas."

You're saying that there's no other way to interface device drivers to
an operating system than the current Linux driver model? That's
strange, since it's a different driver model than Linux had
previously, and it's also different from the BeOS driver interface,
etc. If the Linux driver interface is protectable, it doesn't seem
like scenes a faire applies.
-
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: 2.6.20-git14 rtl8139 possible circular locking dependency detected

2007-02-17 Thread Francois Romieu

Michal Piotrowski <[EMAIL PROTECTED]> :
[...]

Did you enable RTL8139_DEBUG ?

If so you can try the patch below.

diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 35ad5cf..da61368 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -634,7 +634,6 @@ static int rtl8139_close (struct net_dev
 static int netdev_ioctl (struct net_device *dev, struct ifreq *rq, int cmd);
 static struct net_device_stats *rtl8139_get_stats (struct net_device *dev);
 static void rtl8139_set_rx_mode (struct net_device *dev);
-static void __set_rx_mode (struct net_device *dev);
 static void rtl8139_hw_start (struct net_device *dev);
 static void rtl8139_thread (struct work_struct *work);
 static void rtl8139_tx_timeout_task(struct work_struct *work);
@@ -2497,10 +2496,11 @@ static struct net_device_stats *rtl8139_
return >stats;
 }
 
-/* Set or clear the multicast filter for this adaptor.
-   This routine is not state sensitive and need not be SMP locked. */
-
-static void __set_rx_mode (struct net_device *dev)
+/*
+ * Set or clear the multicast filter for this adaptor.
+ * This routine is not state sensitive and need not be SMP locked.
+ */
+static void rtl8139_set_rx_mode (struct net_device *dev)
 {
struct rtl8139_private *tp = netdev_priv(dev);
void __iomem *ioaddr = tp->mmio_addr;
@@ -2545,16 +2545,6 @@ static void __set_rx_mode (struct net_de
RTL_W32_F (MAR0 + 4, mc_filter[1]);
 }
 
-static void rtl8139_set_rx_mode (struct net_device *dev)
-{
-   unsigned long flags;
-   struct rtl8139_private *tp = netdev_priv(dev);
-
-   spin_lock_irqsave (>lock, flags);
-   __set_rx_mode(dev);
-   spin_unlock_irqrestore (>lock, flags);
-}
-
 #ifdef CONFIG_PM
 
 static int rtl8139_suspend (struct pci_dev *pdev, pm_message_t state)
-
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/

[git patches] libata ACPI support

2007-02-17 Thread Jeff Garzik

This has been living in libata-dev#ALL (and thus -mm) for quite a while
now.

For both PATA and SATA, this helps at suspend/resume time.

For SATA, ACPI support mostly consists of taskfiles (ATA commands) that
the BIOS wants us to send to the system drive.  Most notably, if you
have set a hard drive password in BIOS, you cannot access your data
without ACPI support.  Given that libata has survived this long without
ACPI support, this does not appear to impact many people.

For PATA, it makes available some DMA/PIO timing functions that
occasionally cannot be found anywhere else.  There is at least one case
of this where NVIDIA needs ACPI's help to reliably handle various
DMA/PIO modes (search in lkml/linux-ide archives for "pata_acpi").

NOTE: It is difficult to tell from the diff below, but the module
parameter (or kernel command line arg) is "libata.noacpi" not the more
generic "noacpi" that the diff might mistakenly lead you to believe.
search for the associated module_param() code for further details.

Should this cause problems, we can easily turn it off.  But as months of
-mm testing seem to indicate, this hasn't caused much of a ripple, aside
from solving a few lingering problems.

Please pull from 'acpi' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git acpi

to receive the following updates:

 Documentation/kernel-parameters.txt |5 +
 drivers/ata/Kconfig |   13 +
 drivers/ata/Makefile|2 +-
 drivers/ata/libata-acpi.c   |  698 +++
 drivers/ata/libata-core.c   |   14 +
 drivers/ata/libata.h|   15 +
 include/linux/libata.h  |5 +
 7 files changed, 751 insertions(+), 1 deletions(-)
 create mode 100644 drivers/ata/libata-acpi.c

Fiodor Suietov (1):
  libata: wrong sizeof for BUFFER

Kristen Carlson Accardi (3):
  libata: ACPI and _GTF support
  libata: ACPI _SDD support
  libata: change order of _SDD/_GTF execution (resend #3)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index abd575c..5bc8970 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -48,6 +48,7 @@ parameter is applicable:
ISAPNP  ISA PnP code is enabled.
ISDNAppropriate ISDN support is enabled.
JOY Appropriate joystick support is enabled.
+   LIBATA  Libata driver is enabled
LP  Printer support is enabled.
LOOPLoopback device support is enabled.
M68kM68k architecture is enabled.
@@ -1038,6 +1039,10 @@ and is between 256 and 4096 characters. It is defined in 
the file
emulation library even if a 387 maths coprocessor
is present.
 
+   noacpi  [LIBATA] Disables use of ACPI in libata suspend/resume
+   when set.
+   Format: 
+
noaliencache[MM, NUMA] Disables the allcoation of alien caches in
the slab allocator.  Saves per-node memory, but will
impact performance on real NUMA hardware.
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 3747457..4af0a4b 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -161,6 +161,19 @@ config SATA_INTEL_COMBINED
depends on IDE=y && !BLK_DEV_IDE_SATA && (SATA_AHCI || ATA_PIIX)
default y
 
+config SATA_ACPI
+   bool
+   depends on ACPI && PCI
+   default y
+   help
+ This option adds support for SATA-related ACPI objects.
+ These ACPI objects add the ability to retrieve taskfiles
+ from the ACPI BIOS and write them to the disk controller.
+ These objects may be related to performance, security,
+ power management, or other areas.
+ You can disable this at kernel boot time by using the
+ option libata.noacpi=1
+
 config PATA_ALI
tristate "ALi PATA support (Experimental)"
depends on PCI && EXPERIMENTAL
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index cd096f0..74298af 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -66,4 +66,4 @@ obj-$(CONFIG_ATA_GENERIC) += ata_generic.o
 obj-$(CONFIG_PATA_LEGACY)  += pata_legacy.o
 
 libata-objs:= libata-core.o libata-scsi.o libata-sff.o libata-eh.o
-
+libata-$(CONFIG_SATA_ACPI) += libata-acpi.o
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
new file mode 100644
index 000..b4e8be5
--- /dev/null
+++ b/drivers/ata/libata-acpi.c
@@ -0,0 +1,698 @@
+/*
+ * libata-acpi.c
+ * Provides ACPI support for PATA/SATA.
+ *
+ * Copyright (C) 2006 Intel Corp.
+ * Copyright (C) 2006 Randy Dunlap
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "libata.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SATA_ROOT_PORT(x)  (((x) >> 16) &

Re: [PATCH 2.6.21-rc1] powerpc: Make of_device_uevent() compatible with ibmebus

On Sat, 2007-02-17 at 17:28 +0100, Hoang-Nam Nguyen wrote:
> ibmebus has a fake root device that's not associated with an ofdt node.
> Filter out any such devices in of_device_uevent().

Doh ! You are creating an of_device with no attached device-node ? That
is totally evil ! Why do you need that ?

Ben.

> 
> Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
> ---
> 
> 
>  of_device.c |4 
>  1 files changed, 4 insertions(+)
> 
> 
> diff -urp a/arch/powerpc/kernel/of_device.c b/arch/powerpc/kernel/of_device.c
> --- a/arch/powerpc/kernel/of_device.c 2007-02-17 16:36:32.116368480 +0100
> +++ b/arch/powerpc/kernel/of_device.c 2007-02-17 16:44:01.319366352 +0100
> @@ -180,6 +180,10 @@ int of_device_uevent(struct device *dev,
>  
>   ofdev = to_of_device(dev);
>  
> + /* e.g. ibmebus has a fake root device w/o ofdt node -- filter that */
> + if (!ofdev->node)
> + return -ENODEV;
> +
>   if (add_uevent_var(envp, num_envp, ,
>  buffer, buffer_size, ,
>  "OF_NAME=%s", ofdev->node->name))
> 
> ___
> Linuxppc-dev mailing list
> [EMAIL PROTECTED]
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

-
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: [RFC PATCH(Experimental) 2/4] Revert changes to workqueue.c

On 02/17, Srivatsa Vaddagiri wrote:
>
> Yeah, thats what I thought. We will try to split it to the extent
> possible in the next iteration.

Before you begin. You are doing CPU_DOWN_PREPARE after freeze_processes().
Not good. This makes impossible to do flush_workueue() at CPU_DOWN_PREPARE
stage, we have callers.

I'm afraid it won't be so easy to solve all locking/racing problems. Will
wait for the patch :)

Oleg.

-
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: [ck] Re: 2.6.20-ck1

2007-02-17 Thread michael chang

On 2/17/07, Con Kolivas <[EMAIL PROTECTED]> wrote:

On Sunday 18 February 2007 05:45, Chuck Ebbert wrote:
> Con Kolivas wrote:
> > Maintainers are far too busy off testing code for
> > 16+ cpus, petabytes of disk storage and so on to try it for themselves.
> > Plus they worry incessantly that my patches may harm those precious
> > machines' performance...
>
> But the one I like, mm-filesize_dependant_lru_cache_add.patch,
> has an on-off switch.
>
> In other words it adds an option to do things differently.
> How could that possibly affect any workload if that option
> isn't enabled?

Swap prefetch not only has an on-off switch, you can even build your kernel
without it entirely so it costs even less than this patch... I'm not going to
support the argument that it might be built into the kernel and enabled
unknowingly and _then_ cause overhead.

The patch, the way it's written now -- is the default to build with
swap-prefetch, or build without by default? If the former, maybe it
would be more accepted if the latter was the default. (Of course, that
defeats the point for desktop users who add the patch and then wonder
why it doesn't work, but... *shrugs*)

Oh and this patch depends on some of the code from the swap prefetch patch
too. I guess since they're so suspicious of swap prefetch the swap prefetch
patch can be ripped apart for the portions of code required to make this
patch work.

While I'm all for putting Con's patches into mainline, I'm worried
about what happens if you rip swap prefetch apart and (if the
unthinkable happens) somebody accidentally omits something or worse.
Then mainline would have even more reason to be suspicious of code
from you, Con. Unless you already ripped the swap prefetch patch into
the parts that mm-filesize_dependant_lru_cache_add.patch depend on and
the parts it doesn't, and check it's "sane" to use them
independently...

(I'd be WAY more suspicious of having "half" of swap prefetch than
having all of it. I hope that most of mainline agrees with me, but I
have a sneaking suspicion they don't.)

In any case, this "ripping"... would it make the reverse happen? i.e.
swap prefetch being dependent on
mm-filesize_dependant_lru_cache_add.patch instead?

--
~Mike
- Just the crazy copy cat.
-
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: [RFC][PATCH] Documentation: Ask driver writers to provide suspend/resume support

2007-02-17 Thread Rafael J. Wysocki

On Saturday, 17 February 2007 21:57, Rafael J. Wysocki wrote:
> On Saturday, 17 February 2007 12:40, Pavel Machek wrote:
> > > > > +PM support:  Since Linux is used on many portable and desktop 
> > > > > systems, your
> > > > > + driver is likely to be used on such a system and 
> > > > > therefore it
> > > > > + should support basic power management by implementing, 
> > > > > if
> > > > > + necessary, the .suspend and .resume methods used during 
> > > > > the
> > > > > + system-wide suspend and resume transitions.  You should 
> > > > > verify
> > > > > + that your driver correctly handles the suspend and 
> > > > > resume, but
> > > > > + if you are unable to ensure that, please at least 
> > > > > define the
> > > > > + .suspend method returning the -ENOSYS ("Function not
> > > > > + implemented") error.
> > > > 
> > > > Perhaps pointer to Documentation/power/drivers-testing.txt would be
> > > > useful here?
> > > 
> > > Okay, maybe something like this:
> > > 
> > > "Please see Documentation/power/drivers-testing.txt for the driver testing
> > > instructions."
> > > 
> > > as the last sentence?
> > 
> > Looks ok. (BTW you have my ACK).
> 
> Thanks.

Anyway, please have a look at the appended revised version.  I have separated
the driver testing and debugging documents and changed the paragraph in
SubmittingDrivers a bit.

Greetings,
Rafael


---
 Documentation/SubmittingDrivers|   11 +++
 Documentation/power/basic-pm-debugging.txt |  106 +
 Documentation/power/drivers-testing.txt|   42 +++
 3 files changed, 159 insertions(+)

Index: linux-2.6.20-git13/Documentation/SubmittingDrivers
===
--- linux-2.6.20-git13.orig/Documentation/SubmittingDrivers
+++ linux-2.6.20-git13/Documentation/SubmittingDrivers
@@ -87,6 +87,17 @@ Clarity: It helps if anyone can see how 
driver that intentionally obfuscates how the hardware works
it will go in the bitbucket.
 
+PM support:Since Linux is used on many portable and desktop systems, your
+   driver is likely to be used on such a system and therefore it
+   should support basic power management by implementing, if
+   necessary, the .suspend and .resume methods used during the
+   system-wide suspend and resume transitions.  You should verify
+   that your driver correctly handles the suspend and resume, but
+   if you are unable to ensure that, please at least define the
+   .suspend method returning the -ENOSYS ("Function not
+   implemented") error.  For the driver testing instructions see
+   Documentation/power/drivers-testing.txt .
+
 Control:   In general if there is active maintainance of a driver by
the author then patches will be redirected to them unless
they are totally obvious and without need of checking.
Index: linux-2.6.20-git13/Documentation/power/drivers-testing.txt
===
--- /dev/null
+++ linux-2.6.20-git13/Documentation/power/drivers-testing.txt
@@ -0,0 +1,42 @@
+Testing suspend and resume support in device drivers
+   (C) 2007 Rafael J. Wysocki <[EMAIL PROTECTED]>, GPL
+
+1. Preparing the test system
+
+Unfortunately, to effectively test the support for the system-wide suspend and
+resume transitions in a driver, it is necessary to suspend and resume a fully
+functional system with this driver loaded.  Moreover, that should be done
+several times, preferably several times in a row, and separately for the 
suspend
+to disk (STD) and the suspend to RAM (STR) transitions, because each of these
+cases involves different ordering of operations and different interactions with
+the machine's BIOS.
+
+Of course, for this purpose the test system has to be known to suspend and
+resume without the driver being tested.  Thus, if possible, you should first
+resolve all suspend/resume-related problems in the test system before you start
+testing the new driver.  Please see Documents/power/basic-pm-debugging.txt for
+more information about the debugging of suspend/resume functionality.
+
+2. Testing the driver
+
+Once you have resolved the suspend/resume-related problems with your test 
system
+without the new driver, you are ready to test it:
+
+a) Build the driver as a module, load it and try the STD in the test mode (see:
+Documents/power/basic-pm-debugging.txt, 1a)).
+
+b) Load the driver and attempt to suspend to disk in the "reboot", "shutdown"
+and "platform" modes (see: Documents/power/basic-pm-debugging.txt, 1).
+
+c) Compile the driver directly into the kernel and try the STD in the test 
mode.
+
+d) Attempt to suspend to disk with the driver compiled directly into the kernel
+in the "reboot",

Re: [linux-usb-devel] OOM and USB, latest Linux 2.6

2007-02-17 Thread Alan Stern

On Sat, 17 Feb 2007, Dan Aloni wrote:

> You are right, I looked over this state with kdb, and usb-storage
> waited in usb_stor_bulk_transfer_sg, which does pass GFP_NOIO
> at this scenario.
...

> BTW, soft-rebooting the machine in that state made the USB
> storage device (LEXAR,  JD LIGHTNING II) inaccessible to the
> BIOS. I had to do a complete power cycle in order or the BIOS
> to see it again.

That's the fault of the BIOS and/or the Lexar device.  The BIOS ought to 
do a complete reset of the USB controller and a reset of the device.  If 
the device remains unusable after that, there isn't anything we can do 
about it.

Alan Stern

-
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] Block layer: separate out queue-oriented ioctls

2007-02-17 Thread Joerg Schilling

Jens Axboe <[EMAIL PROTECTED]> wrote:

> > This will make it possible for cdrecord and related programs to
> > retrieve reliably the max_sectors value, regardless of whether the
> > user points it to an sr or an sg device.  In particular, this will
> > resolve Bugzilla entry #7026.
>
> The block bits are fine with me, the sg calling point is a bit of a sore
> thumb (a char driver calling into block layer ioctls) though. So the
> block layer bits are certainly ok with me, if Doug acks the sg bit I'll
> merge everything up.

If you care about this kind of order, you would first need to eliminate the
ability of doing low level things like SG_IO from block drivers as this is 
similar low level stuff that rather belongs to low level drivers.

Any driver that allows to use low level interfaces to send RAW SCSI commands
also needs access to other lowlevel stuff like the ability to know the 
max. DMA size.



Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
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: [RFC PATCH(Experimental) 0/4] Freezer based Cpu-hotplug

Rafael, I am trying to understand try_to_freeze_tasks(), and I have a
couple of questions.

static inline int is_user_space(struct task_struct *p)
{
return p->mm && !(p->flags & PF_BORROWED_MM);
}

This doesn't look right. First, an exiting task has ->mm == NULL after
do_exit()->exit_mm(). Probably not a problem. However, PF_BORROWED_MM
check is racy without task_lock(), so we can have a false positive as
well. Is it ok? We can freeze aio_wq prematurely.


try_to_freeze_tasks:

do_each_thread(g, p) {

if (p->state == TASK_TRACED && frozen(p->parent)) {

Why we are doing this check outside of "if (is_user_space(p))" ?
Not a bug of course, but looks strange.

cancel_freezing(p);
continue;

Is it right? Shouldn't we increment "todo" counter?

}
if (is_user_space(p)) {
if (!freeze_user_space)
continue;

/* Freeze the task unless there is a vfork
 * completion pending
 */
if (!p->vfork_done)
freeze_process(p);


Racy. do_fork(CLONE_VFORK) first does copy_process() which puts 'p' on
the task list and unlocks tasklist_lock. This means that 'p' is visible
to try_to_freeze_tasks(), and p->vfork_done == NULL. try_to_freeze_tasks()
sets TIF_FREEZE.

Now, do_fork() continues, sets ->vfork_done, p goes to user space, notices
the fake signal and goes to refrigerator while its parent is blocked on
"struct completion vfork". Freezing failed.

So, shouldn't we do

if (p->vfork_done)
cancel_freezing(p);

instead?

Thanks,

Oleg.

-
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/

e2b2rom_init_one(): Unable to register resource

2007-02-17 Thread Dan Aloni

Hello,

I'm running the x86_64 arch of Linux 2.6.20 on a Supermicro X6DH8-XG2 
board and I got this during boot:

[248660.950695] device id = 2440
[248660.950699] device id = 2480
[248660.950703] device id = 24c0
[248660.950706] device id = 24d0
[248660.950709] matched device = 24d0
[248660.950712] matched device id 24d0
[248660.950716] pci_read_config_byte : 4
[248660.950723] esb2rom: esb2rom_init_one(): Unable to register resource 
0xffc0-0x - kernel bug?
[248660.950729] esb2rom: ioremap(ffc0, 10040) failed
[248660.956859] retVal = -19

Looks like some kind of a 64-bit portability bug...

-- 
Dan Aloni
XIV LTD, http://www.xivstorage.com
da-x (at) monatomic.org, dan (at) xiv.co.il
-
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 03/44 take 2] [UBI] user-space API header

On Saturday 17 February 2007 17:54, Artem Bityutskiy wrote:
> +struct ubi_mkvol_req {
> +   int32_t vol_id;
> +   int32_t alignment;
> +   int64_t bytes;
> +   int8_t vol_type;
> +   int8_t padding[9];
> +   int16_t name_len;
> +   __user const char *name;
> +} __attribute__ ((packed));

This structure is not suitable for an ioctl call, because it has
incompatible layout between 32 and 64 bit processes. The easiest
fix for this would be to change the 'name' field to an array
instead of a pointer.

Arnd <><
-
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: GPL vs non-GPL device drivers

2007-02-17 Thread David Schwartz

> On 2/17/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:

> > Per this principle, it would seem that only source code and
> > hand-crafted object code would be governed by copyright, since
> > compilation is also an automated process.

> Well, compilation is probably equivalent to "translation", which is
> specifically included in the Act as forming a derivative work.

I would hope that courts will hold that "translation" still means what it
originally meant -- the creative process of converting a work from one
language to another where one has to choose how to map the concepts behind a
work to the most appropriate concept in a different language. Clearly
translating Jabberwocky into German is creative in a way that compiling the
Linux kernel from C to x86 binary is not.

Interestingly, if you are right, then what online translation services like
babelfish (that allow you to see a web site in another language) do is
probably illegal as they create derivative works without permission of the
copyright holder. It's easy to argue that putting up a web site grants
people implicit permission to copy and render it so that they can see it,
but much harder to argue that it gives them the right to create a derivative
work. (Of course, you could argue fair use.)

As far as I know, no court has addressed this issue. But I think the
sensible thing is to hold that "translation", in copyright law, is meant as
an example of one type of creative process that could create a derivative
work, not that any process that can be argued to be translation (whether
creative or not) automatically makes the result a work for copyright
purposes.

But you never know.

DS

-
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: [RFC] killing the NR_IRQS arrays.


> > #define NO_IRQ  
> 
> When did you need a magic constant NO_IRQ in generic code.
> One of the reasons I want to convert the drivers is so we can
> kill the NO_IRQ nonsense.
> 
> As for struct irq.  Instead of struct irq_desc I really don't
> care, although the C++ camp hasn't not yet weighed in and mentioned
> how that creates a namespace conflict for them. 

Yeah, NO_IRQ would be NULL here...

What I do on the powerpc code is since IRQ HW numbers are defined
locally to a domain/PIC, when creating a new domain, The PIC code passes
a value to use as an "illegal" value in that domain. It's not exposed
outside of the core though, it's really only used to initialize the
remapping table with something before any interrupt on that PIC has been
mapped. 

> We might need this.  But I don't think we need reference counting in
> the traditional sense.  For all practical purpose we already have
> dynamic irq allocation and it hasn't proven necessary.  I would
> prefer to go to lengths to avoid having to expose that kind of
> an issue to driver code.

I think we do need proper refcounting, but I also think that most
drivers will not need to see it.

For example, a PCI driver will most probably just do something along the
lines of the existing request_irq(pdev->irq), the liftime of pdev->irq
is managed by the PCI core.

Same goes with MSIs imho, the MSI core can manage the lifetime
transparently.

Ben.


-
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 09/44 take 2] [UBI] debug unit header

On Saturday 17 February 2007 17:55, Artem Bityutskiy wrote:
> +
> +/**
> + * UBI debugging unit.
> + *
> + * UBI provides rich debugging capabilities which are implemented in
> + * this unit.

Stop right here. You should be doing one thing and do it right.
Since the point of your patches is to do volume management for MTD,
it should do just that.

If you feel that Linux needs rich debugging capabilities, then submit
a patch for that independent of UBI.

Arnd <><
-
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: [RFC] killing the NR_IRQS arrays.

On Sat, 2007-02-17 at 02:06 -0700, Eric W. Biederman wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> 
> > In addition, if we remove the numbers, archs will need basically the
> > exact same services provided by the powerpc irq core for reverse mapping
> > (going from a HW irq number on a given PIC back to an irq_desc *).
> 
> Ben you seem to be under misapprehension that except for the case of
> ISA (0-16) the linux IRQ number is a hardware number.  It is an arbitrary
> software enumeration, and I think it has been that way a very long time.

Did you actually mean "is not a hardware number" ? If not, then I don't
understand your sentence...

> I can only tell you that my impression of this last is that all the
> world's not a PPC.

Yeah and my grandmother is not the pope, thank you.

However, PowerPC is a good example because it has such a diversity of
very different hardware setups to deal with, ranging from the multiple
layers of cascading controllers all over the place, to interrupts
packets encoding vector/target etc... a bit like x86 on cell, to
hypervisors providing a single giant number space etc etc etc...

Thus, it is extremely likely that something that works well for PowerPC
(or for ARM for that matter as it's probably as a "colorful" environment
as PowerPC is) will end up being useful for others.

> I have a version of the x86 code with a partial conversion done and
> I didn't need a reverse mapping.  What you call the hardware interrupt
> number never happens to be interesting to me after the system is setup.

Because you have the ability to tell your PIC to give you your "linux"
interrupt number when actually sending the interrupt to the processor ?
You need a way to get to the irq_desc * when getting an IRQ, either you
have a way to map HW numbers back to irq_desc * in sofrware, or your HW
allows you to do it.

> I do suspect there may be an interesting chunk of your ppc work that
> probably makes sense as a library so other arches could use it.

Guess what, one of the options of my code is to not instanciate a
remapper... for archs where it's not necessary. (We have the case for
example of iSeries whose hypervisor can return us the number we want for
an arbitrary interrupt).

Now, I'm not saying we should take the PowerPC code and say "hey' here's
the new generic code".

I'm saying that if we're going to change the IRQ stuff that deeply, it
would be nice if we looked into some of that stuff I've done that I
beleive would be of use for other archs (though you seem to imply that
it would be of no use on x86, good, still...).

I found it overall very useful to have a generic remapping core and have
cascaded PIC setups have a numbering domain local to a given PIC (pretty
much, a domain != an irq_chip) and I'm convinced it would make life
easier for archs with similar setups. The remapping core also shows its
usefulness on archs with very big interrupt numbers, like sparc or
pSeries ppc, and possibly others.

Now, I -do- have a problem with one aspect of your proposed design which
is to keep the "linux" interrupt number in the generic irq_desc, which I
think defeats most of the purpose of moving away from those linux irq
numbers. If you do so, then I'll have to keep a separate remapping layer
and keep a mecanism for virtualizing linux numbers.

Ben.

-
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: GPL vs non-GPL device drivers


On 2/17/07, Scott Preece <[EMAIL PROTECTED]> wrote:

Well, compilation is probably equivalent to "translation", which is
specifically included in the Act as forming a derivative work.


Nix.  "Translation" is something that humans do.  What's governed by
copyright is the creative expression contained in a work, and it makes
no difference whether it's source code or object code, RTL or silicon,
PDF or parchment.  There's a requirement of tangible fixation for
registration purposes, so you can't claim copyright on a story that's
in your head which you haven't written down.  But what's copyrightable
about a computer program is neither the "ideas and methods of
operation" nor the blob of bits (compiled or not); it's the
idiosyncrasies, the human touches, the things that would differ
between two equally skilled coders' ways of putting those ideas into
language.

A judge doesn't care whether a C compiler will spin silk purses or
spit chunks when fed this language, except insofar as duplicating
another coder's language (by trial and error or by blatant, arrant,
heartless enslavement of poor little bytes in ROM) is obligatory in
order to build a silk-purse-spinner.  You can't claim copyright on the
only way to accomplish some engineering purpose.  Even if that purpose
is to interoperate with, or even substitute for, someone else's
software or hardware in a way that destroys its marketability or turns
its author's moral imperatives into subjunctives.  Them's the breaks,
folks; if you don't like it, write poetry instead.  (And don't use it
as a passphrase for a printer cartridge.)

(You also can't claim copyright on something that isn't your work of
authorship, so you can't just write down someone else's sermon and go
obtain copyright registration on it.  Or rather, you can, but you will
lose when you try to sue someone else for infringing it, because
you've falsified the registration.  Under the Berne Convention, you
have also not spoiled the actual author's opportunity to write it
down, register her copyright, and sue you and anyone else for
infringing it.  People who thought they licensed it legitimately from
the ostensible copyright holder may have a defense of innocent
infringement, depending on whether the author can demonstrate
negligence according to the usual tort standards in the relevant
jurisdiction.  Copyright infringement is a statutory tort, and the
only limits to contracting away the right to sue for this tort are
those provided in the copyright statute itself.  A contract not to sue
for tort is called a "license".)

Again, I recommend the Lexmark v. Static Control decision to you.  It
references the major appellate decisions in this space from the late
70's forward, mostly from the 9th and 2nd Circuits.  The full text is
available from FindLaw; the few older decisions not available from
FindLaw are easily Googled.  Or you could just mine the debian-legal
archives for the links; sadly, 80% or more of the actual citations to
case law or statute in the debian-legal archives are in my
handwriting, so you can't take that as an independent source of
information.

Cheers,
- Michael
-
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 41/44 take 2] [UBI] gluebi unit header