Hard disk problem? kdm bug? What is going on here...
The last two days I've had freezes when booting up my old 6-STABLE/i386 desktop. It gets as far as kdm (3.5.2) which then freezes. When I reboot into single user mode and after I've fscked the disk (or apparently something that sounds very similar) I can't start bash: # bash /libexec/ld-elf.so.1: Shared object "libintl.so.6" not found, required by "bash" However, the file exists and gettext, which also depends on the library, still runs! Forcing a recompile of gettext fixes bash. However, I only noticed this as a side effect of kdm hanging (simply because the first thing I do when I want to work in SU mode is mount -a && bash). First time it happened I recompiled bash and kdm started; this morning I tried it and kdm hung again. I rebooted and sure enough bash was complaining about libintl.so.6, so this time I disabled kdm, recompiled gettext and did a startx after booting into multi-user mode. Works fine. fsck is reporting no errors on /usr/local (dev/ad0s1e) I'm stumped - I can't work out what the connection is between the symptoms. Any ideas anyone? Thanks Ashley ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hard disk problem
DavidB <[EMAIL PROTECTED]> writes: > Hey, Lowell could you please read the thread I reference and give your > opinion of the issue about the WD diagnostic tool. Most manufacturers have their own versions of such tools. If you can use them, they are indeed quite likely to give you more information than you can get any other way. > So I was studying what you were talking about bad block remapping, > dynamic bad block remapping, or western digital's term "Auto Defect > Retirement" > > I had expected that I disk would when failing to write to a bad area > on disk and fails to mark it bad and redirect it to somewhere else on > the disk. But reads I would not have expected the hardware to do > anything other than give a failure. It seems there is some mechanism > to do this automatically within the hardware with reads also. But it > seems very vague on how and when this is tripped. Most of my reading > including one thing from someone who works for Maxtor is that the bad > block is marked bad at the failed read (or succesive failed reads, > says the Maxtor guy) however doesn't get remapped until the next > write, and from my reading, seems to be, not until the next write to > that particular sector. So the bad block being read would be there > until you did something to cause the hardware to remap it. It doesn't > seem it is done so it is totally hidden from view or seeing issues > with bad blocks. This seems to differ a little between manufacturers, but I think most of them have a few more complexities than that description. One of the more impressive tricks is to re-try failed reads, starting from a different sector on the cylinder (and thus, a different timing, which improves your odds of a good read if you're having problems with the platter-to-head separation). More expensive drive firmware will certainly recover the problem sectors automatically -- I suspect, but do not know for certain, that some drives will first try re-writing the data back to the same sector, in case field strength just needs reinforcing. > The system seems to be setup in order to catch problems and remap them > at the earliest time so that the data is not totally unreachable[lost] > the hardware will try using multiple reads with ECC to read out the > effected data [from what I have read] and writes it somewhere else. Of course, you won't hear about it at that time. > So again I say that the disk PROBABLY is NOT in for a soon demise. > Running the disk diagnostic tools from the disk manufacturer will > remap the bad block immeadiately as well as other things, rather than > waiting until you happen to write to that sector again. Yes, I did "pull the trigger" a bit fast on this; it's possible that the two errors reported by the original poster were the only ones observed. In that case, they could be a fluke for any number of reasons, right down to sunspots. I probably should have recommended being *prepared* to replace the drive. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hard disk problem
Hmmm, Hey, Lowell could you please read the thread I reference and give your opinion of the issue about the WD diagnostic tool. So I was studying what you were talking about bad block remapping, dynamic bad block remapping, or western digital's term "Auto Defect Retirement" I had expected that I disk would when failing to write to a bad area on disk and fails to mark it bad and redirect it to somewhere else on the disk. But reads I would not have expected the hardware to do anything other than give a failure. It seems there is some mechanism to do this automatically within the hardware with reads also. But it seems very vague on how and when this is tripped. Most of my reading including one thing from someone who works for Maxtor is that the bad block is marked bad at the failed read (or succesive failed reads, says the Maxtor guy) however doesn't get remapped until the next write, and from my reading, seems to be, not until the next write to that particular sector. So the bad block being read would be there until you did something to cause the hardware to remap it. It doesn't seem it is done so it is totally hidden from view or seeing issues with bad blocks. The system seems to be setup in order to catch problems and remap them at the earliest time so that the data is not totally unreachable[lost] the hardware will try using multiple reads with ECC to read out the effected data [from what I have read] and writes it somewhere else. So again I say that the disk PROBABLY is NOT in for a soon demise. Running the disk diagnostic tools from the disk manufacturer will remap the bad block immeadiately as well as other things, rather than waiting until you happen to write to that sector again. This is my summation of the matter, based on reading various and sundry things concerning this with none giving an absolute or concrete answer[particularly concerning what happens with data already written to disk]. Sincerly, David Lowell Gilbert wrote: DavidB <[EMAIL PROTECTED]> writes: you probably have a couple bad blocks on the harddrive, which happens over time, you need to scan and repair the harddrive. If the bad blocks reappear rather frequently then you know that the disk will fail in the near future. Correct. Assuming the hard disk was built in the 1980s. If it's more recent, then it almost certainly does internal bad-block remapping on its own. That means that if bad blocks are becoming visible to the operating system, the disk has hundreds or thousands of bad sectors, and is on its way to the grave. This would be more serious if the errors were occurring on writes rather than reads, but there has already been data lost, and some of the data on the disk is known to be corrupted. If the original poster has a hard disk that predates the 486 chip, then I apologize for having given a possibly incorrect answer. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hard disk problem
DavidB <[EMAIL PROTECTED]> writes: > you probably have a couple bad blocks on the harddrive, which happens > over time, you need to scan and repair the harddrive. If the bad > blocks reappear rather frequently then you know that the disk will > fail in the near future. Correct. Assuming the hard disk was built in the 1980s. If it's more recent, then it almost certainly does internal bad-block remapping on its own. That means that if bad blocks are becoming visible to the operating system, the disk has hundreds or thousands of bad sectors, and is on its way to the grave. This would be more serious if the errors were occurring on writes rather than reads, but there has already been data lost, and some of the data on the disk is known to be corrupted. If the original poster has a hard disk that predates the 486 chip, then I apologize for having given a possibly incorrect answer. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hard disk problem
Lowell Gilbert wrote: "Valery" <[EMAIL PROTECTED]> writes: I use FreeBSD 4.4 Stable I faced the following problem. Here is a part from messages --- ad2s1e: hard error reading fsbn 32727951 of 16363936-16364175 (ad2s1 bn 32727951; cn 32468 tn 3 sn 18) status=59 error=40 ad2s1e: hard error reading fsbn 32727967 of 16363952-16364175 (ad2s1 bn 32727967; cn 32468 tn 3 sn 34) status=59 error=40 What sort of problem with my hard disk Is it critical? It is time to replace the disk. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" Das ist nicht richtig/ that not right! you probably have a couple bad blocks on the harddrive, which happens over time, you need to scan and repair the harddrive. If the bad blocks reappear rather frequently then you know that the disk will fail in the near future. The answer to this is in the mail archive in freebsd-stable please read the thread with the subject line "ATA failure with 4.6.2 & 250GB drive?" If you have any further questions then repost. thanks, David ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hard disk problem
"Valery" <[EMAIL PROTECTED]> writes: > I use FreeBSD 4.4 Stable > I faced the following problem. > > Here is a part from messages > --- > ad2s1e: hard error reading fsbn 32727951 of 16363936-16364175 (ad2s1 bn > 32727951; cn 32468 tn 3 sn 18) status=59 error=40 > ad2s1e: hard error reading fsbn 32727967 of 16363952-16364175 (ad2s1 bn > 32727967; cn 32468 tn 3 sn 34) status=59 error=40 > > > > What sort of problem with my hard disk > Is it critical? It is time to replace the disk. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
hard disk problem
Hello! I use FreeBSD 4.4 Stable I faced the following problem. Here is a part from messages --- ad2s1e: hard error reading fsbn 32727951 of 16363936-16364175 (ad2s1 bn 32727951; cn 32468 tn 3 sn 18) status=59 error=40 ad2s1e: hard error reading fsbn 32727967 of 16363952-16364175 (ad2s1 bn 32727967; cn 32468 tn 3 sn 34) status=59 error=40 What sort of problem with my hard disk Is it critical? Yours sincerely, Valery ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
hard disk problem.
h'llo all I've got 2 disks on my primary controller, an 80GB (master) and an 60GB (slave)... (both these selected from CS - cable select) i've installed linux on the first partition of the master while the slave had already some ms-windows things installed. when trying to install freebsd 4.6 OR 4.6.2 from the cd (the same one i have used and worked fine on a 6GB harddisk) i get the following: ad0: 78167MB [158816/16/63] at ata0-master BIOSDMA ad1: READ command timeout tag=0 serv=0 - resetting ata0: resetting devices .. and thats it. it freezes there. anything i cud do? thanks in advance, thanos __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
