* 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
* 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: 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: [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: [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
* [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: [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
* 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
* [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
* [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
* 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
* 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: 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: [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: [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: [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
* Error with OpenVPN
From: Claudia Scotti @ 2006-04-09 10:35 UTC (permalink / raw)
To: linux-hotplug
Dear list,
I am trying to connect a client to a server by OpenVPN using DynDNS but I
get the follwoing error message.
Apr 9 12:35:27 localhost wait_for_sysfs[4506]: either wait_for_sysfs (udev
039) needs an update to handle the device '/class/net/tun0' properly (no
device symlink) or the sysfs-support of your device's driver needs to be
fixed, please report to <linux-hotplug-devel@lists.sourceforge.net>
I am a novice, any suggestions, please?
Many thanks.
Claudia
Claudia Scotti
Dipartimento di Medicina Sperimentale
Sezione di Patologia Generale
Universita' di Pavia
Piazza Botta, 10
27100 Pavia
Italia
Tel. 0039 0382 986335/8/1
Facs 0039 0382 303673
-------------------------------------------------------
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
* AHCI suspend support
From: Bastian Blank @ 2006-04-09 10:30 UTC (permalink / raw)
To: jgarzik; +Cc: linux-ide
Hi Jeff
Do you know what the current state of suspend support in the AHCI driver
is? There was a patch from Hannes Reinecke some weeks ago.
Bastian
--
But Captain -- the engines can't take this much longer!
^ permalink raw reply
* [ALSA - driver 0001857]: regression in snd-cs4281 in recent 2.6.16-rcX kernels
From: bugtrack @ 2006-04-09 10:29 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1857>
======================================================================
Reported By: hoffmajs
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1857
Category: PCI - cs4281
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution: Ubuntu (Dapper)
Kernel Version: 2.6.16-rc4
======================================================================
Date Submitted: 02-19-2006 06:11 CET
Last Modified: 04-09-2006 12:29 CEST
======================================================================
Summary: regression in snd-cs4281 in recent 2.6.16-rcX
kernels
Description:
In the recent 2.6.16-rc kernels snd-cs4281 broke for me.
(I think since 2.6.16-rc2, but Im not sure atm. In 2.6.15 the card works
fine.)
# > modprobe snd-cs4281
ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LNKC] -> GSI 5 (level, low)
-> IRQ 5
never read ISV3 and ISV4 from AC'97
ACPI: PCI interrupt for device 0000:00:08.0 disabled
CS4281: probe of 0000:00:08.0 failed with error -5
and no soundcard is found.
If you need more info or want me to test something, please say so.
kind regards,
Jens
======================================================================
----------------------------------------------------------------------
tiwai - 04-07-06 19:16
----------------------------------------------------------------------
Hm, how 2.6.17rc1? The timeout check in the probe routine was fixed.
----------------------------------------------------------------------
Mo6eB - 04-09-06 12:29
----------------------------------------------------------------------
2.6.17-rc1 fixed it for me.
Issue History
Date Modified Username Field Change
======================================================================
02-19-06 06:11 hoffmajs New Issue
02-19-06 06:11 hoffmajs Distribution => Ubuntu (Dapper)
02-19-06 06:11 hoffmajs Kernel Version => 2.6.16-rc4
03-02-06 16:05 tiwai Note Added: 0008319
04-05-06 10:33 julienbras Note Added: 0009119
04-07-06 13:11 Mo6eB Note Added: 0009138
04-07-06 19:16 tiwai Note Added: 0009142
04-09-06 12:29 Mo6eB Note Added: 0009178
======================================================================
-------------------------------------------------------
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: [RFC] Patch to fix cdrom being confused on using kdump
From: Jens Axboe @ 2006-04-09 10:29 UTC (permalink / raw)
To: Rachita Kothiyal; +Cc: linux-kernel
In-Reply-To: <20060407135714.GA25569@in.ibm.com>
On Fri, Apr 07 2006, Rachita Kothiyal wrote:
> Hi Jens
>
> As we had discussed earlier, I had seen the cdrom drive appearing
> confused on using kdump on certain x86_64 systems. During the booting
> up of the second kernel, the following message would keep flooding
> the console, and the booting would not proceed any further.
>
> hda: cdrom_pc_intr: The drive appears confused (ireason = 0x01)
>
> In this patch, whenever we are hitting a confused state in the interrupt
> handler with the DRQ set, we clear the DSC bit of the status register and
> return 'ide_stopped' from the interrupt handler.
>
> Please provide your comments and feedback.
>
> Thanks
> Rachita
>
>
> Signed-off-by: Rachita Kothiyal <rachita@in.ibm.com>
> ---
>
> drivers/ide/ide-cd.c | 5 +++++
> 1 files changed, 5 insertions(+)
>
> diff -puN drivers/ide/ide-cd.c~cdrom-confused-clrinterrupt drivers/ide/ide-cd.c
> --- linux-2.6.16-mm2/drivers/ide/ide-cd.c~cdrom-confused-clrinterrupt 2006-03-29 11:23:18.000000000 +0530
> +++ linux-2.6.16-mm2-rachita/drivers/ide/ide-cd.c 2006-04-07 19:05:48.962710872 +0530
> @@ -1450,6 +1450,11 @@ static ide_startstop_t cdrom_pc_intr (id
> rq->sense_len += thislen;
> } else {
> confused:
> + if (( stat & DRQ_STAT) == DRQ_STAT) {
if (stat & DRQ_STAT)
checking for DRQ_STAT again doesn't make sense, how can it ever be
anything but DRQ_STAT if DRQ_STAT is set?
> + /* DRQ is set. Interrupt not welcome now. Ignore */
> + HWIF(drive)->OUTB((stat & 0xEF), IDE_STATUS_REG);
> + return ide_stopped;
And this looks very wrong, you can't write to the status register. Well
you can, but then it's the command register! Writing stat & 0xef to the
command register is an odd thing to do. I think you just want to clear
the DRQ bit, which should be fine after it was read initially. How about
if (stat & DRQ_STAT)
return ide_stopped;
Can you test that?
--
Jens Axboe
^ permalink raw reply
* [lm-sensors] Question on my mainboard
From: Rudolf Marek @ 2006-04-09 10:29 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <200603282150.16130.dieter.jurzitza@t-online.de>
Dieter Jurzitza wrote:
> Dear Rudolf,
> would you kindly tell me where activate this debugging stuff? I looked a bit
> through the sensors-sources but I haven't got a clue.
If you have the 2.6 kernel and I think you have so it should be
in kernel menu in i2c section.
Regards
Rudolf
^ permalink raw reply
* Re: [PATCH 3/7] uts namespaces: use init_utsname when appropriate
From: Christoph Hellwig @ 2006-04-09 10:25 UTC (permalink / raw)
To: Christoph Hellwig, Eric W. Biederman, Serge E. Hallyn,
linux-kernel, Kirill Korotaev, herbert, sam, xemul, James Morris
In-Reply-To: <20060409101436.GA20084@infradead.org>
And folks, please remove devel@openvz.org from this thead, it's subscribers
only and gives everyone else nasty bounces.
^ permalink raw reply
* [lm-sensors] Question on my mainboard
From: Dieter Jurzitza @ 2006-04-09 10:16 UTC (permalink / raw)
To: lm-sensors
In-Reply-To: <200603282150.16130.dieter.jurzitza@t-online.de>
Dear Rudolf,
would you kindly tell me where activate this debugging stuff? I looked a bit
through the sensors-sources but I haven't got a clue.
Thank you very much,
take care
Dieter
Am Mittwoch, 5. April 2006 10:28 schrieb Rudolf Marek:
*******
> If you wish to help solve the issue continue using the w93781d and
> tick in the config of i2c the debug stuff. (Bus driver debug) So we will
*******
--
-----------------------------------------------------------
|
\
/\_/\ |
| ~x~ |/-----\ /
\ /- \_/
^^__ _ / _ ____ /
<??__ \- \_/ | |/ | |
|| || _| _| _| _|
if you really want to see the pictures above - use some font
with constant spacing like courier! :-)
-----------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 3/7] uts namespaces: use init_utsname when appropriate
From: Christoph Hellwig @ 2006-04-09 10:14 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Serge E. Hallyn, linux-kernel, Kirill Korotaev, herbert, devel,
sam, xemul, James Morris
In-Reply-To: <m164ljjd70.fsf@ebiederm.dsl.xmission.com>
On Sun, Apr 09, 2006 at 03:44:19AM -0600, Eric W. Biederman wrote:
> There are two ways to avoid the associated problems.
> - modify daemonize to always use the instance of that
> namespace associated with init_task.
> - modify all interesting kernel threads to use the
> kthread api instead of kernel_thread. Using kthread
> makes the kernel threads children of keventd and always
> in the initial namespace instance. As such we know
> we aren't inside of any user space namespace instance.
I've added a deprecation entry for the kernel_thread export and plan
to convert all users to the kthread API. Any help on that is of course
greatly appreciated.
^ permalink raw reply
* [LARTC] Re: source routing does not work with extra ip addresses
From: richard lucassen @ 2006-04-09 10:12 UTC (permalink / raw)
To: lartc
On Sat, 8 Apr 2006 15:31:24 -0500
"Martin A. Brown" <martin-lartc@wonderfrog.net> wrote:
> Only way I have done this myself, although I recall somebody else on
> LARTC using connmark with nfmark and/or the ROUTE target to solve
> this problem using only a single IP. Perhaps the archive will help
> you here....
Ok. I have a working workaround now using fwmarks and a second ip on the
server. That was a very good idea. Thnx! Bu so far so good. Now I'd
like to get it working with 1 ip..
> : That's a very nice idea, but packets keep on entering the wrong
> : table (default), I think it's a bug somewhere in the kernel.
>
> While the kernel certainly has seen bugs before and will see more, I
> hope you don't mind if I continue to entertain a bit of skepticism
> on this point. :)
Ok, it's not a bug in the kernel, it's a bug in the docs :)
[..]
> Routing tables t_eth0 and t_eth1 look fine, although t_eth0 and main
> should be exactly the same. I believe your two host routes (for
> 192.168.201.3 and 10.1.3.100) are unnecessary and simply complicate
> your scenario.
Hmm. You're right. I just need 1 extra table, not two. I just followed
the docs in the lartc-howto, I'll have a closer look at their example
there. I think that 1 extra table does the same job in that example
http://www.lartc.org/lartc.html#LARTC.RPDB.MULTIPLE-LINKS
> I still think your problem is in the RPDB and addressing of the
> packet at routing time. I do not believe (check the KPTD and its
> offspring [0] [1]) that the packet's source address has yet been
> rewritten. Think about this, and look at your RPDB:
>
> : # ip ru s
> : 0: from all lookup local
> : 32762: from all fwmark 0x1 lookup t_eth1
> : 32764: from 192.168.201.2 lookup t_eth1
> : 32765: from 10.1.3.101 lookup t_eth0
> : 32766: from all lookup main
> : 32767: from all lookup default
>
> The addresses you have entered are the public side addresses. When
> the server transmits packets, these packets will have the 10.0.2.1
> and 10.0.2.3 addresses for source addresses. The RPDB should
> include references to these private addresses instead of the
> addresses available on the public side.
Once again you're right. I accidently commented out the necessary
"ip r f c" (flush cache) in the script, that's why it didn't work
(immediately).
But finally I resolved the problem using the CONNMARK. This is the setup
I'm talking about:
http://www.lucassen.org/divers/ar-test.pdf
I don't know if this is the right way to do this, but it seems to work
well. I mark all packets coming in to 192.168.201.3 through eth1 with
mark 1:
iptables -t mangle -A PREROUTING -i eth1 -d 192.168.201.3 \
-j CONNMARK --set-mark 1
I mark the return packets with the same mark:
iptables -t mangle -A PREROUTING -i eth2 -s 10.0.2.1 \
-j CONNMARK --restore-mark
A simple
ip rule add fwmark 1 table t_eth1
ip r f c
does the rest. I have now 1 ip address on the server and two routes to
the internet. And 1 extra table instead of two ;-)
Thnx for your help,
R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.
+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ 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.