Re: radeon panics kernels

[Johannes Lundberg]

On Fri, Oct 4, 2019 at 11:39 Steve Kargl 
wrote:

> On Thu, Oct 03, 2019 at 11:52:38PM +0200, Hans Petter Selasky wrote:
> > On 2019-10-03 22:26, Steve Kargl wrote:
> > > On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote:
> > >>
> > >> If you leave the port debug knob for drm-current-kmod AS-IS, I think
> you
> > >> can get away with:
> > >>
> > >> make DEBUG_FLAGS="-g"
> > >>
> > >> Then re-load the vmcore file in GDB/KGDB from ports (!) and add the
> > >> symbol files for the modules loaded. Then get the backtrace using bt
> > >> command.
> > >>
> > >> BTW: Did you try drm-devel-kmod for 13-current?
> > >>
> > >
> > > Took a bit of trial and error.  If I skip the panic
> > > and trap frames (#0 through #8). I find the backtrace
> > > that follows by sig.  If I move to frame #11, I see
> > >
> > > (kgdb) frame 11
> > > #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=)
> > >  at
> /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c:4114
> > > 4114writel(reg, ((void __iomem *)rdev->rmmio) +
> RADEON_MM_INDEX);
> > > (kgdb) p rdev->rmmio
> > > $3 = (void *) 0x0
> > >
> > > So, your guess of a NULL pointer seems correct.
> >
> > Can you do:
> >
> > set print pretty on
> > print *rdev
> >
>
> This produces close to 3400 lines of output.  Do you want me to
> send it to the list or directly to you?


Please put on gist, pastebin, etc and share the link.


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

[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: wlan can't discover known networks after relocating

[Johannes Lundberg]

On 9/19/19 7:30 PM, Cy Schubert wrote:
> In message  om>
> , Johannes Lundberg writes:
>> --0875960592f275a3
>> Content-Type: text/plain; charset="UTF-8"
>> Content-Transfer-Encoding: quoted-printable
>>
>> Tested today with bgscan added. Didn=E2=80=99t connect to home network unti=
>> l I
>> manually run ifconfig wlan0 scan.
>> Again, this is with failover lagg.
> I use failover lagg too. I'm still at $JOB so no ethernet for my personal 
> FreeBSD laptop here, but that works as well, at home.
>
>> It did however realize I wasn't at the office anymore and the ssid =
>> field
>> was empty in ifconfig output. Sometimes it stays the same long after I
>> leave the network.
> Do you suspend/resume your laptop?
Not the last few months because iichid doesn't support it yet. I just
leave it on while going between work/home.
>
___
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: wlan can't discover known networks after relocating

[Johannes Lundberg]

Tested today with bgscan added. Didn’t connect to home network until I
manually run ifconfig wlan0 scan.
Again, this is with failover lagg.

It did however realize I wasn’t at the office anymore and the ssid field
was empty in ifconfig output. Sometimes it stays the same long after I
leave the network.


On Thu, Sep 19, 2019 at 18:25 Cy Schubert  wrote:

> In message <7938e5fa-67da-35fa-10d0-ee3004438...@freebsd.org>, Johannes
> Lundber
> g writes:
> >
> > On 9/19/19 3:06 PM, Adrian Chadd wrote:
> > > So roaming in ifconfig/net80211 is what's set to manual.
> > >
> > > wpa_supplicant right now does RSSI threshold based roaming. All of the
> > > roaming and network preferences when wpa_supplicant is running is done
> > > in wpa_supplicant. That's where you have to look. Ideally
> > > wpa_supplicant would be triggering bgscan too periodically rather than
> > > only when the RSSI is low.
> > >
> > >
> > >
> > > -adrian
> > >
> > >
> > > On Thu, 19 Sep 2019 at 15:04, Cy Schubert  > > > wrote:
> > >
> > > On September 19, 2019 8:20:07 AM PDT, Adrian Chadd
> > > mailto:adrian.ch...@gmail.com>> wrote:
> > > >Roaming is done in wpa_supplicant when it's running.That's where
> the
> > > >smarts
> > > >need to be. :(
> > > >
> > > >
> > > >
> > > >-adrian
> > > >
> > > >
> > > >On Thu, 19 Sep 2019 at 05:44, Bjoern A. Zeeb
> > > > > > >
> > > >wrote:
> > > >
> > > >> On 19 Sep 2019, at 12:28, Tom Jones wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> freebsd-wireless might be a better list for all this ..
> > > >>
> > > >>
> > > >> > On Tue, Sep 17, 2019 at 04:36:28PM +, Poul-Henning Kamp
> > > wrote:
> > > >> >> 
> > > >> >> In message <707bcd3f-fa6b-82eb-fa8f-09c4b800f...@freebsd.org
> >,
> > > >> >> Johannes Lundber
> > > >> >> g writes:
> > > >> >>
> > > >> >>> For a long time now I have had this problem with iwm and
> wlan0.
> > > >> >>> Whenever
> > > >> >>> I move between work and home it won't reconnect
> > > automatically and
> > > >I
> > > >> >>> have
> > > >> >>> to do wlan0 scan manually for it to pick up the different
> > > >network.
> > > >> >>
> > > >> >> I suffer from the dreaded "reason=0" when I move inside my
> > > house:
> > > >> >>
> > > >> >>  > scan
> > > >> >>  OK
> > > >> >>  <3>CTRL-EVENT-SCAN-RESULTS
> > > >> >>  <3>Trying to associate with 6c:3b:6b:3d:a2:e9
> > > >(SSID='Palombia'
> > > >> >> freq=2452 MHz)
> > > >> >>  <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:3d:a2:e9
> reason
> > =0
> > > >> >>  <3>CTRL-EVENT-SCAN-RESULTS
> > > >> >>  <3>Trying to associate with 6c:3b:6b:ab:ce:d4
> > > >(SSID='Palombia'
> > > >> >> freq=2412 MHz)
> > > >> >>  <3>Associated with 6c:3b:6b:ab:ce:d4
> > > >> >>
> > > >> >> a2:e9 is the loudest AP here in my office, but my I have
> been in
> > > >the
> > > >> >> other end of the house iwn consistently fails to associate
> > > with it
> > > >> >> and
> > > >> >> and keeps picking the weaker AP in the far end.
> > > >> >>
> > > >> >> Eventually (hours!) it disconnects from the weaker ap, also
> with
> > > >> >> "reason=0" and gets it right:
> > > >> >>
> > > >> >>  <3>WPA: Group rekeying completed with 6c:3b:6b:ab:ce:d4
> > > >[GTK=CCMP]
> > > >> >>  <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:ab:ce:d4
> reason
> > =0
> > > >> >>  <3>CTRL-EVENT-SCAN-RESULTS
> > > >> >>  <3>Trying to associate with 6c:3b:6b:3d:a2:e9
> > > >(SSID='Palombia'
> > > >> >> freq=2452 MHz)
> > > >> >>  <3>Associated with 6c:3b:6b:3d:a2:e9
> > > >> >>  <3>WPA: Key negotiation completed with 6c:3b:6b:3d:a2:e9
> > > >[PTK=CCMP
> > > >> >> GTK=CCMP]
> > > >> >>  <3>CTRL-EVENT-CONNECTED - Connection to
> 6c:3b:6b:3d:a2:e9
> > > >> completed
> > > >> >> [id=3 id_str=]
> > > >> >>  <3>WPA: Group rekeying completed with 6c:3b:6b:3d:a2:e9
> > > >[GTK=CCMP]
> > > >> >>
> > > >> >> And yes, working roaming would be nice too...
> > > >> >
> > > >> > I have the problem that when roaming networks become disabled
> > > >> >
> > > >> >   $ wpa_cli
> > > >> >   Selected interface 'wlan0'
> > > >> >
> > > >> >   Interactive mode
> > > >> >
> > > >> >   > list_networks
> > > >> >   network id / ssid / bssid / flags
> > > >> >   0   network1any [CURRENT]
> > > >> >   1   network2 any[DISABLED]
> > > >> >   2   network3 any[DISABLED]
> > > >> >   3   network4 any[DISABLED]
> > > >> >   4   network5 any[DISABLED]
> > > >> >   Selected interface 'wlan0'
> > > >> >
> > > >> >
> > >   

Re: wlan can't discover known networks after relocating

[Johannes Lundberg]

On 9/19/19 3:06 PM, Adrian Chadd wrote:
> So roaming in ifconfig/net80211 is what's set to manual.
>
> wpa_supplicant right now does RSSI threshold based roaming. All of the
> roaming and network preferences when wpa_supplicant is running is done
> in wpa_supplicant. That's where you have to look. Ideally
> wpa_supplicant would be triggering bgscan too periodically rather than
> only when the RSSI is low.
>
>
>
> -adrian
>
>
> On Thu, 19 Sep 2019 at 15:04, Cy Schubert  > wrote:
>
> On September 19, 2019 8:20:07 AM PDT, Adrian Chadd
> mailto:adrian.ch...@gmail.com>> wrote:
> >Roaming is done in wpa_supplicant when it's running.That's where the
> >smarts
> >need to be. :(
> >
> >
> >
> >-adrian
> >
> >
> >On Thu, 19 Sep 2019 at 05:44, Bjoern A. Zeeb
> > >
> >wrote:
> >
> >> On 19 Sep 2019, at 12:28, Tom Jones wrote:
> >>
> >> Hi,
> >>
> >> freebsd-wireless might be a better list for all this ..
> >>
> >>
> >> > On Tue, Sep 17, 2019 at 04:36:28PM +, Poul-Henning Kamp
> wrote:
> >> >> 
> >> >> In message <707bcd3f-fa6b-82eb-fa8f-09c4b800f...@freebsd.org>,
> >> >> Johannes Lundber
> >> >> g writes:
> >> >>
> >> >>> For a long time now I have had this problem with iwm and wlan0.
> >> >>> Whenever
> >> >>> I move between work and home it won't reconnect
> automatically and
> >I
> >> >>> have
> >> >>> to do wlan0 scan manually for it to pick up the different
> >network.
> >> >>
> >> >> I suffer from the dreaded "reason=0" when I move inside my
> house:
> >> >>
> >> >>      > scan
> >> >>      OK
> >> >>      <3>CTRL-EVENT-SCAN-RESULTS
> >> >>      <3>Trying to associate with 6c:3b:6b:3d:a2:e9
> >(SSID='Palombia'
> >> >> freq=2452 MHz)
> >> >>      <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:3d:a2:e9 reason=0
> >> >>      <3>CTRL-EVENT-SCAN-RESULTS
> >> >>      <3>Trying to associate with 6c:3b:6b:ab:ce:d4
> >(SSID='Palombia'
> >> >> freq=2412 MHz)
> >> >>      <3>Associated with 6c:3b:6b:ab:ce:d4
> >> >>
> >> >> a2:e9 is the loudest AP here in my office, but my I have been in
> >the
> >> >> other end of the house iwn consistently fails to associate
> with it
> >> >> and
> >> >> and keeps picking the weaker AP in the far end.
> >> >>
> >> >> Eventually (hours!) it disconnects from the weaker ap, also with
> >> >> "reason=0" and gets it right:
> >> >>
> >> >>      <3>WPA: Group rekeying completed with 6c:3b:6b:ab:ce:d4
> >[GTK=CCMP]
> >> >>      <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:ab:ce:d4 reason=0
> >> >>      <3>CTRL-EVENT-SCAN-RESULTS
> >> >>      <3>Trying to associate with 6c:3b:6b:3d:a2:e9
> >(SSID='Palombia'
> >> >> freq=2452 MHz)
> >> >>      <3>Associated with 6c:3b:6b:3d:a2:e9
> >> >>      <3>WPA: Key negotiation completed with 6c:3b:6b:3d:a2:e9
> >[PTK=CCMP
> >> >> GTK=CCMP]
> >> >>      <3>CTRL-EVENT-CONNECTED - Connection to 6c:3b:6b:3d:a2:e9
> >> completed
> >> >> [id=3 id_str=]
> >> >>      <3>WPA: Group rekeying completed with 6c:3b:6b:3d:a2:e9
> >[GTK=CCMP]
> >> >>
> >> >> And yes, working roaming would be nice too...
> >> >
> >> > I have the problem that when roaming networks become disabled
> >> >
> >> >       $ wpa_cli
> >> >       Selected interface 'wlan0'
> >> >
> >> >       Interactive mode
> >> >
> >> >       > list_networks
> >> >       network id / ssid / bssid / flags
> >> >       0       network1        any     [CURRENT]
> >> >       1       network2 any    [DISABLED]
> >> >       2       network3 any    [DISABLED]
> >> >       3       network4 any    [DISABLED]
> >> >       4       network5 any    [DISABLED]
> >> >       Selected interface 'wlan0'
> >> >
> >> >
> >> > I address this by doing network_enable x in wpa_cli and it all
> >comes
> >> > back. I asked Adrian about this in the past, but it needs some
> >> > debugging
> >> > to pin down.
> >>
> >>
> >> Is this iwm(4) as well in your case or another card?
> >>
> >> /bz
> >> ___
> >> freebsd-wirel...@freebsd.org
>  mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
> >> To unsubscribe, send any mail to
> >"freebsd-wireless-unsubscr...@freebsd.org
> 
> >> "
> >>
> >___
> >freebsd-current@freebsd.org 
> mailing list
> >https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >To unsubscribe, send any mail to
> >"freebsd

wlan can't discover known networks after relocating

[Johannes Lundberg]

Hi

For a long time now I have had this problem with iwm and wlan0. Whenever
I move between work and home it won't reconnect automatically and I have
to do wlan0 scan manually for it to pick up the different network.

Anyone have a solution for this? For now I think I'll put a 'ifconfig
wlan0 scan' in crontab to run every minute.

Dell laptop, 13-CURRENT, always fairly recent.

Also, I'm using lagg wifi failover but I'm pretty sure it's the same if
I configure only wifi.

Cheers!



___
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: pseudofs broken(?) with r351741

[Johannes Lundberg]

On 9/4/19 1:55 PM, Mateusz Guzik wrote:
> have you tried with https://svnweb.freebsd.org/changeset/base/351815 ?


That fixes it. Thanks!

>
> On 9/4/19, Johannes Lundberg  wrote:
>> Hey
>>
>> I noticed that linuxkpi's debugfs which is based on pfs stopped show any
>> content in mounted folders.
>>
>> r351740 works as expected, r351741 does not. Just as if there are no files.
>>
>> Does this change require any patches to users of pfs to work or is pfs
>> broken?
>>
>>
>> commit 378285257117261aba3d181fff97da9d56d5f566 (HEAD)
>>
>> Author: mjg 
>> Date:   Tue Sep 3 05:54:51 2019
>>
>>     pseudofs: fix a LOR pfs_node vs pidhash (sleepable after non-sleepable)
>>
>>     Sponsored by:   The FreeBSD Foundation
>>
>> Notes:
>>     svn path=/head/; revision=351741
>>
>>
>>
>>
>
___
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"

pseudofs broken(?) with r351741

[Johannes Lundberg]

Hey

I noticed that linuxkpi's debugfs which is based on pfs stopped show any
content in mounted folders.

r351740 works as expected, r351741 does not. Just as if there are no files.

Does this change require any patches to users of pfs to work or is pfs
broken?


commit 378285257117261aba3d181fff97da9d56d5f566 (HEAD)

Author: mjg 
Date:   Tue Sep 3 05:54:51 2019

    pseudofs: fix a LOR pfs_node vs pidhash (sleepable after non-sleepable)
   
    Sponsored by:   The FreeBSD Foundation

Notes:
    svn path=/head/; revision=351741



___
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: Cannot open /dev/null:No such file or directory

[Johannes Lundberg]

Hi

This is probably overkill but I've attached a diff that show my patches
to image.sh. It's just a hack so far to make it do what I want and not
meant as general purpose. Use the changes you need for your application.

Changes (only meant to work for building usb images on amd64 and i386)

- mount devfs so pkg will work properly
- add "install packages from official repo" option so you won't have to
build your own packages for each jail
- downloaded packages from official repo is cached locally to avoid
excessive downloads
- hack for i386 so packages are installed properly
- increase swap space to allow for kernel core dumps (for usb image)
- execute post-install script "overlay.sh" in the jail if provided in
the overlay folder

Bapt: Maybe you'll find some of these changes useful? :)

/Johannes

On 6/11/19 8:52 AM, jbwli...@hilltopgroup.com wrote:
> I'm having the same issue with poudriere image; could you please let
> me know what you did to fix it?  I'm assuming the image.sh you're
> referring to is /usr/local/share/poudriere/image.sh, but I'm not sure
> where the change would need to be made.
>
> Thanks in advance,
> Joseph
>
>
> On 2019-06-04 13:02, Johannes Lundberg wrote:
>> On 6/3/19 10:44 PM, Baptiste Daroussin wrote:
>>> On Tue, Jun 04, 2019 at 07:32:16AM +0200, O. Hartmann wrote:
>>>> Hello List,
>>>>
>>>> lately I ran into a serious problem installing packages in a nanoBSD
>>>> environment, in which the package repository server is "remotely"
>>>> on site. The
>>>> issue as documented below occurs on both 12-STABLE r348529 and
>>>> CURRENT r348600
>>>> and must have been introduced shortly, since the last known good
>>>> installation
>>>> with the environment of ours was on 21st May 2019.
>>>>
>>>> As far as I know,, the package installation is performed via
>>>> "chroot'ed"
>>>> environment and somehow /dev/null is out of a sudden not accessible
>>>> anymore
>>>> while pkg tries to delegate some output to /dev/null.
>>>>
>>>> What happened here?
>>>>
>>>> Kind regards and thanks in advance,
>>>>
>>>> oh
>>>>
>>>> [...]
>>>> All repositories are up to date.
>>>> The following 10 package(s) will be affected (of 0 checked):
>>>>
>>>> New packages to be INSTALLED:
>>>>     python3: 3_3 [zeit4]
>>>>     sudo: 1.8.27_1 [zeit4]
>>>>     devcpu-data: 1.22 [zeit4]
>>>>     python36: 3.6.8_2 [zeit4]
>>>>     readline: 8.0.0 [zeit4]
>>>>     indexinfo: 0.3.1 [zeit4]
>>>>     libffi: 3.2.1_3 [zeit4]
>>>>     gettext-runtime: 0.19.8.1_2 [zeit4]
>>>>     openldap-sasl-client: 2.4.47 [zeit4]
>>>>     cyrus-sasl: 2.1.27 [zeit4]
>>>>
>>>> Number of packages to be installed: 10
>>>>
>>> What is new is that pkg is using /dev/null as input when running
>>> script? this is
>>> new since pkg 1.11 . Somehow this does not seems to be avaalaible in
>>> your
>>> environement.
>>
>> Hi
>>
>> Same things applies to poudriere-image. I had to add a mount devfs
>> command to the image.sh script.
>>
>>>
>>> Best regards,
>>> Bapt
>>
>> ___
>> 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"
--- image.sh.orig	2019-06-06 08:24:36.445264000 -0700
+++ image.sh	2019-06-08 17:44:57.852022000 -0700
@@ -40,6 +40,7 @@
 -n imagename-- The name of the generated image
 -o outputdir-- Image destination directory
 -p portstree-- Ports tree
+-P  -- Install packages from official repo
 -s size -- Set the image size
 -t type -- Type of image can be one of (default iso+zmfs):
 -- iso, iso+mfs, iso+zmfs, usb, usb+mfs, usb+zmfs,
@@ -112,7 +113,7 @@
 . ${SCRIPTPREFIX}/common.sh
 HOSTNAME=poudriere-image
 
-while getopts "c:f:h:j:m:n:o:p:s:t:X:z:" FLAG; do
+while getopts "c:f:h:j:m:n:o:Pp:s:t:X:z:" FLAG; do
 	case "${FLAG}" in
 		c)
 			[ -d "${OPTARG}" ] || err 1 "No such extract directory: ${OPTARG}"
@@ -146,6 +147,9 @@
 			OPTARG="${SAVED_PWD}/${OPTARG}"
 			OUTPUTDIR=${OPTARG}
 			;;
+		P)
+			PKGREPO=1
+			;;

Re: pkg: Cannot open /dev/null:No such file or directory

[Johannes Lundberg]

On 6/3/19 10:44 PM, Baptiste Daroussin wrote:
> On Tue, Jun 04, 2019 at 07:32:16AM +0200, O. Hartmann wrote:
>> Hello List,
>>
>> lately I ran into a serious problem installing packages in a nanoBSD
>> environment, in which the package repository server is "remotely" on site. 
>> The
>> issue as documented below occurs on both 12-STABLE r348529 and CURRENT 
>> r348600
>> and must have been introduced shortly, since the last known good installation
>> with the environment of ours was on 21st May 2019.
>>
>> As far as I know,, the package installation is performed via "chroot'ed"
>> environment and somehow /dev/null is out of a sudden not accessible anymore
>> while pkg tries to delegate some output to /dev/null.
>>
>> What happened here?
>>
>> Kind regards and thanks in advance,
>>
>> oh
>>
>> [...]
>> All repositories are up to date.
>> The following 10 package(s) will be affected (of 0 checked):
>>
>> New packages to be INSTALLED:
>> python3: 3_3 [zeit4]
>> sudo: 1.8.27_1 [zeit4]
>> devcpu-data: 1.22 [zeit4]
>> python36: 3.6.8_2 [zeit4]
>> readline: 8.0.0 [zeit4]
>> indexinfo: 0.3.1 [zeit4]
>> libffi: 3.2.1_3 [zeit4]
>> gettext-runtime: 0.19.8.1_2 [zeit4]
>> openldap-sasl-client: 2.4.47 [zeit4]
>> cyrus-sasl: 2.1.27 [zeit4]
>>
>> Number of packages to be installed: 10
>>
> What is new is that pkg is using /dev/null as input when running script? this 
> is
> new since pkg 1.11 . Somehow this does not seems to be avaalaible in your
> environement.

Hi

Same things applies to poudriere-image. I had to add a mount devfs
command to the image.sh script.

>
> Best regards,
> Bapt

___
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: UEFI boot broken in 13?

[Johannes Lundberg]

On 6/3/19 7:25 PM, Rodney W. Grimes wrote:
>> Hi
>>
>> I'm using poudriere-image to create usb memstick images. The images are
>> identical except OS version. They are tested on a laptop with 13-CURRENT
>> installed as only OS, having UEFI boot and root on zfs.
>>
>> 12-STABLE memstick boots fine with in UEFI mode.
> Does it actually boot via a UEFI, or did UEFI fall back to CSM
> and do a legacy boot?
>
> What does "sysctl machdep.bootmethod" say?
> machdep.bootmethod: BIOS

It says UEFI (it is also easy to see the difference between legacy and
uefi boot on the font / font size used so I didn't doubt this).

>> With 13-CURRENT memstick it boots the installed FreeBSD from the SSD
>> instead (I choose USB UEFI OS in boot menu but it silently boots from
>> the SSD instead). If I switch to legacy boot, the memstick image boots fine.
>>
>> Any ideas?
> The .iso building was updated to create hybrid boot images some
> time back, these .iso images should be usable as boot .iso on a
> cd/dvd and as memstick images.  I would encourage there use over
> the memstick images, as there is a plan to remove them once we
> get better experience with the hybrid .iso.

I don't think that would affect things built with poudriere image.
(poudriere image -t usb )

The jails used are download via ftp for both 12 and 13 (created by
poudriere as well).


>
> It is also possible that something has munged the boot in head.
> Have you tried a downloaed ^/head snapshot from the last week,
> as it could also be your build system that is not producing
> a proper boot image?

My 13-CURRENT jail is always latest snapshot.

poudriere image does the same regardless of release: download tarballs,
extract to dir, makefs, mkimg. I don't see why it would work for 12 but
not 13. I can try a newer snapshot later.

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

UEFI boot broken in 13?

[Johannes Lundberg]

Hi

I'm using poudriere-image to create usb memstick images. The images are
identical except OS version. They are tested on a laptop with 13-CURRENT
installed as only OS, having UEFI boot and root on zfs.

12-STABLE memstick boots fine with in UEFI mode.

With 13-CURRENT memstick it boots the installed FreeBSD from the SSD
instead (I choose USB UEFI OS in boot menu but it silently boots from
the SSD instead). If I switch to legacy boot, the memstick image boots fine.

Any ideas?

/Johannes


___
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: Inconsistent behavior with wpa / devd / network interfaces

[Johannes Lundberg]

On 5/30/19 1:25 PM, Miroslav Lachman wrote:
> Greg Rivers wrote on 2019/05/30 18:37:
>
> [...]
>
>>> Do I have something weird in my setup causing this? I don't recall ever
>>> having this issue when not using failover lagg. Running recent
>>> 13-CURRENT.
>>>
>> I think there's a (unknown?) problem that makes lagg(4) incompatible
>> with
>> bridge(4). I've never been unable to make a lagg interface work as a
>> member of
>> a bridge. Lacking the time to pursue it, I've resorted to NATing
>> instead.
>
> lagg and bridge can work together.
> I am running machine with FreeBSD 11.2 with 2 Intel NICs: em0 and em1
> combined in to lagg0
>
> lagg0 has 4 static IP addresses
>
> There is also bhyve VM on tap20, this VM has another 2 static IP
> addresses
>
> tap20 and lagg0 are members of the bridge. This bridge is renamed to
> "vm-public"
>
> vm-public: flags=8843 metric 0
> mtu 1500
>     ether da:ae:ba:75:53:ce
>     nd6 options=1
>     groups: bridge vm-switch viid-4c918@
>     id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>     maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
>     root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>     member: tap20 flags=143
>     ifmaxaddr 0 port 5 priority 128 path cost 200
>     member: lagg0 flags=143
>     ifmaxaddr 0 port 4 priority 128 path cost 200
>
> Everything works without any problem.
>
> The only problem in the beginning was PF rules. I added rule to allow
> traffic to the VM IP addresses.
>
> Miroslav Lachman

Hi

Thanks for the feedback. This setup works great for me too. The problem
is when switching external network on lagg0 (DHCP)... Once I'm connected
and nothing changes, it works perfectly.

> ___
> 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: Inconsistent behavior with wpa / devd / network interfaces

[Johannes Lundberg]

On 5/30/19 12:37 PM, Cy Schubert wrote:
> In message <85a5bf45-231e-1bb4-4c26-677e414af...@freebsd.org>, Johannes 
> Lundber
> g writes:
>> On 5/30/19 9:37 AM, Greg Rivers wrote:
>>> On Thursday, May 30, 2019 10:31:45 AM CDT Johannes Lundberg wrote:
>>>> Hi
>>>>
>>>> I have a bridge and an ethernet/wifi lagg failover like this:
>>>>
>>>> # First define all cloned interfaces
>>>> cloned_interfaces="bridge0 lagg0"
>>>>
>>>> # bhyve bridge
>>>> ifconfig_bridge0="inet 192.168.8.1/24 addm lagg0 up"
>>>>
>>>> # Ethernet/WiFi failvoer
>>>> ifconfig_em0="up"
>>>> wlans_iwm0="wlan0"
>>>> ifconfig_wlan0="WPA up"
>>>> create_args_wlan0="wlanaddr xx:xx:xx:xx:xx:xx"
>>>> ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP up"
>>>>
>>>> When I move between home and work networks and plug in the network cable
>>>> it sometimes reconfigure and sometimes (mostly) not. Looking at devd
>>>> output from a failed occasion and I can see that it calls dhclient on
>>>> em0 and not lagg0. But it since it works sometimes I don't know if this
>>>> is correct or not (I would expect lagg0 and not em0 but manually running
>>>> this command with either em0 or lagg0 doesn't do anything)...
>>>>
>>>> devd log: Executing 'service dhclient quietstart $'em0''
>>>>
>>>> In addition to this, I often have to run ifconfig wlan0 scan (or service
>>>> netif restart) or to have the it reconnect to a different wifi. It
>>>> doesn't seem to be doing any periodical scanning and reconnecting at all
>>>> (but maybe that's a different issue).
>>>>
>>>> For sometime now I usually have to run service netif restart to get
>>>> network working after switching location, followed by adding all my VM
>>>> tap interfaces to the bridge manually, and restarting bhyve guests
>>>> because they lose connectivity.. It's getting a bit tiring and I would
>>>> like to find a solution.
>>>>
>>>> Do I have something weird in my setup causing this? I don't recall ever
>>>> having this issue when not using failover lagg. Running recent 13-CURRENT.
>>>>
>>> I think there's a (unknown?) problem that makes lagg(4) incompatible with 
>>> bridge(4). I've never been unable to make a lagg interface work as a member
>>  of 
>>> a bridge. Lacking the time to pursue it, I've resorted to NATing instead.
>>>
>>> Also, wlan interfaces tend to break if you change their MAC address.  So in
>>  a 
>>> lagg consisting of a wlan interface and a ethernet interface (without a 
>>> bridge), I always set the MAC of the ethernet to match the native MAC of th
>> e 
>>> wlan, and not vice versa.
>>>
>> Hi
>>
>> Thanks for the reply! I could try to reverse the MAC address setting to
>> see if that helps.
>>
>> I'm also running NAT like this for bhyve guests
>>
>> % cat /etc/pf.conf
>> nat on lagg0 from {192.168.8.0/24} to any -> (lagg0)
>>
>> The "bhyve bridge" bridge0's members are lagg0 and the tapX interfaces.
>> This setup works great as long as external connection doesn't change. I
>> have full connectivity between host<->guests and guests can access
>> internet as well (with seamless switching between ethernet/wifi *). The
>> bhyve guests are configured with static IP addresses 192.168.8.X.
>>
>> * Sometimes seamless, sometimes not so much...
> I use a similar configuration except to use $cloned_interfaces.
>
> The caveat is, if on the same network switching from wired to wireless 
> and back again is seamless. However if the wired and wireless networks 
> are on different segments, because dhclient isn't recycled one needs to 
> restart dhclient manually.
>
> The problem is that when switching from wired to wireless or back you 
> are on another network, there is no way to know what network you're on 
> until dhclient is killed and restarted.
>
> OK, so we automatically restart dhclient every time then: Problem: this 
> is highly disruptive when you happen to be connected to the same 
> network don't need dhclient restarted but is restarted anyway, e.g. the 
> network address is the same. The trade-off is take a hit every time 
> there is a recon

Re: Inconsistent behavior with wpa / devd / network interfaces

[Johannes Lundberg]

On 5/30/19 9:37 AM, Greg Rivers wrote:
> On Thursday, May 30, 2019 10:31:45 AM CDT Johannes Lundberg wrote:
>> Hi
>>
>> I have a bridge and an ethernet/wifi lagg failover like this:
>>
>> # First define all cloned interfaces
>> cloned_interfaces="bridge0 lagg0"
>>
>> # bhyve bridge
>> ifconfig_bridge0="inet 192.168.8.1/24 addm lagg0 up"
>>
>> # Ethernet/WiFi failvoer
>> ifconfig_em0="up"
>> wlans_iwm0="wlan0"
>> ifconfig_wlan0="WPA up"
>> create_args_wlan0="wlanaddr xx:xx:xx:xx:xx:xx"
>> ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP up"
>>
>> When I move between home and work networks and plug in the network cable
>> it sometimes reconfigure and sometimes (mostly) not. Looking at devd
>> output from a failed occasion and I can see that it calls dhclient on
>> em0 and not lagg0. But it since it works sometimes I don't know if this
>> is correct or not (I would expect lagg0 and not em0 but manually running
>> this command with either em0 or lagg0 doesn't do anything)...
>>
>> devd log: Executing 'service dhclient quietstart $'em0''
>>
>> In addition to this, I often have to run ifconfig wlan0 scan (or service
>> netif restart) or to have the it reconnect to a different wifi. It
>> doesn't seem to be doing any periodical scanning and reconnecting at all
>> (but maybe that's a different issue).
>>
>> For sometime now I usually have to run service netif restart to get
>> network working after switching location, followed by adding all my VM
>> tap interfaces to the bridge manually, and restarting bhyve guests
>> because they lose connectivity.. It's getting a bit tiring and I would
>> like to find a solution.
>>
>> Do I have something weird in my setup causing this? I don't recall ever
>> having this issue when not using failover lagg. Running recent 13-CURRENT.
>>
> I think there's a (unknown?) problem that makes lagg(4) incompatible with 
> bridge(4). I've never been unable to make a lagg interface work as a member 
> of 
> a bridge. Lacking the time to pursue it, I've resorted to NATing instead.
>
> Also, wlan interfaces tend to break if you change their MAC address.  So in a 
> lagg consisting of a wlan interface and a ethernet interface (without a 
> bridge), I always set the MAC of the ethernet to match the native MAC of the 
> wlan, and not vice versa.
>
Hi

Thanks for the reply! I could try to reverse the MAC address setting to
see if that helps.

I'm also running NAT like this for bhyve guests

% cat /etc/pf.conf
nat on lagg0 from {192.168.8.0/24} to any -> (lagg0)

The "bhyve bridge" bridge0's members are lagg0 and the tapX interfaces.
This setup works great as long as external connection doesn't change. I
have full connectivity between host<->guests and guests can access
internet as well (with seamless switching between ethernet/wifi *). The
bhyve guests are configured with static IP addresses 192.168.8.X.

* Sometimes seamless, sometimes not so much...

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

Inconsistent behavior with wpa / devd / network interfaces

[Johannes Lundberg]

Hi

I have a bridge and an ethernet/wifi lagg failover like this:

# First define all cloned interfaces
cloned_interfaces="bridge0 lagg0"

# bhyve bridge
ifconfig_bridge0="inet 192.168.8.1/24 addm lagg0 up"

# Ethernet/WiFi failvoer
ifconfig_em0="up"
wlans_iwm0="wlan0"
ifconfig_wlan0="WPA up"
create_args_wlan0="wlanaddr xx:xx:xx:xx:xx:xx"
ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 DHCP up"

When I move between home and work networks and plug in the network cable
it sometimes reconfigure and sometimes (mostly) not. Looking at devd
output from a failed occasion and I can see that it calls dhclient on
em0 and not lagg0. But it since it works sometimes I don't know if this
is correct or not (I would expect lagg0 and not em0 but manually running
this command with either em0 or lagg0 doesn't do anything)...

devd log: Executing 'service dhclient quietstart $'em0''

In addition to this, I often have to run ifconfig wlan0 scan (or service
netif restart) or to have the it reconnect to a different wifi. It
doesn't seem to be doing any periodical scanning and reconnecting at all
(but maybe that's a different issue).

For sometime now I usually have to run service netif restart to get
network working after switching location, followed by adding all my VM
tap interfaces to the bridge manually, and restarting bhyve guests
because they lose connectivity.. It's getting a bit tiring and I would
like to find a solution.

Do I have something weird in my setup causing this? I don't recall ever
having this issue when not using failover lagg. Running recent 13-CURRENT.

Thanks!
/Johannes


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

Heads up for LinuxKPI updates to 12-STABLE

[Johannes Lundberg]

Hi

As with recent 13-CURRENT, we're pushing some updates that might break
build of drm modules temporarily on 12-STABLE. One of those changes is
moving lindebugfs.ko from ports to base. If you're building your kernel
with MODULES_OVERRIDE, don't forget to include it since it is required
by drm drivers that use linuxkpi.

A new drm-fbsd12.1-kmod port for 12-STABLE (later includes also
12.1-RELEASE) will be created. The goal is to provide support for
hardware that is supported by Linux 5.0, in FreeBSD 12.1.

In an emergency, drivers for 12-STABLE can (hopefully) be built directly
from github here https://github.com/FreeBSDDesktop/kms-drm (drm-v4.16 or
drm-v5.0 branches), once today's series of commits are in.

Any testing on 12-STABLE is welcome. drm-v5.0 is still WIP but should be
quite usable.

Cheers!


___
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: Weirdness when writing to pseudofs file

[Johannes Lundberg]

On 5/22/19 4:22 PM, Alan Somers wrote:
> On Wed, May 22, 2019 at 5:18 PM Johannes Lundberg  wrote:
>>
>> On 5/22/19 4:12 PM, Johannes Lundberg wrote:
>>> On 5/22/19 3:02 PM, Conrad Meyer wrote:
>>>> On Wed, May 22, 2019 at 1:58 PM Johannes Lundberg  
>>>> wrote:
>>>>>> It seems, a single '>' will cause it to try to create the file (even
>>>>>> though it already exists) and that fails (kern_openat).
>>>>>>
>>>>> I would guess because of
>>>>>
>>>>> https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042
>>>>>
>>>>> struct vop_vector pfs_vnodeops = {
>>>>> ...
>>>>> .vop_create = VOP_EOPNOTSUPP,
>>>>> ...
>>>>> }
>>>> kern_openat -> vn_open(_cred) should only call VOP_CREATE if namei()
>>>> cannot find the named vnode (ni_vp == NULL).  Otherwise, it should
>>>> just invoke VOP_OPEN.  This suggests there might be a lookup bug in
>>>> pfs?  Tracing VOPs as Mark suggested seems like a good next step.
>>>>
>>>> Best,
>>>> Conrad
>>> Thanks Conrad. Yeah, that makes sense that it would open instead of
>>> recreating. Tracing a'la Mark points to
>>>
>>> vop_getwritemount
>>>
>>> failing.
>> Actually vop_setattr also shows up in dtrace.
>>
>> I'll continue digging..
> vop_setattr would get called to truncate the file's size down to 0.
> That's probably called by sh which is opening the file with O_TRUNC.
>
> -Alan

It works if I simply return 0 from pfs_setattr so that's the culprit
indeed. Hmm, wonder if there's any elegant solution to this..



___
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: Weirdness when writing to pseudofs file

[Johannes Lundberg]

On 5/22/19 4:12 PM, Johannes Lundberg wrote:
> On 5/22/19 3:02 PM, Conrad Meyer wrote:
>> On Wed, May 22, 2019 at 1:58 PM Johannes Lundberg  
>> wrote:
>>>> It seems, a single '>' will cause it to try to create the file (even
>>>> though it already exists) and that fails (kern_openat).
>>>>
>>> I would guess because of
>>>
>>> https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042
>>>
>>> struct vop_vector pfs_vnodeops = {
>>> ...
>>> .vop_create = VOP_EOPNOTSUPP,
>>> ...
>>> }
>> kern_openat -> vn_open(_cred) should only call VOP_CREATE if namei()
>> cannot find the named vnode (ni_vp == NULL).  Otherwise, it should
>> just invoke VOP_OPEN.  This suggests there might be a lookup bug in
>> pfs?  Tracing VOPs as Mark suggested seems like a good next step.
>>
>> Best,
>> Conrad
> Thanks Conrad. Yeah, that makes sense that it would open instead of
> recreating. Tracing a'la Mark points to
>
> vop_getwritemount
>
> failing.

Actually vop_setattr also shows up in dtrace.

I'll continue digging..

>
>
___
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: Weirdness when writing to pseudofs file

[Johannes Lundberg]

On 5/22/19 3:02 PM, Conrad Meyer wrote:
> On Wed, May 22, 2019 at 1:58 PM Johannes Lundberg  wrote:
>>> It seems, a single '>' will cause it to try to create the file (even
>>> though it already exists) and that fails (kern_openat).
>>>
>> I would guess because of
>>
>> https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042
>>
>> struct vop_vector pfs_vnodeops = {
>> ...
>> .vop_create = VOP_EOPNOTSUPP,
>> ...
>> }
> kern_openat -> vn_open(_cred) should only call VOP_CREATE if namei()
> cannot find the named vnode (ni_vp == NULL).  Otherwise, it should
> just invoke VOP_OPEN.  This suggests there might be a lookup bug in
> pfs?  Tracing VOPs as Mark suggested seems like a good next step.
>
> Best,
> Conrad

Thanks Conrad. Yeah, that makes sense that it would open instead of
recreating. Tracing a'la Mark points to

vop_getwritemount

failing.


___
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: Weirdness when writing to pseudofs file

[Johannes Lundberg]

On 5/22/19 1:53 PM, Johannes Lundberg wrote:
> On 5/22/19 11:03 AM, Alan Somers wrote:
>> On Wed, May 22, 2019 at 11:59 AM Johannes Lundberg  
>> wrote:
>>> On 5/22/19 10:51 AM, Konstantin Belousov wrote:
>>>> On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote:
>>>>> Hi
>>>>>
>>>>> I'm fiddling with lindebugfs, which is based on pseudofs. When writing
>>>>> to a file,
>>>>>
>>>>> this works: # echo  1 >> /path/to/file
>>>>>
>>>>> but this does not: # echo 1 > /path/to/file
>>>>>
>>>>> "Operation not supported." is returned before the pseudofs code is even
>>>>> entered.
>>>>>
>>>>> Is this expected behavior? (if so, why?)
>>>> Does the file exist ?
>>>>
>>>> Pseudofs does not implement VOP_CREATE(), which is reasonable.
>>> Yes, it exists and my custom write function is receiving the call for
>>> ">>". (which is for example used by drm driver debugfs to do certain
>>> things on demand by accepting write to a debugfs file)
>> First, you need to try ktrace to see exactly which system call is not
>> supported.  If the problem still isn't obvious, then you can try
>> dtrace to see exactly which VOP isn't suppoted.  Do it like this:
>>
>> sudo ktrace /bin/sh -c "echo 1 > /path/to/file"
>> sudo kdump
>> sudo dtrace -i 'fbt:::return /arg1 == 45/ {trace(".")}' -c "/bin/sh -c
>> 'echo 1 > /path/to/file/'"
>>
>> The dtrace command will show you which function returned EOPNOTSUPP.
>> However, it will also show a lot of functions that coincidentally
>> return 45 even though it's not an errno, and even functions that
>> return void.
>>
>> -Alan
>
> Thanks!
>
> It seems, a single '>' will cause it to try to create the file (even
> though it already exists) and that fails (kern_openat).
>
I would guess because of

https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042

struct vop_vector pfs_vnodeops = {
...
.vop_create = VOP_EOPNOTSUPP,
...
}

___
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: Weirdness when writing to pseudofs file

[Johannes Lundberg]

On 5/22/19 11:03 AM, Alan Somers wrote:
> On Wed, May 22, 2019 at 11:59 AM Johannes Lundberg  
> wrote:
>>
>> On 5/22/19 10:51 AM, Konstantin Belousov wrote:
>>> On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote:
>>>> Hi
>>>>
>>>> I'm fiddling with lindebugfs, which is based on pseudofs. When writing
>>>> to a file,
>>>>
>>>> this works: # echo  1 >> /path/to/file
>>>>
>>>> but this does not: # echo 1 > /path/to/file
>>>>
>>>> "Operation not supported." is returned before the pseudofs code is even
>>>> entered.
>>>>
>>>> Is this expected behavior? (if so, why?)
>>> Does the file exist ?
>>>
>>> Pseudofs does not implement VOP_CREATE(), which is reasonable.
>> Yes, it exists and my custom write function is receiving the call for
>> ">>". (which is for example used by drm driver debugfs to do certain
>> things on demand by accepting write to a debugfs file)
> First, you need to try ktrace to see exactly which system call is not
> supported.  If the problem still isn't obvious, then you can try
> dtrace to see exactly which VOP isn't suppoted.  Do it like this:
>
> sudo ktrace /bin/sh -c "echo 1 > /path/to/file"
> sudo kdump
> sudo dtrace -i 'fbt:::return /arg1 == 45/ {trace(".")}' -c "/bin/sh -c
> 'echo 1 > /path/to/file/'"
>
> The dtrace command will show you which function returned EOPNOTSUPP.
> However, it will also show a lot of functions that coincidentally
> return 45 even though it's not an errno, and even functions that
> return void.
>
> -Alan


Thanks!

It seems, a single '>' will cause it to try to create the file (even
though it already exists) and that fails (kern_openat).


___
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: Weirdness when writing to pseudofs file

[Johannes Lundberg]

On 5/22/19 10:51 AM, Konstantin Belousov wrote:
> On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote:
>> Hi
>>
>> I'm fiddling with lindebugfs, which is based on pseudofs. When writing
>> to a file,
>>
>> this works: # echo  1 >> /path/to/file
>>
>> but this does not: # echo 1 > /path/to/file
>>
>> "Operation not supported." is returned before the pseudofs code is even
>> entered.
>>
>> Is this expected behavior? (if so, why?)
> Does the file exist ?
>
> Pseudofs does not implement VOP_CREATE(), which is reasonable.

Yes, it exists and my custom write function is receiving the call for
">>". (which is for example used by drm driver debugfs to do certain
things on demand by accepting write to a debugfs file)


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

Weirdness when writing to pseudofs file

[Johannes Lundberg]

Hi

I'm fiddling with lindebugfs, which is based on pseudofs. When writing
to a file,

this works: # echo  1 >> /path/to/file

but this does not: # echo 1 > /path/to/file

"Operation not supported." is returned before the pseudofs code is even
entered.

Is this expected behavior? (if so, why?)

Thanks in advance
/Johannes



___
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: Heads up for breaking drm update.

[Johannes Lundberg]

On 5/19/19 7:36 PM, Steve Kargl wrote:
> On Sun, May 19, 2019 at 02:50:54PM -0700, Johannes Lundberg wrote:
>> LinuxKPI in base have received a lot of updates recently for Linux 5.0,
>> a couple of them will break drm-current-kmod. So, as of r347973 you will
>> need drm-current-kmod 4.16.g20190519. Ports have been updated and new
>> packages should be available shortly.
>>
> If drm-current-kmod is broken, should I venture to ask
> about drm-stable-kmod and drm-legacy-kmod?

That's a very good question. Maybe I should have included more
information regarding what's not affected. The last series of commits
have been to LinuxKPI in -CURRENT. As such:

drm-kmod: Meta port, not relevant
drm-current-kmod: See original message
drm-fbsd11.2-kmod: Not affected by changes in -CURRENT
drm-fbsd12.0-kmod: Not affected by changes in -CURRENT
drm-legacy-kmod: Not affected by changes in LinuxKPI

drm-stable-kmod does not exist anymore. Stable drm kmod ports for other
than -CURRENT are more or less frozen in separate branches where they
only receive bug fixes (drm-fbsdxxx-kmod).

Hope that answers your questions.

/Johannes


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

Heads up for breaking drm update.

[Johannes Lundberg]

Hi

Cross posting to -current and -x11.

LinuxKPI in base have received a lot of updates recently for Linux 5.0,
a couple of them will break drm-current-kmod. So, as of r347973 you will
need drm-current-kmod 4.16.g20190519. Ports have been updated and new
packages should be available shortly.

A drm-???-kmod port for 5.0 drivers will be created as soon as we fixed
a pretty serious vm page cache memory leak (limited to 5.0 code in
ports). Once 5.0 is regarded stable, it will replace the 4.16 as default
for -CURRENT (and future 12.1) (rejoice Vega graphics users:))

Until then, feel free to test with r347973+ and
https://github.com/FreeBSDDesktop/kms-drm/tree/drm-v5.0

Cheers!

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

Rotating (efi) framebuffer

[Johannes Lundberg]

Hi

I have a Lenovo Ideapad where the screen is rotated 90 degrees and I
can't rotate it to landscape mode until I'm in X. How many of you are in
the same situation and would like a fix? Seeing how development is going
with small (tiny) computers it will probably be more and more common
with ultra portables having a "phone screen" which most likely is in
portrait mode by default. This also applies to embedded and home brew /
prototype devices.

It would certainly be nice if we could have a boot time parameter that
could rotate the framebuffer (just as a data point, I'm pretty sure
Linux can do this). How many would be interested in this? Is there
anyone working on this atm? Not sure I will have the time to develop
this all of my own but thought I'd check the interest at least. Perhaps
a GSoC project?

Cheers
Johannes


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

RTL8821CU USB WiFi

[Johannes Lundberg]

Hi

Is anyone working on adding support for RTL8811CU & RTL8821CU chipsets? 


___
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: SVN r346645 breaks build of DRM drivers

[Johannes Lundberg]

Hi

Sorry about that. Github has been updated to workaround this
https://github.com/FreeBSDDesktop/kms-drm (default branch =
drm-current-kmod)

The port will be updated asap.

/Johannes


On 4/24/19 8:03 PM, Michael Butler wrote:
> The removal of dma_mask (around line 105) in
> /usr/src/sys/compat/linuxkpi/common/include/linux/device.h breaks the
> DRM loadable modules :-(
>
> As follows ..
>
> --- amdgpu_amdkfd.o ---
> /usr/ports/graphics/drm-current-kmod/work/kms-drm-068d6be/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:284:37:
> error: no member named 'dma_mask' in 'struct device'
> uint64_t address_mask = adev->dev->dma_mask ?
> ~*adev->dev->dma_mask :
> ~  ^
> /usr/ports/graphics/drm-current-kmod/work/kms-drm-068d6be/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:284:61:
> error: no member named 'dma_mask' in 'struct device'
> uint64_t address_mask = adev->dev->dma_mask ?
> ~*adev->dev->dma_mask :
> ~  ^
> 2 errors generated.
>
>   imb
> ___
> 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: Switching fb backend back to default

[Johannes Lundberg]

On Mon, Mar 18, 2019 at 19:48 Oliver Pinter 
wrote:

>
>
> On Sunday, March 17, 2019, Johannes Lundberg  wrote:
>
>> On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot 
>> wrote:
>>
>> > On Sun, 17 Mar 2019 16:32:43 +
>> > Johannes Lundberg  wrote:
>> >
>> > >
>> > > On 3/17/19 3:34 PM, Greg V wrote:
>> > > >
>> > > >
>> > > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg
>> > > >  wrote:
>> > > >> Hi
>> > > >>
>> > > >> I'm working on making i915kms unload properly. I've come to what I
>> > think
>> > > >> is the last issue. The drm driver unloads ok, the "efifb" backend
>> is
>> > > >> restored (according to logs) and vt_efifb_init() is being called
>> but
>> > the
>> > > >> screen (laptop built in display) stays black. The system seems
>> > > >> operational otherwise. If I load i915kms again in this state I get
>> > back
>> > > >> a visible (i915kms) framebuffer.
>> > > >>
>> > > >> Did we ever have this working so it's known to work?
>> > > >
>> > > > Recently on the linux kernel mailing list:
>> > > >
>> > > > http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html
>> > > >
>> > > > > Of course, once native drivers like i915 or radeon take over,
>> such a
>> > > > framebuffer is toast... [6]
>> > > >
>> > > > > [6]
>> > linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb()
>> > > > > linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe()
>> > > >
>> > > > So it seems like efifb is not supposed to work after a driver has
>> been
>> > > > loaded at least once.
>> > > >
>> > > >
>> > > Hmm, well the code is there to handle switching back to the boot time
>> > > fb. What I think is happening is that i915 powers off the displays at
>> > > unload and vt doesn't know how to power on (or that it should).
>> > >
>> >
>> >  That and if the display pipeline is de-configured or the resolution
>> > changed you cannot reset it to the original state.
>> >  Unloading drm modules is only useful for testing (and finding leaks).
>>
>>
>> Yeah a normal user would never unload it. Since I mostly ssh to my test
>> machines I think I’m fine personally with losing the display while
>> unloading.
>>
>> Keyboard input still works though and at least it doesn’t crash anymore :)
>
>
>
>  As workaround, can't you turn on the display with intel_backlight?
>

AFAIK, that can only adjust brightness. The display panel is completely
shut off.


>>
>> >
>> > >
>> > > ___
>> > > 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"
>> >
>> >
>> > --
>> > Emmanuel Vadot  
>> >
>> ___
>> 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: Switching fb backend back to default

[Johannes Lundberg]

On Mon, Mar 18, 2019 at 19:28 Pete Wright  wrote:

>
>
> On 3/17/19 2:50 PM, Johannes Lundberg wrote:
> > On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot 
> wrote:
> >
> >> On Sun, 17 Mar 2019 16:32:43 +
> >> Johannes Lundberg  wrote:
> >>
> >>> On 3/17/19 3:34 PM, Greg V wrote:
> >>>>
> >>>> On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg
> >>>>  wrote:
> >>>>> Hi
> >>>>>
> >>>>> I'm working on making i915kms unload properly. I've come to what I
> >> think
> >>>>> is the last issue. The drm driver unloads ok, the "efifb" backend is
> >>>>> restored (according to logs) and vt_efifb_init() is being called but
> >> the
> >>>>> screen (laptop built in display) stays black. The system seems
> >>>>> operational otherwise. If I load i915kms again in this state I get
> >> back
> >>>>> a visible (i915kms) framebuffer.
> >>>>>
> >>>>> Did we ever have this working so it's known to work?
> >>>> Recently on the linux kernel mailing list:
> >>>>
> >>>> http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html
> >>>>
> >>>>> Of course, once native drivers like i915 or radeon take over, such a
> >>>> framebuffer is toast... [6]
> >>>>
> >>>>> [6]
> >> linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb()
> >>>>> linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe()
> >>>> So it seems like efifb is not supposed to work after a driver has been
> >>>> loaded at least once.
> >>>>
> >>>>
> >>> Hmm, well the code is there to handle switching back to the boot time
> >>> fb. What I think is happening is that i915 powers off the displays at
> >>> unload and vt doesn't know how to power on (or that it should).
> >>>
> >>   That and if the display pipeline is de-configured or the resolution
> >> changed you cannot reset it to the original state.
> >>   Unloading drm modules is only useful for testing (and finding leaks).
> >
> > Yeah a normal user would never unload it. Since I mostly ssh to my test
> > machines I think I’m fine personally with losing the display while
> > unloading.
> >
> > Keyboard input still works though and at least it doesn’t crash anymore
> :)
> >
>
> that's awesome, so in theory we will be able to upgrade the drm-kmod and
> use the new driver without a reboot.  i like that as a hacker and
> end-user


You probably have to exit X to unload the driver so I’m not sure it’s that
much better than a reboot :) Either way, it will make simple testing a lot
easier.


>
> -pete
>
> --
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA
>
>
___
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"

Use mic from headphone jack on freebsd laptop?

[Johannes Lundberg]

Hi

On my Dell laptop the output audio switches to the headphones
automatically when plugged in, however, the same does not seem to be
true for the mic. Is there any configuration magic that can be done to
use the headphone mic instead of the internal one?

Here's pin config:

hdaa0: Dumping AFG pins:
hdaa0: nid   0x    as seq device   conn  jack    loc    color   misc
hdaa0: 18 90a60140 4  0  Mic   Fixed Digital Internal   Unknown 1
hdaa0: Caps: IN
hdaa0: 19 4000 0  0  Line-out  None  Unknown 0x00   Unknown
0 DISA
hdaa0: Caps: IN
hdaa0: 20 90170110 1  0  Speaker   Fixed Analog  Internal   Unknown 1
hdaa0: Caps:    OUT    EAPD  Sense: 0x (disconnected)
hdaa0: 24 41f0 15 0  Speaker   None  1/8 Rear   Black  
1 DISA
hdaa0: Caps: IN VREF Sense: 0x (disconnected)
hdaa0: 25 41f0 15 0  Speaker   None  1/8 Rear   Black  
1 DISA
hdaa0: Caps: IN VREF Sense: 0x8000 (connected)
hdaa0: 26 41f0 15 0  Speaker   None  1/8 Rear   Black  
1 DISA
hdaa0: Caps: IN VREF Sense: 0x (disconnected)
hdaa0: 27 41f0 15 0  Speaker   None  1/8 Rear   Black  
1 DISA
hdaa0: Caps: IN OUT    EAPD VREF Sense: 0x (disconnected)
hdaa0: 30 421212f2 15 2  Speaker   None  1/4 Front  Black  
2 DISA
hdaa0: Caps:    OUT  Sense: 0x (disconnected)
hdaa0: 33 0221101f 1  15 Headphones    Jack  1/8 Front  Black   0
hdaa0: Caps:    OUT HP EAPD  Sense: 0x8000 (connected)
hdaa0: NumGPIO=3 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1
hdaa0:  GPIO0: disabled
hdaa0:  GPIO1: disabled
hdaa0:  GPIO2: disabled
hdaa1: Dumping AFG pins:
hdaa1: nid   0x    as seq device   conn  jack    loc    color   misc
hdaa1:  3 18560010 1  0  Digital-out   Jack  Digital 0x18   Unknown 0
hdaa1: Caps:    OUT hdac0: Command timeout on address 2
 Sense: 0x (connected, ELD valid)
hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0

And in /boot/loader.conf I have this (don't remember why I put it there
or if I need it - it might have been copied over from previous laptop)

hint.hdaa.0.nid33.config="as=1 seq=15 device=Headphones"

I'm assuming here that the headphone jack supports mic - it's a 2018
laptop after all.

Cheers

/Johannes


___
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: Switching fb backend back to default

[Johannes Lundberg]

On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot  wrote:

> On Sun, 17 Mar 2019 16:32:43 +
> Johannes Lundberg  wrote:
>
> >
> > On 3/17/19 3:34 PM, Greg V wrote:
> > >
> > >
> > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg
> > >  wrote:
> > >> Hi
> > >>
> > >> I'm working on making i915kms unload properly. I've come to what I
> think
> > >> is the last issue. The drm driver unloads ok, the "efifb" backend is
> > >> restored (according to logs) and vt_efifb_init() is being called but
> the
> > >> screen (laptop built in display) stays black. The system seems
> > >> operational otherwise. If I load i915kms again in this state I get
> back
> > >> a visible (i915kms) framebuffer.
> > >>
> > >> Did we ever have this working so it's known to work?
> > >
> > > Recently on the linux kernel mailing list:
> > >
> > > http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html
> > >
> > > > Of course, once native drivers like i915 or radeon take over, such a
> > > framebuffer is toast... [6]
> > >
> > > > [6]
> linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb()
> > > > linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe()
> > >
> > > So it seems like efifb is not supposed to work after a driver has been
> > > loaded at least once.
> > >
> > >
> > Hmm, well the code is there to handle switching back to the boot time
> > fb. What I think is happening is that i915 powers off the displays at
> > unload and vt doesn't know how to power on (or that it should).
> >
>
>  That and if the display pipeline is de-configured or the resolution
> changed you cannot reset it to the original state.
>  Unloading drm modules is only useful for testing (and finding leaks).


Yeah a normal user would never unload it. Since I mostly ssh to my test
machines I think I’m fine personally with losing the display while
unloading.

Keyboard input still works though and at least it doesn’t crash anymore :)


>
> >
> > ___
> > 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"
>
>
> --
> Emmanuel Vadot  
>
___
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: Switching fb backend back to default

[Johannes Lundberg]

On 3/17/19 3:34 PM, Greg V wrote:
>
>
> On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg
>  wrote:
>> Hi
>>
>> I'm working on making i915kms unload properly. I've come to what I think
>> is the last issue. The drm driver unloads ok, the "efifb" backend is
>> restored (according to logs) and vt_efifb_init() is being called but the
>> screen (laptop built in display) stays black. The system seems
>> operational otherwise. If I load i915kms again in this state I get back
>> a visible (i915kms) framebuffer.
>>
>> Did we ever have this working so it's known to work?
>
> Recently on the linux kernel mailing list:
>
> http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html
>
> > Of course, once native drivers like i915 or radeon take over, such a
> framebuffer is toast... [6]
>
> > [6] linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb()
> > linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe()
>
> So it seems like efifb is not supposed to work after a driver has been
> loaded at least once.
>
>
Hmm, well the code is there to handle switching back to the boot time
fb. What I think is happening is that i915 powers off the displays at
unload and vt doesn't know how to power on (or that it should).



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

Switching fb backend back to default

[Johannes Lundberg]

Hi

I'm working on making i915kms unload properly. I've come to what I think
is the last issue. The drm driver unloads ok, the "efifb" backend is
restored (according to logs) and vt_efifb_init() is being called but the
screen (laptop built in display) stays black. The system seems
operational otherwise. If I load i915kms again in this state I get back
a visible (i915kms) framebuffer.

Did we ever have this working so it's known to work?

Cheers

/Johannes



___
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: What is evdev and autoloading?

[Johannes Lundberg]

On 2/19/19 5:35 PM, Steve Kargl wrote:
> On Tue, Feb 19, 2019 at 08:17:48AM -0800, Cy Schubert wrote:
>> On February 18, 2019 9:17:37 AM PST, Pete Wright  wrote:
>>>
>>> On 2/18/19 8:50 AM, Rodney W. Grimes wrote:
> On Mon, Feb 18, 2019 at 9:12 AM Rodney W. Grimes <
>
> I don't know. I think the fact that drm2 doesn't support anything
>>> newer
> than 5-year-old hardware is a pretty convincing evidence that the
>>> old way
> is broken and doesn't work.
 But it DOES work, I am pretty sure we have 1000's of users on that 5
>>> year
 old hardware that are totally happy with the intree DRM2 that is in
>>> stable/12,
 and some of whom have ventured into head/13 are having issues with
>>> thete a
 "new" model (ie kmod broken by a base commit).  I know that there is
>>> wip
 to get CI coverage for that, but wip is wip, and we need to start
>>> changing
 the cart horse driver order we keep doing and get things right.  Port
 up and working, with CI testing *before* we go remove kmod'ed code
>>> from
 base would be a much more appropriate path.

 I think one serious problem here is the summary dismissal of things
 simply on the "5 year old" basis.  Not everyone, and infact few now
 a days other than corporate buyers, can afford new hardware,
 giving the minimal performance increase in systems over the last 5
 years the cost/benifit factor of a new computer is just too low.
>>> I've put a lot of effort helping test and document how to get a usable 
>>> desktop environment on a modern laptop.  there were two issues which 
>>> motivated me to do this:
>>>
>>> 1) my observation that many developers at conferences and online were 
>>> using macOS as their primary desktop environment.  when comparing this 
>>> to the OpenBSD and Linux community I felt pretty embarrassed, but it
>>> did 
>>> explain the stagnant nature of our graphics subsystem.  people seemed 
>>> afraid to touch things due the brittle nature of its hardware support.
>> I noticed this too. And every time it struck me as odd.
>>
>>> 2) i was in need to an *affordable* machine with a warranty.
>>> fortunately 
>>> there are many affordable laptops at staples, best-buy and amazon - but
>>>
>>> they were all post haswell systems, rendering them basically useless 
>> >from a FreeBSD perspective.
>>
>> Which is why removing drm2 was necessary. 
>>
>>> after trying to get traction to update the in-tree drm subsystem i was 
>>> lucky enough to sync up with the graphics team which was working on 
>>> syncing things up with modern hardware support.  because of that i'm
>>> now 
>>> able to get my small startup pretty much all on board with FreeBSD.  i 
>>> use it on my workstations as well as on or server infrastructure 
>>> (physical and AWS).  i would consider this a success for our community 
>>> as it's opened up the eyes to a whole new generation of devs to
>>> FreeBSD.
>>>
>>> one thing missing from all of these arguments is real data.  how many 
>>> people are on haswell era hardware?  i can tell from my experience the 
>>> past several years the number of people who have post-haswell gear seem
>>>
>>> to be more numerous, or at least more vocal (and frankly easier to work
>>>
>>> with while squashing bugs).
>>>
>>> i can also say that personally it would be great to improve support for
>>>
>>> systems requiring drm2 - but that gear is hard to come by, so we are 
>>> really dependent on helpful collaboration from those who are being
>>> effected.
>> Drm2 is not required. My current laptop is 5 years old, an HD3000. The 
>> previous one is 13 years old, i915. Both work perfectly with drm-current on 
>> 13-current. Franky, I don't see what the fuss is about.
>>
>>
> My Dell Latitude D530 running i386 freebsd, which used the
> i915kms.ko now locks up solid with drm-legacy-kmod.  The PAE vs
> non-PAE i386/conf/pmap.h merger in r342567 broke drm-legacy-kmod.
> It seems that Niclas has provided a patch that fixes the building
> of drm-legacy-kmod.
>
> Doing a bisection on /usr/src commits is fairly slow as it
> takes a day to build world/kernel and the minimum set of ports
> need to fire up Xorg.  r343543 and earlier appear to work fine
> with drm-legacy-kmod.

So it's not only a build error, it's also a runtime bug that would have
happened even with drm2 in base? Hmm..

>
> I have now lost 2 weeks of hacking time that could have been spent
> on the missing C99 complex math routines.

Yeah it sucks when you have to get your hands dirty and actually
contribute yourself to keep the code you use alive and no one else does
it for you... How many hours do you think we have lost dealing with all
the whining and complaining on the mailing list where we instead could
have done productive work?

>   Yeah, I know very few
> people care about numerical simulations on FreeBSD. 
>

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailma

Re: What is evdev and autoloading?

[Johannes Lundberg]

On 2/18/19 10:54 PM, Mark Linimon wrote:
> On Mon, Feb 18, 2019 at 08:50:27AM -0800, Rodney W. Grimes wrote:
>> I think one serious problem here is the summary dismissal of things
>> simply on the "5 year old" basis.
> IIUC the graphics changes are being forced upon FreeBSD by external
> projects (mainly Linux-based) that are making huge architectural changes
> that rely more and more on features from newer hardware.
>
> If our upstreams aren't willing to do the work to keep from violating
> POLA on older hardware, IMHO it's an awful lot to ask of our already
> thinly stretched graphics volunteers to provide it in their stead.
>
> w/rt graphics, we are at far more danger of being left further and
> further behind on modern hardware than we are at risk of losing users
> on older hardware here.

This! Especially, support for modern laptops is important. Personally, I
don't know many developers who use a desktop PC these days (but I do
respect the fact that many do - old PCs as well). My laptop builds world
in 1h30m which is pretty decent. I don't feel a need at all for desktop
computer and I don't want to trade away the freedom of bringing my
laptop with me anywhere for work.

