Re: Bug#547503: git-core: "git clone" fails on armel

[Jonathan Nieder]

Hi arm porters,

Can you reproduce this problem?  If so, any ideas on how to fix it?

Gerrit Pape wrote:
> On Sun, Sep 20, 2009 at 02:08:20PM +0200, Sascha Silbe wrote:

>> git clone fails on my Debian armel system:
>>
>> sascha.silbe@flatty:~$ git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
>> Initialized empty Git repository in /home/sascha.silbe/sugar-jhbuild/.git/
>> remote: Counting objects: 4772, done.
>> remote: Compressing objects: 100% (2079/2079), done.
>> error: inflate: data stream error (invalid distance too far back)
>> fatal: pack has bad object at offset 616818: inflate returned -3
>> fatal: index-pack failed
>> sascha.silbe@flatty:~$ git clone git://git.gnome.org/jhbuild
>> Initialized empty Git repository in /home/sascha.silbe/jhbuild/.git/
>> remote: Counting objects: 19804, done.
>> remote: Compressing objects: 100% (6374/6374), done.
>> fatal: pack has bad object at offset 487227: inflate returned -5
>> fatal: index-pack failed
>> sascha.silbe@flatty:~$
>
> Hi Sascha, the bug seems to be in zlib, not git.  git uses the inflate()
> function from zlib, which, in your case, returns the errors -3
> (Z_DATA_ERROR) and -5 (Z_BUF_ERROR).  See /usr/include/zlib.h.

Thanks,
Jonathan

Please CC me on replies, as I’m not subscribed.


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Riku Voipio-2]

On Sun, Nov 08, 2009 at 07:14:25PM -0600, Jonathan Nieder wrote:
> Hi arm porters,
>
> Can you reproduce this problem?  If so, any ideas on how to fix it?

mv78x00: git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
Initialized empty Git repository in /schroot/sugar-jhbuild/.git/
remote: Counting objects: 4728, done.
remote: Compressing objects: 100% (2095/2095), done.
remote: Total 4728 (delta 2798), reused 4376 (delta 2577)
Receiving objects: 100% (4728/4728), 1.87 MiB | 206 KiB/s, done.
Resolving deltas: 100% (2798/2798), done.
mv78x00: git clone git://git.gnome.org/jhbuild
Initialized empty Git repository in /schroot/jhbuild/.git/
remote: Counting objects: 20162, done.
remote: Compressing objects: 100% (6726/6726), done.
remote: Total 20162 (delta 15845), reused 16820 (delta 13378)
Receiving objects: 100% (20162/20162), 3.52 MiB | 118 KiB/s, done.
Resolving deltas: 100% (15845/15845), done.
mv78x00:

At the original report:

Kernel: Linux 2.6.31-rc9-flatty-ocf-1-00293-g53a104c (PREEMPT)

Whats this kernel? Which CPU and machine is it on? Zlib is heavily used
throughout debian, so any breakage should have been noted before by others.

Versions of packages git-core depends on:
ii  libc6               2.9-25               GNU C Library: Shared libraries

Seems you have quite old sqeeze setup. Can you try updating?

> Gerrit Pape wrote:
> > On Sun, Sep 20, 2009 at 02:08:20PM +0200, Sascha Silbe wrote:
>
> >> git clone fails on my Debian armel system:
> >>
> >> sascha.silbe@flatty:~$ git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
> >> Initialized empty Git repository in /home/sascha.silbe/sugar-jhbuild/.git/
> >> remote: Counting objects: 4772, done.
> >> remote: Compressing objects: 100% (2079/2079), done.
> >> error: inflate: data stream error (invalid distance too far back)
> >> fatal: pack has bad object at offset 616818: inflate returned -3
> >> fatal: index-pack failed
> >> sascha.silbe@flatty:~$ git clone git://git.gnome.org/jhbuild
> >> Initialized empty Git repository in /home/sascha.silbe/jhbuild/.git/
> >> remote: Counting objects: 19804, done.
> >> remote: Compressing objects: 100% (6374/6374), done.
> >> fatal: pack has bad object at offset 487227: inflate returned -5
> >> fatal: index-pack failed
> >> sascha.silbe@flatty:~$
> >
> > Hi Sascha, the bug seems to be in zlib, not git.  git uses the inflate()
> > function from zlib, which, in your case, returns the errors -3
> > (Z_DATA_ERROR) and -5 (Z_BUF_ERROR).  See /usr/include/zlib.h.
>
> Thanks,
> Jonathan
>
> Please CC me on replies, as I’m not subscribed.
>
>
> --
> To UNSUBSCRIBE, email to debian-arm-REQUEST@...
> with a subject of "unsubscribe". Trouble? Contact listmaster@...

