twitter: linux.kernel - 26 new messages in 13 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* perf/sched: fix for getting task's execute time - 4 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/feeb303886efcf24?hl=en
* Unable to use tools/perf sched and timechart correctly - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/9da002544ae8f440?hl=en
* cfq-iosched: reduce write depth only if sync was delayed - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/85566d72f71c5737?hl=en
* What are the goals for the architecture of an in-kernel IR system? - 6
messages, 2 authors
http://groups.google.com/group/linux.kernel/t/344640f275ed964e?hl=en
* x86: compile insn.c and inat.c only for KPROBES - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/33195fd4368c9e29?hl=en
* Doc/stable rules: add new cherry-pick logic - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/38affbffd70e3dd6?hl=en
* Kexec failure on RDC (and possibly other early x86) platforms - 1 messages,
1 author
http://groups.google.com/group/linux.kernel/t/0cc43ea4d8671159?hl=en
* debugging oops after disconnecting Nexio USB touchscreen - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/c35c48be1263c44d?hl=en
* doc/powerpc: try to explain why the interrupt numbers are off by 16 - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/00838c5cbf3ba24e?hl=en
* perf: misc small fixes - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/63332dffdd2fd770?hl=en
* perf: Fix timechart header handling - 6 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/a6009ad0de65646b?hl=en
* scripts/checkpatch.pl: Add warning about leading contination tests - 1
messages, 1 author
http://groups.google.com/group/linux.kernel/t/af76e05f2c3e7b05?hl=en
* acerhdf: BIOS product mismatch due to whitespace - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/ae6d4cac1682e8ed?hl=en

==============================================================================
TOPIC: perf/sched: fix for getting task's execute time
http://groups.google.com/group/linux.kernel/t/feeb303886efcf24?hl=en
==============================================================================

== 1 of 4 ==
Date: Sun, Dec 6 2009 3:00 am
From: Xiao Guangrong

In current code, we get task's execute time by reading
"/proc/<pid>/sched" file, it's wrong if the task is created
by pthread_create(), because every thread task has same pid.
So, the correct way is reading "/proc/<ppid>/task/<tid>/sched"
file.

This patch also remove redundant include files since <sys/types.h>
is included in "perf.h"

Signed-off-by: Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
---
tools/perf/builtin-sched.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index 26b782f..b2e910e 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -13,7 +13,6 @@
#include "util/debug.h"
#include "util/data_map.h"

-#include <sys/types.h>
#include <sys/prctl.h>

#include <semaphore.h>
@@ -416,7 +415,7 @@ static u64 get_cpu_usage_nsec_parent(void)

static u64 get_cpu_usage_nsec_self(void)
{
- char filename [] = "/proc/1234567890/sched";
+ char filename [] = "/proc/1234567890/task/1234567890/sched";
unsigned long msecs, nsecs;
char *line = NULL;
u64 total = 0;
@@ -425,7 +424,9 @@ static u64 get_cpu_usage_nsec_self(void)
FILE *file;
int ret;

- sprintf(filename, "/proc/%d/sched", getpid());
+ sprintf(filename, "/proc/%d/task/%d/sched", getpid(),
+ (pid_t)syscall(SYS_gettid));
+
file = fopen(filename, "r");
BUG_ON(!file);

--
1.6.1.2

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

== 2 of 4 ==
Date: Sun, Dec 6 2009 3:10 am
From: Peter Zijlstra

On Sun, 2009-12-06 at 12:05 +0100, Peter Zijlstra wrote:
> On Sun, 2009-12-06 at 18:57 +0800, Xiao Guangrong wrote:
> > In current code, we get task's execute time by reading
> > "/proc/<pid>/sched" file, it's wrong if the task is created
> > by pthread_create(), because every thread task has same pid.
> > So, the correct way is reading "/proc/<ppid>/task/<tid>/sched"
> > file.
> >
> > This patch also remove redundant include files since <sys/types.h>
> > is included in "perf.h"
>
> We really should not be using these proc files but instead make sure
> this information gets transferred through a tracepoint or similar.
>
> Reading these proc files is too prone to races.

We can probably get the runtime by grouping a task-clock swcounter with
an appropriate other event.

== 3 of 4 ==
Date: Sun, Dec 6 2009 3:10 am
From: Peter Zijlstra

On Sun, 2009-12-06 at 18:57 +0800, Xiao Guangrong wrote:
> In current code, we get task's execute time by reading
> "/proc/<pid>/sched" file, it's wrong if the task is created
> by pthread_create(), because every thread task has same pid.
> So, the correct way is reading "/proc/<ppid>/task/<tid>/sched"
> file.
>
> This patch also remove redundant include files since <sys/types.h>
> is included in "perf.h"

We really should not be using these proc files but instead make sure
this information gets transferred through a tracepoint or similar.

Reading these proc files is too prone to races.

== 4 of 4 ==
Date: Sun, Dec 6 2009 4:00 am
From: Ingo Molnar

* Peter Zijlstra <peterz@infradead.org> wrote:

> On Sun, 2009-12-06 at 12:05 +0100, Peter Zijlstra wrote:
> > On Sun, 2009-12-06 at 18:57 +0800, Xiao Guangrong wrote:
> > > In current code, we get task's execute time by reading
> > > "/proc/<pid>/sched" file, it's wrong if the task is created
> > > by pthread_create(), because every thread task has same pid.
> > > So, the correct way is reading "/proc/<ppid>/task/<tid>/sched"
> > > file.
> > >
> > > This patch also remove redundant include files since <sys/types.h>
> > > is included in "perf.h"
> >
> > We really should not be using these proc files but instead make sure
> > this information gets transferred through a tracepoint or similar.
> >
> > Reading these proc files is too prone to races.

yeah. Ideally we'd want all valuable information that is available via
/proc to be available via perf events as well. In the future it should
be possible to run perf even without /proc mounted for example.

Furthermore it's good for consistency and simplicity as well, plus it's
faster too to get the information from the perf syscall and mmap-ed
ringbuffer than to read things via /proc. No need for ASCII conversion,
fixed record formats, fast streaming and buffering, no read() overhead,
etc.

> We can probably get the runtime by grouping a task-clock swcounter
> with an appropriate other event.

Would be lovely.

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

==============================================================================
TOPIC: Unable to use tools/perf sched and timechart correctly
http://groups.google.com/group/linux.kernel/t/9da002544ae8f440?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 6 2009 3:00 am
From: Peter Zijlstra

On Sun, 2009-12-06 at 18:41 +0800, Xiao Guangrong wrote:

> You should enable "CONFIG_SCHED_DEBUG", because we use
> "/proc/<pid>/sched" file to get the task's cpu usage.
>
> Ingo, I think we do better show the reason about this error,
> just like:
>
> ---
> tools/perf/builtin-sched.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
> index 26b782f..f823631 100644
> --- a/tools/perf/builtin-sched.c
> +++ b/tools/perf/builtin-sched.c
> @@ -427,7 +427,11 @@ static u64 get_cpu_usage_nsec_self(void)
>
> sprintf(filename, "/proc/%d/sched", getpid());
> file = fopen(filename, "r");
> - BUG_ON(!file);
> + if (!file)
> + {
> + printf("You should compile your kernel with CONFIG_SCHED_DEBUG option\n");
> + BUG_ON(1);
> + }
>
> while ((chars = getline(&line, &len, file)) != -1) {
> ret = sscanf(line, "se.sum_exec_runtime : %ld.%06ld\n",

Hrmm, we shouldn't be using a proc file at all, the best solution is to
remove this dependency.

==============================================================================
TOPIC: cfq-iosched: reduce write depth only if sync was delayed
http://groups.google.com/group/linux.kernel/t/85566d72f71c5737?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 6 2009 3:00 am
From: Jens Axboe

On Sun, Dec 06 2009, Corrado Zoccolo wrote:
> Hi Jeff,
> I remember you saw large performance drop on your SAN for sequential
> writes with low_latency=1. Can you test if Shaohua's and this patch
> fix allow to recover some bandwidth? I think that enabling the queue
> depth ramp up only if a sync request was delayed should disable it for
> fast hardware like yours, so you should not be seeing the slowdown any
> more.

I queued this up for post inclusion into 2.6.33, with the time_after()
fixed.

The patch was word-wrapped, btw.

--
Jens Axboe

==============================================================================
TOPIC: What are the goals for the architecture of an in-kernel IR system?
http://groups.google.com/group/linux.kernel/t/344640f275ed964e?hl=en
==============================================================================

== 1 of 6 ==
Date: Sun, Dec 6 2009 3:10 am
From: Mauro Carvalho Chehab

Dmitry Torokhov wrote:
> On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
>> Em Fri, 4 Dec 2009 02:06:42 -0800
>> Dmitry Torokhov <dmitry.torokhov@gmail.com> escreveu:
>>
>>> evdev does not really care what you use as scancode. So nobody stops
>>> your driver to report index as a scancode and accept index from the
>>> ioctl. The true "scancode" will thus be competely hidden from userspace.
>>> In fact a few drivers do just that.
>> Let me better express here. It is all about how we'll expand the limits of those
>> ioctls to fulfill the needs.
>>
>> The point is that we'll have, let's say something like to 50-500 scancode/keycode tuples
>> sparsely spread into a 2^64 scancode universe (assuming 64 bits - Not sure if is there any
>> IR protocol/code with a bigger scancode).
>>
>> On such universe if we want to get all keycodes with the current ioctls for a scancode in
>> the range of 32 bits, we need to do something like:
>>
>> u32 code;
>> int codes[2];
>> for (code = 0; code <= (unsigned u32) - 1; code++) {
>> codes[0] = (int)code;
>> if (!ioctl(fd, EVIOCGKEYCODE, codes))
>> printf("scancode 0x%08x = keycode 0x%08x\n", codes[0], codes[1]);
>> }
>>
>> So, on the 32 bits case, we'll do about 4 billions calls to EVIOGKEYCODE ioctl to
>> read the complete scancode space, to get those 50-500 useful codes.
>>
>
> Right, currently there is no need to query all scancodes defined by
> device. Quite often drivers don't even know what scancodes device
> actually generates (ex AT keyboard).
>
> Could you describe in more detail how you are using this data?

It is useful if you want to dump the keycode maps into file with the current
scancode attribution, in order to modify some keystrokes.

Right now, programs like dumpkeys (from kbd package) allow you to dump for example
the attribution keys from your keyboard.

In the case of IR's this functionality is very important.

For example, you may need to replace the scancode/KEY_CHANNELUP tuple by scancode/KEY_UP,
in order to make your IR to work with some applications that don't recognize the IR
specific keycodes.

In practice, with such applications, you'll need to replace several different scancodes.

So, you may end by having different scancodes producing the same keycode, as such applications
aren't capable of differentiating an UP key from a CHANNELUP key. This is the case, for example
of the popular tvtime application.

The better way is to just generate a dump file, modify the needed entries and reload the
table by calling EVIOSKEYCODE, in order to use the new table.

I wrote a small application that just do the above, and I use to load some special tables
to work with some applications like tvtime and mplayer. (with mplayer, you need to map
<channel down> as KEY_H and <channel up> as KEY_K).

I hope that, after we finish addressing IR's, we'll finally have media applications handling
directly the proper keycodes, but people may still need to write different keycodes to do
other things. I used to have a keymap file in order to use an IR to control the slide show
with openoffice.

>> Due to the current API limit, we don't have any way to use the full 64bits space for scancodes.
>>
>
> Can we probably reduce the "scancode" space? ARe all 64 bits in
> protocols used to represent keypresses or some are used for some kind of
> addressing?

All the IR's I found with V4L/DVB use up to 16 bits code (or 24 bits, for NEC extended protocol).
However, currently, the drivers were getting only 7 bits, due to the old way to implement
EVIO[S|G]KEYCODE.

I know, however, one i2c chip that returns a 5 byte scancode when you press a key.
We're currently just discarding the remaining bits, so I'm not really sure what's there.

The usage of 7 bits, in practice, were meaning that it weren't possible to use
a different remote than the one provided by the device manufacturer, as the scancodes produced
by other remotes differ on more than 7 bits. Also, this means that, if your TV and your PC
are using the same protocol, like RC5, if you press a button on your TV remote, the PC will
also get it.

I know, however, one IR driver that produces 6 bytes when you press a key.
We're currently just discarding the remaining bits, so I'm not really sure
what else is there. Some badly optimized protocol? a bigger scancode? a protocol indication?

In general, the scancode contains 8 or 16 bits for address, and 8 bits for command.

However, the scancode table needs to handle the address as well, since we don't want that a
scancode meant to go to your TV to be handled by the PC, but we may want to get codes from
different addresses there, as we may need to use the address to differentiate the commands
meant to control the TV volume, for example, than the same command meant to control the PC
master volume.

>> if we use code[0] as an index, this means that we'll need to share the 32 bits on code[1]
>> for scancode/keycode. Even using an 32 bits integer for keycode, it is currently limited to:
>>
>> #define KEY_MAX 0x2ff
>> #define KEY_CNT (KEY_MAX+1)
>>
>> So, we have 10 bits already used for keycode. This gives only 22 bits for scancodes, if we share
>> codes[1] for both keycode/scancode. By sharing the 32 bits, we'll need to be care to not extend
>> KEY_MAX to be bigger than 0x3ff, otherwise the keytable won't be able to represent all keys of the
>> key universe.
>>
>> What is need for this case is that the arguments for get key/set key to be something like:
>>
>> struct {
>> u16 index;
>> u64 scancode;
>> u32 keycode;
>> };
>>
>
> Hmm, so what is this index? I am confused...

It is the sequence number of a scancode/keycode tuple stored at the keycode table.

Better than saying it in words, let me put a code snippet:

at include/linux/input.h, we'll add a code like:

struct input_keytable_entry {
u16 index;
u64 scancode;
u32 keycode;
} __attribute__ ((packed));

(the attribute packed avoids needing a compat for 64 bits)

#define EVIOGKEYCODEENTRY _IOR('E', 0x85, struct input_keytable_entry)

(and a similar ioctl for setkeycode)

This struct will be used by the new

at include/media/ir-common.h, we already have:

struct ir_scancode {
u16 scancode;
u32 keycode;
};

struct ir_scancode_table {
struct ir_scancode *scan;
int size;
...
};

The code at ir core that will handle the ioctl will be like:

static int ir_getkeycode_entry(struct input_dev *dev, struct input_keytable_entry *ike)
{
struct ir_scancode_table *rc_tab = input_get_drvdata(dev);

if (rc_tab->size >= ike->index)
return -EINVAL;

irk->scancode = rctab->scan->scancode;
irk->keycode = rctab->scan->keycode;

return 0;
}

---

As a reference, we currently implement the getkeycode at ir-keytable.c as:

static int ir_getkeycode(struct input_dev *dev,
int scancode, int *keycode)
{
int elem;
struct ir_scancode_table *rc_tab = input_get_drvdata(dev);

elem = ir_seek_table(rc_tab, scancode);
if (elem >= 0) {
*keycode = rc_tab->scan[elem].keycode;
return 0;
}

/*
* Scancode not found and table can't be expanded
*/
if (elem < 0 && rc_tab->size == IR_TAB_MAX_SIZE)
return -EINVAL;

/*
* If is there extra space, returns KEY_RESERVED,
* otherwise, input core won't let ir_setkeycode to work
*/
*keycode = KEY_RESERVED;
return 0;
}

where ir_seek_table is a function that checks returns the entry
that corresponds to the given scancode.

By using an index, both userspace and kernelspace code will be simpler
and fast enough to work even with the biggest scancode.

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

== 2 of 6 ==
Date: Sun, Dec 6 2009 3:30 am
From: Mauro Carvalho Chehab

Dmitry Torokhov wrote:
> On Fri, Dec 04, 2009 at 12:12:34PM -0200, Mauro Carvalho Chehab wrote:
>>> How related lirc-core to the current lirc code? If it is not the same
>>> maybe we should not call it lirc to avoid confusion.
>> Just for better illustrate what I'm seeing, I broke the IR generic
>> code into two components:
>>
>> lirc core - the module that receives raw pulse/space and creates
>> a device to receive raw API pulse/space events;
>>
>> IR core - the module that receives scancodes, convert them into
>> keycodes and send via evdev interface.
>>
>> We may change latter the nomenclature, but I'm seeing the core as two different
>> modules, since there are cases where lirc core won't be used (those
>> devices were there's no way to get pulse/space events).
>>
>
> OK, I think we are close but not exactly close. I believe that what you
> call lirc core will be used always - it is the code that create3s class
> devices, connectes decorers with the data streams, etc. I believe it
> will be utilized even in case of devices using hardware decoders. That
> is why we should probably stop calling it "lirc core" just tso we don't
> confuse it with original lirc.
>
> Then we have decoders and lirc_dev - which implements original lirc
> interface (or maybe its modified version) and allows lircd to continue
> working.
>
> Lastly we have what you call IR core which is IR-to-input bridge of
> sorts.

It seems to be just nomenclacure ;)

what I called "IR core" you called "lirc core"
what I called "lirc core" you called "lirc_dev"

What I called IR core is the one that will be used by every IR driver, handling
sysfs, evdev's, calling decoders, etc.

I opted to use the nomenclature Lirc to the part of the IR subsystem that
will create the Lirc interface.

Currently, I almost finished the evdev part of the "IR core", using the current
API to control the dynamic keycode allocation. It is already working fine with
V4L drivers.

== 3 of 6 ==
Date: Sun, Dec 6 2009 3:50 am
From: Mauro Carvalho Chehab

Dmitry Torokhov wrote:
> Hi,
>
> On Sun, Dec 06, 2009 at 04:36:33AM +0100, hermann pitton wrote:
>> Hi,
>>
>> Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl:
>>> On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus <lirc@bartelmus.de> wrote:
>>>> BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
>>>> codes. Anyone here has docs on the XMP protocol?
>>> Assuming a general purpose receiver (not one with fixed hardware
>>> decoding), is it important for Linux to receive IR signals from all
>>> possible remotes no matter how old or obscure? Or is it acceptable to
>>> tell the user to throw away their dedicated remote and buy a universal
>>> multi-function one? Universal multi-function remotes are $12 in my
>>> grocery store - I don't even have to go to an electronics store.
>> finally we have some point here, IMHO, that is not acceptable and I told
>> you previously not to bet on such. Start some poll and win it, and I'll
>> shut up :)
>>
>
> Who would participate in the poll though?
>
>> To be frank, you are quite mad at this point, or deliver working other
>> remotes to __all__ for free.
>>
>
> I do not believe you are being realistic. Sometimes we just need to say
> that the device is a POS and is just not worth it. Remember, there is
> still "lirc hole" for the hard core people still using solder to produce
> something out of the spare electronic components that may be made to
> work (never mind that it causes the CPU constantly poll the device, not
> letting it sleep and wasting electricity as a result - just hypotetical
> example here).
>
> We still need to do cost-benefit analysis and decide whether supporting
> the exotic setups _in kernel_ makes sense if it encumbers implementation
> and causes issues to the other 95% people.

Fully agreed. The costs (our time) to add and keep supporting an in-kernel
driver for an IR that just one person is still using is higher than
asking the user to get a new IR. This time would be better spent adding a new
driver for other devices.

Cheers,
Mauro.

== 4 of 6 ==
Date: Sun, Dec 6 2009 4:10 am
From: lirc@bartelmus.de (Christoph Bartelmus)

Hi Dmitry,

on 04 Dec 09 at 15:15, Dmitry Torokhov wrote:
[...]
>>>>>> http://lirc.sourceforge.net/remotes/lg/6711A20015N
>>>>>>
>>>>>> This is an air-conditioner remote.
>>>>>> The entries that you see in this config file are not really separate
>>>>>> buttons. Instead the remote just sends the current settings for e.g.
>>>>>> temperature encoded in the protocol when you press some up/down key.
>>>>>> You really don't want to map all possible temperature settings to KEY_*
>>>>>> events. For such cases it would be nice to have access at the raw scan
>>>>>> codes from user space to do interpretation of the data.
>>>>>> The default would still be to pass the data to the input layer, but it
>>>>>> won't hurt to have the possibility to access the raw data somehow.
>>>>
>>>>> Interesting. IMHO, the better would be to add an evdev ioctl to return
>>>>> the scancode for such cases, instead of returning the keycode.
>>>>
>>>> That means you would have to set up a pseudo keymap, so that you can get
>>>> the key event which you could than react on with a ioctl. Or are you
>>>> generating KEY_UNKNOWN for every scancode that is not mapped?
>>>> What if different scan codes are mapped to the same key event? How do you
>>>> retrieve the scan code for the key event?
>>>> I don't think it can work this way.
>>>>
>>
>>> EV_MSC/MSC_SCAN.
>>
>> How would I get the 64 bit scan codes that the iMON devices generate?
>> How would I know that the scan code is 64 bit?
>> input_event.value is __s32.
>>

> I suppose we could add MSC_SCAN_END event so that we can transmit
> "scancodes" of arbitrary length. You'd get several MSC_SCAN followed by
> MSC_SCAN_END marker. If you don't get MSC_SCAN_END assume the code is 32
> bit.

And I set a timeout to know that no MSC_SCAN_END will arrive? This is
broken design IMHO.

Furthermore lircd needs to know the length of the scan code in bits, not
as a multiple of 32.

> FWIW there is MSC_RAW as well.

It took me some time to convice people that this is not the right way to
handle raw timing data.

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

== 5 of 6 ==
Date: Sun, Dec 6 2009 4:10 am
From: lirc@bartelmus.de (Christoph Bartelmus)

Hi Dmitry,

on 05 Dec 09 at 22:55, Dmitry Torokhov wrote:
[...]
> I do not believe you are being realistic. Sometimes we just need to say
> that the device is a POS and is just not worth it. Remember, there is
> still "lirc hole" for the hard core people still using solder to produce
> something out of the spare electronic components that may be made to
> work (never mind that it causes the CPU constantly poll the device, not
> letting it sleep and wasting electricity as a result - just hypotetical
> example here).

The still seems to be is a persistent misconception that the home-brewn
receivers need polling or cause heavy CPU load. No they don't. All of them
are IRQ based.
It's the commercial solutions like gpio based IR that need polling.
For transmitters it's a different story, but you don't transmit 24h/7.

== 6 of 6 ==
Date: Sun, Dec 6 2009 4:20 am
From: lirc@bartelmus.de (Christoph Bartelmus)

Hi Jon,

on 04 Dec 09 at 19:28, Jon Smirl wrote:
>> BTW, I just came across a XMP remote that seems to generate 3x64 bit
>> scan codes. Anyone here has docs on the XMP protocol?
>
> Assuming a general purpose receiver (not one with fixed hardware
> decoding), is it important for Linux to receive IR signals from all
> possible remotes no matter how old or obscure? Or is it acceptable to
[...]
> Of course transmitting is a completely different problem, but we
> haven't been talking about transmitting. I can see how we would need
> to record any IR protocol in order to retransmit it. But that's in the
> 5% of users world, not the 90% that want MythTV to "just work". Use
> something like LIRC if you want to transmit.

I don't think anyone here is in the position to be able to tell what is
90% or 5%. Personally I use LIRC exclusively for transmit to my settop box
using an old and obscure RECS80 protocol.
No, I won't replace my setup just because it's old and obscure.

Cable companies tend to provide XMP based boxes to subscribers more often
these days. Simply not supporting these setups is a no-go for me.

==============================================================================
TOPIC: x86: compile insn.c and inat.c only for KPROBES
http://groups.google.com/group/linux.kernel/t/33195fd4368c9e29?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 6 2009 3:20 am
From: OGAWA Hirofumi

At least, insn.c and inat.c is needed for kprobe for now. So, this
compile those only if KPROBES is enabled.

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

arch/x86/Kconfig.debug | 4 ++--
arch/x86/lib/Makefile | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)

diff -L arch/x86/lib/Kconfig -puN /dev/null /dev/null
diff -puN arch/x86/lib/Makefile~kconfig-decoder-only-for-kprobe arch/x86/lib/Makefile
--- linux-2.6/arch/x86/lib/Makefile~kconfig-decoder-only-for-kprobe 2009-12-06 19:49:06.000000000 +0900
+++ linux-2.6-hirofumi/arch/x86/lib/Makefile 2009-12-06 19:49:06.000000000 +0900
@@ -20,7 +20,7 @@ lib-y := delay.o
lib-y += thunk_$(BITS).o
lib-y += usercopy_$(BITS).o getuser.o putuser.o
lib-y += memcpy_$(BITS).o
-lib-y += insn.o inat.o
+lib-$(CONFIG_KPROBES) += insn.o inat.o

obj-y += msr-reg.o msr-reg-export.o

diff -puN arch/x86/Kconfig.debug~kconfig-decoder-only-for-kprobe arch/x86/Kconfig.debug
--- linux-2.6/arch/x86/Kconfig.debug~kconfig-decoder-only-for-kprobe 2009-12-06 19:49:06.000000000 +0900
+++ linux-2.6-hirofumi/arch/x86/Kconfig.debug 2009-12-06 19:49:06.000000000 +0900
@@ -187,8 +187,8 @@ config HAVE_MMIOTRACE_SUPPORT
def_bool y

config X86_DECODER_SELFTEST
- bool "x86 instruction decoder selftest"
- depends on DEBUG_KERNEL
+ bool "x86 instruction decoder selftest"
+ depends on DEBUG_KERNEL && KPROBES
---help---
Perform x86 instruction decoder selftests at build time.
This option is useful for checking the sanity of x86 instruction
_

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

==============================================================================
TOPIC: Doc/stable rules: add new cherry-pick logic
http://groups.google.com/group/linux.kernel/t/38affbffd70e3dd6?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 6 2009 3:30 am
From: Sebastian Andrzej Siewior

- it is possible to submit patches for the stable queue without sending
them directly stable@kernel.org. If the tag (Cc: stable@kernel.org) is
available in the sign-off area than hpa's script will filter them into
the stable mailbox once it hits Linus' tree.
- Patches which require others to be applied first can be also specified.
This was discussued in http://lkml.org/lkml/2009/11/9/474

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
---
Documentation/stable_kernel_rules.txt | 24 +++++++++++++++++++++---
1 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index a452227..bc52bbb 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -25,14 +25,32 @@ Rules on what kind of patches are accepted, and which ones are not, into the
Procedure for submitting patches to the -stable tree:

- Send the patch, after verifying that it follows the above rules, to
- stable@kernel.org.
+ stable@kernel.org. An alternative is to have the tag
+ Cc: stable@kernel.org
+ in the sign-off area. Once the patch is merged it will be filtered
+ into the stable tree even without sending directly to
+ stable@kernel.org
+ - If the patch requires other patches as prerequisites which can be
+ cherry-picked than this can be specified in the following format in
+ the sign-off area:
+
+ Cc: <stable@kernel.org> # .32.x: a1f84a3: sched: Check for an idle shared cache
+ Cc: <stable@kernel.org> # .32.x: 1b9508f: sched: Rate-limit newidle
+ Cc: <stable@kernel.org> # .32.x: fd21073: sched: Fix affinity logic
+ Cc: <stable@kernel.org> # .32.x
+ Signed-off-by: Ingo Molnar <mingo@elte.hu>
+
+ The tag sequence has the meaning of:
+ git cherry-pick a1f84a3
+ git cherry-pick 1b9508f
+ git cherry-pick fd21073
+ git cherry-pick <this commit>
+
- The sender will receive an ACK when the patch has been accepted into the
queue, or a NAK if the patch is rejected. This response might take a few
days, according to the developer's schedules.
- If accepted, the patch will be added to the -stable queue, for review by
other developers and by the relevant subsystem maintainer.
- - If the stable@kernel.org address is added to a patch, when it goes into
- Linus's tree it will automatically be emailed to the stable team.
- Security patches should not be sent to this alias, but instead to the
documented security@kernel.org address.

--
1.6.5.2

==============================================================================
TOPIC: Kexec failure on RDC (and possibly other early x86) platforms
http://groups.google.com/group/linux.kernel/t/0cc43ea4d8671159?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 6 2009 3:40 am
From: bifferos

I've updated the patch to allow Kexec to work on RDC platforms
here:
http://bifferboard.svn.sourceforge.net/viewvc/bifferboard/slack/kernel/2.6.32/0003-kexec-fix.patch

I'm curious as to how one can detect the presence of the CR4
register in assembler, as I'm sure it's possible, but I've just
#ifndefed out the offending instruction in this patch and it
seems to work with this change.

regards,
Biff.

==============================================================================
TOPIC: debugging oops after disconnecting Nexio USB touchscreen
http://groups.google.com/group/linux.kernel/t/c35c48be1263c44d?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 6 2009 3:40 am
From: Andreas Mohr

Hi,

On Sat, Dec 05, 2009 at 12:16:13PM -0500, Alan Stern wrote:
> On Sat, 5 Dec 2009, Andreas Mohr wrote:
>
> > Hi,
> >
> > > Furthermore, the patch shows that the second-to-last argument to
> > > usb_fill_bulk_urb() -- the completion function -- is NULL. That is
> > > strictly illegal and it should have caused an oops as soon as the URB
> > > was used.
> >
> > Then there's definitely a WARN_ON or so missing in
> > static inline void usb_fill_bulk_urb()
>
> No there isn't. That inline just fills in a bunch of fields.

