FreeBSD CURRENT buildworld in virtualbox guest crashes FreeBSD host

2019-09-25 Thread Don Lewis 
Please forgive the crosspost, I don't know where the problem actually
belongs.

For the last several months I've had a problem where doing a buildworld
on FreeBSD CURRENT running as a virtualbox guest is crashing a the
FreeBSD current host.

This doesn't always happen, but there is a pattern.  The host in
question is primarily used for building packages sets with poudriere. If
I do a poudriere run, and after poudriere is finished, I start the
virtual box guest and do a buildworld there, this host will panic,
usually after an hour or so.  After I reboot the host and restart the
guest, the guest's UFS filesystem has some pretty severe damage, which
is not terribly unexpected.  I've never had the host panic under the
same circumstances if this host is freshly booted, though I did
experience a panic this morning during the subsequent installworld.  I'm
guessing that whether the panic happens or not depends on how much the
host memory map has been churned since boot.  According to top, there
are always around 5 GB of free memory when the crash occurs.

As mentioned, the problem has been happening with multiple revisions of
-CURRENT over the last several months, as well as multiple versions of
virtualbox.  This morning's crash happened with:
  FreeBSD zipper.catspoiler.org 13.0-CURRENT FreeBSD 13.0-CURRENT r352198 
GENERIC  amd64
  virtualbox-ose-5.2.32_1General-purpose full virtualizer for x86 
hardware
  virtualbox-ose-kmod-5.2.32_1   VirtualBox kernel module for FreeBSD

