Bug #1239

Another rt remote backtrace

Added by pavalos almost 6 years ago. Updated over 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

rt remote free rt_cpuid 0, mycpuid 1
Stack backtrace:
Trace beginning at frame 0xdb5d2c4c
backtrace(c035259b) at backtrace+0x12
backtrace(c0374d74,0,1,f27da5e0,dacd3a00) at backtrace+0x12
rtfree_remote(ec20d960,1) at rtfree_remote+0x74
rtfree(ec20d960) at rtfree+0x2e
in_pcbdetach(dacd3a00) at in_pcbdetach+0x60
tcp_close(dacd3ac0,c0469334,f0d24620,f0d24620,db5d2d38) at tcp_close+0x575
tcp_drop(dacd3ac0,35,f27da5e0,db5d2d50,c01e639f) at tcp_drop+0x7d
tcp_usr_abort(f27da5e0,0,f0d24620,0,db5d2d64) at tcp_usr_abort+0x61
netmsg_pru_abort(f0d24620,f0d24620,0,db5d2d84,c024f073) at netmsg_pru_abort+0x34
netmsg_service(f0d24620,1,0,ff8083b0,ff808000) at netmsg_service+0x44
tcpmsg_service_loop(0,0,0,0,0) at tcpmsg_service_loop+0x40
lwkt_exit() at lwkt_exit

Running a kernel on master from Jan. 3rd.

--Peter

History

#1 Updated by sepherosa almost 6 years ago

On Thu, Jan 22, 2009 at 10:44 AM, Peter Avalos (via DragonFly issue
tracker) <> wrote:
>
> New submission from Peter Avalos <>:
>
> rt remote free rt_cpuid 0, mycpuid 1
> Stack backtrace:
> Trace beginning at frame 0xdb5d2c4c
> backtrace(c035259b) at backtrace+0x12
> backtrace(c0374d74,0,1,f27da5e0,dacd3a00) at backtrace+0x12
> rtfree_remote(ec20d960,1) at rtfree_remote+0x74
> rtfree(ec20d960) at rtfree+0x2e
> in_pcbdetach(dacd3a00) at in_pcbdetach+0x60
> tcp_close(dacd3ac0,c0469334,f0d24620,f0d24620,db5d2d38) at tcp_close+0x575
> tcp_drop(dacd3ac0,35,f27da5e0,db5d2d50,c01e639f) at tcp_drop+0x7d
> tcp_usr_abort(f27da5e0,0,f0d24620,0,db5d2d64) at tcp_usr_abort+0x61
> netmsg_pru_abort(f0d24620,f0d24620,0,db5d2d84,c024f073) at netmsg_pru_abort+0x34
> netmsg_service(f0d24620,1,0,ff8083b0,ff808000) at netmsg_service+0x44
> tcpmsg_service_loop(0,0,0,0,0) at tcpmsg_service_loop+0x40
> lwkt_exit() at lwkt_exit
>
> Running a kernel on master from Jan. 3rd.

Please test/review following patch:
http://leaf.dragonflybsd.org/~sephe/0001-syncache_socket-fix-abort-path-by-calling-pru_abo.patch

I also believe that tcp_soport() maps socket to the wrong CPU on
syncache_socket() abort path is the root cause of the aborting dead
lock Matt mentioned in the previous uipc_socket.c commit log.

Best Regards,
sephe

#2 Updated by sepherosa almost 6 years ago

If no problem pops up and no objection comes, I plan to commit the
above patch on Feb 1.

Best Regards,
sephe

#3 Updated by sepherosa over 5 years ago

I believe fd86a41c7ed1881bb55e1ad5c825daf2f245a8b6 fixed this bug.

Also available in: Atom PDF