[Bug 237461] Serveral references to emmintrin.h fails
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237461 --- Comment #6 from Dimitry Andric --- (In reply to Josh Paetzel from comment #5) > root@12:/usr/src # clang --version > FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM > 6.0.1) > Target: x86_64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > root@12:/usr/src # ls /usr/lib/clang/ > root@12:/usr/src # Right, but the actual question is: how did it get into this state? After a normal installation, this directory should exist, and it should have the clang internal headers under (in this case) a subdirectory 6.0.1. Is this when people install a system using WITHOUT_CLANG, and then copy a /usr/bin/clang executable by hand onto it, or something? -- 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 239417] ARP ping fails from the host to bridged vnet jails
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239417 Bug ID: 239417 Summary: ARP ping fails from the host to bridged vnet jails Product: Base System Version: 12.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: y...@freebsd.org I connect vnet jails to the host using netgraph bridge using this script /usr/src/share/examples/jails/jng: > jng bridge jailnet sk0 I assign the IP address to jailnet from the LAN network after jailnet is transferred into the jail. Connectivity with jail works in all directions, but arping from host to jail's IP address doesn't receive any response. arping from jail to hosts's IP and to all other IPs, including other jails' IPs work. Why arping doesn't receive responses from jail? ipfw.ko isn't loaded into kernel. -- 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 239393] connect(2) returns EACCESS in vnet jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239393 Yuri Victorovich changed: What|Removed |Added Resolution|--- |Works As Intended Status|New |Closed --- Comment #6 from Yuri Victorovich --- Forward to bug#239416 that asks to patch the man page. -- 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 239416] connect.2 manpage: EACCES error code can be returned when firewall doesn't allow connection to be made
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239416 Yuri Victorovich changed: What|Removed |Added URL||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2393 ||93 --- Comment #1 from Yuri Victorovich --- Add link to bug that has an explanation. -- 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 239416] connect.2 manpage: EACCES error code can be returned when firewall doesn't allow connection to be made
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239416 Bug ID: 239416 Summary: connect.2 manpage: EACCES error code can be returned when firewall doesn't allow connection to be made Product: Documentation Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Manual Pages Assignee: b...@freebsd.org Reporter: y...@freebsd.org CC: d...@freebsd.org Created attachment 206024 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=206024&action=edit patch -- 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 237461] Serveral references to emmintrin.h fails
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237461 --- Comment #5 from Josh Paetzel --- root@12:/usr/src # clang --version FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin root@12:/usr/src # ls /usr/lib/clang/ root@12:/usr/src # -- 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 237461] Serveral references to emmintrin.h fails
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237461 Josh Paetzel changed: What|Removed |Added CC||jpaet...@freebsd.org --- Comment #4 from Josh Paetzel --- I have a system in this state doing an update from stable/12 to HEAD if you want to chase this to ground. -- 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 224496] mpr and mps drivers seems to have issues with large seagate drives
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224496 Daniel Shafer changed: What|Removed |Added CC||dan...@shafer.cc --- Comment #10 from Daniel Shafer --- So I came across this same issue. It was causing my server to reboot several times a day due to kernel panics caused by this issue. It happens with both SAS9200 and 9300 controllers. I have 8 x 10TB Seagate Iron Wolf NAS drives. I wanted to mention that for me there was a resolution. I added an Intel Optane 900p 280GB drive and set that up for cache/l2arc and the problem entirely disappeared. My server ran for 20 days before I rebooted it last night to perform an upgrade. So, a workaround I believe would be is to add a cache drive to your ZFS pool. The Intel Optane 900p is a highly recommended cache drive for ZFS pools. -- 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 239393] connect(2) returns EACCESS in vnet jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239393 --- Comment #5 from Yuri Victorovich --- (In reply to Kristof Provost from comment #4) Thank you for clarifying this, Kristof. Now it is clear that this is expected behavior, and the man page should be updated: > [EACCES] Either an attempt is made to connect to a broadcast > address (obtained through the INADDR_BROADCAST > constant or the INADDR_NONE return value) through a > socket that does not provide broadcast functionality, > or firewall rules don't allow connection to be made. -- 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 239393] connect(2) returns EACCESS in vnet jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239393 --- Comment #4 from Kristof Provost --- You have firewall rules loaded on the host, which allows (some) traffic to pass through. In the vnet jail you do not have firewall rules set, but you still have IPFW loaded, so it block all traffic. (Which is IPFW's default, for arguably very good reasons). Set an allow-all rule in the vnet jail to continue. -- 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 239393] connect(2) returns EACCESS in vnet jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239393 --- Comment #3 from Yuri Victorovich --- (In reply to Kristof Provost from comment #2) ipfw kernel model is loaded, net.inet.ip.fw.default_to_accept=0, but networking works on the host. ipfw has default rules: > $ sudo ipfw list > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 00400 deny ip from any to ::1 > 00500 deny ip from ::1 to any > 00600 allow ipv6-icmp from :: to ff02::/16 > 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 > 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 > 00900 allow ipv6-icmp from any to any icmp6types 1 > 01000 allow ipv6-icmp from any to any icmp6types 2,135,136 > 65000 allow ip from any to any > 65535 deny ip from any to any Unloading the ipfw module removes "Permission denied" in the vnet jail. It becomes "Connection refused" on 127.0.0.1, as it should be. The host works the same with or without ipfw. Why does the presence of ipfw module cause "Permission denied" in the vnet jail, while the host functions the same? -- 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 239402] efifb ignored under 11.3 and later
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239402 --- Comment #3 from Mason Loring Bliss --- Additional notes: Not sure where this behaviour lies, but virt-manager has an option for opening the serial console which fails, and which precludes subsequent attempts to open the serial console via other methods. More notable and interesting, once the VM is completely installed, it retains this behaviour, ignoring the efifb and using the serial console, except that as noted previously, a functioning getty does spawn on the efifb. -- 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 239402] efifb ignored under 11.3 and later
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239402 --- Comment #2 from Mason Loring Bliss --- As a random additional note, it's conceivably specific to OVMF, as I've got EFI installs of 12 on two bare-metal systems here that didn't exhibit this behaviour. -- 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 239402] efifb ignored under 11.3 and later
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239402 Kyle Evans changed: What|Removed |Added CC||i...@freebsd.org, ||kev...@freebsd.org --- Comment #1 from Kyle Evans --- CC imp; I suspect this to be the result of console detection changes in efiland. -- 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 239402] efifb ignored under 11.3 and later
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239402 Bug ID: 239402 Summary: efifb ignored under 11.3 and later Product: Base System Version: 11.3-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: ma...@blisses.org Created attachment 206008 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=206008&action=edit Image of console exhibiting issue. I was installing a VM last night under QEMU/KVM with OVMF for purposes of looking at offline VM migration between this environment and Bhyve, and I thought at first that my VM had locked up. RhodiumToad from Freenode suggested that it hadn't locked up, but that it was using a console I wasn't looking at, and he nailed it - I was able to interact on the VM's serial console. I noted this behaviour on install disks from all of: 11.3-RELEASE, 12.0-RELEASE, 12-STABLE, and 13-CURRENT. Trying the 11.2-RELEASE install disk, the efifb is used by default. Something I noted was that 11.2-RELEASE shows the Beastie logo in colour, whereas the newer installers show it in black and white. Another slight oddity is that when I opted for a live session from the serial console, I noticed a functional getty showing up on the efifb, so it seems like the efifb works but simply isn't preferred under 11.3 and newer. While this behaviour is pretty easy to accomodate, it was surprising, and I didn't know to look at the serial console at first. I haven't tracked down just why it's happening, but I'd be happy to help explore this. I've attached an image of the efifb console at the point when the system starts using the serial console exclusively. -- 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 239245] r350074 will panic on ppc64 PowerMac G5 in vm_phys_enqueue_contig
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239245 --- Comment #58 from Dennis Clarke --- I managed to get an install of r350103 from that same DVD that crashed a few days ago. I simply went for a minimal install without ports or src tarball and the process went smoothly. hydra$ hydra$ uptime 12:41PM up 3 mins, 2 users, load averages: 0.09, 0.20, 0.10 hydra$ uname -apKU FreeBSD hydra 13.0-CURRENT FreeBSD 13.0-CURRENT r350103 GENERIC powerpc powerpc64 1300036 1300036 hydra$ The DVD needs usefdt=1 but after install the system boots fine without it and that makes as much sense as high altitude flying fish. Baffled but it is running for the moment. Dennis -- 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 239393] connect(2) returns EACCESS in vnet jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239393 Kristof Provost changed: What|Removed |Added CC||k...@freebsd.org --- Comment #2 from Kristof Provost --- Are you running ipfw on that machine by any chance? If it's loaded (and net.inet.ip.fw.default_to_accept is not set to 1) it'll actively reject all traffic, unless configured to do differently. That also applies in vnet jails. -- 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 239371] epair(4) doesn't expose network traffic to bpf(4), ex. wireshark doesn't see it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239371 Yuri Victorovich changed: What|Removed |Added Status|New |Closed Resolution|--- |Works As Intended --- Comment #11 from Yuri Victorovich --- Thank you, Kristof, for your explanation. -- 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 239371] epair(4) doesn't expose network traffic to bpf(4), ex. wireshark doesn't see it
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239371 --- Comment #10 from Kristof Provost --- (In reply to Yuri Victorovich from comment #9) lo0 is used for loopback traffic, and that includes connections from a public IP of your machine to a public IP from your machine. So, if your machine has re0, with 10.0.0.1/24 assigned to it, connecting to 10.0.0.1:1234 will pass over lo0, even though you might expect to see that traffic on re0. The same thing applies when that connection is made from a (non-vnet) jail to the host machine. It still applies if you have IP addresses in different nets. Anything to yourself will pass over lo0. If you connect to a different (i.e. non-local) IP, you will see the traffic on re0. That's all expected behaviour. -- 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 239393] connect(2) returns EACCESS in vnet jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239393 --- Comment #1 from Yuri Victorovich --- Connections to 127.0.0.1 via lo0 also fail with "Permission denied". The jail is created with: > jail_setv(JAIL_CREATE, > "path", jailPath.c_str(), > "host.hostname", "my-hostname", > "persist", nullptr, > "allow.raw_sockets", "true", > "allow.socket_af", "true", > "vnet", nullptr, > nullptr); -- 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"
