Re: multitouch support in wsmouse 1/3
On 13/03/16(Sun) 18:37, Ulf Brosziewski wrote: > The diffs below are a rewrite of the input-processing part of wsmouse. It > adds support for multitouch input. > > I have split the set of diffs into three parts and I will post part 2 and 3 > in separate messages. Part 1 below contains all patches for wscons, part 2 > is for the hardware drivers, part 3 is a patch for the synaptics driver in > xenocara (compiling that driver will require the modified version of > wsconsio.h in /usr/include/dev/wscons). I'm really afraid because this is just a single diff split in 3, they are not independent. Plus since your original mails included a broken diff I doubt anybody tried it. That said you've done some great work and I like it a lot. Could you prepare a diff with all the new stuff that does do change anything in the existing code? This could go in directly. Which hardware still need to be tested?
arm: remove xscale 80200
Hi,
armish and zaurus use the XSCALE 80321 and PXA2X0.
80200 is unused and basically dead code, too, so I think we should
remove that, too. This diff is based on the SA1 and IXP425 diffs.
Patrick
diff --git sys/arch/arm/arm/cpu.c sys/arch/arm/arm/cpu.c
index 5c7e385..edb47cd 100644
--- sys/arch/arm/arm/cpu.c
+++ sys/arch/arm/arm/cpu.c
@@ -99,13 +99,6 @@ static const char * const generic_steppings[16] = {
"rev 12", "rev 13", "rev 14", "rev 15"
};
-static const char * const xscale_steppings[16] = {
- "step A-0", "step A-1", "step B-0", "step C-0",
- "step D-0", "rev 5","rev 6","rev 7",
- "rev 8","rev 9","rev 10", "rev 11",
- "rev 12", "rev 13", "rev 14", "rev 15"
-};
-
static const char * const i80321_steppings[16] = {
"step A-0", "step B-0", "rev 2","rev 3",
"rev 4","rev 5","rev 6","rev 7",
@@ -168,9 +161,6 @@ const struct cpuidtab cpuids[] = {
{ CPU_ID_ARM1022ES, CPU_CLASS_ARM10E, "ARM1022E-S",
generic_steppings },
- { CPU_ID_80200, CPU_CLASS_XSCALE, "i80200",
- xscale_steppings },
-
{ CPU_ID_80321_400, CPU_CLASS_XSCALE, "i80321 400MHz",
i80321_steppings },
{ CPU_ID_80321_600, CPU_CLASS_XSCALE, "i80321 600MHz",
@@ -400,8 +390,7 @@ identify_arm_cpu(struct device *dv, struct cpu_info *ci)
case CPU_CLASS_ARMv7:
#endif
-#if defined(CPU_XSCALE_80200) || defined(CPU_XSCALE_80321) || \
-defined(CPU_XSCALE_PXA2X0)
+#if defined(CPU_XSCALE_80321) || defined(CPU_XSCALE_PXA2X0)
case CPU_CLASS_XSCALE:
#endif
break;
diff --git sys/arch/arm/arm/cpufunc.c sys/arch/arm/arm/cpufunc.c
index 178bec9..705eb84 100644
--- sys/arch/arm/arm/cpufunc.c
+++ sys/arch/arm/arm/cpufunc.c
@@ -56,17 +56,12 @@
#include
#include
-#ifdef CPU_XSCALE_80200
-#include
-#include
-#endif
-
#ifdef CPU_XSCALE_80321
#include
#include
#endif
-#if defined(CPU_XSCALE_80200) || defined(CPU_XSCALE_80321)
+#if defined(CPU_XSCALE_80321)
#include
#endif
@@ -322,8 +317,7 @@ struct cpu_functions armv7_cpufuncs = {
};
#endif /* CPU_ARMv7 */
-#if defined(CPU_XSCALE_80200) || defined(CPU_XSCALE_80321) || \
-defined(CPU_XSCALE_PXA2X0)
+#if defined(CPU_XSCALE_80321) || defined(CPU_XSCALE_PXA2X0)
struct cpu_functions xscale_cpufuncs = {
/* CPU functions */
@@ -379,7 +373,7 @@ struct cpu_functions xscale_cpufuncs = {
xscale_setup/* cpu setup*/
};
#endif
-/* CPU_XSCALE_80200 || CPU_XSCALE_80321 || CPU_XSCALE_PXA2X0 */
+/* CPU_XSCALE_80321 || CPU_XSCALE_PXA2X0 */
/*
* Global constants also used by locore.s
@@ -390,8 +384,7 @@ u_int cputype;
u_int cpu_reset_needs_v4_MMU_disable; /* flag used in locore.s */
#if defined(CPU_ARM9E) || defined(CPU_ARM10) || defined(CPU_ARM11) || \
-defined(CPU_XSCALE_80200) || defined(CPU_XSCALE_80321) || \
-defined(CPU_XSCALE_PXA2X0)
+defined(CPU_XSCALE_80321) || defined(CPU_XSCALE_PXA2X0)
static void get_cachetype_cp15 (void);
/* Additional cache information local to this file. Log2 of some of the
@@ -708,65 +701,6 @@ set_cpufuncs()
return 0;
}
#endif /* CPU_ARMv7 */
-#ifdef CPU_XSCALE_80200
- if (cputype == CPU_ID_80200) {
- int rev = cpufunc_id() & CPU_ID_REVISION_MASK;
-
- i80200_icu_init();
-
-#ifdef PERFCTRS
- /*
-* Reset the Performance Monitoring Unit to a
-* pristine state:
-* - CCNT, PMN0, PMN1 reset to 0
-* - overflow indications cleared
-* - all counters disabled
-*/
- __asm volatile("mcr p14, 0, %0, c0, c0, 0"
- :
- : "r" (PMNC_P|PMNC_C|PMNC_PMN0_IF|PMNC_PMN1_IF|
- PMNC_CC_IF));
-#endif /* PERFCTRS */
-
-#if defined(XSCALE_CCLKCFG)
- /*
-* Crank CCLKCFG to maximum legal value.
-*/
- __asm volatile ("mcr p14, 0, %0, c6, c0, 0"
- :
- : "r" (XSCALE_CCLKCFG));
-#endif
-
- /*
-* XXX Disable ECC in the Bus Controller Unit; we
-* don't really support it, yet. Clear any pending
-* error indications.
-*/
- __asm volatile("mcr p13, 0, %0, c0, c1, 0"
- :
- : "r" (BCUCTL_E0|BCUCTL_E1|BCUCTL_EV));
-
- cpufuncs = xscale_cpufuncs;
-#if defined(PERFCTRS)
- xscale_pmu_init();
-#endif
-
- /*
-* i80200 errata: Step-A0 and A1 have a bug where
-* D$ dirty bits are not cleared on "invalidate by
-* address".
-*
-
Re: Remove build machinery for non-UTF-8 charsets
On Thursday, March 17, 2016, Jeremie Courreges-Anglas wrote: > > What's the plan regarding this? libc and locale(1) don't use > LOCALE_CHARSETS anymore, we only support UTF-8 and I doubt that we'll > change our mind about that. > > The diff below removes support for non-UTF-8 LC_CTYPE files. It > survived make release. > > Thoughts? > I think I had a diff like this at some point, but we were still on the > decision of killing the other encodings. That boat has launched, so let's > do it. > Philip Guenther
Re: arm: remove sa1/ixp12x0
On Fri, Mar 18, 2016 at 04:43:08PM +0100, Patrick Wildt wrote:
> Hi,
>
> next up on the list is the StrongARM and IXP12x0.
>
> This diff removes most, but keeps the SA1100 headers,
> which are still used by zaurus.
>
> Patrick
Here is the diff I had:
The only difference seems to be you've gone with
#elif ARM_MMU_GENERIC == 1
and I kept the != 0
#elif (ARM_MMU_GENERIC) != 0
Index: arm/bus_space_asm_generic.S
===
RCS file: /cvs/src/sys/arch/arm/arm/bus_space_asm_generic.S,v
retrieving revision 1.2
diff -u -p -r1.2 bus_space_asm_generic.S
--- arm/bus_space_asm_generic.S 8 May 2009 02:57:31 - 1.2
+++ arm/bus_space_asm_generic.S 18 Mar 2016 22:17:19 -
@@ -50,7 +50,7 @@ ENTRY(generic_bs_r_1)
ldrbr0, [r1, r2]
mov pc, lr
-#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
+#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
ENTRY(generic_armv4_bs_r_2)
ldrhr0, [r1, r2]
mov pc, lr
@@ -68,7 +68,7 @@ ENTRY(generic_bs_w_1)
strbr3, [r1, r2]
mov pc, lr
-#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
+#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
ENTRY(generic_armv4_bs_w_2)
strhr3, [r1, r2]
mov pc, lr
@@ -96,7 +96,7 @@ ENTRY(generic_bs_rm_1)
mov pc, lr
-#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
+#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
ENTRY(generic_armv4_bs_rm_2)
add r0, r1, r2
mov r1, r3
@@ -144,7 +144,7 @@ ENTRY(generic_bs_wm_1)
mov pc, lr
-#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
+#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
ENTRY(generic_armv4_bs_wm_2)
add r0, r1, r2
mov r1, r3
@@ -192,7 +192,7 @@ ENTRY(generic_bs_rr_1)
mov pc, lr
-#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
+#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
ENTRY(generic_armv4_bs_rr_2)
add r0, r1, r2
mov r1, r3
@@ -240,7 +240,7 @@ ENTRY(generic_bs_wr_1)
mov pc, lr
-#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
+#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
ENTRY(generic_armv4_bs_wr_2)
add r0, r1, r2
mov r1, r3
@@ -287,7 +287,7 @@ ENTRY(generic_bs_sr_1)
mov pc, lr
-#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
+#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
ENTRY(generic_armv4_bs_sr_2)
add r0, r1, r2
mov r1, r3
@@ -319,7 +319,7 @@ ENTRY(generic_bs_sr_4)
* copy region
*/
-#if (ARM_ARCH_4 + ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
+#if (ARM_ARCH_5 + ARM_ARCH_6 + ARM_ARCH_7) > 0
ENTRY(generic_armv4_bs_c_2)
add r0, r1, r2
ldr r2, [sp, #0]
Index: arm/cpu.c
===
RCS file: /cvs/src/sys/arch/arm/arm/cpu.c,v
retrieving revision 1.24
diff -u -p -r1.24 cpu.c
--- arm/cpu.c 18 Mar 2016 13:16:02 - 1.24
+++ arm/cpu.c 18 Mar 2016 22:17:20 -
@@ -87,7 +87,6 @@ enum cpu_class {
CPU_CLASS_ARM9ES,
CPU_CLASS_ARM9EJS,
CPU_CLASS_ARM10E,
- CPU_CLASS_SA1,
CPU_CLASS_XSCALE,
CPU_CLASS_ARM11J,
CPU_CLASS_ARMv7
@@ -100,36 +99,6 @@ static const char * const generic_steppi
"rev 12", "rev 13", "rev 14", "rev 15"
};
-static const char * const sa110_steppings[16] = {
- "rev 0","step J", "step K", "step S",
- "step T", "rev 5","rev 6","rev 7",
- "rev 8","rev 9","rev 10", "rev 11",
- "rev 12", "rev 13", "rev 14", "rev 15"
-};
-
-static const char * const sa1100_steppings[16] = {
- "rev 0","step B", "step C", "rev 3",
- "rev 4","rev 5","rev 6","rev 7",
- "step D", "step E", "rev 10""step G",
- "rev 12", "rev 13", "rev 14", "rev 15"
-};
-
-static const char * const sa1110_steppings[16] = {
- "step A-0", "rev 1","rev 2","rev 3",
- "step B-0", "step B-1", "step B-2", "step B-3",
- "step B-4", "step B-5", "rev 10", "rev 11",
- "rev 12", "rev 13", "rev 14", "rev 15"
-};
-
-static const char * const ixp12x0_steppings[16] = {
- "(IXP1200 step A)", "(IXP1200 step B)",
- "rev 2","(IXP1200 step C)",
- "(IXP1200 step D)", "(IXP1240/1250 step A)",
- "(IXP1240 step B)", "(IXP1250 step B)",
- "rev 8","rev 9","rev 10", "rev 11",
- "rev 12", "rev 13", "rev 14", "rev 15"
-};
-
static const char * const xscale_steppings[16] = {
"step A-0", "step A-1", "step B-0", "step C-0",
Re: New scheduler for OpenBSD
> From: Bob Beck > Date: Fri, 18 Mar 2016 09:20:35 -0600 > > this is cool .. but > > I would be interested in someone comparing server workloads, as > opposed to interactive GUI response, using this. > > I wouldn't be surprised that inspiriation from BFS would produce > better interactive response, my bigger concern would be does this > adversely impact how we deal with non-interactive workloads. One other important case to test is network packet forwarding. Some of our network stack is now running inside a kernel thread. And any changes in the scheduling behaviour have the potential of having a significant impact there. Another interesting case is the page zeroing thread. It relies on priority-based scheduling to make sure it only runs if we have nothing better to do. So I'm skeptical about this BFS scheduler. Don't get me wrong; I do think the scheduler needs attention. But I'm not sure a scheduler designed for interactive desktop use is the best option for OpenBSD. I'm willing to be proven wrong. But that means we need careful benchmarking on a wide variety of workloads and hardware. > On Fri, Mar 18, 2016 at 8:56 AM, Norman Golisz wrote: > > Hi Michal, > > > > On Fri Mar 18 2016 10:03, Edd Barrett wrote: > >> On Thu, Mar 17, 2016 at 09:26:08PM +0100, Henrik Friedrichsen wrote: > >> > On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote: > >> > > Chrome still isn't smooth. > >> > > > >> > > Please test, and let me know if the performance of something else > >> > > degrades. > >> > > >> > While Chrome may not be 100% smooth yet, the system is a lot more > >> > interactive. I can now play YouTube videos without stutters while doing > >> > other things. > >> > >> I can't vouch for the code, but this makes video playback in firefox > >> usable on my x240t. Before it would stutter beyond belief. > >> > >> I'll run with this for a while and let you know if anything comes up. > > > > I can also confirm this patch makes a HUGE difference in video playback > > performance in firefox and minitube on my T400. > > > > This is the first time I can watch videos without stuttering (even in > > HD/full screen). > > > > And it seems to improve "GUI responsiveness" in general, too. > > > > Thank you for working on this! > > > >
make armv5te the gcc default
Instead of armv4 tuned for strongarm switch to an armv5te default to allow additional instructions to be used (clz etc). armish and zaurus are both xscale (armv5te with additional extensions). The builtin gcc defines change from #define __ARM_ARCH_4__ 1 to #define __ARM_ARCH_5TE__ 1 -mthumb-interwork remains off by default. Index: openbsd.h === RCS file: /cvs/src/gnu/gcc/gcc/config/arm/openbsd.h,v retrieving revision 1.4 diff -u -p -r1.4 openbsd.h --- openbsd.h 21 Oct 2011 10:17:08 - 1.4 +++ openbsd.h 18 Mar 2016 22:33:16 - @@ -38,8 +38,8 @@ Boston, MA 02111-1307, USA. */ #undef MULTILIB_DEFAULTS -/* strongarm family default cpu. */ -#define SUBTARGET_CPU_DEFAULT TARGET_CPU_strongarm +/* armv5te default cpu. */ +#define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm9e /* Default is to use APCS-32 mode. */
Re: spamd & spamlogd open sync port 8025 as root
Hi Ricardo/All, On 2015-12-18 Fri 20:20 PM |, Craig Skinner wrote: > Hi! > > FYI;- I've noticed spamd & spamlogd open their high ports as root. > > These pf rules work, changing to 'user _spamd' doesn't: > > pass in on $ext_if inet proto udp \ > from $ext_if:network port > 1023 \ > to $ext_if:0 port spamd-sync \ > user root > > pass out on $ext_if inet proto udp \ > from $ext_if:0 port > 1023 \ > to $ext_if:network port spamd-sync \ > user root > > > $ fstat -u _spamd | fgrep internet > _spamd spamlogd28614* internet dgram udp *:12412 > _spamd spamd 14083* internet stream tcp 0x0 *:8025 > _spamd spamd 14084* internet stream tcp 0x0 127.0.0.1:8026 > _spamd spamd 14085* internet dgram udp 203.0.113.21:8025 > _spamd spamd 111543* internet stream tcp 0x0 *:8025 > _spamd spamd 111544* internet stream tcp 0x0 127.0.0.1:8026 > _spamd spamd 111545* internet dgram udp 203.0.113.21:8025 > _spamd spamd 114523* internet stream tcp 0x0 *:8025 > _spamd spamd 114524* internet stream tcp 0x0 127.0.0.1:8026 > _spamd spamd 114525* internet dgram udp 203.0.113.21:8025 > > > This box syslogs: > Dec 18 15:13:25 palm spamd[1408]: new WHITE from 203.0.113.20 for > 208.70.245.125, expires 1453562006 > > The WHITE would be from spamlogd sending to UDP 8025 as root > due to the pf rules above for that port require root to function. > > > The source files show all the sockets are opened before priv drop. > > As the ports are above 1023, is this necessary? - I'm not a C coder... > Thanks Ricardo for your patch moving spamd.c's port binding to the unpriv code block for this bug I found. With spamd rebuilt & restarted, I'm trying to inject some test data from another box which spamd syncs in both directions (as root). This claims to connect & hangs: (Nothing in the updated box's syslogs from spamd.) $ KEY_SHA1=$(sha1 -q /etc/mail/spamd.key) $ print "2 3 145880 145890 1.23.456.789 $KEY_SHA1 0" | nc -4uv mx.example.net 8025 Connection to mx.example.net 8025 port [udp/spamd-sync] succeeded! ^C tcpdump on the spamd modified sync receive mx.example.net box shows: Mar 18 18:35:28.334256 r2:d2:23:48:92:0e c3:p0:3a:c5:a5:2c 0800 60: 203.0.113.21.33635 > 203.0.113.20.8025: udp 1 Mar 18 18:35:28.334309 r2:d2:23:48:92:0e c3:p0:3a:c5:a5:2c 0800 60: 203.0.113.21.33635 > 203.0.113.20.8025: udp 1 Mar 18 18:35:28.334360 r2:d2:23:48:92:0e c3:p0:3a:c5:a5:2c 0800 60: 203.0.113.21.33635 > 203.0.113.20.8025: udp 1 Mar 18 18:35:28.334442 r2:d2:23:48:92:0e c3:p0:3a:c5:a5:2c 0800 60: 203.0.113.21.33635 > 203.0.113.20.8025: udp 1 Mar 18 18:35:28.339011 r2:d2:23:48:92:0e c3:p0:3a:c5:a5:2c 0800 124: 203.0.113.21.33635 > 203.0.113.20.8025: udp 82 How can test data be sent to spamd? Thanks. -- Some people claim that the UNIX learning curve is steep, but at least you only have to climb it once.
Re: New scheduler for OpenBSD
Alexandre Ratchov [a...@caoua.org] wrote: > On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote: > > > > Please test, and let me know if the performance of something else > > degrades. > > > > With your diff firefox consumes twice less cpu (watched the same > video with and without the diff). This suggests firefox spins > somewhere and your diff makes it spin less. > > When audio device is using small blocks it stutters more with your > diff though; according to device counters the stuttering is caused > by sndiod not getting the cpu fast enough. there is no 'nice' functionality at the moment
Re: Implement delay() using TSC
On Wed, Mar 16, 2016 at 11:25:11PM -0700, Mike Larkin wrote:
> On Thu, Mar 17, 2016 at 09:44:22AM +0900, Masao Uebayashi wrote:
> > Implement delay() using TSC
> >
> > - Calculate delay using 64-bit RDTSC instruction
> > - Enable tsc_delay() as delay(9) backend
> > - Use tsc_delay() only when TSC is invariant
> > - Configure tsc_delay() after primary CPU is identified
> > - Assume all CPUs are identical
>
> Why is this needed, or wanted? There is no explanation given above
> aside from "let's make things different". Are you claiming that
> delay(9) is somehow inaccurate or incorrect without this?
I think LAPIC delay() is just fine. Accuracy is not a problem for me.
In the long run, I want to use LAPIC for per-CPU one-shot timer. This
will come later ... but it'd be nice for me to know if using TSC for
delay() is not a problem.
> -ml
>
> >
> > diff --git a/sys/arch/amd64/amd64/cpu.c b/sys/arch/amd64/amd64/cpu.c
> > index df6c623..0863306 100644
> > --- a/sys/arch/amd64/amd64/cpu.c
> > +++ b/sys/arch/amd64/amd64/cpu.c
> > @@ -330,6 +330,7 @@ cpu_attach(struct device *parent, struct device *self,
> > void *aux)
> > vaddr_t kstack;
> > struct pcb *pcb;
> > #endif
> > + void tsc_delay_init(struct cpu_info *);
> >
> > /*
> > * If we're an Application Processor, allocate a cpu_info
> > @@ -409,6 +410,7 @@ cpu_attach(struct device *parent, struct device *self,
> > void *aux)
> > #endif /* MTRR */
> > cpu_init(ci);
> > cpu_init_mwait(sc);
> > + tsc_delay_init(ci);
> > break;
> >
> > case CPU_ROLE_BP:
> > @@ -432,6 +434,7 @@ cpu_attach(struct device *parent, struct device *self,
> > void *aux)
> > ioapic_bsp_id = caa->cpu_number;
> > #endif
> > cpu_init_mwait(sc);
> > + tsc_delay_init(ci);
> > break;
> >
> > case CPU_ROLE_AP:
> > diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
> > new file mode 100644
> > index 000..15242ca
> > --- /dev/null
> > +++ b/sys/arch/amd64/amd64/tsc.c
> > @@ -0,0 +1,68 @@
> > +/*
> > + * Copyright (c) 2016 Masao Uebayashi
> > + *
> > + * 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.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +
> > +#include
> > +#include
> > +
> > +void tsc_delay_init(struct cpu_info *);
> > +void tsc_delay(int);
> > +uint64_t tsc2usec(uint64_t n);
> > +
> > +int64_t tsc_delay_mult;
> > +
> > +void
> > +tsc_delay_init(struct cpu_info *ci)
> > +{
> > +#ifdef DIAGNOSTIC
> > + KASSERT(ci->ci_tsc_freq != 0);
> > +#endif
> > + if ((ci->ci_flags & CPUF_CONST_TSC) == 0)
> > + return;
> > +
> > + tsc_delay_mult = ci->ci_tsc_freq / 100;
> > + delay_func = tsc_delay;
> > +}
> > +
> > +void
> > +tsc_delay(int usec)
> > +{
> > + int64_t n;
> > + uint64_t now, prev;
> > +
> > + n = tsc_delay_mult * usec;
> > + prev = rdtsc();
> > + while (n > 0) {
> > + CPU_BUSY_CYCLE();
> > + now = rdtsc();
> > + if (now < prev)
> > + n -= UINT64_MAX - (prev - now);
> > + else
> > + n -= now - prev;
> > + prev = now;
> > + }
> > +}
> > +
> > +uint64_t
> > +tsc2usec(uint64_t n)
> > +{
> > + struct cpu_info *ci = curcpu();
> > +
> > + return n / ci->ci_tsc_freq * 100;
> > +}
> > diff --git a/sys/arch/amd64/conf/files.amd64
> > b/sys/arch/amd64/conf/files.amd64
> > index 5d58b34..d101cf2 100644
> > --- a/sys/arch/amd64/conf/files.amd64
> > +++ b/sys/arch/amd64/conf/files.amd64
> > @@ -97,6 +97,7 @@ definecpu {[apid = -1]}
> > device cpu
> > attach cpu at mainbus
> > file arch/amd64/amd64/cpu.c cpu
> > +file arch/amd64/amd64/tsc.c cpu
> >
> >
> > define lapic
> >
Re: IB700 watchdog
> Date: Thu, 17 Mar 2016 14:28:04 +0900
> From: Masao Uebayashi
>
> This tiny driver is only meant for a backup watchdog configuration on
> QEMU, whose ICH watchdog, supported by ichwdt(4), seems broken.
>
> ib700wdt(4) supports only 0-30 second timeouts but in practice it should
> be good enough.
The problem is that isa-style probes like this are dangerous. That is
probably why you didn't enable this driver by default. But if you
don't enable the code, it will rot.
Is there a better way to detect this "device"? For example in the
acpi device tree?
> diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC
> index fee3c2a..82e7de0 100644
> --- a/sys/arch/amd64/conf/GENERIC
> +++ b/sys/arch/amd64/conf/GENERIC
> @@ -608,6 +608,7 @@ bktr0 at pci?
> radio* at bktr?
>
> #wdt0at pci? # Ind Computer Source PCI-WDT50x driver
> +#ib700wdt* at isa? port 0x441# iBase 700 (IB700) Watchdog Timer
>
> # crypto support
> hifn*at pci? # Hi/fn 7751 crypto card
> diff --git a/sys/arch/i386/conf/GENERIC b/sys/arch/i386/conf/GENERIC
> index 0984e5b..dbb7df6 100644
> --- a/sys/arch/i386/conf/GENERIC
> +++ b/sys/arch/i386/conf/GENERIC
> @@ -108,6 +108,7 @@ geodesc* at pci? # Geode SC1100/SCx200 IAOC
> wdt0 at pci? # Ind Computer Source PCI-WDT50x driver
> berkwdt0 at pci? # Berkshire PCI-PC Watchdog driver
> pwdog0 at pci? # Quancom PWDOG1 watchdog timer
> +#ib700wdt* at isa? port 0x441# iBase 700 (IB700) Watchdog Timer
>
> # National Semiconductor LM7[89] and compatible hardware monitors
> lm0 at isa? port 0x290
> diff --git a/sys/dev/isa/files.isa b/sys/dev/isa/files.isa
> index 863d11c..92a9ecc 100644
> --- a/sys/dev/isa/files.isa
> +++ b/sys/dev/isa/files.isa
> @@ -380,3 +380,8 @@ file dev/isa/isagpio.c isagpio
> #filedev/isa/pcmcia_pcic.c pcic | pcicmaster
>
> #filedev/isa/pcmcia_isa.cpcmcia
> +
> +# iBase 700 (IB700) Watchdog Timer
> +device ib700wdt
> +attach ib700wdt at isa
> +file dev/isa/ib700wdt.c ib700wdt
> diff --git a/sys/dev/isa/ib700wdt.c b/sys/dev/isa/ib700wdt.c
> new file mode 100644
> index 000..cdad79f
> --- /dev/null
> +++ b/sys/dev/isa/ib700wdt.c
> @@ -0,0 +1,142 @@
> +/*
> + * Copyright (c) 2016 Masao Uebayashi
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +/*
> + * IB700 USER'S MANUAL
> + * Version 1.0B
> + * p28
> + * Watchdog Timer Configuration
> + */
> +
> +#define IB700WDT_BASE 0x441
> +#define IB700WDT_SIZE 3
> +#define IB700WDT_DIS0 /* 0x441 */
> +#define IB700WDT_ENA2 /* 0x443 */
> +#define IB700WDT_SEC_MIN0
> +#define IB700WDT_SEC_MAX30
> +
> +static inline uint8_t
> +ib700wdt_sec2val(int sec)
> +{
> + /* 0/1sec = 0xf, 2/3sec = 0xe, ..., 28/29 = 0x1, 30sec = 0x0 */
> + return (0xf - (sec * 0xf / 30));
> +}
> +
> +/*
> + * Driver for iBase 700 Watchdog Timer
> + * Mainly meant for QEMU's "ib700" watchdog device
> + * Can't handle immediate reset (sec=0)
> + */
> +
> +struct ib700wdt_softc {
> + struct device sc_dev;
> + bus_space_tag_t sc_iot;
> + bus_space_handle_t sc_ioh;
> + int sc_period;
> +};
> +
> +int ib700wdt_match(struct device *, void *, void *);
> +void ib700wdt_attach(struct device *, struct device *, void *);
> +int ib700wdt_activate(struct device *, int);
> +
> +int ib700wdt_cb(void *, int);
> +
> +struct cfattach ib700wdt_ca = {
> + sizeof(struct ib700wdt_softc),
> + ib700wdt_match, ib700wdt_attach, NULL, ib700wdt_activate
> +};
> +
> +struct cfdriver ib700wdt_cd = {
> + NULL, "ib700wdt", DV_DULL
> +};
> +
> +int
> +ib700wdt_match(struct device *parent, void *match, void *aux)
> +{
> + struct isa_attach_args *ia = aux;
> +
> + ia->ia_iosize = IB700WDT_SIZE;
> + ia->ia_msize = 0;
> +
> + return (1);
> +}
> +
> +void
> +ib700wdt_attach(struct device *parent, struct device *self, void *aux)
> +{
> + struct ib700wdt_softc *sc = (struct ib700wdt_softc *)self;
> + struct
Re: CPUID in amd64/i386 boot code
On Thu, Mar 17, 2016 at 16:39 +0100, Mike Belopuhov wrote: > On Wed, Mar 16, 2016 at 23:47 -0700, Mike Larkin wrote: > > On Thu, Mar 17, 2016 at 03:31:45PM +0900, Masao Uebayashi wrote: > > > On Wed, Mar 16, 2016 at 11:26:39PM -0700, Mike Larkin wrote: > > > > On Thu, Mar 17, 2016 at 03:15:07PM +0900, Masao Uebayashi wrote: > > > > > This is the intended use, avoid busy-polling of BIOS PC console if > > > > > running on HV. Avoid 100% CPU usage at boot prompt on hypervisors. > > > > > > > > > > > > > Which hypervisors have you tested this on? > > > > > > VMware ESXi > > > KVM > > > QEMU > > > > While I share some of Theo's concerns about testing this, this particular > > diff seems ok to me. You probably at least need to get someone to test on > > Hyper-V, and run these new bootblocks on a variety of machines (especially > > older non-Intel/AMD i386 machines). > > > > -ml > > > > I've tested the diff and with a small adjustment to the > efiboot/bootia32/Makefile below, I was able to rebuild > stand/ and test the thing (with the follow up diff to > the bioscons.c). > > As I've mentioned on ICB, Xen exposes this issue, while > Hyper-V doesn't. The change doesn't help or harm Xen, no > change on Hyper-V. But I think it's still useful if this > helps KVM and VMware. > Apparently I missed that glass and serial consoles have different implementations. Duh! So with a "glass" console I can see reduction on both Xen and Hyper-V. On Xen CPU load goes from 100% (according to "xl top") to 0, while on Hyper-V: from 8% to 0. Thanks again for the diff.
Re: IB700 watchdog
+#ib700wdt* at isa? port 0x441 # iBase 700 (IB700) Watchdog Timer
We don't do drivers with numbers in their names.
+int
+ib700wdt_match(struct device *parent, void *match, void *aux)
+{
+ struct isa_attach_args *ia = aux;
+
+ ia->ia_iosize = IB700WDT_SIZE;
+ ia->ia_msize = 0;
+
+ return (1);
+}
That does nothing. OH LOOK! My laptop has this chip.
So does my server! Every machine has it.
+ if (period == 0) {
+ if (sc->sc_period != 0)
+ bus_space_write_1(sc->sc_iot, sc->sc_ioh, IB700WDT_DIS,
0);
+ } else {
Now you write to a register, on all x86 machines.
No, that won't do at all. Not even commented out, because the
pattern it teaches others is not right.
