Re: GSoC proposal: Porting Capsicum to OpenBSD
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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....
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....
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! :-)
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! :-)
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
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
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! :-)
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)
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
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