Bug#698917: [wheezy] cpu overheat and shutdown after suspend/resume cycle on Thinkpad T410
Florian Lohoff wrote: Opened a bug in the Kernel Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53101 Thanks! If I have any more questions, I'll ask them upstream. Ciao, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130128091024.GA3184@elie.Belkin
Bug#660425: Possible bugg in linux-image-3.2.0-0.bpo.4-amd64 (resent)
Thanks Ben, not sure how I missed 660425 the first time around. On Wed, 2013-01-23 at 14:50 +, Ben Hutchings wrote: On Tue, 2013-01-22 at 10:15 +0100, Mattias Eriksson wrote: Hi! I have switched back to the current stable kernel in squeeze, 2.6.32-46, since I need the machine to be up and running. And now it is just as stable as it was before. Even though I have never had any real issues using xen and VIA nano (64bit), the CPU is officially not supported by xen, as far as I can see: (XEN) Domain heap initialised (XEN) CPU: Vendor unknown, using generic init. (XEN) CPU: Your system may be unstable. (XEN) Processor #0 6:15 APIC version 20 So, I think there are to many uncertainties for me to dig into this further. [...] Yes, there may be quirks and bugs in VIA/Centaur processors that Xen should handle (which I couldn't find any documentation about). There was a bit of work done to support VIA stuff in, I think, the 4.2 release. I think it is probably not relevant to this specific EFLAGS.AC issue, although it may cause other problems of course. However: http://bugs.debian.org/660425 is a report of an alignment check under Xen while running Linux 2.6.32, and Jonathan Nieder found (message #17) more reports of this - on Intel and AMD processors. In all these cases (and yours) the AC flag is shown as enabled, so alignment checks should be expected. The connection to Xen is this: the AC flag can be set by any program, but the processor ignores it when running code at the maximum privilege level. So normally the kernel is not affected, but under Xen it is running at lower privilege and therefore it is affected. Xen has to clear the AC flag whenever it switches from user mode to a (PV) guest kernel. A bug of this type was fixed in the 4.0.0-rc9 timeframe, but that is before the version of Xen being used here. It's interesting that the kernel version appears to be a relevant factor, but I expect it is simply exposing a hypervisor bug. It seems that the new SMAP (Supervisor Mode Access Prevention) CPU feature reuses the EFLAGS.AC bit, that might explain why we are seeing this bit set in kernel mode with newer kernels. However it looks like this was added in 3.7 and I can't see it backported in either the kernel.org 3.2.y stable kernels or Debian's patch queue. SMEP is in 3.2 but I don't think that involves EFLAGS.AC. It would be great if you could try the 3.2.0 kernel again with the nosmap kernel option though. I don't think the guest kernel itself needs to be aware of this because there is never a direct transition from user mode to kernel mode. Agreed, with a 64-bit PV kernel you always have to pass through the hypervisor when transitioning from user to supervisor mode (which both run in Ring 3 under Xen) Ian. -- Ian Campbell Current Noise: Isis - Threshold Of Transformation Be incomprehensible. If they can't understand, they can't disagree. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1359367066.6559.23.ca...@zakaz.uk.xensource.com
Bug#696650: [PATCH v2] md: protect against crash upon fsync on ro array
Subject was: Re: fsync() on read-only RAID triggers BUG
On 27.01.2013 17:39, Christoph Hellwig wrote:
On Sat, Jan 26, 2013 at 07:44:40PM +, Ben Hutchings wrote:
I applied this on top of 3.2.37 and it certainly fixes the crash.
However I wonder whether fsync() should fail or should immediately
succeed. I don't know whether the installer expects it to succeed.
It should succeed.
O.K., then I hope Neil applies the attached patch. I've changed the
return value to success.
This is also something for linux-stable and should apply to many kernel
versions without an issue.
From fe0357344877c9b9cc623fd582a4e0670e448317 Mon Sep 17 00:00:00 2001
From: Sebastian Riemer sebastian.rie...@profitbricks.com
Date: Fri, 25 Jan 2013 12:46:59 +0100
Subject: [PATCH v2] md: protect against crash upon fsync on ro array
If an fsync occurrs on a read-only array, we need to send a
completion for the IO and may not increment the active IO count.
Otherwise, we hit a bug trace and can't stop the MD array anymore.
By advice of Christoph Hellwig we silently return success.
Cc: Christoph Hellwig h...@infradead.org
Cc: Ben Hutchings b...@decadent.org.uk
Cc: NeilBrown ne...@suse.de
Signed-off-by: Sebastian Riemer sebastian.rie...@profitbricks.com
Reported-by: Ben Hutchings b...@decadent.org.uk
---
drivers/md/md.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 3db3d1b..475e0be 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -322,6 +322,11 @@ static void md_make_request(struct request_queue *q,
struct bio *bio)
}
finish_wait(mddev-sb_wait, __wait);
}
+ if (mddev-ro == 1 unlikely(rw == WRITE)) {
+ rcu_read_unlock();
+ bio_endio(bio, 0);
+ return;
+ }
atomic_inc(mddev-active_io);
rcu_read_unlock();
--
1.7.1
Bug#699157: linux-image-3.2.0-4-amd64: mount -o remount, ro on bind mount causes source filesystem to become read-only
Package: src:linux Version: 3.2.35-2 Severity: normal Dear Maintainer, I'm experiencing what seems to be a kernel bug with read-only remounting of a bind mount (creating a read-only bind mount). After running the following commands, both /foo/dir_ro *and* /foo/dir become read-only: mount --bind /foo/dir /foo/dir_ro mount -o remount,ro /foo/dir_ro Running 'mount -o remount,rw /foo/dir' rectifies the situation, leaving it as I intended (/foo/dir writable, /foo/dir_ro read-only). Thanks, Zev Weiss -- Package-specific info: ** Version: Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.35-2 ** Command line: BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/vg--ssd-sysroot ro quiet ** Tainted: O (4096) * Out-of-tree module has been loaded. ** Kernel log: [3.010929] Console: switching to colour frame buffer device 240x75 [3.013438] fb0: nouveaufb frame buffer device [3.013440] drm: registered panic notifier [3.013445] [drm] Initialized nouveau 1.0.0 20120316 for :01:00.0 on minor 0 [3.799556] md: md0 stopped. [3.800607] md: bindsdb [3.800731] md: bindsde [3.807141] md: raid1 personality registered for level 1 [3.807458] bio: create slab bio-1 at 1 [3.807521] md/raid1:md0: active with 2 out of 2 mirrors [3.807541] md0: detected capacity change from 0 to 2000264560640 [3.835885] md0: unknown partition table [3.962862] md: md1 stopped. [3.965536] md: bindsdd [3.965706] md: bindsda [3.967957] md/raid1:md1: active with 2 out of 2 mirrors [3.967976] md1: detected capacity change from 0 to 500106674176 [4.024324] EXT4-fs (dm-0): re-mounted. Opts: (null) [4.031249] md1: unknown partition table [4.251852] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro,discard [4.295424] loop: module loaded [4.959331] Adding 4194300k swap on /dev/mapper/vg--ssd-swap. Priority:-1 extents:1 across:4194300k SS [6.045526] kjournald starting. Commit interval 5 seconds [6.045628] EXT3-fs (sdc1): using internal journal [6.045632] EXT3-fs (sdc1): mounted filesystem with ordered data mode [6.047893] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Opts: (null) [6.050170] EXT4-fs (dm-3): mounted filesystem with ordered data mode. Opts: (null) [6.122924] EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: (null) [6.236900] EXT4-fs (dm-7): mounted filesystem with ordered data mode. Opts: (null) [6.293508] kjournald starting. Commit interval 5 seconds [6.293634] EXT3-fs (dm-5): mounted filesystem with ordered data mode [6.331067] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: (null) [6.780483] r8169 :04:00.0: eth0: link down [6.780490] r8169 :04:00.0: eth0: link down [6.781506] ADDRCONF(NETDEV_UP): eth0: link is not ready [9.163430] r8169 :04:00.0: eth0: link up [9.164417] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 16.737732] RPC: Registered named UNIX socket transport module. [ 16.737736] RPC: Registered udp transport module. [ 16.737738] RPC: Registered tcp transport module. [ 16.737740] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 16.749189] FS-Cache: Loaded [ 16.759249] FS-Cache: Netfs 'nfs' registered for caching [ 16.768939] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 17.790334] ip_tables: (C) 2000-2006 Netfilter Core Team [ 17.822734] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [ 17.925057] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 18.898599] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory [ 18.898908] NFSD: starting 90-second grace period [ 20.112007] eth0: no IPv6 routers present [ 242.431813] Kprobes globally unoptimized [ 242.468323] stap_7a30e3695e76472eb616ead2970b485_4039: systemtap: 1.7/0.152, base: a057e000, memory: 14data/16text/1ctx/2058net/18alloc kb, probes: 1 [ 255.614619] stap_df243a220556068fca70eedb018891c_4194: systemtap: 1.7/0.152, base: a0587000, memory: 14data/16text/1ctx/2058net/18alloc kb, probes: 1 [ 337.753052] stap_7dc557923d2612917434539e96d25458_4407: systemtap: 1.7/0.152, base: a059, memory: 18data/16text/1ctx/2058net/18alloc kb, probes: 1 [ 5682.988021] usb 1-1.1: USB disconnect, device number 3 [ 5687.028095] usb 1-1.1: new low-speed USB device number 5 using ehci_hcd [ 5687.124839] usb 1-1.1: New USB device found, idVendor=046d, idProduct=c016 [ 5687.124843] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 5687.124846] usb 1-1.1: Product: Optical USB Mouse [ 5687.124849] usb 1-1.1: Manufacturer: Logitech [ 5687.127314] input: Logitech Optical USB Mouse as /devices/pci:00/:00:1a.7/usb1/1-1/1-1.1/1-1.1:1.0/input/input6 [ 5687.127474] generic-usb 0003:046D:C016.0004: input,hidraw0: USB HID v1.10 Mouse [Logitech Optical USB Mouse] on
Bug#696650: [PATCH v3] md: protect against crash upon fsync on ro array
On 28.01.2013 11:32, Sebastian Riemer wrote:
O.K., then I hope Neil applies the attached patch. I've changed the
return value to success.
This is also something for linux-stable and should apply to many kernel
versions without an issue.
I've tried to race with continuous fsyncs against continuous mdadm -o
/dev/md0; mdadm -w /dev/md0; in parallel but couldn't break it.
Therefore, no additional locking is required and this part can be put
directly before the RCU locking stuff and the suspended handling.
I've attached version 3 of the patch.
From fe0357344877c9b9cc623fd582a4e0670e448317 Mon Sep 17 00:00:00 2001
From: Sebastian Riemer sebastian.rie...@profitbricks.com
Date: Fri, 25 Jan 2013 12:46:59 +0100
Subject: [PATCH v3] md: protect against crash upon fsync on ro array
If an fsync occurrs on a read-only array, we need to send a
completion for the IO and may not increment the active IO count.
Otherwise, we hit a bug trace and can't stop the MD array anymore.
By advice of Christoph Hellwig we silently return success.
Cc: Christoph Hellwig h...@infradead.org
Cc: Ben Hutchings b...@decadent.org.uk
Cc: NeilBrown ne...@suse.de
Signed-off-by: Sebastian Riemer sebastian.rie...@profitbricks.com
Reported-by: Ben Hutchings b...@decadent.org.uk
---
drivers/md/md.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 3db3d1b..6ba20f7 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -307,6 +307,10 @@ static void md_make_request(struct request_queue *q,
struct bio *bio)
bio_io_error(bio);
return;
}
+ if (mddev-ro == 1 unlikely(rw == WRITE)) {
+ bio_endio(bio, 0);
+ return;
+ }
smp_rmb(); /* Ensure implications of 'active' are visible */
rcu_read_lock();
if (mddev-suspended) {
Bug#687442: My testresult so far
self-compiled version of http://people.debian.org/~jcristau/wheezy-drm34/ with headers uptime 1day 11 hours (24 hours running) tested: Intel(R) Core(TM) i5-3450 Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller 7 Series/C210 Series Chipset Family High Definition Audio Controller RTL8111/8168B PCI Express Gigabit Ethernet controller video-out: DVI OK multiple suspend-resume cycles OK virtualbox up/downs OK audio OK network OK no freezes probably unrelated problems: 1x no response to clicks of external mouse for 15+ sec. (psmouse serio1: logips2pp) will report back on problems
Bug#699091: linux-image-3.2.0-4-amd64: kernel BUG: Bad page map in process udevd
On Sun, 27 Jan 2013 14:10:49 +, Jules Villard wrote: On Sun, 27 Jan 2013 12:52:26 +, Ben Hutchings wrote: On Sun, 2013-01-27 at 12:37 +, Jules Villard wrote: Package: src:linux Version: 3.2.35-2 Severity: normal Dear Maintainer, I hit a few BUGs at the end of boot time (see dmesg). They do not seem to visibly affect the stability of the system. There's also a swap_free: Bad swap offset entry 7fffc4010a6aa0 in the mix... [...] Please use memtest86+ to test the memory in this system. No errors in 1 pass. I will test again more thoroughly tonight. No errors in 9 passes (9 hours) either. Jules -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130128130659.ga3...@roquette.roquette.dyndns.org
Bug#687442: [Backport] Use DRM/KMS subsystem from Linux 3.4 in wheezy
Le samedi 12 janvier 2013 à 21:54 +0100, Vincent Blut a écrit :
Le lundi 07 janvier 2013 à 23:55 +0100, Vincent Blut a écrit :
Le samedi 05 janvier 2013 à 17:25 +0100, Julien Cristau a écrit :
On Fri, Jan 4, 2013 at 17:13:35 +0100, Julien Cristau wrote:
http://people.debian.org/~jcristau/linux-image-3.2.0-4.drm-686-pae_3.2.35-3~jcristau.1_i386.deb
sha1sum 17980ee5bafc40bb4e7bf42576ce40ac81c75833
http://people.debian.org/~jcristau/linux-image-3.2.0-4.drm-amd64_3.2.35-3~jcristau.1_amd64.deb
sha1sum f6711fe6d0d924aab82ec82fe1a86102a69a8c32
Hi Julien et al.
I tested with an Asus UX31A (Ivybridge Mobile GT2, eDP1 display), using
2D and 3D drivers from Wheezy (respectively versions 2.19.0-6 and
8.0.5-3).
On the DE side, I used GNOME Shell and Cinnamon (both need 3D
acceleration).
On the kernel side, I used:
i915.i915_enable_rc6={0, 1, 3} → no issue (don't know if it worth to
test RC6pp)
i915.semaphores=1 → ditto
In order to stress the GPU, I played some video bits in 1080p mostly
using VAAPI, played video games (native and emulated), and the usual
glxgear to see if all went well, and that's a *success*, the kernel is
pretty stable (contrary to the raw 3.2 series which causes some
freezes on this system, but that's another story I need to
investigate ;-)).
Voilà, to me this kernel is in really good shape, so thank you Julien
for backporting this stuff!
TODO:
- Testing VGA and HDMI outputs
I tested the HDMI output on two external screens (TV and 'standard'
display). Suspending/resuming with external display attached shows no
regressions, as well as sound through HDMI, which is handled by
'drm/i915' IIRC.
To conclude, those 'HDMI output' tests have shown neither new bugs nor
regressions (at least on my system).
Cheers,
Vincent
- Testing my old GPUs to prevent regressions (Radeon X800XL and Nvidia
7600GS)
Hi,
Finally had time to test those old cards, as expected absolutely all
went well.
Concerned devices:
$ lspci -nnv | grep VGA
05:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD]
nee ATI R430 [Radeon X800 XL] (PCIe) [1002:554d] (prog-if 00 [VGA
controller])
$ lspci -nnv | grep VGA
05:00.0 VGA compatible controller [0300]: NVIDIA Corporation G73
[GeForce 7600 GS] [10de:0392] (rev a1) (prog-if 00 [VGA controller])
libdrm, 2D and 3D drivers from Wheezy.
Tested using glxgear, playing 720p videos (with Xvideo and Opengl video
output), playing some basic games, google earth…
Cheers,
Vincent
- Testing SNA (?)
- Advertising about this kernel (I found it haphazardly by diving in the
BTS)
Added
http://people.debian.org/~jcristau/linux-image-3.2.0-4.drm-486_3.2.35-3~jcristau.1_i386.deb
sha1sum 76f67adbed522f8e42216f8595c8b5d1699af9ec
Cheers,
Julien
Regards,
Vincent
PS: By the way if Greg KH tags a new longterm kernel, will there be a
chance to see the DRM subsystem backported in Wheezy or that's
definitely too invasive and we'll stay with 3.4 (I don't have any issue
with that, I'm just curious).
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1359380309.3709.12.camel@lamella
Processed: Re: Bug#699157: linux-image-3.2.0-4-amd64: mount -o remount, ro on bind mount causes source filesystem to become read-only
Processing control commands: reassign -1 mount Bug #699157 [src:linux] linux-image-3.2.0-4-amd64: mount -o remount, ro on bind mount causes source filesystem to become read-only Bug reassigned from package 'src:linux' to 'mount'. No longer marked as found in versions linux/3.2.35-2. Ignoring request to alter fixed versions of bug #699157 to the same values previously set -- 699157: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699157 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.b699157.135937938116549.transcr...@bugs.debian.org
Bug#699157: linux-image-3.2.0-4-amd64: mount -o remount, ro on bind mount causes source filesystem to become read-only
Control: reassign -1 mount On Mon, 2013-01-28 at 04:37 -0600, Zev Weiss wrote: Package: src:linux Version: 3.2.35-2 Severity: normal Dear Maintainer, I'm experiencing what seems to be a kernel bug with read-only remounting of a bind mount (creating a read-only bind mount). After running the following commands, both /foo/dir_ro *and* /foo/dir become read-only: mount --bind /foo/dir /foo/dir_ro mount -o remount,ro /foo/dir_ro Running 'mount -o remount,rw /foo/dir' rectifies the situation, leaving it as I intended (/foo/dir writable, /foo/dir_ro read-only). [...] A bind mount is an alias for the same mount, and shares its options. This is similar too: touch foo ln foo bar chmod a-r bar # affects foo as well, because it is the same file But somewhat confusingly, there is an entirely separate un-shared read-only flag, which can you set when creating a bind-mount or when remounting. The mount command maps the 'ro' option to one of these depending on context. This is documented in mount(8) thus: Note that behavior of the remount operation depends on the /etc/mtab file. The first command stores the 'bind' flag to the /etc/mtab file and the second command reads the flag from the file. If you have a system without the /etc/mtab file or if you explicitly define source and target for the remount command (then mount(8) does not read /etc/mtab), then you have to use bind flag (or option) for the remount command too. For example: mount --bind olddir newdir mount -o remount,ro,bind olddir newdir I'm reassigning this to the mount package: the documentation is not as clear as it could be, and I think it should provide explicit names for the two different flags. Ben. -- Ben Hutchings If more than one person is responsible for a bug, no one is at fault. signature.asc Description: This is a digitally signed message part
[bts-link] source package src:linux
# # 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 #698821 (http://bugs.debian.org/698821) # Bug title: linux-image-3.2.0-4-amd64: ARECA driver arcmsr is out of date - please update # * http://bugzilla.kernel.org/show_bug.cgi?id=52961 # * remote status changed: (?) - NEW usertags 698821 + status-NEW thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130128164014.17366.41658.btsl...@sonntag.debian.org
Updating processor microcode in stable (squeeze)
Please refer to the relevant history at the bottom of this email. Summary for debian-release: 1. We have AMD and Intel microcode update packages in Wheezy and also in stable-backports. These packages have been available for a reasonable amount of time (~two months for AMD, ~three months for Intel), without any relevant issues (i.e. they're field-tested). 2. Uptake of these packages was low, and only picked up a bit after an announcement to some Debian MLs. However, once they started being recommended by the linux-firmware-nonfree packages in Wheeze, there was an extreme increase of uptake, as far as popcon data can tell us[1][2][3]. 3. These packages fix very relevant, system-crash-class issues as well as feature issues (such as perf support, power management) for both Intel and AMD processors. The less tech-savy the user is, the higher the probability of these packages being useful to the user (due to lack of BIOS/EFI updates being applied). 4. The microcode packages in stable (squeeze) only cover Intel processors, and it is also very outdated. Just updating the intel-microcode package in squeeze would not address the issues of AMD users at all. 5. AMD microcode updates are not easily available in any other way than distro packages right now. AMD upstream said in LKML that they will sort it out by the time the next update needs to be published, and likely do it through the linux-firware.git tree now that amd64.org is no more. Therefore, I'd like to propose that the packages in debian-backports (iucode-tool, amd64-microcode, intel-microcode) be uploaded to stable-proposed-updates. This would add one package to contrib stable (iucode-tool), add one package to non-free stable (amd64-microcode), and update one package in non-free stable (intel-microcode). I'd also propose that the firmware-linux-nonfree package in stable be updated to recommends: intel-microcode | amd64-microcode. If this request is approved by the stable release manager, I'll rebuild the backport packages with a stable-compatible version before the upload. They will superseed the backported packages, but still sort before the wheezy packages to not cause issues with the upgrade path. Thank you! [1] http://packages.qa.debian.org/i/intel-microcode.html, http://qa.debian.org/popcon.php?package=intel-microcode [2] http://packages.qa.debian.org/a/amd64-microcode.html, http://qa.debian.org/popcon.php?package=amd64-microcode [3] http://packages.qa.debian.org/i/iucode-tool.html, http://qa.debian.org/popcon.php?package=iucode-tool On Thu, 24 Jan 2013, Ben Hutchings wrote: On Thu, 2013-01-24 at 01:00 -0200, Henrique de Moraes Holschuh wrote: On Wed, 23 Jan 2013, Ben Hutchings wrote: On Wed, Jan 23, 2013 at 11:15:37PM +0200, Touko Korpela wrote: When using squeeze system, with wheezy (backports) of kernel and firmware, recently firmware-linux started to recommend intel-microcode and amd64-microcode packages. I think that intel-microcode recommends can be versioned, so that it prefers reworked versions (1.20120606.1 or newer) instead of old squeeze version. I don't think a versioned Recommends will have the effect you're hoping for. Also if there have been important bug fixes to the microcode then they should be included in stable-updates, not just squeeze-backports. Ideally, we should get iucode-tool (which would be adding *new* package to stable, something that is extremely rarely done) and the new versions of amd64-microcode (also a new package for stable) and intel-microcode to stable-updates. I can certainly create an old-style intel-microcode package for stable-updates, and that will give non-broken hardware counters for stable Intel users [that run with a custom kernel, stable's doesn't support perf AFAIK] It does. and some nasty bugs removed. But AMD users would still run with microcode that screws up power management, has none/broken hardware counter support, and some nasty bugs that hit rarely. BTW, currently you cannot get AMD microcode updates from anywhere else other than the distros and the internet archive. Makes it somewhat more important to add the package to stable proper, IMHO. Should we take this to the stable release manager? Please do. Good, up-to-date packages *are* available in stable-backports, though. Sending word to the users to install those might make more sense and give better results, as people don't install these microcode packages by themselves. I've seen an absurd increase of popcon results for the two microcode packages since the Recommends was added to firmware-linux. Well, perhaps that can also be updated. -- 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
Bug#687442: Success with 3.2.0-4.drm-amd64 / nVidia GF106
I'd like to report success with my HP EliteBook 8560w sporting an nVidia GF106 video card and the 3.2.0-4.drm-amd64 kernel. The stock 3.2.35-2 kernel image results in a black screen once KMS kicks in and I've been following the linux-image trunk packages from experimental instead. The 3.2.35-3~jcristau.1 boots to a GDM login just fine and has survived several suspend/resume cycles. I have not yet tried an external monitor - won't be able to do so until this weekend. Thanks Julien! J. -- Every bug you find is the last one. This .sig brought to you by the letter N and the number 17 Product of the Republic of HuggieTag -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130128193024.gy27...@earth.li
Re: Updating processor microcode in stable (squeeze)
On Mon, Jan 28, 2013 at 03:07:58PM -0200, Henrique de Moraes Holschuh wrote: [...] 2. Uptake of these packages was low, and only picked up a bit after an announcement to some Debian MLs. However, once they started being recommended by the linux-firmware-nonfree packages in Wheeze, there was an extreme increase of uptake, as far as popcon data can tell us[1][2][3]. They are actually recommended by the firmware-linux metapackage. [...] I'd also propose that the firmware-linux-nonfree package in stable be updated to recommends: intel-microcode | amd64-microcode. [...] As there is no way to select the right one automatically, both packages must be recommended. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130128205138.gp13...@decadent.org.uk
Bug#699205: linux-image-3.7-trunk-amd64: ps, pgrep and pkill segfault after upgrade from 3.7.1-1~experimental.2 to 3.7.3-1~experimental.1
Package: src:linux Version: 3.7.3-1~experimental.1 Severity: important Dear Maintainer, after updating the linux-image-3.7-trunk-amd64 from 3.7.1-1~experimental.2 to 3.7.3-1~experimental.1 today and rebooting, the tools ps, pgrep and pkill (package procps) are always segfaulting: === Begin === sascha.silbe@twin:~$ uname -r 3.7-trunk-amd64 sascha.silbe@twin:~$ ps Signal 11 (SEGV) caught by ps (procps-ng version 3.3.3). ps:display.c:59: please report this bug sascha.silbe@twin:~$ pgrep scdaemon Segmentation fault sascha.silbe@twin:~$ pkill scdaemon Segmentation fault sascha.silbe@twin:~$ apt-cache policy linux-image-3.7-trunk-amd64 linux-image-3.7-trunk-amd64: Installed: 3.7.3-1~experimental.1 Candidate: 3.7.3-1~experimental.1 Version table: *** 3.7.3-1~experimental.1 0 1 http://ftp.de.debian.org/debian/ experimental/main amd64 Packages 100 /var/lib/dpkg/status sascha.silbe@twin:~$ grep linux-image-3.7-trunk-amd64 /var/log/dpkg.log 2013-01-06 20:34:07 install linux-image-3.7-trunk-amd64:amd64 none 3.7.1-1~experimental.2 2013-01-06 20:34:07 status half-installed linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 2013-01-06 20:34:07 status half-installed linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 2013-01-06 20:34:38 status unpacked linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 2013-01-06 20:34:38 status unpacked linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 2013-01-06 20:34:39 configure linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 none 2013-01-06 20:34:39 status unpacked linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 2013-01-06 20:34:39 status half-configured linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 2013-01-06 20:36:22 status installed linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 2013-01-28 17:17:20 upgrade linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 3.7.3-1~experimental.1 2013-01-28 17:17:20 status half-configured linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 2013-01-28 17:17:20 status unpacked linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 2013-01-28 17:17:20 status half-installed linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 2013-01-28 17:17:21 status half-installed linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 2013-01-28 17:17:56 status half-installed linux-image-3.7-trunk-amd64:amd64 3.7.1-1~experimental.2 2013-01-28 17:17:56 status unpacked linux-image-3.7-trunk-amd64:amd64 3.7.3-1~experimental.1 2013-01-28 17:17:56 status unpacked linux-image-3.7-trunk-amd64:amd64 3.7.3-1~experimental.1 2013-01-28 17:17:57 configure linux-image-3.7-trunk-amd64:amd64 3.7.3-1~experimental.1 none 2013-01-28 17:17:57 status unpacked linux-image-3.7-trunk-amd64:amd64 3.7.3-1~experimental.1 2013-01-28 17:17:57 status half-configured linux-image-3.7-trunk-amd64:amd64 3.7.3-1~experimental.1 2013-01-28 17:18:14 status installed linux-image-3.7-trunk-amd64:amd64 3.7.3-1~experimental.1 sascha.silbe@twin:~$ === End === This may well be a bug in procps triggered by an API change (i.e. change of format in /proc files), but I wouldn't expect such an API change from an update within the kernel.org stable release series, so I'm filing this against the kernel package, rather than procps. Feel free to reassign or split the ticket. I'll try to provide a backtrace at the end of the week if noone else can reproduce this in the meantime; debugging this issue is a pain as it requires reboots, especially since the procps test suite runs (and fails) despite 'nocheck' in DEB_BUILD_OPTIONS. A pre-built -dbg package would have been nice. I wonder what got of the Squeeze release goal Automatic creation of debug packages for the entire archive... -- Package-specific info: ** Version: Linux version 3.7-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Debian 3.7.3-1~experimental.1 ** Command line: BOOT_IMAGE=/vmlinuz-3.7-trunk-amd64 root=/dev/mapper/twin_vg-wheezy--root ro rootflags=data=journal usbcore.autosuspend=1 snd_hda_intel.power_save=1 resume=/dev/mapper/dmcrypt-swap-ssd quiet ** Not tainted ** Kernel log: [ 59.628580] WARNING! power/level is deprecated; use power/control instead [ 59.631595] kvm: Nested Virtualization enabled [ 59.631599] kvm: Nested Paging enabled [ 59.647230] [drm] ib test on ring 0 succeeded in 0 usecs [ 59.648314] [drm] Radeon Display Connectors [ 59.648316] [drm] Connector 0: [ 59.648318] [drm] HDMI-A-1 [ 59.648319] [drm] HPD1 [ 59.648322] [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c [ 59.648323] [drm] Encoders: [ 59.648325] [drm] DFP1: INTERNAL_UNIPHY2 [ 59.648326] [drm] Connector 1: [ 59.648327] [drm] VGA-1 [ 59.648329] [drm] HPD2 [ 59.648330] [drm] DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c [ 59.648331] [drm] Encoders: [ 59.648332] [drm] CRT1: INTERNAL_UNIPHY2 [ 59.648333]
Bug#699205: linux-image-3.7-trunk-amd64: ps, pgrep and pkill segfault after upgrade from 3.7.1-1~experimental.2 to 3.7.3-1~experimental.1
Hi Sascha, Sascha Silbe wrote: after updating the linux-image-3.7-trunk-amd64 from 3.7.1-1~experimental.2 to 3.7.3-1~experimental.1 today and rebooting, the tools ps, pgrep and pkill (package procps) are always segfaulting: Just to check: if you downgrade to 3.7.1 again, do the segfaults go away? (Historical versions of Debian packages are available from http://snapshot.debian.org) [...] I'll try to provide a backtrace at the end of the week if noone else can reproduce this in the meantime; debugging this issue is a pain as it requires reboots, especially since the procps test suite runs (and fails) despite 'nocheck' in DEB_BUILD_OPTIONS. Sounds like http://bugs.debian.org/656508 A pre-built -dbg package would have been nice. Sounds worth a separate report. :) I wonder what got of the Squeeze release goal Automatic creation of debug packages for the entire archive... I know that for my library package (liblzma) I haven't bothered but would be happy to take care of it if I knew there were a push for this systemwide. Might be worth starting a discussion on debian-policy@. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130128233147.gg7...@google.com
Processed: your mail
Processing commands for cont...@bugs.debian.org:
unarchive 611954
Bug #611954 {Done: Ben Hutchings b...@decadent.org.uk} [firmware-realtek]
installation-reports: broken installation on RTL8111-8168B
Unarchived Bug 611954
reopen 611954 !
Bug #611954 {Done: Ben Hutchings b...@decadent.org.uk} [firmware-realtek]
installation-reports: broken installation on RTL8111-8168B
Bug reopened
Changed Bug submitter to 'Lars-Ivar Hesselberg Simonsen
larsi...@samfundet.no' from 'Norbert Preining prein...@logic.at'
Ignoring request to alter fixed versions of bug #611954 to the same values
previously set
--
Stopping processing here.
Please contact me if you need assistance.
--
611954: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611954
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/handler.s.c.13594177937810.transcr...@bugs.debian.org
Bug#611954: installation-reports: broken installation on RTL8111-8168B
I have recently recreated this bug when trying to netinstall wheezy from pxe. DHCP fails when trying to get ip-address during install. This applies to squeeze as well as wheezy. DHCP works during installation for lenny. -- System information: Debian Release: 7.0 Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.35-2 x86_64 libc6 Version: 2.13-37 -- Hardware information: Motherboard (from dmidecode): ASUSTeK P-P5N9300 Ethernet controller: (from lspci): Realtek RTL8111/8168B (rev2) -- Lars-Ivar Hesselberg Simonsen ITK, Samfundet -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130129010359.gg28...@samfundet.no
Bug#696650: [PATCH v3] md: protect against crash upon fsync on ro array
On Mon, 2013-01-28 at 13:39 +0100, Sebastian Riemer wrote:
On 28.01.2013 11:32, Sebastian Riemer wrote:
O.K., then I hope Neil applies the attached patch. I've changed the
return value to success.
This is also something for linux-stable and should apply to many kernel
versions without an issue.
I've tried to race with continuous fsyncs against continuous mdadm -o
/dev/md0; mdadm -w /dev/md0; in parallel but couldn't break it.
Therefore, no additional locking is required and this part can be put
directly before the RCU locking stuff and the suspended handling.
I've attached version 3 of the patch.
From fe0357344877c9b9cc623fd582a4e0670e448317 Mon Sep 17 00:00:00 2001
From: Sebastian Riemer sebastian.rie...@profitbricks.com
Date: Fri, 25 Jan 2013 12:46:59 +0100
Subject: [PATCH v3] md: protect against crash upon fsync on ro array
If an fsync occurrs on a read-only array, we need to send a
completion for the IO and may not increment the active IO count.
Otherwise, we hit a bug trace and can't stop the MD array anymore.
By advice of Christoph Hellwig we silently return success.
Cc: Christoph Hellwig h...@infradead.org
Cc: Ben Hutchings b...@decadent.org.uk
Cc: NeilBrown ne...@suse.de
Signed-off-by: Sebastian Riemer sebastian.rie...@profitbricks.com
Reported-by: Ben Hutchings b...@decadent.org.uk
---
drivers/md/md.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/md/md.c b/drivers/md/md.c
index 3db3d1b..6ba20f7 100644
--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -307,6 +307,10 @@ static void md_make_request(struct request_queue
*q, struct bio *bio)
bio_io_error(bio);
return;
}
+ if (mddev-ro == 1 unlikely(rw == WRITE)) {
+ bio_endio(bio, 0);
+ return;
+ }
smp_rmb(); /* Ensure implications of 'active' are visible */
rcu_read_lock();
if (mddev-suspended) {
I'm slightly uneasy about returning 0 for all writes to a read-only
deivce, because if someone ever fails to check the read-only flag
elsewhere this could turn into silent data loss. Does this work:
BUG_ON(bio_segments(bio));
Or should it be:
bio_endio(bio, bio_segments(bio) == 0 ? 0 : -EROFS);
to make the error survivable?
Ben.
--
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.
signature.asc
Description: This is a digitally signed message part
