svn commit: r293820 - in stable/10/sys/dev/hyperv: include vmbus

2016-01-13 Thread Xin LI 
Author: delphij
Date: Wed Jan 13 08:22:53 2016
New Revision: 293820
URL: https://svnweb.freebsd.org/changeset/base/293820

Log:
  MFC r292861:
  
  hyperv: vmbus: run non-blocking message handlers in vmbus_msg_swintr()
  
  We'll remove the per-channel control_work_queue because it can't properly
  do serialization of message handling, e.g., when there are 2 NIC devices,
  vmbus_channel_on_offer() -> hv_queue_work_item() has a race condition:
  for an SMP VM, vmbus_channel_process_offer() can run concurrently on
  different CPUs and if the second NIC's
  vmbus_channel_process_offer() -> hv_vmbus_child_device_register() runs
  first, the second NIC's name will be hn0 and the first NIC's name will
  be hn1!
  
  We can fix the race condition by removing the per-channel control_work_queue
  and run all the message handlers in the global
  hv_vmbus_g_connection.work_queue -- we'll do this in the next patch.
  
  With the coming next patch, we have to run the non-blocking handlers
  directly in the kernel thread vmbus_msg_swintr(), because the special
  handling of sub-channel: when a sub-channel (e.g., of the storvsc driver)
  is received and being handled in vmbus_channel_on_offer() running on the
  global hv_vmbus_g_connection.work_queue, vmbus_channel_process_offer()
  invokes channel->sc_creation_callback, i.e., storvsc_handle_sc_creation,
  and the callback will invoke hv_vmbus_channel_open() -> hv_vmbus_post_message
  and expect a further reply from the host, but the handling of the further
  messag can't be done because the current message's handling hasn't finished
  yet; as result, hv_vmbus_channel_open() -> sema_timedwait() will time out
  and th device can't work.
  
  Also renamed the handler type from hv_pfn_channel_msg_handler to
  vmbus_msg_handler: the 'pfn' and 'channel' in the old name make no sense.
  
  Submitted by: Dexuan Cui 
  Reviewed by:  royger
  Differential Revision:https://reviews.freebsd.org/D4596
  
  MFC r292859:
  
  hyperv: vmbus: remove the per-channel control_work_queue
  
  Now vmbus_channel_on_offer() -> vmbus_channel_process_offer() can
  safely run on the global hv_vmbus_g_connection.work_queue now.
  
  We remove the per-channel control_work_queue to achieve the proper
  serialization of the message handling.
  
  I removed the bogus TODO in vmbus_channel_on_offer(): a vmbus offer
  can only come from the parent partition, i.e., the host.
  
  PR:   kern/205156
  Submitted by: Dexuan Cui 
  Reviewed by:  Howard Su , delphij
  Differential Revision:https://reviews.freebsd.org/D4597

Modified:
  stable/10/sys/dev/hyperv/include/hyperv.h
  stable/10/sys/dev/hyperv/vmbus/hv_channel_mgmt.c
  stable/10/sys/dev/hyperv/vmbus/hv_vmbus_drv_freebsd.c
  stable/10/sys/dev/hyperv/vmbus/hv_vmbus_priv.h
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/dev/hyperv/include/hyperv.h
==
--- stable/10/sys/dev/hyperv/include/hyperv.h   Wed Jan 13 08:09:28 2016
(r293819)
+++ stable/10/sys/dev/hyperv/include/hyperv.h   Wed Jan 13 08:22:53 2016
(r293820)
@@ -759,7 +759,6 @@ typedef struct hv_vmbus_channel {
hv_vmbus_ring_buffer_info   inbound;
 
struct mtx  inbound_lock;
-   hv_vmbus_handle control_work_queue;
 
hv_vmbus_pfn_channel_callback   on_channel_callback;
void*   channel_callback_context;

Modified: stable/10/sys/dev/hyperv/vmbus/hv_channel_mgmt.c
==
--- stable/10/sys/dev/hyperv/vmbus/hv_channel_mgmt.cWed Jan 13 08:09:28 
2016(r293819)
+++ stable/10/sys/dev/hyperv/vmbus/hv_channel_mgmt.cWed Jan 13 08:22:53 
2016(r293820)
@@ -34,13 +34,6 @@ __FBSDID("$FreeBSD$");
 
 #include "hv_vmbus_priv.h"
 
-typedef void (*hv_pfn_channel_msg_handler)(hv_vmbus_channel_msg_header* msg);
-
-typedef struct hv_vmbus_channel_msg_table_entry {
-   hv_vmbus_channel_msg_typemessageType;
-   hv_pfn_channel_msg_handler   messageHandler;
-} hv_vmbus_channel_msg_table_entry;
-
 /*
  * Internal functions
  */
@@ -52,36 +45,46 @@ static void vmbus_channel_on_gpadl_creat
 static void vmbus_channel_on_gpadl_torndown(hv_vmbus_channel_msg_header* hdr);
 static void vmbus_channel_on_offers_delivered(hv_vmbus_channel_msg_header* 
hdr);
 static void vmbus_channel_on_version_response(hv_vmbus_channel_msg_header* 
hdr);
-static void vmbus_channel_process_offer(void *context);
 
 /**
  * Channel message dispatch table
  */
 hv_vmbus_channel_msg_table_entry
 g_channel_message_table[HV_CHANNEL_MESSAGE_COUNT] = {
-   { HV_CHANNEL_MESSAGE_INVALID, NULL },
-   { HV_CHANNEL_MESSAGE_OFFER_CHANNEL, vmbus_channel_on_offer },
+   { HV_CHANNEL_MESSAGE_INVALID,
+   0, NULL },
+   { HV_CHANNEL_MESSAGE_OFFER_CHANNEL,
+   0,

Re: svn commit: r293776 - stable/10/usr.sbin/fstyp

2016-01-13 Thread Slawa Olhovchenkov 
On Tue, Jan 12, 2016 at 04:38:09PM +, Allan Jude wrote:

> Author: allanjude
> Date: Tue Jan 12 16:38:09 2016
> New Revision: 293776
> URL: https://svnweb.freebsd.org/changeset/base/293776
> 
> Log:
>   MFC: r284589
> Add the ability to detect ZFS and GELI encrypted file systems to fstyp(8)
>   
>   MFC: r284644
> Fix GCC Warnings
>   
>   MFC: r284728
> Only build ZFS support in absense of WITHOUT_ZFS

What purpose for switch off ZFS support in case WITHOUT_ZFS?
___
svn-src-stable-10@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-stable-10
To unsubscribe, send any mail to "svn-src-stable-10-unsubscr...@freebsd.org"

svn commit: r293857 - stable/10/sys/dev/drm2/i915

2016-01-13 Thread Jean-Sébastien Pédron 
Author: dumbbell
Date: Wed Jan 13 21:56:48 2016
New Revision: 293857
URL: https://svnweb.freebsd.org/changeset/base/293857

Log:
  drm/i915: Remove "Attempting to unbind pinned buffer" message
  
  This error message is removed in later versions of Linux and currently,
  it spams users.
  
  PR:   200712
  MFC of:   r289109

Modified:
  stable/10/sys/dev/drm2/i915/i915_gem.c
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/dev/drm2/i915/i915_gem.c
==
--- stable/10/sys/dev/drm2/i915/i915_gem.c  Wed Jan 13 21:50:08 2016
(r293856)
+++ stable/10/sys/dev/drm2/i915/i915_gem.c  Wed Jan 13 21:56:48 2016
(r293857)
@@ -2771,10 +2771,8 @@ i915_gem_object_unbind(struct drm_i915_g
ret = 0;
if (obj->gtt_space == NULL)
return (0);
-   if (obj->pin_count != 0) {
-   DRM_ERROR("Attempting to unbind pinned buffer\n");
+   if (obj->pin_count != 0)
return (-EINVAL);
-   }
 
ret = i915_gem_object_finish_gpu(obj);
if (ret == -ERESTARTSYS || ret == -EINTR)
___
svn-src-stable-10@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-stable-10
To unsubscribe, send any mail to "svn-src-stable-10-unsubscr...@freebsd.org"

svn commit: r293865 - stable/10/usr.sbin/sesutil

2016-01-13 Thread Allan Jude 
Author: allanjude
Date: Thu Jan 14 01:42:09 2016
New Revision: 293865
URL: https://svnweb.freebsd.org/changeset/base/293865

Log:
  MFC: r287473
Add the new sesutil(8) utility for managing SCSI Enclosure Services (SES) 
device.
  
  MFC: r287493
Fix iteration bug
  
  MFC: r287485, r287494, r287992
Please the angry gcc 4.2 gods
  
  MFC: r287988
Improve and expand sesutil(8)
  
Return an error if no matching device is found
Locate can address a slot, in addition to a drive
Added fault, similar to locate but blinks a different LED
Added the map command, lists all devices connected to the SES controller
Added the status command, overall status of the SES controller
  
  MFC: r292092
sesutil: fix map not printing the status of the LED device in an array
  
  MFC: r292093
sesutil: pass the correct element type when printing the SES map
  
  MFC: r292121
sesutil: Add extra information specific to some SES devices to sesutil map
  
  MFC: r292122
Fix sesutil locate when a sesid is passed to locate command
  
  MFC: r292262
Show the enclosure name and id in sesutil map
  
  Relnotes: yes
  Sponsored by: Gandi.net
  Sponsored by: ScaleEngine Inc.

Added:
  stable/10/usr.sbin/sesutil/eltsub.c
 - copied, changed from r287988, head/usr.sbin/sesutil/eltsub.c
  stable/10/usr.sbin/sesutil/eltsub.h
 - copied, changed from r287988, head/usr.sbin/sesutil/eltsub.h
Modified:
  stable/10/usr.sbin/sesutil/Makefile
  stable/10/usr.sbin/sesutil/sesutil.8
  stable/10/usr.sbin/sesutil/sesutil.c
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/usr.sbin/sesutil/Makefile
==
--- stable/10/usr.sbin/sesutil/Makefile Thu Jan 14 01:34:41 2016
(r293864)
+++ stable/10/usr.sbin/sesutil/Makefile Thu Jan 14 01:42:09 2016
(r293865)
@@ -1,6 +1,9 @@
 # $FreeBSD$
 
 PROG=  sesutil
+SRCS=  sesutil.c eltsub.c
 MAN=   sesutil.8
 
+LIBADD=sbuf
+
 .include 

Copied and modified: stable/10/usr.sbin/sesutil/eltsub.c (from r287988, 
head/usr.sbin/sesutil/eltsub.c)
==
--- head/usr.sbin/sesutil/eltsub.c  Sat Sep 19 16:36:45 2015
(r287988, copy source)
+++ stable/10/usr.sbin/sesutil/eltsub.c Thu Jan 14 01:42:09 2016
(r293865)
@@ -32,6 +32,11 @@
  * mja...@feral.com
  */
 
+#include 
+#include 
+#include 
+
+#include 
 #include 
 #include 
 #include 
@@ -43,6 +48,13 @@
 
 #include "eltsub.h"
 
+/*
+ * offset by +20 degrees.
+ * The range of the value expresses a temperature between -19 and +235 degrees
+ * Celsius. A value of 00h is reserved.
+ */
+#define TEMPERATURE_OFFSET 20
+
 char *
 geteltnm(int type)
 {
@@ -134,7 +146,7 @@ geteltnm(int type)
return (rbuf);
 }
 
-static char *
+char *
 scode2ascii(u_char code)
 {
static char rbuf[32];
@@ -173,22 +185,51 @@ scode2ascii(u_char code)
return (rbuf);
 }
 
-
-char *
-stat2ascii(int eletype, u_char *cstat)
+struct sbuf *
+stat2sbuf(int eletype, u_char *cstat)
 {
-   static char ebuf[256], *scode;
+   struct sbuf *buf;
 
-   scode = scode2ascii(cstat[0]);
-   sprintf(ebuf, "%s%s%s%s%s%s (0x%02x 0x%02x 0x%02x 0x%02x)",
-   scode,
-   (cstat[0] & 0x40) ? ", Prd.Fail" : "",
-   (cstat[0] & 0x20) ? ", Disabled" : "",
-   (cstat[0] & 0x10) ? ", Swapped" : "",
-   (eletype == ELMTYP_DEVICE && (cstat[2] & 0x02)) ?
-   ", LED=Locate" : "",
-   (eletype == ELMTYP_DEVICE && (cstat[3] & 0x20)) ?
-   ", LED=Fault" : "",
-   cstat[0], cstat[1], cstat[2], cstat[3]);
-   return (ebuf);
+   buf = sbuf_new_auto();
+   if (buf == NULL)
+   err(EXIT_FAILURE, "sbuf_new_auto()");
+
+   if (cstat[0] & 0x40)
+   sbuf_printf(buf, "\t\t- Predicted Failure\n");
+   if (cstat[0] & 0x20)
+   sbuf_printf(buf, "\t\t- Disabled\n");
+   if (cstat[0] & 0x10)
+   sbuf_printf(buf, "\t\t- Swapped\n");
+   switch (eletype) {
+   case ELMTYP_DEVICE:
+   if (cstat[2] & 0x02)
+   sbuf_printf(buf, "\t\t- LED=locate\n");
+   if (cstat[2] & 0x20)
+   sbuf_printf(buf, "\t\t- LED=fault\n");
+   break;
+   case ELMTYP_ARRAY_DEV:
+   if (cstat[2] & 0x02)
+   sbuf_printf(buf, "\t\t- LED=locate\n");
+   if (cstat[2] & 0x20)
+   sbuf_printf(buf, "\t\t- LED=fault\n");
+   break;
+   case ELMTYP_FAN:
+   sbuf_printf(buf, "\t\t- Speed: %d rpm\n",
+   (((0x7 & cstat[1]) << 8) + cstat[2]) * 10);
+   break;
+   case ELMTYP_THERM:
+   if (cstat[2]) {
+   sbuf_printf(buf, "\t\t- Temperature: %d C\n",
+   cstat[2] -

svn commit: r293866 - stable/10/sys/fs/ext2fs

2016-01-13 Thread Pedro F. Giffuni 
Author: pfg
Date: Thu Jan 14 01:50:06 2016
New Revision: 293866
URL: https://svnweb.freebsd.org/changeset/base/293866

Log:
  MFC   r293683:
  ext4: mount panic from freeing invalid pointers
  
  Initialize the struct with those fields to zeroes on allocation,
  preventing the panic.
  
  Patch by: Damjan Jovanovic.
  
  PR:   206056

Modified:
  stable/10/sys/fs/ext2fs/ext2_vfsops.c
Directory Properties:
  stable/10/   (props changed)

Modified: stable/10/sys/fs/ext2fs/ext2_vfsops.c
==
--- stable/10/sys/fs/ext2fs/ext2_vfsops.c   Thu Jan 14 01:42:09 2016
(r293865)
+++ stable/10/sys/fs/ext2fs/ext2_vfsops.c   Thu Jan 14 01:50:06 2016
(r293866)
@@ -590,7 +590,7 @@ ext2_mountfs(struct vnode *devvp, struct
 * while Linux keeps the super block in a locked buffer.
 */
ump->um_e2fs = malloc(sizeof(struct m_ext2fs),
-   M_EXT2MNT, M_WAITOK);
+   M_EXT2MNT, M_WAITOK | M_ZERO);
ump->um_e2fs->e2fs = malloc(sizeof(struct ext2fs),
M_EXT2MNT, M_WAITOK);
mtx_init(EXT2_MTX(ump), "EXT2FS", "EXT2FS Lock", MTX_DEF);
___
svn-src-stable-10@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-stable-10
To unsubscribe, send any mail to "svn-src-stable-10-unsubscr...@freebsd.org"

Re: svn commit: r293776 - stable/10/usr.sbin/fstyp

2016-01-13 Thread Warner Losh 

> On Jan 13, 2016, at 9:26 AM, Allan Jude  wrote:
> 
> On 2016-01-13 08:18, Slawa Olhovchenkov wrote:
>> On Tue, Jan 12, 2016 at 04:38:09PM +, Allan Jude wrote:
>> 
>>> Author: allanjude
>>> Date: Tue Jan 12 16:38:09 2016
>>> New Revision: 293776
>>> URL: https://svnweb.freebsd.org/changeset/base/293776
>>> 
>>> Log:
>>>  MFC: r284589
>>>Add the ability to detect ZFS and GELI encrypted file systems to fstyp(8)
>>> 
>>>  MFC: r284644
>>>Fix GCC Warnings
>>> 
>>>  MFC: r284728
>>>Only build ZFS support in absense of WITHOUT_ZFS
>> 
>> What purpose for switch off ZFS support in case WITHOUT_ZFS?
>> 
> 
> If the user builds FreeBSD WITHOUT_CDDL or WITHOUT_ZFS, then they are
> requesting that we not build the ZFS code, so building it anyway would
> be against their wishes. The most likely reason they would request this
> is for license reasons.

For x86, that may be true. For arm and mips platforms, ZFS is too much of a
memory pig-dog to run on much of the kit we run on in that space. Turning it
off is part of removing the type 2 muda from the system.

In any event, the double negative is true. Don’t build ZFS when its absence has
been requested with WITHOUT_ZFS is correct.

Warner



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: svn commit: r293776 - stable/10/usr.sbin/fstyp

2016-01-13 Thread Matthew Ahrens 
On Wed, Jan 13, 2016 at 8:32 AM, Warner Losh  wrote:

>
> > On Jan 13, 2016, at 9:26 AM, Allan Jude  wrote:
> >
> > On 2016-01-13 08:18, Slawa Olhovchenkov wrote:
> >> On Tue, Jan 12, 2016 at 04:38:09PM +, Allan Jude wrote:
> >>
> >>> Author: allanjude
> >>> Date: Tue Jan 12 16:38:09 2016
> >>> New Revision: 293776
> >>> URL: https://svnweb.freebsd.org/changeset/base/293776
> >>>
> >>> Log:
> >>>  MFC: r284589
> >>>Add the ability to detect ZFS and GELI encrypted file systems to
> fstyp(8)
> >>>
> >>>  MFC: r284644
> >>>Fix GCC Warnings
> >>>
> >>>  MFC: r284728
> >>>Only build ZFS support in absense of WITHOUT_ZFS
> >>
> >> What purpose for switch off ZFS support in case WITHOUT_ZFS?
> >>
> >
> > If the user builds FreeBSD WITHOUT_CDDL or WITHOUT_ZFS, then they are
> > requesting that we not build the ZFS code, so building it anyway would
> > be against their wishes. The most likely reason they would request this
> > is for license reasons.
>
> For x86, that may be true. For arm and mips platforms, ZFS is too much of a
> memory pig-dog to run on much of the kit we run on in that space. Turning
> it
> off is part of removing the type 2 muda from the system.
>
> In any event, the double negative is true. Don’t build ZFS when its
> absence has
> been requested with WITHOUT_ZFS is correct.
>

Some of the confusion may be because this is not building ZFS -
just support for detecting ZFS pools in fstyp.  Which would be reasonable
to do even if you are not building support for ZFS.

However, the fstyp ZFS code relies on libzfs and libnvpair which are CDDL
licensed.  So if you did not build ZFS (or CDDL), the fstyp code could not
work.

--matt
___
svn-src-stable-10@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-stable-10
To unsubscribe, send any mail to "svn-src-stable-10-unsubscr...@freebsd.org"

Re: svn commit: r293776 - stable/10/usr.sbin/fstyp

2016-01-13 Thread Slawa Olhovchenkov 
On Wed, Jan 13, 2016 at 08:35:14AM -0800, Matthew Ahrens wrote:

> On Wed, Jan 13, 2016 at 8:32 AM, Warner Losh  wrote:
> 
> >
> > > On Jan 13, 2016, at 9:26 AM, Allan Jude  wrote:
> > >
> > > On 2016-01-13 08:18, Slawa Olhovchenkov wrote:
> > >> On Tue, Jan 12, 2016 at 04:38:09PM +, Allan Jude wrote:
> > >>
> > >>> Author: allanjude
> > >>> Date: Tue Jan 12 16:38:09 2016
> > >>> New Revision: 293776
> > >>> URL: https://svnweb.freebsd.org/changeset/base/293776
> > >>>
> > >>> Log:
> > >>>  MFC: r284589
> > >>>Add the ability to detect ZFS and GELI encrypted file systems to
> > fstyp(8)
> > >>>
> > >>>  MFC: r284644
> > >>>Fix GCC Warnings
> > >>>
> > >>>  MFC: r284728
> > >>>Only build ZFS support in absense of WITHOUT_ZFS
> > >>
> > >> What purpose for switch off ZFS support in case WITHOUT_ZFS?
> > >>
> > >
> > > If the user builds FreeBSD WITHOUT_CDDL or WITHOUT_ZFS, then they are
> > > requesting that we not build the ZFS code, so building it anyway would
> > > be against their wishes. The most likely reason they would request this
> > > is for license reasons.

And what main reason in this case: license or memory consumption?

> > For x86, that may be true. For arm and mips platforms, ZFS is too much of a
> > memory pig-dog to run on much of the kit we run on in that space. Turning
> > it
> > off is part of removing the type 2 muda from the system.

How many additional memory footpint need for support ZFS detecting?

> > In any event, the double negative is true. Don’t build ZFS when its
> > absence has
> > been requested with WITHOUT_ZFS is correct.
> >
> 
> Some of the confusion may be because this is not building ZFS -
> just support for detecting ZFS pools in fstyp.  Which would be reasonable
> to do even if you are not building support for ZFS.

Yes, for diagnostic purpose (interactive and in srcipts).
Also, ZFS may be in FUSE or may be exported by iSCSI (and ZFS
detecting need for selecting raw disk for exporting).

> However, the fstyp ZFS code relies on libzfs and libnvpair which are CDDL
> licensed.  So if you did not build ZFS (or CDDL), the fstyp code could not
> work.

May be better relies on WITHOUT_CDDL? If main purpose is license reasons?
___
svn-src-stable-10@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-stable-10
To unsubscribe, send any mail to "svn-src-stable-10-unsubscr...@freebsd.org"