Shawn Webb shawn.webb at hardenedbsd.org wrote on
Sun Jun 3 01:08:19 UTC 2018 :
> Below is some logic pasted from lib/libpmc/Makefile:
>
> .if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
>
> .if ${MACHINE_ARCH} == "aarch64"
> EVENT_ARCH="arm64"
> .elif ${MACHINE_ARCH} == "amd64" ||
Hi,
I successfully tested the memstick.img on:
Acer Chromebook 14 (EDGAR) [CB3-431-C5EX]
The Results:
UEFI (Coreboot) works perfectly, no issues there.
BIOS (SeaBIOS) does *NOT* work. It puts the machine into a bootloop
until the install medium is disconnected. It does, however, make it past
Michael,
Good to know you still have plans to work on that eventually. It'd be
much appreciated.
Looking at the source for your cyapa driver, I see you've ported it from
the DragonFlyBSD driver (and they in turn adapted it from the Linux
one). I should've looked into that earlier... Instead
Hey all,
Below is some logic pasted from lib/libpmc/Makefile:
.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
.if ${MACHINE_ARCH} == "aarch64"
EVENT_ARCH="arm64"
.elif ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
EVENT_ARCH="x86"
.elif ${MACHINE_ARCH} == "powerpc"
On 2 Jun, O. Hartmann wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On CURRENT, running on an APU as router/firewall service, out of the blue
> after an update
> I receive this weird message when trying to restart "named" (BIND 9.12,
> latest from the
> ports):
>
> service
On Sun, Jun 3, 2018, 02:34 Vladimir Kondratyev
wrote:
> On 2018-06-02 20:36, Allan Jude wrote:
> > On 2018-06-02 11:03, Warner Losh wrote:
> >> On Sat, Jun 2, 2018 at 7:33 AM, Vladimir Kondratyev
> >>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> Our sys/mouse.h header has a definition of
On 2018-06-02 20:36, Allan Jude wrote:
On 2018-06-02 11:03, Warner Losh wrote:
On Sat, Jun 2, 2018 at 7:33 AM, Vladimir Kondratyev
wrote:
Hi,
Our sys/mouse.h header has a definition of MOUSE_GETVARS and
MOUSE_SETVARS
ioctls which are not documented and only stubbed in a few drivers:
On 2018-06-02 11:03, Warner Losh wrote:
> On Sat, Jun 2, 2018 at 7:33 AM, Vladimir Kondratyev
> wrote:
>
>> Hi,
>>
>> Our sys/mouse.h header has a definition of MOUSE_GETVARS and MOUSE_SETVARS
>> ioctls which are not documented and only stubbed in a few drivers: mse(4),
>> psm(4) and syscon's
On Sat, Jun 2, 2018 at 7:33 AM, Vladimir Kondratyev
wrote:
> Hi,
>
> Our sys/mouse.h header has a definition of MOUSE_GETVARS and MOUSE_SETVARS
> ioctls which are not documented and only stubbed in a few drivers: mse(4),
> psm(4) and syscon's sysmouse(4). The only exception is MOUSE_GETVARS
>
Hi,
Our sys/mouse.h header has a definition of MOUSE_GETVARS and
MOUSE_SETVARS ioctls which are not documented and only stubbed in a few
drivers: mse(4), psm(4) and syscon's sysmouse(4). The only exception is
MOUSE_GETVARS implemented in psm(4)
Given the fact that they were introduced 20
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).
>>>
>>> We are working on a fix
On 06/02/18 09:56, Masachika ISHIZUKA wrote:
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).
We are
> On 2. Jun 2018, at 12:41, Matthias Apitz wrote:
>
>> On Saturday, 2 June 2018 12:26:03 CEST, Greg V
>> wrote:
>> ...
>> cyapa is indeed not the right driver either. The "cy" is for Cypress. That's
>> the touchpad found in e.g. the Acer C720.
>> ...
>
> Side note:
>
> I own three C720,
On Saturday, 2 June 2018 12:26:03 CEST, Greg V
wrote:
...
cyapa is indeed not the right driver either. The "cy" is for Cypress.
That's the touchpad found in e.g. the Acer C720.
...
Side note:
I own three C720, they all came with Cypress TP. One was for repair at
Acer.com and returned
This happened again. Now I have a crashdump.
Anyone interested?
Some more answers below.
On Fri, 01 Jun 2018 17:41:54 +0200, bob prohaska
wrote:
On Thu, May 31, 2018 at 05:53:12PM +0200, Ronald Klop wrote:
I had a crash on my RPI-3B+ running freebsd 12/aarch64 from the 29 may
snapshot.
On Sat, Jun 2, 2018 at 3:14 AM, Albert wrote:
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
>> 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).
>
> We are working on a fix now.
> Sorry
2018-05-30 17:50 GMT+02:00 Glen Barber :
> 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On CURRENT, running on an APU as router/firewall service, out of the blue after
an update
I receive this weird message when trying to restart "named" (BIND 9.12, latest
from the
ports):
service named restart
rndc: connect failed: 127.0.0.1#953:
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
20 matches
Mail list logo
