Re: Need Help with OpenBSD VPS
On Sat, Aug 17, 2019 at 08:35:41AM -0400, Michael G Workman wrote: > Hello, > > Thanks everyone for the great work on OpenBSD, I am very happy such a great > operating system is available for people to use. > > I am planning to install OpenBSD on a laptop I have in the future, I am > just waiting for the laptop to be returned to me after being repaired, in > the meantime I obtained a free Unix (NetBSD) Shell account at SDF.org, and > I also obtained an OpenBSD VPS from them as well. > > I was able to initialize the VPS no problem, but when I try to connect to > it, I get a message of "openbsd does not support PV style console" and I am That message comes from their VM software. You need to ask them. > unable to connect, the same message mentions TinyVNC. I tried connecting > using Putty, SSH from the shell, and also OpenSSH from the command line on > my Windows 10 laptop, still get the same message no matter which connection > message. Google and Bing searches return nothing. I sent multiple emails to > SDF but no replies yet. > > I am also trying to get help on openbsd IRC channel on freenode. > > I could really use some help with this issue, I want to start working with > OpenBSD right away. > > Thank you. > > *Michael G. Workman* > (321) 432-9295 > michael.g.work...@gmail.com -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Doc. modification advise not to use softdep with KARL
On Sun, Feb 18, 2018 at 11:51:14AM +1100, Jason Tubnor wrote: > Hi, > > In some instances, we have found that where softdep has been placed on file > systems that are used as part of the KARL process, incomplete writes have > occurred (not committed to storage correctly) prior to reboot. Files > affected have been /bsd, /usr/share/compile/GENERIC/relink.log and > /var/db/kernel.SHA256. This has lead to failed reboots (not being able to > get to the remote host due to malformed kernel), host complaints during boot > because of mismatched SHA256 sums and truncated logs of null after reboot. > > I don't believe this is a bug, more of an unexpected consequence of using > softdep. Users should be recommended to use it [softdep] only on file > systems that would benefit from its features and not blindly apply it to > every file system. > > Below are patches to applicable documentation recommending not to enable > softdep on file systems containing the files above. After significant > testing, not enabling softdep on these file systems fixed our problems for > reboots and after syspatch. The only time I could error messages now is > executing a reboot immediately after the login prompt became active on the > console, however none of the above files were affected. > > Raw patch files: > > https://dnld.ar18.org/pub/OpenBSD/wip/mount.8.patch > > https://dnld.ar18.org/pub/OpenBSD/wip/faq14.patch > Some softdep bugs were fixed in -current back in December. Give -current a try or wait until 6.3. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: arm64 MP
On Mon, Feb 19, 2018 at 01:49:48PM +0100, Mark Kettenis wrote: > The diff below attempts to make the arm64 pmap "mpsafe" and enables MP > support. This diff survived a full build on my Firefly-RK3399 board. > It also seems to work on the Overdrive 1000. It might even work on > the Raspberry Pi 3. I'd appreciate it if people could play with this > on the Raspberry Pi and other arm64 hardware they have. > > I tried to follow a strategy for making the pmap "mpsafe" that more > closely resembles what we did for our other architectures, although I > looked at Dale Rahn's diff as well. It seems I fixed at least some > bugs in the process. But I'm sure there are bugs remaining. I may > even have introduced new ones. So do expect this to crash and burn, > or at least lock up. > > I'm also interested in people testing the normal GENERIC kernel with > this diff, especially building ports. There are some changes in there > that could affect non-MP as well. FYI, GENERIC.MP and GENERIC built from src both work fine on the Olimex A64. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: manpage text width
On Fri, Mar 30, 2018 at 01:57:43AM +0200, Ingo Schwarze wrote: > Hi Paul, > > Theo de Raadt wrote on Thu, Mar 29, 2018 at 04:17:14PM -0600: > > piroft@ wrote: > > >> Is there any reason why manpage text does not resize nicely > >> with <80 columns xterms? > > I want to avoid excessive magic. > > By the way, actually, the default width is 78, not 80. > By tradition. > > >> Is it because of less(1)? > > No. less(1) always wraps and re-wraps its input file to fit the > terminal width. Of course, it preserves existing line breaks, it > only adds new ones, and it adds the new ones after the last character > that fits on each line, possibly in the middle of words and numbers. > > > Can I do anything to fix this? > > Yes. > > When you want a manpage to exactly fill the available terminal width, > you can use an alias like this: > > $ alias wman='man -Owidth=$COLUMNS'# or > $ alias wman='man -Owidth=$((COLUMNS-2))' > > Of course, if you change the terminal width while man(1) is open, > you will have to do: q Ctrl-p to reformat. > > I do *NOT* want to add SIGWINCH signal handling to man(1) to abort > less(1), reformat, and respawn less(1) in that case. That kind of > magic would be over the top, and SIGWINCH is an abomination in the > first place. > > If you are in the habit of always using 65-column terminals on a given > machine, this is another option: > > # echo output width 64 >> /etc/man.conf > > I *could* maybe teach man(1) to honour $COLUMN by default when > starting up in interactive mode, but i did not do so for the following > reasons: > > * Many people are using terminals wider than 80 columns, but >texts get hard to read when much wider than that. Very long >lines become hard to follow. (That's why newspapers usually >have columns of even less than 80 characters, but they don't >have as much indentation as manual pages either.) I'm not asking for this feature but CSS has max-width for cases like this in HTML. It always fills the width until the maximum. > * Nowadays, i guess that terminals narrower than 80 columns >have become seriously rare, so there is not very widespread >benefit for that case. > * Even if someone does use a narrower terminal, formatting will >be somewhat poor with the matching -Owidth. Some text, in >particular literal displays, will still overflow and wrap in >less(1), and text with large indentations will become >ridiculously narrow. >One thing jmc@ does is trying to make sure that pages do not >only read well, but also look visually nice, and much of that >work is optimized for the default -Owidth=78. >So even for narrower terminals, i'd rather leave the decision >to the user. > * Setting up an alias as explained above is quite easy. > > What i could maybe do is recognize "-Owidth=auto" and "output width > auto" in man.conf(5) and use $COLUMNS in that case, but even that > would require some additional code, and so far, i didn't notice > much demand. > > > It is pre-formatted. > > Only in the sense than man(1) completes the formatting before it > forks and executes less(1). Only the manual pages of 25 (out of > 9900) ports are still preformatted at port build time, and none in > the base system and Xenocara are preformatted at system build time. > > Yours, > Ingo > -- Juan Francisco Cantero Hurtado http://juanfra.info
bwfm: kernel panic with a LG AN-WF500 (BCM43242)
Hi, I bought a LG AN-WF500 wifi adapter and I'm trying to use it on OpenBSD with the driver bwfm. The driver supports the chipset BCM43242 but doesn't have the IDs for the adapter. I tried to add the IDs to the driver (patch at the end of the mail) but the kernel detects three devices and panics when tries to initialize the first one. Sorry, I only have a photo of the panic: https://juanfra.info/t/panic_bwfm_1.png I'm not sure what the problem is but maybe the driver is trying to initialize the wrong device. I don't know how to make the driver skips the first device and try the others, so if you can help with it or have a better idea... The adapter is fullmac and works on Linux with the broadcom driver. This is the output of "lsusb -v" from Linux and looks like the wifi chip is the third device: Bus 001 Device 003: ID 043e:3101 LG Electronics USA, Inc. AN-WF500 802.11abgn + BT Wireless Adapter [Broadcom BCM43242] Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 bDeviceProtocol 1 Interface Association bMaxPacketSize064 idVendor 0x043e LG Electronics USA, Inc. idProduct 0x3101 AN-WF500 802.11abgn + BT Wireless Adapter [Broadcom BCM43242] bcdDevice0.01 iManufacturer 1 Broadcom iProduct4 Composite Wireless Adapter iSerial 3 13597 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x005d bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Association: bLength 8 bDescriptorType11 bFirstInterface 0 bInterfaceCount 2 bFunctionClass224 Wireless bFunctionSubClass 1 Radio Frequency bFunctionProtocol 1 Bluetooth iFunction 5 Bluetooth MI Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 6 Bluetooth Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0010 1x 16 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 224 Wireless bInterfaceSubClass 1 Radio Frequency bInterfaceProtocol 1 Bluetooth iInterface 6 Bluetooth Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x0014 1x 20 bytes bInterval 8 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes1 Transfer TypeIsochronous Synch Type None Usage Type Data wMaxPacketSize 0x0014 1x 20 bytes bInterval 8 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass
Simple test case for performance oriented changes
Just a little note for people working on performance. Recently, the go devs found that their CI jobs on OpenBSD were running twice as slow as other OS. It launches a lot of threads and processes, and some parts are really hard with the system. I think that this could be useful for people looking for simple test cases for their performance oriented changes in addition to the usual bulks and build of releases. It's showing a 14% decrease in the build time compared with 6.4. $ cd /usr/ports/lang/go $ make configure $ time make <- this is quick $ time make test Cheers. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: athn(4): enable more calibration
On Wed, Jan 30, 2019 at 05:07:37PM +0800, Kevin Lo wrote: > On Tue, Jan 29, 2019 at 09:11:42PM +0100, Stefan Sperling wrote: > > > > The diff below enables periodic ADC/IQ calibration on athn(4) devices. > > Without this calibration athn devices might perform suboptimally > > as they warm up during operation. > > > > The code is already there, it was just not being called yet. > > I don't know why it was left disabled but it seems to cause no harm on > > my access points, though it doesn't make any notable difference either. > > > > I would like to get some test reports to see whether enabling > > calibration causes problems or behaviour changes for anyone. > > No problem here. > > athn0 at uhub0 port 4 configuration 1 interface 0 "ATHEROS USB2.0 WLAN" rev > 2.00/1.08 addr 3 > athn0: AR9271 rev 1 (1T1R), ROM rev 13, address d8:5d:4c:xx:xx:xx Works for me too. Same chipset. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: athn(4) noisefloor calibration
On Thu, Jan 31, 2019 at 04:30:30PM +0100, Stefan Sperling wrote: > On Thu, Jan 31, 2019 at 03:32:05PM +0100, Stefan Sperling wrote: > > This diff completes noisefloor calibration code in our athn(4) driver. > > Update default/min/max noisefloor values to those used by Linux. > > > > Tested on AR9280 on 2GHz and 5Ghz. Further tests are appreciated. > > jmc@ found out the hard way that my previous diff broke association > to other APs. Fixed in this version. Works for me with an AR9271. I don't see differences. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: acpithinkpad: fix brightness keys, keyboard backlight value
On Tue, Mar 05, 2019 at 02:03:13PM -0600, joshua stein wrote: > Here we go again... > > On at least the ThinkPad X1C6, the screen brightness keys (F5 and > F6) do not work and "wsconsctl keyboard.backlight" doesn't report > the correct value when the keyboard backlight is adjusted with > Fn+Space. > > These are both caused by the default event mask not including these > events, so explicitly enable them. > > But then acpithinkpad has to actually do something for the screen > brightness keys, but it tries the very old CMOS method which doesn't > work on these newer machines[0]. So make it use the ACPI method. > > I renamed thinkpad_[gs]et_backlight to thinkpad_[gs]et_kbd_backlight > because it was confusing that they have nothing to do with screen > backlight. > > > 0. "newer machines" being those with MHKV reporting version 2. If > this diff breaks on older "newer machines", this metric will have to > be changed to something else. The brightness keys on the X61s still work fine. -- Juan Francisco Cantero Hurtado http://juanfra.info
grep ".one\|.two" doesn't work on OpenBSD. Is it expected?
I've a test in one of my ports similar to this: $ cat test.txt $TESTTMP/hgcache/master/packs/7bcd2d90b99395ca43172a0dd24e18860b2902f9.histpack $TESTTMP/hgcache/master/packs/dc8f8fdc76690ce27791ce9f53a18da379e50d37.datapack $ cat test.txt | grep ".datapack\|.histpack" $ cat test.txt | ggrep ".datapack\|.histpack" $TESTTMP/hgcache/master/packs/7bcd2d90b99395ca43172a0dd24e18860b2902f9.histpack $TESTTMP/hgcache/master/packs/dc8f8fdc76690ce27791ce9f53a18da379e50d37.datapack The grep command works with GNU, NetBSD, FreeBSD and BusyBox. It fails on OpenBSD and Solaris 11. I'm suggesting upstream to change the command to "grep -e ".datapack" -e ".histpack"" but I would like to know if this is a bug or we just don't support the | in the grep patterns. Cheers. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: grep ".one\|.two" doesn't work on OpenBSD. Is it expected?
On Mon, May 20, 2019 at 01:22:21PM -0600, Todd C. Miller wrote: > On Mon, 20 May 2019 20:01:12 +0200, Juan Francisco Cantero Hurtado wrote: > > > The grep command works with GNU, NetBSD, FreeBSD and BusyBox. It fails > > on OpenBSD and Solaris 11. I'm suggesting upstream to change the command > > to "grep -e ".datapack" -e ".histpack"" but I would like to know if this > > is a bug or we just don't support the | in the grep patterns. > > That's GNU regexp format, not POSIX. The standard way to do this > is with an extended regular expression using egrep. E.g. > > cat test.txt | egrep ".datapack|.histpack" > > though you should escape the '.' if you want it to match literally. Yes, that worked. Many thanks for the help guys. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Firefox, malloc(3) and threads
On Mon, Jan 25, 2016 at 10:06:22AM +0100, David Coppa wrote: > On Sun, Jan 24, 2016 at 7:47 PM, Adam Wolk wrote: > > On Fri, 22 Jan 2016 22:46:39 +0100 (CET) > > Mark Kettenis wrote: > > > >> Firefox makes a lot of concurrent malloc(3) calls. The locking to > >> make malloc(3) thread-safe is a bit...suboptimal. This diff makes > >> things better by using a mutex instead of spinlock. If you're running > >> Firefox you want to try it; it makes video watchable on some machines. > >> If you're not running Firefox you want to try it; to make sure it > >> doesn't break things. > >> > >> Enjoy, > >> > >> Mark > >> ' > > > > Applied to a Jan 15h snapshot sources. Youtube is not fully 'watchable' > > on firefox but feels significantly better. I can also now watch full > > screen youtube videos on chromium 1920x1080 with no stutter (lenovo > > g50-70). > > > > Generally gnome 3 feels a bit snappier especially on first load, > > bringing up the menu searching for 'terminal' leads to a faster > > rendering of the results. This might be just 'imagined' by me. > > > > On a more measurable front. I ran the octane benchmark against firefox > > post and before the patch. It resulted in a slight improvement from > > 12486 to 12826 score [1]. > > Besides performance related issues, the problem we saw in the past was > firefox using a huge amount of CPU resources with no apparent > reasons... I've seen the same behavior on Linux. Probably not 100% related to the OS. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: New scheduler for OpenBSD
7;t run much recently, and to round-robin among other
> - * processes.
> - */
> -void
> -schedclock(struct proc *p)
> -{
> - int s;
> -
> - SCHED_LOCK(s);
> - p->p_estcpu = ESTCPULIM(p->p_estcpu + 1);
> - resetpriority(p);
> - if (p->p_priority >= PUSER)
> - p->p_priority = p->p_usrpri;
> - SCHED_UNLOCK(s);
> }
>
> void (*cpu_setperf)(int);
> Index: sys/sys/proc.h
> ===
> RCS file: /cvs/src/sys/sys/proc.h,v
> retrieving revision 1.217
> diff -u -p -r1.217 proc.h
> --- sys/sys/proc.h9 Mar 2016 13:38:50 -0000 1.217
> +++ sys/sys/proc.h12 Mar 2016 15:48:37 -
> @@ -44,6 +44,7 @@
> #include /* For struct selinfo */
> #include/* For LOGIN_NAME_MAX */
> #include
> +#include
> #include /* For struct timeout */
> #include/* For struct klist */
> #include/* For struct mutex */
> @@ -267,6 +268,7 @@ struct process {
>
> struct proc {
> TAILQ_ENTRY(proc) p_runq;
> + RB_ENTRY(proc) p_runq2;
> LIST_ENTRY(proc) p_list;/* List of all threads. */
>
> struct process *p_p; /* The process of this thread. */
> @@ -320,6 +322,8 @@ struct proc {
>
> /* The following fields are all copied upon creation in fork. */
> #define p_startcopy p_sigmask
> + u_int64_t p_deadline;
> + int p_rrticks;
> sigset_t p_sigmask; /* Current signal mask. */
>
> u_char p_priority; /* Process priority. */
> @@ -488,6 +492,7 @@ void fixjobc(struct process *, struct pg
> int inferior(struct process *, struct process *);
> void leavepgrp(struct process *);
> void preempt(struct proc *);
> +void sched_deadline(struct proc *);
> void pgdelete(struct pgrp *);
> void procinit(void);
> void resetpriority(struct proc *);
> @@ -570,4 +575,3 @@ struct cpu_info *cpuset_first(struct cpu
>
> #endif /* _KERNEL */
> #endif /* !_SYS_PROC_H_ */
> -
> Index: sys/sys/sched.h
> ===
> RCS file: /cvs/src/sys/sys/sched.h,v
> retrieving revision 1.40
> diff -u -p -r1.40 sched.h
> --- sys/sys/sched.h 9 Mar 2016 13:38:50 - 1.40
> +++ sys/sys/sched.h 12 Mar 2016 15:48:37 -
> @@ -70,6 +70,7 @@
> #define _SYS_SCHED_H_
>
> #include
> +#include
>
> /*
> * Posix defines a which may want to include
> @@ -99,6 +100,7 @@ struct schedstate_percpu {
> u_int spc_schedticks; /* ticks for schedclock() */
> u_int64_t spc_cp_time[CPUSTATES]; /* CPU state statistics */
> u_char spc_curpriority; /* usrpri of curproc */
> + u_int64_t spc_curdeadline;
> int spc_rrticks;/* ticks until roundrobin() */
> int spc_pscnt; /* prof/stat counter */
> int spc_psdiv; /* prof/stat divisor */
> @@ -109,6 +111,8 @@ struct schedstate_percpu {
>
> TAILQ_HEAD(prochead, proc) spc_qs[SCHED_NQS];
> volatile uint32_t spc_whichqs;
> +
> + RB_HEAD(prochead2, proc) spc_rq;
>
> #ifdef notyet
> struct proc *spc_reaper;/* dead proc reaper */
> --
> Michal Mazurek
>
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: New scheduler for OpenBSD
On Sat, Mar 12, 2016 at 08:35:31PM +0100, Juan Francisco Cantero Hurtado wrote: > On Sat, Mar 12, 2016 at 05:36:21PM +0100, Michal Mazurek wrote: > > Gregor Best attempted to improve the scheduler in 2011: > > http://comments.gmane.org/gmane.os.openbsd.tech/27059 > > Here is another attempt, it takes up where the previous one left off. > > > > This is also mostly based on the main idea behind Linux CFS or > > BFS. I found BFS to be described more clearly: > > http://ck.kolivas.org/patches/bfs/4.0/4.3/4.3-sched-bfs-467.patch > > > > > > Some notes: > > > > Chrome is still not very usable. > > Chrome is not the best benchmark for the scheduler ATM. > > Until the work in malloc to enhance the support for multithreaded > programs is finished, forget Chrome and Firefox. > > > > > Much more work is needed, e.g. there is some MD code on sparc64 and > > alpha that depends on spc_schedticks that needs to be understood and > > rewritten. > > > > Maybe using RB trees to queue what is usually no more than 5 elements > > is overkill. > > > > p_usrpri and p_priority will go away, so userland utilities like 'ps' > > will need to be changed. > > > > I also want to try and see if implementing one shared queue, instead of > > keeping one queue per cpu will improve performance even further. Right > > now there are some heuristics to determine whether a process should > > switch cpus. This doesn't work very well yet, in my tests with the > > attached code sometimes one queue was a second behind another. From > > what I understand that's the idea behind BFS and the reason why it > > doesn't scale to 4096 CPUs. I see that OpenBSD supports 256 CPUs on > > sparc64: > > ./arch/sparc64/include/cpu.h:#define MAXCPUS256 > > > > Nice is not yet supported, but it's easy to add (uncomment and modify > > 'offset' in sched_deadline(). I didn't want to add it yet to test just > > how fair this method is. Currently all processes are equal. > > > > Other operating systems provide a couple of different schedulers to > > choose from, this diff overwrites the 4bsd scheduler with the new code > > and leaves no choice. > > > > With the new code I got some visible improvements when compiling the > > kernel: > > old: 1m46.74s real 5m08.48s user 1m27.37s system > > old: 1m46.61s real 5m06.93s user 1m28.13s system > > old: 1m49.91s real 5m19.71s user 1m28.25s system > > new: 1m38.05s real 5m12.16s user 0m55.86s system > > new: 1m38.70s real 5m12.36s user 0m57.82s system > > new: 1m39.10s real 5m16.06s user 0m56.91s system > > That is going to make happy to people running bulk builds :) > > > > > I would be interested in hearing if the new code broke something for > > anyone. > > > > Is there a chance for a scheduler rewrite like this to be commited? >From time to time, I run a batch video conversion. I tried the same commands with and without your patch. Your patch is slowing down the frames-per-second about 30%. Here are the commands: $ download some 20-30 minutes videos in mp4 format (youtube is fine for this) $ install the packages ffmpeg and libx264 $ mkdir output $ for i in *.mp4; do ffmpeg -y -i "$i" -vf 'scale=320:-1' -map 0:v:0 -map 0:a:0 -sws_flags spline -map_metadata -1 -c:v libx264 -profile:v baseline -b:v 360k -c:a aac -strict -2 -ar 44100 -ac 2 -b:a 128k -movflags faststart "output/$i"; done -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: malloc: 1st small step in long way to multiple pools
On Wed, Mar 09, 2016 at 10:06:15AM +0100, Otto Moerbeek wrote: > Hi, > > a future goal for malloc is to use multiple pools in threaded environments, > to reduce lock contention. > > This is a small first step towards that goal: move two globals to the > pool-specific struct dir_info. Currently there's only a single pool, > but that will change one day. > > Lightly tested by myself on amd64, you can help by reviewing and > testing this. I don't see regressions on amd64. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Scheduler hack for multi-threaded processes
On Sat, Mar 19, 2016 at 01:53:07PM +0100, Martin Pieuchot wrote: > Applications using multiple threads often call sched_yield(2) to > indicate that one of the threads cannot make any progress because > it is waiting for a resource held by another one. > > One example of this scenario is the _spinlock() implementation of > our librthread. But if you look on https://codesearch.debian.net > you can find much more use cases, notably MySQL, PostgreSQL, JDK, > libreoffice, etc. > > Now the problem with our current scheduler is that the priority of > a thread decreases when it is the "curproc" of a CPU. So the threads > that don't run and sched_yield(2) end up having a higher priority than > the thread holding the resource. Which means that it's really hard for > such multi-threaded applications to make progress, resulting in a lot of > IPIs numbers. > That'd also explain why if you have a more CPUs, let's say 4 instead > of 2, your application will more likely make some progress and you'll > see less sluttering/freezing. > > So what the diff below does is that it penalizes the threads from > multi-threaded applications such that progress can be made. It is > inspired from the recent scheduler work done by Michal Mazurek on > tech@. > > I experimented with various values for "p_priority" and this one is > the one that generates fewer # IPIs when watching a HD video on firefox. > Because yes, with this diff, now I can. > > I'd like to know if dereferencing ``p_p'' is safe without holding the > KERNEL_LOCK. > > I'm also interested in hearing from more people using multi-threaded > applications. In the ffmpeg test case, the frames-per-second increased 25%. The only modification in the kernel was your patch. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: New scheduler for OpenBSD
On Tue, Mar 15, 2016 at 03:05:47PM +0100, Michal Mazurek wrote: > On 16:28:33, 14.03.16, Martin Pieuchot wrote: > > > The number of calls to yield() dropped to 4,576. > > > > This is really similar to what I observed with Firefox and Chrome. > > > > > This is where I get stuck, I don't know how to replace the call to > > > sched_yield(), or whether it is a good idea to do so. Any advice? > > > > I'd assume the problem is not in the _spinlock() implementation itself > > but rather on the code calling this lock. Do you know which code is > > triggering this? > > > > See r1.13 of lib/librthread/rthread_libc.c, this is an example where a > > the use of a spinlock created similar symptoms. > > I don't know how to fix it, but in the meanwhile here is a workaround so > I can continue working on the scheduler. In yield(): > > + tmp = p->p_rrticks; > + sched_deadline(p); > + p->p_rrticks = tmp; > > So penalise a process calling yield() by giving it the worst deadline, > i.e. make it go to the end of the run queue. > > Other than this, no changes. > > Chrome still isn't smooth. > > Please test, and let me know if the performance of something else > degrades. The performance in the ffmpeg test has increased about 30-40% compared with the default scheduler. Please keep working on it. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: multi-pool malloc wip diff
On Mon, Mar 28, 2016 at 11:27:32AM +0200, Otto Moerbeek wrote: > On Wed, Mar 23, 2016 at 08:00:19AM +0100, Otto Moerbeek wrote: > > > Hi, > > > > first diff that seems to work. Tested on amd64 and compile tested on > > sparc64. > > > > It is alo available at http://www.drijf.net/openbsd/malloc > > > > Form the README: > > > > The diff should be applied while in /usr/src/lib, it will patch > > both librthreads as as well as libc. > > > > THIS IS WORK IN PROGRESS. It contains multiple things that should > > be improved. To name a few things: > > > > - Curently fixed at 4 pools with a fixed thread -> pool mapping. > > - All pools are always initialized, even for single threaded programs, where > > only one pool is used. > > - Especially realloc gets quite a bit uglier. > > - I'm pondering storing the thread -> pool mapping in the thread > > struct instead of computing it each time from the tcb address. > > > > -Otto > > > > Second diff. Only one person (Stefan Kempf, thanks!) gave feedback... > > A race condition was fixed in the init code. But there remain race > problems in the init code. I will be working on that the coming time. > > Please be aware that to make this code ready for commit, I need > feedback/tests/reviews. There's no way this code will end up in the tree > without those. I don't see regressions on amd64. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: armv7 sunxi i2c+pmic(=shutdown -p)
On Sun, Jul 09, 2017 at 08:34:29PM +0300, Artturi Alm wrote: > Hi, > > revived the diff below, i2c tested via pmic's shutdown(), for working > "shutdown -p now" operation. > there was only two i2c's w/"status: 'okay'" in the FDT, so not all of > them do attach. > > related part of dmesg: > > com0: console > sxitwi0 at simplebus0 > iic0 at sxitwi0 > axppmic0 at iic0 addr 0x34: AXP209, ACIN > sxitwi1 at simplebus0 > iic1 at sxitwi1 > dwge0 at simplebus0 > > Comments? With the patch, "halt -p" works on the LIME2. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: sendbug subject
On Sun, May 15, 2016 at 06:43:16PM +0200, Jeremie Courreges-Anglas wrote: > "Ted Unangst" writes: > > > i'm tired of seeing bug reports with no subject. i also get a fair bit of > > spam > > with no subject and i am easily confused. something is better than nothing. > > I fear that after that change all bug reports will only have [bug > report] as Subject. Something that wouldn't catch the eye of people > that might be able to understand and fix the problem. How about this? hw.machine + kern.osrelease + hw.product [sendbug] macppc 6.0 PowerBook5,2 -- Juan Francisco Cantero Hurtado http://juanfra.info
macppc: ld: a.out: Not enough room for program headers (allocated 12, need 13)
I've updated my powerbook to the latest snapshot today. I can't build a
simple C program with the option -Wl,-z,wxneeded. The linker always
shows the same error.
# gcc test.c
# gcc -Wl,-z,wxneeded test.c
/usr/bin/ld: a.out: Not enough room for program headers (allocated 12, need 13)
Section to Segment mapping:
Segment Sections...
00: PHDR:
01: INTERP: .interp
02: LOAD: .interp .note.openbsd.ident .hash .dynsym .dynstr
.rela.dyn .rela.plt .init .text .fini
03: LOAD: .eh_frame
04: LOAD: .openbsd.randomdata .jcr .dynamic .data
05: LOAD: .got .ctors .dtors
06: LOAD: .sdata
07: LOAD: .plt
08: LOAD: .bss
09:DYNAMIC: .dynamic
10: NOTE: .note.openbsd.ident
11: OPENBSD_WXNEED:
12: OPENBSD_RANDOM: .openbsd.randomdata
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
# cat test.c
int main() { return 0; }
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: macppc: ld: a.out: Not enough room for program headers (allocated 12, need 13)
On Mon, Jul 25, 2016 at 05:30:47PM -0700, Philip Guenther wrote:
> On Tue, 26 Jul 2016, Juan Francisco Cantero Hurtado wrote:
> > I've updated my powerbook to the latest snapshot today. I can't build a
> > simple C program with the option -Wl,-z,wxneeded. The linker always
> > shows the same error.
> >
> > # gcc test.c
> > # gcc -Wl,-z,wxneeded test.c
> > /usr/bin/ld: a.out: Not enough room for program headers (allocated 12, need
> > 13)
> ...
> > /usr/bin/ld: final link failed: Bad value
> > collect2: ld returned 1 exit status
>
> I think this solves it, or at least it does on my macppc.
Your patch fixes the problem. Thanks!
> Index: bfd/elf.c
> ===
> RCS file: /data/src/openbsd/src/gnu/usr.bin/binutils-2.17/bfd/elf.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 elf.c
> --- bfd/elf.c 31 May 2016 17:05:03 - 1.9
> +++ bfd/elf.c 26 Jul 2016 00:26:04 -
> @@ -4731,6 +4731,12 @@ get_program_header_size (bfd *abfd)
>++segs;
> }
>
> + if (elf_tdata (abfd)->wxneeded)
> +{
> + /* We need a PT_OPENBSD_WXNEEDED segment. */
> + ++segs;
> + }
> +
> for (s = abfd->sections; s != NULL; s = s->next)
> {
>if ((s->flags & SEC_LOAD) != 0
>
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: iwm driver in latest snapshot has terrible performance
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 > azalia1 at pci0 dev 27 function 0 "Intel 8 Series HD Audio" rev 0x04: msi > azalia1: codecs: Realtek/0x0286 > audio0 at azalia1 > ppb0 at pci0 dev 28 function 0 "Intel 8 Series PCIE" rev 0xe4: msi > pci1 at ppb0 bus 1 > iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0x6b, > msi > ehci0 at pci0 dev 29 function 0 "Intel 8 Series USB" rev 0x04: apic 2 int 23 > usb1 at ehci0: USB revision 2.0 > uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 > pcib0 at pci0 dev 31 function 0 "Intel 8 Series LPC" rev 0x04 > ahci0 at pci0 dev 31 function 2 "Intel 8 Series AHCI" rev 0x04: msi, AHCI > 1.3 > ahci0: port 3: 6.0Gb/s > scsibus1 at ahci0: 32 targets > sd0 at scsibus1 targ 3 lun 0: SCSI3 0/direct > fixed naa.5002538d409a291f > sd0: 238475MB, 512 bytes/sector, 488397168 sectors, thin > ichiic0 at pci0 dev 31 function 3 "Intel 8 Series SMBus" rev 0x04: apic 2 > int 18 > iic0 at ichiic0 > isa0 at pcib0 > isadma0 at isa0 > pckbc0 at isa0 port 0x60/5 irq 1 irq 12 > pckbd0 at pckbc0 (kbd slot) > wskbd0 at pckbd0: console keyboard, using wsdisplay0 > pms0 at pckbc0 (aux slot) > wsmouse0 at pms0 mux 0 > pms0: Synaptics clickpad, firmware 8.1 > pcppi0 at isa0 port 0x61 > spkr0 at pcppi0 > efifb at mainbus0 not configured > error: [drm:pid0:intel_uncore_check_errors] *ERROR* Unclaimed register > before interrupt > uhidev0 at uhub0 port 3 configuration 1 interface 0 "eGalax Inc. eGalaxTouch > EXC7910-1032-11.00.00" rev 2.00/32.02 addr 2 > uhidev0: iclass 3/1, 7 report ids > uhid0 at uhidev0 reportid 3: input=63, output=63, feature=0 > uhid1 at uhidev0 reportid 5: input=0, output=0, feature=2 > ums0 at uhidev0 reportid 6: 1 button, tip > wsmouse1 at ums0 mux 0 > ums1 at uhidev0 reportid 7 > ums1: mouse has no X report > uvideo0 at uhub0 port 5 configuration 1 interface 0 "93010GT00-289-G3878V0 > USB Webcam" rev 2.01/0.16 addr 3 > video0 at uvideo0 > ugen0 at uhub0 port 6 "Intel product 0x07dc" rev 2.00/0.01 addr 4 > uhub2 at uhub1 port 1 "Intel Rate Matching Hub" rev 2.00/0.04 addr 2 > vscsi0 at root > scsibus2 at vscsi0: 256 targets > softraid0 at root > scsibus3 at softraid0: 256 targets > sd1 at scsibus3 targ 1 lun 0: SCSI2 0/direct fixed > sd1: 112857MB, 512 bytes/sector, 231131697 sectors > root on sd1a (2785d9a9c0d8e738.a) swap on sd1b dump on sd1b > iwm0: hw rev 0x140, fw ver 16.242414.0, address 5c:51:4f:43:b5:c0 > axe0 at uhub0 port 2 configuration 1 interface 0 "ASIX Electronics AX88772" > rev 2.00/0.01 addr 5 > axe0: AX88772, address 00:50:b6:0d:64:44 > ukphy0 at axe0 phy 16: Generic IEEE 802.3u media interface, rev. 1: OUI > 0x000ec6, model 0x0006 > gnome-shell(54435): mmap W^X violation > gnome-shell(16831): mmap W^X violation > gjs-console(55763): mmap W^X violation > axe0: usb errors on rx: IOERROR > ukphy0 detached > axe0 detached > gjs-console(26806): mmap W^X violation > axe0 at uhub0 port 2 configuration 1 interface 0 "ASIX Electronics AX88772" > rev 2.00/0.01 addr 5 > axe0: AX88772, address 00:50:b6:0d:64:44 > ukphy0 at axe0 phy 16: Generic IEEE 802.3u media interface, rev. 1: OUI > 0x000ec6, model 0x0006 > gjs-console(85858): mmap W^X violation > -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: armv7 pmap fix for Cortex A53 (and Cortex A7?)
@@ void
> pmap_protect(pmap_t pm, vaddr_t sva, vaddr_t eva, vm_prot_t prot)
> {
> struct l2_bucket *l2b;
> - pt_entry_t *ptep, pte;
> + pt_entry_t *ptep, pte, opte;
> vaddr_t next_bucket;
> u_int flags;
> int flush;
> @@ -1782,19 +1777,19 @@ NPDEBUG(PDB_PROTECT, printf("\n"));
> ptep = &l2b->l2b_kva[l2pte_index(sva)];
>
> while (sva < next_bucket) {
> - pte = *ptep;
> + opte = *ptep;
> /* !!! not l2pte_valid */
> /* XXX actually would only matter if really valid ??? */
> - if (pte != 0 && l2pte_is_writeable(pte, pm)) {
> + if (opte != 0 && l2pte_is_writeable(opte, pm)) {
> struct vm_page *pg;
> u_int f;
>
> - pg = PHYS_TO_VM_PAGE(l2pte_pa(pte));
> + pg = PHYS_TO_VM_PAGE(l2pte_pa(opte));
> if (pg != NULL)
> pmap_clean_page(pg, FALSE);
> - pte = (pte & ~L2_S_PROT_MASK) |
> + pte = (opte & ~L2_S_PROT_MASK) |
> L2_S_PROT(pm == pmap_kernel() ? PTE_KERNEL
> : PTE_USER,
> - pte & L2_V7_S_XN ? PROT_READ : PROT_READ
> | PROT_EXEC);
> + opte & L2_V7_S_XN ? PROT_READ : PROT_READ
> | PROT_EXEC);
> *ptep = pte;
> PTE_SYNC(ptep);
>
> @@ -1802,15 +1797,16 @@ NPDEBUG(PDB_PROTECT, printf("\n"));
> f = pmap_modify_pv(pg, pm, sva,
> PVF_WRITE, 0);
> } else
> - f = PVF_REF | PVF_EXEC;
> + f = PVF_EXEC;
>
> if (flush >= 0) {
> flush++;
> - if (PV_BEEN_EXECD(f))
> - cpu_tlb_flushID_SE(sva);
> - else
> - if (PV_BEEN_REFD(f))
> - cpu_tlb_flushD_SE(sva);
> + if (l2pte_valid(opte)) {
> + if (PV_BEEN_EXECD(f))
> + cpu_tlb_flushID_SE(sva);
> + else
> + cpu_tlb_flushD_SE(sva);
> + }
> } else
> flags |= f;
> }
> @@ -1824,7 +1820,6 @@ NPDEBUG(PDB_PROTECT, printf("\n"));
> if (PV_BEEN_EXECD(flags))
> pmap_tlb_flushID(pm);
> else
> - if (PV_BEEN_REFD(flags))
> pmap_tlb_flushD(pm);
> }
> NPDEBUG(PDB_PROTECT, printf("\n"));
>
--
Juan Francisco Cantero Hurtado http://juanfra.info
PATCH: faq4.html edit the auto layout
It's surprising but many users don't know the "R" option. OK? The webpage with the patch applied: http://juanfra684.devio.us/tmp/faq4.html#InstDisks diff --git faq/faq4.html faq/faq4.html index 51606b3..f2b9486 100644 --- faq/faq4.html +++ faq/faq4.html @@ -946,15 +946,18 @@ The installer has presented us with its proposed "Auto layout" for OpenBSD partitions on our disk, which we are going to accept. -If the proposed layout is not appropriate for your needs, you can, -of course, edit the default or customize it completely, more details -on the disklabel partitioning below. +If the proposed layout is not appropriate for your needs, you can +(E)dit the sizes of the partitions with the R option in the +disklabel editor or customize it completely, more details on the disklabel +partitioning +below. NOTE for re-installers: The new installer will not clear your old disklabel if you chose -"(C)ustom Layout", but you will need to re-specify each mount point -using the 'm' option in disklabel(8). +(C)ustom Layout, but you will need to re-specify each mount point +using the m option in +http://www.openbsd.org/cgi-bin/man.cgi?query=disklabel&sektion=8";>disklabel(8). The installer now creates those partitions and creates file systems
pow() returns a negative result on loongson
Marc Feeley (Gambit Scheme) has been helping me with a bug on Gambit on
Loongson. Apparently the bug is on our side.
I've created this little test based on his code:
#include
#include
int main()
{
double x = 0.5;
double y = 1074.0;
printf("x=%.20g y=%.20g pow(x,y)=%.20g\n",x,y,pow(x,y));
return 0;
}
On OpenBSD/amd64, Linux/amd64, Linux/aarch64 and Linux/mips64:
x=0.5 y=1074 pow(x,y)=4.9406564584124654418e-324
On OpenBSD/loongson:
x=0.5 y=1074 pow(x,y)=-4.9406564584124654418e-324
Is the negative result expected?
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: pow() returns a negative result on loongson
On Tue, Oct 10, 2017 at 12:08:06PM +, Visa Hankala wrote:
> On Mon, Oct 09, 2017 at 10:39:47PM +0200, Juan Francisco Cantero Hurtado
> wrote:
> > Marc Feeley (Gambit Scheme) has been helping me with a bug on Gambit on
> > Loongson. Apparently the bug is on our side.
> >
> > I've created this little test based on his code:
> >
> > #include
> > #include
> >
> > int main()
> > {
> > double x = 0.5;
> > double y = 1074.0;
> > printf("x=%.20g y=%.20g pow(x,y)=%.20g\n",x,y,pow(x,y));
> > return 0;
> > }
> >
> > On OpenBSD/amd64, Linux/amd64, Linux/aarch64 and Linux/mips64:
> > x=0.5 y=1074 pow(x,y)=4.9406564584124654418e-324
> >
> > On OpenBSD/loongson:
> > x=0.5 y=1074 pow(x,y)=-4.9406564584124654418e-324
> >
> > Is the negative result expected?
>
> No. On mips64, ldexp(3) seems to use a garbage value when figuring out
> the sign of a denormal value. This applies to infinity values as well.
>
> The patch below should fix the bug. The t3 register contains the binary
> representation of the floating-point `x' parameter. I can also make
> a regression test for the patch.
>
> OK?
Works for me. Thanks for the quick fix.
>
> Index: arch/mips64/gen/ldexp.S
> ===
> RCS file: src/lib/libc/arch/mips64/gen/ldexp.S,v
> retrieving revision 1.7
> diff -u -p -r1.7 ldexp.S
> --- arch/mips64/gen/ldexp.S 27 Oct 2015 05:54:49 - 1.7
> +++ arch/mips64/gen/ldexp.S 10 Oct 2017 11:52:56 -
> @@ -143,20 +143,20 @@ LEAF(ldexp, 0)
> xorit2, 1
> 1:
> dmtc1 t2, $f0 # save denormalized result (LSW)
> - bge v1, zero, 1f# should result be negative?
> + bge t3, zero, 1f# should result be negative?
> neg.d $f0, $f0# negate result
> 1:
> j ra
> 7:
> dmtc1 zero, $f0 # result is zero
> - beq t0, zero, 1f# is result positive?
> + bge t3, zero, 1f# is result positive?
> neg.d $f0, $f0# negate result
> 1:
> j ra
> 8:
> dli t1, 0x7ff0 # result is infinity (MSW)
> dmtc1 t1, $f0
> - bge v1, zero, 1f# should result be negative infinity?
> + bge t3, zero, 1f# should result be negative infinity?
> neg.d $f0, $f0# result is negative infinity
> 1:
> add.d $f0, $f0# cause overflow faults if enabled
>
--
Juan Francisco Cantero Hurtado http://juanfra.info
Semi-OT: Paper about a new implementation of malloc
I was looking for something else and found this recent paper. They compare their implementation with the OpenBSD malloc. It's probably interesting for some of you. Paper: https://acmccs.github.io/papers/p2389-silvestroA.pdf Code: https://github.com/UTSASRG/FreeGuard -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: stack pointer checking
On Thu, Jan 11, 2018 at 08:39:25PM -0700, Theo de Raadt wrote: > Stefan (stefan@) and I have been working for a few months on this > diff, with help from a few others. > > At every trap and system call, it checks if the stack-pointer is on a > page that is marked MAP_STACK. execve() is changed to create such > mappings for the process stack. Also, libpthread is taught the new > MAP_STACK flag to use with mmap(). > > There is no corresponding system call which can set MAP_FLAG on an > existing page, you can only set the flag by mapping new memory into > place. That is a piece of the security model. > > The purpose of this change is to twart stack pivots, which apparently > have gained some popularity in JIT ROP attacks. It makes it difficult > to place the ROP stack in regular data memory, and then perform a > system call from it. Workarounds are cumbersome, increasing the need > for far more gadgetry. But also the trap case -- if any memory > experiences a demand page fault, the same check will occur and > potentially also kill the process. > > We have experimented a little with performing this check during device > interrupts, but there are some locking concerns and performance may > then become a concern. It'll be best to gain experience from handle > of syncronous trap cases first. > > chrome and other applications I use run fine! > > I'm asking for some feedback to discover what ports this breaks, we'd > like to know. Those would be ports which try to (unconvenionally) > create their stacks in malloc()'d memory or inside another > datastructure. Most of them are probably easily fixed ... racket passes the test suite. chibi-scheme and pypy run fine with a big factorial. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: 2D acceleration for Nvidia
On Sat, Dec 12, 2015 at 03:06:01AM +0100, Theo Buehler wrote:
> On Fri, Dec 11, 2015 at 10:09:20AM +0100, Martin Pieuchot wrote:
> > Without hardware acceleration my PowerBook G4 12'' with a NVIDIA
> > GeForce FX Go 5200 is unusable. Since XAA is no longer supported,
> > here's a simple EXA backend for nv(4) based on the XAA sources and
> > Nouveau. It only implements Solid and Copy but that already makes
> > a huge difference.
> >
> > To test it you need to regenerate configure scripts for xf86-video-nv
> > as described in /usr/xenocara/README.
> >
> > I can provide a diff for upstream it the driver is still maintained.
> >
> > I'd like to hear from people using NVidia cards.
> >
>
> This is quite an impressive improvement, thanks a lot! Full screen
> video becomes watchable. However, trying to move an xterm with the
> mouse still isn't fun.
Try this xorg.conf:
Section "Device"
Identifier "nvidia modesetting"
Driver "modesetting"
Option "HWCursor" "off"
EndSection
--
Juan Francisco Cantero Hurtado http://juanfra.info
Re: 2D acceleration for Nvidia
On Sun, Dec 13, 2015 at 08:53:19AM +0100, Theo Buehler wrote: > On Sun, Dec 13, 2015 at 01:57:02AM +0100, Juan Francisco Cantero Hurtado > wrote: > > On Sat, Dec 12, 2015 at 03:06:01AM +0100, Theo Buehler wrote: > > > On Fri, Dec 11, 2015 at 10:09:20AM +0100, Martin Pieuchot wrote: > > > > Without hardware acceleration my PowerBook G4 12'' with a NVIDIA > > > > GeForce FX Go 5200 is unusable. Since XAA is no longer supported, > > > > here's a simple EXA backend for nv(4) based on the XAA sources and > > > > Nouveau. It only implements Solid and Copy but that already makes > > > > a huge difference. > > > > > > > > To test it you need to regenerate configure scripts for xf86-video-nv > > > > as described in /usr/xenocara/README. > > > > > > > > I can provide a diff for upstream it the driver is still maintained. > > > > > > > > I'd like to hear from people using NVidia cards. > > > > > > > > > > This is quite an impressive improvement, thanks a lot! Full screen > > > video becomes watchable. However, trying to move an xterm with the > > > mouse still isn't fun. > > > > Try this xorg.conf: > > Section "Device" > > Identifier "nvidia modesetting" > > Driver "modesetting" > > Option "HWCursor" "off" > > EndSection > > Thanks for the suggestion, but putting this in a new file > /etc/X11/xorg.conf results in xdm refusing to start both on boot time > and with startx. I don't know anything about xorg.conf, so it may well > be that I'm missing something obvious. Here's the resulting Xorg.log Matthieu and Bryan are right. I was thinking that nv has kms support for old models. My bad. -- Juan Francisco Cantero Hurtado http://juanfra.info
What platforms grow the stack upwards?
I have not found a complete list with this information. Can someone tell me what OpenBSD platforms grow the stack upwards? Thanks. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: clang++ and a modern C++ library
On Sun, Nov 30, 2014 at 03:40:58PM -0800, Dave Huseby wrote:
>
> Status update...
>
> I've been working on porting Rust over to OpenBSD by building a Rust
> cross-compiler for Linux that can target i386-unknown-openbsd and
> x86_64-unknown-openbsd. The largest roadblock on OpenBSD is the lack
> of a more recent GNU linker (ld). I have tried the 2.17 linker in the
> source tree and it doesn't work. To catch everybody up, the rust
> compiler is built on LLVM and uses C++1x which requires a newer
> compiler. I started by using 4.8.3 on OpenBSD but the old linker
> isn't working.
>
> Somebody suggested using clang on OpenBSD, but it appears that the
> port for clang++ doesn't include libc++. Is that correct? So clang++
> doesn't have a new enough standard C++ library to do the job. I've
> tried using clang++ with the libstdc++ that is part of the gcc 4.8.3
> port but I can't seem to figure out the magic set of parameters to
> clang++ to make it select the newer libstdc++ that is part of the gcc
> 4.8.3 port.
>
> I'm starting to think that this may not be possible without some
> catching up on toolchains for OpenBSD. And given the conservative
> nature of OpenBSD, it may be some time before the toolchains are
> "modern" enough to compile and link the Rust compiler.
Disclaimer: I know nothing about c++ :)
I used this program to test clang and c++11 (extracted from
https://solarianprogrammer.com/2013/01/17/building-clang-libcpp-ubuntu-linux/ ):
//Program to test the new C++11 regular expressions syntax
#include
#include
#include
using namespace std;
int main()
{
string input;
regex
rr("((\\+|-)?[[:digit:]]+)(\\.(([[:digit:]]+)?))?((e|E)((\\+|-)?)[[:digit:]]+)?");
//As long as the input is correct ask for another number
while(true)
{
cout<<"Give me a real number!"<>input;
if(!cin) break;
//Exit when the user inputs q
if(input=="q")
break;
if(regex_match(input,rr))
cout<<"float"
Re: Ralink (MediaTek) MT7650 / MT7610 usb stick problem with run(4) driver
On Sat, Mar 25, 2017 at 12:47:47AM +0900, Stefan Sperling wrote: > On Thu, Mar 23, 2017 at 07:42:13PM +0300, Denis wrote: > > Having trouble with TP-LINK AC600 Archer T2UH based on Ralink's MT7650 > > chipset with run driver on OpenBSD 6.0-stable with all the latest source > > tree patches installed. > > Our run(4) driver does not yet support this chipset. Additional changes are > needed to make it work. If you can figure out what else is needed and manage > to make it work, please send a patch. > I've an adapter with the same chipset and it's quite good. Linux has an independent driver only for the MT7601U, so the changes to run(4) is not going to be just a few lines. Denis, for reference: https://github.com/torvalds/linux/tree/master/drivers/net/wireless/mediatek/mt7601u -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Emulated TLS for clang
On Sun, May 07, 2017 at 05:37:47PM +0200, Mark Kettenis wrote: > So this enables the code. It makes -femulated-tls the default, > otherwise it will generated TLS relocations that we can't handle yet. > It is possible to specify -fno-emulated-tls if you really want to > generate those. > > A trivial example program that modifies the variable in one thread and > prints it in another seems to work as expected. > > Note that the libcompiler_rt implementation unconditionally references > some symbols in libpthread. So linking with -lpthread is mandatory. > GCC 4.9 uses weak references, so -lpthread isn't needed there. > > Perhaps those functions should move to libc. Or we can make the > libcompiler_rt code a bit smarter. > > Also note that the libcompiler_rt implementation offers the choice > between posix_memalign() and normal malloc(). With this diff it uses > malloc(). Perhaps otto@ has an opinion what's better here? lang/racket-minimal builds and passes the tests (which includes tests for the TLS related functionality). -- Juan Francisco Cantero Hurtado http://juanfra.info
OpenBSD base doesn't build on ARMv7
Hi, I've been seeing the same error for weeks: ===> gnu/usr.bin/cc/libgcc Using undefined dynamic variable $* (line 0 of (null)) Using undefined dynamic variable $* (line 0 of (null)) /usr/src/gnu/usr.bin/cc/libgcc/obj/../cc/cc -B /usr/src/gnu/usr.bin/cc/libgcc/obj/../cc1 -O2 -pipe -g -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/include -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc -I. -I/usr/src/gnu/usr.bin/cc/libgcc/../cc_tools -Dinhibit_libc -fno-inline -DIN_GCC -DHAVE_CONFIG_H -DPREFIX="/usr" -I/usr/src/gnu/usr.bin/cc/libgcc/obj/../cc_tools -I/usr/src/gnu/usr.bin/cc/libgcc/../cc_tools -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/include -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/libcpp/include -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/libdecnumber-c /usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config/floatunsidf.c -o floatunsidf.o /usr/src/gnu/usr.bin/cc/libgcc/obj/../cc/cc -B /usr/src/gnu/usr.bin/cc/libgcc/obj/../cc1 -O2 -pipe -g -DIN_GCC -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/include -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc -I. -I/usr/src/gnu/usr.bin/cc/libgcc/../cc_tools -Dinhibit_libc -fno-inline -DIN_GCC -DHAVE_CONFIG_H -DPREFIX="/usr" -I/usr/src/gnu/usr.bin/cc/libgcc/obj/../cc_tools -I/usr/src/gnu/usr.bin/cc/libgcc/../cc_tools -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/include -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/libcpp/include -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/libdecnumber-c /usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config/floatunsisf.c -o floatunsisf.o make: don't know how to make .vis (prerequisite of: _bb_init_func.o _dvmd_tls.o) Stop in gnu/usr.bin/cc/libgcc *** Error 2 in gnu/usr.bin/cc (:48 'all') *** Error 2 in gnu/usr.bin (:48 'all') *** Error 2 in gnu (:48 'all') *** Error 2 in . (:48 'all') *** Error 2 in /usr/src (Makefile:89 'build') Any idea? The full log is here (ignore the messages in spanish, I use a script to compile the base): http://juanfra.info/bl/openbsd-arm-201312/error_base.log -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: OpenBSD base doesn't build on ARMv7
On Wed, Dec 25, 2013 at 10:56:59PM -0500, Nick Holland wrote: > On 12/25/13 19:08, Juan Francisco Cantero Hurtado wrote: > > Hi, I've been seeing the same error for weeks: > > > > ===> gnu/usr.bin/cc/libgcc > > Using undefined dynamic variable $* (line 0 of (null)) > > Using undefined dynamic variable $* (line 0 of (null)) > > /usr/src/gnu/usr.bin/cc/libgcc/obj/../cc/cc -B > > /usr/src/gnu/usr.bin/cc/libgcc/obj/../cc1 -O2 -pipe -g -DIN_GCC > > -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/include > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc -I. > > -I/usr/src/gnu/usr.bin/cc/libgcc/../cc_tools -Dinhibit_libc -fno-inline > > -DIN_GCC -DHAVE_CONFIG_H -DPREFIX="/usr" > > -I/usr/src/gnu/usr.bin/cc/libgcc/obj/../cc_tools > > -I/usr/src/gnu/usr.bin/cc/libgcc/../cc_tools > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/include > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/libcpp/include > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/libdecnumber-c > > /usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config/floatunsidf.c -o > > floatunsidf.o > > /usr/src/gnu/usr.bin/cc/libgcc/obj/../cc/cc -B > > /usr/src/gnu/usr.bin/cc/libgcc/obj/../cc1 -O2 -pipe -g -DIN_GCC > > -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -DHAVE_GTHR_DEFAULT > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/include > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc -I. > > -I/usr/src/gnu/usr.bin/cc/libgcc/../cc_tools -Dinhibit_libc -fno-inline > > -DIN_GCC -DHAVE_CONFIG_H -DPREFIX="/usr" > > -I/usr/src/gnu/usr.bin/cc/libgcc/obj/../cc_tools > > -I/usr/src/gnu/usr.bin/cc/libgcc/../cc_tools > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/include > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/libcpp/include > > -I/usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/libdecnumber-c > > /usr/src/gnu/usr.bin/cc/libgcc/../../../gcc/gcc/config/floatunsisf.c -o > > floatunsisf.o > > make: don't know how to make .vis (prerequisite of: _bb_init_func.o > > _dvmd_tls.o) > > Stop in gnu/usr.bin/cc/libgcc > > *** Error 2 in gnu/usr.bin/cc (:48 'all') > > *** Error 2 in gnu/usr.bin (:48 'all') > > *** Error 2 in gnu (:48 'all') > > *** Error 2 in . (:48 'all') > > *** Error 2 in /usr/src (Makefile:89 'build') > > > > > > Any idea? The full log is here (ignore the messages in spanish, I use a > > script to compile the base): > > http://juanfra.info/bl/openbsd-arm-201312/error_base.log > > > > I just spun a build without issues a couple days ago. I did have an > issue with making a release, but certainly not what you are seeing > above. (and I haven't looked closely at my release error messages yet) > > maybe check your gnu/usr.bin/cc directory for 'M's and 'C's when doing a > checkout against another source? > > Nick > I deleted the src dir and downloaded again the code from two anoncvs servers. The build fails always at the same point. Maybe my system is broken, I don't know. Glad to hear you can build a snapshot :P -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: PATCH: new usbdevs vendor Sunplus, new wi-fi devices
On Mon, Jan 06, 2014 at 05:43:16PM +, Alexey E. Suslikov wrote: > previous diff may be mangled. resending. > > Index: usbdevs > === > RCS file: /cvs/src/sys/dev/usb/usbdevs,v > retrieving revision 1.618 > diff -u -p -r1.618 usbdevs > --- usbdevs 17 Dec 2013 12:51:14 - 1.618 > +++ usbdevs 6 Jan 2014 13:27:13 - > @@ -585,6 +585,7 @@ vendor TML0x1b91 The Mobility Lab > vendor TCTMOBILE 0x1bbb TCT Mobile > vendor MDS 0x1bc8 MDS > vendor ALTI2 0x1bc9 Alti-2 > +vendor SUNPLUS 0x1bcf Sunplus Innovation Technology Inc. > vendor WAGO 0x1be3 WAGO Kontakttechnik > vendor LONGCHEER 0x1c9e Longcheer Technology > vendor DRESDENELEC 0x1cf1 Dresden Elektronic > @@ -1463,6 +1464,7 @@ product DLINK RT25700x3c00 RT2570 > product DLINK DUBE100B1 0x3c05 DUB-E100 rev B1 > product DLINK RT2870 0x3c09 RT2870 > product DLINK RT3072 0x3c0a RT3072 > +product DLINK DWA140B3 0x3c15 DWA-140 rev B3 > product DLINK DWA127 0x3c1b DWA-127 > product DLINK DSB650C0x4000 10Mbps Ethernet > product DLINK DSB650TX1 0x4001 10/100 Ethernet > @@ -3390,6 +3392,7 @@ product RALINK RT3071 0x3071 RT3071 > product RALINK RT30720x3072 RT3072 > product RALINK RT33700x3370 RT3370 > product RALINK RT35720x3572 RT3572 > +product RALINK RT53700x5370 RT5370 > product RALINK RT80700x8070 RT8070 > product RALINK RT2570_3 0x9020 RT2570 > product RALINK RT2573_2 0x9021 RT2573 > You need regenerate also usbdevs.h and usbdevs_data.h. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: hppa mutex ipl diff
I've been running a dpb build for hours and I've not seen problems.
On Wed, Jan 29, 2014 at 11:06:40AM +0100, Mark Kettenis wrote:
> Here is a diff that makes mutexes raise their ipl to the highest level
> that has interrupts that take the kernel lock. This is necessary for
> the work dlg@ has been doing on making subsystems run without the
> kernel lock.
>
> This needs to be tested on an MP system, and unfortunately that's
> something I cannot do.
>
>
> Index: include/mutex.h
> ===
> RCS file: /cvs/src/sys/arch/hppa/include/mutex.h,v
> retrieving revision 1.4
> diff -u -p -r1.4 mutex.h
> --- include/mutex.h 10 Jan 2010 04:07:18 - 1.4
> +++ include/mutex.h 29 Jan 2014 10:01:52 -
> @@ -39,9 +39,24 @@ struct mutex {
> void *mtx_owner;
> };
>
> -void mtx_init(struct mutex *, int);
> +/*
> + * To prevent lock ordering problems with the kernel lock, we need to
> + * make sure we block all interrupts that can grab the kernel lock.
> + * The simplest way to achieve this is to make sure mutexes always
> + * raise the interrupt priority level to the highest level that has
> + * interrupts that grab the kernel lock.
> + */
> +#ifdef MULTIPROCESSOR
> +#define __MUTEX_IPL(ipl) \
> +(((ipl) > IPL_NONE && (ipl) < IPL_AUDIO) ? IPL_AUDIO : (ipl))
> +#else
> +#define __MUTEX_IPL(ipl) (ipl)
> +#endif
>
> -#define MUTEX_INITIALIZER(ipl) { MUTEX_UNLOCKED, (ipl), 0, NULL }
> +#define MUTEX_INITIALIZER(ipl) { MUTEX_UNLOCKED, __MUTEX_IPL((ipl)), 0, NULL
> }
> +
> +void __mtx_init(struct mutex *, int);
> +#define mtx_init(mtx, ipl) __mtx_init((mtx), __MUTEX_IPL((ipl)))
>
> #ifdef DIAGNOSTIC
> #define MUTEX_ASSERT_LOCKED(mtx) do {
> \
> Index: hppa/mutex.c
> ===
> RCS file: /cvs/src/sys/arch/hppa/hppa/mutex.c,v
> retrieving revision 1.11
> diff -u -p -r1.11 mutex.c
> --- hppa/mutex.c 20 Apr 2011 16:10:53 - 1.11
> +++ hppa/mutex.c 29 Jan 2014 10:01:52 -
> @@ -50,7 +50,7 @@ try_lock(struct mutex *mtx)
> }
>
> void
> -mtx_init(struct mutex *mtx, int wantipl)
> +__mtx_init(struct mutex *mtx, int wantipl)
> {
> mtx->mtx_lock[0] = 1;
> mtx->mtx_lock[1] = 1;
>
--
Juan Francisco Cantero Hurtado http://juanfra.info
Racket seg fault and atexit
Can someone tell me if this crash is due to a bug on OpenBSD or on Racket? I'm asking because the backtrace shows "atexit" and I don't know if it is something related to the changes to atexit. I only see the bug when racket is compiled with gcc. With clang (on amd64), racket works fine. http://bugs.racket-lang.org/query/?cmd=view%20audit-trail&database=default&pr=14318 -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Racket seg fault and atexit
On Fri, Feb 14, 2014 at 09:00:31PM -0800, Philip Guenther wrote: > On Fri, Feb 14, 2014 at 8:20 PM, Juan Francisco Cantero Hurtado > wrote: > > Can someone tell me if this crash is due to a bug on OpenBSD or on > > Racket? I'm asking because the backtrace shows "atexit" and I don't > > know if it is something related to the changes to atexit. I only see the > > bug when racket is compiled with gcc. With clang (on amd64), racket > > works fine. > > > > http://bugs.racket-lang.org/query/?cmd=view%20audit-trail&database=default&pr=14318 > > To quote that: > > #5 0x175f2cf6ea82 in strlen (str=0x0) at > > /usr/src/lib/libc/string/strlen.c:43 > > s = Variable "s" is not available. > > strlen(NULL) is an error. The question is what happened above that; > why is that being called only when compiled with gcc and not with > clang? The default answer to that question is "undefined behavior > according to C standard in calling program"...but you need to look at > the calling code to be sure. Thanks for the help. I'll add your answer to the report. I've been running a lot of tests with different options today. I can reproduce the bug with gcc 4.2, 4.6 and 4.8 with -O2 and -O1. When racket is compiled with -O0, it passes all tests. Disable the integrated assembler or the builtins of clang doesn't trigger the bug. Fortunately I have a crappy workaround now. :) -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: ffs2 boot
On Wed, Apr 16, 2014 at 05:29:36PM -0500, Shawn K. Quinn wrote: > On Wed, Apr 16, 2014, at 03:05 PM, Miod Vallat wrote: >[responding to Brandon Mercer who wrote:] > > > The other day I was doing an install in qemu-kvm and newfs was taking > > > forever, to the tune of hours. This is similar to formatting on arm > > > boards. In my quest to track down why, I discovered that ffs2 takes far > > > less time to format than ffs1 (about 30 seconds for the entire disk). > > > > > > I've put together a diff that updates the boot blocks on amd64 to be > > > able to boot ffs2. From there it's a one line change to make newfs > > > format ffs2 by default. Obviously this would need to happen for other > > > architectures as well and I'd be glad to tackle that if others see > > > this as worthwhile. Please let me know your thoughts. > > > > Awesome. You've just trimmed my todolist by a few lines (-: > > And you've done it so that you do not force UFS2 support on > > tight-space-challenged boot blocks on other arches. > > I'm not against adding cool features, but are there people who really > need a root filesystem of one whole terabyte or larger? I've never The best feature of UFS2 for me is a faster fsck. > needed my root filesystem to be larger than, say, a gigabyte or two. The > only case for which this might make some sense is an external hard > drive, formatted FFS2, on a 1T+ drive nearly full of personal files that > just happens to have a bsd.rd in the root to reinstall/upgrade a hosed > system. For most others, there should be a note that making your root > filesystem That Big is usually a Really Bad Idea. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Scheduler improvements
On Thu, Oct 04, 2012 at 11:42:45PM +0200, Gregor Best wrote: > Hi people, > > after a (very) long time of silence on this, here's another go at it. This > time, > I basically started from scratch and used a bit of code by Christiano > Haesberth > which had been posted to tech@ a while ago to detect CPU topology on amd64 and > take that into account when moving processes between CPUs. > > This version has one single queue per CPU, getting rid of a) the one single > system > wide runqueue and b) the queue for expired processes. This simplifies things > a bit > and performs just as well as my previous versions (the only difference is the > order > in which expired procs get selected for running on a CPU). One advantage is > that > process selection is in O(log n) of the number of processes on the CPU and > depends > neither on the total number of processes nor the number of expired processes > in > the runqueue. > > The factors for the cost of moving a process between hardware threads, cpu > dies > and cpu packages are guesses now, I think those will have to be tuned further. > Sadly, I haven't had access to a multiprocessor machine with a more diverse > architecture than "a bunch of cores on the same die". > > I tested this on some more machines than before; a Core i5, an i7 and my Core > 2 > Duo and on all machines (perceived) interactivity was improved. The simplest > benchmark I used was playing back a 1080p version of Big Buck Bunny with > mplayer. > All machines I tested on had Intel graphics cards, one GM965 (on the > Core2Duo) and > the others were Sandy Bridge devices. On all of them, playback was smoother > with > the i7 being most visible. With the default scheduler, watching the movie was > a > big pain due to heavy frame-dropping, with my patch, the movie was watchable > (with > frame dropping only (barely) noticable in scenes with much movement). > > As before, I'm looking forward to anything you have to comment, especially > cool > benchmark ideas or the like. With your patch, html5 videos on firefox are smoother, even the playback is better when I try firefox + dpb 2 jobs vs only firefox without your patch installed. I use i3wm, so I can't comment about the performance of a full desktop environment. My hardware: AMD A4-3400, 8GB, ATI Radeon HD 4350. Please, still working on this area :) -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: vga diff for testing
On Sun, Mar 03, 2013 at 10:39:46PM +0100, Mark Kettenis wrote: > > In order to be able to support a framebuffer console on i386/amd64 I'd > like to reorder some code such that wsdisaplay(4) attaches to vga(4) > *after* drm(4). Since I don't have any hardware with radeondrm(4) I'd > appreciate it if people with access to such hardware would test the > diff below. Just check that your vga text glass console and X still > work. All works OK. AMD64 and ATI Radeon HD 4350 PCI. OpenBSD 5.3 (GENERIC.MP) #21: Wed Feb 27 22:58:43 CET 2013 r...@sobremesa.juanfra.info:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8566591488 (8169MB) avail mem = 8316051456 (7930MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb0d0 (65 entries) bios0: vendor American Megatrends Inc. version "0901" date 09/30/2012 bios0: ASUSTeK COMPUTER INC. F1A55 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT acpi0: wakeup devices SBAZ(S4) PS2K(S4) PS2M(S4) UAR1(S4) UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) PE20(S4) PE21(S4) RLAN(S4) PE22(S4) PE23(S4) PCE2(S4) PCE4(S4) P0PC(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD A4-3400 APU with Radeon(tm) HD Graphics, 2700.24 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: smt 0, core 0, package 0 cpu0: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD A4-3400 APU with Radeon(tm) HD Graphics, 2699.93 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu1: AMD erratum 721 detected and fixed cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (PE20) acpiprt2 at acpi0: bus 4 (PE21) acpiprt3 at acpi0: bus -1 (PE22) acpiprt4 at acpi0: bus 5 (PE23) acpiprt5 at acpi0: bus -1 (BR13) acpiprt6 at acpi0: bus -1 (PCE2) acpiprt7 at acpi0: bus -1 (PCE4) acpiprt8 at acpi0: bus 1 (P0PC) acpicpu0 at acpi0: C2, PSS acpicpu1 at acpi0: C2, PSS acpibtn0 at acpi0: PWRB cpu0: 2700 MHz: speeds: 2700 2400 2200 2000 1800 1400 1100 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 12h Host" rev 0x00 ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed t10.ATA_ST3250310AS_5RY0ZTKS sd0: 238475MB, 512 bytes/sector, 488397168 sectors sd1 at scsibus0 targ 1 lun 0: SCSI3 0/direct fixed naa.5000c500142c3ef3 sd1: 476940MB, 512 bytes/sector, 976773168 sectors sd2 at scsibus0 targ 2 lun 0: SCSI3 0/direct fixed naa.5000c5004fab5f8b sd2: 953869MB, 512 bytes/sector, 1953525168 sectors ohci0 at pci0 dev 18 function 0 "AMD Hudson-2 USB" rev 0x11: apic 3 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 "AMD Hudson-2 USB2" rev 0x11: apic 3 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at pci0 dev 19 function 0 "AMD Hudson-2 USB" rev 0x11: apic 3 int 18, version 1.0, legacy support ehci1 at pci0 dev 19 function 2 "AMD Hudson-2 USB2" rev 0x11: apic 3 int 17 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "AMD EHCI root hub" rev 2.00/1.00 addr 1 piixpm0 at pci0 dev 20 function 0 "AMD Hudson-2 SMBus" rev 0x13: polling iic0 at piixpm0 iic0: addr 0x20 01=0d 02=17 03=26 04=8c 05=8c 06=8c 07=8c 08=00 09=00 0a=10 0b=10 0c=10 0d=10 0e=07 0f=8b 10=00 11=00 12=00 13=00 14=00 15=0f 16=17 17=20 18=e0 19=fb 1a=a8 1b=a3 1c=ac 1d=80 1e=04 1f=03 20=09 21=09 22=09 23=09 24=37 3e=a3 words 00=ff0d 01=0d17 02=1726 03=268c 04=8c8c 05=8c8c 06=8c8c 07=8c00 spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600 spdmem1 at iic0 addr 0x51: 4GB DDR3 SDRAM PC3-10600 azalia0 at pci0 dev 20 function 2 "AMD Hudson-2 HD Audio" rev 0x01: apic 3 int 16 azalia0: codecs: Realtek/0x0887 audio0 at azalia0 pcib0 at pci0 dev 20 function 3 "AMD Hudson-2 LPC"
Re: Add family 15h devices, km(4) sensor.
On Wed, Mar 13, 2013 at 10:51:12AM -0400, Brynet wrote: > So someone sent me a new toy, this adds the k15 PCIe devices. Names are > copied from the equivalent k14.. because I'm not sure wherefrom they > were originally sourced. > > For km(4), it seems the temperature calculations are off.. according to > the BKDG curtmp doesn't seem to actually reflect the real temperature, > but some sort of value in relation to the max temperature. > > On my system is shows around <10degC when idle, reaching 40degC when all > cores are under load. So.. the value increases! :P I've the same problem with km and 14h. > > The FreeBSD driver has all sorts of workarounds I'm not sure we want, > but it shows similar temperatures values. > > ok? > > -Bryan. OpenBSD 5.3 (GENERIC.MP) #62: Tue Mar 12 18:21:20 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8566591488 (8169MB) avail mem = 831602 (7930MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xeb0d0 (65 entries) bios0: vendor American Megatrends Inc. version "0901" date 09/30/2012 bios0: ASUSTeK COMPUTER INC. F1A55 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG HPET SSDT SSDT acpi0: wakeup devices SBAZ(S4) PS2K(S4) PS2M(S4) UAR1(S4) UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) PE20(S4) PE21(S4) RLAN(S4) PE22(S4) PE23(S4) PCE2(S4) PCE4(S4) P0PC(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD A4-3400 APU with Radeon(tm) HD Graphics, 2700.25 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: apic clock running at 199MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD A4-3400 APU with Radeon(tm) HD Graphics, 2699.94 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu1: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu1: AMD erratum 721 detected and fixed ioapic0 at mainbus0: apid 3 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 3 (PE20) acpiprt2 at acpi0: bus 4 (PE21) acpiprt3 at acpi0: bus -1 (PE22) acpiprt4 at acpi0: bus 5 (PE23) acpiprt5 at acpi0: bus -1 (BR13) acpiprt6 at acpi0: bus -1 (PCE2) acpiprt7 at acpi0: bus -1 (PCE4) acpiprt8 at acpi0: bus 1 (P0PC) acpicpu0 at acpi0: C2, PSS acpicpu1 at acpi0: C2, PSS acpibtn0 at acpi0: PWRB cpu0: 2700 MHz: speeds: 2700 2400 2200 2000 1800 1400 1100 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD AMD64 12h Host" rev 0x00 ahci0 at pci0 dev 17 function 0 "AMD Hudson-2 SATA" rev 0x40: msi, AHCI 1.3 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed t10.ATA_ST3250310AS_5RY0ZTKS sd0: 238475MB, 512 bytes/sector, 488397168 sectors sd1 at scsibus0 targ 1 lun 0: SCSI3 0/direct fixed naa.5000c500142c3ef3 sd1: 476940MB, 512 bytes/sector, 976773168 sectors sd2 at scsibus0 targ 2 lun 0: SCSI3 0/direct fixed naa.5000c5004fab5f8b sd2: 953869MB, 512 bytes/sector, 1953525168 sectors ohci0 at pci0 dev 18 function 0 "AMD Hudson-2 USB" rev 0x11: apic 3 int 18, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 "AMD Hudson-2 USB2" rev 0x11: apic 3 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "AMD EHCI root hub" rev 2.00/1.00 addr 1 ohci1 at pci0 dev 19 function 0 "AMD Hudson-2 USB" rev 0x11: apic 3 int 18, version 1.0, legacy support ehci1 at pci0 dev 19 function 2 "AMD Hudson-2 USB2" rev 0x11: apic 3 int 17 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "AMD EHCI root hub" rev 2.00/1.00 addr 1 piixpm0 at pci0 dev 20 function 0 "AMD Hudson-2 SMBus" rev 0x13: polling iic0 at piixpm0 iic0: addr 0x20 01=0d 02=17 03=26 04=8c 05=8c 06=8c 07=8c 08=00 09=00 0a=10 0b=10 0c=10 0d=10 0e=07 0f=8b 10=00 11=00 12=00 13=00 14=00 15=0f 16=19 17=20 18=e0 19=fb 1a=a8 1b=a3 1c=ac 1d=80 1e=04 1f=03 20=09 21=09 22=09 23=09 24=37 3e=a3 words 00=ff0d 01=0d17 02=1726 03=268c 04=8c8c 05=8c8c 06=8c8c 07=8c00 spdmem0 at iic0 addr 0x50: 4GB DDR3 SDRAM PC3-10600 spdmem1 at iic0 addr 0x51: 4
Re: vmmap replacement -- please test
On Fri, 30 Dec 2011 17:55:27 +0100, Ariane van der Steldt wrote: On Fri, Dec 30, 2011 at 03:04:30PM +0100, Ariane van der Steldt wrote: On Fri, Dec 30, 2011 at 02:42:18PM +0100, Ariane van der Steldt wrote: > The huge diff included below is to replace vmmap for something that > works a lot better. This is the second version I plan to commit. > I have been running this on my laptop for months and have had no > problems. > > The current incarnation is: > vmmap_sys.diff.63 Which never made it to the list apparently. I'll just blame spam filtering and provide it an alternative way: http://www.stack.nl/~ariane/vmmap_sys.diff.63 SHA256 (vmmap_sys.diff.63) = 5c3e71360795f3899baa652f6ba6caa999b137b01a778dca12c253af1dbcff00 MD5 (vmmap_sys.diff.63) = 11736a0bacb0b8b72079935ba01c62c4 size: 305720 bytes Highlights: - the mapping and allocation (address selection) logic is split - the allocator is in compatibility mode, meaning it ought to perform the same strategies (and hence contain the same bugs, yay) as the version that you are running in your kernel at the moment (this means java and various browsers won't die horribly, at least not more than they used to) - despite using the same algorithm, it is a bit^W alot faster - it's only a 3^W 10494 line diff :P I'll need testing on any and all architectures. Thanks, Hi, I've tried both patches on i386. The system crashed. The code in src is a clean checkout from 3 January. I applied the patches in src and src/sys without errors. I compiled the kernel and userland with this steps: export PARALLEL_BUILD=YES export MAKE_JOBS=2 cd /usr/src/sys/arch/i386/conf config GENERIC.MP cd ../compile/GENERIC.MP make clean make make install rm -rf /usr/obj/* cd /usr/src make obj cd /usr/src make build dmesg with trace and ps: http://juanfra.info/bugs-y-listas/obsd-vmmap-201201/dmesg.txt.bz2 When I boot the system with /obsd (from snapshots) and the userland with your patch applied, all works without issues. I will save the dump for a few weeks. If you need more info, ask me. Cheers. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: vmmap replacement -- please test
On Fri, 06 Jan 2012 23:51:28 +0100, Ariane van der Steldt wrote: Hi, I found and fixed the i386 bug. Please test this, to confirm that it fixes the problem (and doesn't introduce anything else, ofcourse). (vmmap_sys relative to /usr/src/sys, vmmap_userland relative to /usr/src) New version of the diff: http://www.stack.nl/~ariane/vmmap_sys.diff.64 with corresponding userland: http://www.stack.nl/~ariane/vmmap_userland.diff.30 (the userland portion is unchanged). SHA256 (vmmap_sys.diff.64) = aa87c7a6d1c485b6acb228f238a54bee8c28eb5cc6cfc65da6e6b3b047d94e93 MD5 (vmmap_sys.diff.64) = 2d7587702ce2bf7ce50bf58c5b24a6cc vmmap_sys.diff.64 size: 305807 bytes SHA256 (vmmap_userland.diff.30) = 85d2cb4d85a6a9cffd16940f17498321243ef9731a687161b3b38caadaf6dc06 MD5 (vmmap_userland.diff.30) = f5add708c2d1f84dc05f2ceb1749c9cf vmmap_userland.diff.30 size: 2011 Your patch fix the bug. I've been using the computer for 3 hours without apparent problems. Thanks. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: nicer reaper
On Sun, Apr 15, 2012 at 07:30:21PM +0200, Ariane van der Steldt wrote: > Hi, > > The reaper is not very nice: it blocks any access to the kernel (i.e. > syscalls) until it is done with its work. For big processes, this may > result in stalls in userspace. This diff attempts to relieve it by > yielding the reaper during this operation. > > Please test this diff (vmmap_reaperyield.diff.0). Hi. I can't compile the kernel with your patch. OpenBSD 5.1-current (GENERIC.MP) #1: Thu Apr 12 01:08:24 CEST 2012 juan...@portatil.juanfra.info:/usr/src/sys/arch/i386/compile/GENERIC.MP cc -Werror -Wall -Wstrict-prototypes -Wmissing-prototypes -Wno-main -Wno-uninitialized -Wno-format -Wstack-larger-than-2047 -fno-builtin-printf -fno-builtin-snprintf -fno-builtin-vsnprintf -fno-builtin-log -fno-builtin-log2 -fno-builtin-malloc -O2 -pipe -nostdinc -I. -I../../../..-I../../../../arch -DDDB -DDIAGNOSTIC -DKTRACE -DACCOUNTING -DKMEMSTATS -DPTRACE -DPOOL_DEBUG -DCRYPTO -DSYSVMSG -DSYSVSEM -DSYSVSHM -DUVM_SWAP_ENCRYPT -DCOMPAT_43 -DCOMPAT_O48 -DLKM -DFFS -DFFS2 -DFFS_SOFTUPDATES -DUFS_DIRHASH -DQUOTA -DEXT2FS -DMFS -DNFSCLIENT -DNFSSERVER -DCD9660 -DUDF -DMSDOSFS -DFIFO -DSOCKET_SPLICE -DTCP_SACK -DTCP_ECN -DTCP_SIGNATURE -DINET -DALTQ -DINET6 -DIPSEC -DPPP_BSDCOMP -DPPP_DEFLATE -DPIPEX -DMROUTING -DMPLS -DBOOT_CONFIG -DUSER_PCICONF -DKVM86 -DUSER_LDT -DAPERTURE -DCOMPAT_LINUX -DPROCFS -DNTFS -DPCIVERBOSE -DEISAVERBOSE -DUSBVERBOSE -DWSDISPLAY_COMPAT_USL -DWSDISPLAY_COMPAT_RAWKBD -DWSDISPLAY_DEFAULTSCREENS="6" -DWSDISPLAY_COMPAT_PCVT -DX86EMU -DONEWIREVERBOSE -DMULTIPROCESSOR -DMAXUSERS=80 -D_KERNEL -MD -MP -c ../../../../arch/i386/i386/pmap.c ../../../../arch/i386/i386/pmap.c: In function 'pmap_free_pvpage': ../../../../arch/i386/i386/pmap.c:1275: error: too few arguments to function 'uvm_unmap_detach' *** Error code 1 Stop in /usr/src/sys/arch/i386/compile/GENERIC.MP (line 89 of /usr/share/mk/sys.mk). Cheers. -- Juan Francisco Cantero Hurtado http://juanfra.info
Question about wscons/wsksymdef.h
Hi!. This afternoon I was thinking about to change my vim config for to remap the "capslock" key to "control" or "escape" keys. I was searching some of information and I did remember the option "nocaps" of Xorg. Also, I've read the man page of wsconsctl and I saw the option swapctrlcaps. So, I decided to look the code of wscons related to this option. I am not a C programmer but I can understand sometimes the simple code. In short. Can someone say me what are these values?. I don't want a master class, just a link or a bit of documentation is sufficient. #define KB_NODEAD 0x01 /* disable dead accents */ #define KB_DECLK0x02 /* DEC LKnnn layout */ #define KB_LK4010x04 /* DEC LK401 instead LK201 */ #define KB_SWAPCTRLCAPS 0x08 /* swap Left-Control and Caps-Lock */ #define KB_DVORAK 0x10 /* Dvorak layout */ #define KB_METAESC 0x20 /* generate ESC prefix on ALT-key */ #define KB_IOPENER 0x40 /* f1-f12 -> ESC,f1-f11 */ #define KB_MACHDEP 0x80 /* machine dependent */ #define KB_APPLE 0x01 /* Apple specific layout */ Thanks. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Question about wscons/wsksymdef.h
On Fri, May 18, 2012 at 07:07:17PM -0700, Matthew Dempsky wrote: > On Fri, May 18, 2012 at 4:27 PM, Juan Francisco Cantero Hurtado > wrote: > > In short. Can someone say me what are these values?. I don't want a > > master class, just a link or a bit of documentation is sufficient. > > Are you just trying to swap caps and ctrl at the console? If so, just > put "us.swapctrlcaps" (or whatever) in /etc/kbdtype and reboot. (Or > run "kbd us.swapctrlcaps" as root to do it instantly.) I know. No, I'm playing with wscons for add a "nocaps" option. Just for curiosity. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Question about wscons/wsksymdef.h
On Sat, May 19, 2012 at 08:45:48AM +0200, Matthieu Herrb wrote: > On Sat, May 19, 2012 at 01:27:53AM +0200, Juan Francisco Cantero Hurtado > wrote: > > Hi!. This afternoon I was thinking about to change my vim config for > > to remap the "capslock" key to "control" or "escape" keys. I was > > searching some > > of information and I did remember the option "nocaps" of Xorg. > > For Xorg /usr/X11R6/share/X11/xkb/rules/base.lst has the list of all > possible values for XkbModel, XkbLayout and XkbOptions Thanks. Good to know. > > > > Also, I've read the man page of wsconsctl and I saw the option > > swapctrlcaps. So, I decided to look the code of wscons related to this > > option. I am not a C programmer but I can understand sometimes the > > simple code. > > > > In short. Can someone say me what are these values?. I don't want a > > master class, just a link or a bit of documentation is sufficient. > > > > #define KB_NODEAD 0x01 /* disable dead accents */ > > #define KB_DECLK0x02 /* DEC LKnnn layout */ > > #define KB_LK4010x04 /* DEC LK401 instead LK201 */ > > #define KB_SWAPCTRLCAPS 0x08 /* swap Left-Control and Caps-Lock > > */ > > #define KB_DVORAK 0x10 /* Dvorak layout */ > > #define KB_METAESC 0x20 /* generate ESC prefix on ALT-key > > */ > > #define KB_IOPENER 0x40 /* f1-f12 -> ESC,f1-f11 */ > > #define KB_MACHDEP 0x80 /* machine dependent */ > > #define KB_APPLE0x01 /* Apple specific layout */ > > > > Those are arbritrary values corresponding to various flags that can be > set with the kbd(8) command, as keymap variant (their names are at the end of > wsksymdef.h). I assumed the numbers are random but I wanted to be sure. Perfect. > > Unfortunatly wscons is one of the worse areas of OpenBSD for > documentation. To figure out exactly what they do, you need to read > the source. For PC style keyboard you can see how keymaps are built > from their symbolic names in /sys/dev/pckbc/wskbdmap_mfii.c Yep, I've modified wskbdmap_mfii.c, ukbdmap.c and wsksymdef.h. Fortunately, add a new option is easy for a newbie like me. > > And if en route you feel like writing some the missing bits of > documentation, you're of course welcome ! I know :P . The OpenBSD devs are very open a new contributions. Thanks for all the info. -- Juan Francisco Cantero Hurtado http://juanfra.info
