Re: firewall choice
In message , grarpamp writes: > >>> What's the "best" [1] choice for firewalling these days > >>> There's pf, ipf and ipfw. > >> > >>This question comes up over years. > >> > >>Consider starting and joining with people to create > >>a comparison page on the FreeBSD Wiki, > >>both a feature / capability comparison table, > >>and contextual paragraphs. > >>A mini project like that can help many users > >>and add their researches to it. > > > > I'd be happy to if I knew where to start/how to start/is there a guide. > > Starting a wiki is here... > https://wiki.freebsd.org/ > https://wiki.freebsd.org/AboutWiki > > Which falls under larger handbook doc area... > https://lists.freebsd.org/mailman/listinfo/freebsd-doc > > Much of comparison would pull from man pages. > > Could also come from posting a call for input / announce > to questions, hackers, forum, etc. > > Wiki should not duplicate admin info from here... > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html > But would cover this handbook bullet item that is > not actually covered in the handbook (which > could link out to the wiki page for that)... > "- The differences between the firewalls built into FreeBSD." > > A full comparison would also want to note and point to > upstream sources, and have a table of which filter systems > are supported going forward in each unix OS (the *BSD > flavors including DragonFly ipfw3 pf, Linux netfilter+nftables, > Illumos). pf was originally written when Darren Reed took a job at Sun. He changed the license at the time. FreeBSD moved it (and other softwre to contrib), as did NetBSD (in their own way). OpenBSD wrote pf in the space of a week in reaction to the license change. > > And cover layer2 capabilities, switching, bridging, ipv6, > nat, rate limits / shape / queue, proxy, arbitrary rewriting > and routing hooks, etc. > > NetBSD where ipf was last released has deprecated > both ipf and pf in favor of npf. While upstream devel and > maintenance on ipf has died, pf still lives on at OpenBSD. It's hardly deprecated in NetBSD. Christos Zoulas and I have exchanged a fair bit of code. Darren Reed released and maintained IPF through the Australian National University. NetBSD imported it, like we do here at FreeBSD, into their src tree. > > Anyone can start. Have fun. My ipf work is documented at https://wiki.freebsd.org/IPFilter. > ___ > 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" > -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few. ___ 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: firewall choice
On Fri, Nov 27, 2020 at 06:11:43PM -0500, grarpamp wrote: [...lots...] OK thanks for that looks like I've got some reading to do -- J. signature.asc Description: PGP signature
Re: firewall choice
>>> What's the "best" [1] choice for firewalling these days >>> There's pf, ipf and ipfw. >> >>This question comes up over years. >> >>Consider starting and joining with people to create >>a comparison page on the FreeBSD Wiki, >>both a feature / capability comparison table, >>and contextual paragraphs. >>A mini project like that can help many users >>and add their researches to it. > > I'd be happy to if I knew where to start/how to start/is there a guide. Starting a wiki is here... https://wiki.freebsd.org/ https://wiki.freebsd.org/AboutWiki Which falls under larger handbook doc area... https://lists.freebsd.org/mailman/listinfo/freebsd-doc Much of comparison would pull from man pages. Could also come from posting a call for input / announce to questions, hackers, forum, etc. Wiki should not duplicate admin info from here... https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls.html But would cover this handbook bullet item that is not actually covered in the handbook (which could link out to the wiki page for that)... "- The differences between the firewalls built into FreeBSD." A full comparison would also want to note and point to upstream sources, and have a table of which filter systems are supported going forward in each unix OS (the *BSD flavors including DragonFly ipfw3 pf, Linux netfilter+nftables, Illumos). And cover layer2 capabilities, switching, bridging, ipv6, nat, rate limits / shape / queue, proxy, arbitrary rewriting and routing hooks, etc. NetBSD where ipf was last released has deprecated both ipf and pf in favor of npf. While upstream devel and maintenance on ipf has died, pf still lives on at OpenBSD. Anyone can start. Have fun. ___ 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: panic shortly after boot when amdgpu.ko is loaded (fpu?)
> On Nov 27, 2020, at 1:47 PM, Bakul Shah wrote: > > > >> On Nov 27, 2020, at 9:09 AM, Rebecca Cran wrote: >> >> On 11/27/20 4:29 AM, Hans Petter Selasky wrote: >>> >>> Is the problem always triggered by hald? If you disable hald in rc.conf, >>> does the system run for a longer period of time? >> >> It turns out that disabling ntpd let the system run for a longer period of >> time - until I ran "sysctl sys" at which point I got a panic. >> >> And this time the panic actually implicates amdgpu.ko, which is an >> improvement: >> >> >> #9 0x in ?? () >> #10 0x82a14c4e in amdgpu_device_get_pcie_replay_count () >> from /boot/modules/amdgpu.ko >> #11 0x82a14b80 in sysctl_handle_attr () from /boot/modules/amdgpu.ko >> >> #12 0x80c06cc1 in sysctl_root_handler_locked (oid=0xfe02133ff000, >>arg1=0xfe016e360980, arg2=-8724518803888, req=0xfe016e360980, >>tracker=0xf81099af6280) at /usr/src/sys/kern/kern_sysctl.c:184 >> #13 0x80c0610c in sysctl_root (oidp=, >>arg1=0xf810aa27e650, arg2=-2100190360, req=0xfe016e360980) >>at /usr/src/sys/kern/kern_sysctl.c:2211 >> >> >> Since it _is_ a problem in amdgpu, I'll stop this thread and re-post on >> freebsd-x11. > > FWIW, I am using amdgpu on a Ryzen 5 3500U system on a couple days old > -current (r368025). "sysctl sys" complains about "unknown oid 'sys'". > I am runing hald & ntpd. I had a few amdgpu related panics initially > but they vanished once I added > PORTS_MODULES=graphics/drm-devel-kmod > to /etc/src.conf to compile it along with the kernel. I am running > GENERIC-NODEBUG. The machine gets rebooted when I install a new kernel > (usually once a week). > > My guess is some weird interaction rather than something in amdgpu. To get sysctl sys working I compiled a GENERIC kernel from today's 368108 revision and so far there are no problems. $ sysctl sys.device.drmn0.pcie_replay_count sys.device.drmn0.pcie_replay_count: 0 sysctl -a also works. Last commit log on drm-devel-kmod (the last tiem may be what you're running into): Author: manu Date: Mon Nov 9 13:37:12 2020 + drm-current-kmod/drm-devel-kmod: Update to latest version - Use acpi code from base (thanks to wulf@) - Add radeon/i386 patches (thanks to tilj@) - Translate O_ flags for linuxulator (thanks to Greg V) - Lot of linuxkpi cleanup - Hack for amdgpu when the IP isn't init properly, this happens on one of my laptop with a dGPU. We still don't support it but we don't panic when we load amdgpu ___ 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: panic shortly after boot when amdgpu.ko is loaded (fpu?)
> On Nov 27, 2020, at 9:09 AM, Rebecca Cran wrote: > > On 11/27/20 4:29 AM, Hans Petter Selasky wrote: >> >> Is the problem always triggered by hald? If you disable hald in rc.conf, >> does the system run for a longer period of time? > > It turns out that disabling ntpd let the system run for a longer period of > time - until I ran "sysctl sys" at which point I got a panic. > > And this time the panic actually implicates amdgpu.ko, which is an > improvement: > > > #9 0x in ?? () > #10 0x82a14c4e in amdgpu_device_get_pcie_replay_count () >from /boot/modules/amdgpu.ko > #11 0x82a14b80 in sysctl_handle_attr () from /boot/modules/amdgpu.ko > > #12 0x80c06cc1 in sysctl_root_handler_locked (oid=0xfe02133ff000, > arg1=0xfe016e360980, arg2=-8724518803888, req=0xfe016e360980, > tracker=0xf81099af6280) at /usr/src/sys/kern/kern_sysctl.c:184 > #13 0x80c0610c in sysctl_root (oidp=, > arg1=0xf810aa27e650, arg2=-2100190360, req=0xfe016e360980) > at /usr/src/sys/kern/kern_sysctl.c:2211 > > > Since it _is_ a problem in amdgpu, I'll stop this thread and re-post on > freebsd-x11. FWIW, I am using amdgpu on a Ryzen 5 3500U system on a couple days old -current (r368025). "sysctl sys" complains about "unknown oid 'sys'". I am runing hald & ntpd. I had a few amdgpu related panics initially but they vanished once I added PORTS_MODULES=graphics/drm-devel-kmod to /etc/src.conf to compile it along with the kernel. I am running GENERIC-NODEBUG. The machine gets rebooted when I install a new kernel (usually once a week). My guess is some weird interaction rather than something in amdgpu. ___ 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: Wake from sleep kinda broken-ish? (ThinkPad Carbon X1 6th gen)
On Mon, Oct 12, 2020 at 5:22 PM Eirik Øverby wrote: > > On Wednesday, September 16, 2020 9:05:43 AM CEST Warner Losh wrote: > > I too can report this for my Lenovo Yoga running code as of September 13, > > but with manu's latest drm... It used to work fine, but my last build on > > the system was from May. Most likely a new panic in that code path, but > > I've not chased down further... > > So I got a gen8 to play with, and the list of grievances is long - but I have > one observation that may be of interest: > The gen8 would be usable (at least seemingly so) with a 13-kernel from lat > 2019 or very early 2020. Then around the end of January - I've bisected it > down to around Jan 24, give or take, it would start wedging _hard_ after a > minute or two of heavy load (compiling, cat /dev/random, that sort of thing). > It was a problem prior to that too but it was _much_ harder to trigger, at > least based on my tests this weekend. > > The "solution" is to add > hint.hwpstate_intel.0.disabled="1" > to /boot/loader.conf. This obviously has disastrous impact on battery life. > The emt module takes over, so power management is a lot more rudimentary > (powerd now does nearly nothing, while powerd++ kills interactivity). Battery > life is much shorter than on my gen6, and it gets hotter. > > BUT: This thing - gen8 - would get stuck in the acpi_beep before adding this > to loader.conf. After adding the hint, I have not had a single failure when > resuming. It's behaving much better than my gen6. Recently I got an interesting observation: if I suspend with `zzz`, (which is basically doing `acpiconf -s S3`), and resuming by pushing the power button, there is 95% chance of resuming failure. However, if I use close/open the lid to suspend/resume, I haven't hit any failure since last week. I suppose that these 2 suspend/resume methods are basically doing the same thing? My hw.acpi.lid_switch_state sysctl is S3. I have tried suspending with `zzz` then closing the lid, there is about 50% failure rate, but the sample number is very small. Is there any idea about what makes the difference between these 2 suspend/resume methods? I'm running 13.0-CURRENT r367582, with drm-devel-kmod-5.4.62.g20201109 and gpu-firmware-kmod-g20200920. My /boot/loader.conf has hw.i915kms.enable_psr=0 but no hint.hwpstate_intel.0.disabled=1 Best, Li-Wen ___ 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: panic shortly after boot when amdgpu.ko is loaded (fpu?)
On 11/27/20 11:10 AM, Konstantin Belousov wrote: And what is the instruction at 0x81002dcf ? I got a much clearer panic by running "sysctl sys" which shows it's more likely a problem for the amdgpu folks and not an underlying FreeBSD problem. #7 0x810295cd in trap (frame=0xfe016e360760) at /usr/src/sys/amd64/amd64/trap.c:398 #8 #9 0x in ?? () #10 0x82a14c4e in amdgpu_device_get_pcie_replay_count () from /boot/modules/amdgpu.ko #11 0x82a14b80 in sysctl_handle_attr () from /boot/modules/amdgpu.ko #12 0x80c06cc1 in sysctl_root_handler_locked (oid=0xfe02133ff000, arg1=0xfe016e360980, arg2=-8724518803888, req=0xfe016e360980, tracker=0xf81099af6280) at /usr/src/sys/kern/kern_sysctl.c:184 #13 0x80c0610c in sysctl_root (oidp=, arg1=0xf810aa27e650, arg2=-2100190360, req=0xfe016e360980) at /usr/src/sys/kern/kern_sysctl.c:2211 #14 0x80c06783 in userland_sysctl (td=0xfe00f00b6100, name=0xfe016e360a40, namelen=4, old=, oldlenp=, inkernel=, new=0x0, newlen=0, retval=0xfe016e360aa8, flags=0) at /usr/src/sys/kern/kern_sysctl.c:2368 #15 0x80c065cf in sys___sysctl (td=0xfe00f00b6100, uap=0xfe00f00b64e8) at /usr/src/sys/kern/kern_sysctl.c:2241 #16 0x8102a81c in syscallenter (td=0xfe00f00b6100) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:189 #17 amd64_syscall (td=0xfe00f00b6100, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1156 #18 #19 0x0008003819ca in ?? () Backtrace stopped: Cannot access memory at address 0x7fffb618 (kgdb) ___ 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: suspend/resume versus OpenZFS on USB
On 05/09/2020 18:18, Graham Perrin wrote: On 05/09/2020 10:26, Hans Petter Selasky wrote: On 2020-09-05 11:00, Graham Perrin wrote: On 04/09/2020 09:01, Hans Petter Selasky wrote: On 2020-09-04 01:42, Graham Perrin wrote: This week for the first time I toyed with OpenZFS on a USB device: a mobile hard disk drive connected to the dock of an HP EliteBook 8570p. A light test, with the pool imported but not writing to the dataset at suspend time. At resume time (22:31), the device was still physically connected but the pool suffered an I/O failure (and the keyboard and trackball on USB were unusable). … We need output from "procstat -akk" to see where ZFS/USB is hanging. --HPS For test purposes I reproduced the behaviour with a different device, a USB flash drive (connected to the same dock). Attached: 2020-09-05 09:27:55 procstat -akk.txt – output from procstat -akk 2020-09-05 09:17:59 suspend 09:26:49 resume.txt – the output in context. Thank you Graham Hi, USB is not hanging. It looks like a problem with USB resume, that no devices are recognized, until you re-plug them ... --HPS Hi If I export the pool before suspend, no problem at resume time. … Please Is there any way to avoid the need to export before suspending the computer? Might there be a future improvement to support for USB? Thanks ___ 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: panic shortly after boot when amdgpu.ko is loaded (fpu?)
On Thu, Nov 26, 2020 at 10:09:24PM -0700, Rebecca Cran wrote: > I have a Threadripper 2990WX system that I recently installed an AMD Radeon > Pro W5700 into. It runs fine unless I load the amdgpu driver, at which point > it panics several seconds after boot: I have enough time to login and run a > few commands, but even if I just leave it it'll panic. I'm running: > > > FreeBSD photon.int.bluestop.org 13.0-CURRENT FreeBSD 13.0-CURRENT #0 > 6db1a3e8098-c273171(master): Thu Nov 26 01:26:17 MST 2020 > bc...@photon.int.bluestop.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > amd64 > > > I rebuilt the drm-current-kmod-5.4.62.g20201109_1 port today. > > > The panic is: > > Fatal trap 9: general protection fault while in kernel mode > cpuid = 24; apic id = 18 > instruction pointer = 0x20:0x81002dcf > stack pointer = 0x0:0xfe016e6ffaa0 > frame pointer = 0x0:0xfe016e6ffaa0 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 4372 (hald) > trap number = 9 > panic: general protection fault > cpuid = 24 > time = 1606450595 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe016e6ff7b0 > vpanic() at vpanic+0x181/frame 0xfe016e6ff800 > panic() at panic+0x43/frame 0xfe016e6ff860 > trap_fatal() at trap_fatal+0x387/frame 0xfe016e6ff8c0 > trap() at trap+0x8e/frame 0xfe016e6ff9d0 > calltrap() at calltrap+0x8/frame 0xfe016e6ff9d0 > --- trap 0x9, rip = 0x81002dcf, rsp = 0xfe016e6ffaa0, rbp = > 0xfe016e6ffaa0 --- > fpurestore_xrstor3264() at fpurestore_xrstor3264+0x2f/frame 0xfe016e6ffaa0 > restore_fpu_curthread() at restore_fpu_curthread+0x85/frame 0xfe016e6ffac0 > fpudna() at fpudna+0x3a/frame 0xfe016e6ffae0 > trap() at trap+0x246/frame 0xfe016e6ffbf0 > calltrap() at calltrap+0x8/frame 0xfe016e6ffbf0 > --- trap 0x16, rip = 0x80067137f, rsp = 0x7fffd8b0, rbp = 0x7fffd8f0 > --- > Uptime: 1m4s > Dumping 4193 out of 130894 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > > I've uploaded details (core.txt, dmesg.txt etc.) to > https://bsdio.com/freebsd/crashes/2020-11-26-amdgpu/ and the vmcore file is > available on request. And what is the instruction at 0x81002dcf ? ___ 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: possible usb3-connected hard drive spin down causing lag
On Fri, Nov 27, 2020 at 04:34:24PM +0100, Ronald Klop wrote: Mind to share these tips, so I can use them on my RPI4? ;-) sure! I'll write up a simple site later, but in summary this is what I've done subsequent to the initial setup. E&OE, if it breaks you get to keep both bits, no guarantees etc etc. In no particular order: 1. in /boot/msdos/config.txt there's this: over_voltage=6 arm_freq=2000 sdram_freq_min=3200 [I use a FLIRC case to keep it cool. you *must* use cooling for this. Max temps I'm seeing under very heavy compiling (it runs poudriere) is 72 degC in 25 degC ambient] 2. /usr/src /usr/ports /usr/local /usr/obj /home /var/cache/ccache are all on the usb3 disk, seperate datasets. 3. swap is 16GB and is the first partition on the usb3 disk 4. for compiling, ccache is a must. 5. set tmp to tmpfs in /etc/fstab. I use 1GB like this: tmpfs /tmp tmpfs rw,mode=1777,size=1024m 0 0 6. make things like mutt use this /tmp 7. enable powerd and on bootup. Make it almost always use the overclocked speed like this in /etc/rc.conf powerd_enable="YES" powerd_flags="-r 1" This makes it run @ 2GHz always without needing to set something like boost_turbo. 8. in /etc/sysctl.conf: vfs.read_max=128 # default 64 9. compile mutt with kyotocabinet which uses (I think) memory mapping for cache lookups things like that. Faster than on-disk. 10. Look up the spec of yr usb3 connected device. Does it have 4k sectors? If it does, if you're using zfs make sure vfs.zfs.min_auto_ashift=12 in /etc/sysctl.conf 11. if you do compile stuff it'd be worth using -j3 if you want reasonably responsive interactive use from the pi while it's compiling. Like I've said, this isn't even guaranteed to work. All I can say is it's whats working on my rpi4/8GB now and I'm very happy with it. -- J. signature.asc Description: PGP signature
Re: panic shortly after boot when amdgpu.ko is loaded (fpu?)
On 11/27/20 4:29 AM, Hans Petter Selasky wrote: Is the problem always triggered by hald? If you disable hald in rc.conf, does the system run for a longer period of time? It turns out that disabling ntpd let the system run for a longer period of time - until I ran "sysctl sys" at which point I got a panic. And this time the panic actually implicates amdgpu.ko, which is an improvement: #9 0x in ?? () #10 0x82a14c4e in amdgpu_device_get_pcie_replay_count () from /boot/modules/amdgpu.ko #11 0x82a14b80 in sysctl_handle_attr () from /boot/modules/amdgpu.ko #12 0x80c06cc1 in sysctl_root_handler_locked (oid=0xfe02133ff000, arg1=0xfe016e360980, arg2=-8724518803888, req=0xfe016e360980, tracker=0xf81099af6280) at /usr/src/sys/kern/kern_sysctl.c:184 #13 0x80c0610c in sysctl_root (oidp=, arg1=0xf810aa27e650, arg2=-2100190360, req=0xfe016e360980) at /usr/src/sys/kern/kern_sysctl.c:2211 Since it _is_ a problem in amdgpu, I'll stop this thread and re-post on freebsd-x11. -- Rebecca Cran ___ 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: possible usb3-connected hard drive spin down causing lag
Van: tech-lists Datum: vrijdag, 27 november 2020 04:24 Aan: freebsd-current@freebsd.org Onderwerp: Re: possible usb3-connected hard drive spin down causing lag Hi, It seems the issue wasn't with the hardware or the connection. I use mutt and it's the program that was slowing everything down, and that was down to me using new mutt with my old config. The whole pause for 5 seconds thing was due to it scanning gigabytes of email each time it woke up. The fix was to review the config and change a couple of settings. Now there's no delay (well there is a bit but only because it's scanning the folders it's told to for new mail). But looking at a hardware cause wasn't in vain. On the way to the solution, found a few tips through here that sped up the system generally, and learned a bit. So now I have a *really quick* raspberry pi4 which is rock-solid stable, so thanks :D -- J. Mind to share these tips, so I can use them on my RPI4? ;-) ___ 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: firewall choice
On Fri, Nov 27, 2020 at 06:17:53AM -0500, grarpamp wrote: What's the "best" [1] choice for firewalling these days, in the list's opinion? There's pf, ipf and ipfw. This question comes up over years. Consider starting and joining with people to create a comparison page on the FreeBSD Wiki, both a feature / capability comparison table, and contextual paragraphs. A mini project like that can help many users and add their researches to it. I'd be happy to if I knew where to start/how to start/is there a guide. -- J. signature.asc Description: PGP signature
Re: panic shortly after boot when amdgpu.ko is loaded (fpu?)
On 11/27/20 6:09 AM, Rebecca Cran wrote: I have a Threadripper 2990WX system that I recently installed an AMD Radeon Pro W5700 into. It runs fine unless I load the amdgpu driver, at which point it panics several seconds after boot: I have enough time to login and run a few commands, but even if I just leave it it'll panic. I'm running: FreeBSD photon.int.bluestop.org 13.0-CURRENT FreeBSD 13.0-CURRENT #0 6db1a3e8098-c273171(master): Thu Nov 26 01:26:17 MST 2020 bc...@photon.int.bluestop.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 I rebuilt the drm-current-kmod-5.4.62.g20201109_1 port today. The panic is: Fatal trap 9: general protection fault while in kernel mode cpuid = 24; apic id = 18 instruction pointer = 0x20:0x81002dcf stack pointer = 0x0:0xfe016e6ffaa0 frame pointer = 0x0:0xfe016e6ffaa0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 4372 (hald) trap number = 9 panic: general protection fault cpuid = 24 time = 1606450595 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe016e6ff7b0 vpanic() at vpanic+0x181/frame 0xfe016e6ff800 panic() at panic+0x43/frame 0xfe016e6ff860 trap_fatal() at trap_fatal+0x387/frame 0xfe016e6ff8c0 trap() at trap+0x8e/frame 0xfe016e6ff9d0 calltrap() at calltrap+0x8/frame 0xfe016e6ff9d0 --- trap 0x9, rip = 0x81002dcf, rsp = 0xfe016e6ffaa0, rbp = 0xfe016e6ffaa0 --- fpurestore_xrstor3264() at fpurestore_xrstor3264+0x2f/frame 0xfe016e6ffaa0 restore_fpu_curthread() at restore_fpu_curthread+0x85/frame 0xfe016e6ffac0 fpudna() at fpudna+0x3a/frame 0xfe016e6ffae0 trap() at trap+0x246/frame 0xfe016e6ffbf0 calltrap() at calltrap+0x8/frame 0xfe016e6ffbf0 --- trap 0x16, rip = 0x80067137f, rsp = 0x7fffd8b0, rbp = 0x7fffd8f0 --- Uptime: 1m4s Dumping 4193 out of 130894 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% I've uploaded details (core.txt, dmesg.txt etc.) to https://bsdio.com/freebsd/crashes/2020-11-26-amdgpu/ and the vmcore file is available on request. Hi, Is the problem always triggered by hald? If you disable hald in rc.conf, does the system run for a longer period of time? --HPS ___ 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: firewall choice
On 27 Nov 2020, at 9:29, tech-lists wrote: What's the "best" [1] choice for firewalling these days, in the list's opinion? There's pf, ipf and ipfw. Which is the one being most recently developed/updated? I'm used to using pf, have done for over a decade. But OpenBSD's pf has diverged a lot more from when it first came across. There seems to be a lot more options. Is FreeBSD's pf being actively developed still? All three are actively maintained and grow new features from time to time. [1] up-to-date See above. All three are actively maintained. low overhead, high throughput I believe ipfw currently performs best. I can’t rank ipf and pf, because I’ve not seen benchmarks for ipf. IPv6-able, All three. traffic shaping/queueing Mostly ipfw, because dummynet. pf has ALTQ, but that has more limitations than dummynet. I think ipf doesn’t do shaping, but I may be mistaken about that. Best regards, Kristof ___ 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: firewall choice
> What's the "best" [1] choice for firewalling these days, in the list's > opinion? > There's pf, ipf and ipfw. This question comes up over years. Consider starting and joining with people to create a comparison page on the FreeBSD Wiki, both a feature / capability comparison table, and contextual paragraphs. A mini project like that can help many users and add their researches to it. > [1] up-to-date, versatile, low overhead, high throughput, IPv6-able, > traffic shaping/queueing ___ 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: firewall choice
On 2020-11-27 00:29, tech-lists wrote: Hi, What's the "best" [1] choice for firewalling these days, in the list's opinion? I can't speak for the whole list. ;-) But in my opinion with tables totaling over 150 million IPs. I'm casting a vote for pf(4). It's wildly easy on resources and as fast and flexible as I could ever hope to want. Started using it years ago, and never looked back. :-) There's pf, ipf and ipfw. Which is the one being most recently developed/updated? I'm used to using pf, have done for over a decade. But OpenBSD's pf has diverged a lot more from when it first came across. There seems to be a lot more options. Is FreeBSD's pf being actively developed still? Yes. It is actively developed. ipfw seems a lot more syntatically complex than pf. Is it more capable also? I know nothing about ipf yet. [1] up-to-date, versatile, low overhead, high throughput, IPv6-able, traffic shaping/queueing thanks, --Chris ___ 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: firewall choice
Hi! > What's the "best" [1] choice for firewalling these days, in the list's > opinion? At work, we use pf for complex setups, editing the rules using fwbuilder, and ipfw for the simple setups and the quick blocks... -- p...@opsec.eu+49 171 3101372Now what ? ___ 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"
firewall choice
Hi, What's the "best" [1] choice for firewalling these days, in the list's opinion? There's pf, ipf and ipfw. Which is the one being most recently developed/updated? I'm used to using pf, have done for over a decade. But OpenBSD's pf has diverged a lot more from when it first came across. There seems to be a lot more options. Is FreeBSD's pf being actively developed still? ipfw seems a lot more syntatically complex than pf. Is it more capable also? I know nothing about ipf yet. [1] up-to-date, versatile, low overhead, high throughput, IPv6-able, traffic shaping/queueing thanks, -- J. signature.asc Description: PGP signature