The CPU is:
CPU: AMD Ryzen 7 1700X Eight-Core Processor  (3393.72-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x800f11  Family=0x17  Model=0x1  Stepping=1
  Features=0x178bfbff
  Features2=0x7ed8320b
  AMD Features=0x2e500800
  AMD Features2=0x35c233ff
  Structured Extended Features=0x209c01a9
  XSAVE Features=0xf
  AMD Extended Feature Extensions ID EBX=0x1007
  SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
  TSC: P-state invariant, performance statistics

and the machine has 64 GB of ECC RAM.

The stack trace is wierd:

zipper.catspoiler.org dumped core - see /var/crash/vmcore.7

Fri Aug  9 18:03:07 PDT 2019

FreeBSD zipper.catspoiler.org 13.0-CURRENT FreeBSD 13.0-CURRENT r350665 GENERIC 
 amd64

panic: page fault

GNU gdb (GDB) 8.3 [GDB v8.3 for FreeBSD]
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd13.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /boot/kernel/kernel...
Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 7; apic id = 07
fault virtual address   = 0xd45647000
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x82f81b35
stack pointer   = 0x28:0xfe01862681f0
frame pointer   = 0x28:0xfe0186268250
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 34192 (VirtualBox)
trap number = 12
panic: page fault
cpuid = 7
time = 1565393713
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0186267eb0
vpanic() at vpanic+0x19d/frame 0xfe0186267f00
panic() at panic+0x43/frame 0xfe0186267f60
trap_fatal() at trap_fatal+0x39c/frame 0xfe0186267fc0
trap_pfault() at trap_pfault+0x62/frame 0xfe0186268010
trap() at trap+0x2b4/frame 0xfe0186268120
calltrap() at calltrap+0x8/frame 0xfe0186268120
--- trap 0xc, rip = 0x82f81b35, rsp = 0xfe01862681f0, rbp = 
0xfe0186268250 ---
ng_ether_ifnet_arrival_cookie() at 0x82f81b35/frame 0xfe0186268250
ng_ether_ifnet_arrival_cookie() at 0x82f695c5/frame 0xfe01862682e0
ng_ether_ifnet_arrival_cookie() at 0x82f682fb/frame 0xfe0186268350
ng_ether_ifnet_arrival_cookie() at 0x82ec5f2c/frame 0xfe0186268380
ng_ether_ifnet_arrival_cookie() at 0x82ec461f/frame 0xfe0186268400
ng_ether_ifnet_arrival_cookie() at 0x82ec0ec3/frame 0xfe0186268490
ng_ether_ifnet_arrival_cookie() at 0x82f88a36/frame 0xfe0186268530
ng_ether_ifnet_arrival_cookie() at 0x82ec7e8f/frame 0xfe01862685b0
supdrvIOCtlFast() at supdrvIOCtlFast+0xb8/frame 0xfe01862685d0

Re: Booting anything after r352057 kills console

2019-09-25 Thread Thomas Laus 
On 2019-09-24 15:09, Ian Lepore wrote:
> 
> On my system, a whole lotta stuff happens between ntpd and syscons (the
> thing that configures blanktime).  Try setting rc_debug=YES in rc.conf,
> that should write more info to syslog about what's happening between
> ntpd and the lockup point.
>
Ian:

I was able to mount my zfs filesystem r+w and added the rc_debug="YES"
to my rc.conf.  The additional debug messages were written to the beadm
boot environment /var/log/messages.  Since the computer locked up, I was
unable to read this log and email the results.  That log is inaccessible
to a running beadm snapshot, so I gave up on this quest.  I blew away my
source and object files and did a fresh checkout of HEAD today.
Everything built fine and I was able to boot r352710 today.

Thank you and the rest of this list for the help along the way.  I guess
that this is just one of those computer mysteries that won't get solved
at thus time.

Tom


-- 
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
___
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: ktrace/kdump give incorrect message on unlinkat() failure due to capabilities

2019-09-25 Thread Sergey Kandaurov 
On Sat, Sep 21, 2019 at 08:43:58PM -0400, Ryan Stone wrote:
> I have written a short test program that runs unlinkat(2) in
> capability mode and fails due to not having the write capabilities:
> 
> https://people.freebsd.org/~rstone/src/unlink.c
> 
> If I run the binary under ktrace and look at the kdump output, it
> gives the following incorrect output:
> 
> 43775 unlink   CALL  unlinkat(0x3,0x7fffe995,0)
> 43775 unlink   NAMI  "from.QAUlAA0"
> 43775 unlink   CAP   operation requires CAP_LOOKUP, descriptor holds 
> CAP_LOOKUP
> 43775 unlink   RET   unlinkat -1 errno 93 Capabilities insufficient
> 
> The message should instead say that the operation requires
> CAP_UNLINKAT.  Looking at sys/capsicum.h, I suspect that the problem
> is related to the strange definition of CAP_UNLINKAT:
> 
> #define CAP_UNLINKAT (CAP_LOOKUP | 0x1000ULL)

FYI, with this grep it was able to decode capabilities.

Index: lib/libsysdecode/mktables
===
--- lib/libsysdecode/mktables   (revision 352685)
+++ lib/libsysdecode/mktables   (working copy)
@@ -157,7 +157,7 @@
 gen_table "sigcode" "SI_[A-Z]+[[:space:]]+0(x[0-9abcdef]+)?"   
"sys/signal.h"
 gen_table "umtxcvwaitflags" "CVWAIT_[A-Z_]+[[:space:]]+0x[0-9]+"   
"sys/umtx.h"
 gen_table "umtxrwlockflags" "URWLOCK_PREFER_READER[[:space:]]+0x[0-9]+"
"sys/umtx.h"
-gen_table "caprights"   
"CAP_[A-Z_]+[[:space:]]+CAPRIGHT\([0-9],[[:space:]]+0x[0-9]{16}ULL\)"   
"sys/capsicum.h"
+gen_table "caprights"   
"CAP_[A-Z_]+[[:space:]]+(CAPRIGHT|[()A-Z_|[:space:]]+CAP_LOOKUP)"   
"sys/capsicum.h"
 gen_table "sctpprpolicy""SCTP_PR_SCTP_[A-Z_]+[[:space:]]+0x[0-9]+" 
"netinet/sctp_uio.h" "SCTP_PR_SCTP_ALL"
 gen_table "cmsgtypesocket"  "SCM_[A-Z_]+[[:space:]]+0x[0-9]+"  
"sys/socket.h"
 if [ -e "${include_dir}/x86/sysarch.h" ]; then

On unlink.c, it gives:
 45494 unlink   CALL  cap_rights_limit(0x3,0x7fffead0)
 45494 unlink   STRU  cap_rights_t CAP_LOOKUP
 45494 unlink   RET   cap_rights_limit 0
 45494 unlink   CALL  openat(AT_FDCWD,0x200323,0)
 45494 unlink   NAMI  "/tmp"
 45494 unlink   RET   openat 4
 45494 unlink   CALL  cap_rights_limit(0x4,0x7fffead0)
 45494 unlink   STRU  cap_rights_t CAP_LOOKUP,CAP_UNLINKAT
 45494 unlink   RET   cap_rights_limit 0
 45494 unlink   CALL  cap_enter
 45494 unlink   RET   cap_enter 0
 45494 unlink   CALL  unlinkat(0x3,0x7fffeaa5,0)
 45494 unlink   NAMI  "from.YG6jQx2"
 45494 unlink   CAP   operation requires CAP_LOOKUP,CAP_UNLINKAT, descriptor 
holds CAP_LOOKUP

> I have observed the same problem with renameat(2) and
> CAP_RENAMEAT_SOURCE and CAP_RENAMEAT_TARGET:
> 
> https://people.freebsd.org/~rstone/src/rename.c

 49410 rename   CAP   operation requires CAP_LOOKUP,CAP_RENAMEAT_SOURCE, 
descriptor holds CAP_LOOKUP
___
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: The support for AMD graphics and how freebsd hardware support

2019-09-25 Thread Johannes Lundberg 


On 9/25/19 8:00 AM, c...@riseup.net wrote:
> On Wed, Sep 25, 2019 at 09:28:49AM -0500, Valeri Galtsev wrote:
>>
>> On 2019-09-25 01:04, Kevin Oberman wrote:
>>> On Tue, Sep 24, 2019 at 8:56 PM  wrote:
>>>
 developed
 Reply-To:
 X-Priority: 1
 Importance: high
 Disposition-Notification-To: 
 X-Confirm-Reading-To: 
 Return-Receipt-To: 
 Hello,
 1. Does freebsd current and freebsd stable 12 fully support all features
 of AMD Radeon RX 5700, Vega and RX 500 series including the hardware video
 decoding features?

>>> AMD Radeon support is probably the weakest of the three main GPU providers,
>>> but someone else may be able to confirm the status of those particular
>>> units. You would be far more likely to get information on X related issues
>>> by sending to the x...@freebsd.org mailing list.
>>>
 2. From website, https://wiki.freebsd.org/Graphics#AMD_Graphics, it says
 "Update drm-stable to Linux 4.16 for FreeBSD 12.0". Does it mean freebsd
 hardware support or drivers are copied or translated from linux kernel
 codes?

>>> They are derived with minimal changes from the Linux code. FreeBSD has
>>> kernel modules that provide kernel support. These modules are not part of
>>> FreeBSD. They are GPL licensed, so are built as a port, drm-kmod and a
>>> group of slave ports that are for specific kernel versions.
>>>
 3. How are freebsd hardware support really developed? In linux kernel
 mailing list, there are over 2,000 emails per day from hardware vendors
 such as Intel, AMD, Huawei, Samsung, Sony submitting patches or hardware
 drivers. What about BSD? I did not find any such equivalence in freebsd
 after googling.

>>> Only Nvidia provides any significant support for its products on FreeBSD
>>> and, as a result, almost all other X code is identical or very nearly
>>> identical to the Linux code.
>> My impression, however, has always been that NVIDIA never provides
>> substantial specifications of internals of their hardware (thus there is no
>> way to write decent open source driver), and they provide only binary
>> drivers which are accompanied by source code (to a degree kernel specific)
>> of interface between binary driver and kernel (the last is what you compile
>> against your kernel).
>>
>> Am I wrong or awfully outdated with my understanding?
>>
> I think you are right. At least in Linux, the linux kernel 5.3 fully
> support all the above AMO GPU with built in open source driver. But
> NVIDIA GPU will not work or display properly without its closed source,
> proprietary drivers installed. 
>
> But what is the current stage of freebsd stable and freebsd current' copy of
> linux drivers and when will linux kernel 5.3 drivers arrive in freebsd?
Hi!

We still have some minor issues with 5.0 that needs to be fixed and
since it's all volunteer work, it's hard to say. I would expect that 5.0
is the latest we'll support until at least early next year.

/Johannes (maintainer of kernel drm drivers)

>
> The freebsd website should have had some real time update of such info
> in order for people to easily build computer system for freebsd.
>
>> Thanks.
>> Valeri
>>
>>> --
>>> Kevin Oberman, Part time kid herder and retired Network Engineer
>>> E-mail: rkober...@gmail.com
>>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>>> ___
>>> freebsd-questi...@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
>>> To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
>>>
>> -- 
>> 
>> Valeri Galtsev
>> Sr System Administrator
>> Department of Astronomy and Astrophysics
>> Kavli Institute for Cosmological Physics
>> University of Chicago
>> Phone: 773-702-4247
>> 
>> ___
>> freebsd-questi...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
>> To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
> ___
> 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"
___
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: panic: sched_pickcpu: Failed to find a cpu.

2019-09-25 Thread Yasuhiro KIMURA 
From: Yasuhiro KIMURA 
Subject: Re: panic: sched_pickcpu: Failed to find a cpu.
Date: Thu, 26 Sep 2019 00:12:48 +0900 (JST)

>> Yes; mav@ fixed it with r352677.
> 
> Thanks. I'll update source tree and rebuild kernel.

I updated kernel to r352685 and now system boots successfully.

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

Kernel panic after rebuilding CURRENT

2019-09-25 Thread mms.vanbreukelin...@gmail.com 
Had verbose on and got the following kernel error on 290:
taskqgroup_adjust_if_config_tqg: panic: sched_pickcpu: failed to find a cpu
Looked for device tqg,  isn't available in a slightly changing GENERIC custom. 
I know what this personally means to me,  incompatibility and a lack of social 
integration,   but what's the reason for BSD telling me: "thank you,  that's 
it!" I have LOCK_PROFILING as option for building,  but this had nothing to do 
with that kinda problem.  
Reversion from this morning,  as a lack of Inet at the moment, I had to 'svn 
up' from within Linux with ufs write enabled and gave root to the rescue CD for 
fsck'ing the /dev/ada0p7. The hashkey terror stops and when unmounted without 
flags -fl on arch. They're doing well together simple because if unification 
purpose against monopoly. 
Had to rebuild without SMP,  so virtualization is problematic. #ing the 
ule_scheduler shouldn't be "unticked", as this causes severe compile errors. 
I think she just wants a backward development at this age,  nostalgia 
electronica should be a study tribe on universities like history in school!  
Anyone able to get 2nd CPU up again?  
___
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: panic: sched_pickcpu: Failed to find a cpu.

2019-09-25 Thread Yasuhiro KIMURA 
From: David Wolfskill 
Subject: Re: panic: sched_pickcpu: Failed to find a cpu.
Date: Wed, 25 Sep 2019 08:08:15 -0700

> Yes; mav@ fixed it with r352677.

Thanks. I'll update source tree and rebuild kernel.

Regards.

---
Yasuhiro KIMURA
___
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: panic: sched_pickcpu: Failed to find a cpu.

2019-09-25 Thread David Wolfskill 
On Wed, Sep 25, 2019 at 11:44:51PM +0900, Yasuhiro KIMURA wrote:
> yasu@rolling-vm-freebsd1[2001]% uname -a  
>  ~
> FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD 
> 13.0-CURRENT r352351 GENERIC  amd64
> 
> After update to r352669, boot fails as following.
> 
> https://www.utahime.org/FreeBSD/FreeBSD.13-CURRENT.amd64.r352669.screenshot.1.png
> https://www.utahime.org/FreeBSD/FreeBSD.13-CURRENT.amd64.r352669.screenshot.2.png
> 
> Any idea?
> 

Yes; mav@ fixed it with r352677.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"I am the Chosen One!" -- Donald Trump [Cf. Mt 24:23-24; Mk 13:21-23; Jn 5:31]

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: The support for AMD graphics and how freebsd hardware support

2019-09-25 Thread CSO 
On Wed, Sep 25, 2019 at 09:28:49AM -0500, Valeri Galtsev wrote:
> 
> 
> On 2019-09-25 01:04, Kevin Oberman wrote:
> > On Tue, Sep 24, 2019 at 8:56 PM  wrote:
> > 
> > > developed
> > > Reply-To:
> > > X-Priority: 1
> > > Importance: high
> > > Disposition-Notification-To: 
> > > X-Confirm-Reading-To: 
> > > Return-Receipt-To: 
> > > Hello,
> > > 1. Does freebsd current and freebsd stable 12 fully support all features
> > > of AMD Radeon RX 5700, Vega and RX 500 series including the hardware video
> > > decoding features?
> > > 
> > 
> > AMD Radeon support is probably the weakest of the three main GPU providers,
> > but someone else may be able to confirm the status of those particular
> > units. You would be far more likely to get information on X related issues
> > by sending to the x...@freebsd.org mailing list.
> > 
> > > 
> > > 2. From website, https://wiki.freebsd.org/Graphics#AMD_Graphics, it says
> > > "Update drm-stable to Linux 4.16 for FreeBSD 12.0". Does it mean freebsd
> > > hardware support or drivers are copied or translated from linux kernel
> > > codes?
> > > 
> > 
> > They are derived with minimal changes from the Linux code. FreeBSD has
> > kernel modules that provide kernel support. These modules are not part of
> > FreeBSD. They are GPL licensed, so are built as a port, drm-kmod and a
> > group of slave ports that are for specific kernel versions.
> > 
> > > 
> > > 3. How are freebsd hardware support really developed? In linux kernel
> > > mailing list, there are over 2,000 emails per day from hardware vendors
> > > such as Intel, AMD, Huawei, Samsung, Sony submitting patches or hardware
> > > drivers. What about BSD? I did not find any such equivalence in freebsd
> > > after googling.
> > > 
> > 
> > Only Nvidia provides any significant support for its products on FreeBSD
> > and, as a result, almost all other X code is identical or very nearly
> > identical to the Linux code.
> 
> My impression, however, has always been that NVIDIA never provides
> substantial specifications of internals of their hardware (thus there is no
> way to write decent open source driver), and they provide only binary
> drivers which are accompanied by source code (to a degree kernel specific)
> of interface between binary driver and kernel (the last is what you compile
> against your kernel).
> 
> Am I wrong or awfully outdated with my understanding?
> 
I think you are right. At least in Linux, the linux kernel 5.3 fully
support all the above AMO GPU with built in open source driver. But
NVIDIA GPU will not work or display properly without its closed source,
proprietary drivers installed. 

But what is the current stage of freebsd stable and freebsd current' copy of
linux drivers and when will linux kernel 5.3 drivers arrive in freebsd?

The freebsd website should have had some real time update of such info
in order for people to easily build computer system for freebsd.

> Thanks.
> Valeri
> 
> > --
> > Kevin Oberman, Part time kid herder and retired Network Engineer
> > E-mail: rkober...@gmail.com
> > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
> > ___
> > freebsd-questi...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
> > 
> 
> -- 
> 
> Valeri Galtsev
> Sr System Administrator
> Department of Astronomy and Astrophysics
> Kavli Institute for Cosmological Physics
> University of Chicago
> Phone: 773-702-4247
> 
> ___
> freebsd-questi...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
___
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: sched_pickcpu: Failed to find a cpu.

2019-09-25 Thread Yasuhiro KIMURA 
yasu@rolling-vm-freebsd1[2001]% uname -a
   ~
FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD 13.0-CURRENT 
r352351 GENERIC  amd64

After update to r352669, boot fails as following.

https://www.utahime.org/FreeBSD/FreeBSD.13-CURRENT.amd64.r352669.screenshot.1.png
https://www.utahime.org/FreeBSD/FreeBSD.13-CURRENT.amd64.r352669.screenshot.2.png

Any idea?

Regards.

---
Yasuhiro KIMURA
___
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: "panic: sched_pickcpu: Failed to find a cpu" after r352636 -> r352671

2019-09-25 Thread David Wolfskill 
On Wed, Sep 25, 2019 at 08:02:12AM -0400, Alexander Motin wrote:
> Thanks for the notice, it was a wrong assertion.  Fixed.  I'm sorry.
> 

After applying r352677 (via "svn patch --strip 1"), the machine boots
successfully:

FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #683 
r352671M/352671: Wed Sep 25 05:20:43 PDT 2019 
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC  
amd64 1300047 1300047

Thanks! :-)

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"I am the Chosen One!" -- Donald Trump [Cf. Mt 24:23-24; Mk 13:21-23; Jn 5:31]

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: "panic: sched_pickcpu: Failed to find a cpu" after r352636 -> r352671

