On Wed, 2012-11-07 at 16:50 +0400, hr...@infotech.am wrote:
> The problem solved in Debian Wheezy for kernel
>
> linux-image-3.2.0-4-amd64 3.2.32-1 amd64 Linux 3.2 for 64-bit PCs
Are you sure? This doesn't include any of the changes that were
expected to fix this bug, as you did not report that
Processing commands for cont...@bugs.debian.org:
> tags 692604 + pending
Bug #692604 [firmware-linux-nonfree] firmware-linux-nonfree: please recommend
amd64-microcode, intel-microcode
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
692604: h
On Thu, 2012-11-08 at 13:34 +0100, Michael Temmerman wrote:
> Package: src:linux
> Version: 3.2.32-1
> Severity: important
>
> I ran apt-get update && apt-get dist-upgrade, which upgraded my kernel image &
> initrd
>
> now, when running update-initramfs -u either manually or when a package post
>
Your message dated Fri, 09 Nov 2012 05:59:38 +
with message-id <1352440778.4728.66.ca...@deadeye.wl.decadent.org.uk>
and subject line Re: Bug#692746: linux-image-3.2.0-4-amd64: cpu load of a
proces significantly increased
has caused the Debian Bug report #692746,
regarding linux-image-3.2.0-4-
Processing commands for cont...@bugs.debian.org:
> reassign 692742 initramfs-tools
Bug #692742 [src:linux] linux-image-3.2.0-4-rt-686-pae: update-initramfs -u
fatal error after upgrading to linux-image-3.2.0-4-rt-686-pae
Bug reassigned from package 'src:linux' to 'initramfs-tools'.
No longer mark
Processing commands for cont...@bugs.debian.org:
> tags 686284 + pending
Bug #686284 [src:linux] linux-image-3.2.0-3-686-pae: i915 locks up my Thinkpad
X30 (using a GMA 82830)
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
686284: http://bu
Processing commands for cont...@bugs.debian.org:
> # rejected as an ACPI bug not i915 bug
> tags 606713 - fixed-upstream
Bug #606713 [linux-2.6] screen power and lid open/close issues
Removed tag(s) fixed-upstream.
> notforwarded 606713
Bug #606713 [linux-2.6] screen power and lid open/close issue
Processing commands for cont...@bugs.debian.org:
> tags 692436 + pending
Bug #692436 [src:linux] asus-laptop; ACPI HWRS method takes 12 sconds on UL30A
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
692436: http://bugs.debian.org/cgi-bin/bug
Since commit 8871e99f89b7 ('asus-laptop: HRWS/HWRS typo'), module
initialisation is very slow on the Asus UL30A. The HWRS method takes
about 12 seconds to run, and subsequent initialisation also seems to
be delayed. Since we don't really need the result, don't bother
calling it on init. Those wh
On Fri, Nov 02, 2012 at 10:52:35PM +0100, Wilmer van der Gaast wrote:
> >
> Oh yes, definitely. Sorry for not being clear.
>
> Also, this has just happened again. This time, after me not having
> touched the laptop for over ten hours. I'm starting to wonder
> whether my filesystem is corrupted. I'
Hello all,
This crash has happened to me three times now, but the last time is is
five days ago. Seems to have disappeared as mysteriously as it appeared.
On 08-11-12 15:30, Theodore Ts'o wrote:
On Fri, Nov 02, 2012 at 10:52:35PM +0100, Wilmer van der Gaast wrote:
whether my filesystem is co
At 09:39 + on 08 Nov (1352367592), Jan Beulich wrote:
> The plt_wrap < plt_now thing of course is entirely unexplainable
> to me too: Considering that plt_scale doesn't change at all post-
> boot, apart from memory corruption I could only see an memory
> access ordering problem to be the reason
#
# bts-link upstream status pull for source package linux-2.6
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#
user bts-link-upstr...@lists.alioth.debian.org
# remote status report for #606713 (http://bugs.debian.org/606713)
# Bug title: screen power and lid open/close
#
# bts-link upstream status pull for source package src:linux
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#
user bts-link-upstr...@lists.alioth.debian.org
# remote status report for #691902 (http://bugs.debian.org/691902)
# Bug title: Unable to shutdown Debian Wheez
On 08/11/2012 16:45, "Tim Deegan" wrote:
>>> I wonder whether the overflow handling should just be removed, or made
>>> conditional on a command-line parameter, or on the 32-bit platform counter
>>> being at least somewhat likely to overflow before a softirq occurs -- it
>>> seems lots of systems
Processing commands for cont...@bugs.debian.org:
> #
> # bts-link upstream status pull for source package linux-2.6
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user bts-link-upstr...@lists.alioth.debian.org
Setting user to bts-link-upstr...@lists.alioth.debian
Processing commands for cont...@bugs.debian.org:
> #
> # bts-link upstream status pull for source package src:linux
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user bts-link-upstr...@lists.alioth.debian.org
Setting user to bts-link-upstr...@lists.alioth.debian
Processing commands for cont...@bugs.debian.org:
> fixed 689268 linux-2.6/3.3~rc6-1~experimental.1
Bug #689268 [src:linux] linux-image-3.2.0-3-amd64: Intel HD 4000 (Ivy Bridge)
graphics freeze
Bug #692500 [src:linux] [linux-image-amd64] system freezes with Ivy Brigde CPU
Marked as fixed in versio
fixed 689268 linux-2.6/3.3~rc6-1~experimental.1
forcemerge 689268 692234
quit
Ingo wrote:
> I have now been running kernel 3.3.0-rc6-amd64 for 4 days. I did even
> try with different BIOS settings for "IGD DVMT Memory" especially with
> "Maximum DVMT" which according to the manual corresponds to
On 8 November 2012 14:47, wrote:
> Hi Mauro,
>
> that's a question for you :
>
>> Philippe, could you clarify again what CPU model(s) this is being observed on
>> (the long times between individual steps forward with this problem perhaps
>> warrant repeating the basics each time, as it's otherwis
On 07.11.2012 15:15, Corentin Chary wrote:
Hum, we can safely remove this call if it can cause that kind of issue.
Could you cook a patch removing HWRS call on startup end si it to
platform-x86 and stable ? I'll be happy to ack it.
If I remember correctly, on Asus F80L the bit 0x001 of HWRS re
On 08/11/2012 14:28, "Ian Campbell" wrote:
>>> There appears to be a certain amount of hardware-specificness to the
>>> issue -- so I'm wondering if maybe there are some platforms whose tsc is
>>> not as monotonically increasing as it needs to be...
>>
>> plt_* timestamps are not derived from TS
On Thu, 2012-11-08 at 13:47 +, philippe.simo...@swisscom.com wrote:
> Hi Mauro,
>
> that's a question for you :
I think Jan was asking for information relating to the system you saw
this on -- or are you working on the same systems as Mauro?
Of course additional information from Mauro woul
On Thu, 2012-11-08 at 12:54 +, Keir Fraser wrote:
> On 08/11/2012 11:43, "Ian Campbell" wrote:
>
> >>> I'll leave this to Keir (who wrote the debugging patch) to answer but it
> >>> looks to me like it should be useful!
> >>
> >> I'm scratching my head. plt_wrap is earlier than plt_now, whic
On 07/11/2012 17:40, "Keir Fraser" wrote:
> On 07/11/2012 13:22, "Ian Campbell" wrote:
>
(XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306
now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5
plt_stamp64=15b800366a5 plt_mask= tsc=e3839fd23854
tsc_stam
On 08/11/2012 13:53, "Jan Beulich" wrote:
>>> Is it? My understanding was that plt_stamp64 is just a software
>>> extension to the more narrow HW counter, and hence the low
>>> plt_mask bits would always be expected to be identical.
>>
>> No, plt_stamp is simply the HW counter time at which plt_
I have now been running kernel 3.3.0-rc6-amd64 for 4 days. I did even
try with different BIOS settings for "IGD DVMT Memory" especially with
"Maximum DVMT" which according to the manual corresponds to 1.7GB. With
this configuration I did have freezes few times a day with Wheezy stock
kernel before.
>>> On 08.11.12 at 11:38, Keir Fraser wrote:
> On 08/11/2012 09:39, "Jan Beulich" wrote:
>
>> (XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306
>> now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5
>> plt_stamp64=15b800366a5 plt_mask= tsc=e3839fd23854
>>
Hi Mauro,
that's a question for you :
> Philippe, could you clarify again what CPU model(s) this is being observed on
> (the long times between individual steps forward with this problem perhaps
> warrant repeating the basics each time, as it's otherwise quite cumbersome
> to always look up old
Package: src:linux
Version: 3.6.4-1~experimental.1
Severity: wishlist
Dear Maintainer,
please consider enabling the kernel option CONFIG_DVB_USB_RTL28XXU.
Thank you in andvance!
Dirk Meul
-- Package-specific info:
** Version:
Linux version 3.6-trunk-amd64 (debian-kernel@lists.debian.org) (gcc
Package: src:linux
Version: 3.2.32-1
Severity: normal
Dear Maintainer,
The load of a realtime proces that I run is increased by more than 50%. With
kernel 3.2.0-2 it was about 13% and since kernel 3.2.0-3 (and 3.2.0-4) it is
around 19%.
The only difference is the kernel that I boot so therefore
On 08/11/2012 11:43, "Ian Campbell" wrote:
>>> I'll leave this to Keir (who wrote the debugging patch) to answer but it
>>> looks to me like it should be useful!
>>
>> I'm scratching my head. plt_wrap is earlier than plt_now, which should be
>> impossible.
>
> impossible due to guarantees made
Package: src:linux
Version: 3.2.32-1
Severity: important
I ran apt-get update && apt-get dist-upgrade, which upgraded my kernel image &
initrd
now, when running update-initramfs -u either manually or when a package post
installation script calls it, I get the following:
michael@tablet:~$ sudo up
On Wed, 2012-11-07 at 17:40 +, Keir Fraser wrote:
> On 07/11/2012 13:22, "Ian Campbell" wrote:
>
> >>> (XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306
> >>> now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5
> >>> plt_stamp64=15b800366a5 plt_mask= tsc=e3839fd23854
On 08/11/2012 09:39, "Jan Beulich" wrote:
> (XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306
> now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5
> plt_stamp64=15b800366a5 plt_mask= tsc=e3839fd23854
> tsc_stamp=e3839fcb0273
(below is the compl
>>> On 07.11.12 at 18:40, Keir Fraser wrote:
> On 07/11/2012 13:22, "Ian Campbell" wrote:
>
(XEN) XXX plt_overflow: plt_now=5ece12d34128 plt_wrap=5ece12d09306
now=5ece12d16292 old_stamp=35c7c new_stamp=800366a5
plt_stamp64=15b800366a5 plt_mask= tsc=e3839fd23854
tsc_st
Hello,
On Thu, Nov 08, 2012 at 09:51:57AM +0100, Helmut Grohne wrote:
> So I had a further look into the dropbear initramfs issue. The code
> where the breakage occurs is dropbear's hook:
>
> | LIBC_DIR=$(ldd /usr/sbin/dropbear | sed -n -e 's,.* =>
> \(/lib.*\)/libc\.so\..*,\1,p')
> | for so in
So I had a further look into the dropbear initramfs issue. The code
where the breakage occurs is dropbear's hook:
| LIBC_DIR=$(ldd /usr/sbin/dropbear | sed -n -e 's,.* =>
\(/lib.*\)/libc\.so\..*,\1,p')
| for so in $(find "${LIBC_DIR}" -name 'libnss_compat*'); do
| copy_exec "${so}" "${LIBC_
38 matches
Mail list logo