--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[martinwguy]

Hi folks

>  >> git clone fails on my Debian armel system:

Just to say, there's a 500MHz 512MB armel-sid box here
n2100.martinwguy.co.uk that you can use for compilation and over ssh
if that's useful - just suggest a username by private email.

Good luck!

    M


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sascha Silbe-68]

On Mon, Nov 09, 2009 at 10:29:18AM +0200, Riku Voipio wrote:

> mv78x00: git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git
> sugar-jhbuild
[...]

Works fine for me now as well:

sascha.silbe@flatty:~/y$ git clone
git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
Initialized empty Git repository in
/home/sascha.silbe/y/sugar-jhbuild/.git/
remote: Counting objects: 4728, done.
remote: Compressing objects: 100% (2095/2095), done.
remote: Total 4728 (delta 2795), reused 4376 (delta 2577)
Receiving objects: 100% (4728/4728), 1.87 MiB | 545 KiB/s, done.
Resolving deltas: 100% (2795/2795), done.
sascha.silbe@flatty:~/y$


Whatever it was, it seems fixed.

> Kernel: Linux 2.6.31-rc9-flatty-ocf-1-00293-g53a104c (PREEMPT)
>
> Whats this kernel? Which CPU and machine is it on? Zlib is heavily
> used
> throughout debian, so any breakage should have been noted before by
> others.
This is on OpenRD-Base with a custom kernel. The only two changes (vs.
the mainline kernel) that might have been relevant at all to this bug
are:

- apply cpu_idle IRQ fix from http://patchwork.kernel.org/patch/40871/
- apply OCF patch
http://downloads.sourceforge.net/project/ocf-linux/ocf-linux/20090901/ocf-linux-26-20090901.patch.gz

I doubt even that, though. If there's interest I can try again with the
old kernel, otherwise we can just close this bug.

CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

[Jonathan Nieder]

Hi again,

Sascha Silbe wrote:

> Works fine for me now as well:
>
> sascha.silbe@flatty:~/y$ git clone git://git.sugarlabs.org/sugar-jhbuild/mainline.git sugar-jhbuild
> Initialized empty Git repository in
> /home/sascha.silbe/y/sugar-jhbuild/.git/
> remote: Counting objects: 4728, done.
> remote: Compressing objects: 100% (2095/2095), done.
> remote: Total 4728 (delta 2795), reused 4376 (delta 2577)
> Receiving objects: 100% (4728/4728), 1.87 MiB | 545 KiB/s, done.
> Resolving deltas: 100% (2795/2795), done.
> sascha.silbe@flatty:~/y$
>
>
> Whatever it was, it seems fixed.

That’s too bad.

> This is on OpenRD-Base with a custom kernel. The only two changes
> (vs. the mainline kernel) that might have been relevant at all to
> this bug are:
>
> - apply cpu_idle IRQ fix from http://patchwork.kernel.org/patch/40871/
> - apply OCF patch http://downloads.sourceforge.net/project/ocf-linux/ocf-linux/20090901/ocf-linux-26-20090901.patch.gz
>
> I doubt even that, though. If there's interest I can try again with
> the old kernel, otherwise we can just close this bug.

Please do try it.  Also (I know I’m pushing my luck here) if you still
have the old libc package around, could you try with that?  It would
be nice to understand what went wrong here, so we can avoid it
breaking again.

The only possibly relevant kernel change I could find was commit
5a3a29f (ARM: 5691/1: fix cache aliasing issues between kmap() and
kmap_atomic() with highmem, commit 7929eb9 upstream) from 2.6.31.1.
So though I also have my doubts, we _could_ be lucky.

