This is bug #814301, already fixed in unstable.
A package with this fix won't be uploaded to stable-backports until bug
#828819 is fixed, and right now I have nowhere near enough data to do
so.
On Sat, 02 Jul 2016, Nicholas D Steeves wrote:
> the version in sid, please close this bug with "fixed
On Tue, 28 Jun 2016, Jochen Sprickerhof wrote:
> * Henrique de Moraes Holschuh <h...@debian.org> [2016-06-28 10:06]:
> > Should a firmware update not be available yet from your system vendor,
> > please request on their support channels a BIOS/UEFI update that has:
&g
On Tue, 28 Jun 2016, Jochen Sprickerhof wrote:
> microcode : 0x6a
AFAIK, this microcode revision level is subtly incompatible with Linux
due to documented processor errata. Unfortunately, your system really
needs a firmware and microcode update to run Debian in a stable way.
Worse, it looks
On Tue, 28 Jun 2016, Andreas Tille wrote:
> I admit I can not answer the question asked by upstream. The package in
> question is iqtree[1] and they said that they have different
> computational kernels implemented to respect different hardware.
> Current Git[1] does not even build - may be due
severity 828819 grave
thanks
Raising severity to block migration to testing while we examine this
issue.
On Tue, 28 Jun 2016, Jochen wrote:
> Version: 3.20160607.1
>
> my system boots only in 1 out of 5 cases (or less) with the current version in
> unstable. It stops after loading the initrd
dows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
On Fri, 10 Jun 2016, Michael Tokarev wrote:
> 10.06.2016 04:31, Henrique de Moraes Holschuh wrote:
> > One must enable SCTERC (e.g. with smartctl -l scterr,70,500) before
> > starting the array (initramfs included). Fortunately, suport for SCTERC
> > can be detected, and it c
Package: mdadm
Version: 3.3.2-5+deb8u1
Severity: normal
madam waits forever for component devices to complete operations, but
the kernel scsi layer doesn't and may offline the device, causing md to
kick it off the array.
This is actually a very long-standing "stack integration" issue and not
an
the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
Package: wnpp
Severity: wishlist
* Package name: vim-lastplace
Version : 3.0.2
Upstream Author : Greg Dietsche
* URL : https://github.com/dietsche/vim-lastplace
* License : MIT/X
Programming Lang: vim script
Description : Intelligently reopen files at
Package: ndiff
Version: 6.47-3+deb8u1
Severity: grave
Justification: renders package unusable
Tags: jessie
The current ndiff package in jessie-proposed-updates is considered
uninstallable by at least aptitude when zenmap is installed.
This probably happens because ndiff in
On Fri, 06 May 2016, Tormod Volden wrote:
> PS. I didn't think about it initially, but I guess "NACK" means
> "thanks for your patch and your interest in the developer reference,
> but I don't think this is the best solution."
That's pretty much correct, yes.
NACK in this context implies that
On Sat, 07 May 2016, Helmut Grohne wrote:
> I argue that invoke-rc.d changed API. Formerly (with sysv) reloading a
> service that isn't started would generally do nothing (or fail). In any
> case, one generally wouldn't expect a reload operation to finish before
> the invoke-rc.d call returns (as
systemd).
I also need the output of /proc/cpuinfo (on both microcodes, please).
--
"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." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
On Sat, 16 Apr 2016, Ben Hutchings wrote:
> On Wed, 30 Mar 2016 14:33:52 -0300 Henrique de Moraes Holschuh
> <h...@debian.org> wrote:
> > (note: I am not subscribed to this bug report. If you want a reply from
> > me, please keep me Cc'd).
> [...]
> > Now,
ess error message either.
Users of older kernels will still get that message if they lack the
microcode module.
--
"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." -
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.
Thank you for the information.
--
"One
ind them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
ll, 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." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
On Mon, Mar 28, 2016, at 09:44, Stuart Bennett wrote:
> On 16/03/16 17:34, Henrique de Moraes Holschuh wrote:
> > On Mon, Mar 7, 2016, at 14:28, Stuart Bennett wrote:
> >> As it happens there is a published update including microcode 0x36 and
> >> the management engine
Package: debmirror
Version: 1:2.16
Severity: important
Please prepare a stable-update (preferable), or if that is impossible, a
stable-backports release of debmirror that is more compatible with the
changes done to the Debian archive (testing, unstable, experimental) in
2016.
It might even be
Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
On Sun, 20 Mar 2016, Adam D. Barratt wrote:
> On Sun, 2016-03-20 at 12:20 -0300, Henrique de Moraes Holschuh wrote:
> > I have uploaded it through the ftp queue about one hour ago, but I have
> > still not received any email back either from the upload queue daemon,
On Sun, 20 Mar 2016, Adam D. Barratt wrote:
> On Sat, 2016-03-19 at 19:23 -0300, Henrique de Moraes Holschuh wrote:
> > This is the non-free oldstable companion update for the same issue reported
> > in #818689:
> >
> > Unfortunately, the microcode for the earlier AMD
On Thu, 17 Mar 2016, Manuel A. Fernandez Montecelo wrote:
> 2006-01-07 00:22 Henrique de Moraes Holschuh:
> >Package: aptitude
> >Version: 0.4.1-1
> >Severity: important
> >
> >I am tagging this as important because any bug that makes people install
> >
sucessful host-kernel
+ring 0 code injection attack.
+ * The erratum is timing-dependant, easily triggered by workloads that
+cause a high number of NMIs, such as running the "perf" tool.
+
+ -- Henrique de Moraes Holschuh <h...@debian.org> Sat, 19 Mar 2016 19:10:20
On Sat, 19 Mar 2016, Adam D. Barratt wrote:
> On Sat, 2016-03-19 at 15:50 -0300, Henrique de Moraes Holschuh wrote:
> > Unfortunately, the microcode for the earlier AMD Piledriver processors being
> > distributed in the amd64-microcode packages currently in non-free oldstable,
>
On Mon, Mar 7, 2016, at 14:28, Stuart Bennett wrote:
> On 03/03/16 14:48, Henrique de Moraes Holschuh wrote:
> > Argh. Is this a motherboard from a non-joke vendor ? If so, please
> > open a support case and tell them you are hitting a "severe performance
> > issue&qu
-microcode-2.20160316.1~deb8u1/debian/changelog2016-03-19
14:22:44.0 -0300
@@ -1,3 +1,36 @@
+amd64-microcode (2.20160316.1~deb8u1) stable; urgency=critical
+
+ * This is exactly the same release as 2.20160316.1
+
+ -- Henrique de Moraes Holschuh <h...@debian.org> Sat, 19 Mar 2
all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
On Sun, 06 Mar 2016, Petter Reinholdtsen wrote:
> Hi. I would be happy for skilled people with more time to take over the
> maintenance. I would be happy to help with the knowledge I got, but
> lack the time required to do a good job maintaining the sysvinit,
> insserv and startpar package.
On Thu, Mar 3, 2016, at 10:11, Stuart Bennett wrote:
> On 03/03/16 12:33, Henrique de Moraes Holschuh wrote:
> > Does it fix anything?
>
> Sadly not.
...
> /sys/devices/system/cpu/intel_pstate/max_perf_pct:100
> /sys/devices/system/cpu/intel_pstate/no_turbo:0
>
On Thu, Mar 3, 2016, at 08:57, Stuart Bennett wrote:
> On 02/03/16 17:57, Henrique de Moraes Holschuh wrote:
> > This is exactly what happens when thermald messes with these Xeons, as
> > long as your MSR 0x1b0 is also reading "7".
> >
> > So, could you check t
On Wed, Mar 2, 2016, at 11:51, Stuart Bennett wrote:
> On 27/02/16 22:36, Henrique de Moraes Holschuh wrote:
> > In the thermald bug report, you will see lots of posts asking for the values
> > of several MSRs, and also to run "turbostat" and attach its output.
> >
On Sat, 27 Feb 2016, Stuart Bennett wrote:
> Let me know if any other tests/information indicated in the other bug would
> be potentially relevant in this case.
In the thermald bug report, you will see lots of posts asking for the values
of several MSRs, and also to run "turbostat" and attach its
On Fri, 26 Feb 2016, Stuart Bennett wrote:
> Some time after booting, all cores of an Intel E5-2680 v3 get throttled to
> around 400MHz. The intel_pstate cpufreq driver is in use, as is the
Are you using thermald?
If so, could you please try to remove it, **reboot** (with microcode 0x36),
and
On Sun, 21 Feb 2016, Milan Broz wrote:
> On 02/21/2016 09:40 PM, Henrique de Moraes Holschuh wrote:
> Only some of stable kernels are problematic because of incomplete backported
> patch series.
>
> See http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg17926.html
> (I
Source: cryptsetup
Severity: important
Tags: upstream fixed-upstream
This bug is actually severity grave as it renders systems unbootable and
data unaccessible, but since it can only trigger on non-Debian kernels ATM,
I am reporting it at severity important.
On Wed, 27 Jan 2016, Balint Reczey wrote:
> +--- a/config.guess
> b/config.guess
> +@@ -145,6 +145,8 @@ Linux|GNU|GNU/*)
> + LIBC=uclibc
> + #elif defined(__dietlibc__)
> + LIBC=dietlibc
> ++#elif defined(__GNU_FEATURESET_HARDENED1__)
> ++LIBC=gnuhardened1
> + #else
>
(Julian, can you join us in the discussion of bug #812521 ?)
On Sun, 24 Jan 2016, Axel Beckert wrote:
> /usr/share/doc/autotools-dev/README.Debian.gz states:
> > Do NOT use dh-autoreconf and dh_autotools-dev_* helpers at the same
> > time, dh-autoreconf takes care of updating config.sub and
On Mon, 28 Dec 2015, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
>
> On 2015-12-28 19:12, Henrique de Moraes Holschuh wrote:
> >I would like to update the intel-microcode package in Debian stable
> >(jessie), to the microcode that is already being shipped in unstabl
d for jessie (stable update), no changes required
+ * This is the same package as 3.20151106.1~bpo8+1 (jessie-backports)
+and 3.20151106.1 (unstable, stretch)
+
+ -- Henrique de Moraes Holschuh <h...@debian.org> Mon, 28 Dec 2015 15:57:14
-0200
+
+intel-microcode (3.20151106.1) unstable;
plans for uploading new glibc to unstable are.
--
"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." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
cal mail delivery/routing, etc).
--
"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." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
On Sun, 18 Oct 2015, Aurelien Jarno wrote:
> > Broadwell-H with a very recent microcode update (rev 0x12, from
> > 2015-06-04) was confirmed to have broken TSX-NI (RTM) and to _leave it
> > enabled_ in CPUID, causing glibc with lock elision enabled to SIGSEGV.
> > An even more recent Broadwell-H
On Sun, 18 Oct 2015, Aurelien Jarno wrote:
> On 2015-10-07 07:32, Henrique de Moraes Holschuh wrote:
> > Meanwhile, a suggestion by Samuel Thibault to try to use hwcap did
> > provide for a possible long-term plan to fine-tune the lock-elision
> > blacklist (and anyth
find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
Intel TSX is broken on Haswell based processors (erratum HSD136/HSW136)
and a microcode upd
of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
"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." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
On Thu, 01 Oct 2015, Henrique de Moraes Holschuh wrote:
> We have a fix for the HLE BDW50 errata confirmed for Broadwell-H,
> through updated microcode.
>
> Broadwell-H errata BDW50 fix:
> signature 0x40671, pf_mask 0x22, revision >= 0x12
>
> Which would allow us to se
o that we can get
independent reports of the HLE situation in Skylake.
--
"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." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <h...@debian.org>
Package: libc6
Version: 2.19-4
Severity: grave
Justification: causes non-serious data loss
Intel Broadwell-H and Skylake-S/H have critical errata that causes HLE
to be extremely dangerous to use on those processors, resulting in
unpredictable behavior (i.e. process crashes when you are lucky,
On Thu, 24 Sep 2015, Matthias Klose wrote:
> which is EOL upstream for more than a year, and which targets non-default
> flags. You don't even try to reproduce with current GCC versions in
-O3 is not exactly a "uncommon" flag. I just tracked it down to
-ftree-vectorize (enabled by -O3) to
On Thu, 24 Sep 2015, Henrique de Moraes Holschuh wrote:
> It still exists on gcc-4.9 in stable (gcc Debian 4.9.2-10). I am going to
> test on an unstable chroot and gcc-snapshot in a few moments.
I've tested it in unstable as well. Here's a proper summary:
1. Bug exists in gcc Debian 4
On Thu, 24 Sep 2015, Henrique de Moraes Holschuh wrote:
> 1. Bug exists in gcc Debian 4.6.4-7 (latest 4.6 in unstable)
> 2a. Bug exists in gcc Debian 4.7.2-5 (default gcc for oldstable)
> 2b. Bug exists in gcc Debian 4.7.4-3 (latest 4.7 in unstable)
> 3. Bug exists in gcc Debian 4.8
Matthias,
Given the new information I just sent to the bug report, and since all
current versions of gcc have this issue, it should not remain as "wishlist"
in gcc-4.7 only.
I have tagged it "upstream" for now, and removed the "moreinfo" tag.
Should I raise severity back to important, or to
Package: gcc-4.7
Version: 4.7.2-5
Severity: important
On x86 and x86-64, the platform explicitly supports unaligned access,
and in fact such access has been heavily optimized on the latest Intel
and AMD processors.
A _lot_ of code takes advantage of this, as it is often extremely
painful (or
On Fri, 11 Sep 2015, Axel Beckert wrote:
> To demonstrate my point, please sort the following version numbers in
> your head:
>
> * 20110111.0
> * 2010.1
> * 2011.2
These are rather bad, as you might need to use epochs. In fact, they go
against documented current best practice due to a
Package: bugs.debian.org
Severity: important
Some MUAs in their default configuration (i.e. Mutt, which is *extremely*
widely used by Debian users and developers alike) set the Mail-Followup-To
header when composing email.
This easily results in emails sent by reportbug, or directly to
On Wed, 02 Sep 2015, Edward Betts wrote:
> * Package name: tzlocal
>
> It builds those binary packages:
>
> python-tzlocal - tzinfo object for the local timezone
> python3-tzlocal - tzinfo object for the local timezone (Python 3 version)
I usually don't bother with this for source
On Thu, 03 Sep 2015, Gianfranco Costamagna wrote:
> The question was actually:
>
> do you think we should rename now that is in the new queue?
Yes, it is not too late.
> we can upload as soon as it is accepted, or ask ftpmasters to kick it out
> and upload again.
I think it is likely better to
On Thu, 03 Sep 2015, Gianfranco Costamagna wrote:
> Hi Henrique,
>
> Do you think we should rename it?
Yes, otherwise I would not have suggested it :-)
--
"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
lie. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
On Thu, 13 Aug 2015, Victor Seva wrote:
* Package name: processor-trace
Upstream Author : Intel Corporation
Intel's reference implementation for decoding Intel PT.
Maybe it would be better to call this package intel-pt or something like
that? Or at least intel-processor-trace?
After
Package: udftools
Version: 1.0.0b3-14.3
Severity: important
I have recently received email, reproduced below, from Pali Rohár. The
downstream maintainers of other distros were on copy, and both Frantisek
Kluknavsky (@redhat) and Jan Kara (@suse) have replied favorably, which as
far as I am
work as a workaround.
--
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. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
--
To UNSUBSCRIBE, email to debian
. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
checked.
Has the situation changed?
--
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. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
--
To UNSUBSCRIBE
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. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe
, it looks like accepting this in
Debian is a lot of risk for no real gain.
--
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. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h
.
--
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. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ
, 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. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
Package: systemd
Version: 215-17
Severity: grave
Tags: upstream fixed-in-experimental
Justification: causes non-serious data loss
As reported in other distros:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1448259
https://bugzilla.redhat.com/show_bug.cgi?id=1183194
On Fri, May 8, 2015, at 01:01, Martin Pitt wrote:
Henrique de Moraes Holschuh [2015-05-07 23:01 -0300]:
As reported in other distros:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1448259
https://bugzilla.redhat.com/show_bug.cgi?id=1183194
https://bugzilla.redhat.com/show_bug.cgi
, 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. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject
confusion (I hope there is no need for special casing, but
this needs to be carefully considered).
--
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. -- The Silicon Valley Tarot Henrique de
. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
is fixed by removing intel-microcode, I will ask for
further details to narrow the issue down.
--
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. -- The Silicon Valley Tarot
Henrique de
enough information to track the issue, and we
should close this bug...
--
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. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h
On Fri, 13 Mar 2015, David Prévot wrote:
On Thu, Sep 11, 2014 at 09:57:57PM +0300, Niko Tyni wrote:
dpkg 1.17.11 and apt 1.0.7 recently implemented support for versioned
provides.
[…]
This clearly needs an update. No proposed wording yet, sorry.
Here is a simple one, stripping away the
On Thu, 12 Mar 2015, wzabo...@elektron.elka.pw.edu.pl wrote:
I have deleted the /etc/adjtime in the affected machine and rebooted it.
After that it boots correctly, without a delay caused by the future
superblock write time.
However I don't understand what was the real cause of the problem...
On Sat, 07 Mar 2015, Mirco Bauer wrote:
* Package name: corefx
Description : .NET Core Libraries
The .NET Core Runtime also named CoreCLR is an open source, cross-platform
runtime for the Common Language Infrastructure. The runtime currently only
supports on Linux the AMD64/x86_64
On Sat, 07 Mar 2015, Adam D. Barratt wrote:
Control: tags -1 + pending
On Fri, 2015-03-06 at 17:19 -0300, Henrique de Moraes Holschuh wrote:
On Fri, Mar 6, 2015, at 15:49, Adam D. Barratt wrote:
Control: tags -1 + wheezy confirmed
Uploaded.
and flagged for acceptance.
Thank you
+in release 20150107 caused CPU core hangs and Linux boot failures.
+The upstream fix was to downgrade it to the same microcode revision
+that was shipped in release 20140913
+ * source: remove superseded upstream data file: 20150107.
+
+ -- Henrique de Moraes Holschuh h...@debian.org Fri
Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Wed, 18 Feb 2015, Ivan Baldo wrote:
+# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh
and sourcing.
What is the point of running rng-tools under kfreebsd? Does it even work?
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the
On Mon, Feb 9, 2015, at 16:12, Adam D. Barratt wrote:
Control: tags -1 + pending
On Sun, 2015-02-08 at 20:50 -0200, Henrique de Moraes Holschuh wrote:
On Fri, 06 Feb 2015, Adam D. Barratt wrote:
On Tue, 2015-01-20 at 11:28 -0200, Henrique de Moraes Holschuh wrote:
I'd like to update
On Fri, 06 Feb 2015, Adam D. Barratt wrote:
On Tue, 2015-01-20 at 11:28 -0200, Henrique de Moraes Holschuh wrote:
I'd like to update the amd64-microcode package in wheezy.
Please go ahead.
Uploaded.
Thank you very much!
--
One disk to rule them all, One disk to find them. One disk
On Fri, 06 Feb 2015, Adam D. Barratt wrote:
On Sun, 2015-02-01 at 16:06 -0200, Henrique de Moraes Holschuh wrote:
Please unblock package intel-microcode
Intel botched a microcode update in the 20150107 release, currently in
Debian jessie (testing). This broken microcode update causes
it is released...
--
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. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ
file: 20150107.
+ * initramfs.hook: do not mix arrays and lists.
+Avoid echo foo $@, use echo foo $* instead. This is unlikely
+to be expĺoitable, but it makes ShellCheck happier.
+
+ -- Henrique de Moraes Holschuh h...@debian.org Wed, 28 Jan 2015 20:03:20 -0200
+
intel-microcode
for the random device driver.
--
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. -- The Silicon Valley Tarot
Henrique de Moraes Holschuh h...@debian.org
--
To UNSUBSCRIBE, email to debian-bugs
Lost the CC to the bug report... forwarding...
- Original message -
From: Henrique de Moraes Holschuh h...@debian.org
To: Ashish SHUKLA ashish...@lostca.se
Subject: Re: Bug#776431: Rebooting with intel-microcode
3.20150107.1~bpo70+1 causing CPU lockups
Date: Wed, 28 Jan 2015 11:50:45
tag 776431 + confirmed fixed-upstream
thanks
Bug submitter was quite clear that revision 0x2a is the one in his BIOS,
I failed to notice that.
Issue with microcode sig 0x306f2, pf_mask 0x7f, revision 0x2d confirmed.
--
One disk to rule them all, One disk to find them. One disk to bring
retitle 776431 intel-microcode: Haswell-E (306f2) microcode broken in 20150107
found 776431 intel-microcode/3.20150107.1
found 776431 intel-microcode/1.20150107.1
severity 776431 grave
thanks
Microcode for CPUID 0x306F2 has been downgraded by the new 20150121
release to the previously released
On Tue, 20 Jan 2015, Ivo De Decker wrote:
On Mon, Jan 19, 2015 at 04:14:21PM -0200, Henrique de Moraes Holschuh wrote:
Please unblock package intel-microcode
Unblocked.
Thank you!
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind
On Wed, 21 Jan 2015, Bolesław Tokarski wrote:
When update-rc.d is invoked (be it as part of some service installation or
manually), on some machines it takes much more time than anticipated. Example:
# time update-rc.d apache2 defaults
...
real5m23.611s
user0m0.092s
sys
+ * docs: use glob pattern for _fam* README
+ * control: remove homepage and update standards-version
+
+ -- Henrique de Moraes Holschuh h...@debian.org Tue, 20 Jan 2015 11:05:40 -0200
+
amd64-microcode (1.20120910-2) unstable; urgency=medium
* initramfs: work around initramfs-tools bug #688794
superseded upstream data file: 20140913
+
+ -- Henrique de Moraes Holschuh h...@debian.org Sun, 18 Jan 2015 00:30:11 -0200
+
intel-microcode (3.20140913.1) unstable; urgency=low
* New upstream microcode data file 20140913
diff -Nru intel-microcode-3.20140913.1/microcode-20140913.dat intel-microcode
201 - 300 of 1691 matches
Mail list logo
