Re: panics in network stack in 12-current
Andrey V. Elsukov wrote: On 26.04.2017 04:03, Tom Uffner wrote: I think the most of these panics should be fixed in r315956. thanks. I'll give it a try and report back as soon as I have a result. ___ 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: panics in network stack in 12-current
On 26.04.2017 04:03, Tom Uffner wrote: > Since updating my -current box to 12 several months ago, I have been > trying to pin down several elusive and probably related panics. > > they always manifest a a trap out of rw_wlock_hard() > > i am fairly certain that r302409 was stable, revs up through r306792 may be > stable, or perhaps I just didn't wait long enough for my system to panic. I > don't know of anything that I can reproducably poke at to trigger this. > r306807 is definitely bad, as is everything up through r309124. I > haven't seen anything on the mailing lists or in the SVN logs that looks > like it is related to my problem. > > my hardware is an Asus M4A77TD MB, AMD Phenom 2 X6 1100T CPU (for some of > this time I had an Athlon 2 X2, but upgraded recently), and RealTek 8168 > PCIe Gigabit NIC. > > FreeBSD discordia.uffner.com 12.0-CURRENT FreeBSD 12.0-CURRENT #33 > r306807M: Tue Apr 18 17:09:55 EDT 2017 > t...@discordia.uffner.com:/usr/obj/usr/src/sys/DISCORDIA amd64 > > in revs between 306807-307125, the panics have been in flowcleaner, in > more recent ones, they happen in arbitrary userspace processes that make > heavy use > of the network. > > I know I should try the latest rev to see if it went away. aside from > that, any thoughts on how I should proceed? I think the most of these panics should be fixed in r315956. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
panics in network stack in 12-current
Since updating my -current box to 12 several months ago, I have been trying to pin down several elusive and probably related panics. they always manifest a a trap out of rw_wlock_hard() i am fairly certain that r302409 was stable, revs up through r306792 may be stable, or perhaps I just didn't wait long enough for my system to panic. I don't know of anything that I can reproducably poke at to trigger this. r306807 is definitely bad, as is everything up through r309124. I haven't seen anything on the mailing lists or in the SVN logs that looks like it is related to my problem. my hardware is an Asus M4A77TD MB, AMD Phenom 2 X6 1100T CPU (for some of this time I had an Athlon 2 X2, but upgraded recently), and RealTek 8168 PCIe Gigabit NIC. FreeBSD discordia.uffner.com 12.0-CURRENT FreeBSD 12.0-CURRENT #33 r306807M: Tue Apr 18 17:09:55 EDT 2017 t...@discordia.uffner.com:/usr/obj/usr/src/sys/DISCORDIA amd64 in revs between 306807-307125, the panics have been in flowcleaner, in more recent ones, they happen in arbitrary userspace processes that make heavy use of the network. I know I should try the latest rev to see if it went away. aside from that, any thoughts on how I should proceed? Mon Apr 17 02:52:10 EDT 2017 FreeBSD discordia.uffner.com 12.0-CURRENT FreeBSD 12.0-CURRENT #32 r306821M: Fri Apr 7 02:11:44 EDT 2017 t...@discordia.uffner.com:/usr/obj/usr/src/sys/DISCORDIA amd64 panic: page fault Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3b8 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8057820d stack pointer = 0x28:0xfe046a422650 frame pointer = 0x28:0xfe046a422690 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 = 697 (ntpd) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe046a4222b0 vpanic() at vpanic+0x186/frame 0xfe046a422330 panic() at panic+0x43/frame 0xfe046a422390 trap_fatal() at trap_fatal+0x331/frame 0xfe046a4223f0 trap_pfault() at trap_pfault+0x14f/frame 0xfe046a422430 trap() at trap+0x21e/frame 0xfe046a422580 calltrap() at calltrap+0x8/frame 0xfe046a422580 --- trap 0xc, rip = 0x8057820d, rsp = 0xfe046a422650, rbp = 0xfe046a422690 --- __rw_wlock_hard() at __rw_wlock_hard+0xad/frame 0xfe046a422690 ip_output() at ip_output+0x483/frame 0xfe046a4227c0 udp_send() at udp_send+0xb8f/frame 0xfe046a422890 sosend_dgram() at sosend_dgram+0x431/frame 0xfe046a422910 kern_sendit() at kern_sendit+0x178/frame 0xfe046a4229c0 sendit() at sendit+0x179/frame 0xfe046a422a10 sys_sendto() at sys_sendto+0x4d/frame 0xfe046a422a60 amd64_syscall() at amd64_syscall+0x391/frame 0xfe046a422bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe046a422bf0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x8013c9cba, rsp = 0x7fffdfffc7e8, rbp = 0x7fffdfffc830 --- Mon Apr 17 03:19:00 EDT 2017 FreeBSD discordia.uffner.com 12.0-CURRENT FreeBSD 12.0-CURRENT #32 r306821M: Fri Apr 7 02:11:44 EDT 2017 t...@discordia.uffner.com:/usr/obj/usr/src/sys/DISCORDIA amd64 panic: page fault Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3b8 fault code = supervisor read data, page not present instruction pointer = 0x20:0x8057820d stack pointer = 0x28:0xfe0469a0eab0 frame pointer = 0x28:0xfe0469a0eaf0 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 = 21 (flowcleaner) trap number = 12 Timeout initializing vt_vga panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0469a0e710 vpanic() at vpanic+0x186/frame 0xfe0469a0e790 panic() at panic+0x43/frame 0xfe0469a0e7f0 trap_fatal() at trap_fatal+0x331/frame 0xfe0469a0e850 trap_pfault() at trap_pfault+0x14f/frame 0xfe0469a0e890 trap() at trap+0x21e/frame 0xfe0469a0e9e0 calltrap() at calltrap+0x8/frame 0xfe0469a0e9e0 --- trap 0xc, rip = 0x8057820d, rsp = 0xfe0469a0eab0, rbp = 0xfe0469a0eaf0 --- __rw_wlock_hard() at __rw_wlock_hard+0xad/frame 0xfe0469a0eaf0 flowtable_clean_vnet() at flowtable_clean_vnet+0x496/frame 0xfe0469a0eb80 flowtable_cleaner() at flowtable_cleaner+0x90/frame 0xfe0469a0ebb0 fork_exit() at fork_exit+0x75/frame 0xfe0469a0ebf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe0469a0ebf0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- Mon Apr 17 02:25:20 EDT 2017 FreeBSD discord
Re: Add support for ACPI Module Device ACPI0004?
On Wed, Apr 26, 2017 at 4:36 AM, John Baldwin wrote:
> On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
>> > From: John Baldwin [mailto:j...@freebsd.org]
>> > Sent: Thursday, April 20, 2017 02:34
>> > > Can we add the support of "ACPI0004" with the below one-line change?
>> > >
>> > > acpi_sysres_probe(device_t dev)
>> > > {
>> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
>> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004",
>> > > NULL };
>> > >
>> > Hmm, so the role of C01 and C02 is to reserve system resources, though we
>> > in turn allow any child of acpi0 to suballocate those ranges (since
>> > historically
>> > c01 and c02 tend to allocate I/O ranges that are then used by things like
>> > the
>> > EC, PS/2 keyboard controller, etc.). From my reading of ACPI0004 in the
>> > ACPI
>> > 6.1 spec it's not quite clear that ACPI0004 is like that? In particular,
>> > it
>> > seems that 004 should only allow direct children to suballocate? This
>> > change might work, but it will allow more devices to allocate the ranges in
>> > _CRS than otherwise.
>> >
>> > Do you have an acpidump from a guest system that contains an ACPI0004
>> > node that you can share?
>> >
>> > John Baldwin
>>
>> Hi John,
>> Thanks for the help!
>>
>> Please see the attached file, which is got by
>> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>>
>> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
>> "VMBus" (VMBS).
>> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
>> see the length of the MMIO range in the dumped asl code, it does have
>> a 512MB MMIO range [0xFE000, 0xF].
>>
>> It looks FreeBSD can't detect ACPI0004 automatically.
>> With the above one-line change, I can first find the child device
>> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
>> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>>
>> If you think we shouldn't touch acpi_sysresource0 here, I guess
>> we can add a new small driver for ACPI0004, just like we added VMBus
>> driver as a child device of acpi0?
>
> Hmmm, so looking at this, the "right" thing is probably to have a device
> driver for the ACPI0004 device that parses its _CRS and then allows its
> child devices to sub-allocate resources from the ranges in _CRS. However,
> this would mean make VMBus be a child of the ACPI0004 device. Suppose
> we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device
> would need to create a child device for all of its child devices. Right
> now acpi0 also creates devices for them which is somewhat messy (acpi0
> creates child devices anywhere in its namespace that have a valid _HID).
> You can find those duplicates and remove them during acpi_module0's attach
> routine before creating its own child device_t devices. (We associate
> a device_t with each Handle when creating device_t's for ACPI handles
> which is how you can find the old device that is a direct child of acpi0
> so that it can be removed).
The remove/reassociate vmbus part seems kinda "messy" to me. I'd just
hook up a new acpi0004 driver, and let vmbus parse the _CRS like what
we did to the hyper-v's pcib0.
Thanks,
sephe
--
Tomorrow Will Never Die
___
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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Brooks Davis changed: What|Removed |Added Resolution|--- |Works As Intended CC||bro...@freebsd.org Status|New |Closed --- Comment #17 from Brooks Davis --- (In reply to Joe Barbish from comment #16) As a project we DO NOT remove documented features from branches after the .0 release. This sometimes mean we continue shipping a feature we had intended to remove as is the case for the jail_* variables. It happens, we move remove it later and move on (I've removed code with decade "remove this soon" comments. On top of existing policy, removing this compatibility has little value that I can see so we would cause harm to users for no real purpose. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #16 from Joe Barbish --- This is my objection to waiting for 12.0 before doing this. When 10.0 came out the removal of the rc.conf method was scheduled to happen at 11.0. Now 3+ years later 11.0 is out and the rc.conf method is still supported. Now your talking about waiting for 12.0 to remove the the rc.conf method. In 3-4 years this same problem will still not be fixed and again we will be talking about waiting for 13.0 to do it. What you really talking about is holding up os deployment based on a 3rd-party tool. That's just plain crazy. I purpose this solution. I believe that the /etc/rc.d/jail script is the single place where the current 11.0 system issues that warning message and processes the rc.conf method from. The removing of the rc.conf method will mean changing only that script. Someone else should verify this. Inspecting the current version of the ezjail-admin script shows the start/stop commands launches a custom script /usr/local/etc/ezjail. After a bunch of grinding it finally launches /etc/rc.d/jail which does the actual start/stop work. This /etc/rc.d/jail script is part of the base os release. Change the custom /usr/local/etc/ezjail script to launch /usr/local/etc/ezjail-jail instead of /etc/rc.d/jail. This is a one line change. Then populate the ezjail-jail script with the contents of the 11.0 /etc/rc.d/jail script. Make these changes to the port source and the corresponding changes to the port makefiles and bingo you have given ezjail the ability to internally use the rc.conf method for ever forward. Now with this single show stopper fixed the removal of the rc.conf method can proceed to be scheduled for 11.1. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #15 from Mathieu Arnold --- (In reply to Joe Barbish from comment #9) > I see no benefit to dropping rc.conf jail support on a major release over a > minor release. I both cases you are going to suffer the same consequences of > NOT heeding the warning you have been getting for the past 3+ years. You > should be taking this early warning to develop a migration to something else > to limit your production down time. Stalling dropping rc.conf jail support > is not a solution. You will have to face this sooner or later. There can be no dropping of features in minor releases. In the FreeBSD world, we call that POLA, for Principle of Least Astonishment. If the jail_ variables are droppped, it will be for 12.0, or 13.0, but not on 11.1, or 10.4, or whatever. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #14 from rai...@ultra-secure.de --- I think the PTB (powers that be) ultimately decided that it's not in the interest of the project to have a tool and (and possibly an API) in base to create jails a la ezjail. At least, that's my educated guess. IIRC, iX-Systems uses (and sponsors) iocage (previously "warden"). Doubtlessly, other vendors/integrator have their own tools for managing jails - some may be in-house. Maybe there was a tendency not to create too much overlapping functionality in the base-system. It would be interesting to know if any of these vendors would be affected. As such, maybe somebody can bring this up at the next dev/vendor-summit (which I assume to be at BSDCAN). -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 erdge...@erdgeist.org changed: What|Removed |Added CC||erdge...@erdgeist.org --- Comment #13 from erdge...@erdgeist.org --- (In reply to Ngie Cooper from comment #12) Actually, I can not really see a benefit at all in removing that converter in base. It is not like the OS hands users of jail.conf like files a tool to properly create or modify them. Jamie's rewrite of jail(8) just broke editing jail configs for shell scripts. No big deal, as long as the OS keeps a compatibility until there ARE tools. However, once you start taking these converters away from the base, it needs to be reimplemented in several ports, possibly leading to errors with each implementation. If there would be a simple jail-admin tool allowing me operate on those complex structures from a script, or if there would be something like a jail.d with management scopes, where I'd be sure that configs are not manually touched, I would happily give up config in shell variables. I also volunteered in getting stuff done, by adding code to jail(8) to extend the parser with config file management functionality, but Jamie used to be not as reponsive as I would've loved. If there's others wanting to review and possibly commit changes to the tool, I'd say that we go for it. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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: Add support for ACPI Module Device ACPI0004?
On Thursday, April 20, 2017 02:29:30 AM Dexuan Cui wrote:
> > From: John Baldwin [mailto:j...@freebsd.org]
> > Sent: Thursday, April 20, 2017 02:34
> > > Can we add the support of "ACPI0004" with the below one-line change?
> > >
> > > acpi_sysres_probe(device_t dev)
> > > {
> > > -static char *sysres_ids[] = { "PNP0C01", "PNP0C02", NULL };
> > > +static char *sysres_ids[] = { "PNP0C01", "PNP0C02", "ACPI0004", NULL
> > > };
> > >
> > Hmm, so the role of C01 and C02 is to reserve system resources, though we
> > in turn allow any child of acpi0 to suballocate those ranges (since
> > historically
> > c01 and c02 tend to allocate I/O ranges that are then used by things like
> > the
> > EC, PS/2 keyboard controller, etc.). From my reading of ACPI0004 in the
> > ACPI
> > 6.1 spec it's not quite clear that ACPI0004 is like that? In particular, it
> > seems that 004 should only allow direct children to suballocate? This
> > change might work, but it will allow more devices to allocate the ranges in
> > _CRS than otherwise.
> >
> > Do you have an acpidump from a guest system that contains an ACPI0004
> > node that you can share?
> >
> > John Baldwin
>
> Hi John,
> Thanks for the help!
>
> Please see the attached file, which is got by
> "acpidump -dt | gzip -c9 > acpidump.dt.gz"
>
> In the dump, we can see the "ACPI0004" node (VMOD) is the parent of
> "VMBus" (VMBS).
> It looks the _CRS of ACPI0004 is dynamically generated. Though we can't
> see the length of the MMIO range in the dumped asl code, it does have
> a 512MB MMIO range [0xFE000, 0xF].
>
> It looks FreeBSD can't detect ACPI0004 automatically.
> With the above one-line change, I can first find the child device
> acpi_sysresource0 of acpi0, then call AcpiWalkResources() to get
> the _CRS of acpi_sysresource0, i.e. the 512MB MMIO range.
>
> If you think we shouldn't touch acpi_sysresource0 here, I guess
> we can add a new small driver for ACPI0004, just like we added VMBus
> driver as a child device of acpi0?
Hmmm, so looking at this, the "right" thing is probably to have a device
driver for the ACPI0004 device that parses its _CRS and then allows its
child devices to sub-allocate resources from the ranges in _CRS. However,
this would mean make VMBus be a child of the ACPI0004 device. Suppose
we called the ACPI0004 driver 'acpi_module' then the 'acpi_module0' device
would need to create a child device for all of its child devices. Right
now acpi0 also creates devices for them which is somewhat messy (acpi0
creates child devices anywhere in its namespace that have a valid _HID).
You can find those duplicates and remove them during acpi_module0's attach
routine before creating its own child device_t devices. (We associate
a device_t with each Handle when creating device_t's for ACPI handles
which is how you can find the old device that is a direct child of acpi0
so that it can be removed).
Then when you are the "VMBus" device_t your parent is the ACPI0004 device
so you can easily talk to it to obtain resources (probably ACPI0004 can
just intercept bus_if.m resource methods to manage the resources).
--
John Baldwin
___
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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #12 from Ngie Cooper --- For the sake of maintaining POLA, I recommend not breaking it on a dot-release and instead throw the switch on ^/head. I am very much in agreement there with grembo@. I think it would be a great idea to patch ezjail if possible, mark it BROKEN otherwise. If marked BROKEN, this will either force folks to transition from ezjail to another solution, and/or the author to update ezjail to use jail.conf. We should document qjail before doing that though so folks have a way to migrate to an alternate solution, if need be. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Conrad Meyer changed: What|Removed |Added CC||c...@freebsd.org --- Comment #11 from Conrad Meyer --- (In reply to Joe Barbish from comment #9) > I see no benefit to dropping rc.conf jail support on a major release over a > minor release. Breakage is expected in major releases; not in point releases. It makes sense to hold off until a new major release. There is no compelling reason this work needs to land before that. It's simply removing functionality that worked in 11.0. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #10 from Michael Gmelin --- (In reply to Joe Barbish from comment #9) I tried to give you feedback from real world installations and real world upgrade procedures, as you claimed ezjail isn't relevant any more. Even though I agree that the compatibility should be dropped, I don't see the urgency in this matter and don't get why it can't wait for a major release - like, what is the downside of keeping compatibility until 12-RELEASE. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #9 from Joe Barbish --- I see no benefit to dropping rc.conf jail support on a major release over a minor release. I both cases you are going to suffer the same consequences of NOT heeding the warning you have been getting for the past 3+ years. You should be taking this early warning to develop a migration to something else to limit your production down time. Stalling dropping rc.conf jail support is not a solution. You will have to face this sooner or later. If you feel this is too much for your environment, you could patch your copy of ezjail replacing rc.conf jail support with jail.conf support and post a PR. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #8 from Michael Gmelin --- (In reply to Joe Barbish from comment #7) As maintainer of sysutils/qjail you might look at this like it. I just know that we run hundreds of jails using ezjail and breaking that in anything but a major release would cause us major pain. I agree that he best way would be to fix ezjail of course, but if the author doesn't feel like it, breaking it on a minor release will cause a lot of headache for users for no good reason. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 --- Comment #7 from Joe Barbish --- In reply to comment # 3 which states "But I believe the number of ezjail-jails is significant." This is un-true, since 10.0 was published many ezjail users have been moving to qjail because qjail uses jail.conf and its a fork of ezjail so the users are familiar with its operation "Also, as you can see, until now (11.0) it's the 3rd-party tool recommended by the FreeBSD project itself (if you take the mentioning in the handbook as an endorsement)." This statement is also un-true. The FreeBSD project itself never publicly stated any position of 3rd-party tools. The inclusion of ezjail in the handbook is a current departure from the previous long held guild lines that no how-to-use details of 3rd-party tools would be contained in the handbook. A simple statement listing all the 3rd-party tools that may serve a certain function was allowable. The how-to-use details belong in the the 3rd-party tools manual pages. My comment. With RELEASE 10.0 published 1/4/2014, jail.conf became the direction jails are headed. Any one who uses the rc.conf jail method even today gets the warning message telling them to convert to the jail.conf method. This warming has been in existence for 3+ years now. This warning message even shows up when ezjail starts its jails. Its not like the ezjail maintainer doesn't know about this. ezjail has had 2 updates since 1/4/2014 when RELEASE 10.0 was published, PR# 357253, committed 6/10/14, an upgrade from 3.3 to 3.4, and PR# 402477 committed 11/27/2015, an upgrade from 3.4 to 3.4.2. The internal design of ezjail still has not been changed to the jail.conf method. 3+ years has been more than enough time for ezjail to be upgraded to the jail.conf method if the maintainer so desired. Based on the replies, I see no reason to not remove the rc.conf jail definition method from the rc.d script set now. Further more this task should be made a priority so it gets accomplished for inclusion in 11.1. At the same time the handbook ezjail section should be removed from the handbook being replaced with a simple informational statement listing all the 3rd-party jail tools, thus giving all of them fair and equal footing in the handbook. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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: altq and head
On Sat, Apr 8, 2017 at 3:55 AM, Eugene M. Zheganin wrote: > Hi, > > regarding all this stir around ALTQ and igb(4), and mentioning that igb(4) > doesn't have ALTQ in HEAD - I wanted to ask - is this just igb(4) and > ixgbe(4) that lost ALTQ in HEAD, or is ALTQ being removed totally from > FreeBSD ? I did a couple of searches, but seems like I cannot find the > simple answer. I'm also curious what the plan is w.r.t ALTQ. I definitely depend on igb supporting it... Thanks. > > > Thanks. > > Eugene. > > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Michael Gmelin changed: What|Removed |Added CC||gre...@freebsd.org --- Comment #6 from Michael Gmelin --- Even though is not the project's responsibility and the fact that it's quite rusty, ezjail remains popular and breaking people's jails on a dot release sounds like a bad plan. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 218849] Remove rc.conf jail configuration via jail_* variables
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218849 Chris Hutchinson changed: What|Removed |Added CC||portmas...@bsdforge.com --- Comment #5 from Chris Hutchinson --- (In reply to Miroslav Lachman from comment #4) > Or maybe there should not be 3rd party tools used in Handbook. There should > be documented steps using tools in base and link to freshports to many 3rd > party jail tools. Let the users choose. Can I simply add a plus one here? I couldn't agree more on this. It seems very odd to me to read "FreeBSD" documentation. Only to have it explain how to use it through the use of 3rd party software. Isn't it supposed to teach new users how to use the features _provided by FreeBSD? I see no reason not to touch lightly on 3rd party alternatives. But, honestly. Making the article primarily about 3rd party software is just wrong. > > This is very similar problem to portmaster / portupgrade tools - they are > (were) used in Handbook but are not maintained well. They are lacking behind > ports framework features and then some features are not easily implemented > because ports team does not want to break things for these tools... Good example, Miroslav, and thanks! :-) -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