After the fact I've been thinking that yes, such an inline helper
isn't really an appropriate location.

> > And highly likely more checks in those areas that are causing my (and
> > other people's) ftdi_sio tests and USB audio (MIPS mmap) to fail.
> > Followup soon.
>
> Sometimes having too many checks is worse than having too few,
> especially if the failure modes are relatively easy to handle.

True, many checks in all sorts of user places instead of the one core
place where it matters can clutter things. Especially since the WARN_ON
checks are unconditional, not a debug-only setting.

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

==============================================================================
TOPIC: doc/powerpc: try to explain why the interrupt numbers are off by 16
http://groups.google.com/group/linux.kernel/t/00838c5cbf3ba24e?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 6 2009 3:40 am
From: Sebastian Andrzej Siewior

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
---
Documentation/powerpc/dts-bindings/fsl/mpic.txt | 42 +++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpic.txt

diff --git a/Documentation/powerpc/dts-bindings/fsl/mpic.txt b/Documentation/powerpc/dts-bindings/fsl/mpic.txt
new file mode 100644
index 0000000..71e39cf
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/mpic.txt
@@ -0,0 +1,42 @@
+* OpenPIC and its interrupt numbers on Freescale's e500/e600 cores
+
+The OpenPIC specification does not specify which interrupt source has to
+become which interrupt number. This is up to the software implementation
+of the interrupt controller. The only requirement is that every
+interrupt source has to have an unique interrupt number / vector number.
+To accomplish this the current implementation assigns the number zero to
+the first source, the number one to the second source and so on until
+all interrupt sources have their unique number.
+Usually the assigned vector number equals the interrupt number mentioned
+in the documentation for a given core / CPU. This is however not true
+for the e500 cores (MPC85XX CPUs) where the documentation distinguishes
+between internal and external interrupt sources and starts counting at
+zero for both of them.
+
+So what to write for external interrupt source X or internal interrupt
+source Y into the device tree? Here is an example:
+
+The memory map for the interrupt controller in the MPC8544[0] shows,
+that the first interrupt source starts at 0x5_0000 (PIC Register Address
+Map-Interrupt Source Configuration Registers). This source becomes the
+number zero therefore:
+ External interrupt 0 = interrupt number 0
+ External interrupt 1 = interrupt number 1
+ External interrupt 2 = interrupt number 2
+ ...
+Every interrupt number allocates 0x20 bytes register space. So to get
+its number it is sufficient to shift the lower 16bits to right by five.
+So for the external interrupt 10 we have:
+ 0x0140 >> 5 = 10
+
+After the external sources, the internal sources follow. The in core I2C
+controller on the MPC8544 for instance has the internal source number
+27. Oo obtain its interrupt number we take the lower 16bits of its memory
+address (0x5_0560) and shift it right:
+ 0x0560 >> 5 = 43
+
+Therefore the I2C device node for the MPC8544 CPU has to have the
+interrupt number 43 specified in the device tree.
+
+[0] MPC8544E PowerQUICCTM III, Integrated Host Processor Family Reference Manual
+ MPC8544ERM Rev. 1 10/2007
--
1.6.5.3

==============================================================================
TOPIC: perf: misc small fixes
http://groups.google.com/group/linux.kernel/t/63332dffdd2fd770?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Dec 6 2009 3:50 am
From: OGAWA Hirofumi

[Those was checked by valgrind, but not fixed all errors by lazyness. Sorry]

- util/parse-event.c
"path" is pointer. It should be sizeof(*path)

- util/header.c
"len" is aligned to 64. So, it tries to write the out of
long_name buffer.

So, this use "zero_buf" to write aligned area.

- util/trace-event-read.c
"size" is not including nul byte. So, this allocates it, and set '\0'.

- util/trace-event-parse.c
It needs parens to calc correct size.

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

tools/perf/util/header.c | 9 +++++++--
tools/perf/util/parse-events.c | 2 +-
tools/perf/util/trace-event-parse.c | 2 +-
tools/perf/util/trace-event-read.c | 3 ++-
4 files changed, 11 insertions(+), 5 deletions(-)

diff -puN tools/perf/util/parse-events.c~perf-fix-misc tools/perf/util/parse-events.c
--- linux-2.6/tools/perf/util/parse-events.c~perf-fix-misc 2009-12-06 19:42:53.000000000 +0900
+++ linux-2.6-hirofumi/tools/perf/util/parse-events.c 2009-12-06 19:42:53.000000000 +0900
@@ -197,7 +197,7 @@ struct tracepoint_path *tracepoint_id_to
if (id == config) {
closedir(evt_dir);
closedir(sys_dir);
- path = zalloc(sizeof(path));
+ path = zalloc(sizeof(*path));
path->system = malloc(MAX_EVENT_LENGTH);
if (!path->system) {
free(path);
diff -puN tools/perf/util/symbol.c~perf-fix-misc tools/perf/util/symbol.c
diff -puN tools/perf/util/header.c~perf-fix-misc tools/perf/util/header.c
--- linux-2.6/tools/perf/util/header.c~perf-fix-misc 2009-12-06 19:42:53.000000000 +0900
+++ linux-2.6-hirofumi/tools/perf/util/header.c 2009-12-06 19:42:53.000000000 +0900
@@ -187,7 +187,9 @@ static int do_write(int fd, const void *

static int __dsos__write_buildid_table(struct list_head *head, int fd)
{
+#define NAME_ALIGN 64
struct dso *pos;
+ static const char zero_buf[NAME_ALIGN];

list_for_each_entry(pos, head, node) {
int err;
@@ -197,14 +199,17 @@ static int __dsos__write_buildid_table(s
if (!pos->has_build_id)
continue;
len = pos->long_name_len + 1;
- len = ALIGN(len, 64);
+ len = ALIGN(len, NAME_ALIGN);
memset(&b, 0, sizeof(b));
memcpy(&b.build_id, pos->build_id, sizeof(pos->build_id));
b.header.size = sizeof(b) + len;
err = do_write(fd, &b, sizeof(b));
if (err < 0)
return err;
- err = do_write(fd, pos->long_name, len);
+ err = do_write(fd, pos->long_name, pos->long_name_len + 1);
+ if (err < 0)
+ return err;
+ err = do_write(fd, zero_buf, len - pos->long_name_len + 1);
if (err < 0)
return err;
}
diff -puN tools/perf/util/trace-event-read.c~perf-fix-misc tools/perf/util/trace-event-read.c
--- linux-2.6/tools/perf/util/trace-event-read.c~perf-fix-misc 2009-12-06 19:42:53.000000000 +0900
+++ linux-2.6-hirofumi/tools/perf/util/trace-event-read.c 2009-12-06 19:42:53.000000000 +0900
@@ -145,8 +145,9 @@ static void read_proc_kallsyms(void)
if (!size)
return;

- buf = malloc_or_die(size);
+ buf = malloc_or_die(size + 1);
read_or_die(buf, size);
+ buf[size] = '\0';

parse_proc_kallsyms(buf, size);

diff -puN tools/perf/util/trace-event-parse.c~perf-fix-misc tools/perf/util/trace-event-parse.c
--- linux-2.6/tools/perf/util/trace-event-parse.c~perf-fix-misc 2009-12-06 19:42:53.000000000 +0900
+++ linux-2.6-hirofumi/tools/perf/util/trace-event-parse.c 2009-12-06 19:42:53.000000000 +0900
@@ -177,7 +177,7 @@ void parse_proc_kallsyms(char *file, uns
func_count++;
}

- func_list = malloc_or_die(sizeof(*func_list) * func_count + 1);
+ func_list = malloc_or_die(sizeof(*func_list) * (func_count + 1));

i = 0;
while (list) {
_

==============================================================================
TOPIC: perf: Fix timechart header handling
http://groups.google.com/group/linux.kernel/t/a6009ad0de65646b?hl=en
==============================================================================

== 1 of 6 ==
Date: Sun, Dec 6 2009 3:50 am
From: OGAWA Hirofumi

Hi,

Update "struct trace_entry" to match with current one. And remove
"size" field from it.

If it has "size", it become cause of alignment mismatch of structure
with kernel.

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

tools/perf/builtin-timechart.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)

diff -puN tools/perf/builtin-timechart.c~perf-fix-timechart-header-handling tools/perf/builtin-timechart.c
--- linux-2.6/tools/perf/builtin-timechart.c~perf-fix-timechart-header-handling 2009-12-06 19:27:33.000000000 +0900
+++ linux-2.6-hirofumi/tools/perf/builtin-timechart.c 2009-12-06 19:27:44.000000000 +0900
@@ -302,12 +302,11 @@ process_exit_event(event_t *event)
}

struct trace_entry {
- u32 size;
unsigned short type;
unsigned char flags;
unsigned char preempt_count;
int pid;
- int tgid;
+ int lock_depth;
};

struct power_entry {
@@ -489,6 +488,7 @@ process_sample_event(event_t *event)
u64 stamp = 0;
u32 cpu = 0;
u32 pid = 0;
+ u32 size, *size_ptr;
struct trace_entry *te;

if (sample_type & PERF_SAMPLE_IP)
@@ -518,9 +518,13 @@ process_sample_event(event_t *event)
if (sample_type & PERF_SAMPLE_PERIOD)
cursor++;

- te = (void *)&event->sample.array[cursor];
+ size_ptr = (void *)&event->sample.array[cursor];

- if (sample_type & PERF_SAMPLE_RAW && te->size > 0) {
+ size = *size_ptr;
+ size_ptr++;
+
+ te = (void *)size_ptr;
+ if (sample_type & PERF_SAMPLE_RAW && size > 0) {
char *event_str;
struct power_entry *pe;

_

== 2 of 6 ==
Date: Sun, Dec 6 2009 3:50 am
From: OGAWA Hirofumi

Currently, sample event data is parsed for each commands, and it is
assuming that the data is not including other data. (E.g. timechart,
trace, etc. can't parse the event if it has PERF_SAMPLE_CALLCHAIN)

So, even if we record the superset data for multiple commands at a
time, commands can't parse. etc.

To fix it, this makes common sample event parser, and use it to parse
sample event correctly. (PERF_SAMPLE_READ is unsupported for now
though, it seems to be not using.)

Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---

tools/perf/builtin-kmem.c | 36 +++++++--------------
tools/perf/builtin-report.c | 39 ++++++++++-------------
tools/perf/builtin-sched.c | 38 +++++++---------------
tools/perf/builtin-timechart.c | 56 ++++++++-------------------------
tools/perf/builtin-trace.c | 48 ++++++++--------------------
tools/perf/util/event.c | 67 ++++++++++++++++++++++++++++++++++++++++
tools/perf/util/event.h | 17 +++++++++-
7 files changed, 155 insertions(+), 146 deletions(-)

diff -puN tools/perf/util/event.h~perf-make-common-sample tools/perf/util/event.h
--- linux-2.6/tools/perf/util/event.h~perf-make-common-sample 2009-12-06 19:42:51.000000000 +0900
+++ linux-2.6-hirofumi/tools/perf/util/event.h 2009-12-06 19:42:51.000000000 +0900
@@ -56,11 +56,25 @@ struct read_event {
u64 id;
};

-struct sample_event{
+struct sample_event {
struct perf_event_header header;
u64 array[];
};

+struct sample_data {
+ u64 ip;
+ u32 pid, tid;
+ u64 time;
+ u64 addr;
+ u64 id;
+ u64 stream_id;
+ u32 cpu;
+ u64 period;
+ struct ip_callchain *callchain;
+ u32 raw_size;
+ void *raw_data;
+};
+
#define BUILD_ID_SIZE 20

struct build_id_event {
@@ -155,5 +169,6 @@ int event__process_task(event_t *self);
struct addr_location;
int event__preprocess_sample(const event_t *self, struct addr_location *al,
symbol_filter_t filter);
+int event__parse_sample(event_t *event, u64 type, struct sample_data *data);

twitter

Sunday, December 6, 2009

linux.kernel - 26 new messages in 13 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts