On 12/09/2020 03:09, Graham Perrin wrote:
… If the pool is ONLINE and imported at suspend time – and if not
actively writing to the device at suspend time …
Testing more aggressively (still with a low spec USB flash drive),
attempting to suspend _immediately after_ writes to the file system.
On Fri, 11 Sep 2020 14:20:22 +
"Bjoern A. Zeeb" wrote:
> On 11 Sep 2020, at 14:02, Tomoaki AOKI wrote:
>
> > On Thu, 10 Sep 2020 10:22:05 +
> > "Bjoern A. Zeeb" wrote:
> >
> >> On 9 Sep 2020, at 22:41, Tomoaki AOKI wrote:
> >>
> >>> This breaks at least iwm. (Other drivers not tested.)
On Sat, 12 Sep 2020 11:34:18 +0900 (JST)
Yasuhiro KIMURA wrote:
> From: Alan Somers
> Subject: Re: Build of poudriere 13-CURRENT jail is failed
> Date: Fri, 11 Sep 2020 14:50:39 -0600
>
> > Done.
>
> Thank you. I updated host OS to r365643 and now update of poudriere
> jail finished successful
From: Alan Somers
Subject: Re: Build of poudriere 13-CURRENT jail is failed
Date: Fri, 11 Sep 2020 14:50:39 -0600
> Done.
Thank you. I updated host OS to r365643 and now update of poudriere
jail finished successfully.
BTW there is an advice for those who faced same problem as me.
After source
I'm not sure what was going on with device numbers in my previous
report, but this much seems to be easily and consistently reproducible.
If the pool is ONLINE and imported at suspend time – and if not actively
writing to the device at suspend time – then at resume time:
* the pool is SUSPEND
John-Mark Gurney wrote this message on Sat, Jul 25, 2020 at 16:13 -0700:
> Hello,
>
> I'd like people who have ure (RealTek) based USB devices to test
> review D25809[0].
>
> This update adds support for:
> - HW VLAN tagging
> - HW checksum offload for IPv4 and IPv6
> - tx and rx aggreegation (fo
On Fri, Sep 11, 2020 at 1:01 AM wrote:
> > > On 09.09.20 06:18, Kevin Oberman wrote:
> > > > I am seeing a problem since I moved to current on my laptop this
> week.
> > > > It's odd as it is linked to the keyboard. As long as the keyboard is
> > > > active, everything is fine, but if the keyboar
Done.
On Fri, Sep 11, 2020 at 2:27 PM Yasuhiro KIMURA wrote:
> From: Michael Gmelin
> Subject: Re: Build of poudriere 13-CURRENT jail is failed
> Date: Fri, 11 Sep 2020 22:16:56 +0200
>
> >> I made regular update of my 13-CUREENT amd64 environment from r365330
> >> to r365634. Host OS is succes
From: Michael Gmelin
Subject: Re: Build of poudriere 13-CURRENT jail is failed
Date: Fri, 11 Sep 2020 22:16:56 +0200
>> I made regular update of my 13-CUREENT amd64 environment from r365330
>> to r365634. Host OS is successfully updated with regular steps written
>> in /usr/src/Makefile. But upda
> On 11. Sep 2020, at 22:12, Yasuhiro KIMURA wrote:
>
> Hello,
>
> I made regular update of my 13-CUREENT amd64 environment from r365330
> to r365634. Host OS is successfully updated with regular steps written
> in /usr/src/Makefile. But update of poudriere jail is failed with
> error.
Pleas
Hello,
I made regular update of my 13-CUREENT amd64 environment from r365330
to r365634. Host OS is successfully updated with regular steps written
in /usr/src/Makefile. But update of poudriere jail is failed with
error.
The jail was created with following command.
% sudo -i poudriere jail -c -j
Hi,
can you please try out this patch? This is configuration event
and we should use sleepable lock to synchronize, not epoch.
On Fri, Sep 11, 2020 at 10:47:41AM +0300, xto...@mm.st wrote:
x> Updating from latest CURRENT snapshot
x> (FreeBSD-13.0-CURRENT-amd64-20200910-1544934ffb2) to r365620
Kristof,
can you please take a look? IMHO, the problem is that with r360345
the bridge_ioctl() is fully covered by epoch. IMHO, should be either
more fine grained covered, or use internal locking, because some of
the code downstream (driver ioctls) may sleep.
On Fri, Sep 11, 2020 at 10:47:41AM
On Fri, Sep 11, 2020 at 07:45:09PM +0300, xto...@mm.st wrote:
x> Gleb Smirnoff wrote:
x> >Hi,
x> >
x> > can you please try out this patch? This is configuration event
x> > and we should use sleepable lock to synchronize, not epoch.
x>
x> It didn't help, though I guess my problem is in if_brid
Gleb Smirnoff wrote:
Hi,
can you please try out this patch? This is configuration event
and we should use sleepable lock to synchronize, not epoch.
It didn't help, though I guess my problem is in if_bridge, not if_lagg
which the patch modifies?
On Fri, Sep 11, 2020 at 10:47:41AM +0300,
On 11 Sep 2020, at 14:02, Tomoaki AOKI wrote:
On Thu, 10 Sep 2020 10:22:05 +
"Bjoern A. Zeeb" wrote:
On 9 Sep 2020, at 22:41, Tomoaki AOKI wrote:
This breaks at least iwm. (Other drivers not tested.)
Messages below are repeatedly shown and no carrier detected.
Manually reverting this c
On Thu, 10 Sep 2020 10:22:05 +
"Bjoern A. Zeeb" wrote:
> On 9 Sep 2020, at 22:41, Tomoaki AOKI wrote:
>
> > This breaks at least iwm. (Other drivers not tested.)
> >
> > Messages below are repeatedly shown and no carrier detected.
> > Manually reverting this commit fixes the issue.
> >
> > i
On Fri, Sep 11, 2020 at 1:57 AM O. Hartmann wrote:
> On Thu, 10 Sep 2020 10:44:08 -0600
> Alan Somers wrote:
>
> > No, it's devfs. I'll fix it.
> >
> > On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone wrote:
> >
> > > I'm curious: does this give a similar issue?
> > >
> > > touch /tmp/foo
> > > cp
Hans Petter Selasky wrote:
On 2020-09-11 14:08, Hans Petter Selasky wrote:
I think this is another variant of:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232362
Also adding this one for the record:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240609
I see, looks like the proble
On 2020-09-11 14:08, Hans Petter Selasky wrote:
I think this is another variant of:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232362
Also adding this one for the record:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240609
--HPS
___
fre
On 2020-09-11 13:47, xto...@mm.st wrote:
xto...@mm.st wrote:
Updating from latest CURRENT snapshot
(FreeBSD-13.0-CURRENT-amd64-20200910-1544934ffb2) to r365620 broke the
bridges with igb (I350-T2) for me. Booting to kernel.old and/or
commenting the entries in rc.conf helps.
rc.conf:
cl
xto...@mm.st wrote:
Updating from latest CURRENT snapshot
(FreeBSD-13.0-CURRENT-amd64-20200910-1544934ffb2) to r365620 broke the
bridges with igb (I350-T2) for me. Booting to kernel.old and/or
commenting the entries in rc.conf helps.
rc.conf:
cloned_interfaces="bridge0 bridge1 tap0 tap1
Updating from latest CURRENT snapshot
(FreeBSD-13.0-CURRENT-amd64-20200910-1544934ffb2) to r365620 broke the
bridges with igb (I350-T2) for me. Booting to kernel.old and/or
commenting the entries in rc.conf helps.
rc.conf:
cloned_interfaces="bridge0 bridge1 tap0 tap1 tap2 tap3"
ifconfig_
> > On 09.09.20 06:18, Kevin Oberman wrote:
> > > I am seeing a problem since I moved to current on my laptop this week.
> > > It's odd as it is linked to the keyboard. As long as the keyboard is
> > > active, everything is fine, but if the keyboard is not used, after a
> > > few minutes, it locks
On Thu, 10 Sep 2020 10:44:08 -0600
Alan Somers wrote:
> No, it's devfs. I'll fix it.
>
> On Thu, Sep 10, 2020 at 10:18 AM Ryan Stone wrote:
>
> > I'm curious: does this give a similar issue?
> >
> > touch /tmp/foo
> > cp /tmp/foo /tmo/foo2
> >
> > I'm wondering if the issue is that copy_file_ra
25 matches
Mail list logo
