* 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
* [Xenomai-core] [PATCH] trigger I-pipe trace freezing via proc
From: Jan Kiszka @ 2006-04-09 12:08 UTC (permalink / raw)
To: Philippe Gerum; +Cc: adeos-main, xenomai-core
[-- Attachment #1.1: Type: text/plain, Size: 273 bytes --]
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.
Jan
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: ipipe-trace-trigger.patch --]
[-- Type: text/x-patch; name="ipipe-trace-trigger.patch", Size: 1333 bytes --]
Index: linux-2.6.15.3-kgdb/kernel/ipipe/tracer.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/kernel/ipipe/tracer.c
+++ linux-2.6.15.3-kgdb/kernel/ipipe/tracer.c
@@ -1005,11 +1005,28 @@ static int __ipipe_frozen_prtrace_open(s
}
static ssize_t
-__ipipe_frozen_reset(struct file *file, const char __user *pbuffer,
- size_t count, loff_t *data)
+__ipipe_frozen_ctrl(struct file *file, const char __user *pbuffer,
+ size_t count, loff_t *data)
{
+ char *end, buf[16];
+ int val;
+ int n;
+
+ n = (count > sizeof(buf) - 1) ? sizeof(buf) - 1 : count;
+
+ if (copy_from_user(buf, pbuffer, n))
+ return -EFAULT;
+
+ buf[n] = '\0';
+ val = simple_strtol(buf, &end, 0);
+
+ if (((*end != '\0') && !isspace(*end)) || (val < 0))
+ return -EINVAL;
+
down(&out_mutex);
ipipe_trace_frozen_reset();
+ if (val > 0)
+ ipipe_trace_freeze(-1);
up(&out_mutex);
return count;
@@ -1018,7 +1035,7 @@ __ipipe_frozen_reset(struct file *file,
struct file_operations __ipipe_frozen_prtrace_fops = {
.open = __ipipe_frozen_prtrace_open,
.read = seq_read,
- .write = __ipipe_frozen_reset,
+ .write = __ipipe_frozen_ctrl,
.llseek = seq_lseek,
.release = seq_release,
};
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Slow swapon for big (12GB) swap
From: Grzegorz Kulewski @ 2006-04-09 11:45 UTC (permalink / raw)
To: linux-kernel
Hi,
I am using big swap here (as a backing for potentially huge tmpfs). And I
wonder why swapon on such big (like 12GB) swap takes about 7 minutes
(continuous disk IO). Is this expected? Why it is like that? Can I do
anything to speed it up? Or maybe remove it into the background with low
priority or something like that?
Thanks in advance,
Grzegorz Kulewski
^ permalink raw reply
* Re: [-mm patch] drivers/w1/w1.c: fix a compile error
From: Evgeniy Polyakov @ 2006-04-09 11:39 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, gregkh, linux-kernel, lm-sensors
In-Reply-To: <20060409113110.GA8454@stusta.de>
On Sun, Apr 09, 2006 at 01:31:10PM +0200, Adrian Bunk (bunk@stusta.de) wrote:
> This patch fixes the following compile error:
>
> <-- snip -->
>
> ...
> CC drivers/w1/w1.o
> drivers/w1/w1.c:197: error: static declaration of 'w1_bus_type' follows non-static declaration
> drivers/w1/w1.h:217: error: previous declaration of 'w1_bus_type' was here
> make[2]: *** [drivers/w1/w1.o] Error 1
>
> <-- snip -->
>
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Thank you, Adrian, your patch is correct.
--
Evgeniy Polyakov
^ permalink raw reply
* [lm-sensors] [-mm patch] drivers/w1/w1.c: fix a compile error
From: Evgeniy Polyakov @ 2006-04-09 11:39 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Andrew Morton, gregkh, linux-kernel, lm-sensors
In-Reply-To: <20060409113110.GA8454@stusta.de>
On Sun, Apr 09, 2006 at 01:31:10PM +0200, Adrian Bunk (bunk at stusta.de) wrote:
> This patch fixes the following compile error:
>
> <-- snip -->
>
> ...
> CC drivers/w1/w1.o
> drivers/w1/w1.c:197: error: static declaration of 'w1_bus_type' follows non-static declaration
> drivers/w1/w1.h:217: error: previous declaration of 'w1_bus_type' was here
> make[2]: *** [drivers/w1/w1.o] Error 1
>
> <-- snip -->
>
> Signed-off-by: Adrian Bunk <bunk at stusta.de>
Thank you, Adrian, your patch is correct.
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [patch][rfc] quell interactive feeding frenzy
From: Mike Galbraith @ 2006-04-09 11:39 UTC (permalink / raw)
To: bert hubert
Cc: Con Kolivas, lkml, Ingo Molnar, Andrew Morton, Nick Piggin,
Peter Williams
In-Reply-To: <20060409111436.GA26533@outpost.ds9a.nl>
On Sun, 2006-04-09 at 13:14 +0200, bert hubert wrote:
> On Fri, Apr 07, 2006 at 04:14:54PM +0200, Mike Galbraith wrote:
> > Ok. Do we then agree that it makes 2.6 unusable for small servers, and
> > that this constitutes a serious problem? :)
>
> You sure? I may be down there in userspace dirt with the other actual Linux
> users, but I hadn't noticed.
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.
-Mike
^ permalink raw reply
* Re: Building a small sparc32 kernel
From: Ludovic Courtès @ 2006-04-09 11:36 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <20060404151927.GC2358@cassis>
Hi,
Yesterday, 14 hours, 55 minutes, 19 seconds ago, Wolfram Quester wrote:
> Probably I'm wrong but wasn't there an issue with the 390Z50 not having
> cache (in contrast to Z55) an thus not being supported in SMP mode?
Well, 2.4 SMP perfectly runs on this machine. :-)
Thanks,
Ludovic.
^ permalink raw reply
* [-mm patch] drivers/w1/w1.c: fix a compile error
From: Adrian Bunk @ 2006-04-09 11:31 UTC (permalink / raw)
To: Andrew Morton, gregkh, johnpol; +Cc: linux-kernel, lm-sensors
In-Reply-To: <20060408031405.5e5131da.akpm@osdl.org>
This patch fixes the following compile error:
<-- snip -->
...
CC drivers/w1/w1.o
drivers/w1/w1.c:197: error: static declaration of 'w1_bus_type' follows non-static declaration
drivers/w1/w1.h:217: error: previous declaration of 'w1_bus_type' was here
make[2]: *** [drivers/w1/w1.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- linux-2.6.17-rc1-mm2-full/drivers/w1/w1.h.old 2006-04-09 11:21:48.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/drivers/w1/w1.h 2006-04-09 11:21:57.000000000 +0200
@@ -214,7 +214,6 @@
}
extern struct device_driver w1_master_driver;
-extern struct bus_type w1_bus_type;
extern struct device w1_master_device;
extern int w1_max_slave_count;
extern int w1_max_slave_ttl;
^ permalink raw reply
* [lm-sensors] [-mm patch] drivers/w1/w1.c: fix a compile error
From: Adrian Bunk @ 2006-04-09 11:31 UTC (permalink / raw)
To: Andrew Morton, gregkh, johnpol; +Cc: linux-kernel, lm-sensors
In-Reply-To: <20060408031405.5e5131da.akpm@osdl.org>
This patch fixes the following compile error:
<-- snip -->
...
CC drivers/w1/w1.o
drivers/w1/w1.c:197: error: static declaration of 'w1_bus_type' follows non-static declaration
drivers/w1/w1.h:217: error: previous declaration of 'w1_bus_type' was here
make[2]: *** [drivers/w1/w1.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <bunk at stusta.de>
--- linux-2.6.17-rc1-mm2-full/drivers/w1/w1.h.old 2006-04-09 11:21:48.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/drivers/w1/w1.h 2006-04-09 11:21:57.000000000 +0200
@@ -214,7 +214,6 @@
}
extern struct device_driver w1_master_driver;
-extern struct bus_type w1_bus_type;
extern struct device w1_master_device;
extern int w1_max_slave_count;
extern int w1_max_slave_ttl;
^ permalink raw reply
* Re: Linux 2.6.17-rc1
From: Ralf Hildebrandt @ 2006-04-09 11:28 UTC (permalink / raw)
To: Andrew Morton; +Cc: Ralf Hildebrandt, linux-kernel, Jacob Shin, Dave Jones
In-Reply-To: <20060404014421.635b2c51.akpm@osdl.org>
* Andrew Morton <akpm@osdl.org>:
> OK, thanks. That indicates that we did install a
> acpi_processor_performance structure, but something must have later on
> zeroed it.
>
> Hopefully the cpufreq guys will be able to reproduce this.
>
> <tries it>
>
> Actually, I cannot even rmmod the thing:
>
> Module Size Used by
> p4_clockmod 6980 1
> speedstep_lib 5376 1 p4_clockmod
>
> It looks like either it has a refcounting problem or it has been changed so
> that it is deliberately pinned.
I tried 2.6.17-rc1-mm2 today and got better (?) output when modprobing
the module:
powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.60.2)
ACPI Warning (acpi_utils-0065): Invalid package argument [20060310]
ACPI Exception (acpi_processor-0275): AE_BAD_PARAMETER, Invalid _PSS data [20060310]
powernow-k8: 0 : fid 0x0 (800 MHz), vid 0x12 (1100 mV)
powernow-k8: 1 : fid 0x8 (1600 MHz), vid 0x4 (1450 mV)
cpu_init done, current fid 0x8, vid 0x4
--
_________________________________________________
Charité - Universitätsmedizin Berlin
_________________________________________________
Ralf Hildebrandt
i.A. Geschäftsbereich Informationsmanagement
Campus Benjamin Franklin
Hindenburgdamm 30 | Berlin
Tel. +49 30 450 570155 | Fax +49 30 450 570962
Ralf.Hildebrandt@charite.de
http://www.charite.de
^ 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.