Re: ZFS boot inside on the second partition inside a slice
On 06/16/2011 07:32, Zhihao Yuan wrote: I just redo everything, and changed the order of freebsd-zfs and freebsd-swap. The "Read error" still happens! Just a me too. Everything was working great with zfsboot from 8.2-RELEASE + a patch (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/153552). As I update to 8.2-STABLE after v28 MFC, I have to write a new zfsboot to be allowed to upgrade my pool. I get the "Read Error" after that. PS - same comfig, a netboot with windows7 on first partition - so I can't switch to gpt. Henri On Wed, Jun 15, 2011 at 8:07 PM, Zhihao Yuan wrote: On Wed, Jun 15, 2011 at 7:58 PM, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/15/11 17:42, Zhihao Yuan wrote: Hi, I configured my disk layout according to http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition But I swapped the order of the freebsd-zfs and freebsd-swap. The 4.0G freebsd-swap partition appears first inside the slice. After that, I write zfsboot on both ada0s2 and ada0s2b, but the boot0 gives me a "Read error". Where did your second slice start? There can be a lot of reasons why it gives Read error. After an NTFS partition of 12GB. This should be the problem with zfsboot, because if I use sysinstall to install a bootmgr, the boot gives me a "not UFS" error, which means the boot0 is done (am I right?). I personally recommend using GPT scheme instead of MBR, as you have a dedicated partition for gptzfsboot, which is much cleaner than this approach. Yeah, yeah, I agree. I should not plan to play Windows games. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJN+VUrAAoJEATO+BI/yjfBpksH/2ZswQ+ogdDpYwvhRIjJaqLs NEl8FtC2Ua+c3F2sNwrLK5a/fn/LL+jPAXndvuQdxOaz41Iqtnt8w1i9Dz5ATkva T+i0fnRVwXFqjrlRTWK+ODtNtrhI2/7ECAIfOOLNhaiJnPRrJJgvxJ6V5W+/N+l7 Lt4yMp6hGbhO/9Yp2UoaQuUThOTz+dKNZGECd1nLT+ooHbTPhBvjii080hHowNl6 Ef+JBaEng2NbRJPxYWrRwz6R7A44RDXvrKzn5w/TuUa+4fYrS25EZxygzIh3xjFX 2ILP25yabJ+Vw5o8bFCsJ3ExbEfq0PnfROHanRSdTjMDra27dGY9JZKyytE+Ykc= =D5+X -END PGP SIGNATURE- ___ 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" -- Zhihao Yuan, nickname lichray The best way to predict the future is to invent it. ___ 4BSD -- http://4bsd.biz/ ___ 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 boot inside on the second partition inside a slice
On 06/16/2011 19:35, John Baldwin wrote: On Thursday, June 16, 2011 8:45:41 am Zhihao Yuan wrote: Exactly. The MFCed ZFSv28 is different from any patch maintained by mm@. Maybe some untested changes involved. Can you try reverting this change: Author: jhb Date: Thu Apr 28 17:44:24 2011 New Revision: 221177 URL: http://svn.freebsd.org/changeset/base/221177 Log: Due to space constraints, the UFS boot2 and boot1 use an evil hack where boot2 calls back into boot1 to perform disk reads. The ZFS MBR boot blocks do not have the same space constraints, so remove this hack for ZFS. While here, remove commented out code to support C/H/S addressing from zfsldr. The ZFS and GPT bootstraps always just use EDD LBA addressing. MFC after:2 weeks Modified: head/sys/boot/i386/boot2/Makefile head/sys/boot/i386/common/drv.c head/sys/boot/i386/zfsboot/Makefile head/sys/boot/i386/zfsboot/zfsldr.S I will try this saturday! Thanks 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 boot inside on the second partition inside a slice
On 06/16/2011 19:35, John Baldwin wrote: > On Thursday, June 16, 2011 8:45:41 am Zhihao Yuan wrote: >> Exactly. The MFCed ZFSv28 is different from any patch maintained by >> mm@. Maybe some untested changes involved. > > Can you try reverting this change: > > Author: jhb > Date: Thu Apr 28 17:44:24 2011 > New Revision: 221177 > URL: http://svn.freebsd.org/changeset/base/221177 > > Log: > Due to space constraints, the UFS boot2 and boot1 use an evil hack where > boot2 calls back into boot1 to perform disk reads. The ZFS MBR boot blocks > do not have the same space constraints, so remove this hack for ZFS. > While here, remove commented out code to support C/H/S addressing from > zfsldr. The ZFS and GPT bootstraps always just use EDD LBA addressing. > > MFC after:2 weeks > > Modified: > head/sys/boot/i386/boot2/Makefile > head/sys/boot/i386/common/drv.c > head/sys/boot/i386/zfsboot/Makefile > head/sys/boot/i386/zfsboot/zfsldr.S > I try with this revision (221177) reverted to no avail: same error - 'read error' 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 boot inside on the second partition inside a slice
On 06/20/2011 15:51, John Baldwin wrote:
On Saturday, June 18, 2011 5:04:07 am Henri Hennebert wrote:
On 06/17/2011 19:37, John Baldwin wrote:
On Friday, June 17, 2011 1:06:22 pm Henri Hennebert wrote:
On 06/16/2011 19:35, John Baldwin wrote:
On Thursday, June 16, 2011 8:45:41 am Zhihao Yuan wrote:
Exactly. The MFCed ZFSv28 is different from any patch maintained by
mm@. Maybe some untested changes involved.
Can you try reverting this change:
Author: jhb
Date: Thu Apr 28 17:44:24 2011
New Revision: 221177
URL: http://svn.freebsd.org/changeset/base/221177
Log:
Due to space constraints, the UFS boot2 and boot1 use an evil hack where
boot2 calls back into boot1 to perform disk reads. The ZFS MBR boot blocks
do not have the same space constraints, so remove this hack for ZFS.
While here, remove commented out code to support C/H/S addressing from
zfsldr. The ZFS and GPT bootstraps always just use EDD LBA addressing.
MFC after:2 weeks
Modified:
head/sys/boot/i386/boot2/Makefile
head/sys/boot/i386/common/drv.c
head/sys/boot/i386/zfsboot/Makefile
head/sys/boot/i386/zfsboot/zfsldr.S
I try with this revision (221177) reverted to no avail:
same error - 'read error'
Hmm, ok. No other ideas off the top of my head.
I make the same test under virtualbox and get:
A critical error has occurred while running the virtual machine and the
machine execution has been stopped.
I attach VBox.log.
PS - the message 'ZFS: supported version 28' comes from my patch:
Index: sys/boot/zfs/zfsimpl.c
===
--- sys/boot/zfs/zfsimpl.c (revision 212549)
+++ sys/boot/zfs/zfsimpl.c (working copy)
@@ -61,6 +61,8 @@
STAILQ_INIT(&zfs_vdevs);
STAILQ_INIT(&zfs_pools);
+ printf("ZFS: supported version %u\n", (unsigned) SPA_VERSION);
+
zfs_temp_buf = malloc(TEMP_SIZE);
zfs_temp_end = zfs_temp_buf + TEMP_SIZE;
zfs_temp_ptr = zfs_temp_buf;
Hmm, can you add printfs and narrow down where the hang happens (or which
reads are failing)? The VBOX log seems to make no sense. It shows the
CPU trying to call into the BIOS from within protected mode in the loader
but that shouldn't ever happen (note a cs of 0x2b (which is the loader's
%cs selector) but an eip that looks like a cs:ip of a BIOS routine).
I just try to put printf but I get only 'Read error' without any of my
printf.
Previously event my printf in zfs_init don't show up on the console of
my netbook. Under VBox it was printed.
Maybe printf is not allowed so soon in zfsboot ?
For the record, I write the bootcode with this 2 commands after booting
with mfsbsd (from mm@) and fetching zfsboot in /tmp:
dd if=/tmp/zfsboot of=/dev/ad0s2a bs=512 count=1
dd if=/tmp/zfsboot of=/dev/ad0s2a bs=512 skip=1 seek=1024
My debugging patch in zfsboot.c:
[root@morzine zfsboot]# svn diff zfsboot.c
Index: zfsboot.c
===
--- zfsboot.c (revision 223081)
+++ zfsboot.c (working copy)
@@ -447,10 +447,16 @@
off_t off;
struct dsk *dsk;
+ printf("==>trying to boot\n");
+
dmadat = (void *)(roundup2(__base + (int32_t)&_end, 0x1) -
__base);
+ printf("==>about to call bios_getmem()\n");
+
bios_getmem();
+ printf("==>bios_getmem() completed\n");
+
if (high_heap_size > 0) {
heap_end = PTOV(high_heap_base + high_heap_size);
heap_next = PTOV(high_heap_base);
@@ -482,6 +488,8 @@
autoboot = 1;
+ printf("==>about to call zfs_init()\n");
+
zfs_init();
/*
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 boot inside on the second partition inside a slice
On 06/21/2011 15:01, John Baldwin wrote: Index: zfsldr.S === --- zfsldr.S(revision 223339) +++ zfsldr.S(working copy) @@ -234,9 +234,12 @@ nread.1: xor %ecx,%ecx # Get callw read # Read from disk lea 0x10(%bp),%sp # Clear stack jnc return # If success, return - mov $msg_read,%si # Otherwise, set the error - # message and fall through to - # the error routine + mov %ah,%al # Format + mov $read_err,%di # error + call hex8 # code + mov $msg_read,%si # Set the error message and + # fall through to the error + # routine /* * Print out the error message pointed to by %ds:(%si) followed * by a prompt, wait for a keypress, and then reboot the machine. @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si jmp error msg_chs: .asciz "CHS not supported" +/* + * Convert AL to hex, saving the result to [EDI]. + */ +hex8: push %ax# Save + shrb $0x4,%al # Do upper + call hex8.1 # 4 + pop %ax # Restore +hex8.1:andb $0xf,%al # Get lower 4 + cmpb $0xa,%al # Convert + sbbb $0x69,%al # to hex + das # digit + orb $0x20,%al # To lower case + stosb # Save char + ret # (Recursive) + /* Messages */ -msg_read: .asciz "Read" -msg_part: .asciz "Boot" +msg_read: .ascii "Read error: " +read_err: .asciz "XX" +msg_part: .asciz "Boot error" -prompt:.asciz " error\r\n" +prompt:.asciz "\r\n" .org PRT_OFF,0x90 I get Read error: 01 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 boot inside on the second partition inside a slice
On 06/21/2011 17:55, John Baldwin wrote: On Tuesday, June 21, 2011 10:50:14 am Henri Hennebert wrote: On 06/21/2011 15:01, John Baldwin wrote: Index: zfsldr.S === --- zfsldr.S(revision 223339) +++ zfsldr.S(working copy) @@ -234,9 +234,12 @@ nread.1: xor %ecx,%ecx # Get callw read # Read from disk lea 0x10(%bp),%sp # Clear stack jnc return # If success, return - mov $msg_read,%si # Otherwise, set the error - # message and fall through to - # the error routine + mov %ah,%al # Format + mov $read_err,%di # error + call hex8 # code + mov $msg_read,%si # Set the error message and + # fall through to the error + # routine /* * Print out the error message pointed to by %ds:(%si) followed * by a prompt, wait for a keypress, and then reboot the machine. @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si jmp error msg_chs: .asciz "CHS not supported" +/* + * Convert AL to hex, saving the result to [EDI]. + */ +hex8: push %ax# Save + shrb $0x4,%al # Do upper + call hex8.1 # 4 + pop %ax # Restore +hex8.1:andb $0xf,%al # Get lower 4 + cmpb $0xa,%al # Convert + sbbb $0x69,%al # to hex + das # digit + orb $0x20,%al # To lower case + stosb # Save char + ret # (Recursive) + /* Messages */ -msg_read: .asciz "Read" -msg_part: .asciz "Boot" +msg_read: .ascii "Read error: " +read_err: .asciz "XX" +msg_part: .asciz "Boot error" -prompt:.asciz " error\r\n" +prompt:.asciz "\r\n" .org PRT_OFF,0x90 I get Read error: 01 Hmm, that would be 'invalid parameter'. Can you add a 'foo: jmp foo' infinite loop and move it around to figure out which read call is failing? main.5: mov %dx,MEM_ARG # Save args movb $NSECT,%dh # Sector count movl $1024,%eax # Offset to boot2 callw nread.1 # Read disk foo:jmp foo After this one I get 'Read error: 01' 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 boot inside on the second partition inside a slice
On 06/21/2011 19:51, John Baldwin wrote: On Tuesday, June 21, 2011 12:15:58 pm Henri Hennebert wrote: On 06/21/2011 17:55, John Baldwin wrote: On Tuesday, June 21, 2011 10:50:14 am Henri Hennebert wrote: On 06/21/2011 15:01, John Baldwin wrote: Index: zfsldr.S === --- zfsldr.S(revision 223339) +++ zfsldr.S(working copy) @@ -234,9 +234,12 @@ nread.1: xor %ecx,%ecx # Get callw read # Read from disk lea 0x10(%bp),%sp # Clear stack jnc return # If success, return - mov $msg_read,%si # Otherwise, set the error - # message and fall through to - # the error routine + mov %ah,%al # Format + mov $read_err,%di # error + call hex8 # code + mov $msg_read,%si # Set the error message and + # fall through to the error + # routine /* * Print out the error message pointed to by %ds:(%si) followed * by a prompt, wait for a keypress, and then reboot the machine. @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si jmp error msg_chs:.asciz "CHS not supported" +/* + * Convert AL to hex, saving the result to [EDI]. + */ +hex8: push %ax# Save + shrb $0x4,%al # Do upper + call hex8.1 # 4 + pop %ax # Restore +hex8.1:andb $0xf,%al # Get lower 4 + cmpb $0xa,%al # Convert + sbbb $0x69,%al # to hex + das # digit + orb $0x20,%al # To lower case + stosb # Save char + ret # (Recursive) + /* Messages */ -msg_read: .asciz "Read" -msg_part: .asciz "Boot" +msg_read: .ascii "Read error: " +read_err: .asciz "XX" +msg_part: .asciz "Boot error" -prompt:.asciz " error\r\n" +prompt:.asciz "\r\n" .org PRT_OFF,0x90 I get Read error: 01 Hmm, that would be 'invalid parameter'. Can you add a 'foo: jmp foo' infinite loop and move it around to figure out which read call is failing? main.5: mov %dx,MEM_ARG # Save args movb $NSECT,%dh # Sector count movl $1024,%eax # Offset to boot2 callw nread.1 # Read disk foo:jmp foo After this one I get 'Read error: 01' Hmm, ok. NSECT changed in the MFC (it is now larger). Try this patch. It changes the code to read zfsboot in one sector at a time: I encounter 2 problems - see in you patch Henri Index: zfsldr.S === --- zfsldr.S(revision 223365) +++ zfsldr.S(working copy) @@ -16,7 +16,6 @@ */ /* Memory Locations */ - .set MEM_REL,0x700 # Relocation address .set MEM_ARG,0x900 # Arguments .set MEM_ORG,0x7c00 # Origin .set MEM_BUF,0x8000 # Load area @@ -91,26 +90,19 @@ main: cld # String ops inc mov %cx,%ss # Set up mov $start,%sp # stack /* - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets - * %cx == 0x100. - */ - mov %sp,%si # Source - mov $MEM_REL,%di# Destination - incb %ch# Word count - rep # Copy - movsw # code -/* * If we are on a hard drive, then load the MBR and look for the first * FreeBSD slice. We use the fake partition entry below that points to * the MBR when we call nread. The first pass looks for the first active * FreeBSD slice. The second pass looks for the first non-active FreeBSD * slice if the first one fails. */ - mov $part4,%si # Partition + mov $part4,%si # Dummy partition cmpb $0x80,%dl # Hard drive? jb main.4 # No - movb $0x1,%dh
Re: ZFS boot inside on the second partition inside a slice
On 06/21/2011 21:25, John Baldwin wrote: On Tuesday, June 21, 2011 3:02:28 pm Henri Hennebert wrote: On 06/21/2011 19:51, John Baldwin wrote: On Tuesday, June 21, 2011 12:15:58 pm Henri Hennebert wrote: On 06/21/2011 17:55, John Baldwin wrote: On Tuesday, June 21, 2011 10:50:14 am Henri Hennebert wrote: On 06/21/2011 15:01, John Baldwin wrote: Index: zfsldr.S === --- zfsldr.S(revision 223339) +++ zfsldr.S(working copy) @@ -234,9 +234,12 @@ nread.1: xor %ecx,%ecx # Get callw read # Read from disk lea 0x10(%bp),%sp # Clear stack jnc return # If success, return - mov $msg_read,%si # Otherwise, set the error - # message and fall through to - # the error routine + mov %ah,%al # Format + mov $read_err,%di # error + call hex8 # code + mov $msg_read,%si # Set the error message and + # fall through to the error + # routine /* * Print out the error message pointed to by %ds:(%si) followed * by a prompt, wait for a keypress, and then reboot the machine. @@ -296,12 +299,28 @@ read.1: mov $msg_chs,%si jmp error msg_chs: .asciz "CHS not supported" +/* + * Convert AL to hex, saving the result to [EDI]. + */ +hex8: push %ax# Save + shrb $0x4,%al # Do upper + call hex8.1 # 4 + pop %ax # Restore +hex8.1:andb $0xf,%al # Get lower 4 + cmpb $0xa,%al # Convert + sbbb $0x69,%al # to hex + das # digit + orb $0x20,%al # To lower case + stosb # Save char + ret # (Recursive) + /* Messages */ -msg_read: .asciz "Read" -msg_part: .asciz "Boot" +msg_read: .ascii "Read error: " +read_err: .asciz "XX" +msg_part: .asciz "Boot error" -prompt:.asciz " error\r\n" +prompt:.asciz "\r\n" .org PRT_OFF,0x90 I get Read error: 01 Hmm, that would be 'invalid parameter'. Can you add a 'foo: jmp foo' infinite loop and move it around to figure out which read call is failing? main.5: mov %dx,MEM_ARG # Save args movb $NSECT,%dh # Sector count movl $1024,%eax # Offset to boot2 callw nread.1 # Read disk foo:jmp foo After this one I get 'Read error: 01' Hmm, ok. NSECT changed in the MFC (it is now larger). Try this patch. It changes the code to read zfsboot in one sector at a time: I encounter 2 problems - see in you patch Henri Index: zfsldr.S === --- zfsldr.S(revision 223365) +++ zfsldr.S(working copy) @@ -16,7 +16,6 @@ */ /* Memory Locations */ - .set MEM_REL,0x700 # Relocation address .set MEM_ARG,0x900 # Arguments .set MEM_ORG,0x7c00 # Origin .set MEM_BUF,0x8000 # Load area @@ -91,26 +90,19 @@ main: cld # String ops inc mov %cx,%ss # Set up mov $start,%sp # stack /* - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets - * %cx == 0x100. - */ - mov %sp,%si # Source - mov $MEM_REL,%di# Destination - incb %ch# Word count - rep # Copy - movsw # code -/* * If we are on a hard drive, then load the MBR and look for the first * FreeBSD slice. We use the fake partition entry below that points to * the MBR when we call nread. The first pass looks for the first active * FreeBSD slice. The second pass looks for the first non-active FreeBSD * slice if the first one fails. */ - mov $part4,%si # Partition + mov $part4,%si # Dummy partition cmpb $0x80,%dl
Re: ZFS boot inside on the second partition inside a slice
On 06/21/2011 23:27, John Baldwin wrote: On Tuesday, June 21, 2011 4:13:20 pm Henri Hennebert wrote: On 06/21/2011 21:25, John Baldwin wrote: and I get: Read error: 04 Hmm, that is the error for an invalid sector. Try this patch. It reshuffles a few more things and adds code to dump the low 32-bits of the LBA on an error: Index: zfsldr.S === --- zfsldr.S(revision 223365) +++ zfsldr.S(working copy) @@ -16,7 +16,6 @@ */ /* Memory Locations */ - .set MEM_REL,0x700 # Relocation address .set MEM_ARG,0x900 # Arguments .set MEM_ORG,0x7c00 # Origin .set MEM_BUF,0x8000 # Load area @@ -91,26 +90,18 @@ main: cld # String ops inc mov %cx,%ss # Set up mov $start,%sp # stack /* - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets - * %cx == 0x100. - */ - mov %sp,%si # Source - mov $MEM_REL,%di# Destination - incb %ch# Word count - rep # Copy - movsw # code -/* * If we are on a hard drive, then load the MBR and look for the first * FreeBSD slice. We use the fake partition entry below that points to * the MBR when we call nread. The first pass looks for the first active * FreeBSD slice. The second pass looks for the first non-active FreeBSD * slice if the first one fails. */ - mov $part4,%si # Partition + mov $part4,%si # Dummy partition cmpb $0x80,%dl # Hard drive? jb main.4 # No - movb $0x1,%dh # Block count - callw nread # Read MBR + xor %eax,%eax # Read MBR + movw $MEM_BUF,%bx # from first + callw nread # sector mov $0x1,%cx# Two passes main.1: mov $MEM_BUF+PRT_OFF,%si# Partition table movb $0x1,%dh # Partition @@ -161,10 +152,16 @@ main.4: xor %dx,%dx # Partition:drive * area and target area do not overlap. */ main.5: mov %dx,MEM_ARG # Save args - movb $NSECT,%dh # Sector count + mov $NSECT,%cx # Sector count movl $1024,%eax # Offset to boot2 - callw nread.1 # Read disk -main.6:mov $MEM_BUF,%si# BTX (before reloc) + mov $MEM_BUF,%bx# Destination buffer +main.6:pushal # Save params + callw nread # Read disk + popal # Restore + incl %eax # Update for + add $SIZ_SEC,%bx# next sector + loop main.6 # If not last, read another + mov $MEM_BUF,%si# BTX (before reloc) mov 0xa(%si),%bx# Get BTX length and set mov $NSECT*SIZ_SEC-1,%di# Size of load area (less one) mov %di,%si # End of load @@ -214,29 +211,35 @@ seta20.3: sti # Enable interrupts * packet on the stack and passes it to read. * * %eax - int - LBA to read in relative to partition start + * %es:%bx - ptr - destination address * %dl- byte- drive to read from - * %dh - byte- num sectors to read * %si- ptr - MBR partition entry */ -nread: xor %eax,%eax # Sector offset in partition -nread.1: xor %ecx,%ecx # Get +nread: xor %ecx,%ecx # Get addl 0x8(%si),%eax # LBA adc $0,%ecx pushl %ecx # Starting absolute block pushl %eax # block number push %es# Address of - push $MEM_BUF # transfer buffer - xor %ax,%ax # Number of - movb %dh,%al# blocks to - push %ax# transfer + push %bx# transfer buffer + push $0x1 # Read 1 sector push
Re: ZFS boot inside on the second partition inside a slice
On 06/22/2011 16:19, Henri Hennebert wrote: On 06/22/2011 15:57, John Baldwin wrote: On Wednesday, June 22, 2011 7:34:05 am Henri Hennebert wrote: I get LBA: 8200 Read error: 04 Odd. Oh, I fubar'd and read the wrong thing for the sector. Also, we should leave the EDD packet on the stack so it doesn't get trashed by calling hex8, etc. Please try this: Index: zfsldr.S === --- zfsldr.S (revision 223365) +++ zfsldr.S (working copy) @@ -16,7 +16,6 @@ */ /* Memory Locations */ - .set MEM_REL,0x700 # Relocation address .set MEM_ARG,0x900 # Arguments .set MEM_ORG,0x7c00 # Origin .set MEM_BUF,0x8000 # Load area @@ -91,26 +90,18 @@ main: cld # String ops inc mov %cx,%ss # Set up mov $start,%sp # stack /* - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets - * %cx == 0x100. - */ - mov %sp,%si # Source - mov $MEM_REL,%di # Destination - incb %ch # Word count - rep # Copy - movsw # code -/* * If we are on a hard drive, then load the MBR and look for the first * FreeBSD slice. We use the fake partition entry below that points to * the MBR when we call nread. The first pass looks for the first active * FreeBSD slice. The second pass looks for the first non-active FreeBSD * slice if the first one fails. */ - mov $part4,%si # Partition + mov $part4,%si # Dummy partition cmpb $0x80,%dl # Hard drive? jb main.4 # No - movb $0x1,%dh # Block count - callw nread # Read MBR + xor %eax,%eax # Read MBR + movw $MEM_BUF,%bx # from first + callw nread # sector mov $0x1,%cx # Two passes main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table movb $0x1,%dh # Partition @@ -161,10 +152,16 @@ main.4: xor %dx,%dx # Partition:drive * area and target area do not overlap. */ main.5: mov %dx,MEM_ARG # Save args - movb $NSECT,%dh # Sector count + mov $NSECT,%cx # Sector count movl $1024,%eax # Offset to boot2 - callw nread.1 # Read disk -main.6: mov $MEM_BUF,%si # BTX (before reloc) + mov $MEM_BUF,%bx # Destination buffer +main.6: pushal # Save params + callw nread # Read disk + popal # Restore + incl %eax # Update for + add $SIZ_SEC,%bx # next sector + loop main.6 # If not last, read another + mov $MEM_BUF,%si # BTX (before reloc) mov 0xa(%si),%bx # Get BTX length and set mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) mov %di,%si # End of load @@ -214,29 +211,35 @@ seta20.3: sti # Enable interrupts * packet on the stack and passes it to read. * * %eax - int - LBA to read in relative to partition start + * %es:%bx - ptr - destination address * %dl - byte - drive to read from - * %dh - byte - num sectors to read * %si - ptr - MBR partition entry */ -nread: xor %eax,%eax # Sector offset in partition -nread.1: xor %ecx,%ecx # Get +nread: xor %ecx,%ecx # Get addl 0x8(%si),%eax # LBA adc $0,%ecx pushl %ecx # Starting absolute block pushl %eax # block number push %es # Address of - push $MEM_BUF # transfer buffer - xor %ax,%ax # Number of - movb %dh,%al # blocks to - push %ax # transfer + push %bx # transfer buffer + push $0x1 # Read 1 sector push $0x10 # Size of packet mov %sp,%bp # Packet pointer callw read # Read from disk + jc nread.1 # If error, fail lea 0x10(%bp),%sp # Clear stack - jnc return # If success, return - mov $msg_read,%si # Otherwise, set the error - # message and fall through to - # the error routine + ret # If success, return +nread.1: mov %ah,%al # Format + mov $read_err,%di # error + call hex8 # code + movl 0x8(%bp),%eax # Format + mov $lba,%di # LBA + call hex32 + mov $msg_lba,%si # Display + call putstr # LBA + mov $msg_read,%si # Set the error message and + # fall through to the error + # routine /* * Print out the error message pointed to by %ds:(%si) followed * by a prompt, wait for a keypress, and then reboot the machine. @@ -259,14 +262,6 @@ putstr: lodsb # Get char jne putstr.0 # No /* - * Overused return code. ereturn is used to return an error from the - * read function. Since we assume putstr succeeds, we (ab)use the - * same code when we return from putstr. - */ -ereturn: movb $0x1,%ah # Invalid - stc # argument -return: retw # To caller -/* * Reads sectors from the disk. If EDD is enabled, then check if it is * installed and use it if it is. If it is not installed or not enabled, then * fall back to using CHS. Since we use a LBA, if we are using CHS, we have to @@ -294,14 +289,38 @@ read: cmpb $0x80,%dl # Hard drive? retw # To caller read.1: mov $msg_chs,%si jmp error -msg_chs: .asciz "CHS not supported" +/* + * Convert EAX, AX, or AL to hex, saving the result to [EDI]. + */ +hex32: pushl %eax # Save + shrl $0x10,%eax # Do upper + call hex16 # 16 + popl %eax # Restore +hex16: call hex16.1 # Do upper 8 +hex16.1: xchgb %ah,%al # Save/restore +hex8: push %ax # Save + shrb $0x4,%al # Do upper + call hex8.1 # 4 + pop %ax # Restore +hex8.1: andb $0xf,%al # Get lower 4 + cmpb $0xa,%al # Convert + sbbb $0x69,%al # to hex + das # digit + orb $0x20,%al # To lower case + stosb # Save char + ret # (Recu
Re: ZFS boot inside on the second partition inside a slice
On 06/22/2011 15:57, John Baldwin wrote: On Wednesday, June 22, 2011 7:34:05 am Henri Hennebert wrote: I get LBA: 8200 Read error: 04 Odd. Oh, I fubar'd and read the wrong thing for the sector. Also, we should leave the EDD packet on the stack so it doesn't get trashed by calling hex8, etc. Please try this: Index: zfsldr.S === --- zfsldr.S(revision 223365) +++ zfsldr.S(working copy) @@ -16,7 +16,6 @@ */ /* Memory Locations */ - .set MEM_REL,0x700 # Relocation address .set MEM_ARG,0x900 # Arguments .set MEM_ORG,0x7c00 # Origin .set MEM_BUF,0x8000 # Load area @@ -91,26 +90,18 @@ main: cld # String ops inc mov %cx,%ss # Set up mov $start,%sp # stack /* - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets - * %cx == 0x100. - */ - mov %sp,%si # Source - mov $MEM_REL,%di# Destination - incb %ch# Word count - rep # Copy - movsw # code -/* * If we are on a hard drive, then load the MBR and look for the first * FreeBSD slice. We use the fake partition entry below that points to * the MBR when we call nread. The first pass looks for the first active * FreeBSD slice. The second pass looks for the first non-active FreeBSD * slice if the first one fails. */ - mov $part4,%si # Partition + mov $part4,%si # Dummy partition cmpb $0x80,%dl # Hard drive? jb main.4 # No - movb $0x1,%dh # Block count - callw nread # Read MBR + xor %eax,%eax # Read MBR + movw $MEM_BUF,%bx # from first + callw nread # sector mov $0x1,%cx# Two passes main.1: mov $MEM_BUF+PRT_OFF,%si# Partition table movb $0x1,%dh # Partition @@ -161,10 +152,16 @@ main.4: xor %dx,%dx # Partition:drive * area and target area do not overlap. */ main.5: mov %dx,MEM_ARG # Save args - movb $NSECT,%dh # Sector count + mov $NSECT,%cx # Sector count movl $1024,%eax # Offset to boot2 - callw nread.1 # Read disk -main.6:mov $MEM_BUF,%si# BTX (before reloc) + mov $MEM_BUF,%bx# Destination buffer +main.6:pushal # Save params + callw nread # Read disk + popal # Restore + incl %eax # Update for + add $SIZ_SEC,%bx# next sector + loop main.6 # If not last, read another + mov $MEM_BUF,%si# BTX (before reloc) mov 0xa(%si),%bx# Get BTX length and set mov $NSECT*SIZ_SEC-1,%di# Size of load area (less one) mov %di,%si # End of load @@ -214,29 +211,35 @@ seta20.3: sti # Enable interrupts * packet on the stack and passes it to read. * * %eax - int - LBA to read in relative to partition start + * %es:%bx - ptr - destination address * %dl- byte- drive to read from - * %dh - byte- num sectors to read * %si- ptr - MBR partition entry */ -nread: xor %eax,%eax # Sector offset in partition -nread.1: xor %ecx,%ecx # Get +nread: xor %ecx,%ecx # Get addl 0x8(%si),%eax # LBA adc $0,%ecx pushl %ecx # Starting absolute block pushl %eax # block number push %es# Address of - push $MEM_BUF # transfer buffer - xor %ax,%ax # Number of - movb %dh,%al# blocks to - push %ax# transfer + push %bx# transfer buffer + push $0x1 # Read 1 sector
Re: ZFS boot inside on the second partition inside a slice
On 06/22/2011 16:23, Henri Hennebert wrote: On 06/22/2011 16:19, Henri Hennebert wrote: On 06/22/2011 15:57, John Baldwin wrote: On Wednesday, June 22, 2011 7:34:05 am Henri Hennebert wrote: I get LBA: 8200 Read error: 04 Odd. Oh, I fubar'd and read the wrong thing for the sector. Also, we should leave the EDD packet on the stack so it doesn't get trashed by calling hex8, etc. Please try this: Index: zfsldr.S === --- zfsldr.S (revision 223365) +++ zfsldr.S (working copy) @@ -16,7 +16,6 @@ */ /* Memory Locations */ - .set MEM_REL,0x700 # Relocation address .set MEM_ARG,0x900 # Arguments .set MEM_ORG,0x7c00 # Origin .set MEM_BUF,0x8000 # Load area @@ -91,26 +90,18 @@ main: cld # String ops inc mov %cx,%ss # Set up mov $start,%sp # stack /* - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets - * %cx == 0x100. - */ - mov %sp,%si # Source - mov $MEM_REL,%di # Destination - incb %ch # Word count - rep # Copy - movsw # code -/* * If we are on a hard drive, then load the MBR and look for the first * FreeBSD slice. We use the fake partition entry below that points to * the MBR when we call nread. The first pass looks for the first active * FreeBSD slice. The second pass looks for the first non-active FreeBSD * slice if the first one fails. */ - mov $part4,%si # Partition + mov $part4,%si # Dummy partition cmpb $0x80,%dl # Hard drive? jb main.4 # No - movb $0x1,%dh # Block count - callw nread # Read MBR + xor %eax,%eax # Read MBR + movw $MEM_BUF,%bx # from first + callw nread # sector mov $0x1,%cx # Two passes main.1: mov $MEM_BUF+PRT_OFF,%si # Partition table movb $0x1,%dh # Partition @@ -161,10 +152,16 @@ main.4: xor %dx,%dx # Partition:drive * area and target area do not overlap. */ main.5: mov %dx,MEM_ARG # Save args - movb $NSECT,%dh # Sector count + mov $NSECT,%cx # Sector count movl $1024,%eax # Offset to boot2 - callw nread.1 # Read disk -main.6: mov $MEM_BUF,%si # BTX (before reloc) + mov $MEM_BUF,%bx # Destination buffer +main.6: pushal # Save params + callw nread # Read disk + popal # Restore + incl %eax # Update for + add $SIZ_SEC,%bx # next sector + loop main.6 # If not last, read another + mov $MEM_BUF,%si # BTX (before reloc) mov 0xa(%si),%bx # Get BTX length and set mov $NSECT*SIZ_SEC-1,%di # Size of load area (less one) mov %di,%si # End of load @@ -214,29 +211,35 @@ seta20.3: sti # Enable interrupts * packet on the stack and passes it to read. * * %eax - int - LBA to read in relative to partition start + * %es:%bx - ptr - destination address * %dl - byte - drive to read from - * %dh - byte - num sectors to read * %si - ptr - MBR partition entry */ -nread: xor %eax,%eax # Sector offset in partition -nread.1: xor %ecx,%ecx # Get +nread: xor %ecx,%ecx # Get addl 0x8(%si),%eax # LBA adc $0,%ecx pushl %ecx # Starting absolute block pushl %eax # block number push %es # Address of - push $MEM_BUF # transfer buffer - xor %ax,%ax # Number of - movb %dh,%al # blocks to - push %ax # transfer + push %bx # transfer buffer + push $0x1 # Read 1 sector push $0x10 # Size of packet mov %sp,%bp # Packet pointer callw read # Read from disk + jc nread.1 # If error, fail lea 0x10(%bp),%sp # Clear stack - jnc return # If success, return - mov $msg_read,%si # Otherwise, set the error - # message and fall through to - # the error routine + ret # If success, return +nread.1: mov %ah,%al # Format + mov $read_err,%di # error + call hex8 # code + movl 0x8(%bp),%eax # Format + mov $lba,%di # LBA + call hex32 + mov $msg_lba,%si # Display + call putstr # LBA + mov $msg_read,%si # Set the error message and + # fall through to the error + # routine /* * Print out the error message pointed to by %ds:(%si) followed * by a prompt, wait for a keypress, and then reboot the machine. @@ -259,14 +262,6 @@ putstr: lodsb # Get char jne putstr.0 # No /* - * Overused return code. ereturn is used to return an error from the - * read function. Since we assume putstr succeeds, we (ab)use the - * same code when we return from putstr. - */ -ereturn: movb $0x1,%ah # Invalid - stc # argument -return: retw # To caller -/* * Reads sectors from the disk. If EDD is enabled, then check if it is * installed and use it if it is. If it is not installed or not enabled, then * fall back to using CHS. Since we use a LBA, if we are using CHS, we have to @@ -294,14 +289,38 @@ read: cmpb $0x80,%dl # Hard drive? retw # To caller read.1: mov $msg_chs,%si jmp error -msg_chs: .asciz "CHS not supported" +/* + * Convert EAX, AX, or AL to hex, saving the result to [EDI]. + */ +hex32: pushl %eax # Save + shrl $0x10,%eax # Do upper + call hex16 # 16 + popl %eax # Restore +hex16: call hex16.1 # Do upper 8 +hex16.1: xchgb %ah,%al # Save/restore +hex8: push %ax # Save + shrb $0x4,%al # Do upper + call hex8.1 # 4 + pop %ax # Restore +hex8.1: andb $0xf,%al # Get lower 4 + cmpb $0xa,%al # Convert + sbbb $0x69,%al # to hex + das # digit + orb $0x20,%al # To lower
Re: ZFS boot inside on the second partition inside a slice
On 06/22/2011 17:58, John Baldwin wrote: Index: zfsldr.S === --- zfsldr.S(revision 223365) +++ zfsldr.S(working copy) @@ -16,7 +16,6 @@ */ /* Memory Locations */ - .set MEM_REL,0x700 # Relocation address .set MEM_ARG,0x900 # Arguments .set MEM_ORG,0x7c00 # Origin .set MEM_BUF,0x8000 # Load area @@ -91,26 +90,18 @@ main: cld # String ops inc mov %cx,%ss # Set up mov $start,%sp # stack /* - * Relocate ourself to MEM_REL. Since %cx == 0, the inc %ch sets - * %cx == 0x100. - */ - mov %sp,%si # Source - mov $MEM_REL,%di# Destination - incb %ch# Word count - rep # Copy - movsw # code -/* * If we are on a hard drive, then load the MBR and look for the first * FreeBSD slice. We use the fake partition entry below that points to * the MBR when we call nread. The first pass looks for the first active * FreeBSD slice. The second pass looks for the first non-active FreeBSD * slice if the first one fails. */ - mov $part4,%si # Partition + mov $part4,%si # Dummy partition cmpb $0x80,%dl # Hard drive? jb main.4 # No - movb $0x1,%dh # Block count - callw nread # Read MBR + xor %eax,%eax # Read MBR + movw $MEM_BUF,%bx # from first + callw nread # sector mov $0x1,%cx# Two passes main.1: mov $MEM_BUF+PRT_OFF,%si# Partition table movb $0x1,%dh # Partition @@ -143,32 +134,35 @@ main.4: xor %dx,%dx # Partition:drive * (i.e. after the two vdev labels). We don't have do anything fancy * here to allow for an extra copy of boot1 and a partition table * (compare to this section of the UFS bootstrap) so we just load it - * all at 0x8000. The first part of boot2 is BTX, which wants to run + * all at 0x9000. The first part of boot2 is BTX, which wants to run * at 0x9000. The boot2.bin binary starts right after the end of BTX, * so we have to figure out where the start of it is and then move the - * binary to 0xc000. After we have moved the client, we relocate BTX - * itself to 0x9000 - doing it in this order means that none of the - * memcpy regions overlap which would corrupt the copy. Normally, BTX - * clients start at MEM_USR, or 0xa000, but when we use btxld to - * create zfsboot2, we use an entry point of 0x2000. That entry point is - * relative to MEM_USR; thus boot2.bin starts at 0xc000. + * binary to 0xc000. Normally, BTX clients start at MEM_USR, or 0xa000, + * but when we use btxld to create zfsboot2, we use an entry point of + * 0x2000. That entry point is relative to MEM_USR; thus boot2.bin + * starts at 0xc000. * * The load area and the target area for the client overlap so we have * to use a decrementing string move. We also play segment register * games with the destination address for the move so that the client * can be larger than 16k (which would overflow the zero segment since - * the client starts at 0xc000). Relocating BTX is easy since the load - * area and target area do not overlap. + * the client starts at 0xc000). */ main.5: mov %dx,MEM_ARG # Save args - movb $NSECT,%dh # Sector count + mov $NSECT,%cx # Sector count movl $1024,%eax # Offset to boot2 - callw nread.1 # Read disk -main.6:mov $MEM_BUF,%si# BTX (before reloc) + mov $MEM_BTX,%bx# Destination buffer +main.6:pushal # Save params + callw nread # Read disk + popal # Restore + incl %eax # Update for + add $SIZ_SEC,%bx# next sector + loop main.6 # If not last, read another + mov $MEM_BTX,%si# BTX mov 0xa(%si),%bx# Get BTX length and set mov $NSECT*SIZ_SEC-1,%di# Size of load area (less one) mov %di,%si # End of load - add $MEM_BUF,%si# area +
Tripwire segmentation fault - amd64 - 9.0-RC2 in _malloc_postfork
Hello, On 2 systems running 9.0-RC2 amd64 tripwire segfault. The problem occurs during `tripwire --check` after +/- 20 minutes of execution: Here is the bt [root@tignes tripwire]# gdb ./tripwire GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) run --check Starting program: /usr/ports/security/tripwire/work/tripwire-2.4.1.2-src/src/tripwire/tripwire --check (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...Parsing policy file: /usr/local/etc/tripwire/tw.pol *** Processing Unix File System *** Performing integrity check... The object: "/var/spool/httpd/tignes/htdocs/Xfer/Henri_2006_11_24" is on a different file system...ignoring. Program received signal SIGSEGV, Segmentation fault. 0x0008014efb12 in _malloc_postfork () from /lib/libc.so.7 (gdb) bt #0 0x0008014efb12 in _malloc_postfork () from /lib/libc.so.7 #1 0x0008014ef158 in realloc () from /lib/libc.so.7 #2 0x0008014ef385 in free () from /lib/libc.so.7 #3 0x004c6181 in cFileUtil::IsRegularFile () #4 0x00499dbb in WriteObject () #5 0x0049c429 in cTWUtil::WriteReport () #6 0x0042709a in cTWModeIC::Execute () #7 0x0041cf85 in main () Under 9.0-RC1 I encounter no problem at all Henri PS - on another system under 9.0-RC2 i386 tripwire run smoothly ___ 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: libutempter
On 01/14/2012 09:47, Andre Goree wrote: > On Tue, 10 Jan 2012 19:58:13 -0600, Andre Goree wrote: > >> I recently csup'd 9-STABLE and was able to get it working along with my >> custom kernel. I'm now in the process of rebuilding all my ports, and >> I've >> come across something when running 'portmaster -af' that I can't seem to >> find any information on. >> >> ===>>> Launching child to reinstall libutempter-1.1.5_1 >> >> ===>>> Port directory: /usr/ports/sysutils/libutempter >> >> ===>>> This port is marked IGNORE >> ===>>> is now contained in the base system >> >> >> ===>>> If you are sure you can build it, remove the >>IGNORE line in the Makefile and try again. >> >> ===>>> Update for libutempter-1.1.5_1 failed >> ===>>> Aborting update >> >> Terminated >> >> >> I figure, "ok I'll just delete the package and move on." However, there >> are many packages I have installed that depend on libutemper. I would >> still just proceed with the removal given that the functionality is >> provided in base now, however I don't want to break all these ports and >> have to deal with the mess when I portmaster -af again. >> >> What is the recommended action here? Should I just force exclude that >> port >> from the upgrade? That's probably the easiest way but I'd have to deal >> with this at some point. >> >> Thanks in advance for any advice >> >> -- >> Andre Goree >> andre@drenetinfo > > So I've rebuilt everything that I could, but when I get to the ports > that depend on libutempter, I get an error that they could not be > reinstalled due to a failure with libutempter :/ > > ---> Skipping 'www/opera' (opera-11.60) because a requisite package > 'libutempter-1.1.5_1' (sysutils/libutempter) failed (specify -k to force) > ---> Skipping 'www/opera-linuxplugins' (opera-linuxplugins-11.60) > because a requisite package 'opera-11.60' (www/opera) failed (specify -k > to force) > ---> Skipping 'deskutils/kdeplasma-addons' (kdeplasma-addons-4.7.3) > because a requisite package 'kdepimlibs-4.7.3' (deskutils/kdepimlibs4) > failed (specify -k to force) > ---> Skipping 'graphics/libkdcraw-kde4' (libkdcraw-4.7.3) because a > requisite package 'libutempter-1.1.5_1' (sysutils/libutempter) failed > (specify -k to force) > > > I installed misc/compat8x, however it informed my that I'd need to add > "" to the kernel conf. When I try to do that, I'm met with this error: > > /usr/src/sys/amd64/conf/DESKTOPKERN9: unknown option "COMPAT_FREEBSD8" > *** Error code 1 > Stop in /usr/src. > > > Which is weird, because: > > [root@desktop src]# uname -r > 9.0-STABLE > > > Meaning I'm certainly running 9.0-STABLE. So what gives re: that error > above about "unknown option"? I even tried to csup source and > buildworld again, but to no avail -- the error remains. > > I upgrade my ports with portupgrade. After removing libutempter I just run `pkgdb -Fu' and then I can proceed with the update of depending ports. I don't need compat8x. 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: FreeBSD 9 & recompile ports
On 01/14/2012 09:46, Matthew Seaman wrote: > On 13/01/2012 22:57, Andriy Gapon wrote: >> But if the appropriate misc/compatX port is installed, then >> those libraries do actually exist and the system should be fully >> usable... Modulo the compat libraries not working with the new >> kernel as Kostik has pointed out. > > As soon as you update or install an application after this point, > you are likely to end up with an application that tries to > dynamically link two different versions of the same shlib, and > that is a recipe for tears-before-bedtime. This /etc/libmap.conf help me greatly when I reinstall all my ports after 9.0-BETA2 and make delete-old-libs: libsbuf.so.5libsbuf.so.6 libz.so.5 libz.so.6 libutil.so.8libutil.so.9 libcam.so.5 libcam.so.6 libpcap.so.7libpcap.so.8 libufs.so.5 libufs.so.6 libbsnmp.so.5 libbsnmp.so.6 libdwarf.so.2 libdwarf.so.3 libopie.so.6libopie.so.7 librtld_db.so.1 librtld_db.so.2 libtacplus.so.4 libtacplus.so.5 Henri > > Cheers, > > Matthew > ___ 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: FreeBSD 9 & recompile ports
On 01/14/2012 11:37, Jeremy Chadwick wrote: > On Sat, Jan 14, 2012 at 11:29:00AM +0100, Henri Hennebert wrote: >> On 01/14/2012 09:46, Matthew Seaman wrote: >>> On 13/01/2012 22:57, Andriy Gapon wrote: >>>> But if the appropriate misc/compatX port is installed, then >>>> those libraries do actually exist and the system should be fully >>>> usable... Modulo the compat libraries not working with the new >>>> kernel as Kostik has pointed out. >>> >>> As soon as you update or install an application after this point, >>> you are likely to end up with an application that tries to >>> dynamically link two different versions of the same shlib, and >>> that is a recipe for tears-before-bedtime. >> >> This /etc/libmap.conf help me greatly when I reinstall all my ports ---> >> after 9.0-BETA2 and make delete-old-libs: >> >> libsbuf.so.5 libsbuf.so.6 >> libz.so.5libz.so.6 >> libutil.so.8 libutil.so.9 >> libcam.so.5 libcam.so.6 >> libpcap.so.7 libpcap.so.8 >> libufs.so.5 libufs.so.6 >> libbsnmp.so.5libbsnmp.so.6 >> libdwarf.so.2libdwarf.so.3 >> libopie.so.6 libopie.so.7 >> librtld_db.so.1 librtld_db.so.2 >> libtacplus.so.4 libtacplus.so.5 > > This is very, VERY, ***VERY*** dangerous. Apparently nobody has > explained why, so I will: > > When a linked library version number (N of libfoo.so.N) increases or > changes, it indicates there are API/ABI changes to the library. There > is absolutely ZERO guarantee that calling semantics are the same, that > function arguments (thus stack order) are the same, or that structures > used internally by the library are the same. The effects of this can be > devastating -- if you're lucky it'll consist of just "missing symbol", > but it can be a lot worse. The TL;DR version is: there is absolutely > ZERO guarantee that the internal operations and calling semantics of the > libraries are identical. > > Folks reading this thread, PLEASE do not follow the above advice and > leave your system running in that kind of state. Instead of being lazy, I don't want to argue too much, but you don't read me correctly. I just do this during the time I REINSTALL ALL PORTS and then I delete /etc/libmap.conf, of course, I'm not crazy! > rebuild all your ports from scratch or pull down new binary copies > (pkg_add -r ...) for the version of the OS you're running. Doug and I > have the same opinion when it comes to this situation, and it's based > purely on experience. Schedule downtime, spend an afternoon rebuilding > things, whatever -- just do it the Right Way(tm) please. Otherwise > you're creating a lot of support hassle when it comes to trying to > diagnose why some program on your system "behaves oddly" -- weeks go by, > "oh, libmap.conf..." > ___ 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: strange system corruption (freebsd 9.0)
On 04/20/2012 18:38, Ingrid Ditra wrote: Hi, folks! I am in the middle of really creepy problem with my new FreeBSD box. I would appreciate any ideas about what the hell happened. I've installed FreeBSD 9.0 from CD on IBM System x3550 server (with RAID-5 on 4 hard drives) and moved on it the most of config's from my old FreeBSD (8.2) box, and everything seemed working fine for some days. Long story short, today I realised, that I can't login nether through ssh or console, some third-party soft doesn't work, and most of utilities from base system doesn't work too. My /usr/sbin and /usr/libdata are completely gone, /usr/libexec is empty, /usr/bin contains only dtrace dir and librt.so.1 many files from /usr/bin are gone, /usr/src contains only directory with my kernconf (there was all sources) and /usr/ports contains only ports I've installed. Time of access to all deleted or semi-deleted dirs is almost the same, Do you look carefully in /var/log/cron for this same time ? Another thought, give you filesystem layout. but I didn't find any weird actions in logs. First, I thought that portsnap (runned by cron) somehow corrupted my system, but it was executed like eight hours earlier. No one but me has access to this box, so it's unlikely mean joke. This system is connected to the internet ? http server ? if so check the logs So, please, please, help me. I really do not know what I suppose to do now. I can't find out why this happened, so it would be useless just reinstall system -- I'll have this situation again. All this stuff repeated twice Same time, day of the week ? -- so it is not kind of glitch (last time a cvsuped sources and ports and thought it was the reason of crash). Maybe I'm not helpful but you feel less lonely ... ___ 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: cvsup{, d} woes after upgrading to RELENG_9 on amd64 this weekend
On 06/04/2012 10:53, Trond Endrestøl wrote: Hi, After upgrading to RELENG_9 as of yesterday on my amd64 system, cvsup bombs out with Bus error: 10. Example: # /usr/local/bin/cvsup -g -L 2 /usr/src/stable-supfile Parsing supfile "/usr/src/stable-supfile" Connecting to localhost Connected to localhost Server software version: SNAP_16_1h Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Bus error: 10 The only recent change I can think of is switching to clang for building the kernel and base. Made I should rebuild world and kernel using gcc. This is the culprit, you must compile libc and libz with gcc. See http://www.freebsd.org/cgi/query-pr.cgi?pr=162588 Henri Today, I used portupgrade -fprv lang/ezm3 net/cvsup-without-gui, but cvsup gives me the same result as in the example above. This bug also affects cvsupd for those of us who are running a local FreeBSD CVSup mirror (http://motoyuki.bsdclub.org/BSD/cvsup.html) on amd64/RELENG_9. I know csup is generally preferred over cvsup, and in the meantime I'm able to use csup with another local FreeBSD CVSup mirror running on i386/RELENG_8. cvsup on the amd64 box crashes with Bus error even when accessing the CVSup mirror on the i386 box, thus indicating a problem local to the amd64 box. I welcome any clues to solve this problem. ___ 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: cvsup{, d} woes after upgrading to RELENG_9 on amd64 this weekend
On 06/05/2012 10:17, Scot Hetzel wrote:
On Mon, Jun 4, 2012 at 4:34 AM, Henri Hennebert wrote:
On 06/04/2012 10:53, Trond Endrestøl wrote:
Hi,
After upgrading to RELENG_9 as of yesterday on my amd64 system, cvsup
bombs out with Bus error: 10.
Example:
# /usr/local/bin/cvsup -g -L 2 /usr/src/stable-supfile
Parsing supfile "/usr/src/stable-supfile"
Connecting to localhost
Connected to localhost
Server software version: SNAP_16_1h
Negotiating file attribute support
Exchanging collection information
Establishing multiplexed-mode data connection
Running
Updating collection src-all/cvs
Bus error: 10
The only recent change I can think of is switching to clang for
building the kernel and base. Made I should rebuild world and kernel
using gcc.
This is the culprit, you must compile libc and libz with gcc.
See http://www.freebsd.org/cgi/query-pr.cgi?pr=162588
make.conf snipet from PR 162588:
.if defined(WITH_CLANG)
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang -E
.endif
NO_WERROR=
WERROR=
.endif # WITH_CLANG
acccording to http://wiki.freebsd.org/BuildingFreeBSDWithClang#Quickstart,
you should be using:
CPP=clang-cpp
I change this a while ago and it don't change the problem at hand
Henri
If you change this , does it fix the issue?
Scot
___
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: Can not build kernel with modular ata and ATA_CAM
On 06/25/2012 10:50, Mitya wrote:
My kernel options:
# Bus support.
device acpi
device pci
# Modular ATA
device atadisk # ATA disk drives
device atacore # Core ATA functionality
device atapci # PCI bus support; only generic chipset
support
device ataintel# Intel
options ATA_CAM # Handle legacy controllers with CAM
options ATA_STATIC_ID # Static device numbering
# ATA/SCSI peripherals
device scbus # SCSI bus (required for ATA/SCSI)
device da # Direct Access (disks)
device pass# Passthrough device (direct ATA/SCSI
access)
From /usr/src/sys/conf/NOTES:
# ATA_CAM: Turn ata(4) subsystem controller drivers into cam(4)
# interface modules. This deprecates all ata(4)
# peripheral device drivers (atadisk, ataraid,
atapicd,
# atapifd, atapist, atapicam) and all user-level APIs.
# cam(4) drivers and APIs will be connected instead.
So you must remove 'device atadisk'
Henri
make's output:
ata-disk.o: In function `ad_init':
ata-disk.c:(.text+0x7d): undefined reference to `ata_setmode'
ata-disk.c:(.text+0x95): undefined reference to `ata_wc'
ata-disk.c:(.text+0xc9): undefined reference to `ata_controlcmd'
ata-disk.c:(.text+0x11b): undefined reference to `ata_controlcmd'
ata-disk.c:(.text+0x16d): undefined reference to `ata_controlcmd'
ata-disk.c:(.text+0x1b6): undefined reference to `ata_controlcmd'
ata-disk.o: In function `ad_shutdown':
ata-disk.c:(.text+0x258): undefined reference to `ata_controlcmd'
ata-disk.o: In function `ad_detach':
ata-disk.c:(.text+0x479): undefined reference to `ata_fail_requests'
ata-disk.o: In function `ad_dump':
ata-disk.c:(.text+0x861): undefined reference to `ata_drop_requests'
ata-disk.c:(.text+0x921): undefined reference to `ata_controlcmd'
ata-disk.o: In function `ad_attach':
ata-disk.c:(.text+0xa40): undefined reference to `ata_setmax'
ata-disk.c:(.text+0xb62): undefined reference to `ata_satarev2str'
ata-disk.c:(.text+0xba7): undefined reference to `ata_unit2str'
ata-disk.c:(.text+0xfff): undefined reference to `ata_queue_request'
ata-disk.c:(.text+0x131e): undefined reference to `ata_queue_request'
ata-disk.c:(.text+0x1340): undefined reference to `ata_getparam'
ata-disk.o: In function `ad_spindown':
ata-disk.c:(.text+0x539): undefined reference to `ata_queue_request'
ata-disk.o: In function `ad_ioctl':
ata-disk.c:(.text+0x5a4): undefined reference to `ata_device_ioctl'
ata-disk.o: In function `ad_strategy':
ata-disk.c:(.text+0x6c7): undefined reference to `ata_queue_request'
*** [kernel] Error code 1
I found differences in ata-all.c and ata-all.h
In ata-all.c:
#ifndef ATA_CAM
void
ata_setmode(device_t dev)
{
But, in ata-all.h:
void ata_setmode(device_t dev);
without any #ifdef or #ifndef
___
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: zfs destroy snapshot doesn't free space
On 08/13/2010 20:02, Andreas Mayer wrote: > $ uname -a > FreeBSD wurd.dev001.net 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 > 02:36:49 UTC 2010 > r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > 2010/8/13 Malcolm Waltz : >> Have you tried "zfs list -t all" ? > > I have, it produces this output: > $ zfs list -t all > NAME USED AVAIL REFER MOUNTPOINT > rpool 637G 48,4G18K none > rpool/root 245M 1,76G 209M legacy > .. rpool/root backup snapshots ... > rpool/srv 5,31G 48,4G 4,94G /srv > .. rpool/srv backup snapshots ... > rpool/tmp 90,2M 1,91G 90,2M /tmp > .. rpool/tmp backup snapshots ... > rpool/usr 7,91G 48,4G 6,83G /usr > .. rpool/usr backup snapshots ... > rpool/var 623G 48,4G 623G /var > Just to be sure that a process is not still hogging space: fstat |grep /var 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: MFC of ZFSv15
On 09/16/2010 17:18, jhell wrote:
On 09/16/2010 09:55, Mike Tancsa wrote:
Thanks again for all the ZFS fixes and enhancements! Are there any
caveats to upgrading ?
Do I just do
zpool upgrade -a
zfs upgrade -a
or are there any extra steps ?
Hi Mike,
No-one knows your bootcode better than you. So if you are upgrading
don't forget if you are on a ZFS root then your bootcode might need
updating.
I was bitten by this problem in a previous ZFS upgrade.
To be sure, I have added this patch to zfsimpl.c so, at boot I know if
zpool/zfs upgrade will be OK.
Henri
Regards, UPDATING should have anything else.
Index: sys/boot/zfs/zfsimpl.c
===
--- sys/boot/zfs/zfsimpl.c (revision 212549)
+++ sys/boot/zfs/zfsimpl.c (working copy)
@@ -61,6 +61,8 @@
STAILQ_INIT(&zfs_vdevs);
STAILQ_INIT(&zfs_pools);
+ printf("ZFS: supported version %u\n", (unsigned) SPA_VERSION);
+
zfs_temp_buf = malloc(TEMP_SIZE);
zfs_temp_end = zfs_temp_buf + TEMP_SIZE;
zfs_temp_ptr = zfs_temp_buf;
___
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: MFC of ZFSv15
On 09/19/2010 18:33, Dan Mack wrote: > But I should be able to boot my ZFSv14 root pool using the ZFSv15 build of > FreeBSD, correct? Yes > But the problem scenario would be when I've upgraded by root pool to v15 and > I attempt to boot it with v14 boot loader. At least that is what I think ... You are right > > I guess what I'm getting at is ... you should be able to buildworld, > installkernel, reboot, installworld, reboot without worry. It is the case > But when after your run 'zpool upgrade', you will need to re-write the > bootcode using gpart on each of your root pool ZFS disks. I prefer to install bootcode BEFORE. Then reboot and check it with the printf of my simple patch. Then you can zpool/zfs upgrade without problem. > > Am I understanding this correctly ? > > Thanks for all the work on ZFS BTW, it's great! > > Dan > > On Sep 16, 2010, at 2:03 PM, Henri Hennebert wrote: > >> On 09/16/2010 17:18, jhell wrote: >>> On 09/16/2010 09:55, Mike Tancsa wrote: >>>> >>>> Thanks again for all the ZFS fixes and enhancements! Are there any >>>> caveats to upgrading ? >>>> >>>> Do I just do >>>> >>>> zpool upgrade -a >>>> zfs upgrade -a >>>> >>>> or are there any extra steps ? >>>> >>> >>> Hi Mike, >>> >>> No-one knows your bootcode better than you. So if you are upgrading >>> don't forget if you are on a ZFS root then your bootcode might need >>> updating. >>> >> I was bitten by this problem in a previous ZFS upgrade. >> >> To be sure, I have added this patch to zfsimpl.c so, at boot I know if >> zpool/zfs upgrade will be OK. >> >> Henri >>> >>> Regards, UPDATING should have anything else. >>> >> >> ___ >> 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" > > Dan > -- > Dan Mack > m...@macktronics.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"
zfsboot from 8.2RC1 freeze at boot time
Hello and merry Xmas to everybody, I upgrade a remote server from 8.1-RELEASE to 8.2-RC1. This server have one disk: [r...@tignes ~]# gpart show => 63 488397105 ada0 MBR (233G) 63 12583809 1 freebsd (6.0G) 12583872 475813296 2 freebsd [active] (227G) => 0 12583809 ada0s1 BSD (6.0G) 0 8388608 1 freebsd-ufs (4.0G) 8388608 4195201 2 freebsd-swap (2.0G) =>0 475813296 ada0s2 BSD (227G) 0 475813296 1 freebsd-zfs (227G) It boot with zfsboot from ada0s2 containing a zfs pool. After upgrading the zfsboot just to be able to upgrade the pool to v15, the server don't boot anymore. It is a remote server, so I reproduce this config under VirtualBox. The boot freeze after zfsboot displaying "-". I grab a old zfsboot from another server running 8.1-STABLE (r213582) which boot fine. I put the zfsboot from r213582 (zpool v15 aware) on ada0s2 and bingo, the server boot normally. 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: recent regression with REL7 and Zfs
Thierry Herbelot wrote: Hello, I am using a recent 7.0-Stable (x86) and a Zfs pool for my data. After the dtrace import, I have updated my sources (and make buildworld, make buildkernel) and I no longer have access to my Zfs pool (just to be sure, I have since updated twice more to work around the announced issues). Probably same problem here: With new kernel (7.1-PRERELEASE) and a root file system under zfs, the root can't be mounted and system stop with message saying can't mount zfs:pool0 Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> I revert to previous kernel and all is OK now. Henri With the new kernel, the Zpool is listed as "failed" (bad checksum ?). Reverting to the old kernel is sufficient to recover the Zfs pool (which was scrubed last week), and it is declared healthy. cheers and thanks for the good work TfH ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible ZFS patch, please test!
John Baldwin wrote: This patch merges a few changes from HEAD back to 7.x. I think the endian changes specifically might solve the issue people saw with zpools created with non-dtrace kernels not being readable by dtrace kernels and vice versa. http://www.FreeBSD.org/~jhb/patches/zfs_7.patch It works for me with the root on zfs Thanks Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible ZFS patch, please test!
Henri Hennebert wrote: John Baldwin wrote: This patch merges a few changes from HEAD back to 7.x. I think the endian changes specifically might solve the issue people saw with zpools created with non-dtrace kernels not being readable by dtrace kernels and vice versa. http://www.FreeBSD.org/~jhb/patches/zfs_7.patch It works for me with the root on zfs While rebuilding the ports index with `portsdb -Uu` the system become really sluggish with cpu running more than 60% in system... Something really strange here. Henri Thanks Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible ZFS patch, please test!
John Baldwin wrote: On Friday 29 August 2008 03:57:46 am Henri Hennebert wrote: Henri Hennebert wrote: John Baldwin wrote: This patch merges a few changes from HEAD back to 7.x. I think the endian changes specifically might solve the issue people saw with zpools created with non-dtrace kernels not being readable by dtrace kernels and vice versa. http://www.FreeBSD.org/~jhb/patches/zfs_7.patch It works for me with the root on zfs While rebuilding the ports index with `portsdb -Uu` the system become really sluggish with cpu running more than 60% in system... Something really strange here. Can you try removing the 'KDTRACE_*' options from your kernel config file? It appears that they haven't been enabled in 8.x by default yet. I try, but with the wold of 7.1-PRERELEASE I got cc: Internal error: Segmentation fault: 11 (program ld) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Stop in /usr/obj/usr/src/sys/MORZINE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. So I get /usr/bin/cc /usr/bin/ld /usr/libexec/cc* from a previous 7.0-STABLE and try it again... with a lot of cpu-system... >80% on a dual core. Anyway - I reboot the new kernel without KDTRACE_HOOKS and DDB_CTF. After reboot, system cpu is always very high and system not responsive. Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible ZFS patch, please test!
John Birrell wrote: On Sat, Aug 30, 2008 at 09:07:15AM +0200, Henri Hennebert wrote: I try, but with the wold of 7.1-PRERELEASE I got cc: Internal error: Segmentation fault: 11 (program ld) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Henri, please delete the entire contents of your obj directory to remove the bad tools that have been built there. When you run 'make buildkernel' it will use the tools from the last buildworld rather than the installed ones. For anyone experiencing this problem, you can do a 'make installworld' with STRIP= as long as you can boot to single user and mount your file systems. The problem is occurring when static binaries are installed with the default option to strip the binaries. It seems that the strip program doesn't like the presence of the CTF ELF section. OK - I better understand what's happening. I believe that the buildworld that you have is OK, even when built with the CTF data it's the installworld when things go bad. Do you need me to send you any files to recover from this problem? No problem, I have access to a previous 7.0-STABLE. Thanks Henri -- John Birrell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible ZFS patch, please test!
John Birrell wrote: On Sat, Aug 30, 2008 at 10:40:12AM +0200, Henri Hennebert wrote: I believe that the buildworld that you have is OK, even when built with the CTF data it's the installworld when things go bad. Do you need me to send you any files to recover from this problem? No problem, I have access to a previous 7.0-STABLE. I am concerned about the high CPU problem. All the hooks that are built in with KDTRACE_HOOKS are inactive until the DTrace modules are loaded. So there should be no CPU implications there. Are you using i3886 or amd64? It is i386: CPU: Intel(R) Xeon(R) CPU5130 @ 2.00GHz (1995.01-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f6 Stepping = 6 Features=0xbfebfbff Features2=0x4e33d AMD Features=0x2010 AMD Features2=0x1 Cores per package: 2 real memory = 2146369536 (2046 MB) avail memory = 2084503552 (1987 MB) Henri -- John Birrell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible ZFS patch, please test!
John Baldwin wrote: This patch merges a few changes from HEAD back to 7.x. I think the endian changes specifically might solve the issue people saw with zpools created with non-dtrace kernels not being readable by dtrace kernels and vice versa. http://www.FreeBSD.org/~jhb/patches/zfs_7.patch Just a follow-up I cvsup at Sat Aug 30 12:55 without zfs_7.patch and make buildworld && make buildkernel && make installkernel reboot (-s) --root on zfs is ok -- make installworld reboot System is still sluggish even during the make installworld in single user. Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Possible ZFS patch, please test!
Jeremy Chadwick wrote: On Sat, Aug 30, 2008 at 09:28:36PM +0200, Henri Hennebert wrote: John Baldwin wrote: This patch merges a few changes from HEAD back to 7.x. I think the endian changes specifically might solve the issue people saw with zpools created with non-dtrace kernels not being readable by dtrace kernels and vice versa. http://www.FreeBSD.org/~jhb/patches/zfs_7.patch Just a follow-up I cvsup at Sat Aug 30 12:55 without zfs_7.patch and make buildworld && make buildkernel && make installkernel reboot (-s) --root on zfs is ok -- make installworld reboot System is still sluggish even during the make installworld in single user. Sorry if I've missed this, but what tuning have you done for ZFS? Some of us (most of us?) have seen fairly "sluggish" performance when prefetch is enabled (the default), while the system is generally more responsive when prefetch is disabled. prefetch is enabled: vfs.zfs.arc_min: 33554432 vfs.zfs.arc_max: 268435456 vfs.zfs.mdcomp_disable: 0 vfs.zfs.prefetch_disable: 0 vfs.zfs.zio.taskq_threads: 0 vfs.zfs.recover: 0 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zil_disable: 0 vfs.zfs.debug: 0 This may have nothing to do with the problem you've stated, but I thought I'd throw it out there. I think that the problem is somewhere else because >80% of system cpu on a dual core seems awfully bad - eg more than 20 seconds to open this response after clicking on the response button. Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS performance issues (solved?!)
John Birrell wrote: For those people experiencing a performance degradation since the DTrace import, please update your copy of src/sys/cddl/compat/opensolaris/kern/opensolaris_kmem.c by either cvsup of direct edit to remove "#define KMEM_DEBUG". You only need to rebuild the opensolaris kernel module after this change. The code is shared between ZFS and DTrace via the opensolaris kernel module. This is also the reason why you found it necessary to add KDB, DDB and STACK to your kernel. After removing KMEM_DEBUG, you won't need those. Please confirm that this solves the problem you have been seeing. Great, now everything is back to normal Thanks Henri -- John Birrell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
hald and GEOM_PART_BSD + GEOM_PART_MBR
Just for the record, I add options GEOM_PART_BSD and GEOM_PART_MBR to my kernel config (I want to see what gpart was saying abount my disks). At boot time I get some messages as: GEOM: ad4s2: geometry does not match label. GEOM: ad4s2: media size does not match label. and more important: hald eats up cpu time and can't answer to lshal. Removing those options resolve the problem. Henri PS - I'm ready to test some patches ___ 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: cvsweb: src/UPDATING on RELENG_7
Le 1/01/2010 16:40, Ian Smith a écrit : Hi, Thought I had a clue on using cvsweb, but seem to have mislaid it .. After updating 7.0-RELEASE to RELENG_7 sources on Dec 28, checking UPDATING before and during buildworld, went hunting on cvsweb for the very version of UPDATING I was reading, 1.507.2.34 of 2009/11/29. I can't find it, as such. 1.507 shows on MAIN, RELENG_7_BP, RELENG_7. Selecting only RELENG_7 just shows that single ver 1.507 of Oct'07. It is a known bug of cvsweb: http://www.freebsd.org/cgi/query-pr.cgi?prp=120185-1-txt&n=/patch.txt Henri On a punt I manually entered 1.507.2.34 for a diff against 1.507 and that looks just right: http://www.freebsd.org/cgi/cvsweb.cgi/src/UPDATING.diff?r1=text&tr1=1.507&r2=text&tr2=1.507.2.34 But where would I look to find the log and view for 1.507.2.34 itself? cheers, Ian ___ 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: USB problems on 8.0-STABLE
On 01/09/2010 05:39, Warren Block wrote: On Fri, 8 Jan 2010, Frank wrote: On Fri, 8 Jan 2010, Steven Friedrich wrote: Option "AllowEmptyInput" "off" EndSection Comment out the line containing AllowEmptyInput. OK, this took care of the nothing-works-unless-mouse-is-moved problem but why do I get this? It's keeping apcupsd from starting. Ace /usr/ports # usbdevs -d -v usbdevs: no USB controllers found I'd guess that usbdevs is obsolete, part of the old USB system. Ace /usr/ports # usbconfig ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen0.3: at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen0.4: at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON Do you have DEVICE /dev/ugen0.2 in apcupsd.conf? I don't understand why usbdevs can't find any controllers and apcupsd can't find any device while the kernel and usbconfig can find it all. upsdevs: probably obsolete. As for apcupsd, I don't think it can auto-scan for USB devices, but haven't used it with USB. I have: FreeBSD avoriaz.restart.bel 8.0-RELEASE FreeBSD 8.0-RELEASE #0 r199628M: Tue Nov 24 21:38:07 CET 2009 r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 usbconfig: ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON apcupsd.conf: UPSNAME Back-UPS-CS-650 UPSCABLE usb UPSTYPE usb DEVICE apcupsd is working with this config. Henri -Warren Block * Rapid City, South Dakota USA ___ 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: Pack of CAM improvements
On 01/19/2010 17:12, Alexander Motin wrote: Hi. I've made a patch, that should solve set of problems of CAM ATA and CAM generally. I would like to ask for testing and feedback. What patch does: - It unifies bus reset/probe sequence. Whenever bus attached at boot or later, CAM will automatically reset and scan it. It allows to remove duplicate code from many drivers. - Any bus, attached before CAM completed it's boot-time initialization, will equally join to the process, delaying boot if needed. - New kern.cam.boot_delay loader tunable should help controllers that are still unable to register their buses in time (such as slow USB/ PCCard/ CardBus devices). With kern.cam.boot_delay=15000 (I suppose that it was in ms) I can now boot from my sim card reader. Thanks Henri - To allow synchronization between different CAM levels, concept of requests priorities was extended. Priorities now split between several "run levels". Device can be freezed at specified level, allowing higher priority requests to pass. For example, no payload requests allowed, until PMP driver enable port. ATA XPT negotiate transfer parameters, periph driver configure caching and so on. - Frozen requests are no more counted by request allocation scheduler. It fixes deadlocks, when frozen low priority payload requests occupying slots, required by higher levels to manage theit execution. - Two last changes were holding proper ATA reinitialization and error recovery implementation. Now it is done: SATA controllers and Port Multipliers now implement automatic hot-plug and should correctly recover from timeouts and bus resets. Patch can be found here: http://people.freebsd.org/~mav/cam-ata.20100119.patch Feedback as always welcome. ___ 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: "ad0: TIMEOUT - WRITE_DMA" type errors with 7.0-RC1
Jeremy Chadwick wrote: On Fri, Jan 25, 2008 at 06:17:24PM -0700, Joe Peterson wrote: Glad you got it back! Yes, when I was first playing with ZFS, I noticed that booting between single and multi user mode could make the pools "invisible". Import seemed to bring them back... I did go into single-user mode and attempt to do ZFS-related commands, which might explain the "no datasets available" once I was back in multiuser! I would classify that as a bug, and one which is going to cause all sorts of hair-pulling for administrators in the future. I wonder what it's caused by. In single user / is read only and so /boot/zfs/zpool.cache can't be created/updated Henri The "import" technique I found on a forum somewhere, or possibly on a Solaris mailing list. I was really sweating there for a moment... So, is the disk toast, or can you still read anything from it (part table, etc.)? The ad6 disk (/backups) fsck'd cleanly without any missing files or anomalies. The ZFS pool that has two striped disks (ad8 and ad10) is fully intact too, with no loss of data that I can see. I'll have to run a scrub after I'm done copying data over to ad6, just to make sure though. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7.0-RC1 - ZFS + UFS + io activity show a deadlock
Hello, I encounter a deadlock while 1) cpio -p from a ZFS filesystem to a UFS filesystem 2) rsync from ZFS to ZFS I was running with this patch: http://people.freebsd.org/~pjd/patches/zgd_done.patch Here are show alllocks + showpcpu + bt from serial console: Henri KDB: enter: Line break on console [thread pid 259 tid 100064 ] Stopped at kdb_enter+0x32: leave db> show alllocks Process 7816 (java_vm) thread 0xa8b6bcc0 (100477) exclusive sx so_rcv_sx r = 0 (0xa9e40e78) locked @ /usr/src/sys/kern/uipc_sockbuf.c:145 Process 7816 (java_vm) thread 0xa61ebcc0 (100380) exclusive sx so_rcv_sx r = 0 (0xb1227e78) locked @ /usr/src/sys/kern/uipc_sockbuf.c:145 Process 81189 (java_vm) thread 0xa6652aa0 (100458) exclusive sx so_rcv_sx r = 0 (0xa80993a4) locked @ /usr/src/sys/kern/uipc_sockbuf.c:145 Process 81189 (java_vm) thread 0xa5c55660 (100371) exclusive sx so_rcv_sx r = 0 (0xa6138cec) locked @ /usr/src/sys/kern/uipc_sockbuf.c:145 Process 1406 (gnome-pty-helper) thread 0xa8259880 (100301) exclusive sx so_rcv_sx r = 0 (0xa9e3f218) locked @ /usr/src/sys/kern/uipc_sockbuf.c:145 Process 48 (arc_reclaim_thread) thread 0xa56ab440 (100043) exclusive sleep mutex vm object (kmem object) r = 0 (0xa08b1ec0) locked @ /usr/src/sys/vm/vm_map.c:2293 exclusive sleep mutex system map r = 0 (0xa186b0e8) locked @ /usr/src/sys/vm/vm_map.c:2412 exclusive sleep mutex UMA lock r = 0 (0xa08b1b2c) locked @ /usr/src/sys/vm/uma_core.c:1492 db> show allpcpu Current CPU: 1 cpuid= 0 curthread= 0xa56ab440: pid 48 "arc_reclaim_thread" curpcb = 0xf7510d90 fpcurthread = none idlethread = 0xa5529aa0: pid 12 "idle: cpu0" APIC ID = 0 currentldt = 0x50 spin locks held: cpuid= 1 curthread= 0xa5b36aa0: pid 259 "spa_zio_intr_1" curpcb = 0xf99bad90 fpcurthread = none idlethread = 0xa5529880: pid 11 "idle: cpu1" APIC ID = 1 currentldt = 0x50 spin locks held: db> bt 48 Tracing pid 48 tid 100043 td 0xa56ab440 cpustop_handler(1,f7510bb4,a07876dd,0,0,...) at cpustop_handler+0x32 ipi_nmi_handler(0,0,a05a23d8,b04d509c,a56d5804,...) at ipi_nmi_handler+0x2f trap(f7510bc0) at trap+0x2d calltrap() at calltrap+0x6 --- trap 0x13, eip = 0xa058d066, esp = 0xf7510c00, ebp = 0xf7510c1c --- _mtx_unlock_flags(a185d688,0,a07e8e0b,2e0,0,f7510c60,a058d3d3,a08b1b2c,8,a07e8e0b,5d4,f7510c94) at _mtx_unlock_flags+0x56 zone_drain(a18575a0,0,a07e8e0b,5d4,342a0554,...) at zone_drain+0x26e zone_foreach(400,342a0554,f7510cf8,a099a89f,f7510ce4,...) at zone_foreach+0x45 uma_reclaim(f7510ce4,a0a0ce14,1f4,0,0,...) at uma_reclaim+0x16 arc_reclaim_thread(0,f7510d38,a07cdfc5,2ea,a56d5804,...) at arc_reclaim_thread+0x3ef fork_exit(a099a4b0,0,f7510d38) at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf7510d70, ebp = 0 --- db> bt 259 Tracing pid 259 tid 100064 td 0xa5b36aa0 kdb_enter(a07c0400,a08b4928,8,7ec647,a56fb48c,...) at kdb_enter+0x32 siointr1(a08b4928,0,a07ec647,56f,f99babd8,...) at siointr1+0xdf siointr(a56fb400,f99babe8,0,a5b36aa0,a5525280,...) at siointr+0x32 intr_execute_handlers(a5519cd0,f99babf8,f99bac3c,a076fa14,3a,...) at intr_execute_handlers+0xec lapic_handle_intr(3a,f99babf8) at lapic_handle_intr+0x3f Xapic_isr1() at Xapic_isr1+0x34 --- interrupt, eip = 0xa077a99b, esp = 0xf99bac38, ebp = 0xf99bac3c --- spinlock_exit(a085a414,8,a07d329d,108) at spinlock_exit+0x2b _mtx_unlock_spin_flags(a085a414,0,a07d329d,108,f99bac8c,...) at _mtx_unlock_spin_flags+0x4d sleepq_release(a558a454,2,27af18f4,a558a3fc) at sleepq_release+0x37 cv_broadcastpri(a558a454,,a0a02fb3,347,92388953,...) at cv_broadcastpri+0x48 taskq_thread(a558a3fc,f99bad38,a07cdfc5,2ea,a5b34ab0,...) at taskq_thread+0x31c fork_exit(a098ddd0,a558a3fc,f99bad38) at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf99bad70, ebp = 0 --- db> c KDB: enter: Line break on console [thread pid 259 tid 100064 ] Stopped at kdb_enter+0x32: leave db> show alllocks Process 7816 (java_vm) thread 0xa8b6bcc0 (100477) exclusive sx so_rcv_sx r = 0 (0xa9e40e78) locked @ /usr/src/sys/kern/uipc_sockbuf.c:145 Process 7816 (java_vm) thread 0xa61ebcc0 (100380) exclusive sx so_rcv_sx r = 0 (0xb1227e78) locked @ /usr/src/sys/kern/uipc_sockbuf.c:145 Process 81189 (java_vm) thread 0xa6652aa0 (100458) exclusive sx so_rcv_sx r = 0 (0xa80993a4) locked @ /usr/src/sys/kern/uipc_sockbuf.c:145 Process 81189 (java_vm) thread 0xa5c55660 (100371) exclusive sx so_rcv_sx r = 0 (0xa6138cec) locked @ /usr/src/sys/kern/uipc_sockbuf.c:145 Process 1406 (gnome-pty-helper) thread 0xa8259880 (100301) exclusive sx so_rcv_sx r = 0 (0xa9e3f218) locked @ /usr/src/sys/kern/uipc_sockbuf.c:145 Process 48 (arc_reclaim_thread) thread 0xa56ab440 (100043) exclusive sleep mutex vm object (kmem object) r = 0 (0xa08b1ec0) locked @ /usr/src/sys/vm/vm_map.c:2293 exclusive sleep mutex system map r = 0 (0xa186b0e8) locked @ /usr/src/sys/vm/vm_map.c:2412 exclusive sleep mutex UMA lock r = 0 (0xa08b1b2c) locked @ /us
Re: 7.0-RC1 - ZFS + UFS + io activity show a deadlock
Henri Hennebert wrote: Hello, I encounter a deadlock while 1) cpio -p from a ZFS filesystem to a UFS filesystem 2) rsync from ZFS to ZFS I was running with this patch: http://people.freebsd.org/~pjd/patches/zgd_done.patch Here are show alllocks + showpcpu + bt from serial console: PS - the system is still in deadlock and waiting for more debugging... Henri ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0-RC1 - ZFS + UFS + io activity show a deadlock
Pawel Jakub Dawidek wrote: On Sun, Jan 27, 2008 at 02:47:02PM +0100, Henri Hennebert wrote: Hello, I encounter a deadlock while 1) cpio -p from a ZFS filesystem to a UFS filesystem 2) rsync from ZFS to ZFS I was running with this patch: http://people.freebsd.org/~pjd/patches/zgd_done.patch This patch is wrong, why do you use it in the first place? You advise it to me ... I will remove it. Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: finstall alpha3
Julian H. Stacey wrote: Ivan Voras wrote: As some of you may already know, I'm working on a graphical installer for FreeBSD 7, which was started as a Google SoC 2007 project but still continues. 10+ years back when Jordan did first pre= X, 24x80 graphical installer, soon afer he'd finished a blind chap posted ~So how do I install ?~ Answer then: ~Get a friend do it for you, or abandon FreeBSD & use NetBSD~ NetBSD still have Ascii installer, so more attractive to some. Idea for another SOC project : An automated tool that could descramble all the glitz of [arbitrary ?] graphics tools back to something sensible / Ascii, a bit like what OCR does for printed paper. No doubt a bew grraphical installer might be nice (if X is reliable which it often is Not, & don't rely on VESA either on old hardware), but just so's we don't forget blind too, amazingly they use computers (with expensive interfaces). Also visually impaired do too, the later simply with simple text xterms with Monster fonts, rather than graphics I presume. Just my opinion: Maybe you are great BUT YOU ARE TO DEROGATORY about a work witch may be usefull to some new users Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: finstall alpha3
Julian Stacey wrote: Henri Hennebert wrote 2 emails with same common text To: "Julian H. Stacey" <[EMAIL PROTECTED]> Date: Wed, 06 Feb 2008 15:20:38 +0100 Message-ID: <[EMAIL PROTECTED]> The first private shouting got answered. Then came To: freebsd-stable@freebsd.org Date: Wed, 06 Feb 2008 15:25:57 +0100 Message-id: <[EMAIL PROTECTED]> Assume Henri is too young to remember first graphical installer. Thank you! I'm 60 this year :-) and using FreeBSD since 2.1. Xenix since 88 IIRC. My point is that a graphical installer may be usefull, that's all. Though a new graphical installer may be very nice as an option, let it not ever be the only way: Remember blind installers, non VESA supported consoles, non X recognised chips, serial line controlled installs, & non intel/AMD platforms with broken graphics terminal support. (Sparc maybe ? more later ?) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_7 /src/UPDATING out od date?
Abdullah Ibn Hamad Al-Marri wrote: Hey, http://www.freebsd.org/cgi/cvsweb.cgi/src/UPDATING?rev=1.507;only_with_tag=RELENG_7 NOTE TO PEOPLE WHO THINK THAT FreeBSD 7.x IS SLOW: FreeBSD 7.x has many debugging features turned on, in both the kernel and userland. These features attempt to detect incorrect use of system primitives, and encourage loud failure through extra sanity checking and fail stop semantics. They also substantially impact system performance. If you want to do performance measurement, benchmarking, and optimization, you'll want to turn them off. This includes various WITNESS- related kernel options, INVARIANTS, malloc debugging flags in userland, and various verbose features in the kernel. Many developers choose to disable these features on build machines to maximize performance. Could someone please nuke this? It is a problem with cvsweb - see http://www.freebsd.org/cgi/query-pr.cgi?pr=120185 Henri Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysctl -a causes kernel trap 12
On 02/12/2013 12:22, Henri Hennebert wrote: > On 01/19/2013 06:58, Brandon Gooch wrote: >> On Fri, Jan 18, 2013 at 2:56 PM, Xin Li wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA512 >>> >>> On 01/18/13 12:50, Brandon Gooch wrote: >>>> On Thu, Jan 10, 2013 at 4:25 PM, Xin Li >>> <mailto:delp...@delphij.net>> wrote: >>>> >>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >>>> >>>> To all: this became more and more hard to replicate lately. I've >>>> tried these options and the most important progress is that it's >>>> possible to get a crashdump when debug.debugger_on_panic=0 and I >>>> managed to get a backtrace which indicates the panic occur when >>>> trying to do mtx_lock(&Giant) -> __mtx_lock_sleep -> turnstile_wait >>>> -> propagate_priority, but after I've added some instruments to >>>> the surrounding code and enabled INVARIANT and/or WITNESS, it >>>> mysteriously went away. >>>> >>>> Reverting my instruments code and update to latest svn makes the >>>> issue disappear for one day. I've hit it again today but >>>> unfortunately didn't get a successful dump and after reboot I can't >>>> reproduce it again :( >>>> >>>> Still trying... >>>> >>>> >>>> Any updates Xin? >>> >>> No, it mysteriously disappeared for now. According to my >>> understanding to recent svn commits, I didn't see anybody committing >>> something that fixes it but I can no longer panic my system, with or >>> without debugging code :( >>> >>>> I was actually hitting what I believe to be exactly the same issue >>>> as you on one of my systems, and, as you've seen, adding any extra >>>> debugging or diagnostics seemed to eliminate the issue. >>>> >>>> I was able to generate quite a few vmcores and still have these >>>> sitting around in my filesystem (along with the kernels that helped >>>> produce them). >>>> >>>> I can recreate this crash on my system by compiling the NVIDIA >>>> driver with clang at -01 and above. Although it's been noted that >>>> this issue has been seen in scenarios without an NIVIDIA driver in >>>> the mix, whatever is happening in the kernel to cause the panic is >>>> somehow triggered by this, at least on my system. >>> >>> I'm not sure if this is the same problem. Could you please try using >>> gcc to compile the nVIdia driver and see if that "fixes" the problem? >>> >>> Cheers, >>> - -- >>> Xin LI https://www.delphij.net/ >>> FreeBSD - The Power to Serve! Live free or die >>> >> >> Indeed, a gcc compiled NVIDIA module eliminates the issue, sorry if I >> hadn't mentioned this earlier. >> >> What was happening to me at first was that my system would just hang while >> booting. I was able to figure out that it was during /etc/rc.d/initrandom. >> I actually got to a point where I removed the call to sysctl -a from >> 'better_than_nothing()' in /etc/rc.d/initrandom to have a booting system. I >> finally had a situation where I could get a panic by adding SW_WATCHDOG to >> my kernel and running watchdogd(8). >> >> For me, this panic would come and go seemingly at random as well, and I >> couldn't fumble my way around in the debugger to learn much of >> anythingfreebsd-curr...@freebsd.org >> when I first started seeing it. I just started a process of modularizing >> everything I could in my kernel config, then loading modules 1-by-1 and >> booting over-and-over until I finally found what appeared to be the >> problem, which was the NVIDIA module compiled with clang. >> >> Oh, another thing: at times it seemed as though it was the number of >> modules loaded, as I could get the hang with 41 modules loaded, but not 40 >> or 42?! I admit, when I was seeing that behavior, I hadn't eliminated the >> NVIDIA driver from my loaded modules. I need to revisit the panic situation >> to confirm this particular strangeness. >> >> Here's the last panic I had: >> >> Unread portion of the kernel message buffer: >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags= interrupt enabled, resume, IOPL = 0 >> current process = 1175 (sysctl) >> >
9.2-BETA2 - Problem with newsyslog
Hello, My entry for newsyslog in /etc/crontab is: 0 * * * * rootnewsyslog -t \%Y-\%m-\%d_\%H:\%M And I get: newsyslog: Could not convert time string to time value: No such file or directory I try to use the newsyslog from head to to avail. This solution was working a month ago (see Revision 248776) My file system is zfs version 28. 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"
9.2-BETA2 bind + WITH_BIND_XML=yes + libxml2-2.8.0
Hello, When compiling world of 9.2-BETA2 and adding in /etc/src.conf WITH_BIND_XML=yes and with libxml2-2.8.0_2 (textproc/libxml2) installed in /usr/local I get this link error: ===> usr.bin/dig (all) /usr/local/lib/libxml2.a(xzlib.o): In function `__libxml2_xzclose': xzlib.c:(.text+0x69): undefined reference to `lzma_end' /usr/local/lib/libxml2.a(xzlib.o): In function `xz_decomp': xzlib.c:(.text+0x4a6): undefined reference to `lzma_code' /usr/local/lib/libxml2.a(xzlib.o): In function `xz_make': xzlib.c:(.text+0x8cd): undefined reference to `lzma_auto_decoder' xzlib.c:(.text+0xa04): undefined reference to `lzma_properties_decode' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** [dig] Error code 1 Stop in /usr/src/usr.bin/dig. *** [all] Error code 1 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: 9.2-BETA2 - Problem with newsyslog
On 07/29/2013 11:18, Henri Hennebert wrote: > Hello, > > My entry for newsyslog in /etc/crontab is: > > 0 * * * * rootnewsyslog -t \%Y-\%m-\%d_\%H:\%M > > And I get: > > newsyslog: Could not convert time string to time value: No such file or > directory > > I try to use the newsyslog from head to to avail. This solution was > working a month ago (see Revision 248776) Here I must have make some mistake... I retry with newsyslog.c from head and all is OK Henri > > My file system is zfs version 28. > > 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" > ___ 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: Lost CAM Access to DVD Writer
On 09/02/2013 01:54, Thomas Laus wrote: > Hi, > :-( Unable to CAMGETPASSTHRU for /dev/cd0 Inappropriate ioctl for > device. I encounter the same problem and reinstalling dvd+rw-tools-7.1 solved it. Henri >> >> Could someone else try to make a 'dump to DVD' backup [...] >> /sbin/dump -0u -L -C16 -B4589840 -P 'growisofs -Z /dev/cd0=/dev/fd/0' /u > > A test with less disk load would be to write e.g. 100 MB of zeros > to e.g. DVD+RW media (in order to reduce waste): > > dd if=/dev/zero bs=1M count=100 | growisofs -Z /dev/cd0=/dev/fd/0 > > I got the same result and error message as I did when trying to dump the file > system on all of the computers that use ATA for disk access. On the one PC > that uses AHCI, it was able to write to the DVD. > > Tom > ___ 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"
Link error in usr.bin/dig if WITH_BIND_XML=yes
Hello, Dig can't be linked if WITH_BIND_XML=yes is added to /etc/src.conf. [root@morzine src]# svn info Path: . Working Copy Root Path: /usr/src URL: http://svn.restart.bel/svn-FreeBSD-base/stable/9 Relative URL: ^/stable/9 Repository Root: http://svn.restart.bel/svn-FreeBSD-base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 255473 Node Kind: directory Schedule: normal Last Changed Author: des Last Changed Rev: 255443 Last Changed Date: 2013-09-10 12:07:21 +0200 (Tue, 10 Sep 2013) ===> usr.bin/dig (all) /usr/src/usr.bin/dig/../../contrib/bind9/bin/dig/dighost.c:4336:27: warning: passing 'const char *' to parameter of type 'void *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] isc_buffer_init(&buffer, str, len); ^~~ /usr/src/usr.bin/dig/../../contrib/bind9/lib/isc/include/isc/buffer.h:225:41: note: passing argument to parameter 'base' here isc__buffer_init(isc_buffer_t *b, void *base, unsigned int length); ^ 1 warning generated. /usr/local/lib/libxml2.a(xzlib.o): In function `__libxml2_xzclose': xzlib.c:(.text+0x69): undefined reference to `lzma_end' /usr/local/lib/libxml2.a(xzlib.o): In function `xz_decomp': xzlib.c:(.text+0x4a6): undefined reference to `lzma_code' /usr/local/lib/libxml2.a(xzlib.o): In function `xz_make': xzlib.c:(.text+0x8cd): undefined reference to `lzma_auto_decoder' xzlib.c:(.text+0xa04): undefined reference to `lzma_properties_decode' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** [dig] Error code 1 Stop in /usr/src/usr.bin/dig. *** [all] Error code 1 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: PF Question
Morgan Reed wrote:
Not sure if this is the most appropriate place to ask, feel free to
redirect me if it isn't.
I've got an issue with a simple NAT with pf.
I've got two machines;
the first (I will call m1) has 2 ethernet interfaces (I will call them
m1.0 and m1.1)
the second (I will call m2) has 1 ethernet interface (I will call it m2.0)
m1.0 faces my LAN, m1.1 and m2.0 are on a separate, isolated segment.
what I need to be able to do is to access the "outside world" from m2
and be able to get to Ports 80, 443 and 3128 on m2 from my LAN by
connecting to ports 80, 443 and 3128 on m1 and having traffic
forwarded appropriately.
m1.0 - 192.168.0.X/24 (DHCP assigned)
m1.1 - 192.168.1.2/24
m2.0 - 192.168.1.30/24
/etc/pf.conf
=
ext_if="m1.0"
int_if="m1.1"
nat on $ext_if from !($ext_if) -> ($ext_if:0)
I think traffic comming back is natted a second time ???
I prefer:
nat on $ext_if from $int_if:network to any -> ($ext_if)
rdr pass on $ext_if proto tcp to port 80 -> 192.168.1.30 port 80
rdr pass on $ext_if proto tcp to port 443 -> 192.168.1.30 port 443
rdr pass on $ext_if proto tcp to port 3128 -> 192.168.1.30 port 3128
I would also nat on int_if in this case -- except for m1.
no nat on $int_if proto tcp from $int_if to $int_if:network
nat on $int_if proto tcp from $int_if:network to 192.168.1.30 port {80
443 3128 } -> $int_if
Henri
pass in keep state
pass out keep state
=
The current status is as follows;
* I can ping m1.0 from m2
* I can't ping any of the other address on the 192.168.0.0/24 network
from m2
- tcpdump'ing m1.1
* Connecting to one of the forwarded ports on m1.0 I see nothing
* Connecting from m2 to a host on the LAN I see the connections going
out but, not coming back
Your assistance is greatly appreciated.
Morgan
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel trap with zfs root after shutdown
Hello, I enjoy reading "A conversation with Jeff Bonwick and Bill Moore" in ACM Queue. PJD paper "Porting the ZFS file system to the FreeBSD operation system" was really interesting... As a result, I switch all my filesystems to zfs -- Yes I know: WARNING: ZFS is considered to be an experimental feature in FreeBSD -- and it's quite stable for me. Nevertheless I encouter a glitch *after* shutdown: Kernel: 7.0-BETA1 - cvsup Oct 23 with patch http://people.freebsd.org/~pjd/patches/vm_kern.c.2.patch. Note: without this patch I get a kmem_map too small after some io load. I setup my root fs under zfs. the boot fs is under gmirror+ufs. loader.conf: #--- Tuning for ZFS - http://wiki.freebsd.org/ZFSTuningGuide vm.kmem_size="600M" # Size of kernel memory vm.kmem_size_max="600M" # Max kmem size vfs.zfs.debug="0" # ZFS - debug messages vfs.zfs.prefetch_disable="1"# ZFS - disable prefetch vfs.zfs.arc_max="128M" # ZFS - maximum ARC size : 128MB #--- Mount root filesystem from ZFS zfs_load="YES" # Load ZFS module vfs.root.mountfrom="zfs:pool0" # Root filesystem is pool0 zpool status: pool: pool0 state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM pool0 ONLINE 0 0 0 mirrorONLINE 0 0 0 da0s2 ONLINE 0 0 0 da1s2 ONLINE 0 0 0 errors: No known data errors pool: pool1 state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM pool1 ONLINE 0 0 0 da0s3 ONLINE 0 0 0 da1s3 ONLINE 0 0 0 errors: No known data errors pool: pool2 state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM pool2 ONLINE 0 0 0 raidz1ONLINE 0 0 0 ad4s3 ONLINE 0 0 0 ad6s3 ONLINE 0 0 0 errors: No known data errors After shutdown I get a kernel trap: [EMAIL PROTECTED] MORZINE]# kgdb kernel.debug /var/crash/vmcore.20 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: <118>Oct 28 09:58:48 morzine syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 0 done All buffers synced. kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x188 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0593425 stack pointer = 0x28:0xf668fa68 frame pointer = 0x28:0xf668fa80 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 1 (init) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c080a4a9,f668f944,c059f96f,c0825e2c,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0825e2c,0,c07eebd8,f668f950,0,...) at kdb_backtrace+0x29 panic(c07eebd8,c08270e8,c5527f68,1,1,...) at panic+0x10f trap_fatal(c0826fea,c,c588f000,f668f9c0,c5527d48,...) at trap_fatal+0x333 trap(f668fa28) at trap+0x11f calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc0593425, esp = 0xf668fa68, ebp = 0xf668fa80 --- _mtx_lock_sleep(c69d1a18,c5528440,0,0,0,...) at _mtx_lock_sleep+0x85 vrele(c69d1990,c5b80d0c,c5528440,c080eb5b,91f,...) at vrele+0x5b vflush(c5b80d0c,1,2,c5528440,c5b5a844,...) at vflush+0x69b zfs_umount(c5b80d0c,8,c5528440,c5528440,c080e762,...) at zfs_umount+0xd5 dounmount(c5b80d0c,8,c5528440,ead65aec,0,...) at dounmount+0x4ef vfs_unmountall(c08083ac,0,c0808410,10e,f668fc50,...) at vfs_unmountall+0x33 boot(c5528440,8,0,fffe,c5528440,...) at boot+0x444 reboot(c5528440,f668fcfc,4,8048260,9e7c9054,...) at reboot+0x67 syscall(f668fd38) at syscall+0x335 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (55, FreeBSD ELF32, reboot), eip = 0x8050be3, esp = 0xbfbfe90c, ebp = 0xbfbfe9d8 --- Uptime: 3d16h44m52s Physical memory: 2030 MB Dumping 468 MB: 453 437 421 405 389 373 357 341 325 309 293
ZFS - kmem_malloc too small
Hello I'm running 7.0-BETA1 with patch http://people.freebsd.org/~pjd/patches/vm_kern.c.2.patch -- without this patch, the panic come sooner. I setup my root fs under zfs. the boot fs is under gmirror+ufs. loader.conf: #--- Tuning for ZFS - http://wiki.freebsd.org/ZFSTuningGuide vm.kmem_size="600M" # Size of kernel memory vm.kmem_size_max="600M" # Max kmem size vfs.zfs.debug="0" # ZFS - debug messages vfs.zfs.prefetch_disable="1"# ZFS - disable prefetch vfs.zfs.arc_max="128M" # ZFS - maximum ARC size : 128MB #--- Mount root filesystem from ZFS zfs_load="YES" # Load ZFS module vfs.root.mountfrom="zfs:pool0" # Root filesystem is pool0 zpool status: pool: pool0 state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM pool0 ONLINE 0 0 0 mirrorONLINE 0 0 0 da0s2 ONLINE 0 0 0 da1s2 ONLINE 0 0 0 errors: No known data errors pool: pool1 state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM pool1 ONLINE 0 0 0 da0s3 ONLINE 0 0 0 da1s3 ONLINE 0 0 0 errors: No known data errors pool: pool2 state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM pool2 ONLINE 0 0 0 raidz1ONLINE 0 0 0 ad4s3 ONLINE 0 0 0 ad6s3 ONLINE 0 0 0 errors: No known data errors When copying avi files (~300MB each) from pool0 to a ufs under gjournal gjournal list Geom name: gjournal 2719642309 ID: 2719642309 Providers: 1. Name: ad4s2.journal Mediasize: 49384282112 (46G) Sectorsize: 512 Mode: r1w1e2 Consumers: 1. Name: ad4s2 Mediasize: 51531766272 (48G) Sectorsize: 512 Mode: r1w1e1 Jend: 51531765760 Jstart: 49384282112 Role: Data,Journal I got: Panic String: kmem_malloc(131072): kmem_map too small: 400539648 total allocated Just before the panic, I observe a freeze of 8 sec. as by the patch. Anyway, I'm quite pleased with zfs Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ZFS deadlock ?
hello To push zfs, I launch 2 scrub at the same time, after ~20 seconds the system freeze: zpool scrub pool0 && zpool scrub pool2 My pools: zpool status pool: pool0 state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM pool0 ONLINE 0 0 0 mirrorONLINE 0 0 0 da0s2 ONLINE 0 0 0 da1s2 ONLINE 0 0 0 errors: No known data errors pool: pool1 state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM pool1 ONLINE 0 0 0 da0s3 ONLINE 0 0 0 da1s3 ONLINE 0 0 0 errors: No known data errors pool: pool2 state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM pool2 ONLINE 0 0 0 raidz1ONLINE 0 0 0 ad4s3 ONLINE 0 0 0 ad6s3 ONLINE 0 0 0 errors: No known data errors I'm running 7.0-BETA2 with patch http://people.freebsd.org/~pjd/patches/vm_kern.c.2.patch Root is on pool0 [EMAIL PROTECTED] ~]# df -h FilesystemSizeUsed Avail Capacity Mounted on pool0 34G 16M 34G 0%/ devfs 1.0K1.0K 0B 100%/dev /dev/mirror/gm0s1a496M220M236M48%/bootfs procfs4.0K4.0K 0B 100%/proc pool0/home 35G1.5G 34G 4%/home pool1 16G128K 16G 0%/pool1 pool1/qemu 24G 16G8.1G66%/pool1/qemu pool1/squid12G 39M 12G 0%/pool1/squid pool2 72G 0B 72G 0%/pool2 pool2/WorkBench64G 21G 43G33%/pool2/WorkBench pool2/backup 32G6.8G 25G21%/pool2/backup pool2/download 72G 0B 72G 0%/pool2/download pool2/morzine 85G 13G 72G16%/pool2/morzine pool2/qemu 16G 16G112M99%/pool2/qemu pool2/sys 73G1.2G 72G 2%/pool2/sys pool0/tmp 34G384K 34G 0%/tmp pool0/usr 40G5.7G 34G14%/usr pool0/var 34G116M 34G 0%/var pool0/var/spool39G5.2G 34G13%/var/spool devfs 1.0K1.0K 0B 100%/var/named/dev I can break on my serial console and her are some informations: db> ps pid ppid pgrp uid state wmesg wchancmd 3425 3424 3425 0 RVs cron 3424 1161 1161 0 S ppwait 0xc5f3 cron 3423 589 3423 0 S+ zfs:&vq- 0xc5c0b334 zpool 3419 0 0 0 SL vgeom:io 0xc8ba1308 [vdev:worker ad6s3] 3418 0 0 0 SL vgeom:io 0xda70f748 [vdev:worker ad4s3] 3417 0 0 0 SL zfs:(&sp 0xc56da318 [spa_scrub_thread] 3415 0 0 0 SL vgeom:io 0xd90229c8 [vdev:worker da1s2] 3414 0 0 0 SL vgeom:io 0xc5892208 [vdev:worker da0s2] 3413 0 0 0 SL zfs:(&sp 0xc56db318 [spa_scrub_thread] 3309 998 979 8 S nanslp 0xc0890924 sleep 3136 995 995 8 S select 0xc089b778 initial thread 2610 1490 2610 0 S+ select 0xc089b778 ssh 76040 1 76016 2001 S select 0xc089b778 initial thread 76038 76034 76016 2001 S (threaded) firefox-bin 100333 S ucond0xcb3fc080 firefox-bin 100327 S ucond0xc8ba1e80 firefox-bin 100326 S ucond0xc722abc0 firefox-bin 100323 S ucond0xc5b56680 firefox-bin 1002850xcb466580 firefox-bin 100156 S select 0xc089b778 firefox-bin 100441 S select 0xc089b778 initial thread 76034 76030 76016 2001 S wait 0xcca1e2a8 sh 76030 1 76016 2001 S wait 0xcca1f000 sh 29979 29976 2997970 Rs postgres 29978 29976 2997870 Rs postgres 29976 1 2997670 Ss select 0xc089b778 postgres 25774 1 2577425 Ss pause0xcf074858 sendmail 25770 1 25770 0 Ss select 0xc089b778 sendmail 589 587 589 0 S+ wait 0xcbe18d48 bash 587 1311 587 2001 Ss+ wait 0xca7e52a8 su 7234 1486 7234 0 S+ select 0xc089b778 ssh 58922 1 58922 0 Ss kqread 0xdb632200 cupsd 54279 1 5427953 Ss (threaded) named 100207 S select 0xc089b778 named 100206 S ucond0xc76cadc0 named 100205 S ucond0xd1c3c440 named 100204 S ucond0xd1c3dac0 named 00291
Re: ZFS deadlock ?
Richard Arends wrote: On Fri, Nov 09, 2007 at 05:37:00PM +0100, Henri Hennebert wrote: Henri, To push zfs, I launch 2 scrub at the same time, after ~20 seconds the system freeze: zpool scrub pool0 && zpool scrub pool2 This won't start the scrubs at the same time, but after each other. And the second will only start if the first one not fails (exitcode == 0) Not at all, the scrub is asynchronious, I'm sure of it Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS deadlock ?
Richard Arends wrote: On Fri, Nov 09, 2007 at 09:35:59PM +0100, Henri Hennebert wrote: This won't start the scrubs at the same time, but after each other. And the second will only start if the first one not fails (exitcode == 0) Not at all, the scrub is asynchronious, I'm sure of it Running 2 commands seperated by && will not run at the same time. Scrub could be asynchronious, i don't know, but that has nothing to do with the way you are running it. See: echo "sleep 1" && time sleep 2 && echo "sleep 2" && time sleep 2 and: ls -l /notfound && echo yes Per the man page, zpool scrub *begin* a scrub witch go on in background, so two scrubs are running simustaneously on 2 different pools. Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS deadlock ?
Pawel Jakub Dawidek wrote: On Fri, Nov 09, 2007 at 05:37:00PM +0100, Henri Hennebert wrote: hello To push zfs, I launch 2 scrub at the same time, after ~20 seconds the system freeze: [...] I found a deadlock too. If it's reproducable for you, can you try this patch: I reproduce it after 30 minutes, si I try you patch. http://people.freebsd.org/~pjd/patches/zgd_done.patch when I try to load zfs.ko I get: # kldload zfs link_elf: symbol kproc_create undefined kldload: can't load zfs: No such file or directory What must I add to my config to resolve this symbol / problem Thanks Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: No boot messages after upgrading to 7.0-BETA2
AngryWolf wrote: Hi, Recently I upgraded my FreeBSD 6.2 system to 7.0-BETA2 using cvsup and the following howto, except that what I first did was a `pkg_delete -a': http://d-kriptik.com/blog/2007/10/30/updating-to-freebsd-7-beta-1-from-freebsd-62/ Everything went OK, except that, after the second reboot, now I can see: - no system messages (what I usually see in dmesg), - no rc messages (about daemons startup), - no general syslog messages (like using command 'su'). Just a thought, are you using a serial console, have you a /boot.config file? Henri It's like I've lost the default tty or something, because after the boot process finishes, I can still log in, KDM starts up fine, etc. How can I fix this? FreeBSD localhost.localdomain 7.0-BETA2 FreeBSD 7.0-BETA2 #7: Fri Nov 9 13:16:53 CET 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYKERNEL i386 I used the GENERIC configuration with the only difference that I added `device atapicam' for kbd. Also, I'm not sure whether I should enable SMP for my CPU, which is Intel(R) Celeron(R) D 3.20GHz. Thanks in advance. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS deadlock ?
Pawel Jakub Dawidek wrote: On Sat, Nov 10, 2007 at 12:39:27PM +0100, Henri Hennebert wrote: Pawel Jakub Dawidek wrote: On Fri, Nov 09, 2007 at 05:37:00PM +0100, Henri Hennebert wrote: hello To push zfs, I launch 2 scrub at the same time, after ~20 seconds the system freeze: [...] I found a deadlock too. If it's reproducable for you, can you try this patch: I reproduce it after 30 minutes, si I try you patch. http://people.freebsd.org/~pjd/patches/zgd_done.patch when I try to load zfs.ko I get: # kldload zfs link_elf: symbol kproc_create undefined kldload: can't load zfs: No such file or directory What must I add to my config to resolve this symbol / problem Ouch, you don't use HEAD. Try changing kproc_*() to kthread_*(). It load correctly now... Moreover, no deadlock after multiple scrub in // and some buildworld to make sure... look fine for my config :-) Just to give credit to zfs, scrub encounter 2 IO errors without impact on my data :) /var/log/messages: Nov 10 15:33:00 morzine kernel: ad6: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=299882429 Nov 10 15:33:06 morzine kernel: ad6: TIMEOUT - READ_DMA48 retrying (0 retries left) LBA=299882429 Nov 10 15:33:12 morzine kernel: ad6: FAILURE - READ_DMA48 timed out LBA=299882429 Nov 10 16:55:53 morzine kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Nov 10 16:55:53 morzine kernel: ad6: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=299883325 Nov 10 16:56:06 morzine kernel: ad6: TIMEOUT - READ_DMA48 retrying (0 retries left) LBA=299883325 Nov 10 16:56:13 morzine kernel: ad6: FAILURE - READ_DMA48 timed out LBA=299883325 ZFS is realy great! I will run more test tomorrow... and keep you posted Thanks Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS deadlock ?
Pawel Jakub Dawidek wrote: On Sat, Nov 10, 2007 at 12:39:27PM +0100, Henri Hennebert wrote: Pawel Jakub Dawidek wrote: On Fri, Nov 09, 2007 at 05:37:00PM +0100, Henri Hennebert wrote: hello To push zfs, I launch 2 scrub at the same time, after ~20 seconds the system freeze: [...] I found a deadlock too. If it's reproducable for you, can you try this patch: I reproduce it after 30 minutes, si I try you patch. http://people.freebsd.org/~pjd/patches/zgd_done.patch when I try to load zfs.ko I get: # kldload zfs link_elf: symbol kproc_create undefined kldload: can't load zfs: No such file or directory What must I add to my config to resolve this symbol / problem Ouch, you don't use HEAD. Try changing kproc_*() to kthread_*(). Today, after more than 10 scrubs, no deadlock. This patch is effective. Thanks Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ZFS from FreeBSD -> Indiana -> FreeBSD - some problem
Hello, As seen in another thread, I was curious about a zpool created under FreeBSD being available under opensolaris. So I boot indiana and do: zpool import -f -o ro pool2 zpool scrub pool2 all ended properly... shutdown. When I reboot with FreeBSD (7.0-BETA2) I get: zpool status pool2 pool: pool2 state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-D3 scrub: none requested config: NAME STATE READ WRITE CKSUM pool2UNAVAIL 0 0 0 insufficient replicas raidz1 UNAVAIL 0 0 0 insufficient replicas dsk/c10d0p3 UNAVAIL 0 0 0 cannot open dsk/c11d0p3 UNAVAIL 0 0 0 cannot open Is it possible to replace dsk/c10d0p3 by ad4s3 and dsk/c11d0p3 by ad6s3 as it must be under FreeBSD or does I need to make some entry in /etc/devfs.rules to create dsk/c10d0p3 and dsk/c11d0p3 (if at all possible?) Isn't it a interesting challenge ? Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS from FreeBSD -> Indiana -> FreeBSD - some problem
Henri Hennebert wrote: Hello, As seen in another thread, I was curious about a zpool created under FreeBSD being available under opensolaris. So I boot indiana and do: zpool import -f -o ro pool2 zpool scrub pool2 all ended properly... shutdown. When I reboot with FreeBSD (7.0-BETA2) I get: zpool status pool2 pool: pool2 state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-D3 scrub: none requested config: NAME STATE READ WRITE CKSUM pool2UNAVAIL 0 0 0 insufficient replicas raidz1 UNAVAIL 0 0 0 insufficient replicas dsk/c10d0p3 UNAVAIL 0 0 0 cannot open dsk/c11d0p3 UNAVAIL 0 0 0 cannot open Is it possible to replace dsk/c10d0p3 by ad4s3 and dsk/c11d0p3 by ad6s3 as it must be under FreeBSD or does I need to make some entry in /etc/devfs.rules to create dsk/c10d0p3 and dsk/c11d0p3 (if at all possible?) Isn't it a interesting challenge ? I got it: zpool export pool2 && zpool import -f pool2 do the trick sorry for the noise :-| Henri Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS deadlock ?
Henri Hennebert wrote: Pawel Jakub Dawidek wrote: On Sat, Nov 10, 2007 at 12:39:27PM +0100, Henri Hennebert wrote: Pawel Jakub Dawidek wrote: On Fri, Nov 09, 2007 at 05:37:00PM +0100, Henri Hennebert wrote: hello To push zfs, I launch 2 scrub at the same time, after ~20 seconds the system freeze: [...] I found a deadlock too. If it's reproducable for you, can you try this patch: I reproduce it after 30 minutes, si I try you patch. http://people.freebsd.org/~pjd/patches/zgd_done.patch when I try to load zfs.ko I get: # kldload zfs link_elf: symbol kproc_create undefined kldload: can't load zfs: No such file or directory What must I add to my config to resolve this symbol / problem Ouch, you don't use HEAD. Try changing kproc_*() to kthread_*(). Today, after more than 10 scrubs, no deadlock. This patch is effective. Maybe this is not related, but when I copy a 600MB file from zfs to a ufs under gjournal, my system freeze completely. A break on the serial console don't go to debugging! Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
7.0-BETA4 - i386 - root on zfs - system freeze
Hello, I'm running 7.0-BETA4 - i386 with the root fs on zfs. This nigth, the system freeze. I can enter kdb - see attached file - If I request the wrong informations let me know for the next time... I use the patch http://people.freebsd.org/~pjd/patches/zgd_done.patch . Henri show lockedvnods Locked vnodes 0xa6ce1330: tag zfs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags (VV_ROOT) v_object 0xaaca4554 ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xabc69440 (pid 1200) with 1 pending 0xabcfc880: tag zfs, type VDIR usecount 25, writecount 0, refcount 27 mountedhere 0 flags () v_object 0xba6ec1f0 ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xabc6c220 (pid 1195) with 1 pending 0xabaa0bb0: tag zfs, type VDIR usecount 1, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xaeea61f0 ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xa5ba7440 (pid 1190) with 1 pending 0xa938e000: tag zfs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xae7f983c ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xa5b4 (pid 50869) 0xc227: tag zfs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xb0a7a07c ref 0 pages 0 lock type zfs: EXCL (count 1) by thread 0xa5ba7000 (pid 33960) db> ps pid ppid pgrp uid state wmesg wchancmd 33962 33959 33943 0 S piperd 0xa5dad4a4 wc 33961 33959 33943 0 S piperd 0xa69a7dec tee 33960 33959 33943 0 R find 33959 33955 33943 0 S wait 0xa61ea000 sh 33955 33952 33943 0 S piperd 0xa5ea6dec sh 33954 33953 33943 0 S piperd 0xa5d0b4a4 mail 33953 33945 33943 0 S wait 0xa6435ab0 sh 33952 33945 33943 0 S wait 0xa88fe2ac sh 33945 33943 33943 0 S wait 0xa6439804 sh 33943 33941 33943 0 Ss wait 0xa65e0ab0 sh 33941 1047 1047 0 S piperd 0xa60d9000 cron 33909 886 865 8 R sleep 96256 1 9625625 Rs sendmail 96252 1 96252 0 Rs sendmail 96004 1 96004 389 Ss (threaded) slapd 100382 S ucond0xa6113c00 slapd 100171 S select 0xa089b7f8 slapd 100343 S uwait0xa5b56a00 slapd 95808 95796 9579680 R (threaded) httpd --More--100381 CanRun httpd 100380 S ucond0xab0f03c0 httpd 100379 S ucond0xa63c2c00 httpd 100378 S ucond0xaf422a80 httpd 100377 S ucond0xac2c4d80 httpd 100376 S ucond0xa5b1ab40 httpd 100375 S ucond0xa6417800 httpd 100374 S ucond0xa5b7a480 httpd 100373 S ucond0xa984f640 httpd 100372 S ucond0xa79f1580 httpd 100371 S ucond0xa9dcfb80 httpd 100370 S ucond0xa6ec48c0 httpd 100369 S ucond0xa6418900 httpd 100368 S ucond0xa79f1b00 httpd 100342 S ucond0xa894b000 httpd 100341 S ucond0xa991e940 httpd 100274 S piperd 0xa6534318 httpd 95805 95796 9579680 S accept 0xa930103a httpd 95804 95798 95796 0 S piperd 0xa5fefdec cronolog 95803 95800 95796 0 S piperd 0xa5b60630 cronolog 95802 95799 95796 0 S piperd 0xa6121000 cronolog 95801 95797 95796 0 S piperd 0xa5c86ad4 cronolog 95800 95796 95796 0 S wait 0xaadbaab0 sh 95799 95796 95796 0 S wait 0xa7f82000 sh 95798 95796 95796 0 S wait 0xa6283804 sh 95797 95796 95796 0 S wait 0xa8b9dab0 sh 95796 1 95796 0 Rs httpd 95792 95787 95777 0 S+ piperd 0xa588718c cronolog 95787 1 95777 0 S+ wait 0xa623b804 sh 95764 1 95764 0 Ss kqread 0xa5f70b80 cupsd 50945 50869 50945 100 Ss piperd 0xa5ea6948 unlinkd 50869 50867 50867 100 R (threaded) squid 100397 S ucond0xa682ca00 squid 100396 S ucond0xa5b1b740 squid 100395 S ucond0xa79f7c40 squid 100394 S ucond0xa7842c40 squid 100393 S ucond0xab0f06c0 squid 100392 S ucond0xa718b4c0 squid 100391 S ucond0xc2453000 squid 100390 S ucond0xa647dd00 squid 100389 S ucond0xb053b080 squ
Re: 6.4-STABLE and PHP5 pcre and phpsysinfo
xer wrote: Hello Mine 6.4-STABLE today has a strange problem regarding "phpsysinfo" that i use it. Ports are updated,but phpsysinfo (on browser) today show errors about pcre: --- Notice: Undefined offset: 3 in /usr/local/www/data-dist/phpsysinfo/includes/os/class.FreeBSD.inc.php on line 59 ^ a lots Warning: preg_match() [function.preg-match]: Internal pcre_fullinfo() error -3 in /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php on line 126 ^ a lots Warning: asort() expects parameter 1 to be array, boolean given in /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php on line 174 ^ a lots Warning: preg_match() [function.preg-match]: Internal pcre_fullinfo() error -3 in /usr/local/www/data-dist/phpsysinfo/includes/os/class.BSD.common.inc.php on line 187 ^ a lots XPath error in XPath.class.php:3492 Expression failed to parse as PrimaryExpr because: Expression is not a PrimaryExpr XPath error in XPath.class.php:5903 The supplied xPath '/phpsysinfo/Vitals/Distro' does not *uniquely* describe a node in the xml document.Not unique xpath-query, matched 0-times. and more... It seems that the FreeBSD patch does not work so well, someone use phpsysinfo? I did deinstalled php5 and 1.3 extension and reinstalled as expected.. but no resolve. Contrary to /usr/ports/UPDATING - entry 20081211, base php5 (5.2.9) don't contains pcre. You simply have to add /usr/ports/devel/php5-pcre. All will be OK. Henri Any help please? Thanx in advance. _ Quante ne sai? Scoprilo con CrossWire! http://clk.atdmt.com/GBL/go/140630367/direct/01/___ 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"
7.2-RC1 - serial console / sio0 not working
Hello, Experiencing some deadlock, I try to reenable my serial console on 7.2-RC1. (console="comconsole,vidconsole" in /boot/loader.conf and -Dh or -Dh -S115200 in /boot.config). /var/log/message show: 'sio0: type 16550A, console' and from the vga point of view, console output from kernel is slow as if echoed on a serial and rc output is going somewhere. At the other end of the serial, minicom show nothing and is 'offline'. A break at the minicom set my 7.2-RC1 in debugging (ddb) but 'continue' has no effect. The cable is working fine (serial console mode) with another box in 8.0-CURRENT. If I disable serial console and try minicom on 7.2-RC1, status is offline but any key is recieved at the other end and any key type at the other end is displayed fine. Does anyone encounter such a problem ? Thanks in advance 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"
7.2-RC1 - serial console / sio0 not working
Sorry for the previous wrong followup :-( Hello, Experiencing some deadlock, I try to reenable my serial console on 7.2-RC1. (console="comconsole,vidconsole" in /boot/loader.conf and -Dh or -Dh -S115200 in /boot.config). /var/log/message show: 'sio0: type 16550A, console' and from the vga point of view, console output from kernel is slow as if echoed on a serial and rc output is going somewhere. At the other end of the serial, minicom show nothing and is 'offline'. A break at the minicom set my 7.2-RC1 in debugging (ddb) but 'continue' has no effect. The cable is working fine (serial console mode) with another box in 8.0-CURRENT. If I disable serial console and try minicom on 7.2-RC1, status is offline but any key is recieved at the other end and any key type at the other end is displayed fine. Does anyone encounter such a problem ? Thanks in advance 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: 7.2-RC1 - serial console / sio0 not working
Marten Vijn wrote: On Mon, 2009-04-20 at 16:49 +0200, Henri Hennebert wrote: Hello, Experiencing some deadlock, I try to reenable my serial console on 7.2-RC1. (console="comconsole,vidconsole" in /boot/loader.conf and -Dh or -Dh -S115200 in /boot.config). /var/log/message show: 'sio0: type 16550A, console' and from the vga point of view, console output from kernel is slow as if echoed on a serial and rc output is going somewhere. At the other end of the serial, minicom show nothing and is 'offline'. A break at the minicom set my 7.2-RC1 in debugging (ddb) but 'continue' has no effect. The cable is working fine (serial console mode) with another box in 8.0-CURRENT. If I disable serial console and try minicom on 7.2-RC1, status is offline but any key is recieved at the other end and any key type at the other end is displayed fine. Does anyone encounter such a problem ? maybe diff /etc/ttys between 8.0 and 7.2 I don't use the serial for login, so I believe it is not important in my case. Thank you for your time Henri I had problems updrading a machine (over serial console) lately, (7.1.to Current) Marten Thanks in advance 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" ___ 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 MFC heads down
Navdeep Parhar wrote: On Wed, May 20, 2009 at 5:00 PM, Kip Macy wrote: Not really a problem but a question: Is the v13 on-disk format exactly the same as that used by Solaris/Opensolaris? It is supposed to be. The sources are the same. However, I have not tested interoperability. Does this make it possible to have a ZFS-only dual boot system running FreeBSD-stable and Solaris, with a shared home directory between the two environments? It should be. Has anyone tried anything like this? Google anyone? :-) My google-fu is weak today, and considering that this went into -stable a few minutes back, I didn't look that hard for v13/fbsd-stable/opensolaris adventures. :-) I do it with 7.1 and opensolaris 2008.05 without problem. I keep the pool in V6 of course. Henri I'm feeling brave. I think I'll try it myself. Thanks for getting this into -stable! Navdeep -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" ___ 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 MFC heads down
Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. I upgrade to stable r192523: FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu May 21 13:18:53 CEST 2009 r...@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 some strange things: just after boot: [r...@morzine ~]# zfs upgrade This system is currently running ZFS filesystem version 3. The following filesystems are out of date, and can be upgraded. After being upgraded, these filesystems (and any 'zfs send' streams generated from subsequent snapshots) will no longer be accessible by older software versions. VER FILESYSTEM --- 1 pool1 1 pool1/qemu 1 pool1/squid 1 pool2 1 pool2/WorkBench 1 pool2/backup 1 pool2/download 1 pool2/qemu 1 pool2/sys 1 rpool 1 rpool/home 1 rpool/root 1 rpool/tmp 1 rpool/usr 1 rpool/var 1 rpool/var/spool [r...@morzine ~]# zfs upgrade -v The following filesystem versions are supported: VER DESCRIPTION --- 1 Initial ZFS filesystem version 2 Enhanced directory entries 3 Case insensitive and File system unique identifer (FUID) For more information on a particular version, including supported releases, see: http://www.opensolaris.org/os/community/zfs/version/zpl/N Where 'N' is the version number. And now, after a few minutes: [r...@morzine ~]# zpool upgrade This system is currently running ZFS pool version 13. The following pools are out of date, and can be upgraded. After being upgraded, these pools will no longer be accessible by older software versions. VER POOL --- 6 pool1 6 pool2 6 rpool Use 'zpool upgrade -v' for a list of available versions and their associated features. [r...@morzine ~]# zpool upgrade -v This system is currently running ZFS pool version 13. The following versions are supported: VER DESCRIPTION --- 1 Initial ZFS version 2 Ditto blocks (replicated metadata) 3 Hot spares and double parity RAID-Z 4 zpool history 5 Compression using the gzip algorithm 6 bootfs pool property 7 Separate intent log devices 8 Delegated administration 9 refquota and refreservation properties 10 Cache devices 11 Improved scrub performance 12 Snapshot properties 13 snapused property For more information on a particular version, including supported releases, see: http://www.opensolaris.org/os/community/zfs/version/N Where 'N' is the version number. Strange isn't it o-) By the way all seems ok! Thanks to all for this update to zfs V13 Henri 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" ___ 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 MFC heads down
Henri Hennebert wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. I upgrade to stable r192523: FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu May 21 13:18:53 CEST 2009 r...@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 some strange things: just after boot: [r...@morzine ~]# zfs upgrade This system is currently running ZFS filesystem version 3. The following filesystems are out of date, and can be upgraded. After being upgraded, these filesystems (and any 'zfs send' streams generated from subsequent snapshots) will no longer be accessible by older software versions. VER FILESYSTEM --- 1 pool1 1 pool1/qemu 1 pool1/squid 1 pool2 1 pool2/WorkBench 1 pool2/backup 1 pool2/download 1 pool2/qemu 1 pool2/sys 1 rpool 1 rpool/home 1 rpool/root 1 rpool/tmp 1 rpool/usr 1 rpool/var 1 rpool/var/spool [r...@morzine ~]# zfs upgrade -v The following filesystem versions are supported: VER DESCRIPTION --- 1 Initial ZFS filesystem version 2 Enhanced directory entries 3 Case insensitive and File system unique identifer (FUID) For more information on a particular version, including supported releases, see: http://www.opensolaris.org/os/community/zfs/version/zpl/N Where 'N' is the version number. And now, after a few minutes: [r...@morzine ~]# zpool upgrade This system is currently running ZFS pool version 13. The following pools are out of date, and can be upgraded. After being upgraded, these pools will no longer be accessible by older software versions. VER POOL --- 6 pool1 6 pool2 6 rpool Use 'zpool upgrade -v' for a list of available versions and their associated features. [r...@morzine ~]# zpool upgrade -v This system is currently running ZFS pool version 13. The following versions are supported: VER DESCRIPTION --- 1 Initial ZFS version 2 Ditto blocks (replicated metadata) 3 Hot spares and double parity RAID-Z 4 zpool history 5 Compression using the gzip algorithm 6 bootfs pool property 7 Separate intent log devices 8 Delegated administration 9 refquota and refreservation properties 10 Cache devices 11 Improved scrub performance 12 Snapshot properties 13 snapused property For more information on a particular version, including supported releases, see: http://www.opensolaris.org/os/community/zfs/version/N Where 'N' is the version number. Strange isn't it o-) By the way all seems ok! This happen after the first boot in stable (comming from 7.2-RELEASE). I reboot and can't reproduce it!. Henri Thanks to all for this update to zfs V13 Henri 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" ___ 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: ZFS MFC heads down
Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. I get a panic: panic: solaris assert: 0 == dmu_read(os, lr->lr_foid, off, dlen, buf), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c, line: 991 during `make -s DESTDIR=/kingston installworld` kingston is a pool on a USB stick with GPT partitions more info at : http://verbier.restart.be/xfer/core.txt.60 Thanks for your work Henri 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" ___ 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 MFC heads down
Kip Macy wrote: I haven't looked at the panic yet, but adding a USB quirk (no SYNCHRONIZE_CACHE) would certainly reduce the noise in your logs. Thanks for this hint. I patch usbdevs and umass.c. No more noise but more interesting, now I can complete install on my usb key without deadlock or crash. Henri -Kip On Mon, May 25, 2009 at 4:16 AM, Henri Hennebert wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. I get a panic: panic: solaris assert: 0 == dmu_read(os, lr->lr_foid, off, dlen, buf), file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c, line: 991 during `make -s DESTDIR=/kingston installworld` kingston is a pool on a USB stick with GPT partitions more info at : http://verbier.restart.be/xfer/core.txt.60 Thanks for your work Henri 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" ___ 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 MFC heads down
Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. No a real problem but maybe worth mentioning: on FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue May 26 15:37:48 CEST 2009 r...@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 [r...@morzine ~]# zdb rpool version=13 name='rpool' state=0 txg=959 pool_guid=17669857244588609348 hostid=2315842372 hostname='unset' vdev_tree type='root' id=0 guid=17669857244588609348 children[0] type='mirror' id=0 guid=3225603179255348056 metaslab_array=23 metaslab_shift=28 ashift=9 asize=51534888960 is_log=0 children[0] type='disk' id=0 guid=17573085726489368265 path='/dev/da0p2' whole_disk=0 children[1] type='disk' id=1 guid=2736169600077218893 path='/dev/da1p2' whole_disk=0 Assertion failed: (?Àuè?ëÛ´&), function mp->m_owner == NULL, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 112. Abort trap: 6 and on FreeBSD avoriaz.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon May 25 12:06:07 CEST 2009 r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 [r...@avoriaz ~]# zdb rpool version=13 name='rpool' state=0 txg=3467 pool_guid=536117255064806899 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=536117255064806899 children[0] type='mirror' id=0 guid=3124217685892976292 metaslab_array=23 metaslab_shift=30 ashift=9 asize=155741847552 is_log=0 children[0] type='disk' id=0 guid=11099413743436480159 path='/dev/ad4p2' whole_disk=0 children[1] type='disk' id=1 guid=12724983687805955432 path='/dev/ad6p2' whole_disk=0 Segmentation fault: 11 By the way, to help prepare a boot/root pool does a utility to display the content of zpool.cache exist ? Henri 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" ___ 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 MFC heads down
Artem Belevich wrote: I had the same problem on -current. Try attached patch. It may not apply cleanly on -stable, but should be easy enough to make equivalent changes on -stable. The patch is ok for stable. now I get for the pool with my root: [r...@morzine libzpool]# zdb rpool version=13 name='rpool' state=0 txg=959 pool_guid=17669857244588609348 hostid=2315842372 hostname='unset' vdev_tree type='root' id=0 guid=17669857244588609348 children[0] type='mirror' id=0 guid=3225603179255348056 metaslab_array=23 metaslab_shift=28 ashift=9 asize=51534888960 is_log=0 children[0] type='disk' id=0 guid=17573085726489368265 path='/dev/da0p2' whole_disk=0 children[1] type='disk' id=1 guid=2736169600077218893 path='/dev/da1p2' whole_disk=0 WARNING: pool 'rpool' could not be loaded as it was last accessed by another system (host: unset hostid: 0x8a08f344). See: http://www.sun.com/msg/ZFS-8000-EY zdb: can't open rpool: No such file or directory But rpool have been used for many boot now - strange ... Thanks for your patch and time Henri --Artem On Wed, May 27, 2009 at 3:00 AM, Henri Hennebert wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. No a real problem but maybe worth mentioning: on FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue May 26 15:37:48 CEST 2009 r...@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 [r...@morzine ~]# zdb rpool version=13 name='rpool' state=0 txg=959 pool_guid=17669857244588609348 hostid=2315842372 hostname='unset' vdev_tree type='root' id=0 guid=17669857244588609348 children[0] type='mirror' id=0 guid=3225603179255348056 metaslab_array=23 metaslab_shift=28 ashift=9 asize=51534888960 is_log=0 children[0] type='disk' id=0 guid=17573085726489368265 path='/dev/da0p2' whole_disk=0 children[1] type='disk' id=1 guid=2736169600077218893 path='/dev/da1p2' whole_disk=0 Assertion failed: (?Ąuč? ėŪ¨´&), function mp->m_owner == NULL, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 112. Abort trap: 6 and on FreeBSD avoriaz.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon May 25 12:06:07 CEST 2009 r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 [r...@avoriaz ~]# zdb rpool version=13 name='rpool' state=0 txg=3467 pool_guid=536117255064806899 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=536117255064806899 children[0] type='mirror' id=0 guid=3124217685892976292 metaslab_array=23 metaslab_shift=30 ashift=9 asize=155741847552 is_log=0 children[0] type='disk' id=0 guid=11099413743436480159 path='/dev/ad4p2' whole_disk=0 children[1] type='disk' id=1 guid=12724983687805955432 path='/dev/ad6p2' whole_disk=0 Segmentation fault: 11 By the way, to help prepare a boot/root pool does a utility to display the content of zpool.cache exist ? Henri Thanks, Kip ___ freebsd-stable@freebsd.o
Re: ZFS MFC heads down
Henri Hennebert wrote: Artem Belevich wrote: I had the same problem on -current. Try attached patch. It may not apply cleanly on -stable, but should be easy enough to make equivalent changes on -stable. The patch is ok for stable. now I get for the pool with my root: [r...@morzine libzpool]# zdb rpool version=13 name='rpool' state=0 txg=959 pool_guid=17669857244588609348 hostid=2315842372 hostname='unset' vdev_tree type='root' id=0 guid=17669857244588609348 children[0] type='mirror' id=0 guid=3225603179255348056 metaslab_array=23 metaslab_shift=28 ashift=9 asize=51534888960 is_log=0 children[0] type='disk' id=0 guid=17573085726489368265 path='/dev/da0p2' whole_disk=0 children[1] type='disk' id=1 guid=2736169600077218893 path='/dev/da1p2' whole_disk=0 WARNING: pool 'rpool' could not be loaded as it was last accessed by another system (host: unset hostid: 0x8a08f344). See: http://www.sun.com/msg/ZFS-8000-EY zdb: can't open rpool: No such file or directory But rpool have been used for many boot now - strange ... And dangerous: the second time I try: [r...@morzine ~]# zdb rpool zdb: can't open rpool: No such file or directory [r...@morzine ~]# And the real problem: rpool is no more in /boot/zfs/zpool.cache !!! Next boot will not work smoothly. Tomorrow, I will use the 3rd bootable disk to rebuild this. Henri Thanks for your patch and time Henri --Artem On Wed, May 27, 2009 at 3:00 AM, Henri Hennebert wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. No a real problem but maybe worth mentioning: on FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue May 26 15:37:48 CEST 2009 r...@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 [r...@morzine ~]# zdb rpool version=13 name='rpool' state=0 txg=959 pool_guid=17669857244588609348 hostid=2315842372 hostname='unset' vdev_tree type='root' id=0 guid=17669857244588609348 children[0] type='mirror' id=0 guid=3225603179255348056 metaslab_array=23 metaslab_shift=28 ashift=9 asize=51534888960 is_log=0 children[0] type='disk' id=0 guid=17573085726489368265 path='/dev/da0p2' whole_disk=0 children[1] type='disk' id=1 guid=2736169600077218893 path='/dev/da1p2' whole_disk=0 Assertion failed: (?Ąuč? ėŪ¨´&), function mp->m_owner == NULL, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 112. Abort trap: 6 and on FreeBSD avoriaz.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon May 25 12:06:07 CEST 2009 r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 [r...@avoriaz ~]# zdb rpool version=13 name='rpool' state=0 txg=3467 pool_guid=536117255064806899 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=536117255064806899 children[0] type='mirror' id=0 guid=3124217685892976292 metaslab_array=23 metaslab_shift=30 ashift=9 asize=155741847552 is_log=0 children[0] type='disk' id=0 guid=11099413743436480159 path='/dev/ad4p2' whole_disk=0 children[1] type='disk' id=1
Re: ZFS MFC heads down
Artem Belevich wrote: Did you by any chance do that from single-user mode? ZFS seems to rely on hostid being set. Try running "/etc/rc.d/hostid start" and then re-try your zfs commands. I was in multiuser with hostid set. Henri --Artem On Wed, May 27, 2009 at 1:06 PM, Henri Hennebert wrote: Artem Belevich wrote: I had the same problem on -current. Try attached patch. It may not apply cleanly on -stable, but should be easy enough to make equivalent changes on -stable. The patch is ok for stable. now I get for the pool with my root: [r...@morzine libzpool]# zdb rpool version=13 name='rpool' state=0 txg=959 pool_guid=17669857244588609348 hostid=2315842372 hostname='unset' vdev_tree type='root' id=0 guid=17669857244588609348 children[0] type='mirror' id=0 guid=3225603179255348056 metaslab_array=23 metaslab_shift=28 ashift=9 asize=51534888960 is_log=0 children[0] type='disk' id=0 guid=17573085726489368265 path='/dev/da0p2' whole_disk=0 children[1] type='disk' id=1 guid=2736169600077218893 path='/dev/da1p2' whole_disk=0 WARNING: pool 'rpool' could not be loaded as it was last accessed by another system (host: unset hostid: 0x8a08f344). See: http://www.sun.com/msg/ZFS-8000-EY zdb: can't open rpool: No such file or directory But rpool have been used for many boot now - strange ... Thanks for your patch and time Henri --Artem On Wed, May 27, 2009 at 3:00 AM, Henri Hennebert wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. No a real problem but maybe worth mentioning: on FreeBSD morzine.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue May 26 15:37:48 CEST 2009 r...@morzine.restart.bel:/usr/obj/usr/src/sys/MORZINE i386 [r...@morzine ~]# zdb rpool version=13 name='rpool' state=0 txg=959 pool_guid=17669857244588609348 hostid=2315842372 hostname='unset' vdev_tree type='root' id=0 guid=17669857244588609348 children[0] type='mirror' id=0 guid=3225603179255348056 metaslab_array=23 metaslab_shift=28 ashift=9 asize=51534888960 is_log=0 children[0] type='disk' id=0 guid=17573085726489368265 path='/dev/da0p2' whole_disk=0 children[1] type='disk' id=1 guid=2736169600077218893 path='/dev/da1p2' whole_disk=0 Assertion failed: (?Ąuč? ėŪ¨´&), function mp->m_owner == NULL, file /usr/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/kernel.c, line 112. Abort trap: 6 and on FreeBSD avoriaz.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon May 25 12:06:07 CEST 2009 r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 [r...@avoriaz ~]# zdb rpool version=13 name='rpool' state=0 txg=3467 pool_guid=536117255064806899 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=536117255064806899 children[0] type='mirror' id=0 guid=3124217685892976292 metaslab_array=23 metaslab_shift=30 ashift=9 asize=155741847552 is_log=0 children[0] type='disk' id=0 guid=11099413743436480159 path='/dev/ad4p2' whole_disk=0 children[1] type='disk' id=1 guid=12724983687805955432 path='/dev/ad6p2' whole_disk=0 Segmentatio
Re: ZFS MFC heads down
Kip Macy wrote: On Wed, May 27, 2009 at 11:04 AM, Artem Belevich wrote: I had the same problem on -current. Try attached patch. It may not apply cleanly on -stable, but should be easy enough to make equivalent changes on -stable. --Artem Adding to rw_init looks fine, but I'd rather find out why owner isn't NULL when the calling convention expects it. Getting a backtrace from where the assert is hit would be helpful. -Kip on FreeBSD avoriaz.restart.bel 7.2-STABLE FreeBSD 7.2-STABLE #0: Mon May 25 12:06:07 CEST 2009 r...@avoriaz.restart.bel:/usr/obj/usr/src/sys/AVORIAZ amd64 Is it useful ? [r...@avoriaz ~]# gdb zdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) r rpool Starting program: /usr/sbin/zdb rpool (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100343] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8018020b0 (LWP 100343)] [New Thread 0x801802240 (LWP 100346)] version=13 name='rpool' state=0 txg=3467 pool_guid=536117255064806899 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=536117255064806899 children[0] type='mirror' id=0 guid=3124217685892976292 metaslab_array=23 metaslab_shift=30 ashift=9 asize=155741847552 is_log=0 children[0] type='disk' id=0 guid=11099413743436480159 path='/dev/ad4p2' whole_disk=0 children[1] type='disk' id=1 guid=12724983687805955432 path='/dev/ad6p2' whole_disk=0 [New Thread 0x8018023d0 (LWP 100347)] [New Thread 0x801802560 (LWP 100354)] [New Thread 0x8018026f0 (LWP 100355)] [New Thread 0x801802880 (LWP 100356)] [New Thread 0x801802a10 (LWP 100359)] [New Thread 0x801802ba0 (LWP 100360)] [New Thread 0x801802d30 (LWP 100368)] [New Thread 0x801802ec0 (LWP 100369)] [New Thread 0x801803050 (LWP 100370)] [New Thread 0x8018031e0 (LWP 100371)] [New Thread 0x801803370 (LWP 100372)] [New Thread 0x801803500 (LWP 100373)] [New Thread 0x801803690 (LWP 100374)] [New Thread 0x801803820 (LWP 100375)] [New Thread 0x8018039b0 (LWP 100376)] [New Thread 0x801803b40 (LWP 100377)] [New Thread 0x801803cd0 (LWP 100378)] [New Thread 0x801803e60 (LWP 100379)] [New Thread 0x801803ff0 (LWP 100380)] [New Thread 0x801804180 (LWP 100381)] [New Thread 0x801804310 (LWP 100382)] [New Thread 0x8018044a0 (LWP 100383)] [New Thread 0x801804630 (LWP 100384)] [New Thread 0x8018047c0 (LWP 100385)] [New Thread 0x801804950 (LWP 100386)] [New Thread 0x801804ae0 (LWP 100387)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x8018020b0 (LWP 100343)] 0x0008012a6f22 in strlen () from /lib/libc.so.7 (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 #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 #13 0x00408b41 in ?? () #14 0x004036de in ?? () #15 0x000800534000 in ?? () #16 0x in ?? () #17 0x0002 in ?? () #18 0x7fffed70 in ?? () #19 0x7fffed7e in ?? () #20 0x in ?? () #21 0x7fffed84 in ?? () #22 0x7fffed9a in ?? () #23 0x7fffeda5 in ?? () #24 0x7fffedbf in ?? () #25 0x7fffedea in ?? () #26 0x7
Re: ZFS MFC heads down
Andriy Gapon wrote: 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 But back to the problem - without an additional printf we still can not what was the value in m_owner. Only that it was not null. Probably it's better to build with debugging symbols and examine with gdb. Firt try: [r...@avoriaz libzpool]# gdb zdb GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... (gdb) r pool1 Starting program: /usr/sbin/zdb pool1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New LWP 100299] (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 0x8018020b0 (LWP 100299)] [New Thread 0x801802240 (LWP 100354)] version=13 name='pool1' state=0 txg=4 pool_guid=9156958376606789 hostid=1133576597 hostname='unset' vdev_tree type='root' id=0 guid=9156958376606789 children[0] type='raidz' id=0 guid=8214939615613279020 nparity=1 metaslab_array=23 metaslab_shift=32 ashift=9 asize=500108886016 is_log=0 children[0] type='disk' id=0 guid=7001907692988243779 path='/dev/ad8p2' whole_disk=0 children[1] type='disk' id=1 guid=1909032920962573263 path='/dev/ad10p2' whole_disk=0 [New Thread 0x8018023d0 (LWP 100369)] [New Thread 0x801802560 (LWP 100370)] [New Thread 0x8018026f0 (LWP 100371)] [New Thread 0x801802880 (LWP 100372)] [New Thread 0x801802a10 (LWP 100376)] [New Thread 0x801802ba0 (LWP 100382)] [New Thread 0x801802d30 (LWP 100383)] [New Thread 0x801802ec0 (LWP 100384)] [New Thread 0x801803050 (LWP 100385)] [New Thread 0x8018031e0 (LWP 100386)] [New Thread 0x801803370 (LWP 100387)] [New Thread 0x801803500 (LWP 100388)] [New Thread 0x801803690 (LWP 100389)] [New Thread 0x801803820 (LWP 100390)] [New Thread 0x8018039b0 (LWP 100391)] [New Thread 0x801803b40 (LWP 100392)] [New Thread 0x801803cd0 (LWP 100393)] [New Thread 0x801803e60 (LWP 100394)] [New Thread 0x801803ff0 (LWP 100395)] [New Thread 0x801804180 (LWP 100396)] [New Thread 0x801804310 (LWP 100397)] [New Thread 0x8018044a0 (LWP 100398)] [New Thread 0x801804630 (LWP 100399)] [New Thread 0x8018047c0 (LWP 100400)] [New Thread 0x801804950 (LWP 100401)] [New Thread 0x801804ae0 (LWP 100402)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x8018020b0 (LWP 100299)] 0x0008012a6f22 in strlen () from /lib/libc.so.7 (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 #6 0x000800fef230 in zmutex_destroy (mp=0x8018b2cc0) at /usr
Re: ZFS MFC heads down
Henri Hennebert wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. --- clipped --- By the way, to help prepare a boot/root pool does a utility to display the content of zpool.cache exist ? I find the answer to this question and think it may be really useful to others: zdb -C [ -U ] Henri Henri 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" ___ 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: Problem with postfix and mail command
Ruben Lara wrote: Hi all! I just installed postfix, after build world without sendmail If i try to send mail i get: mail# mail aaa Subject: a a . EOT mail# mail: /usr/sbin/sendmail: No such file or directory Event with WITHOUT_SENDMAIL=yes in /etc/src.conf, make installworld must create this symbolic links: # ls -l /usr/sbin/sendmail lrwxr-xr-x 1 root wheel 21 May 21 13:54 /usr/sbin/sendmail -> /usr/sbin/mailwrapper Henri I edited: mail# cat /etc/mail/mailer.conf # # Execute the Postfix sendmail program, named /usr/local/sbin/sendmail # sendmail/usr/local/sbin/sendmail send-mail/usr/local/sbin/sendmail mailq/usr/local/sbin/sendmail newaliases/usr/local/sbin/sendmail mail# where actually i have my postfix esecutables Thanks for help in advance Rubén Lara _ ¡Acelera con la Fórmula 1! Juega y demuestra lo que sabes con MSN Deportes http://msn.es.predictorpro.com/grand-prix/overview.aspx?season=8 ___ 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: ZFS MFC heads down
Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. I get a Fatal trap 12: page fault while in kernel mode at shutdown. the core.txt is http://verbier.restart.be/xfer/core.txt.61 Thanks for you work Henri 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" ___ 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 MFC heads down
Kip Macy wrote: Please try applying this change to your tree and let me know. I patch, I reboot 2 times without problem. I keep you posted is I encounter a new crash. Thanks Henri Thanks, Kip http://svn.freebsd.org/viewvc/base?view=revision&revision=193110 On Sat, May 30, 2009 at 2:11 AM, Henri Hennebert wrote: Kip Macy wrote: On Wed, May 20, 2009 at 2:59 PM, Kip Macy wrote: I will be MFC'ing the newer ZFS support some time this afternoon. Both world and kernel will need to be re-built. Existing pools will continue to work without upgrade. If you choose to upgrade a pool to take advantage of new features you will no longer be able to use it with sources prior to today. 'zfs send/recv' is not expected to inter-operate between different pool versions. The MFC went in r192498. Please let me know if you have any problems. I get a Fatal trap 12: page fault while in kernel mode at shutdown. the core.txt is http://verbier.restart.be/xfer/core.txt.61 Thanks for you work Henri 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" ___ 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
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): 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 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
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
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): 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 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
Re: libzpool assert vs libc assert
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 g
Re: /boot/loader can't load kernel if too many pool/devices
Doug Rabson wrote: On 1 Jun 2009, at 11:22, Henri Hennebert wrote: 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. I recently increased the number of file descriptors available for /boot/loader. Could you rebuild and try again please. Make sure you rebuild libstand.a as well as /boot/loader. OK - I can boot with the USB key and 4 disks Thanks 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
Kip Macy wrote:
On Mon, Jun 1, 2009 at 10:21 AM, Adam McDougall 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.
At last I get this F.G diff!!!
The problem was in libstand.a. By the way , the patch also take into
account the update of Doug Rabson to answer my problem with too many
devices / pools.
Happy to help on this one.
Cheers,
Kip
--- lib/libstand/stand.h.orig 2007-01-09 02:02:04.0 +0100
+++ lib/libstand/stand.h2009-06-03 17:24:42.627552341 +0200
@@ -167,7 +167,7 @@
#define SOPEN_RASIZE 512
};
-#defineSOPEN_MAX 8
+#defineSOPEN_MAX 64
extern struct open_file files[];
/* f_flags values */
--- lib/libstand/nfs.c.orig 2004-01-21 21:12:23.0 +0100
+++ lib/libstand/nfs.c 2009-06-05 20:36:26.001368421 +0200
@@ -29,7 +29,7 @@
*/
#include
-__FBSDID("$FreeBSD: src/lib/libstand/nfs.c,v 1.12 2004/01/21 20:12:23 jhb Exp
$");
+__FBSDID("$FreeBSD: src/lib/libstand/nfs.c,v 1.14 2008/11/21 09:14:29 luigi
Exp $");
#include
#include
@@ -405,16 +405,23 @@
#ifdef NFS_DEBUG
if (debug)
- printf("nfs_open: %s (rootpath=%s)\n", path, rootpath);
+ printf("nfs_open: %s (rootpath=%s)\n", upath, rootpath);
#endif
if (!rootpath[0]) {
printf("no rootpath, no nfs\n");
return (ENXIO);
}
+ /*
+* This is silly - we should look at dv_type but that value is
+* arch dependant and we can't use it here.
+*/
#ifndef __i386__
if (strcmp(f->f_dev->dv_name, "net") != 0)
return(EINVAL);
+#else
+ if (strcmp(f->f_dev->dv_name, "pxe") != 0)
+ return(EINVAL);
#endif
if (!(desc = socktodesc(*(int *)(f->f_devdata
___
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"
Stable from May 31 - zfs list locked
Hello, I encounter this problem for the second time. The system is working perfectly well but suddenly the command `zfs list' don't work and can't be killed. Here is a procstat of the culprit: [r...@morzine ~]# procstat -k 91766 PIDTID COMM TDNAME KSTACK 91766 100490 zfs -mi_switch sleepq_switch sleepq_wait _cv_wait zio_wait dbuf_read dmu_buf_hold zap_lockdir zap_lookup_norm zap_lookup dsl_prop_get_dd dsl_dataset_get_ref dsl_dataset_hold dmu_objset_open zfs_ioc_objset_stats zfsdev_ioctl devfs_ioctl_f kern_ioctl same thing happen if I try to run `zpool list' un another terminal. 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: Stable from May 31 - zfs list locked
Henri Hennebert wrote: Hello, I encounter this problem for the second time. The system is working perfectly well but suddenly the command `zfs list' don't work and can't be killed. Here is a procstat of the culprit: [r...@morzine ~]# procstat -k 91766 PIDTID COMM TDNAME KSTACK 91766 100490 zfs -mi_switch sleepq_switch sleepq_wait _cv_wait zio_wait dbuf_read dmu_buf_hold zap_lockdir zap_lookup_norm zap_lookup dsl_prop_get_dd dsl_dataset_get_ref dsl_dataset_hold dmu_objset_open zfs_ioc_objset_stats zfsdev_ioctl devfs_ioctl_f kern_ioctl same thing happen if I try to run `zpool list' un another terminal. Stangely, zfs snapsot and zfs destroy seems working properly ... I reboot to check this 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" ___ 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 pool from current
Nenhum_de_Nos wrote: On Wed, June 17, 2009 11:16, Dimitry Andric wrote: On 2009-06-17 16:09, Nenhum_de_Nos wrote: And for virtualbox on amd64 purposes I want to run 7.2R or STABLE to use VT-x and amd64 vm's under vbox. will I have to make anything, or it will just work ? Kip Macy created a branch were there is the new zfs code, but I didn't get it if it is in the main sources or if I need to fetch any especial code. Kip merged the ZFS v13 support to -STABLE just last month. It seems to work okay for most people, but be sure to read the UPDATING file, especially if you are upgrading existing pools. thanks, I was just looking for this update on web interface to cvs and there is nothing in UPDATING for RELENG_7 there. is this really supposed to happen ? Sadly a known and ignored problem of cvsweb http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/120185 Henri I'll get from csup now ... thanks again, matheus ___ 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 pool from current
Gavin Atkinson wrote: On Wed, 2009-06-17 at 16:51 +0200, Henri Hennebert wrote: Nenhum_de_Nos wrote: thanks, I was just looking for this update on web interface to cvs and there is nothing in UPDATING for RELENG_7 there. is this really supposed to happen ? Sadly a known and ignored problem of cvsweb http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/120185 Henri As far as I can tell, this isn't really a problem with cvsweb, but more of a problem with the repository itself. The issue comes when a commit is made and the log message includes the magic string that CVS uses internally to track different revisions. The patch proposed in that PR appears to be more of a hack than a fix. Ok with that but there is no fix if you base your algorithm on a wrong specification. It's the same reason that (for example) http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/rc.d/ntpd lists a revision 1.335 even though the most recent commit was version 1.18. The hack work well in this case too. I prefer a hack instead of a confusing answer. Henri On the upside, it doesn't appear that these bogus commits have ended up replicated in the SVN repository. Gavin ___ 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: FreeBSD 7-STABLE and chflags on ZFS now(?) failing
Ralf S. Engelschall wrote: One of my FreeBSD boxes is a 7-STABLE/amd64 one on ZFS, now in production for over a 1.5 years now and which receives regular upgrades. The last installation of FreeBSD 7-STABLE was just about 2 weeks ago. Today the upgrade failed the first time: cd /usr/src; /usr/bin/make -f Makefile.inc1 install ===> share/info (install) ===> lib (install) ===> lib/csu/amd64 (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.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 -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib install: /lib/libc.so.7: chflags: Invalid argument *** Error code 71 Stop in /usr/src/lib/libc. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. 3.30s real 0.35s user 0.75s sys /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "sh" *** Error code 1 Stop in /usr/adm. *** Error code 1 (ignored) /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "sh" *** Error code 1 (ignored) /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "sh" *** Error code 1 (ignored) /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "sh" *** Error code 1 (ignored) /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "sh" *** Error code 1 Stop in /usr/adm. *** Error code 1 (ignored) # sh /libexec/ld-elf.so.1: Shared object "libc.so.7" not found, required by "sh" # Fortunately, I was able to quickly recover via "/rescue/cp" by copying a libc.so.7 from a Jail to the host system (where the upgrade was performed). But why has this problem occurred now. Well, /lib is on ZFS and I can remember from the past that ZFS did not honor chflags. But remains two questions: 1. I thought chflags support for ZFS was added already in the past. Can it be that just a _few_ chflags flags are supported? It looks like uchg works while the above schg fails. I believe that for schg `zfs get version ` must be 3. To upgrade this: `zfs upgrade ` 2. Assuming that schg was never supported on ZFS by us, why did the upgrades in the past on this FreeBSD 7-STABLE box never failed until now? Why now the first time? I would have expected that it already failed from day zero with the above error. Just a try to this strange problem: `man install` say: By default, install preserves all file flags, with the exception of the ``nodump'' flag. With the previous version of zfs there was no flags and so no try to play with flags during update. Henri As workaround I've now put a NO_SCHG=yes into /etc/make.conf and performed the upgrade from scratch. Now it succeeded, of course. But I still do not know the answer to the above two questions and this makes me still feel a little bit unsure about the whole situation... PS: At a mergemaster run I now got a problems which looks related: mv: /var/db/mergemaster.mtree: set flags (was: ): Invalid argument Yes, /var is also on ZFS here. Same problem as it looks. But I'm sure also this error did not occur in the past... -- r...@freebsd.orgRalf S. Engelschall FreeBSD.org/~rse r...@engelschall.com FreeBSD committer www.engelschall.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: Zfs on usb-disk checksum errors?
Ronald Klop wrote:
Hi.
I put zfs on my external usb-disk, so I can backup my harddisk with zfs
send/receive.
I now have corruption on this volume.
[r...@sjakie ~]# zpool status -v
pool: extern
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://www.sun.com/msg/ZFS-8000-8A
scrub: scrub completed after 0h2m with 0 errors on Wed Jul 8 00:35:09
2009
config:
NAMESTATE READ WRITE CKSUM
extern ONLINE 1 0 0
da0 ONLINE 9 0 0
errors: Permanent errors have been detected in the following files:
<0x3f>:<0xf5d6>
I don't really understand which files have corruption. :-(
In my syslog is this: (repeated quite often)
Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): SYNCHRONIZE
CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0
Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): CAM Status: SCSI
Status Error
Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): SCSI Status:
Check Condition
Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): ILLEGAL REQUEST
asc:20,0
Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): Invalid command
operation code
Jul 8 10:00:37 sjakie kernel: (da0:umass-sim0:0:0:0): Unretryable error
I experience the same error with 'Kingston DataTraveler II 1.13'. I
simply add in /usr/src/sys/dev/usb/usbdevs:
product KINGSTON DATATRAVELER_2 0x1600 DAtaTraveler II
(VENDOR was already in the file).
and in sys/dev/usb/storage/umass.c:
{ USB_VENDOR_KINGSTON, USB_PRODUCT_KINGSTON_DATATRAVELER_2,
RID_WILDCARD,
UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
NO_SYNCHRONIZE_CACHE
},
Note the flag NO_SYNCHRONIZE_CACHE and everything return to normal.
PS - I encounter this problem on 7.2_STABLE with the MFC of ZFS v13.
Henri
and sometimes
Jul 8 10:00:35 sjakie root: ZFS: vdev I/O failure, zpool=extern
path=/dev/da0 offset=127558877184 size=3072 error=5
Jul 8 10:00:35 sjakie root: ZFS: vdev I/O failure, zpool=extern
path=/dev/da0 offset=127558877184 size=3072 error=5
Jul 8 10:00:35 sjakie root: ZFS: zpool I/O failure, zpool=extern error=5
With varying offsets and sizes.
What can I conclude from this? Is the disk failing? Is the 'Invalid
command operation code' something to worry about? It didn't show up when
the disk was UFS.
I reinstalled the pool but the read-errors showed up again.
Thanks for any advice,
Ronald.
___
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"
8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when connecting with firefox to a local apache server using the global unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [r...@avoriaz ~]# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX ) status: active [r...@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if="em0" block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [r...@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet> quit Connection closed. [r...@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... --->Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if from ($int_if) to ($int_if:network) \ keep state flags any Then all is OK By the way, on 7.2 netstat -rn display 192.168.24.100:1d:60:ad:2a:ce 2001:41d0:2:2d29:1:1::00:1d:60:ad:2a:ce On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: Hope it may help someone 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"
8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when connecting with firefox to a local apache server using the global unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [r...@avoriaz ~]# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX ) status: active [r...@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if="em0" block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [r...@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet> quit Connection closed. [r...@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... --->Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if from ($int_if) to ($int_if:network) \ keep state flags any Then all is OK By the way, on 7.2 netstat -rn display 192.168.24.100:1d:60:ad:2a:ce 2001:41d0:2:2d29:1:1::00:1d:60:ad:2a:ce On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: Hope it may help someone 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: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
Li, Qing wrote: Hi, Please try patch-7-10 in my home directory http://people.freebsd.org/~qingli/ and let me know how it works out for you. I thought I had committed the patch but turned out I didn't. I apply the patch, reset my pf.conf to its previous content and all is running smoothly. By the way, I discover after my post that my "solution" was not working for long (many bytes) connections and this is solved too. Many thank for your time Henri PS please commit as soon as possible On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: This is by design as part of the new architecture in 8.0, which maintains the L2 ARP/ND6 and L3 routing tables separately. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org on behalf of Henri Hennebert Sent: Fri 7/10/2009 5:32 AM To: freebsd-stable@freebsd.org; freebsd...@freebsd.org Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when connecting with firefox to a local apache server using the global unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [r...@avoriaz ~]# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX ) status: active [r...@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if="em0" block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [r...@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet> quit Connection closed. [r...@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... --->Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if from ($int_if) to ($int_if:network) \ keep state flags any Then all is OK By the way, on 7.2 netstat -rn display 192.168.24.100:1d:60:ad:2a:ce 2001:41d0:2:2d29:1:1::00:1d:60:ad:2a:ce On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: Hope it may help someone 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" ___ 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: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections
Li, Qing wrote: The patch has been committed, svn revision 195643. Thanks, -- Qing Just another case where the route must be created: [r...@avoriaz ~]# ifconfig gif0 gif0: flags=8051 metric 0 mtu 1280 tunnel inet 212.239.166.57 --> 94.23.44.41 inet6 fe80::21d:60ff:fead:2ace%gif0 prefixlen 64 scopeid 0x4 inet6 2001:41d0:2:2d29:1::: --> 2001:41d0:2:2d29:0::: prefixlen 128 options=1 [r...@avoriaz ~]# ping6 2001:41d0:2:2d29:1::: PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1::: --> 2001:41d0:2:2d29:1::: ^C --- 2001:41d0:2:2d29:1::: ping6 statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss [r...@avoriaz ~]# route add -inet6 2001:41d0:2:2d29:1::: -interface lo0 add host 2001:41d0:2:2d29:1:::: gateway lo0 [r...@avoriaz ~]# ping6 2001:41d0:2:2d29:1::: PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1::: --> 2001:41d0:2:2d29:1::: 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.531 ms 16 bytes from ::1, icmp_seq=1 hlim=64 time=0.884 ms 16 bytes from ::1, icmp_seq=2 hlim=64 time=0.748 ms ^C --- 2001:41d0:2:2d29:1::: ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.531/0.721/0.884/0.145 ms Thanks Henri -Original Message- From: Henri Hennebert [mailto:h...@restart.be] Sent: Sat 7/11/2009 3:09 AM To: Li, Qing Cc: freebsd-stable@freebsd.org; freebsd-...@freebsd.org Subject: Re: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections Li, Qing wrote: Hi, Please try patch-7-10 in my home directory http://people.freebsd.org/~qingli/ and let me know how it works out for you. I thought I had committed the patch but turned out I didn't. I apply the patch, reset my pf.conf to its previous content and all is running smoothly. By the way, I discover after my post that my "solution" was not working for long (many bytes) connections and this is solved too. Many thank for your time Henri PS please commit as soon as possible On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: This is by design as part of the new architecture in 8.0, which maintains the L2 ARP/ND6 and L3 routing tables separately. -- Qing -Original Message- From: owner-freebsd-sta...@freebsd.org on behalf of Henri Hennebert Sent: Fri 7/10/2009 5:32 AM To: freebsd-stable@freebsd.org; freebsd...@freebsd.org Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections Hello, After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when connecting with firefox to a local apache server using the global unicast IPv6 address of the local machine. pf.conf must be updated! My configuration: [r...@avoriaz ~]# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=19b ether 00:1d:60:ad:2a:ce inet 192.168.24.1 netmask 0xff00 broadcast 192.168.24.255 inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 media: Ethernet 100baseTX (100baseTX ) status: active [r...@avoriaz ~]# host www.restart.bel www.restart.bel is an alias for avoriaz.restart.bel. avoriaz.restart.bel has address 192.168.24.1 avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: pf.conf: int_if="em0" block in log all block out log all set skip on lo0 antispoof quick for $int_if inet # Allow trafic with physical internal network pass in quick on $int_if from ($int_if:network) to ($int_if) keep state pass out quick on $int_if from ($int_if) to ($int_if:network) keep state The problem: [r...@avoriaz ~]# telnet -4 www.restart.bel 80 Trying 192.168.24.1... Connected to avoriaz.restart.bel. Escape character is '^]'. ^] telnet> quit Connection closed. [r...@avoriaz ~]# telnet -6 www.restart.bel 80 Trying 2001:41d0:2:2d29:1:1::... --->Never connect and get a timeout! tcpdump and logging in pf show me that For a IPv4 connection: the packet from telnet to apache pass 2 times on lo0 (out and in) the answer packet from apache to telnet pass 2 times on lo0 (out and in) So no problem, there is `set skip on lo0' For a IPv6 connection: The first packet from telnet to apache pass 2 times on lo0 (out and in) The answer packet from apache to telnet path on em0 and is rejected due to the default flags S/SA. So I have to change pf.conf and replace the last line: pass out quick on $int_if from ($int_if) to ($int_if:network) \ keep state flags any Then all is OK By the way, on 7.2 netstat -rn display 192.168.24.100:1d:60:ad:2a:ce 2001:41d0:2:2d29:1:1::00:1d:60:ad:2a:ce On 8.0-BETA1 there is an assymetry: netstat -rn display 192.168.24.1 link#3 no entry for 2001:41d0:2:2d29:1:1:: Hope it may help someone Henri
