Re: Testing requested: Hybrid ISO/USB boot

[O'Connor, Daniel]

> On 24 Mar 2018, at 07:31, Benno Rice  wrote:
> I think I’ve addressed this in this revision:
> 
> https://svnweb.freebsd.org/changeset/base/331463 
> 
> 
> And I’ve regenerated the image here:
> 
> https://people.freebsd.org/~benno/hybrid-bootonly-20180323-00.iso.xz 
> 

Hi Benno,
I tried this image on a Supermicro SYS-5019S-M (X11SSH-Fmotherboard) and it 
boots both ways (USB was via a USB stick, ISO was via the IPMI CD emulation 
with the Java JNLP applet)

The USB way booted legacy and the CD emulation booted UEFI (not sure if that's 
significant).

I also tried renaming it to .img and then telling the JNLP applet it was a hard 
disk image but the BIOS didn't detect it.

It also has a 'Web ISO' option but I can't figure out how you're supposed to 
enter a URL so I couldn't try it.

Thanks for the work!

--
Daniel O'Connor
"The nice thing about standards is that there
are so many of them to choose from."
 -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Mon, Mar 26, 2018 at 01:11:28AM +0200, Bernd Walter wrote:
> On Mon, Mar 12, 2018 at 12:12:47PM +0100, Bernd Walter wrote:
> > On Sat, Mar 10, 2018 at 01:03:39AM +0100, Bernd Walter wrote:
> > > On Fri, Mar 09, 2018 at 02:25:39PM +0100, Bernd Walter wrote:
> > > So the older 7" HDMI C Rev 1.1 with the non IPS panel won't even attach, 
> > > but
> > > it always needed some special binary support for Linux, no surprises here.
> > > The newer Rev 2.1 with the IPS panel claims to be the same and work with
> > > webcamd, at least I get data via /dev/input/event0, which looks reasonable
> > > with evdev-dump.
> > > That's an interesting starting point.
> > 
> > I've got a new model of the 10" HDMI B.
> > It behaves differently.
> > First of all - uep seems to take it, which it didn't for any of
> > the previous displays I'd tested.
> > I had to remove the driver from the loader.conf to have webcamd attach to 
> > it.
> > webcamd attaches fine and it delivers touch events:
> > [29]sa# evdev-dump /dev/input/event0
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_TRACKING_ID 0x
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_POSITION_X 0x01CF
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_POSITION_Y 0x025E
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_PRESSURE 0x0005
> > /dev/input/event0  3041705595.425438 EV_KEY BTN_TOUCH 0x0001
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_X 0x01CF
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_Y 0x025E
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_PRESSURE 0x0005
> > /dev/input/event0  3041705595.425438 EV_SYN SYN_REPORT 0x
> > 
> > Whatever had been the cause for my previous problem, they obviously
> > have fixed them in firmware.
> 
> Unfortunately I still have some problems.
> [63]sa# evdev-dump /dev/input/event1
> /dev/input/event1  3043946310.664423 EV_ABS ABS_MT_TRACKING_ID 0x003F
> /dev/input/event1  3043946310.664423 EV_ABS ABS_MT_POSITION_X 0x01C9
> /dev/input/event1  3043946310.664423 EV_ABS ABS_MT_POSITION_Y 0x0112
> /dev/input/event1  3043946310.664423 EV_KEY BTN_TOUCH 0x0001
> /dev/input/event1  3043946310.664423 EV_ABS ABS_X 0x01C9
> /dev/input/event1  3043946310.664423 EV_ABS ABS_Y 0x0112
> /dev/input/event1  3043946310.664423 EV_SYN SYN_REPORT 0x
> /dev/input/event1  3043946310.784395 EV_ABS ABS_MT_TRACKING_ID 0x
> /dev/input/event1  3043946310.784395 EV_KEY BTN_TOUCH 0x
> /dev/input/event1  3043946310.784395 EV_SYN SYN_REPORT 0x
> 
> 
> 
> 
> /dev/input/event1  3043946316.944324 EV_ABS ABS_MT_TRACKING_ID 0x0040
> /dev/input/event1  3043946316.944324 EV_ABS ABS_MT_POSITION_X 0x01CE
> /dev/input/event1  3043946316.944324 EV_ABS ABS_MT_POSITION_Y 0x00FE
> /dev/input/event1  3043946316.944324 EV_KEY BTN_TOUCH 0x0001
> /dev/input/event1  3043946316.944324 EV_ABS ABS_X 0x01CE
> /dev/input/event1  3043946316.944324 EV_ABS ABS_Y 0x00FE
> /dev/input/event1  3043946316.944324 EV_SYN SYN_REPORT 0x
> /dev/input/event1  3043946317.004303 EV_ABS ABS_MT_TRACKING_ID 0x
> /dev/input/event1  3043946317.004303 EV_KEY BTN_TOUCH 0x
> /dev/input/event1  3043946317.004303 EV_SYN SYN_REPORT 0x
> 
> 
> 
> /dev/input/event1  3043946319.744283 EV_ABS ABS_MT_TRACKING_ID 0x0041
> /dev/input/event1  3043946319.744283 EV_ABS ABS_MT_POSITION_X 0x020E
> /dev/input/event1  3043946319.744283 EV_ABS ABS_MT_POSITION_Y 0x00D8
> /dev/input/event1  3043946319.744283 EV_KEY BTN_TOUCH 0x0001
> /dev/input/event1  3043946319.744283 EV_ABS ABS_X 0x020E
> /dev/input/event1  3043946319.744283 EV_ABS ABS_Y 0x00D8
> /dev/input/event1  3043946319.744283 EV_SYN SYN_REPORT 0x
> /dev/input/event1  3043946319.864240 EV_ABS ABS_MT_TRACKING_ID 0x
> /dev/input/event1  3043946319.864240 EV_KEY BTN_TOUCH 0x
> /dev/input/event1  3043946319.864240 EV_SYN SYN_REPORT 0x
> 
> 
> 
> /dev/input/event1  3043946322.004229 EV_ABS ABS_MT_TRACKING_ID 0x0042
> /dev/input/event1  3043946322.004229 EV_ABS ABS_MT_POSITION_X 0x0209
> /dev/input/event1  3043946322.004229 EV_ABS ABS_MT_POSITION_Y 0x00CD
> /dev/input/event1  3043946322.004229 EV_KEY BTN_TOUCH 0x0001
> /dev/input/event1  3043946322.004229 EV_ABS ABS_X 0x0209
> /dev/input/event1  3043946322.004229 EV_ABS ABS_Y 0x00CD
> /dev/input/event1  3043946322.004229 EV_SYN SYN_REPORT 0x
> 
> 
> 
> 
> /dev/input/event1  3043946325.454187 EV_ABS ABS_MT_POSITION_X 0x016A
> /dev/input/event1  3043946325.454187 EV_ABS ABS_MT_POSITION_Y 0x00D2
> /dev/input/event1  3043946325.454187 EV_ABS ABS_X 0x016A
> /dev/input/event1  3043946325.454187 EV_ABS ABS_Y 0x00D2
> /dev/input/event1  3043946325.454187 EV_SYN SYN_REPORT 0x
> /dev/input/event1  3043946325.574174 EV_ABS ABS_MT_POSITION_X 0x016B
> /dev/input/event1  3043946325.574174 EV_ABS ABS_X 0x016B
> /dev/input/event1  

Re: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Mon, Mar 12, 2018 at 12:12:47PM +0100, Bernd Walter wrote:
> On Sat, Mar 10, 2018 at 01:03:39AM +0100, Bernd Walter wrote:
> > On Fri, Mar 09, 2018 at 02:25:39PM +0100, Bernd Walter wrote:
> > So the older 7" HDMI C Rev 1.1 with the non IPS panel won't even attach, but
> > it always needed some special binary support for Linux, no surprises here.
> > The newer Rev 2.1 with the IPS panel claims to be the same and work with
> > webcamd, at least I get data via /dev/input/event0, which looks reasonable
> > with evdev-dump.
> > That's an interesting starting point.
> 
> I've got a new model of the 10" HDMI B.
> It behaves differently.
> First of all - uep seems to take it, which it didn't for any of
> the previous displays I'd tested.
> I had to remove the driver from the loader.conf to have webcamd attach to it.
> webcamd attaches fine and it delivers touch events:
> [29]sa# evdev-dump /dev/input/event0
> /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_TRACKING_ID 0x
> /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_POSITION_X 0x01CF
> /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_POSITION_Y 0x025E
> /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_PRESSURE 0x0005
> /dev/input/event0  3041705595.425438 EV_KEY BTN_TOUCH 0x0001
> /dev/input/event0  3041705595.425438 EV_ABS ABS_X 0x01CF
> /dev/input/event0  3041705595.425438 EV_ABS ABS_Y 0x025E
> /dev/input/event0  3041705595.425438 EV_ABS ABS_PRESSURE 0x0005
> /dev/input/event0  3041705595.425438 EV_SYN SYN_REPORT 0x
> 
> Whatever had been the cause for my previous problem, they obviously
> have fixed them in firmware.

Unfortunately I still have some problems.
[63]sa# evdev-dump /dev/input/event1
/dev/input/event1  3043946310.664423 EV_ABS ABS_MT_TRACKING_ID 0x003F
/dev/input/event1  3043946310.664423 EV_ABS ABS_MT_POSITION_X 0x01C9
/dev/input/event1  3043946310.664423 EV_ABS ABS_MT_POSITION_Y 0x0112
/dev/input/event1  3043946310.664423 EV_KEY BTN_TOUCH 0x0001
/dev/input/event1  3043946310.664423 EV_ABS ABS_X 0x01C9
/dev/input/event1  3043946310.664423 EV_ABS ABS_Y 0x0112
/dev/input/event1  3043946310.664423 EV_SYN SYN_REPORT 0x
/dev/input/event1  3043946310.784395 EV_ABS ABS_MT_TRACKING_ID 0x
/dev/input/event1  3043946310.784395 EV_KEY BTN_TOUCH 0x
/dev/input/event1  3043946310.784395 EV_SYN SYN_REPORT 0x




/dev/input/event1  3043946316.944324 EV_ABS ABS_MT_TRACKING_ID 0x0040
/dev/input/event1  3043946316.944324 EV_ABS ABS_MT_POSITION_X 0x01CE
/dev/input/event1  3043946316.944324 EV_ABS ABS_MT_POSITION_Y 0x00FE
/dev/input/event1  3043946316.944324 EV_KEY BTN_TOUCH 0x0001
/dev/input/event1  3043946316.944324 EV_ABS ABS_X 0x01CE
/dev/input/event1  3043946316.944324 EV_ABS ABS_Y 0x00FE
/dev/input/event1  3043946316.944324 EV_SYN SYN_REPORT 0x
/dev/input/event1  3043946317.004303 EV_ABS ABS_MT_TRACKING_ID 0x
/dev/input/event1  3043946317.004303 EV_KEY BTN_TOUCH 0x
/dev/input/event1  3043946317.004303 EV_SYN SYN_REPORT 0x



/dev/input/event1  3043946319.744283 EV_ABS ABS_MT_TRACKING_ID 0x0041
/dev/input/event1  3043946319.744283 EV_ABS ABS_MT_POSITION_X 0x020E
/dev/input/event1  3043946319.744283 EV_ABS ABS_MT_POSITION_Y 0x00D8
/dev/input/event1  3043946319.744283 EV_KEY BTN_TOUCH 0x0001
/dev/input/event1  3043946319.744283 EV_ABS ABS_X 0x020E
/dev/input/event1  3043946319.744283 EV_ABS ABS_Y 0x00D8
/dev/input/event1  3043946319.744283 EV_SYN SYN_REPORT 0x
/dev/input/event1  3043946319.864240 EV_ABS ABS_MT_TRACKING_ID 0x
/dev/input/event1  3043946319.864240 EV_KEY BTN_TOUCH 0x
/dev/input/event1  3043946319.864240 EV_SYN SYN_REPORT 0x



/dev/input/event1  3043946322.004229 EV_ABS ABS_MT_TRACKING_ID 0x0042
/dev/input/event1  3043946322.004229 EV_ABS ABS_MT_POSITION_X 0x0209
/dev/input/event1  3043946322.004229 EV_ABS ABS_MT_POSITION_Y 0x00CD
/dev/input/event1  3043946322.004229 EV_KEY BTN_TOUCH 0x0001
/dev/input/event1  3043946322.004229 EV_ABS ABS_X 0x0209
/dev/input/event1  3043946322.004229 EV_ABS ABS_Y 0x00CD
/dev/input/event1  3043946322.004229 EV_SYN SYN_REPORT 0x




/dev/input/event1  3043946325.454187 EV_ABS ABS_MT_POSITION_X 0x016A
/dev/input/event1  3043946325.454187 EV_ABS ABS_MT_POSITION_Y 0x00D2
/dev/input/event1  3043946325.454187 EV_ABS ABS_X 0x016A
/dev/input/event1  3043946325.454187 EV_ABS ABS_Y 0x00D2
/dev/input/event1  3043946325.454187 EV_SYN SYN_REPORT 0x
/dev/input/event1  3043946325.574174 EV_ABS ABS_MT_POSITION_X 0x016B
/dev/input/event1  3043946325.574174 EV_ABS ABS_X 0x016B
/dev/input/event1  3043946325.574174 EV_SYN SYN_REPORT 0x

All 5 blocks are a single touch, which means finger on screen for a short
moment.
On the first 3 I get position data and BTN_TOUCH 1 as well as BTN_TOUCH 0.
But this is not consistent, sometime I get only a 1 

Re: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so.

[Mark Millard]

On 2018-Mar-25, at 1:09 PM, Mark Johnston  wrote:

> On Sun, Mar 25, 2018 at 12:32:09PM -0700, Mark Millard wrote:
>> On 2018-Mar-25, at 11:34 AM, Mark Johnston  wrote:
>> 
>>> On Sun, Mar 25, 2018 at 10:41:38AM -0700, Mark Millard wrote:
 FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a"
 would get the "unnecessary swapping" problem in my UFS-only context,
 -r331499 (non-debug but with symbols), under Hyper-V. This is a
 Ryzen Threadripper context, but I've no clue if that is important
 to the problem. This was after 14 hours or so of building:
 
 . . .
 [14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | 
 p5-Test-HTML-Tidy-1.00_1: Success
 [14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | ocaml-camlp5-6.16
 
 So I've no clue if or how to repeat this.
 
 Unfortunately dump was unsuccessful. 
>>> 
>>> What happened?
>> 
>> It reported:
>> 
>> (da1:strovsc1:0:0:0) WRITE(10). CDB 2a 00 35 24 37 c7 00 00 0 00
>> (da1:storvsc1:0:0:0) CAM status Command timeout
>> (da1:storvsc1:0:0:0) Error 5, Retries exhausted
>> Aborting dump to to I/O error.
>> 
>> ** DUMP FAILED (ERROR 5) **
>> = 0x5
> 
> Thanks. Do you happen to know if this occurs consistently under Hyper-V?

For both "this" being (A) the panic and (B) the attempt
to dump to the Optane SSD that holds the swap/page partition:

First ever occurrence of the activity, so nothing to compare
with.

The system sat at the db> prompt for a notable time while I
was sleeping. It kept its "cores" busy while I slept. (Hardware
threads being very active is visible from Windows 10 Pro x64's
Task Manager.)

It is rare that I try such a large bulk build. I do such mostly
just to test how well the Ryzen Threadripper context seems to be
doing or to otherwise test something about FreeBSD stability.
I do buildworld buildkernel for such testing as well. Sometimes
both poudriere ports-building and FreeBSD-building in parallel
for a time.

I have started "poudriere bulk -j -w -a" again, letting
it continue from where it left off.

 So all I have is the
 backtrace. Hand typed from a screen shot of the console
 window:
>>> 
>>> Do you know what the panic message was? There are multiple calls to
>>> panic() in vm_page_free_prep().
>> 
>> No. I listed what I could see. The console screen does not have many
>> lines or rows and I was sleeping when the panic happened.
> 
> For future reference, you should be able to use "show panic" at the DDB
> prompt to get the panic message.

Da. Too obvious of a thing for me to think of checking for such on
my own. At least now I know. (It is not the first time that I could have
used that command.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so.

[Mark Millard]

[Just an added note about where in the sequence panic
messages are sent to the console vs. could potentially
be sent to the console.]

> On 2018-Mar-25, at 12:32 PM, Mark Millard  wrote:
> 
> On 2018-Mar-25, at 11:34 AM, Mark Johnston  wrote:
> 
>> On Sun, Mar 25, 2018 at 10:41:38AM -0700, Mark Millard wrote:
>>> FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a"
>>> would get the "unnecessary swapping" problem in my UFS-only context,
>>> -r331499 (non-debug but with symbols), under Hyper-V. This is a
>>> Ryzen Threadripper context, but I've no clue if that is important
>>> to the problem. This was after 14 hours or so of building:
>>> 
>>> . . .
>>> [14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | 
>>> p5-Test-HTML-Tidy-1.00_1: Success
>>> [14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | ocaml-camlp5-6.16
>>> 
>>> So I've no clue if or how to repeat this.
>>> 
>>> Unfortunately dump was unsuccessful. 
>> 
>> What happened?
> 
> It reported:
> 
> (da1:strovsc1:0:0:0) WRITE(10). CDB 2a 00 35 24 37 c7 00 00 0 00
> (da1:storvsc1:0:0:0) CAM status Command timeout
> (da1:storvsc1:0:0:0) Error 5, Retries exhausted
> Aborting dump to to I/O error.
> 
> ** DUMP FAILED (ERROR 5) **
> = 0x5
> 
>>> So all I have is the
>>> backtrace. Hand typed from a screen shot of the console
>>> window:
>> 
>> Do you know what the panic message was? There are multiple calls to
>> panic() in vm_page_free_prep().
> 
> No. I listed what I could see. The console screen does not have many
> lines or rows and I was sleeping when the panic happened.

I sometimes wonder if panic should repeat the panic message at the
end of the backtrace in order to deal with keeping it visible in
row-restricted console contexts.

> I redid a buildworld buildkernel installkernel installworld sequence
> since then and it looks like the detailed addresses changed (as seen
> in objdump now vs. what was on the console). But the relative offset
> in vm_page_free_prep seem to be a match, at least for the instruction
> after the "callq panic".
> 
> Looking at the kernel code I see:
> 
> . . .
>  mov0x81843690,%rax
>  mov$0x81d6d880,%rcx
>  sub%rcx,%rax
>  addq   $0x1,%gs:(%rax)
>  mov0x54(%rbx),%eax
>  and$0x1,%eax
>  jne
> . . .
> (several paths reach +0x106)
>  movw   $0x0,0x64(%rbx)
>  cmpl   $0x0,0x50(%rbx)
>  jne
> . . .
>  mov$0x8116628b,%rdi
>  jmp
>  mov$0x8120ca97,%rdi
>  xor%eax,%eax
>  mov%rbx,%rsi
>  callq  
>  nopw   %cs:0x0(%rax,%rax,1)
> 
> No KASSERTS present (a non-debug build). That leaves:
> 
>if (vm_page_sbusied(m))
>panic("vm_page_free: freeing busy page %p", m);
> and:
> 
>if (m->wire_count != 0)
>panic("vm_page_free: freeing wired page %p", m);
> 
> I do not have anything that lets me differentiate which
> occurred based on the above detail. Sorry.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so.

[Mark Johnston]

On Sun, Mar 25, 2018 at 12:32:09PM -0700, Mark Millard wrote:
> On 2018-Mar-25, at 11:34 AM, Mark Johnston  wrote:
> 
> > On Sun, Mar 25, 2018 at 10:41:38AM -0700, Mark Millard wrote:
> >> FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a"
> >> would get the "unnecessary swapping" problem in my UFS-only context,
> >> -r331499 (non-debug but with symbols), under Hyper-V. This is a
> >> Ryzen Threadripper context, but I've no clue if that is important
> >> to the problem. This was after 14 hours or so of building:
> >> 
> >> . . .
> >> [14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | 
> >> p5-Test-HTML-Tidy-1.00_1: Success
> >> [14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | ocaml-camlp5-6.16
> >> 
> >> So I've no clue if or how to repeat this.
> >> 
> >> Unfortunately dump was unsuccessful. 
> > 
> > What happened?
> 
> It reported:
> 
> (da1:strovsc1:0:0:0) WRITE(10). CDB 2a 00 35 24 37 c7 00 00 0 00
> (da1:storvsc1:0:0:0) CAM status Command timeout
> (da1:storvsc1:0:0:0) Error 5, Retries exhausted
> Aborting dump to to I/O error.
> 
> ** DUMP FAILED (ERROR 5) **
> = 0x5

Thanks. Do you happen to know if this occurs consistently under Hyper-V?

> >> So all I have is the
> >> backtrace. Hand typed from a screen shot of the console
> >> window:
> > 
> > Do you know what the panic message was? There are multiple calls to
> > panic() in vm_page_free_prep().
> 
> No. I listed what I could see. The console screen does not have many
> lines or rows and I was sleeping when the panic happened.

For future reference, you should be able to use "show panic" at the DDB
prompt to get the panic message.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Niclas Zeising]

On 2018-03-25 14:52, Sheda wrote:
>>
>> I've tested on two different computers, my ThinkPad x230 and my desktop
>> with a Intel DQ77MK motherboard.  I've only done light testing such as
>> loading efirt.ko and running efibootmgr to check the boot settings, but it
>> has worked fine.
>> I also haven't seen any issues with console graphics on either machine.
>> Both computers are running CURRENT from yesterday, the desktop is on
>> r331481 and the laptop probably somewhere around that as well.
>>
> 
> ​Hi,
> 
> I also would like to test the changes on my X230 but looking at ​
> https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.0/, the most
> recent snapshot seems to be r331345. How did you get r331481?
> 

Hi!
I updated my FreeBSD system from source.  There are instructions here
https://www.freebsd.org/doc/handbook/current-stable.html and here
https://www.freebsd.org/doc/handbook/makeworld.html on how to do it.
Regards
-- 
Niclas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so.

[Mark Millard]

On 2018-Mar-25, at 11:34 AM, Mark Johnston  wrote:

> On Sun, Mar 25, 2018 at 10:41:38AM -0700, Mark Millard wrote:
>> FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a"
>> would get the "unnecessary swapping" problem in my UFS-only context,
>> -r331499 (non-debug but with symbols), under Hyper-V. This is a
>> Ryzen Threadripper context, but I've no clue if that is important
>> to the problem. This was after 14 hours or so of building:
>> 
>> . . .
>> [14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | 
>> p5-Test-HTML-Tidy-1.00_1: Success
>> [14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | ocaml-camlp5-6.16
>> 
>> So I've no clue if or how to repeat this.
>> 
>> Unfortunately dump was unsuccessful. 
> 
> What happened?

It reported:

(da1:strovsc1:0:0:0) WRITE(10). CDB 2a 00 35 24 37 c7 00 00 0 00
(da1:storvsc1:0:0:0) CAM status Command timeout
(da1:storvsc1:0:0:0) Error 5, Retries exhausted
Aborting dump to to I/O error.

** DUMP FAILED (ERROR 5) **
= 0x5

>> So all I have is the
>> backtrace. Hand typed from a screen shot of the console
>> window:
> 
> Do you know what the panic message was? There are multiple calls to
> panic() in vm_page_free_prep().

No. I listed what I could see. The console screen does not have many
lines or rows and I was sleeping when the panic happened.

I redid a buildworld buildkernel installkernel installworld sequence
since then and it looks like the detailed addresses changed (as seen
in objdump now vs. what was on the console). But the relative offset
in vm_page_free_prep seem to be a match, at least for the instruction
after the "callq panic".

Looking at the kernel code I see:

. . .
 mov0x81843690,%rax
 mov$0x81d6d880,%rcx
 sub%rcx,%rax
 addq   $0x1,%gs:(%rax)
 mov0x54(%rbx),%eax
 and$0x1,%eax
 jne
. . .
(several paths reach +0x106)
 movw   $0x0,0x64(%rbx)
 cmpl   $0x0,0x50(%rbx)
 jne
. . .
 mov$0x8116628b,%rdi
 jmp
 mov$0x8120ca97,%rdi
 xor%eax,%eax
 mov%rbx,%rsi
 callq  
 nopw   %cs:0x0(%rax,%rax,1)

No KASSERTS present (a non-debug build). That leaves:

if (vm_page_sbusied(m))
panic("vm_page_free: freeing busy page %p", m);
and:

if (m->wire_count != 0)
panic("vm_page_free: freeing wired page %p", m);

I do not have anything that lets me differentiate which
occurred based on the above detail. Sorry.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: problem with [intr{swi4: clock (0)}]

[AN]

Hi:


On Fri, 23 Mar 2018, John Baldwin wrote:


Date: Fri, 23 Mar 2018 12:11:03 -0700
From: John Baldwin 
To: freebsd-current@freebsd.org
Cc: AN , "ma...@freebsd.org" ,
"" 
Subject: Re: problem with [intr{swi4: clock (0)}]

On Wednesday, March 21, 2018 11:36:48 AM AN wrote:

Hi:

I would appreciate any help with this issue, this is a new machine built
in the last week and if it is a hardware issue I want to return it.  The
problem seems to have started in the last 24 hours or so.  I am seeing a
really high cpu utilization for [intr{swi4: clock (0)}].  I have tried a
couple things to troubleshoot:


I would try using dtrace to figure out which functions are running in the
callout thread.  I've cc'd a couple of folks in case they already have dtrace
scripts to do this.  You would probably want a script that watched
callout_execute::callout-start and callout_execute::callout-end events.  You
would want to save the start time in callout-start and then report a delta
along with the values of 'c->c_func' (the last argument to these probes is
'c').  You might be able to just store the time delta in an aggregate that is
keyed on the function.  Actually, I've gone ahead and written a little
script:


callout_execute:::callout-start
{
self->start = timestamp;
self->func = args[0]->c_func;
@funcs[self->func] = count();
}

callout_execute:::callout-end
{
@functimes[self->func] = sum(timestamp - self->start);
}

END
{
printf("\n\nCallout function counts:\n");
printa("%@8u %a\n", @funcs);
printf("\nCallout function runtime:\n");
printa("%@d %a\n", @functimes);
}


Store this in a file named 'callout.d' and then run 'dtrace -s callout.d'.
Let it run for a second or two and then use Ctrl-C to stop it.

The first table it will output is a histogram showing how many times
different functions were invoked.   The second table will count how much
total time was spent in each function:

CPU IDFUNCTION:NAME
 4  2 :END

Callout function counts:
  2 kernel`kbdmux_kbd_intr_timo
  2 kernel`usb_power_wdog
  2 kernel`ipport_tick
  2 kernel`tcp_timer_delack
  2 kernel`nd6_timer
  2 kernel`key_timehandler
  2 dtrace.ko`dtrace_state_deadman
  4 kernel`newnfs_timer
  4 kernel`pfslowtimo
 10 kernel`logtimeout
 10 kernel`pffasttimo
 18 kernel`lim_cb
 32 kernel`iflib_timer
 84 kernel`sleepq_timeout
224 dtrace.ko`dtrace_state_clean

Callout function runtime:
2080 kernel`logtimeout
2198 kernel`kbdmux_kbd_intr_timo
2890 kernel`ipport_tick
3550 kernel`iflib_timer
3672 kernel`lim_cb
3936 kernel`pffasttimo
4023 dtrace.ko`dtrace_state_clean
4224 kernel`newnfs_timer
4751 kernel`key_timehandler
5286 kernel`nd6_timer
6700 kernel`usb_power_wdog
7341 kernel`pfslowtimo
19607 kernel`tcp_timer_delack
20273 dtrace.ko`dtrace_state_deadman
32262 kernel`sleepq_timeout

You can use this to figure out which timer events are using CPU in the
softclock thread/process.




To John and others who responded thanks for your time.  I have to 
apologize though for wasting your spare cpu cycles.  It turns out the root 
cause was a malfunctioning USB keyboard with a stuck key.  Removed and 
replaced, now everything is working normally.  Thanks again and sorry 
for the noise.


Best regards,

Andy
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so.

[Mark Johnston]

On Sun, Mar 25, 2018 at 10:41:38AM -0700, Mark Millard wrote:
> FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a"
> would get the "unnecessary swapping" problem in my UFS-only context,
> -r331499 (non-debug but with symbols), under Hyper-V. This is a
> Ryzen Threadripper context, but I've no clue if that is important
> to the problem. This was after 14 hours or so of building:
> 
> . . .
> [14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | 
> p5-Test-HTML-Tidy-1.00_1: Success
> [14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | ocaml-camlp5-6.16
> 
> So I've no clue if or how to repeat this.
> 
> Unfortunately dump was unsuccessful. 

What happened?

> So all I have is the
> backtrace. Hand typed from a screen shot of the console
> window:

Do you know what the panic message was? There are multiple calls to
panic() in vm_page_free_prep().
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

head -r331499 amd64/threadripper panic in vm_page_free_prep during "poudriere bulk -a", after 14h 22m or so.

[Mark Millard]

FreeBSD panic'd while attempting to see if a "poudriere bulk -w -a"
would get the "unnecessary swapping" problem in my UFS-only context,
-r331499 (non-debug but with symbols), under Hyper-V. This is a
Ryzen Threadripper context, but I've no clue if that is important
to the problem. This was after 14 hours or so of building:

. . .
[14:22:05] [18] [00:01:16] Finished devel/p5-Test-HTML-Tidy | 
p5-Test-HTML-Tidy-1.00_1: Success
[14:22:08] [18] [00:00:00] Building devel/ocaml-camlp5 | ocaml-camlp5-6.16

So I've no clue if or how to repeat this.

Unfortunately dump was unsuccessful. So all I have is the
backtrace. Hand typed from a screen shot of the console
window:

cpuid = 18
time = 1521986594
KDB: stack backtrace:
db_trace_self_srapper() at db_trace_self_srapper+0x2b/frame 0xfe00f2e132a0
vpanic() at vpanic+0x18d/frame 0xfe00f2e13300
panic() at panic+0c43/frame 0xfe00f2e13360
vm_page_free_prep() at vm_page_free_prep+0x174/frame 0xfe00f2e13390
vm_page_free_toq() at vm_page_free_toq+0x11/frame 0xfe00f2e133b0
unlock_and_deallocate() at unlock_and_deallocate+0xbb/frame 0xfe00f2e133d0
vm_fault_hold() at vm_fault_hold+0x1d04/frame 0xfe00f2e13500
proc_rwmem() at proc_rwmem+0x8d/frame 0xfe00f2e13570
proc_readmem() at proc_readmem+0x46/frame 0xfe00f2e135d0
get_proc_vector() at get_proc_vector+0x16e/frame 0xfe00f2e13660
proc_getauxv() at proc_getauxv+0x26/frame 0xfe00f2e136a0
elf64_note_procstat_auxv() at elf64_note_procstat_auxv+0x1ee/frame 
0xfe00f2e136f0
elf64_coredump() at elf64coredump+0x57c7/frame 0xfe00f2e137c0
sigexit() at sigexit+0x76f/frame 0xfe00f2e139b0
postsig() at postsig+0x289/frame 0xfe00f2e13a70
ast() at ast+0x357/frame 0xfe00f2e13ab0
doreti_ast() at doreti_ast+0x1f/frame 0x706d6f6320432041
KBD: enter: panic
[ thread pid 61836 tid 101063 ]
Stopped at kdb_enter+0x3b: movq $0,kdb_why


The Hyper-V/Ryzen-Threadripper context was/is:

FreeBSD 12.0-CURRENT  r331499M amd64
FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 
6.0.0)
SRAT: Ignoring memory at addr 0x1b2820
VT(vga): text 80x25
Hyper-V Version: 10.0.16299 [SP0]
  
Features=0x2e7f
  PM Features=0x0 [C2]
  Features3=0xbed7b2
Timecounter "Hyper-V" frequency 1000 Hz quality 2000
CPU: AMD Ryzen Threadripper 1950X 16-Core Processor  (3393.73-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x800f11  Family=0x17  Model=0x1  Stepping=1
  
Features=0x1783fbff
  
Features2=0xfed83203
  AMD Features=0x2e500800
  AMD Features2=0x3f3
  Structured Extended 
Features=0x201c01a9
  XSAVE Features=0xf
  AMD Extended Feature Extensions ID EBX=0x4
Hypervisor: Origin = "Microsoft Hv"
real memory  = 115964116992 (110592 MB)
avail memory = 112847249408 (107619 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 29 CPUs
FreeBSD/SMP: 1 package(s) x 29 core(s)

(I leave 3 hardware threads and some of the 128 GiBytes
of memory for Windows 10 Pro x64.)

FreeBSD and its swap are directly on NVMe SSDs, not in
NTFS file(s).


The M in -r331499M is for powerpc64/powerpc/arm64/armv7
related experiments, not amd64:

# svnlite status /usr/src/ | sort
?   /usr/src/nohup.out
?   /usr/src/sys/amd64/conf/GENERIC-DBG
?   /usr/src/sys/amd64/conf/GENERIC-NODBG
?   /usr/src/sys/arm/conf/GENERIC-DBG
?   /usr/src/sys/arm/conf/GENERIC-NODBG
?   /usr/src/sys/arm64/conf/GENERIC-DBG
?   /usr/src/sys/arm64/conf/GENERIC-NODBG
?   /usr/src/sys/dts/arm/a83t.dtsi
?   /usr/src/sys/dts/arm/sinovoip-bpi-m3.dts
?   /usr/src/sys/dts/arm/sun8i-a83t-sinovoip-bpi-m3.dts
?   /usr/src/sys/dts/arm/sun8i-a83t.dtsi
?   /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG
?   /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG
?   /usr/src/sys/powerpc/conf/GENERICvtsc-DBG
?   /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG
M   /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
M   /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
M   /usr/src/crypto/openssl/crypto/armcap.c
M   /usr/src/lib/libkvm/kvm_powerpc.c
M   /usr/src/lib/libkvm/kvm_private.c
M   /usr/src/stand/defs.mk
M   /usr/src/stand/powerpc/boot1.chrp/Makefile
M   /usr/src/stand/powerpc/kboot/Makefile
M   /usr/src/sys/arm64/arm64/identcpu.c
M   /usr/src/sys/conf/kmod.mk
M   /usr/src/sys/conf/ldscript.powerpc
M   /usr/src/sys/kern/subr_pcpu.c
M   /usr/src/sys/modules/dtb/allwinner/Makefile
M   /usr/src/sys/powerpc/aim/mmu_oea64.c
M   

Re: Call for Testing: UEFI Changes

[Sheda]

>
> I've tested on two different computers, my ThinkPad x230 and my desktop
> with a Intel DQ77MK motherboard.  I've only done light testing such as
> loading efirt.ko and running efibootmgr to check the boot settings, but it
> has worked fine.
> I also haven't seen any issues with console graphics on either machine.
> Both computers are running CURRENT from yesterday, the desktop is on
> r331481 and the laptop probably somewhere around that as well.
>

​Hi,

I also would like to test the changes on my X230 but looking at ​
https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/12.0/, the most
recent snapshot seems to be r331345. How did you get r331481?

Regards,

-S
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 12-Current panics on boot (didn't a week ago.)

[Jonathan Looney]

For now, you can update through r331485 and then take TCP_BLACKBOX out of
your kernel config file. That won’t really “fix” anything, but should at
least get you a booting system (assuming the new code from r331347 is
really triggering a problem).


I’ll take another look to see if I missed something in the commit. But, at
the moment, I’m hard-pressed to see how r331347 would cause the problem you
describe.


Jonathan

On Sat, Mar 24, 2018 at 9:17 PM Andrew Reilly 
wrote:

> OK, I've completed the search: r331346 works, r331347 panics
> somewhere in the initialization of random.
>
> In the 331347 change (Add the "TCP Blackbox Recorder") I can't see
> anything obvious to tweak, unfortunately.  It's a fair chunk of new
> code but it's all network-stack related, and my kernel is panicking
> long before any network activity happens.
>
> Any suggestions?
>
> Cheers,
>
> Andrew
>
> On Sat, Mar 24, 2018 at 05:23:18PM -0600, Warner Losh wrote:
> > Thanks Andrew... I can't recreate this on my VM nor my real hardware.
> >
> > Warner
> >
> > On Sat, Mar 24, 2018 at 5:22 PM, Andrew Reilly 
> > wrote:
> >
> > > So, r331464 crashes in the same place, on my system.  r331064 still
> boots
> > > OK.  I'll keep searching.
> > >
> > > One week ago there was a change to randomdev to poll for signals every
> so
> > > often, as a defence against very large reads.  That wouldn't have
> > > introduced a race somewhere,
> > > or left things in an unexpected state, perhaps?  That change (r331070)
> by
> > > cem@ is just a few revisions after the one that is working for me.
> I'll
> > > start looking there...
> > >
> > > Cheers,
> > >
> > > Andrew
> > >
> > > On Sun, Mar 25, 2018 at 07:49:17AM +1100, Andrew Reilly wrote:
> > > > Hi Warner,
> > > >
> > > > The breakage was in 331470,  and at least one version earlier, that I
> > > updated past when it panicked.
> > > >
> > > > I'm guessing that kdb's inability to dump would be down to it not
> having
> > > found any disk devices yet, right?  So yes, bisecting to narrow down
> the
> > > issue is probably the best bet.  I'll try your r331464: if that works
> that
> > > leaves only four or five revisions.  Of course the breakage could be
> > > hardware specific.
> > > >
> > > > Cheers,
> > > > --
> > > > Andrew
> > >
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 12-Current panics on boot (didn't a week ago.)

[Herbert J. Skuhra]

On Sun, 25 Mar 2018 05:21:10 +0200, Andrew Reilly wrote:
> 
> OK, I've completed the search: r331346 works, r331347 panics
> somewhere in the initialization of random.
> 
> In the 331347 change (Add the "TCP Blackbox Recorder") I can't see
> anything obvious to tweak, unfortunately.  It's a fair chunk of new
> code but it's all network-stack related, and my kernel is panicking
> long before any network activity happens.
> 
> Any suggestions?

Does your system boot if you upgrade to at least r331485 and remove
"options TCP_BLACKBOX" from sys/amd64/conf/GENERIC (if you build and
run GENERIC)?

--
Herbert
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Strange ARC/Swap/CPU on yesterday's -CURRENT

[Slawa Olhovchenkov]

On Fri, Mar 23, 2018 at 04:21:32PM -0700, Bryan Drewery wrote:

> On 3/20/2018 12:07 AM, Peter Jeremy wrote:
> > 
> > On 2018-Mar-11 10:43:58 -1000, Jeff Roberson  
> > wrote:
> >> Also, if you could try going back to r328953 or r326346 and let me know if 
> >> the problem exists in either.  That would be very helpful.  If anyone is 
> >> willing to debug this with me contact me directly and I will send some 
> >> test patches or debugging info after you have done the above steps.
> > 
> > I ran into this on 11-stable and tracked it to r326619 (MFC of r325851).
> > I initially got around the problem by reverting that commit but either
> > it or something very similar is still present in 11-stable r331053.
> > 
> > I've seen it in my main server (32GB RAM) but haven't managed to reproduce
> > it in smaller VBox guests - one difficulty I faced was artificially filling
> > ARC.
> > 
> 
> Looking at the ARC change you referred to from r325851
> https://reviews.freebsd.org/D12163, I am convinced that ARC backpressure
> is completely broken. On my 78GB RAM system with ARC limited to 40GB and
> doing a poudriere build of all LLVM and GCC packages at once in tmpfs I
> can get swap up near 50GB and yet the ARC remains at 40GB through it
> all.  It's always been slow to give up memory for package builds but it
> really seems broken right now.

Can you test: revert all 'needfree' related commits and applay
https://reviews.freebsd.org/D7538 ?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: UEFI Changes

[Niclas Zeising]

On 03/22/18 01:45, Kyle Evans wrote:

Hello!

A number of changes have gone in recently pertaining to UEFI booting
and UEFI runtime services. The changes with the most damaging
potential are:

We now put UEFI runtime services into virtual address mode, fixing
runtime services with U-Boot/UEFI as well as the firmware
implementation in many Lenovos. The previously observed behavior was a
kernel panic upon invocation of efibootmgr/efivar, or a kernel panic
just loading efirt.ko or compiling EFIRT into the kernel.

Graphics mode selection is now done differently to avoid regression
caused by r327058 while still achieving the same effect. The observed
regression was that the kernel would usually end up drawing
incorrectly at the old resolution on a subset of the screen, due to
incorrect framebuffer information.

Explicit testing of these changes, the latest of which happened in
r331326, and any feedback from this testing would be greatly
appreciated. Testing should be done with either `options EFIRT` in
your kernel config or efirt.ko loaded along with updated bootloader
bits.

I otherwise plan to MFC commits involved with the above-mentioned
changes by sometime in the first week of April, likely no earlier than
two (2) weeks from now on April 4th.



Hi!
I've tested on two different computers, my ThinkPad x230 and my desktop 
with a Intel DQ77MK motherboard.  I've only done light testing such as 
loading efirt.ko and running efibootmgr to check the boot settings, but 
it has worked fine.

I also haven't seen any issues with console graphics on either machine.
Both computers are running CURRENT from yesterday, the desktop is on 
r331481 and the laptop probably somewhere around that as well.


Please let me know if you want me to test anything else!
Regards
--
Niclas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"