2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[Ben Gardner]

Hi all,

I'm using the Geode GX processor and the associated frame buffer
driver in 2.6.19-rc5.
I have a 640x480 LCD attached, without DDC support (not sure if that matters).

The frame buffer driver takes 12.5 seconds to initialize.

Is this normal?

Relevant kernel log:
[   18.516093] io scheduler deadline registered (default)
[   18.539818] gxfb 0000:00:01.1: 16384 Kibyte of video memory at 0x41000000
[   31.052135] Console: switching to colour frame buffer device 80x30
[   31.070906] fb0: Geode GX frame buffer device
[   31.094200] Real Time Clock Driver v1.12ac

I tried building the driver as a module, but that makes no difference
-- modprobe 'hangs' for 13 seconds.

I looked through the Geode driver code and didn't see anything obvious
that would eat up 13 seconds.

Any idea as to what is going on?

Thanks,
Ben

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[James Simmons]

> Hi all,
> 
> I'm using the Geode GX processor and the associated frame buffer
> driver in 2.6.19-rc5.
> I have a 640x480 LCD attached, without DDC support (not sure if that matters).
> 
> The frame buffer driver takes 12.5 seconds to initialize.
> 
> Is this normal?
> 
> Relevant kernel log:
> [   18.516093] io scheduler deadline registered (default)
> [   18.539818] gxfb 0000:00:01.1: 16384 Kibyte of video memory at 0x41000000
> [   31.052135] Console: switching to colour frame buffer device 80x30
> [   31.070906] fb0: Geode GX frame buffer device
> [   31.094200] Real Time Clock Driver v1.12ac
> 
> I tried building the driver as a module, but that makes no difference
> -- modprobe 'hangs' for 13 seconds.
> 
> I looked through the Geode driver code and didn't see anything obvious
> that would eat up 13 seconds.
> 
> Any idea as to what is going on?

No idea. I do have hardware with this chipset altho I don't have a 2.6.X 
kernel running on it. So I will see what the problem is in the next few 
weeks.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[Jordan Crouse]

On 16/11/06 10:29 -0600, Ben Gardner wrote:
> Hi all,
> 
> I'm using the Geode GX processor and the associated frame buffer
> driver in 2.6.19-rc5.
> I have a 640x480 LCD attached, without DDC support (not sure if that 
> matters).
> 
> The frame buffer driver takes 12.5 seconds to initialize.
> 
> Is this normal?

It shouldn't be.  We're beating the stuffing out of this driver for the 
OLPCs, and people certainly would have complained loudly if it didn't work.  
We are building it in (rather then as a module) so its not exactly an 
equivalent test.

Can you get any indication of where the break down is happening during
the init sequence?

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[Ben Gardner]

I tracked it down to the memset_io() call in gxfb_core.c that clears
all the video memory.

It take 12.5 seconds to memset() a mere 16,384 Kibyte of memory.
That seems a bit strange to me.

What's stranger is the time it takes to clear the fb memory:
The first 4 MB clear in 0.01 s each.
The last 12MB are SLOW.

Check out this dd output:
~ # time dd if=/dev/zero of=/dev/fb0 bs=1M count=4
4+0 records in
4+0 records out
real    0m 0.04s
user    0m 0.00s
sys     0m 0.04s
~ # time dd if=/dev/zero of=/dev/fb0 bs=1M count=5
5+0 records in
5+0 records out
real    0m 1.08s
user    0m 0.00s
sys     0m 1.08s
~ # time dd if=/dev/zero of=/dev/fb0 bs=1M count=10
10+0 records in
10+0 records out
real    0m 6.29s
user    0m 0.00s
sys     0m 6.29s
~ # time dd if=/dev/zero of=/dev/fb0 bs=1M count=16
16+0 records in
16+0 records out
real    0m 12.54s
user    0m 0.00s
sys     0m 12.54s

Removing the memset_io() didn't seem to affect anything other than
speeding the boot by 12.5 seconds.

