[wireless] iwx: small code nitpicking and removal of iwx_wait_tx_queues_empty

Inlined patch does the following: - removes functions in initialization per style(9) (splnet) - removes double definition of IWX_NVM_GET_INFO - removes unused 'ring' variable from iwx_sta_tx_agg_start - removes unused 'iwx_tid_to_ac' array - removes iwx_wait_tx_queues_empty function Regarding

Re: any work on port of rtw89? (realtek 8852 AE/BE/CE)

On Sun, Oct 01, 2023 at 11:17:32AM -0600, Theo de Raadt wrote: > >I'm interested if anyone has already done any research or code regarding > >these drivers to save double effort. > > Over in freebsd land won't you just use the linux drivers, to "save double > effort"? And how's that going.

any work on port of rtw89? (realtek 8852 AE/BE/CE)

I'm interested if anyone has already done any research or code regarding these drivers to save double effort.

Re: Have sysupgrade run fw_update -vv

On Sun, Aug 13, 2023 at 10:02:26PM -0700, Kevin Williams wrote: > What about giving sysupgrade the same verbosity options as fw_update? > This would mean -v and -vv I sysupgrade would pass through the same > options to fw_update. > > And for the installer, maybe another question: “Verbose download

Re: Have sysupgrade run fw_update -vv

On Sun, Aug 13, 2023 at 11:44:33AM -0700, Andrew Hewus Fresh wrote: > My laptop doesn't have the fastest wifi and sysupgrade already uses a > progress bar to show what it's doing, so I'd really like to provide more > feedback on what it is doing: > > $ doas fw_update -d intel > fw_update: deleted

Re: uvm_meter: remove wakeup of proc0

On Mon, Jul 31, 2023 at 10:04:44PM +0200, Claudio Jeker wrote: > On Mon, Jul 31, 2023 at 09:49:30PM +0200, Claudio Jeker wrote: > > On Mon, Jul 31, 2023 at 08:03:41PM +0300, Vitaliy Makkoveev wrote: > > > This is the culprit: > > > > > > schedule_timeout_uninterruptible(long timeout) > > > { > >

Re: uvm_meter: remove wakeup of proc0

On Sat, Jul 29, 2023 at 11:16:14AM +0200, Claudio Jeker wrote: > proc0 aka the swapper does not do anything. So there is no need to wake it > up. Now the problem is that last time this was tried some inteldrm systems > did hang during bootup because the drm code unexpectedly depended on this >

Re: [installer] default answer to "Is the disk partition already mounted?"

On Sat, Apr 01, 2023 at 04:33:39PM +0300, Mikhail wrote: > Currently default answer for the question is 'yes', which is not true > for install case, but correct for upgrade one. > > Changing default answer depending on the mode of the installer looks > like a good approach. Id

Re: [installer] default answer to "Is the disk partition already mounted?"

On Sat, Apr 01, 2023 at 04:31:59PM +, Klemens Nanni wrote: > 01.04.2023 13:33, Mikhail пишет: > $_answer may be unset, but you still pass it and thus rely on ask_yn()'s > default 'no' answer. > > I'd just default-initialise up front and flip if conditions are met. >

[installer] default answer to "Is the disk partition already mounted?"

Currently default answer for the question is 'yes', which is not true for install case, but correct for upgrade one. Changing default answer depending on the mode of the installer looks like a good approach. Idea by Christian (naddy@), implementation and testing are mine. diff /usr/src commit -

pledge utility

While reviewing Bob's presentation[1] on pledge and unveil I came across his idea about pledge utility which will take unveil paths, pledge promises and execute a program with the restrictions (slide 12). What do you think about the idea and implementation? [1] -

Re: iwx(4) -77 firmware diff for testing

On Wed, Feb 22, 2023 at 03:31:28PM +0100, Stefan Sperling wrote: > Below is my work-in-progress diff to update iwx(4) to latest firmware. > Every system tracking -current should already have the new -77 firmware > images. > > The new images contain security fixes of (to me) unknown severity. >

Re: [xenocara] xenodm.man fix

On Sat, Feb 18, 2023 at 08:00:26AM +0100, Matthieu Herrb wrote: > On Fri, Feb 17, 2023 at 11:52:44AM +, Laurence Tratt wrote: > > On Thu, Feb 16, 2023 at 09:29:53PM +0300, Mikhail wrote: > > > > Hello Mikhail, > > > > > /etc/X11/xenodm/Xsession fil

[xenocara] xenodm.man fix

/etc/X11/xenodm/Xsession file has a check for x bit startup=$HOME/.xsession [...] if [ -s "$startup" ]; then if [ -x "$startup" ]; then "$startup" else /bin/sh "$startup" fi [...] diff /var/git/xenocara commit -

typo in if_urtwn.c

diff /usr/src commit - 810555b25bf5444b727efabdb7f5ed0506159a65 path + /usr/src blob - a615fdea5fca69bcd980bdc027050f59be89d0ed file + sys/dev/usb/if_urtwn.c --- sys/dev/usb/if_urtwn.c +++ sys/dev/usb/if_urtwn.c @@ -1659,7 +1659,7 @@ urtwn_tx(void *cookie, struct mbuf *m, struct ieee8021

Re: [acpi] patch to run _INI methods before table devices attach

On Sat, Oct 22, 2022 at 01:41:23PM +0200, Mark Kettenis wrote: > Identifying which of the "table-driven" device attachments is the > culprit here might help. I have following tables: acpi0: tables DSDT FACP UEFI SSDT SSDT SSDT SSDT SSDT SSDT TPM2 MSDM NHLT SSDT LPIT WSMT SSDT SSDT DBGP DBG2

Re: [acpi] patch for embedded controller detection

On Sat, Oct 08, 2022 at 03:10:18PM +0300, Mikhail wrote: > I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on > latest -current it shows that battery is absent and AC not connected: > > Battery state: absent, 0% remaining, unknown life estimate > A

Re: [acpi] patch to run _INI methods before table devices attach

On Sat, Oct 22, 2022 at 01:41:23PM +0200, Mark Kettenis wrote: > > I continue my fight with ACPI on Lenovo IdeaPad 3 14ITL05, now, when > > battery status problem has been resolved[1] next target is backlight > > brightness keys. > > Well it hasn't been resolved yet. The firmware is clearly

[acpi] patch to run _INI methods before table devices attach

I continue my fight with ACPI on Lenovo IdeaPad 3 14ITL05, now, when battery status problem has been resolved[1] next target is backlight brightness keys. With the inlined patch and explicitly specified correct EC_ID in the code I'm able to control brightness with functional keys. The patch moves

Re: [acpi] patch for embedded controller detection

On Sat, Oct 08, 2022 at 03:10:18PM +0300, Mikhail wrote: > I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on > latest -current it shows that battery is absent and AC not connected: > > Battery state: absent, 0% remaining, unknown life estimate > A

Re: [acpi] patch for embedded controller detection

On Sat, Oct 08, 2022 at 03:10:18PM +0300, Mikhail wrote: > I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on > latest -current it shows that battery is absent and AC not connected: > > Battery state: absent, 0% remaining, unknown life estimate > A

Re: [acpi] patch for embedded controller detection

On Sat, Oct 08, 2022 at 05:10:31PM +0200, Mark Kettenis wrote: > > Date: Sat, 8 Oct 2022 16:36:09 +0300 > > From: Mikhail > > > > On Sat, Oct 08, 2022 at 02:56:18PM +0200, Mark Kettenis wrote: > > > The patch isn't quite right, but you're on the right t

Re: [acpi] patch for embedded controller detection

On Sat, Oct 08, 2022 at 02:56:18PM +0200, Mark Kettenis wrote: > The patch isn't quite right, but you're on the right track here. Can > you send me the contents of /var/db/acpi for this machine? > Alternatively you can use sendbug(1), which will create a report with > all the necessary

[acpi] patch for embedded controller detection

I'm troubleshooting battery status for my Lenovo IdeaPad 3 14ITL05, on latest -current it shows that battery is absent and AC not connected: Battery state: absent, 0% remaining, unknown life estimate AC adapter state: not connected Performance adjustment mode: manual (2900 MHz) while reviewing

Re: [patch] 802.11 printing akm and cipher suite lists in tcpdump

Friendly weekly ping On Thu, Jun 02, 2022 at 11:43:30PM +0300, Mikhail wrote: > Recently I bought a router with WPA3 support and decided to investigate > wireless dump with WPA3 config, during the process I've found a small > bug in tcpdump - it doesn't print all akms, also the print

[patch] 802.11 printing akm and cipher suite lists in tcpdump

Recently I bought a router with WPA3 support and decided to investigate wireless dump with WPA3 config, during the process I've found a small bug in tcpdump - it doesn't print all akms, also the printing logic is flawed if more than one akm or pairwise cipher is presented - there is extra addition

openrsync man page fix

Replace rsync command with openrsync in EXAMPLES. diff --git usr.bin/rsync/rsync.1 usr.bin/rsync/rsync.1 index 8144754695a..9bcf3566bb9 100644 --- usr.bin/rsync/rsync.1 +++ usr.bin/rsync/rsync.1 @@ -290,7 +290,7 @@ with the local and .Pa ../src/baz : .Pp -.Dl % rsync -t ../src/bar ../src/baz

Re: initial iwx(4) 11ac patch for testing

On Wed, Mar 09, 2022 at 01:07:47PM +0100, Stefan Sperling wrote: > This patch adds initial 11ac support to the iwx(4) driver. > This means that 80MHz channels can be used. No other 11ac features > are enabled yet. > > This is not yet a patch which could be committed. Apart from debug > prints

Re: mg and trailing whitespaces

On Wed, Mar 02, 2022 at 09:47:31AM +0100, Omar Polo wrote: > Hello tech, > > mg(1) has this tendency to leave a lot of trailing whitespaces around in > auto-indent-mode and c-mode which I find annoying. Yes, there's > delete-trailing-space but it works only on the current line (and not the >

Re: [patch] ksh: backspace in search-history buffer with UTF8 chars

On Tue, Mar 08, 2022 at 03:15:55PM +0300, Mikhail wrote: > Inlined diff helps ksh search-history function (ctrl-r) to handle > backspace for UTF8 characters properly, without the patch, if I have > UTF8 characters in my search buffer, I need to press backspace twice to > push cursor

[patch] ksh: backspace in search-history buffer with UTF8 chars

Inlined diff helps ksh search-history function (ctrl-r) to handle backspace for UTF8 characters properly, without the patch, if I have UTF8 characters in my search buffer, I need to press backspace twice to push cursor to the left. The search itself is not perfect for UTF8 either, sometimes I get

Re: fix net80211 ioctl name collision

On Fri, Mar 04, 2022 at 10:46:29PM +0100, Stefan Sperling wrote: > The net80211 ioctl which ifconfig is using to obtain a list of all > supported channels is using a struct name that belongs to the kernel. > > Fix this by renaming struct ieee80211_channel to struct ieee80211_chaninfo > in

chrome crash on latest snapshot with intel driver

On latest snapshot I see Xorg crash when trying to launch chrome browser (firefox works fine), I can reproduce it with 'intel' driver, 'modesetting' crashed for me too, but it took about two weeks of uptime and wasn't related to chrome launch (no logs for 'modesetting' crash unfortunately, but it

Re: tcpdump core's on the latest snapshot

On Sun, Feb 13, 2022 at 12:54:19PM +0100, Otto Moerbeek wrote: > I can see two problems: > > 1. setjump returning 1 > 2. freechunks() segfaulting. > > Here I'll concentrate on 2), as I suspect 1) has a cause that is already in > the process of being diagnosed/fixed elsewhere. The patch works -

tcpdump core's on the latest snapshot

Running this command on the latest snapshot produces core file for me: doas tcpdump -i urtwn0 proto ip6 Core details: misha:/home/misha:3959$ doas lldb --core tcpdump.core tcpdump (lldb) target create "tcpdump" --core "tcpdump.core" Core file '/home/misha/tcpdump.core' (x86_64) was loaded.

Re: [patch] urndis: uncomment watchdog

On Wed, Dec 08, 2021 at 03:26:25PM +0100, Gerhard Roth wrote: > > I don't want to fight for this diff, if you think that it's too naive to > > expect proper reset from unresponsive device - that's fine, I'm ready to > > drop the diff, but who knows how those devices are engineered and trade > > of

Re: [patch] urndis: uncomment watchdog

On Wed, Dec 08, 2021 at 02:43:04PM +0100, Gerhard Roth wrote: > Well, the RNDIS device doesn't respond to REMOTE_NDIS_KEEPALIVE_MSG > messages anymore, but now you hope that it'll still process the > REMOTE_NDIS_RESET_MSG we are sending? Sounds like wishful thinking. > I'd say a usbd_reset_port()

Re: [patch] urndis: uncomment watchdog

On Wed, Dec 08, 2021 at 02:10:49PM +0100, Gerhard Roth wrote: > Well, there's only one watchdog thread for all of the > network interfaces. If it is blocked, not other watchdogs > can run. I don't think this is a big loss. On one side - no other watchdogs can run for 5 secs, but on other side -

Re: [patch] urndis: uncomment watchdog

On Wed, Dec 08, 2021 at 10:39:15AM +0100, Gerhard Roth wrote: > urndis_watchdog() calls urndis_ctrl_keepalive() which sends an RNDIS > keepalive msg and then waits for the reply with USBD_DEFAULT_TIMEOUT. > That means if the device stopped responding, the if_watchdog_thread > will be blocked for 5

Re: [patch] urndis: uncomment watchdog

On Tue, Nov 30, 2021 at 09:40:35PM +0300, Mikhail wrote: > Currently watchdog functionality for urndis driver is disabled > (commented), I've tested it and it works properly - reset messages are > correctly sent and cmplt packets are received according to RNDIS spec (I > patche

Re: [patch] ehci: change explicit function names to __func__ in debugging printfs

Ping On Sat, Nov 27, 2021 at 09:36:32PM +0300, Mikhail wrote: > While fiddling with ehci.c and fighting with urndis I noticed that most > of the debugging printf's use explicit names, which is inconvenient for > grep'ing. Also, couple of items used wrong function names > (ehci_check_

[patch] urndis: uncomment watchdog

Currently watchdog functionality for urndis driver is disabled (commented), I've tested it and it works properly - reset messages are correctly sent and cmplt packets are received according to RNDIS spec (I patched the driver to forcedly send reset message and act on it with device reset every 5

[patch] ehci: change explicit function names to __func__ in debugging printfs

While fiddling with ehci.c and fighting with urndis I noticed that most of the debugging printf's use explicit names, which is inconvenient for grep'ing. Also, couple of items used wrong function names (ehci_check_intr instead of ehci_check_qh_intr). Compilation tested with DIAGNOSTIC and

Re: urndis0: IOERROR

On Mon, Nov 22, 2021 at 04:28:54PM +0100, Gerhard Roth wrote: > > Your OpenBSD pcap contains not "URB_CONTROL in" packets. Don't know where > they got lost but since you cannot see any data sent by the function on the > control pipe, it is almost impossible to do any debugging here. You only see

Re: urndis0: IOERROR

On Mon, Nov 22, 2021 at 12:32:30PM +0300, Mikhail wrote: > On Mon, Nov 22, 2021 at 09:31:59AM +0100, Gerhard Roth wrote: > > On 11/20/21 17:12, Mikhail wrote: > > > Comparing Windows and OpenBSD tcpdumps I noticed some differences: > > > > > > 1) In R

Re: urndis0: IOERROR

d anywhere down to USB stack. On Sun, Nov 14, 2021 at 02:39:33PM +0300, Mikhail wrote: > On Sat, Nov 13, 2021 at 08:27:21PM +0300, Mikhail wrote: > > Hello, I get aforesaid error when trying to plug in my 4G usb modem, it > > works well on another laptop with windows 10. >

Re: urndis0: IOERROR

On Sat, Nov 13, 2021 at 08:27:21PM +0300, Mikhail wrote: > Hello, I get aforesaid error when trying to plug in my 4G usb modem, it > works well on another laptop with windows 10. > > I enabled debug info, but seem the failure somewhere deeper in usb stack > and I wasn't able t

urndis0: IOERROR

Hello, I get aforesaid error when trying to plug in my 4G usb modem, it works well on another laptop with windows 10. I enabled debug info, but seem the failure somewhere deeper in usb stack and I wasn't able to catch it, can someone advice me on further debugging efforts? urndis0 at uhub3 port

Re: [PATCH] Change maximum size of /usr/src to 3G for autoinstall

On Sat, Oct 30, 2021 at 11:39:54AM +0300, Mikhail wrote: > On Sun, Oct 24, 2021 at 02:17:25PM +0300, Mikhail wrote: > > On Sun, Oct 24, 2021 at 11:32:26AM +0100, Stuart Henderson wrote: > > > The minimum needs to go up too, a cvs checkout is 1.3G already. > > > > >

Re: [PATCH] Change maximum size of /usr/src to 3G for autoinstall

On Sun, Oct 24, 2021 at 02:17:25PM +0300, Mikhail wrote: > On Sun, Oct 24, 2021 at 11:32:26AM +0100, Stuart Henderson wrote: > > The minimum needs to go up too, a cvs checkout is 1.3G already. > > > > (Not that I use auto defaults without changes anyway, they don't > >

Re: [PATCH] Change maximum size of /usr/src to 3G for autoinstall

On Sun, Oct 24, 2021 at 11:32:26AM +0100, Stuart Henderson wrote: > The minimum needs to go up too, a cvs checkout is 1.3G already. > > (Not that I use auto defaults without changes anyway, they don't > work too well for ports dev..) Changed minimum to 1.5G. diff --git

[PATCH] Change maximum size of /usr/src to 3G for autoinstall

Hello, current maximum size of /usr/src in large disk autoinstall configuration is set to 2G, which in insufficient for 'git clone', where the repo already exceeded this size, I suggest to change it to 3G, since most users have disks large enough to handle it. diff --git

Re: [patch] man page improvement for sem* family of functions

On Sat, Oct 23, 2021 at 11:45:03AM +0100, Jason McIntyre wrote: > i think this is fine. are you asking for an ok because you are a > developer? if not i'll commit it unless i hear anyone object. I'm not a developer, so please commit on your behalf.

Re: [patch] man page improvement for sem* family of functions

On Sat, Oct 16, 2021 at 03:13:39PM +0300, Mikhail wrote: > Hello, I was troubleshooting postgresql not being able to start after > 'pkill -6 postgres'. The error was: > > FATAL: could not create semaphores: No space left on device > DETAIL: Failed system call was semget(78927, 17,

Re: Increase of kern.seminfo.semmns sysctl

On Sun, Oct 17, 2021 at 01:36:02PM +0100, Stuart Henderson wrote: > On 2021/10/17 15:31, Mikhail wrote: > > Hello, current git of postgresql requires more semaphores than OpenBSD > > currently suggests as a default, I propose to rise the limit to 100. > > FreeBSD has

Increase of kern.seminfo.semmns sysctl

Hello, current git of postgresql requires more semaphores than OpenBSD currently suggests as a default, I propose to rise the limit to 100. FreeBSD has 340, as a comparison. Another solution may be to add the note to README of postgresql's port to rise the limit for the future version, but it

[patch] man page improvement for sem* family of functions

Hello, I was troubleshooting postgresql not being able to start after 'pkill -6 postgres'. The error was: FATAL: could not create semaphores: No space left on device DETAIL: Failed system call was semget(78927, 17, 03600). HINT: This error does *not* mean that you have run out of disk space. It

Re: ieee80211_node diff

OK? Anyone? On Thu, Jan 23, 2020 at 6:08 PM Mikhail wrote: > > There is no way ic_bgscan_fail can be less then zero, since it's unsigned[1]. > > Sorry for the attachment - web browser mail in act. > > [1] - http://bxr.su/OpenBSD/sys/net80211/ieee80211_var.h#251

ieee80211_node diff

There is no way ic_bgscan_fail can be less then zero, since it's unsigned[1]. Sorry for the attachment - web browser mail in act. [1] - http://bxr.su/OpenBSD/sys/net80211/ieee80211_var.h#251 ieee80211_node.patch Description: Binary data

Re: cwm: remove menu-ssh

Can you elaborate on tools for menu-ssh replacement? On Wed, Jan 22, 2020 at 11:16 PM Okan Demirmen wrote: > > Hi, > > I think we've (or at least I have) mused about this for a while; a > recent mail reminded me that this feature should go - a window manager > doesn't need to parse the ssh

libressl: Allow custom config location

1) +#endif     return NULL; return p;  } >From 4074611c49806fa5e8937a5aa24d9084235a89a5 Mon Sep 17 00:00:00 2001 From: Mikhail Novosyolov Date: Fri, 29 Nov 2019 21:24:49 +0300 Subject: [PATCH] Allow custom config location I want LibreSSL to: - coexist with OpenSSL - be installed into /

Fwd: new usb id for urtwn

Anyone? -- Forwarded message -- From: Mikhail Date: Wed, Jul 11, 2018 at 6:12 PM Subject: Re: new usb id for urtwn To: Stuart Henderson Cc: tech@openbsd.org Sorry, new patch attached. On Wed, Jul 11, 2018 at 4:45 PM, Stuart Henderson wrote: > On 2018/07/11 16:27, Mikh

Re: new usb id for urtwn

Sorry, new patch attached. On Wed, Jul 11, 2018 at 4:45 PM, Stuart Henderson wrote: > On 2018/07/11 16:27, Mikhail wrote: >> Ping? Ok? >> >> On Thu, 21 Jun 2018 at 18:28, Mikhail wrote: >> >> > Taken from FreeBSD: >> > >> > diff --git a/sys/

Re: new usb id for urtwn

Ping? Ok? On Thu, 21 Jun 2018 at 18:28, Mikhail wrote: > Taken from FreeBSD: > > diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c > index 0e204a196b1..d9aee16b05f 100644 > --- a/sys/dev/usb/if_urtwn.c > +++ b/sys/dev/usb/if_urtwn.c > @@ -306,6 +306,7 @

Re: integer divide fault trap: ilk_compute_vm_level panic

ping? On Fri, Jun 15, 2018 at 8:47 PM, Mikhail wrote: > Hello, tech@, I'm running freshly upgraded -current (upgraded via > today snapshot from -stable 6.3 where I had similar issue) on my > ThinkPad Edge 530. > > I get attached panic when my monitor is connected through HDMI po

new usb id for urtwn

Taken from FreeBSD: diff --git a/sys/dev/usb/if_urtwn.c b/sys/dev/usb/if_urtwn.c index 0e204a196b1..d9aee16b05f 100644 --- a/sys/dev/usb/if_urtwn.c +++ b/sys/dev/usb/if_urtwn.c @@ -306,6 +306,7 @@ static const struct urtwn_type { URTWN_DEV_8192CU(TRENDNET, RTL8192CU),

integer divide fault trap: ilk_compute_vm_level panic

Hello, tech@, I'm running freshly upgraded -current (upgraded via today snapshot from -stable 6.3 where I had similar issue) on my ThinkPad Edge 530. I get attached panic when my monitor is connected through HDMI port, the panic happens just after the boot, on the moment when xenodm is starting.

missed keybinding in cwm.1

Missed keybinding in the man page: diff --git a/app/cwm/cwm.1 b/app/cwm/cwm.1 index 3b4e76e83..3f8f5d241 100644 --- a/app/cwm/cwm.1 +++ b/app/cwm/cwm.1 @@ -103,6 +103,8 @@ Reverse cycle through currently visible windows. Delete current window. .It Ic CM-[n] Toggle visibility of group n, where

netintro.4 fix

Nuke non-existing chapter link in netintro.4. Index: netintro.4 === RCS file: /home/misha/work/cvs/src/share/man/man4/netintro.4,v retrieving revision 1.52 diff -u -p -r1.52 netintro.4 --- netintro.4 28 Apr 2018 16:16:43 -

Re: urndis printf cleanup

On Fri, Oct 27, 2017 at 1:19 PM, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: > On Fri, Oct 27 2017, Mikhail <mp39...@gmail.com> wrote: >> add missed DEVNAME's and \n's > > They are not missing. The point is to have _attach() print a single > line in dmesg. >

urndis printf cleanup

add missed DEVNAME's and \n's Index: dev/usb/if_urndis.c === RCS file: /home/misha/work/cvs/src/sys/dev/usb/if_urndis.c,v retrieving revision 1.67 diff -u -p -r1.67 if_urndis.c --- dev/usb/if_urndis.c 19 Jul 2017 16:31:56 - 1.67

[patch] acpithinkpad(4) unknown event 0x6005

Hello, when I press 'Fn' key on on thinkpad e530 I see aforesaid message on console log. Can someone review inlined patch? Index: dev/acpi/acpithinkpad.c === RCS file: /home/misha/work/cvs/src/sys/dev/acpi/acpithinkpad.c,v

Re: merge ping6(8) into ping(8)

binaries I have more trust when one of them is working >> *only* with IPv4 and another one *only* with IPv6. >> >> So, what user problems are you trying to solve with this merge? >> > > Mikhail, with great regret I am informing you that the opinion of some > random

Re: merge ping6(8) into ping(8)

> this does 2 things: > [...] I may recall what I have sent to you in private email, excerpt from FreeBSD ping6 manpage: 8<8<8<8<8<8< There have been many discussions on why we separate ping6 and ping(8). Some people argued that it would

Re: Further cleanup of Russian calendars

2015-10-23 14:15 GMT+03:00 Vadim Zhukov : > Further cleanup in Russian calendars: > > * Fix #ifndef safeguards (rename/add where missing); > * Use consistent spelling for year when it's mentioned in day desc; > * Tweak some wrong casing cases; > * Remove calendar.msk

[patch] urtwn(4) hostap mode support for 8188eu

Hello, inlined patch adds support for hostap mode for 8188eu chip. One known issue is documented in urtwn(4), I would like to know if people with other hw will see it too, or if it's my local issue. If you want to help, please test the patch and in case of problems provide as much as you can

[patch] urtwn(4) 8188eu additions

Hello, inlined patch is a compilation of fixes which were pushed into FreeBSD tree after 8188eu driver came in. It adds four new usbdevs (r270191, r273589, r282120), fixes efuse length and replaces magic numbers with proper defines (r281918), fixes efuse access (r281592, r282623), and fixes man

Re: [patch] rtl8188eu support for urtwn(4)

On 20:20 26-Apr 2015 Stefan Sperling wrote: The chunk below is wrong for OpenBSD since it sets the intitial transmit rate to an 11n rate. 0x13 corresponds to the MCS7 11n rate, see linux/drivers/net/wireless/rtlwifi/rtl8188ee/def.h enum rtl_desc92c_rate. The value 11 corresponds to OFDM 54Mbit

Re: [patch] rtl8188eu support for urtwn(4)

On 23:25 26-Apr 2015 patrick keshishian wrote: On 4/26/15, Mikhail mp39...@gmail.com wrote: urtwn_write_1(sc, R92C_USB_SPECIAL_OPTION, urtwn_read_1(sc, R92C_USB_SPECIAL_OPTION) | - R92C_USB_SPECIAL_OPTION_AGG_EN); + (sc-chip URTWN_CHIP_88E

Re: [patch] rtl8188eu support for urtwn(4)

On 20:20 26-Apr 2015 Stefan Sperling wrote: On Sun, Apr 26, 2015 at 01:31:17PM +0200, Stefan Sperling wrote: On Sun, Apr 19, 2015 at 11:48:32PM +0300, Mikhail wrote: Bellow new version of the patch with above things fixed, also I've fixed detection of ETV chip in urtwn_attach(), nothing

Re: [patch] rtl8188eu support for urtwn(4)

On 21:22 26-Apr 2015 Mikhail wrote: On 20:20 26-Apr 2015 Stefan Sperling wrote: On Sun, Apr 26, 2015 at 01:31:17PM +0200, Stefan Sperling wrote: On Sun, Apr 19, 2015 at 11:48:32PM +0300, Mikhail wrote: Bellow new version of the patch with above things fixed, also I've fixed detection

[patch] acpithinkpad(4) unknown event 0x6000

Hello, when I switch numlock on thinkpad e530 I see aforesaid message on console log. Can someone review inlined patch? Index: sys/dev/acpi/acpithinkpad.c === RCS file: /cvs/src/sys/dev/acpi/acpithinkpad.c,v retrieving revision 1.43

[patch] rtl8188eu support for urtwn(4)

Hello, I inline the patch for rtl8188eu chip support in urtwn driver, origins for this patch are in r264912[1] from FreeBSD. In order to work, correct firmware must be presented in /etc/firmware - one can be found in FreeBSD commit itself[2] - I'm not sure what is the correct procedure of