Hard disk problem? kdm bug? What is going on here...

2006-04-19 Thread Ashley Moran
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

2003-10-27 Thread Lowell Gilbert
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

2003-10-27 Thread DavidB
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

2003-10-27 Thread Lowell Gilbert
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

2003-10-27 Thread DavidB
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

2003-10-27 Thread Lowell Gilbert
"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

2003-10-26 Thread Valery
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.

2002-12-07 Thread Thanos Tsouanas
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