Re: malloc should always abort

[Thierry Deval]

​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

[Thierry Deval]

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

[Thierry Deval]

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

[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 thierry+openbsd.t...@deval.be

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: SanDisk SDCFB-64
** 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

Re: ATI SB400 PCI bridge fallback to substractive decode

[Thierry Deval]

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 thierry+openbsd.t...@deval.be

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 thierry+openbsd.t...@deval.be

 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

diff snipped


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: SanDisk SDCFB-64
** 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: Speeding up openbsd on amd64 MP

[Thierry Deval]

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

ATI SB400 PCI bridge fallback to substractive decode

[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: SanDisk SDCFB-64
** 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