When it comes to attracting new developers, modern laptop support also
plays an important role. Without new developers coming in, this project
will fade out and die.

Another side of graphics which isn't discussed at all is GPU computing
using technologies like Radeon Open Compute, made possible by the amdgpu
driver with KFD (porting work in progress but not a priority atm).
i915kms has GVT for virtualization of the GPU (porting initialized).
These are pretty serious technologies that could potentially lead to
good business (which is now lost to Linux). Modern graphics support
isn't all about fancy desktops and spinning gears. 

Totally outside the topic of this thread but I felt like ranting a bit

PS, if anyone want to help develop an iommu driver for amdkfd, please
let us know :)

Cheers!

> Again all IMHO.
>
> disclaimer: I don't use any fancy graphics stuff, so (as the old folks
> say around here) "I have no dog in this hunt".
>
> mcl
> ___
> 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: What is evdev and autoloading?

[Johannes Lundberg]

On 2/19/19 12:37 AM, Warner Losh wrote:
> On Mon, Feb 18, 2019 at 9:50 AM Steve Kargl <
> s...@troutmask.apl.washington.edu> wrote:
>
>> On Mon, Feb 18, 2019 at 09:11:14AM -0700, Warner Losh wrote:
>>> You do know these constant complaints about people trying to make things
>>> better is demoralizing and counter productive.
>>>
>> You do realize some of the emails are from frustrated users
>> who are trying to make FreeBSD (see for example libm).
>>
> Yes. I get that. My frustration isn't with you, or your questions. I get
> why you want to run -current. I'm sorry it's being painful for you.
> Sometimes, -current is like that.

When this happens, there's always vesa and scfb (software rendering) to
fall back to so your machine won't be rendered useless. Not saying this
should be the norm, but good to know so that your work get minimal
interruption. Alternatively, run experimental kernels/worlds in bhyve
(what I tend to do when I want everything accessible on the same local
machine).


>
> Warner
> ___
> 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: What is evdev and autoloading?

[Johannes Lundberg]

On 2/18/19 3:12 PM, Rodney W. Grimes wrote:
>> On 2/18/19 12:06 PM, Stefan Blachmann wrote:
>>> On 2/18/19, Vladimir Kondratyev  wrote:
 On 2019-02-17 21:03, Steve Kargl wrote:
> Anyone have insight into what evdev is?
 evdev.ko is a small in-kernel library that makes all your input events
 like keyboard presses libinput-compatible.
>>> And libinput was created by the Freedesktop Wayland team to create
>>> pressure on OS people to make their systems Wayland-compatible.
>>>
> I do not need nor what these modules loaded.
 I think removing "option EVDEV_SUPPORT" from your kernel config should
 disable most of evdev.ko dependencies
>>> Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
>>> as libinput not be part of the standard packages?
>>>
>>> The Freedesktop Wayland team consists of people with the Kay Sievers
>>> mentality, which made Linus Torvalds ban his contributions. They do
>>> not care about the bugs they introduce, forcing others to clean up the
>>> mess they create.
>>>
>>> I'd be glad if FreeBSD would keep clean of following that Wayland fad...
>> EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve 
>> input device handling in X and Wayland.  Not having it means that a lot 
>> of input devices stop working, or work much worse.
>>
>> We in the FreeBSD Graphics Team are working very hard to improve the 
>> FreeBSD Desktop experience, since it is an avenue to recruit new users, 
>> and make current users use FreeBSD more.
> Sadly your execution on that seems to be missing the mark,
> telling people they have to go get a port now to get drm working
> because it could not be maintained in base, and then telling them,
> oh, you need this new code in base so that it is so much easier
> to use graphical stuff this way.
>
> These seem to be conflicting stories.

You don't need evdev or libinput to have a functional desktop with a
3-button mouse but some modern desktop environments require it. Why
should we not include the large group of people who want to run a modern
desktop? Including more users does not mean excluding anyone in this case.


>
>> Evdev and libinput is used by both Wayland and xorg.  You are free to 
>> use either one.
> And sadly now must take action when no action was required before
> when using neither.

Take what action? If you don't need it, just don't use it. If you don't
want change, stay on older release. If you are a purist and want to
remove everything in the kernel you don't use, you probably already have
your custom kernel config, and you probably are a minority. Consider the
well-being, progress and future of the project and the community at
large instead of your ego.


>

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

Fwd: What is evdev and autoloading?

[Johannes Lundberg]

Missed to include current@


 Forwarded Message 
Subject:Re: What is evdev and autoloading?
Date:   Mon, 18 Feb 2019 12:02:50 +
From:   Johannes Lundberg 
To: freebsd-hack...@freebsd.org




On 2/18/19 11:06 AM, Stefan Blachmann wrote:
> On 2/18/19, Vladimir Kondratyev  wrote:
>> On 2019-02-17 21:03, Steve Kargl wrote:
>>> Anyone have insight into what evdev is?
>> evdev.ko is a small in-kernel library that makes all your input events
>> like keyboard presses libinput-compatible.
> And libinput was created by the Freedesktop Wayland team to create
> pressure on OS people to make their systems Wayland-compatible.
>
>>> I do not need nor what these modules loaded.
>> I think removing "option EVDEV_SUPPORT" from your kernel config should
>> disable most of evdev.ko dependencies
> Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
> as libinput not be part of the standard packages?

Evdev with libinput provide things like, multitouch gestures, horizontal
scrolling, touchpad support, etc, i.e. functionality that one might
expect from a laptop or desktop computer newer than 10 years,  also for X11.

Having it enabled by default doesn't force you to use it but it makes it
a whole lot easier for all of those who want to use it. Please try to
consider what is the best middle ground for ALL users. If you have a
special application for FreeBSD you're probably building your own kernel
anyway and it is easy to disable if needed. Most normal (and especially
new to FreeBSD) desktop/laptop users use stock kernel and would benefit
from having access to this functionality.

Cheers

> The Freedesktop Wayland team consists of people with the Kay Sievers
> mentality, which made Linus Torvalds ban his contributions. They do
> not care about the bugs they introduce, forcing others to clean up the
> mess they create.
>
> I'd be glad if FreeBSD would keep clean of following that Wayland fad...
> ___
> freebsd-hack...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-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: drm2 removed?

[Johannes Lundberg]

On 2/11/19 4:23 PM, Niclas Zeising wrote:
> On 2/11/19 5:20 PM, Steve Kargl wrote:
>> On Mon, Feb 11, 2019 at 08:12:05AM -0800, Steve Kargl wrote:
>>> Anyone have any idea which recent change broke the
>>> drm-legacy-kmod port.  This is why I raised an issue
>>> with removal of drm2 from src/sys.  How is suppose
>>> to be fixed?
>>>
>>
>> It was r343567.  The merging of PAE and NO PAE pmap.h
>> by kib removed all of the missing macros. :(
>>
>
> The code is still in base, but disabled by default.  I have to have a
> look at this, but it might take a couple of days before we have a fix.
> Regards


Commit from 12 days ago and we get the news now... Any progress on the
CI for drm modules?

___
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: axp288 on Intel HW

[Johannes Lundberg]

On Fri, Nov 16, 2018 at 5:11 PM John Baldwin  wrote:

> On 11/16/18 12:51 AM, Johannes Lundberg wrote:
> > Hi
> >
> > I have a Lenovo Ideapad Miix 310 that has a Intel CherryTrail CPU and it
> > runs FreeBSD quite nicely (with accelerated graphics). What I'm missing
> is
> > battery life status..
> >
> > I can get this information using smb (for some reason i2c just returns
> > error sending start condition)
> > smbmsg -f /dev/smb6 -s 0x68 -c 0xB9 -i 1 -F %d
> >
> > In emergency this works but it would be nice to have a kernel driver for
> > it.
> >
> > I found the axp2xx driver for Allwinner in the tree. Would it be possible
> > to share this with amd64 with not too much effort?
> >
> > If not, all I'm really interested in is battery status so I might just
> hack
> > together a simple driver for that report values to hw.acpi.battery
> (because
> > I don't think there is a sysctl for battery info that aggregates
> different
> > sources?)
> >
> > Datasheet for the pmic can be found here
> > http://download.bbs.ickey.cn/201707/cfe88ee7ef01eed7a4586ce340165da0.pdf
>
> Have you looked to see why ACPI isn't reporting battery status?  Maybe we
> need to be invoking some specific method like DSM or OSC before your
> battery
> devices work?  Maybe your battery devices don't have a _STA method and you
> need the change in
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191?
>

On Linux the axp288 driver is needed to make this happen so I haven't
considered any other options.

https://www.normalesup.org/~george/comp/linux_lenovo_miix3/#s_7_9


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

axp288 on Intel HW

[Johannes Lundberg]

Hi

I have a Lenovo Ideapad Miix 310 that has a Intel CherryTrail CPU and it
runs FreeBSD quite nicely (with accelerated graphics). What I'm missing is
battery life status..

I can get this information using smb (for some reason i2c just returns
error sending start condition)
smbmsg -f /dev/smb6 -s 0x68 -c 0xB9 -i 1 -F %d

In emergency this works but it would be nice to have a kernel driver for
it.

I found the axp2xx driver for Allwinner in the tree. Would it be possible
to share this with amd64 with not too much effort?

If not, all I'm really interested in is battery status so I might just hack
together a simple driver for that report values to hw.acpi.battery (because
I don't think there is a sysctl for battery info that aggregates different
sources?)

Datasheet for the pmic can be found here
http://download.bbs.ickey.cn/201707/cfe88ee7ef01eed7a4586ce340165da0.pdf

Cheers
___
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: Graphics open-source-friendliness, AMD Ryzen vs. Intel

[Johannes Lundberg]

On Mon, Nov 12, 2018 at 2:04 AM Johannes Dieterich 
wrote:

> On Sun, Nov 11, 2018 at 4:48 PM Johannes Lundberg 
> wrote:
> >
> > I have an AMD Ryzen 3 2200G (with Vega graphics) and it panics all the
> time
> > with references to various memory access errors (use after free among
> > other).
> >
> > Ubuntu is also unstable on this machine but Windows 10 works well after a
> > windows update (I had to reinstall the previous motherboard with older
> cpu
> > to be able to run Windows update without crash...)
> >
> > From my experience, stay away from this CPU.
> To put this a little into perspective: the R3 2200G is part of the
> most recent AMD APU generation and contains the most recent Vega
> graphics IP ("Vega 8"). It was officially released only in February of
> this year. The most recent DRM in ports is 4.16, which itself was
> released only in April. Problems with the 2200G on "older" Linux
> releases are unfortunately well known. However, kernel 4.18 with
> latest firmwares and BIOSs is documented to be stable on this platform
> (see phoronix, Ubuntu 18.10 "benchmark").
>

This is not related to graphics. It's just generally very unstable. I could
reproduce zfs uma related panics by scp'ing files to this machine.
Often I get panics in very early boot as well.

I have all the latest HEAD, ports and microcode updates...

Either it's just too soon to run FreeBSD on this CPU (which is why I don't
recommend it yet) or,
I have a bad CPU and/or memory (but given that Windows 10 runs fine this
seems unlikely)...

Configuration:
ASRock A320M-HDV
<https://www.amazon.co.uk/gp/product/B06XD6SYKD/ref=oh_aui_detailpage_o07_s01?ie=UTF8&psc=1>
QUMOX 4GB DDR4 2133 2133MHz PC4-17000 PC-17000 (288 PIN) DIMM MEMORY 4GB
AMD YD2200C5FBBOX Ryzen 3 2200G CPU with Wraith Stealth Cooler and RX Vega
Graphics


> Johannes
>
> > On Sun, Nov 11, 2018 at 18:57 Allan Jude  wrote:
> >
> > > On 2018-11-11 12:54, Greg V wrote:
> > > >
> > > >
> > > > On Sun, Nov 11, 2018 at 3:42 PM, Thomas Mueller  >
> > > > wrote:
> > > >> I may need to buy parts for a new computer because of malfunctions
> on
> > > >> current motherboard and CPU (Intel Sandy Bridge dating to May 2011).
> > > >>
> > > >> Question is whether I am better off, regarding
> > > >> open-source-friendliness of graphics chips for running Xorg, with
> AMD
> > > >> Ryzen or the newer Intel chipsets.  I know to avoid NVIDIA.
> > > >
> > >
> > > My FreeBSD workstation use an nVidia Quadro K1200 and it works very
> well
> > > under FreeBSD with the nVidia kernel driver from ports.
> > >
> > > > Both are great for open source friendliness in general.
> > > >
> > > > Onboard Vega GPUs on the Ryzen APUs should work fine on FreeBSD with
> > > > kms-drm 4.16.
> > > >
> > > > If you're looking for high performance though, don't get an APU, get
> an
> > > > 8-core (R7 2700X/2700/1700X/1700) and a discrete GPU (Radeon RX
> > > > 550/560/570/580 depending on how much you care about graphics
> > > performance).
> > > >
> > > >> I am inclined to run FreeBSD-current and build Xorg from FreeBSD
> ports.
> > > >>
> > > >> When I boot into UEFI setup, I see the CPU temperature is or quickly
> > > >> goes to 97 C and stays there.
> > > >>
> > > >> I tried replacing the thermal paste and installing a new case fan to
> > > >> replace one that had quit, but CPU temperature still shows and stays
> > > >> at 97 C.
> > > >>
> > > >> Now I have a replacement Arctic Cooler heatsink and fan on order to
> > > >> replace the original Intel heatsink and fan whose connectors were
> > > >> damaged in taking out and struggling to get back in.
> > > >>
> > > >> Currently, I boot into UEFI Setup, but after a couple minutes, the
> > > >> computer powers off and then tries to power back on, then off again
> a
> > > >> few seconds later, until I end the loop by turning off the power
> > > >> supply switch.  I can guess CPU overheating.
> > > >
> > > > Yeah, a new CPU cooler should help.
> > > >
> > > >> I could transplant the current hard drive (Seagate NAS 4 TB) to get
> a
> > > >> quicker start software-wise.
> > > >
> > > > An SSD might provide a quicker start too ;)
> > > >
> > > > ___
> > > > 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"
> > >
> > >
> > > --
> > > Allan Jude
> > >
> > >
> > ___
> > 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: Graphics open-source-friendliness, AMD Ryzen vs. Intel

[Johannes Lundberg]

I have an AMD Ryzen 3 2200G (with Vega graphics) and it panics all the time
with references to various memory access errors (use after free among
other).

Ubuntu is also unstable on this machine but Windows 10 works well after a
windows update (I had to reinstall the previous motherboard with older cpu
to be able to run Windows update without crash...)

>From my experience, stay away from this CPU.

On Sun, Nov 11, 2018 at 18:57 Allan Jude  wrote:

> On 2018-11-11 12:54, Greg V wrote:
> >
> >
> > On Sun, Nov 11, 2018 at 3:42 PM, Thomas Mueller 
> > wrote:
> >> I may need to buy parts for a new computer because of malfunctions on
> >> current motherboard and CPU (Intel Sandy Bridge dating to May 2011).
> >>
> >> Question is whether I am better off, regarding
> >> open-source-friendliness of graphics chips for running Xorg, with AMD
> >> Ryzen or the newer Intel chipsets.  I know to avoid NVIDIA.
> >
>
> My FreeBSD workstation use an nVidia Quadro K1200 and it works very well
> under FreeBSD with the nVidia kernel driver from ports.
>
> > Both are great for open source friendliness in general.
> >
> > Onboard Vega GPUs on the Ryzen APUs should work fine on FreeBSD with
> > kms-drm 4.16.
> >
> > If you're looking for high performance though, don't get an APU, get an
> > 8-core (R7 2700X/2700/1700X/1700) and a discrete GPU (Radeon RX
> > 550/560/570/580 depending on how much you care about graphics
> performance).
> >
> >> I am inclined to run FreeBSD-current and build Xorg from FreeBSD ports.
> >>
> >> When I boot into UEFI setup, I see the CPU temperature is or quickly
> >> goes to 97 C and stays there.
> >>
> >> I tried replacing the thermal paste and installing a new case fan to
> >> replace one that had quit, but CPU temperature still shows and stays
> >> at 97 C.
> >>
> >> Now I have a replacement Arctic Cooler heatsink and fan on order to
> >> replace the original Intel heatsink and fan whose connectors were
> >> damaged in taking out and struggling to get back in.
> >>
> >> Currently, I boot into UEFI Setup, but after a couple minutes, the
> >> computer powers off and then tries to power back on, then off again a
> >> few seconds later, until I end the loop by turning off the power
> >> supply switch.  I can guess CPU overheating.
> >
> > Yeah, a new CPU cooler should help.
> >
> >> I could transplant the current hard drive (Seagate NAS 4 TB) to get a
> >> quicker start software-wise.
> >
> > An SSD might provide a quicker start too ;)
> >
> > ___
> > 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"
>
>
> --
> Allan Jude
>
>
___
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: drm changes and updating to 12.0

[Johannes Lundberg]

On Mon, Nov 5, 2018 at 10:05 PM Carsten Mattner 
wrote:

> On Mon, Nov 5, 2018 at 7:00 PM Johannes Lundberg 
> wrote:
>
> > Which Linux version is tracked is listed in the port info.
> > drm-stable-kmod is currently at Linux 4.9
> > drm-devel-kmod is currently at Linux 4.16
>
> This is very useful to know. I can't find the Linux kernel version in
> drm-legacy-kmod metadata. Is it a mix of different kernel releases?
>

According to the old, abandoned wiki page it seems to be Linux 3.8.
(zeising: we should add this info to drm-legacy)
https://wiki.freebsd.org/Graphics

That was developed by the previous graphics team with all different members
(for the kernel drivers) so to be honest I don't know much details about
the old drm code.
___
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: drm changes and updating to 12.0

[Johannes Lundberg]

On Mon, Nov 5, 2018 at 5:27 PM Robert Huff  wrote:

>
> Warner Losh writes:
>
> >  I'm curious where 2013 comes from. I know that Intel Sandy Bridge
> graphics
> >  is supported with VAAPI acceleration by drm-stable-kmod, since it i
> working
> >  on the system I am using to send this message. I bought it in 2011,
> the
> >  year Sandy Bridge was introduced to production products.
> >
> >  2013 is "five year old hardware or newer". It's a number I pulled out
> of the
> >  air when trying to nail down the group in describing who should use
> what.
> >  Giving code names would also work. Sandy Bridge and newer, though, is
> confusing
> >  to people.  I'd use 2011 as the release date for Sandy Bridge, but then
> what
> >  about the AMD other GPUs?
> >
> >  If there's a better way to message what's supported, I'm all ears.
>
> Lacking a better plan: is there a list of which card/gpu is
> currently known to work with which drm(-kmod) version, perhaps
> gathered from those involved with development?  (Is this based on work
> from Linux? If so, do they have a list?)
>

Hi

Updating the wiki graphics pages is long overdue and we hope to have it
refreshed before the 12.0 release. Everything will be explained there in
detail together with some compatibility matrix.
This has probably been said many times on the mailing list but I feel
obligated to try to inform the best I can until we have updated the wiki.

The short version is that drm2 in base (/sys/dev/drm2/) have support for hw
up to 2013 (maybe 2014), that's why drm-legacy-kmod is said to support hw
up to that year.

Now, the linuxkpi based ones, drm-stable-kmod and drm-devel-kmod (I'm not
including drm-next-kmod because that will go away), potentially could work
on hw older than 2013. Initially they didn't but they have been patched to
potentially work on same hw as base drm2 but this is barely tested yet.

Recently, drm-devel-kmod was patched to work on i386 but this is also not
fully tested yet. So, theoretically, if you're running current,
drm-devel-kmod could run your 10 years old 32 bit computer's gpu but it's
too early to make any guarantees. Please feel free to test.

Usually the meta-port, drm-kmod, will choose the best (safest bet) for your
system.

Which Linux version is tracked is listed in the port info.
drm-stable-kmod is currently at Linux 4.9
drm-devel-kmod is currently at Linux 4.16

The best way is lookup what is supported by the Linux version (if anyone
know a good site, please share the link). If the hw is supported there, and
it's driven by i915, amdgpu or radeon, it should work on FreeBSD as well.

If you have any of the _really_ old cards supported by drm1 (what's in
/sys/dev/drm/), you'll always need drm-legacy-kmod.

We know this transition has been messy and confusing but we're working hard
to improve this.

/Johannes


>
>
> Respectfully,
>
>
> Robert Huff
>
> ___
> 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: is 4k desktop possible on freebsd-12?

[Johannes Lundberg]

On Thu, Oct 11, 2018 at 9:58 AM tech-lists  wrote:

> On 10/10/2018 15:24, Slawa Olhovchenkov wrote:
> > You need check HDMI 2.0 available on video card and monitor.
> > For HDMI 1.4 you need check of support both card and monitor support
> 4K@24.
>
> Yes, the card, cable and monitor are all capable of 4k@30fps. The cable
> and monitor were tested by connecting a laptop running linux mint. This
> gave a 4k display @ 30fps. So for some reason, the card (AMD RX580)
> isn't sending 4k.
>
> Is there a resource explaining how/can anyone tell me how to make the
> card send 4k? The xorg section of the handbook unfortunately hasn't been
> much help.
>
>
Do you have anything configured in /etc/X11/xorg.conf? If so, remove the
file and let X auto configure.
Otherwise try switching DDX driver, modesetting or amdgpu

/etc/X11/xorg.conf:

Section "Device"
Driver  "amdgpu"
EndSection

VS

Section "Device"
Driver  "modesetting"
EndSection


thanks,
> --
> J.
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-x11
> To unsubscribe, send any mail to "freebsd-x11-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: is 4k desktop possible on freebsd-12?

[Johannes Lundberg]

On Wed, Oct 10, 2018 at 11:18 AM tech-lists  wrote:

> Hi,
>
> I'm trying to get xorg to display 4k. The context is:
>
> FreeBSD 12.0-ALPHA8 r339084 amd64
> ports r481640
> AMD RX580 GPU
> Asus X99 Extreme3 mobo
> cpu: intel e5-2699v4
> 48GB RAM
> Samsung UE48JU6410U monitor connected via HDMI
>
> drm-next-kmod-4.11.g20180822
> libdrm-2.4.93,1
> xf86-video-amdgpu-18.1.0
> xf86-video-ati-18.1.0,1
> xf86-video-openchrome-0.6.0_3
> xf86-video-scfb-0.0.4_7
> xf86-video-vesa-2.4.0_2
> linux_base-c7-7.4.1708_6 and all its xorg/mesa libs
>
> /var/log/Xorg.0.log has this:
>
> [  3470.966] (II) AMDGPU(0): Printing probed modes for output HDMI-A-0
> [  3470.966] (II) AMDGPU(0): Modeline "1920x1080"x60.0  148.50  1920
> 2008 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
> [  3470.966] (II) AMDGPU(0): Modeline "1680x1050"x59.9  119.00  1680
> 1728 1760 1840  1050 1053 1059 1080 +hsync -vsync (64.7 kHz e)
> [  3470.966] (II) AMDGPU(0): Modeline "1600x900"x60.0  108.00  1600 1624
> 1704 1800  900 901 904 1000 +hsync +vsync (60.0 kHz e)
>
> but further along we have this:
>
> [  3474.097] (II) AMDGPU(0): EDID vendor "SAM", prod id 3140
> [  3474.097] (II) AMDGPU(0): Using EDID range info for horizontal sync
> [  3474.097] (II) AMDGPU(0): Using EDID range info for vertical refresh
> [  3474.097] (II) AMDGPU(0): Printing DDC gathered Modelines:
> [  3474.098] (II) AMDGPU(0): Modeline "3840x2160"x0.0  297.00  3840 4016
> 4104 4400  2160 2168 2178 2250 +hsync +vsync (67.5 kHz eP)
> [  3474.098] (II) AMDGPU(0): Modeline "1920x1080"x0.0  148.50  1920 2008
> 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
> [  3474.098] (II) AMDGPU(0): Modeline "800x600"x0.0   40.00  800 840 968
> 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
>
> and
>
> [  3474.211] (II) AMDGPU(0): Printing DDC gathered Modelines:
> [  3474.211] (II) AMDGPU(0): Modeline "3840x2160"x0.0  297.00  3840 4016
> 4104 4400  2160 2168 2178 2250 +hsync +vsync (67.5 kHz eP)
> [  3474.211] (II) AMDGPU(0): Modeline "1920x1080"x0.0  148.50  1920 2008
> 2052 2200  1080 1084 1089 1125 +hsync +vsync (67.5 kHz e)
> [  3474.211] (II) AMDGPU(0): Modeline "800x600"x0.0   40.00  800 840 968
> 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
>
> so would this indicate the card is 4k capable but the HDMI port on the
> card is not? Or the port on the monitor? Or something else?
>
>
Hi

What is the actual problem? Do you get any 4K modes listed when you run
'xrandr' ?
I've been running 4K@60FPS on an external display for a long time on my
Intel laptops. However, that requires DP output. Your HDMI output is most
likely limited to 30 FPS (but should still display 4K resolution...).

thanks,
>
> --
> J.
> ___
> 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: drm confusion / xorg / AMD RX580 GPU

[Johannes Lundberg]

On Mon, Oct 8, 2018 at 1:47 PM tech-lists  wrote:

> Hi,
>
> context: 12-alpha8, amd64, xorg, AMD rx580 card
>
> As per /usr/ports/UPDATING, I have installed graphics/drm-kmod which has
> installed drm-next-kmod-4.11.g20180822
>
> As per pkg message, it's loaded with this line in /etc/rc.conf:
>
> kld_list="amdgpu"
>
> But even though I get a graphical display, this shows in the X.org.0.log:
>
> [91.379] (II) LoadModule: "ati"
> [91.379] (II) Loading /usr/local/lib/xorg/modules/drivers/ati_drv.so
> [91.379] (II) Module ati: vendor="X.Org Foundation"
> [91.379]compiled for 1.18.4, module version = 18.1.0
> [91.379]Module class: X.Org Video Driver
> [91.379]ABI class: X.Org Video Driver, version 20.0
> [91.382] (II) LoadModule: "amdgpu"
> [91.383] (WW) Warning, couldn't open module amdgpu
> [91.383] (II) UnloadModule: "amdgpu"
> [91.383] (II) Unloading amdgpu
> [91.383] (EE) Failed to load module "amdgpu" (module does not exist, 0)
>
> $ kldstat
> Id Refs AddressSize Name
>  1   86 0x8020  13341b0 kernel
>  21 0x81536000   3ace18 zfs.ko
>  32 0x818e3000 a500 opensolaris.ko
>  41 0x81a22000   159978 amdgpu.ko
>  51 0x81b7c00075d70 drm.ko
>  64 0x81bf200010570 linuxkpi.ko
>  73 0x81c0300011300 linuxkpi_gplv2.ko
>  82 0x81c15000  6c0 debugfs.ko
>  91 0x81c16000 80db amdgpu_polaris10_mc_bin.ko
> 101 0x81c1f000 441d amdgpu_polaris10_pfp_bin.ko
> 111 0x81c24000 441b amdgpu_polaris10_me_bin.ko
> 121 0x81c29000 241b amdgpu_polaris10_ce_bin.ko
> 131 0x81c2c000 5d3d amdgpu_polaris10_rlc_bin.ko
> 141 0x81c320004042d amdgpu_polaris10_mec_bin.ko
> 151 0x81c730004042f amdgpu_polaris10_mec2_bin.ko
> 161 0x81cb4000 331f amdgpu_polaris10_sdma_bin.ko
> 171 0x81cb8000 3321 amdgpu_polaris10_sdma1_bin.ko
> 181 0x81cbc0005bbfd amdgpu_polaris10_uvd_bin.ko
> 191 0x81d1800028d1d amdgpu_polaris10_vce_bin.ko
> 201 0x81d410001fe51 amdgpu_polaris10_k_smc_bin.ko
> 211 0x81d61000 1800 uhid.ko
> 221 0x81d63000 2368 ums.ko
> 231 0x81d66000399d8 linux.ko
> 242 0x81da 2d98 linux_common.ko
> 251 0x81da300034008 linux64.ko
>
> Need to know:
>
> 1. is this the right/fastest/best driver for this card?
>
> 2. how can I tell if it's using all its capability?
>
> 3. I'd like this card to crunch with boinc. What determines if this is
> possible? is it freebsd, boinc, the card driver, the project boinc is on
> or something else?
>

Hi

Let me know if you manage to get GPU processing working. I haven't explored
the option so much but from what I've seen so far, there doesn't seem to be
much GPU work available for *nix systems. I'm also on WCG.

PS. A tip for not having your custom Linux-enabled boinc-client pkg
overwritten every time you run pkg upgrade, do 'pkg lock boinc-client' :)


> thanks,
> --
> J.
> ___
> 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: linux-c7 and opengl apps?

[Johannes Lundberg]

On Sat, Oct 6, 2018 at 1:39 PM Greg V  wrote:

>
>
> On Fri, Oct 5, 2018 at 11:21 PM, Theron  wrote:
> > % /compat/linux/opt/VirtualGL/bin/glxinfo | grep OpenGL
> > libGL error: MESA-LOADER: failed to retrieve device information
>
> Do you have linsysfs mounted?
>
> Try reading /compat/linux/sys/class/drm/card0/device/uevent.
>
> Mesa won't retrieve device information without linsysfs.
> I wrote the linsysfs patch that exposed the info there so that recent
> Mesa would work :)
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222375
> (Wow, that was a year ago… interesting note from there: you might
> need to set LIBGL_DRI3_DISABLE=1 for Linux apps)
>


Thank you Greg!  LIBGL_DRI3_DISABLE=1 was it for me! Now I can run OpenGL
apps with linux-c7 :)


>
> Also, what's with the "/opt/VirtualGL"? Are you using mesa from
> linux-c7 or something… weird?
>
> > This problem has existed forever.  I am not sure it is actually a
> > fault in Linux emulation, as these very same symptoms ("failed to
> > retrieve device information" message, console freeze) existed back in
> > FreeBSDDesktop/freebsd-base-graphics days when attempting to run
> > purely FreeBSD OpenGL apps.  At the time the workaround was a patch
> > to Mesa's GPU detection; the underlying kernel problem wasn't
> > addressed.
>
> There was a somewhat related issue (but not the same one, FreeBSD and
> Linux versions of mesa/libdrm use different mechanisms to get device
> info).
> Mostly affected Wayland-EGL clients — they would try to access
> /dev/dri/card408 instead of /dev/dri/card0, fail to get info and fall
> back to software rendering.
> I fixed it a while ago:
>
> https://gitlab.freedesktop.org/mesa/mesa/commit/db8519a369261cdedda50852facc45616d4eba28
>
> But I never saw console freezes when Mesa couldn't properly detect the
> GPU o_0
>
> ___
> 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: Radeon HD 7570M: drm: deep frustration with r339186

[Johannes Lundberg]

On Sat, Oct 6, 2018 at 7:19 AM Pete Wright  wrote:

>
> On 10/5/18 6:34 PM, Graham Perrin wrote:
> > On 23/09/2018 08:09, Graham Perrin wrote:
> >
> >> Re: Suspend, resume, UEFI, CSM, drm-stable-kmod and drm-next-kmod with
> Radeon HD 7570M
> >> … better without drm-next-kmod; and (as expected, given the package
> message) drm-stable-kmod has known problems with UEFI.
> > Now (with r339186) it seems that drm-next-kmod is the only usable option.
> >
> > However, I'm sorry to say:
> >
> > - it does feel regressive, compared to working without drm-next-kmod
> with earlier versions of -CURRENT.
> >
> > I can no longer find a way to reliably suspend (sleep) the notebook.
>
> hey Graham - I'm struggling with suspend/resume issues as well on my end
> with recent 12-ALPHA releases.  can you verify that you can
> suspend/resume without loading the radeonkms.ko (i believe that is what
> you are using for gfx)?  on my systems it's broken regardless if i load
> the drm modules.
>
> also, what was the last version of CURRENT you were able to
> suspend/resume with?
>
>
> > At the time of writing my part-working configuration is as outlined
> below.
> >
> > However – frustratingly – for a while, an hour or so ago, it seemed as
> if the same configuration was useless; after a point, the screen would go
> blank (grey) and things would progress no further e.g. no login manager
> (sddm); no response to Control-Alt-F2; no response to Control-Alt-Delete.
> The apparent unpredictability leading to a dead-end situation has created a
> sense of unease; now I'm genuinely afraid to test suspend :-(
>
> i believe johannes lundberg is working on a fix for this issue. i'm in
> the same uneasy situation as you.  the system i use for dogfooding is
> also my main work laptop, and not having suspend/resume and other
> instability like this is certainly not ideal.  one potential fix
> workaround we've found is to not load the module via "kld_list" but
> rather load it by hand via "kldload" manually.  i believe the bug is in
> relation to how the BIOS allocates memory - i'll let him fill in details :)
>

Hi

This kld_list issue is only for newer Intel and drm-devel.

Regarding instability with CURRENT. When something changes in CURRENT that
might affect the drm drivers there's always a delay until the drm-kmod
packages have been rebuilt against the new source. If you're frequently
updating your -CURRENT system, it's safest to build drm-kmod from source at
the same time. Either with ports or from the github repo. We're working on
trying to reduce this lag but to avoid it completely is impossible when
living in -CURRENT.


for me at least it looks like system instability when loading drm-next
> kernels is separate from suspend/resume.  but its certainly possible my
> laptop is a snowflake :p
>
> hope this helps.
>
> -pete
>
>
> --
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA
>
> ___
> 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: Sound issues with Dell Latitude 7490 (kabylake)

[Johannes Lundberg]

On Wed, Oct 3, 2018 at 2:30 PM Jakob Alvermark  wrote:

> On 10/3/18 3:06 PM, David Wolfskill wrote:
> > On Mon, Oct 01, 2018 at 11:12:25PM +0200, Jakob Alvermark wrote:
> >> 
> >> Do the headphones work with this patch?
> >>
> >> Index: sys/dev/sound/pci/hda/hdaa.c
> >> ===
> >> --- sys/dev/sound/pci/hda/hdaa.c(revision 339076)
> >> +++ sys/dev/sound/pci/hda/hdaa.c(working copy)
> >> @@ -5034,11 +5034,13 @@
> >>pincap = w->wclass.pin.cap;
> >>
> >>/* Disable everything. */
> >> +/*
> >>w->wclass.pin.ctrl &= ~(
> >>HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
> >>HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
> >>HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
> >>HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
> >> +*/
> >>
> >>if (w->enable == 0) {
> >>/* Pin is unused so left it disabled. */
> >> 
> > Thank you!  This addressed the long-standing (Reported:  2015-05-29
> > 21:15 UTC) issue I have had with my laptop (Dell Precision M4800), as
> > documented in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200526
> > -- now updated to reflect the fix.
>
>
> That's great! Glad to hear it helped.
>
> This is probably not a proper fix, but it helps to understand the problem.
>
> Could you post the output of 'sysctl dev.hdaa' with and without the
> patch so we can see what's different?
>
>
Hi Jakob

Here's my diff from orig to patched (full output zipped and attached)

johannes@jm:~ % diff -u -U5 tmp/dev_hdaa_0_orig.txt
tmp/dev_hdaa_0_patched.txt
--- tmp/dev_hdaa_0_orig.txt2018-10-03 14:32:31.264778000 +0100
+++ tmp/dev_hdaa_0_patched.txt2018-10-03 14:28:18.767561000 +0100
@@ -58,11 +58,11 @@
 dev.hdaa.0.nid30_config: 0x421212f2 as=15 seq=2 device=Speaker conn=None
ctype=1/4 loc=Front color=Black misc=2
 dev.hdaa.0.nid30: pin: Speaker (None) [DISABLED]
  Widget cap: 0x00400781 PWR DIGITAL UNSOL STEREO
 Pin cap: 0x0014 PDC OUT
  Pin config: 0x421212f2 as=15 seq=2 device=Speaker conn=None ctype=1/4
loc=Front color=Black misc=2
-Pin control: 0x
+Pin control: 0x0040 OUT
 Connections: 1
   + <- nid=6 [audio output] [DISABLED]

 dev.hdaa.0.nid29_original: 0x4071 as=0 seq=1 device=Modem-handset
conn=None ctype=Unknown loc=0x00 color=Unknown misc=0
 dev.hdaa.0.nid29_config: 0x4071 as=0 seq=1 device=Modem-handset
conn=None ctype=Unknown loc=0x00 color=Unknown misc=0
@@ -81,11 +81,11 @@
 dev.hdaa.0.nid27_config: 0x41f0 as=15 seq=0 device=Speaker conn=None
ctype=1/8 loc=Rear color=Black misc=1
 dev.hdaa.0.nid27: pin: Speaker (None) [DISABLED]
  Widget cap: 0x0040058f PWR UNSOL STEREO
 Pin cap: 0x00013734 PDC OUT IN VREF[ 50 80 100 GROUND HIZ ] EAPD
  Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None ctype=1/8
loc=Rear color=Black misc=1
-Pin control: 0x
+Pin control: 0x0020 IN
EAPD: 0x0002 EAPD
  Output amp: 0x8000 mute=1 step=0 size=0 offset=0 (0/0dB)
   Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)
 Connections: 2
   + [DISABLED] <- nid=2 [audio output] (selected)
@@ -104,20 +104,20 @@
 dev.hdaa.0.nid25_config: 0x41f0 as=15 seq=0 device=Speaker conn=None
ctype=1/8 loc=Rear color=Black misc=1
 dev.hdaa.0.nid25: pin: Speaker (None) [DISABLED]
  Widget cap: 0x0040048b PWR UNSOL STEREO
 Pin cap: 0x3724 PDC IN VREF[ 50 80 100 GROUND HIZ ]
  Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None ctype=1/8
loc=Rear color=Black misc=1
-Pin control: 0x
+Pin control: 0x0020 IN
   Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)

 dev.hdaa.0.nid24_original: 0x41f0 as=15 seq=0 device=Speaker conn=None
ctype=1/8 loc=Rear color=Black misc=1
 dev.hdaa.0.nid24_config: 0x41f0 as=15 seq=0 device=Speaker conn=None
ctype=1/8 loc=Rear color=Black misc=1
 dev.hdaa.0.nid24: pin: Speaker (None) [DISABLED]
  Widget cap: 0x0040048b PWR UNSOL STEREO
 Pin cap: 0x3724 PDC IN VREF[ 50 80 100 GROUND HIZ ]
  Pin config: 0x41f0 as=15 seq=0 device=Speaker conn=None ctype=1/8
loc=Rear color=Black misc=1
-Pin control: 0x
+Pin control: 0x0020 IN
   Input amp: 0x00270300 mute=0 step=3 size=39 offset=0 (0/30dB)

 dev.hdaa.0.nid23: vendor widget [DISABLED]
  Widget cap: 0x00f0




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

linux-c7 and opengl apps?

[Johannes Lundberg]

Hi

Have anyone successfully run opengl apps with linux-c7?

Linux opengl apps works great with linux-c6 on gpu < kabylake but
linux-c6-dri does not include support for kabylake gpus.
Linux glxinfo in c7 show support for hardware rendering on kabylake but any
attempt to run an opengl app results in application seg fault or other
crash (I believe this is also the case with skylake gpus on linux-c7).

Is there any way to run gdb on linux apps/core dumps?

/Johannes
___
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: Sound issues with Dell Latitude 7490 (kabylake)

[Johannes Lundberg]

On Tue, Oct 2, 2018 at 9:36 PM Johannes Lundberg  wrote:

>
>
> On Tue, Oct 2, 2018 at 9:32 PM Jakob Alvermark 
> wrote:
>
>> On 10/2/18 9:56 PM, Johannes Lundberg wrote:
>>
>>
>>
>> On Mon, Oct 1, 2018 at 10:12 PM Jakob Alvermark 
>> wrote:
>>
>>> On 10/1/18 10:56 PM, Johannes Lundberg wrote:
>>> > On Mon, Oct 1, 2018 at 8:37 PM Jakob Alvermark 
>>> wrote:
>>> >
>>> >> On 10/1/18 5:57 PM, Johannes Lundberg wrote:
>>> >>> Hi
>>> >>>
>>> >>> While sound work out of the box (with headphone switching) on the 1-2
>>> >> year
>>> >>> older Latitude 7270, it does not on my new machine.
>>> >>>
>>> >>> The internal speaker works fine. If I plug in external speakers in
>>> the
>>> >>> headphone jack, sound still goes to the internal speaker while a very
>>> >> load
>>> >>> buzz comes from the external speakers.
>>> >>>
>>> >>> Do we have a solution for this?
>>> >>>
>>> >>> # cat /dev/sndstat
>>> >>> Installed devices:
>>> >>> pcm0:  (play/rec) default
>>> >>> pcm1:  (play)
>>> >>> pcm2:  (play)
>>> >>> No devices installed from userspace.
>>> >>>
>>> >>> # sysctl hw.snd
>>> >>> hw.snd.maxautovchans: 16
>>> >>> hw.snd.default_unit: 0
>>> >>> hw.snd.version: 2009061500/amd64
>>> >>> hw.snd.default_auto: 1
>>> >>> hw.snd.verbose: 0
>>> >>> hw.snd.vpc_mixer_bypass: 1
>>> >>> hw.snd.feeder_rate_quality: 1
>>> >>> hw.snd.feeder_rate_round: 25
>>> >>> hw.snd.feeder_rate_max: 2016000
>>> >>> hw.snd.feeder_rate_min: 1
>>> >>> hw.snd.feeder_rate_polyphase_max: 183040
>>> >>> hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97
>>> >>> hw.snd.feeder_eq_exact_rate: 0
>>> >>> hw.snd.feeder_eq_presets:
>>> >>>
>>> PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000
>>> >>> hw.snd.basename_clone: 1
>>> >>> hw.snd.compat_linux_mmap: 0
>>> >>> hw.snd.syncdelay: -1
>>> >>> hw.snd.usefrags: 0
>>> >>> hw.snd.vpc_reset: 0
>>> >>> hw.snd.vpc_0db: 45
>>> >>> hw.snd.vpc_autoreset: 1
>>> >>> hw.snd.timeout: 5
>>> >>> hw.snd.latency_profile: 1
>>> >>> hw.snd.latency: 5
>>> >>> hw.snd.report_soft_matrix: 1
>>> >>> hw.snd.report_soft_formats: 1
>>> >>>
>>> >>> # sysctl dev.pcm
>>> >>> dev.pcm.2.bitperfect: 0
>>> >>> dev.pcm.2.buffersize: 65536
>>> >>> dev.pcm.2.play.vchanformat: s16le:2.0
>>> >>> dev.pcm.2.play.vchanrate: 48000
>>> >>> dev.pcm.2.play.vchanmode: passthrough
>>> >>> dev.pcm.2.play.vchans: 1
>>> >>> dev.pcm.2.play.32bit: 24
>>> >>> dev.pcm.2.%parent: hdaa1
>>> >>> dev.pcm.2.%pnpinfo:
>>> >>> dev.pcm.2.%location: nid=3
>>> >>> dev.pcm.2.%driver: pcm
>>> >>> dev.pcm.2.%desc: Intel Kabylake (HDMI/DP 8ch)
>>> >>> dev.pcm.1.bitperfect: 0
>>> >>> dev.pcm.1.buffersize: 65536
>>> >>> dev.pcm.1.play.vchanformat: s16le:2.0
>>> >>> dev.pcm.1.play.vchanrate: 48000
>>> >>> dev.pcm.1.play.vchanmode: fixed
>>> >>> dev.pcm.1.play.vchans: 1
>>> >>> dev.pcm.1.play.32bit: 24
>>> >>> dev.pcm.1.%parent: hdaa0
>>> >>> dev.pcm.1.%pnpinfo:
>>> >>> dev.pcm.1.%location: nid=33
>>> >>> dev.pcm.1.%driver: pcm
>>> >>> dev.pcm.1.%desc: Realtek ALC256 (Front Analog Headphones)
>>> >>> dev.pcm.0.bitperfect: 0
>>> >>> dev.pcm.0.buffersize: 65536
>>> >>> dev.pcm.0.rec.vchanformat: s16le:2.0
>>> >>> dev.pcm.0.rec.vchanrate: 48000
>>> >>> dev.pcm.0.rec.vchanmode: fixed
>>> >>> dev.pcm.0.rec.vchans: 1
>>> >>> dev.pcm.0.rec.autosrc: 2
>>> >>> dev.pcm.0.rec.32bit: 24
>>> >>> dev.pcm.0.play.vchanformat: s16le:2.0
>>> >>> dev.p

