G'day Alan, all,
In November, I assembled a new machine using a Soyo Dragon+ mb with a
Pinnacle PCTV/Pro card as the only add-in board (I have an ATI 7500 in the
AGP slot). Very quickly I learned that any heavy disk activity (from two
UDMA100 drives) during TV card use would lock the system tight. As long
as I didn't use the TV card, the system was completely solid -- under
heavy disk, sound, net usage, etc. I tried moving the card around,
playing with BIOS, upgrading BIOS, with no success. I dug around in
quirks.c and put a serious dent in google's usage reports trying to find
answers. About the time I was concluding that I had a defective mb, a
friend decided to install Linux on his KT266 system also. After the
install, we popped a PCTV (non-PRO minus FM radio) into it and ended up
duplicating my machines's crashing behaviour.
About a month ago, after giving up and either avoiding TV card use (which
given the state of US TV isn't a completely bad thing :-), or resigning
myself to not doing serious work if I had the TV card on, I stumbled
across Serguei Miridonov's site (http://www.cicese.mx/~mirsev/Linux/VIA/).
His small module changes PCI config register 0x75 from 0x01 to 0x07 and
clears all the bits on 0x76 (originally set to 0x10 on my mb). The result
has been perfect stability for both boards with TV cards and as much disk
and other I/O as bonnie and friends could generate.
Alan, given that you are one of gurus on VIA chipset quirks, what am I
trading off on this? Is this an isolated quirk, or have I stumbled across
something mildly useful to others?
Any insights would be appreciated.
Many thanks,
--
-Jonathan <[email protected]>
On 19 June 2002 02:13, Jonathan A. Davis wrote:
> G'day Alan, all,
>
> In November, I assembled a new machine using a Soyo Dragon+ mb with a
> Pinnacle PCTV/Pro card as the only add-in board (I have an ATI 7500 in the
> AGP slot). Very quickly I learned that any heavy disk activity (from two
> UDMA100 drives) during TV card use would lock the system tight. As long
> as I didn't use the TV card, the system was completely solid -- under
> heavy disk, sound, net usage, etc. I tried moving the card around,
> playing with BIOS, upgrading BIOS, with no success. I dug around in
> quirks.c and put a serious dent in google's usage reports trying to find
> answers. About the time I was concluding that I had a defective mb, a
> friend decided to install Linux on his KT266 system also. After the
> install, we popped a PCTV (non-PRO minus FM radio) into it and ended up
> duplicating my machines's crashing behaviour.
>
> About a month ago, after giving up and either avoiding TV card use (which
> given the state of US TV isn't a completely bad thing :-), or resigning
> myself to not doing serious work if I had the TV card on, I stumbled
> across Serguei Miridonov's site (http://www.cicese.mx/~mirsev/Linux/VIA/).
> His small module changes PCI config register 0x75 from 0x01 to 0x07 and
> clears all the bits on 0x76 (originally set to 0x10 on my mb). The result
> has been perfect stability for both boards with TV cards and as much disk
> and other I/O as bonnie and friends could generate.
[75:7]=Arbitration Mode 0=REQ-based 1=Frame-based
(75:6)=CPU Latency Timer read only
(75:5)=(same as above)
(75:4)=(same as above)
[75:3]=(Reserved)
[75:2]=PCI Master Bus Time-Out 000=Disable
[75:1]=001=1x32 PCICLKs 010=2x32 PCICLKs
[75:0]=011=3x32 PCICLKs ... 111=7x32 PCICLKs
You increased busmaster timeout sevenfold here.
[76:7]=I/O Port 22 Enable
[76:6]=(Reserved)
[76:5]=Master Priority Rotation 0x=every PCI master grant
[76:4]=10=after every 2 PCI 11=after every 3 PCI
[76:3]=REQn# to REQ4# Mapping 00=REQ4# 01=REQ0#
[76:2]=10=REQ1# 11=REQ2#
[76:1]=(Reserved)
[76:0]=REQ4# Is High Priority 0=disable 1=enable
Heh... doc says 0x00 and 0x10 are the same for reg 0x76...
did you test with 0x76 unchanged?
I have a PDF also, need to reboot into WinNT to look at it...
KDE's PDF viewer can't grok it.
--
vda
>
> G'day Alan, all,
>
> In November, I assembled a new machine using a Soyo Dragon+ mb with a
> Pinnacle PCTV/Pro card as the only add-in board (I have an ATI 7500 in the
> AGP slot). Very quickly I learned that any heavy disk activity (from two
> UDMA100 drives) during TV card use would lock the system tight. As long
> as I didn't use the TV card, the system was completely solid -- under
> heavy disk, sound, net usage, etc. I tried moving the card around,
> playing with BIOS, upgrading BIOS, with no success. I dug around in
> quirks.c and put a serious dent in google's usage reports trying to find
> answers. About the time I was concluding that I had a defective mb, a
> friend decided to install Linux on his KT266 system also. After the
> install, we popped a PCTV (non-PRO minus FM radio) into it and ended up
> duplicating my machines's crashing behaviour.
>
> About a month ago, after giving up and either avoiding TV card use (which
> given the state of US TV isn't a completely bad thing :-), or resigning
> myself to not doing serious work if I had the TV card on, I stumbled
> across Serguei Miridonov's site (http://www.cicese.mx/~mirsev/Linux/VIA/).
> His small module changes PCI config register 0x75 from 0x01 to 0x07 and
> clears all the bits on 0x76 (originally set to 0x10 on my mb). The result
> has been perfect stability for both boards with TV cards and as much disk
> and other I/O as bonnie and friends could generate.
>
> Alan, given that you are one of gurus on VIA chipset quirks, what am I
> trading off on this? Is this an isolated quirk, or have I stumbled across
> something mildly useful to others?
>
> Any insights would be appreciated.
>
> Many thanks,
>
I have an epox kta3 aka VIA kt133a chipset which has the odd habit to freeze after 10-30 minutes in linux or
winxp even when not using the tv card. If I perfom a warm reset after post the system is perfectly stable.
Except the cdwriter I have scsi only system.
Is there any relation to this problem?
I also read 2 weeks ago that VIA confirmed that they didn't have some intel PCI extentions that some pci card
makers assume like the ceative SBlive which caused some known problems.
Although I am pretty used to the warm reset before bot-up I rather see the problem fixed, I'll have a go with this
"fix".
Tommy
> --
>
> -Jonathan <[email protected]>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Wed, 19 Jun 2002, Denis Vlasenko wrote:
>
> Heh... doc says 0x00 and 0x10 are the same for reg 0x76...
> did you test with 0x76 unchanged?
>
I don't know what 0x76 does exactly, but I can say there is a very real
difference between 0x00 and 0x10 on my system. Leaving the register
unchanged (0x10) results in system hangs. They are a little harder to
provoke than running without any changes, but they could still be
triggered under severe disk load. Clearing that register and the same
tests run to completion (I've done about 5 iterations). Perhaps this may
be unique to specific board designs or chip steppings. Clearing 0x76 and
leaving 0x75 with it's initial value results in hangs that trigger just
about as quickly (subjectively) as leaving both registers in their
original state.
Kinda reminds me of the original Tandy 1000 computers. 99.99% compatible
which left you with a 0.01% that would drive you batty. ;-)
Oh, another data point. Back when I first put this machine together and
before I discovered ALSA drivers that would actually work properly with
the onboard CMI chip, I dropped an Ensoniq 1371 (SB) card in. Although
the machine didn't crash, the sound was horrible with clicks, pops, etc.
-- even when no actual sounds were being generated. As that was about an
hour before the discovery of ALSA and I had heard that some of the
Ensoniq-based cards had PCI issues -- I didn't put much effort into
diagnosing it.
-Jonathan <[email protected]>
On 20 June 2002 01:46, Jonathan A. Davis wrote:
> On Wed, 19 Jun 2002, Denis Vlasenko wrote:
> > Heh... doc says 0x00 and 0x10 are the same for reg 0x76...
> > did you test with 0x76 unchanged?
>
> I don't know what 0x76 does exactly, but I can say there is a very real
> difference between 0x00 and 0x10 on my system. Leaving the register
> unchanged (0x10) results in system hangs. They are a little harder to
> provoke than running without any changes, but they could still be
> triggered under severe disk load. Clearing that register and the same
> tests run to completion (I've done about 5 iterations). Perhaps this may
> be unique to specific board designs or chip steppings. Clearing 0x76 and
> leaving 0x75 with it's initial value results in hangs that trigger just
> about as quickly (subjectively) as leaving both registers in their
> original state.
Do you plan to submit a patch?
I'm heavily overloaded at the moment by totally non-Linux work right now
(Win NT / Oracle madness. In their world I need several CDs with faulty
installer just for client-side TCP/IP protocol stack. I feel very bad.
Shoot me someone!).
But if you really need some help, mail me.
--
vda