From: Johannes Stezenbach on
On Tue, Mar 09, 2010 at 04:32:04PM -0800, H. Peter Anvin wrote:
>
> It can. The BIOS doesn't care about the partition table at all --
> all it does is load the MBR.

A little story for your entertainment pleasure:

I have a Gigabyte GA-MA78GM-S2H board, and during install
turned off the power after partitioning but before formatting
any partition because I got distracted by something else.

Result: System could not boot anymore, BIOS hung before
I could get to the "select boot device" screen. This also
happened when I removed the hdd from the boot device
list in BIOS. The last BIOS message was "Verifying DMI Pool Data"
and you can find numerous similar reports by searching for
'gigabyte bios hang "Verifying DMI Pool Data"'.

In my case it worked to switch the SATA mode from AHCI to
something else, then wipe the partition table and switch
back to AHCI. But I read on the net that some people had
to format the drive in another PC, or hotplug it after the BIOS
got past "Verifying DMI Pool Data".


Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on
On 03/10/2010 02:46 AM, Johannes Stezenbach wrote:
> On Tue, Mar 09, 2010 at 04:32:04PM -0800, H. Peter Anvin wrote:
>>
>> It can. The BIOS doesn't care about the partition table at all --
>> all it does is load the MBR.
>
> A little story for your entertainment pleasure:
>
> I have a Gigabyte GA-MA78GM-S2H board, and during install
> turned off the power after partitioning but before formatting
> any partition because I got distracted by something else.
>
> Result: System could not boot anymore, BIOS hung before
> I could get to the "select boot device" screen. This also
> happened when I removed the hdd from the boot device
> list in BIOS. The last BIOS message was "Verifying DMI Pool Data"
> and you can find numerous similar reports by searching for
> 'gigabyte bios hang "Verifying DMI Pool Data"'.
>
> In my case it worked to switch the SATA mode from AHCI to
> something else, then wipe the partition table and switch
> back to AHCI. But I read on the net that some people had
> to format the drive in another PC, or hotplug it after the BIOS
> got past "Verifying DMI Pool Data".
>

Well, yes, there are buggy BIOSes of a gazillion varieties. A fair
number of them read the partition table to try to guess what C/H/S
geometry the user intended. However, the GPT spec specifically uses a
"Protective MBR" to guard against this and other issues like it; it
makes the entire disk look to MBR-reading software like a single fully
partitioned disk with one large partition on it.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jeff Garzik on
On 03/10/2010 02:53 AM, Matthew Wilcox wrote:
> On Mon, Mar 08, 2010 at 10:41:57AM -0500, Martin K. Petersen wrote:
>> What I meant to say was that I know ATA supports 4 KB LBS and that
>> nobody appears to care about it.
>
> I sent patches to add support ... they were ignored.

Not true, read the rest of the thread.

Jeff



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Damian Lukowski on
> S-2. The proper solution.
>
> Correct alignments for all partitions can't be achieved by the
> firmware alone. The system utilities should be informed about the
> alignment requirements and align partitions accordingly.
>
> The above firmware workaround complicates the situation because the
> two different configurations require different offsets to achieve
> the correct alignments. ATA/ATAPI-8 specifies a way for a drive to
> export the physical and logical sector sizes and the LBA offset
> which is aligned to the physical sectors.
>
> In Linux, these parameters are exported via the following sysfs
> nodes.
>
> physical sector size : /sys/block/sdX/queue/physical_block_size
> logical sector size : /sys/block/sdX/queue/logical_block_size
> alignment offset : /sys/block/sdX/alignment_offset
>
> Let the physical sector size be PSS, logical sector size LSS and
> alignment offset AOFF. The system software should place partitions
> such that the starting LBAs of all partitions are aligned on
>
> (n * PSS + AOFF) / LSS
>
> For 4 KiB physical sector offset-by-one drives, PSS is 4096, LSS 512
> and AOFF 3584 and with n of 7 the above becomes,
>
> (7 * 4096 + 3584) / 512 == 63
>
> making sector 63 an aligned LBA where the first partition can be
> put, but without the offset-by-one mapping, AOFF is zero and LBA 63
> is not aligned.
>
> With the above new alignment requirement in place, it becomes
> difficult to honor the legacy one - first partition on sector 63 and
> all other partitions on cylinder boundary (255 * 63 sectors) - as
> the two alignment requirements contradict each other. This might be
> worked around by adjusting how LBA and CHS addresses are mapped but
> the disk geometry parameters are hard coded everywhere and there is
> no reliable way to communicate custom geometry parameters.

Hello,
I have practically no knowledge of Linux' block device drivers,
but is this really a partitioning issue? I think the problem is
with the filesystems when clustering multiple blocks without
knowledge of the sector alignment and sector size of the underlying
block device. Maybe it is a better solution to adapt the filesystem
buffer routine which reads/writes data from/to the block device?

Best regards
Damian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Henrique de Moraes Holschuh on
On Wed, 10 Mar 2010, Martin K. Petersen wrote:
> >>>>> "Karel" == Karel Zak <kzak(a)redhat.com> writes:
>
> [Cleaned up the CC: list from hell]
>
> Karel> # cat /sys/block/md8/queue/{minimum,optimal}_io_size
> Karel> 65536 65536
>
> This one had me puzzled. We set min_io and opt_io correctly in raid5.c
> depending on number of non-parity disks. And yet it turns into
> something nonsensical after.
>
> Turns out we overrun unsigned int calculating the lowest common multiple
> in the stacking function. That's why we ended up with the wrong value.
>
> I never noticed this because my userland topology regression test tool
> uses unsigned long.
>
> I'll get a patch off to Jens right away.

And please get the whole fixed deal in -stable eventually, for 2.6.32.y's
benefit :-)

--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/