The modesetting driver uses acceleration or not?

2018-04-06 Thread Zsolt Kantor
Hello,

In the modesetting video driver man page states that it is a non-accelerated 
driver, but you have a option to set the acceleration method. If it is 
non-accelerated driver why can you set the acceleration?

Thanks.



Re: How is the synaptics driver loaded in OpenBSD v6.2, thanks.

2018-03-27 Thread Zsolt Kantor

Ok, thanks!





On Tuesday, March 27, 2018, 3:07:28 PM GMT+3, Ulf Brosziewski 
<ulf.brosziew...@t-online.de> wrote: 





The short answer is:  The X server has hard-coded defaults, which
can be overridden by configuration files, which are processed in a
specific order - if they are present.  Please see xorg.conf(5) for
details.  For customizing the settings, you have to *create* an
/etc/xorg.conf file.

70-synaptics.conf is no "example". In 6.2, its "Driver" setting
matches the programmatic default for touchpads (synaptics). In 6.3,
the driver setting is gone, and the program default is different
(it's ws).

On 03/26/2018 09:27 PM, Zsolt Kantor wrote:
> Hello to all. 
> I'm using OpenBSD 6.2. I try to figure out how is loaded the synaptics 
> driver. In the /var/log/Xorg.0.log file I can see that the driver is loaded 
> by X:
> 
> LoadModule: "synaptics"
> Loading /usr/X11R6/lib/modules/input/synaptics_drv.so
> . . .
>  
> But I can not find in any configuration file to be declared, I searched the 
> whole system using grep for the synaptics pattern, but I did not found any 
> relevant config files, or something like that. There is  a 
> /usr/X11R6/share/X11/xorg.conf.d/70-synaptics.conf file, but that is just an 
> example, because if I remove it, the driver still loads. In OpenBSD 6.2 there 
> is also no xorg.conf file. So If I would guess I think the X server 
> automatically recognizes my touchpad and loads the appropriate driver from 
> the path /usr/X11R6/lib/modules/input/. Is that correct? Or the driver is 
> loaded in a different way?
> 
> Thanks!
> 
> 



How is the synaptics driver loaded in OpenBSD v6.2, thanks.

2018-03-26 Thread Zsolt Kantor
Hello to all. 
I'm using OpenBSD 6.2. I try to figure out how is loaded the synaptics driver. 
In the /var/log/Xorg.0.log file I can see that the driver is loaded by X:

LoadModule: "synaptics"
Loading /usr/X11R6/lib/modules/input/synaptics_drv.so
. . .
 
But I can not find in any configuration file to be declared, I searched the 
whole system using grep for the synaptics pattern, but I did not found any 
relevant config files, or something like that. There is  a 
/usr/X11R6/share/X11/xorg.conf.d/70-synaptics.conf file, but that is just an 
example, because if I remove it, the driver still loads. In OpenBSD 6.2 there 
is also no xorg.conf file. So If I would guess I think the X server 
automatically recognizes my touchpad and loads the appropriate driver from the 
path /usr/X11R6/lib/modules/input/. Is that correct? Or the driver is loaded in 
a different way?

Thanks!



Re: With the latest snapshot there are some issues in Xfce, please help!

2018-03-18 Thread Zsolt Kantor
 For the snapshot packages I was told to use pkg_add -u first, and after that 
install the preferred package. That worked.
For the terminal I will check out the ports mailing list.For the touchpad, I 
got the point, thanks.


On Sunday, March 18, 2018, 2:37:40 PM GMT+2, Dave Voutila <d...@sisu.io> 
wrote:  
 
 Zsolt Kantor <zsoltkan...@yahoo.co.uk> writes:

> Hello to all.
> I installed the latest snapshot with Xfce. But there are some issues whit 
> Xfce. I found 3 problems.
>
> 1. The terminal size is very expanded, it is not 80x..., its 145x..., but if 
> I check the terminal properties the width setting is 80. Very strange.
>

The XFCE terminal? Might want to check ports@. No idea if this is an
upstream change or in the port itself.

> 2. There are some dependency problems when I try to install chromium
> or firefox. For instance the colord package can not be found in the
> snapshot packages repository, and other package dependency problems
> are also displayed. So I can't install Chromium or Firefox.

The snapshots are a moving target given the impending release of 6.3. 

Are you using `pkg_add -Dsnap firefox`? 

You might also need to grab the most recent build of -current if 
libraries were bumped. A dmesg would tell people if you're up to date
or not.

>
> 3. My synaptic touchpad is not fully functional. In Xfce the touchpad
> tab is missing from the mouse and touchpad configuration window. This
> is not the case of 6.2. In OpenBSD 6.2 it was there.
>

See note from 2017/12/05: https://www.openbsd.org/faq/current.html

You probably need a custom Xorg config, but if there is regression in
functionality I'm sure reporting the delta and a dmesg would be
helpful. Personally I've seen some improvements, but there were initial
regressions that were reported and I believe resolved or worked
around.

> Will these issues corrected until the release? Or should I send an e-mail to 
> the bug's mailing list?
>
> Thanks!
  


With the latest snapshot there are some issues in Xfce, please help!

2018-03-17 Thread Zsolt Kantor
Hello to all.
I installed the latest snapshot with Xfce. But there are some issues whit Xfce. 
I found 3 problems.

1. The terminal size is very expanded, it is not 80x..., its 145x..., but if I 
check the terminal properties the width setting is 80. Very strange.

2. There are some dependency problems when I try to install chromium or 
firefox. For instance the colord package can not be found in the snapshot 
packages repository, and other package dependency problems are also displayed. 
So I can't install Chromium or Firefox.

3. My synaptic touchpad is not fully functional. In Xfce the touchpad tab is 
missing from the mouse and touchpad configuration window. This is not the case 
of 6.2. In OpenBSD 6.2 it was there.

Will these issues corrected until the release? Or should I send an e-mail to 
the bug's mailing list?

Thanks!



Annoyingly low drm resolution on OpenBSD 6.2

2018-03-07 Thread Zsolt Kantor
Hello,
In OpenBSD 6.2 the inteldrm driver was updated to code based on Linux 4.4.70 as 
in the changelog states.
I'm using OpenBSD 6.1 and with this version the resolution at boot time is set 
to  1280x800. But with OpenBSD 6.2 the resolution is set to 840x600 (or 
something like that). Is this because the driver was updated?? I would like to 
use 6.2, but that resolution is annoying on the TTy's (it does not fill the 
whole screen when using vi, cat, less . . . or any other program). Can that 
resolution changed, or it is hard coded into the driver/kernel? Is this 
resolution change between 6.1 versus 6.2 related to the updates made in the 
inteldrm driver?



Re: Please explain the pkg_check F option, thank you.

2018-02-28 Thread Zsolt Kantor


By the way. For a simple user (I'm using OpenBSD just for fun, and learning) it 
is worth to enable the weekly script, or not?

Thanks,
Zsolt



Re: Please explain the pkg_check F option, thank you.

2018-02-28 Thread Zsolt Kantor
Thanks Sebastien, I just figured out this. Now everything is clear.
If I may propose something . . . those "Not found" items even if it is not an 
error, is a little bit misleading . . . From a simple user's point of view the 
pkg_check -F in normal circumstances should return cleanly. Maybe an extra 
option for pkg_check in future that tells to show those "Not found" items (by 
default not to show).



On Wednesday, February 28, 2018 9:06 PM, Sebastien Marie <sema...@online.fr> 
wrote:



On Wed, Feb 28, 2018 at 06:56:17PM +, Zsolt Kantor wrote:

> Another question.
> pkg_check -F uses pkg_locate script to locate package files, directories.
> pkg_locate uses locate to do that.
> Question: If I use pkg_locate bsd.rd nothing is returned, but if I use locate 
> bsd.rd the ramdisk kernel is returned. Why? Is pkg_locate not working 
> correctly? Or I'm missing something?

pkg_locate uses a database populated with all files from ports
(installed packages or not).

locate uses a database populated with updatedb, and it contains only
files installed on filesystem (it is updated weekly).

so pkg_locate bsd.rd searchs if a file "bsd.rd" exists in some port
(installed or not); whereas locate bsd.rd searchs if a file "bsd.rd"
exists in current filesystem.

-- 
Sebastien Marie



Re: Please explain the pkg_check F option, thank you.

2018-02-28 Thread Zsolt Kantor
Another question.
pkg_check -F uses pkg_locate script to locate package files, directories.
pkg_locate uses locate to do that.
Question: If I use pkg_locate bsd.rd nothing is returned, but if I use locate 
bsd.rd the ramdisk kernel is returned. Why? Is pkg_locate not working 
correctly? Or I'm missing something?



Please explain the pkg_check F option, thank you.

2018-02-27 Thread Zsolt Kantor
What exactly does the pkg_check -F option?  If I use it, it does some 
filesystem check, and some "Locating unknown files".

At the end I get: "Locating unknown files: ok", "Locating unknown directories: 
ok", and a long list of "not found" directories and files, like below.
Not found:
/boot
/bsd
/bsd.rd
/bsd.sp
/bsd.syspatch61
/etc/X11/xenodm/authdir
. . . . 


At the really end I get this: Locating unknown directories: ok

I don't understand what is with that list of "not found" files.
In the manual page it does not say much about this option (or I don't 
understand much), it only states: "-F  Check the filesystem for random 
objects.".

Q1: What are those random objects?
Q2: It actually checks the file system?? (like fsck)
Q3: What's about that long list of not found directories and files?



Re: Why is so slow the download speed in OpenBSD?

2018-02-15 Thread Zsolt Kantor
Ok, in this case, what I understood is that the "optimal rate algorithm" needs 
to be updated, rewritten, corrected . . . etc. I was also a programmer once, 
and I know that this can't happen from one day to another, so as a workaround I 
propose the following: mention about these "issue" in the afterboot manual 
(afterboot - things to check after the first complete boot) . For more about 
afterboot type man afterboot.



On Thursday, February 15, 2018 1:46 AM, Charlie Eddy 
<charlie.e...@occipital.com> wrote:



Nice!

>From Stefan's mail:
>"In the current implementation, the wifi layer selects a transmit rate 
>based>on the number of frame transmission retries reported by wpi(4) firmware."

That's the "automatically selected optimal media type", comme ci comme ca 
defined w/r/t the strictness of your definition.

>"If you find that one of these commands makes it work as fast as it does on
>Windows, we can conclude that the problem is with OpenBSD's rate selection
>algorithm. This algorithm is very old and dates from a time when wifi networks
>were much less densly deployed."


It looks like OpenBSD is like driving a beautiful old car. Malfunction doesn't 
make sense to say even though existing properties of the OS and existing 
properties of the world aren't making it easy.


On Wed, Feb 14, 2018 at 1:47 PM, Zsolt Kantor <zsoltkan...@yahoo.co.uk> wrote:


>
>Now, I just switched to OpenBSD, and executed the commands as you wrote down. 
>AND IT WORKS!
>You have more in depth network knowledge than me, so I just will write down 
>what I did, and I have also some questions related to that media option of the 
>ifconfig (which I, to be honest don't really understand).
>So, I used the same mirror (https://ftp2.eu.openbsd.org/ 
>pub/OpenBSD/6.2/amd64/) for testing and used only wget for downloads. With 
>wget the download speed is a bit higher compared to firefox or chromium, I 
>think because wget is more 'light', command line tool, more optimized 
>(probably the code is more clear), firefox and chromium opens slower maybe 
>also bloat in code, so the download rate is also less.
>Now back to the point. I logged in to Xfce, I opened a terminal with two tabs, 
>one for normal user, to execute the downloads, with the following command: 
>'wget https://ftp2.eu.openbsd.org/ pub/OpenBSD/6.2/amd64/ install62.fs', and 
>one for root user to use ifconfig to make those settings. After every ifconfig 
>change, I switched to the normal user tab and started the download process 
>(sometimes, when I saw some unusual fluctuation I interrupted the download 
>process and started again, waited a while to see what happens, than if the 
>download process was not stable I waited a little to be just sure, after that 
>started the process again and so on, to have a more precise report).
>Here are the test results:
>OFDM6: max: 1.30MB/s, min: 700KB/s (this config. is not stable, sometimes 
>drops from 1.20MB/s to 700KB and back)
>OFDM9: average: 1.45MB/s (more stable, do not drops above 1.30MB)
>OFDM12: quite stable as with OFDM9, sometimes reaches a max. of 1.70MB/s
>OFDM18: stable, average: 1.50MB (I saw also 1.80MB/s for fractions of seconds)
>OFDM24: At the first try was not stable, fluctuated between 900KB/s and 
>1.70Mb/s, at the second try it was stable, avg: 1.55MB/s (for fractions of 
>seconds 1.80MB/s), at the third, fourth . . . tries was stable, avg: 1.60MB
>OFDM36: quiet stable, avg: 1.55MB/s
>OFDM48: not so stable, 700KB/s, 800KB/s, rarely reaches  1000KB/s (but 
>immediately drops)
>OFDM54: not stable at all, between 700KB and 900KB (sometimes reaches 1.1MB/s, 
>rarely drops down to 300KB/s), the avg. rate is 700-750KB.
>
>These for the tests. Now, I have a few questions. In the ifconfig manual at 
>the media option states that if it is used with no arguments displays all 
>available media. In my case it looks like this:
>
>supported media:
>media autoselect
>media autoselect mediaopt monitor
>media autoselect mode 11a
>media autoselect mode 11a mediaopt monitor
>media autoselect mode 11b
>media autoselect mode 11b mediaopt monitor
>media autoselect mode 11g
>media autoselect mode 11g mediaopt monitor
>
>But what you proposed to me to try is OFDM6, 9, 12 . . . In the supported 
>media list I don't find those types, why?
>
>The second question is: now theoretically the problem is solved, to be honest 
>I have no clue about media types, radio frequencies and such things, but based 
>on my tests it's need to be corrected something in OpenBSD related to this 
>issue? Or it is more like a user side configuration? If somebody would ask me 
>I think the optimal media type should ne automatically selected by the system 
>(driver, firmware . . . I don't know who'

Re: Why is so slow the download speed in OpenBSD?

2018-02-14 Thread Zsolt Kantor


Now, I just switched to OpenBSD, and executed the commands as you wrote down. 
AND IT WORKS!
You have more in depth network knowledge than me, so I just will write down 
what I did, and I have also some questions related to that media option of the 
ifconfig (which I, to be honest don't really understand).
So, I used the same mirror (https://ftp2.eu.openbsd.org/pub/OpenBSD/6.2/amd64/) 
for testing and used only wget for downloads. With wget the download speed is a 
bit higher compared to firefox or chromium, I think because wget is more 
'light', command line tool, more optimized (probably the code is more clear), 
firefox and chromium opens slower maybe also bloat in code, so the download 
rate is also less.
Now back to the point. I logged in to Xfce, I opened a terminal with two tabs, 
one for normal user, to execute the downloads, with the following command: 
'wget https://ftp2.eu.openbsd.org/pub/OpenBSD/6.2/amd64/install62.fs', and one 
for root user to use ifconfig to make those settings. After every ifconfig 
change, I switched to the normal user tab and started the download process 
(sometimes, when I saw some unusual fluctuation I interrupted the download 
process and started again, waited a while to see what happens, than if the 
download process was not stable I waited a little to be just sure, after that 
started the process again and so on, to have a more precise report).
Here are the test results:
OFDM6: max: 1.30MB/s, min: 700KB/s (this config. is not stable, sometimes drops 
from 1.20MB/s to 700KB and back)
OFDM9: average: 1.45MB/s (more stable, do not drops above 1.30MB)
OFDM12: quite stable as with OFDM9, sometimes reaches a max. of 1.70MB/s
OFDM18: stable, average: 1.50MB (I saw also 1.80MB/s for fractions of seconds)
OFDM24: At the first try was not stable, fluctuated between 900KB/s and 
1.70Mb/s, at the second try it was stable, avg: 1.55MB/s (for fractions of 
seconds 1.80MB/s), at the third, fourth . . . tries was stable, avg: 1.60MB
OFDM36: quiet stable, avg: 1.55MB/s
OFDM48: not so stable, 700KB/s, 800KB/s, rarely reaches  1000KB/s (but 
immediately drops)
OFDM54: not stable at all, between 700KB and 900KB (sometimes reaches 1.1MB/s, 
rarely drops down to 300KB/s), the avg. rate is 700-750KB.

These for the tests. Now, I have a few questions. In the ifconfig manual at the 
media option states that if it is used with no arguments displays all available 
media. In my case it looks like this:

supported media:
media autoselect
media autoselect mediaopt monitor
media autoselect mode 11a
media autoselect mode 11a mediaopt monitor
media autoselect mode 11b
media autoselect mode 11b mediaopt monitor
media autoselect mode 11g
media autoselect mode 11g mediaopt monitor

But what you proposed to me to try is OFDM6, 9, 12 . . . In the supported media 
list I don't find those types, why?

The second question is: now theoretically the problem is solved, to be honest I 
have no clue about media types, radio frequencies and such things, but based on 
my tests it's need to be corrected something in OpenBSD related to this issue? 
Or it is more like a user side configuration? If somebody would ask me I think 
the optimal media type should ne automatically selected by the system (driver, 
firmware . . . I don't know who's in charge for this), and not by the user 
(after the system is installed).
That's all, thanks again. For me the problem is solved. You need to decide if 
this is a malfunction or not.

Thanks again.




On Wednesday, February 14, 2018 9:36 PM, Zsolt Kantor <zsoltkan...@yahoo.co.uk> 
wrote:



You told me a very interesting thing, and I need to admit that I did not 
thought about this (although in the past I wrote some ping program using 
sockets, so I have a basic knowledge about networking in general). I will try 
that, but right now I need to resolve other things (not related to OpenBSD), I 
also thought to do some wireshark tests in  Win and BSD and check the traffic, 
the packets, and the times between the packets sent and received. I also want 
to test the wired connection in OpenBSD. I'm only using wifi, I have no wires 
to connect to the router, so I need to buy one and test. I also need to study a 
little bit more how transmissions are working in OpenBSD, the layers, etc. I 
will be back when I have some concrete result.

Thanks for the advices,
Zsolt



On Wednesday, February 14, 2018 1:09 PM, Stefan Sperling <s...@stsp.name> wrote:



On Tue, Feb 13, 2018 at 11:00:39PM +, Zsolt Kantor wrote:
> So if you have any idea, any new testing method, please tell me, I will try.

The information we'd need to fix anyting is still not there because
what you are measuring is the result of an interaction between many
layers: application, sockets, TCP, IP, wifi, physical medium (radio).

In order to fix anything we'll need to determine which layer is
causing the problem, and why.

I can make a guess, based on my knowledge of how the wifi layer behaves:

The tra

Re: Why is so slow the download speed in OpenBSD?

2018-02-14 Thread Zsolt Kantor
You told me a very interesting thing, and I need to admit that I did not 
thought about this (although in the past I wrote some ping program using 
sockets, so I have a basic knowledge about networking in general). I will try 
that, but right now I need to resolve other things (not related to OpenBSD), I 
also thought to do some wireshark tests in  Win and BSD and check the traffic, 
the packets, and the times between the packets sent and received. I also want 
to test the wired connection in OpenBSD. I'm only using wifi, I have no wires 
to connect to the router, so I need to buy one and test. I also need to study a 
little bit more how transmissions are working in OpenBSD, the layers, etc. I 
will be back when I have some concrete result.

Thanks for the advices,
Zsolt


On Wednesday, February 14, 2018 1:09 PM, Stefan Sperling <s...@stsp.name> wrote:



On Tue, Feb 13, 2018 at 11:00:39PM +, Zsolt Kantor wrote:
> So if you have any idea, any new testing method, please tell me, I will try.

The information we'd need to fix anyting is still not there because
what you are measuring is the result of an interaction between many
layers: application, sockets, TCP, IP, wifi, physical medium (radio).

In order to fix anything we'll need to determine which layer is
causing the problem, and why.

I can make a guess, based on my knowledge of how the wifi layer behaves:

The transmit rate used by wpi(4) is selected dynamically by the wifi layer.
The higher the selected transmit rate is the faster your TCP stream will
be because your TCP ACKs will flow faster.

In the current implementation, the wifi layer selects a transmit rate based
on the number of frame transmission retries reported by wpi(4) firmware.

Frame transmission retries at a given transmit rate will happen if either:

1) You are too far away from the AP. A lower rate has more chance
   of getting through so lowering the rate is a good idea.


or:

2) You are close to the AP but there is lots of unrelated wifi traffic
   on the same channel using up air time. Attempts to transmit a frame
   are often blocked by other legitimate frames on the air, so we need
   more than one attempt and all our attempts get counted as retries,
   and now we end up using a lower transmit rate.
   Using a lower rate in this situation means we use up more air time
   and make the problem even worse, not just for us but for everyone
   on this channel.

The access point density in many residential buildings today means that
case 2 is very likely and case 1 is very unlikely, especially on a 2GHz
channel. Adapting the transmit rate based on retries doesn't achieve
the desired result in this situation, so your download speed sucks.

You can test my theory by disabling the automatic rate selection algorithm
and tell wpi(4) to send all frames at a transmit rate of your choice.
To do so, associate to the AP, and now fix the transmit rate as shown below.
Repeat your test each time after changing the transmit rate.

  ifconfig wpi0 media OFDM6 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM9 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM12 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM18 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM24 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM36 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM48 mode 11g
  # repeat test
  ifconfig wpi0 media OFDM54 mode 11g
  # repeat test

If you find that one of these commands makes it work as fast as it does on
Windows, we can conclude that the problem is with OpenBSD's rate selection
algorithm. This algorithm is very old and dates from a time when wifi networks
were much less densly deployed. Windows is probably using a different algorithm
to make decisions about which transmit rate to use (for reference, it probably
uses a similar algorithm as was implemented in Intel's Linux iwlegacy driver,
in file 3945-rs.c of that driver's source code).



Re: Why is so slow the download speed in OpenBSD?

2018-02-13 Thread Zsolt Kantor
I just made a quick test using the same browser (to not to complicate things 
with wget) firefox (almost the same versions, the ESR release line). Used the 
mirror: https://ftp2.eu.openbsd.org/pub/OpenBSD/6.2/amd64/
Started to download the file: install62.fs (360MB)
In OpenBSD when the download starts: 11 minutes (remaining), download rate: 
fluctuating between 450-480 KB/sec, sometimes drops to 320-350 KB/sec, and the 
remaining time increases to 14 minutes. I wrote here the units (minutes, KB, 
sec) exactly as appears in the firefox download window.
In Windows using the same mirror and the same file, on the other hand the 
starting download rate is between 1300-1400 KB/sec, and so of course the 
download time is 2-3 minutes.
Just for more info, and to be more precise with the tests I used wget too in 
OpenBSD. Her is the output of wget after the downloading was started for about 
10 seconds:

$ wget https://ftp2.eu.openbsd.org/pub/OpenBSD/6.2/amd64/install62.fs 
--2018-02-14 00:39:01--  
https://ftp2.eu.openbsd.org/pub/OpenBSD/6.2/amd64/install62.fs
Resolving ftp2.eu.openbsd.org (ftp2.eu.openbsd.org)... 137.208.8.135
Connecting to ftp2.eu.openbsd.org (ftp2.eu.openbsd.org)|137.208.8.135|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 377978880 (360M)
Saving to: 'install62.fs'

install62.fs  1%[   
   ]   6.63M   648KB/seta 9m 16s ^C
$ 


It is interesting to observe that with wget the download speed is a little bit 
higher, but far to be as high as in Windows.

So if you have any idea, any new testing method, please tell me, I will try. 
But after all those tests as I mentioned above, I really think is an issue with 
the OpenBSD wifi (I'm not a specialist so I can not tell if it is a firmware 
issue, or default configuration issue, but I think it is.) To be honest my 
humbling opinion is that it is a firmware issue, Because I saw once in the 
system message buffer a wpi firmware error (I already mentioned this in an 
earlier message in the same thread, so you can look around, or if you want I 
could find it for you and show it).
And to answer your question more directly as you can see the programs that I 
used to test the speed always used KB/s (in case of wget), or KB/sec (in case 
of firefox). So it is absolutely excluded the term of bits.


Thanks,
Zsolt




> There is a bit of information that I am missing. You mentioned that the
> throughput on your Amilo, with OpenBSD, is 240KB/s whereas "other OS"
> (SiC) is able to get a throughput of 1.4MB/s.

> What application are you using to measure the performance? And this is
> not meant as an insult, but could it be that whatever you are using on
> OpenBSD shows the speed in KByte/s, whereas "other OS" shows it in
> Mbit/s?

> Second, this might seem unrelated, could you list your fstab? I would
> like to know whether to applied the 'noatime,softdep' options :-)

> Regards
> -J.

On Mon, 2018-02-12 at 22:24 +, Zsolt Kantor wrote:
> I've tried different channels and also different modes, I even
> replaced the 6.2 firmware with the snapshot (the snapshot version is
> a little bit bigger in size) hoping that it will work better. To be
> sure with the configuration I used the same channel and mode with
> which in other OS (Windows) is working well. So now I'm even more
> close to the idea that it is a bug in the firmware. If somebody can
> guaranty that it is not from the firmware than it should be a
> configuration issue, but as I stated before I have not touched
> anything related to network configuration, I just made a fresh
> install and the basic config to set up xfce, that's all.
> Probably I will fill out a bug report.
> Thanks for the support, If you have some other ideas please let me
> know. 
> 
> 
> 



Re: Why is so slow the download speed in OpenBSD?

2018-02-12 Thread Zsolt Kantor
I've tried different channels and also different modes, I even replaced the 6.2 
firmware with the snapshot (the snapshot version is a little bit bigger in 
size) hoping that it will work better. To be sure with the configuration I used 
the same channel and mode with which in other OS (Windows) is working well. So 
now I'm even more close to the idea that it is a bug in the firmware. If 
somebody can guaranty that it is not from the firmware than it should be a 
configuration issue, but as I stated before I have not touched anything related 
to network configuration, I just made a fresh install and the basic config to 
set up xfce, that's all.
Probably I will fill out a bug report.
Thanks for the support, If you have some other ideas please let me know.   


On Monday, February 12, 2018 2:48 PM, "ed...@pettijohn-web.com" 
<ed...@pettijohn-web.com> wrote:



Try different channels. See the wireless section of ifconfig(8).

On Feb 12, 2018 3:02 AM, Zsolt Kantor <zsoltkan...@yahoo.co.uk> wrote:

>

> I tried that, but as Edgar said it downloaded all the firmware's from the 
> site, even those I'm not needing, eg. radeondrm, but I'm using inteldrm.

>

> I want to send a bug report, but (with a big b) the question is who gonna 
> debug the firmware, because as I know those firmware's are non-free code, so 
> maybe it is not even the 'job' of the OpenBSD developers to fix the error.

>

>

> On Monday, February 12, 2018 5:41 AM, Tom Smyth 
> <tom.sm...@wirelessconnect.eu> wrote:

>

>

>

> Hi Zolt

>

> when your laptop is on line try

>

> fw_update -a

> command to update firmware...  you probably were not online when the

> firmware update command ran (on first boot after install)

> See what happens when you run that command ..

>

> Thanks

> Tom Smyth

>

> On 11 February 2018 at 23:15, Zsolt Kantor <zsoltkan...@yahoo.co.uk> wrote:

> > Below I provide full information from ifconfig, route and a full dmesg. By 
> > the way, I think this is a BUG in the wireless firmware that I'm using 
> > (downloaded from the OpenBSD firmware site). I say this because I found 
> > this line in the dmesg output: wpi0: fatal firmware error

> >

> > So below are the outputs.

> >

> > ifconfig output:

> >

> > lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768

> > index 4 priority 0 llprio 3

> > groups: lo

> > inet6 ::1 prefixlen 128

> > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4

> > inet 127.0.0.1 netmask 0xff00

> > re0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500

> > lladdr 00:1f:16:03:90:fe

> > index 1 priority 0 llprio 3

> > media: Ethernet autoselect (none)

> > status: no carrier

> > wpi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

> > lladdr 00:1f:3c:8d:aa:a2

> > index 2 priority 4 llprio 3

> > groups: wlan egress

> > media: IEEE802.11 autoselect (DS1 mode 11g)

> > status: active

> > ieee80211: nwid zsolt chan 11 bssid 70:4f:57:2c:b1:04 -42dBm wpakey  > displayed> wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp

> > inet 192.168.0.101 netmask 0xff00 broadcast 192.168.0.255

> > enc0: flags=0<>

> > index 3 priority 0 llprio 3

> > groups: enc

> > status: active

> > pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136

> > index 5 priority 0 llprio 3

> > groups: pflog

> >

> >

> >

> > route -n show output:

> >

> > Routing tables

> >

> > Internet:

> > DestinationGatewayFlags   Refs  Use   Mtu  Prio 
> > Iface

> > default192.168.0.1UGS3  450 -12 wpi0

> > 224/4  127.0.0.1  URS0   12 32768 8 lo0

> > 127/8  127.0.0.1  UGRS   00 32768 8 lo0

> > 127.0.0.1  127.0.0.1  UHhl   1 3101 32768 1 lo0

> > 192.168.0/24   192.168.0.101  UCn10 - 8 wpi0

> > 192.168.0.170:4f:57:2c:b1:04  UHLch  2  267 - 7 wpi0

> > 192.168.0.101  00:1f:3c:8d:aa:a2  UHLl   0  831 - 1 wpi0

> > 192.168.0.255  192.168.0.101  UHb00 - 1 wpi0

> >

> > Internet6:

> > DestinationGatewayFlags   
> > Refs  Use   Mtu  Prio Iface

> > ::/96  ::1UGRS  
> >  00 32768 8 lo0

> > ::/104 ::1UGRS  
> >  0

Re: Why is so slow the download speed in OpenBSD?

2018-02-12 Thread Zsolt Kantor
I tried that, but as Edgar said it downloaded all the firmware's from the site, 
even those I'm not needing, eg. radeondrm, but I'm using inteldrm.

I want to send a bug report, but (with a big b) the question is who gonna debug 
the firmware, because as I know those firmware's are non-free code, so maybe it 
is not even the 'job' of the OpenBSD developers to fix the error.


On Monday, February 12, 2018 5:41 AM, Tom Smyth <tom.sm...@wirelessconnect.eu> 
wrote:



Hi Zolt

when your laptop is on line try

fw_update -a
command to update firmware...  you probably were not online when the
firmware update command ran (on first boot after install)
See what happens when you run that command ..

Thanks
Tom Smyth

On 11 February 2018 at 23:15, Zsolt Kantor <zsoltkan...@yahoo.co.uk> wrote:
> Below I provide full information from ifconfig, route and a full dmesg. By 
> the way, I think this is a BUG in the wireless firmware that I'm using 
> (downloaded from the OpenBSD firmware site). I say this because I found this 
> line in the dmesg output: wpi0: fatal firmware error
>
> So below are the outputs.
>
> ifconfig output:
>
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 32768
> index 4 priority 0 llprio 3
> groups: lo
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
> inet 127.0.0.1 netmask 0xff00
> re0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:1f:16:03:90:fe
> index 1 priority 0 llprio 3
> media: Ethernet autoselect (none)
> status: no carrier
> wpi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
> lladdr 00:1f:3c:8d:aa:a2
> index 2 priority 4 llprio 3
> groups: wlan egress
> media: IEEE802.11 autoselect (DS1 mode 11g)
> status: active
> ieee80211: nwid zsolt chan 11 bssid 70:4f:57:2c:b1:04 -42dBm wpakey  displayed> wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp
> inet 192.168.0.101 netmask 0xff00 broadcast 192.168.0.255
> enc0: flags=0<>
> index 3 priority 0 llprio 3
> groups: enc
> status: active
> pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136
> index 5 priority 0 llprio 3
> groups: pflog
>
>
>
> route -n show output:
>
> Routing tables
>
> Internet:
> DestinationGatewayFlags   Refs  Use   Mtu  Prio Iface
> default192.168.0.1UGS3  450 -12 wpi0
> 224/4  127.0.0.1  URS0   12 32768 8 lo0
> 127/8  127.0.0.1  UGRS   00 32768 8 lo0
> 127.0.0.1  127.0.0.1  UHhl   1 3101 32768 1 lo0
> 192.168.0/24   192.168.0.101  UCn10 - 8 wpi0
> 192.168.0.170:4f:57:2c:b1:04  UHLch  2  267 - 7 wpi0
> 192.168.0.101  00:1f:3c:8d:aa:a2  UHLl   0  831 - 1 wpi0
> 192.168.0.255  192.168.0.101  UHb00 - 1 wpi0
>
> Internet6:
> DestinationGatewayFlags   
> Refs  Use   Mtu  Prio Iface
> ::/96  ::1UGRS   
> 00 32768 8 lo0
> ::/104 ::1UGRS   
> 00 32768 8 lo0
> ::1::1UHhl  
> 14   34 32768 1 lo0
> ::127.0.0.0/104::1UGRS   
> 00 32768 8 lo0
> ::224.0.0.0/100::1UGRS   
> 00 32768 8 lo0
> ::255.0.0.0/104::1UGRS   
> 00 32768 8 lo0
> :::0.0.0.0/96  ::1UGRS   
> 00 32768 8 lo0
> 2002::/24  ::1UGRS   
> 00 32768 8 lo0
> 2002:7f00::/24 ::1UGRS   
> 00 32768 8 lo0
> 2002:e000::/20 ::1UGRS   
> 00 32768 8 lo0
> 2002:ff00::/24 ::1UGRS   
> 00 32768 8 lo0
> fe80::/10  ::1UGRS   
> 00 32768 8 lo0
> fec0::/10  ::1UGRS   
> 00 32768 8 lo0
> fe80::1%lo0fe80::1%lo0UHl
> 00 32768 1 lo0
> ff01::/16  ::1UGRS   
> 00 32768 8 lo0
> ff01::%lo0/32  ::1

Re: Why is so slow the download speed in OpenBSD?

2018-02-11 Thread Zsolt Kantor
First of all I must to clarify that I'm newbie in networking and there are some 
thinks that I don't understand in your message, but, I will do anything you ask 
to resolve the problem, because I think this is a bug in the wifi firmware that 
I'm using (please read the reply sent to Tom). I'm running the default config, 
I have not modified anything related to the network. I will paste here the 
config file output and the command output.
This is in my pf.conf:

#   $OpenBSD: pf.conf,v 1.54 2014/08/23 05:49:42 deraadt Exp $
#
# See pf.conf(5) and /etc/examples/pf.conf

set skip on lo

block return# block stateless traffic
pass# establish keep-state

# By default, do not permit remote connections to X11
block return in on ! lo0 proto tcp to port 6000:6010


this is the output of that command:

block return all
pass all flags S/SA
block return in on ! lo0 proto tcp from any to any port 6000:6010



Re: Why is so slow the download speed in OpenBSD?

2018-02-11 Thread Zsolt Kantor
B DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM
spdmem1 at iic0 addr 0x52: 1GB DDR2 SDRAM non-parity PC2-5300CL5 SO-DIMM
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb6 at uhci4: USB revision 1.0
uhub6 at usb6 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
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 touchpad, firmware 6.3, 0x1280b1 0xa04000
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vblank wait timed out on crtc 1
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (eb090922f0f6e0ef.a) swap on wd0b dump on wd0b
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
wpi0: fatal firmware error
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1
vblank wait timed out on crtc 1

 
 




On Sunday, February 11, 2018 9:33 PM, Tom Smyth <tom.sm...@wirelessconnect.eu> 
wrote:



Hi Zsolt,

in order to help us help you try to include more information

output from dmesg  ,  what is your network configuration

ifconfig
route -n show

there is no default queuing in OpenBSD that would limit you that
badly

Thanks





On 11 February 2018 at 19:15, Zsolt Kantor <zsoltkan...@yahoo.co.uk> wrote:
> Hello,
> I'm using the latest release. Where the dl speed in other OS is approx. 1.4 
> MB/s in BSD is only approx. 240 KB/s. Why is this? Is about a setting in some 
> config file that limits download/traffic rate?
>
> Thanks.
>



-- 
Kindest regards,
Tom Smyth

Mobile: +353 87 6193172
The information contained in this E-mail is intended only for the
confidential use of the named recipient. If the reader of this message
is not the intended recipient or the person responsible for
delivering it to the recipient, you are hereby notified that you have
received this communication in error and that any review,
dissemination or copying of this communication is strictly prohibited.
If you have received this in error, please notify the sender
immediately by telephone at the number above and erase the message
You are requested to carry out your own virus check before
opening any attachment.



Why is so slow the download speed in OpenBSD?

2018-02-11 Thread Zsolt Kantor
Hello,
I'm using the latest release. Where the dl speed in other OS is approx. 1.4 
MB/s in BSD is only approx. 240 KB/s. Why is this? Is about a setting in some 
config file that limits download/traffic rate?

Thanks.



Re: How to send a bug report with sendbug? What to configure to actually send the message?

2018-02-08 Thread Zsolt Kantor
Thanks for the answer.


On Friday, February 9, 2018 1:29 AM, "ed...@pettijohn-web.com" 
<ed...@pettijohn-web.com> wrote:





On Feb 8, 2018 4:26 PM, Tom Smyth <tom.sm...@wirelessconnect.eu> wrote:

>

> Hi Zolt

>

> you can open the message on a command terminal ...  copy and paste

> the message manually into a working email client,

> make sure the subject and email addresses are consistent

>

> I hope this helps ...

> Tom Smyth

>

> On 8 February 2018 at 21:37, Zsolt Kantor <zsoltkan...@yahoo.co.uk> wrote:

> > Hello, I'm very new to the OpenBSD OS, I found a bug in the inteldrm driver 
> > and I want to send it with sendbug. Probably something needs to be 
> > configured to actually send out the message, because I sent the bug report, 
> > but it only landed in my local mailbox. The question is what should I 
> > configure to actually send the message to the mailing list.

> >

> > Thanks.

> >

>

>

>

> -- 

> Kindest regards,

> Tom Smyth

>

> Mobile: +353 87 6193172

> The information contained in this E-mail is intended only for the

> confidential use of the named recipient. If the reader of this message

> is not the intended recipient or the person responsible for

> delivering it to the recipient, you are hereby notified that you have

> received this communication in error and that any review,

> dissemination or copying of this communication is strictly prohibited.

> If you have received this in error, please notify the sender

> immediately by telephone at the number above and erase the message

> You are requested to carry out your own virus check before

> opening any attachment.

>

sendbug -p


Copy paste


Or set up smtpd to relay your email through Gmail, etc.



Re: How to send a bug report with sendbug? What to configure to actually send the message?

2018-02-08 Thread Zsolt Kantor
Yes, thanks for the hint. I thought about this. Actually in theory is more 
simple to use directly the sendbug command, but for that you need to configure 
a server (smtp I think). And I do not want to spend days now to learning how to 
do it. So I will do at the simple way, as you told me.
Thanks 

On Friday, February 9, 2018 12:33 AM, Tom Smyth 
<tom.sm...@wirelessconnect.eu> wrote:
 

 Hi Zolt

you can open the message on a command terminal ...  copy and paste
the message manually into a working email client,
make sure the subject and email addresses are consistent

I hope this helps ...
Tom Smyth

On 8 February 2018 at 21:37, Zsolt Kantor <zsoltkan...@yahoo.co.uk> wrote:
> Hello, I'm very new to the OpenBSD OS, I found a bug in the inteldrm driver 
> and I want to send it with sendbug. Probably something needs to be configured 
> to actually send out the message, because I sent the bug report, but it only 
> landed in my local mailbox. The question is what should I configure to 
> actually send the message to the mailing list.
>
> Thanks.
>



-- 
Kindest regards,
Tom Smyth

Mobile: +353 87 6193172
The information contained in this E-mail is intended only for the
confidential use of the named recipient. If the reader of this message
is not the intended recipient or the person responsible for
delivering it to the recipient, you are hereby notified that you have
received this communication in error and that any review,
dissemination or copying of this communication is strictly prohibited.
If you have received this in error, please notify the sender
immediately by telephone at the number above and erase the message
You are requested to carry out your own virus check before
opening any attachment.

   


How to send a bug report with sendbug? What to configure to actually send the message?

2018-02-08 Thread Zsolt Kantor
Hello, I'm very new to the OpenBSD OS, I found a bug in the inteldrm driver and 
I want to send it with sendbug. Probably something needs to be configured to 
actually send out the message, because I sent the bug report, but it only 
landed in my local mailbox. The question is what should I configure to actually 
send the message to the mailing list.

Thanks.



inteldrm issue in release 6.2

2018-02-05 Thread Zsolt Kantor
I don't know if this is a bug or it was intentionally changed in release 6.2, 
so I write the details here and please tell me if I should post to the bugs 
mailing list.The problem is the following: I have an integrated Mobile Intel 
965 video card. With the 6.1 release at the boot time the resolution is set to 
the highest value, but with the 6.2 release the resolution is set to a low 
value (840x480). I have tested this with both i386 and amd64 variants. Here are 
some technical details from dmesg:
OpenBSD 6.1:inteldrm0 at pci0 dev 2 function 0 "Intel GM965 Video" rev 0x03drm0 
at inteldrm0intagp0 at inteldrm0agp0 at intagp0: aperture at 0xd000, size 
0x1000inteldrm0: msiinteldrm0: 1280x800, 32bpp
OpenBSD 6.2:inteldrm0 at pci0 dev 2 function 0 "Intel GM965 Video" rev 0x03drm0 
at inteldrm0intagp0 at inteldrm0agp0 at intagp0: aperture at 0xd000, size 
0x1000inteldrm0: msiinteldrm0: 848x480, 32bpp
This is a laptop. FUJITSU SIEMENS AMILO Li 2735Should I report this as a bug?
Thanks