From owner-freebsd-hackers Mon Feb 18 10: 8:32 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id C8A2F37B43E for ; Mon, 18 Feb 2002 10:08:17 -0800 (PST) Received: from pool0457.cvx22-bradley.dialup.earthlink.net ([209.179.199.202] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16csD0-0002al-00; Mon, 18 Feb 2002 10:08:15 -0800 Message-ID: <3C7142E8.E987BD6@mindspring.com> Date: Mon, 18 Feb 2002 10:07:36 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andy Sporner Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Porting a device driver from NetBSD to FreeBSD References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Andy Sporner wrote: [ ... ] At this point, lack of information about the device makes it hard to offer advice. I can only offer the following observartions, and the rest is up to you: o You indicated that the Realtek interface has ovrlapping memory, if probed and attached. Maybe it has it anyway. o You indicate that there is a register that is available through the I/O space. There has to be a reason why the vendor did this. o The following are the differences between the NetBSD and FreeBSD versions; I believe them to be significant: o The NetBSD driver does not lock up, while the FreeBSD driver does o The NetBSD "pattern write and read" is slow, but the FreeBSD version is fast My suggestion is to: 1) Print out the configuration bits on both FreeBSD and NetBSD to see if there is a difference. 2) Find out why the register is exposed in I/O space. 3) Find out why the NetBSD is slower. It may be the configuration bits. It may be the programming of the bridge chipset; it may be writeback caching; it may be something else entirely. 4) Intentionally add a delay into the FreeBSD code; for all I know about the hardware, it has DRAM on it, and accessing it at full throttle without the waits that the NetBSD version of the code has may mean that it misses too many refresh cycles and craps out. 5) Add a timeout reset to the receive interrupt; if this fixes it, the problem is in the receive interrupt getting lost. 6) "" for the transmit interrupt. 7) Consider going to NETISR based polling, where you call the ISR for the card, as if there had been an interrupt. Worst case, if everything else is equal, this will effectively poll the card, instead of waiting for interrupts, and lost interrupts will be apparent. Other than that, it's Bill Paul time... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message