Den tors 22 apr. 2021 kl 23:13 skrev Scott Bennett :
> > Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
> > both amd64 and sparc64. That means the kernel lock will only be taken
> > for lower faults and some amap/anon code will now run without it.
> >
> > I'd be interested
Errata:
A few minutes later the problem occured on 6.8
It was looking stable but:
Apr 23 00:04:49 libre /bsd: ugen0 detached
Apr 23 00:04:56 libre /bsd: ugen0 at uhub0 port 2 "INNO TECH USB to
Serial" rev 1.10/0.02 addr 2
Apr 23 00:06:08 libre upsmon[1619]: UPS ups0@localhost on battery
Apr 23 00
Hello,
> > +
> Can you remove one of the double empty lines?
sure, updated diff is below.
> > +
> > + old_reverse = atomic_cas_ptr(&skrev->reverse, NULL, sk);
> > + if (old_reverse != NULL)
> > + KASSERT(old_reverse == sk);
> > + else
> > + pf_state_key_ref(sk);
>
My x230 laptop was setup to do the testing with 6.8.
First observations:
- There's no `ugen_clear_iface_eps: clear endpoints failed!` messages
- I haven't managed to trigger the bug on 6.8
- I'm still getting trouble to make upsd able to detect the ups at boot
I have to replug the USB then it wo
Found a small mistake in the 6.9 changelog.
Index: 69.html
===
RCS file: /cvs/www/69.html,v
retrieving revision 1.70
diff -u -p -r1.70 69.html
--- 69.html 22 Apr 2021 17:59:45 - 1.70
+++ 69.html 22 Apr 2021 20:34:16 -
On Thu, 22 Apr 2021 15:38:53 +0200, Martin Pieuchot wrote:
> Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
> both amd64 and sparc64. That means the kernel lock will only be taken
> for lower faults and some amap/anon code will now run without it.
>
> I'd be interested t
On 2021/04/22 22:52, xs wrote:
> - I've seen mentions of usb_quirks.c for usbhid driver in
> /usr/local/share/doc/pkg-readmes/nut
> ```
> The option with fewest side-effects is to add the following entries to
> the table in /sys/dev/usb/usb_quirks.c and build a new kernel:
>
> { USB_VENDOR_APC,
I'm having an USB communication issue with ugen and the blazer_usb NUT
driver on the last snapshot 6.9 GENERIC.MP#473 amd64. Notably the
'ugen_clear_iface_eps: clear endpoints failed!' message and
communication loss with the UPS.
Here is a link to my dmesg: https://clbin.com/pc1dk
- NUT configur
On Thu, Apr 22, 2021 at 03:38:53PM +0200, Martin Pieuchot wrote:
> Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
> both amd64 and sparc64. That means the kernel lock will only be taken
> for lower faults and some amap/anon code will now run without it.
>
> I'd be interes
If partition is smaller than 32MB, mount_msdos(8) will yield "not an MSDOS
filesystem".
pmp->pm_Sectors is set by newfs_msdos(8) when the number of sectors is less
than MAXU16 even if asked to format in FAT32.
I choosed to fix mounting instead of formatting (newfs_msdos.c frightens me...)
FreeBS
On Thu, Apr 22, 2021 at 07:47:29PM +0200, Matthias Schmidt wrote:
> I have a kernel with your patch running since several hours and
> noticed a regression. My usual "test case" is copying several large
> files from my file server via NFSv3 to my laptop. In the beginning the
> transfer rate was a
On 22/04/21(Thu) 20:19, Alexander Bluhm wrote:
> Hi,
>
> sysctl witnesswatch gives an error message if the feature is not
> compiled into the kernel. I think dt(4) allowdt should do the same.
>
> sysctl: kern.allowdt: value is not available
>
> This removes a bit of unused code from ramdisk ker
Hi,
sysctl witnesswatch gives an error message if the feature is not
compiled into the kernel. I think dt(4) allowdt should do the same.
sysctl: kern.allowdt: value is not available
This removes a bit of unused code from ramdisk kernel.
The variable allowdt should be in the device, not in sysct
Hi Stefan,
* Stefan Sperling wrote:
> This patch adds A-MSDU rx offloading support for both iwm(4) and iwx(4)
> and re-enables net80211's software A-MSDU Rx support for all 11n drivers.
>
> Meaning iwn(4) and athn(4) will also be receiving A-MSDUs again.
> This feature has been turned off since J
Hello tech@,
following patch enables urtwn driver to attach to USB wifi adapter
ASUS USB-N10 Nano (Wireless-N150)
Sticker on box says:
Model: USB-N10 NANO B1
H/W Ver.: B1
### N10 B1
usbdevs:
addr 02: 0b05:18f0 Realtek, 802.11n NIC
dmesg:
urtwn0 at uhub0 port 1 configuration 1 interface 0 "Realt
On Wed, Apr 21, 2021 at 10:19:10PM +0200, Alexandr Nedvedicky wrote:
> would it be OK to commit it once bluhm's diff [1] will be in?
Diff can be commited independently when we know that it is correct.
> 8<---8<---8<--8<
> diff --git a/sys/ne
Diff below remove the KERNEL_LOCK()/UNLOCK() dance from uvm_fault() for
both amd64 and sparc64. That means the kernel lock will only be taken
for lower faults and some amap/anon code will now run without it.
I'd be interested to have this tested and see how much does that impact
the build time of
Hello,
On Thu, Apr 22, 2021 at 03:08:21PM +0200, Mark Kettenis wrote:
> > Date: Thu, 22 Apr 2021 14:43:24 +0200
> > From: Alexandr Nedvedicky
> >
> > Hello,
> >
> > On Thu, Apr 22, 2021 at 01:09:34PM +0200, Alexander Bluhm wrote:
> > > On Thu, Apr 22, 2021 at 12:33:13PM +0200, Hrvoje Popovski w
On 22/04/21(Thu) 15:08, Mark Kettenis wrote:
> > Date: Thu, 22 Apr 2021 14:43:24 +0200
> > From: Alexandr Nedvedicky
> >
> > Hello,
> >
> > On Thu, Apr 22, 2021 at 01:09:34PM +0200, Alexander Bluhm wrote:
> > > On Thu, Apr 22, 2021 at 12:33:13PM +0200, Hrvoje Popovski wrote:
> > > > r620-1# papn
> Date: Thu, 22 Apr 2021 14:43:24 +0200
> From: Alexandr Nedvedicky
>
> Hello,
>
> On Thu, Apr 22, 2021 at 01:09:34PM +0200, Alexander Bluhm wrote:
> > On Thu, Apr 22, 2021 at 12:33:13PM +0200, Hrvoje Popovski wrote:
> > > r620-1# papnpaiancini:cc :p :op
> > > opooolo_llc_ac_caccahhceh_ei_eti_ti
On Thu, Apr 22, 2021 at 01:13:50PM +1000, David Gwynne wrote:
> On Wed, Apr 21, 2021 at 01:15:53PM +, Visa Hankala wrote:
> > On Wed, Apr 21, 2021 at 11:04:20AM +1000, David Gwynne wrote:
> > > On Wed, Apr 21, 2021 at 10:21:32AM +1000, David Gwynne wrote:
> > > > if you have a program that uses
Hello,
On Thu, Apr 22, 2021 at 01:09:34PM +0200, Alexander Bluhm wrote:
> On Thu, Apr 22, 2021 at 12:33:13PM +0200, Hrvoje Popovski wrote:
> > r620-1# papnpaiancini:cc :p :op
> > opooolo_llc_ac_caccahhceh_ei_eti_tieetmme_mm__amgamigacigci__cc_hccehhcekcekc::
> > k :m bmubmfubfuppflp llc pc pcuup
On Thu, Apr 22, 2021 at 12:26:50AM +0200, Alexander Bluhm wrote:
> As a wild guess, you could apply this diff on top. Something similar
> has fixed IPv6 NDP problem I have seen. Maybe it is in the routing
> table, that is used for ARP and NDP.
Here are the performance numbers for forwarding with
This patch adds A-MSDU rx offloading support for both iwm(4) and iwx(4)
and re-enables net80211's software A-MSDU Rx support for all 11n drivers.
Meaning iwn(4) and athn(4) will also be receiving A-MSDUs again.
This feature has been turned off since July 2019:
https://cvsweb.openbsd.org/cgi-bin/cv
On 21.4.2021. 22:19, Alexandr Nedvedicky wrote:
> Hello,
>
> people who will be running pf(4) with bluhm's diff [1], may trip
> one of the asserts triggered by pf_state_key_link_reverse() here:
>
> 7366 void
> 7367 pf_state_key_link_reverse(struct pf_state_key *sk, struct pf_state_key
> *skrev)
On 22.4.2021. 13:42, Mark Kettenis wrote:
>> Date: Thu, 22 Apr 2021 13:09:34 +0200
>> From: Alexander Bluhm
>>
>> On Thu, Apr 22, 2021 at 12:33:13PM +0200, Hrvoje Popovski wrote:
>>> r620-1# papnpaiancini:cc :p :op
>>> opooolo_llc_ac_caccahhceh_ei_eti_tieetmme_mm__amgamigacigci__cc_hccehhcekcekc::
> Date: Thu, 22 Apr 2021 13:09:34 +0200
> From: Alexander Bluhm
>
> On Thu, Apr 22, 2021 at 12:33:13PM +0200, Hrvoje Popovski wrote:
> > r620-1# papnpaiancini:cc :p :op
> > opooolo_llc_ac_caccahhceh_ei_eti_tieetmme_mm__amgamigacigci__cc_hccehhcekcekc::
> > k :m bmubmfubfuppflp llc pc pcuup uf r
On Thu, Apr 22, 2021 at 12:33:13PM +0200, Hrvoje Popovski wrote:
> r620-1# papnpaiancini:cc :p :op
> opooolo_llc_ac_caccahhceh_ei_eti_tieetmme_mm__amgamigacigci__cc_hccehhcekcekc::
> k :m bmubmfubfuppflp llc pc pcuup uf rfferree eel el iilsitss tm tom
> omddoidfiiifeifeidde:d ::i ti etietmme m
>
On 22.4.2021. 12:38, Alexander Bluhm wrote:
> It is not clear why the lock helps. Is it a bug in routing or ARP?
> Or is it just different timing introduced by the additional kernel
> lock? The parallel network task stress the subsystems of the kernel
> more than before with MP load. Having more
On Thu, Apr 22, 2021 at 11:36:07AM +0200, Hrvoje Popovski wrote:
> On 22.4.2021. 11:02, Alexander Bluhm wrote:
> > This was without my kernel lock around ARP bandage, right?
>
> yes, yes ...
Good. Just wanted to be sure.
> > Did you enter boot reboot before doing mach ddbcpu 0xa?
>
> nope... i
On 22.4.2021. 11:36, Hrvoje Popovski wrote:
> if you want i'll try to reproduce in on other boxes..
> maybe i can trigger it here easily because of 2 sockets ?
on second box with 6 x Intel(R) Xeon(R) CPU E5-2643 v2 @ 3.50GHz,
3600.02 MHz..
r620-1# papnpaiancini:cc :p :op
opooolo_llc_ac_caccahhce
Am Thu, Apr 22, 2021 at 11:19:22AM +0200 schrieb Martin Pieuchot:
> uao_shrink() and uao_grow() are only used by TMPFS, ok to place them
> under an #ifdef? This save some bytes on RAMDISKs.
sure, ok patrick@
> Index: uvm/uvm_aobj.c
> ==
On 22.4.2021. 11:02, Alexander Bluhm wrote:
> On Thu, Apr 22, 2021 at 09:03:22AM +0200, Hrvoje Popovski wrote:
>> something like this:
>>
>> x3550m4# pappnaiannc:iicc :p:o ppoolo_oolcla__ddcohoe__gg_eiettt::e m
>> _mmcbmualg2fkpilc2_:: chppeaag
>> gceke: ee mmmbppttuyfyp
>
> This was without my
uao_shrink() and uao_grow() are only used by TMPFS, ok to place them
under an #ifdef? This save some bytes on RAMDISKs.
Index: uvm/uvm_aobj.c
===
RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v
retrieving revision 1.94
diff -u -p -r1.94 uvm_
On Thu, Apr 22, 2021 at 09:03:22AM +0200, Hrvoje Popovski wrote:
> something like this:
>
> x3550m4# pappnaiannc:iicc :p:o ppoolo_oolcla__ddcohoe__gg_eiettt::e m
> _mmcbmualg2fkpilc2_:: chppeaag
> gceke: ee mmmbppttuyfyp
This was without my kernel lock around ARP bandage, right?
> ddb{9}> mac
On 22.4.2021. 1:10, Hrvoje Popovski wrote:
> On 22.4.2021. 0:31, Alexandr Nedvedicky wrote:
>> Hello,
>>
>>
Hi,
with this diff i'm getting panic when i'm pushing traffic over that box.
This is plain forwarding. To compile with witness ?
>>>
>>>
>>> with witness
>>>
>>
>> an
36 matches
Mail list logo