Testing on PowerMac G4

Testing on PowerMac G4

[Pavel Roskin]

Hello!

I have tried the current GRUB on a PowerMac G4 running Fedora 8.

If I follow the instructions at  
http://grub.enbug.org/TestingOnPowerPC, I cannot load grubof.modules.   
If I do it directly from openfirmware, I get "CLAIM failed" message.

I tried adding grubof.modules to the OS selection menu in ofboot.b  
script installed by yaboot, so that grubof.modules is loaded like  
yaboot.  That doesn't work either.  In some cases, I would get the  
openfirmware prompt, in other cases, the menu would restart.  It looks  
like the attempt to load grubof.modules makes openfirmware unstable.

I also tried loading kernel.elf created by the build process.  It  
loads and shows the prompt.  However, GRUB starts in the rescue mode,  
and I cannot do anything in that mode.

-- 
Regards,
Pavel Roskin

Re: Testing on PowerMac G4

[Jan Nieuwenhuizen]

Pavel Roskin writes:

> However, GRUB starts in the rescue mode,  
> and I cannot do anything in that mode.

In rescue mode, type
 
    insmod normal
    normal

That will print the error why the menu is not started, because
this should have been automatic, or else it will starts the menu.

Greetings,
Jan.

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

Re: Testing on PowerMac G4

[Pavel Roskin]

On Mon, 2007-12-31 at 09:45 +0100, Jan Nieuwenhuizen wrote:
> Pavel Roskin writes:
> 
> > However, GRUB starts in the rescue mode,  
> > and I cannot do anything in that mode.
> 
> In rescue mode, type
>  
>     insmod normal
>     normal
> 
> That will print the error why the menu is not started, because
> this should have been automatic, or else it will starts the menu.

Oh well, that PowerMac G4 won't work at all anymore (looks like a
hardware failure, there is no video output), so I'm trying it on
PowerMAC G3 (Blue&White).

I copied grub.cfg and kernel.elf to the root of the HFS boot partition
hd:2.  I entered openfirmware on startup by holding Alt-Mac-O-F.  I used
"dir hd:2,\" to check that kernel.elf is there.  Then I loaded it with
"boot hd:2,\kernel.elf".  That's what I got:

grub rescue> insmod normal
error: unknown device
grub rescue> normal
unknown command `normal'
Try `help' for usage
grub rescue> lsmod
Name    Ref Count     Dependencies
grub rescue> set
prefix=(ultra0,2)
root=ultra0,2
grub rescue> ls
(ide0/disk) DISK-LABEL: read of block0 failed
(cd) DISK-LABEL: read of block0 failed
(zip) (ide1/disk) (hd) (utltra0)

My guess is kernel.elf doesn't include the necessary code.  It's about
60k long.

-- 
Regards,
Pavel Roskin

Re: Testing on PowerMac G4

[Robert Millan]

On Mon, Dec 31, 2007 at 05:37:35PM -0500, Pavel Roskin wrote:
> 
> On Mon, 2007-12-31 at 09:45 +0100, Jan Nieuwenhuizen wrote:
> > Pavel Roskin writes:
> > 
> > > However, GRUB starts in the rescue mode,  
> > > and I cannot do anything in that mode.
> > 
> > In rescue mode, type
> >  
> >     insmod normal
> >     normal
> > 
> > That will print the error why the menu is not started, because
> > this should have been automatic, or else it will starts the menu.
> 
> Oh well, that PowerMac G4 won't work at all anymore (looks like a
> hardware failure, there is no video output), so I'm trying it on
> PowerMAC G3 (Blue&White).
> 
> I copied grub.cfg and kernel.elf to the root of the HFS boot partition
> hd:2.  I entered openfirmware on startup by holding Alt-Mac-O-F.  I used
> "dir hd:2,\" to check that kernel.elf is there.  Then I loaded it with
> "boot hd:2,\kernel.elf".  That's what I got:
> 
> grub rescue> insmod normal
> error: unknown device
> grub rescue> normal
> unknown command `normal'
> Try `help' for usage
> grub rescue> lsmod
> Name    Ref Count     Dependencies
> grub rescue> set
> prefix=(ultra0,2)
> root=ultra0,2
> grub rescue> ls
> (ide0/disk) DISK-LABEL: read of block0 failed
> (cd) DISK-LABEL: read of block0 failed
> (zip) (ide1/disk) (hd) (utltra0)
> 
> My guess is kernel.elf doesn't include the necessary code.  It's about
> 60k long.

Sounds like "DISK-LABEL: read of block0 failed" is printed by the firmware
and not by GRUB.

Also, device enumeration is the same for all devices, so the fact that it
only appears for some of them hints at a firmware bug.

What happens if you set debug=disk ?

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Testing on PowerMac G4

[Pavel Roskin]

Quoting Robert Millan <rmh@aybabtu.com>:

>> My guess is kernel.elf doesn't include the necessary code.  It's about
>> 60k long.

Now I'm sure about that.  Unfortunately, grub-mkimage produces images  
that the OpenFirmware fails to load with "CLAIM failed" (even with  
just one short module).  Indeed, bad things started with the first  
commit on 2007-02-21.  I'm afraid I won't be able to figure it out  
without Hollis.

(Not to put any pressure of anyone, but GNU ChangeLog shows its age  
here - the detailed changes are described, but the motivation behind  
the whole patch is not, yet the details can be recovered with the  
version control, whereas the motivation has to be guessed)

> Sounds like "DISK-LABEL: read of block0 failed" is printed by the firmware
> and not by GRUB.
>
> Also, device enumeration is the same for all devices, so the fact that it
> only appears for some of them hints at a firmware bug.

Both ide0/disk and cd refer to the CD-ROM.  The messages are not shown  
if there is a CD in the drive.

> What happens if you set debug=disk ?

Typing from another monitor, sorry for possible typos.

