Date: Sat, 2 May 1998 14:30:01 -0700 (PDT) From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: freebsd-bugs@FreeBSD.ORG Subject: Re: i386/5398 Message-ID: <199805022130.OAA19767@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR i386/5398; it has been noted by GNATS. From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Matthew Dillon <dillon@backplane.com> Cc: John-Mark Gurney <gurney_j@efn.org>, freebsd-gnats-submit@FreeBSD.ORG Subject: Re: i386/5398 Date: Sat, 02 May 1998 23:27:25 +0200 In message <199805021640.JAA00443@apollo.backplane.com>, Matthew Dillon writes: >:> cpu out of suds? This is a pentium pro 200. More likely, there is a >:> serious interrupt disablement latency somewhere in the kernel. >: >:What graphics card is this ? Is the blt done in HW when you move the >:window or by the CPU over the PCI bus ? > > At the time the bug report was submitted, it was a matrox mystique > running with the latest XFree86 (so probably some hardware blit). > > But it doesn't matter if the blit is done in software or not, frankly, > because interrupts had better be enabled at the time the X server does > a software blit (since it's a user mode process), and a hardware > blit in the matrox shouldn't stall a pci write to the board > for more then a few microseconds anyway before the pentium can unstall > and take the serial interrupt. Any description making such blatant use of the word "should" about PC hardware in a FreeBSD PR is reason enough to summarily close it. Both Bruce and I seem to lean to bus and/or cpu contention as the explanation of your problem. You havn't even bothered to tell us which interrupt the serial port was on, which chipset you have, what graphics card, if it had irq9 enables, which diskcontroller, if you were swapping (well, you did mention Netscape, so I guess you do) but you get the drift... Until you have evidence of something else being the cause, the PR remains closed. Please take a detailed look at the Intel SMP document, which spends a good deal of text on how interrupts work in PC's, then next look at the databook for a modern chipset, and see how long and non- predictable the interrupt-chain is. Then tell "should", "should", "should" again. I can tell you from personal research that busmatering on PCI is an extreemely evil thing to do to your interrupt latency. (See this page for an example: http://phk.freebsd.dk/rover.html) PC hardware sucks, but it is cheap... :-/ -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805022130.OAA19767>