The default traceroute timeout of 5 seconds is excruciatingly long
when there are elements of the route that don't respond, and it
wasn't allowed to be set lower than 2 seconds.
This changes the minimum to 1 second, matching FreeBSD, and also
makes that the default, which should be reasonable for
I would like to be able to clone the github mirror on windows. I do
wind up
using 7z on the tar file as a workaround, but it would be nice if github
"just worked". The com files is what the clone fails on, and those
seemed
easy enough to address, but if it is actually a deep rat hole, I
Perform an explicit check for the unsupported exFAT MSDOS filesystem
instead of letting it fail mysteriously when it gets cluster sizes
of 0 from the normal fields.
This causes mount_msdos to report:
mount_msdos: /dev/sd1i on /root/mnt: filesystem not supported by kernel
Instead of the more
IO rates above 100 MB/s are common with SSD; this patch expands the
column so it stays neatly printed.
An argument can be made for expanding it one more for fast M.2 drives.
? dkstats.d
? iostat
? iostat.d
Index: iostat.c
===
RCS
I tried to mount a 12TB USB drive, and was getting an "Inappropriate
file type or format" error.
It turned out to be due to exFAT formatting, but it took me some
investigating to figure that out. Would it be reasonable to have the
kernel print a more informative warning like "exFAT filesystem
There are several user visible "warts" with wsmoused:
Wsmoused conflicts with X's use of the mouse, you can't ctrl-alt-screen
between X and text consoles and use the mouse in both of them.
The cursor location is in character cells instead of pixels, so the
cursor moves twice as fast vertically
I have also noticed that comments are hard to read in color-vim
because of the dark blue on black; increasing the intensity would
be a trivial improvement.
I have thought about testing a bold attribute implementation by
way of shift-and-overlay of the font bitmap so all the colors could
be full
I did some more tests, and I think the odd performance I am seeing
may be due to TLB thrash on the 32x64 characters with 4k pages,
since writing each character will require 64 data TLB.
Are huge page mappings supported in OpenBSD?
Original Message
Subject: Re: [PATCH} Optimized
I was doing my timings with a user mode program after mmmaping the
efifb display, so the mapping might be different in the kernel.
Related to that, I was going to add mmap / WSDISPLAYIO_LINEBYTES /
WSDISPLAYIO_SMODE to the drm drivers by consolidating code into
rasops. While the point of the DRM
I believe it is mapped as normally cached right now, rather than
uncached or write combining.
Reads aren't ultra-slow, and the timings of 48 byte writes appear to
involve a cacheline read.
128 byte writes are actually slower than 64 byte writes, which I
guessed might be because of automatic
I should have been more rigorous -- I had two different changes running
on my system, as well as forcing it to use the 12x24 font for a 160x45
console.
If you apply the "Optimized rasops32 putchar" patch I just posted, you
should see another significant speedup.
Original Message
Optimized 32 bit character rendering with unrolled rows and pairwise
foreground / background pixel rendering.
If it weren't for the 5x8 font, I would have just assumed everything
was an even width and made the fallback path also pairwise.
In isolation, the 16x32 character case got 2x faster, but
This causes the write-only framebuffer console to only redraw the
chars that differ between the start and end positions.
'time ls -R /usr/src/sys' is 3x faster with this, because most of
the characters stay the same after a scroll.
If this looks good, I can do the same thing for clear rows and
Are SSE instructions allowed in the AMD64 kernel? Is #ifdef __SSE__
a sufficient guard?
I have a rasops32 putchar with SSE that is 2x faster.
Ok, I didn't know such things existed.
I would think that a coreboot framebuffer would be preferred over a
VGA console, unless there was a system that only had the framebuffer
in uncached-not-write-combined mapping.
Original Message
Subject: Re: [patch] remove NPCDISPLAY from
You can't put an ISA CGA/EGA/MGA in an AMD64 system, so these can
go away.
Does anyone know if there is an ordering reason that the coreboot
efifb_cb_cnattach console is after the VGA attach? Things could be
cleaned up a bit if the efifb entry points just checked for both
efi and coreboot
What would be a good system with CoreBoot to get for OpenBSD testing?
It looks like there are some edge cases where the CoreBoot framebuffer
support won't behave the same as the EFI framebuffer.
Looking for some guidance to avoid proposing any unpopular diffs.
Style(9) says not to use static on file-local functions in the
kernel, because it interferes with the debugger. They still show up
on some functions today; is this still an issue?
I usually advocate for directly inlining small
Most of the display drivers wrap the rasops functions, but you can
get rid of a lot of code by swapping the cookies and just using
the rasops functions directly in wsdisplay_accessops.
It is unfortunate that an extra parameter was added to the
alloc_screen function, aparently for an obscure
I think I am missing some basic bit of configuration lore.
I hacked my kernel to change the font size selected by rasops, but I
would like to make a proper configuration interface for it, something
like an integer that biased the default size calculation.
It would be nice to be able to use
Another trivial code readability comment:
I see 24 references to this in the code, 20 of which pass 0, and 4 of
which pass 1,000,000 as the parameter.
Passing 0 defaults to a baud of 115200. The baud determines the qlen,
which is 4096 for 115200 and 8192 for anything larger, so all it is
doing
The efifb driver behaves almost identically to the inteldrm driver
for wscons, but did not implement the getchar() accessops, so
wsmoused would fail at startup.
Separately, I increased the maximum screen dimensions to 160x50 to
allow the 12x24 font to be used on an 1920 monitor, which looks
Ulf pointed out that you could scale the mouse speed with the cryptic:
wsconsctl mouse.param=0:401,1:401
Looking into it more, wsconsctl already has a floating point version
of this that sets both X and Y values, but it only shows up and
functions if you have a touchpad, not a mouse:
wsconsctl
Ok, that works -- I could not tell what that parsing code did in
wsconsctl, and I thought the scaling code in wscons only got applied to
touchpads.
In that case, how about just allowing wsconsctl to accept mouse.speed as
a special floating point parameter that sets both the DX and DY scales
With the changes I proposed in the "mouse movement speed" message,
the text mode cursor can be slowed down to the point where it is
controllable, but it still isn't ideal for a few reasons:
It is still anisotropic, with vertical movement feeling faster than
horizontal due to the aspect of the
I enabled wsmoused for console mouse support, but the cursor was
unusably fast. This is a high resolution, high update rate USB gaming
mouse, but it was off by well over an order of magnitude.
I searched for a global mouse speed setting, but the only thing I
found was a
(Not sure if this belongs in tech@ or misc@)
What is the thinking around non-functional code changes that just
improve clarity without functionality changes? I can imagine bad
experiences with that, but there is certainly room for improvement.
For instance, in the wsdisplay_emulops structure,
The process of using 40/50 row vga text modes is pretty cumbersome now:
wsfontload -h 8 -e ibm /usr/share/misc/pcvtfonts/vt220l.808
wsconscfg -dF 1
wsconscfg -t 80x50 1
I just reported a bug and a fix with font corruption, but I want to
propose a
few usability improvements that I am interested
28 matches
Mail list logo
