From: "David A. Long"
Using Rabin Vincent's ARM uprobes patches as a base, enable uprobes
support on ARM.
Caveats:
- Thumb is not supported
Signed-off-by: David A. Long
---
arch/arm/Kconfig | 4 +
arch/arm/include/asm/ptrace.h | 6 +
arch/arm/include/asm/thread_in
From: "David A. Long"
Because the common underlying code for ARM kprobes and uprobes needs
to share a common architecrure-specific context structure, and because
the generic kprobes include file insists on defining this to a dummy
structure when kprobes is not configured, a new common structure i
From: "David A. Long"
Add an emulate flag into the instruction interpreter, primarily for uprobes
support.
Signed-off-by: David A. Long
---
arch/arm/kernel/kprobes.c | 2 +-
arch/arm/kernel/kprobes.h | 1 +
arch/arm/kernel/probes-arm.c | 4 ++--
arch/arm/kernel/probes-arm.h |
From: "David A. Long"
Allow arches to decided to ignore a probe hit. ARM will use this to
only call handlers if the conditions to execute a conditionally executed
instruction are satisfied.
Signed-off-by: David A. Long
Acked-by: Oleg Nesterov
---
include/linux/uprobes.h | 1 +
kernel/events/
From: "David A. Long"
Any more ARM kprobes/uprobes symbols which have "kprobe" in the name must be
changed to the more generic "probes" or other non-kprobes specific symbol.
Signed-off-by: David A. Long
---
arch/arm/include/asm/probes.h| 13 ++---
arch/arm/kernel/kprobes-common.c |
From: "David A. Long"
Change kprobe_emulate_none, kprobe_simulate_nop, and arm_kprobe_decode_init
function names to something more appropriate for code being shared
outside of the kprobes subsystem. Also, move the new arm_probes_decode_init
declaration out of the kprobes.h include file and into t
From: "David A. Long"
Change the generic ARM probes code to pass in the opcode and
architecture-specific
structure separately instead of using struct kprobe, so we do not pollute
code being used only for uprobes or other non-kprobes instruction
interpretation.
Signed-off-by: David A. Long
---
From: "David A. Long"
Change the name of kprobes_insn to probes_insn so it can be shared between
kprobes and uprobes without confusion.
Signed-off-by: David A. Long
---
arch/arm/kernel/kprobes-common.c | 2 +-
arch/arm/kernel/kprobes-thumb.c | 16
arch/arm/kernel/kprobes.h
From: "David A. Long"
In preparation for sharing the ARM kprobes instruction interpreting
code with uprobes, make the symbols names less kprobes-specific.
Signed-off-by: David A. Long
---
arch/arm/include/asm/probes.h | 4 ++--
arch/arm/kernel/kprobes-thumb.c | 4 ++--
arch/arm/kernel/probes
From: "David A. Long"
For any ARM kprobes/uprobes code interfacing to the generic ARM probes code
use a new probes_opcode_t type to avoid a dependency on kprobes definitions.
Signed-off-by: David A. Long
---
arch/arm/include/asm/probes.h| 7 ++--
arch/arm/kernel/kprobes-arm.c| 16
On Thu, 23 Jan 2014, Valentina Manea wrote:
> 1. The usbip_status file is no longer created for interface 0, but for
> the whole device (such as
> /sys/devices/pci:00/:00:01.2/usb1/1-1/usbip_status).
> 2. Per interface information, such as interface class or protocol, is
> no longer sent/r
From: "Jon Medhurst (Tixy)"
For now the jprobes tests fail on ARM for when built into a kernel compiled
in thumb mode. They work fine for ARM kernels, and when built as a loadable
module.
Signed-off-by: "Jon Medhurst (Tixy)"
Signed-off-by: David A. Long
---
arch/arm/kernel/kprobes-test.c | 10
From: "David A. Long"
This patch series adds basic uprobes support to ARM. It is based on patches
developed earlier by Rabin Vincent. That approach of adding hooks into
the kprobes instruction parsing code was not well received. This approach
separates the ARM instruction parsing code in kprobes
From: "David A. Long"
Separate the kprobe-only definitions from the definitions needed by
both kprobes and uprobes.
Signed-off-by: David A. Long
---
arch/arm/include/asm/kprobes.h | 15 +-
arch/arm/include/asm/{kprobes.h => probes.h} | 44 +---
2 f
> > It has to be lockless, the machine checks run as NMIs.
> > The whole point of the self nmi is to get back to a lockable state.
>
> "It" is arch_irq_work_raise, or more?
Really irq_work_queue, but it boils down to arch_irq_work_raise
-Andi
--
To unsubscribe from this list: send the line "unsu
On Thu, Jan 23, 2014 at 11:00:16AM +, li.xi...@freescale.com wrote:
> Hi,
>
> I'd like to know the status about this patch.
Please send upstream mail to kernel.org if you want it reading - almost
all upstream mail sent to my Linaro address is a duplicate and doesn't
get read there.
signatur
On Fri, Jan 10, 2014 at 01:17:27PM +0800, Xiubo Li wrote:
> Fix the usage of simple card widgets routing property, and make it the
> same with simple card routing property name.
Applied, thanks.
signature.asc
Description: Digital signature
The network.c code is always built in. It will never be modular,
so using module_init as an alias for __initcall is rather
misleading.
Fix this up now, so that we can relocate module_init from
init.h into module.h in the future. If we don't do this, we'd
have to add module.h to obviously non-mod
On Thu, Jan 23, 2014 at 7:18 PM, Mikulas Patocka wrote:
> The cfb_copyarea code was very buggy and it looks like it was written
> and never tried with non-8-pixel font.
My memory may suffer from bitrot, but I think I tested it with the Sun
12x22 font. That was on big endian (PPC), though.
BTW, g
On Thu, Jan 23, 2014 at 7:19 PM, Mikulas Patocka wrote:
> The card works fine in 1980x1080 resolution. Therefore, there is no need
1920x1080?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal convers
The network.c code is piggybacking off of the arch independent
CONFIG_NET, which is bool. So the code is either built in or
absent. It will never be modular, so using module_init as an
alias for __initcall is rather misleading.
Fix this up now, so that we can relocate module_init from
init.h int
On Thu, Jan 23, 2014 at 04:44:38PM +, Mel Gorman wrote:
> On Thu, Jan 23, 2014 at 07:47:53AM -0800, James Bottomley wrote:
> > On Thu, 2014-01-23 at 19:27 +1100, Dave Chinner wrote:
> > > On Wed, Jan 22, 2014 at 10:13:59AM -0800, James Bottomley wrote:
> > > > On Wed, 2014-01-22 at 18:02 +,
On Wed, Jan 22, 2014 at 3:33 PM, Andrew Morton
wrote:
> On Wed, 22 Jan 2014 09:19:58 -0500 Dan Streetman wrote:
>
>> >>> > Acutally, I really don't know how much benefit we have that in-memory
>> >>> > swap overcomming to the real storage but if you want, zRAM with
>> >>> > dm-cache
>> >>> > is
On Thu, Jan 23, 2014 at 11:59 AM, Kumar Gala wrote:
>
> On Jan 23, 2014, at 11:25 AM, Kevin Hilman wrote:
>
>> Stephen Boyd writes:
>>
>>> These patches add the clock controller nodes, enable the clock drivers
>>> on MSM based platforms, and hook it up enough to get the serial console
>>> workin
On 01/23/2014 07:47 PM, Zoltan Kiss wrote:
> Nikolay Aleksandrov's recent bonding option API changes (25a9b54a and
> e4994612)
> introduced u64 as the type of downdelay and updelay. On 32 bit the division
> and
> modulo operations cause compile errors:
>
> ERROR: "__udivdi3" [drivers/net/bonding
On Thu, 23 Jan 2014, Geert Uytterhoeven wrote:
> On Thu, Jan 23, 2014 at 7:18 PM, Mikulas Patocka wrote:
> > The cfb_copyarea code was very buggy and it looks like it was written
> > and never tried with non-8-pixel font.
>
> My memory may suffer from bitrot, but I think I tested it with the S
On Thu, 23 Jan 2014, Geert Uytterhoeven wrote:
> On Thu, Jan 23, 2014 at 7:19 PM, Mikulas Patocka wrote:
> > The card works fine in 1980x1080 resolution. Therefore, there is no need
>
> 1920x1080?
Yes, I meant that.
Mikulas
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> G
The compatible string of the Broadcom Capri pinctrl driver is renamed to
"brcm,bcm11351-pinctrl" to match the machine binding here:
Documentation/devicetree/bindings/arm/bcm/bcm11351.txt
Signed-off-by: Sherman Yin
Reviewed-by: Matt Porter
Acked-by: Linus Walleij
---
...capri-pinctrl.txt => brc
This commit updates bcm11351.dtsi with the new compatible string for
the same driver.
Signed-off-by: Sherman Yin
Reviewed-by: Matt Porter
Acked-by: Linus Walleij
---
arch/arm/boot/dts/bcm11351.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm1135
On 01/23/2014 12:52 PM, Linus Torvalds wrote:
On Thu, Jan 23, 2014 at 9:47 AM, Waiman Long wrote:
Thank for the info. I am less familiar with that kind of issues on other
architecture. I will add a smp_mb__after_atomic_dec()& send out a new
patch.
SInce it's the unlock path,. you need to use
To be consistent with other Broadcom drivers, the Broadcom Capri pinctrl
driver and its related CONFIG option are renamed to bcm281xx.
This commit updates the defconfig that enables the pinctrl driver.
Signed-off-by: Sherman Yin
Reviewed-by: Matt Porter
Acked-by: Linus Walleij
---
arch/arm/co
To be consistent with other Broadcom drivers, the Broadcom Capri pinctrl
driver and its related CONFIG option are renamed to bcm281xx.
Devicetree compatible string and binding documentation use
"brcm,bcm11351-pinctrl" to match the machine binding here:
Documentation/devicetree/bindings/arm/bcm/bcm
On Wed, 22 Jan 2014, Mel Gorman wrote:
> Don't get me wrong, I'm interested in the topic but I severely doubt I'd
> have the capacity to research the background of this in advance. It's also
> unlikely that I'd work on it in the future without throwing out my current
> TODO list. In an ideal world
On Wed, 22 Jan 2014, Mel Gorman wrote:
> Large block support was proposed years ago by Christoph Lameter
> (http://lwn.net/Articles/232757/). I think I was just getting started
> in the community at the time so I do not recall any of the details. I do
> believe it motivated an alternative by Nick
On Thu, 23 Jan 2014, James Bottomley wrote:
> If the compound page infrastructure exists today and is usable for this,
> what else do we need to do? ... because if it's a couple of trivial
> changes and a few minor patches to filesystems to take advantage of it,
> we might as well do it anyway. I
On Thu, 23 Jan 2014, Geert Uytterhoeven wrote:
> BTW, good to see you still have a working TGA. My PPC and Alpha gear
> died a decade ago.
>
> Gr{oetje,eeting}s,
>
> Geert
With the patches that I sent, I can switch it to 1920x1080 and let it
drive my monitor in native
I have been reading the code around pci_scan_bridge and noticed a few oddities.
These patches try to cleanup some of the these things.
Most of the patches make also sense in isolation, but some make more sense with
the previous ones applied as well. None of the patches fix any observed bugs.
Patch
When assigning a new bus number in pci_scan_bridge we check whether
max+1 is free by calling pci_find_bus. If it does already exists then we
assume that we are rescanning and that this is the right bus to scan.
This is fragile. If max+1 lies outside of bus->busn_res.end then we will
rescan some ra
pci_scan_child_bus can (potentially) return a bus number higher than the
subordinate
value of the child bus. Possible reasons are that bus numbers are reserved for
SR-IOV or for CardBus (SR-IOV is done without checks and the CardBus
checks are sketchy at best).
We clamp the returned value to the
The function has no effect.
If pcibios_assign_all_busses() is not set then the function does nothing.
If it is set then in pci_scan_bridge we are always in the branch where
we assign the bus numbers ourselves and the subordinate values of all
parent busses will be set to 0xff since that is what t
If a conflict happens during insert_resource_conflict and all conflicts
fit within the newly inserted resource then they will become children of
the new resource. This is almost certainly not what we want for bus
numbers.
Signed-off-by: Andreas Noever
---
drivers/pci/probe.c | 2 +-
1 file chang
Right now the CardBus code in pci_scan_bridge is executed during both
passes. Since we always allocate the bus number ourselves it makes sense
to put it into the second pass.
Signed-off-by: Andreas Noever
---
drivers/pci/probe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Right now we use 0xff for busn_res.end when probing and later reduce it
to the value that is actually used. This does not work if a parent
bridge has already a lower subordinate value. For example during hotplug of a
new bridge below an already configured bridge the following message is
printed fro
This patch fixes two small issues:
- If pci_add_new_bus fails then max must not be incremented. Otherwise
an incorrect value is returned from pci_scan_bridge().
- If the bus is already present, then max must be incremented. I think
that this case should only be hit if we trigger a manual re
On Thu, 23 Jan 2014 19:14:45 +0400 Cyrill Gorcunov wrote:
> VM_SOFTDIRTY bit affects vma merge routine: if two VMAs has all
> bits in vm_flags matched except dirty bit the kernel can't longer
> merge them and this forces the kernel to generate new VMAs instead.
Do you intend to alter the brk() a
Initially when we encountered a bus that was already present we skipped
it. Since 74710ded8e16 'PCI: always scan child buses' we continue
scanning in order to allow user triggered rescans of already existing
busses.
The old comment suggested that the reason for continuing the scan is a
bug in the
On Wed, Jan 22, 2014 at 5:21 PM, Olof Johansson wrote:
> On Wed, Jan 22, 2014 at 2:06 AM, Daniel Vetter wrote:
>> Hi Stephen,
>>
>> On Wed, Jan 22, 2014 at 4:04 AM, Stephen Rothwell
>> wrote:
>>> Hi all,
>>>
>>> Today's linux-next merge of the drm-intel tree got a conflict in
>>> drivers/gpu/dr
> If you don't bind the interfaces, they will naturally bind to their
> normal drivers on the host. You probably don't want that to happen.
> (Although, at the moment, I don't see how you can prevent it.)
>
That's true but, the way I see USB/IP general use case, the drivers
from the host the devi
This driver was previously an interface driver. Since USB/IP
exports a whole device, not just an interface, it would make
sense to be a device driver.
This patch also modifies the way userspace sees and uses a
shared device:
* the usbip_status file is no longer created for interface 0, but for
th
On Thu, 2014-01-23 at 13:56 -0500, Tejun Heo wrote:
> On Thu, Jan 23, 2014 at 10:38:33AM -0800, Frank Mayhar wrote:
> > On Wed, 2014-01-22 at 07:46 -0800, Frank Mayhar wrote:
> > > On Tue, 2014-01-21 at 07:58 -0800, Frank Mayhar wrote:
> > > > Replacing? Or adding to? Is BYPASS always set when DY
On 01/23/2014 09:44 PM, Nikolay Aleksandrov wrote:
> On 01/23/2014 07:47 PM, Zoltan Kiss wrote:
>> Nikolay Aleksandrov's recent bonding option API changes (25a9b54a and
>> e4994612)
>> introduced u64 as the type of downdelay and updelay. On 32 bit the division
>> and
>> modulo operations cause co
On Thu, Jan 23, 2014 at 07:55:50AM -0500, Theodore Ts'o wrote:
> On Thu, Jan 23, 2014 at 07:35:58PM +1100, Dave Chinner wrote:
> > >
> > > I expect it would be relatively simple to get large blocksizes working
> > > on powerpc with 64k PAGE_SIZE. So before diving in and doing huge
> > > amounts o
On Thu, 23 Jan 2014 15:51:31 +0530 Prabhakar Lad
wrote:
> Hi Sachin,
>
> On Thu, Jan 23, 2014 at 3:38 PM, Sachin Kamat wrote:
> > Hi Prabhakar,
> >
> > On 23 January 2014 15:26, Prabhakar Lad wrote:
> >> From: "Lad, Prabhakar"
> >>
> >> In the gen_pool_dma_alloc() the dma pointer can be NULL
The grant mapping API does m2p_override unnecessarily: only gntdev needs it,
for blkback and future netback patches it just cause a lock contention, as
those pages never go to userspace. Therefore this series does the following:
- the original functions were renamed to __gnttab_[un]map_refs, with a
On Thu, Jan 23, 2014 at 02:32:33PM -0500, Richard Guy Briggs wrote:
> These are a number of patches inspired by ebiederman's container work that
> were
> included by me 2013-08-20 as the patchset:
> RFC: steps to make audit pid namespace-safe
>
> They have been seperated out for the pid mai
On Thu, 23 Jan 2014, Viresh Kumar wrote:
> update_flag() routine uses heap only when spread_flag_changed is true.
> Otherwise
> heap isn't used, but is allocated and freed unnecessarily.
>
> Fix this by allocating heap only when required.
>
> Signed-off-by: Viresh Kumar
Acked-by: David Rientj
This is a Win7 device which does not work correctly with the default
settings (not the previous default BT).
However, the quirk ALWAYS_TRUE makes it working like a charm.
Signed-off-by: Benjamin Tissoires
---
Hi Jiri,
well, it's been a long time since I did not add those kind of small patches.
On Thu, 23 Jan 2014 20:05:09 +
Mark Brown wrote:
> On Thu, Jan 23, 2014 at 07:51:44PM +, Alan Cox wrote:
>
> > That strikes me as rather more risky. We can propogate it through the
> > drivers as we are sure it is safe to do so on that platform and encourage
> > driver authors to migrate
On Thu, 2014-01-23 at 13:27 -0800, Joel Becker wrote:
> On Wed, Jan 22, 2014 at 10:47:01AM -0800, James Bottomley wrote:
> > On Wed, 2014-01-22 at 18:37 +, Chris Mason wrote:
> > > On Wed, 2014-01-22 at 10:13 -0800, James Bottomley wrote:
> > > > On Wed, 2014-01-22 at 18:02 +, Chris Mason w
From: "J. Bruce Fields"
d_splice_alias can create duplicate directory aliases (in the !new
case), or (in the new case) d_move directories without holding
appropriate locks.
d_materialise_unique deals with both of these problems. (The latter
seems to be dealt by trylocks (see __d_unalias), which
On Wed, Jan 22, 2014 at 10:47:01AM -0800, James Bottomley wrote:
> On Wed, 2014-01-22 at 18:37 +, Chris Mason wrote:
> > On Wed, 2014-01-22 at 10:13 -0800, James Bottomley wrote:
> > > On Wed, 2014-01-22 at 18:02 +, Chris Mason wrote:
> [agreement cut because it's boring for the reader]
> >
On Thu, 23 Jan 2014, Ard Biesheuvel wrote:
> The GOOGLE_SMI Kconfig symbol depends on DMI and selects EFI. This
> causes problems on other archs when introducing DMI support that
> depends on EFI, as it results in a recursive dependency:
>
> arch/arm/Kconfig:1845:error: recursive dependency detec
From: Zoltan Kiss
Date: Thu, 23 Jan 2014 13:13:07 +
> It is already based on two predecessor patches, one which is already
> accepted but not applied yet:
>
> [PATCH net-next v2] xen-netback: Rework rx_work_todo
>
> And the other one is hopefully will be accepted very soon:
>
> [PATCH v5]
On Thu, Jan 23, 2014 at 1:36 PM, David Rientjes wrote:
> On Thu, 23 Jan 2014, Ard Biesheuvel wrote:
>
>> The GOOGLE_SMI Kconfig symbol depends on DMI and selects EFI. This
>> causes problems on other archs when introducing DMI support that
>> depends on EFI, as it results in a recursive dependency
On Thu, Jan 23, 2014 at 01:02:35PM -0800, Andrew Morton wrote:
> On Thu, 23 Jan 2014 19:14:45 +0400 Cyrill Gorcunov wrote:
>
> > VM_SOFTDIRTY bit affects vma merge routine: if two VMAs has all
> > bits in vm_flags matched except dirty bit the kernel can't longer
> > merge them and this forces the
On 23 January 2014 22:40, Mike Waychison wrote:
> On Thu, Jan 23, 2014 at 1:36 PM, David Rientjes wrote:
>> On Thu, 23 Jan 2014, Ard Biesheuvel wrote:
>>
>>> The GOOGLE_SMI Kconfig symbol depends on DMI and selects EFI. This
>>> causes problems on other archs when introducing DMI support that
>>>
On 23/01/14 21:39, David Miller wrote:
From: Zoltan Kiss
Date: Thu, 23 Jan 2014 13:13:07 +
It is already based on two predecessor patches, one which is already
accepted but not applied yet:
[PATCH net-next v2] xen-netback: Rework rx_work_todo
And the other one is hopefully will be accept
On Thu, 23 Jan 2014 13:36:55 -0800 (PST) David Rientjes
wrote:
> $ ./scripts/get_maintainer.pl -f drivers/firmware/google/Kconfig
> linux-kernel@vger.kernel.org (open list)
>
> I wonder why he's not listed as a recipient for patches from
> get_maintainer.pl since it's clearly obvious he wrote
On 1/21/2014 1:32 PM, Aravind Gopalakrishnan wrote:
On 1/20/2014 1:07 AM, Ingo Molnar wrote:
* Aravind Gopalakrishnan wrote:
+
+#if defined(CONFIG_PCI)
+/*
+ * Apply AMD Fam16h Erratum792
+ * see Revision Guide for AMD F16h models 00h-0fh,
+ * document 51810 rev. 3.04, Nov 2013
+ */
+static v
The workaround for this Erratum is included in AGESA. But BIOSes spun
only after Jan2014 will have the fix (atleast server versions of the
chip). The erratum affects both embedded and server platforms and since
we cannot say with certainity that ALL BIOSes on systems out in the
field will have the
On Jan 23, 2014, at 2:43 PM, Olof Johansson wrote:
> On Thu, Jan 23, 2014 at 11:59 AM, Kumar Gala wrote:
>>
>> On Jan 23, 2014, at 11:25 AM, Kevin Hilman wrote:
>>
>>> Stephen Boyd writes:
>>>
These patches add the clock controller nodes, enable the clock drivers
on MSM based pla
On 01/23/2014 12:50 AM, Guenter Roeck wrote:
> Hi folks,
>
> we are seeing an odd problem with kernel version 3.13 running on Mohan Peak
> with an Avoton 8-core CPU. The kernel boots to the login prompt and then
> freezes silently within a few seconds.
>
> The problem disappears if we revert patc
On Jan 8, 2014, at 7:50 PM, Stephen Boyd wrote:
> On 01/08/14 13:37, Arnd Bergmann wrote:
>> On Tuesday 24 December 2013, Stephen Boyd wrote:
>>> This is a rework of patches sent a months back by Rohit[1].
>>> The goal of these patches is to add support for SMP and (basic)
>>> hotplug on MSM bas
On Thu, Jan 23, 2014 at 1:57 PM, Kumar Gala wrote:
>
> On Jan 23, 2014, at 2:43 PM, Olof Johansson wrote:
>
>> On Thu, Jan 23, 2014 at 11:59 AM, Kumar Gala wrote:
>>>
>>> On Jan 23, 2014, at 11:25 AM, Kevin Hilman wrote:
>>>
Stephen Boyd writes:
> These patches add the clock cont
We've been hitting the following bug in the latest kernel, during boot:
kernel BUG at arch/x86/mm/init_64.c:351!
invalid opcode: [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-medusa-04156-g90804ed-dirty
#750
Hardware name: Intel Corp. Stoutland Platform, BIOS 2
I have a system with 4 cores (configured with CONFIG_NR_CPUS=4) that shows
during boot..
[0.00] smpboot: 8 Processors exceeds NR_CPUS limit of 4
it looks like this is because..
[0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[0.00] ACPI: LAPIC (acpi_id[0x02] la
Hello.
On 23-01-2014 22:47, Zoltan Kiss wrote:
Nikolay Aleksandrov's recent bonding option API changes (25a9b54a and e4994612)
You should also specify those commits' summary lines.
introduced u64 as the type of downdelay and updelay. On 32 bit the division and
modulo operations cause com
On Thu, Jan 23, 2014 at 03:44:05PM -0600, Peter Tyser wrote:
> On 01/23/2014 12:50 AM, Guenter Roeck wrote:
> > Hi folks,
> >
> > we are seeing an odd problem with kernel version 3.13 running on Mohan Peak
> > with an Avoton 8-core CPU. The kernel boots to the login prompt and then
> > freezes sil
On Thu, Jan 23, 2014 at 01:58:24AM -0500, Dave Jones wrote:
> 128 bytes is a pretty small amount of stack though, so I'm just as confused
> as to what the actual bug here is.
>
> After trying the proposed fix, I got another oops in the early init code..
>
>
> nr_free_zone_pages
> nr_fre
Bridge irqs are edge-triggered, i.e. they get asserted on low-to-high
transitions and not on the level of the downstream interrupt line.
This replaces handle_level_irq by the more appropriate handle_edge_irq.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Andr
It is good practice to mask and clear pending irqs on init. We already
mask all irqs, so also clear the bridge irq cause register.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Thomas Gleixner
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Jason Gunthorpe
Cc: Ezequiel Garcia
Cc: li
This is a small patch set to fix some shortcomings how Orion bridge
irqs are handled. The patches are based on v3.13-rc8 and should go
into v3.14. They can possibly also marked for -stable down to v3.10.
This patches are the result of a discussion about a stale watchdog irq,
that can accidentially
Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
them before unmask. This installs an .irq_enable callback to ensure stale
irqs are cleared before initial unmask.
Signed-off-by: Sebastian Hesselba
On Thu, 23 Jan 2014, Andrew Morton wrote:
> > $ ./scripts/get_maintainer.pl -f drivers/firmware/google/Kconfig
> > linux-kernel@vger.kernel.org (open list)
> >
> > I wonder why he's not listed as a recipient for patches from
> > get_maintainer.pl since it's clearly obvious he wrote the entire fi
On Thu, Jan 23, 2014 at 04:11:08PM -0600, Alex Thorlton wrote:
> We've been hitting the following bug in the latest kernel, during boot:
Can you merge
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git#next
into your tree, enable CONFIG_EFI_PGT_DUMP, apply the debugging patch
below,
On Thu, 23 Jan 2014 20:27:29 +0400 (MSK) malc wrote:
> Sep 17 00:00:00 2001
> From: Vladimir Murzin
> Date: Thu, 23 Jan 2014 14:54:20 +0400
> Subject: [PATCH] Revert "mm/vmalloc: interchage the implementation of
> vmalloc_to_{pfn,page}"
>
> This reverts commit ece86e222db48d04bda218a2be70e3845
Linus's current tree doesn't boot on an 8-node/1TB NUMA system that I
have. Its reboots are *LONG*, so I haven't fully bisected it, but it's
down to a just a few commits, most of which are changes to the memblock
code. Since the panic is in the memblock code, it looks like a
no-brainer. It's alm
On Thu, Jan 23, 2014 at 11:38:06PM +0100, Sebastian Hesselbarth wrote:
> Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
> IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
> them before unmask. This installs an .irq_enable callback to ensure sta
On Tue, Jan 21, K. Y. Srinivasan wrote:
> Implement the file copy service for Linux guests on Hyper-V. This permits the
> host to copy a file (over VMBUS) into the guest. This facility is part of
> "guest integration services" supported on the Windows platform.
> Here is a link that provides addit
Hi Florian,
>> Patch #8 [1] of this series has the "compatible" string set exactly that
>> way. I was
>> following the pattern seen in the other reference DTS files, where
>> "arm,cortex-a15-gic" is
>> used as the fall-back.
>
> Ah, I missed that, thanks! How about the CPU compatible property?
>
Hi Linus,
On Thu, 23 Jan 2014 09:12:43 +0100 Linus Walleij
wrote:
>
> On Tue, Jan 21, 2014 at 10:23 PM, Paul Gortmaker
> wrote:
>
> > None of these files are actually using any __init type directives
> > and hence don't need to include . Most are just a
> > left over from __devinit and __cpu
On 01/23/2014 11:52 PM, Jason Gunthorpe wrote:
On Thu, Jan 23, 2014 at 11:38:06PM +0100, Sebastian Hesselbarth wrote:
Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
them before unmask. This in
Bridge IRQ_CAUSE bits are asserted regardless of the corresponding bit in
IRQ_MASK register. To avoid interrupt events on stale irqs, we have to clear
them before unmask. This installs an .irq_startup callback to ensure stale
irqs are cleared before initial unmask.
Signed-off-by: Sebastian Hesselb
On Thu, Jan 23, 2014 at 11:23:37AM -0500, Elena Ufimtseva wrote:
> On Wed, Jan 22, 2014 at 3:33 PM, Steven Noonan wrote:
> > On Wed, Jan 22, 2014 at 03:18:50PM -0500, Elena Ufimtseva wrote:
> >> On Wed, Jan 22, 2014 at 9:29 AM, Daniel Borkmann
> >> wrote:
> >> > On 01/22/2014 08:29 AM, Steven No
On Thu, Jan 23, 2014 at 11:06:37AM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.12.9 release.
> There are 27 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
Jean-Francois Moine wrote on Sun [2014-Jan-19 19:58:40 +0100]:
> This patch uses always the adjusted video mode instead of a mix of
> original and adjusted mode.
>
> Signed-off-by: Jean-Francois Moine
> ---
> drivers/gpu/drm/i2c/tda998x_drv.c | 66
> +++
> 1
On Thu, 23 Jan 2014, Zoltan Kiss wrote:
> The grant mapping API does m2p_override unnecessarily: only gntdev needs it,
> for blkback and future netback patches it just cause a lock contention, as
> those pages never go to userspace. Therefore this series does the following:
> - the original functio
On Thu, Jan 23, 2014 at 10:39:33AM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.28 release.
> There are 23 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know
"Srivatsa S. Bhat" writes:
> On 01/23/2014 07:59 AM, Rusty Russell wrote:
>> "Srivatsa S. Bhat" writes:
>>> On 01/22/2014 02:00 PM, Srivatsa S. Bhat wrote:
Hi Paul,
>>
>> I find an old patch for register_allcpu_notifier(), but the "bool
>> replay_history" should be eliminated (always true):
On Thu 23-01-14 16:07:45, Jiri Kosina wrote:
> On Thu, 23 Jan 2014, Jan Kara wrote:
>
> > > > > But refcounting seems like an overkill for this - there is exactly one
> > > > > fanotify_response_event structure iff it is a permission event. So
> > > > > something like the (completely untested) att
501 - 600 of 691 matches
Mail list logo
