Le 18/12/2020 à 23:49, Christian Zigotzky a écrit :
On 18 December 2020 at 10:25pm, Denis Kirjanov wrote:
>
>
> On Friday, December 18, 2020, Christian Zigotzky
wrote:
>
> Hello,
>
> I compiled the latest Git kernel with the new PowerPC updates 5.11-1 [1] today. Unfortunately
On 18 December 2020 at 11:49pm, Christian Zigotzky wrote:
On 18 December 2020 at 10:25pm, Denis Kirjanov wrote:
>
>
> On Friday, December 18, 2020, Christian Zigotzky
wrote:
>
> Hello,
>
> I compiled the latest Git kernel with the new PowerPC updates
5.11-1 [1] today. Unfortunately th
The ibmvfc driver in its current form relies heavily on the host_lock. This
patchset introduces a genric queue with its own queue lock and sent/free event
list locks. This generic queue allows the driver to decouple the primary queue
and future subordinate queues from the host lock reducing lock co
The drivers queuecommand routine is still wrapped to hold the host lock
for the duration of the call. This will become problematic when moving
to multiple queues due to the lock contention preventing asynchronous
submissions to mulitple queues. There is no real legatimate reason to
hold the host lo
Drain the command queue and place all commands on a completion list.
Perform command completion on that list outside the host/queue locks.
Further, move purged command compeletions outside the host_lock as well.
Signed-off-by: Tyrel Datwyler
Reviewed-by: Brian King
---
drivers/scsi/ibmvscsi/ibm
The primary and async CRQs are nearly identical outside of the format
and length of each message entry in the dma mapped page that represents
the queue data. These queues can be represented with a generic queue
structure that uses a union to differentiate between message format of
the mapped page.
Define per-queue locks for protecting queue state and event pool
sent/free lists. The evt list lock is initially redundant but it allows
the driver to be modified in the follow-up patches to relax the queue
locking around submissions and completions.
Signed-off-by: Tyrel Datwyler
Reviewed-by: Bri
There is currently a single command event pool per host. In anticipation
of providing multiple queues add a per-queue event pool definition and
reimplement the existing CRQ to use its queue defined event pool for
command submission and completion.
Signed-off-by: Tyrel Datwyler
Reviewed-by: Brian
On 18 December 2020 at 10:25pm, Denis Kirjanov wrote:
>
>
> On Friday, December 18, 2020, Christian Zigotzky
wrote:
>
> Hello,
>
> I compiled the latest Git kernel with the new PowerPC updates
5.11-1 [1] today. Unfortunately this kernel doesn't boot on my FSL P5040
board [2] and in a
On Friday, December 18, 2020, Christian Zigotzky
wrote:
> Hello,
>
> I compiled the latest Git kernel with the new PowerPC updates 5.11-1 [1]
> today. Unfortunately this kernel doesn't boot on my FSL P5040 board [2] and
> in a virtual e5500 QEMU machine [3].
>
> I was able to revert the new Power
On Fri, Dec 18, 2020 at 5:39 PM Christophe Leroy <
christophe.le...@csgroup.eu> wrote:
> It can cause, or it causes ? Did you encounter the issue ?
>
Yes, in configs that result in the section layout I described, the crush is
consistent.
>
> > The init sections are ordered like this:
> > .i
On Fri, Dec 18, 2020 at 5:39 PM Christophe Leroy <
christophe.le...@csgroup.eu> wrote:
> It can cause, or it causes ? Did you encounter the issue ?
>
Yes, in configs that result in the section layout I described, the crush is
consistent.
>
> > The init sections are ordered like this:
> > .i
On Thu, Dec 17, 2020 at 1:54 AM Christophe Leroy
wrote:
>
>
>
> Le 17/12/2020 à 07:11, Alexei Starovoitov a écrit :
> > On Wed, Dec 16, 2020 at 10:07:37AM +, Christophe Leroy wrote:
> >> Implement Extended Berkeley Packet Filter on Powerpc 32
> >>
> >> Test result with test_bpf module:
> >>
>
Hello,
I compiled the latest Git kernel with the new PowerPC updates 5.11-1 [1]
today. Unfortunately this kernel doesn't boot on my FSL P5040 board [2]
and in a virtual e5500 QEMU machine [3].
I was able to revert the new PowerPC updates 5.11-1 [4] and after a new
compiling, the kernel boots
On Fri, Dec 18, 2020 at 4:37 PM Enrico Weigelt, metux IT consult
wrote:
> + if (printk_ratelimit())
> + pr_warn("spurious IRQ: irq=%d hwirq=%d nr_irqs=%d\n",
> + irq, hwirq, nr_irqs);
Perhaps you missed pr_warn_ratelimit() macro w
Le 13/12/2020 à 19:35, Ariel Marcovitch a écrit :
This is a bug that can cause early crashes in configurations with a
.exit.text section smaller than a page and a .init.text section that
ends in the beginning of a physical page (this is kinda random, which
might explain why this wasn't really
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/arm/include/asm/hardirq.h | 2 +-
arch/arm/include/asm/hw_irq.h | 6 --
arch/arm/kernel/irq.c
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/arm64/include/asm/hardirq.h | 9 ++---
arch/arm64/kernel/smp.c | 6 ++
2 files chang
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/c6x/include/asm/hardirq.h | 3 ---
arch/c6x/include/asm/irq.h | 2 --
arch/c6x/kernel/irq.c
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/mips/include/asm/hw_irq.h | 4
arch/mips/kernel/irq-gt641xx.c | 3 ++-
arch/mips/kernel/irq.c
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/alpha/include/asm/hardirq.h | 3 ---
arch/alpha/include/asm/hw_irq.h | 2 --
arch/alpha/kernel/irq
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
We currently have counters for spurious interrupt spread over all the
individual architectures. Mostly done in the arch's ack_bad_irq(),
sometimes also in arch specific drivers.
It's time to consolidate this code duplication:
* introduce a global counter and inlined accessors
* increase the c
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
Add a warning on spurious IRQs to __handle_domain_irq(), also telling the
linux IRQ number (if any), the hw IRQ number and the max nr of IRQs.
That's far more informative than the warnings in (some of) the individual
arch's ack_bad_irq()'s. These aren't really helpful since either the
other caller
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o "0x" prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
Hello friends,
<< reposting, since first queue didn't go through completely, due to mailer
problem >>
here's a patch queue for cleaning up the IRQ handling. Inspired by a
discussion we had on a previous patch of mine:
"arch: fix 'unexpected IRQ trap at vector' warnings"
https://www.spi
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/c6x/include/asm/hardirq.h | 3 ---
arch/c6x/include/asm/irq.h | 2 --
arch/c6x/kernel/irq.c
We currently have counters for spurious interrupt spread over all the
individual architectures. Mostly done in the arch's ack_bad_irq(),
sometimes also in arch specific drivers.
It's time to consolidate this code duplication:
* introduce a global counter and inlined accessors
* increase the c
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/alpha/include/asm/hardirq.h | 3 ---
arch/alpha/include/asm/hw_irq.h | 2 --
arch/alpha/kernel/irq
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/arm/include/asm/hardirq.h | 2 +-
arch/arm/include/asm/hw_irq.h | 6 --
arch/arm/kernel/irq.c
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/arm64/include/asm/hardirq.h | 9 ++---
arch/arm64/kernel/smp.c | 6 ++
2 files chang
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
Use the newly introduced irq error counter, that's already maintained
by all callers of ack_bad_irq(), in order to remove duplicate code.
Signed-off-by: Enrico Weigelt, metux IT consult
---
arch/mips/include/asm/hw_irq.h | 4
arch/mips/kernel/irq-gt641xx.c | 3 ++-
arch/mips/kernel/irq.c
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
Add a warning on spurious IRQs to __handle_domain_irq(), also telling the
linux IRQ number (if any), the hw IRQ number and the max nr of IRQs.
That's far more informative than the warnings in (some of) the individual
arch's ack_bad_irq()'s. These aren't really helpful since either the
other caller
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o "0x" prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it
Hello friends,
here's a patch queue for cleaning up the IRQ handling. Inspired by a
discussion we had on a previous patch of mine:
"arch: fix 'unexpected IRQ trap at vector' warnings"
https://www.spinics.net/lists/kernel/msg3763137.html
Turned out that the whole message, as it is right
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to
powerpc was the last provider of arch_remap() and the last
user of mm-arch-hooks.h.
Since commit 526a9c4a7234 ("powerpc/vdso: Provide vdso_remap()"),
arch_remap() hence mm-arch-hooks.h are not used anymore.
Remove them.
Signed-off-by: Christophe Leroy
---
arch/um/include/asm/Kbuild |
Skirmisher reported on IRC that the 32-bit LE VDSO was hanging. This
turned out to be due to a branch to self in eg. __kernel_gettimeofday.
Looking at the disassembly with objdump -dR shows why:
0528 <__kernel_gettimeofday>:
528: f0 ff 21 94 stwur1,-16(r1)
52c: a6 02 08 7c
When building the 32-bit VDSO, we are building 32-bit code as part of
a 64-bit kernel build. That requires us to tweak the cflags to trick
the compiler into building 32-bit code for us. The main way we do that
is by passing -m32, but there are other options that affect code
generation and ABI selec
Add R_PPC_REL24 relocations to the list of relocations we do NOT
support in the VDSO.
These are generated in some cases and we do not support relocating
them at runtime, so if they appear then the VDSO will not work at
runtime, therefore it's preferable to break the build if we see them.
Fixes: a
hv_24x7 performance monitoring unit creates list of supported events
from the event catalog obtained via HCALL. hv_24x7 catalog could also
contain invalid or dummy events (with names like FREE_* or CPM_FREE_*
and RESERVED*). These events do not have any hardware counters
backing them. So patch adds
61 matches
Mail list logo
