Re: Using camcontrol on a Corsair CSSD-F120GB2

2013-06-27 Thread Steven Hartland


- Original Message - 
From: "Sevan / Venture37" 

To: 
Sent: Thursday, June 27, 2013 1:48 AM
Subject: Re: Using camcontrol on a Corsair CSSD-F120GB2



On 26/06/2013 17:08, Steven Hartland wrote:

Try: camcontrol security ada0 -U user -s Erase -e Erase


camcontrol security ada0 -U user -s Erase -e Erase -v
camcontrol: sending ATA ATA_IDENTIFY with timeout of 3 msecs
pass0: Raw identify data:
   0: 0040 3fff c837 0010   003f 
   8:   3130 3434 3635 3236 3332 3030
  16: 3039 3938 3033 3736   0004 312e
  24: 3120 2020 2020 436f 7273 6169 7220 4353
  32: 5344 2d46 3132 3047 4232 2020 2020 2020
  40: 2020 2020 2020 2020 2020 2020 2020 8010
  48:  2f00 4000 0200 0200 0007 3fff 0010
  56: 003f fc10 00fb 0110 4bb0 0df9  0007
  64: 0003 0078 0078 0078 0078 4000  
  72:    001f 0706  004c 0044
  80: 01fc 0028 746b 7501 6163 706b b401 6163
  88: 407f   00fe    
  96:     4bb0 0df9  
 104:  0001 4000  5000  0998 0376
 112:        4014
 120: 4014       
 128: 0003       
 136:        
 144:        
 152:        
 160:        
 168:  0001      
 176:        
 184:        
 192:        
 200:       003d 
 208:  4000      
 216:  0001     1010 
 224:        
 232:        
 240:        
 248:        16a5

pass0:  ATA-8 SATA 2.x device
pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)

You are about to ERASE ALL DATA from the following device:
pass0,ada0:  ATA-8 SATA 2.x device

Are you SURE you want to ERASE ALL DATA? (yes/no) yes
Issuing SECURITY_SET_PASSWORD password='Erase', user='user', mode='high'
camcontrol: sending ATA SECURITY_SET_PASSWORD with timeout of 15000 msecs
Issuing SECURITY_ERASE_PREPARE
camcontrol: sending ATA SECURITY_ERASE_PREPARE with timeout of 15000 msecs
Issuing SECURITY_ERASE_UNIT password='Erase', user='user'
camcontrol: sending ATA SECURITY_ERASE_UNIT with timeout of 720 msecs
camcontrol: ATA SECURITY_ERASE_UNIT failed: 0
(pass0:ahcich0:0:0:0): SECURITY_ERASE_UNIT. ACB: f4 00 00 00 00 40 00 00 
00 00 00 00

(pass0:ahcich0:0:0:0): CAM status: Command timeout


How long did the command actually take to timeout?

I ask as you may well be tripping over a timeout overfow.

   Regards
   Steve


This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.

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


Re: RFC: swapon(8) vnode-backed md and gbde/geli encryption support

2013-06-27 Thread Hiroki Sato
Hiroki Sato  wrote
  in <20130623.035356.644417021040610458@allbsd.org>:

hr> Hi,
hr>
hr>  I created a patchset to add support of automatic generation of
hr>  vnode-backed md(4) devices and gbde/geli geom providers to swapon(8)
hr>  via /etc/fstab.  We already have equivalent functionality by using
hr>  rc.d scripts.  This simplifies rc.d scripts and fixes a race between
hr>  mdconfig/gbde/geli and swapon/swapoff by using /etc/fstab.

 A slightly revised patch is attached.  I will commit this today.

-- Hiroki
- Add vnode-backed swap space specification support.  This is enabled when
  device names "md" or "md[0-9]*" and a "file" option are specified in
  /etc/fstab like this:

  mdnoneswapsw,file=/swap.bin   0   0

- Add GBDE/GELI encrypted swap space specification support, which
  rc.d/encswap supported.  The /etc/fstab lines are like the following:

  /dev/ada1p1.bde   noneswapsw  0   0
  /dev/ada1p2.eli   noneswapsw  0   0

  .eli devices accepts aalgo, ealgo, keylen, and sectorsize as options.

  swapctl(8) can understand an encrypted device in the command line
  like this:

  # swapctl -a /dev/ada2p1.bde

- "-L" flag is added to support "late" option to defer swapon until
  rc.d/mountlate runs.

- rc.d script change:

rc.d/encswap -> removed
rc.d/addswap -> just display a warning message if  is defined.
rc.d/swap1 -> renamed to rc.d/swap
rc.d/swaplate -> newly added to support "late" option

These changes alleviate a race condition between device creation/removal
and swapon/swapoff.

MFC after:  1 week


Index: sbin/swapon/swapon.c
===
--- sbin/swapon/swapon.c	(revision 252094)
+++ sbin/swapon/swapon.c	(working copy)
@@ -41,35 +41,51 @@ static char sccsid[] = "@(#)swapon.c	8.1 (Berkeley
 #include 
 __FBSDID("$FreeBSD$");

+#include 
+#include 
+#include 
 #include 
-#include 
 #include 
+#include 
 #include 

 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 

 static void usage(void);
-static int swap_on_off(char *name, int ignoreebusy);
+static const char *swap_on_off(char *, int, char *);
+static const char *swap_on_off_gbde(char *, int);
+static const char *swap_on_off_geli(char *, char *, int);
+static const char *swap_on_off_md(char *, char *, int);
+static const char *swap_on_off_sfile(char *, int);
 static void swaplist(int, int, int);
+static int run_cmd(int *, const char *, ...) __printflike(2, 3);

 static enum { SWAPON, SWAPOFF, SWAPCTL } orig_prog, which_prog = SWAPCTL;

+static int qflag;
+
 int
 main(int argc, char **argv)
 {
 	struct fstab *fsp;
+	const char *swfile;
 	char *ptr;
 	int ret;
 	int ch, doall;
-	int sflag = 0, lflag = 0, hflag = 0, qflag = 0;
+	int sflag = 0, lflag = 0, late = 0, hflag = 0;
 	const char *etc_fstab;

 	if ((ptr = strrchr(argv[0], '/')) == NULL)
@@ -82,7 +98,7 @@ main(int argc, char **argv)

 	doall = 0;
 	etc_fstab = NULL;
-	while ((ch = getopt(argc, argv, "AadghklmqsUF:")) != -1) {
+	while ((ch = getopt(argc, argv, "AadghklLmqsUF:")) != -1) {
 		switch(ch) {
 		case 'A':
 			if (which_prog == SWAPCTL) {
@@ -116,6 +132,9 @@ main(int argc, char **argv)
 		case 'l':
 			lflag = 1;
 			break;
+		case 'L':
+			late = 1;
+			break;
 		case 'm':
 			hflag = 'M';
 			break;
@@ -145,6 +164,7 @@ main(int argc, char **argv)
 	argv += optind;

 	ret = 0;
+	swfile = NULL;
 	if (etc_fstab != NULL)
 		setfstab(etc_fstab);
 	if (which_prog == SWAPON || which_prog == SWAPOFF) {
@@ -154,27 +174,37 @@ main(int argc, char **argv)
 	continue;
 if (strstr(fsp->fs_mntops, "noauto"))
 	continue;
-if (swap_on_off(fsp->fs_spec, 1)) {
+if (which_prog != SWAPOFF &&
+strstr(fsp->fs_mntops, "late") &&
+!late)
+	continue;
+swfile = swap_on_off(fsp->fs_spec, 1,
+fsp->fs_mntops);
+if (swfile == NULL) {
 	ret = 1;
-} else {
-	if (!qflag) {
-		printf("%s: %sing %s as swap device\n",
-		getprogname(),
-		which_prog == SWAPOFF ? "remov" : "add",
-		fsp->fs_spec);
-	}
+	continue;
 }
+if (!qflag) {
+	printf("%s: %sing %s as swap device\n",
+	getprogname(),
+	(which_prog == SWAPOFF) ?
+	"remov" : "add", swfile);
+}
 			}
 		}
 		else if (!*argv)
 			usage();
 		for (; *argv; ++argv) {
-			if (swap_on_off(*argv, 0)) {
+			swfile = swap_on_off(*argv, 0, NULL);
+			if (swfile == NULL) {
 ret = 1;
-			} else if (orig_prog == SWAPCTL) {
+continue;
+			}
+			if (orig_prog == SWAPCTL) {
 printf("%s: %sing %s as swap device\n",
-getprogname(), which_prog == SWAPOFF ? "remov" : "add",
-*argv);
+getprogname(),
+(which_prog == SWAPOFF) ? "remov" : "add",
+swfile);
 			}
 		}
 	} else {
@@ -186,14 +216,503 @@ main(int argc, char **argv)
 	ex

Re: Kernel hangs on reboot on system with 05/2013~06/2013 CURRENT sources

2013-06-27 Thread Florian Smeets
On 26.06.13 03:19, Attilio Rao wrote:
> On Tue, Jun 25, 2013 at 11:27 PM, Florian Smeets  wrote:
>> On 06/25/2013 22:45, Garrett Cooper wrote:
>>> Long story short is that I've run into an issue on several VM
>>> images and real machines where UFS on mpt fails to reboot because it
>>> hangs in the kernel. I don't have any specific details, other than it
>>> occurs regularly with cam/mpt on VMware boxes running builds; however
>>> I've also seen this occur with a Dell box that has an mpt SAS
>>> controller with 2 zpools and gobs of RAM. Does anyone know of any
>>> issues in this area [recently]?
>>> This set of issues appears to have started cropping up after
>>> 03/2013, because I was running reliable builds off those sources.
>>> Thanks!
>>> -Garrett
>>>
>>
>> Yes, I saw the same thing today when rebooting a box running r251905:
>> Tue Jun 18 10:12:42 CEST 2013 with ahci on a zfs only system.
>>
>> I update this box about once a week, that previous kernel was from Jun
>> 11. and that still rebooted successfully. As the kernel from June 18. is
>> now kernel.old I don't know the SVN rev for the June 11 kernel, but it
>> looks like it was broken between June 11. and 18.
> 
> Can you break into KDB once the loop happens?
> 

I cannot reproduce on kernels from yesterday/today. So for me the case
is closed.

Florian



signature.asc
Description: OpenPGP digital signature


Re: Using camcontrol on a Corsair CSSD-F120GB2

2013-06-27 Thread Sevan / Venture37
On 27 Jun 2013, at 11:39 AM, "Steven Hartland"  wrote:

> How long did the command actually take to timeout?
> 
> I ask as you may well be tripping over a timeout overfow


A second?

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


Re: Using camcontrol on a Corsair CSSD-F120GB2

2013-06-27 Thread Steven Hartland
- Original Message - 
From: "Sevan / Venture37" 

On 27 Jun 2013, at 11:39 AM, "Steven Hartland":


How long did the command actually take to timeout?

I ask as you may well be tripping over a timeout overfow



A second?


Sounds like you did overflow, try adding -T 60 to the command
line e.g.
camcontrol security ada0 -U user -s Erase -e Erase -T 60

   Regards
   Steve


This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.

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


Re: Using camcontrol on a Corsair CSSD-F120GB2

2013-06-27 Thread Sevan / Venture37




On 27 Jun 2013, at 02:16 PM, "Steven Hartland"  wrote:

> Sounds like you did overflow, try adding -T 60 to the command
> line e.g.
> camcontrol security ada0 -U user -s Erase -e Erase -T 60

Awesome, worked a treat, after reboot both disks do not contain any partition.

Thanks Steve


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


Re: RFC: swapon(8) vnode-backed md and gbde/geli encryption support

2013-06-27 Thread Chris Rees
On 27 Jun 2013, at 09:06, Hiroki Sato wrote:

> Hiroki Sato  wrote
>  in <20130623.035356.644417021040610458@allbsd.org>:
> 
> hr> Hi,
> hr>
> hr>  I created a patchset to add support of automatic generation of
> hr>  vnode-backed md(4) devices and gbde/geli geom providers to swapon(8)
> hr>  via /etc/fstab.  We already have equivalent functionality by using
> hr>  rc.d scripts.  This simplifies rc.d scripts and fixes a race between
> hr>  mdconfig/gbde/geli and swapon/swapoff by using /etc/fstab.
> 
> A slightly revised patch is attached.  I will commit this today.
> 
> -- Hiroki
> - Add vnode-backed swap space specification support.  This is enabled when
>  device names "md" or "md[0-9]*" and a "file" option are specified in
>  /etc/fstab like this:
> 
>  mdnoneswapsw,file=/swap.bin   0   0
> 
> - Add GBDE/GELI encrypted swap space specification support, which
>  rc.d/encswap supported.  The /etc/fstab lines are like the following:
> 
>  /dev/ada1p1.bde   noneswapsw  0   0
>  /dev/ada1p2.eli   noneswapsw  0   0
> 
>  .eli devices accepts aalgo, ealgo, keylen, and sectorsize as options.
> 
>  swapctl(8) can understand an encrypted device in the command line
>  like this:
> 
>  # swapctl -a /dev/ada2p1.bde
> 
> - "-L" flag is added to support "late" option to defer swapon until
>  rc.d/mountlate runs.
> 
> - rc.d script change:
> 
>rc.d/encswap -> removed
>rc.d/addswap -> just display a warning message if  is defined.
>rc.d/swap1 -> renamed to rc.d/swap
>rc.d/swaplate -> newly added to support "late" option
> 
> These changes alleviate a race condition between device creation/removal
> and swapon/swapoff.
> 
> MFC after:  1 week

Looks fantastic-- better than hacking around in shell scripts I suppose :)

Chris


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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


Re: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS?

2013-06-27 Thread Kristof Provost
On 2013-06-24 22:08:01 (+0200), Alexander Leidinger  
wrote:
> On Mon, 24 Jun 2013 12:15:18 +0200
> Kristof Provost  wrote:
> 
> > For what it's worth, I'm running into exactly the same problem.
> > (amd64, stable/9). I have no custom settings in /etc/make.conf
> > or /etc/src.conf
> 
> I had a short discussion with the maintainer of our stress-test-suite,
> he was able to create a test-case which triggers the problem.
> 
I've been bisecting for a little bit, and while I'm not 100% sure yet,
there is one likely culprit right now: r249643.
It's an MFC with a number of ZFS changes relating to a refactoring of
the ioctl() interface. 

It is, unfortunately, also a rather large commit.

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


Re: request for your comments on release documentation

2013-06-27 Thread John Nielsen
On Jun 12, 2013, at 11:49 AM, Hiroki Sato  wrote:

> I would like your comments on release notes for each release.
> Although I have been working on editing them for years, the workflow
> is still not optimal and sometimes delay of the preparation became an
> obstacle for release process.  I would like to improve it, but before
> that I would like to know what are desired of the contents which
> people think.
> 
> Release Notes is just listing the changes between the two releases.
> It includes user-visible change (bugfix and/or UI change), new
> functionality, and performance improvement.  Minor changes such as
> one in kernel internal structure are omitted.  I always try to keep
> these series of relnotes items are correct and reasonably
> comprehensive, but this lengthy list may be boring and
> technically-correct descriptions can be cryptic for average users.
> 
> So, my questions are:
> 
> 1. What do you think about current granularity of the relnotes items?
>Too detailed, good, or too rough?  Currently, judgment of what is
>included or not is based on user-visible, new functionality, or
>performance improvement.  Applicable changes are included as
>relnotes items even if the changes are small,

I think the current granularity is good.

> 2. Do you want technical details?  For example, just "disk access
>performance was improved by 50%" or "Feature A has been added.
>This changes the old behavior because ..., and as a result, it
>improves disk access performance by 50%".

I want technical details. You could compromise here by trying to always have 
the non-technical end result in the first sentence or so, and then go on with a 
more technical explanation.

I would echo Mark Felder and say that if in doubt, more detail is better.

> 3. Is there missing information which should be in the relnotes?
>Probably there are some missing items for each release, but this
>question is one at some abstraction level.  Link to commit log and
>diff, detailed description of major incompatible changes, and so
>on.

I've not ever noticed any. Thanks!

I'm on the SVN mailing lists so I tend to know about or be able to find changes 
I care about independent of the release notes. However if there is a 
mostly-automated way to link to specific commits in the release notes that 
could be valuable.

> Although the other release documentations---Errata, Installation
> Notes, ReadMe, and Hardware Notes---also need some improvements,
> please focus on Release Notes only.  And you might think quality of
> English writing are not good, please leave that alone for now.

I've never noticed any language problems in the release notes, and I tend to be 
a stickler. :)

JN

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


Re: request for your comments on release documentation

2013-06-27 Thread Miroslav Lachman

Mark Felder wrote:

On Wed, 12 Jun 2013 12:49:21 -0500, Hiroki Sato  wrote:


[...]


3. Is there missing information which should be in the relnotes?
Probably there are some missing items for each release, but this
question is one at some abstraction level. Link to commit log and
diff, detailed description of major incompatible changes, and so
on.


I try to keep up with the development and changes in releases as best I
can and I haven't noticed any glaring omissions over the last several
releases. I think you're doing a fine job.

Also, is there a reason this isn't a "living" document that can be
updated as things get MFC'd to STABLE? It would help take load off your
end and maybe speed up release once the freeze has happened and we begin
the final grind through release candidates.


It would be nice if all release related documents (relnotes, errata, 
hardware notes etc.) will be "living" after release (in online version) 
and not considered as set in stone. There are sometimes missing items 
which should be included online as soon as possible, but rarely are.


For example, I found two issues with OpenSSH in 8.4 release. (bugs or 
features, or just incompatibilities with older versions) None of them is 
listed anywhere and I think it is really bad, because one issue can 
cause sshd not started after upgrade.


So the online version of these docs should be "living" and updated as 
some issues and questions arises on the mailing lists and forums few 
days / weeks after release.



On the other hand, FreeBSD has good quality of docs included Release 
Notes. (thank you for your work!)
If there is some "man power", some items can be more detailed with links 
to other online resources like FreeBSD wiki, but only for some important 
items.


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


Re: request for your comments on release documentation

2013-06-27 Thread Charles Sprickman
On Jun 27, 2013, at 7:24 PM, Miroslav Lachman wrote:

> Mark Felder wrote:
>> On Wed, 12 Jun 2013 12:49:21 -0500, Hiroki Sato  wrote:
> 
> [...]
> 
>>> 3. Is there missing information which should be in the relnotes?
>>> Probably there are some missing items for each release, but this
>>> question is one at some abstraction level. Link to commit log and
>>> diff, detailed description of major incompatible changes, and so
>>> on.
>> 
>> I try to keep up with the development and changes in releases as best I
>> can and I haven't noticed any glaring omissions over the last several
>> releases. I think you're doing a fine job.
>> 
>> Also, is there a reason this isn't a "living" document that can be
>> updated as things get MFC'd to STABLE? It would help take load off your
>> end and maybe speed up release once the freeze has happened and we begin
>> the final grind through release candidates.
> 
> It would be nice if all release related documents (relnotes, errata, hardware 
> notes etc.) will be "living" after release (in online version) and not 
> considered as set in stone. There are sometimes missing items which should be 
> included online as soon as possible, but rarely are.
> 
> For example, I found two issues with OpenSSH in 8.4 release. (bugs or 
> features, or just incompatibilities with older versions) None of them is 
> listed anywhere and I think it is really bad, because one issue can cause 
> sshd not started after upgrade.
> 
> So the online version of these docs should be "living" and updated as some 
> issues and questions arises on the mailing lists and forums few days / weeks 
> after release.

Additionally, it would be nice if the documentation for beta and RCs was posted 
before the actual release as well.  Just like the OS itself, docs can be "beta" 
and open for feedback from the community.  It's also nice to know about changes 
before you upgrade a box for testing as well - for example, the jail changes 
and zfs version bump in 8.4 were something of a surprise for me (I follow 
-stable, but not much else).  If the project wants people to test before 
release, having a list of changes, major and minor to focus on would probably 
net the project more useful feedback.

I'm also all for the "living" document idea.  It seems like the mailing lists 
always have a few issues that are documented nowhere else because they don't 
quite merit a ERRATA notice (eg: dhclient/fxp issue).

Thanks,

Charles

> 
> 
> On the other hand, FreeBSD has good quality of docs included Release Notes. 
> (thank you for your work!)
> If there is some "man power", some items can be more detailed with links to 
> other online resources like FreeBSD wiki, but only for some important items.
> 
> Miroslav Lachman
> ___
> freebsd-sta...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

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


RE: IPv6 - sobind fails with 49

2013-06-27 Thread Sreenivasa Honnur
I am writing a kernel socket program which binds to a IPv6 address, so bind 
always fails with 49. Below is the code snippet I am using, is something wrong 
here?



roundhay# uname -a

FreeBSD roundhay 9.1-RELEASE FreeBSD 9.1-RELEASE #2: Mon Apr  8 16:15:06 IST 
2013 
root@roundhay:/usr/obj/home/freebsd.org/sys/TOED
  amd64



Ifconfig/ping6 output:

==

cxgbe1: flags=8843 metric 0 mtu 1500


options=6c07bb

ether 00:07:43:11:89:88

inet6 2010::102 prefixlen 64

inet6 fe80::207:43ff:fe11:8988%cxgbe1 prefixlen 64 scopeid 0xd

inet6 fe80::1%cxgbe1 prefixlen 64 scopeid 0xd

nd6 options=21

media: Ethernet 10Gbase-SR 

status: active

roundhay# ping6 2010::101

PING6(56=40+8+8 bytes) 2010::102 --> 2010::101

16 bytes from 2010::101, icmp_seq=0 hlim=64 time=0.915 ms

16 bytes from 2010::101, icmp_seq=1 hlim=64 time=0.168 ms

^C

--- 2010::101 ping6 statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.168/0.541/0.915/0.374 ms





Code:

struct sockaddr_in6 saddr6;

rv = socreate(AF_INET6, &sock, SOCK_STREAM, IPPROTO_TCP,

td->td_ucred, td);



if (rv != 0) {

printf("sock create ipv6 %s failed %d.\n",

tbuf, rv);

return NULL;

}



saddr6.sin6_family = AF_INET6;

rv = inet_pton(AF_INET6, "2010::102", &saddr6.sin6_addr); ==> 
returns 1, which indicates it's a valid IPV6 address

printf("inet_pton retunred:%d\n", rv);



saddr6.sin6_port = htons(3260);

saddr6.sin6_len = sizeof(saddr6);



rv = sobind(sock, (struct sockaddr *)&saddr6, td); ==> fails 
with return value of 49



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


[head tinderbox] failure on ia64/ia64

2013-06-27 Thread FreeBSD Tinderbox
TB --- 2013-06-28 03:31:36 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-06-28 03:31:36 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-06-28 03:31:36 - starting HEAD tinderbox run for ia64/ia64
TB --- 2013-06-28 03:31:36 - cleaning the object tree
TB --- 2013-06-28 03:31:36 - /usr/local/bin/svn stat /src
TB --- 2013-06-28 03:31:40 - At svn revision 252320
TB --- 2013-06-28 03:31:41 - building world
TB --- 2013-06-28 03:31:41 - CROSS_BUILD_TESTING=YES
TB --- 2013-06-28 03:31:41 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-06-28 03:31:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-06-28 03:31:41 - SRCCONF=/dev/null
TB --- 2013-06-28 03:31:41 - TARGET=ia64
TB --- 2013-06-28 03:31:41 - TARGET_ARCH=ia64
TB --- 2013-06-28 03:31:41 - TZ=UTC
TB --- 2013-06-28 03:31:41 - __MAKE_CONF=/dev/null
TB --- 2013-06-28 03:31:41 - cd /src
TB --- 2013-06-28 03:31:41 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jun 28 03:31:49 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
cc1: warnings being treated as errors
/src/sbin/swapon/swapon.c: In function 'swap_on_off_gbde':
/src/sbin/swapon/swapon.c:251: warning: declaration of 'devname' shadows a 
global declaration
/obj/ia64.ia64/src/tmp/usr/include/stdlib.h:272: warning: shadowed declaration 
is here
/src/sbin/swapon/swapon.c: In function 'swap_on_off_geli':
/src/sbin/swapon/swapon.c:323: warning: declaration of 'devname' shadows a 
global declaration
/obj/ia64.ia64/src/tmp/usr/include/stdlib.h:272: warning: shadowed declaration 
is here
/src/sbin/swapon/swapon.c:394: warning: cast discards qualifiers from pointer 
target type
*** Error code 1

Stop.
make: stopped in /src/sbin/swapon
*** Error code 1

Stop.
make: stopped in /obj/ia64.ia64/src/rescue/rescue
*** Error code 1

Stop.
make: stopped in /src/rescue/rescue
*** Error code 1

Stop.
make: stopped in /src/rescue
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-06-28 04:38:53 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-06-28 04:38:53 - ERROR: failed to build world
TB --- 2013-06-28 04:38:53 - 3189.36 user 605.19 system 4036.81 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-ia64-ia64.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


[head tinderbox] failure on mips/mips

2013-06-27 Thread FreeBSD Tinderbox
TB --- 2013-06-28 04:38:54 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-06-28 04:38:54 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-06-28 04:38:54 - starting HEAD tinderbox run for mips/mips
TB --- 2013-06-28 04:38:54 - cleaning the object tree
TB --- 2013-06-28 04:38:54 - /usr/local/bin/svn stat /src
TB --- 2013-06-28 04:39:01 - At svn revision 252320
TB --- 2013-06-28 04:39:02 - building world
TB --- 2013-06-28 04:39:02 - CROSS_BUILD_TESTING=YES
TB --- 2013-06-28 04:39:02 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-06-28 04:39:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-06-28 04:39:02 - SRCCONF=/dev/null
TB --- 2013-06-28 04:39:02 - TARGET=mips
TB --- 2013-06-28 04:39:02 - TARGET_ARCH=mips
TB --- 2013-06-28 04:39:02 - TZ=UTC
TB --- 2013-06-28 04:39:02 - __MAKE_CONF=/dev/null
TB --- 2013-06-28 04:39:02 - cd /src
TB --- 2013-06-28 04:39:02 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jun 28 04:39:09 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
cc1: warnings being treated as errors
/src/sbin/swapon/swapon.c: In function 'swap_on_off_gbde':
/src/sbin/swapon/swapon.c:251: warning: declaration of 'devname' shadows a 
global declaration
/obj/mips.mips/src/tmp/usr/include/stdlib.h:272: warning: shadowed declaration 
is here
/src/sbin/swapon/swapon.c: In function 'swap_on_off_geli':
/src/sbin/swapon/swapon.c:323: warning: declaration of 'devname' shadows a 
global declaration
/obj/mips.mips/src/tmp/usr/include/stdlib.h:272: warning: shadowed declaration 
is here
/src/sbin/swapon/swapon.c:394: warning: cast discards qualifiers from pointer 
target type
*** Error code 1

Stop.
make: stopped in /src/sbin/swapon
*** Error code 1

Stop.
make: stopped in /obj/mips.mips/src/rescue/rescue
*** Error code 1

Stop.
make: stopped in /src/rescue/rescue
*** Error code 1

Stop.
make: stopped in /src/rescue
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-06-28 05:27:29 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-06-28 05:27:29 - ERROR: failed to build world
TB --- 2013-06-28 05:27:29 - 2100.08 user 524.52 system 2915.05 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips-mips.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


making bhyve 100% silent

2013-06-27 Thread Aryeh Friedman
bhyve(8) seems to bypass the standard stdin/out/err and send it's
output directly to the TTY when handling guest console I/O.   I need
to make it so it is 100% silent (and/or send all it's output to a file
and accept no input at all).   How can I do this?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


[head tinderbox] failure on mips64/mips

2013-06-27 Thread FreeBSD Tinderbox
TB --- 2013-06-28 05:27:29 - tinderbox 2.10 running on freebsd-current.sentex.ca
TB --- 2013-06-28 05:27:29 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE 
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC  amd64
TB --- 2013-06-28 05:27:29 - starting HEAD tinderbox run for mips64/mips
TB --- 2013-06-28 05:27:29 - cleaning the object tree
TB --- 2013-06-28 05:27:29 - /usr/local/bin/svn stat /src
TB --- 2013-06-28 05:27:39 - At svn revision 252320
TB --- 2013-06-28 05:27:40 - building world
TB --- 2013-06-28 05:27:40 - CROSS_BUILD_TESTING=YES
TB --- 2013-06-28 05:27:40 - MAKEOBJDIRPREFIX=/obj
TB --- 2013-06-28 05:27:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2013-06-28 05:27:40 - SRCCONF=/dev/null
TB --- 2013-06-28 05:27:40 - TARGET=mips
TB --- 2013-06-28 05:27:40 - TARGET_ARCH=mips64
TB --- 2013-06-28 05:27:40 - TZ=UTC
TB --- 2013-06-28 05:27:40 - __MAKE_CONF=/dev/null
TB --- 2013-06-28 05:27:40 - cd /src
TB --- 2013-06-28 05:27:40 - /usr/bin/make -B buildworld
>>> Building an up-to-date make(1)
>>> World build started on Fri Jun 28 05:27:47 UTC 2013
>>> Rebuilding the temporary build tree
>>> stage 1.1: legacy release compatibility shims
>>> stage 1.2: bootstrap tools
>>> stage 2.1: cleaning up the object tree
>>> stage 2.2: rebuilding the object tree
>>> stage 2.3: build tools
>>> stage 3: cross tools
>>> stage 4.1: building includes
>>> stage 4.2: building libraries
>>> stage 4.3: make dependencies
>>> stage 4.4: building everything
[...]
cc1: warnings being treated as errors
/src/sbin/swapon/swapon.c: In function 'swap_on_off_gbde':
/src/sbin/swapon/swapon.c:251: warning: declaration of 'devname' shadows a 
global declaration
/obj/mips.mips64/src/tmp/usr/include/stdlib.h:272: warning: shadowed 
declaration is here
/src/sbin/swapon/swapon.c: In function 'swap_on_off_geli':
/src/sbin/swapon/swapon.c:323: warning: declaration of 'devname' shadows a 
global declaration
/obj/mips.mips64/src/tmp/usr/include/stdlib.h:272: warning: shadowed 
declaration is here
/src/sbin/swapon/swapon.c:394: warning: cast discards qualifiers from pointer 
target type
*** Error code 1

Stop.
make: stopped in /src/sbin/swapon
*** Error code 1

Stop.
make: stopped in /obj/mips.mips64/src/rescue/rescue
*** Error code 1

Stop.
make: stopped in /src/rescue/rescue
*** Error code 1

Stop.
make: stopped in /src/rescue
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop.
make: stopped in /src
*** Error code 1

Stop in /src.
TB --- 2013-06-28 06:14:55 - WARNING: /usr/bin/make returned exit code  1 
TB --- 2013-06-28 06:14:55 - ERROR: failed to build world
TB --- 2013-06-28 06:14:55 - 2104.07 user 472.66 system 2845.70 real


http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-mips64-mips.full
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


RE: IPv6 - sobind fails with 49

2013-06-27 Thread Trond Endrestøl
On Fri, 28 Jun 2013 04:05-, Sreenivasa Honnur wrote:

> I am writing a kernel socket program which binds to a IPv6 address, so bind 
> always fails with 49. Below is the code snippet I am using, is something 
> wrong here?
> 
> roundhay# uname -a
> FreeBSD roundhay 9.1-RELEASE FreeBSD 9.1-RELEASE #2: Mon Apr  8 16:15:06 IST 
> 2013 
> root@roundhay:/usr/obj/home/freebsd.org/sys/TOED
>   amd64
> 
> Ifconfig/ping6 output:
> ==
> cxgbe1: flags=8843 metric 0 mtu 1500
> 
> options=6c07bb
> ether 00:07:43:11:89:88
> inet6 2010::102 prefixlen 64
> inet6 fe80::207:43ff:fe11:8988%cxgbe1 prefixlen 64 scopeid 0xd
> inet6 fe80::1%cxgbe1 prefixlen 64 scopeid 0xd
> nd6 options=21
> media: Ethernet 10Gbase-SR 
> status: active
> 
> roundhay# ping6 2010::101
> PING6(56=40+8+8 bytes) 2010::102 --> 2010::101
> 16 bytes from 2010::101, icmp_seq=0 hlim=64 time=0.915 ms
> 16 bytes from 2010::101, icmp_seq=1 hlim=64 time=0.168 ms
> ^C
> --- 2010::101 ping6 statistics ---
> 2 packets transmitted, 2 packets received, 0.0% packet loss
> round-trip min/avg/max/std-dev = 0.168/0.541/0.915/0.374 ms

Warning: I haven't dabbled in programming FreeBSD kernel internals, 
but I have done some socket programming some years ago.

You failed to present the line declaring sock. The prototype for 
socreate is:

  int
  socreate(int dom, struct socket **aso, int type, int proto,
   struct ucred *cred, struct thread *td);

The second argument expects a pointer to a pointer to a socket (a 
struct socket). The memory for the socket will be allocated by 
socreate() and a pointer returned through the formal argument aso.

I only hope you declared sock as:

  struct socket *sock;

Next, it would probably be wise to clear saddr6 before assigning 
values to its members, something along:

  memset((void *)&saddr6, 0, sizeof(saddr6));

or even:

  bzero((void *)&saddr6, sizeof(saddr6));

That's all I can think of atm. Maybe someone more knowledgeable on 
FreeBSD internals can assist you further.

> Code:
> 
> struct sockaddr_in6 saddr6;
> rv = socreate(AF_INET6, &sock, SOCK_STREAM, IPPROTO_TCP,
> td->td_ucred, td);
> 
> if (rv != 0) {
> printf("sock create ipv6 %s failed %d.\n",
> tbuf, rv);
> return NULL;
> }
> 
> saddr6.sin6_family = AF_INET6;
> rv = inet_pton(AF_INET6, "2010::102", &saddr6.sin6_addr); ==> 
> returns 1, which indicates it's a valid IPV6 address
> printf("inet_pton retunred:%d\n", rv);
> 
> saddr6.sin6_port = htons(3260);
> saddr6.sin6_len = sizeof(saddr6);
> 
> rv = sobind(sock, (struct sockaddr *)&saddr6, td); ==> fails 
> with return value of 49

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"