Bug#894187: autotools-dev: Update config.guess to recognize mips r6

tag 894187 + upstream thanks On Tue, 27 Mar 2018, YunQiang Su wrote: > We add some new architectures for mips, > > mipsisa{32,64}r6{el,}-unknown-linux-gnu{,abin32,abi64} > > These architectures are supported by config.sub, > while not supported by config.guess now. > > Please submit the

Bug#887856: intel-microcode: Spectre / Meltdown : bring intel-microcode 20180104 to stretch

On Wed, 14 Mar 2018, Moritz Muehlenhoff wrote: > On Sun, Jan 21, 2018 at 07:47:35AM -0200, Henrique de Moraes Holschuh wrote: > > severity 887856 grave > > block 887856 by 886998 > > thanks > > > > On Sat, 20 Jan 2018, Julien Aubin wrote: > > > As of n

Bug#891281: autotools-dev: Please update to new upstream version with x32 detection

On Sat, 24 Feb 2018, James Clarke wrote: > Hi, > Until today, config.guess (both upstream and in Debian) has lacked > support for detecting x32, instead just printing out the tuple for > amd64, x86_64-*-linux-gnu, and somehow this has gone unnoticed and not > caused much issue (with one exception

Bug#889709: Package update caused hard drive failure

tags 889709 + moreinfo thanks On Tue, 06 Feb 2018, Yevgeny Kosarzhevsky wrote: > I have updated system recently and intel-microcode was updated 3.20180108.1 > -> 3.20180108.1+really20171117.1 and it caused following issue with my hard > drive. ... > These messages were appearing every few

Bug#887856: intel-microcode: Spectre / Meltdown : bring intel-microcode 20180104 to stretch

severity 887856 grave block 887856 by 886998 thanks On Sat, 20 Jan 2018, Julien Aubin wrote: > As of now intel-microcode of stretch is still set to 20170707 (20171117 > through > bpo) which lets users vulnerable to Spectre attack CVE-2017-5715. Could you > please bring quickly the microcode

Bug#886998: regressions also possible on Skylake

Updated information from Intel: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088 ---8<--- Recommendations: Status Intel has made significant progress in our investigation into the customer reboot sightings that we confirmed publicly last week Intel has reproduced

Bug#886367: partial fix uploaded

On Mon, 15 Jan 2018, Andreas Heinlein wrote: > On Thu, 4 Jan 2018 23:18:49 -0200 Henrique de Moraes Holschuh wrote: > > Intel has released several updates already, but not all of them AFAIK. > > > > These microcode updates are of little impact until the kernel changes to >

Bug#886998: List of sigs for microcode with regressions

The VMWare KB52345 article at: https://kb.vmware.com/s/article/52345 Includes an _incomplete_ list of signatures for the microcode updates that are problematic in release 20180108: Processor name (non-exhaustive) signature stepping name Intel Xeon E3-1200-v3, Intel i3-4300, Intel

Bug#886445: needrestart: detect need to reboot due to Intel microcode updates

On Sat, 13 Jan 2018, Thomas Liske wrote: > wouldn't the microcode updates included into the initrd automaticly? I > don't find any config option in intel-microcode or initramfs-tools to > disable adding the microcode updates. I would expect that > intel-microcode is removed in such cases.

Bug#886445: needrestart: detect need to reboot due to Intel microcode updates

On Sat, 13 Jan 2018, Paul Wise wrote: > It should be enough, but it would be better to handle all cases IMO. > I have no idea if iucode-tool handles systems with multiple sockets, > so I am CCing Debian's Intel/AMD microcode maintainer. Current versions of iucode_tool will include microcode for

Bug#886445: needrestart: detect need to reboot due to Intel microcode updates

On Sat, 13 Jan 2018, Thomas Liske wrote: > # iucode_tool -Sl /lib/firmware/intel-ucode/ It would have to be: iucode_tool -Sl /lib/firmware/intel-ucode /usr/share/misc/intel-microcode* and that could still miss something. Maybe it would be best to look inside the initrds directly, too...

Bug#886998: if you downgrade, do it to the 20171117 release, NOT 20171215

On Fri, 12 Jan 2018, Henrique de Moraes Holschuh wrote: > Should you face issues with the new microcode (note: test it with an > older kernel as well, since the current crop of new kernels are *ALSO* > causing boot and resume-from-sleep issues that are completely unrelated > to t

Bug#886998: intel-microcode: regressions on Haswell, Broadwell (crashes/reboots) and Kaby Lake (sleep-to-ram)

Package: intel-microcode Version: 3.20180108.1 Severity: grave According to this: https://newsroom.intel.com/news/intel-security-issue-update-addressing-reboot-issues/ and this far more helpful information: https://pcsupport.lenovo.com/br/en/product_security/ps500151 A subset of systems with

Bug#886806: intel-microcode: New version 20180108 published

found 886806 intel-microcode/3.20140913.1 fixed 886806 intel-microcode/3.20180108.1 thanks On Wed, 10 Jan 2018, Karl Kornel wrote: > Well, it looks like there has been a release! The data file version is > 20180108. Due to timing, I missed this bug report when I readied the 3.20180108.1

Bug#886367: intel-microcode: coming updates for meltdown/spectre

On Mon, 08 Jan 2018, Christoph Anton Mitterer wrote: > Shouldn't that go to stable security updates as well? The current plans are for stable to wait for Intel's official microcode update pack. It is not like this set of microcode updates will get you anything without the kernel IBRS and IPBP

Bug#886424: intel-microcode: amd64-microcode and intel-microcode cannot be used together when both use INITRAMFS=early

tag 886424 moreinfo thanks On Fri, 05 Jan 2018, Benjamin Drung wrote: > we create an initrd for a live system that should be bootable on AMD and > Intel systems. Due to various CPU bugs, the microcode update for both > AMD and Intel should be included in the initrd. We do not want to manage > two

Bug#886382: Coming updates for meltdown/spectre

Hi Louis-Philippe! On Fri, 05 Jan 2018, Louis-Philippe Véronneau wrote: > > No, we don't know if they will release it *only* to vendors for a > > firmware update, or also for operating system updates. Also, for Zen > > and later one cannot just hope to update microcode through the operating > >

Bug#886368: intel-microcode: copyright URLs out of date

On Thu, 04 Jan 2018, Matt Taggart wrote: > The two upstream download URLs listed in the copyright file no longer work > (and are also http URLs). Searching I found the following > > https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File > > but I suspect that URL

Bug#886382: Coming updates for meltdown/spectre

On Fri, 05 Jan 2018, Louis-Philippe Véronneau wrote: > Package: amd64-microcode > Severity: grave > > It seems AMD cpus are also affected by the meltdown/spectre bugs. Yes, they are, although just by Spectre as far as we know (i.e. not affected by Meltdown). > Do you know if AMD plans to

Bug#886367: partial fix uploaded

Intel has released several updates already, but not all of them AFAIK. These microcode updates are of little impact until the kernel changes to activate the new MSRs are deployed. But they do mess with conditional jumps and LFENCE. Anyway, uploading a partial, unofficial set of updates to

Bug#883394: logs

Now attached for real... sorry about this. -- Henrique Holschuh Aptitude 0.8.7: log report Sun, Dec 3 2017 05:03:16 -0200 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 17 packages, and remove 0 packages. 13.3

Bug#883394: libc6: does not remove /etc/ld.so.nohwloc after all libc6-* packages are upgraded

Package: libc6 Version: 2.24-11+deb9u2 Severity: important This seems to be a regression in the stretch-proposed-updates release 2.24.11+deb9u2, at least I did not observe it when going jessie->stretch, or in the 2.24.11->2.24.11+deb9u1 update. And yes, I am sure the file was created by

Bug#878528: autotools-dev: Please deprecate the debhelper tools/sequence

On Sat, 14 Oct 2017, Niels Thykier wrote: > Package: autotools-dev > Version: 20161112.1 > Severity: wishlist > Tags: patch > > Hi, > > As discussed in [1], let us deprecate the debhelper tools/sequence > from autotools-dev and recommend dh_update_autotools_config as a > replacement. > > I have

Bug#875297: dracut: Support early loading microcode on Debian

On Sun, 10 Sep 2017, Philipp Kern wrote: > On 09/10/2017 02:32 PM, Philipp Kern wrote: > > 3) Add a patch to dracut.sh (/usr/bin/dracut) because intel-microcode > > uses the .initramfs suffix for the ucode files where it requests early > > loading. Given that hostonly is the default for dracut,

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

On Thu, 24 Aug 2017, Sean Whitton wrote: > Seconded, but I think the integrity protection is a more important > reason to avoid the git protocol or http, so if we can come up with a > further change to reflect that it would be better. Attacking the integrity of the messages in transit requires

Bug#872577: debootstrap: Handle existing /dev

On Fri, 18 Aug 2017, Dan Nicholson wrote: > When devices.tar.gz was being used, the devices would be written into > place with tar. This has the effect that the devices would be merged > into an existing /dev in the target. setup_devices_simple() does not > handle this case and fails when /dev

Bug#871053: cbios: new upstream release 0.28 fixes important issue

Package: cbios Version: 0.27-2 Severity: important New cbios upstream release 0.28 fixes an important issue, which caused several keyboard rows to not work properly. Most users affected would just switch to their non-free full MSX BIOSes, but that isn't a very optimal solution for Debian...

Bug#868983: trackballs: new upstream version available (new fork)

Package: trackballs Version: 1.1.4-4.3 Severity: important According to: http://trackballs.sourceforge.net/, there is a new, modernized fork of trackballs at: https://trackballs.github.io/. The new versions likely fix several of the current bugs, including the RC one that will result in this

Bug#868892: tasksel: Unexpected mass package removal with no way to cancel

gency=medium + + * Non-maintainer upload. + * Provide an exit path to tasksel, this partially fixes #868892 by using +the debconf "backup" capability to add an exit path to the multiselect +dialog. + + -- Henrique de Moraes Holschuh <h...@debian.org> Wed, 19 Jul 2017 12:57:07

Bug#863682: jessie-pu: package intel-microcode/3.20170511.1~deb8u1 [v2]: target jessie

On Sat, 15 Jul 2017, Adam D. Barratt wrote: > On Tue, 2017-06-20 at 14:58 -0300, Henrique de Moraes Holschuh wrote: > > Attached new debdiff and diffstat files (v2) with the following fixes: > > * target jessie > > Flagged for acceptance. Thank you! -- Henrique Holschuh

Bug#867989: stretch-pu: package intel-microcode/3.20170707.1~deb9u1

On Sat, 15 Jul 2017, Adam D. Barratt wrote: > On Thu, 2017-07-13 at 18:40 -0300, Henrique de Moraes Holschuh wrote: > > On Thu, 13 Jul 2017, Adam D. Barratt wrote: > > > Please go ahead. > > > > Uploaded, thank you very much! > > Flagged for acceptance. Thanks! -- Henrique Holschuh

Bug#867989: stretch-pu: package intel-microcode/3.20170707.1~deb9u1

On Thu, 13 Jul 2017, Adam D. Barratt wrote: > Please go ahead. Uploaded, thank you very much! -- Henrique Holschuh

Bug#863682: superseeding with new version

On Thu, 13 Jul 2017, Adam D. Barratt wrote: > > Intel released the fixes for Kaby Lake as well, so I am updating this > > s-p-u bug for the newer version of the intel-microcode package. > > Please go ahead. I've just uploaded it. Thank you very much! -- Henrique Holschuh

Bug#863682: more information

I have been taking a daily look for any reports of issues with intel microcode updates over the last 30 days, and so far there are no reports of issues caused by these updates. Due to the HT errata issue, these microcode updates had a lot more adoption than usual by users across most Linux

Bug#867989: stretch-pu: package intel-microcode/3.20170707.1~deb9u1

* Rebuild for stretch (no changes) + + -- Henrique de Moraes Holschuh <h...@debian.org> Sat, 08 Jul 2017 19:47:45 -0300 + +intel-microcode (3.20170707.1) unstable; urgency=high + + * New upstream microcode datafile 20170707 ++ New Microcodes: + sig 0x00050654, pf_mask 0x97, 2017-06-0

Bug#863682: superseeding with new version

is still the same, so I will quote it below. Thank you! For the record, this is related to: https://lists.debian.org/debian-devel/2017/06/msg00308.html On Mon, 29 May 2017, Henrique de Moraes Holschuh wrote: > I'd like to update the intel-microcode package in Debian jessie. > > Usually,

Bug#865713: Please Start UTF-8 debian-policy Text Files with UTF-8 Signature

On Sat, 24 Jun 2017, Russ Allbery wrote: > Russ Allbery writes: > > I did a bit more research, and apparently this approach has become more > > blessed again. I'm glad I looked it up! As of Unicode 5.0, the ... > Okay, I experimented with this, but unfortunately less displays

Bug#865367: developers-reference: section 5.5.1: explicitly mention that stable and oldstable uploads must use release codename

Package: developers-reference Version: 3.4.18 Severity: normal Section 5.5.1 seems to imply uploads to stable and oldstable should target "stable" or "oldstable" in the distribution field of the changelog entry, which is incorrect. Please add explicit text to section 5.5.1, directing uploaders

Bug#863682: jessie-pu: package intel-microcode/3.20170511.1~deb8u1 [v2]: target jessie

). The OCaml community was hit by this erratum + and has been investigating the issue since 2017-01. It affected the + OCaml compiler, and OCaml programs when gcc was used as the backend. + https://caml.inria.fr/mantis/view.php?id=7452 + + -- Henrique de Moraes Holschuh <h...@debian.

Bug#717096: not amavis' fault, but file magic

On Tue, 20 Jun 2017, d-eb...@q3co.de wrote: > Hi, I've run into this lately, too. > It appears that amavis uses the local installation of "file"'s magic > configuration for identifying file-content. > > With an old "file magic" it says "Zip archive" for newer word docs, > and in turn probably

Bug#865070: tracker.debian.org: jessie->stretch issues with backports on version pane

Package: tracker.debian.org Severity: important Apparently, tracker.debian.org still thinks jessie-backports is stable-backports, and that wheezy-backports is oldstable-backports Sample pages with incorrect information: https://tracker.debian.org/pkg/intel-microcode

Bug#864716: modules and custom kernels

It is recommended that users building their own kernels never configure as a module any driver that Debian doesn't configure as a module. Anyway, essential modules for system operation should preferably be added to /etc/modules. They will be early-loaded by whatever gets to them first (be it the

Bug#863682: jessie-pu: package intel-microcode/3.20170511.1~deb8u1

the issue since 2017-01. It affected the + OCaml compiler, and OCaml programs when gcc was used as the backend. + https://caml.inria.fr/mantis/view.php?id=7452 + + -- Henrique de Moraes Holschuh <h...@debian.org> Mon, 29 May 2017 19:06:06 -0300 + +intel-microcode (3.2017051

Bug#862871: unblock: intel-microcode/3.20170511.1

On Thu, 18 May 2017, Jonathan Wiltshire wrote: > On 2017-05-17 22:44, Henrique de Moraes Holschuh wrote: > >Please unblock package intel-microcode. > > Unblocked. Thank you! -- Henrique Holschuh

Bug#862871: unblock: intel-microcode/3.20170511.1

superseded upstream data file: 20161104 + + -- Henrique de Moraes Holschuh <h...@debian.org> Mon, 15 May 2017 15:12:25 -0300 + intel-microcode (3.20161104.1) unstable; urgency=medium * New upstream microcode datafile 20161104 diff -Nru intel-microcode-3.20161104.1/releasenote in

Bug#862606: intel-microcode: microcode update may hang Xeon E7-8891v4/E7-8893v4

Package: intel-microcode Version: 3.20160607.1 Severity: important Erratum BDF90 (BDX90?) for the Xeon E7v4 (and maybe Xeon E5v4) may result in a hung system on all affected processors when a microcode update is attempted during boot on a Debian system with the intel-microcode package installed.

Bug#862217: [Pkg-sysvinit-devel] Bug#862217: initscript does fsck on empty floppy drive and stops booting

On Tue, 09 May 2017, David Lawyer wrote: > My PC has a floppy drive which I seldom use. When I boot linux, it runs > /etc/init.d/checkfs.sh which runs fsck.fat on the floppy drive > /dev/fd0. The fsck fails because there is no floppy in the drive and ... > Linux should not try to run fsck on a

Bug#861169: Triaging and downgrading severity (includes rationale and suggestions)

severity 861169 important retitle 861169 systemd service overrides opendkim.conf socket at start thanks The previous report mentioned by the bug submitter is #853769. (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853769) >From that bug report, message #38

Bug#847311: amavisd-new: After the last Debian update Amavis does not read data type float from Mysql DB correctly. All fields are "0".

n is done by that. > This could be quite relevant. LOC, could you send (to this bug report) a dump of the *schema* for the relevant tables (the ones returning 0 instead of the correct float) ? Maybe ISPConfig is not creating them exactly the same way amavisd- new would... -- Henriq

Bug#847311: amavisd-new: After the last Debian update Amavis does not read data type float from Mysql DB correctly. All fields are "0".

On Sun, 12 Feb 2017, Brian May wrote: > >> https://github.com/perl5-dbi/DBD-mysql/issues/78 > > Please read the latest message on the above report... Jakub, This issue is a nasty problem between amavisd-new and DBD-mysql. It is yet not clear which program is at fault, or if it is an ABI break

Bug#847311: amavisd-new: After the last Debian update Amavis does not read data type float from Mysql DB correctly. All fields are "0".

On Sun, 12 Feb 2017, Brian May wrote: > I am starting to think that maybe the bug lies solely in p5-DBD-mysql > not returning valid data. I guess one could try to look at what it actually returns, comparing 4.037 (old API/ABI) with 4.041 (new API/ABI?), for the "string" return type, I think. And

Bug#853769: [PATCH] PROPOSED NMU

On Sat, 11 Feb 2017, Scott Kitterman wrote: > Please don't upload. I'll take care of it this week. Ok. Thanks. -- Henrique Holschuh

Bug#847311: amavisd-new: After the last Debian update Amavis does not read data type float from Mysql DB correctly. All fields are "0".

On Sun, 05 Feb 2017, Brian May wrote: > On Wed, Dec 07, 2016 at 09:26:04AM +0100, Jakub Novak wrote: > > With the latest update of Debian packages in Scratch, Amavis started to > > reject more than 50% of all emails as spam. > > From Amavis debuging logs, all the MySQL fields that are of type

Bug#853769: [PATCH] PROPOSED NMU

in the command line may require +overriding the systemd unit, but this is exactly as it works in +sysvinit. + + -- Henrique de Moraes Holschuh <h...@debian.org> Sat, 11 Feb 2017 14:40:45 -0200 + opendkim (2.11.0~alpha-9) unstable; urgency=medium * Set umask to 0007 in opendkim.serv

Bug#851427: [Pkg-sysvinit-devel] Bug#851427: sysvinit makes /dev/shm a symlink to /run/shm, should be other way round

On Sat, 14 Jan 2017, Holger Levsen wrote: > On Sat, Jan 14, 2017 at 09:50:43PM +, Holger Levsen wrote: > > and /dev/shm is owned by root:root and has perms 1755? > > actually I have both 1777 and 0755 here, which of the two is correct or > are both fine?? It has to be mode 01777, read+write.

Bug#850182: Please disable TSX in stretch and backport to jessie

On Thu, 05 Jan 2017, Aurelien Jarno wrote: > On 2017-01-05 09:15, Henrique de Moraes Holschuh wrote: > > Also valid for S/390x, POWER, and anything else where glibc 2.24 > > supports hardware lock elision. > > Do you have some pointers about the different behaviour of lock

Bug#848341: jessie-pu: package intel-microcode/3.20161104.1~deb8u1

On Thu, 05 Jan 2017, Adam D. Barratt wrote: > On Fri, 2016-12-16 at 10:17 -0200, Henrique de Moraes Holschuh wrote: > > I would like to update the intel-microcode packages in stable to address > > several critical errata in newer Intel processors. > > > > The upda

Bug#850182: Please disable TSX in stretch and backport to jessie

d generate a warning instead. That said, I am not speaking against disabling hardware lock elision acceleration for Debian Stretch. We might be better off disabling it. -- Henrique de Moraes Holschuh <h...@debian.org>

Bug#826214: [Pkg-sysvinit-devel] Bug#826215: Bug #826214: Bug #826215: init-d-script and systemd: solution

is currently broken that it fails to, by default, also stop related socket units, thus ensuring chaos if activated midway during the unpack/configure steps. A bug is already open about it, but stalled. -- Henrique de Moraes Holschuh <h...@debian.org>

Bug#835520: [PATCH v2 11/11] Drop entire section 9.4 Console messages from init.d scripts

ainers to follow the relevant sections of the LSB? -- Henrique de Moraes Holschuh <h...@debian.org>

Bug#848341: jessie-pu: package intel-microcode/3.20161104.1~deb8u1

Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu I would like to update the intel-microcode packages in stable to address several critical errata in newer Intel processors. The updated packages being proposed in this bug report

Bug#848121: [Pkg-sysvinit-devel] Bug#848121: File conflict between manpages and initscripts

On Wed, 14 Dec 2016, Ian Jackson wrote: > Michael Kerrisk (man-pages) writes ("Re: Bug#848121: [Pkg-sysvinit-devel] > File conflict between manpages and initscripts"): > > On 14 December 2016 at 16:45, Ian Jackson > > wrote: > > > - rename the manpage about

Bug#630920: rng-tools5 uploaded, waiting in NEW

tag 630920 + pending thanks On Thu, 08 Dec 2016, gustavo panizzo (gfa) wrote: > I could prepare an upload using upstream source (the one you forked > from, as it supports RDRAND) and updating the debian packaging to > today's practices (debhelper 10, gbp, etc). rng-tools5 is in the NEW queue,

Bug#692450: rng-tools: please update to version 4

On Sat, 03 Dec 2016, Lee Garrett wrote: > On 03/12/16 14:19, Henrique de Moraes Holschuh wrote: > > On Fri, 02 Dec 2016, Michael Stone wrote: > >>> Meh, I have requested help for it a long time ago. The RFH bug is from > >>> 2011. > >> > >>

Bug#692450: rng-tools: please update to version 4

On Fri, 02 Dec 2016, Michael Stone wrote: > >Meh, I have requested help for it a long time ago. The RFH bug is from > >2011. > > Well, nobody looks at those :D > > >Will you maintain rng-tools4? > > Well, it's up to 5 at this point but yes unless someone else is itching to. Ok, let's

Bug#692450: rng-tools: please update to version 4

On Fri, 02 Dec 2016, Michael Stone wrote: > This has been pending with no action for more than 4 years now. Is there a > strategy for moving forward? I see 3 realistic options: > > 1) upload the new upstream with a big warning in NEWS that things will break I consider this acceptable, but you

Bug#845194: amd64-microcode: please make the early initramfs image reproducible

On Sun, 27 Nov 2016, Chris Lamb wrote: > Henrique de Moraes Holschuh wrote: > > Please test the attached patch. Does it pass all the reproducibility > > testing? > > Not quite; I needed to make the following change to your patch: > > - CHANGELOG_TS :=$(shell

Bug#845194: amd64-microcode: please make the early initramfs image reproducible

On Fri, 25 Nov 2016, Holger Levsen wrote: > On Thu, Nov 24, 2016 at 11:20:19PM +0100, Chris Lamb wrote: > > > Please test the attached patch. Does it pass all the reproducibility > > > testing? > > This is not actually tested in Debian's Reproducible Builds testing > > framework — I discovered it

Bug#845194: amd64-microcode: please make the early initramfs image reproducible

Chris, Please test the attached patch. Does it pass all the reproducibility testing? -- Henrique Holschuh diff --git a/debian/initramfs.hook b/debian/initramfs.hook index d250719..c65d7d4 100755 --- a/debian/initramfs.hook +++ b/debian/initramfs.hook @@ -73,6 +73,9 @@ fi verbose

Bug#845194: amd64-microcode: please make the early initramfs image reproducible

te to create any early initramfs... -- Henrique de Moraes Holschuh <h...@debian.org>

Bug#844431: Packages should be reproducible

On Tue, 15 Nov 2016, Chris Lamb wrote: > [As a mild suggestion to streamline this; we should probably come to some > consensus on principle of this addition to Policy first and only then > move to the more difficult topic of defining exactly what reproducibility > means in a technical sense.] I

Bug#842796: libc recently more aggressive about pthread locks in stable ?

Lucas, Thanks for trying a build run with TSX enabled. On Sat, 12 Nov 2016, Lucas Nussbaum wrote: > I did an archive rebuild on Amazon EC2 using m4.16xlarge instances, that > use a CPU with TSX enabled. What microcode revision is that Xeon E5-2686 running? > I've filed bugs for the packages

Bug#842796: libc recently more aggressive about pthread locks in stable ?

On Mon, 07 Nov 2016, Lucas Nussbaum wrote: > On 06/11/16 at 17:41 -0200, Henrique de Moraes Holschuh wrote: > > On Sun, 06 Nov 2016, Ben Hutchings wrote: > > > It's worth noting that TSX is broken in 'Haswell' processors and is > > > supposed to be disabled via a micr

Bug#842796: libc recently more aggressive about pthread locks in stable ?

On Sun, 06 Nov 2016, Adrian Bunk wrote: > On Sun, Nov 06, 2016 at 05:41:34PM -0200, Henrique de Moraes Holschuh wrote: > > On Sun, 06 Nov 2016, Ben Hutchings wrote: > > > It's worth noting that TSX is broken in 'Haswell' processors and is > > > supposed to be disabled

Bug#842796: libc recently more aggressive about pthread locks in stable ?

On Sun, 06 Nov 2016, Ben Hutchings wrote: > It's worth noting that TSX is broken in 'Haswell' processors and is > supposed to be disabled via a microcode update. I don't know whether > glibc avoids using it on these processors if the microcode update is > not applied. (Linux doesn't appear to

Bug#842796: libc recently more aggressive about pthread locks in stable ?

On Sat, 05 Nov 2016, Ian Jackson wrote: > Looking at the code, I think that gs in jessie is plainly violating > the rules about the use of pthread locks. On my partner's machine, Per logs from message #15 on bug #842796: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842796#15 SIGSEGV on

Bug#840255: tiny-initramfs: please use iucode_tool to generate early-initramfs for Intel

On Tue, 01 Nov 2016, Christian Seiler wrote: > On 10/10/2016 04:46 AM, Henrique de Moraes Holschuh wrote: > > Plase use iucode_tool to generate the early initramfs for Intel > > microcode. Not only this can create a smaller initramfs when coupled > > with iucode_

Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

ss grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh <h...@debian.org>

Bug#840255: tiny-initramfs: please use iucode-tool to generate early-initramfs for Intel

Package: tiny-initramfs Version: 0.1-1 Severity: minor Plase use iucode_tool to generate the early initramfs for Intel microcode. Not only this can create a smaller initramfs when coupled with iucode_tool's "--scan-system" functionality, it also tweaks the cpio header of the early-initramfs

Bug#839882: amd64-microcode recommends dracut or initramfs-tools only

tag 839882 + confirmed severity 839882 normal retitle 839882 amd64-microcode: please accept tiny-initramfs for recommends thanks On Thu, 06 Oct 2016, Ricardo Fabian Peliquero wrote: > On Thu, Oct 06, 2016 at 03:21:16PM -0300, Henrique de Moraes Holschuh wrote: > > On Thu, 06 Oct 2016

Bug#839882: amd64-microcode recommends dracut or initramfs-tools only

On Thu, 06 Oct 2016, Ricardo Fabian Peliquero wrote: > On Thu, Oct 06, 2016 at 08:13:33AM -0300, Henrique de Moraes Holschuh > wrote: > > On Thu, 06 Oct 2016, Ricardo Fabian Peliquero wrote: > > > amd64-microcode recommends dracut or initramfs-tools. Please > > >

Bug#839882: amd64-microcode recommends dracut or initramfs-tools only

On Thu, 06 Oct 2016, Ricardo Fabian Peliquero wrote: > amd64-microcode recommends dracut or initramfs-tools. Please consider > recommending virtual package linux-initramfs-tool instead. That way, > it would include any of these packages: dracut, initramfs-tools or > tiny-initramfs. Have you

Bug#839114: RFS: [ITA] Hi, I'd like to adopt systemd-shim

On Thu, 29 Sep 2016, Ab B wrote: > I've only looked at ubuntu but it seems like it's maintained at least > there. It looks like mint 15 which dw says is the most popular distro > seems to use it. It is gone from Ubuntu. It will not be present in their next stable release, refer to

Bug#839114: RFS: [ITA] Hi, I'd like to adopt systemd-shim

On Wed, 28 Sep 2016, Ab B wrote: > Hello. I'd like to adopt the systemd-shim package. I suppose I > would need a sponsor/mentor to do that? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832508 Read that bug report again, especially this part: "The upstream branch is currently at

Bug#600433: collectd: rrd: gets terribly confused when entering DST (daylight savings time)

On Sat, 24 Sep 2016, Sebastian Harl wrote: > Is this still happening? I believe there were a few fixes that could be > related to this in the past years. If it's still happening, we'll have > to look into more details. I wouldn't know if the bug still exists: I have stopped using collectd a long

Bug#815990: Upgrade of intel-microcode to 3.20151106.1~deb8u1 results in throttled CPU (E5-2680 v3)

On Tue, 06 Sep 2016, Jonas Zierer wrote: > I'm running Ubuntu on my Dell E7440 (CPU: i7-4600U CPU @ 2.10GHz, > sig=0x40651) and have exactly the same problem. I updated the microcode It might be, or it might not be exactly the same problem. Do you have *exactly* the same problem as the one

Bug#834261: jessie-pu: package intel-microcode/3.20160714.1~deb8u1

On Sun, 28 Aug 2016, Adam D. Barratt wrote: > On Sat, 2016-08-13 at 18:27 -0300, Henrique de Moraes Holschuh wrote: > > I would like to update the intel-microcode packages in stable to address > > several critical errata in newer Intel processors, as well as to > > prope

Bug#834261: jessie-pu: package intel-microcode/3.20160714.1~deb8u1

Due to new information, I have now high confidence that this proposed update fixes a regression currently present in jessie (stable): Debian bug #815990. -- Henrique Holschuh

Bug#815990: Upgrade of intel-microcode to 3.20151106.1~deb8u1 results in throttled CPU (E5-2680 v3)

On Fri, 26 Aug 2016, Stuart Bennett wrote: > I reproducibly found that on initial booting, with no system load, 0x36 came > up with processors clocked at 900MHz (below the cpufreq scaling_min_freq of > 1200MHz), before then settling to 1200MHz after some time, whereas 0x32 and > 0x38 behaved

Bug#815990: Upgrade of intel-microcode to 3.20151106.1~deb8u1 results in throttled CPU (E5-2680 v3)

On Fri, 19 Aug 2016, Stuart Bennett wrote: > On 19/08/16 13:49, Henrique de Moraes Holschuh wrote: > >No need to downgrade the BIOS, it is enough if you go from microcode > >0x36 to 0x38 by just installing intel-microcode and rebooting. It is > >not a complete test, but

Bug#815990: Upgrade of intel-microcode to 3.20151106.1~deb8u1 results in throttled CPU (E5-2680 v3)

On Fri, 19 Aug 2016, Stuart Bennett wrote: > On 19/08/16 13:10, Henrique de Moraes Holschuh wrote: > a) downgrade the BIOS > b) wait to verify that the performance bug returns > c) install the 0x38 microcode > d) wait for performance to regress (potentially) > e) restore the

Bug#815990: Upgrade of intel-microcode to 3.20151106.1~deb8u1 results in throttled CPU (E5-2680 v3)

On Fri, 22 Jul 2016, Henrique de Moraes Holschuh wrote: > > On Mon, 28 Mar 2016, Stuart Bennett wrote: > > > On 28/03/16 19:00, Henrique de Moraes Holschuh wrote: > > > >That said, what microcode comes with this new BIOS? Is it 0x36 already, > > > >or somet

Bug#834261: jessie-pu: package intel-microcode/3.20160714.1~deb8u1

E7-v3 48xx/88xx + + -- Henrique de Moraes Holschuh <h...@debian.org> Sun, 07 Aug 2016 21:48:59 -0300 + +intel-microcode (3.20160714.1~bpo8+1) jessie-backports; urgency=medium + + * Rebuild for jessie-backports (no changes) + + -- Henrique de Moraes Holschuh <h...@debian.org> Fri, 22

Bug#722348: (no subject)

Looks like the usual lock b0rkage where something tries to unlock an already unlocked lock, to me. In that case, it is a simple software bug. However, if (and only if) it only happens under x32, but works fine under amd64 on the same box, it could be a bug somewhere else (kernel, libpthreads,

Bug#833388: Please raise your opinion to package size and the given options to restrict it (Was: Bug#833388: ITP: metaphlan2 -- Metagenomic Phylogenetic Analysis)

On Thu, 04 Aug 2016, Holger Levsen wrote: > On Thu, Aug 04, 2016 at 09:30:19AM +0200, Andreas Tille wrote: > [...] > > > 2) When unpackaging the orig.tar.gz translating binary data to > > > text format and recompress using xz the tarball is "only" 265MB. > > > The transformation

Bug#815990: Upgrade of intel-microcode to 3.20151106.1~deb8u1 results in throttled CPU (E5-2680 v3)

> On Mon, 28 Mar 2016, Stuart Bennett wrote: > > On 28/03/16 19:00, Henrique de Moraes Holschuh wrote: > > >That said, what microcode comes with this new BIOS? Is it 0x36 already, > > >or something earlier? > > > > It is indeed 0x36. The intel-microcode up

Bug#828819: intel-microcode: i7-6500U doesn't boot in 4/5 cases with 3.20160607.1

On Fri, 22 Jul 2016, Jochen Sprickerhof wrote: > thanks for clearing this up so quickly :). Just as a follow up, Tuxedo > released > a new BIOS version including microcode 0x8a and I tested that 3.20160607.1 > doesn't fail with that anymore. Yeah, information about their BIOS update was

Bug#828819: intel-microcode: i7-6500U doesn't boot in 4/5 cases with 3.20160607.1

Well, more information: Report for the same issue on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1353103 All reports of this issue being "fixed" by a firmware update (in Debian, Arch and Fedora) are for firmware updates that come with microcode 0x8a already, effectively rendering the

Bug#828819: intel-microcode: i7-6500U doesn't boot in 4/5 cases with 3.20160607.1

On Mon, 04 Jul 2016, Mike Palmer wrote: > Jul  3 22:12:30 carbon kernel: [1.670464] microcode: CPU0 > sig=0x406e3, pf=0x80, revision=0x8a Well, basically it is not doing anything because your BIOS has the new microcode already... I wanted to confirm the "pf", and it is the same pf as the

Bug#828819: intel-microcode: i7-6500U doesn't boot in 4/5 cases with 3.20160607.1

Mike, After the BIOS update, do you have any "microcode" entries in the kernel log? Could you send them to the bug report? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." --

<    1   2   3   4   5   6   7   8   9   10   >