Fw: VT82C686A corruption with 2.4.x
oops, I forgot to send this to linux-kernel as well... - Original Message - From: "Nicholas Knight" <[EMAIL PROTECTED]> To: "David D.W. Downey" <[EMAIL PROTECTED]> Sent: Thursday, February 01, 2001 5:24 AM Subject: Re: VT82C686A corruption with 2.4.x > - Original Message - > From: "David D.W. Downey" <[EMAIL PROTECTED]> > To: "David Riley" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Thursday, February 01, 2001 4:51 AM > Subject: Re: VT82C686A corruption with 2.4.x > > > > Yeah, I'm seriously beginning to think it's a board specific issue. If I > > drop the RAM count down to 768MB I get far less drops in app deaths > > <> > > >Right now I've got the full 1GB in there. What I'm seeing now is > >application deaths, occational X11 lockups, but SUPRIZE! SUPRIZE! no more > >drive corruptions since I removed the DMA flag from the drives, disabled > >DMA use in the BIOS and replaced the ATA66 cable with an ATA33. > > (the following is a lot of conjecture and doesn't wholly fit the information > avalible to me on this problem, but maybe it'll help bring about other ideas > that will lead to a fix for this) > > OK, I haven't had a chance to get 2.4 up and running yet, but yesterday I > was troubleshooting some lockup issues in Win2k and there was a slim chance > that it might have had to do with overheating of the chipset that controls > the RAM on the machine; but it turned out to be something of a driver issue. > However this got me thinking more about heat... this *really* is sounding > more and more like a heat problem to me... esspecialy if it might be board > specific, since there might be something in the specific designs that causes > higher levels of heat. > I *KNOW* that it seems unlikely since no other OS is exhibiting these > problems to my knowledge (including linux 2.2.*) but what if? Could there be > something in 2.4 making it more sensitive to errors related to heat? Could > 2.4 somehow be making the HDD controllers run hotter? > Prehaps we should start collecting average system tempatures of systems that > display this problem, esspecialy while running 2.4.x both with and without > DMA enabled. > > him> > > -NK > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Fw: VT82C686A corruption with 2.4.x
oops, I forgot to send this to linux-kernel as well... - Original Message - From: "Nicholas Knight" [EMAIL PROTECTED] To: "David D.W. Downey" [EMAIL PROTECTED] Sent: Thursday, February 01, 2001 5:24 AM Subject: Re: VT82C686A corruption with 2.4.x - Original Message - From: "David D.W. Downey" [EMAIL PROTECTED] To: "David Riley" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, February 01, 2001 4:51 AM Subject: Re: VT82C686A corruption with 2.4.x Yeah, I'm seriously beginning to think it's a board specific issue. If I drop the RAM count down to 768MB I get far less drops in app deaths Right now I've got the full 1GB in there. What I'm seeing now is application deaths, occational X11 lockups, but SUPRIZE! SUPRIZE! no more drive corruptions since I removed the DMA flag from the drives, disabled DMA use in the BIOS and replaced the ATA66 cable with an ATA33. (the following is a lot of conjecture and doesn't wholly fit the information avalible to me on this problem, but maybe it'll help bring about other ideas that will lead to a fix for this) OK, I haven't had a chance to get 2.4 up and running yet, but yesterday I was troubleshooting some lockup issues in Win2k and there was a slim chance that it might have had to do with overheating of the chipset that controls the RAM on the machine; but it turned out to be something of a driver issue. However this got me thinking more about heat... this *really* is sounding more and more like a heat problem to me... esspecialy if it might be board specific, since there might be something in the specific designs that causes higher levels of heat. I *KNOW* that it seems unlikely since no other OS is exhibiting these problems to my knowledge (including linux 2.2.*) but what if? Could there be something in 2.4 making it more sensitive to errors related to heat? Could 2.4 somehow be making the HDD controllers run hotter? Prehaps we should start collecting average system tempatures of systems that display this problem, esspecialy while running 2.4.x both with and without DMA enabled. end conjecture spoken by someone without enough information avalible to him -NK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.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.Mhz. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
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 motherboardsbut 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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
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 21 30 | 28.0 56.0 84.0 >22 |1 21 30 | 29.3 58.6 88.0 >23 |1 21 30 | 30.6 61.2 92.0 [snip] >31 |1 31 40 | 31.0 62.0 93.0 >32 |1 31 40 | 32.0 64.0 96.0 >33 |1 31 40 | 33.0 66.0 99.0 >34 |1 32 50 | 27.2 54.4 81.6 [snip] >59 |2 53 81 | 29.5 59.0 88.5 >60 |2 53 81 | 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 xxx 686a |25 |1 2 1 | 20 | 3T=33.3 2T=50.0 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 xxx 686a |33 |1 2 1 | 15 | 4T=33.3 2T=66.6 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
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 > 28Mhzso 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 21 30 | 28.0 56.0 84.0 22 |1 21 30 | 29.3 58.6 88.0 23 |1 21 30 | 30.6 61.2 92.0 24 |1 21 30 | 32.0 64.0 96.0 25 |1 21 30 | 33.3 66.6 100.0 26 |1 22 40 | 26.0 52.0 78.0 27 |1 22 40 | 27.0 54.0 81.0 28 |1 22 40 | 28.0 56.0 84.0 29 |1 31 40 | 29.0 58.0 87.0 30 |1 31 40 | 30.0 60.0 90.0 31 |1 31 40 | 31.0 62.0 93.0 32 |1 31 40 | 32.0 64.0 96.0 33 |1 31 40 | 33.0 66.0 99.0 34 |1 32 50 | 27.2 54.4 81.6 35 |1 32 50 | 28.0 56.0 84.0 36 |1 32 50 | 28.8 57.6 86.4 37 |1 32 50 | 29.6 59.2 88.8 38 |1 32 50 | 30.4 60.8 91.2 39 |1 32 50 | 31.2 62.4 93.6 40 |1 32 50 | 32.0 64.0 96.0 41 |2 32 50 | 32.8 65.6 98.4 42 |2 42 60 | 28.0 56.0 84.0 43 |2 42 60 | 28.6 57.2 86.0 44 |2 42 61 | 29.3 58.6 88.0 45 |2 42 61 | 30.0 60.0 90.0 46 |2 42 61 | 30.6 61.2 92.0 47 |2 42 61 | 31.3 62.6 94.0 48 |2 42 61 | 32.0 64.0 96.0 49 |2 42 61 | 32.6 65.2 98.0 50 |2 42 61 | 33.3 66.6 100.0 51 |2 43 71 | 29.1 58.2 87.4 52 |2 43 71 | 29.7 59.4 89.1 53 |2 43 71 | 30.2 60.4 90.8 54 |2 43 71 | 30.8 61.6 92.5 55 |2 43 71 | 31.4 62.8 94.2 56 |2 53 81 | 28.0 56.0 84.0 57 |2 53 81 | 28.5 57.0 85.5 58 |2 53 81 | 29.0 58.0 87.0 59 |2 53 81 | 29.5 59.0 88.5 60 |2 53 81 | 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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a
Re: VT82C686A corruption with 2.4.x
Yeah, I'm seriously beginning to think it's a board specific issue. If I drop the RAM count down to 768MB I get far less drops in app deaths now. I'm living in Sunnyvale CA which is part of the Rolling Blackouts designated spots in CA. Ever since the power companies have been instituting this I've seen equipment that otherwise ran great all of a sudden start flaking. I've got this particular machine connected to a UPS so I figured the voltage regulation would be right on the money. Now, I'm not so sure since a number of people have brought this up. I'm going to drop her down to 768MB and then try a 128MB DIMM in there. I want to see if it can handle that. Since the 128s have less draw than the 256s do, maybe this will work. Right now I've got the full 1GB in there. What I'm seeing now is application deaths, occational X11 lockups, but SUPRIZE! SUPRIZE! no more drive corruptions since I removed the DMA flag from the drives, disabled DMA use in the BIOS and replaced the ATA66 cable with an ATA33. For everyone out there that's assisted in tracking this down and assisted in getting a working fix going.. .THANK YOU! For now, I'm going to have to play keep in step with the kernel, patches, and the VIA driver. Voj, can you directly add me to whatever ANNOUNCE list you use for announcing the latest release of the driver? Once again thanks folks. It's still not totally stable here, but it's a DAMN sight farther than it was before. While not TOTALLY convinced that it's a local hardware issue, I do thank folks for their 2 cents. :-) On Wed, 31 Jan 2001, David Riley wrote: > Mark Hahn wrote: > > > > >>From what I gather this chipset on 2.4.x is only stable if you cripple just >about everything that makes > > > it worth having (udma, 2nd ide channel etc etc) ?does it even work when >all that's done now or is > > > it fully functional? > > > > it seems to be fully functional for some or most people, > > with two, apparently, reporting major problems. > > > > my via (kt133) is flawless in 2.4.1 (a drive on each channel, > > udma enabled and in use) and has for all the 2.3's since I got it. > > Not to make a "mee too" post but... > > It's worked flawlessly for me. Always. Since it seems to work fine for > just about everyone else, I'd venture to say that it's a board specific > issue, quite likely with the BIOS. Some other problems seem to have to > do with the memory; I remember the KX133 had some definite problems with > memory timing, especially with large amounts (3 DIMMS were a problem on > some motherboards that were loosely laid out). > > My 2 cents, > David > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
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 high110 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 28Mhzso 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Yeah, I'm seriously beginning to think it's a board specific issue. If I drop the RAM count down to 768MB I get far less drops in app deaths now. I'm living in Sunnyvale CA which is part of the Rolling Blackouts designated spots in CA. Ever since the power companies have been instituting this I've seen equipment that otherwise ran great all of a sudden start flaking. I've got this particular machine connected to a UPS so I figured the voltage regulation would be right on the money. Now, I'm not so sure since a number of people have brought this up. I'm going to drop her down to 768MB and then try a 128MB DIMM in there. I want to see if it can handle that. Since the 128s have less draw than the 256s do, maybe this will work. Right now I've got the full 1GB in there. What I'm seeing now is application deaths, occational X11 lockups, but SUPRIZE! SUPRIZE! no more drive corruptions since I removed the DMA flag from the drives, disabled DMA use in the BIOS and replaced the ATA66 cable with an ATA33. For everyone out there that's assisted in tracking this down and assisted in getting a working fix going.. .THANK YOU! For now, I'm going to have to play keep in step with the kernel, patches, and the VIA driver. Voj, can you directly add me to whatever ANNOUNCE list you use for announcing the latest release of the driver? Once again thanks folks. It's still not totally stable here, but it's a DAMN sight farther than it was before. While not TOTALLY convinced that it's a local hardware issue, I do thank folks for their 2 cents. :-) On Wed, 31 Jan 2001, David Riley wrote: Mark Hahn wrote: From what I gather this chipset on 2.4.x is only stable if you cripple just about everything that makes it worth having (udma, 2nd ide channel etc etc) ?does it even work when all that's done now or is it fully functional? it seems to be fully functional for some or most people, with two, apparently, reporting major problems. my via (kt133) is flawless in 2.4.1 (a drive on each channel, udma enabled and in use) and has for all the 2.3's since I got it. Not to make a "mee too" post but... It's worked flawlessly for me. Always. Since it seems to work fine for just about everyone else, I'd venture to say that it's a board specific issue, quite likely with the BIOS. Some other problems seem to have to do with the memory; I remember the KX133 had some definite problems with memory timing, especially with large amounts (3 DIMMS were a problem on some motherboards that were loosely laid out). My 2 cents, David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
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 28Mhzso 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 21 30 | 28.0 56.0 84.0 22 |1 21 30 | 29.3 58.6 88.0 23 |1 21 30 | 30.6 61.2 92.0 24 |1 21 30 | 32.0 64.0 96.0 25 |1 21 30 | 33.3 66.6 100.0 26 |1 22 40 | 26.0 52.0 78.0 27 |1 22 40 | 27.0 54.0 81.0 28 |1 22 40 | 28.0 56.0 84.0 29 |1 31 40 | 29.0 58.0 87.0 30 |1 31 40 | 30.0 60.0 90.0 31 |1 31 40 | 31.0 62.0 93.0 32 |1 31 40 | 32.0 64.0 96.0 33 |1 31 40 | 33.0 66.0 99.0 34 |1 32 50 | 27.2 54.4 81.6 35 |1 32 50 | 28.0 56.0 84.0 36 |1 32 50 | 28.8 57.6 86.4 37 |1 32 50 | 29.6 59.2 88.8 38 |1 32 50 | 30.4 60.8 91.2 39 |1 32 50 | 31.2 62.4 93.6 40 |1 32 50 | 32.0 64.0 96.0 41 |2 32 50 | 32.8 65.6 98.4 42 |2 42 60 | 28.0 56.0 84.0 43 |2 42 60 | 28.6 57.2 86.0 44 |2 42 61 | 29.3 58.6 88.0 45 |2 42 61 | 30.0 60.0 90.0 46 |2 42 61 | 30.6 61.2 92.0 47 |2 42 61 | 31.3 62.6 94.0 48 |2 42 61 | 32.0 64.0 96.0 49 |2 42 61 | 32.6 65.2 98.0 50 |2 42 61 | 33.3 66.6 100.0 51 |2 43 71 | 29.1 58.2 87.4 52 |2 43 71 | 29.7 59.4 89.1 53 |2 43 71 | 30.2 60.4 90.8 54 |2 43 71 | 30.8 61.6 92.5 55 |2 43 71 | 31.4 62.8 94.2 56 |2 53 81 | 28.0 56.0 84.0 57 |2 53 81 | 28.5 57.0 85.5 58 |2 53 81 | 29.0 58.0 87.0 59 |2 53 81 | 29.5 59.0 88.5 60 |2 53 81 | 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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL
Re: VT82C686A corruption with 2.4.x
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 21 30 | 28.0 56.0 84.0 22 |1 21 30 | 29.3 58.6 88.0 23 |1 21 30 | 30.6 61.2 92.0 [snip] 31 |1 31 40 | 31.0 62.0 93.0 32 |1 31 40 | 32.0 64.0 96.0 33 |1 31 40 | 33.0 66.0 99.0 34 |1 32 50 | 27.2 54.4 81.6 [snip] 59 |2 53 81 | 29.5 59.0 88.5 60 |2 53 81 | 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 xxx 686a |25 |1 2 1 | 20 | 3T=33.3 2T=50.0 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 xxx 686a |33 |1 2 1 | 15 | 4T=33.3 2T=66.6 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
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 motherboardsbut 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). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wed, Jan 31, 2001 at 07:46:31PM -0500, Byron Stanoszek wrote: > > yea i know. . same mode i also had a big problem with DMA timeouts on > > 2.4 so .. i dont know what's up with 2.4 and my motherboard ...2.2 > > hasn't shown a single irq or DMA error yet since going back to it. > > currently 2.2.19-pre7 is using UDMA4 i just flashed the bios today so .. > > hopefully that should have fixed any problems. I get 24MB/s each according > > to hdparm -t on my hdd's and both are on the same channel. This is much > > better than i ever got with 2.4 even when only one drive was on a channel. > > Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. > > my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so > > i'm happy with 2.2. The only thing that would make me want to upgrade would > > be latency patches. I'm convinced 2.4 has performance issues so i guess i'll > > be using 2.2 until 2.5 begins. Is it really only 1 or 2 people having > > this Via corruption problem? i doubt it's a bios problem because wouldn't > > 2.2 be effected by a bios bug if 2.4 is? In either case the changelogs dont > > show any fixes for it. > > If your FSB is running at 114 MHz, you should try the kernel parameter > idebus=37 to get DMA working correctly. Otherwise you'll see an ide-reset error > on bootup because the instructions are too fast. The VIA driver on 2.2 doesn't > correctly program the PCI card, so you don't see weird behavior running 2.2 > with a faster PCI clock. > > (Note: 1.14 * 33 = 37.6 PCI Clk) It's 38: 114 / 3 == 38 == 1.14 * 33.33 But definitely it isn't 34 or the default 33. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
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 high110 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. > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wed, Jan 31, 2001 at 05:57:45PM -0500, safemode wrote: > Alan Cox wrote: > > > > better than i ever got with 2.4 even when only one drive was on a channel. > > > Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. > > > > Hint: people who overclock machines get suprising odd results and bad stuff > > happens. Please dont waste developers time unless you can reproduce it at > > the intended speed for the components > > Like i said .. i just did that within the last 5 min it has nothing to do > with any problems i've been talking about Btw, if you run your FSB at 114 MHz, you need to pass 'idebus=38' to the IDE driver so that it knows your PCI bus runs at 38 MHz (3x38 = 114). Otherwise you'll get incorrect timing etc. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Byron Stanoszek wrote: > On Wed, 31 Jan 2001, safemode wrote: > > > yea i know. . same mode i also had a big problem with DMA timeouts on > > 2.4 so .. i dont know what's up with 2.4 and my motherboard ...2.2 > > hasn't shown a single irq or DMA error yet since going back to it. > > currently 2.2.19-pre7 is using UDMA4 i just flashed the bios today so .. > > hopefully that should have fixed any problems. I get 24MB/s each according > > to hdparm -t on my hdd's and both are on the same channel. This is much > > better than i ever got with 2.4 even when only one drive was on a channel. > > Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. > > my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so > > i'm happy with 2.2. The only thing that would make me want to upgrade would > > be latency patches. I'm convinced 2.4 has performance issues so i guess i'll > > be using 2.2 until 2.5 begins. Is it really only 1 or 2 people having > > this Via corruption problem? i doubt it's a bios problem because wouldn't > > 2.2 be effected by a bios bug if 2.4 is? In either case the changelogs dont > > show any fixes for it. > > If your FSB is running at 114 MHz, you should try the kernel parameter > idebus=37 to get DMA working correctly. Otherwise you'll see an ide-reset error > on bootup because the instructions are too fast. The VIA driver on 2.2 doesn't > correctly program the PCI card, so you don't see weird behavior running 2.2 > with a faster PCI clock. > > (Note: 1.14 * 33 = 37.6 PCI Clk) > > It also matters what motherboard you're using, and if it can support speeds up > past 100. If you're serious about overclocking, buy one of the new KT133A > boards that support speeds up to 133 (or an average overclocked 145 limit). > > For instance, my Epox KX133 board is unstable at anything above 110 FSB, but > I've seen the Abit KT7 go as high as 116. You should also have some good > memory that is rated for 150MHz, otherwise you're just asking for trouble. 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 high110 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. > > As always, if you have problems with the kernel and want to submit a bug > report, please put all the settings back to normal and test thoroughly before > continuing. It's funny how many bug reports I've heard from people who've > overclocked their FSB and expected the IDE DMA to be set appropriately under > 2.4... maybe this should be mentioned somewhere in ide.txt, even though > overclocking is frowned upon. As i mentioned in older emails, i did this _today_ i mentioned this "bug" over two weeks ago. I turned off DMA in the bios and kernel and the "bug" was still present. you can read the old emails and see for yourself. > > Regards, > Byron > > -- > Byron Stanoszek Ph: (330) 644-3059 > Systems Programmer Fax: (330) 644-8110 > Commercial Timesharing Inc. Email: [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wed, 31 Jan 2001, safemode wrote: > yea i know. . same mode i also had a big problem with DMA timeouts on > 2.4 so .. i dont know what's up with 2.4 and my motherboard ...2.2 > hasn't shown a single irq or DMA error yet since going back to it. > currently 2.2.19-pre7 is using UDMA4 i just flashed the bios today so .. > hopefully that should have fixed any problems. I get 24MB/s each according > to hdparm -t on my hdd's and both are on the same channel. This is much > better than i ever got with 2.4 even when only one drive was on a channel. > Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. > my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so > i'm happy with 2.2. The only thing that would make me want to upgrade would > be latency patches. I'm convinced 2.4 has performance issues so i guess i'll > be using 2.2 until 2.5 begins. Is it really only 1 or 2 people having > this Via corruption problem? i doubt it's a bios problem because wouldn't > 2.2 be effected by a bios bug if 2.4 is? In either case the changelogs dont > show any fixes for it. If your FSB is running at 114 MHz, you should try the kernel parameter idebus=37 to get DMA working correctly. Otherwise you'll see an ide-reset error on bootup because the instructions are too fast. The VIA driver on 2.2 doesn't correctly program the PCI card, so you don't see weird behavior running 2.2 with a faster PCI clock. (Note: 1.14 * 33 = 37.6 PCI Clk) It also matters what motherboard you're using, and if it can support speeds up past 100. If you're serious about overclocking, buy one of the new KT133A boards that support speeds up to 133 (or an average overclocked 145 limit). For instance, my Epox KX133 board is unstable at anything above 110 FSB, but I've seen the Abit KT7 go as high as 116. You should also have some good memory that is rated for 150MHz, otherwise you're just asking for trouble. As always, if you have problems with the kernel and want to submit a bug report, please put all the settings back to normal and test thoroughly before continuing. It's funny how many bug reports I've heard from people who've overclocked their FSB and expected the IDE DMA to be set appropriately under 2.4... maybe this should be mentioned somewhere in ide.txt, even though overclocking is frowned upon. Regards, Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Tobias Ringstrom wrote: > On Wed, 31 Jan 2001, safemode wrote: > > > I'm wondering... Perhaps it's a problem motherboard specific. I'm > > using the KA7 and saw pretty bad problems (extreme fs corruption) > > and bad latency. Perhaps the K7V and the KT7's dont have this problem. > > I dont see any of the problems with dma enabled on 2.2.x > > But are you using the same DMA mode in 2.2 as in 2.4? You can check that > using hdparm -i, I believe. > > /Tobias yea i know. . same mode i also had a big problem with DMA timeouts on 2.4 so .. i dont know what's up with 2.4 and my motherboard ...2.2 hasn't shown a single irq or DMA error yet since going back to it. currently 2.2.19-pre7 is using UDMA4 i just flashed the bios today so .. hopefully that should have fixed any problems. I get 24MB/s each according to hdparm -t on my hdd's and both are on the same channel. This is much better than i ever got with 2.4 even when only one drive was on a channel. Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so i'm happy with 2.2. The only thing that would make me want to upgrade would be latency patches. I'm convinced 2.4 has performance issues so i guess i'll be using 2.2 until 2.5 begins. Is it really only 1 or 2 people having this Via corruption problem? i doubt it's a bios problem because wouldn't 2.2 be effected by a bios bug if 2.4 is? In either case the changelogs dont show any fixes for it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wed, 31 Jan 2001, safemode wrote: > I'm wondering... Perhaps it's a problem motherboard specific. I'm > using the KA7 and saw pretty bad problems (extreme fs corruption) > and bad latency. Perhaps the K7V and the KT7's dont have this problem. > I dont see any of the problems with dma enabled on 2.2.x But are you using the same DMA mode in 2.2 as in 2.4? You can check that using hdparm -i, I believe. /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Alan Cox wrote: > > better than i ever got with 2.4 even when only one drive was on a channel. > > Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. > > Hint: people who overclock machines get suprising odd results and bad stuff > happens. Please dont waste developers time unless you can reproduce it at > the intended speed for the components Like i said .. i just did that within the last 5 min it has nothing to do with any problems i've been talking about - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
> better than i ever got with 2.4 even when only one drive was on a channel. > Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. Hint: people who overclock machines get suprising odd results and bad stuff happens. Please dont waste developers time unless you can reproduce it at the intended speed for the components - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Mark Hahn wrote: > >From what I gather this chipset on 2.4.x is only stable if you cripple just about >everything that makes > > it worth having (udma, 2nd ide channel etc etc) ?does it even work when all >that's done now or is > > it fully functional? > > it seems to be fully functional for some or most people, > with two, apparently, reporting major problems. > > my via (kt133) is flawless in 2.4.1 (a drive on each channel, > udma enabled and in use) and has for all the 2.3's since I got it. I'm wondering... Perhaps it's a problem motherboard specific. I'm using the KA7 and saw pretty bad problems (extreme fs corruption) and bad latency. Perhaps the K7V and the KT7's dont have this problem. I dont see any of the problems with dma enabled on 2.2.x Output of 2.2.19-pre7 lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [KX133 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d9ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at d000 Capabilities: [c0] Power Management version 2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Mark Hahn wrote: > > >>From what I gather this chipset on 2.4.x is only stable if you cripple just about >everything that makes > > it worth having (udma, 2nd ide channel etc etc) ?does it even work when all >that's done now or is > > it fully functional? > > it seems to be fully functional for some or most people, > with two, apparently, reporting major problems. > > my via (kt133) is flawless in 2.4.1 (a drive on each channel, > udma enabled and in use) and has for all the 2.3's since I got it. Not to make a "mee too" post but... It's worked flawlessly for me. Always. Since it seems to work fine for just about everyone else, I'd venture to say that it's a board specific issue, quite likely with the BIOS. Some other problems seem to have to do with the memory; I remember the KX133 had some definite problems with memory timing, especially with large amounts (3 DIMMS were a problem on some motherboards that were loosely laid out). My 2 cents, David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wed, 31 Jan 2001, Vojtech Pavlik wrote:
> > > 1) You don't seem to have any drives on the VIA controller. If this is
> > > true, I don't think this can be a VIA IDE driver problem.
> > >
Umm, since the only 2 controllers in the machine are the VIA Vt82C686A and
the Promise PDC20265, yes I AM running drives on the VIA controller.
I have NO drives on the ATA100 controller which is the Promise
controller. Everything is running off the VIA.
>
> > > 2) In your original message you suggest bs=1024M, which isn't a very
> > > good idea, even on a 768 MB system. Here with bs=1024k it seems to run
> > > fine.
> > >
Yes, that was a typo. My apologies. It _should_ have been a k not an M.
> > > 3) You sent next to none VIA related debugging info. lspci -v itself
> > > isn't much valuable because I don't get the register contents. Also
> > > hdparm -i of the drives attached to the VIA chip would be useful. Plus
> > > also the contents of /proc/ide/via.
> >
OK, here are quite a few outputs.
lspci -n outputs
00:00.0 Class 0600: 1106:0691 (rev c4)
00:01.0 Class 0604: 1106:8598
00:07.0 Class 0601: 1106:0686 (rev 22)
00:07.1 Class 0101: 1106:0571 (rev 10)
00:07.4 Class 0600: 1106:3057 (rev 30)
00:07.5 Class 0401: 1106:3058 (rev 20)
00:0c.0 Class 0180: 105a:0d30 (rev 02)
00:0e.0 Class 0100: 10cd:2300
00:10.0 Class 0200: 11ad:0002 (rev 20)
01:00.0 Class 0300: 121a:0005 (rev 01)
lspci -H1 outputs
00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30
(rev 02)
00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW
00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01)
lspci -m outputs
00:00.0 "Host bridge" "VIA Technologies, Inc." "VT82C691 [Apollo PRO]" -rc4 "" ""
00:01.0 "PCI bridge" "VIA Technologies, Inc." "VT82C598 [Apollo MVP3 AGP]" "" ""
00:07.0 "ISA bridge" "VIA Technologies, Inc." "VT82C686 [Apollo Super]" -r22 "VIA
Technologies, Inc." "VT82C686/A PCI to ISA Bridge"
00:07.1 "IDE interface" "VIA Technologies, Inc." "VT82C586 IDE [Apollo]" -r10 -p8a ""
""
00:07.4 "Host bridge" "VIA Technologies, Inc." "VT82C686 [Apollo Super ACPI]" -r30 ""
""
00:07.5 "Multimedia audio controller" "VIA Technologies, Inc." "VT82C686 [Apollo Super
AC97/Audio]" -r20 "VIA Technologies, Inc." "VT82C686 [Apollo Super AC97/Audio]"
00:0c.0 "Unknown mass storage controller" "Promise Technology, Inc." "0d30" -r02
"Promise Technology, Inc." "0d30"
00:0e.0 "SCSI storage controller" "Advanced System Products, Inc" "ABP940-UW" "" ""
00:10.0 "Ethernet controller" "Lite-On Communications Inc" "LNE100TX" -r20 "Netgear"
"FA310TX"
01:00.0 "VGA compatible controller" "3Dfx Interactive, Inc." "Voodoo 3" -r01 "3Dfx
Interactive, Inc." "Voodoo3 AGP"
lspci outputs
00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super
AC97/Audio] (rev 20)
00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30
(rev 02)
00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW
00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01)
hdparm -i /dev/hda outputs
/dev/hda:
Model=WDC WD300BB-00AUA1, FwRev=18.20D18, SerialNo=WD-WMA6W1132085
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=58633344
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5
hdparm -i /dev/hdc outputs
/dev/hdc:
Model=WDC WD153AA, FwRev=05.05B05, SerialNo=WD-WMA0R1258522
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=30064608
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0
Re: VT82C686A corruption with 2.4.x
>From what I gather this chipset on 2.4.x is only stable if you cripple just about >everything that makes > it worth having (udma, 2nd ide channel etc etc) ?does it even work when all >that's done now or is > it fully functional? it seems to be fully functional for some or most people, with two, apparently, reporting major problems. my via (kt133) is flawless in 2.4.1 (a drive on each channel, udma enabled and in use) and has for all the 2.3's since I got it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wed, Jan 31, 2001 at 04:48:41AM -0500, safemode wrote: > From what I gather this chipset on 2.4.x is only stable if you > cripple just about everything that makes > it worth having (udma, 2nd ide channel etc etc) ?does it even > work when all that's done now or is it fully functional? For most people (95% at least) it's fully functional, including DMA (even UDMA100), both channels (I have never seen a problem with the 2nd channel?), etc. There are some people who have problems, namely Abit KT7 users, but a BIOS upgrade seems to fix those case usually. > I used some pre 2.4.1 kernel before it thrashed my disk and i had UDMA > disabled in bios and kernel and the corruption persisted. I heard > somewhere that it may have been linked to swap ? Anyway, I'm using > 2.2.19-pre7 right now with DMA and it's doing perfect ...with better > responsiveness than 2.4.x . Could this be because of via problems on > the 2.4.x kernel or is it 2.4.x arch ? No, probably not. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Tue, Jan 30, 2001 at 11:55:25PM -0800, David Raufeisen wrote: > On Wednesday, 31 January 2001, at 08:36:42 (+0100), > Vojtech Pavlik wrote: > > > Hi! > > > > 1) You don't seem to have any drives on the VIA controller. If this is > > true, I don't think this can be a VIA IDE driver problem. > > > > Hi, Are you referring to Mark or me? I was referring to David D.W. Downey, the one who started this thread. He was in the To: fiels, you and Mark were in Cc: > > 2) In your original message you suggest bs=1024M, which isn't a very > > good idea, even on a 768 MB system. Here with bs=1024k it seems to run > > fine. > > > > 3) You sent next to none VIA related debugging info. lspci -v itself > > isn't much valuable because I don't get the register contents. Also > > hdparm -i of the drives attached to the VIA chip would be useful. Plus > > also the contents of /proc/ide/via. > > I didn't supply anything either, even though my configuration works great it > might prove useful to someone comparing: Sorry, this message indeed was directed to someone else. Thanks for your info, anyway, it's always useful to have some positive evidence that the thing does work for people. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
David Raufeisen wrote:
> On Wednesday, 31 January 2001, at 08:36:42 (+0100),
> Vojtech Pavlik wrote:
>
> > Hi!
> >
> > 1) You don't seem to have any drives on the VIA controller. If this is
> > true, I don't think this can be a VIA IDE driver problem.
> >
>
> Hi, Are you referring to Mark or me?
>
> I have drives on my VIA (only..) IDE controller:
>
> VP_IDE: IDE controller on PCI bus 00 dev 39
> VP_IDE: chipset revision 16
> VP_IDE: not 100% native mode: will probe irqs later
> VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
> VP_IDE: ATA-66/100 forced bit set (WARNING)!!
> ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
> VP_IDE: ATA-66/100 forced bit set (WARNING)!!
> ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
> hda: Maxtor 51536H2, ATA DISK drive
> hdb: Maxtor 94098U8, ATA DISK drive
> hdc: CD-ROM 52X/AKH, ATAPI CD/DVD-ROM drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
> hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(66)
> hdc: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33)
> Uniform CD-ROM driver Revision: 3.12
> Partition check:
> hda: hda1 hda2
> hdb: hdb1
>
> > 2) In your original message you suggest bs=1024M, which isn't a very
> > good idea, even on a 768 MB system. Here with bs=1024k it seems to run
> > fine.
> >
> > 3) You sent next to none VIA related debugging info. lspci -v itself
> > isn't much valuable because I don't get the register contents. Also
> > hdparm -i of the drives attached to the VIA chip would be useful. Plus
> > also the contents of /proc/ide/via.
>
> I didn't supply anything either, even though my configuration works great it
> might prove useful to someone comparing:
>
> bash-2.04# hdparm -i /dev/hda
>
> /dev/hda:
>
> Model=Maxtor 51536H2, FwRev=JAC61HU0, SerialNo=F203VTHC
> Config={ Fixed }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
> BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=30015216
> IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
> bash-2.04# hdparm -i /dev/hdb
>
> /dev/hdb:
>
> Model=Maxtor 94098U8, FwRev=FA500S60, SerialNo=G8066RQC
> Config={ Fixed }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
> BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
> CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=80041248
> IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
> PIO modes: pio0 pio1 pio2 pio3 pio4
> DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
> bash-2.04#
>
> bash-2.04# cat /proc/ide/via
> --VIA BusMastering IDE Configuration
> Driver Version: 2.1e
> South Bridge: VIA vt82c686a rev 0x22
> Command register: 0x7
> Latency timer: 32
> PCI clock: 33MHz
> Master Read Cycle IRDY:0ws
> Master Write Cycle IRDY:0ws
> FIFO Output Data 1/2 Clock Advance: off
> BM IDE Status Register Read Retry: on
> Max DRDY Pulse Width: No limit
> ---Primary IDE---Secondary IDE--
> Read DMA FIFO flush: on on
> End Sect. FIFO flush: on on
> Prefetch Buffer: on on
> Post Write Buffer: on on
> FIFO size: 8 8
> Threshold Prim.: 1/2 1/2
> Bytes Per Sector: 512 512
> Both channels togth: yes yes
> ---drive0drive1drive2drive3-
> BMDMA enabled:yes yes yesno
> Transfer Mode: UDMA UDMA UDMA DMA/PIO
> Address Setup: 30ns 30ns 30ns 120ns
> Active Pulse:90ns 90ns 90ns 330ns
> Recovery Time: 30ns 30ns 30ns 270ns
> Cycle Time: 30ns 30ns 60ns 600ns
> Transfer Rate: 66.0MB/s 66.0MB/s 33.0MB/s 3.3MB/s
>
> bash-2.04# lspci -v (trimmed)
> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
> Flags: bus master, medium devsel, latency 8
> Memory at e000 (32-bit, prefetchable) [size=64M]
> Capabilities: [a0] AGP version 2.0
> Capabilities: [c0] Power Management version 2
>
> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00
>[Normal decode])
> Flags: bus master, 66Mhz, medium devsel, latency 0
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: 9000-9fff
> Memory
Re: VT82C686A corruption with 2.4.x
David Raufeisen wrote:
On Wednesday, 31 January 2001, at 08:36:42 (+0100),
Vojtech Pavlik wrote:
Hi!
1) You don't seem to have any drives on the VIA controller. If this is
true, I don't think this can be a VIA IDE driver problem.
Hi, Are you referring to Mark or me?
I have drives on my VIA (only..) IDE controller:
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: Maxtor 51536H2, ATA DISK drive
hdb: Maxtor 94098U8, ATA DISK drive
hdc: CD-ROM 52X/AKH, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(66)
hdc: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
hda: hda1 hda2
hdb: hdb1
2) In your original message you suggest bs=1024M, which isn't a very
good idea, even on a 768 MB system. Here with bs=1024k it seems to run
fine.
3) You sent next to none VIA related debugging info. lspci -v itself
isn't much valuable because I don't get the register contents. Also
hdparm -i of the drives attached to the VIA chip would be useful. Plus
also the contents of /proc/ide/via.
I didn't supply anything either, even though my configuration works great it
might prove useful to someone comparing:
bash-2.04# hdparm -i /dev/hda
/dev/hda:
Model=Maxtor 51536H2, FwRev=JAC61HU0, SerialNo=F203VTHC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=30015216
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
bash-2.04# hdparm -i /dev/hdb
/dev/hdb:
Model=Maxtor 94098U8, FwRev=FA500S60, SerialNo=G8066RQC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=80041248
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
bash-2.04#
bash-2.04# cat /proc/ide/via
--VIA BusMastering IDE Configuration
Driver Version: 2.1e
South Bridge: VIA vt82c686a rev 0x22
Command register: 0x7
Latency timer: 32
PCI clock: 33MHz
Master Read Cycle IRDY:0ws
Master Write Cycle IRDY:0ws
FIFO Output Data 1/2 Clock Advance: off
BM IDE Status Register Read Retry: on
Max DRDY Pulse Width: No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush: on on
End Sect. FIFO flush: on on
Prefetch Buffer: on on
Post Write Buffer: on on
FIFO size: 8 8
Threshold Prim.: 1/2 1/2
Bytes Per Sector: 512 512
Both channels togth: yes yes
---drive0drive1drive2drive3-
BMDMA enabled:yes yes yesno
Transfer Mode: UDMA UDMA UDMA DMA/PIO
Address Setup: 30ns 30ns 30ns 120ns
Active Pulse:90ns 90ns 90ns 330ns
Recovery Time: 30ns 30ns 30ns 270ns
Cycle Time: 30ns 30ns 60ns 600ns
Transfer Rate: 66.0MB/s 66.0MB/s 33.0MB/s 3.3MB/s
bash-2.04# lspci -v (trimmed)
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
Flags: bus master, medium devsel, latency 8
Memory at e000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00
[Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 9000-9fff
Memory behind bridge: dde0-dfef
Prefetchable memory behind bridge: cdc0-ddcf
Capabilities: [80] Power
Re: VT82C686A corruption with 2.4.x
On Tue, Jan 30, 2001 at 11:55:25PM -0800, David Raufeisen wrote: On Wednesday, 31 January 2001, at 08:36:42 (+0100), Vojtech Pavlik wrote: Hi! 1) You don't seem to have any drives on the VIA controller. If this is true, I don't think this can be a VIA IDE driver problem. Hi, Are you referring to Mark or me? I was referring to David D.W. Downey, the one who started this thread. He was in the To: fiels, you and Mark were in Cc: 2) In your original message you suggest bs=1024M, which isn't a very good idea, even on a 768 MB system. Here with bs=1024k it seems to run fine. 3) You sent next to none VIA related debugging info. lspci -v itself isn't much valuable because I don't get the register contents. Also hdparm -i of the drives attached to the VIA chip would be useful. Plus also the contents of /proc/ide/via. I didn't supply anything either, even though my configuration works great it might prove useful to someone comparing: Sorry, this message indeed was directed to someone else. Thanks for your info, anyway, it's always useful to have some positive evidence that the thing does work for people. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wed, Jan 31, 2001 at 04:48:41AM -0500, safemode wrote: From what I gather this chipset on 2.4.x is only stable if you cripple just about everything that makes it worth having (udma, 2nd ide channel etc etc) ?does it even work when all that's done now or is it fully functional? For most people (95% at least) it's fully functional, including DMA (even UDMA100), both channels (I have never seen a problem with the 2nd channel?), etc. There are some people who have problems, namely Abit KT7 users, but a BIOS upgrade seems to fix those case usually. I used some pre 2.4.1 kernel before it thrashed my disk and i had UDMA disabled in bios and kernel and the corruption persisted. I heard somewhere that it may have been linked to swap ? Anyway, I'm using 2.2.19-pre7 right now with DMA and it's doing perfect ...with better responsiveness than 2.4.x . Could this be because of via problems on the 2.4.x kernel or is it 2.4.x arch ? No, probably not. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wed, 31 Jan 2001, Vojtech Pavlik wrote:
1) You don't seem to have any drives on the VIA controller. If this is
true, I don't think this can be a VIA IDE driver problem.
Umm, since the only 2 controllers in the machine are the VIA Vt82C686A and
the Promise PDC20265, yes I AM running drives on the VIA controller.
I have NO drives on the ATA100 controller which is the Promise
controller. Everything is running off the VIA.
2) In your original message you suggest bs=1024M, which isn't a very
good idea, even on a 768 MB system. Here with bs=1024k it seems to run
fine.
Yes, that was a typo. My apologies. It _should_ have been a k not an M.
3) You sent next to none VIA related debugging info. lspci -v itself
isn't much valuable because I don't get the register contents. Also
hdparm -i of the drives attached to the VIA chip would be useful. Plus
also the contents of /proc/ide/via.
OK, here are quite a few outputs.
lspci -n outputs
00:00.0 Class 0600: 1106:0691 (rev c4)
00:01.0 Class 0604: 1106:8598
00:07.0 Class 0601: 1106:0686 (rev 22)
00:07.1 Class 0101: 1106:0571 (rev 10)
00:07.4 Class 0600: 1106:3057 (rev 30)
00:07.5 Class 0401: 1106:3058 (rev 20)
00:0c.0 Class 0180: 105a:0d30 (rev 02)
00:0e.0 Class 0100: 10cd:2300
00:10.0 Class 0200: 11ad:0002 (rev 20)
01:00.0 Class 0300: 121a:0005 (rev 01)
lspci -H1 outputs
00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30
(rev 02)
00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW
00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01)
lspci -m outputs
00:00.0 "Host bridge" "VIA Technologies, Inc." "VT82C691 [Apollo PRO]" -rc4 "" ""
00:01.0 "PCI bridge" "VIA Technologies, Inc." "VT82C598 [Apollo MVP3 AGP]" "" ""
00:07.0 "ISA bridge" "VIA Technologies, Inc." "VT82C686 [Apollo Super]" -r22 "VIA
Technologies, Inc." "VT82C686/A PCI to ISA Bridge"
00:07.1 "IDE interface" "VIA Technologies, Inc." "VT82C586 IDE [Apollo]" -r10 -p8a ""
""
00:07.4 "Host bridge" "VIA Technologies, Inc." "VT82C686 [Apollo Super ACPI]" -r30 ""
""
00:07.5 "Multimedia audio controller" "VIA Technologies, Inc." "VT82C686 [Apollo Super
AC97/Audio]" -r20 "VIA Technologies, Inc." "VT82C686 [Apollo Super AC97/Audio]"
00:0c.0 "Unknown mass storage controller" "Promise Technology, Inc." "0d30" -r02
"Promise Technology, Inc." "0d30"
00:0e.0 "SCSI storage controller" "Advanced System Products, Inc" "ABP940-UW" "" ""
00:10.0 "Ethernet controller" "Lite-On Communications Inc" "LNE100TX" -r20 "Netgear"
"FA310TX"
01:00.0 "VGA compatible controller" "3Dfx Interactive, Inc." "Voodoo 3" -r01 "3Dfx
Interactive, Inc." "Voodoo3 AGP"
lspci outputs
00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4)
00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super
AC97/Audio] (rev 20)
00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30
(rev 02)
00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW
00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01)
hdparm -i /dev/hda outputs
/dev/hda:
Model=WDC WD300BB-00AUA1, FwRev=18.20D18, SerialNo=WD-WMA6W1132085
Config={ HardSect NotMFM HdSw15uSec SpinMotCtl Fixed DTR5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=58633344
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5
hdparm -i /dev/hdc outputs
/dev/hdc:
Model=WDC WD153AA, FwRev=05.05B05, SerialNo=WD-WMA0R1258522
Config={ HardSect NotMFM HdSw15uSec SpinMotCtl Fixed DTR5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=30064608
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4
Re: VT82C686A corruption with 2.4.x
Mark Hahn wrote: From what I gather this chipset on 2.4.x is only stable if you cripple just about everything that makes it worth having (udma, 2nd ide channel etc etc) ?does it even work when all that's done now or is it fully functional? it seems to be fully functional for some or most people, with two, apparently, reporting major problems. my via (kt133) is flawless in 2.4.1 (a drive on each channel, udma enabled and in use) and has for all the 2.3's since I got it. Not to make a "mee too" post but... It's worked flawlessly for me. Always. Since it seems to work fine for just about everyone else, I'd venture to say that it's a board specific issue, quite likely with the BIOS. Some other problems seem to have to do with the memory; I remember the KX133 had some definite problems with memory timing, especially with large amounts (3 DIMMS were a problem on some motherboards that were loosely laid out). My 2 cents, David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Mark Hahn wrote: From what I gather this chipset on 2.4.x is only stable if you cripple just about everything that makes it worth having (udma, 2nd ide channel etc etc) ?does it even work when all that's done now or is it fully functional? it seems to be fully functional for some or most people, with two, apparently, reporting major problems. my via (kt133) is flawless in 2.4.1 (a drive on each channel, udma enabled and in use) and has for all the 2.3's since I got it. I'm wondering... Perhaps it's a problem motherboard specific. I'm using the KA7 and saw pretty bad problems (extreme fs corruption) and bad latency. Perhaps the K7V and the KT7's dont have this problem. I dont see any of the problems with dma enabled on 2.2.x Output of 2.2.19-pre7 lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [KX133 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d9ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at d000 Capabilities: [c0] Power Management version 2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
better than i ever got with 2.4 even when only one drive was on a channel. Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. Hint: people who overclock machines get suprising odd results and bad stuff happens. Please dont waste developers time unless you can reproduce it at the intended speed for the components - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Alan Cox wrote: better than i ever got with 2.4 even when only one drive was on a channel. Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. Hint: people who overclock machines get suprising odd results and bad stuff happens. Please dont waste developers time unless you can reproduce it at the intended speed for the components Like i said .. i just did that within the last 5 min it has nothing to do with any problems i've been talking about - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wed, 31 Jan 2001, safemode wrote: I'm wondering... Perhaps it's a problem motherboard specific. I'm using the KA7 and saw pretty bad problems (extreme fs corruption) and bad latency. Perhaps the K7V and the KT7's dont have this problem. I dont see any of the problems with dma enabled on 2.2.x But are you using the same DMA mode in 2.2 as in 2.4? You can check that using hdparm -i, I believe. /Tobias - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Tobias Ringstrom wrote: On Wed, 31 Jan 2001, safemode wrote: I'm wondering... Perhaps it's a problem motherboard specific. I'm using the KA7 and saw pretty bad problems (extreme fs corruption) and bad latency. Perhaps the K7V and the KT7's dont have this problem. I dont see any of the problems with dma enabled on 2.2.x But are you using the same DMA mode in 2.2 as in 2.4? You can check that using hdparm -i, I believe. /Tobias yea i know. . same mode i also had a big problem with DMA timeouts on 2.4 so .. i dont know what's up with 2.4 and my motherboard ...2.2 hasn't shown a single irq or DMA error yet since going back to it. currently 2.2.19-pre7 is using UDMA4 i just flashed the bios today so .. hopefully that should have fixed any problems. I get 24MB/s each according to hdparm -t on my hdd's and both are on the same channel. This is much better than i ever got with 2.4 even when only one drive was on a channel. Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so i'm happy with 2.2. The only thing that would make me want to upgrade would be latency patches. I'm convinced 2.4 has performance issues so i guess i'll be using 2.2 until 2.5 begins. Is it really only 1 or 2 people having this Via corruption problem? i doubt it's a bios problem because wouldn't 2.2 be effected by a bios bug if 2.4 is? In either case the changelogs dont show any fixes for it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wed, 31 Jan 2001, safemode wrote: yea i know. . same mode i also had a big problem with DMA timeouts on 2.4 so .. i dont know what's up with 2.4 and my motherboard ...2.2 hasn't shown a single irq or DMA error yet since going back to it. currently 2.2.19-pre7 is using UDMA4 i just flashed the bios today so .. hopefully that should have fixed any problems. I get 24MB/s each according to hdparm -t on my hdd's and both are on the same channel. This is much better than i ever got with 2.4 even when only one drive was on a channel. Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so i'm happy with 2.2. The only thing that would make me want to upgrade would be latency patches. I'm convinced 2.4 has performance issues so i guess i'll be using 2.2 until 2.5 begins. Is it really only 1 or 2 people having this Via corruption problem? i doubt it's a bios problem because wouldn't 2.2 be effected by a bios bug if 2.4 is? In either case the changelogs dont show any fixes for it. If your FSB is running at 114 MHz, you should try the kernel parameter idebus=37 to get DMA working correctly. Otherwise you'll see an ide-reset error on bootup because the instructions are too fast. The VIA driver on 2.2 doesn't correctly program the PCI card, so you don't see weird behavior running 2.2 with a faster PCI clock. (Note: 1.14 * 33 = 37.6 PCI Clk) It also matters what motherboard you're using, and if it can support speeds up past 100. If you're serious about overclocking, buy one of the new KT133A boards that support speeds up to 133 (or an average overclocked 145 limit). For instance, my Epox KX133 board is unstable at anything above 110 FSB, but I've seen the Abit KT7 go as high as 116. You should also have some good memory that is rated for 150MHz, otherwise you're just asking for trouble. As always, if you have problems with the kernel and want to submit a bug report, please put all the settings back to normal and test thoroughly before continuing. It's funny how many bug reports I've heard from people who've overclocked their FSB and expected the IDE DMA to be set appropriately under 2.4... maybe this should be mentioned somewhere in ide.txt, even though overclocking is frowned upon. Regards, Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Byron Stanoszek wrote: On Wed, 31 Jan 2001, safemode wrote: yea i know. . same mode i also had a big problem with DMA timeouts on 2.4 so .. i dont know what's up with 2.4 and my motherboard ...2.2 hasn't shown a single irq or DMA error yet since going back to it. currently 2.2.19-pre7 is using UDMA4 i just flashed the bios today so .. hopefully that should have fixed any problems. I get 24MB/s each according to hdparm -t on my hdd's and both are on the same channel. This is much better than i ever got with 2.4 even when only one drive was on a channel. Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so i'm happy with 2.2. The only thing that would make me want to upgrade would be latency patches. I'm convinced 2.4 has performance issues so i guess i'll be using 2.2 until 2.5 begins. Is it really only 1 or 2 people having this Via corruption problem? i doubt it's a bios problem because wouldn't 2.2 be effected by a bios bug if 2.4 is? In either case the changelogs dont show any fixes for it. If your FSB is running at 114 MHz, you should try the kernel parameter idebus=37 to get DMA working correctly. Otherwise you'll see an ide-reset error on bootup because the instructions are too fast. The VIA driver on 2.2 doesn't correctly program the PCI card, so you don't see weird behavior running 2.2 with a faster PCI clock. (Note: 1.14 * 33 = 37.6 PCI Clk) It also matters what motherboard you're using, and if it can support speeds up past 100. If you're serious about overclocking, buy one of the new KT133A boards that support speeds up to 133 (or an average overclocked 145 limit). For instance, my Epox KX133 board is unstable at anything above 110 FSB, but I've seen the Abit KT7 go as high as 116. You should also have some good memory that is rated for 150MHz, otherwise you're just asking for trouble. 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 high110 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. As always, if you have problems with the kernel and want to submit a bug report, please put all the settings back to normal and test thoroughly before continuing. It's funny how many bug reports I've heard from people who've overclocked their FSB and expected the IDE DMA to be set appropriately under 2.4... maybe this should be mentioned somewhere in ide.txt, even though overclocking is frowned upon. As i mentioned in older emails, i did this _today_ i mentioned this "bug" over two weeks ago. I turned off DMA in the bios and kernel and the "bug" was still present. you can read the old emails and see for yourself. Regards, Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wed, Jan 31, 2001 at 05:57:45PM -0500, safemode wrote: Alan Cox wrote: better than i ever got with 2.4 even when only one drive was on a channel. Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. Hint: people who overclock machines get suprising odd results and bad stuff happens. Please dont waste developers time unless you can reproduce it at the intended speed for the components Like i said .. i just did that within the last 5 min it has nothing to do with any problems i've been talking about Btw, if you run your FSB at 114 MHz, you need to pass 'idebus=38' to the IDE driver so that it knows your PCI bus runs at 38 MHz (3x38 = 114). Otherwise you'll get incorrect timing etc. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
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 high110 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. 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wed, Jan 31, 2001 at 07:46:31PM -0500, Byron Stanoszek wrote: yea i know. . same mode i also had a big problem with DMA timeouts on 2.4 so .. i dont know what's up with 2.4 and my motherboard ...2.2 hasn't shown a single irq or DMA error yet since going back to it. currently 2.2.19-pre7 is using UDMA4 i just flashed the bios today so .. hopefully that should have fixed any problems. I get 24MB/s each according to hdparm -t on my hdd's and both are on the same channel. This is much better than i ever got with 2.4 even when only one drive was on a channel. Right now my k7-2 750 is at 849mhz with a FSB of 114Mhz and PCI at 34Mhz. my nbench performance under 2.2 is comparable to results for 1Ghz t-bird's so i'm happy with 2.2. The only thing that would make me want to upgrade would be latency patches. I'm convinced 2.4 has performance issues so i guess i'll be using 2.2 until 2.5 begins. Is it really only 1 or 2 people having this Via corruption problem? i doubt it's a bios problem because wouldn't 2.2 be effected by a bios bug if 2.4 is? In either case the changelogs dont show any fixes for it. If your FSB is running at 114 MHz, you should try the kernel parameter idebus=37 to get DMA working correctly. Otherwise you'll see an ide-reset error on bootup because the instructions are too fast. The VIA driver on 2.2 doesn't correctly program the PCI card, so you don't see weird behavior running 2.2 with a faster PCI clock. (Note: 1.14 * 33 = 37.6 PCI Clk) It's 38: 114 / 3 == 38 == 1.14 * 33.33 But definitely it isn't 34 or the default 33. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wednesday, 31 January 2001, at 08:36:42 (+0100),
Vojtech Pavlik wrote:
> Hi!
>
> 1) You don't seem to have any drives on the VIA controller. If this is
> true, I don't think this can be a VIA IDE driver problem.
>
Hi, Are you referring to Mark or me?
I have drives on my VIA (only..) IDE controller:
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: Maxtor 51536H2, ATA DISK drive
hdb: Maxtor 94098U8, ATA DISK drive
hdc: CD-ROM 52X/AKH, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(66)
hdc: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
hda: hda1 hda2
hdb: hdb1
> 2) In your original message you suggest bs=1024M, which isn't a very
> good idea, even on a 768 MB system. Here with bs=1024k it seems to run
> fine.
>
> 3) You sent next to none VIA related debugging info. lspci -v itself
> isn't much valuable because I don't get the register contents. Also
> hdparm -i of the drives attached to the VIA chip would be useful. Plus
> also the contents of /proc/ide/via.
I didn't supply anything either, even though my configuration works great it
might prove useful to someone comparing:
bash-2.04# hdparm -i /dev/hda
/dev/hda:
Model=Maxtor 51536H2, FwRev=JAC61HU0, SerialNo=F203VTHC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=30015216
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
bash-2.04# hdparm -i /dev/hdb
/dev/hdb:
Model=Maxtor 94098U8, FwRev=FA500S60, SerialNo=G8066RQC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=80041248
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
bash-2.04#
bash-2.04# cat /proc/ide/via
--VIA BusMastering IDE Configuration
Driver Version: 2.1e
South Bridge: VIA vt82c686a rev 0x22
Command register: 0x7
Latency timer: 32
PCI clock: 33MHz
Master Read Cycle IRDY:0ws
Master Write Cycle IRDY:0ws
FIFO Output Data 1/2 Clock Advance: off
BM IDE Status Register Read Retry: on
Max DRDY Pulse Width: No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush: on on
End Sect. FIFO flush: on on
Prefetch Buffer: on on
Post Write Buffer: on on
FIFO size: 8 8
Threshold Prim.: 1/2 1/2
Bytes Per Sector: 512 512
Both channels togth: yes yes
---drive0drive1drive2drive3-
BMDMA enabled:yes yes yesno
Transfer Mode: UDMA UDMA UDMA DMA/PIO
Address Setup: 30ns 30ns 30ns 120ns
Active Pulse:90ns 90ns 90ns 330ns
Recovery Time: 30ns 30ns 30ns 270ns
Cycle Time: 30ns 30ns 60ns 600ns
Transfer Rate: 66.0MB/s 66.0MB/s 33.0MB/s 3.3MB/s
bash-2.04# lspci -v (trimmed)
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
Flags: bus master, medium devsel, latency 8
Memory at e000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00
[Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 9000-9fff
Memory behind bridge: dde0-dfef
Prefetchable memory behind bridge: cdc0-ddcf
Capabilities: [80] Power Management version 2
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
Re: VT82C686A corruption with 2.4.x
Hi! 1) You don't seem to have any drives on the VIA controller. If this is true, I don't think this can be a VIA IDE driver problem. 2) In your original message you suggest bs=1024M, which isn't a very good idea, even on a 768 MB system. Here with bs=1024k it seems to run fine. 3) You sent next to none VIA related debugging info. lspci -v itself isn't much valuable because I don't get the register contents. Also hdparm -i of the drives attached to the VIA chip would be useful. Plus also the contents of /proc/ide/via. 4) Did you check the problem you're experiencing isn't a memory problem? That'd go away with removing some RAM. Vojtech PS. I'm not sure how wise is to use both ACPI and APM at once. Well, I never used either in a server environment - I don't think it makes much sense. PPS. What should I do with a ksyms dump of the Advansys SCSI and a Tulip NIC drivers? It isn't related anyhow. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
OK, just completed the upgrade to 2.4.1-pre12 + via82c.diff. SYSTEM SPECS CHANGES === Shut off ACPI Shut off 2nd IDE controller in BIOS Shut off APM Disabled UDMA support in BIOS Removed 256MB RAM (768M total RAM) * Everything is running stabler now. Here's what I've got set up right now. VIA SUPPORT 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 9000-9fff Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d9ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at a000 Capabilities: [c0] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ac00 I/O ports at b000 I/O ports at b400 I/O ports at b800 I/O ports at bc00 Memory at db00 (32-bit, non-prefetchable) Capabilities: [58] Power Management version 1 00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW Flags: bus master, medium devsel, latency 32, IRQ 15 I/O ports at c000 Memory at db02 (32-bit, non-prefetchable) 00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at c400 Memory at db021000 (32-bit, non-prefetchable) 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA]) Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP Flags: 66Mhz, fast devsel Memory at d400 (32-bit, non-prefetchable) Memory at d800 (32-bit, prefetchable) I/O ports at 9000 Capabilities: [54] AGP version 1.0 Capabilities: [60] Power Management version 1 PROMISE SUPPORT === PDC20265: IDE controller on PCI bus 00 dev 60 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. DMESG - VIA == PCI: Using IRQ router VIA [1106/0686] at 00:07.0 System Vendor: VIA Technologies, Inc.. VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB DD TESTING == [root@timberwolf /root]# dd if=/dev/hda7 of=/tmp/testing.img bs=1024k count=20002000+0 records in 2000+0 records out [root@timberwolf /root]# ls -al /tmp/testing.img -rw-r--r--1 root root 2097152000 Jan 29 17:54 /tmp/testing.img [root@timberwolf /root]# ls -alh /tmp/testing.img -rw-r--r--1 root root 2.0G Jan 29 17:54 /tmp/testing.img [root@timberwolf /root]# I'm also attaching a ksyms dump. David D.W. Downey Address SymbolDefined by f286a060 advansys_proc_info[advansys] f286a060 __insmod_advansys_S.text_L60896 [advansys] f286caf0 advansys_reset[advansys] f286c770 advansys_abort[advansys] f286c660 advansys_command [advansys] f286a58c advansys_detect [advansys] f286d084 advansys_biosparam[advansys] f287b0e0 __insmod_advansys_S.data_L15488 [advansys] f287ef00 __insmod_advansys_S.bss_L128 [advansys] f2878e60 __insmod_advansys_S.rodata_L8808 [advansys] f286c350 advansys_release [advansys] f286c698 advansys_queuecommand [advansys] f286a000 __insmod_advansys_O/lib/modules/2.4.1-pre12/kernel/drivers/scsi/advansys.o_M3A761A3A_V132097 [advansys] f286c444 advansys_info [advansys] f286d10c advansys_setup
Re: VT82C686A corruption with 2.4.x
OK, here is the output of lspci -v on the SMP box I'm having trouble with as requested... 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 9000-9fff Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d9ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at a000 Capabilities: [c0] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ac00 I/O ports at b000 I/O ports at b400 I/O ports at b800 I/O ports at bc00 Memory at db00 (32-bit, non-prefetchable) Capabilities: [58] Power Management version 1 00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW Flags: bus master, medium devsel, latency 32, IRQ 15 I/O ports at c000 Memory at db02 (32-bit, non-prefetchable) 00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at c400 Memory at db021000 (32-bit, non-prefetchable) 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA]) Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP Flags: 66Mhz, fast devsel Memory at d400 (32-bit, non-prefetchable) Memory at d800 (32-bit, prefetchable) I/O ports at 9000 Capabilities: [54] AGP version 1.0 Capabilities: [60] Power Management version 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
bash-2.04# dmesg | grep -i udma VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1 hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66) hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(66) hdc: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33) bash-2.04# uname -a Linux prototype 2.4.1 #1 Tue Jan 30 01:45:38 PST 2001 i686 unknown bash-2.04# df -h FilesystemSize Used Avail Use% Mounted on /dev/hda2 14G 3.7G 10G 26% / /dev/hdb1 38G 20G 19G 51% /storage I dunno what you wanted to do by: > dd if=/dev/hda4 of=/tmp/testing.img bs=1024M count=2k Becuase it won't read 1024M into memory at once, says memory exhausted.. So I did.. bash-2.04# cd /storage bash-2.04# dd if=/dev/hda2 of=testing.img bs=1024k count=2000 2000+0 records in 2000+0 records out bash-2.04# ls -sh testing.img 2.0G testing.img bash-2.04# No problems here (nothing in dmesg, no crashing..) Course interactivity in X was total shit while dd was running =\. On Tuesday, 30 January 2001, at 11:51:58 (-0800), David D.W. Downey wrote: > > Actually what rumors are you hearing? > > Right now I can tell you from personal experience that the VIA VT82C686A > chipset is causing kernel deaths, corrupted data on my drives, and UDMA > issues (meaning that when I enable the UDMA support the kernel > CONSISTENTLY crashes.) > > This is all pre patch-2.4.1-pre11. I've not tested the new patch as of yet > as I was in a car accident and have not felt well enough to mess with > things. I will however be testing the new patch in about a half hour. The > test bed will be the SMP box I've been talking about on the list, Red Hat > 7.0 (only one that will install on the machine without dying instantly > during installation) and using the KGCC rather than the GCC that comes > with RH7. > > Supposedly there are a couple of other patches available to add as well, > but I'm not sure where they are exactly. I just downloaded the patch that > Voj gave (v3.20) for the VIA chipsets. > > > Nicholas, give me a bit and I'll let you know what's going on with my > tests here. I can consistently get the current kernel to die simply by > running > > dd if=/dev/hda4 of=/tmp/testing.img bs=1024M count=2k > > > TRy this on your box with the patch-2.4.1-pre11 added to the kernel source > and let me know what you get. Maybe we can work on this together. > > > David D.W. Downey > -- David Raufeisen <[EMAIL PROTECTED]> Cell: (604) 818-3596 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Actually what rumors are you hearing? Right now I can tell you from personal experience that the VIA VT82C686A chipset is causing kernel deaths, corrupted data on my drives, and UDMA issues (meaning that when I enable the UDMA support the kernel CONSISTENTLY crashes.) This is all pre patch-2.4.1-pre11. I've not tested the new patch as of yet as I was in a car accident and have not felt well enough to mess with things. I will however be testing the new patch in about a half hour. The test bed will be the SMP box I've been talking about on the list, Red Hat 7.0 (only one that will install on the machine without dying instantly during installation) and using the KGCC rather than the GCC that comes with RH7. Supposedly there are a couple of other patches available to add as well, but I'm not sure where they are exactly. I just downloaded the patch that Voj gave (v3.20) for the VIA chipsets. Nicholas, give me a bit and I'll let you know what's going on with my tests here. I can consistently get the current kernel to die simply by running dd if=/dev/hda4 of=/tmp/testing.img bs=1024M count=2k TRy this on your box with the patch-2.4.1-pre11 added to the kernel source and let me know what you get. Maybe we can work on this together. David D.W. Downey On Tue, 30 Jan 2001, Tobias Ringstrom wrote: > So you have not seen any corruption, but are willing to do testing. Very > kind, but you could have choosen a better subject, I think. There are a > lot more rumours that facts regarding the VIA drivers right now. > > /Tobias > > > On Tue, 30 Jan 2001, Nicholas Knight wrote: > > > I have a Soyo K7VIA motherboard which uses VT82C686A, with an 800mhz Athlon > > CPU in it. > > So far I've never run a 2.3* or 2.4* kernel on it, I've only done that on my > > P3 using a propriatory micron motherboard that uses an intel BX2 chipset. > > However, I recently trashed my linux installation (doing things totaly > > unrelated to the kernel) and now would be more than happy to assist in > > trying to figure out what the heck is causing the filesystem corruption on > > VIA chipsets, but so far I've only found bits and peices of information on > > it, and have been unable to locate a compiliation of information avalible on > > the problem, so I'd know just where to start. > > If anyone could point me to a good place to start looking, besides the > > thousands of messages containing just bits and peices of information, I > > could get to work on some testing. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
So you have not seen any corruption, but are willing to do testing. Very kind, but you could have choosen a better subject, I think. There are a lot more rumours that facts regarding the VIA drivers right now. /Tobias On Tue, 30 Jan 2001, Nicholas Knight wrote: > I have a Soyo K7VIA motherboard which uses VT82C686A, with an 800mhz Athlon > CPU in it. > So far I've never run a 2.3* or 2.4* kernel on it, I've only done that on my > P3 using a propriatory micron motherboard that uses an intel BX2 chipset. > However, I recently trashed my linux installation (doing things totaly > unrelated to the kernel) and now would be more than happy to assist in > trying to figure out what the heck is causing the filesystem corruption on > VIA chipsets, but so far I've only found bits and peices of information on > it, and have been unable to locate a compiliation of information avalible on > the problem, so I'd know just where to start. > If anyone could point me to a good place to start looking, besides the > thousands of messages containing just bits and peices of information, I > could get to work on some testing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
VT82C686A corruption with 2.4.x
I have a Soyo K7VIA motherboard which uses VT82C686A, with an 800mhz Athlon CPU in it. So far I've never run a 2.3* or 2.4* kernel on it, I've only done that on my P3 using a propriatory micron motherboard that uses an intel BX2 chipset. However, I recently trashed my linux installation (doing things totaly unrelated to the kernel) and now would be more than happy to assist in trying to figure out what the heck is causing the filesystem corruption on VIA chipsets, but so far I've only found bits and peices of information on it, and have been unable to locate a compiliation of information avalible on the problem, so I'd know just where to start. If anyone could point me to a good place to start looking, besides the thousands of messages containing just bits and peices of information, I could get to work on some testing. -NK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
VT82C686A corruption with 2.4.x
I have a Soyo K7VIA motherboard which uses VT82C686A, with an 800mhz Athlon CPU in it. So far I've never run a 2.3* or 2.4* kernel on it, I've only done that on my P3 using a propriatory micron motherboard that uses an intel BX2 chipset. However, I recently trashed my linux installation (doing things totaly unrelated to the kernel) and now would be more than happy to assist in trying to figure out what the heck is causing the filesystem corruption on VIA chipsets, but so far I've only found bits and peices of information on it, and have been unable to locate a compiliation of information avalible on the problem, so I'd know just where to start. If anyone could point me to a good place to start looking, besides the thousands of messages containing just bits and peices of information, I could get to work on some testing. -NK - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
So you have not seen any corruption, but are willing to do testing. Very kind, but you could have choosen a better subject, I think. There are a lot more rumours that facts regarding the VIA drivers right now. /Tobias On Tue, 30 Jan 2001, Nicholas Knight wrote: I have a Soyo K7VIA motherboard which uses VT82C686A, with an 800mhz Athlon CPU in it. So far I've never run a 2.3* or 2.4* kernel on it, I've only done that on my P3 using a propriatory micron motherboard that uses an intel BX2 chipset. However, I recently trashed my linux installation (doing things totaly unrelated to the kernel) and now would be more than happy to assist in trying to figure out what the heck is causing the filesystem corruption on VIA chipsets, but so far I've only found bits and peices of information on it, and have been unable to locate a compiliation of information avalible on the problem, so I'd know just where to start. If anyone could point me to a good place to start looking, besides the thousands of messages containing just bits and peices of information, I could get to work on some testing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
Actually what rumors are you hearing? Right now I can tell you from personal experience that the VIA VT82C686A chipset is causing kernel deaths, corrupted data on my drives, and UDMA issues (meaning that when I enable the UDMA support the kernel CONSISTENTLY crashes.) This is all pre patch-2.4.1-pre11. I've not tested the new patch as of yet as I was in a car accident and have not felt well enough to mess with things. I will however be testing the new patch in about a half hour. The test bed will be the SMP box I've been talking about on the list, Red Hat 7.0 (only one that will install on the machine without dying instantly during installation) and using the KGCC rather than the GCC that comes with RH7. Supposedly there are a couple of other patches available to add as well, but I'm not sure where they are exactly. I just downloaded the patch that Voj gave (v3.20) for the VIA chipsets. Nicholas, give me a bit and I'll let you know what's going on with my tests here. I can consistently get the current kernel to die simply by running dd if=/dev/hda4 of=/tmp/testing.img bs=1024M count=2k TRy this on your box with the patch-2.4.1-pre11 added to the kernel source and let me know what you get. Maybe we can work on this together. David D.W. Downey On Tue, 30 Jan 2001, Tobias Ringstrom wrote: So you have not seen any corruption, but are willing to do testing. Very kind, but you could have choosen a better subject, I think. There are a lot more rumours that facts regarding the VIA drivers right now. /Tobias On Tue, 30 Jan 2001, Nicholas Knight wrote: I have a Soyo K7VIA motherboard which uses VT82C686A, with an 800mhz Athlon CPU in it. So far I've never run a 2.3* or 2.4* kernel on it, I've only done that on my P3 using a propriatory micron motherboard that uses an intel BX2 chipset. However, I recently trashed my linux installation (doing things totaly unrelated to the kernel) and now would be more than happy to assist in trying to figure out what the heck is causing the filesystem corruption on VIA chipsets, but so far I've only found bits and peices of information on it, and have been unable to locate a compiliation of information avalible on the problem, so I'd know just where to start. If anyone could point me to a good place to start looking, besides the thousands of messages containing just bits and peices of information, I could get to work on some testing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
bash-2.04# dmesg | grep -i udma VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1 hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66) hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(66) hdc: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33) bash-2.04# uname -a Linux prototype 2.4.1 #1 Tue Jan 30 01:45:38 PST 2001 i686 unknown bash-2.04# df -h FilesystemSize Used Avail Use% Mounted on /dev/hda2 14G 3.7G 10G 26% / /dev/hdb1 38G 20G 19G 51% /storage I dunno what you wanted to do by: dd if=/dev/hda4 of=/tmp/testing.img bs=1024M count=2k Becuase it won't read 1024M into memory at once, says memory exhausted.. So I did.. bash-2.04# cd /storage bash-2.04# dd if=/dev/hda2 of=testing.img bs=1024k count=2000 2000+0 records in 2000+0 records out bash-2.04# ls -sh testing.img 2.0G testing.img bash-2.04# No problems here (nothing in dmesg, no crashing..) Course interactivity in X was total shit while dd was running =\. On Tuesday, 30 January 2001, at 11:51:58 (-0800), David D.W. Downey wrote: Actually what rumors are you hearing? Right now I can tell you from personal experience that the VIA VT82C686A chipset is causing kernel deaths, corrupted data on my drives, and UDMA issues (meaning that when I enable the UDMA support the kernel CONSISTENTLY crashes.) This is all pre patch-2.4.1-pre11. I've not tested the new patch as of yet as I was in a car accident and have not felt well enough to mess with things. I will however be testing the new patch in about a half hour. The test bed will be the SMP box I've been talking about on the list, Red Hat 7.0 (only one that will install on the machine without dying instantly during installation) and using the KGCC rather than the GCC that comes with RH7. Supposedly there are a couple of other patches available to add as well, but I'm not sure where they are exactly. I just downloaded the patch that Voj gave (v3.20) for the VIA chipsets. Nicholas, give me a bit and I'll let you know what's going on with my tests here. I can consistently get the current kernel to die simply by running dd if=/dev/hda4 of=/tmp/testing.img bs=1024M count=2k TRy this on your box with the patch-2.4.1-pre11 added to the kernel source and let me know what you get. Maybe we can work on this together. David D.W. Downey -- David Raufeisen [EMAIL PROTECTED] Cell: (604) 818-3596 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
OK, here is the output of lspci -v on the SMP box I'm having trouble with as requested... 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 9000-9fff Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d9ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at a000 Capabilities: [c0] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ac00 I/O ports at b000 I/O ports at b400 I/O ports at b800 I/O ports at bc00 Memory at db00 (32-bit, non-prefetchable) Capabilities: [58] Power Management version 1 00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW Flags: bus master, medium devsel, latency 32, IRQ 15 I/O ports at c000 Memory at db02 (32-bit, non-prefetchable) 00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at c400 Memory at db021000 (32-bit, non-prefetchable) 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA]) Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP Flags: 66Mhz, fast devsel Memory at d400 (32-bit, non-prefetchable) Memory at d800 (32-bit, prefetchable) I/O ports at 9000 Capabilities: [54] AGP version 1.0 Capabilities: [60] Power Management version 1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
OK, just completed the upgrade to 2.4.1-pre12 + via82c.diff. SYSTEM SPECS CHANGES === Shut off ACPI Shut off 2nd IDE controller in BIOS Shut off APM Disabled UDMA support in BIOS Removed 256MB RAM (768M total RAM) * Everything is running stabler now. Here's what I've got set up right now. VIA SUPPORT 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Flags: bus master, medium devsel, latency 0 Memory at d000 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 9000-9fff Memory behind bridge: d400-d7ff Prefetchable memory behind bridge: d800-d9ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at a000 Capabilities: [c0] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 00:0c.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 0d30 (rev 02) Subsystem: Promise Technology, Inc.: Unknown device 4d33 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ac00 I/O ports at b000 I/O ports at b400 I/O ports at b800 I/O ports at bc00 Memory at db00 (32-bit, non-prefetchable) Capabilities: [58] Power Management version 1 00:0e.0 SCSI storage controller: Advanced System Products, Inc ABP940-UW Flags: bus master, medium devsel, latency 32, IRQ 15 I/O ports at c000 Memory at db02 (32-bit, non-prefetchable) 00:10.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20) Subsystem: Netgear FA310TX Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at c400 Memory at db021000 (32-bit, non-prefetchable) 01:00.0 VGA compatible controller: 3Dfx Interactive, Inc. Voodoo 3 (rev 01) (prog-if 00 [VGA]) Subsystem: 3Dfx Interactive, Inc. Voodoo3 AGP Flags: 66Mhz, fast devsel Memory at d400 (32-bit, non-prefetchable) Memory at d800 (32-bit, prefetchable) I/O ports at 9000 Capabilities: [54] AGP version 1.0 Capabilities: [60] Power Management version 1 PROMISE SUPPORT === PDC20265: IDE controller on PCI bus 00 dev 60 PDC20265: chipset revision 2 PDC20265: not 100% native mode: will probe irqs later PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode. DMESG - VIA == PCI: Using IRQ router VIA [1106/0686] at 00:07.0 System Vendor: VIA Technologies, Inc.. VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1 [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB [drm] AGP 0.99 on VIA Apollo Pro @ 0xd000 64MB DD TESTING == [root@timberwolf /root]# dd if=/dev/hda7 of=/tmp/testing.img bs=1024k count=20002000+0 records in 2000+0 records out [root@timberwolf /root]# ls -al /tmp/testing.img -rw-r--r--1 root root 2097152000 Jan 29 17:54 /tmp/testing.img [root@timberwolf /root]# ls -alh /tmp/testing.img -rw-r--r--1 root root 2.0G Jan 29 17:54 /tmp/testing.img [root@timberwolf /root]# I'm also attaching a ksyms dump. David D.W. Downey Address SymbolDefined by f286a060 advansys_proc_info[advansys] f286a060 __insmod_advansys_S.text_L60896 [advansys] f286caf0 advansys_reset[advansys] f286c770 advansys_abort[advansys] f286c660 advansys_command [advansys] f286a58c advansys_detect [advansys] f286d084 advansys_biosparam[advansys] f287b0e0 __insmod_advansys_S.data_L15488 [advansys] f287ef00 __insmod_advansys_S.bss_L128 [advansys] f2878e60 __insmod_advansys_S.rodata_L8808 [advansys] f286c350 advansys_release [advansys] f286c698 advansys_queuecommand [advansys] f286a000 __insmod_advansys_O/lib/modules/2.4.1-pre12/kernel/drivers/scsi/advansys.o_M3A761A3A_V132097 [advansys] f286c444 advansys_info [advansys] f286d10c advansys_setup
Re: VT82C686A corruption with 2.4.x
Hi! 1) You don't seem to have any drives on the VIA controller. If this is true, I don't think this can be a VIA IDE driver problem. 2) In your original message you suggest bs=1024M, which isn't a very good idea, even on a 768 MB system. Here with bs=1024k it seems to run fine. 3) You sent next to none VIA related debugging info. lspci -v itself isn't much valuable because I don't get the register contents. Also hdparm -i of the drives attached to the VIA chip would be useful. Plus also the contents of /proc/ide/via. 4) Did you check the problem you're experiencing isn't a memory problem? That'd go away with removing some RAM. Vojtech PS. I'm not sure how wise is to use both ACPI and APM at once. Well, I never used either in a server environment - I don't think it makes much sense. PPS. What should I do with a ksyms dump of the Advansys SCSI and a Tulip NIC drivers? It isn't related anyhow. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: VT82C686A corruption with 2.4.x
On Wednesday, 31 January 2001, at 08:36:42 (+0100),
Vojtech Pavlik wrote:
Hi!
1) You don't seem to have any drives on the VIA controller. If this is
true, I don't think this can be a VIA IDE driver problem.
Hi, Are you referring to Mark or me?
I have drives on my VIA (only..) IDE controller:
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a IDE UDMA66 controller on pci0:7.1
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
VP_IDE: ATA-66/100 forced bit set (WARNING)!!
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:DMA, hdd:pio
hda: Maxtor 51536H2, ATA DISK drive
hdb: Maxtor 94098U8, ATA DISK drive
hdc: CD-ROM 52X/AKH, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 30015216 sectors (15368 MB) w/2048KiB Cache, CHS=1868/255/63, UDMA(66)
hdb: 80041248 sectors (40981 MB) w/2048KiB Cache, CHS=4982/255/63, UDMA(66)
hdc: ATAPI 52X CD-ROM drive, 192kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
hda: hda1 hda2
hdb: hdb1
2) In your original message you suggest bs=1024M, which isn't a very
good idea, even on a 768 MB system. Here with bs=1024k it seems to run
fine.
3) You sent next to none VIA related debugging info. lspci -v itself
isn't much valuable because I don't get the register contents. Also
hdparm -i of the drives attached to the VIA chip would be useful. Plus
also the contents of /proc/ide/via.
I didn't supply anything either, even though my configuration works great it
might prove useful to someone comparing:
bash-2.04# hdparm -i /dev/hda
/dev/hda:
Model=Maxtor 51536H2, FwRev=JAC61HU0, SerialNo=F203VTHC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=30015216
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4 udma5
bash-2.04# hdparm -i /dev/hdb
/dev/hdb:
Model=Maxtor 94098U8, FwRev=FA500S60, SerialNo=G8066RQC
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=80041248
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
bash-2.04#
bash-2.04# cat /proc/ide/via
--VIA BusMastering IDE Configuration
Driver Version: 2.1e
South Bridge: VIA vt82c686a rev 0x22
Command register: 0x7
Latency timer: 32
PCI clock: 33MHz
Master Read Cycle IRDY:0ws
Master Write Cycle IRDY:0ws
FIFO Output Data 1/2 Clock Advance: off
BM IDE Status Register Read Retry: on
Max DRDY Pulse Width: No limit
---Primary IDE---Secondary IDE--
Read DMA FIFO flush: on on
End Sect. FIFO flush: on on
Prefetch Buffer: on on
Post Write Buffer: on on
FIFO size: 8 8
Threshold Prim.: 1/2 1/2
Bytes Per Sector: 512 512
Both channels togth: yes yes
---drive0drive1drive2drive3-
BMDMA enabled:yes yes yesno
Transfer Mode: UDMA UDMA UDMA DMA/PIO
Address Setup: 30ns 30ns 30ns 120ns
Active Pulse:90ns 90ns 90ns 330ns
Recovery Time: 30ns 30ns 30ns 270ns
Cycle Time: 30ns 30ns 60ns 600ns
Transfer Rate: 66.0MB/s 66.0MB/s 33.0MB/s 3.3MB/s
bash-2.04# lspci -v (trimmed)
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
Flags: bus master, medium devsel, latency 8
Memory at e000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 2.0
Capabilities: [c0] Power Management version 2
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00
[Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 9000-9fff
Memory behind bridge: dde0-dfef
Prefetchable memory behind bridge: cdc0-ddcf
Capabilities: [80] Power Management version 2
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
Subsystem:
