Re: Xen HVM Panic, HEAD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/17/15 00:56, Konstantin Belousov wrote: On Mon, Feb 16, 2015 at 08:10:06PM -0800, Sean Bruno wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://people.freebsd.org/~sbruno/Xen_APIC_panic.png I suspect that there may be one

Re: Xen HVM Panic, HEAD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/17/15 12:30, Sean Bruno wrote: On 02/17/15 12:26, Konstantin Belousov wrote: On Tue, Feb 17, 2015 at 12:00:04PM -0800, Sean Bruno wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/17/15 00:56, Konstantin Belousov wrote

Re: Xen HVM Panic, HEAD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This panic starts at: https://svnweb.freebsd.org/base?view=revisionrevision=278473 If I use 278472, I can boot the Xen VM normally. If I use head and set hw.x2apic_enable=0 in loader.conf and boot head (278970), it boots normally.

Xen HVM Panic, HEAD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://people.freebsd.org/~sbruno/Xen_APIC_panic.png I suspect that there may be one or two more lines above this that are relevant to this panic, but XENHVM kernel's now panic booting on Xen server. The working kernel output looks like this:

Re: Xen HVM Panic, HEAD

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 This panic starts at: https://svnweb.freebsd.org/base?view=revisionrevision=278473 If I use 278472, I can boot the Xen VM normally. If I use head and set hw.x2apic_enable=0 in loader.conf and boot head (278970), it boots normally.

Re: Haswell CPU Feature

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/05/15 16:57, Neel Natu wrote: Congratulations, you have the ability to debug the Haswell silicon HA! Is this turned on purposefully (its a feature of the CPU) or is this turned on unintentionally and is a bug in manufacturing? sean

Haswell CPU Feature

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 \014b11 I don't know what this cpu feature2 flag means, but my x240 haswell laptop has a b11 feature2 set. sean dmesg | grep -i features

Re: Haswell CPU Feature

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/05/15 17:50, Andrey Fesenko wrote: On Tue, Jan 6, 2015 at 4:24 AM, Sean Bruno sbr...@ignoranthack.me wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/05/15 16:57, Neel Natu wrote: Congratulations, you have the ability

Re: Haswell CPU Feature

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/06/15 07:48, John Baldwin wrote: On 1/6/15 12:44 AM, Jia-Shiun Li wrote: On Tue, Jan 6, 2015 at 1:23 PM, Neel Natu neeln...@gmail.com wrote: Hi Sean, On Mon, Jan 5, 2015 at 6:34 PM, Sean Bruno sbr...@ignoranthack.me wrote: I'm

Re: panic on application core dump?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Err. Is it easily reproducable in your setup ? The core file vnode is indeed unreferenced before notification is sent. Try this. diff --git a/sys/kern/kern_sig.c b/sys/kern/kern_sig.c index 41da3dd..57f66b0 100644 Restarted my

Re: panic on application core dump?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/22/15 10:53, Konstantin Belousov wrote: On Sun, Feb 22, 2015 at 10:46:53AM -0800, Sean Bruno wrote: Hmm ... looks unrelated to signals (maybe). This looks like a common ZFS deadlock that is yet undiagnosed. I do not have a show alllocks

Re: panic on application core dump?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/22/15 10:04, Konstantin Belousov wrote: On Sun, Feb 22, 2015 at 09:34:29AM -0800, Sean Bruno wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Err. Is it easily reproducable in your setup ? The core file vnode is indeed

Re: panic on application core dump?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/21/15 13:17, Konstantin Belousov wrote: On Sat, Feb 21, 2015 at 12:27:22PM -0800, Sean Bruno wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Well, this is new. It looks like current panic'd when trying to dump a core from

Re: panic on application core dump?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 02/22/15 10:54, Sean Bruno wrote: On 02/22/15 10:53, Konstantin Belousov wrote: On Sun, Feb 22, 2015 at 10:46:53AM -0800, Sean Bruno wrote: Hmm ... looks unrelated to signals (maybe). This looks like a common ZFS deadlock that is yet

