Marvell YukonII Status Update?

[Pyun YongHyeon]

On Tue, Sep 19, 2006 at 12:58:59PM +0300, Dmitry Pryanishnikov wrote:
 > 
 > Hello!
 > 
 > On Mon, 18 Sep 2006, Pyun YongHyeon wrote:
 > >> 1. Has situation with this driver improved somehow (is somebody going to
 > >>    support it and commit into the CURRENT)?
 > >>
 > >
 > >I'm working on it. Unlike OpenBSD/NetBSD msk(4) my code is based on
 > >sk(4) and myk(4) from Marvell. I've managed to send packets with new
 > >driver but it needs more testing and codes to support hardware
 > >features(VLAN tagging, TSO support, RX checksum offload etc). I can't
 > >sure TSO support could be done due to lack of documentation.
 > 
 >   Wow, great! Where can I get the latest version of your driver for fresh
 > RELENG_6? I'm willing to test it! I could live w/o TSO support and RX 

Unfortunately it's only for CURRENT at the moment and it needs big
cleanups. Rx TCP/UDP checksum offload has the same issue I've seen
on sk(4). I've tried every possible combinations I can think of but
have no clue yet. Personally I think checksum offload has more
important than that of TSO. If any guys know the magic of Rx checksum
offload on Yukon II please let me know.

 > checksum
 > offload; while hardware VLAN tagging is desirable feature. Does your driver
 > support software VLAN tagging currently?
 > 

Yes. Today, I've made hardware VLAN tag insertion/stripping work.        
I'll post my code when it's ready for more testing.

 > >> 2. What kinds of performance problems / stability issues should I expect
 > >>    with the driver in it's current state under 6-STABLE?
 > >You can see lots of witness warnings. Unloading the driver module or
 > 
 >  Indeed (after enabling WITNESS, loading the module and just connecting the 
 > cable):
 > 
 > myk0: link up
 > lock order reversal:
 >  1st 0xc4c13084 LE Status (LE Status) @ sky2.c:1757
 >  2nd 0xc4c131d0 Tx LE async port 1 (Tx LE async port 1) @ sky2.c:2877
 > KDB: stack backtrace:
 > kdb_backtrace(0,ffffffff,c06550e0,c06551a8,c0624924,...) at 0xc04b3eed = 
 > kdb_backtrace+0x29
 > witness_checkorder(c4c131d0,9,c087a299,b3d) at 0xc04be9a8 = 
 > witness_checkorder+0x578
 > _mtx_lock_flags(c4c131d0,0,c087a299,b3d,80246,...) at 0xc0494278 = 
 > _mtx_lock_flags+0x78
 > ProcessStatusList(c04ad267,40000000,2,c05f4e6c,267,...) at 0xc085757d = 
 > ProcessStatusList+0x2c9
 > Yk2IntServiceRoutine(c4c10000) at 0xc0857f70 = Yk2IntServiceRoutine+0x150
 > ithread_execute_handlers(c4bae218,c4ae0280) at 0xc0488ed6 = 
 > ithread_execute_handlers+0xe6
 > ithread_loop(c4c09be0,e35a5d38,c4c09be0,c0488f94,0,...) at 0xc0488ffa = 
 > ithread_loop+0x66
 > fork_exit(c0488f94,c4c09be0,e35a5d38) at 0xc0488144 = fork_exit+0xa0
 > fork_trampoline() at 0xc05b745c = fork_trampoline+0x8
 > --- trap 0x1, eip = 0, esp = 0xe35a5d6c, ebp = 0 ---
 > 
 > >using Jumboframe may panic your system.
 > 
 >   Thanks for the information!
 > 
 > >Regards,
 > >Pyun YongHyeon
 > 
 > Sincerely, Dmitry
 > -- 
 > Atlantis ISP, System Administrator
 > e-mail:  dmitry at atlantis.dp.ua
 > nic-hdl: LYNX-RIPE

-- 
Regards,
Pyun YongHyeon