Re: How to find CPU microcode version ?

[Kurt Jaeger]

Hi!

> > One situation that can cause out of swap errors is large amounts of
> > wired ram.
> 
> Indeed: Very large amounts of wired RAM. What happened ? This
> did not happen before the last upgrade ? I'm at r328899.

vfs.zfs.arc_max was at 32345493504

changed that to

vfs.zfs.arc_max=16172746752

Looks better now.

-- 
p...@opsec.eu+49 171 3101372 2 years to go !
___
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: How to find CPU microcode version ?

[Kurt Jaeger]

Hi!

> One situation that can cause out of swap errors is large amounts of
> wired ram.

Indeed: Very large amounts of wired RAM. What happened ? This
did not happen before the last upgrade ? I'm at r328899.

CPU:  0.0% user,  0.0% nice,  0.1% system,  0.0% interrupt, 99.9% idle
Mem: 2472K Active, 8K Inact, 31G Wired, 515M Free
ARC: 25G Total, 19G MFU, 3792M MRU, 840K Anon, 492M Header, 2040M Other
 22G Compressed, 36G Uncompressed, 1.67:1 Ratio
Swap: 34G Total, 76M Used, 34G Free, 8K In, 92K Out

-- 
p...@opsec.eu+49 171 3101372 2 years to go !
___
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"

A small procedural request

[Julian Elischer]

Hi,  I have a very small request to those committing into head.

If you commit a fix, then if it is possible to easily do so, can you 
give the revision number in which the regression was introduced?


like "this was  broken in r329xxx"

this allows people who are looking for specific problems to say "Ok 
that bug was introduced after the snapshot I'm working on and can't be 
my issue".


(we are not always working on the very tip).


thanks

Julian


___
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: GELI with UEFI supporting Boot Environments goes to HEAD when?

[Tommi Pernila]

Hi Eric,

could you provide a brief update how the work is going?


Br,

Tommi


On Nov 16, 2017 04:29, "Eric McCorkle"  wrote:

Right, so basically, the remaining GELI patches are against loader, and
most of them can go in independently of the work on removing boot1.
There's a unanimous consensus on getting rid of boot1 which includes its
original author, so that's going to happen.


For GELI, we have the following (not necessarily in order):

a) Adding the KMS interfaces, pseudo-device, and kernel keybuf interactions
b) Modifications to the efipart driver
c) boot crypto
d) GELI partition types (not strictly necessary)

Then there's the GELI driver itself.  (a) and (c) are good to land, (b)
needs some more work after Toomas Soome pointed out a legitimate
problem, and (d) actually needs a good bit more code (but again, it's
more cosmetic).  Additionally, the GELI driver will need further mods to
efipart to be written (nothing too big).  But we could go ahead with (a)
and (c), as they've already been proven to work.

I'd wanted to have this stuff shaped up sooner, but I'm preoccupied with
the 7th RISC-V workshop at the end of the month.

Once this stuff is all in, loader should handle any GELI volumes it
finds, and it should Just Work once boot1 is gone.
___
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: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d

[Chris H]

On Tue, 20 Feb 2018 12:39:53 +0100  said


On Mon, 19 Feb 2018 14:18:15 -0800
"Chris H"  wrote:

> I'm seeing a number of messages like the following:
> kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d
> 
> and was wondering if it's anything to be concerned with, or whether

> fsck(8) is fixing them.
> This began to happen when the power went out on a new install:
> FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59 PST
> 2017
> root@dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64
> which hadn't yet been hooked up to the UPS.
> I performed an fsck in single user mode upon power-up. Which ended with the
> mount points being masked CLEAN. I was asked if I wanted to use the JOURNAL.
> I answered Y.
> FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thusly:
> newfs -U -j
> 
> Thank you for all your time, and consideration.
> 


fsck fixes these errors only when the user does NOT use the journal.
You should re-do the fsck.

This doesn't seem quite right. That is; fsck(8) /should/ fix it when soft 
journaling
is enabled. Otherwise the -j option, to newfs(8) and journaling have no value.
OTOH you are indeed correct in that "falling through" will correct any errors. I
used that option after submitting this question. But there /does/ appear to be a
regression. As this has never been the case in earlier versions of FreeBSD. fe;
imposing the same conditions on an 11, or 9.3 system does NOT exhibit this 
problem.
I literally pulled the plug on 2 systems (1 @11, and 1 @9.3) and fsck(8) using
the journal happily fixed the errors, without any latter fallout as described in
this message.

Thank you very much Gary, for taking the time to reply!

--Chris


--
Gary Jennejohn



___
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: ACPI panic on boot with new Lua loader and other minor issues

[Kyle Evans]

On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor  wrote:
> [... snip ...]
>
> Moreover, the "boot [kernel]" loader command does not work:
>
> OK ls /boot/kernel.old/kernel
> /boot/kernel.old/kernel
> OK boot kernel.old
> Command failed
> OK boot /boot/kernel.old/kernel
> Command failed
> OK boot kernel
> Command failed
>
> On the other hand, just "boot" works.
>

This part should work as expected as of r329674, so please give that a
shot. I'm still trying to see if I can reproduce your box drawing
problem.

Thanks,

Kyle Evans
___
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: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

[Mateusz Guzik]

Committed in https://svnweb.freebsd.org/base?view=revision=329660

thanks for reporting

On Tue, Feb 20, 2018 at 6:06 PM, Mateusz Guzik  wrote:

> I missed a consumer, try this:
>
> diff --git a/sys/kern/sys_procdesc.c b/sys/kern/sys_procdesc.c
> index 5e8928cb1534..174fffc5c666 100644
> --- a/sys/kern/sys_procdesc.c
> +++ b/sys/kern/sys_procdesc.c
> @@ -398,7 +398,6 @@ procdesc_close(struct file *fp, struct thread *td)
>  * process's reference to the process descriptor
> when it
>  * calls back into procdesc_reap().
>  */
> -   PROC_SLOCK(p);
> proc_reap(curthread, p, NULL, 0);
> } else {
> /*
>
>
> On Tue, Feb 20, 2018 at 5:50 PM, Juan Ramón Molina Menor 
> wrote:
>
>> I committed the fix in
>>> https://svnweb.freebsd.org/base?view=revision=329542
>>>
>>> i.e. should be stable from this point on.
>>>
>>
>> Hi!
>>
>> It is maybe unrelated, but recent commits have broken my system with a
>> similar error. I did not have panics with a system built around December,
>> but since updating first to r329555 then today to r329641 I’m getting a
>> reproducible panic when logging out from a Lumina desktop session:
>>
>> Unread portion of the kernel message buffer:
>> spin lock 0xf8000d440020 (process slock) held by 0xf8000daed560
>> (tid 100111) too long
>> panic: spin lock held too long
>> cpuid = 1
>> time = 1519143505
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfe5c15e0
>> vpanic() at vpanic+0x18d/frame 0xfe5c1640
>> panic() at panic+0x43/frame 0xfe5c16a0
>> _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame
>> 0xfe5c16b0
>> mtx_spin_wait_unlocked() at mtx_spin_wait_unlocked+0x59/frame
>> 0xfe5c16e0
>> proc_reap() at proc_reap+0x24/frame 0xfe5c1720
>> procdesc_close() at procdesc_close+0x125/frame 0xfe5c1760
>> closef() at closef+0x251/frame 0xfe5c17f0
>> fdescfree_fds() at fdescfree_fds+0x90/frame 0xfe5c1840
>> fdescfree() at fdescfree+0x4df/frame 0xfe5c1900
>> exit1() at exit1+0x508/frame 0xfe5c1970
>> sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe5c1980
>> amd64_syscall() at amd64_syscall+0xa48/frame 0xfe5c1ab0
>> fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffea90
>> Uptime: 17m45s
>> Dumping 327 out of 3990 MB:..5%..15%..25%..35%..44%..5
>> 4%..64%..74%..84%..93%
>>
>> Reading symbols from /boot/kernel/linux.ko...done.
>> Loaded symbols for /boot/kernel/linux.ko
>> Reading symbols from /boot/kernel/linux_common.ko...done.
>> Loaded symbols for /boot/kernel/linux_common.ko
>> Reading symbols from /boot/kernel/acpi_ibm.ko...done.
>> Loaded symbols for /boot/kernel/acpi_ibm.ko
>> Reading symbols from /boot/kernel/iwm7260fw.ko...done.
>> Loaded symbols for /boot/kernel/iwm7260fw.ko
>> Reading symbols from /boot/kernel/coretemp.ko...done.
>> Loaded symbols for /boot/kernel/coretemp.ko
>> Reading symbols from /boot/kernel/if_iwm.ko...done.
>> Loaded symbols for /boot/kernel/if_iwm.ko
>> Reading symbols from /boot/kernel/acpi_video.ko...done.
>> Loaded symbols for /boot/kernel/acpi_video.ko
>> Reading symbols from /boot/kernel/nullfs.ko...done.
>> Loaded symbols for /boot/kernel/nullfs.ko
>> Reading symbols from /boot/kernel/fdescfs.ko...done.
>> Loaded symbols for /boot/kernel/fdescfs.ko
>> Reading symbols from /boot/kernel/i915kms.ko...done.
>> Loaded symbols for /boot/kernel/i915kms.ko
>> Reading symbols from /boot/kernel/drm2.ko...done.
>> Loaded symbols for /boot/kernel/drm2.ko
>> Reading symbols from /boot/kernel/iicbus.ko...done.
>> Loaded symbols for /boot/kernel/iicbus.ko
>> Reading symbols from /boot/kernel/iic.ko...done.
>> Loaded symbols for /boot/kernel/iic.ko
>> Reading symbols from /boot/kernel/iicbb.ko...done.
>> Loaded symbols for /boot/kernel/iicbb.ko
>> #0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324
>> 1324CPU_SET_ATOMIC(cpu, _cpus);
>> (kgdb) bt
>> #0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324
>> #1  0x80e29fb4 in ipi_nmi_handler () at
>> /usr/src/sys/x86/x86/mp_x86.c:1280
>> #2  0x80d09a79 in trap (frame=0x8158bef0)
>> at /usr/src/sys/amd64/amd64/trap.c:188
>> #3  0x80cec054 in nmi_calltrap () at
>> /usr/src/sys/amd64/amd64/exception.S:633
>> #4  0x80e1aaef in acpi_cpu_idle_mwait (mwait_hint=0) at
>> cpufunc.h:611
>> Previous frame inner to this frame (corrupt stack?)
>> Current language:  auto; currently minimal
>>
>> kgdb is over my head, but I can provide more details under some guidance.
>>
>> Hope it helps,
>> Juan
>>
>>
>
>
> --
> Mateusz Guzik 
>



-- 
Mateusz Guzik 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To 

Re: pkg does not recognize correct kernel version

[Conrad Meyer]

On Mon, Feb 19, 2018 at 2:38 PM, Ronald Klop  wrote:
> On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov
>  wrote:
>
>> Look at the man page.  pkg reads version from the /bin/sh ELF FreeBSD
>
>
> Which man page? I can't find it in pkg help update or pkg help upgrade or
> man pkg.

I had to dig for quite a while to find a reference (pkg.conf(5)):

 ABI: string  The ABI of the package you want to install.  Default:
  derived from the ABI of the /bin/sh binary.

>> version note:
>> orion% file /bin/ls
>> /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
>> dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1
>> (1101506), FreeBSD-style, stripped
>>
>> Update world past the __FreeBSD_version which is reported for the
>> repository.
>
>
> Does this mean I always have to do a *clean* buildworld after every version
> bump? This takes ages.

You could also do a -DNO_CLEAN buildworld.

Or you can continue to override with "-o OSVERSION=foo", although that
may eventually result in broken packages.  In general the OSVERSION is
bumped conservatively (more often than will actually result in
breakage), so you can get away with the easy workaround for a while
between buildworlds.

Best,
Conrad
___
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: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

[Konstantin Belousov]

On Tue, Feb 20, 2018 at 05:50:57PM +0100, Juan Ram?n Molina Menor wrote:
> > I committed the fix in
> > https://svnweb.freebsd.org/base?view=revision=329542
> >
> > i.e. should be stable from this point on.
> 
> Hi!
> 
> It is maybe unrelated, but recent commits have broken my system with a 
> similar error. I did not have panics with a system built around 
> December, but since updating first to r329555 then today to r329641 I?m 
> getting a reproducible panic when logging out from a Lumina desktop session:
> 
> Unread portion of the kernel message buffer:
> spin lock 0xf8000d440020 (process slock) held by 0xf8000daed560 
> (tid 100111) too long
> panic: spin lock held too long
> cpuid = 1
> time = 1519143505
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
> 0xfe5c15e0
> vpanic() at vpanic+0x18d/frame 0xfe5c1640
> panic() at panic+0x43/frame 0xfe5c16a0
> _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame 
> 0xfe5c16b0
> mtx_spin_wait_unlocked() at mtx_spin_wait_unlocked+0x59/frame 
> 0xfe5c16e0
> proc_reap() at proc_reap+0x24/frame 0xfe5c1720
> procdesc_close() at procdesc_close+0x125/frame 0xfe5c1760
> closef() at closef+0x251/frame 0xfe5c17f0
> fdescfree_fds() at fdescfree_fds+0x90/frame 0xfe5c1840
> fdescfree() at fdescfree+0x4df/frame 0xfe5c1900
> exit1() at exit1+0x508/frame 0xfe5c1970
> sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe5c1980
> amd64_syscall() at amd64_syscall+0xa48/frame 0xfe5c1ab0
> fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffea90
> Uptime: 17m45s
> Dumping 327 out of 3990 MB:..5%..15%..25%..35%..44%..54%..64%..74%..84%..93%
> 
> Reading symbols from /boot/kernel/linux.ko...done.
> Loaded symbols for /boot/kernel/linux.ko
> Reading symbols from /boot/kernel/linux_common.ko...done.
> Loaded symbols for /boot/kernel/linux_common.ko
> Reading symbols from /boot/kernel/acpi_ibm.ko...done.
> Loaded symbols for /boot/kernel/acpi_ibm.ko
> Reading symbols from /boot/kernel/iwm7260fw.ko...done.
> Loaded symbols for /boot/kernel/iwm7260fw.ko
> Reading symbols from /boot/kernel/coretemp.ko...done.
> Loaded symbols for /boot/kernel/coretemp.ko
> Reading symbols from /boot/kernel/if_iwm.ko...done.
> Loaded symbols for /boot/kernel/if_iwm.ko
> Reading symbols from /boot/kernel/acpi_video.ko...done.
> Loaded symbols for /boot/kernel/acpi_video.ko
> Reading symbols from /boot/kernel/nullfs.ko...done.
> Loaded symbols for /boot/kernel/nullfs.ko
> Reading symbols from /boot/kernel/fdescfs.ko...done.
> Loaded symbols for /boot/kernel/fdescfs.ko
> Reading symbols from /boot/kernel/i915kms.ko...done.
> Loaded symbols for /boot/kernel/i915kms.ko
> Reading symbols from /boot/kernel/drm2.ko...done.
> Loaded symbols for /boot/kernel/drm2.ko
> Reading symbols from /boot/kernel/iicbus.ko...done.
> Loaded symbols for /boot/kernel/iicbus.ko
> Reading symbols from /boot/kernel/iic.ko...done.
> Loaded symbols for /boot/kernel/iic.ko
> Reading symbols from /boot/kernel/iicbb.ko...done.
> Loaded symbols for /boot/kernel/iicbb.ko
> #0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324
> 1324    CPU_SET_ATOMIC(cpu, _cpus);
> (kgdb) bt
> #0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324
> #1  0x80e29fb4 in ipi_nmi_handler () at 
> /usr/src/sys/x86/x86/mp_x86.c:1280
> #2  0x80d09a79 in trap (frame=0x8158bef0)
>      at /usr/src/sys/amd64/amd64/trap.c:188
> #3  0x80cec054 in nmi_calltrap () at 
> /usr/src/sys/amd64/amd64/exception.S:633
> #4  0x80e1aaef in acpi_cpu_idle_mwait (mwait_hint=0) at 
> cpufunc.h:611
> Previous frame inner to this frame (corrupt stack?)
> Current language:  auto; currently minimal
> 
> kgdb is over my head, but I can provide more details under some guidance.

Use this.

diff --git a/sys/kern/sys_procdesc.c b/sys/kern/sys_procdesc.c
index 5e8928cb153..174fffc5c66 100644
--- a/sys/kern/sys_procdesc.c
+++ b/sys/kern/sys_procdesc.c
@@ -398,7 +398,6 @@ procdesc_close(struct file *fp, struct thread *td)
 * process's reference to the process descriptor when it
 * calls back into procdesc_reap().
 */
-   PROC_SLOCK(p);
proc_reap(curthread, p, NULL, 0);
} else {
/*
___
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: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

[Mateusz Guzik]

I missed a consumer, try this:

diff --git a/sys/kern/sys_procdesc.c b/sys/kern/sys_procdesc.c
index 5e8928cb1534..174fffc5c666 100644
--- a/sys/kern/sys_procdesc.c
+++ b/sys/kern/sys_procdesc.c
@@ -398,7 +398,6 @@ procdesc_close(struct file *fp, struct thread *td)
 * process's reference to the process descriptor
when it
 * calls back into procdesc_reap().
 */
-   PROC_SLOCK(p);
proc_reap(curthread, p, NULL, 0);
} else {
/*


On Tue, Feb 20, 2018 at 5:50 PM, Juan Ramón Molina Menor 
wrote:

> I committed the fix in
>> https://svnweb.freebsd.org/base?view=revision=329542
>>
>> i.e. should be stable from this point on.
>>
>
> Hi!
>
> It is maybe unrelated, but recent commits have broken my system with a
> similar error. I did not have panics with a system built around December,
> but since updating first to r329555 then today to r329641 I’m getting a
> reproducible panic when logging out from a Lumina desktop session:
>
> Unread portion of the kernel message buffer:
> spin lock 0xf8000d440020 (process slock) held by 0xf8000daed560
> (tid 100111) too long
> panic: spin lock held too long
> cpuid = 1
> time = 1519143505
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe5c15e0
> vpanic() at vpanic+0x18d/frame 0xfe5c1640
> panic() at panic+0x43/frame 0xfe5c16a0
> _mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame
> 0xfe5c16b0
> mtx_spin_wait_unlocked() at mtx_spin_wait_unlocked+0x59/frame
> 0xfe5c16e0
> proc_reap() at proc_reap+0x24/frame 0xfe5c1720
> procdesc_close() at procdesc_close+0x125/frame 0xfe5c1760
> closef() at closef+0x251/frame 0xfe5c17f0
> fdescfree_fds() at fdescfree_fds+0x90/frame 0xfe5c1840
> fdescfree() at fdescfree+0x4df/frame 0xfe5c1900
> exit1() at exit1+0x508/frame 0xfe5c1970
> sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe5c1980
> amd64_syscall() at amd64_syscall+0xa48/frame 0xfe5c1ab0
> fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffea90
> Uptime: 17m45s
> Dumping 327 out of 3990 MB:..5%..15%..25%..35%..44%..5
> 4%..64%..74%..84%..93%
>
> Reading symbols from /boot/kernel/linux.ko...done.
> Loaded symbols for /boot/kernel/linux.ko
> Reading symbols from /boot/kernel/linux_common.ko...done.
> Loaded symbols for /boot/kernel/linux_common.ko
> Reading symbols from /boot/kernel/acpi_ibm.ko...done.
> Loaded symbols for /boot/kernel/acpi_ibm.ko
> Reading symbols from /boot/kernel/iwm7260fw.ko...done.
> Loaded symbols for /boot/kernel/iwm7260fw.ko
> Reading symbols from /boot/kernel/coretemp.ko...done.
> Loaded symbols for /boot/kernel/coretemp.ko
> Reading symbols from /boot/kernel/if_iwm.ko...done.
> Loaded symbols for /boot/kernel/if_iwm.ko
> Reading symbols from /boot/kernel/acpi_video.ko...done.
> Loaded symbols for /boot/kernel/acpi_video.ko
> Reading symbols from /boot/kernel/nullfs.ko...done.
> Loaded symbols for /boot/kernel/nullfs.ko
> Reading symbols from /boot/kernel/fdescfs.ko...done.
> Loaded symbols for /boot/kernel/fdescfs.ko
> Reading symbols from /boot/kernel/i915kms.ko...done.
> Loaded symbols for /boot/kernel/i915kms.ko
> Reading symbols from /boot/kernel/drm2.ko...done.
> Loaded symbols for /boot/kernel/drm2.ko
> Reading symbols from /boot/kernel/iicbus.ko...done.
> Loaded symbols for /boot/kernel/iicbus.ko
> Reading symbols from /boot/kernel/iic.ko...done.
> Loaded symbols for /boot/kernel/iic.ko
> Reading symbols from /boot/kernel/iicbb.ko...done.
> Loaded symbols for /boot/kernel/iicbb.ko
> #0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324
> 1324CPU_SET_ATOMIC(cpu, _cpus);
> (kgdb) bt
> #0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324
> #1  0x80e29fb4 in ipi_nmi_handler () at
> /usr/src/sys/x86/x86/mp_x86.c:1280
> #2  0x80d09a79 in trap (frame=0x8158bef0)
> at /usr/src/sys/amd64/amd64/trap.c:188
> #3  0x80cec054 in nmi_calltrap () at /usr/src/sys/amd64/amd64/excep
> tion.S:633
> #4  0x80e1aaef in acpi_cpu_idle_mwait (mwait_hint=0) at
> cpufunc.h:611
> Previous frame inner to this frame (corrupt stack?)
> Current language:  auto; currently minimal
>
> kgdb is over my head, but I can provide more details under some guidance.
>
> Hope it helps,
> Juan
>
>


-- 
Mateusz Guzik 
___
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: amd64 head -r329465 (non-debug build, but with symbols): "panic: spin lock held too long" during make check-old, reported during a sys_vfork

[Juan Ramón Molina Menor]

I committed the fix in
https://svnweb.freebsd.org/base?view=revision=329542

i.e. should be stable from this point on.


Hi!

It is maybe unrelated, but recent commits have broken my system with a 
similar error. I did not have panics with a system built around 
December, but since updating first to r329555 then today to r329641 I’m 
getting a reproducible panic when logging out from a Lumina desktop session:


Unread portion of the kernel message buffer:
spin lock 0xf8000d440020 (process slock) held by 0xf8000daed560 
(tid 100111) too long

panic: spin lock held too long
cpuid = 1
time = 1519143505
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe5c15e0

vpanic() at vpanic+0x18d/frame 0xfe5c1640
panic() at panic+0x43/frame 0xfe5c16a0
_mtx_lock_indefinite_check() at _mtx_lock_indefinite_check+0x71/frame 
0xfe5c16b0
mtx_spin_wait_unlocked() at mtx_spin_wait_unlocked+0x59/frame 
0xfe5c16e0

proc_reap() at proc_reap+0x24/frame 0xfe5c1720
procdesc_close() at procdesc_close+0x125/frame 0xfe5c1760
closef() at closef+0x251/frame 0xfe5c17f0
fdescfree_fds() at fdescfree_fds+0x90/frame 0xfe5c1840
fdescfree() at fdescfree+0x4df/frame 0xfe5c1900
exit1() at exit1+0x508/frame 0xfe5c1970
sys_sys_exit() at sys_sys_exit+0xd/frame 0xfe5c1980
amd64_syscall() at amd64_syscall+0xa48/frame 0xfe5c1ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffea90
Uptime: 17m45s
Dumping 327 out of 3990 MB:..5%..15%..25%..35%..44%..54%..64%..74%..84%..93%

Reading symbols from /boot/kernel/linux.ko...done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/linux_common.ko...done.
Loaded symbols for /boot/kernel/linux_common.ko
Reading symbols from /boot/kernel/acpi_ibm.ko...done.
Loaded symbols for /boot/kernel/acpi_ibm.ko
Reading symbols from /boot/kernel/iwm7260fw.ko...done.
Loaded symbols for /boot/kernel/iwm7260fw.ko
Reading symbols from /boot/kernel/coretemp.ko...done.
Loaded symbols for /boot/kernel/coretemp.ko
Reading symbols from /boot/kernel/if_iwm.ko...done.
Loaded symbols for /boot/kernel/if_iwm.ko
Reading symbols from /boot/kernel/acpi_video.ko...done.
Loaded symbols for /boot/kernel/acpi_video.ko
Reading symbols from /boot/kernel/nullfs.ko...done.
Loaded symbols for /boot/kernel/nullfs.ko
Reading symbols from /boot/kernel/fdescfs.ko...done.
Loaded symbols for /boot/kernel/fdescfs.ko
Reading symbols from /boot/kernel/i915kms.ko...done.
Loaded symbols for /boot/kernel/i915kms.ko
Reading symbols from /boot/kernel/drm2.ko...done.
Loaded symbols for /boot/kernel/drm2.ko
Reading symbols from /boot/kernel/iicbus.ko...done.
Loaded symbols for /boot/kernel/iicbus.ko
Reading symbols from /boot/kernel/iic.ko...done.
Loaded symbols for /boot/kernel/iic.ko
Reading symbols from /boot/kernel/iicbb.ko...done.
Loaded symbols for /boot/kernel/iicbb.ko
#0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324
1324    CPU_SET_ATOMIC(cpu, _cpus);
(kgdb) bt
#0  cpustop_handler () at /usr/src/sys/x86/x86/mp_x86.c:1324
#1  0x80e29fb4 in ipi_nmi_handler () at 
/usr/src/sys/x86/x86/mp_x86.c:1280

#2  0x80d09a79 in trap (frame=0x8158bef0)
    at /usr/src/sys/amd64/amd64/trap.c:188
#3  0x80cec054 in nmi_calltrap () at 
/usr/src/sys/amd64/amd64/exception.S:633
#4  0x80e1aaef in acpi_cpu_idle_mwait (mwait_hint=0) at 
cpufunc.h:611

Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal

kgdb is over my head, but I can provide more details under some guidance.

Hope it helps,
Juan

___
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: ACPI panic on boot with new Lua loader and other minor issues

[Juan Ramón Molina Menor]

Le 19/02/2018 à 21:21, Kyle Evans a écrit :> Hello!


On Mon, Feb 19, 2018 at 8:21 AM, Juan Ramón Molina Menor  wrote:

I have done a full build of r329555 to test the new Lua boot loader.

Both the new and the old kernels panic after being loaded with:

panic: running without device atpic requires a local APIC

For reasons unknown, ACPI is off, as shown by David Wolfskill in a previous
message:
https://lists.freebsd.org/pipermail/freebsd-current/2018-February/068497.html

OK show hint.acpi.0.disabled
1

Setting ACPI to On resolves the issue.



Hi Kyle.


As David noted, this should actually Just Work (TM) now. Can you break
into a loader prompt with just the forth loader and tell me what "show
hint.acpi.0.rsdp" looks like?

OK show hint.acpi.0.rsdp
Command error

I tested both with hint.acpi.0.disabled= 1 and 0.





Also, I can not stop boot2 to try to use the copy of the Forth loader: the
keyboard only becomes responsive at the loader stage.


Hmm...

In fact, I don’t think this has ever worked here… I’ve found a very old (July 
2016) FreeBSD 12 memstick and neither can I stop the boot2 stage.



There is an error during this stage:

Loading /boot/defaults/loader.conf
Failed to open config: ’/boot/loader.conf.local’


David's diagnosis of this is right- this is more of an informational
message that you don't need to worry about.

Thanks.



Moreover, the "boot [kernel]" loader command does not work:

OK ls /boot/kernel.old/kernel
 /boot/kernel.old/kernel
OK boot kernel.old
Command failed
OK boot /boot/kernel.old/kernel
Command failed
OK boot kernel
Command failed

On the other hand, just "boot" works.


It seems that the Forth loader might be doing something sneaky and
replacing the standard common "boot" with a Forth boot that handles
this a lot better. CC'ing dteske@ so they can confirm.


Finally, the double lines drawing a frame around the loader menu do not work
with the new loader and are replaced by ? characters in a box.


Interesting, I'll look into that... anything interesting/unique about
your setup? r329387 should have addressed one potential cause of this,
but I see you're past that.

I’m using a memory stick to boot a Lenovo ThinkPad S440 (i3-4030U processor, 
4GB RAM). The only thing I can think of is that the ACPI of this model is not 
well supported, but the errors I have are related to thermal zones…:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201678

To build the memstick I’m using a 11.1-RELEASE VM under Hyper-V, with ccache 
and WITH_META_MODE, but this build process has been working nicely for months.

The kernel is based on GENERIC-NODEBUG and has been also working reliably:

juan@Server ~ % cat /root/kernels/MEMSTICK
include GENERIC-NODEBUG

ident   MEMSTICK

nodevicefdc

nodevicech
nodevicesa
nodeviceses

nodeviceamr
nodevicearcmsr
nodeviceciss
nodevicedpt
nodevicehptmv
nodevicehptnr
nodevicehptrr
nodevicehpt27xx
nodeviceiir
nodeviceips
nodevicemly
nodevicetwa
nodevicetws

nodeviceaac
nodeviceaacp
nodeviceaacraid
nodeviceida
nodevicemfi
nodevicemlx
nodevicemrsas
nodevicepmspcv
nodevicetwe

nodevicenvme
nodevicenvd

nodevicevirtio
nodevicevirtio_pci
nodevicevtnet
nodevicevirtio_blk
nodevicevirtio_scsi
nodevicevirtio_balloon

nooptions   HYPERV
nodevicehyperv

nooptions   XENHVM
nodevicexenpci

nodevicevmx


There is maybe something fishy in my src.conf, where I disable a lot of things 
to slim down the memstick, but still, it has been stable till now:

juan@Server ~ % cat /etc/src.conf
# For memory sticks

WITH_CCACHE_BUILD=

WITHOUT_ACCT=
WITHOUT_AMD=
WITHOUT_ATM=
WITHOUT_AUTHPF=
WITHOUT_AUTOFS=
WITHOUT_BHYVE=
WITHOUT_BLACKLIST=
# iwm does not support Bluetooth
WITHOUT_BLUETOOTH=
WITHOUT_BOOTPARAMD=
WITHOUT_BOOTPD=
# WITHOUT_BSDINSTALL enforced by WITHOUT_DIALOG
WITHOUT_BSNMP=
WITHOUT_CALENDAR=
# Don't set this when building HEAD from RELENG
# WITHOUT_CROSS_COMPILER=
WITHOUT_CTM=
WITHOUT_DEBUG_FILES=
#WITHOUT_DIALOG=
WITHOUT_DICT=
WITHOUT_EE=
WITHOUT_EXAMPLES=
WITHOUT_FDT=
WITHOUT_FINGER=
WITHOUT_FLOPPY=
# For testing the Lua loader (WITH_LOADER_LUA)
WITHOUT_FORTH=
WITHOUT_FREEBSD_UPDATE=
WITHOUT_GAMES=
WITHOUT_GCOV=
WITHOUT_GPIO=
# You disable Kerberos later, but try to keep GSSAPI for curl > pkg
# But this does not work, base Kerberos is required
#WITH_GSSAPI=
WITHOUT_GSSAPI=
WITHOUT_HAST=
WITHOUT_HESIOD=
WITHOUT_HTML=
WITHOUT_HYPERV=
WITHOUT_IPFILTER=
WITHOUT_IPFW=
WITHOUT_ISCSI=
WITHOUT_JAIL=
WITHOUT_KERBEROS=
WITHOUT_KERNEL_SYMBOLS=
WITHOUT_KVM=
WITHOUT_LDNS=
# This disables moused
#WITHOUT_LEGACY_CONSOLE=
WITHOUT_LLDB=
# This requires WITHOUT_FORTH
WITH_LOADER_LUA=
# This breaks setting locale and thus tmux
#WITHOUT_LOCALES=
WITHOUT_LPR=

Re: Recent world+kernel has broken Linux 3D apps?

[Johannes Lundberg]

On Tue, Feb 20, 2018 at 1:39 PM, Hans Petter Selasky 
wrote:

> On 02/20/18 14:03, Johannes Lundberg wrote:
>
>> On Tue, Feb 20, 2018 at 12:57 PM, Hans Petter Selasky 
>> wrote:
>>
>> On 02/20/18 12:39, Johannes Lundberg wrote:
>>>
>>> Before rebuilding world my system was running Linux games fine with a
 couple of months old world/kernel and drm-next-kmod.

 Since updating world+kernel last week all Linux 3D apps fail (native
 binaries like glxgears and supertuxkart works fine).

 linux-c6/c7, intel/modesetting, does no difference
 This is on Dell Intel Broadwell laptop.

 Doom 3 fail like this:

 - R_ReloadARBPrograms -
 glprogs/test.vfpsignal caught: Segmentation fault
 si_code 1
 Trying to exit gracefully..


 And glxgears (in /compat/linux/usr/bin/)

 johannes@jd2:~ % /compat/linux/usr/bin/glxgears
 Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
 broken.
 Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
 broken.
 Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
 broken.
 Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
 broken.
 Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
 broken.
 libdrm aub dumping is deprecated.

 Use intel_aubdump from intel-gpu-tools instead.  Install
 intel-gpu-tools,
 then run (for example)

   $ intel_aubdump --output=trace.aub glxgears -geometry 500x500

 See the intel_aubdump man page for more details.
 bo_create: buf 1 (swizzle test) 32768b
 bo_unreference final: 1 (swizzle test)
 libGL: Can't open configuration file /home/johannes/.drirc: No such file
 or
 directory.
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 bo_create: buf 1 (transform feedback offsets) 16b
 bo_create: buf 2 (xfb primitive counts) 4096b
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 intelNewTextureObject
 Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
 compression/decompression unavailable
 libGL: Can't open configuration file /home/johannes/.drirc: No such file
 or
 directory.
 bo_create: buf 3 (batchbuffer) 32768b
 drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1
 bo_map: 3 (batchbuffer), map_count=1
 bo_map: 3 (batchbuffer) -> 0x1000
 bo_create: buf 4 (pipe_control workaround) 4096b
 bo_create: buf 5 (program cache) 4096b
 drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1
 bo_map_gtt: mmap 5 (program cache), map_count=1
 intel_bufmgr_gem.c:1461: Error mapping buffer 5 (program cache): Invalid
 argument .
 drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1
 bo_create: buf 6 (shader time) 393216b
 bo_create: buf 7 (bufferobj) 65536b
 enter intel_update_renderbuffers, drawable 0x614b80
 enter intel_update_dri2_buffers, drawable 0x614b80
 attaching buffer 3, at 1, cpp 4, pitch 1536
 bo_create_from_handle: 3 (dri2 back buffer)
 intel_miptree_create_layout target GL_TEXTURE_2D format
 MESA_FORMAT_B8G8R8X8_UNORM level 0..0 slices 1 <-- 0x778210
 intel_miptree_set_level_info level 0, depth 1, offset 0,0
 intel_miptree_set_total_width_height: 300x300x4
 intel_alloc_private_renderbuffer_storage: GL_DEPTH_COMPONENT:
 MESA_FORMAT_Z24_UNORM_X8_UINT (300x300)
 intel_miptree_create_layout target GL_TEXTURE_2D format
 MESA_FORMAT_Z24_UNORM_X8_UINT level 0..0 slices 1 <-- 0x778440
 intel_miptree_set_level_info level 0, depth 1, offset 0,0
 intel_miptree_set_total_width_height: 300x300x4
 bo_create: buf 9 (miptree) 409600b
 bo_create: buf 10 (hiz) 98304b
 mt 0x778440 level 0: HiZ enabled
 intel_alloc_private_renderbuffer_storage: GL_STENCIL_INDEX:
 MESA_FORMAT_S_UINT8 (300x300)
 intel_miptree_create_layout target GL_TEXTURE_2D format
 MESA_FORMAT_S_UINT8
 level 0..0 slices 1 <-- 0x778890
 intel_miptree_set_level_info level 0, depth 1, offset 0,0
 intel_miptree_set_total_width_height: 300x304x1
 bo_create: buf 11 (miptree) 102400b
 Running synchronized to the vertical refresh.  The framerate should be
 approximately the same as the monitor refresh rate.
 bo_create: buf 12 (bufferobj) 32768b
 drm_intel_gem_bo_purge_vma_cache: 

Re: Recent world+kernel has broken Linux 3D apps?

[Hans Petter Selasky]

On 02/20/18 14:03, Johannes Lundberg wrote:

On Tue, Feb 20, 2018 at 12:57 PM, Hans Petter Selasky 
wrote:


On 02/20/18 12:39, Johannes Lundberg wrote:


Before rebuilding world my system was running Linux games fine with a
couple of months old world/kernel and drm-next-kmod.

Since updating world+kernel last week all Linux 3D apps fail (native
binaries like glxgears and supertuxkart works fine).

linux-c6/c7, intel/modesetting, does no difference
This is on Dell Intel Broadwell laptop.

Doom 3 fail like this:

- R_ReloadARBPrograms -
glprogs/test.vfpsignal caught: Segmentation fault
si_code 1
Trying to exit gracefully..


And glxgears (in /compat/linux/usr/bin/)

johannes@jd2:~ % /compat/linux/usr/bin/glxgears
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
libdrm aub dumping is deprecated.

Use intel_aubdump from intel-gpu-tools instead.  Install intel-gpu-tools,
then run (for example)

  $ intel_aubdump --output=trace.aub glxgears -geometry 500x500

See the intel_aubdump man page for more details.
bo_create: buf 1 (swizzle test) 32768b
bo_unreference final: 1 (swizzle test)
libGL: Can't open configuration file /home/johannes/.drirc: No such file
or
directory.
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
bo_create: buf 1 (transform feedback offsets) 16b
bo_create: buf 2 (xfb primitive counts) 4096b
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
libGL: Can't open configuration file /home/johannes/.drirc: No such file
or
directory.
bo_create: buf 3 (batchbuffer) 32768b
drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1
bo_map: 3 (batchbuffer), map_count=1
bo_map: 3 (batchbuffer) -> 0x1000
bo_create: buf 4 (pipe_control workaround) 4096b
bo_create: buf 5 (program cache) 4096b
drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1
bo_map_gtt: mmap 5 (program cache), map_count=1
intel_bufmgr_gem.c:1461: Error mapping buffer 5 (program cache): Invalid
argument .
drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1
bo_create: buf 6 (shader time) 393216b
bo_create: buf 7 (bufferobj) 65536b
enter intel_update_renderbuffers, drawable 0x614b80
enter intel_update_dri2_buffers, drawable 0x614b80
attaching buffer 3, at 1, cpp 4, pitch 1536
bo_create_from_handle: 3 (dri2 back buffer)
intel_miptree_create_layout target GL_TEXTURE_2D format
MESA_FORMAT_B8G8R8X8_UNORM level 0..0 slices 1 <-- 0x778210
intel_miptree_set_level_info level 0, depth 1, offset 0,0
intel_miptree_set_total_width_height: 300x300x4
intel_alloc_private_renderbuffer_storage: GL_DEPTH_COMPONENT:
MESA_FORMAT_Z24_UNORM_X8_UINT (300x300)
intel_miptree_create_layout target GL_TEXTURE_2D format
MESA_FORMAT_Z24_UNORM_X8_UINT level 0..0 slices 1 <-- 0x778440
intel_miptree_set_level_info level 0, depth 1, offset 0,0
intel_miptree_set_total_width_height: 300x300x4
bo_create: buf 9 (miptree) 409600b
bo_create: buf 10 (hiz) 98304b
mt 0x778440 level 0: HiZ enabled
intel_alloc_private_renderbuffer_storage: GL_STENCIL_INDEX:
MESA_FORMAT_S_UINT8 (300x300)
intel_miptree_create_layout target GL_TEXTURE_2D format
MESA_FORMAT_S_UINT8
level 0..0 slices 1 <-- 0x778890
intel_miptree_set_level_info level 0, depth 1, offset 0,0
intel_miptree_set_total_width_height: 300x304x1
bo_create: buf 11 (miptree) 102400b
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
bo_create: buf 12 (bufferobj) 32768b
drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1
bo_map_gtt: mmap 12 (bufferobj), map_count=1
intel_bufmgr_gem.c:1461: Error mapping buffer 12 (bufferobj): Invalid
argument .
drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1


Segmentation fault (core dumped)



Can you compare the debug prints with working version?



I don't have a working system anymore.. Need some time to set one up...
If anyone has, try this

$ setenv INTEL_DEBUG all
$ setenv MESA_DEBUG 1
$ setenv LIBGL_DEBUG 1
$ /compat/linux/usr/bin/glxgears



This patch fixes it for me:


Index: sys/compat/linux/linux_mmap.c
===
--- 

Re: Recent world+kernel has broken Linux 3D apps?

[Johannes Lundberg]

On Tue, Feb 20, 2018 at 12:57 PM, Hans Petter Selasky 
wrote:

> On 02/20/18 12:39, Johannes Lundberg wrote:
>
>> Before rebuilding world my system was running Linux games fine with a
>> couple of months old world/kernel and drm-next-kmod.
>>
>> Since updating world+kernel last week all Linux 3D apps fail (native
>> binaries like glxgears and supertuxkart works fine).
>>
>> linux-c6/c7, intel/modesetting, does no difference
>> This is on Dell Intel Broadwell laptop.
>>
>> Doom 3 fail like this:
>>
>> - R_ReloadARBPrograms -
>> glprogs/test.vfpsignal caught: Segmentation fault
>> si_code 1
>> Trying to exit gracefully..
>>
>>
>> And glxgears (in /compat/linux/usr/bin/)
>>
>> johannes@jd2:~ % /compat/linux/usr/bin/glxgears
>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
>> broken.
>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
>> broken.
>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
>> broken.
>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
>> broken.
>> Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
>> broken.
>> libdrm aub dumping is deprecated.
>>
>> Use intel_aubdump from intel-gpu-tools instead.  Install intel-gpu-tools,
>> then run (for example)
>>
>>  $ intel_aubdump --output=trace.aub glxgears -geometry 500x500
>>
>> See the intel_aubdump man page for more details.
>> bo_create: buf 1 (swizzle test) 32768b
>> bo_unreference final: 1 (swizzle test)
>> libGL: Can't open configuration file /home/johannes/.drirc: No such file
>> or
>> directory.
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> bo_create: buf 1 (transform feedback offsets) 16b
>> bo_create: buf 2 (xfb primitive counts) 4096b
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> intelNewTextureObject
>> Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
>> compression/decompression unavailable
>> libGL: Can't open configuration file /home/johannes/.drirc: No such file
>> or
>> directory.
>> bo_create: buf 3 (batchbuffer) 32768b
>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1
>> bo_map: 3 (batchbuffer), map_count=1
>> bo_map: 3 (batchbuffer) -> 0x1000
>> bo_create: buf 4 (pipe_control workaround) 4096b
>> bo_create: buf 5 (program cache) 4096b
>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1
>> bo_map_gtt: mmap 5 (program cache), map_count=1
>> intel_bufmgr_gem.c:1461: Error mapping buffer 5 (program cache): Invalid
>> argument .
>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1
>> bo_create: buf 6 (shader time) 393216b
>> bo_create: buf 7 (bufferobj) 65536b
>> enter intel_update_renderbuffers, drawable 0x614b80
>> enter intel_update_dri2_buffers, drawable 0x614b80
>> attaching buffer 3, at 1, cpp 4, pitch 1536
>> bo_create_from_handle: 3 (dri2 back buffer)
>> intel_miptree_create_layout target GL_TEXTURE_2D format
>> MESA_FORMAT_B8G8R8X8_UNORM level 0..0 slices 1 <-- 0x778210
>> intel_miptree_set_level_info level 0, depth 1, offset 0,0
>> intel_miptree_set_total_width_height: 300x300x4
>> intel_alloc_private_renderbuffer_storage: GL_DEPTH_COMPONENT:
>> MESA_FORMAT_Z24_UNORM_X8_UINT (300x300)
>> intel_miptree_create_layout target GL_TEXTURE_2D format
>> MESA_FORMAT_Z24_UNORM_X8_UINT level 0..0 slices 1 <-- 0x778440
>> intel_miptree_set_level_info level 0, depth 1, offset 0,0
>> intel_miptree_set_total_width_height: 300x300x4
>> bo_create: buf 9 (miptree) 409600b
>> bo_create: buf 10 (hiz) 98304b
>> mt 0x778440 level 0: HiZ enabled
>> intel_alloc_private_renderbuffer_storage: GL_STENCIL_INDEX:
>> MESA_FORMAT_S_UINT8 (300x300)
>> intel_miptree_create_layout target GL_TEXTURE_2D format
>> MESA_FORMAT_S_UINT8
>> level 0..0 slices 1 <-- 0x778890
>> intel_miptree_set_level_info level 0, depth 1, offset 0,0
>> intel_miptree_set_total_width_height: 300x304x1
>> bo_create: buf 11 (miptree) 102400b
>> Running synchronized to the vertical refresh.  The framerate should be
>> approximately the same as the monitor refresh rate.
>> bo_create: buf 12 (bufferobj) 32768b
>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1
>> bo_map_gtt: mmap 12 (bufferobj), map_count=1
>> intel_bufmgr_gem.c:1461: Error mapping buffer 12 (bufferobj): Invalid
>> argument .
>> drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1
>>
>>
>> Segmentation fault (core dumped)
>>
>
> Can you compare the debug prints with working version?
>
>
I don't have a working system anymore.. Need some 

Re: Recent world+kernel has broken Linux 3D apps?

[Hans Petter Selasky]

On 02/20/18 12:39, Johannes Lundberg wrote:

Before rebuilding world my system was running Linux games fine with a
couple of months old world/kernel and drm-next-kmod.

Since updating world+kernel last week all Linux 3D apps fail (native
binaries like glxgears and supertuxkart works fine).

linux-c6/c7, intel/modesetting, does no difference
This is on Dell Intel Broadwell laptop.

Doom 3 fail like this:

- R_ReloadARBPrograms -
glprogs/test.vfpsignal caught: Segmentation fault
si_code 1
Trying to exit gracefully..


And glxgears (in /compat/linux/usr/bin/)

johannes@jd2:~ % /compat/linux/usr/bin/glxgears
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
libdrm aub dumping is deprecated.

Use intel_aubdump from intel-gpu-tools instead.  Install intel-gpu-tools,
then run (for example)

 $ intel_aubdump --output=trace.aub glxgears -geometry 500x500

See the intel_aubdump man page for more details.
bo_create: buf 1 (swizzle test) 32768b
bo_unreference final: 1 (swizzle test)
libGL: Can't open configuration file /home/johannes/.drirc: No such file or
directory.
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
bo_create: buf 1 (transform feedback offsets) 16b
bo_create: buf 2 (xfb primitive counts) 4096b
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
libGL: Can't open configuration file /home/johannes/.drirc: No such file or
directory.
bo_create: buf 3 (batchbuffer) 32768b
drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1
bo_map: 3 (batchbuffer), map_count=1
bo_map: 3 (batchbuffer) -> 0x1000
bo_create: buf 4 (pipe_control workaround) 4096b
bo_create: buf 5 (program cache) 4096b
drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1
bo_map_gtt: mmap 5 (program cache), map_count=1
intel_bufmgr_gem.c:1461: Error mapping buffer 5 (program cache): Invalid
argument .
drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1
bo_create: buf 6 (shader time) 393216b
bo_create: buf 7 (bufferobj) 65536b
enter intel_update_renderbuffers, drawable 0x614b80
enter intel_update_dri2_buffers, drawable 0x614b80
attaching buffer 3, at 1, cpp 4, pitch 1536
bo_create_from_handle: 3 (dri2 back buffer)
intel_miptree_create_layout target GL_TEXTURE_2D format
MESA_FORMAT_B8G8R8X8_UNORM level 0..0 slices 1 <-- 0x778210
intel_miptree_set_level_info level 0, depth 1, offset 0,0
intel_miptree_set_total_width_height: 300x300x4
intel_alloc_private_renderbuffer_storage: GL_DEPTH_COMPONENT:
MESA_FORMAT_Z24_UNORM_X8_UINT (300x300)
intel_miptree_create_layout target GL_TEXTURE_2D format
MESA_FORMAT_Z24_UNORM_X8_UINT level 0..0 slices 1 <-- 0x778440
intel_miptree_set_level_info level 0, depth 1, offset 0,0
intel_miptree_set_total_width_height: 300x300x4
bo_create: buf 9 (miptree) 409600b
bo_create: buf 10 (hiz) 98304b
mt 0x778440 level 0: HiZ enabled
intel_alloc_private_renderbuffer_storage: GL_STENCIL_INDEX:
MESA_FORMAT_S_UINT8 (300x300)
intel_miptree_create_layout target GL_TEXTURE_2D format MESA_FORMAT_S_UINT8
level 0..0 slices 1 <-- 0x778890
intel_miptree_set_level_info level 0, depth 1, offset 0,0
intel_miptree_set_total_width_height: 300x304x1
bo_create: buf 11 (miptree) 102400b
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
bo_create: buf 12 (bufferobj) 32768b
drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1
bo_map_gtt: mmap 12 (bufferobj), map_count=1
intel_bufmgr_gem.c:1461: Error mapping buffer 12 (bufferobj): Invalid
argument .
drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1


Segmentation fault (core dumped)


Can you compare the debug prints with working version?

--HPS

___
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"

Recent world+kernel has broken Linux 3D apps?

[Johannes Lundberg]

Before rebuilding world my system was running Linux games fine with a
couple of months old world/kernel and drm-next-kmod.

Since updating world+kernel last week all Linux 3D apps fail (native
binaries like glxgears and supertuxkart works fine).

linux-c6/c7, intel/modesetting, does no difference
This is on Dell Intel Broadwell laptop.

Doom 3 fail like this:

- R_ReloadARBPrograms -
glprogs/test.vfpsignal caught: Segmentation fault
si_code 1
Trying to exit gracefully..


And glxgears (in /compat/linux/usr/bin/)

johannes@jd2:~ % /compat/linux/usr/bin/glxgears
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
Couldn't dlopen libudev.so.1 or libudev.so.0, driver detection may be
broken.
libdrm aub dumping is deprecated.

Use intel_aubdump from intel-gpu-tools instead.  Install intel-gpu-tools,
then run (for example)

$ intel_aubdump --output=trace.aub glxgears -geometry 500x500

See the intel_aubdump man page for more details.
bo_create: buf 1 (swizzle test) 32768b
bo_unreference final: 1 (swizzle test)
libGL: Can't open configuration file /home/johannes/.drirc: No such file or
directory.
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
bo_create: buf 1 (transform feedback offsets) 16b
bo_create: buf 2 (xfb primitive counts) 4096b
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
intelNewTextureObject
Mesa warning: couldn't open libtxc_dxtn.so, software DXTn
compression/decompression unavailable
libGL: Can't open configuration file /home/johannes/.drirc: No such file or
directory.
bo_create: buf 3 (batchbuffer) 32768b
drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1
bo_map: 3 (batchbuffer), map_count=1
bo_map: 3 (batchbuffer) -> 0x1000
bo_create: buf 4 (pipe_control workaround) 4096b
bo_create: buf 5 (program cache) 4096b
drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1
bo_map_gtt: mmap 5 (program cache), map_count=1
intel_bufmgr_gem.c:1461: Error mapping buffer 5 (program cache): Invalid
argument .
drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1
bo_create: buf 6 (shader time) 393216b
bo_create: buf 7 (bufferobj) 65536b
enter intel_update_renderbuffers, drawable 0x614b80
enter intel_update_dri2_buffers, drawable 0x614b80
attaching buffer 3, at 1, cpp 4, pitch 1536
bo_create_from_handle: 3 (dri2 back buffer)
intel_miptree_create_layout target GL_TEXTURE_2D format
MESA_FORMAT_B8G8R8X8_UNORM level 0..0 slices 1 <-- 0x778210
intel_miptree_set_level_info level 0, depth 1, offset 0,0
intel_miptree_set_total_width_height: 300x300x4
intel_alloc_private_renderbuffer_storage: GL_DEPTH_COMPONENT:
MESA_FORMAT_Z24_UNORM_X8_UINT (300x300)
intel_miptree_create_layout target GL_TEXTURE_2D format
MESA_FORMAT_Z24_UNORM_X8_UINT level 0..0 slices 1 <-- 0x778440
intel_miptree_set_level_info level 0, depth 1, offset 0,0
intel_miptree_set_total_width_height: 300x300x4
bo_create: buf 9 (miptree) 409600b
bo_create: buf 10 (hiz) 98304b
mt 0x778440 level 0: HiZ enabled
intel_alloc_private_renderbuffer_storage: GL_STENCIL_INDEX:
MESA_FORMAT_S_UINT8 (300x300)
intel_miptree_create_layout target GL_TEXTURE_2D format MESA_FORMAT_S_UINT8
level 0..0 slices 1 <-- 0x778890
intel_miptree_set_level_info level 0, depth 1, offset 0,0
intel_miptree_set_total_width_height: 300x304x1
bo_create: buf 11 (miptree) 102400b
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
bo_create: buf 12 (bufferobj) 32768b
drm_intel_gem_bo_purge_vma_cache: cached=0, open=2, limit=-1
bo_map_gtt: mmap 12 (bufferobj), map_count=1
intel_bufmgr_gem.c:1461: Error mapping buffer 12 (bufferobj): Invalid
argument .
drm_intel_gem_bo_purge_vma_cache: cached=0, open=1, limit=-1


Segmentation fault (core dumped)
___
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: kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d

[Gary Jennejohn]

On Mon, 19 Feb 2018 14:18:15 -0800
"Chris H"  wrote:

> I'm seeing a number of messages like the following:
> kernel: failed: cg 5, cgp: 0xd11ecd0d != bp: 0x63d3ff1d
> 
> and was wondering if it's anything to be concerned with, or whether
> fsck(8) is fixing them.
> This began to happen when the power went out on a new install:
> FreeBSD dns0 12.0-CURRENT FreeBSD 12.0-CURRENT #0: Wed Dec 13 06:07:59 PST 
> 2017
> root@dns0:/usr/obj/usr/src/amd64.amd64/sys/DNS0 amd64
> which hadn't yet been hooked up to the UPS.
> I performed an fsck in single user mode upon power-up. Which ended with the
> mount points being masked CLEAN. I was asked if I wanted to use the JOURNAL.
> I answered Y.
> FWIW the systems are UFS2 (ffs) have gpart labels, and were newfs'd thusly:
> newfs -U -j
> 
> Thank you for all your time, and consideration.
> 

fsck fixes these errors only when the user does NOT use the journal.
You should re-do the fsck.

-- 
Gary Jennejohn
___
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: pkg does not recognize correct kernel version

[Trond Endrestøl]

On Mon, 19 Feb 2018 23:38+0100, Ronald Klop wrote:

> Does this mean I always have to do a *clean* buildworld after every version
> bump? This takes ages.

Yes, I've come to the conclusion that whenever __FreeBSD_version in 
sys/sys/param.h is incremented, then it's time to blow away /usr/obj, 
recreate everything to ensure the correct value of osversion in the 
.note.tag section of each executable, and reinstall base prior to 
updating localbase. See PR 225104 for more details, 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225104.

-- 
Trond.
___
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"

[panic][bhyve] mtx_lock_spin: recursed on non-recursive mutex vcpu lock @ /usr/src/sys/amd64/vmm/vmm.c:2246

[Dave Cottlehuber]

# info

- 100% reproducible on starting a bhyve-based vm
- recent current r329611, also panics at r329531
- GENERIC + WITH_CTF=1 and DEBUG=-g
- built WITH_META_MODE=yes & CCACHE_BUILD=yes

# panic dmesg

[36984] panic: mtx_lock_spin: recursed on non-recursive mutex vcpu lock @ 
/usr/src/sys/amd64/vmm/vmm.c:2246
[36984] 
[36984] cpuid = 3
[36984] time = 1519121280
[36984] KDB: stack backtrace:
[36984] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
0xfe020c272360
[36984] vpanic() at vpanic+0x18d/frame 0xfe020c2723c0
[36984] vpanic() at vpanic/frame 0xfe020c272440
[36984] __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0x148/frame 
0xfe020c272480
[36984] vcpu_get_state() at vcpu_get_state+0x44/frame 0xfe020c2724c0
[36984] vmx_pending_intr() at vmx_pending_intr+0xc6/frame 0xfe020c272500
[36984] vm_run() at vm_run+0x759/frame 0xfe020c272600
[36984] vmmdev_ioctl() at vmmdev_ioctl+0x86b/frame 0xfe020c2726a0
[36984] devfs_ioctl() at devfs_ioctl+0xcb/frame 0xfe020c2726f0
[36984] VOP_IOCTL_APV() at VOP_IOCTL_APV+0xd9/frame 0xfe020c272720
[36984] vn_ioctl() at vn_ioctl+0x124/frame 0xfe020c272830
[36984] devfs_ioctl_f() at devfs_ioctl_f+0x1f/frame 0xfe020c272850
[36984] kern_ioctl() at kern_ioctl+0x2b9/frame 0xfe020c2728b0
[36984] sys_ioctl() at sys_ioctl+0x15c/frame 0xfe020c272980
[36984] amd64_syscall() at amd64_syscall+0x79b/frame 0xfe020c272ab0
[36984] fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffdddecee0
[36984] KDB: enter: panic

# debugger

db:0:kdb.enter.panic>  run lockinfo
db:1:lockinfo> show locks
db:1:locks>  show alllocks
db:1:alllocks>  show lockedvnods
Locked vnodes
db:0:kdb.enter.panic>  show pcpu
cpuid= 3
dynamic pcpu = 0xfe0084b95800
curthread= 0xf8017ad76560: pid 12951 tid 103324 "vcpu 0"
curpcb   = 0xfe020c272b80
fpcurthread  = none
idlethread   = 0xf8010764f560: tid 16 "idle: cpu3"
curpmap  = 0xf80dbaba5130
tssp = 0x81d8bfd8
commontssp   = 0x81d8bfd8
rsp0 = 0xfe020c272b80
gs32p= 0x81d92c10
ldt  = 0x81d92c50
tss  = 0x81d92c40
curvnet  = 0
spin locks held:
db:0:kdb.enter.panic>  bt
Tracing pid 12951 tid 103324 td 0xf8017ad76560
kdb_enter() at kdb_enter+0x3b/frame 0xfe020c272360
vpanic() at vpanic+0x1aa/frame 0xfe020c2723c0
vpanic() at vpanic/frame 0xfe020c272440
__mtx_lock_spin_flags() at __mtx_lock_spin_flags+0x148/frame 0xfe020c272480
vcpu_get_state() at vcpu_get_state+0x44/frame 0xfe020c2724c0
vmx_pending_intr() at vmx_pending_intr+0xc6/frame 0xfe020c272500
vm_run() at vm_run+0x759/frame 0xfe020c272600
vmmdev_ioctl() at vmmdev_ioctl+0x86b/frame 0xfe020c2726a0
devfs_ioctl() at devfs_ioctl+0xcb/frame 0xfe020c2726f0
VOP_IOCTL_APV() at VOP_IOCTL_APV+0xd9/frame 0xfe020c272720
vn_ioctl() at vn_ioctl+0x124/frame 0xfe020c272830
devfs_ioctl_f() at devfs_ioctl_f+0x1f/frame 0xfe020c272850
kern_ioctl() at kern_ioctl+0x2b9/frame 0xfe020c2728b0
sys_ioctl() at sys_ioctl+0x15c/frame 0xfe020c272980
amd64_syscall() at amd64_syscall+0x79b/frame 0xfe020c272ab0
fast_syscall_common() at fast_syscall_common+0x101/frame 0x7fffdddecee0
db:0:kdb.enter.panic>  ps
  pid  ppid  pgrp   uid  state   wmesg   wchan   cmd
18384 99134 12632  1002  S+  select  0xf80152b4e9c0  ssh
12951 53776 53776 0  R+  (threaded)  bhyve
101692   S   kqread  0xf81c41243400  mevent
102880   S   uwait   0xf80d4915e500  blk-3:0:0-0
102881   S   uwait   0xf8025b2c5800  blk-3:0:0-1
102982   S   uwait   0xf802d198b680  blk-3:0:0-2
102985   S   uwait   0xf8015fdb6a00  blk-3:0:0-3
102988   S   uwait   0xf80721bbab00  blk-3:0:0-4
102990   S   uwait   0xf806a1161b00  blk-3:0:0-5
102994   S   uwait   0xf8010a0db480  blk-3:0:0-6
103009   S   uwait   0xf80aae76f700  blk-3:0:0-7
103016   S   uwait   0xf8073b79d980  blk-4:0-0
103018   S   uwait   0xf8010a0d8900  blk-4:0-1
103020   S   uwait   0xf80618184780  blk-4:0-2
103022   S   uwait   0xf802d198ba00  blk-4:0-3
103024   S   uwait   0xf807ac4e2800  blk-4:0-4
103320   S   uwait   0xf807ac4e2180  blk-4:0-5
103321   S   uwait   0xf8015fdb5b80  blk-4:0-6
103322   S   uwait   0xf807473e9900  blk-4:0-7
103323   S   uwait   0xf80721c41b80  vtnet-5:0 tx
103324   Run CPU 3   vcpu 0
100505   Run CPU 11  vcpu 1
53776 38209 53776 0  Ss+ wait0xf80d4942da70  sh
38209 1 38209