On Mon, Aug 18, 2014 at 6:24 PM, David Gwynne da...@gwynne.id.au wrote:
On Sun, Jul 13, 2014 at 02:01:15PM +1000, David Gwynne wrote:
i think i'll try to find the sk at work and wire it up. its just annoying
cos im pretty sure its sr optics with sc connectors.
thanks for testing.
how's
On Fri, Jan 24, 2014 at 4:24 AM, Henning Brauer
lists-openbsdt...@bsws.de wrote:
* Henning Brauer lists-openbsdt...@bsws.de [2014-01-24 05:50]:
i need this tested on an sk(4).
I don't have that hardware at all.
this gets rif od a slight little bit more.
Resurrected an old box, kernel
As of lib/libc/time/strptime.c r1.15, certain conversions will perform
calculations using the provided tm_mday value, which will frequently
produce incorrect values for tm_mday and tm_yday. Apologies in
advance for the mangled patch.
Thanks.
--david
Compare runs of the test program below:
/*
Long time user, first time patch submission. I can send this again after tree
lock, but feedback is welcome in the meantime.
I started trying to fix PR 6006 and felt like there was progress being made
for a while. I was pretty sure that x_file_glob function shouldn't have
stripped backslashes
I am trying to figure out how to handle the buggy USB firmware in my UPS (see
misc@ thread from last week). With some kernel debug enabled, I see
usb_transfer_complete: short transfer 35 messages. Since the BatteryPresent
sensor could not be read, all battery-related sensors were forced into
On Dec 4, 2014, at 4:30 PM, David Higgs hig...@gmail.com wrote:
I am trying to figure out how to handle the buggy USB firmware in my UPS (see
misc@ thread from last week). With some kernel debug enabled, I see
usb_transfer_complete: short transfer 35 messages. Since the
BatteryPresent
On Sat, Dec 6, 2014 at 8:57 AM, Martin Pieuchot mpieuc...@nolizard.org wrote:
The ohci(4) diff is almost fine, USBD_SHORT_XFER should only be set in
usbd_transfer_complete() so the HCD should only set the status to
USBD_NORMAL_COMPLETION, see below.
Concerning your broken firmware, what we
On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot mpieuc...@nolizard.org wrote:
On 08/12/14(Mon) 09:02, David Higgs wrote:
On Sat, Dec 6, 2014 at 8:57 AM, Martin Pieuchot mpieuc...@nolizard.org
wrote:
The ohci(4) diff is almost fine, USBD_SHORT_XFER should only be set
As per an earlier thread on misc@, this fixes sensorsd.conf(5) parsing of
SENSOR_INDICATOR values. Since parsing as integers was both undocumented and
confusing, it is no longer supported. Also, bail on error if the high/low
values don’t create a valid range.
This mimics existing behavior,
On Mon, Dec 8, 2014 at 6:07 PM, Martin Pieuchot mpieuc...@nolizard.org wrote:
On 08/12/14(Mon) 09:35, David Higgs wrote:
On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot mpieuc...@nolizard.org
wrote:
[...]
Now I'd like to finish the transition that started with the import of
upd(4
Working and non-working dmesgs from the same VM below. Let me know if
any more info is needed. If this is already known, sorry for the
noise.
--david
# does not work
OpenBSD 5.6-current (RAMDISK_CD) #555: Tue Dec 9 00:50:21 MST 2014
On Tue, Dec 9, 2014 at 5:02 AM, Stuart Henderson st...@openbsd.org wrote:
On 2014/12/08 15:04, David Higgs wrote:
As per an earlier thread on misc@, this fixes sensorsd.conf(5)
parsing of SENSOR_INDICATOR values. Since parsing as integers was both
undocumented and confusing, it is no longer
I was playing with afl a few weeks ago and found this. I believe it is
triggered by non-sequential timestamp records, but I didn’t dig into it or run
afl for particularly long. The patch below fixed all the crashes afl had found
up to that point.
The string used doesn’t matter, ‘crmsg’ just
On Tue, Dec 9, 2014 at 9:40 AM, Stuart Henderson st...@openbsd.org wrote:
On 2014/12/09 09:36, David Higgs wrote:
On Tue, Dec 9, 2014 at 5:02 AM, Stuart Henderson st...@openbsd.org wrote:
On 2014/12/08 15:04, David Higgs wrote:
As per an earlier thread on misc@, this fixes sensorsd.conf(5
On Tue, Dec 9, 2014 at 9:19 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Tue, 9 Dec 2014 14:12:20 +
From: Stuart Henderson st...@openbsd.org
On 2014/12/09 08:37, David Higgs wrote:
Working and non-working dmesgs from the same VM below. Let me know if
any more info is needed
On Dec 8, 2014, at 6:07 PM, Martin Pieuchot mpieuc...@nolizard.org wrote:
On 08/12/14(Mon) 09:35, David Higgs wrote:
On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot mpieuc...@nolizard.org
wrote:
[...]
Now I'd like to finish the transition that started with the import of
upd(4) and move
On Dec 9, 2014, at 9:53 AM, David Higgs hig...@gmail.com wrote:
On Tue, Dec 9, 2014 at 9:40 AM, Stuart Henderson st...@openbsd.org wrote:
I was thinking more that it might be better for sensorsd internally
to treat state transitions of indicator sensors like it treats
status changes, rather
On Thu, Dec 11, 2014 at 6:22 AM, Martin Pieuchot mpieuc...@nolizard.org wrote:
Thanks for all your comments. I though a bit more about this change and
decided to:
- Simply return the number of bytes written/read upon success and -1
otherwise (à la read/write). This allows us to remove
Now that my upd(4) is working (thanks to all involved), I’m looking to improve
behavior a bit. Let’s add some state transitions to the sensors.
Feedback is welcome.
--david
## before
[vm@vm usb]$ sysctl hw.sensors.upd0
hw.sensors.upd0.indicator0=Off (Charging), OK
First, I think the BatteryPresent check has a signedness problem. Second, I
think that it should check for sensor validity too, so it doesn’t use stale
values if BatteryPresent somehow goes straight from present to invalid.
This diff should fix both things, in theory. Compiled and running
While my device does not seem to provide AtRateTimeToFull or AtRateTimeToEmpty,
it does have RunTimeToEmpty. Then I found that SENSOR_TIMEDELTA values are in
nanoseconds and that scaling for them was never implemented correctly.
I am confused by the spec [1], though; see 4.2.5 - Battery
For consistency.
--david
Index: sensors.h
===
RCS file: /cvs/src/sys/sys/sensors.h,v
retrieving revision 1.33
diff -u -p -r1.33 sensors.h
--- sensors.h 4 Nov 2013 02:41:49 - 1.33
+++ sensors.h 18 Dec 2014 18:16:07
Bah. One of those should be (muAh).
--david
On Dec 18, 2014, at 1:48 PM, David Higgs hig...@gmail.com wrote:
Bah. One of those should be (muAh).
Take two.
--david
Index: sensors.h
===
RCS file: /cvs/src/sys/sys/sensors.h,v
retrieving revision 1.33
diff -u -p -r1.33
On Fri, Dec 19, 2014 at 7:17 AM, Martin Pieuchot mpieuc...@nolizard.org wrote:
Hello David,
On 18/12/14(Thu) 00:45, David Higgs wrote:
While my device does not seem to provide AtRateTimeToFull or
AtRateTimeToEmpty, it does have RunTimeToEmpty. Then I found that
SENSOR_TIMEDELTA values
Split upd_update_sensors() behavior to gather all values prior to updating
sensor contents.
Because sensors were updated in report_ID order, it could take multiple passes
of upd_refresh() to update some sensors. Specifically, battery-related sensors
“prior” to a change in BatteryPresent would
On Fri, Dec 19, 2014 at 8:55 AM, Martin Pieuchot mpieuc...@nolizard.org wrote:
On 19/12/14(Fri) 08:04, David Higgs wrote:
Split upd_update_sensors() behavior to gather all values prior to updating
sensor contents.
Because sensors were updated in report_ID order, it could take multiple
On Fri, Jan 9, 2015 at 2:07 PM, Martin Pieuchot mpieuc...@nolizard.org wrote:
On 09/01/15(Fri) 12:36, David Higgs wrote:
On Fri, Jan 9, 2015 at 9:00 AM, Martin Pieuchot mpieuc...@nolizard.org
wrote:
As pointed out by David Higgs, uhidev report functions do a lot of
memory allocations
I guess nobody else has tried calling uhidev_get_report_async() yet. :)
First I was getting a NULL pointer deref in the uhidev async callback.
Then I realized that due to USBD_NO_COPY, xfer-buffer was always
NULL. Next, I tried to use the DMA buffer, but I ended up in DDB in a
very cryptic way.
On Fri, Jan 9, 2015 at 9:00 AM, Martin Pieuchot mpieuc...@nolizard.org wrote:
As pointed out by David Higgs, uhidev report functions do a lot of
memory allocations and copies between buffers. This is not uncommon
in USB land due to way DMA buffers are handled.
One way to reduce the number
On Feb 13, 2015, at 7:29 AM, David Higgs hig...@gmail.com wrote:
On Friday, February 13, 2015, Martin Pieuchot mpieuc...@nolizard.org wrote:
On 13/02/15(Fri) 00:28, David Higgs wrote:
I guess nobody else has tried calling uhidev_get_report_async() yet. :)
First I was getting a NULL
On Friday, February 13, 2015, Martin Pieuchot mpieuc...@nolizard.org
wrote:
On 13/02/15(Fri) 00:28, David Higgs wrote:
I guess nobody else has tried calling uhidev_get_report_async() yet. :)
First I was getting a NULL pointer deref in the uhidev async callback.
Then I realized that due
On Feb 13, 2015, at 7:29 AM, David Higgs hig...@gmail.com wrote:
On Friday, February 13, 2015, Martin Pieuchot mpieuc...@nolizard.org wrote:
On 13/02/15(Fri) 00:28, David Higgs wrote:
I guess nobody else has tried calling uhidev_get_report_async() yet. :)
First I was getting a NULL
On Mon, Mar 9, 2015 at 6:04 AM, Martin Pieuchot mpieuc...@nolizard.org
wrote:
On 05/03/15(Thu) 12:25, David Higgs wrote:
On Mar 3, 2015, at 8:44 AM, David Higgs hig...@gmail.com wrote:
With much help from mpi@, I have made a first big step towards
improving upd(4). I'm not sure when
This was much more straightforward than expected.
- Replace an array with a LIST of allocated sensors.
- Remove or rescope variables counting sensors.
- Allocated sensors are always attached.
- Drop an unnecessary size calculation.
Thanks.
--david
--- a/upd.c
+++ b/upd.c
@@ -23,6 +23,7 @@
First in what will probably be a slow trickle, as I split my original big diff
into more-easily reviewed chunks and test each in sequence.
This patch makes upd_attach less confusing:
1. Ignore all bogus report IDs up front, they shouldn't be queried.
2. When a sensor is attached, it will be
On Wed, Apr 1, 2015 at 7:52 AM, Martin Pieuchot m...@openbsd.org wrote:
On 31/03/15(Tue) 23:06, David Higgs wrote:
This was much more straightforward than expected.
- Replace an array with a LIST of allocated sensors.
- Remove or rescope variables counting sensors.
- Allocated sensors
On Mar 3, 2015, at 8:44 AM, David Higgs hig...@gmail.com wrote:
With much help from mpi@, I have made a first big step towards improving
upd(4). I’m not sure when tree lock ends, but I’m still happy to accept
feedback if right now isn’t the time to commit. There’s plenty more to do
With much help from mpi@, I have made a first big step towards improving
upd(4). I’m not sure when tree lock ends, but I’m still happy to accept
feedback if right now isn’t the time to commit. There’s plenty more to do, but
I’d like to get this ironed out before moving on.
New behavior with
On Fri, Apr 24, 2015 at 8:43 PM, David Higgs hig...@gmail.com wrote:
Associate sensors with the reports they are updated by. Only the reports
that have sensors will be enabled, so the enabled field becomes redundant.
An important but subtle side-effect is that because the sensor tree
Associate sensors with the reports they are updated by. Only the reports that
have sensors will be enabled, so the enabled field becomes redundant.
An important but subtle side-effect is that because the sensor tree is
constructed depth-first, each report SLIST will contain sensors in
This is the final patch in the series.
Utilize the pending flags and report callback for their intended purpose - to
process async behavior.
Apply splusb() to ensure report callbacks can't fire before their data
structures have been properly updated. This only needs to happen in
Locate sensors in table order - by parsing the USB descriptor multiple times -
instead of in the order they exist in the USB descriptor.
This will greatly ease construction of a sensor dependency tree, in the next
diff.
--david
--- a/upd.c
+++ b/upd.c
@@ -86,7 +86,6 @@ struct upd_softc {
Huge thanks to all devs who provided initial feedback in spite of my
inconsistent development pace, especially mpi.
This was mainly a bugfix/infrastructure effort. There's still plenty of
work to do on new features - better sensor units, new sensors, maybe some
sysctls.
Happy to accept bug
Split out sensor value update now, since sensor updating will become more
complex.
Also, avoid potential signed/unsigned and truncation errors. Sensor values are
int64_t wide, so put them to work.
--david
--- a/upd.c
+++ b/upd.c
@@ -101,6 +101,8 @@ int upd_detach(struct device *, int);
Should be pretty straightforward.
--david
--- a/upd.c
+++ b/upd.c
@@ -39,6 +39,8 @@
#define DPRINTF(x)
#endif
+#define DEVNAME(sc)((sc)-sc_hdev.sc_dev.dv_xname)
+
struct upd_usage_entry {
uint8_t usage_pg;
uint8_t usage_id;
@@ -164,12
Divide sensors into two tables - normal sensors and battery dependent sensors.
Build the sensor dependency tree - every sensor has an SLIST of dependent
children.
Also, don’t bother looking for battery dependent sensors at device attach, it
doesn’t seem helpful.
(Someone please correct me if
This is the big change that puts all the previous work together.
When a sensor update is needed, mark its report as pending; do this in
dependency order. When a report fails to query/reply, mark it and its children
as invalid. When the BatteryPresent says there is no battery, mark its
On Thu, Apr 30, 2015 at 7:09 AM, Martin Pieuchot m...@openbsd.org wrote:
On 24/04/15(Fri) 20:48, David Higgs wrote:
This is the final patch in the series.
Utilize the pending flags and report callback for their intended purpose
- to process async behavior.
Apply splusb() to ensure
On Apr 30, 2015, at 7:09 AM, Martin Pieuchot m...@openbsd.org wrote:
On 24/04/15(Fri) 20:48, David Higgs wrote:
This is the final patch in the series.
Utilize the pending flags and report callback for their intended purpose -
to process async behavior.
Apply splusb() to ensure report
On Mon, May 11, 2015 at 8:07 PM, Alexander Hall alexan...@beard.se wrote:
Upgrading to the latest snapshot, I noticed my upd sensors had been
disturbingly crippled.
uhidev0 at uhub4 port 1 configuration 1 interface 0 EATON Eaton 3S rev
2.00/1.00 addr 2
uhidev0: iclass 3/0, 32 report ids
On May 11, 2015, at 8:21 PM, David Higgs hig...@gmail.com wrote:
On Mon, May 11, 2015 at 8:07 PM, Alexander Hall alexan...@beard.se
mailto:alexan...@beard.sewrote:
Upgrading to the latest snapshot, I noticed my upd sensors had been
disturbingly crippled.
uhidev0 at uhub4 port 1
On May 11, 2015, at 9:02 PM, David Higgs hig...@gmail.com wrote:
On May 11, 2015, at 8:21 PM, David Higgs hig...@gmail.com
mailto:hig...@gmail.com wrote:
On Mon, May 11, 2015 at 8:07 PM, Alexander Hall alexan...@beard.se
mailto:alexan...@beard.sewrote:
Upgrading to the latest snapshot
Features of this diff:
- All upd(4) reports are queried asynchronously
- Use pending status to prevent duplicate usb queries
- No apparent changes from end-user point of view
Note: depends on the previous upd(4) LIST diff, not yet committed.
As usual, feedback and comments are welcome.
--david
If there’s no further work on upd(4) prior to 5.8, at least make the man page
reflect present reality.
- Update list of supported sensors, re-sorted by source file occurrence
- Explain why manual sensorsd.conf(5) intervention can be necessary
- Link to HID power specs
- Prefer “a UPS” over “an
On Wed, Jun 10, 2015 at 5:23 AM, Martin Pieuchot m...@openbsd.org wrote:
On 02/06/15(Tue) 22:36, David Higgs wrote:
Here are some new sensors for upd(4) devices. All exist on my device
except AtRateTimeToEmpty, which still seemed a logical addition given that
AtRateTimeToFull is already
On Wed, Jun 10, 2015 at 5:23 AM, Martin Pieuchot m...@openbsd.org wrote:
On 02/06/15(Tue) 22:36, David Higgs wrote:
Here are some new sensors for upd(4) devices. All exist on my device
except AtRateTimeToEmpty, which still seemed a logical addition given that
AtRateTimeToFull is already
Here are some new sensors for upd(4) devices. All exist on my device except
AtRateTimeToEmpty, which still seemed a logical addition given that
AtRateTimeToFull is already present.
- AtRateTimeToEmpty
- RunTimeToEmpty
- NeedReplacement
- Overload
If anyone had an AtRate sensor, it was probably
On Tue, Aug 18, 2015 at 6:22 AM, Mark Kettenis mark.kette...@xs4all.nl
wrote:
Date: Tue, 18 Aug 2015 05:03:19 +
From: Miod Vallat m...@online.fr
I spent some time today figuting out why the binutils update broke ld
-Z on powerpc. Turns out to be a fairly thorny issue.
The
On Wed, Oct 31, 2018 at 6:58 PM Sebastian Benoit wrote:
On a phone, saw some typos and such, sorry no diff.
[benoit@border2:~]$ cat before
> RDE memory statistics
> 715727 IPv4 unicast network entries using 27.3M of memory
> 58953 IPv6 unicast network entries using 3.1M of memory
>
I often use VirtualBox (version 5.2.18 on OS X) to familiarize myself
with new features in snapshots, before upgrading my physical hardware.
This afternoon, I tried updating bsd.rd (amd64, 6.4-beta RAMDISK_CD
#281) and wasn't able to successfully boot it. I had to rely on the
video capture
On Sat, Sep 15, 2018 at 10:05 PM, Philip Guenther wrote:
> On Sat, Sep 15, 2018 at 11:59 AM David Higgs wrote:
>>
>> I often use VirtualBox (version 5.2.18 on OS X) to familiarize myself
>> with new features in snapshots, before upgrading my physical hardware.
>>
On Sun, Sep 16, 2018 at 1:15 PM, Johan Huldtgren
wrote:
> On 2018/09/16 10:52, David Higgs wrote:
>> On Sun, Sep 16, 2018 at 10:17 AM, David Higgs wrote:
>>> On Sat, Sep 15, 2018 at 10:05 PM, Philip Guenther
>>> wrote:
>>>> On Sat, Sep 15, 2018 at 11:
On Mon, Aug 31, 2020 at 2:41 AM Otto Moerbeek wrote:
> Hi,
>
> A question from Theo made me think about realloc and come up with a
> particular bad case for performance. I do not know if it happens in
> practice, but it was easy to create a test program to hit the case.
>
> We're talking
On Mon, Oct 26, 2020 at 3:18 PM Mark Kettenis
wrote:
> > Date: Sun, 25 Oct 2020 10:42:38 +0100 (CET)
> > From: Mark Kettenis
> >
> > While making radeondrm(4) work on powerpc64 I'm running into an
> > interesting unaligned access issue.
> >
> > Modern POWER CPUs generally support unaligned
On Fri, Jun 12, 2020 at 9:41 AM Theo Buehler wrote:
> I finally found the time to think about the mathematics of this some
> more and I'm now convinced that it's a sound construction. I hope that
> one or the other observation below will be useful for you.
>
> The hash as it is now can be proved
On Thu, Jul 15, 2021 at 11:20 AM Leo Unglaub wrote:
> Hey,
> this is a very clean solution to a very common problem that i have. A
> lot of tasks that i run from cron have very different completion times.
> Right now i use the -s [1] option in crontab to make sure only one task
> is running at
On Sat, Nov 26, 2022 at 1:47 AM Anton Lindqvist wrote:
> Hi,
> This diff adds supports for the following to uhidpp:
>
> 1. Bolt receivers, they use a different set of registers for querying
>paired devices.
>
> 2. The Unified Battery feature, this is a more competent feature
>function
68 matches
Mail list logo