grub rescue> ls
(ide0/disk) kern/disk.c:220: Opening `ide0/disk'...
disk/ieee1275/ofdisk.c:65: Opening `ide0/disk:0'.
DISK-LABEL: read of block0 failed.
kern/disk.c:299: Opening `ide0/disk' failed.
kern/disk.c:312: Closing `ide0/disk'.
(cd) kern/disk.c:220: Opening `cd'...
disk/ieee1275/ofdisk.c:65: Opening `cd:0'.
DISK-LABEL: read of block0 failed.
kern/disk.c:299: Opening `cd' failed.
kern/disk.c:312: Closing `cd'.
(zip) kern/disk.c:220: Opening `zip'...
disk/ieee1275/ofdisk.c:65: Opening `zip:0'.
kern/disk.c:299: Opening `zip' failed.
kern/disk.c:312: Closing `zip'.
(disk/ide1) kern/disk.c:220: Opening `ide1/disk'...
disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'.
disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
kern/disk.c:299: Opening `ide1/disk' failed.
kern/disk.c:312: Closing `ide1/disk'.
(hd) kern/disk.c:220: Opening `hd'...
disk/ieee1275/ofdisk.c:65: Opening `hd:0'.
disk/ieee1275/ofdisk.c:74: Opened `hd:0' as handle 0xff9d1c00.
kern/disk.c:299: Opening `hd' failed.
kern/disk.c:312: Closing `hd'.
(ultra0) kern/disk.c:220: Opening `ultra0'...
disk/ieee1275/ofdisk.c:65: Opening `ultra0:0'.
disk/ieee1275/ofdisk.c:74: Opened `ultra0:0' as handle 0xff9d1c00.
kern/disk.c:299: Opening `ultra0' failed.
kern/disk.c:312: Closing `ultra0'.

error: unknown device
grub rescue>

-- 
Regards,
Pavel Roskin

Re: Testing on PowerMac G4

[Robert Millan]

On Wed, Jan 02, 2008 at 01:46:04AM -0500, Pavel Roskin wrote:
> Quoting Robert Millan <rmh@aybabtu.com>:
> 
> >>My guess is kernel.elf doesn't include the necessary code.  It's about
> >>60k long.
> 
> Now I'm sure about that.  Unfortunately, grub-mkimage produces images  
> that the OpenFirmware fails to load with "CLAIM failed" (even with  
> just one short module).  Indeed, bad things started with the first  
> commit on 2007-02-21.  I'm afraid I won't be able to figure it out  
> without Hollis.

It can mostly be solved by analizing/testing the regression diff.

In August I sent an updated version that might be helpful:

  http://lists.gnu.org/archive/html/grub-devel/2007-08/msg00031.html

just take the grub-mkimage.c part of it and try to revert it on CVS HEAD,
that would confirm it's a grub-mkimage problem.  Then apply the hunks
selectively untill you find the exact change that broke it.  And finally
it's just a matter of "looking hard" at that hunk untill it's coerced to
reveal the problem :-)

This seems to affect many powermac users.  I'd have gone through the bug
myself, but I don't have access to the hardware.

> (Not to put any pressure of anyone, but GNU ChangeLog shows its age  
> here - the detailed changes are described, but the motivation behind  
> the whole patch is not, yet the details can be recovered with the  
> version control, whereas the motivation has to be guessed)

Full ack.  But, you didn't mention any alternative.

> Both ide0/disk and cd refer to the CD-ROM.  The messages are not shown  
> if there is a CD in the drive.
> 
> >What happens if you set debug=disk ?
> 
> Typing from another monitor, sorry for possible typos.
> 
> disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'.
> disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
> kern/disk.c:299: Opening `ide1/disk' failed.
> kern/disk.c:312: Closing `ide1/disk'.

This seems to be contradictory.  If OF returned a handle, why does the
open fail ?  Looks like GRUB doesn't like something but isn't telling you
what.  I'd investigate that part;  at the least it can mean our error
handling isn't good enough.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Testing on PowerMac G4

[Pavel Roskin]

Quoting Robert Millan <rmh@aybabtu.com>:

> just take the grub-mkimage.c part of it and try to revert it on CVS HEAD,
> that would confirm it's a grub-mkimage problem.  Then apply the hunks
> selectively untill you find the exact change that broke it.  And finally
> it's just a matter of "looking hard" at that hunk untill it's coerced to
> reveal the problem :-)

OK, here's what I have so far.  The patch tries to make the memory  
layout more compact.  Two changes are make to the layout.  kernel.elf  
is loaded at 64k instead of 2M and the modules are loaded at the  
lowest 4k boundary after kernel.elf rather that at 3M.

Moving the kernel.elf load address is fine.  Moving the modules is not.

The module base address is calculated separately in kernel.elf and in  
grub-mkimage.  kernel.elf uses the "_end" symbol, whereas grub-mkimage  
looks for the ELF segment with the highest end address.

One problem in grub-mkimage is the infamous build ID, which is present  
in kernel.elf.  It is located in a loadable segment starting at  
0x10000d4 (i.e. just about 256M).  That's what confuses objcopy, and  
it must be confusing grub-mkimage as well.

I actually doubt that it's the right behavior to go through segments.   
The "_end" marker should be located in a specific segment.  And if the  
search through segments is correct, then maybe grub-mkimage should  
hardcore the module base into the output, rather than rely on  
kernel.elf doing the same calculation and getting the same result.

All I need to to do fix the problem is to make kernel.elf and  
grub-mkimage come to the same value of the module base address.

>> (Not to put any pressure of anyone, but GNU ChangeLog shows its age
>> here - the detailed changes are described, but the motivation behind
>> the whole patch is not, yet the details can be recovered with the
>> version control, whereas the motivation has to be guessed)
>
> Full ack.  But, you didn't mention any alternative.

Linux style description.  The first line is the synopsis.  If it  
doesn't fit 72 characters, the patch is a candidate for splitting.   
Then an empty line.  Then a more detailed description of the patch,  
including the motivation behind the changes.  The list of the affected  
files can be generated by the version control system.

The linear ChangeLog with everybody changing it in the same place (in  
the beginning) doesn't work well with parallel development.

>> Both ide0/disk and cd refer to the CD-ROM.  The messages are not shown
>> if there is a CD in the drive.
>>
>> >What happens if you set debug=disk ?
>>
>> Typing from another monitor, sorry for possible typos.
>>
>> disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'.
>> disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
>> kern/disk.c:299: Opening `ide1/disk' failed.
>> kern/disk.c:312: Closing `ide1/disk'.
>
> This seems to be contradictory.  If OF returned a handle, why does the
> open fail ?  Looks like GRUB doesn't like something but isn't telling you
> what.  I'd investigate that part;  at the least it can mean our error
> handling isn't good enough.

Actually, there are no "failures" with the version from 2007-02-20.   
But maybe it's because in the normal mode with all modules loaded,  
unlike bare kernel.elf.

-- 
Regards,
Pavel Roskin

Re: Testing on PowerMac G4

[Robert Millan]

On Thu, Jan 03, 2008 at 03:09:17AM -0500, Pavel Roskin wrote:
> Quoting Robert Millan <rmh@aybabtu.com>:
> 
> >just take the grub-mkimage.c part of it and try to revert it on CVS HEAD,
> >that would confirm it's a grub-mkimage problem.  Then apply the hunks
> >selectively untill you find the exact change that broke it.  And finally
> >it's just a matter of "looking hard" at that hunk untill it's coerced to
> >reveal the problem :-)
> 
> OK, here's what I have so far.  The patch tries to make the memory  
> layout more compact.  Two changes are make to the layout.  kernel.elf  
> is loaded at 64k instead of 2M and the modules are loaded at the  
> lowest 4k boundary after kernel.elf rather that at 3M.
> 
> Moving the kernel.elf load address is fine.  Moving the modules is not.
> 
> The module base address is calculated separately in kernel.elf and in  
> grub-mkimage.  kernel.elf uses the "_end" symbol, whereas grub-mkimage  
> looks for the ELF segment with the highest end address.

Ok, so you mean this setting:

  phdr->p_vaddr = grub_host_to_target32 (modbase);
  phdr->p_paddr = grub_host_to_target32 (modbase);

is not what it's used to calculate _end ?

I thought _end was calculated by the ELF loader (our own ELF loader,
multiboot.c seems to calculate _end and pass it to its payload).

> One problem in grub-mkimage is the infamous build ID, which is present  
> in kernel.elf.  It is located in a loadable segment starting at  
> 0x10000d4 (i.e. just about 256M).  That's what confuses objcopy, and  
> it must be confusing grub-mkimage as well.

Isn't build ID a recent change in binutils?  We had this problem for a while.

> I actually doubt that it's the right behavior to go through segments.   

No idea about that I'm afraid :-(

> Linux style description.  The first line is the synopsis.  If it  
> doesn't fit 72 characters, the patch is a candidate for splitting.   
> Then an empty line.  Then a more detailed description of the patch,  
> including the motivation behind the changes.  The list of the affected  
> files can be generated by the version control system.

Looks good.  But I guess you'll have to convince Marco and Okuji about this :-)

> The linear ChangeLog with everybody changing it in the same place (in  
> the beginning) doesn't work well with parallel development.

It's not that much of a problem, I just write them in the patch header and
copy them at the last minute before commit.

> >>disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'.
> >>disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
> >>kern/disk.c:299: Opening `ide1/disk' failed.
> >>kern/disk.c:312: Closing `ide1/disk'.
> >
> >This seems to be contradictory.  If OF returned a handle, why does the
> >open fail ?  Looks like GRUB doesn't like something but isn't telling you
> >what.  I'd investigate that part;  at the least it can mean our error
> >handling isn't good enough.
> 
> Actually, there are no "failures" with the version from 2007-02-20.   

Does a snapshot from 2007-02-21 also have this problem?

> But maybe it's because in the normal mode with all modules loaded,  
> unlike bare kernel.elf.

But you don't need modules for ofdisk to work, it's built into the kernel.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Testing on PowerMac G4

[Pavel Roskin]

Quoting Robert Millan <rmh@aybabtu.com>:

>> The module base address is calculated separately in kernel.elf and in
>> grub-mkimage.  kernel.elf uses the "_end" symbol, whereas grub-mkimage
>> looks for the ELF segment with the highest end address.
>
> Ok, so you mean this setting:
>
>   phdr->p_vaddr = grub_host_to_target32 (modbase);
>   phdr->p_paddr = grub_host_to_target32 (modbase);
>
> is not what it's used to calculate _end ?

OK, it turns out the values of _end actually match, so it's not a problem.

It turns out there needs to be a gap between _end and the module base.  
  16k (0x4000) is not enough.  32k (0x8000) is enough.

This patch against the current CVS version fixes loading:

diff --git a/kern/powerpc/ieee1275/init.c b/kern/powerpc/ieee1275/init.c
index 4727d7d..d2fa980 100644
--- a/kern/powerpc/ieee1275/init.c
+++ b/kern/powerpc/ieee1275/init.c
@@ -231,5 +231,5 @@ grub_get_rtc (void)
  grub_addr_t
  grub_arch_modules_addr (void)
  {
-  return ALIGN_UP(_end, GRUB_MOD_ALIGN);
+  return ALIGN_UP(_end + 0x8000, GRUB_MOD_ALIGN);
  }
diff --git a/util/elf/grub-mkimage.c b/util/elf/grub-mkimage.c
index 9e44af1..c39717a 100644
--- a/util/elf/grub-mkimage.c
+++ b/util/elf/grub-mkimage.c
@@ -228,6 +228,7 @@ add_segments (char *dir, FILE *out, int chrp, char  
*mods[])
        phdr->p_offset = grub_host_to_target32 (ALIGN_UP  
(grub_util_get_fp_size (out),
  						   sizeof (long)));

+      modbase += 0x8000;
        load_modules (modbase, phdr, dir, mods, out);
      }

>> One problem in grub-mkimage is the infamous build ID, which is present
>> in kernel.elf.  It is located in a loadable segment starting at
>> 0x10000d4 (i.e. just about 256M).  That's what confuses objcopy, and
>> it must be confusing grub-mkimage as well.
>
> Isn't build ID a recent change in binutils?  We had this problem for a while.

I haven't looked at binutils yet.  Anyway, the problem doesn't exist  
with the current grub code because it suppressed build ID on  
kernel.elf.  My workaround to get older grub compiled didn't actually  
strip build ID, it just fooled the objcopy test.

But it would be great to detect and skip the segment corresponding to  
the build ID in grub-mkimage, just to make it more robust.

>> I actually doubt that it's the right behavior to go through segments.
>
> No idea about that I'm afraid :-(

We need to figure out why the extra gap is needed.  Maybe something  
doesn't get counted.

>> Linux style description.  The first line is the synopsis.  If it
>> doesn't fit 72 characters, the patch is a candidate for splitting.
>> Then an empty line.  Then a more detailed description of the patch,
>> including the motivation behind the changes.  The list of the affected
>> files can be generated by the version control system.
>
> Looks good.  But I guess you'll have to convince Marco and Okuji   
> about this :-)

Sure, it's in my TODO list :)

>> But maybe it's because in the normal mode with all modules loaded,
>> unlike bare kernel.elf.
>
> But you don't need modules for ofdisk to work, it's built into the kernel.

Just going to the rescue mode with the "rescue" command won't cause  
those hidden failures.  It seems like they are caused by some missing  
module.  I need to look into it.

-- 
Regards,
Pavel Roskin

Re: Testing on PowerMac G4

[Robert Millan]

On Thu, Jan 03, 2008 at 10:28:46AM -0500, Pavel Roskin wrote:
> Quoting Robert Millan <rmh@aybabtu.com>:
> 
> >>The module base address is calculated separately in kernel.elf and in
> >>grub-mkimage.  kernel.elf uses the "_end" symbol, whereas grub-mkimage
> >>looks for the ELF segment with the highest end address.
> >
> >Ok, so you mean this setting:
> >
> >  phdr->p_vaddr = grub_host_to_target32 (modbase);
> >  phdr->p_paddr = grub_host_to_target32 (modbase);
> >
> >is not what it's used to calculate _end ?
> 
> OK, it turns out the values of _end actually match, so it's not a problem.
> 
> It turns out there needs to be a gap between _end and the module base.  
>  16k (0x4000) is not enough.  32k (0x8000) is enough.

Why?  Does the firmware impose this restriction, or is it GRUB itself that
gets confused?

> This patch against the current CVS version fixes loading:
> 
> diff --git a/kern/powerpc/ieee1275/init.c b/kern/powerpc/ieee1275/init.c
> index 4727d7d..d2fa980 100644
> --- a/kern/powerpc/ieee1275/init.c
> +++ b/kern/powerpc/ieee1275/init.c
> @@ -231,5 +231,5 @@ grub_get_rtc (void)
>  grub_addr_t
>  grub_arch_modules_addr (void)
>  {
> -  return ALIGN_UP(_end, GRUB_MOD_ALIGN);
> +  return ALIGN_UP(_end + 0x8000, GRUB_MOD_ALIGN);
>  }
> diff --git a/util/elf/grub-mkimage.c b/util/elf/grub-mkimage.c
> index 9e44af1..c39717a 100644
> --- a/util/elf/grub-mkimage.c
> +++ b/util/elf/grub-mkimage.c
> @@ -228,6 +228,7 @@ add_segments (char *dir, FILE *out, int chrp, char  
> *mods[])
>        phdr->p_offset = grub_host_to_target32 (ALIGN_UP  
> (grub_util_get_fp_size (out),
>  						   sizeof (long)));
> 
> +      modbase += 0x8000;
>        load_modules (modbase, phdr, dir, mods, out);
>      }

This might differ from the init.c counterpart.  There's an ALIGN_UP just
a few lines above, if you set it to:

  modbase = ALIGN_UP(grub_end + 0x8000, GRUB_MOD_ALIGN);

both alignment and 0x8000 gap are still garanteed, without claiming more
space than necessary.

That is, if it really is a gap that you need :-)

> I haven't looked at binutils yet.  Anyway, the problem doesn't exist  
> with the current grub code because it suppressed build ID on  
> kernel.elf.  My workaround to get older grub compiled didn't actually  
> strip build ID, it just fooled the objcopy test.

Ah, ok.

> But it would be great to detect and skip the segment corresponding to  
> the build ID in grub-mkimage, just to make it more robust.

Can we make this work per inclusion rather than exclusion?  The names
of needed segments are well-known, right?

> >>I actually doubt that it's the right behavior to go through segments.
> >
> >No idea about that I'm afraid :-(
> 
> We need to figure out why the extra gap is needed.  Maybe something  
> doesn't get counted.

Yep.  How did you find that an extra gap solves the problem?

> >>But maybe it's because in the normal mode with all modules loaded,
> >>unlike bare kernel.elf.
> >
> >But you don't need modules for ofdisk to work, it's built into the kernel.
> 
> Just going to the rescue mode with the "rescue" command won't cause  
> those hidden failures.  It seems like they are caused by some missing  
> module.  I need to look into it.

It might be simpler than this.  If you check what is the code flow between
those two:

disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
kern/disk.c:299: Opening `ide1/disk' failed.

