Bug#1061652: bookworm-pu: package rss-glx/0.9.1-6.4+deb12u1
- Original Message -
> From: "Adam D. Barratt"
> To: "Timothy Pearson" , "1061652"
> <1061...@bugs.debian.org>
> Sent: Monday, January 29, 2024 11:21:44 AM
> Subject: Re: Bug#1061652: bookworm-pu: package rss-glx/0.9.1-6.4+deb12u1
> On Sun, 2024-01-28 at 16:38 -0600, Timothy Pearson wrote:
>>
>> > The version in the topic also implies a higher version than the
>> > unstable upload, whereas the stable upload needs a lower version -
>> > either -6.3+deb12u1 or -6.4~deb12u1 depending on whether you take
>> > the
>> > approach of adding the new patches on top of the existing stable
>> > version, or backporting the unstable upload as a whole. It looks
>> > like
>> > the effect would be identical in this case afaict, so it's purely a
>> > matter of preference.
>>
>> I will useg -6.4~deb12u1 for simplicity, since we are tracking the
>> unstable version in this update. I inadvertently made an error in
>> the bug report subject line.
>
> Sorry for missing a detail here, but if you're going for that approach
> then the changelog should follow the style it would for an upload to
> backports - i.e. taking the unstable upload, including the changelog
> entry for -6.4, and prepending a new stanza for -6.4~deb12u1 with an
> entry similar to "Rebuild for bookworm". Does that make sense?
>
> Regards,
>
> Adam
Yes, that makes sense to me. First time I'm proposing a new stable update
package that isn't a security update, so appreciate the patience and
assistance!diff -Nru rss-glx-0.9.1/debian/changelog rss-glx-0.9.1/debian/changelog
--- rss-glx-0.9.1/debian/changelog 2021-10-16 08:11:19.00000 -0500
+++ rss-glx-0.9.1/debian/changelog 2024-01-29 11:26:00.0 -0600
@@ -1,3 +1,18 @@
+rss-glx (0.9.1-6.4~deb12u1) bookworm; urgency=medium
+
+ * Rebuild for Bookworm (Closes: #1061652)
+
+ -- Timothy Pearson Mon, 29 Jan 2024 11:26:00 -0600
+
+rss-glx (0.9.1-6.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/glfinish.patch: Call GLFinish() prior to glXSwapBuffers()
+(Closes: #1061507)
+ * Install screensavers into /usr/libexec/xscreensaver (Closes: #979490)
+
+ -- Timothy Pearson Sat, 27 Jan 2024 08:41:00 -0600
+
rss-glx (0.9.1-6.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru rss-glx-0.9.1/debian/patches/glfinish.patch rss-glx-0.9.1/debian/patches/glfinish.patch
--- rss-glx-0.9.1/debian/patches/glfinish.patch 1969-12-31 18:00:00.0 -0600
+++ rss-glx-0.9.1/debian/patches/glfinish.patch 2024-01-25 10:43:27.0 -0600
@@ -0,0 +1,12 @@
+Index: rss-glx-0.9.1/src/driver.c
+===
+--- rss-glx-0.9.1.orig/src/driver.c
rss-glx-0.9.1/src/driver.c
+@@ -238,6 +238,7 @@
+
+ if (drawEnabled) {
+ hack_draw (XStuff, (double)now.tv_sec + now.tv_usec / 100.0f, frameTimeSoFar / 100.0f);
++ glFinish();
+
+ glXSwapBuffers (XStuff->display, XStuff->window);
+ }
diff -Nru rss-glx-0.9.1/debian/patches/series rss-glx-0.9.1/debian/patches/series
--- rss-glx-0.9.1/debian/patches/series 2021-10-16 08:05:56.0 -0500
+++ rss-glx-0.9.1/debian/patches/series 2024-01-27 08:46:13.0 -0600
@@ -2,3 +2,4 @@
pixelcity-cpp.patch
readme.patch
include-cstddef.patch
+glfinish.patch
diff -Nru rss-glx-0.9.1/debian/rules rss-glx-0.9.1/debian/rules
--- rss-glx-0.9.1/debian/rules 2011-05-27 10:01:25.0 -0500
+++ rss-glx-0.9.1/debian/rules 2024-01-27 08:45:36.0 -0600
@@ -15,12 +15,12 @@
override_dh_auto_configure:
dh_auto_configure -- --with-configdir=/usr/share/xscreensaver/config \
--with-kdessconfigdir=/usr/share/kde4/services/ScreenSavers \
- --bindir=/usr/lib/xscreensaver --enable-static=no \
+ --bindir=/usr/libexec/xscreensaver --enable-static=no \
LDFLAGS=-Wl,--as-needed
override_dh_auto_install:
dh_auto_install
- mv $(CURDIR)/debian/rss-glx/usr/lib/xscreensaver/rss-glx_install.pl \
+ mv $(CURDIR)/debian/rss-glx/usr/libexec/xscreensaver/rss-glx_install.pl \
$(CURDIR)/debian/rss-glx/usr/bin/rss-glx_install
cp $(CURDIR)/debian/desktop_files/*.desktop \
$(CURDIR)/debian/rss-glx/usr/share/applications/screensavers
Bug#1061652: bookworm-pu: package rss-glx/0.9.1-6.4+deb12u1
Control: tags - moreinfo
> You appear to have attached a debdiff between your upload to unstable
> and the package in stable. The request is for a debdiff between the
> package in stable and the package you intend to upload _to stable_.
> Please provide that, and remove the "moreinfo" tag once done.
Understood. Corrected patch attached.
> The version in the topic also implies a higher version than the
> unstable upload, whereas the stable upload needs a lower version -
> either -6.3+deb12u1 or -6.4~deb12u1 depending on whether you take the
> approach of adding the new patches on top of the existing stable
> version, or backporting the unstable upload as a whole. It looks like
> the effect would be identical in this case afaict, so it's purely a
> matter of preference.
I will useg -6.4~deb12u1 for simplicity, since we are tracking the
unstable version in this update. I inadvertently made an error in
the bug report subject line.
Thank you!diff -Nru rss-glx-0.9.1/debian/changelog rss-glx-0.9.1/debian/changelog
--- rss-glx-0.9.1/debian/changelog 2021-10-16 08:11:19.0 -0500
+++ rss-glx-0.9.1/debian/changelog 2024-01-27 08:41:00.0 -0600
@@ -1,3 +1,12 @@
+rss-glx (0.9.1-6.4~deb12u1) bookworm; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/glfinish.patch: Call GLFinish() prior to glXSwapBuffers()
+(Closes: #1061507)
+ * Install screensavers into /usr/libexec/xscreensaver (Closes: #979490)
+
+ -- Timothy Pearson Sat, 27 Jan 2024 08:41:00 -0600
+
rss-glx (0.9.1-6.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru rss-glx-0.9.1/debian/patches/glfinish.patch rss-glx-0.9.1/debian/patches/glfinish.patch
--- rss-glx-0.9.1/debian/patches/glfinish.patch 1969-12-31 18:00:00.0 -0600
+++ rss-glx-0.9.1/debian/patches/glfinish.patch 2024-01-25 10:43:27.0 -0600
@@ -0,0 +1,12 @@
+Index: rss-glx-0.9.1/src/driver.c
+===
+--- rss-glx-0.9.1.orig/src/driver.c
rss-glx-0.9.1/src/driver.c
+@@ -238,6 +238,7 @@
+
+ if (drawEnabled) {
+ hack_draw (XStuff, (double)now.tv_sec + now.tv_usec / 100.0f, frameTimeSoFar / 100.0f);
++ glFinish();
+
+ glXSwapBuffers (XStuff->display, XStuff->window);
+ }
diff -Nru rss-glx-0.9.1/debian/patches/series rss-glx-0.9.1/debian/patches/series
--- rss-glx-0.9.1/debian/patches/series 2021-10-16 08:05:56.0 -0500
+++ rss-glx-0.9.1/debian/patches/series 2024-01-27 08:41:00.0 -0600
@@ -2,3 +2,4 @@
pixelcity-cpp.patch
readme.patch
include-cstddef.patch
+glfinish.patch
diff -Nru rss-glx-0.9.1/debian/rules rss-glx-0.9.1/debian/rules
--- rss-glx-0.9.1/debian/rules 2011-05-27 10:01:25.0 -0500
+++ rss-glx-0.9.1/debian/rules 2024-01-27 08:41:00.0 -0600
@@ -15,12 +15,12 @@
override_dh_auto_configure:
dh_auto_configure -- --with-configdir=/usr/share/xscreensaver/config \
--with-kdessconfigdir=/usr/share/kde4/services/ScreenSavers \
- --bindir=/usr/lib/xscreensaver --enable-static=no \
+ --bindir=/usr/libexec/xscreensaver --enable-static=no \
LDFLAGS=-Wl,--as-needed
override_dh_auto_install:
dh_auto_install
- mv $(CURDIR)/debian/rss-glx/usr/lib/xscreensaver/rss-glx_install.pl \
+ mv $(CURDIR)/debian/rss-glx/usr/libexec/xscreensaver/rss-glx_install.pl \
$(CURDIR)/debian/rss-glx/usr/bin/rss-glx_install
cp $(CURDIR)/debian/desktop_files/*.desktop \
$(CURDIR)/debian/rss-glx/usr/share/applications/screensavers
Bug#550255:
Is this still a problem? If so, the package to install will be rss-glx-dbgsym, and a "thread apply all bt" in GDB would give the needed debug information once the flux process hangs.
Bug#1061652: bookworm-pu: package rss-glx/0.9.1-6.4+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: rss-...@packages.debian.org
Control: affects -1 + src:rss-glx
[ Reason ]
The current rss-glx package in Bookworm contains two bugs that
render it unusable for a large percentage of its target audience
without direct intervention (to move files to the correct location)
or recompilation (if the user's GPU doesn't automatically flush
before buffer swap).
[ Impact ]
rss-glx continues to silently fail for a significant proportion
of its target user base.
[ Tests ]
Tested in several modes on a POWER host with an AMD GPU, using
the open source GPU drivers.
[ Risks ]
The only risk would be potentially triggering a latent GPU driver
bug that I am unaware of on non-AMD hardware. Such a bug would
need to be fixed in the relevant driver, as the operation order
now used in the updated rss-glx source is correct per standards.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
* debian/patches/glfinish.patch: Call GLFinish() prior to glXSwapBuffers()
(Closes: #1061507)
* Install screensavers into /usr/libexec/xscreensaver (Closes: #979490)dpkg-source: warning: extracting unsigned source package (/disk2/SCREENSAVERS/NEW.FOR_UPLOAD/rss-glx_0.9.1-6.4.dsc)
diff -Nru rss-glx-0.9.1/debian/changelog rss-glx-0.9.1/debian/changelog
--- rss-glx-0.9.1/debian/changelog 2021-10-16 08:11:19.0 -0500
+++ rss-glx-0.9.1/debian/changelog 2024-01-27 08:41:00.0 -0600
@@ -1,3 +1,12 @@
+rss-glx (0.9.1-6.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/patches/glfinish.patch: Call GLFinish() prior to glXSwapBuffers()
+(Closes: #1061507)
+ * Install screensavers into /usr/libexec/xscreensaver (Closes: #979490)
+
+ -- Timothy Pearson Sat, 27 Jan 2024 08:41:00 -0600
+
rss-glx (0.9.1-6.3) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru rss-glx-0.9.1/debian/patches/glfinish.patch rss-glx-0.9.1/debian/patches/glfinish.patch
--- rss-glx-0.9.1/debian/patches/glfinish.patch 1969-12-31 18:00:00.0 -0600
+++ rss-glx-0.9.1/debian/patches/glfinish.patch 2024-01-25 10:43:27.0 -0600
@@ -0,0 +1,12 @@
+Index: rss-glx-0.9.1/src/driver.c
+===
+--- rss-glx-0.9.1.orig/src/driver.c
rss-glx-0.9.1/src/driver.c
+@@ -238,6 +238,7 @@
+
+ if (drawEnabled) {
+ hack_draw (XStuff, (double)now.tv_sec + now.tv_usec / 100.0f, frameTimeSoFar / 100.0f);
++ glFinish();
+
+ glXSwapBuffers (XStuff->display, XStuff->window);
+ }
diff -Nru rss-glx-0.9.1/debian/patches/series rss-glx-0.9.1/debian/patches/series
--- rss-glx-0.9.1/debian/patches/series 2021-10-16 08:05:56.0 -0500
+++ rss-glx-0.9.1/debian/patches/series 2024-01-27 08:41:00.0 -0600
@@ -2,3 +2,4 @@
pixelcity-cpp.patch
readme.patch
include-cstddef.patch
+glfinish.patch
diff -Nru rss-glx-0.9.1/debian/rules rss-glx-0.9.1/debian/rules
--- rss-glx-0.9.1/debian/rules 2011-05-27 10:01:25.0 -0500
+++ rss-glx-0.9.1/debian/rules 2024-01-27 08:41:00.0 -0600
@@ -15,12 +15,12 @@
override_dh_auto_configure:
dh_auto_configure -- --with-configdir=/usr/share/xscreensaver/config \
--with-kdessconfigdir=/usr/share/kde4/services/ScreenSavers \
- --bindir=/usr/lib/xscreensaver --enable-static=no \
+ --bindir=/usr/libexec/xscreensaver --enable-static=no \
LDFLAGS=-Wl,--as-needed
override_dh_auto_install:
dh_auto_install
- mv $(CURDIR)/debian/rss-glx/usr/lib/xscreensaver/rss-glx_install.pl \
+ mv $(CURDIR)/debian/rss-glx/usr/libexec/xscreensaver/rss-glx_install.pl \
$(CURDIR)/debian/rss-glx/usr/bin/rss-glx_install
cp $(CURDIR)/debian/desktop_files/*.desktop \
$(CURDIR)/debian/rss-glx/usr/share/applications/screensavers
Bug#672250:
Would it be possible for someone that can reproduce this bug to do the following: * Install the rss-glx-dbgsym package * Provoke the bug * Attach gdb to the running process with 'gdb --pid ' * Grab a backtrace and upload here? If I can see where the process is stuck I'm willing to take a quick look to see if it can be easily fixed. Thanks!
Bug#1061507: [regression] rss-glx screensavers will not display on certain X11 windows
Package: rss-glx
Version: 0.9.1-6.3+b1
Tags: patch
On certain hardware and with specific X11 windows (such as the TDE lock
screen), the RSS-GLX hacks no longer display after upgrading to Bookworm from
Bullseye. This was traced to a missing glFinish() call prior to
glXSwapBuffers(); likely the AMD GPU driver has not completed rendering prior
to the Swap call, leading to the hack output not showing up on the target
window.
I have attached a patch that is confirmed to fix the issue. If desired, I can
do an NMU to include this simple fix. Ideally, this would also be backported
to Bookworm, and I can handle the backport for that as well if desired.Index: rss-glx-0.9.1/src/driver.c
===
--- rss-glx-0.9.1.orig/src/driver.c
+++ rss-glx-0.9.1/src/driver.c
@@ -238,6 +238,7 @@
if (drawEnabled) {
hack_draw (XStuff, (double)now.tv_sec + now.tv_usec / 100.0f, frameTimeSoFar / 100.0f);
+ glFinish();
glXSwapBuffers (XStuff->display, XStuff->window);
}
Bug#1032104:
Root cause found, merge request here: https://salsa.debian.org/kernel-team/linux/-/merge_requests/917
Bug#1032104: Status update
I have traced this bug to a missing memory barrier in the powerpc IPI handling code. io_uring uses task_work_add() to schedule I/O worker creation, which in turn issues an IPI, and when precise timing conditions are met the inconsistent state between the two CPU cores can lead to corruption of userspace data in RAM. I have sent a patch upstream, and created a merge request for Debian here: https://salsa.debian.org/kernel-team/linux/-/merge_requests/907
Bug#1032104: Status update
I have traced this to a regression in the Linux kernel. The issue appears to be a type of data race that is more likely to occur on ppc64el than on other architectures, but is also likely to affect other architectures. The issue remains in the latest GIT version of the Linux kernel, and I am working with both upstream and our internal resources to try to isolate the root cause and generate a fix. In the interim, disabling the io_uring subsystem will allow mariadb to function normally. Given the nature of the kernel bug, I would recommend disabling io_uring entirely in the kernel configuration for affected systems, as other applications may also be impacted by the data corruption.
Bug#1051355: Processed: your mail
For 16 to work we'll need the Debian clang team to include this patchset: https://reviews.llvm.org/D158066 Any chance of that happening? - Original Message - > From: "Andres Salomon" > To: "Leandro Cunha" , 1051...@bugs.debian.org > Cc: "Timothy Pearson" > Sent: Sunday, September 10, 2023 11:43:18 PM > Subject: Re: Bug#1051355: Processed: your mail > Alright, I built 117 w/ clang-16 on sid and it doesn't segfault. Same > exact build but with clang-14 segfaults. > > Timothy, did you ever get the ppc64 issues with clang >= 15 squared > away? It's looking like I'm going to need to upload a build with > clang-16. > > On Sun, Sep 10 2023 at 03:07:29 PM -03:00:00, Leandro Cunha > wrote: >> Hi, >> >> Em dom., 10 de set. de 2023 15:01, Andres Salomon >> mailto:dilin...@queued.net>> escreveu: >>> Unfortunately 117 *also* segfaults on sid. >>> >>> I'm tempted to try a newer clang, but probably not 15 since debian's >>> planning to remove it. 16, I guess? >> >> Arch is already with Clang 16 and I tested Chromium 117 in a vm that >> I installed here and it was working normally.
Bug#1032104: Still present in Bookworm
We've started hitting this on a busy server after upgrading to Bookworm: 2023-09-07 17:00:31 0 [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work. 2023-09-07 17:00:31 0 [Note] Server socket created on IP: '127.0.0.1'. 2023-09-07 17:00:31 0 [Note] /usr/sbin/mariadbd: ready for connections. Version: '10.11.3-MariaDB-1' socket: '/run/mysqld/mysqld.sock' port: 3306 Debian 12 2023-09-07 17:00:31 0 [Note] InnoDB: Buffer pool(s) load completed at 230907 17:00:31 2023-09-07 20:35:06 8630 [ERROR] InnoDB: Database page corruption on disk or a failed read of file './database/data_table.ibd' page [page id: space=393, page number=1534]. You may have to recover from a backup. 2023-09-07 20:35:06 8630 [Note] InnoDB: Page dump (8192 bytes): 2023-09-07 20:35:06 8630 [Note] InnoDB: 86c518ee05fe05fd05ff00067ee5a53145bf 2023-09-07 20:35:06 8630 [Note] InnoDB: 0189000f3eff803d3e030002003a003b 2023-09-07 20:35:06 8630 [Note] InnoDB: 045a6881 2023-09-07 20:35:06 8630 [Note] InnoDB: 12d4ae6314accb64e0a8630400b55a4b8f6557796d5eb10dee577503 2023-09-07 20:35:06 8630 [Note] InnoDB: c64ee090070c90e9fd7e2014256e140c31c2b84d193051d88fefebbe72b9caaa 2023-09-07 20:35:06 8630 [Note] InnoDB: aa36b4985494699461a42852fe41a48ca248f91b5186496a1009f10320bc42d6 2023-09-07 20:35:06 8630 [Note] InnoDB: bef79c7b6fd53d7546a73df0b5caf5d53d6b7dafb5f63ed7ba3bdddbd7ceaeb5 2023-09-07 20:35:06 8630 [Note] InnoDB: 7fbefdb3d5e7b58ff2e2804eeedd3fa674ba789fee9547e9f8f4e4deebc7f4ee 2023-09-07 20:35:06 8630 [Note] InnoDB: e2f1bb2fef53393d3a7ef96be5e8f0e5d716f9381d3fb9f7069da6c5c1f26727 2023-09-07 20:35:06 8630 [Note] InnoDB: f71eec7ff5de57d2f13bf71e3c3a7aefbdc5e1c3ee95f4b013f28b27ef3f54c6 2023-09-07 20:35:06 8630 [Note] InnoDB: a44aac65a0646a544255978c7554b3d05652ff28ff3d12da3fdd5efff9cceaf3 2023-09-07 20:35:06 8630 [Note] InnoDB: f9bf6a9f7ff9853ffef2f667ff3bd7b2d4e43c9134ae70a69088490b1b6d0a2a 2023-09-07 20:35:06 8630 [Note] InnoDB: 7852f8bd97ae751feb1e0c1cfc7c6e0ebe4e3fa483e3270d8074ce09a77dd245 2023-09-07 20:35:06 8630 [Note] InnoDB: 7b321c284b67524ec12525580ed8b742c631dfbc3f85d9daa0133952d6280ab5 2023-09-07 20:35:06 8630 [Note] InnoDB: b028926a9456a6500d8b15e6dbdd7707ccfffbd4f27e1f7fa0c1705e0ac79c95 2023-09-07 20:35:06 8630 [Note] InnoDB: cb1c44c93269ca8695676d4b60dec9fa10388efff6fff4b8bfb4fd39e0a72cbc 2023-09-07 20:35:06 8630 [Note] InnoDB: 2c26daacaab2c20a5d3c809baa6355a29415feadbaffc5dcf8df4a070774daa5 2023-09-07 20:35:06 8630 [Note] InnoDB: c3da80d40684a565112db9a26a55896ba254bda7ec8a14b6e4818191d0710eae 2023-09-07 20:35:06 8630 [Note] InnoDB: ffd31407316a8a3a3b67854825e69482cd5278958b032f3d077bddf7060e7e39 2023-09-07 20:35:06 8630 [Note] InnoDB: 3707f7d3c9a3ee0de2c7402254c39102f08aaa751445db2475cd35e8685cd241 2023-09-07 20:35:06 8630 [Note] InnoDB: ca5a060a7623c719f8d4c15417184e5c925146061b0c33eace07e3654ac58283 2023-09-07 20:35:06 8630 [Note] InnoDB: 9e81e7bb3707067e357f172c96c5bc4c3fb28c311738666b63b5a1c860220aa0 2023-09-07 20:35:06 8630 [Note] InnoDB: ea628c8f9b06d8c48ca3defbd054de0ba98c660bd12a7c93641f3102285b6f63 2023-09-07 20:35:06 8630 [Note] InnoDB: 492a8715ea9bdd5b03ea5fcf8e3a1d1086f6c93bb46ce0200b5b4c7b2f7d724e 2023-09-07 20:35:06 8630 [Note] InnoDB: 3b5652b28dca5a5b83e5b0067e316c1cfbcdff9cca78100163d44aad35a66921 2023-09-07 20:35:06 8630 [Note] InnoDB: 937c44fb57a525c7487685fd56f79d01fb6fe6c6fe95633a39e9904384371482 2023-09-07 20:35:06 8630 [Note] InnoDB: 6b4e967c102a455d6d515a4b9b4375687965fd00fe72dc38fadb7f3f95791fdb 2023-09-07 20:35:06 8630 [Note] InnoDB: 2a11ca05cc561d42162260b21699bc9414d3d9e54df77f73a37f351d3ea4e325 2023-09-07 20:35:06 8630 [Note] InnoDB: 8050b35656b1e06c6370b93a8995a46b72a8f694f3007c2b641cf38dbda98cd7 2023-09-07 20:35:06 8630 [Note] InnoDB: a48553598548c280670cba5c94773561b4b0952bcccf76af0f987ffb34aa7db9 2023-09-07 20:35:06 8630 [Note] InnoDB: da83ab46d59443abbb1c83748c1fa4429cbc4a7abbcc2726da07a6d092d1de60 2023-09-07 20:35:06 8630 [Note] InnoDB: 60586da9266b52a02a5bad83578c939dbdb63f44ce57df8b9372f4f8f0b47bb3 2023-09-07 20:35:06 8630 [Note] InnoDB: 89b2e5682e3a20d55201371592229a9a527602722e665a36ddaac47743c739d8 2023-09-07 20:35:06 8630 [Note] InnoDB: fbc7290ed890434547634df499547186a3935240d529cb7dc637da66ff037373 2023-09-07 20:35:06 8630 [Note] InnoDB: d06fa7878b93533a6e304cb04a64af183c44e858283cfcc0d79065117993fa9d 2023-09-07 20:35:06 8630 [Note] InnoDB: c071fc2ffc5d8f7bb4cb33a5040e72c56c0f6d7114c8298af83236d5bb7ebedf 2023-09-07 20:35:06 8630 [Note] InnoDB: e886dcef7f706efc5f5df069f7e034adbad689e8bc434f1379a36cc88692a4a2 2023-09-07 20:35:06 8630 [Note] InnoDB: 30dcbca8d10de02f468d237ff1afa7328f0de25451b10a7210b34d356b2f8268 2023-09-07 20:35:06 8630 [Note] InnoDB: d97769691c2e56ff879e6ef52f2d092bacf0a86a4c55845ca3774a90909804d9 2023-09-07 20:35:06 8630 [Note] InnoDB:
Bug#1049362: clang SIMD compatibility headers broken on ppc64el
Package: libclang-common-15-dev Version: 1:15.0.7-8 Severity: important Tags: upstream Forwarded: https://github.com/llvm/llvm-project/issues/64664 After upgrading from clang 14 to clang 15 debian's chromium package fails to compile with SIMD errors: /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:71:25: error: use of undeclared identifier '__builtin_mffs' __fpscr_save.__fr = __builtin_mffs(); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:74:5: error: use of undeclared identifier '__builtin_mtfsf' __builtin_mtfsf(0b0011, __fpscr_save.__fr); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:86:25: error: use of undeclared identifier '__builtin_mffsl'; did you mean '__builtin_infl'? __fpscr_save.__fr = __builtin_mffsl(); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:86:25: note: '__builtin_infl' declared here /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:89:5: error: use of undeclared identifier '__builtin_set_fpscr_rn' __builtin_set_fpscr_rn(0b00); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:105:5: error: use of undeclared identifier '__builtin_set_fpscr_rn' __builtin_set_fpscr_rn(__fpscr_save.__fpscr); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:131:25: error: use of undeclared identifier '__builtin_mffsl'; did you mean '__builtin_infl'? __fpscr_save.__fr = __builtin_mffsl(); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:86:25: note: '__builtin_infl' declared here __fpscr_save.__fr = __builtin_mffsl(); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:133:5: error: use of undeclared identifier '__builtin_mtfsf' __builtin_mtfsf(0b0011, __fpscr_save.__fr); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:162:25: error: use of undeclared identifier '__builtin_mffs' __fpscr_save.__fr = __builtin_mffs(); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:165:5: error: use of undeclared identifier '__builtin_mtfsf' __builtin_mtfsf(0b0011, __fpscr_save.__fr); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:177:25: error: use of undeclared identifier '__builtin_mffsl'; did you mean '__builtin_infl'? __fpscr_save.__fr = __builtin_mffsl(); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:86:25: note: '__builtin_infl' declared here __fpscr_save.__fr = __builtin_mffsl(); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:180:5: error: use of undeclared identifier '__builtin_set_fpscr_rn' __builtin_set_fpscr_rn(0b00); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:196:5: error: use of undeclared identifier '__builtin_set_fpscr_rn' __builtin_set_fpscr_rn(__fpscr_save.__fpscr); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:222:25: error: use of undeclared identifier '__builtin_mffsl'; did you mean '__builtin_infl'? __fpscr_save.__fr = __builtin_mffsl(); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:86:25: note: '__builtin_infl' declared here __fpscr_save.__fr = __builtin_mffsl(); ^ /usr/lib/llvm-15/lib/clang/15.0.7/include/ppc_wrappers/smmintrin.h:224:5: error: use of undeclared identifier '__builtin_mtfsf' __builtin_mtfsf(0b0011, __fpscr_save.__fr); This is a bug in Clang, and is being tracked upstream at https://github.com/llvm/llvm-project/issues/64664
Bug#1042111: chromium: Web Environment Integrity
In my opinion, as a maintainer and user of Chromium (as distinct from Chrome), we absolutely need to ship this with the code removed / disabled. This is a deliberate attempt to lock out the open Web, to force the use of a Google-approved (and Google-locked) software, firmware, and hardware stack, and to enable persistent, lifelong tracking per user of every action ever taken on the Web. If a bank or similar requires it, then a separate (locked) commercial device should be used to interact with that specific commercial entity. It is not our responsibility as open source developers to work for free, or at the expense of companies supporting open ecosystems, in order to make it easy to access the services provided by hostile for-profit entities. Furthermore, it is the responsibility of the company requiring the locked commercial device to ensure it is fit for purpose, etc. at their own expense, and they need to bear the full financial and legal liability of that requirement. In some ways this is no different than the old Bluray fight. Illegal (in the US) access methods aside, people got used to using a separate player or other device and continued to enjoy their freedom to modify and use their Debian computers, privately, as they always had. This did not measurably harm Debian, and in fact probably helped as people begain to understand that the Debian ecosystem was trustworthy in the true sense, i.e. not watching every move or preventing access to key OS components. If this code is not removed, I would probably need to stop helping with the maintainance efforts. Conversely I am happy to step up and assist with the removal process.
Bug#1038744: Update Kotlin to 1.3.40 or higher to enable reflection for Jitsi
Package: kotlin Version: 1.3.31 When attempting to package Jitsi for Debian, I ran into a blocking issue due to Kotlin 1.3.31 not providing the typeOf() reflection function, which was introduced as experimental in Kotlin 1.3.40. Since the lift to move from one minor version to another is probably less than the lift needed to rewrite Jitsi's reflection code through its entire codebase, it would be useful to upgrade Kotlin to at least 1.3.40 in the Debian archives.
Bug#990016: marked as done (Debian installer images missing ASpeed video driver)
Earlier merge request was redundant, after futher tracing I believe this merge request directly addresses the root of the remaining issues: https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/34 - Original Message - > From: "Timothy Pearson" > To: "990016" <990...@bugs.debian.org> > Cc: "Salvatore Bonaccorso" > Sent: Monday, June 5, 2023 2:02:55 PM > Subject: Re: Bug#990016: marked as done (Debian installer images missing > ASpeed video driver) > Unfortunately it appears the bug persists. On the latest ppc64el netinst > weekly > build there is no trace of the ast module: > > ~ # modprobe ast > modprobe: FATAL: Module ast not found in directory > /lib/modules/6.1.0-9-powerpc64le
Bug#990016: marked as done (Debian installer images missing ASpeed video driver)
Issue traced and merge request opened here: https://salsa.debian.org/kernel-team/linux/-/merge_requests/743 - Original Message - > From: "Timothy Pearson" > To: "990016" <990...@bugs.debian.org> > Cc: "Salvatore Bonaccorso" > Sent: Monday, June 5, 2023 2:02:55 PM > Subject: Re: Bug#990016: marked as done (Debian installer images missing > ASpeed video driver) > Unfortunately it appears the bug persists. On the latest ppc64el netinst > weekly > build there is no trace of the ast module: > > ~ # modprobe ast > modprobe: FATAL: Module ast not found in directory > /lib/modules/6.1.0-9-powerpc64le
Bug#990016: marked as done (Debian installer images missing ASpeed video driver)
Unfortunately it appears the bug persists. On the latest ppc64el netinst weekly build there is no trace of the ast module: ~ # modprobe ast modprobe: FATAL: Module ast not found in directory /lib/modules/6.1.0-9-powerpc64le
Bug#1034538: gox doesn't work under linux/ppc64le
Package: gox Version: 0.3.0-8+b5 When attempting to build a package with the bundled gox version in Debian, it doesn't seem to understand linux/ppc64le and silently exits. Installing the upstream version directly with "go install" yields a working gox binary. Issue first discovered with the gitlab runner, report filed at https://gitlab.com/gitlab-org/gitlab-runner/-/issues/30954.
Bug#1033534:
Merge request to fix this bug here: https://salsa.debian.org/mozilla-team/thunderbird/-/merge_requests/7
Bug#1033534: Thunderbird unusable on ppc64el
Package: thunderbird Version: 1:102.9.0-1~deb11u1 Severity: important Thunderbird uses an incorrect SQLite endianness when built on a little endian ppc64 (ppc64el) system. As a result, it is unable to initialize and load its databases, leading to a blank / unusable application. There is some discussion upstream and potential patches at https://bugzilla.mozilla.org/show_bug.cgi?id=1757271
Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries
- Original Message - > From: "Andres Salomon" > To: "Soren Stoutner" > Cc: 1020...@bugs.debian.org, "Dmitry Shachnev" , "Agustin > Martin" , "Debian > Qt/KDE Maintainers" , "Roland > Rosenfeld" , "Rene Engelhard" > , "Mattia Rizzolo" , "Debian Chromium > Team" , > "Timothy Pearson" > Sent: Monday, December 26, 2022 2:33:52 PM > Subject: Re: Bug#1020387: dictionaries-common: Consensus regarding the > packaging of the Qt WebEngine hunspell binary > dictionaries > On Mon, Dec 26 2022 at 10:32:20 AM -0700, Soren Stoutner > wrote: >> Dmitry >> >> >> It hasn’t been discussed, but I think it would make sense for >> Chromium to ship the convert_dict tool as it is the upstream for the >> project. I suppose the reason why the discussion was around how it >> is shipped in the Qt packages was because that is the only place it >> is currently shipped in Debian: >> >> >> <https://packages.debian.org/search?searchon=contents=convert_dict=path=testing=any> >> >> >> Andres, do you have an comments on the feasibility of shipping >> convert_dict as part of a Chromium package targeted at developers? >> >> > > > It's definitely feasible*. However, there's the question of whether we > want other important packages depending on chromium. > https://bugs.debian.org/1004441 shows that it's still an outstanding > question whether chromium will even ship in bookworm. I now have Tim > helping with packaging, which is wonderful and a huge help (thanks > Tim!), but he doesn't have upload privs. For what it's worth I'm interested in obtaining upload privileges to further assist, but I think I need a sponsor etc. for that process? Thanks!
Bug#1022251: libsndfile links against libFLAC.so.8, causing linker errors
Package: libsndfile1 Version: 1.1.0-3 Severity: important Tags: sid X-Debbugs-CC: dilin...@queued.net When attempting to build an application that uses both libsndfile and libFLAC, the application fails to link with "/usr/bin/ld: warning: libFLAC.so.8, needed by /lib/-linux-gnu/libsndfile.so.1, may conflict with libFLAC.so.12" It appears this issue was introduced in the last libFLAC update on Oct. 14. libsndfile probably needs to be (re)built against libFLAC.so.12 to resolve the problem.
Bug#1021415: Acknowledgement (SIGSEGV when attempting to enter chroot)
affects chroot After investigation, this appears to be the same bug as #1021109. Installing the locales package and adding a default locale prior to upgrading to sid appears to work around the issue. - Original Message - > From: "Debian Bug Tracking System" > To: "Timothy Pearson" > Sent: Friday, October 7, 2022 6:00:04 PM > Subject: Bug#1021415: Acknowledgement (SIGSEGV when attempting to enter > chroot) > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 1021415: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021415. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Matthias Klose > > If you wish to submit further information on this problem, please > send it to 1021...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 1021415: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021415 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Bug#1021415: SIGSEGV when attempting to enter chroot
Package: bash Version: 5.2-1 When attempting to enter a sid chroot on ppc64el, bash causes a SIGSEGV. Confirmed to be in the bash package by successfully installing a bookworm chroot, then confirming the crash occurs after upgrading only bash to the version in sid.
Bug#1016047:
The areas I'm specifically interested in helping with are the security updates and the ungoogled Chromium patchset -- I'm already maintaining the ungoogled patches on top of the ppc64el patches, and I'd like to get both of those in Debian proper.
Bug#1016047:
I'm willing to help out, provided I can also work toward enabling ppc64el support in the official packages. I'm already on the biweekly pull / build schedule as a result of needing to patch + rebuild the ppc64el binaries, so am familiar with the workload involved. On my Talos II workstation the build time is around an hour, so I should be able to iterate significantly faster as needed.
Bug#1005083: Chromium 99 update
As a quick update, I'm starting another push (small at first) to try to get some of the more downstream-invasive changes upstream. Starting with the build config generators, as downstream distros can only patch in the entire generated config which gets messy. https://chromium-review.googlesource.com/c/chromium/src/+/3626304 https://chromium-review.googlesource.com/c/chromium/src/+/3627862 https://chromium-review.googlesource.com/c/chromium/src/+/3626305 Let's see how those three are received and plan from there...
Bug#1005083: Chromium 99 update
- Original Message - > From: "Andres Salomon" > To: "1005083" <1005...@bugs.debian.org> > Cc: "Timothy Pearson" > Sent: Tuesday, February 15, 2022 4:21:27 PM > Subject: Re: Chromium 99 update > > Hi, > > So the good news is, I'm not opposed to these patches in theory, > especially if you're working with upstream to get them merged. The bad > news is the timing. I just took over chromium, and I've been working to > get fewer debian-specific patches rather than more. We've gone from > 70-something patches to 50-something patches, dropping irrelevant (and > often undocumented) ones and getting some upstream. I still have a lot > more patches to work through before I'm in a place where I'd be > comfortable considering patches for a new platform. So I'd be open to > continuing this discussion in the chromium 100/101 time frame. Great to hear and definitely looking forward to continuing discussion as you have time for Chromium 100 or so. I'll continue to update the patchset in the interim and build (where practical) on the Raptor build farm -- the latter will be made a bit easier as newer versions are backported to Bullseye. > BTW, do you have links to any upstream gerrit or bug entries so I can > see why upstream doesn't want to support a new architecture? There is a long and complex history here, much of it out of the public eye, but the long and short of it is that Google simply doesn't want to put effort into supporting an architecture it doesn't use / ship hardware products (Chromebook / Pixel) for. Personally I have suspicions that it goes deeper, into the owner control aspects of the POWER systems currently shipping (e.g. Widevine will never work by design, and it will be harder to track users in the future without various vendor components (Intel ME/AMD PSP/ARM Trustzone) subverting the OS, but the latter is still pure speculation on my part. At the end of the day it's likely a pure business decision from Google -- one less architecture to support means fewer employees working on the Chromium project overall and lower costs / faster code churn. Here are some of the public bugs and Google's responses: https://bugs.chromium.org/p/chromium/issues/detail?id=925171 https://bugs.chromium.org/p/chromium/issues/detail?id=1029662 https://bugs.chromium.org/p/chromium/issues/detail?id=1076455 Note I am willing to try to re-enage with upstream and see if there has been an opportunity for merge created with e.g. Gentoo and Void shipping Chromium with these patches enabled. If Debian (and by extension Ubuntu?) were to also add the patches, that would help with the overall business case in terms of the real-world need to have the patches accepted by upstream. Thoughts welcome!
Bug#990279: Status?
- Original Message - > From: "Salvatore Bonaccorso" > To: "Timothy Pearson" , "990279" > <990...@bugs.debian.org> > Cc: "Christian König" , "Xi Ruoyao" > , "Alex Deucher" > > Sent: Wednesday, February 9, 2022 2:18:34 PM > Subject: Re: Bug#990279: Status? > Hi Timothy, > > On Wed, Feb 09, 2022 at 01:20:40PM -0600, Timothy Pearson wrote: >> - Original Message - >> > From: "Christian König" >> > To: "Timothy Pearson" , "Salvatore >> > Bonaccorso" >> > >> >> >> >> If you need me to generate / submit a patch just let me know. >> > >> > Please do, I don't have time nor a test system to look into this. >> > >> > Regards, >> > Christian. >> >> Submitted here: >> https://lists.debian.org/debian-kernel/2022/02/msg00099.html > > This is not exactly what we meant. The idea is to submit it to > upstream for stable 5.10.y so we can pick it up in Debian. I'm taking > the backport in #47 now. > > It is now submitted here: > https://lore.kernel.org/stable/20220209201624.1234062-1-car...@debian.org/T/#u > > Regards, > Salvatore Understood, apologies for the mixup. I'll monitor the upstream submission and help push it through if needed. Thanks!
Bug#990279: Status?
- Original Message - > From: "Salvatore Bonaccorso" > To: "Timothy Pearson" , "990279" > <990...@bugs.debian.org> > Cc: "Christian König" , "Xi Ruoyao" > , "Alex Deucher" > > Sent: Tuesday, February 8, 2022 3:16:32 PM > Subject: Re: Bug#990279: Status? > Hi Timothy, > > On Tue, Feb 08, 2022 at 01:23:10PM -0600, Timothy Pearson wrote: >> I can confirm Bullseye is still affected by this bug. >> >> Is there any chance of this fix being applied to the Bullseye stable >> kernels? We're having to maintain kernel builds in our own >> repositories to fix this regression, and that introduces some lag >> when e.g. security updates are pushed to Debian. > > This needs someone to submit a (tested) backport patch to > stable maintainers, so it can be applied in the 5.10.y stable series. I can confirm the patch in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990279#47 is what we're using and that it does work as intended. If you need me to generate / submit a patch just let me know. > Christian, would it be possible to do that? Cf. > https://bugs.debian.org/990279#42 and > https://bugs.debian.org/990279#52 > > Regards, > Salvatore
Bug#990279: Status?
I can confirm Bullseye is still affected by this bug. Is there any chance of this fix being applied to the Bullseye stable kernels? We're having to maintain kernel builds in our own repositories to fix this regression, and that introduces some lag when e.g. security updates are pushed to Debian.
Bug#990016: Debian installer images missing ASpeed video driver
We just got hit with this again, in a customer-facing issue this time. The ASpeed video driver is going to be useful for nearly any non-x86 platform; i.e. any platform that is not likely to have a standard video BIOS / character mode display fallback but still have a display attached. That means ppc64el, arm64, riscv, sparc64 in practice. - Original Message - > From: "Jochen Sprickerhof" > To: "Timothy Pearson" , 990...@bugs.debian.org > Sent: Saturday, July 10, 2021 1:09:14 PM > Subject: Re: Bug#990016: Debian installer images missing ASpeed video driver > Control: reassign -1 src:linux > > Hi Timothy, > > * Timothy Pearson [2021-06-17 15:46]: >>The current Bullseye installer images don't include the "ast" video driver, >>making it impossible to install Debian on systems that don't have a fallback >>VGA BIOS (anything non-x86, e.g. ARM/OpenPOWER). >> >>Ubuntu fixed this issue almost 5 years ago: >>https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1514711 >> >>Please include the "ast" kernel module, which does not require any proprietary >>firmware to function, in the Debian installer CD images. > > The module is part of the fb-modules-5.10.0-7-arm64-di: > > https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/installer/modules/arm64/fb-modules#L3 > > and fb-modules-5.10.0-7-loongson-3-di: > > https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/installer/modules/mipsel-loongson-3/fb-modules#L5 > > Additionally CONFIG_DRM_AST is enabled for ppc64: > > https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/kernelarch-powerpc/config-arch-64#L94 > > and x86: > > https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/kernelarch-x86/config#L519 > > So I assume it should be easy to add the module to the corresponding > udebs. Reassigning to the linux package, accordingly. > > I guess it would help if you could be more specific on which > architectures it would be useful. > > Cheers Jochen
Bug#990279: Also affects stable...
Reverting this patch restores the GPU to functionality: drm/amdgpu: check alignment on CPU page for bo map diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index dc4d6ae71476..a01c158bc29f 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -2198,8 +2198,8 @@ int amdgpu_vm_bo_map(struct amdgpu_device *adev, uint64_t eaddr; /* validate the parameters */ - if (saddr & AMDGPU_GPU_PAGE_MASK || offset & AMDGPU_GPU_PAGE_MASK || - size == 0 || size & AMDGPU_GPU_PAGE_MASK) + if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK || + size == 0 || size & ~PAGE_MASK) return -EINVAL; /* make sure object fit at this offset */ @@ -2264,8 +2264,8 @@ int amdgpu_vm_bo_replace_map(struct amdgpu_device *adev, int r; /* validate the parameters */ - if (saddr & AMDGPU_GPU_PAGE_MASK || offset & AMDGPU_GPU_PAGE_MASK || - size == 0 || size & AMDGPU_GPU_PAGE_MASK) + if (saddr & ~PAGE_MASK || offset & ~PAGE_MASK || + size == 0 || size & ~PAGE_MASK) return -EINVAL; /* make sure object fit at this offset */ As nearly all POWER distros ship a 64k page kernel, the switch from AMDGPU_GPU_PAGE_MASK to PAGE_MASK may be at fault. As an aside, it seems there is little to no QA for POWER desktop systems from the Debian developers. If this is due to lack of hardware access, we may be able to assist. - Original Message - > From: "Timothy Pearson" > To: "990279" <990...@bugs.debian.org> > Sent: Saturday, July 24, 2021 11:42:02 PM > Subject: Also affects stable... > Just hit this upgrading a stable box from 4.19.0-6-powerpc64le to > 4.19.0-17-powerpc64le. AMD RX480, works perfectly again after downgrading to > the older kernel.
Bug#990279: Also affects stable...
Just hit this upgrading a stable box from 4.19.0-6-powerpc64le to 4.19.0-17-powerpc64le. AMD RX480, works perfectly again after downgrading to the older kernel.
Bug#990017: [REGRESSION] Bullseye CD installer images fail to install GRUB on OpenPOWER machines
- Original Message - > From: "Timothy Pearson" > To: "Steve McIntyre" > Cc: "990017" <990...@bugs.debian.org> > Sent: Thursday, June 17, 2021 7:56:27 PM > Subject: Re: Bug#990017: [REGRESSION] Bullseye CD installer images fail to > install GRUB on OpenPOWER machines > - Original Message - >> From: "Steve McIntyre" >> To: "Timothy Pearson" , >> 990...@bugs.debian.org >> Sent: Thursday, June 17, 2021 7:43:15 PM >> Subject: Re: Bug#990017: [REGRESSION] Bullseye CD installer images fail to >> install GRUB on OpenPOWER machines > >> Control: reassign -1 grub-ieee1275 >> >> Hi Timothy, >> >> Reassigning this to the correct package where it should get more >> attention... > > Thank you, much appreciated. > >> On Thu, Jun 17, 2021 at 04:20:47PM -0500, Timothy Pearson wrote: >>>Package: debian-cd >>>Severity: Grave >>> >>>Attempting to use the latest Bullseye RC2 CD installer on an OpenPOWER >>>machine >>>results in a fatal error during bootloader installation: >>> >>>Jun 17 21:14:45 grub-installer: info: Installing grub on '/dev/sda1' >>>Jun 17 21:14:45 grub-installer: info: grub-install does not support >>>--no-floppy >>>Jun 17 21:14:45 grub-installer: info: Running chroot /target grub-install >>>--force "/dev/sda1" >>>Jun 17 21:14:45 grub-installer: Installing for powerpc-ieee1275 platform. >>>Jun 17 21:14:57 grub-installer: grub-install: error: unknown filesystem. >>>Jun 17 21:14:57 grub-installer: error: Running 'grub-install --force >>>"/dev/sda1"' failed. >>> >>>The bootloader installs normally using the Buster CD installers on the same >>>hardware. >> >> Just a quick sanity check - how did you partition the disk? Does it >> have the normal boot partition etc. needed for OpenPOWER? I'll admit I >> don't know all the details here - I'm not a powerpc expert. > > All defaults. PReP partition was added automatically by the apparition, it > almost looks like Grub doesn't know what to do with it? > > Layout: > PReP: /dev/sda1 > System: /dev/sda2 > Swap: /dev/sda3 Correction: that should read "by the partitioner" above. Autocorrect didn't like that word. :)
Bug#990017: [REGRESSION] Bullseye CD installer images fail to install GRUB on OpenPOWER machines
- Original Message - > From: "Steve McIntyre" > To: "Timothy Pearson" , 990...@bugs.debian.org > Sent: Thursday, June 17, 2021 7:43:15 PM > Subject: Re: Bug#990017: [REGRESSION] Bullseye CD installer images fail to > install GRUB on OpenPOWER machines > Control: reassign -1 grub-ieee1275 > > Hi Timothy, > > Reassigning this to the correct package where it should get more > attention... Thank you, much appreciated. > On Thu, Jun 17, 2021 at 04:20:47PM -0500, Timothy Pearson wrote: >>Package: debian-cd >>Severity: Grave >> >>Attempting to use the latest Bullseye RC2 CD installer on an OpenPOWER machine >>results in a fatal error during bootloader installation: >> >>Jun 17 21:14:45 grub-installer: info: Installing grub on '/dev/sda1' >>Jun 17 21:14:45 grub-installer: info: grub-install does not support >>--no-floppy >>Jun 17 21:14:45 grub-installer: info: Running chroot /target grub-install >>--force "/dev/sda1" >>Jun 17 21:14:45 grub-installer: Installing for powerpc-ieee1275 platform. >>Jun 17 21:14:57 grub-installer: grub-install: error: unknown filesystem. >>Jun 17 21:14:57 grub-installer: error: Running 'grub-install --force >>"/dev/sda1"' failed. >> >>The bootloader installs normally using the Buster CD installers on the same >>hardware. > > Just a quick sanity check - how did you partition the disk? Does it > have the normal boot partition etc. needed for OpenPOWER? I'll admit I > don't know all the details here - I'm not a powerpc expert. All defaults. PReP partition was added automatically by the apparition, it almost looks like Grub doesn't know what to do with it? Layout: PReP: /dev/sda1 System: /dev/sda2 Swap: /dev/sda3
Bug#990017: [REGRESSION] Bullseye CD installer images fail to install GRUB on OpenPOWER machines
Package: debian-cd Severity: Grave Attempting to use the latest Bullseye RC2 CD installer on an OpenPOWER machine results in a fatal error during bootloader installation: Jun 17 21:14:45 grub-installer: info: Installing grub on '/dev/sda1' Jun 17 21:14:45 grub-installer: info: grub-install does not support --no-floppy Jun 17 21:14:45 grub-installer: info: Running chroot /target grub-install --force "/dev/sda1" Jun 17 21:14:45 grub-installer: Installing for powerpc-ieee1275 platform. Jun 17 21:14:57 grub-installer: grub-install: error: unknown filesystem. Jun 17 21:14:57 grub-installer: error: Running 'grub-install --force "/dev/sda1"' failed. The bootloader installs normally using the Buster CD installers on the same hardware.
Bug#990016: Debian installer images missing ASpeed video driver
Package: debian-cd Severity: Important The current Bullseye installer images don't include the "ast" video driver, making it impossible to install Debian on systems that don't have a fallback VGA BIOS (anything non-x86, e.g. ARM/OpenPOWER). Ubuntu fixed this issue almost 5 years ago: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1514711 Please include the "ast" kernel module, which does not require any proprietary firmware to function, in the Debian installer CD images.
Bug#989212: No LiveCD available for ppc64le
Package: debian-cd Despite having a wide deployment of desktop-class systems, the ppc64le port does not have a live CD/DVD available. This makes installation needlessly difficult on desktop machines that may or may not have external BMC or serial access, given that the installer images also assume no graphical output is available (console=hvc0 is passed by default). Other distributions such as Fedora are currently offering LiveCDs for ppc64le. Debian should do the same, with a version that includes the proprietary card-side firmware for commonly available GPUs with fully open source drivers (e.g. AMD GPUs).
Bug#960897: Update android-platform-external-libunwind and build for ppc64el
- Original Message - > From: "殷啟聰 | Kai-Chung Yan" > To: 960...@bugs.debian.org, "Timothy Pearson" > Sent: Sunday, May 17, 2020 11:13:32 PM > Subject: Re: Update android-platform-external-libunwind and build for ppc64el >> According to the source trees at both >> https://github.com/Unity-Technologies/android-libunwind and >> https://android.googlesource.com/platform/external/libunwind/, ppc64[le] >> systems are supported. > > I doubt it. Android never officially supported architectures other than x86, > ARM > or MIPS. And these days MIPS support is being removed. The source tree for > PowerPC is probably from the original `libunwind` and never touched by Google. > > Even if it builds successfully in PowerPC, I'm quite sure it was never tested. Is there any reason not to build the ppc64el version though, especially since there is no ppc64el Android version in existence? It's blocking adb, which I can confirm works fine on ppc64el *if* manually compiled.
Bug#960897: Update android-platform-external-libunwind and build for ppc64el
Package: android-platform-external-libunwind According to the source trees at both https://github.com/Unity-Technologies/android-libunwind and https://android.googlesource.com/platform/external/libunwind/, ppc64[le] systems are supported. However, the version in Debian, even Sid, explicitly removes and disables support for ppc66el. Please update to the current version and re-enable ppc64el builds. There are several Android host-side tools, including adb, that are blocked partly by the lack of a build for this library on ppc64el.
Bug#959487: libpng built without VSX support on ppc64le
Package: libpng16-16:ppc64le Version: 1.6.36-6 libpng is built without VSX support on POWER systems. This breaks assumptions in other software, such as node optipng (log below). I can work around it with this, but it is not ideal: CFLAGS="-DPNG_POWERPC_VSX_OPT=0" npm install optipng-bin npm install optipng-bin npm WARN npm npm does not support Node.js v10.15.2 npm WARN npm You should probably upgrade to a newer version of node as we npm WARN npm can't make any promises that npm will work with this version. npm WARN npm Supported releases of Node.js are the latest release of 4, 6, 7, 8, 9. npm WARN npm You can find the latest version at https:/nodejs.org/ > optipng-bin@6.0.0 postinstall > /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin > node lib/install.js ⚠ Command failed: /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng --version /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: 1: /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: @@8�@@@�: not found /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: 2: /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: d: not found /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: 1: /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: ELF: not found /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: 1: /home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/vendor/optipng: Syntax error: ";" unexpected ⚠ optipng pre-build test failed ℹ compiling from source ✖ Error: Command failed: /bin/sh -c make install pngrtran.c:99:1: warning: ‘png_rtran_ok’ defined but not used [-Wunused-function] png_rtran_ok(png_structrp png_ptr, int need_IHDR) ^~~~ ar: `u' modifier ignored since `D' is the default (see `U') ar: `u' modifier ignored since `D' is the default (see `U') ar: `u' modifier ignored since `D' is the default (see `U') ar: `u' modifier ignored since `D' is the default (see `U') pngxmem.c: In function ‘pngx_malloc_rows_extended’: pngxmem.c:38:34: warning: comparison is always false due to limited range of data type [-Wtype-limits] (pngx_alloc_size_t)height > (pngx_alloc_size_t)(-1) / sizeof(png_bytep)) ^ ar: `u' modifier ignored since `D' is the default (see `U') /usr/bin/ld: ../libpng/libpng.a(pngrutil.o): in function `png_read_filter_row': pngrutil.c:(.text+0x29c0): undefined reference to `png_init_filter_functions_vsx' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:100: optipng] Error 1 make: *** [Makefile:14: install] Error 2 cd src/optipng && \ make install && \ cd ../.. make[1]: Entering directory '/home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/a4e0fea9-c020-4419-98f6-a1b3d4dfc863/src/optipng' cd ../libpng && \ make -f Makefile PNGLIBCONF_H_PREBUILT=pnglibconf.h.optipng && \ cd ../optipng make[2]: Entering directory '/home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/a4e0fea9-c020-4419-98f6-a1b3d4dfc863/src/libpng' cp pnglibconf.h.optipng pnglibconf.h gcc -c -I../zlib -O2 -Wall -Wextra -o png.o png.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngerror.o pngerror.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngget.o pngget.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngmem.o pngmem.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngpread.o pngpread.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngread.o pngread.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngrio.o pngrio.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngrtran.o pngrtran.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngrutil.o pngrutil.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngset.o pngset.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngtrans.o pngtrans.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngwio.o pngwio.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngwrite.o pngwrite.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngwtran.o pngwtran.c gcc -c -I../zlib -O2 -Wall -Wextra -o pngwutil.o pngwutil.c ar rcs libpng.a png.o pngerror.o pngget.o pngmem.o pngpread.o pngread.o pngrio.o pngrtran.o pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o pngwutil.o ranlib libpng.a gcc -c -I../zlib -O2 -Wall -Wextra -o pngtest.o pngtest.c gcc -L../zlib -o pngtest pngtest.o libpng.a -lz -lm make[2]: Leaving directory '/home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/a4e0fea9-c020-4419-98f6-a1b3d4dfc863/src/libpng' cd ../opngreduc && \ make -f Makefile libopngreduc.a && \ cd ../optipng make[2]: Entering directory '/home/develop/build/ONLYOFFICE/build_tools/node_modules/optipng-bin/a4e0fea9-c020-4419-98f6-a1b3d4dfc863/src/opngreduc' gcc -c -O2 -Wall -Wextra -I../libpng -o opngreduc.o opngreduc.c ar cru libopngreduc.a opngreduc.o ranlib libopngreduc.a make[2]: Leaving directory
Bug#955466: bind daemon crashes with assert
Package: bind9 Version: 1:9.11.5.P4+dfsg-5.1 Latest Debian Buster ppc64le, bind9 keeps crashing every few days with an assert: named[412]: ../../../lib/dns/rbtdb.c:10330: INSIST(((void *)((header)->link.prev) != (void *)(-1))) failed, back trace named[412]: #0 0x10609cee8 in ?? named[412]: #1 0x7fffa206d6e8 in ?? named[412]: #2 0x7fffa2882f84 in ?? named[412]: #3 0x7fffa28899d8 in ?? named[412]: #4 0x7fffa288a17c in ?? named[412]: #5 0x7fffa280b224 in ?? named[412]: #6 0x1060b50f0 in ?? named[412]: #7 0x1060b5e08 in ?? named[412]: #8 0x7fffa20a5b4c in ?? named[412]: #9 0x7fffa1ed8b90 in ?? named[412]: #10 0x7fffa19e1018 in ?? named[412]: exiting (due to assertion failure) systemd[1]: bind9.service: Main process exited, code=killed, status=6/ABRT systemd[1]: bind9.service: Failed with result 'signal'. This appeared after an upgrade from Stretch; the old bind version was not affected.
Bug#944501: Missing ppc64le builds
Package: reptyr Version: 0.6.2-1.2 Upstream reptyr 0.70 now has support for PowerPC. We tested it earlier today to great success, however the older 0.6.2 version in Debian lacks this support and we had to build from GIT. Please update to the latest reptyr release and enable ppc64le builds. Thank you!
Bug#933299: isohybrid.pl should not be architecture dependent
Package: syslinux-utils Version: 3:6.04~git20190206.bf6db5b4+dfsg1-1 There are two versions of the hybrid ISO utility, a native C implementation and a Perl version. Neither of these should be in the architecture-dependent (x86-only) syslinux-utils package, but especially the Perl version of the script should be moved to syslinux-common (which is architecture-independent).
Bug#932851: systemd causes diskless nodes to stop working / require hard reset
Package: systemd Version: 241-5 Ever since the switch to systemd we have been experiencing significant problems with our diskless nodes, where if the NFS connection is dropped for any reason (NFS server reboot, network router state reset, etc.) there is a high chance the diskless nodes will enter an unrecoverable state and require a hard reset (power off, power on). While we've been working around this for a while and assumed it was just a Debian quirk, I was able to obtain the following trace from the console of a hung system today: [820689.313769] nfs: server 192.168.1.1 not responding, still trying [820693.530338] nfs: server 192.168.1.1 not responding, still trying [820693.530451] nfs: server 192.168.1.1 not responding, still trying [820696.994677] nfs: server 192.168.1.1 not responding, still trying [820697.218891] nfs: server 192.168.1.1 not responding, still trying [820697.698918] nfs: server 192.168.1.1 not responding, still trying [820698.106834] nfs: server 192.168.1.1 not responding, still trying [820721.177609] nfs: server 192.168.1.1 not responding, still trying [820725.466102] nfs: server 192.168.1.1 not responding, still trying [820818.681006] watchdog: BUG: soft lockup - CPU#2 stuck for 21s! [systemd-logind:273] [820932.960202] INFO: task openvpn:5096 blocked for more than 120 seconds. [820937.889046] nfs: server 192.168.1.1 OK [820937.889226] nfs: server 192.168.1.1 OK [820937.889374] nfs: server 192.168.1.1 OK [820937.889381] nfs: server 192.168.1.1 OK [820937.889448] nfs: server 192.168.1.1 OK [820937.889503] nfs: server 192.168.1.1 OK [820937.889574] nfs: server 192.168.1.1 OK [820937.889665] nfs: server 192.168.1.1 OK [820937.889670] nfs: server 192.168.1.1 OK [820937.889674] nfs: server 192.168.1.1 OK [820937.903880] systemd-journald[171]: Failed to open system journal: Permission denied [820938.083071] systemd[1]: systemd-journald.service: Main process exited, code=killed, status=6/ABRT [820938.57] systemd[1]: systemd-journald.service: Failed to kill control group /system.slice/systemd-journald.service, ignoring: Permission denied [820938.124774] systemd[1]: systemd-journald.service: Failed to kill control group /system.slice/systemd-journald.service, ignoring: Permission denied [820938.131244] systemd[1]: systemd-journald.service: Unit entered failed state. [820938.131418] systemd[1]: systemd-journald.service: Failed with result 'watchdog'. [820938.144754] systemd[1]: systemd-udevd.service: Main process exited, code=killed, status=6/ABRT [820938.170807] systemd[1]: systemd-udevd.service: Failed to kill control group /system.slice/systemd-udevd.service, ignoring: Permission denied [820938.177666] systemd[1]: systemd-udevd.service: Unit entered failed state. [820938.177798] systemd[1]: systemd-udevd.service: Failed with result 'watchdog'. [820938.189036] systemd[1]: systemd-udevd.service: Service has no hold-off time, scheduling restart. This fairly clearly puts the blame somewhere in systemd, which makes sense as our older non-systemd machines recover perfectly fine from even extended NFS server failures. At minimum the systemd watchdog should probably be disabled while the NFS server is unavailable.
Bug#923860: rsync crashes sporadically when remote host closes connection
On 03/06/2019 05:40 AM, Paul Slootman wrote: > On Wed 06 Mar 2019, Timothy Pearson wrote: > >> Package: rsync >> Version: 0.9.7-10+b1 > > This is either a really ancient version, or a version not related to > rsync. Please check this. What does 'rsync --version' show? > > > Paul Apologies, pasted the wrong version line (librsync). The version is actually 3.1.3-5; this is an up-to-date Buster system.
Bug#923860: rsync crashes sporadically when remote host closes connection
Package: rsync Version: 0.9.7-10+b1 rsync occasionally crashes with a SIGSEGV when run from a cron job and the remote host closes the connection unexpectedly. Backtrace: > Core was generated by `rsync -av user@test-host:/first/path/file > /second/path/file'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 utf8_internal_loop (irreversible=, outend=, > outptrp=, inend=0x7fffcb50deda "\n", inptrp= out>, step_data=, step=) at ../iconv/loop.c:336 > 336 ../iconv/loop.c: No such file or directory. > (gdb) bt > #0 utf8_internal_loop (irreversible=, outend=, > outptrp=, inend=0x7fffcb50deda "\n", inptrp= out>, step_data=, step=) at ../iconv/loop.c:336 > #1 __gconv_transform_utf8_internal (step=0x105c41a50, data=0x105c41b40, > inptrp=0x7fffcb50d4e8, inend=0x7fffcb50deda "\n", outbufstart=0x0, > irreversible=0x7fffcb50d440, do_flush=, > consume_incomplete=) > at ../iconv/skeleton.c:609 > #2 0x7fff8609633c in __gconv (cd=0x105c41b30, inbuf=0x7fffcb50d4e8, > inbufend=0x7fffcb50deda "\n", outbuf=0x7fffcb50d500, outbufend= out>, irreversible=0x7fffcb50d440) at gconv.c:78 > #3 0x7fff860956b8 in iconv (cd=, inbuf=0x7fffcb50d4e8, > inbytesleft=0x7fffcb50d4f0, outbuf=0x7fffcb50d500, > outbytesleft=0x7fffcb50d4f8) at iconv.c:52 > #4 0x0001001f6998 in iconvbufs (ic=0x105c41b30, in=0x7fffcb50ddd0, > out=0x7fffcb50ddf0, flags=) at rsync.c:209 > #5 0x000100217508 in rwrite (code=, code@entry=FERROR, > buf=, buf@entry=0x7fffcb50de90 "rsync: connection unexpectedly > closed (0 bytes received so far) [Receiver]\n", len=, > is_utf8=, is_utf8@entry=0) at log.c:375 > #6 0x000100217cd8 in rprintf (code=, format=0x100261be0 > "rsync: connection unexpectedly closed (%s bytes received so far) [%s]\n") at > log.c:434 > #7 0x000100223378 in whine_about_eof (allow_kluge=allow_kluge@entry=0) > at inums.h:22 > #8 0x0001002282f8 in read_buf (f=, > buf=buf@entry=0x7fffcb50f390 "\037", len=len@entry=4) at io.c:1825 > #9 0x000100228480 in read_int (f=) at io.c:1720 > #10 0x00010022ac64 in setup_protocol (f_out=, > f_in=) at compat.c:160 > #11 0x000100212ab8 in client_run (f_in=, f_out= out>, pid=, argc=, argv=0x105c41628) at > main.c:1152 > #12 0x0001001e9d68 in start_client (argv=, argc=1) at > main.c:1447 > #13 main (argc=, argv=) at main.c:1673
Bug#904380: (no subject)
Just wanted to see if this was something we could get applied to the kernel. Right now people are needing to rebuild their kernels locally to update firmware, or use a more complex out of band update mechanism, which is not ideal.
Bug#904380: [PATCH] Flash partitions not showing up on PowerNV systems
Package: linux-image-4.17.0-1-powerpc64le Version: 4.17.8-1 The MTD partitions of the main firmware Flash device are not exposed as MTD device nodes on PowerNV systems. This makes firmware updates difficult, requiring manual intervention on the loader shell. This issue has been fixed upstream via a one-line kernel patch (attached, see also [1]). Debian kernels should include this patch to allow firmware updates to be applied to PowerNV machines. Thank you! [1] https://patchwork.ozlabs.org/patch/943327/ >From patchwork Fri Jul 13 08:15:59 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: mtd: powernv_flash: set of_node in mtd's dev X-Patchwork-Submitter: =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= X-Patchwork-Id: 943327 X-Patchwork-Delegate: boris.brezil...@free-electrons.com Message-Id: <20180713081559.4373-1-zaj...@gmail.com> To: David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Richard Weinberger Cc: Benjamin Herrenschmidt , Timothy Pearson , linux-...@lists.infradead.org, Michael Ellerman , Miquel Raynal , =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= , Paul Mackerras , linuxppc-...@lists.ozlabs.org, Cyril Bur Date: Fri, 13 Jul 2018 10:15:59 +0200 From: =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= List-Id: Linux MTD discussion mailing list From: RafaÅ MiÅecki This enables some features implemented in mtd subsystem like reading label and partitioning info from DT. Reported-by: Timothy Pearson Signed-off-by: RafaÅ MiÅecki --- drivers/mtd/devices/powernv_flash.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/devices/powernv_flash.c b/drivers/mtd/devices/powernv_flash.c index c1312b141ae0..33593122e49b 100644 --- a/drivers/mtd/devices/powernv_flash.c +++ b/drivers/mtd/devices/powernv_flash.c @@ -223,6 +223,7 @@ static int powernv_flash_set_driver_info(struct device *dev, mtd->_read = powernv_flash_read; mtd->_write = powernv_flash_write; mtd->dev.parent = dev; + mtd_set_of_node(mtd, dev->of_node); return 0; }
Bug#902246: (no subject)
This was actually a bug in mesa. See https://bugs.freedesktop.org/show_bug.cgi?id=107012
Bug#902247: Acknowledgement (glxgears crashes with SIGSEGV on ppc64el with amdgpu graphics)
This is actually a bug in mesa. See https://bugs.freedesktop.org/show_bug.cgi?id=107012 .
Bug#902247: glxgears crashes with SIGSEGV on ppc64el with amdgpu graphics
Package: mesa-utils Version: 8.4.0-1 glxgears crashes immediately on startup using the amdgpu drivers. Other 3D applications, including complex ones like rss-glx, openarena, and supertux, work fine. Package xserver-xorg-video-amdgpu is version 18.0.1-1. Kernel is 4.18 staging. Backtrace: > Thread 9 (Thread 0x7fffe9fbf160 (LWP 4797)): > #0 0x72ae5ec4 in llvm::Value::getContext() const () from > /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1 > #1 0x72ae7db8 in llvm::Value::setNameImpl(llvm::Twine const&) () > from /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1 > #2 0x72ae8140 in llvm::Value::setName(llvm::Twine const&) () from > /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1 > #3 0x72a67b60 in > llvm::ExtractValueInst::init(llvm::ArrayRef, llvm::Twine > const&) () from /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1 > #4 0x729ee6f0 in LLVMBuildExtractValue () from > /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1 > #5 0x769bb2e4 in si_build_ps_prolog_function (ctx=0x7fffe9fb9e80, > key=0x7fffe9fbe152) at > ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7722 > #6 0x769bf8c8 in si_get_shader_part (sscreen=0x100104f00, > list=0x100105448, type=PIPE_SHADER_FRAGMENT, prolog=true, key=0x7fffe9fbe152, > tm=0x1000aca60, debug=0x7fffc80adc68, build=0x769bab40 > , > name=0x76bb8420 "Fragment Shader Prolog") at > ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7154 > #7 0x769c25c0 in si_shader_select_ps_parts (debug=0x7fffc80adc68, > shader=0x7fffc80adc60, tm=0x1000aca60, sscreen=0x100104f00) at > ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7924 > #8 si_shader_create (sscreen=0x100104f00, tm=0x1000aca60, > shader=0x7fffc80adc60, debug=0x7fffc80adc68) at > ../../../../../src/gallium/drivers/radeonsi/si_shader.c:8114 > #9 0x769e21b0 in si_build_shader_variant (shader=0x7fffc80adc60, > thread_index=, low_priority=) at > ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1510 > #10 0x769e4fdc in si_shader_select_with_key (thread_index=-1, > key=0x7fffe9fbe2ae, compiler_state=0x7fffe9fbe420, state=0x100063fb0, > sscreen=0x100104f00) at > ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1772 > #11 si_shader_select (ctx=0x100063350, state=0x100063fb0, > compiler_state=0x7fffe9fbe420) at > ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1790 > #12 0x769e5c28 in si_update_shaders (sctx=0x100063350) at > ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:3242 > #13 0x769de2a0 in si_draw_vbo (ctx=0x100063350, info=0x1000adf48) at > ../../../../../src/gallium/drivers/radeonsi/si_state_draw.c:1331 > #14 0x766913e8 in tc_call_draw_vbo (pipe=, > payload=) at > ../../../../src/gallium/auxiliary/util/u_threaded_context.c:2012 > #15 0x7668ae04 in tc_batch_execute (job=0x1000adc50, > thread_index=) at > ../../../../src/gallium/auxiliary/util/u_threaded_context.c:96 > #16 0x76488be8 in util_queue_thread_func (input=) at > ../../../src/util/u_queue.c:271 > #17 0x76488690 in impl_thrd_routine (p=) at > ../../../include/c11/threads_posix.h:87 > #18 0x773e86d8 in start_thread (arg=0x0) at pthread_create.c:463 > #19 0x77963f48 in clone () at > ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:82 > > Thread 8 (Thread 0x7fffea7cf160 (LWP 4796)): > #0 0x773f1a0c in futex_wait_cancelable (private=, > expected=0, futex_word=0x200) at > ../sysdeps/unix/sysv/linux/futex-internal.h:88 > #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x1001055c8, > cond=0x1001055f0) at pthread_cond_wait.c:502 > #2 __pthread_cond_wait (cond=0x1001055f0, mutex=0x1001055c8) at > pthread_cond_wait.c:655 > #3 0x77977b14 in __pthread_cond_wait (cond=, > mutex=) at forward.c:149 > #4 0x76488b3c in cnd_wait (mtx=0x1001055c8, cond=0x1001055f0) at > ../../../include/c11/threads_posix.h:155 > #5 util_queue_thread_func (input=) at > ../../../src/util/u_queue.c:255 > #6 0x76488690 in impl_thrd_routine (p=) at > ../../../include/c11/threads_posix.h:87 > #7 0x773e86d8 in start_thread (arg=0x0) at pthread_create.c:463 > #8 0x77963f48 in clone () at > ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:82 > > Thread 7 (Thread 0x7fffeafdf160 (LWP 4795)): > #0 0x773f1a0c in futex_wait_cancelable (private=, > expected=0, futex_word=0x200) at > ../sysdeps/unix/sysv/linux/futex-internal.h:88 > #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x1001055c8, > cond=0x1001055f0) at pthread_cond_wait.c:502 > #2 __pthread_cond_wait (cond=0x1001055f0, mutex=0x1001055c8) at > pthread_cond_wait.c:655 > #3 0x77977b14 in __pthread_cond_wait (cond=, > mutex=) at forward.c:149 > #4 0x76488b3c in cnd_wait (mtx=0x1001055c8, cond=0x1001055f0) at > ../../../include/c11/threads_posix.h:155 > #5
Bug#902246: alien-arena crashes with SIGSEGV on ppc64el with amdgpu graphics
Package: alien-arena Version: 7.66+dfsg-5 When alien-arena loads a map, right before the gameplay starts, we get a SIGSEGV and the game quits: > Thread 1 "alienarena" received signal SIGSEGV, Segmentation fault. > 0x71ba5ec4 in llvm::Value::getContext() const () from > /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1 > (gdb) bt > #0 0x71ba5ec4 in llvm::Value::getContext() const () from > /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1 > #1 0x71ba7db8 in llvm::Value::setNameImpl(llvm::Twine const&) () > from /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1 > #2 0x71ba8140 in llvm::Value::setName(llvm::Twine const&) () from > /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1 > #3 0x71b27b60 in > llvm::ExtractValueInst::init(llvm::ArrayRef, llvm::Twine > const&) () from /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1 > #4 0x71aae6f0 in LLVMBuildExtractValue () from > /usr/lib/powerpc64le-linux-gnu/libLLVM-6.0.so.1 > #5 0x75a7b2e4 in si_build_ps_prolog_function (ctx=0x7fffa120, > key=0x7fffe3f2) at > ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7722 > #6 0x75a7f8c8 in si_get_shader_part (sscreen=0x10b67dbc0, > list=0x10b67e108, type=PIPE_SHADER_FRAGMENT, prolog=true, key=0x7fffe3f2, > tm=0x10b635f80, debug=0x10c7050a8, build=0x75a7ab40 > , > name=0x75c78420 "Fragment Shader Prolog") at > ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7154 > #7 0x75a825c0 in si_shader_select_ps_parts (debug=0x10c7050a8, > shader=0x10c7050a0, tm=0x10b635f80, sscreen=0x10b67dbc0) at > ../../../../../src/gallium/drivers/radeonsi/si_shader.c:7924 > #8 si_shader_create (sscreen=0x10b67dbc0, tm=0x10b635f80, > shader=0x10c7050a0, debug=0x10c7050a8) at > ../../../../../src/gallium/drivers/radeonsi/si_shader.c:8114 > #9 0x75aa21b0 in si_build_shader_variant (shader=0x10c7050a0, > thread_index=, low_priority=) at > ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1510 > #10 0x75aa4fdc in si_shader_select_with_key (thread_index=-1, > key=0x7fffe54e, compiler_state=0x7fffe6c0, state=0x10b5ed490, > sscreen=0x10b67dbc0) at > ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1772 > #11 si_shader_select (ctx=0x10b5ec830, state=0x10b5ed490, > compiler_state=0x7fffe6c0) at > ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:1790 > #12 0x75aa5c28 in si_update_shaders (sctx=0x10b5ec830) at > ../../../../../src/gallium/drivers/radeonsi/si_state_shaders.c:3242 > #13 0x75a9e2a0 in si_draw_vbo (ctx=0x10b5ec830, info=0x10b6372e8) at > ../../../../../src/gallium/drivers/radeonsi/si_state_draw.c:1331 > #14 0x757513e8 in tc_call_draw_vbo (pipe=, > payload=) at > ../../../../src/gallium/auxiliary/util/u_threaded_context.c:2012 > #15 0x7574e134 in tc_batch_execute (thread_index=0, job= out>) at ../../../../src/gallium/auxiliary/util/u_threaded_context.c:96 > #16 _tc_sync (tc=0x10b636bd0, func=, info=) at > ../../../../src/gallium/auxiliary/util/u_threaded_context.c:207 > #17 0x75752468 in tc_texture_subdata (_pipe=0x10b636bd0, > resource=0x10c704890, level=, usage=, > box=0x7fffea50, data=0x10ca68650, stride=, > layer_stride=) > at ../../../../src/gallium/auxiliary/util/u_threaded_context.c:1717 > #18 0x75423a30 in st_TexSubImage (ctx=0x10b75ef60, dims=2, > texImage=0x10c70d300, xoffset=0, yoffset=, zoffset= out>, width=, height=, depth=, > format=, type=, pixels=, > unpack=) at > ../../../src/mesa/state_tracker/st_cb_texture.c:1434 > #19 0x75425d14 in st_TexImage (ctx=0x10b75ef60, dims=, > texImage=0x10c70d300, format=, type=, > pixels=0x10ca68650, unpack=0x10b7684e8) > at ../../../src/mesa/state_tracker/st_cb_texture.c:1651 > #20 0x75386f40 in teximage (no_error=false, pixels=0x10ca68650, > imageSize=0, type=5121, format=6408, border=0, depth=, > height=, width=, internalFormat=4, level=0, > target=3553, > dims=2, compressed=0 '\000', ctx=0x10b75ef60) at > ../../../src/mesa/main/teximage.c:3101 > #21 teximage_err (ctx=0x10b75ef60, compressed=0 '\000', dims=2, > target=, level=, internalFormat= out>, width=, height=, depth=1, border=0, > format=6408, type=5121, > imageSize=0, pixels=0x10ca68650) at ../../../src/mesa/main/teximage.c:3128 > #22 0x75388e9c in _mesa_TexImage2D (target=, > level=, internalFormat=, width=, > height=, border=, format=, > type=, pixels=0x10ca68650) at > ../../../src/mesa/main/teximage.c:3166 > #23 0x0001000970b4 in ?? () > #24 0x000100097a9c in ?? () > #25 0x0001000987fc in ?? () > #26 0x0001000cbeec in ?? () > #27 0x0001000a4a5c in ?? () > #28 0x0001000a6624 in ?? () > #29 0x0001000a6998 in ?? () > #30 0x00010004a564 in ?? () > #31 0x000100043014 in ?? () > #32 0x000100036678 in ?? () > #33 0x000100083b50 in ?? () > #34 0x000100012778 in ?? () > #35
Bug#881655: "uname -p" returns "unknown" on ppc64el
Package: coreutils Version: 8.26-3 "uname -p" returns "unknown" on ppc64el. It should return a valid string, such as ppc64le.
Bug#881593: AMDGPU module not built for ppc64el
Package: linux-image-powerpc64le Version: For an unknown (historical?) reason, the AMDGPU kernel module is not built on ppcl64el systems. I have rebuilt the kernel and verified that it does work on POWER9 with Linux 4.14 and an AMD Vega 64 card, so the module build should be enabled for Debian. Without this module there is no way to get video out of the Vega cards on OpenPOWER machines. I have attached a patch for the kernel configuration file that enables the AMDGPU module.--- .config +++ .config @@ -658,7 +658,10 @@ # CONFIG_PM_TEST_SUSPEND is not set CONFIG_PM_SLEEP_DEBUG=y CONFIG_PM_OPP=y +CONFIG_PM_GENERIC_DOMAINS=y # CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set +CONFIG_PM_GENERIC_DOMAINS_SLEEP=y +CONFIG_PM_GENERIC_DOMAINS_OF=y CONFIG_SECCOMP=y CONFIG_ISA_DMA_API=y @@ -4507,11 +4510,16 @@ # CONFIG_DRM_I2C_NXP_TDA998X is not set CONFIG_DRM_RADEON=m # CONFIG_DRM_RADEON_USERPTR is not set -# CONFIG_DRM_AMDGPU is not set +CONFIG_DRM_AMDGPU=m +CONFIG_DRM_AMDGPU_SI=y +CONFIG_DRM_AMDGPU_CIK=y +# CONFIG_DRM_AMDGPU_USERPTR is not set +# CONFIG_DRM_AMDGPU_GART_DEBUGFS is not set # # ACP (Audio CoProcessor) Configuration # +CONFIG_DRM_AMD_ACP=y CONFIG_DRM_NOUVEAU=m CONFIG_NOUVEAU_DEBUG=5 CONFIG_NOUVEAU_DEBUG_DEFAULT=3
Bug#838605: Enable PowerNV MTD modules on POWER systems
Package: linux-image-4.6.0-1-powerpc64le Version: 4.6.4-1 Severity: important The PowerNV MTD module is required for checkstop diagnostics on POWER8 and higher machines, but it is not enabled in the kernel build. Please enable it as a module with the following kernel .config lines: CONFIG_MTD=m CONFIG_MTD_POWERNV_FLASH=m Thanks!
Bug#838604: Enable opal-prd module on POWER systems
Package: linux-image-4.6.0-1-powerpc64le Version: 4.6.4-1 Severity: important The opal-prd module is required for checkstop diagnostics on POWER8 and higher machines, but it is not enabled in the kernel build. Please enable it as a module with the following kernel .config line: CONFIG_OPAL_PRD=m Thanks!
Bug#838588: Out of date
Package: libpam-pkcs11 Version: 0.6.8-4 Severity: important This package is out of date by at least a year; since the last udate there have been numerous fixes that allow this module to integrate properly into modern card based environments. Please update this package to the latest upstream GIT head. Thank you,
Bug#836881: Mea culpa
Good catch! The version was wrong, and in fact was pulled four days before my commit that fixed this bug last year. Apologies for the noise, I had no idea the version in Stretch was that old.
Bug#836881: X509 card-based logins fail with SIGSEGV
Package: libhx509-5-heimdal Version: 1.7~git20160703+dfsg-1 Severity: grave Heimdal's X509 PAM authentication plugin crashes with the following backtrace when attempting to use a cryptographic card to log in: Program received signal SIGSEGV, Segmentation fault. 0x7f5c0f30e38d in _hx509_match_keys (c=0x18e2ed0, key=0x18e0960) at crypto.c:3018 3018crypto.c: No such file or directory. (gdb) bt #0 0x7f5c0f30e38d in _hx509_match_keys (c=0x18e2ed0, key=0x18e0960) at crypto.c:3018 #1 0x7f5c0f30b17b in match_keys (value=0x18e0500, certs=0x18e1620, context=0x18a0430) at collector.c:232 #2 _hx509_collector_collect_certs (context=context@entry=0x18a0430, c=0x18e0b30, ret_certs=ret_certs@entry=0x18e0438) at collector.c:275 #3 0x7f5c0f315669 in p11_list_keys (certs=0x18e0438, lock=, session=26085952, slot=0x18e0410, p=0x18a3740, context=0x18a0430) at ks_p11.c:804 #4 p11_init_slot (context=context@entry=0x18a0430, p=p@entry=0x18a3740, lock=lock@entry=0x18a36a0, id=, num=, slot=0x18e0410) at ks_p11.c:363 #5 0x7f5c0f315963 in p11_init (context=0x18a0430, certs=, data=0x1889f70, flags=, residue=, lock=0x18a36a0) at ks_p11.c:933 #6 0x7f5c0f311b10 in hx509_certs_init (context=0x18a0430, name=name@entry=0x1867910 "PKCS11:/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so", flags=flags@entry=0, lock=0x18a36a0, certs=certs@entry=0x18a3668) at keyset.c:159 #7 0x7f5c0fc72f0f in _krb5_pk_load_id (context=context@entry=0x18a0240, ret_id=0x18a3580, user_id=user_id@entry=0x1867910 "PKCS11:/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so", anchor_id=anchor_id@entry=0x18a3440 "FILE:/etc/trinity/ldap/tde-ca/public/odin.starlink.edu.ldap.crt", chain_list=0x0, revoke_list=0x1889ba0, prompter=0x7f5c0feb30d0, prompter_data=0x1867740, password=0x0) at pkinit.c:1882 #8 0x7f5c0fc74b07 in krb5_get_init_creds_opt_set_pkinit (context=0x18a0240, opt=0x1867810, principal=0x1867880, user_id=0x1867910 "PKCS11:/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so", x509_anchors=0x18a3440 "FILE:/etc/trinity/ldap/tde-ca/public/odin.starlink.edu.ldap.crt", pool=, pki_revoke=, flags=0, prompter=0x7f5c0feb30d0, prompter_data=0x1867740, password=0x0) at pkinit.c:2394 #9 0x7f5c0feb0e49 in ?? () from /lib/x86_64-linux-gnu/security/pam_krb5.so #10 0x7f5c0feb175b in ?? () from /lib/x86_64-linux-gnu/security/pam_krb5.so #11 0x7f5c0feb36b7 in pam_sm_authenticate () from /lib/x86_64-linux-gnu/security/pam_krb5.so #12 0x7f5c123c80a6 in ?? () from /lib/x86_64-linux-gnu/libpam.so.0 #13 0x7f5c123c781d in pam_authenticate () from /lib/x86_64-linux-gnu/libpam.so.0 #14 0x004031b3 in ?? () #15 0x7f5c11c18700 in __libc_start_main (main=0x402a90, argc=3, argv=0x7ffd37fe93f8, init=, fini=, rtld_fini=, stack_end=0x7ffd37fe93e8) at ../csu/libc-start.c:291 #16 0x00404200 in ?? ()
Bug#409271: Workaround
For now, since klibc does not have NFSV4 support, the attached file works around the problem (place in /usr/share/initramfs-tools/hooks/nfsv4). nfsv4 Description: Binary data
Bug#409271: Status?
What is the status of this bug report? NFSv3 is becoming obsolete, and this bug report is over *9 years* old now!
Bug#810913: mesa: Enable OpenCL on ppc64el
> As I understand your first mail in this report, this requires a fix > somewhere first? (I wouldn't want to apply a "temporary" patch in > Debian.) Unfortunately it doesn't look like upstream is going to patch their code. There is a protracted "blame game" going on between mesa and gcc: https://bugs.freedesktop.org/show_bug.cgi?id=93687 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58241 Master Khronos bug report (unfortunately largely ignored): https://www.khronos.org/bugzilla/show_bug.cgi?id=1449 I suspect this won't be dealt with unless downstream distributions patch the codebase themselves. Thanks!
Bug#810913: Progress?
Is there any chance this bug report could be handled soon? We keep having to recompile mesa to enable OpenCL for our POWER machines. Thanks!
Bug#832072: handbrake not build for ppc64el
> On 2016-07-21 19:46:17, Timothy Pearson wrote: > Would it be also possible to simple switch powerpc to any-powerpc? I see no obvious reason for that not to work. I only have access to POWER8+ machines for testing, however AFAIK the AltiVec parts of the codebase should function correctly on all non-embedded PPC CPUs.
Bug#832072: handbrake not build for ppc64el
Package: handbrake Version: 0.10.5+ds1-2 Severity: important Handbrake should be built for ppc64el. It has been tested on POWER8 and works fine. The only required change is to add ppc64el to the debian/control file.
Bug#828711: nvidia-texture-tools not available on ppc64el
Package: nvidia-texture-tools Version: 2.0.8-1+dfsg-8 Tags: patch nvidia-texture-tools is not built for ppc64el due to a failure to build from source on that platform. This patch fixes the build failure: https://github.com/castano/nvidia-texture-tools/pull/238 Please apply the patch to the Debian sources and enable ppc64el builds of nvidia-texture-tools and associated binary packages. Thanks!
Bug#826367:
Apologies; one of the options given above was incorrect. The following options need to be set on ppc64el to enable PCI VFIO functionality: CONFIG_SPAPR_TCE_IOMMU=y CONFIG_VFIO=m CONFIG_VFIO_PCI=m
Bug#826367: Enable VFIO PCI passthrough on ppc64le
Package: linux-image-4.5.0-2-powerpc64le Version: 4.5.5-1 Severity: important VFIO PCI passthrough is not available on POWER8 systems due to several missing kernel configuration options. PCI passthrough is an important feature of POWER8 machines, works well under at least Linux 4.5, and should be available in the Debian stock kernels as a module. The following options need to be set on ppc64el to enable this functionality: CONFIG_SPAPR_TCE_IOMMU=y CONFIG_VIRTIO=m CONFIG_VFIO_PCI=m As ppc64el does not support any systems below POWER8 it should be safe to set these options for all ppc64el kernels.
Bug#817063: Severe performance regression in Infiniband or IPoIB
-BEGIN PGP SIGNED MESSAGE- Hash: SHA224 Package: linux-image-4.3.0-1-powerpc64le Version: 4.3.5-1 When upgrading to the latest 4.3 testing kernel on a Mellanox MT25208 controller, all IPoIB links showed a severe performance regression as compared with kernel 3.16. The bandwidth of each link dropped from around 3Gbps to around 3Mbps (3 orders of magnitude worse!); reverting to the 3.16 kernel immediately fixed this problem. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iFYEARELAAYFAlbdyVkACgkQLaxZSoRZrGEfeADgrTgu8+cP87QUzG3dlt7WzFE1 sZqh6KD/6fBW/wDgreyn3o9yKw5Dd61zf1ehZc7GjzvCJyL7NnDMEQ== =h8Kk -END PGP SIGNATURE-
Bug#814827:
A similar crash also occurs when outputs are hotplugged. Revised patch attached. Note that at least on my test machine with an HDMI display attached Xorg starts but the display remains disabled. It is currently unknown whether this is a general bug in the radeon driver or something pcc64el specific.--- xorg-server-1.18.0/randr/randr.c 2015-11-06 08:07:41.0 -0600 +++ xorg-server-1.18.0/randr/randr.c 2016-02-15 12:49:06.469645421 -0600 @@ -559,6 +559,9 @@ mastersp = pScrPriv; } +if (!mastersp) +return; + mastersp->changed = TRUE; } --- xorg-server-1.18.0/randr/rroutput.c 2015-11-09 14:28:04.0 -0600 +++ xorg-server-1.18.0/randr/rroutput.c 2016-02-15 13:41:52.190584324 -0600 @@ -50,6 +50,10 @@ } RRSetChanged(pScreen); + +if (!mastersp) +return; + if (configChanged) mastersp->configChanged = TRUE; }
Bug#814827:
The attached patch fixes the crash and Xorg appears to start normally.--- xorg-server-1.18.0/randr/randr.c 2015-11-06 08:07:41.0 -0600 +++ xorg-server-1.18.0/randr/randr.c 2016-02-15 12:49:06.469645421 -0600 @@ -559,6 +559,9 @@ mastersp = pScrPriv; } +if (!mastersp) +return; + mastersp->changed = TRUE; }
Bug#814827: X crashes on start on POWER8/radeon machine
Package: xserver-xorg-core Version: 2:1.18.0-3 On a POWER8 machine under both Debian Jessie and Debian Stretch Xorg crashes on startup when using the radeon driver and a Radeon R9 290X. Kernel modesetting outside of X appears to function normally. crash: Program received signal SIGSEGV, Segmentation fault. 0x201676c8 in RRSetChanged (pScreen=0x202e6800) at ../../randr/randr.c:562 562 ../../randr/randr.c: No such file or directory. (gdb) bt #0 0x201676c8 in RRSetChanged (pScreen=0x202e6800) at ../../randr/randr.c:562 #1 0x2016ceec in RRScreenSetSizeRange (pScreen=, minWidth=, minHeight=, maxWidth=, maxHeight=) at ../../randr/rrinfo.c:228 #2 0x2010e894 in xf86RandR12CreateScreenResources12 (pScreen=0x202e6800) at ../../../../hw/xfree86/modes/xf86RandR12.c:1637 #3 xf86RandR12CreateScreenResources (pScreen=0x202e6800) at ../../../../hw/xfree86/modes/xf86RandR12.c:833 #4 0x200fd8fc in xf86CrtcCreateScreenResources (screen=0x202e6800) at ../../../../hw/xfree86/modes/xf86Crtc.c:713 #5 0x20061338 in dix_main (argc=, argv=0x3ca8, envp=) at ../../dix/main.c:215 #6 0x200445d8 in main (argc=, argv=, envp=) at ../../dix/stubmain.c:34 (gdb) dmesg log: [ 15.063739] [drm] radeon kernel modesetting enabled. [ 15.078968] sd 6:0:0:0: Attached scsi generic sg0 type 0 [ 15.079056] sr 7:0:0:0: Attached scsi generic sg1 type 5 [ 15.079114] sr 7:0:0:1: Attached scsi generic sg2 type 5 [ 15.079192] sr 7:0:0:2: Attached scsi generic sg3 type 5 [ 15.079270] sr 7:0:0:3: Attached scsi generic sg4 type 5 [ 15.079327] sd 8:0:0:0: Attached scsi generic sg5 type 0 [ 15.079402] sd 8:0:0:1: Attached scsi generic sg6 type 0 [ 15.079475] sd 8:0:0:2: Attached scsi generic sg7 type 0 [ 15.079527] sd 8:0:0:3: Attached scsi generic sg8 type 0 [ 15.079599] sd 9:0:0:0: Attached scsi generic sg9 type 0 [ 15.079673] sd 9:0:0:1: Attached scsi generic sg10 type 0 [ 15.079724] sd 9:0:0:2: Attached scsi generic sg11 type 0 [ 15.079795] sd 9:0:0:3: Attached scsi generic sg12 type 0 [ 15.079868] sd 9:0:0:4: Attached scsi generic sg13 type 0 [ 15.418010] [drm] initializing kernel modesetting (HAWAII 0x1002:0x67B0 0x1002:0x0B00). [ 15.418023] radeon :01:00.0: Using 32-bit DMA via iommu [ 15.418027] [drm] register mmio base: 0x [ 15.418029] [drm] register mmio size: 262144 [ 15.418035] [drm] doorbell mmio base: 0x1000 [ 15.418037] [drm] doorbell mmio size: 8388608 [ 15.418068] [drm:radeon_device_init [radeon]] *ERROR* Unable to find PCI I/O BAR [ 15.588562] [drm:radeon_atombios_init [radeon]] *ERROR* Unable to find PCI I/O BAR; using MMIO for ATOM IIO [ 15.588810] ATOM BIOS: C67101 [ 15.59] radeon :01:00.0: VRAM: 4096M 0x - 0x (4096M used) [ 15.588893] radeon :01:00.0: GTT: 2048M 0x0001 - 0x00017FFF [ 15.588895] [drm] Detected VRAM RAM=4096M, BAR=256M [ 15.588897] [drm] RAM width 512bits DDR [ 15.588964] [TTM] Zone kernel: Available graphics memory: 66909920 kiB [ 15.588966] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 15.588967] [TTM] Initializing pool allocator [ 15.589006] [drm] radeon: 4096M of VRAM memory ready [ 15.589008] [drm] radeon: 2048M of GTT memory ready. [ 15.589023] [drm] Loading hawaii Microcode [ 15.637786] radeon :01:00.0: firmware: direct-loading firmware radeon/hawaii_pfp.bin [ 15.654034] radeon :01:00.0: firmware: direct-loading firmware radeon/hawaii_me.bin [ 15.802419] radeon :01:00.0: firmware: direct-loading firmware radeon/hawaii_ce.bin [ 15.849419] radeon :01:00.0: firmware: direct-loading firmware radeon/hawaii_mec.bin [ 15.855296] radeon :01:00.0: firmware: direct-loading firmware radeon/hawaii_rlc.bin [ 15.933110] Adding 79000512k swap on /dev/sda3. Priority:-1 extents:1 across:79000512k FS [ 16.010924] radeon :01:00.0: firmware: direct-loading firmware radeon/hawaii_sdma.bin [ 16.024299] radeon :01:00.0: firmware: direct-loading firmware radeon/hawaii_mc.bin [ 16.046812] radeon :01:00.0: firmware: direct-loading firmware radeon/hawaii_smc.bin [ 16.046819] [drm] Internal thermal controller with fan control [ 16.046884] [drm] probing gen 2 caps for device 1014:3dc = 33f503/e [ 16.074582] [drm] radeon: dpm initialized [ 16.252838] radeon :01:00.0: firmware: direct-loading firmware radeon/BONAIRE_uvd.bin [ 16.285442] radeon :01:00.0: firmware: direct-loading firmware radeon/BONAIRE_vce.bin [ 16.286876] [drm] Found VCE firmware/feedback version 40.2.2 / 15! [ 16.286893] [drm] GART: num cpu pages 32768, num gpu pages 524288 [ 16.288330] [drm] probing gen 2 caps for device 1014:3dc = 33f503/e [ 16.288334] [drm] PCIE gen 3 link speeds already enabled [ 16.357665] [drm] PCIE GART of 2048M enabled (table at 0x0033). [ 16.357811] radeon :01:00.0: WB enabled [ 16.357826] radeon :01:00.0: fence
Bug#813640: Enable VMX crypto extensions module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA224 Package: linux-image-4.3.0-1-powerpc64 Version: 4.3.3-7 Severity: normal The POWER8 processors use VMX to accelerate cryptographic functions. Linux supports the use of VMX for cryptographic acceleration, however Debian does not build this module, leaving users of some systems (e.g. OpenPOWER) unable to reach rated bandwidths e.g. in OpenSSL. Please enable the VMX cryptographic extensions module with CONFIG_CRYPTO_DEV_VMX=m in the kernel configuration. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iFYEARELAAYFAlayfr0ACgkQLaxZSoRZrGG7jgDeJP6HVdTmuRbnBrMdM9JKxLFS V0e4BLuRB2qp8gDdHQ2pcqsHPF1uxHHMag5N7c8GZgGv0N0a5vEgYQ== =epAE -END PGP SIGNATURE-
Bug#810936: mesa: Add osmesa debug package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA224 > On Wed, Jan 13, 2016 at 16:27:02 -0600, Timothy Pearson wrote: > >> Package: mesa >> Version: 11.0.8-1 >> Severity: normal >> Tags: +patch >> >> The mesa package currently relies on an autogenerated debug symbol package >> for osmesa. The attached patch switches this to a control file-defined debug symbol package. > > Why? This seems backwards. > > Cheers, > Julien > I thought each package was supposed to have a debug package defined, and that the -dbgsym packages were more of a stopgap? If the -dbgsym packages are the way Debian is going there's a fair amount of build infrastructure that may need to be fixed; there were already reports in the Debian bugtracker of certain package publishing programs failing due to the unexpected -dbgsym package (this actually is what alerted me to the problem in the first place). Can you point me to something showing which way the debug symbols are supposed to be published, and why that decision was made? Thanks! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iFYEARELAAYFAlaasTQACgkQLaxZSoRZrGH5zADcCpjR4w9y8RIN9gL9eC6+mMAm 1ObPhLBGeZeM5QDfaSx5ifZHhjBGWXciAH2W8xKtQCHgxgnsSA/Oog== =RCHM -END PGP SIGNATURE-
Bug#649037:
-BEGIN PGP SIGNED MESSAGE- Hash: SHA224 I'm still seeing this issue with Debian Jessie on POWER8 hardware, trying to boot the FreeBSD 10.2 ISO image. The error is almost identical, with a slight change to the kernel address: Booting [/boot/kernel/kernel]... Kernel entry at 0x101f00 ... Not sure if this is a FreeBSD problem or a qemu/OpenBIOS problem? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iFYEARELAAYFAlaX8j0ACgkQLaxZSoRZrGHrOQDdFMxQeIEE7cJ0BWPHdP0tAArE kdhxb/NTBSk5KADfQrWK1YdpWnu5pcqgkY4RHhOLapxb5v/Nq1vrzA== =c5JX -END PGP SIGNATURE-
Bug#810936: mesa: Add osmesa debug package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA224 Package: mesa Version: 11.0.8-1 Severity: normal Tags: +patch The mesa package currently relies on an autogenerated debug symbol package for osmesa. The attached patch switches this to a control file-defined debug symbol package. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iFYEARELAAYFAlaWzzYACgkQLaxZSoRZrGHWIADdHPGjnQ7ZtgFDdvpNABa0+VO0 zi0kVwY205UfiwDeJReg2n57YcSuVpvLnRFARNmhTvNkDcE57TEFYg== =ghYh -END PGP SIGNATURE- mesa-add-osmesa-debug-package.diff Description: Binary data mesa-add-osmesa-debug-package.diff.sig.asc Description: PGP signature
Bug#810913: mesa: Enable OpenCL on ppc64el
-BEGIN PGP SIGNED MESSAGE- Hash: SHA224 Package: mesa Version: 11.0.8-1 Severity: important OpenCL was disabled on ppc64el due to an altivec-related build failure. The attached patch fixes the build failure and reenable OpenCL on ppc64el. Note that an upstream bug report was filed here: https://bugs.freedesktop.org/show_bug.cgi?id=93687 It is currently unknown who is actually responsible for the final fix, however the temporary patch works for now. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iFYEARELAAYFAlaWfxUACgkQLaxZSoRZrGEvTADgz2PQYHQobpIpV5ZgNy6Ttr+I byG+M36+/bGZ6wDgt1+Eprs5mn2dbiJwek/yjV83xHNdcVKS0Yybng== =Kpk1 -END PGP SIGNATURE- fix-opencl-build-ppc64el.diff Description: Binary data fix-opencl-build-ppc64el.diff.sig.asc Description: PGP signature
Bug#808246: binutils bug report
I went ahead and filed a bug report upstream at: https://sourceware.org/bugzilla/show_bug.cgi?id=19421 Hopefully this helps prod some action on this serious bug... P,S. I completely agree with the previous commenter; this bug is unreal. This is 2015, not 1998...core libraries breaking modern platforms like this is just not acceptable.
Bug#808338: Enable ASpeed VGA module
Package: linux-image-4.2.0-1-powerpc64le Version: 4.2.6-3 Severity: normal Many server- and workstation-class boards use the ASpeed Technologies BMC device as the primary VGA output. Linux supports initialization of this device via the AST DRM module, however Debian does not build this module, leaving users of some systems (e.g. OpenPOWER) without a working VGA output. Please enable the AST DRM module with CONFIG_DRM_AST=m in the kernel configuration.
Bug#808246: Stretch fails to install on OpenPOWER systems
Package: linux-image-4.2.0-1-powerpc64le Version: 4.2.6-3 Severity: grave Using the latest debian-installer netboot kernel to install on an OpenPOWER server; install proceeds normally until disk detection when it fails stating no disks can be found. dmesg shows a slew of errors similar to the following: fat: no symbol version for TOC. fat: Unknown symbol TOC. (err -22) ext4: no symbol version for TOC. ext4: Unknown symbol TOC. (err -22) ahci: no symbol version for TOC. ahci: Unknown symbol TOC. (err -22) Forcibly loading the modules (modprobe --force ext4, etc.) and resuming the installer allows the system to install normally, however the same issue shows up on reboot. This causes a boot failure that cannot be overridden as the modprobe version in the initramfs does not support the force parameter. Jessie installs normally on the same system.
Bug#715498: Additional patch
An additional patch is required to correct a second crash when using syncrepl and slapi plugins. This crash has been reported in upstream ITS#7641 (http://www.openldap.org/its/index.cgi/Incoming?id=7641;selectid=7641); the requisite patch is available in that report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715498: Updated patch
Upstream has generated a corrected patch that has been verified as working. This patch should be applied to the Debian OpenLDAP package instead. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715499: OpenLDAP crashes when syncrepl enabled and plugins in use
Package: openldap Version: 2.4.31-1+nmu2 OpenLDAP crashes when syncrepl has been enabled and plugins are in use. Full details (along with a patch to fix this problem) are available in upstream Bug 7636 (http://www.openldap.org/its/index.cgi/Incoming?id=7636). The patch in that report is applicable to the current version of OpenLDAP in Debian, therefore it should be included in the Debian OpenLDAP packages. Furthermore, as this problem causes an almost immediate crash with a valid OpenLDAP configuration, this fix should be considered for inclusion in Wheezy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715498: OpenLDAP crashes when syncrepl enabled and plugins in use
Package: slapd Version: 2.4.31-1+nmu2 OpenLDAP crashes when syncrepl has been enabled and plugins are in use. Full details (along with a patch to fix this problem) are available in upstream Bug 7636 (http://www.openldap.org/its/index.cgi/Incoming?id=7636). The patch in that report is applicable to the current version of OpenLDAP in Debian, therefore it should be included in the Debian OpenLDAP packages. Furthermore, as this problem causes an almost immediate crash with a valid OpenLDAP configuration, this fix should be considered for inclusion in Wheezy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703424: Regression: CUPS Web interface fails to authenticate Kerberos access to IPP information
Control: tags -moreinfo +fixed Initial tests of cups 1.6.2 indicate that this bug is fixed, and that Kerberos authentication now works properly. I will reopen this report if any glitches are noted during testing over the next few weeks. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703424: Regression: CUPS Web interface fails to authenticate Kerberos access to IPP information
Control: tags -1 +moreinfo Hi Timothy, and thanks for your bugreport, Can you confirm that this still applies to CUPS 1.6.2 (as uploaded to unstable)? Thanks in advance, cheers, OdyX I will see what I can do in the next couple of weeks. The machine in question is slated for deployment to production, so I will probably need to test on a clone (thus the delay). Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703424: Regression: CUPS Web interface fails to authenticate Kerberos access to IPP information
Package: cups Version: 1.5.3-2.16 When using the Web interface to CUPS in a Kerberized environment, CUPS fails to pass Kerberos authentication information to the local IPP socket. This manifests as access being denied to any pages which access printer information, even though the user logged in via Kerberos has been granted access to both the pages and printers in question. The CUPS error log shows that it has rejected unauthenticated access to the printers in question, even though the prior access to the Web printer list page was successfully authenticated. This appears to be a regression introduced when resolving Bug 640939, specifically this patch removes the ability for CUPS to pass Kerberos login credentials to the local IPP socket: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=105;filename=cups-1.5.3-2.14-nmu.diff;att=1;bug=640939 Unfortunately, simply reverting that patch introduces another problem, specifically an inability to access any administrative pages and this line appearing in the error log: [CGI] cgi_passwd(prompt=Password for lp on localhost? ) called! Therefore, it would seem that a more selective approach to passing the Kerberos credentials to the local IPP socket is in order. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688002: Patch
The attached patch resolves the issue.--- ruby1.9.1-1.9.3.194/debian/rules +++ ruby1.9.1-1.9.3.194/debian/rules @@ -206,7 +206,8 @@ dh_movefiles -p$(cdbs_curpkg) \ usr/lib/libruby-$(ruby_ver).so \ usr/lib/libruby-$(ruby_ver)-static.a \ - $(ruby_libdir)/mkmf.rb + $(ruby_libdir)/mkmf.rb \ + usr/lib/pkgconfig/ruby-1.9.pc (cd $(CURDIR)/debian/tmp \ find usr/include/ruby-$(ruby_ver) -name '*.h' -type f) | \ xargs dh_movefiles -p$(cdbs_curpkg)
Bug#688002: Ruby 1.9.x pkg-config file is not packaged
Package: ruby1.9.1-dev Version: 1.9.3.194-1 The ruby.pc (or ruby-1.9.pc, depending on exactly which Ruby sources you look at) pkg-config information file that comes as part of the upstream Ruby sources is not part of the ruby1.9.1-dev package. This makes it difficult for third party build systems to determine exactly where various Ruby files are located. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
