Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1612552 > unrolled thread
| Started by | Vikram Mulukutla <markivx@codeaurora.org> |
|---|---|
| First post | 2017-03-30 06:20 +0200 |
| Last post | 2017-03-30 12:30 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: spin_lock behavior with ARM64 big.Little/HMP Vikram Mulukutla <markivx@codeaurora.org> - 2017-03-30 06:20 +0200
Re: spin_lock behavior with ARM64 big.Little/HMP Sudeep Holla <sudeep.holla@arm.com> - 2017-03-30 12:30 +0200
| From | Vikram Mulukutla <markivx@codeaurora.org> |
|---|---|
| Date | 2017-03-30 06:20 +0200 |
| Subject | Re: spin_lock behavior with ARM64 big.Little/HMP |
| Message-ID | <tqzJ0-HD-7@gated-at.bofh.it> |
Hi Sudeep, > > Interesting. Just curious if this is r0p0/p1 A53 ? If so, is the errata > 819472 enabled ? Sorry for bringing this up after the loo-ong delay, but I've been assured that the A53 involved is > r0p1. I've also confirmed this problem on multiple internal platforms, and I'm pretty sure that it occurs on any b.L out there today. Also, we found the same problematic lock design used in the workqueue code in the kernel, causing the same livelock. It's very very rare and requires a perfect set of circumstances. If it would help I can provide a unit test if you folks would be generous enough to test it on the latest Juno or something b.L that's also upstream. Thanks, Vikram
[toc] | [next] | [standalone]
| From | Sudeep Holla <sudeep.holla@arm.com> |
|---|---|
| Date | 2017-03-30 12:30 +0200 |
| Message-ID | <tqFv4-4UX-5@gated-at.bofh.it> |
| In reply to | #1612552 |
On 30/03/17 05:12, Vikram Mulukutla wrote: > > Hi Sudeep, > >> >> Interesting. Just curious if this is r0p0/p1 A53 ? If so, is the errata >> 819472 enabled ? > > Sorry for bringing this up after the loo-ong delay, but I've been > assured that the A53 involved is > r0p1. I've also confirmed this > problem on multiple internal platforms, and I'm pretty sure that it > occurs on any b.L out there today. Also, we found the same problematic > lock design used in the workqueue code in the kernel, causing the same > livelock. It's very very rare and requires a perfect set of circumstances. > > If it would help I can provide a unit test if you folks would be > generous enough to test it on the latest Juno or something b.L that's > also upstream. > Sure, please do share the unit test. I will give that a try on Juno. -- Regards, Sudeep
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web