Stephen Smalley <[EMAIL PROTECTED]> wrote:
> Right, the latter is reasonable.
> Requires adding the class and permission definition to
> policy/flask/security_classes and policy/flask/access_vectors and then
> regenerating the kernel headers from those files, ala:
> svn co http://oss.tresys.com/
On Wed, 9 Jan 2008 18:48:14 +
Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 09, 2008 at 01:36:21PM -0500, Jeff Layton wrote:
> > I don't see a good alternative though. We need to be able to drop
> > the and check the refcount in nlmsvc_unlink_block. That function is
> > called fro
Jan Beulich wrote:
That's somewhat ugly, as it will need to be undone/modified for Dom0 and
physical device access support. Jan
Yes, I know, but its a quick workaround for a silent change in
hypervisor behaviour.
The proper fix would probably mask them out of the supported_pte_flags,
but
> Probing vmalloc faults is _really_ tricky : it also implies that the
> handler (let's call it probe) connected to the probe point (marker or
> kprobe) should _never_ cause a vmalloc page fault,
That is why vmalloc_sync_all() was invented. It might make sense
to just call that on kprobe registr
On Tue, 2008-01-08 at 23:07 +0900, FUJITA Tomonori wrote:
> CC'ed Jes,
>
> On Tue, 8 Jan 2008 14:15:53 +0300
> Evgeniy Dushistov <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Nov 25, 2007 at 01:24:25PM +0200, James Bottomley wrote:
> > > This is a bit of a rash of bug fixes. The qla1280 is actually
Hello,
I found this kconfig info on kernel page size:
'8KB and 64KB work quite well, since Sparc ELF sections provide for up to 64KB
alignment.'
so I thought I'll give it a try. I tested 2.6.24-rc7 and it stopped right after
'Remapping the kernel ... done'
At first I wanted to bisect
On Wed, Jan 09, 2008 at 03:44:04PM +0530, Sudhir Kumar wrote:
> Hi Andrew,
> Build fails on my Power Machine with following error message.
>
>
> HOSTLD arch/powerpc/boot/dtc
> WRAParch/powerpc/boot/zImage.pseries
> WRAParch/powerpc/boot/zImage.pmac
> strip -s -R .comment vmlinux -o ar
On Mon, 2008-01-07 at 20:06 +0200, Pekka J Enberg wrote:
> Hi Matt,
>
> On Sun, 6 Jan 2008, Matt Mackall wrote:
> > I don't have any particular "terrible" workloads for SLUB. But my
> > attempts to simply boot with all three allocators to init=/bin/bash in,
> > say, lguest show a fair margin for
On Wed, 9 Jan 2008, Yinghai Lu wrote:
> +#ifdef CONFIG_FLAT_NODE_MEM_MAP
> /* Initialize final allocator for a zone */
> -void __init setup_node_zones(int nodeid)
> +static void __init setup_node_zones(int nodeid)
> {
> unsigned long start_pfn, end_pfn, memmapsize, limit;
>
> @@ -244,14
On Wed, 2008-01-09 at 18:56 +, David Howells wrote:
> Stephen Smalley <[EMAIL PROTECTED]> wrote:
>
> > Right, the latter is reasonable.
> > Requires adding the class and permission definition to
> > policy/flask/security_classes and policy/flask/access_vectors and then
> > regenerating the ke
On Tue, 2008-01-08 at 13:10 -0800, [EMAIL PROTECTED] wrote:
> Form a single percpu.h from percpu_32.h and percpu_64.h. Both are now pretty
> small so this is simply adding them together.
I guess I just don't really see the point of moving the code around like
this. Before, it would have been eas
On Wed, 2008-01-09 at 10:30 -0800, Yinghai Lu wrote:
>
> [PATCH] x86_64: cleanup setup_node_zones called by paging_init v2
>
> setup_node_zones calcuates some variable but only use them when
> FLAT_NODE_MEM_MAP is set
>
> so change the MACRO postion to avoid calculating.
>
> also change it to s
On Wed, 9 Jan 2008, Dave Hansen wrote:
> On Tue, 2008-01-08 at 13:10 -0800, [EMAIL PROTECTED] wrote:
> > Form a single percpu.h from percpu_32.h and percpu_64.h. Both are now pretty
> > small so this is simply adding them together.
>
> I guess I just don't really see the point of moving the code
Hi Andrew,
On Sat 22-12-07 00:12:06, Andrew Morton wrote:
> On Thu, 20 Dec 2007 18:51:04 +0100 Jan Kara <[EMAIL PROTECTED]> wrote:
>
> > Although we don't allow writes over s_maxbytes, it can happen that a file's
> > size is larger than s_maxbytes. For example we can write the file from a
> > c
On Wed, 2008-01-09 at 11:31 -0800, Christoph Lameter wrote:
> Well this is only the first patchset. The next one will unify this even
> more (and make percpu functions work consistent between the two arches)
> but it requires changes to the way the %gs register is used in
> x86_64. So we only do
On Wed, 2008-01-09 at 18:21 +, Christoph Hellwig wrote:
> On Wed, Jan 09, 2008 at 01:18:44PM -0500, Pavel Roskin wrote:
> > notification without patching the kernel. But if no such solution is
> > found, I would also support reverting the patch that removed fault
> > notifiers on i386.
>
> W
On Wed, 9 Jan 2008 11:41:49 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i agree. There a few practical complication on x86: the
> do_page_fault() function is currently excluded from kprobe probing,
> for recursion reasons. handle_mm_fault() can be probed OTOH - but
> that does not catch vmalloc
> I have been reading about kprobes and one thing particularly bothers me
> in the case of mmio-trace. The probe will actually service the page
> fault, therefore it should be able force do_page_fault() to return at
> the probe point. I could not figure out a way to do that.
>
> Is it possible to
On Wed, 9 Jan 2008, Dave Hansen wrote:
> Then I really think this particular patch belongs in that other patch
> set. Here, it makes very little sense, and it's on the end anyway.
It makes sense in that both percpu_32/64 are very small as a result of
earlier patches and so its justifiable to pu
Takashi Iwai wrote:
Thanks. Then the possible reason might be the registers that don't
appear in this proc output, such as GPIO.
Could you try the patch below with the latency patch (you reverted) in
rc7?
Using rc7:
hda_intel.c(rc6) + patch for sigmatel.c: sound works
hda_intel.c(rc7) +
On Tue, 2008-01-08 at 20:58 +0100, Paolo Ciarrocchi wrote:
> On Jan 8, 2008 5:40 PM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> So I cooked up the following patch (probably mangled, just to give you
> a rough idea of what I did):
> diff --git a/arch/arm/common/rtctime.c b/arch/arm/common/rtctime.c
>
On Jan 9, 2008 2:53 PM, Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
> On Jan 9, 2008 1:25 PM, Theodore Tso <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
> > > Actually you can force Windows to accept a hardware clock in UTC:
> > > HKEY_LOCAL_MA
I agree with your points. I thought about making it display both.
But I didn't want to worry about breaking scripts that parse console
logs or whatever. Personally I don't think I've ever found the ppid
in that display useful in debugging a ptrace issue. I don't have any
special opinions about t
Pierre Ossman <[EMAIL PROTECTED]> writes:
> Marvell tend to not have a one true firmware, but one for each device,
> so you might end up having to dig out the ones shipped with the
> device.
I finally got these firmware files from the manufacturer; still, with
2.6.24-rc6 and the new firmware files
On Thu, Jan 10, 2008 at 06:58:23AM +1100, Benjamin Herrenschmidt wrote:
> It's a sane thing to do, Christoph, I don't think it's a unreasonable
> request to put the hooks back in.
As said a few times before there's simply no way we're going to put
exactly that crap back. For one the patch removed
On Wed, 09 Jan 2008 10:18:11 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Zachary Amsden wrote:
> >
> > I'm speaking specifically in terms of 64-bit platforms here.
> > Shouldn't we unconditionally drop outb_p doing extra port I/O on
> > 64-bit architectures? Especially considering they d
On Thu, 2008-01-10 at 06:58 +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2008-01-09 at 18:21 +, Christoph Hellwig wrote:
> > On Wed, Jan 09, 2008 at 01:18:44PM -0500, Pavel Roskin wrote:
> > > notification without patching the kernel. But if no such solution is
> > > found, I would also supp
On Wed, 9 Jan 2008 18:48:00 +0100
> And after all that's still by far the most common system call
> (not only for databases; i profiled this using systemtap in some
> loads some time ago and it usually came up with >50%)
> and quite important for many workloads.
>
btw be careful with this; the X
On Wed, Jan 09, 2008 at 03:24:16PM -0500, Pavel Roskin wrote:
> I just assumed (wrongly, as it seems) that the API change didn't remove
> any useful functionality.
No, this was exactly the correct assumption. Out of tree modules simply
don't count.
> The problem is that mmiotrace only makes sens
Anton Salikhmetov wrote:
From: Anton Salikhmetov <[EMAIL PROTECTED]>
I would like to propose my solution for the bug #2645 from the kernel bug
tracker:
http://bugzilla.kernel.org/show_bug.cgi?id=2645
The Open Group defines the behavior of the mmap() function as follows.
The st_ctime and st_m
On Wed, 2008-01-09 at 00:28 +0100, Andi Kleen wrote:
> > I have no problem with that, but if we want to make it buildable as a
> > module, the call to get_kprobe() needs to be replaced with some other
> > gcc-inline-defeating mechanism, or we need to export get_probe(). I
>
> It's still unclear w
[PATCH] x86_64: cleanup setup_node_zones called by paging_init v3
setup_node_zones calcuates some variables but only use them when
FLAT_NODE_MEM_MAP is set
so change the MACRO postion to avoid calculating.
also change it to static, rename it to flat_setup_node_zones
Signed-off-by: Yinghai Lu <
On Wed, Jan 09, 2008 at 12:25:59PM -0800, Arjan van de Ven wrote:
> On Wed, 9 Jan 2008 18:48:00 +0100
> > And after all that's still by far the most common system call
> > (not only for databases; i profiled this using systemtap in some
> > loads some time ago and it usually came up with >50%)
> >
On Wed, 2008-01-09 at 20:26 +, Christoph Hellwig wrote:
> On Wed, Jan 09, 2008 at 03:24:16PM -0500, Pavel Roskin wrote:
> > I just assumed (wrongly, as it seems) that the API change didn't remove
> > any useful functionality.
>
> No, this was exactly the correct assumption. Out of tree modul
This patch is different than the first patch I sent out.
This one just sends an IPI to all CPUS that don't check in after 1 sec.
Sometimes cpu_idle_wait gets stuck because it might miss CPUS that are
already in idle, have no tasks waiting to run and have no interrupts
going to them. This is comm
On Wed, 09 Jan 2008 20:26:44 GMT, Christoph Hellwig said:
> > Exactly. In MadWifi, they are inlined on i386 and x86_64, and I cannot
> > ask every user with an unsupported card to get a Mac.
>
> Maybe it's time to do some simple xoring in the ioremap return value
> to force them not to do such s
On Mon, 07 Jan 2008 20:54:19 +0300
Anton Salikhmetov <[EMAIL PROTECTED]> wrote:
> This program showed that the msync() function had a bug:
> it did not update the st_mtime and st_ctime fields.
>
> The program shows appropriate behavior of the msync()
> function using the kernel with the proposed
Hi,
David P. Reed reed.com> writes:
> And actually, if I had looked at the /sys/bus/pnp definitions, rather
> than /proc/ioports, I would have noticed that port 80 was part of a
> PNP0C02 resource set. That means exactly one thing: ACPI says that
> port 80 is NOT free to be used, for delay
FASTCALL is defined empty in -mm, but UML is not compiled with
-mregparm=3 and so this breaks things (I noticed problems with
rwsem_down_write_failed).
Tried recompiling UML with -mregparm=3, but that resulted in a strange
failure immediately after startup:
|%G�%@: Invalid argument
What's up
On Tue, 8 Jan 2008, Rafael J. Wysocki wrote:
> Appended is what I managed to put together today.
>
> It probably still has some problems, but I'm not seeing them right now (too
> tired). At least, it doesn't break my system. ;-)
>
> Please review.
Okay, this seems to be better. I like the way
Andi Kleen wrote:
People tend to make jokes about optimizing the idle loop too, but they're
actually wrong. Exit latency for the idle loop is important -- it
decides how quickly you can react to load changes on idle CPUs.
For short udelays I suspect shorter exit latency is also moderately use
The /sys/devices/.../power/state files have been gone for a while
now, but I just noticed some documentation that still refers to
them. (Fortunately described as DEPRECATED and WILL REMOVE).
Time to remove that obsolete documentation too ...
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
On Wed, 09 Jan 2008 15:50:15 EST, Rik van Riel said:
> Could you explain (using short words and simple sentences) what the
> exact problem is?
>
> Eg.
>
> 1) program mmaps file
> 2) program writes to mmaped area
> 3) ??? <=== this part, in equally simple words :)
> 4) data loss
On Wed, Jan 09, 2008 at 01:00:38PM -0800, Roland Dreier wrote:
> .
> The reason this hasn't been an issue until now is that almost all
> drivers work correctly if the Altix code just sets the "flush" bit for
> memory allocated via the consistent/coherent allocators. However, if
> we want the d
Miklos Szeredi <[EMAIL PROTECTED]> writes:
> FASTCALL is defined empty in -mm, but UML is not compiled with
> -mregparm=3 and so this breaks things (I noticed problems with
> rwsem_down_write_failed).
>
> Tried recompiling UML with -mregparm=3, but that resulted in a strange
> failure immediately
On Wed, Jan 09, 2008 at 12:24:00PM -0800, Jim Keniston wrote:
> On Wed, 2008-01-09 at 00:28 +0100, Andi Kleen wrote:
> > > I have no problem with that, but if we want to make it buildable as a
> > > module, the call to get_kprobe() needs to be replaced with some other
> > > gcc-inline-defeating mec
Anton Salikhmetov wrote:
> From: Anton Salikhmetov <[EMAIL PROTECTED]>
>
> I would like to propose my solution for the bug #2645 from the kernel
bug tracker:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=2645
>
> The Open Group defines the behavior of the mmap() function as follows.
>
> The st_
> Miklos Szeredi <[EMAIL PROTECTED]> writes:
>
> > FASTCALL is defined empty in -mm, but UML is not compiled with
> > -mregparm=3 and so this breaks things (I noticed problems with
> > rwsem_down_write_failed).
> >
> > Tried recompiling UML with -mregparm=3, but that resulted in a strange
> > fail
On Wed, Jan 09, 2008 at 15:50:15 -0500, Rik van Riel wrote:
> > Specifically, the ctime and mtime time stamps do change
> > when modifying the mapped memory and do not change when
> > there have been no write references between the mmap()
> > and msync() system calls.
>
> As long as the ctime and
> What it wants to do is set strict ordering for the bus ... well, that is
> an attribute in the PCIe standard (it just happens to be the default one
> for a standard bus, whereas relaxed is the default for altix). However,
> set bus attribute strict would be a simple no-op for a standard bus
Hi,
thanks for your report.
> I'm using Debian unstable/sid/lenny with homemade kernel 2.6.23.12
> patched with tuxonice-3.0-rc3-for-2.6.23.9 and compiled with
> gcc version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4).
>
> My root file system is xfs which does not have "noatime" option.
>
> FASTCALL is useless and should not make a difference. It enables
> regparm on specific functions, but that should not make a difference
> if it works or not.
__down_write() in include/asm-x86/rwsem.h seems to assume, that the
semaphore pointer is passed in %eax down to rwsem_down_write_failed(),
On Wed, Jan 09, 2008 at 08:14:56PM +0100, Sam Ravnborg wrote:
> On Wed, Jan 09, 2008 at 03:44:04PM +0530, Sudhir Kumar wrote:
> > Hi Andrew,
> > Build fails on my Power Machine with following error message.
> >
> >
> > HOSTLD arch/powerpc/boot/dtc
> > WRAParch/powerpc/boot/zImage.pseries
>
On Wednesday, 9 of January 2008, David Brownell wrote:
> The /sys/devices/.../power/state files have been gone for a while
> now, but I just noticed some documentation that still refers to
> them. (Fortunately described as DEPRECATED and WILL REMOVE).
>
> Time to remove that obsolete documentatio
In gitx86:
commit 692effca950d7c6032e8e2ae785a32383e7af4a3
Author: John Reiser <[EMAIL PROTECTED]>
Date: Wed Jan 9 13:31:12 2008 +0100
STT_FUNC for assembler checksum and semaphore ops
...
Comments?
Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
Signed-off-by: Ingo Mol
On Wed, Jan 09, 2008 at 10:20:49PM +0100, Miklos Szeredi wrote:
> > Miklos Szeredi <[EMAIL PROTECTED]> writes:
> >
> > > FASTCALL is defined empty in -mm, but UML is not compiled with
> > > -mregparm=3 and so this breaks things (I noticed problems with
> > > rwsem_down_write_failed).
> > >
> > > T
On Tue, 2008-01-08 at 21:19 -0800, H. Peter Anvin wrote:
> Zachary Amsden wrote:
> >
> > BTW, it isn't ever safe to pass port 0x80 through to hardware from a
> > virtual machine; some OSes use port 0x80 as a hardware available scratch
> > register (I believe Darwin/x86 did/does this during boot).
On Thursday 10 January 2008 02:24:40 Paulo Marques wrote:
> Rusty Russell wrote:
> > Or better, rework all the name lookup interfaces, rather than having:
>
> Yes, there is some rework we can do here
Hi Paulo,
Yes, it just needs some thought...
> > extern int sprint_symbol(char *buff
ommit 67a385d9ac12e5940989362333b8fa8511e2ec37
Author: Ingo Molnar <[EMAIL PROTECTED]>
Date: Wed Jan 9 13:31:08 2008 +0100
x86: fix up merge conflict
fix up kgdb merge conflict.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
diff --git a/include/asm-x86/system.h b/include
On Thursday 10 January 2008 05:16:57 Zach Brown wrote:
> > The latter. A ring is optimal for processing a huge number of requests,
> > but if you're really going to be firing off syslet threads all over the
> > place you're not going to be optimal anyway. And being able to point the
> > return va
On Wed, 09 Jan 2008 16:06:17 -0500
[EMAIL PROTECTED] wrote:
> On Wed, 09 Jan 2008 15:50:15 EST, Rik van Riel said:
>
> > Could you explain (using short words and simple sentences) what the
> > exact problem is?
>
> It's like this:
>
> Monday 9:04AM: System boots, database server starts up, mma
On Wednesday, 9 of January 2008, Alan Stern wrote:
> On Tue, 8 Jan 2008, Rafael J. Wysocki wrote:
>
> > Appended is what I managed to put together today.
> >
> > It probably still has some problems, but I'm not seeing them right now (too
> > tired). At least, it doesn't break my system. ;-)
> >
On Wed, 2008-01-09 at 15:42 -0500, Steven Rostedt wrote:
> This patch is different than the first patch I sent out.
> This one just sends an IPI to all CPUS that don't check in after 1 sec.
>
>
> Sometimes cpu_idle_wait gets stuck because it might miss CPUS that are
> already in idle, have no tas
Anton Salikhmetov wrote:
Since no reaction in LKML was recieved for this message it seemed
logical to suggest closing the bug #2645 as "WONTFIX":
http://bugzilla.kernel.org/show_bug.cgi?id=2645#c15
However, the reporter of the bug, Jacob Oestergaard, insisted the
solution to be resubmitted once
Rik van Riel wrote:
On Wed, 09 Jan 2008 16:06:17 -0500
[EMAIL PROTECTED] wrote:
On Wed, 09 Jan 2008 15:50:15 EST, Rik van Riel said:
Could you explain (using short words and simple sentences) what the
exact problem is?
It's like this:
Monday 9:04AM: System boots, database se
On Wed, Jan 09, 2008 at 10:20:49PM +0100, Miklos Szeredi wrote:
> > Miklos Szeredi <[EMAIL PROTECTED]> writes:
> >
> > > FASTCALL is defined empty in -mm, but UML is not compiled with
> > > -mregparm=3 and so this breaks things (I noticed problems with
> > > rwsem_down_write_failed).
> > >
> > > T
On Wed, 2008-01-09 at 13:00 -0800, Roland Dreier wrote:
> > What it wants to do is set strict ordering for the bus ... well, that is
> > an attribute in the PCIe standard (it just happens to be the default one
> > for a standard bus, whereas relaxed is the default for altix). However,
> > set
Zachary Amsden wrote:
According to Phoenix Technologies book "System BIOS for IBM PCs,
Compatibles and EISA Computers, 2nd Edition", the I/O port list gives
port 0080h R/W Extra page register (temporary storage)
Despite looking, I've never seen it documented anywhere else, but I
believe it
On Wed, Jan 09, 2008 at 11:09:48PM +0100, Björn Steinbrink wrote:
> On 2008.01.09 18:48:00 +0100, Andi Kleen wrote:
> > On Wed, Jan 09, 2008 at 05:30:18PM +0100, Ingo Molnar wrote:
> > > then you have a truly ancient x86.git repository ;-)
> >
> > I update only infrequently because frankly git's r
On Tue, 2008-01-08 at 11:39 +1100, Rusty Russell wrote:
> On Tuesday 08 January 2008 02:48:23 James Bottomley wrote:
> > We're always open to new APIs (or more powerful and expanded old ones).
> > The way we've been doing the sg_chain conversion is to slide API layers
> > into the drivers so sg_ch
On 2008.01.09 18:48:00 +0100, Andi Kleen wrote:
> On Wed, Jan 09, 2008 at 05:30:18PM +0100, Ingo Molnar wrote:
> > then you have a truly ancient x86.git repository ;-)
>
> I update only infrequently because frankly git's remote branch tracking
> is a mess. At least it doesn't really work for x86#m
On Wed, 9 Jan 2008, Miklos Szeredi wrote:
> FASTCALL is defined empty in -mm, but UML is not compiled with
> -mregparm=3 and so this breaks things (I noticed problems with
> rwsem_down_write_failed).
>
> Tried recompiling UML with -mregparm=3, but that resulted in a strange
> failure immediately
Christer Weinigel wrote:
On Wed, 09 Jan 2008 10:18:11 -0800
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
Zachary Amsden wrote:
I'm speaking specifically in terms of 64-bit platforms here.
Shouldn't we unconditionally drop outb_p doing extra port I/O on
64-bit architectures? Especially consider
Use a central kprobe_handle_fault() inline in kprobes.h to remove
all of the arch-dependant, practically identical implementations in
avr32, ia64, powerpc, s390, sparc64, and x86.
This patch removes the preempt_disable/enable pair around kprobe_running
which was originally added to avoid the asser
On Wed, Jan 09, 2008 at 05:06:33PM -0500, Rik van Riel wrote:
...
> >
> > Lather, rinse, repeat
Just verified this at one customer site; they had a db that was last backed up
in 2003 :/
>
> On the other hand, updating the mtime and ctime whenever a page is dirtied
> also does not work right
On Wed, Jan 09, 2008 at 02:35:55PM -0800, Harvey Harrison wrote:
> On Wed, 2008-01-09 at 23:28 +0100, Andi Kleen wrote:
>
> > Do you have a simple recipe to just update from the the remote branch,
> > assuming there are no local changes or local branches?
> >
> > -Andi
>
> For staying up to dat
On Wed, 2008-01-09 at 22:21 +0100, Andi Kleen wrote:
> On Wed, Jan 09, 2008 at 12:24:00PM -0800, Jim Keniston wrote:
> > On Wed, 2008-01-09 at 00:28 +0100, Andi Kleen wrote:
> > > > I have no problem with that, but if we want to make it buildable as a
> > > > module, the call to get_kprobe() needs
On Wed, Jan 09, 2008 at 02:12:40PM -0600, Matt Mackall wrote:
> You'll need to change the prototype, the unlocked version doesn't take
> an inode. And you'll need to make sure that nothing in the function uses
> the inode, which I think Andi forgot to mention.
This old chestnut again. Perhaps we
On Wed, Jan 09, 2008 at 10:40:26PM +, Alasdair G Kergon wrote:
> On Wed, Jan 09, 2008 at 02:12:40PM -0600, Matt Mackall wrote:
> > You'll need to change the prototype, the unlocked version doesn't take
> > an inode. And you'll need to make sure that nothing in the function uses
> > the inode, w
Hi Matt,
On Wed, 9 Jan 2008, Matt Mackall wrote:
> I kicked this around for a while, slept on it, and then came up with
> this little hack first thing this morning:
>
>
> slob: split free list by size
>
[snip]
> And the results are fairly miraculous, so please double-check them on
Hello,
as hibernation (swsusp) started to work with my CPU, I found that my Turtle
Beach Malibu stops working after resume from hibernation. It's caused by fact
that the card is not enabled on the pnp layer during resume - and thus card
registers are inaccessible (reads return FFs, writes go now
On Wed, Jan 09, 2008 at 11:46:03PM +0100, Andi Kleen wrote:
> struct inode *inode = file->f_dentry->d_inode;
And oops if that's not defined?
Alasdair
--
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Mor
While trying to gain some insight into a disk issue, I found that
blktrace/blkparse was giving me bogus traces -- I was seeing requests
complete before they were even dispatched or queued even! I had thought
that maybe this was an issue with SMP on the box, but when running with
'maxcpus=1', it tol
On Wed 2008-01-09 22:55:09, Rafael J. Wysocki wrote:
> On Wednesday, 9 of January 2008, David Brownell wrote:
> > The /sys/devices/.../power/state files have been gone for a while
> > now, but I just noticed some documentation that still refers to
> > them. (Fortunately described as DEPRECATED and
On Wed, 9 Jan 2008, Rafael J. Wysocki wrote:
> > In dpm_resume() you shouldn't need to use dpm_list_mtx at all, because
> > the list_move_tail() comes before the resume_device(). It's the same
> > as in dpm_power_up().
>
> Still, device_pm_schedule_removal() can (in theory) be called concurrentl
On Wed, 2008-01-09 at 23:28 +0100, Andi Kleen wrote:
> Do you have a simple recipe to just update from the the remote branch,
> assuming there are no local changes or local branches?
>
> -Andi
For staying up to date I use the following:
# Add Linus's tree as a remote
git remote --add linus
git
Hello again,
I've tried a little bit more with the XTS and the LRW Cipher, XTS is
unuseable it crashes with the kernel panic below. LRW doenst work in
2.6.23.12 with/without the patch from
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg244470.html
or with 2.6.24-rc7
My System i
Alasdair G Kergon wrote:
On Wed, Jan 09, 2008 at 11:46:03PM +0100, Andi Kleen wrote:
struct inode *inode = file->f_dentry->d_inode;
And oops if that's not defined?
Isn't this basically identical to what was being passed in to .ioctl()?
Chris
--
To unsubscribe from this list: send the lin
On Thu, 2008-01-10 at 00:43 +0200, Pekka J Enberg wrote:
> Hi Matt,
>
> On Wed, 9 Jan 2008, Matt Mackall wrote:
> > I kicked this around for a while, slept on it, and then came up with
> > this little hack first thing this morning:
> >
> >
> > slob: split free list by size
> >
>
>
On Thu, 10 Jan 2008, Rusty Russell wrote:
>
> I'd have to read his original statement, but eventfd doesn't build up state,
> so I think it qualifies.
How about you guys battle it out by giving an example program usign the
interface?
Here's a favourite really simple load of mine:
- do the e
On Wed, 09 Jan 2008 12:11:20 +0100
Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2008-01-08 at 16:27 +0100, Mike Galbraith wrote:
> > On Tue, 2008-01-08 at 16:21 +0100, Mike Galbraith wrote:
> > > On Tue, 2008-01-08 at 03:38 -0800, Andrew Morton wrote:
> > > >
> > > > Well. From your ea
On Wed, 09 Jan 2008 16:42:34 +0100
Pierre Peiffer <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This very small patch:
> ipc-convert-handmade-min-to-min.patch
> introduces a new warning when compiling the -mm kernel:
>
> .../linux-2.6.24-rc6-mm1/ipc/msg.c: In function `do_msgrcv':
> .../linux-2.6.24-
On Wed, 9 Jan 2008, Linus Torvalds wrote:
>
> Try this with and without a "echo 3 > /proc/sys/vm/drop_caches" in
> between. Both are real and relevant usage cases, I think.
Side note, for me the difference on my home directory for the cached vs
uncached case is 5 seconds vs 5 minutes. I like
On Thu, 10 Jan 2008, Rusty Russell wrote:
> On Thursday 10 January 2008 05:16:57 Zach Brown wrote:
> > > The latter. A ring is optimal for processing a huge number of requests,
> > > but if you're really going to be firing off syslet threads all over the
> > > place you're not going to be optimal
> arch/avr32/mm/fault.c | 21 +
> arch/ia64/mm/fault.c| 24 +---
> arch/powerpc/mm/fault.c | 25 +
> arch/s390/mm/fault.c| 25 +
> arch/sparc64/mm/fault.c | 23 +--
> arc
Here's the latest version of dm-loop, for comparison.
To try it out,
ln -s dmsetup dmlosetup
and supply similar basic parameters to losetup.
(using dmsetup version 1.02.11 or higher)
Alasdair
From: Bryn Reeves <[EMAIL PROTECTED]>
This implements a loopback target for device mapper allowing a
From: Mariusz Kozlowski <[EMAIL PROTECTED]>
Date: Wed, 9 Jan 2008 20:14:16 +0100
> So ... am I doing something wrong here or something is broken?
I know that non-8K page sizes are broken but haven't had time
to go fix it, sorry.
--
To unsubscribe from this list: send the line "unsubscribe linux-k
On 2008.01.09 23:41:42 +0100, Andi Kleen wrote:
> On Wed, Jan 09, 2008 at 02:35:55PM -0800, Harvey Harrison wrote:
> > On Wed, 2008-01-09 at 23:28 +0100, Andi Kleen wrote:
> >
> > > Do you have a simple recipe to just update from the the remote branch,
> > > assuming there are no local changes or
On Wednesday, 9 of January 2008, Alan Stern wrote:
> On Wed, 9 Jan 2008, Rafael J. Wysocki wrote:
>
> > > In dpm_resume() you shouldn't need to use dpm_list_mtx at all, because
> > > the list_move_tail() comes before the resume_device(). It's the same
> > > as in dpm_power_up().
> >
> > Still, d
This adds the task comm and pid to the trace output. This gives the
output like:
CPU 0: sshd:2605 [] remove_wait_queue+0xc/0x4a <--
[] free_poll_entry+0x1e/0x2a
CPU 2: bash:2610 [] tty_check_change+0x9/0xb6 <--
[] tty_ioctl+0x59f/0xcdd
CPU 0: sshd:2605 [] _spin_lock_irqsave+0xe/0x81 <--
[] remo
201 - 300 of 442 matches
Mail list logo