2019-09-25 Thread Alexander Motin 
Thanks for the notice, it was a wrong assertion.  Fixed.  I'm sorry.

On 25.09.2019 06:54, David Wolfskill wrote:
> ...
> SMP: AP CPU #3 Launched!
> cpu3 AP:
>  ID: 0x0003   VER: 0x01060015 LDR: 0x0008 DFR: 0x x2APIC: 
> 1
>   lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x11ff
>   timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400
>cmci: 0x000100f2
> SMP: AP CPU #6 Launched!
> cpu6 AP:
>  ID: 0x0006   VER: 0x01060015 LDR: 0x0040 DFR: 0x x2APIC: 
> 1
>   lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x11ff
>   timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400
>cmci: 0x000100f2
> panic: sched_pickcpu: Failed to find a cpu.
> cpuid = 0
> time = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x82550830
> vpanic() at vpanic+0x19d/frame 0x82550880
> panic() at panic+0x43/frame 0x825508e0
> sched_pickcpu() at sched_pickcpu+0x4c1/frame 0x82550990
> sched_add() at sched_add+0x6e/frame 0x825509d0
> gtaskqueue_start_threads() at gtaskqueue_start_threads+0x124/frame 
> 0x82550a70
> taskqgroup_cpu_create() at taskqgroup_cpu_create+0x135/frame 
> 0x82550ab0
> taskqgroup_adjust() at taskqgroup_adjust+0x1ad/frame 0x82550b20
> mi_startup() at mi_startup+0x210/frame 0x82550b70
> btext() at btext+0x2c
> KDB: enter: panic
> [ thread pid 0 tid 10 ]
> Stopped at  kdb_enter+0x3b: movq$0,kdb_why
> db> 
> 
> This is an Intel amd64 on a 4-core, 2 threads/core machine; I note
> that src/sys/kern/sched_ule.c was modified in this update:
> 
> 
> r352658 | mav | 2019-09-24 13:01:20 -0700 (Tue, 24 Sep 2019) | 24 lines
> 
> Fix/improve interrupt threads scheduling.
> 
> 
> A copy of "dmesg.boot" from a verbose boot from yesterday for the
> machine may be found at
> http://www.catwhisker.org/~david/FreeBSD/history/freebeast.13_dmesg.txt
> 
> I'm about to find out if my laptop (which shares the above salient
> characteristics, and is being updated in parallel) exhibits similar
> symptoms.
> 
> Peace,
> david
> 

