sysutils/pftop on 9.x+

sysutils/pftop was marked broken on 9.x and above last March[1]. Are there any plans to fix it soon? It's a really handy utility. [1] http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/pftop/Makefile?rev=1.17 -- Greg Rivers ___ freebsd-s

Re: sysutils/pftop on 9.x+

On Tue, 14 Feb 2012, Florian Smeets wrote: On 14.02.12 17:14, Fabian Keil wrote: Greg Rivers wrote: sysutils/pftop was marked broken on 9.x and above last March[1]. Are there any plans to fix it soon? It's a really handy utility. [1] http://www.freebsd.org/cgi/cvsweb.cgi/ports/sys

Driver for Intel 10GbE adapter

er of adding/updating a card ID in the driver header file, but I see that sys/dev/ixgb/ixgb_ids.h already contains an entry for 0xA15F as listed above. Does anyone have experience with this card or know how to get it to probe and attach? Thanks! -- Greg Rivers ___

Re: Driver for Intel 10GbE adapter

usr/src. *** Error code 1 Stop in /usr/src. Is there any hope of seeing ixgbe fully merged into RELENG_7 soon, or is my best bet to switch to CURRENT? Thank you all for your help. -- Greg Rivers ___ freebsd-stable@freebsd.org mailing list http://

Re: Driver for Intel 10GbE adapter

status: no carrier Thanks! -- Greg Rivers ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: strange abort with kcheckpass

ience, several ports (eg. samba, cups, parts of kde3) depend on PIE and will not run with this disabled on 7.x. References: http://security.freebsd.org/advisories/FreeBSD-EN-09:05.null.asc http://lists.freebsd.org/pipermail/freebsd-stable/2009-October/052235.html -- Greg R

bin/121684: dump frequently hangs

I'm seeing dump hang frequently on RELENG_7 i386. Details and a ktrace in PR bin/121684. Is anyone else experiencing this? -- Greg ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, se

HP EliteBook EFI boot failure

e 1920 masks 0x0ff, 0x00ff, 0xff00 In both cases the system simply hangs. How can I help debug this? -- Greg Rivers ___ freebsd-stable@free

Re: HP EliteBook EFI boot failure

On Mon, 16 Mar 2015, John Baldwin wrote: I am curious if the redzone fix I committed to the EFI loader last week might help. It was noticed because gzipped kernels were corrupted when loaded from disk, but it might generate other random corruption even in the non-gzip case. I think the chanc

Booting from ZFS

0 0 procfs /proc procfs rw 0 0 fdescfs /dev/fd fdescfs rw 0 0 ! zpool export syspool --- -- Greg Rivers _

Re: Booting from ZFS

On Wed, 25 Mar 2015, Bob Bishop wrote: Hi, On 25 Mar 2015, at 04:56, Greg Rivers wrote: I'm trying to build a bootable ZFS system on a USB drive. Using the procedure below results in the following error when I try to boot: gptzfsboot: error 66 LBA 48 gptzfsboot: err

High UDP loss on 11.2-RELEASE-p4

I'm seeing considerable packet loss running recursive DNS (BIND 9.12.2) on 11.2. This is on server grade hardware (HP DL380G8) with an Intel 10Gb NIC (ix). I spun up iperf3; the results were disappointing: $ iperf3 --get-server-output -c r5 -u -b 1g -R Connecting to host r5, port 5201 Reverse

Boot time panic with 11.3-RELEASE on HP DL380 G7

year old hardware. Thoughts or suggestions? -- Greg Rivers ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Regression in IXGBE(4) on 12.0-RELEASE?

s Bus: Speed 5.0GT/s Width x8 ix0: netmap queues/slots: TX 1/2048, RX 1/2048 ix0: link state changed to UP MSI-X is disabled, and only one queue is enabled. I'm sure this is going to perform poorly under high network loads. Does anyone know why

Re: Regression in IXGBE(4) on 12.0-RELEASE?

On Wednesday, August 7, 2019 10:14:01 AM CDT Sergey Akhmatov wrote: > $ freebsd-version > 12.0-RELEASE-p7 > > $ pciconf -lvc ix0 > ix0@pci0:17:0:0:class=0x02 card=0x7a128086 chip=0x10fb8086 > rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82599ES 10-Gig

Re: Regression in IXGBE(4) on 12.0-RELEASE?

On Wednesday, August 7, 2019 12:53:44 PM CDT Pieper, Jeffrey E wrote: > Please file a PR @ https://bugs.freebsd.org/bugzilla/enter_bug.cgi > Thanks Jeff. . -- Greg ___ freebsd-stable@freebsd.o

Re: New Xorg - different key-codes

On Wednesday, 11 March 2020 13:53:45 CDT Peter Jeremy wrote: > On 2020-Mar-11 10:29:08 +0100, Niclas Zeising wrote: > >This has to do with switching to using evdev to handle input devices on > >FreeBSD 12 and CURRENT. There's been several reports, and suggested > >solutions to this, as well as

wpa_supplicant features and compile options

ere a better way to accomplish this? If not, might a change such as this be committed to enable GTC and OTP by default? -- Greg Rivers ---cut here- --- usr.sbin/wpa/wpa_supplicant/Makefile.old ThuMar 23 19:43:18 2006 +++ usr.sbi

Re: wpa_supplicant features and compile options

On Thu, 6 Sep 2007, Scot Hetzel wrote: On 9/6/07, Sam Leffler <[EMAIL PROTECTED]> wrote: Greg Rivers wrote: I connect to certain wireless networks that require the EAP_GTC and EAP_OTP features in wpa_supplicant. These features are not compiled into wpa_supplicant by default. Using the

No more geom_gpt.ko ?

The kernel module for GPT(8) partition tables is not present in RELENG_7 as it was in RELENG_6. Is "options GEOM_PART_GPT" now mandatory in the kernel config, or is not building the kernel module an oversight? -- Greg ___ freebsd-stable@freebsd.org m

Re: [HEADS UP] drm merged to -STABLE

I tried setting hw.dri.0.debug=1. That produced a lot of output, but nothing that looked like an error or warning. Do you have any idea what might be causing this, or how to troubleshoot further? -- Greg Rivers ___ freebsd-stable@freebsd.org mailing

Re: [HEADS UP] drm merged to -STABLE

On Tue, 17 Mar 2009, Robert Noland wrote: On Tue, 2009-03-17 at 12:20 -0500, Greg Rivers wrote: On Sat, 10 Jan 2009, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD. - Support for latest Intel chips - Support and fixes for many AMD/ATI chips r500 and below

Re: [HEADS UP] drm merged to -STABLE

On Wed, 18 Mar 2009, Robert Noland wrote: On Tue, 2009-03-17 at 18:24 -0500, Greg Rivers wrote: On Tue, 17 Mar 2009, Robert Noland wrote: On Tue, 2009-03-17 at 12:20 -0500, Greg Rivers wrote: On Sat, 10 Jan 2009, Robert Noland wrote: I just merged drm (Direct Rendering) from HEAD

Re: [HEADS UP] drm merged to -STABLE

window is never garbled. I'm running a dual-head configuration with the frame buffer spanning both monitors. -- Greg Rivers ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, s

Re: [HEADS UP] drm merged to -STABLE

On Thu, 19 Mar 2009, Robert Noland wrote: On Thu, 2009-03-19 at 15:01 -0500, Greg Rivers wrote: On Wed, 18 Mar 2009, Robert Noland wrote: Ok, so it isn't the gart caching... Can you get me a pointer to a screenshot? fetch http://www.tharned.org/rv380-drm-issue.tbz This archive con

Uppercase RE matching problems in FreeBSD 11

I happened to run an old script today that uses sed(1) to extract the system boot time from the kern.boottime sysctl MIB. On 11.0 this no longer works as expected: $ sysctl kern.boottime kern.boottime: { sec = 1478380714, usec = 145351 } Sat Nov 5 16:18:34 2016 $ sysctl kern.boottime | sed -e

SLAAC not working

: Neighbor Linklayer Address Netif ExpireS Flags fe80::ae16:2dff:fe1e:b880%lagg0 ac:16:2d:1e:b8:80 lagg0 permanent R Other hosts (running RedHat 6) on the same network SLAAC just fine. Does anyone have insight into this problem or suggestions for trouble

Re: SLAAC not working

should have mentioned that. Thanks for your reply. -- Greg Rivers ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: SLAAC not working

5983 (15.9 GiB) TX bytes:90980707420 (84.7 GiB) It may not be lagg related. As I recall, a few months ago I tried bringing one of the hosts up on oce0 alone, and SLAAC failed then too. I wonder if it's an oce(4) problem? -- Greg Rivers ___ free

Re: SLAAC not working

sereachable=30s0ms, reachable=31s, retrans=1s0ms Flags: nud accept_rtadv auto_linklocal Clearly there's no SLAAC action. I can't find any NDP debug messages in the kernel message log or in the syslog. Where might they be going? -- Greg Rivers __

Re: SLAAC not working

0, whose state is 2 set timer for lagg0 to 1s New timer is 1s timer expiration on lagg0, state = 2 No answer after sending 3 RSs stop timer for lagg0 there is no timer -- Greg Rivers ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mai

Re: SLAAC not working

On Wednesday, August 09, 2017 17:41:47 Hiroki Sato wrote: > Greg Rivers wrote > in <2045487.fzlpjxt...@flake.tharned.org>: > > gc> > 2. What is shown by the command "ping6 ff02::1%lagg0" ...? > gc> > > gc> $ ping6 -c 2 ff02::1%lagg0 > gc>

Re: SLAAC not working

Aside from ruling out the MTU option in the RAs as the cause, I've made little progress on finding the problem. Can anyone explain the use of net.inet6.icmp6.nd6_debug=1 for NDP debugging? I get no log output at all. -- Greg Rivers https://lists.freebsd.org/pipermail/freebsd-stable

Re: SLAAC not working

On Monday, September 04, 2017 13:22:16 Andrey V. Elsukov wrote: > On 03.09.2017 09:20, Greg Rivers wrote: > > Aside from ruling out the MTU option in the RAs as the cause, I've > > made little progress on finding the problem. > > > > Can anyone explain the use of

Re: SLAAC not working

gt; > $ ping6 fe80:::4013:23::2%lagg0 > > ping6: UDP connect: Network is unreachable > > Hmm. Can you show the second word of address in this example? > Is it not zero? I.e. fe80:: is correct or you missed '::' part? > Correct, neither of the parts are

Re: SLAAC not working [solved]

s that violated scope rules Looks like we've nailed it. The network engineering guys say that setting the LLA on the routers as they do is a Cisco convention. The value chosen reflects the /64 prefix being published in the RAs. I guess that makes it easy at a glance to see which prefi

Re: Disk I/O system hang on 5.4-RELEASE-p8 i386

On Thu, 23 Feb 2006, Michael R. Wayne wrote: Been fighting this for a while. We have an older server, running 5.4-RELEASE-p8 i386 and used primarily for email, which hangs every couple of weeks. The hang seems to be in the disk I/O system; pings succeed, and I can continue get a login: prompt

Re: Disk I/O system hang on 5.4-RELEASE-p8 i386

On Thu, 23 Feb 2006, Kris Kennaway wrote: I believe this issue has made it onto the show-stopper list for 6.1-RELEASE and is being actively worked on. It's on the todo list, but I don't think it's being worked on yet. The main problem is that we need a way to reproduce it on command. I'd forgo

Re: Required audit group is missing...