Jonathan


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Sascha Silbe-68]

On Thu, Nov 12, 2009 at 09:09:49PM -0600, Jonathan Nieder wrote:

>> I doubt even that, though. If there's interest I can try again with
>> the old kernel, otherwise we can just close this bug.
> Please do try it.
Confirmed, it still breaks with the old kernel
(2.6.31-rc9-flatty-ocf-1-00293-g53a104c), but works with the current one
(2.6.32-rc4-flatty-ocf-1-00488-g4b69b78).

> The only possibly relevant kernel change I could find was commit
> 5a3a29f (ARM: 5691/1: fix cache aliasing issues between kmap() and
> kmap_atomic() with highmem, commit 7929eb9 upstream) from 2.6.31.1.
> So though I also have my doubts, we _could_ be lucky.
I'd prefer not to track this down to a specific commit as this is a
production server now, but can try if you convince me there's some
benefit.
Can rule out my own patches, though, since they haven't changed between
the two kernels (only been rebased).

CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/

[Jonathan Nieder]

Sascha Silbe wrote:

> Confirmed, it still breaks with the old kernel
> (2.6.31-rc9-flatty-ocf-1-00293-g53a104c), but works with the current
> one (2.6.32-rc4-flatty-ocf-1-00488-g4b69b78).

Thanks!

>> The only possibly relevant kernel change I could find was commit
>> 5a3a29f (ARM: 5691/1: fix cache aliasing issues between kmap() and
>> kmap_atomic() with highmem, commit 7929eb9 upstream) from 2.6.31.1.
>> So though I also have my doubts, we _could_ be lucky.
>
> I'd prefer not to track this down to a specific commit as this is a
> production server now, but can try if you convince me there's some
> benefit.

That's okay.  I don't think you should bother.

I am satisfied, because now it's clear (1) the problem was in the
kernel, (2) the problem is actually fixed (not just a change in what
the remote repos were serving, for example), and (3) there was at least
one kernel change meant to address similar problems.  It would be
lovely to confirm on some other machine that reverting that patch
introduces the errors, but even that does not seem necessary to me.

> Can rule out my own patches, though, since they haven't changed
> between the two kernels (only been rebased).

Thanks for tracking this down.

Pleased,
Jonathan


--
To UNSUBSCRIBE, email to debian-arm-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[danny.rodriguez]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hello all -

I've seen quite a bit of activity about the SS4000-E serial console, and I was wondering if others have had difficulty?

I went out and purchased two 9pin F/F null modem cables.  I also purchased two (seemingly different anyway) IDC 10 -> DB9 serial bracket cables.

At first I tried using both of the IDC->DB9 cables as they came, connecting them into the SS4000 and rebooting.  I tried on Vista (hyperterm) and Linux (cu) and got absolutely nothing (yes using 115200, 8, n, 1) on the console.  I've read that others got at least junk on minicom/cu, but I get nothing.

I saw Tom Judge's website for the pinouts and decided to take apart one of the brackets and re-solder as seen here : http://www.tomjudge.com/index.php/SS4000-E/Serial_Cable ... the debian arm installer page says nothing about needing to re-solder [http://www.id.debian.org/releases/squeeze/armel/ch05s01.html.en] but I figured what the heck.

I tried -just- resoldering wires 3,5,9 ... that still gave nothing.   I then unsoldered off every wire from the DB9 connector and -just- resoldered wires 3,5,9 (to 2,3,5 on DB9 respectively).   Still absolutely nothing.  I even tried making sure the little grounding wire was both on and off Pin 5 (the one that solders directly onto the metal housing)

I'm at a loss here..  nothing I do seems to be working.  I've tried ssh'ing into the SS4000 and tried passing information between both serial ports (the intel box runs getty on ttyS0, figured was worth a shot)  ... nada, nothing, zilch.

I got the null modem cables from a PC Warehouse... they seem to be a cheap chinese-made version (brand is "SOHO-Family", super cheap looking) ... but could -two- of them not work?  Is there something about null modem serial cables I dont know?

Any advice would be appreciated.

-Danny