On Tue, 2007-10-16 at 16:12 -0400, Dmitry Torokhov wrote:
> On 10/16/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > On Tue, 16 Oct 2007, Matthew Garrett wrote:
> > > >
> > > > It still doesn't mean it belongs inside the stream of data for the
> > > > keyboard,
> > > > maskerading as a key
On Tue, 2007-10-16 at 16:12 -0400, Dmitry Torokhov wrote:
On 10/16/07, Linus Torvalds [EMAIL PROTECTED] wrote:
On Tue, 16 Oct 2007, Matthew Garrett wrote:
It still doesn't mean it belongs inside the stream of data for the
keyboard,
maskerading as a key press.
But it *is*
On Mon, 2007-10-15 at 19:07 -0200, Henrique de Moraes Holschuh wrote:
> On Mon, 15 Oct 2007, Jeremy Katz wrote:
> > There are standard keycodes for brightness and volume; map the events to
> > emit them so that things work properly
>
> NAK. It is the completely wron
There are standard keycodes for brightness and volume; map the events to
emit them so that things work properly
Signed-off-by: Jeremy Katz <[EMAIL PROTECTED]>
---
drivers/misc/thinkpad_acpi.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/driver
There are standard keycodes for brightness and volume; map the events to
emit them so that things work properly
Signed-off-by: Jeremy Katz [EMAIL PROTECTED]
---
drivers/misc/thinkpad_acpi.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/misc
On Mon, 2007-10-15 at 19:07 -0200, Henrique de Moraes Holschuh wrote:
On Mon, 15 Oct 2007, Jeremy Katz wrote:
There are standard keycodes for brightness and volume; map the events to
emit them so that things work properly
NAK. It is the completely wrong thing to do for IBM thinkpads which
On Wed, 25 Jul 2007, Oleg Nesterov wrote:
On 07/24, Jeremy Katz wrote:
Sorry. That should have been "without apparent effect".
Sorry. I confused completely.
So. You mean that even with that patch you _still_ see the
BUG_ON(!SIGQUEUE_PREALLOC) in sigqueue_free() ?
Yes. I did
On Tue, 24 Jul 2007, Oleg Nesterov wrote:
On 07/23, Jeremy Katz wrote:
On Fri, 20 Jul 2007, Oleg Nesterov wrote:
I still can't believe we have a double-free problem, this looks imposiible.
Do you see the
"idr_remove called for id=%d which is not allocated.\n"
in syslog
On Tue, 24 Jul 2007, Oleg Nesterov wrote:
On 07/23, Jeremy Katz wrote:
On Fri, 20 Jul 2007, Oleg Nesterov wrote:
I still can't believe we have a double-free problem, this looks imposiible.
Do you see the
idr_remove called for id=%d which is not allocated.\n
in syslog?
No. I
On Wed, 25 Jul 2007, Oleg Nesterov wrote:
On 07/24, Jeremy Katz wrote:
Sorry. That should have been without apparent effect.
Sorry. I confused completely.
So. You mean that even with that patch you _still_ see the
BUG_ON(!SIGQUEUE_PREALLOC) in sigqueue_free() ?
Yes. I did not notice
On Fri, 20 Jul 2007, Oleg Nesterov wrote:
On 07/18, Jeremy Katz wrote:
On Wed, 18 Jul 2007, Oleg Nesterov wrote:
Jeremy, I agree with Thomas that your patch should not be right, but it
does make a difference. Perhaps this is just the timing, but who knows.
Could you add some printk's
On Fri, 20 Jul 2007, Oleg Nesterov wrote:
On 07/18, Jeremy Katz wrote:
On Wed, 18 Jul 2007, Oleg Nesterov wrote:
Jeremy, I agree with Thomas that your patch should not be right, but it
does make a difference. Perhaps this is just the timing, but who knows.
Could you add some printk's
On Thu, 19 Jul 2007, Thomas Gleixner wrote:
On Wed, 2007-07-18 at 16:43 -0700, Jeremy Katz wrote:
On Wed, 18 Jul 2007, Jeremy Katz wrote:
On Wed, 18 Jul 2007, Thomas Gleixner wrote:
Also can you please enable CONFIG_PROVE_LOCKING, which might catch any
locking problem, which might
On Thu, 19 Jul 2007, Thomas Gleixner wrote:
On Wed, 2007-07-18 at 16:43 -0700, Jeremy Katz wrote:
On Wed, 18 Jul 2007, Jeremy Katz wrote:
On Wed, 18 Jul 2007, Thomas Gleixner wrote:
Also can you please enable CONFIG_PROVE_LOCKING, which might catch any
locking problem, which might
On Wed, 18 Jul 2007, Jeremy Katz wrote:
On Wed, 18 Jul 2007, Thomas Gleixner wrote:
Also can you please enable CONFIG_PROVE_LOCKING, which might catch any
locking problem, which might be related to this.
Another test: Can you please disable CONFIG_SCHED_SMT to narrow it down
further
On Wed, 18 Jul 2007, Oleg Nesterov wrote:
Jeremy, I agree with Thomas that your patch should not be right, but it
does make a difference. Perhaps this is just the timing, but who knows.
Could you add some printk's to be sure that lock_timer() actually fails
while it never should?
Agreed.
On Wed, 18 Jul 2007, Thomas Gleixner wrote:
On Wed, 2007-07-18 at 08:05 +0200, Thomas Gleixner wrote:
On Tue, 2007-07-17 at 16:58 -0700, Jeremy Katz wrote:
EFLAGS: 00010246 (2.6.22.1-WR1.4aq_cgl #2)
Hmm. Are there any other patches on that kernel ?
Just hrt6 and your proposed fix
On Wed, 18 Jul 2007, Thomas Gleixner wrote:
On Wed, 2007-07-18 at 08:05 +0200, Thomas Gleixner wrote:
On Tue, 2007-07-17 at 16:58 -0700, Jeremy Katz wrote:
EFLAGS: 00010246 (2.6.22.1-WR1.4aq_cgl #2)
Hmm. Are there any other patches on that kernel ?
Just hrt6 and your proposed fix
On Wed, 18 Jul 2007, Oleg Nesterov wrote:
Jeremy, I agree with Thomas that your patch should not be right, but it
does make a difference. Perhaps this is just the timing, but who knows.
Could you add some printk's to be sure that lock_timer() actually fails
while it never should?
Agreed.
On Wed, 18 Jul 2007, Jeremy Katz wrote:
On Wed, 18 Jul 2007, Thomas Gleixner wrote:
Also can you please enable CONFIG_PROVE_LOCKING, which might catch any
locking problem, which might be related to this.
Another test: Can you please disable CONFIG_SCHED_SMT to narrow it down
further
On Tue, 17 Jul 2007, Jeremy Katz wrote:
On Tue, 17 Jul 2007, Thomas Gleixner wrote:
With 2.6.14 or with current mainline ?
I haven't been keeping notes quite as studiously as I should have been, but
this just occurred with 2.6.22.1 + the hrt6 patch + your proposed fix:
Scratch that. I
On Tue, 17 Jul 2007, Thomas Gleixner wrote:
On Tue, 2007-07-17 at 11:39 -0700, Jeremy Katz wrote:
I tried the patch with my test case, but still see the issue.
Here's my explanation of the double free race:
CPU 0 CPU 1
sys_timer_delete():
lock_timer
On Tue, 17 Jul 2007, Thomas Gleixner wrote:
Jeremy Katz experienced a posix-timer related bug on 2.6.14. This is
caused by a subtle race, which is there since the original posix timer
commit and persists until today.
timer_delete does:
lock_timer();
timer->it_process = NULL;
unlock_ti
On Tue, 17 Jul 2007, Ingo Molnar wrote:
nice one! The race looks pretty narrow - Jeremy, does your Xens have
hyperthreading? (or are there any heavy SMI sources perhaps that could
open up this race.) If not then there might be some other bug lurking in
there as well.
Affirmative. 2 cores, 2
On Tue, 17 Jul 2007, Ingo Molnar wrote:
nice one! The race looks pretty narrow - Jeremy, does your Xens have
hyperthreading? (or are there any heavy SMI sources perhaps that could
open up this race.) If not then there might be some other bug lurking in
there as well.
Affirmative. 2 cores, 2
On Tue, 17 Jul 2007, Thomas Gleixner wrote:
Jeremy Katz experienced a posix-timer related bug on 2.6.14. This is
caused by a subtle race, which is there since the original posix timer
commit and persists until today.
timer_delete does:
lock_timer();
timer-it_process = NULL;
unlock_timer
On Tue, 17 Jul 2007, Thomas Gleixner wrote:
On Tue, 2007-07-17 at 11:39 -0700, Jeremy Katz wrote:
I tried the patch with my test case, but still see the issue.
Here's my explanation of the double free race:
CPU 0 CPU 1
sys_timer_delete():
lock_timer
On Tue, 17 Jul 2007, Jeremy Katz wrote:
On Tue, 17 Jul 2007, Thomas Gleixner wrote:
With 2.6.14 or with current mainline ?
I haven't been keeping notes quite as studiously as I should have been, but
this just occurred with 2.6.22.1 + the hrt6 patch + your proposed fix:
Scratch that. I
rage scsi_mod sctp uhci_hcd usbcore
ip6_tables ip_tables ipv6
----
Jeremy Katz, Senior Engineer, Wind River
Telephone: +1 510 749 2901
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECT
softdog binfmt_misc video
thermal processor fan button battery ac
usb_storage scsi_mod sctp uhci_hcd usbcore
ip6_tables ip_tables ipv6
Jeremy Katz, Senior Engineer, Wind River
Telephone: +1 510 749 2901
-
To unsubscribe from this list: send the line
30 matches
Mail list logo
