HAST different disk sizes
The documentation for HAST assumes that the disks being used are of identical size. In the real world, this rarely happens. How are disks of different sizes handled? In my case, on drive is about 1TB and one is about 500GB. Is it possible to run HAST on a partition? All the examles show it running on the raw device (/dev/da0, for example). I guess if the answer to the second question is "yes, you can run HAST on a partition", then it also answers my first question. I'm sorry if this is the wrong list. freebsd-cluster seems to be dormant except for spam. ___ 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))
Ah -- I didn't implement the fix I had in that bugzilla correctly -- em and
igb devices will use the same function instead of using two different ones
even though it seems em devices generally require the interface restart yet
igb devices do not.
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.
- Eric
On Fri, Nov 6, 2020 at 3:35 PM mike tancsa wrote:
> On 11/6/2020 5:32 PM, Eric Joyner wrote:
> > Could you reply to that issue with what you've found?
> >
> > Though, as far as I can recall, igb(4) devices are not supposed to do
> > the iflib reset talked about in the bug, so I wouldn't expect to see a
> > link flap on those.
> >
> Hi Eric,
>
> I have added my findings to
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
>
> I tried it on 3 different vendor's boards. All I210 variants it seems.
>
> I am testing with
>
> --- if_em.c 2020-11-06 15:00:22.120953000 -0500
> +++ /tmp/if_em.c2020-11-06 14:59:55.678195000 -0500
> @@ -4047,6 +4047,7 @@
> {
> switch (event) {
> case IFLIB_RESTART_VLAN_CONFIG:
> + return (false);
> default:
> return (true);
> }
>
> And if fixes the problem, but not quite sure if it introduces any
> regressions or other issues ?
>
> ---Mike
>
>
> > - Eric
> >
> > On Fri, Nov 6, 2020 at 12:48 PM mike tancsa > > wrote:
> >
> > On 11/6/2020 2:17 PM, mike tancsa wrote:
> > > On 5/31/2020 5:39 PM, Lev Serebryakov wrote:
> > >> Hello Ian,
> > >>
> > >> Thursday, May 28, 2020, 2:45:48 AM, you wrote:
> > >>
> > >>> I noticed that my VLAN interfaces stopped working after a
> > recent build.
> > >>> tcpdump showed traffic leaving leaving and entering the
> > interface but no
> > >>> host on the network actually received any packets from this
> > host. A
> > >>> binary search led me to r360902 and indeed the following
> > change fixed
> > >>> the issue for me:
> > >> Problem is, this change will return terrible situation when
> > adding new VLAN
> > >> will flap connection status.
> > >>
> > >> It all worked before iflib: hardware VLAN filtering worked, and
> > >> adding/removing new VLAN didn't cause link to flap.
> > >>
> > >> Now, with iflib, looks like we can not have all good things at
> > once :(
> >
> >
> > Looks like this is captured in
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
> >
> >
> >
> > > Hi All,
> > >
> > > Just came across this thread as I am running into this behaviour on
> > > RELENG_12. Adding a new vlan causes all vlans on the parent
> > interface
> > > to flap. Not the greatest thing as it bounces a LOT of traffic
> > > potentially, flaps routing etc. Is there a way around this ?
> > >
> > > This is on r367411 releng12
> > >
> > > igb0@pci0:2:0:0:class=0x02 card=0x153315d9
> > chip=0x15338086
> > > rev=0x03 hdr=0x00
> > > vendor = 'Intel Corporation'
> > > device = 'I210 Gigabit Network Connection'
> > > class = network
> > > subclass = ethernet
> > >
> > > eg. just something simple like
> > >
> > > ifconfig vlan16 create 10.1.2.3/29 vlandev
> > igb1 vlan 16
> > >
> > > # dmesg | tail -8
> > > igb1: link state changed to DOWN
> > > vlan16: link state changed to DOWN
> > > vlan2049: link state changed to DOWN
> > > vlan15: link state changed to DOWN
> > > igb1: link state changed to UP
> > > vlan16: link state changed to UP
> > > vlan2049: link state changed to UP
> > > vlan15: link state changed to UP
> > >
> > >
> > > ---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
> > "
> > >
> > ___
> > 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/6/2020 5:32 PM, Eric Joyner wrote:
> Could you reply to that issue with what you've found?
>
> Though, as far as I can recall, igb(4) devices are not supposed to do
> the iflib reset talked about in the bug, so I wouldn't expect to see a
> link flap on those.
>
Hi Eric,
I have added my findings to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
I tried it on 3 different vendor's boards. All I210 variants it seems.
I am testing with
--- if_em.c 2020-11-06 15:00:22.120953000 -0500
+++ /tmp/if_em.c 2020-11-06 14:59:55.678195000 -0500
@@ -4047,6 +4047,7 @@
{
switch (event) {
case IFLIB_RESTART_VLAN_CONFIG:
+ return (false);
default:
return (true);
}
And if fixes the problem, but not quite sure if it introduces any
regressions or other issues ?
---Mike
> - Eric
>
> On Fri, Nov 6, 2020 at 12:48 PM mike tancsa > wrote:
>
> On 11/6/2020 2:17 PM, mike tancsa wrote:
> > On 5/31/2020 5:39 PM, Lev Serebryakov wrote:
> >> Hello Ian,
> >>
> >> Thursday, May 28, 2020, 2:45:48 AM, you wrote:
> >>
> >>> I noticed that my VLAN interfaces stopped working after a
> recent build.
> >>> tcpdump showed traffic leaving leaving and entering the
> interface but no
> >>> host on the network actually received any packets from this
> host. A
> >>> binary search led me to r360902 and indeed the following
> change fixed
> >>> the issue for me:
> >> Problem is, this change will return terrible situation when
> adding new VLAN
> >> will flap connection status.
> >>
> >> It all worked before iflib: hardware VLAN filtering worked, and
> >> adding/removing new VLAN didn't cause link to flap.
> >>
> >> Now, with iflib, looks like we can not have all good things at
> once :(
>
>
> Looks like this is captured in
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818
>
>
>
> > Hi All,
> >
> > Just came across this thread as I am running into this behaviour on
> > RELENG_12. Adding a new vlan causes all vlans on the parent
> interface
> > to flap. Not the greatest thing as it bounces a LOT of traffic
> > potentially, flaps routing etc. Is there a way around this ?
> >
> > This is on r367411 releng12
> >
> > igb0@pci0:2:0:0: class=0x02 card=0x153315d9
> chip=0x15338086
> > rev=0x03 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'I210 Gigabit Network Connection'
> > class = network
> > subclass = ethernet
> >
> > eg. just something simple like
> >
> > ifconfig vlan16 create 10.1.2.3/29 vlandev
> igb1 vlan 16
> >
> > # dmesg | tail -8
> > igb1: link state changed to DOWN
> > vlan16: link state changed to DOWN
> > vlan2049: link state changed to DOWN
> > vlan15: link state changed to DOWN
> > igb1: link state changed to UP
> > vlan16: link state changed to UP
> > vlan2049: link state changed to UP
> > vlan15: link state changed to UP
> >
> >
> > ---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
> "
> >
> ___
> 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
> "
>
___
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"
(perceived) regression for panics during boot
Having tried an upgrade from r365296 to r367410 I ran into a problem. If a system panics during boot, then it does not automatically reboot. It prints: Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. So, it looks like the system detects a (phantom) key press after it prints the first line and then it (correctly) does not see any more key presses. The result is that unattended systems just hang at the prompt. I do not recall having this problem earlier. Not sure where the regression could be. Perhaps something changed in the keyboard initialization? -- 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"
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
Could you reply to that issue with what you've found? Though, as far as I can recall, igb(4) devices are not supposed to do the iflib reset talked about in the bug, so I wouldn't expect to see a link flap on those. - Eric On Fri, Nov 6, 2020 at 12:48 PM mike tancsa wrote: > On 11/6/2020 2:17 PM, mike tancsa wrote: > > On 5/31/2020 5:39 PM, Lev Serebryakov wrote: > >> Hello Ian, > >> > >> Thursday, May 28, 2020, 2:45:48 AM, you wrote: > >> > >>> I noticed that my VLAN interfaces stopped working after a recent > build. > >>> tcpdump showed traffic leaving leaving and entering the interface but > no > >>> host on the network actually received any packets from this host. A > >>> binary search led me to r360902 and indeed the following change fixed > >>> the issue for me: > >> Problem is, this change will return terrible situation when adding new > VLAN > >> will flap connection status. > >> > >> It all worked before iflib: hardware VLAN filtering worked, and > >> adding/removing new VLAN didn't cause link to flap. > >> > >> Now, with iflib, looks like we can not have all good things at once :( > > > Looks like this is captured in > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 > > > > Hi All, > > > > Just came across this thread as I am running into this behaviour on > > RELENG_12. Adding a new vlan causes all vlans on the parent interface > > to flap. Not the greatest thing as it bounces a LOT of traffic > > potentially, flaps routing etc. Is there a way around this ? > > > > This is on r367411 releng12 > > > > igb0@pci0:2:0:0:class=0x02 card=0x153315d9 chip=0x15338086 > > rev=0x03 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'I210 Gigabit Network Connection' > > class = network > > subclass = ethernet > > > > eg. just something simple like > > > > ifconfig vlan16 create 10.1.2.3/29 vlandev igb1 vlan 16 > > > > # dmesg | tail -8 > > igb1: link state changed to DOWN > > vlan16: link state changed to DOWN > > vlan2049: link state changed to DOWN > > vlan15: link state changed to DOWN > > igb1: link state changed to UP > > vlan16: link state changed to UP > > vlan2049: link state changed to UP > > vlan15: link state changed to UP > > > > > > ---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" > > > ___ > 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" > ___ 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
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 ___ 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 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 ___ 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 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. > On 11/6/20, Andriy Gapon wrote: >> >> The subject panic happens for me with r367410 when mounting root >> filesystem. >> The panic is in zfs_freebsd_cached_lookup -> zfs_lookup -> zfs_dirlook. >> I have a picture of the screen with a little bit more details, I'll share it >> later. -- 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"
Re: panic: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed
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) On 11/6/20, Andriy Gapon wrote: > > The subject panic happens for me with r367410 when mounting root > filesystem. > The panic is in zfs_freebsd_cached_lookup -> zfs_lookup -> zfs_dirlook. > I have a picture of the screen with a little bit more details, I'll share it > later. > > -- > 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" > -- Mateusz Guzik ___ 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: Fails to load linprocfs
From: Yasuhiro KIMURA Subject: Fails to load linprocfs Date: Sat, 07 Nov 2020 05:11:20 +0900 (JST) > I updated both host and poudriere jail from r367172 to r367418. But > after that `poudriere bulk` fails as following. > (snip) > > What's wrong? Two people told me following bug report by private mail. linux_common fails to load as a module after r367395: link_elf_obj: symbol sdt_provider_linuxulator undefined https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250897 Just FYI. --- Yasuhiro KIMURA ___ 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"
panic: VERIFY(ZFS_TEARDOWN_READ_HELD(zfsvfs)) failed
The subject panic happens for me with r367410 when mounting root filesystem. The panic is in zfs_freebsd_cached_lookup -> zfs_lookup -> zfs_dirlook. I have a picture of the screen with a little bit more details, I'll share it later. -- 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"
Re: Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 11/6/2020 2:17 PM, mike tancsa wrote: > On 5/31/2020 5:39 PM, Lev Serebryakov wrote: >> Hello Ian, >> >> Thursday, May 28, 2020, 2:45:48 AM, you wrote: >> >>> I noticed that my VLAN interfaces stopped working after a recent build. >>> tcpdump showed traffic leaving leaving and entering the interface but no >>> host on the network actually received any packets from this host. A >>> binary search led me to r360902 and indeed the following change fixed >>> the issue for me: >> Problem is, this change will return terrible situation when adding new VLAN >> will flap connection status. >> >> It all worked before iflib: hardware VLAN filtering worked, and >> adding/removing new VLAN didn't cause link to flap. >> >> Now, with iflib, looks like we can not have all good things at once :( Looks like this is captured in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 > Hi All, > > Just came across this thread as I am running into this behaviour on > RELENG_12. Adding a new vlan causes all vlans on the parent interface > to flap. Not the greatest thing as it bounces a LOT of traffic > potentially, flaps routing etc. Is there a way around this ? > > This is on r367411 releng12 > > igb0@pci0:2:0:0: class=0x02 card=0x153315d9 chip=0x15338086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'I210 Gigabit Network Connection' > class = network > subclass = ethernet > > eg. just something simple like > > ifconfig vlan16 create 10.1.2.3/29 vlandev igb1 vlan 16 > > # dmesg | tail -8 > igb1: link state changed to DOWN > vlan16: link state changed to DOWN > vlan2049: link state changed to DOWN > vlan15: link state changed to DOWN > igb1: link state changed to UP > vlan16: link state changed to UP > vlan2049: link state changed to UP > vlan15: link state changed to UP > > > ---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" > ___ 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"
Fails to load linprocfs
Hello, I updated both host and poudriere jail from r367172 to r367418. But after that `poudriere bulk` fails as following. -- yasu@rolling-vm-freebsd1[1014]% uname -a FreeBSD rolling-vm-freebsd1.home.utahime.org 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r367418: Sat Nov 7 02:00:32 JST 2020 ro...@rolling-vm-freebsd1.home.utahime.org:/usr0/freebsd/base/obj/usr0/freebsd/base/head/amd64.amd64/sys/GENERIC amd64 yasu@rolling-vm-freebsd1[1014]% sudo -i poudriere bulk -j curamd64 -z LocalSetting -f /usr/local/etc/ports-list.txt kldload: an error occurred while loading module linprocfs. Please check dmesg(8) for more details. [00:00:00] Error: Required kernel module 'linprocfs' not found yasu@rolling-vm-freebsd1[1015]% -- Executing `sudo -i kldload linprocfs.ko` results in same error. -- yasu@rolling-vm-freebsd1[1016]% sudo -i kldload linprocfs.ko kldload: an error occurred while loading module linprocfs.ko. Please check dmesg(8) for more details. yasu@rolling-vm-freebsd1[1017]% -- dmesg(8) shows following error messages. -- link_elf_obj: symbol sdt_provider_linuxulator undefined linker_load_file: /boot/kernel/linux_common.ko - unsupported file type KLD linprocfs.ko: depends on linux_common - not available or version mismatch linker_load_file: /boot/kernel/linprocfs.ko - unsupported file type -- What's wrong? Best Regards. --- Yasuhiro KIMURA ___ 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"
Link flap when adding / removing a vlan (was Re: r360902 breaks VLAN interface on if_em (82579LM))
On 5/31/2020 5:39 PM, Lev Serebryakov wrote: > Hello Ian, > > Thursday, May 28, 2020, 2:45:48 AM, you wrote: > >> I noticed that my VLAN interfaces stopped working after a recent build. >> tcpdump showed traffic leaving leaving and entering the interface but no >> host on the network actually received any packets from this host. A >> binary search led me to r360902 and indeed the following change fixed >> the issue for me: > Problem is, this change will return terrible situation when adding new VLAN > will flap connection status. > > It all worked before iflib: hardware VLAN filtering worked, and > adding/removing new VLAN didn't cause link to flap. > > Now, with iflib, looks like we can not have all good things at once :( Hi All, Just came across this thread as I am running into this behaviour on RELENG_12. Adding a new vlan causes all vlans on the parent interface to flap. Not the greatest thing as it bounces a LOT of traffic potentially, flaps routing etc. Is there a way around this ? This is on r367411 releng12 igb0@pci0:2:0:0: class=0x02 card=0x153315d9 chip=0x15338086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'I210 Gigabit Network Connection' class = network subclass = ethernet eg. just something simple like ifconfig vlan16 create 10.1.2.3/29 vlandev igb1 vlan 16 # dmesg | tail -8 igb1: link state changed to DOWN vlan16: link state changed to DOWN vlan2049: link state changed to DOWN vlan15: link state changed to DOWN igb1: link state changed to UP vlan16: link state changed to UP vlan2049: link state changed to UP vlan15: link state changed to UP ---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: r367415: can't load linuxulator, link_elf_obj: symbol sdt_provider_linuxulator undefined
On Fri, Nov 06, 2020 at 08:35:41AM -0800, John Kennedy wrote: > Trying a run against r367420 with the LIN_SDT_PROVIDER_DECLARE() commented > out. Not the solution. ___ 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: r367415: can't load linuxulator, link_elf_obj: symbol sdt_provider_linuxulator undefined
On Fri, Nov 06, 2020 at 08:35:41AM -0800, John Kennedy wrote: > I had this crop up this morning r367410, while yesterdays build against > r367379 seemed fine. I think this is an issue because of r367395: > > linux(4): Deduplicate unimpl/dummy syscall handlers > > If I tracked it down correctly, the LIN_SDT_PROVIDER_DECLARE(LINUX_DTRACE) > in sys/compat/linux/linux_dummy.c creates an undefined external structure > sdt_provider_linuxulator, which breaks poudriere and X11 (at least via > nvidia drivers). > > [from /var/log/messages] > kernel: link_elf_obj: symbol sdt_provider_linuxulator undefined > kernel: linker_load_file: /boot/kernel/linux_common.ko - unsupported > file type > kernel: KLD linprocfs.ko: depends on linux_common - not available or > version mismatch > > I guess to be more precise, X11 complained about this: > > (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see > the > (EE) NVIDIA: system's kernel log for additional error messages and > (EE) NVIDIA: consult the NVIDIA README for details. > > Normally no issues there since I have PORTS_MODULES += x11/nvidia-driver, > but I was going to re-poudriere everything since __FreeBSD_version got bumped > and that's when I noticed that poudriere had issues: > > Error: Required kernel module 'linprocfs' not found > > Trying a run against r367420 with the LIN_SDT_PROVIDER_DECLARE() commented > out. It looks like there is already an open bug report for this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=250897 Looks like an ordering issue with linux_dummy, linux_common, and linux64. ___ 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"
r367415: can't load linuxulator, link_elf_obj: symbol sdt_provider_linuxulator undefined
I had this crop up this morning r367410, while yesterdays build against r367379 seemed fine. I think this is an issue because of r367395: linux(4): Deduplicate unimpl/dummy syscall handlers If I tracked it down correctly, the LIN_SDT_PROVIDER_DECLARE(LINUX_DTRACE) in sys/compat/linux/linux_dummy.c creates an undefined external structure sdt_provider_linuxulator, which breaks poudriere and X11 (at least via nvidia drivers). [from /var/log/messages] kernel: link_elf_obj: symbol sdt_provider_linuxulator undefined kernel: linker_load_file: /boot/kernel/linux_common.ko - unsupported file type kernel: KLD linprocfs.ko: depends on linux_common - not available or version mismatch I guess to be more precise, X11 complained about this: (EE) NVIDIA: Failed to initialize the NVIDIA kernel module. Please see the (EE) NVIDIA: system's kernel log for additional error messages and (EE) NVIDIA: consult the NVIDIA README for details. Normally no issues there since I have PORTS_MODULES += x11/nvidia-driver, but I was going to re-poudriere everything since __FreeBSD_version got bumped and that's when I noticed that poudriere had issues: Error: Required kernel module 'linprocfs' not found Trying a run against r367420 with the LIN_SDT_PROVIDER_DECLARE() commented out. ___ 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: r367415: can't load linuxulator, link_elf_obj: symbol sdt_provider_linuxulator undefined
On Fri, Nov 06, 2020 at 09:59:06AM +0100, O. Hartmann wrote: > Just updated CURRENT to r367415 and loading linux kernel module(s) fail with > > # kldload linux > > link_elf_obj: symbol sdt_provider_linuxulator undefined > linker_load_file: /boot/kernel/linux_common.ko - unsupported file type > KLD linux.ko: depends on linux_common - not available or version mismatch > linker_load_file: /boot/kernel/linux.ko - unsupported file type > > Neither manual linux module loading works, nor rc.conf based. > > What happended? > > Thanks, > > oh > I do not have an answer, but I offer corroboration: I saw it, as well, after updating my laptop's "head" slice from r367368 to r367410. (Note that r367410 is the most recent commit to head when the repository is updated to r367415.) In the list of files updated between those commits, I find the following files updated that have "linux" in their names: D/S4/usr/src/sys/amd64/linux/linux_dummy.c A/S4/usr/src/sys/amd64/linux/linux_dummy_machdep.c U/S4/usr/src/sys/amd64/linux32/linux32_dummy.c D/S4/usr/src/sys/arm64/linux/linux_dummy.c A/S4/usr/src/sys/arm64/linux/linux_dummy_machdep.c A/S4/usr/src/sys/compat/linux/linux_dummy.c D/S4/usr/src/sys/i386/linux/linux_dummy.c A/S4/usr/src/sys/i386/linux/linux_dummy_machdep.c U/S4/usr/src/sys/modules/linux/Makefile U/S4/usr/src/sys/modules/linux64/Makefile U/S4/usr/src/sys/modules/linux_common/Makefile A/S4/usr/src/sys/x86/linux A/S4/usr/src/sys/x86/linux/linux_dummy_x86.c For src/sys/amd64/linux/linux_dummy_machdep.c, the most recent change is: r367395 | cem | 2020-11-05 11:30:31 -0800 (Thu, 05 Nov 2020) | 7 lines linux(4): Deduplicate unimpl/dummy syscall handlers No functional change. Reviewed by:emaste, trasz Differential Revision: https://reviews.freebsd.org/D27099 Peace, david -- David H. Wolfskill da...@catwhisker.org Trump didn't "undercut his own credibility," because he didn't have any. See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
r367415: can't load linuxulator, link_elf_obj: symbol sdt_provider_linuxulator undefined
Just updated CURRENT to r367415 and loading linux kernel module(s) fail with # kldload linux link_elf_obj: symbol sdt_provider_linuxulator undefined linker_load_file: /boot/kernel/linux_common.ko - unsupported file type KLD linux.ko: depends on linux_common - not available or version mismatch linker_load_file: /boot/kernel/linux.ko - unsupported file type Neither manual linux module loading works, nor rc.conf based. What happended? Thanks, oh ___ 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"
