Date: Tue, 19 Sep 2006 21:01:25 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> Cc: freebsd-net@freebsd.org Subject: Re: Marvell YukonII Status Update? Message-ID: <20060919120125.GA34461@cdnetworks.co.kr> In-Reply-To: <20060919125046.E35560@atlantis.atlantis.dp.ua> References: <ef10de9a0606292053i31abe4e2na30ec0028b54da8e@mail.gmail.com> <20060918150510.D33680@atlantis.atlantis.dp.ua> <20060918124431.GD30078@cdnetworks.co.kr> <20060919125046.E35560@atlantis.atlantis.dp.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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@atlantis.dp.ua > nic-hdl: LYNX-RIPE -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060919120125.GA34461>