From: "address@hidden" <address@hidden>
To: address@hidden
Sent: Thu, 24 December, 2009 6:27:54 AM
Subject: Grub-devel Digest, Vol 70, Issue 67
Send Grub-devel mailing list submissions
to
address@hiddenTo subscribe or unsubscribe via the World Wide Web, visit
http://lists.gnu.org/mailman/listinfo/grub-develor, via email, send a message with subject or body 'help' to
address@hiddenYou can reach the person managing the list at
address@hiddenWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of Grub-devel digest..."
Today's Topics:
1. Re: help ragarding Multiprocessor(MP) Configuration Table
(Brendan Trotter)
2. Non-static variables and nested function pointers [bug
#28392] (Gr?goire Sutre)
3. Re: Non-static variables and nested function pointers [bug
#28392] (Seth Goldberg)
4. Re: How to install grub on fakeraid (raid 0) which spans 2
TB? (Andr? Heynatz)
5. Re: How to install grub on fakeraid (raid 0) which spans 2
TB? (Bruce Dubbs)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Dec 2009 06:24:53 +1030
From: Brendan Trotter <
address@hidden>
Subject: Re: help ragarding Multiprocessor(MP) Configuration Table
To: The development of GNU GRUB <
address@hidden>
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
On Thu, Dec 24, 2009 at 1:09 AM, mandar naik <
address@hidden> wrote:
> So we wanted to know how & what MP information is made available to grub on
> Intel core2duo architecture if MP Floating Point structure & MP
> configuration table are not present.
> If Intel core2duo architecture is one of default configuration type then is
> it possible to modify smp-imps.c file to use default configuration settings.
> Also we would like
to know if there is similar SMP support provided in GRUB
> 1.97.
> Thanking in anticipation,
The "default configurations" mentioned in Intel's Multi-Processor
Specification haven't been used for over 15 years.
About a decade ago everything started shifting to ACPI, and in the
last few years I've seen a few systems without Intel's (much older) MP
Specification tables or with dummy/incomplete MP specification tables
(although they are still rare - almost all modern computers have both
MP and ACPI). The ACPI tables include a "Multiple APIC Description
Table" which tells you everything that the MP Tables did, and modern
software should check for ACPI tables and use them (and should only
use MP Specification tables if no ACPI tables are found).
Modifying GRUB to suit your specific hardware is a bad idea
(especially when the problem is your software and not the hardware,
firmware or GRUB); and
learning how to make software that doesn't work
on other computers and stops working when you change some of the BIOS
settings is also a bad idea.
Use the ACPI tables.
Cheers,
Brendan
------------------------------
Message: 2
Date: Wed, 23 Dec 2009 21:48:31 +0100
From: Gr?goire Sutre <
address@hidden>
Subject: Non-static variables and nested function pointers [bug
#28392]
To: The development of GNU GRUB <
address@hidden>
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I am trying to add NetBSD specific code to util/hostdisk.c
in order to
make grub-probe work. This part is almost finished. However, I had a
hard time dealing with segfaults in callbacks (hook function pointers)
in a number of places of the vanilla code. Actually, I get segfaults in
grub-probe with the vanilla trunk code (see bug report #28392). This is
on NetBSD 5.0 i386.
In the end, these segfaults were fixed by making sure that all variables
accessed by pointers to nested functions are declared static. I attach
a patch that fixes these segfaults on my NetBSD box (this patch is also
included in the bug report).
However, I am not a C expert, and I must be missing something as the
code (obviously) works well on other systems.
Thanks for your help,
Grégoire
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-nested-functions.diff
Type: text/x-patch
Size: 7659
bytes
Desc: not available
Url :
http://lists.gnu.org/pipermail/grub-devel/attachments/20091223/70cf596a/patch-nested-functions.bin------------------------------
Message: 3
Date: Wed, 23 Dec 2009 14:17:06 -0800 (PST)
From: Seth Goldberg <
address@hidden>
Subject: Re: Non-static variables and nested function pointers [bug
#28392]
To: The development of GNU GRUB <
address@hidden>
Message-ID:
<
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
Your problem is probably lack of executable stack support, or at least you
haven't linked your application with a linker mapfile that specifies an
executable stack -- the callbacks require the use of trampolines to access
local variables, which require an executable stack.
--S
Quoting Grégoire Sutre, who wrote the following on Wed, 23 Dec 2009:
> Hi,
>
> I am trying to add NetBSD specific code to util/hostdisk.c in order to make
> grub-probe work. This part is almost finished. However, I had a hard time
> dealing with segfaults in callbacks (hook function pointers) in a number of
> places of the vanilla code. Actually, I get segfaults in grub-probe
with the
> vanilla trunk code (see bug report #28392). This is on NetBSD 5.0 i386.
>
> In the end, these segfaults were fixed by making sure that all variables
> accessed by pointers to nested functions are declared static. I attach a
> patch that fixes these segfaults on my NetBSD box (this patch is also
> included in the bug report).
>
> However, I am not a C expert, and I must be missing something as the code
> (obviously) works well on other systems.
>
> Thanks for your help,
>
> Grégoire
>
------------------------------
Message: 4
Date: Thu, 24 Dec 2009 00:05:42 +0100
From: "Andr? Heynatz" <
address@hidden>
Subject: Re: How to install grub on fakeraid (raid 0) which spans 2
TB?
To: The development of GNU GRUB <
address@hidden>
Message-ID: <
address@hidden>
Content-Type: text/plain; charset="iso-8859-1"
> André Heynatz wrote:
> > I have bought two 1 TB harddisks and one 2 TB harddisk (backup).
> > I want to use the 1 TB harddisks in a RAID 0 array (Intel ICH8R
> Fakeraid).
> >
> > OS: Win XP SP3, Win 7, Ubuntu Linux 9.10 32 Bit
> >
> > My partition plan 1:
> >
> > P ntfs 300 GB Windows XP SP3 32 Bit
> > P ntfs 300 GB Windows 7 32 Bit
> > E
> > L swap 2 GB Linux swap
> > L ext4 250 GB Ubuntu Linux 9.10 (Karmic) 32 Bit
> > L ntfs 1100 GB data (for data exchange and storage)
> > L
ext4 48 GB spare space for testing of new OSes
>
> I'd suggest:
>
> P ext2 100 MB /boot
> P ntfs 300 GB Windows XP SP3 32 Bit
> P ntfs 300 GB Windows 7 32 Bit
> E
> L swap 2 GB Linux swap
> L ext4 250 GB Ubuntu Linux 9.10 (Karmic) 32 Bit
> L ntfs 1100 GB data (for data exchange and storage)
> L ext4 48 GB spare space for testing of new OSes
>
> There is no need for /boot to be on a raid or other 'special' partition
> type.
>
> -- Bruce
Hello Bruce,
thanks for the suggestion. But in order to do this I would need to remove the perfectly working Windows XP and Windows 7 systems to do this which would be a pity. I feel that Linux just CAN do it with Fakeraid, only a tiny bit of work is needed for support. I managed to install Linux on Fakeraid three years ago, with a complicated
procedure. It worked like a charm, until I needed more capacity. This time it is a little bit more difficult to get to a solution. I do not care if it is GRUB1 or GRUB2, it should work with both because we are at a turning point and cannot neglect the fact that we need a transition period. I assume that GRUB is to serve users well of course.
My only explanation for the failure of GRUB1 the second time is that there is some overflow happening because of the huge sector counts. If a sector count is stored in a 32 Bit Integer (int), there may be a problem if the sector count exceeds 0x7fffffff, which is 1 TB. My first partition plan lets GRUB use a sector count below 0x80000000, my second partition plan lets the Linux system partition be at a sector address definitely above 0x7fffffff, which may overflow. In general, signedness should be cared about. But in this case it would be even better to use a 64 Bit sector address to accomodate for LBA48 (or
LBA64?). Hard disk sizes can only increase, and I read about people using RAID-5 with 6 TB capacity and needing to go to GUID partition tables (GPT) because one partition is to be larger than 2 TB. Windows Vista and Windows 7 support this EFI feature. I am sure Linux does it too, at least Ubuntu Linux which I use has UIDs even in the GRUB1 configuration (probably patched).
I return to partition plan 1 and create the whole partition table with Windows 7 which should be recent enough to handle the size of the disks. The newest Intel Matrix driver should work flawlessly. Afterwards I install Ubuntu Linux near the other system partitions which was my original plan. Especially Windows XP 32 Bit is unsupported in this area (by intent) so I should not depend on it to deal with a partition table. Firstable I try Ubuntu 10.04 GRUB2, then if it does not work I try Ubuntu 9.10 GRUB1 (most recent update).
My old computer without RAID uses GRUB2, and it
works flawlessly. Keep up the good work! There will always be special cases which need some attention. We get closer to a "just works" system which would attract many new users. It is not the design which sells systems, maybe later it is, but now it still is the lacking functionality or compatibility which drives users away.
I wish you all a Merry Christmas!
Greetings,
André
--
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter
http://portal.gmx.net/de/go/maxdome01------------------------------
Message: 5
Date: Wed, 23 Dec 2009 18:57:45 -0600
From: Bruce Dubbs <
address@hidden>
Subject: Re: How to install grub on fakeraid (raid 0) which spans 2
TB?
To: The development
of GNU GRUB <
address@hidden>
Message-ID: <
address@hidden>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
André Heynatz wrote:
>> André Heynatz wrote:
>>> I have bought two 1 TB harddisks and one 2 TB harddisk (backup).
>>> I want to use the 1 TB harddisks in a RAID 0 array (Intel ICH8R
>>> P ntfs 300 GB Windows XP SP3 32 Bit P ntfs 300 GB Windows 7 32
>>> Bit E L swap 2 GB Linux swap L ext4 250 GB Ubuntu Linux 9.10
>>> (Karmic) 32 Bit L ntfs 1100 GB data (for data exchange and
>>> storage) L ext4 48 GB spare space for testing of new OSes
>> I'd suggest:
>>
>> P ext2 100 MB /boot
P ntfs 300 GB Windows XP SP3 32 Bit P ntfs
>> 300 GB Windows 7 32 Bit E L swap 2 GB Linux swap L ext4 250 GB
>> Ubuntu Linux 9.10 (Karmic) 32 Bit L ntfs 1100 GB data (for data
>> exchange and storage) L ext4 48 GB spare space for testing of new
>> OSes
>>
>> There is no need for /boot to be on a raid or other 'special'
>> partition type.
>>
>> -- Bruce
>
> Hello Bruce,
>
> thanks for the suggestion. But in order to do this I would need to
> remove the perfectly working Windows XP and Windows 7 systems to do
> this which would be a pity.
No, not really. From your post I thought you you were working with a
blank HD. Try this:
P ntfs 300 GB Windows XP SP3 32 Bit
P ntfs 300 GB Windows 7 32 Bit
P ext2 100 MB /boot
E
L swap 2 GB Linux
swap
L ext4 250 GB Ubuntu Linux 9.10 (Karmic) 32 Bit
L ntfs 1100 GB data (for data exchange and storage)
L ext4 48 GB spare space for testing of new OSes
I like to use the first partition as /boot, but there is no requirement
to do that. I think you can use a logical partition too, but I'm not
100% sure.
GRUB normally uses a BIOS call as a part of its internal process. The
extended call is defined for up to 2^48 sectors. That is far larger
than any disk available today. Any limitation, if it exists, is in the
BIOS.
> I feel that Linux just CAN do it with
> Fakeraid, only a tiny bit of work is needed for support. I managed to
> install Linux on Fakeraid three years ago, with a complicated
> procedure. It worked like a charm, until I needed more capacity. This
> time it is a little bit more difficult to get to a solution. I do not
> care
if it is GRUB1 or GRUB2, it should work with both because we are
> at a turning point and cannot neglect the fact that we need a
> transition period. I assume that GRUB is to serve users well of
> course.
That's your choice of course. I haven't worked with any SW raid. I've
always thought that HW raid was a better choice. After all, the value
of your data is far greater than any raid device.
-- Bruce
------------------------------
_______________________________________________
Grub-devel mailing list
address@hiddenhttp://lists.gnu.org/mailman/listinfo/grub-develEnd of Grub-devel Digest, Vol 70, Issue 67
******************************************