that'll give more details.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Testing on PowerMac G4

[Pavel Roskin]

Quoting Robert Millan <rmh@aybabtu.com>:

> On Thu, Jan 03, 2008 at 10:28:46AM -0500, Pavel Roskin wrote:
>> Quoting Robert Millan <rmh@aybabtu.com>:
>>
>> >>The module base address is calculated separately in kernel.elf and in
>> >>grub-mkimage.  kernel.elf uses the "_end" symbol, whereas grub-mkimage
>> >>looks for the ELF segment with the highest end address.
>> >
>> >Ok, so you mean this setting:
>> >
>> >  phdr->p_vaddr = grub_host_to_target32 (modbase);
>> >  phdr->p_paddr = grub_host_to_target32 (modbase);
>> >
>> >is not what it's used to calculate _end ?

I can answer it now.  No, it's not used to calculate _end, it needs to  
be incremented separately.

>> OK, it turns out the values of _end actually match, so it's not a problem.
>>
>> It turns out there needs to be a gap between _end and the module base.
>>  16k (0x4000) is not enough.  32k (0x8000) is enough.
>
> Why?  Does the firmware impose this restriction, or is it GRUB itself that
> gets confused?

I wish I knew it.  0x7000 is not OK, 0x8000 is OK.  Less granularity  
makes no sense since the value is aligned at the 0x1000 boundary.

> This might differ from the init.c counterpart.  There's an ALIGN_UP just
> a few lines above, if you set it to:
>
>   modbase = ALIGN_UP(grub_end + 0x8000, GRUB_MOD_ALIGN);
>
> both alignment and 0x8000 gap are still garanteed, without claiming more
> space than necessary.
>
> That is, if it really is a gap that you need :-)

Thanks, that would be safer indeed, although it makes no difference  
for the values divisible by 0x1000.

> Can we make this work per inclusion rather than exclusion?  The names
> of needed segments are well-known, right?

Segments don't have names AFAIK.  Sections have names.  But anyway, it  
should be possible to recognize what we need.  On the other hand,  
"work per inclusion" would make me nervous about breaking other  
architectures.

>> We need to figure out why the extra gap is needed.  Maybe something
>> doesn't get counted.
>
> Yep.  How did you find that an extra gap solves the problem?

I started with the original boundary at 0x300000, then I tried  
0x30000, then _end+0xb000 (_end is something like 0x2496c), then  
_end+0x1000 and so on, until I found that 0x7000 is not enough and  
0x8000 is enough.

> It might be simpler than this.  If you check what is the code flow between
> those two:
>
> disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
> kern/disk.c:299: Opening `ide1/disk' failed.
>
> that'll give more details.

There is a possibility that grub_errno remains set to some error.

-- 
Regards,
Pavel Roskin

Re: Testing on PowerMac G4

[Robert Millan]

On Thu, Jan 03, 2008 at 11:23:01AM -0500, Pavel Roskin wrote:
> >Why?  Does the firmware impose this restriction, or is it GRUB itself that
> >gets confused?
> 
> I wish I knew it.  0x7000 is not OK, 0x8000 is OK.  Less granularity  
> makes no sense since the value is aligned at the 0x1000 boundary.

AFAICT, it can only happen in three ways:

  1- The firmware doesn't like GRUB image, and aborts with bogus errors before
  transferring control to GRUB.  You can easily tell this appart by checking
  for early "Welcome to GRUB" message.

  2- The change in layout makes GRUB issue different parameters in its claim
  requests, which the firmware doesn't like.  I'd verify that the change you
  added by setting up this 0x8000 gap propagates as a change in the parameters
  passed to claim requests (grub_ieee1275_claim() invokation), and if this is
  so, try to determine what is it in the claim request that it doesn't like
  (we already work this out mostly by heuristics e.g. see my commit in
  2007-10-07).

  3- Some twisted mind in Apple decided to add a tilt flag that is activated
  under some circumstances and makes claim requests fail afterwards, thereby
  confusing free software developers.  I hope this is not the case :-)

> >Can we make this work per inclusion rather than exclusion?  The names
> >of needed segments are well-known, right?
> 
> Segments don't have names AFAIK.  Sections have names.

Ah, right.  Sorry, I get easily confused about ELF stuff.

> >It might be simpler than this.  If you check what is the code flow between
> >those two:
> >
> >disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
> >kern/disk.c:299: Opening `ide1/disk' failed.
> >
> >that'll give more details.
> 
> There is a possibility that grub_errno remains set to some error.

Well, that's easy to tell appart with some printfs.

One thing that makes me suspicious is the ":0" bit.  We already found two
brands of firmware that have their own way of understanding what :0 means.
Maybe this is the same as GRUB_IEEE1275_FLAG_NO_PARTITION_0 ?

Btw, one thing I find very disturbing about GRUB_IEEE1275_FLAG_NO_PARTITION_0,
is that its description in ieee1275.h says this is an Apple bug, but the code
that is supposed to initialise this flag is only targetted at SmartFirmware.

Now THAT is suspicious :-)

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Testing on PowerMac G4

[Robert Millan]

On Fri, Jan 04, 2008 at 01:32:24PM +0100, Robert Millan wrote:
>   (we already work this out mostly by heuristics e.g. see my commit in
>   2007-10-07).

Erm sorry, this part is not accurate.  What I mean is that we use heuristics
when firmware is buggy and its /memory/available OFW path doesn't represent
actual memory availability.  This is probably the case here.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Testing on PowerMac G4

[Pavel Roskin]

On Fri, 2008-01-04 at 13:32 +0100, Robert Millan wrote:
> On Thu, Jan 03, 2008 at 11:23:01AM -0500, Pavel Roskin wrote:
> > >Why?  Does the firmware impose this restriction, or is it GRUB itself that
> > >gets confused?
> > 
> > I wish I knew it.  0x7000 is not OK, 0x8000 is OK.  Less granularity  
> > makes no sense since the value is aligned at the 0x1000 boundary.
> 
> AFAICT, it can only happen in three ways:
> 
>   1- The firmware doesn't like GRUB image, and aborts with bogus errors before
>   transferring control to GRUB.  You can easily tell this appart by checking
>   for early "Welcome to GRUB" message.

I'm quite sure now that it's the case.  That's how it looks on the
surface, I just was extra cautious before I had a chance to learn more
about OpenFirmware and the GRUB code.

Not only there is no "Welcome to GRUB" message, but the screen is not
erased and remains black on white.  "CLAIM failed" is followed by the
OpenFirmware prompt.  There are no messages that the execution was
interrupted, which would appear in other failure cases.

I tried to convert grub-mkimage output to the binary format, and found
that objcopy doesn't like it.  In fact, the image doesn't even survive
simple objcopy intact.  "objcopy grubof.modules grubof.modules1"
produces a file 208 bytes long.

Moreover, "objdump -h grubof.modules" doesn't show any sections at all,
whereas "objdump -p grubof.modules" shows the segments.  It seems to me
that grub-mkimage produces something that looks like and ELF file and
the first glance, but is not a valid ELF file.  I can reproduce this
problem with linuxbios images on i386.

We just cannot expect OpenFirmware to process invalid ELF files.  It can
be looking for the section headers and finding non-zero data is the gap
is not wide enough.  It can be just anything.

A quick look into util/elf/grub-mkimage.c finds "Don't bother preserving
the section headers".  I don't even know if the problem is specifically
with the section headers or with something else.  Perhaps
util/elf/grub-mkimage.c should be rewritten as a linker script, or maybe
it should use the BFD library that comes with binutils.  I'm optimistic
about the linker script, since all we need is essentially linking.

> > There is a possibility that grub_errno remains set to some error.
> 
> Well, that's easy to tell appart with some printfs.

What I see is the last invocation of grub_ofdisk_open() has grub_errno
set to 13 (EACCESS) throughout the code.  It's never unset by any
successful operations.  I think some filesystem module may be resetting
grub_errno to 0.  It's strange that I don't even see EACCESS in the
code.

A quote from the glibc manual:

These functions do not change `errno' when they succeed; thus, the value
of `errno' after a successful call is not necessarily zero, and you
should not use `errno' to determine _whether_ a call failed.  The proper
way to do that is documented for each function.  _If_ the call failed,
you can examine `errno'.

grub_ofdisk_open() is in direct violation of that rule.  The execution
can reach the "fail:" label without having failed anywhere, yet the code
returns grub_errno unconditionally.

That's not to negate your findings, of course.

-- 
Regards,
Pavel Roskin

Re: Testing on PowerMac G4

[Robert Millan]

On Fri, Jan 04, 2008 at 01:26:59PM -0500, Pavel Roskin wrote:
> > 
> > AFAICT, it can only happen in three ways:
> > 
> >   1- The firmware doesn't like GRUB image, and aborts with bogus errors before
> >   transferring control to GRUB.  You can easily tell this appart by checking
> >   for early "Welcome to GRUB" message.
> 
> I'm quite sure now that it's the case.  That's how it looks on the
> surface, I just was extra cautious before I had a chance to learn more
> about OpenFirmware and the GRUB code.
> 
> Not only there is no "Welcome to GRUB" message, but the screen is not
> erased and remains black on white.  "CLAIM failed" is followed by the
> OpenFirmware prompt.  There are no messages that the execution was
> interrupted, which would appear in other failure cases.
> 
> I tried to convert grub-mkimage output to the binary format, and found
> that objcopy doesn't like it.

If you want to confirm that it's grub-mkimage's fault, you can try booting
kernel.elf directly.  In theory it should give you a rescue prompt.

> In fact, the image doesn't even survive
> simple objcopy intact.  "objcopy grubof.modules grubof.modules1"
> produces a file 208 bytes long.

What is grubof.modules ?  I never heard of it.

> We just cannot expect OpenFirmware to process invalid ELF files.  It can
> be looking for the section headers and finding non-zero data is the gap
> is not wide enough.  It can be just anything.
> 
> A quick look into util/elf/grub-mkimage.c finds "Don't bother preserving
> the section headers".  I don't even know if the problem is specifically
> with the section headers or with something else.  Perhaps
> util/elf/grub-mkimage.c should be rewritten as a linker script, or maybe
> it should use the BFD library that comes with binutils.  I'm optimistic
> about the linker script, since all we need is essentially linking.

There's another [1] outstanding problem with elf/grub-mkimage.c:

  http://lists.gnu.org/archive/html/grub-devel/2007-10/msg00056.html

I think what you propose is a good idea.  It sounds odd that we have to
reimplement ELF handling when another GNU project already has.  But I don't
know how the GRUB maintainers think about it.

[1] or, perhaps, it's the same problem?

> > > There is a possibility that grub_errno remains set to some error.
> > 
> > Well, that's easy to tell appart with some printfs.
> 
> What I see is the last invocation of grub_ofdisk_open() has grub_errno
> set to 13 (EACCESS) throughout the code.

Wait, that would be EACCES in Linux errno codes.  In GRUB, grub_errno
13 means GRUB_ERR_UNKNOWN_DEVICE (at the time of writing; there isn't a
stable ABI for this afaik).

If grub_errno was set you should've seen an error message somewhere.  It
seems there's something wrong in our error handling. :-/

> A quote from the glibc manual:
> 
> These functions do not change `errno' when they succeed; thus, the value
> of `errno' after a successful call is not necessarily zero, and you
> should not use `errno' to determine _whether_ a call failed.  The proper
> way to do that is documented for each function.  _If_ the call failed,
> you can examine `errno'.
> 
> grub_ofdisk_open() is in direct violation of that rule.  The execution
> can reach the "fail:" label without having failed anywhere, yet the code
> returns grub_errno unconditionally.

Yeah, would be nice if functions had their behaviour more similar to Glibc
equivalents.  I'm not sure how much of a "policy" is this in GRUB, though.

> That's not to negate your findings, of course.

I would really check the GRUB_IEEE1275_FLAG_NO_PARTITION_0 issue.  It was just
a guess, but it smells really badly :-)

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Testing on PowerMac G4

[Yoshinori K. Okuji]

On Friday 04 January 2008 21:37, Robert Millan wrote:
> > A quick look into util/elf/grub-mkimage.c finds "Don't bother preserving
> > the section headers".  I don't even know if the problem is specifically
> > with the section headers or with something else.  Perhaps
> > util/elf/grub-mkimage.c should be rewritten as a linker script, or maybe
> > it should use the BFD library that comes with binutils.  I'm optimistic
> > about the linker script, since all we need is essentially linking.
>
> There's another [1] outstanding problem with elf/grub-mkimage.c:
>
>   http://lists.gnu.org/archive/html/grub-devel/2007-10/msg00056.html
>
> I think what you propose is a good idea.  It sounds odd that we have to
> reimplement ELF handling when another GNU project already has.  But I don't
> know how the GRUB maintainers think about it.
>
> [1] or, perhaps, it's the same problem?

I object to using a linker, since it is more odd that the user must install 
development tools to just install GRUB.

About BFD, the old discussion was that it made the binary size bloated, thus 
didn't fit into a small disk or initrd or whatever, so it was not convenient 
for installers. I don't know if the same discussion can apply nowadays, since 
most people install operating systems by CD or DVD, memory size is plenty, 
etc. Especially if this is only for OpenFirmware platforms, I don't believe 
that anybody cares.

Okuji

Re: Testing on PowerMac G4

[Robert Millan]

On Sat, Jan 05, 2008 at 02:45:41AM +0100, Yoshinori K. Okuji wrote:
> On Friday 04 January 2008 21:37, Robert Millan wrote:
> > > A quick look into util/elf/grub-mkimage.c finds "Don't bother preserving
> > > the section headers".  I don't even know if the problem is specifically
> > > with the section headers or with something else.  Perhaps
> > > util/elf/grub-mkimage.c should be rewritten as a linker script, or maybe
> > > it should use the BFD library that comes with binutils.  I'm optimistic
> > > about the linker script, since all we need is essentially linking.
> >
> > There's another [1] outstanding problem with elf/grub-mkimage.c:
> >
> >   http://lists.gnu.org/archive/html/grub-devel/2007-10/msg00056.html
> >
> > I think what you propose is a good idea.  It sounds odd that we have to
> > reimplement ELF handling when another GNU project already has.  But I don't
> > know how the GRUB maintainers think about it.
> >
> > [1] or, perhaps, it's the same problem?
> 
> I object to using a linker, since it is more odd that the user must install 
> development tools to just install GRUB.

Distributors could push GNU ld from development binutils package to a separate
one that is part of their base system.  This happened already in Debian (and
derivatives, gee) for gnupg and gpgv (since apt-get started using them for
archive verification).

> About BFD, the old discussion was that it made the binary size bloated, thus 
> didn't fit into a small disk or initrd or whatever, so it was not convenient 
> for installers. I don't know if the same discussion can apply nowadays, since 
> most people install operating systems by CD or DVD, memory size is plenty, 
> etc.

I don't know about others, but Debian (and, yes, derivatives..) doesn't put
grub-mkimage in the initrd.  What is put is a script that will install
standard GRUB package in the target chroot, and use that directly.

I think using BFD is a good idea.

> Especially if this is only for OpenFirmware platforms, I don't believe 
> that anybody cares.

And LinuxBIOS !  And Xbox if we ever support it (I haven't managed to boot
code in it yet, but it works with ELF).

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Testing on PowerMac G4

[Pavel Roskin]

On Fri, 2008-01-04 at 21:37 +0100, Robert Millan wrote:

> If you want to confirm that it's grub-mkimage's fault, you can try booting
> kernel.elf directly.  In theory it should give you a rescue prompt.

That's what it does.  And that's what we have been discussing closer to
the bottom :-)

> > In fact, the image doesn't even survive
> > simple objcopy intact.  "objcopy grubof.modules grubof.modules1"
> > produces a file 208 bytes long.
> 
> What is grubof.modules ?  I never heard of it.

That's the suggested name for the grub-mkimage output on PowerPC,
according to http://grub.enbug.org/TestingOnPowerPC

Yes, it's long and misleading.  Maybe it should be called grub.elf or
something.  I'm usually good at inventing new names, but I have no good
ideas this time :-)

> Wait, that would be EACCES in Linux errno codes.  In GRUB, grub_errno
> 13 means GRUB_ERR_UNKNOWN_DEVICE (at the time of writing; there isn't a
> stable ABI for this afaik).

Thanks, that explains something!

> If grub_errno was set you should've seen an error message somewhere.  It
> seems there's something wrong in our error handling. :-/

I agree.

> I would really check the GRUB_IEEE1275_FLAG_NO_PARTITION_0 issue.  It was just
> a guess, but it smells really badly :-)

I'll have a look.

-- 
Regards,
Pavel Roskin

Re: Testing on PowerMac G4

[Robert Millan]

On Fri, Jan 04, 2008 at 09:10:03PM -0500, Pavel Roskin wrote:
> On Fri, 2008-01-04 at 21:37 +0100, Robert Millan wrote:
> 
> > If you want to confirm that it's grub-mkimage's fault, you can try booting
> > kernel.elf directly.  In theory it should give you a rescue prompt.
> 
> That's what it does.  And that's what we have been discussing closer to
> the bottom :-)

Yeah, but it never hurts to be sure!

> > > In fact, the image doesn't even survive
> > > simple objcopy intact.  "objcopy grubof.modules grubof.modules1"
> > > produces a file 208 bytes long.
> > 
> > What is grubof.modules ?  I never heard of it.
> 
> That's the suggested name for the grub-mkimage output on PowerPC,
> according to http://grub.enbug.org/TestingOnPowerPC

I found this in NEWS:

  "* Use the filename "kernel.elf" instead of "grubof" on ieee1275."

Sounds like a deprecated name.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Testing on PowerMac G4

[Yoshinori K. Okuji]

On Thursday 03 January 2008 16:28, Pavel Roskin wrote:
> >> Linux style description.  The first line is the synopsis.  If it
> >> doesn't fit 72 characters, the patch is a candidate for splitting.
> >> Then an empty line.  Then a more detailed description of the patch,
> >> including the motivation behind the changes.  The list of the affected
> >> files can be generated by the version control system.
> >
> > Looks good.  But I guess you'll have to convince Marco and Okuji
> > about this :-)
>
> Sure, it's in my TODO list :)

I do not think automatically generated logs can be as precise as being made by 
human.

Anyway, there is no reason that you shouldn't write a detailed description in 
ChangeLog. Indeed, I myself sometimes do that, when I make a big change or 
something hard to understand.

Okuji

Re: Testing on PowerMac G4

[Pavel Roskin]

