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
Hello,
> > +
> Can you remove one of the double empty lines?
sure, updated diff is below.
> > +
> > + old_reverse = atomic_cas_ptr(>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
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
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
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
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...)
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
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
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
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
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
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
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
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
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#
> 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
> > >
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
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
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:
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)
> 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
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
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...
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
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
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
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}>
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
>>>
>>
>>
34 matches
Mail list logo
