From owner-freebsd-hackers Sun Nov 21 23:22: 7 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from dingo.cdrom.com (castles523.castles.com [208.214.165.87]) by hub.freebsd.org (Postfix) with ESMTP id DF75E14FAC for ; Sun, 21 Nov 1999 23:22:03 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.3/8.8.8) with ESMTP id XAA06555; Sun, 21 Nov 1999 23:12:29 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199911220712.XAA06555@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Dennis Cc: Mike Smith , hackers@freebsd.org Subject: Re: PCI DMA lockups in 3.2 (3.3 maybe?) In-reply-to: Your message of "Mon, 22 Nov 1999 08:47:28 EST." <199911220127.UAA28430@etinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Nov 1999 23:12:29 -0800 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> I'll test this in 3.3 shortly...has anything been done in this area? It >>>>> seems to happen on passive backplace systems (although its more likely the >>>>> chipsets used on SBCs)...my acer MB doesnt lock up with the same test. This >>>>> problem has been duplicated on more than 1 system with completely different >>>>> hardware. >>>>> >>>>> Any ideas? >>>> >>>>Nope. You haven't given anything like enough information to even guess >>>>at the nature of the problem. >>> >>> And what additional info, short of putting a scope on the bus, may I >>> provide you? >> >>Anything that might help locating the nature of the "lockup". A scope >>on the bus would be helpful, sure. Some idea where in the kernel the >>CPU was executing would be good. The values of cpl and ipending are >>always informative. >> >>Basically though, you're saying "I have a problem with an old version of >>freebsd on some sorts of hardware. Is it fixed?". There's no possible >>way for anyone else to answer such a totally vague question. > > Its a late 3.2-STABLE. so its not that old. Surely someone knows if > something in this area was fixed or not? Since you haven't actually identified the nature of the problem, how can we know whether any changes might have affected it? > Since its a DMA lockup, how would you suggest that the informatoin about > what instruction was executing be obtained? How do you know it's a DMA lockup? What other information are you hiding from us? Since this seems to be a problem fairly unique to your hardware and your particular configurations, it's beholden upon you to perform your own exploration. > The nightmare of instability of 3.x continues whilst the braintrust flogs > away at 4.x. Its really a damn shame. And why is 3.x so much slower than > 2.2.8? Will 4.0 be slower yet? This is basically all hyperbole; unsubstantiated, irrational and unconstructive. You know, you'd get much better results if you stuck to the facts. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message