Re: [patch] xdm doesn't clear wtmp/utmp entry after log out
Matthieu Herrb writes: > On Tue, Jan 13, 2015 at 01:38:36PM -0800, patrick keshishian wrote: [...] > Makes sense. ok matthieu@ Committed, thanks. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Use rtdeletemsg()
On 23/01/15(Fri) 19:59, Alexander Bluhm wrote: > On Mon, Jan 19, 2015 at 11:49:53AM +0100, Martin Pieuchot wrote: > > Instead of rerolling rtrequest1(RTM_DELETE...) code in various places, > > I am a fan of code unification. > > > simply use rtdeletemsg() which also notify userland that the route entry > > is going away. > > When we notify the userland about mtu discovery removal, should we > inform it about added routes from ICMP packets? I'd like to. I think we should inform userland every time we add or remove a route from the routing table. I also think we should not always inform userland when we do a route lookup. Too many rtalloc(9) calls have the RT_REPORT and RT_RESOLVE flags because of copy & paste. > May some userland daemons get confused about the new messages? I don't think so because these messages are similar to the ones generated when routes are manually created/deleted. But I'm not an expert regarding route messages processing in userland daemons.
Do not let umass(4) insult you
Some HTC phones first present a Umass descriptor when they're attached
to a machine then disconnect them self and reattach with an Imaging
(MTP) descriptor.
In between they stop answering to umass(4) which vomit some of its best
prose:
umass0: BBB reset failed, IOERROR
umass0: BBB bulk-in clear stall failed, IOERROR
umass0: BBB bulk-out clear stall failed, IOERROR
umass0: BBB reset failed, IOERROR
umass0: BBB bulk-in clear stall failed, IOERROR
umass0: BBB bulk-out clear stall failed, IOERROR
...
I don't see the point of printing such stuff in GENERIC. These messages
alone are useless, so just print them in DEBUG mode.
Ok?
Index: umass.c
===
RCS file: /home/ncvs/src/sys/dev/usb/umass.c,v
retrieving revision 1.68
diff -u -p -r1.68 umass.c
--- umass.c 18 Jan 2015 14:40:05 - 1.68
+++ umass.c 26 Jan 2015 13:09:15 -
@@ -1182,10 +1182,10 @@ umass_bbb_state(struct usbd_xfer *xfer,
* err == 0 and the following if block is passed.
*/
if (err) { /* should not occur */
- printf("%s: BBB bulk-%s stall clear failed, %s\n",
- sc->sc_dev.dv_xname,
+ DPRINTF(UDMASS_BBB, ("%s: BBB bulk-%s stall clear"
+ " failed, %s\n", sc->sc_dev.dv_xname,
(sc->transfer_dir == DIR_IN? "in":"out"),
- usbd_errstr(err));
+ usbd_errstr(err)));
umass_bbb_reset(sc, STATUS_WIRE_FAILED);
return;
}
@@ -1327,8 +1327,8 @@ umass_bbb_state(struct usbd_xfer *xfer,
/* Bulk Reset */
case TSTATE_BBB_RESET1:
if (err)
- printf("%s: BBB reset failed, %s\n",
- sc->sc_dev.dv_xname, usbd_errstr(err));
+ DPRINTF(UDMASS_BBB, ("%s: BBB reset failed, %s\n",
+ sc->sc_dev.dv_xname, usbd_errstr(err)));
sc->transfer_state = TSTATE_BBB_RESET2;
umass_clear_endpoint_stall(sc, UMASS_BULKIN,
@@ -1337,8 +1337,9 @@ umass_bbb_state(struct usbd_xfer *xfer,
return;
case TSTATE_BBB_RESET2:
if (err)/* should not occur */
- printf("%s: BBB bulk-in clear stall failed, %s\n",
- sc->sc_dev.dv_xname, usbd_errstr(err));
+ DPRINTF(UDMASS_BBB, ("%s: BBB bulk-in clear stall"
+ " failed, %s\n", sc->sc_dev.dv_xname,
+ usbd_errstr(err)));
/* no error recovery, otherwise we end up in a loop */
sc->transfer_state = TSTATE_BBB_RESET3;
@@ -1348,8 +1349,9 @@ umass_bbb_state(struct usbd_xfer *xfer,
return;
case TSTATE_BBB_RESET3:
if (err)/* should not occur */
- printf("%s: BBB bulk-out clear stall failed, %s\n",
- sc->sc_dev.dv_xname, usbd_errstr(err));
+ DPRINTF(UDMASS_BBB,("%s: BBB bulk-out clear stall"
+ " failed, %s\n", sc->sc_dev.dv_xname,
+ usbd_errstr(err)));
/* no error recovery, otherwise we end up in a loop */
sc->transfer_state = TSTATE_IDLE;
Re: elantech-v4 clickpad support
On 25/01/15(Sun) 20:07, Alexandr Shadchin wrote: > On Wed, Jan 14, 2015 at 12:23:13AM +0100, Ulf Brosziewski wrote: > [...] > Sorry for the long answer. > > I tested xenocara part on x201(synaptics touchpad) and x220(synaptics > clickpad), > this works, no regress, even works click-and-drag :) > > I have no other touchpads (ALPS, Elantech) and I can not test patch on them. > > Has anyone else tried this diff? My laptop with an ALPS touchpad is dead so I can no longer test it. But since all touchpad implementations supposedly match what the Synaptics driver is doing, it should be safe. That said, it would be nice to make sure we're not breaking any touchpad at this point of the release. If we don't have more test reports, I'd wait for the next release cycle before committing this. M.
Re: PATCH: NAT on IPSec
On Thu, Jan 15, 2015 at 04:00:20PM +0100, Vincent Gross wrote:
> Hello folks,
>
> This patch brings nat capabilites into iked, the same way that mpf@ did
> with isakmpd about 6 years ago.
>
> Comments ?
bumpity bump bump.
Any comments on this ?
>
> Tested with the following setup, with icmp, udp and tcp:
>
> >> Local pf.conf:
> table { 172.23.0.0/23 }
>
> set skip on lo
>
> match out on enc0 from ! to nat-to 172.23.50.1
>
> block return
> pass
> block return in on ! lo0 proto tcp to port 6000:6010
>
> >> Local iked.conf:
> ikev2 active esp \
> from 172.23.50.1 (0.0.0.0/0) to 172.23.0.0/23 peer 79.143.250.153 \
> srcid 'spinoza.kilob.yt' dstid 'brouwer.kilob.yt'
>
> >> Local ip address:
> ppp0: flags=8051 mtu 1500
> priority: 0
> groups: ppp egress
> inet 100.97.217.112 --> 10.64.64.64 netmask 0xff00
>
> >> Remote pf.conf:
> [...]
> pass on enc0
> [...]
>
> >> Remote iked.conf:
> ikev2 esp \
> from 172.23.0.0/23 to 172.23.50.1 peer any \
> srcid 'brouwer.kilob.yt' dstid 'spinoza.kilob.yt'
>
>
>
>
> Index: iked.h
> ===
> RCS file: /cvs/src/sbin/iked/iked.h,v
> retrieving revision 1.82
> diff -u -p -r1.82 iked.h
> --- iked.h18 Aug 2014 09:43:02 - 1.82
> +++ iked.h15 Jan 2015 13:54:46 -
> @@ -139,6 +139,8 @@ struct iked_flow {
> struct iked_addr flow_src;
> struct iked_addr flow_dst;
> u_intflow_dir; /* in/out */
> + struct iked_addr flow_prenat; /* pre-nat source */
> + u_intflow_usenat;
>
> u_intflow_loaded; /* pfkey done */
>
> Index: parse.y
> ===
> RCS file: /cvs/src/sbin/iked/parse.y,v
> retrieving revision 1.43
> diff -u -p -r1.43 parse.y
> --- parse.y 12 Jan 2015 11:24:58 - 1.43
> +++ parse.y 15 Jan 2015 13:54:47 -
> @@ -2401,7 +2401,7 @@ create_ike(char *name, int af, u_int8_t
> {
> char idstr[IKED_ID_SIZE];
> u_intidtype = IKEV2_ID_NONE;
> - struct ipsec_addr_wrap *ipa, *ipb;
> + struct ipsec_addr_wrap *ipa, *ipb, *ipn;
> struct iked_policy pol;
> struct iked_proposal prop[2];
> u_intj;
> @@ -2622,6 +2622,16 @@ create_ike(char *name, int af, u_int8_t
> flows[j].flow_dst.addr_mask = ipb->mask;
> flows[j].flow_dst.addr_net = ipb->netaddress;
> flows[j].flow_dst.addr_port = hosts->dport;
> +
> + ipn = ipa->srcnat;
> + if (ipn) {
> + memcpy(&flows[j].flow_prenat.addr, &ipn->address,
> + sizeof(ipn->address));
> + flows[j].flow_prenat.addr_af = ipn->af;
> + flows[j].flow_prenat.addr_mask = ipn->mask;
> + flows[j].flow_prenat.addr_net = ipn->netaddress;
> + flows[j].flow_usenat = 1;
> + }
>
> flows[j].flow_ipproto = ipproto;
>
> Index: pfkey.c
> ===
> RCS file: /cvs/src/sbin/iked/pfkey.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 pfkey.c
> --- pfkey.c 29 Oct 2014 06:26:39 - 1.40
> +++ pfkey.c 15 Jan 2015 13:54:47 -
> @@ -180,6 +180,7 @@ int
> pfkey_flow(int sd, u_int8_t satype, u_int8_t action, struct iked_flow *flow)
> {
> struct sadb_msg smsg;
> + struct iked_addr*flow_src, *flow_dst;
> struct sadb_address sa_src, sa_dst, sa_local, sa_peer, sa_smask,
>sa_dmask;
> struct sadb_protocol sa_flowtype, sa_protocol;
> @@ -192,58 +193,76 @@ pfkey_flow(int sd, u_int8_t satype, u_in
> sport = dport = 0;
> sa_srcid = sa_dstid = NULL;
>
> + flow_src = &flow->flow_src;
> + flow_dst = &flow->flow_dst;
> +
> + if (flow->flow_usenat)
> + switch (flow->flow_type) {
> + case SADB_X_FLOW_TYPE_USE:
> + flow_dst = &flow->flow_prenat;
> + break;
> + case SADB_X_FLOW_TYPE_REQUIRE:
> + flow_src = &flow->flow_prenat;
> + break;
> + case 0:
> + if (flow->flow_dir == IPSP_DIRECTION_IN)
> + flow_dst = &flow->flow_prenat;
> + else
> + flow_src = &flow->flow_prenat;
> + }
> +
> bzero(&ssrc, sizeof(ssrc));
> bzero(&smask, sizeof(smask));
> - memcpy(&ssrc, &flow->flow_src.addr, sizeof(ssrc));
> - memcpy(&smask, &flow->flow_src.addr, sizeof(smask));
> - if ((sport = flow->flow_src.addr_port) != 0)
> + memcpy(&ssrc, &flow_src->addr, sizeof(ssrc));
> + mem
ntpd: adjtime variations between OSes
Hi,
Paul and I have been doing some testing of OpenNTPD on various OSes,
and found some interesting deviations. Paul noted that running the
latest OpenNTPD-portable on OmniOS (Solaris derivative) that it would
cycle back and forth between 'clock is now synced' and 'clock is now
unsynced'. So, we put together a short test program to test behavior
of adjtime:
#include
#include
#include
#include
#include
#include
int main(int argc, char *argv[])
{
struct timeval a, b, c = { 0 };
a.tv_sec = 0;
a.tv_usec = 50;
if (argc > 1)
a.tv_usec = atoi(argv[1]);
printf("setting adjtime to %lu usec\n", (long)a.tv_usec);
if (adjtime(&a, &b) == -1) {
perror("adjtime");
return 1;
}
do {
sleep(1);
// try putting &c for Solaris in the first arg
if (adjtime(NULL, &b) == -1) {
perror("adjtime");
return 1;
}
printf("%ld usec left\n", b.tv_usec);
} while (b.tv_usec != 0);
return 0;
}
OpenBSD appears to adjust by 5000 usec/sec.
Linux appears to adjust by 500 usec/sec.
Solaris adjust by...well, who knows what amount. But, it is
inconsistent in its ability to eventually hit '0', especially if the
clock frequency adjustment for 'adjfreq/ntpd_adjtime' was ever set to
anything other than '0'. It also doesn't allow specifying a NULL first
argument to adjtime, so a run looks something like this:
setting adjtime to 50 usec
437963 usec left
375299 usec left
312634 usec left
249343 usec left
186679 usec left
124015 usec left
-339216 usec left
-272516 usec left
-205817 usec left
-139740 usec left
-73041 usec left
-6341 usec left
-3 usec left
-3 usec left
-3 usec left
In a number of machines, it never hits '0' at all, simply gets kind of
close. I was wondering if it made sense to either:
1. add some sort of fudge factor to the clock 'synced' state when
the olddelta simply stabilizes (not sure if there's a good technique
here)?
2. quiet the debug logging for synced/unsynced
3. document as a Solaris bug and move on?
I got the same behavior after running ntp.org's ntpd and openntpd (and
stopping them) and having adjfreq pre-set, so I don't think its a case
of us programming adjfreq/ntp_adjtime incorrectly. It seems this
behavior first showed up since OpenNTPD-portable now calls adjfreq. It
is also possible that if we never call adjfreq that Solaris does
eventually adjust the time all the way. We've tested on a variety of
Solaris 10 / 11 and x86 and Sparc hardware.
- Brent
machine with a zzz problem with lidsuspend=1
This machine (server-ish hw used as a desktop) used to suspend and resume nicely, but following the lidsuspend change no longer resumes (machine powers up, screen stays black). It works correctly if machdep.lidsuspend is set to 0. I can run like that without a problem but it would be nicer to fix it, does anyone have ideas where to poke? Note: it has a LID0 device (unsure what it's connected to; there is a chassis intrusion switch but operating that doesn't change the state of acpibtn1.indicator0). It does not have a _LID method in the dsdt. hw.sensors.cpu0.temp0=22.00 degC hw.sensors.cpu1.temp0=22.00 degC hw.sensors.acpitz0.temp0=27.80 degC (zone temperature) hw.sensors.acpitz1.temp0=29.80 degC (zone temperature) hw.sensors.acpibtn1.indicator0=On (lid open) hw.sensors.sdtemp0.temp0=20.50 degC hw.sensors.sdtemp1.temp0=21.00 degC OpenBSD 5.7-beta (GENERIC.MP) #814: Thu Jan 22 15:39:30 MST 2015 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8477315072 (8084MB) avail mem = 8247771136 (7865MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec400 (90 entries) bios0: vendor Dell Inc. version "A04" date 07/20/2014 bios0: Dell Inc. PowerEdge T20 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT ASF! acpi0: wakeup devices PS2K(S3) PS2M(S3) UAR1(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Pentium(R) CPU G3220 @ 3.00GHz, 2993.50 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,XSAVE,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,ERMS,INVPCID cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.0, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Pentium(R) CPU G3220 @ 3.00GHz, 2993.07 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,XSAVE,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,ERMS,INVPCID cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus -1 (PEG0) acpiprt4 at acpi0: bus -1 (PEG1) acpiprt5 at acpi0: bus -1 (PEG2) acpiec0 at acpi0: not present acpicpu0 at acpi0: C1, PSS acpicpu1 at acpi0: C1, PSS acpitz0 at acpi0: critical temperature is 105 degC acpitz1 at acpi0: critical temperature is 105 degC acpibat0 at acpi0: BAT0 not present acpibat1 at acpi0: BAT1 not present acpibat2 at acpi0: BAT2 not present acpibtn0 at acpi0: PWRB acpibtn1 at acpi0: LID0 acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 2993 MHz: speeds: 3000, 2900, 2700, 2600, 2400, 2300, 2100, 2000, 1800, 1700, 1500, 1400, 1200, 1100, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 4G Host" rev 0x06 vga1 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x06 intagp at vga1 not configured inteldrm0 at vga1 drm0 at inteldrm0 drm: Memory usable by graphics device = 2048M error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 10 inteldrm0: 1280x1024 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) xhci0 at pci0 dev 20 function 0 "Intel 8 Series xHCI" rev 0x04: msi usb0 at xhci0: USB revision 3.0 uhub0 at usb0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel 8 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 "Intel I217-LM" rev 0x04: msi, address f8:b1:56:b0:df:e7 ehci0 at pci0 dev 26 function 0 "Intel 8 Series USB" rev 0x04: apic 8 int 16 usb1 at ehci0: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x04: msi azalia0: codecs: Realtek/0x0280 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 8 Series PCIE" rev 0xd4 pci1 at ppb0 bus 1 ppb1 at pci0 dev 28 function 1 "Intel 8 Series PCIE" rev 0xd4: msi pci2 at ppb1 bus 2 ppb2 at pci2 dev 0 function 0 "TI XIO2001 PCIE-PCI" rev 0x00 pci3 at ppb2 bus 3 ehci1 at pci0 dev 29 function 0 "Inte
Re: machine with a zzz problem with lidsuspend=1
> Date: Mon, 26 Jan 2015 21:17:33 + > From: Stuart Henderson > > This machine (server-ish hw used as a desktop) used to suspend and > resume nicely, but following the lidsuspend change no longer resumes > (machine powers up, screen stays black). > > It works correctly if machdep.lidsuspend is set to 0. I can run like > that without a problem but it would be nicer to fix it, does anyone have > ideas where to poke? > > Note: it has a LID0 device (unsure what it's connected to; there is a > chassis intrusion switch but operating that doesn't change the state > of acpibtn1.indicator0). It does not have a _LID method in the dsdt. Really Stuart, you looked at the cpidump output, but didn't include it in your report?
Re: machine with a zzz problem with lidsuspend=1
On 2015/01/26 23:18, Mark Kettenis wrote: > > Date: Mon, 26 Jan 2015 21:17:33 + > > From: Stuart Henderson > > > > This machine (server-ish hw used as a desktop) used to suspend and > > resume nicely, but following the lidsuspend change no longer resumes > > (machine powers up, screen stays black). > > > > It works correctly if machdep.lidsuspend is set to 0. I can run like > > that without a problem but it would be nicer to fix it, does anyone have > > ideas where to poke? > > > > Note: it has a LID0 device (unsure what it's connected to; there is a > > chassis intrusion switch but operating that doesn't change the state > > of acpibtn1.indicator0). It does not have a _LID method in the dsdt. > > Really Stuart, you looked at the cpidump output, but didn't include it > in your report? It's a bit long to in-line in a list mail. I've put the disassembled versions and a tar of the acpidump output files at http://junkpile.org/t20/ e.g. http://junkpile.org/t20/t20.DSDT.dsl http://junkpile.org/t20/t20.tgz
Re: machine with a zzz problem with lidsuspend=1
> Date: Mon, 26 Jan 2015 22:30:02 +
> From: Stuart Henderson
>
> On 2015/01/26 23:18, Mark Kettenis wrote:
> > > Date: Mon, 26 Jan 2015 21:17:33 +
> > > From: Stuart Henderson
> > >
> > > This machine (server-ish hw used as a desktop) used to suspend and
> > > resume nicely, but following the lidsuspend change no longer resumes
> > > (machine powers up, screen stays black).
> > >
> > > It works correctly if machdep.lidsuspend is set to 0. I can run like
> > > that without a problem but it would be nicer to fix it, does anyone have
> > > ideas where to poke?
> > >
> > > Note: it has a LID0 device (unsure what it's connected to; there is a
> > > chassis intrusion switch but operating that doesn't change the state
> > > of acpibtn1.indicator0). It does not have a _LID method in the dsdt.
Can you try the diff below?
Index: acpibtn.c
===
RCS file: /home/cvs/src/sys/dev/acpi/acpibtn.c,v
retrieving revision 1.40
diff -u -p -r1.40 acpibtn.c
--- acpibtn.c 24 Nov 2014 03:54:06 - 1.40
+++ acpibtn.c 26 Jan 2015 23:09:53 -
@@ -55,7 +55,6 @@ struct acpibtn_softc {
#define ACPIBTN_SLEEP 3
};
-intacpibtn_getsta(struct acpibtn_softc *);
intacpibtn_setpsw(struct acpibtn_softc *, int);
struct acpi_lid {
@@ -157,10 +156,19 @@ acpibtn_attach(struct device *parent, st
struct acpi_attach_args *aa = aux;
struct acpi_lid *lid;
int64_t lid_open;
+ int64_t st;
sc->sc_acpi = (struct acpi_softc *)parent;
sc->sc_devnode = aa->aaa_node;
+ printf(": %s\n", sc->sc_devnode->name);
+
+ if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL, &st))
+ st = STA_PRESENT | STA_ENABLED | STA_DEV_OK;
+ if ((st & (STA_PRESENT | STA_ENABLED | STA_DEV_OK)) !=
+ (STA_PRESENT | STA_ENABLED | STA_DEV_OK))
+ return;
+
if (!strcmp(aa->aaa_dev, ACPI_DEV_LD)) {
sc->sc_btn_type = ACPIBTN_LID;
@@ -174,10 +182,6 @@ acpibtn_attach(struct device *parent, st
else if (!strcmp(aa->aaa_dev, ACPI_DEV_SBD))
sc->sc_btn_type = ACPIBTN_SLEEP;
- acpibtn_getsta(sc);
-
- printf(": %s\n", sc->sc_devnode->name);
-
if (sc->sc_btn_type == ACPIBTN_LID) {
strlcpy(sc->sc_sensdev.xname, DEVNAME(sc),
sizeof(sc->sc_sensdev.xname));
@@ -194,17 +198,6 @@ acpibtn_attach(struct device *parent, st
aml_register_notify(sc->sc_devnode, aa->aaa_dev, acpibtn_notify,
sc, ACPIDEV_NOPOLL);
-}
-
-int
-acpibtn_getsta(struct acpibtn_softc *sc)
-{
- if (aml_evalname(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL, NULL) !=
0) {
- dnprintf(20, "%s: no _STA\n", DEVNAME(sc));
- /* XXX not all buttons have _STA so FALLTROUGH */
- }
-
- return (0);
}
int
Re: machine with a zzz problem with lidsuspend=1
On Tue, Jan 27, 2015 at 12:11:35AM +0100, Mark Kettenis wrote:
> > Date: Mon, 26 Jan 2015 22:30:02 +
> > From: Stuart Henderson
> >
> > On 2015/01/26 23:18, Mark Kettenis wrote:
> > > > Date: Mon, 26 Jan 2015 21:17:33 +
> > > > From: Stuart Henderson
> > > >
> > > > This machine (server-ish hw used as a desktop) used to suspend and
> > > > resume nicely, but following the lidsuspend change no longer resumes
> > > > (machine powers up, screen stays black).
> > > >
> > > > It works correctly if machdep.lidsuspend is set to 0. I can run like
> > > > that without a problem but it would be nicer to fix it, does anyone have
> > > > ideas where to poke?
> > > >
> > > > Note: it has a LID0 device (unsure what it's connected to; there is a
> > > > chassis intrusion switch but operating that doesn't change the state
> > > > of acpibtn1.indicator0). It does not have a _LID method in the dsdt.
>
> Can you try the diff below?
If this works, ok mlarkin@. It matches some other fixes that went in
previously.
-ml
>
> Index: acpibtn.c
> ===
> RCS file: /home/cvs/src/sys/dev/acpi/acpibtn.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 acpibtn.c
> --- acpibtn.c 24 Nov 2014 03:54:06 - 1.40
> +++ acpibtn.c 26 Jan 2015 23:09:53 -
> @@ -55,7 +55,6 @@ struct acpibtn_softc {
> #define ACPIBTN_SLEEP3
> };
>
> -int acpibtn_getsta(struct acpibtn_softc *);
> int acpibtn_setpsw(struct acpibtn_softc *, int);
>
> struct acpi_lid {
> @@ -157,10 +156,19 @@ acpibtn_attach(struct device *parent, st
> struct acpi_attach_args *aa = aux;
> struct acpi_lid *lid;
> int64_t lid_open;
> + int64_t st;
>
> sc->sc_acpi = (struct acpi_softc *)parent;
> sc->sc_devnode = aa->aaa_node;
>
> + printf(": %s\n", sc->sc_devnode->name);
> +
> + if (aml_evalinteger(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL, &st))
> + st = STA_PRESENT | STA_ENABLED | STA_DEV_OK;
> + if ((st & (STA_PRESENT | STA_ENABLED | STA_DEV_OK)) !=
> + (STA_PRESENT | STA_ENABLED | STA_DEV_OK))
> + return;
> +
> if (!strcmp(aa->aaa_dev, ACPI_DEV_LD)) {
> sc->sc_btn_type = ACPIBTN_LID;
>
> @@ -174,10 +182,6 @@ acpibtn_attach(struct device *parent, st
> else if (!strcmp(aa->aaa_dev, ACPI_DEV_SBD))
> sc->sc_btn_type = ACPIBTN_SLEEP;
>
> - acpibtn_getsta(sc);
> -
> - printf(": %s\n", sc->sc_devnode->name);
> -
> if (sc->sc_btn_type == ACPIBTN_LID) {
> strlcpy(sc->sc_sensdev.xname, DEVNAME(sc),
> sizeof(sc->sc_sensdev.xname));
> @@ -194,17 +198,6 @@ acpibtn_attach(struct device *parent, st
>
> aml_register_notify(sc->sc_devnode, aa->aaa_dev, acpibtn_notify,
> sc, ACPIDEV_NOPOLL);
> -}
> -
> -int
> -acpibtn_getsta(struct acpibtn_softc *sc)
> -{
> - if (aml_evalname(sc->sc_acpi, sc->sc_devnode, "_STA", 0, NULL, NULL) !=
> 0) {
> - dnprintf(20, "%s: no _STA\n", DEVNAME(sc));
> - /* XXX not all buttons have _STA so FALLTROUGH */
> - }
> -
> - return (0);
> }
>
> int
>
Following Current / Flag Day
We narrowed the definition of what a static pie binary is in the kernel. This change is a flag day where newer kernels will not recognize older pie binaries making upgrading via source hard. If you are running an older version of -current, upgrade via snapshots prior to building a new kernel from source to get over this flag day. -Kurt
Re: elantech-v4 clickpad support
On 01/25/2015 04:07 PM, Alexandr Shadchin wrote:
On Wed, Jan 14, 2015 at 12:23:13AM +0100, Ulf Brosziewski wrote:
Currently pms and the wsconscomm module of the synaptics driver offer a
somewhat limited support for Elantech clickpads with hardware version 4.
Above all, I missed the options of performing click-and-drag operations
with two fingers and of using a "soft button area" for the emulation of
right button clicks (tap-and-drag and two-finger tapping are no
alternatives for me, usually I don't enable tapping).
I have written two patches that provide these options (I'm using them
[...]
Sorry for the long answer.
I tested xenocara part on x201(synaptics touchpad) and x220(synaptics clickpad),
this works, no regress, even works click-and-drag :)
I have no other touchpads (ALPS, Elantech) and I can not test patch on them.
Has anyone else tried this diff?
[...]
Thanks for the feedback. Meanwhile, I have tested the patch to the
synaptics driver with an ALPS touchpad ("ALPS Glidepoint, version 0x7321").
As expected, it seems that the patch doesn't affect the driver's behaviour
as long as clickpad support is disabled. However, when I enabled that
support for testing purposes - there is no other reason to do that because
the touchpad has two external buttons -, it showed inconsistencies. Making
two successive touches while the left button is being pressed may produce
cursor jumps. I haven't had the time to look at synaptics.c again, but I
could check what a recent Linux version of the driver does with that
touchpad: When the clickpad option is enabled, left clicks make the X
cursor freeze. Perhaps the clickpad code of the driver wasn't meant to
work seamlessly with all touchpads, and if this is the case, then the
wsconscomm patch is too simplistic in this form. At least I think it
shouldn't unmask such defects, even where the clickpad support makes no
sense. I'm sorry that I had to draw these negative conclusions now. It is
not clear to me whether these things could be fixed with reasonable means.
Re: Following Current / Flag Day
On 01/26/15 19:34, Kurt Miller wrote: We narrowed the definition of what a static pie binary is in the kernel. This change is a flag day where newer kernels will not recognize older pie binaries making upgrading via source hard. If you are running an older version of -current, upgrade via snapshots prior to building a new kernel from source to get over this flag day. -Kurt Is the below the change that is the flag day? Or, when is the FD? Modified files: sys/kern : exec_elf.c Log message: Require EFT shared objects have a PT_PHDR entry to be considered a pie binary. The kernel will now reject executing a typical shared library with EINVAL. This breaks compatibility with initial static pie binaries and requires a recent user-land prior to upgrading. In addition, more fine grained errors can be returned from execve(2) when errors occur while attempting to execute ELF objects. okay guenther@, kettenis@, deraadt@ --STeve Andre'
Re: Following Current / Flag Day
>On 01/26/15 19:34, Kurt Miller wrote: >> We narrowed the definition of what a static pie binary is in the kernel. >> This change is a flag day where newer kernels will not recognize older >> pie binaries making upgrading via source hard. If you are running an >> older version of -current, upgrade via snapshots prior to building a new >> kernel from source to get over this flag day. >> >> -Kurt >> >> >Is the below the change that is the flag day? Or, when is the FD? > >Modified files: > sys/kern : exec_elf.c > >Log message: >Require EFT shared objects have a PT_PHDR entry to be considered >a pie binary. The kernel will now reject executing a typical shared >library with EINVAL. This breaks compatibility with initial static pie >binaries and requires a recent user-land prior to upgrading. In >addition, more fine grained errors can be returned from execve(2) >when errors occur while attempting to execute ELF objects. > >okay guenther@, kettenis@, deraadt@ Look, you'll be fine. There is approximately a 3-4 day window about a 4 weeks or a month back, depending on architecture. Use snapshots, if in doubt.
Re: Following Current / Flag Day
On 01/27/15 00:16, Theo de Raadt wrote: On 01/26/15 19:34, Kurt Miller wrote: We narrowed the definition of what a static pie binary is in the kernel. This change is a flag day where newer kernels will not recognize older pie binaries making upgrading via source hard. If you are running an older version of -current, upgrade via snapshots prior to building a new kernel from source to get over this flag day. -Kurt Is the below the change that is the flag day? Or, when is the FD? Modified files: sys/kern : exec_elf.c Log message: Require EFT shared objects have a PT_PHDR entry to be considered a pie binary. The kernel will now reject executing a typical shared library with EINVAL. This breaks compatibility with initial static pie binaries and requires a recent user-land prior to upgrading. In addition, more fine grained errors can be returned from execve(2) when errors occur while attempting to execute ELF objects. okay guenther@, kettenis@, deraadt@ Look, you'll be fine. There is approximately a 3-4 day window about a 4 weeks or a month back, depending on architecture. Use snapshots, if in doubt. OK, already did that. The tense of the message is what made me question this. Thanks. --STeve Andre'
patch: hide processes non owned by a user
Hello,
I wrote a patch which adds a new kernel sysctl (hideproc) to hide
processes non owned by a user, except for root. This should be mostly
useful on shell servers and on servers with chroots.
I know some controversial patches have been presented in the past, but
this one only does only one thing and should have a small enough impact.
While writing it, I was using a snapshot of about 1 week old, and the
patch didn't work for a reason I have not found. But it works fine on
5.6 (that's why this one applies to 5.6). So there might be or have been
a regression somewhere.
diff -aur oldsys/kern/kern_sysctl.c sys/kern/kern_sysctl.c
--- oldsys/kern/kern_sysctl.c Tue Jul 22 19:13:26 2014
+++ sys/kern/kern_sysctl.c Tue Jan 27 08:32:31 2015
@@ -38,7 +38,6 @@
/*
* sysctl system call.
*/
-
#include
#include
#include
@@ -246,6 +245,7 @@
char domainname[MAXHOSTNAMELEN];
int domainnamelen;
long hostid;
+int hideproc;
char *disknames = NULL;
struct diskstats *diskstats = NULL;
#ifdef INSECURE
@@ -597,6 +597,8 @@
return sysctl_rdstruct(oldp, oldlenp, newp, &dev,
sizeof(dev));
case KERN_NETLIVELOCKS:
return (sysctl_rdint(oldp, oldlenp, newp, net_livelocks));
+ case KERN_HIDEPROC:
+ return(sysctl_int(oldp, oldlenp, newp, newlen, &hideproc));
case KERN_POOL_DEBUG: {
int old_pool_debug = pool_debug;
@@ -1376,6 +1378,17 @@
* Skip embryonic processes.
*/
if (pr->ps_flags & PS_EMBRYO)
+ continue;
+
+ /*
+ * Only show user owned processes if hideproc flag is set
+ * or the last exec gave us setuid/setgid privs
+ * (unless you're root).
+ */
+
+ if ( hideproc > 0 && (pr != curproc->p_p &&
+ (pr->ps_ucred->cr_ruid !=
curproc->p_ucred->cr_ruid ||
+ (pr->ps_flags & PS_SUGID)) && suser(curproc, 0)
!= 0))
continue;
/*
--- oldsys/sys/sysctl.h Sun Jul 13 18:41:22 2014
+++ sys/sys/sysctl.hTue Jan 27 08:38:31 2015
@@ -180,7 +180,8 @@
#defineKERN_POOL_DEBUG 77 /* int: enable
pool_debug */
#defineKERN_PROC_CWD 78 /* node: proc cwd */
#defineKERN_PROC_NOBROADCASTKILL 79/* node: proc no
broadcast kill */
-#defineKERN_MAXID 80 /* number of valid kern
ids */
+#define KERN_HIDEPROC 80 /* int: system hide other procs */
+#defineKERN_MAXID 81 /* number of valid kern
ids */
#defineCTL_KERN_NAMES { \
{ 0, 0 }, \
@@ -263,6 +264,7 @@
{ "pool_debug", CTLTYPE_INT }, \
{ "proc_cwd", CTLTYPE_NODE }, \
{ "proc_nobroadcastkill", CTLTYPE_NODE }, \
+ { "hideproc", CTLTYPE_INT }, \
}
/*
smime.p7s
Description: S/MIME Cryptographic Signature
