Re: Hangs while building the tree in -current

["Chavdar Ivanov" <ci4ic4%gmail.com@localhost>]

2008/6/12 M Graff <explorer%flame.org@localhost>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> | Either way, it still doesn't progress. Are either of you on nfs
> mounted src?
>
> All disks are local for me.  On my Xen machines, source is NFS mounted,
> but the build completes.
>
> My build disk on the locking-up machine is the same disk as the source
> tree.  Additionally, I have a SATA controller in there but I cannot use
> it as it locks up (since about 5 months ago) due to interrupt routing.
>
> - --Michael
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
>
> iD8DBQFIULlWl6Nz7kJWYWYRAqHdAJ40AxuKqO+znmRwMeCnr0hkya+8FgCfVDcn
> k/0eiCIW/44Y6S92p45cdTc=
> =AZMc
> -----END PGP SIGNATURE-----
>

I got the same again - this time I even forgot to actually start the
build and left the machine overnight just doing cvs update. In the
morning it was pingable, but any attemt to start enything resulted in
"resource temporarily unavailable" message. I could not shut the box
at all, so I break into ddb; dmesg showd me hundreds of "increase
kern.maxproc or NPROC" messages; the trace is as follows (although
probably not useful):

>======...===========<
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386--netbsdelf"...
(gdb) target kvm netbsd.14.core
#0  0xc0518792 in cpu_reboot ()
(gdb) bt
#0  0xc0518792 in cpu_reboot ()
#1  0xc01b3aa8 in db_reboot_cmd ()
#2  0xc01b35b8 in db_command ()
#3  0xc01b3902 in db_command_loop ()
#4  0xc01b6810 in db_trap ()
#5  0xc05137bb in kdb_trap ()
#6  0xc051b3ac in trap ()
#7  0xc010cd8f in calltrap ()
#8  0xc0511e9c in breakpoint ()
#9  0xc031610a in wskbd_translate ()
#10 0xc03162ff in wskbd_input ()
#11 0xc0686cd1 in pckbd_input ()
#12 0xc02da132 in pckbcintr ()
#13 0xc0502d6f in intr_biglock_wrapper ()
#14 0xc01032d9 in Xintr_ioapic_edge1 ()
#15 0xc0511f35 in x86_stihlt ()
Previous frame inner to this frame (corrupt stack?)
(gdb)

I'll try now with kern.maxproc up to, say, 5000 from the default just
over a thousand.



-- 
Bill Watterson  - "There is not enough time to do all the nothing we
want to do."