I wrote:
> [I repeat myself just in case my last message disappeared. It would be
> a shame if 4.4 was also regressed because of a missing response.]
Crap, I should have checked one more time before hitting send. The patch
is already in there! Sorry for the confusion.
Cheers,
Peter
--
To unsubsc
[I repeat myself just in case my last message disappeared. It would be
a shame if 4.4 was also regressed because of a missing response.]
I wrote:
> Russell King wrote:
> > On Thu, Dec 10, 2015 at 03:29:37PM +, Peter Rosin wrote:
> > > Russell King wrote:
> > > > On Thu, Dec 03, 2015 at 09:37:
Russell King wrote:
> On Thu, Dec 10, 2015 at 03:29:37PM +, Peter Rosin wrote:
> > Russell King wrote:
> > > On Thu, Dec 03, 2015 at 09:37:51PM +, Peter Rosin wrote:
> > > > I took both patches for a quick spin (a dozen boots and one hour
> > > > uptime after that for each patch) and no in
On Thu, Dec 10, 2015 at 03:29:37PM +, Peter Rosin wrote:
> Russell King wrote:
> > On Thu, Dec 03, 2015 at 09:37:51PM +, Peter Rosin wrote:
> > > I took both patches for a quick spin (a dozen boots and one hour uptime
> > > after that for each patch) and no incidents. I have not gathered da
Russell King wrote:
> On Thu, Dec 03, 2015 at 09:37:51PM +, Peter Rosin wrote:
> > I took both patches for a quick spin (a dozen boots and one hour uptime
> > after that for each patch) and no incidents. I have not gathered data,
> > but the crash on boot feels like it's quite a bit above 50% w
On Thu, Dec 03, 2015 at 09:37:51PM +, Peter Rosin wrote:
> I took both patches for a quick spin (a dozen boots and one hour uptime
> after that for each patch) and no incidents. I have not gathered data,
> but the crash on boot feels like it's quite a bit above 50% when there
> is a problem so
On Thu, Dec 03, 2015 at 01:28:12PM -0500, Nicolas Pitre wrote:
> On Thu, 3 Dec 2015, Russell King - ARM Linux wrote:
>
> > On Thu, Dec 03, 2015 at 04:41:18PM +, Russell King - ARM Linux wrote:
> > > On Thu, Dec 03, 2015 at 04:12:06PM +, Peter Rosin wrote:
> > > > * uaccess_with_memcpy.c:__
Russell King wrote:
> On Thu, Dec 03, 2015 at 04:41:18PM +, Russell King - ARM Linux wrote:
> > On Thu, Dec 03, 2015 at 04:12:06PM +, Peter Rosin wrote:
> > > * uaccess_with_memcpy.c:__copy_to_user() has a mode in which it copies
> > > "non-atomically" (if faulthandler_disabled() returns
On Thu, 3 Dec 2015, Russell King - ARM Linux wrote:
> On Thu, Dec 03, 2015 at 04:41:18PM +, Russell King - ARM Linux wrote:
> > On Thu, Dec 03, 2015 at 04:12:06PM +, Peter Rosin wrote:
> > > * uaccess_with_memcpy.c:__copy_to_user() has a mode in which it copies
> > > "non-atomically" (if
On Thu, Dec 03, 2015 at 04:41:18PM +, Russell King - ARM Linux wrote:
> On Thu, Dec 03, 2015 at 04:12:06PM +, Peter Rosin wrote:
> > * uaccess_with_memcpy.c:__copy_to_user() has a mode in which it copies
> > "non-atomically" (if faulthandler_disabled() returns 0). If a fault
> > happens
On Thu, Dec 03, 2015 at 04:12:06PM +, Peter Rosin wrote:
> Since it seems like a race is at the bottom of the observed problems, I'm
> going to look for things that look racy. The things that stand out to me
> are:
>
> * uaccess.h:modify_domain() does a read-modify-write on DACR using
> get_
Russell King wrote:
> On Thu, Dec 03, 2015 at 12:08:11PM +, Peter Rosin wrote:
> > Russell King wrote:
> > > On Thu, Dec 03, 2015 at 11:38:20AM +, Peter Rosin wrote:
> > > > Russell King wrote:
> > > > > On Thu, Dec 03, 2015 at 08:33:13AM +, Peter Rosin wrote:
> > > > > > I wrote:
> > >
On Thu, Dec 03, 2015 at 12:08:11PM +, Peter Rosin wrote:
> Russell King wrote:
> > On Thu, Dec 03, 2015 at 11:38:20AM +, Peter Rosin wrote:
> > > Russell King wrote:
> > > > On Thu, Dec 03, 2015 at 08:33:13AM +, Peter Rosin wrote:
> > > > > I wrote:
> > > > > > If I enable CONFIG_CPU_SW
Russell King wrote:
> On Thu, Dec 03, 2015 at 11:38:20AM +, Peter Rosin wrote:
> > Russell King wrote:
> > > On Thu, Dec 03, 2015 at 08:33:13AM +, Peter Rosin wrote:
> > > > I wrote:
> > > > > If I enable CONFIG_CPU_SW_DOMAIN_PAN, I sometimes (but not always)
> > > > > get the
> > > > > fo
On Thu, Dec 03, 2015 at 11:38:20AM +, Peter Rosin wrote:
> Russell King wrote:
> > On Thu, Dec 03, 2015 at 08:33:13AM +, Peter Rosin wrote:
> > > I wrote:
> > > > If I enable CONFIG_CPU_SW_DOMAIN_PAN, I sometimes (but not always) get
> > > > the
> > > > following (or very similar) on boot.
Russell King wrote:
> On Thu, Dec 03, 2015 at 08:33:13AM +, Peter Rosin wrote:
> > I wrote:
> > > If I enable CONFIG_CPU_SW_DOMAIN_PAN, I sometimes (but not always) get the
> > > following (or very similar) on boot.
> >
> > I should have said "if I don't disable", as the option is "default y".
On Thu, Dec 03, 2015 at 08:33:13AM +, Peter Rosin wrote:
> I wrote:
> > If I enable CONFIG_CPU_SW_DOMAIN_PAN, I sometimes (but not always) get the
> > following (or very similar) on boot.
>
> I should have said "if I don't disable", as the option is "default y".
>
> Also, if it survives on bo
I wrote:
> If I enable CONFIG_CPU_SW_DOMAIN_PAN, I sometimes (but not always) get the
> following (or very similar) on boot.
I should have said "if I don't disable", as the option is "default y".
Also, if it survives on boot, below is an example of later trouble (after 30+
minutes on
this occasi
Hi!
If I enable CONFIG_CPU_SW_DOMAIN_PAN, I sometimes (but not always) get the
following (or very similar) on boot.
Cheers,
Peter
Unhandled fault: page domain fault (0x81b) at 0x00086578
pgd = c281
[00086578] *pgd=22819831, *pte=224fe34f, *ppte=224fe83f
Internal error: : 81b [#1] ARM
Modules
19 matches
Mail list logo
