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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3efb10970801300305g693a8371u36011426d3a13b3e@mail.gmail.com>
Date:	Wed, 30 Jan 2008 12:05:40 +0100
From:	"Remy Bohmer" <linux@...mer.net>
To:	"Haavard Skinnemoen" <hskinnemoen@...el.com>
Cc:	michael <trimarchi@...dalf.sssup.it>, fabio@...dalf.sssup.it,
	"Andrew Victor" <linux@...im.org.za>,
	"Chip Coldwell" <coldwell@...hat.com>,
	"Marc Pignat" <marc.pignat@...s.ch>,
	"David Brownell" <david-b@...bell.net>,
	linux-kernel@...r.kernel.org, "Alan Cox" <alan@...rguk.ukuu.org.uk>
Subject: 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 latest set of patches, and try to find
> > any regressions. Do you have a location somewhere where I can download
> > the latest versions? Or do I need to dig through LKML to find the
> > latest... ;-)
> They are in -mm. You were Cc'ed I think...

Yes, I saw them, but I did not know if there were any updates in the
mean time, because I had seen some discussions, which confused me a
bit about the current status of the complete set.

> - with full preemption  it runs but the serial line can't be used for
> receiving at high bit rate (using lrz)

A few questions arise here to me:
* What serial port is used here? (DBGU, or something else)
* No DMA was used, was flow-control enabled? (cannot with DBGU)
* If some other UART, why not using DMA?

Notice that the DBGU has no flow control, and just a 1 byte FIFO (thus
no fifo at all).
At high speeds (e.g. >=115200) it is _likely_ that you will miss
characters, nothing can prevent that. DBGU should only be used at
lower speeds, or just as text console. 115200 is running fine here as
text-console.
I would not expect that the behaviour is worse than without the
patchset, because without it it does not work at all on Preempt-RT,
but also: there was done much more in interrupt context previously, so
the chance of buffer overruns was much more likely in the old
situation.
The real interrupt handler (doing the reading from the fifo) must be
as short as possible, to be able to keep up with the data flow.

A simple calculation: 115200bps results in approx. 11520 bytes per second.
This means that the interrupt handler must be capable of handling each
byte on DBGU within 87us. With a worst case interrupt latency of about
85us, and average between 2us and 54us (on Preempt-RT and AT91RM9200),
you can simply understand that this will not match, how good/fast the
interrupt handling will ever be.

So, I suggest to either use flow-control, or DMA for bulkdata... (thus not DBGU)

Kind Regards,

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