* [PATCH] Re: "apm: set display: Interface not engaged" is back on armada laptops [Was: APM Screen Blanking fix]
From: Samuel Thibault @ 2006-04-09 13:57 UTC (permalink / raw)
To: torvalds; +Cc: jordan.crouse, linux-kernel
In-Reply-To: <20060325134625.GA4593@bouh.residence.ens-lyon.fr>
Hi,
Samuel Thibault, le Sat 25 Mar 2006 14:46:25 +0100, a écrit :
> Part of a fix for APM Screen Blanking in
> arch/i386/kernel/apm.c:apm_console_blank() from Jordan Crouse was:
>
> - if (error == APM_NOT_ENGAGED) {
> + if (error == APM_NOT_ENGAGED && state != APM_STATE_READY) {
>
> for "Prevent[ing] the error message from printing out twice."
>
> However, this puts the "apm: set display: Interface not engaged"
> error back on armada laptops (which was the original need for this if
> statement).
Here is a fix:
Fix the "apm: set display: Interface not engaged" error on Armada
laptops again.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
diff --git a/arch/i386/kernel/apm.c b/arch/i386/kernel/apm.c
index da30a37..df0e174 100644
--- a/arch/i386/kernel/apm.c
+++ b/arch/i386/kernel/apm.c
@@ -1079,7 +1079,7 @@ static int apm_console_blank(int blank)
break;
}
- if (error == APM_NOT_ENGAGED && state != APM_STATE_READY) {
+ if (error == APM_NOT_ENGAGED) {
static int tried;
int eng_error;
if (tried++ == 0) {
^ permalink raw reply related
* RE: [RFC] Hypercalls from HVM guests
From: Nakajima, Jun @ 2006-04-09 13:56 UTC (permalink / raw)
To: Keir Fraser; +Cc: Steve Ofsthun, xen-devel
Keir Fraser wrote:
> On 9 Apr 2006, at 00:33, Nakajima, Jun wrote:
>
>> If eax is set to a value outside the recognized range of CPUID
>> currently defined, CPUID does not necessarily return all zero's on
>> Intel. It's "Reserved" (Information returned for highest basic
>> information leaf). Also "an unused index" can have conflicts in the
>> future.
>>
>> If we just need to tell on which CPU the current HVM guest is
>> running, I think "GeunineIntel" or "AuthenticAMD" is the best
>> because it's been used by native systems as well.
>
> Then how do you tell whether you are running on a hypervisor without
> executing some instruction that might fault? We would like to avoid
> requiring that.
This is a different question, and I think detecting a virtual device
(i.e. virtual block device, NIC) or chipset would be a cleaner way at
this point. And that would be proper for the patch that Steve mentioned
(we wrote it). The fact that it's running on a hypervisor does not
necessarily guarantee presence of such virtual devices (in fact they
don't exist today ;-).
If we really need to tell if we are running on a hypervisor at a very
early point or even in user-mode, I think CPUID with "an unused index"
would be the simplest, but so far I haven't seen any usage models that
really require that. If we want to add virtualization hints for
processor architectures (e.g. MMU) in guests, it would be needed.
>
> There is quite a lot of CPUID and MSR address space, and a random
> return value for CPUID when running natively is practically-speaking
> fine if we're looking for a 128-bit signature.
Many bits are already reserved for the future capabilities in CPUID, and
MSR is CPU _model_ specific by definition, i.e. not architecturally
clean. But my point is that we should specify "reserved for
virtualization" or something in the H/W manual rather than inventing an
ad hoc one (when we don't really need). BTW, I think virtualization
hints (nop on the native, hypercall on a hypervisor) would be very
useful for performance optimizations.
>
> The only other option I think would be a BIOS table, probably below
> 1MB. I prefer the CPUID/MSR method.
>
> -- Keir
Jun
---
Intel Open Source Technology Center
^ permalink raw reply
* Re: NATed packets only enter the default routing table
From: Jeroen Elebaut @ 2006-04-09 13:56 UTC (permalink / raw)
To: netfilter
In-Reply-To: <20060408194058.71fa3e09.mailinglists@lucassen.org>
Hi,
i had a similar problem with our setup. The problem is i think that the
routing decision on the linux box is made before the address in the packet is
changed back to 1.2.3.3. So it doesn't use the source policy routing entry. I
solved this by using the connmark module from iptables and then do routing
based on the mark. The following should work in your setup:
iptables -t mangle -I PREROUTING -m conntrack --ctstate ESTABLISHED,RELATED -j
CONNMARK --restore-mark
iptables -t mangle -I PREROUTING -i eth1 -m conntrack --ctstate NEW -j
CONNMARK --set-mark 1
ip rule add fwmark 1 lookup eth1_up
This will route everything that entered via eth1 back via eth1.
Greetings,
jeroen
^ permalink raw reply
* A failed-disk-how-to anywhere?
From: Martin Stender @ 2006-04-09 13:53 UTC (permalink / raw)
To: linux-raid
Hi there!
I have two identical disks sitting on a Promise dual channel IDE
controller. I guess both disks are primary's then.
One of the disks have failed, so I bought a new disk, took out the
failed disk, and put in the new one.
That might seem a little naive, and apparently it was, since the
system won't boot up now.
It boots fine, when only the old, healthy disk is connected.
By the way, all three partitions are raided - including /boot ...
Anyway, I have removed the old disk from the Raid with:
#mdadm /dev/mdo --remove /dev/hde1
#mdadm /dev/md1 --remove /dev/hde2
#mdadm /dev/md2 --remove /dev/hde3
- but the the problem persists.
I can't seem to find a decent 'How-To' - so how it this supposed to
be done?
Thanks in advance!
Martin
^ permalink raw reply
* Re: [Qemu-devel] qemu exec.c
From: Paul Brook @ 2006-04-09 13:51 UTC (permalink / raw)
To: qemu-devel, a_mulyadi
In-Reply-To: <200604092046.23092.a_mulyadi@softhome.net>
> > Modified files:
> > . : exec.c
> >
> > Log message:
> > Fix breakpoint TLB invalidation.
>
> Does this fix do the same thing like Andre pech's gdb fix?
Yes, it also fixes that problem.
Paul
^ permalink raw reply
* Re: [Qemu-devel] qemu exec.c
From: Mulyadi Santosa @ 2006-04-09 13:46 UTC (permalink / raw)
To: qemu-devel, Paul Brook
In-Reply-To: <E1FSH1U-00006o-C1@savannah.gnu.org>
Hi Paul...
> CVSROOT: /sources/qemu
> Module name: qemu
> Branch:
> Changes by: Paul Brook <pbrook@savannah.gnu.org> 06/04/08 17:14:56
>
> Modified files:
> . : exec.c
>
> Log message:
> Fix breakpoint TLB invalidation.
Does this fix do the same thing like Andre pech's gdb fix?
regards
Mulyadi
^ permalink raw reply
* [PATCH] Improve the git-diff-tree -c/-cc documentation
From: Petr Baudis @ 2006-04-09 13:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslonaxq6.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sun, Apr 09, 2006 at 11:45:37AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@ucw.cz> writes:
>
> > Now, the -c option documentation says:
> >
> > It shows the differences from each of the parents to the merge
> > result simultaneously, instead of showing pairwise diff between
> > a parent and the result one at a time, which '-m' option output
> > does.
> >
> > This sounds as exactly what I want. Well, the only problem is that the
> > same diff command as above with -c option added produces no diff at all,
> > just the header and commit messages. Did I misunderstand the -c
> > description and does it do something different?
>
> The --combined diff option is to show merges more sensibly than
> plain -m option. Now, the definition of "sensible" is to say
> that a merge is not interesting if it takes a version from one
> of the parents. The paths whose results do not match any of the
> parents' version are deemed interesting and are shown.
>
> I think you could tweak and give an option to intersect_paths()
> in combine-diff.c, so that paths that match one of the parents
> are also included in the output. I haven't thought about it too
> much, but my gut feeling is it would not be very involved
> change.
Aha, thanks! I actually think this is more sensible to do, so now I'm
only pondering if in cg-log -f it is more useful to show the list of
files changed relative to the first parent or the files which were
subjected to a content merge...
---
This tries to clarify the -c/-cc documentation and clean up the style and
grammar.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-diff-tree.txt | 25 ++++++++++++++++---------
1 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 9153e4c..d7e529b 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -60,7 +60,8 @@ separated with a single space are given.
-m::
By default, "git-diff-tree --stdin" does not show
differences for merge commits. With this flag, it shows
- differences to that commit from all of its parents.
+ differences to that commit from all of its parents. See
+ also '-c'.
-s::
By default, "git-diff-tree --stdin" shows differences,
@@ -81,19 +82,25 @@ separated with a single space are given.
git-diff-tree outputs a line with the commit ID when
applicable. This flag suppressed the commit ID output.
--c,--cc::
- These flags change the way a merge commit is displayed
+-c::
+ This flag changes the way a merge commit is displayed
(which means it is useful only when the command is given
one <tree-ish>, or '--stdin'). It shows the differences
- from each of the parents to the merge result
- simultaneously, instead of showing pairwise diff between
- a parent and the result one at a time, which '-m' option
- output does. '--cc' further compresses the output by
- omiting hunks that show differences from only one
+ from each of the parents to the merge result simultaneously
+ instead of showing pairwise diff between a parent and the
+ result one at a time (which is what the '-m' option does).
+ Furthermore, it lists only files which were modified
+ in both parents.
+
+-cc::
+ This flag changes the way a merge commit patch is displayed,
+ in a similar way to the '-c' option. It implies the '-c'
+ and '-p' options and further compresses the patch output
+ by omitting hunks that show differences from only one
parent, or show the same change from all but one parent
for an Octopus merge. When this optimization makes all
hunks disappear, the commit itself and the commit log
- message is not shown, just like any other "empty diff" cases.
+ message is not shown, just like in any other "empty diff" case.
--always::
Show the commit itself and the commit log message even
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply related
* Re: [LARTC] Trying to do some very simple ingress limiting, no success
From: Andy Furniss @ 2006-04-09 13:42 UTC (permalink / raw)
To: lartc
In-Reply-To: <1144579998.5694.18.camel@localhost.localdomain>
Erik Slagter wrote:
>
> Found it and deselected it. Now making new kernel...
>
> The "old" policer is marked as "obsolete", so I guess it will go away.
>
> What am I supposed to replace it with, then?
There may be a way in the future to get netfilter state with an
ematch/meta data (I don't know the detail Thomas Graf has mentioned it).
> For IMQ I need to patch the kernel (feasible) and the netfilter tools
> (not feasible :-() I just learned.
I didn't know there is a problrm with IMQ + netfilter.
Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [RFC] Source format change for drawing functions
From: Antonino A. Daplas @ 2006-04-09 13:29 UTC (permalink / raw)
To: Linux Fbdev development list
Hi people,
Currently, the drawing functions of the framebuffer devices accepts either an
index to the pseudo_palette (truecolor, directcolor) or an index to the
clut (the rest of the visuals) as the source color. It has distinct
advantages in that the upper layer (fbcon) need not convert the console colors
to framebuffer format, and makes writing to the framebuffer quite fast.
However, it has certain disadvantages:
- we are restricted to 16 colors only, or with hacks, 256, as in the logo
drawing code
- most drivers need to keep a pseudo_palette which rightly belongs to fbcon,
not the drivers
- the drawing functions are basically useless outside fbcon/fbdev
Therefore, I'm proposing that we change the source format so we can take
advantage of the full range of colors offered by a particular visual while
keeping clients (mainly fbcon) free from the hassle of color conversion.
To implement this:
1. Separate fb_setcolreg() into two functions:
a. fb_setcolreg() - writes the color components to the hardware clut
b. fb_get_pixel() - returns a u32 value which is the raw framebuffer format
given red, green, blue, and transparency components. The returned value
can be directly written to the framebuffer. Basically, this is the part of
the fb_setcolreg() function that writes entries to the pseudo_palette, but
it returns the value instead.
Doing the above should be very simple. In pseudocode, from:
static int xxxfb_setcolreg(...)
{
write_to_dac()
pseudo_palette(regno) = red | green | blue | transp;
return 0;
}
to
static int xxxfb_setcolreg(...)
{
write_to_dac()
return 0;
}
static u32 xxxfb_get_pixel(...)
u32 pixel = red | green | blue | transp;
return pixel;
}
2. For drivers that implements fb_get_pixel(), the pseudo_palette will become
unused, thus there is no need to allocate memory for this. (fbcon will
instead maintain the pseudo_palette. And once all drivers are converted we
can remove the pointer from struct fb_info.)
3. Convert drawing functions to accept source format in ARGB8888
Truecolor. Drawing functions will use fb_get_pixel() to convert ARGB8888
into a value which can be directly written to the framebuffer or fed to the
accelerator engine.
The advantage of doing this is that the drawing functions become usable
outside of fbdev/fbcon. It also makes displaying an image to the
framebuffer easy. As long as the bitmap is in ARGB8888 (or monochrome),
this can be fed to the driver and it should display properly regardless of
the current visual.
The disadvantage is we do on-the-fly format conversions, so fbcon will slow
down a litte. Not very noticeable except for the speed freaks.
If speed is of the essence, we can instead use source in raw
framebuffer format. This will be very fast, but this will require that
clients know how to do the conversion. fbcon can use fb_get_pixel() to do
the conversion, so it won't be a problem.
I have a working implementation in my private tree using ARGB8888 as the
source format with several commonly used drivers already converted and
working. There won't be breakage for drivers that do not implement
fb_get_pixel() as the code that uses the index to the pseudo_palette is still
in place.
Comments? I may send this to akpm for testing unless there are violent
objections.
Tony
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: RT task scheduling
From: Ingo Molnar @ 2006-04-09 13:16 UTC (permalink / raw)
To: Darren Hart
Cc: linux-kernel, Thomas Gleixner, Stultz, John, Peter Williams,
Siddha, Suresh B, Nick Piggin
In-Reply-To: <200604052025.05679.darren@dvhart.com>
* Darren Hart <darren@dvhart.com> wrote:
> My last mail specifically addresses preempt-rt, but I'd like to know
> people's thoughts regarding this issue in the mainline kernel. Please
> see my previous post "realtime-preempt scheduling - rt_overload
> behavior" for a testcase that produces unpredictable scheduling
> results.
thanks for the testcase! It indeed triggered a bug in the -rt tree's
"RT-overload" balancing feature. The nature of the bug made it trigger
much less likely on 2-way boxes (where i do most of my -rt testing),
probably that's why it didnt get discovered before. I've uploaded the
-rt14 tree with this bug fixed - does it fix the failures for you?
Ingo
^ permalink raw reply
* Re: [LARTC] Trying to do some very simple ingress limiting, no success
From: Erik Slagter @ 2006-04-09 13:09 UTC (permalink / raw)
To: lartc
In-Reply-To: <1144579998.5694.18.camel@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 2230 bytes --]
On Sun, 2006-04-09 at 14:00 +0100, Andy Furniss wrote:
> Erik Slagter wrote:
> > Hi,
> >
> > I am trying to do some simple ingress limiting based on fwmark. I know
> > the ability and sense to do INGRESS limiting is ehm... limited ;-) but
> > still I want to try it.
> >
> > I tried several things.
> >
> > === 1 ===
> >
> > tcq ingress handle ffff:
> > tcf parent ffff: protocol ip prio 1 handle 1 fw police rate 12mbit burst 10k drop
> > tcf parent ffff: protocol ip prio 1 handle 2 fw police rate 10mbit burst 10k drop
> > tcf parent ffff: protocol ip prio 1 handle 3 fw police rate 1mbit burst 10k drop
> >
> > This installs OK, but the filters are never called. The netfilter stats
> > show the marks are set though. To make sure it's not just the tc stats
> > output that's borked, I changed the bw limits to a rediculous low value,
> > and indeed, no effect at all.
> >
> There are two policers now the old one will work as you want but you
> need to change your kernel config. Unselect packet action and you should
> be able to choose a different policer.
Found it and deselected it. Now making new kernel...
The "old" policer is marked as "obsolete", so I guess it will go away.
What am I supposed to replace it with, then?
> Or you could try using tc filters instead of netfilter - I don't know if
> it will be possible for what you want as I can't see the rules that mark.
It's probably possible, but I already have quite a large set of
netfilter rules. I don't want to make the whole thing even more
complicated by also adding lots of tc stuff, I'd rather have the
tc/iproute things as simple as possible.
> This has never worked if you want a queue on ingress you need to use IMQ
> (in the case that you need netfilter PREROUTING marks) or IFB (kernel >=
> 2.6.16) but this will hook before netfilter - so no marks.
For IMQ I need to patch the kernel (feasible) and the netfilter tools
(not feasible :-() I just learned.
And you're just telling me I cannot use IFB. Bummer. Anyway, if there is
any simple (!) way to implement what I am searching for, I am happy.
I will try your "old policer version" suggestion asap.
Thanks for your help.
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2771 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: [2.6 patch] drivers/isdn/capi/capiutil.c: unexport capi_message2str
From: Karsten Keil @ 2006-04-09 13:07 UTC (permalink / raw)
To: Adrian Bunk; +Cc: isdn4linux, linux-kernel
In-Reply-To: <20060407211736.GO7118@stusta.de>
On Fri, Apr 07, 2006 at 11:17:36PM +0200, Adrian Bunk wrote:
> This patch removes an unused EXPORT_SYMBOL.
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>
> --- linux-2.6.17-rc1-mm1-full/drivers/isdn/capi/capiutil.c.old 2006-04-07 10:47:30.000000000 +0200
> +++ linux-2.6.17-rc1-mm1-full/drivers/isdn/capi/capiutil.c 2006-04-07 10:47:37.000000000 +0200
> @@ -855,5 +855,4 @@
> EXPORT_SYMBOL(capi_cmsg_header);
> EXPORT_SYMBOL(capi_cmd2str);
> EXPORT_SYMBOL(capi_cmsg2str);
> -EXPORT_SYMBOL(capi_message2str);
> EXPORT_SYMBOL(capi_info2str);
>
Yes it is currently unused, but part of the CAPI driver SDK for supporting
debug messages in capi drivers, so I would tend to let it exported, if here
are not strong arguments against exporting it.
--
Karsten Keil
SuSE Labs
ISDN development
^ permalink raw reply
* Re: [LARTC] Trying to do some very simple ingress limiting, no success
From: Andy Furniss @ 2006-04-09 13:00 UTC (permalink / raw)
To: lartc
In-Reply-To: <1144579998.5694.18.camel@localhost.localdomain>
Erik Slagter wrote:
> Hi,
>
> I am trying to do some simple ingress limiting based on fwmark. I know
> the ability and sense to do INGRESS limiting is ehm... limited ;-) but
> still I want to try it.
>
> I tried several things.
>
> == 1 =>
> tcq ingress handle ffff:
> tcf parent ffff: protocol ip prio 1 handle 1 fw police rate 12mbit burst 10k drop
> tcf parent ffff: protocol ip prio 1 handle 2 fw police rate 10mbit burst 10k drop
> tcf parent ffff: protocol ip prio 1 handle 3 fw police rate 1mbit burst 10k drop
>
> This installs OK, but the filters are never called. The netfilter stats
> show the marks are set though. To make sure it's not just the tc stats
> output that's borked, I changed the bw limits to a rediculous low value,
> and indeed, no effect at all.
>
There are two policers now the old one will work as you want but you
need to change your kernel config. Unselect packet action and you should
be able to choose a different policer.
Or you could try using tc filters instead of netfilter - I don't know if
it will be possible for what you want as I can't see the rules that mark.
> == 2 =>
> tcq ingress handle ffff:
> tcq parent ffff: handle 10 htb
> tcc parent ffff: htb rate 12mbit
> tcc parent ffff: htb rate 10mbit
> tcc parent ffff: htb rate 1mbit
> tcf parent ffff: protocol ip prio 1 fw
>
> I tricked tc into attaching a htb to the root qdisc. This gives no errors
> but also doesn't seem to do anything. If you use tc show qdisc|filter|class
> the qdisc,filters and classes are not even shown, so I guess it's borked
> (tc should have given an error that it won't work).
>
> ====
This has never worked if you want a queue on ingress you need to use IMQ
(in the case that you need netfilter PREROUTING marks) or IFB (kernel >=
2.6.16) but this will hook before netfilter - so no marks.
Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* [PATCH] Staircase cpu scheduler v15 for 2.6.17-rc1*
From: Con Kolivas @ 2006-04-09 12:56 UTC (permalink / raw)
To: linux list, ck list
[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]
Patches for the current staircase cpu scheduler (v15) for 2.6.17-rc1 are here:
http://www.kernel.org/pub/linux/kernel/people/ck/patches/staircase/2.6.17-rc1/2.6.17-rc1-staircase-15.patch
and for mm2 here:
http://www.kernel.org/pub/linux/kernel/people/ck/patches/staircase/2.6.17-rc1/2.6.17-rc1-mm2/2.6.17-rc1-mm2-staircase-15.patch
Martin Bligh was kind enough to put the current version of staircase on
2.6.17-rc1 for testing on http://test.kernel.org/
Performance more or less parallels mainline 2.6.17-rc1 (apart from
interactivity as shown here previously where staircase mostly trumps
mainline).
Jens Axboe was also kind enough to do a kernbench run on 4xIA64 which also
showed no performance difference. See
http://article.gmane.org/gmane.linux.kernel.ck/5472 (the 2nd run is staircase
and the attachments seem to be listed twice by gmane)
Just as a reminder of how much less code than the ever increasing complexity
mainline scheduler staircase is, here is a diffstat of the patch for
2.6.17-rc1-mm2:
fs/proc/array.c | 4
include/linux/sched.h | 20 -
kernel/exit.c | 1
kernel/sched.c | 987
++++++++++++++++----------------------------------
4 files changed, 327 insertions(+), 685 deletions(-)
--
-ck
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [Xenomai-core] Re: [PATCH] trigger I-pipe trace freezing via proc
From: Philippe Gerum @ 2006-04-09 12:50 UTC (permalink / raw)
To: Jan Kiszka; +Cc: adeos-main, xenomai-core
In-Reply-To: <4438F951.5010507@domain.hid>
Jan Kiszka wrote:
> Hi Philippe,
>
> here is a tiny patch to re-trigger trace freezing by writing a positive
> number to /proc/ipipe/trace/frozen. Writing 0 provides the old
> behaviour, i.e. resets the frozen trace so that ipipe_trace_freeze() can
> capture a new trace.
>
> Please apply.
>
Applied, thanks.
--
Philippe.
^ permalink raw reply
* [Xenomai-core] Re: [PATCH] display domain status in I-ipipe tracer
From: Philippe Gerum @ 2006-04-09 12:50 UTC (permalink / raw)
To: Jan Kiszka; +Cc: adeos-main, xenomai-core
In-Reply-To: <4438EB6C.1030607@domain.hid>
Jan Kiszka wrote:
> Hi,
>
> as promised, here is the patch to extend the I-ipipe trace so that it
> displays also the domain stall flags of the first 4 domains (I don't
> expect more in practice yet ;) ). The information is shown if you switch
> on the verbose mode (echo 1 > /proc/ipipe/tracer/verbose). Also, more
> explanation of the shown columns is given now.
>
> Please apply.
>
Applied, thanks.
--
Philippe.
^ permalink raw reply
* Re: [uml-devel] [RFC][PATCH] include /usr/lib/uml in PATH
From: Stefano Melchior @ 2006-04-09 12:52 UTC (permalink / raw)
To: Mattia Dongili
Cc: Blaisorblade, user-mode-linux-devel, Geert Uytterhoeven,
Jeff Dike
In-Reply-To: <20060407165205.GE23715@inferi.kami.home>
[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]
On Fri, Apr 07, 2006 at 06:52:05PM +0200, Mattia Dongili wrote:
Dear all,
> > > > #define UML_LIB_PATH ":/usr/lib/uml"
> >
> > > what about a config option instead? CONFIG_UML_NET_PATH
> >
> > Don't think so, that's not supposed to be changed according to any config
> > option or I can't see that. Unless on 64-bit system that's /usr/lib64/uml,
> > and in that case it makes sense to have CONFIG_XXX =
> > "/usr/lib/uml" (without :, add them only in the source, i.e. insulate details
> > away).
>
> Yes, that was what I meant. However it's probably not worth the effort
> yet.
>
> > > > 19 -> strlen(UML_LIB_PATH)
> > > > in snprintf, "PATH=%s:/usr/lib/uml" -> "PATH=%s" UML_LIB_PATH
> > > >
> > > > (using string literal concatenation)
> >
> > > here's an updated patch, I added a check for current PATH=="" to avoid
> > > touching the PATH variable when empty (again, kind of keeping the same
> > > behaviour of a clean execvp, I mean it makes no sense to append
> > > /usr/lib/uml and not /bin:/usr/bin too).
> >
> > In that case, you should append both IMHO - empty PATH and no PATH should be
> > treated the same way, I think.
>
> updated patch attached, I hope you like the if-statement .
>
> Description:
> append /usr/lib/uml to the existing PATH environment variable to let
> execvp search uml_net in FHS compliant locations.
at this point, is it the case to have also this patch for the
uml-utilities in order to install uml-net directly on the FHS complaint
path (uml-net):
--- uml_net/Makefile 2003-02-08 05:04:55.000000000 +0100
+++ uml_net/Makefile 2006-04-09 12:48:27.000000000 +0200
@@ -3,7 +3,7 @@
BIN = uml_net
CFLAGS = -g -Wall $(TUNTAP)
-BIN_DIR ?= /usr/bin
+BIN_DIR ?= /usr/lib/uml
OBJS = ethertap.o host.o output.o slip.o uml_net.o
What do you think?
Cheers
SteX
--
Stefano Melchior, GPG key = D52DF829 - <stefano.melchior@openlabs.it>
http://etinarcadiaego.dyndns.org -- http://www.stex.name
Skype ID "stefanomelchior"
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 309 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] sbp2: remove manipulation of inquiry response
From: Stefan Richter @ 2006-04-09 12:47 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-scsi, linux1394-devel
In-Reply-To: <20060409111907.GA20852@infradead.org>
Christoph Hellwig wrote:
> On Sat, Apr 08, 2006 at 08:55:10PM +0200, Stefan Richter wrote:
...
>>PS: Of my SBP-2 devices, 3 of 3 CD-RWs and 3 of 7 HDDs report a SCSI
>>level of 0. With and without the patch.
(By which I meant the SCSI Version as seen by the mid level and above,
after the response went through sbp2.)
> do they expect scsi1/2-style lun encoding in the cbd or not?
Maybe I am missing something, but the only places where the LUN is
significant in the communication from the initiator to SBP-2 targets are
Login ORBs and Query Login ORBs. Both have the LUN encoded in the 16
bits long variant.
--
Stefan Richter
-=====-=-==- -=-- -=--=
http://arcgraph.de/sr/
^ permalink raw reply
* Re: NFS directio
From: Neil Brown @ 2006-04-09 12:38 UTC (permalink / raw)
To: cel; +Cc: Olaf Kirch, Trond Myklebust, nfs
In-Reply-To: <442D4FC2.7060109@citi.umich.edu>
On Friday March 31, cel@citi.umich.edu wrote:
> Olaf Kirch wrote:
> > On Fri, Mar 31, 2006 at 09:35:34AM -0500, Chuck Lever wrote:
> >> the check isn't in 2.6.16. it was removed sometime after 2.6.5.
> >
> > It is still in the 2.6.16 tree I'm looking at; else I wouldn't ask :)
>
> it's been in my trees since 2.6.13 or even earlier, my mistake.
>
> that change is part of the aio+dio patches that were just included in
> 2.6.17-rc1. instead of creating a single patch for this change, you
> should consider taking those patches, since they were tested as a unit.
>
> if you can guarantee that atomic_t is 32-bits on every platform you
> support, then it should be save to change that #define to 2^31.
> otherwise, the work to eliminate the limit entirely has already been
> done by the above-mentioned patches.
(Coming into the conversation a bit late....)
What about the kmalloc in nfs_get_user_pages:
array_size = (page_count * sizeof(struct page *));
*pages = kmalloc(array_size, GFP_KERNEL);
With a page_count of 1024, this allocates one page (on 32bit) which is
easy.
With a page_count of 4096 (the previous MAX_DIRECTIO_SIZE)), this
allocates 4 consecutive pages, which won't always succeed.
If you want to go higher than that (which was the point of the start
of this thread) then you need a large-order allocation which doesn't
(in my understanding) have a good chance of success due to
fragmentation.
So I guess my question is: how hard would it be to use a more scalable
data structure so that very large IO sizes would be reliably
practical?
NeilBrown
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* md/mdadm fails to properly run on 2.6.15 after upgrading from 2.6.11
From: Marc L. de Bruin @ 2006-04-09 12:35 UTC (permalink / raw)
To: linux-raid
Hi,
(I just subscribed, sorry if this is a dupe. I did try to match the
subject from the archives, but couldn't find any...)
I ran into trouble after upgrading a Debian Sarge system from 2.6.11 to
2.6.15. To be more precise, it turned out that md/mdadm seems to not
function properly during the boot process of 2.6.15.
My /etc/mdadm/mdadm.conf contains this:
>>>---[mdadm.conf]---
DEVICE /dev/hdi1 /dev/hdg1 /dev/hdc1
ARRAY /dev/md1 level=raid5 num-devices=3
UUID=09c58ab6:f706e37b:504cf890:1a597046 devices=/dev/hdi1,/dev/hdg1,/dev/hdc1
DEVICE /dev/hdg2 /dev/hdc2
ARRAY /dev/md2 level=raid1 num-devices=2
UUID=86210844:6abbf533:dc82f982:fe417066 devices=/dev/hdg2,/dev/hdc2
DEVICE /dev/hda2 /dev/hdb2
ARRAY /dev/md0 level=raid1 num-devices=2
UUID=da619c37:6c072dc8:52e45423:f4a58b7c devices=/dev/hda2,/dev/hdb2
DEVICE /dev/hda1 /dev/hdb1
ARRAY /dev/md4 level=raid1 num-devices=2
UUID=bfc30f9b:d2c21677:c4ae5f90:b2bddb75 devices=/dev/hda1,/dev/hdb1
DEVICE /dev/hdc3 /dev/hdg3
ARRAY /dev/md3 level=raid1 num-devices=2
UUID=fced78ce:54f00a78:8662e7eb:2ad01d0b devices=/dev/hdc3,/dev/hdg3
>>>---[/mdadm.conf]---
On 2.6.11, it booted (and still boots) correctly. The interesting parts
from the boot-sequence are:
>>>---[2.6.11 dmesg]---
md: md driver 0.90.1 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: raid1 personality registered as nr 3
[...]
md: md0 stopped.
md: bind<hdb2>
md: bind<hda2>
[...]
md: md1 stopped.
md: bind<hdg1>
md: bind<hdc1>
md: bind<hdi1>
raid5: automatically using best checksumming function: pIII_sse
pIII_sse : 3872.000 MB/sec
raid5: using function: pIII_sse (3872.000 MB/sec)
md: raid5 personality registered as nr 4
raid5: device hdi1 operational as raid disk 0
raid5: device hdc1 operational as raid disk 2
raid5: device hdg1 operational as raid disk 1
raid5: allocated 3161kB for md1
raid5: raid level 5 set md1 active with 3 out of 3 devices, algorithm 2
RAID5 conf printout:
--- rd:3 wd:3 fd:0
disk 0, o:1, dev:hdi1
disk 1, o:1, dev:hdg1
disk 2, o:1, dev:hdc1
md: md2 stopped.
md: bind<hdc2>
md: bind<hdg2>
raid1: raid set md2 active with 2 out of 2 mirrors
md: md4 stopped.
md: bind<hdb1>
md: bind<hda1>
raid1: raid set md4 active with 2 out of 2 mirrors
md: md3 stopped.
md: bind<hdg3>
md: bind<hdc3>
raid1: raid set md3 active with 2 out of 2 mirrors
>>>---[/2.6.11 dmesg]---
This all looks great and is as expected by the mdadm.conf file. The
bootlog daemon continues to report ordinary things such as:
>>>---[2.6.11 bootlog]---
Sat Apr 8 16:47:53 2006: bootlogd.
Sat Apr 8 16:47:53 2006: Setting parameters of disc: (none).
Sat Apr 8 16:47:53 2006: Activating swap.
Sat Apr 8 16:47:53 2006: Checking root file system...
Sat Apr 8 16:47:53 2006: fsck 1.37 (21-Mar-2005)
Sat Apr 8 16:47:53 2006: /: clean, 122183/524288 files, 508881/1048576 blocks
[...]
Sat Apr 8 14:47:55 2006: Creating device-mapper devices...done.
Sat Apr 8 14:47:55 2006: Creating device-mapper devices...done.
Sat Apr 8 14:47:56 2006: Starting raid devices: mdadm-raid5:
Sat Apr 8 14:47:56 2006: mdadm: /dev/md1 has been started with 3 drives.
Sat Apr 8 14:47:56 2006: mdadm: /dev/md2 has been started with 2 drives.
Sat Apr 8 14:47:56 2006: mdadm: /dev/md4 has been started with 2 drives.
Sat Apr 8 14:47:56 2006: mdadm: /dev/md3 has been started with 2 drives.
Sat Apr 8 14:47:56 2006: done.
Sat Apr 8 14:47:56 2006: Setting up LVM Volume Groups...
Sat Apr 8 14:47:57 2006: Reading all physical volumes. This may take a
while...
Sat Apr 8 14:47:58 2006: Found volume group "vg" using metadata type lvm2
Sat Apr 8 14:47:58 2006: 2 logical volume(s) in volume group "vg" now
active
Sat Apr 8 14:47:58 2006: Checking all file systems...
Sat Apr 8 14:47:58 2006: fsck 1.37 (21-Mar-2005)
Sat Apr 8 14:47:58 2006: /dev/md4: clean, 54/48192 files, 43630/192640 blocks
Sat Apr 8 14:47:58 2006: /dev/mapper/vg-home: clean, 7560/219520 files,
120502/438272 blocks
Sat Apr 8 14:47:58 2006: /dev/md1: clean, 38614/9781248 files,
15097260/19539008 blocks
Sat Apr 8 14:47:58 2006: /dev/md2: clean, 18/7325696 files,
8634921/14651264 blocks
Sat Apr 8 14:47:58 2006: /dev/md3: clean, 2079183/7094272 files,
10865102/14185376 blocks
Sat Apr 8 14:47:58 2006: /dev/hde1: clean, 74/28640 files,
26855696/29296527 blocks
Sat Apr 8 14:47:58 2006: /dev/hde2: clean, 573/9781248 files,
13186560/19543072 blocks
Sat Apr 8 14:47:58 2006: Setting kernel variables ...
Sat Apr 8 14:47:58 2006: ... done.
Sat Apr 8 14:47:59 2006: Mounting local filesystems...
Sat Apr 8 14:47:59 2006: /dev/md4 on /boot type ext3 (rw)
Sat Apr 8 14:47:59 2006: /dev/mapper/vg-home on /home type ext3 (rw)
Sat Apr 8 14:47:59 2006: /dev/md1 on /mnt/raid5 type ext3 (rw)
Sat Apr 8 14:47:59 2006: /dev/md2 on /mnt/others2 type ext3 (rw)
Sat Apr 8 14:47:59 2006: /dev/md3 on /mnt/others type ext3 (rw)
Sat Apr 8 14:47:59 2006: proc on /mnt/others/sid-chrooted/proc type proc (rw)
Sat Apr 8 14:47:59 2006: /dev/hde1 on /mnt/vmsdata type ext3 (rw)
Sat Apr 8 14:47:59 2006: /dev/hde2 on /mnt/vms type ext3 (rw)
Sat Apr 8 14:47:59 2006: Cleaning /tmp /var/run /var/lock.
>>>---[/2.6.11 bootlog]---
Again, this all looks great.
But...
now...
booting 2.6.15 leads to a disaster.
>>>---[2.6.15 dmesg]---
md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: bitmap version 4.39
md: raid1 personality registered as nr 3
raid5: automatically using best checksumming function: pIII_sse
pIII_sse : 3916.000 MB/sec
raid5: using function: pIII_sse (3916.000 MB/sec)
md: raid5 personality registered as nr 4
md: md0 stopped.
md: bind<hdb1>
md: bind<hda1>
raid1: raid set md0 active with 2 out of 2 mirrors
md: md1 stopped.
md: bind<hdb2>
md: bind<hda2>
raid1: raid set md1 active with 2 out of 2 mirrors
md: md2 stopped.
md: bind<hdg1>
md: bind<hdc1>
md: bind<hdi1>
raid5: device hdi1 operational as raid disk 0
raid5: device hdc1 operational as raid disk 2
raid5: device hdg1 operational as raid disk 1
raid5: allocated 3162kB for md2
raid5: raid level 5 set md2 active with 3 out of 3 devices, algorithm 2
RAID5 conf printout:
--- rd:3 wd:3 fd:0
disk 0, o:1, dev:hdi1
disk 1, o:1, dev:hdg1
disk 2, o:1, dev:hdc1
md: md3 stopped.
md: bind<hdc2>
md: bind<hdg2>
raid1: raid set md3 active with 2 out of 2 mirrors
md: md4 stopped.
md: bind<hdg3>
md: bind<hdc3>
raid1: raid set md4 active with 2 out of 2 mirrors
device-mapper: 4.4.0-ioctl (2005-01-12) initialised: dm-devel@redhat.com
>>>---[/2.6.15 dmesg]---
As you might already have noticed, md0 does NOT get /dev/hda2 and
/dev/hdb2 attached, but /dev/hda1 and /dev/hdb1! Same goes for md1, md2,
md3 and md4. They all get wrong partitions.
Things get even worse further on:
>>>---[2.6.15 bootlog]---
Sat Apr 8 16:36:23 2006: bootlogd.
Sat Apr 8 16:36:23 2006: Setting parameters of disc: (none).
Sat Apr 8 16:36:23 2006: Activating swap.
Sat Apr 8 16:36:23 2006: Checking root file system...
Sat Apr 8 16:36:23 2006: fsck 1.37 (21-Mar-2005)
Sat Apr 8 16:36:23 2006: /: clean, 122181/524288 files, 508826/1048576 blocks
[...]
Sat Apr 8 14:36:28 2006: Creating device-mapper devices...done.
Sat Apr 8 14:36:28 2006: Creating device-mapper devices...done.
Sat Apr 8 14:36:28 2006: Starting raid devices: mdadm-raid5: done.
Sat Apr 8 14:36:28 2006: Setting up LVM Volume Groups...
Sat Apr 8 14:36:29 2006: Reading all physical volumes. This may take a
while...
Sat Apr 8 14:36:29 2006: Found volume group "vg" using metadata type lvm2
Sat Apr 8 14:36:29 2006: 2 logical volume(s) in volume group "vg" now
active
Sat Apr 8 14:36:30 2006: Checking all file systems...
Sat Apr 8 14:36:30 2006: fsck 1.37 (21-Mar-2005)
Sat Apr 8 14:36:30 2006: /dev/md4: clean, 2079183/7094272 files,
10865102/14185376 blocks
Sat Apr 8 14:36:30 2006: /dev/mapper/vg-home: clean, 7560/219520 files,
120502/438272 blocks
Sat Apr 8 14:36:30 2006: /: Note: if there is several inode or block
bitmap blocks
Sat Apr 8 14:36:30 2006: which require relocation, or one part of the
inode table
Sat Apr 8 14:36:30 2006: which must be moved, you may wish to try running
e2fsck
Sat Apr 8 14:36:30 2006: with the '-b 32768' option first. The problem
may lie only
Sat Apr 8 14:36:30 2006: with the primary block group descriptor, and the
backup
Sat Apr 8 14:36:30 2006: block group descriptor may be OK.
Sat Apr 8 14:36:30 2006:
Sat Apr 8 14:36:30 2006: /: Block bitmap for group 0 is not in group.
(block 1852402720)
Sat Apr 8 14:36:30 2006:
Sat Apr 8 14:36:30 2006:
Sat Apr 8 14:36:30 2006: /: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
Sat Apr 8 14:36:30 2006:
Sat Apr 8 14:36:30 2006: /dev/md2: clean, 38614/9781248 files,
15097260/19539008 blocks
Sat Apr 8 14:36:30 2006: /dev/md3: clean, 18/7325696 files,
8634921/14651264 blocks
Sat Apr 8 14:36:30 2006: /dev/hde1: clean, 74/28640 files,
26855696/29296527 blocks
Sat Apr 8 14:36:30 2006: /dev/hde2: clean, 573/9781248 files,
13186560/19543072 blocks
Sat Apr 8 14:36:30 2006:
Sat Apr 8 14:36:30 2006: fsck failed. Please repair manually.
Sat Apr 8 14:36:30 2006:
Sat Apr 8 14:36:30 2006: CONTROL-D will exit from this shell and continue
system startup.
Sat Apr 8 14:36:30 2006:
Sat Apr 8 14:36:30 2006: Give root password for maintenance
Sat Apr 8 14:36:30 2006: (or type Control-D to continue):
>>>---[/2.6.15 bootlog]---
Okay, just pressing Control-D continues the boot process and AFAIK the
root filesystemen actually isn't corrupt. Running e2fsck returns no errors
and booting 2.6.11 works just fine, but I have no clue why it picked the
wrong partitions to build md[01234].
What could have happened here?
Thanks!
^ permalink raw reply
* [ALSA - driver 0001703]: NVidia CK804 - Realtek ALC850 rev 0 - passthrough not working
From: bugtrack @ 2006-04-09 12:31 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1703>
======================================================================
Reported By: alsarealist
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1703
Category: PCI - intel8x0
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution: self burned
Kernel Version:
======================================================================
Date Submitted: 01-03-2006 18:42 CET
Last Modified: 04-09-2006 14:31 CEST
======================================================================
Summary: NVidia CK804 - Realtek ALC850 rev 0 - passthrough
not working
Description:
Pass-through with xine is not working.
PCM Stereo downmix works fine
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio
Controller (rev a2)
gcc (GCC) 4.0.2
alsa version 1.0.11rc2
Linux 2.6.15
======================================================================
----------------------------------------------------------------------
alsarealist - 01-06-06 01:03
----------------------------------------------------------------------
Using xine I got a funny effect with SPSA:
Before starting xine I set SPSA to 3:
cat /proc/asound/card0/codec97#0/ac97#0-0+regs |grep 0:2a
0:2a = 05f4
After I started xine SPSA is set back to 0:
cat /proc/asound/card0/codec97#0/ac97#0-0+regs |grep 0:2a
0:2a = 05c4
What's going on here?
I tried to play a wave file but I heared no sound.
aplay -Dplug:spdif some-sound.wav
Playing WAVE 'some-sound.wav' : Signed 16 bit Little Endian, Rate 48000
Hz, Channels 6
<silence>
During this test I had the same funny effect of switching SPSA from 3 to 0
and back to 3. Is that normal? What exactly are these "AC-LINK slots"?
Channels on SPDIF?
----------------------------------------------------------------------
alsarealist - 04-09-06 14:31
----------------------------------------------------------------------
Giving up frustrated - DTS, Dolby 5.1 seems not to be possible. Stay an
stereo.
Closing case.
Issue History
Date Modified Username Field Change
======================================================================
01-03-06 18:42 alsarealist New Issue
01-03-06 18:42 alsarealist Distribution => self burned
01-03-06 19:05 rlrevell Note Added: 0007403
01-04-06 01:45 alsarealist Note Added: 0007409
01-04-06 17:11 tiwai Note Added: 0007436
01-04-06 17:32 alsarealist File Added: asound.state
01-04-06 17:33 alsarealist Note Added: 0007443
01-04-06 17:38 alsarealist File Added: proc-asound
01-04-06 17:42 alsarealist Note Added: 0007447
01-04-06 23:11 alsarealist Note Added: 0007459
01-05-06 20:00 tiwai Note Added: 0007477
01-06-06 01:03 alsarealist Note Added: 0007486
04-09-06 14:31 alsarealist Note Added: 0009179
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Adding a new architecture to alsa-driver
From: Adrian McMenamin @ 2006-04-09 12:26 UTC (permalink / raw)
To: Jaroslav Kysela; +Cc: Lee Revell, alsa-devel
In-Reply-To: <Pine.LNX.4.61.0604091315410.22163@tm8103.perex-int.cz>
On Sun, 2006-04-09 at 13:24 +0200, Jaroslav Kysela wrote:
> On Sun, 9 Apr 2006, Adrian McMenamin wrote:
>
> > On Sat, 2006-04-08 at 21:04 -0400, Lee Revell wrote:
> > > On Sun, 2006-04-09 at 01:23 +0100, Adrian McMenamin wrote:
> > > > The changes you suggest simply are inadequate. There is no makefile
> > > > without configure and even though I have managed to patch the
> > > > configure
> > > > file so it will create a Makefile, a make simply builds the alsa core
> > > > and doesn't touch the sh sub directory despite having this in the
> > > > makefile:
> > > >
> > >
> > > Did you patch alsa-driver/configure.in?
> > >
> > > $ grep CONFIG_PARISC configure.in
> > > #elif defined(CONFIG_PARISC)
> > > AC_SUBST(CONFIG_PARISC)
> > >
> > > I don't know autoconf well enough to know exactly what this is doing but
> > > it seems like you could just copy/paste and s/PARISC/SUPERH/...
> > >
> >
> > I had to patch it in about 6 or 7 places and that was one of them
>
> Do you have a valid Kconfig file with your driver? The dependencies are
> parsed from Kconfig files.
>
Yes, though I have put it in alsa-kernel for the build as Lee suggested
(the writing a driver document doesn't say that though)
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: [Xenomai-core] kgdb over ipipe
From: Jan Kiszka @ 2006-04-09 12:15 UTC (permalink / raw)
To: xenomai-core; +Cc: adeos-main
In-Reply-To: <44377F75.9030707@domain.hid>
[-- Attachment #1.1: Type: text/plain, Size: 1606 bytes --]
Jan Kiszka wrote:
> Hi,
>
> this is the preliminary, though already usable result of my recent
> effort to extend the tool situation for Xenomai: A kgdb patch series for
> 2.6.15 on x86. It already works quite well but likely does not yet catch
> all fatal scenarios (e.g. page faults in the Xenomai domain).
>
And here comes another revision (prepare patch remains unmodified).
It gets closer to what Philippe also just suggested in the original
thread: hook KGDB into I-pipe in favour of registering a dedicated
domain. The latter approach modifies the I-pipe state in a way which may
blur the picture of I-pipe itself to the debugger. This revision hooks
exception events into the I-pipe core so that they are delivered the
normal way when the root domain is active, but get catched early for
higher domains like Xenomai. I'm just not sure about the best way to
handle the serial line IRQ. Philippe, do you see problems with current
approach? Should we better hook into __ipipe_handle_irq (which would
make things more complicated, I'm afraid)?
In contrast to the first version, exceptions happening in the Xenomai
domain now also get reported to KGDB. Debugging mostly works fine, I'm
just facing unknown problems with intercepting and then continuing
kernel-only RT threads. KGDB sometimes reports "E22" back in this case,
but always locks up. Maybe it gets confused by the fact the there is no
Linux task behind Xenomai kernel threads? I tested this by putting a
breakpoint into xnpod_suspend_thread and running latency in mode 0 and
1. 0 works fine, 1 not.
Jan
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: kgdb-ipipe.patch --]
[-- Type: text/x-patch; name="kgdb-ipipe.patch", Size: 3641 bytes --]
Index: linux-2.6.15.3-kgdb/kernel/kgdb.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/kernel/kgdb.c
+++ linux-2.6.15.3-kgdb/kernel/kgdb.c
@@ -740,7 +740,7 @@ static void kgdb_wait(struct pt_regs *re
unsigned long flags;
int processor;
- local_irq_save(flags);
+ local_irq_save_hw(flags);
processor = smp_processor_id();
kgdb_info[processor].debuggerinfo = regs;
kgdb_info[processor].task = current;
@@ -770,7 +770,7 @@ static void kgdb_wait(struct pt_regs *re
/* Signal the master processor that we are done */
atomic_set(&procindebug[processor], 0);
spin_unlock(&slavecpulocks[processor]);
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
}
#endif
@@ -1033,7 +1033,7 @@ int kgdb_handle_exception(int ex_vector,
* Interrupts will be restored by the 'trap return' code, except when
* single stepping.
*/
- local_irq_save(flags);
+ local_irq_save_hw(flags);
/* Hold debugger_active */
procid = smp_processor_id();
@@ -1056,7 +1056,7 @@ int kgdb_handle_exception(int ex_vector,
if (atomic_read(&cpu_doing_single_step) != -1 &&
atomic_read(&cpu_doing_single_step) != procid) {
atomic_set(&debugger_active, 0);
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
goto acquirelock;
}
@@ -1556,7 +1556,7 @@ int kgdb_handle_exception(int ex_vector,
kgdb_restore:
/* Free debugger_active */
atomic_set(&debugger_active, 0);
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
return error;
}
@@ -1925,9 +1925,9 @@ static int kgdb_notify_reboot(struct not
if (!kgdb_connected || atomic_read(&debugger_active) != 0)
return 0;
if ((code == SYS_RESTART) || (code == SYS_HALT) || (code == SYS_POWER_OFF)){
- local_irq_save(flags);
+ local_irq_save_hw(flags);
put_packet("X00");
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
}
return NOTIFY_DONE;
}
@@ -1942,9 +1942,9 @@ void kgdb_console_write(struct console *
if (!kgdb_connected || atomic_read(&debugger_active) != 0)
return;
- local_irq_save(flags);
+ local_irq_save_hw(flags);
kgdb_msg_write(s, count);
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
}
static struct console kgdbcons = {
Index: linux-2.6.15.3-kgdb/drivers/serial/8250_kgdb.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/drivers/serial/8250_kgdb.c
+++ linux-2.6.15.3-kgdb/drivers/serial/8250_kgdb.c
@@ -301,6 +301,10 @@ static void __init kgdb8250_late_init(vo
"GDB-stub", current_port) < 0)
printk(KERN_ERR "KGDB failed to request the serial IRQ (%d)\n",
current_port->irq);
+#ifdef CONFIG_IPIPE
+ ipipe_control_irq(current_port->irq, 0,
+ IPIPE_HANDLE_MASK|IPIPE_STICKY_MASK|IPIPE_SYSTEM_MASK);
+#endif /* CONFIG_IPIPE */
}
static __init int kgdb_init_io(void)
Index: linux-2.6.15.3-kgdb/lib/Kconfig.debug
===================================================================
--- linux-2.6.15.3-kgdb.orig/lib/Kconfig.debug
+++ linux-2.6.15.3-kgdb/lib/Kconfig.debug
@@ -250,7 +250,7 @@ choice
config KGDB_ONLY_MODULES
bool "KGDB: Use only kernel modules for I/O"
- depends on MODULES
+ depends on MODULES && !IPIPE
help
Use only kernel modules to configure KGDB I/O after the
kernel is booted.
@@ -295,7 +295,7 @@ config KGDB_SIBYTE
endchoice
config KGDBOE
- tristate "KGDB: On ethernet" if !KGDBOE_NOMODULE
+ tristate "KGDB: On ethernet" if !KGDBOE_NOMODULE && !IPIPE
depends on m && KGDB
select NETPOLL
select NETPOLL_TRAP
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: kgdb-ipipe-x86.patch --]
[-- Type: text/x-patch; name="kgdb-ipipe-x86.patch", Size: 3486 bytes --]
Index: linux-2.6.15.3-kgdb/arch/i386/kernel/entry.S
===================================================================
--- linux-2.6.15.3-kgdb.orig/arch/i386/kernel/entry.S
+++ linux-2.6.15.3-kgdb/arch/i386/kernel/entry.S
@@ -194,7 +194,7 @@ VM_MASK = 0x00020000
.previous
-ENTRY(ret_from_fork)
+KPROBE_ENTRY(ret_from_fork)
STI_COND_HW
pushl %eax
call schedule_tail
@@ -582,7 +582,7 @@ ENTRY(simd_coprocessor_error)
PUSH_XCODE(do_simd_coprocessor_error)
jmp error_code
-ENTRY(device_not_available)
+KPROBE_ENTRY(device_not_available)
pushl $-1 # mark this as an int
SAVE_ALL
DIVERT_EXCEPTION(device_not_available)
@@ -767,7 +767,7 @@ ENTRY(machine_check)
jmp error_code
#endif
-ENTRY(spurious_interrupt_bug)
+KPROBE_ENTRY(spurious_interrupt_bug)
pushl $0
PUSH_XCODE(do_spurious_interrupt_bug)
jmp error_code
Index: linux-2.6.15.3-kgdb/arch/i386/kernel/ipipe-root.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/arch/i386/kernel/ipipe-root.c
+++ linux-2.6.15.3-kgdb/arch/i386/kernel/ipipe-root.c
@@ -34,6 +34,9 @@
#include <asm/irq.h>
#include <asm/desc.h>
#include <asm/io.h>
+#ifdef CONFIG_KGDB
+#include <linux/kgdb.h>
+#endif /* CONFIG_KGDB */
#ifdef CONFIG_X86_LOCAL_APIC
#include <asm/tlbflush.h>
#include <asm/fixmap.h>
@@ -427,8 +430,44 @@ static __ipipe_exptr __ipipe_std_extable
[ex_do_iret_error] = &do_iret_error,
};
+#ifdef CONFIG_KGDB
+static int __ipipe_xlate_signo[] = {
+
+ [ex_do_divide_error] = SIGFPE,
+ [ex_do_debug] = SIGTRAP,
+ [2] = -1,
+ [ex_do_int3] = SIGTRAP,
+ [ex_do_overflow] = SIGSEGV,
+ [ex_do_bounds] = SIGSEGV,
+ [ex_do_invalid_op] = SIGILL,
+ [ex_device_not_available] = -1,
+ [8] = -1,
+ [ex_do_coprocessor_segment_overrun] = SIGFPE,
+ [ex_do_invalid_TSS] = SIGSEGV,
+ [ex_do_segment_not_present] = SIGBUS,
+ [ex_do_stack_segment] = SIGBUS,
+ [ex_do_general_protection] = SIGSEGV,
+ [ex_do_page_fault] = SIGSEGV,
+ [ex_do_spurious_interrupt_bug] = -1,
+ [ex_do_coprocessor_error] = -1,
+ [ex_do_alignment_check] = SIGBUS,
+ [ex_machine_check_vector] = -1,
+ [ex_do_simd_coprocessor_error] = -1,
+ [20 ... 31] = -1,
+ [ex_do_iret_error] = SIGSEGV,
+};
+#endif /* CONFIG_KGDB */
+
fastcall int __ipipe_handle_exception(struct pt_regs *regs, long error_code, int vector)
{
+#ifdef CONFIG_KGDB
+ /* catch exception KGDB is interested in over non-root domains */
+ if ((ipipe_current_domain != ipipe_root_domain) &&
+ (__ipipe_xlate_signo[vector] >= 0) &&
+ !kgdb_handle_exception(vector, __ipipe_xlate_signo[vector], error_code, regs))
+ return 1;
+#endif /* CONFIG_KGDB */
+
if (!__ipipe_event_pipelined_p(vector) ||
__ipipe_dispatch_event(vector,regs) == 0) {
__ipipe_exptr handler = __ipipe_std_extable[vector];
@@ -442,6 +481,19 @@ fastcall int __ipipe_handle_exception(st
fastcall int __ipipe_divert_exception(struct pt_regs *regs, int vector)
{
+#ifdef CONFIG_KGDB
+ /* catch int1 and int3 over non-root domains */
+ if ((ipipe_current_domain != ipipe_root_domain) &&
+ (vector != ex_device_not_available)) {
+ unsigned int condition = 0;
+
+ if (vector == 1)
+ get_debugreg(condition, 6);
+ if (!kgdb_handle_exception(vector, SIGTRAP, condition, regs))
+ return 1;
+ }
+#endif /* CONFIG_KGDB */
+
if (__ipipe_event_pipelined_p(vector) &&
__ipipe_dispatch_event(vector,regs) != 0)
return 1;
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [patch][rfc] quell interactive feeding frenzy
From: bert hubert @ 2006-04-09 12:14 UTC (permalink / raw)
To: Mike Galbraith
Cc: Con Kolivas, lkml, Ingo Molnar, Andrew Morton, Nick Piggin,
Peter Williams
In-Reply-To: <1144582778.13991.10.camel@homer>
On Sun, Apr 09, 2006 at 01:39:38PM +0200, Mike Galbraith wrote:
> Ok, unusable may be overstated. Nonetheless, that bit of code causes
> serious problems. It makes my little PIII/500 test box trying to fill
> one 100Mbit local network unusable. That is not overstated.
If you try to make a PIII/500 fill 100mbit of TCP/IP using lots of different
processes, that IS a corner load.
I'm sure you can fix this (rare) workload but are you very sure you are not
killing off performance for other situations?
I get flashbacks to the old days of the VM where we had lots patches around
that would all solve (more or less) real problems, but never all at the same
time..
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply
* Re: Linux v2.6.16-rc6
From: Andy Furniss @ 2006-04-09 12:08 UTC (permalink / raw)
To: David S. Miller; +Cc: michal.k.k.piotrowski, torvalds, linux-kernel, netdev
In-Reply-To: <20060311.183904.71244086.davem@davemloft.net>
David S. Miller wrote:
> From: "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com>
> Date: Sun, 12 Mar 2006 02:51:40 +0100
>
>
>>I have noticed this warnings
>>TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
>>148470938:148470943. Repaired.
>>TCP: Treason uncloaked! Peer 82.113.55.2:11759/50967 shrinks window
>>148470938:148470943. Repaired.
>>TCP: Treason uncloaked! Peer 82.113.55.2:11759/59768 shrinks window
>>1124211698:1124211703. Repaired.
>>TCP: Treason uncloaked! Peer 82.113.55.2:11759/59768 shrinks window
>>1124211698:1124211703. Repaired.
>>
>>It maybe problem with ktorrent.
>
>
> It is a problem with the remote TCP implementation, it is
> illegally advertising a smaller window that it previously
> did.
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Packeteer manipulates window for shaping. I probably misread/read wrong
RFC on this but I thought it didn't break any MUST NOTs.
I assume Linux + SFQ reordering packets during window growth would not
trigger it.
Andy.
^ 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.