[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
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.
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
It does NOT happen on my VMWare system, which makes me suspect LOCKDEBUG.
Main Index |
Thread Index |