The problem must be other; I have a Voodoo3 3000 and its runing under 9.0 better than ever in linux, DRI reach maximum fps even than in windows98 (tuxracer installed for both OS), probably due to the new XFree86 4.2.
Perhaps is the sound card the problem???? Francisco Alcaraz Murcia (Spain) ----- Mensaje Original ----- Remitente: Ben Reser <[EMAIL PROTECTED]> Fecha: Martes, Octubre 1, 2002 3:46 am Asunto: Re: [Cooker] 9.0 - Voodoo 3 - "No devices detected" > On Tue, Oct 01, 2002 at 11:13:17AM +1000, Ron Stodden wrote: > > Since retracted, plainly, as the fault at issue which they did > not want > > to hear about was finally tested for and accepted by Mandrake. > I am > > 100% vindicated. > > > > Go check your facts, sir. > > It's only been retracted if GC did it in private email. And GC wasn't > unhappy with you for reporting a bug. It was your comment about 9.0 > being a "waste of time." It was about your constant complaining. And > there is a difference here. You don't report bugs you complain about > them. > > All gc said was that it'd been fixed. At least I can't find a > retraction in the archives and I certainly don't remember seeing it. > This is probably what you are calling a retraction: > http://marc.theaimsgroup.com/?l=mandrake-cooker&m=103312525009634&w=2 > > > Off-target, once more, sir. It is clearly, plainly, a > development > > issue. I am not aware that you had or have the authority to > tell > > anyone anything. Are you the moderator? I thought Mandrake > Cooker > > was not a moderated mailing list. > > Put it away, Ben <G>. > > You're complaining to the wrong place about this issue. It's > clearly a > bug in XFree86 4.2.1 with regard to detecting your soundcard as a > videodevice. > > Putting the BusID in the XFree86 by default is a "bad idea." Here's > why: > > BusID's on PCI are dependent upon the slot. Consider the following: > [root@dev breser]# XFree86 -scanpci > Probing for PCI devices (Bus:Device:Function) > > (0:0:0) unknown chip (DeviceId 0x0305) from VIA > (0:1:0) unknown chip (DeviceId 0x8305) from VIA > (0:7:0) VIA card using a VIA VT 82C686 MVP4 ISA Bridge > (0:7:1) VIA VT 82C586 MVP3 IDE Bridge > (0:7:2) unknown card (0x0925/0x1234) using a VIA VT 82C586 MVP3 USB > Controller > (0:7:3) unknown card (0x0925/0x1234) using a VIA VT 82C586 MVP3 USB > Controller > (0:7:4) VIA VT 8501 MVP4 ACPI Bridge > (0:7:5) unknown card (0x1462/0x3300) using a VIA VT 8501 MVP4 > MultiMedia(0:9:0) unknown card (0x1317/0x0574) using an unknown > chipset(0x1317/0x0985) > (1:0:0) ATI card using a ATI Rage 128 RF > > Now I take and move the Ethernet card (which is 0:9:0 above) from one > slot to another. > > [root@dev breser]# XFree86 -scanpci | more > Probing for PCI devices (Bus:Device:Function) > > (0:0:0) unknown chip (DeviceId 0x0305) from VIA > (0:1:0) unknown chip (DeviceId 0x8305) from VIA > (0:7:0) VIA card using a VIA VT 82C686 MVP4 ISA Bridge > (0:7:1) VIA VT 82C586 MVP3 IDE Bridge > (0:7:2) unknown card (0x0925/0x1234) using a VIA VT 82C586 MVP3 USB > Controller > (0:7:3) unknown card (0x0925/0x1234) using a VIA VT 82C586 MVP3 USB > Controller > (0:7:4) VIA VT 8501 MVP4 ACPI Bridge > (0:7:5) unknown card (0x1462/0x3300) using a VIA VT 8501 MVP4 > MultiMedia(0:12:0) unknown card (0x1317/0x0574) using an unknown > chipset(0x1317/0x0985) > (1:0:0) ATI card using a ATI Rage 128 RF > > Now it's on 12. > > An inexperienced user who might add some small piece of hardware > and end > up shuffling the exact order the cards were put in, or that moved the > card because of space constraints. Would suddenly find their XFree86 > configuration non-functional if you always put BusIDs in. Granted > thatfor AGP cards the bus id is currently guaranteed to be the > same. But in > the age of multiheaded systems, I really don't think assuming that > won'tchange is a safe bet. > > As a result BusIDs should only be put in when they are absolutely > necessary. E.G. multihead systems. The BusID is merely a > workaround to > your problem. The real problem is a bug in 4.2.1 which is improperly > identifying your hardware. > > -- > Ben Reser <[EMAIL PROTECTED]> > http://ben.reser.org > > Never take no as an answer from someone who isn't authorized to say > yes. >
