DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=ZP3dvq9hAkcf4TLeOgs3NAtQX38V+W5vJv5dFhfRryGnNoIJ/9iJiW9GtDB4FDEHnWdiJ0qbwdRMwyGrY6uU5q68D/qby7s4PGcO3V2AZYVhZEkMVBtjaNNlsTKoucnLcJMannbFlEw+RNXpVLuX/C7ntJGBPiLbq6JwbywmGYQ=
Message-ID: <3efb10970802041144j6b4e6893j293819238b5b82e8@mail.gmail.com>
Date: Mon, 4 Feb 2008 20:44:51 +0100
From: "Remy Bohmer" <linux@bohmer.net>
To: "Haavard Skinnemoen" <hskinnemoen@atmel.com>
Subject: Re: [PATCH -mm v4 6/9] atmel_serial: Split the interrupt handler
Cc: michael <trimarchi@gandalf.sssup.it>, fabio@gandalf.sssup.it,
       "Andrew Victor" <linux@maxim.org.za>,
       "Chip Coldwell" <coldwell@redhat.com>,
       "Marc Pignat" <marc.pignat@hevs.ch>,
       "David Brownell" <david-b@pacbell.net>, linux-kernel@vger.kernel.org,
       "Alan Cox" <alan@lxorguk.ukuu.org.uk>
In-Reply-To: <20080204133925.73733f5f@dhcp-252-066.norway.atmel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20080129224316.GA23155@gandalf.sssup.it>
	 <20080130104113.48ec376f@dhcp-252-066.norway.atmel.com>
	 <47A051A7.7030004@gandalf.sssup.it>
	 <20080130133659.55ebd828@dhcp-252-066.norway.atmel.com>
	 <47A09723.7020000@gandalf.sssup.it>
	 <20080130164631.7de4f6bd@dhcp-252-066.norway.atmel.com>
	 <47A12A2E.5040309@gandalf.sssup.it>
	 <20080131160721.6dddf30e@dhcp-252-066.norway.atmel.com>
	 <3efb10970801311136y12670f12x6e4fdd44de3677b9@mail.gmail.com>
	 <20080204133925.73733f5f@dhcp-252-066.norway.atmel.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1206
Lines: 28

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
running in thread context, even tasklets, softirqs etc. They are _all_
preemptible, and if Michael has some RT-thread in the system that has
a higher priority than this tasklet or softirq, than the buffer will
eventually overflow.
I wonder also if Michael has set the RT-priorities correctly, on RT
_every_ softirq/irq thread starts by default on priority 50,
SCHED_FIFO. If they are still at 50, any other softirq/tasklet, or irq
can make this behavior worse.
Notice that the default 50 thingy rarely gives a decent behaving
system. (But any other default will also give problems anyway, so it
_has_ to be customized/tuned by the end user)

Kind Regards,

Remy
--
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/