This was NOT ment as a crusade against VIA, but a warning against a particular Motherboard/chipset combination: A7V266E+KT266A. Actually, it specifically happens when you copy a few BG of files (each about 16MB) from an SGI machine running IRIX64 to the A7V266E+KT266A running LM 8.2, and it happens every time. It happens with the 2.4.8 kernel as well as with the 2.4.18 kernel. We could not test the 2.2.19 kernel as we use the xfs file system. It crashed both by transferring data via NFS and FTP.
The problem is this specific combination: SGI/IRIX64 <-> A7V266E/LM8.2 Actually, it also crashed with RH7.2 and LM8.1. I do not know for sure if this is a VIA problem. It could be some other component on the ASUS A7V266E. But at this point I have really lost interest in finding the exact location on the board. All we wanted to know was if we should get a new type of board or another Linux distribution! Thank you for your response. -- Bjarne On Fri, 2002-05-10 at 10:22, civileme wrote: > Udo Rader wrote: > > >This crusade against VIA is ridiculous to me. > > > >Here at work we have about 25 computers working around, some of them are > >under very heavy duty as database servers or even worse as parts of a > >cluster. Approximately half of them is VIA based, even my workstation > >that I'm writing this is based on a soyo dragon-raid plus mobo (VIA > >KT266). > > > >And we've had no - I repeat: NO - problems so far that could be directly > >linked to the chipset. But I remember a couple of other things that made > >our life hard: bad compilers (gcc 2.96, aka garbagecc), broken memory, > >malfunctioning harddrives - but that was **never** related to VIA in any > >reasonable way. > > > >And if you come around and say that even VIA has a path for the IDE > >driver in the kernel to work around some problems, you are simply wrong: > >This patch soley enables UDMA133 on some chipsets because the > >modifications did not make it yet into the current *STABLE* kernel > >(guess why???). > > > >... had to say this ... > > > >udo > > > Ummm, I would never be one to single out VIA. There have been real bugs > in _ALL_ the chipsets around. How much of those you see depends on > where in the arms race you pick out a kernel, in most cases. > > The VIA 686B southbridge had a problem which caused cross-channel IDE > DMAs to provide _massive_ corruption on transfers of more than 100Mb, > but a workaround was found and put into the kernel. > > The KT266A and current ALi Chipsets have broken clocks. Under heavy > loads, spurious clock pulses can play hell with UDMA transfers. A > temporary fix would be to depress the priority of the clock interrupt > using irqtune, but then dispatching would be adversely affected. Yes, > under certain circumstances (software RAID with journaling filesystem > and heavy load) these chipsets with the broken clocks show data > corruption, really. > > SiS and Intel are not free of problems either. Just right now those are > covered by kernel workarounds, mostly. Some workarounds have to be > invoked, separately, as is the case with K6-2 and SiS 530 chipsets which > perform much better under "nopentium" installs and boots. There is a > serious break for agpgart for some i815 implementations... You pays > your money and you takes your chances; when has it been different? > > I used to hate certain brands of Motherboard and love others, but while > I was busy avoiding the ones I hated, some of them became good and > reliable, while those I thought were great acquired new owners who were > determined to cash in on the reputations of the previous owners's > fanaticism for quality. > > There are no constants in this industry. Things are moving too fast. > Knowledge overall is doubling every 6 years or less, and in the > computing industry it is quite a bit faster than that (remember > processor speed is doubling every 18 months, for example). The people > in good odor today may smell of the sewer tomorrow, depending on whether > the techs or the marketeers are in control of their company. > > Civileme > > > Of course, some companies still seem to survive on corner-cut products > after years and years of the practice. You can tell of them by the > smoothness and courtesy with which they treat any customer with a > complaint--they invested their money in massaging disgruntled customers > rather than doing the product right and with consistently high quality. > When I call in with a complaint and don't meet a harassed staff but > rather a smooth approach , I become very afraid. > > > > The "patch" for this is to give the ISR for clock a very low priority, > but that tends to slow the system by interfering with dispatching > > > > > > > > ---- > > Want to buy your Pack or Services from MandrakeSoft? > Go to http://www.mandrakestore.com
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
