Re: 4 significant issues with amd64 -current

[Scott Ellis <scotte%warped.com@localhost>]

Scott Ellis wrote:
> Scott Ellis wrote:
> > Now that the ahcisata issues with the first drive not probing 
> > correctly seems to be ironed out (thanks!), I figured I'd update my 
> > Feb 11th -current to May 11th.  An install on a VMWare system worked 
> > fine, so I had high confidence in it working on my home server.  
> > Unfortunately, I had to roll back to Feb 11, due to the following 4 
> > issues:
> >
> > Issue 1:
> >     Neither root nor a normal user can login.  More precisely, 
> > entering proper credentials on either the serial console or via ssh 
> > seems to work, insomuch as I see the NetBSD banner, and the requisite 
> > "You have new mail" line.  But then instead of a shell prompt, I'm 
> > returned to the login prompt.  I can't find anything in authlog (which 
> > makes sense, since I did seem to authenticate properly!) or 
> > /var/log/messages.  This one has me utterly stumped.
> >
> > Issue 2:
> >     In single-user mode (since I can't login in multi-user...see 
> > above), "vipw" reports that it cannot find /usr/bin/vi (no such file 
> > or directory).  Of course, "vi" does reside there, and works fine. 
> > Comparing a ktrace on my VMWare installation and one on my real system 
> > shows everything identical up to:
> [snip]
>
> It looks like both of these issues are due to a regression in PAX_ASLR. 
>  Setting that to zero works around these two issues.

Issue #3 (paraphrased below):

breakpoint() at netbsd:breakpoint+0x5
panic() at netbsd:panic+0x253
lockdebug_wantlock() at netbsd:lockdebug_wantlock
rw_vector_enter() at netbsd:rw_vector_enter+0x237
prop_dictionary_iterator() at netbsd:prop_dictionary_iterator+0x67
_prop_dictionary_externalize() at netbsd:_prop_dictionary_externalize+0xa2
prop_dictionary_externalize() at netbsd:prop_dictionary_externalize+0x30
_prop_object_copyout_ioctl() at netbsd:_prop_object_copyout_ioctl+0x121
sysmonioctl_power() at netbsd:sysmonioctl_power+0xf2
VOP_IOCTL() at netbsd:VOP_IOCTL+0x64
vn_ioctl() at netbsd:vn_ioctl+0x62
sys_ioctl() at netbsd:sys_ioctl+0x11e
syscall() at netbsd:syscall+0x8f
db{1}>

This occurs when doing "envstat -I" as well.  Looks like it's a defect 
in either LOCKDEBUG (incorrectly catching a problem) or proplib.  I 
haven't looked into this, just wanted to note another way to trigger the 
problem.

It does NOT happen on my VMWare system, which makes me suspect LOCKDEBUG.

        ScottE