>From 54c70ca7671750fe8986451fae91d42107d0ca90 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Date: Fri, 28 Sep 2007 10:33:33 -0500
Subject: [PATCH 1/2 -mm] capabilities: define CONFIG_COMMONCAP
currently the compilation of commoncap.c is determined
through Makefile logic. So
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> Well, yes and no ... A valid option here would be to use soft-masking,
> which is possible because MSIs are edge interrupts. That is, basically,
> when masked, just ignore them and set IRQF_PENDING, and when unmasked,
> replay (which can be don
--- Al Viro <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote:
> > > > Because you throw "simple" out the window when you require userland
> > > > assistance to perform this function.
> > >
> > > Any more than having /tmp replaced with a symlink?
> >
>
On Thu, 4 Oct 2007, Tomoya Adachi wrote:
> This patch fixes the problem, that Japanese MacBook doesn't recognize
> some keys like '\'(yen, or backslash), '|'(pipe), and '_'(underscore).
> It is due to that MacBook JIS keyboard (jp106) sends wrong report
> descriptor. It saids "logical maximum =
On Wed, 03 Oct 2007 14:58:07 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Peter Zijlstra <[EMAIL PROTECTED]>
> Date: Wed, 03 Oct 2007 17:44:53 +0200
>
> > Index: linux-2.6/net/core/dev.c
> > ===
> > --- linux-2.6.orig/
> We should also be leaving the INTx irqs disabled. So no irq
> should be generated.
>
> If you have a mask bit implemented you are required to be
> able to refire it after the msi is enabled. I don't recall
> the requirements for when both intx and msi irqs are both
> disabled. Intuitively I
From: Peter Zijlstra <[EMAIL PROTECTED]>
Date: Wed, 03 Oct 2007 17:44:53 +0200
> Index: linux-2.6/net/core/dev.c
> ===
> --- linux-2.6.orig/net/core/dev.c
> +++ linux-2.6/net/core/dev.c
> @@ -2095,11 +2095,11 @@ static int process_bac
From: Tomoya Adachi <[EMAIL PROTECTED]>
This patch fixes the problem, that Japanese MacBook doesn't recognize some keys
like '\'(yen, or backslash), '|'(pipe), and '_'(underscore).
It is due to that MacBook JIS keyboard (jp106) sends wrong report descriptor.
It saids "logical maximum = 0x65", so
Loic Prylli <[EMAIL PROTECTED]> writes:
> Hi,
>
> We observe a problem with MSI since kernel 2.6.21 where interrupts would
> randomly stop working. We have tracked it down to the new
> msi_set_mask_bit definition in 2.6.21. In the MSI case with a device not
> providing a "native" MSI mask, it was
On Mon, 01 Oct 2007 11:51:48 -0400 bo yang wrote:
> Adding module parameters to configure max sectors per request & # of cmds per
> lun.
>
> Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
>
> ---
> drivers/scsi/megaraid/megaraid_sas.c | 68 -
> drivers/scsi/megaraid/megar
Changes in V2:
- Removed now unnecessary check as suggested by Ken Chen
When shrinking the size of the hugetlb pool via the nr_hugepages sysctl, we
are careful to keep enough pages around to satisfy reservations. But the
calculation is flawed for the following scenario:
Action
On Sunday 09 September 2007, Adrian Bunk wrote:
> noautodma can now be unexported.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
applied
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger
On Wed, Oct 03, 2007 at 07:18:23PM +0100, Hugh Dickins wrote:
> On Wed, 3 Oct 2007, Nick Piggin wrote:
> > On Tue, Oct 02, 2007 at 05:20:03PM -0500, Matt Mackall wrote:
> > > In lib/pagewalk.c, I've been using the various forms of
> > > {pgd,pud,pmd}_none_or_clear_bad while walking page tables as t
On Mon, 1 Oct 2007 02:29:51 +0300
Samuel Ortiz <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> Every IrCOMM socket is registered with the discovery subsystem, so we don't
> need to loop over all of them for every discovery event. We just need to
> do it for the registered IrCOMM socket.
>
> Would yo
On Wed, Oct 03, 2007 at 02:12:03PM -0700, Andrew Morton wrote:
> On Mon, 1 Oct 2007 09:12:56 -0700
> "Keshavamurthy, Anil S" <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Sep 29, 2007 at 05:16:38AM -0700, FUJITA Tomonori wrote:
> > >
> > >x86_64 defines ARCH_HAS_SG_CHAIN. So if IOMMU implementatio
Subject: [patch][Intel-IOMMU] Fix for IOMMU early crash
pci_dev's->sysdata is highly overloaded and currently
IOMMU is broken due to IOMMU code depending on this field.
This patch introduces new field in pci_dev's struct to
hold IOMMU specific per device IOMMU private data.
Signed-off-by: Anil S
Berck E. Nash wrote:
Greetings,
I get a few million of these on boot-- the system never actually boots.
Works fine in 2.6.23-rc7.
[ 50.456012] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 50.462484] ata2.00: irq_stat 0x4001
[ 50.466441] ata2.00: cmd e5/00:00:00:00:00/00
The latest maintenance release GIT 1.5.3.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.3.4.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.3.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.3.4.tar.{gz,bz2}
On Mon, 1 Oct 2007 09:12:56 -0700
"Keshavamurthy, Anil S" <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 29, 2007 at 05:16:38AM -0700, FUJITA Tomonori wrote:
> >
> >x86_64 defines ARCH_HAS_SG_CHAIN. So if IOMMU implementations don't
> >support sg chaining, we will get data corruption.
> >Si
Hi,
We observe a problem with MSI since kernel 2.6.21 where interrupts would
randomly stop working. We have tracked it down to the new
msi_set_mask_bit definition in 2.6.21. In the MSI case with a device not
providing a "native" MSI mask, it was a no-op before, and now it
disables MSI in the MSI-c
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> > An embedded system that does not have user logins but that does
> > have applications that require separation, perhaps a moble communication
> > device with application download capability, is just one example
> > where the smack symlink implementation
Justin Piszcz <[EMAIL PROTECTED]> :
[...]
The bug is fixed in 2.6.23-rc9. Try it.
--
Ueimor
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the F
Update version and changelog.
Updated "LSI Logic" to new name "LSI"
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
Documentation/scsi/ChangeLog.megaraid_sas | 160
drivers/scsi/megaraid/megaraid_sas.c | 10 -
drivers/scsi/megaraid/megaraid_sas.h |8 -
3 fil
Paul,
I ran your original preemption test of RCU torture, and after several
minutes, my preempt boost patch had one Preemption stall. I then
disabled preemption boosting, and ran the preempt torture again, and it
seemed to never stall. Something seemed strange, so I took a look.
Looks like you
Added module parameter "poll_mode_io" to support for "polling" (reduced
interrupt operation).
In this mode, IO completion interrupts are delayed. At the end of
initiating IOs, the
driver schedules for cmd completion if there are pending cmds. A
timer-based interrupt
ha
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> But now (correct me if I'm wrong here) cgroups has a per-cgroup task
> list, and the above loop has cost linear in the number of tasks
> actually in the cgroup, plus (unfortunate but necessary and tolerable)
> the cost of taking a global css_s
On Wed, Oct 03, 2007 at 12:51:08PM -0700, Casey Schaufler wrote:
> > > Because you throw "simple" out the window when you require userland
> > > assistance to perform this function.
> >
> > Any more than having /tmp replaced with a symlink?
>
> Yes. By the way, there's nothing that really require
Andrew - please kill this patch.
Looks like Paul Menage has a better solution
that I will be trying out.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe fro
> What was wrong with my suggestion from a couple of emails back? Adding
> the following in cpuset_attach():
>
> struct cgroup_iter it;
> struct task_struct *p;
> while ((p = cgroup_iter_next(cs->css.cgroup, &it))) {
>set_cpus_allowed(p, cs->cpus_allowed);
> }
> cgroup_iter_end(cs->css.cgr
Driver will call cmd completion routine from Reset path without waiting for cmd
completion from isr context.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 122 +
drivers/scsi/megaraid/megaraid_sas.h |2
2 files changed, 70 ins
MegaRAID utilities expect sense_buff to be of type unsigned long.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff -uprN linux-2.6.22_orig/drivers/scsi/megaraid/megaraid_sas.c
linux-2
> An embedded system that does not have user logins but that does
> have applications that require separation, perhaps a moble communication
> device with application download capability, is just one example
> where the smack symlink implementation provides the required
> function without requiring
1. Setting the max_sectors_per_req based on max SGL supported by the FW. Prior
versions calculated
this value from controller info's max_sectors_1, max_sectors_2. For
certain controllers/FW,
this was resulting in a value greater than max SGL supported by the FW.
Now we take th
Roland Dreier <[EMAIL PROTECTED]> writes:
> > Well it is a bug worth fixing. Who knows it may have something
> > to do with the disable_irq problems the forcedeth driver was seeing.
>
> I agree completely, the fix looks obvious and there's no point in
> leaving the bug there. I just don't have
Adding module parameters to configure max sectors per request & # of cmds per
lun.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 68 -
drivers/scsi/megaraid/megaraid_sas.h |2
2 files changed, 68 insertions(+), 2 deletions(-)
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> So far as I can tell, this patch just removes a minor optimization,
It's not minor for any subsystem that has a non-trivial attach() operation.
>
> Any further suggestions, or embarrassing (;) questions?
>
What was wrong with my suggestion
Driver will skip physical devices scan for the first time if the fast_load is
set. This is to reduce time for loading driver.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 69 +++--
1 files changed, 55 insertions(+), 14 deletions(-)
On Wed, Oct 03, 2007 at 09:27:41PM +0200, Frans Pop wrote:
> On Wednesday 03 October 2007, you wrote:
> > On Wed, 3 Oct 2007, Ilpo Järvinen wrote:
> > > On Wed, 3 Oct 2007, Frans Pop wrote:
> > > > The only change is in 2 consecutive columns: "2911 502" -> "2912
> > > > 500". Is processor usage cal
On Wed, 3 Oct 2007 22:35:24 +0300
"Pekka Enberg" <[EMAIL PROTECTED]> wrote:
> Hi Linus,
>
> On 10/3/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > I would bet that the reason the intel-optimized memcpy triggers this is
> > that the non-temporal stores just means that you go out directly on the
Adding hibernation support. suspend, resume routine implemented.
Signed-off-by: Bo Yang <[EMAIL PROTECTED]>
---
drivers/scsi/megaraid/megaraid_sas.c | 302 +++--
drivers/scsi/megaraid/megaraid_sas.h |1
2 files changed, 233 insertions(+), 70 deletions(-)
diff -uprN linu
--- Alan Cox <[EMAIL PROTECTED]> wrote:
> > Absolute paths in that kind of thing are _wrong_. You know where the
> things
> > are on your fs. You don't know if anything else will be visible, let alone
> > whether it will be at the same place in all chroots or namespaces. And no,
> > you _can't
Just updated jgarzik/misc-2.6.git#ALL...
'ALL' meta-branch contains these branches, exported for review and testing:
dmi-const DMI subsystem constification
--> added your fix/warning patches
isdn-cleanups ISDN subsystem cleanups for 2.6.24
--> no word fr
Paul M wrote:
> Given that later in cpusets.txt you say:
>
> >If hotplug functionality is used
> >to remove all the CPUs that are currently assigned to a cpuset,
> >then the kernel will automatically update the cpus_allowed of all
> >tasks attached to CPUs in that cpuset to allow all CPUs
>
> why
> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> On Wed, 3 Oct 2007, Chuck Ebbert wrote:
>>
>> But we reduce the number of samples because some ticks just never
>> happen when the timers get rounded:
>>
>> No rounding:
>>
>> tick ... tick
>> 1 running
> Well it is a bug worth fixing. Who knows it may have something
> to do with the disable_irq problems the forcedeth driver was seeing.
I agree completely, the fix looks obvious and there's no point in
leaving the bug there. I just don't have a test case that I can point
to as being fixed by t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
What's the state of this patch? I can confirm tst-robust1
from glibc testsuite locks a armv5 machine hard. With this patch
applied, the test succeeds.
> The higher-end archs (x86, sparc64, ppc64, etc) provide fully-functional
> asm/futex.h implementat
Roland Dreier <[EMAIL PROTECTED]> writes:
> > > While reading the MSI code trying to find a reason why MSI wouldn't
> > > work for devices that have a 32-bit MSI address capability, I noticed
> > > that read_msi_msg() seems to read the message data from the wrong
> > > offset in this case.
>
On Wed, 3 Oct 2007, Pekka Enberg wrote:
>
> On 10/3/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > I would bet that the reason the intel-optimized memcpy triggers this is
> > that the non-temporal stores just means that you go out directly on the
> > bus, and it probably just shows a weakness
--- Al Viro <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote:
> > > what
> > > happens if we want it in two chroot jails with different layouts?
> >
> > As you can only have /smack mounted once, this isn't an issue,
> > but it does present an interesti
Andrew-
Could you please add the trace patches to the merge list?
These patches have been very well reviewed on lkml. I believe they are
ready to be merged. The patches can be found here:
http://lkml.org/lkml/2007/10/2/236
http://lkml.org/lkml/2007/10/2/237
http://lkml.org/lkml/2007/10/2/238
Hi Linus,
On 10/3/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> I would bet that the reason the intel-optimized memcpy triggers this is
> that the non-temporal stores just means that you go out directly on the
> bus, and it probably just shows a weakness in the chipset or bus that
> doesn't show
Hi Paul,
I just now found this. I'll take a look immediately. I tried it
on a couple of systems but not margin.
Thanks,
Mike
Paul Jackson wrote:
> Mike,
>
> I think there is a bug either in this ia64 patch, or in the related
> generic arch patch: Convert cpu_sibling_map to be a per cpu varia
On Wed, 3 Oct 2007, Jeff Garzik wrote:
>
> I'm a bit confused... you typed 2.6.24-rc4; I'm guessing you meant
> 2.6.24-rc1, but did you mean
No, I just meant "2.6.24 merge window", so:
> "x86 merge as soon as 2.6.23 is released" (merge window opens)
is the correct interpretation.
It w
On Wednesday 03 October 2007, you wrote:
> On Wed, 3 Oct 2007, Ilpo Järvinen wrote:
> > On Wed, 3 Oct 2007, Frans Pop wrote:
> > > The only change is in 2 consecutive columns: "2911 502" -> "2912
> > > 500". Is processor usage calculated from those? Can someone explain
> > > how?
> >
> > The latter
On Wed, 3 Oct 2007, Pekka Enberg wrote:
> Hi Neil,
>
> On 10/3/07, Neil Romig <[EMAIL PROTECTED]> wrote:
> > > > Thanks for your help on this. I have narrowed it down to commit
> > > > "c22ce143d15eb288543fe9873e1c5ac1c01b69a1 x86: cache pollution aware
> > > > __copy_from_user_ll()". This fits
> > While reading the MSI code trying to find a reason why MSI wouldn't
> > work for devices that have a 32-bit MSI address capability, I noticed
> > that read_msi_msg() seems to read the message data from the wrong
> > offset in this case.
>
> Doh! Sorry about that.
Doesn't matter, it was
Linus Torvalds wrote:
Doing it as early as possible in the 2.6.24-rc4 series (basically I'll do
it first thing) will mean that we'll have the maximum amount of time to
sort out any issues, and the thing is, Thomas and Ingo already have a tree
ready to go, so people can check their work against
On 10/3/07, Dave Hansen <[EMAIL PROTECTED]> wrote:
> > Not quite. Count can never go below the number of reserved pages plus
> > pages allocated to MAP_PRIVATE mappings. That number is computed by:
> > (resv + (total - free)).
>
> So, (total - free) equals the number of MAP_PRIVATE pages? Does t
On ons, 2007-10-03 at 14:04 -0400, Bill Davidsen wrote:
> Ian Kumlien wrote:
> > On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
> >> Remove unneeded check that caused problems with jumbo frame sizes.
> >> The check was recently added and is wrong.
> >> When using jumbo frames the sky2
On 10/3/07, Adam Litke <[EMAIL PROTECTED]> wrote:
> The key is that we don't want to shrink the pool below the number of
> pages we are committed to keeping around. Before this patch, we only
> accounted for the pages we plan to hand out (reserved huge pages) but
> not the ones we've already hande
On Wed, 2007-10-03 at 13:33 -0500, Adam Litke wrote:
> On Wed, 2007-10-03 at 10:40 -0700, Dave Hansen wrote:
> > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > index 84c795e..7af3908 100644
> > > --- a/mm/hugetlb.c
> > > +++ b/mm/hugetlb.c
> > > @@ -224,14 +224,14 @@ static void try_to_free_low(u
Fix ugly sata_mv bug, that exists due to lack of IOMMU knowledge about
device constraints (FUJITA Tomonori's current work should fix this issue
long term, hopefully).
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
t
On Wed, Oct 03, 2007 at 02:09:46PM +1000, Michael Ellerman wrote:
>
> Until we initialise what exactly?
Until we allocate the error log buffer. The original crash was
for a null-pointer deref of the unallocated buffer. I just sent
out a patch to fix this; its a bit simpler than the below.
In t
On Wed, 3 Oct 2007, Balbir Singh wrote:
> Hugh Dickins wrote:
> >
> > Sorry, Balbir, I've failed to get back to you, still attending to
> > priorities. Let me briefly summarize my issue with the mem controller:
> > you've not yet given enough attention to swap.
>
> I am open to suggestions and w
Hi Neil,
On 10/3/07, Neil Romig <[EMAIL PROTECTED]> wrote:
> > > Thanks for your help on this. I have narrowed it down to commit
> > > "c22ce143d15eb288543fe9873e1c5ac1c01b69a1 x86: cache pollution aware
> > > __copy_from_user_ll()". This fits with the errors I'm getting, so now I
> > > need
> >
Roland Dreier <[EMAIL PROTECTED]> wrote on 09/17/2007 02:47:42 PM:
> > > IPoIB CM handles this properly by gathering together single pages
in
> > > skbs' fragment lists.
>
> > Then can we reuse IPoIB CM code here?
>
> Yes, if possible, refactoring things so that the rx skb allocation
> code
Olof Johansson wrote:
Fix bug in sata_mv for cases where the IOMMU layer has merged SG entries
to larger than 64KB. They need to be split up before being sent to
the driver.
Just for simplicity's sake, split up at 64K boundary instead of 64K size,
since that's what the common code does anyway.
sky2 is really the only important fix, the others are trivial.
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/sky2.c |3 ---
drivers/net/w
Pekka Enberg wrote:
Hi Neil,
On 10/3/07, Neil Romig <[EMAIL PROTECTED]> wrote:
Thanks for your help on this. I have narrowed it down to commit
"c22ce143d15eb288543fe9873e1c5ac1c01b69a1 x86: cache pollution aware
__copy_from_user_ll()". This fits with the errors I'm getting, so now I need
to fin
Normally I wait a day or two between pushes, to queue up patches and
also to avoid annoying my upstream :) But this includes a couple fixes
I felt should be upstreamed sooner rather than later.
Please pull from 'upstream' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.
> "AM" == Andrew Morton <[EMAIL PROTECTED]> writes:
AM> On Tue, 02 Oct 2007 23:37:31 +0200 (CEST)
AM> Anders Bostr__m <[EMAIL PROTECTED]> wrote:
>> My computer suffers from high load average when the system is idle,
>> introduced by commit 44d306e1508fef6fa7a6eb15a1aba86ef68389a6 .
>>
On Wed, 2007-10-03 at 10:40 -0700, Dave Hansen wrote:
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 84c795e..7af3908 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -224,14 +224,14 @@ static void try_to_free_low(unsigned long count)
> > for (i = 0; i < MAX_NUMNODES; ++i) {
Summary: a random hanging bug when receiving multicast datagrams on
2.6.x kernels.
Keywards: hang, networking, kernel, multicast, recv, multicast loopback,
poll hang, select hang
Kernel version: 2.6.x
Full description of the problem:
---
* This simple
Linus Torvalds wrote:
On Wed, 3 Oct 2007, Arjan van de Ven wrote:
not sure this is going to help; I mean, the load gets only updated in actual
timer interrupts... and on a tickless system there's very few of those
around. and usually at places round_jiffies() already put a timer on.
Yeah,
On Wed, 3 Oct 2007, Arjan van de Ven wrote:
>
> not sure this is going to help; I mean, the load gets only updated in actual
> timer interrupts... and on a tickless system there's very few of those
> around. and usually at places round_jiffies() already put a timer on.
Yeah, you're right. A
On 10/3/07, Paul Menage <[EMAIL PROTECTED]> wrote:
>
> What's wrong with, in update_cpumask(), doing a loop across all
> members of the cgroup and updating their cpus_allowed fields?
i.e. something like:
struct cgroup_iter it;
struct task_struct *p;
while ((p = cgroup_iter_next(cs->css.cgroup, &i
Roland Dreier <[EMAIL PROTECTED]> writes:
> While reading the MSI code trying to find a reason why MSI wouldn't
> work for devices that have a 32-bit MSI address capability, I noticed
> that read_msi_msg() seems to read the message data from the wrong
> offset in this case.
Doh! Sorry about that
Linus Torvalds wrote:
Without this, I can easily imagine that the rounding code tends to try to
round to an even second, and the load-average code generally also runs at
even seconds!
Linus
---
include/linux/sched.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
> (irq_stat 0x4001)
IRQ status of the chip
> tag 0
Tag (or zero for non NCQ commands)
> cmd 0xb0
The ATA command number issued
> emask 0x1
Internal libata error category (used to decide what to do to
recover)
> stat 0x51
Status register of drive
> err 0
One more well tested Ocfs2 fix to get in before 2.6.24.
Thanks,
--Mark
Please pull from 'upstream-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/mfasheh/ocfs2.git upstream-linus
to receive the following updates:
fs/ocfs2/localalloc.c |4 +++-
1 files changed, 3 inse
On Wed, 3 Oct 2007, Nick Piggin wrote:
> On Tue, Oct 02, 2007 at 05:20:03PM -0500, Matt Mackall wrote:
> > In lib/pagewalk.c, I've been using the various forms of
> > {pgd,pud,pmd}_none_or_clear_bad while walking page tables as that
> > seemed the canonical way to do things. Lately (eg with -rc7-mm
On Wed, Oct 03, 2007 at 07:17:35PM +0100, Alan Cox wrote:
> > Absolute paths in that kind of thing are _wrong_. You know where the things
> > are on your fs. You don't know if anything else will be visible, let alone
> > whether it will be at the same place in all chroots or namespaces. And no,
> Absolute paths in that kind of thing are _wrong_. You know where the things
> are on your fs. You don't know if anything else will be visible, let alone
> whether it will be at the same place in all chroots or namespaces. And no,
> you _can't_ make sure that fs is visible only in one place. N
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> So after changing the 'cpus' of a cpuset, you (something in
> user space) then has to rewrite every pid in that cpusets
> tasks file back to that same tasks file, in order to get the
> change to be applied to each of those tasks, and get them
On 10/3/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
>
> Yes, something in user space has to do it. It's part of the
> kernel-user cpuset API. If you change a cpuset's 'cpus', then
> you have to rewrite each pid in its 'tasks' file back to that
> 'tasks' file in order to get that 'cpus' change to
On Wed, 03 Oct 2007 18:19:01 +0400 Pavel Emelyanov wrote:
> This is a pid which is attached to tasks when they detach
> their pids. This is done in detach_pid() and transfer_pid().
> The pid_alive() check is changed to reflect this fact.
>
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
>
>
> > Replace struct ibmebus_dev and struct ibmebus_driver with struct of_device
> > and struct of_platform_driver, respectively. Match the external ibmebus
> > interface and drivers using it.
> >
> > Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
>
> If not, then you need to get an Acked
On 10/3/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 07:36:55PM +0200, Torsten Kaiser wrote:
> > Of note might be, that at the time of this error init has not been
> > started. I'm using a program from initramfs to start the RAID.
> > The initramfs was primarily build using
On Wed, 3 Oct 2007, Chuck Ebbert wrote:
>
> But we reduce the number of samples because some ticks just never
> happen when the timers get rounded:
>
> No rounding:
>
> tick ... tick
> 1 running1 running
>
> Rounded:
>
> tick
> 2 running
>
> In
On Wed, 3 Oct 2007, Yasunori Goto wrote:
> >
> > That would work. But it would be better to shrink the cache first. The
> > first 2 slabs on a node may be empty and the shrinking will remove those.
> > If you do not shrink then the code may falsely assume that there are
> > objects on the node
this is the second part of the patch to replace latency.c use with
pm_qos_params use.
--mgross
Signed-off-by: mark gross <[EMAIL PROTECTED]>
---
diff -urN -X linux-2.6.23-rc8/Documentation/dontdiff
linux-2.6.23-rc8-qos/drivers/acpi/processor_idle.c
linux-2.6.23-rc8-qos-nolatency.c/
Ian Kumlien wrote:
On tis, 2007-10-02 at 18:02 -0700, Stephen Hemminger wrote:
Remove unneeded check that caused problems with jumbo frame sizes.
The check was recently added and is wrong.
When using jumbo frames the sky2 driver does fragmentation, so
rx_data_size is less than mtu.
Confirmed w
Paul M wrote:
> > The code in kernel/cgroup.c attach_task() which skips the
> > attachment of a task to the group it is already in has to be
> > removed. Cpusets depends on reattaching a task to its current
> > cpuset, in order to trigger updating the cpus_allowed mask in the
> > task struct.
>
>
Mike Robak wrote:
Does a doc exist that provides a detailed description of the different
errors that could be produced by libata and its associated drivers?
The libATA developer's guide provides a very good general description
of the types of messages, but I'm looking for more detail.
For exampl
On Wed, Oct 03, 2007 at 10:21:08AM -0700, Casey Schaufler wrote:
> > what
> > happens if we want it in two chroot jails with different layouts?
>
> As you can only have /smack mounted once, this isn't an issue,
> but it does present an interesting use case that brings the one
> mount limitation in
On Tue, Oct 02, 2007 at 08:10:23PM -0700, David Miller wrote:
> From: [EMAIL PROTECTED]
> Date: Tue, 2 Oct 2007 19:49:06 -0700
>
> >
> > Pass a "dmabarrier" argument to ib_umem_get() and use the new
> > argument to control setting the DMA_BARRIER_ATTR attribute on
> > the memory that ib_umem_ge
On Wed, Oct 03, 2007 at 07:36:55PM +0200, Torsten Kaiser wrote:
> On 10/3/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
> > On Wed, Oct 03, 2007 at 05:55:10PM +0200, Torsten Kaiser wrote:
> > > This patch removes clear_refs_smap() from fs/proc/task_mmu.c by moving
> > > its code to a new function. Bu
Paul M wrote:
> Are there cases when userspace is
> required to try to reattach a task to its current cpuset in order to
> get a cpu mask change to stick?
Yes, there are such cases.
If tasks are running in a cpuset, and someone changes the
'cpus' of that cpuset, the tasks already in that cpuset d
Nick wrote:
> So if a new pdflush is spawned, it get's moved to some cpuset? That
> probably isn't something these realtime systems want to do (ie. the
> non-realtime portion probably doesn't want to have any sort of scheduler
> or even worry about cpusets at all).
No - the new pdflush is put in t
Nick wrote:
> There won't be any CPU cycles used, if the tasks are paused (surely
> they're not spin waiting).
Consider the case when there are two, smaller, non-overlapping cpusets
with active jobs, and one larger cpuset, covering both those smaller
ones, with only paused tasks.
If we realize we
101 - 200 of 380 matches
Mail list logo
