date:20070215


Linus Torvalds wrote:


On Thu, 15 Feb 2007, Jeff Garzik wrote:

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index db185f3..d51f0f1 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -22,6 +22,7 @@ config IA64
 
 config 64BIT

bool
+   select ATA_NONSTANDARD if ATA
default y


Ok, this is just _strange_.


Agreed.


Tying ATA_NONSTANDARD into ia64 by tying it to the 64BIT config variable 
may work (well, I _assume_ it does), but it's just psychedelic.


AFAICT it's an attempt to do an unconditional 'select'.  I'm /not/ 
disputing its psychedilic properties, certainly, just figured that was 
the way that IA64 arch folks did stuff like this.




How about adding a separate config entry like

config IA64_ATA
bool
depends on ATA
select ATA_NONSTANDARD
default y

which kind of makes sense when you squint just the right way..


Either way, that seems sane to me.  I'd love to have some IA64 folks to 
comment though.


Jeff


-
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-15 Thread v j

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

On 2/15/07, v j <[EMAIL PROTECTED]> wrote:
> So far I have heard nothing but, "if you don't contribute, screw you."
> All this is fine. Just say so. Make it black and white. Make it
> perfectly clear what is and isn't legal. If we can't load proprietary
> modules, then so be it. It will help everybody if this is out in the
> clear, instead of resorting to stupid half measures like
> EXPORT_SYMBOL_GPL.
---

I'm not sure what you're asking for. Greg KH's statement was pretty
black-and-white, and there are a lot of comments in this stream, from
name-brand developers, that are in line with them. They're the best
answer you can hope for on this question. The question you're asking
is an issue of interpretation, which only a court can answer. Do you
want them to modify the license to make this particular issue clearer?
Or do you just want a statement from Linus?

Which statement are you talking about? First of all it is not clear to
me if proprietary modules need to be GPL or not. If they do, I guess I
have nothing to say. If that is the way developers want it, so be it.

Assuming these need not be GPL, I have a problem with
EXPORT_SYMBOL_GPL and the general trend in the direction of making
proprietary drivers harder on companies. Our drivers use basic
interfaces in the kernel like open, read, write, ioctl, semaphores,
interrupts, timers etc. This is functionality we would expect from any
operating system. We used devfs before and had no problems there. Greg
KH has gone and made the basic sysfs interface, which any generic
driver could use as EXPORT_SYMBOL_GPL. I don't really care, I just
don't use sysfs. The point is that old functionality is being ripped
off and new ones introduced, and their interfaces are not open
anymore. Hence there will be a point where non-GPLed drivers simply
cannot be loaded.

So why beat about the bush? Just make it illegal to load proprietary
drivers, or remove EXPORT_SYMBOL_GPL.

vj.
-
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] Optimize generic get_unaligned / put_unaligned implementations.

2007-02-15 Thread Ralf Baechle

On Thu, Feb 15, 2007 at 05:27:20PM -0800, Andrew Morton wrote:

> No, icc surely supports attribute(packed).  My point is that we shouldn't
> rely upon the gcc info file for this, because other compilers can (or
> could) be used to build the kernel.
> 
> So it would be safer if the C spec said (or could be interpreted to say)
> "members of packed structures are always copied bytewise".  So then we
> can be reasonably confident that this change won't break the use of
> those compilers.
> 
> But then, I don't even know if any C standard says anything about packing.

Memory layout and alignment of structures and members are implementation
defined according to the C standard; the standard provides no means to
influence these.  So it takes a compiler extension such as gcc's
__attribute__().

> Ho hum.  Why are we talking about this, anyway?  Does the patch make the
> code faster?  Or just nicer?

Smaller binary and from looking at the disassembly a tad faster also.

  Ralf
-
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-15 Thread Lee Revell


On 2/15/07, Greg Trounson <[EMAIL PROTECTED]> wrote:

I wasn't disputing legal problems with proprietary drivers nor suggesting 
people ignore
the issue.  I was trying to make the point that Linux is adversely affected 
when lots of
users, proprietary developers or otherwise, abandon Linux, and the issue might 
be more
serious than people here think.

IMO the lack of provision for proprietary drivers in the GPL is a problem.  Not
necessarily one we can do anything about now the horse has bolted, but a 
problem nonetheless.


What has changed lately that would cause anyone to "abandon Linux"?
The rules are the same as they have ever been, and Linux is more
popular than ever in the embedded market.

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/

Re: [PATCH] Linux Kernel Markers Documentation

2007-02-15 Thread Randy Dunlap

On Thu, 15 Feb 2007 20:33:48 -0500 Mathieu Desnoyers wrote:

> Linux Kernel Markers - Documentation
> 
> Here is some documentation explaining what is/how to use the Linux
> Kernel Markers.
> 
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> 
> --- /dev/null
> +++ b/Documentation/marker.txt
> @@ -0,0 +1,130 @@
> +  Using the Linux Kernel Markers
> +
> + Mathieu Desnoyers
> +
> +
> + This document discusses the purpose of markers. It shows some usage
> +examples of the Linux Kernel Markers : how to insert markers within the 
> kernel
> +and how to connect probes to a marker. Finally, it has some probe module
> +examples. This is what connects to a marker.
> +
> +
> +* Purpose of markers
> +
> +You can put markers at important locations in the code. They act as
> +lightweight hooks that can pass an arbitrary number of parameters,
> +described in a printk-like format string, to a function whenever the marker
> +code is reached.
> +
> +They can be used for tracing (LTTng, LKET over SystemTAP), overall 
> performance
> +accounting (SystemTAP). They could also be used to implement
> +efficient hooks for SELinux or any other subsystem the would have this
  that

> +kind of need.
> +
> +Using the markers for system audit (SELinux) would require to pass a
> +variable by address that would be later checked by the marked routine.
> +
> +
> +* Usage
> +
> +MARK(subsystem_event, "%d %s %p[struct task_struct]",
> +  someint, somestring, current);
> +Where :
> +- Subsystem is the name of your subsystem.
> +- event is the name of the event to mark.

so is the MARK() supposed to be:
  MARK(subsystem, event, ...

Please make the 2 doc. lines above match the parameters...
or the parameters match the text.

> +- "%d %s %p[struct task_struct]" is the formatted string for (printk-style).
> +- someint is an integer.
> +- somestring is a char pointer.
> +- current is a pointer to a struct task_struct.
> +
> +The expression %p[struct task_struct] is a suggested marker definition
> +standard that could eventually be used for pointer type checking in
> +sparse. The brackets contain the type to which the pointer refer.
  refers.

> +
> +The marker mechanism supports multiple instances of the same marker.
> +Markers can be put in inline functions, inlined static functions and
> +unrolled loops.
> +
> +Note : It is safe to put markers within preempt-safe code : preempt_enable()
> +will not call the scheduler due to the tests in preempt_schedule().
> +
> +
> +* Optimization for a given architecture
> +
> +You will find, in asm-*/marker.h, optimisations for given architectures
> +(currently i386 and powerpc). They use a load immediate instead of a data 
> read,
> +which saves a data cache hit, but also requires cross CPU code modification. 
> In
> +order to support embedded systems which use read-only memory for their code, 
> the
> +optimization can be disabled through menu options.
> +
> +
> +* Probe example
> +
> +-- CUT -
> +/* probe-example.c
> + *
> + * Loads a function at a marker call site.
> + *
> + * (C) Copyright 2007 Mathieu Desnoyers <[EMAIL PROTECTED]>
> + *
> + * This file is released under the GPLv2.
> + * See the file COPYING for more details.
> + */
> +
> +#include 
> +#include 
> +
> +#define SUBSYSTEM_EVENT_FORMAT "%d %s %p[struct task_struct]"

Is SUBSYSTEM_EVENT_FORMAT used implicitly below?  or elsewhere?

> +void probe_subsystem_event(const char *format, ...)
> +{
> + va_list ap;
> + /* Declare args */
> + unsigned int value;
> + const char *mystr;
> + struct task_struct *task;
> +
> + /* Assign args */
> + va_start(ap, format);
> + value = va_arg(ap, typeof(value));
> + mystr = va_arg(ap, typeof(mystr));
> + task = va_arg(ap, typeof(task));
> +
> + /* Call tracer */
> + trace_subsystem_event(value, mystr, task);
> +
> + /* Or call printk */
> + vprintk(format, ap);
> +
> + /* or count, check rights... */
> + 
> + va_end(ap);
> +}
> +
> +static int __init probe_init(void)
> +{
> + int result;
> + result = marker_set_probe("subsystem_event",
> + FS_CLOSE_FORMAT,
> + probe_fs_close);

Do FS_CLOSE_FORMAT and probe_fs_close() need to be defined here?
I.e., is this a complete example?

> + if (!result)
> + goto cleanup;
> + return 0;
> +
> +cleanup:
> + marker_remove_probe(probe_subsystem_event);
> + return -EPERM;
> +}
> +
> +static void __exit probe_fini(void)
> +{
> + marker_remove_probe(probe_subsystem_event);
> +}
> +
> +module_init(probe_init);
> +module_exit(probe_fini);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Mathieu Desnoyers");
> +MODULE_DESCRIPTION("SUBSYSTEM Probe");
> +-- CUT --

Re: GPL vs non-GPL device drivers


On 2/15/07, Gene Heskett <[EMAIL PROTECTED]> wrote:


This definition seems to be a bit like nailing jelly to a tree in that so
far only one companies legal dept has pursued this to the point of
actually getting a court verdict rendered.  That was the German ruling a
link was given to earlier in this thread(s).

---

The German decision did not go anywhere near the question of kernel
modules. It was a nice victory that the court decided the license was
enforceable, but the details of the license are still largely
untested.

---

...



I'm a bit like Clint Eastwood here, do you feel lucky?  If not, then
please comply with the terms of the software you have chosen to base your
product on.

---

Note that it's not just "lucy", but "rich". Both sides would spend a
LOT of money if this went to court in the US. And, of course, "the
terms of the software [license]" are exactly what the case would be
deciding. There wouldn't be a case unless the two parties had
different views of the terms of the license.

---

As you have been told here repeatedly, a distribution to
your customers of code that is based on the GPL'd kernel headers does
bring you into non-compliance with the terms of the GPL.  You can do
anything you want in house, but the minute that code ships, that is
a "distribution" and the GPL applies in full force in that its all made
GPL, or you cannot legally ship it.  I don't know how it can be said any
plainer than that.  But of course IANAL, so talk to yours, please.

---

I also ANAL, but even so I can point out that your assertion and Greg
KH's assertions do not have the force of law.  Questions like "what is
a derived work" and "what does 'unrelated' mean" in the license are
just not black-and-white.

I don't like niggling about interpretation, either, especially with
material that someone has contributed to the community; I think it's
rude and possibly unethical and that not testing the limits avoids any
danger of impropriety. But claiming it's clear what the license
requires is simply misleading.

scott
-
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-15 Thread sfaibish

On Thu, 15 Feb 2007 14:46:34 -0500, Jan Engelhardt  
<[EMAIL PROTECTED]> wrote:




On Feb 15 2007 21:38, Andi Kleen wrote:


Also I would expect your design to be slow for metadata read intensive
workloads. E.g. have you tried to boot a root partition with dual fs?
That's a very important IO benchmark for desktop Linux systems.


Did someone say metadata intensive? Try kernel tarballs, they're a
perfect workload. Tons of directories, and even more files here and
there. Works wonders.


I just did now per your request. To make things more relevant I
created a file structure from the 2.4.19 kernel sources and repeated it
recursively into the deepest dir level (10) 4 times ending up with
7280 directories with 40 levels of directories depth and 1 GB
data set size. I run both tar and untar operations on the tree
for ext3, reiserfs, jfs and DualFS. I remounted the FS before
each test. I end up with 7280 directories 40 levels depth and
1 GB data. Both tar file and directory tree were on the FS under
test.

Here are the results - elapse time in sec:
tar untar
ext3:   144 143
reiserfs:   100 100
JFS:196 140
DualFS: 63  54

Hope this helps.



Jan


/Sorin

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Linux Kernel Markers Documentation

Linux Kernel Markers - Documentation

Here is some documentation explaining what is/how to use the Linux
Kernel Markers.

Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>

--- /dev/null
+++ b/Documentation/marker.txt
@@ -0,0 +1,130 @@
+Using the Linux Kernel Markers
+
+   Mathieu Desnoyers
+
+
+   This document discusses the purpose of markers. It shows some usage
+examples of the Linux Kernel Markers : how to insert markers within the kernel
+and how to connect probes to a marker. Finally, it has some probe module
+examples. This is what connects to a marker.
+
+
+* Purpose of markers
+
+You can put markers at important locations in the code. They act as
+lightweight hooks that can pass an arbitrary number of parameters,
+described in a printk-like format string, to a function whenever the marker
+code is reached.
+
+They can be used for tracing (LTTng, LKET over SystemTAP), overall performance
+accounting (SystemTAP). They could also be used to implement
+efficient hooks for SELinux or any other subsystem the would have this
+kind of need.
+
+Using the markers for system audit (SELinux) would require to pass a
+variable by address that would be later checked by the marked routine.
+
+
+* Usage
+
+MARK(subsystem_event, "%d %s %p[struct task_struct]",
+  someint, somestring, current);
+Where :
+- Subsystem is the name of your subsystem.
+- event is the name of the event to mark.
+- "%d %s %p[struct task_struct]" is the formatted string for (printk-style).
+- someint is an integer.
+- somestring is a char pointer.
+- current is a pointer to a struct task_struct.
+
+The expression %p[struct task_struct] is a suggested marker definition
+standard that could eventually be used for pointer type checking in
+sparse. The brackets contain the type to which the pointer refer.
+
+The marker mechanism supports multiple instances of the same marker.
+Markers can be put in inline functions, inlined static functions and
+unrolled loops.
+
+Note : It is safe to put markers within preempt-safe code : preempt_enable()
+will not call the scheduler due to the tests in preempt_schedule().
+
+
+* Optimization for a given architecture
+
+You will find, in asm-*/marker.h, optimisations for given architectures
+(currently i386 and powerpc). They use a load immediate instead of a data read,
+which saves a data cache hit, but also requires cross CPU code modification. In
+order to support embedded systems which use read-only memory for their code, 
the
+optimization can be disabled through menu options.
+
+
+* Probe example
+
+-- CUT -
+/* probe-example.c
+ *
+ * Loads a function at a marker call site.
+ *
+ * (C) Copyright 2007 Mathieu Desnoyers <[EMAIL PROTECTED]>
+ *
+ * This file is released under the GPLv2.
+ * See the file COPYING for more details.
+ */
+
+#include 
+#include 
+
+#define SUBSYSTEM_EVENT_FORMAT "%d %s %p[struct task_struct]"
+void probe_subsystem_event(const char *format, ...)
+{
+   va_list ap;
+   /* Declare args */
+   unsigned int value;
+   const char *mystr;
+   struct task_struct *task;
+
+   /* Assign args */
+   va_start(ap, format);
+   value = va_arg(ap, typeof(value));
+   mystr = va_arg(ap, typeof(mystr));
+   task = va_arg(ap, typeof(task));
+
+   /* Call tracer */
+   trace_subsystem_event(value, mystr, task);
+
+   /* Or call printk */
+   vprintk(format, ap);
+
+   /* or count, check rights... */
+   
+   va_end(ap);
+}
+
+static int __init probe_init(void)
+{
+   int result;
+   result = marker_set_probe("subsystem_event",
+   FS_CLOSE_FORMAT,
+   probe_fs_close);
+   if (!result)
+   goto cleanup;
+   return 0;
+
+cleanup:
+   marker_remove_probe(probe_subsystem_event);
+   return -EPERM;
+}
+
+static void __exit probe_fini(void)
+{  
+   marker_remove_probe(probe_subsystem_event);
+}
+
+module_init(probe_init);
+module_exit(probe_fini);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Mathieu Desnoyers");
+MODULE_DESCRIPTION("SUBSYSTEM Probe");
+-- CUT -
+
-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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/05] Linux Kernel Markers - kernel 2.6.20

* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Sun, 11 Feb 2007 15:03:22 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> 
> wrote:
> 
> > You will find, in the following posts, the latest revision of the Linux 
> > Kernel
> > Markers.
> 
> 
> 

I guess the header of include/linux/marker.h should go into
Documentation/marker.txt. Will fix. Will be in the next reply.

> And what can I do with these markers?
> 

You can put markers at important locations in the code. They act as
lightweight hooks that can pass an abitrary number of parameters,
described in a printk-like format string, to a function.

They can be used for tracing (LTTng, LKET over SystemTAP), overall
performance accounting (SystemTAP). They could also be used to implement
efficient hooks for SELinux or any other subsystem the would have this
kind of need.

> And once I've done it, are there any userspace applications I can use to
> get the data out in human-usable form?
> 

LTTng and LTTV, SystemTAP (should be updated to the new API).

> It seems to me that these patches aren't sequenced correctly - the kernel 
> won't
> build at each step of the patch sequence.  Maybe I'm mistaken in that.  We 
> prefer
> it this way so that people don't hit wont-compile points when doing bisection 
> searches.

Will fix for the next complete post.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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] Optimize generic get_unaligned / put_unaligned implementations.

On Fri, 16 Feb 2007 00:43:17 +
Ralf Baechle <[EMAIL PROTECTED]> wrote:

> On Thu, Feb 15, 2007 at 03:38:23PM -0800, Andrew Morton wrote:
> 
> > hm.  So if I have
> > 
> > struct bar {
> > unsigned long b;
> > } __attribute__((packed));
> > 
> > struct foo {
> > unsigned long u;
> > struct bar b;
> > };
> > 
> > then the compiler can see that foo.b.b is well-aligned, regardless of the
> > packedness.
> > 
> > Plus some crazy people compile the kernel with icc (or at least they used
> > to).  What happens there?
> 
> A quick grep for __attribute__((packed)) and __packed find around 900 hits,
> I'd probably find more if I'd look for syntactical variations.  Some hits
> are in arch/{i386,x86_64,ia64}.  At a glance it seems hard to configure a
> useful x86 kernel that doesn't involve any packed attribute.  I take that
> as statistical proof that icc either has doesn't really work for building
> the kernel or groks packing.  Any compiler not implementing gcc extensions
> is lost at building the kernel but that's old news.
> 

No, icc surely supports attribute(packed).  My point is that we shouldn't
rely upon the gcc info file for this, because other compilers can (or
could) be used to build the kernel.

So it would be safer if the C spec said (or could be interpreted to say)
"members of packed structures are always copied bytewise".  So then we
can be reasonably confident that this change won't break the use of
those compilers.

But then, I don't even know if any C standard says anything about packing.

Ho hum.  Why are we talking about this, anyway?  Does the patch make the
code faster?  Or just nicer?
-
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] sparse chokes on arch/i386/kernel/i8253.c

On Thu, 15 Feb 2007 19:58:04 -0500
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:

> > > 
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -309,7 +309,8 @@ AFLAGS_KERNEL =
> > >  LINUXINCLUDE:= -Iinclude \
> > > $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
> > >  -include include/linux/autoconf.h \
> > > --include linux/marker.h
> > > +-include \
> > > + $(if $(KBUILD_SRC),$(srctree)/)include/linux/marker.h
> > >  
> > >  CPPFLAGS:= -D__KERNEL__ $(LINUXINCLUDE)
> > 
> > But what is so magical about marker.h to justify special-case treatment at 
> > the
> > kbuid level?
> 
> Idealistically speaking, nothing. It is however much easier to maintain
> an external set of patches introducing markers within the kernel tree :
> most of the rejects between kernel version comes from new includes that
> comes in the way.
> 
> So this is there more by convenience than requirement.

