[Bug 270904] Same Block Device over SATA and USB gpart(8) Broken
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270904 fgorter changed: What|Removed |Added CC||fgor...@gmail.com --- Comment #1 from fgorter --- Does this not require a USB Quirk? Seems the probe is more the issue, rather than enumerating the storage device. I will try and replicate this problem here locally. Any information of make/model of the mSATA device & the mSATA-to-USB enclosure? I have a Samsung mSATA SSD (850 EVO, IIRC) that needs to be backed-up & wiped. Will follow up if I discovery anything useful. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270904] Same Block Device over SATA and USB gpart(8) Broken
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270904 --- Comment #2 from Slawomir Wojciech Wojtczak --- Funny ... I used the same Samsung mSATA SSD 850 EVO (250GB) in that test :) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270903] Black screen and kernel crash after reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270903 fgorter changed: What|Removed |Added CC||fgor...@gmail.com --- Comment #1 from fgorter --- Are you using the 5700G APU's integrated GPU or specifically only the NVidia GPU? I had a very intermittent issue with my RTX 3060Ti & FreeBSD-13 Stable branch some weeks ago. I track the more recent NVidia-driver for multiple testing & noticed one or two of the more recent releases causing issues, where the GPU would disappear from the PCIe bus for whatever reason... And the fans suddenly spooling up along with black screen & no response from the machine. Curiously, none of these issues presented themselves while using the exact same machine with a GeForce 1030 GT installed. Go to https://www.nvidia.com/en-us/drivers/unix/freebsd-x64-archive/ and try one of the more recent 525.x driver releases. Ports/Packages is version 515.86.01. I can confirm 525.105.17, 525.105.01 & 530.41.03 work perfectly fine & without even a single problem/hiccup/crash. The 530.30.02 release is buggy as hell -- AVOID at all costs. 525.89.02 occasionally had some problem -- never quite figured out what exactly. 525.85.05 worked without issue. 525.78.01 worked without issue. Note: These drivers may require a more recent FreeBSD kernel release, thus a quick kernel recompile may be required. Hope this helps you. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270759] [modules] kldload ktls_ocf on FreeBSD/arm64 13.2: link_elf: symbol sysctl___kern_ipc_tls_stats undefined
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270759 --- Comment #2 from ru...@verweg.com --- Thanks, I was under the impression that with exception of certain hardware related differences both amd64/arm64 kernels would have the same options. I’ll compile a custom kernel for now and wait to see the option to be added in e.g. 13.3 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270909] find: /.zfs: Invalid argument
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270909 Bug ID: 270909 Summary: find: /.zfs: Invalid argument Product: Base System Version: 13.2-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: rx5...@gmail.com Hello. I up upgraded from 12.3 to 13.2 Now when I try to find on any zfs snapdir (.zfs) I get: find: /.zfs: Invalid argument [root@ven-t ~]# uname -a FreeBSD ven-t 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n254617-525ecfdad597 GENERIC amd64 [root@ven-t ~]# find /.zfs /.zfs /.zfs/snapshot find: /.zfs: Invalid argument -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270909] find: /.zfs: Invalid argument
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270909 Marek Zarychta changed: What|Removed |Added CC||zarych...@plan-b.pwste.edu. ||pl --- Comment #1 from Marek Zarychta --- I can't reproduce on 13.2-STABLE. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270759] [modules] kldload ktls_ocf on FreeBSD/arm64 13.2: link_elf: symbol sysctl___kern_ipc_tls_stats undefined
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270759 --- Comment #3 from Ed Maste --- > I was under the impression that with exception of certain hardware related > differences both amd64/arm64 kernels would have the same options. In general they should. I'll take a look at this one. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270909] find: /.zfs: Invalid argument
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270909 --- Comment #2 from rx5...@gmail.com --- Sorry I didn't mention that I use mirrored zpool I just fresh installed 13.2-RELEASE on mirrored zpool and: root@fbsd3:~ # zpool status pool: zroot state: ONLINE config: NAMESTATE READ WRITE CKSUM zroot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 da0p3 ONLINE 0 0 0 da1p3 ONLINE 0 0 0 errors: No known data errors root@fbsd3:~ # root@fbsd3:~ # root@fbsd3:~ # gpart show => 40 134217648 da0 GPT (64G) 40 10241 freebsd-boot (512K) 1064984 - free - (492K) 204841943042 freebsd-swap (2.0G) 4196352 1300193283 freebsd-zfs (62G) 134215680 2008 - free - (1.0M) => 40 134217648 da1 GPT (64G) 40 10241 freebsd-boot (512K) 1064984 - free - (492K) 204841943042 freebsd-swap (2.0G) 4196352 1300193283 freebsd-zfs (62G) 134215680 2008 - free - (1.0M) => 9 523725 cd0 MBR (1.0G) 9 523725 - free - (1.0G) => 9 523725 iso9660/13_2_RELEASE_AMD64_CD MBR (1.0G) 9 523725 - free - (1.0G) root@fbsd3:~ # root@fbsd3:~ # root@fbsd3:~ # find /.zfs /.zfs /.zfs/snapshot find: /.zfs: Invalid argument root@fbsd3:~ # -- You are receiving this mail because: You are the assignee for the bug.
[Bug 268005] rsync to FAT32 flash drive gets "Freeing unused sector" errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268005 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #2 from Ed Maste --- The error message you report was added for 13.1, after 13.0. It was previously a (compiled-out) assertion and changed into an error, so it is possible that the same problem occurred in 13.0, but silently. https://cgit.freebsd.org/src/commit/?id=472f5760644320e59abc2b5362e84635dc650daf -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270909] find: /.zfs: Invalid argument
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270909 --- Comment #3 from Marek Zarychta --- (In reply to rx5670 from comment #2) Indeed, the error "Invalid argument" appears at the end of the find(1) output. You can redirect stderr if it hurts you. Is it really a bug? I doubt it. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270909] find: /.zfs: Invalid argument
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270909 --- Comment #4 from rx5...@gmail.com --- (In reply to Marek Zarychta from comment #3) Actually these errors emailed from daily security checks from some scripts in /etc/periodic/security/ So I've never seen them before I updated from 12.3 to 13.2. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 268005] rsync to FAT32 flash drive gets "Freeing unused sector" errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268005 --- Comment #3 from w...@psr.com --- OK, reporting a problem is certainly better than ignoring it, and that explains why it appeared in 13.1, but that leaves the question of why it's happening at all and fixing that. As a user, what I see is that rsync to an msdosfs flash drive has appeared to work for years (FreeBSD 9 - 13.0), even repeatedly to the same drive, mixed with mounting it on a Windows machine and adding and deleting files there with no problems evident, so if there was corruption, it didn't cause any apparent problem. Yes, that's not proof. :) Now that the issue has been turned into an error, I get "remounting read-only due to corruption" when the error occurs and the rsync fails rather dramatically. If corruption really has been happening for years, maybe I've just been lucky. When this problem arose, I wrote a script that does "find -newer" and "cp -p" to the flash drive: that doesn't trigger this problem, even now. rsync to a freshly formatted drive (almost all writes) generally works, too. It's rsync when only some files out of many have changed that pretty consistently dies. I've only seen this with MSDOSFS flash drives. The same size and type of flash drive with UFS works fine. I have no data regarding non-flash MSDOSFS drives. While I've been using Win10 for repairs, I could try fsck(_msdosfs) if that would be more informative and helpful. -WBE -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270917] Panic on recent -CURRENT: Unread portion of the kernel message buffer: no proper vop_fplookup_vexec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270917 Bug ID: 270917 Summary: Panic on recent -CURRENT: Unread portion of the kernel message buffer: no proper vop_fplookup_vexec Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: g...@freebsd.org Created attachment 241568 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=241568&action=edit Core.txt from the kernel panic On a very recent -CURRENT as of April 18, 2023, I get a reproducible panic running the kyua test suite (as root). Unread portion of the kernel message buffer: no proper vop_fplookup_vexec 0xf8003b7bb700: type VFIFO state VSTATE_CONSTRUCTED op 0x81af9380 usecount 0, writecount 0, refcount 0 seqc users 0 fifoinfo 0 hold count flags () flags () lock type tmpfs: UNLOCKED tag VT_TMPFS, tmpfs_node 0xf8000bc95570, flags 0x0, links 1 mode 0644, owner 0, group 0, size 0, status 0x0 , NULL v_fifoinfo panic: no proper vop_fplookup_vexec cpuid = 0 time = 1681794059 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0096cab990 vpanic() at vpanic+0x152/frame 0xfe0096cab9e0 panic() at panic+0x43/frame 0xfe0096caba40 cache_vop_bad_vexec() at cache_vop_bad_vexec+0x24/frame 0xfe0096caba50 cache_fplookup() at cache_fplookup+0x524/frame 0xfe0096cabb40 namei() at namei+0x1eb/frame 0xfe0096cabbc0 kern_statat() at kern_statat+0x12f/frame 0xfe0096cabd00 sys_fstatat() at sys_fstatat+0x2f/frame 0xfe0096cabe00 amd64_syscall() at amd64_syscall+0x6dc/frame 0xfe0096cabf30 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0096cabf30 --- syscall (552, FreeBSD ELF64, fstatat), rip = 0xf124c7f7eea, rsp = 0xf124a173e28, rbp = 0xf124a173f40 --- The core.txt is attached to this PR, the dump is available on request. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 131341] makefs (ffs): error "Bad file descriptor" on the mount point of md-presentation makefs image
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=131341 Ed Maste changed: What|Removed |Added Summary|makefs: error "Bad file |makefs (ffs): error "Bad |descriptor" on the mount |file descriptor" on the |point of md-presentation|mount point of |makefs image|md-presentation makefs ||image --- Comment #8 from Ed Maste --- Patch URL is 404 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 196389] makefs(8): when populating METALOG with symlink information, no default user/group is populated
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196389 --- Comment #2 from Ed Maste --- (In reply to Graham Perrin from comment #1) > Is this still an issue? I have no reason to expect this has changed. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 221854] makefs: Reject UFS labels that are too long to fit
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221854 Ed Maste changed: What|Removed |Added See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2104 ||63 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 203937] makefs: Coverity CID 975347, 975348: No provisions for i/o error
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203937 Ed Maste changed: What|Removed |Added Status|New |Open -- You are receiving this mail because: You are the assignee for the bug.
[Bug 203938] makefs: Coverity CID 975345, 975346: No provisions for i/o error
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203938 Ed Maste changed: What|Removed |Added Status|New |Open -- You are receiving this mail because: You are the assignee for the bug.
[Bug 203940] makefs: Coverity CID 976847: Delayed error with wrong output file type
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203940 Ed Maste changed: What|Removed |Added Status|New |Open -- You are receiving this mail because: You are the assignee for the bug.
[Bug 240619] makefs (ffs): "ffs_alloccg: map corrupted" error on small filesystem
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240619 Ed Maste changed: What|Removed |Added Summary|makefs: "ffs_alloccg: map |makefs (ffs): "ffs_alloccg: |corrupted" error on small |map corrupted" error on |filesystem |small filesystem -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270884] Enable vCD OS Guest Customization Screen
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270884 Ed Maste changed: What|Removed |Added CC||ema...@freebsd.org --- Comment #1 from Ed Maste --- Can you find some VMware documentation on how to enable guest OS customization? (I.e., how a guest OS is intended to interact with the settings.) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270917] Panic on recent -CURRENT: Unread portion of the kernel message buffer: no proper vop_fplookup_vexec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270917 --- Comment #1 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5e954b9216ed94f66c74ef55622e0a8fe18d805a commit 5e954b9216ed94f66c74ef55622e0a8fe18d805a Author: Mateusz Guzik AuthorDate: 2023-04-18 18:04:16 + Commit: Mateusz Guzik CommitDate: 2023-04-18 18:06:30 + tmpfs: add missing vop_fplookup ops to tmpfs_fifoop_entries Reported by:gbe PR: 270917 sys/fs/tmpfs/tmpfs_fifoops.c | 2 ++ 1 file changed, 2 insertions(+) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270867] xargs -E is not working properly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270867 Ed Maste changed: What|Removed |Added Status|New |In Progress CC||ema...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270917] Panic on recent -CURRENT: Unread portion of the kernel message buffer: no proper vop_fplookup_vexec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270917 Mateusz Guzik changed: What|Removed |Added Resolution|--- |FIXED CC||m...@freebsd.org Assignee|b...@freebsd.org|m...@freebsd.org Status|New |Closed -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270824] [local_unbound] exceeded the maximum number of sends
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270824 Dag-Erling Smørgrav changed: What|Removed |Added Assignee|b...@freebsd.org|d...@freebsd.org Status|New |Open --- Comment #1 from Dag-Erling Smørgrav --- Can you try to create /var/unbound/conf.d/pr270824.conf with the following contents: server: do-udp: no This should improve matters if the problem is caused by packet loss. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270903] Black screen and kernel crash after reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270903 Daniel Toschläger changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed --- Comment #2 from Daniel Toschläger --- I made two different xorg.conf files with the help of xorg (xorg -configure than only changed the keyboard section). both behave like described, first was without the APU, second with both RTX in PCIE and the APU configured (together with the kernel modules and user in group video and wheel). Throughout today I came also to the conclusion it must be an nvidia driver specific problem. I helped myself so far by just "killall -9 Xorg" -ing my actual session from a terminal window which throws me als back into a working GDM interface. Thank you very much for your help. I will try your advice. Very good tipps! Kind greetings :) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270920] drill: "Error creating socket" with link-local IPv6 nameserver in /etc/resolv.conf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270920 Bug ID: 270920 Summary: drill: "Error creating socket" with link-local IPv6 nameserver in /etc/resolv.conf Product: Base System Version: 13.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: m...@svmhdvn.name `drill` isn't able to use a link-local IPv6 (e.g. specified as fe80::abcd%re0) nameserver specified in /etc/resolv.conf, but `ping` is able to resolve DNS just fine. in /etc/resolv.conf: nameserver fe80::abcd%re0 $ drill google.ca Error: error sending query: Error creating socket $ ping google.ca [...] 16 bytes from [...] # indicating success When switching the nameserver IP from a link-local to a global IPv6 on the same interface, `drill` works just fine. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270922] buildworld should detect noexec on /usr/obj
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270922 Bug ID: 270922 Summary: buildworld should detect noexec on /usr/obj Product: Base System Version: Unspecified Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: b...@freebsd.org Reporter: m...@fork.pl When /usr/obj is mounted with noexec/exec=off (clearly user's mistake) bootstrapped toolset is not used, build silently switches to basesystem toolset (which is possibly not compatible). This causes strange errors - in my case (building 12.4) it was: [Creating nested objdir /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvm/llvm/IR...] llvm-tblgen --gen-directive-impl -I /usr/src/contrib/llvm-project/llvm/include -d OMP.cpp.d -o OMP.cpp /usr/src/contrib/llvm-project/llvm/include/llvm/Frontend/OpenMP/OMP.td llvm-tblgen: Unknown command line argument '--gen-directive-impl'. Try: 'llvm-tblgen --help' llvm-tblgen: Did you mean '--gen-intrinsic-impl'? *** Error code 1 it's because old llvm-tblgen is used instead of /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/llvm-tblgen -rwxr-xr-x 1 root wheel 5330928 Apr 19 00:22 /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/llvm-tblgen # /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin/llvm-tblgen zsh: permission denied: /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/clang/llvm-tblgen -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270904] Same Block Device over SATA and USB gpart(8) Broken
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270904 --- Comment #3 from fgorter --- (In reply to Slawomir Wojciech Wojtczak from comment #2) I am unable to reproduce the same problem on my end. My mSATA device is in a simple mSATA-to-USB enclosure. Works as expected here, both with the USB enclosure attached at boot time & when connecting and mounting the same USB enclosure after login. Read/write works as expected & speed is nominal. Is there anything special about the USB adapter you are using? Maybe it requires some camcontrol cmd da0 magic number command? That "CDB: a0 00 00 00 00 00 00 00 00 10 00 00" return seems odd. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270903] Black screen and kernel crash after reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270903 --- Comment #3 from fgorter --- I tend to rely on x11/nvidia-xconfig to write a fully functional working /etc/X11/xorg.conf Might be helpful to you too. You can try building the nvidia-driver from ports with the ACPI_PM switched on/off perhaps. There might be a buggy ACPI state in the motherboard firmware. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 261005] hostname -d is not resolved domain information correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261005 Evan Marshall changed: What|Removed |Added CC||sampsonjohnniemeredith@gmai ||l.com --- Comment #4 from Evan Marshall --- Check the DNS server's Host (A) record availability with nslookup. To make sure that A resource records are present in DNS, read the provided link. https://geometrydashlite.co -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270928] Blacklistd does not handle SSHD failed logins
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270928 Bug ID: 270928 Summary: Blacklistd does not handle SSHD failed logins Product: Base System Version: 13.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: bc...@lafn.org Created attachment 241577 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=241577&action=edit A patch to blacklistd to have BL_BADUSER handled as BL_ADD Blacklistd with SSHD does not work properly. To create the problem, configure /etc/ssh/sshd.config to enable UseBlacklistd. Then start Blacklistd. Use ssh from another system to login with an invalid id and password. Try again. Blacklistd should have locked you out. Check with "blacklistctl dump -a" There will not be any entries. The problem is that sshd uses the type BL_BADUSER when calling blacklistd. The code in blacklistd.c says that this type is "ignore for now". The BL_BADUSER type was supposed to immediately block the IP on the first time regardless of the configuration in /etc/blacklistd.conf. However, at this time it never does anything. As a result the calling IP is never blocked. The simple solution is the attached patch. However, after some consideration, I believe that BL_BADUSER should always be handled as BL_ADD. The purpose of the configuration file is to give the system administrator control over when callers are blocked. By sshd using BL_BADUSER, the configuration in the config file is never used. That will certainly confuse the administrator and removes control over blocking from the administrator to the programmer who develops the code that calls blacklistd. Having sshd block the IP after the first invalid id or password is not a great idea. A simple fat fingered user will be blocked for 24 hours after the first login attempt. It is not uncommon for there to be typos in login attempts. That is a severe penalty for the user. There is no way for the administrator to remove the entry from blacklistd (presuming the user can actually contact the administrator). The administrator can only remove the IP address from the pf blocking table. That will "work" until something causes blacklistd to be restarted. On restart, blacklistd will reenable the block in pf. I believe that blacklistd should not override the administrator's configuration. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270909] find: /.zfs: Invalid argument
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270909 rx5...@gmail.com changed: What|Removed |Added Component|bin |kern -- You are receiving this mail because: You are the assignee for the bug.
[Bug 270929] Intel LAN card I219LM (23) error load when boot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270929 Bug ID: 270929 Summary: Intel LAN card I219LM (23) error load when boot Product: Base System Version: 13.1-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: david@durieux.family Hi, I had a new Dell laptop and the Intel LAN card I219_LM (23) not works. So I have got the kernel branch 'stable/13' and compiled the kernel on the laptop. When I boot, I have this lines of error: em0: mem 0x9df0-0x9df1 at device 31.6 on pci0 em0: Setup init failure em0: Setup of Shared code failed, error -5 em0: IFDI_ATTACH_PRE failed 6 device_attach: em0 attach returned 6 The information of my LAN card: none9@pci0:0:31:6: class=0x02 rev=0x01 hdr=0x00 vendor=0x8086 device=0x0dc5 subvendor=0x1028 subdevice=0x0c00 -- You are receiving this mail because: You are the assignee for the bug.
