Re: [RFC] Deprecation and removal of the drm2 driver

[Johannes Lundberg]

On Thu, May 31, 2018 at 11:34 PM Oliver Pinter <
oliver.pin...@hardenedbsd.org> wrote:

>
>
> On Thursday, May 31, 2018, Johannes Lundberg  wrote:
>
>> On Thu, May 31, 2018 at 4:34 PM Joe Maloney 
>> wrote:
>>
>> > I personally wish that more drivers, and firmware were separated from
>> > base.
>> >
>> >
>> I'm not a committer
>
>
>>
>>
> If you are not a committer,  how and why want to remove drm2 from the base
> system?
>


Nice way to shoot down people (who are working together with active
committers) trying to make FreeBSD and it's derivatives a better OS for its
users. As a way to help prevent breakage I suggested an upgrade to the
outdated build infrastructure. Something that should be done anyway. But
what do I know, I don't have a commit bit...



>
> From other side, how you want to maintain VM and other KPI changes in
> unmaintained and abandoned port? ;) Or how you can guarantee to everyone
> who breaks KPI to follow these breaks in an external abandoned port?
>
>
>>
>> but as I understand there's not pre-commit integration
>> tests.. If one had that, plus that it would test build kmod ports against
>> the pre-commit state of head as well, then maybe this would work.
>>
>>
>> > For example wireless firmware:
>> >
>> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=169433
>> >
>> > That was a ticket which I chimed in on about a firmware I needed to make
>> > my wireless adapter work.  I went through numerous efforts on IRC, and
>> > elsewhere to try to bring attention that ticket in order to attempt to
>> get
>> > that firmware backported for several 10.x releases in a row without
>> > success.  The firmware worked perfectly fine in PC-BSD where it was
>> cherry
>> > picked for numerous 10.x releases.
>> >
>> > Technically since I was using PC-BSD, and was a committer for that
>> project
>> > I had no real dire need to reach out to FreeBSD about the issue.  I was
>> > simply trying to help anyone else who might be encountering the same
>> issue
>> > trying to use stock FreeBSD because it was a simple backport.  If my
>> effort
>> > had turned out to be more fruitful I would have spent more time pursuing
>> > tickets, diffs, or whatever to get more things back-ported when I found
>> > them.  I am not sure where the breakdown was which did not allow that to
>> > happen.  Anyways I don't want to bikeshed, or anything but I just
>> wanted to
>> > point out how I think having more drivers, and firmware in ports could
>> be
>> > helpful to enhance compatibility for end users.
>> >
>> > Having a separate port for legacy drm could definitely make things
>> easier
>> > to providing installation options for end users, and automating the post
>> > install action chosen in TrueOS, GhostBSD, and future derivative
>> projects
>> > tailored for the desktop use case.  For example for TrueOS we boot the
>> > installer in failsafe mode with either VESA, or SCFB depending on
>> whether
>> > or not BIOS, or EFI is booted.  Then we could simply make a checkbox for
>> > legacy intel, or skylake + to install the correct package then the
>> module
>> > path for either driver can more or less remain the same.  Eventually
>> with
>> > something like devmatch maybe that can even be fully automatic.
>> >
>> > Joe Maloney
>> >
>> > On Thu, May 31, 2018 at 10:23 AM, Daniel Eischen 
>> > wrote:
>> >
>> >> On Thu, 31 May 2018, Konstantin Belousov wrote:
>> >>
>> >> On Thu, May 31, 2018 at 08:34:44AM +0100, Johannes Lundberg wrote:
>> >>>
>> >>> We're not replacing anything. We are moving the older drm1 and drm2
>> from
>>  kernel to ports to make it easier for the majority of the users to
>> load
>>  the
>>  correct driver without conflicts.
>> 
>> >>>
>> >>> You do understand that you increase your maintainence load by this
>> move.
>> >>> dev/drm and dev/drm2 use KPIs which cannot be kept stable even in
>> stable
>> >>> branches, so you will need to chase these updates.
>> >>>
>> >>
>> >> I agree.  One argument previously made was that it's easier
>> >> to maintain in ports.  One data point from me - I rarely
>> >> update my ports, I update my OS much more frequently.  In
>> >> fact, some times my ports get so out of date I just
>> >> (take off and) nuke /usr/local (from orbit, it's the only
>> >> way to be sure).
>> >>
>> >> Also, are we trying to solve a problem by moving drm[2] to
>> >> ports that won't be a problem when base is pkg'ized?  If
>> >> drm[2] is a package unto itself, then you don't have this
>> >> problem of ports conflicting with it, at least not so
>> >> much.  You can either not install the base drm[2] package
>> >> or deinstall it to make way for a conflicting port.  Once
>> >> drm[2] is pkg rm'd, it's not going to be reinstalled
>> >> again when you update the base OS.
>> >>
>> >> And don't we have the same problem with sendmail and a
>> >> few other base services?
>> >>
>> >> --
>> >> DE
>> >>
>> >> ___
>> >> freebsd-current@freebsd.org mail

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