On Fri, 10 Mar 2006, Alfred Perlstein wrote: ... stable... :D /usr/src # make installworld ERROR: Required audit group is missing, see /usr/src/UPDATING. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. /usr/src # grep audit /usr/src/UPDATING /usr/src # ??? mergem

Re: kmem leak in tmpmfs?

On Thursday 25 May 2006 19:43, Paul Allen wrote: > >From Jonathan Noack <[EMAIL PROTECTED]>, Thu, May 25, 2006 at > > 07:56:07PM -0400: I am currently running with the following in > > /etc/rc.conf and haven't experienced any problems: > > tmpmfs_flags="-S -o async" > > Is there a way to accomplish

Re: kmem leak in tmpmfs?

On Mon, 29 May 2006, Ulrich Spoerlein wrote: Greg Rivers wrote: On Thursday 25 May 2006 19:43, Paul Allen wrote: From Jonathan Noack <[EMAIL PROTECTED]>, Thu, May 25, 2006 at 07:56:07PM -0400: I am currently running with the following in /etc/rc.conf and haven't experienced a

Re: Recurring problem: processes block accessing UFS file system

On Mon, 21 Nov 2005, Kris Kennaway wrote: Looks like a UFS snapshot deadlock. Are you running something like dump -L on this filesystem, or making other use of snapshots? Indeed I am (dump -L), but as I said (not very clearly, sorry), the deadlock also occurs under normal operation when no

Re: HEADS UP: MFC of local_startup changes to rc.d complete

On Wed, 21 Dec 2005, Doug Barton wrote: As has been discussed for a couple weeks now, I have MFC'ed to RELENG_6 the changes in /etc/rc* that bring new-style boot scripts from the local_startup directories (by default /usr/local/etc/rc.d and /usr/X11R6/etc/rc.d) into the base rcorder... This

Re: Recurring problem: processes block accessing UFS file system

On Tue, 22 Nov 2005, I wrote: On Mon, 21 Nov 2005, Kris Kennaway wrote: It may not be the same problem. You should also try to obtain a trace when snapshots are not implicated. Agreed. I'll do so at the first opportunity. First, my thanks to all of you for looking into this. It's tak

Re: Recurring problem: processes block accessing UFS file system

On Tue, 3 Jan 2006, Don Lewis wrote: There are large number of sendmail processes waiting on vnode locks which are held by other sendmail processes that are waiting on other vnode locks, etc. until we get to sendmail pid 87150 which is holding a vnode lock and waiting to lock a buf. Tracing com

Re: Recurring problem: processes block accessing UFS file system

On Tue, 3 Jan 2006, Don Lewis wrote: db> show lockedbufs [snip] looks like this is the buf that pid 87150 is waiting for: buf at 0xdc713f50 b_flags = 0xa00200a0 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8985610), b_data = 0xe0b7b000, b_blkno = 365094624 lo

Re: Recurring problem: processes block accessing UFS file system

On Wed, 4 Jan 2006, Don Lewis wrote: How about "show buffer 0xdc76fe30"? db> show buffer 0xdc76fe30 buf at 0xdc76fe30 b_flags = 0x20a0 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xc8985610), b_data = 0xe1d6b000, b_blkno = 365086368 lockstatus = 0, excl count

Re: FreeBSD 13/stable and zpool upgrade

On Friday, 19 February 2021 12:24:24 CST Kurt Jaeger wrote: > > > Unfortunately it contains an old version of the boot loader: > [...] > > We should be better about upgrading boot blocks, but EFI is kinda new and > > kinda different than the other out-of-root-filesystem boot blocks we've had > > in

Re: Drastic slowdown for geli attach

On Wednesday, 24 February 2021 23:34:06 CST Kevin Oberman wrote: > Sometime around the first week of this month (February) the time to do a > geli attach on my 13.0-ALPHA3 amd64 system sharply increased. It started > taking about 10 seconds. Prior to this, it took about 3-4 seconds. I have > not se