wd0a: device timeout writing fsbn ... of .....-.......

[daemonfowl]

Hi !

I was upgrading my imac via ftp , suddently an error message read repeatedly :

wd0a : device timeout writing fsbn ......number..... of .....number......
and :
d0 : soft error (corrected)

then it ended with :

could not retrieve Tx statistics cancelling automatic rate control
couldn not transmit buffer : TIMEOUT

what does it mean in understandible human language ?
thank you very much

Note : Mates who are upgrading maccpc .. avoid packages , and build ports instead .. the packages list is older than the install sets .. :-)

[jggimi]

Your first quote refers to wd0a -- this is partition 'a' on drive wd0. The device driver was unable to write to the drive within a time limit set by the wd(4) driver. "fsbn" is "file system block number". The message should also describes the physical block number within wd0 and may also provide "cn" which is "cylinder number" and "tn" which is "track" number. These latter two are probably not very useful with a modern drive, since the cylinder/track/sector addressing is virtual, and mapped by drive electronics.

The error was eventually corrected -- meaning that after retrying many, many times, perhaps hundreds or thousands of times, the drive electronics eventually confirmed the write had occurred.

The second block of messages, regarding "Tx" or "Transmit" is a kernel message produced by the ral(4) or rum(4) Ethernet drivers and have nothing directly to do, I think, with your disk I/O trouble. However if the system was "hung" while the I/O retries were occurring, this could explain a network hiccup.

---
Your entirely unrelated "warning" regarding packages should 1) reflect that you mean -current, rather than -release, and 2) does not belong in this thread, and 3) is a transient condition...as you have been told many times, snapshot packages are never exactly in sync with snapshots. They are provided as a courtesy, only.

[ocicat]

Originally Posted by daemonfowl

Note : Mates who are upgrading maccpc .. avoid packages , and build ports instead .. the packages list is older than the install sets .. :-)

daemonfowl, while I understand why you make this statement (being a -current user...), there will be readers who are not attuned to the specifics of your situation to understand why this is not good advice. As stated in Section 15.3 of the FAQ:

IMPORTANT NOTE: The ports tree is meant for advanced users. Everyone is encouraged to use the pre-compiled binary packages.

In general, this site attempts to provide reasoned advice which stays in step with the wishes & dictates of the project. Anything said in contradiction needs to provide supporting evidence.

[daemonfowl]

Teacher @jgimmi , and teacher @ocicat : molte gratzie !!!!
your help is much appreciated !!
sorry for the inconvenience , I abide by the golden rule .. yet I wanted to save others times by stating that I failed to install packages after an upgrade ( 5.1 GENERIC#172 macppc) .. but again on i386 .. eveything is runing fine : I mean to this very moment I am installing packages without problems (5.1 GENERIC.MP#230 i386)

[jggimi]

Back to the thread's topic -- your "temporary" I/O error: what might have been the problem, and why did it suddenly resolve after a long time passed by?

Let us assume, for the sake of this discussion, that the timeout was 5 seconds, and your drive spins at a typical 7200rpm.

During that 5 seconds, 600 times the sector passed underneath the head and the write failed. Why would it fail ~600 times and then ... suddenly succeed? Keep in mind:

• Writes are not tested after being written to the physical media. You won't find out if you've written to a bad sector until you later attempt to read it. However, if the sector is n
• Writes and reads typically share the use of a cache buffer on the drive electronics. This chunk of RAM improves performance, though on write operations, the drive does not report the write is complete until the block(s) are actually written to the disk.
• If the drive was busy having trouble on a prior read, and was busy retrying, and placed the write into a queue until the read was either successful or failed.... you would have had other indications of this, such as a read timeout.

There are two possibilities: 1) Perhaps that the sector could not be located by the drive electronics, or the sector header was damaged and could not be read. The sudden success would be due to the electronics selecting a replacement sector from its built-in spares and remapping the sector. Or .... 2) Perhaps the drive was unable to seek to the track, and a realignment exercise was conducted by the drive to correct the error, which took five seconds.

If you are interested in finding out which it was, your drive electronics may be able to tell you. There is data stored on the electronics, through a technology called SMART. The atactl(8) program can read it, but I find sysutil/smartmontools much easier to use.

[jggimi]

I've revised my thoughts on possible reasons for the error -- not just a sector access error; seek errors may have caused this also. Posting revised.

[daemonfowl]

thank you for this detailed explanation!

not just a sector access error; seek errors may have caused this also

do we describe a sector access error as a hardware-specific problem , while seek errors as software ?
I've read the atactl man page .. it's interesting what kind of information one can get from it .. why isn't there a satactl ?

[jggimi]

Seek errors are hardware errors. SATA drives are ATA and may be used with atactl.

[daemonfowl]

I left that pseudo-Note unchanged so that Ocicat & jgimmi 's helpful replies stay relevant .. one more extra reason against using ports on legacy hardware : mozilla-firefox failed to build on old ibook because of memory exhaustion ! .. this was the error message I received a while ago after one night spent on port-building .. :-)