I'm testing unionfs on top of nfsv2/3/4, using 2.6.24 as of linus's commit
4fa4d23fa20de67df919030c1216295664866ad7. A lot of my unionfs regression
tests are failing on nfs2, b/c files that should be deleted, aren't. It
feels like there may be a ref leak that prevents the files from being
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 19 Oct 2007 13:36:24 +0800
> [NET]: Fix possible dev_deactivate race condition
>
> The function dev_deactivate is supposed to only return when
> all outstanding transmissions have completed. Unfortunately
> it is possible for store operations in
On Fri, Oct 19, 2007 at 12:27:16PM +0930, David Newall wrote:
> >Learn to read. Linux has never allowed that. Most of the Unix systems
> >do not allow that.
>
> I did read the claim and it is ambiguous, in that it can reasonably be
> read to mean that most UNIX systems never allowed such
On Fri, Oct 19, 2007 at 12:20:25PM +0800, Herbert Xu wrote:
>
> In fact this bug exists elsewhere too. For example, the network
> stack does this in net/sched/sch_generic.c:
>
> /* Wait for outstanding qdisc_run calls. */
> while (test_bit(__LINK_STATE_QDISC_RUNNING, >state))
>
On Thu, 18 Oct 2007 22:20:17 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Fri, 19 Oct 2007 15:04:31 +1000 Stephen Rothwell wrote:
>
> > At least for now.
>
> Please explain "why" in the changelog (what changelog?).
>
> E.g.:
> so that make allmodconfig on powerpc will have a better
Reduce the function pointer mess of the m68knommu timer code.
Call direct to the local hardware's timer setup, and expose the local
common timer interrupt handler to the lower level hardware timer.
Ultimately this will save definitions of all these functions across
all the platform code to setup
On Fri, 19 Oct 2007 15:04:31 +1000 Stephen Rothwell wrote:
> At least for now.
Please explain "why" in the changelog (what changelog?).
E.g.:
so that make allmodconfig on powerpc will have a better chance
of building.
or whatever.
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
> ---
>
Ulrich Drepper wrote:
I agree. Applications shouldn't be expected to be yet more complicated
and have different levels of low memory handling. You might want to
give a process a second shot at handling SIGDANGER but after that's it's
all about preparation for a shutdown.
I disagree. From
I missed an obvious one!
x86 CPUs are defined not to reorder stores past earlier loads, so there is
no hardware memory barrier required to implement a release-consistent store
(all stores are, by definition).
So ditch the generic lock bitops, and implement optimised versions for x86,
which
From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Fri, 19 Oct 2007 15:04:31 +1000
> At least for now.
>
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hi Nathan,
> Gautham R Shenoy wrote:
> > On Thu, Oct 18, 2007 at 03:22:21AM -0500, Nathan Lynch wrote:
> > > Gautham R Shenoy wrote:
> > > > Hi Nathan,
> > > > > Hi Gautham-
> > > > >
> > > > > Gautham R Shenoy wrote:
> > > > > > Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel
At least for now.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/scsi/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index
In the debug code of the hidp_queue_report function, the "device" variable does
not exist, replace it with "session->hid"
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
net/bluetooth/hidp/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -upr
On Fri, 2007-10-19 at 12:48 +0800, Herbert Xu wrote:
> [IRQ]: Fix synchronize_irq races with IRQ handler
>
> As it is some callers of synchronize_irq rely on memory barriers
> to provide synchronisation against the IRQ handlers. For example,
> the tg3 driver does
>
> tp->irq_sync = 1;
>
From: Olof Johansson <[EMAIL PROTECTED]>
Date: Thu, 18 Oct 2007 21:29:47 -0500
> So, looks like rcu_dereference() returned NULL. I don't know the
> filter code at all, but it seems like it might be a valid case?
> sk_detach_filter() seems to handle a NULL sk_filter, at least.
>
>
> So, this
From: Matt Waddel <[EMAIL PROTECTED]>
Fix the system call code for handling syscall tracing, so strace
and gdbserver work properly.
This fix originally developed by Philippe De Muyter and Stuart Hughes.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp
On Friday 19 October 2007 13:28, Herbert Xu wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> >> First of all let's agree on some basic assumptions:
> >>
> >> * A pair of spin lock/unlock subsumes the effect of a full mb.
> >
> > Not unless you mean a pair of spin lock/unlock as in
> > 2 spin
On Fri, Oct 19, 2007 at 12:20:25PM +0800, Herbert Xu wrote:
>
> That's why I think this patch is in fact the only one that
> solves all the races in this thread. The case that it solves
> which the lock/unlock patch does not is the one where action
> flows downwards past the clearing of
From: Erez Zadok <[EMAIL PROTECTED]>
Date: Fri, 19 Oct 2007 00:33:09 -0400
> Call Trace:
> [] show_trace_log_lvl+0x1a/0x2f
> [] show_stack_log_lvl+0x9b/0xa3
> [] show_registers+0x1b4/0x285
> [] die+0x100/0x21d
> [] do_page_fault+0x434/0x515
> [] error_code+0x6a/0x70
> []
Fix system call restart handling. We can call directly to the
restart handler, no need to back track through trap that isn't
even implemented on m68knommu.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/kernel/signal.c
There is no separate stack region addresses to print at startup time,
so remove it from the debug listing
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/kernel/setup.c
linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c
---
> What may happen is that action can either float upwards to give
>
> spin_lock
> action
> set IRQ_INPROGRESS
> spin_unlock
>
> spin_lock
> clear IRQ_INPROGRESS
> spin_unlock
>
> or it can float downwards to give
>
> spin_lock
> set
In message <[EMAIL PROTECTED]>, Jeff Garzik writes:
> Erez Zadok wrote:
> > I'm using Linus's git tree as of commit
> > d85714d81cc0408daddb68c10f7fd69eafe7c213. I built that kernel under vmware
> > workstation 6.0.1 which emulates a pcnet32 nic. When I only turn on
> > CONFIG_PCNET32, my
Remove use of undefined symbols CONFIG_TELOS, CONFIG_M68EZ328ADS
and CONFIG_ALMA_ANS.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/kernel/setup.c
linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c
--- linux-2.6.23/arch/m68knommu/kernel/setup.c
From: Wilson Callan <[EMAIL PROTECTED]>
Add make support for the Savant/Rosie1 board.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/Makefile
linux-2.6.23-uc0/arch/m68knommu/Makefile
--- linux-2.6.23/arch/m68knommu/Makefile2007-10-19
From: Wilson Callan <[EMAIL PROTECTED]>
Add configure support for the Savant/Rosie1 board.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/Kconfig
linux-2.6.23-uc0/arch/m68knommu/Kconfig
--- linux-2.6.23/arch/m68knommu/Kconfig 2007-10-19
On Fri, 2007-10-19 at 12:20 +0800, Herbert Xu wrote:
>
> That's why I think this patch is in fact the only one that
> solves all the races in this thread. The case that it solves
> which the lock/unlock patch does not is the one where action
> flows downwards past the clearing of
> The whole lock/set IRQ_INPROGRESS/unlock path can then only happen
> before the locked section above, in which case we see and wait nicely
> and all is good, or after, in which case the store to foo will be
> visible to the IRQ handler as it will be ordered with the unlock in the
> code above.
Good Day,
My randconfig just caught an error on:
kernel/built-in.o: In function `sysctl_check_lookup':
sysctl_check.c:(.text+0x17db1): undefined reference to `sysctl_head_next'
sysctl_check.c:(.text+0x17dc7): undefined reference to `sysctl_head_finish'
Git bisect was unsuccessful due to too many
On Thu, Oct 18, 2007 at 08:26:45PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 18 Oct 2007, Linus Torvalds wrote:
> >
> > I *think* it should work with something like
> >
> > for (;;) {
> > smp_rmb();
> > if (!spin_is_locked(>lock)) {
> >
>
> repeat:
> /* Optimistic, no-locking loop */
> while (desc->status & IRQ_INPROGRESS)
> cpu_relax();
>
> /* Ok, that indicated we're done: double-check carefully */
> spin_lock_irqsave(>lock, flags);
>
From: Matt Waddel <[EMAIL PROTECTED]>
Define __clear_user macro, consistent with other architectures.
fs/signalfd.c won't compile without it.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/uaccess.h
Hello, Linus,
Please pull from:
git://www.linux-m32r.org/git/takata/linux-2.6_dev.git for-linus
This patchset adds missing m32r syscalls for 2.6.23 kernel.
It has been included in 2.6.23-mm1 kernel and tested for a while.
-- Takata
Hirokazu Takata (3):
m32r: Add missing syscalls
On Thu, 18 Oct 2007 18:25:58 -0400
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
Have you tested this patch with LOCKDEP enabled? eventpoll is... tricky
in what it does with waitqueues and locks and some of this stuff is
there, afaik, to deal with that. You're now changing this ... call me
Remove use of undefined symbol CONFIG_DISKtel.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/system.h
linux-2.6.23-uc0/include/asm-m68knommu/system.h
--- linux-2.6.23/include/asm-m68knommu/system.h 2007-10-19 10:21:31.0
+1000
+++
Up to now m68knommu has been using the asm-m68k/module.h instead of
defining its own. There are recent changes there that we don't need
(fixups specifically). We don't need much support here so it makes
sense to have an m68knommu specific one now.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
Remove use of undefined symbol CONFIG_DISKtel.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/include/asm-m68knommu/mcfuart.h
linux-2.6.23-uc0/include/asm-m68knommu/mcfuart.h
--- linux-2.6.23/include/asm-m68knommu/mcfuart.h2007-10-19
10:21:30.0
On Thu, Oct 18, 2007 at 09:39:04PM -0700, Kristoffer Ericson wrote:
> This patch adds HD64461 Timer adresses & registers to the HD64461
> header file (/include/asm-sh/hd64461.h). The timers (TMU0 & TMU1) can
> hold 16bit values and auto loads the counter constant when it reaches
> zero. Upon
From: Philippe De Muyter <[EMAIL PROTECTED]>
Indent all the `else' the same way.
Remove some unecesary white space.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/drivers/net/fec.c
From: Philippe De Muyter <[EMAIL PROTECTED]>
Improve the readability of mii_do_cmd().
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/drivers/net/fec.c linux-2.6.23-uc0/drivers/net/fec.c
---
On Thu, Oct 18, 2007 at 06:14:07PM +0900, [EMAIL PROTECTED] wrote:
>
> Hi Simon,
>
> On Thu, 18 Oct 2007 14:37:41 +0900, Simon Horman <[EMAIL PROTECTED]> wrote:
> > On Wed, Oct 17, 2007 at 02:16:19PM +0900, Ken'ichi Ohmichi wrote:
> > >
> > > Hi Simon,
> > >
> > > Simon Horman wrote:
> > > >
Mark Lord さんは書きました:
> Kenji Kaneshige wrote:
>>
>> - When the card is inserted *after* modprobing pciehp, the card
>>is *not* automatically powered on/detected. So it is very
>>natural that the card, which had been inserted before modprobing
>>pciehp, is not automatically enabled at
(Resend with CC's fixed)
Back in April, Mikko posted a patch to force enable the HPET on some nVidia
chipsets:
v2:
http://lkml.org/lkml/2007/4/16/46
v3:
http://lkml.org/lkml/2007/4/17/354
What would need to be done to this patch to get it into x86 now (besides i386/
x86_64 -> x86
Nick Piggin <[EMAIL PROTECTED]> wrote:
>
>> First of all let's agree on some basic assumptions:
>>
>> * A pair of spin lock/unlock subsumes the effect of a full mb.
>
> Not unless you mean a pair of spin lock/unlock as in
> 2 spin lock/unlock pairs (4 operations).
>
> *X = 10;
> spin_lock();
>
On Thu, 18 Oct 2007, Linus Torvalds wrote:
>
> I *think* it should work with something like
>
> for (;;) {
> smp_rmb();
> if (!spin_is_locked(>lock)) {
> smp_rmb();
> if (!(desc->status & IRQ_INPROGRESS)
>
On Fri, 19 Oct 2007, Nick Piggin wrote:
> I'm not sure, I had an idea it was relatively expensive on ia64,
> but I didn't really test with a good workload (a microbenchmark
> probably isn't that good because it won't generate too much out
> of order memory traffic that needs to be fenced).
Its
On 26/08/07, Paul Rolland <[EMAIL PROTECTED]> wrote:
My machine (an ASUS P5W-DH-Deluxe, Core2, 4Go RAM, 3 SATA and 2IDE) is
reporting a :
irq 23: nobody cared (try booting with the "irqpoll" option)
together with a Call Trace, but :
- irqpoll is present on the command line,
- the irq is
Kenji Kaneshige wrote:
- When the card is inserted *after* modprobing pciehp, the card
is *not* automatically powered on/detected. So it is very
natural that the card, which had been inserted before modprobing
pciehp, is not automatically enabled at the pciehp modprobe time.
Not
On Fri, 19 Oct 2007, Herbert Xu wrote:
>
> In other words I think this patch is great :)
Hey, I appreciate it, but I do think that the "spinlock only to
immediately unlock it again" is pretty horrid.
I'm convinced that there should be some way to do this without actually
taking the lock. I
Al Viro wrote:
On Fri, Oct 19, 2007 at 06:07:45AM +0930, David Newall wrote:
considerations of this whole scheme. Linux, like most Unix systems,
has never allowed hard links to directories for a number of reasons;
The claim is wrong. UNIX systems have traditionally allowed the
peer chen wrote:
I hope one of the following patches can be merged to 2.6.24.
==
http://lkml.org/lkml/2007/10/8/93
http://lkml.org/lkml/2007/9/25/20
Unfortunately I do not feel like this is the right course of action.
Experience from Intel platforms tells us that our
On Friday 19 October 2007 12:32, Herbert Xu wrote:
> First of all let's agree on some basic assumptions:
>
> * A pair of spin lock/unlock subsumes the effect of a full mb.
Not unless you mean a pair of spin lock/unlock as in
2 spin lock/unlock pairs (4 operations).
*X = 10;
spin_lock();
/* *Y
On Thu, 2007-10-18 at 23:33 +0100, Samuel Thibault wrote:
> Hi,
>
> Mike Galbraith, le Thu 18 Oct 2007 19:56:38 +0200, a écrit :
> > The winner of a very long git bisect session:
> >
> > unicode diacritics support
>
> Uh, I fail to see how that could have an impact, I've again checked the
>
If a PCIe ExpressCard34 is inserted into the slot *before*
I modprobe pciehp (with pciehp_force=1), then the card is not
detected nor enabled. The patch provided here fixes that.
Could you give me answers against the following questions?
(1) Did you try "echo 1 >
On Thu, Oct 18, 2007 at 04:39:59PM -0700, Linus Torvalds wrote:
>
> Basic notion: the only thing that serializes the IRQ_INPROGRESS flag is
> the descriptor lock. And we don't have to (or even want to!) hold it while
> waiting for the thing, but we want to *have*held*it* in between whatever
>
On Wed, Oct 17, 2007 at 09:23:02PM -0700, David Miller wrote:
[...]
> > The same problem exists for detaching filter (SO_DETACH_FILTER).
> >
> > The proposed fix consists of 3 preparation patches and the fix itself.
> >
> > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
>
> Looks good,
On Friday 19 October 2007 12:01, Christoph Lameter wrote:
> On Fri, 19 Oct 2007, Nick Piggin wrote:
> > > Yes that is what I attempted to do with the write barrier. To my
> > > knowledge there are no reads that could bleed out and I wanted to avoid
> > > a full fence instruction there.
> >
> > Oh,
On Wed, 2007-10-17 at 21:09 -0700, Andrew Morton wrote:
> On Thu, 11 Oct 2007 13:18:49 +0200 Jan Kara <[EMAIL PROTECTED]> wrote:
>
> > With 64KB blocksize, a directory entry can have size 64KB which does not fit
> > into 16 bits we have for entry lenght. So we store 0x instead and
> >
Remove build reference to arch/m68knommu/boot directory, it doesn't
exist.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/Makefile
linux-2.6.23-uc0/arch/m68knommu/Makefile
--- linux-2.6.23/arch/m68knommu/Makefile2007-10-19 10:30:58.0
On Fri, 19 Oct 2007, Nick Piggin wrote:
> > Yes that is what I attempted to do with the write barrier. To my knowledge
> > there are no reads that could bleed out and I wanted to avoid a full fence
> > instruction there.
>
> Oh, OK. Bit risky ;) You might be right, but anyway I think it
> should
On Friday 19 October 2007 11:21, Christoph Lameter wrote:
> On Fri, 19 Oct 2007, Nick Piggin wrote:
> > Ah, thanks, but can we just use my earlier patch that does the
> > proper __bit_spin_unlock which is provided by
> > bit_spin_lock-use-lock-bitops.patch
>
> Ok.
>
> > This primitive should have
[POWERPC] Switch to generic WARN_ON()/BUG_ON()
Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
4K text on a ppc64_defconfig. The main reason seems to be that prepping
the arguments to the conditional trap instructions is more work than
just doing a compare and branch.
No need to have the HAVE_ARCH_BUG.* / HAVE_ARCH_WARN.* defines, when
the generic implementation can just use #ifndef on the macros themselves.
Also, introduce __WARN() in the generic case, so the generic WARN_ON()
can use arch-specific code for when the condition is true.
Built on powerpc, i386,
Updated defconfig with new options for m68knommu.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naurp linux-2.6.23/arch/m68knommu/defconfig
linux-2.6.23-uc0/arch/m68knommu/defconfig
--- linux-2.6.23/arch/m68knommu/defconfig 2007-10-19 10:30:58.0
+1000
+++
A new style serial driver for the Freescale ColdFire UART to replace
the old style one currently in the tree (drivers/serial/mcfserial.c).
Currently this UART is only found in the ColdFire CPU family of parts
(thus I prefixed this patch [M68KNOMMU]).
This has been around for a long while now,
On Thu, 2007-10-18 at 16:08 -0400, Alan Stern wrote:
> On Thu, 18 Oct 2007, Kay Sievers wrote:
>
> > On Thu, 2007-10-18 at 15:23 -0400, Alan Stern wrote:
> > > This patch (as1004) fixes a refcounting bug in the development version
> > > of the block-device core.
> > >
> > > Signed-off-by: Alan
On Fri, 19 Oct 2007, Nick Piggin wrote:
> Ah, thanks, but can we just use my earlier patch that does the
> proper __bit_spin_unlock which is provided by
> bit_spin_lock-use-lock-bitops.patch
Ok.
> This primitive should have a better chance at being correct, and
> also potentially be more
On 10/19/07, Kristoffer Ericson <[EMAIL PROTECTED]> wrote:
> Greetings,
>
> I've been trying to implement proper suspend on my jornada 720 machine. But
> as far as I can see it never reaches
> the sa11x0_suspend code.
>
> I've linked power button event to produce APM_SUSPEND and I can see that it
Sam Ravnborg wrote:
> And I recall that extern char sym[] is considered correct by binutils
> people - but I'm not 100% sure and google did not give me an appropriate hit.
Yes, I generally prefer char[] - but only because gcc irritatingly
rejects void []...
J
-
To unsubscribe from this
On Fri, Oct 19, 2007 at 12:15:47AM +0200, Thomas Gleixner wrote:
> On Thu, 18 Oct 2007, Andrew Morton wrote:
> > > +
> > > +#include
> > > +#include
> > > +#include
> >
> > Please see the large comment at the top of linux/irq.h. I believe this
> > driver will fial to compile on at least arm.
> So how about something like this (untested! not necessarily very well
> thought through either!)
>
> Basic notion: the only thing that serializes the IRQ_INPROGRESS flag is
> the descriptor lock. And we don't have to (or even want to!) hold it while
> waiting for the thing, but we want to
On Friday 19 October 2007 08:05, Richard Jelinek wrote:
> Hello guys,
>
> I'm not subscribed to this list, so if you find this question valid
> enough to answer it, please cc me. Thanks.
>
> This is what the top-output looks like on my machine after having
> copied about 550GB of data from a
On 18/10/07 15:27 -0400, Andres Salomon wrote:
> The existing Geode GPIO API only allows for updating one GPIO at once. There
> are instances where users want to update multiple GPIOs at once. With the
> current API, they are given two choices; either ignore the GPIO API:
>
> outl(0xc000,
On 18/10/07 15:26 -0400, Andres Salomon wrote:
> Simple cosmetic update for the cs5536 reboot fixup; define the MSR that's used
> for rebooting in geode.h, and use the define.
>
> Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>
Acked-by: Jordan Crouse <[EMAIL PROTECTED]>
> diff --git
[sorry, I read and replied to my inbox before mailing lists...
please ignore the last mail on this patch, and reply to this
one which is properly threaded]
On Friday 19 October 2007 08:15, Christoph Lameter wrote:
> Currently page flags are only modified in SLUB under page lock. This means
> that
On Friday 19 October 2007 08:31, [EMAIL PROTECTED] wrote:
> --
> Subject: SLUB: avoid atomic operation for slab_unlock
> From: Christoph Lameter <[EMAIL PROTECTED]>
>
> Currently page flags are only modified in SLUB under page lock. This means
On Fri, 19 Oct 2007, Benjamin Herrenschmidt wrote:
>
> I agree and you can see that in fact, we don't have enough barrier on
> the other side since spin_unlock doesn't prevent subsequent loads from
> crossing a previous store...
>
> I wonder if that's worth trying to address, adding a barrier
Greetings,
I've been trying to implement proper suspend on my jornada 720 machine. But as
far as I can see it never reaches
the sa11x0_suspend code.
I've linked power button event to produce APM_SUSPEND and I can see that it
says "Stopping TASKS ==". It then
blanks screen but keeps LCD
The 32-bit version is more efficient (and apparently gives better hash
results than the 64-bit version), so users who are only hashing a 32-bit
quantity can now opt to use the 32-bit version explicitly, rather than
promoting to a long.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
On Thu, 2007-10-18 at 16:01 -0500, [EMAIL PROTECTED] wrote:
> > We've come across an Oops, in what appears to NFS.
> >
> > 2.6.22.6 vanilla + realtime-lsm
> > RHEL4 over PXE/NFS_ROOT
> >
> >
> > Oct 9 14:26:13 WS15 gdm(pam_unix)[6038]: session opened for
> > user mockj by (uid=0) Oct 9
Add support for version 2 of the ioatdma device. This device handles
the descriptor chain and DCA services slightly differently:
- Instead of moving the dma descriptors between a busy and an idle chain,
this new version uses a single circular chain so that we don't have
rewrite the
On Thu, 2007-10-18 at 15:52 -0700, Linus Torvalds wrote:
>
> On Fri, 19 Oct 2007, Benjamin Herrenschmidt wrote:
> >
> > The barrier would guarantee that ioc->active (and in fact the write to
> > the chip too above) are globally visible
>
> No, it doesn't really guarantee that.
>
> The thing
Avi Kivity <[EMAIL PROTECTED]> writes:
> This is more useful operating on an entire file, so the script can see
> all the context.
>
> A 'gcc -Windentation-contradicts-codeflow -Werror' would be nice.
I had a tool long ago on the Amiga which did exactly that. It double checked
that the
* Ken Chen ([EMAIL PROTECTED]) wrote:
> On 10/18/07, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> > Good question indeed. How large is this memory footprint exactly ? If it
> > is as small as you say, I suspect that the real issue could be that
> > these variable are accessed by the scheduler
>-Original Message-
>From: Jiri Slaby [mailto:[EMAIL PROTECTED]
>Sent: Thursday, October 18, 2007 5:08 PM
>To: Nick Thompson
>Cc: Jiri Slaby; linux-kernel@vger.kernel.org; Ferenc Wagner
>Subject: Re: RocketPort Linux driver errors on module reload
>
>
>>On 10/17/2007 09:48 PM, Nick
On 10/18/07, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Good question indeed. How large is this memory footprint exactly ? If it
> is as small as you say, I suspect that the real issue could be that
> these variable are accessed by the scheduler critical paths and
> therefore trash the caches.
On Fri, 19 Oct 2007, Benjamin Herrenschmidt wrote:
>
> The barrier would guarantee that ioc->active (and in fact the write to
> the chip too above) are globally visible
No, it doesn't really guarantee that.
The thing is, there is no such thing as "globally visible".
There is a "ordering of
On Wed, Oct 17, 2007 at 10:48:52AM -0400, Alan Stern wrote:
> On Tue, 16 Oct 2007, Matthew Dharm wrote:
>
> > On Tue, Oct 16, 2007 at 02:04:43PM -0400, Alan Stern wrote:
> > > On Tue, 16 Oct 2007, Matthew Dharm wrote:
> > >
> > > > I haven't looked at this code at all, but neither approach feels
Hi,
Mike Galbraith, le Thu 18 Oct 2007 19:56:38 +0200, a écrit :
> The winner of a very long git bisect session:
>
> unicode diacritics support
Uh, I fail to see how that could have an impact, I've again checked the
boundaries, it looks fine, please people have a look.
Could you try
On Thursday 18 October 2007, Benjamin Herrenschmidt wrote:
>
> On Thu, 2007-10-18 at 16:02 +0400, Sergei Shtylyov wrote:
> > Benjamin Herrenschmidt wrote:
> >
> > > The siimage use an incorrect construct to access the other drive
> > > of a pair, causing it to access beyond an array boundary on
On Thursday 18 October 2007, Benjamin Herrenschmidt wrote:
> The cs5535 use an incorrect construct to access the other drive
> of a pair, causing it to access beyond an array boundary on non-0
> interfaces. This fixes it by using the new ide_get_paired_drive()
> hepler instead.
>
> Signed-off-by:
On Thursday 18 October 2007, Benjamin Herrenschmidt wrote:
> The siimage use an incorrect construct to access the other drive
> of a pair, causing it to access beyond an array boundary on non-0
> interfaces. This fixes it by using the new ide_get_paired_drive()
> hepler instead.
>
>
On Thursday 18 October 2007, Benjamin Herrenschmidt wrote:
> This adds a helper to get to the "other" drive on a pair connected
> to a given hwif.
>
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
applied
-stable team: please include this patch series in 2.6.23.2
> ---
>
> Note:
On Thursday 18 October 2007, Benjamin Herrenschmidt wrote:
> At least 2 drivers (siimage and cs5535) have a bug where they use
> the construct:
>
> ide_drive_t *pair = >drives[drive->dn ^ 1];
>
> To access the other drive in a master/slave pair. This is bogus
> because drive->dn is
Jiri Slaby <[EMAIL PROTECTED]> writes:
> I meant the creating of a git repository with only the module would be the
> easiest possible and most comfortable way for you :). Otherwise I can post
> you a
> patch serie.
We can go either way, as you prefer.
> On 10/18/2007 11:53 PM, Ferenc Wagner
On Thu, Oct 18, 2007 at 03:37:51PM -0700, Andrew Morton wrote:
> On Fri, 19 Oct 2007 00:18:13 +0200
> Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>
> > And I recall that extern char sym[] is considered correct by binutils
> > people - but I'm not 100% sure and google did not give me an appropriate
Hello guys,
I'm not subscribed to this list, so if you find this question valid
enough to answer it, please cc me. Thanks.
This is what the top-output looks like on my machine after having
copied about 550GB of data from a twofish256 crypted disk to a raid
array:
--
Mem: 8178452k
On Thu, 18 Oct 2007, Dmitry Torokhov wrote:
> On 10/17/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> > Still, I was
> > thinking about it, and a doubt came to mind: would it cause problems for a
> > bitmap to share the function for EV_foo and EV_foo notifications?
>
> Not sure if I
On Fri, 19 Oct 2007 00:18:13 +0200
Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> And I recall that extern char sym[] is considered correct by binutils
> people - but I'm not 100% sure and google did not give me an appropriate hit.
An ancient memory tells me that these things are traditionally
On Thu, Oct 18, 2007 at 03:17:52PM -0700, Andrew Morton wrote:
> On Thu, 11 Oct 2007 12:12:11 -0500
> Olof Johansson <[EMAIL PROTECTED]> wrote:
>
> > HAVE_ARCH_WARN is used to determine if an arch already has a __WARN()
> > macro, or if a generic one is needed.
> >
> > With this, some of the
1 - 100 of 968 matches
Mail list logo
