Updating src tree:
P src/distrib/utils/embedded/conf/arm64.conf
P src/distrib/utils/embedded/conf/arm64mbr.conf
P src/distrib/utils/embedded/files/ec2_init
P src/sys/arch/hppa/hppa/intr.c
P src/sys/dev/ic/ax88190.c
P src/sys/dev/ic/dl10019.c
P src/sys/dev/ic/dp8390.c
P src/sys/dev/pci/if_ena.c
P
> On Jul 1, 2021, at 1:53 PM, Björn Johannesson wrote:
>
>
> Yep. That fixes the media problems. Great!
> Would it be easy to backport the media fix to netbsd9?
I think so, yes. I’ll send a pull-up request for that.
Thanks for your patience with this!
-- thorpej
On Thu, Jul 01, 2021 at 07:04:24PM +, David Holland wrote:
> However, except in the fastforward code the vnode will be locked. So I
> think it should be "= = =" in vnode_if.src. If you also need to add
> FSTRANS=NO, that should be fine too.
I'm testing this:
diff -r bb3a26d8fb23
> On 1. Jul 2021, at 21:04, David Holland wrote:
>
> On Thu, Jul 01, 2021 at 07:54:33PM +0200, J. Hannken-Illjes wrote:
>> lookup_fastforward -> lookup_parsepath -> VOP_PARSEPATH -> ... ->
>> fstrans_start
>
> Bleh. I had a feeling we were going to end up regretting that
> fastforward code.
On Wed, Jun 30, 2021 at 05:57:46PM +, David Holland wrote:
> Sorry, that patch of mine seems to have been pretty broken. Not
> entirely sure how it managed to pass the test runs... maybe I tested
> the wrong kernel or something (?)
And for the record it looks like I did test the wrong
On Thu, Jul 01, 2021 at 07:54:33PM +0200, J. Hannken-Illjes wrote:
> lookup_fastforward -> lookup_parsepath -> VOP_PARSEPATH -> ... ->
> fstrans_start
Bleh. I had a feeling we were going to end up regretting that
fastforward code. :-|
> According to vnode_if.src VOP_PARSEPATH(dvp...)
> On 1. Jul 2021, at 18:24, Martin Husemann wrote:
>
> I did not trust macppc / lockdebug so reproduced it on evbarm.
>
> Unfortunately nearly identical (not making any sense to me) output again...
I'm quite sure one thread does something like
lookup_fastforward -> lookup_parsepath ->
I did not trust macppc / lockdebug so reproduced it on evbarm.
Unfortunately nearly identical (not making any sense to me) output again...
Martin
db> show locks
[Locks tracked through LWPs]
** LWP 1370.1370 (umount) @ 0xc488b180, l_stat=3
db> bt/a 0xc488b180
trace: pid 1370 lid 1370 at
Same output again, augmented with stack traces.
Martin
db{0}> show locks
[Locks tracked through LWPs]
** LWP 1856.1856 (rxvt) @ 0x1372f100, l_stat=3
*** Locks held: none
*** Locks wanted:
* Lock 0 (initialized at fstrans_init)
lock address : 0x00c0f2c0 type :
Here is show locks and ps output while the test hangs
Martin
db{0}> show locks
[Locks tracked through LWPs]
** LWP 1856.1856 (rxvt) @ 0x1372f100, l_stat=3
*** Locks held: none
*** Locks wanted:
* Lock 0 (initialized at fstrans_init)
lock address : 0x00c0f2c0 type :
On Thu, Jul 01, 2021 at 10:54:45AM +0300, Andreas Gustafsson wrote:
> Martin Husemann wrote:
> > Hmm, that is the last commit I needed to get everything working again
> > here - any idea what exactly hangs and where?
>
> The same way it has been hanging ever since dholland's commit of
>
Martin Husemann wrote:
> Hmm, that is the last commit I needed to get everything working again
> here - any idea what exactly hangs and where?
The same way it has been hanging ever since dholland's commit of
2021.06.29.22.37.11 (except for a period when the tests didn't even
start):
On Thu, Jul 01, 2021 at 09:56:03AM +0300, Andreas Gustafsson wrote:
> Martin Husemann wrote:
> > All regressions I am aware of have been fixed now.
>
> At least i386 still hangs while running the ATF tests as of source
> date 2021.07.01.04.25.51.
Hmm, that is the last commit I needed to get
Martin Husemann wrote:
> All regressions I am aware of have been fixed now.
At least i386 still hangs while running the ATF tests as of source
date 2021.07.01.04.25.51.
--
Andreas Gustafsson, g...@gson.org
> All regressions I am aware of have been fixed now.
>
> Martin
Thank you all.
15 matches
Mail list logo
