Scott Cheloha [2022-09-23, 14:51 -0500]:
> On Fri, Sep 23, 2022 at 10:40:19PM +0300, Timo Myyr?? wrote:
>
>> Scott Cheloha [2022-09-23, 09:16 -0500]:
>>
>> > [...]
>> >
>> > Test results? Clues on reading the configuration space?
>> >
>
multiplier = fid = def & 0xff;
> + printf(" base %llu mul %llu div %llu",
> + base, multiplier, divisor);
> + break;
> + default:
> + return 0;
> + }
> + printf(" freq %llu Hz\n", base * mult
Scott Cheloha [2022-07-30, 22:13 -0500]:
> Hi,
>
> At the urging of sthen@ and dv@, here is v5.
>
> Two major changes from v4:
>
> - Add the function tc_reset_quality() to kern_tc.c and use it
> to lower the quality of the TSC timecounter if we fail the
> sync test.
>
> tc_reset_quality() w
Scott Cheloha [2022-07-28, 20:34 -0500]:
> On Thu, Jul 28, 2022 at 04:57:41PM -0400, Dave Voutila wrote:
>
>>
>> Stuart Henderson writes:
>>
>> > On 2022/07/28 12:57, Scott Cheloha wrote:
>> >> On Thu, Jul 28, 2022 at 07:55:40AM -0400, Dave Voutila wrote:
>> >> >
>> >> > This is breaking timec
good start patching it.
>
> I have a crude understanding of C, C++. Better of rust. Don't know much about
> deep kernel and OS stuff. Want to learn more.
>
> Thanks
Check out following paper to get started:
https://www.openbsd.org/papers/eurobsdcon2017-device-drivers.pdf
Timo
ste
with mouse.
Here's cleaned up patch for reference.
timo
Index: sys/dev/usb/ums.c
===
RCS file: /cvs/src/sys/dev/usb/ums.c,v
retrieving revision 1.45
diff -u -p -u -p -r1.45 ums.c
--- sys/dev/usb/ums.c 23 Aug 2020 1
so without the TSC patch and it didn't make any difference.
Only other tweak is enabled amdgpu driver in GENERIC.
timo
Martin Pieuchot writes:
> On 06/06/19(Thu) 15:16, Martin Pieuchot wrote:
>> On 02/06/19(Sun) 16:41, Martin Pieuchot wrote:
>> > On 01/06/19(Sat) 18:55, Martin Pieuchot wrote:
>> > > Diff below exists mainly for documentation and test purposes. If
>> > > you're not interested about how to break t
Paul Irofti writes:
> Hi,
>
> Here is an initial diff, adapted from NetBSD, that synchronizes TSC
> clocks across cores.
>
> CPU0 is the reference clock and all others are skewed. During CPU
> initialization the clocks synchronize by keeping a registry of each CPU
> clock skewness and adapting th
g videos and
suspend/resume. I didn't notice any regressions.
Though it still has following lines:
error: [drm:pid0:cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo
underrun on pch transcoder A
error: [drm:pid0:intel_pch_fifo_underrun_irq_handler] *ERROR* PCH transcoder A
On Mon, Apr 24, 2017 at 12:01:10AM +0200, Marc Espie wrote:
> On Sun, Apr 23, 2017 at 10:16:38PM +0200, Timo Buhrmester wrote:
> > > The main difference between you and Theo is that Theo knows what he's
> > > talking about.
>
> > If you want to contribute an
> The main difference between you and Theo is that Theo knows what he's
> talking about.
If you want to contribute anything, point out how casting a non-negative
into to size_t for comparison against another size_t could lead to
"real errors later whenever the code evolves in any way". Nice straw
> Timo if you feel the need to be an asshole, please be that asshole
> elsewhere.
Pot, meet Kettle.
> > Otherwise people might fall into a habit
> > of ignoring warnings [that may point to actual problems].
>
> People might fall into the habit of ignoring a warning from an
> extension to C provided by a single compiler?
>
> I doubt it.
Doubt away. I find it more than obvious that telling peopl
> The code is already safe.
It is reasonably safe(*) and triggers a warning. That's a good reason
to silence the warning. Otherwise people might fall into a habit
of ignoring warnings [that may point to actual problems]. I just
pointed out a safe way to silence the warning, without it
potentially
> Well, when the world changes, that cast is suddenly wrong.
I.e. instead of
> if (ret == -1 || ret >= sizeof(buffer))
one could use
> if (ret < 0 || (size_t)ret >= sizeof(buffer))
And be safe from a changing world.
Stefan Sperling writes:
> On Mon, Mar 06, 2017 at 07:36:21AM +0200, Timo Myyrä wrote:
>
>> Did some tcpbench testing and got following results:
>> Each test run with: tcpbench -s || tcpbench -t 15 commands.
>> Host AP: apu 2b4 with athn, client = thinkpad t430s with iwn
Stefan Sperling writes:
> On Tue, Jan 31, 2017 at 07:10:04AM +0200, Timo Myyrä wrote:
>> 11g: Client->AP: ~15Mbps, AP->Client: ~5Mbps
>> 11n: Client->AP: ~3Mbps, AP->Client: ~5Mbps
>
> I just committed a change which makes RTS optional in 11n mode.
> The AP s
Stefan Sperling writes:
> On Sun, Jan 29, 2017 at 07:49:56AM +0200, Timo Myyrä wrote:
>> Hmm, I've been running the 11n for a while and it seems to be a lot slower
>> than
>> 11g for me. Just did quick benchmark using tcpbench between OpenBSD hostAP
>> (athn) an
if (j >= AR_HTC_RATE_MAX)
> + break;
> + rate.ht_rates.rs_rates[j++] = i;
> + }
> + rate.ht_rates.rs_nrates = j;
> #ifdef notyet
> - /* XXX setup HT rates */
> if (ni->ni_htcaps & IEEE80211_HTCAP_CBW20_40)
> rate.capflags |= htobe32(AR_RC_40_FLAG);
> if (ni->ni_htcaps & IEEE80211_HTCAP_SGI40)
>
Hmm, I've been running the 11n for a while and it seems to be a lot slower than
11g for me. Just did quick benchmark using tcpbench between OpenBSD hostAP
(athn) and
laptop (iwn). It looks when my athn is in 11n mode I get around ~3 Mbps:
...
Conn: 1 Mbps:3.321 Peak Mbps:5.763 Avg Mbps:3.321
16044 4068883.249 100.00%
Conn: 1 Mbps:3.249 Peak Mbps:5.763 Avg Mbps:3.249
17045 3504162.803 100.00%
Conn: 1 Mbps:2.803 Peak Mbps:5.763 Avg Mbps:2.803
18047 4083363.260 100.00%
Conn: 1 Mbps:3.260 Peak Mbps:5.763 Avg Mbps:3.260
19050 4141283.303 100.00%
Conn: 1 Mbps:3.303 Peak Mbps:5.763 Avg Mbps:3.303
20054 4025443.211 100.00%
Conn: 1 Mbps:3.211 Peak Mbps:5.763 Avg Mbps:3.211
21055 4445363.553 100.00%
Conn: 1 Mbps:3.553 Peak Mbps:5.763 Avg Mbps:3.553
22056 3634482.908 100.00%
Conn: 1 Mbps:2.908 Peak Mbps:5.763 Avg Mbps:2.908
23058 4271603.414 100.00%
...
Switching the AP to 11g mode seems to provide a lot better throughput:
...
Conn: 1 Mbps: 13.449 Peak Mbps: 14.373 Avg Mbps: 13.449
40031765112 14.121 100.00%
Conn: 1 Mbps: 14.121 Peak Mbps: 14.373 Avg Mbps: 14.121
50031579768 12.638 100.00%
Conn: 1 Mbps: 12.638 Peak Mbps: 14.373 Avg Mbps: 12.638
60041374152 10.993 100.00%
Conn: 1 Mbps: 10.993 Peak Mbps: 14.373 Avg Mbps: 10.993
70171268448 10.027 100.00%
Conn: 1 Mbps: 10.027 Peak Mbps: 14.373 Avg Mbps: 10.027
801711656409.325 100.00%
Conn: 1 Mbps:9.325 Peak Mbps: 14.373 Avg Mbps:9.325
901810816568.653 100.00%
Conn: 1 Mbps:8.653 Peak Mbps: 14.373 Avg Mbps:8.653
1001911135128.908 100.00%
Conn: 1 Mbps:8.908 Peak Mbps: 14.373 Avg Mbps:8.908
1102011555049.235 100.00%
Conn: 1 Mbps:9.235 Peak Mbps: 14.373 Avg Mbps:9.235
...
Quickly looking it seems the 11g is 3x faster than 11n which seems a bit odd.
I'd assume they should be roughly the same.
Any idea what could explain the difference?
There are 8 other wireless networks in range but all of those are on different
channels.
running with:
athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16
athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:16:93:cc
and
iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi,
MIMO 2T2R, MoW, address 60:67:20:f8:17:f4
Timo
> delete [vnd] entirely
Out of curiosity (I'm mostly a NetBSD user), without vnd what would be
the OpenBSD-way of providing a disk-ish interface to a file?
> It's kind of ironic that we're arguing about the POSIX compliance of 'cp
> -i' while the 'yes' command doesn't even exist in POSIX.
Not really, because this is about the 'cp -i' part rather than the 'yes n'.
Consider the latter an alias for ``while true; do echo n; done'' :-).
> 'pax', which is
On Sat, Mar 05, 2016 at 03:03:36AM +0100, Dmitrij D. Czarkoff wrote:
> So the goal of the diff is to replace something like
>
> $ for src in ${files}; do [ -r "$src" ] && cp ${src} dst/; done
>
> with
>
> $ yes n | cp -i ${files} dst/
>
> ?
Or alternatively, to state in the manual that -i w
On Sat, Mar 05, 2016 at 02:39:41AM +0100, Dmitrij D. Czarkoff wrote:
> > This breaks doing something along the lines of ``yes n | cp -i [...]''
>
> Why would anyone want that?
To simulate what in FreeBSD's and GNU's implementation of cp is the
-n option, i.e. to only copy files that don't already
t use of -i is a request for
> interaction, so when the destination path exists, the utility takes
> instructions from whatever responds on standard input.
..which I believe conflicts with what our cp's -i does.
At the bottom of this mail is a patch that drops the ``isatty()''.
Che
Ok makes sense. I'll look over the documentation and see if I find
something I can contribute to.
Regards.
Timo
On 23/01/2016 10:44, Martijn van Duren wrote:
> On 01/23/16 09:35, Timo wrote:
>> Hi who is responsible for writing documentation for OpenBSD?
>> I'd like t
Hi who is responsible for writing documentation for OpenBSD?
I'd like to get involved in writing documentation for OpenBSD as I
really like OpenBSD and I feel technical writing is one of my strong points.
Regards.
Timo
t inteldrm? console 1
> -wsdisplay* at inteldrm?
> +wsdisplay* at inteldrm? mux -1
> radeondrm* at pci? # ATI Radeon DRM driver
> drm0 at radeondrm? console 1
> drm* at radeondrm?
> wsdisplay0 at radeondrm? console 1
> -wsdisplay* at radeondrm?
> +wsdisplay* at radeondrm? mux -1
>
> pcppi0 at isa?
>
Just tested this on my desktop (amd64) and it attaches my usb keyboard
correctly.
Timo
and
Zlib should review them so that they don't contain any suprises.
Timo
Index: regress/lib/Makefile
===
RCS file: /cvs/src/regress/lib/Makefile,v
retrieving revision 1.18
diff -u -u -p -r1.18 Makefile
--- regress/lib/Makefile
Index: net80211/ieee80211_ioctl.c
> ===
> RCS file: /cvs/src/sys/net80211/ieee80211_ioctl.c,v
> retrieving revision 1.39
> diff -u -p -r1.39 ieee80211_ioctl.c
> --- net80211/ieee80211_ioctl.c14 Mar 2015 03:38:51 -
type would be int_least32_t, no? (required to exist (C99
7.18.1.2p3))
(That said, I'm not sure if there's a port for which this could be a problem,
so if not, feel free to disregard)
--
Timo Buhrmester
> (dmesg attached anyway).
Eh, or not? But now.
OpenBSD 5.8-current (GENERIC.MP) #2: Mon Sep 7 03:09:58 CEST 2015
fstd@flap.localdomain:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3472392192 (3311MB)
avail mem = 3363315712 (3207MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
main
> get some reports that this doesn't break suspend/resume on real machines,
> especially older ones (like core 2 duo and older) and ones with an amd cpu.
Suspend (and more importantly, resume) still works on my 2011-ish amd64 laptop
with your patch (dmesg attached anyway).
Chee
);
> +
> + KERNEL_LOCK();
> +
> pmap_destroy(map->pmap);
> map->pmap = NULL;
> }
> @@ -3185,6 +3190,8 @@ void
> uvmspace_init(struct vmspace *vm, struct pmap *pmap, vaddr_t min, vaddr_t
> max,
> boolean_t pageable, boolean_t remove_holes
Hi,
Noticed that Tampere airport is missing from the list.
Timo
Index: airport
===
RCS file: /cvs/src/share/misc/airport,v
retrieving revision 1.44
diff -u -r1.44 airport
--- airport 7 Dec 2014 22:54:05 - 1.44
e full release build with and
without SMALL defined to cover the alternatives. Also with different
architectures to cover any arch-specific issues.
My original idea was to get notmuch working but as pointed out, it was trivially
patched to work with base version.
Timo
Stuart Henderson writes:
> On 2014/12/23 22:54, Timo Myyrä wrote:
>> I was trying to port notmuch mail indexer but got little stuck with it as it
>> requires newer Zlib version than whats in base. I got little spare time in
>> my
>> hands and here's a rough p
mainbus0 bus 255
pchb1 at pci5 dev 0 function 0 "Intel QuickPath" rev 0x02
pchb2 at pci5 dev 0 function 1 "Intel QuickPath" rev 0x02
pchb3 at pci5 dev 2 function 0 "Intel QPI Link" rev 0x02
pchb4 at pci5 dev 2 function 1 "Intel QPI Physical" rev 0x02
pchb5 at pci5 dev 2 function 2 "Intel Reserved" rev 0x02
pchb6 at pci5 dev 2 function 3 "Intel Reserved" rev 0x02
uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
ugen0 at uhub2 port 3 "UPEK Biometric Coprocessor" rev 1.01/0.02 addr 3
ugen1 at uhub2 port 4 "Broadcom Corp Broadcom Bluetooth Device" rev 2.00/3.60
addr 4
uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
sd1 at scsibus2 targ 1 lun 0: SCSI2 0/direct fixed
sd1: 152625MB, 512 bytes/sector, 312576113 sectors
root on sd1a (741cf65615793b8b.a) swap on sd1b dump on sd1b
ugen0 detached
ugen1 detached
uhub2 detached
uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
ugen0 at uhub2 port 3 "UPEK Biometric Coprocessor" rev 1.01/0.02 addr 3
ugen1 at uhub2 port 4 "Broadcom Corp Broadcom Bluetooth Device" rev 2.00/3.60
addr 4
uhub3 detached
uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
ugen0 detached
ugen1 detached
uhub2 detached
uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
ugen0 at uhub2 port 3 "UPEK Biometric Coprocessor" rev 1.01/0.02 addr 3
ugen1 at uhub2 port 4 "Broadcom Corp Broadcom Bluetooth Device" rev 2.00/3.60
addr 4
uhub3 detached
uhub3 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
timo
d->v_field.type == AMLOP_BANKFIELD) {
> _aml_setvalue(&tmp, AML_OBJTYPE_INTEGER, fld->v_field.ref3, 0);
> aml_rwfield(ref2, 0, aml_intlen, &tmp, ACPI_IOWRITE);
> @@ -2414,10 +2487,6 @@ aml_createfield(struct aml_value *field,
> opcode == AMLO
The sysctl.h doesn't include comment for struct kinfo_proc.p_comm.
Add field comment as all other fields seem to be commented.
Timo
Index: sysctl.h
===
RCS file: /cvs/src/sys/sys/sysctl.h,v
retrieving revision 1.121
diff
cording
to second reply bto that thread.
Still haven't tested further this.
Diffs can be found here:
http://kerneltrap.org/mailarchive/openbsd-bugs/2009/5/20/5754773/thread
Timo M
41 matches
Mail list logo