[Kevin Lo]

On Wed, May 30, 2018 at 03:50:39PM +, Glen Barber wrote:
> Hi,
> 
> Could folks please help boot-test the most recent 12.0-CURRENT amd64
> memstick images on various hardware?  Note, this is not a request to
> install 12.0-CURRENT, only a boot-test with various system knobs
> tweaked.
> 
> The most recent images are available at:
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img
> 
> We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we
> would like to get this included in the upcoming 11.2-RELEASE if the
> change that had been committed addresses several boot issues reported
> recently.
> 
> Please help test, and report back (both successes and failures).

Tested memstick.img in both UEFI and legacy mode on :

Lenovo ThinkPad T430s
MSI Cubi 3 Silent

Both work for me.

> Thanks,
> 
> Glen

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

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

[Philip Homburg]

>https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD
>-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img

Works fine on a Lenovo ThinkPad x201

Fails on a Dell PowerEdge 2950
- The USB stick doen't show up in the boot menu
- After fixing the partition table entries, the USB stick does show up
- And then fails with 'Missing operating system'

Note that after fixing the partition table entries, it still works on the
ThinkPad.
___
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"

HPET-based NMI (debug) watchdog

[Andriy Gapon]

Maybe this patch / hack would be interesting to anyone else besides me :)
If it is, I would appreciate any testing or review.
https://reviews.freebsd.org/D15630

-- 
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: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)

[Mark Linimon]

On Thu, May 31, 2018 at 10:25:10PM -0500, Matthew D. Fuller wrote:
> because the incentives are rigged.  A bad outside contribution brought
> into ports more often yields "hey, you should have noticed" to the
> committer and more opprobrium back to the submitter.

I believe you're missing two important points:

 - there is feedback to the ports committers that goes on behind the
   scenes (e.g. not on public mailing lists);

 - everyone who uses FreeBSD needs src to work.  Not everyone who uses
   FreeBSD needs even a large fraction of ports to work.

Let me reframe this debate.  To me, the correct comparison is:

  "compare commits to src"

 vs. 

  "compare commits to key ports pieces such as Mk/, perl, apache24, &c"

Commits to the latter are thoroughly tested* in external staging areas
and/or "exp-runs" done by portmgr, _before_ they hit the tree.

For src committers that aren't aware: since adopting the exp-runs, there
have been far, far, fewer large-scale regressions of the ports tree.
Check the monthly portmgr reports to see how much work is going into
this -- and that doesn't count projects like gnome and kde that do their
own external precommit work.

Also, IMHO talking about whether this process is, or should be, automated
misses the point.  The distinguishing feature is the buy-in by the people
who are making changes to the tree to have done sufficient testing _first_.
Without that buy-in, the tools are irrelvant.

Next, let me assure you that anyone who breaks those key pieces of ports
hears about it _immediately_.

tl:dr; at least for the key pieces, FreeBSD ports has moved away from the
"throw it at the wall to see if it will stick" paradigm.  That's the part
of the codebase that ought to be the comparison point.

mcl

* almost always.  They are supposed to be, in any case.  Humans are involved.
___
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: PR backlog (was: [RFC] Deprecation and removal of the drm2 driver)

[Mark Linimon]

On Thu, May 31, 2018 at 09:04:25PM -0700, K. Macy wrote:
> This is where culling older bug reports comes in.

