Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

Hello All, > All works now for me with preempt-rt. The problem is using hrtimer. > I think that hrtimer are executed with interrupts disabled so, if > this happen when I must receive a char, i have an overrun. No, they share the same interrupt line... So, while the timer interrupt handler is

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

Hello All, All works now for me with preempt-rt. The problem is using hrtimer. I think that hrtimer are executed with interrupts disabled so, if this happen when I must receive a char, i have an overrun. No, they share the same interrupt line... So, while the timer interrupt handler is

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

Hello Michael, > the serial driver works fine. The problem seems to be related to the > tclib, when I use it as a clocksource. tclib as a clocksource should be no problem on Preempt-RT, do not use it as clockevent device, it will not work properly on preempt-rt on at91* yet, especially with the

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

Hello Michael, the serial driver works fine. The problem seems to be related to the tclib, when I use it as a clocksource. tclib as a clocksource should be no problem on Preempt-RT, do not use it as clockevent device, it will not work properly on preempt-rt on at91* yet, especially with the

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

Hello Haavard, > That's what I was thinking too. If this is indeed the cause, the > dev_err() added by the debug patch I posted should trigger and we may > consider boosting the priority of the tasklet (using > tasklet_hi_schedule.) Notice that we are talking about Preempt-RT here. Everything is

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

Hello Haavard, That's what I was thinking too. If this is indeed the cause, the dev_err() added by the debug patch I posted should trigger and we may consider boosting the priority of the tasklet (using tasklet_hi_schedule.) Notice that we are talking about Preempt-RT here. Everything is

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

Hello Haavard, > It seems to be very sensitive to network traffic though...could it have > something to do with softirq scheduling? Could you try the patch below > and see if you can trigger the error message? Funny that you mention this. The largest latencies I currently have on RT (and rm9200)

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

Hello Haavard, It seems to be very sensitive to network traffic though...could it have something to do with softirq scheduling? Could you try the patch below and see if you can trigger the error message? Funny that you mention this. The largest latencies I currently have on RT (and rm9200)

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

Hello Haavard, > The code above is from the tasklet, so I don't think that's the problem. > The interrupt handler doesn't take any locks. > Or are spinlocks not allowed in softirq context either? They are allowed there... So, it has to be something different. > > I believe I have to look at the

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

remove_one_port(_uart, port); > > >> > > >> + tasklet_kill(_port->tasklet); > > >> + kfree(atmel_port->rx_ring.buf); > > >> + > > >> > > Why the tasklet_kill is not done in atmel_shutdown? > > Why should it be? If it should, we

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

Hello Haavard, The code above is from the tasklet, so I don't think that's the problem. The interrupt handler doesn't take any locks. Or are spinlocks not allowed in softirq context either? They are allowed there... So, it has to be something different. I believe I have to look at the

Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler

Signed-off-by: Remy Bohmer [EMAIL PROTECTED] --- include/linux/serial_core.h |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) Index: linux-2.6.23/include/linux/serial_core.h === --- linux-2.6.23.orig/include/linux

Re: [PATCH] kthread: always create the kernel threads with normal priority

