skliros diskos

[Άγγελος Οικονομόπουλος]

DJ Art wrote:

> On Monday 31 December 2001 20:21, Άγγελος Οικονομόπουλος wrote:
> 
>> Egw sth 8esh sou den 8a to diafimiza oti exw 686A. Ase pou oi le3eis
>> "Apollo133A" den stekontai mones tous se mia protash. Prepei
>> aparaithtws na prohgeitai to "kwlo-". Sthn ka8areuousa sunh8izetai to
>> pro8ema "skato-".
> 
> Εγώ δεν θα το έλεγα αυτό. Δεν έχω συναντήσει ούτε ένα πρόβλημα που να
> σχετίζεται με το Apollo.
Σε πιστεύω. Δεν είμαστε πολλά τα κορόιδα που χρησιμοποιήσαμε reiserfs (ποτέ 
ξανά). Ούτε ξέρω άλλον που να χρειάστηκε να πάει σε 133(χωρίς Α) γιά να δει 
σταθερά Χ.

DJ Art, δώσε προσοχή στο υπογραμμισμένο.

Από ένα τεράστιο (καλύτερα: _ΤΕΡΑΣΤΙΟ_) thread βρήκα πρόχειρο αυτό:
(μεγάλο αλλά κανείς δεν θα ψάξει στο groups.google)
Αν κανείς θέλει να μπεί στην ουσία του προβλήματος μπορεί να κοιτάξει στη 
λίστα του stable γιά via+Schmidt
:...
:> > 
:> > There is also the "only supports 16MxN RAM" feature.
:> 
:> Maybe I should toss in that I've had spontaneous reboots during heavy
:> IDE activity both on my desktop (VIA 82C686) and my laptop (Intel
:> 82443BX).  And before that, random disk corruption during heavy SCSI
:> activity on my old desktop machine (seen with Tekram and Acer
:> 83C575-based host adapters and a borrowed Adaptec 2940).
:
:Guys guys, we are talking about known HW issues that causes known
:bad behavior, having a system that is flaky can have all kinds of 
:reasons, I'd risk saying that genuine HW bugs like the 686B bug
:is one of the least likely problems...
:
:The most likely reasons are probably bad/subspec'd RAM, lousy PSU,
:bad/subspec'd cabeling, too many "performance features" enabled,
:generally crappy hardware (there are *tons* of that out there), 
:bad/insufficient cooling, overclocking (even the motherboard makers 
:overclock pr default nowadays to gain a litte over the competition), 
:
:And do *not* forget bugs/bogons/mistakes in your favorite OS :)
:
:-S?ren

    Ok, I have more information on Nils problem.  First of all, Soren's
    patch greatly reduced the rate of corruption.  It took 25 loops of
    Nils 'cp' test to generate the corruption.

    However, Soren's patch did not fiix the corruption.  The same exact
    corruption is occuring.  In Nils case it is always the same exact
    location in VM -- a certain bit (or byte) in the middle of the nfsnode
    hash table.  Hardware watch points indicate that the cpu is NOT 
modifying
    this location, so I really doubt that it is a kernel bug.

    From this and from reading a number of other postings about VIA chipsets
    I believe that Soren's original patch (which I guess is the official
    VIA chipset patch) does not completely solve the VIA chipset's problems.
    I also believe, from reading some of the reference material that has
    been posted, that this corruption is not limited to the 686[A/B] but
---------------------------------------------------------------------------
    may also occur in earlier VIA chipsets.

    What I would like to do is try forcing the DMA transfer rate to 66 MHz,
    i.e. UDMA66 or UDMA33, to see if that solves the problem.  Soren,
    could you supply a patch that universally turns off higher UDMA modes?

                                        -Matt
                                        Matthew Dillon 
                                        <dillon at backplane.com>


-- 
"If geiger counter does not click,
the coffee, she is just not thick"
              --Pitr Dubovich(Illiad)