panic on application core dump?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Well, this is new. It looks like current panic'd when trying to dump a core from a qemu crash? I can leave this at the debugger for now as this is a machine doing mips package builds and is not production. sean Thu Feb 19 18:50:59 UTC 2015

Re: Connected sanitizer libraries to the build (for x86)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/13/15 12:28, Dimitry Andric wrote: Hi, In r277146, I have connected the sanitizer libraries from compiler-rt to the build. Currently, this works for i386 and amd64, and contains Address Sanitizer (ASan) and Undefined Behavior

Re: Seeing about 4K exec: No such file or directory msgs in installworld

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/01/15 10:38, David Wolfskill wrote: On Mon, Jun 01, 2015 at 07:31:53PM +0200, Dimitry Andric wrote: ... 87386:exec: No such file or directory Yep, I saw these too. Hundreds of them. Ah; well, I'm fairly relived that I'm not either

ex(4) Removal from -current

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201127 ex(4) is an old Intel ethernet driver that isn't being actively maintained. I propose purging it from -current for 11.0 release things. sean p.s. will post to -net as well -BEGIN PGP

Re: Kernel panic with fresh current, probably nfs related

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/23/15 18:36, Yonghyeon PYUN wrote: Index: sys/dev/e1000/if_em.c === - --- sys/dev/e1000/if_em.c (revision 287087) +++ sys/dev/e1000/if_em.c (working copy) @@

Re: Kernel panic with fresh current, probably nfs related

I'm going to guess that you're using an em net driver, since that is the only one that sets if_hw_tsomax IP_MAXPACKET (65535) from what I can see. Sean, EM_TSO_SIZE is defined as (65535 + sizeof(struct ether_vlan_header)), which makes it IP_MAXPACKET. The value of if_hw_tsomax must be =

Are DDB custom function hooks broken in head?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I added a couple of DDB_HOOKS to em(4) recently and they definitely used to work. :-) KDB: enter: Break to debugger [ thread pid 11 tid 16 ] Stopped at kdb_alt_break_internal+0x197: movq$0,kdb_why db help ahd_dumpahd_in

Re: Are DDB custom function hooks broken in head?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/15/15 13:24, Sean Bruno wrote: I added a couple of DDB_HOOKS to em(4) recently and they definitely used to work. :-) KDB: enter: Break to debugger [ thread pid 11 tid 16 ] Stopped at kdb_alt_break_internal+0x197: movq

[CFT] em(4) - Update to use Extended RX Descriptor Format

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://reviews.freebsd.org/D3447 I'm looking for a bunch of you folks who have em(4) and *not* lem(4) to test out this update. This matches what linux does in e1000e vs e1000 and should be a no-op for your machines. The more devices we test here

Re: Kernel panic with fresh current, probably nfs related

On 08/29/15 00:38, Joel Dahl wrote: > On Tue, Aug 25, 2015 at 12:55:02PM -0700, Sean Bruno wrote: >> >> >> On 08/25/15 12:10, Joel Dahl wrote: >>>>> Seems to work. However, I cannot reproduce the user panic in the first >>>>> place. What's the

Re: em broken on current amd64

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/07/15 14:10, Mark R V Murray wrote: > >> On 5 Sep 2015, at 17:11, Garrett Cooper >> wrote: >> >> >>> On Sep 5, 2015, at 08:50, Manfred Antar wrote: >>> >>> Recent changes to em have broken current

Re: Kernel panic with fresh current, probably nfs related

On 08/25/15 12:10, Joel Dahl wrote: Seems to work. However, I cannot reproduce the user panic in the first place. What's the scenario that seems to work here? NFS seems happy with/without the patch so I'm not confident in anything we are doing her e. I see several patches here. Which

Re: em broken on current amd64

>>> >>> I’m also seeing breakage with the em0 device; this isn’t a kernel >>> hang, it is a failure to move data after about 10-15 minutes. The >>> symptom is that my WAN ethernet no longer moves traffic, no pings, >>> nothing. Booting looks normal: >>> >>> em0:

Re: em broken on current amd64

