Re: Is "/usr/bin/sscop" still relevant? (related to ATM)
mj-mailingl...@gmx.de writes: > Is "/usr/bin/sscop" still relevant? The sscop tool implements the Q.2110 > transport protocol, [...] Q.2110 is ATM over ISDN B-channels, and the only use-case I have ever heard about is to run SS7 signalling over ISDN-30 connections. (The ability to do so is largely why phone scammers can fake the calling number when they annoy you.) Unless somebody else know of other uses, you can kill it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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"
Is "/usr/bin/sscop" still relevant? (related to ATM)
Is "/usr/bin/sscop" still relevant? The sscop tool implements the Q.2110 transport protocol, which is used in ATM-Networks. The NATM framework was removed in April 2017, but sscop depends on netgraph (libngatm.so.4), so it seems to be independent from NATM. The manpage refers to libunimsg(3), which does not exist, but unimsg(3) does. It also depends on libngatm.so.4, which also does not have a man page. So, is it still useful? The most documents i found about ATM are from the early 2000 to mid 2010s. -- Martin ___ 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: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 11/9/2020 7:32 AM, Lev Serebryakov wrote:
> On 07.11.2020 2:46, Eric Joyner wrote:
>
>> The other issue is that I still don't know which devices need a
>> restart / which devices do not, or whether a restart is strictly
>> necessary and if there is another way to do this without worrying
>> about restarting the device.
> Could this be copied from pre-iflib driver? It did right things
> without unneeded resets, including some `em` chips.
>
> BTW, I'm surprised, that pre-iflib drivers still available on Intel
> site and in ports. And sometimes works better :-(
>
For my specific case (no DHCLIENT and I210 chipset), I just used
--- if_em.c 2020-09-26 07:46:16.474942000 -0400
+++ /tmp/if_em.c 2020-11-09 08:13:55.888378000 -0500
@@ -4047,6 +4047,7 @@
{
switch (event) {
case IFLIB_RESTART_VLAN_CONFIG:
+ return (false);
default:
return (true);
}
And that seems to work for my particular chipset and use case.
---Mike
___
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: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 07.11.2020 2:46, Eric Joyner wrote: The other issue is that I still don't know which devices need a restart / which devices do not, or whether a restart is strictly necessary and if there is another way to do this without worrying about restarting the device. Could this be copied from pre-iflib driver? It did right things without unneeded resets, including some `em` chips. BTW, I'm surprised, that pre-iflib drivers still available on Intel site and in ports. And sometimes works better :-( -- // Lev Serebryakov ___ 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: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed
On 07/11/2020 19:00, Mateusz Guzik wrote: > Fixed as of r367454 (also see r367453). Thank you! > On 11/6/20, Mateusz Guzik wrote: >> I think I have an idea how to keep this. In the meantime you can just >> comment it out. >> >> On 11/6/20, Mateusz Guzik wrote: >>> On 11/6/20, Andriy Gapon wrote: On 06/11/2020 22:58, Mateusz Guzik wrote: > Note the underlying primitive was recently replaced. > > One immediate thing to check would be exact state of the lock. > READ_HELD checks for reading only, fails if you have this > write-locked, which is a plausible explanation if you are coming in > from less likely codepath. > > iow what's the backtrace and can you print both rms->readers and > rms->owner (+ curthread) Unfortunately, I do not have a vmcore, only a picture of the screen. ZFS code looks correct, the lock should be held in read mode, so indeed I suspect that the problem is with rms. It looks like rms_rlock() does not change rmslock::readers, but rms_rowned() checks it? That's just from a first, super-quick look at the code. >>> >>> Heh, now that you mention it, I remember wanting to just remove the >>> arguably spurious assert. Linux is never doing it for reading. The >>> only state asserts made are for writing which works fine. >>> >>> As for reading assertions, there is no performant way to make it work >>> and I don't think it is worth it as it is. >>> >>> As such, I vote for just removing these 2 asserts. They really don't >>> buy anything to begin with. >>> >>> -- >>> Mateusz Guzik >>> >> >> >> -- >> Mateusz Guzik >> > > -- Andriy Gapon ___ 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"