Well, even with doing that, the sheer number really doesn't help the
S/N that much.  It may make someone a bit neurotic like me feel a bit
better, but that's all.

> However, when I've tried wading through the bug system to find things
> that I might be able to fix, I have not found it easy at all.

To me, reasoning about 'search' is the riqht direction to go.  (Apologies
to folks for the long URLs, but I would rather not hide the search terms
here.)

We've been inconsistent about applying the 'patch-ready' tag to indicate
something is ready to go, but here's the current list for the Base System:

  
https://bugs.freebsd.org/bugzilla/buglist.cgi?keywords=patch-ready&keywords_type=allwords&list_id=232422&product=Base%20System&query_format=advanced&resolution=---

8 bugs.  Not that bad.

The 'patch' tag by itself produces a much less satisfying result:

  
https://bugs.freebsd.org/bugzilla/buglist.cgi?keywords=patch&keywords_type=allwords&limit=0&list_id=232422&order=bug_id%20DESC&product=Base%20System&query_format=advanced&resolution=---

600 bugs.  Moderately overwhelming.

Narrowing it down to just the 'kern' component only helps a little:

  
https://bugs.freebsd.org/bugzilla/buglist.cgi?component=kern&keywords=patch&keywords_type=allwords&list_id=232433&product=Base%20System&query_format=advanced&resolution=---

300 bugs.

Looking for tag 'regression' within that is more satisfying:

  
https://bugs.freebsd.org/bugzilla/buglist.cgi?component=kern&keywords=regression&keywords_type=allwords&list_id=232433&product=Base%20System&query_format=advanced&resolution=---

82 bugs.

tl:dr; expecting any sane person to 'browse' thousands of entries of
any kind from _any_ kind of list, is itself madness.  OTOH myself, and
koobs and others, are willing to work on the search metadata to at
least make 'search' reasonable.

[obv. disclaimer: I am only citing statistics for Bugzilla here, not
Phabricator; I simply know it better.]

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"

Can't seem to use 5GHz APs with Intel wireless

[Dhananjay Balan]

Hi,

(Apologies if this is the wrong list, please point me at the right one if you 
know)

I run 12-CURRENT (r334442) on a Thinkpad X230. This machine has an Intel
Centrino Advanced N 6205. But freebsd only uses in in 11g mode. When I
try to scan, it won't even display 5GHz aps.


wlan0: flags=8843 metric 0 mtu 1500
ether a4:4e:31:02:70:3c
inet 192.168.1.108 netmask 0x broadcast 192.168.255.255 
nd6 options=29
media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
status: associated
ssid SSID channel 7 (2442 MHz 11g ht/20) bssid bc:8a:e8:0b:a9:3f
regdomain FCC4 country DE authmode WPA2/802.11i privacy ON
deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid 60
protmode CTS ampdulimit 32k ampdudensity 16 -amsdutx amsdurx shortgi
-stbc -ldpc wme roaming MANUAL
groups: wlan 



>From reading man pages, I can see that iwn(4) supports 11n. Is it
really supprted?  What can I do to enable 11n?


Here are my configs

/etc/rc.conf
wlans_iwn0="wlan0"
ifconfig_wlan0="ssid SSID WPA SYNCDHCP"


/etc/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
eapol_version=2
ap_scan=1
fast_reauth=1

network={
ssid="SSID"
scan_ssid=0
psk="PSK"
priority=5
}


/boot/loader.conf
# wifi
if_iwn_load="YES"
iwn1000fw_load="YES"
iwn100fw_load="YES"
iwn105fw_load="YES"
iwn135fw_load="YES"
iwn2000fw_load="YES"
iwn2030fw_load="YES"
iwn4965fw_load="YES"
iwn5000fw_load="YES"
iwn5150fw_load="YES"
iwn6000fw_load="YES"
iwn6000g2afw_load="YES"
iwn6000g2bfw_load="YES"
iwn6050fw_load="YES"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted

[Tomoaki AOKI]

Hi.

Booted as expected on ThinkPad T420.
Fixed with descrete (nvidia) GPU, CPU internal GPU is disabled.
Both UEFI and Legacy (CSM) boot are enabled.

 UEFI first  : Boot on UEFI mode. [Confirmed efifb is used.]
 Legecy first: Boot on CSM mode.  [Confirmed vt(vga) is used.]

