Date: Tue, 1 Dec 1998 11:59:46 -0800 (PST) From: Bill Paul <wpaul@FreeBSD.ORG> To: phk@critter.freebsd.dk (Poul-Henning Kamp) Cc: mike@smith.net.au, peter@netplex.com.au, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_clock.c Message-ID: <199812011959.LAA23472@freefall.freebsd.org> In-Reply-To: <15187.912499131@critter.freebsd.dk> from Poul-Henning Kamp at "Dec 1, 98 08:58:51 am"
next in thread | previous in thread | raw e-mail | index | archive | help
>
> >> Because I want the system to be bloddy unstable, weird and generally
> >> misbehaving, so that people actively have to acknowledge that it
> >> is broken in some way (hw and/or sw).
> >
> >This is totally screwed. Are you familiar with the expression "fail
> >safe"? We should *default* to the less efficient but functional
> >method, and make the unreliable method _optional_.
>
> Mike, I am not going to paste over this problem, it should be solved
> so that interrupt delivery on these systems works, not by pasting
> over the fact that they don't.
>
> Think about it, everything in the bloddy system will suffer under this
> bogosity, serial ports ? sorry but you're toast. Protocol timeouts ?
> well, eventually. real-time responses ? HA!
>
> We fully agree that we need to figure out the problem, absolutely, but
> if I paste over it in the timecounters, we will never hear about these
> systems, until something else is even more hosed.
>
> We found out why it happens on Wolfgangs system (lpip) and Bill
> Paul was a hosed X11 server/graphics card combination I think. I
> don't recall that we have even heard a response from you yet with
> some diagnostics in it, have we ?
I have since learned the cause of the problem with the 3DLabs X server,
though I don't understand exactly what the problem is. Luckily for us,
XFree86 3.3.3 just came out, and it has the source code for the 3DLabs
server. The bug responsible for the system slowdown has since been found.
Somebody made a mind-o in:
xc/programs/Xserver/hw/xfree86/accel/glint/glint_regs.h
There's a macro there which looks like this:
#define GLINT_SLOW_READ_REG(r) \
( outb(80,0),*(unsigned int *)((char*)GLINTMMIOBase+r))
This is wrong. It should be:
#define GLINT_SLOW_READ_REG(r) \
( outb(0x80,0),*(unsigned int *)((char*)GLINTMMIOBase+r))
Notice the difference: the wrong macro does an outb to port 80 instead of
0x80. However, I don't know what's supposed to be at I/O port 80 (0x50).
Whatever it is, this is definitely the cause of the problem: I just built
a complete XFree86 3.3.3 kit with this bug patched and the 3DLabs server
works perfectly now.
Any idea what this I/O port does and why it would cause the system to
slow down like it did?
-Bill
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812011959.LAA23472>