Would anyone object to a patch that removes the call to memset_io() ?

If there's some reason why that shouldn't be removed, is it OK to
reduce the memset_io() to clear the memory used by the current
resolution (xres * yres * bpp / 8)?

Thanks,
Ben

On 11/20/06, James Simmons <jsimmons@infradead.org> wrote:
>
> > Hi all,
> >
> > I'm using the Geode GX processor and the associated frame buffer
> > driver in 2.6.19-rc5.
> > I have a 640x480 LCD attached, without DDC support (not sure if that matters).
> >
> > The frame buffer driver takes 12.5 seconds to initialize.
> >
> > Is this normal?
> >
> > Relevant kernel log:
> > [   18.516093] io scheduler deadline registered (default)
> > [   18.539818] gxfb 0000:00:01.1: 16384 Kibyte of video memory at 0x41000000
> > [   31.052135] Console: switching to colour frame buffer device 80x30
> > [   31.070906] fb0: Geode GX frame buffer device
> > [   31.094200] Real Time Clock Driver v1.12ac
> >
> > I tried building the driver as a module, but that makes no difference
> > -- modprobe 'hangs' for 13 seconds.
> >
> > I looked through the Geode driver code and didn't see anything obvious
> > that would eat up 13 seconds.
> >
> > Any idea as to what is going on?
>
> No idea. I do have hardware with this chipset altho I don't have a 2.6.X
> kernel running on it. So I will see what the problem is in the next few
> weeks.
>
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[Jordan Crouse]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On 20/11/06 16:47 -0600, Ben Gardner wrote:
> I tracked it down to the memset_io() call in gxfb_core.c that clears
> all the video memory.
> 
> It take 12.5 seconds to memset() a mere 16,384 Kibyte of memory.
> That seems a bit strange to me.
> 
> What's stranger is the time it takes to clear the fb memory:
> The first 4 MB clear in 0.01 s each.
> The last 12MB are SLOW.
 
Hmmm - thats interesting.  One thing about the current gxfb driver is that
it assumes a 16Mb framebuffer, which may or may not be what you have, since 
the amount of memory that is assigned to the graphics engine is configurable.

Its possible that you only have 4Mb of memory assigned to the graphics
engine, and that memsetting further is out being subtractively decoded on
the PCI bus and going nowhere slowly.

The attached patch queries the BIOS for the true amount of memory that
is configured.  The patch has been kicking around in the Geode git tree and 
-mm for a while so it should be sane.  Give it a try and see if it helps.

Jordan

