On Tue, Oct 02 2007, Benjamin Herrenschmidt wrote:
>
> On Mon, 2007-10-01 at 13:59 +0200, Jens Axboe wrote:
> > On Sun, Sep 30 2007, Grant Likely wrote:
> > > On 9/30/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > > > On Sun, Sep 30, 2007 at 04:57:09PM -0600, Grant Likely wrote:
> > > > > +
* David Schwartz <[EMAIL PROTECTED]> wrote:
> > These are generic statements, but i'm _really_ interested in the
> > specifics. Real, specific code that i can look at. The typical Linux
> > distro consists of in execess of 500 millions of lines of code, in
> > tens of thousands of apps, so the
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * David Schwartz <[EMAIL PROTECTED]> wrote:
>
> > > These are generic statements, but i'm _really_ interested in the
> > > specifics. Real, specific code that i can look at. The typical Linux
> > > distro consists of in execess of 500 millions of lines
On Mon, 1 Oct 2007, Jeff Dike wrote:
> The Kconfig language seems not to allow calculation of hex constants,
> so I moved this to as-layout.h. CONFIG_STUB_CODE, CONFIG_STUB_DATA,
> and CONFIG_STUB_START are now gone. In their place are STUB_CODE,
> STUB_DATA, and STUB_START in as-layout.h.
Hmm,
On Mon, Oct 01, 2007 at 11:08:14AM -0700, Arjan van de Ven wrote:
> On Mon, 1 Oct 2007 16:15:53 +0400
> Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
>
> > Save ~650 bytes here.
> >
> > add/remove: 4/0 grow/shrink: 0/7 up/down: 430/-1088 (-658)
> > function old
On 02 Oct 2007 08:18:17 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
> >
> > revert-x86_64-mm-cpa-einval.patch
> > fix-x86_64-mm-sched-clock-share.patch
> > agp-fix-race-condition-between-unmapping-and-freeing-pages.patch
> > x86_64-mce-poll-at-idle_star
Rusty Russell wrote:
> That's good, but this code does lose on native because we no longer
> simply replace the entire thing with noops.
>
> Perhaps inverting this and having (inline) helpers is the way to go?
>
I'm thinking that the overhead will be unmeasurably small, and its not
really worth
* David Schwartz <[EMAIL PROTECTED]> wrote:
> > at a quick glance this seems broken too - but if you show the
> > specific code i might be able to point out the breakage in detail.
> > (One underlying problem here appears to be fairness: a quick
> > unlock/lock sequence may starve out other th
Avi Kivity wrote:
> The code doesn't support having both lazy modes active at once. Maybe
> that's not an issue, but aren't the two modes orthogonal?
Hm, well, that's a good question. The initial semantics of the lazy
mode calls were "what VMI wants", and they're still not really nailed
down. V
On Tue, 2 Oct 2007, Andi Kleen wrote:
> > Agreed.
> >
> > I just got a x8664-hrt report, where I found the following oddity:
> >
> > 0: 1197 172881 IO-APIC-edge timer
> >
> > That's one of those infamous AMD C1E boxen. Strange, all my systems have
> > IRQ#0 on CPU#0 and nowher
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> revert-x86_64-mm-cpa-einval.patch
> fix-x86_64-mm-sched-clock-share.patch
> agp-fix-race-condition-between-unmapping-and-freeing-pages.patch
> x86_64-mce-poll-at-idle_start-and-printk-fix.patch
> fix-x86_64-mm-unwinder.patch
> geode-mfgpt-support-for-g
* David Schwartz <[EMAIL PROTECTED]> wrote:
> > (user-space spinlocks are broken beyond words for anything but
> > perhaps SCHED_FIFO tasks.)
>
> User-space spinlocks are broken so spinlocks can only be implemented
> in kernel-space? Even if you use the kernel to schedule/unschedule the
> tas
* David Schwartz <[EMAIL PROTECTED]> wrote:
> > These are generic statements, but i'm _really_ interested in the
> > specifics. Real, specific code that i can look at. The typical Linux
> > distro consists of in execess of 500 millions of lines of code, in
> > tens of thousands of apps, so the
On Mon, 2007-10-01 at 13:59 +0200, Jens Axboe wrote:
> On Sun, Sep 30 2007, Grant Likely wrote:
> > On 9/30/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > > On Sun, Sep 30, 2007 at 04:57:09PM -0600, Grant Likely wrote:
> > > > + if ((rc = platform_driver_register(&ace_platform_driver)) !
On Sun, 2007-09-30 at 16:57 -0600, Grant Likely wrote:
> val |= ACE_CTRL_DATABUFRDYIRQ | ACE_CTRL_ERRORIRQ;
> ace_out(ace, ACE_CTRL, val);
>
> + /* Now we can hook up the irq handler */
> + if (ace->irq != NO_IRQ) {
> + rc = request_irq(ace->irq, ace_int
> Agreed.
>
> I just got a x8664-hrt report, where I found the following oddity:
>
> 0: 1197 172881 IO-APIC-edge timer
>
> That's one of those infamous AMD C1E boxen. Strange, all my systems have
> IRQ#0 on CPU#0 and nowhere else. Any idea ?
Hmm, in lowestpriority mode it wo
Jeremy Fitzhardinge wrote:
Currently, the set_lazy_mode pv_op is overloaded with 5 functions:
1. enter lazy cpu mode
2. leave lazy cpu mode
3. enter lazy mmu mode
4. leave lazy mmu mode
5. flush pending batched operations
This complicates each paravirt backend, since it needs to deal with
a
* Willy Tarreau <[EMAIL PROTECTED]> wrote:
> Well, I think that we could do something like this :
>
> #define KERN_CONT ""
> ...
> printk(KERN_ERR "foo");
> <100 lines of whatever>
> printk(KERN_CONT "bar\n");
>
> It would indicate the author's *intent* which is to continue a
On Mon, Oct 01, 2007 at 08:57:10PM -0600, Thayne Harbaugh wrote:
> Yeah, after I sent the email I realized that it was a bit more involved.
> As far as the 32/31 bit, it just depends on the perspective. I can see
> that 32 bits are needed to represent all possible return values from
> mmap() - pos
hi Mike,
* Mike Kravetz <[EMAIL PROTECTED]> wrote:
> I've been trying to track down some unexpected realtime latencies and
> believe one source is a bug in the wakeup code. Specifically, this is
> within the try_to_wake_up() routine. Within this routine there is the
> following code segment:
>
On Tue, 02 Oct 2007 07:56:24 +0300
Mika Penttilä <[EMAIL PROTECTED]> wrote:
> Here I have with stock FC7 (2.6.22.9-91) kernel :
> 0: 107835 133459760 IO-APIC-edge timer
>
fwiw this is entirely done by the hardware; no irq balancer has touched
this one (fc7 has the new irqbalancer
Benjamin Herrenschmidt wrote:
> On Tue, 2007-10-02 at 14:44 +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2007-10-01 at 20:23 -0700, Philip Langdale wrote:
>>> Thanks to Matt Domsch and Rezwanul Kabir at Dell, we know how to disable the
>>> MMC controller on the multi-function Ricoh R5C832. The M
Thomas Gleixner wrote:
On Tue, 2 Oct 2007, Andi Kleen wrote:
OTOH, the accounting hook would allow us to remove the IRQ#0 -> CPU#0
restriction. Not sure whether it's worth the trouble.
Some SIS chipsets hang the machine when you migrate irq 0 to another
CPU. It's better to keep that A
On Mon, Oct 01, 2007 at 10:28:30AM -0400, Bill Davidsen wrote:
> Lennart Sorensen wrote:
> >On Fri, Sep 28, 2007 at 05:24:20PM -0400, Bill Davidsen wrote:
> >
> >>I'll offer this suggestion, knowing it may piss you off, given the
> >>difficulty of preserving whitespace on *many* mailers without
On Tue, 2007-10-02 at 14:44 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2007-10-01 at 20:23 -0700, Philip Langdale wrote:
> > Thanks to Matt Domsch and Rezwanul Kabir at Dell, we know how to disable the
> > MMC controller on the multi-function Ricoh R5C832. The MMC controller needs
> > to be di
On Mon, 2007-10-01 at 20:23 -0700, Philip Langdale wrote:
> Thanks to Matt Domsch and Rezwanul Kabir at Dell, we know how to disable the
> MMC controller on the multi-function Ricoh R5C832. The MMC controller needs
> to be disabled or it will steal MMC cards from the SD controller where they
> wou
On Mon, Oct 01, 2007 at 12:30:07AM -0700, Andrew Morton wrote:
> On Mon, 1 Oct 2007 08:44:48 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> >
> > (lkml Cc:-ed - this might be of interest to others too)
> >
> > * Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> >
> > > WARNING: EXPORT_SYMBOL(foo);
Have you checked your memory already (memtest86)?
[...]
Again... sounds like bad memory to me.
Nightly memtest86 run : 11 hours, 23 passes, 0 errors.
--
./lxnt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Andrew Morton wrote:
> memory-controller-add-documentation.patch
> memory-controller-resource-counters-v7.patch
> memory-controller-resource-counters-v7-fix.patch
> memory-controller-containers-setup-v7.patch
> memory-controller-accounting-setup-v7.patch
> memory-controller-memory-accounting-v7.pat
On Mon, 2007-10-01 at 10:03 -0700, Dave Hansen wrote:
> On Mon, 2007-10-01 at 19:43 +1000, Rusty Russell wrote:
> > On Fri, 2007-09-28 at 16:00 -0700, Dave Hansen wrote:
> > > Module refcounts currently use a percpu counter stored
> > > in the 'struct module'. However, we also have a more
> > > ge
> On Sunday, 30 September 2007 20:39, Alexey Starikovskiy wrote:
> > ACPI uses acpi_get_register() in order to get into suspend.
> > This function is guarded by acpi_gbl_hardware_lock, which will be carried
> > into resume phase.
> > At resume interrupts are enabled and first ACPI interrupt deadloc
From: Rob Landley <[EMAIL PROTECTED]>
Add Documentation/power/00-INDEX
Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
---
All my pending 00-INDEX patches are at http://landley.net/kdocs/make/patches
Documentation/power/00-INDEX | 34 +
1 file changed, 34 insert
I said I was hoping that -rc8 was the last -rc, and I hate doing this, but
we've had more changes since -rc8 than we had in -rc8. And while most of
them are pretty trivial, I really couldn't face doing a 2.6.23 release and
take the risk of some really stupid brown-paper-bag thing.
So there's a
Thanks to Matt Domsch and Rezwanul Kabir at Dell, we know how to disable the
MMC controller on the multi-function Ricoh R5C832. The MMC controller needs
to be disabled or it will steal MMC cards from the SD controller where they
would otherwise be supported by the Linux SDHCI driver.
Signed-off-by
Pierre Ossman wrote:
>
> Preferably. But if you can't figure it out until it is time to merge
> things upstream, then I'll go with what we have right now.
I have not been contacted by anyone with one of those laptops so I
haven't been able to find out what's going on.
I'm updating the diff, beca
On Wed, 2007-09-26 at 16:02 +0200, Arnd Bergmann wrote:
> The /proc/bus/pci/* files list PCI domain numbers only for
> devices that claim to be on a multi-domain system. The check
> for this is broken on powerpc, because the buid value is
> truncated to 32 bits.
>
> There is at least one machine
On Mon, 2007-10-01 at 13:13 +0200, Andi Kleen wrote:
> > @@ -388,6 +392,9 @@
> > if (vma->vm_flags & VM_MAYSHARE)
> > map_flags |= MAP_SHARED;
> >
> > + if (flags & MAP_32BIT)
> > + map_flags |= MAP_32BIT;
On Friday 28 September 2007 7:25:28 pm Rob Landley wrote:
> From: Rob Landley <[EMAIL PROTECTED]>
>
> Remove nonstandard line break from Documentation/powerpc/00-INDEX
>
> Signed-off-by: Rob Landley <[EMAIL PROTECTED]>
> ---
>
> This is the only instance of a newline in a 00-INDEX file description,
On Mon, Oct 01, 2007 at 06:37:44PM -0400, Jeff Garzik wrote:
> Olof Johansson wrote:
>> Hardware config in my case:
>> Highpoint 2310 controller
>> PPC (big endian)
>> WD Raptor disk
>> Works fine with the other controller I've been using (SIL24), and works
>> fine if I revert the driver.
>> It als
> On Mon, 1 Oct 2007, Yasunori Goto wrote:
>
> > +#ifdef CONFIG_MEMORY_HOTPLUG
> > +static void __slab_callback_offline(int nid)
> > +{
> > + struct kmem_cache_node *n;
> > + struct kmem_cache *s;
> > +
> > + list_for_each_entry(s, &slab_caches, list) {
> > + if (s->node[nid]) {
>
On Tue, 2 Oct 2007 10:00:40 +0800 Fengguang Wu <[EMAIL PROTECTED]> wrote:
> writeback: avoid possible balance_dirty_pages() lockup on a light-load bdi
>
> On a busy-writing system, a writer could be hold up infinitely on a
> light-load device. It will be trying to sync more than available dirty d
On Mon, Oct 01, 2007 at 11:57:34AM -0400, Chuck Ebbert wrote:
> On 09/29/2007 07:04 AM, Fengguang Wu wrote:
> > On Thu, Sep 27, 2007 at 11:32:36PM -0700, Chakri n wrote:
> >> Hi,
> >>
> >> In my testing, a unresponsive file system can hang all I/O in the system.
> >> This is not seen in 2.4.
> >>
>
On Mon, 2007-10-01 at 16:46 -0700, Jeremy Fitzhardinge wrote:
> This patch removes the set_lazy_mode operation, and adds "enter" and
> "leave" lazy mode operations on mmu_ops and cpu_ops. All the logic
> associated with enter and leaving lazy states is now in common code
> (basically BUG_ONs to ma
On Mon, Oct 01, 2007 at 05:41:32PM -0500, Linas Vepstas wrote:
> On Mon, Oct 01, 2007 at 02:12:47PM -0600, Matthew Wilcox wrote:
> > I think the fundamental problem is that completions aren't really
> > supposed to be used like this. Here's one attempt at using completions
> > perhaps a little mor
Support large blocksize up to PAGESIZE (max 64KB) for ext3
From: Takashi Sato <[EMAIL PROTECTED]>
This patch set supports large block size(>4k, <=64k) in ext3
just enlarging the block size limit. But it is NOT possible to have 64kB
blocksize on ext3 without some changes to the directory handling
ext3: Avoid rec_len overflow with 64KB block size
From: Jan Kara <[EMAIL PROTECTED]>
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 convert
value when read from / written to disk. The patch also co
ext2: Avoid rec_len overflow with 64KB block size
From: Jan Kara <[EMAIL PROTECTED]>
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 convert
value when read from / written to disk.
Signed-off-by: J
Support large blocksize up to PAGESIZE (max 64KB) for ext2
From: Takashi Sato <[EMAIL PROTECTED]>
This patch set supports large block size(>4k, <=64k) in ext2,
just enlarging the block size limit. But it is NOT possible to have 64kB
blocksize on ext2 without some changes to the directory handling
ext4: Avoid rec_len overflow with 64KB block size
From: Jan Kara <[EMAIL PROTECTED]>
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 convert
value when read from / written to disk. The patch also co
Support large blocksize up to PAGESIZE (max 64KB) for ext4.
From: Takashi Sato <[EMAIL PROTECTED]>
This patch set supports large block size(>4k, <=64k) in ext4,
just enlarging the block size limit. But it is NOT possible to have 64kB
blocksize on ext4 without some changes to the directory handli
Hi.
On Monday 01 October 2007 08:28:02 Rafael J. Wysocki wrote:
> On Sunday, 30 September 2007 23:43, Nigel Cunningham wrote:
> > On Monday 01 October 2007 05:56:45 Rafael J. Wysocki wrote:
> > > On Sunday, 30 September 2007 13:44, Nigel Cunningham wrote:
> > > > Hi Rafael et al.
> > > >
> > > >
Linus Torvalds wrote:
On Mon, 1 Oct 2007, Tim Shimmin wrote:
Lachlan's description:
This fix is for a problem that has been in XFS since day one.
[XFS] Avoid replaying inode buffer initialisation log items if on-disk
version is newer.
...
Why wasn't this in the commit logs? N
William Cattey wrote:
> Thanks very much for responding.
>
> From your two replies, I crafted the attached patch.
> Alas, the EDID transfer comes up all zeros.
> I see two possible causes of this behavior:
>
> 1. I misunderstood how you intended the file to be modified.
> 2. The fix for my bug is N
The following is the cleaned up patch implementing the power management
quality of service infrastructure discussed at the pm summit last June.
It is a genralization of the latency code put into the kernel last year
by Arjan.
I would like to get this code included in the MM tree and to get some
m
Andrew Morton wrote:
libata-add-human-readable-error-value-decoding-v3.patch
I think I own this now. Will send to jgarzik then drop it if it doesn't
stick.
Another plug for this one, as the author. I really don't think one can
object to it, and it definitely seems useful.
--
Robert Han
Currently, the set_lazy_mode pv_op is overloaded with 5 functions:
1. enter lazy cpu mode
2. leave lazy cpu mode
3. enter lazy mmu mode
4. leave lazy mmu mode
5. flush pending batched operations
This complicates each paravirt backend, since it needs to deal with
all the possible state transit
On Saturday 29 September 2007 22:11, Sam Ravnborg wrote:
> The second is the more controversial suggestion.
> In several Makefile we have simple if expression of the variants:
> if ($(CONFIG_FOO),y)
> obj-$(CONFIG_BAR) += fubar.o
> endif
Sometimes substitution looks acceptable:
> -nfsd-$(CONFIG
On Mon, 1 Oct 2007 15:44:09 -0700
"David Schwartz" <[EMAIL PROTECTED]> wrote:
>
> > yielding IS blocking. Just with indeterminate fuzzyness added to
> > it
>
> Yielding is sort of blocking, but the difference is that yielding
> will not idle the CPU while blocking might.
not really; SOMEON
On Tue, 2 Oct 2007 00:47:12 +0200 (CEST)
Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Tue, 2 Oct 2007, Andi Kleen wrote:
> >
> > > OTOH, the accounting hook would allow us to remove the IRQ#0 ->
> > > CPU#0 restriction. Not sure whether it's worth the trouble.
> >
> > Some SIS chipsets hang t
On Tue, 2 Oct 2007, Andi Kleen wrote:
>
> > OTOH, the accounting hook would allow us to remove the IRQ#0 -> CPU#0
> > restriction. Not sure whether it's worth the trouble.
>
> Some SIS chipsets hang the machine when you migrate irq 0 to another
> CPU. It's better to keep that Also I wouldn't be s
> yielding IS blocking. Just with indeterminate fuzzyness added to it
Yielding is sort of blocking, but the difference is that yielding will not
idle the CPU while blocking might. Yielding is sometimes preferable to
blocking in a case where the thread knows it can make forward progress even
i
On Mon, Oct 01, 2007 at 02:12:47PM -0600, Matthew Wilcox wrote:
>
> I think the fundamental problem is that completions aren't really
> supposed to be used like this. Here's one attempt at using completions
> perhaps a little more the way they're supposed to be used,
Yes, that looks very good t
> There was a bug in 2.6.23-rc8 that caused this to happen.
>
> It's been fixed in the later -git kernels
> (commits 2f3f22269bdf702311342c5d106dfdd7347d1c3e,
> 853298bc03ef65e3eb392f5d61265605214ee8fb).
You are right, I have downloaded current head of git and seems to work ok.
Sorry for the los
On Mon, 1 Oct 2007 15:17:52 -0700
"David Schwartz" <[EMAIL PROTECTED]> wrote:
>
> Arjan van de Ven wrote:
>
> > > It can occasionally be an optimization. You may have a case where
> > > you can do something very efficiently if a lock is not held, but
> > > you cannot afford to wait for the lock
Olof Johansson wrote:
Hi,
I just pulled out my Marvell 7042 SATA controller here to give it a spin
and noticed that it no longer worked (i.e. init segvs when loading from
it), etc. 2.6.22 is fine.
Bisecting (just the file drivers/ata/sata_mv.c) resulted in
bdd4dddee325a7dce3e84cf48201a06aa8508a
Jiri Kosina wrote:
> On Tue, 2 Oct 2007, Gabriel C wrote:
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-10-01-04-09.tar.gz
>>> There is a 'series' file, which tells you the correct order. If you are
>>> planning to make any patches on top of mm, you should
Thanks very much for responding.
From your two replies, I crafted the attached patch.
Alas, the EDID transfer comes up all zeros.
I see two possible causes of this behavior:
1. I misunderstood how you intended the file to be modified.
2. The fix for my bug is NOT in correcting the audit call, bu
On Mon, Oct 01, 2007 at 03:09:16PM -0700, Davide Libenzi wrote:
> On Mon, 1 Oct 2007, Paul E. McKenney wrote:
>
> > That would indeed be one approach that CPU designers could take to
> > avoid being careless or sadistic. ;-)
>
> That'd be the easier (unique maybe) approach too for them, from an
Arjan van de Ven wrote:
> > It can occasionally be an optimization. You may have a case where you
> > can do something very efficiently if a lock is not held, but you
> > cannot afford to wait for the lock to be released. So you check the
> > lock, if it's held, you yield and then check again. If
I've been trying to track down some unexpected realtime latencies and
believe one source is a bug in the wakeup code. Specifically, this is
within the try_to_wake_up() routine. Within this routine there is the
following code segment:
/*
* If a newly woken up RT task cannot preem
On Tue, 2 Oct 2007, Gabriel C wrote:
> >>>
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-10-01-04-09.tar.gz
> > There is a 'series' file, which tells you the correct order. If you are
> > planning to make any patches on top of mm, you should use quilt for this.
>
On Mon, Oct 01, 2007 at 11:45:22PM +0200, Andi Kleen wrote:
>
>
> > feature flag does not disappear when its disabled. But because with CPUs
> > having the SVM-lock feature it can be re-enabled in a secure way under
> > some circumstances
>
> Who would reenable it in what circumstances?
I plan
Jiri Kosina wrote:
> On Mon, 1 Oct 2007, Gabriel C wrote:
>
>>>
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-10-01-04-09.tar.gz
>> I have a question about these snapshots , what is the right way to apply
>> the patches ? some magic script ? =)
>
> There is a 'seri
On Mon, 1 Oct 2007, Paul E. McKenney wrote:
> That would indeed be one approach that CPU designers could take to
> avoid being careless or sadistic. ;-)
That'd be the easier (unique maybe) approach too for them, from an silicon
complexity POV. Distinguishing between different CPUs stores once i
> OTOH, the accounting hook would allow us to remove the IRQ#0 -> CPU#0
> restriction. Not sure whether it's worth the trouble.
Some SIS chipsets hang the machine when you migrate irq 0 to another
CPU. It's better to keep that Also I wouldn't be surprised if there are some
other assumptions about
On Mon, 1 Oct 2007 16:35:11 -0500
"Luis Garcia-Vega" <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> I'm getting kernel panics when I boot a pair of Xeon 2.8GHz on a
> Nexcom PEAK 7220VL2G board (one of those system on a board setups).
> I'm running the stock Red Hat Enterprise 4.5 kernel. I mention
On Mon, 1 Oct 2007, Andi Kleen wrote:
>
> > IRQ_NOBALANCING is not preventing cpu unplug. It moves the affinity to the
> > next CPU, but the check in NMI watchdog for CPU == 0 would not longer
> > work.
>
> That cannot happen right now because cpu_disable() on both i386/x86-64
> reject CPU #0. So
Hi,
I just pulled out my Marvell 7042 SATA controller here to give it a spin
and noticed that it no longer worked (i.e. init segvs when loading from
it), etc. 2.6.22 is fine.
Bisecting (just the file drivers/ata/sata_mv.c) resulted in
bdd4dddee325a7dce3e84cf48201a06aa8508aa4 popping out as the cu
On Mon, 1 Oct 2007, Gabriel C wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-10-01-04-09.tar.gz
> I have a question about these snapshots , what is the right way to apply
> the patches ? some magic script ? =)
There is a 'series' file, which tells you the
On Mon, 1 Oct 2007 22:54:47 +0200, Jean Delvare wrote:
> 2.6.23-rc8 and 2.6.23-rc8-git4 fail to build on one of my test
> machines, with:
>
> drivers/built-in.o(.init.text+0x780e): In function `dmi_id_init':
> : undefined reference to `__you_cannot_kmalloc_that_much'
>
> The code is allocating si
On Mon, 1 Oct 2007, Andrew Morton wrote:
> Ah. So the already-dropped
> slub-exploit-page-mobility-to-increase-allocation-order.patch was the
> culprit?
Yes without that patch SLUB will no longer take special action if antifrag
is around.
-
To unsubscribe from this list: send the line "unsubsc
[EMAIL PROTECTED] wrote:
> The mm snapshot broken-out-2007-10-01-04-09.tar.gz has been uploaded to
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-10-01-04-09.tar.gz
>
> It contains the following patches against 2.6.23-rc8:
I have a question about these snapshots ,
On Mon, 1 Oct 2007 14:38:55 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Mon, 1 Oct 2007, Andrew Morton wrote:
>
> > Do slab and slub use the same underlying page size for each slab?
>
> SLAB cannot pack objects as dense as SLUB and they have different
> algorithm to make the c
> feature flag does not disappear when its disabled. But because with CPUs
> having the SVM-lock feature it can be re-enabled in a secure way under
> some circumstances
Who would reenable it in what circumstances?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> IRQ_NOBALANCING is not preventing cpu unplug. It moves the affinity to the
> next CPU, but the check in NMI watchdog for CPU == 0 would not longer
> work.
That cannot happen right now because cpu_disable() on both i386/x86-64
reject CPU #0. So just setting IRQ_NOBALANCING is sufficient and both
On Saturday 29 September 2007, Sergei Shtylyov wrote:
> The Marvell bridge chips used on HighPoint SATA cards do not seem to support
> the MWDMA modes (at least that caould be seen in their so-called drivers :-),
> so the driver needs to account for this -- to achieve this:
>
> - add mdma_filter()
On Mon, 1 Oct 2007, Andrew Morton wrote:
> Do slab and slub use the same underlying page size for each slab?
SLAB cannot pack objects as dense as SLUB and they have different
algorithm to make the choice of order. Thus the number of objects per slab
may vary between SLAB and SLUB and therefore
Ingo Molnar wrote:
>
> Really, i have never seen a _single_ mainstream app where the use of
> sched_yield() was the right choice.
Pliant 'FastSem' semaphore implementation (as oppsed to 'Sem') uses 'yield'
http://old.fullpliant.org/
Basically, if the ressource you are protecting with the semaphor
Hi list,
I'm getting kernel panics when I boot a pair of Xeon 2.8GHz on a
Nexcom PEAK 7220VL2G board (one of those system on a board setups).
I'm running the stock Red Hat Enterprise 4.5 kernel. I mentioned a
pair, because the system boots fine with the Uniprocessor kernel. I
thought it could
In -mm merge plans for 2.6.24, Andrew wrote:
> cpuset-remove-sched-domain-hooks-from-cpusets.patch
>
> Paul continues to wibble over this. Hold, I guess.
Oh dear ... after looking at the following to figure out what
a wibble is, I wonder which one Andrew had in mind:
http://www.urbandiction
On Mon, 1 Oct 2007 13:55:29 -0700 (PDT)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Sat, 29 Sep 2007, Andrew Morton wrote:
>
> > > atomic allocations. And with SLUB using higher order pages, atomic !0
> > > order allocations will be very very common.
> >
> > Oh OK.
> >
> > I thought we'd
The calculation of CONFIG_STUB_CODE and CONFIG_STUB_DATA didn't take
into account anything but 3G/1G and 2G/2G, leaving the other vmsplits
out in the cold.
I'd rather not duplicate the four known host vmsplit cases for each of
these symbols. I'd also like to calculate them based on the highest
us
From: Lepton Wu <[EMAIL PROTECTED]>
In a stock 2.6.22.6 kernel, poweroff a user mode linux guest
(2.6.22.6 running in skas0 mode) will halt the host linux. I
think the reason is the kernel thread abort because of a bug.
Then the sys_reboot in process of user mode linux guest is
not trapped by th
Style fixes for the rest of the drivers. arch/um/drivers should be
pretty CodingStyle-compliant now.
Except for the ubd driver, which will have to be treated separately.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
---
arch/um/drivers/chan_user.c | 18 +++--
arch/um/drivers/cow_user.c
On Mon, 1 Oct 2007, Arjan van de Ven wrote:
> > > I already did this here by checking for cpu != 0. But it also needs
> > > either tracking or forbidding migrations of irq 0. I can take care
> > > of the patch.
> >
> > I was thinking about the same fix. On i386 we already have the irq
> > migrati
On Fri, 28 Sep 2007, Mel Gorman wrote:
> Minimally, SLUB by default should continue to use order-0 pages. Peter has
> managed to bust order-1 pages with mem=128MB. Admittedly, it was a really
> hostile workload but the point remains. It was artifically worked around
> with min_free_kbytes (value s
On Sat, 29 Sep 2007, Peter Zijlstra wrote:
>
> On Fri, 2007-09-28 at 11:20 -0700, Christoph Lameter wrote:
>
> > Really? That means we can no longer even allocate stacks for forking.
>
> I think I'm running with 4k stacks...
4k stacks will never fly on an SGI x86_64 NUMA configuration given th
On Sat, 29 Sep 2007, Andrew Morton wrote:
> > atomic allocations. And with SLUB using higher order pages, atomic !0
> > order allocations will be very very common.
>
> Oh OK.
>
> I thought we'd already fixed slub so that it didn't do that. Maybe that
> fix is in -mm but I don't think so.
>
> T
From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Mon, 01 Oct 2007 22:10:03 +0200
> So maybe the following patch is necessary...
>
> I believe IPV6 & DCCP are immune to this problem.
>
> Thanks again Denys for spotting this.
>
> Eric
>
> [PATCH] TCP : secure_tcp_sequence_number() should not use a t
Hi all,
2.6.23-rc8 and 2.6.23-rc8-git4 fail to build on one of my test
machines, with:
drivers/built-in.o(.init.text+0x780e): In function `dmi_id_init':
: undefined reference to `__you_cannot_kmalloc_that_much'
The code is allocating sizeof(struct device) so it really shouldn't be
a problem. I h
1 - 100 of 371 matches
Mail list logo
