ork with the CCS driver, too, but that's
> > > another
> > > discussion.)
> > >
> > Using the CCS PLL calculator seems quite complicated compared to
> > switching to the CCS driver. That's why I looked at the later
> > first.
> > But for i
lready need to be applied in
> ccs_power_on(), to disable writing to COMPRESSION_MODE, and in
> ccs_identify_module(), to change the MODULE_MANUFACTURER_ID register.
>
> I'll check if CCS PLL calculator could be used.
>
> Best regards,
> André
Hi Sakari,
the CCS PLL c
Hi, all!
In the linux-next tree, next-20241108, coccinelle found an error.
In the line 617, ret = bpf_skb_set_tunnel_opt(skb, gopt, sizeof(local_gopt));
In the line 678, ret = bpf_skb_set_tunnel_opt(skb, gopt, sizeof(gopt));
when
592 struct local_geneve_opt local_gopt;
593 str
ng on
> > a saturated outgoing device. I missed this submission so that I haven't
> > checked it yet but given the description of v3->v4 changes above, it's
> > quite likely that it suffers from the same problem.
>
> And it indeed does. However, with the
going device. I missed this submission so that I haven't
>> checked it yet but given the description of v3->v4 changes above, it's
>> quite likely that it suffers from the same problem.
>
> And it indeed does. However, with the additional patch from the v3
>
the CPU time was spent in softirq
>>> and running top in parallel with the test confirms that there are
>>> multiple ksofirqd threads running at 100% CPU. I had similar problem
>>> with earlier versions of my patch (work in progress, I still need to
>>> check some c
> checked it yet but given the description of v3->v4 changes above, it's
> quite likely that it suffers from the same problem.
And it indeed does. However, with the additional patch from the v3
discussion, the numbers are approximately the same as with an unpatched
mainline kernel.
Note that there are two completely separate sysctls here - the timeout on fragments, and the amount of memory available
for fragment reassembly. You have to multiply them together to reach the "Mbps of lost or deliberately-lost fragments
before we start dropping all future fragments". See the cal
On Fri, Apr 16, 2021 at 09:16:48AM +0800, Yunsheng Lin wrote:
> Lockless qdisc has below concurrent problem:
> cpu0 cpu1
> . .
> q->enqueue .
> . .
(si: 3.8%) 20% (si:13.5%) 11% (si:3.8%)
>32 12% (si: 4.4%) 30% (si:22%) 13% (si:4.4%)
>64 13% (si: 4.9%) 35% (si:26%) 13% (si:4.7%)
>
> "11% (si: 3.8%)": 11% means the total cpu useage in node 0, and 3.8%
> means the sof
> but the growth is way beyond any statistical fluctuation with one
> > exception: 8-thread test of patched kernel showed values from 155.5% to
> > 311.4%. Closer look shows that most of the CPU time was spent in softirq
> > and running top in parallel with the test confirms
On 2021/4/19 10:04, Yunsheng Lin wrote:
> On 2021/4/19 6:59, Michal Kubecek wrote:
>> On Thu, Mar 25, 2021 at 11:13:11AM +0800, Yunsheng Lin wrote:
>>> Lockless qdisc has below concurrent problem:
>>> cpu0 cpu1
>>> .
On Sun, Apr 18, 2021 at 4:31 PM Matt Corallo
wrote:
>
> Should the default, though, be so low? If someone is still using a old modem
> they can crank up the sysctl, it does seem
> like such things are pretty rare these days :). Its rather trivial to,
> without any kind of attack, hit 1Mbps of lo
On 2021/4/19 6:59, Michal Kubecek wrote:
> On Thu, Mar 25, 2021 at 11:13:11AM +0800, Yunsheng Lin wrote:
>> Lockless qdisc has below concurrent problem:
>> cpu0 cpu1
>> .
On Thu, Mar 25, 2021 at 11:13:11AM +0800, Yunsheng Lin wrote:
> Lockless qdisc has below concurrent problem:
> cpu0 cpu1
> . .
> q->enqueue .
> . .
Should the default, though, be so low? If someone is still using a old modem they can crank up the sysctl, it does seem
like such things are pretty rare these days :). Its rather trivial to, without any kind of attack, hit 1Mbps of lost
fragments in today's networks, at which point all fragments
On Sat, Apr 17, 2021 at 10:26:30PM -0400, Matt Corallo wrote:
> Sure, there are better ways to handle the reassembly cache overflowing, but
> that is pretty unrelated to the fact that waiting 30 full seconds for a
> fragment to come in doesn't really make sense in today's networks (the 30
> second
Sure, there are better ways to handle the reassembly cache overflowing, but that is pretty unrelated to the fact that
waiting 30 full seconds for a fragment to come in doesn't really make sense in today's networks (the 30 second delay
that is used today appears to even be higher than RFC 791 sugg
Willy's words make sense to me and I agree that the existing fragments
should be evicted when the new one comes in and the cache is full.
Though the attacker can still leverage this to flush the victim's
cache, as mentioned previously, since fragments are likely to be
assembled in a very short time
See-also "[PATCH] Reduce IP_FRAG_TIME fragment-reassembly timeout to 1s, from 30s" (and the two resends of it) - given
the size of the default cache (4MB) and the time that it takes before we flush the cache (30 seconds) you only need
about 1Mbps of fragments to hit this issue. While DoS attacks
On Sat, Apr 17, 2021 at 12:42:39AM -0700, Keyu Man wrote:
> How about at least allow the existing queue to finish? Currently a tiny new
> fragment would potentially invalid all previous fragments by letting them
> timeout without allowing the fragments to come in to finish the assembly.
Because th
On Sat, Apr 17, 2021 at 06:44:40AM +0200, Eric Dumazet wrote:
> On Sat, Apr 17, 2021 at 2:31 AM David Ahern wrote:
> >
> > [ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
>
> I think this has been discussed already. There is no strategy that
> makes IP reassembly units immune to DDOS at
On Sat, Apr 17, 2021 at 2:31 AM David Ahern wrote:
>
> [ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
I think this has been discussed already. There is no strategy that
makes IP reassembly units immune to DDOS attacks.
We added rb-tree and sysctls to let admins choose to use GB of R
[ cc author of 648700f76b03b7e8149d13cc2bdb3355035258a9 ]
On 4/16/21 3:58 PM, Keyu Man wrote:
> Hi,
>
>
>
> My name is Keyu Man. We are a group of researchers from University
> of California, Riverside. Zhiyun Qian is my advisor. We found the code
> in processing IPv4/IPv6 fragments will p
Hi,
My name is Keyu Man. We are a group of researchers from University
of California, Riverside. Zhiyun Qian is my advisor. We found the code
in processing IPv4/IPv6 fragments will potentially lead to DoS
Attacks. Specifically, after the latest kernel receives an IPv4
fragment, it will try to
On Tue, 13 Apr 2021, Juergen Gross wrote:
> > what Jiri said about "I am still planning to have Yunsheng Lin's
> > (CCing) fix [1] tested in the coming days." is that Juergen has
> > done the test and provide a "Tested-by" tag.
>
> Correct. And I did this after Jiri asking me to do so.
Exactly,
Lockless qdisc has below concurrent problem:
cpu0 cpu1
. .
q->enqueue .
. .
qdisc_run_begin() .
. .
dequeue_skb() .
. .
sch_direct_x
This patchset fixes the packet stuck problem mentioned in [1].
Patch 1: Add STATE_MISSED flag to fix packet stuck problem.
Patch 2: Fix a tx_action rescheduling problem after STATE_MISSED
flag is added in patch 1.
V4: Change STATE_NEED_RESCHEDULE to STATE_MISSED and add patch 2.
[1
This patchset fixes the packet stuck problem mentioned in [1].
Patch 1: Add STATE_MISSED flag to fix packet stuck problem.
Patch 2: Fix a tx_action rescheduling problem after STATE_MISSED
flag is added in patch 1.
V4: Change STATE_NEED_RESCHEDULE to STATE_MISSED and add patch 2.
[1
On Thu, Apr 15, 2021 at 5:47 PM Gong, Sishuai wrote:
>
> Hi,
>
> We found a data race between tcp_set_default_congestion_control() and
> tcp_set_congestion_control() in linux-5.12-rc3.
> In general, when tcp_set_congestion_control() is reading ca->flags with a
> lock grabbed, tcp_set_default_con
Hi,
We found a data race between tcp_set_default_congestion_control() and
tcp_set_congestion_control() in linux-5.12-rc3.
In general, when tcp_set_congestion_control() is reading ca->flags with a lock
grabbed, tcp_set_default_congestion_control()
may be updating ca->flags at the same time, as
On Tue, 13 Apr 2021, Mike Rapoport wrote:
>
> I think I've found the reason. trim_snb_memory() reserved the entire first
> megabyte very early leaving no room for real mode trampoline allocation.
> Since this reservation is needed only to make sure integrated gfx does not
> access some memory, it
On 4/13/21 11:23 AM, Mike Rapoport wrote:
> On Tue, Apr 13, 2021 at 10:34:25AM -0700, Randy Dunlap wrote:
>> On 4/13/21 9:58 AM, Mike Rapoport wrote:
>>
>> Mike,
>> That works.
>>
>> Please send the next test.
>
> I think I've found the reason. trim_snb_memory() reserved the entire first
> megaby
On Tue, Apr 13, 2021 at 10:34:25AM -0700, Randy Dunlap wrote:
> On 4/13/21 9:58 AM, Mike Rapoport wrote:
> > On Mon, Apr 12, 2021 at 11:21:48PM -0700, Randy Dunlap wrote:
> >> On 4/12/21 11:06 PM, Mike Rapoport wrote:
> >>> Hi Randy,
> >>>
> >>> On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunla
On 4/13/21 9:58 AM, Mike Rapoport wrote:
> On Mon, Apr 12, 2021 at 11:21:48PM -0700, Randy Dunlap wrote:
>> On 4/12/21 11:06 PM, Mike Rapoport wrote:
>>> Hi Randy,
>>>
>>> On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
On 4/12/21 10:01 AM, Mike Rapoport wrote:
> On Mon, Apr
On Mon, Apr 12, 2021 at 11:21:48PM -0700, Randy Dunlap wrote:
> On 4/12/21 11:06 PM, Mike Rapoport wrote:
> > Hi Randy,
> >
> > On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
> >> On 4/12/21 10:01 AM, Mike Rapoport wrote:
> >>> On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap
ing to revert NOLOCK, but add optimization
to it if the patch fixes the packet stuck problem.
Fix is not optimization, right?
For this patch, it is a fix.
In case you missed it, I do have a couple of idea to optimize the
lockless qdisc:
1. RFC patch to add lockless qdisc bypass optimizat
sure I understood what you meant above.
>>>>>>
>>>>>> As my understanding, the below patch is essentially the same as
>>>>>> your previous patch, the only difference I see is it uses qdisc->pad
>>>>>> instead of __QDISC_ST
SC_STATE_NEED_RESCHEDULE.
>>>>
>>>> So instead of proposing another patch, it would be better if you
>>>> comment on my patch, and make improvement upon that.
>>>>
>>> Happy to do that after you show how it helps revert NOLOCK.
>>
&g
On 4/12/21 11:06 PM, Mike Rapoport wrote:
> Hi Randy,
>
> On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
>> On 4/12/21 10:01 AM, Mike Rapoport wrote:
>>> On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
>>>
>>> I thought about adding some prints to see what's causing
Hi Randy,
On Mon, Apr 12, 2021 at 01:53:34PM -0700, Randy Dunlap wrote:
> On 4/12/21 10:01 AM, Mike Rapoport wrote:
> > On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
> >
> > I thought about adding some prints to see what's causing the hang, the
> > reservations or their absence.
see is it uses qdisc->pad
>> instead of __QDISC_STATE_NEED_RESCHEDULE.
>>
>> So instead of proposing another patch, it would be better if you
>> comment on my patch, and make improvement upon that.
>>
> Happy to do that after you show how it helps revert NOLOCK.
Actually I am not going to revert NOLOCK, but add optimization
to it if the patch fixes the packet stuck problem.
Is there any reason why you want to revert it?
>
> .
>
On 2021/4/13 10:21, Hillf Danton wrote:
> On Mon, 12 Apr 2021 20:00:43 Yunsheng Lin wrote:
>>
>> Yes, the below patch seems to fix the data race described in
>> the commit log.
>> Then what is the difference between my patch and your patch below:)
>
> Hehe, this is one of the tough questions over
On 4/12/21 10:01 AM, Mike Rapoport wrote:
> On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
>> On 4/11/21 11:14 PM, Mike Rapoport wrote:
>>> Hi Randy,
>>>
>>> On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> Hi all,
>>
loc skbs as normal skbs.
> I'm not sure if you understand what I'm saying. Please look at the
> code of "__netif_receive_skb" and see what will happen when
> "sk_memalloc_socks()" is false and "skb_pfmemalloc(skb)" is true.
Do you see the problem now?
On Mon, Apr 12, 2021 at 08:49:49AM -0700, Randy Dunlap wrote:
> On 4/11/21 11:14 PM, Mike Rapoport wrote:
> > Hi Randy,
> >
> > On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
> >> On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> >>> Hi all,
> >>>
> >>> Changes since 20210408:
> >>>
> >>
On 4/11/21 11:14 PM, Mike Rapoport wrote:
> Hi Randy,
>
> On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
>> On 4/9/21 4:51 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20210408:
>>>
>>
>> Hi,
>>
>> I cannot boot linux-next 20210408 nor 20210409 on an antique
>> x86_
On 2021/4/12 15:28, Hillf Danton wrote:
> On Mon, 12 Apr 2021 11:37:24 Yunsheng Lin wrote:
>> On 2021/4/12 11:21, Hillf Danton wrote:
>>> On Mon, 12 Apr 2021 09:24:30 Yunsheng Lin wrote:
On 2021/4/9 17:09, Hillf Danton wrote:
> On Fri, 9 Apr 2021 07:31:03 Juergen Gross wrote:
>> On 2
On 12.04.21 03:04, Yunsheng Lin wrote:
On 2021/4/9 13:31, Juergen Gross wrote:
On 25.03.21 04:13, Yunsheng Lin wrote:
Lockless qdisc has below concurrent problem:
cpu0 cpu1
. .
q->enqu
Hi Randy,
On Sun, Apr 11, 2021 at 07:41:37PM -0700, Randy Dunlap wrote:
> On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20210408:
> >
>
> Hi,
>
> I cannot boot linux-next 20210408 nor 20210409 on an antique
> x86_64 laptop (Toshiba Portege).
>
> After many faile
On 2021/4/12 11:21, Hillf Danton wrote:
> On Mon, 12 Apr 2021 09:24:30 Yunsheng Lin wrote:
>> On 2021/4/9 17:09, Hillf Danton wrote:
>>> On Fri, 9 Apr 2021 07:31:03 Juergen Gross wrote:
On 25.03.21 04:13, Yunsheng Lin wrote:
I have a setup which is able to reproduce the issue quite reli
On 4/9/21 4:51 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20210408:
>
Hi,
I cannot boot linux-next 20210408 nor 20210409 on an antique
x86_64 laptop (Toshiba Portege).
After many failed tests, I finally resorted to git bisect,
which led me to:
git bisect start
# good: [e49d033bdd
On 2021/4/9 17:09, Hillf Danton wrote:
> On Fri, 9 Apr 2021 07:31:03 Juergen Gross wrote:
>> On 25.03.21 04:13, Yunsheng Lin wrote:
>> I have a setup which is able to reproduce the issue quite reliably:
>>
>> In a Xen guest I'm mounting 8 NFS shares and run sysbench fileio on
>> each of them. The
gt;> forcibly close the interruption and make the device unusable.
>>
>> Because the root cause of the problem is that ohci_suspend is not
>> called to perform normal interrupt shutdown operations when the system
>> enters S4 sleep mode.
>>
>> Therefore
On 2021/4/9 13:31, Juergen Gross wrote:
> On 25.03.21 04:13, Yunsheng Lin wrote:
>> Lockless qdisc has below concurrent problem:
>> cpu0 cpu1
>> . .
>> q->enqueue .
>> .
e' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Longfang-Liu/USB-ohci-fix-ohci-interruption-problem/20210409-155150
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: i386-randconfig-a012-20210411
On Fri, Apr 9, 2021 at 4:50 AM Eric Dumazet wrote:
>
> On 4/9/21 12:14 PM, Xie He wrote:
>
> Then simply copy the needed logic.
No, there's no such thing as "sockets" in some of the protocols. There
is simply no way to copy "the needed logic".
> >
e interrupt. It will cause
> the entire system to be stuck during sleep, causing the device to
> fail to respond.
>
> When the abnormal interruption reaches 100,000 times, the system will
> forcibly close the interruption and make the device unusable.
>
> Because the root cause of
On Fri, Apr 09, 2021 at 04:48:01PM +0800, Longfang Liu wrote:
> Kunpeng920's EHCI controller does not have SBRN register.
> Reading the SBRN register when the controller driver is
> initialized will get 0.
>
> When rebooting the EHCI driver, ehci_shutdown() will be called.
> if the sbrn flag is 0,
eds an "struct sock" argument. Some of
> my protocols act like a middle layer to another protocol and don't
> have any "struct sock".
Then simply copy the needed logic.
>
> Also, I think this is a problem in net/core/dev.c, there are a lot of
> old protocols
middle layer to another protocol and don't
have any "struct sock".
Also, I think this is a problem in net/core/dev.c, there are a lot of
old protocols that are not aware of pfmemalloc skbs. I don't think
it's a good idea to fix them one by one.
On Fri, Apr 9, 2021 at 2:58 AM Mel Gorman wrote:
>
> On Fri, Apr 09, 2021 at 02:14:12AM -0700, Xie He wrote:
> >
> > Do you mean that at the time "sk_memalloc_socks()" changes from "true"
> > to "false", there would be no in-flight skbs currently being received,
> > and all network communications
p device to be deactivated while pfmemalloc skbs still
>> existed. Have you encountered this problem?
>
> I'm not a user of swap devices or pfmemalloc skbs. I just want to make
> sure the protocols that I'm developing (not IP or IPv6) won't get
> pfmemalloc skbs when receiv
t; require the swap device to be deactivated while pfmemalloc skbs still
> > existed. Have you encountered this problem?
>
> I'm not a user of swap devices or pfmemalloc skbs. I just want to make
> sure the protocols that I'm developing (not IP or IPv6) won't get
&g
t; existed. Have you encountered this problem?
I'm not a user of swap devices or pfmemalloc skbs. I just want to make
sure the protocols that I'm developing (not IP or IPv6) won't get
pfmemalloc skbs when receiving, because those protocols cannot handle
them.
According to the code, it seems
Kunpeng920's EHCI controller does not have SBRN register.
Reading the SBRN register when the controller driver is
initialized will get 0.
When rebooting the EHCI driver, ehci_shutdown() will be called.
if the sbrn flag is 0, ehci_shutdown() will return directly.
The sbrn flag being 0 will cause th
On Fri, Apr 09, 2021 at 01:33:24AM -0700, Xie He wrote:
> On Fri, Apr 9, 2021 at 12:30 AM Mel Gorman
> wrote:
> >
> > Under what circumstances do you expect sk_memalloc_socks() to be false
> > and skb_pfmemalloc() to be true that would cause a problem?
>
> For exam
/* ConneXT has no sbrn register */
> + else if (pdev->vendor == PCI_VENDOR_ID_HUAWEI
> + && pdev->device == 0xa239)
Sorry.
There is a problem with the format, I need to resend
Thanks.
Longfang.
> + ; /* HUAWEI Kunpeng920 USB EHCI has no sbrn register */
> else
> pci_read_config_byte(pdev, 0x60, &ehci->sbrn);
>
>
Kunpeng920's EHCI controller does not have SBRN register.
Reading the SBRN register when the controller driver is
initialized will get 0.
When rebooting the EHCI driver, ehci_shutdown() will be called.
if the sbrn flag is 0, ehci_shutdown() will return directly.
The sbrn flag being 0 will cause th
On Fri, Apr 9, 2021 at 12:30 AM Mel Gorman wrote:
>
> Under what circumstances do you expect sk_memalloc_socks() to be false
> and skb_pfmemalloc() to be true that would cause a problem?
For example, if at the time the skb is allocated,
"sk_memalloc_socks()" was true, th
normal interruption reaches 100,000 times, the system will
forcibly close the interruption and make the device unusable.
Because the root cause of the problem is that ohci_suspend is not
called to perform normal interrupt shutdown operations when the system
enters S4 sleep mode.
Therefore, our so
On Thu, Apr 08, 2021 at 11:52:01AM -0700, Xie He wrote:
> Hi Mel Gorman,
>
> I may have found a problem in pfmemalloc skb handling in
> net/core/dev.c. I see there are "if" conditions checking for
> "sk_memalloc_socks() && skb_pfmemalloc(skb)", and when
7;s EHCI device to the whitelist.
> >>
> >> Changes in v2:
> >>- Fix some code style issues.
> >>- Update function name.
> >>
> >> Longfang Liu (2):
> >> USB:ehci:Add a whitelist for EHCI controllers
&
On 25.03.21 04:13, Yunsheng Lin wrote:
Lockless qdisc has below concurrent problem:
cpu0 cpu1
. .
q->enqueue .
. .
qdisc_run_begin() .
. .
dequeue_
Kunpeng920's EHCI controller does not have SBRN register.
Reading the SBRN register when the controller driver is
initialized will get 0.
When rebooting the EHCI driver, ehci_shutdown() will be called.
if the sbrn flag is 0, ehci_shutdown() will return directly.
The sbrn flag being 0 will cause th
iu (2):
USB:ehci:Add a whitelist for EHCI controllers
USB:ehci:fix Kunpeng920 ehci hardware problem
drivers/usb/host/ehci-pci.c | 29 +
1 file changed, 25 insertions(+), 4 deletions(-)
--
2.8.1
me code style issues.
>> - Update function name.
>>
>> Longfang Liu (2):
>> USB:ehci:Add a whitelist for EHCI controllers
>> USB:ehci:fix Kunpeng920 ehci hardware problem
>>
>> drivers/usb/host/ehci-pci.c | 30 ++
>>
Hi Mel Gorman,
I may have found a problem in pfmemalloc skb handling in
net/core/dev.c. I see there are "if" conditions checking for
"sk_memalloc_socks() && skb_pfmemalloc(skb)", and when the condition
is true, the skb is handled specially as a pfmemalloc skb, otherwi
e.
>
> Longfang Liu (2):
> USB:ehci:Add a whitelist for EHCI controllers
> USB:ehci:fix Kunpeng920 ehci hardware problem
>
> drivers/usb/host/ehci-pci.c | 30 ++
> 1 file changed, 26 insertions(+), 4 deletions(-)
I don't think we need a whole lis
Kunpeng920's EHCI controller does not have SBRN register.
Reading the SBRN register when the controller driver is
initialized will get 0.
When rebooting the EHCI driver, ehci_shutdown() will be called.
if the sbrn flag is 0, ehci_shutdown() will return directly.
The sbrn flag being 0 will cause th
ehci hardware problem
drivers/usb/host/ehci-pci.c | 30 ++
1 file changed, 26 insertions(+), 4 deletions(-)
--
2.8.1
On 2021/4/8 17:09, Longfang Liu wrote:
> (1) Add a whitelist for EHCI devices without SBRN registers.
> (2) Add Kunpeng920's EHCI device to the whitelist.
>
> Longfang Liu (2):
> USB:ehci:Add a whitelist for EHCI controllers
> USB:ehci:fix Kunpeng920 ehci hardware pr
(1) Add a whitelist for EHCI devices without SBRN registers.
(2) Add Kunpeng920's EHCI device to the whitelist.
Longfang Liu (2):
USB:ehci:Add a whitelist for EHCI controllers
USB:ehci:fix Kunpeng920 ehci hardware problem
drivers/usb/host/ehci-pci.c | 29 +--
Kunpeng920's EHCI controller does not have SBRN register.
Reading the SBRN register when the controller driver is
initialized will get 0.
When rebooting the EHCI driver, ehci_shutdown() will be called.
if the sbrn flag is 0, ehci_shutdown() will return directly.
The sbrn flag being 0 will cause th
(1) Add a whitelist for EHCI devices without SBRN registers.
(2) Add Kunpeng920's EHCI device to the whitelist.
Longfang Liu (2):
USB:ehci:Add a whitelist for EHCI controllers
USB:ehci:fix Kunpeng920 ehci hardware problem
drivers/usb/host/ehci-pci.c | 29 +--
ot be turned off after reboot. An interrupt
that is not closed will cause an exception to the device sharing
the interrupt.
Currently, Kunpeng920's EHCI hardware has this problem. We hope to
solve this problem by skipping reading the sbrn register value.
On the EHCI hardware of the next-
Kunpeng920's EHCI controller does not have SBRN register.
Reading the SBRN register when the controller driver is
initialized will get 0.
When rebooting the EHCI driver, ehci_shutdown() will be called.
if the sbrn flag is 0, ehci_shutdown() will return directly.
The sbrn flag being 0 will cause th
ag being 0 will cause the
> EHCI interrupt signal to not be turned off after reboot. An interrupt
> that is not closed will cause an exception to the device sharing
> the interrupt.
>
> Currently, our hardware has this problem. We hope to solve this
> problem by skipping reading the
after reboot. An interrupt
that is not closed will cause an exception to the device sharing
the interrupt.
Currently, our hardware has this problem. We hope to solve this
problem by skipping reading the sbrn register value. On the next
generation of hardware, we will define this SBRN register in
iously the kernel is
> not capable of handling interrupts at this time.
>
> Also, why would a device interrupt be reported at this time? What
> causes the interrupt request?
>
>> When the abnormal interruption reaches 100,000 times, the system will
>> forcibly close the
e' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Longfang-Liu/USB-ohci-fix-ohci-interruption-problem/20210402-173222
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: x86_64-randconfig-a005-20210401
em is powered off. Obviously the kernel is
not capable of handling interrupts at this time.
Also, why would a device interrupt be reported at this time? What
causes the interrupt request?
> When the abnormal interruption reaches 100,000 times, the system will
> forcibly close the interruptio
close this device interrupt. It will cause
> the entire system to be stuck during sleep, causing the device to
> fail to respond.
>
> When the abnormal interruption reaches 100,000 times, the system will
> forcibly close the interruption and make the device unusable.
>
> Because
On Sat, Mar 27, 2021 at 06:28:30PM +0800, Longfang Liu wrote:
> The input data of the ECB (AES) algorithm needs to be aligned
> with 16 bytes, and the input data of the XTS (AES) algorithm is
> at least 16 bytes. Otherwise the SEC hardware will go wrong.
>
> Signed-off-by: Longfang Liu
> ---
> d
ond.
When the abnormal interruption reaches 100,000 times, the system will
forcibly close the interruption and make the device unusable.
Because the root cause of the problem is that ohci_suspend is not
called to perform normal interrupt shutdown operations when the system
enters S4 sleep m
t. It will cause
> the entire system to be stuck during sleep, causing the device to
> fail to respond.
>
> When the abnormal interruption reaches 100,000 times, the system will
> forcibly close the interruption and make the device unusable.
>
> Because the root cause of th
ond.
When the abnormal interruption reaches 100,000 times, the system will
forcibly close the interruption and make the device unusable.
Because the root cause of the problem is that ohci_suspend is not
called to perform normal interrupt shutdown operations when the system
enters S4 sleep m
,
this e-mails is a follow-up of my report at:
https://bugzilla.suse.com/show_bug.cgi?id=1180681
There is a problem with *@plt symbols in some libraries, they are unresolved
by perf (memcmp@plt in this case):
> 0.26% main2/usr/lib64/libstdc++.so.6.0.280xa51a0
On Mon, Mar 29, 2021 at 04:38:10PM +0800, liulongfang wrote:
> On 2021/3/26 23:28, Alan Stern wrote:
> > On Fri, Mar 26, 2021 at 04:54:56PM +0800, Longfang Liu wrote:
> >> When OHCI enters the S4 sleep state, the USB sleep process will call
> >> check_root_hub_suspend() and ohci_bus_suspend() inste
> > > >
> > > > On 11. 01. 21, 7:31, Jiri Slaby wrote:
> > > > > Hi,
> > > > >
> > > > > this e-mails is a follow-up of my report at:
> > > > > https://bugzilla.suse.com/show_bug.cgi?id=1180681
> > &g
1 - 100 of 8013 matches
Mail list logo
