From owner-freebsd-current@FreeBSD.ORG Sun May 7 20:45:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 318C216A42A; Sun, 7 May 2006 20:45:12 +0000 (UTC) (envelope-from garrison@mail.ru) Received: from umail.ru (umail.ru [195.34.32.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C0EA43DA0; Sun, 7 May 2006 20:44:46 +0000 (GMT) (envelope-from garrison@mail.ru) Received: from [85.141.196.97] (HELO skyserv) by umail.ru (CommuniGate Pro SMTP 4.2b6) with ESMTP-TLS id 668321361; Mon, 08 May 2006 00:44:45 +0400 Received: from localhost ([127.0.0.1]) by skyserv with esmtp (Exim 4.61) (envelope-from ) id 1Fcq7Q-0001nh-E4; Mon, 08 May 2006 00:44:44 +0400 Message-ID: <445E5C3B.405@mail.ru> Date: Mon, 08 May 2006 00:44:43 +0400 From: Igor Kovalenko User-Agent: Thunderbird 1.5.0.2 (X11/20060505) MIME-Version: 1.0 To: nox@jelal.kn-bremen.de, freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Gleb Smirnoff 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> <20060507164230.GA63540@saturn.kn-bremen.de> In-Reply-To: <20060507164230.GA63540@saturn.kn-bremen.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 07 May 2006 22:41:44 +0000 Cc: Subject: Re: playing with qemu's 8139 nic and FreeBSD (loopback mode missing? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2006 20:45:13 -0000 Hi Juergen, Juergen Lock wrote: > 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) > I see the re driver actually is doing 2 byte write at RL_TXSTART so the second byte goes to RL_MAXRXPKTLEN. Comment in if_rlreg.h says RL_TXSTART is 8bit so this is a bug in if_re.c line 2063 This is not affecting qemu's card emulation (the extra byte write is ignored) so I think the problem is somewhere else. -- Kind regards, Igor V. Kovalenko