On Wed, Oct 29, 2014 at 01:24:30AM +1100, Joel Sing wrote:
> On Wed, 29 Oct 2014, Joel Sing wrote:
> >
> > A CRYPTO key disk is slightly special in that it has softraid metadata but
> > is not technically part of the same volume (well, it is in some ways but it
> > is not in others). The problem in
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
childre
hello,
a few hours after I sent the previous e-mail the backup
(April 23rd snap) took over and became the master, at
that point I could not reach the carp interfaces anymore.
Reverting roles so the host running the April 12th snap
became the master would mostly fix the problems although
occasiona
On Fri, Apr 24, 2015 at 08:53:44PM -0400, James Turner wrote:
> On Fri, Apr 24, 2015 at 08:23:01PM -0400, James Turner wrote:
> > The attached diff allows sound to work on my late 2013 Macbook Air
> > (6,1). oks?
> >
>
> Ok that diff had lots of typos, please ignore until I can send a new
> one.
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
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 repor
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);
vo
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
upd_refresh()
On Fri, Apr 24, 2015 at 08:23:01PM -0400, James Turner wrote:
> The attached diff allows sound to work on my late 2013 Macbook Air
> (6,1). oks?
>
Ok that diff had lots of typos, please ignore until I can send a new
one. Sorry for the noise.
--
James Turner
On Fri, Apr 24, 2015 at 8:43 PM, David Higgs 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 is
> constructed dep
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 dependenc
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 +166
The attached diff allows sound to work on my late 2013 Macbook Air
(6,1). oks?
--
James Turner
Index: azalia_codec.c
===
RCS file: /cvs/src/sys/dev/pci/azalia_codec.c,v
retrieving revision 1.165
diff -u -p -u -p -r1.165 azalia_codec
On Fri, Apr 24, 2015 at 10:36:24AM -0600, David Coppa wrote:
>
> Hi!
>
> Code says "7860":
>
> $ grep 7860 *
> sndiod.c:#define DEFAULT_BUFSZ7860
>
> While manpage says "7680":
>
> $ grep 7680 *
> sndiod.1:The default is 7680 or twice the block size
>
oops, the man page is right and
hello,
I noticed some carp weirdness and sthen@ thought it might be worth
bringing to light. Quick background, I run two carp nodes, one
(current master) is running the April 12th snapshot, the other is
running the April 23rd snapshot. The node running the April 23rd
snap when it's the backup no
Hi!
Code says "7860":
$ grep 7860 *
sndiod.c:#define DEFAULT_BUFSZ 7860
While manpage says "7680":
$ grep 7680 *
sndiod.1:The default is 7680 or twice the block size
Ciao,
David
Index: sndiod.1
===
RCS file: /cvs/src/usr.bin/sn
On 04/24/15 13:20, Mikhail wrote:
> Hello, when I switch numlock on thinkpad e530 I see aforesaid message on
> console log.
>
> Can someone review inlined patch?
>
it's ok for me and fixes the same "problem", ok anyone ?
Cheers
Giovanni
> For future references: is it possible to see if a kernel from snapshots
> contains
> 'non committed' code?
No.
It is rare. However the process has been a great success, so it will
be done every once in a while.
In armcap.c there is a variable (e) that is no longer used since
revision 1.5 that is gaurded by __OpenBSD__
--- armcap.c2015-04-24 09:01:28.951425244 -0400
+++ armcap.c2015-04-24 09:02:06.879426067 -0400
@@ -31,9 +31,6 @@
void
OPENSSL_cpuid_setup(void)
{
-#ifndef __OpenBSD__
-char
Hello, when I switch numlock on thinkpad e530 I see aforesaid message on
console log.
Can someone review inlined patch?
Index: sys/dev/acpi/acpithinkpad.c
===
RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v
retrieving revision 1.43
FYI:
- Forwarded message from Craig Skinner -
Date: Sat, 31 Jan 2015 11:02:39 + (GMT)
From: Craig Skinner
To: b...@openbsd.org
Subject: sudo not honouring $PATH, $MAIL & umask
>Synopsis: sudo not honouring $PATH, $MAIL & umask
>Category: user
>Environment:
System
On Fri 24/04/2015 16:25, David Gwynne wrote:
>
> > On 24 Apr 2015, at 3:39 pm, Theo de Raadt wrote:
> >
> >> After updating one of my machines to a more recent snapshot I noticed that
> >> networking speed was reduced and that the machine was 'less' responsive.
> >
> > Be aware there is a fairl
23 matches
Mail list logo
