Le 22/11/2013 09:55, Guillaume Gardet a écrit :

Hi,

Le 22/11/2013 09:12, Michal Hrusecky a écrit :

...

Hi,

today I tried upgrading openSUSE on my tablet (Tegra2) from 12.3 to 13.1 and I ended up with invalid instruction errors just after update of glibc. My guess is that glibc was compiled with neon support enabled. Was there any decision to drop non-neon devices or is it simply a bug? Is it just glibc that has neon enabled or everything? I know that for 32bits we have two glibc packages, maybe something similar would be possible for armv7?

AFAIK, neon should not be enabled by default, so this is a big bug. Someone else noticed this bug few days ago, on a Mirabox (Marvel SoC).

All my ARM boards are neon capable so I cannot test. :(

Maybe Alex, or Dirk, could help here?

Apparently, glibc is now capable of multiarch for armv7. Which mean that it can auto-detect if hardware is neon capable, or not. For that, we need to build glibc with multi-arch option enabled, which is not the case right now. Without multiarch enabled, no tests are performed and assume that neon is present. I am building glibc with multi-arch enabled. Once built, could you test if it fix your problem? Guillaume

Guillaume

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Guillaume Gardet - 10:13 22.11.13 wrote:

Le 22/11/2013 09:55, Guillaume Gardet a écrit :

...

Hi,

Le 22/11/2013 09:12, Michal Hrusecky a écrit :

...

Hi,

today I tried upgrading openSUSE on my tablet (Tegra2) from 12.3 to 13.1 and I ended up with invalid instruction errors just after update of glibc. My guess is that glibc was compiled with neon support enabled. Was there any decision to drop non-neon devices or is it simply a bug? Is it just glibc that has neon enabled or everything? I know that for 32bits we have two glibc packages, maybe something similar would be possible for armv7?

AFAIK, neon should not be enabled by default, so this is a big bug. Someone else noticed this bug few days ago, on a Mirabox (Marvel SoC).

All my ARM boards are neon capable so I cannot test. :(

Maybe Alex, or Dirk, could help here?

Apparently, glibc is now capable of multiarch for armv7. Which mean that it can auto-detect if hardware is neon capable, or not. For that, we need to build glibc with multi-arch option enabled, which is not the case right now. Without multiarch enabled, no tests are performed and assume that neon is present.

I am building glibc with multi-arch enabled. Once built, could you test if it fix your problem?

Sure! -- Michal Hrusecky -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Guillaume Gardet - 11:57 22.11.13 wrote:

Le 22/11/2013 11:47, Michal Hrusecky a écrit :

...

Guillaume Gardet - 10:13 22.11.13 wrote:

...

Le 22/11/2013 09:55, Guillaume Gardet a écrit :

...

Hi,

Le 22/11/2013 09:12, Michal Hrusecky a écrit :

...

Hi,

today I tried upgrading openSUSE on my tablet (Tegra2) from 12.3 to 13.1 and I ended up with invalid instruction errors just after update of glibc. My guess is that glibc was compiled with neon support enabled. Was there any decision to drop non-neon devices or is it simply a bug? Is it just glibc that has neon enabled or everything? I know that for 32bits we have two glibc packages, maybe something similar would be possible for armv7?

AFAIK, neon should not be enabled by default, so this is a big bug. Someone else noticed this bug few days ago, on a Mirabox (Marvel SoC).

All my ARM boards are neon capable so I cannot test. :(

Maybe Alex, or Dirk, could help here? Apparently, glibc is now capable of multiarch for armv7. Which mean that it can auto-detect if hardware is neon capable, or not. For that, we need to build glibc with multi-arch option enabled, which is not the case right now. Without multiarch enabled, no tests are performed and assume that neon is present.

I am building glibc with multi-arch enabled. Once built, could you test if it fix your problem?

Sure!

Here is the glibc RPM to test: http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-4.6.1.armv7hl.rpm

Not sure it will fix the problem because build log seems to tell multiarch was auto-detected before. But let's try it.

If rpm, yast or zypper cannot install it, extract it on the SD card.

hmmm, tried it, didn't helped, tried 12.3 glibc, that one helped :-/ -- Michal Hrusecky -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 25/11/2013 11:14, Guillaume Gardet a écrit :

Le 24/11/2013 21:12, Michal Hrusecky a écrit :

...

Guillaume Gardet - 11:57 22.11.13 wrote:

...

Le 22/11/2013 11:47, Michal Hrusecky a écrit :

...

Guillaume Gardet - 10:13 22.11.13 wrote:

...

Le 22/11/2013 09:55, Guillaume Gardet a écrit :

...

Hi,

Le 22/11/2013 09:12, Michal Hrusecky a écrit : > Hi, > > today I tried upgrading openSUSE on my tablet (Tegra2) from 12.3 to 13.1 and I > ended up with invalid instruction errors just after update of glibc. My guess > is that glibc was compiled with neon support enabled. Was there any decision to > drop non-neon devices or is it simply a bug? Is it just glibc that has neon > enabled or everything? I know that for 32bits we have two glibc packages, maybe > something similar would be possible for armv7? > AFAIK, neon should not be enabled by default, so this is a big bug. Someone else noticed this bug few days ago, on a Mirabox (Marvel SoC).

All my ARM boards are neon capable so I cannot test. :(

Maybe Alex, or Dirk, could help here? Apparently, glibc is now capable of multiarch for armv7. Which mean that it can auto-detect if hardware is neon capable, or not. For that, we need to build glibc with multi-arch option enabled, which is not the case right now. Without multiarch enabled, no tests are performed and assume that neon is present.

I am building glibc with multi-arch enabled. Once built, could you test if it fix your problem?

Sure!

Here is the glibc RPM to test: http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-4.6.1.armv7hl.rpm

Not sure it will fix the problem because build log seems to tell multiarch was auto-detected before. But let's try it.

If rpm, yast or zypper cannot install it, extract it on the SD card. hmmm, tried it, didn't helped, tried 12.3 glibc, that one helped :-/

Will ask upstream.

But could you try a 13.1 JeOS rootfs, please? Just to be sure that things are not working with updated glibc and software built with this one.

Upstream seems to know this problem. See this resolved bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15905 Will try to apply this patch on a locally built glibc and I will send you so that you can test. Guillaume

Guillaume

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 25/11/2013 15:32, Michal Hrusecky a écrit :

Guillaume Gardet - 11:33 25.11.13 wrote:

...

Le 25/11/2013 11:14, Guillaume Gardet a écrit :

...

Le 24/11/2013 21:12, Michal Hrusecky a écrit :

...

Guillaume Gardet - 11:57 22.11.13 wrote:

...

Le 22/11/2013 11:47, Michal Hrusecky a écrit :

...

Guillaume Gardet - 10:13 22.11.13 wrote: > Le 22/11/2013 09:55, Guillaume Gardet a écrit : >> Hi, >> >> Le 22/11/2013 09:12, Michal Hrusecky a écrit : >>> Hi, >>> >>> today I tried upgrading openSUSE on my tablet (Tegra2) from 12.3 to 13.1 and I >>> ended up with invalid instruction errors just after update of glibc. My guess >>> is that glibc was compiled with neon support enabled. Was there any decision to >>> drop non-neon devices or is it simply a bug? Is it just glibc that has neon >>> enabled or everything? I know that for 32bits we have two glibc packages, maybe >>> something similar would be possible for armv7? >>> >> AFAIK, neon should not be enabled by default, so this is a big bug. Someone else noticed this bug few days ago, on a Mirabox (Marvel SoC). >> >> All my ARM boards are neon capable so I cannot test. :( >> >> Maybe Alex, or Dirk, could help here? > Apparently, glibc is now capable of multiarch for armv7. Which mean that it can auto-detect if hardware is neon capable, or not. For that, we need to build glibc with multi-arch option enabled, which is not the case right now. Without multiarch enabled, no tests are performed and assume that neon is present. > > I am building glibc with multi-arch enabled. > Once built, could you test if it fix your problem? > Sure!

Here is the glibc RPM to test: http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-4.6.1.armv7hl.rpm

Not sure it will fix the problem because build log seems to tell multiarch was auto-detected before. But let's try it.

If rpm, yast or zypper cannot install it, extract it on the SD card. hmmm, tried it, didn't helped, tried 12.3 glibc, that one helped :-/

Will ask upstream.

But could you try a 13.1 JeOS rootfs, please? Just to be sure that things are not working with updated glibc and software built with this one. Upstream seems to know this problem. See this resolved bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15905

Will try to apply this patch on a locally built glibc and I will send you so that you can test.

Cool, thanks!

Could you try this one, please: http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-312.1.armv7hl.rpm Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 26/11/2013 09:59, Michal Hrusecky a écrit :

Guillaume Gardet - 16:44 25.11.13 wrote:

...

Le 25/11/2013 15:32, Michal Hrusecky a écrit :

...

Guillaume Gardet - 11:33 25.11.13 wrote:

...

Le 25/11/2013 11:14, Guillaume Gardet a écrit :

...

Le 24/11/2013 21:12, Michal Hrusecky a écrit :

...

Guillaume Gardet - 11:57 22.11.13 wrote: > Le 22/11/2013 11:47, Michal Hrusecky a écrit : >> Guillaume Gardet - 10:13 22.11.13 wrote: >>> Le 22/11/2013 09:55, Guillaume Gardet a écrit : >>>> Hi, >>>> >>>> Le 22/11/2013 09:12, Michal Hrusecky a écrit : >>>>> Hi, >>>>> >>>>> today I tried upgrading openSUSE on my tablet (Tegra2) from 12.3 to 13.1 and I >>>>> ended up with invalid instruction errors just after update of glibc. My guess >>>>> is that glibc was compiled with neon support enabled. Was there any decision to >>>>> drop non-neon devices or is it simply a bug? Is it just glibc that has neon >>>>> enabled or everything? I know that for 32bits we have two glibc packages, maybe >>>>> something similar would be possible for armv7? >>>>> >>>> AFAIK, neon should not be enabled by default, so this is a big bug. Someone else noticed this bug few days ago, on a Mirabox (Marvel SoC). >>>> >>>> All my ARM boards are neon capable so I cannot test. :( >>>> >>>> Maybe Alex, or Dirk, could help here? >>> Apparently, glibc is now capable of multiarch for armv7. Which mean that it can auto-detect if hardware is neon capable, or not. For that, we need to build glibc with multi-arch option enabled, which is not the case right now. Without multiarch enabled, no tests are performed and assume that neon is present. >>> >>> I am building glibc with multi-arch enabled. >>> Once built, could you test if it fix your problem? >>> >> Sure! >> > Here is the glibc RPM to test: > http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-4.6.1.armv7hl.rpm > > Not sure it will fix the problem because build log seems to tell multiarch was auto-detected before. But let's try it. > > If rpm, yast or zypper cannot install it, extract it on the SD card. hmmm, tried it, didn't helped, tried 12.3 glibc, that one helped :-/

Will ask upstream.

But could you try a 13.1 JeOS rootfs, please? Just to be sure that things are not working with updated glibc and software built with this one. Upstream seems to know this problem. See this resolved bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15905

Will try to apply this patch on a locally built glibc and I will send you so that you can test.

Cool, thanks!

Could you try this one, please: http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-312.1.armv7hl.rpm

This one works! Great! Thanks!

Ok, perfect! I submitted my glibc patch to Base:System project, see: https://build.opensuse.org/request/show/208445 Dirk, Alex, what would be the best way to handle this update? copypac to 13.1:Ports, 13.1:Update or something else? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 26/11/2013 12:01, Andrew Wafaa a écrit :

On 26 November 2013 09:09, Guillaume Gardet wrote:

...

Le 26/11/2013 09:59, Michal Hrusecky a écrit :

...

Guillaume Gardet - 16:44 25.11.13 wrote:

...

Le 25/11/2013 15:32, Michal Hrusecky a écrit :

...

Guillaume Gardet - 11:33 25.11.13 wrote:

...

Le 25/11/2013 11:14, Guillaume Gardet a écrit : > Le 24/11/2013 21:12, Michal Hrusecky a écrit : >> Guillaume Gardet - 11:57 22.11.13 wrote: >>> Le 22/11/2013 11:47, Michal Hrusecky a écrit : >>>> Guillaume Gardet - 10:13 22.11.13 wrote: >>>>> Le 22/11/2013 09:55, Guillaume Gardet a écrit : >>>>>> Hi, >>>>>> >>>>>> Le 22/11/2013 09:12, Michal Hrusecky a écrit : >>>>>>> Hi, >>>>>>> >>>>>>> today I tried upgrading openSUSE on my tablet (Tegra2) from 12.3 to 13.1 and I >>>>>>> ended up with invalid instruction errors just after update of glibc. My guess >>>>>>> is that glibc was compiled with neon support enabled. Was there any decision to >>>>>>> drop non-neon devices or is it simply a bug? Is it just glibc that has neon >>>>>>> enabled or everything? I know that for 32bits we have two glibc packages, maybe >>>>>>> something similar would be possible for armv7? >>>>>>> >>>>>> AFAIK, neon should not be enabled by default, so this is a big bug. Someone else noticed this bug few days ago, on a Mirabox (Marvel SoC). >>>>>> >>>>>> All my ARM boards are neon capable so I cannot test. :( >>>>>> >>>>>> Maybe Alex, or Dirk, could help here? >>>>> Apparently, glibc is now capable of multiarch for armv7. Which mean that it can auto-detect if hardware is neon capable, or not. For that, we need to build glibc with multi-arch option enabled, which is not the case right now. Without multiarch enabled, no tests are performed and assume that neon is present. >>>>> >>>>> I am building glibc with multi-arch enabled. >>>>> Once built, could you test if it fix your problem? >>>>> >>>> Sure! >>>> >>> Here is the glibc RPM to test: >>> http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-4.6.1.armv7hl.rpm >>> >>> Not sure it will fix the problem because build log seems to tell multiarch was auto-detected before. But let's try it. >>> >>> If rpm, yast or zypper cannot install it, extract it on the SD card. >> hmmm, tried it, didn't helped, tried 12.3 glibc, that one helped :-/ >> > Will ask upstream. > > But could you try a 13.1 JeOS rootfs, please? Just to be sure that things are not working with updated glibc and software built with this one. Upstream seems to know this problem. See this resolved bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15905

Will try to apply this patch on a locally built glibc and I will send you so that you can test.

Cool, thanks!

Could you try this one, please: http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-312.1.armv7hl.rpm

This one works! Great! Thanks!

Ok, perfect! I submitted my glibc patch to Base:System project, see: https://build.opensuse.org/request/show/208445

Dirk, Alex, what would be the best way to handle this update? copypac to 13.1:Ports, 13.1:Update or something else?

I forget exactly how, but you should be able to submit it to 13.1:Update as an update (which this is). It then goes through review and then gets pushed out.

Yes, Andreas declined my request to Base:System because he prepares an update which will obsolete my patch. But this will be for Factory only. :( I would need to get it in 13.1:Update as you said it. Will try to submit it to 13.1:Update later today. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

G. Heim - 12:43 26.11.13 wrote:

Hi Guillaume,

You wrote:

...

I would need to get it in 13.1:Update as you said it. Will try to submit it to 13.1:Update later today.

What happens if you install from scratch with "zypper dup"? At some moment the installer downloads libc and tries to install it. Does it download from Updates first or from the base repository? If the latter, the installation will crash.

It will pick the newer version - should pick the one from updates. Once it will be there, I'll test :-)

Do you have any idea when it will be available?

Thanks a lot for all this work.

-- Michal Hrusecky -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Hi, Le 04/12/2013 17:33, G. Heim a écrit :

Hi Guillaume (and others),

Do you have any idea when your patch will be available in the official repositories? I do not see it yet on http://download.opensuse.org/ports/update/13.1/armv7hl/ nor on http://download.opensuse.org/ports/armv7hl/distribution/13.1/repo/oss/suse/a....

It is on the way: * Maintenance request accepted: https://build.opensuse.org/request/show/208720 * Request to get it in 13.1:Update repo in review state: https://build.opensuse.org/request/show/210488 Guillaume

Thanks.

----------------------------------------

...

Date: Tue, 26 Nov 2013 12:05:11 +0100 From: guillaume.gardet@free.fr To: awafaa@opensuse.org CC: michal@hrusecky.net; opensuse-arm@opensuse.org; dirk@dmllr.de; agraf@suse.de Subject: Re: [opensuse-arm] 13.1 & neon?

Le 26/11/2013 12:01, Andrew Wafaa a écrit :

...

...

...

Could you try this one, please: http://guillaume.gardet.free.fr/openSUSE/glibc-2.18-312.1.armv7hl.rpm

This one works! Great! Thanks! Yes, Andreas declined my request to Base:System because he prepares an update which will obsolete my patch. But this will be for Factory only. :(

I would need to get it in 13.1:Update as you said it. Will try to submit it to 13.1:Update later today.

Guillaume

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Le 23/12/2013 14:27, Andreas Färber a écrit :
> Hi Guillaume,
>
> Am 11.12.2013 16:11, schrieb Guillaume Gardet:
>> Le 04/12/2013 17:33, G. Heim a écrit :
>>> Hi Guillaume (and others),
>>>
>>> Do you have any idea when your patch will be available in the official repositories? 
>>> I do not see it yet on http://download.opensuse.org/ports/update/13.1/armv7hl/ nor on http://download.opensuse.org/ports/armv7hl/distribution/13.1/repo/oss/suse/armv7hl/.
>> It is on the way:
>> * Maintenance request accepted: https://build.opensuse.org/request/show/208720
>> * Request to get it in 13.1:Update repo in review state: https://build.opensuse.org/request/show/210488
> That request is marked accepted, but `zypper dup` gets stuck with
> "Illegal instruction" and not much working any more(*) and I don't spot
> a glibc RPM in: http://download.opensuse.org/ports/update/13.1/armv7hl/

You will be stuck with that unless you install the right RPM manually. Because zypper, yast or rpm will try to use the broken glibc before trying to download and install the new one.

Moreover, the new RPM is not yet out for ARM whereas it is for x86. Not sure why.


>
> (*) including zypper and rpm :/
>
> I tried copying over libc-2.17.so from 12.3 (non-update) RPM
> http://download.opensuse.org/ports/armv7hl/distribution/12.3/repo/oss/suse/armv7hl/glibc-2.17-4.4.1.armv7hl.rpm
> and changing the symlink from 2.18 to 2.17 on my SD card, but the next
> boot gets stuck with a backtrace in some unwinding function. Any hints?

We must wait for the new glibc in 13.1 ARM update. :(
I will ask some people about that.

Guillaume

>
> Regards,
> Andreas
>

-- 
To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Am 28.12.2013 14:58, schrieb Guillaume Gardet:
> Le 23/12/2013 14:27, Andreas Färber a écrit :
>> Am 11.12.2013 16:11, schrieb Guillaume Gardet:
>>> Le 04/12/2013 17:33, G. Heim a écrit :
>>>> Do you have any idea when your patch will be available in the official repositories? 
>>>> I do not see it yet on http://download.opensuse.org/ports/update/13.1/armv7hl/ nor on http://download.opensuse.org/ports/armv7hl/distribution/13.1/repo/oss/suse/armv7hl/.
>>> It is on the way:
>>> * Maintenance request accepted: https://build.opensuse.org/request/show/208720
>>> * Request to get it in 13.1:Update repo in review state: https://build.opensuse.org/request/show/210488
>> That request is marked accepted, but `zypper dup` gets stuck with
>> "Illegal instruction" and not much working any more(*) and I don't spot
>> a glibc RPM in: http://download.opensuse.org/ports/update/13.1/armv7hl/
> 
> You will be stuck with that unless you install the right RPM manually. Because zypper, yast or rpm will try to use the broken glibc before trying to download and install the new one.
> 
> Moreover, the new RPM is not yet out for ARM whereas it is for x86. Not sure why.
[...]
> We must wait for the new glibc in 13.1 ARM update. :(

With Dirk's help I have managed to rescue my AC100 system:

$ osc getbinaries openSUSE:13.1:Update patchinfo.2349 ports aarch64

downloads all ports binaries of the update that includes glibc.

Mount the SD card and copy over .armv7hl.rpm and .noarch.rpm files.
Chroot into the SD card as usual and install these RPMs:

/> rpm -Fvh /path/to/*.rpm

In my case the original update seems to have failed during PAM update,
so that booting with the fixed glibc worked but login didn't. :/

The solution was to complete the update with `zypper up` inside the
chroot. (Remember, you can't proceed with `zypper dup` as it would
revert to the broken glibc.)
After all update'able packages were installed, `zypper dup` (followed by
'n' to abort) gave me a short list of packages that needed downgrading
via `zypper in --oldpackage foo-x.y.z`. In the end, `zypper dup` should
only show glibc and nscd that you had manually installed, which - again
- you should not touch before the glibc packages are officially published.

One problem to note is that apparently there is currently an
inconsistency in the repositories with gnome-menus at 3.10.1 but
gnome-menus-branding-openSUSE at 3.10.0. Deinstalling
gnome-menus-branding-openSUSE and installing
gnome-menus-branding-upstream seemed to work as conflict resolution.

So far so good, system is usable again. Yay!


My AC100 was configured to run XFCE via DISPLAYMANAGER="gdm".
Unfortunately the screen stayed black and after a while a white screen

  Oh no! Something has gone wrong.
  A problem has occurred and the system can't recover. Please contact a
system administrator

appeared.

/var/log/gdm/:0.log had some warning about gpio-keys and duplicate
.../event0, so that I dropped my xorg.conf in favor of a 20-fbdev.conf
snippet from the JeOS package's config.sh. That resolved the log entry,
but that screen is still with me.

I have worked through `zypper se -i -s | grep '(System'`, `zypper rm`ing
any leftover or non-updatable packages except for glibc*, nscd,
kernel-tegra-ac100 and Mozilla{Firefox,Thunderbird}.
`zypper ve` shows nothing.
I've disabled the newly installed AppArmor just to be sure.

Any ideas what else to check?

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
-- 
To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse-arm+owner@opensuse.org