No sale.  Let's kill it, please ;)
-
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 1/3] Input: psmouse - create PS/2 protocol options for Kconfig

On Thu, 15 Feb 2007 19:55:29 -0500
Andres Salomon <[EMAIL PROTECTED]> wrote:

> Andrew Morton wrote:
> > On Thu, 15 Feb 2007 05:08:21 -0500
> > Andres Salomon <[EMAIL PROTECTED]> wrote:
> > 
> >> Initial framework for disabling PS/2 protocol extensions.  The current
> >> protocols can only be disabled if CONFIG_EMBEDDED is selected.  No
> >> source files are changed, merely build stuff.
> > 
> > ugleee.  What benefit do we get for all this additional maintenance burden?
> 
> On any platform where you know exactly what ps/2 device you'll have
> plugged in, you can cut the size of psmouse.ko in half by disabling
> protocol extensions that are not in use.

hm, saving 4k or so.

Oh well, let's leave that up to Dmitry.

> For future protocol extension additions, we can add them without making
> the psmouse driver even larger.  We have one queued up for OLPC's
> touchpad which we'd like to get included in mainline, and it was made
> clear that being able to disable protocol extensions was a prerequisite
> for getting it included.  The OLPC ps/2 protocol extension would be
> disabled unless CONFIG_EMBEDDED and CONFIG_MOUSE_PS2_OLPC were both enabled.
> 
> See http://lkml.org/lkml/2006/9/11/200

Perhaps a nicer implementation would be to have a separate .c file for each
variant.
-
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-15 Thread David Lang


On Thu, 15 Feb 2007, Scott Preece wrote:


On 2/15/07, Miguel Ojeda <[EMAIL PROTECTED]> wrote:


Stupid, maybe. But some people just don't want closed-source
projects/companies like yours using their free work, without any kind
of feedback. Some others don't care, but they could in the future, as
it is their code, and that is your risk.


---

So, how are such companies any different from the myriad individuals
and companies that use Linux on the desktop or in their server rooms
without ever modifying it and who also contribute nothing back to the
community? They are also, in many (most?) cases taking advantage of
the free (as in beer) nature of Linux - saving money by using the work
of others without returning anything, but the product builders seem to
get a lot more abuse...


if they don't modify it and don't distribute it there is not issue.

it's people who modify it (by creating a derived work) and then redistribute it 
that get the abuse.


now if your kernel module is _not_ a derived work (and such things can exist, 
much as some people don't want to admit it) then you don't have a problem 
either.


but the definition of what is a derived work is not cut-and-dry, and that is 
where you have to get lawyers involved if you care.


I am _not_ a lawyer, but there are two basic approaches you can take

1. The easy way out is to release the module source under a GPL compatable 
license.


2. If you don't want to do this you need to involve the lawyers to tell you if 
they think that your development work is derived or not, and even if you decide 
that it isn't you may have to prove that it's not in court, potentially in 
multiple juristrictions (in the relativly unlikly event that you offend enough 
different kernel developers that they take the time to sue you individually).


I believe that it's extremely unusual for a lawyer to give a cut-and-dry answer 
to a liability question, so from a liability point of view it seems clear cut.


what your company needs to decide is if they consider the risk to their "IP" to 
be outweight the costs of #2, including the risk that the lawyer is wrong and a 
cour may order you to stop distributing the product unless you comply with the 
GPL.


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

Using sched_clock for mmio-trace

2007-02-15 Thread Jeff Muizelaar

I've built a tool with the goal of logging mmio writes and reads by
device drivers. See http://nouveau.freedesktop.org/wiki/MmioTrace.

I'd like to add support for recording a time stamp on each read and
write. Unfortunately, I am not sure which clock api I should use.

I had a look at blktrace and saw that it uses 'sched_clock()' for time
stamps. However, this symbol is not exported to modules, and from what
I've read it sounds like its use is discouraged.

The question is, what api should I be using? I need something that can
be called from inside interrupt handlers, and obviously the more
accurate and the lower the overhead the better.

-Jeff
-
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/15/07, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:

On Thu, 15 Feb 2007, v j wrote:



Personally, I see no real difference between EXPORT_SYMBOL and
EXPORT_SYMBOL_GPL.
If you derive from GPL'ed code, your code is a derived work.

---

I agree with you that there's no difference in law, though I think the
difference is that neither creates a derived work. "Derived work" is a
very vague notion in law, and the case law on this has varied over
time. I think it would be a real crap shoot for both sides to bring
this to court, at least in the US.

Note, though, that I DO support the OSS equation and believe that
companies *should not* use closed-source modules, whether it's legal
or not, except in the very specific case of code that also works with
other systems. I think this ethical imperative goes with the nature of
the author's gift to the community.

scott
-
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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)

On Thu, 15 Feb 2007 19:37:39 -0500
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:

> > For what reason was that change made?
> > 
> 
> It was made so that we can use the markers in C code without actually
> including marker.h everywhere. I am sure someone has a better way to do
> it : I would be happy to use this-nice-build-system-feature-I-missed to
> have marker.h included.

Oh.  One could whack it in kernel.h: pretty much everything includes that.

But it'd be better to simply require that the clients of this
infrastructure include the appropriate header file.  We do that for
everything else and markers aren't special in this regard.
-
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] serial driver PMC MSP71xx, kernel linux-mips.git master

On Thu, 15 Feb 2007 13:26:29 -0600
Marc St-Jean <[EMAIL PROTECTED]> wrote:

> + status = *(volatile u32 *)up->port.private_data;

It distresses me that this patch uses a variable which this patch
doesn't initialise anywhere.  It isn't complete.

The sub-driver code whch sets up this field shuld be included in the
patch, no?
-
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/15/07, Miguel Ojeda <[EMAIL PROTECTED]> wrote:


Stupid, maybe. But some people just don't want closed-source
projects/companies like yours using their free work, without any kind
of feedback. Some others don't care, but they could in the future, as
it is their code, and that is your risk.


---

So, how are such companies any different from the myriad individuals
and companies that use Linux on the desktop or in their server rooms
without ever modifying it and who also contribute nothing back to the
community? They are also, in many (most?) cases taking advantage of
the free (as in beer) nature of Linux - saving money by using the work
of others without returning anything, but the product builders seem to
get a lot more abuse...

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

[PATCH] update Doc/oops-tracing.txt for TAINT_USER

2007-02-15 Thread Randy Dunlap

From: Randy Dunlap <[EMAIL PROTECTED]>

Add TAINT_USER description to Tainted flags in oops-tracing.txt.

Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
 Documentation/oops-tracing.txt |3 +++
 1 file changed, 3 insertions(+)

--- linux-2.6.20-git9.orig/Documentation/oops-tracing.txt
+++ linux-2.6.20-git9/Documentation/oops-tracing.txt
@@ -234,6 +234,9 @@ characters, each representing a particul
   6: 'B' if a page-release function has found a bad page reference or
  some unexpected page flags.
 
+  7: 'U' if a user specifically requested that the Tainted flag be set,
+ ' ' otherwise.
+
 The primary reason for the 'Tainted: ' string is to tell kernel
 debuggers if this is a clean kernel or if anything unusual has
 occurred.  Tainting is permanent: even if an offending module is
-
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] sparse chokes on arch/i386/kernel/i8253.c

* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Thu, 15 Feb 2007 19:23:47 -0500
> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> 
> > sparse chokes on arch/i386/kernel/i8253.c
> > 
> > Here is a marker fix that puts the correct -i include/linux/marker.h in
> > the top level Makefile so sparse works correctly. The tricky part is to
> > keep the kernel compiling correctly with a kernel build directory
> > different from the kernel source tree too.
> > 
> > The fix applies on top the the Linux Kernel Markers for 2.6.20.
> > 
> > Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> > 
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -309,7 +309,8 @@ AFLAGS_KERNEL   =
> >  LINUXINCLUDE:= -Iinclude \
> > $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
> >-include include/linux/autoconf.h \
> > -  -include linux/marker.h
> > +  -include \
> > +   $(if $(KBUILD_SRC),$(srctree)/)include/linux/marker.h
> >  
> >  CPPFLAGS:= -D__KERNEL__ $(LINUXINCLUDE)
> 
> But what is so magical about marker.h to justify special-case treatment at the
> kbuid level?

Idealistically speaking, nothing. It is however much easier to maintain
an external set of patches introducing markers within the kernel tree :
most of the rejects between kernel version comes from new includes that
comes in the way.

So this is there more by convenience than requirement.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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/15/07, Theodore Tso <[EMAIL PROTECTED]> wrote:


But so what?  How will that hurt *Linux*?  If the Embedded developers
don't contribute changes back, it doesn't hurt us any if they go away
and start paying $$$ to VxWorks instead of using Linux for free.

---

Well, this is somewhat oversimplified. If the device supports add-on
software, that may be good for the FLOSS community even if the
underlying OS is partly closed. And if they're returning changes and
patches from any work they do in the code kernel (aside from their
drivers), that is also good for the community. And there is some value
to the community in their hiring and/or growing developers who may
later contribute directly to the kernel. And there is even some value
in just the publicity and hype for Linux, which helps bring new people
in. I'm not saying those things are worth "enough", just that they're
worth
something.

---

Contrawise, if Embedded developers do contribute their device driver
changes back to the kernel, they will be fine.  ...

---

In fairness, though, some of the developers WILL bitch about your not
using a recent kernel and not providing patches until products ship,
despite that meeting the letter of the license. Some of the notes in
this thread do exactly that. And I HAVE seen real developers say
something very close to "Your code is based on a kernel too old to
have any value to us" even though they would also claim abuse if the
code hadn't been made available at all. And I've seen lots of cases
where laptop-centric developers rejected or simply ignored code
submitted by embedded developers.

I'm completely in line with participating fully in the community, but
it's important that the mainstream developers recognize that the
community is bigger than the laptop/server-room crowd.

scott
-
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 1/3] Input: psmouse - create PS/2 protocol options for Kconfig

2007-02-15 Thread Andres Salomon

Andrew Morton wrote:
> On Thu, 15 Feb 2007 05:08:21 -0500
> Andres Salomon <[EMAIL PROTECTED]> wrote:
> 
>> Initial framework for disabling PS/2 protocol extensions.  The current
>> protocols can only be disabled if CONFIG_EMBEDDED is selected.  No
>> source files are changed, merely build stuff.
> 
> ugleee.  What benefit do we get for all this additional maintenance burden?

On any platform where you know exactly what ps/2 device you'll have
plugged in, you can cut the size of psmouse.ko in half by disabling
protocol extensions that are not in use.

For future protocol extension additions, we can add them without making
the psmouse driver even larger.  We have one queued up for OLPC's
touchpad which we'd like to get included in mainline, and it was made
clear that being able to disable protocol extensions was a prerequisite
for getting it included.  The OLPC ps/2 protocol extension would be
disabled unless CONFIG_EMBEDDED and CONFIG_MOUSE_PS2_OLPC were both enabled.

See http://lkml.org/lkml/2006/9/11/200
-
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 1/3] Input: psmouse - create PS/2 protocol options for Kconfig

On Thu, 15 Feb 2007 05:08:21 -0500
Andres Salomon <[EMAIL PROTECTED]> wrote:

> Initial framework for disabling PS/2 protocol extensions.  The current
> protocols can only be disabled if CONFIG_EMBEDDED is selected.  No
> source files are changed, merely build stuff.

ugleee.  What benefit do we get for all this additional maintenance burden?
-
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-rt5 Oops on boot [-rt8 OK]

2007-02-15 Thread Rui Nuno Capela

Rui Nuno Capela (me) wrote:
> 
> I have terrible news: 2.6.20-rt5 does not boot at all on a couple
> machines I was brave enough to try -- a [EMAIL PROTECTED] SMP/HT desktop, and 
> a
> Core2 Duo [EMAIL PROTECTED] laptop. For the first case I could capture the
> following dump via serial console:
> ...

News are that 2.6.20-rt8 got it all back to business :)

Cheers.
-- 
rncbc aka Rui Nuno Capela
[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: [PATCH] Optimize generic get_unaligned / put_unaligned implementations.

2007-02-15 Thread Ralf Baechle

On Thu, Feb 15, 2007 at 03:38:23PM -0800, Andrew Morton wrote:

> hm.  So if I have
> 
>   struct bar {
>   unsigned long b;
>   } __attribute__((packed));
> 
>   struct foo {
>   unsigned long u;
>   struct bar b;
>   };
> 
> then the compiler can see that foo.b.b is well-aligned, regardless of the
> packedness.
> 
> Plus some crazy people compile the kernel with icc (or at least they used
> to).  What happens there?

A quick grep for __attribute__((packed)) and __packed find around 900 hits,
I'd probably find more if I'd look for syntactical variations.  Some hits
are in arch/{i386,x86_64,ia64}.  At a glance it seems hard to configure a
useful x86 kernel that doesn't involve any packed attribute.  I take that
as statistical proof that icc either has doesn't really work for building
the kernel or groks packing.  Any compiler not implementing gcc extensions
is lost at building the kernel but that's old news.

  Ralf
-
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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)

* Andrew Morton ([EMAIL PROTECTED]) wrote:
> On Thu, 15 Feb 2007 17:46:56 -0500
> Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> 
> > > Me too.  It's due to the linux-kernel-markers patches.  Mathieu, can you
> > > take a look please?
> > 
> > I will give a deeper look in sparse, but I should say up front that I
> > add this to the root build tree Makefile :
> > 
> > LINUXINCLUDE:= -Iinclude \
> >$(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
> >-include include/linux/autoconf.h \
> >-include linux/marker.h
> > 
> > I guess sparse is maybe not using this Makefile or variable ?
> 
> ow, that's going to hurt - this stuff is complex and fragile.
> 

Sorry, I will remember to do more explicit changelogs.

> For what reason was that change made?
> 

It was made so that we can use the markers in C code without actually
including marker.h everywhere. I am sure someone has a better way to do
it : I would be happy to use this-nice-build-system-feature-I-missed to
have marker.h included.

> Pleeze, tricky things like this should be changelogged - we shouldn't need
> to ask.  I missed it.
> 
> 

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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] sparse chokes on arch/i386/kernel/i8253.c

On Thu, 15 Feb 2007 19:23:47 -0500
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:

> sparse chokes on arch/i386/kernel/i8253.c
> 
> Here is a marker fix that puts the correct -i include/linux/marker.h in
> the top level Makefile so sparse works correctly. The tricky part is to
> keep the kernel compiling correctly with a kernel build directory
> different from the kernel source tree too.
> 
> The fix applies on top the the Linux Kernel Markers for 2.6.20.
> 
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> 
> --- a/Makefile
> +++ b/Makefile
> @@ -309,7 +309,8 @@ AFLAGS_KERNEL =
>  LINUXINCLUDE:= -Iinclude \
> $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
>  -include include/linux/autoconf.h \
> --include linux/marker.h
> +-include \
> + $(if $(KBUILD_SRC),$(srctree)/)include/linux/marker.h
>  
>  CPPFLAGS:= -D__KERNEL__ $(LINUXINCLUDE)

But what is so magical about marker.h to justify special-case treatment at the
kbuid level?
-
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-15 Thread David Schwartz


> I must have missed something, who is trying to coerce people into not
> exercising the rights the GPL gave them?

Anyone who claims that it is unlawful to "circumvent" the EXPORT_SYMBOL_GPL
stuff. Anyone who adds copyright or license enforcement mechansims to GPL'd
code and distributes the result. Anyone who tries to frighten people into
openening their code based on a crazy notion of what constitutes a
derivative work. Anyone who tries to use copyrights as if they were patents
and claims they can own *every* *way* to do a particular thing. (Especially
if those same people *oppose* software patents!)

> I don't debate that people
> are trying to coerce people into passing on the rights the GPL gave
> them when they distribute the kernel... coercion, that's what software
> licenses are.  Who's changing the rules?

Anyone who adds a mechanism to the Linux kernel, distributes the result, and
then argues that one is subjected to new restrictions on how you can modify
and distributed GPL'd works (restrictions not found in the GPL) as a result
of the code that they added.

Just to be perfectly clear, it is an outrageous claim that *every*
*possible* kernel module must be a derivative work of the kernel. Copyright
*cannot* protect every possible way to accomplish a particular function (and
"a Linux driver for the X800 graphics chipset" is a function). Copyright can
*only* protect the one possible way you chose to do something out of a large
number of equally good possible ways. (See, for example, Lexmark v. Static
Controls where courts held that Static Controls could take Lexmark's TLP
software because that was the only practical way to make a compatible toner
cartridge.)

This is an absurd claim.

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

Michael K. Edwards wrote:

On 2/15/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:

v j wrote:
> So far I have heard nothing but, "if you don't contribute, screw you."
> All this is fine. Just say so. Make it black and white. Make it

It is black and white in copyright law and the GPL.

The /whole point/ of the GPL is to funnel contributions back.

Bzzzt.  The whole point of the GPL is to "guarantee your freedom to
share and change free software--to make sure the software is free for
all its users."

No, that's the FSF marketing fluff you've been taught to recite.

In the context of the Linux kernel, I'm referring to the original reason 
why Linus chose the GPL for the Linux kernel.

Jeff

-
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-15 Thread Greg Trounson

Lee Revell wrote:

On 2/15/07, Greg Trounson <[EMAIL PROTECTED]> wrote:

Theodore Tso wrote:
> On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:
>> You are right. I have not contributed anything to Linux. Except one
>> small patch to the MTD code. However, I don't think that is the point
>> here. I am perfectly willing to live with the way Linux is today. I am
>> telling you as a user that if Linux continues on the current path it
>> will become less and less attractive to Embedded Users.
>
> But so what?  How will that hurt *Linux*?  If the Embedded developers
> don't contribute changes back, it doesn't hurt us any if they go away
> and start paying $$$ to VxWorks instead of using Linux for free.

I disagree.  Linux needs popularity at the moment.

Um... what's your point?  Allowing vendors to legally ship embedded
devices containing proprietary drivers would require relicensing the
kernel which is impossible, for reasons that have been discussed at
length on this list.

Lee

I wasn't disputing legal problems with proprietary drivers nor suggesting people ignore 
the issue.  I was trying to make the point that Linux is adversely affected when lots of 
users, proprietary developers or otherwise, abandon Linux, and the issue might be more 
serious than people here think.

IMO the lack of provision for proprietary drivers in the GPL is a problem.  Not 
necessarily one we can do anything about now the horse has bolted, but a problem nonetheless.

Greg

-
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/15/07, Stuart MacDonald <[EMAIL PROTECTED]> wrote:


Linus does allow for one exception; drivers written for other OSes
that happen to compile for Linux as well. I believe this is the POSIX
exception mentioned elsethread. However, from your description of
requiring GPL-only symbols, I'm pretty sure your driver is a derived
work. Since you're distributing it (inside your device), the code must
be made available, under the GPL.

---

It really is legally unclear. There is substantial case law that
supports the idea that interfacing for interoperability does not
create a derived work. I agree that it's uncivil to ignore the
author's intentions, but I think that it's very unclear whether it's
"illegal". The company I work for has made the choice to avoid the
question and ship only GPL kernel modules, which seems like the right
answer to me.

