Re: ZFS booting without partitions (was: ZFS boot on zfs mirror)

2009-06-01 Thread Alberto Villa
On Thu, May 28, 2009 at 3:58 PM, Lorenzo Perone
lopez.on.the.li...@yellowspace.net wrote:
 the result is, when choosing the disk with the zfs boot
 sectors in it (in my case F5, which goes to ad6), the kernel
 is not found. the console shows:

 forth not found
 definitions not found
 only not found
 (the above repeated several times)

 can't load 'kernel'

 and I get thrown to the loader prompt.
 lsdev does not show any ZFS devices.

same here on 7-stable (csupped yesterday)
i've followed the same steps, but i've used gpt as explained in the
first mail. the same exact steps worked perfectly on 8-current in
virtualbox
-- 
Alberto Villa villa.albe...@gmail.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: ZFS booting without partitions

2009-06-01 Thread Henri Hennebert

Lorenzo Perone wrote:

Hi,

I tried hard... but without success ;(

the result is, when choosing the disk with the zfs boot
sectors in it (in my case F5, which goes to ad6), the kernel
is not found. the console shows:

forth not found
definitions not found
only not found
(the above repeated several times)


This is the file /boot/loader from 7.2-STABLE which is wrong.

You can find a copy from 8.0-CURRENT and a script that I tested on a USB 
key) and is running for me:


http://verbier.restart.be/xfer/boot-zfs/

Put this directory somewhere, eg /tmp/boot-zfs

and run the script eg:
`cd /tmp/boot-zfs  sh -x make_usb_key.sh da6 kingston`

good luck

Henri


can't load 'kernel'

and I get thrown to the loader prompt.
lsdev does not show any ZFS devices.

Strange thing: if I boot from the other disk, F1, which is my
ad4 containing the normal ufs system I used to make up the other
one, and escape to the loader prompt, lsdev actually sees the
zpool which is on the other disk, and shows:
zfs0: tank

I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel,
but there I get the panic: free: guard1 fail message.
(would boot zfs:tank:/boot/kernel/kernel be correct, anyways?)

Sure I'm doing something wrong, but what...? Is it a problem that
the pool is made out of the second disk only (ad6)?

Here are my details (note: latest stable and biosdisk.c merged
with changes shown in r185095. no problems in buildworld/kernel):

snip

Machine: p4 4GHz 4 GB RAM (i386)

Note: the pool has actually a different name (heidi
instead of tank, if this can be of any relevance...),
just using tank here as it's one of the conventions...

mount (just to show my starting situation)

/dev/mirror/gm0s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates)
/dev/mirror/gm0s1f on /usr (ufs, local, soft-updates)
/dev/mirror/gm0s1d on /var (ufs, local, soft-updates)

gmirror status
  NameStatus  Components
mirror/gm0  DEGRADED  ad4
(ad6 used to be the second disk...)

echo 'LOADER_ZFS_SUPPORT=yes'  /etc/make.conf

cd /usr/src
make buildworld  make buildkernel KERNCONF=HEIDI
make installkernel KERNCONF=HEIDI
mergemaster
make installworld
shutdown -r now

dd if=/dev/zero of=/dev/ad6 bs=512 count=32

zpool create tank ad6
zfs create tank/usr
zfs create tank/var
zfs create -V 4gb tank/swap
zfs set org.freebsd:swap=on tank/swap
zpool set bootfs=tank tank

rsync -avx / /tank
rsync -avx /usr/ /tank/usr
rsync -avx /var/ /tank/var
cd /usr/src
make installkernel KERNCONF=HEIDI DESTDIR=/tank

zpool export tank

dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1
dd if=/boot/zfsboot of=/dev/ad6 bs=512 skip=1 seek=1024

zpool import tank

zfs set mountpoint=legacy tank
zfs set mountpoint=/usr tank/usr
zfs set mountpoint=/var tank/var

shutdown -r now ...

at the 'mbr prompt' I pressed F5 (the second disk, ad6)
.. as written above, loader gets loaded (at this stage
I suppose it's the stuff dd't after block 1024?),
but kernel not found.

/usr/src/sys/i386/conf/HEIDI:
(among other things...):
options KVA_PAGES=512

(/tank)/boot/loader.conf:
vm.kmem_size=1024M
vm.kmem_size_max=1024M
vfs.zfs.arc_max=128M
vfs.zfs.vdev.cache.size=8M
vfs.root.mountfrom=zfs:tank

(/tank)/etc/fstab:
# DeviceMountpointFStypeOptionsDumpPass#
tank/zfsrw00
/dev/acd0/cdromcd9660ro,noauto00

/snap

any help is welcome... don't know where to go from here right now.

BTW: I can't stop thanking the team for the incredible
pace at which bugs are fixed these days!


Regards,

Lorenzo



On 26.05.2009, at 18:42, George Hartzell wrote:


Andriy Gapon writes:

on 26/05/2009 19:21 George Hartzell said the following:

Dmitry Morozovsky writes:

On Tue, 26 May 2009, Mickael MAILLOT wrote:

MM Hi,
MM
MM i prefere use zfsboot boot sector, an example is better than a 
long talk:

MM
MM $ zpool create tank mirror ad4 ad6
MM $ zpool export tank
MM $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1
MM $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1
MM $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 skeep=1  seek=1024
MM $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 skeep=1  seek=1024

s/skeep/skip/ ? ;-)


What is the reason for copying zfsboot one bit at a time, as opposed
to

 dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=2


seek=1024 for the second part? and no 'count=1' for it? :-)

[Just guessing] Apparently the first block of zfsboot is some form of 
MBR and the

rest is zfs-specific code that goes to magical sector 1024.


Ok, I managed to read the argument to seek as one block, apparently
my coffee hasn't hit yet.

I'm still confused about the two parts of zfsboot and what's magical
about seeking to 1024.

g.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org



/boot/loader can't load kernel if too many pool/devices

2009-06-01 Thread Henri Hennebert

Hello,

During my tests (succesful) to directly boot from ZFS (with zfsboot and 
gptzfsboot) I encounter the error can't boot 'kernel' if too many 
devices/pools are connected to the machine. In my case:


2 SAS disks with 2 pools
2 SATA disks with 2 pools
1 USB key with one pool

`heap` command:

Active Allocations: 171/173
536576 bytes reserved 527800 bytes allocated

`ls` command:

open '/' failed: too many open files

If I reboot without the USB key all is OK.

If I reboot from the USB key after disconnecting 2 disks all is OK.

By the way, the /boot/loader in 7.2-STABLE don't work, complains about 
forth not found.


The previous tests were made with 7.2-STABLE (May 31) with /boot/loader 
from 8.0-CURRENT.


Henri
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: ZFS booting without partitions

2009-06-01 Thread Henri Hennebert

Henri Hennebert wrote:

Lorenzo Perone wrote:

Hi,

I tried hard... but without success ;(

the result is, when choosing the disk with the zfs boot
sectors in it (in my case F5, which goes to ad6), the kernel
is not found. the console shows:

forth not found
definitions not found
only not found
(the above repeated several times)


This is the file /boot/loader from 7.2-STABLE which is wrong.

You can find a copy from 8.0-CURRENT and a script that I tested on a USB 
key) and is running for me:


http://verbier.restart.be/xfer/boot-zfs/

Put this directory somewhere, eg /tmp/boot-zfs

and run the script eg:
`cd /tmp/boot-zfs  sh -x make_usb_key.sh da6 kingston`

good luck


CAVEAT:

The script put tuning in '/boot/loader.conf' wich imply options 
 KVA_PAGES=384 in my i386 kernel.


Henri



Henri


can't load 'kernel'

and I get thrown to the loader prompt.
lsdev does not show any ZFS devices.

Strange thing: if I boot from the other disk, F1, which is my
ad4 containing the normal ufs system I used to make up the other
one, and escape to the loader prompt, lsdev actually sees the
zpool which is on the other disk, and shows:
zfs0: tank

I tried booting with boot zfs:tank or zfs:tank:/boot/kernel/kernel,
but there I get the panic: free: guard1 fail message.
(would boot zfs:tank:/boot/kernel/kernel be correct, anyways?)

Sure I'm doing something wrong, but what...? Is it a problem that
the pool is made out of the second disk only (ad6)?

Here are my details (note: latest stable and biosdisk.c merged
with changes shown in r185095. no problems in buildworld/kernel):

snip

Machine: p4 4GHz 4 GB RAM (i386)

Note: the pool has actually a different name (heidi
instead of tank, if this can be of any relevance...),
just using tank here as it's one of the conventions...

mount (just to show my starting situation)

/dev/mirror/gm0s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/mirror/gm0s1e on /tmp (ufs, local, soft-updates)
/dev/mirror/gm0s1f on /usr (ufs, local, soft-updates)
/dev/mirror/gm0s1d on /var (ufs, local, soft-updates)

gmirror status
  NameStatus  Components
mirror/gm0  DEGRADED  ad4
(ad6 used to be the second disk...)

echo 'LOADER_ZFS_SUPPORT=yes'  /etc/make.conf

cd /usr/src
make buildworld  make buildkernel KERNCONF=HEIDI
make installkernel KERNCONF=HEIDI
mergemaster
make installworld
shutdown -r now

dd if=/dev/zero of=/dev/ad6 bs=512 count=32

zpool create tank ad6
zfs create tank/usr
zfs create tank/var
zfs create -V 4gb tank/swap
zfs set org.freebsd:swap=on tank/swap
zpool set bootfs=tank tank

rsync -avx / /tank
rsync -avx /usr/ /tank/usr
rsync -avx /var/ /tank/var
cd /usr/src
make installkernel KERNCONF=HEIDI DESTDIR=/tank

zpool export tank

dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1
dd if=/boot/zfsboot of=/dev/ad6 bs=512 skip=1 seek=1024

zpool import tank

zfs set mountpoint=legacy tank
zfs set mountpoint=/usr tank/usr
zfs set mountpoint=/var tank/var

shutdown -r now ...

at the 'mbr prompt' I pressed F5 (the second disk, ad6)
.. as written above, loader gets loaded (at this stage
I suppose it's the stuff dd't after block 1024?),
but kernel not found.

/usr/src/sys/i386/conf/HEIDI:
(among other things...):
options KVA_PAGES=512

(/tank)/boot/loader.conf:
vm.kmem_size=1024M
vm.kmem_size_max=1024M
vfs.zfs.arc_max=128M
vfs.zfs.vdev.cache.size=8M
vfs.root.mountfrom=zfs:tank

(/tank)/etc/fstab:
# DeviceMountpointFStypeOptionsDumpPass#
tank/zfsrw00
/dev/acd0/cdromcd9660ro,noauto00

/snap

any help is welcome... don't know where to go from here right now.

BTW: I can't stop thanking the team for the incredible
pace at which bugs are fixed these days!


Regards,

Lorenzo



On 26.05.2009, at 18:42, George Hartzell wrote:


Andriy Gapon writes:

on 26/05/2009 19:21 George Hartzell said the following:

Dmitry Morozovsky writes:

On Tue, 26 May 2009, Mickael MAILLOT wrote:

MM Hi,
MM
MM i prefere use zfsboot boot sector, an example is better than a 
long talk:

MM
MM $ zpool create tank mirror ad4 ad6
MM $ zpool export tank
MM $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=1
MM $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 count=1
MM $ dd if=/boot/zfsboot of=/dev/ad4 bs=512 skeep=1  seek=1024
MM $ dd if=/boot/zfsboot of=/dev/ad6 bs=512 skeep=1  seek=1024

s/skeep/skip/ ? ;-)


What is the reason for copying zfsboot one bit at a time, as opposed
to

 dd if=/boot/zfsboot of=/dev/ad4 bs=512 count=2


seek=1024 for the second part? and no 'count=1' for it? :-)

[Just guessing] Apparently the first block of zfsboot is some form 
of MBR and the

rest is zfs-specific code that goes to magical sector 1024.


Ok, I managed to read the argument to seek as one block, apparently
my coffee hasn't hit yet.

I'm still confused about the two parts of zfsboot and what's magical
about seeking to 1024.

g.

___
freebsd-stable@freebsd.org mailing list

Re: ZFS booting without partitions

2009-06-01 Thread Alberto Villa
On Mon, Jun 1, 2009 at 12:06 PM, Henri Hennebert h...@restart.be wrote:
 This is the file /boot/loader from 7.2-STABLE which is wrong.

 You can find a copy from 8.0-CURRENT and a script that I tested on a USB
 key) and is running for me:

replacing /boot/loader with yours did the job
thanks!
-- 
Alberto Villa villa.albe...@gmail.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: ZFS booting without partitions

2009-06-01 Thread Kip Macy
Odds are that there are more changes that were made in HEAD to the
loader that need to be MFC'd.

-Kip

On Mon, Jun 1, 2009 at 3:55 AM, Alberto Villa villa.albe...@gmail.com wrote:
 On Mon, Jun 1, 2009 at 12:06 PM, Henri Hennebert h...@restart.be wrote:
 This is the file /boot/loader from 7.2-STABLE which is wrong.

 You can find a copy from 8.0-CURRENT and a script that I tested on a USB
 key) and is running for me:

 replacing /boot/loader with yours did the job
 thanks!
 --
 Alberto Villa villa.albe...@gmail.com
 ___
 freebsd-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org




-- 
When bad men combine, the good must associate; else they will fall one
by one, an unpitied sacrifice in a contemptible struggle.

Edmund Burke
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: libzpool assert vs libc assert

2009-06-01 Thread Andriy Gapon
on 29/05/2009 15:35 Andriy Gapon said the following:
 So anyone else feels that this is a bug?
 
 on 28/05/2009 16:55 Andriy Gapon said the following:
 on 28/05/2009 16:26 Henri Hennebert said the following:
 (gdb) bt
 #0  0x0008012a6f22 in strlen () from /lib/libc.so.7
 #1  0x0008012a0feb in open () from /lib/libc.so.7
 #2  0x00080129ea59 in open () from /lib/libc.so.7
 #3  0x0008012a1f2e in vfprintf () from /lib/libc.so.7
 #4  0x000801291158 in fprintf () from /lib/libc.so.7
 #5  0x000801290fb0 in __assert () from /lib/libc.so.7
 I find the above part interesting.
 Could this be because of the following discrepancy:

 1)
 cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:
 extern void __assert(const char *, const char *, int);
 2)
 lib/libc/gen/assert.c:
 void
 __assert(func, file, line, failedexpr)
 const char *func, *file;
 int line;
 const char *failedexpr;

 #6  0x000800fef120 in zmutex_destroy () from /lib/libzpool.so.1
 #7  0x00080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1
 #8  0x000801045ffa in dbuf_find () from /lib/libzpool.so.1
 #9  0x000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1
 #10 0x000801027546 in dsl_pool_open () from /lib/libzpool.so.1
 #11 0x00080101bcec in spa_create () from /lib/libzpool.so.1
 #12 0x00080101c820 in spa_tryimport () from /lib/libzpool.so.1

I propose the following patch for this issue.
It fixes mismatch between __assert extern declaration in zfs code and actual
signature in libc code.
I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. I think 
that
those checks are not needed with compilers that can be used to compile FreeBSD.
Besides, both branches of __STDC_VERSION__ check were exactly the same.

Henri,

if you still experience that crash of zpool command, could you please try the
patch and see if you have a nicer assert message and stacktrace now?
Sorry, that this is still not a fix for the real issue.

diff --git a/cddl/contrib/opensolaris/head/assert.h
b/cddl/contrib/opensolaris/head/assert.h
index 394820a..c2a4936 100644
--- a/cddl/contrib/opensolaris/head/assert.h
+++ b/cddl/contrib/opensolaris/head/assert.h
@@ -37,15 +37,7 @@
 extern C {
 #endif

-#if defined(__STDC__)
-#if __STDC_VERSION__ - 0 = 199901L
-extern void __assert(const char *, const char *, int);
-#else
-extern void __assert(const char *, const char *, int);
-#endif /* __STDC_VERSION__ - 0 = 199901L */
-#else
-extern void _assert();
-#endif
+extern void __assert(const char *, const char *, int, const char *);

 #ifdef __cplusplus
 }
@@ -68,14 +60,6 @@ extern void _assert();

 #else

-#if defined(__STDC__)
-#if __STDC_VERSION__ - 0 = 199901L
-#defineassert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 
0))
-#else
-#defineassert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 
0))
-#endif /* __STDC_VERSION__ - 0 = 199901L */
-#else
-#defineassert(EX) (void)((EX) || (_assert(EX, __FILE__, __LINE__), 
0))
-#endif /* __STDC__ */
+#defineassert(EX) (void)((EX) || (__assert(__func__, __FILE__, 
__LINE__, #EX), 0))

 #endif /* NDEBUG */
diff --git a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h
b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h
index 7ae7f9d..631e302 100644
--- a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h
+++ b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h
@@ -120,21 +120,12 @@ extern void vpanic(const char *, __va_list);
 #definefm_panicpanic

 /* This definition is copied from assert.h. */
-#if defined(__STDC__)
-#if __STDC_VERSION__ - 0 = 199901L
-#defineverify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 
0))
-#else
-#defineverify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 
0))
-#endif /* __STDC_VERSION__ - 0 = 199901L */
-#else
-#defineverify(EX) (void)((EX) || (_assert(EX, __FILE__, __LINE__), 
0))
-#endif /* __STDC__ */
-
+#defineverify(EX) (void)((EX) || (__assert(__func__, __FILE__, 
__LINE__, #EX), 0))

 #defineVERIFY  verify
 #defineASSERT  assert

-extern void __assert(const char *, const char *, int);
+extern void __assert(const char *, const char *, int, const char *);

 #ifdef lint
 #defineVERIFY3_IMPL(x, y, z, t)if (x == z) ((void)0)
@@ -148,7 +139,7 @@ extern void __assert(const char *, const char *, int);
(void) snprintf(__buf, 256, %s %s %s (0x%llx %s 0x%llx), \
#LEFT, #OP, #RIGHT, \
(u_longlong_t)__left, #OP, (u_longlong_t)__right); \
-   __assert(__buf, __FILE__, __LINE__); \
+   __assert(__func__, __FILE__, __LINE__, __buf); \
} \
 _NOTE(CONSTCOND) } while (0)
 /* END CSTYLED */


-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list

Unnamed POSIX shared semaphores

2009-06-01 Thread Vlad Galu
Hello,

According to sem_init(3), we can't have shared unnamed semaphores.
However, the following code snippet seems to work just  fine:

-- cut here --
sem_t semaphore;
if (sem_init(semaphore, 1, 10)  0)
std::cout  Couldn't init semaphore:  
strerror(errno)  std::endl;
if (sem_wait(semaphore)  0)
std::cout  Couldn't decrement semaphore:  
strerror(errno)  std::endl;
int val;
sem_getvalue(semaphore, val);
std::cout  Value is   val  std::endl;
-- and here --

Is this a case where sem_init() silently reports success, or should be
the man page get an update?

Thanks,
Vlad
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Unnamed POSIX shared semaphores

2009-06-01 Thread cpghost
On Mon, Jun 01, 2009 at 06:33:42PM +0300, Vlad Galu wrote:
 Hello,
 
 According to sem_init(3), we can't have shared unnamed semaphores.
 However, the following code snippet seems to work just  fine:
 
 -- cut here --
 sem_t semaphore;
 if (sem_init(semaphore, 1, 10)  0)
 std::cout  Couldn't init semaphore:  
 strerror(errno)  std::endl;
 if (sem_wait(semaphore)  0)
 std::cout  Couldn't decrement semaphore:  
 strerror(errno)  std::endl;
 int val;
 sem_getvalue(semaphore, val);
 std::cout  Value is   val  std::endl;
 -- and here --
 
 Is this a case where sem_init() silently reports success, or should be
 the man page get an update?

You may want to read the comments in /usr/src/lib/libc/gen/sem.c
regarding sem_init().

But yes, the man page is somewhat unclear and I'm not sure the last
paragraph is still totally accurate.

 Thanks,
 Vlad

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: libzpool assert vs libc assert

2009-06-01 Thread Henri Hennebert

Andriy Gapon wrote:

on 29/05/2009 15:35 Andriy Gapon said the following:

So anyone else feels that this is a bug?

on 28/05/2009 16:55 Andriy Gapon said the following:

on 28/05/2009 16:26 Henri Hennebert said the following:

(gdb) bt
#0  0x0008012a6f22 in strlen () from /lib/libc.so.7
#1  0x0008012a0feb in open () from /lib/libc.so.7
#2  0x00080129ea59 in open () from /lib/libc.so.7
#3  0x0008012a1f2e in vfprintf () from /lib/libc.so.7
#4  0x000801291158 in fprintf () from /lib/libc.so.7
#5  0x000801290fb0 in __assert () from /lib/libc.so.7

I find the above part interesting.
Could this be because of the following discrepancy:

1)
cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:
extern void __assert(const char *, const char *, int);
2)
lib/libc/gen/assert.c:
void
__assert(func, file, line, failedexpr)
const char *func, *file;
int line;
const char *failedexpr;


#6  0x000800fef120 in zmutex_destroy () from /lib/libzpool.so.1
#7  0x00080102e1a0 in dsl_dataset_fast_stat () from /lib/libzpool.so.1
#8  0x000801045ffa in dbuf_find () from /lib/libzpool.so.1
#9  0x000801047bf3 in dmu_buf_rele () from /lib/libzpool.so.1
#10 0x000801027546 in dsl_pool_open () from /lib/libzpool.so.1
#11 0x00080101bcec in spa_create () from /lib/libzpool.so.1
#12 0x00080101c820 in spa_tryimport () from /lib/libzpool.so.1


I propose the following patch for this issue.
It fixes mismatch between __assert extern declaration in zfs code and actual
signature in libc code.
I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks. I think 
that
those checks are not needed with compilers that can be used to compile FreeBSD.
Besides, both branches of __STDC_VERSION__ check were exactly the same.

Henri,

if you still experience that crash of zpool command, could you please try the
patch and see if you have a nicer assert message and stacktrace now?
Sorry, that this is still not a fix for the real issue.

diff --git a/cddl/contrib/opensolaris/head/assert.h
b/cddl/contrib/opensolaris/head/assert.h
index 394820a..c2a4936 100644
--- a/cddl/contrib/opensolaris/head/assert.h
+++ b/cddl/contrib/opensolaris/head/assert.h
@@ -37,15 +37,7 @@
 extern C {
 #endif

-#if defined(__STDC__)
-#if __STDC_VERSION__ - 0 = 199901L
-extern void __assert(const char *, const char *, int);
-#else
-extern void __assert(const char *, const char *, int);
-#endif /* __STDC_VERSION__ - 0 = 199901L */
-#else
-extern void _assert();
-#endif
+extern void __assert(const char *, const char *, int, const char *);

 #ifdef __cplusplus
 }
@@ -68,14 +60,6 @@ extern void _assert();

 #else

-#if defined(__STDC__)
-#if __STDC_VERSION__ - 0 = 199901L
-#defineassert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 
0))
-#else
-#defineassert(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 
0))
-#endif /* __STDC_VERSION__ - 0 = 199901L */
-#else
-#defineassert(EX) (void)((EX) || (_assert(EX, __FILE__, __LINE__), 
0))
-#endif /* __STDC__ */
+#defineassert(EX) (void)((EX) || (__assert(__func__, __FILE__, 
__LINE__, #EX), 0))

 #endif /* NDEBUG */
diff --git a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h
b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h
index 7ae7f9d..631e302 100644
--- a/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h
+++ b/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h
@@ -120,21 +120,12 @@ extern void vpanic(const char *, __va_list);
 #definefm_panicpanic

 /* This definition is copied from assert.h. */
-#if defined(__STDC__)
-#if __STDC_VERSION__ - 0 = 199901L
-#defineverify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 
0))
-#else
-#defineverify(EX) (void)((EX) || (__assert(#EX, __FILE__, __LINE__), 
0))
-#endif /* __STDC_VERSION__ - 0 = 199901L */
-#else
-#defineverify(EX) (void)((EX) || (_assert(EX, __FILE__, __LINE__), 
0))
-#endif /* __STDC__ */
-
+#defineverify(EX) (void)((EX) || (__assert(__func__, __FILE__, 
__LINE__, #EX), 0))

 #defineVERIFY  verify
 #defineASSERT  assert

-extern void __assert(const char *, const char *, int);
+extern void __assert(const char *, const char *, int, const char *);

 #ifdef lint
 #defineVERIFY3_IMPL(x, y, z, t)if (x == z) ((void)0)
@@ -148,7 +139,7 @@ extern void __assert(const char *, const char *, int);
(void) snprintf(__buf, 256, %s %s %s (0x%llx %s 0x%llx), \
#LEFT, #OP, #RIGHT, \
(u_longlong_t)__left, #OP, (u_longlong_t)__right); \
-   __assert(__buf, __FILE__, __LINE__); \
+   __assert(__func__, __FILE__, __LINE__, __buf); \
} \
 _NOTE(CONSTCOND) } while (0)
 /* END CSTYLED */



Here is the new bt after the patch

[r...@avoriaz libzpool]# gdb zdb
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is 

Re: Unnamed POSIX shared semaphores

2009-06-01 Thread Jilles Tjoelker
On Mon, Jun 01, 2009 at 06:33:42PM +0300, Vlad Galu wrote:
 According to sem_init(3), we can't have shared unnamed semaphores.
 However, the following code snippet seems to work just  fine:

 -- cut here --
 sem_t semaphore;
 if (sem_init(semaphore, 1, 10)  0)
 std::cout  Couldn't init semaphore:  
 strerror(errno)  std::endl;
 if (sem_wait(semaphore)  0)
 std::cout  Couldn't decrement semaphore:  
 strerror(errno)  std::endl;
 int val;
 sem_getvalue(semaphore, val);
 std::cout  Value is   val  std::endl;
 -- and here --

 Is this a case where sem_init() silently reports success, or should be
 the man page get an update?

Reading the code, it seems like this should work, but only between
related processes where the parent process creates the semaphore before
forking and no exec is done. This is because a sem_t is a pointer to a
structure containing the kernel level semid_t (and a mutex, condvar and
the like for process-private semaphores). sem_init() will allocate this
structure using malloc(3).

Changing sem_t to be a structure would be the obvious way to fix this,
but I think this cannot be versioned properly. For example, if someone
puts in the public header file of their .so:

struct my_struct
{
int foo;
sem_t bar;
int quux;
};

Changing the size of sem_t will break this. Also, assuming symbol
versioning were to be used, if you compile the .so for FreeBSD 7 and the
app for FreeBSD 8, the FreeBSD 8 sem_* functions will get FreeBSD 7
style sem_t's.

If process-shared semaphores really work, then the above structure is
not a pathological case. Effectively, sem_t is carved in stone. So
process-private semaphores should continue to have most of their stuff
in a separately allocated structure, to preserve flexibility.

Perhaps a better method is to set bit 0 of the sem_t to 1 and use the
other bits to store the semid_t.

-- 
Jilles Tjoelker
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: libzpool assert vs libc assert

2009-06-01 Thread Andriy Gapon
on 01/06/2009 19:12 Henri Hennebert said the following:
 Andriy Gapon wrote:
 I propose the following patch for this issue.
 It fixes mismatch between __assert extern declaration in zfs code and
 actual
 signature in libc code.
 I also took liberty of dropping __STDC__ and __STDC_VERSION__ checks.
 I think that
 those checks are not needed with compilers that can be used to compile
 FreeBSD.
 Besides, both branches of __STDC_VERSION__ check were exactly the same.

 Henri,

 if you still experience that crash of zpool command, could you please
 try the
 patch and see if you have a nicer assert message and stacktrace now?
 Sorry, that this is still not a fix for the real issue.

 Here is the new bt after the patch

Henri,

thank you very much for testing!
It look like the patch did its job.

P.S. hopefully someone is looking into the cause of the assertion.

 Assertion failed: (mp-m_owner == NULL), function zmutex_destroy, file
 /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c,
 line 112.
 
 Program received signal SIGABRT, Aborted.
 [Switching to Thread 0x8018020b0 (LWP 100178)]
 0x00080121fadc in thr_kill () from /lib/libc.so.7
 (gdb) bt
 #0  0x00080121fadc in thr_kill () from /lib/libc.so.7
 #1  0x0008012af06b in abort () from /lib/libc.so.7
 #2  0x000801296fe5 in __assert () from /lib/libc.so.7
 #3  0x000800fef42e in zmutex_destroy (mp=0x8018b2cc0) at

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: ZFS booting without partitions (was: ZFS boot on zfs mirror)

2009-06-01 Thread Lorenzo Perone

On 31.05.2009, at 09:18, Adam McDougall wrote:


I encountered the same symptoms today on both a 32bit and 64bit
brand new install using gptzfsboot.  It works for me when I use
a copy of loader from an 8-current box with zfs support compiled in.
I haven't looked into it much yet but it might help you.  If you
want, you can try the loader I am using from:
http://www.egr.msu.edu/~mcdouga9/loader



Hi, thanx a lot for this hint. Meanwhile, I was almost giving up,
and had a try with ZFS on Root with GPT partitioning, using
gptzfsboot as the bootloader, a UFS root partition as boot
partition (gmirrored to both disks), and the rest (inclusive of a
zvol for swap!) on ZFS. This worked perfectly on the first try.
(if anyone is interested, I can post my commented command
series for that, but it's just a mix of the available tutorials on
the web..).

I'll be glad do give the zfs-only solution a new try.
Had the same impression, that the loader was involved in the
problem, but had no env at hand to build a -CURRENT right
away... (I did, in fact, repeat the dd-steps a zfsboot
bootloader from a recent 8- snapshot iso... with the results
being the same as before...).

Sidenote: I encountered a few panics when using rsync with the
HAX flags enabled (rsync -avxHAX from UFS to ZFS).
I'll try to figure out which one of the flags caused it...
(Hard links, ACLs, or eXtended attributes..).
Never had even the slightest problem with rsync -avx.

Thanx for posting me your loader,  I'll try with this tomorrow night!
(any hint, btw, on why the one in -STABLE seems to be
broken, or whether it has actually been fixed by now?)

Regards,
Lorenzo


(...)


2009/5/28 Lorenzo Perone:

Hi,

I tried hard... but without success ;(

the result is, when choosing the disk with the zfs boot
sectors in it (in my case F5, which goes to ad6), the kernel
is not found. the console shows:

forth not found
definitions not found
only not found
(the above repeated several times)

can't load 'kernel'

and I get thrown to the loader prompt.
lsdev does not show any ZFS devices.

(...)



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: ZFS booting without partitions

2009-06-01 Thread Adam McDougall
I'm thinking that too.  I spent some time taking stabs at figuring it 
out yesterday but didn't get anywhere useful.  I did try compiling the 
-current src/sys/boot tree on 7.2 after a couple header tweaks to make 
it compile but the loader still didn't work.  The working loader is the 
same file size as the broken loader unless it was compiled on i386 and 
then it is ~30k bigger for some reason (it shrinks to the same size as 
the rest if I force it to use the same 32bit compilation flags as used 
on amd64).  Just mentioning this in case it saves someone else some 
time.  I'm real pleased it works at all.


Kip Macy wrote:

Odds are that there are more changes that were made in HEAD to the
loader that need to be MFC'd.

-Kip

On Mon, Jun 1, 2009 at 3:55 AM, Alberto Villa villa.albe...@gmail.com wrote:
  

On Mon, Jun 1, 2009 at 12:06 PM, Henri Hennebert h...@restart.be wrote:


This is the file /boot/loader from 7.2-STABLE which is wrong.

You can find a copy from 8.0-CURRENT and a script that I tested on a USB
key) and is running for me:
  

replacing /boot/loader with yours did the job
thanks!
--
Alberto Villa villa.albe...@gmail.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org






  


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: buildworld fails with WITHOUT_CDDL=yes in src.conf

2009-06-01 Thread Claude Buisson

Daniel O'Connor wrote:

On Mon, 1 Jun 2009, Pavel Greenberg wrote:

Hello everybody!
After today's source update I have a problem when doing make
buildworld:

cc -O2 -fno-strict-aliasing -pipe -march=pentium4
-DLOADER_NFS_SUPPORT - DBOOT_FORTH
-I/usr/src/sys/boot/i386/loader/../../ficl -I/usr/src/sys/boot/
i386/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT
-DLOADER_GPT_SUPPORT -I/usr/ src/sys/boot/i386/loader/../../common
-I. -Wall -I/usr/src/sys/boot/i386/ loader/..
-I/usr/src/sys/boot/i386/loader/../btx/lib -ffreestanding -
mpreferred-stack-boundary=2  -mno-mmx -mno-3dnow -mno-sse -mno-sse2
-mno- sse3  -c
/usr/src/sys/boot/i386/loader/../../common/interp_forth.c make: don't
know how to make /usr/obj/usr/src/tmp/usr/lib/libzfs.a. Stop ***
Error code 2

Stop in /usr/src/sys/boot/i386.
*** Error code 1

Stop in /usr/src/sys/boot.
*** Error code 1

Stop in /usr/src/sys.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.

In my src.conf I have options
WITHOUT_CDDL=   true
WITHOUT_ZFS=true
because I don't use ZFS, my desktop haven't enought resources for it
and I want not to build it. When I updated my OS some weeks ago with
the same src.conf process ended OK.


While the above IS a bug it should be pointed out that unless you
actually load the ZFS kld it won't use any memory on your system.



Same here..

The first bug is the use of a LIBZFS variable in
src/sys/boot/i386/loader/Makefile, as this variable is set in
share/mk/bsd.libnames.mk

I just replaced LIBZFS by LIBZFSBOOT and the buildworld succeeded.

The second bug is the use of LOADER_ZFS_SUPPORT without any
consideration of WITHOUT_CDDL and/or WITHOUT_ZFS (or MK_ZFS)

I won't comment the it won't use any memory on your system..

Claude Buisson

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: ZFS booting without partitions

2009-06-01 Thread Enrico M.
On Monday 01 June 2009 12:06:18 Henri Hennebert wrote:
 Lorenzo Perone wrote:
  Hi,
 
  I tried hard... but without success ;(
 
  the result is, when choosing the disk with the zfs boot
  sectors in it (in my case F5, which goes to ad6), the kernel
  is not found. the console shows:
 
  forth not found
  definitions not found
  only not found
  (the above repeated several times)

 This is the file /boot/loader from 7.2-STABLE which is wrong.

 You can find a copy from 8.0-CURRENT and a script that I tested on a USB
 key) and is running for me:

 http://verbier.restart.be/xfer/boot-zfs/

Thanks!
I replaced /boot/loader with the file from your link.
Now the system boot.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Unnamed POSIX shared semaphores

2009-06-01 Thread Bruce Simpson

Jilles Tjoelker wrote:

If process-shared semaphores really work, then the above structure is
not a pathological case. Effectively, sem_t is carved in stone. So
process-private semaphores should continue to have most of their stuff
in a separately allocated structure, to preserve flexibility.
  


There was an inadvertent race in FreeBSD's POSIX semaphores which I 
fixed in HEAD and STABLE about 6 weeks before 7.2 was released.


I believe process-shared POSIX semaphores now work -- the Python 
'multiprocessing' regression test now runs to completion with no errors 
on both HEAD and STABLE.


cheers,
BMS
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: Unnamed POSIX shared semaphores

2009-06-01 Thread Daniel Eischen

On Mon, 1 Jun 2009, Bruce Simpson wrote:


Jilles Tjoelker wrote:

If process-shared semaphores really work, then the above structure is
not a pathological case. Effectively, sem_t is carved in stone. So
process-private semaphores should continue to have most of their stuff
in a separately allocated structure, to preserve flexibility.



There was an inadvertent race in FreeBSD's POSIX semaphores which I fixed in 
HEAD and STABLE about 6 weeks before 7.2 was released.


I believe process-shared POSIX semaphores now work -- the Python 
'multiprocessing' regression test now runs to completion with no errors on 
both HEAD and STABLE.


Process-shared semaphores, mutexes, etc, will never work
until their public types are structs, not pointers to
structs (i.e. allocated by our library functions).

The intrinsic *kernel* semaphore functions (ksem) supposedly
do support process-shared semantics, but our POSIX functions'
use of them cannot be shared across processes.

--
DE
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: ZFS booting without partitions

2009-06-01 Thread Kip Macy
On Mon, Jun 1, 2009 at 10:21 AM, Adam McDougall mcdou...@egr.msu.edu wrote:
 I'm thinking that too.  I spent some time taking stabs at figuring it out
 yesterday but didn't get anywhere useful.  I did try compiling the -current
 src/sys/boot tree on 7.2 after a couple header tweaks to make it compile but
 the loader still didn't work.  The working loader is the same file size as
 the broken loader unless it was compiled on i386 and then it is ~30k bigger
 for some reason (it shrinks to the same size as the rest if I force it to
 use the same 32bit compilation flags as used on amd64).  Just mentioning
 this in case it saves someone else some time.  I'm real pleased it works at
 all.

If someone has the time to track down the differences I'll MFC them.
I'm not using ZFS boot at the moment so I have no way of testing.

Cheers,
Kip
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


Re: buildworld fails with WITHOUT_CDDL=yes in src.conf

2009-06-01 Thread Kip Macy
 Same here..

 The first bug is the use of a LIBZFS variable in
 src/sys/boot/i386/loader/Makefile, as this variable is set in
 share/mk/bsd.libnames.mk

 I just replaced LIBZFS by LIBZFSBOOT and the buildworld succeeded.

 The second bug is the use of LOADER_ZFS_SUPPORT without any
 consideration of WITHOUT_CDDL and/or WITHOUT_ZFS (or MK_ZFS)

 I won't comment the it won't use any memory on your system..


I'll try get it fixed by Wednesday.

Thanks,
Kip
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org