From owner-freebsd-emulation@FreeBSD.ORG Sun May 7 16:45:10 2006 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4FD816A400; Sun, 7 May 2006 16:45:10 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id C080F43D4C; Sun, 7 May 2006 16:45:09 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k47Gj7fJ002746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 7 May 2006 18:45:07 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id k47Gj7vY002744; Sun, 7 May 2006 18:45:07 +0200 Received: from saturn.kn-bremen.de (nox@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.3/8.13.1) with ESMTP id k47GgWpc063719; Sun, 7 May 2006 18:42:32 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.3/8.13.1/Submit) id k47GgVg2063718; Sun, 7 May 2006 18:42:31 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sun, 7 May 2006 18:42:30 +0200 To: Igor Kovalenko Message-ID: <20060507164230.GA63540@saturn.kn-bremen.de> Mail-Followup-To: Igor Kovalenko , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Gleb Smirnoff , nox@jelal.kn-bremen.de References: <20060427203718.GA15953@saturn.kn-bremen.de> <445241DE.9020909@mail.ru> <20060428221142.GA11504@saturn.kn-bremen.de> <44530C50.6040902@mail.ru> <20060430004646.GA70632@saturn.kn-bremen.de> <4458277F.4010902@mail.ru> <20060506152059.GA33481@saturn.kn-bremen.de> <445D092E.2040501@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <445D092E.2040501@mail.ru> User-Agent: Mutt/1.4.2.1i Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Gleb Smirnoff , nox@jelal.kn-bremen.de Subject: Re: playing with qemu's 8139 nic and FreeBSD (loopback mode missing? X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2006 16:45:11 -0000 On Sun, May 07, 2006 at 12:38:06AM +0400, Igor Kovalenko wrote: > Hi Juergen, > > Juergen Lock wrote: > >[Cc'ing glebius@ because he did most of the recent re(4) commits, and > >-current in case possible other driver developers didn't see this thread > >in -emulation] > > > >On Wed, May 03, 2006 at 07:46:07AM +0400, Igor Kovalenko wrote: > >>Juergen Lock wrote: > >>>On Sat, Apr 29, 2006 at 10:48:48AM +0400, Igor Kovalenko wrote: > >>>>Juergen Lock wrote: > >>>>>On Fri, Apr 28, 2006 at 08:25:02PM +0400, Igor Kovalenko wrote: > >>>>>>Juergen Lock wrote: > >>>>>>>I played with > >>>>>>> qemu -monitor stdio -m 256 -cdrom 6.1-RC1-i386-disc1.iso > >>>>>>> -usb -soundhw es1370 -kernel-kqemu -net nic,model=rtl8139 > >>>>>>> -net user > >>>>>>>and got it as far as > >>>>>>> re0: diagnostic failed, failed to receive packet in loopback > >>>>>>> mode > >>>>>>>(followed by a panic :) with the (experimental) patches below. > >>>>>>> > >>>>>>> Anyone in the mood to implement loopback mode for this nic? > >>>>>>> > >>>>>>> Hmm actually... I just found the original posting in the archive, > >>>>>>>is C+ mode implemented now? If not re is probably not what I want, > >>>>>>The rtl8139 is set up with PCI rev ID 0x20 which should be enough for > >>>>>>OS driver > >>>>>>to detect C+ mode features. C+ mode is OK, tested with Linux driver. > >>>>>Cool, so I want FreeBSD's re driver. That one checks TxConfig > >>>>>tho, as changed in my patch (inside #if 0). And when changed, > >>>>>it still doesn't work as mentioned above because the driver expects > >>>>>loopback mode to be working. > >>>>>>>but the rl driver that it attaches without that #if 0'd (now) hunk > >>>>>>>below doesnt seem to be able to get data thru either and I get > >>>>>>> rl0: watchdog timeout > >>>>>>>in dmesg, which usually means the driver doesnt receive interrupts. > >>>>>>> > >>>>>>> What the heck, I'll append a log of a run just doing in > >>>>>>> fixit->cdrom: > >>>>>>> ifconfig rl0 10.0.2.15 > >>>>>>>and then exiting (which is enough to trigger the watchdog timeout...) > >>>>>>> > >>>>>>I'm too lasy to test with fresh freebsd installation :) > >>>>> No need to install FreeBSD, you can get away by just using > >>>>>fixit mode of an install iso, i.e. disc1. (which actually is > >>>>>what I did above. :) > >>>>> > >>>>> You can look at 6.1RC's re driver here: > >>>>>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c?annotate=1.46.2.14 > >>>>> which includes: > >>>>>http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/pci/if_rlreg.h?annotate=1.51.2.3 > >>>>> > >>>>> And 6.1RC disc1 iso is e.g. here: > >>>>>ftp://ftp.ru.freebsd.org:/pub/FreeBSD/ISO-IMAGES-i386/6.1/6.1-RC1-i386-disc1.iso > >>>>> > >>>>> > >>>>Thanks, that iso pointer made it. > >>>> > >>> :) > >>> > >>>>Please try the following on top of your patch, at least ping should now > >>>>work: > >>> Thanks, that seems to get the rl driver going. Now to fix C+ mode > >>>(re driver) change the #if 0 in my patch to #if 1... > >>> > >>> > >>I believe freebsd re driver is somewhat broken, e.g. it does not follow > >>documented > >>procedure to detect hardware features (e.g. 8139 c+ mode) > > > >Hmm, a bit of googling didn't reveal docs about this, do you have > >a pointer? (I only found the data sheet at > > http://people.freebsd.org/~wpaul/RealTek/spec-8139cp(150).pdf > >which doesnt seem to mention detecting c+ hardware specifically) > > Well, I might have misread some docs; please do not consider this as an > assault :) > I remember PCI rev id >= 0x20 is C+ mode for realtek 8139. I don't. It may well be the doc you saw this in just is no longer online, or I didn't came up with the right search terms... > > > > >> and in tries to use 8169 > >>registers (e.g. 0xda) on 8139 hardware etc. > > > > Oh, then it must have mis-detected the nic as a 8169 because > >the code in question reads: > > > > if (sc->rl_type == RL_8169) > > CSR_WRITE_2(sc, RL_MAXRXPKTLEN, 16383); And with your patch i get RTL8139: not implemented write(b) addr=0xda val=0x00 but that can't be this line anyway because it seems to be a byte access... Any of the re(4) experts have an idea where this comes from? (log generated by defining DEBUG_RTL8139 in the patched hw/rtl8139.c) > >>Therefore some action from driver people is needed; I can provide a patch > >>which > >>enables board timer in rtl8139 emulation (and thus enables hardware > >>timeout > >>events) if you need it. > > > > Yeah I guess that would be useful... > > > > > > Please find rtl8139.c.freebsd.timer.diff attached hereto. > The diff contains part of your changes to chip identification so re driver > does see it as C+ mode chip. Timer support is added (and there is no kpanic > now), > though the specs require it to be clocked with PCI bus; that is somewhat > hard > to achieve. Common qemu timer is of much lower resolution; doing it > differently > will require some effort. Thankx! (I doubt cycle accuracy is really needed here anyway, and afaik nowhere else in qemu is that done either.)