---


You also asserted that the code is only useful to your competitors.
That simply is not true. No company suppports a product forever, even
if they believe they will. Once that support is gone, the only way to
fix bugs or improve the product is to **have the code in hand**. THAT
is what the GPL-openness is all about. THAT is when the code is useful
to the open source community at large. Since that need is inevitable,
the code must be provided up-front, when distribution starts.

---

Note that it is possible that what vj said is strictly true. IF the
product they ship is non-modifiable, then it's hard to argue that
anyone else could maintain it. And if the drivers are for devices
proprietary to their hardware, then they have no real value to anyone
else. And the drivers MIGHT contain information useful to their actual
competitors. I have no knowledge as to whether those conditions
actually apply.

scott
-
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: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch

2007-02-15 Thread Maynard Johnson


Arnd Bergmann wrote:


On Thursday 15 February 2007 00:52, Carl Love wrote:


 


--- linux-2.6.20-rc1.orig/arch/powerpc/oprofile/Kconfig 2007-01-18 
16:43:14.0 -0600
+++ linux-2.6.20-rc1/arch/powerpc/oprofile/Kconfig  2007-02-13 
19:04:46.271028904 -0600
@@ -7,7 +7,8 @@

config OPROFILE
tristate "OProfile system profiling (EXPERIMENTAL)"
-   depends on PROFILING
+   default m
+   depends on SPU_FS && PROFILING
help
  OProfile is a profiling system capable of profiling the
  whole system, include the kernel, kernel modules, libraries,
   



Milton already commented on this being wrong. I think what you want
is
depends on PROFILING && (SPU_FS = n || SPU_FS)

that should make sure that when SPU_FS=y that OPROFILE can not be 'm'.
 

The above suggestion would not work if SPU_FS is not defined, since the 
entire config option is ignored if an undefined symbol is used.  So, 
here's what I propose instead: 
   - Leave the existing 'config OPROFILE' unchanged from its current 
form in mainline (shown below)

   - Add the new 'config OPROFILE_CELL' (shown below)
   - In arch/powerpc/configs/cell-defconfig, set CONFIG_OPROFILE=m, to 
correspond to setting for CONFIG_SPU_FS

   - In arch/powerpc/oprofile/Makefile, do the following:
   oprofile-$(CONFIG_OPROFILE_CELL) += op_model_cell.o \
   
cell/spu_profiler.o cell/vma_map.o cell/spu_task_sync.o


===
config OPROFILE
   tristate "OProfile system profiling (EXPERIMENTAL)"
   depends on PROFILING
   help
 OProfile is a profiling system capable of profiling the
 whole system, include the kernel, kernel modules, libraries,
 and applications.

 If unsure, say N.

config OPROFILE_CELL
   bool "OProfile for Cell Broadband Engine"
   depends on OPROFILE && SPU_FS
   default y if ((SPU_FS = y && OPROFILE = y) || (SPU_FS = m && 
OPROFILE = m))

   help
 Profiling of Cell BE SPUs requires special support enabled
 by this option.  Both SPU_FS and OPROFILE options must be
 set 'y' or both be set 'm'.
=

Can anyone see a problem with any of this . . . or perhaps a suggestion 
of a better way?


Thanks.

-Maynard

-
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: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch

2007-02-15 Thread Arnd Bergmann

On Thursday 15 February 2007 22:50, Paul E. McKenney wrote:
> Is this 1.5ms with interrupts disabled?  This time period is problematic
> from a realtime perspective if so -- need to be able to preempt.

No, interrupts should be enabled here. Still, 1.5ms is probably a little
too long without a cond_resched() in case kernel preemption is disabled.

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: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-15 Thread Olaf Kirch

On Thursday 15 February 2007 12:34, [EMAIL PROTECTED] wrote:
> On Wed, 14 Feb 2007 22:14:53 PST, Andreas Gruenbacher said:
> > I agree, that's really what should happen. We solve this by marking
> > modules as supported, partner supported, or unsupported, but in an
> > "insecure" way, so partners and users could try to fake the support
> > status of a module and/or remove status flags from Oopses, and
> > cryptography wouldn't save us.
>
> Where cryptography *can* save you is that a partner or user can't fake a
> 'Suse Supported' signature without access to the Suse private key.

The user has control over the running kernel, and given enough time
and clue, can circumvent any protection mechanism the vendor comes
up with. And that's a good thing IMO, unless you believe in "trusted
computing" and all those Bigbrotherisms some agencies want to put
in your machines.

So the user is running a system in some state that may or may not
resemble what the vendor shipped. When the machine crashes, the
user is free to munge the oops until it looks like a valid one.

Someone mentioned in this context that you can sign the oops - but to
do that you need a private key. And the whole point of this exercise is
that the user does not have access to that key.

So as far as support is concerned, you're back in square one.
You cannot tell a "genuine" oops produced on a supported kernel
from a doctored one produced on Joe Doe's Garage Kernel.

Olaf
-- 
Olaf Kirch|  Anyone who has had to work with X.509 has probably
[EMAIL PROTECTED]   |  experienced what can best be described as
--+  ISO water torture. -- Peter Gutmann
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] sparse chokes on arch/i386/kernel/i8253.c

sparse chokes on arch/i386/kernel/i8253.c

Here is a marker fix that puts the correct -i include/linux/marker.h in
the top level Makefile so sparse works correctly. The tricky part is to
keep the kernel compiling correctly with a kernel build directory
different from the kernel source tree too.

The fix applies on top the the Linux Kernel Markers for 2.6.20.

Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>

--- a/Makefile
+++ b/Makefile
@@ -309,7 +309,8 @@ AFLAGS_KERNEL   =
 LINUXINCLUDE:= -Iinclude \
$(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
   -include include/linux/autoconf.h \
-  -include linux/marker.h
+  -include \
+   $(if $(KBUILD_SRC),$(srctree)/)include/linux/marker.h
 
 CPPFLAGS:= -D__KERNEL__ $(LINUXINCLUDE)
-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Candidate, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
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 4/4] ipmi: add new IPMI nmi watchdog handling

2007-02-15 Thread Corey Minyard


Andrew Morton wrote:

On Thu, 15 Feb 2007 09:49:15 -0600
Corey Minyard <[EMAIL PROTECTED]> wrote:

  

So I see the following options besides what's already there:

1) add asm/kdebug.h and DIE_NMI_POST to everything that might have an 
IPMI implementation.
2) use CONFIG_X86 to tell if NMI will work, since that's the only thing 
it will work on at the present.


I don't have any way to know how different systems have implemented that 
feature, so I can't actually implement it for the various architectures 
(plus I don't have any of those boards).  So maybe #2 is the best?



I tend to think that #1 is the best option - it keeps things consistent
and it gives arch/board maintainers a framework in which to add the
support code at their leisure.   But it's something which would be best
worked through with the affected arch maintainers, please.

Which architectures are we talking about here?  ia64 and ppc?
  

I'm not 100% sure, to tell you there truth.  I know there are ARM, PPC,
x86, SPARC, ia64, and MIPS systems that have IPMI.  But you can stick
it on anything, really.  I'd like to be able to have basic support work
without having to add arch-specific things for one feature of the driver.

-Corey
-
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] shm: Fix the locking and cleanup error handling in do_shmat.

2007-02-15 Thread Michal Piotrowski

Eric W. Biederman napisał(a):
> When enhancing do_shmat I forgot to take into account that shm_lock
> is a spinlock, and was allocating memory with the lock held.
> 
> This patch fixes that by grabbing a reference to the dentry and
> mounts of shm_file before we drop the shm_lock and then performing
> the memory allocations.
> 
> This is also a bit of a general scrub on the error handling.
> Everything is now forced through the single return statement
> for clarity, and the handling of the return address now uses
> fewer casts.
> 
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> ---
>  ipc/shm.c |   56 
>  1 files changed, 32 insertions(+), 24 deletions(-)
> 
> diff --git a/ipc/shm.c b/ipc/shm.c
> index e0b6544..26b935b 100644
> --- a/ipc/shm.c
> +++ b/ipc/shm.c
> @@ -815,15 +815,16 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr)
>   unsigned long flags;
>   unsigned long prot;
>   int acc_mode;
> - void *user_addr;
> + unsigned long user_addr;
>   struct ipc_namespace *ns;
>   struct shm_file_data *sfd;
> + struct path path;
>   mode_t f_mode;
>  
> - if (shmid < 0) {
> - err = -EINVAL;
> + err = -EINVAL;
> + if (shmid < 0)
>   goto out;
> - } else if ((addr = (ulong)shmaddr)) {
> + else if ((addr = (ulong)shmaddr)) {
>   if (addr & (SHMLBA-1)) {
>   if (shmflg & SHM_RND)
>   addr &= ~(SHMLBA-1);   /* round down */
> @@ -831,12 +832,12 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr)
>  #ifndef __ARCH_FORCE_SHMLBA
>   if (addr & ~PAGE_MASK)
>  #endif
> - return -EINVAL;
> + goto out;
>   }
>   flags = MAP_SHARED | MAP_FIXED;
>   } else {
>   if ((shmflg & SHM_REMAP))
> - return -EINVAL;
> + goto out;
>  
>   flags = MAP_SHARED;
>   }
> @@ -860,7 +861,6 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr)
>* additional creator id...
>*/
>   ns = current->nsproxy->ipc_ns;
> - err = -EINVAL;
>   shp = shm_lock(ns, shmid);
>   if(shp == NULL)
>   goto out;
> @@ -877,19 +877,25 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr)
>   if (err)
>   goto out_unlock;
>  
> + path.dentry = dget(shp->shm_file->f_path.dentry);
> + path.mnt= mntget(shp->shm_file->f_path.mnt);
> + shp->shm_nattch++;
> + size = i_size_read(path.dentry->d_inode);
> + shm_unlock(shp);
> +
>   err = -ENOMEM;
>   sfd = kzalloc(sizeof(*sfd), GFP_KERNEL);
>   if (!sfd)
> - goto out_unlock;
> + goto out_put_path;

drivers/video/Kconfig:1606:warning: 'select' used by config symbol 'FB_PS3' 
refer to undefined symbol 'PS3_PS3AV'
/mnt/md0/devel/linux-mm/ipc/shm.c: In function 'do_shmat':
/mnt/md0/devel/linux-mm/ipc/shm.c:945: warning: passing argument 1 of 'IS_ERR' 
makes pointer from integer without a cast
/mnt/md0/devel/linux-mm/ipc/shm.c:946: warning: passing argument 1 of 'PTR_ERR' 
makes pointer from integer without a cast
/mnt/md0/devel/linux-mm/ipc/shm.c:931: warning: label 'out_nattch' defined but 
not used
/mnt/md0/devel/linux-mm/ipc/shm.c:890: error: label 'out_put_path' used but not 
defined
make[2]: *** [ipc/shm.o] Error 1
make[1]: *** [ipc] Error 2
make: *** [_all] Error 2


