Re: GPIO for P8 Expansion Header on Beaglebone Black
> > > Most hardware + firmware combinations provide insufficient detail > > > to know what pins are used for what, reserved for what, or wired > > > to an auto-destruct. > > > > But that's by design. GPIO is simply an interface to a digital I/O pin = > > on the CPU. Everything after that is up to the end-user. > > That is not true. > > OpenBSD has no clue what it is wired to. Except on a lot of machines, > some pin has been wired to something on the board itself. > So it was, kernel being clueless, before FDT became mandatory, no? I'd guess we're more likely to run into a u-boot build in the future not providing safe voltages or such on some not-yet-existing board, that might really fry things given OpenBSD has no clue about adjusting the voltages nor input to sensors it could support. -Artturi > > Especially so since they are the ones controlling what is connected > > to those pins. > > That is not true. > > I have an armv7 machine here. It has no pins on the outside. It has > a pile of gpio devices. > > Are they all wired to nothing?? No, some of them are wired to things, > I can promise you that. > > > I bit-bang the RPI all the time, and no two of them ever uses the = > > available pins in the same way. > > That's nice. The RPI is one machine, out of a growing catagory of > machines numbering a 100+ > > Many of those machines wire pins pins to internal things. When they > do that, OpenBSD does not know. It depends on someone reading the > manual. > > Really, I suggest you go read the start of the thread.
Re: Override NGROUPS_MAX
On Wed, Jul 20, 2016 at 06:32:49PM -0400, Eric Furman wrote:
> The person didn't make a simple config change they made
> a change to the actual kernal code.
> Huge difference.
>
thank you for your reply, but that's no answer to my question, and
you have no sense for my lack of humour it seems.
the Huge difference is between kernel and kernal code, now have you used
config to make changes to usar code? you should test the diff i sent, if so.
-Artturi
> On Wed, Jul 20, 2016, at 05:02 PM, Artturi Alm wrote:
> > > Congratulations. You are no longer running OpenBSD. Your system
> > > has a significant incompatibility, and now we cannot accept any
> > > bug reports from you anymore. Any bug you hit might be due to that
> > > change you made. You own the change.
> >
> > How about config(8)?
> > "Use of an alternative kernel configuration is not recommended."
> > Rather mildly written, if it is to be understood like that.
> >
> > -Artturi
> >
> > (i'm not good w/man-pages, so..:)
> >
> > diff --git a/usr.sbin/config/main.c b/usr.sbin/config/main.c
> > index 33d82e1..71c9fc9 100644
> > --- a/usr.sbin/config/main.c
> > +++ b/usr.sbin/config/main.c
> > @@ -110,6 +110,9 @@ main(int argc, char *argv[])
> > if (pledge("stdio rpath wpath cpath flock", NULL) == -1)
> > err(1, "pledge");
> >
> > + (void)fprintf(stderr, "Any bug you hit might be due to that
> > change"
> > + " you made.\n\tYou own the change.\n");
> > +
> > pflag = eflag = uflag = fflag = 0;
> > while ((ch = getopt(argc, argv, "egpfb:s:o:u")) != -1) {
> > switch (ch) {
Re: Override NGROUPS_MAX
> Congratulations. You are no longer running OpenBSD. Your system
> has a significant incompatibility, and now we cannot accept any
> bug reports from you anymore. Any bug you hit might be due to that
> change you made. You own the change.
How about config(8)?
"Use of an alternative kernel configuration is not recommended."
Rather mildly written, if it is to be understood like that.
-Artturi
(i'm not good w/man-pages, so..:)
diff --git a/usr.sbin/config/main.c b/usr.sbin/config/main.c
index 33d82e1..71c9fc9 100644
--- a/usr.sbin/config/main.c
+++ b/usr.sbin/config/main.c
@@ -110,6 +110,9 @@ main(int argc, char *argv[])
if (pledge("stdio rpath wpath cpath flock", NULL) == -1)
err(1, "pledge");
+ (void)fprintf(stderr, "Any bug you hit might be due to that change"
+ " you made.\n\tYou own the change.\n");
+
pflag = eflag = uflag = fflag = 0;
while ((ch = getopt(argc, argv, "egpfb:s:o:u")) != -1) {
switch (ch) {
Re: Request to OpenBSD Dev's - Beer on offer
On 10/29/13 13:45, Andy wrote: Code snippets can be seen on; http://sourceforge.net/projects/kbfd/ http://sourceforge.net/projects/bfdd/ Editing these to compile and work on OpenBSD and run 'bgpctl neighbor $bfdpeer down' etc is beyond my skills.. No editing will make the license work in OpenBSD kernel, i think. -Artturi Thanks for reading, Andy. On Tue 29 Oct 2013 11:16:20 GMT, Andy wrote: Yea its 24.. Would even be happy to offer some champers.. I think this is more of a Maudite crowd.. Connoisseurs on here... As I understand it you would need to write a small daemon to do the BFD state monitoring for the transmission and reception of the heartbeats with various peers. The protocol is fairly simple so for an experienced dev this should be easy. Then in OpenBGPD you would need to have a way of gracefully and forcefully immediately shutting down the BGP neighbor that matches the BFD peer. This could be achieved by simply having the BFD daemon call 'bgpctl neighbor $bfdpeer down' It is not so important for OSPF as that already has fast convergence time with fast hello's etc.. But for BGP this would make a world of difference to remove the BGP routes immediately (in less than a second) as soon as the BGP neighbor goes down/becomes unreachable (even if not a direct link (multi-hop etc)). On 28/10/13 21:10, Dan Farrell wrote: I'm not sure how much a crate is, but if it's a case (24 bottles), then I'll throw in a case as well for this work. Blanche de Chambly, anyone? Or is this more a Maudite crowd? Sincerely, Dan Farrell On Mon, Oct 28, 2013 at 12:54 PM, Andy a...@brandwatch.com mailto:a...@brandwatch.com wrote: Hi all, Would any of the esteemed OpenBSD developers be interested in adding support for BFD (Bidirectional Forward Detection) to OpenBSD. The protocol itself seems pretty simple and provides a sub-second keep-alive mechanism to monitor links for routes. E.g. Upon BFD failure BGP or OSPF can be torn down etc thus allowing for sub-second re-convergence of i/eBGP! I can only offer a crate of beer to anyone who has the skills and is willing :) '+1's welcome from others who would be interested to show signs of support/interest.. Cheers, Andy.
Re: Verified OS concerns
On 09/20/13 00:00, thornton.rich...@gmail.com wrote: Interesting thread... Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. this is misc@, not twitter. while i finally reply to message by you, i want to ask a question. how about dropping at least the 'Wireless' out of your annoying signature? it would fit in a single line. I've never heard of Wired 4G LTE network. From: josef.winger@email.deSent: Thursday, September 19, 2013 4:30 PMTo: misc@openbsd.orgSubject: Verified OS concerns Does OpenBSD plan to varify its (main) components, to reach the level of zero-bug software? If not, isn't there any concern that (future) varified OS will render OBSD redundant one day? /jo With the hardware at large, you're likely a troll for asking. -Artturi
Re: Squeezebox (forward udp broadcasts between interfaces?) )
2013/5/10 Tor Houghton t...@bogus.net I'm running 5.2, and I am wondering if it's possible to forward broadcast requests between interfaces. I've got a Squeezebox that doesn't seem to like that the media server is on a different segment than itself. Both the media server and the Squeezebox itself send out what to be are you there packets in the form of: From Mediaserver ($int_if): 00:51:38.750309 192.168.16.3.3483 255.255.255.255.3483: udp 16 (DF) From Squeezebox ($dmz_if): 00:56:06.588102 192.168.32.130.17784 255.255.255.255.17784: udp 27 (DF) 00:56:06.589912 192.168.32.130.49127 255.255.255.255.3483: udp 37 (DF) I thought perhaps I could configure pf so (for example): pass in quick on $dmz_if proto udp to 255.255.255.255 port 17784 \ rdr-to $int_if port 17784 or perhaps: pass in quick on $dmz_if proto udp to 255.255.255.255 port 17784 \ rdr-to 192.168.16.3 port 17784 But that doesn't seem to work. Should pf be able to do this? Tor Hi, Just in case you did not even try google, here's the first hit for forwarding multicast traffic openbsd: http://undeadly.org/cgi?action=articlesid=20110222002946 The article ought to give enough clues. -Artturi
Re: turn ipw(4) off when not needed
2012/10/18 Stuart Henderson s...@spacehopper.org: On 2012-10-17, Artturi Alm artturi@gmail.com wrote: Hmm, there used to be sensors on my thinkpad T60, now sysctl hw.sensors shows me nothing, and sysctl hw does seem to wait something, i gave up after an half minute and ^C'd my way out of sysctl. this sounds like it could well be a mismatch between kernel and userland. and it was, forgot to straighten it out on misc, thanks. -Artturi
Re: turn ipw(4) off when not needed
2012/10/17 Jan Stary h...@stare.cz: This is current/i386 on an IBM Thinkpad T40. It comes with an ipw(4) wifi interface, which works fine. Anyway, the ipw(4) seems to be one of the substantial battery eaters. So I would like to not use the interface when running on battery and not actually using a wifi connection. Running 'ifconfig ipw0 down' seems to do that: the antenna icon led switches off, and time left (as reported by apm) starts increasing. (What would be a more rigorous way to see that the battery is actually running off more slowly now, others being equal? The machine doesn't have any sensors, as reported by 'sysctl hw'). I would like to let that happen automatically, if only because sometimes I forget to do that, and drain the battery considerably faster. What is the preffered way to do that? Is ifstated(8) the way? istated(8) is monitoring the 'interface link state'. Is 'no network' recognizable as an interface link state? What I would like to recognize with ipw0 is what 'no carrier' would be for an ethernet interface: is that a good analogy? 'no network' just means the interface is not associated to any network, not that there isn't a nework around, right? Now I tend to put ifconfig ipw0 | grep 'no network' /dev/null ifconfig ipw0 down into the root's crontab but that seems a bit crude. Jan Hmm, there used to be sensors on my thinkpad T60, now sysctl hw.sensors shows me nothing, and sysctl hw does seem to wait something, i gave up after an half minute and ^C'd my way out of sysctl. -Artturi
Re: Bitcoin client for OpenBSD?
2012/10/16 Fritz Wuehler fr...@spamexpire-201210.rodent.frell.theremailer.net: ...snip... Bottom line appears to be a lone miner with a normal desktop computer is not going to be able to do anything but heat up his room. I agree bitcoin is a cool concept and design and the history is fascinating. But we are probably priced out. I don't see much difference to 'real money' when thinking from standpoint of a lone miner with a normal desktop printer. we don't create the money, we just trade it, be it buying things or working to earn it etc.. -Artturi
Re: the idea of /fastboot ?
2012/10/11 Boudewijn Dijkstra sp4mtr4p.boudew...@indes.com: What about init.8 and init.c? They also mention fastboot. You're right, those were missing since i redirected output of cvs diff into a wrong file from sbin/init because of typo. i should triple-read before sending, thanks for the note. :) -Artturi -- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ (Remove the obvious prefix to reply privately.)
Re: the idea of /fastboot ?
2012/10/10 Philip Guenther guent...@gmail.com:
On Tue, Oct 9, 2012 at 5:01 PM, Theo de Raadt dera...@cvs.openbsd.org wrote:
Yes, it is a relic. You may take action against it, Ted.
Don't forget to also remove the shutdown(8) bits that use it.
Philip Guenther
was bored, does this miss anything?
Index: rc.8
===
RCS file: /cvs/src/share/man/man8/rc.8,v
retrieving revision 1.38
diff -u -p -r1.38 rc.8
--- rc.831 Jul 2011 12:46:17 - 1.38
+++ rc.810 Oct 2012 01:18:43 -
@@ -94,11 +94,6 @@ caused by hardware or software failure.
If this auto-check and repair succeeds, then the second part of
.Nm rc
is run.
-However, if the file
-.Pa /fastboot
-exists,
-fsck will not be invoked.
-The file is then removed so that fsck will be run on subsequent boots.
.Pp
The second part of
.Nm rc
Index: pathnames.h
===
RCS file: /cvs/src/sbin/shutdown/pathnames.h,v
retrieving revision 1.5
diff -u -p -r1.5 pathnames.h
--- pathnames.h 2 Jun 2003 20:06:17 - 1.5
+++ pathnames.h 10 Oct 2012 01:18:24 -
@@ -34,7 +34,6 @@
#include paths.h
-#define_PATH_FASTBOOT /fastboot
#define_PATH_HALT /sbin/halt
#define_PATH_REBOOT/sbin/reboot
#define_PATH_WALL /usr/bin/wall
Index: shutdown.8
===
RCS file: /cvs/src/sbin/shutdown/shutdown.8,v
retrieving revision 1.39
diff -u -p -r1.39 shutdown.8
--- shutdown.8 19 Nov 2007 08:51:49 - 1.39
+++ shutdown.8 10 Oct 2012 01:18:24 -
@@ -67,16 +67,6 @@ state of a corrupted or misbehaving syst
See
.Xr savecore 8
for information on how to recover this dump.
-.It Fl f
-Create the file
-.Pa /fastboot
-so that the file systems will
-.Em not
-be checked by
-.Xr fsck 8
-during the next boot.
-(See
-.Xr rc 8 ) .
.It Fl h
The system is halted at the specified
.Ar time
Index: shutdown.c
===
RCS file: /cvs/src/sbin/shutdown/shutdown.c,v
retrieving revision 1.36
diff -u -p -r1.36 shutdown.c
--- shutdown.c 24 Dec 2009 10:06:35 - 1.36
+++ shutdown.c 10 Oct 2012 01:18:24 -
@@ -56,8 +56,6 @@
#ifdef DEBUG
#undef _PATH_NOLOGIN
#define_PATH_NOLOGIN ./nologin
-#undef _PATH_FASTBOOT
-#define_PATH_FASTBOOT ./fastboot
#endif
#defineH *60*60
@@ -85,13 +83,12 @@ struct interval {
#undef S
static time_t offset, shuttime;
-static int dofast, dohalt, doreboot, dopower, dodump, mbuflen, nosync;
+static int dohalt, doreboot, dopower, dodump, mbuflen, nosync;
static sig_atomic_t killflg;
static char *whom, mbuf[BUFSIZ];
void badtime(void);
void __dead die_you_gravy_sucking_pig_dog(void);
-void doitfast(void);
void __dead finish(int);
void getoffset(char *);
void __dead loop(void);
@@ -112,7 +109,7 @@ main(int argc, char *argv[])
if (geteuid())
errx(1, NOT super-user);
#endif
- while ((ch = getopt(argc, argv, dfhknpr-)) != -1)
+ while ((ch = getopt(argc, argv, dhknpr-)) != -1)
switch (ch) {
case '-':
readstdin = 1;
@@ -120,9 +117,6 @@ main(int argc, char *argv[])
case 'd':
dodump = 1;
break;
- case 'f':
- dofast = 1;
- break;
case 'h':
dohalt = 1;
break;
@@ -147,11 +141,6 @@ main(int argc, char *argv[])
if (argc 1)
usage();
- if (dofast nosync) {
- (void)fprintf(stderr,
- shutdown: incompatible switches -f and -n.\n);
- usage();
- }
if (doreboot dohalt) {
(void)fprintf(stderr,
shutdown: incompatible switches -h and -r.\n);
@@ -340,8 +329,6 @@ die_you_gravy_sucking_pig_dog(void)
(void)printf(\rbut you'll have to do it yourself\r\n);
finish(0);
}
- if (dofast)
- doitfast();
#ifdef DEBUG
if (doreboot)
(void)printf(reboot);
@@ -349,8 +336,6 @@ die_you_gravy_sucking_pig_dog(void)
(void)printf(halt);
if (nosync)
(void)printf( no sync);
- if (dofast)
- (void)printf( no fsck);
if (dodump)
(void)printf( with dump);
(void)printf(\nkill -HUP 1\n);
@@ -489,19 +474,6 @@ getoffset(char *timearg)
}
}
-#defineFSMSG fastboot file for fsck\n
-void
-doitfast(void)
-{
- int fastfd;
-
- if ((fastfd = open(_PATH_FASTBOOT, O_WRONLY|O_CREAT|O_TRUNC,
- 0664)) = 0) {
- (void)write(fastfd, FSMSG, sizeof(FSMSG) - 1);
- (void)close(fastfd);
-
Re: Weird sudo behavior?
2012/10/9 Todd C. Miller todd.mil...@courtesan.com: This is normal behavior for the version of sudo that ships with OpenBSD. You can enable per-tty timestamps by enabling the tty_tickets option. E.g., in sudoers add a line like: Defaults tty_tickets - todd Confusingly sudoers(5) says that tty_tickets is off by default, while sudo(5)-current does claim the opposite: By default, sudo uses a tty-based time stamp which means that there is a separate time stamp for each of a user's login sessions. The tty_tickets option can be disabled to force the use of a single time stamp for all of a user's sessions. -Artturi
Re: Nginx, FCGI and C programs
2012/10/4 Ville Valkonen weezeld...@gmail.com:
Hi,
I've configured Nginx and FCGI to run some C/C++ apps, well almost.
When navitaging to http://host.foo/weezel/progut/default.cgi nginx's error log
states the following (below there is test.c, test.c == default.cgi):
2012/10/04 16:52:22 [error] 26690#0: *14 kevent() reported that connect()
failed (61: Connection refused) while connecting to upstream, client:
192.168.50.102, server: host.foo, request: GET /weezel/progut/ HTTP/1.1,
upstream: fastcgi://127.0.0.1:9001, host: host.foo
..and browser says HTTP Error 500 (Internal Server Error). I'd say the problem
lies somewhere in nginx configuration since nc 127.0.0.1 9001 let's
connections
in.
So apparently I am missing something obvious here. Therefore any help will be
appreciated. Here is the setup I've done so far:
Hi,
I'm not sure what you're exactly trying to do, is it cgi or fastcgi
you want to use?
i managed to get cgi working with fcgi-cgi, yet i didn't figure out how
to make use of fastcgi.
atleast under chroot i was receiving error about prematurely closed
connection while reading response header from upstream.
this was through unix socket. i launched the 'fastcgi processes'
by hand with spawn-fcgi, and saw them die one after another when
trying to access it via browser, to be clear, 1 process died per request,
and i had launched multiple w/-F arg for spawn-fcgi.
i'm not going to try debugging it any further, plain cgi is what i was after.
[...]
test.c
#include fcgi_stdio.h
#include stdlib.h
int count;
void
initialize(void)
{
count=0;
}
void
main(void)
{
initialize();
while (FCGI_Accept() = 0) {
printf(Content-type: text/html\r\n
\r\n
titleFastCGI Hello! (C, fcgi_stdio
library)/title
h1FastCGI Hello! (C, fcgi_stdio library)/h1
Request number %d running on host i%s/i\n,
++count, getenv(SERVER_HOSTNAME));
}
}
i
this is what i was testing plain cgi with, while the above does work,
there is no benefit for the extra w/o fastcgi, needs to be built w/-static:
#include stdio.h
int
main(void)
{
printf(Content-type: text/plain\n\n);
printf(req on host %s,
getenv(SERVER_NAME));
return 0;
}
here is my ngix.conf for testing cgi:
worker_processes 1;
events {
worker_connections 100;
}
http {
include mime.types;
default_type application/octet-stream;
keepalive_timeout 65;
server {
listen 80;
server_name 192.168.2.94;
location = /cgi-bin {
rewrite ^ /cgi-bin/ permanent;
}
location /cgi-bin/ {
fastcgi_index default.cgi;
fastcgi_pass unix:/fcgi.socket;
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
include fastcgi_params;
}
location / {
root /htdocs;
index index.html index.htm;
}
}
}
-Artturi
fopen.3
Hi, Diff below would make fopen.3 description more consistent, i think. while it's more repetitive, it does get rid of 'create text file'. -Artturi Index: fopen.3 === RCS file: /cvs/src/lib/libc/stdio/fopen.3,v retrieving revision 1.25 diff -u -p -r1.25 fopen.3 --- fopen.3 22 Jan 2012 13:02:45 - 1.25 +++ fopen.3 3 Oct 2012 01:01:21 - @@ -64,7 +64,8 @@ Open file for reading. .It Dq Li r+ Open for reading and writing. .It Dq Li w -Truncate file to zero length or create text file for writing. +Open for writing. +The file is created if it does not exist, otherwise it is truncated. .It Dq Li w+ Open for reading and writing. The file is created if it does not exist, otherwise it is truncated.
Re: How to PROVE your system is up to date?
2012/9/18 Ed Flecko edfle...@gmail.com: Thanks Ted! You lost me - could you explain what you mean, Make a list of files affected, and then demonstrate that their timestamps occur after the patch publication.? Ed I'm not Ted, but i'd say it means that you should manually keep a list of files affected by applied patches, and run the list through with stat(1) for demonstration. however, i'd try and see if they would accept script(1) file of the patching session. -Artturi
ctrl+a/c/d/e.. cwm, xterm -current
Hi, I've lost atleast ctrl after updating(amd64) from source yesterday(i think), in anything besides cwm it seems, so that's my guess for the culprit. atm. i'm too busy to test if reverting /xenocara/app/cwm/xevents.c back to 1.65 does help, being able to ^C might speed up things, tho. I'm using 'sv' encoding for wscons if that matters, and got nothing related to keyboard in .Xfiles. anyone else with these symptoms? i think this is non-trivial enough to allow this mail without dmesg etc. -Artturi
Re: ctrl+a/c/d/e.. cwm, xterm -current
2012/9/12 Alexander Polakov p...@sdf.org: * Artturi Alm artturi@gmail.com [120912 17:10]: Hi, I've lost atleast ctrl after updating(amd64) from source yesterday(i think), in anything besides cwm it seems, so that's my guess for the culprit. atm. i'm too busy to test if reverting /xenocara/app/cwm/xevents.c back to 1.65 does help, being able to ^C might speed up things, tho. I'm using 'sv' encoding for wscons if that matters, and got nothing related to keyboard in .Xfiles. anyone else with these symptoms? i think this is non-trivial enough to allow this mail without dmesg etc. -Artturi Please post your ~/.cwmrc. -- open source wizard I've been thinking i should add support for 'unmapall'. fontname sans-serif:pixelsize=12:bold sticky yes moveamount 10 borderwidth 4 snapdist 15 autogroup 0 xconsole,XConsole autogroup 0 xclock,XClock autogroup 1 xterm,XTerm autogroup 2 Buddy List,Pidgin autogroup 2 *,Pidgin command termxterm command Firefox firefox command Pidgin pidgin command - true command ranger ranger command - true command ssvnc ssvnc command - true command xmanxman command gvimgvim bind CM-Delete unmap # lock bind M-question unmap # exec bind CM-w unmap # exec_wm bind M-period unmap # ssh bind M-Return unmap # hide bind M-Down unmap # lower bind M-Up unmap # raise bind M-slashunmap # search bind C-slashunmap # menusearch bind M-Tab unmap # cycle bind MS-Tab unmap # rcycle bind CM-n unmap # label bind CM-x unmap # delete bind CM-0 unamp # nogroup bind CM-1 unmap # group1 bind CM-2 unmap # group2 bind CM-3 unmap # group3 bind CM-4 unmap # group4 bind CM-5 unmap # group5 bind CM-6 unmap # group6 bind CM-7 unmap # group7 bind CM-8 unmap # group8 bind CM-9 unmap # group9 bind M-Rightunmap # cyclegroup bind M-Left unmap # rcyclegroup bind CM-g unmap # grouptoggle bind CM-f unmap # maximize bind CM-equal unmap # vmaximize bind CMS-equal unmap # hmaximize bind CMS-f unmap # freeze bind CMS-r unmap # reload bind CMS-q unmap # quit bind M-hunmap # moveleft bind M-junmap # movedown bind M-kunmap # moveup bind M-lunmap # moveright bind M-Hunmap # bigmoveleft bind M-Junmap # bigmovedown bind M-Kunmap # bigmoveup bind M-Lunmap # bigmoveright bind CM-h unmap # resizeleft bind CM-j unmap # resizedown bind CM-k unmap # resizeup bind CM-l unmap # resizeright bind CM-H unmap # bigresizeleft bind CM-J unmap # bigresizedown bind CM-K unmap # bigresizeup bind CM-L unmap # bigresizeright bind C-Left unmap # ptrmoveleft bind C-Down unmap # ptrmovedown bind C-Up unmap # ptrmoveup bind C-Rightunmap # ptrmoveright bind CS-Leftunmap # bigptrmoveleft bind CS-Downunmap # bigptrmovedown bind CS-Up unmap # bigptrmoveup bind CS-Right unmap # bigptrmoveright bind 4S-r reload bind 4-Escape lock bind 4S-x delete bind 4-wraise bind 4-slower bind 4-dhmaximize bind 4-avmaximize bind 4-gfreeze bind 4-xhide bind 4-fmaximize bind 4-section nogroup bind C-section menusearch bind M-section search bind MS-section label bind C-Tab cyclegroup bind 4-Tab cycleingroup bind M-Tab cycle bind CS-Tab rcyclegroup bind 4S-Tab rcycleingroup bind MS-Tab rcycle #next to arrow up key on lenovo T60 bind C-XF86Back rcyclegroup bind C-XF86Forward cyclegroup bind 4-XF86Back rcycleingroup bind 4-XF86Forward cycleingroup bind M-XF86Back rcycle bind M-XF86Forward cycle bind 4-1grouponly1 bind 4-2grouponly2 bind 4-3grouponly3 bind 4-4grouponly4 bind 4-5grouponly5 bind 4-6grouponly6 bind 4-7grouponly7 bind 4-8grouponly8 bind 4-9grouponly9 bind M-1group1 bind M-2group2 bind M-3group3 bind M-4group4 bind M-5
Re: ctrl+a/c/d/e.. cwm, xterm -current
2012/9/12 Okan Demirmen o...@demirmen.com: On Wed 2012.09.12 at 16:42 +0300, Artturi Alm wrote: 2012/9/12 Alexander Polakov p...@sdf.org: * Artturi Alm artturi@gmail.com [120912 17:10]: Hi, I've lost atleast ctrl after updating(amd64) from source yesterday(i think), in anything besides cwm it seems, so that's my guess for the culprit. atm. i'm too busy to test if reverting /xenocara/app/cwm/xevents.c back to 1.65 does help, being able to ^C might speed up things, tho. I'm using 'sv' encoding for wscons if that matters, and got nothing related to keyboard in .Xfiles. anyone else with these symptoms? i think this is non-trivial enough to allow this mail without dmesg etc. -Artturi Please post your ~/.cwmrc. -- open source wizard I've been thinking i should add support for 'unmapall'. [snip] Interestingly, I lose Control with a reverted xevents.c and your .cwmrc. When you say 1.65 does help, does it solve it for you completely, or only partially? Cheers. I had not tested it yet, should have phrased it better. but reverting to 1.65 did actually work for me with my .cwmrc, just tried.
Re: ctrl+a/c/d/e.. cwm, xterm -current
2012/9/12 Artturi Alm artturi@gmail.com: 2012/9/12 Okan Demirmen o...@demirmen.com: On Wed 2012.09.12 at 16:42 +0300, Artturi Alm wrote: 2012/9/12 Alexander Polakov p...@sdf.org: * Artturi Alm artturi@gmail.com [120912 17:10]: Hi, I've lost atleast ctrl after updating(amd64) from source yesterday(i think), in anything besides cwm it seems, so that's my guess for the culprit. atm. i'm too busy to test if reverting /xenocara/app/cwm/xevents.c back to 1.65 does help, being able to ^C might speed up things, tho. I'm using 'sv' encoding for wscons if that matters, and got nothing related to keyboard in .Xfiles. anyone else with these symptoms? i think this is non-trivial enough to allow this mail without dmesg etc. -Artturi Please post your ~/.cwmrc. -- open source wizard I've been thinking i should add support for 'unmapall'. [snip] Interestingly, I lose Control with a reverted xevents.c and your .cwmrc. When you say 1.65 does help, does it solve it for you completely, or only partially? Cheers. I had not tested it yet, should have phrased it better. but reverting to 1.65 did actually work for me with my .cwmrc, just tried. I forgot to cc you, and add that with 1.66 alt+w/a/s/d did not iirc. work with cwm either, while 4/w/a/s/d did, so it's not just ctrl that is acting wrong.
ugen(4) and libusb1 confusion
Hi,
Bugs section of ugen(4) up to date? or does devel/libusb1
support reads from isochronous endpoints by mistake?
In my tests with cheap chinese video capture usb-stick,
for which the userland code
using libusb supposedly works on other platforms, it never
seems to return from read() in _sync_gen_transfer() within
openbsd backend of libusb.
I added more debug messages into ugen.c, while trying to find out
where it fails, only to find out that the code _seems_ to work as
supposed (with minimal knowledge about everything related),
just that usbd_get_xfer_status does always return 0 count.
I see that the bugs section hasn't been touched since the initial
commit about 13years ago.
Comparing uvideo(4) code in relevant parts for isoc transfers
gave me no obvious clues as to what might still be wrong with ugen.c.
I think going deeper to find out more is too much for me, without
reading specs etc..
Totally off-topic:
Index: ehci.c
===
RCS file: /cvs/src/sys/dev/usb/ehci.c,v
retrieving revision 1.125
diff -u -p -r1.125 ehci.c
--- ehci.c 7 Aug 2012 23:51:36 - 1.125
+++ ehci.c 15 Aug 2012 17:36:17 -
@@ -3884,7 +3884,7 @@ ehci_device_isoc_start(usbd_xfer_handle
splx(s);
if (sc-sc_bus.use_polling) {
- DPRINTF((Starting ohci isoc xfer with polling. Bad idea?\n));
+ DPRINTF((Starting ehci isoc xfer with polling. Bad idea?\n));
ehci_waitintr(sc, xfer);
}
Re: route(8) doc question
2012/8/1 Michael W. Lucas mwlu...@michaelwlucas.com Hi, route show displays flags for a route. But route(8) doesn't give me a conversion between those flags and their meaning. route(4) lists the flags, but in hex format and not such that I can translate UGRS into anything useful. I found the table in src/sbin/route/show.c, so my immediate purposes are met. But I *know* this has to be in a man page somewhere. Is it missing? Or did I just gloss over it somewhere? Thanks, ==ml -- Michael W. Lucas http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ Latest book: SSH Mastery http://www.michaelwlucas.com/nonfiction/ssh-mastery mwlu...@michaelwlucas.com, Twitter @mwlauthor See netstat(1), as suggested in route(8).
Re: simple PF rule? redirect port without touching address
2012/7/9 Stuart Henderson s...@spacehopper.org On 2012-07-09, Fil DiNoto fdin...@gmail.com wrote: I am trying to achieve something I thought would be simple, but haven't had any luck. I have an OpenBSD 5.0 router/firewall with public IP X.X.X.A Behind it are a mix of OpenBSD and Linux systems, all with public IP. NO NAT. I run ssh on an alternate port, XXX22. However, from a certain location I am dealing with a firewall that will not allow outbound connections on XXX22 only on 22 I have already set up a rule like this, and it works: pass in on egress proto tcp from $location1 to any port ssh rdr-to X.X.X.A port XXX22 But i was wondering if I could achieve something that would work for ALL the addresses behind the router as well without creating individual rules for each address. Something like this: pass in on egress proto tcp from $location1 to any port ssh rdr-to (original destination IP) port XXX22 nope. easiest option for this is probably a userland proxy. not sure but I reckon relayd can probably do it. Not sure either, but i would try to use divert(4).
Re: acpitz critical temperature is too high
2012/6/19 Robert Connolly robertconnolly1...@gmail.com sensorsd(8)'s low goes in the other direction. If I set low to 60C, it will go off if the CPU is running at 50C. Sensorsd(8) isn't made for such fine control as some of us would like. If the battery is low, we want the sensor to alert us. If the temperature is low, we do not want to be alerted. So a medium setting simply wouldn't work with the way sensorsd(8) works. Furthermore, I checked out Windows and Acer software, and I don't see a way of resetting the BIOS critical temperature. They use daemons, and so my kernel hack option to take advantage of acpitz(4) looks like a good idea. On Mon, Jun 18, 2012 at 8:05 PM, Artturi Alm artturi@gmail.comwrote: How about setting low to the warning level, and high to the shutdown level? That way you should be able to handle all 3 states w/o timers. below being normal, within where it notifies and steps down CPU and above where it does shutdown. I don't see the problem with that. Those three states should be enough, given that the 'warning zone' has reasonable limits, where you feel confident that it doesn't hurt running even in the long run. Ie. you've got this in your sensorsd.conf: hw.sensors.cpu0.temp0:low=50C:high=55C:command=/etc/sensorsd/temp %l and /etc/sensorsd/temp looks like this: #!/bin/sh case $1 in below) apm -A ;; within) apm -C echo 'Running HOT' | wall ;; above) shutdown -h now ;; esac Or did I miss the point?
Re: acpitz critical temperature is too high
How about setting low to the warning level, and high to the shutdown level? That way you should be able to handle all 3 states w/o timers. below being normal, within where it notifies and steps down CPU and above where it does shutdown. 2012/6/19 Robert Connolly robertconnolly1...@gmail.com I want to initiate a shutdown if the temperature gets too high. I have been using sensorsd(8), but sensorsd(8) only reacts once to the high (or low) event, leaving it up to the program/script to run timers to keep checking if the temperature gets worse. For my satisfaction, the timers would have to keep running until the system cooled down below the high temperature, so that sensorsd(8) will pick up the monitoring from there. When the temperature gets to a warning level, I would like sensorsd(8) to notify logged in users (me), mail root, step down the CPU with apm -L, and then let the kernel do a shutdown, with acpitz(4), if the temperature continues to rise to critical. This would be easier and more simple for me than using sensorsd(8) alone (no timers). I checked this out a little bit today. Some laptop manufacturers release Windows programs to control these temperature settings. I don't know if the setting is permanent/saved in BIOS, but if it is then I could run it from a Windows Livecd to reset the critical temperature. Another idea was installing Coreboot (free-bios), but I doubt my mainboard is supported, and it could brick my system. Or, configure the OpenBSD kernel to ignore the BIOS setting, and use my hard coded temperature instead. Or, use sensorsd(8) and a script. On Mon, Jun 18, 2012 at 9:35 AM, Mike Larkin mlar...@azathoth.net wrote: On Mon, Jun 18, 2012 at 06:35:58AM -0700, Robert Connolly wrote: Hello. During boot I see: acpitz0 at acpi0: critical temperature is 200 degC The acpitz(4) man page mentions that the system will power down if this critical temperature is reached. I assume this temperature is retrieved from BIOS, but I do not have an option in BIOS setup for it. Can I hard code this temperature in sys/dev/acpi/acpitz.c to a saner number? If so, it looks like I need to define sc-sc_crt, or possibly _CRT. Or is there another way to do this? Thanks Why do you want to do this? -ml