UEFI boot is much faster than legacy (CSM) boot.

Is firmware version needed?


On Wed, 30 May 2018 15:50:39 +
Glen Barber  wrote:

> Hi,
> 
> Could folks please help boot-test the most recent 12.0-CURRENT amd64
> memstick images on various hardware?  Note, this is not a request to
> install 12.0-CURRENT, only a boot-test with various system knobs
> tweaked.
> 
> The most recent images are available at:
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img
> 
> We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we
> would like to get this included in the upcoming 11.2-RELEASE if the
> change that had been committed addresses several boot issues reported
> recently.
> 
> Please help test, and report back (both successes and failures).
> 
> Thanks,
> 
> Glen
> 


-- 
Tomoaki AOKI
___
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: HPET-based NMI (debug) watchdog

[Gary Jennejohn]

On Fri, 1 Jun 2018 12:12:29 +0300
Andriy Gapon  wrote:

> Maybe this patch / hack would be interesting to anyone else besides me :)
> If it is, I would appreciate any testing or review.
> https://reviews.freebsd.org/D15630
> 

This could be of interest to me because my AMD Ryzen 5 1600 system
hangs randomly and I don't know why.  I suspect an infinite loop
somewhere in the USB stack, but can't prove it because the box is
totally unresponsive and I have to hit the reset switch.

But my single HPET doesn't seem to be using MSI.

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

create-kernel-packages-extra-flavor-debug: *** Error code 70: Unable to open plist

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On recent CURRENT with recent CURRENT sources (r334490), building FreeBSD 
packages for
FreeBSD-base fails on arm64.aarch64 with a custom kernel (see below).

WITH_META_MODE is used.

Such problems do not occur when building "make packages" on custom kernels on 
amd64 on
which I have erased all DEBUG facilities or DEBUG options. The same is with a 
customised
PINE64 kernel.

It is strange that the GENERIC kernel can be packaged.

Any ideas?

Kind regards,

oh


[...]
===> Creating FreeBSD-zfs-12.0.s20180601173814
pkg -o
ABI_FILE=/pool/sources/CURRENT/obj/pool/sources/CURRENT/src/arm64.aarch64/worldstage/bin/sh
- -o ALLOW_BASE_SHLIBS=yes  create
- -M 
/pool/sources/CURRENT/obj/pool/sources/CURRENT/src/arm64.aarch64/worldstage/zfs.ucl
- -p 
/pool/sources/CURRENT/obj/pool/sources/CURRENT/src/arm64.aarch64/worldstage/zfs.plist
- -r /pool/sources/CURRENT/obj/pool/sources/CURRENT/src/arm64.aarch64/worldstage
- -o /pool/sources/CURRENT/obj/pool/sources/CURRENT/src/repo/$(pkg -o
ABI_FILE=/pool/sources/CURRENT/obj/pool/sources/CURRENT/src/arm64.aarch64/worldstage/bin/sh
config ABI)/12.0.s20180601173814 ===> Creating
FreeBSD-kernel-generic-12.0.s20180601173814 ===> Creating
FreeBSD-kernel-generic-debug-12.0.s20180601173814 ===> Creating
FreeBSD-kernel-pine64-12.0.s20180601173814 ===> Creating
FreeBSD-kernel-pine64-debug-12.0.s20180601173814 pkg: Unable to open plist
file: 
/pool/sources/CURRENT/obj/pool/sources/CURRENT/src/arm64.aarch64/kernelstage/kernel.PINE64/kernel.PINE64-debug.plist
*** Error code 70

Stop.
make[4]: stopped in /pool/sources/CURRENT/src
*** Error code 1


- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWxGVJAAKCRDS528fyFhY
lCnQAfkB6RoR8X791l0FkHfp3mmyu+vH+es09po25LZtZOctka7gJqUYpNEnxYBl
ipqTrPFuypAYlAHPBRFBLO+OJbpoAgCVvRVctYh4nlXJBT72l8M7jewhgqWn/gRc
XPMUuxeqG91eQSxGOsjkBMp7cBNCiXnetV7Kb3BP4cEpCCQ2uaB2
=qJ8C
-END PGP SIGNATURE-
___
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: Can't seem to use 5GHz APs with Intel wireless

[Kevin Oberman]

On Fri, Jun 1, 2018 at 2:10 AM, Dhananjay Balan  wrote:

> Hi,
>
> (Apologies if this is the wrong list, please point me at the right one if
> you know)
>
> I run 12-CURRENT (r334442) on a Thinkpad X230. This machine has an Intel
> Centrino Advanced N 6205. But freebsd only uses in in 11g mode. When I
> try to scan, it won't even display 5GHz aps.
>
>
> wlan0: flags=8843 metric 0 mtu
> 1500
> ether a4:4e:31:02:70:3c
> inet 192.168.1.108 netmask 0x broadcast 192.168.255.255
> nd6 options=29
> media: IEEE 802.11 Wireless Ethernet MCS mode 11ng
> status: associated
> ssid SSID channel 7 (2442 MHz 11g ht/20) bssid bc:8a:e8:0b:a9:3f
> regdomain FCC4 country DE authmode WPA2/802.11i privacy ON
> deftxkey UNDEF AES-CCM 2:128-bit txpower 30 bmiss 10 scanvalid 60
> protmode CTS ampdulimit 32k ampdudensity 16 -amsdutx amsdurx
> shortgi
> -stbc -ldpc wme roaming MANUAL
> groups: wlan
>
>
>
> From reading man pages, I can see that iwn(4) supports 11n. Is it
> really supprted?  What can I do to enable 11n?
>
>
> Here are my configs
>
> /etc/rc.conf
> wlans_iwn0="wlan0"
> ifconfig_wlan0="ssid SSID WPA SYNCDHCP"
>
>
> /etc/wpa_supplicant.conf
> ctrl_interface=/var/run/wpa_supplicant
> eapol_version=2
> ap_scan=1
> fast_reauth=1
>
> network={
> ssid="SSID"
> scan_ssid=0
> psk="PSK"
> priority=5
> }
>
>
> /boot/loader.conf
> # wifi
> if_iwn_load="YES"
> iwn1000fw_load="YES"
> iwn100fw_load="YES"
> iwn105fw_load="YES"
> iwn135fw_load="YES"
> iwn2000fw_load="YES"
> iwn2030fw_load="YES"
> iwn4965fw_load="YES"
> iwn5000fw_load="YES"
> iwn5150fw_load="YES"
> iwn6000fw_load="YES"
> iwn6000g2afw_load="YES"
> iwn6000g2bfw_load="YES"
> iwn6050fw_load="YES"
> ___
>

First, if you are using GENERIC, the driver and firmware are either in the
kernel (driver) or auto-loaded. Yo should not have anything about this in
your loader.conf.

As far as other configuration goes, rc.local should not need (or want) the
SSID. That is why it is in wpa_supplicant.conf. All global wpa_supplicant
global definition is not needed except for eapol_version=2 as 1 is default.
Normally teh default works, but some APs insist on V2. Still, it should not
hurt to define everything.

I do find the iwn driver to be pretty poor and sometimes a bit unstable,
but it does work. I have 11n and 54 MHz working. what do you see with
'ifconfig wlan0 list aps'? If 54M is available, it should show up.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Can't seem to use 5GHz APs with Intel wireless

[Christoph Moench-Tegeder]

## Dhananjay Balan (m...@dbalan.in):

> From reading man pages, I can see that iwn(4) supports 11n. Is it
> really supprted?  What can I do to enable 11n?

The wlan system will auto-select 11n (wide channels, MIMO) as supported
by interface and network. See "ht" flag in ifconfig(8).

> wlans_iwn0="wlan0"
> ifconfig_wlan0="ssid SSID WPA SYNCDHCP"

Did you try adding "mode 11a" to select 5GHz band? (This might be
out-of-date, as my WiFi stuff is all on 11) (currently I'm also
using 2.4GHz only, for compatibility with some devices and the fact
that I have quite some trouble running 2.4GHz and 5GHz from the same
interface at the same time).

Regards,
Christoph

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

SVN r334499 breaks i386 kernel build

[Michael Butler]

