Re: Panic - uma_zfree_arg - zone argument is NULL
On 09/26/14 07:51, Hans Petter Selasky wrote:
On 09/25/14 11:19, Gleb Smirnoff wrote:
On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote:
H #7 0x80b07863 in uma_zfree_arg (zone=0x0,
item=0xf800114ee000,
H udata=0x81484760)
udata here is uma_slab_t. Can you look at it?
btw, is that reproducible on stable/10 or head?
Yes, it is reproducible. I have not tried stable/10 or head yet.
(kgdb) print *(uma_slab_t)udata
$3 = {
us_keg = 0xf8085696d680,
us_type = {
_us_link = {
le_next = 0xf80856970a80,
le_prev = 0x3
},
_us_size = 18446735313429006976
},
us_hlink = {
sle_next = 0x0
},
us_data = 0x81484778 ,
us_free = {
__bits = {0, 0, -2125969520, 0}
},
us_freecount = 0,
us_flags = 0 '\0',
us_pad = 0 '\0'
}
BTW: I don't rule out that this might be an indirect error of some other
kernel modules which I am experimenting with currently. But if you see
something which is obvious then please let me know.
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic - uma_zfree_arg - zone argument is NULL
On Fri, Sep 26, 2014 at 07:59:09AM +0200, Hans Petter Selasky wrote:
H On 09/26/14 07:51, Hans Petter Selasky wrote:
H On 09/25/14 11:19, Gleb Smirnoff wrote:
H On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote:
H H #7 0x80b07863 in uma_zfree_arg (zone=0x0,
H item=0xf800114ee000,
H H udata=0x81484760)
H
H udata here is uma_slab_t. Can you look at it?
H
H btw, is that reproducible on stable/10 or head?
H
H
H Yes, it is reproducible. I have not tried stable/10 or head yet.
H
H (kgdb) print *(uma_slab_t)udata
H $3 = {
H us_keg = 0xf8085696d680,
Can you print the us_keg, please?
--
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic - uma_zfree_arg - zone argument is NULL
On 09/26/14 08:06, Gleb Smirnoff wrote:
On Fri, Sep 26, 2014 at 07:59:09AM +0200, Hans Petter Selasky wrote:
H On 09/26/14 07:51, Hans Petter Selasky wrote:
H On 09/25/14 11:19, Gleb Smirnoff wrote:
H On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote:
H H #7 0x80b07863 in uma_zfree_arg (zone=0x0,
H item=0xf800114ee000,
H H udata=0x81484760)
H
H udata here is uma_slab_t. Can you look at it?
H
H btw, is that reproducible on stable/10 or head?
H
H
H Yes, it is reproducible. I have not tried stable/10 or head yet.
H
H (kgdb) print *(uma_slab_t)udata
H $3 = {
H us_keg = 0xf8085696d680,
Can you print the us_keg, please?
(kgdb) print *(*(uma_slab_t)udata).us_keg
$5 = {
uk_lock = {
lock_object = {
lo_name = 0xf8085696fd80 \200\n\227V\b???\200?\226V\b???,
lo_flags = 2168997728,
lo_data = 4294967295,
lo_witness = 0x0
},
mtx_lock = 0
},
uk_hash = {
uh_slab_hash = 0x0,
uh_hashsize = 0,
uh_hashmask = 0
},
uk_zones = {
lh_first = 0x0
},
uk_part_slab = {
lh_first = 0x224821000
},
uk_free_slab = {
lh_first = 0x0
},
uk_full_slab = {
lh_first = 0xf8085696d720
},
uk_align = 0,
uk_pages = 6,
uk_free = 0,
uk_reserve = 1,
uk_size = 131072,
uk_rsize = 67044352,
uk_maxpages = 269,
uk_init = 0,
uk_fini = 0x81484760 vm_phys_free_queues+336,
uk_allocf = 0xf8085696d7b8,
uk_freef = 0xf80854307748,
uk_offset = 18446744071584084984,
uk_kva = 36435,
uk_slabzone = 0x224822000,
uk_slabsize = 0,
uk_pgoff = 0,
uk_ppera = 0,
uk_ipers = 0,
uk_flags = 1452726152,
uk_name = 0x6 Address 0x6 out of bounds,
uk_link = {
le_next = 0x10001,
le_prev = 0x3ff0400
}
}
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic - uma_zfree_arg - zone argument is NULL
On Fri, Sep 26, 2014 at 08:30:06AM +0200, Hans Petter Selasky wrote:
H On 09/26/14 08:06, Gleb Smirnoff wrote:
H On Fri, Sep 26, 2014 at 07:59:09AM +0200, Hans Petter Selasky wrote:
H H On 09/26/14 07:51, Hans Petter Selasky wrote:
H H On 09/25/14 11:19, Gleb Smirnoff wrote:
H H On Thu, Sep 18, 2014 at 02:03:44PM +0200, Hans Petter Selasky wrote:
H H H #7 0x80b07863 in uma_zfree_arg (zone=0x0,
H H item=0xf800114ee000,
H H H udata=0x81484760)
H H
H H udata here is uma_slab_t. Can you look at it?
H H
H H btw, is that reproducible on stable/10 or head?
H H
H H
H H Yes, it is reproducible. I have not tried stable/10 or head yet.
H H
H H (kgdb) print *(uma_slab_t)udata
H H $3 = {
H H us_keg = 0xf8085696d680,
H
H Can you print the us_keg, please?
H
H (kgdb) print *(*(uma_slab_t)udata).us_keg
skip
It is trash. This means that vtoslab() returned us bad pointer.
Either this mean the address passed to free() is invalid, and
belongs to a page not under UMA control, or someone else have
mangled the page belonging to UMA.
Can you please print *(struct vm_page *)0x81484760 ?
--
Totus tuus, Glebius.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic - uma_zfree_arg - zone argument is NULL
On 09/26/14 08:44, Gleb Smirnoff wrote:
print *(struct vm_page *)0x81484760
(kgdb) print *(struct vm_page *)0x81484760
$4 = {
plinks = {
q = {
tqe_next = 0xf8085696d680,
tqe_prev = 0xf80856970a80
},
s = {
ss = {
sle_next = 0xf8085696d680
},
pv = 0xf80856970a80
},
memguard = {
p = 18446735313428993664,
v = 18446735313429006976
}
},
listq = {
tqe_next = 0x3,
tqe_prev = 0x0
},
object = 0x81484778,
pindex = 0,
phys_addr = 0,
md = {
pv_list = {
tqh_first = 0x81484790,
tqh_last = 0x0
},
pv_gen = 0,
pat_mode = 0
},
wire_count = 2168997800,
busy_lock = 4294967295,
hold_count = 0,
flags = 0,
aflags = 0 '\0',
oflags = 0 '\0',
queue = 0 '\0',
segind = 0 '\0',
order = 0 '\0',
pool = 0 '\0',
act_count = 0 '\0',
valid = 0 '\0',
dirty = 0 '\0'
}
--HPS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Boot failure with r272146
On Thu, 2014-09-25 at 20:40 -0700, Justin Hibbits wrote: With r272146 my SATA controller fails to attach, preventing the kernel from mounting root. I've attached a log of as much as dconschat would allow. The relevant portion is pcib10: atapci0: ServerWorks K2 SATA150 controller mem 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 pcib10: failed to allocate initial I/O port window (0-0x,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0x). atapci0: unable to map interrupt device_attach: atapci0 attach returned 6 pcib10: allocated memory range (0xfa40-0xfa400fff) for rid 10 of pci1:3:14:0 atapci0: ServerWorks K2 SATA150 controller mem 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 pcib10: failed to allocate initial I/O port window (0-0x,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0x). atapci0: unable to map interrupt device_attach: atapci0 attach returned 6 ata0: Shasta Kauai ATA Controller mem 0xfa404000-0xfa407fff at device 13.0 on pci10 ofw_pci mapdev: start fa404000, len 16384 ata0: unable to allocate interrupt device_attach: ata0 attach returned 6 It works fine with r271697 kernel (latest I have booting). I haven't yet tried bisecting. Hardware is a PowerMac G5 (last generation). - Justin Ooops, I think a paste-o in my r272109 caused it. See if this fixes it. -- Ian Index: sys/powerpc/ofw/ofw_pcibus.c === --- sys/powerpc/ofw/ofw_pcibus.c (revision 272109) +++ sys/powerpc/ofw/ofw_pcibus.c (working copy) @@ -201,7 +201,7 @@ ofw_pcibus_enum_devtree(device_t dev, u_int domain * resource list. */ if (dinfo-opd_dinfo.cfg.intpin == 0) - ofw_bus_intr_to_rl(dev, node, dinfo-opd_dinfo.resources); + ofw_bus_intr_to_rl(dev, child, dinfo-opd_dinfo.resources); } } ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Boot failure with r272146
That fixed it, thanks! -Justin On Sep 26, 2014 6:59 AM, Ian Lepore i...@freebsd.org wrote: On Thu, 2014-09-25 at 20:40 -0700, Justin Hibbits wrote: With r272146 my SATA controller fails to attach, preventing the kernel from mounting root. I've attached a log of as much as dconschat would allow. The relevant portion is pcib10: atapci0: ServerWorks K2 SATA150 controller mem 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 pcib10: failed to allocate initial I/O port window (0-0x,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0x). atapci0: unable to map interrupt device_attach: atapci0 attach returned 6 pcib10: allocated memory range (0xfa40-0xfa400fff) for rid 10 of pci1:3:14:0 atapci0: ServerWorks K2 SATA150 controller mem 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 pcib10: failed to allocate initial I/O port window (0-0x,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0x). atapci0: unable to map interrupt device_attach: atapci0 attach returned 6 ata0: Shasta Kauai ATA Controller mem 0xfa404000-0xfa407fff at device 13.0 on pci10 ofw_pci mapdev: start fa404000, len 16384 ata0: unable to allocate interrupt device_attach: ata0 attach returned 6 It works fine with r271697 kernel (latest I have booting). I haven't yet tried bisecting. Hardware is a PowerMac G5 (last generation). - Justin Ooops, I think a paste-o in my r272109 caused it. See if this fixes it. -- Ian Index: sys/powerpc/ofw/ofw_pcibus.c === --- sys/powerpc/ofw/ofw_pcibus.c(revision 272109) +++ sys/powerpc/ofw/ofw_pcibus.c(working copy) @@ -201,7 +201,7 @@ ofw_pcibus_enum_devtree(device_t dev, u_int domain * resource list. */ if (dinfo-opd_dinfo.cfg.intpin == 0) - ofw_bus_intr_to_rl(dev, node, dinfo-opd_dinfo.resources); + ofw_bus_intr_to_rl(dev, child, dinfo-opd_dinfo.resources); } } ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Boot failure with r272146
On Fri, 2014-09-26 at 07:40 -0700, Justin Hibbits wrote: That fixed it, thanks! -Justin Fix committed as r272181, sorry for the glitch. -- Ian On Sep 26, 2014 6:59 AM, Ian Lepore i...@freebsd.org wrote: On Thu, 2014-09-25 at 20:40 -0700, Justin Hibbits wrote: With r272146 my SATA controller fails to attach, preventing the kernel from mounting root. I've attached a log of as much as dconschat would allow. The relevant portion is pcib10: atapci0: ServerWorks K2 SATA150 controller mem 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 pcib10: failed to allocate initial I/O port window (0-0x,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0x). atapci0: unable to map interrupt device_attach: atapci0 attach returned 6 pcib10: allocated memory range (0xfa40-0xfa400fff) for rid 10 of pci1:3:14:0 atapci0: ServerWorks K2 SATA150 controller mem 0xfa402000-0xfa403fff at device 12.0 on pci10 pcib1: failed to reserve resource for pcib10 pcib10: failed to allocate initial I/O port window (0-0x,0x10) atapci0: 0x10 bytes of rid 0x20 res 4 failed (0, 0x). atapci0: unable to map interrupt device_attach: atapci0 attach returned 6 ata0: Shasta Kauai ATA Controller mem 0xfa404000-0xfa407fff at device 13.0 on pci10 ofw_pci mapdev: start fa404000, len 16384 ata0: unable to allocate interrupt device_attach: ata0 attach returned 6 It works fine with r271697 kernel (latest I have booting). I haven't yet tried bisecting. Hardware is a PowerMac G5 (last generation). - Justin Ooops, I think a paste-o in my r272109 caused it. See if this fixes it. -- Ian Index: sys/powerpc/ofw/ofw_pcibus.c === --- sys/powerpc/ofw/ofw_pcibus.c(revision 272109) +++ sys/powerpc/ofw/ofw_pcibus.c(working copy) @@ -201,7 +201,7 @@ ofw_pcibus_enum_devtree(device_t dev, u_int domain * resource list. */ if (dinfo-opd_dinfo.cfg.intpin == 0) - ofw_bus_intr_to_rl(dev, node, dinfo-opd_dinfo.resources); + ofw_bus_intr_to_rl(dev, child, dinfo-opd_dinfo.resources); } } ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Xorg causes panics with multiple drivers (Was: panic: resource_list_alloc: resource entry is busy)
On Monday, September 15, 2014 11:25:47 AM John Baldwin wrote: On Saturday, September 13, 2014 10:57:53 AM d...@gmx.com wrote: John Baldwin wrote on 09/12/2014 23:06: X loaded i915kms automatically and i915 and i915kms do not get along. i915 had already allocated the IRQ when i915kms tried to alloc the same IRQ causing the issue. Who is to blame? The user who tried to manually load an unsupported combination of modules, or the system, which should have handled things gracefully (whether by automatically unloading the first driver, or producing a soft-error upon loading the 2nd driver)? On a side-note, I also had a resource_list_alloc: resource entry is busy panic right after switching from the 10.0-supported Xorg to the new Xorg; I exited Xorg, enabled FreeBSD_new_Xorg, ran pkg upgrade, then ran startx, and got the panic. Surely this wasn't my fault! I can turn the panic into a resource allocation failure, but specifically with KMS I am unsure if it will actually be better. FYI, I wrote a test for the patch I sent to make this not panic and verified it worked ok and committed it. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Build failed in Jenkins: FreeBSD_HEAD #1534
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1534/changes Changes: [np] cxgbe(4): explicitly set various if_hw_tso* values. MFC after: 3 days [delphij] Add libuutil to dependency list. Noticed by: sef MFC after: 3 days -- [...truncated 86223 lines...] https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:2543:50: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Wformat] dgettext(TEXT_DOMAIN, cannot fault %llu), guid); ^~~~ %lu https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:2578:52: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Wformat] dgettext(TEXT_DOMAIN, cannot degrade %llu), guid); ^~~~ %lu https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:3247:6: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Wformat] guid); ^~~~ https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:3841:57: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(pathname, len, metadata:0x%llx, obj); ^~~ %lx https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:3852:7: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Wformat] dsobj, obj); ^ https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:3852:14: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Wformat] dsobj, obj); ^~~ https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:3873:57: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Wformat] (void) snprintf(pathname, len, %s:0x%llx, dsname, obj); ^~~ %lx --- kerberos5/lib__L --- --- crypto.o --- cc -O2 -pipe -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libgssapi_ntlm/../../../crypto/heimdal/lib/gssapi -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libgssapi_ntlm/../../../crypto/heimdal/lib/gssapi/gssapi -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libgssapi_ntlm/../../../crypto/heimdal/lib/gssapi/ntlm -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libgssapi_ntlm/../../../crypto/heimdal/lib/krb5 -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libgssapi_ntlm/../../../crypto/heimdal/lib/ntlm -DHAVE_CONFIG_H -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libgssapi_ntlm/../../include -std=gnu99 -fstack-protector -Qunused-arguments -c https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libgssapi_ntlm/../../../crypto/heimdal/lib/gssapi/ntlm/crypto.c -o crypto.o --- lib__L --- --- depend_subdir_clang --- --- depend_subdir_libclangarcmigrate --- === lib/clang/libclangarcmigrate (depend) --- kerberos5/lib__L --- --- delete_sec_context.o --- cc -O2 -pipe -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libgssapi_ntlm/../../../crypto/heimdal/lib/gssapi -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libgssapi_ntlm/../../../crypto/heimdal/lib/gssapi/gssapi -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libgssapi_ntlm/../../../crypto/heimdal/lib/gssapi/ntlm -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libgssapi_ntlm/../../../crypto/heimdal/lib/krb5 -Ihttps://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/kerberos5/lib/libgssapi_ntlm/../../../crypto/heimdal/lib/ntlm -DHAVE_CONFIG_H
Build failed in Jenkins: FreeBSD_HEAD #1535
See https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/1535/changes
Changes:
[kevlo] Remove a bogus AIC.
Reviewed by:imp
[grehan] Allow the PIC's IMR register to be read before ICW initialisation.
As of git submit e179f6914152eca9, the Linux kernel does a simple
probe of the PIC by writing a pattern to the IMR and then reading it
back, prior to the init sequence of ICW words.
The bhyve PIC emulation wasn't allowing the IMR to be read until
the ICW sequence was complete. This limitation isn't required so
relax the test.
With this change, Linux kernels 3.15-rc2 and later won't hang
on boot when calibrating the local APIC.
Reviewed by:tychon
MFC after: 3 days
--
[...truncated 89694 lines...]
^~
%lu
--- lib__L ---
rm -f .depend
CC='cc ' mkdep -f .depend -a -std=gnu99
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/libmemstat/memstat.c
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/libmemstat/memstat_all.c
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/libmemstat/memstat_malloc.c
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/lib/libmemstat/memstat_uma.c
--- cddl/lib__L ---
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:1493:8:
warning: format specifies type 'long long' but the argument has type 'long'
[-Wformat]
(loss + 30) / 60);
^~~~
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:1499:48:
warning: format specifies type 'long long' but the argument has type 'int64_t'
(aka 'long') [-Wformat]
dryrun ? Would discard : Discarded, loss);
^~~~
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:1553:48:
warning: format specifies type 'long long' but the argument has type 'long'
[-Wformat]
\tmust be discarded, irreversibly. ), (loss + 30) / 60);
^~~~
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:1557:48:
warning: format specifies type 'long long' but the argument has type 'int64_t'
(aka 'long') [-Wformat]
\tmust be discarded, irreversibly. ), loss);
^~~~
--- lib__L ---
--- depend_subdir_libmd ---
=== lib/libmd (depend)
--- cddl/lib__L ---
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:2543:50:
warning: format specifies type 'unsigned long long' but the argument has type
'uint64_t' (aka 'unsigned long') [-Wformat]
dgettext(TEXT_DOMAIN, cannot fault %llu), guid);
^~~~
%lu
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:2578:52:
warning: format specifies type 'unsigned long long' but the argument has type
'uint64_t' (aka 'unsigned long') [-Wformat]
dgettext(TEXT_DOMAIN, cannot degrade %llu), guid);
^~~~
%lu
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:3247:6:
warning: format specifies type 'unsigned long long' but the argument has type
'uint64_t' (aka 'unsigned long') [-Wformat]
guid);
^~~~
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:3841:57:
warning: format specifies type 'unsigned long long' but the argument has type
'uint64_t' (aka 'unsigned long') [-Wformat]
(void) snprintf(pathname, len, metadata:0x%llx, obj);
^~~
%lx
https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD/ws/cddl/lib/libzfs/../../../cddl/contrib/opensolaris/lib/libzfs/common/libzfs_pool.c:3852:7:
warning: format specifies type 'unsigned long long' but the argument has type
'uint64_t' (aka 'unsigned long') [-Wformat]
dsobj, obj);
^
