unexpected softupdate inconsistency

[othermark]

Manfred Lotz wrote:
> At system startup fsck was started which produced the message: unexpected
> softupdate inconsistency and also that some blocks could not be written
> to. At the end fsck said: filesystem still dirty and I should run fsck
> manually which I did but without any success.

I have a large EIDE drive (30 gigs) with a large partition on it that was
getting unexpected softupdate inconsistency on it when I did large writes
(untar, remove, installworld, etc..).

I turned off softupdates, and that did not help, so I turned off dma and
just went to PIO mode.  Things got much better from then on, however
performance was miserable in PIO mode, so I took a chance and upgraded to
-CURRENT to get atang.  It now works great in -current with dma+soft
updates.

I'm assuming this was a incompatibility/bug between my controller and
-STABLE, otherwise I would see a littering of complaints in stable mailing
list.  I found one pr in gnats mentioning one such incompatibility and
softupdate inconsistencies.

For reference:
atapci0: <ServerWorks ROSB4 UDMA33 controller> port 0xfc90-0xfc9f at device
15.1 on pci0

[root]$ atacontrol mode 0
Master = UDMA33
Slave  = BIOSPIO

[root]$ atacontrol list
ATA channel 0:
    Master:  ad0 <ST330630A/3.21> ATA/ATAPI rev 4
    Slave:       no device present


the best test I could find for this was grabbing a large tarball, extracting
it and then comparing the extraction 30 seconds later with the tar '-d'
switch.

> However, I'm really worried. Is there anybody I could do???

Try performing the tar test above (I used the openoffice 1.1 source tarball
from ports which failed the compare everytime), and if you get differences
then try booting up a 5.2.1 cd, mount your UFS r/w partition and try the
tar test again to see if it's still there.  If so, I would recommend a
source upgrade to 5.2.1 or -current.

-- 
othermark
atkin901 at nospam dot yahoo dot com
(!wired)?(coffee++):(wired);