assembler fix
This adds support for a few more instruction patterns that are
apparentl needed by gcc 4.8. Taken from binutils 2.17. Not sure if
adding NoRex64 to the existing patterns is really necessary, but it
shouldn't hurt.
ok?
Index: include/opcode/i386.h
===
RCS file: /cvs/src/gnu/usr.bin/binutils/include/opcode/i386.h,v
retrieving revision 1.14
diff -u -p -r1.14 i386.h
--- include/opcode/i386.h 9 Feb 2014 22:42:27 - 1.14
+++ include/opcode/i386.h 16 Feb 2014 10:48:50 -
@@ -1000,10 +1000,14 @@ static const template i386_optab[] = {
{movd, 2, 0x660f7e,X,CpuSSE2,FP|Modrm, { RegXMM,
Reg64|LLongMem, 0 } },
/* In the 64bit mode the short form mov immediate is redefined to have
64bit displacement value. */
-{movq, 2, 0x0f6f, X, CpuMMX, FP|Modrm, { RegMMX|LongMem,
RegMMX, 0 } },
-{movq, 2, 0x0f7f, X, CpuMMX, FP|Modrm, { RegMMX,
RegMMX|LongMem, 0 } },
-{movq, 2, 0xf30f7e,X,CpuSSE2,FP|Modrm, { RegXMM|LLongMem,
RegXMM, 0 } },
-{movq, 2, 0x660fd6,X,CpuSSE2,FP|Modrm, { RegXMM,
RegXMM|LLongMem, 0 } },
+{movq, 2, 0x0f6f, X, CpuMMX, FP|Modrm|NoRex64, { RegMMX|LongMem,
RegMMX, 0 } },
+{movq, 2, 0x0f7f, X, CpuMMX, FP|Modrm|NoRex64, { RegMMX,
RegMMX|LongMem, 0 } },
+{movq, 2, 0xf30f7e,X,CpuSSE2,FP|Modrm|NoRex64, { RegXMM|LLongMem,
RegXMM, 0 } },
+{movq, 2, 0x660fd6,X,CpuSSE2,FP|Modrm|NoRex64, { RegXMM,
RegXMM|LLongMem, 0 } },
+{movq, 2, 0x0f6e, X, Cpu64, FP|Modrm, { Reg64|LLongMem,
RegMMX, 0 } },
+{movq, 2, 0x0f7e, X, Cpu64, FP|Modrm, { RegMMX,
Reg64|LLongMem, 0 } },
+{movq, 2, 0x660f6e,X,Cpu64, FP|Modrm, { Reg64|LLongMem,
RegXMM, 0 } },
+{movq, 2, 0x660f7e,X,Cpu64, FP|Modrm, { RegXMM,
Reg64|LLongMem, 0 } },
{movq, 2, 0x88, X, Cpu64, NoSuf|D|W|Modrm|Size64,{ Reg64, Reg64|AnyMem,
0 } },
{movq, 2, 0xc6, 0, Cpu64, NoSuf|W|Modrm|Size64, { Imm32S,
Reg64|WordMem, 0 } },
{movq, 2, 0xb0, X, Cpu64, NoSuf|W|ShortForm|Size64,{ Imm64, Reg64, 0 } },
Re: Routing issues
On 2014/02/14 13:03, Alex Mathiasen wrote: Hello, First of all: I hope I am posting this to the correct maillinglist, if not then I'm sorry! I am having big issues with my OpenBSD 5.4 (Also had these issues prior to upgrading to 5.4). The server is a complete new installation - I have tried this setup with 3 different servers from different manufactures, and 4 different network cards (HP 100 Mbit, HP 4x1 Gbit, Intel 2x1 Gbit, Trend Net 1Gbit). The server is loaded with 4Gigs of RAM, and have plenty of resources available. Current load is 0.10. Kernel have not been modified or altered. The setup is as following: BGPD configured, routing enabled. The BGPD works fine, I get all the prefixes loaded, as seen below. # bgpctl show Neighbor ASMsgRcvdMsgSent OutQ Up/Down State/PrfRcvd TDC 3292 82071 16 0 00:12:47 476299 This is my sysctl.conf (kern.bufcache and net.inet.ip was added trying to resolve this issue, without result.) net.inet.ip.forwarding=1# 1=Permit forwarding (routing) of IPv4 packets kern.bufcachepercent=50 Remove this bufcachepercent=50 line, it is useless on a router and potentially harmful. net.inet.ip.ifq.maxlen=512 The issue is: I am having big diffeculties with routing my packets both to internal hosts, and external hosts. Periodically when tracing/pinging from my OpenBSD, it just can't route successfully. This also affect my ingoing and outgoing traffic, by resulting in lost packets. This is an example of attempting to ping: # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes ping: sendto: No route to host ping: wrote 8.8.8.8 64 chars, ret=-1 ping: sendto: No route to host ping: wrote 8.8.8.8 64 chars, ret=-1 ping: sendto: No route to host ping: wrote 8.8.8.8 64 chars, ret=-1 ping: sendto: No route to host ping: wrote 8.8.8.8 64 chars, ret=-1 ping: sendto: No route to host ping: wrote 8.8.8.8 64 chars, ret=-1 64 bytes from 8.8.8.8: icmp_seq=5 ttl=51 time=23.881 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=51 time=22.117 ms Second attempt: # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes ping: sendto: No route to host ping: wrote 8.8.8.8 64 chars, ret=-1 ping: sendto: No route to host ping: wrote 8.8.8.8 64 chars, ret=-1 ping: sendto: No route to host ping: wrote 8.8.8.8 64 chars, ret=-1 64 bytes from 8.8.8.8: icmp_seq=3 ttl=51 time=22.276 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=51 time=22.315 ms Third attempt: # ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=51 time=22.356 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=51 time=22.309 ms And this just keeps going on, sometimes 100% sucessfully, sometimes with 2-xx packets lost before routing is successful. Trace-routes to internal hosts: # traceroute 212.70.x.x traceroute to 212.70.x.x (212.70.x.x), 64 hops max, 40 byte packets 1 firewall (212.70.x.x5) 0.260 ms 0.224 ms 0.111 ms 2 php (212.70.x.x) 0.496 ms 0.484 ms 0.352 ms Second attempt: # traceroute 212.70.x.x traceroute to 212.70.x.x (212.70.x.x), 64 hops max, 40 byte packets 1 firewall (212.70.x.x5) 0.176 ms 0.223 ms 0.235 ms 2 php (212.70.x.x) 0.483 ms 0.474 ms 0.363 ms Third attempt: # traceroute 212.70.x.x traceroute to 212.70.x.x (212.70.x.x), 64 hops max, 40 byte packets sendto: No route to host 1 traceroute: wrote 212.70.x.x 40 chars, ret=-1 *sendto: No route to host traceroute: wrote 212.70.x.x 40 chars, ret=-1 *sendto: No route to host traceroute: wrote 212.70.x.x 40 chars, ret=-1 *sendto: No route to host 2 traceroute: wrote 212.70.x.x 40 chars, ret=-1 *sendto: No route to host traceroute: wrote 212.70.x.x 40 chars, ret=-1 *sendto: No route to host traceroute: wrote 212.70.x.x 40 chars, ret=-1 * 3 php (212.70.x.x) 0.416 ms 0.482 ms 0.474 ms Any suggestions on how I can further debug this issue, or possible resolve this once in for all? I can grant access to the server as well, if anyone feels like debugging. Looking forward to some replies. Thank you in advance. Best regards, Alex Mathiasen Some ideas: - Check bgpd log entries in /var/log/daemon - Check kernel log entries in dmesg - Examine things both when it's working fand when it's not working and compare to spot differences, for example: bgpctl show nexthop route -n get bgp peer's address route -n get failing destination ifconfig -A
kernel / userland communications
Hi, I am currently extending my asmc driver (in kernel) to listen to a userland utility (asmcctl). I want to be able to e.g. tell the kernel asmc driver to increase/decrease backlight. Now I need to get this brightness integer from userland (everybody should be able to do this without privilegdes) to the kernel module. I went through the recommended docs: An Introductory 4.4BSD Interprocess Communication Tutorial An Advanced 4.4BSD Interprocess Communication Tutorial Does IPC apply for calls between kernel and userland? Or is the syscall framework the right path ? (man 9 syscall). Trying to proceed, I could only find two additional docs explaining some principles: 1. NetBSD Documentation: Writing a pseudo device 2. OpenBSD Loadable Kernel Modules (well, I don't really wand a lkm...). I was thinking to use s.th. like wsconsctl or the usr.bin/radioctl/radioctl.c and sys/dev/radio.c, but got stuck on that machine independent stuff (struct device * radio_attach_mi ...). Can someone point me to the right direction ? thx Volker
Re: kernel / userland communications
From: Sven-Volker Nowarra peb.nowa...@bluewin.ch Date: Sun, 16 Feb 2014 14:43:07 +0100 Hi, I am currently extending my asmc driver (in kernel) to listen to a userland utility (asmcctl). In general we don;t encourage device-specific control utilities in OpenBSD; instead we try to provide generic utilities that work across an entire class of devices. For example bioctl(8) supports several hardware raid devices in a uniform way. And... I want to be able to e.g. tell the kernel asmc driver to increase/decrease backlight. Now I need to get this brightness integer from userland (everybody should be able to do this without privilegdes) to the kernel module. ...for controlling the display backlight the appropriate utility is wsconsctl: $ wsconsctl display.brightness display.brightness=100.00% $ wsconsctl display.brightness=50 display.brightness - 50.00% To make this work, your driver has to provide the ws_get_param and ws_set_param hooks. An example can be found in sys/dev/acpi/acpitoshiba.c, which hooks up the non-standard ACPI mechanism found on some Toshiba laptops.
Re: kernel / userland communications
On 2014/02/16 14:43, Sven-Volker Nowarra wrote: Hi, I am currently extending my asmc driver (in kernel) to listen to a userland utility (asmcctl). I want to be able to e.g. tell the kernel asmc driver to increase/decrease backlight. Now I need to get this brightness integer from userland (everybody should be able to do this without privilegdes) to the kernel module. I went through the recommended docs: An Introductory 4.4BSD Interprocess Communication Tutorial An Advanced 4.4BSD Interprocess Communication Tutorial Does IPC apply for calls between kernel and userland? Or is the syscall framework the right path ? (man 9 syscall). Trying to proceed, I could only find two additional docs explaining some principles: 1. NetBSD Documentation: Writing a pseudo device 2. OpenBSD Loadable Kernel Modules (well, I don't really wand a lkm...). I was thinking to use s.th. like wsconsctl or the usr.bin/radioctl/radioctl.c and sys/dev/radio.c, but got stuck on that machine independent stuff (struct device * radio_attach_mi ...). Can someone point me to the right direction ? thx Volker Hooking into the wsconsctl framework would probably be most appropriate for this. You may like to look at scoop_set_backlight / lcd_param in the source files in /sys/arch/zaurus/zaurus/ as a possible starting point.
Re: man.conf mandoc -Tlocale
Hi Ted, Ted Unangst wrote on Fri, Feb 14, 2014 at 12:42:20PM -0500: On Fri, Feb 14, 2014 at 14:02, Ingo Schwarze wrote: I even considered switching the mandoc(1) default from -Tascii to -Tlocale in general, but forgot about it again. If you like the idea, that would be something to do after unlock; it might require explicitly giving the -Tascii option in some build system and similar contexts. I think -Tlocale might be a saner default than -Tascii nowadays. People who don't want UTF-8 shouldn't have it in their LC_CTYPE, and it's hard to see why people who do want it and have it in their LC_CTYPE should be forced to give -Tlocale or something similar to each and every utility they call. Inclined to agree, but I wanted to try the conservative approach for this release. I fully understand that, and i'm not strongly opposed to your less intrusive suggestion, not even to putting it in before the release. However there are two (weak) reasons why you might decide to wait even with this less intrusive step, anyway. 1. I asked around a bit and Thomas Klausner (NetBSD) mentioned that both groff and mandoc format bare, unescaped ASCII minus characters (`-', 0x2d) found in the input stream as the three-byte UTF-8 sequence 0xe2 0x80 0x93 in the output stream when running with -Tutf8 or with -Tlocale and LC_CTYPE=*_*.UTF-8. That can be annoying when trying to copy and paste code examples from formatted manual pages. Maybe we should not rush this in but allow more time to decide whether we dislike that quick and maybe devise mitigations. More similar issues might hide under some rocks in the vicinity. 2. If we hope to switch the mandoc default anyway, switching /etc/man.conf back and forth in the process maybe just gratuitiously exercises sysmerge(8) on people's machines. I don't know how many places the output of mandoc is saved for later. Few, probably, because mandoc(1) is fast enough that we run in on demand whenever possible and usually avoid preformatting anything during builds, or where we do preformat, we use groff for that, anyway. But even missing one single instance that is hiding somewhere would just be pointless disruption in a release. Yours, Ingo
Re: man.conf mandoc -Tlocale
On Sun, Feb 16, 2014 at 03:11:07PM +0100, Ingo Schwarze wrote:
Few, probably, because mandoc(1) is fast enough that we run in on
demand whenever possible and usually avoid preformatting anything
during builds, or where we do preformat, we use groff for that, anyway.
But even missing one single instance that is hiding somewhere
would just be pointless disruption in a release.
We can try specifically poisoning mandoc in ports land, so that you would
see whenever it's invoked.
Don't remember if you're familiar with that, but it's fairly trivial to do:
the ports tree runs all the builds with PATH starting with
${WRKDIR}/bin
you can poison mandoc very easily around line 2477 of bsd.port.mk.
zap man.template
Hi, the file /usr/share/misc/man.template is horribly outdated and incomplete, compare it to mdoc.template in the same directory. I think deleting it completely is better than updating it, because nobody is supposed to manually write new man(7) manuals, certainly not in OpenBSD, but nowehere else, either, really. If you do need man(7) code, you can generate it with mandoc -Tman from mdoc(7) input, like it is done in the portable sudo(8) build system. People do continue to write and maintain tools to generate man(7) code, think of pod2man(1) or mandoc -Tman. But man.template is not helping with such tasks at all. I got an OK from jmc@ for zapping it, but want to make sure people don't regard it as still useful for reasons we missed. Objections, OKs? Ingo Index: Makefile === RCS file: /cvs/src/share/misc/Makefile,v retrieving revision 1.11 diff -u -p -r1.11 Makefile --- Makefile1 Aug 2007 21:31:45 - 1.11 +++ Makefile16 Feb 2014 14:27:23 - @@ -2,7 +2,7 @@ # from: @(#)Makefile 5.13 (Berkeley) 5/7/91 FILES= airport ascii birthtoken countrycodes eqnchar getopt \ - inter.phone license.template man.template mdoc.template \ + inter.phone license.template mdoc.template \ na.phone operator scsi_modes usb_hid_usages usb_hid_usages \ zipcodes Index: man.template === RCS file: man.template diff -N man.template --- man.template18 Oct 1995 08:44:44 - 1.1.1.1 +++ /dev/null 1 Jan 1970 00:00:00 - @@ -1,8 +0,0 @@ -.TH NAME SECTION local -.SH NAME -.SH SYNOPSIS -.SH DESCRIPTION -.SH FILES -.SH SEE ALSO -.SH DIAGNOSTICS -.SH BUGS
Re: zap man.template
Date: Sun, 16 Feb 2014 15:39:15 +0100 From: Ingo Schwarze schwa...@usta.de Hi, the file /usr/share/misc/man.template is horribly outdated and incomplete, compare it to mdoc.template in the same directory. I think deleting it completely is better than updating it, because nobody is supposed to manually write new man(7) manuals, certainly not in OpenBSD, but nowehere else, either, really. If you do need man(7) code, you can generate it with mandoc -Tman from mdoc(7) input, like it is done in the portable sudo(8) build system. People do continue to write and maintain tools to generate man(7) code, think of pod2man(1) or mandoc -Tman. But man.template is not helping with such tasks at all. I got an OK from jmc@ for zapping it, but want to make sure people don't regard it as still useful for reasons we missed. Objections, OKs? zap it!
Re: zap man.template
Zap++ Ken On 16 February 2014 10:47, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Sun, 16 Feb 2014 15:39:15 +0100 From: Ingo Schwarze schwa...@usta.de Hi, the file /usr/share/misc/man.template is horribly outdated and incomplete, compare it to mdoc.template in the same directory. I think deleting it completely is better than updating it, because nobody is supposed to manually write new man(7) manuals, certainly not in OpenBSD, but nowehere else, either, really. If you do need man(7) code, you can generate it with mandoc -Tman from mdoc(7) input, like it is done in the portable sudo(8) build system. People do continue to write and maintain tools to generate man(7) code, think of pod2man(1) or mandoc -Tman. But man.template is not helping with such tasks at all. I got an OK from jmc@ for zapping it, but want to make sure people don't regard it as still useful for reasons we missed. Objections, OKs? zap it!
Re: kernel / userland communications
...for controlling the display backlight the appropriate utility is wsconsctl: $ wsconsctl display.brightness display.brightness=100.00% $ wsconsctl display.brightness=50 display.brightness - 50.00% To make this work, your driver has to provide the ws_get_param and ws_set_param hooks. An example can be found in sys/dev/acpi/acpitoshiba.c, which hooks up the non-standard ACPI mechanism found on some Toshiba laptops. Note that part of my evil wscons plans include the introduction of a ``brightness controller'' abstraction, so that a given driver could advertize itself as a brightness controller for a given display. This should eventually get us rid of many ugly #if NFOO 0 in the code, or global function pointers tests against NULL. But this is post-release material. Miod
Re: man.conf mandoc -Tlocale
On Sun, Feb 16, 2014 at 22:19, Ingo Schwarze wrote: Ingo Schwarze wrote on Sun, Feb 16, 2014 at 03:11:07PM +0100: 1. I asked around a bit and Thomas Klausner (NetBSD) mentioned that both groff and mandoc format bare, unescaped ASCII minus characters (`-', 0x2d) found in the input stream as the three-byte UTF-8 sequence 0xe2 0x80 0x93 in the output stream when running with -Tutf8 or with -Tlocale and LC_CTYPE=*_*.UTF-8. Dmitrij D. Czarkoff just pointed out to me in private mail that this isn't true at all. I misunderstood what Thomas said. Damn. I was going to count that as feature to teach people to not blindly copy and paste samples.
Re: upd(4) proposal
On Fri, Feb 14, 2014 at 02:20:57PM +0100, Ingo Schwarze wrote: Hi, a few comments regarding the manual: Ingo, thanks for your feedback. Here follows an updated version, just documentation changes. I also submitted it to mandoc-lint, now seems cleaner. diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..a43f9f5 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +**.swp diff --git a/share/man/man4/Makefile b/share/man/man4/Makefile index beaffb8..76b20e7 100644 --- a/share/man/man4/Makefile +++ b/share/man/man4/Makefile @@ -61,7 +61,7 @@ MAN= aac.4 ac97.4 acphy.4 \ uk.4 ukbd.4 \ ukphy.4 ulpt.4 umass.4 umbg.4 umct.4 umidi.4 umodem.4 ums.4 umsm.4 \ unix.4 uow.4 uoaklux.4 uoakrh.4 uoakv.4 \ - upgt.4 upl.4 uplcom.4 ural.4 urio.4 url.4 urlphy.4 \ + upd.4 upgt.4 upl.4 uplcom.4 ural.4 urio.4 url.4 urlphy.4 \ urndis.4 urtw.4 urtwn.4 usb.4 usbf.4 uslcom.4 usps.4 \ uthum.4 uticom.4 utpms.4 utwitch.4 utrh.4 uts.4 uvideo.4 uvisor.4 \ uvscom.4 uyap.4 \ diff --git a/share/man/man4/upd.4 b/share/man/man4/upd.4 new file mode 100644 index 000..58857c7 --- /dev/null +++ b/share/man/man4/upd.4 @@ -0,0 +1,111 @@ +.\$OpenBSD$ +.\ +.\ Copyright (c) 2014 Andre de Oliveira deoliveira...@googlemail.com +.\ +.\ Permission to use, copy, modify, and distribute this software for any +.\ purpose with or without fee is hereby granted, provided that the above +.\ copyright notice and this permission notice appear in all copies. +.\ +.\ THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES +.\ WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +.\ MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +.\ ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +.\ WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +.\ ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +.\ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. +.\ +.Dd $Mdocdate: February 8 2014 $ +.Dt UPD 4 +.Os +.Sh NAME +.Nm upd +.Nd USB Power Devices battery voltage and load sensor +.Sh SYNOPSIS +.Cd upd* at uhub? +.Sh DESCRIPTION +The +.Nm +driver exposes data from USB Power Devices (such as an UPS), +as hardware sensors via +.Xr sysctl 3 . +The following devices are supported by the +.Nm +driver: +.Bl -bullet -offset indent +.It +American Power Conversion Smart-UPS 750 +.It +American Power Conversion Back-UPS CS 350 +.El +.Pp +The following sensors are provided by the +.Nm +driver, which can be monitored using +.Xr sensorsd 8 : +.Bl -bullet -offset indent +.It +Battery Nominal Voltage +.It +Battery Current Voltage +.It +Battery Charging +.It +Battery Discharging +.It +Battery Present +.It +Shutdown Imminent +.It +AC Power Present +.It +Battery Current Load +.El +.Sh EXAMPLES +In this example, the upd0 device is a regular UPS. +We use an entry on +.Xr sensorsd 8 +to take an action when the battery level is below a 70%: +.Bd -literal +hw.sensors.upd0.percent0:low=70:command=/etc/sensorsd/lowbattwarn %l +.Ed +.Pp +The contents of lowbattwarn could be: +.Bd -literal -offset indent +#!/bin/ksh + +if [ $# -lt 1 ]; then +return; +fi + +if [ $1 -lt 70 ]; then +logger ups battery warning-level, halting +/sbin/halt -p +fi +.Ed +.Sh SEE ALSO +.Xr intro 4 , +.Xr uhub 4 , +.Xr sensorsd 8 , +.Xr sysctl 8 +.Sh HISTORY +The +.Nm +driver first appeared in +.Ox 5.6 . +.Sh AUTHORS +The +.Nm +driver was written by +.An Andre de Oliveira Aq Mt deoliveira...@googlemail.com , +sponsored by Esdenera Networks GmbH. +.Sh CAVEATS +When the battery is not present, even with Battery Presence indicator set to +Off the remaining battery sensors will still be present, besides their values +cannot be trusted. +.Pp +Users of apcupsd port will notice either +.Xr ugen 4 , +is missing, it is necessary to disable the +.Nm +driver +in order to use apcupsd. diff --git a/share/man/man4/usb.4 b/share/man/man4/usb.4 index 9009e62..f631fe2 100644 --- a/share/man/man4/usb.4 +++ b/share/man/man4/usb.4 @@ -281,6 +281,8 @@ Maxim/Dallas DS2490 USB 1-Wire adapter Prolific based host-to-host adapters .It Xr usps 4 USPS composite AC power and temperature sensor +.It Xr upd 4 +USB Power Devices battery voltage and load sensor .It Xr uts 4 USB touchscreen support .It Xr uyap 4 diff --git a/sys/arch/.gitignore b/sys/arch/.gitignore new file mode 100644 index 000..af7465e --- /dev/null +++ b/sys/arch/.gitignore @@ -0,0 +1 @@ +*/compile diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC index 0a1bf36..77225c2 100644 --- a/sys/arch/amd64/conf/GENERIC +++ b/sys/arch/amd64/conf/GENERIC @@ -236,6 +236,7 @@ udsbr* at uhub?# D-Link DSB-R100 radio radio* at udsbr? # USB radio uberry*at uhub?# Research In Motion Blackberry ugen* at uhub?# USB Generic driver +upd* at uhub?# USB Power
Re: upd(4) proposal
On Fri, Feb 14, 2014 at 04:26:07PM +0100, Martin Pieuchot wrote: Hello Andre, On 14/02/14(Fri) 14:07, Andre de Oliveira wrote: hello. blambert@ suggested me to write a driver for exposing usb-based uninterruptable power systems devices data as sysctl(8) sensors, thus enabling people to write shutdown policies using sensorsd(8), which can replaces apcupsd in some cases. I received some feedback from reyk@ and blambert@, hope it's now ok for tech@ comments. I'll take more time to review your driver, it looks good. One thing for the moment, could you try to use usbd_get_report() and not rewrite your own version here ? :) Martin, thanks for this tip. I was in the hope of get more feedback from usb-skilled people posting to tech. I still couldn't realize how to properly use the hid-dev API without attaching it to uhidev(4). Currently upd(4) attaches to uhub(4) due to my lack of skill to make it attaches to uhidev(4) correctly. I will summarize the problems I faced and a list of questions for you, thanks in advance. -a
Re: upd(4) proposal
On Fri, Feb 14, 2014 at 10:26:53PM +0400, Kirill Bychkov wrote: On Fri, February 14, 2014 17:07, Andre de Oliveira wrote: hello. blambert@ suggested me to write a driver for exposing usb-based uninterruptable power systems devices data as sysctl(8) sensors, thus enabling people to write shutdown policies using sensorsd(8), which can replaces apcupsd in some cases. I received some feedback from reyk@ and blambert@, hope it's now ok for tech@ comments. -a Hi. Tested with upd0 at uhub2 port 1 American Power Conversion Back-UPS RS 500 FW:30.j5.I USB FW:j5 rev 1.10/0.06 addr 2 kirby@humppalaki:ttyp0kirby % sysctl hw.sensors.upd0 hw.sensors.upd0.volt0=1.20 VDC (battery nominal volt) hw.sensors.upd0.volt1=0.00 VDC (battery current volt) hw.sensors.upd0.indicator0=Off (battery charging) hw.sensors.upd0.indicator1=Off (battery discharging) hw.sensors.upd0.indicator2=On (battery present) hw.sensors.upd0.indicator3=Off (shutdown imminent) hw.sensors.upd0.indicator4=On (acpower present) hw.sensors.upd0.percent0=100.00% (battery load) Kirill, thank you very much for the test. Currently the problem is when UPS is attached as /dev/updX, apcupsd stops working. So shpuld /dev/upd be enabled by default? You are right, I added a caveats session to the manpage explaining this. And another moment. What is about MODBUS? Are you going to support other APC protocols? I'm monitoring apcupsd mailing lists and it doesn't look like APC is giving all the documentation for developers on demand. I don't know, my current needs are just for USB devices, iirc modbus works over rs232 and tcp. A driver for ups based on tcp-connection the doesn't sounds to have a chance to get into base. Do you have this kind of device? let me know. As it looks to me, this driver is going to have half of apcupsd usb devices support to be really useful. It has been tested with the two devices we already have in usbdevs_data.h: http://bxr.su/OpenBSD/sys/dev/usb/usbdevs_data.h#621 -a
Re: upd(4) proposal
Forgot to include tech@... Hi Andre, I tested upd(4) with my APC Back-UPS ES 550. It looks like it may only have partial support but figured the report will be helpful nonetheless. I'm currently using NUT for monitoring. dmesg: upd0 at uhub3 port 2 APC Back-UPS ES 550 FW:843.K2 .D USB FW:K2 rev 1.10/1.06 addr 3 usbdevs -v: port 1 addr 2: low speed, power 2 mA, config 1, Back-UPS ES 550 FW:843.K2 .D USB FW:K2(0x0002), APC(0x051d), rev 1.06, iSerialNumber 4B1004P9325 sysctl hw.sensors.upd0: hw.sensors.upd0.volt0=0.00 VDC (battery nominal volt) hw.sensors.upd0.volt1=0.00 VDC (battery current volt) hw.sensors.upd0.indicator0=Off (battery charging) hw.sensors.upd0.indicator1=Off (battery discharging) hw.sensors.upd0.indicator2=On (battery present) hw.sensors.upd0.indicator3=Off (shutdown imminent) hw.sensors.upd0.indicator4=On (acpower present) hw.sensors.upd0.percent0=0.00% (battery load) And for comparison here are the numbers from NUT: battery.voltage: 13.5 battery.voltage.nominal: 12.0 battery.charge: 100 ups.status: OL ups.load: 5 -- James Turner
