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?
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?
Guillaume
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
Wonderful, sure I can test. Please let me know what you want me to do and when you've rebuilt.
Thanks again! ----------------------------------------
Date: Fri, 22 Nov 2013 10:13:15 +0100 From: guillaume.gardet@free.fr To: michal@hrusecky.net; opensuse-arm@opensuse.org CC: agraf@suse.de; dirk@dmllr.de; heelgeheim@hotmail.com Subject: Re: [opensuse-arm] 13.1 & neon?
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 --
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!
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.
Guillaume
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 :-/
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.
Guillaume
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
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!
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
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!
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
On 26 November 2013 09:09, Guillaume Gardet guillaume.gardet@free.fr 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.
Le 26/11/2013 12:01, Andrew Wafaa a écrit :
On 26 November 2013 09:09, Guillaume Gardet guillaume.gardet@free.fr 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
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.
Do you have any idea when it will be available?
Thanks a lot for all this work.
----------------------------------------
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?
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
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.
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....
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
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
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/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
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/
(*) 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/a... 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?
Regards, Andreas
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/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
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/a... 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
Hi Guillaume, Adrian,
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.
According to the build status on
https://build.opensuse.org/project/show/openSUSE:13.1:Update
it looks like the aarch64 repo (which is also serving armv7l binaries, don't ask..) didn't publish anymore since December 9th, 15:21. Apparently this happened shortly after publishing openSUSE:13.1:Update/patchinfo.2253 (rq 208829), which might be related.
Unfortunately I don't know why/how this happened or what the error is, there is no useful error message in the OBS publisher logfile (at least for me). Adrian, any idea?
Thanks, Dirk
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/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
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
Am 03.01.2014 02:59, schrieb Andreas Färber:
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.
On Alex' request I have tried the linux-ac100-3.10 branch (which appeared to freeze in X11 - known stability issues) and now succeeded with the for-next branch. Still the above gdm issue, so not the 3.0.x kernel's fault. :(
Unfortunately the device's touchpad and keyboard don't always work, at least not on first try, so I'm not confident enough to update the kernel-tegra-ac100 package yet.
The main difference between marvin24's for-next branch and upstream was said to be panel support for the AC100, HDMI may be working upstream. So it seems, we're finally getting closer to using a Factory kernel.
As for using U-Boot on the AC100, I've been pointed to the following: http://ac100.grandou.net/sosbootr5 (http://ac100.grandou.net/sosboot hadn't booted on Dirk's machine.)
Andreas
-
Andreas Färber -
Andrew Wafaa -
Dirk Müller -
G. Heim -
Guillaume Gardet -
Michal Hrusecky