Vojtech Pavlik wrote:
> On Wed, Jan 31, 2001 at 08:52:58PM -0500, safemode wrote:
>
> > My KA7 can go over 160Mhz FSB
> > Yes i know about memory speed limitions ..that's why you are able to choose
> > HW clock - PCI so at those high speeds it's actually say 120Mhz - 33
> > keeping you below or near 100 and not well over the spec of the ram. Anyway i
> > dont go that high 110 is safe an doesn't cause any heat increase and gives me
> > 100Mhz more. nbench shows my performance about equal to t-bird 1ghz. at least in
> > memory and integer. The KA7 lets you increase the FSB without increasing the
> > PCI bus speed, so i dont have to worry about changing ide bus timings, PCI is
> > still at 33 - 34 not enough to hurt any cards.
>
> Ugh. What chips your KA7 has? As far as I know the KX133 chip (vt8731)
> can't do asynchronous PCI, allowing for 2x, 3x and 4x FSB/PCI divisors
> only. So I don't a way to have your FSB at 114 and your PCI at 34 with
> this chip.
Actually it can and it's a simple bios option. I'd show you but it's in the manual and
it's hard to scan stuff without a scanner. You can have asynchronous FSB up to
28Mhz so i can have 128Mhz FSB with 33Mhz PCI after that i have to use the
synchronous increase which changes PCI as i change the FSB value but the other value
gets added onto that asynchronously. It's really a standard feature of this board.
I'm not making it up and the proof is me not changing idebus at all and still working
after a day at full load and semi-constant usage and MANY compiles. also the bios
screen doesn't lie.
>
> > OK ok.. just forget i ever mentioned it .. It has nothing to do with anything
> > i've been talking about problem wise because i _JUST_ did it now ... It is the
> > cause of nothing because they all happened before i did anything to the speed.
> > This is a 2.4.x kernel problem. It has nothing to do with overclocking because at
> > the time i didn't. When i used 2.2.x it did not have any problems and i did not
> > overclock. As of now i have no problems with ide resets or dma timeouts (which
> > is what i said before), regardless of if i'm overclocking it now or not. It's
> > working great (better than great) without changing anyhing in 2.2.19-pre7.
> > heh. so everyone can stop flipping out over overclocking because i made sure
> > hardware settings were default failsafe even before deciding it was definitely a
> > kernel problem and i never had the settings over spec before the problem surfaced.
>
> Ok. So do you still have a working 2.2 setup and a non-working 2.4
> setup? Would you be able to send me the usual (lspci -vvxxx, dmesg,
> hdparm -t /dev/hd*, hdparm -i /dev/hd*, cat /proc/ide/via) data for both
> so that I can compare them?
>
> If I find any differences, I'll know what the bug is.
>
> --
> Vojtech Pavlik
> SuSE Labs
I cant get anything from 2.4 because I kind of dont want to re-format and re-install
debian again and lose my email and logs and config scripts. It's seriously that bad.
fsck would say it fixed everything .. I would reboot and immediately it would come up
with certain files having IO errors and then inode errors. Strangely though, this
didn't occur the very first time i booted with the kernel... it took about 3 days
until it happened, but after that it would happen all the time and even after
reboots. I even disabled DMA support for both and it still happened . So i really
doubt it has to do with the via specific driver for DMA support in the kernel (ie.
there is no /proc/ide/via). i'll look into finding some way of running 2.4 so that
it cant destroy my filesystems.
On Thu, 1 Feb 2001, safemode wrote:
> Vojtech Pavlik wrote:
>
> > Ugh. What chips your KA7 has? As far as I know the KX133 chip (vt8731)
> > can't do asynchronous PCI, allowing for 2x, 3x and 4x FSB/PCI divisors
> > only. So I don't a way to have your FSB at 114 and your PCI at 34 with
> > this chip.
>
> Actually it can and it's a simple bios option. I'd show you but it's in the manual and
> it's hard to scan stuff without a scanner. You can have asynchronous FSB up to
> 28Mhz so i can have 128Mhz FSB with 33Mhz PCI after that i have to use the
> synchronous increase which changes PCI as i change the FSB value but the other value
> gets added onto that asynchronously. It's really a standard feature of this board.
> I'm not making it up and the proof is me not changing idebus at all and still working
> after a day at full load and semi-constant usage and MANY compiles. also the bios
> screen doesn't lie.
Yeah, by bios does the same thing too on the Abit KT7(a). But you might not
want to run your PCI clock at 34 instead of 33. Two problems can occur. If you
don't specify idebus=34 on the kernel prompt, the IDE timings might eventually
get a DMA reset under 100% disk access. If you do say idebus=34, then you drop
your maximum throughput from 33 MB/s to 27MB/s.
I was curious and compiled a list of timings from Vojtech's formula for certain
idebus=xx MHz ratings (I _think_ the UDMA-66 timings are correct, maybe you can
check on these, Vojtech..)
Clock | Setup Active Recover Cycle UDMA | UDMA-33 UDMA-66 UDMA-100
21 | 1 2 1 3 0 | 28.0 56.0 84.0
22 | 1 2 1 3 0 | 29.3 58.6 88.0
23 | 1 2 1 3 0 | 30.6 61.2 92.0
24 | 1 2 1 3 0 | 32.0 64.0 96.0
25 | 1 2 1 3 0 | 33.3 66.6 100.0
26 | 1 2 2 4 0 | 26.0 52.0 78.0
27 | 1 2 2 4 0 | 27.0 54.0 81.0
28 | 1 2 2 4 0 | 28.0 56.0 84.0
29 | 1 3 1 4 0 | 29.0 58.0 87.0
30 | 1 3 1 4 0 | 30.0 60.0 90.0
31 | 1 3 1 4 0 | 31.0 62.0 93.0
32 | 1 3 1 4 0 | 32.0 64.0 96.0
33 | 1 3 1 4 0 | 33.0 66.0 99.0
34 | 1 3 2 5 0 | 27.2 54.4 81.6
35 | 1 3 2 5 0 | 28.0 56.0 84.0
36 | 1 3 2 5 0 | 28.8 57.6 86.4
37 | 1 3 2 5 0 | 29.6 59.2 88.8
38 | 1 3 2 5 0 | 30.4 60.8 91.2
39 | 1 3 2 5 0 | 31.2 62.4 93.6
40 | 1 3 2 5 0 | 32.0 64.0 96.0
41 | 2 3 2 5 0 | 32.8 65.6 98.4
42 | 2 4 2 6 0 | 28.0 56.0 84.0
43 | 2 4 2 6 0 | 28.6 57.2 86.0
44 | 2 4 2 6 1 | 29.3 58.6 88.0
45 | 2 4 2 6 1 | 30.0 60.0 90.0
46 | 2 4 2 6 1 | 30.6 61.2 92.0
47 | 2 4 2 6 1 | 31.3 62.6 94.0
48 | 2 4 2 6 1 | 32.0 64.0 96.0
49 | 2 4 2 6 1 | 32.6 65.2 98.0
50 | 2 4 2 6 1 | 33.3 66.6 100.0
51 | 2 4 3 7 1 | 29.1 58.2 87.4
52 | 2 4 3 7 1 | 29.7 59.4 89.1
53 | 2 4 3 7 1 | 30.2 60.4 90.8
54 | 2 4 3 7 1 | 30.8 61.6 92.5
55 | 2 4 3 7 1 | 31.4 62.8 94.2
56 | 2 5 3 8 1 | 28.0 56.0 84.0
57 | 2 5 3 8 1 | 28.5 57.0 85.5
58 | 2 5 3 8 1 | 29.0 58.0 87.0
59 | 2 5 3 8 1 | 29.5 59.0 88.5
60 | 2 5 3 8 1 | 30.0 60.0 90.0
Personally I like the 113 MHz FSB setting, which runs PCI at 37 and memory at
150 (133*1.13). It helps to have memory rated for 150. :) I've had a system
run at this rate for the past 4 months now and I've never had any problems.
Of course, your results may vary.
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [email protected]
On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote:
> Yeah, by bios does the same thing too on the Abit KT7(a).
Ok, I'll remember this. This is most likely the cause of the problems
many people had with the KT7 in the past.
> But you might not
> want to run your PCI clock at 34 instead of 33. Two problems can occur. If you
> don't specify idebus=34 on the kernel prompt, the IDE timings might eventually
> get a DMA reset under 100% disk access. If you do say idebus=34, then you drop
> your maximum throughput from 33 MB/s to 27MB/s.
>
> I was curious and compiled a list of timings from Vojtech's formula for certain
> idebus=xx MHz ratings (I _think_ the UDMA-66 timings are correct, maybe you can
> check on these, Vojtech..)
>
> Clock | Setup Active Recover Cycle UDMA | UDMA-33 UDMA-66 UDMA-100
> 21 | 1 2 1 3 0 | 28.0 56.0 84.0
> 22 | 1 2 1 3 0 | 29.3 58.6 88.0
> 23 | 1 2 1 3 0 | 30.6 61.2 92.0
[snip]
> 31 | 1 3 1 4 0 | 31.0 62.0 93.0
> 32 | 1 3 1 4 0 | 32.0 64.0 96.0
> 33 | 1 3 1 4 0 | 33.0 66.0 99.0
> 34 | 1 3 2 5 0 | 27.2 54.4 81.6
[snip]
> 59 | 2 5 3 8 1 | 29.5 59.0 88.5
> 60 | 2 5 3 8 1 | 30.0 60.0 90.0
Well, the table depends on what type of southbridge chip are you using -
if it's 586b or other UDMA33 chip, 586b/686a or other UDMA66 chip or the
UDMA100 capable 686b.
The U33 chips do UDMA timing in PCICLK (T = 30ns @ 33MHz) increments, U66 in
PCICLK*2 (T = 15ns @ 33 MHz) increments, and for U100 it's assumed that
there is an external 100MHz clock fed to the chip, so that the UDMA timing is
in T = 10ns increments independent of the PCICLK. I'm not 100% sure about
the last, it might be just PCICLK*3 (T = 10ns @ 33 MHz). An experiment needs
to be carried out to verify this.
So, s ahort excerpt of the table will look like:
Chip | Clock | Setup Active Recover | T | UDMA-33 UDMA-66 UDMA-100
586b | 25 | 1 2 1 | 40 | 2T=25.0 xxxxxxx xxxxxxxx
686a | 25 | 1 2 1 | 20 | 3T=33.3 2T=50.0 xxxxxxxx
686b | 25 | 1 2 1 | 10 | 6T=33.3 4T=66.6 2T=100.0
Chip | Clock | Setup Active Recover | T | UDMA-33 UDMA-66 UDMA-100
586b | 33 | 1 2 1 | 30 | 2T=33.3 xxxxxxx xxxxxxxx
686a | 33 | 1 2 1 | 15 | 4T=33.3 2T=66.6 xxxxxxxx
686b | 33 | 1 2 1 | 10 | 6T=33.3 4T=66.6 2T=100.0
... that is, if the 686b indeed has a 100MHz clock source. If not, then
in the case of 25 MHz, T would be 13.3ns. If you can verify this, it'd
be nice.
--
Vojtech Pavlik
SuSE Labs
On Thu, 1 Feb 2001, Vojtech Pavlik wrote:
> On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote:
>
> > Yeah, by bios does the same thing too on the Abit KT7(a).
>
> Ok, I'll remember this. This is most likely the cause of the problems
> many people had with the KT7 in the past.
What cause are you referring to? As far as I know, there are two options to
increasing the FSB clock.. one increases both FSB+PCICLK, the other just
increases FSB. If you increase the FSB only, it should keep PCICLK at a solid
33. (But I could be wrong, I've never tested that. I can tomorrow though.)
> The U33 chips do UDMA timing in PCICLK (T = 30ns @ 33MHz) increments, U66 in
> PCICLK*2 (T = 15ns @ 33 MHz) increments, and for U100 it's assumed that
> there is an external 100MHz clock fed to the chip, so that the UDMA timing is
> in T = 10ns increments independent of the PCICLK. I'm not 100% sure about
> the last, it might be just PCICLK*3 (T = 10ns @ 33 MHz). An experiment needs
> to be carried out to verify this.
I don't have a KT7A personally, I only have a KT7. Can anyone else with a KT7A
verify this? By verify, I take it you mean to use idebus=33 and overclock
PCICLK? :) At least that would determine if UDMA100 is based on PCI or an
external 100MHz source.
Regards,
Byron
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [email protected]
On Thu, Feb 01, 2001 at 01:20:00PM -0500, Byron Stanoszek wrote:
> > On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote:
> >
> > > Yeah, by bios does the same thing too on the Abit KT7(a).
> >
> > Ok, I'll remember this. This is most likely the cause of the problems
> > many people had with the KT7 in the past.
>
> What cause are you referring to? As far as I know, there are two options to
> increasing the FSB clock.. one increases both FSB+PCICLK, the other just
> increases FSB. If you increase the FSB only, it should keep PCICLK at a solid
> 33. (But I could be wrong, I've never tested that. I can tomorrow though.)
I mean that people can alter the PCI clock on these boards and that 33
doesn't to be always exactly 33 due to rounding errors if used with a
FSB other than 66 or 100 or 133.
Could it be that the PCI bus is not asynchronous, but only
pseudo-synchronous, allowing for divisors of 5, 4.5, 4, 3.5, 3, 2.5, 2?
> > The U33 chips do UDMA timing in PCICLK (T = 30ns @ 33MHz) increments, U66 in
> > PCICLK*2 (T = 15ns @ 33 MHz) increments, and for U100 it's assumed that
> > there is an external 100MHz clock fed to the chip, so that the UDMA timing is
> > in T = 10ns increments independent of the PCICLK. I'm not 100% sure about
> > the last, it might be just PCICLK*3 (T = 10ns @ 33 MHz). An experiment needs
> > to be carried out to verify this.
>
> I don't have a KT7A personally, I only have a KT7. Can anyone else with a KT7A
> verify this? By verify, I take it you mean to use idebus=33 and overclock
> PCICLK? :) At least that would determine if UDMA100 is based on PCI or an
> external 100MHz source.
Actually he should use the correct idebus= so that the Active/Recover
timings are correct. If KT7A doesn't work with UDMA at high PCI clocks
*even when* idebus= is correct would mean that the UDMA timing is in
1/(PCICLK*3) units instead of units of 10ns.
Anyone help us?
--
Vojtech Pavlik
SuSE Labs
Vojtech Pavlik wrote:
> On Thu, Feb 01, 2001 at 01:20:00PM -0500, Byron Stanoszek wrote:
>
> > > On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote:
> > >
> > > > Yeah, by bios does the same thing too on the Abit KT7(a).
> > >
> > > Ok, I'll remember this. This is most likely the cause of the problems
> > > many people had with the KT7 in the past.
> >
> > What cause are you referring to? As far as I know, there are two options to
> > increasing the FSB clock.. one increases both FSB+PCICLK, the other just
> > increases FSB. If you increase the FSB only, it should keep PCICLK at a solid
> > 33. (But I could be wrong, I've never tested that. I can tomorrow though.)
>
> I mean that people can alter the PCI clock on these boards and that 33
> doesn't to be always exactly 33 due to rounding errors if used with a
> FSB other than 66 or 100 or 133.
>
> Could it be that the PCI bus is not asynchronous, but only
> pseudo-synchronous, allowing for divisors of 5, 4.5, 4, 3.5, 3, 2.5, 2?
>
> > > The U33 chips do UDMA timing in PCICLK (T = 30ns @ 33MHz) increments, U66 in
> > > PCICLK*2 (T = 15ns @ 33 MHz) increments, and for U100 it's assumed that
> > > there is an external 100MHz clock fed to the chip, so that the UDMA timing is
> > > in T = 10ns increments independent of the PCICLK. I'm not 100% sure about
> > > the last, it might be just PCICLK*3 (T = 10ns @ 33 MHz). An experiment needs
> > > to be carried out to verify this.
> >
> > I don't have a KT7A personally, I only have a KT7. Can anyone else with a KT7A
> > verify this? By verify, I take it you mean to use idebus=33 and overclock
> > PCICLK? :) At least that would determine if UDMA100 is based on PCI or an
> > external 100MHz source.
>
> Actually he should use the correct idebus= so that the Active/Recover
> timings are correct. If KT7A doesn't work with UDMA at high PCI clocks
> *even when* idebus= is correct would mean that the UDMA timing is in
> 1/(PCICLK*3) units instead of units of 10ns.
>
> Anyone help us?
>
> --
> Vojtech Pavlik
> SuSE Labs
I for one dont use the KT7 motherboards but i know from experience that
increasing the FSB only effects ram speed ( at least negatively anyway) i have
100Mhz ram and 133Mhz ram so once i'm at 114Mhz the 100Mhz ram cant handle too much
more .. so 114Mhz is what i stay at. My PCI clock is not changed at all and so
far (for the last couple days) the hdd's on my idebus have not had any problems what
so ever. Sorry but i've only got UDMA66 drives and idebus is whatever the 2.2.x
kernel defaults to. I'm guessing any sort of corruption caused by 2.4.x had
something to do with that dirty page writes mail that was sent to the list a while
ago and was probably fixed but never made it to the changelog. I'll stick to 2.2
until 2.5 though just in case. What would be interesting is figuring out why the
kernel can't recover somehow from infinite ide irq reset loops which are usually
brought on by dma timeouts. That would at least somewhat usefull for when they
actually happen (I saw them numerous times in 2.4.x but not since going back to
2.2.x).
On Thu, 1 Feb 2001 19:06:53 +0100, Vojtech Pavlik wrote:
>On Thu, Feb 01, 2001 at 11:46:08AM -0500, Byron Stanoszek wrote:
>
>> Yeah, by bios does the same thing too on the Abit KT7(a).
>
>Ok, I'll remember this. This is most likely the cause of the problems
>many people had with the KT7 in the past.
>
I've had (I now have 2.4.1 with dma off) the problems with a KT7,
although according to the BIOS its set to 100FSB/33PCI and the option
to tweak the clock further is set to zero
One further thought though - 1/3 of 100 is actually 33.3333Mhz. What
if the flexibility in the motherboard is actually causing the bus to
be exactly 1/3 of 100
Interpolating according to Byron Stanoszek's table for UDMA-33 (where
I have the problem) this could have a not insignificant effect on the
paramter given the chip.
Alan
[email protected]
http://www.chandler.u-net.com