[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061128120916.GG2352@gamma.logic.tuwien.ac.at>
Date: Tue, 28 Nov 2006 13:09:16 +0100
From: Andreas Leitgeb <avl@...ic.at>
To: Tejun Heo <htejun@...il.com>
Cc: avl@...ic.at, Alan <alan@...rguk.ukuu.org.uk>,
linux-kernel@...r.kernel.org
Subject: Re: Allow turning off hpa-checking.
It seems I was too eagerly deleting context from my mails.
This made people misunderstand my questions or answer
details that have been clarified in previous mails already.
I did learn quite a lot already about harddisks during this thread.
"Thank you" to Alan. In particular, about the quantities involved:
1 2
+---------------------------------------------+---+
^-3
There is
1) the "native" size of the disk: strictly constant
2) the spare sectors for remapping bad ones. (not included in 1)
3) An arbitrary quantity, being what the drive advertises as size.
Bios thinks 3) is the disks total size. So does Linux before the
hpa-check. During that "hpa-check", Linux queries the quantity "1)",
which is indeed the disks (constant) size.
There seem to be many (in some way conflicting) uses for "3)":
- fool the BIOS: because bioses might get upset for too large disks.
- fool some old OS: because the OS might get upset ---"---
- reserve some sectors for some non-volatile data hidden to
certain systems e.g. for "nanny the user"-purposes.
This thread is (for one part) about another appearant use of "3)",
namely by the drive to tell that "2)" is exhausted, and less than
"1)" sectors are left usable. So quantity "3)" is set to the number
of actually physically remaining sectors.
This theory is backed by my observation of a nearly-broken disk,
that the quantity "3)" gradually goes down one step after some time.
The first such step was, when I noticed the problem about half a
year ago, and just recently it stepped down by another one.
Linux queries the real size "1)", gets read errors on the last two
sectors and consequencially turns off dma making the machine awfully
slow. But this is not a kernel's problem, because really the disk
should be replaced (it doesn't contain precious data, so I keep
watching its degrade, till it no longer does anything).
The point I'm really trying to make is, that there should be a
boot option, to disable the query for "1)". This *must* be a
boot option, because the querying that I want to be able to
prevent happens at boot time.
My broken drive surely doesn't justify the option (or even this
thread), but the third one of the "uses for 3)" mentioned above
does. Once the native size is read, I no longer know how many
sectors were previously "hidden away" by HPA, except by checking
the kernel-log.
While Alan has already said, why he thought that this was the
wrong approach, the reasoning was based on a misunderstanding
of my question, which I here tried to clear up.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists