On 11.08.2010 10:04, Valentin Nechayev wrote:
example, set up geometry xxx*64*32 for all new disks and align GPT
partitions on 1MB boundary. As soon as FS requests in FreeBSD are no
less than 4KB in size, this would satisfy any disk.
If 4KB sectors are our future for a few next years, this
Bakul Shah ba...@bitblocks.com writes:
After poking around some, it seems ATA/ATAPI-7 Identify Device word
106 bit 13 is set to 1 and bits 0-3 are set to 3 (for 2^3 or 8 LBAs
per sector) for a 4KB sector size (pin 7-8 jumper on a WD AF disks
presumably changes this setting to 0,0). See page
Matthew Jacob m...@feral.com writes:
Yes, that should be it!
No, it shouldn't, cf. extensive discussion about EARS disks on -current.
They lie about their physical sector size. There's a jumper setting for
Windows XP compatibility, but apparently, it only affects the (fake)
geometry the disk
I am encountering a situation similar to one reported by Andrew Heybey
at http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C25464D
This morning I found this in my /var/log/messages:
Aug 11 01:59:48 kraken kernel: MCA: Bank 4, Status 0x94614c62001c011b
Aug 11 01:59:48 kraken
I'm looking into a clean, permanent solution for WD Green drives that
use 4096-byte physical sectors. To summarize the information I've
collected so far:
There is attempt to look from another side - is it really needed?
Captain Obvious says that if one have a new disk, it's easy to format
it
On Aug 11, 2010, at 6:47 AM, Dan Langille wrote:
I am encountering a situation similar to one reported by Andrew Heybey
at http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C25464D
This morning I found this in my /var/log/messages:
Aug 11 01:59:48 kraken kernel: MCA: Bank
des@ wrote:
There's a jumper setting for
Windows XP compatibility, but apparently, it only affects the (fake)
geometry the disk reports to the BIOS.
No, this jumper internally increases any linear block number learned from bus
request by 1. I.e. the block number 1 without this jumper is seen
On Wed, Aug 11, 2010 at 09:04:39AM +0300, Valentin Nechayev wrote:
I'm looking into a clean, permanent solution for WD Green drives that
use 4096-byte physical sectors. To summarize the information I've
collected so far:
There is attempt to look from another side - is it really needed?
2010/8/11, Valentin Nechayev ne...@netch.kiev.ua:
I'm looking into a clean, permanent solution for WD Green drives that
use 4096-byte physical sectors. To summarize the information I've
collected so far:
There is attempt to look from another side - is it really needed?
Captain Obvious says
On Wed, August 11, 2010 7:31 am, Andrew Heybey wrote:
On Aug 11, 2010, at 6:47 AM, Dan Langille wrote:
I am encountering a situation similar to one reported by Andrew Heybey
at
http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C25464D
This morning I found this in my
Dan Langille wrote:
I am encountering a situation similar to one reported by Andrew Heybey
at http://docs.freebsd.org/cgi/mid.cgi?6E83197B-9DD5-4C7E-846D-AD176C25464D
This morning I found this in my /var/log/messages:
Aug 11 01:59:48 kraken kernel: MCA: Bank 4, Status 0x94614c62001c011b
Aug
Ref. http://berklix.com/~jhs/hardware/laptops/novatech-8355/
I wrote
A laptop here emits a puzzlingly dmesg to both 8.1-RC2 8.1-RELEASE:
real memory = 8572108800 (8175 MB)
avail memory = 1018789888 (971 MB)
BIOS reckons it has 1G. No panel to unscrew to inspect memory.
I
12 matches
Mail list logo