>  
> + err = -ENOMEM;
>   file = get_empty_filp();
>   if (!file)
>   goto out_free;
>  
>   file->f_op = &shm_file_operations;
>   file->private_data = sfd;
> - file->f_path.dentry = dget(shp->shm_file->f_path.dentry);
> - file->f_path.mnt = mntget(shp->shm_file->f_path.mnt);
> + file->f_path = path;
>   file->f_mapping = shp->shm_file->f_mapping;
>   file->f_mode = f_mode;
>   sfd->id = shp->id;
> @@ -897,13 +903,9 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr)
>   sfd->file = shp->shm_file;
>   sfd->vm_ops = NULL;
>  
> - size = i_size_read(file->f_path.dentry->d_inode);
> - shp->shm_nattch++;
> - shm_unlock(shp);
> -
>   down_write(¤t->mm->mmap_sem);
>   if (addr && !(shmflg & SHM_REMAP)) {
> - user_addr = ERR_PTR(-EINVAL);
> + err = -EINVAL;
>   if (find_vma_intersection(current->mm, addr, addr + size))
>   goto invalid;
>   /*
> @@ -915,13 +917,17 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr)
>   goto invalid;
>   }
>   
> - user_addr = (void*) do_mmap (file, addr, size, prot, flags, 0);
> -
> + user_addr = do_mmap (file, addr, size, prot, flags, 0);
> + *raddr = user_add

Re: GPL vs non-GPL device drivers

2007-02-15 Thread Lee Revell


On 2/15/07, Greg Trounson <[EMAIL PROTECTED]> wrote:

Theodore Tso wrote:
> On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:
>> You are right. I have not contributed anything to Linux. Except one
>> small patch to the MTD code. However, I don't think that is the point
>> here. I am perfectly willing to live with the way Linux is today. I am
>> telling you as a user that if Linux continues on the current path it
>> will become less and less attractive to Embedded Users.
>
> But so what?  How will that hurt *Linux*?  If the Embedded developers
> don't contribute changes back, it doesn't hurt us any if they go away
> and start paying $$$ to VxWorks instead of using Linux for free.

I disagree.  Linux needs popularity at the moment.


Um... what's your point?  Allowing vendors to legally ship embedded
devices containing proprietary drivers would require relicensing the
kernel which is impossible, for reasons that have been discussed at
length on this list.

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/

Re: 2.6.20-mm1

On Fri, 16 Feb 2007 00:24:35 +0100
Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> Andrew Morton napisa__(a):
> > On Thu, 15 Feb 2007 15:37:20 +0100
> > Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> > 
> >> Andrew Morton napisa__(a):
> >>> Temporarily at
> >>>
> >>>   http://userweb.kernel.org/~akpm/2.6.20-mm1/
> >>>
> >>> Will appear later at
> >>>
> >>>  
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/
> >>>
> >>>
> >> BUG: sleeping function called from invalid context at 
> >> /mnt/md0/devel/linux-mm/mm/slab.c:3043
> >> in_atomic():1, irqs_disabled():0
> >> 1 lock held by artsd/3819:
> >>  #0:  (&new->lock){--..}, at: [] ipc_lock+0x35/0x4f
> >>  [] show_trace_log_lvl+0x1a/0x2f
> >>  [] show_trace+0x12/0x14
> >>  [] dump_stack+0x16/0x18
> >>  [] __might_sleep+0xc9/0xcf
> >>  [] kmem_cache_zalloc+0x28/0xe5
> >>  [] do_shmat+0x111/0x372
> >>  [] sys_ipc+0x148/0x1b5
> >>  [] syscall_call+0x7/0xb
> > 
> > That's shm-make-sysv-ipc-shared-memory-use-stacked-files.patch, brought to
> > us by Eric-who-hasnt-read-Documentation/SubmitChecklist.
> > 
> > Like this, I guess:
> > 
> > diff -puN ipc/shm.c~shm-make-sysv-ipc-shared-memory-use-stacked-files-fix 
> > ipc/shm.c
> 
> I might be drunk...
> 
> This patch still doesn't solve the problem.
> 
> BUG: sleeping function called from invalid context at 
> /mnt/md0/devel/linux-mm/mm/slab.c:3043
> in_atomic():1, irqs_disabled():0
> 1 lock held by Xorg/2885:
>  #0:  (&new->lock){--..}, at: [] ipc_lock+0x35/0x4f
>  [] show_trace_log_lvl+0x1a/0x2f
>  [] show_trace+0x12/0x14
>  [] dump_stack+0x16/0x18
>  [] __might_sleep+0xc9/0xcf
>  [] kmem_cache_alloc+0x28/0xbf
>  [] get_empty_filp+0x6a/0x173
>  [] do_shmat+0x136/0x390
>  [] sys_ipc+0x148/0x1b5
>  [] syscall_call+0x7/0xb

yes, that's the other one, which Eric will be looking at.

>  ===
> BUG: MAX_LOCK_DEPTH too low!
> turning off the locking correctness validator.
> do_IRQ: stack overflow: -52
>  [] show_trace_log_lvl+0x1a/0x2f
>  [] show_trace+0x12/0x14
>  [] dump_stack+0x16/0x18
>  [] do_IRQ+0x95/0xc1
> BUG: unable to handle kernel paging request at virtual address 0e200034
>  printing eip:
> c01052e2
> *pde = 
> Oops:  [#1]
> PREEMPT SMP
> last sysfs file: 
> /devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/vendor
> Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd 
> nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT 
> nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter 
> ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram 
> 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 evdev snd_mixer_oss 
> snd_pcm snd_timer skge snd 8139too intel_agp sk98lin agpgart soundcore mii 
> i2c_i801 snd_page_alloc ide_cd cdrom rtc unix
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00013046   (2.6.20-mm1 #16)
> EIP is at dump_trace+0x88/0x9e
> eax:    ebx: f412c01c   ecx: c0429344   edx: c03cf8fa
> BUG: unable to handle kernel paging request at virtual address 8d17ca6c
>  printing eip:
> c011d927
> *pde = 
> esi: 0e20   edi: c03daed2   ebp: f412bfd0   esp: f412bfc0
> ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> Process Xorg (pid: 2885, ti=f412a000 task=f4a58aa0 task.ti=f412c000)
> Stack: c7422ac0 c03daed2 0011  f412bfe4 c0105312 c0429344 c03daed2
>0004 f412bff0 c0105a25 c03daed2 f412bffc c0105ae7 f412c008 f412c01c
> Call Trace:
>  [] show_trace_log_lvl+0x1a/0x2f
>  [] show_stack_log_lvl+0x9d/0xac
>  [] show_registers+0x1ed/0x34c
>  [] die+0x11d/0x234
>  [] do_page_fault+0x47c/0x55b
>  [] error_code+0x7c/0x84
>  [] show_trace_log_lvl+0x1a/0x2f
>  [] show_trace+0x12/0x14
>  [] dump_stack+0x16/0x18
>  [] do_IRQ+0x95/0xc1
> BUG: unable to handle kernel paging request at virtual address 0e200034

ooh, we broke lockdep.
-
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] shm: Fix the locking and cleanup error handling in do_shmat.

2007-02-15 Thread Michal Piotrowski

Eric W. Biederman napisał(a):
> When enhancing do_shmat I forgot to take into account that shm_lock
> is a spinlock, and was allocating memory with the lock held.
> 
> This patch fixes that by grabbing a reference to the dentry and
> mounts of shm_file before we drop the shm_lock and then performing
> the memory allocations.
> 
> This is also a bit of a general scrub on the error handling.
> Everything is now forced through the single return statement
> for clarity, and the handling of the return address now uses
> fewer casts.
> 
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> ---
>  ipc/shm.c |   56 
>  1 files changed, 32 insertions(+), 24 deletions(-)
> 
> diff --git a/ipc/shm.c b/ipc/shm.c
> index e0b6544..26b935b 100644
> --- a/ipc/shm.c
> +++ b/ipc/shm.c
> @@ -815,15 +815,16 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr)
>   unsigned long flags;
>   unsigned long prot;
>   int acc_mode;
> - void *user_addr;
> + unsigned long user_addr;
>   struct ipc_namespace *ns;
>   struct shm_file_data *sfd;
> + struct path path;
>   mode_t f_mode;
>  
> - if (shmid < 0) {
> - err = -EINVAL;
> + err = -EINVAL;
> + if (shmid < 0)
>   goto out;
> - } else if ((addr = (ulong)shmaddr)) {
> + else if ((addr = (ulong)shmaddr)) {
>   if (addr & (SHMLBA-1)) {
>   if (shmflg & SHM_RND)
>   addr &= ~(SHMLBA-1);   /* round down */
> @@ -831,12 +832,12 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr)
>  #ifndef __ARCH_FORCE_SHMLBA
>   if (addr & ~PAGE_MASK)
>  #endif
> - return -EINVAL;
> + goto out;
>   }
>   flags = MAP_SHARED | MAP_FIXED;
>   } else {
>   if ((shmflg & SHM_REMAP))
> - return -EINVAL;
> + goto out;
>  
>   flags = MAP_SHARED;
>   }
> @@ -860,7 +861,6 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr)
>* additional creator id...
>*/
>   ns = current->nsproxy->ipc_ns;
> - err = -EINVAL;
>   shp = shm_lock(ns, shmid);
>   if(shp == NULL)
>   goto out;
> @@ -877,19 +877,25 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr)
>   if (err)
>   goto out_unlock;
>  
> + path.dentry = dget(shp->shm_file->f_path.dentry);
> + path.mnt= mntget(shp->shm_file->f_path.mnt);
> + shp->shm_nattch++;
> + size = i_size_read(path.dentry->d_inode);
> + shm_unlock(shp);
> +
>   err = -ENOMEM;
>   sfd = kzalloc(sizeof(*sfd), GFP_KERNEL);
>   if (!sfd)
> - goto out_unlock;
> + goto out_put_path;
>  
> + err = -ENOMEM;
>   file = get_empty_filp();
>   if (!file)
>   goto out_free;
>  
>   file->f_op = &shm_file_operations;
>   file->private_data = sfd;
> - file->f_path.dentry = dget(shp->shm_file->f_path.dentry);
> - file->f_path.mnt = mntget(shp->shm_file->f_path.mnt);
> + file->f_path = path;
>   file->f_mapping = shp->shm_file->f_mapping;
>   file->f_mode = f_mode;
>   sfd->id = shp->id;
> @@ -897,13 +903,9 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr)
>   sfd->file = shp->shm_file;
>   sfd->vm_ops = NULL;
>  
> - size = i_size_read(file->f_path.dentry->d_inode);
> - shp->shm_nattch++;
> - shm_unlock(shp);
> -
>   down_write(¤t->mm->mmap_sem);
>   if (addr && !(shmflg & SHM_REMAP)) {
> - user_addr = ERR_PTR(-EINVAL);
> + err = -EINVAL;
>   if (find_vma_intersection(current->mm, addr, addr + size))
>   goto invalid;
>   /*
> @@ -915,13 +917,17 @@ long do_shmat(int shmid, char __user *shmaddr, int 
> shmflg, ulong *raddr)
>   goto invalid;
>   }
>   
> - user_addr = (void*) do_mmap (file, addr, size, prot, flags, 0);
> -
> + user_addr = do_mmap (file, addr, size, prot, flags, 0);
> + *raddr = user_addr;
> + err = 0;
> + if (IS_ERR_VALUE(user_addr))
> + err = (long)user_addr;
>  invalid:
>   up_write(¤t->mm->mmap_sem);
> -
> + 
>   fput(file);
>  
> +out_nattch:
>   mutex_lock(&shm_ids(ns).mutex);
>   shp = shm_lock(ns, shmid);
>   BUG_ON(!shp);
> @@ -933,17 +939,19 @@ invalid:



???


>   shm_unlock(shp);
>   mutex_unlock(&shm_ids(ns).mutex);
>  
> - *raddr = (unsigned long) user_addr;
> - err = 0;
> - if (IS_ERR(user_addr))
> - err = PTR_ERR(user_addr);
>  out:
>   return err;
> -out_free:
> - kfree(sfd);
> +
>  out_unlock:
>   shm_unlock(shp);
>   goto out;
> +
> +out

Re: [2.6 patch] drivers/isdn/gigaset/: build asyncdata.o into the gigaset module

2007-02-15 Thread Tilman Schmidt

Am 15.02.2007 22:56 schrieb Adrian Bunk:
> This patch fixes the following compile error:
> 
> <--  snip  -->
> 
> ...
>   LD  drivers/isdn/gigaset/built-in.o
> drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_send_skb':
> (.text+0xe50): multiple definition of `gigaset_m10x_send_skb'
> drivers/isdn/gigaset/usb_gigaset.o:(.text+0x0): first defined here
> drivers/isdn/gigaset/ser_gigaset.o: In function `gigaset_m10x_input':
> (.text+0x1121): multiple definition of `gigaset_m10x_input'
> drivers/isdn/gigaset/usb_gigaset.o:(.text+0x2d1): first defined here
> make[4]: *** [drivers/isdn/gigaset/built-in.o] Error 1

How did you manage to produce that error? I have never encountered it.

Thanks,
Tilman

-- 
Tilman Schmidt  E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations.

Andrew Morton wrote:
> hm.  So if I have
>
>   struct bar {
>   unsigned long b;
>   } __attribute__((packed));
>
>   struct foo {
>   unsigned long u;
>   struct bar b;
>   };
>
> then the compiler can see that foo.b.b is well-aligned, regardless of the
> packedness.

In Ralf's code, the structure is anonymous, and is used to declare a
pointer type, which is initialized from a void *.  So I think the
compiler isn't allowed to assume anything about its alignment.

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/

Re: [PATCH 3/5] scsi: megaraid_sas - throttle io if FW is busy

2007-02-15 Thread James Bottomley

On Tue, 2007-02-06 at 14:11 -0800, Sumant Patro wrote:
> Checks added in megasas_queue_command to know if FW is able to process
> commands within timeout period. If number of retries is 2 or greater,
> the driver stops sending cmd to FW. IO is resumed if pending cmd count
> reduces to 16 or 5 seconds has elapsed from the time cmds were last sent
> to FW.
> 
> Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
> ---
> 
>  drivers/scsi/megaraid/megaraid_sas.c |   27 +
>  drivers/scsi/megaraid/megaraid_sas.h |3 ++
>  2 files changed, 30 insertions(+)
> 
> diff -uprN 2.6.new-p2/drivers/scsi/megaraid/megaraid_sas.c 
> 2.6.new-p3/drivers/scsi/megaraid/megaraid_sas.c
> --- 2.6.new-p2/drivers/scsi/megaraid/megaraid_sas.c   2007-02-06 
> 08:43:40.0 -0800
> +++ 2.6.new-p3/drivers/scsi/megaraid/megaraid_sas.c   2007-02-06 
> 08:50:40.0 -0800
> @@ -839,6 +839,7 @@ megasas_queue_command(struct scsi_cmnd *
>   u32 frame_count;
>   struct megasas_cmd *cmd;
>   struct megasas_instance *instance;
> + unsigned long sec;
>  
>   instance = (struct megasas_instance *)
>   scmd->device->host->hostdata;
> @@ -856,6 +857,23 @@ megasas_queue_command(struct scsi_cmnd *
>   goto out_done;
>   }
>  
> + /* Check if we can process cmds */
> + if(instance->is_busy){
^  ^
   space needed per linux coding style (and the rest of the file

> + sec = (jiffies - instance->last_time) / HZ;

please don't do this.  You want to be using time_before() and
jiffies_to_msecs().  The space problems apply to the rest of the code

> + if(sec<5)
> + return SCSI_MLQUEUE_HOST_BUSY;
> + else{
> + instance->is_busy=0;
> + instance->last_time=0;
> + }
> + }
> +
> + if(scmd->retries>1){

I really don't think this is a good indicator of your firmware
necessarily having problems; I really think you might want to look at
other indicators ... jiffies_at_alloc might be better, or even
throttling from the abort handler, which must have been called before
you get to here if the command is actually timing out.

Timeout and abort has it's own throttle anyway, since we quiesce the
host before beginning error recovery ... are you sure this scheme
actually solves anything for your device?

James


-
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-15 Thread Greg Trounson

Theodore Tso wrote:

On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:

You are right. I have not contributed anything to Linux. Except one
small patch to the MTD code. However, I don't think that is the point
here. I am perfectly willing to live with the way Linux is today. I am
telling you as a user that if Linux continues on the current path it
will become less and less attractive to Embedded Users.

But so what? How will that hurt *Linux*? If the Embedded developers
don't contribute changes back, it doesn't hurt us any if they go away
and start paying $$$ to VxWorks instead of using Linux for free.

I disagree. Linux needs popularity at the moment.

Otherwise, Linux may be in for a hard time once manufacturers standardize on TPM-enabled
processors that only allow 'authorized' code to run. And it looks like this is going to
happen.

Unless there is a sufficient user base (ie a market) for Linux, what incentive are Intel,
AMD, etc going to have to make their hardware run anything except code signed by Microsoft?

When taken off modern CPUs, Linux will be relegated to hobby cpu fabs, legacy hardware and
maybe a niche back in the embedded market. Then watch development all but stagnate.
Something I'd rather not see happen.

Greg

-
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 1/1] unify queue_delayed_work and queue_delayed_work_on fix

2007-02-15 Thread Jiri Slaby


Jiri Slaby napsal(a):
[...]

unify queue_delayed_work and queue_delayed_work_on fix


Oh sorry, the name should be
make queue_delayed_work() friendly to flush_fork() fix


Since cwq->wq is unset for other than singlethread_cpu when singlethread
workqueue was created, an oops occurs during bootup. Fix it by setting
correct private value for workqueue.

Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

---
commit 7bc281be5811f9b1dd01c25eaf492f4765737fd0
tree 7795008066bb89e7489384cde95e63260602d5af
parent 61c2024a2dd044e32747542cfbf4b22251df3bc2
author Jiri Slaby <[EMAIL PROTECTED]> Fri, 16 Feb 2007 00:49:15 +0100
committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 16 Feb 2007 00:49:15 +0100

 kernel/workqueue.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index f2089bf..af5e597 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -210,7 +210,8 @@ int queue_delayed_work_on(int cpu, struct workqueue_struct 
*wq,
 
 		/* This stores cwq for the moment, for the timer_fn */

set_wq_data(work,
-   per_cpu_ptr(wq->cpu_wq, raw_smp_processor_id()));
+   per_cpu_ptr(wq->cpu_wq, wq->singlethread ?
+   singlethread_cpu : raw_smp_processor_id()));
timer->expires = jiffies + delay;
timer->data = (unsigned long)dwork;
timer->function = delayed_work_timer_fn;



regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] shm: Fix the locking and cleanup error handling in do_shmat.

2007-02-15 Thread Eric W. Biederman


When enhancing do_shmat I forgot to take into account that shm_lock
is a spinlock, and was allocating memory with the lock held.

This patch fixes that by grabbing a reference to the dentry and
mounts of shm_file before we drop the shm_lock and then performing
the memory allocations.

This is also a bit of a general scrub on the error handling.
Everything is now forced through the single return statement
for clarity, and the handling of the return address now uses
fewer casts.

Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
 ipc/shm.c |   56 
 1 files changed, 32 insertions(+), 24 deletions(-)

diff --git a/ipc/shm.c b/ipc/shm.c
index e0b6544..26b935b 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -815,15 +815,16 @@ long do_shmat(int shmid, char __user *shmaddr, int 
shmflg, ulong *raddr)
unsigned long flags;
unsigned long prot;
int acc_mode;
-   void *user_addr;
+   unsigned long user_addr;
struct ipc_namespace *ns;
struct shm_file_data *sfd;
+   struct path path;
mode_t f_mode;
 
-   if (shmid < 0) {
-   err = -EINVAL;
+   err = -EINVAL;
+   if (shmid < 0)
goto out;
-   } else if ((addr = (ulong)shmaddr)) {
+   else if ((addr = (ulong)shmaddr)) {
if (addr & (SHMLBA-1)) {
if (shmflg & SHM_RND)
addr &= ~(SHMLBA-1);   /* round down */
@@ -831,12 +832,12 @@ long do_shmat(int shmid, char __user *shmaddr, int 
shmflg, ulong *raddr)
 #ifndef __ARCH_FORCE_SHMLBA
if (addr & ~PAGE_MASK)
 #endif
-   return -EINVAL;
+   goto out;
}
flags = MAP_SHARED | MAP_FIXED;
} else {
if ((shmflg & SHM_REMAP))
-   return -EINVAL;
+   goto out;
 
flags = MAP_SHARED;
}
@@ -860,7 +861,6 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, 
ulong *raddr)
 * additional creator id...
 */
ns = current->nsproxy->ipc_ns;
-   err = -EINVAL;
shp = shm_lock(ns, shmid);
if(shp == NULL)
goto out;
@@ -877,19 +877,25 @@ long do_shmat(int shmid, char __user *shmaddr, int 
shmflg, ulong *raddr)
if (err)
goto out_unlock;
 
+   path.dentry = dget(shp->shm_file->f_path.dentry);
+   path.mnt= mntget(shp->shm_file->f_path.mnt);
+   shp->shm_nattch++;
+   size = i_size_read(path.dentry->d_inode);
+   shm_unlock(shp);
+
err = -ENOMEM;
sfd = kzalloc(sizeof(*sfd), GFP_KERNEL);
if (!sfd)
-   goto out_unlock;
+   goto out_put_path;
 
+   err = -ENOMEM;
file = get_empty_filp();
if (!file)
goto out_free;
 
file->f_op = &shm_file_operations;
file->private_data = sfd;
-   file->f_path.dentry = dget(shp->shm_file->f_path.dentry);
-   file->f_path.mnt = mntget(shp->shm_file->f_path.mnt);
+   file->f_path = path;
file->f_mapping = shp->shm_file->f_mapping;
file->f_mode = f_mode;
sfd->id = shp->id;
@@ -897,13 +903,9 @@ long do_shmat(int shmid, char __user *shmaddr, int shmflg, 
ulong *raddr)
sfd->file = shp->shm_file;
sfd->vm_ops = NULL;
 
-   size = i_size_read(file->f_path.dentry->d_inode);
-   shp->shm_nattch++;
-   shm_unlock(shp);
-
down_write(¤t->mm->mmap_sem);
if (addr && !(shmflg & SHM_REMAP)) {
-   user_addr = ERR_PTR(-EINVAL);
+   err = -EINVAL;
if (find_vma_intersection(current->mm, addr, addr + size))
goto invalid;
/*
@@ -915,13 +917,17 @@ long do_shmat(int shmid, char __user *shmaddr, int 
shmflg, ulong *raddr)
goto invalid;
}

-   user_addr = (void*) do_mmap (file, addr, size, prot, flags, 0);
-
+   user_addr = do_mmap (file, addr, size, prot, flags, 0);
+   *raddr = user_addr;
+   err = 0;
+   if (IS_ERR_VALUE(user_addr))
+   err = (long)user_addr;
 invalid:
up_write(¤t->mm->mmap_sem);
-
+   
fput(file);
 
+out_nattch:
mutex_lock(&shm_ids(ns).mutex);
shp = shm_lock(ns, shmid);
BUG_ON(!shp);
@@ -933,17 +939,19 @@ invalid:
shm_unlock(shp);
mutex_unlock(&shm_ids(ns).mutex);
 
-   *raddr = (unsigned long) user_addr;
-   err = 0;
-   if (IS_ERR(user_addr))
-   err = PTR_ERR(user_addr);
 out:
return err;
-out_free:
-   kfree(sfd);
+
 out_unlock:
shm_unlock(shp);
goto out;
+
+out_free:
+   kfree(sfd);
+out_put_path:
+   dput(path.dentry);
+   mntput(path.mnt);
+   goto out_nattch;

 }
 
-- 
1.4.4.1.

Re: GPL vs non-GPL device drivers

2007-02-15 Thread Michael K. Edwards

On 2/15/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:

v j wrote:
> So far I have heard nothing but, "if you don't contribute, screw you."
> All this is fine. Just say so. Make it black and white. Make it

It is black and white in copyright law and the GPL.

The /whole point/ of the GPL is to funnel contributions back.

Bzzzt.  The whole point of the GPL is to "guarantee your freedom to
share and change free software--to make sure the software is free for
all its users."  Undo the EXPORT_SYMBOL_GPL brain damage if you like;
it's not part of the offer of contract, which ties itself in knots to
avoid any measure of derivative-ness other than that enshrined in the
appropriate jurisdiction's copyright law (conformant to the Berne
Convention anywhere that matters).  Fork to your heart's content; if
it breaks, you get to keep both pieces.  Just remember that there is
also no severability clause in the offer of contract (very much the
contrary; see Section 7), so if the contract breaks, you do not
necessarily get to keep both pieces, and weird things happen when you
wander off into the vagaries of your jurisdiction's tort law and
commercial code.

We happen to think there are solid engineering reasons for this.
Customers think there are solid reasons for this. Libre activists think
there are freedom aspects to this.

There are no solid engineering reasons for demanding code that is
probably crap, tied to hardware you will never see, from people with
regard to whom you indulge in mutual hostility and distrust.  There
are, however, solid economies of scale in warranting the unwarrantable
and hand-holding at each stage of the skill hierarchy, and they depend
on keeping the interchangeable parts interchangeable.  The "IP asset"
delusion interferes with these economies of scale and annoys the
Morlocks who keep the gears turning.

99% of customers could care less; show them good, fast, and cheap,
offer them two out of three, they'll leave "good" on the table every
time.  Libre activists don't understand the meaning of the word
"freedom", at least not in the same way I do; freedom is spelled
R-U-L-E O-F L-A-W and they seem to have contempt for this concept.

But ignoring all the justifications, it /is/ the letter of the law.  And
you are expected to follow it, just like everybody else.

Fiddlesticks.  The letter of the law is very different from what you
have been led to believe.  Most law is created in the marketplace,
discovered in a courtroom, codified by a legislature, reconciled by
treaty and gunship, and enforced by insurers and other financial
institutions.  This kind of law considers the "free software"
philosophy to be a curiosity at best, and renders the GPL down to:

You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work ...

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.

... you must cause it ... to print or display an announcement
including an appropriate copyright notice and a notice that there is
no warranty (or else, saying that you provide a warranty) ...

... Accompany it with the complete corresponding machine-readable
source code ...

*** BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, *** THERE IS
NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE
LAW.

That's a straightforward license of modification and distribution
rights in return for attribution and warranty disclaimer, just like
any other "open source" license; except that it creates SEVERE
obstacles to commercial exploitation without cutting the originator
in, just like most "free as in beer" licenses.  The rest of the GPL is
composed of no-ops in any legal system that matters.  Don't take my
word for it; read the actual court decisions in which the GPL has come
up, and Nimmer on Copyright for the backstory.

IANAL, YMMV, HTH, HAND, 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 patch] correct CONFIG_GIGASET_M101 Makefile entry

2007-02-15 Thread Tilman Schmidt

Am 15.02.2007 22:56 schrieb Adrian Bunk:
> Advanced Mathematics, lesson 1:
> 101 != 105

Ouch. Sorry. Thanks for catching that one.

> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

Acked-by: Tilman Schmidt <[EMAIL PROTECTED]>

> ---
> --- linux-2.6.20-mm1/drivers/isdn/gigaset/Makefile.old2007-02-15 
> 17:38:23.0 +0100
> +++ linux-2.6.20-mm1/drivers/isdn/gigaset/Makefile2007-02-15 
> 17:38:41.0 +0100
> @@ -5,4 +5,4 @@
>  
>  obj-$(CONFIG_GIGASET_M105) += usb_gigaset.o gigaset.o
>  obj-$(CONFIG_GIGASET_BASE) += bas_gigaset.o gigaset.o
> -obj-$(CONFIG_GIGASET_M105) += ser_gigaset.o gigaset.o
> +obj-$(CONFIG_GIGASET_M101) += ser_gigaset.o gigaset.o
> 


-- 
Tilman Schmidt  E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

Re: Linux 2.6.16.41-rc1

2007-02-15 Thread Adrian Bunk

On Fri, Feb 16, 2007 at 01:49:45AM +0200, S.Çağlar Onur wrote:
> Hi;
> 
> 15 Şub 2007 Per tarihinde şunları yazmıştınız:
> > Location:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/
> >
> > git tree:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
> >
> >
> > Changes since 2.6.16.40:
> 
> What about CVE-2006-6333, CVE-2006-5753 and CVE-2007-0006?
> 
> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333

Problem not present in 2.6.16.

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753

Not a serious security problem, but I'll get it fixed in 2.6.16.42.

> * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006

Problem is more or less impossible in 2.6.16, but I'll look at it
for 2.6.16.42.

> Cheers

cu
Adrian

-- 

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

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

Re: [PATCH] aio: fix kernel bug when page is temporally busy

2007-02-15 Thread Zach Brown



On Feb 15, 2007, at 3:32 PM, Ananiev, Leonid I wrote:


If EIOCBRETRY then generic_file_aio_write() will be recalled for the
same iocb.

Only if kick_iocb() is called.  It won't be called if i_i_p2_r() was
the only thing to return -EIOCBRETRY.

It is not need to call kick_iocb()
for generic_file_aio_write() calling.
It is recalled without any wakeup waiting:
for (;;) {
ret = filp->f_op->aio_write(&kiocb, &iov, 1,
kiocb.ki_pos);
if (ret != -EIOCBRETRY)
break;
wait_on_retry_sync_kiocb(&kiocb);
}
Note: wait_on_retry_sync_kiocb() does not wait.


Yes it does.  It will not return until kiocbSetKicked() is called,  
and that is only called from kick_iocb().



It overwrites -EIOCBQUEUED

Do you mean that there is one more kernel bug which
overwrites -EIOCBQUEUED by any errno or number of bytes and this
new value is returned to caller as an IO result
while IO is not finished yet.

The proposed patch does not crate this bug if any.


Right, and I said that in the mail you're quoting.


It actually fixes a kernel panic bag when iocb.users count becomes
incorrect. The bag " Kernel BUG at fs/aio.c:509" is there because
aio_run_iocb() have not a chance to differ real EIO and
EIO which is actually means EAGAYN or EIOCBRETRY.


Yes, I understand the bug you're trying to fix.  You're introducing  
other bugs with the patch.  It will not be merged.



It is interesting that I've not seen any EIOCBQUEUED returned
to aio_run_iocb() during 5 hours aiostress running.


What arguments are you running aio-stress with?  -EIOCBQUEUED is only  
used for O_DIRECT, and then only in certain circumstances.


- z
-
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-15 Thread Andi Kleen

> >Also many storage subsystems have some internal parallelism
> >in writing (e.g. a RAID can write on different disks in parallel for
> >a single partition) so i'm not sure your distinction is that useful.
> >
> But we are talking about a different case. What I have said is that if you 
> use two devices, one for the 'regular' file system and another one for the 
> log, DualFS is better in that case because it can use the log for reads. 
> Other journaling file systems can not do that.

Shadow paging based systems typically can, but we have no widely used
one on Linux (reiser4 would be probably the closest) 

> >If you stripe two disks with a standard fs versus use one of them
> >as metadata volume and the other as data volume with dualfs i would
> >expect the striped variant usually be faster because it will give
> >parallelism not only to data versus metadata, but also to all data
> >versus other data.
> >
> If you have a RAID system, both the data and meta-data devices of DualFS 
> can be stripped, and you get the same result. No problem for DualFS :)

Sure, but then you need four disks. And if your workloads happens 
to be much more data intensive than metadata intensive the 
stripped spindles assigned to metadata only will be more idle
than the ones doing data.

Stripping everything from the same pool has the potential
to adapt itself to any workload mix better.

I can see that you win for some specific workloads, but it is 
hard to see how you can win over a wide range of workloads
because of that.

> 
> >Also I would expect your design to be slow for metadata read intensive
> >workloads. E.g. have you tried to boot a root partition with dual fs?
> >That's a very important IO benchmark for desktop Linux systems.
> >
> I do not think so. The performance of DualFS is superb in meta-data read 
> intensive workloads . And it is also better than the performance of other 
> file system when reading a directory tree with several copies of the Linux 
> kernel source code (I showed those results on Tuesday at the LSF07 
> workshop)

PDFs available? 

Is that with running a LFS style cleaner inbetween or without?

I would be interested in a "install distro with installer ; boot afterwards
from it" type benchmark. Do you have something like this? 

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

[PATCH 1/1] unify queue_delayed_work and queue_delayed_work_on fix

2007-02-15 Thread Jiri Slaby

Andrew Morton wrote:
> Temporarily at
> 
>   http://userweb.kernel.org/~akpm/2.6.20-mm1/
[...]
> +unify-queue_delayed_work-and-queue_delayed_work_on.patch

I'm getting oops in delayed_work_timer_fn, since cwq->wq is NULL and accessed
there. The patch below fixes the problem for me.

--

unify queue_delayed_work and queue_delayed_work_on fix

Since cwq->wq is unset for other than singlethread_cpu when singlethread
workqueue was created, an oops occurs during bootup. Fix it by setting
correct private value for workqueue.

Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>

---
commit 7bc281be5811f9b1dd01c25eaf492f4765737fd0
tree 7795008066bb89e7489384cde95e63260602d5af
parent 61c2024a2dd044e32747542cfbf4b22251df3bc2
author Jiri Slaby <[EMAIL PROTECTED]> Fri, 16 Feb 2007 00:49:15 +0100
committer Jiri Slaby <[EMAIL PROTECTED]> Fri, 16 Feb 2007 00:49:15 +0100

 kernel/workqueue.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index f2089bf..af5e597 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -210,7 +210,8 @@ int queue_delayed_work_on(int cpu, struct workqueue_struct 
*wq,
 
/* This stores cwq for the moment, for the timer_fn */
set_wq_data(work,
-   per_cpu_ptr(wq->cpu_wq, raw_smp_processor_id()));
+   per_cpu_ptr(wq->cpu_wq, wq->singlethread ?
+   singlethread_cpu : raw_smp_processor_id()));
timer->expires = jiffies + delay;
timer->data = (unsigned long)dwork;
timer->function = delayed_work_timer_fn;
-
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: [git patches] libata updates (mostly fixes)

2007-02-15 Thread Linus Torvalds



On Thu, 15 Feb 2007, Linus Torvalds wrote:
> 
> Ok, this is just _strange_.

Btw, I did pull, but I still think we shouldn't do those kinds of strange 
Kconfig file games.

Linus
-
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 9/11] Panic delay fix

Zachary Amsden wrote:
> So Rusty, Chris, Jeremy, any objections to killing udelay() and
> friends in paravirt-ops?  It would simplify things a bit.  The only
> thing we lose is a slightly faster boot time in the 100% emulated
> device case.  I'm ok with losing that.  Even the PIT fast paths don't
> use udelay, so I don't think we care for runtime performance at all. 

Fine with me.  That always seemed a bit warty to me.

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/

Re: [-mm patch] pci_iomap_regions error handling fix (was Re: 2.6.20-mm1)

On Fri, 16 Feb 2007 16:41:59 +
Frederik Deweerdt <[EMAIL PROTECTED]> wrote:

> On Thu, Feb 15, 2007 at 05:14:08AM -0800, Andrew Morton wrote:
> > 
> > Temporarily at
> > 
> >   http://userweb.kernel.org/~akpm/2.6.20-mm1/
> > 
> Hi,
> 
> It appears that the pcim_iomap_regions() function doesn't get the error
> handling right. It BUGs early at boot with a backtrace along the lines of:
> 
> ahci_init
> pci_register_driver
> driver_register
> [...]
> ahci_init_one
> pcim_iomap_region
> pcim_iounmap
> 
> The following patch allows me to boot. Only the if(mask..) continue;
> part fixes the problem actually, the gotos where changed so that we
> don't try to unmap something we couldn't map anyway.
> 
> Regards,
> Frederik
> 
> Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
> 
> 
> diff --git a/lib/devres.c b/lib/devres.c
> index 2a668dd..eb38849 100644
> --- a/lib/devres.c
> +++ b/lib/devres.c
> @@ -274,21 +274,21 @@ int pcim_iomap_regions(struct pci_dev *pdev, u16 mask, 
> const char *name)
>  
>   rc = pci_request_region(pdev, i, name);
>   if (rc)
> - goto err_region;
> + goto err_inval;
>  
>   rc = -ENOMEM;
>   if (!pcim_iomap(pdev, i, 0))
> - goto err_iomap;
> + goto err_region;
>   }
>  
>   return 0;
>  
> - err_iomap:
> - pcim_iounmap(pdev, iomap[i]);
>   err_region:
>   pci_release_region(pdev, i);
>   err_inval:
>   while (--i >= 0) {
> + if (!(mask & (1 << i)))
> + continue;
>   pcim_iounmap(pdev, iomap[i]);
>   pci_release_region(pdev, i);
>   }

yep, the fix looks good and is needed in mainline, thanks.
-
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: Linux 2.6.16.41-rc1

2007-02-15 Thread S.Çağlar Onur

Hi;

15 Şub 2007 Per tarihinde şunları yazmıştınız:
> Location:
> ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/
>
> git tree:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
>
>
> Changes since 2.6.16.40:

What about CVE-2006-6333, CVE-2006-5753 and CVE-2007-0006?

* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
* http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006

Cheers
-- 
S.Çağlar Onur <[EMAIL PROTECTED]>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!


pgpMfDZoXJp85.pgp
Description: PGP signature

Re: [PATCH 9/11] Panic delay fix

2007-02-15 Thread Pavel Machek

Hi!

> >You know it is ugly. Alan demonstrated it even hurts performance, but
> >being ugly is the main problem.
> >  
> 
> No argument with that.  Well, we're ok with dropping it.  Actually, 
> reverting the entire set of udelay changes now seems wise.  The same
>bug

Good, thanks.
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] No need to use -traditional for processing asm in i386/kernel/

Sam Ravnborg wrote:
> On Thu, Feb 15, 2007 at 01:19:12PM -0800, Jeremy Fitzhardinge wrote:
>   
>> No need to use -traditional for processing asm in i386/kernel/
>>
>> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
>> 
>
> Any possibility that you could 'fix' the three remaining
> uses of -traditional in i386?
>   

Sure.  Looks like they're not even really used.

J

--

No need to use -traditional for processing asm in arch/i386/

Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>

diff -r 9e6791a29740 arch/i386/boot/Makefile
--- a/arch/i386/boot/Makefile   Thu Feb 15 11:57:29 2007 -0800
+++ b/arch/i386/boot/Makefile   Thu Feb 15 15:45:46 2007 -0800
@@ -36,9 +36,9 @@ HOSTCFLAGS_build.o := $(LINUXINCLUDE)
 # ---
 
 $(obj)/zImage:  IMAGE_OFFSET := 0x1000
-$(obj)/zImage:  EXTRA_AFLAGS := -traditional $(SVGA_MODE) $(RAMDISK)
+$(obj)/zImage:  EXTRA_AFLAGS := $(SVGA_MODE) $(RAMDISK)
 $(obj)/bzImage: IMAGE_OFFSET := 0x10
-$(obj)/bzImage: EXTRA_AFLAGS := -traditional $(SVGA_MODE) $(RAMDISK) 
-D__BIG_KERNEL__
+$(obj)/bzImage: EXTRA_AFLAGS := $(SVGA_MODE) $(RAMDISK) -D__BIG_KERNEL__
 $(obj)/bzImage: BUILDFLAGS   := -b
 
 quiet_cmd_image = BUILD   $@
diff -r 9e6791a29740 arch/i386/boot/compressed/Makefile
--- a/arch/i386/boot/compressed/MakefileThu Feb 15 11:57:29 2007 -0800
+++ b/arch/i386/boot/compressed/MakefileThu Feb 15 15:45:46 2007 -0800
@@ -6,7 +6,6 @@
 
 targets:= vmlinux vmlinux.bin vmlinux.bin.gz head.o misc.o 
piggy.o \
vmlinux.bin.all vmlinux.relocs
-EXTRA_AFLAGS   := -traditional
 
 LDFLAGS_vmlinux := -T
 CFLAGS_misc.o += -fPIC
diff -r 9e6791a29740 arch/i386/kernel/Makefile
--- a/arch/i386/kernel/Makefile Thu Feb 15 11:57:29 2007 -0800
+++ b/arch/i386/kernel/Makefile Thu Feb 15 15:45:46 2007 -0800
@@ -44,8 +44,6 @@ obj-$(CONFIG_PARAVIRT)+= paravirt.o
 obj-$(CONFIG_PARAVIRT) += paravirt.o
 obj-y  += pcspeaker.o
 
-EXTRA_AFLAGS   := -traditional
-
 obj-$(CONFIG_SCx200)   += scx200.o
 
 # vsyscall.o contains the vsyscall DSO images as __initdata.
diff -r 9e6791a29740 arch/i386/kernel/entry.S
--- a/arch/i386/kernel/entry.S  Thu Feb 15 11:57:29 2007 -0800
+++ b/arch/i386/kernel/entry.S  Thu Feb 15 15:45:46 2007 -0800
@@ -635,7 +635,7 @@ ENTRY(name) \
SAVE_ALL;   \
TRACE_IRQS_OFF  \
movl %esp,%eax; \
-   call smp_/**/name;  \
+   call smp_##name;\
jmp ret_from_intr;  \
CFI_ENDPROC;\
 ENDPROC(name)
diff -r 9e6791a29740 include/asm-i386/percpu.h
--- a/include/asm-i386/percpu.h Thu Feb 15 11:57:29 2007 -0800
+++ b/include/asm-i386/percpu.h Thu Feb 15 15:45:46 2007 -0800
@@ -20,10 +20,10 @@
 #ifdef CONFIG_SMP
 #define PER_CPU(var, cpu) \
movl __per_cpu_offset(,cpu,4), cpu; \
-   addl $per_cpu__/**/var, cpu;
+   addl $per_cpu__##var, cpu;
 #else /* ! SMP */
 #define PER_CPU(var, cpu) \
-   movl $per_cpu__/**/var, cpu;
+   movl $per_cpu__##var, cpu;
 #endif /* SMP */
 
 #endif /* !__ASSEMBLY__ */

-
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: [git patches] libata updates (mostly fixes)

2007-02-15 Thread Linus Torvalds



On Thu, 15 Feb 2007, Jeff Garzik wrote:
> 
> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> index db185f3..d51f0f1 100644
> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -22,6 +22,7 @@ config IA64
>  
>  config 64BIT
>   bool
> + select ATA_NONSTANDARD if ATA
>   default y

Ok, this is just _strange_.

Tying ATA_NONSTANDARD into ia64 by tying it to the 64BIT config variable 
may work (well, I _assume_ it does), but it's just psychedelic.

How about adding a separate config entry like

config IA64_ATA
bool
depends on ATA
select ATA_NONSTANDARD
default y

which kind of makes sense when you squint just the right way..

Linus
-
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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)

On Thu, 15 Feb 2007 17:46:56 -0500
Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:

> > Me too.  It's due to the linux-kernel-markers patches.  Mathieu, can you
> > take a look please?
> 
> I will give a deeper look in sparse, but I should say up front that I
> add this to the root build tree Makefile :
> 
> LINUXINCLUDE:= -Iinclude \
>$(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
>-include include/linux/autoconf.h \
>-include linux/marker.h
> 
> I guess sparse is maybe not using this Makefile or variable ?

ow, that's going to hurt - this stuff is complex and fragile.

For what reason was that change made?

Pleeze, tricky things like this should be changelogged - we shouldn't need
to ask.  I missed it.


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

2007-02-15 Thread Kumar Gala



On Feb 15, 2007, at 4:33 PM, Sam Ravnborg wrote:


On Thu, Feb 15, 2007 at 01:18:52PM -0600, Kumar Gala wrote:

I was wondering if there was some way to make a Kconfig menu either
be just a menu or a choice depending on another bool being set or  
not.


What I'm trying to accomplish is if CONFIG_ONLY_HAVE_ONE is set I
want it so you can only select on option, however if
CONFIG_ONLY_HAVE_ONE is not set you should be able to select multiple
options.


You can do so using if.
See following example:
--
config ONLY_HAVE_ONE
prompt "only have one?"
boolean

if ONLY_HAVE_ONE
config FOO
bool foo
default y
endif

if !ONLY_HAVE_ONE
choice
prompt "multiple values"
default VAL_FIRST

config VAL_FIRST
bool "First value"

config VAL_SECOND
bool "Second value"
endchoice

endif
--

You should be able to modify this for the usage you ask for.

Hope this is useful,


It is.

Now is there some way to not have to duplicate the 'config choices  
between if ONLY_HAVE_ONE and if !ONLY_HAVE_ONE


To use your example I want to do:

config ONLY_HAVE_ONE
prompt "only have one?"
boolean

if ONLY_HAVE_ONE
config VAL_FIRST
bool "First value"

config VAL_SECOND
bool "Second value"
endif

if !ONLY_HAVE_ONE
choice
prompt "multiple values"
default VAL_FIRST

config VAL_FIRST
bool "First value"

config VAL_SECOND
bool "Second value"
endchoice

endif

I'd like not to have to repeat/duplicate VAL_FIRST, VAL_SECOND, etc..

- k
-
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 3/6] scsi: megaraid_sas - throttle io if FW is busy

2007-02-15 Thread Patro, Sumant

Yes I can make it boolean. 
Will change it in a future patch submission.

Thanks,
Sumant

-Original Message-
From: Richard Knutsson [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 15, 2007 12:10 AM
To: Patro, Sumant
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org; Kolli, Neela;
Yang, Bo; Patro, Sumant
Subject: Re: [PATCH 3/6] scsi: megaraid_sas - throttle io if FW is busy

Sumant Patro wrote:
> Checks added in megasas_queue_command to know if FW is able to process

> commands within the timeout period. If number of retries is 2 or more,

> the driver stops sending cmd to FW. IO is resumed when pending cmd 
> count reduces to 16 or 10 seconds has elapsed from the time cmds were 
> last sent to FW.
>
> Signed-off-by: Sumant Patro <[EMAIL PROTECTED]>
> ---
>
>  drivers/scsi/megaraid/megaraid_sas.c |   27 +
>  drivers/scsi/megaraid/megaraid_sas.h |3 ++
>  2 files changed, 30 insertions(+)
>
>   
[snip]
> diff -uprN linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.h
linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.h
> --- linux-feb13-new-p2/drivers/scsi/megaraid/megaraid_sas.h
2007-02-13 07:22:40.0 -0800
> +++ linux-feb13-new-p3/drivers/scsi/megaraid/megaraid_sas.h
2007-02-13 11:37:09.0 -0800
> @@ -1102,6 +1102,9 @@ struct megasas_instance {
>   atomic_t fw_outstanding;
>   u32 hw_crit_error;
>  
> + u8 is_busy;
>   
Why not "bool is_busy:8;"? It obviously is a boolean. I would also think
false/true would be more descriptive then 0/1.

Richard Knutsson

-
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-15 Thread Bodo Eggert

v j <[EMAIL PROTECTED]> wrote:

> So far I have heard nothing but, "if you don't contribute, screw you."

That's exactly what you tell to the linux community: If they don't contribute
to your project *FOR*NOTHING*IN*RETURN*, you'll punish them by - stamping
your feet, crying out loud and *paying* for another OS. Off cause you are
serious about your rambling - after all, you're no longer spoon-fed for free -
but nobody fears one more small embedded company stuffing their money in
proprietary OS for developement licenses, an extra developement kit, a
royality per device etc.

> All this is fine. Just say so. Make it black and white. Make it
> perfectly clear what is and isn't legal. If we can't load proprietary
> modules, then so be it. It will help everybody if this is out in the
> clear, instead of resorting to stupid half measures like
> EXPORT_SYMBOL_GPL.

You don't have to worry, because your product is based on linux. (I asume,
because if it weren't, you could replace linux by $whatever right now and
be happy, but obviously you aren't happy.) Therefore the GPL license requires
you to release everything under GPL, including your driver. And since your
driver is GPL-ed, you can use GPL symbols.
-- 
"If you see a bomb technician running, follow him."
-U.S.A.F. Ammo Tech Sgt

Friß, Spammer: [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: [git patches] libata updates (mostly fixes)


Jeff Garzik wrote:

--- a/include/linux/ata.h
+++ b/include/linux/ata.h
@@ -352,7 +352,7 @@ static inline int ata_drive_40wire(const u16 *dev_id)
 {
if (ata_id_major_version(dev_id) >= 5 && ata_id_is_sata(dev_id))
return 0;   /* SATA */
-   if (dev_id[93] & 0x4000)
+   if ((dev_id[93] & 0xE000) == 0x6000)
return 0;   /* 80 wire */
return 1;
 }


A thought:  it seems to me that the major version check should be moved 
into ata_id_is_sata().


Jeff


-
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 9/11] Panic delay fix

2007-02-15 Thread Zachary Amsden


Pavel Machek wrote:


You know it is ugly. Alan demonstrated it even hurts performance, but
being ugly is the main problem.
  


No argument with that.  Well, we're ok with dropping it.  Actually, 
reverting the entire set of udelay changes now seems wise.  The same bug 
that happened with i8042 can happen with any hardware device driven by 
the VM in passthrough mode - potentially USB or IDE CDROM or direct SCSI.


Since that is per-device and not global, a global udelay disable really 
is broken in that case, and recompiling individual C files or modules 
for passthrough vs. non-passthrough is not the answer.


So Rusty, Chris, Jeremy, any objections to killing udelay() and friends 
in paravirt-ops?  It would simplify things a bit.  The only thing we 
lose is a slightly faster boot time in the 100% emulated device case.  
I'm ok with losing that.  Even the PIT fast paths don't use udelay, so I 
don't think we care for runtime performance at all.


Zach
-
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] Optimize generic get_unaligned / put_unaligned implementations.

On Thu, 15 Feb 2007 22:18:39 +
Ralf Baechle <[EMAIL PROTECTED]> wrote:

> On Thu, Feb 15, 2007 at 01:53:58PM -0800, Andrew Morton wrote:
> 
> > > The whole union thing was only needed to get rid of a warning but Marcel's
> > > solution does the same thing by attaching the packed keyword to the entire
> > > structure instead, so this patch is now using his macros but using 
> > > __packed
> > > instead.
> > 
> > How do we know this trick will work as-designed across all versions of gcc
> > and icc (at least) and for all architectures and for all sets of compiler
> > options?
> > 
> > Basically, it has to be guaranteed by a C standard.  Is it?
> 
> Gcc info page says:
> 
> [...]
> `packed'
>  The `packed' attribute specifies that a variable or structure field
>  should have the smallest possible alignment--one byte for a
>  variable, and one bit for a field, unless you specify a larger
>  value with the `aligned' attribute.
> [...]
> 

hm.  So if I have

struct bar {
unsigned long b;
} __attribute__((packed));

struct foo {
unsigned long u;
struct bar b;
};

then the compiler can see that foo.b.b is well-aligned, regardless of the
packedness.

Plus some crazy people compile the kernel with icc (or at least they used
to).  What happens there?

> Qed?

worried.
-
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-mm1

2007-02-15 Thread J.A. Magallón

On Thu, 15 Feb 2007 15:31:42 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:

> On Thu, 15 Feb 2007 22:30:17 +0100
> "J.A. Magall__n" <[EMAIL PROTECTED]> wrote:
> 
> > On Thu, 15 Feb 2007 05:14:08 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> > 
> > > 
> > > Temporarily at
> > > 
> > >   http://userweb.kernel.org/~akpm/2.6.20-mm1/
> > > 
> > > Will appear later at
> > > 
> > >  
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/
> > > 
> > > 
> > 
> > Oops plague for me :(.
> > 
> > A lot like this:
> > 
> > ee1394 usblp evdev
> > CPU:1
> > EIP:0060:[]Tainted: P   VLI
> > EFLAGS: 00010246   (2.6.20-jam01 #1)
> > EIP is at sysfs_lookup+0x5b/0x20a
> > eax: f6707118   ebx: f6b33e5c   ecx: f6917d38   edx: 0004
> > esi:    edi: f670717c   ebp: f6b33e24   esp: f6997db4
> > ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> > Process udevd (pid: 3899, ti=f6996000 task=f7e34540 task.ti=f6996000)
> > Stack: f66e1800 f6707118 c016da12 f66e1800 f6707118 c02f75c0 f6707118 
> > f6997f04 
> >f6997e38 c0164238 f6997e44 c210d8c0 f6b39340 f6b393b4 f7a7d025 
> > f6997e38 
> >27692f8b f6997f04 c0165a6a f7a7d01d  000200d2 c037ddac 
> > 0286 
> > Call Trace:
> >  [] d_alloc+0x140/0x198
> >  [] do_lookup+0x128/0x165
> >  [] __link_path_walk+0x7e2/0xc9b
> >  [] link_path_walk+0x45/0xbf
> >  [] do_path_lookup+0x88/0x1cc
> >  [] getname+0x90/0xad
> >  [] __user_walk_fd+0x2f/0x47
> >  [] vfs_lstat_fd+0x16/0x3d
> >  [] sys_lstat64+0xf/0x23
> >  [] do_page_fault+0x326/0x5e2
> >  [] do_page_fault+0x0/0x5e2
> >  [] sysenter_past_esp+0x5f/0x85
> >  [] wait_for_completion_interruptible+0xdf/0xee
> 
> 
> Oh dear.  Any one of about 700 developers might have caused this.
> 
> bisection-search will find this.  Can you upload the .config please?
> 

Here it goes:

http://belly.cps.unizar.es/~magallon/oops/config-2.6.20-jam01

copied from previous and answered missing CONFIG_'s.
Just 2.6.20-m11 + 11-pci-iomap-regions posted in LKML + patch to make
HDIO_OBSOLETE_IDENTITY work on sata (also from LKML).

> > 
> > Full dmesg at:
> > 
> > http://belly.cps.unizar.es/~magallon/oops/oops.txt
> > 
> > And another one on reboot. Picture here:
> > 
> > http://belly.cps.unizar.es/~magallon/oops/IMG_1448.JPG
> > 
> > (sorry, no tripod available ;), just the back of my soft chair).
> >
> > And yes, before nobody says anything, nvidia.ko is loaded.
> > If you really want, I can try without it.
> 
> It would be appreciated if you could do that, thanks.

Probably tomorrow.

--
J.A. Magallon  \   Software is like sex:
 \ It's better when it's free
Mandriva Linux release 2007.1 (Cooker) for i586
Linux 2.6.19-jam07 (gcc 4.1.2 20070115 (prerelease) 
(4.1.2-0.20070115.1mdv2007.1)) #2 SMP PREEMPT
-
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] input: extend EV_LED

2007-02-15 Thread Richard Purdie

On Fri, 2007-02-16 at 00:24 +0100, Pavel Machek wrote:
> > The led framework is generic. If you can write a function to turn it
> > on/off you can drive it with the LED framework.
> 
> Even if that function is slow and sleeps?

The LED class itself can call in interrupt context so you'd have to
schedule a workqueue if you need to sleep.

> > One way I've come up with is adds capability to the class to have LED
> > specific triggers and you can then expose these hardware capabilities as
> > an extra trigger specific to the LED.
> > 
> > Another proposal more specific to this use case was to have some
> > information behind the scenes which the software timer based trigger
> > could use to turn on the "hardware acceleration" if present and capable
> > of the requested mode. This might just need a function pointer in the
> > core so could be quite neat.
> 
> I do not think we want to permit this led to run in "not accelerated"
> mode. I believe i8042 accesses are pretty expensive.

Which means they probably won't work well with the standard triggers.
Not something we can do much about though...

> > Nether patch exists yet.
> 
> Yep, interested party should create one of them :-). (And I'd prefer
> the first one, due to i8042 slowness).

Right, patches welcome :)

Cheers,

Richard


-
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 updates (mostly fixes)


The pile that was waiting for post-conference, largely bug fixes.

As mentioned in the last push, were two other push points planned for
2.6.21:
1) merge libata support for ACPI
2) Remove ugly combined mode hacks in libata-sff and pci/quirks, now
   that old-IDE and libata have the necessary improvements.

Depending on timing and the devres bug count, I may push #2 back to
2.6.22.  The sum of devres + ACPI + remove-combined-mode-quirks
might be more change than should be in 2.6.21.

Both ACPI and remove-combined-quirks are ready to be pushed, it's just a
matter of staging.  Comments welcome.

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

to receive the following updates:

 arch/ia64/Kconfig |1 +
 drivers/ata/libata-core.c |   11 ++-
 drivers/ata/pata_legacy.c |   11 +-
 drivers/ata/pata_qdi.c|4 ++-
 drivers/ata/pata_sl82c105.c   |3 ++
 drivers/ata/sata_nv.c |6 +++-
 drivers/ata/sata_promise.c|   64 +++--
 drivers/ata/sata_vsc.c|8 +++-
 include/asm-ia64/libata-portmap.h |   12 +++
 include/linux/ata.h   |2 +-
 include/linux/libata.h|1 +
 11 files changed, 63 insertions(+), 60 deletions(-)
 create mode 100644 include/asm-ia64/libata-portmap.h

Alan Cox (1):
  libata: Add a host flag to indicate lack of IORDY capability

Mikael Pettersson (2):
  sata_promise: fix missing PATA cable detection
  sata_promise: new EH conversion for 20619 chips, take 2

Nate Dailey (1):
  sata_vsc: use default cache line size if non-zero

Olaf Hering (1):
  add delay around sl82c105_reset_engine calls

Robert Hancock (1):
  sata_nv: handle SError status indication

Tejun Heo (2):
  libata: fix drive side 80c cable check, take 3
  libata: clear TF before IDENTIFYing

Zhang, Yanmin (1):
  ATA convert GSI to irq on ia64

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index db185f3..d51f0f1 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -22,6 +22,7 @@ config IA64
 
 config 64BIT
bool
+   select ATA_NONSTANDARD if ATA
default y
 
 config ZONE_DMA
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 25d8d3f..2cf8251 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1410,7 +1410,16 @@ int ata_dev_read_id(struct ata_device *dev, unsigned int 
*p_class,
}
 
tf.protocol = ATA_PROT_PIO;
-   tf.flags |= ATA_TFLAG_POLLING; /* for polling presence detection */
+
+   /* Some devices choke if TF registers contain garbage.  Make
+* sure those are properly initialized.
+*/
+   tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE;
+
+   /* Device presence detection is unreliable on some
+* controllers.  Always poll IDENTIFY if available.
+*/
+   tf.flags |= ATA_TFLAG_POLLING;
 
err_mask = ata_exec_internal(dev, &tf, NULL, DMA_FROM_DEVICE,
 id, sizeof(id[0]) * ATA_ID_WORDS);
diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c
index 4223e10..98c1fee 100644
--- a/drivers/ata/pata_legacy.c
+++ b/drivers/ata/pata_legacy.c
@@ -89,9 +89,10 @@ static int probe_all;/* Set to check 
all ISA port ranges */
 static int ht6560a;/* HT 6560A on primary 1, secondary 2, 
both 3 */
 static int ht6560b;/* HT 6560A on primary 1, secondary 2, 
both 3 */
 static int opti82c611a;/* Opti82c611A on primary 1, 
secondary 2, both 3 */
-static int opti82c46x; /* Opti 82c465MV present (pri/sec autodetect) */
+static int opti82c46x; /* Opti 82c465MV present (pri/sec 
autodetect) */
 static int autospeed;  /* Chip present which snoops speed 
changes */
 static int pio_mask = 0x1F;/* PIO range for autospeed devices */
+static int iordy_mask = 0x;/* Use iordy if available */
 
 /**
  * legacy_set_mode -   mode setting
@@ -113,6 +114,7 @@ static int legacy_set_mode(struct ata_port *ap, struct 
ata_device **unused)
for (i = 0; i < ATA_MAX_DEVICES; i++) {
struct ata_device *dev = &ap->device[i];
if (ata_dev_enabled(dev)) {
+   ata_dev_printk(dev, KERN_INFO, "configured for PIO\n");
dev->pio_mode = XFER_PIO_0;
dev->xfer_mode = XFER_PIO_0;
dev->xfer_shift = ATA_SHIFT_PIO;
@@ -695,6 +697,7 @@ static __init int legacy_init_one(int port, unsigned long 
io, unsigned long ctrl
void __iomem *io_addr, *ctrl_addr;
int pio_modes = pio_mask;
u32 mask = (1 << port);
+   u32 iordy = (iordy_mask & mask) ? 0: ATA_FLAG_NO_IORDY;
int ret;
 
pdev = platform_device_register_simp

Re: [PATCH] add CONFIG_PNP=y to x86_64 defconfig

2007-02-15 Thread Andi Kleen


> Maybe we should select CONFIG_PNP from CONFIG_ACPI?

That would be probably better I think because it will fix existing
user configurations. You'll get the defconfig for free with that too.

-Andi
-
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: Modular kernel (2.6.20) and software raid auto detection

2007-02-15 Thread Neil Brown

On Thursday February 15, [EMAIL PROTECTED] wrote:
> 
> With my ide driver and the md stuff all built into the kernel, my software 
> raid drives and associated /dev/md? devices are detected and created by the 
> kernel.

Yep.

> 
> With the md stuff built in but the ide driver modular and loaded later by 
> udev, the drives are not detected.

No, they aren't.

> 
> So, I guessed that perhaps if I made the md stuff modular aswell and load it 
> _after_ loading the ide driver, this might kickstart the auto-detect stuff. 
> But it didn't :(

No, it wouldn't.

> 
> Is there a way to make auto-detection work without having the ide driver 
> built 
> in?

Don't use in-kernel auto-detection.  Use mdadm to do the
auto-detection for you.

  mdadm --assemble --scan --homehost='' --auto-update-homehost

might work providing your hostname has been set by the time it runs.

NeilBrown
-
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] aio: fix kernel bug when page is temporally busy

2007-02-15 Thread Ananiev, Leonid I

>> If EIOCBRETRY then generic_file_aio_write() will be recalled for the
>> same iocb.
> Only if kick_iocb() is called.  It won't be called if i_i_p2_r() was  
> the only thing to return -EIOCBRETRY.
It is not need to call kick_iocb()
for generic_file_aio_write() calling.
It is recalled without any wakeup waiting:
for (;;) {
ret = filp->f_op->aio_write(&kiocb, &iov, 1,
kiocb.ki_pos);
if (ret != -EIOCBRETRY)
break;
wait_on_retry_sync_kiocb(&kiocb);
}
Note: wait_on_retry_sync_kiocb() does not wait.
That is for dio. For aio iocb generic_file_aio_write() call
is required from ki_run_list while next io_submit or
read_events() is called.
So when an IO hang may happen?

>> It overwrites -EIOCBQUEUED
Do you mean that there is one more kernel bug which
overwrites -EIOCBQUEUED by any errno or number of bytes and this
new value is returned to caller as an IO result
while IO is not finished yet.

The proposed patch does not crate this bug if any.
It actually fixes a kernel panic bag when iocb.users count becomes
incorrect. The bag " Kernel BUG at fs/aio.c:509" is there because
aio_run_iocb() have not a chance to differ real EIO and
EIO which is actually means EAGAYN or EIOCBRETRY.
I'me sure the patch changes source code in correct direction:
to differentiate that two kinds of EIOs.

> Have you read the giant comment over the definition of struct kiocb  
> in include/linux/aio.h?
I have read. But compiler has not: it did not create an object code for
* If ki_retry returns -EIOCBRETRY ...

>>> This can lead to reference count confusion.
>> But just reference count confusion was deleted by patch. Isn't it?
>Sorry, I don't understand what you're trying to ask here.
One of reference count iocb.users confusion is deleted by the patch.
I'm not sure that there is other bag.

At least I have not see IO hang while testing.
It is interesting that I've not seen any EIOCBQUEUED returned
to aio_run_iocb() during 5 hours aiostress running.
Does it mean that EIOCBQUEUED is always reset and never returned?

Leonid

-Original Message-
From: Zach Brown [mailto:[EMAIL PROTECTED] 
Sent: Thursday, February 15, 2007 10:23 PM
To: Ananiev, Leonid I
Cc: Ken Chen; [EMAIL PROTECTED]; Andrew Morton;
linux-kernel@vger.kernel.org; linux-aio; Chris Mason
Subject: Re: [PATCH] aio: fix kernel bug when page is temporally busy

On Feb 15, 2007, at 11:11 AM, Ananiev, Leonid I wrote:

>> It returns -EIOCBRETRY without guaranteeing that kick_iocb() will be
>> called.  This can lead to operations hanging
>
> If EIOCBRETRY then generic_file_aio_write() will be recalled for the
> same iocb.

Only if kick_iocb() is called.  It won't be called if i_i_p2_r() was  
the only thing to return -EIOCBRETRY.

>
>> It overwrites -EIOCBQUEUED, leading to an aio_complete() while a
>> retry is happening.
>
> EIOCBQUEUED or EIOCBRETRY does not lead to aio_complete() call:

Not by fs/aio.c, but *by the place that originated -EIOCBQUEUED*.   
Later.  After IO has completed.  see fs/direct-io.c:dio_bio_end_aio().

This is what -EIOCBQUEUED means!  It's a promise to call aio_complete 
() in the future.

Have you read the giant comment over the definition of struct kiocb  
in include/linux/aio.h?

>> This can lead to reference count confusion.
> But just reference count confusion was deleted by patch. Isn't it?

Sorry, I don't understand what you're trying to ask here.

- z
-
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-15 Thread Robert Hancock


linux-os (Dick Johnson) wrote:

There are a lot of device drivers that will never make it into the
mainline kernel because they are for one-of-a-kind devices or boards
that companies embed into their products. Nobody would even want a
copy of the software to interface with something that they would
never even have. When Version 2.6 started, it became necessary to
use special tools and procedures to compile a module that was not
inside the mainline kernel. However, it was still quite easy. Recently,
somebody, apparently with an advanced degree in obfuscation, has made
that more difficult. This is abuse, pure and simple. That, in my
opinion, is one of the major reasons why people who use Linux in
embedded systems end up using very old versions.


What are you talking about? There's nothing wrong with external module 
compilation in current kernels. You need about a 5-line makefile that 
calls the kernel build system, and it works fine.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

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

On Thu, 15 Feb 2007 22:30:17 +0100
"J.A. Magall__n" <[EMAIL PROTECTED]> wrote:

> On Thu, 15 Feb 2007 05:14:08 -0800, Andrew Morton <[EMAIL PROTECTED]> wrote:
> 
> > 
> > Temporarily at
> > 
> >   http://userweb.kernel.org/~akpm/2.6.20-mm1/
> > 
> > Will appear later at
> > 
> >  
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/
> > 
> > 
> 
> Oops plague for me :(.
> 
> A lot like this:
> 
> ee1394 usblp evdev
> CPU:1
> EIP:0060:[]Tainted: P   VLI
> EFLAGS: 00010246   (2.6.20-jam01 #1)
> EIP is at sysfs_lookup+0x5b/0x20a
> eax: f6707118   ebx: f6b33e5c   ecx: f6917d38   edx: 0004
> esi:    edi: f670717c   ebp: f6b33e24   esp: f6997db4
> ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> Process udevd (pid: 3899, ti=f6996000 task=f7e34540 task.ti=f6996000)
> Stack: f66e1800 f6707118 c016da12 f66e1800 f6707118 c02f75c0 f6707118 
> f6997f04 
>f6997e38 c0164238 f6997e44 c210d8c0 f6b39340 f6b393b4 f7a7d025 
> f6997e38 
>27692f8b f6997f04 c0165a6a f7a7d01d  000200d2 c037ddac 
> 0286 
> Call Trace:
>  [] d_alloc+0x140/0x198
>  [] do_lookup+0x128/0x165
>  [] __link_path_walk+0x7e2/0xc9b
>  [] link_path_walk+0x45/0xbf
>  [] do_path_lookup+0x88/0x1cc
>  [] getname+0x90/0xad
>  [] __user_walk_fd+0x2f/0x47
>  [] vfs_lstat_fd+0x16/0x3d
>  [] sys_lstat64+0xf/0x23
>  [] do_page_fault+0x326/0x5e2
>  [] do_page_fault+0x0/0x5e2
>  [] sysenter_past_esp+0x5f/0x85
>  [] wait_for_completion_interruptible+0xdf/0xee


Oh dear.  Any one of about 700 developers might have caused this.

bisection-search will find this.  Can you upload the .config please?

> 
> Full dmesg at:
> 
> http://belly.cps.unizar.es/~magallon/oops/oops.txt
> 
> And another one on reboot. Picture here:
> 
> http://belly.cps.unizar.es/~magallon/oops/IMG_1448.JPG
> 
> (sorry, no tripod available ;), just the back of my soft chair).
>
> And yes, before nobody says anything, nvidia.ko is loaded.
> If you really want, I can try without it.

It would be appreciated if you could do that, thanks.
-
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] input: extend EV_LED

2007-02-15 Thread Németh Márton

Pavel Machek <[EMAIL PROTECTED]> wrote:

> Hi!
> 
> > >I do not know the LED subsystem in detail, but I do not 
> > >know
> > >any possibility to access the i8042 from different 
> > >subsystem
> > >than the input subsystem.
> > >
> > >What do you think and recommend?
> > 
> > I think you need to use leds framework for what you are 
> > trying to do.
> 
> I'm actually not sure if led framework can do that. It was
designed
> for leds on gpios, and handles blinking itself.
> 
> But he could export two leds :-).

Hi,

what do you mean about two leds? The first one would be
off/0.5Hz and the other off/1Hz?

I read in linux/Documentation/led-class.txt the following:

| Some leds can be programmed to flash in hardware. As this
isn't a generic
| LED device property, this should be exported as a device
specific sysfs
| attribute rather than part of the class if this
functionality is required.

Does it mean that neither the input subsystem nor the led
subsystem is designed for hardware acelerated blinking leds?
Is there any usual way what attribute a hw accelerated
blinking LED_MAIL should export?

NMarci

__
10.000 Ft ajándék fotókidolgozás minden Panasonic digitális fényképezőgéphez!
FotoMarket Online Fotóáruház 
http://ad.adverticum.net/b/cl,1,6022,99786,162268/click.prm

-
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] mm: NUMA replicated pagecache

2007-02-15 Thread Lee Schermerhorn

On Thu, 2007-02-15 at 01:38 +0100, Nick Piggin wrote:
> On Wed, Feb 14, 2007 at 03:32:04PM -0500, Lee Schermerhorn wrote:
> > On Tue, 2007-02-13 at 07:09 +0100, Nick Piggin wrote:
> > > Hi,
> > > 
> > > Just tinkering around with this and got something working, so I'll see
> > > if anyone else wants to try it.
> > > 
> > > Not proposing for inclusion, but I'd be interested in comments or results.
> > > 
> > > Thanks,
> > > Nick
> > 
> > I've included a small patch below that allow me to build and boot with
> > these patches on an HP NUMA platform.  I'm still seeing an "unable to
> 
> Thanks Lee. Merged.

No worries...

I've attached another patch that closes one race and fixes a context
problem [irq/preemption state] in __unreplicate_page_range().  This
makes the locking even uglier :-(.

I get further with this patch.  Boot all the way up and can run fine
with page replication.  However, I still get a NULL pcd in
find_get_page_readonly() when attempting a highly parallel kernel build
[16cpu/4node numa platform].  I'm still trying to track that down.

Question about locking:  looks like the pcache_descriptor members are
protected by the tree_lock of the mapping, right?

Lee

==

Additional fixes for Nick's page cache replication patch

1) recheck that page is replicated after down grading mapping tree lock.
   return results of check from __replicate_pcache().

2) in __unreplicate_pcache_range(), call __unreplicate_pcache() in appropriate
   context vis a vis irqs and preemption

3) report null pcd in find_get_page_readonly().  shouldn't happen?

Signed-off-by:  Lee Schermerhorn <[EMAIL PROTECTED]>

 mm/filemap.c |   27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

Index: Linux/mm/filemap.c
===
--- Linux.orig/mm/filemap.c 2007-02-15 15:25:23.0 -0500
+++ Linux/mm/filemap.c  2007-02-15 17:42:27.0 -0500
@@ -669,7 +669,6 @@ static int __replicate_pcache(struct pag
struct pcache_desc *pcd;
int nid, page_node;
int writelock = 0;
-   int ret = 0;
 
if (unlikely(PageSwapCache(page)))
goto out;
@@ -691,7 +690,7 @@ again:
lock_page(page);
if (!page->mapping) {
unlock_page(page);
-   return 0;
+   goto read_lock_out; /* reacquire read lock */
}
write_lock_irq(&mapping->tree_lock);
writelock = 1;
@@ -716,15 +715,19 @@ again:
BUG_ON(radix_tree_insert(&mapping->page_tree, offset, pcd));
radix_tree_tag_set(&mapping->page_tree, offset,
PAGECACHE_TAG_REPLICATED);
-   ret = 1;
 out:
if (writelock) {
write_unlock_irq(&mapping->tree_lock);
unlock_page(page);
+read_lock_out:
read_lock_irq(&mapping->tree_lock);
}
 
-   return ret;
+   /*
+* ensure page still replicated after demoting the tree lock
+*/
+   return (radix_tree_tag_get(&mapping->page_tree, offset,
+   PAGECACHE_TAG_REPLICATED));
 }
 
 void __unreplicate_pcache(struct address_space *mapping, unsigned long offset)
@@ -813,6 +816,11 @@ retry:
 replicated:
nid = numa_node_id();
pcd = radix_tree_lookup(&mapping->page_tree, offset);
+   if (!pcd) {
+   printk(KERN_DEBUG "%s NULL pcd at tagged offset\n",
+   __FUNCTION__);
+   BUG();
+   }
if (!node_isset(nid, pcd->nodes_present)) {
struct page *repl_page;
 
@@ -991,9 +999,16 @@ again:
struct pcache_desc *pcd = (struct pcache_desc 
*)pages[i];
pages[i] = (struct page *)pcd->master->index;
}
-   read_unlock(&mapping->tree_lock);
+   read_unlock(&mapping->tree_lock);   /* irqs/preempt off */
for (i = 0; i < ret; i++) {
-   write_lock(&mapping->tree_lock);
+   /*
+* __unreplicate_pcache() expects tree write locked
+* with irq/preemption disabled.
+*/
+   if (i)
+   write_lock_irq(&mapping->tree_lock);
+   else
+   write_lock(&mapping->tree_lock);
__unreplicate_pcache(mapping, (unsigned long)pages[i]);
}
read_lock_irq(&mapping->tree_lock);


-
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] MAINTAINERS: mark framebuffer as Orphan

On Thu, 15 Feb 2007 13:25:49 -0800
Randy Dunlap <[EMAIL PROTECTED]> wrote:

> From: Randy Dunlap <[EMAIL PROTECTED]>
> 
> Are we ready to do this?
> I'd love for Tony to return, but he's been missing for awhile now.
> 
> So this give us the following major areas that are marked as Orphan:
> 
> Firmware loader
> Framebuffer
> Serial (8250/16x50)
> 
> and PCMCIA has a Team.  It doesn't seem to be hurting.  :)
> 
> Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
> ---
>  MAINTAINERS |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> --- linux-2.6.20-git9.orig/MAINTAINERS
> +++ linux-2.6.20-git9/MAINTAINERS
> @@ -1321,11 +1321,9 @@ W: http://www.farsite.co.uk/
>  S:   Supported
>  
>  FRAMEBUFFER LAYER
> -P:   Antonino Daplas
> -M:   [EMAIL PROTECTED]
>  L:   [EMAIL PROTECTED] (subscribers-only)
>  W:   http://linux-fbdev.sourceforge.net/
> -S:   Maintained
> +S:   Orphan

No, James is keeping an eye on things, but he obviously doesn't have as
much time to work on it as Tony did.

My point was that for bugs such as the one Pavel identified we're no longer
able to palm it off on the maintainer and expect magic to happen.  Either we
all dig in and help out or things don't get fixed.
-
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] input: extend EV_LED

2007-02-15 Thread Pavel Machek

Hi!

> > > > >I do not know the LED subsystem in detail, but I do not 
> > > > >know any possibility to access the i8042 from different 
> > > > >subsystem than the input subsystem.
> > > > >
> > > > >What do you think and recommend?
> > > > 
> > > > I think you need to use leds framework for what you are 
> > > > trying to do.
> > > 
> > > I'm actually not sure if led framework can do that. It was
> > > designed for leds on gpios, and handles blinking itself.
> 
> The led framework is generic. If you can write a function to turn it
> on/off you can drive it with the LED framework.

Even if that function is slow and sleeps?

> > > But he could export two leds :-).
> >
> > what do you mean about two leds? The first one would be
> > off/0.5Hz and the other off/1Hz?
> > 
> > I read in linux/Documentation/led-class.txt the following:
> > 
> > | Some leds can be programmed to flash in hardware. As this
> > isn't a generic
> > | LED device property, this should be exported as a device
> > specific sysfs
> > | attribute rather than part of the class if this
> > functionality is required.
> > 
> > Does it mean that neither the input subsystem nor the led
> > subsystem is designed for hardware acelerated blinking leds?
> > Is there any usual way what attribute a hw accelerated
> > blinking LED_MAIL should export?
> 
> This has been discussed in several places several times. The problem
> with hardware accelerated flashing is that you're are often limited to
> certain constraints (this case being no exception) and indicating what
> these are to userspace in a generic fashion is difficult.
> 
> One way I've come up with is adds capability to the class to have LED
> specific triggers and you can then expose these hardware capabilities as
> an extra trigger specific to the LED.
> 
> Another proposal more specific to this use case was to have some
> information behind the scenes which the software timer based trigger
> could use to turn on the "hardware acceleration" if present and capable
> of the requested mode. This might just need a function pointer in the
> core so could be quite neat.

I do not think we want to permit this led to run in "not accelerated"
mode. I believe i8042 accesses are pretty expensive.

> Nether patch exists yet.

Yep, interested party should create one of them :-). (And I'd prefer
the first one, due to i8042 slowness).

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

2007-02-15 Thread Michal Piotrowski

Andrew Morton napisał(a):
> On Thu, 15 Feb 2007 15:37:20 +0100
> Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> 
>> Andrew Morton napisa__(a):
>>> Temporarily at
>>>
>>>   http://userweb.kernel.org/~akpm/2.6.20-mm1/
>>>
>>> Will appear later at
>>>
>>>  
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm1/
>>>
>>>
>> BUG: sleeping function called from invalid context at 
>> /mnt/md0/devel/linux-mm/mm/slab.c:3043
>> in_atomic():1, irqs_disabled():0
>> 1 lock held by artsd/3819:
>>  #0:  (&new->lock){--..}, at: [] ipc_lock+0x35/0x4f
>>  [] show_trace_log_lvl+0x1a/0x2f
>>  [] show_trace+0x12/0x14
>>  [] dump_stack+0x16/0x18
>>  [] __might_sleep+0xc9/0xcf
>>  [] kmem_cache_zalloc+0x28/0xe5
>>  [] do_shmat+0x111/0x372
>>  [] sys_ipc+0x148/0x1b5
>>  [] syscall_call+0x7/0xb
> 
> That's shm-make-sysv-ipc-shared-memory-use-stacked-files.patch, brought to
> us by Eric-who-hasnt-read-Documentation/SubmitChecklist.
> 
> Like this, I guess:
> 
> diff -puN ipc/shm.c~shm-make-sysv-ipc-shared-memory-use-stacked-files-fix 
> ipc/shm.c

I might be drunk...

This patch still doesn't solve the problem.

BUG: sleeping function called from invalid context at 
/mnt/md0/devel/linux-mm/mm/slab.c:3043
in_atomic():1, irqs_disabled():0
1 lock held by Xorg/2885:
 #0:  (&new->lock){--..}, at: [] ipc_lock+0x35/0x4f
 [] show_trace_log_lvl+0x1a/0x2f
 [] show_trace+0x12/0x14
 [] dump_stack+0x16/0x18
 [] __might_sleep+0xc9/0xcf
 [] kmem_cache_alloc+0x28/0xbf
 [] get_empty_filp+0x6a/0x173
 [] do_shmat+0x136/0x390
 [] sys_ipc+0x148/0x1b5
 [] syscall_call+0x7/0xb
 ===
BUG: MAX_LOCK_DEPTH too low!
turning off the locking correctness validator.
do_IRQ: stack overflow: -52
 [] show_trace_log_lvl+0x1a/0x2f
 [] show_trace+0x12/0x14
 [] dump_stack+0x16/0x18
 [] do_IRQ+0x95/0xc1
BUG: unable to handle kernel paging request at virtual address 0e200034
 printing eip:
c01052e2
*pde = 
Oops:  [#1]
PREEMPT SMP
last sysfs file: 
/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/vendor
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd 
nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT 
nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter 
ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram 
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 evdev snd_mixer_oss 
snd_pcm snd_timer skge snd 8139too intel_agp sk98lin agpgart soundcore mii 
i2c_i801 snd_page_alloc ide_cd cdrom rtc unix
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00013046   (2.6.20-mm1 #16)
EIP is at dump_trace+0x88/0x9e
eax:    ebx: f412c01c   ecx: c0429344   edx: c03cf8fa
BUG: unable to handle kernel paging request at virtual address 8d17ca6c
 printing eip:
c011d927
*pde = 
esi: 0e20   edi: c03daed2   ebp: f412bfd0   esp: f412bfc0
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process Xorg (pid: 2885, ti=f412a000 task=f4a58aa0 task.ti=f412c000)
Stack: c7422ac0 c03daed2 0011  f412bfe4 c0105312 c0429344 c03daed2
   0004 f412bff0 c0105a25 c03daed2 f412bffc c0105ae7 f412c008 f412c01c
Call Trace:
 [] show_trace_log_lvl+0x1a/0x2f
 [] show_stack_log_lvl+0x9d/0xac
 [] show_registers+0x1ed/0x34c
 [] die+0x11d/0x234
 [] do_page_fault+0x47c/0x55b
 [] error_code+0x7c/0x84
 [] show_trace_log_lvl+0x1a/0x2f
 [] show_trace+0x12/0x14
 [] dump_stack+0x16/0x18
 [] do_IRQ+0x95/0xc1
BUG: unable to handle kernel paging request at virtual address 0e200034
 printing eip:
c01052e2
*pde = 
Oops:  [#2]
PREEMPT SMP
last sysfs file: 
/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/vendor
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nfsd exportfs lockd 
nfs_acl autofs4 sunrpc af_packet nf_conntrack_netbios_ns ipt_REJECT 
nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink xt_tcpudp iptable_filter 
ip_tables x_tables ipv6 binfmt_misc thermal processor fan container nvram 
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 evdev snd_mixer_oss 
snd_pcm snd_timer skge snd 8139too intel_agp sk98lin agpgart soundcore mii 
i2c_i801 snd_page_alloc ide_cd cdrom rtc unix
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00013046   (2.6.20-mm1 #16)
EIP is at dump_trace+0x88/0x9e
eax:    ebx: f412c01c   ecx: c0429344   edx: c03cf8fa
esi: 0e20   edi: c03cfa80   ebp: f412be5c   esp: f412be4c
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process Xorg (pid: 2885, ti=f412a000 task=f4a58aa0 task.ti=f412c000)
Stack: f412be64 c03cfa80 0010  f412be70 c0105312 c0429344 c03cfa80
   f412c003 f412be94 c01053c4 c03cfa80 c03cfa80 f412bf88 f412bfc0 f4a58c3c
   002b 0040 f412bef8 c01055c0 c03cfa80 0010 f4a58c3c 0b45
Call Trace:
 [] show_trace_log_lvl+0x1a/0x2f
 [] show_stack_log_lvl+0x9d/0xac
 [] show_registers+0x1ed/0x34c
 [] die+

Re: GPL vs non-GPL device drivers

2007-02-15 Thread Bernd Petrovitsch

On Thu, 2007-02-15 at 17:41 -0500, Jeff Garzik wrote:
> Bernd Petrovitsch wrote:
> > On Thu, 2007-02-15 at 18:40 +1100, Nick Piggin wrote:
> >> Rhetorical question: what stops me from taking somebody's copyrighted
> >> work, stripping the copyrights or falsely claiming to have a license
> >> to redistribute it, then selling it?
> > 
> > No one.
> 
> Well, that's not quite true, is it?  This little microcosm of life has 
> its checks and balances, and certainly strives for an equilibrium.
> 
> You make a choice, as in Nick's example, to balance the risk of being 

ACK.

> caught, being sued, being shamed, and/or being avoided by customers 
> against the perceived rewards.

ACK, *iff* you get caught.

But I cannot stop you if you just do it. Perhaps I can stop you later on
if I find it out, can proove it sufficient to go to court (or at least
threaten enough) and have the economical power to do it.

> Negative incentives are present, is the overall answer, even if they are 
> not immediately obvious and spelled out in excruciating detail.

Of course. And given the cases on gpl-violations.org I fear I'm right.

Bernd
-- 
Firmix Software GmbH   http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
  Embedded Linux Development and Services

-
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/05] Linux Kernel Markers - kernel 2.6.20

2007-02-15 Thread Vara Prasad


Andrew Morton wrote:


On 15 Feb 2007 10:28:57 -0500
[EMAIL PROTECTED] (Frank Ch. Eigler) wrote:

 


akpm wrote:

   


[...]  And what can I do with these markers?  And once I've done it,
are there any userspace applications I can use to get the data out
in human-usable form?  [...]
 


The LTTng user-space programs use it today.  Systemtap used to support
the earlier marker prototype and will be rapidly ported over to this
new API upon acceptance.

   



That's good.

It would be beneficial if some people from those projects could spare the
cycles to carefully review and runtime test this code.
 



Sure, as soon as SystemTap translator supports this new marker mechanism 
we will give it a spin and report results.



Also, I'm not 100% clear on where we ended up with the huge
static-vs-dynamic flamewar.  Did everyone end up happy?  Is this patchset a
reasonable compromise?  Or do we need a rematch?
 

From my view this is a good compromise. We all realized in that long 
discussion thread that we need a way to mark the code in the middle of 
functions that can later be activated dynamically. Mathieu's current 
implementation meets that goal. I will be happy to see this in.


Thanks,
Vara Prasad


-
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 000/196] V4L/DVB updates

2007-02-15 Thread Georgi Chorbadzhiyski


Mauro Carvalho Chehab wrote:

Basically, this series adds support for a bunch of newer cards and newer
drivers, do some relevant cleanups on cx88 (improving source code 
readability and reducing binary code size), adds FM radio support on

pvrusb2 and do several other fixes and improvements.


Hi, what is the status of Mantis driver for Twinhham DVB-S cards
and support for their CAM interface?

--
Georgi Chorbadzhiyski
http://georgi.unixsol.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] input: extend EV_LED

2007-02-15 Thread Richard Purdie

On Thu, 2007-02-15 at 23:47 +0100, Németh Márton wrote:
> Pavel Machek <[EMAIL PROTECTED]> wrote:
> > > >I do not know the LED subsystem in detail, but I do not 
> > > >know any possibility to access the i8042 from different 
> > > >subsystem than the input subsystem.
> > > >
> > > >What do you think and recommend?
> > > 
> > > I think you need to use leds framework for what you are 
> > > trying to do.
> > 
> > I'm actually not sure if led framework can do that. It was
> > designed for leds on gpios, and handles blinking itself.

The led framework is generic. If you can write a function to turn it
on/off you can drive it with the LED framework.

> > But he could export two leds :-).
>
> what do you mean about two leds? The first one would be
> off/0.5Hz and the other off/1Hz?
> 
> I read in linux/Documentation/led-class.txt the following:
> 
> | Some leds can be programmed to flash in hardware. As this
> isn't a generic
> | LED device property, this should be exported as a device
> specific sysfs
> | attribute rather than part of the class if this
> functionality is required.
> 
> Does it mean that neither the input subsystem nor the led
> subsystem is designed for hardware acelerated blinking leds?
> Is there any usual way what attribute a hw accelerated
> blinking LED_MAIL should export?

This has been discussed in several places several times. The problem
with hardware accelerated flashing is that you're are often limited to
certain constraints (this case being no exception) and indicating what
these are to userspace in a generic fashion is difficult.

One way I've come up with is adds capability to the class to have LED
specific triggers and you can then expose these hardware capabilities as
an extra trigger specific to the LED.

Another proposal more specific to this use case was to have some
information behind the scenes which the software timer based trigger
could use to turn on the "hardware acceleration" if present and capable
of the requested mode. This might just need a function pointer in the
core so could be quite neat.

Nether patch exists yet.

Cheers,

Richard

-
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] MAINTAINERS: mark framebuffer as Orphan

2007-02-15 Thread Randy Dunlap

On Thu, 15 Feb 2007 22:26:10 + (GMT) James Simmons wrote:

> 
> I wouldn't say it orphan. I just can't spend 8 hours a day on it. 
> Alot of patches have been flowing into the layer.

So would you like to leave it as Maintained or change it to
"Odd Fixes"?  (Maintained => a maintainer)  From the MAINTAINTERS file:

Supported:  Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
Odd Fixes:  It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete:   Old code. Something tagged obsolete generally means
it has been replaced by a better system and you
should be using that.


> On Thu, 15 Feb 2007, Randy Dunlap wrote:
> 
> > From: Randy Dunlap <[EMAIL PROTECTED]>
> > 
> > Are we ready to do this?
> > I'd love for Tony to return, but he's been missing for awhile now.
> > 
> > So this give us the following major areas that are marked as Orphan:
> > 
> > Firmware loader
> > Framebuffer
> > Serial (8250/16x50)
> > 
> > and PCMCIA has a Team.  It doesn't seem to be hurting.  :)
> > 
> > Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
> > ---
> >  MAINTAINERS |4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > --- linux-2.6.20-git9.orig/MAINTAINERS
> > +++ linux-2.6.20-git9/MAINTAINERS
> > @@ -1321,11 +1321,9 @@ W:   http://www.farsite.co.uk/
> >  S: Supported
> >  
> >  FRAMEBUFFER LAYER
> > -P: Antonino Daplas
> > -M: [EMAIL PROTECTED]
> >  L: [EMAIL PROTECTED] (subscribers-only)
> >  W: http://linux-fbdev.sourceforge.net/
> > -S: Maintained
> > +S: Orphan
> >  
> >  FREESCALE SOC FS_ENET DRIVER
> >  P: Pantelis Antoniou

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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] sata_nv: handle SError status indication


Robert Hancock wrote:

ADMA-capable controllers provide a bit in the status register that appears
to indicate that the controller detected an SError condition. Update 
sata_nv

to detect this and trigger error handling in order to handle the fault.

Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>


applied


-
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] ATA convert GSI to irq on ia64


Zhang, Yanmin wrote:

On Thu, 2007-02-08 at 20:19 -0500, Jeff Garzik wrote:

Zhang, Yanmin wrote:

If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the
fixed irq number. On ia64 platform, such numbers are GSI and should be converted
to irq vector.

Below patch against kernel 2.6.20 fixes it.

Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]>
IA64 should create its own libata-portmap.h, rather than modifying the 
one in asm-generic with arch-specific choices.


powerpc is a current example of this (and currently the only 
non-asm-generic user) found in kernel 2.6.20.

Thank Jeff. I worked out a new patch.

If an ATA drive uses legacy mode, ata driver will choose 14 and 15 as the fixed
irq number. On ia64 platform, such numbers are GSI and should be converted to 
irq
vector.

Below patch against kernel 2.6.20 fixes it.
 
Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]>


applied


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

[PATCH] s2io: add PCI error recovery support

2007-02-15 Thread Linas Vepstas


Koushik, Raju,

Please review, comment, and if you find this acceptable, 
please forward upstream. This patch incorporates all of 
fixes resulting from the last set of discussions, circa 
November 2006.

--linas

This patch adds PCI error recovery support to the 
s2io 10-Gigabit ethernet device driver. Fourth revision,
blocks interrupts and the watchdog. Adds a flag to 
s2io_down(), to avoid doing I/O when PCI bus is offline.

Tested, seems to work well.

Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
Acked-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
Cc: Raghavendra Koushik <[EMAIL PROTECTED]>
Cc: Ananda Raju <[EMAIL PROTECTED]>
Cc: Wen Xiong <[EMAIL PROTECTED]>


 drivers/net/s2io.c |  116 ++---
 drivers/net/s2io.h |5 ++
 2 files changed, 116 insertions(+), 5 deletions(-)

Index: linux-2.6.20-git4/drivers/net/s2io.c
===
--- linux-2.6.20-git4.orig/drivers/net/s2io.c   2007-02-15 15:39:35.0 
-0600
+++ linux-2.6.20-git4/drivers/net/s2io.c2007-02-15 16:15:10.0 
-0600
@@ -435,11 +435,18 @@ static struct pci_device_id s2io_tbl[] _
 
 MODULE_DEVICE_TABLE(pci, s2io_tbl);
 
+static struct pci_error_handlers s2io_err_handler = {
+   .error_detected = s2io_io_error_detected,
+   .slot_reset = s2io_io_slot_reset,
+   .resume = s2io_io_resume,
+};
+
 static struct pci_driver s2io_driver = {
   .name = "S2IO",
   .id_table = s2io_tbl,
   .probe = s2io_init_nic,
   .remove = __devexit_p(s2io_rem_nic),
+  .err_handler = &s2io_err_handler,
 };
 
 /* A simplifier macro used both by init and free shared_mem Fns(). */
@@ -2577,6 +2584,9 @@ static void s2io_netpoll(struct net_devi
u64 val64 = 0xULL;
int i;
 
+   if (pci_channel_offline(nic->pdev))
+   return;
+
disable_irq(dev->irq);
 
atomic_inc(&nic->isr_cnt);
@@ -3079,6 +3089,8 @@ static void alarm_intr_handler(struct s2
int i;
if (atomic_read(&nic->card_state) == CARD_DOWN)
return;
+   if (pci_channel_offline(nic->pdev))
+   return;
nic->mac_control.stats_info->sw_stat.ring_full_cnt = 0;
/* Handling the XPAK counters update */
if(nic->mac_control.stats_info->xpak_stat.xpak_timer_count < 72000) {
@@ -4117,6 +4129,10 @@ static irqreturn_t s2io_isr(int irq, voi
struct mac_info *mac_control;
struct config_param *config;
 
+   /* Pretend we handled any irq's from a disconnected card */
+   if (pci_channel_offline(sp->pdev))
+   return IRQ_NONE;
+
atomic_inc(&sp->isr_cnt);
mac_control = &sp->mac_control;
config = &sp->config;
@@ -6188,7 +6204,7 @@ static void s2io_rem_isr(struct s2io_nic
} while(cnt < 5);
 }
 
-static void s2io_card_down(struct s2io_nic * sp)
+static void do_s2io_card_down(struct s2io_nic * sp, int do_io)
 {
int cnt = 0;
struct XENA_dev_config __iomem *bar0 = sp->bar0;
@@ -6203,7 +6219,8 @@ static void s2io_card_down(struct s2io_n
atomic_set(&sp->card_state, CARD_DOWN);
 
/* disable Tx and Rx traffic on the NIC */
-   stop_nic(sp);
+   if (do_io)
+   stop_nic(sp);
 
s2io_rem_isr(sp);
 
@@ -6211,7 +6228,7 @@ static void s2io_card_down(struct s2io_n
tasklet_kill(&sp->task);
 
/* Check if the device is Quiescent and then Reset the NIC */
-   do {
+   while(do_io) {
/* As per the HW requirement we need to replenish the
 * receive buffer to avoid the ring bump. Since there is
 * no intention of processing the Rx frame at this pointwe are
@@ -6236,8 +6253,9 @@ static void s2io_card_down(struct s2io_n
  (unsigned long long) val64);
break;
}
-   } while (1);
-   s2io_reset(sp);
+   }
+   if (do_io)
+   s2io_reset(sp);
 
spin_lock_irqsave(&sp->tx_lock, flags);
/* Free all Tx buffers */
@@ -6252,6 +6270,11 @@ static void s2io_card_down(struct s2io_n
clear_bit(0, &(sp->link_state));
 }
 
+static void s2io_card_down(struct s2io_nic * sp)
+{
+   do_s2io_card_down(sp, 1);
+}
+
 static int s2io_card_up(struct s2io_nic * sp)
 {
int i, ret = 0;
@@ -7536,3 +7559,86 @@ static void lro_append_pkt(struct s2io_n
sp->mac_control.stats_info->sw_stat.clubbed_frms_cnt++;
return;
 }
+
+/**
+ * s2io_io_error_detected - called when PCI error is detected
+ * @pdev: Pointer to PCI device
+ * @state: The current pci conneection state
+ *
+ * This function is called after a PCI bus error affecting
+ * this device has been detected.
+ */
+static pci_ers_result_t s2io_io_error_detected(struct pci_dev *pdev,
+   pci_channel_state_t state)
+{
+   struct net_device *netdev = pci_get_drvdata(pdev);
+

Re: Experimental driver for Ricoh Bay1Controller SD Card readers

2007-02-15 Thread Ivan Babkin

Hi!
> Apart from that I did the following changes:
> - implemented suspend/resume support (not tested very much)
> - named the registers
> - fixed a bug that caused a major slowdown when modprobed without debug=1
> - added writting support (disabled by default, modprobe with write=1)
> Before you enable writting please make sure that you did a proper backup of 
> the data on the card. Do not use this driver to save important data.
Thank for the job you've done!
Your driver works with 1 Gb sd-card (x86_64 suse's 2.16.18.2 kernel).
Read rate for me was around 250 Kb/s, write - 28 Kb/s (using dd utility).
BTW, I get continuous flow of "sdricoh_cs: timeout waiting for data"
messages in dmesg.

Good luck!
-
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] Optimize generic get_unaligned / put_unaligned implementations.

Ralf Baechle wrote:
> Gcc info page says:
>
> [...]
> `packed'
>  The `packed' attribute specifies that a variable or structure field
>  should have the smallest possible alignment--one byte for a
>  variable, and one bit for a field, unless you specify a larger
>  value with the `aligned' attribute.
> [...]
>
> Qed?

So that the compiler has to assume that if its accessing this __packed
structure, it may be embedded unaligned within something else? And
because the pointer is cast through (void *) it isn't allowed to use
alias analysis to notice that the pointer wasn't originally (apparently)
unaligned.

Seems sound to me.

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/

Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation

2007-02-15 Thread Juan Piernas Canovas


Hi Jörn,

On Thu, 15 Feb 2007, [utf-8] Jörn Engel wrote:


On Thu, 15 February 2007 19:38:14 +0100, Juan Piernas Canovas wrote:


The patch for 2.6.11 is not still stable enough to be released. Be patient
;-)


While I don't want to discourage you, this is about the point in
development where most log structured filesystems stopped.  Doing a
little web research, you will notice those todo-lists with "cleaner"
being the top item for...years!

Getting that one to work robustly is _very_ hard work and just today
I've noticed that mine was not as robust as I would have liked to think.
Also, you may note that by updating to newer kernels, the VM writeout
policies can change and impact your cleaner.  To an extent even that you
had a rock-solid filesystem with 2.6.18 and thing crumble between your
fingers in 2.6.19 or later.

If the latter happens, most likely the VM is not to blame, it just
proved that your cleaner is still getting some corner-cases wrong and
needs more work.  There goes another week of debugging. :(

Jörn

Actually, the version of DualFS for Linux 2.4.19 implements a cleaner. In 
our case, the cleaner is not really a problem because there is not too 
much to clean (the meta-data device only contains meta-data blocks which 
are 5-6% of the file system blocks; you do not have to move data blocks).


Anyway, thank you for warning me ;-)

Regards,

Juan.

--
D. Juan Piernas Cánovas
Departamento de Ingeniería y Tecnología de Computadores
Facultad de Informática. Universidad de Murcia
Campus de Espinardo - 30080 Murcia (SPAIN)
Tel.: +34968367657Fax: +34968364151
email: [EMAIL PROTECTED]
PGP public key:
http://pgp.rediris.es:11371/pks/lookup?search=piernas%40ditec.um.es&op=index

