[Bug 243538] [vmware] Startup process freeze for VM with a single cpu and attached cdrom drive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243538 Bug ID: 243538 Summary: [vmware] Startup process freeze for VM with a single cpu and attached cdrom drive Product: Base System Version: 11.3-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: hadesis...@gmail.com Created attachment 210981 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210981&action=edit Boot freeze screenshot FreeBSD 11.3 and higher versions deployed as a VM on vmware platform can get stuck when configured with a single CPU/single core as soon as a cdrom drive is attached (Tested on ESXi 6.0, ESX 6.5 and on VMWare Workstation 15 Player). Notice that the VM doesn't crash but just hangs in the booting process as indicated in the attached screenshot. This issue was likely introduced by the fix proposed for the following issue https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219857 since previous build are not affected. This is not critical as several work around are available: adding a CPU or detaching the cdrom do the trick, but this might have other unidentified side effects. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243538] [vmware] Startup process freeze for VM with a single cpu and attached cdrom drive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243538 --- Comment #1 from Andriy Gapon --- (In reply to Alexis.S from comment #0) What's the point of this report? Have seen the latest comments and commits in bug 219857 which you referenced? -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243538] [vmware] Startup process freeze for VM with a single cpu and attached cdrom drive
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243538 Alexis.S changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED --- Comment #2 from Alexis.S --- @Andriy Gapon Good point, I didn't payed enough attention to this last post as I prepared this report a while ago. I should have checked back the original issue. Tested on FreeBSD 11.3-STABLE r356901 on ESXi 6.0.0 it seems fixed. Sorry for the noise, this one can be closed. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243534] Kernel panics with "panic: invalid count 2" early during boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243534 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #1 from Ed Maste --- This happened on other architectures after r355784; see the thread at https://lists.freebsd.org/pipermail/svn-src-all/2019-December/191362.html It was fixed for others in r355819. I'll apply the same change to sparc64. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243534] Kernel panics with "panic: invalid count 2" early during boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243534 --- Comment #2 from commit-h...@freebsd.org --- A commit references this bug: Author: emaste Date: Thu Jan 23 14:11:03 UTC 2020 New revision: 357045 URL: https://svnweb.freebsd.org/changeset/base/357045 Log: Apply r355819 to sparc64 - fix assertion failure after r355784 From r355819: Repeat the spinlock_enter/exit pattern from amd64 on other architectures to fix an assert violation introduced in r355784. Without this spinlock_exit() may see owepreempt and switch before reducing the spinlock count. amd64 had been optimized to do a single critical enter/exit regardless of the number of spinlocks which avoided the problem and this optimization had not been applied elsewhere. This is completely untested - I have no obsolete Sparc hardware - but someone did try testing recent changes on sparc64 (PR 243534). PR: 243534 Changes: head/sys/sparc64/sparc64/machdep.c -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243534] Kernel panics with "panic: invalid count 2" early during boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243534 --- Comment #3 from Ed Maste --- FYI I have the GCC removal changes staged in a Git branch on GitHub at https://github.com/emaste/freebsd/tree/deorbit-gcc (which includes the change I just committed). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243534] Kernel panics with "panic: invalid count 2" early during boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243534 --- Comment #4 from Michael Reim --- (In reply to Ed Maste from comment #1) Thanks for the quick fix! It solved that problem and lead to the machine boot further. With r357045 I'm getting a new panic, though (this time obviously from the VM system): Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... jumping to kernel entry at 0xc00b8020. GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2020 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT #0 r357046: Thu Jan 23 15:54:21 CET 2020 r...@fbsdtest.omc.net:/usr/obj/usr/src/sparc64.sparc64/sys/GENERIC sparc64 gcc version 9.2.0 (FreeBSD Ports Collection for sparc64) WARNING: WITNESS option enabled, expect reduced performance. real memory = 1073741824 (1024 MB) avail memory = 1024761856 (977 MB) cpu0: Sun Microsystems UltraSparc-IIe Processor (548.00 MHz CPU) random: unblocking device. random: entropy device external interface [ath_hal] loaded WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. kbd0 at kbdmux0 WARNING: Device "openfirm" is Giant locked and may be deleted before FreeBSD 13.0. WARNING: Device "openprom" is Giant locked and may be deleted before FreeBSD 13.0. nexus0: pcib0: mem 0x1fe-0x1fe,0x1fe0100-0x1fe01ff irq 2032,2030,2031,2021 on nexus0 pcib0: Sabre, impl 0, version 0, IGN 0x1f, bus A, 66MHz pcib0: DVMA map: 0x6000 to 0x63ff 8192 entries pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 3.0 (no driver attached) dc0: port 0x1-0x100ff mem 0-0xff at device 12.0 on pci0 miibus0: on dc0 amphy0: PHY 1 on miibus0 amphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:03:ba:4e:55:e6 dc1: port 0x10100-0x101ff mem 0x2000-0x20ff at device 5.0 on pci0 miibus1: on dc1 amphy1: PHY 1 on miibus1 amphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: Ethernet address: 00:03:ba:4e:55:e6 ohci0: mem 0x100-0x1000fff at device 10.0 on pci0 usbus0 on ohci0 atapci0: port 0x10200-0x10207,0x10218-0x1021b,0x10210-0x10217,0x10208-0x1020b,0x10220-0x1022f at device 13.0 on pci0 atapci0: using PIO transfers above 137GB as workaround for 48bit DMA access bug, expect reduced performance ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 cryptosoft0: on nexus0 nexus0: type unknown (no driver attached) rtc0: at port 0x70-0x71 pnpid PNP0b00 on isa0 rtc0: registered as a time-of-day clock, resolution 1.00s uart0: console (9600,n,8,1)> at port 0x3f8-0x3ff irq 43 pnpid PNP0501 on isa0 uart1: <16550 or compatible> at port 0x2e8-0x2ef irq 43 pnpid PNP0501 on isa0 Timecounter "tick" frequency 54800 Hz quality 1000 Event timer "tick" frequency 54800 Hz quality 1000 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 Obsolete code will be removed soon: random(9) is the obsolete Park-Miller LCG from 1988 WARNING: WITNESS option enabled, expect reduced performance. ugen0.1: at usbus0 uhub0 on usbus0 uhub0: on usbus0 Trying to mount root from ufs:/dev/ada1a [rw]... Root mount waiting for: usbus0 CAM cd0 at ata3 bus 0 scbus1 target 1 lun 0 cd0: Removable CD-ROM SCSI device cd0: 16.700MB/s transfers (WDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present uhub0: 2 ports with 2 removable, self powered ada0 at ata2 bus 0 scbus0 target 0 lun 0 ada0: ATA-5 device ada0: Serial Number SZPTZ202544 ada0: 66.700MB/s transfers (UDMA4, PIO 8192bytes) ada0: 58644MB (120103200 512 byte sectors) ada1 at ata3 bus 0 scbus1 target 0 lun 0 ada1: ATA-5 device ada1: Serial Number YFEYFML4312 ada1: 66.700MB/s transfers (UDMA4, PIO 8192bytes) ada1: 14649MB (30003120 512 byte sectors) mountroot: waiting for device /dev/ada1a... panic: vm_page_assert_xbusied: page 0xf8009f65cb90 not exclusive busy @ /usr/src/sys/vm/vm_page.c:1555 cpuid = 0 time = 1579793596 KDB: stack backtrace: _end() at 0xc92e90f8 vpanic() at vpanic+0x31c panic() at pa
[Bug 243534] Kernel panics with "panic: invalid count 2" early during boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243534
Mark Johnston changed:
What|Removed |Added
CC||ma...@freebsd.org
--- Comment #5 from Mark Johnston ---
sparc64's pmap_release() is freeing pages belonging to the TSB object, and the
new vm_page_free() contract requires the caller to busy the page.
diff --git a/sys/sparc64/sparc64/pmap.c b/sys/sparc64/sparc64/pmap.c
index 46454795ad26..753bd6af5aa1 100644
--- a/sys/sparc64/sparc64/pmap.c
+++ b/sys/sparc64/sparc64/pmap.c
@@ -1301,6 +1301,7 @@ pmap_release(pmap_t pm)
while (!TAILQ_EMPTY(&obj->memq)) {
m = TAILQ_FIRST(&obj->memq);
m->md.pmap = NULL;
+ vm_page_xbusy(m);
vm_page_unwire_noq(m);
vm_page_free_zero(m);
}
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Advice:Port these utilities/drivers to FreeBSD
FreeBSD Version: 12.0 Advice:Port these utilities/drivers to FreeBSD: Linux x86_energy_perf_policy utility VMware PVSCSI Driver Intel Ice Lake GPU Driver ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243534] Kernel panics with "panic: invalid count 2" early during boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243534 --- Comment #6 from Michael Reim --- (In reply to Mark Johnston from comment #5) Thank you, that fixed the second issue! I re-built the kernel after applying your patch and was able to successfully boot it up. So now we have a working SPARC64 -CURRENT kernel built using the xtoolchain. I'll see if I can build the userland, too, next. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243533] vt_fb.c can overwrite frame buffer bounds if stride length is not a multiple of bytes-per-pixel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243533 Thomas Skibo changed: What|Removed |Added Attachment #210977|0 |1 is obsolete|| --- Comment #1 from Thomas Skibo --- Created attachment 210991 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210991&action=edit fix vt_fb_blank(). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243533] vt_fb.c can overwrite frame buffer bounds if stride length is not a multiple of bytes-per-pixel
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243533 --- Comment #2 from Thomas Skibo --- Comment on attachment 210991 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210991 fix vt_fb_blank(). My previous patch was wrong. fb_width is the width in pixels, not bytes. This was my other suggested fix. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 234031] loader can't traverse filesystem, LUA ERROR: cannot open /boot/lua/loader.lua
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234031 --- Comment #28 from Sean McBride --- I don't think this is fixed. My hardware is much like Trev's 2019-04-16 comment: I'm using an old MacPro1,1. [1] All disks physically removed except a real DVD made from the .iso. No upgrading here, just trying to boot an install DVD. My result is much like Jeff Gibbons' 2019-02-15 comment, but I've used a newer build: FreeBSD-13.0-CURRENT-amd64-20191226-r356085-disc1.iso.xz By contrast, I've succeeded in booting an OpenBSD 6.6 install DVD. So I'm pretty sure my hardware is fine, and my DVD burning works. [1] https://everymac.com/systems/apple/mac_pro/specs/mac-pro-quad-2.66-specs.html -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 234031] loader can't traverse filesystem, LUA ERROR: cannot open /boot/lua/loader.lua
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234031 --- Comment #29 from Toomas Soome --- (In reply to Sean McBride from comment #28) Could you test with latest image (20200123 seems to be currenlty latest one). Also please paste output from lsdev -v (from loader prompt). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243534] Kernel panics with "panic: invalid count 2" early during boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243534 Ed Maste changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243534] Kernel panics with "panic: invalid count 2" early during boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243534 --- Comment #7 from commit-h...@freebsd.org --- A commit references this bug: Author: markj Date: Thu Jan 23 17:18:59 UTC 2020 New revision: 357055 URL: https://svnweb.freebsd.org/changeset/base/357055 Log: sparc64: Busy the TSB page before freeing it in pmap_release(). This is now required by vm_page_free(). PR: 243534 Reported and tested by: Michael Reim Changes: head/sys/sparc64/sparc64/pmap.c -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243548] mlx4en shows DAC cable media type as '10Gbase-SR'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243548 Bug ID: 243548 Summary: mlx4en shows DAC cable media type as '10Gbase-SR' Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: greg@unrelenting.technology Not a serious problem but something I've noticed — for the same cable, an Intel (ix) card correctly shows: media: Ethernet autoselect (10Gbase-Twinax ) While mlx4en (ConnectX-2) shows: media: Ethernet autoselect (10Gbase-SR ) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243551] Cannot "svn checkout" in automounted $HOME
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243551
Bug ID: 243551
Summary: Cannot "svn checkout" in automounted $HOME
Product: Base System
Version: 12.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: jo...@freebsd.org
On a server where user's $HOME is automounted through the following maps:
/etc/auto_master:
/home auto_home
/etc/auto_home:
* -nfsv4 server:/home/&
trying to "svn checkout" a new working copy from any SVN server yields:
joerg@daemon ~/tmp% svn co https://svn.freebsd.org/base
svn: E05: Can't check path '/home/.svn/wc.db': Input/output error
The respective ktrace output is:
8779 svn NAMI "/home/joerg/.svn"
8779 svn RET fstatat -1 errno 2 No such file or directory
8779 svn CALL
fstatat(AT_FDCWD,0x801abc0d0,0x7fffdfa0,0x200)
8779 svn NAMI "/home/.svn"
8779 svn STRU struct stat {dev=18446744072887533315, ino=4,
mode=040755, nlink=3, uid=0, gid=0, rdev=0, atime=1579769649.589640074,
mtime=1579769649.589640074, ctime=1579769649.589640074,
birthtime=1579769649.589640074, size=512, blksize=4096, blocks=1, flags=0x0 }
8779 svn RET fstatat 0
8779 svn CALL
fstatat(AT_FDCWD,0x8013e6d80,0x7fffdf30,0x200)
8779 svn NAMI "/home/.svn/wc.db"
8779 svn RET fstatat -1 errno 5 Input/output error
8779 svn CALL write(0x2,0x80137e1e0,0x46)
8779 svn GIO fd 2 wrote 70 bytes
"svn: E05: Can't check path '/home/.svn/wc.db': Input/output error
"
So SVN traverses directories upwards for .svn/wc.db entries. Surprisingly
enough, stat(2) on /home/.svn does not yield the expected ENOENT but a valid
result. (NB: /home/.svn does *not* exist on the NFS server.) However, trying to
access wc.db under that ficticous directory then yields EIO.
The automountd debug log looks like that:
Jan 23 21:34:44 daemon automountd[8692]: map "auto_home" maps to
"/etc/auto_home"
Jan 23 21:34:44 daemon automountd[8692]: done parsing map "auto_home"
Jan 23 21:34:44 daemon automountd[8692]: map may contain wildcard entries
Jan 23 21:34:44 daemon automountd[8692]: found node defined at auto_home:1; it
is a mountpoint
Jan 23 21:34:44 daemon automountd[8692]: fstype not specified in options;
defaulting to "nfs"
Jan 23 21:34:44 daemon automountd[8692]: retrycnt not specified in options;
defaulting to 1
Jan 23 21:34:44 daemon automountd[8692]: executing "mount -t nfs -o
nfsv4,automounted,retrycnt=1 alfred.sax.de:/home/joerg /home/joerg/" as pid
8693
Jan 23 21:34:44 daemon automountd[8692]: "mount -t nfs -o
nfsv4,automounted,retrycnt=1 alfred.sax.de:/home/joerg /home/joerg/", pid 8693,
terminated gracefully
Jan 23 21:34:44 daemon automountd[8692]: mount done; exiting
Jan 23 21:34:44 daemon automountd[8692]: completing request 100 with error 0
Jan 23 21:34:44 daemon automountd[8675]: child process 8692 terminated
gracefully
Jan 23 21:34:44 daemon automountd[8675]: waiting for request from the kernel
Jan 23 21:35:26 daemon automountd[8675]: got request; forking child process #0
Jan 23 21:35:26 daemon automountd[8675]: waiting for request from the kernel
Jan 23 21:35:26 daemon automountd[8705]: got request 101: from map auto_home,
path /home/.svn/, prefix "/home", key ".svn", options ""
Jan 23 21:35:26 daemon automountd[8705]: parsing map "auto_home"
Jan 23 21:35:26 daemon automountd[8705]: map "auto_home" maps to
"/etc/auto_home"
Jan 23 21:35:26 daemon automountd[8705]: done parsing map "auto_home"
Jan 23 21:35:26 daemon automountd[8705]: map may contain wildcard entries
Jan 23 21:35:26 daemon automountd[8705]: found node defined at auto_home:1; it
is a mountpoint
Jan 23 21:35:26 daemon automountd[8705]: fstype not specified in options;
defaulting to "nfs"
Jan 23 21:35:26 daemon automountd[8705]: retrycnt not specified in options;
defaulting to 1
Jan 23 21:35:26 daemon automountd[8705]: executing "mount -t nfs -o
nfsv4,automounted,retrycnt=1 alfred.sax.de:/home/.svn /home/.svn/" as pid 8706
Jan 23 21:35:26 daemon automountd[8705]: completing request 101 with error 5
Jan 23 21:35:26 daemon automountd[8675]: child process 8705 terminated with
exit status 1
Jan 23 21:35:26 daemon automountd[8675]: waiting for request from the kernel
Jan 23 21:35:27 daemon automountd[8675]: got request; forking child process #0
Jan 23 21:35:27 daemon automountd[8675]: waiting for request from the kernel
Jan 23 21:35:27 daemon automountd[8708]: got request 102: from map auto_home,
path /home/.svn/, prefix "/home", key ".svn", options ""
Jan 23 21:35:27 daemon automountd[8708]: parsing map "auto_home"
Jan 23 21:35:27 daemon automountd[8708]: map "auto_home" maps to
"/etc/auto_home"
Jan 23 21:35:27 daemon automountd[8708]: done parsing map "auto_home"
Jan 23 21:35:27 daemon automountd[8708]: map may contain wildc
[Bug 204521] [new driver] [request] Port rtsx from OpenBSD to FreeBSD
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521 Sergey V. Dyatko changed: What|Removed |Added CC||sergey.dya...@gmail.com --- Comment #39 from Sergey V. Dyatko --- Hi, I have lenovo thinkpad t470p with none4@pci0:4:0:0: class=0xff rev=0x01 hdr=0x00 vendor=0x10ec device=0x522a subvendor=0x17aa subdevice=0x505d vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTS522A PCI Express Card Reader' and can test too -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243554] multicast packets not seen on PHY bridge member
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243554 Bug ID: 243554 Summary: multicast packets not seen on PHY bridge member Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: james.blac...@gmail.com Summary: if_bridge(4) purports in the man page[1] to forward multicast traffic to all members of the bridge. However, this does not appear to be the case. Extended summary: a bridge with members tap0, tap1, ... comprising bhyve virtual machines, as well as igb1 (the host's primary interface) forwards multicast traffic (mDNS specifically) among the taps, and OUT the PHY interface (igb1), however, the PHY interface does not receive inbound multicast traffic (on the FreeBSD side). Unicast traffic operates fine. Details: I use FreeBSD 12.1 as a VM host and ran into a problem with multicast packets over a bridge not being seen by programs [on the host] listening on the bridge's physical interface constituent (igb1), which I discovered when running avahi-daemon. Briefly, my setup is as follows: FreeBSD 11.2 host, bare metal, eth PHY igb1 bridge0 with members igb1, tap0, tap1 VM linux guest virtio-net to tap0 to bridge on FreeBSD VM freebsd guest virtio-net to tap1 to bridge on FreeBSD Mac, ethernet to same switch as FreeBSD mDNS query/response operates properly between the Mac and any of the others (both physical and virtual), and all work in the converse direction with the Mac. The guests, all of which are constituents of the bridge, are able to communicate via mDNS with one another. However, the guests are _unable_ to communicate with the host via mDNS. tcpdump shows the query packets appearing on igb1, but truss on avahi-daemon shows they are not received. This means multicast packets are forwarded OUT all members of the bridge, but not IN (at least, to physical interfaces -- they do go both directions on the taps) If I add an IP address to the bridge, avahi-daemon on the host binds to the bridge interface directly and then receives incoming packets, responding with the IP of the bridge. All then operates correctly, except that the host now has two IPs on the same subnet of course. Given that if_bridge(4) is described as a virtual switch [1] and Given that unicast packets originating on one of the bridge's taps are received by host programs bound to igb1, it seems to me that anything bound to igb1 should also be receiving the multicast packets. Is the discrepancy between handling of unicast and multicast packets * an error specifically related to multicast and bridging, or * an accident that unicast connections work? [unlikely] * (or none of the above) Kind regards and thanks in advance. [1] A bridge works like a switch, forwarding traffic from one interface to another. Multicast and broadcast packets are always forwarded to all interfaces that are part of the bridge. For unicast traffic, the bridge learns which MAC addresses are associated with which interfaces and will forward the traffic selectively. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243554] multicast packets not seen on PHY bridge member
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243554 --- Comment #1 from James Blachly --- (In reply to James Blachly from comment #0) I have to correct the below, I meant to type FreeBSD 12.1-RELEASE as my current version. The problem first manifest for me in version 11.2 and the text I pasted from an unanswered 2018 email to free-net ML. Sorry for any confusion. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243554] multicast packets not seen on PHY bridge member
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243554 Kyle Evans changed: What|Removed |Added CC||kev...@freebsd.org, ||k...@freebsd.org --- Comment #2 from Kyle Evans --- CC'ing kp, since he's done some work on bridge, too -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 243554] multicast packets not seen on PHY bridge member
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=243554 --- Comment #3 from Kyle Evans --- Created attachment 211002 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=211002&action=edit diff against releng/12.1 It looks similar to some of the other observability problems I've fixed in the past. While the conventional setup is that the bridge alone would get the IP and not igb1, I think being able to observe the packets in question on igb1 is still important for debugging purposes. There's also an incorrect looking comment in if_bridge.c that I'll dig into a little later; in bridge_forward(), we claim that tapping multicast/broadcast traffic isn't important because it will be reinjected into ether_input. I can't see how this is true. AFAICT these packets will travel bridge_broadcast() -> bridge_enqueue() -> if_transmit OR just bridge_enqueue() -> if_transmit, which will typically not involve ether_input. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
