On Sep 10, 2013, at 12:45 AM, "Koen Kooi" wrote:
>
> Op 10 sep. 2013, om 01:42 heeft Joel Fernandes het volgende
> geschreven:
>
>> On 09/09/2013 03:12 PM, Joel Fernandes wrote:
>>> On 09/09/2013 03:00 PM, Koen Kooi wrote:
Op 9 sep. 2013, om 21:50 heeft Joel Fernandes het
On 09/09/2013 10:39 PM, Wei Ni wrote:
On 09/10/2013 12:50 PM, Guenter Roeck wrote:
On 09/09/2013 09:05 PM, Wei Ni wrote:
On 09/10/2013 04:39 AM, Mark Brown wrote:
* PGP Signed by an unknown key
On Mon, Sep 09, 2013 at 09:17:35AM -0700, Guenter Roeck wrote:
On Mon, Sep 09, 2013 at 05:02:37PM
Op 10 sep. 2013, om 01:42 heeft Joel Fernandes het volgende
geschreven:
> On 09/09/2013 03:12 PM, Joel Fernandes wrote:
>> On 09/09/2013 03:00 PM, Koen Kooi wrote:
>>>
>>> Op 9 sep. 2013, om 21:50 heeft Joel Fernandes het volgende
>>> geschreven:
>>>
On 09/09/2013 01:51 PM, Joel
(2013/09/09 18:07), David Woodhouse wrote:
> On Wed, 2013-08-21 at 16:15 +0900, Takao Indoh wrote:
>>
>> This causes problem on kdump. Devices are working in first kernel, and
>> after switching to second kernel and initializing IOMMU, many DMAR faults
>> occur and it causes problems like driver
On Mon, Sep 09, 2013 at 02:44:03PM +, Christoph Lameter wrote:
> On Mon, 9 Sep 2013, Joonsoo Kim wrote:
>
> > 32 byte is not minimum object size, minimum *kmalloc* object size
> > in default configuration. There are some slabs that their object size is
> > less than 32 byte. If we have a 8
On 09/10/2013 01:22 PM, Igor Gnatenko wrote:
> On Tue, 2013-09-10 at 13:16 +0800, Aaron Lu wrote:
>> On 09/10/2013 01:13 PM, Igor Gnatenko wrote:
>>> On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> On Mon, 2013-09-09 at 16:42 +0800, Aaron
On 09/10/2013 12:50 PM, Guenter Roeck wrote:
> On 09/09/2013 09:05 PM, Wei Ni wrote:
>> On 09/10/2013 04:39 AM, Mark Brown wrote:
>>> * PGP Signed by an unknown key
>>>
>>> On Mon, Sep 09, 2013 at 09:17:35AM -0700, Guenter Roeck wrote:
On Mon, Sep 09, 2013 at 05:02:37PM +0100, Mark Brown
On Tue, 10 Sep 2013 13:00:52 +0800 y b wrote:
> When raid5 hit a fresh badblock, this badblock will flagged as unack
> badblock until md_update_sb is called.
> But md_stop/reboot/md_set_readonly will avoid raid5d call md_update_sb
> in md_check_recovery, the badblock will always be unack, so
On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows [8] doesn't use the ACPI
On Mon, 2013-09-09 at 16:40 +0800, Aaron Lu wrote:
> The backlight control and event delivery functionality provided by ACPI
> video module is mixed together and registered all during video device
> enumeration time. As a result, the two functionality are also removed
> together on module unload
On Tue, 2013-09-10 at 13:16 +0800, Aaron Lu wrote:
> On 09/10/2013 01:13 PM, Igor Gnatenko wrote:
> > On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
> >> On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> >>> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
> diff --git
ret == 0 means success, anything else is failure.
Signed-off-by: navin patidar
---
drivers/staging/usbip/stub_main.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/usbip/stub_main.c
b/drivers/staging/usbip/stub_main.c
index 33027cc..baf857f 100644
ret == 0 means success, anything else is failure.
Signed-off-by: navin patidar
---
drivers/staging/usbip/vhci_hcd.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c
index d7974cb..b3c9217 100644
---
On 09/10/2013 01:13 PM, Igor Gnatenko wrote:
> On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
>> On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
>>> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
diff --git a/drivers/gpu/drm/i915/i915_dma.c
b/drivers/gpu/drm/i915/i915_dma.c
On Tue, 2013-09-10 at 11:27 +0800, Aaron Lu wrote:
> On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> > On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
> >> diff --git a/drivers/gpu/drm/i915/i915_dma.c
> >> b/drivers/gpu/drm/i915/i915_dma.c
> >> index f466980..75fba17 100644
> >> ---
vhci_hcd is a virtual usb host controller, so no need to
check for dma.
Signed-off-by: navin patidar
---
drivers/staging/usbip/vhci_hcd.c |6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/staging/usbip/vhci_hcd.c b/drivers/staging/usbip/vhci_hcd.c
index b3c9217..e810ad5 100644
Hi all,
Please do not add any code for v3.13 to your linux-next included branches
until after v3.12-rc1 is released.
Changes since 20130909:
The vfs tree lost its build failure.
The dmaengine tree gained a conflict against the slave-dma tree.
The akpm tree gained conflicts against the vfs
Hey Linus,
Back from the longish weekend here, so time to send you the pull request.
Okay we have fairly longish pull this time, and NO recent rebase which got you
annoyed last time :(
This pull brings:
- Andy's DW driver updates
- Guennadi's sh driver updates
- Pl08x driver fixes from Tomasz &
When raid5 hit a fresh badblock, this badblock will flagged as unack
badblock until md_update_sb is called.
But md_stop/reboot/md_set_readonly will avoid raid5d call md_update_sb
in md_check_recovery, the badblock will always be unack, so raid5d
thread enter a infinite loop and never can
On 09/09/2013 09:05 PM, Wei Ni wrote:
On 09/10/2013 04:39 AM, Mark Brown wrote:
* PGP Signed by an unknown key
On Mon, Sep 09, 2013 at 09:17:35AM -0700, Guenter Roeck wrote:
On Mon, Sep 09, 2013 at 05:02:37PM +0100, Mark Brown wrote:
It does, though it gets complicated trying to use it for
On Tue, Sep 10, 2013 at 02:02:54PM +1000, Dave Chinner wrote:
> Hi folks,
>
> I just updated my performance test VM to the current 3.12-git
> tree after the XFS dev branch was merged. The first test I ran
> which was a 16-way concurrent fsmark test to create lots of files
> gave me a number about
On 09/09/2013 09:13 PM, Stephen Warren wrote:
On 09/09/2013 09:53 PM, Guenter Roeck wrote:
On 09/09/2013 08:40 PM, Stephen Warren wrote:
On 09/09/2013 09:36 PM, Guenter Roeck wrote:
...
My understanding is that by adding regulator support you essentially
committed to adding regulators (if
Currently seqlocks and seqcounts don't support lockdep.
After running across a seqcount related deadlock in the timekeeping
code, I used a less-refined and more focused varient of this patch
to narrow down the cause of the issue.
This is a first-pass attempt to properly enable lockdep
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/super.c
between commit d040790391f2 ("prune_super(): sb->s_op is never NULL")
from the vfs tree and commit "fs: convert inode and dentry shrinking to
be node aware" from the akpm tree.
I fixed it up (see below) and can
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/dcache.c
between commit 8aab6a27332b ("vfs: reorganize dput() memory accesses")
from Linus' tree and commit "dcache: convert to use new lru list
infrastructure" from the akpm tree.
/me mutters about development happening
On 09/10/2013 12:35 PM, Wei Ni wrote:
> On 09/09/2013 06:57 PM, Ramkumar Ramachandra wrote:
>> Wei Ni wrote:
>>> diff --git a/Documentation/devicetree/bindings/hwmon/lm90.txt
>>> b/Documentation/devicetree/bindings/hwmon/lm90.txt
>>> new file mode 100644
>>> index 000..5570875
>>> ---
On 09/09/2013 06:57 PM, Ramkumar Ramachandra wrote:
> Wei Ni wrote:
>> diff --git a/Documentation/devicetree/bindings/hwmon/lm90.txt
>> b/Documentation/devicetree/bindings/hwmon/lm90.txt
>> new file mode 100644
>> index 000..5570875
>> --- /dev/null
>> +++
On 09/10/2013 06:23 AM, Guenter Roeck wrote:
> On Mon, Sep 09, 2013 at 04:15:57PM -0600, Stephen Warren wrote:
>> On 09/09/2013 04:29 AM, Wei Ni wrote:
>>> Add OF document for LM90 in Documentation/devicetree/.
>>
>>> diff --git a/Documentation/devicetree/bindings/hwmon/lm90.txt
>>>
On 09/10/2013 06:14 AM, Stephen Warren wrote:
> On 09/09/2013 04:52 AM, Guenter Roeck wrote:
>> On 09/09/2013 03:29 AM, Wei Ni wrote:
>>> Add OF document for LM90 in Documentation/devicetree/.
>
>>> diff --git a/Documentation/devicetree/bindings/hwmon/lm90.txt
>
>>> +* LM90 series thermometer.
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/dcache.c
between commits 8aab6a27332b ("vfs: reorganize dput() memory accesses")
and 0d98439ea3c6 ("vfs: use lockred "dead" flag to mark unrecoverably
dead dentries") from Linus' tree and commit "dcache: remove dentries
The following changes since commit d8dfad3876e438b759da3c833d62fb8b2267:
Linux 3.11-rc7 (2013-08-25 17:43:22 -0700)
are available in the git repository at:
git://neil.brown.name/md/ tags/md/3.12
for you to fetch changes up to bfc90cb0936f5b972706625f38f72c7cb726c20a:
raid5: only
On 09/09/2013 09:53 PM, Guenter Roeck wrote:
> On 09/09/2013 08:40 PM, Stephen Warren wrote:
>> On 09/09/2013 09:36 PM, Guenter Roeck wrote:
...
>>> My understanding is that by adding regulator support you essentially
>>> committed to adding regulators (if necessary dummy ones) for this driver
>>>
On 09/10/2013 11:53 AM, Guenter Roeck wrote:
> On 09/09/2013 08:40 PM, Stephen Warren wrote:
>> On 09/09/2013 09:36 PM, Guenter Roeck wrote:
>>> On 09/09/2013 08:22 PM, Wei Ni wrote:
On 09/09/2013 11:50 PM, Guenter Roeck wrote:
> On Mon, Sep 09, 2013 at 02:50:22PM +0100, Mark Brown wrote:
[ Just adding Dave Chinner to the cc list]
On Tue, 10 Sep 2013 14:09:23 +1000 Stephen Rothwell
wrote:
>
> Hi Andrew,
>
> Today's linux-next merge of the akpm tree got a conflict in fs/dcache.c
> between commit 8aab6a27332b ("vfs: reorganize dput() memory accesses")
> from Linus' tree and
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in fs/dcache.c
between commit 8aab6a27332b ("vfs: reorganize dput() memory accesses")
from Linus' tree and commit "dentry: move to per-sb LRU locks" from the
akpm tree.
I fixed it up (I think - see below) and can carry the fix
On Mon, 2013-09-09 at 14:49 +, Christoph Lameter wrote:
> Its just that PREEMPT kernels are
> not in use and AFAICT the full preempt stuff requires significant developer
> support and complicates the code without much benefit.
The openSUSE desktop kernel is PREEMPT, and presumably has users.
On 09/10/2013 04:39 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Mon, Sep 09, 2013 at 09:17:35AM -0700, Guenter Roeck wrote:
>> On Mon, Sep 09, 2013 at 05:02:37PM +0100, Mark Brown wrote:
>
>>> It does, though it gets complicated trying to use it for a case like
>>> this since
Acked-by: Hirokazu Takata
Sorry, it is my old mistake that still remained in the m32r kernel.
Please apply this patch.
Thanks,
-- Takata
From: Ben Hutchings
Subject: [112/121] m32r: consistently use "suffix-$(...)"
Date: Sun, 08 Sep 2013 03:52:01 +0100
> 3.2.51-rc1 review patch. If anyone
Hi folks,
I just updated my performance test VM to the current 3.12-git
tree after the XFS dev branch was merged. The first test I ran
which was a 16-way concurrent fsmark test to create lots of files
gave me a number about 30% lower than I expected - ~180k files/s
when I was expecting somewhere
On 09/09/2013 08:40 PM, George Spelvin wrote:
I'm really wondering about only trying once before taking the write lock.
Yes, using the lsbit is a cute hack, but are we using it for its cuteness
rather than its effectiveness?
Renames happen occasionally. If that causes all the current pathname
Hi Tom,
On Mon, Sep 9, 2013 at 3:01 PM, Tom Gundersen wrote:
> During the last merge window (3.12) a couple of modules gained devname
> aliases, but without the necessary major and minor information. These were
> then silently ignored when generating modules.devname.
>
> Complain loudly to avoid
On 09/10/2013 07:36 AM, Michael Ellerman wrote:
> On Fri, 2013-08-30 at 09:54 +0530, Anshuman Khandual wrote:
>> This patchset is the re-spin of the original branch stack sampling
>> patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This patchset
>> also enables SW based branch
On 09/09/2013 08:40 PM, Stephen Warren wrote:
On 09/09/2013 09:36 PM, Guenter Roeck wrote:
On 09/09/2013 08:22 PM, Wei Ni wrote:
On 09/09/2013 11:50 PM, Guenter Roeck wrote:
On Mon, Sep 09, 2013 at 02:50:22PM +0100, Mark Brown wrote:
On Mon, Sep 09, 2013 at 04:34:43AM -0700, Guenter Roeck
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/27/2013 09:24 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki Subject: ACPI: Move
> acpi_bus_get_device()
> from bus.c to scan.c
>
> Move acpi_bus_get_device() from bus.c to scan.c which allows
> acpi_bus_data_handler() to become
>
On Mon, 2013-09-09 at 20:09 -0700, David Lang wrote:
> On Tue, 10 Sep 2013, Matthew Garrett wrote:
> > Someone adds a new "install_evil()" syscall and adds a disable bit. If I
> > don't disable it, I'm now vulnerable. Please pay attention to earlier
> > discussion.
>
> so instead they add
/sys/kernel/slab/:t-048 # cat cpu_slabs
231 N0=16 N1=215
/sys/kernel/slab/:t-048 # cat slabs
145 N0=36 N1=109
See, the number of slabs is smaller than that of cpu slabs.
The bug was introduced by commit 49e2258586b423684f03c278149ab46d8f8b6700
("slub: per cpu cache for partial
On 09/09/2013 09:36 PM, Guenter Roeck wrote:
> On 09/09/2013 08:22 PM, Wei Ni wrote:
>> On 09/09/2013 11:50 PM, Guenter Roeck wrote:
>>> On Mon, Sep 09, 2013 at 02:50:22PM +0100, Mark Brown wrote:
On Mon, Sep 09, 2013 at 04:34:43AM -0700, Guenter Roeck wrote:
> On 09/09/2013 04:12 AM,
On 09/09/2013 08:22 PM, Wei Ni wrote:
On 09/09/2013 11:50 PM, Guenter Roeck wrote:
On Mon, Sep 09, 2013 at 02:50:22PM +0100, Mark Brown wrote:
On Mon, Sep 09, 2013 at 04:34:43AM -0700, Guenter Roeck wrote:
On 09/09/2013 04:12 AM, Mark Brown wrote:
On Mon, Sep 09, 2013 at 06:29:11PM +0800,
(2013/09/10 12:31), Yasuaki Ishimatsu wrote:
> (2013/09/10 9:24), Toshi Kani wrote:
>> cpu_up() has #ifdef CONFIG_MEMORY_HOTPLUG code blocks, which
>> call mem_online_node() to put its node online if offlined and
>> then call build_all_zonelists() to initialize the zone list.
>> These steps are
(2013/09/10 9:24), Toshi Kani wrote:
> cpu_up() has #ifdef CONFIG_MEMORY_HOTPLUG code blocks, which
> call mem_online_node() to put its node online if offlined and
> then call build_all_zonelists() to initialize the zone list.
> These steps are specific to memory hotplug, and should be
> managed
On 09/09/2013 07:44 PM, Igor Gnatenko wrote:
> On Mon, 2013-09-09 at 16:42 +0800, Aaron Lu wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_dma.c
>> b/drivers/gpu/drm/i915/i915_dma.c
>> index f466980..75fba17 100644
>> --- a/drivers/gpu/drm/i915/i915_dma.c
>> +++ b/drivers/gpu/drm/i915/i915_dma.c
On 09/09/2013 11:50 PM, Guenter Roeck wrote:
> On Mon, Sep 09, 2013 at 02:50:22PM +0100, Mark Brown wrote:
>> On Mon, Sep 09, 2013 at 04:34:43AM -0700, Guenter Roeck wrote:
>>> On 09/09/2013 04:12 AM, Mark Brown wrote:
On Mon, Sep 09, 2013 at 06:29:11PM +0800, Wei Ni wrote:
>>
This
From: Lan Tianyu
This patch is to use pr_debug/info/warn/err to replace acpiphp debug
functions and remove module's debug param.
Signed-off-by: Lan Tianyu
---
drivers/pci/hotplug/acpiphp.h | 10 --
drivers/pci/hotplug/acpiphp_core.c | 35 +--
From: Lan Tianyu
This patch is to convert internal debug macros to dynamic debug function
and remove module's debug param.
Signed-off-by: Lan Tianyu
---
drivers/pci/hotplug/acpiphp_ibm.c | 56 ---
1 file changed, 23 insertions(+), 33 deletions(-)
diff
Linus Torvalds wrote:
> It doesn't need to. The RCU lookup looks at individual dentry sequence
> numbers and doesn't care about the bigger rename sequence number at
> all.
Right; it's sequential.
> The fallback (if you hit one of the very very rare races, or if you
> hit a symlink) ends up doing
On Tue, 10 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 19:44 -0700, David Lang wrote:
On Tue, 10 Sep 2013, Matthew Garrett wrote:
No. Say someone adds an additional lockdown bit to forbid raw access to
mounted block devices. The "Turn everything off" approach now means that
I won't
On Mon, 2013-09-09 at 19:44 -0700, David Lang wrote:
> On Tue, 10 Sep 2013, Matthew Garrett wrote:
> > No. Say someone adds an additional lockdown bit to forbid raw access to
> > mounted block devices. The "Turn everything off" approach now means that
> > I won't be able to perform raw access to
On Mon, Sep 9, 2013 at 7:15 PM, Peter Zijlstra wrote:
> On Mon, Sep 02, 2013 at 02:26:45PM +0800, Lei Wen wrote:
>> Hi Peter,
>>
>> I find one list API usage may not be correct in current fair.c code.
>> In move_one_task function, it may iterate through whole cfs_tasks
>> list to get one task to
On Tue, 10 Sep 2013, Matthew Garrett wrote:
On Mon, 2013-09-09 at 16:19 -0700, David Lang wrote:
On Mon, 9 Sep 2013, Matthew Garrett wrote:
Having thought about this, the answer is no. It presents exactly the
same problem as capabilities do - the set can never be meaningfully
extended. If an
On Mon, Sep 09, 2013 at 04:24:18PM +0100, Sudeep KarkadaNagesha wrote:
> Hi Shawn,
>
> Ok. But I am bit suspicious about devm_clk_get(cpu_dev, NULL).
> I don't understand completely as how the clock are registered(whether
> with dev_id or with connection_id).
As the connection_id of
> Subject: Re: [PATCHv3 1/4] pwm: Add Freescale FTM PWM driver support
>
> On Mon, Sep 09, 2013 at 02:20:09PM +0200, Thierry Reding wrote:
> > On Fri, Sep 06, 2013 at 04:08:24PM +0800, Xiubo Li wrote:
> > > The FTM PWM device can be found on Vybrid VF610 Tower and Layerscape
> LS-1 SoCs.
> > >
>
On Mon, Sep 9, 2013 at 7:25 PM, Al Viro wrote:
>
> One name: Mark V. Shaney...
Heh, yes. I had ignored the earlier emails, and that last one looked
more reasonable than the earlier ones ;)
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Sun, Sep 08, 2013 at 11:22:23PM +0800, Jiang Liu wrote:
> From: Jiang Liu
>
> Commit f44310b98ddb7 "smp: Fix SMP function call empty cpu mask race"
> introduced field call_function_data->cpumask_ipi to resolve a race
> condition in smp_call_function_many().
>
> Later commit 9a46ad6d6df3
On Mon, Sep 09, 2013 at 06:34:16PM -0700, Linus Torvalds wrote:
> On Mon, Sep 9, 2013 at 6:15 PM, Ramkumar Ramachandra
> wrote:
> >
> > Maybe it should then?
>
> It doesn't need to. The RCU lookup looks at individual dentry sequence
> numbers and doesn't care about the bigger rename sequence
On Fri, 2013-08-30 at 09:54 +0530, Anshuman Khandual wrote:
> This patchset is the re-spin of the original branch stack sampling
> patchset which introduced new PERF_SAMPLE_BRANCH_COND filter. This patchset
> also enables SW based branch filtering support for PPC64 platforms which have
>
On 09/05/2013 07:26:22 AM, Xishi Qiu wrote:
Fix some typos in
Documentation/IRQ-domain.txt/email-clients.txt/io-mapping.txt
Signed-off-by: Xishi Qiu
---
Documentation/IRQ-domain.txt|4 ++--
Documentation/email-clients.txt |2 +-
Documentation/io-mapping.txt|2 +-
3 files
On Tue, Sep 10, 2013 at 09:52:35AM +0800, Libin wrote:
> From: Li Bin
>
> When one work starts execution, the high bits of work's data contain
> pool ID. It can represent a maximum of WORK_OFFQ_POOL_NONE. Pool ID
> is assigned WORK_OFFQ_POOL_NONE when the work being initialized
> indicating that
Hi Dan,
Today's linux-next merge of the dmaengine tree got a conflict in
include/linux/dmaengine.h between commit 7bb587f4eef8 ("dmaengine: add
interface of dma_get_slave_channel") from the slave-dma tree and commit
4a43f394a082 ("dmaengine: dma_sync_wait and dma_find_channel undefined")
from the
From: Li Bin
When one work starts execution, the high bits of work's data contain
pool ID. It can represent a maximum of WORK_OFFQ_POOL_NONE. Pool ID
is assigned WORK_OFFQ_POOL_NONE when the work being initialized
indicating that no pool is associated and get_work_pool() uses it to
check the
On 09/09/13 21:41, Christoph Hellwig wrote:
>> Modules linked in: oracleacfs(P)(U) oracleadvm(P)(U) oracleoks(P)(U)
>
> Please reproduce without this weird crap loaded.
>
These modules is filesystem and will not impact enclosure.
Thanks,
Joe
--
To unsubscribe from this list: send the line
drivers/of/of_reserved_mem.c:14:32: fatal error: asm/dma-contiguous.h: No such
file or directory
#include
Seen with
arm64:defconfig
mips:nlm_xlp_defconfig
mips:cavium_octeon_defconfig
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Mon, 2013-09-09 at 14:07 -0700, Jason Low wrote:
> On Mon, 2013-09-09 at 13:49 +0200, Peter Zijlstra wrote:
> > On Wed, Sep 04, 2013 at 12:10:01AM -0700, Jason Low wrote:
> > > On Fri, 2013-08-30 at 12:18 +0200, Peter Zijlstra wrote:
> > > > On Thu, Aug 29, 2013 at 01:05:36PM -0700, Jason Low
powerpc allmodconfig build fails with:
ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
The problem was introduced with commit 15863ff3b (powerpc: Make chip-id
information available to userspace).
Export the missing symbol.
Cc: Vasant Hegde
Cc: Shivaprasad G Bhat
On Tuesday, September 10, 2013 01:12:49 AM Rafael J. Wysocki wrote:
> On Monday, September 09, 2013 11:42:41 PM Guennadi Liakhovetski wrote:
> > Hi Rafael
> >
> > On Mon, 9 Sep 2013, Rafael J. Wysocki wrote:
> >
> > > Hi,
> > >
> > > On Monday, September 09, 2013 05:11:10 PM Guennadi
On Mon, Sep 9, 2013 at 6:15 PM, Ramkumar Ramachandra wrote:
>
> Maybe it should then?
It doesn't need to. The RCU lookup looks at individual dentry sequence
numbers and doesn't care about the bigger rename sequence number at
all.
The fallback (if you hit one of the very very rare races, or if
Commit(88d2613) removed the pm_runtime_put_sync() from pci_pm_complete()
to PM core code device_complete().
Here the pci_pm_complete() is doing the same work which can be done in
device_complete(), so we can remove it directly.
Signed-off-by: liu chuansheng
---
drivers/pci/pci-driver.c |9
On 09/09/2013 04:55 PM, Asai Thambi S P wrote:
On 09/08/2013 5:28 PM, Guenter Roeck wrote:
Hi all,
powerpc allmodconfig build on the latest upstream kernel results in:
ERROR: ".cpu_to_chip_id" [drivers/block/mtip32xx/mtip32xx.ko] undefined!
This is due to commit 15863ff3b (powerpc: Make
Al Viro wrote:
> _What_ "pathname translations"? Pathname resolution doesn't fall back to
> seq_writelock() at all.
Maybe it should then?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
于 2013年09月09日 21:02, Lee Jones 写道:
#define PHY_FLD4 0x1E
>+#define FLDEN_SEL 0x4000
>+#define REQ_REF 0x2000
>+#define RXAMP_OFF 0x1000
>+#define REQ_ADDA 0x0800
>+#define BER_COUNT
On 2013/9/9 22:55, Marciniszyn, Mike wrote:
>> Subject: [PATCH 4/6] IB/qib: Use pcie_set_mps() and pcie_get_mps() to
>> simplify
>> code
>>
>> Refactor qib_tune_pcie_caps() function, use pcie_set_mps() and
>> pcie_get_mps() to simply code. Because pci core caches the "PCI-E Max
>> Payload Size
Hi,
2013-09-07 (토), 08:00 +, Chao Yu:
> Hi Knize,
>
> Thanks for your reply, I think it's actually meaningless that it's
> being named after "spin_lock",
> it's better to rename this spinlock to "round_robin_lock".
>
> This patch can only resolve the issue of unbalanced fs_lock
From: Andi Kleen
With checkpointed counters there can be a situation where the counter
is overflowing, aborts the transaction, is set back to a non overflowing
checkpoint, causes interupt. The interrupt doesn't see the overflow
because it has been checkpointed. This is then a spurious PMI,
On Mon, Sep 09, 2013 at 08:40:20PM -0400, George Spelvin wrote:
> I'm really wondering about only trying once before taking the write lock.
> Yes, using the lsbit is a cute hack, but are we using it for its cuteness
> rather than its effectiveness?
>
> Renames happen occasionally. If that causes
Hi Linus,
The following changes since commit c095ba7224d8edc71dcef0d655911399a8bd4a3f:
Linux 3.11-rc4 (2013-08-04 13:46:46 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine
tags/dmaengine-3.12
for you to fetch changes up to
Hi,
Nice catch.
This is definitely a bug where one thread grabbed two fs_locks across
the same flow.
Any idea?
Thanks,
2013-09-06 (금), 14:25 -0500, Russ Knize:
> I encountered this same issue recently and solved it in much the same
> way. Can we rename "spin_lock" to something more meaningful?
On Mon, 2013-09-09 at 16:19 -0700, David Lang wrote:
> On Mon, 9 Sep 2013, Matthew Garrett wrote:
> > Having thought about this, the answer is no. It presents exactly the
> > same problem as capabilities do - the set can never be meaningfully
> > extended. If an application sets only the bits it
Hi,
At first, thank you for the report and please follow the email writing
rules. :)
Anyway, I agree to the below issue.
One thing that I can think of is that we don't need to use the
spin_lock, since we don't care about the exact lock number, but just
need to get any not-collided number.
So,
Hi Ben, Al,
On 09/10/2013 12:02 AM, Benjamin LaHaise wrote:
> Hi Al, Gu,
>
> I've added this patch to my tree at git://git.kvack.org/~bcrl/aio-next.git
> to fix the get_user_pages() issue introduced by Gu's changes in the page
> migration patch. Thanks Al for spotting this.
Thanks very much
I'm really wondering about only trying once before taking the write lock.
Yes, using the lsbit is a cute hack, but are we using it for its cuteness
rather than its effectiveness?
Renames happen occasionally. If that causes all the current pathname
translations to fall back to the write lock,
Hello Tejun,
On 2013/9/9 22:14, Tejun Heo wrote:
> On Mon, Sep 09, 2013 at 01:12:14PM +0800, Libin wrote:
>> From: Li Bin
>>
>> When one work starts execution, the high bits of work's data contain
>> pool ID. It can represent a maximum of WORK_OFFQ_POOL_NONE. Pool ID
>> is assigned
cpu_up() has #ifdef CONFIG_MEMORY_HOTPLUG code blocks, which
call mem_online_node() to put its node online if offlined and
then call build_all_zonelists() to initialize the zone list.
These steps are specific to memory hotplug, and should be
managed in mm/memory_hotplug.c. lock_memory_hotplug()
On 2013/9/9 22:18, Tejun Heo wrote:
> On Mon, Sep 09, 2013 at 10:13:02AM -0400, Tejun Heo wrote:
>> Indeed, but can you please update worker_pool_assign_id() so that it
>> doesn't allocate ids >= WORK_OFFQ_POOL_NONE?
>
> So, you did this separately on the next patch. Can you please roll
> that
Sorry, please ignore this email. I accidentally sent a wrong patch...
-Toshi
On Mon, 2013-09-09 at 18:21 -0600, Toshi Kani wrote:
> lock_device_hotplug() serializes hotplug & online/offline operations.
> The lock is held in common sysfs online/offline interfaces and ACPI
> hotplug code paths.
lock_device_hotplug() serializes hotplug & online/offline operations.
The lock is held in common sysfs online/offline interfaces and ACPI
hotplug code paths.
try_offline_node() off-lines a node if all memory sections and cpus
are removed on the node. It is called from acpi_processor_remove()
and
On Mon, Sep 09, 2013 at 06:28:14PM +0200, Frantisek Hrbata wrote:
> I'm not sure if coexistence of .ctors and .init_array sections should result
> in
> denial of module, but I for sure know nothing about this :). Could you maybe
> privide one example of the "weird thing"?
>
They shouldn't exist
Fix the following warning when !CONFIG_MMC:
arch/arm/mach-msm/board-trout.c: In function 'trout_init':
arch/arm/mach-msm/board-trout.c:67:6: warning: unused variable 'rc'
[-Wunused-variable]
int rc;
^
Also, while we're here, rework explicit printk(KERN_CRIT..) to use
pr_crit.
Fix several errors, all in the following form:
arch/arm/mach-msm/board-trout-gpio.c: In function 'trout_gpio_irq_ack':
arch/arm/mach-msm/board-trout-gpio.c:120:2: warning: passing argument 2 of
'__raw_writeb' makes pointer from integer without a cast [enabled by default]
writeb(mask,
On Mon, Sep 9, 2013 at 4:51 PM, Jon Mason wrote:
> dma_sync_wait and dma_find_channel are declared regardless of whether
> CONFIG_DMA_ENGINE is enabled, but calling the function without
> CONFIG_DMA_ENGINE enabled results "undefined reference" errors.
>
> To get around this, declare dma_sync_wait
Linus Torvalds writes:
> On Mon, Sep 9, 2013 at 3:42 PM, Kevin Hilman wrote:
>>
>> The main thing of note (or of potential annoyance factor) here is the
>> handful of conflicts in PULL 2/3 coming from platform changes
>> conflicting with driver changes going in to the V4L tree. I've listed
>>
On Mon, 9 Sep 2013 16:49:23 -0700 Linus Torvalds
wrote:
> On Mon, Sep 9, 2013 at 3:42 PM, Kevin Hilman wrote:
> >
> > The main thing of note (or of potential annoyance factor) here is the
> > handful of conflicts in PULL 2/3 coming from platform changes
> > conflicting with driver changes going
1 - 100 of 1474 matches
Mail list logo