On 09/12/15 13:45, Mark R V Murray wrote: > >> On 8 Sep 2015, at 19:02, Mark R V Murray <ma...@freebsd.org> wrote: >> >> >>> On 8 Sep 2015, at 17:22, Sean Bruno <sbr...@freebsd.org> wrote: >>> >>> >>>>>> >&g

Re: CURRENT: net/igb broken

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 10/02/15 00:47, O. Hartmann wrote: > On Thu, 01 Oct 2015 15:39:11 + Eric Joyner <ricer...@gmail.com> > wrote: > >> Oliver, >> >> did you try Sean's suggestion? >> >> - Eric >>

Re: CURRENT: net/igb broken

n proceed from there. sean > > On Fri, Sep 18, 2015 at 9:50 AM Sean Bruno <sbr...@freebsd.org > <mailto:sbr...@freebsd.org>> wrote: > > >> >> r287762 broke the system > > > Before I revert this changeset *again* can you test revert r287762 >

Re: CURRENT: net/igb broken

his. > > is that observation of any help? > > Regards, > > oh > >> >> On Mon, Sep 21, 2015 at 1:58 AM O. Hartmann >> <ohart...@zedat.fu-berlin.de> wrote: >> >>> On Sat, 19 Sep 2015 11:23:44 -0700 Sean Bruno >>> <sbr...@freebsd.o

Re: HWPMC panic

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/26/15 14:12, Larry Rosenman wrote: > Was playing with pmcstats -S instructions -T, and got the following > when I tried to ctrl/c out. > > > oldtbh.lerctr.org dumped core - see /var/crash/vmcore.3 > > Wed Aug 26 16:05:16 CDT 2015 > >

Re: CURRENT: net/igb broken

> > r287762 broke the system Before I revert this changeset *again* can you test revert r287762 from if_igb.c, e1000_82575.c and e1000_82575.h *only* That narrows down the change quite a bit. sean ___ freebsd-current@freebsd.org mailing list

Re: This igb change makes my igb not working anymore - Re: regression in igb/clang?

Please create/update/point-me-at a bugzilla issue with all this information. sean On 12/22/15 08:37, Alan Somers wrote: > I'm experiencing the same problem, and I can confirm that Alexander's > workaround fixes it. Here is some more information: > > * I see the exact same problem on two

Re: r292688: ix_txrx.c:812:4: error: use of undeclared identifier 'ip6';

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/24/15 04:03, O. Hartmann wrote: > Building kernel on r292688 fails with the error shown below: > This appears to be breakage due to missing "options INET6" in the kernconf being used. I've repaired this at svn revision 292697. > [...] cc

Re: r292688: ix_txrx.c:812:4: error: use of undeclared identifier 'ip6';

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 12/24/15 04:03, O. Hartmann wrote: > Building kernel on r292688 fails with the error shown below: > > [...] cc -O2 -pipe -O3 -O3 -pipe -march=native > -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc >

Re: sys/modules "make clean" seems broken again

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/19/15 15:42, Warner Losh wrote: > > > On Thu, Nov 19, 2015 at 11:12 AM, John Baldwin <j...@freebsd.org > <mailto:j...@freebsd.org>> wrote: > > On Thursday, November 19, 2015 09:13:06 AM Sean Bruno wrote: &g

Re: sys/modules "make clean" seems broken again

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 11/19/15 10:12, John Baldwin wrote: > On Thursday, November 19, 2015 09:13:06 AM Sean Bruno wrote: >> I thought I fixed this a year or two ago, but now a "make clean" >> in sys/modules seems to leave bus_if.h

