> The current idea is that we will have multiple governors changeable at run
> time only for
> DEBUG and DEVELOPMENT. On a standard end user system there will be one
> governor
> (current optimal governor) that will be loaded. This gives
> flexibality to experiments with governors and also
Hi,
Do the PCI Express chipsets also use the same PCI API ? The device
specifications are thus for the device that i am looking at:
PCI Express interface
* Compliant to PCI Express Base Specification 1.0a
* The PCI Express circuit supports isochronous data traffic intended
for
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
In -v14 the biggest user-visible change is increased sleeper fairness
On May 22 2007 20:48, Miklos Szeredi wrote:
>Why do we want this?
>
>
>That depends on who you ask. My answer is this:
>
> 'foo.tar.gz/foo/bar' or
> 'foo.tar.gz/contents/foo/bar'
>
>or something similar.
Stole reiser4 an idea.
These semantics are quite fragile. Until now,
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
I get this on boot :
[ 0.333581] BUG: at include/linux/slub_def.h:83 kmalloc_index()
[ 0.333587] [] show_trace_log_lvl+0x1a/0x2f
[ 0.333601] [] show_trace+0x12/0x14
[ 0.333606] []
Hi!
> I have kernel panic message when trying to put Dell
> Inspiron 6400 into hibernation.
>
> The following is the message:
>
> Process pm-hibernate (pid: 3168, threadinfo
> 810013dba000, task 810018d0e
> 860)
> Stack:
> 01bc7e40f260
Hello!
> #2 crash be explained via any of the bugs you fixed? (i.e. memory
> corruption?)
Yes, I found the reason, it is really fixed by taking tasklist_lock.
This happens after task struct with not cleared pi_state_list is freed
and the list of futex_pi_state's is corrupted.
Meanwhile... two
Hi Michael,
On 5/23/07, Michael-Luke Jones <[EMAIL PROTECTED]> wrote:
On 23 May 2007, at 09:27, Nitin Gupta wrote:
> This contains LZO1X-1 compressor and LZO1X decompressor (safe and
> standard version).
I understand that the 'safe' decompression code is 'somewhat slower'
and that
* Herbert Xu <[EMAIL PROTECTED]> wrote:
> [NET_SCHED]: Fix qdisc_restart return value when dequeue is empty
>
> My previous patch that changed the return value of qdisc_restart
> incorrectly made the case where dequeue returns empty continue
> processing packets.
>
> This patch is based on
> When the real superblock is created. It could even be the _same_
> super block as the real one. There'd be just the problem of anchoring
> the dir-on-file dentries somewhere...
>
> Or with fuse the dir-on-file mount can just come from any mounted
> filesystem, again possibly the same one as
Herbert Xu wrote:
> On Wed, May 23, 2007 at 12:56:04PM +0200, Patrick McHardy wrote:
>
>>Looking at the recent changes to __qdisc_run, this indeed seems
>>to be the case, when the qdisc is throttled and has packets queued
>>we return a value != 0, causing __qdisc_run to loop until all
>>packets
On Wed, May 23, 2007 at 12:56:04PM +0200, Patrick McHardy wrote:
>
> Looking at the recent changes to __qdisc_run, this indeed seems
> to be the case, when the qdisc is throttled and has packets queued
> we return a value != 0, causing __qdisc_run to loop until all
> packets have been sent, which
I wrote on 2007-05-19:
> Linus, please pull from the for-linus branch at
>
> git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git
> for-linus
>
> to receive the following IEEE 1394 subsystem updates:
>
> - fix regression in 2.6.22-rc1:
> raw1394 asynchronous
* Patrick McHardy <[EMAIL PROTECTED]> wrote:
> How is this trace to be understood? Is it simply a call trace in
> execution-order? [...]
yeah. There's a help section at the top of the trace which explains the
other fields too:
_--=> CPU#
/ _-=>
Randy Dunlap wrote:
>
> Add "notime" boot option to prevent timing data from being printed on
> each printk message line.
That's a good source of confusion. To me, "notime" means something
like "don't bother calculating time", instead of the proposed
behavior. Can't it be something like
> -Message d'origine-
> De : Greg KH [mailto:[EMAIL PROTECTED]
> Envoyé : 22 mai 2007 23:37
> À : Fortier,Vincent [Montreal]
>
> On Tue, May 22, 2007 at 09:28:34PM -0400, Fortier,Vincent
> [Montreal] wrote:
> > > -Message d'origine-
> > > De : [EMAIL PROTECTED]
> > >
Ingo Molnar wrote:
> if you feel inclined to try the git-bisection then by all means please
> do it (it will certainly be helpful and educative), but it's optional: i
> dont think you should 'need' to go through extra debugging chores, my
> analysis based on the excellent trace you provided
On 23 May 2007, at 09:27, Nitin Gupta wrote:
This contains LZO1X-1 compressor and LZO1X decompressor (safe and
standard version).
I understand that the 'safe' decompression code is 'somewhat slower'
and that decompressor performance is a key feature of this algorithm.
However, I am
On Tue, May 22, 2007 at 08:35:17AM -0400, Shaya Potter wrote:
> Bharata B Rao wrote:
> >
> >In case of regular files, when we copyup a file, we are actually preventing
> >any writes to the lower layers (which we have designated as read only).
> >
> >Applying the same logic to devices, what do we
* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Use the lockdep infrastructure to track lock contention and other lock
> statistics.
>
> It tracks lock contention events, and the first four unique call-sites
> that encountered contention.
>
> It also measures lock wait-time and hold-time in
> > > + * This is tricky, because for namespace modification we must take the
> > > + * namespace semaphore. But mntput() is called from various places,
> > > + * sometimes with namespace_sem held. Fortunately in those places the
> > > + * mount cannot yet have MNT_DIRONFILE, or at least that's
On Wed, May 23, 2007 at 12:09:19PM +0200, Miklos Szeredi wrote:
> Right. After locking vfsmount_lock, mount_dironfile() should recheck
> if there was a race and bail out.
Owww... Not pretty, that...
> I don't think the filesystem ought to try _creating_ a vfsmount. I
> imagine, that the fs
Hello,
As per the recent discussion, the folowing patch removes the TIF_NOTIFY_RESUME
flag from all processor architectures. The flag was not used except on IA-64
for the perfmon subsystem. For IA-64, the patch replaces the flag with a new
dedicated TIF flag. This provides an extra low-order bit
--- Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Wed, 23 May 2007, Srihari Vijayaraghavan wrote:
[...]
> Yup. compile with
>
> CONFIG_NUMA
>
> CONFIG_LOCKDEP
>
> CONFIG_DEBUG_LOCK_ALLOCS
(All the tests in this email was conducted on top of your patch)
Yup done that. The resulting kernel
> On Wed, May 23, 2007 at 11:03:08AM +0200, Miklos Szeredi wrote:
> > I still don't get it where the superblock comes in. The locking is
> > "interesting" in there, yes. And I haven't completely convinced
> > myself it's right, let alone something that won't easily be screwed up
> > in the
> > + * This is called if the object has no ->lookup() defined, yet the
> > + * path contains a slash after the object name.
> > + *
> > + * If the filesystem defines an ->enter() method, this will be called,
> > + * and the filesystem shall fill the supplied struct path or return an
> > + *
This small patch adds the automatic recalibration feature without
spoiling previously calibrated devices. It's a fix for those joysticks
that report faulty range, specially Saitek Cyborg Evo Force.
File: drivers/input/joydev.c
Fix:
- extracted code from joydev_connect to method
raw_spinlock_t should not use lockdep (and doesn't) since lockdep itself relies
on it.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/linux/spinlock_types.h|4 ++--
include/linux/spinlock_types_up.h |9 +
2 files changed, 3 insertions(+), 10 deletions(-)
Use the lockdep infrastructure to track lock contention and other lock
statistics.
It tracks lock contention events, and the first four unique call-sites that
encountered contention.
It also measures lock wait-time and hold-time in nanoseconds. The minimum and
maximum times are tracked, as well
Count lock contention events per lock class. Additionally track the first four
callsites that resulted in the contention.
/proc/lock_contentions - gives a single line per lock class:
<(write) contentions>
Followed by another three columns per contention point:
writing a '0' to the
Put the lock dependancy tracking bits under CONFIG_PROVE_LOCKING
This way we can reuse the hold_lock part of lockdep for other purposes.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
kernel/lockdep.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
Index:
Track lock waittime - that is the time spend waiting on lock acquisition.
/proc/lock_waittime - starts with the same three colums as lock_contentions:
<(write) contentions>
After that come two times four more columns:
for both (write) contentions and read contentions. Times are in
Allow for runtime configuration of lockdep and lockstat.
/proc/sys/kernel/prove_locking
/proc/sys/kernel/lock_stat
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
kernel/lockdep.c | 27 +++
kernel/sysctl.c | 27 +++
2 files changed,
Rework the lock stat counters to be scalable.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/linux/lockdep.h | 34 +-
kernel/lockdep.c| 162
kernel/lockdep_proc.c | 136 ++--
Track lock hold times - that is the time we held the lock.
/proc/lock_holdtime - starts with the same three colums as lock_contentions:
<(write) contentions>
After that come two times four more columns:
for both (write) locks and read locks. Times are in 1e-9 seconds.
Writing a 0 to
On 23/05/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
(Adding Dmitry to CC so that he doesn't miss it.
Also, if you'd like to get your patch merged, you should add proper
Signed-off-by line.
Hi Jiri,
Sorry, it's my first kernel patch, how do I add Signed-off-by line?
I did with:
$ diff -u
During prereset, -ENODEV return from ata_wait_ready() is not an error.
This causes unnecessary bug message on controllers which uses 0xff to
indicate empty port. Fix it.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Paul Mundt <[EMAIL PROTECTED]>
---
This one is for 2.6.22 too. Thanks.
On Wed, May 23, 2007 at 11:03:08AM +0200, Miklos Szeredi wrote:
> I still don't get it where the superblock comes in. The locking is
> "interesting" in there, yes. And I haven't completely convinced
> myself it's right, let alone something that won't easily be screwed up
> in the future. So
On Wed, 2007-05-23 at 11:05 +0200, Rafael J. Wysocki wrote:
> Hi,
>
> On Wednesday, 23 May 2007 09:25, Romano Giannetti wrote:
> > http://lkml.org/lkml/2007/5/23/38
>
> Please see http://bugzilla.kernel.org/show_bug.cgi?id=8456
> That seems to resemble the symptoms you describe.
>
No, I don't
On Tue, May 22, 2007 at 08:48:49PM +0200, Miklos Szeredi wrote:
> */
> -static int __follow_mount(struct path *path)
> +static int __follow_mount(struct path *path, bool enter)
> {
> int res = 0;
> while (d_mountpoint(path->dentry)) {
> - struct vfsmount *mounted =
On Wed, May 23, 2007 at 11:29:37AM +0200, Tejun Heo wrote:
> Paul Mundt wrote:
> > On Wed, May 23, 2007 at 10:07:08AM +0200, Tejun Heo wrote:
> >> Paul Mundt wrote:
> >>> On a number of boards the current prereset logic seems to misbehave:
> >>>
> >>> scsi0 : pata_platform
> >>> ata1: PATA max
Hi,
Andrew Morton napisał(a):
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
>
Christoph, this looks like a bug in SLUB.
[ 16.232377] PM: Adding info for No Bus:vcs1
[ 16.237588] PM: Adding info for No Bus:vcsa1
[ 18.683210] PM: Adding info for
(Adding Dmitry to CC so that he doesn't miss it.
Also, if you'd like to get your patch merged, you should add proper
Signed-off-by line.
Thanks)
On Wed, 23 May 2007, Renato Golin wrote:
> This small patch adds the automatic recalibration feature without
> spoiling previously calibrated
> > > As for unlink... How do you deal with having that thing
> > > mounted, mounting something _under_ it (so that vfsmount would be kept
> > > busy) and then unlinking that sucker?
> >
> > Yeah, that's a good point. Current patch doesn't deal with that.
> > Simplest solution could be to
> > So your question is, which mount takes priority on the lookup? It
> > probably should be the propagated real mount, rather than the
> > dir-on-file one, shouldn't it?
> >
>
> Maybe this might belong into __link_path_walk() similar to the
> handling of symbolic links. If the real mount has
Paul Mundt wrote:
> On Wed, May 23, 2007 at 10:07:08AM +0200, Tejun Heo wrote:
>> Paul Mundt wrote:
>>> On a number of boards the current prereset logic seems to misbehave:
>>>
>>> scsi0 : pata_platform
>>> ata1: PATA max PIO0 cmd 0xb06001f0 ctl 0xb06003f6 bmdma 0x irq 0
>>> ata1: device
From: "Wu, Bryan" <[EMAIL PROTECTED]>
This patch implements the driver necessary use the Analog Devices
Blackfin processor's on-chip ethernet MAC controller.
Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
Cc: Jeff Garzik <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
On Tue, May 22, 2007 at 04:31:22PM -0700, Jesse Barnes wrote:
> On Tuesday, May 22, 2007, Wayne Sherman wrote:
> > If so, the D-Link is not being mapped into the
> > right region, and the bridge it is behind does not have enough memory
> > assigned to it (ff50-ff5f : PCI Bus #02).
>
>
On Tue, May 22, 2007 at 04:41:36PM -0700, Kevin Hilman wrote:
> On Tue, 2007-05-22 at 16:25 -0700, Daniel Walker wrote:
> > On Tue, 2007-05-22 at 16:01 -0700, Kevin Hilman wrote:
> > > Add a preempt_enable() to flush_tlb_kernel_page() since -rt4 patch
> > > adds a preempt_disable but no
On 5/23/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> As for unlink... How do you deal with having that thing
> mounted, mounting something _under_ it (so that vfsmount would be kept
> busy) and then unlinking that sucker?
Yeah, that's a good point. Current patch doesn't deal with that.
On Wednesday, 23 May 2007 09:48, Andrew Morton wrote:
> On Wed, 23 May 2007 00:42:33 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
>
> This is intermittently getting resume-from-RAM failures. It is
On Wed, 2007-05-23 at 05:13 -0400, Jeff Garzik wrote:
> Bryan Wu wrote:
> > Hi Jeff:
> >
> > Could you please review this patch? Sorry for miss sending the patch to
> > you for review at beginning.
>
> can you resend as a patch rather than a quoted patch?
>
> Jeff
>
>
Oh, sorry, I
On 5/23/07, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
So your question is, which mount takes priority on the lookup? It
probably should be the propagated real mount, rather than the
dir-on-file one, shouldn't it?
Maybe this might belong into __link_path_walk() similar to the
handling of
Bryan Wu wrote:
Hi Jeff:
Could you please review this patch? Sorry for miss sending the patch to
you for review at beginning.
can you resend as a patch rather than a quoted patch?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
> On Wed, May 23, 2007 at 10:05:21AM +0200, Miklos Szeredi wrote:
> > > Er... These mounts might not be propagated, but what about a bind
> > > over another instance of such file in master tree?
> >
> > So your question is, which mount takes priority on the lookup? It
> > probably should be the
Hi,
On Wednesday, 23 May 2007 09:25, Romano Giannetti wrote:
> Hi,
>
> I am trying to upgrade from my ubuntu kernel 2.6.17.3 to 2.6.21.1 and I
> have quite a bunch of problems with suspend/resume, both to disk and to
> ram. I have reported the s2ram problem in a separate message (search for
> a
On Tuesday 22 May 2007 23:09:39 Richard Griffiths wrote:
> Venerable cramfs fs Linear XIP patch originally from MontaVista, used in
> the embedded Linux community for years, updated for 2.6.21. Tested on
> several systems with NOR Flash. PXA270, TI OMAP2430, ARM Versatile and
> Freescale iMX31ADS.
On Wed, 2007-05-23 at 10:46 +0200, Cornelia Huck wrote:
> Taking a quick look at the async_*.c stuff, the functions in question
> basically seem to be of the form
>
> check_if_we_can_do_it_async();
> if (async_ok) {
> /* do async stuff */
> /* that's where the dma mapping creeps
On Wednesday, 23 May 2007 03:48, Matt Mackall wrote:
> On Tue, May 22, 2007 at 09:19:43PM -0300, Henrique de Moraes Holschuh wrote:
> > On Tue, 22 May 2007, Matt Mackall wrote:
> > > On Mon, May 21, 2007 at 08:03:49PM -0300, Henrique de Moraes Holschuh
> > > wrote:
> > > > On Mon, 21 May 2007,
> > This does not happen in reality. Breakpoints can only be set by the
> > debugger, not by the program itself. The debugger should always eat the
> > trap.
>
> Hmmm. I put in a little extra code to account for the possibility that
> a program might want to set hardware breakpoints in
On Tue, 22 May 2007, Andrew Morton wrote:
> > This patch is using mmap()'s randomization functionality in such a way
> > that it maps the main executable of (specially compiled/linked
> > -pie/-fpie) ET_DYN binaries onto a random address (in cases in which
> > mmap() is allowed to perform a
On Wed, 23 May 2007 10:05:39 +0200,
Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> We are trying to get rid of dma-mapping.h, see the last change to the
> file with commit 411f0f3edc141a582190d3605cadd1d993abb6df. I don't think
> we should reintroduce dma related definition but split the
Hi,
Sorry for the wrong patch in my last post.
How about save the tsk then call kthread_stop like this:
diff -udr linux/fs/cifs/connect.c linux.new/fs/cifs/connect.c
--- linux/fs/cifs/connect.c 2007-05-23 10:59:13.0 +
+++ linux.new/fs/cifs/connect.c 2007-05-23 16:33:54.0
On 5/23/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote:
"Robert P. J. Day" <[EMAIL PROTECTED]> writes:
> that may be but, as i suggested earlier, that would get into guessing
> what those developers were thinking, and i just didn't want to go
> there.
No guessing, I just checked it (though a
On Wed, May 23, 2007 at 10:07:08AM +0200, Tejun Heo wrote:
> Paul Mundt wrote:
> > On a number of boards the current prereset logic seems to misbehave:
> >
> > scsi0 : pata_platform
> > ata1: PATA max PIO0 cmd 0xb06001f0 ctl 0xb06003f6 bmdma 0x irq 0
> > ata1: device not ready
On Wed, May 23, 2007 at 10:05:21AM +0200, Miklos Szeredi wrote:
> > Er... These mounts might not be propagated, but what about a bind
> > over another instance of such file in master tree?
>
> So your question is, which mount takes priority on the lookup? It
> probably should be the propagated
Hi Jeff:
Could you please review this patch? Sorry for miss sending the patch to
you for review at beginning.
Thanks a lot
-Bryan Wu
On Sun, 2007-05-06 at 14:50 -0700, [EMAIL PROTECTED] wrote:
> From: "Wu, Bryan" <[EMAIL PROTECTED]>
>
> This patch implements the driver necessary use the Analog
Hi,
This contains LZO1X-1 compressor and LZO1X decompressor (safe and
standard version).
This includes changes suggested by various people - Thanks to all who
reviewed previous patches for this LZO port.
Changelog vs original LZO 2.02 code:
- Chopped down huge parts of original code that were
On Wed, May 23, 2007 at 09:58:35AM +0200, Xavier Bestel wrote:
> On Wed, 2007-05-23 at 07:23 +0200, Michael Gerdau wrote:
> > For me the huge difference you have for sd to the others increases the
> > likelyhood the glxgears benchmark does not measure scheduling of graphic
> > but something else.
Greg KH wrote:
> On Mon, May 21, 2007 at 10:31:01AM +0530, Maneesh Soni wrote:
>> On Thu, May 17, 2007 at 08:16:10PM +0200, Tejun Heo wrote:
>>> Allowing attribute and symlink dentries to be reclaimed means
>>> sd->s_dentry can change dynamically. However, updates to the field
>>> are
Paul Mundt wrote:
> On a number of boards the current prereset logic seems to misbehave:
>
> scsi0 : pata_platform
> ata1: PATA max PIO0 cmd 0xb06001f0 ctl 0xb06003f6 bmdma 0x irq 0
> ata1: device not ready (errno=-19), forcing hardreset
> ata1: BUG: prereset() requested invalid reset
> > > Eh... Arbitrary limitations are fun, aren't they?
> >
> > But these mounts _are_ special. There is really no point in moving or
> > pivoting them.
>
> pivoting - probably true, moving... why not?
I don't see any use for that. But indeed, it should not be too hard
to do.
> > > What
On Tue, 2007-05-22 at 17:25 -0700, Williams, Dan J wrote:
> The approach I have taken is to add the missing definitions to
> include/asm-s390/dma-mapping.h [ a non-outlook-mangled version of the
> patch is pushed out in my rebased git tree ]. I was not able to fully
> compile-test this change as
On Wed, 2007-05-23 at 07:23 +0200, Michael Gerdau wrote:
> For me the huge difference you have for sd to the others increases the
> likelyhood the glxgears benchmark does not measure scheduling of graphic
> but something else.
I think some people forget that X11 has its own scheduler for graphics
On Wed, 23 May 2007 08:50:01 +1000
Con Kolivas <[EMAIL PROTECTED]> wrote:
> On Wednesday 23 May 2007 06:42, Ash Milsted wrote:
> > Hi. I just did some video encoding on my desktop and I was noticing
> > (for the first time in a while) that running apps had to hit swap quite
> > a lot when I
Andrew Morton wrote:
But we'd expected and hoped that flash-based XIP would be able to use
the existing xip infrastructure, in mm/filemap_xip.c. Not possible?
Thanks for the heads up Andrew. Reading the cramfs patch, I've found a
lot of similarities between the current mainline xip stack and
On Wed, 23 May 2007 00:42:33 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
This is intermittently getting resume-from-RAM failures. It is not
sufficiently repeatable to be able to bisect.
[ 1381.119362]
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc2/2.6.22-rc2-mm1/
- A new readahead patch series. This needs serious review and performance
testing please.
- Added Ingo's CFS CPU scheduler
- Xen dom-U support is now in the x86 tree.
Boilerplate:
- See the
On Wed, 2007-05-23 at 09:19 +0200, Paolo Ornati wrote:
> On Wed, 23 May 2007 09:09:00 +0200
> Romano Giannetti <[EMAIL PROTECTED]> wrote:
>
> > Will try to reboot with clocksource=acpi_pm, althoughI think that this
> > is the one I'm using.
>
> you can see that with:
>
> cat
On Wed, May 23, 2007 at 09:19:17AM +0200, Miklos Szeredi wrote:
> > Eh... Arbitrary limitations are fun, aren't they?
>
> But these mounts _are_ special. There is really no point in moving or
> pivoting them.
pivoting - probably true, moving... why not?
> > What about MNT_SLAVE stuff being
On Tue 22-05-07 15:39:31, Eric Sandeen wrote:
> Eric Sandeen wrote:
>
> > Jan -
> >
> > I ran 2.6.21 + your udf patches from -mm through some udf tests which,
> > oddly enough, can be found in the xfstests test suite in xfsprogs cvs
> > from sgi.
> >
> > It looks much better than before, but I
Hi,
Paa Paa hotmail.com> writes:
>
> But are you saying that with most desktop mobos one doesn't usually have the
> different power states available at all? So basically the only means to
> conserve power is to scale the frequency?
>
Even frequency is very limited on core 2 duo. Because of
* Alexey Kuznetsov <[EMAIL PROTECTED]> wrote:
> Hello!
>
> 1. New entries can be added to tsk->pi_state_list after task completed
>exit_pi_state_list(). The result is memory leakage and deadlocks.
>
> 2. handle_mm_fault() is called under spinlock. The result is obvious.
>
> 3. State
On Wed, 23 May 2007, Rob Landley wrote:
> On Tuesday 22 May 2007 10:38 pm, Roland Dreier wrote:
> > > I could send a patch to do this, but moving files via patch is icky.
> Would it
> > > be better to start a git tree and ask people to pull from it, or to send
> in
> > > script snippets
Hi,
I am trying to upgrade from my ubuntu kernel 2.6.17.3 to 2.6.21.1 and I
have quite a bunch of problems with suspend/resume, both to disk and to
ram. I have reported the s2ram problem in a separate message (search for
a follow-up to the thread with subject "[patch 00/69] -stable review".
Hi Al,
On Wed, 23 May 2007 08:04:50 +0100 Al Viro <[EMAIL PROTECTED]> wrote:
>
> On Wed, May 23, 2007 at 05:01:55PM +1000, Stephen Rothwell wrote:
> > Make some offending drivers depend on it and set
> > CONFIG_ARCH_NO_VIRT_TO_BUS for ppc64 so that we don't build those drivers.
>
> Seeing how few
* Hemmann, Volker Armin <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I wanted to mail earlier, but I had always something get in my way.
>
> I used cfs v13 since you announced it. Since patching the kernel
> (2.6.21.1) with cfs v13 I did the following things;
[...]
> So far I am pretty satisfied. I
> > > Interesting... How do you deal with mount propagation and things like
> > > mount --move?
> >
> > Moving (or doing other mount operations on) an ancestor shouldn't be a
> > problem. Moving this mount itself is not allowed, and neither is
> > doing bind or pivot_root. Maybe bind could be
On Wed, 23 May 2007 09:09:00 +0200
Romano Giannetti <[EMAIL PROTECTED]> wrote:
> Will try to reboot with clocksource=acpi_pm, althoughI think that this
> is the one I'm using.
you can see that with:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
--
Paolo Ornati
Hi,
Yeah, that's racy: once we've sent the signal, the kernel thread can write
NULL to srvTcp->tsk at any time.
Yes, here is another patch :
diff -ur linux/fs/cifs/connect.c linux.new/fs/cifs/connect.c
--- linux/fs/cifs/connect.c 2007-05-23 10:59:13.0 +
+++
From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Wed, 23 May 2007 17:01:55 +1000
> Make some offending drivers depend on it and set
> CONFIG_ARCH_NO_VIRT_TO_BUS for ppc64 so that we don't build those drivers.
>
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
Acked-by: David S. Miller
From: Al Viro <[EMAIL PROTECTED]>
Date: Wed, 23 May 2007 08:04:50 +0100
> On Wed, May 23, 2007 at 05:01:55PM +1000, Stephen Rothwell wrote:
> > Make some offending drivers depend on it and set
> > CONFIG_ARCH_NO_VIRT_TO_BUS for ppc64 so that we don't build those drivers.
>
> Seeing how few
Hi,
I wanted to mail earlier, but I had always something get in my way.
I used cfs v13 since you announced it. Since patching the kernel (2.6.21.1)
with cfs v13
I did the following things;
- big backup of home onto tape and restoring it after changing to reiser4
(yes, I know the threads
(resent, using gmail)
On Mon, 2007-05-21 at 14:25 -0700, Chris Wright wrote:
> * Linus Torvalds ([EMAIL PROTECTED]) wrote:
> > On Mon, 21 May 2007, Chuck Ebbert wrote:
> > >
> > > What happened to:
> > >
> > > "Fix ACPI suspend / device suspend ordering problem"
> > >
On Tue, May 22 2007, Christoph Lameter wrote:
> On Wed, 23 May 2007, Srihari Vijayaraghavan wrote:
>
> > (If you want me to test it with other slub or kernel debug options please
> > let
> > me know. It just takes a lot of time to eliminate the variables, if there
> > are
> > problems.)
>
>
(changing email. My employer server adds a stupid and malformed
disclaimer, so that vger refuses the post. Oh well. I will no trim the
quot to my original message so that it's here for anyone).
On Tue, 2007-05-22 at 15:07 -0700, Linus Torvalds wrote:
>
> On Tue, 22 May 2007, Romano Giannetti
On Wed, May 23, 2007 at 05:01:55PM +1000, Stephen Rothwell wrote:
> Make some offending drivers depend on it and set
> CONFIG_ARCH_NO_VIRT_TO_BUS for ppc64 so that we don't build those drivers.
Seeing how few targets _do_ have that, I'd invert the that. I.e. have
HAS_VIRT_TO_BUS in
On Wed, May 23, 2007 at 08:36:04AM +0200, Miklos Szeredi wrote:
> > Interesting... How do you deal with mount propagation and things like
> > mount --move?
>
> Moving (or doing other mount operations on) an ancestor shouldn't be a
> problem. Moving this mount itself is not allowed, and neither
Make some offending drivers depend on it and set
CONFIG_ARCH_NO_VIRT_TO_BUS for ppc64 so that we don't build those drivers.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig|3 +++
drivers/atm/Kconfig |8
drivers/block/Kconfig |
On Wednesday 23 May 2007 12:56 am, Paul Mundt wrote:
> On Wed, May 23, 2007 at 12:25:44AM -0400, Rob Landley wrote:
> >mv arm cris blackfin parisc powerpc s390 x86_64 uml arch
>
> You missed sh, mips, fujitsu/frv, m68k, ia64, i386, and sparc.
Yup. I'll add 'em to the next pass. Thanks.
401 - 500 of 1026 matches
Mail list logo
