Re: malloc should always abort
Hi Ted, FWIW, I agree with malloc always failing on error. On Wed, Dec 30, 2015 at 7:12 AM, Ted Unangst wrote: > @@ -523,10 +521,8 @@ omalloc_init(struct dir_info **dp) > mopts.malloc_cache >>= 1; > break; > case 'a': > - mopts.malloc_abort = 0; > break; > case 'A': > - mopts.malloc_abort = 1; > break; > case 'c': > mopts.malloc_canaries = 0; > I guess you will remove the option treatment in a near future ? ;-) On a side note, with this option var removal, you can collapse the switch condition as : @@ -523,10 +521,7 @@ omalloc_init(struct dir_info **dp) mopts.malloc_cache >>= 1; break; case 'a': - mopts.malloc_abort = 0; - break; case 'A': - mopts.malloc_abort = 1; break; case 'c': mopts.malloc_canaries = 0; Thierry
Re: Slow wsmouse down in console
Hi Ulf, I indeed guess there are not much console users these modern days. Personally, my current laptop is so slow in X that I find it convenient to switch back and forth between ttyC[014]. In that regard, I will probably investigate the possibility of sharing the copy-buffer between screens. Who knows ? I unfortunately couldn't test my patch as much as you did. (I'm still waiting for my new laptop to speed up my builds. Should arrive soon hopefully) Thanks for your involved feedback, Thierry On Sun, Nov 29, 2015 at 5:02 PM, Ulf Brosziewski < ulf.brosziew...@t-online.de> wrote: > This looks nice. Maybe someone else who is more familiar with wsdisplay > could also have a look at it? > > I made a test with a USB mouse and an ALPS Glidepoint, which worked > well. Without the patch wsmoused is completely useless for that > touchpad. Out of curiosity, I made another test with an Elantech-v4 > clickpad, and the cursor control also worked well (of course, wsmoused > remains useless for clickpads because you cannot paste). > > Both tracking the remainders when scaling and taking the size of the > cells into account looks reasonable. There might still be no g > u > arantee > that this works everywhere - pms, for example, applies somewhat > arbitrary scale factors in compat mode, there is no stable correlation > to the touchpad resolutions. But if this works in standard environments, > it is certainly more useful than the current version. > > Because I saw no complaints up to now, I have been thinking that hardly > anyone uses touchpads at the console. Am I wrong here? > > > > On 11/27/2015 12:35 AM, Thierry Deval wrote: > >> Hi, >> >> I hope I'm not the only one being annoyed by the fast movement of wsmouse >> when >> in text mode, and this one can be useful. >> >> Here is a patch that slows down the cursor by reducing the mouse >> coordinates >> proportionally to the console font size. >> I confess I have only tried it on this laptop with its Synaptics touchpad >> and >> some other USB mouses. >> >> Anyone else interested ? >> >> Thierry >> >> Index: sys/dev/wscons/wsdisplay.c >> === >> RCS file: /cvs/src/sys/dev/wscons/wsdisplay.c,v >> retrieving revision 1.124 >> diff -u -p -r1.124 wsdisplay.c >> --- dev/wscons/wsdisplay.c 8 Sep 2015 11:13:20 - 1.124 >> +++ dev/wscons/wsdisplay.c 26 Nov 2015 20:28:48 - >> @@ -2463,27 +2463,39 @@ ctrl_event(struct wsdisplay_softc *sc, u >> void >> mouse_moverel(struct wsscreen *scr, int dx, int dy) >> { >> + static int acc_dx, acc_dy; >> struct wsscreen_internal *dconf = scr->scr_dconf; >> + const struct wsscreen_descr *descr = dconf->scrdata; >> u_int old_mouse = scr->mouse; >> int mouse_col = scr->mouse % N_COLS(dconf); >> int mouse_row = scr->mouse / N_COLS(dconf); >> + int norm_dx, norm_dy; >> + >> + /* accumulate movement and calculate character equivalent */ >> + acc_dx += dx; >> + if ((norm_dx = acc_dx / descr->fontwidth )) acc_dx -= >> descr->fontwidth * norm_dx; >> + acc_dy += dy; >> + if ((norm_dy = acc_dy / descr->fontheight)) acc_dy -= >> descr->fontheight * norm_dy; >> + >> + /* bail out if mouse hasn't virtually moved */ >> + if (norm_dx == 0 && norm_dy == 0) return; >> >> /* update position */ >> - if (mouse_col + dx >= MAXCOL(dconf)) >> + if (mouse_col + norm_dx >= MAXCOL(dconf)) >> mouse_col = MAXCOL(dconf); >> else { >> - if (mouse_col + dx <= 0) >> + if (mouse_col + norm_dx <= 0) >> mouse_col = 0; >> else >> - mouse_col += dx; >> + mouse_col += norm_dx; >> } >> - if (mouse_row + dy >= MAXROW(dconf)) >> + if (mouse_row + norm_dy >= MAXROW(dconf)) >> mouse_row = MAXROW(dconf); >> else { >> - if (mouse_row + dy <= 0) >> + if (mouse_row + norm_dy <= 0) >> mouse_row = 0; >> else >> - mouse_row += dy; >> + mouse_row += norm_dy; >> } >> scr->mouse = mouse_row * N_COLS(dconf) + mouse_col; >> >> >> >> >
Slow wsmouse down in console
Hi, I hope I'm not the only one being annoyed by the fast movement of wsmouse when in text mode, and this one can be useful. Here is a patch that slows down the cursor by reducing the mouse coordinates proportionally to the console font size. I confess I have only tried it on this laptop with its Synaptics touchpad and some other USB mouses. Anyone else interested ? Thierry Index: sys/dev/wscons/wsdisplay.c === RCS file: /cvs/src/sys/dev/wscons/wsdisplay.c,v retrieving revision 1.124 diff -u -p -r1.124 wsdisplay.c --- dev/wscons/wsdisplay.c 8 Sep 2015 11:13:20 - 1.124 +++ dev/wscons/wsdisplay.c 26 Nov 2015 20:28:48 - @@ -2463,27 +2463,39 @@ ctrl_event(struct wsdisplay_softc *sc, u void mouse_moverel(struct wsscreen *scr, int dx, int dy) { + static int acc_dx, acc_dy; struct wsscreen_internal *dconf = scr->scr_dconf; + const struct wsscreen_descr *descr = dconf->scrdata; u_int old_mouse = scr->mouse; int mouse_col = scr->mouse % N_COLS(dconf); int mouse_row = scr->mouse / N_COLS(dconf); + int norm_dx, norm_dy; + + /* accumulate movement and calculate character equivalent */ + acc_dx += dx; + if ((norm_dx = acc_dx / descr->fontwidth )) acc_dx -= descr->fontwidth * norm_dx; + acc_dy += dy; + if ((norm_dy = acc_dy / descr->fontheight)) acc_dy -= descr->fontheight * norm_dy; + + /* bail out if mouse hasn't virtually moved */ + if (norm_dx == 0 && norm_dy == 0) return; /* update position */ - if (mouse_col + dx >= MAXCOL(dconf)) + if (mouse_col + norm_dx >= MAXCOL(dconf)) mouse_col = MAXCOL(dconf); else { - if (mouse_col + dx <= 0) + if (mouse_col + norm_dx <= 0) mouse_col = 0; else - mouse_col += dx; + mouse_col += norm_dx; } - if (mouse_row + dy >= MAXROW(dconf)) + if (mouse_row + norm_dy >= MAXROW(dconf)) mouse_row = MAXROW(dconf); else { - if (mouse_row + dy <= 0) + if (mouse_row + norm_dy <= 0) mouse_row = 0; else - mouse_row += dy; + mouse_row += norm_dy; } scr->mouse = mouse_row * N_COLS(dconf) + mouse_col;
Re: ATI SB400 PCI bridge fallback to substractive decode
On Mon, Sep 15, 2014 at 11:15:48AM +0200, Mark Kettenis wrote: Date: Mon, 15 Sep 2014 09:37:56 +0200 From: Thierry Deval On Mon, Sep 15, 2014 at 12:25:19AM +0200, Mark Kettenis wrote: >> Date: Sun, 14 Sep 2014 23:57:09 +0200 >> From: Thierry Deval >> >> Hi, >> >> When I put a CF to PCCard adapter (not CardBus) in my laptop to work on a CF >> boot image, I was surprised by this kernel message : >> >> ** wdc2 at pcmcia0 function 0 "SanDisk, SDP, 5/3 0.6": can't handle card info >> >> . > >Can you send pcidump -vxxx output for that machine? Sure Mark, here it is. Thanks. So your PCI bridge properly advertises itself as subtractive decode. Can you try the diff below? Thanks, Mark Thanks Mark, the patch works like a charm. As expected: ** ppb2 at pci0 dev 20 function 4 "ATI SB400 PCI" rev 0x00 ** pci3 at ppb2 bus 6 ** cbb0 at pci3 dev 9 function 0 "TI PCI7XX1 CardBus" rev 0x00: apic 1 int 23 ** cardslot0 at cbb0 slot 0 flags 0 ** cardbus0 at cardslot0: bus 7 device 0 cacheline 0x8, lattimer 0x20 ** pcmcia0 at cardslot0 ** wdc2 at pcmcia0 function 0 "SanDisk, SDP, 5/3 0.6" port 0xa000/16 ** wd1 at wdc2 channel 0 drive 0: ** wd1: 1-sector PIO, LBA, 61MB, 125440 sectors ** wd1(wdc2:0:0): using BIOS timings ** wd1 detached ** wdc2 detached I'm all for it ! Thanks, Thierry
Re: ATI SB400 PCI bridge fallback to substractive decode
On Mon, Sep 15, 2014 at 12:25:19AM +0200, Mark Kettenis wrote: Date: Sun, 14 Sep 2014 23:57:09 +0200 From: Thierry Deval Hi, When I put a CF to PCCard adapter (not CardBus) in my laptop to work on a CF boot image, I was surprised by this kernel message : ** wdc2 at pcmcia0 function 0 "SanDisk, SDP, 5/3 0.6": can't handle card info And the card was not working at all, as weren't any other PCCard I tried afterwards. After digging and enabling as much debugging as I could, I found that the cardbus bridge (TI PCI7xx1 CardBus) couldn't allocate any IO or mem range for the cards. Digging deeper to understand how the allocation should work, I noticed a comment in dev/pci/ppb.c talking about handling substractive (or is it really 'subtractive' as in the comment ? ) decode scheme for more than the Intel 82801 PCI bridge. So, as a test, I included the ATI SB400 PCI bridge (behind which the TI PCI7xx1 CardBus bridge was lying) to the substractive decode treatment. I was rewarded by a working CF card. ** ppb2 at pci0 dev 20 function 4 "ATI SB400 PCI" rev 0x00 ** pci3 at ppb2 bus 6 ** cbb0 at pci3 dev 9 function 0 "TI PCI7XX1 CardBus" rev 0x00: apic 1 int 23 ** cardslot0 at cbb0 slot 0 flags 0 ** cardbus0 at cardslot0: bus 7 device 0 cacheline 0x8, lattimer 0x20 ** pcmcia0 at cardslot0 ** wdc2 at pcmcia0 function 0 "SanDisk, SDP, 5/3 0.6" port 0xa000/16 ** wd1 at wdc2 channel 0 drive 0: ** wd1: 1-sector PIO, LBA, 61MB, 125440 sectors ** wd1(wdc2:0:0): using BIOS timings ** wd1 detached ** wdc2 detached I don't know if anybody else have seen the same problem but I would be glad to have a confirmation of the fix. Here's the diff: Index: ppb.c === RCS file: /cvs/src/sys/dev/pci/ppb.c,v retrieving revision 1.58 diff -u -p -u -p -r1.58 ppb.c --- ppb.c 12 Jul 2014 18:48:52 - 1.58 +++ ppb.c 14 Sep 2014 17:00:40 - @@ -286,9 +286,11 @@ ppbattach(struct device *parent, struct * XXX We probably should handle subtractive decode bridges * in general. */ - if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_INTEL && + if ((PCI_VENDOR(pa->pa_id) == PCI_VENDOR_INTEL && (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_82801BA_HPB || - PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_82801BAM_HPB)) { +PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_82801BAM_HPB)) || + (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_ATI && +PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_SB400_PCI)){ if (sc->sc_ioex == NULL) sc->sc_ioex = pa->pa_ioex; if (sc->sc_memex == NULL) I hope this could go in, at least as a first step. I plan on looking further about what this substractive decode means, and if there could be a generic way of enabling it where supported... Can you send pcidump -vxxx output for that machine? Sure Mark, here it is. (I compressed it to save mail real estate : 280k -> 14k) pcidump.gz Description: application/gunzip
ATI SB400 PCI bridge fallback to substractive decode
Hi, When I put a CF to PCCard adapter (not CardBus) in my laptop to work on a CF boot image, I was surprised by this kernel message : ** wdc2 at pcmcia0 function 0 "SanDisk, SDP, 5/3 0.6": can't handle card info And the card was not working at all, as weren't any other PCCard I tried afterwards. After digging and enabling as much debugging as I could, I found that the cardbus bridge (TI PCI7xx1 CardBus) couldn't allocate any IO or mem range for the cards. Digging deeper to understand how the allocation should work, I noticed a comment in dev/pci/ppb.c talking about handling substractive (or is it really 'subtractive' as in the comment ? ) decode scheme for more than the Intel 82801 PCI bridge. So, as a test, I included the ATI SB400 PCI bridge (behind which the TI PCI7xx1 CardBus bridge was lying) to the substractive decode treatment. I was rewarded by a working CF card. ** ppb2 at pci0 dev 20 function 4 "ATI SB400 PCI" rev 0x00 ** pci3 at ppb2 bus 6 ** cbb0 at pci3 dev 9 function 0 "TI PCI7XX1 CardBus" rev 0x00: apic 1 int 23 ** cardslot0 at cbb0 slot 0 flags 0 ** cardbus0 at cardslot0: bus 7 device 0 cacheline 0x8, lattimer 0x20 ** pcmcia0 at cardslot0 ** wdc2 at pcmcia0 function 0 "SanDisk, SDP, 5/3 0.6" port 0xa000/16 ** wd1 at wdc2 channel 0 drive 0: ** wd1: 1-sector PIO, LBA, 61MB, 125440 sectors ** wd1(wdc2:0:0): using BIOS timings ** wd1 detached ** wdc2 detached I don't know if anybody else have seen the same problem but I would be glad to have a confirmation of the fix. Here's the diff: Index: ppb.c === RCS file: /cvs/src/sys/dev/pci/ppb.c,v retrieving revision 1.58 diff -u -p -u -p -r1.58 ppb.c --- ppb.c 12 Jul 2014 18:48:52 - 1.58 +++ ppb.c 14 Sep 2014 17:00:40 - @@ -286,9 +286,11 @@ ppbattach(struct device *parent, struct * XXX We probably should handle subtractive decode bridges * in general. */ - if (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_INTEL && + if ((PCI_VENDOR(pa->pa_id) == PCI_VENDOR_INTEL && (PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_82801BA_HPB || - PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_82801BAM_HPB)) { +PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_INTEL_82801BAM_HPB)) || + (PCI_VENDOR(pa->pa_id) == PCI_VENDOR_ATI && +PCI_PRODUCT(pa->pa_id) == PCI_PRODUCT_ATI_SB400_PCI)){ if (sc->sc_ioex == NULL) sc->sc_ioex = pa->pa_ioex; if (sc->sc_memex == NULL) I hope this could go in, at least as a first step. I plan on looking further about what this substractive decode means, and if there could be a generic way of enabling it where supported... Thierry
Re: Speeding up openbsd on amd64 MP
On Sun, Sep 14, 2014 at 08:07:17PM +0200, Stefan Fritsch wrote: On Sunday 14 September 2014 12:13:44, Brent Cook wrote: Results for an old Athlon (hmm, I don't remember it running at 10.8 Ghz before) cpu0: AMD Athlon(tm) 64 X2 Dual Core Processor 6000+, 10823.06 MHz forktest 0m19.23s real 0m0.72s user 0m22.46s system forktest+0m16.33s real 0m0.50s user 0m18.22s system kernel -j2 3m0.68s real 5m10.95s user0m41.58s system kernel -j2+3m0.45s real 5m10.14s user0m41.53s system On Sunday 14 September 2014 19:16:41, Job Snijders wrote: The speedup kernel seems to perform slightly better: [root@speedup ~]# time ./forktest real0m33.134s user0m1.230s sys 0m53.710s [root@5.5stable ~]# time ./forktest real0m37.600s user0m1.200s sys 0m59.530s Thanks to both of you for testing. These results are more in line with my Core i7 and I expected the effect to be larger the large the number of CPUs is. Just my 6-year- old Core2 Duo does not fit in there and gives a much larger speedup. Maybe it is particularily bad at something the current pmap code does. Hello Stefan, This machine is an old AMD Turion64 @2GHz, and all tests were done with X off. cpu0: AMD Turion(tm) 64 Mobile Technology ML-37, 1990.08 MHz I tested by forcing CPU speed both low and high. -current apm -L Performance adjustment mode: manual (800 MHz) 41.62s real 2.26s user 24.32s system 40.35s real 2.21s user 24.65s system 38.40s real 2.18s user 23.27s system 40.15s real 2.30s user 23.64s system 41.15s real 2.34s user 22.77s system 38.77s real 2.03s user 23.49s system --- -- - ~ 40.24s real 2.22s user 23.69s system apm -H Performance adjustment mode: manual (2000 MHz) 19.51s real 0.80s user 11.91s system 19.95s real 1.00s user 12.44s system 19.28s real 0.76s user 12.29s system 19.53s real 0.74s user 11.81s system 18.49s real 0.90s user 11.51s system 19.94s real 0.94s user 12.44s system --- -- - ~ 19.45s real 0.85s user 12.06s system kernel -j29m22.59s real 8m17.30s user 47.90s system speeddup apm -L Performance adjustment mode: manual (800 MHz) 39.67s real 1.88s user 22.77s system 38.91s real 2.32s user 24.78s system 39.75s real 2.35s user 23.11s system 38.19s real 2.02s user 23.18s system 40.46s real 2.18s user 24.10s system 40.56s real 2.24s user 22.53s system --- -- - ~ 39.59s real 2.16s user 23.41s system apm -H Performance adjustment mode: manual (2000 MHz) 21.66s real 1.03s user 12.72s system 19.81s real 1.08s user 11.44s system 19.67s real 0.75s user 11.99s system 19.28s real 0.76s user 11.56s system 19.38s real 0.92s user 12.10s system 19.71s real 1.00s user 12.17s system --- -- - ~ 19.91s real 0.92s user 11.99s system kernel -j29m38.43s real 8m32.10s user 49.10s system As you can see, there is not much difference in speed, but it looks stable. But as it's SP only, it's probably expected. Unfortunately, my MP AMD PhenomII x8 is currently used as a SmartOS virtualizer. I may try to load a MP VM to test the patch on it, but it will have to wait a bit more. Thierry