Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: 4 significant issues with amd64 -current

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:

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

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.


Home | Main Index | Thread Index | Old Index