RQ-kthreads as well as the prio of a certain interrupt handler. This might give some conflicts, and I have to check how to resolve these. Kind Regards, Remy 2008/1/7, Michal Schmidt <[EMAIL PROTECTED]>: > On Mon, 7 Jan 2008 12:22:51 +0100 > "Remy Bohmer" <[EMAIL PRO

Re: [PATCH] kthread: always create the kernel threads with normal priority

Hello Michal and Andrew, > Let's not make the decision for the user. Just allow the administrator to > change kthreadd's priority safely if he chooses to do it. Ensure that the > kernel threads are created with the usual nice level even if kthreadd's > priority is changed from the default. Last

Re: [PATCH] kthread: always create the kernel threads with normal priority

Hello Michal and Andrew, Let's not make the decision for the user. Just allow the administrator to change kthreadd's priority safely if he chooses to do it. Ensure that the kernel threads are created with the usual nice level even if kthreadd's priority is changed from the default. Last

Re: [PATCH] kthread: always create the kernel threads with normal priority

to check how to resolve these. Kind Regards, Remy 2008/1/7, Michal Schmidt [EMAIL PROTECTED]: On Mon, 7 Jan 2008 12:22:51 +0100 Remy Bohmer [EMAIL PROTECTED] wrote: Hello Michal and Andrew, Let's not make the decision for the user. Just allow the administrator to change kthreadd's

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

/12/20, Jaswinder Singh <[EMAIL PROTECTED]>: > Hello Remy, > > On 12/20/07, Remy Bohmer <[EMAIL PROTECTED]> wrote: > > So, Is this a serious requirement? Should this be possible? > > I have noticed this problem: > [EMAIL PROTECTED]:~# cat /proc/loadavgrt > 1.00 1

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

an IRQ that generates large latencies, and each RT-system designer shall divide the priorities different, due to different system requirements. Kind Regards, Remy 2007/12/20, Jaswinder Singh <[EMAIL PROTECTED]>: > On 12/20/07, Remy Bohmer <[EMAIL PROTECTED]> wrote: > > The RT-patch origina

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

large latencies, and each RT-system designer shall divide the priorities different, due to different system requirements. Kind Regards, Remy 2007/12/20, Jaswinder Singh [EMAIL PROTECTED]: On 12/20/07, Remy Bohmer [EMAIL PROTECTED] wrote: The RT-patch originally creates all its softirq-threads

Re: [patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

, Jaswinder Singh [EMAIL PROTECTED]: Hello Remy, On 12/20/07, Remy Bohmer [EMAIL PROTECTED] wrote: So, Is this a serious requirement? Should this be possible? I have noticed this problem: [EMAIL PROTECTED]:~# cat /proc/loadavgrt 1.00 1.00 1.00 0/52 1158 [EMAIL PROTECTED]:~# cat /proc/loadavg

Re: [patch 1/3] Add generic routine for parsing map-like options on kernel cmd-line (repost:CC to LKML)

Hello Randy, Sorry for the language errors, English is not my Native language, so I make these stupid errors... > > + * get_map_option - Parse integer from an option map > The @param lines (below) need to go here, immediately following the > function short description (the line above). No

Re: [PATCH v2 0/6] atmel_serial: Cleanups, irq handler splitup & DMA

Hello, > preempt-rt can disable interrupts for 300 us? I am not sure if it really is an interrupt lock that long, but on these ARM cores I still run into latencies that large. I tried using latency_trace to figure out where they come from, but that tool even reports interrupt locks up to 10 ms

[patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

kernel/Documentation/kernel-parameters.txt for usage info. Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt | 11 +++ kernel/softirq.c| 105 ++-- 2 files changed, 99 insertions(+), 17 deletions(-)

[patch 2/3] Enable setting of IRQ-thread priorities from kernel cmdline (repost:CC to LKML)

as before, and all IRQ-threads start at 50. * No wildcards are supported on the cmdline. See kernel/Documentation/kernel-parameters.txt for usage info. Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]> --- Documentation/kernel-parameters.txt |7 ++ include/linux/irq.h

[patch 1/3] Add generic routine for parsing map-like options on kernel cmd-line (repost:CC to LKML)

This patch adds a generic routine to the kernel, so that a map of settings can be entered on the kernel commandline. Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]> --- --- include/linux/kernel.h |1 lib/cmdline.c | 58 + 2

[patch 0/3] add kernel-cmdline support for interrupt thread priorities (repost:CC to LKML)

=) routine to kernel/softirq.c I hope you can find the time to review this set. Kind Regards, Remy Bohmer -- -- 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

Re: [PATCH v2 0/6] atmel_serial: Cleanups, irq handler splitup & DMA

