* Re: [Qemu-devel] Unified device model
From: Paul Brook @ 2006-04-09 10:38 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <E1FSSRx-0004OR-Eg@lists.gnu.org>
> >>I am wondering about making unified device models architecture for open
> >>source simulators.
> >>The device models will be used in QEMU, Bochs, Xen and other open source
> >>simulators which would use the device models.
> >
> >I would support this idea, if it was possible.
>
> Why not ?
> You always could consider to add simple modules C++ to QEMU or build C++
> device -> C device interface bridge ...
I think to be acceptable to qemu (and probably also for Xen) the devices would
have to be written in C. C++ is more pain that it's worth in this context.
Of course there's no reason why we couldn't use the subset of C that's also
valid C++. You could also write C++ wrappers round the interface for bochs to
use.
I'm not a fan of binary plugins (for the same reasons I'm don't like binary
kernel modules), and don't think there's any real need to them. I can't see
any good reasons why open source devices would need to be broken out into a
separate shared library.
If you do want to accommodate proprietary binary plugins then C++ is a really
bad idea. The C++/libstdc++ ABI simply isn't stable enough to make this a
realistic option.
Paul
^ permalink raw reply
* Re: [PATCH 3/7] uts namespaces: use init_utsname when appropriate
From: Eric W. Biederman @ 2006-04-09 10:36 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Serge E. Hallyn, linux-kernel, Kirill Korotaev, herbert, sam,
xemul, James Morris
In-Reply-To: <20060409102522.GA20276@infradead.org>
Christoph Hellwig <hch@infradead.org> writes:
> And folks, please remove devel@openvz.org from this thead, it's subscribers
> only and gives everyone else nasty bounces.
Odd. I haven't been getting bounces, and I'm not subscribed.
I wonder if some of the principals in the conversation were given an
explicit exception. If so that is a subtle pain.
Eric
^ permalink raw reply
* Re: [Xenomai-help] Re: Problems using Xenoscope
From: Philippe Gerum @ 2006-04-09 10:42 UTC (permalink / raw)
To: Bernhard Walle; +Cc: xenomai
In-Reply-To: <a3vmg3-6is.ln1@domain.hid>
Bernhard Walle wrote:
> Hello,
>
> Philippe Gerum <rpm@xenomai.org> [2006-04-08]:
>
>>Bernhard Walle wrote:
>>
>>>Hello,
>>>
>>>I have problems using Xenoscope (Xenomai 2.1.0, Xenosim 2.1). The
>>>simulation works, i.e. text messages are printed on the console. I use
>>>the example from
>>>http://www.mail-archive.com/xenomai@xenomai.org.
>>>
>>>The problem is that the traces dialog is empty, there are also no items
>>>in the tree, only
>>>
>>> - System
>>> -RT/Interfaces
>>>
>>
>>It's not a bug, it's just that the tracer and some other interface
>>objects are still missing.
>
>
> Just wondering at
> http://www.linux-automation.de/konferenz/papers/Jan_Kiszka_UNI-HANNOVER_RTAI/RTAI-fusion.pdf
> I can see more functionality? Is this because this is RTAI Fusion 0.9
> and I'm trying Xenomai 2.1?
>
Nope, RTAI/fusion is dead, and Xenomai 2.0 is what would have been
RTAI/fusion 1.0 under other circumstances. This document likely
reproduces some information found in the simulator's documentation for
Xenomai, which is itself somehow a copy of the documentation found in
the original simulator called "CarbonKernel"
(www.gna.org/projects/carbonkernel/), which does provide these
functionalities, but for a different simulation system.
The CarbonKernel simulator has been adapted to use the Xenomai real-time
core instead of its own RTOS simulation models written in C++, so that
its event-driven engine could be used as a virtual hw architecture for
running the Xenomai nucleus in a simulation environment. However, due to
lack of time, a few bits have not been ported from CarbonKernel to the
Xenomai simulator, including the syscall tracer and some Tcl snippets
that present a graphical interface for manipulating the active RTOS
objects while the simulation is running. The core support for these
features is already available in the Xenomai simulator codebase since
it's part of the event-driven simulation core, but the outer interfaces
have not been plugged in.
--
Philippe.
^ permalink raw reply
* Re: Adding a new architecture to alsa-driver
From: Adrian McMenamin @ 2006-04-09 10:50 UTC (permalink / raw)
To: Lee Revell; +Cc: alsa-devel
In-Reply-To: <1144544652.22490.181.camel@mindpipe>
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
-------------------------------------------------------
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 10:52 UTC (permalink / raw)
To: Lee Revell; +Cc: alsa-devel
In-Reply-To: <1144545416.22490.184.camel@mindpipe>
On Sat, 2006-04-08 at 21:16 -0400, Lee Revell wrote:
> On Sun, 2006-04-09 at 01:23 +0100, Adrian McMenamin wrote:
> > On Sat, 2006-04-08 at 12:03 -0400, Lee Revell wrote:
> > > On Sat, 2006-04-08 at 16:35 +0100, Adrian McMenamin wrote:
> > > > I've now wasted two days of my life trying to do this and I have had no
> > > > luck, can someone explain the steps needed to added SH (ie
> > > > CONFIG_SUPERH) to the alsa-driver build. I am sure somebody knows the
> > > > steps needed to make this happen
> > >
> > > I already explained it. What *exactly* does not work if you change the
> > > Makefiles as I explained?
> >
> > 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:
> >
> > ifeq (y,$(CONFIG_SUPERH))
> > SUBDIRS += sh
> > endif
> >
> >
> >
>
> OK, how does this work - try this patch against a clean alsa-driver CVS
> checkout, then add your driver. Replace c_opts with whatever CFLAGS you
> need.
>
> Index: Makefile
> ===================================================================
> RCS file: /cvsroot/alsa/alsa-driver/Makefile,v
> retrieving revision 1.121
> diff -u -r1.121 Makefile
> --- Makefile 17 Nov 2005 11:15:20 -0000 1.121
> +++ Makefile 9 Apr 2006 01:15:23 -0000
> @@ -6,7 +6,7 @@
> ifneq ($(KERNELRELEASE),)
> # call from 2.6 kernel build system
>
> -obj-m += acore/ i2c/ drivers/ isa/ pci/ ppc/ arm/ synth/ usb/ sparc/ parisc/ pcmcia/
> +obj-m += acore/ i2c/ drivers/ isa/ pci/ ppc/ arm/ synth/ usb/ sparc/ parisc/ pcmcia/ sh/
>
> else
>
> @@ -99,6 +99,9 @@
> ifeq (y,$(CONFIG_PARISC))
> SUBDIRS += parisc
> endif
> +ifeq (y,$(CONFIG_SUPERH))
> +SUBDIRS += sh
> +endif
> CSUBDIRS += include test utils
>
> KCONFIG_FILES = $(shell find $(SND_TOPDIR) -name Kconfig) $(shell find $(SND_TOPDIR)/alsa-kernel/ -name Kconfig)
> Index: configure.in
> ===================================================================
> RCS file: /cvsroot/alsa/alsa-driver/configure.in,v
> retrieving revision 1.358
> diff -u -r1.358 configure.in
> --- configure.in 29 Mar 2006 16:52:47 -0000 1.358
> +++ configure.in 9 Apr 2006 01:15:24 -0000
> @@ -872,6 +872,8 @@
> fprintf(file, "amba");
> #elif defined(CONFIG_PARISC)
> fprintf(file, "parisc");
> +#elif defined(CONFIG_SUPERH)
> + fprintf(file, "sh");
> #elif defined(CONFIG_MVIAC3_2)
> fprintf(file, "viac3_2");
> #else
> @@ -1117,6 +1119,11 @@
> c_opts="-mno-space-regs -mfast-indirect-calls -mschedule=7200 -mdisable-fpregs"
> test "$CONFIG_ISA" = "probe" && CONFIG_ISA=
> ;;
> + sh)
> + ARCH=sh
> + c_opts="-mno-space-regs -mfast-indirect-calls -mschedule=7200 -mdisable-fpregs"
> + test "$CONFIG_ISA" = "probe" && CONFIG_ISA=
> + ;;
> viac3_2)
> ARCH=i386
> if $KCC -march=c3-2 -S -o /dev/null -xc /dev/null >/dev/null 2>&1; then
> @@ -1259,6 +1266,7 @@
> AC_SUBST(CONFIG_ISA)
> AC_SUBST(CONFIG_ISA_DMA_API)
> AC_SUBST(CONFIG_PARISC)
> +AC_SUBST(CONFIG_SUPERH)
> test "$CONFIG_ISA" = "y" && AC_DEFINE(CONFIG_SND_ISA)
>
> dnl Check for SMP...
>
I've done all of this except for the c_opts which obviously wouldn't
impact on the non-building of the sh directory. I'll have another look
shortly
-------------------------------------------------------
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] [BUG?] stalled xeno domain
From: Philippe Gerum @ 2006-04-09 10:52 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
In-Reply-To: <4437E704.4010607@domain.hid>
Jan Kiszka wrote:
> Jan Kiszka wrote:
>
>>Hi Philippe,
>>
>>debugging is nice, tracing is still nicer. As you suggested, I extended
>>the tracer with per-domain stall flags (needs some output clean-up,
>>preliminary patch attached nevertheless).
>>
>>And here is the result (full trace attached):
>>
>>
>>>:| (0x51) 0x000000c8 -1113+ 1.112 __ipipe_sync_stage+0x142 (ipipe_suspend_domain+0x56)
>>>:| fn -1112+ 1.789 __ipipe_sync_stage+0xe (ipipe_suspend_domain+0x56)
>>>:| *(0x50) 0x00000064 -1110+ 1.293 __ipipe_sync_stage+0x97 (ipipe_suspend_domain+0x56)
>>>: *fn -1109+ 1.398 do_IRQ+0x8 (__ipipe_sync_stage+0xcf)
>>>: *fn -1107+ 2.105 __do_IRQ+0xc (do_IRQ+0x21)
>>>: *fn -1105+ 1.631 handle_IRQ_event+0xd (__do_IRQ+0x9e)
>>>: *fn -1104+ 2.413 timer_interrupt+0x9 (handle_IRQ_event+0x40)
>>>: *fn -1101+ 3.022 mark_offset_tsc+0xe (timer_interrupt+0x31)
>>>: *fn -1098+ 2.721 do_timer+0x9 (timer_interrupt+0x37)
>>>:| *fn -1096+ 2.112 __ipipe_handle_irq+0xe (common_interrupt+0x18)
>>>:| *fn -1093+ 1.210 __ipipe_ack_common_irq+0xc (__ipipe_handle_irq+0xc0)
>>>:| *(0x50) 0x00000064 -1092+ 1.218 __ipipe_ack_common_irq+0x31 (__ipipe_handle_irq+0xc0)
>>>:| *fn -1091+ 1.834 mask_and_ack_8259A+0xb (__ipipe_ack_common_irq+0x5d)
>>>:| *(0x50) 0x00000064 -1089+ 1.345 __ipipe_ack_common_irq+0x9d (__ipipe_handle_irq+0xc0)
>>>:| *fn -1088 0.924 ipipe_suspend_domain+0xb (__ipipe_handle_irq+0x174)
>>>:| *(0x51) 0x000000c8 -1087+ 1.172 ipipe_suspend_domain+0x26 (__ipipe_handle_irq+0x174)
>>>:| *fn -1086+ 2.030 __ipipe_sync_stage+0xe (ipipe_suspend_domain+0x56)
>>>:| **(0x50) 0x000000c8 -1084+ 1.330 __ipipe_sync_stage+0x97 (ipipe_suspend_domain+0x56)
>>>:| **fn -1082 0.879 xnintr_clock_handler+0x8 (__ipipe_sync_stage+0x12b)
>>>:| **fn -1082+ 1.218 xnintr_irq_handler+0xb (xnintr_clock_handler+0x18)
>>>:| **fn -1080+ 1.233 xnpod_announce_tick+0x9 (xnintr_irq_handler+0x2a)
>>>:| **(0x50) 0x000000c8 -1079+ 1.736 xnpod_announce_tick+0x20 (xnintr_irq_handler+0x2a)
>>>:| **fn -1077+ 2.984 xntimer_do_tick_aperiodic+0xe (xnpod_announce_tick+0x36)
>>>:| **fn -1074+ 2.751 xnthread_timeout_handler+0x8 (xntimer_do_tick_aperiodic+0x18d)
>>>:| **fn -1072+ 1.864 xnpod_resume_thread+0xe (xnthread_timeout_handler+0x1d)
>>>:| **(0x50) 0x000000c8 -1070+ 4.699 xnpod_resume_thread+0x2b (xnthread_timeout_handler+0x1d)
>>>:| **(0x50) 0x000000c8 -1065+ 1.586 xnpod_resume_thread+0x2bf (xnthread_timeout_handler+0x1d)
>>>:| **(0x01) 0x00001237 -1063+ 2.661 xntimer_do_tick_aperiodic+0x309 (xnpod_announce_tick+0x36)
>>>:| **(0x50) 0x000000c8 -1061+ 1.263 xnpod_announce_tick+0x4f (xnintr_irq_handler+0x2a)
>>>:| **fn -1060+ 1.255 rthal_irq_end+0x8 (xnintr_irq_handler+0x46)
>>>:| **fn -1058+ 2.007 enable_8259A_irq+0x9 (rthal_irq_end+0x2e)
>>>:| **fn -1056+ 1.924 xnpod_schedule+0xe (xnintr_irq_handler+0x6e)
>>>:| **(0x50) 0x000000c8 -1054! 15.368 xnpod_schedule+0x53 (xnintr_irq_handler+0x6e)
>>>:| **fn -1039! 13.300 __switch_to+0xc (xnpod_schedule+0x689)
>>>:| **(0x50) 0x000000c8 -1026+ 1.766 xnpod_schedule+0x951 (xnpod_suspend_thread+0x27c)
>>>:| **(0x50) 0x000000c8 -1024! 18.195 xnpod_suspend_thread+0x2bb (rt_task_sleep+0x54)
>>>: **fn -1006+ 1.624 __ipipe_syscall_root+0x9 (system_call+0x20)
>>>: **fn -1004+ 1.406 __ipipe_dispatch_event+0xe (__ipipe_syscall_root+0x58)
>>>: **fn -1003+ 4.323 hisyscall_event+0xe (__ipipe_dispatch_event+0x5e)
>>>: **fn -998+ 1.398 __rt_task_sleep+0xa (hisyscall_event+0x23c)
>>>: **fn -997+ 1.789 __copy_from_user_ll+0xa (__rt_task_sleep+0x1a)
>>>: **fn -995! 15.345 rt_task_sleep+0xa (__rt_task_sleep+0x25)
>>>: **fn -980 0.879 __ipipe_syscall_root+0x9 (system_call+0x20)
>>>: **fn -979+ 1.308 __ipipe_dispatch_event+0xe (__ipipe_syscall_root+0x58)
>>>: **fn -978+ 2.451 hisyscall_event+0xe (__ipipe_dispatch_event+0x5e)
>>>: **fn -975+ 1.631 sys_rtdm_ioctl+0x8 (hisyscall_event+0x23c)
>>>: **fn -974+ 1.255 _rtdm_ioctl+0xc (sys_rtdm_ioctl+0x1b)
>>>: **fn -972+ 4.180 rtdm_context_get+0xa (_rtdm_ioctl+0x20)
>>>: **fn -968+ 1.203 __ipipe_syscall_root+0x9 (system_call+0x20)
>>>: **fn -967+ 1.345 __ipipe_dispatch_event+0xe (__ipipe_syscall_root+0x58)
>>
>>The '*' mark a stalled domain, root domain on the right. It seems to me
>>that xnpod_suspend_thread() leaves the xeno domain stalled on wake up.
>>This gets recovered somehow later.
>>
>>But here we see a different effect which finally causes the tick to get
>>frozen:
>>
>>
>>>: fn -504+ 2.075 sched_clock+0xd (schedule+0x112)
>>>: fn -502 0.992 __ipipe_stall_root+0x8 (schedule+0x18e)
>>>: *(0x50) 0x00000064 -501+ 4.022 __ipipe_stall_root+0x32 (schedule+0x18e)
>>>: *fn -497+ 1.977 __ipipe_dispatch_event+0xe (schedule+0x412)
>>>: *fn -495+ 4.210 schedule_event+0xd (__ipipe_dispatch_event+0x5e)
>>>: **(0x50) 0x000000c8 -491+ 1.428 schedule_event+0x261 (__ipipe_dispatch_event+0x5e)
>>>:| **fn -490+ 2.067 xnpod_schedule_runnable+0xe (schedule_event+0x28b)
>>>:| **fn -488 0.954 ipipe_unstall_pipeline_from+0xc (schedule_event+0x2c1)
>>>:| *(0x51) 0x000000c8 -487+ 4.646 ipipe_unstall_pipeline_from+0x25 (schedule_event+0x2c1)
>>>:| *fn -482+ 7.248 __switch_to+0xc (xnpod_schedule+0x689)
>>>:| **(0x50) 0x000000c8 -475+ 1.421 xnpod_schedule+0x77f (xnpod_suspend_thread+0x27c)
>>>:| **(0x50) 0x000000c8 -473+ 1.481 xnpod_schedule+0x951 (xnpod_suspend_thread+0x27c)
>>>:| **(0x50) 0x000000c8 -472+ 1.654 xnpod_suspend_thread+0x2bb (xnshadow_relax+0x136)
>>>:| **(0x50) 0x000000c8 -470+ 2.917 xnshadow_relax+0x154 (hisyscall_event+0x2ec)
>>>:| **fn -467+ 1.375 ipipe_reenter_root+0xb (xnshadow_relax+0x204)
>>>:| **fn -466 0.954 __ipipe_unstall_root+0x8 (ipipe_reenter_root+0x26)
>>>:| * (0x51) 0x00000064 -465+ 3.789 __ipipe_unstall_root+0x25 (ipipe_reenter_root+0x26)
>>>: * fn -461+ 1.578 send_sig+0x8 (xnshadow_relax+0x228)
>>>: * fn -460+ 1.496 send_sig_info+0xb (send_sig+0x1d)
>>>: * fn -458 0.909 __ipipe_test_and_stall_root+0x9 (send_sig_info+0x38)
>>>: **(0x50) 0x00000064 -457+ 1.699 __ipipe_test_and_stall_root+0x27 (send_sig_info+0x38)
>>>: **fn -455+ 1.203 specific_send_sig_info+0xb (send_sig_info+0x69)
>>>: **fn -454+ 1.706 __ipipe_test_root+0x8 (specific_send_sig_info+0x16)
>>>: **fn -453+ 3.360 sig_ignored+0x9 (specific_send_sig_info+0x29)
>>>: **fn -449+ 1.714 send_signal+0xb (specific_send_sig_info+0x55)
>>>: **fn -447+ 3.142 __sigqueue_alloc+0x9 (send_signal+0x3f)
>>>: **fn -444+ 1.210 kmem_cache_alloc+0xa (__sigqueue_alloc+0x42)
>>>: **fn -443 0.909 __ipipe_test_and_stall_root+0x9 (kmem_cache_alloc+0x12)
>>>: **(0x50) 0x00000064 -442+ 2.180 __ipipe_test_and_stall_root+0x27 (kmem_cache_alloc+0x12)
>>>: **fn -440+ 1.218 __ipipe_restore_root+0x8 (kmem_cache_alloc+0x52)
>>>: **fn -439+ 1.315 __ipipe_stall_root+0x8 (__ipipe_restore_root+0x11)
>>
>>No more recovery from the xeno stall, no more timer ticks.
>>
>>The special traces were generated via
>>
>>#define ipipe_mark_domain_stall(ipd,cpuid) \
>> ipipe_trace_special(0x50, ipd->priority)
>>#define ipipe_mark_domain_unstall(ipd,cpuid) \
>> ipipe_trace_special(0x51, ipd->priority)
>>
>>Any ideas? I do not find anything fishy yet that we may have introduced
>>to cause this problem.
>>
>
>
> Hmm, what about this theory: the RT-thread which got woken up in the
> first trace snippet suffered from a leaking IRQ lock. Its broken flags
> got restored on wakeup, and also when the thread went for termination
> (second trace). Therefore, we see this leaking domain stall. Possible
> explanation?
The incoming thread - after the last switch from the deleted thread -
always restores its own interrupt flag, so I don't think an IRQ lock
leakage from the deleted thread could cause what we are seing.
--
Philippe.
^ permalink raw reply
* [LARTC] Trying to do some very simple ingress limiting, no success
From: Erik Slagter @ 2006-04-09 10:53 UTC (permalink / raw)
To: lartc
[-- Attachment #1.1: Type: text/plain, Size: 1994 bytes --]
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.
=== 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).
========
IMHO it isn't that complex I want to achieve... The example of the synflood
protector also doesn't work, btw.
I am using linux 2.6.16.1 and these rules to mark:
iptables -t mangle -N classify-high
iptables -t mangle -A classify-high -j MARK --set-mark 1
iptables -t mangle -A classify-high -j ACCEPT
iptables -t mangle -N classify-medium
iptables -t mangle -A classify-medium -j MARK --set-mark 2
iptables -t mangle -A classify-medium -j ACCEPT
iptables -t mangle -N classify-low
iptables -t mangle -A classify-low -j MARK --set-mark 3
iptables -t mangle -A classify-low -j ACCEPT
The "ACCEPT"s are necessary, otherwise the classification will
overflow and all packets are marked with "3".
Thanks in advance.
[-- 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
* [uml-devel] [PATCH] uml: problem with 2G/2G host address space
From: Joris van Rantwijk @ 2006-04-09 10:57 UTC (permalink / raw)
To: user-mode-linux-devel
Hello,
I believe the current version (2.6.16.2) of UML does not work properly
on a i386 host with non-3G/1G address space split. The included patch
attempts to fix this.
On a i386 2.6.16.2 host configured with "3G/1G user/kernel split for
full 1G low memory" (VMSPLIT_3G_OPT), I found that UML would crash
on boot with the following error message:
mapping mmap stub failed, errno = 12
It soon made sense to me that a 3G/1G configured UML would crash like
this, but I then found that UML 2.6.16.2 configured for 2G/2G crashed
in exactly the same way. I think this is due to the fact that STUB_CODE
and STUB_DATA are fixed at the 3G/1G settings. After changing these
settings, everything seems to work properly in 2G/2G mode.
Bye,
Joris.
diff -urN -U 5 linux-2.6.16.2/arch/um/Kconfig.i386 linux-2.6.16.2-joris/arch/um/Kconfig.i386
--- linux-2.6.16.2/arch/um/Kconfig.i386 2006-04-07 18:56:47.000000000 +0200
+++ linux-2.6.16.2-joris/arch/um/Kconfig.i386 2006-04-09 11:33:46.000000000 +0200
@@ -33,15 +33,17 @@
However, this it experimental on 32-bit architectures, so if unsure say
N (on x86-64 it's automatically enabled, instead, as it's safe there).
config STUB_CODE
hex
- default 0xbfffe000
+ default 0xbfffe000 if !HOST_2G_2G
+ default 0x7fffe000 if HOST_2G_2G
config STUB_DATA
hex
- default 0xbffff000
+ default 0xbffff000 if !HOST_2G_2G
+ default 0x7ffff000 if HOST_2G_2G
config STUB_START
hex
default STUB_CODE
--
-------------------------------------------------------
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
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: [Xenomai-core] Proposal to use buildbot for Xenomai
From: Jan Kiszka @ 2006-04-09 10:59 UTC (permalink / raw)
To: niklaus.giger; +Cc: xenomai-core
In-Reply-To: <200604081223.11896.niklaus.giger@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2097 bytes --]
Niklaus Giger wrote:
> Am Samstag, 8. April 2006 10:44 schrieb Jan Kiszka:
>> Niklaus Giger wrote:
>>> Hi everybody
> <..>
>> This is a really great idea! Of course, I already have another test
>> candidate in mind: RTnet 8). Specifically the PPC environment would be
>> interesting, as our "buildbot" (sorry, Wolfgang G. ;) ) is typically
>> very busy so that build regressions are sometimes only detected with
>> delay on that platform. Is it also possible to explicitly trigger an
>> update and rebuild?
> Yes of course. Just select a buildslave (e.g. ppc or hcu3 ->
> http://ngiger.dyndns.org/buildbot/hcu3) and you may manually trigger it. I
> intentionally left this facility open for everybody to test it. But it would
> of course be possible to restrict it only to a few selected developers.
>
> If you want, I can help you to setup the master.cfg for a rtnet buildbot.
I would love to, but you know - time...
>
>> But also for Xenomai I would see this as a very useful tool, e.g. for
>> 2.4 build tests (I must confess I only test sporadically against this
>> kernel).
> I will add one. Could you please e-mail me (privately if you want) a working
> config (ppc, no cross compiling if possible). Or do you want to add a build
> slave under your control?
Hmm, I would prefer to just use something, especially as my PPC
experiences are quite limited :). But I guess here are qualified people
listening who can quickly dig out some config.
> <..>
>> Is there no reset button you could control via a master station, e.g. by
>> attaching some cheap electronic to a parallel or serial port?
> There is a reset button, but then you have it running and consuming
> electricity all the times.
Yep, understandable.
>> I just remember that DENX once had or still have a remote PPC test-lab
>> running. I CC'ed Wolfgang, maybe he could comment on this if and how it
>> could be used.
> I would be willing to setup a buildbot for the u-boot, too, as my board boots
> with a very outdated version of u-boot.
>
> Best regards
>
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [RFC PATCH] sbp2: remove manipulation of inquiry response
From: Jeff Garzik @ 2006-04-09 11:08 UTC (permalink / raw)
To: Stefan Richter; +Cc: linux-scsi, linux1394-devel
In-Reply-To: <4438070E.9000804@s5r6.in-berlin.de>
Stefan Richter wrote:
> I wrote:
>> This code became ineffective a few Linux releases ago and is
>> apparently not required anyway.
>
> 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.
That's expected... ATAPI-based MMC devices do that too.
Jeff
^ permalink raw reply
* [Xenomai-core] [PATCH] display domain status in I-ipipe tracer
From: Jan Kiszka @ 2006-04-09 11:09 UTC (permalink / raw)
To: Philippe Gerum; +Cc: adeos-main, xenomai-core
[-- Attachment #1.1: Type: text/plain, Size: 365 bytes --]
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.
Jan
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: ipipe-dom-state.patch --]
[-- Type: text/x-patch; name="ipipe-dom-state.patch", Size: 5450 bytes --]
---
kernel/ipipe/core.c | 4 --
kernel/ipipe/tracer.c | 77 +++++++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 71 insertions(+), 10 deletions(-)
Index: linux-2.6.15.3-kgdb/kernel/ipipe/core.c
===================================================================
--- linux-2.6.15.3-kgdb.orig/kernel/ipipe/core.c
+++ linux-2.6.15.3-kgdb/kernel/ipipe/core.c
@@ -40,7 +40,7 @@ struct ipipe_domain *ipipe_percpu_domain
ipipe_spinlock_t __ipipe_pipelock = IPIPE_SPIN_LOCK_UNLOCKED;
-struct list_head __ipipe_pipeline;
+LIST_HEAD(__ipipe_pipeline);
unsigned long __ipipe_virtual_irq_map = 0;
@@ -66,8 +66,6 @@ void ipipe_init(void)
* secondary CPUs are still lost in space.
*/
- INIT_LIST_HEAD(&__ipipe_pipeline);
-
ipd->name = "Linux";
ipd->domid = IPIPE_ROOT_ID;
ipd->priority = IPIPE_ROOT_PRIO;
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
@@ -51,6 +51,7 @@
#define IPIPE_TFLG_HWIRQ_OFF 0x0100
#define IPIPE_TFLG_FREEZING 0x0200
+#define IPIPE_TFLG_DOMSTATE_SHIFT 12 /* bits 12..15: domain stalled? */
struct ipipe_trace_point{
@@ -118,6 +119,24 @@ __ipipe_trace_point_type(char *buf, stru
static void __ipipe_print_symname(struct seq_file *m, unsigned long eip);
+static notrace void
+__ipipe_store_domain_states(struct ipipe_trace_point *point, int cpu_id)
+{
+ int i = IPIPE_TFLG_DOMSTATE_SHIFT;
+ struct list_head *pos;
+
+ list_for_each_prev(pos, &__ipipe_pipeline) {
+ struct ipipe_domain *ipd =
+ list_entry(pos, struct ipipe_domain, p_link);
+
+ if (test_bit(IPIPE_STALL_FLAG, &ipd->cpudata[cpu_id].status))
+ point->flags |= (1 << i);
+
+ if (++i > IPIPE_TFLG_DOMSTATE_SHIFT+3)
+ break;
+ }
+}
+
static notrace int __ipipe_get_free_trace_path(int old, int cpu_id)
{
int new_active = old;
@@ -282,6 +301,8 @@ restart:
point->v = v;
ipipe_read_tsc(point->timestamp);
+ __ipipe_store_domain_states(point, cpu_id);
+
/* forward to next point buffer */
next_pos = WRAP_POINT_NO(pos+1);
tp->trace_pos = next_pos;
@@ -617,6 +638,7 @@ __ipipe_print_pathmark(struct seq_file *
{
char mark = ' ';
int point_no = point - print_path->point;
+ int i;
if (print_path->end == point_no)
mark = '<';
@@ -626,6 +648,12 @@ __ipipe_print_pathmark(struct seq_file *
mark = ':';
seq_printf(m, "%c%c", mark,
(point->flags & IPIPE_TFLG_HWIRQ_OFF) ? '|' : ' ');
+
+ if (verbose_trace)
+ for (i = IPIPE_TFLG_DOMSTATE_SHIFT + 3;
+ i >= IPIPE_TFLG_DOMSTATE_SHIFT; i--)
+ seq_printf(m, "%c",
+ (point->flags & (1 << i)) ? '*' : ' ');
}
static void
@@ -695,6 +723,9 @@ static void __ipipe_print_dbgwarning(str
#ifdef CONFIG_XENO_OPT_DEBUG
" o CONFIG_XENO_OPT_DEBUG\n"
#endif /* CONFIG_XENO_OPT_DEBUG */
+#ifdef CONFIG_XENO_OPT_DEBUG_QUEUES
+ " o CONFIG_XENO_OPT_DEBUG_QUEUES (very costly)\n"
+#endif /* CONFIG_XENO_OPT_DEBUG */
#ifdef CONFIG_DEBUG_PREEMPT
" o CONFIG_DEBUG_PREEMPT\n"
#endif /* CONFIG_DEBUG_PREEMPT */
@@ -706,9 +737,44 @@ static void __ipipe_print_dbgwarning(str
static void __ipipe_print_headline(struct seq_file *m)
{
- seq_puts(m, verbose_trace ?
- " Type User Val. Time Delay Function (Parent)\n" :
- " Type Time Function (Parent)\n");
+ if (verbose_trace) {
+ const char *name[4] = { [0 ... 3] = "<unused>" };
+ struct list_head *pos;
+ int i = 0;
+
+ list_for_each_prev(pos, &__ipipe_pipeline) {
+ struct ipipe_domain *ipd =
+ list_entry(pos, struct ipipe_domain, p_link);
+
+ name[i] = ipd->name;
+ if (++i > 3)
+ break;
+ }
+
+ seq_printf(m,
+ " +----- Hard IRQs ('|': locked)\n"
+ " |+---- %s\n"
+ " ||+--- %s\n"
+ " |||+-- %s\n"
+ " ||||+- %s%s\n"
+ " ||||| +---------- "
+ "Delay flag ('+': > %d us, '!': > %d us)\n"
+ " ||||| | +- "
+ "NMI noise ('N')\n"
+ " ||||| | |\n"
+ " Type User Val. Time Delay Function "
+ "(Parent)\n",
+ name[3], name[2], name[1], name[0],
+ name[0] ? " ('*': domain stalled)" : "",
+ IPIPE_DELAY_NOTE/1000, IPIPE_DELAY_WARN/1000);
+ } else
+ seq_printf(m,
+ " +-------------- Hard IRQs ('|': locked)\n"
+ " | +- Delay flag "
+ "('+': > %d us, '!': > %d us)\n"
+ " | |\n"
+ " Type Time Function (Parent)\n",
+ IPIPE_DELAY_NOTE/1000, IPIPE_DELAY_WARN/1000);
}
static void *__ipipe_max_prtrace_start(struct seq_file *m, loff_t *pos)
@@ -914,10 +980,7 @@ static void *__ipipe_frozen_prtrace_star
seq_printf(m, "Freeze: %lld cycles, Trace Points: %d (+%d)\n\n",
print_path->point[print_path->begin].timestamp,
print_pre_trace+1, print_post_trace);
-
- seq_puts(m, verbose_trace ?
- " Type User Val. Time Delay Function (Parent)\n" :
- " Type Time Function (Parent)\n");
+ __ipipe_print_headline(m);
}
/* check if we are inside the trace range */
[-- 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 11:14 UTC (permalink / raw)
To: Mike Galbraith
Cc: Con Kolivas, lkml, Ingo Molnar, Andrew Morton, Nick Piggin,
Peter Williams
In-Reply-To: <1144419294.14231.7.camel@homer>
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.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply
* Re: [RFC PATCH] sbp2: remove manipulation of inquiry response
From: Christoph Hellwig @ 2006-04-09 11:19 UTC (permalink / raw)
To: Stefan Richter; +Cc: linux-scsi, linux1394-devel
In-Reply-To: <4438070E.9000804@s5r6.in-berlin.de>
On Sat, Apr 08, 2006 at 08:55:10PM +0200, Stefan Richter wrote:
> I wrote:
> >This code became ineffective a few Linux releases ago and is
> >apparently not required anyway.
>
> 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.
do they expect scsi1/2-style lun encoding in the cbd or not?
^ permalink raw reply
* Re: Error with OpenVPN
From: Marco d'Itri @ 2006-04-09 11:20 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <BAY108-F347C1CC9CB4D26F99E8575AECF0@phx.gbl>
On Apr 09, Claudia Scotti <claudiascotti@hotmail.com> wrote:
> I am trying to connect a client to a server by OpenVPN using DynDNS but I
> get the follwoing error message.
It's not relevant to whatever problem you may have.
It's harmless, and it will disappear when you will upgrade udev.
--
ciao,
Marco
-------------------------------------------------------
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\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: Adding a new architecture to alsa-driver
From: Jaroslav Kysela @ 2006-04-09 11:24 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: Lee Revell, alsa-devel
In-Reply-To: <1144579821.9248.0.camel@localhost.localdomain>
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.
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-------------------------------------------------------
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: 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
* [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
* [-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
* 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
* 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
* [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: [-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
* 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
* [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
* 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.