[Note: mips64 built for -r336251 but failed for -r336252 and -r336253 .]
An example (mips64):
--- all_subdir_stand ---
cc1: warnings being treated as errors
/usr/src/stand/libsa/geli/geliboot_crypto.c: In function 'geliboot_crypt':
/usr/src/stand/libsa/geli/geliboot_crypto.c:45: warning: 'blks' m
On 07/12/2018 21:15, Yuri wrote:
On 07/12/18 13:38, Pete Wright wrote:
sorry if i missed something (don't see details in the bug report) -
is the issue that the run(4) kernel module is not being loaded? is
there an error when the system attempts to load the kernel module in
the dmesg buffe
I'm experiencing wireless connection failure after HEAD/i386 update performed
today.
Below is relevant portion of dmesg buffer:
Jul 12 18:43:39 desktop kernel: wlan0: Ethernet address: 18:a6:f7:8a:b1:52
Jul 12 18:43:39 desktop kernel: wlan0: link state changed to UP
Jul 12 18:43:39 desktop kern
> On 13 Jul 2018, at 17:44, O. Hartmann wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Fri, 13 Jul 2018 14:26:51 +0300
> Toomas Soome mailto:tso...@me.com>> schrieb:
>
>>> On 13 Jul 2018, at 14:00, O. Hartmann wrote:
>>>
>>> The problem is some kind of weird. I face UE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Fri, 13 Jul 2018 14:26:51 +0300
Toomas Soome schrieb:
> > On 13 Jul 2018, at 14:00, O. Hartmann wrote:
> >
> > The problem is some kind of weird. I face UEFI boot problems on GPT drives
> > where the first partition begins at block 40 of the h
On 2018-Jul-13, at 3:15 AM, tech-lists wrote:
> On 12/07/2018 19:32, Dimitry Andric wrote:
>> No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes
>> , an intrinsics header, which in turn requires .
>> This was introduced inhttps://svnweb.freebsd.org/changeset/base/308921,
>> and at
=== Reason:
In compiling the kernel again after a long time after 'pkg upgrade' the
following errors. The Intel graphics card is in use and something had
changed, the 'startx' did not start the XFCE session. This was the
reason to compile the kernel again with the new sources of today. After
>
>
> > On 13 Jul 2018, at 14:00, O. Hartmann wrote:
> >
> > The problem is some kind of weird. I face UEFI boot problems on GPT drives
> > where the first partition begins at block 40 of the hdd/ssd.
> >
> > I have two host in private use based on an
> > outdated ASRock Z77-Pro4-M and Z77-Pro
On Thu, Jul 12, 2018 at 02:42:29PM +0200, Alexander Leidinger wrote:
> __curthread () at ./machine/pcpu.h:230
> 230 __asm("movq %%gs:%1,%0" : "=r" (td)
> (kgdb) bt
> #0 __curthread () at ./machine/pcpu.h:230
> #1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:366
> #2 0xf
On 12/07/2018 15:42, Alexander Leidinger wrote:
> #9 0x81391fbe in arc_check_uma_cache (lowest=-1011712)
> at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532
Do you have any local modifications to ZFS code?
I cannot find that function.
--
Andriy Gapon
> On 13 Jul 2018, at 14:00, O. Hartmann wrote:
>
> The problem is some kind of weird. I face UEFI boot problems on GPT drives
> where the first partition begins at block 40 of the hdd/ssd.
>
> I have two host in private use based on an
> outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyB
Quoting Andriy Gapon (from Fri, 13 Jul 2018 14:50:48 +0300):
On 12/07/2018 15:42, Alexander Leidinger wrote:
#9 0x81391fbe in arc_check_uma_cache (lowest=-1011712)
at /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c:4532
Do you have any local modifications to ZFS c
Hi!
First post to the mailing list.
I was trying out the https://reviews.freebsd.org/D12419 on a recent FreeBSD
current (>= 336229) but didn’t get it to work using debian 9 as a guest. Mpg123
just hangs when trying to play a mp3. Also tried Ubuntu 18 but that just hangs
at boot time at “Detec
On 13.07.2018 14:10, Lev Serebryakov wrote:
> when system is unresponsive I see this in `top -SH`
>
> 100083 root -76 - 0K 272K - 1 291.8H 95.31% kernel{if_io_tqg_1}
> 100082 root -76 - 0K 272K - 0 297.7H 95.20% kernel{if_io_tqg_0}
>
> And it is new to me.
Oh, this MoBo has
I have "SOHO" router on Atom D2500 with FreeBSD CURRENT. It runs
CURRENT for very long time (from 11-CURRENT times), and recently it
start to consume much more CPU on same traffic — to the point when it
becomes unresponsive in shell (via ssh, not local console).
I have rather complex ipfw rules
Yuri Pankov wrote:
Yuri wrote:
On 07/03/18 12:45, Yuri wrote:
I updated the laptop to r335884 last night, and 'service
wpa_supplicant start wlan0' doesn't succeed any more.
kernel is supposed to create the network interface 'run0', but it
doesn't. This is the immediate reason why wpa_supplican
The problem is some kind of weird. I face UEFI boot problems on GPT drives
where the first partition begins at block 40 of the hdd/ssd.
I have two host in private use based on an
outdated ASRock Z77-Pro4-M and Z77-Pro4 mainboard (IvyBridge, Socket LGA1155).
Both boards are equipted with the lates
Yuri wrote:
On 07/03/18 12:45, Yuri wrote:
I updated the laptop to r335884 last night, and 'service
wpa_supplicant start wlan0' doesn't succeed any more.
kernel is supposed to create the network interface 'run0', but it
doesn't. This is the immediate reason why wpa_supplicant fails.
The non-cr
Hello.
The target host is a
Fujitsu Esprimo Q956
Firmware V5.0.0.11 R1.26.0 for A3413-A1x
Date 05/25/2018
BIOS Revision 1.26
FreeBSD 11.2-RELEASE and 12-CURRENT (ISO Image from 9th July 2018, r336134) are
spamming the console with an annoying error:
Jul 13 10:00:32 kernel: Firmware Error (ACPI
On 12/07/2018 19:32, Dimitry Andric wrote:
No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes
, an intrinsics header, which in turn requires .
This was introduced inhttps://svnweb.freebsd.org/changeset/base/308921,
and at the time resulted in similar build failures, specifically when
20 matches
Mail list logo
