Re: trident noise
On Aug 21, 2002 at 12:11 +0200, Karl Hammar wrote: > > I have the same motherboard with their fanless 533MHz processor. > The system has the problem that switching to text console and back > (c-a-f1, a-f9) makes the screen dark (as if it was off), and after > a little fiddling trying different options, look as if the horizontal > lines are not properly synced and the screen is darker. I had a similar problem on my laptop (Acer 340T using Trident CyberBlade) with XFree86 4.1.0. Switching back to X from console, or waking up from suspend, caused the screen to "bloom", which I believe is a symptom of improper sync timings. The problem went away when I upgraded to 4.2.0. -- Thatcher Ulrich http://tulrich.com
Re: trident noise
> > for inexpensive hardware. However, as soon as X is loaded and a window > > is perturbed, the sound card goes insane. > > > Now, if I remember my history, PCI video card manufacturers discovered > > at some point that they could lengthen the little bars produced by > > WinBench by a few percent if they wrote blindly to the instruction > > queue on the video card. > > Exactly. > > > I can't imagine that Branden had anything to do with this, so is > > probably an upstream problem. > > Yep. Try adding ``Option "PciRetry" "true"'' to your Device section. > Upstream is trying to be benchmark- rather than user-friendly. > > (To expand on that: the XFree86 4 client scheduler specially optimises > the case of a single client. That only happens when benchmarking.) > > Juliusz ... I have the same motherboard with their fanless 533MHz processor. The system has the problem that switching to text console and back (c-a-f1, a-f9) makes the screen dark (as if it was off), and after a little fiddling trying different options, look as if the horizontal lines are not properly synced and the screen is darker. Blindly trying things: Lowering HorizSync or VertRefresh or setting or clearing NoPciBurst, PciRetry, CyberShadow, or CyberStretch gives me the not synced look. Setting NoAccel, NoMMIO, ShadowFB, or SWcursor to "true" gives you a dark screen (the monitor behaves as if the computer is powered off). Do anyone have any suggestions. I use this as an potential netbooting, no noise, low cost xterminal. Regards, /Karl --- Karl HammarAspö Data [EMAIL PROTECTED] Lilla Aspö 2340 +46 173 140 57Networks S-742 94 Östhammar +46 18 26 09 00 Computers Sweden +46 10 270 26 67 Consulting ---
Re: trident noise
On Thu, Aug 15, 2002 at 05:27:53PM +0200, Juliusz Chroboczek wrote: > Yep. Try adding ``Option "PciRetry" "true"'' to your Device section. > Upstream is trying to be benchmark- rather than user-friendly. > > (To expand on that: the XFree86 4 client scheduler specially optimises > the case of a single client. That only happens when benchmarking.) Hmph. Well, as a package maintainer for a distribution, I care a lot more about users having machines that don't lock up than I do about benchmarks. Do you happen to know where I can reverse this default in the X server? Hmm, actually, looking at the sources, I don't see anyplace where this option defaults to "on" on a server-wide basis. Only specific drivers appear to be cognizant of this option and, typically, they don't even consistently call it by the same name internally: drivers/siliconmotion/smi_driver.c: pSmi->NoPCIRetry = FALSE; drivers/trident/trident_driver.c: pTrident->UsePCIRetry = FALSE; /* Not Supported */ So which upstream is the problem? The Trident driver author? -- G. Branden Robinson| Psychology is really biology. Debian GNU/Linux | Biology is really chemistry. [EMAIL PROTECTED] | Chemistry is really physics. http://people.debian.org/~branden/ | Physics is really math. pgpUZfHZuGHl6.pgp Description: PGP signature
Re: trident noise
Awesome! That nailed the problem. I didn't realize what I was looking at when I saw this option in the man page. When I first saw this problem, it was a "patch the source or bother your vendor problem." Thanks to Sven too. Russell Juliusz Chroboczek <[EMAIL PROTECTED]> writes: > > for inexpensive hardware. However, as soon as X is loaded and a window > > is perturbed, the sound card goes insane. > > > Now, if I remember my history, PCI video card manufacturers discovered > > at some point that they could lengthen the little bars produced by > > WinBench by a few percent if they wrote blindly to the instruction > > queue on the video card. > > Exactly. > > > I can't imagine that Branden had anything to do with this, so is > > probably an upstream problem. > > Yep. Try adding ``Option "PciRetry" "true"'' to your Device section. > Upstream is trying to be benchmark- rather than user-friendly. > > (To expand on that: the XFree86 4 client scheduler specially optimises > the case of a single client. That only happens when benchmarking.) > > Juliusz
Re: trident noise
> for inexpensive hardware. However, as soon as X is loaded and a window > is perturbed, the sound card goes insane. > Now, if I remember my history, PCI video card manufacturers discovered > at some point that they could lengthen the little bars produced by > WinBench by a few percent if they wrote blindly to the instruction > queue on the video card. Exactly. > I can't imagine that Branden had anything to do with this, so is > probably an upstream problem. Yep. Try adding ``Option "PciRetry" "true"'' to your Device section. Upstream is trying to be benchmark- rather than user-friendly. (To expand on that: the XFree86 4 client scheduler specially optimises the case of a single client. That only happens when benchmarking.) Juliusz
Re: trident noise
That sounds like the problem (more or less), but I don't know how it could have been turned on by default. I'll give it a try. Russell Sven LUTHER <[EMAIL PROTECTED]> writes: > On Tue, Aug 13, 2002 at 04:01:36PM -0400, Russell Neches wrote: > > > > Hey there -- > > > > I've recently been tinkering with VIA's EPIA motherboard and the > > various gizmos integrated into VIA's "super southbridge" chip. > > Basically everything is crammed into this chip: > > > > 00:00.0 Host bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia] (rev > > 05) > > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia AGP] > > 00:11.0 ISA bridge: VIA Technologies, Inc. VT8231 [PCI-to-ISA Bridge] (rev > > 10) > > 00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) > > 00:11.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1e) > > 00:11.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1e) > > 00:11.4 Bridge: VIA Technologies, Inc. VT8235 Power Management (rev 10) > > 00:11.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio > > Controller (rev 40) > > 00:12.0 Ethernet controller: VIA Technologies, Inc. Ethernet Controller > > (rev 51) > > 00:13:0 Kitchen sink: VIA Technologies, Inc. Sink (rev 08) Faucet (rev 11b) > > 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev > > 6a) > > > > (all right, 00:13 is fictional) > > > > The problem I've been having is something I've not seen much since AGP > > came around - the sound card chirps and skips when you move a window > > around. I've tried everything I can think of to reproduce the problem > > in other ways, but I'm pretty confidant that I've isolated it to X. > > Playing with DMA mode on the disk, unloading the network driver, > > blasting the CPU to induce latency and all permutations of such abuse > > fail to cause the sound card to skip. In fact, it sounds pretty good > > for inexpensive hardware. However, as soon as X is loaded and a window > > is perturbed, the sound card goes insane. > > > > Now, if I remember my history, PCI video card manufacturers discovered > > at some point that they could lengthen the little bars produced by > > WinBench by a few percent if they wrote blindly to the instruction > > queue on the video card. This didn't cause trouble for most PCI > > devices, but it caused that obnoxious popping and squeaking from sound > > cards. The PCI bus would lock up for a few tens of audio cycles - > > insignificant for filesystem performance, but you will definitely hear > > (and hate) it. The only way to fix it was to put the code that checks > > the video instruction queue back into the video driver. > > I am not sure, but what you describe could be the usage of the PCI > disconnect feature, in which the video card would disconnect from the > bus until there is space in the instruction queue, while the processor > keeps resending the data until there is space in the fifo, thus eating > all the bus bandwith. > > I don't know the trident driver, but from the manpage, maybe you could > unset the following option : > >Option "PciRetry" "boolean" > Enable or disable PCI retries. Default: off. > > > You see, it seems to default to off, but may get enabled in the config > file, please check. > > Friendly, > > Sven Luther > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: trident noise
On Tue, Aug 13, 2002 at 04:01:36PM -0400, Russell Neches wrote: > > Hey there -- > > I've recently been tinkering with VIA's EPIA motherboard and the > various gizmos integrated into VIA's "super southbridge" chip. > Basically everything is crammed into this chip: > > 00:00.0 Host bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia] (rev 05) > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia AGP] > 00:11.0 ISA bridge: VIA Technologies, Inc. VT8231 [PCI-to-ISA Bridge] (rev 10) > 00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) > 00:11.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1e) > 00:11.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 1e) > 00:11.4 Bridge: VIA Technologies, Inc. VT8235 Power Management (rev 10) > 00:11.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio > Controller (rev 40) > 00:12.0 Ethernet controller: VIA Technologies, Inc. Ethernet Controller (rev > 51) > 00:13:0 Kitchen sink: VIA Technologies, Inc. Sink (rev 08) Faucet (rev 11b) > 01:00.0 VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 6a) > > (all right, 00:13 is fictional) > > The problem I've been having is something I've not seen much since AGP > came around - the sound card chirps and skips when you move a window > around. I've tried everything I can think of to reproduce the problem > in other ways, but I'm pretty confidant that I've isolated it to X. > Playing with DMA mode on the disk, unloading the network driver, > blasting the CPU to induce latency and all permutations of such abuse > fail to cause the sound card to skip. In fact, it sounds pretty good > for inexpensive hardware. However, as soon as X is loaded and a window > is perturbed, the sound card goes insane. > > Now, if I remember my history, PCI video card manufacturers discovered > at some point that they could lengthen the little bars produced by > WinBench by a few percent if they wrote blindly to the instruction > queue on the video card. This didn't cause trouble for most PCI > devices, but it caused that obnoxious popping and squeaking from sound > cards. The PCI bus would lock up for a few tens of audio cycles - > insignificant for filesystem performance, but you will definitely hear > (and hate) it. The only way to fix it was to put the code that checks > the video instruction queue back into the video driver. I am not sure, but what you describe could be the usage of the PCI disconnect feature, in which the video card would disconnect from the bus until there is space in the instruction queue, while the processor keeps resending the data until there is space in the fifo, thus eating all the bus bandwith. I don't know the trident driver, but from the manpage, maybe you could unset the following option : Option "PciRetry" "boolean" Enable or disable PCI retries. Default: off. You see, it seems to default to off, but may get enabled in the config file, please check. Friendly, Sven Luther
