Cannot setup dumpdev on glabel disk
I am running 11-STABLE, and I am experiencing kernel panics when I am destroying a VIMAGE-based jail. Naturally, I flipped to the chapter about 'Kernel Debugging' to learn about 'Obtaining a Kernel Crash Dump'. However, I am finding that my permanently glabel'ed disk partition cannot be used as dumpdev. Is that true, and why not? I mean, swap can use it just fine. I am unable to find this restriction in the documentation. # grep swap /etc/fstab /dev/label/boot01b none swap sw 0 0 # swapinfo Device 1K-blocks Used Avail Capacity /dev/label/boot01b 41943040 0 41943040 0% # glabel status | grep boot label/boot01 N/A ada4s1 label/boot02 N/A ada5s1 # dumpon /dev/label/boot01b dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported by device ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cannot setup dumpdev on glabel disk
On Fri, Aug 31, 2018 at 10:08:20AM -0600, Samuel Chow wrote: > I am running 11-STABLE, and I am experiencing kernel panics when I am > destroying a VIMAGE-based jail. Naturally, I flipped to the chapter > about 'Kernel Debugging' to learn about 'Obtaining a Kernel Crash Dump'. > > However, I am finding that my permanently glabel'ed disk partition > cannot be used as dumpdev. Is that true, and why not? I mean, swap can > use it just fine. I am unable to find this restriction in the documentation. I don't think that there is a real reason for this restriction; the glabel GEOM class simply doesn't implement the required support. Do you mind submitting a PR for this at https://bugs.freebsd.org/bugzilla/ ? I will try and get that fixed soon if no one else beats me to it. > # grep swap /etc/fstab > /dev/label/boot01b none swap sw 0 0 > # swapinfo > Device 1K-blocks Used Avail Capacity > /dev/label/boot01b 41943040 0 41943040 0% > # glabel status | grep boot > label/boot01 N/A ada4s1 > label/boot02 N/A ada5s1 > # dumpon /dev/label/boot01b > dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported by device > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cannot setup dumpdev on glabel disk
31.08.2018 23:08, Samuel Chow wrote:
> I am running 11-STABLE, and I am experiencing kernel panics when I am
> destroying a VIMAGE-based jail. Naturally, I flipped to the chapter about
> 'Kernel Debugging' to learn about 'Obtaining a Kernel Crash Dump'.
>
> However, I am finding that my permanently glabel'ed disk partition cannot be
> used as dumpdev. Is that true, and why not? I mean, swap can use it just
> fine. I am unable to find this restriction in the documentation.
>
>
> # grep swap /etc/fstab
> /dev/label/boot01b none swap sw 0 0
> # swapinfo
> Device 1K-blocks UsedAvail Capacity
> /dev/label/boot01b 419430400 41943040 0%
> # glabel status | grep boot
> label/boot01 N/A ada4s1
> label/boot02 N/A ada5s1
> # dumpon /dev/label/boot01b
> dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported by device
That's not about label but underlying device that seems to be GEOM_PART_MBR
and it allows kernel dumps only if slice (MBR partition) type is 0xa5 for
"freebsd"
or 0x82 ("linux swap"). Please show output of the command "gpart show ada4".
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cannot setup dumpdev on glabel disk
On Sat, Sep 01, 2018 at 02:09:12AM +0700, Eugene Grosbein wrote:
> 31.08.2018 23:08, Samuel Chow wrote:
>
> > I am running 11-STABLE, and I am experiencing kernel panics when I am
> > destroying a VIMAGE-based jail. Naturally, I flipped to the chapter about
> > 'Kernel Debugging' to learn about 'Obtaining a Kernel Crash Dump'.
> >
> > However, I am finding that my permanently glabel'ed disk partition cannot
> > be used as dumpdev. Is that true, and why not? I mean, swap can use it just
> > fine. I am unable to find this restriction in the documentation.
> >
> >
> > # grep swap /etc/fstab
> > /dev/label/boot01b none swap sw 0 0
> > # swapinfo
> > Device 1K-blocks UsedAvail Capacity
> > /dev/label/boot01b 419430400 41943040 0%
> > # glabel status | grep boot
> > label/boot01 N/A ada4s1
> > label/boot02 N/A ada5s1
> > # dumpon /dev/label/boot01b
> > dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported by device
>
> That's not about label but underlying device that seems to be GEOM_PART_MBR
> and it allows kernel dumps only if slice (MBR partition) type is 0xa5 for
> "freebsd"
> or 0x82 ("linux swap"). Please show output of the command "gpart show ada4".
Ah, right, please ignore my other reply. When I actually test it
myself, dumpon /dev/label/foo seems to work; I assumed the lack of
handling for GEOM::kerneldump in the glabel code was a problem. Sorry
for the noise.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cannot setup dumpdev on glabel disk
On 8/31/2018 1:09 PM, Eugene Grosbein wrote:
31.08.2018 23:08, Samuel Chow wrote:
I am running 11-STABLE, and I am experiencing kernel panics when I am
destroying a VIMAGE-based jail. Naturally, I flipped to the chapter about
'Kernel Debugging' to learn about 'Obtaining a Kernel Crash Dump'.
However, I am finding that my permanently glabel'ed disk partition cannot be
used as dumpdev. Is that true, and why not? I mean, swap can use it just fine.
I am unable to find this restriction in the documentation.
# grep swap /etc/fstab
/dev/label/boot01b none swap sw 0 0
# swapinfo
Device 1K-blocks UsedAvail Capacity
/dev/label/boot01b 419430400 41943040 0%
# glabel status | grep boot
label/boot01 N/A ada4s1
label/boot02 N/A ada5s1
# dumpon /dev/label/boot01b
dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported by device
That's not about label but underlying device that seems to be GEOM_PART_MBR
and it allows kernel dumps only if slice (MBR partition) type is 0xa5 for
"freebsd"
or 0x82 ("linux swap"). Please show output of the command "gpart show ada4".
I do have "freebsd" (0xa5) type configured on the MBR partition.
# gpart show ada4
=> 63 937703025 ada4 MBR (447G)
63 937703025 1 freebsd [active] (447G)
# gpart show -r ada4
=> 63 937703025 ada4 MBR (447G)
63 937703025 1 165 [active] (447G)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cannot setup dumpdev on glabel disk
On 8/31/2018 1:21 PM, Mark Johnston wrote:
On Sat, Sep 01, 2018 at 02:09:12AM +0700, Eugene Grosbein wrote:
31.08.2018 23:08, Samuel Chow wrote:
I am running 11-STABLE, and I am experiencing kernel panics when I am
destroying a VIMAGE-based jail. Naturally, I flipped to the chapter about
'Kernel Debugging' to learn about 'Obtaining a Kernel Crash Dump'.
However, I am finding that my permanently glabel'ed disk partition cannot be
used as dumpdev. Is that true, and why not? I mean, swap can use it just fine.
I am unable to find this restriction in the documentation.
# grep swap /etc/fstab
/dev/label/boot01b none swap sw 0 0
# swapinfo
Device 1K-blocks UsedAvail Capacity
/dev/label/boot01b 419430400 41943040 0%
# glabel status | grep boot
label/boot01 N/A ada4s1
label/boot02 N/A ada5s1
# dumpon /dev/label/boot01b
dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported by device
That's not about label but underlying device that seems to be GEOM_PART_MBR
and it allows kernel dumps only if slice (MBR partition) type is 0xa5 for
"freebsd"
or 0x82 ("linux swap"). Please show output of the command "gpart show ada4".
Ah, right, please ignore my other reply. When I actually test it
myself, dumpon /dev/label/foo seems to work; I assumed the lack of
handling for GEOM::kerneldump in the glabel code was a problem. Sorry
for the noise.
I wonder if you are testing the same thing as I am? It looks like you
are dumping to a glabel'ed device directly, whereas I am dumping to the
b partition of my glabel'ed disk.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cannot setup dumpdev on glabel disk
On 8/31/2018 1:46 PM, Samuel Chow wrote:
On 8/31/2018 1:21 PM, Mark Johnston wrote:
On Sat, Sep 01, 2018 at 02:09:12AM +0700, Eugene Grosbein wrote:
31.08.2018 23:08, Samuel Chow wrote:
I am running 11-STABLE, and I am experiencing kernel panics when I
am destroying a VIMAGE-based jail. Naturally, I flipped to the
chapter about 'Kernel Debugging' to learn about 'Obtaining a Kernel
Crash Dump'.
However, I am finding that my permanently glabel'ed disk partition
cannot be used as dumpdev. Is that true, and why not? I mean, swap
can use it just fine. I am unable to find this restriction in the
documentation.
# grep swap /etc/fstab
/dev/label/boot01b none swap sw 0 0
# swapinfo
Device 1K-blocks Used Avail Capacity
/dev/label/boot01b 41943040 0 41943040 0%
# glabel status | grep boot
label/boot01 N/A ada4s1
label/boot02 N/A ada5s1
# dumpon /dev/label/boot01b
dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported by device
That's not about label but underlying device that seems to be
GEOM_PART_MBR
and it allows kernel dumps only if slice (MBR partition) type is
0xa5 for "freebsd"
or 0x82 ("linux swap"). Please show output of the command "gpart
show ada4".
Ah, right, please ignore my other reply. When I actually test it
myself, dumpon /dev/label/foo seems to work; I assumed the lack of
handling for GEOM::kerneldump in the glabel code was a problem. Sorry
for the noise.
I wonder if you are testing the same thing as I am? It looks like you
are dumping to a glabel'ed device directly, whereas I am dumping to
the b partition of my glabel'ed disk.
Wait. Maybe my problem is because I did not setup the b partition
correctly with fstype swap. I will check it out later.
# bsdlabel /dev/label/boot01
# /dev/label/boot01:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 10485760 1 4.2BSD 0 0 0
b: 83886080 10485761 4.2BSD 0 0 0
c: 937703024 0 unused 0 0 # "raw" part,
don't edit
d: 41943040 94371841 4.2BSD 0 0 0
e: 20971520 136314881 4.2BSD 0 0 0
f: 83886080 157286401 4.2BSD 0 0 0
g: 696530536 241172481 ZFS
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Cannot setup dumpdev on glabel disk
On 8/31/2018 1:52 PM, Samuel Chow wrote:
On 8/31/2018 1:46 PM, Samuel Chow wrote:
On 8/31/2018 1:21 PM, Mark Johnston wrote:
On Sat, Sep 01, 2018 at 02:09:12AM +0700, Eugene Grosbein wrote:
31.08.2018 23:08, Samuel Chow wrote:
I am running 11-STABLE, and I am experiencing kernel panics when I
am destroying a VIMAGE-based jail. Naturally, I flipped to the
chapter about 'Kernel Debugging' to learn about 'Obtaining a
Kernel Crash Dump'.
However, I am finding that my permanently glabel'ed disk partition
cannot be used as dumpdev. Is that true, and why not? I mean, swap
can use it just fine. I am unable to find this restriction in the
documentation.
# grep swap /etc/fstab
/dev/label/boot01b none swap sw 0 0
# swapinfo
Device 1K-blocks Used Avail Capacity
/dev/label/boot01b 41943040 0 41943040 0%
# glabel status | grep boot
label/boot01 N/A ada4s1
label/boot02 N/A ada5s1
# dumpon /dev/label/boot01b
dumpon: ioctl(DIOCSKERNELDUMP): Operation not supported by device
That's not about label but underlying device that seems to be
GEOM_PART_MBR
and it allows kernel dumps only if slice (MBR partition) type is
0xa5 for "freebsd"
or 0x82 ("linux swap"). Please show output of the command "gpart
show ada4".
Ah, right, please ignore my other reply. When I actually test it
myself, dumpon /dev/label/foo seems to work; I assumed the lack of
handling for GEOM::kerneldump in the glabel code was a problem. Sorry
for the noise.
I wonder if you are testing the same thing as I am? It looks like you
are dumping to a glabel'ed device directly, whereas I am dumping to
the b partition of my glabel'ed disk.
Wait. Maybe my problem is because I did not setup the b partition
correctly with fstype swap. I will check it out later.
# bsdlabel /dev/label/boot01
# /dev/label/boot01:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 10485760 1 4.2BSD 0 0 0
b: 83886080 10485761 4.2BSD 0 0 0
c: 937703024 0 unused 0 0 # "raw" part,
don't edit
d: 41943040 94371841 4.2BSD 0 0 0
e: 20971520 136314881 4.2BSD 0 0 0
f: 83886080 157286401 4.2BSD 0 0 0
g: 696530536 241172481 ZFS
That was indeed the problem. It is working now. Sorry for the noise.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Constraints in libmap(32).conf do not work as expected, possible bug in rtld-elf
On a FreeBSD 10.4-STABLE r337823 (amd64) server I have to run some old
php52 scripts from an FreeBSD 8.4-STABLE r284383 (i386) server. I have
copied the old php software to /usr/local/php52, installed the ports
misc/compat8x and misc/compat9x and have copied all missing 32-bit
libraries from the old machine to /usr/local/lib32. With the following
libmap32.conf everything works fine:
## php52
/usr/local/lib /usr/local/lib32
/usr/local/lib/mysql/usr/local/lib32/mysql
Two examples:
-> ldd /usr/local/php52/bin/php
/usr/local/php52/bin/php:
libcrypt.so.5 => /usr/lib32/libcrypt.so.5 (0x28273000)
librt.so.1 => /usr/lib32/librt.so.1 (0x28292000)
libm.so.5 => /usr/lib32/libm.so.5 (0x28298000)
libxml2.so.5 => /usr/local/lib32/libxml2.so.5 (0x282c2000)
libz.so.5 => /usr/local/lib32/compat/libz.so.5 (0x283ec000)
libiconv.so.3 => /usr/local/lib32/libiconv.so.3 (0x283fe000)
libc.so.7 => /usr/lib32/libc.so.7 (0x284f2000)
libthr.so.3 => /usr/lib32/libthr.so.3 (0x2866c000)
-> ldd /usr/local/php52/lib/php/20060613/mysql.so
/usr/local/php52/lib/php/20060613/mysql.so:
libmysqlclient.so.16 =>
/usr/local/lib32/mysql/libmysqlclient.so.16 (0x28206000)
libc.so.7 => /usr/lib32/libc.so.7 (0x2807)
libcrypt.so.5 => /usr/lib32/libcrypt.so.5 (0x2835e000)
libm.so.5 => /usr/lib32/libm.so.5 (0x2837d000)
libz.so.5 => /usr/local/lib32/compat/libz.so.5 (0x283a7000)
librt.so.1 => /usr/lib32/librt.so.1 (0x283b9000)
libthr.so.3 => /usr/lib32/libthr.so.3 (0x283bf000)
Because I like to use constraints in libmap32.conf I chenged the file to
## php52
[/usr/local/php52/]
/usr/local/lib /usr/local/lib32
[/usr/local/php52/lib/php/20060613/mysql.so]
/usr/local/lib/mysql/usr/local/lib32/mysql
The same examples as above shows that libmap does not work anymore:
-> ldd /usr/local/php52/bin/php
/usr/local/php52/bin/php:
libcrypt.so.5 => /usr/lib32/libcrypt.so.5 (0x28273000)
librt.so.1 => /usr/lib32/librt.so.1 (0x28292000)
libm.so.5 => /usr/lib32/libm.so.5 (0x28298000)
libxml2.so.5 => not found (0)
libz.so.5 => /usr/local/lib32/compat/libz.so.5 (0x282c2000)
libiconv.so.3 => not found (0)
libc.so.7 => /usr/lib32/libc.so.7 (0x282d4000)
libthr.so.3 => /usr/lib32/libthr.so.3 (0x2844e000)
-> ldd /usr/local/php52/lib/php/20060613/mysql.so
/usr/local/php52/lib/php/20060613/mysql.so:
libmysqlclient.so.16 => not found (0)
libc.so.7 => /usr/lib32/libc.so.7 (0x2807)
The constraints in libmap.conf are handled in rtld-elf with the help of
contexts, and especially a "$DEFAULT$" context is used for all entries
in libmap.conf before the first constraint statement. Now when rtld-elf
loads a program the mapping rules from libmap.conf are applied. In a
first step rtld-elf does a direct mapping using the correct context. But
in a second step called "Searching for ..." rtld-elf uses always the
"$DEFAULT$" context, which in the last example is empty. Therfore
rtld-elf does never find a library in his searching step and cannot load
programs where searching for libraries is necessary.
I cannot see any reason why rtld-elf should change the context between
step1 and step2, The following patch provokes that rtld-elf uses the
context from step1 in step2 too:
--- rtld.c.orig 2018-03-20 16:56:48.0 +0100
+++ rtld.c 2018-08-31 23:17:18.051206000 +0200
@@ -186,6 +186,7 @@
static Obj_Entry obj_rtld; /* The dynamic linker shared object */
static unsigned int obj_count; /* Number of objects in obj_list */
static unsigned int obj_loads; /* Number of loads of objects (gen count) */
+static char *save_refobj_path;
static Objlist list_global = /* Objects dlopened with RTLD_GLOBAL */
STAILQ_HEAD_INITIALIZER(list_global);
@@ -1499,6 +1500,7 @@
if (libmap_disable || !objgiven ||
(name = lm_find(refobj->path, xname)) == NULL)
name = (char *)xname;
+save_refobj_path = refobj->path;
dbg(" Searching for \"%s\"", name);
@@ -2831,7 +2833,7 @@
char *res;
len = strcspn(path, ":;");
- trans = lm_findn(NULL, path, len);
+ trans = lm_findn(save_refobj_path, path, len);
if (trans)
res = callback(trans, strlen(trans), arg);
else
This patch solves the described problem for me.
Andreas Longwitz
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD OpenCL/CUDA nVidia
Hello world, Is nVidia OpenCL/CUDA supported on FreeBSD? I have GF1030GT on 11.2-RELEASE AMD64 using 390.77 nvidia driver. CLINFO shows 0 number of platforms :-( Any hints welcome :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
