[Bug 204622] [zfs] [patch] Improve 'zpool labelclear' command
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204622 Bug ID: 204622 Summary: [zfs] [patch] Improve 'zpool labelclear' command Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: ganael.laplan...@corp.ovh.com Keywords: patch Created attachment 163238 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163238&action=edit Patch for 10.2 Hi, Here is a proposal to improve the "zpool labelclear" command. Currently, this command blindly overwrites both the 2 first and last labels of a disk (i.e. 2 x 256 kB at the beginning and end of a disk). This can lead to tricky situations where labels are still seen while another filesystem has taken place over the original zpool. In such a case, still being able to import the zpool can lead to destroying the filesystem that has been created over the pool. Here is a simple example : # zpool create test ada1 [... work ...] # zpool export test then, one decides to re-format the drive (without clearing the labels, damn!) : # newfs /dev/ada1 # mount /dev/ada1 /mnt # touch /mnt/foo # umount /mnt Unfortunately, ZFS labels are still there as newfs did not overwrite them : # zpool import pool: test id: 17834878187816880903 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: testONLINE ada1 ONLINE If we import/export the pool, labels a re-written and the UFS filesystem is broken : # zpool import test # zpool export test # mount /dev/ada1 /mnt mount: /dev/ada1: Invalid argument To minimize the risks of overwriting important data, I have looked for a way to invalidate a label by writing the *minimal* amount of data. I have found a simple way to invalidate a whole label by just modifying 1 byte: setting an invalid encoding for its nvlist is enough to make it considered as broken and ignored. The attached patch adds a -m (minimal) option to the 'labelclear' command that exploits this hack. With this option, we are now able to clear labels (to avoid a future import/export) without breaking a UFS filesystem : (after having unmounted UFS mountpoint /mnt) # zpool labelclear -m -f /dev/ada1 # zpool import # mount /dev/ada1 /mnt # ls /mnt .snap foo Of course, if the 4 bytes (4 * 1 byte) which are overwritten here are important for the new filesystem, it will be broken too. Anyway, erasing 4 bytes will always be less risky than erasing 4 * 256 kB! There are other situations where one would like to clear beginning or ending labels only ; the patch adds two options for that purpose : -b (beginning) and -e (ending). It also adds the ability to invalidate a single label using the -i (index) option. Here is an example with a msdosfs filesystem : # zpool create test ada1 # zpool export test # newfs_msdos /dev/ada1 # mount -t msdosfs -o large /dev/ada1 /mnt # touch /mnt/foo # umount /mnt # zdb -l /dev/ada1 LABEL 0 failed to unpack label 0 LABEL 1 failed to unpack label 1 LABEL 2 version: 5000 name: 'test' [...] LABEL 3 version: 5000 name: 'test' [...] Ending labels remain valid : # zpool import pool: test id: 693883832785598877 state: ONLINE action: The pool can be imported using its name or numeric identifier. config: testONLINE ada1 ONLINE If we import that filesystem, we will be breaking our msdosfs. To invalidate those two ending labels (only) without breaking our filesystem, we can safely perform the following : # zpool labelclear -e -m -f /dev/ada1 # zpool import # mount -t msdosfs -o large /dev/ada1 /mnt # ls /mnt foo Finally, the original command did a blind invalidation, without even trying to check that there is a valid label to erase. I have added a '-c' (check) option that tries to validate a label before doing anything on the disk. It will exit if no label is detected, avoiding to erase important data. This feature will try to unpack the pool configuration (nvlist) to see if it is valid or not ; this should be enough in most cases : # zpool create test ada1 # zpool export test # zpool labelclear -c -f /dev/ada1 # zpool labelclear -c -f /dev/ada1 Label clear failed on vdev /dev/ada1 Here, the second call did nothing as the label has already been invalidated. Find attached two patches: one for 10.2 and another one for -CURRENT (r290928). It keeps full co
[Bug 204622] [zfs] [patch] Improve 'zpool labelclear' command
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204622 --- Comment #1 from Ganael LAPLANCHE --- Created attachment 163239 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163239&action=edit Patch for -CURRENT -- 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 204622] [zfs] [patch] Improve 'zpool labelclear' command
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204622 Ganael LAPLANCHE changed: What|Removed |Added Keywords||feature Assignee|freebsd-bugs@FreeBSD.org|freebsd...@freebsd.org CC||marty...@freebsd.org -- 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 204626] 'zpool get' command help output.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204626 Bug ID: 204626 Summary: 'zpool get' command help output. Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: 21474...@gmail.com Hi, running the command $ zpool get missing property argument usage: get [-Hp] [-o "all" | field[,...]] <"all" | property[,...]> ... the following properties are supported: PROPERTY EDIT VALUES allocated NO capacity NO dedupratio NO <1.00x or higher if deduped> expandsize NO fragmentation NO free NO freeingNO guid NO health NO leaked NO size NO altroot YES autoexpandYES on | off autoreplace YES on | off bootfsYES cachefile YES| none comment YES dedupdittoYES delegationYES on | off failmode YES wait | continue | panic listsnapshots YES on | off readonly YES on | off version YES feature@... YES disabled | enabled | active The feature@ properties must be appended with a feature name. See zpool-features(7). I notice that: - the property "capacity" is a and not a - the property "name" is missing. -- Regards, Maurizio -- 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 204626] 'zpool get' command help output has two small errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204626 Kurt Jaeger changed: What|Removed |Added Summary|'zpool get' command help|'zpool get' command help |output. |output has two small errors -- 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 204628] ZFS dies when another dataset appears with same mountpoint as existing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204628 Bug ID: 204628 Summary: ZFS dies when another dataset appears with same mountpoint as existing Product: Base System Version: 10.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: vlad-f...@acheronmedia.com Importing a pool with mountpoints already existing for another, mounted dataset, or doing send | receive of existing mounted datasets to, say, external media, will cause ZFS to break instead of refusing to mount to existing mountpoints. What happens is that running any ZFS command fails with "internal error: failed to initialize ZFS library". In case of sending a backup of zroot (root dataset) snapshot to external media, if the external media is then unplugged, the system freezes. I have used -u on zfs receive but I apparently misunderstood the flag and will file another PR about the manpage flag description ambiguity. Is it "is not mounted" or "will not be mounted" (as I was lead to believe following an article on zfs send,recv backups)? I suspect this is also a gaping security hole if you import unknown pools and forget to -N. -- 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 204628] ZFS dies when another dataset appears with same mountpoint as existing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204628 Allan Jude changed: What|Removed |Added Resolution|--- |Not A Bug Status|New |Closed CC||allanj...@freebsd.org --- Comment #1 from Allan Jude --- This has not broken ZFS, what has happened is you have mounted a new / over top of the old one, and hidden /dev, so the zfs commands cannot find the /dev/zfs device they need to be able to talk to the kernel mount -t devfs devfs /dev and you should be able to go about fixing things. -- 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 204633] If INVARIANTS is enabled, free() may attempt to acquire sleeping lock
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204633 Bug ID: 204633 Summary: If INVARIANTS is enabled, free() may attempt to acquire sleeping lock Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: j...@freebsd.org While testing new code with WITNESS enabled, I saw this panic: panic: acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) 64 Bucket @ /usr/src/sys/vm/uma_dbg.c:217 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe21c690 vpanic() at vpanic+0x182/frame 0xfe21c710 kassert_panic() at kassert_panic+0x126/frame 0xfe21c780 witness_checkorder() at witness_checkorder+0x13b/frame 0xfe21c800 __mtx_lock_flags() at __mtx_lock_flags+0xa4/frame 0xfe21c850 uma_dbg_getslab() at uma_dbg_getslab+0x42/frame 0xfe21c880 uma_dbg_alloc() at uma_dbg_alloc+0x36/frame 0xfe21c8b0 uma_zalloc_arg() at uma_zalloc_arg+0x53e/frame 0xfe21c910 bucket_alloc() at bucket_alloc+0xa6/frame 0xfe21c930 uma_zfree_arg() at uma_zfree_arg+0x293/frame 0xfe21c980 free() at free+0x8b/frame 0xfe21c9c0 pmc_hook_handler() at pmc_hook_handler+0xbbb/frame 0xfe21ca50 thread_exit() at thread_exit+0x1b7/frame 0xfe21ca90 kern_thr_exit() at kern_thr_exit+0x119/frame 0xfe21cac0 sys_thr_exit() at sys_thr_exit+0x62/frame 0xfe21cae0 amd64_syscall() at amd64_syscall+0x2de/frame 0xfe21cbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe21cbf0 --- syscall (431, FreeBSD ELF64, sys_thr_exit), rip = 0x40b70a, rsp = 0x7fffde9f2ee8, rbp = 0x7fffde9f2f00 --- KDB: enter: panic The free() man page promises that free() will not sleep. However, if INVARIANTS is enabled, free() may very well attempt to acquire a sleeping lock. In fact, it appears that malloc() may even attempt to acquire a sleeping lock if INVARIANTS is enabled. The problem is that uma_zalloc_arg() calls uma_dbg_alloc(). uma_dbg_alloc() calls uma_dbg_getslab(). uma_dbg_getslab() may acquire the zone lock, which is a normal (sleepable) mutex. -- 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 204633] If INVARIANTS is enabled, free() may attempt to acquire sleeping lock
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204633 Mark Johnston changed: What|Removed |Added CC||ma...@freebsd.org --- Comment #1 from Mark Johnston --- I think this indicates a bug in the caller rather than UMA. The nomenclature is a bit confusing: a sleep mutex is just a "default" mutex, i.e. a non-spin mutex. When a thread blocks on a sleep mutex, it enters bounded sleep; "sleep" in the free(9) man page refers to unbounded sleep. The assertion is failing because the thread holds a spin mutex or a critical section, in which case it is not valid to try and acquire a sleep mutex. It could probably be triggered in a non-INVARIANTS kernel too, since uma_zfree_arg() will attempt to acquire the corresponding zone lock, which is also a sleep mutex. -- 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 204633] If INVARIANTS is enabled, free() may attempt to acquire sleeping lock
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204633 --- Comment #2 from Jonathan T. Looney --- (In reply to Mark Johnston from comment #1) > The assertion is failing because the thread holds a spin mutex or a critical > section, > in which case it is not valid to try and acquire a sleep mutex. It could > probably be > triggered in a non-INVARIANTS kernel too, since uma_zfree_arg() will attempt > to > acquire the corresponding zone lock, which is also a sleep mutex. Good point. That makes this very much look like intended behavior. I only saw this when I tried testing my changes with an unusually high load. Presumably, that caused the allocator to need to acquire the zone lock when it would normally not need to do so. I wonder how many other things have slipped through without enough testing to actually trigger the assert? Perhaps, I should propose a man page change to make this more clear. And/or add a check in malloc/free to catch these problems more reliably. -- 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 204633] If INVARIANTS is enabled, free() may attempt to acquire sleeping lock
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204633 --- Comment #3 from Mark Johnston --- (In reply to Jonathan T. Looney from comment #2) I think it would be correct and reasonable to assert that curthread->td_critnest == 0 at the beginning of uma_zalloc_arg() and uma_zfree_arg(). In most cases, UMA can satisfy allocation and free requests without acquiring a lock, so the checking currently done by witness is not consistent. -- 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 204637] Chnage to makefiles maybe in (r290928) breaks installworld
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204637 Bug ID: 204637 Summary: Chnage to makefiles maybe in (r290928) breaks installworld Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: misc Assignee: freebsd-bugs@FreeBSD.org Reporter: edwin.br...@gmail.com Chnage to makefiles maybe in (r290928) breaks installworld ===> share/ctypedef (install) install -o root -g wheel -m 444 be_BY.CP1131.LC_CTYPE /usr/share/locale/be_BY.CP1131/LC_CTYPE install -o root -g wheel -m 444 ca_IT.ISO8859-1.LC_CTYPE /usr/share/locale/ca_IT.ISO8859-1/LC_CTYPE install -o root -g wheel -m 444 ca_IT.ISO8859-15.LC_CTYPE /usr/share/locale/ca_IT.ISO8859-15/LC_CTYPE install -o root -g wheel -m 444 el_GR.ISO8859-7.LC_CTYPE /usr/share/locale/el_GR.ISO8859-7/LC_CTYPE install -o root -g wheel -m 444 en_US.ISO8859-1.LC_CTYPE /usr/share/locale/en_US.ISO8859-1/LC_CTYPE install -o root -g wheel -m 444 en_US.ISO8859-15.LC_CTYPE /usr/share/locale/en_US.ISO8859-15/LC_CTYPE install: /usr/share/locale/en_US.ISO8859-15/LC_CTYPE: No such file or directory *** Error code 71 Stop. make[5]: stopped in /usr/src/share/ctypedef *** Error code 1 Stop. make[4]: stopped in /usr/src/share *** Error code 1 Stop. make[3]: stopped in /usr/src *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src # ^D Script done on Sun Nov 15 19:38:43 2015 -- 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 204637] Chnage to makefiles maybe in (r290928) breaks installworld
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204637 Ed changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED --- Comment #1 from Ed --- I failed to find the note in UPDATING :( -- 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 195901] Addition of a well-commented default /etc/src.conf file
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195901 George changed: What|Removed |Added Resolution|--- |FIXED Status|New |Closed --- Comment #3 from George --- I concur with your comments ngie. Originally, this was meant for Tim Kientzle's crochet, but it was recommended to be a PR here. Despite my apprehensions, I submitted here... I agree it could/should be automatically generated, but I think it's much more relevant for particular platforms and use-cases, such as embedded or SoC systems like RPis. -- 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 195925] freebsd-update(8) needed manual creation of paths to install
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195925 George changed: What|Removed |Added Status|New |Closed Resolution|--- |Overcome By Events --- Comment #1 from George --- dated and pointless now. -- 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 204641] 10.2 UNMAP/TRIM not available on a zfs zpool that uses iSCSI disks, backed on a zpool file target
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204641
Bug ID: 204641
Summary: 10.2 UNMAP/TRIM not available on a zfs zpool that uses
iSCSI disks, backed on a zpool file target
Product: Base System
Version: 10.2-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: misc
Assignee: freebsd-bugs@FreeBSD.org
Reporter: ch...@acsi.ca
Consider this scenario:
Virtual FreeBSD Machine, with a zpool created out of iSCSI disks.
Physical FreeBSD Machine, with a zpool holding a sparse file that is the target
for the iSCSI disk.
This setup works in an environment with all 10.1 machines, doesn't with all
10.2 machines.
- The 10.2 Machines are 10.2-p7 RELEASE, updated via freebsd-update, no custom.
- The 10.1 Machine are 10.1-p24 RELEASE, updated via freebsd-update, no custom.
- iSCSI is all CAM iSCSI, not the old istgt platform.
- The iSCSI Target is a sparse file, stored on a zpool (not a vdev Target)
The target machine is the same physical machine, with the same zpools - I
either boot 10.1 or 10.2 for testing, and use the same zpool/disks to ensure
nothing is changing.
If I have a 10.2 iSCSI Initiator (client) connected to a 10.2 iSCSI Target,
TRIM doesn't work (shows as NONE below).
If I have a 10.2 iSCSI Initiator (client) connected to a 10.1 iSCSI Target,
TRIM does work.
(There is another bug with that last scenario as well, but I will open it
separately)
...for clarity, a 10.1 iSCSI Initiator connected to a 10.1 iSCSI Target also
works perfectly. I have ~20 of these in the field.
On the 10.1 / 10.2 Targets, the ctl.conf file is identical. Zpools are
identical, because they are shared between reboots of the same iSCSI target
machine.
On the 10.2 initiator machine, connected to a 10.2 Target machine:
# sysctl -a | grep cam.da
kern.cam.da.2.minimum_cmd_size: 6
kern.cam.da.2.delete_max: 131072
kern.cam.da.2.delete_method: NONE
kern.cam.da.1.error_inject: 0
kern.cam.da.1.sort_io_queue: 0
kern.cam.da.1.minimum_cmd_size: 6
kern.cam.da.1.delete_max: 131072
kern.cam.da.1.delete_method: NONE
kern.cam.da.0.error_inject: 0
kern.cam.da.0.sort_io_queue: -1
kern.cam.da.0.minimum_cmd_size: 6
kern.cam.da.0.delete_max: 131072
kern.cam.da.0.delete_method: NONE
Note the delete_method is NONE
# sysctl -a | grep trim
vfs.zfs.trim.max_interval: 1
vfs.zfs.trim.timeout: 30
vfs.zfs.trim.txg_delay: 32
vfs.zfs.trim.enabled: 1
vfs.zfs.vdev.trim_max_pending: 1
vfs.zfs.vdev.trim_max_active: 64
vfs.zfs.vdev.trim_min_active: 1
vfs.zfs.vdev.trim_on_init: 1
kstat.zfs.misc.zio_trim.failed: 0
kstat.zfs.misc.zio_trim.unsupported: 181
kstat.zfs.misc.zio_trim.success: 0
kstat.zfs.misc.zio_trim.bytes: 0
Note no trimmed bytes.
On the target machine, 10.1 and 10.2 share the same config file: /etc/ctl.conf
portal-group pg0 {
discovery-auth-group no-authentication
listen 0.0.0.0
listen [::]
}
lun 0 {
path /pool92/iscsi/iscsi.zvol
blocksize 4K
size 5T
option unmap "on"
option scsiname "pool92"
option vendor "pool92"
option insecure_tpc "on"
}
}
target iqn.iscsi1.zvol {
auth-group no-authentication
portal-group pg0
lun 0 {
path /pool92_1/iscsi/iscsi.zvol
blocksize 4K
size 5T
option unmap "on"
option scsiname "pool92_1"
option vendor "pool92_1"
option insecure_tpc "on"
}
}
When I boot a 10.1 Target server, the 10.2 initiator connects, and we do see
proper UNMAP ability:
kern.cam.da.2.minimum_cmd_size: 6
kern.cam.da.2.delete_max: 5497558138880
kern.cam.da.2.delete_method: UNMAP
kern.cam.da.1.error_inject: 0
kern.cam.da.1.sort_io_queue: 0
kern.cam.da.1.minimum_cmd_size: 6
kern.cam.da.1.delete_max: 5497558138880
kern.cam.da.1.delete_method: UNMAP
kern.cam.da.0.error_inject: 0
kern.cam.da.0.sort_io_queue: -1
kern.cam.da.0.minimum_cmd_size: 6
kern.cam.da.0.delete_max: 131072
kern.cam.da.0.delete_method: NONE
Please let me know what you'd like to know next.
Thanks.
--
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 204640] make installworld fails installing libc_p.a to /usr/lib
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204640 --- Comment #1 from Thomas Schweikle --- I've checked out the complete tree new to make sure nothing old and deprecated left over from previous compiles interrupting or clashing the build process. -- 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 204640] make installworld fails installing libc_p.a to /usr/lib
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204640 Thomas Schweikle changed: What|Removed |Added CC||t...@vr-web.de --- Comment #2 from Thomas Schweikle --- FreeBSD fbsd12-64.bfs.de 11.0-CURRENT FreeBSD 11.0-CURRENT #6 r290979: Tue Nov 17 20:08:13 CET 2015 r...@fbsd12-64.bfs.de:/usr/obj/usr/src/sys/FBSD11 amd64 -- 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 204640] make installworld fails installing libc_p.a to /usr/lib
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204640 Bug ID: 204640 Summary: make installworld fails installing libc_p.a to /usr/lib Product: Base System Version: 11.0-CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: t...@vr-web.de -- >>> Installing everything -- cd /usr/src; make -f Makefile.inc1 install ===> lib (install) ===> lib/csu (install) ===> lib/csu/amd64 (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o Scrt1.o gcrt1.o /usr/lib/ ===> lib/libc (install) install -C -o root -g wheel -m 444 libc.a /usr/lib/ install -C -o root -g wheel -m 444 libc_p.a /usr/lib/ install: libc_p.a: No such file or directory *** Error code 71 Stop. make[5]: stopped in /usr/src/lib/libc *** Error code 1 Stop. make[4]: stopped in /usr/src/lib *** Error code 1 Stop. make[3]: stopped in /usr/src *** Error code 1 Stop. make[2]: stopped in /usr/src *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src The file isn't there and seems to never have been compiled ...! At least I could not find anything referencing to libc_p.a within the logs. -- 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 204340] [panic] nfsd, em, msix, fatal trap 9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204340 --- Comment #5 from g_amana...@yahoo.com --- (In reply to Rick Macklem from comment #4) I am testing it, so far it seems ok. Give me a couple of days to test it thoroughly. -- You are receiving this mail because: You are on the CC list 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 204642] 10.2 iSCSI connected initiator to a 10.1 iSCSI Target generates excessive UNMAP/TRIM commands, system unresponsive.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204642
Bug ID: 204642
Summary: 10.2 iSCSI connected initiator to a 10.1 iSCSI Target
generates excessive UNMAP/TRIM commands, system
unresponsive.
Product: Base System
Version: 10.2-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: misc
Assignee: freebsd-bugs@FreeBSD.org
Reporter: ch...@acsi.ca
A FreeBSD 10.2-p7 RELEASE machine connected via CAM iSCSI Initiator to a
10.1p24 RELEASE iSCSI file-based target, on a zpool generates a crazy amount of
TRIM commands, locking the system.
This is a gstat -d on the 10.2 Initiator, once the zpools are mounted, and just
a basic bit of activity is started (simple file write, etc - no real load)
dT: 12.546s w: 1.000s
L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps ms/d
%busy Name
0 3 0 00.0 3 46 58.3 0 00.0
4.2| da0
0 0 0 00.0 0 00.0 0 00.0
0.0| da0p1
0 0 0 00.0 0 00.0 0 00.0
0.0| da0p2
0 3 0 00.0 3 46 58.3 0 00.0
4.2| da0p3
0 333485 0 00.0 0 00.0 333485 00.0
48.0| da1
0 306605 0 00.0 0 00.0 306605 00.0
47.7| da2
Notice the huge number of deletes per second.
The iSCSI Target doesn't seem to be doing anything, so I suspect these are
internally dying/retrying. They don't seem to show up in the sysctl:
# sysctl -a | grep trim
vfs.zfs.trim.max_interval: 1
vfs.zfs.trim.timeout: 30
vfs.zfs.trim.txg_delay: 32
vfs.zfs.trim.enabled: 1
vfs.zfs.vdev.trim_max_pending: 1
vfs.zfs.vdev.trim_max_active: 64
vfs.zfs.vdev.trim_min_active: 1
vfs.zfs.vdev.trim_on_init: 1
kstat.zfs.misc.zio_trim.failed: 0
kstat.zfs.misc.zio_trim.unsupported: 110
kstat.zfs.misc.zio_trim.success: 11
kstat.zfs.misc.zio_trim.bytes: 118784
I do notice that the delete_method is now switched to 'DISABLE'. It originally
was 'UNMAP' after boot, and before the zpools had activity.
# sysctl -a | grep cam.da
kern.cam.da.2.minimum_cmd_size: 6
kern.cam.da.2.delete_max: 0
kern.cam.da.2.delete_method: DISABLE
kern.cam.da.1.error_inject: 0
kern.cam.da.1.sort_io_queue: 0
kern.cam.da.1.minimum_cmd_size: 6
kern.cam.da.1.delete_max: 0
kern.cam.da.1.delete_method: DISABLE
kern.cam.da.0.error_inject: 0
kern.cam.da.0.sort_io_queue: -1
kern.cam.da.0.minimum_cmd_size: 6
kern.cam.da.0.delete_max: 131072
kern.cam.da.0.delete_method: NONE
For reference, here is the /etc/ctl.conf on the 10.1 iSCSI Target:
portal-group pg0 {
discovery-auth-group no-authentication
listen 0.0.0.0
listen [::]
}
lun 0 {
path /pool92/iscsi/iscsi.zvol
blocksize 4K
size 5T
option unmap "on"
option scsiname "pool92"
option vendor "pool92"
option insecure_tpc "on"
}
}
target iqn.iscsi1.zvol {
auth-group no-authentication
portal-group pg0
lun 0 {
path /pool92_1/iscsi/iscsi.zvol
blocksize 4K
size 5T
option unmap "on"
option scsiname "pool92_1"
option vendor "pool92_1"
option insecure_tpc "on"
}
}
Thanks.
--
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 204643] [msdosfs] [panic] Crash while accessing files with large, non-english names
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204643 Bug ID: 204643 Summary: [msdosfs] [panic] Crash while accessing files with large, non-english names Product: Base System Version: 9.3-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: gordon...@mail.ru Created attachment 163261 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163261&action=edit Kernel config file How-to-repeat: 1. Create file with large name, non-english (130 symbols enough) on msdos fat disk. This must be done under ms windows (FreeBSD does not allow shot in your leg and create file with name > 127 non-english symbols on fat fs). Under the windows long non-english filenames (127+ symbols) is correct and can be easily and accessed. 2. Mount disk on FreeBSD system like "mount_msdosfs -o longnames -D cp1251 -L ru_RU.UTF-8 /dev/daX /mnt" (or use the your language settings in -D and -L) 3. Try "ls /mnt/directory-with-large-name" You get "panic: stack overflow detected; backtrace may be corrupted" I guess this is the same bug #141897 And, i guess this happening because locale uses multibyte encoding (UTF-8). But utf-8 the only way and this is the future. Unfortunately fat file systems are widespread, and i from time to time encounter with this. Kernel config in attachment. Trace: #0 doadump (textdump=) at pcpu.h:235 #1 0x805e1b6f in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:454 #2 0x805e1fb7 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:642 #3 0x8060acc2 in __stack_chk_fail () at /usr/src/sys/kern/stack_protector.c:17 #4 0x804f3982 in msdosfs_readdir (ap=0xff81a3edfaa0) at /usr/src/sys/fs/msdosfs/msdosfs_vnops.c:1817 #5 0x80894c10 in VOP_READDIR_APV (vop=, a=) at vnode_if.c:1793 #6 0x80686ec7 in kern_getdirentries (td=0xfe001724d000, fd=, buf=0x8010ab000 , count=, basep=0xff81a3edfb10) at vnode_if.h:758 #7 0x80686c1b in sys_getdirentries (td=0x0, uap=0xff81a3edfbc0) at /usr/src/sys/kern/vfs_syscalls.c:4145 #8 0x808401b9 in amd64_syscall (td=0xfe001724d000, traced=0) at subr_syscall.c:135 #9 0x8082978b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #10 0x000800d032ec in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal uname: FreeBSD HP635 9.3-RELEASE FreeBSD 9.3-RELEASE #5: Tue Nov 17 20:24:39 MSK 2015 Freeman@thanatos:/usr/obj/usr/src/sys/E300 amd64 dmesg: Copyright (c) 1992-2014 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 9.3-RELEASE #5: Tue Nov 17 20:24:39 MSK 2015 Freeman@thanatos:/usr/obj/usr/src/sys/E300 amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 info: [drm] Initialized drm 1.1.0 20060810 CPU: AMD E-300 APU with Radeon(tm) HD Graphics (1297.26-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x500f20 Family = 0x14 Model = 0x2 Stepping = 0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff TSC: P-state invariant, performance statistics real memory = 6442450944 (6144 MB) avail memory = 5767602176 (5500 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 hpet0: iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 450 atrtc0: port 0x70-0x71 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x4000-0x40ff mem 0xe000-0xefff,0xf040-0xf043 irq 18 at device 1.0 on pci0 acpi_video0: on vgapci0 drmn0: on vgapci0 info: [drm] MSI enabled 1 message(s) info: [drm] RADEON_IS_PCIE info: [drm] initializing kernel modesetting (PALM 0x1002:0x9802 0x103C:0x3577). info: [drm] register mmio base: 0xF040 info: [drm] register mmio size: 262144 info: [drm] ra
[Bug 204646] 10.2 iSCSI backed zpool shows imporper warnings about non-native block sizes that 10.1 doesn't show
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204646
Bug ID: 204646
Summary: 10.2 iSCSI backed zpool shows imporper warnings about
non-native block sizes that 10.1 doesn't show
Product: Base System
Version: 10.2-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: misc
Assignee: freebsd-bugs@FreeBSD.org
Reporter: ch...@acsi.ca
This is similar to Bug 197513, but that is a 9.3 system.
Consider this scenario:
Virtual FreeBSD Machine Initiator, with a zpool created out of iSCSI disks.
Physical FreeBSD Machine Target, with a zpool holding a sparse file that is the
target for the iSCSI disk.
- The 10.2 Machines are 10.2-p7 RELEASE, updated via freebsd-update, no custom.
- The 10.1 Machine are 10.1-p24 RELEASE, updated via freebsd-update, no custom.
- iSCSI is all CAM iSCSI, not the old istgt platform.
- The iSCSI Target is a sparse file, stored on a zpool (not a vdev Target)
The target machine is the same physical machine, with the same zpools - I
either boot 10.1 or 10.2 for testing, and use the same zpool/disks
to ensure nothing is changing.
If I have a 10.2 iSCSI Initiator (client) connected to a 10.2 iSCSI Target, I
get eroneous warnings.
If I have a 10.1 iSCSI Initiator (client) connected to a 10.1 iSCSI Target, I
don't get the warnings.
On the iSCSI Target, the file that backs the iSCSI disk is stored in a zpool
that has a recordsize=64k set.
It's something in the CAM iSCSI Target code that is reporting the zfs
recordsize as the sector size.
If you use a 10.1 iSCSI Initiator connected to a 10.2 iSCSI Target, or 10.1
iSCSI Target, this is what you see on the Initiator:
#zpool status
pool: iscsi-nfs
state: ONLINE
scan: scrub repaired 0 in 0h0m with 0 errors on Tue Nov 17 15:25:51 2015
config:
NAME STATE READ WRITE CKSUM
iscsi-nfs ONLINE 0 0 0
diskid/DISK-MYSERIAL%20%20%201 ONLINE 0 0 0
errors: No known data errors
pool: iscsi-nfs1
state: ONLINE
scan: scrub repaired 0 in 0h0m with 0 errors on Tue Nov 17 15:25:51 2015
config:
NAME STATE READ WRITE CKSUM
iscsi-nfs1ONLINE 0 0 0
diskid/DISK-MYSERIAL%20%20%200 ONLINE 0 0 0
errors: No known data errors
With a 10.2 iSCSI Initiator connected to a 10.2 iSCSI Target, this is what I
see on zpool status:
# zpool status
pool: iscsi-nfs
state: ONLINE
status: One or more devices are configured to use a non-native block size.
Expect reduced performance.
action: Replace affected devices with devices that support the
configured block size, or migrate data to a properly configured
pool.
scan: scrub repaired 0 in 0h0m with 0 errors on Tue Nov 17 15:25:51 2015
config:
NAME STATE READ WRITE CKSUM
iscsi-nfs ONLINE 0 0 0
diskid/DISK-MYSERIAL%20%20%200 ONLINE 0 0 0 block
size: 4096B configured, 65536B native
errors: No known data errors
pool: iscsi-nfs1
state: ONLINE
status: One or more devices are configured to use a non-native block size.
Expect reduced performance.
action: Replace affected devices with devices that support the
configured block size, or migrate data to a properly configured
pool.
scan: scrub repaired 0 in 0h0m with 0 errors on Tue Nov 17 15:25:51 2015
config:
NAME STATE READ WRITE CKSUM
iscsi-nfs1ONLINE 0 0 0
diskid/DISK-MYSERIAL%20%20%201 ONLINE 0 0 0 block
size: 4096B configured, 65536B native
errors: No known data errors
Notice the block size warnings.
The /etc/ctl.conf on both of the target machines is:
portal-group pg0 {
discovery-auth-group no-authentication
listen 0.0.0.0
listen [::]
}
lun 0 {
path /pool92/iscsi/iscsi.zvol
blocksize 4K
size 5T
option unmap "on"
option scsiname "pool92"
option vendor "pool92"
option insecure_tpc "on"
}
}
target iqn.iscsi1.zvol {
auth-group no-authentication
portal-group pg0
lun 0 {
path /pool92_1/iscsi/iscsi.zvol
blocksize 4K
size 5T
option unmap "on"
option scsiname "pool92_1"
option vendor "pool92_1"
option insecure_tpc "on"
}
}
Note the 4k size for my iSCSI Blocks.
I believe this error message to be incorrect, as recordsize=64k on the Target
will not affect the ashift value at a
[Bug 204633] If INVARIANTS is enabled, free() may attempt to acquire sleeping lock
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204633 --- Comment #4 from Ed Maste --- > Perhaps, I should propose a man page change to make this more clear. > And/or add a check in malloc/free to catch these problems more reliably. Indeed, it would be useful to have this clarified in the man page, and an explicit check under INVARIANTS in malloc/free would be sensible. -- 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 204640] make installworld fails installing libc_p.a to /usr/lib
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204640 NGie Cooper changed: What|Removed |Added CC||n...@freebsd.org --- Comment #3 from NGie Cooper --- Thomas: - What command did you use when you ran `make installworld`? `sudo make installworld`? - Did you set environment variables that affect SRCCONF or __MAKE_CONF? - Did you change WITHOUT_PROFILE to WITH_PROFILE after running `make buildworld`? - Did `make buildworld` succeed last time you ran it? -- 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 204633] If INVARIANTS is enabled, free() may attempt to acquire sleeping lock
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204633 Jonathan T. Looney changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|j...@freebsd.org --- Comment #5 from Jonathan T. Looney --- I have a proposed change out for review. See https://reviews.freebsd.org/D4197. -- 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 204650] [libc][rpc-svc][patch] rendezvous_request() does not populate local address
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204650 Bug ID: 204650 Summary: [libc][rpc-svc][patch] rendezvous_request() does not populate local address Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: alex.burlyga.i...@gmail.com Keywords: patch For connection oriented transporters when creating rendezvous transporter rpc library does not populate on which local address this transporter was created. patch which fixes the problem is coming up. -- 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 204651] ls --libxo html -l crashes in xo_format_string_direct()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204651
Bug ID: 204651
Summary: ls --libxo html -l crashes in
xo_format_string_direct()
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs@FreeBSD.org
Reporter: jbe...@freebsd.org
$ lldb =ls -- --libxo html -l
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (x86_64).
(lldb) settings set -- target.run-args "--libxo" "html" "-l"
(lldb) r
Process 78182 launching
Process 78182 launched: '/bin/ls' (x86_64)
total 204Process 78182 stopped
* thread #1: tid = 100311, 0x00080083e8b4
libxo.so.0`xo_format_string_direct(xop=0x00080062c910,
xbp=0x00080062c958, flags=4096, wcp=0x,
cp=0x0004, len=-1, max=-1, need_enc=2, have_enc=2) + 180 at
libxo.c:2291, stop reason = signal SIGSEGV: invalid address (fault address:
0x4)
frame #0: 0x00080083e8b4
libxo.so.0`xo_format_string_direct(xop=0x00080062c910,
xbp=0x00080062c958, flags=4096, wcp=0x,
cp=0x0004, len=-1, max=-1, need_enc=2, have_enc=2) + 180 at
libxo.c:2291
2288 break;
2289
2290 if (cp) {
-> 2291 if (*cp == '\0')
2292 break;
2293 if ((flags & XFF_UNESCAPE) && (*cp == '\\' || *cp == '%'))
{
2294 cp += 1;
(lldb) bt
* thread #1: tid = 100311, 0x00080083e8b4
libxo.so.0`xo_format_string_direct(xop=0x00080062c910,
xbp=0x00080062c958, flags=4096, wcp=0x,
cp=0x0004, len=-1, max=-1, need_enc=2, have_enc=2) + 180 at
libxo.c:2291, stop reason = signal SIGSEGV: invalid address (fault address:
0x4)
* frame #0: 0x00080083e8b4
libxo.so.0`xo_format_string_direct(xop=0x00080062c910,
xbp=0x00080062c958, flags=4096, wcp=0x,
cp=0x0004, len=-1, max=-1, need_enc=2, have_enc=2) + 180 at
libxo.c:2291
frame #1: 0x00080083f40e
libxo.so.0`xo_format_string(xop=0x00080062c910, xbp=0x00080062c958,
flags=4096, xfp=0x7fffc8a0) + 1006 at libxo.c:2555
frame #2: 0x00080083d07e
libxo.so.0`xo_do_format_field(xop=0x00080062c910, xbp=0x00080062c958,
fmt=0x00408121, flen=4, flags=4096) + 2798 at libxo.c:3071
frame #3: 0x000800832cb7
libxo.so.0`xo_buf_append_div(xop=0x00080062c910, class=0x0008008464e5,
flags=4096, name=0x0040811c, nlen=4, value=0x00408121, vlen=4,
encoding=0x, elen=0) + 2791 at libxo.c:3559
frame #4: 0x000800839d8c
libxo.so.0`xo_format_value(xop=0x00080062c910, name=0x0040811c,
nlen=4, format=0x00408121, flen=4, encoding=0x, elen=0,
flags=4096) + 1468 at libxo.c:3851
frame #5: 0x00080083640b libxo.so.0`xo_do_emit(xop=0x00080062c910,
fmt=0x004080ec) + 1163 at libxo.c:5776
frame #6: 0x000800836dfd libxo.so.0`xo_emit(fmt=0x004080ec) +
365 at libxo.c:5975
frame #7: 0x004052a7 ls`printlong(dp=0x7fffd788) + 807 at
print.c:197
frame #8: 0x00404ba1 ls`display(p=0x00080168a140,
list=0x00080168a780, options=16) + 4561 at ls.c:896
frame #9: 0x0040381e ls`traverse(argc=1, argv=0x006094b0,
options=16) + 702 at ls.c:577
frame #10: 0x0040352f ls`main(argc=0, argv=0x7fffe3a0) +
3455 at ls.c:498
frame #11: 0x0040208f ls`_start(ap=,
cleanup=) + 383 at crt1.c:78
--
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 204650] [libc][rpc-svc][patch] rendezvous_request() does not populate local address
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204650 --- Comment #1 from alex.burlyga.i...@gmail.com --- Created attachment 163272 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=163272&action=edit Populate local address when creating new transporter for connection oritented transporters -- 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 204340] [panic] nfsd, em, msix, fatal trap 9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204340 --- Comment #6 from g_amana...@yahoo.com --- (In reply to Rick Macklem from comment #4) It still crashes. I am going to get a dump tomorrow. -- You are receiving this mail because: You are on the CC list 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 204340] [panic] nfsd, em, msix, fatal trap 9
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204340 --- Comment #7 from g_amana...@yahoo.com --- This a fresh dump with the second patch applied, it seems the same. The problem seems to occur in xprt_active(). Unread portion of the kernel message buffer: stack pointer = 0x28:0xfe01ee7ee430 frame pointer = 0x28:0xfe01ee7ee4b0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq266: em1:rx0) trap number = 9 panic: general protection fault cpuid = 0 KDB: stack backtrace: #0 0x80984e30 at kdb_backtrace+0x60 #1 0x809489e6 at vpanic+0x126 #2 0x809488b3 at panic+0x43 #3 0x80d4ab6b at trap_fatal+0x36b #4 0x80d4a7ec at trap+0x75c #5 0x80d30882 at calltrap+0x8 #6 0x80b4a725 at xprt_active+0x45 #7 0x80b4e185 at svc_vc_soupcall+0x35 #8 0x809bcc52 at sowakeup+0x82 #9 0x80aea942 at tcp_do_segment+0x2b22 #10 0x80ae7720 at tcp_input+0x12b0 #11 0x80a77f57 at ip_input+0x97 #12 0x80a177d2 at netisr_dispatch_src+0x62 #13 0x80a0eb76 at ether_demux+0x126 #14 0x80a0f81e at ether_nh_input+0x35e #15 0x80a177d2 at netisr_dispatch_src+0x62 #16 0x804e121b at em_rxeof+0x2eb #17 0x804e1663 at em_msix_rx+0x33 Uptime: 10h5m21s Dumping 3079 out of 8134 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/zfs.ko.symbols...done. Loaded symbols for /boot/kernel/zfs.ko.symbols Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. Loaded symbols for /boot/kernel/opensolaris.ko.symbols Reading symbols from /boot/kernel/if_tap.ko.symbols...done. Loaded symbols for /boot/kernel/if_tap.ko.symbols Reading symbols from /boot/kernel/if_bridge.ko.symbols...done. Loaded symbols for /boot/kernel/if_bridge.ko.symbols Reading symbols from /boot/kernel/bridgestp.ko.symbols...done. Loaded symbols for /boot/kernel/bridgestp.ko.symbols Reading symbols from /boot/kernel/aio.ko.symbols...done. Loaded symbols for /boot/kernel/aio.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ipmi.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/aesni.ko.symbols...done. Loaded symbols for /boot/kernel/aesni.ko.symbols Reading symbols from /boot/kernel/crypto.ko.symbols...done. Loaded symbols for /boot/kernel/crypto.ko.symbols Reading symbols from /boot/kernel/mps.ko.symbols...done. Loaded symbols for /boot/kernel/mps.ko.symbols Reading symbols from /boot/kernel/vmm.ko.symbols...done. Loaded symbols for /boot/kernel/vmm.ko.symbols Reading symbols from /boot/kernel/nmdm.ko.symbols...done. Loaded symbols for /boot/kernel/nmdm.ko.symbols Reading symbols from /boot/kernel/geom_eli.ko.symbols...done. Loaded symbols for /boot/kernel/geom_eli.ko.symbols Reading symbols from /boot/kernel/ums.ko.symbols...done. Loaded symbols for /boot/kernel/ums.ko.symbols Reading symbols from /boot/kernel/ipfw.ko.symbols...done. Loaded symbols for /boot/kernel/ipfw.ko.symbols Reading symbols from /boot/kernel/dummynet.ko.symbols...done. Loaded symbols for /boot/kernel/dummynet.ko.symbols Reading symbols from /boot/kernel/ipfw_nat.ko.symbols...done. Loaded symbols for /boot/kernel/ipfw_nat.ko.symbols Reading symbols from /boot/kernel/libalias.ko.symbols...done. Loaded symbols for /boot/kernel/libalias.ko.symbols Reading symbols from /boot/kernel/ctl.ko.symbols...done. Loaded symbols for /boot/kernel/ctl.ko.symbols Reading symbols from /boot/kernel/iscsi.ko.symbols...done. Loaded symbols for /boot/kernel/iscsi.ko.symbols Reading symbols from /boot/kernel/nullfs.ko.symbols...done. Loaded symbols for /boot/kernel/nullfs.ko.symbols Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. Loaded symbols for /boot/kernel/fdescfs.ko.symbols #0 doadump (textdump=) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) list *0xfe01ee7ee430 No source file for address 0xfe01ee7ee430. (kgdb) backtrace #0 doadump (textdump=) at pcpu.h:219 #1 0x80948642 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0x80948a25 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0x809488b3 in panic (fmt=0x0) at /usr/src/sys/kern/kern_shutdown.c:687 #4 0x80d4ab6b in trap_fatal (frame=, eva=) at /usr/src/sys/amd64/amd64/trap.c:851 #5 0x80d4a7ec in trap (frame=) at /usr/src/sys/amd64/amd64/trap.c:203 #6 0x80d30882 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:236 #7 0x8092e980 in __mtx_lock_sleep (c=0xfe