-- 
Alexander Motin
___
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: sched_pickcpu: Failed to find a cpu" after r352636 -> r352671

2019-09-25 Thread David Wolfskill 
...
SMP: AP CPU #3 Launched!
cpu3 AP:
 ID: 0x0003   VER: 0x01060015 LDR: 0x0008 DFR: 0x x2APIC: 1
  lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x11ff
  timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400
   cmci: 0x000100f2
SMP: AP CPU #6 Launched!
cpu6 AP:
 ID: 0x0006   VER: 0x01060015 LDR: 0x0040 DFR: 0x x2APIC: 1
  lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x11ff
  timer: 0x000100ef therm: 0x0001 err: 0x00f0 pmc: 0x00010400
   cmci: 0x000100f2
panic: sched_pickcpu: Failed to find a cpu.
cpuid = 0
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x82550830
vpanic() at vpanic+0x19d/frame 0x82550880
panic() at panic+0x43/frame 0x825508e0
sched_pickcpu() at sched_pickcpu+0x4c1/frame 0x82550990
sched_add() at sched_add+0x6e/frame 0x825509d0
gtaskqueue_start_threads() at gtaskqueue_start_threads+0x124/frame 
0x82550a70
taskqgroup_cpu_create() at taskqgroup_cpu_create+0x135/frame 0x82550ab0
taskqgroup_adjust() at taskqgroup_adjust+0x1ad/frame 0x82550b20
mi_startup() at mi_startup+0x210/frame 0x82550b70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at  kdb_enter+0x3b: movq$0,kdb_why
db> 

