On Saturday 15 September 2007, Andrew Morton wrote:
> On Sat, 15 Sep 2007 11:50:21 -0700 David Brownell <[EMAIL PROTECTED]> wrote:
>
> > > On Thu, 06 Sep 2007 18:23:22 -0400 Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> > >
> > > > # ls -li
> > > > total 0
> > > > 4026532007 -r--r--r-- 1 root root 0
By default, we allocate DMA buffers when actually reading from the video
capture device. On a system with 128MB or 256MB of ram, it's very easy
for that memory to quickly become fragmented. We've had users report
having 30+MB of memory free, but the cafe_ccic driver is still unable to
allocate
The use of vector in ia64_machine_kexec() seems spurios,
and removing it simplifies the code slightly.
As suggested by Alex Williamson <[EMAIL PROTECTED]>
Cc: Alex Williamson <[EMAIL PROTECTED]>
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/arch/ia64/kernel/machine_kexec.c
Hi,
while trying to compile 2.6.23-rc6-mm1 I came across the following
build error:
[EMAIL PROTECTED]:/usr/src/linux-2.6.23-rc6-mm1> make modules
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
:1389:2: warning: #warning syscall revokeat
On Tue, 2007-09-18 at 22:30 -0700, H. Peter Anvin wrote:
> Huang, Ying wrote:
> > Known issues:
> >
> > - The hd0_info and hd1_info are deleted from the zero page. Additional
> > work should be done for this? Or this is unnecessary (because no new
> > fields will be added to zero page)?
> >
Huang, Ying wrote:
> Known issues:
>
> - The hd0_info and hd1_info are deleted from the zero page. Additional
> work should be done for this? Or this is unnecessary (because no new
> fields will be added to zero page)?
>
For backwards compatibility, they should be marked as there for the
On Sep 18, 2007, at 19:44:59, Satyam Sharma wrote:
On Thu, 6 Sep 2007, Kyle Moffett wrote:
On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
The question of how to protect against
On Tue, Sep 18, 2007 at 06:06:52PM -0700, Linus Torvalds wrote:
> > especially as the Linux
> > kernel limitations in this area are well known. There's no "16K mess"
> > that SGI is trying to clean up here (and SGI have offered both IA64 and
> > x86_64
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix hda help text typo.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
sound/pci/Kconfig |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2.6.23-rc6-mm1.orig/sound/pci/Kconfig
+++ linux-2.6.23-rc6-mm1/sound/pci/Kconfig
@@ -506,7
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix kgdb help text typos, grammar, config symbol names, and indentation.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
lib/Kconfig.kgdb | 42 --
1 file changed, 20 insertions(+), 22 deletions(-)
---
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix typos in uniform watchdog driver help text.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/watchdog/core/Kconfig |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.23-rc6-mm1.orig/drivers/watchdog/core/Kconfig
On 09/19/2007 06:33 AM, Linus Torvalds wrote:
On Wed, 19 Sep 2007, Rene Herman wrote:
I do feel larger blocksizes continue to make sense in general though. Packet
writing on CD/DVD is a problem already today since the hardware needs 32K or
64K blocks and I'd expect to see more of these and
This patch allows relay channels to be reset i.e. unconsumed.
Basically allows a 'rewind' function for flight-recorder tracing.
Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
Signed-off-by: David Wilder <[EMAIL PROTECTED]>
---
Documentation/filesystems/relay.txt | 11 ++
Trace - Provides tracing primitives
Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
Signed-off-by: Martin Hunt <[EMAIL PROTECTED]>
Signed-off-by: David Wilder <[EMAIL PROTECTED]>
---
Documentation/trace/src/Makefile |7 +
Documentation/trace/src/README | 18 +
These patches provide a kernel tracing interface called "trace".
The motivation for "trace" is to:
- Provide a simple set of tracing primitives that will utilize the high-
performance and low-overhead of relayfs for passing traces data from
kernel to user space.
- Provide a common user
On Wed, 19 Sep 2007, Rene Herman wrote:
>
> I do feel larger blocksizes continue to make sense in general though. Packet
> writing on CD/DVD is a problem already today since the hardware needs 32K or
> 64K blocks and I'd expect to see more of these and similiar situations when
> flash gets
On 09/19/2007 05:50 AM, Linus Torvalds wrote:
On Wed, 19 Sep 2007, Rene Herman wrote:
Well, not so sure about that. What if one of your expected uses for example is
video data storage -- lots of data, especially for multiple streams, and needs
still relatively fast machinery. Why would you
Christoph Lameter wrote:
>
> + if (is_vmalloc_addr(word))
> + page = vmalloc_to_page(word)
^^
Missing ' ; '
> + else
> + page = virt_to_page(word);
> +
> + zone = page_zone(page);
> return
Andi Kleen wrote:
> At least the Xen port seems to have specific requirements
> and essentially only work on xen-unstable (?) [or at least
> some very new Xen version] which probably very few
> people use.
>
Only on 64-bit hosts, because of bugs in the 64-bit compat layer.
32-on-32 and
On Wed, 19 Sep 2007, Rene Herman wrote:
>
> Well, not so sure about that. What if one of your expected uses for example is
> video data storage -- lots of data, especially for multiple streams, and needs
> still relatively fast machinery. Why would you care for the overhead af
> _small_ blocks?
On Tue, Sep 18, 2007 at 10:22:43PM +0200, Ingo Molnar wrote:
> (I have not tested the group scheduling bits but perhaps Srivatsa would
> like to do that?)
Ingo,
I plan to test it today and send you any updates that may be
required.
--
Regards,
vatsa
-
To unsubscribe from this list:
Make vunmap return the page array that was used at vmap. This is useful
if one has no structures to track the page array but simply stores the
virtual address somewhere. The disposition of the page array can be
decided upon after vunmap. vfree() may now also be used instead of
vunmap which will
On 09/18/2007 09:44 PM, Linus Torvalds wrote:
Nobody sane would *ever* argue for 16kB+ blocksizes in general.
Well, not so sure about that. What if one of your expected uses for example
is video data storage -- lots of data, especially for multiple streams, and
needs still relatively fast
This adds a new gfp flag
__GFP_VFALLBACK
If specified during a higher order allocation then the system will fall
back to vmap and attempt to create a virtually contiguous area instead of
a physically contiguous area. In many cases the virtually contiguous area
can stand in for the physically
Sometimes we need to figure out which vmalloc address is in use
for a certain page struct. There is no easy way to figure out
the vmalloc address from the page struct. So simply search through
the kernel page table to find the address. This is a fairly expensive
process. Use sparingly (or provide
SLAB_VFALLBACK can be specified for selected slab caches. If fallback is
available then the conservative settings for higher order allocations are
overridden. We then request an order that can accomodate at mininum
100 objects. The size of an individual slab allocation is allowed to reach
up to
Sparsemem currently attempts first to do a physically contiguous mapping
and then falls back to vmalloc. The same thing can now be accomplished
using GFP_VFALLBACK.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/sparse.c | 23 +++
1 file changed, 3
Virtual fallbacks are rare and thus subtle bugs may creep in if we do not
test the fallbacks. CONFIG_VFALLBACK_ALWAYS makes all GFP_VFALLBACK
allocations fall back to virtual mapping.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
lib/Kconfig.debug | 11 +++
mm/page_alloc.c
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
fs/dcache.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6/fs/dcache.c
===
--- linux-2.6.orig/fs/dcache.c 2007-09-18 18:42:19.0 -0700
If we are in an interrupt context then simply defer the free via a workqueue.
In an interrupt context it is not possible to use vmalloc_addr() to determine
the vmalloc address. So add a variant that does that too.
Removing a virtual mappping *must* be done with interrupts enabled
since tlb_xx
If bit waitqueue is passed a virtual address then it must use
vmalloc_to_page instead of virt_to_page to get to the page struct.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
kernel/wait.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
Index:
This is in particular useful for large I/Os because it will allow > 100
allocs from the SLUB fast path without having to go to the page allocator.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
fs/buffer.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index:
Currently we have to use vmalloc for the zone wait table possibly generating
the need to create lots of TLBs to access the tables. We can now use
GFP_VFALLBACK to attempt the use of a physically contiguous page that can then
use the large kernel TLBs.
Signed-off-by: Christoph Lameter <[EMAIL
In an interrupt context we cannot wait for the vmlist_lock in
__get_vm_area_node(). So use a trylock instead. If the trylock fails
then the atomic allocation will fail and subsequently be retried.
This only works because the flush_cache_vunmap in use for
allocation is never performing any IPIs in
This test is used in a couple of places. Add a version to vmalloc.h
and replace the other checks.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/cxgb3_offload.c |4 +---
fs/ntfs/malloc.h |3 +--
fs/proc/kcore.c |2 +-
Avoid expensive lookups of virtual addresses from page structs by
storing the vmalloc address in page->private. We can then avoid
the vmalloc_address() in the get__page() functions and
simply return page->private.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/page_alloc.c
We already have page table manipulation for vmalloc in vmalloc.c. Move the
vmalloc_to_page() function there as well. Also move the related definitions
from include/linux/mm.h.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
include/linux/mm.h |2 --
include/linux/vmalloc.h |
Currently there is a strong tendency to avoid larger page allocations in
the kernel because of past fragmentation issues and the current
defragmentation methods are still evolving. It is not clear to what extend
they can provide reliable allocations for higher order pages (plus the
definition of
Make vmalloc functions work the same way as kfree() and friends that
take a const void * argument.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
include/linux/vmalloc.h | 10 +-
mm/vmalloc.c| 16
2 files changed, 13 insertions(+), 13
The page array is repeatedly indexed both in vunmap and vmalloc_area_node().
Add a temporary variable to make it easier to read (and easier to patch
later).
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/vmalloc.c | 16 +++-
1 file changed, 11 insertions(+), 5
cache_nice_tries and flags entry do not appear in proc fs sched_domain
directory,
because ctl_table entry is skipped.
This patch fix the issue.
Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
--- linux-2.6.23-rc6/kernel/sched.c 2007-09-18 23:47:07.0 -0400
+++ b/kernel/sched.c
This patch defines a 32-bit boot protocol and adds corresponding
document. It is based on the proposal of Peter Anvin.
Known issues:
- The hd0_info and hd1_info are deleted from the zero page. Additional
work should be done for this? Or this is unnecessary (because no new
fields will be
This patch add a field of 64-bit physical pointer to NULL terminated
single linked list of struct setup_data to real-mode kernel
header. This is used as a more extensible boot parameters passing
mechanism.
This patch has been tested against 2.6.23-rc6-mm1 kernel on x86_64. It
is based on the
On Tue, 18 Sep 2007 17:25:31 -0700 Avantika Mathur <[EMAIL PROTECTED]> wrote:
> +
> +__u16 crc16(__u16 crc, __u8 const *buffer, size_t len)
And is we really really have to do this, then the ext4-private crc16()
should have static scope.
-
To unsubscribe from this list: send the line
On Tue, 18 Sep 2007 17:25:31 -0700 Avantika Mathur <[EMAIL PROTECTED]> wrote:
> +#if !defined(CONFIG_CRC16)
> +/** CRC table for the CRC-16. The poly is 0x8005 (x16 + x15 + x2 + 1) */
> +__u16 const crc16_table[256] = {
> + 0x, 0xC0C1, 0xC181, 0x0140, 0xC301, 0x03C0, 0x0280, 0xC241,
> +
On Sat, 2007-08-25 at 11:13 +0200, Olaf Hering wrote:
> The atyfb does not work on my 233MHz PowerBook with Mach64 LP, when the
> kernel is booted from firmware. aty_ld_pll_ct() returns 0x22 and xtal
> remains at 14.31818. When booted from MacOS, aty_ld_pll_ct() returns 0x3c
> and xtal is changed
On Fri, 14 Sep 2007 11:35:34 BST, Denys Vlasenko said:
> Hi Tapio,
>
> You are the author of these files. Are you still maintaining them?
> If not, do you know who is the current maintainer?
> These two object files hold the biggest data objects in the whole Linux kernel
> after lockdep:
>
>
On Wed, 19 Sep 2007 08:05:32 +0530 (IST) Satyam Sharma wrote:
> Hi Andries,
>
>
> On Wed, 19 Sep 2007, Andries E. Brouwer wrote:
> >
> > On Wed, Sep 19, 2007 at 05:48:28AM +0530, Satyam Sharma wrote:
> >
> > > > > On the other hand, this filesystem announces itself as UDF
> > > > > ("CD-RTOS"
On Tue, 2007-09-18 at 18:06 -0700, Linus Torvalds wrote:
> There is *no* valid reason for 16kB blocksizes unless you have legacy
> issues.
That's not correct.
> The performance issues have nothing to do with the block-size, and
We must be thinking of different performance issues.
> should be
Sorry... I sent old version...it returns -ENOSYS.
Andrew-san, please replace.
Goto-san, please confirm and ack.
==
Now, arch dependent code around CONFIG_MEMORY_HOTREMOVE is a mess.
This patch cleans up them.
- For !CONFIG_MEMORY_HOTREMOVE, add generic no-op remove_memory(),
which returns
Hi Andries,
On Wed, 19 Sep 2007, Andries E. Brouwer wrote:
>
> On Wed, Sep 19, 2007 at 05:48:28AM +0530, Satyam Sharma wrote:
>
> > > > On the other hand, this filesystem announces itself as UDF
> > > > ("CD-RTOS" "CD-BRIDGE" "CDUDF File System - Adaptec Inc"),
> > > > perhaps the kernel code
On Tue, 18 Sep 2007 18:00:01 -0700 Mingming Cao <[EMAIL PROTECTED]> wrote:
> JBD: Replace slab allocations with page cache allocations
>
> JBD allocate memory for committed_data and frozen_data from slab. However
> JBD should not pass slab pages down to the block layer. Use page allocator
>
Now, arch dependent code around CONFIG_MEMORY_HOTREMOVE is a mess.
This patch cleans up them. This is against 2.6.23-rc6-mm1.
- fix compile failure on ia64/ CONFIG_MEMORY_HOTPLUG &&
!CONFIG_MEMORY_HOTREMOVE case.
- For !CONFIG_MEMORY_HOTREMOVE, add generic no-op remove_memory(),
which
On Fri, Sep 14, 2007 at 12:51:34PM -0700, Christoph Lameter wrote:
> On Fri, 14 Sep 2007, Siddha, Suresh B wrote:
> > We are trying to get the latest data with 2.6.23-rc4-mm1 with and without
> > slub. Is this good enough?
>
> Good enough. If you are concerned about the page allocator pass through
On Tue, 18 Sep 2007 17:51:49 -0700 Ethan Solomita <[EMAIL PROTECTED]> wrote:
> >
> >> +void cpuset_update_dirty_nodes(struct address_space *mapping,
> >> + struct page *page)
> >> +{
> >> + nodemask_t *nodes = mapping->dirty_nodes;
> >> + int node = page_to_nid(page);
> >> +
>
Badari Pulavarty wrote:
> On Tue, 2007-09-18 at 15:21 -0700, Badari Pulavarty wrote:
>> Hi Balbir,
>>
>> I get following panic from SLUB, while doing simple fsx tests.
>> I haven't used any container/memory controller stuff except
>> that I configured them in :(
>>
>> Looks like slub doesn't like
On Tue, 2007-09-18 at 23:52 +0200, Andi Kleen wrote:
> On Tuesday 18 September 2007 23:34, Rusty Russell wrote:
> > How about a "select" based on Xen, lguest or VMI? There's no other
> > reason to enable it, after all.
>
> I did an patch to do that recently because the current setup
> is indeed
On Tue, Sep 18, 2007 at 07:55:13PM +0200, Sam Ravnborg wrote:
> Sounds to me like a known issue by you. Can you give a few more details
> so we maybe can get it fixed?
I believe what happened here is an x86_64 build followed by a
UML/x86_64 build with no intervening mrproper.
I've always
The former uml-fix-x86_64-core-dump-crash.patch expressed
ELF_CORE_COPY_REGS in terms of the pt_regs struct currently in -mm. I
fast-tracked this to mainline, where it was wrong because the pt_regs
struct there hadn't been changed. Fixing that then made the patch
wrong for -mm when it was
uml-stop-saving-process-fp-state.patch broke the UML/x86_64 build.
On x86_64, sys/ptrace.h has to be included before asm/ptrace.h.
Otherwise, the defines in asm/ptrace.h will ruin the parse of
sys/ptrace.h -
asm/ptrace.h:
#define PTRACE_GETREGS12
sys/ptrace.h:
These two patches fix UML build breakages on x86_64.
They are -mm-specific, so don't need to go to mainline until 2.6.24.
Jeff
--
Work email - jdike at linux dot intel dot com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Tue, 2007-09-18 at 12:44 -0700, Linus Torvalds wrote:
> This is not about performance. Never has been. It's about SGI wanting a
> way out of their current 16kB mess.
Pass the crack pipe, Linus?
> The way to fix performance is to move to x86-64, and use 4kB pages and be
> happy. However, the
On Wed, 19 Sep 2007, Nathan Scott wrote:
>
> FWIW (and I hate to let reality get in the way of a good conspiracy) -
> all SGI systems have always defaulted to using 4K blocksize filesystems;
Yes. And I've been told that:
> there's very few customers who would use larger
.. who apparently
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> On Tue, 18 Sep 2007 17:12:59 EDT, Mathieu Desnoyers said:
>
> > +++ linux-2.6-lttng/kernel/Kconfig.instrumentation 2007-09-18 13:18:17.000
> 00 -0400
> > @@ -0,0 +1,40 @@
> > +menuconfig INSTRUMENTATION
> > + bool "Instrumentation Support"
>
On 9/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Miles Lane wrote:
> > ERROR: "dvb_dmx_swfilter" [drivers/media/video/video-buf-dvb.ko]
> undefined!
> > ERROR: "dvb_net_init" [drivers/media/video/video-buf-dvb.ko] undefined!
> > ERROR: "dvb_dmxdev_init"
* Mon, 23 Jul 2007 11:02:39 -0700 (PDT)
>
> On Mon, 23 Jul 2007, Nicolas Pitre wrote:
>>
>> I started this once.
>>
>> I have (sort of) a GIT tree with all Linux revisions that I could find
>> from v0.01 up to v1.0.9. But the most interesting information and also
>> what is the most time
On 9/9/07, Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> One of the cpus was unplugged during suspend... perhaps some
> save/restore is needed during hotplug/unplug?
Or else keep track separately in cpusets of
- cpus that the cpuset can run on
- cpus that the admin has specified for the cpu to run
On Tue, 2007-09-18 at 13:04 -0500, Dave Kleikamp wrote:
> On Tue, 2007-09-18 at 09:35 -0700, Mingming Cao wrote:
> > On Tue, 2007-09-18 at 10:04 +0100, Christoph Hellwig wrote:
> > > On Mon, Sep 17, 2007 at 03:57:31PM -0700, Mingming Cao wrote:
> > > > Here is the incremental small cleanup patch.
Hi Gilboa,
On Sat, 15 Sep 2007, Gilboa Davara wrote:
>
> This is my second stab at solving the "stack over flow due to
> dump_strace when close to stack-overflow is detected by do_IRQ" problem.
> (Hopefully) this patch is creates less noise then the previous one.
>
> [snip]
> > I'll try and
Andrew Morton wrote:
> On Tue, 11 Sep 2007 18:36:34 -0700
> Ethan Solomita <[EMAIL PROTECTED]> wrote:
>
>> Add a dirty map to struct address_space
>
> I get a tremendous number of rejects trying to wedge this stuff on top of
> Peter's mm-dirty-balancing-for-tasks changes. More rejects than I am
On Wed, Sep 19, 2007 at 05:48:28AM +0530, Satyam Sharma wrote:
> > > On the other hand, this filesystem announces itself as UDF
> > > ("CD-RTOS" "CD-BRIDGE" "CDUDF File System - Adaptec Inc"),
> > > perhaps the kernel code should be more robust.
>
> Could you send the complete dmesg log, and
On Tue, 2007-09-18 at 15:21 -0700, Badari Pulavarty wrote:
> Hi Balbir,
>
> I get following panic from SLUB, while doing simple fsx tests.
> I haven't used any container/memory controller stuff except
> that I configured them in :(
>
> Looks like slub doesn't like one of the flags passed in ?
>
Christoph Lameter wrote:
> On Fri, 14 Sep 2007, Andrew Morton wrote:
>
>>> + mutex_lock(_mutex);
>>> + *cs_int = val;
>>> + mutex_unlock(_mutex);
>> I don't think this locking does anything?
>
> Locking is wrong here. The lock needs to be taken before the cs pointer
> is dereferenced from
> sorry, but calling attribution claims of any sort "petty" is nothing
> short of dangerous ignorance.
Says a man who has a .sig of "SDF Public Access UNIX System -
http://sdf.lonestar.org;
Well sdf.lonestar.org claims to be NetBSD so might I suggest your
dangerous ignorance starts at the Unix
Hi,
On Tue, 18 Sep 2007, Jan Kara wrote:
>
> > Today I got a CD. MacOS does not mount it and Linux does not
> > mount it without an explicit filesystemtype option.
> > That is,
> > # mount /dev/hdc /dir -t iso9660
> > works fine, but
> > # mount /dev/hdc /dir
> > mount: you didn't
On Tue, 18 Sep 2007 19:33:36 -0400
Jeff Dike <[EMAIL PROTECTED]> wrote:
> ===
> --- linux-2.6.17.orig/arch/um/os-Linux/signal.c 2007-09-09
> 11:15:37.0 -0400
> +++ linux-2.6.17/arch/um/os-Linux/signal.c2007-09-18
On Fri, 7 Sep 2007, Kyle Moffett wrote:
>
> So you can't draw any relationships between "Protect the end-user" with
> "Protect the device FROM the end-user", the former can be done very reliably
^^^ *attacker*
> to whatever level of risk-reduction you need and the
On Thu, 6 Sep 2007, Kyle Moffett wrote:
>
> On Sep 06, 2007, at 19:35:14, Trond Myklebust wrote:
> >
> > On Thu, 2007-09-06 at 19:30 -0400, Kyle Moffett wrote:
> > >
> > > On Sep 06, 2007, at 11:06:16, J. Bruce Fields wrote:
> > > > The question of how to protect against someone with
On Tue, Sep 18, 2007 at 08:56:47AM -0400, Theodore Tso wrote:
> all of the megabytes and megabhytes of flamewar is over these two
> lines:
>
> > * Copyright (c) 2006-2007 Nick Kossifidis <[EMAIL PROTECTED]>
> > * Copyright (c) 2007 Jiri Slaby <[EMAIL PROTECTED]>
>
> Petty, isn't it? Let's just
This patch fixes a crash caused by an interrupt coming in when an IRQ
stack is being torn down. When this happens, handle_signal will loop,
setting up the IRQ stack again because the tearing down had finished,
and handling whatever signals had come in.
However, to_irq_stack returns a mask of
On Tue, 18 Sep 2007, Jeff Garzik wrote:
>
> Easy enough... 'pcimap' branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git
This is wrong.
You must not put it in lib/iomap.c, since that file is only compiled for
architectures that use CONFIG_GENERIC_IOMAP.
So you need
On Tue, 18 Sep 2007 16:06:21 -0700
Shentino <[EMAIL PROTECTED]> wrote:
> Run any program that opens the ALSA sound (and probably the dsp
> legacy), and then suspend to disk during playback.
>
> On the next and each subsequent thawout, the sound is dead even if you
> close and repoen the sound.
On Fri, 7 Sep 2007, J. Bruce Fields wrote:
>
> On Fri, Sep 07, 2007 at 01:32:52AM +0200, Trond Myklebust wrote:
> > Sorry. Of course, you have to copy the entire /lib, etc. onto the tmpfs,
> > but you get the gist
> >
> > The point is that it is easy to subvert userspace if you have enough
On Tue, 18 Sep 2007 17:13:27 -0400 Mathieu Desnoyers wrote:
> Here is some documentation explaining what is/how to use the Linux
> Kernel Markers.
>
> ---
>
> Documentation/markers/markers.txt | 93 +++
> Documentation/markers/src/Makefile |7 ++
>
On Thu, 6 Sep 2007, J. Bruce Fields wrote:
>
> On Thu, Sep 06, 2007 at 01:59:50PM +0530, Satyam Sharma wrote:
> > Oh and btw, note that we're talking of the (lack of) security of a
> > "running kernel" here -- because across reboots, there is /really/
> > *absolutely* no such thing as
Benjamin Herrenschmidt wrote:
On Tue, 2007-09-18 at 16:21 -0400, Jeff Garzik wrote:
A new pci_mmio_map() helper, to be used with 100% MMIO hardware, might
help eliminate confusion.
Maybe not the best name in theory but at least would show that it
relates to existing ioremap would be
Run any program that opens the ALSA sound (and probably the dsp
legacy), and then suspend to disk during playback.
On the next and each subsequent thawout, the sound is dead even if you
close and repoen the sound. Only a "cold boot" can fix it.
-
To unsubscribe from this list: send the line
On 09/18/2007 06:46 PM, Ingo Molnar wrote:
>>> We need a (tested)
>>> solution for 2.6.23 and the CFS-devel patches are not for 2.6.23. I've
>>> attached below the latest version of the -rc6 yield patch - the switch
>>> is not dependent on SCHED_DEBUG anymore but always available.
>>>
>> Is
On Tue, Sep 18, 2007 at 07:56:05PM -0300, Mauro Carvalho Chehab wrote:
> proprietary format. This way, an userspace app may use the userspace
> library as a "fallback method" for unknown FOURCC formats. The result
> will be probably far away from an optimal result on some cases (since it
>
> The reason why there is no single 'format conversion library' that
> everybody uses is because of the large differences between requirements
> for such a thing. The line between 'format conversion' and things such
> as a video codec, or image processing is very vague.
Agreed. What I think it
Gabriel C wrote:
> Sam Ravnborg wrote:
>> On Tue, Sep 18, 2007 at 03:42:58PM -0400, Miles Lane wrote:
>>> On 9/18/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
Hi Miles.
On Tue, Sep 18, 2007 at 11:27:23AM -0400, Miles Lane wrote:
> Selecting Help for "Subarchitecture Type" causes "make
* Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> On 09/14/2007 11:32 AM, Ingo Molnar wrote:
> > * Antoine Martin <[EMAIL PROTECTED]> wrote:
> >
> have an impact) Keep CONFIG_SCHED_DEBUG=y to be able to twiddle the
> sysctl.
> >> It looks good now! Updated results here:
> >>
On Tue, 2007-09-18 at 11:55 -0700, Can E. Acar wrote:
> Theodore Tso wrote:
> > On Mon, Sep 17, 2007 at 03:06:37PM -0700, Can E. Acar wrote:
> >> The only remaining issue is whether Nick & Jiri have enough
> >> original contributions to the code to be added to the Copyright.
> >>
> >> I believe
On Tue, Sep 18, 2007 at 03:29:50PM -0700, Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
> >
> >> It's a pity that gas seems to generate plain 0x90 nops rather than
> >> long-nop forms here. I thought it could do that.
> >>
> >
> >
Sam Ravnborg wrote:
> On Tue, Sep 18, 2007 at 03:42:58PM -0400, Miles Lane wrote:
>> On 9/18/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>>> Hi Miles.
>>> On Tue, Sep 18, 2007 at 11:27:23AM -0400, Miles Lane wrote:
Selecting Help for "Subarchitecture Type" causes "make menuconfig" to
Benjamin Herrenschmidt wrote:
To be more precise, a platform has every right to return some kind of
"token" from ioport_map/pci_iomap that encodes the type of address, and
that is -different- from what a normal ioremap does. In which case, you
will -not- be able to use readb/writeb & cie on such
On Wed, 19 Sep 2007, Benjamin Herrenschmidt wrote:
>
> Also, I've been told that modern x86 chipsets have the ability to remap
> IO space in the CPU physical address space. Is that true ? That would
> allow even x86 to get rid of the condition and just use some magic
> offset at map time.
I've
On 9/13/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
> Hi Andi and everyone,
>
> Wanted to get your thoughts on this patch. lguest now supports plan9
> guests which use 0x40 for system calls. We want to let the guests use
> that vector if available, but have no way to stop io_apic from
>
Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
>> Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
>>
>>> It's a pity that gas seems to generate plain 0x90 nops rather than
>>> long-nop forms here. I thought it could do that.
>>>
>> .p2align does it
>
> Just .p2align? Not align, balign,
Andi Kleen wrote:
> Jeremy Fitzhardinge <[EMAIL PROTECTED]> writes:
>
>> It's a pity that gas seems to generate plain 0x90 nops rather than
>> long-nop forms here. I thought it could do that.
>>
>
> .p2align does it
Just .p2align? Not align, balign, org or skip? Seems... strange.
1 - 100 of 962 matches
Mail list logo
