On 24 Apr 2015, at 3:39 pm, Theo de Raadt dera...@cvs.openbsd.org 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 fairly expensive debugging diff in the snapshots
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
On Fri 24/04/2015 16:25, David Gwynne wrote:
On 24 Apr 2015, at 3:39 pm, Theo de Raadt dera...@cvs.openbsd.org 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
FYI:
- Forwarded message from Craig Skinner skin...@britvault.co.uk -
Date: Sat, 31 Jan 2015 11:02:39 + (GMT)
From: Craig Skinner skin...@britvault.co.uk
To: b...@openbsd.org
Subject: sudo not honouring $PATH, $MAIL umask
Synopsis: sudo not honouring $PATH, $MAIL umask
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
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.
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
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 is
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
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
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
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);
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
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
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. Sorry for
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 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
Hi!
Code says 7860:
dcoppa@t420:/usr/src/usr.bin/sndiod$ grep 7860 *
sndiod.c:#define DEFAULT_BUFSZ 7860
While manpage says 7680:
dcoppa@t420:/usr/src/usr.bin/sndiod$ grep 7680 *
sndiod.1:The default is 7680 or twice the block size
Ciao,
David
Index: sndiod.1
On Fri, Apr 24, 2015 at 10:36:24AM -0600, David Coppa wrote:
Hi!
Code says 7860:
dcoppa@t420:/usr/src/usr.bin/sndiod$ grep 7860 *
sndiod.c:#define DEFAULT_BUFSZ7860
While manpage says 7680:
dcoppa@t420:/usr/src/usr.bin/sndiod$ grep 7680 *
sndiod.1:The default is 7680 or
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
24 matches
Mail list logo