On Sat, 2008-01-05 at 02:27 +0100, Yoshinori K. Okuji wrote:
> On Thursday 03 January 2008 16:28, Pavel Roskin wrote:
> > >> Linux style description.  The first line is the synopsis.  If it
> > >> doesn't fit 72 characters, the patch is a candidate for splitting.
> > >> Then an empty line.  Then a more detailed description of the patch,
> > >> including the motivation behind the changes.  The list of the affected
> > >> files can be generated by the version control system.
> > >
> > > Looks good.  But I guess you'll have to convince Marco and Okuji
> > > about this :-)
> >
> > Sure, it's in my TODO list :)
> 
> I do not think automatically generated logs can be as precise as being made by 
> human.
> 
> Anyway, there is no reason that you shouldn't write a detailed description in 
> ChangeLog. Indeed, I myself sometimes do that, when I make a big change or 
> something hard to understand.

We are talking about a changeset from 2007-02-21 (the earliest of them),
where the ChangeLog entry has the usual "calculate this" and "rename
this to that".  It took me hours of experiments to figure out that the
intention was to load the core image and the modules much lower in the
memory.  Sure, it looks trivial when explained.

And by the way, a trivial change that doesn't modify anything as
fundamental as memory layout could be described in very similar terms.
There is no way to see how profound changes are and whether they are
relevant to the observed problems.

Detailed descriptions may be useful in many cases, but in my opinion,
they should be secondary to high level descriptions.

-- 
Regards,
Pavel Roskin

Re: Testing on PowerMac G4

[Yoshinori K. Okuji]

On Saturday 05 January 2008 03:02, Pavel Roskin wrote:
> On Sat, 2008-01-05 at 02:27 +0100, Yoshinori K. Okuji wrote:
> > On Thursday 03 January 2008 16:28, Pavel Roskin wrote:
> > > >> Linux style description.  The first line is the synopsis.  If it
> > > >> doesn't fit 72 characters, the patch is a candidate for splitting.
> > > >> Then an empty line.  Then a more detailed description of the patch,
> > > >> including the motivation behind the changes.  The list of the
> > > >> affected files can be generated by the version control system.
> > > >
> > > > Looks good.  But I guess you'll have to convince Marco and Okuji
> > > > about this :-)
> > >
> > > Sure, it's in my TODO list :)
> >
> > I do not think automatically generated logs can be as precise as being
> > made by human.
> >
> > Anyway, there is no reason that you shouldn't write a detailed
> > description in ChangeLog. Indeed, I myself sometimes do that, when I make
> > a big change or something hard to understand.
>
> We are talking about a changeset from 2007-02-21 (the earliest of them),
> where the ChangeLog entry has the usual "calculate this" and "rename
> this to that".  It took me hours of experiments to figure out that the
> intention was to load the core image and the modules much lower in the
> memory.  Sure, it looks trivial when explained.
>
> And by the way, a trivial change that doesn't modify anything as
> fundamental as memory layout could be described in very similar terms.
> There is no way to see how profound changes are and whether they are
> relevant to the observed problems.

You are right, but this is nothing with ChangeLog itself. If one did not write 
a good commit message, the same thing happens with any kind of system.

> Detailed descriptions may be useful in many cases, but in my opinion,
> they should be secondary to high level descriptions.

Huh? You only think about the technical aspect. Note that ChangeLog is not 
only for technical purpose.

http://www.gnu.org/prep/maintain/html_node/Legally-Significant.html#Legally-Significant

Okuji

Re: Testing on PowerMac G4

[Robert Millan]

On Sat, Jan 05, 2008 at 02:27:34AM +0100, Yoshinori K. Okuji wrote:
> 
> Anyway, there is no reason that you shouldn't write a detailed description in 
> ChangeLog. Indeed, I myself sometimes do that, when I make a big change or 
> something hard to understand.

Good enough for me..  I'll take it into account.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Testing on PowerMac G4

[Robert Millan]

On Mon, Dec 31, 2007 at 03:12:29AM -0500, Pavel Roskin wrote:
> Hello!
> 
> I have tried the current GRUB on a PowerMac G4 running Fedora 8.
> 
> If I follow the instructions at  
> http://grub.enbug.org/TestingOnPowerPC, I cannot load grubof.modules.   
> If I do it directly from openfirmware, I get "CLAIM failed" message.

Known problem.  I fixed this for Efika, but for some reason my fix didn't work
for PowerMac.  Anyway, first of all I'd verify that if you revert to CVS
version before this commit:

  2007-02-21  Hollis Blanchard  <hollis@penguinppc.org>

  (both of them, actually)

it works again.

I believe the kern/powerpc/ieee1275/init.c part of things doesn't need to be
touched again after:

  2007-10-07  Robert Millan  <rmh@aybabtu.com>

and that the problem affecting PowerMac was introduces with the rest of Hollis
commit (that would be grub-mkimage.c ?).

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)

Re: Testing on PowerMac G4

[Pavel Roskin]

On Mon, 2007-12-31 at 15:04 +0100, Robert Millan wrote:
> On Mon, Dec 31, 2007 at 03:12:29AM -0500, Pavel Roskin wrote:
> > Hello!
> > 
> > I have tried the current GRUB on a PowerMac G4 running Fedora 8.
> > 
> > If I follow the instructions at  
> > http://grub.enbug.org/TestingOnPowerPC, I cannot load grubof.modules.   
> > If I do it directly from openfirmware, I get "CLAIM failed" message.
> 
> Known problem.  I fixed this for Efika, but for some reason my fix didn't work
> for PowerMac.  Anyway, first of all I'd verify that if you revert to CVS
> version before this commit:
> 
>   2007-02-21  Hollis Blanchard  <hollis@penguinppc.org>
> 
>   (both of them, actually)
> 
> it works again.

Yes, it's working.  If doesn't load grub.cfg by default, but if I load
it with "configfile", I can boot Linux from the menu!

Sorry, I had to switch to a G3 machine in the meantime, and I didn't
have a chance to test the current code on G3 system yet.  "CLAIM failed"
was on G4.

-- 
Regards,
Pavel Roskin