[-- Attachment #2: patch_011 --]
[-- Type: text/plain, Size: 1434 bytes --]

Author: Jordan Crouse <jordan.crouse@amd.com>
Date:   Mon May 15 20:54:51 2006 -0600

    FB: Get the Geode GX frambuffer size from the BIOS
    
    Use the Geode GX BIOS virtual registers to get the actual size of the
    framebuffer.
    
    Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>

diff --git a/drivers/video/geode/display_gx.c b/drivers/video/geode/display_gx.c
index 825c340..0245169 100644
--- a/drivers/video/geode/display_gx.c
+++ b/drivers/video/geode/display_gx.c
@@ -21,10 +21,19 @@ #include <asm/delay.h>
 #include "geodefb.h"
 #include "display_gx.h"
 
-int gx_frame_buffer_size(void)
+unsigned int gx_frame_buffer_size(void)
 {
-	/* Assuming 16 MiB. */
-	return 16*1024*1024;
+	unsigned int val;
+
+	/* FB size is reported by a virtual register */
+	/* Virtual register class = 0x02 */
+	/* VG_MEM_SIZE(512Kb units) = 0x00 */
+
+	outw(0xFC53, 0xAC1C);
+	outw(0x0200, 0xAC1C);
+
+	val = (unsigned int)(inw(0xAC1E)) & 0xFFl;
+	return (val << 19);
 }
 
 int gx_line_delta(int xres, int bpp)
diff --git a/drivers/video/geode/display_gx.h b/drivers/video/geode/display_gx.h
index 86c6233..41e79f4 100644
--- a/drivers/video/geode/display_gx.h
+++ b/drivers/video/geode/display_gx.h
@@ -11,7 +11,7 @@
 #ifndef __DISPLAY_GX_H__
 #define __DISPLAY_GX_H__
 
-int gx_frame_buffer_size(void);
+unsigned int gx_frame_buffer_size(void);
 int gx_line_delta(int xres, int bpp);
 
 extern struct geode_dc_ops gx_dc_ops;


[-- Attachment #3: Type: text/plain, Size: 347 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #4: Type: text/plain, Size: 182 bytes --]

_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[Ben Gardner]

Hi Jordan,

Now that you mention it, the kernel logs say it has 123 MB of LOWMEM,
so it must have 4 MB allocated to video memory. (128 MB total).

I'll try the patch on Monday -- I'm on holiday and don't have access
to the hardware.

If it works, (and I assume it will), can we get this pushed into the
main kernel tree?
IMO, this is a bug fix, not a new feature. =)

Thanks,
Ben

On 11/20/06, Jordan Crouse <jordan.crouse@amd.com> wrote:
> On 20/11/06 16:47 -0600, Ben Gardner wrote:
> > I tracked it down to the memset_io() call in gxfb_core.c that clears
> > all the video memory.
> >
> > It take 12.5 seconds to memset() a mere 16,384 Kibyte of memory.
> > That seems a bit strange to me.
> >
> > What's stranger is the time it takes to clear the fb memory:
> > The first 4 MB clear in 0.01 s each.
> > The last 12MB are SLOW.
>
> Hmmm - thats interesting.  One thing about the current gxfb driver is that
> it assumes a 16Mb framebuffer, which may or may not be what you have, since
> the amount of memory that is assigned to the graphics engine is configurable.
>
> Its possible that you only have 4Mb of memory assigned to the graphics
> engine, and that memsetting further is out being subtractively decoded on
> the PCI bus and going nowhere slowly.
>
> The attached patch queries the BIOS for the true amount of memory that
> is configured.  The patch has been kicking around in the Geode git tree and
> -mm for a while so it should be sane.  Give it a try and see if it helps.
>
> Jordan
>
>
> Author: Jordan Crouse <jordan.crouse@amd.com>
> Date:   Mon May 15 20:54:51 2006 -0600
>
>     FB: Get the Geode GX frambuffer size from the BIOS
>
>     Use the Geode GX BIOS virtual registers to get the actual size of the
>     framebuffer.
>
>     Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
>
> diff --git a/drivers/video/geode/display_gx.c b/drivers/video/geode/display_gx.c
> index 825c340..0245169 100644
> --- a/drivers/video/geode/display_gx.c
> +++ b/drivers/video/geode/display_gx.c
> @@ -21,10 +21,19 @@ #include <asm/delay.h>
>  #include "geodefb.h"
>  #include "display_gx.h"
>
> -int gx_frame_buffer_size(void)
> +unsigned int gx_frame_buffer_size(void)
>  {
> -       /* Assuming 16 MiB. */
> -       return 16*1024*1024;
> +       unsigned int val;
> +
> +       /* FB size is reported by a virtual register */
> +       /* Virtual register class = 0x02 */
> +       /* VG_MEM_SIZE(512Kb units) = 0x00 */
> +
> +       outw(0xFC53, 0xAC1C);
> +       outw(0x0200, 0xAC1C);
> +
> +       val = (unsigned int)(inw(0xAC1E)) & 0xFFl;
> +       return (val << 19);
>  }
>
>  int gx_line_delta(int xres, int bpp)
> diff --git a/drivers/video/geode/display_gx.h b/drivers/video/geode/display_gx.h
> index 86c6233..41e79f4 100644
> --- a/drivers/video/geode/display_gx.h
> +++ b/drivers/video/geode/display_gx.h
> @@ -11,7 +11,7 @@
>  #ifndef __DISPLAY_GX_H__
>  #define __DISPLAY_GX_H__
>
> -int gx_frame_buffer_size(void);
> +unsigned int gx_frame_buffer_size(void);
>  int gx_line_delta(int xres, int bpp);
>
>  extern struct geode_dc_ops gx_dc_ops;
>
>
>
>

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[James Simmons]

Thank you :-) If this works it will save me alot of trouble.

