[VIA Support] Instruction timing and cache coherency issues

[VIA Support] Instruction timing and cache coherency issues

[Michael S. Zick]

Started back in mid-May - long time and a lot of hours later...

As suggested very early in this examination by others -
It is a timing issue.  My inserting "lock" for config_mviac7
was just poking at the edges of the sore spot.  ;)

The "break through" came yesterday while running (or trying to run)
FreeBSD-8.0-beta2 on the various machines at hand. . .

Depending on the cpu model variation and the integrated chipset
used with that cpu - -
*) FB-8.0 will run
*) FB-8.0 will only run in "safe mode"
*) FB-8.0 panics

And that pattern is similar to the 2.6.30 cpu model / chipset pattern.
Scratches head, asking: "now how can that be" with two very different OS designs.

Diddling with the things I have found that either "fix" or "work around"
the various timing / cache coherency issues - - -
Aw, so - found how to affect the timing issues sufficiently so that Linux
would panic dump rather than deadlock on the troublesum combination - -
*Functionally the same* panic backtrace that FreeBSD is showing.

NOW I have a lead into making a "minimum invasive" change so that the 
kernel is happy - even on the flaky VIA combinations.  Patch RSN, just any month.
The FreeBSD project can fix their problems themselves.  ;)

@H.W.  Download the FreeBSD-8.0-beta2 and try running it on your Cloudbook and HP-2133,
you can see what is happening.  Then you might have a word or two with the silicon growers.

Mike

Re: [VIA Support] Instruction timing and cache coherency issues

[Pavel Machek]

Hi!

> Started back in mid-May - long time and a lot of hours later...
> 
> As suggested very early in this examination by others -
> It is a timing issue.  My inserting "lock" for config_mviac7
> was just poking at the edges of the sore spot.  ;)
> 
> The "break through" came yesterday while running (or trying to run)
> FreeBSD-8.0-beta2 on the various machines at hand. . .
> 
> Depending on the cpu model variation and the integrated chipset
> used with that cpu - -
> *) FB-8.0 will run
> *) FB-8.0 will only run in "safe mode"
> *) FB-8.0 panics
> 
> And that pattern is similar to the 2.6.30 cpu model / chipset pattern.
> Scratches head, asking: "now how can that be" with two very different OS designs.
> 
> Diddling with the things I have found that either "fix" or "work around"
> the various timing / cache coherency issues - - -
> Aw, so - found how to affect the timing issues sufficiently so that Linux
> would panic dump rather than deadlock on the troublesum combination - -
> *Functionally the same* panic backtrace that FreeBSD is showing.
> 
> NOW I have a lead into making a "minimum invasive" change so that the 
> kernel is happy - even on the flaky VIA combinations.  Patch RSN, just any month.
> The FreeBSD project can fix their problems themselves.  ;)
> 
> @H.W.  Download the FreeBSD-8.0-beta2 and try running it on your Cloudbook and HP-2133,
> you can see what is happening.  Then you might have a word or two with the silicon growers.
> 

So... you believe you have pinpointed bug in their cpu design?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [VIA Support] Instruction timing and cache coherency issues

[Harald Welte]

On Thu, Jul 30, 2009 at 11:08:04AM +0200, Pavel Machek wrote:

> > Diddling with the things I have found that either "fix" or "work around"
> > the various timing / cache coherency issues - - -
> > Aw, so - found how to affect the timing issues sufficiently so that Linux
> > would panic dump rather than deadlock on the troublesum combination - -
> > *Functionally the same* panic backtrace that FreeBSD is showing.
> > 
> > @H.W.  Download the FreeBSD-8.0-beta2 and try running it on your Cloudbook
> > and HP-2133, you can see what is happening.  Then you might have a word or
> > two with the silicon growers.
> > 
> So... you believe you have pinpointed bug in their cpu design?

I would not preclude that, but I think what might be more likely is that there
is some difference between how Intel and how VIA/Centaur behaves in a certain
situation, or the compiler making a wrong assumption about what it can do or
cannot do (remember e.g. for the VIA C3 there was no cmpxchg8, but gcc uses
it in case you compile with i686 optiomization).

I have not yet tried FreeBSD 8 on the cloudbook, but expect to have time during
the next days.  However, since I am not familiar with the FreeBSD kernel
architecture, I would definitely prefer something where I can reproduce the
problem on Linux.

Michael has indicated that he can now crash (oops) the kernel rather than deadlock.
With which kernel is that?  I would love to give that one a try.

-- 
- Harald Welte <HaraldWelte@viatech.com>	    http://linux.via.com.tw/
============================================================================
VIA Free and Open Source Software Liaison

Re: [VIA Support] Instruction timing and cache coherency issues

[Pavel Machek]

On Sun 2009-08-02 21:08:51, Harald Welte wrote:
> On Thu, Jul 30, 2009 at 11:08:04AM +0200, Pavel Machek wrote:
> 
> > > Diddling with the things I have found that either "fix" or "work around"
> > > the various timing / cache coherency issues - - -
> > > Aw, so - found how to affect the timing issues sufficiently so that Linux
> > > would panic dump rather than deadlock on the troublesum combination - -
> > > *Functionally the same* panic backtrace that FreeBSD is showing.
> > > 
> > > @H.W.  Download the FreeBSD-8.0-beta2 and try running it on your Cloudbook
> > > and HP-2133, you can see what is happening.  Then you might have a word or
> > > two with the silicon growers.
> > > 
> > So... you believe you have pinpointed bug in their cpu design?
> 
> I would not preclude that, but I think what might be more likely is that there
> is some difference between how Intel and how VIA/Centaur behaves in a certain
> situation, or the compiler making a wrong assumption about what it can do or
> cannot do (remember e.g. for the VIA C3 there was no cmpxchg8, but gcc uses
> it in case you compile with i686 optiomization).

I'd expect any difference in behaviour (modulo timing, extensions, and
cpuid) between Intel 486 and VIA C3 to be VIA bug, because VIA is
supposed to be Intel 486 compatible, no?

If not, where is behaviour of VIA cpus specified? Will we have to
compare 1000s of pages of instruction manuals to see where the traps lie?

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html