Subject: Re: Hard lockups on 2.0_BETA when using python?
To: Joachim Thiemann <thiemann@gel.usherbrooke.ca>
From: glen mccready <gkm+nb@petting-zoo.net>
List: port-sparc
Date: 06/23/2004 11:07:57
joachim wrote:
> I have a SS4 (32Meg) with a 2.0_BETA install from releng (20040531000), 
> running GENERIC.  Since it is my "always-on" machine with few tasks (dyndns 
> updates, private FTP, ssh gateway) I decided it could be used to run some 
> bittorrents...
> 
> However, either the bitorrent process (that is, the python interpreter) or 
> the fact that load is heavy causes a machine lock-up; sometimes silent, 
> sometimes with a "Watchdog" message.
> 
> So far, I have only been able to cause that to happen with 
> "btlaunchmanycurses.py" which is why I am suspecting the heavy load issue 
> somewhat.
> 
> I have't done any kernel debugging, but if someone tells me what to do to 
> obtain more info, I'd be happy to oblige.  I have other (i386) NetBSD and 
> Linux machines on my network, so provided I can get a Sparc-PeeCee null 
> modem cable I could do remote debugging.

does it look something like this panic? :-)

http://mail-index.netbsd.org/port-sparc64/2004/02/26/0000.html

panic: ltsleep: l_stat 3 != LSONPROC
kdb breakpoint at 13220bc
Stopped in pid 8478.1 (python2p3) at    netbsd:cpu_Debugger+0x4:        nop
db> bt
ltsleep(1e24c90, 204, 1490440, 0, a74dd0c, 0) at netbsd:ltsleep+0x4bc
uvmfault_anonget(0, b569180, a74dd08, 8, 1, 181c720) at netbsd:uvmfault_anonget+0xe0
uvm_fault(48402000, 8, 2, ffffffffffffffff, 1, a7f8da0) at netbsd:uvm_fault+0x478
data_access_fault(a7f8f90, 30, 100b068, 483f8006, 483f9c10, 11081f) at netbsd:data_access_fault+0x258
[not sure what happened here in the log -gkm]
?(a7f6128, 483f9c10, 78, a7f6000, 100b0fc, 1f43c90) at 0x1008e40
rwindow_save(483f9c10, 0, 0, b160670, 41d540, 29c2c30) at netbsd:rwindow_save+0xc0
cpu_getmcontext(b459e20, b1606a0, b160660, 2441800, 2000, 3e8000) at netbsd:cpu_getmcontext+0x10
sa_upcall_getstate(b160660, b459e20, deadbeef, 0, b160620, a7f9ce0) at netbsd:sa_upcall_getstate+0x10
sa_upcall0(b160620, 2, b459e20, 0, 0, 0) at netbsd:sa_upcall0+0x90
sa_switch(a469ae0, b108090, 19d, 1486a10, 1, 0) at netbsd:sa_switch+0x21c
ltsleep(29c2c30, 11, 0, 0, 29c2c40, 188c400) at netbsd:ltsleep+0x43c
biowait(29c2c30, 2, 825e000, be, a7f99cc, 18bc400) at netbsd:biowait+0x3c
uvm_swap_io(0, 35540, 1, 100000, d5, 1f43c90) at netbsd:uvm_swap_io+0x16c
uvm_swap_get(5, 3554, 2, 0, 0, 0) at netbsd:uvm_swap_get+0x48
uvmfault_anonget(a7f9ca0, b569180, a74dd08, 8, 1, 181c720) at netbsd:uvmfault_anonget+0x2f0
uvm_fault(48402000, 8, 2, ffffffffffffffff, 1, a7f9ce0) at netbsd:uvm_fault+0x478
data_access_fault(a7f9ed0, 30, 4104e4a0, 483f8006, 483f9d8c, 800805) at netbsd:data_access_fault+0x258
?(ffffffffffffffff, ffffffffffffffff, 1b6, 0, 72cc80, badcafe) at 0x1008e40
emul_sunos32_object(ffffffffffffffff, ffffffffffffffff, ffffffffffffffff, ffffffffffffffff, ffffffffffffffff, ffffffffffffffff) at 0x4080e6fc