On Mon, 20 Nov 2006, Jordan Crouse wrote:

> On 20/11/06 16:47 -0600, Ben Gardner wrote:
> > I tracked it down to the memset_io() call in gxfb_core.c that clears
> > all the video memory.
> > 
> > It take 12.5 seconds to memset() a mere 16,384 Kibyte of memory.
> > That seems a bit strange to me.
> > 
> > What's stranger is the time it takes to clear the fb memory:
> > The first 4 MB clear in 0.01 s each.
> > The last 12MB are SLOW.
>  
> Hmmm - thats interesting.  One thing about the current gxfb driver is that
> it assumes a 16Mb framebuffer, which may or may not be what you have, since 
> the amount of memory that is assigned to the graphics engine is configurable.
> 
> Its possible that you only have 4Mb of memory assigned to the graphics
> engine, and that memsetting further is out being subtractively decoded on
> the PCI bus and going nowhere slowly.
> 
> The attached patch queries the BIOS for the true amount of memory that
> is configured.  The patch has been kicking around in the Geode git tree and 
> -mm for a while so it should be sane.  Give it a try and see if it helps.
> 
> Jordan
> 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[Ben Gardner]

Hi Jordan,

> > Author: Jordan Crouse <jordan.crouse@amd.com>
> > Date:   Mon May 15 20:54:51 2006 -0600
> >
> >     FB: Get the Geode GX frambuffer size from the BIOS
> >
> >     Use the Geode GX BIOS virtual registers to get the actual size of the
> >     framebuffer.
> >
> >     Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>

The patch works. The frame buffer size now matches what is really there (4 MB).

Out of curiosity, where are the magic registers (0xAC1C, 0xAC1E) documented?
I searched "AMD Geode GX Processors Data Book", but had no luck...

Also, I notice that the pci_resource_len() shows 16 MB, even though
the resource should only cover 4 MB.  I assume this is a BIOS bug...
=)

Is there anything I can do to help get this pushed into the 2.6.19 kernel?

Thanks,
Ben

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[James Simmons]

> Hi Jordan,
> 
> > > Author: Jordan Crouse <jordan.crouse@amd.com>
> > > Date:   Mon May 15 20:54:51 2006 -0600
> > >
> > >     FB: Get the Geode GX frambuffer size from the BIOS
> > >
> > >     Use the Geode GX BIOS virtual registers to get the actual size of the
> > >     framebuffer.
> > >
> > >     Signed-off-by: Jordan Crouse <jordan.crouse@amd.com>
> 
> The patch works. The frame buffer size now matches what is really there (4
> MB).
> 
> Out of curiosity, where are the magic registers (0xAC1C, 0xAC1E) documented?
> I searched "AMD Geode GX Processors Data Book", but had no luck...
> 
> Also, I notice that the pci_resource_len() shows 16 MB, even though
> the resource should only cover 4 MB.  I assume this is a BIOS bug...
> =)
> 
> Is there anything I can do to help get this pushed into the 2.6.19 kernel?

Jordan can you repost the patch and CC andrew morton with it so the patch 
will be in the -mm tree. Thank you.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[Jordan Crouse]

On 27/11/06 10:28 -0600, Ben Gardner wrote:
> Out of curiosity, where are the magic registers (0xAC1C, 0xAC1E) documented?
> I searched "AMD Geode GX Processors Data Book", but had no luck...

