misc/161324: Patch to solve build problem for www/axis2

2011-10-06 Thread Emil 

>Number: 161324
>Category:   misc
>Synopsis:   Patch to solve build problem for www/axis2
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Oct 06 08:00:18 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Emil
>Release:8.2-RELEASE
>Organization:
>Environment:
FreeBSD d07r1508.local 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Fri Feb 18 02:24:46 
UTC 2011 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
>Description:
www/axis2 is broken during installation as per 
http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.8.20110926093045/axis2-1.6.1.log

It seemed to me as if the problem was a missing /usr/local/bin/unzip binary. 

I solved this by adding a build dependency to archivers/unzip
>How-To-Repeat:
Build www/axis2 on pointyhat cluster
>Fix:
Apply patch to Makefile in www/axis2:
"
26a27,28
> BUILD_DEPENDS+=${PORTSDIR}/archivers/unzip
>
"


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

misc/162952: Problems including netinet/tcp_var.h

2011-11-29 Thread Emil 

>Number: 162952
>Category:   misc
>Synopsis:   Problems including netinet/tcp_var.h
>Confidential:   no
>Severity:   non-critical
>Priority:   medium
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Nov 29 19:20:08 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Emil
>Release:8.2-RELEASE
>Organization:
>Environment:
FreeBSD $HOSTNAME.local 8.2-RELEASE FreeBSD 8.2-RELEASE #3: Sat Apr 16 09:20:53 
CEST 2011 emil@$HOSTNAME.local:/usr/obj/usr/src/sys/IPSEC  i386

>Description:
When attempting to include netinet/tcp_var.h in a c++ file, the compiler throws 
a number of errors. 

"In file included from INPUT.cpp:1:
/usr/include/netinet/tcp_var.h:51: error: expected ';' before 'tqe_q'
/usr/include/netinet/tcp_var.h:56: error: expected constructor, destructor, or 
type conversion before '(' token
/usr/include/netinet/tcp_var.h:67: error: expected ';' before 'scblink'
/usr/include/netinet/tcp_var.h:102: error: field 't_segq' has incomplete type
/usr/include/netinet/tcp_var.h:184: error: 'sackhole_head' has not been declared
/usr/include/netinet/tcp_var.h:184: error: expected ';' before 'snd_holes'
/usr/include/netinet/tcp_var.h:318: error: expected ';' before 'tw_2msl'"

I am assuming that I am missing an include, as such I have filed this as a 
documentation bug. 
>How-To-Repeat:
execute "c++ INPUT" 

INPUT.cpp

1 #include 
2
3 using namespace std;
4
5 int main() {
6 return 0;
7 }

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

misc/173598: torrents.freebsd.org seems to be down

2012-11-13 Thread Emil 

>Number: 173598
>Category:   misc
>Synopsis:   torrents.freebsd.org seems to be down
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Nov 13 09:30:00 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator: Emil
>Release:Not Applicable
>Organization:
>Environment:
>Description:
torrents.freebsd.org seems to be down. 
I can not reach the website nor the tracker. My torrents are not being 
uploaded. 

>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

Re: bin/174711: [fdc] Floppy drive 5.25" 360Kb bug.

2013-05-05 Thread Emil Mamedov 
The following reply was made to PR bin/174711; it has been noted by GNATS.

From: Emil Mamedov 
To: freebsd-gnats-sub...@freebsd.org, freebsd-i...@freebsd.org
Cc:  
Subject: Re: bin/174711: [fdc] Floppy drive 5.25" 360Kb bug.
Date: Sun, 5 May 2013 07:54:03 -0700 (PDT)

 --630850330-1557395377-1367765643=:41507
 Content-Type: text/plain; charset=iso-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 Dear reader!
 
 I've seen my old bug report about 5.25" DD floppy disk. During last months,
 I've fixed numerious bugs in the standart FreeBSD 8.3 floppy driver (fdc.c)
 and floppy utilites.=20
 
 First.
 The file fdcio.c set has #define for DD disk in HD drive, but #define for
 DD disk in DD drive has missed. I changed transfer rate from 300kbps to 250=
 kbps
 and also sector gap from 0x23 to 0x2A. However DD disks in HD drives
 need to speed 300kbps and sector gap 0x23.
 
 Second.
 I've found that my DD floppy drive has "Ready" signal (pin 34)
 instead "Disk Change". I've opened RY jumper and was able to mount diskette=
 .
 I set fd.0.flags=3D"0x10"(drive doesn't support changeline),
 but this flag hasn't effect. In the case of RY jumper is installed,
 I can not mount DD floppy. Flag FD_NO_CHLINE doesn't work properly.
 
 Third.
 System doesn't detect absence disk in the DD FDD and too long
 positions floppy drive heads during boot process.
 
 Fourth.
 System anomally long unmount diskettes (previously mount with:
 mount_msdos -o rw
 even if I did not made writing files to diskette! I really don't sure
 that is a bag, maybe it is the feature of file systems' driver?
 
 Fifth.
 Autoselect floppy works properly in the case DD floppy disk in a 1.2Mb(HD) =
 FDD,
 flag FL_2STEP  set properly. But I can read cylinder 0 only (first 18 secto=
 rs).
 Under MS-DOS DD disk in HD drive is read/wrote properly. I seem that code
 appropriating  FL_2STEP flag doesn't works properly.
 
 Sixth.
 When I run fdformat utility question "y/n" appears.
 But if I print "n" system long positions  heads and only after=20
 this returns to command prompt. I think, system must be returning
 to command prompt immediately after "n".
 
 My modifications.
 I've added code which recognize FD_NO_CHLINE flag, changed function fdautos=
 elect
 (for found sectors per track), corrected and renamed #define variables in f=
 dcio.h
 
 I've found that implied seek (on enhanced fdc) make 2step operations
 impossible. I've added code by disabling implied seek when FL_2STEP
 flag is enable. Also, I've made many small changes.
 
 In the fdcontrol utility I've exluded unnecesarry flag [-a].
 I've found flag [-d dbg] in the fdcontrol "usage", but this flag
 doesn't appropriating code. I've deleted [-d] flag from "usage".
 I've deleted string return(0) from if (showfmt)...{} operator.
 Also, I've made some small changes.
 
 In the fdformat utility I've exluded y/n request.
 
 Also, I've edited the file fdutil.c and made small changed in the fdcontrol
 and fdformat man pages.
 The file fdcio.h has in the 2 location: "/usr/include/sys" and "/usr/sys/sy=
 s".
 
 All my changes in the attachment tarball floppy.tgz.
 I hope for you authority comments.
 With kindest regards, Emil.
 
 --- On Tue, 12/25/12, freebsd-gnats-sub...@freebsd.org  wrote:
 
 From: freebsd-gnats-sub...@freebsd.org 
 Subject: Re: i386/174711: Floppy drive 5.25" 360Kb bug.
 To: "Emil Mamedov" 
 Date: Tuesday, December 25, 2012, 11:40 PM
 
 Thank you very much for your problem report.
 It has the internal identification `i386/174711'.
 The individual assigned to look at your
 report is: freebsd-i386.=20
 
 You can access the state of your problem report at any time
 via this link:
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D174711
 
 >Category:=A0 =A0 =A0=A0=A0i386
 >Responsible:=A0 =A0 freebsd-i386
 >Synopsis:=A0 =A0 =A0=A0=A0Floppy drive 5.25" 360Kb bug.
 >Arrival-Date:=A0=A0=A0Wed Dec 26 07:40:00 UTC 2012
 --630850330-1557395377-1367765643=:41507
 Content-Type: application/x-gzip; name="floppy.tgz"
 Content-Transfer-Encoding: base64
 Content-Disposition: attachment; filename="floppy.tgz"
 
 H4sIAHCzhlEAA+y9fX8aR7IofP6FT9FR1jY4CAGSLEWKk8UC2ZxIQgvIjp/E
 P3YEgzRrmCHMIFm78f3sT711T88LSHac3XvuieJIMNNd3V1dXV1dXS+T8Wg4
 C8be5G5rMh5VR//1B/zUarVnOzsK/tb3duv4F3/kb31np/GsruqN2t7e9s6z
 xrNnCp416nv/pWp/RGfSP8swchbQlcgNo3Xlbq9dd7rmfWJQ8Pd/yM/W082i
 eqqOgvndwru6jlRpVFaNWm1HnQfL6eYr1/c9/0r96Mzm2XL1b7+tqcG1q3ru
 letHoQomKoKvF7534y5CL7rDJ0fO1JsEC99zqgiiOZ0qAhGqhRu6ixt3jM/x
 1eDaC9UoGLsK/o7dBUAZq8kimKkwmES3zsKFt3608C6XEbyJAvXCXbx3p+6d
 urxDAK3AV81rX8M78S4XbgTFzo9OjzpNNZkG8/mdCpfzebCIoI5qOTfeWL0K
 FrdeBGMaX/Onvy5H4bjqjpdlBON4Y2gNSuPYTjx/+UFDGmMXF4oWkDdyIi/w
 Q+4wA37hRO7M8RFIaXzJX/7q+lfVZRQi+KqzLOvOZlC7XcHfOzI09Y/RX

Re: bin/174711: [fdc] Floppy drive 5.25" 360Kb bug.

2013-05-07 Thread Emil Mamedov 
The following reply was made to PR bin/174711; it has been noted by GNATS.

From: Emil Mamedov 
To: freebsd-gnats-sub...@freebsd.org, freebsd-i...@freebsd.org
Cc:  
Subject: Re: bin/174711: [fdc] Floppy drive 5.25" 360Kb bug.
Date: Tue, 7 May 2013 08:26:57 -0700 (PDT)

 My previous tarball has been corrupted and I've attached
 floppy-diff files to message body:
 
 --- fdc.c.org  2012-03-03 06:15:13.0 +
 +++ fdc.c  2013-01-21 23:18:14.0 +
 @@ -136,33 +136,35 @@
   */
  
  static struct fd_type fd_searchlist_360k[] = {
 -  { FDF_5_360 },
 +  { FDD_5_360 | FL_AUTO},
 +  { FDD_5_180 | FL_AUTO},
{ 0 }
  };
  
  static struct fd_type fd_searchlist_12m[] = {
 -  { FDF_5_1200 | FL_AUTO },
 -  { FDF_5_360 | FL_2STEP | FL_AUTO},
 +  { FHD_5_1200 | FL_AUTO },
 +  { FHD_5_360  | FL_2STEP | FL_AUTO},
 +  { FHD_5_180  | FL_2STEP | FL_AUTO},
{ 0 }
  };
  
  static struct fd_type fd_searchlist_720k[] = {
 -  { FDF_3_720 },
 +  { FHD_3_720 },
{ 0 }
  };
  
  static struct fd_type fd_searchlist_144m[] = {
 -  { FDF_3_1440 | FL_AUTO},
 -  { FDF_3_720 | FL_AUTO},
 +  { FHD_3_1440 | FL_AUTO},
 +  { FHD_3_720  | FL_AUTO},
{ 0 }
  };
  
  static struct fd_type fd_searchlist_288m[] = {
 -  { FDF_3_1440 | FL_AUTO },
 +  { FHD_3_1440 | FL_AUTO },
  #if 0
 -  { FDF_3_2880 | FL_AUTO }, /* XXX: probably doesn't work */
 +  { FHD_3_2880 | FL_AUTO }, /* XXX: probably doesn't work */
  #endif
 -  { FDF_3_720 | FL_AUTO},
 +  { FHD_3_720 | FL_AUTO},
{ 0 }
  };
  
 @@ -297,7 +299,7 @@
  fdprinttype(struct fd_type *ft)
  {
  
 -  printf("(%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,0x%x)",
 +  printf("(%d,%d,0x%x,0x%x,%d,%d,%d,%d,0x%x,%d,%d,0x%x)\n",
ft->sectrac, ft->secsize, ft->datalen, ft->gap, ft->tracks,
ft->size, ft->trans, ft->heads, ft->f_gap, ft->f_inter,
ft->offset_side2, ft->flags);
 @@ -856,7 +858,8 @@
return (fdc_biodone(fdc, ENXIO));
  
/* Check if we lost our media */
 -  if (fdin_rd(fdc) & FDI_DCHG) {
 +  if ((fdin_rd(fdc) & FDI_DCHG) &&
 +  !(device_get_flags(fd->dev) & FD_NO_CHLINE)) {
if (debugflags & 0x40)
printf("Lost disk\n");
mtx_lock(&fdc->fdc_mtx);
 @@ -884,7 +887,7 @@
  
mfm = (fd->ft->flags & FL_MFM)? NE7CMD_MFM: 0;
steptrac = (fd->ft->flags & FL_2STEP)? 2: 1;
 -  i = fd->ft->sectrac * fd->ft->heads;
 +  i = fd->ft->sectrac * fd->ft->heads; //sectors per cyl
cylinder = bp->bio_pblkno / i;
descyl = cylinder * steptrac;
sec = bp->bio_pblkno % i;
 @@ -928,6 +931,22 @@
 * Enhanced controllers do implied seeks for read&write as long as
 * we do not need multiple steps per track.
 */
 +   /* But if DD diskette in HD FDD then disable do implied seek */
 +  if (fdc->fdct == FDC_ENHANCED) {
 +  int imp_seek;
 +  if (fd->ft->flags & FL_2STEP) imp_seek = 0x00;
 +  else  imp_seek = 0x40;  
 +  if (fdc_cmd(fdc, 4,
 +  I8207X_CONFIG,
 +  0,
 +  imp_seek |  /* Disable/Enable  Implied Seek */
 +  0x10 |  /* Polling disabled */
 +  (fifo_threshold - 1),   /* Fifo threshold */
 +  0x00,   /* Precomp track */
 +  0))
 +  device_printf(fdc->fdc_dev,
 +  " CONFIGURE failed\n");
 +  }
if (cylinder != fd->track && (
fdc->fdct != FDC_ENHANCED ||
descyl != cylinder ||
 @@ -1229,7 +1248,9 @@
if (fdc_sense_int(fdc, &st0, &cyl) == FD_NOT_VALID)
goto done;  /* XXX */
*recal |= (1 << fd->fdsu);
 -  if (fdin_rd(fdc) & FDI_DCHG) {
 +  
 +  if ((fdin_rd(fdc) & FDI_DCHG) &&
 +  !(device_get_flags(fd->dev) & FD_NO_CHLINE)) {
if (debugflags & 0x40)
printf("Empty in probe\n");
mtx_lock(&fdc->fdc_mtx);
 @@ -1238,8 +1259,8 @@
} else {
if (fdc_sense_drive(fdc, &st3) != 0)
goto done;
 -  if (debugflags & 0x40)
 -  printf("Got disk in probe\n");
 +//if (debugflags & 0x40)
 +//printf("Got disk in probe\n");
mtx_lock(&fdc->fdc_mtx);
fd->flags &= ~FD_EMPTY;
if (st3 & NE7_ST3_WP)
 @@ -1341,37 +1362,61 @@
 * Stepping to cylin

kern/151910: [zfs] booting from raidz/raidz2 on ciss(4) doesn't work

2010-11-03 Thread Emil Smolenski 

>Number: 151910
>Category:   kern
>Synopsis:   [zfs] booting from raidz/raidz2 on ciss(4) doesn't work
>Confidential:   no
>Severity:   serious
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Nov 03 09:40:10 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Emil Smolenski
>Release:FreeBSD 8.1-RELEASE
>Organization:
>Environment:
FreeBSD  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
>Description:
FreeBSD 8.1 installed using Fixit# environment on HP Proliant 185 G5 with HP 
SmartArray does not boot from ZFS pool in raidz or raidz2 setup. Mirror-based 
configurations work as expected.

There are 6 disks, each configured on HP SmartArray as single disk RAID0 array. 
Thus there are 6 logical devices (da[0-5]).

System information gathered from Fixit# environment:

# dmesg
(...)
ciss0:  port 0xe800-0xe8ff mem 
0xdef0-0xdeff,0xdeeff000-0xdeef irq 35 at device 0.0 on pci4
ciss0: PERFORMANT Transport
ciss0: [ITHREAD]
(...)
da0 at ciss0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SCSI-5 device
da0: 135.168MB/s transfers
da0: Command Queueing enabled
da0: 1430767MB (2930211632 512 byte sectors: 255H 32S/T 65535C)
(...)
da1 at ciss0 bus 0 scbus0 target 1 lun 0
(...)
da2 at ciss0 bus 0 scbus0 target 2 lun 0
(...)
da3 at ciss0 bus 0 scbus0 target 3 lun 0
(...)
da4 at ciss0 bus 0 scbus0 target 4 lun 0
(...)
da5 at ciss0 bus 0 scbus0 target 5 lun 0
(...)

# diskinfo -v da0
da0
512 # sectorsize
1500268355584   # mediasize in bytes (1.4T)
2930211632  # mediasize in sectors
0   # stripesize
0   # stripeoffset
359094  # Cylinders according to firmware.
255 # Heads according to firmware.
32  # Sectors according to firmware.
PAFGL0T9SXH13E  # Disk ident.
(...)

# camcontrol devlist -v
scbus0 on ciss0 bus 0:
 at scbus0 target 0 lun 0 (da0,pass0)
 at scbus0 target 1 lun 0 (da1,pass1)
 at scbus0 target 2 lun 0 (da2,pass2)
 at scbus0 target 3 lun 0 (da3,pass3)
 at scbus0 target 4 lun 0 (da4,pass4)
 at scbus0 target 5 lun 0 (da5,pass5)
scbus1 on ciss0 bus 32:
scbus-1 on xpt0 bus 0:
<> at scbus-1 target -1 lun -1 (xpt0)

# pciconf -lv
(...)
ci...@pci0:4:0:0:   class=0x010400 card=0x3234103c chip=0x3230103c rev=0x04 
hdr=0x00
class  = mass storage
subclass   = RAID
(...)

I've done several tests with different configurations. Common setup:

Each logical device (array) has GPT scheme with following partitions:

=>34  2930211565  da0  GPT  (1.4T)
  34 1281  freebsd-boot  (64K)
 162 20971522  freebsd-swap  (1.0G)
 2097314 41943043  freebsd-zfs  (2.0G)
 6291618  2923919981   - free -  (1.4T)
(...)

Each freebsd-zfs partition has GPT label: gpt/test0, gpt/test1, etc. ZFS pool 
is created with following default options: canmount=off, checksum=fletcher4, 
atime=off, setuid=off. There are some datasets with compress=lzjb or 
compress=gzip option set.

Boot code is initialized on each disk this way:
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

Results from tests:
1) + One logical device -> works
2) + Mirror built on 2 logical devices -> works
3) + Mirror built on 6 LDs -> works
4) - RAIDZ2 built on 3 LDs -> doesn't work
5) - RAIDZ2 built on 6 LDs -> doesn't work
6) - RAIDZ built on 3 LDs -> doesn't work
7) - RAIDZ built on 6 LDs -> doesn't work

8) + RAIDZ built on 3 USB sticks on the same machine -> works
9) + RAIDZ built on 3 LDs on another machine (aacdX devices) -> works

There are three different error messages I encountered. It depends on where 
bootcodes were built.

a) Error message encountered when using bootcodes from Fixit# media:

error 1 lba 32
error 1 lba 1
error 1 lba 32
error 1 lba 1
No ZFS pools located, can't boot

b) Error message encountered when using bootcodes that I built myself:

ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS object directory
Cant' find root filesystem - giving up
ZFS: unexpected object set type 0 
ZFS: unexpected object set type 0

FreeBSD/x86 boot
Default: test:/boot/kernel/kernel
boot:
ZFS: unexpected object set type 0

c) I also saw message similar to shown above, but with "ZFS: can't read MOS" 
message.

Example output from "status" command at "boot:" prompt (when error b appears):

boot: status pool: test
config:
  NAME STATE
  test ONLINE
raidz1 ONLINE

kern/153695: [PATCH] [ZFS] Booting from zpool created on 4k-sector drive doesn't work

2011-01-04 Thread Emil Smolenski 

>Number: 153695
>Category:   kern
>Synopsis:   [PATCH] [ZFS] Booting from zpool created on 4k-sector drive 
>doesn't work
>Confidential:   no
>Severity:   serious
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jan 04 23:50:09 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Emil Smolenski
>Release:FreeBSD 8.2-PRERELEASE
>Organization:
>Environment:
FreeBSD 8.2-PRERELEASE amd64
>Description:
There is a hack to force zpool creation with minimum sector size equal to 4k:

# gnop create -S 4096 ${DEV0}
# zpool create tank ${DEV0}.nop
# zpool export tank
# gnop destroy ${DEV0}.nop
# zpool import tank

Zpool created this way is faster on problematic 4k sector drives which lies 
about its sector size (like WD EARS). This hack works perfectly fine when 
system is running. Gnop layer is created only for "zpool create" command -- ZFS 
stores information about sector size in its metadata. After zpool creation one 
can export the pool, remove gnop layer and reimport the pool. Difference can be 
seen in the output from the zdb command:

- on 512 sector device (2**9 = 512):
% zdb tank |grep ashift
ashift=9

- on 4096 sector device (2**12 = 4096):
% zdb tank |grep ashift
ashift=12

This change is permanent. The only possibility to change the value of  
ashift is: zpool destroy/create and restoring pool from backup.

But there is one problem: I cannot boot from such pool. Error message:

ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS
ZFS: unexpected object set type 0

This is standard configuration with GPT scheme.

# gpart show da0
=>34  2930211565  da0  GPT  (1.4T)
   34  30   - free -  (15K)
   64 1281  freebsd-boot  (64K)
  192 41943042  freebsd-swap  (2.0G)
  4194496 83886083  freebsd-zfs  (4.0G)
 12583104  2917628495   - free -  (1.4T)

# zpool status tank
   pool: tank
  state: ONLINE
  scrub: none requested
config:

 NAME STATE READ WRITE CKSUM
 tank ONLINE   0 0 0
   gpt/tank0  ONLINE   0 0 0

# zdb -uuu tank
Uberblock

 magic = 00bab10c
 version = 15
 txg = 2838
 guid_sum = 12371721502612965633
 timestamp = 1292860198 UTC = Mon Dec 20 15:49:58 2010
 rootbp = [L0 DMU objset] 800L/200P DVA[0]=<0:2041000:1000>  
DVA[1]=<0:30062000:1000> DVA[2]=<0:ee0bd000:1000> fletcher4 lzjb LE contiguous 
birth=2838 fill=374 cksum=c9605617d:4e2cf0a8c94:f6decb77086a:210752c3aee4a8

This PR is similar to message which I send to freebsd-fs@ mailing list: 
http://lists.freebsd.org/pipermail/freebsd-fs/2010-December/010350.html
>How-To-Repeat:
Install FreeBSD 8.2-PRERELEASE like described here: 
http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot with following exceptions:

1. Add "-b 32K" to "gpart add -s 64K -t freebsd-boot ad0" command for proper 4k 
alignment.
2. Issue "gnop create -S 4096 ad0" command before creating zpool.
3. Use .nop device to create zpool.
4. Export the zpool, remove the gnop layer and reimport the zpool.
>Fix:
Attached patch is far from being perfect. I posted it here because maybe it 
could help someone skilled enough in tracking down this issue and provide 
proper solution.

With this patch applied:
- I can boot from single disk zpool,
- I can boot from mirrored zpool,
- I can't boot from raidz,
- I can't boot from mirrored zpool created on HP SmartArray P400 (it may be 
related to bug described in this PR: kern/151910

Patch attached with submission follows:

diff -ruN sys.orig/boot/zfs/zfsimpl.c sys/boot/zfs/zfsimpl.c
--- sys.orig/boot/zfs/zfsimpl.c 2010-12-29 13:55:38.195215000 +0100
+++ sys/boot/zfs/zfsimpl.c  2010-12-29 13:24:39.825206000 +0100
@@ -770,7 +770,7 @@
const char *pool_name;
const unsigned char *vdevs;
int i, rc, is_newer;
-   char upbuf[1024];
+   vdev_phys_t upbuf;
const struct uberblock *up;
 
/*
@@ -921,21 +921,21 @@
 * the contents of the pool.
 */
for (i = 0;
-i < VDEV_UBERBLOCK_RING >> UBERBLOCK_SHIFT;
+i < VDEV_UBERBLOCK_COUNT(vdev);
 i++) {
-   off = offsetof(vdev_label_t, vl_uberblock);
-   off += i << UBERBLOCK_SHIFT;
+   off = VDEV_UBERBLOCK_OFFSET(vdev, i);
BP_ZERO(&bp);
DVA_SET_OFFSET(&bp.blk_dva[0], off);
-   BP_SET_LSIZE(&bp, 1 << UBERBLOCK_SHIFT);
-   BP_SET_PSIZE(&bp, 1 << UBERBLOCK_SHIFT);
+   DVA_SET_ASIZE(&bp.blk_dva[0], VDEV

misc/148655: [zfs] Booting from a degraded raidz no longer works in 8-STABLE [regression]

2010-07-15 Thread Emil Smolenski 

>Number: 148655
>Category:   misc
>Synopsis:   [zfs] Booting from a degraded raidz no longer works in 
>8-STABLE [regression]
>Confidential:   no
>Severity:   serious
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jul 15 23:00:04 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Emil Smolenski
>Release:FreeBSD 8-STABLE
>Organization:
>Environment:
FreeBSD 8.0-STABLE i386
>Description:
After upgrade 8.0-RELEASE system to 8-STABLE, the machine no longer boots from 
degraded raidz. Booting stops with a message:

error 1 lba 32
error 1 lba 1

Booting from a non-degraded raidz still works fine.

After encountering a problem I prepared an isolated (qemu) environment to test 
this issue.

In 8.0-RELEASE everything works fine. I can remove one disk and the system 
boots. My configuration:

- gpart config:
=> 34  6291389  ad0  GPT  (3.0G)
   34  1281  freebsd-boot  (64K)
  162  62912612  freebsd-zfs  (3.0G)

=> 34  6291389  ad1  GPT  (3.0G)
   34  1281  freebsd-boot  (64K)
  162  62912612  freebsd-zfs  (3.0G)

=> 34  6291389  ad3  GPT  (3.0G)
   34  1281  freebsd-boot  (64K)
  162  62912612  freebsd-zfs  (3.0G)

(with GPT labeling)

- zpool (v13) config:
NAMESTATE READ WRITE CKSUM
bijou   ONLINE   0 0 0
  raidz1ONLINE   0 0 0
gpt/bijou0  ONLINE   0 0 0
gpt/bijou1  ONLINE   0 0 0
gpt/bijou2  ONLINE   0 0 0

- loader.conf:
zfs_load="YES"
vfs.root.mountfrom="zfs:bijou"

- rc.conf:
zfs_enable="YES"

After upgrade to 8-STABLE (world and kernel) and BEFORE reinstalling bootcode 
booting from degraded raidz no longer works: 
http://img28.imageshack.us/img28/9118/raidz8stable.png . Note: the installworld 
upgrades /boot/loader.

After reinstalling bootcode:

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad0
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad1
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ad3

booting stops with a message:

error 1 lba 32
error 1 lba 1

( http://img17.imageshack.us/img17/36/raidz8stablereinstalled.png )

Upgrading zpool to v14 doesn't help. I think this is serious regression -- 
disks often fail during reboot. The whole idea of raidz doesn't make any sense.
>How-To-Repeat:
1. Have FreeBSD 8.0-RELEASE "RootOnZFS" raidz1 installation (like the one 
described here: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 )
2. Upgrade to 8-STABLE.
3. Physically remove one disk from raidz.
4. Boot the machine.
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

misc/148961: [PATCH] netstart and network_ipv6 contains references to nonexistent files

2010-07-26 Thread Emil Smolenski 

>Number: 148961
>Category:   misc
>Synopsis:   [PATCH] netstart and network_ipv6 contains references to 
>nonexistent files
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:freebsd-bugs
>State:  open
>Quarter:
>Keywords:   
>Date-Required:
>Class:  sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jul 26 12:40:03 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Emil Smolenski
>Release:8.1-STABLE
>Organization:
>Environment:
>Description:
/etc/netstart tries to execute nonexistent /etc/rc.d/ip6fw script:

# /etc/netstart
(...)
/etc/netstart: /etc/rc.d/ip6fw: not found
(...)

# ls /etc/rc.d/ip6fw
ls: /etc/rc.d/ip6fw: No such file or directory

Also /etc/rc.d/network_ipv6 contains reference to ip6fw:

# grep ip6fw /etc/rc.d/network_ipv6
# REQUIRE: routing ip6fw
>How-To-Repeat:
# /etc/netstart
# grep ip6fw /etc/rc.d/network_ipv6
# ls /etc/rc.d/ip6fw
>Fix:
Look at the attached patch. I'm not sure if patch for the network_ipv6 is 
proper.

Patch attached with submission follows:

diff -ruN etc.orig/netstart etc/netstart
--- etc.orig/netstart   2009-08-03 10:13:06.0 +0200
+++ etc/netstart2010-07-26 13:02:21.819860465 +0200
@@ -55,7 +55,6 @@
 /etc/rc.d/dhclient ${_start}
 /etc/rc.d/ppp ${_start}
 /etc/rc.d/ipfw ${_start}
-/etc/rc.d/ip6fw ${_start}
 /etc/rc.d/network_ipv6 ${_start}
 /etc/rc.d/routing ${_start}
 /etc/rc.d/mroute6d ${_start}
diff -ruN etc.orig/rc.d/network_ipv6 etc/rc.d/network_ipv6
--- etc.orig/rc.d/network_ipv6  2009-08-03 10:13:06.0 +0200
+++ etc/rc.d/network_ipv6   2010-07-26 13:02:40.223567202 +0200
@@ -29,7 +29,7 @@
 #
 
 # PROVIDE: network_ipv6
-# REQUIRE: routing ip6fw
+# REQUIRE: routing ipfw
 # KEYWORD: nojail
 
 . /etc/rc.subr


>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

N/A, hoping to chat

2019-05-14 Thread emil...@onelocal.com 


Hi N/A,

How are you going about getting a positive review after you close a file? I 
know how difficult it can be for lawyers to ask for reviews from a client.

My company has been working with law firms to help them get more positive 
reviews on Google once they close a file, which has been helping them rank 
higher when someone is searching for their services.

When do you have 2-3 minutes to chat about this in further detail?

Best,
Emily

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