sys/modules "make clean" seems broken again

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I thought I fixed this a year or two ago, but now a "make clean" in sys/modules seems to leave bus_if.h device_if.h and pci_if.h in the directory. Should I just add these to the clean targets? Index: kmod.mk

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On 01/23/17 08:39, Olivier Cochard-Labbé wrote: > > On Thu, Jan 12, 2017 at 1:54 AM, Matthew Macy > wrote: > > > A flame graph for the core cycle count and a flame graph with > cache miss stats from pmc would be a great start. > > >

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On 01/23/17 23:31, Olivier Cochard-Labbé wrote: > On Tue, Jan 24, 2017 at 2:40 AM, Sean Bruno <sbr...@freebsd.org > <mailto:sbr...@freebsd.org>> wrote: > > > > Which set of configs from your test suite are you using for this? > Specifically, what pa

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On 01/24/17 08:27, Olivier Cochard-Labbé wrote: > On Tue, Jan 24, 2017 at 3:17 PM, Sean Bruno <sbr...@freebsd.org > <mailto:sbr...@freebsd.org>> wrote: > > > > Did you increase the number of rx/tx rings to 8 and the number of > descriptors to 4k i

Re: Panic on boot current amd64

On 01/16/17 11:33, Manfred Antar wrote: >>From current today after changes to /sys/sys/gtaskqueue.h (r312293) I get >>panic on boot. > reverting to r312235 boot ok > > random: harvesting attach, 8 bytes (4 bits) from uhub9 > ugen1.3: at usbus1 > kernel trap 12 with interrupts disabled > > >

Re: igb is broken, even across reboots, at r312294

On 01/16/17 13:52, Alan Somers wrote: > Today I updated my machine from 311787 to 312294. After the update, > my igb ports can pass no traffic. If I reboot into kernel.old, they > still can't pass any traffic. They won't even work in the PXE ROM. I > have to power off, pull the power cables,

Re: Panic on boot current amd64

On 01/17/17 02:10, O. Hartmann wrote: > Am Mon, 16 Jan 2017 10:33:35 -0800 > Manfred Antar schrieb: > >> From current today after changes to /sys/sys/gtaskqueue.h (r312293) I get >> panic on boot. >> reverting to r312235 boot ok >> >> random: harvesting attach, 8 bytes (4 bits)

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On 01/18/17 07:41, Sean Bruno wrote: > > > On 01/18/17 00:34, O. Hartmann wrote: >> On Thu, 5 Jan 2017 20:17:56 -0700 >> Sean Bruno <sbr...@freebsd.org> wrote: >>> >> On a Fujitsu Celsius M740, the "em0" device gets stuck on heavy I/O. I c

Re: crash in iflib_fast_intr

On 01/18/17 03:37, peter.b...@bsd4all.org wrote: > Hi, > > A kernel without option EARLY_AP_STARTUP crashes in if lib_fast_intr. Since > GENERIC now has EARLY_AP_STARTUP, this probably got unnoticed. Problem is > reproducible. > > KDB: stack backtrace: > #0 0x805cec97 at

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On 01/18/17 00:34, O. Hartmann wrote: > On Thu, 5 Jan 2017 20:17:56 -0700 > Sean Bruno <sbr...@freebsd.org> wrote: > >> tl;dr --> igbX devices will become emX devices >> >> We're about to commit an update to sys/dev/e1000 that will implement and >>

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On 01/18/17 08:20, O. Hartmann wrote: > On Wed, 18 Jan 2017 07:59:17 -0700 > Sean Bruno <sbr...@freebsd.org> wrote: > >> On 01/18/17 07:41, Sean Bruno wrote: >>> >>> >>> On 01/18/17 00:34, O. Hartmann wrote: >>>> On Thu, 5 Jan 20

NFS clients (nfsroot netboot) never purged from showmount -a

I just noticed that our netboot nfsroot implementation never clears its entry or logs out or whatever when rebooting. I see the same server in the showmount -a output over the course of testing various configurations on various nfsroots: showmount -a All mount points on localhost:

Large patch/diff refuses to apply

I'm doing a large amount of change to ixgbe(4) in support of IFLIB implementations and running into failures when trying to apply large diffs. This is causing phabricator reviews to be unuseable as well. I've setup two trees to test this. The first tree is used to generate the diff and the

Re: Large patch/diff refuses to apply

On 10/06/16 10:58, Dimitry Andric wrote: > On 06 Oct 2016, at 17:23, Sean Bruno <sbr...@freebsd.org> wrote: >> >> On 10/06/16 09:19, Sean Bruno wrote: >>> >>> On 10/06/16 09:00, Alan Somers wrote: >>>> On Thu, Oct 6, 2016 at 8:41 AM, Sean Bruno