Those are virtual magic registers courtesy of our VSA.  The document is
on the Developers website, though its probably time that I go down and throw
things until the technical marketing department agrees to put that document
on the public site as well.

> Also, I notice that the pci_resource_len() shows 16 MB, even though
> the resource should only cover 4 MB.  I assume this is a BIOS bug...
> =)

You say bug, I say limitation... :)  IIRC, PCI resource sizes can only
be powers of two, but the video memory doesn't nessesarly need to be a power
of two.    So the VSA just sets the PCI resource to 16MB and expects the
code to access the virtual register, as you have experienced.

> Is there anything I can do to help get this pushed into the 2.6.19 kernel?

Ask folks more important then me... :)  I don't know if this really
qualifies for a -rc release.  There should be nothing standing in our way
for 2.6.20, though (I hope).

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[Jordan Crouse]

> Jordan can you repost the patch and CC andrew morton with it so the patch 
> will be in the -mm tree. Thank you.

Its in the geode GIT tree
(http://git.infradead.org/?p=users/jcrouse/geode.git;a=summary), and I
believe that Andrew already pulls from there - so all should be 
well.  Am I right in saying that?

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[Andrew Morton]

On Mon, 27 Nov 2006 11:39:30 -0700
"Jordan Crouse" <jordan.crouse@amd.com> wrote:

> > Jordan can you repost the patch and CC andrew morton with it so the patch 
> > will be in the -mm tree. Thank you.
> 
> Its in the geode GIT tree
> (http://git.infradead.org/?p=users/jcrouse/geode.git;a=summary), and I
> believe that Andrew already pulls from there - so all should be 
> well.  Am I right in saying that?
> 

I was including git://git.infradead.org/users/jcrouse/geode.git but I
tossed it out a few weeks back due, I think, to unpleasant interactions
with git-cryptodev.

I'll bring git-geode back, see what happens.

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[Andrew Morton]

On Mon, 27 Nov 2006 11:54:03 -0800
Andrew Morton <akpm@osdl.org> wrote:

> I'll bring git-geode back, see what happens.

patching file arch/i386/Kconfig
Hunk #1 succeeded at 752 (offset 11 lines).
patching file arch/i386/Makefile.cpu
Hunk #1 succeeded at 39 (offset 1 line).
patching file arch/i386/boot/setup.S
Hunk #1 succeeded at 405 (offset 11 lines).
Hunk #2 succeeded at 1022 (offset 13 lines).
patching file drivers/crypto/Kconfig
Hunk #2 succeeded at 65 with fuzz 2 (offset 13 lines).
patching file drivers/crypto/Makefile
Hunk #1 succeeded at 1 with fuzz 1.
The next patch would create the file drivers/crypto/geode-aes.c,
which already exists!  Applying it anyway.
patching file drivers/crypto/geode-aes.c
Patch attempted to create file drivers/crypto/geode-aes.c, which already exists.
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file drivers/crypto/geode-aes.c.rej
The next patch would create the file drivers/crypto/geode-aes.h,
which already exists!  Applying it anyway.
patching file drivers/crypto/geode-aes.h
Patch attempted to create file drivers/crypto/geode-aes.h, which already exists.
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file drivers/crypto/geode-aes.h.rej


It seems that there's duplication between Herbert's git-cryptodev tree
and your git-geode tree.

What's the story here?

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: 2.6.19-rc5: Geode GX frame buffer takes 13 seconds to initialize

[Jordan Crouse]

On 27/11/06 12:35 -0800, Andrew Morton wrote:
 
> It seems that there's duplication between Herbert's git-cryptodev tree
> and your git-geode tree.
> 
> What's the story here?

Does - I'm an idiot count as an explanation?  I committed the crime of
a duplicate commit (well, actually several crimes).

Go ahead and pull the tree from your list.  I've decided to rebuild the
tree from scratch without the newbie behavior.  I'll let you know when
its clean again.

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV