Re: Enabling PIE by default for Stretch

[Niels Thykier]

Niels Thykier:
> Hi,
> 
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
>  * It is a substantial hardening feature
>  * Upstream has vastly reduced the performance penalty for x86
>  * The majority of all porters believe their release architecture is
>ready for it.
>  * We have sufficient time to solve any issues or revert if it turns out
>to be too problematic.
> 
> [...]
> 
>  * Deadline for major concerns:  Fri, 7th of October 2016.
> 
> [...]
> 
> Thanks,
> ~Niels
> 
> [...]

It appears that there were no major concerns.  I will follow up #835148
and request PIE by default for the following architectures.

 * amd64
 * arm64
 * armel
 * armhf
 * i386
 * mips
 * mips64el
 * mipsel
 * ppc64el
 * s390x

Should you be a porter for an architecture not listed above and want PIE
by default on your architecture, please follow up on #835148 as well (or
a file a new wishlist bug if #835148 is closed when you do it)

NB: The omission of powerpc was intentional as there were no porters
supporting it during the roll-call.

Thanks,
~Niels

Re: Porter roll call for Debian Stretch

[Adam D. Barratt]

On Sun, 2016-10-09 at 21:12 +0300, Adrian Bunk wrote:
> [ adding debian-powerpc ]
> 
> On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> > Niels Thykier  schrieb:
> > > If I am to support powerpc as a realease architecture for Stretch, I
> > > need to know that there are *active* porters behind it committed to
> > > keeping it in the working.  People who would definitely catch such
> > > issues long before the release.  People who file bugs / submit patches 
> > > etc.
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
> > a powerpc-specific build failure of mariadb in stable. The maintainer
> > said he can't work on it, so if anyone considers himself/herself a
> > powerpc porter, this is something to look it.
> 
> Can you give a hint what exactly should be looked at?

https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.0=powerpc=10.0.27-0%2Bdeb8u1=1473621159

> The bug did not make it clear that there is any problem left at all when 
> I looked at it recently.
> 
> The last message was closing the bug.
> 
> There was a control command reopening the bug without giving any 
> rationale, but the last control command was
>   fixed 832931 10.0.27-1

For unstable, yes. The stable package is still broken.

> buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1]

That's an artefact of how builds for suites with "overlays" (i.e. pu /
tpu) are displayed. If one actually looks at the archive:

mariadb-client-10.0 | 10.0.25-0+deb8u1 | stable | powerpc
mariadb-client-10.0 | 10.0.27-0+deb8u1 | stable | amd64, arm64, armel, 
armhf, i386, mips, mipsel, ppc64el, s390x

Regards,

Adam

Re: CPU requirements for powerpc

[Rick Thomas]

Your evidence is compelling.  Even if it doesn’t present a smoking gun.
It definitely looks like you’ve got enough material for a bug report against 
syslog-ng.
You can always add to the bug report later when you have a suggested patch.

Rick

On Oct 9, 2016, at 1:58 AM, Christoph Biedl  
wrote:

> Rick Thomas wrote...
> 
>> Can you give us some more details?
> 
> In general I'm somewhat reluctant since first conclusions are usually
> wrong and I certainly don't want to create noise at the wrong place.
> So I'd rather debug a little longer until I can identify the real
> cause, and create a patch to prove I was right. So yesterday I would
> wrongly have blamed openssl, now it rather looks like pcre3. Which
> still might not be true.
> 
> But since I'm rather busy today doing other things, here are the bits
> if you want to take over:
> 
>> 1) Which debian (stable/testing/sid)?
>> 2) Which packages?
>> 3) Which G4 boxes?
> 
> This is Debian stretch, package is syslog-ng 3.7.3-3, box is a
> PowerMac G4 running a "7410, altivec supported" CPU.
> 
> Rebuild syslog-ng, you should see four errors in the test suite, the
> first being
> 
> | PASS: lib/transport/tests/test_aux_data
> | ../../test-driver: line 107: 77989 Illegal instruction "$@" > $log_file 
> 2>&1
> 
> This is triggered by ./lib/logproto/tests/test_logproto, started
> without any parameters.
> 
> Using gdb you will encounter SIGILL in the libcrypt initialization,
> that's ok, openssl probes the CPU capabilities (see above). Second
> time it's something like
> 
> | #0  0xb7faf008 in ?? ()
> | #1  0x0fc42a38 in ?? () from /lib/powerpc-linux-gnu/libpcre.so.3
> | #2  0x0fc67c20 in ?? () from /lib/powerpc-linux-gnu/libpcre.so.3
> 
> where disassemble shows different instructions when tried again, it's
> either "mflr" or "mr". Next step would be to identify where the actual
> instruction comes from and how the code path is triggered. Also big
> question why this doesn't happen more often.
> 
> The package used to build with 3.7.3-1 back in July, the changes in
> syslog-ng are minimal, and nothing obvious in pcre3 (was 2:8.38-3.1,
> now it's 2:8.39-2).
> 
> Godspeed, and please share any findings so I can focus on other
> issues.
> 
>Christoph

Re: Porter roll call for Debian Stretch

[Adrian Bunk]

[ adding debian-powerpc ]

On Sun, Oct 09, 2016 at 06:54:44PM +0200, Moritz Mühlenhoff wrote:
> Niels Thykier  schrieb:
> > If I am to support powerpc as a realease architecture for Stretch, I
> > need to know that there are *active* porters behind it committed to
> > keeping it in the working.  People who would definitely catch such
> > issues long before the release.  People who file bugs / submit patches etc.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832931 is about
> a powerpc-specific build failure of mariadb in stable. The maintainer
> said he can't work on it, so if anyone considers himself/herself a
> powerpc porter, this is something to look it.

Can you give a hint what exactly should be looked at?

The bug did not make it clear that there is any problem left at all when 
I looked at it recently.

The last message was closing the bug.

There was a control command reopening the bug without giving any 
rationale, but the last control command was
  fixed 832931 10.0.27-1

buildd.debian.org says that 10.0.27-0+deb8u1 was installed on jessie.[1]

If there is a problem left somewhere it is well-hidden, and not visible 
immediately when looking at the bug - I thought this was already resolved.

> Cheers,
> Moritz

cu
Adrian

[1] https://buildd.debian.org/status/package.php?p=mariadb-10.0=jessie

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: CPU requirements for powerpc

[Christoph Biedl]

Rick Thomas wrote...

> Can you give us some more details?

In general I'm somewhat reluctant since first conclusions are usually
wrong and I certainly don't want to create noise at the wrong place.
So I'd rather debug a little longer until I can identify the real
cause, and create a patch to prove I was right. So yesterday I would
wrongly have blamed openssl, now it rather looks like pcre3. Which
still might not be true.

But since I'm rather busy today doing other things, here are the bits
if you want to take over:

> 1) Which debian (stable/testing/sid)?
> 2) Which packages?
> 3) Which G4 boxes?

This is Debian stretch, package is syslog-ng 3.7.3-3, box is a
PowerMac G4 running a "7410, altivec supported" CPU.

Rebuild syslog-ng, you should see four errors in the test suite, the
first being

| PASS: lib/transport/tests/test_aux_data
| ../../test-driver: line 107: 77989 Illegal instruction "$@" > $log_file 
2>&1

This is triggered by ./lib/logproto/tests/test_logproto, started
without any parameters.

Using gdb you will encounter SIGILL in the libcrypt initialization,
that's ok, openssl probes the CPU capabilities (see above). Second
time it's something like

| #0  0xb7faf008 in ?? ()
| #1  0x0fc42a38 in ?? () from /lib/powerpc-linux-gnu/libpcre.so.3
| #2  0x0fc67c20 in ?? () from /lib/powerpc-linux-gnu/libpcre.so.3

