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 runn

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 N

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

gt; > >> platform_device *pdev) > > >> > > >>ret = uart_remove_one_port(&atmel_uart, port); > > >> > > >> + tasklet_kill(&atmel_port->tasklet); > > >> + kfree(atmel_port->rx_ring.buf); > > >> + &g

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 PROTECT

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 y

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)

Q 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 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 inte

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 wh

[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 or

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

this? 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 o

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

ns 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

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] 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 m

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) pat

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

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 "un

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, R

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 poste

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

Re: 2.6.23.9-rt13

> > - latency tracer updates (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 s

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 Ple

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. H

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?

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 goo

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

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.

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

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 Wa

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

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 o

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 us

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

ve regression compared to mainline. 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

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

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

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

[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: [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

'struct semaphore' types, 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 Bo

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

> > Sure, you want to split the list? > > split the list with you? Feel free to take any of those :-) dev->sem is > nontrivial and probably not possible right now - and some of the others > might be problematic too. But there might be fixable ones in the list. > This shouldnt become like the BKL co

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

the integration in mainline of the RT-patch. 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 Please read the FAQ at http://www.tux.org/lkml/

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

Hello Steven, > It should print out warnings, do you have CONFIG_DEBUG_RT_MUTEXES set? Nope, not yet... I will do that on Monday also. (On ARM I have as less as debug options enabled per default, because it eats too much CPU-power) > > * PI should only take place if it is for 100% sure that the

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

ork out how to use a completion for your code. And > if that doesn't work, then use a compat_semaphore. But beware, that the > compat_semaphore can cause unbounded latencies. But then again, so can > completions. I hope you get my point now. Other mechanisms like ordinary rt-mute

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

you can look at the attached driver source and help me with this... Kind Regards, Remy Bohmer 2007/11/16, Steven Rostedt <[EMAIL PROTECTED]>: > > > On Fri, 16 Nov 2007, Remy Bohmer wrote: > > > Hello All, > > > > I have a problem with the RT-mutex code an

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

init_MUTEX() has the same problem. Anyone an idea? Below the kernel oops output. (I run on ARM, but I think that should not matter for this problem) Kind Regards, Remy Bohmer [ 52.113254] WARNING: at kernel/rtmutex.c:585 remove_waiter() [ 52.113254] [] (dump_stack+0x0/0x14) from [] (remov

Re: [RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

Hello Daniel, > Here's another fix for this. I compile tested for ARM (!GENERIC_TIME) , > but I didn't boot test .. Could you boot test this patch? This fix seems to work! The target still boots properly. So, it can be pushed upstream... :-) Kind Regards, Remy Bohmer 2007/10/1

[RT] seqlocks: use of PICK_FUNCTION breaks kernel compile when CONFIG_GENERIC_TIME is NOT set

inux-2.6.23/arch/s390/kernel/time.c:197 Kind Regards, Remy Bohmer 2007/8/28, Daniel Walker <[EMAIL PROTECTED]>: > Replace the old PICK_OP style macros with PICK_FUNCTION. Although, > seqlocks has some alien code, which I also replaced as can be seen > from the line count below. > &

Re: halt does not shut the system down

Hello John, > Thanks for the suggestion. I didn't see anything related to SMM in the > BIOS menus. However, the system has real-time constraints. Thus, I'd > turn SMM off if I knew how :-) Here you can find a driver that can disable and enable the SMI interrupt in the chipset. It supports up to t

Re: halt does not shut the system down

Hello John, > John Sigler wrote: > > When I run 'halt' the kernel prints: > > Halting. > > Shutdown: hdc > > ACPI: PCI interrupt for device :01:05.0 disabled > > ACPI: PCI interrupt for device :01:04.0 disabled > > ACPI: PCI interrupt for device :01:03.0 disabled > > ACPI: PCI interrup

Re: MODULE_LICENSE usage

Hello Nathan, There has been a lot of discussion about this in the past. Read for example this thread: http://lkml.org/lkml/2006/12/13/370 This will probably clears some things up. Remy 2007/8/6, Nathan Williams <[EMAIL PROTECTED]>: > Hi, > > I'm working on a driver for an ADSL modem which requi

[PATCH (updated)]: PTHREAD_PRIO_INHERIT support for ARM.

lease apply. Kind Regards, Remy Böhmer PTHREAD_PRIO_INHERIT support for ARM. This patch implements the futex_atomic_cmpxchg_inatomic() for the ARM architecture. Without this patch the userland PI mutex will not work. Signed-off-by: Remy Bohmer <[EMAIL PROTECTED]> --- # include/asm-arm/fut

Re: [Question] Hooks for scheduler tracing (CFS)

, Arjan van de Ven <[EMAIL PROTECTED]>: On Mon, 2007-07-16 at 21:46 +0200, Remy Bohmer wrote: > So I was wondering if anybody knows some tool/kernel mechanism which > can do this? > If not, I will build a kernel extension for it myself (new extension > to 'latency_trace'

[Question] Hooks for scheduler tracing (CFS)

Hello, I am looking for some tool/kernel machanism that enables me to track every schedule change on the CFS scheduler of the RT-kernel for some period of time. Thus a tool that gives me an overview after some time which task got "scheduled in/out" at "which timestamp" and at "which CPU". ( I nee

Re: v2.6.22.1-rt3

Thomas, http://www.tglx.de/projects/preempt-rt/2.6.22.1 This is a dead link... It should be: http://www.tglx.de/projects/preempt-rt/2.6.22.1-rt3/ Remy more info about the -rt patchset can be found in the RT wiki: http://rt.wiki.kernel.org This release is bugfix release: - update of

Re: PI mutex support on ARM

Hello Ingo, patch format problem: never diff the asm/ files, diff the asm-arm/ files. Yeah, of course, I know, I believe I made a real mess of this one ... is it safe to do a get_user() with irqs off? rhetorical question ;-)) I was wondering, Is it safe to use a normal spinlock here, like th

PI mutex support on ARM

Hello Thomas, I have build an implementation for the routine futex_atomic_cmpxchg_inatomic() to make PTHREAD_PRIO_INHERIT mutex work on ARM. Compared to other architectures where CPU specific assembler is used, it is probably not the most optimal implementation possible, but I tested it successfu

Userland PI-futex does not work on ARM (2.6.21.5-rt18)

Hello All, I am using the 2.6.21.5-rt18 kernel on the ARM core Atmel at91rm9200 together with a Glibc 2.5+GCC4.2.0 toolchain, and I found out that the userland PI futexes (configured with PTHREAD_PRIO_INHERIT) do not work. What happens is: * Thread A claims the mutex, and gets the lock. * Thread

[PATCH]: Make LEDS work on evaluation board AT91SAM9261-EK

patch to the kernel mainline? Kind Regards, Remy Bohmer diff -ruN linux-2.6.21.orig/arch/arm/mach-at91/board-sam9261ek.c linux-2.6.21/arch/arm/mach-at91/board-sam9261ek.c --- linux-2.6.21.orig/arch/arm/mach-at91/board-sam9261ek.c 2007-05-04 15:51:34.0 +0200 +++ linux-2.6.21/arch/arm/mach-at

Re: gtod/clocksource/clockevents documentation

Hello David, > But, unfortunately, I have some problems with compiling the kernel, as > this patch does not enable CONFIG_GENERIC_TIME, while the patch you > published earlier did. I'm not sure which patch you mean. I tested only in conjunction with updates specific to the at91rm9200. To be

Re: gtod/clocksource/clockevents documentation

cct.c:(.text+0x1fd3c): undefined reference to `warp_check_clock_was_changed' Kind Regards, Remy Böhmer 2007/4/22, David Brownell <[EMAIL PROTECTED]>: On Saturday 21 April 2007, Remy Bohmer wrote: > Hello All, > > I need to implem

gtod/clocksource/clockevents documentation

Hello All, I need to implement a gtod/clocksource/clockevents implementation for the Atmel ARM AT91SAM9261 CPU, and I am looking for some kernel (interface) documentation about these mechanisms. I already investigated the 'examples'/implementations of other architectures in the kernel, but that

[UPDATE] bigphysarea patch update for i386 and x86_64

to make it compile against the stock 2.6.20.1 kernel. Kind Regards, Remy Bohmer bigphysarea-i386-x86-64.tgz Description: GNU Zip compressed data

Re: IRQ Sharing

other devices I have made the choice to close down 1 USB controller that shared the interrupt with my IO-board. USB still works in my case, but 1 onboard controller/connector is dead) Kind Regards, Remy 2007/2/6, Jorge Almeida <[EMAIL PROTECTED]>: Em Tuesday, 6 de February de 2007 18:43,

Re: IRQ Sharing

Hello Jorge, It is not uncommon that interrupt lines are hardwired to each other on a standard PC-board. Therefor it is not always feasible to get rid of interrupt sharing. Especially on-board USB adapters can easily use up to 5 interrupt lines on a standard main-board. Also, sharing of interrupt

Re: [ OOPS ] at do_futex with 2.6.20-RC5-RT10

Hello Henri, I have seen similar problems... I do not know yet what caused it... Remy 2007/1/30, Henri Hunnekens <[EMAIL PROTECTED]>: Dear Ingo, I've an made an application which causes an OOPS using kernel version 2.6.20-RC5-RT10 ( also seen with older verison 2.6.19.1-rt15 ) + FC6 userland.

Fwd: [OOPS] on 2.6.20-rc5-rt10

-- Forwarded message -- From: Remy Bohmer <[EMAIL PROTECTED]> Date: 30 jan 2007 16:49 Subject: Re: [OOPS] on 2.6.20-rc5-rt10 To: Michal Schmidt <[EMAIL PROTECTED]> Hello Michal, This cap_over driver is a capability driver to give certain processes extra capabilities

[OOPS] on 2.6.20-rc5-rt10

Hello All, Once in a while we see the following stacktrace. We do not know yet the exact condition that generates this, but is there anyone that recognises this oops? Kind Regards, Remy Bohmer Jan 30 14:09:20 localhost kernel: BUG: unable to handle kernel paging request at virtual address

Re: [BUG-RT] RTC has been stopped-> long delay during boot, soft reboot->GRUB fails to call getrtsecs()

for me. Thanks to you all. FYI: Attached I have put the differences I had to make to make it work. Kind Regards, Remy Bohmer 2007/1/5, Remy Bohmer <[EMAIL PROTECTED]>: Hello Dries, Thanks for your reply, but as it looks a lot like the same problem, I want to mention that we do NOT have

Re: [BUG-RT] RTC has been stopped-> long delay during boot, soft reboot->GRUB fails to call getrtsecs()

Hello Dries, Thanks for your reply, but as it looks a lot like the same problem, I want to mention that we do NOT have a Dell system here. It is a Fujitsu Siemens i945 motherboard. I also saw the problem about "long delays during boot by hwclock" on an old i845 Kontron Motherboard, running the sa

Re: [BUG-RT] RTC has been stopped-> long delay during boot, soft reboot->GRUB fails to call getrtsecs()

called for the first time by the init scripts, directly after kernel boot. Every sub sequential call to hwclock show normal times like your measurement. Best Regards and also a Happy New Year, Remy 2007/1/2, Ingo Molnar <[EMAIL PROTECTED]>: * Remy Bohmer <[EMAIL PROTECTED]> wrote:

[BUG-RT] RTC has been stopped-> long delay during boot, soft reboot->GRUB fails to call getrtsecs()

herwise it is probably not allowed to execute this command during normal runtime) Kind Regards, Remy Bohmer kernel-i686.config Description: Binary data

[BUG+PATCH] RT-Preempt: IRQ threads running at prio 0 SCHED_OTHER

Hello Ingo, I am using your yum-distributed kernel 2.6.19.1-rt15, and unfortunately I experienced very worse latencies. It turned out that ALL the IRQ threads were all running at prio 0, SCHED_OTHER. Looking at the current code in kernel/irq/manage.c, the goal was to put them at MAX_RT_PRIO, but

Re: [BUG] 2.6.19-rt14 does not compile with CONFIG_NO_HZ

Hello Ingo, -rt15 is indeed better... Thanks! Remy 2006/12/16, Ingo Molnar <[EMAIL PROTECTED]>: * Remy Bohmer <[EMAIL PROTECTED]> wrote: > Hello, > > For your Information, I get the following compile error when > CONFIG_NO_HZ is NOT configured on 2.6.19.1-rt14: do