Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-13 Thread Jean-Philippe Ouellet
On 3/12/14 11:15 PM, Loganaden Velvindron wrote:
 I've read about the file vulnerability, and capsicumization also
 came to mind. However, there was also a discussion when i was
 playing with capsicum and openssh, about the limits of capsicum.
 Capsicum doesn't prevent DoS, and we still need rlimit on FreeBSD
 in addition to capsicum.

Yep, I consider it as an incremental improvement, not a complete
solution.

 I would suggest that you come up with a regression plan to test
 the demons in base and the most popular one in ports. In this
 case, unbound was not capsicumised, but the changes made to the
 kernel affected unbound.

I plan to build a src/regress/sys/kern/capsicum as I implement
various functionality, but as for other services and such, I'm not
sure how best to go about formally testing that. For larger
integration-test stuff I generally just throw all my experimental
code on all my production boxes and watch what happens. The more
people who use those services the better because if something is
broken I'll find out earlier and I can fix it. That's also the
impression I got of how the pre-release testing cycle seems to work
here.

 Also, please look into FreeBSD's regression test suite for capsicum.

I'm aware of:
http://svnweb.freebsd.org/base/head/tools/regression/security/cap_test/
http://svnweb.freebsd.org/base/head/tools/regression/capsicum/
https://github.com/google/capsicum-test

is there something else?

 Good testing coverage is also very important

Agreed.

 There's going to be a lot of follow-up to do. I would suggest
 that you contact the maintainers and see who is interested in getting
 capsicum into their demon.  The response may be varied.

I was going to wait until it's at a usable state before I solicit
effort from others, otherwise it's just pointless discussion, but
yes, that's the plan. In the mean time, I'll just shut up and hack.

 The patches will probably be peer reviewed by many people, as
 capsicum touches different areas of the kernel. This process will
 take time.

Naturally. I'd expect nothing less! :)



Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-13 Thread Loganaden Velvindron
On Thu, Mar 13, 2014 at 10:08 AM, Jean-Philippe Ouellet
jean-phili...@ouellet.biz wrote:
 On 3/12/14 11:15 PM, Loganaden Velvindron wrote:
 I've read about the file vulnerability, and capsicumization also
 came to mind. However, there was also a discussion when i was
 playing with capsicum and openssh, about the limits of capsicum.
 Capsicum doesn't prevent DoS, and we still need rlimit on FreeBSD
 in addition to capsicum.

 Yep, I consider it as an incremental improvement, not a complete
 solution.

 I would suggest that you come up with a regression plan to test
 the demons in base and the most popular one in ports. In this
 case, unbound was not capsicumised, but the changes made to the
 kernel affected unbound.

 I plan to build a src/regress/sys/kern/capsicum as I implement
 various functionality, but as for other services and such, I'm not
 sure how best to go about formally testing that. For larger
 integration-test stuff I generally just throw all my experimental
 code on all my production boxes and watch what happens. The more
 people who use those services the better because if something is
 broken I'll find out earlier and I can fix it. That's also the
 impression I got of how the pre-release testing cycle seems to work
 here.

I'm not a mentor, but I'd be happy to help you in any way I can. You
can send mails
to  tech@ for testing your diffs.

Also, it will probably help to contact the port maintainers as well, and ask
them to test the capsicum diffs, to make sure that we don't end up with things
like unbound crashing on OpenBSD.



 Also, please look into FreeBSD's regression test suite for capsicum.

 I'm aware of:
 http://svnweb.freebsd.org/base/head/tools/regression/security/cap_test/
 http://svnweb.freebsd.org/base/head/tools/regression/capsicum/
 https://github.com/google/capsicum-test

 is there something else?

Those are what I'm aware as well.


 Good testing coverage is also very important

 Agreed.

 There's going to be a lot of follow-up to do. I would suggest
 that you contact the maintainers and see who is interested in getting
 capsicum into their demon.  The response may be varied.

 I was going to wait until it's at a usable state before I solicit
 effort from others, otherwise it's just pointless discussion, but
 yes, that's the plan. In the mean time, I'll just shut up and hack.

What I'm referring to here is that some developers are interested in
capsicum, and
others are less interested. If you plan on working on capsicum on say
ntpd, then it
would help to contact the maintainer of ntp and see if he's
interested. If he is, then
you can put it on your workplan for your gsoc. It doesn't help much if
there is no interest
in merging the code upstream IMHO.

Please see this discussion for opensmtpd:
https://www.mail-archive.com/misc@opensmtpd.org/msg00641.html



 The patches will probably be peer reviewed by many people, as
 capsicum touches different areas of the kernel. This process will
 take time.

 Naturally. I'd expect nothing less! :)

I hope that you will stick around after the gsoc :-)





-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-13 Thread Jean-Philippe Ouellet
On 3/13/14 2:39 AM, Loganaden Velvindron wrote:
 I'm not a mentor, but I'd be happy to help you in any way I can.
 You can send mails to tech@ for testing your diffs.

Any chance you'd like to review my bootloader patch from last month then?

http://marc.info/?l=openbsd-techm=139408992902933

I still haven't gotten any feedback.

 What I'm referring to here is that some developers are interested in
 capsicum, and others are less interested. If you plan on working on
 capsicum on say ntpd, then it would help to contact the maintainer of
 ntp and see if he's interested. If he is, then you can put it on your
 workplan for your gsoc. It doesn't help much if there is no interest
 in merging the code upstream IMHO.

 Please see this discussion for opensmtpd:
 https://www.mail-archive.com/misc@opensmtpd.org/msg00641.html

I see. OpenNTPD was actually one of the services I hilighted as a
potentially good candidate in the short proposal thing I submitted
as google's requirement.

 I hope that you will stick around after the gsoc :-)

Oh, I've been around a while, mostly just lurking, and I don't plan on
going anywhere. The question is more about finding time to contribute.



Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-13 Thread Loganaden Velvindron
On Thu, Mar 13, 2014 at 10:57 AM, Jean-Philippe Ouellet
jean-phili...@ouellet.biz wrote:
 On 3/13/14 2:39 AM, Loganaden Velvindron wrote:
 I'm not a mentor, but I'd be happy to help you in any way I can.
 You can send mails to tech@ for testing your diffs.

 Any chance you'd like to review my bootloader patch from last month then?

I'm not a committer, but I can test your diff once I get back home. I
have a sparc64 machine.
It needs to powered on. Your best bet is asking a guy who hacks on
Sparc64. Check out the commit
logs to see who last hacked on that area.


 http://marc.info/?l=openbsd-techm=139408992902933

 I still haven't gotten any feedback.

 What I'm referring to here is that some developers are interested in
 capsicum, and others are less interested. If you plan on working on
 capsicum on say ntpd, then it would help to contact the maintainer of
 ntp and see if he's interested. If he is, then you can put it on your
 workplan for your gsoc. It doesn't help much if there is no interest
 in merging the code upstream IMHO.

 Please see this discussion for opensmtpd:
 https://www.mail-archive.com/misc@opensmtpd.org/msg00641.html

 I see. OpenNTPD was actually one of the services I hilighted as a
 potentially good candidate in the short proposal thing I submitted
 as google's requirement.

Is that proposal available online ?


 I hope that you will stick around after the gsoc :-)

 Oh, I've been around a while, mostly just lurking, and I don't plan on
 going anywhere. The question is more about finding time to contribute.

:-)





-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: inteldrm/radeondrm suspend/resume diff

2014-03-13 Thread Timo Myyrä
Mark Kettenis mark.kette...@xs4all.nl writes:

 The recent inteldrm suspend/resume regression thread pointed out
 that suspend/resume was quite horribly broken and only worked somewhat
 if you didn't heavily use the 3D acceleration stuff.  Here's a diff
 that should fix most of the problems, by making sure userland programs
 are properly blocked if they try to use drm while we're suspending or
 resuming the machine.

 I would like to see this diff tested some more by people who actually
 use all that eye candy.  The thing to watch for is hangs when you try
 to suspend your machine.

 Thanks,

 Mark

 P.S. This seems to make hibernation (ZZZ) work with both inteldrm(4)
 and radeondrm(4) on my t400.


 Index: drmP.h
 ===
 RCS file: /cvs/src/sys/dev/pci/drm/drmP.h,v
 retrieving revision 1.169
 diff -u -p -r1.169 drmP.h
 --- drmP.h9 Mar 2014 07:42:29 -   1.169
 +++ drmP.h12 Mar 2014 21:38:43 -
 @@ -785,6 +785,10 @@ struct drm_device {
   bus_dma_tag_t   dmat;
   bus_space_tag_t bst;
  
 + struct mutexquiesce_mtx;
 + int quiesce;
 + int quiesce_count;
 +
   char  *unique;  /* Unique identifier: e.g., busid  */
   int   unique_len;   /* Length of unique field  */
   
 Index: drm_drv.c
 ===
 RCS file: /cvs/src/sys/dev/pci/drm/drm_drv.c,v
 retrieving revision 1.124
 diff -u -p -r1.124 drm_drv.c
 --- drm_drv.c 9 Mar 2014 07:42:29 -   1.124
 +++ drm_drv.c 12 Mar 2014 21:38:43 -
 @@ -63,8 +63,12 @@ int drm_lastclose(struct drm_device *);
  void  drm_attach(struct device *, struct device *, void *);
  int   drm_probe(struct device *, void *, void *);
  int   drm_detach(struct device *, int);
 +void  drm_quiesce(struct drm_device *);
 +void  drm_wakeup(struct drm_device *);
 +int   drm_activate(struct device *, int);
  int   drmprint(void *, const char *);
  int   drmsubmatch(struct device *, void *, void *);
 +int   drm_do_ioctl(struct drm_device *, int, u_long, caddr_t);
  int   drm_dequeue_event(struct drm_device *, struct drm_file *, size_t,
struct drm_pending_event **);
  
 @@ -212,6 +216,7 @@ drm_attach(struct device *parent, struct
  
   rw_init(dev-dev_lock, drmdevlk);
   mtx_init(dev-event_lock, IPL_TTY);
 + mtx_init(dev-quiesce_mtx, IPL_NONE);
  
   TAILQ_INIT(dev-maplist);
   SPLAY_INIT(dev-files);
 @@ -293,9 +298,47 @@ drm_detach(struct device *self, int flag
   return 0;
  }
  
 +void
 +drm_quiesce(struct drm_device *dev)
 +{
 + mtx_enter(dev-quiesce_mtx);
 + dev-quiesce = 1;
 + while (dev-quiesce_count  0) {
 + msleep(dev-quiesce_count, dev-quiesce_mtx,
 + PZERO, drmqui, 0);
 + }
 + mtx_leave(dev-quiesce_mtx);
 +}
 +
 +void
 +drm_wakeup(struct drm_device *dev)
 +{
 + mtx_enter(dev-quiesce_mtx);
 + dev-quiesce = 0;
 + wakeup(dev-quiesce);
 + mtx_leave(dev-quiesce_mtx);
 +}
 +
 +int
 +drm_activate(struct device *self, int act)
 +{
 + struct drm_device *dev = (struct drm_device *)self;
 +
 + switch (act) {
 + case DVACT_QUIESCE:
 + drm_quiesce(dev);
 + break;
 + case DVACT_WAKEUP:
 + drm_wakeup(dev);
 + break;
 + }
 +
 + return (0);
 +}
 +
  struct cfattach drm_ca = {
   sizeof(struct drm_device), drm_probe, drm_attach,
 - drm_detach
 + drm_detach, drm_activate
  };
  
  struct cfdriver drm_cd = {
 @@ -540,20 +583,13 @@ done:
   return (retcode);
  }
  
 -/* drmioctl is called whenever a process performs an ioctl on /dev/drm.
 - */
  int
 -drmioctl(dev_t kdev, u_long cmd, caddr_t data, int flags, 
 -struct proc *p)
 +drm_do_ioctl(struct drm_device *dev, int minor, u_long cmd, caddr_t data)
  {
 - struct drm_device *dev = drm_get_device_from_kdev(kdev);
   struct drm_file *file_priv;
  
 - if (dev == NULL)
 - return ENODEV;
 -
   DRM_LOCK();
 - file_priv = drm_find_file_by_minor(dev, minor(kdev));
 + file_priv = drm_find_file_by_minor(dev, minor);
   DRM_UNLOCK();
   if (file_priv == NULL) {
   DRM_ERROR(can't find authenticator\n);
 @@ -715,6 +751,34 @@ drmioctl(dev_t kdev, u_long cmd, caddr_t
   return (EINVAL);
  }
  
 +/* drmioctl is called whenever a process performs an ioctl on /dev/drm.
 + */
 +int
 +drmioctl(dev_t kdev, u_long cmd, caddr_t data, int flags, struct proc *p)
 +{
 + struct drm_device *dev = drm_get_device_from_kdev(kdev);
 + int error;
 +
 + if (dev == NULL)
 + return ENODEV;
 +
 + mtx_enter(dev-quiesce_mtx);
 + while (dev-quiesce)
 + msleep(dev-quiesce, dev-quiesce_mtx, PZERO, drmioc, 0);
 + dev-quiesce_count++;
 + mtx_leave(dev-quiesce_mtx);
 +
 + error = drm_do_ioctl(dev, minor(kdev), 

Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-13 Thread dpl
Wow, I like to see this activity. I'm the one that started this thread.

Jean-Phillipe: The main problem we'll have if both of us work on this is
that it won't not be possible to work on userland if the kernel doesn't yet
provide capability mode.

Also, I think that both of us working in this project is not a good idea
(specially given that what I liked most of this idea is the fact of getting
to know the OpenBSD kernel, and work with it at the low level). FWIW, some
future work with this would be great, but only after having the basic
Capsicum support in the kernel.

It's either that, or having a competition, and I would rather be able to
work on something else than having a silly competition for a job, specially
when there's a lot of work to be done :)

Loganaden, many thanks for the awesome email(s) you sent here.
I already contacted the Implement clang/llvm static code checker mentor,
and he is quite responsive, so it seems that I just have found my proposal
for OpenBSD :)

Many thanks to everyone, and I'm happy to see that from this thread has
sprung some activity over here.

2014-03-12 22:01 GMT+01:00 Jean-Philippe Ouellet jean-phili...@ouellet.biz
:

 On 3/12/14 4:58 AM, tuchalia wrote:
  Should l try to port also the Casper daemon to OpenBSD,  or
  only work in the kernel implementation?

 Based on more private mail, I figured it'd be a good idea to make what I
 plan to work on public in case there are others interested so we can
 avoid stepping on each others' toes.

 I've been told that the OpenBSD project's main objective in supporting
 capsicum is to have stronger privsep in our default services (think ssh,
 etc.) and the first steps to support that are the relevant kernel
 changes, therefore that's what I plan to work on first.

 I wasn't planning on doing anything with casper, user angels, etc. and
 even porting libcapsicum was a 2ndary objective, at least not during
 this summer.

 There's also a ton of userland things besides daemons/services that
 could (probably should) be capsicumized.

 Just yesterday there was just a vuln reported by the debian folks in
 their file(1) that potentially allowed arbitrary code execution. I
 immediately checked our implementation and didn't see the same code that
 was patched, but our src/usr.bin/file/softmagic.c still contains a ton
 of logic which probably has at least one bug somewhere, and file(1)
 should be a fairly easily capsicumizable utility.

 Userland capsicumization is something that could very easily be done by
 multiple people since it's naturally separated into small chunks (per
 utility). I planned to focus on getting the primary kernel
 infrastructure in place this summer (because it's a somewhat large
 project, and it would definitely help to be sponsored by Google so I can
 focus on it) and then it'd be easier to work on userland stuff in small
 chunks of free time throughout the next school year.

 The reason I really want to work on Capsicum is because it addresses my
 primary concern with OpenBSD: the poor availability of post-exploit
 mitigation techniques, especially post-parallelism with sysjail. I
 haven't completely bought into what appears to me to be Robert Watson's
 greater vision of a realistic transition path towards
 capability-oriented operating systems, I mostly just want to improve the
 tools I use every day.




-- 
Daniel


Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-13 Thread Jean-Philippe Ouellet
On 3/13/14 3:18 AM, Loganaden Velvindron wrote:
 On 3/13/14 10:57 AM, Jean-Philippe Ouellet wrote:
 On 3/13/14 2:39 AM, Loganaden Velvindron wrote:
 I'm not a mentor, but I'd be happy to help you in any way I can.
 You can send mails to tech@ for testing your diffs.

 Any chance you'd like to review my bootloader patch from last month
 then?

 I'm not a committer, but I can test your diff once I get back home.
 I have a sparc64 machine. It needs to powered on. Your best bet is
 asking a guy who hacks on Sparc64. Check out the commit logs to see
 who last hacked on that area.

Ofwboot hasn't had many substantive changes in years. There was the
early entropy stuff, PIE stuff, and some minor cleanups, but otherwise
it's just been left alone. (as it should IMO. it's minimal and that's
what I want. I consider this patch to reduce the complexity of the
required booting infrastructure in general, as it eliminates the
need for more daemons and stuff on your lan.)

I was wondering whether I should bug kettenis@ about it since AFAIK
he's the main sparc64 guy, but the part that I think maybe should
change before it's considered for OKs is the ugly (although I'm pretty
sure correct) NFS URL parsing code, which really anybody could look at
as it isn't hardware-specific.

Is it considered rude to bug specific people about patches? I assumed
someone would step forward if they were interested, and if nobody was
interested, then it didn't belong in the tree.

 I see. OpenNTPD was actually one of the services I hilighted as a
 potentially good candidate in the short proposal thing I submitted
 as google's requirement.

 Is that proposal available online ?

No, but it didn't contain anything I haven't said in some form on
tech@ by now anyway, except for the Provide a schedule estimate
with dates and important milestones in two week increments. which
I'm sure wasn't accurate anyway.



signature.asc
Description: OpenPGP digital signature


Re: GSoC proposal: Porting Capsicum to OpenBSD

2014-03-13 Thread Loganaden Velvindron
On Thu, Mar 13, 2014 at 11:44 AM, dpl tucha...@gmail.com wrote:
 Wow, I like to see this activity. I'm the one that started this thread.

 Jean-Phillipe: The main problem we'll have if both of us work on this is
 that it won't not be possible to work on userland if the kernel doesn't yet
 provide capability mode.

 Also, I think that both of us working in this project is not a good idea
 (specially given that what I liked most of this idea is the fact of getting
 to know the OpenBSD kernel, and work with it at the low level). FWIW, some
 future work with this would be great, but only after having the basic
 Capsicum support in the kernel.

 It's either that, or having a competition, and I would rather be able to
 work on something else than having a silly competition for a job, specially
 when there's a lot of work to be done :)

 Loganaden, many thanks for the awesome email(s) you sent here.
 I already contacted the Implement clang/llvm static code checker mentor,
 and he is quite responsive, so it seems that I just have found my proposal
 for OpenBSD :)

(Logan's fine)

Great !

If you have friends in your university who are interested in OpenBSD
and security stuff,
please let them know about OpenBSD's GSOC for this year !


 Many thanks to everyone, and I'm happy to see that from this thread has
 sprung some activity over here.

You're welcome.


 2014-03-12 22:01 GMT+01:00 Jean-Philippe Ouellet jean-phili...@ouellet.biz
 :

 On 3/12/14 4:58 AM, tuchalia wrote:
  Should l try to port also the Casper daemon to OpenBSD,  or
  only work in the kernel implementation?

 Based on more private mail, I figured it'd be a good idea to make what I
 plan to work on public in case there are others interested so we can
 avoid stepping on each others' toes.

 I've been told that the OpenBSD project's main objective in supporting
 capsicum is to have stronger privsep in our default services (think ssh,
 etc.) and the first steps to support that are the relevant kernel
 changes, therefore that's what I plan to work on first.

 I wasn't planning on doing anything with casper, user angels, etc. and
 even porting libcapsicum was a 2ndary objective, at least not during
 this summer.

 There's also a ton of userland things besides daemons/services that
 could (probably should) be capsicumized.

 Just yesterday there was just a vuln reported by the debian folks in
 their file(1) that potentially allowed arbitrary code execution. I
 immediately checked our implementation and didn't see the same code that
 was patched, but our src/usr.bin/file/softmagic.c still contains a ton
 of logic which probably has at least one bug somewhere, and file(1)
 should be a fairly easily capsicumizable utility.

 Userland capsicumization is something that could very easily be done by
 multiple people since it's naturally separated into small chunks (per
 utility). I planned to focus on getting the primary kernel
 infrastructure in place this summer (because it's a somewhat large
 project, and it would definitely help to be sponsored by Google so I can
 focus on it) and then it'd be easier to work on userland stuff in small
 chunks of free time throughout the next school year.

 The reason I really want to work on Capsicum is because it addresses my
 primary concern with OpenBSD: the poor availability of post-exploit
 mitigation techniques, especially post-parallelism with sysjail. I
 haven't completely bought into what appears to me to be Robert Watson's
 greater vision of a realistic transition path towards
 capability-oriented operating systems, I mostly just want to improve the
 tools I use every day.




 --
 Daniel



-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.



Re: inteldrm/radeondrm suspend/resume diff

2014-03-13 Thread Mark Kettenis
 Date: Wed, 12 Mar 2014 22:54:06 +0100 (CET)
 From: Mark Kettenis mark.kette...@xs4all.nl
 
 The recent inteldrm suspend/resume regression thread pointed out
 that suspend/resume was quite horribly broken and only worked somewhat
 if you didn't heavily use the 3D acceleration stuff.  Here's a diff
 that should fix most of the problems, by making sure userland programs
 are properly blocked if they try to use drm while we're suspending or
 resuming the machine.
 
 I would like to see this diff tested some more by people who actually
 use all that eye candy.  The thing to watch for is hangs when you try
 to suspend your machine.
 
 Thanks,
 
 Mark
 
 P.S. This seems to make hibernation (ZZZ) work with both inteldrm(4)
 and radeondrm(4) on my t400.

Here's a slightly better diff that should eleminate a (largely
theoretical) deadlock.  If you didn't test yet, try this version
instead.

Index: drmP.h
===
RCS file: /home/cvs/src/sys/dev/pci/drm/drmP.h,v
retrieving revision 1.169
diff -u -p -r1.169 drmP.h
--- drmP.h  9 Mar 2014 07:42:29 -   1.169
+++ drmP.h  12 Mar 2014 22:06:11 -
@@ -785,6 +785,10 @@ struct drm_device {
bus_dma_tag_t   dmat;
bus_space_tag_t bst;
 
+   struct mutexquiesce_mtx;
+   int quiesce;
+   int quiesce_count;
+
char  *unique;  /* Unique identifier: e.g., busid  */
int   unique_len;   /* Length of unique field  */

Index: drm_drv.c
===
RCS file: /home/cvs/src/sys/dev/pci/drm/drm_drv.c,v
retrieving revision 1.124
diff -u -p -r1.124 drm_drv.c
--- drm_drv.c   9 Mar 2014 07:42:29 -   1.124
+++ drm_drv.c   13 Mar 2014 09:25:38 -
@@ -63,8 +63,12 @@ int   drm_lastclose(struct drm_device *);
 voiddrm_attach(struct device *, struct device *, void *);
 int drm_probe(struct device *, void *, void *);
 int drm_detach(struct device *, int);
+voiddrm_quiesce(struct drm_device *);
+voiddrm_wakeup(struct drm_device *);
+int drm_activate(struct device *, int);
 int drmprint(void *, const char *);
 int drmsubmatch(struct device *, void *, void *);
+int drm_do_ioctl(struct drm_device *, int, u_long, caddr_t);
 int drm_dequeue_event(struct drm_device *, struct drm_file *, size_t,
 struct drm_pending_event **);
 
@@ -212,6 +216,7 @@ drm_attach(struct device *parent, struct
 
rw_init(dev-dev_lock, drmdevlk);
mtx_init(dev-event_lock, IPL_TTY);
+   mtx_init(dev-quiesce_mtx, IPL_NONE);
 
TAILQ_INIT(dev-maplist);
SPLAY_INIT(dev-files);
@@ -293,9 +298,47 @@ drm_detach(struct device *self, int flag
return 0;
 }
 
+void
+drm_quiesce(struct drm_device *dev)
+{
+   mtx_enter(dev-quiesce_mtx);
+   dev-quiesce = 1;
+   while (dev-quiesce_count  0) {
+   msleep(dev-quiesce_count, dev-quiesce_mtx,
+   PZERO, drmqui, 0);
+   }
+   mtx_leave(dev-quiesce_mtx);
+}
+
+void
+drm_wakeup(struct drm_device *dev)
+{
+   mtx_enter(dev-quiesce_mtx);
+   dev-quiesce = 0;
+   wakeup(dev-quiesce);
+   mtx_leave(dev-quiesce_mtx);
+}
+
+int
+drm_activate(struct device *self, int act)
+{
+   struct drm_device *dev = (struct drm_device *)self;
+
+   switch (act) {
+   case DVACT_QUIESCE:
+   drm_quiesce(dev);
+   break;
+   case DVACT_WAKEUP:
+   drm_wakeup(dev);
+   break;
+   }
+
+   return (0);
+}
+
 struct cfattach drm_ca = {
sizeof(struct drm_device), drm_probe, drm_attach,
-   drm_detach
+   drm_detach, drm_activate
 };
 
 struct cfdriver drm_cd = {
@@ -540,20 +583,13 @@ done:
return (retcode);
 }
 
-/* drmioctl is called whenever a process performs an ioctl on /dev/drm.
- */
 int
-drmioctl(dev_t kdev, u_long cmd, caddr_t data, int flags, 
-struct proc *p)
+drm_do_ioctl(struct drm_device *dev, int minor, u_long cmd, caddr_t data)
 {
-   struct drm_device *dev = drm_get_device_from_kdev(kdev);
struct drm_file *file_priv;
 
-   if (dev == NULL)
-   return ENODEV;
-
DRM_LOCK();
-   file_priv = drm_find_file_by_minor(dev, minor(kdev));
+   file_priv = drm_find_file_by_minor(dev, minor);
DRM_UNLOCK();
if (file_priv == NULL) {
DRM_ERROR(can't find authenticator\n);
@@ -715,6 +751,34 @@ drmioctl(dev_t kdev, u_long cmd, caddr_t
return (EINVAL);
 }
 
+/* drmioctl is called whenever a process performs an ioctl on /dev/drm.
+ */
+int
+drmioctl(dev_t kdev, u_long cmd, caddr_t data, int flags, struct proc *p)
+{
+   struct drm_device *dev = drm_get_device_from_kdev(kdev);
+   int error;
+
+   if (dev == NULL)
+   return ENODEV;
+
+   mtx_enter(dev-quiesce_mtx);
+   while 

Re: inteldrm/radeondrm suspend/resume diff

2014-03-13 Thread Gregor Best
On Thu, Mar 13, 2014 at 10:31:18AM +0100, Mark Kettenis wrote:
  [...]
  P.S. This seems to make hibernation (ZZZ) work with both inteldrm(4)
  and radeondrm(4) on my t400.
 
 Here's a slightly better diff that should eleminate a (largely
 theoretical) deadlock.  If you didn't test yet, try this version
 instead.
 [...]

Suspend (to RAM) and resume works fine here with

vga1 at pci0 dev 2 function 0 Intel GM965 Video rev 0x0c

Couldn't test hibernate yet because my system has root on a softraid
crypto device and the swap is outside the crypto area.

-- 
Gregor Best



Re: [xenocara] [UPDATE] freetype-2.5.3

2014-03-13 Thread David Coppa
On Thu, Mar 13, 2014 at 9:34 AM, David Coppa dco...@openbsd.org wrote:

 Hi!

 This diff updates freetype to version 2.5.3.

 It fixes a vulnerability in the CFF driver (CVE-2014-2240).

 Minor bumped due to the addition of FT_MulFix_x86_64() in
 /usr/X11R6/include/freetype2/config/ftconfig.h (is this really
 needed?)

Please wait.
There's a problem wrt the creation of the freetype2.pc file that needs
further investigation :(

Ciao,
David



Re: inteldrm/radeondrm suspend/resume diff

2014-03-13 Thread Gregor Best
On Thu, Mar 13, 2014 at 11:16:42AM +0100, Gregor Best wrote:
 [...]
 Couldn't test hibernate yet because my system has root on a softraid
 crypto device and the swap is outside the crypto area.
 [...]

David gave me a hint on how to hardwire my kernel for swap on sd0b.

With that, hibernate works slowly, but it works. The full hibernate +
resume cycle takes about one or two minutes, which I guess is fine.

I'm not sure whether hibernation working is a direct consequence of this
diff, but I think that's OK since the diff didn't break it either.

--
Gregor Best



Re: inteldrm/radeondrm suspend/resume diff

2014-03-13 Thread Marc Peters
On 03/13/14 10:31, Mark Kettenis wrote:
 Date: Wed, 12 Mar 2014 22:54:06 +0100 (CET)
 From: Mark Kettenis mark.kette...@xs4all.nl

 The recent inteldrm suspend/resume regression thread pointed out
 that suspend/resume was quite horribly broken and only worked somewhat
 if you didn't heavily use the 3D acceleration stuff.  Here's a diff
 that should fix most of the problems, by making sure userland programs
 are properly blocked if they try to use drm while we're suspending or
 resuming the machine.

 I would like to see this diff tested some more by people who actually
 use all that eye candy.  The thing to watch for is hangs when you try
 to suspend your machine.

 Thanks,

 Mark

 P.S. This seems to make hibernation (ZZZ) work with both inteldrm(4)
 and radeondrm(4) on my t400.
 
 Here's a slightly better diff that should eleminate a (largely
 theoretical) deadlock.  If you didn't test yet, try this version
 instead.

suspend/resume is working. After waking up, Jira in Chrome is no more
dead slow, as it was before.

Hibernating is not working at all at my T530 (crypto softraid on SSD
with Swap inside the softraid). I don't know, if it was working before,
but i usually use suspend. Maybe my swap partition (16G) is to few for
the RAM, didn't really check yet.

dmesg below.

Marc

dmesg:
OpenBSD 5.5-current (GENERIC.MP) #0: Thu Mar 13 11:14:31 CET 2014

root@trivago-620.trivago.local:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16845565952 (16065MB)
avail mem = 16388415488 (15629MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9d000 (68 entries)
bios0: vendor LENOVO version G4ET97WW (2.57 ) date 10/17/2013
bios0: LENOVO 24297TG
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT
FPDT ASF! UEFI UEFI MSDM SSDT SSDT UEFI DBG2
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3)
EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.58 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.11 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.11 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz, 2594.11 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus 4 (EXP3)
acpicpu0 at acpi0: C2, C1, PSS
acpicpu1 at acpi0: C2, C1, PSS
acpicpu2 at acpi0: C2, C1, PSS
acpicpu3 at acpi0: C2, C1, PSS
acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1, EHC2
acpitz0 at acpi0: critical temperature is 103 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model 45N1001 serial 27100 type LION oem SANYO
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
cpu0: Enhanced SpeedStep 2594 MHz: speeds: 2601, 2600, 2500, 2400, 2300,
2200, 2100, 2000, 1900, 1800, 1700, 1600, 1500, 1400, 1300, 1200 MHz
pci0 at 

Re: inteldrm/radeondrm suspend/resume diff

2014-03-13 Thread David Coppa
On Thu, Mar 13, 2014 at 11:53 AM, Gregor Best g...@ring0.de wrote:
 On Thu, Mar 13, 2014 at 11:16:42AM +0100, Gregor Best wrote:
 [...]
 Couldn't test hibernate yet because my system has root on a softraid
 crypto device and the swap is outside the crypto area.
 [...]

 David gave me a hint on how to hardwire my kernel for swap on sd0b.

 With that, hibernate works slowly, but it works. The full hibernate +
 resume cycle takes about one or two minutes, which I guess is fine.

 I'm not sure whether hibernation working is a direct consequence of this
 diff, but I think that's OK since the diff didn't break it either.

I currently have a regression with hibernate (reboot during resume, it
was working fine before).
I will test tonight if Mark's diff unbreaks it...

Ciao,
David



Re: inteldrm/radeondrm suspend/resume diff

2014-03-13 Thread Mattieu Baptiste
On Thu, Mar 13, 2014 at 12:23 PM, Marc Peters m...@mpeters.org wrote:

 On 03/13/14 10:31, Mark Kettenis wrote:
  Date: Wed, 12 Mar 2014 22:54:06 +0100 (CET)
  From: Mark Kettenis mark.kette...@xs4all.nl
 
  The recent inteldrm suspend/resume regression thread pointed out
  that suspend/resume was quite horribly broken and only worked somewhat
  if you didn't heavily use the 3D acceleration stuff.  Here's a diff
  that should fix most of the problems, by making sure userland programs
  are properly blocked if they try to use drm while we're suspending or
  resuming the machine.
 
  I would like to see this diff tested some more by people who actually
  use all that eye candy.  The thing to watch for is hangs when you try
  to suspend your machine.
 
  Thanks,
 
  Mark
 
  P.S. This seems to make hibernation (ZZZ) work with both inteldrm(4)
  and radeondrm(4) on my t400.
 
  Here's a slightly better diff that should eleminate a (largely
  theoretical) deadlock.  If you didn't test yet, try this version
  instead.

 suspend/resume is working. After waking up, Jira in Chrome is no more
 dead slow, as it was before.

 Hibernating is not working at all at my T530 (crypto softraid on SSD
 with Swap inside the softraid). I don't know, if it was working before,
 but i usually use suspend. Maybe my swap partition (16G) is to few for
 the RAM, didn't really check yet.



This patch also fixes the problem for me. After multiple suspend/resume
cycles, X no longer eats the CPU on my T510 with:

vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1366x768





Re: [xenocara] [UPDATE] freetype-2.5.3

2014-03-13 Thread Mark Kettenis
 Date: Thu, 13 Mar 2014 02:34:17 -0600
 From: David Coppa dco...@openbsd.org
 
 Hi!
 
 This diff updates freetype to version 2.5.3.
 
 It fixes a vulnerability in the CFF driver (CVE-2014-2240).
 
 Minor bumped due to the addition of FT_MulFix_x86_64() in
 /usr/X11R6/include/freetype2/config/ftconfig.h (is this really
 needed?)

No, that's not needed.  FT_MulFix_x86_64() is defined as a static
inline so it is not part of the ABI.



Re: [xenocara] [UPDATE] freetype-2.5.3

2014-03-13 Thread David Coppa
On Thu, Mar 13, 2014 at 3:06 PM, Mark Kettenis mark.kette...@xs4all.nl wrote:
 Date: Thu, 13 Mar 2014 02:34:17 -0600
 From: David Coppa dco...@openbsd.org

 Hi!

 This diff updates freetype to version 2.5.3.

 It fixes a vulnerability in the CFF driver (CVE-2014-2240).

 Minor bumped due to the addition of FT_MulFix_x86_64() in
 /usr/X11R6/include/freetype2/config/ftconfig.h (is this really
 needed?)

 No, that's not needed.  FT_MulFix_x86_64() is defined as a static
 inline so it is not part of the ABI.

Thanks, Mark.

I will fix my diff asap...

Ciao!
David



Re: Before sending to bug at openbsd....

2014-03-13 Thread sven falempin
On Wed, Mar 12, 2014 at 3:33 PM, sven falempin sven.falem...@gmail.com wrote:
 On Wed, Mar 12, 2014 at 2:01 PM, Stuart Henderson st...@openbsd.org wrote:
 On 2014/03/12 13:47, sven falempin wrote:
  You might do better with qemu socket network devices (or the L2TPv3
  support that was recently added to qemu head), which should allow a
  direct connection between the virtual interfaces, rather than using
  a bridge device that exists outside the VMs.
 

 qemu is 1.7.0

 something like :

 vio0(bsd1) --- socket client 127.0.0.1:5000 --- socket server
 127.0.0.1:5000 --- vio0(bsd2)

 The sockets just talk directly to each other, you don't need a server.


 Because i am an idiot and do not listen GOOD advice, i created two
 ethernet tunnel with almighty SSH.

 But apparently LACP is not forwarded, (the round robin works just
 fine), here is the trunk with the two link0 tun
 and the LACP packet sended to LACP slow protocol


 tun0: flags=9943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK0,MULTICAST mtu 
 1500
 lladdr fe:e1:ba:d1:62:79
 priority: 0
 trunk: trunkdev trunk0
 groups: tun
 status: active
 inet6 fe80::f044:d4c2:63de:2fc4%tun0 prefixlen 64 scopeid 0x8
 tun1: flags=9943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK0,MULTICAST mtu 
 1500
 lladdr fe:e1:ba:d1:62:79
 priority: 0
 trunk: trunkdev trunk0
 groups: tun
 status: active
 inet6 fe80::f044:d4c2:63de:2fc4%tun1 prefixlen 64 scopeid 0xa
 trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 lladdr fe:e1:ba:d1:62:79
 priority: 0
 trunk: trunkproto lacp
 trunk id: [(,00:00:00:00:00:00,,,),
  (,00:00:00:00:00:00,,,)]
 trunkport tun1 collecting,distributing
 trunkport tun0 collecting,distributing
 groups: trunk
 media: Ethernet autoselect
 status: active
 inet 172.18.1.2 netmask 0x broadcast 172.18.255.255
 inet6 fe80::fce1:baff:fed1:6279%trunk0 prefixlen 64 scopeid 0xb
 #  tcpdump -tteni tun0
 tcpdump: listening on tun0, link-type EN10MB
 1394652132.550634 fe:e1:ba:d7:fb:2e 01:80:c2:00:00:02 8809 124:
 LACPv1, length: 110
 1394652159.024470 fe:e1:ba:d1:62:79 01:80:c2:00:00:02 8809 124:
 LACPv1, length: 110


 I guess 01:80:c2:00:00:02 is not sent to the other side  is this
 normal , a tun should forward broadcast, should it not ?

 *go read qemu socket node*


Hello again !

Using socket qemu was a bit tricky, trying to get to socketed
interface leads to machine hang when doing ifconfig up on the second
interface (probably the addr argument is wrong).
Anyhow , trunk should work on one interface and it does but once again
only with roundrobin, NO LACP :(

the qemus is now using :
 -net nic,model=virtio,macaddr=52:54:00:12:01:01,addr=0x12 -net
socket,mcast=230.0.0.1:42421
and
 -net nic,model=virtio,macaddr=52:54:00:12:01:02,addr=0x12 -net
socket,mcast=230.0.0.1:42421

Machine number1:

bsd1 # ifconfig vio0 up
bsd1 # ifconfig trunk0 trunkport vio0 10.100.42.1/24
bsd1 # ping 10.100.42.2
PING 10.100.42.2 (10.100.42.2): 56 data bytes
64 bytes from 10.100.42.2: icmp_seq=0 ttl=255 time=20.186 ms
64 bytes from 10.100.42.2: icmp_seq=1 ttl=255 time=10.495 ms
64 bytes from 10.100.42.2: icmp_seq=2 ttl=255 time=9.848 ms
--- 10.100.42.2 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 9.848/13.509/20.186/4.730 ms
bsd1 # ifconfig trunk0 trunkproto lacp
bsd1 # ping 10.100.42.2
PING 10.100.42.2 (10.100.42.2): 56 data bytes
--- 10.100.42.2 ping statistics ---
28 packets transmitted, 0 packets received, 100.0% packet loss
bsd1 # ifconfig trunk0 down
bsd1 # ifconfig trunk0 up
bsd1 # ping 10.100.42.2
PING 10.100.42.2 (10.100.42.2): 56 data bytes
--- 10.100.42.2 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
bsd1 # ifconfig trunk0 trunkproto roundrobin
bsd1 # ping 10.100.42.2
PING 10.100.42.2 (10.100.42.2): 56 data bytes
64 bytes from 10.100.42.2: icmp_seq=0 ttl=255 time=19.379 ms
64 bytes from 10.100.42.2: icmp_seq=1 ttl=255 time=12.347 ms
64 bytes from 10.100.42.2: icmp_seq=2 ttl=255 time=10.107 ms
64 bytes from 10.100.42.2: icmp_seq=3 ttl=255 time=11.031 ms
--- 10.100.42.2 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 10.107/13.216/19.379/3.646 ms
bsd1 # ifconfig trunk0
trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 52:54:00:12:01:01
priority: 0
trunk: trunkproto roundrobin
trunkport vio0 master,active
groups: trunk
media: Ethernet autoselect
status: active
inet 10.100.42.1 netmask 0xff00 broadcast 10.100.42.255
inet6 fe80::5054:ff:fe12:101%trunk0 prefixlen 64 duplicated scopeid 0x6
bsd1 # ifconfig trunk0 trunkproto lacp
bsd1 # ping 

Re: Before sending to bug at openbsd....

2014-03-13 Thread Giancarlo Razzolini
Em 13-03-2014 11:32, sven falempin escreveu:
 On Wed, Mar 12, 2014 at 3:33 PM, sven falempin sven.falem...@gmail.com 
 wrote:
 On Wed, Mar 12, 2014 at 2:01 PM, Stuart Henderson st...@openbsd.org wrote:
 On 2014/03/12 13:47, sven falempin wrote:
 You might do better with qemu socket network devices (or the L2TPv3
 support that was recently added to qemu head), which should allow a
 direct connection between the virtual interfaces, rather than using
 a bridge device that exists outside the VMs.

 qemu is 1.7.0

 something like :

 vio0(bsd1) --- socket client 127.0.0.1:5000 --- socket server
 127.0.0.1:5000 --- vio0(bsd2)
 The sockets just talk directly to each other, you don't need a server.

 Because i am an idiot and do not listen GOOD advice, i created two
 ethernet tunnel with almighty SSH.

 But apparently LACP is not forwarded, (the round robin works just
 fine), here is the trunk with the two link0 tun
 and the LACP packet sended to LACP slow protocol


 tun0: flags=9943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK0,MULTICAST mtu 
 1500
 lladdr fe:e1:ba:d1:62:79
 priority: 0
 trunk: trunkdev trunk0
 groups: tun
 status: active
 inet6 fe80::f044:d4c2:63de:2fc4%tun0 prefixlen 64 scopeid 0x8
 tun1: flags=9943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,LINK0,MULTICAST mtu 
 1500
 lladdr fe:e1:ba:d1:62:79
 priority: 0
 trunk: trunkdev trunk0
 groups: tun
 status: active
 inet6 fe80::f044:d4c2:63de:2fc4%tun1 prefixlen 64 scopeid 0xa
 trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 lladdr fe:e1:ba:d1:62:79
 priority: 0
 trunk: trunkproto lacp
 trunk id: [(,00:00:00:00:00:00,,,),
  (,00:00:00:00:00:00,,,)]
 trunkport tun1 collecting,distributing
 trunkport tun0 collecting,distributing
 groups: trunk
 media: Ethernet autoselect
 status: active
 inet 172.18.1.2 netmask 0x broadcast 172.18.255.255
 inet6 fe80::fce1:baff:fed1:6279%trunk0 prefixlen 64 scopeid 0xb
 #  tcpdump -tteni tun0
 tcpdump: listening on tun0, link-type EN10MB
 1394652132.550634 fe:e1:ba:d7:fb:2e 01:80:c2:00:00:02 8809 124:
 LACPv1, length: 110
 1394652159.024470 fe:e1:ba:d1:62:79 01:80:c2:00:00:02 8809 124:
 LACPv1, length: 110


 I guess 01:80:c2:00:00:02 is not sent to the other side  is this
 normal , a tun should forward broadcast, should it not ?

 *go read qemu socket node*

 Hello again !

 Using socket qemu was a bit tricky, trying to get to socketed
 interface leads to machine hang when doing ifconfig up on the second
 interface (probably the addr argument is wrong).
 Anyhow , trunk should work on one interface and it does but once again
 only with roundrobin, NO LACP :(

 the qemus is now using :
  -net nic,model=virtio,macaddr=52:54:00:12:01:01,addr=0x12 -net
 socket,mcast=230.0.0.1:42421
 and
  -net nic,model=virtio,macaddr=52:54:00:12:01:02,addr=0x12 -net
 socket,mcast=230.0.0.1:42421

 Machine number1:

 bsd1 # ifconfig vio0 up
 bsd1 # ifconfig trunk0 trunkport vio0 10.100.42.1/24
 bsd1 # ping 10.100.42.2
 PING 10.100.42.2 (10.100.42.2): 56 data bytes
 64 bytes from 10.100.42.2: icmp_seq=0 ttl=255 time=20.186 ms
 64 bytes from 10.100.42.2: icmp_seq=1 ttl=255 time=10.495 ms
 64 bytes from 10.100.42.2: icmp_seq=2 ttl=255 time=9.848 ms
 --- 10.100.42.2 ping statistics ---
 3 packets transmitted, 3 packets received, 0.0% packet loss
 round-trip min/avg/max/std-dev = 9.848/13.509/20.186/4.730 ms
 bsd1 # ifconfig trunk0 trunkproto lacp
 bsd1 # ping 10.100.42.2
 PING 10.100.42.2 (10.100.42.2): 56 data bytes
 --- 10.100.42.2 ping statistics ---
 28 packets transmitted, 0 packets received, 100.0% packet loss
 bsd1 # ifconfig trunk0 down
 bsd1 # ifconfig trunk0 up
 bsd1 # ping 10.100.42.2
 PING 10.100.42.2 (10.100.42.2): 56 data bytes
 --- 10.100.42.2 ping statistics ---
 5 packets transmitted, 0 packets received, 100.0% packet loss
 bsd1 # ifconfig trunk0 trunkproto roundrobin
 bsd1 # ping 10.100.42.2
 PING 10.100.42.2 (10.100.42.2): 56 data bytes
 64 bytes from 10.100.42.2: icmp_seq=0 ttl=255 time=19.379 ms
 64 bytes from 10.100.42.2: icmp_seq=1 ttl=255 time=12.347 ms
 64 bytes from 10.100.42.2: icmp_seq=2 ttl=255 time=10.107 ms
 64 bytes from 10.100.42.2: icmp_seq=3 ttl=255 time=11.031 ms
 --- 10.100.42.2 ping statistics ---
 4 packets transmitted, 4 packets received, 0.0% packet loss
 round-trip min/avg/max/std-dev = 10.107/13.216/19.379/3.646 ms
 bsd1 # ifconfig trunk0
 trunk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
 lladdr 52:54:00:12:01:01
 priority: 0
 trunk: trunkproto roundrobin
 trunkport vio0 master,active
 groups: trunk
 media: Ethernet autoselect
 status: active
 inet 10.100.42.1 netmask 0xff00 broadcast 10.100.42.255
 inet6 fe80::5054:ff:fe12:101%trunk0 

ACPI diff: Let's expand upon our list of lies! :-)

2014-03-13 Thread Bryan Steele
It seems Microsoft has a document in an annoying format (DOCX) that
contains a list of their _OSI strings, so, let's pretend to be Windows 8
and Windows 8.1 if the firmware asks us. This could avoid buggy AML
paths on systems that don't ship with Windows 7 anymore.

http://webcache.googleusercontent.com/search?q=cache:IQGiRbuEXSUJ:download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/WinACPI_OSI.docx+

-Bryan.

Index: dsdt.c
===
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.205
diff -u -p -r1.205 dsdt.c
--- dev/acpi/dsdt.c 12 Dec 2013 20:56:01 -  1.205
+++ dev/acpi/dsdt.c 13 Mar 2014 17:06:35 -
@@ -1510,6 +1510,8 @@ char *aml_valid_osi[] = {
Windows 2001 SP4,
Windows 2006,
Windows 2009,
+   Windows 2012,
+   Windows 2013,
NULL
 };
 



Re: ACPI diff: Let's expand upon our list of lies! :-)

2014-03-13 Thread Mark Kettenis
 Date: Thu, 13 Mar 2014 13:23:40 -0400
 From: Bryan Steele bry...@openbsd.org
 
 It seems Microsoft has a document in an annoying format (DOCX) that
 contains a list of their _OSI strings, so, let's pretend to be Windows 8
 and Windows 8.1 if the firmware asks us. This could avoid buggy AML
 paths on systems that don't ship with Windows 7 anymore.
 
 http://webcache.googleusercontent.com/search?q=cache:IQGiRbuEXSUJ:download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/WinACPI_OSI.docx+
 
 -Bryan.

This will potentially screw up the brighness buttons on some machines.
Let's go ahead with it and see what happens ;)

 Index: dsdt.c
 ===
 RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
 retrieving revision 1.205
 diff -u -p -r1.205 dsdt.c
 --- dev/acpi/dsdt.c   12 Dec 2013 20:56:01 -  1.205
 +++ dev/acpi/dsdt.c   13 Mar 2014 17:06:35 -
 @@ -1510,6 +1510,8 @@ char *aml_valid_osi[] = {
   Windows 2001 SP4,
   Windows 2006,
   Windows 2009,
 + Windows 2012,
 + Windows 2013,
   NULL
  };
  
 
 



acpidump(8) man page suggestion

2014-03-13 Thread Bryan Steele
When the AML interpretor was stripped from acpidump(8) people weren't
pointed toward a better alternative. This should make it more obvious
that Intel's tools are there to play with.

-Bryan.

Index: acpidump.8
===
RCS file: /cvs/src/usr.sbin/acpidump/acpidump.8,v
retrieving revision 1.11
diff -u -p -u -r1.11 acpidump.8
--- usr.sbin/acpidump.8 8 Aug 2010 14:40:19 -   1.11
+++ usr.sbin/acpidump.8 13 Mar 2014 18:19:07 -
@@ -52,12 +52,23 @@ is unique for each table.
 .Pp
 Additionally a file called prefix.headers will be created that contains
 additional human readable information pertaining to this specific dump.
+.Pp
+The ACPICA disassembler is available through the
+.Ox
+ports tree or package system:
+.Bd -literal -offset indent
+# pkg_add acpica
+# iasl -d prefix.sig.id
+.Ed
 .Sh FILES
 .Bl -tag -width /dev/mem
 .It Pa /dev/mem
 .El
 .Sh SEE ALSO
 .Xr mem 4
+.Xr ports 7
+.Xr packages 7
+.Xr pkg_add 8
 .Sh HISTORY
 The
 .Nm



Re: acpidump(8) man page suggestion

2014-03-13 Thread Bryan Steele
On Thu, Mar 13, 2014 at 02:22:13PM -0400, Bryan Steele wrote:
..
  .Sh SEE ALSO
  .Xr mem 4
 +.Xr ports 7
 +.Xr packages 7
 +.Xr pkg_add 8
  .Sh HISTORY
  The
  .Nm

I noticed the lack of comma seperation, I'd fix that before commit.. ;)



Re: ACPI diff: Let's expand upon our list of lies! :-)

2014-03-13 Thread Theo de Raadt
I agree as well.

  It seems Microsoft has a document in an annoying format (DOCX) that
  contains a list of their _OSI strings, so, let's pretend to be Windows 8
  and Windows 8.1 if the firmware asks us. This could avoid buggy AML
  paths on systems that don't ship with Windows 7 anymore.
  
  http://webcache.googleusercontent.com/search?q=cache:IQGiRbuEXSUJ:download.microsoft.com/download/7/E/7/7E7662CF-CBEA-470B-A97E-CE7CE0D98DC2/WinACPI_OSI.docx+
  
  -Bryan.
 
 This will potentially screw up the brighness buttons on some machines.
 Let's go ahead with it and see what happens ;)
 
  Index: dsdt.c
  ===
  RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
  retrieving revision 1.205
  diff -u -p -r1.205 dsdt.c
  --- dev/acpi/dsdt.c 12 Dec 2013 20:56:01 -  1.205
  +++ dev/acpi/dsdt.c 13 Mar 2014 17:06:35 -
  @@ -1510,6 +1510,8 @@ char *aml_valid_osi[] = {
  Windows 2001 SP4,
  Windows 2006,
  Windows 2009,
  +   Windows 2012,
  +   Windows 2013,
  NULL
   };
   
  
  
 



ISY IWL 4000 Wireless Micro Adapter support for urtwn(4)

2014-03-13 Thread Fabian Raetz
Hi,

the diff below adds the ISY IWL4000 USB Wireless Micro Adapter to urtwn(4).

there was a similar diff to tech@ some time ago. See
http://openbsd.7691.n7.nabble.com/USB-Wireless-Micro-Adapter-IWL-4000-support-td219255.html
 .

I took the chipset from https://wikidevi.com/wiki/ISY_IWL_4000 .

Cheers,
Fabian


Index: if_urtwn.c
===
RCS file: /cvs/src/sys/dev/usb/if_urtwn.c,v
retrieving revision 1.33
diff -u -p -r1.33 if_urtwn.c
--- if_urtwn.c  7 Mar 2014 18:39:02 -   1.33
+++ if_urtwn.c  13 Mar 2014 20:07:52 -
@@ -84,6 +84,7 @@ static const struct usb_devno urtwn_devs
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8188CU },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8188CUS },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8192CU },
+   { USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8192CU_1 },
{ USB_VENDOR_BELKIN,USB_PRODUCT_BELKIN_RTL8192CU_2 },
{ USB_VENDOR_CHICONY,   USB_PRODUCT_CHICONY_RTL8188CUS_1 },
{ USB_VENDOR_CHICONY,   USB_PRODUCT_CHICONY_RTL8188CUS_2 },
Index: usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.624
diff -u -p -r1.624 usbdevs
--- usbdevs 9 Mar 2014 05:09:39 -   1.624
+++ usbdevs 13 Mar 2014 20:07:54 -
@@ -1170,6 +1170,7 @@ product BELKIN RTL8188CUS 0x11f2  RTL8188
 product BELKIN F5U120  0x1203  F5U120-PC Hub
 product BELKIN RTL8192CU   0x2102  RTL8192CU
 product BELKIN F7D2102 0x2103  F7D2102
+product BELKIN RTL8192CU_1 0x21f2  RTL8192CU
 product BELKIN F9L1004V1   0x1004  F9L1004V1
 product BELKIN ZD1211B 0x4050  ZD1211B
 product BELKIN F5D5055 0x5055  F5D5055
Index: usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.636
diff -u -p -r1.636 usbdevs.h
--- usbdevs.h   9 Mar 2014 05:10:52 -   1.636
+++ usbdevs.h   13 Mar 2014 20:07:56 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs.h,v 1.636 2014/03/09 05:10:52 brad Exp $  */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -1177,6 +1177,7 @@
 #defineUSB_PRODUCT_BELKIN_F5U120   0x1203  /* F5U120-PC 
Hub */
 #defineUSB_PRODUCT_BELKIN_RTL8192CU0x2102  /* RTL8192CU */
 #defineUSB_PRODUCT_BELKIN_F7D2102  0x2103  /* F7D2102 */
+#defineUSB_PRODUCT_BELKIN_RTL8192CU_1  0x21f2  /* RTL8192CU */
 #defineUSB_PRODUCT_BELKIN_F9L1004V10x1004  /* F9L1004V1 */
 #defineUSB_PRODUCT_BELKIN_ZD1211B  0x4050  /* ZD1211B */
 #defineUSB_PRODUCT_BELKIN_F5D5055  0x5055  /* F5D5055 */
Index: usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.630
diff -u -p -r1.630 usbdevs_data.h
--- usbdevs_data.h  9 Mar 2014 05:10:53 -   1.630
+++ usbdevs_data.h  13 Mar 2014 20:07:58 -
@@ -1,4 +1,4 @@
-/* $OpenBSD: usbdevs_data.h,v 1.630 2014/03/09 05:10:53 brad Exp $ */
+/* $OpenBSD$   */
 
 /*
  * THIS FILE IS AUTOMATICALLY GENERATED.  DO NOT EDIT.
@@ -1552,6 +1552,10 @@ const struct usb_known_product usb_known
{
USB_VENDOR_BELKIN, USB_PRODUCT_BELKIN_F7D2102,
F7D2102,
+   },
+   {
+   USB_VENDOR_BELKIN, USB_PRODUCT_BELKIN_RTL8192CU_1,
+   RTL8192CU,
},
{
USB_VENDOR_BELKIN, USB_PRODUCT_BELKIN_F9L1004V1,



Re: inteldrm/radeondrm suspend/resume diff

2014-03-13 Thread David Coppa
On Thu, Mar 13, 2014 at 12:31 PM, David Coppa dco...@gmail.com wrote:
 On Thu, Mar 13, 2014 at 11:53 AM, Gregor Best g...@ring0.de wrote:
 On Thu, Mar 13, 2014 at 11:16:42AM +0100, Gregor Best wrote:
 [...]
 Couldn't test hibernate yet because my system has root on a softraid
 crypto device and the swap is outside the crypto area.
 [...]

 David gave me a hint on how to hardwire my kernel for swap on sd0b.

 With that, hibernate works slowly, but it works. The full hibernate +
 resume cycle takes about one or two minutes, which I guess is fine.

 I'm not sure whether hibernation working is a direct consequence of this
 diff, but I think that's OK since the diff didn't break it either.

 I currently have a regression with hibernate (reboot during resume, it
 was working fine before).
 I will test tonight if Mark's diff unbreaks it...

I confirm this diff fixed my regression with ZZZ.

Thanks a lot, Mark.
Ciao!
David