where disassemble shows different instructions when tried again, it's
either "mflr" or "mr". Next step would be to identify where the actual
instruction comes from and how the code path is triggered. Also big
question why this doesn't happen more often.

The package used to build with 3.7.3-1 back in July, the changes in
syslog-ng are minimal, and nothing obvious in pcre3 (was 2:8.38-3.1,
now it's 2:8.39-2).

Godspeed, and please share any findings so I can focus on other
issues.

Christoph


signature.asc
Description: Digital signature

Re: PowerPC agpmode issues

[Benjamin Herrenschmidt]

On Sat, 2016-10-08 at 12:05 -0700, Herminio Hernandez, Jr. wrote:
> Performed an apt dist-upgrade and rebooted with agpmode=4 and still
> the GPU is failing with errors. Should I proceed to place a bug
> report on this?

I wouldn't even try to be honest. The HW issues in Apple AGP
implementation pretty much guarantee that things will crash
with the recent DRIs. Back when AGP memory was just a single
chunk of memory we got it to limp along but since DRI2 it's
pretty much hopeless.

I would stick to PCI GART even if it sucks for performances.

Cheers,
Ben.

> Herminio
> 
> On Tue, Sep 20, 2016 at 11:20 PM, Herminio Hernandez, Jr.  ernande...@gmail.com> wrote:
> > I am still getting errors even with radeon.agpmode=4 is set
> > 
> > rican-linux@Debian-G5:~$ dmesg |grep -e radeom -e drm -e
> > radeon.agpmode
> > [    0.00] Kernel command line: root=UUID=aeca9a67-31d7-4c4b-
> > a0f8-4db328b33305  radeon.agpmode=4
> > [    9.734366] [drm] Initialized drm 1.1.0 20060810
> > [   10.934519] [drm] radeon kernel modesetting enabled.
> > [   10.943743] fb: switching to radeondrmfb from OFfb ATY,Simone
> > [   10.954622] fb: switching to radeondrmfb from OFfb ATY,Simone
> > [   10.956515] [drm] initializing kernel modesetting (RV350
> > 0x1002:0x4150 0x1002:0x4150 0x00).
> > [   10.956552] [drm] register mmio base: 0xA000
> > [   10.956558] [drm] register mmio size: 65536
> > [   11.046327] [drm] Not an x86 BIOS ROM, not using.
> > [   11.046358] [drm] Using device-tree clock info
> > [   11.046369] [drm] AGP mode requested: 4
> > [   11.046528] [drm] Generation 2 PCI interface, using max
> > accessible memory
> > [   11.046582] [drm] Detected VRAM RAM=256M, BAR=256M
> > [   11.046587] [drm] RAM width 128bits DDR
> > [   11.046858] [drm] radeon: 64M of VRAM memory ready
> > [   11.046866] [drm] radeon: 256M of GTT memory ready.
> > [   11.046935] [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
> > [   11.061306] [drm] Supports vblank timestamp caching Rev 2
> > (21.10.2013).
> > [   11.061312] [drm] Driver supports precise vblank timestamp
> > query.
> > [   11.061363] [drm] radeon: irq initialized.
> > [   11.061405] [drm] Loading R300 Microcode
> > [   11.110467] [drm] radeon: ring at 0x0001
> > [   11.257952] [drm:.r100_ring_test [radeon]] *ERROR* radeon: ring
> > test failed (scratch(0x15E4)=0xCAFEDEAD)
> > [   11.258060] [drm:.r100_cp_init [radeon]] *ERROR* radeon: cp
> > isn't working (-22).
> > [   11.404548] [drm:.r100_cp_fini [radeon]] *ERROR* Wait for CP
> > idle timeout, shutting down CP.
> > [   11.551199] [drm] radeon: cp finalized
> > [   12.547388] [drm] radeon: cp finalized
> > [   12.553854] [drm] radeon: ttm finalized
> > [   12.553861] [drm] Forcing AGP to PCI mode
> > [   12.643384] [drm] Not an x86 BIOS ROM, not using.
> > [   12.643406] [drm] Using device-tree clock info
> > [   12.643414] [drm] Generation 2 PCI interface, using max
> > accessible memory
> > [   12.643446] [drm] Detected VRAM RAM=256M, BAR=256M
> > [   12.643452] [drm] RAM width 128bits DDR
> > [   12.643712] [drm] radeon: 64M of VRAM memory ready
> > [   12.643719] [drm] radeon: 512M of GTT memory ready.
> > [   12.643761] [drm] GART: num cpu pages 8192, num gpu pages 131072
> > [   12.645324] [drm] radeon: 1 quad pipes, 1 Z pipes initialized.
> > [   12.645343] [drm] PCI GART of 512M enabled (table at
> > 0x62F8).
> > [   12.645462] [drm] Supports vblank timestamp caching Rev 2
> > (21.10.2013).
> > [   12.645468] [drm] Driver supports precise vblank timestamp
> > query.
> > [   12.645512] [drm] radeon: irq initialized.
> > [   12.645689] [drm] radeon: ring at 0x9001
> > [   12.793131] [drm:.r100_ring_test [radeon]] *ERROR* radeon: ring
> > test failed (scratch(0x15E4)=0xCAFEDEAD)
> > [   12.793235] [drm:.r100_cp_init [radeon]] *ERROR* radeon: cp
> > isn't working (-22).
> > [   12.939961] [drm:.r100_cp_fini [radeon]] *ERROR* Wait for CP
> > idle timeout, shutting down CP.
> > [   12.940193] [drm] radeon: cp finalized
> > [   12.944581] [drm] Connector Table: 12 (mac g5 9600)
> > [   12.944609] [drm] No valid Ext TMDS info found in BIOS
> > [   12.944621] [drm] No TV DAC info found in BIOS
> > [   12.944798] [drm] No TMDS info found in BIOS
> > [   12.944974] [drm] Radeon Display Connectors
> > [   12.944981] [drm] Connector 0:
> > [   12.944985] [drm]   DVI-I-1
> > [   12.944990] [drm]   HPD1
> > [   12.944995] [drm]   DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64
> > [   12.945000] [drm]   Encoders:
> > [   12.945005] [drm] DFP2: INTERNAL_DVO1
> > [   12.945010] [drm] CRT2: INTERNAL_DAC2
> > [   12.945015] [drm] Connector 1:
> > [   12.945019] [drm]   DVI-I-2
> > [   12.945023] [drm]   HPD2
> > [   12.945028] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
> > [   12.945033] [drm]   Encoders:
> > [   12.945037] [drm] DFP1: INTERNAL_TMDS1
> > [   12.945042] [drm] CRT1: INTERNAL_DAC1
> > [   12.945046] [drm] Connector 2:
> > [   12.945051] [drm]   SVIDEO-1
> > [  

Re: CPU requirements for powerpc

[Rick Thomas]

On Oct 8, 2016, at 11:02 AM, Christoph Biedl  
wrote:

> Hello,
> 
> just to make sure I got things right: The 74xx/G4 processors are
> to be supported by Debian's powerpc architecture?
> 
> Background: On my G4 boxes I encounter SIGILL from several packages,
> turns out they were built with compiler options for more recent CPUs,
> hence the program abort. The buildds don't notice that as they are
> already G5 or whatever.
> 
> So before filing grim bug reports for nothing, would they be
> justified?
> 
>Christoph

Hi Christoph,

Can you give us some more details?

1) Which debian (stable/testing/sid)?
2) Which packages?
3) Which G4 boxes?

Thanks!
Rick  — who is also interested in keeping his G4 boxes running Debian!

Re: CPU requirements for powerpc

[Riccardo Mottola]

Hi,


On 08/10/2016 20:51, Mathieu Malaterre wrote:

I use a PowerMac (Mac Mini) with a G4 and everything is fine.
Technically even Altivec is not required:


and I hope it remains so or G3 users will loose their iMacs or iBooks 
(like i mine!)


Riccardo