Re: MFC: graid(8) (RAID GEOM) support
Jeremy Chadwick wrote: On Fri, Jun 17, 2011 at 05:51:24PM -0700, Jeremy Chadwick wrote: Sorry for the cross-post, but I thought both lists would want to know about this. Looks like mav@ just committed this ~17 hours ago: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/raid/g_raid.c Those who have historically wanted to use Intel MatrixRAID (now called Intel RST (Rapid Storage Technology)), but haven't due to the severe issues/risks with ataraid(4), will probably be very interested in this commit. I know I am! I plan on stress-testing the Intel support on a 2-disk system with RAID-1 enabled, and will document my experiences, procedures, etc... Thanks, mav@ and imp@ ! I'll be sending another mail momentarily asking about USB memory stick image building, since to accomplish the above, I want to do a bare-bones install on our test system (e.g. enable Intel RAID, set up 2 disks in a RAID-1 mirror, boot a USB memory stick that contains this latest RELENG_8 build, and do sysinstall, etc.. the normal way). = MFC r219974, r220209, r220210, r220790: Add new RAID GEOM class, that is going to replace ataraid(4) in supporting various BIOS-based software RAIDs. Unlike ataraid(4) this implementation does not depend on legacy ata(4) subsystem and can be used with any disk drivers, including new CAM-based ones (ahci(4), siis(4), mvs(4), ata(4) with `options ATA_CAM`). To make code more readable and extensible, this implementation follows modular design, including core part and two sets of modules, implementing support for different metadata formats and RAID levels. Support for such popular metadata formats is now implemented: Intel, JMicron, NVIDIA, Promise (also used by AMD/ATI) and SiliconImage. Such RAID levels are now supported: RAID0, RAID1, RAID1E, RAID10, SINGLE, CONCAT. For all of these RAID levels and metadata formats this class supports full cycle of volume operations: reading, writing, creation, deletion, disk removal and insertion, rebuilding, dirty shutdown detection and resynchronization, bad sector recovery, faulty disks tracking, hot-spare disks. For Intel and Promise formats there is support multiple volumes per disk set. Look graid(8) manual page for additional details. Co-authored by: imp Sponsored by: Cisco Systems, Inc. and iXsystems, Inc. = By the way, it doesn't look like the graid(8) man page is being brought in to the base system on either of the two RELENG_8 systems I've rebuilt in the past few days. I'm thinking /usr/src/sbin/geom/class/raid/graid.8 isn't being noticed as a man page. /usr/src/sbin/geom/class/raid/Makefile doesn't have MAN8=graid.8 in it, is that the problem? I've just rebuilt my test 8-STABLE system and it installed graid(8). -- Alexander Motin ___ 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: graid(8) (RAID GEOM) support
On Wed, Jun 22, 2011 at 12:02:50PM +0300, Alexander Motin wrote: Jeremy Chadwick wrote: On Fri, Jun 17, 2011 at 05:51:24PM -0700, Jeremy Chadwick wrote: Sorry for the cross-post, but I thought both lists would want to know about this. Looks like mav@ just committed this ~17 hours ago: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/geom/raid/g_raid.c Those who have historically wanted to use Intel MatrixRAID (now called Intel RST (Rapid Storage Technology)), but haven't due to the severe issues/risks with ataraid(4), will probably be very interested in this commit. I know I am! I plan on stress-testing the Intel support on a 2-disk system with RAID-1 enabled, and will document my experiences, procedures, etc... Thanks, mav@ and imp@ ! I'll be sending another mail momentarily asking about USB memory stick image building, since to accomplish the above, I want to do a bare-bones install on our test system (e.g. enable Intel RAID, set up 2 disks in a RAID-1 mirror, boot a USB memory stick that contains this latest RELENG_8 build, and do sysinstall, etc.. the normal way). = MFC r219974, r220209, r220210, r220790: Add new RAID GEOM class, that is going to replace ataraid(4) in supporting various BIOS-based software RAIDs. Unlike ataraid(4) this implementation does not depend on legacy ata(4) subsystem and can be used with any disk drivers, including new CAM-based ones (ahci(4), siis(4), mvs(4), ata(4) with `options ATA_CAM`). To make code more readable and extensible, this implementation follows modular design, including core part and two sets of modules, implementing support for different metadata formats and RAID levels. Support for such popular metadata formats is now implemented: Intel, JMicron, NVIDIA, Promise (also used by AMD/ATI) and SiliconImage. Such RAID levels are now supported: RAID0, RAID1, RAID1E, RAID10, SINGLE, CONCAT. For all of these RAID levels and metadata formats this class supports full cycle of volume operations: reading, writing, creation, deletion, disk removal and insertion, rebuilding, dirty shutdown detection and resynchronization, bad sector recovery, faulty disks tracking, hot-spare disks. For Intel and Promise formats there is support multiple volumes per disk set. Look graid(8) manual page for additional details. Co-authored by: imp Sponsored by: Cisco Systems, Inc. and iXsystems, Inc. = By the way, it doesn't look like the graid(8) man page is being brought in to the base system on either of the two RELENG_8 systems I've rebuilt in the past few days. I'm thinking /usr/src/sbin/geom/class/raid/graid.8 isn't being noticed as a man page. /usr/src/sbin/geom/class/raid/Makefile doesn't have MAN8=graid.8 in it, is that the problem? I've just rebuilt my test 8-STABLE system and it installed graid(8). Hmm, there must be something I'm missing either in the base system or the kernel or both. Does this kernel module and/or bits and pieces not get built unless it's included strictly in the kernel? Below is one of the two systems, looking for both graid* and geom_raid*. There's the old geom_raid3 stuff there, and the source bits/pieces for the new graid(8), but nothing seems built (including kernel module) for the new graid(8). If you'd like I can rm -fr /usr/src/* ; rm -fr /var/db/sup/src-all and then re-download source from an official cvsup mirror (I've been using cvsup9.freebsd.org for both boxes). icarus# uname -a FreeBSD icarus.home.lan 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Jun 17 18:01:45 PDT 2011 r...@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_8_amd64 amd64 icarus# find /usr -name graid* -ls 32111288 -r--r--r--1 root wheel2521 Jun 17 18:25 /usr/share/man/man8/graid3.8.gz 169318 16 -rw-r--r--1 root wheel6390 Aug 3 2009 /usr/src/sbin/geom/class/raid3/graid3.8 169624 16 -rw-r--r--1 root wheel8126 Jun 16 23:59 /usr/src/sbin/geom/class/raid/graid.8 9214308 -rw-r--r--1 root wheel2521 Jun 17 17:51 /usr/obj/usr/src/sbin/geom/class/raid3/graid3.8.gz 33693724 drwxr-xr-x2 root wheel 512 May 3 03:58 /usr/ports/sysutils/graid5 icarus# icarus# find /boot -name graid* -ls icarus# icarus# find /usr -name geom_raid* -ls 169317 20 -rw-r--r--1 root wheel9257 Jan 18 21:13 /usr/src/sbin/geom/class/raid3/geom_raid3.c 1652658 -rw-r--r--1 root wheel2992 Jun 16 23:59 /usr/src/sbin/geom/class/raid/geom_raid.c 2596524 drwxr-xr-x2 root wheel 512 Jun 6 06:28 /usr/src/sys/modules/geom/geom_raid3 285292
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
commit PR 154469, ftp-proxy(8) bug ?
Hi! Can someone have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=154469 and commit it ? So that it ends up in 8.3 8-} ? Thanks! -- p...@opsec.eu+49 171 3101372 9 years to go ! ___ 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 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
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 # (Recursive) + /* Messages */
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 push $0x10
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 case + stosb # Save char
ata: SIGNATURE: ffffffff
This is the 3rd disk I replace in 3 disk- Raiz1 pool and I really start to believe that the problem is somewhere else. The disks reside in a Promise PDC40718 SATA300 controller. I am running this set up since 8.0-Release with no issues till a few months ago after 8.2-Release now at 8.2-Stable. Symptoms: Jun 22 17:08:53 hp kernel: ata2: timeout waiting to issue command Jun 22 17:08:53 hp kernel: ata2: error issuing SETFEATURES ENABLE WCACHE command Jun 22 17:09:33 hp kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Jun 22 17:09:33 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558741 Jun 22 17:09:34 hp kernel: ata2: SIGNATURE: 0101 Jun 22 17:09:34 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558869 Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this device Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this device Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed After a while the disk gets detached from the pool. Always the same disk. Rite now I am in the process of resilvering : pool: tank state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Wed Jun 22 17:09:40 2011 189G scanned out of 578G at 88.8M/s, 1h14m to go 62.9G resilvered, 32.63% done config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0ONLINE 0 0 0 label/zdisk1 ONLINE 0 0 0 label/zdisk2 ONLINE 0 0 0 label/zdisk3 ONLINE 0 0 0 (resilvering) But those errors have started to appear again. Again this is the 3rd disk replaced !!! Full dmesg attached -- George Kontostanos aisecure.net http://www.aisecure.net Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #0: Mon Jun 6 19:00:19 EEST 2011 gkon...@hp.aicom.loc:/usr/obj/usr/src/sys/ML110G3 amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 3.20GHz (3200.13-MHz K8-class CPU) Origin = GenuineIntel Id = 0xf64 Family = f Model = 6 Stepping = 4 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe4bdSSE3,DTES64,MON,DS_CPL,VMX,EST,CNXT-ID,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4106780672 (3916 MB) ACPI APIC Table: HP OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: HP OEMXSDT on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 17 at device 28.5 on pci0 pci7: ACPI PCI bus on pcib2 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x004101 mem 0xfeaf-0xfeaf irq 17 at device 0.0 on pci7 bge0: CHIP ID 0x4101; ASIC REV 0x04; CHIP REV 0x41; PCI-E miibus0: MII bus on bge0 brgphy0: BCM5750 10/100/1000baseTX PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:13:21:cc:39:35 bge0: [ITHREAD] uhci0: Intel 82801G (ICH7) USB controller USB-A port 0xdc00-0xdc1f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: Intel 82801G (ICH7) USB controller USB-A on uhci0 uhci1: Intel 82801G (ICH7) USB controller USB-B port 0xd880-0xd89f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: Intel 82801G (ICH7) USB controller USB-B on uhci1 uhci2: Intel 82801G (ICH7) USB controller USB-C port 0xd800-0xd81f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: Intel 82801G (ICH7) USB controller USB-C on uhci2 ehci0: Intel 82801GB/R (ICH7) USB 2.0 controller mem 0xfe9ffc00-0xfe9f irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: Intel 82801GB/R (ICH7) USB 2.0 controller on ehci0 pcib3: ACPI
Re: ata: SIGNATURE: ffffffff
Forgot to mention, I have changed the SATA cables too. On Wed, Jun 22, 2011 at 5:52 PM, George Kontostanos gkontos.m...@gmail.comwrote: This is the 3rd disk I replace in 3 disk- Raiz1 pool and I really start to believe that the problem is somewhere else. The disks reside in a Promise PDC40718 SATA300 controller. I am running this set up since 8.0-Release with no issues till a few months ago after 8.2-Release now at 8.2-Stable. Symptoms: Jun 22 17:08:53 hp kernel: ata2: timeout waiting to issue command Jun 22 17:08:53 hp kernel: ata2: error issuing SETFEATURES ENABLE WCACHE command Jun 22 17:09:33 hp kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Jun 22 17:09:33 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558741 Jun 22 17:09:34 hp kernel: ata2: SIGNATURE: 0101 Jun 22 17:09:34 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558869 Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this device Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this device Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed After a while the disk gets detached from the pool. Always the same disk. Rite now I am in the process of resilvering : pool: tank state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Wed Jun 22 17:09:40 2011 189G scanned out of 578G at 88.8M/s, 1h14m to go 62.9G resilvered, 32.63% done config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0ONLINE 0 0 0 label/zdisk1 ONLINE 0 0 0 label/zdisk2 ONLINE 0 0 0 label/zdisk3 ONLINE 0 0 0 (resilvering) But those errors have started to appear again. Again this is the 3rd disk replaced !!! Full dmesg attached -- George Kontostanos aisecure.net http://www.aisecure.net -- George Kontostanos aisecure.net http://www.aisecure.net ___ 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: [poll / rfc] kdb_stop_cpus
on 04/06/2011 11:22 Andriy Gapon said the following:
commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016
generic_stop_cpus: move timeout detection code from under DIAGNOSTIC
... and also increase it a bit.
IMO it's better to detect and report the (rather serious) condition and
allow a system to proceed somehow rather than be stuck in an endless
loop.
diff --git a/sys/kern/subr_smp.c b/sys/kern/subr_smp.c
index ae52f4b..4bd766b 100644
--- a/sys/kern/subr_smp.c
+++ b/sys/kern/subr_smp.c
@@ -232,12 +232,10 @@ generic_stop_cpus(cpumask_t map, u_int type)
/* spin */
cpu_spinwait();
i++;
-#ifdef DIAGNOSTIC
- if (i == 10) {
+ if (i == 1) {
printf(timeout stopping cpus\n);
break;
}
-#endif
}
stopping_cpu = NOCPU;
I would like to commit the above, if nobody objects.
A to do item is adding some code to aid debugging of the timeout condition. I
discussed this with Attilio, he doesn't see this as a show-stopper and he plans
to
add the code at a later time.
--
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [poll / rfc] kdb_stop_cpus
on 03/06/2011 18:13 Andriy Gapon said the following: I wonder if anybody uses kdb_stop_cpus with non-default value. I would like to go ahead and remove kdb_stop_cpus tunable/sysctl if nobody objects. If, yes, I am very interested to learn about your usecase for it. I think that the default kdb behavior is the correct one, so it doesn't make sense to have a knob to turn on incorrect behavior. But I may be missing something obvious. The comment in the code doesn't really satisfy me: /* * Flag indicating whether or not to IPI the other CPUs to stop them on * entering the debugger. Sometimes, this will result in a deadlock as * stop_cpus() waits for the other cpus to stop, so we allow it to be * disabled. In order to maximize the chances of success, use a hard * stop for that. */ The hard stop should be sufficiently mighty. Yes, I am aware of supposedly extremely rare situations where a deadlock could happen even when using hard stop. But I'd rather fix that than have this switch. Oh, the commit message (from 2004) explains it: Add a new sysctl, debug.kdb.stop_cpus, which controls whether or not we attempt to IPI other cpus when entering the debugger in order to stop them while in the debugger. The default remains to issue the stop; however, that can result in a hang if another cpu has interrupts disabled and is spinning, since the IPI won't be received and the KDB will wait indefinitely. We probably need to add a timeout, but this is a useful stopgap in the mean time. But that was before we started using hard stop in this context (in 2009). -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS boot inside on the second partition inside a slice
On Wednesday, June 22, 2011 10:23:22 am Henri Hennebert wrote: On 06/22/2011 16:19, Henri Hennebert wrote: This time: LBA: 3c802308 Read error: 04 This morning I was reading the code (I'm in Belgium) and find that the previous LBA output was DAP+4 and so was the addr of the buffer. 0x8200 = $MEM_BUF+512, and so we must be in the second read. OK I think I see, the first read mangle the partition table previously read at $MEM_BUF and so the next one is wrong. Ahh, very true. I was planning to simplify the code to just load at MEM_BTX directly and avoid copying BTX. I went ahead and did that below: 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 +
Re: MFC: graid(8) (RAID GEOM) support
On Wed, 22 Jun 2011, Alexander Motin wrote: Jeremy Chadwick wrote: [..] Look graid(8) manual page for additional details. Co-authored by: imp Sponsored by: Cisco Systems, Inc. and iXsystems, Inc. = By the way, it doesn't look like the graid(8) man page is being brought in to the base system on either of the two RELENG_8 systems I've rebuilt in the past few days. I'm thinking /usr/src/sbin/geom/class/raid/graid.8 isn't being noticed as a man page. /usr/src/sbin/geom/class/raid/Makefile doesn't have MAN8=graid.8 in it, is that the problem? I've just rebuilt my test 8-STABLE system and it installed graid(8). I don't know if it's possibly related, or just that ongoing? issue with some? new manpages not making it into man.cgi but .. http://www.freebsd.org/cgi/man.cgi?query=graidapropos=0sektion=0manpath=FreeBSD+8.2-stableformat=html isn't working either, nor even for 9-current: Sorry, no data found for `graid'. Please try a keyword search. 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
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 +
Re: ata: SIGNATURE: ffffffff
I have also changed the SATA port in the controller! I am afraid that I might get a new controller and still have the same issues. I just want to eliminate any other options first. On Wed, Jun 22, 2011 at 7:41 PM, Chris Brennan xa...@xaerolimit.net wrote: * George Kontostanos gkontos.m...@gmail.com [2011-06-22 18:48:45 +0300]: Forgot to mention, I have changed the SATA cables too. Just a stab in the dark here ... but since you mention the same disk almost being removed from the raidz1, maybe the port on the card is bad? if you've replaced the disk and the cable(s), then what is left? The card. -- Chris Brennan -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon? http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) -- George Kontostanos aisecure.net http://www.aisecure.net ___ 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: ata: SIGNATURE: ffffffff
* George Kontostanos gkontos.m...@gmail.com [2011-06-22 18:48:45 +0300]: Forgot to mention, I have changed the SATA cables too. Just a stab in the dark here ... but since you mention the same disk almost being removed from the raidz1, maybe the port on the card is bad? if you've replaced the disk and the cable(s), then what is left? The card. -- Chris Brennan -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon? http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) ___ 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: ata: SIGNATURE: ffffffff
* George Kontostanos gkontos.m...@gmail.com [2011-06-22 19:58:50 +0300]: I have also changed the SATA port in the controller! I am afraid that I might get a new controller and still have the same issues. I just want to eliminate any other options first. Don't top post, it's against list policy. See my siganture for a reasonable reason why. Replace the port or just moved the drive to an unused port? Or did you physically remove the card and solder a new SATA Female port to your card (which I would imagine would violate/void your warranty on the card. Essentially this is what you've done so far: 1. Changed drives 2. Changed SATA Cable 3. Moved to an unused port To be perfectly honest, it sounds like a faulty card, which was my original assessment. First I would see replacement on the same card under the warranty, if it still produces a problem, I would change cards. There is a slim chance it could also be a driver issue. -- Chris Brennan -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon? http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) --- ___ 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 Wednesday, June 22, 2011 12:48:43 pm Henri Hennebert wrote: No error message but a reboot... I add: loop main.6 # If not last, read another mov $msg_debug,%si call putstr mov $MEM_BTX,%si# BTX .. msg_debug: .asciz @\r\n I don't get the @ on the console :-( Hmm, so it never exits the loop? PS - I have to keep a short message otherwise: /usr/src/sys/boot/i386/zfsboot/zfsldr.S:322: Error: attempt to move .org backwards Yeah, it's getting tight. I've commented the LBA printing bits out (so there is more room to play with) and made it print out a . for each disk sector read: 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
Re: commit PR 154469, ftp-proxy(8) bug ?
On Wednesday, June 22, 2011 8:11:36 am Kurt Jaeger wrote: Hi! Can someone have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=154469 and commit it ? So that it ends up in 8.3 8-} ? Does the patch from OpenBSD fix the problem for you? -- John Baldwin ___ 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: ata: SIGNATURE: ffffffff
You already mentioned your thought about a faulty card. If you don't have to add anything beyond that then please keep it for yourself. On Wed, Jun 22, 2011 at 8:13 PM, Chris Brennan xa...@xaerolimit.net wrote: * George Kontostanos gkontos.m...@gmail.com [2011-06-22 19:58:50 +0300]: I have also changed the SATA port in the controller! I am afraid that I might get a new controller and still have the same issues. I just want to eliminate any other options first. Don't top post, it's against list policy. See my siganture for a reasonable reason why. -- George Kontostanos aisecure.net http://www.aisecure.net ___ 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: commit PR 154469, ftp-proxy(8) bug ?
On Jun 22, 2011, at 12:11 PM, Kurt Jaeger wrote: Hi! Can someone have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=154469 I have a pf45 universe tree sitting here with the works from max and ermal that needs to go in; without checking specifically it should have the fix and the fix could possibly be merges to 8 from there then but knowing that just this fix applied to stable/8 works would be good for that. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ 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: commit PR 154469, ftp-proxy(8) bug ?
Hi! Can someone have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=154469 and commit it ? So that it ends up in 8.3 8-} ? Does the patch from OpenBSD fix the problem for you? Yes, sure. That why I sent the pr! -- p...@opsec.eu+49 171 3101372 9 years to go ! ___ 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: ata: SIGNATURE: ffffffff
* George Kontostanos gkontos.m...@gmail.com [2011-06-23 00:43:09 +0300]: You already mentioned your thought about a faulty card. If you don't have to add anything beyond that then please keep it for yourself. And yet, your still top posting. I was only pointing out the logical conclusion here. You've tried the obvious, time to move up the chain. I'm sorry you don't happen to like that but there is no need to be rude about it. -- Chris Brennan -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon? http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) ___ 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: ata: SIGNATURE: ffffffff
Look, I think that this is getting personal and not constructive at all. Stop mumbling unless you have something useful to add. Like pointing out a old PR regarding this controller: http://www.freebsd.org/cgi/query-pr.cgi?pr=116935cat= Best Regards, On Thu, Jun 23, 2011 at 1:44 AM, Chris Brennan xa...@xaerolimit.net wrote: * George Kontostanos gkontos.m...@gmail.com [2011-06-23 00:43:09 +0300]: You already mentioned your thought about a faulty card. If you don't have to add anything beyond that then please keep it for yourself. And yet, your still top posting. I was only pointing out the logical conclusion here. You've tried the obvious, time to move up the chain. I'm sorry you don't happen to like that but there is no need to be rude about it. -- Chris Brennan -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon? http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) -- George Kontostanos aisecure.net http://www.aisecure.net ___ 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: ata: SIGNATURE: ffffffff
On Wed, Jun 22, 2011 at 05:52:39PM +0300, George Kontostanos wrote: This is the 3rd disk I replace in 3 disk- Raiz1 pool and I really start to believe that the problem is somewhere else. The disks reside in a Promise PDC40718 SATA300 controller. I am running this set up since 8.0-Release with no issues till a few months ago after 8.2-Release now at 8.2-Stable. Symptoms: Jun 22 17:08:53 hp kernel: ata2: timeout waiting to issue command Jun 22 17:08:53 hp kernel: ata2: error issuing SETFEATURES ENABLE WCACHE command Jun 22 17:09:33 hp kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Jun 22 17:09:33 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558741 Jun 22 17:09:34 hp kernel: ata2: SIGNATURE: 0101 Jun 22 17:09:34 hp kernel: ad4: WARNING - WRITE_DMA48 requeued due to channel reset LBA=321558869 Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this device Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed Jun 22 17:09:34 hp kernel: ata2: FAILURE - already active DMA on this device Jun 22 17:09:34 hp kernel: ata2: setting up DMA failed After a while the disk gets detached from the pool. Always the same disk. Rite now I am in the process of resilvering : pool: tank state: ONLINE status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Wed Jun 22 17:09:40 2011 189G scanned out of 578G at 88.8M/s, 1h14m to go 62.9G resilvered, 32.63% done config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz1-0ONLINE 0 0 0 label/zdisk1 ONLINE 0 0 0 label/zdisk2 ONLINE 0 0 0 label/zdisk3 ONLINE 0 0 0 (resilvering) But those errors have started to appear again. Again this is the 3rd disk replaced !!! Full dmesg attached -- George Kontostanos aisecure.net http://www.aisecure.net Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-STABLE #0: Mon Jun 6 19:00:19 EEST 2011 gkon...@hp.aicom.loc:/usr/obj/usr/src/sys/ML110G3 amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) D CPU 3.20GHz (3200.13-MHz K8-class CPU) Origin = GenuineIntel Id = 0xf64 Family = f Model = 6 Stepping = 4 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe4bdSSE3,DTES64,MON,DS_CPL,VMX,EST,CNXT-ID,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4106780672 (3916 MB) ACPI APIC Table: HP OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: HP OEMXSDT on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge irq 17 at device 28.5 on pci0 pci7: ACPI PCI bus on pcib2 bge0: Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x004101 mem 0xfeaf-0xfeaf irq 17 at device 0.0 on pci7 bge0: CHIP ID 0x4101; ASIC REV 0x04; CHIP REV 0x41; PCI-E miibus0: MII bus on bge0 brgphy0: BCM5750 10/100/1000baseTX PHY PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:13:21:cc:39:35 bge0: [ITHREAD] uhci0: Intel 82801G (ICH7) USB controller USB-A port 0xdc00-0xdc1f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: Intel 82801G (ICH7) USB controller USB-A on uhci0 uhci1: Intel 82801G (ICH7) USB controller USB-B port 0xd880-0xd89f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: Intel 82801G (ICH7) USB controller USB-B on uhci1 uhci2: Intel 82801G (ICH7) USB controller USB-C port 0xd800-0xd81f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: Intel 82801G (ICH7) USB controller USB-C on uhci2 ehci0: Intel 82801GB/R (ICH7) USB 2.0
Re: ata: SIGNATURE: ffffffff
On 23 Jun 2011, at 01:02, George Kontostanos gkontos.m...@gmail.com wrote: Look, I think that this is getting personal and not constructive at all. Stop mumbling unless you have something useful to add. How about you do what he says and stop top posting, as per the list's policy ? Annoying pretty much everyone in the list with your stubbornness about top posting and your misplaced rudeness towards a helper might result in a drop in the number of people willing to spend time helping you. This being said, have you tried using a different PSU ?___ 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: ata: SIGNATURE: ffffffff
* Damien Fleuriot m...@my.gd [2011-06-23 03:56:54 +0200]: On 23 Jun 2011, at 01:02, George Kontostanos gkontos.m...@gmail.com wrote: Look, I think that this is getting personal and not constructive at all. Stop mumbling unless you have something useful to add. How about you do what he says and stop top posting, as per the list's policy ? Annoying pretty much everyone in the list with your stubbornness about top posting and your misplaced rudeness towards a helper might result in a drop in the number of people willing to spend time helping you. This will be my last post on this topic. George you are rude and I know I will not be offering any more suggestions for you. I foresee few others willing to help you now as well. Jeremy has willingly given you a great amount of detail to work with and it's up to him to look past your rude behavior and continue to help you. -- Chris Brennan -- A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting frowned upon? http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C) ___ 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: ata: SIGNATURE: ffffffff
On Wed, Jun 22, 2011 at 11:08:57PM -0400, Chris Brennan wrote: * Damien Fleuriot m...@my.gd [2011-06-23 03:56:54 +0200]: On 23 Jun 2011, at 01:02, George Kontostanos gkontos.m...@gmail.com wrote: Look, I think that this is getting personal and not constructive at all. Stop mumbling unless you have something useful to add. How about you do what he says and stop top posting, as per the list's policy ? Annoying pretty much everyone in the list with your stubbornness about top posting and your misplaced rudeness towards a helper might result in a drop in the number of people willing to spend time helping you. This will be my last post on this topic. George you are rude and I know I will not be offering any more suggestions for you. I foresee few others willing to help you now as well. Jeremy has willingly given you a great amount of detail to work with and it's up to him to look past your rude behavior and continue to help you. off-topic The difference is that I really don't care if people top-post, bottom-post, or respond in-line. I work with whatever I'm presented with. I personally use all 3 methods depending upon the context is and what mailing list rules allow/permit. But it varies per list, and some lists have zealots that absolutely despise top-posting (even if the list permits it). I fully acknowledge that the FreeBSD lists advocate and insist upon in-line or bottom-post replies, and I honour that -- as should George. But let's be reasonable: there's a problem at hand that George is needing help with. The last thing a person under duress (re: in a situation like this) needs is to be lectured about not confirming to mailing list style. I say this knowing that conforming to said list style is important, however. I tend to keep my style conformity requests very terse and mentioned as one-liners at the bottom of the mail, e.g. P.S. -- Folks here don't like top-posting, please try to avoid it if you can, thanks!. Otherwise all it does is irritate an already-irritated person who's in need of assistance. Remember: they took the time to ask for help, which in this day and age is practically a miracle. /off-topic -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: ata: SIGNATURE: ffffffff
On 06/23/2011 14:05, Jeremy Chadwick wrote: [..] off-topic The difference is that I really don't care if people top-post, bottom-post, or respond in-line. I work with whatever I'm presented with. +1 cheers, gja ___ 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: commit PR 154469, ftp-proxy(8) bug ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kurt Jaeger wrote: Hi! Can someone have a look at http://www.freebsd.org/cgi/query-pr.cgi?pr=154469 and commit it ? So that it ends up in 8.3 8-} ? Does the patch from OpenBSD fix the problem for you? Yes, sure. That why I sent the pr! Yep, the patch does the right thing: Setup: FTP server: 87.51.34.132 (ftp.freebsd.org) FTP client: 10.11.0.8 (stock freebsd ftp client) GW with pf ftp-proxy (FreeBSD 7.3) ext: em0 77.73.232.13 int: vlan3 10.11.0.1 FTP session: 23:50 [0] bibi# ftp -a 87.51.34.132 Connected to 87.51.34.132. 220 ftp.beastie.tdk.net FTP server (Version 6.00LS) ready. 331 Guest login ok, send your email address as password. 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp quit TCPDUMP (10.11.0.8 em0): (-lnpAs0 host 87.51.34.132) 23:51:39.487136 IP 10.11.0.8.47376 87.51.34.132.21: Flags [P.], ack 303, win 8326, options [nop,nop,TS val 458938281 ecr 1611018784], length 6 E..:b.@.@.TW ...W3...E... .Z..`.2 QUIT 23:51:39.530414 IP 87.51.34.132.21 10.11.0.8.47376: Flags [F.], seq 303, ack 56, win 4163, options [nop,nop,TS val 1611020954 ecr 458938281], length 0 E..4..@.@...W3. .ECT.. `.:..Z.. Note 'server' silently closing connection TCPDUMP (GW em0): 23:56:20.405425 IP 77.73.232.13.61168 87.51.34.132.21: P 50:56(6) ack 303 win 4163 nop,nop,timestamp 2027802761 1933653527 W3.dn.C... x...sA6.QUIT 23:56:20.448332 IP 87.51.34.132.21 77.73.232.13.61168: . ack 56 win 257 nop,nop,timestamp 1933655700 2027802761 dn sA.x... 23:56:20.448345 IP 87.51.34.132.21 77.73.232.13.61168: P 303:317(14) ack 56 win 257 nop,nop,timestamp 1933655700 2027802761 dn...8. sA.x...221 Goodbye. 23:56:20.448353 IP 87.51.34.132.21 77.73.232.13.61168: F 317:317(0) ack 56 win 257 nop,nop,timestamp 1933655700 2027802761 dn sA.x... Note real server transmits '221 Goodbye' After applying patch: 23:54 [0] bibi# ftp -a 87.51.34.132 Connected to 87.51.34.132. 220 ftp.beastie.tdk.net FTP server (Version 6.00LS) ready. 331 Guest login ok, send your email address as password. 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp quit 221 Goodbye. Note '221 Goodvye' received by ftp client -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4CzWYACgkQwcJ4iSZ1q2lOcwCfYqknB9i1P7bfjgYVpSjkSWP1 Y8wAn3hC2pZ/OHDicCN+o3v1O5YiFZ8W =dqk/ -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
