Re: swap-prefetch: 2.6.22 -mm merge plans
On 5/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Ray Lee wrote:
> On 5/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
>
>> You said it helped with the updatedb problem. That says we should look at
>> why it is going bad first, and for example improve use-once algorithms.
>> After we do that, then swap prefetching might still help, which is fine.
>
> Nick, if you're volunteering to do that analysis, then great. If not,
> then you're just providing a airy hope with nothing to back up when or
> if that work would ever occur.
I'd like to try helping. Tell me your problem.
Huh? You already stated one version of it above, namely updatedb. But
let's put this another way, shall we? A gedankenexperiment, if you
will.
Say we have a perfect swap-out algorithm that can choose exactly what
needs to be evicted to disk. ('Perfect', of course, is dependent upon
one's metric, but let's go with "maximizes overall system utilization
and minimizes IO wait time." Arbitrary, but hey.)
So, great, the right things got swapped out. Anything else that could
have been chosen would have caused more overall IO Wait. Yay us.
So what happens when those processes that triggered the swap-outs go
away? (Firefox is closed, I stop hitting my local copy of a database,
whatever.) Well, currently, nothing. What happens when I switch
workspaces and try to use my email program? Swap-ins.
Okay, so why didn't the system swap that stuff in preemptively? Why am
I sitting there waiting for something that it could have already done
in the background?
A new swap-out algorithm, be it use-once, Clock-Pro, or perfect
foreknowledge isn't going to change that issue. Swap prefetch does.
> Further, if you or someone else *does* do that work, then guess what,
> we still have the option to rip out the swap prefetching code after
> the hypothetical use-once improvements have been proven and merged.
> Which, by the way, I've watched people talk about since 2.4. That was,
> y'know, a *while* ago.
What's wrong with the use-once we have? What improvements are you talking
about?
You said, effectively: "Use-once could be improved to deal with
updatedb". I said I've been reading emails from Rik and others talking
about that for four years now, and we're still talking about it. Were
it merely updatedb, I'd say us userspace folk should step up and
rewrite the damn thing to amortize its work. However, I and others
feel it's only an example -- glaring, obviously -- of a more pervasive
issue. A small issue, to be sure!, but an issue nevertheless.
In general, I/others are talking about improving the desktop
experience of running too much on a RAM limited machine. (Which, in my
case, is with a gig and a 2.2GHz processor.)
Or restated: the desktop experience occasionally sucks for me, and I
don't think I'm alone. There may be a heuristic, completely isolated
from userspace (and so isn't an API the kernel has to support! -- if
it doesn't work, we can rip it out again), that may mitigate the
suckiness. Let's try it.
> So enough with the stop energy, okay? You're better than that.
I don't think it is about energy or being mean, I'm just stating the
issues I have with it.
Nick, I in no way think you're being mean, and I'm sorry if I've given
you that impression. However, if you're just stating the issues you
have with it, then can I assume that you won't lobby against having
this experiment merged?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] timer: parenthesis fix in tbase_get_deferrable() etc.
On Wed, May 09, 2007 at 11:59:39PM +0530, Satyam Sharma wrote:
> On 5/9/07, Pallipadi, Venkatesh <[EMAIL PROTECTED]> wrote:
> >
> >>-Original Message-
> >>From: Jarek Poplawski [mailto:[EMAIL PROTECTED]
> >>Sent: Tuesday, May 08, 2007 10:32 PM
> >>To: Andrew Morton
> >>Cc: Pallipadi, Venkatesh; linux-kernel@vger.kernel.org; Oleg Nesterov
> >>Subject: Re: [PATCH -mm] timer: parenthesis fix in
> >>tbase_get_deferrable() etc.
> >>
> >>On Tue, May 08, 2007 at 04:33:58PM -0700, Andrew Morton wrote:
> >>> On Tue, 8 May 2007 12:33:48 +0200
> >>> Jarek Poplawski <[EMAIL PROTECTED]> wrote:
...
> >>> > static inline unsigned int tbase_get_deferrable(tvec_base_t *base)
> >>> > {
> >>> > - return ((unsigned int)(unsigned long)base &
> >>TBASE_DEFERRABLE_FLAG);
> >>> > + return (unsigned int)((unsigned long)base &
> >>TBASE_DEFERRABLE_FLAG);
> >>> > }
> >>...
> >>> The change makes sense, but does it actually "fix" anything?
> >>>
> >>
> >>Yes - this first place fixes logical error, so it's a sin
> >>- even if not punishable in practice. (It's also unnecessary
> >>test for long to int conversion.)
> >>
> >
> >I am sorry, I don't understand. What is the logical error in the first
> >one?
I am sorry, too - for my "logic". It seems it's all correct!
(Except, I don't know what's going here...)
> >
> >Actually, your change makes it different from what was originally
> >indended.
> >Original intention was to type convert base to a 32 bit value and
> >bitwise& with FLAG.
>
> But that is not what the original code is doing. If you wanted to
> typecast "base" to "a 32 bit value" then you should've used u32
> instead.
>
> Anyway, if you originally intended to actually typecast "base" to
> unsigned int, then you could do that directly without typecasting it
> first to unsigned long (unnecessarily) and then to unsigned int. Of
> course, if your system implements a pointer as something bigger than
> unsigned int (which is what you eventually convert "base" to), then
> you're screwed anyway and the intermediate typecast to unsigned long
> doesn't buy you anything at all.
>
> The other 3 changes in this patch were clearly meaningless, though.
>
((unsigned int)(unsigned long)base ...
((tvec_base_t *)((unsigned long)base ...
((tvec_base_t *)((unsigned long)(timer->base) ...
(tvec_base_t *)((unsigned long)(new_base) ...
Yes, if you don't count reading this one close each other, they are
clearly meaningles.
Regards,
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Different scheduler behavior between 2.4 and 2.6
Hi, Recently I met a problem on different scheduler behavior between 2.4.22 and 2.6.18.8. The application works as a proxy, it listen on an interface, connect through another interface. This application works on a box with two Xeon cpu, each of them is hyper-threading. On 2.4.22, CPU0 serve interrupts, the application works on other three CPUs. But on 2.6.18.8, if I turn on 'noirqbalance' kernel parameter, and no irqbalance process, the application will stuck to CPU0 as well as interrupts after several seconds' working. Then there will be a 0% idle cpu, and three 100%idle CPUs. /proc/interrupt shows all eths's interrupts are working at CPU0. It seems that scheduler ignores the working load of interrupts. My question is, is there a way to tune 2.6 kernel working as 2.4? Just one cpu for interrupts, other three cpu for normal work. -- Quan Sun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] MMC updates
Russell King wrote: > See the comments immediately above and below its use. > > Welcome to buggy hardware. > > I've read through the erratum, and to me it seems like the bug affects all long replies, not just these codes. So I think the code should be fixed to look at the response flag, not the opcode. Do you have hardware so that you can test such a change? -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Section mismatch warnings (was Re: [PATCH] early_pfn_to_nid needs to be __meminit)
Add to CC: Sam-san. :-) > On Wed, 2007-05-09 at 14:45 -0500, Linas Vepstas wrote: > > On Wed, May 09, 2007 at 06:51:15PM +0200, Gabriel Paubert wrote: > > > On Thu, May 10, 2007 at 02:25:52AM +1000, Stephen Rothwell wrote: > > > > This removes a section mismatch warning in those circumstances. > > > > > > Speaking of this, I just tried to compile an official (Linus' git tree) > > > kernel for my old PMac G4 and I get a lot of section mismatch warnings at > > > the end of the compilation: > > > > > > WARNING: arch/powerpc/mm/built-in.o - Section mismatch: reference to > > > .init.text:early_get_page from .text between 'pte_alloc_one_kernel' (at > > > offset 0xf50) and 'v_mapped_by_bats' > > > > > > I find these 50 or so warnings so scary that I've not yet tried > > > to boot the kernel. Note that this is a non-modular kernel. > > > > I'm getting oodles of these on an older -mm2 tree. The kernels seem to > > work fine. Yes, they should be fixed but I'm up to my proverbial eyballs > > in alligators. > > Yeah, I see all kinds of this too. Does anyone have an idea why they're > being spit out? Or if it's related to a particular binutils version, > etc? These warnings are showed by scripts/mod/modposts.c. It checks section mismatch stricter than before. Some of them are not defined as __init even if it's called at just boottime. This is simple to fix. Second case is that the functions judge which functions should call (boottime or normal) by themselves. pte_alloc_one_kernel() looks its case. In this case, they must be registered in whitelist of modpost.c Other possibility is they are just rare called functions. It should be investigated Bye. -- Yasunori Goto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Add hard_irq_disable()
On Thu, 10 May 2007 15:25:58 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> --- linux-cell.orig/include/linux/interrupt.h 2007-05-10 14:51:22.0
> +1000
> +++ linux-cell/include/linux/interrupt.h 2007-05-10 15:18:04.0
> +1000
> @@ -241,6 +241,16 @@ static inline void __deprecated save_and
> #define save_and_cli(x) save_and_cli()
> #endif /* CONFIG_SMP */
>
> +/* Some architectures might implement lazy enabling/disabling of
> + * interrupts. In some cases, such as stop_machine, we might want
> + * to ensure that after a local_irq_disable(), interrupts have
> + * really been disabled in hardware. Such architectures need to
> + * implement the following hook.
> + */
> +#ifndef hard_irq_disable
> +#define hard_irq_disable() do { } while(0)
> +#endif
We absolutely require that the architecture's hard_irq_disable() be defined
when we do this. If it happens that the definition of hard_irq_disable()
is implemented three levels deep in nested includes then we risk getting
into a situation where different .c files see different implementations of
hard_irq_disable(), which could lead to confusing results, to say the least.
Your implementation comes via the inclusion of system.h which then includes
hw_irq.h. That's perhaps a little fragile and it would be better to
a) include in the comment the name of the arch file which must implement
hard_irq_disable() and
b) include that file directly from this one.
Oh, and your comment layout style is wrong ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] stop_machine() now uses hard_irq_disable
On Thu, 2007-05-10 at 15:25 +1000, Benjamin Herrenschmidt wrote: > Add a call to hard_irq_disable() to stop_machine so that we make sure > IRQs are really disabled and not only lazy-disabled on archs like > powerpc as some users of stop_machine() may rely on that. > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Acked-by: Rusty Russell <[EMAIL PROTECTED]> Thanks, Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 7/9] lguest: the net driver
Rusty Russell wrote:
Hi Jeff,
Thanks for your review. Questions below.
On Wed, 2007-05-09 at 08:28 -0400, Jeff Garzik wrote:
[EMAIL PROTECTED] wrote:
+static void transfer_packet(struct net_device *dev,
...
+ hcall(LHCALL_SEND_DMA, peer_key(info,peernum), __pa(), 0);
__pa() should not be used in any driver.
At the very least, lguest helper code should wrap this.
I realize your continual battle with this, but adding a layer of
indirection doesn't seem like it will add clarity. The issues with
__pa() are reasonably known (don't hand it a vmalloc address, for
example). Any wrapper I create would be another hurdle to jump 8(
You don't want this low level stuff in drivers.
All such details should be hidden away in the arch code, which in your
case is the lguest support code.
lguest should present a nice, friendly driver API that any Computer
Science freshman at university will understand. Because that's the
level at which we driver writers exist... :)
+static irqreturn_t lguestnet_rcv(int irq, void *dev_id)
...
+ return done ? IRQ_HANDLED : IRQ_NONE;
Using NAPI would be preferable...
I'm not so convinced: scheduling tends to give us pretty good interrupt
mitigation. However, if you wish to send a patch, I'd be happy to
benchmark the two 8)
NAPI means system-wide load leveling, across multiple network
interfaces. Lack of NAPI can mean competition at higher loads. Though
maybe that's less important with lguest.
+ /* Ethernet defaults with some changes */
+ ether_setup(dev);
+ dev->set_mac_address = NULL;
why NULL?
Because it's not implemented: our MAC is advertised in the device page
and we'd have to change it there too.
Trivial to do, but is there a compelling reason to implement it?
Bonding, and situations where you /do/ want the MAC address to "leak"
out of the host onto the wider net.
+ dev->mem_start = ((unsigned long)desc->pfn << PAGE_SHIFT);
+ dev->mem_end = dev->mem_start + PAGE_SIZE * desc->num_pages;
+ dev->irq = lgdev->index+1;
don't fill in mem_start, mem_end and irq. they are useless, and for
lguest, misleading.
You meant to type "useful and accurate", I think? They show up in
ifconfig, so you can see what the underlying devices are using. They're
as useful for virtual hardware as they are for physical hardware.
Indeed -- they are useless for physical hardware, as well.
Those items have not been used since the ISA days. Hardware is far more
complex than those three variables can provide, so the wise choice is to
SET_NETDEV_DEV() to your device, which reveals all manner of bus
information by reference.
Storing information in those variables is needless duplication, which is
why they have been relegated only to ancient ISA drivers -- or in the
case of ->mem_start, repurposed as a method of passing options.
+ dev->features = NETIF_F_SG;
+ if (desc->features & LGUEST_NET_F_NOCSUM)
+ dev->features |= NETIF_F_NO_CSUM;
do not set SG without an accompanying csum bitflag
That seems... odd. My driver can do SG, and may or may not need csums.
The current Linux code turns SG off if I need csums and that's fine, but
it hardly seems like my device should be making that decision.
The net stack does not have a safety cushion. Set the wrong flags, and
things can and will go wrong. SG without CSUM support is illogical, and
can and will break things. Remember what SG is for. If you cannot
offload the csum, you have to build the csum yourself, at which point
you might as well copy it too. grep around for skb_copy_and_csum_dev()
to see if that helps you at all.
+static struct lguest_driver lguestnet_drv = {
+ .name = "lguestnet",
+ .owner = THIS_MODULE,
+ .device_type = LGUEST_DEVICE_T_NET,
+ .probe = lguestnet_probe,
+};
You are distinctly missing module remove support
Yes. It is never built as a module currently (though it should work).
That's my point. It won't work as a module, because it lacks remove
support. It is not unrealistic to think of [un|re|]loading the net
support module in an lguest guest. And, adding module support makes the
programmer more responsible, because they now have to learn to clean up
after themselves. Any driver that cannot clean up after itself is an
incomplete driver in my book.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/7] libata: check for AN support
On Thu, 10 May 2007 01:14:38 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > >> + *@dev: Device to which command will be sent > >> + * > >> + *Issue SET FEATURES - SATA FEATURES command to device @dev > >> + *on port @ap. > >> + * > >> + *LOCKING: > >> + *PCI/etc. bus probe sem. > >> + * > >> + *RETURNS: > >> + *0 on success, AC_ERR_* mask otherwise. > >> + */ > > > > ooh, locking and return value documentation. Often missed, and nice. > > > We set high standards in the libata world ;-) > It seems to be working. This series is perhaps the most idiomatic and generally kernelly-looking code I've seen in ages. Who cares if it works? ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] powerpc: Fixup hard_irq_disable semantics
This patch renames the raw hard_irq_{enable,disable} into
__hard_irq_{enable,disable} and introduces a higher level
hard_irq_disable() function that can be used by any code
to enforce that IRQs are fully disabled, not only lazy
disabled.
The difference with the __ versions is that it will update
some per-processor fields so that the kernel keeps track and
properly re-enables them in the next local_irq_disable();
This prepares powerpc for my next patch that introduces
hard_irq_disable() generically.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
arch/powerpc/kernel/irq.c |2 +-
arch/powerpc/kernel/swsusp.c|4
arch/powerpc/platforms/cell/pervasive.c |6 ++
include/asm-powerpc/hw_irq.h| 11 +--
4 files changed, 12 insertions(+), 11 deletions(-)
Index: linux-cell/arch/powerpc/kernel/irq.c
===
--- linux-cell.orig/arch/powerpc/kernel/irq.c 2007-05-10 14:58:56.0
+1000
+++ linux-cell/arch/powerpc/kernel/irq.c2007-05-10 14:58:59.0
+1000
@@ -173,7 +173,7 @@ void local_irq_restore(unsigned long en)
lv1_get_version_info();
}
- hard_irq_enable();
+ __hard_irq_enable();
}
#endif /* CONFIG_PPC64 */
Index: linux-cell/arch/powerpc/kernel/swsusp.c
===
--- linux-cell.orig/arch/powerpc/kernel/swsusp.c2007-05-10
14:57:03.0 +1000
+++ linux-cell/arch/powerpc/kernel/swsusp.c 2007-05-10 14:57:07.0
+1000
@@ -36,8 +36,4 @@ void restore_processor_state(void)
#ifdef CONFIG_PPC32
set_context(current->active_mm->context.id, current->active_mm->pgd);
#endif
-
-#ifdef CONFIG_PPC64
- hard_irq_enable();
-#endif
}
Index: linux-cell/arch/powerpc/platforms/cell/pervasive.c
===
--- linux-cell.orig/arch/powerpc/platforms/cell/pervasive.c 2007-05-10
14:57:34.0 +1000
+++ linux-cell/arch/powerpc/platforms/cell/pervasive.c 2007-05-10
14:57:54.0 +1000
@@ -43,12 +43,10 @@ static void cbe_power_save(void)
unsigned long ctrl, thread_switch_control;
/*
-* We need to hard disable interrupts, but we also need to mark them
-* hard disabled in the PACA so that the local_irq_enable() done by
-* our caller upon return propertly hard enables.
+* We need to hard disable interrupts, the local_irq_enable() done by
+* our caller upon return will hard re-enable.
*/
hard_irq_disable();
- get_paca()->hard_enabled = 0;
ctrl = mfspr(SPRN_CTRLF);
Index: linux-cell/include/asm-powerpc/hw_irq.h
===
--- linux-cell.orig/include/asm-powerpc/hw_irq.h2007-05-10
14:51:43.0 +1000
+++ linux-cell/include/asm-powerpc/hw_irq.h 2007-05-10 14:59:32.0
+1000
@@ -48,8 +48,15 @@ extern void iseries_handle_interrupts(vo
#define irqs_disabled()(local_get_flags() == 0)
-#define hard_irq_enable() __mtmsrd(mfmsr() | MSR_EE, 1)
-#define hard_irq_disable() __mtmsrd(mfmsr() & ~MSR_EE, 1)
+#define __hard_irq_enable()__mtmsrd(mfmsr() | MSR_EE, 1)
+#define __hard_irq_disable() __mtmsrd(mfmsr() & ~MSR_EE, 1)
+
+#define hard_irq_disable()\
+ do {\
+ __hard_irq_disable(); \
+ get_paca()->soft_enabled = 0; \
+ get_paca()->hard_enabled = 0; \
+ } while(0)
#else
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Add hard_irq_disable()
Some architectures, like powerpc, implement lazy disabling of
interrupts. That means that on those, local_irq_disable() doesn't
actually disable interrupts on the CPU, but only sets some per
CPU flag which cause them to be disabled only if an interrupt actually
occurs.
However, in some cases, such as stop_machine, we really want
interrupts to be fully disabled. For example, I have code using
stop machine to do ECC error injection, used to verify operations
of the ECC hardware, that sort of thing. It really needs to make
sure that nothing is actually writing to memory while the injection
happens. Similar examples can be found in other low level bits and
pieces.
This patch implements a generic hard_irq_disable() function which
is meant to be called -after- local_irq_disable() and ensures that
interrupts are fully disabled on that CPU. The default implementation
is a nop, though powerpc does already provide an appropriate one.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
include/linux/interrupt.h | 10 ++
1 file changed, 10 insertions(+)
Index: linux-cell/include/linux/interrupt.h
===
--- linux-cell.orig/include/linux/interrupt.h 2007-05-10 14:51:22.0
+1000
+++ linux-cell/include/linux/interrupt.h2007-05-10 15:18:04.0
+1000
@@ -241,6 +241,16 @@ static inline void __deprecated save_and
#define save_and_cli(x)save_and_cli()
#endif /* CONFIG_SMP */
+/* Some architectures might implement lazy enabling/disabling of
+ * interrupts. In some cases, such as stop_machine, we might want
+ * to ensure that after a local_irq_disable(), interrupts have
+ * really been disabled in hardware. Such architectures need to
+ * implement the following hook.
+ */
+#ifndef hard_irq_disable
+#define hard_irq_disable() do { } while(0)
+#endif
+
/* PLEASE, avoid to allocate new softirqs, if you need not _really_ high
frequency threaded job scheduling. For almost all the purposes
tasklets are more than enough. F.e. all serial device BHs et
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] stop_machine() now uses hard_irq_disable
Add a call to hard_irq_disable() to stop_machine so that we make sure
IRQs are really disabled and not only lazy-disabled on archs like
powerpc as some users of stop_machine() may rely on that.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
kernel/stop_machine.c |2 ++
1 file changed, 2 insertions(+)
Index: linux-cell/kernel/stop_machine.c
===
--- linux-cell.orig/kernel/stop_machine.c 2007-05-10 14:46:08.0
+1000
+++ linux-cell/kernel/stop_machine.c2007-05-10 14:47:12.0 +1000
@@ -45,6 +45,7 @@ static int stopmachine(void *cpu)
if (stopmachine_state == STOPMACHINE_DISABLE_IRQ
&& !irqs_disabled) {
local_irq_disable();
+ hard_irq_disable();
irqs_disabled = 1;
/* Ack: irqs disabled. */
smp_mb(); /* Must read state first. */
@@ -124,6 +125,7 @@ static int stop_machine(void)
/* Make them disable irqs. */
local_irq_disable();
+ hard_irq_disable();
stopmachine_set_state(STOPMACHINE_DISABLE_IRQ);
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21] m32r: Fix switch_to macro to push/pop frame pointer if needed
On Thu, 10 May 2007 13:58:36 +0900 Hirokazu Takata <[EMAIL PROTECTED]> wrote: > +#if defined(CONFIG_FRAME_POINTER) > +|| !defined(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER) hm, I didn't know that the preprocessor permitted that. I'll stick a \ in there to be safe. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/7] libata: check for AN support
Andrew Morton wrote: + * @dev: Device to which command will be sent + * + * Issue SET FEATURES - SATA FEATURES command to device @dev + * on port @ap. + * + * LOCKING: + * PCI/etc. bus probe sem. + * + * RETURNS: + * 0 on success, AC_ERR_* mask otherwise. + */ ooh, locking and return value documentation. Often missed, and nice. We set high standards in the libata world ;-) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 06/10] Linux Kernel Markers - Non optimized architectures
On Wed, May 09, 2007 at 09:56:01PM -0400, Mathieu Desnoyers wrote: > This patch also includes marker code for non optimized architectures. > include/asm-alpha/marker.h | 13 + > include/asm-arm/marker.h | 13 + > include/asm-arm26/marker.h | 13 + > include/asm-cris/marker.h | 13 + > include/asm-frv/marker.h | 13 + > include/asm-generic/marker.h | 37 + > include/asm-h8300/marker.h | 13 + > include/asm-ia64/marker.h | 13 + > include/asm-m32r/marker.h | 13 + > include/asm-m68k/marker.h | 13 + > include/asm-m68knommu/marker.h | 13 + > include/asm-mips/marker.h | 13 + > include/asm-parisc/marker.h| 13 + > include/asm-ppc/marker.h | 13 + > include/asm-s390/marker.h | 13 + > include/asm-sh/marker.h| 13 + > include/asm-sh64/marker.h | 13 + > include/asm-sparc/marker.h | 13 + > include/asm-sparc64/marker.h | 13 + > include/asm-um/marker.h| 13 + > include/asm-v850/marker.h | 13 + > include/asm-x86_64/marker.h| 13 + > include/asm-xtensa/marker.h| 13 + > 23 files changed, 323 insertions(+) > --- /dev/null > +++ linux-2.6-lttng/include/asm-arm/marker.h > @@ -0,0 +1,13 @@ > +/* > + * marker.h > + * > + * Code markup for dynamic and static tracing. Architecture specific > + * optimisations. > + * > + * No optimisation implemented. > + * > + * This file is released under the GPLv2. > + * See the file COPYING for more details. > + */ > + > +#include Come on, one line file is enough! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 02/10] Linux Kernel Markers, architecture independent code.
On Wed, May 09, 2007 at 09:55:57PM -0400, Mathieu Desnoyers wrote:
> --- /dev/null
> +++ linux-2.6-lttng/include/linux/marker.h
> @@ -0,0 +1,124 @@
> +#ifdef __KERNEL__
Just don't add this file to include/linux/Kbuild and remove __KERNEL__
ifdef.
> --- linux-2.6-lttng.orig/include/linux/module.h
> +++ linux-2.6-lttng/include/linux/module.h
> @@ -356,6 +356,9 @@
> /* The command line arguments (may be mangled). People like
> keeping pointers to this stuff */
> char *args;
> +
> + const struct __mark_marker *markers;
> + unsigned int num_markers;
#ifdef CONFIG_MARKERS, please.
> --- linux-2.6-lttng.orig/kernel/module.c
> +++ linux-2.6-lttng/kernel/module.c
> @@ -1659,6 +1884,9 @@
> unsigned int unusedcrcindex;
> unsigned int unusedgplindex;
> unsigned int unusedgplcrcindex;
> + unsigned int markersindex;
> + unsigned int markersdataindex;
> + unsigned int markersstringsindex;
Bunch of underscores wouldn't hurt.
> +void list_modules(void)
> +{
> + /* Enumerate loaded modules */
> + struct list_head*i;
> + struct module *mod;
> + unsigned long refcount = 0;
> +
> + mutex_lock(_mutex);
> + list_for_each(i, ) {
> + mod = list_entry(i, struct module, list);
> +#ifdef CONFIG_MODULE_UNLOAD
> + refcount = local_read(>ref[0].count);
^
Buy second CPU, already. ;-)
> +#endif //CONFIG_MODULE_UNLOAD
> + trace_mark(list_module, "%s %d %lu",
> + mod->name, mod->state, refcount);
> + }
> + mutex_unlock(_mutex);
> +}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Kconfig warnings on latest GIT
On Tue, May 08, 2007 at 03:11:52PM -0500, Timur Tabi wrote: > Kim Phillips wrote: > >On Tue, 8 May 2007 00:04:14 +0300 > >Ismail Dönmez <[EMAIL PROTECTED]> wrote: > >>drivers/net/Kconfig:2279:warning: 'select' used by config symbol 'UCC_GETH' > >>refers to undefined symbol 'UCC_FAST' > >looks like this introduces the error: > >commit 7d776cb596994219584257eb5956b87628e5deaf > >Author: Timur Tabi <[EMAIL PROTECTED]> > >Date: Mon Mar 12 15:40:27 2007 -0500 > >[POWERPC] QE: automatically select QE options > > I have a dilemma, so I need help fixing this bug. > > This particular patch is necessary because without it, selecting support for > the QE is too complicated. > > Background: The QUICC Engine (QE) is a microcontroller on some Freescale CPUs > that can mimic a wide variety of devices. It has multiple controllers > (called > UCCs), and each one can be an ethernet device, or a UART, or an HDLC thingy, > etc. There's a QE library and a bunch of other support code in the > arch/powerpc directory, so the QE is a powerpc-specific device. However, all > of the drivers that use it are located in drivers/xxx. > > This isn't a new problem. The common solution is to define some intermediate > Kconfig option, like UCC_FAST_TEMP in the driver's Kconfig. Selecting > UCC_FAST > will then also set UCC_FAST_TEMP. The device driver then depends on > UCC_FAST_TEMP. > > There's also a UCC_SLOW option with the same problem. > > The dillema is that there is no single device driver class that depends on > UCC_FAST. Currently, there's only one that uses UCC_FAST: the ucc_geth > driver. > But I'm also working on a UART driver. > > So my question is: in which Kconfig do I define "UCC_FAST_TEMP" and > "UCC_SLOW_TEMP"? At first I thought, just put it in drivers/Kconfig, but > that > Kconfig does nothing but including other Kconfigs. I believe that if I > submit > a patch that adds "UCC_FAST_TEMP" and "UCC_SLOW_TEMP" to drivers/Kconfig, it > will be rejected. Either that, or I'll spend six weeks trying to persuade > everyone that it's a good idea. > > Does anyone have any suggestions on how I can fix this? That does seem like a reasonable suggestion, and one that would probably work well with the other similar problems that have been introduced sice 2.6.21. drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refer to undefined symbol 'ATARI_KBD_CORE' drivers/input/mouse/Kconfig:102:warning: 'select' used by config symbol 'MOUSE_ATARI' refer to undefined symbol 'ATARI_KBD_CORE' Which seem to be introduced by: commit c04cb856e20a8bf68762d60737b84328c1ab5900 Author: Michael Schmitz <[EMAIL PROTECTED]> Date: Tue May 1 22:32:38 2007 +0200 m68k: Atari keyboard and mouse support. Atari keyboard and mouse support. (reformating and Kconfig fixes by Roman Zippel) Signed-off-by: Michael Schmitz <[EMAIL PROTECTED]> Signed-off-by: Roman Zippel <[EMAIL PROTECTED]> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> drivers/macintosh/Kconfig:112:warning: 'select' used by config symbol 'PMAC_APM_EMU' refer to undefined symbol 'SYS_SUPPORTS_APM_EMULATION' Which seems to have been introduced by: commit b302887854d6f0c6f9fc3f1080535e7c1bd53134 Author: Johannes Berg <[EMAIL PROTECTED]> Date: Tue Mar 20 05:18:02 2007 +1100 [POWERPC] apm_emu: Use generic apm-emulation This patch removes a huge amount of code that is now in common code in drivers/char/apm-emulation.c Signed-off-by: Johannes Berg <[EMAIL PROTECTED]> Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> Signed-off-by: Paul Mackerras <[EMAIL PROTECTED]> -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 1/7] libata: check for AN support
On Wed, 9 May 2007 16:38:09 -0700 Kristen Carlson Accardi <[EMAIL PROTECTED]> wrote: > /** > + * ata_dev_set_AN - Issue SET FEATURES - SATA FEATURES > + * with sector count set to indicate > + * Asynchronous Notification feature I think kenreldoc requires that all this be on a single line? > + * @dev: Device to which command will be sent > + * > + * Issue SET FEATURES - SATA FEATURES command to device @dev > + * on port @ap. > + * > + * LOCKING: > + * PCI/etc. bus probe sem. > + * > + * RETURNS: > + * 0 on success, AC_ERR_* mask otherwise. > + */ ooh, locking and return value documentation. Often missed, and nice. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Use write_trylock_irqsave in ptrace_attach
On Thursday 10 May 2007 07:20, Andrew Morton wrote:
> On Wed, 9 May 2007 14:13:27 +0530 Sripathi Kodi <[EMAIL PROTECTED]>
wrote:
> > Hi,
> >
> > This patch makes ptrace_attach use write_trylock_irqsave.
> >
> > Signed-off-by: Sripathi Kodi <[EMAIL PROTECTED]>
> >
> > ---
> > kernel/ptrace.c |7 +++
> > 1 files changed, 3 insertions(+), 4 deletions(-)
> >
> > Index: linux-2.6.21/kernel/ptrace.c
> > ===
> > --- linux-2.6.21.orig/kernel/ptrace.c
> > +++ linux-2.6.21/kernel/ptrace.c
> > @@ -160,6 +160,7 @@ int ptrace_may_attach(struct task_struct
> > int ptrace_attach(struct task_struct *task)
> > {
> > int retval;
> > + unsigned long flags = 0;
> >
> > retval = -EPERM;
> > if (task->pid <= 1)
> > @@ -178,9 +179,7 @@ repeat:
> > * cpu's that may have task_lock).
> > */
> > task_lock(task);
> > - local_irq_disable();
> > - if (!write_trylock(_lock)) {
> > - local_irq_enable();
> > + if (!write_trylock_irqsave(_lock, flags)) {
> > task_unlock(task);
> > do {
> > cpu_relax();
> > @@ -208,7 +207,7 @@ repeat:
> > force_sig_specific(SIGSTOP, task);
> >
> > bad:
> > - write_unlock_irq(_lock);
> > + write_unlock_irqrestore(_lock, flags);
> > task_unlock(task);
> > out:
> > return retval;
>
> Your changelogs aren't vey logical. The context for this change is off in
>
> a different patch. I reproduce it here:
> > I am trying to fix the BUG I mentioned here:
> > http://lkml.org/lkml/2007/04/20/41. I noticed that an elegant way to
> > solve this problem is to have a write_trylock_irqsave helper function.
> > Since we don't have this now, the code in ptrace_attach implements it
> > using local_irq_disable and write_trylock. I wish to add
> > write_trylock_irqsave to mainline kernel and then fix the -rt specific
> > problem using this.
>
> I can't imagine why -rt's write_unlock_irq() doesn't do local_irq_enable().
-rt's write_unlock_irq() does local_irq_enable() while dealing with 'raw'
rwlock_t. However tasklist_lock is a regular rwlock_t and hence -rt doesn't
save/restore irqs while dealing with it. The probelm in ptrace_attach arises
because we explicitely call local_irq_disable(), whereas write_unlock_irq()
doesn't restore them.
>
> I have no problem adding write_trylock_irqsave() - it fills a gap in the
> API.
>
> Once we have write_trylock_irqsave() it makes sense to use it here.
>
> One the downside, we added a few bytes to the SMP kernel, which I guess we
> can live with.
>
> Whether this change is desired in -rt I don't know. Ingo?
I will send a patch against -rt in a little while.
>
> I don't think the initialisation of `flags' there was needed?
Yes, it was not needed. I will send a patch to remove it.
Thanks,
Sripathi.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.21] m32r: Fix switch_to macro to push/pop frame pointer if needed
Hello,
This patch fixes a rarely-happened but severe scheduling problem of
the recent m32r kernel of 2.6.17-rc3 or later.
In the following previous m32r patch, the switch_to macro was
modified not to do unnecessary push/pop operations for tuning.
> [PATCH] m32r: update switch_to macro for tuning
> 4127272c38619c56f0c1aa01d01c7bd757db70a1
In this modification, only 'lr' and 'sp' registers are push/pop'ed,
assuming that the m32r kernel is always compiled with
-fomit-frame-pointer option.
However, in 2.6 kernel, kernel/sched.c is irregularly compiled
with -fno-omit-frame-pointer if CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER
is not defined.
-- kernel/Makefile --
:
ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
# According to Alan Modra <[EMAIL PROTECTED]>, the -fno-omit-frame-pointer is
# needed for x86 only. Why this used to be enabled for all architectures is
beyond
# me. I suspect most platforms don't need this, but until we know that for
sure
# I turn this off for IA-64 only. Andreas Schwab says it's also needed on m68k
# to get a correct value for the wait-channel (WCHAN in ps). --davidm
CFLAGS_sched.o := $(PROFILING) -fno-omit-frame-pointer
endif
:
---
Therefore, for the recent m32r kernel, we have to push/pop 'fp'
(frame pointer) if CONFIG_FRAME_POINTER is defined or
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not defined.
Signed-off-by: Hitoshi Yamamoto <[EMAIL PROTECTED]>
Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]>
---
arch/m32r/Kconfig |4
include/asm-m32r/system.h | 11 +++
2 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/m32r/Kconfig b/arch/m32r/Kconfig
index 9740d6b..c3bb8a7 100644
--- a/arch/m32r/Kconfig
+++ b/arch/m32r/Kconfig
@@ -241,6 +241,10 @@ config GENERIC_CALIBRATE_DELAY
bool
default y
+config SCHED_NO_NO_OMIT_FRAME_POINTER
+bool
+default y
+
config PREEMPT
bool "Preemptible Kernel"
help
diff --git a/include/asm-m32r/system.h b/include/asm-m32r/system.h
index 99ee098..8b47816 100644
--- a/include/asm-m32r/system.h
+++ b/include/asm-m32r/system.h
@@ -21,12 +21,22 @@
* `next' and `prev' should be struct task_struct, but it isn't always defined
*/
+#if defined(CONFIG_FRAME_POINTER)
+|| !defined(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER)
+#define M32R_PUSH_FP " push fp\n"
+#define M32R_POP_FP " pop fp\n"
+#else
+#define M32R_PUSH_FP ""
+#define M32R_POP_FP ""
+#endif
+
#define switch_to(prev, next, last) do { \
__asm__ __volatile__ ( \
" sethlr, #high(1f) \n" \
" or3 lr, lr, #low(1f)\n" \
" st lr, @%4 ; store old LR \n" \
" ld lr, @%5 ; load new LR \n" \
+ M32R_PUSH_FP \
" st sp, @%2 ; store old SP \n" \
" ld sp, @%3 ; load new SP \n" \
" push%1 ; store `prev' on new stack \n" \
@@ -34,6 +44,7 @@
" .fillinsn \n" \
"1: \n" \
" pop %0 ; restore `__last' from new stack \n" \
+ M32R_POP_FP \
: "=r" (last) \
: "0" (prev), \
"r" (&(prev->thread.sp)), "r" (&(next->thread.sp)), \
--
1.5.1
--
Hirokazu Takata <[EMAIL PROTECTED]>
Linux/M32R Project: http://www.linux-m32r.org/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.21] m32r: Fix tme_handler to check _PAGE_PRESENT bit
Fix the tlb-miss handler (tme_handler) to check _PAGE_PRESENT bit in order to handle file-mapped or swapped-out pages correctly. This patch is required to fix unexpected page errors for m32r. Signed-off-by: Hitoshi Yamamoto <[EMAIL PROTECTED]> Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]> --- arch/m32r/mm/mmu.S | 22 +- 1 files changed, 13 insertions(+), 9 deletions(-) diff --git a/arch/m32r/mm/mmu.S b/arch/m32r/mm/mmu.S index 8bb74b1..49a6d16 100644 --- a/arch/m32r/mm/mmu.S +++ b/arch/m32r/mm/mmu.S @@ -163,7 +163,8 @@ ENTRY(tme_handler) ; pte_data = (unsigned long)pte_val(*pte); ld r2, @r3 ; r2: pte data - or3 r2, r2, #2 ; _PAGE_PRESENT(=2) + and3r3, r2, #2 ; _PAGE_PRESENT(=2) check + beqzr3, 3f .fillinsn 5: @@ -264,11 +265,8 @@ ENTRY(tme_handler) ; and3r1, r1, #0xeff ldi r4, #611; _KERNPG_TABLE(=611) - beq r1, r4, 4f ; !pmd_bad(*pmd) ? - .fillinsn -3: - ldi r1, #0 ; r1: pte_data = 0 - bra 5f + bne r1, r4, 3f ; !pmd_bad(*pmd) ? + .fillinsn 4: ; pte = pte_offset(pmd, address); @@ -282,8 +280,10 @@ ENTRY(tme_handler) add r4, r3 ; r4: pte ; pte_data = (unsigned long)pte_val(*pte); ld r1, @r4 ; r1: pte_data - .fillinsn + and3r3, r1, #2 ; _PAGE_PRESENT(=2) check + beqzr3, 3f + .fillinsn ;; set tlb ; r0: address, r1: pte_data, r2: entry ; r3,r4: (free) @@ -295,8 +295,7 @@ ENTRY(tme_handler) and3r4, r4, #(MMU_CONTEXT_ASID_MASK) or r3, r4 st r3, @r2 - or3 r4, r1, #2 ; _PAGE_PRESENT(=2) - st r4, @(4,r2) ; set_tlb_data(entry, pte_data); + st r1, @(4,r2) ; set_tlb_data(entry, pte_data); ld r4, @sp+ ld r3, @sp+ @@ -306,6 +305,11 @@ ENTRY(tme_handler) ld sp, @sp+ rte + .fillinsn +3: + ldi r1, #2 ; r1: pte_data = 0 | _PAGE_PRESENT(=2) + bra 5b + #else #error unknown isa configuration #endif -- 1.5.1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.21] m32r: Fix pte_to_pgoff(), pgoff_to_pte() and __swp_type() macros
This patch is required to handle file-mapped or swapped-out pages
correctly.
- Fix pte_to_pgoff() and pgoff_to_pte() macros not to include
_PAGE_PROTNONE bit of PTE.
Mask value for { ACCESSED, N, (R, W, X), L, G } is not 0xef but 0x7f.
- Fix __swp_type() macro for MAX_SWAPFILES_SHIFT(=5), which is defined
in include/linux/swap.h.
* M32R TLB format
[0][1:19] [20:23] [24:31]
+---++-+
| VPN ||ASID |
+---++-+
+-+-++-+---+-+-+-+-+
|0 PPN ||N|AC |L|G|V| |
+-+-++-+---+-+-+-+-+
|| RWX | |
* software bits in PTE || | +-- _PAGE_FILE | _PAGE_DIRTY
|| + _PAGE_PRESENT
|+ _PAGE_ACCESSED
+- _PAGE_PROTNONE
Signed-off-by: Hitoshi Yamamoto <[EMAIL PROTECTED]>
Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]>
---
include/asm-m32r/pgtable-2level.h |4 ++--
include/asm-m32r/pgtable.h|2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/asm-m32r/pgtable-2level.h
b/include/asm-m32r/pgtable-2level.h
index 7509257..bca3475 100644
--- a/include/asm-m32r/pgtable-2level.h
+++ b/include/asm-m32r/pgtable-2level.h
@@ -71,8 +71,8 @@ static inline pmd_t *pmd_offset(pgd_t * dir, unsigned long
address)
#define pfn_pmd(pfn, prot) __pmd(((pfn) << PAGE_SHIFT) | pgprot_val(prot))
#define PTE_FILE_MAX_BITS 29
-#define pte_to_pgoff(pte) (((pte_val(pte) >> 2) & 0xef) | (((pte_val(pte)
>> 10)) << 7))
-#define pgoff_to_pte(off) ((pte_t) { (((off) & 0xef) << 2) | (((off) >>
7) << 10) | _PAGE_FILE })
+#define pte_to_pgoff(pte) (((pte_val(pte) >> 2) & 0x7f) | (((pte_val(pte)
>> 10)) << 7))
+#define pgoff_to_pte(off) ((pte_t) { (((off) & 0x7f) << 2) | (((off) >>
7) << 10) | _PAGE_FILE })
#endif /* __KERNEL__ */
#endif /* _ASM_M32R_PGTABLE_2LEVEL_H */
diff --git a/include/asm-m32r/pgtable.h b/include/asm-m32r/pgtable.h
index 1c15ba7..4e94876 100644
--- a/include/asm-m32r/pgtable.h
+++ b/include/asm-m32r/pgtable.h
@@ -366,7 +366,7 @@ static inline void pmd_set(pmd_t * pmdp, pte_t * ptep)
#define pte_unmap_nested(pte) do { } while (0)
/* Encode and de-code a swap entry */
-#define __swp_type(x) (((x).val >> 2) & 0x3f)
+#define __swp_type(x) (((x).val >> 2) & 0x1f)
#define __swp_offset(x)((x).val >> 10)
#define __swp_entry(type, offset) \
((swp_entry_t) { ((type) << 2) | ((offset) << 10) })
--
1.5.1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: remove broken URLs from net drivers' output
On Thu, May 10, 2007 at 12:23:53AM -0400, Jeff Garzik wrote: > Adrian Bunk wrote: >> It had been sent twice to both linux-kernel and netdev, and when going >> through old linux-kernel emails I considered it trivial enough (people >> might argue about dead email addresses, but not about dead URLs). >> I could send such patches to Andrew for that he includes them in -mm and >> therefore will include them in his huge list of "forward again and again >> to the maintainer until there is any reaction" patches. >> But IMHO for such trivial patches it's enough if the maintainer had the >> chance to veto them. > > > Please follow the rule that everybody else follows: send to me and netdev. > It's that simple :) This doesn't answer the main question: How often, if there's no maintainer reaction? It happens that Andrew forwards patches from me in -mm 5 or 10 times to a maintainer until he gets any reaction from the maintainer. Before I'd start the same with trivial patches, it would be easier to change the "[EMAIL PROTECTED]" mail alias to point to Andrew so that trivial patches can also become part of his "forward patches to maintainers again and again until there's any reaction" process. That's not meant as a threat or anything like that, it's a serious suggestion to avoid duplicated work. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ckrm-tech] [PATCH 1/9] Containers (V9): Basic container framework
Paul Jackson wrote: > Balbir wrote: >> Thanks for the script. Would you like to contribute this script to >> LTP for wider availability and testing? > > Sounds good - though I'm a tad lazy, and don't know how to contribute > this to the LTP. > > You're welcome to contribute it yourself, if that's easier for you, > or to point me in the direction of some information on this. > > Since it's GPL, you can republish it, under that license. > > ... Most likely however, it will take a little tweaking to make this > test work well for LTP. Most automated test environments have some > requirements on the behaviour of each test, and it would be surprising > if this test happen already to conform to LTP's requirements. > I'll figure out more, once I am comfortable with the script and the setup environment, I'll try and get this into LTP with a GPL license. -- Thanks, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: remove broken URLs from net drivers' output
On Thu, May 10, 2007 at 12:22:59AM -0400, Jeff Garzik wrote: > Adrian Bunk wrote: >> I thought it was just an informal tag to mark which people did agree with >> the patch (and the line between your "Makes good sense to me." and a "Feel >> free to add my ACK to this" is really thin). > > No, the line is easy and obvious: if there is any doubt, DO NOT ASSUME. > > If they do not explicitly ACK it, then do not presume to speak for them. There is no doubt that Jesper did explicitly ACK the patch. We are ONLY discussing whether his informal ACK can be translated into an "Acked-by:" line. The line I mentioned only exists if "Acked-by:" is considered a formal tag someone must explicitely give, and not an informal indication that someone agrees with the patch. But in this case, we should better require people to give explicit "Acked-by:" lines, like we already require for "Signed-off-by:" lines. I've seen many cases where people other than me added "Acked-by:" tags when there was only a "Makes good sense to me." or "Fine with me.", but no formal "Acked-by:" given. If "Acked-by:" should be considered a formal tag, it - should be documented in Documentation/SubmittingPatches and - the practice must change to always require people to give a formal "Acked-by:". > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ckrm-tech] [PATCH 1/9] Containers (V9): Basic container framework
Balbir wrote: > Thanks for the script. Would you like to contribute this script to > LTP for wider availability and testing? Sounds good - though I'm a tad lazy, and don't know how to contribute this to the LTP. You're welcome to contribute it yourself, if that's easier for you, or to point me in the direction of some information on this. Since it's GPL, you can republish it, under that license. ... Most likely however, it will take a little tweaking to make this test work well for LTP. Most automated test environments have some requirements on the behaviour of each test, and it would be surprising if this test happen already to conform to LTP's requirements. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG][debian-2.6.20-1-686] bridging + vlans + "vconfig rem" == stuck kernel
On May 10, 2007, at 00:25:54, Ben Greear wrote: Kyle Moffett wrote: vconfig D 83CCD8CE 0 16564 16562 (NOTLB) efdd7e7c 0086 ee120afb 83ccd8ce 98f00788 b7083ffa 5384b49a c76c0b05 9ebaf791 0004 efdd7e4e 0007 f1468a90 2ab74174 0362 0326 f1468b9c c180e420 0001 0286 c012933c efdd7e8c df98a000 c180e468 Call Trace: [] lock_timer_base+0x15/0x2f [] __mod_timer+0x91/0x9b [] schedule_timeout+0x70/0x8d [] vlan_device_event+0x13/0xf8 [8021q] Looks like a deadlock in the vlan code. Any chance you can run this test with lockdep enabled? You could also add a printk in vlan_device_event() to check which event it is hanging on, and the netdevice that is passed in. Ok, I'll try building a 2.6.21 kernel with lockdep and some debugging printk()s in the vlan_device_event() function and get back to you tomorrow. Thanks for the quick response! Since the vlan code holds RTNL at this point, then most other network tasks will eventually hang as well. Well, it's less of an "eventually" and more of an "almost immediately". When that happens pretty close to everything more complicated than socket(), bind(), and connect() with straightforward UNIX or INET sockets tends to stick completely. Thanks again! Cheers, Kyle Moffett - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH (trivial)] Fix wrong identifier name in Documentation/kref.txt
Hi Adrian, Nobody seems to have picked this up -- I didn't see it in the other trivial stuff you pushed to Linus earlier today (my mistake, I hadn't copied you in the original post), and it's not in the latest git either. If somebody can please pick this up for upstream ... Thanks, Satyam On Fri, 4 May 2007, Corey Minyard wrote: Yes, please add this. Thanks. -corey Satyam Sharma wrote: Here's another trivial one I've been meaning to send since ... a long time back. Cheers, Satyam --- There's a typo / wrong identifier name in Documentation/kref.txt. Fix it. Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> --- diff -ruNp linux-2.6.21.1/Documentation/kref.txt linux-2.6.21.1~patch/Documentation/kref.txt --- linux-2.6.21.1/Documentation/kref.txt2007-05-04 19:40:01.0 +0530 +++ linux-2.6.21.1~patch/Documentation/kref.txt2007-05-04 19:41:04.0 +0530 @@ -67,7 +67,7 @@ void more_data_handling(void *cb_data) . . do stuff with data here . -kref_put(data, data_release); +kref_put(>refcount, data_release); } int my_data_handler(void) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announcing free software drivers for the new Intel® 965GM Express Chipset
Great news. Here's hoping that Intel produces a standalone video card eventually, to further take away market share from closed source competitors. Jeff, not biased at all... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG][debian-2.6.20-1-686] bridging + vlans + "vconfig rem" == stuck kernel
Kyle Moffett wrote: vconfig D 83CCD8CE 0 16564 16562 (NOTLB) efdd7e7c 0086 ee120afb 83ccd8ce 98f00788 b7083ffa 5384b49a c76c0b05 9ebaf791 0004 efdd7e4e 0007 f1468a90 2ab74174 0362 0326 f1468b9c c180e420 0001 0286 c012933c efdd7e8c df98a000 c180e468 Call Trace: [] lock_timer_base+0x15/0x2f [] __mod_timer+0x91/0x9b [] schedule_timeout+0x70/0x8d [] vlan_device_event+0x13/0xf8 [8021q] Looks like a deadlock in the vlan code. Any chance you can run this test with lockdep enabled? You could also add a printk in vlan_device_event() to check which event it is hanging on, and the netdevice that is passed in. Since the vlan code holds RTNL at this point, then most other network tasks will eventually hang as well. Thanks, Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: remove broken URLs from net drivers' output
Adrian Bunk wrote: It had been sent twice to both linux-kernel and netdev, and when going through old linux-kernel emails I considered it trivial enough (people might argue about dead email addresses, but not about dead URLs). I could send such patches to Andrew for that he includes them in -mm and therefore will include them in his huge list of "forward again and again to the maintainer until there is any reaction" patches. But IMHO for such trivial patches it's enough if the maintainer had the chance to veto them. Please follow the rule that everybody else follows: send to me and netdev. It's that simple :) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: remove broken URLs from net drivers' output
Adrian Bunk wrote: I thought it was just an informal tag to mark which people did agree with the patch (and the line between your "Makes good sense to me." and a "Feel free to add my ACK to this" is really thin). No, the line is easy and obvious: if there is any doubt, DO NOT ASSUME. If they do not explicitly ACK it, then do not presume to speak for them. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Definition of fairness (was Re: [patch] CFS scheduler, -v11)
> Ex: consider two equally important tasks T1 and T2 running on > same CPU and > whose execution nature is: > > T1 = 100% cpu hog > T2 = 60% cpu hog (run for 600ms, sleep for 400ms) > > Over a arbitrary observation period of 10 sec, > > T1 was ready to run for all 10sec > T2 was ready to run for 6 sec > > Over this observation period, how much execution time should T2 get, > under a "fair" scheduler? Anywhere between 30% and 50% of the CPU is fair. There is nothing particularly fair or unfair about how much credit you give an interactive task. Less than 30% is unfair as the task is being punished for voluntarily yielding. More than 50% is unfair as the task should not be entitled to more than half the CPU if another task with equal static priority wants as much CPU as possible. Slightly less than 30% or slightly more than 50% can also be reasonable due to rounding or the scheduling interval beating against T2's internal timing. From a practical standpoint, we'd like such a task to get a bit more than 30%. How much more may reasonably depend on exactly what the sleep/run interval is for the task. It would be unreasonable to expect a task to be credited for sleeping for an entire day, but unreasonable to expect a task to not get any credit for voluntarily yielding the CPU when it is later ready-to-run. Typical UNIX schedulers bump a task's dynamic priority when it voluntarily yields. As a result, it can pre-empty a CPU-burner when it later becomes ready-to-run. This is intended more to reduce latency than to increase CPU share. However, it should also have the effect of giving a polite task more CPU than pure CPU-burned when it needs it. (That's only fair.) DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ckrm-tech] [PATCH 1/9] Containers (V9): Basic container framework
Paul Jackson wrote: > Balbir wrote: > > 1) Testing batch schedulers against cpusets: > > I doubt that the batch scheduler developers would be able to > extract a cpuset test from their tests, or be able to share it if > they did. Their tests tend to be large tests of batch schedulers, > and only incidentally test cpusets -- if we break cpusets, > in sometimes even subtle ways that they happen to depend on, > we break them. > > Sometimes there is no way to guess exactly what sorts of changes > will break their code; we'll just have to schedule at least one > run through one or more of them that rely heavily on cpusets > before a change as big as rebasing cpusets on containers is > reasonably safe. This test cycle won't be all that easy, so I'd > wait until we are pretty close to what we think should be taken > into the mainline kernel. > > I suppose I will have to be the one co-ordinating this test, > as I am the only one I know with a presence in both camps. > > Once this test is done, from then forward, if we break them, > we'll just have to deal with it as we do now, when the breakage > shows up well down stream from the main kernel tree, at the point > that a major batch scheduler release runs into a major distribution > release containing the breakage. There is no practical way that I > can see, as an ongoing basis, to continue testing for such breakage > with every minor change to cpuset related code in the kernel. Any > breakage found this way is dealt with by changes in user level code. > > Once again, I have bcc'd one or more developers of batch schedulers, > so they can see what nonsense I am spouting about them now ;). > That sounds reasonable to me > 2) Testing cpusets with a specific test. > > There I can do better. Attached is the cpuset regression test I > use. It requires at least 4 cpus and 2 memory nodes to do anything > useful. It is copyright by SGI, released under GPL license. > > This regression test is the primary cpuset test upon which I > relied during the development of cpusets, and continue to rely. > Except for one subtle race condition in the test itself, it has > not changed in the last two to three years. > > This test requires no user level code not found in an ordinary > distro. It does require the taskset and numactl commands, > for the purposes of testing certain interactions with them. > It assumes that there are not other cpusets currently setup in > the system that happen to conflict with the ones it creates. > > See further comments within the test script itself. > Thanks for the script. Would you like to contribute this script to LTP for wider availability and testing? -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] UML - Monitor stack usage
On Wed, 9 May 2007 16:27:22 -0400 Jeff Dike <[EMAIL PROTECTED]> wrote: > In preparation for reducing stack size, add a machanism to see how > much of a kernel stack is used. This fills a new stack with 0x6b on > allocation and sees where the lowest non-0x6b byte is on process > exit. It keeps track of the lowest value and logs values as they get > lower. but, but. We already have CONFIG_DEBUG_STACK_USAGE? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: remove broken URLs from net drivers' output
On Thu, May 10, 2007 at 01:04:24AM +0200, Jesper Juhl wrote: > On 10/05/07, Jeff Garzik <[EMAIL PROTECTED]> wrote: >> Linux Kernel Mailing List wrote: >> > Gitweb: >> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2c2a8c531e953c753b06605c8ad6a9161ca527fa >> > Commit: 2c2a8c531e953c753b06605c8ad6a9161ca527fa >> > Parent: b96687768a9ac0fdd005c7700093ebb24b93450f >> > Author: Markus Dahms <[EMAIL PROTECTED]> >> > AuthorDate: Wed May 9 07:58:10 2007 +0200 >> > Committer: Adrian Bunk <[EMAIL PROTECTED]> >> > CommitDate: Wed May 9 08:58:18 2007 +0200 >> > >> > remove broken URLs from net drivers' output >> > >> > Remove broken URLs (www.scyld.com) from network drivers' logging >> output. >> > URLs in comments and other strings are left intact. >> > >> > Signed-off-by: Markus Dahms <[EMAIL PROTECTED]> >> > Acked-by: Jesper Juhl <[EMAIL PROTECTED]> >> > Acked-by: Alan Cox <[EMAIL PROTECTED]> >> > igned-off-by: Adrian Bunk <[EMAIL PROTECTED]> >> > --- >> > drivers/net/3c509.c |5 ++--- >> > drivers/net/3c59x.c |2 +- >> > drivers/net/atp.c |8 +++- >> > drivers/net/eepro100.c |2 +- >> > drivers/net/epic100.c | 10 -- >> > drivers/net/natsemi.c |1 - >> > drivers/net/ne2k-pci.c |3 +-- >> > drivers/net/sundance.c |3 +-- >> > drivers/net/yellowfin.c |1 - >> > 9 files changed, 13 insertions(+), 22 deletions(-) >> >> Grumble... This stuff should go through my tree. >> >> Jeff >> > > Note, just for the record; I never explicitly added an Acked-by to > this patch, I only said in a conversational email that it made sense > to me... > I don't actually mind, in this case, to have an Acked-by tagged on > with my name, but in general I think that such lines should only be > added when people explicitly say Acked-by: John Doe, or something like > "Feel free to add my ACK to this" etc. Did I miss that "Acked-by:" is considered to be a formal tag like "Signed-off-by:"? I thought it was just an informal tag to mark which people did agree with the patch (and the line between your "Makes good sense to me." and a "Feel free to add my ACK to this" is really thin). > Jesper Juhl cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] removes MAX_ARG_PAGES
On 5/9/07, Rob Landley <[EMAIL PROTECTED]> wrote: Just FYI, a really really quick and dirty way of testing this sort of thing on more architectures and you're likely to physically have? Does this properly emulate caching? On parisc, cache coherency was the main issue we ran into. I suspect this might be the case with other architectures as well. Ollie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swap-prefetch: 2.6.22 -mm merge plans
On Thursday 10 May 2007 13:48, Ray Lee wrote: > On 5/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote: > > You said it helped with the updatedb problem. That says we should look at > > why it is going bad first, and for example improve use-once algorithms. > > After we do that, then swap prefetching might still help, which is fine. > > Nick, if you're volunteering to do that analysis, then great. If not, > then you're just providing a airy hope with nothing to back up when or > if that work would ever occur. > > Further, if you or someone else *does* do that work, then guess what, > we still have the option to rip out the swap prefetching code after > the hypothetical use-once improvements have been proven and merged. > Which, by the way, I've watched people talk about since 2.4. That was, > y'know, a *while* ago. > > So enough with the stop energy, okay? You're better than that. > > Con? He is right about the last feature to go in needs to work > gracefully with what's there now. However, it's not unheard of for > authors of other sections of code to help out with incompatibilities > by answering politely phrased questions for guidance. Though the > intersection of users between cpusets and desktop systems seems small > indeed. Let's just set the record straight. I actually discussed cpusets over a year ago in this nonsense and was told by sgi folk there was no need to get my head around cpusets and honouring node placement should be enough which, by the way, swap prefetch does. So I by no means ignored this; we just hit an impasse on just how much more featured it should be for the sake of a goddamn home desktop pc feature. Anyway why the hell am I resurrecting this thread? The code is declared dead already. Leave it be. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: remove broken URLs from net drivers' output
On Wed, May 09, 2007 at 06:41:22PM -0400, Jeff Garzik wrote: > Linux Kernel Mailing List wrote: >> Gitweb: >> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2c2a8c531e953c753b06605c8ad6a9161ca527fa >> Commit: 2c2a8c531e953c753b06605c8ad6a9161ca527fa >> Parent: b96687768a9ac0fdd005c7700093ebb24b93450f >> Author: Markus Dahms <[EMAIL PROTECTED]> >> AuthorDate: Wed May 9 07:58:10 2007 +0200 >> Committer: Adrian Bunk <[EMAIL PROTECTED]> >> CommitDate: Wed May 9 08:58:18 2007 +0200 >> remove broken URLs from net drivers' output >> Remove broken URLs (www.scyld.com) from network drivers' logging >> output. >> URLs in comments and other strings are left intact. >> Signed-off-by: Markus Dahms <[EMAIL PROTECTED]> >> Acked-by: Jesper Juhl <[EMAIL PROTECTED]> >> Acked-by: Alan Cox <[EMAIL PROTECTED]> >> igned-off-by: Adrian Bunk <[EMAIL PROTECTED]> >> --- >> drivers/net/3c509.c |5 ++--- >> drivers/net/3c59x.c |2 +- >> drivers/net/atp.c |8 +++- >> drivers/net/eepro100.c |2 +- >> drivers/net/epic100.c | 10 -- >> drivers/net/natsemi.c |1 - >> drivers/net/ne2k-pci.c |3 +-- >> drivers/net/sundance.c |3 +-- >> drivers/net/yellowfin.c |1 - >> 9 files changed, 13 insertions(+), 22 deletions(-) > > Grumble... This stuff should go through my tree. It had been sent twice to both linux-kernel and netdev, and when going through old linux-kernel emails I considered it trivial enough (people might argue about dead email addresses, but not about dead URLs). I could send such patches to Andrew for that he includes them in -mm and therefore will include them in his huge list of "forward again and again to the maintainer until there is any reaction" patches. But IMHO for such trivial patches it's enough if the maintainer had the chance to veto them. > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swap-prefetch: 2.6.22 -mm merge plans
Ray Lee wrote: On 5/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote: You said it helped with the updatedb problem. That says we should look at why it is going bad first, and for example improve use-once algorithms. After we do that, then swap prefetching might still help, which is fine. Nick, if you're volunteering to do that analysis, then great. If not, then you're just providing a airy hope with nothing to back up when or if that work would ever occur. I'd like to try helping. Tell me your problem. Further, if you or someone else *does* do that work, then guess what, we still have the option to rip out the swap prefetching code after the hypothetical use-once improvements have been proven and merged. Which, by the way, I've watched people talk about since 2.4. That was, y'know, a *while* ago. What's wrong with the use-once we have? What improvements are you talking about? So enough with the stop energy, okay? You're better than that. I don't think it is about energy or being mean, I'm just stating the issues I have with it. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] net: trivial MLX4_DEBUG dependency fix.
First SLUB_DEBUG, and now this.. CONFIG_MLX4_DEBUG works out to a def_bool y for those that have CONFIG_EMBEDDED set. Make it depend on MLX4_CORE.. I'll let someone else wonder why debugging output is default enabled, this seems to be a worrying trend as of late. Signed-off-by: Paul Mundt <[EMAIL PROTECTED]> -- diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index fa489b1..b3f4ffa 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -2500,6 +2500,7 @@ config MLX4_CORE config MLX4_DEBUG bool "Verbose debugging output" if (MLX4_CORE && EMBEDDED) + depends on MLX4_CORE default y ---help--- This option causes debugging code to be compiled into the - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swap-prefetch: 2.6.22 -mm merge plans
On 5/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote: You said it helped with the updatedb problem. That says we should look at why it is going bad first, and for example improve use-once algorithms. After we do that, then swap prefetching might still help, which is fine. Nick, if you're volunteering to do that analysis, then great. If not, then you're just providing a airy hope with nothing to back up when or if that work would ever occur. Further, if you or someone else *does* do that work, then guess what, we still have the option to rip out the swap prefetching code after the hypothetical use-once improvements have been proven and merged. Which, by the way, I've watched people talk about since 2.4. That was, y'know, a *while* ago. So enough with the stop energy, okay? You're better than that. Con? He is right about the last feature to go in needs to work gracefully with what's there now. However, it's not unheard of for authors of other sections of code to help out with incompatibilities by answering politely phrased questions for guidance. Though the intersection of users between cpusets and desktop systems seems small indeed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc] optimise unlock_page
On Wed, May 09, 2007 at 08:33:15PM +0100, Hugh Dickins wrote:
>
> Not good enough, I'm afraid. It looks like Ben's right and you need
> a count - and counts in the page struct are a lot harder to add than
> page flags.
>
> I've now played around with the hangs on my three 4CPU machines
> (all of them in io_schedule below __lock_page, waiting on pages
> which were neither PG_locked nor PG_waiters when I looked).
>
> Seeing Ben's mail, I thought the answer would be just to remove
> the "_exclusive" from your three prepare_to_wait_exclusive()s.
> That helped, but it didn't eliminate the hangs.
>
> After fiddling around with different ideas for some while, I came
> to realize that the ClearPageWaiters (in very misleadingly named
> __unlock_page) is hopeless. It's just so easy for it to clear the
> PG_waiters that a third task relies upon for wakeup (and which
> cannot loop around to set it again, because it simply won't be
> woken by unlock_page/__unlock_page without it already being set).
OK, I found a simple bug after pulling out my hair for a while :)
With this, a 4-way system survives a couple of concurrent make -j250s
quite nicely (wheras they eventually locked up before).
The problem is that the bit wakeup function did not go through with
the wakeup if it found the bit (ie. PG_locked) set. This meant that
waiters would not get a chance to reset PG_waiters.
However you probably weren't referring to that particular problem
when you imagined the need for a full count, or the slippery 3rd
task... I wasn't able to derive any such problems with the basic
logic, so if there was a bug there, it would still be unfixed in this
patch.
---
Speed up unlock_page by introducing a new page flag to signal that there are
page waitqueue waiters for PG_locked. This means a memory barrier and a random
waitqueue hash cacheline load can be avoided in the fastpath when there is no
contention.
Index: linux-2.6/include/linux/page-flags.h
===
--- linux-2.6.orig/include/linux/page-flags.h 2007-05-10 10:22:05.0
+1000
+++ linux-2.6/include/linux/page-flags.h2007-05-10 10:22:06.0
+1000
@@ -91,6 +91,8 @@
#define PG_nosave_free 18 /* Used for system suspend/resume */
#define PG_buddy 19 /* Page is free, on buddy lists */
+#define PG_waiters 20 /* Page has PG_locked waiters */
+
/* PG_owner_priv_1 users should have descriptive aliases */
#define PG_checked PG_owner_priv_1 /* Used by some filesystems */
@@ -113,6 +115,10 @@
#define SetPageLocked(page)\
set_bit(PG_locked, &(page)->flags)
+#define PageWaiters(page) test_bit(PG_waiters, &(page)->flags)
+#define SetPageWaiters(page) set_bit(PG_waiters, &(page)->flags)
+#define ClearPageWaiters(page) clear_bit(PG_waiters, &(page)->flags)
+
#define PageError(page)test_bit(PG_error, &(page)->flags)
#define SetPageError(page) set_bit(PG_error, &(page)->flags)
#define ClearPageError(page) clear_bit(PG_error, &(page)->flags)
Index: linux-2.6/include/linux/pagemap.h
===
--- linux-2.6.orig/include/linux/pagemap.h 2007-05-10 10:22:05.0
+1000
+++ linux-2.6/include/linux/pagemap.h 2007-05-10 10:22:06.0 +1000
@@ -133,7 +133,8 @@
extern void FASTCALL(__lock_page(struct page *page));
extern void FASTCALL(__lock_page_nosync(struct page *page));
-extern void FASTCALL(unlock_page(struct page *page));
+extern void FASTCALL(__wait_on_page_locked(struct page *page));
+extern void FASTCALL(__unlock_page(struct page *page));
static inline int trylock_page(struct page *page)
{
@@ -160,7 +161,15 @@
if (!trylock_page(page))
__lock_page_nosync(page);
}
-
+
+static inline void unlock_page(struct page *page)
+{
+ VM_BUG_ON(!PageLocked(page));
+ clear_bit_unlock(PG_locked, >flags);
+ if (unlikely(PageWaiters(page)))
+ __unlock_page(page);
+}
+
/*
* This is exported only for wait_on_page_locked/wait_on_page_writeback.
* Never use this directly!
@@ -176,8 +185,9 @@
*/
static inline void wait_on_page_locked(struct page *page)
{
+ might_sleep();
if (PageLocked(page))
- wait_on_page_bit(page, PG_locked);
+ __wait_on_page_locked(page);
}
/*
@@ -185,6 +195,7 @@
*/
static inline void wait_on_page_writeback(struct page *page)
{
+ might_sleep();
if (PageWriteback(page))
wait_on_page_bit(page, PG_writeback);
}
Index: linux-2.6/mm/filemap.c
===
--- linux-2.6.orig/mm/filemap.c 2007-05-10 10:22:05.0 +1000
+++ linux-2.6/mm/filemap.c 2007-05-10 11:03:10.0 +1000
@@ -165,10 +165,12 @@
mapping = page_mapping(page);
if (mapping && mapping->a_ops &&
Re: [PATCH 1/2] Introduce write_trylock_irqsave
On 5/9/07, Sripathi Kodi <[EMAIL PROTECTED]> wrote:
Hi,
I am trying to fix the BUG I mentioned here:
http://lkml.org/lkml/2007/04/20/41. I noticed that an elegant way to solve
this problem is to have a write_trylock_irqsave helper function. Since we
don't have this now, the code in ptrace_attach implements it using
local_irq_disable and write_trylock. I wish to add write_trylock_irqsave to
mainline kernel and then fix the -rt specific problem using this.
The patch below adds write_trylock_irqsave function.
Why not implement this as follows? That way we're able to (1) be
consistent in style with spin_trylock_irqsave, (2) type fewer lines,
(3) touch fewer files, and (4) not add extra bulk to kernel text size
either.
For the sake of completeness of the API, we could also add a
read_trylock_irqsave, but I'd be against the _irq variants (or should
we call them hazards) that don't save / restore.
Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]>
---
include/linux/spinlock.h |7 +++
1 file changed, 7 insertions(+)
---
diff -ruNp a/include/linux/spinlock.h b/include/linux/spinlock.h
--- a/include/linux/spinlock.h 2007-04-26 08:38:32.0 +0530
+++ b/include/linux/spinlock.h 2007-05-10 08:43:32.0 +0530
@@ -282,6 +282,13 @@ do { \
1 : ({ local_irq_restore(flags); 0; }); \
})
+#define write_trylock_irqsave(lock, flags) \
+({ \
+ local_irq_save(flags); \
+ write_trylock(lock) ? \
+ 1 : ({ local_irq_restore(flags); 0; }); \
+})
+
/*
* Locks two spinlocks l1 and l2.
* l1_first indicates if spinlock l1 should be taken first.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] v4l: saa7134: enable ir-remote for 10moons TM300 card
Enable the IR-remote of the 10moons TM300 card and add the key-codes for
it's remote. But to enable all the keys, "IR_KEYTAB_SIZE", the size of
code tables should be at least 256.
It has been tested using lirc. All the key codes are accepted.
This patch depends on the "[PATCH 1/3] v4l: Support 10moons TM300
(saa7130) Card"
Signed-off-by: Tony Wan <[EMAIL PROTECTED]>
---
drivers/media/common/ir-keymaps.c | 71
+++
drivers/media/video/saa7134/saa7134-cards.c |1 +
drivers/media/video/saa7134/saa7134-input.c |6 ++
include/media/ir-common.h |1 +
4 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/drivers/media/common/ir-keymaps.c
b/drivers/media/common/ir-keymaps.c
index cbd1184..df11ed4 100644
--- a/drivers/media/common/ir-keymaps.c
+++ b/drivers/media/common/ir-keymaps.c
@@ -1783,3 +1783,74 @@ IR_KEYTAB_TYPE ir_codes_tt_1500[IR_KEYTAB_SIZE] =
{
};
EXPORT_SYMBOL_GPL(ir_codes_tt_1500);
+
+/* 10MOONS TM300 */
+IR_KEYTAB_TYPE ir_codes_10moonstm3[IR_KEYTAB_SIZE] = {
+ [ 0x10 ] = KEY_POWER, // Power
+ [ 0x0d ] = KEY_MUTE,// Mute
+ [ 0x1e ] = KEY_TUNER, // Cable
+ [ 0x00 ] = KEY_VIDEO, // Composite / S-Video
+ [ 0x01 ] = KEY_RADIO, // Music
+ [ 0x02 ] = KEY_TEXT,// Photo
+
+ [ 0x1f ] = KEY_1,
+ [ 0x03 ] = KEY_2,
+ [ 0x04 ] = KEY_3,
+ [ 0x05 ] = KEY_4,
+ [ 0x1c ] = KEY_5,
+ [ 0x06 ] = KEY_6,
+ [ 0x07 ] = KEY_7,
+ [ 0x08 ] = KEY_8,
+ [ 0x1d ] = KEY_9,
+ [ 0x09 ] = KEY_SELECT, // 2 digit select (-/--)
+ [ 0x0a ] = KEY_0,
+ [ 0x0b ] = KEY_AGAIN, // Recall
+
+ [ 0x14 ] = KEY_F1, // Begin
+ [ 0x15 ] = KEY_F2, // End
+
+ [ 0x16 ] = KEY_CHANNELUP, // CH+
+ [ 0x12 ] = KEY_CHANNELDOWN, // CH-
+ [ 0x0c ] = KEY_VOLUMEUP,// VOL+
+ [ 0x17 ] = KEY_VOLUMEDOWN, // VOL-
+ [ 0x18 ] = KEY_OK, // OK
+
+ [ 0x0e ] = KEY_EXIT,// Exit
+ [ 0x13 ] = KEY_COMPUTER,// Desktop
+ [ 0x11 ] = KEY_TAB, // TAB
+ [ 0x19 ] = KEY_CYCLEWINDOWS,// Switch task
+
+ [ 0x1a ] = KEY_MENU,// Menu
+ [ 0x1b ] = KEY_ZOOM,// Fullscreen
+#if IR_KEYTAB_SIZE>=256
+ [ 0x84 ] = KEY_ARCHIVE, // Time shifting
+ [ 0x80 ] = KEY_SWITCHVIDEOMODE, // Selcect source
+
+ [ 0x9a ] = KEY_RECORD, // Record
+ [ 0x82 ] = KEY_PLAY,// Play/Pause
+ [ 0x85 ] = KEY_STOP,// Stop
+ [ 0x83 ] = KEY_CAMERA, // Snapshot
+
+ [ 0x88 ] = KEY_BACK,// Backward <<
+ [ 0x8a ] = KEY_FORWARD, // Forward >>
+ [ 0x89 ] = KEY_PREVIOUS,// Back |<<
+ [ 0x8b ] = KEY_NEXT,// End >>|
+
+ [ 0x8c ] = KEY_PROGRAM, // Multi-view
+ [ 0x8d ] = KEY_AUDIO, // Audio Tracks
+ [ 0x8e ] = KEY_SOUND, // Sound
+ [ 0x8f ] = KEY_SUBTITLE,// Subtitles
+
+ [ 0x90 ] = KEY_TIME,// Set timer
+ [ 0x91 ] = KEY_CHANNEL, // Stereo
+ [ 0x92 ] = KEY_LANGUAGE,// Language
+ [ 0x93 ] = KEY_TEXT,// Text
+
+ [ 0x99 ] = KEY_RED, // RED
+ [ 0x81 ] = KEY_GREEN, // GREEN
+ [ 0x87 ] = KEY_YELLOW, // YELLOW
+ [ 0x97 ] = KEY_BLUE,// BLUE
+#endif /* IR_KEYTAB_SIZE>=256 */
+};
+
+EXPORT_SYMBOL_GPL(ir_codes_10moonstm3);
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index 44f2077..5813509 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -4368,6 +4368,7 @@ int saa7134_board_init1(struct saa7134_dev *dev)
case SAA7134_BOARD_AVERMEDIA_A16AR:
case SAA7134_BOARD_ENCORE_ENLTV:
case SAA7134_BOARD_ENCORE_ENLTV_FM:
+ case SAA7134_BOARD_10MOONSTVMASTER3:
dev->has_remote = SAA7134_REMOTE_GPIO;
break;
case SAA7134_BOARD_FLYDVBS_LR300:
diff --git a/drivers/media/video/saa7134/saa7134-input.c
b/drivers/media/video/saa7134/saa7134-input.c
index c0de37e..5511aff 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -333,6 +333,12 @@ int saa7134_input_init1(struct saa7134_dev *dev)
mask_keyup = 0x04;
polling = 50; // ms
break;
+ case SAA7134_BOARD_10MOONSTVMASTER3:
+ ir_codes = ir_codes_10moonstm3;
+ mask_keycode = 0x7f8;
+ mask_keyup = 0x800;
+ polling = 50; //ms
+ break;
}
if (NULL == ir_codes) {
printk("%s: Oops: IR config error
[PATCH 3/3] v4l: enlarge the size of ir-key table to 256
Some IR-remote will produce key codes larger than 128. Enlarge the size IR_KEYTAB_SIZE to 256 to enable all the keys. Signed-off-by: Tony Wan <[EMAIL PROTECTED]> --- include/media/ir-common.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/media/ir-common.h b/include/media/ir-common.h index 4e4d207..5355ebc 100644 --- a/include/media/ir-common.h +++ b/include/media/ir-common.h @@ -31,7 +31,7 @@ #define IR_TYPE_OTHER 99 #define IR_KEYTAB_TYPE u32 -#define IR_KEYTAB_SIZE 128 // enougth for rc5, probably need more some day ... +#define IR_KEYTAB_SIZE 256 // some remote needs 8-bit keycodes #define IR_KEYCODE(tab,code) (((unsigned)code < IR_KEYTAB_SIZE) \ ? tab[code] : KEY_RESERVED) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 8462] New: applications under wine freezes
On Wed, 9 May 2007 19:37:05 -0700 [EMAIL PROTECTED] wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8462 Let's do this via emailed reply-to-all, please. bugzilla is more appropriate for tracking of longer-term bugs. >Summary: applications under wine freezes > Kernel Version: 2.6.21-git > Status: NEW > Severity: normal > Owner: [EMAIL PROTECTED] > Submitter: [EMAIL PROTECTED] > > > Most recent commit where this bug did *NOT* occur: > commit a989705c4cf6e6c1a339c95f9daf658b4ba88ca8 > Merge: 2d56d3c... d291825... > Author: Linus Torvalds <[EMAIL PROTECTED]> > Date: Mon May 7 12:34:57 2007 -0700 > > Distribution: slackware 11.0 > > Problem Description: > applications, namely starcraft and pokerstars, running under wine freezes > shortly after starting the app. > > bisect produced the following commit: > commit 6192bd536f96c6a0d969081bc71ae24f9319bfdc > Author: Davide Libenzi <[EMAIL PROTECTED]> > Date: Tue May 8 00:25:41 2007 -0700 Thanks for doing the bisection. That's "epoll: optimizations and cleanups". - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] v4l: saa7134: add support for 10moons TM300 card
Support the 10moons TM300 TV card (so called TV Master 3), which is a
10moons saa7130 based board.
Here not include features for the IR-remote.
It has been tested using TVTIME. The card was auto-detected and all the
input sources worked correct with sound.
Signed-off-by: Tony Wan <[EMAIL PROTECTED]>
---
drivers/media/video/saa7134/saa7134-cards.c | 38
+++
drivers/media/video/saa7134/saa7134.h |1 +
2 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/saa7134/saa7134-cards.c
b/drivers/media/video/saa7134/saa7134-cards.c
index 50f15ad..44f2077 100644
--- a/drivers/media/video/saa7134/saa7134-cards.c
+++ b/drivers/media/video/saa7134/saa7134-cards.c
@@ -3502,6 +3502,38 @@ struct saa7134_board saa7134_boards[] = {
.amux = TV,
},
},
+ [SAA7134_BOARD_10MOONSTVMASTER3] = {
+ /* Tony Wan <[EMAIL PROTECTED]> */
+ .name = "10MOONS TM300 TV Card",
+ .audio_clock= 0x0020,
+ .tuner_type = TUNER_LG_PAL_NEW_TAPC,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .gpiomask = 0x7000,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = LINE2,
+ .gpio = 0x,
+ .tv = 1,
+ },{
+ .name = name_comp1,
+ .vmux = 3,
+ .amux = LINE1,
+ .gpio = 0x2000,
+ },{
+ .name = name_svideo,
+ .vmux = 8,
+ .amux = LINE1,
+ .gpio = 0x2000,
+ }},
+ .mute = {
+ .name = name_mute,
+ .amux = LINE2,
+ .gpio = 0x3000,
+ },
+ },
};
const unsigned int saa7134_bcount = ARRAY_SIZE(saa7134_boards);
@@ -4219,6 +4251,12 @@ struct pci_device_id saa7134_pci_tbl[] = {
.subdevice= 0x2003, /* OEM cardbus */
.driver_data = SAA7134_BOARD_SABRENT_TV_PCB05,
},{
+ .vendor = PCI_VENDOR_ID_PHILIPS,
+ .device = PCI_DEVICE_ID_PHILIPS_SAA7130,
+ .subvendor= PCI_VENDOR_ID_PHILIPS,
+ .subdevice= 0x2304,
+ .driver_data = SAA7134_BOARD_10MOONSTVMASTER3,
+ },{
/* --- boards without eeprom + subsystem ID --- */
.vendor = PCI_VENDOR_ID_PHILIPS,
.device = PCI_DEVICE_ID_PHILIPS_SAA7134,
diff --git a/drivers/media/video/saa7134/saa7134.h
b/drivers/media/video/saa7134/saa7134.h
index 15623b2..6389c0e 100644
--- a/drivers/media/video/saa7134/saa7134.h
+++ b/drivers/media/video/saa7134/saa7134.h
@@ -238,6 +238,7 @@ struct saa7134_format {
#define SAA7134_BOARD_ECS_TVP3XP_4CB6 113
#define SAA7134_BOARD_KWORLD_DVBT_210 114
#define SAA7134_BOARD_SABRENT_TV_PCB05 115
+#define SAA7134_BOARD_10MOONSTVMASTER3 116
#define SAA7134_MAXBOARDS 8
#define SAA7134_INPUT_MAX 8
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] IB/ehca: Serialize hypervisor calls in ehca_register_mr()
thanks, it all looks fine... I'll apply when I'm back from my trip on Monday. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG][debian-2.6.20-1-686] bridging + vlans + "vconfig rem" == stuck kernel
I've managed to fairly reliably trigger a deadlock in some portion of
the linux networking code on my Debian test box (using the debian
kernel linux-image-2.6.20-1-686). I'm pretty sure that it's a race
condition of some sort as it doesn't trigger if I ifdown the
interfaces one by one, but if I run "ifdown -a" then it triggers
halfway through reliably (although not with the same reference count
numbers, once it was 6, this time it was 2).
The message I get is: "unregister_netdevice: waiting for world0 to
become free. Usage count = 2"
My /etc/network/interfaces file uses a couple custom-made if-pre-up.d
and if-post-down.d scripts to set up the bridges and VLANs a little
more cleanly than the standard debian scripts do, but the general
configuration is as follows:
net0: Tigon-3 onboard gigabit NIC, hooked to managed switch, untagged
packets
wfi0: (net0.2 before renaming) WAP-connected VLAN 2 on the managed
switch
world0: (net0.4094 before renaming) Internet connection, runs DHCP
lan: Local Area Network bridge of "net0" and "wfi0" (current box has
lowest STP priority) This will eventually also have another untagged-
only ethernet port attached to it.
lan:0: Alias for acting as primary nameserver
world: pseudo-bridge of "world0" for highly-available DHCP client.
Just for a bit of background on why this is so complex: When I get
this networking problem sorted out I'm going to set up heartbeat and
a dummy "world1" interface with a shared MAC which is added to the
"world" bridge when the current system is the DHCP-client master.
Hopefully that way I can have 3 systems act as a highly-available
router. Whichever one is currently the master will add the dummy
world1 interface with shared MAC address to its "world" bridge and
bring dhcp3-client up on the "world1" interface with the latest copy
of the leases file from the previous master (even if the previous
master mysteriously crashed. This should keep my public IP from
changing unnecessarily and should allow me to reboot any one of the 3
router/firewall/mailserver/fileserver/etc systems without adversely
affecting the internet connection or other critical services.
Eventually I plan to add ebtables to help filter traffic between wfi*
interfaces and untagged VLAN-1 net* interfaces, but for now there's
no filtering.
Anyways, after the unregister_netdevice messages start popping up all
sorts of networking related things start to hang hard in the kernel;
I can't "ip link set down" any interfaces, etc. I've captured sysrq
dumps of the process state on the system at the time with most
processes. See the attached syslog.bz2 file.
The important part is probably the stuck "vconfig" process, but I
don't really understand enough about the timer stuff to interpret
that backtrace.
vconfig D 83CCD8CE 0 16564 16562 (NOTLB)
efdd7e7c 0086 ee120afb 83ccd8ce 98f00788 b7083ffa
5384b49a c76c0b05
9ebaf791 0004 efdd7e4e 0007 f1468a90 2ab74174
0362 0326
f1468b9c c180e420 0001 0286 c012933c efdd7e8c
df98a000 c180e468
Call Trace:
[] lock_timer_base+0x15/0x2f
[] __mod_timer+0x91/0x9b
[] schedule_timeout+0x70/0x8d
[] vlan_device_event+0x13/0xf8 [8021q]
[] process_timeout+0x0/0x5
[] msleep+0x1a/0x1f
[] netdev_run_todo+0x10f/0x203
[] vlan_ioctl_handler+0x4dc/0x594 [8021q]
[] sock_ioctl+0x145/0x1be
[] sock_ioctl+0x0/0x1be
[] do_ioctl+0x1f/0x62
[] vfs_ioctl+0x244/0x256
[] sys_ioctl+0x4c/0x64
[] syscall_call+0x7/0xb
There's also a whole bunch of processes stuck in netdev_run_todo()
trying to lock a mutex. This even frustratingly affects things like
rndc which use netlink sockets:
rpc.mountdD C9F2BD14 0 4351 1 4425 4229 (NOTLB)
c9f2bd28 0086 0002 c9f2bd14 c9f2bd10
10ff 46422e36
0002 0202 0007 ed266030 495bcd12
03a5 00013461
ed26613c c180e420 0001 dffc8200 dfaeb580
10ff df99ce00
Call Trace:
[] __mutex_lock_slowpath+0x48/0x77
[] mutex_lock+0xa/0xb
[] netdev_run_todo+0x10/0x203
[] netlink_run_queue+0x9f/0xbe
[] rtnetlink_rcv_msg+0x0/0x1d9
[] rtnetlink_rcv+0x34/0x3d
[] netlink_data_ready+0x12/0x4c
[] netlink_sendskb+0x19/0x30
[] netlink_sendmsg+0x26a/0x276
[] sock_sendmsg+0xd0/0xeb
[] autoremove_wake_function+0x0/0x35
[] extract_entropy+0x45/0x89
[] __wake_up+0x32/0x43
[] netlink_insert+0x10f/0x119
[] sys_sendto+0x116/0x140
[] find_get_page+0x18/0x41
[] filemap_nopage+0x197/0x2f9
[] sys_getsockname+0x86/0xb0
[] __handle_mm_fault+0x2ee/0x7d4
[] sys_socketcall+0x15e/0x242
[] syscall_call+0x7/0xb
The "zz-km-vlan" script is the bash if-post-down.d script in charge
of disassembling VLAN interfaces. There is an equivalent "zz-km-
bridge" script for bridge interfaces, as well as if-pre-up.d scripts
called "00-km-vlan" and "00-km-bridge" to create the interfaces.
If anyone has any suggestions,
[patch 04/10] Linux Kernel Markers - PowerPC optimized version
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Cc: Paul Mackerras <[EMAIL PROTECTED]>
Cc: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/Makefile |1
arch/powerpc/kernel/marker.c | 25
include/asm-powerpc/marker.h | 85 +++
3 files changed, 111 insertions(+)
Index: linux-2.6-lttng/arch/powerpc/kernel/Makefile
===
--- linux-2.6-lttng.orig/arch/powerpc/kernel/Makefile 2007-05-09
18:14:51.0 -0400
+++ linux-2.6-lttng/arch/powerpc/kernel/Makefile2007-05-09
18:16:00.0 -0400
@@ -96,3 +96,4 @@
extra-$(CONFIG_PPC_FPU)+= fpu.o
extra-$(CONFIG_PPC64) += entry_64.o
+obj-$(CONFIG_MARKERS_ENABLE_OPTIMIZATION) += marker.o
Index: linux-2.6-lttng/arch/powerpc/kernel/marker.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-lttng/arch/powerpc/kernel/marker.c2007-05-09
18:16:00.0 -0400
@@ -0,0 +1,25 @@
+/* marker.c
+ *
+ * Powerpc optimized marker enabling/disabling.
+ *
+ * Mathieu Desnoyers <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+#include
+#include
+
+int marker_optimized_set_enable(void *address, char enable)
+{
+ char newi[MARK_OPTIMIZED_ENABLE_IMMEDIATE_OFFSET+1];
+ int size = MARK_OPTIMIZED_ENABLE_IMMEDIATE_OFFSET
+ + sizeof(MARK_OPTIMIZED_ENABLE_TYPE);
+
+ memcpy(newi, address, size);
+ MARK_OPTIMIZED_ENABLE([0]) = enable;
+ memcpy(address, newi, size);
+ flush_icache_range((unsigned long)address, size);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(marker_optimized_set_enable);
Index: linux-2.6-lttng/include/asm-powerpc/marker.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-lttng/include/asm-powerpc/marker.h2007-05-09
18:16:00.0 -0400
@@ -0,0 +1,85 @@
+#ifndef _ASM_POWERPC_MARKER_H
+#define _ASM_POWERPC_MARKER_H
+
+/*
+ * marker.h
+ *
+ * Code markup for dynamic and static tracing. PowerPC architecture
+ * optimisations.
+ *
+ * (C) Copyright 2006 Mathieu Desnoyers <[EMAIL PROTECTED]>
+ *
+ * This file is released under the GPLv2.
+ * See the file COPYING for more details.
+ */
+
+#include
+
+#ifdef CONFIG_MARKERS
+
+#define MF_DEFAULT (MF_OPTIMIZED | MF_LOCKDEP | MF_PRINTK)
+
+/* Optimized version of the markers */
+#define trace_mark_optimized(flags, name, format, args...) \
+ do { \
+ static const char __mstrtab_name_##name[] \
+ __attribute__((section("__markers_strings"))) \
+ = #name; \
+ static const char __mstrtab_format_##name[] \
+ __attribute__((section("__markers_strings"))) \
+ = format; \
+ static const char __mstrtab_args_##name[] \
+ __attribute__((section("__markers_strings"))) \
+ = #args; \
+ static struct __mark_marker_data __mark_data_##name \
+ __attribute__((section("__markers_data"))) = \
+ { __mstrtab_name_##name, __mstrtab_format_##name, \
+ __mstrtab_args_##name, \
+ (flags) | MF_OPTIMIZED, __mark_empty_function, NULL }; \
+ char condition; \
+ asm volatile( ".section __markers, \"a\", @progbits;\n\t" \
+ PPC_LONG "%1, 0f;\n\t" \
+ ".previous;\n\t" \
+ ".align 4\n\t" \
+ "0:\n\t" \
+ "li %0,0;\n\t" \
+ : "=r" (condition) \
+ : "i" (&__mark_data_##name)); \
+ __mark_check_format(format, ## args); \
+ if (unlikely(condition)) { \
+ preempt_disable(); \
+ (*__mark_data_##name.call)(&__mark_data_##name, \
+ format, ## args); \
+ preempt_enable(); \
+ } \
+ } while (0)
+
+/* Marker macro selecting the generic or optimized version of marker, depending
+ * on the flags specified. */
+#define _trace_mark(flags, format, args...) \
+do { \
+ if ((flags) & MF_OPTIMIZED) \
+ trace_mark_optimized(flags, format, ## args); \
+ else \
+ trace_mark_generic(flags, format, ## args); \
+} while (0)
+
+/* Marker with default behavior */
+#define trace_mark(format, args...) _trace_mark(MF_DEFAULT, format, ## args)
+
+/* Architecture dependant marker information, used internally for marker
+ * activation. */
+
+/* Offset of the immediate value from the start of the addi instruction (result
+ * of the li mnemonic),
[patch 05/10] Linux Kernel Markers - i386 optimized version
[EMAIL PROTECTED]: marker exports must be EXPORT_SYMBOL_GPL]
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
arch/i386/kernel/Makefile |1
arch/i386/kernel/marker.c | 99 ++
include/asm-i386/marker.h | 84 +++
3 files changed, 184 insertions(+)
Index: linux-2.6-lttng/arch/i386/kernel/Makefile
===
--- linux-2.6-lttng.orig/arch/i386/kernel/Makefile 2007-05-09
18:14:51.0 -0400
+++ linux-2.6-lttng/arch/i386/kernel/Makefile 2007-05-09 18:16:03.0
-0400
@@ -33,6 +33,7 @@
obj-y += sysenter.o vsyscall.o
obj-$(CONFIG_ACPI_SRAT)+= srat.o
obj-$(CONFIG_EFI) += efi.o efi_stub.o
+obj-$(CONFIG_MARKERS_ENABLE_OPTIMIZATION) += marker.o
obj-$(CONFIG_DOUBLEFAULT) += doublefault.o
obj-$(CONFIG_SERIAL_8250) += legacy_serial.o
obj-$(CONFIG_VM86) += vm86.o
Index: linux-2.6-lttng/arch/i386/kernel/marker.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-lttng/arch/i386/kernel/marker.c 2007-05-09 18:16:03.0
-0400
@@ -0,0 +1,99 @@
+/* marker.c
+ *
+ * Erratum 49 fix for Intel PIII and higher.
+ *
+ * Permits marker activation by XMC with correct serialization.
+ *
+ * Reentrant for NMI and trap handler instrumentation. Permits XMC to a
+ * location that has preemption enabled because it involves no temporary or
+ * reused data structure.
+ *
+ * Mathieu Desnoyers <[EMAIL PROTECTED]>
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define BREAKPOINT_INSTRUCTION 0xcc
+#define BREAKPOINT_INS_LEN 1
+
+static DEFINE_MUTEX(mark_mutex);
+static long target_eip = 0;
+
+static void mark_synchronize_core(void *info)
+{
+ sync_core();/* use cpuid to stop speculative execution */
+}
+
+/* We simply skip the 2 bytes load immediate here, leaving the register in an
+ * undefined state. We don't care about the content (0 or !0), because we are
+ * changing the value 0->1 or 1->0. This small window of undefined value
+ * doesn't matter.
+ */
+static int mark_notifier(struct notifier_block *nb,
+ unsigned long val, void *data)
+{
+ enum die_val die_val = (enum die_val) val;
+ struct die_args *args = (struct die_args *)data;
+
+ if (!args->regs || user_mode_vm(args->regs))
+ return NOTIFY_DONE;
+
+ if (die_val == DIE_INT3 && args->regs->eip == target_eip) {
+ args->regs->eip += 1; /* Skip the next byte of load immediate */
+ return NOTIFY_STOP;
+ }
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block mark_notify = {
+ .notifier_call = mark_notifier,
+ .priority = 0x7fff, /* we need to be notified first */
+};
+
+int marker_optimized_set_enable(void *address, char enable)
+{
+ char saved_byte;
+ int ret;
+ char *dest = address;
+
+ if (!(enable ^ dest[1])) /* Must be a state change 0<->1 to execute */
+ return 0;
+
+ mutex_lock(_mutex);
+ target_eip = (long)address + BREAKPOINT_INS_LEN;
+ /* register_die_notifier has memory barriers */
+ register_die_notifier(_notify);
+ saved_byte = *dest;
+ *dest = BREAKPOINT_INSTRUCTION;
+ wmb();
+ /* Execute serializing instruction on each CPU.
+* Acts as a memory barrier. */
+ ret = on_each_cpu(mark_synchronize_core, NULL, 1, 1);
+ BUG_ON(ret != 0);
+
+ dest[1] = enable;
+ wmb();
+ *dest = saved_byte;
+ /* Wait for all int3 handlers to end
+ (interrupts are disabled in int3).
+ This CPU is clearly not in a int3 handler
+ (not preemptible).
+ synchronize_sched has memory barriers */
+ synchronize_sched();
+ unregister_die_notifier(_notify);
+ /* unregister_die_notifier has memory barriers */
+ target_eip = 0;
+ mutex_unlock(_mutex);
+ flush_icache_range(address, size);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(marker_optimized_set_enable);
Index: linux-2.6-lttng/include/asm-i386/marker.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-lttng/include/asm-i386/marker.h 2007-05-09 18:16:03.0
-0400
@@ -0,0 +1,84 @@
+#ifndef _ASM_I386_MARKER_H
+#define _ASM_I386_MARKER_H
+
+/*
+ * marker.h
+ *
+ * Code markup for dynamic and static tracing. i386 architecture optimisations.
+ *
+ * (C) Copyright 2006 Mathieu Desnoyers <[EMAIL PROTECTED]>
+ *
+ * This file is released under the GPLv2.
+ * See the file COPYING for more details.
+ */
+
+
+#ifdef CONFIG_MARKERS
+
+#define
[patch 07/10] Linux Kernel Markers - Documentation
Here is some documentation explaining what is/how to use the Linux Kernel Markers. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- Documentation/marker.txt | 266 +++ 1 file changed, 266 insertions(+) Index: linux-2.6-lttng/Documentation/marker.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/Documentation/marker.txt2007-05-09 18:16:13.0 -0400 @@ -0,0 +1,266 @@ +Using the Linux Kernel Markers + + Mathieu Desnoyers + + + This document introduces to markers and discusses its purpose. It +shows some usage examples of the Linux Kernel Markers : how to insert markers +within the kernel and how to connect probes to a marker. Finally, it has some +probe module examples. This is what connects to a marker. + + +* Purpose of markers + +A marker placed in your code provides a hook to a function (probe) that +you can provide at runtime. A marker can be "on" (a probe is connected to it) +or "off" (no probe is attached). An "off" marker has no effect. When turned on, +the function you provide is called each time the marker is executed in the +execution context of the caller. When the function provided ends its execution, +it returns to the caller (marker site). + +You can put markers at important locations in the code. They act as +lightweight hooks that can pass an arbitrary number of parameters, +described in a printk-like format string, to a function whenever the marker +code is reached. + +They can be used for tracing (LTTng, LKET over SystemTAP), overall performance +accounting (SystemTAP). They could also be used to implement +efficient hooks for SELinux or any other subsystem that would have this +kind of need. + +Using the markers for system audit (SELinux) would require to pass a +variable by address that would be later checked by the marked routine. + + +* Usage + +In order to use the macro MARK, you should include linux/marker.h. + +#include + +Add, in your code : + +trace_mark(subsystem_event, "%d %s", someint, somestring); +Where : +- subsystem_event is an identifier unique to your event +- subsystem is the name of your subsystem. +- event is the name of the event to mark. +- "%d %s" is the formatted string for the serializer. +- someint is an integer. +- somestring is a char pointer. + +Connecting a function (probe) to a marker is done by providing a probe +(function to call) for the specific marker through marker_set_probe(). It will +automatically connect the function and enable the marker site. Removing a probe +is done through marker_remove_probe(). Probe removal is preempt safe because +preemption is disabled around the probe call. See the "Probe example" section +below for a sample probe module. + +The marker mechanism supports multiple instances of the same marker. +Markers can be put in inline functions, inlined static functions and +unrolled loops. + +Note : It is safe to put markers within preempt-safe code : preempt_enable() +will not call the scheduler due to the tests in preempt_schedule(). + + +* Optimization for a given architecture + +You will find, in asm-*/marker.h, optimisations for given architectures +(currently i386 and powerpc). They use a load immediate instead of a data load, +which saves a data cache hit, but also requires cross CPU code modification. In +order to support embedded systems which use read-only memory for their code, the +optimization can be disabled through menu options. + +The MF_* flags can be used to control the type of marker. See the +include/marker.h header for the list of flags. They can be specified as the +first parameter of the _trace_mark() macro, such as the following example which +is safe with respect to lockdep.c (useful for marking lockdep.c and printk +functions). + +_trace_mark(MF_DEFAULT | ~MF_LOCKDEP, subsystem_eventb, MARK_NOARGS); + +Another example is to specify that a specific marker must never call printk : +_trace_mark(MF_DEFAULT | ~MF_PRINTK, subsystem_eventc, + "%d %s", someint, somestring,); + +Flag compatibility is checked before connecting the probe to the marker : the +right flags must be given to _marker_set_enable(). + + +* Probe example + +You can build the kernel modules, probe-example.ko and marker-example.ko, +using the following Makefile: +-- CUT - +obj-m := probe-example.o marker-example.o +KDIR := /lib/modules/$(shell uname -r)/build +PWD := $(shell pwd) +default: + $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules +clean: + rm -f *.mod.c *.ko *.o +-- CUT - +/* probe-example.c + * + * Connects two functions to marker call sites. + * + * (C) Copyright 2007 Mathieu Desnoyers <[EMAIL PROTECTED]> + * + * This file is released
[patch 08/10] Defines the linker macro EXTRA_RWDATA for the marker data section.
Defines the linker macro EXTRA_RWDATA for the marker data section. It puts
the marker data in a separate section that will not pollute the normal .data
section, which minimize the cache impact. Markers need such a special section
because they define a lot of spreaded and small data structures at multiple
sites.
This patch also creates the __markers_strings section (ro marker strings) and
makes sure the __markers section is aligned by putting it before the
__ksymtab_strings (not after).
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/asm-generic/vmlinux.lds.h | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
Index: linux-2.6-lttng/include/asm-generic/vmlinux.lds.h
===
--- linux-2.6-lttng.orig/include/asm-generic/vmlinux.lds.h 2007-05-08
17:07:12.0 -0400
+++ linux-2.6-lttng/include/asm-generic/vmlinux.lds.h 2007-05-08
17:09:12.0 -0400
@@ -116,21 +116,19 @@
*(__kcrctab_gpl_future) \
VMLINUX_SYMBOL(__stop___kcrctab_gpl_future) = .;\
} \
- \
- /* Kernel symbol table: strings */ \
-__ksymtab_strings : AT(ADDR(__ksymtab_strings) - LOAD_OFFSET) {
\
- *(__ksymtab_strings)\
- } \
/* Kernel markers : pointers */ \
- .markers : AT(ADDR(.markers) - LOAD_OFFSET) { \
+ __markers : AT(ADDR(__markers) - LOAD_OFFSET) { \
VMLINUX_SYMBOL(__start___markers) = .; \
- *(.markers) \
+ *(__markers)\
VMLINUX_SYMBOL(__stop___markers) = .; \
} \
- .markers.c : AT(ADDR(.markers.c) - LOAD_OFFSET) { \
- VMLINUX_SYMBOL(__start___markers_c) = .;\
- *(.markers.c) \
- VMLINUX_SYMBOL(__stop___markers_c) = .; \
+ /* Kernel symbol table: strings */ \
+__ksymtab_strings : AT(ADDR(__ksymtab_strings) - LOAD_OFFSET) {
\
+ *(__ksymtab_strings)\
+ } \
+ /* Kernel markers : strings */ \
+ __markers_strings : AT(ADDR(__markers_strings) - LOAD_OFFSET) { \
+ *(__markers_strings)\
} \
__end_rodata = .; \
. = ALIGN(4096);\
@@ -145,6 +143,10 @@
\
. = ALIGN(4096);
+#define EXTRA_RWDATA \
+ . = ALIGN(8); \
+ *(__markers_data) \
+
#define SECURITY_INIT \
.security_initcall.init : AT(ADDR(.security_initcall.init) -
LOAD_OFFSET) { \
VMLINUX_SYMBOL(__security_initcall_start) = .; \
@@ -241,4 +243,3 @@
*(.initcall6s.init) \
*(.initcall7.init) \
*(.initcall7s.init)
-
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/10] Linux Kernel Markers for 2.6.21-mm2
On Wed, 09 May 2007 21:55:55 -0400 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > He is an updated, folded, version of the Linux Kernel Markers. It replaces the > version found in 2.6.21-mm2 at the exact same spot in the series file. urgh. That basically takes us back to square one with whatever review has happened. I suppose I could do s/MARK/trace_mark/g on the existing diffs then have a go at generating incremental diffs so we can review these changes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch added to -mm tree
On Thu, May 10, 2007 at 11:00:17AM +1000, Nick Piggin wrote: > Andrew Morton wrote: > >On Wed, 09 May 2007 12:02:29 +1000 > >Nick Piggin <[EMAIL PROTECTED]> wrote: > > > > > >>BTW, we _really_ should be doing RCU properly in slob, because you > >>technically can't noop RCU on UP (even though the current users may be > >>safe...). > >> > >>Patch attached to do that. > > > > > >Does it work? > > That one booted my desktop (very slowly) but as Matt pointed out, it broke > alignment on RCU slabs. The last version I posted should work and has the > alignment problem fixed. I can retest and resubmit it to you if you like, > I was just waiting on an ack from Matt. Looks good to me, but haven't had time to actually test it. Acked-by: Matt Mackall <[EMAIL PROTECTED]> -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] libata: add human-readable error value decoding
This adds human-readable decoding of the ATA status and error registers (similar
to what drivers/ide does) as well as the SATA Serror register to libata error
handling output. This prevents the need to pore through standards documents
to figure out the meaning of the bits in these registers when looking at error
reports. Some bits that drivers/ide decoded are not decoded here, since the bits
are either command-dependent or obsolete, and properly parsing them would add
too much complexity.
Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
--- linux-2.6.21.1/drivers/ata/libata-eh.c 2007-04-27 15:49:26.0
-0600
+++ linux-2.6.21.1edit/drivers/ata/libata-eh.c 2007-05-09 19:47:53.0
-0600
@@ -1523,6 +1523,27 @@ static void ata_eh_report(struct ata_por
ata_port_printk(ap, KERN_ERR, "(%s)\n", desc);
}
+ if (ehc->i.serror)
+ ata_port_printk(ap, KERN_ERR,
+ "SError: {%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s%s}\n",
+ ehc->i.serror & SERR_DATA_RECOVERED ? "RecovDataErr " : "",
+ ehc->i.serror & SERR_COMM_RECOVERED ? "RecovCommErr " : "",
+ ehc->i.serror & SERR_DATA ? "UnrecovDataErr " : "",
+ ehc->i.serror & SERR_PERSISTENT ? "PersistErr " : "",
+ ehc->i.serror & SERR_PROTOCOL ? "ProtocolErr " : "",
+ ehc->i.serror & SERR_INTERNAL ? "HostInternalErr " : "",
+ ehc->i.serror & SERR_PHYRDY_CHG ? "PHYRdyChg " : "",
+ ehc->i.serror & SERR_PHY_INT_ERR ? "PHYInternalErr " : "",
+ ehc->i.serror & SERR_COMM_WAKE ? "CommWake " : "",
+ ehc->i.serror & SERR_10B_8B_ERR ? "10B8BErr " : "",
+ ehc->i.serror & SERR_DISPARITY ? "Disparity " : "",
+ ehc->i.serror & SERR_CRC ? "CRCErr " : "",
+ ehc->i.serror & SERR_HANDSHAKE ? "HandshakeErr " : "",
+ ehc->i.serror & SERR_LINK_SEQ_ERR ? "LinkSeqErr " : "",
+ ehc->i.serror & SERR_TRANS_ST_ERROR ? "TransStatTransErr " :
"",
+ ehc->i.serror & SERR_UNRECOG_FIS ? "UnrecogFIS " : "",
+ ehc->i.serror & SERR_DEV_XCHG ? "DevExchanged " : "" );
+
for (tag = 0; tag < ATA_MAX_QUEUE; tag++) {
static const char *dma_str[] = {
[DMA_BIDIRECTIONAL] = "bidi",
@@ -1552,6 +1573,29 @@ static void ata_eh_report(struct ata_por
res->hob_feature, res->hob_nsect,
res->hob_lbal, res->hob_lbam, res->hob_lbah,
res->device, qc->err_mask,
ata_err_string(qc->err_mask));
+
+ if (res->command & (ATA_BUSY | ATA_DRDY | ATA_DF | ATA_DRQ |
+ ATA_ERR) ) {
+ if (res->command & ATA_BUSY)
+ ata_dev_printk(qc->dev, KERN_ERR,
+ "status: {Busy}\n" );
+ else
+ ata_dev_printk(qc->dev, KERN_ERR,
+ "status: {%s%s%s%s}\n",
+ res->command & ATA_DRDY ? "DRDY " : "",
+ res->command & ATA_DF ? "DF " : "",
+ res->command & ATA_DRQ ? "DRQ " : "",
+ res->command & ATA_ERR ? "ERR " : "" );
+ }
+
+ if (cmd->command != ATA_CMD_PACKET &&
+ (res->feature & (ATA_ICRC | ATA_UNC | ATA_IDNF |
ATA_ABORTED)))
+ ata_dev_printk(qc->dev, KERN_ERR,
+ "error: {%s%s%s%s}\n",
+ res->feature & ATA_ICRC ? "ICRC " : "",
+ res->feature & ATA_UNC ? "UNC " : "",
+ res->feature & ATA_IDNF ? "IDNF " : "",
+ res->feature & ATA_ABORTED ? "ABRT " : "" );
}
}
--- linux-2.6.21.1/include/linux/ata.h 2007-04-27 15:49:26.0 -0600
+++ linux-2.6.21.1edit/include/linux/ata.h 2007-05-09 19:25:54.0
-0600
@@ -223,6 +223,15 @@ enum {
SERR_PROTOCOL = (1 << 10), /* protocol violation */
SERR_INTERNAL = (1 << 11), /* host internal error */
SERR_PHYRDY_CHG = (1 << 16), /* PHY RDY changed */
+ SERR_PHY_INT_ERR= (1 << 17), /* PHY internal error */
+ SERR_COMM_WAKE = (1 << 18), /* Comm wake */
+ SERR_10B_8B_ERR = (1 << 19), /* 10b to 8b decode error */
+ SERR_DISPARITY = (1 << 20), /* Disparity */
+ SERR_CRC= (1 << 21), /* CRC error */
+ SERR_HANDSHAKE = (1 << 22), /* Handshake error */
+ SERR_LINK_SEQ_ERR = (1 << 23), /* Link sequence error */
+ SERR_TRANS_ST_ERROR = (1 << 24), /* Transport state transition
error */
+ SERR_UNRECOG_FIS= (1 << 25), /*
[patch 10/10] Port of blktrace to the Linux Kernel Markers.
Here is a proof of concept patch, for demonstration purpose, of moving
blktrace to the markers.
A few remarks : this patch has the positive effect of removing some code
from the block io tracing hot paths, minimizing the i-cache impact in a
system where the io tracing is compiled in but inactive.
It also moves the blk tracing code from a header (and therefore from the
body of the instrumented functions) to a separate C file.
There, as soon as one device has to be traced, every devices have to
fall into the tracing function call. This is slower than the previous
inline function which tested the condition quickly. If it becomes a
show stopper, it could be fixed by having the possibility to test a
supplementary condition, dependant of the marker context, at the marker
site, just after the enable/disable test.
It does not make the code smaller, since I left all the specialized
tracing functions for requests, bio, generic, remap, which would go away
once a generic infrastructure is in place to serialize the information
passed to the marker. This is mostly why I consider it a proof a
concept.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
---
block/Kconfig|1
block/blktrace.c | 282 ++-
block/elevator.c |6
block/ll_rw_blk.c| 27 ++--
drivers/block/cciss.c|4
drivers/md/dm.c | 14 +-
fs/bio.c |4
include/linux/blktrace_api.h | 146 +-
mm/bounce.c |4
mm/highmem.c |2
10 files changed, 323 insertions(+), 167 deletions(-)
Index: linux-2.6-lttng/block/elevator.c
===
--- linux-2.6-lttng.orig/block/elevator.c 2007-05-09 18:09:47.0
-0400
+++ linux-2.6-lttng/block/elevator.c2007-05-09 18:16:30.0 -0400
@@ -32,7 +32,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -551,7 +551,7 @@
unsigned ordseq;
int unplug_it = 1;
- blk_add_trace_rq(q, rq, BLK_TA_INSERT);
+ trace_mark(blk_request_insert, "%p %p", q, rq);
rq->q = q;
@@ -730,7 +730,7 @@
* not be passed by new incoming requests
*/
rq->cmd_flags |= REQ_STARTED;
- blk_add_trace_rq(q, rq, BLK_TA_ISSUE);
+ trace_mark(blk_request_issue, "%p %p", q, rq);
}
if (!q->boundary_rq || q->boundary_rq == rq) {
Index: linux-2.6-lttng/block/ll_rw_blk.c
===
--- linux-2.6-lttng.orig/block/ll_rw_blk.c 2007-05-09 18:14:40.0
-0400
+++ linux-2.6-lttng/block/ll_rw_blk.c 2007-05-09 18:16:30.0 -0400
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1551,7 +1552,7 @@
if (!test_and_set_bit(QUEUE_FLAG_PLUGGED, >queue_flags)) {
mod_timer(>unplug_timer, jiffies + q->unplug_delay);
- blk_add_trace_generic(q, NULL, 0, BLK_TA_PLUG);
+ trace_mark(blk_plug_device, "%p %p %d", q, NULL, 0);
}
}
@@ -1617,7 +1618,7 @@
* devices don't necessarily have an ->unplug_fn defined
*/
if (q->unplug_fn) {
- blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
+ trace_mark(blk_pdu_unplug_io, "%p %p %d", q, NULL,
q->rq.count[READ] + q->rq.count[WRITE]);
q->unplug_fn(q);
@@ -1628,7 +1629,7 @@
{
request_queue_t *q = container_of(work, request_queue_t, unplug_work);
- blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
+ trace_mark(blk_pdu_unplug_io, "%p %p %d", q, NULL,
q->rq.count[READ] + q->rq.count[WRITE]);
q->unplug_fn(q);
@@ -1638,7 +1639,7 @@
{
request_queue_t *q = (request_queue_t *)data;
- blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_TIMER, NULL,
+ trace_mark(blk_pdu_unplug_timer, "%p %p %d", q, NULL,
q->rq.count[READ] + q->rq.count[WRITE]);
kblockd_schedule_work(>unplug_work);
@@ -2150,7 +2151,7 @@
rq_init(q, rq);
- blk_add_trace_generic(q, bio, rw, BLK_TA_GETRQ);
+ trace_mark(blk_get_request, "%p %p %d", q, bio, rw);
out:
return rq;
}
@@ -2180,7 +2181,7 @@
if (!rq) {
struct io_context *ioc;
- blk_add_trace_generic(q, bio, rw, BLK_TA_SLEEPRQ);
+ trace_mark(blk_sleep_request, "%p %p %d", q, bio, rw);
__generic_unplug_device(q);
spin_unlock_irq(q->queue_lock);
@@ -2254,7 +2255,7 @@
*/
void blk_requeue_request(request_queue_t *q, struct request *rq)
{
-
[patch 09/10] Linux Kernel Markers - Use EXTRA_RWDATA in architectures
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
arch/alpha/kernel/vmlinux.lds.S|1 +
arch/arm/kernel/vmlinux.lds.S |1 +
arch/arm26/kernel/vmlinux-arm26-xip.lds.in |1 +
arch/arm26/kernel/vmlinux-arm26.lds.in |1 +
arch/avr32/kernel/vmlinux.lds.c|1 +
arch/cris/arch-v10/vmlinux.lds.S |1 +
arch/cris/arch-v32/vmlinux.lds.S |1 +
arch/frv/kernel/vmlinux.lds.S |1 +
arch/h8300/kernel/vmlinux.lds.S|4 +++-
arch/i386/kernel/vmlinux.lds.S |1 +
arch/ia64/kernel/vmlinux.lds.S |2 +-
arch/m32r/kernel/vmlinux.lds.S |1 +
arch/m68k/kernel/vmlinux-std.lds |1 +
arch/m68k/kernel/vmlinux-sun3.lds |1 +
arch/m68knommu/kernel/vmlinux.lds.S|1 +
arch/mips/kernel/vmlinux.lds.S |2 ++
arch/parisc/kernel/vmlinux.lds.S |1 +
arch/powerpc/kernel/vmlinux.lds.S |2 ++
arch/ppc/kernel/vmlinux.lds.S |1 +
arch/s390/kernel/vmlinux.lds.S |1 +
arch/sh/kernel/vmlinux.lds.S |1 +
arch/sh64/kernel/vmlinux.lds.S |1 +
arch/sparc/kernel/vmlinux.lds.S|1 +
arch/sparc64/kernel/vmlinux.lds.S |1 +
arch/um/kernel/dyn.lds.S |1 +
arch/um/kernel/uml.lds.S |1 +
arch/v850/kernel/vmlinux.lds.S |1 +
arch/x86_64/kernel/vmlinux.lds.S |1 +
arch/xtensa/kernel/vmlinux.lds.S |2 +-
29 files changed, 33 insertions(+), 3 deletions(-)
Index: linux-2.6-lttng/arch/alpha/kernel/vmlinux.lds.S
===
--- linux-2.6-lttng.orig/arch/alpha/kernel/vmlinux.lds.S2007-05-09
18:14:50.0 -0400
+++ linux-2.6-lttng/arch/alpha/kernel/vmlinux.lds.S 2007-05-09
18:16:17.0 -0400
@@ -90,6 +90,7 @@
_data = .;
.data : {/* Data */
*(.data)
+ EXTRA_RWDATA
CONSTRUCTORS
}
Index: linux-2.6-lttng/arch/arm/kernel/vmlinux.lds.S
===
--- linux-2.6-lttng.orig/arch/arm/kernel/vmlinux.lds.S 2007-05-09
18:14:50.0 -0400
+++ linux-2.6-lttng/arch/arm/kernel/vmlinux.lds.S 2007-05-09
18:16:17.0 -0400
@@ -159,6 +159,7 @@
* and the usual data section
*/
*(.data)
+ EXTRA_RWDATA
CONSTRUCTORS
_edata = .;
Index: linux-2.6-lttng/arch/arm26/kernel/vmlinux-arm26-xip.lds.in
===
--- linux-2.6-lttng.orig/arch/arm26/kernel/vmlinux-arm26-xip.lds.in
2007-05-09 18:14:50.0 -0400
+++ linux-2.6-lttng/arch/arm26/kernel/vmlinux-arm26-xip.lds.in 2007-05-09
18:16:17.0 -0400
@@ -112,6 +112,7 @@
* and the usual data section
*/
*(.data)
+ EXTRA_RWDATA
CONSTRUCTORS
*(.init.data)
Index: linux-2.6-lttng/arch/arm26/kernel/vmlinux-arm26.lds.in
===
--- linux-2.6-lttng.orig/arch/arm26/kernel/vmlinux-arm26.lds.in 2007-05-09
18:14:50.0 -0400
+++ linux-2.6-lttng/arch/arm26/kernel/vmlinux-arm26.lds.in 2007-05-09
18:16:17.0 -0400
@@ -107,6 +107,7 @@
* and the usual data section
*/
*(.data)
+ EXTRA_RWDATA
CONSTRUCTORS
_edata = .;
Index: linux-2.6-lttng/arch/avr32/kernel/vmlinux.lds.c
===
--- linux-2.6-lttng.orig/arch/avr32/kernel/vmlinux.lds.c2007-05-09
18:14:50.0 -0400
+++ linux-2.6-lttng/arch/avr32/kernel/vmlinux.lds.c 2007-05-09
18:16:17.0 -0400
@@ -113,6 +113,7 @@
/* And the rest... */
*(.data.rel*)
*(.data)
+ EXTRA_RWDATA
CONSTRUCTORS
_edata = .;
Index: linux-2.6-lttng/arch/cris/arch-v10/vmlinux.lds.S
===
--- linux-2.6-lttng.orig/arch/cris/arch-v10/vmlinux.lds.S 2007-05-09
18:14:50.0 -0400
+++ linux-2.6-lttng/arch/cris/arch-v10/vmlinux.lds.S2007-05-09
18:16:17.0 -0400
@@ -45,6 +45,7 @@
__Sdata = . ;
.data : { /* Data */
*(.data)
+ EXTRA_RWDATA
}
__edata = . ; /* End of data section */
_edata = . ;
Index: linux-2.6-lttng/arch/cris/arch-v32/vmlinux.lds.S
===
---
[patch 02/10] Linux Kernel Markers, architecture independent code.
[EMAIL PROTECTED]: marker exports must be EXPORT_SYMBOL_GPL]
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
include/asm-generic/vmlinux.lds.h | 13 +
include/linux/marker.h| 124 +
include/linux/module.h|4
kernel/module.c | 273 ++
4 files changed, 414 insertions(+)
Index: linux-2.6-lttng/include/asm-generic/vmlinux.lds.h
===
--- linux-2.6-lttng.orig/include/asm-generic/vmlinux.lds.h 2007-05-09
18:14:52.0 -0400
+++ linux-2.6-lttng/include/asm-generic/vmlinux.lds.h 2007-05-09
18:15:55.0 -0400
@@ -121,6 +121,19 @@
__ksymtab_strings : AT(ADDR(__ksymtab_strings) - LOAD_OFFSET) {
\
*(__ksymtab_strings)\
} \
+ /* Kernel markers : pointers */ \
+ .markers : AT(ADDR(.markers) - LOAD_OFFSET) { \
+ VMLINUX_SYMBOL(__start___markers) = .; \
+ *(.markers) \
+ VMLINUX_SYMBOL(__stop___markers) = .; \
+ } \
+ .markers.c : AT(ADDR(.markers.c) - LOAD_OFFSET) { \
+ VMLINUX_SYMBOL(__start___markers_c) = .;\
+ *(.markers.c) \
+ VMLINUX_SYMBOL(__stop___markers_c) = .; \
+ } \
+ __end_rodata = .; \
+ . = ALIGN(4096);\
\
/* Built-in module parameters. */ \
__param : AT(ADDR(__param) - LOAD_OFFSET) { \
Index: linux-2.6-lttng/include/linux/marker.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-2.6-lttng/include/linux/marker.h 2007-05-09 18:15:55.0
-0400
@@ -0,0 +1,124 @@
+#ifndef _LINUX_MARKER_H
+#define _LINUX_MARKER_H
+
+/*
+ * marker.h
+ *
+ * Code markup for dynamic and static tracing.
+ *
+ * See Documentation/marker.txt.
+ *
+ * (C) Copyright 2006 Mathieu Desnoyers <[EMAIL PROTECTED]>
+ *
+ * This file is released under the GPLv2.
+ * See the file COPYING for more details.
+ */
+
+#ifdef __KERNEL__
+
+struct __mark_marker_data;
+
+typedef void marker_probe_func(const struct __mark_marker_data *mdata,
+ const char *fmt, ...);
+
+struct __mark_marker_data {
+ const char *name;
+ const char *format;
+ const char *args;
+ int flags;
+ marker_probe_func *call;
+ void *pdata;
+} __attribute__((packed));
+
+struct __mark_marker {
+ struct __mark_marker_data *mdata;
+ void *enable;
+} __attribute__((packed));
+
+#ifdef CONFIG_MARKERS
+
+/* Marker flags : selects the mechanism used to connect the probes to the
+ * markers and what can be executed within the probes. This is primarily
+ * used at reentrancy-unfriendly sites. */
+#define MF_OPTIMIZED (1 << 0)/* Use optimized markers */
+#define MF_LOCKDEP (1 << 1)/* Can call lockdep */
+#define MF_PRINTK (1 << 2)/* vprintk can be called in the probe */
+#define _MF_NR 3 /* Number of marker flags */
+
+/* Generic marker flavor always available */
+#define trace_mark_generic(flags, name, format, args...) \
+ do { \
+ static const char __mstrtab_name_##name[] \
+ __attribute__((section("__markers_strings"))) \
+ = #name; \
+ static const char __mstrtab_format_##name[] \
+ __attribute__((section("__markers_strings"))) \
+ = format; \
+ static const char __mstrtab_args_##name[] \
+ __attribute__((section("__markers_strings"))) \
+ = #args; \
+ static struct __mark_marker_data __mark_data_##name \
+ __attribute__((section("__markers_data"))) = \
+ { __mstrtab_name_##name, __mstrtab_format_##name, \
+ __mstrtab_args_##name, \
+ (flags) & ~MF_OPTIMIZED, __mark_empty_function, NULL }; \
+ static char __marker_enable_##name = 0; \
+ static const struct __mark_marker __mark_##name \
+ __attribute__((section("__markers"))) = \
+ { &__mark_data_##name, &__marker_enable_##name } ; \
+ asm
[patch 06/10] Linux Kernel Markers - Non optimized architectures
This patch also includes marker code for non optimized architectures. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> --- include/asm-alpha/marker.h | 13 + include/asm-arm/marker.h | 13 + include/asm-arm26/marker.h | 13 + include/asm-cris/marker.h | 13 + include/asm-frv/marker.h | 13 + include/asm-generic/marker.h | 37 + include/asm-h8300/marker.h | 13 + include/asm-ia64/marker.h | 13 + include/asm-m32r/marker.h | 13 + include/asm-m68k/marker.h | 13 + include/asm-m68knommu/marker.h | 13 + include/asm-mips/marker.h | 13 + include/asm-parisc/marker.h| 13 + include/asm-ppc/marker.h | 13 + include/asm-s390/marker.h | 13 + include/asm-sh/marker.h| 13 + include/asm-sh64/marker.h | 13 + include/asm-sparc/marker.h | 13 + include/asm-sparc64/marker.h | 13 + include/asm-um/marker.h| 13 + include/asm-v850/marker.h | 13 + include/asm-x86_64/marker.h| 13 + include/asm-xtensa/marker.h| 13 + 23 files changed, 323 insertions(+) Index: linux-2.6-lttng/include/asm-arm/marker.h === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/include/asm-arm/marker.h2007-05-09 18:16:05.0 -0400 @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include Index: linux-2.6-lttng/include/asm-cris/marker.h === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/include/asm-cris/marker.h 2007-05-09 18:16:05.0 -0400 @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include Index: linux-2.6-lttng/include/asm-frv/marker.h === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/include/asm-frv/marker.h2007-05-09 18:16:05.0 -0400 @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + * + * No optimisation implemented. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + */ + +#include Index: linux-2.6-lttng/include/asm-generic/marker.h === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/include/asm-generic/marker.h2007-05-09 18:16:05.0 -0400 @@ -0,0 +1,37 @@ +#ifndef _ASM_GENERIC_MARKER_H +#define _ASM_GENERIC_MARKER_H + +/* + * marker.h + * + * Code markup for dynamic and static tracing. Generic header. + * + * This file is released under the GPLv2. + * See the file COPYING for more details. + * + * Note : the empty asm volatile with read constraint is used here instead of a + * "used" attribute to fix a gcc 4.1.x bug. + */ + +/* Default flags, used by MARK() */ +#define MF_DEFAULT (MF_LOCKDEP | MF_PRINTK) + +/* Fallback on the generic markers, since no optimized version is available */ +#define trace_mark_optimized trace_mark_generic +#define _trace_marktrace_mark_generic + +/* Marker with default behavior */ +#define trace_mark(format, args...)_trace_mark(MF_DEFAULT, format, ## args) + +/* Architecture dependant marker information, used internally for marker + * activation. */ + +#define MARK_OPTIMIZED_ENABLE_IMMEDIATE_OFFSET \ + MARK_GENERIC_ENABLE_IMMEDIATE_OFFSET +#define MARK_OPTIMIZED_ENABLE_TYPE MARK_GENERIC_ENABLE_TYPE +/* Dereference enable as lvalue from a pointer to its instruction */ +#define MARK_OPTIMIZED_ENABLE MARK_GENERIC_ENABLE + +#define marker_optimized_set_enable marker_generic_set_enable + +#endif /* _ASM_GENERIC_MARKER_H */ Index: linux-2.6-lttng/include/asm-h8300/marker.h === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/include/asm-h8300/marker.h 2007-05-09 18:16:05.0 -0400 @@ -0,0 +1,13 @@ +/* + * marker.h + * + * Code markup for dynamic and static tracing. Architecture specific + * optimisations. + *
[patch 01/10] Linux Kernel Markers - Add kconfig menus for the marker code
With the increasing complexity of today's user-space application and the wide deployment of SMP systems, the users need an increasing understanding of the behavior and performance of a system across multiple processes/different execution contexts/multiple CPUs. In applications such as large clusters (Google, IBM), video acquisition (Autodesk), embedded real-time systems (Wind River, Monta Vista, Sony) or sysadmin/programmer-type tasks (SystemTAP from Redhat), a tool that permits tracing of kernel-user space interaction becomes necessary. Usage of such tools have been made to successfully pinpoint problems such as: latency issues in a user-space video acquisition application, slowdown problems in large clusters due to a switch to a different filesystems with a different cache size, abnormal Linux scheduler latency (just to name a few that I have personally investigated). The currently existing solutions does not give a system-wide overview of what - and when - things are happening on the system. Ptracing a program works with few processes, but quickly becomes useless when it comes to keeping track of many processes. Bugs occuring because of bad interaction of such complex systems can be very hard to find due to the fact that they occur rarely (sometimes once a week on hundreds of machines). One can therefore only hope at having the best conditions to statistically reproduce the bug while extracting information from the system. Some bugs have been successfully found at Google using their ktrace tracer only because they could enable it on production machines and therefore recreate the same context where the bug happened. Therefore, it makes sense to offer an instrumentation set of the most relevant events occurring in the Linux that can have the smallest performance cost possible when not active while not requiring a reboot of a production system to activate. This is essentially what the markers are providing. Since we cannot limit the growth of the Linux kernel, nor can we pre-determine each and every "interesting" instrumentation within each subsystem and driver, it is sensible to let this task to the persons who knows the best their code. Adding instrumentation should therefore be as easy as adding and maintaining a "printk" in the kernel code from the developer's point of view. Towards a complete tracing mechanism in the Linux kernel, the markers are only one step forward. The following step is to connect probes to those markers that will record the tracing information in buffers exported to user-space, organized in timestamped "events". Probe callbacks are responsible for serializing the information passed as parameter to the markers (described by the format string) into the events. A control mechanism to activate/stop the tracing is required, as well as a daemon that maps the buffers to write them to disk or send them through the network. Keeping track of the events also requires a centralized infrastructure : the idea is to assign a unique ID to each event so they can be later recognized in the trace. Keeping in mind that recording the complete instrumentation site name string for each event would be more that inefficient, assigning a numeric unique identifier makes sense. Finally, support for gathering events coming from user-space, with a minimal performance impact, is very useful to see the interaction between the system's execution contexts. The last steps are currently implemented in Linux Trace Toolkit Next Generation (LTTng). The SystemTAP project could clearly benefit from such an infrastructure for tracing. In addition, they would be providing support for dynamic addition of kernel probes through breakpoints/jumps when possible, with the associated restrictions (accessing local variables, reentrancy, speed). This marker infrastructure is a hook-callback mechanism. It is meant to have an impact as low as possible on the system performances when no callback (probe) is connected so markers (hooks) can be compiled into a production kernel without noticeable slowdown. The rationale behind this mechanism the following : 1 - It makes sense to have instrumentation (for tracing, profiling) within the kernel source tree so that it can follow its evolution. Other options, such as kprobes, imply maintaining an external set of instrumentation that must be adapted to each kernel version. Although it may make sense for distributions, it is not well suited for kernel developers, since they rarely work on a major distribution image. 2 - kprobes, although being a very good attempt at providing a dynamic hooking mechanism that has no impact when disabled, suffers from important limitations : a - It cannot access local variables of a function at a particular point within its body that will be consistent thorough the kernel versions without involving a lot of recurrent hair-pulling. b - Kprobes is slow, since it involves going though a
[patch 03/10] Allow userspace applications to use marker.h to parse the markers section in the kernel binary.
One of the things I'm starting to work on is adding support for your
kernel markers to systemtap. I know the marker stuff is still in a bit
of flux because you are trying to meet the (sometimes conflicting)
requirements of the people on lkml.
One of the things systemtap is going to need is to be able to parse the
'__markers' section so it will be able to look up a user-specified
marker. For instance, if the user says 'probe kernel.mark("foo") {}',
I've got to see if marker "foo" really exists.
There are 2 problems with this currently, since systemtap is a user-land
program:
1) include/linux/markers.h isn't currently installed by "make
headers_install"
2) even if include/linux/markers.h was installed, it is completely
surrounded by "#ifdef __KERNEL__"
So, I've attached a patch that tries to fix those 2 problems. I've
moved "#ifdef __KERNEL__" down a bit past the structure and flag
definitions and included marker.h in Kbuild so it will get installed.
I'd appreciate any comments you have. I'd like to get either this
patch or something like it included in the next version you post to lkml.
Signed-off-by: David Smith <[EMAIL PROTECTED]>
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
---
include/linux/Kbuild |1 +
include/linux/marker.h |8
2 files changed, 5 insertions(+), 4 deletions(-)
Index: linux-2.6-lttng/include/linux/marker.h
===
--- linux-2.6-lttng.orig/include/linux/marker.h 2007-05-09 18:15:55.0
-0400
+++ linux-2.6-lttng/include/linux/marker.h 2007-05-09 21:44:47.0
-0400
@@ -14,8 +14,6 @@
* See the file COPYING for more details.
*/
-#ifdef __KERNEL__
-
struct __mark_marker_data;
typedef void marker_probe_func(const struct __mark_marker_data *mdata,
@@ -35,8 +33,6 @@
void *enable;
} __attribute__((packed));
-#ifdef CONFIG_MARKERS
-
/* Marker flags : selects the mechanism used to connect the probes to the
* markers and what can be executed within the probes. This is primarily
* used at reentrancy-unfriendly sites. */
@@ -45,6 +41,10 @@
#define MF_PRINTK (1 << 2)/* vprintk can be called in the probe */
#define _MF_NR 3 /* Number of marker flags */
+#ifdef __KERNEL__
+
+#ifdef CONFIG_MARKERS
+
/* Generic marker flavor always available */
#define trace_mark_generic(flags, name, format, args...) \
do { \
Index: linux-2.6-lttng/include/linux/Kbuild
===
--- linux-2.6-lttng.orig/include/linux/Kbuild 2007-05-09 21:41:55.0
-0400
+++ linux-2.6-lttng/include/linux/Kbuild2007-05-09 21:46:07.0
-0400
@@ -254,6 +254,7 @@
unifdef-y += llc.h
unifdef-y += loop.h
unifdef-y += lp.h
+unifdef-y += marker.h
unifdef-y += mempolicy.h
unifdef-y += mii.h
unifdef-y += mman.h
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 00/10] Linux Kernel Markers for 2.6.21-mm2
Hi Andrew, He is an updated, folded, version of the Linux Kernel Markers. It replaces the version found in 2.6.21-mm2 at the exact same spot in the series file. Main changes : - It renames the MARK() trace_mark(), as suggested by Christoph Hellwig. - It now defines the structures contained out of the marker section outside of the #ifdef __KERNEL__ so the SystemTAP tool can use the header to extract the markers from the kernel binary. - The i386 optimization has been tweaked a bit : the call is now in the else branch. It has something to do with the i386 "fast path" being the taken branch of a jump, to make loops faster. It seems that the if/else statements are also affected : the if () will be faster than the else. Therefore, I put the call in the else, to make sure the fastest path is when the marker is disabled. - I added the blktrace port to the markers infrastructure. It makes one in-tree markers user. Please remove : linux-kernel-markers-kconfig-menus.patch linux-kernel-markers-architecture-independant-code.patch linux-kernel-markers-powerpc-optimization.patch linux-kernel-markers-i386-optimization.patch markers-add-instrumentation-markers-menus-to-avr32.patch linux-kernel-markers-non-optimized-architectures.patch markers-alpha-and-avr32-supportadd-alpha-markerh-add-arm26-markerh.patch linux-kernel-markers-documentation.patch # markers-define-the-linker-macro-extra_rwdata.patch markers-use-extra_rwdata-in-architectures.patch And add, instead : linux-kernel-markers-kconfig-menus.patch linux-kernel-markers-architecture-independant-code.patch linux-kernel-markers-header-visible-from-userspace.h linux-kernel-markers-powerpc-optimization.patch linux-kernel-markers-i386-optimization.patch linux-kernel-markers-non-optimized-architectures.patch linux-kernel-markers-documentation.patch # linux-kernel-markers-define-the-linker-macro-extra_rwdata.patch linux-kernel-markers-use-extra_rwdata-in-architectures.patch # linux-kernel-markers-port-blktrace-to-markers.patch Thanks, Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] time locale in gen_initramfs_list.sh
On Wednesday 09 May 2007 8:09 pm, Andrew Morton wrote: > hm, --time-style sounds rather gnu-specific and perhaps we'd rather not > add that requirement. Or perhaps we already require gnu ls, dunno. Running this sort of thing with busybox instead of the gnu tools is why I sent the gawk/awk patches earlier. If a requirement for gnu ls has snuck in, it's been within the last few months. Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Announcing free software drivers for the new Intel® 965GM Express Chipset
The Intel® 965GM Express Chipset represents the first mobile product that implements fourth generation Intel graphics architecture. Designed to support advanced rendering features in modern graphics APIs, this chipset includes support for programmable vertex, geometry, and fragment shaders. Extending Intel's commitment to work with the X.org and Mesa communities to continuously improve and enhance the drivers, support for this new chipset is provided through the X.org 2.0 Intel driver and the Mesa 6.5.3 releases. These drivers represent significant work by both Intel and the broader open source community. In addition to Intel® 965GM chipset support, the X.org 2.0 driver adds native video mode programming support for all chipsets from i830 forward. The driver supports automatic video mode detection and selection, monitor hot plug, dynamic extended and merged desktops and per-monitor screen rotation. These Intel-developed features are built in to the X.org 1.3 X server release and will eventually be supported across most of the open source X.org video drivers. Additional information available on the web: http://intellinuxgraphics.org "Intel's committment to providing high-quality drivers that meet the needs of the mobile Linux community is second to none." Matthew Garrett, Ubuntu Mobile Linux Engineer -- [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: swap-prefetch: 2.6.22 -mm merge plans
Con Kolivas wrote: On Thursday 10 May 2007 10:05, Nick Piggin wrote: I'm not the gatekeeper and it is completely up to you whether you want to work on something or not... but I'm sure you understand where I was coming from when I suggested it doesn't get merged yet. No matter how you spin it, you're the gatekeeper. If raising unaddressed issues means closing a gate, then OK. You can equally open it by answering them. You may not believe this, but I agree that swap prefetching (and prefetching in general) has some potential to help desktop workloads :). But it still should go through the normal process of being tested and questioned and having a look at options for first improving existing code in those problematic cases. Not this again? Proof was there ages ago that it helped and no proof that it harmed could be found yet you cunningly pretend it never existed. It's been done to death and I'm sick of this. I said I know it can help. Do you know how many patches I have that help some workloads but are not merged? That's just the way it works. What I have seen is it helps the case where you force out a huge amount of swap. OK, that's nice -- the base case obviously works. You said it helped with the updatedb problem. That says we should look at why it is going bad first, and for example improve use-once algorithms. After we do that, then swap prefetching might still help, which is fine. Once that process happens and it is shown to work nicely, etc., then I would not be able to (or want to) keep it from getting merged. As far as cpusets goes... if your code goes in last, then you have to make it work with what is there, as a rule. People are using cpusets for memory resource control, which would have uses on a desktop system. It is just a really bad precedent to set, having different parts of the VM not work correctly together. Even if you made them mutually exclusive CONFIG_ options, that is still not a very nice solution. That's as close to a 3 as I'm likely to get out of you. If you're not willing to try making it work with existing code, among other things, then yes it will be difficult to get it merged. That's not going to change. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Please revert 5b479c91da90eef605f851508744bfe8269591a0 (md partition rescan)
On Thu, 10 May 2007, Neil Brown wrote: > > Hi Linus, > Could you please revert > > 5b479c91da90eef605f851508744bfe8269591a0 Done. (But Andrew never saw your email, I suspect: "[EMAIL PROTECTED]" is probably some strange mixup of Andrew Morton and Andi Kleen in your mind ;) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Use write_trylock_irqsave in ptrace_attach
On Wed, 9 May 2007 14:13:27 +0530 Sripathi Kodi <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This patch makes ptrace_attach use write_trylock_irqsave.
>
> Signed-off-by: Sripathi Kodi <[EMAIL PROTECTED]>
>
> ---
> kernel/ptrace.c |7 +++
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> Index: linux-2.6.21/kernel/ptrace.c
> ===
> --- linux-2.6.21.orig/kernel/ptrace.c
> +++ linux-2.6.21/kernel/ptrace.c
> @@ -160,6 +160,7 @@ int ptrace_may_attach(struct task_struct
> int ptrace_attach(struct task_struct *task)
> {
> int retval;
> + unsigned long flags = 0;
>
> retval = -EPERM;
> if (task->pid <= 1)
> @@ -178,9 +179,7 @@ repeat:
>* cpu's that may have task_lock).
>*/
> task_lock(task);
> - local_irq_disable();
> - if (!write_trylock(_lock)) {
> - local_irq_enable();
> + if (!write_trylock_irqsave(_lock, flags)) {
> task_unlock(task);
> do {
> cpu_relax();
> @@ -208,7 +207,7 @@ repeat:
> force_sig_specific(SIGSTOP, task);
>
> bad:
> - write_unlock_irq(_lock);
> + write_unlock_irqrestore(_lock, flags);
> task_unlock(task);
> out:
> return retval;
Your changelogs aren't vey logical. The context for this change is off in
a different patch. I reproduce it here:
> I am trying to fix the BUG I mentioned here:
> http://lkml.org/lkml/2007/04/20/41. I noticed that an elegant way to solve
> this problem is to have a write_trylock_irqsave helper function. Since we
> don't have this now, the code in ptrace_attach implements it using
> local_irq_disable and write_trylock. I wish to add write_trylock_irqsave to
> mainline kernel and then fix the -rt specific problem using this.
I can't imagine why -rt's write_unlock_irq() doesn't do local_irq_enable().
I have no problem adding write_trylock_irqsave() - it fills a gap in the
API.
Once we have write_trylock_irqsave() it makes sense to use it here.
One the downside, we added a few bytes to the SMP kernel, which I guess we
can live with.
Whether this change is desired in -rt I don't know. Ingo?
I don't think the initialisation of `flags' there was needed?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] powerpc prom.c - Remove #undef printk
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/prom.c |2 --
1 file changed, 2 deletions(-)
Index: linux-2.6-lttng/arch/powerpc/kernel/prom.c
===
--- linux-2.6-lttng.orig/arch/powerpc/kernel/prom.c 2007-05-09
14:56:55.0 -0400
+++ linux-2.6-lttng/arch/powerpc/kernel/prom.c 2007-05-09 14:57:24.0
-0400
@@ -1040,8 +1040,6 @@
DBG(" <- early_init_devtree()\n");
}
-#undef printk
-
int of_n_addr_cells(struct device_node* np)
{
const int *ip;
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 0/1] Remove #undef printk in powerpc prom.c
Hi Paul, Is there a reason why there is a #undef printk in arch/powerpc/kernel/prom.c ? It looks a little odd... Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git patch] move USB net drivers to drivers/net
This was ACK'd by Greg, as you see in the sign-offs. See the commit
below for rationale.
USB is now treated like other buses, for network drivers:
* USB network driver patches should go to me and netdev
* Just like in PCI or PCMCIA land, bus-specific code may
originate from the USB side of the house (Greg's tree).
Please pull from 'usb-move' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git usb-move
to receive the following update:
commit 5b2fc499917e5897a13add780e181b4cef197072
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed May 9 21:31:55 2007 -0400
Move USB network drivers to drivers/net/usb.
It is preferable to group drivers by usage (net, scsi, ATA, ...) than
by bus. When reviewing drivers, the [PCI|USB|PCMCIA|...] maintainer
is probably less qualified on networking issues than a networking
maintainer. Also, from a practical standpoint, chips often
appear on multiple buses, which is why we do not put drivers into
drivers/pci/net.
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/net/Kconfig |2 ++
drivers/net/Makefile |8
drivers/{usb/net => net/usb}/Kconfig |0
drivers/{usb/net => net/usb}/Makefile |0
drivers/{usb/net => net/usb}/asix.c |0
drivers/{usb/net => net/usb}/catc.c |0
drivers/{usb/net => net/usb}/cdc_ether.c |0
drivers/{usb/net => net/usb}/cdc_subset.c |0
drivers/{usb/net => net/usb}/dm9601.c |0
drivers/{usb/net => net/usb}/gl620a.c |0
drivers/{usb/net => net/usb}/kaweth.c |0
drivers/{usb/net => net/usb}/kawethfw.h |0
drivers/{usb/net => net/usb}/mcs7830.c|0
drivers/{usb/net => net/usb}/net1080.c|0
drivers/{usb/net => net/usb}/pegasus.c|0
drivers/{usb/net => net/usb}/pegasus.h|0
drivers/{usb/net => net/usb}/plusb.c |0
drivers/{usb/net => net/usb}/rndis_host.c |0
drivers/{usb/net => net/usb}/rtl8150.c|0
drivers/{usb/net => net/usb}/usbnet.c |0
drivers/{usb/net => net/usb}/usbnet.h |0
drivers/{usb/net => net/usb}/zaurus.c |0
drivers/usb/Kconfig |2 --
drivers/usb/Makefile |7 ---
24 files changed, 10 insertions(+), 9 deletions(-)
rename drivers/{usb/net => net/usb}/Kconfig (100%)
rename drivers/{usb/net => net/usb}/Makefile (100%)
rename drivers/{usb/net => net/usb}/asix.c (100%)
rename drivers/{usb/net => net/usb}/catc.c (100%)
rename drivers/{usb/net => net/usb}/cdc_ether.c (100%)
rename drivers/{usb/net => net/usb}/cdc_subset.c (100%)
rename drivers/{usb/net => net/usb}/dm9601.c (100%)
rename drivers/{usb/net => net/usb}/gl620a.c (100%)
rename drivers/{usb/net => net/usb}/kaweth.c (100%)
rename drivers/{usb/net => net/usb}/kawethfw.h (100%)
rename drivers/{usb/net => net/usb}/mcs7830.c (100%)
rename drivers/{usb/net => net/usb}/net1080.c (100%)
rename drivers/{usb/net => net/usb}/pegasus.c (100%)
rename drivers/{usb/net => net/usb}/pegasus.h (100%)
rename drivers/{usb/net => net/usb}/plusb.c (100%)
rename drivers/{usb/net => net/usb}/rndis_host.c (100%)
rename drivers/{usb/net => net/usb}/rtl8150.c (100%)
rename drivers/{usb/net => net/usb}/usbnet.c (100%)
rename drivers/{usb/net => net/usb}/usbnet.h (100%)
rename drivers/{usb/net => net/usb}/zaurus.c (100%)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index b86ccd2..d9842d8 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2499,6 +2499,8 @@ source "drivers/net/tokenring/Kconfig"
source "drivers/net/wireless/Kconfig"
+source "drivers/net/usb/Kconfig"
+
source "drivers/net/pcmcia/Kconfig"
source "drivers/net/wan/Kconfig"
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 59c0459..c5d8423 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -206,6 +206,14 @@ obj-$(CONFIG_TR) += tokenring/
obj-$(CONFIG_WAN) += wan/
obj-$(CONFIG_ARCNET) += arcnet/
obj-$(CONFIG_NET_PCMCIA) += pcmcia/
+
+obj-$(CONFIG_USB_CATC) += usb/
+obj-$(CONFIG_USB_KAWETH)+= usb/
+obj-$(CONFIG_USB_PEGASUS) += usb/
+obj-$(CONFIG_USB_RTL8150) += usb/
+obj-$(CONFIG_USB_USBNET)+= usb/
+obj-$(CONFIG_USB_ZD1201)+= usb/
+
obj-y += wireless/
obj-$(CONFIG_NET_TULIP) += tulip/
obj-$(CONFIG_HAMRADIO) += hamradio/
[SNIP ADD PATCHES AS OBVIOUS]
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index b847bbc..278a22c 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -87,8 +87,6 @@ source "drivers/usb/storage/Kconfig"
source "drivers/usb/image/Kconfig"
-source "drivers/usb/net/Kconfig"
-
source "drivers/usb/mon/Kconfig"
comment "USB port drivers"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 0ef090b..72464b5 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
Re: swap-prefetch: 2.6.22 -mm merge plans
On Thursday 10 May 2007 10:05, Nick Piggin wrote: > Con Kolivas wrote: > > Well how about that? That was the difference with a swap _file_ as I > > said, but I went ahead and checked with a swap partition as I used to > > have. I didn't notice, but somewhere in the last few months, swap > > prefetch code itself being unchanged for a year, seems to have been > > broken by other changes in the vm and it doesn't even start up > > prefetching often and has stale swap entries in its list. Once it breaks > > like that it does nothing from then on. So that leaves me with a quandry > > now. > > > > > > Do I: > > > > 1. Go ahead and find whatever breakage was introduced and fix it with > > hopefully a trivial change > > > > 2. Do option 1. and then implement support for yet another kernel feature > > (cpusets) that will be used perhaps never with swap prefetch [No Nick I > > don't believe you that cpusets have anything to do with normal users on a > > desktop ever; if it's used on a desktop it will only be by a kernel > > developer testing the cpusets code]. > > > > or > > > > 3. Dump swap prefetch forever and ignore that it ever worked and was > > helpful and was a lot of work to implement and so on. > > > > > > Given that even if I do 1 and/or 2 it'll still be blocked from ever going > > to mainline I think the choice is clear. > > > > Nick since you're personally the gatekeeper for this code, would you like > > to make a call? Just say 3 and put me out of my misery please. > > I'm not the gatekeeper and it is completely up to you whether you want > to work on something or not... but I'm sure you understand where I was > coming from when I suggested it doesn't get merged yet. No matter how you spin it, you're the gatekeeper. > You may not believe this, but I agree that swap prefetching (and > prefetching in general) has some potential to help desktop workloads :). > But it still should go through the normal process of being tested and > questioned and having a look at options for first improving existing > code in those problematic cases. Not this again? Proof was there ages ago that it helped and no proof that it harmed could be found yet you cunningly pretend it never existed. It's been done to death and I'm sick of this. > Once that process happens and it is shown to work nicely, etc., then I > would not be able to (or want to) keep it from getting merged. > > As far as cpusets goes... if your code goes in last, then you have to > make it work with what is there, as a rule. People are using cpusets > for memory resource control, which would have uses on a desktop system. > It is just a really bad precedent to set, having different parts of the > VM not work correctly together. Even if you made them mutually > exclusive CONFIG_ options, that is still not a very nice solution. That's as close to a 3 as I'm likely to get out of you. Andrew you'll be relieved to know I would like you to throw swap prefetch and related patches into the bin. Thanks. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lguest re-review
On Wed, 2007-05-09 at 17:50 -0700, Andrew Morton wrote: > On Thu, 10 May 2007 10:24:08 +1000 > Rusty Russell <[EMAIL PROTECTED]> wrote: > > > On Wed, 2007-05-09 at 02:51 -0700, Andrew Morton wrote: > > > Some concern was expressed over the lguest review status, so I shall send > > > the patches out again for people to review, to test, to make observations > > > about the author's personal appearance, etc. > > > > Thanks Andrew, > > > > This means I can finally ack this patch (thanks Eric): > > > > From: [EMAIL PROTECTED] (Eric W. Biederman) > > Subject: [PATCH] Revert "[PATCH] paravirt: Add startup infrastructure for > > paravirtualization" > > > > This reverts commit c9ccf30d77f04064fe5436027ab9d2230c7cdd94. > > I don't get it. Does lguest no longer need this code, or will > it be reintroduced with an lguest merge, or something else? Lguest no longer needs it (the magic signature patch you took). HPA and Eric are brewing a new, shinier way for booting not-a-normal-pc which will address lguest as well as others. But it seems they first need to go through the "who knows most about ancient PCs" slapfight. Thanks! Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-git10/11: files getting truncated on xfs? or maybe an nlink problem?
On Wed, May 09, 2007 at 05:54:09PM -0700, Jeremy Fitzhardinge wrote: > David Chinner wrote: > > Suspend-resume, eh? > > > > There's an immediate suspect. Can you test this specifically for us? > > i.e. download a known good file set, do some stuff, suspend, resume, > > then check the files? If it doesn't show up the first time, can > > you do it a few times just to rule it out? > > Well, I've been doing suspend-resume with xfs for a while without > problems; the problems seem to be recent and easily repeatable. Which > just means that it could be a new suspend-resume problem, of course. Ok. I'm just trying to find a relatively simple test case for the problem - seeing as you seem to be able to reliably reproduce this we should be able to work out the trigger... > > If suspend/resume does cause the problem, can you try again but this > > time please run 'xfs_freeze -f ' on the filesystem before > > suspend, and then 'xfs_freeze -u ' after the resume and see if > > the problem still occurs? > > OK, but I tend to find that xfs_freeze ends up locking up large parts of > the system... (For example, I tried to do the xfs_freeze + lvm snapshot > thing, but the lvm snapshot just blocked on the frozen filesystem until > I unfroze it). Yes, because LVM snapshot freezes the filesystem for you - if you've already frozen the filesystem the snapshot will block until you unfreeze it and then it will freeze it itself to take the snapshot. > But I'll try it out. Hm, is there some script I can > stick it into? No idea. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/1] x86_64 : fix default_do_nmi() missing return after a if ()
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> Index: linux-2.6-lttng/arch/x86_64/kernel/traps.c === --- linux-2.6-lttng.orig/arch/x86_64/kernel/traps.c 2007-05-09 17:29:51.0 -0400 +++ linux-2.6-lttng/arch/x86_64/kernel/traps.c 2007-05-09 17:30:07.0 -0400 @@ -779,6 +779,7 @@ return; if (notify_die(DIE_NMI_POST, "nmi_post", regs, reason, 2, 0) == NOTIFY_STOP) + return; if (!do_nmi_callback(regs,cpu)) unknown_nmi_error(reason, regs); -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/1] Fix default_do_nmi on x86_64 in 2.6.21-mm2
Hi Andrew, I guess it's the expected behavior for default_do_nmi on x86_64 : there is a new case tested in the -mm tree but it lacks the appropriate return. It applies at the end of the 2.6.21-mm2 patch series. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lguest re-review
Andrew Morton <[EMAIL PROTECTED]> writes: > I don't get it. Does lguest no longer need this code, or will > it be reintroduced with an lguest merge, or something else? No longer needed. For the short term lguest has a separate entry point. For the long term 2.6.23 we will rev the boot protocol, so lguest and Xen can work with a bzImage and use our standard set of kernel parameters. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] removes MAX_ARG_PAGES
On Wednesday 09 May 2007 4:48 pm, Andrew Morton wrote: > On Sun, 6 May 2007 01:51:34 -0700 > "Ollie Wild" <[EMAIL PROTECTED]> wrote: > > > A while back, I sent out a preliminary patch > > (http://thread.gmane.org/gmane.linux.ports.hppa/752) to remove the > > MAX_ARG_PAGES limit on command line sizes. Since then, Peter Zijlstra > > and I have fixed a number of bugs and addressed the various > > outstanding issues. > > > > The attached patch incorporates the following changes: > > > > - Fixes a BUG_ON() assertion failure discovered by Ingo Molnar. > > - Adds CONFIG_STACK_GROWSUP (parisc) support. > > - Adds auditing support. > > - Reverts to the old behavior on architectures with no MMU. > > - Fixes broken execution of 64-bit binaries from 32-bit binaries. > > - Adds elf_fdpic support. > > - Fixes cache coherency bugs. > > > > We've tested the following architectures: i386, x86_64, um/i386, > > parisc, and frv. These are representative of the various scenarios > > which this patch addresses, but other architecture teams should try it > > out to make sure there aren't any unexpected gotchas. > > I'll duck this for now, given the couple of problems which people have > reported. Just FYI, a really really quick and dirty way of testing this sort of thing on more architectures and you're likely to physically have? 1) Install QEMU. 2) Grab http://landley.net/code/firmware (releases in the downloads directory, or tarball of most recent repository snapshot is wget "http://landley.net/hg/firmware?ca=tip;type=gz;). 3) Edit "download.sh" to point at the URL of your tarball instead of whatever kernel.org version it's using. (Or add your patch to sources/patches if it applies to the version it's already using. Note that if you set SHA1= blank in download.sh it'll skip the checksum test, so you don't have to recalculate the sha1sum if you don't want to.) 4) Run ./build.sh for the architecture you're interested in. (I suggest armv4l, i686, mipsel, and x86_64. Both sparc and ppc are currently broken for different reasons; I'm working on it.) Wait a longish time for it to finish compiling. :) 5) "cd build; ./run-armv4l.sh" and your shell prompt should now be in qemu running a kernel for the appropriate architecture. (You even have a native version of gcc you can build stuff with, although you may have to "ln -s /tools/lib /lib" to run the results, for reasons Linux From Scratch developers will recognize. :) This won't help you test real hardware (at least hardware qemu doesn't emulate), but for stuff like filesystems or executable file formats, it's handy. :) Email me if something doesn't work... Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch added to -mm tree
Andrew Morton wrote: On Wed, 09 May 2007 12:02:29 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: BTW, we _really_ should be doing RCU properly in slob, because you technically can't noop RCU on UP (even though the current users may be safe...). Patch attached to do that. Does it work? That one booted my desktop (very slowly) but as Matt pointed out, it broke alignment on RCU slabs. The last version I posted should work and has the alignment problem fixed. I can retest and resubmit it to you if you like, I was just waiting on an ack from Matt. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] fallocate() implementation in i86, x86_64 and powerpc
On Wed, May 09, 2007 at 09:31:02PM +0530, Amit K. Arora wrote: > I have the updated patches ready which take care of Andrew's comments. > Will run some tests and post them soon. > > But, before submitting these patches, I think it will be better to finalize > on certain things which might be worth some discussion here: > > 1) Should the file size change when preallocation is done beyond EOF ? >- Andreas and Chris Wedgwood are in favor of not changing the > file size in this case. I also tend to agree with them. Does anyone > has an argument in favor of changing the filesize ? > If not, I will remove the code which changes the filesize, before I > resubmit the concerned ext4 patch. I think there needs to be both. If we don't have a mechanism to atomically change the file size with the preallocation, then applications that use stat() to work out if they need to preallocate more space will end up racing. > 2) For FA_UNALLOCATE mode, should the file system allow unallocation >of normal (non-preallocated) blocks (blocks allocated via >regular write/truncate operations) also (i.e. work as punch()) ? Yes. That is the current XFS implementation for XFS_IOC_UNRESVSP, and what i did for FA_UNALLOCATE as well. >- Though FA_UNALLOCATE mode is yet to be implemented on ext4, still > we need to finalize on the convention here as a general guideline > to all the filesystems that implement fallocate. > > 3) If above is true, the file size will need to be changed >for "unallocation" when block holding the EOF gets unallocated. No - we punch a hole. If you want the filesize to change, then you use ftruncate() to remove the blocks at EOF and change the file size atomically. > 4) Should we update mtime & ctime on a successfull allocation/ >unallocation ? >- David Chinner raised this question in following post: > http://lkml.org/lkml/2007/4/29/407 > I think it makes sense to update the [mc]time for a successfull > preallocation/unallocation. Does anyone feel otherwise ? > It will be interesting to know how XFS behaves currently. Does XFS > update [mc]time for preallocation ? No, XFS does *not* update a/m/ctime on prealloc/punch unless the file size changes. If the filesize changes, it behaves exactly the same way that ftruncate() behaves. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-git10/11: files getting truncated on xfs? or maybe an nlink problem?
David Chinner wrote: > Suspend-resume, eh? > > There's an immediate suspect. Can you test this specifically for us? > i.e. download a known good file set, do some stuff, suspend, resume, > then check the files? If it doesn't show up the first time, can > you do it a few times just to rule it out? > Well, I've been doing suspend-resume with xfs for a while without problems; the problems seem to be recent and easily repeatable. Which just means that it could be a new suspend-resume problem, of course. > If suspend/resume does cause the problem, can you try again but this > time please run 'xfs_freeze -f ' on the filesystem before > suspend, and then 'xfs_freeze -u ' after the resume and see if > the problem still occurs? OK, but I tend to find that xfs_freeze ends up locking up large parts of the system... (For example, I tried to do the xfs_freeze + lvm snapshot thing, but the lvm snapshot just blocked on the frozen filesystem until I unfroze it). But I'll try it out. Hm, is there some script I can stick it into? J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
On 5/9/07, Gerd Hoffmann <[EMAIL PROTECTED]> wrote: Refine SCREEN_INFO sanity check for vgacon initialization. Checking video mode field only to see whenever SCREEN_INFO is initialized is not enougth, in some cases it is zero although a vga card is present. Lets additionally check cols and lines. Signed-off-by: Gerd Hoffmann <[EMAIL PROTECTED]> Cc: Rusty Russell <[EMAIL PROTECTED]> Cc: Andi Kleen <[EMAIL PROTECTED]> Cc: Alan <[EMAIL PROTECTED]> Cc: Ingo Molnar <[EMAIL PROTECTED]> Cc: Eric W. Biederman <[EMAIL PROTECTED]> --- drivers/video/console/vgacon.c |9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) Index: vanilla-2.6.21-git11/drivers/video/console/vgacon.c === --- vanilla-2.6.21-git11.orig/drivers/video/console/vgacon.c +++ vanilla-2.6.21-git11/drivers/video/console/vgacon.c @@ -368,9 +368,14 @@ static const char *vgacon_startup(void) #endif } + /* SCREEN_INFO initialized? */ + if ((ORIG_VIDEO_MODE == 0) && + (ORIG_VIDEO_LINES == 0) && + (ORIG_VIDEO_COLS == 0)) + goto no_vga; + /* VGA16 modes are not handled by VGACON */ - if ((ORIG_VIDEO_MODE == 0x00) ||/* SCREEN_INFO not initialized */ - (ORIG_VIDEO_MODE == 0x0D) ||/* 320x200/4 */ + if ((ORIG_VIDEO_MODE == 0x0D) ||/* 320x200/4 */ (ORIG_VIDEO_MODE == 0x0E) ||/* 640x200/4 */ (ORIG_VIDEO_MODE == 0x10) ||/* 640x350/4 */ (ORIG_VIDEO_MODE == 0x12) ||/* 640x480/4 */ it works. YH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patches] [PATCH] [21/22] x86_64: Extend bzImage protocol for relocatable bzImage
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Obviously not, but it was more of a comment on the apparent assumption > that doing so would be simple. Reasonable comment then. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lguest re-review
On Thu, 10 May 2007 10:24:08 +1000 Rusty Russell <[EMAIL PROTECTED]> wrote: > On Wed, 2007-05-09 at 02:51 -0700, Andrew Morton wrote: > > Some concern was expressed over the lguest review status, so I shall send > > the patches out again for people to review, to test, to make observations > > about the author's personal appearance, etc. > > Thanks Andrew, > > This means I can finally ack this patch (thanks Eric): > > From: [EMAIL PROTECTED] (Eric W. Biederman) > Subject: [PATCH] Revert "[PATCH] paravirt: Add startup infrastructure for > paravirtualization" > > This reverts commit c9ccf30d77f04064fe5436027ab9d2230c7cdd94. I don't get it. Does lguest no longer need this code, or will it be reintroduced with an lguest merge, or something else? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-git10/11: files getting truncated on xfs? or maybe an nlink problem?
On Wed, May 09, 2007 at 05:04:36PM -0700, Jeremy Fitzhardinge wrote: > David Chinner wrote: > > Seems very unlikely. Have you unmounted and mounted the filesystem > > (or rebooted or suspended) between the files being seen good and > > the files being seen bad? > > > > There was definitely a suspend-resume, and maybe a reboot. I'll try > again later on. Suspend-resume, eh? There's an immediate suspect. Can you test this specifically for us? i.e. download a known good file set, do some stuff, suspend, resume, then check the files? If it doesn't show up the first time, can you do it a few times just to rule it out? If suspend/resume does cause the problem, can you try again but this time please run 'xfs_freeze -f ' on the filesystem before suspend, and then 'xfs_freeze -u ' after the resume and see if the problem still occurs? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ACPI: fix oops after dock driver fails to initialize
On Tue, 08 May 2007 18:39:55 -0400
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
You didn't write much.
Oh, it was an attachment. thwap.
> ACPI: fix oops after dock driver fails to initialize
>
> The driver tests the dock_station pointer for nonnull
> to check whether it has initialized properly. But in
> some cases dock_station will be non-null after being
> freed when driver init fails. Fix by zeroing the
> pointer after freeing.
>
> Signed-off-by: Chuck Ebbert <[EMAIL PROTECTED]>
>
> ---
> drivers/acpi/dock.c |6 ++
> 1 file changed, 6 insertions(+)
>
> --- 2.6.21-d390.orig/drivers/acpi/dock.c
> +++ 2.6.21-d390/drivers/acpi/dock.c
> @@ -698,6 +698,7 @@ static int dock_add(acpi_handle handle)
> if (ret) {
> printk(KERN_ERR PREFIX "Error %d registering dock device\n",
> ret);
> kfree(dock_station);
> + dock_station = NULL;
> return ret;
> }
> ret = device_create_file(_device.dev, _attr_docked);
> @@ -705,6 +706,7 @@ static int dock_add(acpi_handle handle)
> printk("Error %d adding sysfs file\n", ret);
> platform_device_unregister(_device);
> kfree(dock_station);
> + dock_station = NULL;
> return ret;
> }
> ret = device_create_file(_device.dev, _attr_undock);
> @@ -713,6 +715,7 @@ static int dock_add(acpi_handle handle)
> device_remove_file(_device.dev, _attr_docked);
> platform_device_unregister(_device);
> kfree(dock_station);
> + dock_station = NULL;
> return ret;
> }
>
> @@ -725,6 +728,7 @@ static int dock_add(acpi_handle handle)
> dd = alloc_dock_dependent_device(handle);
> if (!dd) {
> kfree(dock_station);
> + dock_station = NULL;
> ret = -ENOMEM;
> goto dock_add_err_unregister;
> }
> @@ -752,6 +756,7 @@ dock_add_err_unregister:
> device_remove_file(_device.dev, _attr_undock);
> platform_device_unregister(_device);
> kfree(dock_station);
> + dock_station = NULL;
> return ret;
> }
>
> @@ -785,6 +790,7 @@ static int dock_remove(void)
>
> /* free dock station memory */
> kfree(dock_station);
> + dock_station = NULL;
> return 0;
> }
>
I think you're missing a case, here:
ret = device_create_file(_device.dev, _attr_uid);
if (ret) {
printk("Error %d adding sysfs file\n", ret);
platform_device_unregister(_device);
kfree(dock_station);
return ret;
}
also, the code duplication in there is unpleasing. Doesn't this look
better?
drivers/acpi/dock.c | 26 --
1 files changed, 12 insertions(+), 14 deletions(-)
diff -puN
drivers/acpi/dock.c~acpi-fix-oops-after-dock-driver-fails-to-initialize
drivers/acpi/dock.c
--- a/drivers/acpi/dock.c~acpi-fix-oops-after-dock-driver-fails-to-initialize
+++ a/drivers/acpi/dock.c
@@ -714,31 +714,24 @@ static int dock_add(acpi_handle handle)
dock_device.name = dock_device_name;
ret = platform_device_register(_device);
if (ret) {
- printk(KERN_ERR PREFIX "Error %d registering dock device\n",
ret);
- kfree(dock_station);
- return ret;
+ printk(KERN_ERR PREFIX "Error %d registering dock device\n",
+ ret);
+ goto err;
}
ret = device_create_file(_device.dev, _attr_docked);
if (ret) {
printk("Error %d adding sysfs file\n", ret);
- platform_device_unregister(_device);
- kfree(dock_station);
- return ret;
+ goto err_register;
}
ret = device_create_file(_device.dev, _attr_undock);
if (ret) {
printk("Error %d adding sysfs file\n", ret);
- device_remove_file(_device.dev, _attr_docked);
- platform_device_unregister(_device);
- kfree(dock_station);
- return ret;
+ goto err_sysfs_1;
}
ret = device_create_file(_device.dev, _attr_uid);
if (ret) {
printk("Error %d adding sysfs file\n", ret);
- platform_device_unregister(_device);
- kfree(dock_station);
- return ret;
+ goto err_sysfs_2;
}
/* Find dependent devices */
@@ -749,7 +742,6 @@ static int dock_add(acpi_handle handle)
/* add the dock station as a device dependent on itself */
dd = alloc_dock_dependent_device(handle);
if (!dd) {
- kfree(dock_station);
ret = -ENOMEM;
goto dock_add_err_unregister;
}
@@ -773,10 +765,15 @@ static int dock_add(acpi_handle handle)
dock_add_err:
kfree(dd);
dock_add_err_unregister:
+err_sysfs_2:
Re: + fix-spellings-of-slab-allocator-section-in-init-kconfig.patch added to -mm tree
On Wed, 09 May 2007 12:02:29 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote: > BTW, we _really_ should be doing RCU properly in slob, because you > technically can't noop RCU on UP (even though the current users may be > safe...). > > Patch attached to do that. Does it work? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git patches] libata fixes, minor updates
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
Documentation/kernel-parameters.txt |8 ---
drivers/ata/libata-acpi.c |3 +-
drivers/ata/libata-core.c |2 +
drivers/ata/pata_pcmcia.c |1 +
drivers/ata/pata_qdi.c |2 +-
drivers/ata/pata_scc.c |4 +-
drivers/ata/sata_nv.c | 92 +-
drivers/ata/sata_promise.c | 24 --
drivers/ata/sata_via.c |8 +++
9 files changed, 113 insertions(+), 31 deletions(-)
Alexey Dobriyan (1):
pata_scc: fix compilation
Jesse Barnes (1):
Doc Fix: remove mention of combined mode-related kernel parameters
Mikael Pettersson (2):
sata_promise: fix another error decode regression
sata_promise: SATAII-150/300 TX4 port numbering fix
Randy Dunlap (1):
libata: fix kernel-doc parameters
Richard Kennedy (1):
pata_pcmcia.c: add card ident for jvc cdrom
Robert Hancock (1):
sata_nv: fix ADMA freeze/thaw/irq_clear issues
Samuel Thibault (1):
Fix pata_qdi.c probe code
Tejun Heo (2):
libata-acpi: fix _GTF command protocol for ATAPI devices
sata_via: add missing PM hooks
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 6b8ad06..09220a1 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -754,14 +754,6 @@ and is between 256 and 4096 characters. It is defined in
the file
inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver
Format:
- combined_mode= [HW] control which driver uses IDE ports in combined
- mode: legacy IDE driver, libata, or both
- (in the libata case, libata.atapi_enabled=1 may be
- useful as well). Note that using the ide or libata
- options may affect your device naming (e.g. by
- changing hdc to sdb).
- Format: combined (default), ide, or libata
-
inttest=[IA64]
io7=[HW] IO7 for Marvel based alpha systems
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 03a0acf..cb3eab6 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -489,8 +489,7 @@ static void taskfile_load_raw(struct ata_port *ap,
/* convert gtf to tf */
tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE; /* TBD */
- tf.protocol = atadev->class == ATA_DEV_ATAPI ?
- ATA_PROT_ATAPI_NODATA : ATA_PROT_NODATA;
+ tf.protocol = ATA_PROT_NODATA;
tf.feature = gtf->tfa[0]; /* 0x1f1 */
tf.nsect = gtf->tfa[1]; /* 0x1f2 */
tf.lbal= gtf->tfa[2]; /* 0x1f3 */
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index fef87dd..4595d1f 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -895,6 +895,7 @@ static u64 ata_read_native_max_address(struct ata_device
*dev)
/**
* ata_set_native_max_address_ext - LBA48 native max set
* @dev: Device to query
+ * @new_sectors: new max sectors value to set for the device
*
* Perform an LBA48 size set max upon the device in question. Return the
* actual LBA48 size or zero if the command fails.
@@ -932,6 +933,7 @@ static u64 ata_set_native_max_address_ext(struct ata_device
*dev, u64 new_sector
/**
* ata_set_native_max_address - LBA28 native max set
* @dev: Device to query
+ * @new_sectors: new max sectors value to set for the device
*
* Perform an LBA28 size set max upon the device in question. Return the
* actual LBA28 size or zero if the command fails.
diff --git a/drivers/ata/pata_pcmcia.c b/drivers/ata/pata_pcmcia.c
index 75dc847..11245e3 100644
--- a/drivers/ata/pata_pcmcia.c
+++ b/drivers/ata/pata_pcmcia.c
@@ -357,6 +357,7 @@ static struct pcmcia_device_id pcmcia_devices[] = {
PCMCIA_DEVICE_MANF_CARD(0x000a, 0x),/* I-O Data CFA */
PCMCIA_DEVICE_MANF_CARD(0x001c, 0x0001),/* Mitsubishi CFA */
PCMCIA_DEVICE_MANF_CARD(0x0032, 0x0704),
+ PCMCIA_DEVICE_MANF_CARD(0x0032, 0x2904),
PCMCIA_DEVICE_MANF_CARD(0x0045, 0x0401),/* SanDisk CFA */
PCMCIA_DEVICE_MANF_CARD(0x0098, 0x),/* Toshiba */
PCMCIA_DEVICE_MANF_CARD(0x00a4, 0x002d),
diff --git a/drivers/ata/pata_qdi.c b/drivers/ata/pata_qdi.c
index 27685ce..fb8c9e1 100644
--- a/drivers/ata/pata_qdi.c
+++ b/drivers/ata/pata_qdi.c
@@ -375,7 +375,7 @@ static __init int qdi_init(void)
res = inb(port + 3);
if (res & 1) {
/* Single channel mode */
-
Please revert 5b479c91da90eef605f851508744bfe8269591a0 (md partition rescan)
Hi Linus, Could you please revert 5b479c91da90eef605f851508744bfe8269591a0 It causes an oops when auto-detecting raid arrays, and it doesn't seem easy to fix. The array may not be 'open' when do_md_run is called, so bdev->bd_disk might be NULL, so bd_set_size can oops. I cannot really open the array (blkdev_get) at this point as I deadlock on mddev->reconfig_mutex. I could simply guard against bdev->bd_disk being NULL, but that is too ugly as sometimes the partitions would be found, and sometimes not. This whole approach of opening an md device before it has been assembled just seems to get more and more painful. I think I'm going to have to come up with something clever to provide both backward comparability with usage expectation, and sane integration into the rest of the kernel. Maybe if you open before the array is assembled you get a completely different bdev somehow, and on array assembly, a new bdev, or gendisk or something, gets swapped in so the next open finds it Anyway, if that patch can go I'd appreciate it. Thanks, NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PCMCIA on ppc64, and the joys of io port ranges on mmio-only platforms
Hi, We've got a very simple CF interface on our eval board, sitting on localbus with a couple of gpios for control. mem and i/o port ranges are mapped to two mmio ranges, i.e. 0xf000 and 0xf100 in our case. I've got a pcmcia driver for the slot to handle all the probing, etc. It ioremaps both the mem and io ranges, and provides that with the registered device: cf->mem_base = ioremap(mem->start, mem->end - mem->start); cf->io_base = ioremap(io->start, io->end - io->start); [...] /* pcmcia layer only remaps "real" memory not iospace */ cf->socket.io_offset = (unsigned long)cf->io_base; /* reserve chip-select regions */ if (!request_mem_region(mem->start, mem->end + 1 - mem->start, [...] if (!request_mem_region(io->start, io->end + 1 - io->start, driver_name)) [...] cf->socket.dev.parent = >dev; cf->socket.ops = _cf_ops; cf->socket.resource_ops = _static_ops; cf->socket.features = SS_CAP_PCCARD | SS_CAP_STATIC_MAP | SS_CAP_MEM_ALIGN; [...] (I'll post the full driver separately, but wanted to bring this up first). Bottom line is that io_offset points to the ioremap()ed memory, i.e a 64-bit kernel address. The problems show up further up the stack, in this case in the pata_pcmcia driver, where pcmcia_request_io() is used to handle the address allocation. That in turn calls alloc_io_space(), which takes an ioaddr_t * as argument and does math on it. ioaddr_t is 32-bit, causing obvious problems since io_offset is 64-bit. There's a compatible kio_addr_t available, but I'm guessing it's already not used because of ABI requiremenets given the big warning at the definition of ioaddr_t. Since ppc64 never has had pcmcia before (We're the first platform with it), changing the type under ifdef like mips/arm shouldn't be a problem, at least it won't lead to regressions -- there's no previous user apps to regress. However, that's not enough in this case: Next thing that will fail is ioport_map() in ppc-specific code, called from devm_ioport_map(). It currently assumes to be passed the bus-local port number and adding it to the ioremap base of the (normally only) bus with I/O ports, i.e. ISA/LPC. Since we already use that for other devices (UARTS, etc), we now have more than one base register. I see two ways to solve this: 1. Create infrastructure to track the various io-port ranges, register them and let the infrastructure take care of the ioremap, pick the right ioport_map(), etc. I.e. create virtual io port ranges. 2. Make ioport_map() detect already mapped arguments (i.e.: + if (port >= IMALLOC_BASE && (port+len) < IMALLOC_END) + return (void __iomem *)port; (1) would be appealing if it was the only change needed, and if that meant that I didn't have to change ioaddr_t. It doesn't though, since the pcmcia code still stores the ioport_map():ed value in an ioaddr_t, so it really just adds complexity without that much benefit. I'm tempted to go with (2) + type change but if someone has a third option I'm all ears. -Olof - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lguest re-review
On Wed, 2007-05-09 at 02:51 -0700, Andrew Morton wrote:
> Some concern was expressed over the lguest review status, so I shall send
> the patches out again for people to review, to test, to make observations
> about the author's personal appearance, etc.
Thanks Andrew,
This means I can finally ack this patch (thanks Eric):
From: [EMAIL PROTECTED] (Eric W. Biederman)
Subject: [PATCH] Revert "[PATCH] paravirt: Add startup infrastructure for
paravirtualization"
This reverts commit c9ccf30d77f04064fe5436027ab9d2230c7cdd94.
Entering the kernel at startup_32 without passing our real mode data
in %esi, and without guaranteeing that physical and virtual addresses
are identity mapped makes head.S impossible to maintain.
The only user of this infrastructure is lguest which is not merged so
nothing we currently support will break by removing this over designed
nightmare, and only the pending lguest patches will be affected. The
pending Xen patches have a different entry point that they use.
We are currently discussing what Xen and lguest need to do to boot the
kernel in a more normal fashion so using startup_32 in this weird
manner is clearly not their long term direction.
So let's remove this code in head.S before it causes brain damage to
people trying to maintain head.S
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Chris Wright <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Zachary Amsden <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
CC: H. Peter Anvin <[EMAIL PROTECTED]>
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>
---
arch/i386/kernel/head.S| 38 --
arch/i386/kernel/paravirt.c|1 -
arch/i386/kernel/vmlinux.lds.S |6 --
include/asm-i386/paravirt.h|5 -
4 files changed, 50 deletions(-)
===
--- a/arch/i386/kernel/head.S
+++ b/arch/i386/kernel/head.S
@@ -70,12 +70,6 @@ INIT_MAP_BEYOND_END = BOOTBITMAP_SIZE +
*/
.section .text.head,"ax",@progbits
ENTRY(startup_32)
-
-#ifdef CONFIG_PARAVIRT
-movl %cs, %eax
-testl $0x3, %eax
-jnz startup_paravirt
-#endif
/*
* Set segments to known values.
@@ -501,38 +495,6 @@ ignore_int:
iret
.section .text
-#ifdef CONFIG_PARAVIRT
-startup_paravirt:
- cld
- movl $(init_thread_union+THREAD_SIZE),%esp
-
- /* We take pains to preserve all the regs. */
- pushl %edx
- pushl %ecx
- pushl %eax
-
- pushl $__start_paravirtprobe
-1:
- movl0(%esp), %eax
- cmpl$__stop_paravirtprobe, %eax
- je unhandled_paravirt
- pushl (%eax)
- movl8(%esp), %eax
- call*(%esp)
- popl%eax
-
- movl4(%esp), %eax
- movl8(%esp), %ecx
- movl12(%esp), %edx
-
- addl$4, (%esp)
- jmp 1b
-
-unhandled_paravirt:
- /* Nothing wanted us: we're screwed. */
- ud2
-#endif
-
/*
* Real beginning of normal "text" segment
*/
===
--- a/arch/i386/kernel/paravirt.c
+++ b/arch/i386/kernel/paravirt.c
@@ -19,7 +19,6 @@
#include
#include
#include
-#include
#include
#include
===
--- a/arch/i386/kernel/vmlinux.lds.S
+++ b/arch/i386/kernel/vmlinux.lds.S
@@ -80,12 +80,6 @@ SECTIONS
EXTRA_RWDATA
CONSTRUCTORS
} :data
-
- .paravirtprobe : AT(ADDR(.paravirtprobe) - LOAD_OFFSET) {
- __start_paravirtprobe = .;
- *(.paravirtprobe)
- __stop_paravirtprobe = .;
- }
. = ALIGN(4096);
.data_nosave : AT(ADDR(.data_nosave) - LOAD_OFFSET) {
===
--- a/include/asm-i386/paravirt.h
+++ b/include/asm-i386/paravirt.h
@@ -221,11 +221,6 @@ struct paravirt_ops
void (*irq_enable_sysexit)(void);
void (*iret)(void);
};
-
-/* Mark a paravirt probe function. */
-#define paravirt_probe(fn) \
- static asmlinkage void (*__paravirtprobe_##fn)(void) __attribute_used__ \
- __attribute__((__section__(".paravirtprobe"))) = fn
extern struct paravirt_ops paravirt_ops;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-git11: BUG in loop.ko
Andrew Morton wrote: > On Wed, 09 May 2007 16:52:41 -0700 > Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > > >> Seems to be getting a 0 refcount. I don't see anything in the recent >> changes which might cause this, but this is relatively new behaviour. >> It was working for me in the 2.6.21-pre time period, but I haven't tried >> this since 2.6.21 was released. >> >> The BUG is actually triggered by the __module_get(THIS_MODULE) in >> loop_set_fd. >> >> J >> >> loop: module loaded >> device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [EMAIL >> PROTECTED] >> [ cut here ] >> kernel BUG at /home/jeremy/hg/xen/paravirt/linux/include/linux/module.h:396! >> invalid opcode: [#1] >> PREEMPT SMP >> Modules linked in: dm_snapshot dm_mod loop >> CPU:1 >> EIP:0061:[]Not tainted VLI >> EFLAGS: 00010246 (2.6.21-paravirt #1339) >> EIP is at lo_ioctl+0x65/0xa52 [loop] >> eax: ebx: cfb92c98 ecx: d085e480 edx: 0200 >> esi: 4c00 edi: cf8ad428 ebp: cf37fdc0 esp: cf37fbf8 >> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0069 >> Process losetup (pid: 440, ti=cf37e000 task=cf30b4d0 task.ti=cf37e000) >> Stack: c1390080 c1390080 cf37fc10 0008 cf8ad428 cfbb2258 >> cf37fc34 >>c01458c5 cfb92c98 c1392a40 cf30ba70 cf30b4d0 cf30ba54 0002 >> cf30ba70 >>cf30b4d0 cf30ba54 0002 0003 c134c088 c134c088 cf37fc90 >> c01215b8 >> Call Trace: >> [] show_trace_log_lvl+0x1a/0x30 >> [] show_stack_log_lvl+0x9d/0xa5 >> [] show_registers+0x1f7/0x336 >> [] die+0x119/0x21b >> [] do_trap+0x8a/0xa4 >> [] do_invalid_op+0x88/0x92 >> [] error_code+0x72/0x78 >> [] blkdev_driver_ioctl+0x4c/0x5d >> [] blkdev_ioctl+0x754/0x7a2 >> [] block_ioctl+0x1b/0x1f >> [] do_ioctl+0x22/0x68 >> [] vfs_ioctl+0x232/0x245 >> [] sys_ioctl+0x49/0x63 >> [] syscall_call+0x7/0xb >> === >> Code: ff 83 f8 06 0f 87 5a 09 00 00 ff 24 85 5c bc 85 d0 8b 9b cc 01 00 00 >> b8 80 e4 85 d0 89 9d 5c fe ff ff e8 37 0a 8f ef 85 c0 75 04 <0f> 0b eb fe b8 >> 01 00 00 00 e8 79 9f 8c ef e8 ec 4b 9c ef c1 e0 >> EIP: [] lo_ioctl+0x65/0xa52 [loop] SS:ESP 0069:cf37fbf8 >> >> > > A few people have been playing with module refcounting lately. Did you > work out a reproduce-it recipe? > 100% reliable, but a bit obscure. I'm booting an FC6 livecd with a paravirt_ops kernel under Xen. The relevant part of the iso's initrd script is: + mknod /dev/loop118 b 7 118 + mknod /dev/loop119 b 7 119 + mknod /dev/loop120 b 7 120 + mknod /dev/loop121 b 7 121 + mkdir -p /dev/mapper + mknod /dev/mapper/control c 10 63 + modprobe loop max_loop=128 loop: the max_loop option is obsolete and will be removed in March 2008 loop: module loaded + modprobe dm_snapshot device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [EMAIL PROTECTED] + '[' 0 == 1 ']' + losetup /dev/loop120 /sysroot/squashfs.img [ cut here ] kernel BUG at /home/jeremy/hg/xen/paravirt/linux/include/linux/module.h:396! invalid opcode: [#1] PREEMPT SMP Modules linked in: dm_snapshot dm_mod loop CPU:0 EIP:0061:[]Not tainted VLI EFLAGS: 00010246 (2.6.21-paravirt #1339) [...] J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git patches] libata updates
Jesse Barnes wrote: On Sunday, April 29, 2007 9:15 am Jeff Garzik wrote: Noteworthy changes: * remove combined mode PCI quirk. IDE driver selection (libata or old-IDE) is now determined purely by module load order. * new driver API, that is far more like other kernel APIs: alloc...register...unregister...free. * More Alan PATA work * Lots of other little bits. drivers/pci/quirks.c| 113 Looks like you removed the combined_mode quirk (yay!) but didn't update kernel-parameters.txt... might confuse people. Here's a patch to remove mention of it from the documentation. Signed-off-by: Jesse Barnes <[EMAIL PROTECTED]> Thanks, Jesse diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 84c3bd0..49b1ea3 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -722,14 +722,6 @@ and is between 256 and 4096 characters. It is defined in the file inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver Format: - combined_mode= [HW] control which driver uses IDE ports in combined - mode: legacy IDE driver, libata, or both - (in the libata case, libata.atapi_enabled=1 may be - useful as well). Note that using the ide or libata - options may affect your device naming (e.g. by - changing hdc to sdb). - Format: combined (default), ide, or libata - applied - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sata_nv: fix ADMA freeze/thaw/irq_clear issues
Robert Hancock wrote: This patch fixes some problems with ADMA-capable controllers with regard to freeze, thaw and irq_clear libata callbacks. Freeze and thaw didn't switch the ADMA-specific interrupts on or off, and more critically the irq_clear function didn't respect the restriction that the notifier clear registers for both ports have to be written at the same time even when only one port is being cleared. This could result in timeouts on one port when error handling (i.e. as a result of hotplug) occurred on the other port. As well, this fixes some issues in the interrupt handler: we shouldn't check any ADMA status if the port has ADMA switched off because of an ATAPI device, and it also checks to see if any ADMA interrupt has been raised even when we are in port-register mode. Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> applied please properly word-wrap your patch descriptions in the future - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/9] lguest: the asm offsets
On Wed, 2007-05-09 at 22:46 +0200, Sam Ravnborg wrote: > On Wed, May 09, 2007 at 02:51:36AM -0700, [EMAIL PROTECTED] wrote: > > From: Rusty Russell <[EMAIL PROTECTED]> > > > > This is the structure offsets required by lg.ko's switcher.S. > > > > Unfortunately we don't have infrastructure for private asm-offsets > > creation. > Someone maybe it was Oleg? did an OK job to abstract out asm-offset > generation. I asked to have it rebased but never heard anything back. > > I would like to get this generic approach in and then let lguest use it. > But I do not see this as a reason to hold back inclusion in -linus. Hi Sam, Yeah, I never heard back either. And I'm reluctant to try to fix it myself: I've never managed to patch the build system without causing you to rewrite it better 8) > But could we please get rid of the "../../../" in the include Sure: but how? It's a private internal include for the lg.ko module. Thanks! Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] time locale in gen_initramfs_list.sh
On Tue, 8 May 2007 07:55:26 +0200
Florian Fainelli <[EMAIL PROTECTED]> wrote:
> I noticed that some zsh users who forced their ls formatting to something non
> standard could not generate the initramfs file list. Forcing the locale to C
> while generating seems not to be enough. Adding --time-style=locale will use
> C locale ls output and will let them generate the initramfs list. It has no
> side effects for other users.
>
> Signed-off-by: Florian Fainelli <[EMAIL PROTECTED]>
> --
>
>
> [time_locale.patch text/plain (761B)]
> diff --git a/scripts/gen_initramfs_list.sh b/scripts/gen_initramfs_list.sh
> index 683eb12..1f96b9b 100644
> --- a/scripts/gen_initramfs_list.sh
> +++ b/scripts/gen_initramfs_list.sh
> @@ -125,7 +125,7 @@ parse() {
> str="${ftype} ${name} ${location} ${str}"
> ;;
> "nod")
> - local dev=`LC_ALL=C ls -l "${location}"`
> + local dev=`LC_ALL=C ls --time-style=locale -l
> "${location}"`
> local maj=`field 5 ${dev}`
> local min=`field 6 ${dev}`
> maj=${maj%,}
> @@ -135,7 +135,7 @@ parse() {
> str="${ftype} ${name} ${str} ${dev} ${maj} ${min}"
> ;;
> "slink")
> - local target=`field 11 $(LC_ALL=C ls -l "${location}")`
> + local target=`field 11 $(LC_ALL=C ls
> --time-style=locale -l "${location}")`
> str="${ftype} ${name} ${target} ${str}"
> ;;
hm, --time-style sounds rather gnu-specific and perhaps we'd rather not
add that requirement. Or perhaps we already require gnu ls, dunno.
I'll dump the problem in Sam's lap ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [bisect] NFS regression breaks X
On Wed, 2007-05-09 at 15:52 -0700, Andrew Morton wrote: > It's a bit rough that Jeff spent a large amount of time hunting down an > already-known bug. That's normally my job :( The bug was reported by Florin Iucha (on lkml!) on Saturday. It has only just been debugged, and I was in fact in the middle of marshalling the fixes. > This five-week-old diff only ever appeared in 2.6.21-mm1, which was > released four days ago. It was then whizzed into mainline. We thus lost > five weeks public testing which would probably have saved Jeff his pain. > > What went wrong? Probably my fault. I've had a couple of weeks of heavy travel due to various circumstances that were beyond my control, and so I had little time in which to test the stuff and push it out. Another factor that is affecting us is the slow but gradual collapse of the OSDL NFSv4 regression testing effort. Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: fallback to the other IDENTIFY on device error
Tejun Heo wrote:
It seems the world isn't as frank as we thought and some devices lie
about who they are. Fallback to the other IDENTIFY if IDENTIFY fails
with device error. As this is the strategy used by IDE for a long
time, it shouldn't cause too much problem.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: William Thompson <[EMAIL PROTECTED]>
---
Willam, please verify this fixes your problem. Jeff, after all, we
seem to need this. :-(
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index ca67484..f543109 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1652,7 +1652,7 @@ int ata_dev_read_id(struct ata_device *d
struct ata_taskfile tf;
unsigned int err_mask = 0;
const char *reason;
- int tried_spinup = 0;
+ int may_fallback = 1, tried_spinup = 0;
int rc;
if (ata_msg_ctl(ap))
@@ -1696,11 +1696,30 @@ int ata_dev_read_id(struct ata_device *d
return -ENOENT;
}
+ if (may_fallback && (err_mask == AC_ERR_DEV)) {
+ may_fallback = 0;
+
+ /* Device or controller might have reported
+* the wrong device class. Give a shot at then
+* other IDENTIFY
+*/
+ if (class == ATA_DEV_ATA)
+ class = ATA_DEV_ATAPI;
+ else
+ class = ATA_DEV_ATA;
The error handling should be more specific -- check and make sure the
error is 'command aborted'
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-git10/11: files getting truncated on xfs? or maybe an nlink problem?
David Chinner wrote: > Seems very unlikely. Have you unmounted and mounted the filesystem > (or rebooted or suspended) between the files being seen good and > the files being seen bad? > There was definitely a suspend-resume, and maybe a reboot. I'll try again later on. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