*** Por favor, envíeme sus documentos en formato texto, HTML, PDF o PostScript 
:-) ***

Re: e1000_intr in request_irq faults in 2.6.20-git

2007-02-15 Thread Eric W. Biederman

Len Brown <[EMAIL PROTECTED]> writes:

> e1000 faults in 2.6.20-git, while 2.6.20 worked fine.
>
> System is a D875PBZ with LOM.
>
> clues?

I'm guessing this is an old bug found by the following bit of
debug coded added into since v2.6.20

+#ifdef CONFIG_DEBUG_SHIRQ
+   if (irqflags & IRQF_SHARED) {
+   /*
+* It's a shared IRQ -- the driver ought to be prepared for it
+* to happen immediately, so let's make sure
+* We do this before actually registering it, to make sure that
+* a 'real' IRQ doesn't run in parallel with our fake
+*/
+   if (irqflags & IRQF_DISABLED) {
+   unsigned long flags;
+
+   local_irq_save(flags);
+   handler(irq, dev_id);
+   local_irq_restore(flags);
+   } else
+   handler(irq, dev_id);
+   }
+#endif

I don't have a clue why the e1000 wasn't ready though.

Eric


>
> Bringing up loopback interface:  [  OK  ]
> Bringing up interface eth0: BUG: unable to handle kernel NULL pointer
> dereference at virtual address 
>  printing eip:
> *pde = 3747c001
> Oops:  [#1]
> SMP
> Modules linked in: dm_mod video thermal sbs i2c_ec fan button dock battery
> asus_acpi ac lp intel_agp agpgart ehci_hcd parport_serial parpt
> CPU:0
> EIP:0060:[<>]Not tainted VLI
> EFLAGS: 00010246   (2.6.20-g724339d7 #32)
> EIP is at _stext+0x3fefed10/0x14
> eax: c21cd3a0   ebx: f884   ecx:    edx: c22d2e44
> esi: c21cd3a0   edi:    ebp: c21cd564   esp: f755de6c
> ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> Process ip (pid: 2975, ti=f755d000 task=f75590b0 task.ti=f755d000)
> Stack: c02a2077 fff4 f7987404  c02a1fc3 c0140cb5 0010 012321b4
>c21cd3a0 c21cd000 c21cd000  c02a1a71 c21cd000 c21cd000 c21cd3a0
> c21cd3a0  c02a4916 c21cd000 1003 1002 c03b3751
> Call Trace:
>  [] e1000_intr+0xb4/0x107
>  [] e1000_intr+0x0/0x107
>  [] request_irq+0xa5/0xcc
>  [] e1000_request_irq+0xad/0xe6
>  [] e1000_open+0x43/0xbd
>  [] dev_open+0x2b/0x62
>  [] dev_change_flags+0x47/0xe4
>  [] devinet_ioctl+0x250/0x56d
>  [] dev_ifsioc+0x113/0x38d
>  [] copy_to_user+0x2d/0x43
>  [] sock_ioctl+0x19f/0x1be
>  [] sock_ioctl+0x0/0x1be
>  [] do_ioctl+0x1f/0x62
>  [] vfs_ioctl+0x244/0x256
>  [] sys_ioctl+0x33/0x4c
>  [] sysenter_past_esp+0x5d/0x81
>  ===
> Code:  Bad EIP value.
> EIP: [<>] _stext+0x3fefed10/0x14 SS:ESP 0068:f755de6c
> /etc/sysconfig/network-scripts/ifup-eth: line 272: 2975 Segmentation fault ip
> link set dev ${REALDEVICE} up
> Failed to bring up eth0.
> [FAILED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] s3c2410fb: fix un-initialised dev field

2007-02-15 Thread Ben Dooks

The current driver is not setting the dev
field in the private data structure, which
can lead to an OOPS if the driver tries to
report an error.

Signed-off-by: Ben Dooks <[EMAIL PROTECTED]>

--- linux-2.6.20/drivers/video/s3c2410fb.c  2007-02-04 18:44:54.0 
+
+++ linux-2.6.20-fbfix1/drivers/video/s3c2410fb.c   2007-02-15 
22:42:51.0 +
@@ -791,6 +791,8 @@ static int __init s3c2410fb_probe(struct
 
info = fbinfo->par;
info->fb = fbinfo;
+   info->dev = &pdev->dev;
+
platform_set_drvdata(pdev, fbinfo);
 
dprintk("devinit\n");
-
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: sparse chokes on arch/i386/kernel/i8253.c (was: 2.6.20-mm1)