Building /usr/obj/usr/src/i386.i386/sys/SARAH/vm_mmap.o
--- vm_mmap.o ---
/usr/src/sys/vm/vm_mmap.c:245:6: error: use of undeclared identifier
'MAP_32BIT'
MAP_32BIT | MAP_ALIGNMENT_MASK)) != 0))
^
1 error generated.
*** [vm_mmap.o] Error code 1

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"

Re: SVN r334499 breaks i386 kernel build

[Konstantin Belousov]

On Fri, Jun 01, 2018 at 07:42:07PM -0400, Michael Butler wrote:
> Building /usr/obj/usr/src/i386.i386/sys/SARAH/vm_mmap.o
> --- vm_mmap.o ---
> /usr/src/sys/vm/vm_mmap.c:245:6: error: use of undeclared identifier
> 'MAP_32BIT'
> MAP_32BIT | MAP_ALIGNMENT_MASK)) != 0))
> ^
> 1 error generated.
> *** [vm_mmap.o] Error code 1
Should be fixed by r334507.
___
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"

Elantech Touchpad Woes - Support for Elantech touchpads over i2c/SMBus still possibly missing

[Albert]

Hi all,


I'd like to start out by saying that I'm a newcomer to FreeBSD, but I've 
been running Linux for years now and I'm still having a few issues 
transitioning. Despite that. I've been having a blast setting things up 
for myself, and I'm hopeful I can get this resolved soon enough.


I'm trying to get FreeBSD running on my laptop, an "Acer Chromebook 14" 
(EDGAR), and although I've managed to overcome most of the problems I've 
faced along the way (needing to upgrade to a UEFI, misnamed wireless 
modules, video drivers not working on RELEASE nor STABLE), I just can't 
seem to get the touchpad on this thing to work.


For reference, EDGAR is an Intel Celeron N3160 SoC. Pretty much the only 
thing in it that isn't Intel are the case, the keyboard, the webcam and 
the touchpad. On Linux, the touchpad appears in _/proc_ as


I: Bus=0018 Vendor=04f3 Product=0055 Version=
N: Name="Elan Touchpad"
P: Phys=
S: Sysfs=/devices/pci:00/808622C1:05/i2c-1/i2c-ELAN:00/input/input5
U: Uniq=
H: Handlers=mouse0 event4
B: PROP=5
B: EV=b
B: KEY=e520 1 0 0 0 0
B: ABS=66380001303

It seems _dmesg_ confirms this:

[   18.416171] input: Elan Touchpad as 
/devices/pci:00/808622C1:05/i2c-1/i2c-ELAN:00/input/input5

and it can be seen from _lsmod_ as *elan_i2c*. The source for the 
corresponding driver can be found here: Google ChromeOS Git. 



Now on FreeBSD, it's as though it didn't even exist. Without applying 
any of the changes I've tried to get it working, here's the (verbose) 
output to _dmesg_ on FreeBSD: (vdmesg-nochanges 
). 
With the knowledge I have so far, this is to be expected, as it seems 
FreeBSD requires the *ig4* module to work with *i2c* devices. Loading it 
at boot does seem to make the buses visible, but the touchpad still 
doesn't appear (or not properly, I don't know all these codes): 
(vdmesg-ig4 
). 
The obvious solution is to enable support for elantech devices with 
_hw.psm.elantech_support_, but nada: (vdmesg-elantech 
). 
The only difference is _sysctl_ shows that option is enabled. Aside from 
that, it seems I'm not the only one who's had this sort of issue before, 
so support has been worked on and is claimed to be working. Loading the 
recommended cyapa and chromebook_platform modules at boot does not fix 
this issue: (vdmesg-chromebook 
). 
The reason appears, at least to me, to be that the cyapa driver isn't a 
proper elan driver. These are /different/ devices.


I'm determined to get this working /somehow/, so any help would be 
appreciated. It feels like there's a solution here somewhere and I'm 
either too dumb to find it or it's just not there quite yet. If it's the 
latter, I'm willing to put some work into porting the right driver with 
a little guidance. (I have plenty of experience with C but none of this 
driver stuff.)



- Albert

PS. External mice are working perfectly, so it's nothing to do with the 
base install.


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

How to run drm-next-kmod on r334511

[Masachika ISHIZUKA]

  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).
-- 
Masachika ISHIZUKA
___
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"