> > but I noticed that I sometimes get an input overrun (ttyS0: 1 > > input overrun(s) ) during stress conditions. > > This is something I did not notice before, maybe it was already there, > > or has something changed in this area that it is now more sensitive > > for this? > Hmm...is this with

Re: [PATCH v2 0/6] atmel_serial: Cleanups, irq handler splitup & DMA

Kind Regards, Remy 2007/12/19, Haavard Skinnemoen <[EMAIL PROTECTED]>: > On Wed, 19 Dec 2007 16:57:04 +0100 > "Remy Bohmer" <[EMAIL PROTECTED]> wrote: > > > Hello Haavard, > > > > Sorry.. But I get an Oops on Preempt-RT with the latest set of >

Re: [PATCH v2 0/6] atmel_serial: Cleanups, irq handler splitup & DMA

cleans up the atmel_serial driver a bit, > moves a significant portion of the interrupt handler into a tasklet, > and adds DMA support. This is the result of a combined effort by Chip > Coldwell, Remy Bohmer and me. The patches should apply cleanly onto > Linus' latest git tree. > > With DMA,

Re: [PATCH] atmel_serial: Split the interrupt handler

Hello Haavard, > Hrm. We probably need to lock while updating icount. That's a problem > since we do that from the tx interrupt handler...and I don't suppose we > want to move most of the atmel_tx_chars() code into the tasklet too...? I do not see a reason why not moving transmit to a tasklet.

Re: [PATCH] atmel_serial: Split the interrupt handler

on top of the other 5 patches, and everything still works, also tested under stress conditions. So: Acked-by: Remy Bohmer <[EMAIL PROTECTED]> Kind Regards, Remy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More m

Re: [PATCH] atmel_serial: Split the interrupt handler

of the other 5 patches, and everything still works, also tested under stress conditions. So: Acked-by: Remy Bohmer [EMAIL PROTECTED] Kind Regards, Remy -- 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

Re: [PATCH] atmel_serial: Split the interrupt handler

Hello Haavard, Hrm. We probably need to lock while updating icount. That's a problem since we do that from the tx interrupt handler...and I don't suppose we want to move most of the atmel_tx_chars() code into the tasklet too...? I do not see a reason why not moving transmit to a tasklet. It

Re: [PATCH v2 0/6] atmel_serial: Cleanups, irq handler splitup DMA

a significant portion of the interrupt handler into a tasklet, and adds DMA support. This is the result of a combined effort by Chip Coldwell, Remy Bohmer and me. The patches should apply cleanly onto Linus' latest git tree. With DMA, I see transfer rates around 92 kbps when transferring a big

Re: [PATCH v2 0/6] atmel_serial: Cleanups, irq handler splitup DMA

Regards, Remy 2007/12/19, Haavard Skinnemoen [EMAIL PROTECTED]: On Wed, 19 Dec 2007 16:57:04 +0100 Remy Bohmer [EMAIL PROTECTED] wrote: Hello Haavard, Sorry.. But I get an Oops on Preempt-RT with the latest set of patches. I did not see it earlier today with the other set of patches

Re: [PATCH v2 0/6] atmel_serial: Cleanups, irq handler splitup DMA

but I noticed that I sometimes get an input overrun (ttyS0: 1 input overrun(s) ) during stress conditions. This is something I did not notice before, maybe it was already there, or has something changed in this area that it is now more sensitive for this? Hmm...is this with or without

[patch 0/3] add kernel-cmdline support for interrupt thread priorities (repost:CC to LKML)

=) routine to kernel/softirq.c I hope you can find the time to review this set. Kind Regards, Remy Bohmer -- -- 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

[patch 1/3] Add generic routine for parsing map-like options on kernel cmd-line (repost:CC to LKML)

This patch adds a generic routine to the kernel, so that a map of settings can be entered on the kernel commandline. Signed-off-by: Remy Bohmer [EMAIL PROTECTED] --- --- include/linux/kernel.h |1 lib/cmdline.c | 58 + 2 files

[patch 2/3] Enable setting of IRQ-thread priorities from kernel cmdline (repost:CC to LKML)

as before, and all IRQ-threads start at 50. * No wildcards are supported on the cmdline. See kernel/Documentation/kernel-parameters.txt for usage info. Signed-off-by: Remy Bohmer [EMAIL PROTECTED] --- Documentation/kernel-parameters.txt |7 ++ include/linux/irq.h |1

[patch 3/3] Enable setting of IRQ-thread priorities from kernel cmdline. (repost:CC to LKML)

kernel/Documentation/kernel-parameters.txt for usage info. Signed-off-by: Remy Bohmer [EMAIL PROTECTED] --- Documentation/kernel-parameters.txt | 11 +++ kernel/softirq.c| 105 ++-- 2 files changed, 99 insertions(+), 17 deletions(-) Index

Re: [PATCH v2 0/6] atmel_serial: Cleanups, irq handler splitup DMA

Hello, preempt-rt can disable interrupts for 300 us? I am not sure if it really is an interrupt lock that long, but on these ARM cores I still run into latencies that large. I tried using latency_trace to figure out where they come from, but that tool even reports interrupt locks up to 10 ms

Re: [patch 1/3] Add generic routine for parsing map-like options on kernel cmd-line (repost:CC to LKML)

Hello Randy, Sorry for the language errors, English is not my Native language, so I make these stupid errors... + * get_map_option - Parse integer from an option map The @param lines (below) need to go here, immediately following the function short description (the line above). No

Re: [PATCH] atmel_serial: Split the interrupt handler

Hello Haavard, > > BTW: Attached I have added a 2nd patch that I use for Preempt-RT. (For > > cleaner startup, and to get rid of useless IRQ-threads. > > Hrm. That assumption isn't valid on AVR32...on AP7000, for example, > IRQ1 is used by the LCD controller. In that case, forget that (dirty)

Re: [PATCH] atmel_serial: Split the interrupt handler

Hello Haavard, A few remarks: > From: Remy Bohmer <[EMAIL PROTECTED]> My name, at your address ;-))) > This patch splits up the interrupt handler of the serial port > into a interrupt top-half and a tasklet. I see you moved the handling of the sysrq-key to the tasklet. Th

Re: [PATCH]: Atmel Serial Console interrupt handler splitup

Hello Haavard, > I don't think so, but I don't feel all that strongly about it. I'd > actually prefer if we used at_writel() and at_readl() throughout the > code and killed those UART_PUT/UART_GET macros. I completely agree. Kind Regards, Remy -- To unsubscribe from this list: send the line

Re: [PATCH v2] atmel_serial: Clean up the code

Hello Haavard, > Please note that I'm not trying to steal the show here -- I just want That did not even come to my mind at all... I am happy with everything that helps making this driver better. What shall we do first from here, splitup of the interrupt handler? Or DMA patch? Kind Regards,

Re: [PATCH v2] atmel_serial: Clean up the code

Hello Haavard, Please note that I'm not trying to steal the show here -- I just want That did not even come to my mind at all... I am happy with everything that helps making this driver better. What shall we do first from here, splitup of the interrupt handler? Or DMA patch? Kind Regards,

Re: [PATCH]: Atmel Serial Console interrupt handler splitup

Hello Haavard, I don't think so, but I don't feel all that strongly about it. I'd actually prefer if we used at_writel() and at_readl() throughout the code and killed those UART_PUT/UART_GET macros. I completely agree. Kind Regards, Remy -- To unsubscribe from this list: send the line

Re: [PATCH] atmel_serial: Split the interrupt handler

Hello Haavard, A few remarks: From: Remy Bohmer [EMAIL PROTECTED] My name, at your address ;-))) This patch splits up the interrupt handler of the serial port into a interrupt top-half and a tasklet. I see you moved the handling of the sysrq-key to the tasklet. This was actually a very

Re: [PATCH] atmel_serial: Split the interrupt handler

Hello Haavard, BTW: Attached I have added a 2nd patch that I use for Preempt-RT. (For cleaner startup, and to get rid of useless IRQ-threads. Hrm. That assumption isn't valid on AVR32...on AP7000, for example, IRQ1 is used by the LCD controller. In that case, forget that (dirty) patch

Re: [PATCH]: Atmel Serial Console interrupt handler splitup

Hello Haavard, > > Yep. All calls that block on a Mutex somehow on Preempt-RT. (such as > > spinlocks, wakeup_interruptible() and many of its friends.) > Right. Looks like the DMA patch call these functions from irq context > too...I guess it'll need the same treatment? That is correct. DMA code

Re: [PATCH]: Atmel Serial Console interrupt handler splitup

Hello Haavard, > I'll give it a shot, but first I have some comments on your other > patches. Good news someone is working on this bug again. Also good news you already found a bug in there. > Btw, it would be nice if patches that affect more or less > architecture-independent drivers were

Re: [PATCH]: Atmel Serial Console interrupt handler splitup

Hello Haavard, I'll give it a shot, but first I have some comments on your other patches. Good news someone is working on this bug again. Also good news you already found a bug in there. Btw, it would be nice if patches that affect more or less architecture-independent drivers were posted

Re: [PATCH]: Atmel Serial Console interrupt handler splitup

Hello Haavard, Yep. All calls that block on a Mutex somehow on Preempt-RT. (such as spinlocks, wakeup_interruptible() and many of its friends.) Right. Looks like the DMA patch call these functions from irq context too...I guess it'll need the same treatment? That is correct. DMA code does

Re: [PATCH] Revert lazy irq disable for simple irqs

Hello Steven, > In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq disabling > was implemented, and the simple irq handler had a masking set to it. > > Remy Bohmer discovered that some devices in the ARM architecture > would trigger the mask, but never unmask it.

Re: 2.6.23.9-rt13

pdates (Daniel Walker) > > - Remove warning in local_bh_enable (Kevin Hilman) > > - use real time pcp locking for page draining during cpu (Andi Kleen) > > - Revert lazy disable irq from simple irq handler (Steven Rostedt) > > - AT91 switch to edge from simple irq

Re: 2.6.23.9-rt13

for page draining during cpu (Andi Kleen) - Revert lazy disable irq from simple irq handler (Steven Rostedt) - AT91 switch to edge from simple irq (Remy Bohmer) to build a 2.6.23.9-rt13 tree, the following patches should be applied: http://www.kernel.org/pub/linux/kernel/v2.6/linux

Re: [PATCH] Revert lazy irq disable for simple irqs

Hello Steven, In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq disabling was implemented, and the simple irq handler had a masking set to it. Remy Bohmer discovered that some devices in the ARM architecture would trigger the mask, but never unmask it. His patch to do

Re: [PATCH RT] Revert Softdisable for simple irqs.

> No problem. Could you also ACK the one I sent for mainline. I will test it first tomorrow morning. Remy -- 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

Re: [PATCH RT] Revert Softdisable for simple irqs.

Hello Steven, > > In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq disabling > was implemented, and the simple irq handler had a masking set to it. > > Remy Bohmer discovered that some devices in the ARM architecture > would trigger the mask, but never unmask i

Re: [PATCH RT] Revert Softdisable for simple irqs.

Hello Steven, In commit 76d2160147f43f982dfe881404cfde9fd0a9da21 lazy irq disabling was implemented, and the simple irq handler had a masking set to it. Remy Bohmer discovered that some devices in the ARM architecture would trigger the mask, but never unmask it. His patch to do

Re: [PATCH RT] Revert Softdisable for simple irqs.

No problem. Could you also ACK the one I sent for mainline. I will test it first tomorrow morning. Remy -- 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

Re: lockdep problem conversion semaphore->mutex (dev->sem)

Peter, Thanks for this clear answer. Remy 2007/12/8, Peter Zijlstra <[EMAIL PROTECTED]>: > > On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote: > > > Which problems? I did not see any special things, it looked rather > > straight forward. What have I overlook

Re: lockdep problem conversion semaphore->mutex (dev->sem)

Hello Ingo, > no, you are wrong. If you want to do complex locking, you can still do > it: take a look at the dev->sem conversion patches from Peter which > correctly do this. Lockdep has all the facilities for that. > (you just dont know about them) Ok. > the general policy message here is: do

Re: lockdep problem conversion semaphore->mutex (dev->sem)

Hello Peter, > And while you might not see it in-tree anymore, lockdep does help out > tremendously while developing new code. I'm sure that without it the > locking would be in a much worse state than it is today. I am not arguing that, I am also convinced it has done a good job. > I have a

Re: lockdep problem conversion semaphore->mutex (dev->sem)

Hello Peter and Daniel, > Yeah, it are different lock instances, however by virtue of sharing the > same lock init site, they belong to the same lock class. Lockdep works > by tracking class dependancies, not instance dependancies. The device and its parent both indeed have different

Re: lockdep problem conversion semaphore-mutex (dev-sem)

Hello Peter and Daniel, Yeah, it are different lock instances, however by virtue of sharing the same lock init site, they belong to the same lock class. Lockdep works by tracking class dependancies, not instance dependancies. The device and its parent both indeed have different

Re: lockdep problem conversion semaphore-mutex (dev-sem)

Hello Peter, And while you might not see it in-tree anymore, lockdep does help out tremendously while developing new code. I'm sure that without it the locking would be in a much worse state than it is today. I am not arguing that, I am also convinced it has done a good job. I have a good

Re: lockdep problem conversion semaphore-mutex (dev-sem)

Hello Ingo, no, you are wrong. If you want to do complex locking, you can still do it: take a look at the dev-sem conversion patches from Peter which correctly do this. Lockdep has all the facilities for that. (you just dont know about them) Ok. the general policy message here is: do not

Re: lockdep problem conversion semaphore-mutex (dev-sem)

Peter, Thanks for this clear answer. Remy 2007/12/8, Peter Zijlstra [EMAIL PROTECTED]: On Sat, 2007-12-08 at 21:33 +0100, Remy Bohmer wrote: Which problems? I did not see any special things, it looked rather straight forward. What have I overlooked? On suspend it locks the whole device

lockdep problem conversion semaphore->mutex (dev->sem)

Hello Peter, > > What specifically is wrong with dev->sem ? > > Nothing really, other than that they use semaphores to avoid lockdep :-/ > > I think I know how to annotate this, after Alan Stern explained all the > use cases, but I haven't come around to implementing it. Hope to do that >

lockdep problem conversion semaphore-mutex (dev-sem)

Hello Peter, What specifically is wrong with dev-sem ? Nothing really, other than that they use semaphores to avoid lockdep :-/ I think I know how to annotate this, after Alan Stern explained all the use cases, but I haven't come around to implementing it. Hope to do that soonish. I was

Re: [PATCH 3/3] printer port driver: semaphore to mutex

Hello Daniel, > I looked at the console_sem , but i was going to leave that as last.. > > The problem with the console_sem is that it can get locked from > interrupt context, which is discouraged with mutex types.. I think it > will be complicated to convert.. At first it looked simple, but

Re: [PATCH 3/3] printer port driver: semaphore to mutex

Hello Matthias, Which do you have exactly on your list? (good to know, it prevents double work...) Remy 2007/12/6, Matthias Kaehlcke <[EMAIL PROTECTED]>: > El Thu, Dec 06, 2007 at 08:34:06AM -0800 Daniel Walker ha dit: > > > On Thu, 2007-12-06 at 11:23 +0100, Ingo Molnar wrote: > > > * Daniel

Re: [PATCH 3/3] printer port driver: semaphore to mutex

Daniel, FYI: I am working on the conversion of the 2 sem->mutex in kernel/printk.c Remy 2007/12/6, Daniel Walker <[EMAIL PROTECTED]>: > On Thu, 2007-12-06 at 11:23 +0100, Ingo Molnar wrote: > > * Daniel Walker <[EMAIL PROTECTED]> wrote: > > > > > The port_mutex is actually a semaphore, so

Re: [PATCH 3/3] printer port driver: semaphore to mutex

Daniel, FYI: I am working on the conversion of the 2 sem-mutex in kernel/printk.c Remy 2007/12/6, Daniel Walker [EMAIL PROTECTED]: On Thu, 2007-12-06 at 11:23 +0100, Ingo Molnar wrote: * Daniel Walker [EMAIL PROTECTED] wrote: The port_mutex is actually a semaphore, so easily converted

Re: [PATCH 3/3] printer port driver: semaphore to mutex

Hello Matthias, Which do you have exactly on your list? (good to know, it prevents double work...) Remy 2007/12/6, Matthias Kaehlcke [EMAIL PROTECTED]: El Thu, Dec 06, 2007 at 08:34:06AM -0800 Daniel Walker ha dit: On Thu, 2007-12-06 at 11:23 +0100, Ingo Molnar wrote: * Daniel Walker

Re: [PATCH 3/3] printer port driver: semaphore to mutex

Hello Daniel, I looked at the console_sem , but i was going to leave that as last.. The problem with the console_sem is that it can get locked from interrupt context, which is discouraged with mutex types.. I think it will be complicated to convert.. At first it looked simple, but after I

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

time on that board. Kind Regards, Remy 2007/11/29, Remy Bohmer <[EMAIL PROTECTED]>: > Hello Russell, > > > While I realise that, I'm telling you that the _problem_ is being > > caused by the wrong handler being used. > > Okay, I believe you... (someone told me once,

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Hello Russell, > While I realise that, I'm telling you that the _problem_ is being > caused by the wrong handler being used. Okay, I believe you... (someone told me once, Russell is right, and if you do not believe him, he is still right ;-) > SA1100 and PXA have exactly the same setup. They

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Hello Russell, > If people insist on adding the mask/unmask crap to it, the function > might as well be deleted and be an alias for handle_level_IRQ. Because > that's _precisely_ what you lot are turning it into. First, I want to make clear that I am just debugging a problem on RT that does not

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Kind Regards, Remy 2007/11/29, Russell King - ARM Linux <[EMAIL PROTECTED]>: > On Thu, Nov 29, 2007 at 11:14:30AM +0100, Remy Bohmer wrote: > > I do not think Russell is right here with assuming that the wrong > > interrupt handler type is used. Looking at the behaviour

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Hello Steven, > Remy, sorry about this round-a-bout. But I don't have any of the hardware > that this affects, and I'm just being cautious. No problem, I expected this discussion when I submitted the patch. It is logical that everybody is cautious on this subject. But still, there is a bug here.

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Hello Steven, Remy, sorry about this round-a-bout. But I don't have any of the hardware that this affects, and I'm just being cautious. No problem, I expected this discussion when I submitted the patch. It is logical that everybody is cautious on this subject. But still, there is a bug here.

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

King - ARM Linux [EMAIL PROTECTED]: On Thu, Nov 29, 2007 at 11:14:30AM +0100, Remy Bohmer wrote: I do not think Russell is right here with assuming that the wrong interrupt handler type is used. Looking at the behaviour of the mainline kernel (non-RT), the implementation is quite different

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Hello Russell, If people insist on adding the mask/unmask crap to it, the function might as well be deleted and be an alias for handle_level_IRQ. Because that's _precisely_ what you lot are turning it into. First, I want to make clear that I am just debugging a problem on RT that does not

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Hello Russell, While I realise that, I'm telling you that the _problem_ is being caused by the wrong handler being used. Okay, I believe you... (someone told me once, Russell is right, and if you do not believe him, he is still right ;-) SA1100 and PXA have exactly the same setup. They use

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

time on that board. Kind Regards, Remy 2007/11/29, Remy Bohmer [EMAIL PROTECTED]: Hello Russell, While I realise that, I'm telling you that the _problem_ is being caused by the wrong handler being used. Okay, I believe you... (someone told me once, Russell is right, and if you do

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Hello Kevin, Just copied your mail to the list, maybe your solution is also worth looking at. Remy > I had a similar issue when using the chained GPIO interrupts on OMAP > under PREEMPT_RT. > > I believe the chained handler itself is supposed to be doing the > ack/unmask instead of the

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Hello Daniel, > * Note: The caller is expected to handle the ack, clear, mask and > * unmask issues if necessary. > So we shouldn't need any flow control unless there is some other > factors.. This comment can be misinterpreted, I think. Who is assumed to be the caller in this

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Hello Daniel, * Note: The caller is expected to handle the ack, clear, mask and * unmask issues if necessary. So we shouldn't need any flow control unless there is some other factors.. This comment can be misinterpreted, I think. Who is assumed to be the caller in this context?

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Hello Kevin, Just copied your mail to the list, maybe your solution is also worth looking at. Remy I had a similar issue when using the chained GPIO interrupts on OMAP under PREEMPT_RT. I believe the chained handler itself is supposed to be doing the ack/unmask instead of the

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Attached the same patch, but it also cleans the manage.c code a bit, because the IRQ types 'simple IRQ', 'level-IRQ' and 'FastEOI' were handled differently while they should be handled the same. Kind Regards, Remy 2007/11/26, Remy Bohmer <[EMAIL PROTECTED]>: > Hello, > > I u

[PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

handling stalls forever. This is caused by a unbalanced interrupt mask/unmask problem in the kernel. The attached patch fixes this. More information about this problem is documented inside the patch itself. This patch is meant for Preempt-RT only. Kind Regards, Remy Bohmer On ARM there is a problem

[PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

handling stalls forever. This is caused by a unbalanced interrupt mask/unmask problem in the kernel. The attached patch fixes this. More information about this problem is documented inside the patch itself. This patch is meant for Preempt-RT only. Kind Regards, Remy Bohmer On ARM there is a problem

Re: [PATCH PREEMPT_RT]: On AT91 ARM: GPIO Interrupt handling can/will stall forever

Attached the same patch, but it also cleans the manage.c code a bit, because the IRQ types 'simple IRQ', 'level-IRQ' and 'FastEOI' were handled differently while they should be handled the same. Kind Regards, Remy 2007/11/26, Remy Bohmer [EMAIL PROTECTED]: Hello, I use 2.6.23.1-rt5

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

Hello Daniel, Can we coordinate who is doing what somehow, to prevent double work? Remy 2007/11/19, Daniel Walker <[EMAIL PROTECTED]>: > On Mon, 2007-11-19 at 02:24 -0500, Jon Masters wrote: > > On Sat, 2007-11-17 at 09:55 -0800, Daniel Walker wrote: > > > > > Sure, you want to split the list?

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

es, which is thus different compared to the non-RT kernel and therefor quite confusing. So, thank you (and Daniel) for pointing me into the right direction. Now lets get rid of the 'struct semaphore' completely in the kernel :-)) Kind Regards, Remy Bohmer - To unsubscribe from this list: sen

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

kernel and therefor quite confusing. So, thank you (and Daniel) for pointing me into the right direction. Now lets get rid of the 'struct semaphore' completely in the kernel :-)) Kind Regards, Remy Bohmer - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: [BUG on PREEMPT_RT, 2.6.23.1-rt5] in rt-mutex code and signals

Hello Daniel, Can we coordinate who is doing what somehow, to prevent double work? Remy 2007/11/19, Daniel Walker [EMAIL PROTECTED]: On Mon, 2007-11-19 at 02:24 -0500, Jon Masters wrote: On Sat, 2007-11-17 at 09:55 -0800, Daniel Walker wrote: Sure, you want to split the list? I'm

  1   2   >