Re: msk Marvell Yukon 88E8038 hangs

On Sat, Jan 10, 2009 at 08:19:50AM -0500, Kim Culhan wrote:
 > On Fri, Jan 9, 2009 at 10:18 PM, Pyun YongHyeon <pyunyh_at_gmail.com> wrote:
 > > On Fri, Jan 09, 2009 at 03:43:38PM -0500, Kim Culhan wrote:
 > >  > On Fri, Jan 9, 2009 at 1:10 AM, Pyun YongHyeon <pyunyh_at_gmail.com> wrote:
 > >  > > On Thu, Jan 08, 2009 at 11:35:28AM -0500, Kim Culhan wrote:
 > >  > >  > On Thu, Jan 8, 2009 at 2:51 AM, Pyun YongHyeon <pyunyh_at_gmail.com> wrote:
 > 
 > >  > > Ok, then how about disabling TSO/Tx checksum offload?
 > >  > > (eg. ifconfig msk0 -tso -txcsum)
 > >  >
 > >  > This stops the messages: in_cksum_skip: out of data by 56952
 > >
 > > Ok, would you try attached patch?
 > 
 > With the patch there are no in_cksum_skip messages
 > 

Thanks for testing!

 > a cvsup session still has:
 > Network write failure: Connection timed out
 > 

That's odd, I can't reproduce this on my box. If you disable Tx
checksum offload of msk(4), cvsup session completes without
problems?
When cvsup plains network errors, can you still send/receive
packets with msk(4)?

 > There are some instances of LOR, maybe these are already known:
 > 

Probably yes.

 > lock order reversal:
 >  1st 0xd9544090 bufwait (bufwait) _at_ kern/vfs_bio.c:2443
 >  2nd 0xc5d72c00 dirhash (dirhash) _at_ ufs/ufs/ufs_dirhash.c:263
 > KDB: stack backtrace:
 > db_trace_self_wrapper(c0be4788,e8308778,c0871d75,4,c0bdfd93,...) at
 > db_trace_self_wrapper+0x26
 > kdb_backtrace(4,c0bdfd93,c55236d8,c5526528,e83087d4,...) at kdb_backtrace+0x29
 > _witness_debugger(c0be7442,c5d72c00,c0c06baa,c5526528,c0c06850,...) at
 > _witness_debugger+0x25
 > witness_checkorder(c5d72c00,9,c0c06847,107,0,...) at witness_checkorder+0x839
 > _sx_xlock(c5d72c00,0,c0c06847,107,c5f7d7f8,...) at _sx_xlock+0x85
 > ufsdirhash_acquire(d9544030,e83088ec,30,da9360a4,e83088a4,...) at
 > ufsdirhash_acquire+0x35
 > ufsdirhash_add(c5f7d7f8,e83088ec,30a4,e8308890,e8308894,...) at
 > ufsdirhash_add+0x13
 > ufs_direnter(c5e13860,c6054648,e83088ec,e8308bd4,0,...) at ufs_direnter+0x729
 > ufs_makeinode(e8308bd4,e8308acc,e8308acc,e8308a34,c0b41375,...) at
 > ufs_makeinode+0x519
 > ufs_create(e8308acc,e8308acc,0,e8308acc,e8308ba8,...) at ufs_create+0x30
 > VOP_CREATE_APV(c0ceb5a0,e8308acc,2,c0bda5a0,3,...) at VOP_CREATE_APV+0xa5
 > vn_open_cred(e8308ba8,e8308c5c,180,c5b05200,c595e498,...) at vn_open_cred+0x1d0
 > vn_open(e8308ba8,e8308c5c,180,c595e498,2e0013,...) at vn_open+0x33
 > kern_openat(c596cd80,ffffff9c,82561e0,0,603,...) at kern_openat+0x110
 > kern_open(c596cd80,82561e0,0,602,180,...) at kern_open+0x35
 > open(c596cd80,e8308cf8,c,c0be7c53,c0cc6918,...) at open+0x30
 > syscall(e8308d38) at syscall+0x2a3
 > Xint0x80_syscall() at Xint0x80_syscall+0x20
 > --- syscall (5, FreeBSD ELF32, open), eip = 0x2823b8d3, esp =
 > 0x8202a60, ebp = 0x8202afc ---
 > 
 > --
 > -kim

-- 
Regards,
Pyun YongHyeon