On 6/6/24 1:41 AM, Yosry Ahmed wrote:
> On Wed, Jun 5, 2024 at 4:04 PM Erhard Furtner wrote:
>
> I am personally leaning toward (c), but I want to hear the opinions of
> other people here. Yu, Vlastimil, Johannes, Nhat? Anyone else?
Besides the zpool commit which might have just pushed the machi
/pci-epf.h | 2 +
18 files changed, 162 insertions(+), 68 deletions(-)
---
base-commit: 7d96527bc16e46545739c6fe0ab6e4c915e9910e
change-id: 20240606-pci-deinit-2e6cdf1bd69f
Best regards,
--
Manivannan Sadhasivam
Currently dw_pcie_ep_init_notify() wrapper just calls pci_epc_init_notify()
directly. So this wrapper provides no benefit to the glue drivers.
So let's remove it and call pci_epc_init_notify() directly from glue
drivers.
Suggested-by: Bjorn Helgaas
Signed-off-by: Manivannan Sadhasivam
---
driv
As like the 'epc_init' event, that is used to signal the EPF drivers about
the EPC initialization, let's introduce 'epc_deinit' event that is used to
signal EPC deinitialization.
The EPC deinitialization applies only when any sort of fundamental reset
is supported by the endpoint controller as per
Now that the API is available, let's make use of it. It also handles the
reinitialization of DWC non-sticky registers in addition to sending the
notification to EPF drivers.
Reviewed-by: Niklas Cassel
Signed-off-by: Manivannan Sadhasivam
---
drivers/pci/controller/dwc/pcie-qcom-ep.c | 2 +-
1 f
As per the PCIe base spec r5.0, section 5.2, Link Down event can happen
under any of the following circumstances:
1. Fundamental/Hot reset
2. Link disable transmission by upstream component
3. Moving from L2/L3 to L0
In those cases, Link Down causes some non-sticky DWC registers to loose the
stat
Now that the API is available, let's make use of it. It also handles the
reinitialization of DWC non-sticky registers in addition to sending the
notification to EPF drivers.
Reported-by: Bjorn Helgaas
Closes: https://lore.kernel.org/linux-pci/20240528195539.GA458945@bhelgaas/
Signed-off-by: Maniv
diff --git a/drivers/ata/pata_macio.c b/drivers/ata/pata_macio.c
index 817838e2f70e..3cb455a32d92 100644
--- a/drivers/ata/pata_macio.c
+++ b/drivers/ata/pata_macio.c
@@ -915,10 +915,13 @@ static const struct scsi_host_template pata_macio_sht = {
.sg_tablesize = MAX_DCMDS,
The pata_macio driver advertises a max_segment_size of 0xff00, because
the hardware doesn't cope with requests >= 64K.
However the SCSI core requires max_segment_size to be at least
PAGE_SIZE, which is a problem for pata_macio when the kernel is built
with 64K pages.
In older kernels the SCSI cor
On Thu, Jun 06, 2024 at 12:56:35PM +0530, Manivannan Sadhasivam wrote:
> As like the 'epc_init' event, that is used to signal the EPF drivers about
> the EPC initialization, let's introduce 'epc_deinit' event that is used to
> signal EPC deinitialization.
>
> The EPC deinitialization applies only
On Thu, Jun 06, 2024 at 12:56:36PM +0530, Manivannan Sadhasivam wrote:
> As per the PCIe base spec r5.0, section 5.2, Link Down event can happen
> under any of the following circumstances:
>
> 1. Fundamental/Hot reset
> 2. Link disable transmission by upstream component
> 3. Moving from L2/L3 to L
On Thu, Jun 06, 2024 at 12:56:34PM +0530, Manivannan Sadhasivam wrote:
> Currently dw_pcie_ep_init_notify() wrapper just calls pci_epc_init_notify()
> directly. So this wrapper provides no benefit to the glue drivers.
>
> So let's remove it and call pci_epc_init_notify() directly from glue
> drive
Yu Zhao writes:
> On Wed, Jun 5, 2024 at 9:12 PM Michael Ellerman wrote:
>>
>> David Hildenbrand writes:
>> > On 01.06.24 08:01, Yu Zhao wrote:
>> >> On Wed, May 15, 2024 at 4:06 PM Yu Zhao wrote:
>> ...
>> >>
>> >> Your system has 2GB memory and it uses zswap with zsmalloc (which is
>> >> good
On 6/6/24 20:14, Michael Ellerman wrote:
> The pata_macio driver advertises a max_segment_size of 0xff00, because
> the hardware doesn't cope with requests >= 64K.
>
> However the SCSI core requires max_segment_size to be at least
> PAGE_SIZE, which is a problem for pata_macio when the kernel is b
John Garry writes:
>> diff --git a/drivers/ata/pata_macio.c b/drivers/ata/pata_macio.c
>> index 817838e2f70e..3cb455a32d92 100644
>> --- a/drivers/ata/pata_macio.c
>> +++ b/drivers/ata/pata_macio.c
>> @@ -915,10 +915,13 @@ static const struct scsi_host_template pata_macio_sht
>> = {
>> .sg_t
Gautam Menghani writes:
> On Wed, Jun 05, 2024 at 05:09:08PM GMT, Gautam Menghani wrote:
>> Doorbell emulation for KVM on PAPR guests is broken as support for DPDES
>> was not added in initial patch series [1].
>> Add DPDES support and doorbell handling support for V2 API.
>>
>> [1] lore.kernel.
On Thu, Jun 06, 2024 at 09:14:45PM +1000, Michael Ellerman wrote:
> The pata_macio driver advertises a max_segment_size of 0xff00, because
> the hardware doesn't cope with requests >= 64K.
>
> However the SCSI core requires max_segment_size to be at least
> PAGE_SIZE, which is a problem for pata_m
On Wed, 5 Jun 2024 16:58:11 -0700
Yosry Ahmed wrote:
> On Wed, Jun 5, 2024 at 4:53 PM Yu Zhao wrote:
> >
> > On Wed, Jun 5, 2024 at 5:42 PM Yosry Ahmed wrote:
> > >
> > > On Wed, Jun 5, 2024 at 4:04 PM Erhard Furtner
> > > wrote:
> > > >
> > > > On Tue, 4 Jun 2024 20:03:27 -0700
> > > > Y
Fixed the issue where the kernel, when booting from address 0, had
code incorrectly duplicated to address 0.
Signed-off-by: Jinglin Wen
---
arch/powerpc/kernel/head_64.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/hea
On Thu, 6 Jun 2024 09:24:56 +0200
"Vlastimil Babka (SUSE)" wrote:
> Besides the zpool commit which might have just pushed the machine over the
> edge, but it was probably close to it already. I've noticed a more general
> problem that there are GFP_KERNEL allocations failing from kswapd. Those
>
https://bugzilla.kernel.org/show_bug.cgi?id=218858
--- Comment #24 from doru iorgulescu (doru.iorgules...@gmail.com) ---
Created attachment 306427
--> https://bugzilla.kernel.org/attachment.cgi?id=306427&action=edit
dmesg6100-rc2.txt
--
You may reply to this email to add a comment.
You are re
https://bugzilla.kernel.org/show_bug.cgi?id=218858
--- Comment #25 from doru iorgulescu (doru.iorgules...@gmail.com) ---
I finalized to compile linux kernel 6.10.0-rc2 uith the patch aplied and is OK!
Thank You
I have atached dmesg-6100-rc2.txt
Thank You Very mutch
Regards
--
You may reply to th
On Thu, 9 May 2024 16:48:33 +0800
Zhenzhong Duan wrote:
> When processing an ANFE, ideally both correctable error(CE) status and
> uncorrectable error(UE) status should be cleared. However, there is no
> way to fully identify the UE associated with ANFE. Even worse, Non-Fatal
> Error(NFE) may se
On Thu, 9 May 2024 16:48:31 +0800
Zhenzhong Duan wrote:
> In some cases the detector of a Non-Fatal Error(NFE) is not the most
> appropriate agent to determine the type of the error. For example,
> when software performs a configuration read from a non-existent
> device or Function, completer wi
On Thu, 9 May 2024 16:48:32 +0800
Zhenzhong Duan wrote:
> When an Advisory Non-Fatal error(ANFE) triggers, both correctable error(CE)
> status and ANFE related uncorrectable error(UE) status will be printed:
>
> AER: Correctable error message received from :b7:02.0
> PCIe Bus Error: sev
We found an AA deadlock problem as shown belowed:
TaskA TaskB WatchDog
system_wq
...
css_killed_work_fn:
P(cgroup_mutex)
...
...
> From: "Mark Brown"
> Sent: Friday, 31 May, 2024 18:06:30
> On Fri, May 31, 2024 at 10:48:14AM -0400, Elinor Montmasson wrote:
>> From: "Mark Brown"
>
>> > Why not just use the existing compatible - why would someone not want to
>> > be able to use the ASRC if it's available in their system?
>
On Thu, Jun 6, 2024 at 6:28 AM Erhard Furtner wrote:
>
> On Wed, 5 Jun 2024 16:58:11 -0700
> Yosry Ahmed wrote:
>
> > On Wed, Jun 5, 2024 at 4:53 PM Yu Zhao wrote:
> > >
> > > On Wed, Jun 5, 2024 at 5:42 PM Yosry Ahmed wrote:
> > > >
> > > > On Wed, Jun 5, 2024 at 4:04 PM Erhard Furtner
> > >
On 6/6/24 3:32 PM, Erhard Furtner wrote:
> On Thu, 6 Jun 2024 09:24:56 +0200
> "Vlastimil Babka (SUSE)" wrote:
>
>> Besides the zpool commit which might have just pushed the machine over the
>> edge, but it was probably close to it already. I've noticed a more general
>> problem that there are GF
On Thu, Jun 6, 2024 at 10:14 AM Takero Funaki wrote:
>
> 2024年6月6日(木) 8:42 Yosry Ahmed :
>
> > I think there are multiple ways to go forward here:
> > (a) Make the number of zpools a config option, leave the default as
> > 32, but allow special use cases to set it to 1 or similar. This is
> > prob
On Thu, Jun 6, 2024 at 11:42 AM Yosry Ahmed wrote:
>
> On Thu, Jun 6, 2024 at 10:14 AM Takero Funaki wrote:
> >
> > 2024年6月6日(木) 8:42 Yosry Ahmed :
> >
> > > I think there are multiple ways to go forward here:
> > > (a) Make the number of zpools a config option, leave the default as
> > > 32, but
On Thu, Jun 6, 2024 at 10:55 AM Yu Zhao wrote:
>
> On Thu, Jun 6, 2024 at 11:42 AM Yosry Ahmed wrote:
> >
> > On Thu, Jun 6, 2024 at 10:14 AM Takero Funaki wrote:
> > >
> > > 2024年6月6日(木) 8:42 Yosry Ahmed :
> > >
> > > > I think there are multiple ways to go forward here:
> > > > (a) Make the nu
On Thu, Jun 06, 2024 at 12:56:38PM +0530, Manivannan Sadhasivam wrote:
> Now that the API is available, let's make use of it. It also handles the
> reinitialization of DWC non-sticky registers in addition to sending the
> notification to EPF drivers.
>
> Reported-by: Bjorn Helgaas
> Closes: https
On Thu, Jun 06, 2024 at 12:56:34PM +0530, Manivannan Sadhasivam wrote:
> Currently dw_pcie_ep_init_notify() wrapper just calls pci_epc_init_notify()
> directly. So this wrapper provides no benefit to the glue drivers.
>
> So let's remove it and call pci_epc_init_notify() directly from glue
> drive
On Thu, Jun 06, 2024 at 12:56:35PM +0530, Manivannan Sadhasivam wrote:
> As like the 'epc_init' event, that is used to signal the EPF drivers about
> the EPC initialization, let's introduce 'epc_deinit' event that is used to
> signal EPC deinitialization.
>
> The EPC deinitialization applies only
https://bugzilla.kernel.org/show_bug.cgi?id=218858
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
2024年6月6日(木) 8:42 Yosry Ahmed :
> I think there are multiple ways to go forward here:
> (a) Make the number of zpools a config option, leave the default as
> 32, but allow special use cases to set it to 1 or similar. This is
> probably not preferable because it is not clear to users how to set
> i
Niklas Cassel writes:
> On Thu, Jun 06, 2024 at 09:14:45PM +1000, Michael Ellerman wrote:
>> The pata_macio driver advertises a max_segment_size of 0xff00, because
>> the hardware doesn't cope with requests >= 64K.
>>
>> However the SCSI core requires max_segment_size to be at least
>> PAGE_SIZE,
Perf bench futex fails as below when attempted to run on
on a powerpc system:
./perf bench futex all
Running futex/hash benchmark...
Run summary [PID 626307]: 80 threads, each operating on 1024 [private] futexes
for 10 secs.
perf: pthread_create: No such file or directory
In the setup where t
Perf bench epoll fails as below when attempted to run on
on a powerpc system:
./perf bench epoll wait
Running 'epoll/wait' benchmark:
Run summary [PID 627653]: 79 threads monitoring on 64 file-descriptors for 8
secs.
perf: pthread_create: No such file or directory
In the setup where
perf bench futex fails as below and hangs intermittently when
attempted to run on on a powerpc system:
./perf bench futex wake-parallel
Running 'futex/wake-parallel' benchmark:
Run summary [PID 88588]: blocking on 640 threads (at [private] futex
0x10464b8c), 640 threads waking up 1 at a time.
From: Arnd Bergmann
Building powerpc64le kernels with the kernel.org crosstool toolchains
no longer works as the linker attempts to build a big-endian vdso:
powerpc-linux/lib/gcc/powerpc-linux/12.3.0/../../../../powerpc-linux/bin/ld:
arch/powerpc/kernel/vdso/sigtramp32-32.o: compiled for a litt
42 matches
Mail list logo