Re: Large patch/diff refuses to apply

On 10/06/16 09:19, Sean Bruno wrote: > > > On 10/06/16 09:00, Alan Somers wrote: >> On Thu, Oct 6, 2016 at 8:41 AM, Sean Bruno <sbr...@freebsd.org> wrote: >>> >>> >>> On 10/06/16 08:23, Slawa Olhovchenkov wrote: >>>> On Thu, Oct 06

Re: Large patch/diff refuses to apply

On 10/06/16 08:23, Slawa Olhovchenkov wrote: > On Thu, Oct 06, 2016 at 07:57:57AM -0600, Sean Bruno wrote: > >> I'm doing a large amount of change to ixgbe(4) in support of IFLIB >> implementations and running into failures when trying to apply large >> diffs. Thi

Re: Large patch/diff refuses to apply

On 10/06/16 09:00, Alan Somers wrote: > On Thu, Oct 6, 2016 at 8:41 AM, Sean Bruno <sbr...@freebsd.org> wrote: >> >> >> On 10/06/16 08:23, Slawa Olhovchenkov wrote: >>> On Thu, Oct 06, 2016 at 07:57:57AM -0600, Sean Bruno wrote: >>> >>>>

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

bsd-net@ megaphone for things that I may have broken. man page updates are coming up next. Please let us know if this revision has made things better, worse or none-of-the above on whatever Intel Gigabit NIC you happen to have lying around. sean On 01/05/17 20:17, Sean Bruno wrote: > tl;dr --

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On 01/11/17 05:54, Matthew Macy wrote: > > > > On Wed, 11 Jan 2017 01:23:46 -0800 Olivier Cochard-Labbé > <oliv...@cochard.me> wrote > > On Tue, Jan 10, 2017 at 4:31 AM, Sean Bruno <sbr...@freebsd.org> wrote: > > > > > > >

Re: CURRENT: em0 NIC freezes under heavy I/O on net

