On 2020-Jun-11, at 16:49, Mark Millard wrote:
> On 2020-Jun-11, at 14:42, Justin Hibbits wrote:
>
> On Thu, 11 Jun 2020 14:36:37 -0700
> Mark Millard wrote:
>
>> On 2020-Jun-11, at 13:55, Justin Hibbits
>> wrote:
>>
>>> On Wed, 10 Jun 2020 18:56:57 -0700
>>> Mark Millard wrote:
> . . .
>>
On 2020-Jun-11, at 14:42, Justin Hibbits wrote:
On Thu, 11 Jun 2020 14:36:37 -0700
Mark Millard wrote:
> On 2020-Jun-11, at 13:55, Justin Hibbits
> wrote:
>
>> On Wed, 10 Jun 2020 18:56:57 -0700
>> Mark Millard wrote:
. . .
>
>
>> That said, the attached patch effectively copies
>> what's
On Thu, 11 Jun 2020 17:30:24 -0700
Mark Millard wrote:
> On 2020-Jun-11, at 16:49, Mark Millard wrote:
>
> > On 2020-Jun-11, at 14:42, Justin Hibbits
> > wrote:
> >
> > On Thu, 11 Jun 2020 14:36:37 -0700
> > Mark Millard wrote:
> >
> >> On 2020-Jun-11, at 13:55, Justin Hibbits
> >> wrote
On 2020-Jun-11, at 14:41, Brandon Bergren wrote:
> An update from my end: I now have the ability to test dual processor G4 as
> well, now that mine is up and running.
Cool.
FYI:
Dual processors are not required for the
problem to happen: the stress based testing
showed the problem just as
On 2020-Jun-11, at 13:55, Justin Hibbits wrote:
> On Wed, 10 Jun 2020 18:56:57 -0700
> Mark Millard wrote:
>
>> On 2020-May-13, at 08:56, Justin Hibbits wrote:
>>
>>> Hi Mark,
>>
>> Hello Justin.
>
> Hi Mark,
Hello again, Justin.
>>
>>> On Wed, 13 May 2020 01:43:23 -0700
>>> Mark Mi
On 6/11/20 10:19, Mark Johnston wrote:
> On Thu, Jun 11, 2020 at 10:08:08AM -0700, David Wolfskill wrote:
>> On Thu, Jun 11, 2020 at 07:44:21PM +0300, Konstantin Belousov wrote:
>>> ...
>>> This should fix noexec for modules.
>>>
>>> diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c
>>> inde
On Thu, 11 Jun 2020 14:36:37 -0700
Mark Millard wrote:
> On 2020-Jun-11, at 13:55, Justin Hibbits
> wrote:
>
> > On Wed, 10 Jun 2020 18:56:57 -0700
> > Mark Millard wrote:
> >
> >> On 2020-May-13, at 08:56, Justin Hibbits
> >> wrote:
> >>> Hi Mark,
> >>
> >> Hello Justin.
> >
> >
An update from my end: I now have the ability to test dual processor G4 as
well, now that mine is up and running.
On Thu, Jun 11, 2020, at 4:36 PM, Mark Millard wrote:
>
> How did you test?
>
> In my context it was far easier to see the problem
> with builds that did not use MALLOC_PRODUCTION.
On Wed, 10 Jun 2020 18:56:57 -0700
Mark Millard wrote:
> On 2020-May-13, at 08:56, Justin Hibbits wrote:
>
> > Hi Mark,
>
> Hello Justin.
Hi Mark,
>
> > On Wed, 13 May 2020 01:43:23 -0700
> > Mark Millard wrote:
> >
> >> [I'm adding a reference to an old arm64/aarch64 bug that had
>
On Thu, Jun 11, 2020 at 01:19:33PM -0400, Mark Johnston wrote:
> On Thu, Jun 11, 2020 at 10:08:08AM -0700, David Wolfskill wrote:
> > On Thu, Jun 11, 2020 at 07:44:21PM +0300, Konstantin Belousov wrote:
> > > ...
> > > This should fix noexec for modules.
> > >
> > > diff --git a/sys/x86/x86/mp_x86
On Thu, Jun 11, 2020 at 10:08:08AM -0700, David Wolfskill wrote:
> On Thu, Jun 11, 2020 at 07:44:21PM +0300, Konstantin Belousov wrote:
> > ...
> > This should fix noexec for modules.
> >
> > diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c
> > index 81db4d7ca85..cb84fc95691 100644
> > ---
On Thu, Jun 11, 2020 at 07:44:21PM +0300, Konstantin Belousov wrote:
> ...
> This should fix noexec for modules.
>
> diff --git a/sys/x86/x86/mp_x86.c b/sys/x86/x86/mp_x86.c
> index 81db4d7ca85..cb84fc95691 100644
> --- a/sys/x86/x86/mp_x86.c
> +++ b/sys/x86/x86/mp_x86.c
>
Thanks! Patch app
On Thu, Jun 11, 2020 at 09:33:31AM -0700, David Wolfskill wrote:
> On Thu, Jun 11, 2020 at 12:24:17PM -0400, Mark Johnston wrote:
> > ...
> > > Unfortunately, I ran out of time to do further experiments for now; I'll
> > > need to do some work-related things for a while, but thought that this
> > >
On Thu, Jun 11, 2020 at 12:24:17PM -0400, Mark Johnston wrote:
> ...
> > Unfortunately, I ran out of time to do further experiments for now; I'll
> > need to do some work-related things for a while, but thought that this
> > might at least provide some useful information.
> >
> > Here is what I co
On Thu, Jun 11, 2020 at 12:24:17PM -0400, Mark Johnston wrote:
> On Thu, Jun 11, 2020 at 09:11:56AM -0700, David Wolfskill wrote:
> > On Thu, Jun 11, 2020 at 06:51:43PM +0300, Konstantin Belousov wrote:
> > > ...
> > > Can you boot into single-user, without loading linux/cuse/nvidia modules.
> > >
On Thu, Jun 11, 2020 at 09:11:56AM -0700, David Wolfskill wrote:
> On Thu, Jun 11, 2020 at 06:51:43PM +0300, Konstantin Belousov wrote:
> > ...
> > Can you boot into single-user, without loading linux/cuse/nvidia modules.
> > Even, do not load any module at all, and keeping root ro.
> >
> > If boo
On Thu, Jun 11, 2020 at 06:51:43PM +0300, Konstantin Belousov wrote:
> ...
> Can you boot into single-user, without loading linux/cuse/nvidia modules.
> Even, do not load any module at all, and keeping root ro.
>
> If boot succeed, then try to load modules one by one and see which causes
> panic.
On Thu, Jun 11, 2020 at 08:44:56AM -0700, David Wolfskill wrote:
> On Thu, Jun 11, 2020 at 04:46:58PM +0300, Konstantin Belousov wrote:
> > ...
> > > I have not used -DNO_CLEAN in years -- I do use META_MODE, though. I
> > > can certainly clean out /usr/obj/* & start a new build (just before I
> >
On Thu, Jun 11, 2020 at 10:42:59AM -0400, Mark Johnston wrote:
> ...
> Since you are preloading some iwm firmware file, it might be worth
> trying to revert r362035. I don't really see how the change could
> result in this panic, though.
It's iwn (vs. iwm), but sure, I'll try that as time permits
On Thu, Jun 11, 2020 at 04:46:58PM +0300, Konstantin Belousov wrote:
> ...
> > I have not used -DNO_CLEAN in years -- I do use META_MODE, though. I
> > can certainly clean out /usr/obj/* & start a new build (just before I
> > head out for a bike ride).
>
> That, and also rebuild all third-party m
Op 11-06-2020 om 15:21 schreef Konstantin Belousov:
On Thu, Jun 11, 2020 at 06:05:00AM -0700, David Wolfskill wrote:
Build machine (mini-tower) performed the update (r362008 -> r362045)
without issue, but my laptop panicked quite early on -- before the dump
device was configured.
I have taken
Op 11-06-2020 om 15:21 schreef Konstantin Belousov:
On Thu, Jun 11, 2020 at 06:05:00AM -0700, David Wolfskill wrote:
Build machine (mini-tower) performed the update (r362008 -> r362045)
without issue, but my laptop panicked quite early on -- before the dump
device was configured.
I have taken
Hi Everyone, i haven't forget about this yet :)
I perform the following test in preparation to apply the patch:
1. Installed 12.1 stable with one disc in raid0, no issues (did this so
i can apply patch and don't have to build a new bootable image).
2. with 12.1 added second raid, in this
On Thu, Jun 11, 2020 at 06:29:24AM -0700, David Wolfskill wrote:
> On Thu, Jun 11, 2020 at 04:21:29PM +0300, Konstantin Belousov wrote:
> > ...
> > The link times out.
>
> Sigh. Sorry about that; I have copied the images to
> freefall:~dhw/head/r362045/ .
>
> > There is not much to access in fut
On Thu, Jun 11, 2020 at 06:29:24AM -0700, David Wolfskill wrote:
> On Thu, Jun 11, 2020 at 04:21:29PM +0300, Konstantin Belousov wrote:
> > ...
> > The link times out.
>
> Sigh. Sorry about that; I have copied the images to
> freefall:~dhw/head/r362045/ .
>
> > There is not much to access in fut
On Thu, Jun 11, 2020 at 04:21:29PM +0300, Konstantin Belousov wrote:
> ...
> The link times out.
Sigh. Sorry about that; I have copied the images to
freefall:~dhw/head/r362045/ .
> There is not much to access in futex_xchgl_resolver() except for the
> data segment. Without full panic message an
On Thu, Jun 11, 2020 at 06:05:00AM -0700, David Wolfskill wrote:
> Build machine (mini-tower) performed the update (r362008 -> r362045)
> without issue, but my laptop panicked quite early on -- before the dump
> device was configured.
>
> I have taken and placed a couple of screen shots in
> http:
Build machine (mini-tower) performed the update (r362008 -> r362045)
without issue, but my laptop panicked quite early on -- before the dump
device was configured.
I have taken and placed a couple of screen shots in
http://www.catwhisker.org/~david/FreeBSD/head/r362045/
Looking at the displayed b
28 matches
Mail list logo