Re: Sound issues with Dell Latitude 7490 (kabylake)

[Johannes Lundberg]

On Tue, Oct 2, 2018 at 9:32 PM Jakob Alvermark  wrote:

> On 10/2/18 9:56 PM, Johannes Lundberg wrote:
>
>
>
> On Mon, Oct 1, 2018 at 10:12 PM Jakob Alvermark 
> wrote:
>
>> On 10/1/18 10:56 PM, Johannes Lundberg wrote:
>> > On Mon, Oct 1, 2018 at 8:37 PM Jakob Alvermark 
>> wrote:
>> >
>> >> On 10/1/18 5:57 PM, Johannes Lundberg wrote:
>> >>> Hi
>> >>>
>> >>> While sound work out of the box (with headphone switching) on the 1-2
>> >> year
>> >>> older Latitude 7270, it does not on my new machine.
>> >>>
>> >>> The internal speaker works fine. If I plug in external speakers in the
>> >>> headphone jack, sound still goes to the internal speaker while a very
>> >> load
>> >>> buzz comes from the external speakers.
>> >>>
>> >>> Do we have a solution for this?
>> >>>
>> >>> # cat /dev/sndstat
>> >>> Installed devices:
>> >>> pcm0:  (play/rec) default
>> >>> pcm1:  (play)
>> >>> pcm2:  (play)
>> >>> No devices installed from userspace.
>> >>>
>> >>> # sysctl hw.snd
>> >>> hw.snd.maxautovchans: 16
>> >>> hw.snd.default_unit: 0
>> >>> hw.snd.version: 2009061500/amd64
>> >>> hw.snd.default_auto: 1
>> >>> hw.snd.verbose: 0
>> >>> hw.snd.vpc_mixer_bypass: 1
>> >>> hw.snd.feeder_rate_quality: 1
>> >>> hw.snd.feeder_rate_round: 25
>> >>> hw.snd.feeder_rate_max: 2016000
>> >>> hw.snd.feeder_rate_min: 1
>> >>> hw.snd.feeder_rate_polyphase_max: 183040
>> >>> hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97
>> >>> hw.snd.feeder_eq_exact_rate: 0
>> >>> hw.snd.feeder_eq_presets:
>> >>>
>> PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000
>> >>> hw.snd.basename_clone: 1
>> >>> hw.snd.compat_linux_mmap: 0
>> >>> hw.snd.syncdelay: -1
>> >>> hw.snd.usefrags: 0
>> >>> hw.snd.vpc_reset: 0
>> >>> hw.snd.vpc_0db: 45
>> >>> hw.snd.vpc_autoreset: 1
>> >>> hw.snd.timeout: 5
>> >>> hw.snd.latency_profile: 1
>> >>> hw.snd.latency: 5
>> >>> hw.snd.report_soft_matrix: 1
>> >>> hw.snd.report_soft_formats: 1
>> >>>
>> >>> # sysctl dev.pcm
>> >>> dev.pcm.2.bitperfect: 0
>> >>> dev.pcm.2.buffersize: 65536
>> >>> dev.pcm.2.play.vchanformat: s16le:2.0
>> >>> dev.pcm.2.play.vchanrate: 48000
>> >>> dev.pcm.2.play.vchanmode: passthrough
>> >>> dev.pcm.2.play.vchans: 1
>> >>> dev.pcm.2.play.32bit: 24
>> >>> dev.pcm.2.%parent: hdaa1
>> >>> dev.pcm.2.%pnpinfo:
>> >>> dev.pcm.2.%location: nid=3
>> >>> dev.pcm.2.%driver: pcm
>> >>> dev.pcm.2.%desc: Intel Kabylake (HDMI/DP 8ch)
>> >>> dev.pcm.1.bitperfect: 0
>> >>> dev.pcm.1.buffersize: 65536
>> >>> dev.pcm.1.play.vchanformat: s16le:2.0
>> >>> dev.pcm.1.play.vchanrate: 48000
>> >>> dev.pcm.1.play.vchanmode: fixed
>> >>> dev.pcm.1.play.vchans: 1
>> >>> dev.pcm.1.play.32bit: 24
>> >>> dev.pcm.1.%parent: hdaa0
>> >>> dev.pcm.1.%pnpinfo:
>> >>> dev.pcm.1.%location: nid=33
>> >>> dev.pcm.1.%driver: pcm
>> >>> dev.pcm.1.%desc: Realtek ALC256 (Front Analog Headphones)
>> >>> dev.pcm.0.bitperfect: 0
>> >>> dev.pcm.0.buffersize: 65536
>> >>> dev.pcm.0.rec.vchanformat: s16le:2.0
>> >>> dev.pcm.0.rec.vchanrate: 48000
>> >>> dev.pcm.0.rec.vchanmode: fixed
>> >>> dev.pcm.0.rec.vchans: 1
>> >>> dev.pcm.0.rec.autosrc: 2
>> >>> dev.pcm.0.rec.32bit: 24
>> >>> dev.pcm.0.play.vchanformat: s16le:2.0
>> >>> dev.pcm.0.play.vchanrate: 48000
>> >>> dev.pcm.0.play.vchanmode: fixed
>> >>> dev.pcm.0.play.vchans: 2
>> >>> dev.pcm.0.play.32bit: 24
>> >>> dev.pcm.0.%parent: hdaa0
>> >>> dev.pcm.0.%pnpinfo:
>> >>> dev.pcm.0.%location: nid=20,18
>> >>> dev.pcm.0.%driver: pcm
>> >>> dev.pcm.0.%desc: Realtek ALC256 (Internal Analog)
>> >>> dev.pcm.%parent:
>> &

Re: Sound issues with Dell Latitude 7490 (kabylake)

[Johannes Lundberg]

On Mon, Oct 1, 2018 at 10:12 PM Jakob Alvermark  wrote:

> On 10/1/18 10:56 PM, Johannes Lundberg wrote:
> > On Mon, Oct 1, 2018 at 8:37 PM Jakob Alvermark 
> wrote:
> >
> >> On 10/1/18 5:57 PM, Johannes Lundberg wrote:
> >>> Hi
> >>>
> >>> While sound work out of the box (with headphone switching) on the 1-2
> >> year
> >>> older Latitude 7270, it does not on my new machine.
> >>>
> >>> The internal speaker works fine. If I plug in external speakers in the
> >>> headphone jack, sound still goes to the internal speaker while a very
> >> load
> >>> buzz comes from the external speakers.
> >>>
> >>> Do we have a solution for this?
> >>>
> >>> # cat /dev/sndstat
> >>> Installed devices:
> >>> pcm0:  (play/rec) default
> >>> pcm1:  (play)
> >>> pcm2:  (play)
> >>> No devices installed from userspace.
> >>>
> >>> # sysctl hw.snd
> >>> hw.snd.maxautovchans: 16
> >>> hw.snd.default_unit: 0
> >>> hw.snd.version: 2009061500/amd64
> >>> hw.snd.default_auto: 1
> >>> hw.snd.verbose: 0
> >>> hw.snd.vpc_mixer_bypass: 1
> >>> hw.snd.feeder_rate_quality: 1
> >>> hw.snd.feeder_rate_round: 25
> >>> hw.snd.feeder_rate_max: 2016000
> >>> hw.snd.feeder_rate_min: 1
> >>> hw.snd.feeder_rate_polyphase_max: 183040
> >>> hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97
> >>> hw.snd.feeder_eq_exact_rate: 0
> >>> hw.snd.feeder_eq_presets:
> >>>
> PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000
> >>> hw.snd.basename_clone: 1
> >>> hw.snd.compat_linux_mmap: 0
> >>> hw.snd.syncdelay: -1
> >>> hw.snd.usefrags: 0
> >>> hw.snd.vpc_reset: 0
> >>> hw.snd.vpc_0db: 45
> >>> hw.snd.vpc_autoreset: 1
> >>> hw.snd.timeout: 5
> >>> hw.snd.latency_profile: 1
> >>> hw.snd.latency: 5
> >>> hw.snd.report_soft_matrix: 1
> >>> hw.snd.report_soft_formats: 1
> >>>
> >>> # sysctl dev.pcm
> >>> dev.pcm.2.bitperfect: 0
> >>> dev.pcm.2.buffersize: 65536
> >>> dev.pcm.2.play.vchanformat: s16le:2.0
> >>> dev.pcm.2.play.vchanrate: 48000
> >>> dev.pcm.2.play.vchanmode: passthrough
> >>> dev.pcm.2.play.vchans: 1
> >>> dev.pcm.2.play.32bit: 24
> >>> dev.pcm.2.%parent: hdaa1
> >>> dev.pcm.2.%pnpinfo:
> >>> dev.pcm.2.%location: nid=3
> >>> dev.pcm.2.%driver: pcm
> >>> dev.pcm.2.%desc: Intel Kabylake (HDMI/DP 8ch)
> >>> dev.pcm.1.bitperfect: 0
> >>> dev.pcm.1.buffersize: 65536
> >>> dev.pcm.1.play.vchanformat: s16le:2.0
> >>> dev.pcm.1.play.vchanrate: 48000
> >>> dev.pcm.1.play.vchanmode: fixed
> >>> dev.pcm.1.play.vchans: 1
> >>> dev.pcm.1.play.32bit: 24
> >>> dev.pcm.1.%parent: hdaa0
> >>> dev.pcm.1.%pnpinfo:
> >>> dev.pcm.1.%location: nid=33
> >>> dev.pcm.1.%driver: pcm
> >>> dev.pcm.1.%desc: Realtek ALC256 (Front Analog Headphones)
> >>> dev.pcm.0.bitperfect: 0
> >>> dev.pcm.0.buffersize: 65536
> >>> dev.pcm.0.rec.vchanformat: s16le:2.0
> >>> dev.pcm.0.rec.vchanrate: 48000
> >>> dev.pcm.0.rec.vchanmode: fixed
> >>> dev.pcm.0.rec.vchans: 1
> >>> dev.pcm.0.rec.autosrc: 2
> >>> dev.pcm.0.rec.32bit: 24
> >>> dev.pcm.0.play.vchanformat: s16le:2.0
> >>> dev.pcm.0.play.vchanrate: 48000
> >>> dev.pcm.0.play.vchanmode: fixed
> >>> dev.pcm.0.play.vchans: 2
> >>> dev.pcm.0.play.32bit: 24
> >>> dev.pcm.0.%parent: hdaa0
> >>> dev.pcm.0.%pnpinfo:
> >>> dev.pcm.0.%location: nid=20,18
> >>> dev.pcm.0.%driver: pcm
> >>> dev.pcm.0.%desc: Realtek ALC256 (Internal Analog)
> >>> dev.pcm.%parent:
> >>
> >> You could try
> >>
> >> sysctl dev.hdaa.0.nid33_config="as=1 seq=15 device=Headphones"
> >>
> >> sysctl dev.hdaa.0.reconfig=1
> >>
> >>
> >> It should result in you having only one pcm device for the two outputs
> >> and it should switch from
> >>
> >> internal to external when you plug in the external speakers and vice
> versa.
> >>
> >> To make

Re: Sound issues with Dell Latitude 7490 (kabylake)

[Johannes Lundberg]

On Mon, Oct 1, 2018 at 8:37 PM Jakob Alvermark  wrote:

> On 10/1/18 5:57 PM, Johannes Lundberg wrote:
> > Hi
> >
> > While sound work out of the box (with headphone switching) on the 1-2
> year
> > older Latitude 7270, it does not on my new machine.
> >
> > The internal speaker works fine. If I plug in external speakers in the
> > headphone jack, sound still goes to the internal speaker while a very
> load
> > buzz comes from the external speakers.
> >
> > Do we have a solution for this?
> >
> > # cat /dev/sndstat
> > Installed devices:
> > pcm0:  (play/rec) default
> > pcm1:  (play)
> > pcm2:  (play)
> > No devices installed from userspace.
> >
> > # sysctl hw.snd
> > hw.snd.maxautovchans: 16
> > hw.snd.default_unit: 0
> > hw.snd.version: 2009061500/amd64
> > hw.snd.default_auto: 1
> > hw.snd.verbose: 0
> > hw.snd.vpc_mixer_bypass: 1
> > hw.snd.feeder_rate_quality: 1
> > hw.snd.feeder_rate_round: 25
> > hw.snd.feeder_rate_max: 2016000
> > hw.snd.feeder_rate_min: 1
> > hw.snd.feeder_rate_polyphase_max: 183040
> > hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97
> > hw.snd.feeder_eq_exact_rate: 0
> > hw.snd.feeder_eq_presets:
> > PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000
> > hw.snd.basename_clone: 1
> > hw.snd.compat_linux_mmap: 0
> > hw.snd.syncdelay: -1
> > hw.snd.usefrags: 0
> > hw.snd.vpc_reset: 0
> > hw.snd.vpc_0db: 45
> > hw.snd.vpc_autoreset: 1
> > hw.snd.timeout: 5
> > hw.snd.latency_profile: 1
> > hw.snd.latency: 5
> > hw.snd.report_soft_matrix: 1
> > hw.snd.report_soft_formats: 1
> >
> > # sysctl dev.pcm
> > dev.pcm.2.bitperfect: 0
> > dev.pcm.2.buffersize: 65536
> > dev.pcm.2.play.vchanformat: s16le:2.0
> > dev.pcm.2.play.vchanrate: 48000
> > dev.pcm.2.play.vchanmode: passthrough
> > dev.pcm.2.play.vchans: 1
> > dev.pcm.2.play.32bit: 24
> > dev.pcm.2.%parent: hdaa1
> > dev.pcm.2.%pnpinfo:
> > dev.pcm.2.%location: nid=3
> > dev.pcm.2.%driver: pcm
> > dev.pcm.2.%desc: Intel Kabylake (HDMI/DP 8ch)
> > dev.pcm.1.bitperfect: 0
> > dev.pcm.1.buffersize: 65536
> > dev.pcm.1.play.vchanformat: s16le:2.0
> > dev.pcm.1.play.vchanrate: 48000
> > dev.pcm.1.play.vchanmode: fixed
> > dev.pcm.1.play.vchans: 1
> > dev.pcm.1.play.32bit: 24
> > dev.pcm.1.%parent: hdaa0
> > dev.pcm.1.%pnpinfo:
> > dev.pcm.1.%location: nid=33
> > dev.pcm.1.%driver: pcm
> > dev.pcm.1.%desc: Realtek ALC256 (Front Analog Headphones)
> > dev.pcm.0.bitperfect: 0
> > dev.pcm.0.buffersize: 65536
> > dev.pcm.0.rec.vchanformat: s16le:2.0
> > dev.pcm.0.rec.vchanrate: 48000
> > dev.pcm.0.rec.vchanmode: fixed
> > dev.pcm.0.rec.vchans: 1
> > dev.pcm.0.rec.autosrc: 2
> > dev.pcm.0.rec.32bit: 24
> > dev.pcm.0.play.vchanformat: s16le:2.0
> > dev.pcm.0.play.vchanrate: 48000
> > dev.pcm.0.play.vchanmode: fixed
> > dev.pcm.0.play.vchans: 2
> > dev.pcm.0.play.32bit: 24
> > dev.pcm.0.%parent: hdaa0
> > dev.pcm.0.%pnpinfo:
> > dev.pcm.0.%location: nid=20,18
> > dev.pcm.0.%driver: pcm
> > dev.pcm.0.%desc: Realtek ALC256 (Internal Analog)
> > dev.pcm.%parent:
>
>
> You could try
>
> sysctl dev.hdaa.0.nid33_config="as=1 seq=15 device=Headphones"
>
> sysctl dev.hdaa.0.reconfig=1
>
>
> It should result in you having only one pcm device for the two outputs
> and it should switch from
>
> internal to external when you plug in the external speakers and vice versa.
>
> To make it permanent put 'hint.hdaa.0.nid33.config="as=1 seq=15
> device=Headphones"' in your loader.conf
>
>
> The loud buzz is a bit worrying, it could be related to the problem I
> have been having, where I got strange sound
>
> when using headphones on my laptop. I have worked around it by patching
> the sound driver, I have kept my local
>
> patch for years.
>
>
With that hint it does turn off the internal speakers but I can hear
nothing in my headphones. Turning the volume to 100% I can hear the
playback in my internal speakers at very low volume (with headphones
connected).
The headphones has no buzzing sound, that is only my external speakers and
they only act like that when connect to this laptop (kind of like the buzz
noise you get when the connector touches something (ground?))...


> Jakob
>
>
___
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: Sound issues with Dell Latitude 7490 (kabylake)

[Johannes Lundberg]

On Mon, Oct 1, 2018 at 5:43 PM Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:

> > Hi
> >
> > While sound work out of the box (with headphone switching) on the 1-2
> year
> > older Latitude 7270, it does not on my new machine.
> >
> > The internal speaker works fine. If I plug in external speakers in the
> > headphone jack, sound still goes to the internal speaker while a very
> load
> > buzz comes from the external speakers.
> >
> > Do we have a solution for this?
>
> I do not believe we have anything that detects stuff plugged into
> and removed from the newer sound stuff that needs switching to
> change from internal to external speakers.
>
> I think you need to do what I have to do when I plug in external
> speakers on my thinkpad x230:
> sysctl hw.snd.default_unit=1
>
> And when I unplug them I have to do:
> sysctl hw.snd.default_unit=0
>
> to switch back to the internal speakers.
>
>
Thanks for the tips. I will try that.

But, I think there is also something more serious with this. While pulse
audio clients (firefox) seem to play fine, Minecraft which uses OpenAL,
produces crackling noises and eventually crash Minecraft with OpenAL being
the culprit...

>
> > # cat /dev/sndstat
> > Installed devices:
> > pcm0:  (play/rec) default
> > pcm1:  (play)
> > pcm2:  (play)
> > No devices installed from userspace.
> >
> > # sysctl hw.snd
> > hw.snd.maxautovchans: 16
> > hw.snd.default_unit: 0
> > hw.snd.version: 2009061500/amd64
> > hw.snd.default_auto: 1
> > hw.snd.verbose: 0
> > hw.snd.vpc_mixer_bypass: 1
> > hw.snd.feeder_rate_quality: 1
> > hw.snd.feeder_rate_round: 25
> > hw.snd.feeder_rate_max: 2016000
> > hw.snd.feeder_rate_min: 1
> > hw.snd.feeder_rate_polyphase_max: 183040
> > hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97
> > hw.snd.feeder_eq_exact_rate: 0
> > hw.snd.feeder_eq_presets:
> > PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000
> > hw.snd.basename_clone: 1
> > hw.snd.compat_linux_mmap: 0
> > hw.snd.syncdelay: -1
> > hw.snd.usefrags: 0
> > hw.snd.vpc_reset: 0
> > hw.snd.vpc_0db: 45
> > hw.snd.vpc_autoreset: 1
> > hw.snd.timeout: 5
> > hw.snd.latency_profile: 1
> > hw.snd.latency: 5
> > hw.snd.report_soft_matrix: 1
> > hw.snd.report_soft_formats: 1
> >
> > # sysctl dev.pcm
> > dev.pcm.2.bitperfect: 0
> > dev.pcm.2.buffersize: 65536
> > dev.pcm.2.play.vchanformat: s16le:2.0
> > dev.pcm.2.play.vchanrate: 48000
> > dev.pcm.2.play.vchanmode: passthrough
> > dev.pcm.2.play.vchans: 1
> > dev.pcm.2.play.32bit: 24
> > dev.pcm.2.%parent: hdaa1
> > dev.pcm.2.%pnpinfo:
> > dev.pcm.2.%location: nid=3
> > dev.pcm.2.%driver: pcm
> > dev.pcm.2.%desc: Intel Kabylake (HDMI/DP 8ch)
> > dev.pcm.1.bitperfect: 0
> > dev.pcm.1.buffersize: 65536
> > dev.pcm.1.play.vchanformat: s16le:2.0
> > dev.pcm.1.play.vchanrate: 48000
> > dev.pcm.1.play.vchanmode: fixed
> > dev.pcm.1.play.vchans: 1
> > dev.pcm.1.play.32bit: 24
> > dev.pcm.1.%parent: hdaa0
> > dev.pcm.1.%pnpinfo:
> > dev.pcm.1.%location: nid=33
> > dev.pcm.1.%driver: pcm
> > dev.pcm.1.%desc: Realtek ALC256 (Front Analog Headphones)
> > dev.pcm.0.bitperfect: 0
> > dev.pcm.0.buffersize: 65536
> > dev.pcm.0.rec.vchanformat: s16le:2.0
> > dev.pcm.0.rec.vchanrate: 48000
> > dev.pcm.0.rec.vchanmode: fixed
> > dev.pcm.0.rec.vchans: 1
> > dev.pcm.0.rec.autosrc: 2
> > dev.pcm.0.rec.32bit: 24
> > dev.pcm.0.play.vchanformat: s16le:2.0
> > dev.pcm.0.play.vchanrate: 48000
> > dev.pcm.0.play.vchanmode: fixed
> > dev.pcm.0.play.vchans: 2
> > dev.pcm.0.play.32bit: 24
> > dev.pcm.0.%parent: hdaa0
> > dev.pcm.0.%pnpinfo:
> > dev.pcm.0.%location: nid=20,18
> > dev.pcm.0.%driver: pcm
> > dev.pcm.0.%desc: Realtek ALC256 (Internal Analog)
> > dev.pcm.%parent:
> > ___
> > 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"
> >
>
> --
> Rod Grimes
> rgri...@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"

Sound issues with Dell Latitude 7490 (kabylake)

[Johannes Lundberg]

Hi

While sound work out of the box (with headphone switching) on the 1-2 year
older Latitude 7270, it does not on my new machine.

The internal speaker works fine. If I plug in external speakers in the
headphone jack, sound still goes to the internal speaker while a very load
buzz comes from the external speakers.

Do we have a solution for this?

# cat /dev/sndstat
Installed devices:
pcm0:  (play/rec) default
pcm1:  (play)
pcm2:  (play)
No devices installed from userspace.

# sysctl hw.snd
hw.snd.maxautovchans: 16
hw.snd.default_unit: 0
hw.snd.version: 2009061500/amd64
hw.snd.default_auto: 1
hw.snd.verbose: 0
hw.snd.vpc_mixer_bypass: 1
hw.snd.feeder_rate_quality: 1
hw.snd.feeder_rate_round: 25
hw.snd.feeder_rate_max: 2016000
hw.snd.feeder_rate_min: 1
hw.snd.feeder_rate_polyphase_max: 183040
hw.snd.feeder_rate_presets: 100:8:0.85 100:36:0.92 100:164:0.97
hw.snd.feeder_eq_exact_rate: 0
hw.snd.feeder_eq_presets:
PEQ:16000,0.2500,62,0.2500:-9,9,1.0:44100,48000,88200,96000,176400,192000
hw.snd.basename_clone: 1
hw.snd.compat_linux_mmap: 0
hw.snd.syncdelay: -1
hw.snd.usefrags: 0
hw.snd.vpc_reset: 0
hw.snd.vpc_0db: 45
hw.snd.vpc_autoreset: 1
hw.snd.timeout: 5
hw.snd.latency_profile: 1
hw.snd.latency: 5
hw.snd.report_soft_matrix: 1
hw.snd.report_soft_formats: 1

# sysctl dev.pcm
dev.pcm.2.bitperfect: 0
dev.pcm.2.buffersize: 65536
dev.pcm.2.play.vchanformat: s16le:2.0
dev.pcm.2.play.vchanrate: 48000
dev.pcm.2.play.vchanmode: passthrough
dev.pcm.2.play.vchans: 1
dev.pcm.2.play.32bit: 24
dev.pcm.2.%parent: hdaa1
dev.pcm.2.%pnpinfo:
dev.pcm.2.%location: nid=3
dev.pcm.2.%driver: pcm
dev.pcm.2.%desc: Intel Kabylake (HDMI/DP 8ch)
dev.pcm.1.bitperfect: 0
dev.pcm.1.buffersize: 65536
dev.pcm.1.play.vchanformat: s16le:2.0
dev.pcm.1.play.vchanrate: 48000
dev.pcm.1.play.vchanmode: fixed
dev.pcm.1.play.vchans: 1
dev.pcm.1.play.32bit: 24
dev.pcm.1.%parent: hdaa0
dev.pcm.1.%pnpinfo:
dev.pcm.1.%location: nid=33
dev.pcm.1.%driver: pcm
dev.pcm.1.%desc: Realtek ALC256 (Front Analog Headphones)
dev.pcm.0.bitperfect: 0
dev.pcm.0.buffersize: 65536
dev.pcm.0.rec.vchanformat: s16le:2.0
dev.pcm.0.rec.vchanrate: 48000
dev.pcm.0.rec.vchanmode: fixed
dev.pcm.0.rec.vchans: 1
dev.pcm.0.rec.autosrc: 2
dev.pcm.0.rec.32bit: 24
dev.pcm.0.play.vchanformat: s16le:2.0
dev.pcm.0.play.vchanrate: 48000
dev.pcm.0.play.vchanmode: fixed
dev.pcm.0.play.vchans: 2
dev.pcm.0.play.32bit: 24
dev.pcm.0.%parent: hdaa0
dev.pcm.0.%pnpinfo:
dev.pcm.0.%location: nid=20,18
dev.pcm.0.%driver: pcm
dev.pcm.0.%desc: Realtek ALC256 (Internal Analog)
dev.pcm.%parent:
___
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: Resume Issue with em(4) ALPHA7

[Johannes Lundberg]

On Sun, Sep 30, 2018 at 8:24 AM Ali Abdallah  wrote:

> I'm having also the same problem on my Thinkpad x230. However I'm running a
> minimal kernel, so usually I do kldunload/kldload if_em,
> to reset the hardware and to avoid a reboot.
>
> Hopefully this gets fixed soon.
>
>
Hi

I've been having the same problem for at least several months with if_em,
hw I218-LM and I219-LM.
Need to unload and reload if_em to make it work again after resume.


/Johannes

Cheers,
> Ali
>
> On Sat, Sep 29, 2018 at 7:06 PM Pete Wright  wrote:
>
> > Hello,
> >
> > More suspend/resume testing on my end.  This system is a desktop, so not
> > critical for my daily workflow but wanted to flag it regardless.  The
> > system is a Lenovo m900 with skylake and em(4) NIC.  Entering suspend
> > works without issues, resuming seems to mostly work as well.  I.e. no
> > issues with display or input from keyboard or mouse.
> >
> > The one issue I am running into is my NIC is non-functional after
> > resume.  restarting the network stack via "service netif restart" does
> > not work - as in no DHCP lease is aquired and no link is detected.  Nor
> > does manually down'ing and up'ing the interface work.  I see these
> > messages in my dmesg buffer after resume:
> >
> > in6_purgeaddr: err=65, destination address delete failed
> > lo0: link state changed to DOWN
> > lo0: link state changed to UP
> > Link state changed to down
> > em0: link state changed to DOWN
> > em0: TX(0) desc avail = 1024, pidx = 0
> > em0: TX(0) desc avail = 1024, pidx = 0
> > em0: TX(0) desc avail = 1024, pidx = 0
> > em0: TX(0) desc avail = 1024, pidx = 0
> >
> > Another thing I noticed is that after resume "ifconfig" hangs for a
> > couple seconds printing after printing the first line of my em0 device
> > (after the flags).  Not sure if that's helpful but thought it could be a
> > useful datapoint.
> >
> > It is easy to reproduce this, so I am happy to do any additional
> > debugging or testing on this.
> >
> >
> > Cheers,
> >
> > -pete
> >
> > --
> > Pete Wright
> > p...@nomadlogic.org
> > @nomadlogicLA
> >
> > ___
> > 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"
>
___
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"

Dell latitude 7490 touchpad support?

[Johannes Lundberg]

Hi

I just got a new work laptop and the touchpad does not work. Some
information points to that this machine has a Microsoft precision touchpad.
I can't see any USB device so I'm wondering if this is an I2C device?

Do we have any driver for this?

/Johannes
___
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: drm2 in base

[Johannes Lundberg]

drm-legacy-kmod will be ready before 12 is released.

On Fri, Sep 28, 2018 at 13:48 Steve Kargl 
wrote:

> On Fri, Sep 28, 2018 at 01:30:59PM -0700, Matthew Macy wrote:
> >
> > Bug reports are addressed as they come in. If issues haven't come up
> > it likely reflects a scarcity of users.
> >
>
> It is likely that -current users are still using drm2 from
> base (or have sufficiently new hardware that drm-stable-kmod
> works for them).  I saw Glen's post about the updated
> release schedule, and decided to be pro-active in moving
> to drm-*-kmod to counter the possibility that someone
> might remove drm2 from head as soon as the FreeBSD-12 branch
> exists.
>
> --
> Steve
> ___
> 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: 12.0-ALPHA5 - ZFS default ARC max apparently forcing system to run out of memory

[Johannes Lundberg]

On Thu, Sep 27, 2018 at 15:03 Rebecca Cran  wrote:

> I'm running 12.0-ALPHA5 on a laptop which has 32GB RAM and 2GB swap.
> I've found it running out of memory when building ports via synth: I
> think I've also seen it when running a buildworld. Johannes on
> FreeBSDDesktop suggested it might be related to ZFS, and setting
> vfs.zfs.arc_max to 8GB *does* appear to have resolved the problem.
>
>
> Shortly after running out of memory (with |"swap_pager_getswapspace(32):
> failed" messages)|, the first few lines of 'top' were:
>
>
> Mem: 4335M Active, 4854M Inact, 7751M Laundry, 9410M Wired, 48K Buf,
> 5332M Free
>
> ARC: 5235M Total, 4169M MFU, 497M MRU, 172K Anon, 97M Header, 471M Other
>
>  3479M Compressed, 5930M Uncompressed, 1.70:1 Ratio
>
> Swap: 2048M Total, 2009M Used, 39M Free, 98% Inuse
>
>
>
> I've not seen this happen before on ZFS systems, so is it a regression
> in 12?


Hi

It’s been a few months since I did the same thing so it’s not a recent
issue.


>
>
> --
> Rebecca Cran
>
> ___
> 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: r338641 && /dev/cyapa0: moused does not show pointer on console

[Johannes Lundberg]

On Mon, Sep 24, 2018 at 21:57 Matthias Apitz  wrote:

> El día Monday, September 24, 2018 a las 09:01:34PM +0200, Michael Gmelin
> escribió:
>
> > >> On 24/09/2018 13:21, Matthias Apitz wrote:
> > >> Re/ i915kms, I have to load it with kldload by hand. If I load it via
> > >> loader.conf, the cyapa devices (both) say 'Unable to bring the device
> > >> out of bootstrap'.
> > >
> > > That's probably because you use device hints to configure cyapa, but
> i2c bus
> > > numbers are different depending on whether the kms driver is loaded or
> not
> > > (because it also creates i2c buses).
> > >
> > > Try to remove the hints and to use chromebook_platform(4) instead.
>
> Thanks, I will test
>
> chromebook_platform_load="YES"
>
> > Also, I think the preferred way to load i915kms is to use kld_list
> (might be unrelated, but still).
> >
> > pkg install drm-next-kmod
> > sysrc kld_list="/boot/modules/i915kms.ko"
>
> Thanks too. On my laptop in production I do use a handmade script
> /usr/local/etc/rc.d/loadi915kms to load the module at late time.


Hi

Yes, the new drm drivers can’t be loaded from loader.conf. Use kld_list in
rc.conf as suggested.


>
> matthias
>
> --
> Matthias Apitz, ✉ g...@unixarea.de, ⌂ http://www.unixarea.de/  📱
> +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub
> ___
> 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"

Random reboots with wifi/wpa/iwm (12-alpha6)

[Johannes Lundberg]

Hi

For a while I have had occasional random reboots. Today I managed to get 2
core dumps, both with the same backtrace.

It might be the case that this only happens after the system has been
resumed from S3 but I'm not sure. The second time the reboot was 30 minutes
after resume. I'm using wpa_supplicant from pkg.

Is this a known issue or should I file a report in bugzilla?

Unread portion of the kernel message buffer:
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80682bed
stack pointer   = 0x28:0xfe009b4183d0
frame pointer   = 0x28:0xfe009b418440
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 = 3266 (wpa_supplicant)
trap number = 12
Dumping 1195 out of 16251
MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..92%

__curthread () at ./machine/pcpu.h:230
230 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) #0  __curthread () at ./machine/pcpu.h:230
#1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:366
#2  0x823adfe8 in vt_kms_postswitch ()
   from /boot/modules.drm-v4.16/drm.ko
#3  0x80521aac in vt_window_switch (
vw=0x80e8b960 )
at /usr/src/sys/dev/vt/vt_core.c:580
#4  0x8051ecc0 in vtterm_cngrab (tm=)
at /usr/src/sys/dev/vt/vt_core.c:1572
#5  0x80640552 in cngrab () at /usr/src/sys/kern/kern_cons.c:370
#6  0x806a363b in vpanic (fmt=0x80afcafc "%s",
ap=0xfe009b418120) at /usr/src/sys/kern/kern_shutdown.c:846
#7  0x806a3533 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:799
#8  0x80a3da6f in trap_fatal (frame=0xfe009b418310, eva=1040)
at /usr/src/sys/amd64/amd64/trap.c:935
#9  0x80a3dac9 in trap_pfault (frame=0xfe009b418310, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:771
#10 0x80a3d0ee in trap (frame=0xfe009b418310)
at /usr/src/sys/amd64/amd64/trap.c:441
#11 
#12 __mtx_lock_sleep (c=0xfe00a21f71b0, v=)
at /usr/src/sys/kern/kern_mutex.c:565
#13 0x8080d362 in psq_drain (psq=)
at /usr/src/sys/net80211/ieee80211_power.c:187
#14 ieee80211_node_psq_drain (ni=0xfe00a21f4000)
at /usr/src/sys/net80211/ieee80211_power.c:214
#15 0x80801a37 in node_cleanup (ni=0xfe00a21f4000)
at /usr/src/sys/net80211/ieee80211_node.c:1238
#16 0x80801955 in node_free (ni=0xfe00a21f4000)
at /usr/src/sys/net80211/ieee80211_node.c:1275
#17 0x80802e40 in ieee80211_sta_join1 (selbs=)
at /usr/src/sys/net80211/ieee80211_node.c:865
#18 0x80803d74 in ieee80211_sta_join (vap=,
chan=, se=)
at /usr/src/sys/net80211/ieee80211_node.c:1037
#19 0x807f8de1 in setmlme_assoc_sta (vap=,
mac=0xfe009b4185e4 "`\320,\017\035\330Courtyard_GUEST",
ssid_len=, ssid=)
at /usr/src/sys/net80211/ieee80211_ioctl.c:1579
#20 ieee80211_ioctl_setmlme (vap=, ireq=)
at /usr/src/sys/net80211/ieee80211_ioctl.c:1636
#21 ieee80211_ioctl_set80211 (vap=, cmd=0,
ireq=) at /usr/src/sys/net80211/ieee80211_ioctl.c:2907
#22 0x807a8b61 in ifioctl (so=0xf802342dca38, cmd=2149607914,
data=, td=0xf8011b9b7000) at
/usr/src/sys/net/if.c:3101
#23 0x8070e55d in fo_ioctl (fp=, com=,
active_cred=0xf8011b9b7000, td=, data=)
at /usr/src/sys/sys/file.h:330
#24 kern_ioctl (td=0xf8011b9b7000, fd=4, com=2149607914,
data=0xfe887000 "") at /usr/src/sys/kern/sys_generic.c:800
#25 0x8070e27e in sys_ioctl (td=0xf8011b9b7000,
uap=0xf8011b9b73c0) at /usr/src/sys/kern/sys_generic.c:712
#26 0x80a3e489 in syscallenter (td=)
at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:135
#27 amd64_syscall (td=0xf8011b9b7000, traced=0)
at /usr/src/sys/amd64/amd64/trap.c:1050
#28 
#29 0x000800828bba in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffe6f8
___
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: usb rtwn not loaded properly at boot

[Johannes Lundberg]

On Wed, Sep 19, 2018 at 1:40 AM Patrick McMunn 
wrote:

> I filed a bug about this issue:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231441 I have
> encountered
> it with the run USB wireless driver. I haven't tested it with ethernet.
> Does this issue only affect wireless devices, only certain drivers, or all
> network connections?
>

It looks like the regexps are messed up. In this case none of those wifi
and scsi driver would do what's intended.

https://gist.github.com/johalun/c9383ff03cb29e12c3f4978e06ca6413#file-gistfile1-txt-L761-L762



>
> On Tue, Sep 18, 2018 at 6:55 AM Johannes Lundberg 
> wrote:
>
> > On Tue, Sep 18, 2018 at 10:03 AM Johannes Lundberg 
> > wrote:
> >
> > >
> > >
> > > On Tue, Sep 18, 2018 at 9:43 AM Johannes Lundberg 
> > > wrote:
> > >
> > >>
> > >>
> > >> On Tue, Sep 18, 2018 at 9:39 AM Daniel Braniss 
> > >> wrote:
> > >>
> > >>>
> > >>>
> > >>> > On 18 Sep 2018, at 10:32, Johannes Lundberg 
> > >>> wrote:
> > >>> >
> > >>> > On Tue, Sep 18, 2018 at 9:27 AM Yuri Pankov 
> > wrote:
> > >>> >
> > >>> >> Johannes Lundberg wrote:
> > >>> >>> Hi
> > >>> >>>
> > >>> >>> I have (with 12-ALPHA5)
> > >>> >>>
> > >>> >>> /boot/loader.conf
> > >>> >>> rtwn_load="YES"
> > >>> >>> if_urtw_usb_load="YES"
> > >>> >>
> > >>> >> rtwn(4) thinks this should be if_rtwn_usb_load="YES".
> > >>> >>
> > >>> >
> > >>> > Ah yes. Sorry about that. I still suffer confusion from the rename.
> > >>> > Still, it doesn't change anything since if_rtwn_usb was loaded
> > anyway.
> > >>> >
> > >>> >
> > >>> >>> /etc/rc.conf
> > >>> >>> wlans_rtwn0="wlan0"
> > >>> >>> ifconfig_wlan0="WPA DHCP"
> > >>> >>>
> > >>> >>> but still after boot only lo0 exists and all modules are loaded.
> > >>> >>>
> > >>> >>> Manually running
> > >>> >>> ifconfig wlan0 create wlandev rtwn0
> > >>> >>> sets up the interface correctly.
> > >>> >>>
> > >>> >>> In my kernel config I have
> > >>> >>> MODULES_OVERRIDE="usb rtwn_usb rtwn "
> > >>> >>>
> > >>> >>> I'm pretty sure this has worked before... Any clues?
> > >>> >>
> > >>>
> > >>>
> > >>> devd is not calling netif!
> > >>> try running ’service netif start’ and see what happens.
> > >>>
> > >>
> > >> Yep that enables wlan0!
> > >>
> > >>
> > > With wlan0 up and running, unplug and re-plug the wifi adapter will
> > create
> > > rtwn0 device but no wlan0.
> > > Firmware was missing so I added rtwnfw to MODULES_OVERRIDE but it makes
> > no
> > > difference for this problem.
> > >
> > >
> > (cc: imp)
> >
> > Here's devd output:
> >
> > https://gist.github.com/johalun/c9383ff03cb29e12c3f4978e06ca6413
> >
> > Not sure how to interpret this but it looks like it fails to match rtwn0
> at
> >
> >
> https://gist.github.com/johalun/c9383ff03cb29e12c3f4978e06ca6413#file-gistfile1-txt-L761
> >
> >
> >
> >
> > >>> danny
> > >>>
> > >>> > ___
> > >>> > 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"
> >
>
>
> --
> Patrick McMunn
>
> - Learn more about the Catholic Faith: http://www.catholic.com/
> - Pray with the Church: http://www.universalis.com/
> ___
> 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: usb rtwn not loaded properly at boot

[Johannes Lundberg]

On Tue, Sep 18, 2018 at 10:03 AM Johannes Lundberg 
wrote:

>
>
> On Tue, Sep 18, 2018 at 9:43 AM Johannes Lundberg 
> wrote:
>
>>
>>
>> On Tue, Sep 18, 2018 at 9:39 AM Daniel Braniss 
>> wrote:
>>
>>>
>>>
>>> > On 18 Sep 2018, at 10:32, Johannes Lundberg 
>>> wrote:
>>> >
>>> > On Tue, Sep 18, 2018 at 9:27 AM Yuri Pankov  wrote:
>>> >
>>> >> Johannes Lundberg wrote:
>>> >>> Hi
>>> >>>
>>> >>> I have (with 12-ALPHA5)
>>> >>>
>>> >>> /boot/loader.conf
>>> >>> rtwn_load="YES"
>>> >>> if_urtw_usb_load="YES"
>>> >>
>>> >> rtwn(4) thinks this should be if_rtwn_usb_load="YES".
>>> >>
>>> >
>>> > Ah yes. Sorry about that. I still suffer confusion from the rename.
>>> > Still, it doesn't change anything since if_rtwn_usb was loaded anyway.
>>> >
>>> >
>>> >>> /etc/rc.conf
>>> >>> wlans_rtwn0="wlan0"
>>> >>> ifconfig_wlan0="WPA DHCP"
>>> >>>
>>> >>> but still after boot only lo0 exists and all modules are loaded.
>>> >>>
>>> >>> Manually running
>>> >>> ifconfig wlan0 create wlandev rtwn0
>>> >>> sets up the interface correctly.
>>> >>>
>>> >>> In my kernel config I have
>>> >>> MODULES_OVERRIDE="usb rtwn_usb rtwn "
>>> >>>
>>> >>> I'm pretty sure this has worked before... Any clues?
>>> >>
>>>
>>>
>>> devd is not calling netif!
>>> try running ’service netif start’ and see what happens.
>>>
>>
>> Yep that enables wlan0!
>>
>>
> With wlan0 up and running, unplug and re-plug the wifi adapter will create
> rtwn0 device but no wlan0.
> Firmware was missing so I added rtwnfw to MODULES_OVERRIDE but it makes no
> difference for this problem.
>
>
(cc: imp)

Here's devd output:

https://gist.github.com/johalun/c9383ff03cb29e12c3f4978e06ca6413

Not sure how to interpret this but it looks like it fails to match rtwn0 at
https://gist.github.com/johalun/c9383ff03cb29e12c3f4978e06ca6413#file-gistfile1-txt-L761




>>> danny
>>>
>>> > ___
>>> > 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: usb rtwn not loaded properly at boot

[Johannes Lundberg]

On Tue, Sep 18, 2018 at 9:43 AM Johannes Lundberg 
wrote:

>
>
> On Tue, Sep 18, 2018 at 9:39 AM Daniel Braniss 
> wrote:
>
>>
>>
>> > On 18 Sep 2018, at 10:32, Johannes Lundberg  wrote:
>> >
>> > On Tue, Sep 18, 2018 at 9:27 AM Yuri Pankov  wrote:
>> >
>> >> Johannes Lundberg wrote:
>> >>> Hi
>> >>>
>> >>> I have (with 12-ALPHA5)
>> >>>
>> >>> /boot/loader.conf
>> >>> rtwn_load="YES"
>> >>> if_urtw_usb_load="YES"
>> >>
>> >> rtwn(4) thinks this should be if_rtwn_usb_load="YES".
>> >>
>> >
>> > Ah yes. Sorry about that. I still suffer confusion from the rename.
>> > Still, it doesn't change anything since if_rtwn_usb was loaded anyway.
>> >
>> >
>> >>> /etc/rc.conf
>> >>> wlans_rtwn0="wlan0"
>> >>> ifconfig_wlan0="WPA DHCP"
>> >>>
>> >>> but still after boot only lo0 exists and all modules are loaded.
>> >>>
>> >>> Manually running
>> >>> ifconfig wlan0 create wlandev rtwn0
>> >>> sets up the interface correctly.
>> >>>
>> >>> In my kernel config I have
>> >>> MODULES_OVERRIDE="usb rtwn_usb rtwn "
>> >>>
>> >>> I'm pretty sure this has worked before... Any clues?
>> >>
>>
>>
>> devd is not calling netif!
>> try running ’service netif start’ and see what happens.
>>
>
> Yep that enables wlan0!
>
>
With wlan0 up and running, unplug and re-plug the wifi adapter will create
rtwn0 device but no wlan0.
Firmware was missing so I added rtwnfw to MODULES_OVERRIDE but it makes no
difference for this problem.


>> danny
>>
>> > ___
>> > 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: usb rtwn not loaded properly at boot

[Johannes Lundberg]

On Tue, Sep 18, 2018 at 9:39 AM Daniel Braniss  wrote:

>
>
> > On 18 Sep 2018, at 10:32, Johannes Lundberg  wrote:
> >
> > On Tue, Sep 18, 2018 at 9:27 AM Yuri Pankov  wrote:
> >
> >> Johannes Lundberg wrote:
> >>> Hi
> >>>
> >>> I have (with 12-ALPHA5)
> >>>
> >>> /boot/loader.conf
> >>> rtwn_load="YES"
> >>> if_urtw_usb_load="YES"
> >>
> >> rtwn(4) thinks this should be if_rtwn_usb_load="YES".
> >>
> >
> > Ah yes. Sorry about that. I still suffer confusion from the rename.
> > Still, it doesn't change anything since if_rtwn_usb was loaded anyway.
> >
> >
> >>> /etc/rc.conf
> >>> wlans_rtwn0="wlan0"
> >>> ifconfig_wlan0="WPA DHCP"
> >>>
> >>> but still after boot only lo0 exists and all modules are loaded.
> >>>
> >>> Manually running
> >>> ifconfig wlan0 create wlandev rtwn0
> >>> sets up the interface correctly.
> >>>
> >>> In my kernel config I have
> >>> MODULES_OVERRIDE="usb rtwn_usb rtwn "
> >>>
> >>> I'm pretty sure this has worked before... Any clues?
> >>
>
>
> devd is not calling netif!
> try running ’service netif start’ and see what happens.
>

Yep that enables wlan0!


> danny
>
> > ___
> > 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: usb rtwn not loaded properly at boot

[Johannes Lundberg]

On Tue, Sep 18, 2018 at 9:27 AM Yuri Pankov  wrote:

> Johannes Lundberg wrote:
> > Hi
> >
> > I have (with 12-ALPHA5)
> >
> > /boot/loader.conf
> > rtwn_load="YES"
> > if_urtw_usb_load="YES"
>
> rtwn(4) thinks this should be if_rtwn_usb_load="YES".
>

Ah yes. Sorry about that. I still suffer confusion from the rename.
Still, it doesn't change anything since if_rtwn_usb was loaded anyway.


> > /etc/rc.conf
> > wlans_rtwn0="wlan0"
> > ifconfig_wlan0="WPA DHCP"
> >
> > but still after boot only lo0 exists and all modules are loaded.
> >
> > Manually running
> > ifconfig wlan0 create wlandev rtwn0
> > sets up the interface correctly.
> >
> > In my kernel config I have
> > MODULES_OVERRIDE="usb rtwn_usb rtwn "
> >
> > I'm pretty sure this has worked before... Any clues?
>
___
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"

usb rtwn not loaded properly at boot

[Johannes Lundberg]

Hi

I have (with 12-ALPHA5)

/boot/loader.conf
rtwn_load="YES"
if_urtw_usb_load="YES"

/etc/rc.conf
wlans_rtwn0="wlan0"
ifconfig_wlan0="WPA DHCP"

but still after boot only lo0 exists and all modules are loaded.

Manually running
ifconfig wlan0 create wlandev rtwn0
sets up the interface correctly.

In my kernel config I have
MODULES_OVERRIDE="usb rtwn_usb rtwn "

I'm pretty sure this has worked before... Any clues?
___
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: drm / drm2 removal in 12

[Johannes Lundberg]

On Sun, Aug 26, 2018 at 00:25 blubee blubeeme  wrote:

> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav  wrote:
>
> > blubee blubeeme  writes:
> > > True on both points my tone is just a reflection of attitudes of the
> > > individuals that I am currently addressing.
> >
> > Well, congratulations on alienating absolutely everybody you have
> > interacted with on this topic.
> >
> > > Some people enjoy making contributions w/o waving a banner constantly
> > > wanting acknowledgement, a pat on the head and good job from everyone.
> >
> > The only person I see constantly craving attention and validation from
> > others here is you.
> >
> > > How far will core FreeBSD bend over backwards to accommodate these
> > > devs.
> >
> > The core team does not decide what goes into the tree or not.  The
> > developers do.
> >
> > > This is the beauty of an open source project, we bring the best to the
> > > table, [...]
> >
> > Who exactly is “we” here?  You are not a member of the project, you do
> > not speak for the project, and after seeing how you treat our fellow
> > developers, our friends, most of us want nothing to do with you.  If
> > can't live with that, I'm sure you can figure out how to install Linux.
> >
> > DES
> > --
> > Dag-Erling Smørgrav - d...@des.no
>
>
> Some on here want to attack my personality because they think that I am
> abrasive, fine but that's not the issue.
>
> Some claim that they run the code and it works wonderful for them with no
> issues, again that's lovely keep on running the code.
>
>  Nevertheless let me restate the point that you guys are all seeming to
> miss; If you can go out and build custom kernels with custom options and
> out of mainline tree that's fine, keep doing that until you have something
> that's production ready and as easy to install as the rest of FreeBSD
> system.
>
> The graphics stack on FreeBSD is pretty bad as it stands but all the
> documentation currently out there is about using it as it stands now.
>
> Why do you need to rip out the current graphics drivers which will break
> systems for the vast majority of silent users who will not complain and
> just leave?
>
>  A little background 
> Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update
> their phones to the latest android version?
>
> It's because the Linux kernel is such a mess they know it's a waste of
> resources to try. You should not have to ask how or why I know this but if
> it's unclear I was in the field.
> ---
>
> Now you guys who claim to only be hobbyist doing this in their free time
> expect to maintain this when those companies with all their resources
> cannot?
>
> Those 30,000 ports many of them bring bugs with them because of this
> Linuxkpi stuff. Just recently there was a user who said google earth
> doesn't work the answer was it doesn't work and that's that.
>
> They get ported and then get dropped so while the ports tree is large, if
> you actually try to use some of those programs they are broken, maintenance
> hell for the developers and confusion for the users.
>
> Johannes Lundberg I know that you are one of the main working on this
> linuxkpi stuff but anyone else is free to answer as well.
>
> Let's have an open discussion why do you need to remove the current
> graphics stack to continue with your work?


This has been discussed over and over on the mailing list and I don’t think
anyone wants to do it over again so please feel free to search the
archives.

You’re misinformed. We are not removing anything for anyone. We are moving
it to ports.
“pkg install drm-legacy-kmod” will install those drivers for you that were
earlier in base. I thought we have been clear about this but maybe we
haven’t been clear enough.



> ___
> 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: drm / drm2 removal in 12

[Johannes Lundberg]

Hi Owen

I'm truly sorry you feel this way about our work.

At first I was thinking "I'm not going to feed the troll" but after giving
what you're writing some more thought it seems maybe you have misunderstood
some things that I want to clarify to make sure there's no misunderstanding
by you or any one else reading this.

There are almost 30,000 ports now in the ports tree. Many are ported from
various operating systems. Many are from Linux, GPL'd and in most cases we
depend on them for running the graphical desktop of our choice on FreeBSD.

However, these ports are all optional. You don't have to install any of
them if you don't want to, this includes the new generation GPU drivers and
LinuxKPI.  Linux is not "moving in to" the FreeBSD kernel.

For those of you who want a "pure" BSD experience, running without X is
just fine, or finding a pure BSD solution if one exists. For those who
don't want Linux derived graphics drivers (which by the way the ones in
sys/dev/drm2/ also are), nothing is forcing you to use them. Vesa of scfb
works beautifully for a software rendered graphical user interface. Nvidia
provides a native driver for FreeBSD if you have their hardware.

CURRENT breaks sometimes, not only because of graphics. This is the nature
of bleeding edge but we work hard to keep breakage to a minimal. For those
of you who wish to run a more stable system, use a stable release.

The graphics team at FreeBSD has new members and we're still trying to find
our way regarding release schedule, support and other things. It's still a
WIP and the road has been bumpy. There is still a lot to do for us to catch
up and be able to provide a consistent experience for everyone.