On 01/11/17 01:27, O. Hartmann wrote: > Running recent CURRENT (FreeBSD 12.0-CURRENT #5 r311919: Wed Jan 11 08:24:28 > CET 2017 amd64), the system freezes when doing a rsync over automounted > (autofs) NFSv4 filesystem, mounted from another CURRENT server (same revision, > but with BCM NICs). >

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On 01/11/17 15:44, Sean Bruno wrote: > >> My tunning are (same for both test): >> hw.igb.rxd="2048" (it should be useless now) >> hw.igb.txd="2048" (it should be useless now) >> hw.em.rxd="2048" >> hw.em.txd="

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

> My tunning are (same for both test): > hw.igb.rxd="2048" (it should be useless now) > hw.igb.txd="2048" (it should be useless now) > hw.em.rxd="2048" > hw.em.txd="2048" > hw.igb.rx_process_limit="-1" (It should be useless now too) > hw.em.rx_process_limit="-1" > > dev.igb.2.fc=0 >

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

On 01/11/17 12:47, Olivier Cochard-Labbé wrote: > On Wed, Jan 11, 2017 at 4:17 PM, Sean Bruno <sbr...@freebsd.org > <mailto:sbr...@freebsd.org>> wrote: > > > > Olivier: > > Give this a quick try. This isn't the correct way to do this, but I >

HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

tl;dr --> igbX devices will become emX devices We're about to commit an update to sys/dev/e1000 that will implement and activate IFLIB for em(4), lem(4) & igb(4) and would appreciate all folks who can test and poke at the drivers to do so this week. This will have some really great changes for

Re: HEADS-UP: IFLIB implementations of sys/dev/e1000 em, lem, igb pending

ntly* when we dropped this implementation, hence why we wanted to make 12-current a clean break. sean bcc matt > > On 06/01/2017 03:17, Sean Bruno wrote: >> tl;dr --> igbX devices will become emX devices >> >> We're about to commit an update to sys/dev/e1000 that will i

List test, please ignore.

ignore signature.asc Description: OpenPGP digital signature

Re: Failover Mode Between Ethernet and Wireless Interfaces broken on >= 11

On 06/21/17 11:48, Renato Botelho wrote: > I've already sent it to net, but I suspect this is the appropriate place > to discuss this subject. > > Last night I was configuring a new laptop and decided to give it [1] a > try. I figured out this section of handbook (similar instructions are on >

Re: Panic: @r323525: iflib

> Previous successful build was: > FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #398 > r323483M/323489:1200044: Tue Sep 12 04:31:08 PDT 2017 > r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 > > The usual historical information, including a

Recent warnings.

make[3]: "/usr/src/share/mk/bsd.prog.mk" line 274: warning: duplicate script for target "_scriptsinstall" ignored make[3]: "/usr/src/share/mk/bsd.prog.mk" line 274: warning: using previous script for "_scriptsinstall" defined here This popped up on me this week. Anyone see what's going on?

Microcode Updater Changes

https://reviews.freebsd.org/D15443 The FreeBSD Foundation has collaborated with a few folks so that we can continue to process and update microcode on FreeBSD. This review represents the first step in updating our infrastructure. If you are currently using microcode updates, please give this a

Re: Microcode Updater Changes

On 05/16/18 10:42, Sean Bruno wrote: > https://reviews.freebsd.org/D15443 > > The FreeBSD Foundation has collaborated with a few folks so that we can > continue to process and update microcode on FreeBSD. > > This review represents the first step in updating our infras

Re: Intel Corporation Wireless 8265 / 8275 (rev 78) on FreeBSD 12

On 05/23/18 01:41, David Pan wrote: > Hi: > how config the Intel Corporation Wireless 8265 / 8275 (rev 78) on FreeBSD > 12?I installed FreeBSD 12 on my thinkpad t470p ,and can not drive the Intel > Wireless Card. > please help me fix that, > > thx > David Pan > This seems to be a "iwm(4)"

Re: how to browse svnweb source?

On 05/28/18 15:37, Jeffrey Bouquet wrote: > Suddenly the site www.secnetix.de/olli/FreeBSD/svnews which showed sequential > source as for example xx1966 on april 3 xx2040 on april 4 this year, is > not loading > in the browser. It was informative to read color coded the source backported

Re: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more

On 07/03/18 13:53, Yuri wrote: > On 07/03/18 12:50, Lev Serebryakov wrote: >>   No, it isn't. >> >>   >> https://lists.freebsd.org/pipermail/freebsd-wireless/2016-October/007232.html >> >> >>   I don't know, why is it not mentioned in UPDATING:-( > > > I may be mistaken about the interface

[CFT] sysutils/devcpu-data Intel microcode migration

https://reviews.freebsd.org/D13921 In order to better absorb updates as they appear, I'm proposing that we switch from the current model of processing the "microcode.dat" legacy file to consuming the pre-digested update files. This update should not change the microcode version that you

Re: [CFT] sysutils/devcpu-data Intel microcode migration

On 01/15/18 11:14, Sean Bruno wrote: > https://reviews.freebsd.org/D13921 > > In order to better absorb updates as they appear, I'm proposing that we > switch from the current model of processing the "microcode.dat" legacy > file to consuming the pre-digested updat

Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832

On 01/12/18 08:38, Mike Tancsa wrote: > On 1/11/2018 6:03 PM, Sean Bruno wrote: >> https://reviews.freebsd.org/D13832 <--- test this update >> >> I'd like to get some feedback from AMD cpu users on this update. I've >> restructured and undone a few things th

Re: [CFT] AMD cpu microcode update port sysutils/devcpu-data D13832

On 01/12/18 04:49, Rainer Hurling wrote: > Am 12.01.2018 um 00:03 schrieb Sean Bruno: >> https://reviews.freebsd.org/D13832 <--- test this update >> >> I'd like to get some feedback from AMD cpu users on this update. I've >> restructured and undone a few things th

[CFT] AMD cpu microcode update port sysutils/devcpu-data D13832

https://reviews.freebsd.org/D13832 <--- test this update I'd like to get some feedback from AMD cpu users on this update. I've restructured and undone a few things that may have been keeping folks using this port from getting their runtime cpu microcode updates. After installing the port, grab

IPMI SOL seems to not accept characters after getty starts

tl;dr pxeboot new x86 host, ipmi sol works in loader, not after multiuser. The FreeBSD cluster just acquired 4x Supermicro X11DDW-L and I am having the hardest time with the IPMI SOL interface. I have configured "COM2" as the IPMI SOL interface and enabled console redirection. Netbooting via

Re: IPMI SOL seems to not accept characters after getty starts

On 08/08/18 17:13, Warner Losh wrote: > > > On Wed, Aug 8, 2018 at 4:39 PM, Sean Bruno <mailto:sbr...@freebsd.org>> wrote: > > tl;dr pxeboot new x86 host, ipmi sol works in loader, not after > multiuser. > > The FreeBSD cluster just acquire

Re: page fault in ip6_output

On 9/2/18 6:17 AM, Alexander Leidinger wrote: > Hi, > > -current at r338322 with manually applied r338372 (fix potential data > corruption in iflib) and r338416 (re-compute arc size). > > What worries me a little bit about the validity of this report is the > gdb 8.1.1 error when loading the

Re: em0 link fail

On 07/03/18 11:47, Michael Butler wrote: > On June 1st, I was able to do my monthly laptop ZFS snap-shot/back-up > (using "zfs snapshot -r zroot@backup; zfs send -R >nfs-filesys"). Now I > can't without the em0 interface stalling :-( > Can you tell what version of FreeBSD SVN was in use on

Re: head -r335795 broke the builds for ci.freebsd.org 's FreeBSD-head-{amd64,i386,powerpc,risc64,sparc64}-build

On 06/29/18 08:50, Mark Millard wrote: > Side note: > > All I get for the lists that I normally look at is: > > Error 503 Backend fetch failed > > Backend status: Backend fetch failed > > Transaction ID: . . . I think I fixed that about an hour ago. Try again. sean signature.asc

Re: UFS panics

On 10/24/18 9:22 AM, Leandro wrote: > Hello, > > I'm seeing a kernel panic when trying to move a specific file. > > panic: Bad effnlink fip 0xc004a2c69a00, fdp 0xc00497093be0, > tdp 0xc004be6295a0 > cpuid = 72 > time = 1540283798 > KDB: stack backtrace: > 0xe000adb8dcc0: at

Re: pkg problem on FreeBSD 13.0-CURRENT

On 10/25/18 6:57 AM, Kurt Jaeger wrote: > Hi! > >> FreeBSD konjak 13.0-CURRENT FreeBSD 13.0-CURRENT r339705 GENERIC  amd64 >> >> pkg-static install -f pkg >> pkg-static: Warning: Major OS version upgrade detected.  Running >> "pkg-static install -f pkg" recommended >> Updating FreeBSD

Re: pkg problem on FreeBSD 13.0-CURRENT

On 10/25/18 10:29 AM, Pieper, Jeffrey E wrote: > I'm seeing: > > Installing pkg-1.10.5_5... > Extracting pkg-1.10.5_5: 100% > ld-elf.so.1: Shared object "libssl.so.9" not found, required by "pkg" > > Thanks, > Jeff Is this before or after the move of libssl.so.9 -> libssl.so.111 ?

Re: Some delete-old detrius

On 9/18/18 8:48 PM, Mark Millard wrote: > A problem here is that the references should be to usr.bin instead > of usr/bin . See: > > https://lists.freebsd.org/pipermail/svn-src-head/2018-September/118426.html > > which reports for svn commit: r336601 - head: > > QUOTE > Looks like this

UEFI layout includes a freebsd-boot?

I don't think this layout from the installer is correct, but I could be wrong. Is there any reason to have a freebsd-boot in this layout created by the installer when using UEFI? % gpart show => 40 537234688 ada0 GPT (256G) 40 409600 1 efi (200M) 409640

IPv6 for local_unbound?

Does it make sense to add an IPv6 localhost (::1) to our setup scripts for local_unbound? unbound is definitely listening on ::1 as well at 127.0.0.1 so things like "host -6" will work if we add it like this perhaps? --- /usr/sbin/local-unbound-setup 2018-09-20 21:47:41.0 -0600 +++

Re: UEFI layout includes a freebsd-boot?

vid P. Discher  > https://davidpdischer.com/ > d...@dpdtech.com > >> On Sep 23, 2018, at 1:57 PM, Sean Bruno > <mailto:sbr...@freebsd.org>> wrote: >> >> I don't think this layout from the installer is correct, but I could be >> wrong.  Is there any

test

Just testing mailing lists. Delete. sean signature.asc Description: OpenPGP digital signature

pkg-base noise

make[8]: "/home/sbruno/bsd/fbsd_head/share/mk/bsd.files.mk" line 92: warning: duplicate script for target "_testsFILESINS_cleanup.ksh" ignored make[8]: "/home/sbruno/bsd/fbsd_head/share/mk/bsd.files.mk" line 92: warning: using previous script for "_testsFILESINS_cleanup.ksh" defined here Is this

Some delete-old detrius

doing a delete-old run: drwxr-xr-x 2 root wheel 25 Sep 18 22:55 usr/lib/debug/usr/lib/i18n rm: usr/bin/indent/tests/nsac.0: Not a directory rm: usr/bin/indent/tests/nsac.0.pro: Not a directory rm: usr/bin/indent/tests/nsac.0.stdout: Not a directory rm: usr/bin/indent/tests/sac.0: Not a

USB CD Eject Failures

Been playing around with sysutils/eject to automate some media backup stuff. I note that "after a number of ejects" the USB 2 CD drive will cease responding. I don't think its a race to failure, it acts like resource starvation/leak. Seems fairly reproducible, if someone gets to it before I

Re: USB Disk Stalls on -current

I think I'm going to grab one of these fancy 5-disk USB 3 enclosures I see on the Internet.  ;-) Most of the consumer grade units seem to have one or more issues (no NCQ depth more than 1, loud/bad fans, hard to get a real JBOD mode, JBOD mode eats serial numbers making ID hard). I

xhci(4) hanging in early boot with drives attached

As far as I can tell, xhci(4) is hanging on "something" during early boot (probably something uninitialized) that causes it to basically never attach drives. I only have one controller here, so it could be something special with my device. If I single user my machine and attach my storage

Re: USB Disk Stalls on -current

On 2/6/22 10:14, Sean Bruno wrote: I'm doing something "gross" with ZFS & Plex on a little Intel NUC that I have here at the house to provide me with a nice little NAS at home. I'm using 2x USB2 external disks as the mirror. I noted that the two USB2 disks I'm using in

Re: USB Disk Stalls on -current

On 2/6/22 10:52, Mehmet Erol Sanliturk wrote: On Sun, Feb 6, 2022 at 8:15 PM Sean Bruno <mailto:sbr...@freebsd.org>> wrote: I'm doing something "gross" with ZFS & Plex on a little Intel NUC that I have here at the house to provide me with a nice litt

USB Disk Stalls on -current

I'm doing something "gross" with ZFS & Plex on a little Intel NUC that I have here at the house to provide me with a nice little NAS at home. I'm using 2x USB2 external disks as the mirror. I noted that the two USB2 disks I'm using in a mirror seem to "stall" from time to time and its not

Re: USB Disk Stalls on -current

So there's some tools you can use. For usb, there's usbdump that can get you the USB transactions. I've not used it enough to give more details here. This will let you know what's going on, and when, on the USB endpoint. You can also enable the CAM_IOSCHED stuff. This will allow you to get

installworld failure with poudriere

https://people.freebsd.org/~sbruno/poudriere_atf_debug.txt I think that some of the atf_check(1) Makefiles aren't respecting WITHOUT_DEBUG_FILES and this change has happened in the last few months. ===> libexec/atf/atf-check (install) --- _proginstall --- install -N /usr/src/etc -s -o root

<    1   2   3   4   >