From owner-freebsd-current@FreeBSD.ORG Thu Oct 13 16:28:28 2005 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 2643316A41F for ; Thu, 13 Oct 2005 16:28:28 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9020943D49 for ; Thu, 13 Oct 2005 16:28:27 +0000 (GMT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.13.4/8.13.1) with ESMTP id j9DGSQ8V081061; Thu, 13 Oct 2005 09:28:27 -0700 (PDT) (envelope-from bakul@bitblocks.com) Message-Id: <200510131628.j9DGSQ8V081061@gate.bitblocks.com> To: thierry@herbelot.com In-reply-to: Your message of "Thu, 13 Oct 2005 16:21:05 +0200." <200510131621.07299.thierry@herbelot.com> Date: Thu, 13 Oct 2005 09:28:26 -0700 From: Bakul Shah Cc: freebsd-current@freebsd.org, Joshua Coombs Subject: Re: Loss of ed(4) in a RC1 booted in qemu 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: Thu, 13 Oct 2005 16:28:28 -0000 > Le Thursday 13 October 2005 15:38, Joshua Coombs a écrit : > > Welp, while I have no real help, I can point out this was reported by > > another user on the stable list, QEMU + RC1 == no ed > > well, I should have looked there before posting here ;-) (sorry for the > excellent Michel talon at lpthe.jussieu.fr : I should have seeen your post) > > > I'm kinda dreading upgrading my 386... I'll pull down the generic > > kernel and do a test boot to see if it's a QEMU thing or a reguression > > in RC1 > > for me, it's definitely a qemu thing : I have two other machines upgraded to > 6.0 post-RC1, and both are working *fine* ; moreover one is a notebook with a > > pcmcia ed(4), and this NIC works perfectly (the issue is therefore seen only > on qemu) The same problem exists on -current as well. This is due to the /dev/ed related commit done on RELENG_6 branch on 10/8 (merge from an earlier 10/5 commit done on the HEAD branch. This commit supports more ed devices but breaks qemu's ed emulation). qemu does not emulate a couple of ID registers that ed_probe_RTL_80x9() seems to insist on reading. I don't know who is right -- at this point qemu needs to be one of the standard test targets. As shown below, I worked around the problem by always calling nced_probe_Novell() as before (in /sys/dev/ed directory). NOTE: THIS IS A QUICK WORKAROUND, NOT A REAL FIX. I tried a better fix but it didn't work in the few minutes I spent on it (the idea was this: if ed_probe_RTL80x9 fails() with ENXIO, release all resources that may have been allocated by it and then call ed_probe_Novell()). Index: if_ed_pci.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ed/if_ed_pci.c,v retrieving revision 1.47 diff -w -u -b -r1.47 if_ed_pci.c --- if_ed_pci.c 5 Oct 2005 05:21:07 -0000 1.47 +++ if_ed_pci.c 12 Oct 2005 23:30:27 -0000 @@ -84,9 +84,9 @@ int flags = 0; int error; - if (pci_get_devid(dev) == ED_RTL8029_PCI_ID) - error = ed_probe_RTL80x9(dev, PCIR_BAR(0), flags); - else + //if (pci_get_devid(dev) == ED_RTL8029_PCI_ID) + //error = ed_probe_RTL80x9(dev, PCIR_BAR(0), flags); + //else error = ed_probe_Novell(dev, PCIR_BAR(0), flags); if (error) { ed_release_resources(dev);