Date: Thu, 21 Jun 2007 17:39:49 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Alexander Pohoyda <alexander.pohoyda@gmx.net> Cc: freebsd-drivers@freebsd.org Subject: Re: Finally SiS190 NIC driver ported! Message-ID: <20070621083949.GF21711@cdnetworks.co.kr> In-Reply-To: <20070621071814.271290@gmx.net> References: <20070621071814.271290@gmx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 21, 2007 at 09:18:14AM +0200, Alexander Pohoyda wrote: > Hello, > > Based on the code of SiS900/7016 FreeBSD driver and using SiS190/191 Linux and Solaris drivers as references, I have developed a working FreeBSD driver for the above mentioned SiS190 NIC. > > It works stable for a few months on my amd64-based FreeBSD-5.4 machine in 64bit mode. I don't know whether it works in 32bit mode. I have also removed the sis_poll() code because I didn't have time to test it. > > Since this is my first driver ever, I have a few questions open which I would like to clarify. > > This NIC uses main memory for both receive and transmit descriptor rings but descriptor structures and registers are different from the ones used in SiS900/7016, so I decided to write a separate driver. How should I name this new driver? Is if_sis190.c + if_sis190reg.h right? It could later be extended to support also SiS191 NIC, I suppose. Or should I really merge the code with the sis(4) driver? I don't have any information for SiS190/191 so I don't know the differences between SiS190 and SiS900. However it's Gigabit ethernet so I guess it would require a seperate driver for the hardware. Personally, I think merging with sis(4) is not good idea. sis(4) needs big clean up for bus_dma/endian-ness. > > I do not clearly understand the reason of separating the data into list_data and chain_data structures. It seems unnecessary in my driver. It may help managing DMA tag/map and descriptor rings. > > In sis_encap() function I have to always defragment MBUF chain, otherwise big packets (e.g. during SSH connection there are packets consisting of 3 chunks) are broken. When defragmentation is done -- SSH and other protocols work. Is there a well-known mistake that causes this behavior? > Since I didn't see datasheet for the hardware I can not say what caused this. But the hardware may have required special DMA address alignment. Otherwise you may had missed descriptor set up sequences such that you may have seen the result of races with hardware. -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070621083949.GF21711>