VIA comments on the bugs
The colleagues from Heise Online had the opportunity at Computex to talk to Wen Chi Chen, VIA's Marketing Director Eric Chang and press spokesman Richard Brown about the well-discussed 686B problem.
There are quite interesting points came to light:
According to Chang, the 686B bug, which he continued to call 'compatibility problem', is in Gaps in the PCI specification justified. In modern systems, says Chang, a number of fast and bandwidth-hungry devices were fighting for the PCI bus. This creates conflicts in bus arbitration that nobody thought of when the PCI standards were drafted. Every manufacturer of PCI devices and chipsets has to develop its own strategies for tasks such as assigning priority, because the PCI bus is not completely up to the requirements of modern hardware. Problems arose again and again, which in the best case only meant a loss of performance, but in the worst case led to crashes and data loss.
'There is no general solution for these conflicts,' said Chang. Each individual case must be examined and resolved individually. Especially with the 686B bug, changing the prioritization on the PCI helps: With a lot of traffic, the processor usually has to wait three bus master requests before it can access it again. If bus masters occupy the PCI bus for too long, however, this seems to lead to a buffer overflow and ultimately to data loss in the south bridge. According to Chang, this can be remedied by only allowing two instead of three bus master requests. However, this setting is not suitable as a general solution because it can hinder the isochronous data transfer on the PCI bus. Isochronous transfers require a guaranteed minimum bandwidth, for example for audio or video streams. A shortfall is particularly evident in the case of audio datanoticeable through crackling.
In general, the chipset manufacturer is not to blame, it's just strange that there are no such problems with other chipsets. As VIA also announced, they are currently working on diagnostic software to trigger the internal revision number of the Northbridge and thus to identify the affected chips via software.