* Re: swapping and oom-killer: gfp_mask=0x201d2, order=0
From: Mike Galbraith @ 2006-05-12 15:31 UTC (permalink / raw)
To: Al Boldi; +Cc: linux-kernel
In-Reply-To: <200605121517.59988.a1426z@gawab.com>
On Fri, 2006-05-12 at 15:17 +0300, Al Boldi wrote:
> Note that this is not specific to mem=8M, but rather a general oom
> observation even for mem=4G, where it is only much later to occur.
An oom situation with 4G ram would be more interesting than this one.
-Mike
^ permalink raw reply
* Re: [LARTC] HTB at 100+ Mbits/sec
From: Muthukumar S @ 2006-05-12 15:32 UTC (permalink / raw)
To: lartc
In-Reply-To: <d5c845ac0605101239r384bd499r58cc6f4571e7136b@mail.gmail.com>
I'll try using 450 K and setting a higher ceil to see how it works.
Also I was wondering what limits (if any) the kernel timer resolution
imposes on HTB.
Thanks!
Muthu
On 5/11/06, Jody Shumaker <jody.shumaker@gmail.com> wrote:
> On 5/10/06, Muthukumar S <muthukumar@gmail.com> wrote:
> > First up, thanks for the response Jody. I appreciate your taking the
> > time to answer.
> >
> > So in essence what this means is that I will not be able to use the
> > maximum that the link allows if I'm shaping traffic? Please correct me
> > if I got this wrong - let's say my ISP claims 512 Kbit/s upload and
> > real throughput varies between 450 Kbit/s and 500 Kbit/s. So if I
> > shaped traffic using 450 Kbit/s as the root qdisc, I would lose out on
> > the occasions when the line does allow more than 450 Kbit/s?
> >
>
> Unfortunately yes, if you want the shaping to work well you need to
> set it appropiately. No real way to have it vary dynamically.
> Basically what happens when you're not the bottleneck is that ping
> times will go up as data will queue at the other bottleneck, and your
> bandwidth allotments will no longer accurately represent the
> connection. They'll have less of an effect as TCP throttling starts
> having to kick in.
>
> I imagine if you designed the rules you could have the ratio between
> your classes still honored, and only have the increased lag or
> possibility for packet loss. To do this if you knew it was always
> atleast 450k but sometimes 500k, set the rates for all the child
> classes to add up to 450k, but use 500k as the highest ceiling and
> for the base class. Then in this case it should still continue to
> split the 450k evenly between the classes as you described, but still
> using up to the 500k when its available. Not sure how well this would
> work though as I've usually been more concerned with keeping the
> latency down, and set the ceil such that the majority of the time its
> slightly below the real bandwidth.
>
> - Jody
>
> P.S. Thanks for forwarding the email to the list, I alway forget to
> hit reply to all.
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [PATCH] XATTR support on JFFS2 (version. 5)
From: Jörn Engel @ 2006-05-12 15:32 UTC (permalink / raw)
To: KaiGai Kohei
Cc: jmorris, KaiGai Kohei, russell, linux-mtd, lorenzo,
Thomas Gleixner, David Woodhouse, sds
In-Reply-To: <4464A7B1.4070605@kaigai.gr.jp>
On Sat, 13 May 2006 00:20:17 +0900, KaiGai Kohei wrote:
>
> OK, I'll pay attention to attach 'JFFS2' to the subject.
> But nine of previous patches which have been already commited did not
> attach such a keyword. Is it necessary to update the subject of them ?
> (But I don't know how to operate for this. Hmm...)
Quite likely, the easiest way would be to work with two scripts. One
to convert a git tree into a quilt series and another to convert the
quilt series back into a git tree.
Advantage of quilt is the ease with which one can cherry-pick patches,
change patches or descriptions, reorder patches, rebase them for a new
kernel, etc.
I believe tglx (added to Cc:) has some scripts like that. And since
many kernel hacker have similar needs, google should find even more.
[ Note to self: I need them as well. ]
Jörn
--
This above all: to thine own self be true.
-- Shakespeare
^ permalink raw reply
* Re: [ANNOUNCE] libata: new EH, NCQ, hotplug and PM patches against stable kernel
From: Mikael Pettersson @ 2006-05-12 15:34 UTC (permalink / raw)
To: htejun, linux-ide, linux-kernel
On Fri, 12 May 2006 22:24:37 +0900, Tejun Heo wrote:
>The following drivers support new features.
>
>ata_piix: new EH, irq-pio, warmplug (hardware restriction)
>sata_sil: new EH, irq-pio, hotplug
>ahci: new EH, irq-pio, NCQ, hotplug
>sata_sil24: new EH, irq-pio, NCQ, hotplug, Port Multiplier
If you were to add new EH and NCQ support to sata_promise,
then I'd test it on my News server.
/Mikael
^ permalink raw reply
* Re: [LARTC] HTB at 100+ Mbits/sec
From: Muthukumar S @ 2006-05-12 15:35 UTC (permalink / raw)
To: lartc
In-Reply-To: <d5c845ac0605101239r384bd499r58cc6f4571e7136b@mail.gmail.com>
> Iperf has a demonstrated behavior that when running more than one copy at the
> same time on the same box (client side); that the timing of each will
> start to effect
> the other copies. This is a function of how Iperf does it's timing
> (spin loops).
What traffic generators would you recommend? What do other members
use? Has anyone used TG (http://www.postel.org/tg/)?
Thanks!
- Muthu
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [ALSA - driver 0002106]: Sound card snd-hda-intel emits NO sound
From: bugtrack @ 2006-05-12 15:36 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2106>
======================================================================
Reported By: louisvd
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2106
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Fedora Core 5
Kernel Version: 2.6.16-1.2111_FC5smp
======================================================================
Date Submitted: 05-08-2006 21:00 CEST
Last Modified: 05-12-2006 17:36 CEST
======================================================================
Summary: Sound card snd-hda-intel emits NO sound
Description:
Hi
I was merrily running Fedora Core 4 and after upgrading the kernel to
2.6.16 my sound no longer worked under Linux (it works under Windows).
After a lot of battling I figured I may as well upgrade to FC5 now. A
clean install, out of the box, and the sound STILL did not work. I've
applied every available patch to date and no luck. Tonight I installed
the Alsa 1.0.11 driver, lib and util tarballs -- all installed
successfully -- but there is STILL no sound produced.
Everything LOOKS normal. There are no errors that I can detect. In the X
and console versions of Alsamixer I have ALL the devices displayed and
unmuted with the volumes at max. I've removed the sound lines from
modprobe.conf and am running with alsasound and that didn't help either --
even though it says the driver has been loaded.
FYI, the OSS Volume control calls it a Realtek ALC260. lspci refers to it
as Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller
(rev 01).
Please help.
======================================================================
----------------------------------------------------------------------
louisvd - 05-12-06 17:18
----------------------------------------------------------------------
Ah, thanks. ALMOST there now.
I updated my /etc/modprobe.conf file to this:
alias eth0 tg3
alias scsi_hostadapter ata_piix
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0
options snd-hda-intel model=auto
remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-hda-intel
I now get sound out of the "Front" slider. This is the Internal Mono
speaker inside the PC.
I have external PC speakers plugged into the sound out plug at the rear of
the PC. This channel is NOT playing any sound.
Help me fix that and we can close the call.
Thanks for the help so far.
----------------------------------------------------------------------
tiwai - 05-12-06 17:36
----------------------------------------------------------------------
You should write only one "options snd-hda-intel" line. The first one is
overridden.
As mentioned, try different model option values as found in
ALSA-Configuration.txt. For example, model=hp. If none of them matches
properly with yours, we'll need to create another model.
In the case of ALC260, you can use model=test when the drivers are
compiled with debug option (--with-debug=full configure option). It will
allow you to tune almost everything on the codec chip. Figure out which
pin and configuration matches with the actual I/O by trial-and-error.
Issue History
Date Modified Username Field Change
======================================================================
05-08-06 21:00 louisvd New Issue
05-08-06 21:00 louisvd Distribution => Fedora Core 5
05-08-06 21:00 louisvd Kernel Version => 2.6.16-1.2111_FC5smp
05-10-06 16:16 tiwai Note Added: 0009722
05-10-06 16:52 louisvd Note Added: 0009731
05-10-06 16:55 tiwai Note Added: 0009732
05-10-06 20:02 louisvd Note Added: 0009751
05-12-06 00:40 louisvd Note Added: 0009770
05-12-06 10:31 UMMO Issue Monitored: UMMO
05-12-06 16:11 tiwai Note Added: 0009778
05-12-06 17:18 louisvd Note Added: 0009782
05-12-06 17:36 tiwai Note Added: 0009783
======================================================================
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: 3c59x vortex_timer rt hack (was: rt20 patch question)
From: Steven Rostedt @ 2006-05-12 15:36 UTC (permalink / raw)
To: Andrew Morton; +Cc: mingo, markh, linux-kernel, dwalker, tglx
In-Reply-To: <20060512082340.3e169128.akpm@osdl.org>
On Fri, 12 May 2006, Andrew Morton wrote:
>
> Well, only if the hardware's fratzed. Normally this is quick.
>
> otoh vortex_timer() will play with the MII interface, which is slooooow.
>
The vortex_timer is a timeout, will it go off often?
-- Steve
^ permalink raw reply
* Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
From: Dan Sandberg @ 2006-05-12 15:36 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20060512132601.GB25118@mail.shareable.org>
Jamie Lokier wrote:
>Dan Sandberg wrote:
>
>
>>Creating a rectangular direct output area in OpenGL is actually like
>>vitualizing a graphics card.
>>
>>
>
>That is what X's XF86DGA ("Direct Graphics Adapter") feature does.
>And I believe SDL already supports XF86DGA when in full screen mode.
>
>
>
>>It is updated at native speed
>>
>>
>
>Not necessarily. When I tried using mplayer (a video player) with the
>video output set to use OpenGL, it was the slowest of all options -
>even slower than writing the images though X11 shared memory with a
>copy-to-screen bitblt for each frame.
>
>But then, OpenGL drivers vary considerably in their performance and quality.
>
>
>
>>and you can select pixelformat for that
>>area independent of the host pixel format and you do not have to be
>>doing any RectangleBlit operation or causing any CPU-load - to my
>>understanding at least.
>>
>>
>
>Well, OpenGL does a RectangleBlit each time it redraws the 3d
>rendering area, doesn't it? If you have hardware accelerated OpenGL
>support, that shouldn't use much CPU. But then, the same is true for
>old-fashioned hardware accelerated 2d bitblt, if the pixel format is
>supported.
>
>
>
>>[...] I am not saying that any of todays possibilities in Qemu
>>should be retired, rather that it could be sort of a new plug-in
>>module for those who want a virtual display adapter with close to
>>native graphic performance and happen to have what is needed in
>>terms of graphic card and drivers.
>>
>>
>
>I agree it's worth a look, because it may be faster for some people,
>and because it provides access to image scaling (potentially hardware
>assisted), which classic X11 bitblt does not.
>
>It might be worth looking at mplayer's OpenGL driver, which does
>something similar to what Qemu would need.
>
>Other X features which can do similar things and may provide equal or
>better performance are: Xv (used to display video, but generally
>provides a resizable overlay; may or may not provide a usable pixel
>format), and Xrender.
>
>-- Jamie
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
Yes, in the worst case the OpenGL-driver is all software emulation and
then it is slow and CPU-consuming.
It may also be that some old OpenGL-drivers have to emulate a direct
output area by bitblt operations from an off-screen buffer to the
on-screen buffer and then there will be no gain, I agree.
But technically that's not the only way to do the trick and newer boards
should be capable of doing it much smarter without any bitblt operations
involved.
I still remember my old favorite, the Amiga computer with its unique
virtual screens that allowed multiple programs to coexist in the same
physical screen, each with its own display buffer, pixel format and all
rendering in full speed. That was never done by bitblt-operations,
instead much smarter by synchronized on-the-fly switching between
multiple display buffers as the electron beam painted the screen.
Lets say that you want to set up a 800x600 direct output rectangle with
BGR-pixel format inside a 1600x1200 RGB host screen on a modern card
with an adequate OpenGL driver.
When the screen is "painted" the DAC's read from the host video buffer
(1600x1200) and interpret it as RGB. Somewhere they "hit" the left
boundary of the separate viewport that you have set up and bang, on the
fly they switch to reading 800x600-organized data from the other video
buffer and interpreting it as BGR. Later on the same video line they
"hit" the right boundary of the separate viewport and bang they switch
back to reading from the main buffer and interpreting it as RGB.
As a result the 1600x1200 RGB buffer and the 800x600 BGR buffer are
equally active and equally often updated on the same physical screen -
without need for any moving data around, and without any time consuming
activity at all taking place as all switches are done on the fly in the
background by special hardware (if the board supports this).
It is like having two separate physical video boards, each with its own
display buffer.
Regards
Dan
^ permalink raw reply
* Re: [PATCH] XATTR support on JFFS2 (version. 5)
From: David Woodhouse @ 2006-05-12 15:38 UTC (permalink / raw)
To: KaiGai Kohei
Cc: jmorris, KaiGai Kohei, russell, linux-mtd, lorenzo, sds,
Jörn Engel
In-Reply-To: <4464A7B1.4070605@kaigai.gr.jp>
On Sat, 2006-05-13 at 00:20 +0900, KaiGai Kohei wrote:
> Sorry, it's translated by terminal emulator automatically.
> The patch keeps consistency of tabs in the indenting.
OK, that's good.
> OK, I'll pay attention to attach 'JFFS2' to the subject.
> But nine of previous patches which have been already commited did not
> attach such a keyword. Is it necessary to update the subject of them ?
> (But I don't know how to operate for this. Hmm...)
It is possible, I think -- the 'cg-admin-rewritehist' tool in Cogito
allows it. Alternatively, it's easy enough to cherry-pick patches from
git and apply them to a new branch, then make that new branch your
'master'. If you do this, remember to push with the '--force' option so
that your new tree overwrites the remote.
If you like, we can leave the XATTR tree as it is, and import it as a
patch instead of with git-pull. Then the history doesn't matter.
--
dwmw2
^ permalink raw reply
* [PATCH] Input: ads7846: fix byteorder in the filtering logic
From: Imre Deak @ 2006-05-12 15:38 UTC (permalink / raw)
To: Dmitry Torokhov, Tony Lindgren; +Cc: omap-linux
The BE->CPU conversion must be done also in the filtering logic.
Signed-off-by: Imre Deak <imre.deak@nokia.com>
Index: linux-2.6/drivers/input/touchscreen/ads7846.c
===================================================================
--- linux-2.6.orig/drivers/input/touchscreen/ads7846.c 2006-05-12 18:30:38.000000000 +0300
+++ linux-2.6/drivers/input/touchscreen/ads7846.c 2006-05-12 18:35:02.000000000 +0300
@@ -471,7 +471,7 @@ static void ads7846_debounce(void *ads)
m = &ts->msg[ts->msg_idx];
t = list_entry(m->transfers.prev, struct spi_transfer, transfer_list);
- val = (*(u16 *)t->rx_buf) >> 3;
+ val = (be16_to_cpu(*(__be16 *)t->rx_buf) >> 3) & 0x0fff;
if (!ts->read_cnt || (abs(ts->last_read - val) > ts->debounce_tol)) {
/* Repeat it, if this was the first read or the read
* wasn't consistent enough. */
^ permalink raw reply
* Re: [ANNOUNCE] libata: new EH, NCQ, hotplug and PM patches against stable kernel
From: Chris Boot @ 2006-05-12 15:42 UTC (permalink / raw)
Cc: Tejun Heo, kernel list
In-Reply-To: <44649CE1.4060407@bootc.net>
Chris Boot wrote:
> Tejun Heo wrote:
>> Patches against v2.6.16.16 is avaialbe at the following URL.
>>
>> http://home-tj.org/files/libata-tj-stable/libata-tj-2.6.16.16-20060512.tar.bz2
>>
>>
>> Please read README carefully before testing the patches. Keep in mind
>> that these are still quite experimental and not ready for production
>> use.
>
> Are these patches likely to work alongside Alan's PATA patches?
> Specifically I have a DVD-RW and an IDE tape that I'd like to use.
I'll answer my own question: this fails miserably!
I'll test 'em anyway, screw the DVD and tape for now. :-P
Chris
--
Chris Boot
bootc@bootc.net
http://www.bootc.net/
^ permalink raw reply
* Re: git-bisect failed me again
From: Linus Torvalds @ 2006-05-12 15:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: junkio, git
In-Reply-To: <20060512081207.6cd701f9.akpm@osdl.org>
On Fri, 12 May 2006, Andrew Morton wrote:
>
> Linus Torvalds <torvalds@osdl.org> wrote:
> >
> > Anyway, my first guess would be that you might have marked something good
> > or bad that wasn't. How sure are you about that initial "git bisect bad"
> > you did?
>
> Am pretty confident.
And I'm pretty damn sure it ain't.
Andrew, git is _not_ linear. You can't just list the commits, take the
last and the first, and say "the last must be bad, the first must be
good". Which seems to be what you did.
>
>
> bix:/usr/src/25> grep '^commit ' patches/git-acpi.patch
> commit 9011bff4bdc0fef1f9a782d7415c306ee61826c9 <- This was my `bad'
> commit 5d882e684aafea30c508d86d235327d94e1d38ae
> commit 14394600cdfe0c952ce662a32a68c5c5524d32ac
> commit da95181baf3cf6a2bd81c0c8af1d4c6790703e4f
> commit b128440ed11d108c375772b7fe9ad46d2ac07084 <- This was the bug
That "b128440e.." commit wasn't even among the collection of commits that
you tested with "git bisect" in the first place.
You've apparently created a "list of commits" that doesn't include any
merges, and then you decided that the "most recent of those commits was
obviously bad".
WHICH IS NOT TRUE.
You never actually even TESTED that 9011bff commit, did you? In fact, I'm
100% sure you didn't. You just said "it's bad", without any confidence
what-so-ever except that it happened to be first on your list.
Right?
The fact is, it seems that the way you generated the list of commits was
basically:
- pick every commit that is not a merge and doesn't exist in linus tree.
(ie you basically did the equivalent of "git-rev-list --no-merges
linus..acpi", although it's possible that you used "git whatchanged" or
something else that will not show merges because they don't generate
diffs)
And then you believed that you had a linear series of commits, and that
the most recent commit must thus be the buggy one.
But git isn't linear. Never has been. The fact that commits get (roughtly)
sorted by date (modified by their ancestry relationships either subtly or
grossly depending on whether --topo-sort is off or on) does not make
anything linear.
The commit you mark as "this was the bug" is on a totally different
development branch from the one you marked "bad". That development branch
was merged with the branch that your "bad" commit came from with commit
7378614.. (which is not on your list at all):
"Pull bugzilla-5737 into test branch"
but there are actually a few other merges there too (and ACPI-only commits
that aren't reachable from your "top" bad commit).
> and git-bisect claimed that 9011bff4bdc0fef1f9a782d7415c306ee61826c9
> introduced the bug.
Hell no. Git bisect did no such thing at all. YOU DID.
Go back and look at what your sequence of instructions was (from your
original email):
->> Trying to find a recently-merged box-killer in Len's tree:
->>
->> bix:/usr/src/git26> cat .git/branches/git-acpi
->> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test
->>
->> git-checkout git-acpi
->> git-bisect reset
->> git-bisect start
->> git-bisect good ff2fc3e9e3edb918b6c6b288485c6cb267bc865e
->> git-bisect bad 9011bff4bdc0fef1f9a782d7415c306ee61826c9
->>
->> And it led me to
and notice how YOU claimed that "9011bff4.." was bad at the very
beginning of the "git bisect" run. Not "git bisect". YOU. You started off
by claiming that 9011bff4 was bad, apparently without having ever even
tested it.
The way "git bisect" works is that if you give it garbage information, it
_will_ give you a garbage result. That's pretty much guaranteed. But if
you actually give it tested and correct information, it will very
efficiently zero in on what the problem really was.
And the whole _point_ about "git bisect" is that the git history isn't
linear. If it was linear, you wouldn't need a tool to bisect it at all:
you'd just pick the middle entry from the history list, and use it. It
would be so trivial to bisect by hand, that using a tool is just
unnecessary.
So really, take a look at "git bisect visualize". In this case, you should
have noticed that you had a list of 50+ commits, but when you did
git bisect good ff2fc3e
git bisect bad 9011bff
git bisect visualize
you had cut your list of commits down to just six (none of which was the
bug).
This is why I integrated "gitk" immediately when it became available. It's
really important to see the non-linear history, because if you don't
visualize it (either mentally or with a tool like "gitk"), you'll never
understand what is going on.
Linus
^ permalink raw reply
* Re: [PATCH 2/9] nsproxy: incorporate fs namespace
From: Dave Hansen @ 2006-05-12 15:44 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Eric W. Biederman, Andi Kleen, linux-kernel, herbert, dev, sam,
xemul, clg, frankeh
In-Reply-To: <20060512152412.GA11734@sergelap.austin.ibm.com>
On Fri, 2006-05-12 at 10:24 -0500, Serge E. Hallyn wrote:
>
> - exit_utsname(current);
> - exit_namespace(current);
> - exit_nsproxy(current);
> + exit_task_namespaces(current);
> current->nsproxy = init_task.nsproxy;
> - get_nsproxy(current->nsproxy);
> - get_namespace(current->nsproxy->namespace);
> - get_uts_ns(current->nsproxy->uts_ns);
> + get_namespaces(current);
That really cleans up the main path quite a bit. Very nice.
For parity with exit_task_namespaces(), should that be called
get_task_namespaces()?
-- Dave
^ permalink raw reply
* [PATCH] oprofile: Fix unnecessary cleverness
From: Markus Armbruster @ 2006-05-12 15:49 UTC (permalink / raw)
To: linux-kernel
nmi_create_files() in arch/i386/oprofile/nmi_int.c depends on
model->num_counters (number of performance counters) being less than
10. While this is currently the case, it's too clever by half.
Other archs aren't quite as clever: they assume 100. I suggest to
normalize them all to 1000.
diff -r ddba92a5cba9 arch/i386/oprofile/nmi_int.c
--- a/arch/i386/oprofile/nmi_int.c Tue May 09 12:41:38 2006 +0200
+++ b/arch/i386/oprofile/nmi_int.c Fri May 12 17:45:25 2006 +0200
@@ -281,9 +281,9 @@ static int nmi_create_files(struct super
for (i = 0; i < model->num_counters; ++i) {
struct dentry * dir;
- char buf[2];
-
- snprintf(buf, 2, "%d", i);
+ char buf[4];
+
+ snprintf(buf, sizeof(buf), "%d", i);
dir = oprofilefs_mkdir(sb, root, buf);
oprofilefs_create_ulong(sb, dir, "enabled", &counter_config[i].enabled);
oprofilefs_create_ulong(sb, dir, "event", &counter_config[i].event);
diff -r ddba92a5cba9 arch/alpha/oprofile/common.c
--- a/arch/alpha/oprofile/common.c Tue May 09 12:41:38 2006 +0200
+++ b/arch/alpha/oprofile/common.c Fri May 12 17:45:25 2006 +0200
@@ -112,7 +112,7 @@ op_axp_create_files(struct super_block *
for (i = 0; i < model->num_counters; ++i) {
struct dentry *dir;
- char buf[3];
+ char buf[4];
snprintf(buf, sizeof buf, "%d", i);
dir = oprofilefs_mkdir(sb, root, buf);
diff -r ddba92a5cba9 arch/mips/oprofile/common.c
--- a/arch/mips/oprofile/common.c Tue May 09 12:41:38 2006 +0200
+++ b/arch/mips/oprofile/common.c Fri May 12 17:45:25 2006 +0200
@@ -38,7 +38,7 @@ static int op_mips_create_files(struct s
for (i = 0; i < model->num_counters; ++i) {
struct dentry *dir;
- char buf[3];
+ char buf[4];
snprintf(buf, sizeof buf, "%d", i);
dir = oprofilefs_mkdir(sb, root, buf);
diff -r ddba92a5cba9 arch/powerpc/oprofile/common.c
--- a/arch/powerpc/oprofile/common.c Tue May 09 12:41:38 2006 +0200
+++ b/arch/powerpc/oprofile/common.c Fri May 12 17:45:25 2006 +0200
@@ -93,7 +93,7 @@ static int op_powerpc_create_files(struc
for (i = 0; i < model->num_counters; ++i) {
struct dentry *dir;
- char buf[3];
+ char buf[4];
snprintf(buf, sizeof buf, "%d", i);
dir = oprofilefs_mkdir(sb, root, buf);
diff -r ddba92a5cba9 arch/sh/oprofile/op_model_sh7750.c
--- a/arch/sh/oprofile/op_model_sh7750.c Tue May 09 12:41:38 2006 +0200
+++ b/arch/sh/oprofile/op_model_sh7750.c Fri May 12 17:45:25 2006 +0200
@@ -198,7 +198,7 @@ static int sh7750_perf_counter_create_fi
for (i = 0; i < NR_CNTRS; i++) {
struct dentry *dir;
- char buf[3];
+ char buf[4];
snprintf(buf, sizeof(buf), "%d", i);
dir = oprofilefs_mkdir(sb, root, buf);
^ permalink raw reply
* Re: BUG: soft lockup detected on CPU#0!
From: Winn Johnston @ 2006-05-12 15:51 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20060511180320.49788.qmail@web52901.mail.yahoo.com>
I noticed another post the other day, and contacted
the indavidual who posted it. note his message below.
Hi Winn,
Latest news i had was a *hint* from Andrew Morton
telling me to try with kernel 2.6.17-rc3 and report if
the problem was gone or not. I've had no
time to give it a try yet.Your problem seems similar
to mine, a few person argued that the message
was bogus and that no harm was done but i guess they
did not read carefully the post since the consequences
are pretty bad.
Let me know if you manage to try with the latest rc of
the 2.6.17 kernel and if things are better.
ref:
http://groups.google.com/group/linux.kernel/browse_thread/thread/450966ffa3043609/59e6a2350b7690bf?lnk=st&q=kernel%3A+ide%3A+failed+opcode+was%3A+0xea%22+BUG%3A+soft+lockup+detected+on+CPU%230!%22&rnum=1&hl=en#59e6a2350b7690bf
--- Winn Johnston <winn_johnston@yahoo.com> wrote:
> Error:
>
> kernel: hdi: drive_cmd: status=0xd0 { Busy }
> kernel: ide: failed opcode was: 0xea
> BUG: soft lockup detected on CPU#0!
>
> the odd thing is the system experiences a hard
> lockup,
> so it is not a false positive. I am working on a
> trace, but it is hard to get.
>
> My supervisor has asked me to help research this
> problem. We are using multiple ata cards in our
> backup
> machine. We have a Promiss sata 300tx4, and three
> ATA
> cards (3 SIG UltraATA 133 PCI) or (3 promise ultra
> 100tx2). We are experiencing hard lockups. The
> system
> resides on a scsi drive connected to the on board
> controler Adaptec AIC-7899P (Tyan S2462
> motherboard)the error is repeated for all drives
> connected to the promis cards, and the error
> continues
> until a lock up is eventualy reached.
>
> Also, its in dma mode, not pio.
> PREEMPT_NONE is already set, so its not the
> preemption
> model
>
> possibly related posts
>
http://www.ussg.iu.edu/hypermail/linux/kernel/0309.1/0444.html
>
>
http://groups.google.com/group/linux.kernel/browse_thread/thread/450966ffa3043609/59e6a2350b7690bf?lnk=st&q=kernel%3A+ide%3A+failed+opcode+was%3A+0xea%22+BUG%3A+soft+lockup+detected+on+CPU%230!%22&rnum=1&hl=en#59e6a2350b7690bf
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
> -
> 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/
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: mlock into kernel module
From: linux-os (Dick Johnson) @ 2006-05-12 15:52 UTC (permalink / raw)
To: sej.kernel; +Cc: linux-kernel
In-Reply-To: <4464A819.2050706@gmail.com>
On Fri, 12 May 2006, sej.kernel wrote:
> Hello,
> I need to use mlock and munlock function into a kernel module. How so
> I call this system call from my module ?
> I need to do this because I must use mlock in my software, but I can't
> use root or suser to start it. So mlock alwaays fail.
> Regards,
> sej
You don't call mlock from a module. You can lock down pages inside
your module by using non-paged RAM. This can be accessed from user-space
by implimenting mmap() in your module so that the user-code can
memory-map it. That way, the page(s) you have allocated in the
kernel are never swapped.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
New book: http://www.lymanschool.com
_
\x1a\x04
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
^ permalink raw reply
* Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
From: Jamie Lokier @ 2006-05-12 15:53 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <4464AB9B.9030107@medsci.uu.se>
Dan Sandberg wrote:
> When the screen is "painted" the DAC's read from the host video buffer
> (1600x1200) and interpret it as RGB. Somewhere they "hit" the left
> boundary of the separate viewport that you have set up and bang, on the
> fly they switch to reading 800x600-organized data from the other video
> buffer and interpreting it as BGR. Later on the same video line they
> "hit" the right boundary of the separate viewport and bang they switch
> back to reading from the main buffer and interpreting it as RGB.
>
> As a result the 1600x1200 RGB buffer and the 800x600 BGR buffer are
> equally active and equally often updated on the same physical screen -
> without need for any moving data around, and without any time consuming
> activity at all taking place as all switches are done on the fly in the
> background by special hardware (if the board supports this).
>
> It is like having two separate physical video boards, each with its own
> display buffer.
Thanks; I didn't know OpenGL had that function as well as 3d rendering.
That's what the Xv extension does ("X video") - it's to provide an
overlay to be used by video players. Xv scales the source image and
mixes it with the primary framebuffer in the way you describe.
However, Xv is intended for non-RGB colourspace source formats, so may
not be suitable for Qemu. I don't know if Xv sometimes can support RGB.
Since Xv is supported by many video cards, even old ones without 3d,
or without working 3d drivers, I'm surprised that particular OpenGL
function isn't commonly implemented with equal performance.
-- Jamie
^ permalink raw reply
* Re: skge driver oops
From: Stephen Hemminger @ 2006-05-12 15:53 UTC (permalink / raw)
To: David Arnold; +Cc: netdev
In-Reply-To: <861.1147397784@d.0x1.org>
On Fri, 12 May 2006 11:36:24 +1000
"David Arnold" <david@mantara.com> wrote:
> i've been getting semi-regular lockups on my machine over 2.6.16
> series. I recently attached a serial console in an attempt to capture
> an OOPS.
>
> i got one yesterday. it's copied manually from the console, but
> hopefully the values are all accurate. there was more that had scrolled
> off screen above this too (sorry).
>
> oops, lspci, uname -a, .config and dmesg below.
>
> any suggestions for further debugging would be great,
>
> thanks,
Could you retest with the v1.5 version that is 2.6.17-rc3?
^ permalink raw reply
* Re: [Qemu-devel] PATCH: Support for multi-file raw images
From: Ryan Lortie @ 2006-05-12 15:54 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20060512143517.GL15855@narn.hozed.org>
[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]
On Fri, 2006-12-05 at 09:35 -0500, Troy Benjegerdes wrote:
> Have you tried making a read-only 'base' image and using qcow images
> instead? I'm not convinced that splitting things up is going to help a
> lot. You might end up writing 1 512 byte block each to 500 files.. in
> the qcow image case, that is writing 256K, and with 10mb files, that's
> 5GB.
The problem with this approach is that I get an ever-growing changes
file which must eventually be merged (and then I have to copy the 20GB
again).
> at the very least, the console should print an error. If you can keep
> all the files open, deleting the file won't be a problem.
I agree -- console error should definitely occur.
Opening all the files at the start is something to consider. It does
fly in the face of two things, though:
1 -- Limiting the number of fds. Obviously opening all file parts at
the very start will use up a whack of fds right away.
2 -- Not modifying files that haven't been modified. If you open a file
read-write then its modification time is automatically updated and rsync
will want to checksum/copy it again (it quickly checks local files based
on modtime and size). If you open all files read-only then the file may
not be there when you go to reopen it read-write. This is why the
current implementation is as lazy as possible in terms of opening files.
Cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 703 bytes --]
^ permalink raw reply
* Re: Reproducible reiser4 bug with 2.6.16.2 patch on tail_conversion.c:80
From: Timo Kokkonen @ 2006-05-12 15:55 UTC (permalink / raw)
To: reiserfs-list
In-Reply-To: <200605111124.53927.zam@namesys.com>
Hello,
Alexander Zarochentsev wrote:
> Hello
>
> please check whether the attached patch helps.
>
It did help indeed, thanks. I haven't had any further trouble with it
yet, looks good to me.
Thanks for the quick patch.
Timo Kokkonen
^ permalink raw reply
* [PATCH] ARM: OMAP: omap2_mcspi: use the per transfer wordsize and speed overrides
From: Imre Deak @ 2006-05-12 15:56 UTC (permalink / raw)
To: Tony Lindgren; +Cc: omap-linux
Each transfer in an SPI message can have its wordsize and speed override.
Add a omap2_mcspi_setup_transfer to handle this.
Interpret spi->bits_per_word == 0 as a default wordsize of 8.
Signed-off-by: Imre Deak <imre.deak@nokia.com>
diff --git a/drivers/spi/omap2_mcspi.c b/drivers/spi/omap2_mcspi.c
index 7e06358..903481c 100644
--- a/drivers/spi/omap2_mcspi.c
+++ b/drivers/spi/omap2_mcspi.c
@@ -92,6 +92,7 @@ struct omap2_mcspi {
struct omap2_mcspi_cs {
u8 transmit_mode;
+ int word_len;
};
#define MOD_REG_BIT(val, mask, set) do { \
@@ -168,12 +169,15 @@ static void omap2_mcspi_set_master_mode(
static void omap2_mcspi_txrx(struct spi_device *spi, struct spi_transfer *xfer)
{
+ struct omap2_mcspi_cs *cs = spi->controller_state;
unsigned int count, c;
u32 l;
unsigned long base, tx_reg, rx_reg, chstat_reg;
+ int word_len;
count = xfer->len;
c = count;
+ word_len = cs->word_len;
l = mcspi_read_cs_reg(spi, OMAP2_MCSPI_CHCONF0);
l &= ~OMAP2_MCSPI_CHCONF_TRM_MASK;
@@ -196,7 +200,7 @@ static void omap2_mcspi_txrx(struct spi_
if (xfer->tx_buf == NULL)
__raw_writel(0, tx_reg);
- if (spi->bits_per_word <= 8) {
+ if (word_len <= 8) {
u8 *rx;
const u8 *tx;
@@ -215,7 +219,7 @@ static void omap2_mcspi_txrx(struct spi_
*rx++ = __raw_readl(rx_reg);
}
}
- } else if (spi->bits_per_word <= 16) {
+ } else if (word_len <= 16) {
u16 *rx;
const u16 *tx;
@@ -234,7 +238,7 @@ static void omap2_mcspi_txrx(struct spi_
*rx++ = __raw_readl(rx_reg);
}
}
- } else if (spi->bits_per_word <= 32) {
+ } else if (word_len <= 32) {
u32 *rx;
const u32 *tx;
@@ -262,25 +266,22 @@ static void omap2_mcspi_txrx(struct spi_
}
}
-static int omap2_mcspi_setup(struct spi_device *spi)
+static int omap2_mcspi_setup_transfer(struct spi_device *spi,
+ struct spi_transfer *t)
{
struct omap2_mcspi_cs *cs = spi->controller_state;
struct omap2_mcspi_device_config *conf;
u32 l = 0, div = 0;
u8 word_len = spi->bits_per_word;
+ if (t != NULL && t->bits_per_word)
+ word_len = t->bits_per_word;
if (!word_len)
- return 0;
-
- if (!cs) {
- cs = kzalloc(sizeof *cs, SLAB_KERNEL);
- if (!cs)
- return -ENOMEM;
- spi->controller_state = cs;
- }
+ word_len = 8;
if (spi->bits_per_word > 32)
return -EINVAL;
+ cs->word_len = word_len;
conf = (struct omap2_mcspi_device_config *) spi->controller_data;
@@ -327,6 +328,20 @@ static int omap2_mcspi_setup(struct spi_
return 0;
}
+static int omap2_mcspi_setup(struct spi_device *spi)
+{
+ struct omap2_mcspi_cs *cs = spi->controller_state;
+
+ if (!cs) {
+ cs = kzalloc(sizeof *cs, SLAB_KERNEL);
+ if (!cs)
+ return -ENOMEM;
+ spi->controller_state = cs;
+ }
+
+ return omap2_mcspi_setup_transfer(spi, NULL);
+}
+
static void omap2_mcspi_cleanup(const struct spi_device *spi)
{
if (spi->controller_state != NULL)
@@ -347,6 +362,7 @@ static void omap2_mcspi_work(unsigned lo
int cs_active = 0;
struct omap2_mcspi_device_config *conf;
struct omap2_mcspi_cs *cs;
+ int par_override = 0;
int status = 0;
m = container_of(mcspi->msg_queue.next, struct spi_message,
@@ -364,6 +380,14 @@ static void omap2_mcspi_work(unsigned lo
status = -EINVAL;
break;
}
+ if (par_override || t->speed_hz || t->bits_per_word) {
+ par_override = 1;
+ status = omap2_mcspi_setup_transfer(spi, t);
+ if (status < 0)
+ break;
+ if (!t->speed_hz && !t->bits_per_word)
+ par_override = 0;
+ }
if (!cs_active) {
omap2_mcspi_force_cs(spi, 1);
@@ -381,6 +405,12 @@ static void omap2_mcspi_work(unsigned lo
}
}
+ /* Restore defaults they are overriden */
+ if (par_override) {
+ par_override = 0;
+ status = omap2_mcspi_setup_transfer(spi, NULL);
+ }
+
if (cs_active)
omap2_mcspi_force_cs(spi, 0);
^ permalink raw reply related
* Re: Symbios-NCR 6285-3621 + Adaptec 2944W multilun problem
From: Mike Anderson @ 2006-05-12 15:56 UTC (permalink / raw)
To: James Bottomley; +Cc: Gabriel Gomiz, linux-scsi
In-Reply-To: <1147446596.3769.25.camel@mulgrave.il.steeleye.com>
James Bottomley <James.Bottomley@SteelEye.com> wrote:
> On Fri, 2006-05-12 at 11:34 -0300, Gabriel Gomiz wrote:
> > I'm attaching dmesg output. I'm sorry I forgot to attach it in the
> > last
> > email. The I/O errors occur when the devices are being detected and
> > whenever I try to access them. For example to do 'fsidk -l /dev/sdc'.
>
> Well, what I was hoping for was mode sense messages but, unfortunately,
> there aren't any. My suspicion is that the 6285 is dual controller
> running in RDAC mode and you're attached to the inactive controller (in
> that configuration it allowed INQUIRY and MODE SENSE through but errors
> out on all other I/O operations). I think you can verify by physically
> removing one of the controllers and rebooting the array (or just attach
> the SCSI cable to the other controller)
I would agree with your suspicion as the error signature is similar to
ones I receive using some FC based storage in RDAC mode. This problem is
showing up more as we have more storage support move from other multipath
solutions implemented in the mid-layer to using device mapper.
-andmike
--
Michael Anderson
andmike@us.ibm.com
^ permalink raw reply
* [ALSA - driver 0002106]: Sound card snd-hda-intel emits NO sound
From: bugtrack @ 2006-05-12 15:58 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2106>
======================================================================
Reported By: louisvd
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 2106
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Fedora Core 5
Kernel Version: 2.6.16-1.2111_FC5smp
======================================================================
Date Submitted: 05-08-2006 21:00 CEST
Last Modified: 05-12-2006 17:58 CEST
======================================================================
Summary: Sound card snd-hda-intel emits NO sound
Description:
Hi
I was merrily running Fedora Core 4 and after upgrading the kernel to
2.6.16 my sound no longer worked under Linux (it works under Windows).
After a lot of battling I figured I may as well upgrade to FC5 now. A
clean install, out of the box, and the sound STILL did not work. I've
applied every available patch to date and no luck. Tonight I installed
the Alsa 1.0.11 driver, lib and util tarballs -- all installed
successfully -- but there is STILL no sound produced.
Everything LOOKS normal. There are no errors that I can detect. In the X
and console versions of Alsamixer I have ALL the devices displayed and
unmuted with the volumes at max. I've removed the sound lines from
modprobe.conf and am running with alsasound and that didn't help either --
even though it says the driver has been loaded.
FYI, the OSS Volume control calls it a Realtek ALC260. lspci refers to it
as Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller
(rev 01).
Please help.
======================================================================
----------------------------------------------------------------------
tiwai - 05-12-06 17:36
----------------------------------------------------------------------
You should write only one "options snd-hda-intel" line. The first one is
overridden.
As mentioned, try different model option values as found in
ALSA-Configuration.txt. For example, model=hp. If none of them matches
properly with yours, we'll need to create another model.
In the case of ALC260, you can use model=test when the drivers are
compiled with debug option (--with-debug=full configure option). It will
allow you to tune almost everything on the codec chip. Figure out which
pin and configuration matches with the actual I/O by trial-and-error.
----------------------------------------------------------------------
louisvd - 05-12-06 17:58
----------------------------------------------------------------------
SUCCESS!!
I changed the model to 'basic' and that worked.
Here is my modprobe.conf
alias eth0 tg3
alias scsi_hostadapter ata_piix
alias snd-card-0 snd-hda-intel
options snd-card-0 index=0
options snd-hda-intel index=0 model=basic
remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; };
/sbin/modprobe -r --ignore-remove snd-hda-intel
Thank you VERY MUCH for your assistance. You may close this call.
Issue History
Date Modified Username Field Change
======================================================================
05-08-06 21:00 louisvd New Issue
05-08-06 21:00 louisvd Distribution => Fedora Core 5
05-08-06 21:00 louisvd Kernel Version => 2.6.16-1.2111_FC5smp
05-10-06 16:16 tiwai Note Added: 0009722
05-10-06 16:52 louisvd Note Added: 0009731
05-10-06 16:55 tiwai Note Added: 0009732
05-10-06 20:02 louisvd Note Added: 0009751
05-12-06 00:40 louisvd Note Added: 0009770
05-12-06 10:31 UMMO Issue Monitored: UMMO
05-12-06 16:11 tiwai Note Added: 0009778
05-12-06 17:18 louisvd Note Added: 0009782
05-12-06 17:36 tiwai Note Added: 0009783
05-12-06 17:54 UMMO Issue End Monitor: UMMO
05-12-06 17:58 louisvd Note Added: 0009784
======================================================================
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: 3c59x vortex_timer rt hack (was: rt20 patch question)
From: Andrew Morton @ 2006-05-12 16:03 UTC (permalink / raw)
To: Steven Rostedt; +Cc: mingo, markh, linux-kernel, dwalker, tglx
In-Reply-To: <Pine.LNX.4.58.0605121136060.4281@gandalf.stny.rr.com>
Steven Rostedt <rostedt@goodmis.org> wrote:
>
>
> On Fri, 12 May 2006, Andrew Morton wrote:
>
> >
> > Well, only if the hardware's fratzed. Normally this is quick.
> >
> > otoh vortex_timer() will play with the MII interface, which is slooooow.
> >
>
> The vortex_timer is a timeout,
err, it's actually a function.
> will it go off often?
Every five seconds if the cable's unplugged. Every 60 seconds otherwise.
^ permalink raw reply
* Re: [Xenomai-help] starnge latencies with native
From: Philippe Gerum @ 2006-05-12 16:08 UTC (permalink / raw)
To: Daniel Simon; +Cc: Xenomai-help
In-Reply-To: <20060512172456.555caf51@domain.hid>
Daniel Simon wrote:
> Hi all,
>
> I'm doing some tests with the native skins. The attached program uses
> an alarm to trigger a periodic task and measures the sampling latency.
>
> Initial latencies are in the range of tens of millisecs. and then
> decrease slowly to the range of microsecs:
>
> rt_timer_set_mode(TM_ONESHOT) started
> alarm started with period 1000000000 ns
> increment 1124642266 absjitter 124642266
> increment 937743828 absjitter 62256172
> increment 1031095424 absjitter 31095424
> increment 984466651 absjitter 15533349
> increment 1007758686 absjitter 7758686
> increment 996126407 absjitter 3873593
> increment 1001934707 absjitter 1934707
> increment 999039749 absjitter 960251
> increment 1000477139 absjitter 477139
> increment 999759707 absjitter 240293
> increment 1000119631 absjitter 119631
> increment 999938964 absjitter 61036
> increment 1000029816 absjitter 29816
> increment 999985508 absjitter 14492
> increment 1000004750 absjitter 4750
> increment 999998882 absjitter 1118
> increment 1000000946 absjitter 946
> increment 999998780 absjitter 1220
> increment 1000001951 absjitter 1951
> increment 999999514 absjitter 486
> increment 999998746 absjitter 1254
> [...]
>
> What may be wrong?
>
> I observe the same behaviour if the periodic sampling is given by a
> rt_periodic task or by a rt_sleep_until in the clock loop...
>
This code works here, so there might be an issue with your environment.
Does some Xenomai message appear in the kernel log, such as SMI warning?
Or did you activate the ACPI+cpufreq support for your kernel?
Also, what does /proc/xenomai/timer and /proc/xenomai/sched say when
your app is running?
Additionally, three remarks on your code:
- do NOT call rt_task_set_mode(0, T_PRIMARY, NULL); in your
applications. It's utterly useless and at best a waste of cycles since
Xenomai will move your thread to the proper mode as needed to run the
syscalls. This call is here for the 0.00000001% of situations where
eager control over the current mode is required by some internal Xenomai
code, but normal applications should not need this unless they are doing
something really weird.
- In the same vein, calling rt_timer_set_mode() is useless, unless you
want to override the default timing mode you set up during the kernel
configuration (CONFIG_XENO_OPT_TIMING_PERIODIC et al.) If you disabled
the previous option, then your system can only work in aperiodic mode
anyway, so you don't need to re-specify it by a call to rt_timer_set_mode().
- calling printf() in the middle of your measurement loop adds
uncertainty to your results, since migrating from Xenomai to Linux for
this purpose - and the other way around to get blocked on
rt_alarm_wait() - has a cost wrt latency. A 1 second period should not
be that much perturbated by a printf() though, but still, it's a wrong
way of writing time predictable code.
{rpm@xenomai.org} sudo ./orcalarm
rt_timer_set_mode(TM_ONESHOT) started
alarm started with period 1000000000 ns
increment 999986989 absjitter 13011
increment 1000006146 absjitter 6146
increment 999989806 absjitter 10194
increment 1000022829 absjitter 22829
increment 999997693 absjitter 2307
increment 1000003468 absjitter 3468
increment 999997452 absjitter 2548
increment 999999961 absjitter 39
increment 1000001230 absjitter 1230
increment 1000025352 absjitter 25352
increment 999985543 absjitter 14457
increment 999998970 absjitter 1030
Ctrl C Interrupt
increment 1000012630 absjitter 12630
jittermoy = 7682, jittermax = 25352
deleting rt devices
--
Philippe.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.