Again, we're doing the best we can with the resources we have. There's no
way the few developers we have could develop and maintain native GPU
drivers, spanning 20 years on three different hardware platforms.
Especially considering how fast moving target the graphics hardware is.

I know nothing I say matters to you, Owen, but your comments are quite
extreme and contain false doomsday propaganda.. This mail is more to
provide some information from the graphics team for anyone reading this so
they don't fall for false propaganda.


On Sat, Aug 25, 2018 at 12:45 PM blubee blubeeme 
wrote:

> On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen <
> sh+freebsd-curr...@codevoid.de>
> wrote:
>
> > blubee blubeeme wrote:
> > > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote:
> > >> I've been personally using the new DRM bits since almost day one. I
> > >> haven't found it to be unstable in the slightest. Compared to not
> > >> having it and being forced to run 5+ year old hardware, it's been a
> > >> huge blessing for those of us who care about running FreeBSD as a
> > >> modern desktop / laptop.
> > >>
> > >> FreeBSD being an open source project, you are welcome to contribute
> > >> back your work anytime. But since I don't imagine we'll see that
> > >> patch coming anytime soon, I'll stick with this new LinuxKPI-powered,
> > >> Plasma-desktop running awesomeness.
> > >>
> > >> (Written from my brand new Lenovo P71 which worked flawlessly out of
> > >> box)
> > >
> > > Please tell me more about you're modern hardware, Kris Vice President
> > > of Engineering at iXsystems.
> > >
> > > Try asking a person who doesn't run server infrastructure software and
> > > hardware to get that stuff up and running, would you?
> >
> > Do you want to ask me? I'm mostly a private individual and linux/debian
> > user that got fed up with the Linux fragmentation and direction of
> > development (from a user perspective). I found my new home in FreeBSD.
> > I migrated my (hobby) root server and have a few jails up and running
> > and doing random stuff on them for myself and friends.
> >
> > Key to this was that I was able to get FreeBSD up and running on my
> > Laptop - with the drm-next kmod - and use it daily to get used to it and
> > learn about it. Actually it was a pain in the ass because back then I
> > had to learn how to make -current run and even worse, I had to use the
> > drm-next graphics branch from a github repository which wasn't even
> > on the main FreeBSD account. I was forced to update the kernel every
> > once in a while because the pkg update would complain otherwise. It
> > frequently broke and I had to deal with it and learn how to recover it.
> >
> > The alternative would have been to go back to Linux, which has a whole
> > lot more to complain about. So I stayed. And I'm happy with it.
> >
> > I accepted all this trouble to have decent graphics support. In all
> > the time I had to fight -current issues a lot more than anything
> > drm/graphics related. This stuff was always stable for me.
> >
> > I saw a few people trying out FreeBSD. And the first thing after the
> > Installation is always: Graphics and Wifi. That's what people need.
> >
> > These are "desktop needs", where supporting new hardware fast is more
> > important than being rock stable

Re: priority of paths to kernel modules?

[Johannes Lundberg]

On Fri, Aug 24, 2018 at 5:43 PM Warner Losh  wrote:

>
>
> On Fri, Aug 24, 2018 at 9:27 AM Johannes Lundberg 
> wrote:
>
>> There's some tricks we can do here.
>>>
>>> First, I talked to Kyle yesterday about augmenting the Lua loader to
>>> have a X_loadflag option. Some background. We look at a lot of X_ flags
>>> for loading modules. X_load=yes being the most familiar. One way to avoid
>>> POLA would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so
>>> that by default, we'd run load -K i915kms instead of load i915kms. We'd
>>> augment the built-in load command so it knew that -K means 'add the kernel
>>> to the path last rather than first'. This would solve one of the POLA
>>> violations in a very targeted way: people that put i915kms_load=YES in
>>> their loader.conf wouldn't be surprised by this transition. It would be at
>>> the cost of 2 entires in loader.conf, I believe, and it shuts down one
>>> vector of hassle for our users. People do this, btw, to get more lines /
>>> columns in the BIOS boot environment for their console, so it's not an
>>> unreasonable path to attend to.
>>>
>>> We could also have a sysctl that we could set to override specific
>>> modules locations. This would allow the graphics port to have a rc script
>>> that sets this up so when X11 goes to automatically load the module, the
>>> right one gets loaded. This would solve the issue for the people that 'do
>>> nothing' except install the port. While it's a small bit of programming for
>>> the kernel, it's a general mechanism that's laser-focused on exceptions to
>>> the rule w/o wholesale changes. This would solve the other main vector and
>>> motivator for the 'kill it with fire' calls that doesn't leave behind a
>>> scorched earth.
>>>
>>
>>
>> Just a small note here. With the modesetting driver (which is replacing
>> the deprecated xf86-video-intel and is built into Xorg), X will not load
>> the drm driver for you. It has to be done by putting kld_list="i915kms" in
>> your rc.conf (I don't think loading drm next modules from /boot/loader.conf
>> works).
>>
>
> I have done this in the past, but I had to jump through a number of hoops
> to do it. I'll have to buy a laptop and see if I can do it with modern gear
> and modern software.
>
> But if X isn't loading the module for you, that makes the problem much,
> much easier.
>

Yes for Intel+modesetting. I forgot to mention that for amdgpu and radeon,
X might still do it. Need to test to confirm. However, there's nothing
stopping you from loading it in rc.conf before starting X (which is
probably better anyway).


> Warner
>
___
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: priority of paths to kernel modules?

[Johannes Lundberg]

On Fri, Aug 24, 2018 at 5:20 PM Warner Losh  wrote:

>
>
> On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
>
>> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg 
>> wrote:
>> > >
>> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy 
>> wrote:
>> > >
>> > > > No we're not. x86 and PPC will be disconnected from the build in a
>> > > > subsequent commit during the freeze. Warner was simply too tired to
>> > > > communicate this adequately and still meet the timeline that RE
>> wanted.
>> > > >
>> > > > And take heart. Even if Warner weren't trying to balance the needs
>> of RE
>> > > > and the graphics team + user base on post-2013 hardware - the
>> graphics
>> > > > doesn't _have_ to support 12.x. it's well within the team's rights
>> to
>> > > > simply declare 12.x as unsupported. The team is welcome to simply
>> say we
>> > > > support 11.x and 13.x. The failing was largely in that "expected"
>> processes
>> > > > are not documented and not well communicated.
>>
>> The deprececation policy is documented, though poorly, and I agree in
>> the spirit that much of the processes here in the FreeBSD project are
>> sadly in a similiar situation.
>>
>
> To say this is a learning situation for all those involved is not an
> understatement.
>
>
>> Since we are in code freeze we could all go work on those things :-)
>>
>
> Yes. That's why I wanted all removals to wait until after the freeze so
> that I could get the deprecation policy hammered out better, including a
> common set of guidelines to know when to remove, when to disable, and how
> to ease things out of the tree in as a non-disruptive way as possible.
>
>
>> > > > Warner is acting in good faith. He's just trying to balance many
>> demands
>> > > > in a compressed time period.
>> > > >
>> > > > Cheers.
>> > > > -M
>> > > >
>> > > >
>> > > OK, thanks for the clarification. That's a good compromise I guess.
>> > >
>> > > Still, regardless of drm, aren't modules in overlay folders suppose
>> to have
>> > > higher priority than those in the kernel folder?
>>
>> I agree, but usually do not depend on that to get what I need,
>> but rather resort to any special needs by force loading with
>> /boot/loader.conf modules that are loaded out of order.
>>
>
> There's some tricks we can do here.
>
> First, I talked to Kyle yesterday about augmenting the Lua loader to have
> a X_loadflag option. Some background. We look at a lot of X_ flags for
> loading modules. X_load=yes being the most familiar. One way to avoid POLA
> would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that
> by default, we'd run load -K i915kms instead of load i915kms. We'd augment
> the built-in load command so it knew that -K means 'add the kernel to the
> path last rather than first'. This would solve one of the POLA violations
> in a very targeted way: people that put i915kms_load=YES in their
> loader.conf wouldn't be surprised by this transition. It would be at the
> cost of 2 entires in loader.conf, I believe, and it shuts down one vector
> of hassle for our users. People do this, btw, to get more lines / columns
> in the BIOS boot environment for their console, so it's not an unreasonable
> path to attend to.
>
> We could also have a sysctl that we could set to override specific modules
> locations. This would allow the graphics port to have a rc script that sets
> this up so when X11 goes to automatically load the module, the right one
> gets loaded. This would solve the issue for the people that 'do nothing'
> except install the port. While it's a small bit of programming for the
> kernel, it's a general mechanism that's laser-focused on exceptions to the
> rule w/o wholesale changes. This would solve the other main vector and
> motivator for the 'kill it with fire' calls that doesn't leave behind a
> scorched earth.
>


Just a small note here. With the modesetting driver (which is replacing the
deprecated xf86-video-intel and is built into Xorg), X will not load the
drm driver for you. It has to be done by putting kld_list="i915kms" in your
rc.conf (I don't think loading drm next modules from /boot/loader.conf
works).


> The people that do nothing, not even in

Re: priority of paths to kernel modules?

[Johannes Lundberg]

On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy  wrote:

> No we're not. x86 and PPC will be disconnected from the build in a
> subsequent commit during the freeze. Warner was simply too tired to
> communicate this adequately and still meet the timeline that RE wanted.
>
> And take heart. Even if Warner weren't trying to balance the needs of RE
> and the graphics team + user base on post-2013 hardware - the graphics
> doesn't _have_ to support 12.x. it's well within the team's rights to
> simply declare 12.x as unsupported. The team is welcome to simply say we
> support 11.x and 13.x. The failing was largely in that "expected" processes
> are not documented and not well communicated.
>
> Warner is acting in good faith. He's just trying to balance many demands
> in a compressed time period.
>
> Cheers.
> -M
>
>
OK, thanks for the clarification. That's a good compromise I guess.

Still, regardless of drm, aren't modules in overlay folders suppose to have
higher priority than those in the kernel folder?



>
>
>
> On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg 
> wrote:
>
>> Hi
>>
>> Since we now stuck with drm2 in base for a few more years I have an idea
>> would make things much smoother for many of us, hugely reduce the amount
>> of
>> bug reports we get and I think would be beneficial in other ways too.
>>
>> Current I run with something like this in /boot/loader.conf
>>
>>
>> module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays"
>>
>> So I expect modules to be loaded in that order, with /boot/
>> LAST.
>>
>> However, if you look at this
>> sysctl kern.module_path
>> kern.module_path:
>>
>> /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays
>>
>> /boot/kernel is inserted first and probably modules in /boot/kernel have
>> the highest priority. This is also proven by everyone wanting to use
>> drm*kmods that get drm.ko from base loaded instead of the installed in
>> /boot/modules.
>>
>> Please correct me if I'm wrong but if my understanding is correct this is
>> a
>> flaw and /boot/ should be inserted last so that any overlays or
>> custom modules have higher priority than the default ones.
>>
>> I can imagine this is also useful when building custom modules and you
>> don't want to overwrite or delete the default one in /boot/kernel...
>>
>> Cheers
>> ___
>> 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"

priority of paths to kernel modules?

[Johannes Lundberg]

Hi

Since we now stuck with drm2 in base for a few more years I have an idea
would make things much smoother for many of us, hugely reduce the amount of
bug reports we get and I think would be beneficial in other ways too.

Current I run with something like this in /boot/loader.conf

module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays"

So I expect modules to be loaded in that order, with /boot/ LAST.

However, if you look at this
sysctl kern.module_path
kern.module_path:
/boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays

/boot/kernel is inserted first and probably modules in /boot/kernel have
the highest priority. This is also proven by everyone wanting to use
drm*kmods that get drm.ko from base loaded instead of the installed in
/boot/modules.

Please correct me if I'm wrong but if my understanding is correct this is a
flaw and /boot/ should be inserted last so that any overlays or
custom modules have higher priority than the default ones.

I can imagine this is also useful when building custom modules and you
don't want to overwrite or delete the default one in /boot/kernel...

Cheers
___
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: Suspend, resume, UEFI, CSM, drm-stable-kmod and drm-next-kmod with Radeon HD 7570M

[Johannes Lundberg]

On Wed, Aug 22, 2018 at 6:00 PM Graham Perrin 
wrote:

> On 22/08/2018 17:50, Pete Wright wrote:
> > not sure this will address this specific issue - but have you tested
> setting this sysctl knob and seeing if that fixes your resume issues:
> > hw.acpi.reset_video=1
>
> Thanks, I'll be away for around three weeks, I'll test some time in
> September.
>

Hi

Make sure you also update the drm packages from ports when you're back.
There was an issue causing kernel panic for amdgpu and radeon on
suspend/resume that has been fixed. It should be available in an updated
pkg later this week.
Try drm-stable or drm-devel. drm-devel will require a rather recent
12/13-CURRENT.



>
> ___
> 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: Make drm drivers use MTRR write-combine

[Johannes Lundberg]

On Tue, Aug 14, 2018 at 9:54 PM Johannes Lundberg 
wrote:

>
>
> On Tue, Aug 14, 2018 at 3:39 PM Konstantin Belousov 
> wrote:
>
>> On Tue, Aug 14, 2018 at 08:55:36AM -0500, Eric van Gyzen wrote:
>> > On 8/14/18 4:12 AM, Johannes Lundberg wrote:
>> > > Hi
>> > >
>> > > Something that we have seen for a long time on FreeBSD is the boot
>> message
>> > >
>> > > Failed to add WC MTRR for [0xd000-0xdfff]: -22; performance
>> may
>> > > suffer
>> > >
>> > > Taking a closer look at this with memcontrol I can see that the 256 MB
>> > > region that DRM wants to set as WC is already covered by this entry
>> > > 0xc000/0x4000 BIOS uncacheable set-by-firmware active
>> > >
>> > > Similar on both my Skylake and Broadwell systems.
>> > I see something similar on my Dell XPS 13 with a Kaby Lake R:
>> >
>> > Failed to add WC MTRR for [0x9000-0x9fff]: -22; performance may
>> > suffer
>> >
>> > 0x8000/0x8000 BIOS uncacheable set-by-firmware active
>> >
>> > The only mappings in this range are MMIO:
>> >
>> > machdep.efi_map:
>> >Type Physical  Virtual   #Pages Attr
>> > [snip]
>> > MemoryMappedIO e000   0xe000 0001 RUNTIME
>> > MemoryMappedIO fe00   0xfe00 0011 UC RUNTIME
>> > MemoryMappedIO fec0   0xfec0 0001 UC RUNTIME
>> > MemoryMappedIO fee0   0xfee0 0001 UC WT WB WP RUNTIME
>> > MemoryMappedIO ff00   0xff00 1000 UC WT WB WP RUNTIME
>>
>> Yes, the cause of the message is that current x86 mtrr code is not
>> sufficient to handle this situation. You have BIOS-configured variable
>> range MTRR which covers upper half of the low 4G, as uncacheable (UC).
>> It is reasonable for BIOS to set it up this way because this is where
>> PCIe BARs and other devices MMIO regions are located.
>>
>> One of the BARs there is the GPU aperture that really should be WC
>> (write-combining). There are two ways to achieve this: split the UC
>> variable-length MTRR range into three, UC/WC/UC, which would require
>> three MTRRs to cover. This is what current x86_mem.c code does not
>> support.
>>
>> Another way is to set WC mode in the page table entries (PTEs) using
>> Page Attribute Table (PAT), for all PTEs. According to the rules of
>> combination of the memory access types between MTRR and PAT, WC in PAT
>> and any access mode in MTRR gives effective WC.
>>
>> I saw the same warning when I initially ported GEM. My code used WC PAT
>> type, which makes the warning cosmetical, and which made me to not add
>> MTRR split. If new drm driver also consistently uses WC memattr when
>> creating aperture mappings, then the warning can be ignored as well.
>>
>
> Hi Kib
>
> Thanks for the detailed answer. This might already be the case for the out
> of tree drivers as well. From what I read about the VESA driver the
> performance difference should be quite big w/o WC and I haven't noticed and
> performance issues with the newer drivers at all.
>
> I will confirm this tomorrow.
>

Yeah, seems like it's already done.

https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.15/linuxkpi/gplv2/src/linux_page.c#L260

https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.15/drivers/gpu/drm/i915/i915_gem_gtt.c#L415
https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.15/drivers/gpu/drm/ttm/ttm_page_alloc.c#L534


>
> ___
>> 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: Make drm drivers use MTRR write-combine

[Johannes Lundberg]

On Tue, Aug 14, 2018 at 3:39 PM Konstantin Belousov 
wrote:

> On Tue, Aug 14, 2018 at 08:55:36AM -0500, Eric van Gyzen wrote:
> > On 8/14/18 4:12 AM, Johannes Lundberg wrote:
> > > Hi
> > >
> > > Something that we have seen for a long time on FreeBSD is the boot
> message
> > >
> > > Failed to add WC MTRR for [0xd000-0xdfff]: -22; performance may
> > > suffer
> > >
> > > Taking a closer look at this with memcontrol I can see that the 256 MB
> > > region that DRM wants to set as WC is already covered by this entry
> > > 0xc000/0x4000 BIOS uncacheable set-by-firmware active
> > >
> > > Similar on both my Skylake and Broadwell systems.
> > I see something similar on my Dell XPS 13 with a Kaby Lake R:
> >
> > Failed to add WC MTRR for [0x9000-0x9fff]: -22; performance may
> > suffer
> >
> > 0x8000/0x8000 BIOS uncacheable set-by-firmware active
> >
> > The only mappings in this range are MMIO:
> >
> > machdep.efi_map:
> >Type Physical  Virtual   #Pages Attr
> > [snip]
> > MemoryMappedIO e000   0xe000 0001 RUNTIME
> > MemoryMappedIO fe00   0xfe00 0011 UC RUNTIME
> > MemoryMappedIO fec0   0xfec0 0001 UC RUNTIME
> > MemoryMappedIO fee0   0xfee0 0001 UC WT WB WP RUNTIME
> > MemoryMappedIO ff00   0xff00 1000 UC WT WB WP RUNTIME
>
> Yes, the cause of the message is that current x86 mtrr code is not
> sufficient to handle this situation. You have BIOS-configured variable
> range MTRR which covers upper half of the low 4G, as uncacheable (UC).
> It is reasonable for BIOS to set it up this way because this is where
> PCIe BARs and other devices MMIO regions are located.
>
> One of the BARs there is the GPU aperture that really should be WC
> (write-combining). There are two ways to achieve this: split the UC
> variable-length MTRR range into three, UC/WC/UC, which would require
> three MTRRs to cover. This is what current x86_mem.c code does not
> support.
>
> Another way is to set WC mode in the page table entries (PTEs) using
> Page Attribute Table (PAT), for all PTEs. According to the rules of
> combination of the memory access types between MTRR and PAT, WC in PAT
> and any access mode in MTRR gives effective WC.
>
> I saw the same warning when I initially ported GEM. My code used WC PAT
> type, which makes the warning cosmetical, and which made me to not add
> MTRR split. If new drm driver also consistently uses WC memattr when
> creating aperture mappings, then the warning can be ignored as well.
>

Hi Kib

Thanks for the detailed answer. This might already be the case for the out
of tree drivers as well. From what I read about the VESA driver the
performance difference should be quite big w/o WC and I haven't noticed and
performance issues with the newer drivers at all.

I will confirm this tomorrow.

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

Make drm drivers use MTRR write-combine

[Johannes Lundberg]

Hi

Something that we have seen for a long time on FreeBSD is the boot message

Failed to add WC MTRR for [0xd000-0xdfff]: -22; performance may
suffer

Taking a closer look at this with memcontrol I can see that the 256 MB
region that DRM wants to set as WC is already covered by this entry
0xc000/0x4000 BIOS uncacheable set-by-firmware active

Similar on both my Skylake and Broadwell systems.

The linuxkpi wrapper can be found here:
https://github.com/FreeBSDDesktop/kms-drm/blob/drm-v4.15/linuxkpi/gplv2/src/linux_mtrr.c

There doesn't seem to exist a function for changing the properties of a sub
region:
https://github.com/FreeBSDDesktop/freebsd-base/blob/master/sys/dev/mem/memutil.c

Any ideas of a good solution to this? Can this region be blacklisted or is
there a safe way to split the big region into several regions with
different flags when the drm driver loads?

For reference, my AMD machine logs this
# dmesg | grep MTRR
Successfully added WC MTRR for [0xe000-0xefff]: 0;
# memcontrol list
--SNIP--
0xff000/0x1000 BIOS write-protect fixed-base fixed-length set-by-firmware
active
0x0/0x8000 BIOS write-back set-by-firmware active
0x8000/0x4000 BIOS write-back set-by-firmware active
0xc000/0x2000 BIOS write-back set-by-firmware active
0xe000/0x1000 drm write-combine active

Not sure if it's a BIOS or CPU vendor issue.
___
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: Early kernel boot log?

[Johannes Lundberg]

On Thu, Aug 9, 2018 at 9:29 AM Konstantin Belousov 
wrote:

> On Thu, Aug 09, 2018 at 08:54:31AM +0100, Johannes Lundberg wrote:
> > Hi
> >
> > So I believe the reason I'm not seeing and printf output in dmesg is that
> > it is too early in some functions.
> > For example
> > machdep.s
> >  getmemsize()
> >  add_efi_map_entries()
> >  etc
> >
> > However, these functions do contain debug printf statements so if they're
> > logging to somewhere, where/how can I see this?
> >
> > I also tried booting in bhyve too see if I could get any output via
> serial
> > console but nothing there either.
> Disable efi console, only leaving comconsole around, then set
> debug.late_console=0
> in loader.
>

Thanks for the tip. I found the comment in machdep.c that explains this
now.
However, running in bhyve with
console="comconsole" (not needed in bhyve I guess?)
debug.late_console=0

Boot hangs after
Booting...
output.
Caused by late_console=0.



> >
> > printfs in cpu_startup() does give me output in dmesg.
> >
> > Cheers
> > ___
> > 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"

Early kernel boot log?

[Johannes Lundberg]

Hi

So I believe the reason I'm not seeing and printf output in dmesg is that
it is too early in some functions.
For example
machdep.s
 getmemsize()
 add_efi_map_entries()
 etc

However, these functions do contain debug printf statements so if they're
logging to somewhere, where/how can I see this?

I also tried booting in bhyve too see if I could get any output via serial
console but nothing there either.

printfs in cpu_startup() does give me output in dmesg.

Cheers
___
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: Unkillable linux processes

[Johannes Lundberg]

On Tue, Aug 7, 2018 at 21:16 Konstantin Belousov 
wrote:

> On Tue, Aug 07, 2018 at 08:54:39PM +0100, Johannes Lundberg wrote:
> > Hi
> >
> > I seem to have some unkillable Linux processes...
> > This is on my AMD Ryzen, the exact same installation on my Broadwell
> laptop
> > does not show this behavior.
> > At the second top output, the three remaining processes' cpu usage is
> > fluctuating, just as when they are running normally.
> > Kernel is from one or two days ago with kib's patch that I got the other
> > day.
> Exactly which patch ?  There was a followup to the initial change.
>
> Both are committed as of r337431.


Ok. I will try a new fresh kernel build tomorrow.
Thanks!


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

Unkillable linux processes

[Johannes Lundberg]

Hi

I seem to have some unkillable Linux processes...
This is on my AMD Ryzen, the exact same installation on my Broadwell laptop
does not show this behavior.
At the second top output, the three remaining processes' cpu usage is
fluctuating, just as when they are running normally.
Kernel is from one or two days ago with kib's patch that I got the other
day.

root@amd:~ # top
  PID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU
COMMAND
  978 boinc 3 155  i31   129M64M futex3   0:52 100.74%
wcgrid_zika_vina_7.
  979 boinc 3 155  i31   112M47M futex2   0:56  99.24%
wcgrid_oet1_vina_7.
  980 boinc 2 155  i31   150M87M CPU3 3   0:46  97.66%
wcgrid_mip1_rosetta
  977 boinc 3 155  i31   109M43M futex1   0:56  97.39%
wcgrid_oet1_vina_7.

root@amd:~ # service boinc-client stop
Stopping boinc_client.
Waiting for PIDS: 892.
root@amd:~ # top

last pid:  1003;  load averages:  3.18,  2.04,
0.94  up 0+00:05:31  20:48:06
25 processes:  1 running, 21 sleeping, 3 stopped
CPU:  0.0% user,  0.0% nice, 73.8% system,  0.0% interrupt, 26.2% idle
Mem: 157M Active, 2736K Inact, 300M Wired, 162M Buf, 2907M Free
Swap:

  PID USERNAMETHR PRI NICE   SIZERES STATEC   TIMEWCPU
COMMAND
  977 boinc 2  20  i31   110M44M STOP 0   3:57 100.00%
wcgrid_oet1_vina_7.
  979 boinc 2  20  i31   113M47M STOP 0   3:54  97.02%
wcgrid_oet1_vina_7.
  978 boinc 2  20  i31   130M64M STOP 0   3:50  96.12%
wcgrid_zika_vina_7.

root@amd:~ # procstat -ak | grep wcgrid
  977 100162 wcgrid_oet1_vina_7. -   mi_switch
thread_suspend_switch thread_single exit1 linux_exit_group ia32_syscall
int0x80_syscall_common
  977 100172 wcgrid_oet1_vina_7. -   witness_checkorder
__mtx_lock_flags linux_sys_futex ia32_syscall int0x80_syscall_common
  978 100163 wcgrid_zika_vina_7. -   mi_switch
thread_suspend_switch thread_single exit1 linux_exit_group ia32_syscall
int0x80_syscall_common
  978 100174 wcgrid_zika_vina_7. -   __mtx_lock_flags
futex_put linux_sys_futex ia32_syscall int0x80_syscall_common
  979 100132 wcgrid_oet1_vina_7. -   mi_switch
thread_suspend_switch thread_single exit1 linux_exit_group ia32_syscall
int0x80_syscall_common
  979 100171 wcgrid_oet1_vina_7. -   linux_sys_futex
ia32_syscall int0x80_syscall_common
___
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"

Need to reserve Intel graphics memory in early boot

[Johannes Lundberg]

Hi

I'm working on getting the graphics drivers up to Linux 4.16 version and
there has been a patch for Intel gpus that require some code in early boot.

The problem is that no all bios report the memory allocated for the gpu,
called stolen memory, correctly so on some configurations the OS can
reclaim this memory during boot that thus it's not accessible to the gpu
driver (at least that is my understanding). Drivers need the stolen memory
for frame buffer compression (fbc) to work (maybe more features as well
depend on stolen memory). The purpose of fbc is to reduce power consumption.

So, what we need to do is get the base and size of the stolen memory and
reserve it before the OS have a chance to claim it. This information will
be stored in a global variable that the drm i915 driver can later read.

The Linux implementation can be found here:
https://elixir.bootlin.com/linux/v4.16/source/arch/x86/kernel/early-quirks.c#L539

The drm and i915 driver code are dual licensed but I'm not sure about the
code in the file above, it might be GPL only.

Anyone feeling up to doing this? Or if you have any pointers as to where
would be a good place to implement this in FreeBSD, I can give it a shot.

Cheers
___
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: Linux process causes kernel panic

[Johannes Lundberg]

On Sat, Aug 4, 2018 at 3:22 PM Konstantin Belousov 
wrote:

> On Sat, Aug 04, 2018 at 01:12:17PM +0100, Johannes Lundberg wrote:
> > No panic over night with that tunable so it seems you're on the right
> > track.
>
> Please try this, on top of r337316.
>

Been running boinc client now with 4 linux processes at 100% cpu load with
this patch for a while. So far so good.


> diff --git a/sys/amd64/linux/linux_machdep.c
> b/sys/amd64/linux/linux_machdep.c
> index 6c5b014853f..434ea0eac07 100644
> --- a/sys/amd64/linux/linux_machdep.c
> +++ b/sys/amd64/linux/linux_machdep.c
> @@ -78,6 +78,9 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>
> +#include 
> +#include 
> +
>  #include 
>  #include 
>  #include 
> @@ -88,8 +91,6 @@ __FBSDID("$FreeBSD$");
>  #include 
>  #include 
>
> -#include 
> -
>  int
>  linux_execve(struct thread *td, struct linux_execve_args *args)
>  {
> @@ -276,3 +277,48 @@ linux_set_cloned_tls(struct thread *td, void *desc)
>
> return (0);
>  }
> +
> +int futex_xchgl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
> +int futex_xchgl_smap(int oparg, uint32_t *uaddr, int *oldval);
> +DEFINE_IFUNC(, int, futex_xchgl, (int, uint32_t *, int *), static)
> +{
> +
> +   return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
> +   futex_xchgl_smap : futex_xchgl_nosmap);
> +}
> +
> +int futex_addl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
> +int futex_addl_smap(int oparg, uint32_t *uaddr, int *oldval);
> +DEFINE_IFUNC(, int, futex_addl, (int, uint32_t *, int *), static)
> +{
> +
> +   return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
> +   futex_addl_smap : futex_addl_nosmap);
> +}
> +
> +int futex_orl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
> +int futex_orl_smap(int oparg, uint32_t *uaddr, int *oldval);
> +DEFINE_IFUNC(, int, futex_orl, (int, uint32_t *, int *), static)
> +{
> +
> +   return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
> +   futex_orl_smap : futex_orl_nosmap);
> +}
> +
> +int futex_andl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
> +int futex_andl_smap(int oparg, uint32_t *uaddr, int *oldval);
> +DEFINE_IFUNC(, int, futex_andl, (int, uint32_t *, int *), static)
> +{
> +
> +   return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
> +   futex_andl_smap : futex_andl_nosmap);
> +}
> +
> +int futex_xorl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
> +int futex_xorl_smap(int oparg, uint32_t *uaddr, int *oldval);
> +DEFINE_IFUNC(, int, futex_xorl, (int, uint32_t *, int *), static)
> +{
> +
> +   return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
> +   futex_xorl_smap : futex_xorl_nosmap);
> +}
> diff --git a/sys/amd64/linux/linux_support.s
> b/sys/amd64/linux/linux_support.s
> index a9f02160be2..391f76414f2 100644
> --- a/sys/amd64/linux/linux_support.s
> +++ b/sys/amd64/linux/linux_support.s
> @@ -38,7 +38,7 @@ futex_fault:
> movl$-EFAULT,%eax
> ret
>
> -ENTRY(futex_xchgl)
> +ENTRY(futex_xchgl_nosmap)
> movqPCPU(CURPCB),%r8
> movq$futex_fault,PCB_ONFAULT(%r8)
> movq$VM_MAXUSER_ADDRESS-4,%rax
> @@ -49,25 +49,58 @@ ENTRY(futex_xchgl)
> xorl%eax,%eax
> movq%rax,PCB_ONFAULT(%r8)
> ret
> -END(futex_xchgl)
> +END(futex_xchgl_nosmap)
>
> -ENTRY(futex_addl)
> +ENTRY(futex_xchgl_smap)
> movqPCPU(CURPCB),%r8
> movq$futex_fault,PCB_ONFAULT(%r8)
> movq$VM_MAXUSER_ADDRESS-4,%rax
> cmpq%rax,%rsi
> ja  futex_fault
> +   stac
> +   xchgl   %edi,(%rsi)
> +   clac
> +   movl%edi,(%rdx)
> +   xorl%eax,%eax
> +   movq%rax,PCB_ONFAULT(%r8)
> +   ret
> +END(futex_xchgl_smap)
> +
> +ENTRY(futex_addl_nosmap)
> +   movqPCPU(CURPCB),%r8
> +   movq$futex_fault,PCB_ONFAULT(%r8)
> +   movq$VM_MAXUSER_ADDRESS-4,%rax
> +   cmpq%rax,%rsi
> +   ja  futex_fault
> +#ifdef SMP
> +   lock
> +#endif
> +   xaddl   %edi,(%rsi)
> +   movl%edi,(%rdx)
> +   xorl%eax,%eax
> +   movq%rax,PCB_ONFAULT(%r8)
> +   ret
> +END(futex_addl_nosmap)
> +
> +ENTRY(futex_addl_smap)
> +   movqPCPU(CURPCB),%r8
> +   movq$futex_fault,PCB_ONFAULT(%r8)
> +   movq$VM_MAXUSER_ADDRESS-4,%rax
> +   cmpq%rax,%rsi
> +   ja  futex_fault
> +   stac
>  #ifdef SMP
> lock
>  #endif
> xaddl   %edi,(%rsi)
> +   clac
> movl%edi,(%rdx)
&

IOMMU for GPUs

[Johannes Lundberg]

Hi

First I have to say I don't know much when it comes to virtual GPUs and
IOMMU. I'm trying to figure out what we have and what is missing in regards
to sharing the GPU to virtual guests on Intel and AMD and things like the
amdkfd driver (for Radeon open compute).

Looking at the state of IOMMU in FreeBSD there seem to be (what I guess is)
a general driver for Intel at /usr/src/sys/x86/iommu/.

Then there's the support for AMD's IOMMU in bhyve at
/usr/src/sys/amd64/vmm/io/iommu.c.

Without looking too much into the details my guess is we have an iommu
driver for Intel that Intel's i915/gvt can use but for AMD there's only the
specific implementation for bhyve and no general driver that other clients
can use... Or?

If anyone wants to work on this, it's up for grabs :)
We'll probably have to add some glue in linuxkpi as well.

Cheers
___
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: Linux process causes kernel panic

[Johannes Lundberg]

On Fri, Aug 3, 2018 at 9:43 PM Konstantin Belousov 
wrote:

> On Fri, Aug 03, 2018 at 09:26:08PM +0100, Johannes Lundberg wrote:
> > Hi
> >
> > After install new kernel+world built from today's checkout I keep getting
> > the same crash over and over. Never had this problem before. The previous
> > kernel was from 3 weeks ago.
> >
> > Looks familiar to anyone?
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address= 0xfffe665c
> > fault code= supervisor write data, protection violation
> > instruction pointer= 0x20:0x82282db3
> > stack pointer= 0x0:0xfe004c74c8c8
> > frame pointer= 0x0:0xfe004c74c980
> > 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= 1579 (wcgrid_zika_vina_7.)
> > trap number= 12
> > panic: page fault
> > cpuid = 0
> > time = 1533327428
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe004c74c580
> > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
> > panic() at panic+0x43/frame 0xfe004c74c640
> > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
> > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
> > trap() at trap+0x2ba/frame 0xfe004c74c7f0
> > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
> > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
> > 0xfe004c74c980 ---
> > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
> > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
> > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
> > Uptime: 7m29s
> > Dumping 411 out of 8056
> MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
> > Dump complete
>
> Post first 40 lines from the verbose dmesg boot of your machine.
>
> I have a guess what is going on, I need the dmesg to confirm.
> If my guess is correct, you can use a workaround by setting the
> "hw.cpu_stdext_disable=0x0010" tunable at the loader prompt for now.
>

No panic over night with that tunable so it seems you're on the right
track.
___
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: Linux process causes kernel panic

[Johannes Lundberg]

On Fri, Aug 3, 2018 at 9:43 PM Konstantin Belousov 
wrote:

> On Fri, Aug 03, 2018 at 09:26:08PM +0100, Johannes Lundberg wrote:
> > Hi
> >
> > After install new kernel+world built from today's checkout I keep getting
> > the same crash over and over. Never had this problem before. The previous
> > kernel was from 3 weeks ago.
> >
> > Looks familiar to anyone?
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address= 0xfffe665c
> > fault code= supervisor write data, protection violation
> > instruction pointer= 0x20:0x82282db3
> > stack pointer= 0x0:0xfe004c74c8c8
> > frame pointer= 0x0:0xfe004c74c980
> > 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= 1579 (wcgrid_zika_vina_7.)
> > trap number= 12
> > panic: page fault
> > cpuid = 0
> > time = 1533327428
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe004c74c580
> > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
> > panic() at panic+0x43/frame 0xfe004c74c640
> > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
> > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
> > trap() at trap+0x2ba/frame 0xfe004c74c7f0
> > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
> > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
> > 0xfe004c74c980 ---
> > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
> > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
> > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
> > Uptime: 7m29s
> > Dumping 411 out of 8056
> MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
> > Dump complete
>
> Post first 40 lines from the verbose dmesg boot of your machine.
>


Table 'FACP' at 0xd970da80
Table 'APIC' at 0xd970db90
APIC: Found table at 0xd970db90
APIC: Using the MADT enumerator.
Copyright (c) 1992-2018 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #86 d2391fd58c4(master)-dirty: Fri Aug  3 10:57:46 BST
2018
root@jd:/usr/obj/usr/src/amd64.amd64/sys/JD amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM
6.0.1)
WARNING: WITNESS option enabled, expect reduced performance.
Table 'FACP' at 0xd970da80
Table 'APIC' at 0xd970db90
Table 'FPDT' at 0xd970dc18
Table 'FIDT' at 0xd970dc60
Table 'MCFG' at 0xd970dd00
Table 'HPET' at 0xd970dd40
Table 'SSDT' at 0xd970dd78
Table 'UEFI' at 0xd970e230
Table 'SSDT' at 0xd970e278
Table 'ASF!' at 0xd970eef8
Table 'SSDT' at 0xd970ef98
Table 'SSDT' at 0xd970f4b8
Table 'SSDT' at 0xd9710030
Table 'SSDT' at 0xd97101f8
Table 'PCCT' at 0xd97105a0
Table 'SSDT' at 0xd9710610
Table 'SSDT' at 0xd97110d8
Table 'SSDT' at 0xd9715288
Table 'SLIC' at 0xd9719790
Table 'MSDM' at 0xd9719908
Table 'DMAR' at 0xd9719960
Table 'BGRT' at 0xd9719a10
ACPI: No SRAT table found
PPIM 0: PA=0xe000, VA=0x81a1, size=0x7e9000, mode=0x1
VT(efifb): resolution 1920x1080
Preloaded elf kernel "/boot/kernel.JD/kernel" at 0x8186c000.
Preloaded boot_entropy_cache "/boot/entropy" at 0x81875e58.
Preloaded elf obj module "/boot/kernel.JD/snd_hda.ko" at 0x81875eb0.
Preloaded elf obj module "/boot/kernel.JD/ums.ko" at 0x81876560.
Table 'FACP' at 0xd970da80
FACP: Found table at 0xd970da80
Calibrating TSC clock ... TSC clock: 2194965386 Hz
CPU: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz (2194.97-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306d4  Family=0x6  Model=0x3d  Stepping=4

Features=0xbfebfbff

Features2=0x7ffafbbf
  AMD Features=0x2c100800
  AMD Features2=0x121
  Structured Extended
Features=0x21c27ab
  XSAVE Features=0x1
  VT-x: Basic Features=0xda0400
Pin-Based Controls=0x7f
Primary Processor
Controls=0xfff9fffe
Secondary Processor
Controls=0x53cff
Exit Controls=0xda0400
Entry Controls=0xda0400
EPT Features=0x6334141
VPID Features=0xf01
  TSC: P-state invariant, performance statistics
Data TLB: 2 MByte or 4 MByte pages, 4-way set associative

Re: Linux process causes kernel panic

[Johannes Lundberg]

On Fri, Aug 3, 2018 at 9:34 PM Oliver Pinter 
wrote:

> Hi!
>
> On 8/3/18, Johannes Lundberg  wrote:
> > Hi
> >
> > After install new kernel+world built from today's checkout I keep getting
> > the same crash over and over. Never had this problem before. The previous
> > kernel was from 3 weeks ago.
> >
> > Looks familiar to anyone?
>
> Have you an Intel Broadwell or newer Intel CPU or an AMD CPU with SMAP
> support?
>

This is Intel Broadwell, Core i5.


> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address= 0xfffe665c
> > fault code= supervisor write data, protection violation
> > instruction pointer= 0x20:0x82282db3
> > stack pointer= 0x0:0xfe004c74c8c8
> > frame pointer= 0x0:0xfe004c74c980
> > 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= 1579 (wcgrid_zika_vina_7.)
> > trap number= 12
> > panic: page fault
> > cpuid = 0
> > time = 1533327428
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> > 0xfe004c74c580
> > vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
> > panic() at panic+0x43/frame 0xfe004c74c640
> > trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
> > trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
> > trap() at trap+0x2ba/frame 0xfe004c74c7f0
> > calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
> > --- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
> > 0xfe004c74c980 ---
> > futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
> > ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
> > int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
> > Uptime: 7m29s
> > Dumping 411 out of 8056
> > MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
> > Dump complete
> > ___
> > 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"

Linux process causes kernel panic

[Johannes Lundberg]

Hi

After install new kernel+world built from today's checkout I keep getting
the same crash over and over. Never had this problem before. The previous
kernel was from 3 weeks ago.

Looks familiar to anyone?

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address= 0xfffe665c
fault code= supervisor write data, protection violation
instruction pointer= 0x20:0x82282db3
stack pointer= 0x0:0xfe004c74c8c8
frame pointer= 0x0:0xfe004c74c980
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= 1579 (wcgrid_zika_vina_7.)
trap number= 12
panic: page fault
cpuid = 0
time = 1533327428
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe004c74c580
vpanic() at vpanic+0x1a3/frame 0xfe004c74c5e0
panic() at panic+0x43/frame 0xfe004c74c640
trap_fatal() at trap_fatal+0x35f/frame 0xfe004c74c690
trap_pfault() at trap_pfault+0x62/frame 0xfe004c74c6e0
trap() at trap+0x2ba/frame 0xfe004c74c7f0
calltrap() at calltrap+0x8/frame 0xfe004c74c7f0
--- trap 0xc, rip = 0x82282db3, rsp = 0xfe004c74c8c8, rbp =
0xfe004c74c980 ---
futex_xchgl() at futex_xchgl+0x23/frame 0xfe004c74c980
ia32_syscall() at ia32_syscall+0x29f/frame 0xfe004c74cab0
int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
Uptime: 7m29s
Dumping 411 out of 8056 MB:..4%..12%..24%..32%..43%..51%..63%..74%..82%..94%
Dump complete
___
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: acpiconf -s 3 does not call acpi sleep event handlers

[Johannes Lundberg]

On Thu, Aug 2, 2018 at 06:20 Andriy Gapon  wrote:

> On 02/08/2018 01:17, Conrad Meyer wrote:
> > I don't understand the concern.  There is only one listener to the
> > event and it just invokes ReqSleepState, which is responsible for
> > performing all suspend behavior.  The behavior is identical between
> > lid close and acpiconf.
>
> Unless someone is adding a new listener for that event.
>

Exactly my point.


> --
> Andriy Gapon
>
___
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: acpiconf -s 3 does not call acpi sleep event handlers

[Johannes Lundberg]

On Wed, Aug 1, 2018 at 22:55 Conrad Meyer  wrote:

> ReqSleepState is the routine that takes care of suspend, not the
> eventhandler.  I'm not sure what difference the proposed change is
> supposed to make.


Listeners to acpi_sleep_event don’t get the event when suspending with
acpiconf (but they do when suspending via lid or sleep button).

I think one would expect the same behavior when suspending via command line
or physical switch.



>
> Best,
> Conrad
>
> On Wed, Aug 1, 2018 at 2:48 PM, Johannes Lundberg 
> wrote:
> >
> >
> > On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer  wrote:
> >>
> >> It seems deliberate, although the commit message does not call it out
> >> and the event is perhaps poorly named.  The event currently indicates
> >> that the lid was closed.  And the final registered eventhandler for
> >> the event calls ReqSleepState.
> >>
> >> The ReqSleepState routine, as well as the userspace ioctl that
> >> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
> >> than invoking the acpi sleep event), were introduced together in
> >> r170976.
> >>
> >
> > Unless there's a way of calling suspend properly from the cli (zzz uses
> > acpiconf...) maybe something like this makes more sense to get the same
> > behavior on for example lid close as zzz or acpiconf -s 3? (untested)
> >
> > diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
> > index c1bfd880c89..87b506d6bf5 100644
> > --- a/sys/dev/acpica/acpi.c
> > +++ b/sys/dev/acpica/acpi.c
> > @@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t
> addr,
> > int flag, struct thread *t
> >  case ACPIIO_REQSLPSTATE:
> > state = *(int *)addr;
> > if (state != ACPI_STATE_S5)
> > -   return (acpi_ReqSleepState(sc, state));
> > +   return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER,
> > +   acpi_invoke_sleep_eventhandler, &state)) ? 0 :
> > ENXIO;
> > device_printf(sc->acpi_dev, "power off via acpi ioctl not
> > supported\n");
> > error = EOPNOTSUPP;
> > break;
> >
> >
> >>
> >> Best,
> >> Conrad
> >>
> >> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg 
> >> wrote:
> >> > Hi
> >> >
> >> > As the title says, callbacks registered with
> >> > EVENTHANDLER_REGISTER(acpi_sleep_event, 
> >> > does not get called when calling acpiconf -s 3.
> >> > They do however, when suspending with lid or sleep button.
> >> >
> >> > Is this deliberate or an oversight?
> >> >
> >> > Cheers
> >> > ___
> >> > 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: acpiconf -s 3 does not call acpi sleep event handlers

[Johannes Lundberg]

On Wed, Aug 1, 2018 at 9:15 PM Conrad Meyer  wrote:

> It seems deliberate, although the commit message does not call it out
> and the event is perhaps poorly named.  The event currently indicates
> that the lid was closed.  And the final registered eventhandler for
> the event calls ReqSleepState.
>
> The ReqSleepState routine, as well as the userspace ioctl that
> 'acpiconf -s' uses (which just invokes ReqSleepState directly, rather
> than invoking the acpi sleep event), were introduced together in
> r170976.
>
>
Unless there's a way of calling suspend properly from the cli (zzz uses
acpiconf...) maybe something like this makes more sense to get the same
behavior on for example lid close as zzz or acpiconf -s 3? (untested)

diff --git a/sys/dev/acpica/acpi.c b/sys/dev/acpica/acpi.c
index c1bfd880c89..87b506d6bf5 100644
--- a/sys/dev/acpica/acpi.c
+++ b/sys/dev/acpica/acpi.c
@@ -3700,7 +3700,8 @@ acpiioctl(struct cdev *dev, u_long cmd, caddr_t addr,
int flag, struct thread *t
 case ACPIIO_REQSLPSTATE:
state = *(int *)addr;
if (state != ACPI_STATE_S5)
-   return (acpi_ReqSleepState(sc, state));
+   return ACPI_SUCCESS(AcpiOsExecute(OSL_NOTIFY_HANDLER,
+   acpi_invoke_sleep_eventhandler, &state)) ? 0 :
ENXIO;
device_printf(sc->acpi_dev, "power off via acpi ioctl not
supported\n");
error = EOPNOTSUPP;
    break;



> Best,
> Conrad
>
> On Wed, Aug 1, 2018 at 8:05 AM, Johannes Lundberg 
> wrote:
> > Hi
> >
> > As the title says, callbacks registered with
> > EVENTHANDLER_REGISTER(acpi_sleep_event, 
> > does not get called when calling acpiconf -s 3.
> > They do however, when suspending with lid or sleep button.
> >
> > Is this deliberate or an oversight?
> >
> > Cheers
> > ___
> > 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"

acpiconf -s 3 does not call acpi sleep event handlers

[Johannes Lundberg]

Hi

As the title says, callbacks registered with
EVENTHANDLER_REGISTER(acpi_sleep_event, 
does not get called when calling acpiconf -s 3.
They do however, when suspending with lid or sleep button.

Is this deliberate or an oversight?

Cheers
___
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: atomic changes break drm-next-kmod?

[Johannes Lundberg]

On Fri, Jul 6, 2018 at 9:49 AM Konstantin Belousov 
wrote:

> On Fri, Jul 06, 2018 at 09:52:24AM +0200, Niclas Zeising wrote:
> > On 07/06/18 00:02, Warner Losh wrote:
> > >
> > >
> > > On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin  > > > wrote:
> > >
> > > On 7/5/18 12:36 PM, Konstantin Belousov wrote:
> > >  > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky
> wrote:
> > >  >> On 07/05/18 20:59, Hans Petter Selasky wrote:
> > >  >>> On 07/05/18 19:48, Pete Wright wrote:
> > >  
> > >  
> > >   On 07/05/2018 10:10, John Baldwin wrote:
> > >  > On 7/3/18 5:10 PM, Pete Wright wrote:
> > >  >>
> > >  >> On 07/03/2018 15:56, John Baldwin wrote:
> > >  >>> On 7/3/18 3:34 PM, Pete Wright wrote:
> > >   On 07/03/2018 15:29, John Baldwin wrote:
> > >  > That seems like kgdb is looking at the wrong CPU.  Can
> > > you use
> > >  > 'info threads' and look for threads not stopped in
> > > 'sched_switch'
> > >  > and get their backtraces?  You could also just do
> 'thread
> > > apply
> > >  > all bt' and put that file at a URL if that is easiest.
> > >  >
> > >   sure thing John - here's a gist of "thread apply all bt"
> > >  
> > >  
> > > https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
> > >  >
> > >  >>> That doesn't look right at all.  Are you sure the kernel
> > > matches the
> > >  >>> vmcore?  Also, which kgdb version are you using?
> > >  >>>
> > >  >> yea i agree that doesn't look right at all.  here is my
> setup:
> > >  >>
> > >  >> $ which kgdb
> > >  >> /usr/bin/kgdb
> > >  >> $ kgdb
> > >  >> GNU gdb 6.1.1 [FreeBSD]
> > >  >> $ ls -lh /var/crash/vmcore.1
> > >  >> -rw---  1 root  wheel   1.6G Jul  3 15:03
> > > /var/crash/vmcore.1
> > >  >> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug
> > >  >> -r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
> > >  >> /usr/lib/debug/boot/kernel/kernel.debug
> > >  >>
> > >  >> and i invoke kgdb like so:
> > >  >> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug
> > > /var/crash/vmcore.1
> > >  >>
> > >  >> here's a gist of my full gdb session:
> > >  >> http://termbin.com/krsn
> > >  >>
> > >  >> dunno - maybe i have a bad core dump?  regardless, more
> than
> > > happy to
> > >  >> help so let me know if i should try anything else or
> patches
> > > etc..
> > >  > Can you try installing gdb from ports and using
> > > /usr/local/bin/kgdb?
> > >  >
> > >  
> > >   that seems to have done the trick, at least the output looks
> more
> > >   encouraging.
> > >  
> > >     --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> > >   KDB: enter: panic
> > >  
> > >   __curthread () at ./machine/pcpu.h:231
> > >   231__asm("movq %%gs:%1,%0" : "=r" (td)
> > >  
> > >  
> > >   here's my full kgdb session:
> > >   http://termbin.com/qa4f
> > >  
> > >   i don't see any threads not in "sched_switch" though :(
> > >  >>>
> > >  >>> Hi,
> > >  >>>
> > >  >>> The problem may be that the patch to enable atomic inlining
> of all
> > >  >>> macros forgot to set the SMP keyword which means SMP is not
> > > defined at
> > >  >>> all for KLD's so all non-kernel atomic usage is with MPLOCKED
> > > empty!
> > >  > Problem is that out-of-tree modules build does not have opt*.h
> files
> > >  > from the kernel.  UP config is a valid one, flipping some
> option's
> > >  > default value does not solve the problem.
> > >
> > > Yes, but using the lock prefix in a generic module is ok (it will
> still
> > > work, just not quite as fast) whereas the lack of lock is fatal on
> > > SMP.  I would amend Hans' patch slightly to honor the opt_* setting
> > > for KLD_TIED (but that is only true if KLD_TIED means "built as
> part of
> > > a kernel build, so has valid opt_foo.h headers" and not
> > > 'a standalone module where someone put MODULES_TIED=1 on the
> command
> > > line
> > > to make').
> > >
> > >
> > > I agree with this default. It's sensible to default to (a) the most
> > > popular thing and (b) thing that always works, especially when (a) and
> > > (b) are identical.
> > >
> > > Don't make me start the "Do we really need an SMP option, why not make
> > > it always on" thread :) The number of relevant uniprocessor x86 boxes
> > > that benefit from omitting SMP is so small as to be irrelevant, IMHO.
> A
> > > MP kernel runs just fine on them...
> > >
> > > W

Re: Ryzen public erratas

[Johannes Lundberg]

Konstantin Belousov writes:

> Today I noted that AMD published the public errata document for Ryzens,
> https://developer.amd.com/wp-content/resources/55449_1.12.pdf
>
> Some of the issues listed there looks quite relevant to the potential
> hangs that some people still experience with the machines.  I wrote
> a script which should apply the recommended workarounds to the erratas
> that I find interesting.
>
> To run it, kldload cpuctl, then apply the latest firmware update to your
> CPU, then run the following shell script.  Comments indicate the errata
> number for the workarounds.
>
> Please report the results.  If the script helps, I will code the kernel
> change to apply the workarounds.
>
> #!/bin/sh
>
> # Enable workarounds for erratas listed in
> # https://developer.amd.com/wp-content/resources/55449_1.12.pdf
>
> # 1057, 1109
> sysctl machdep.idle_mwait=0
> sysctl machdep.idle=hlt
>
> for x in /dev/cpuctl*; do
>   # 1021
>   cpucontrol -m '0xc0011029|=0x2000' $x
>   # 1033
>   cpucontrol -m '0xc0011020|=0x10' $x
>   # 1049
>   cpucontrol -m '0xc0011028|=0x10' $x
>   # 1095
>   cpucontrol -m '0xc0011020|=0x200' $x
> done
>

Hi

Thanks for the fix! I'm trying it now on my Ryzen 3 2200G which does
experience some random occasional resets.

About updating to latest firmware, is this something that's done from BIOS or
from FreeBSD? If the latter, how?

> ___
> 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: How to run drm-next-kmod on r334511

[Johannes Lundberg]

Masachika ISHIZUKA writes:

>   Hi.
>
>   When I updated to r334511, drm-next-kmod is not working with
> the message '[drm:fw_domain_wait_ack] render: timed out waiting
> for forcewake ack request.'.
>
>   drm-next-kmod was working fine on r333704.
>
>   My CPU is pentium G4560(kaby lake).

Hi

We are working on a fix now.
Sorry for any trouble caused.

/Johannes

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