headers
Paul Goyette | 1 Jan 2012 03:54

Problem with today's -current

I just did a 'build.sh release' from sources (including xsrc) updated at 
2012-01-01 01:37:13 and installed it on top of a running 5.99.55 system.

Upon reboot, the system came up normally, and then tried to start xdm. 
It failed with

 	xdm: in openpam_dynamic(): m
 	quicky xdm: in openpam_load_module(): no pam_nologin.so found

Attempting to ssh to the machine results in similar failures messages 
from sshd.

And even a local attempt to login from the console fails.

-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
NetBSD source update | 1 Jan 2012 04:11
Picon

daily CVS update output


Updating src tree:
P src/doc/CHANGES
P src/external/bsd/iscsi/lib/Makefile
P src/sbin/fdisk/fdisk.8
P src/share/man/man4/bpf.4
P src/sys/arch/hppa/hppa/db_machdep.c
P src/sys/arch/usermode/conf/Makefile.usermode
P src/sys/arch/usermode/include/thunk.h
P src/sys/arch/usermode/usermode/thunk.c
P src/sys/conf/copyright
P src/sys/ddb/db_user.h
P src/sys/dev/usb/usbdevices.config
P src/sys/net/rtsock.c
P src/sys/net80211/ieee80211_input.c
P src/sys/net80211/ieee80211_ioctl.c
P src/sys/net80211/ieee80211_netbsd.h
P src/sys/net80211/ieee80211_output.c
P src/sys/netinet/if_arp.c
P src/sys/netinet/ip_icmp.c
P src/sys/netinet/ip_output.c
P src/sys/netinet/tcp_input.c
P src/sys/netinet/tcp_output.c
P src/sys/netinet/tcp_subr.c
P src/sys/netinet6/frag6.c
P src/sys/netinet6/icmp6.c
P src/sys/netinet6/in6_ifattach.c
P src/sys/netinet6/in6_pcb.c
P src/sys/netinet6/in6_proto.c
P src/sys/netinet6/ip6_input.c
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Goyette | 1 Jan 2012 16:30

Problems updating on amd64

My current system is running 5.99.55 from August 20th.

If I install a -current kernel from today (all sources updated just a 
short while ago), the system will run fine and even boot into multi-user 
mode.  I can log in, either via the console or ssh.

However, as soon as I start xdm, the system locks up hard.  Not able to 
get a dump or backtrace.  I have to use the 'reset' button to reboot.

-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------
Permalink | Reply | 3 comments |
headers
Paul Goyette | 1 Jan 2012 16:32

Re: Problems updating on amd64

On Sun, 1 Jan 2012, Paul Goyette wrote:

> My current system is running 5.99.55 from August 20th.
>
> If I install a -current kernel from today (all sources updated just a short 
> while ago), the system will run fine and even boot into multi-user mode.  I 
> can log in, either via the console or ssh.
>
> However, as soon as I start xdm, the system locks up hard.  Not able to get a 
> dump or backtrace.  I have to use the 'reset' button to reboot.

Oh, and as previously reported, installing a -current usermode fails to 
get a working pam.

-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
Paul Goyette | 1 Jan 2012 16:57

/sbin/restore behavior

While trying to recover from my recent attempts to upgrade, I have 
noticed that '/sbin/restore -x -u' doesn't seem to work as expected.

I would expect the -u to unlink both the files _and_hard_links_ being 
restored.  However, when restoring a hard link, it does not unlink the 
original, and displays an error message instead.

Is this behavior correct?

-------------------------------------------------------------------------
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer |                          | pgoyette at netbsd.org  |
-------------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
Thomas Klausner | 2 Jan 2012 01:14
Picon

Re: firefox + flash exit -> ddb

On Thu, Dec 08, 2011 at 07:51:34AM -0800, Chuck Silvers wrote:
> I saw this problem pretty regularly earlier this year, but I haven't seen it
> in the last two months or so.  if someone could send me a crash dump from
> one of these crashes, that would be great.  I never managed to get a dump
> back when it was happening to me.

I've just reproduced this bug with my 5.99.58 kernel.
It doesn't happen everytime, but when firefox runs for a longer time,
the chances are pretty good. Visiting a flash site is not a guarantee for
the bug.

Sadly, when I "reboot 0x104"ed, I got a recursive panic.

Here's the backtrace of the original panic:
panic: kernel diagnostic assertion "anon != NULL && anon->an_ref !=
failed: file "/archive/cvs/src/sys/uvm/uvm_amap.c", line 718
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip ... cs 8 rflags 246 cr2 ... cpl
rsp ...
Stopped in pid 765.5103 (xulrunner-bin) at netbsd:breakpoint+0x5: leave
breakpint
vpanic
kern_assert
awap_wipeout
uvm_unmap_detach
uvmspace_free
exit1
sigexit
postsig
lwp_userret
(Continue reading)

Permalink | Reply | 3 comments |
headers
NetBSD source update | 2 Jan 2012 04:39
Picon

daily CVS update output


Updating src tree:
P src/crypto/dist/ipsec-tools/src/racoon/cfparse.y
P src/crypto/dist/ipsec-tools/src/racoon/cftoken.l
P src/crypto/dist/ipsec-tools/src/racoon/cftoken_proto.h
P src/crypto/dist/ipsec-tools/src/racoon/grabmyaddr.c
P src/crypto/dist/ipsec-tools/src/racoon/handler.c
P src/crypto/dist/ipsec-tools/src/racoon/ipsec_doi.c
P src/crypto/dist/ipsec-tools/src/racoon/ipsec_doi.h
P src/crypto/dist/ipsec-tools/src/racoon/isakmp.c
P src/crypto/dist/ipsec-tools/src/racoon/isakmp_unity.c
P src/crypto/dist/ipsec-tools/src/racoon/localconf.c
P src/crypto/dist/ipsec-tools/src/racoon/localconf.h
P src/crypto/dist/ipsec-tools/src/racoon/pfkey.c
P src/crypto/dist/ipsec-tools/src/racoon/remoteconf.c
P src/crypto/dist/ipsec-tools/src/racoon/sainfo.c
P src/dist/ipf/ipsend/iptest.1
P src/distrib/utils/sysinst/util.c
P src/lib/libcrypt/crypt.3
P src/share/man/man8/man8.sandpoint/altboot.8
P src/sys/arch/hppa/spmath/fcnvfx.c
P src/sys/arch/hppa/spmath/fcnvfxt.c
P src/sys/arch/sandpoint/stand/altboot/README.altboot
P src/sys/arch/sandpoint/stand/altboot/main.c
P src/sys/arch/usermode/dev/vncfb.c
P src/sys/arch/usermode/usermode/pmap.c
P src/sys/sys/quota.h
P src/usr.bin/nl/nl.1
P src/usr.bin/soelim/soelim.1
P src/usr.sbin/wsmoused/wsmoused.8
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Husemann | 2 Jan 2012 14:49
Picon

Re: firefox + flash exit -> ddb

On Mon, Jan 02, 2012 at 01:14:50AM +0100, Thomas Klausner wrote:
> I've just reproduced this bug with my 5.99.58 kernel.
> It doesn't happen everytime, but when firefox runs for a longer time,
> the chances are pretty good. Visiting a flash site is not a guarantee for
> the bug.

I have seen it (on amd64, current as of a few days ago) once, without any
flash or other plugins involved.

Unfortunately I didn't get a crash dump.

Martin
Permalink | Reply | 0 comments |
headers
Gary Duzan | 2 Jan 2012 14:59
Favicon

Re: firefox + flash exit -> ddb

In Message <20120102134926.GA8397 <at> mail.duskware.de>,
   Martin Husemann <martin <at> duskware.de>wrote:

=>On Mon, Jan 02, 2012 at 01:14:50AM +0100, Thomas Klausner wrote:
=>> I've just reproduced this bug with my 5.99.58 kernel.
=>> It doesn't happen everytime, but when firefox runs for a longer time,
=>> the chances are pretty good. Visiting a flash site is not a guarantee for
=>> the bug.
=>
=>I have seen it (on amd64, current as of a few days ago) once, without any
=>flash or other plugins involved.
=>
=>Unfortunately I didn't get a crash dump.

   I get screen mangling and a hard lock instead, but I get it under
similar circumstances. This stabilizes things for me, so it may be
worth a shot.

Index: sys/arch/amd64/include/types.h
===================================================================
RCS file: /usr2/netbsd-cvs/src/sys/arch/amd64/include/types.h,v
retrieving revision 1.40
diff -u -r1.40 types.h
--- sys/arch/amd64/include/types.h	4 Dec 2011 16:24:13 -0000	1.40
+++ sys/arch/amd64/include/types.h	2 Jan 2012 13:54:18 -0000
 <at>  <at>  -95,7 +95,7  <at>  <at> 
 #define	__HAVE_RAS

 #include "opt_xen.h"
-#if defined(__x86_64__) && !defined(XEN)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chuck Silvers | 2 Jan 2012 18:13
Favicon

Re: System freeze w/display strangeness on amd64/current

On Tue, Dec 27, 2011 at 07:52:29AM -0500, Gary Duzan wrote:
> In Message <20111225114643.GD11619 <at> mail.duskware.de>,
>    Martin Husemann <martin <at> duskware.de>wrote:
> 
> =>On Fri, Dec 23, 2011 at 08:20:51PM -0500, Gary Duzan wrote:
> =>>    Any thoughts for diagnosing the problem? Loading older versions
> =>> would be possible, if a bit messy. dmesg included below.
> =>
> =>Just a very tiny straw, but you could try to comment out the 
> =>
> =>#define __HAVE_DIRECT_MAP 1
> =>#define __HAVE_MM_MD_DIRECT_MAPPED_IO
> =>#define __HAVE_MM_MD_DIRECT_MAPPED_PHYS
> =>
> =>block in /usr/src/sys/arch/amd64/include/types.h and build a new kernel.
> 
>    Thanks for this. I #if 0'd out those lines, and things seem much
> more stable now. I ran the full test suite and have been browsing
> using Firefox without incident for a while. From the commit note,
> I guess the video memory is being grabbed by a large page allocation
> improperly?

if the physical address of the video memory is less than the highest
physical address of normal memory, then it's being mapped by the
direct-map, yes.  that shouldn't cause a problem since nothing should be
referencing non-RAM addresses via the direct map, but there may be something
subtle going on.  openbsd and freebsd also have a direct map that includes
the gaps between RAM regions, and they apparently don't have these problems,
so something else that we're doing differently must be involved.
(Continue reading)

Permalink | Reply | 10 comments |

Gmane