This is an Intel amd64 on a 4-core, 2 threads/core machine; I note
that src/sys/kern/sched_ule.c was modified in this update:


r352658 | mav | 2019-09-24 13:01:20 -0700 (Tue, 24 Sep 2019) | 24 lines

Fix/improve interrupt threads scheduling.


A copy of "dmesg.boot" from a verbose boot from yesterday for the
machine may be found at
http://www.catwhisker.org/~david/FreeBSD/history/freebeast.13_dmesg.txt

I'm about to find out if my laptop (which shares the above salient
characteristics, and is being updated in parallel) exhibits similar
symptoms.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"I am the Chosen One!" -- Donald Trump [Cf. Mt 24:23-24; Mk 13:21-23; Jn 5:31]

See http://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: The support for AMD graphics and how freebsd hardware support

2019-09-25 Thread Kevin Oberman 
On Tue, Sep 24, 2019 at 8:56 PM  wrote:

> developed
> Reply-To:
> X-Priority: 1
> Importance: high
> Disposition-Notification-To: 
> X-Confirm-Reading-To: 
> Return-Receipt-To: 
> Hello,
> 1. Does freebsd current and freebsd stable 12 fully support all features
> of AMD Radeon RX 5700, Vega and RX 500 series including the hardware video
> decoding features?
>

AMD Radeon support is probably the weakest of the three main GPU providers,
but someone else may be able to confirm the status of those particular
units. You would be far more likely to get information on X related issues
by sending to the x...@freebsd.org mailing list.

>
> 2. From website, https://wiki.freebsd.org/Graphics#AMD_Graphics, it says
> "Update drm-stable to Linux 4.16 for FreeBSD 12.0". Does it mean freebsd
> hardware support or drivers are copied or translated from linux kernel
> codes?
>

They are derived with minimal changes from the Linux code. FreeBSD has
kernel modules that provide kernel support. These modules are not part of
FreeBSD. They are GPL licensed, so are built as a port, drm-kmod and a
group of slave ports that are for specific kernel versions.

>
> 3. How are freebsd hardware support really developed? In linux kernel
> mailing list, there are over 2,000 emails per day from hardware vendors
> such as Intel, AMD, Huawei, Samsung, Sony submitting patches or hardware
> drivers. What about BSD? I did not find any such equivalence in freebsd
> after googling.
>

Only Nvidia provides any significant support for its products on FreeBSD
and, as a result, almost all other X code is identical or very nearly
identical to the Linux code.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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"