Re: [Xen-devel] Debian Kernel: Xen-fb-frontend as a module?

2014-09-24 Thread David Vrabel
On 24/09/14 11:23, Stefano Stabellini wrote:
 On Tue, 23 Sep 2014, Konrad Rzeszutek Wilk wrote:
 On Tue, Sep 23, 2014 at 04:57:26PM +0100, Ian Campbell wrote:
 On Tue, 2014-09-23 at 16:43 +0100, David Vrabel wrote:
 On 23/09/14 15:30, Ian Campbell wrote:
 create !
 title it 30s delay loading xenfb driver on some systems
 owner it Konrad Rzeszutek Wilk konrad.w...@oracle.com
 thanks

 Hi James,

 Some of the other Xen devs were discussing an issue which sounded
 awfully similar to this one, so I am copying the xen-devel list and
 creating a Xen bug to track the issue, please CC xen-devel (no need to
 subscribe but you may be moderated the first time), since the tracker
 slurps mails from the list.

 I'm not sure of the details of the other issue but it involved
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b1a3b1c8a8d963424c4699efa64dd8986b2f76d7
  hopefully Konrad or one of the others will follow up.

 That was with an HVM guest running under Xen 4.1 in which this
 guest config was used:

 vfb = ['type=vnc,vncunused=1,vnclisten=0.0.0.0']

 Xend would create an XenStore keys for the PV framebuffer and also making
 sure that QEMU VGA driver was running. The end result was that the guest
 would boot up to Xorg VGA driver, but the frame buffer console (so from
 the moment GRUB2 started Linux up to Xorg) would try to use the xen-fbfront.

 And since this is HVM guest and VNCviewer was slurping contents from the
 VGA buffer - which was not used at all - we wouldn't get anything.

 Reverting the above patch fixed the issue.
 
 If you have a vfb line in your config file, aren't you actually
 explicitly requesting a vfb frontend/backend pair?
 XenD is just doing what the user asked him to do, I wouldn't call this a
 bug.
 
 What is strange is that given that there is no running vfb backend for
 HVM guests in a regular Xen 4.1 installation, xen-fbfront could never
 reach the connected state (4 on xenstore): so why is Linux trying to
 use vfb when the frontend is not even connected?
 
 The reason is that xenfb_probe calls register_framebuffer and
 xenfb_make_preferred_console too early, before even knowing if the
 backend is alive.
 
 I would move the register_framebuffer and xenfb_make_preferred_console
 calls in xenfb_backend_changed, case XenbusStateConnected. That should
 fix it.

I don't think that will help.  Registering the frontend driver will
still wait for CONNECTED, regardless of whether the frame buffer will
actually be used.

David


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54229ccb.5000...@citrix.com



Re: [Xen-devel] Debian Kernel: Xen-fb-frontend as a module?

2014-09-24 Thread Stefano Stabellini
On Wed, 24 Sep 2014, David Vrabel wrote:
 On 24/09/14 11:23, Stefano Stabellini wrote:
  On Tue, 23 Sep 2014, Konrad Rzeszutek Wilk wrote:
  On Tue, Sep 23, 2014 at 04:57:26PM +0100, Ian Campbell wrote:
  On Tue, 2014-09-23 at 16:43 +0100, David Vrabel wrote:
  On 23/09/14 15:30, Ian Campbell wrote:
  create !
  title it 30s delay loading xenfb driver on some systems
  owner it Konrad Rzeszutek Wilk konrad.w...@oracle.com
  thanks
 
  Hi James,
 
  Some of the other Xen devs were discussing an issue which sounded
  awfully similar to this one, so I am copying the xen-devel list and
  creating a Xen bug to track the issue, please CC xen-devel (no need to
  subscribe but you may be moderated the first time), since the tracker
  slurps mails from the list.
 
  I'm not sure of the details of the other issue but it involved
  http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b1a3b1c8a8d963424c4699efa64dd8986b2f76d7
   hopefully Konrad or one of the others will follow up.
 
  That was with an HVM guest running under Xen 4.1 in which this
  guest config was used:
 
  vfb = ['type=vnc,vncunused=1,vnclisten=0.0.0.0']
 
  Xend would create an XenStore keys for the PV framebuffer and also making
  sure that QEMU VGA driver was running. The end result was that the guest
  would boot up to Xorg VGA driver, but the frame buffer console (so from
  the moment GRUB2 started Linux up to Xorg) would try to use the 
  xen-fbfront.
 
  And since this is HVM guest and VNCviewer was slurping contents from the
  VGA buffer - which was not used at all - we wouldn't get anything.
 
  Reverting the above patch fixed the issue.
  
  If you have a vfb line in your config file, aren't you actually
  explicitly requesting a vfb frontend/backend pair?
  XenD is just doing what the user asked him to do, I wouldn't call this a
  bug.
  
  What is strange is that given that there is no running vfb backend for
  HVM guests in a regular Xen 4.1 installation, xen-fbfront could never
  reach the connected state (4 on xenstore): so why is Linux trying to
  use vfb when the frontend is not even connected?
  
  The reason is that xenfb_probe calls register_framebuffer and
  xenfb_make_preferred_console too early, before even knowing if the
  backend is alive.
  
  I would move the register_framebuffer and xenfb_make_preferred_console
  calls in xenfb_backend_changed, case XenbusStateConnected. That should
  fix it.
 
 I don't think that will help.  Registering the frontend driver will
 still wait for CONNECTED, regardless of whether the frame buffer will
 actually be used.

It will wait for a long time but then it should work.
The problem of the long wait time is a different matter. To solve that
couldn't we simply reduce the wait time?


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.02.1409241134270.22...@kaball.uk.xensource.com



Re: [Xen-devel] Debian Kernel: Xen-fb-frontend as a module?

2014-09-24 Thread Stefano Stabellini
On Tue, 23 Sep 2014, Konrad Rzeszutek Wilk wrote:
 On Tue, Sep 23, 2014 at 04:57:26PM +0100, Ian Campbell wrote:
  On Tue, 2014-09-23 at 16:43 +0100, David Vrabel wrote:
   On 23/09/14 15:30, Ian Campbell wrote:
create !
title it 30s delay loading xenfb driver on some systems
owner it Konrad Rzeszutek Wilk konrad.w...@oracle.com
thanks

Hi James,

Some of the other Xen devs were discussing an issue which sounded
awfully similar to this one, so I am copying the xen-devel list and
creating a Xen bug to track the issue, please CC xen-devel (no need to
subscribe but you may be moderated the first time), since the tracker
slurps mails from the list.

I'm not sure of the details of the other issue but it involved
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b1a3b1c8a8d963424c4699efa64dd8986b2f76d7
 hopefully Konrad or one of the others will follow up.
 
 That was with an HVM guest running under Xen 4.1 in which this
 guest config was used:
 
 vfb = ['type=vnc,vncunused=1,vnclisten=0.0.0.0']
 
 Xend would create an XenStore keys for the PV framebuffer and also making
 sure that QEMU VGA driver was running. The end result was that the guest
 would boot up to Xorg VGA driver, but the frame buffer console (so from
 the moment GRUB2 started Linux up to Xorg) would try to use the xen-fbfront.
 
 And since this is HVM guest and VNCviewer was slurping contents from the
 VGA buffer - which was not used at all - we wouldn't get anything.
 
 Reverting the above patch fixed the issue.

If you have a vfb line in your config file, aren't you actually
explicitly requesting a vfb frontend/backend pair?
XenD is just doing what the user asked him to do, I wouldn't call this a
bug.

What is strange is that given that there is no running vfb backend for
HVM guests in a regular Xen 4.1 installation, xen-fbfront could never
reach the connected state (4 on xenstore): so why is Linux trying to
use vfb when the frontend is not even connected?

The reason is that xenfb_probe calls register_framebuffer and
xenfb_make_preferred_console too early, before even knowing if the
backend is alive.

I would move the register_framebuffer and xenfb_make_preferred_console
calls in xenfb_backend_changed, case XenbusStateConnected. That should
fix it.




For xen-devel, the first two mails in this thread are
https://lists.debian.org/debian-kernel/2014/09/msg00229.html and 
https://lists.debian.org/debian-kernel/2014/09/msg00233.html
   
   The wait stuff for xenbus devices looks like pre-dates distros handling
   asynchronous devices with suitable initrds etc.
  
  Perhaps, but I think most distros still don't use rootwait by default so
  unless / turns up reasonably promptly (single digit seconds) the boot
  may fail.
  
   I think we need a command line configurable white list of device types
   to wait for.  The default should be (to match what was done historically):
   
   PV: vbd, vif, pci, vfb, vkbd.
   HVM: vbd, vif.
   
   I also think it should be possible to default (via a config option) to
   an empty white list.
  
  Irrespective of the above this seems like a reasonable enough idea to
  me.
 
 What about ARM?

On ARM (and on PV on HVM x86) we want vfb to work by default if the
xenstore keys are there.  But I don't think that it means we need to
wait 30 secs for it at boot.  What is a reasonable amount of time to
wait for on a slow and overcommitted system? Maybe 5 to 10 secs?


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.02.1409241106450.22...@kaball.uk.xensource.com



Re: [Xen-devel] Debian Kernel: Xen-fb-frontend as a module?

2014-09-24 Thread Ian Campbell
On Wed, 2014-09-24 at 11:23 +0100, Stefano Stabellini wrote:

 On ARM (and on PV on HVM x86) we want vfb to work by default if the
 xenstore keys are there.  But I don't think that it means we need to
 wait 30 secs for it at boot.  What is a reasonable amount of time to
 wait for on a slow and overcommitted system? Maybe 5 to 10 secs?

NB there are already two classes of wait. Non-essential
(xenbus_probe_frontend.c's wording) wait 30s essential wait for an
additional 270s (so 300s total).

Non-essential appears to be vfb and vkbd (but not mouse?). We could
certainly consider reducing the 30 (and increasing the 270 to
correspond).

Ian.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1411555438.1781.195.ca...@kazak.uk.xensource.com



Bug#762148: Fix intel_pstate kernel panic in wheezy, already done upstream

2014-09-24 Thread Ben Hutchings
Control: tag -1 - patch
Control: tag -1 moreinfo

On Thu, 2014-09-18 at 16:18 -0700, Jimmy Kaplowitz wrote:
 Package: linux-image-3.2.0-4-amd64
 Version: 3.2.60-1+deb7u3
 Severity: normal
 Tags: patch
 
 
 Hi kernel folks,
 
 
 The intel_pstate driver in wheezy
[...]

No such thing in 3.2, and we didn't backport it either.  Is there a
similar bug elsewhere?

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert Einstein


signature.asc
Description: This is a digitally signed message part


Bug#748577: [PATCH RESEND] x86: relocs: Make per_cpu_load_addr static

2014-09-24 Thread Ben Hutchings
per_cpu_load_addr is only used for 64-bit relocations, but is declared
in both configurations of relocs.c - with different types.  This has
undefined behaviour in general.  GNU ld is documented to use the
larger size in this case, but other tools may differ and some warn
about this.

References: https://bugs.debian.org/748577
Reported-by: Michael Tautschnig m...@debian.org
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
 arch/x86/tools/relocs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
index bbb1d22..a5efb21 100644
--- a/arch/x86/tools/relocs.c
+++ b/arch/x86/tools/relocs.c
@@ -695,7 +695,7 @@ static void walk_relocs(int (*process)(struct section *sec, 
Elf_Rel *rel,
  *
  */
 static int per_cpu_shndx   = -1;
-Elf_Addr per_cpu_load_addr;
+static Elf_Addr per_cpu_load_addr;
 
 static void percpu_init(void)
 {


-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert Einstein


signature.asc
Description: This is a digitally signed message part


Bug#727041: marked as done (kernel 3.11 freezes when via velocity interface comes up)

2014-09-24 Thread Debian Bug Tracking System
Your message dated Wed, 24 Sep 2014 13:15:38 +0100
with message-id 1411560938.3659.21.ca...@decadent.org.uk
and subject line Re: kernel 3.11-1 freezes when via velocity interface comes up
has caused the Debian Bug report #727041,
regarding kernel 3.11 freezes when via velocity interface comes up
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
727041: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727041
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: src:linux
Version: 3.11.5-1
Severity: grave
Tags: patch

Subject kind of says it all. My system freezes solidly as soon as I ifup the
network interface. Please see e.g.
http://www.spinics.net/lists/netdev/msg251287.html for more details.

Attached patch from mentioned URL fixes the problem for me. I haven't checked
if kernel devs used the same patch, though.

Michael
Description: prevent freeze in velocity based networking
Origin: http://www.spinics.net/lists/netdev/msg251312.html

--- linux-3.11.5.orig/drivers/net/ethernet/via/via-velocity.c
+++ linux-3.11.5/drivers/net/ethernet/via/via-velocity.c
@@ -2172,14 +2172,12 @@ static int velocity_poll(struct napi_str
 	unsigned int rx_done;
 	unsigned long flags;
 
-	spin_lock_irqsave(vptr-lock, flags);
 	/*
 	 * Do rx and tx twice for performance (taken from the VIA
 	 * out-of-tree driver).
 	 */
-	rx_done = velocity_rx_srv(vptr, budget / 2);
-	velocity_tx_srv(vptr);
-	rx_done += velocity_rx_srv(vptr, budget - rx_done);
+	rx_done = velocity_rx_srv(vptr, budget);
+	spin_lock_irqsave(vptr-lock, flags);
 	velocity_tx_srv(vptr);
 
 	/* If budget not fully consumed, exit the polling mode */
---End Message---
---BeginMessage---
Version: 3.13~rc6-1~exp1

On Mon, 2013-10-21 at 21:26 +0200, Michael Meskes wrote:
 Package: src:linux
 Version: 3.11.5-1
 Severity: grave
 Tags: patch
 
 Subject kind of says it all. My system freezes solidly as soon as I ifup the
 network interface. Please see e.g.
 http://www.spinics.net/lists/netdev/msg251287.html for more details.
 
 Attached patch from mentioned URL fixes the problem for me. I haven't checked
 if kernel devs used the same patch, though.

This was applied upstream in 3.13-rc3.

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert Einstein


signature.asc
Description: This is a digitally signed message part
---End Message---


Processed: Re: Bug#762148: Fix intel_pstate kernel panic in wheezy, already done upstream

2014-09-24 Thread Debian Bug Tracking System
Processing control commands:

 tag -1 - patch
Bug #762148 [linux-image-3.2.0-4-amd64] Fix intel_pstate kernel panic in 
wheezy, already done upstream
Removed tag(s) patch.
 tag -1 moreinfo
Bug #762148 [linux-image-3.2.0-4-amd64] Fix intel_pstate kernel panic in 
wheezy, already done upstream
Added tag(s) moreinfo.

-- 
762148: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762148
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: 
https://lists.debian.org/handler.s.b762148.141156093130279.transcr...@bugs.debian.org



Processed: notfound 759389 in 3.16-1~exp1

2014-09-24 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 # not a bug
 notfound 759389 3.16-1~exp1
Bug #759389 [src:linux] linux: ppc64el: switch to vmlinuz (from vmlinux)
No longer marked as found in versions linux/3.16-1~exp1.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
759389: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759389
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: 
https://lists.debian.org/handler.s.c.1411561334875.transcr...@bugs.debian.org



Processed: tagging 762390

2014-09-24 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 tags 762390 + pending
Bug #762390 [linux] Patch for hppa arch
Added tag(s) pending.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
762390: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762390
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: 
https://lists.debian.org/handler.s.c.1411561282566.transcr...@bugs.debian.org



Bug#745147: WARNING on removal of SCSI device which is still in use

2014-09-24 Thread Ben Hutchings
On Wed, 2014-09-24 at 13:38 +0100, Ben Hutchings wrote:
 Version: 3.15~rc5-1~exp1
 
 This is supposed to be fixed in 3.15-rc1 by:
 
 commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59
 Author: James Bottomley jbottom...@parallels.com
 Date:   Tue Jan 21 07:00:50 2014 -0800
 
 [SCSI] fix our current target reap infrastructure

plus:

commit f2495e228fce9f9cec84367547813cbb0d6db15a
Author: James Bottomley jbottom...@parallels.com
Date:   Tue Jan 21 07:01:41 2014 -0800

[SCSI] dual scan thread bug fix

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert Einstein


signature.asc
Description: This is a digitally signed message part


Processed: closing 750925

2014-09-24 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 close 750925
Bug #750925 [linux] make deb-pkg produces a non-installable package on the 
s390x architecture
Marked Bug as done
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
750925: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750925
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: 
https://lists.debian.org/handler.s.c.14115617013419.transcr...@bugs.debian.org



Processed: tagging 748398

2014-09-24 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 tags 748398 + pending
Bug #748398 [src:linux] linux: Please compile FB drivers on powerpc as modules
Added tag(s) pending.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
748398: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748398
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: 
https://lists.debian.org/handler.s.c.14115618484256.transcr...@bugs.debian.org



Bug#747467: marked as done (linux-image-3.14-1-amd64: backlight control broken on dell xps13)

2014-09-24 Thread Debian Bug Tracking System
Your message dated Wed, 24 Sep 2014 13:33:20 +0100
with message-id 1411562000.3659.24.ca...@decadent.org.uk
and subject line Re: linux-image-3.14-1-amd64: backlight control broken on dell 
xps13
has caused the Debian Bug report #747467,
regarding linux-image-3.14-1-amd64: backlight control broken on dell xps13
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
747467: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747467
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: src:linux
Version: 3.14.2-1
Severity: normal
Tags: patch

Dear Maintainer,

Hello,

Kernel 3.14 contains a regression wrt backlight control on the Dell XPS13
laptops.
Details can be found on http://bugs.freedesktop.org/show_bug.cgi?id=76276

That bugzilla link also contains fixes: either revert a change or apply
another patch on top.

Would it be possible to consider either for 3.14?

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: XPS L322X
product_version:
chassis_vendor: Dell Inc.
chassis_version: 0.1
bios_vendor: Dell Inc.
bios_version: A10
board_vendor: Dell Inc.
board_name: 0WW7PG
board_version: A00

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM
Controller [8086:0154] (rev 09)
Subsystem: Dell Device [1028:058b]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort+ SERR- PERR- INTx-
Latency: 0
Capabilities: access denied

00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core
processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA
controller])
Subsystem: Dell Device [1028:058b]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 44
Region 0: Memory at d000 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at c000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 2000 [size=64]
Expansion ROM at unassigned [disabled]
Capabilities: access denied
Kernel driver in use: i915

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30
[XHCI])
Subsystem: Dell Device [1028:058b]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 40
Region 0: Memory at d050 (64-bit, non-prefetchable) [size=64K]
Capabilities: access denied
Kernel driver in use: xhci_hcd

00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210
Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
Subsystem: Dell Device [1028:058b]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 42
Region 0: Memory at d0515000 (64-bit, non-prefetchable) [size=16]
Capabilities: access denied
Kernel driver in use: mei_me

00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series
Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
(prog-if 20 [EHCI])
Subsystem: Dell Device [1028:058b]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort- MAbort- SERR- PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 16
Region 0: Memory at d051a000 (32-bit, non-prefetchable) [size=1K]
Capabilities: access denied
Kernel driver in use: ehci-pci

00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset
Family High Definition Audio Controller [8086:1e20] (rev 04)
Subsystem: Dell Device [1028:058b]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 45
Region 0: Memory at 

Bug#745147: marked as done (WARNING on removal of SCSI device which is still in use)

2014-09-24 Thread Debian Bug Tracking System
Your message dated Wed, 24 Sep 2014 13:38:19 +0100
with message-id 1411562299.3659.26.ca...@decadent.org.uk
and subject line Re: WARNING on removal of SCSI device which is still in use
has caused the Debian Bug report #745147,
regarding WARNING on removal of SCSI device which is still in use
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
745147: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745147
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: src:linux
Version: 3.13.7-1
Severity: important



-- Package-specific info:
** Version:
Linux version 3.13-1-amd64 (debian-kernel@lists.debian.org) (gcc version 4.8.2 
(Debian 4.8.2-16) ) #1 SMP Debian 3.13.7-1 (2014-03-25)

** Command line:
BOOT_IMAGE=/vmlinuz-3.13-1-amd64 root=/dev/mapper/pc-root ro

** Tainted: PWO (4609)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.

** Kernel log:
Apr 17 09:42:12 teenymac kernel: [1202533.365163] sr0: scsi3-mmc drive: 24x/24x 
writer cd/rw xa/form2 cdda tray
Apr 17 09:42:12 teenymac kernel: [1202533.365187] cdrom: Uniform CD-ROM driver 
Revision: 3.20
Apr 17 09:42:12 teenymac kernel: [1202533.365355] [ cut here 
]
Apr 17 09:42:12 teenymac kernel: [1202533.365363] WARNING: CPU: 0 PID: 14387 at 
/build/linux-oxWk_8/linux-3.13.7/block/blk-core.c:457 
blk_queue_bypass_end+0x54/0x60()
Apr 17 09:42:12 teenymac kernel: [1202533.365364] Modules linked in: sr_mod(+) 
cdrom nls_cp437 vfat fat nls_utf8 isofs usb_storage b43 ctr ccm snd_seq_dummy 
adm1021 nouveau mxm_wmi wmi ttm drm_kms_helper drm i2c_algo_bit snd_hrtimer 
ip6table_filter ip6_tables iptable_filter ip_tables ebtable_nat ebtables 
x_tables parport_pc ppdev lp parport 8021q garp stp mrp cpufreq_stats 
speedstep_lib binfmt_misc cpufreq_userspace cpufreq_powersave 
cpufreq_conservative uinput nfsd auth_rpcgss oid_registry nfs_acl nfs lockd 
fscache sunrpc appletalk ipx p8023 p8022 psnap llc rose netrom ax25 tun 
firewire_sbp2 loop fuse arc4 snd_usb_audio bcma mac80211 snd_usbmidi_lib 
snd_hda_codec_realtek snd_seq_midi cfg80211 uvcvideo snd_seq_midi_event 
videobuf2_vmalloc videobuf2_memops ftdi_sio iTCO_wdt iTCO_vendor_support 
snd_hda_intel rfkill snd_hda_codec joydev videobuf2_core snd_rawmidi snd_hwdep 
applesmc usbserial snd_pcm hid_appleir hid_generic evdev input_polldev lpc_ich 
mfd_core i2c_i801 videodev media snd
 _page_alloc i2c_core usbhid hid
Apr 17 09:42:12 teenymac kernel: coretemp acpi_cpufreq rng_core processor 
snd_seq snd_seq_device snd_timer apple_bl snd kvm_intel kvm video thermal_sys 
soundcore button ext4 crc16 mbcache jbd2 dm_mod sd_mod crc_t10dif 
crct10dif_common ata_generic firewire_ohci ata_piix firewire_core crc_itu_t 
ehci_pci uhci_hcd ehci_hcd ssb mmc_core pcmcia pcmcia_core libata scsi_mod 
usbcore usb_common [last unloaded: cdrom]
Apr 17 09:42:12 teenymac kernel: [1202533.365442] CPU: 0 PID: 14387 Comm: 
modprobe Tainted: PW  O 3.13-1-amd64 #1 Debian 3.13.7-1
Apr 17 09:42:12 teenymac kernel: [1202533.365443] Hardware name: Apple 
Computer, Inc. iMac6,1/Mac-F4218FC8, BIOS IM61.88Z.0093.B07.0706281250 
06/28/07
Apr 17 09:42:12 teenymac kernel: [1202533.365446]  0009 
814a1327  8105ba72
Apr 17 09:42:12 teenymac kernel: [1202533.365449]  88003646b1c0 
88004081c880 88004081c800 88004081c870
Apr 17 09:42:12 teenymac kernel: [1202533.365452]  88004081c80c 
812497b4 88003646b1c0 8124cd8d
Apr 17 09:42:12 teenymac kernel: [1202533.365455] Call Trace:
Apr 17 09:42:12 teenymac kernel: [1202533.365461]  [814a1327] ? 
dump_stack+0x41/0x51
Apr 17 09:42:12 teenymac kernel: [1202533.365464]  [8105ba72] ? 
warn_slowpath_common+0x72/0x90
Apr 17 09:42:12 teenymac kernel: [1202533.365467]  [812497b4] ? 
blk_queue_bypass_end+0x54/0x60
Apr 17 09:42:12 teenymac kernel: [1202533.365471]  [8124cd8d] ? 
blk_register_queue+0x2d/0x130
Apr 17 09:42:12 teenymac kernel: [1202533.365474]  [81256ef9] ? 
add_disk+0x1b9/0x490
Apr 17 09:42:12 teenymac kernel: [1202533.365480]  [a002f24c] ? 
sr_probe+0x4bc/0x510 [sr_mod]
Apr 17 09:42:12 teenymac kernel: [1202533.365485]  [81355058] ? 
driver_probe_device+0x68/0x220
Apr 17 09:42:12 teenymac kernel: [1202533.365487]  [813552cb] ? 
__driver_attach+0x7b/0x80
Apr 17 09:42:12 teenymac kernel: [1202533.365490]  [81355250] ? 
__device_attach+0x40/0x40
Apr 17 09:42:12 teenymac kernel: [1202533.365493]  [81353413] ? 
bus_for_each_dev+0x53/0x90
Apr 17 09:42:12 

Bug#741079: marked as done (linux-image-3.13-1-686-pae: Stack trace when unplugging usb devices)

2014-09-24 Thread Debian Bug Tracking System
Your message dated Wed, 24 Sep 2014 13:43:05 +0100
with message-id 1411562585.3659.30.ca...@decadent.org.uk
and subject line Re: linux-image-3.13-1-686-pae: Stack trace when unplugging 
usb devices
has caused the Debian Bug report #741079,
regarding linux-image-3.13-1-686-pae: Stack trace when unplugging usb devices
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
741079: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741079
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: src:linux
Version: 3.13.5-1
Severity: normal

Dear Maintainer,

When unplugging usb devices I have a stack trace. I tried an external usb disk, 
and a wifi dongle.
The message present in both cases is : warn_slowpath_common...
Note that I've moved from 3.11 to 3.13. I haven't used 3.12

Regards

nb


-- Package-specific info:
** Version:
Linux version 3.13-1-686-pae (debian-kernel@lists.debian.org) (gcc version 
4.8.2 (Debian 4.8.2-14) ) #1 SMP Debian 3.13.5-1 (2014-03-04)

** Command line:
BOOT_IMAGE=/vmlinuz-3.13-1-686-pae 
root=UUID=ae9930fd-764c-4354-901c-0abaf3657eb0 ro quiet

** Tainted: WO (4608)
 * Taint on warning.
 * Out-of-tree module has been loaded.

** Kernel log:
[51572.170508]  [c14161f7] ? ret_from_kernel_thread+0x1b/0x28
[51572.170516]  [c1068bd0] ? kthread_create_on_node+0x110/0x110
[51572.170522] ---[ end trace 8c972f800d5df207 ]---
[51740.164059] usb 5-1: new high-speed USB device number 55 using ehci-pci
[51740.297207] usb 5-1: New USB device found, idVendor=7392, idProduct=a811
[51740.297228] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[51740.297236] usb 5-1: Product: 802.11n WLAN Adapter
[51740.297243] usb 5-1: Manufacturer: Realtek
[51740.297249] usb 5-1: SerialNumber: 00e04c01
[51740.874130] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[51746.127024] RTL871X: set ssid [belkin.92e.5GHz] fw_state=0x0008
[51746.427442] RTL871X: start auth
[51746.430511] RTL871X: auth success, start assoc
[51746.432673] RTL871X: assoc success
[51746.432759] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[51746.435382] UpdateHalRAMask8812A = mac_id:0, networkType:0x14, 
mask:0x0000
[51746.435382]   == rssi_level:0, rate_bitmap:0x000ff010
[51746.450049] RTL871X: send eapol packet
[51746.461143] RTL871X: send eapol packet
[51746.462871] RTL871X: set pairwise key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 
AES-4) camid:4
[51746.462880] RTL871X: set group key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 
AES-4) keyid:1
[51746.886607] UpdateHalRAMask8812A = mac_id:0, networkType:0x14, 
mask:0x0000
[51746.886607]   == rssi_level:1, rate_bitmap:0x000f
[51769.309148] [ cut here ]
[51769.309196] WARNING: CPU: 0 PID: 27157 at 
/build/linux-ncyRvS/linux-3.13.5/net/wireless/sme.c:854 
__cfg80211_disconnected+0x227/0x230 [cfg80211]()
[51769.309212] Modules linked in: usb_storage pci_stub vboxpci(O) vboxnetadp(O) 
vboxnetflt(O) snd_hrtimer cpufreq_powersave cpufreq_userspace cpufreq_stats 
cpufreq_conservative rfcomm bnep binfmt_misc vboxdrv(O) synaptics_i2c 
firewire_sbp2 loop fuse parport_pc ppdev lp parport 8812au(O) hid_generic btusb 
bluetooth usbhid hid joydev gspca_m5602 gspca_main videodev media cfg80211 
evdev pcspkr psmouse pcmcia serio_raw r852 sm_common yenta_socket nand 
pcmcia_rsrc nand_ecc pcmcia_core r592 nand_ids mtd memstick lpc_ich mfd_core 
rng_core snd_hda_codec_realtek asus_laptop acpi_cpufreq i915 snd_hda_intel 
snd_hda_codec snd_hwdep snd_pcm sparse_keymap snd_page_alloc rfkill ac battery 
video processor button input_polldev drm_kms_helper drm i2c_algo_bit i2c_core 
snd_seq snd_seq_device snd_timer snd soundcore ext4 crc16 mbcache jbd2 sg 
sd_mod sr_mod crc_t10dif crct10dif_common cdrom ata_generic ata_piix 
firewire_ohci sdhci_pci sdhci firewire_core crc_itu_t 8139too 8139cp mii 
mmc_core ehci_pci the
 rmal libata scsi_mod fan uhci_hcd ehci_hcd thermal_sys usbcore usb_common
[51769.309388] CPU: 0 PID: 27157 Comm: kworker/u2:2 Tainted: GW  O 
3.13-1-686-pae #1 Debian 3.13.5-1
[51769.309394] Hardware name: ASUSTeK Computer Inc. W5A   /W5A  
 , BIOS 020911/17/2005
[51769.309412] Workqueue: cfg80211 cfg80211_event_work [cfg80211]
[51769.309418]  0009 c140b038  c104d41e c14d7898  6a15 
f88d3554
[51769.309432]  0356 f88b7277 f88b7277 c9d787a8   f35f4d20 
c104d4db
[51769.309445]  0009  f88b7277  2f15 c163c380 f3646000 
d3dd5000
[51769.309458] Call Trace:
[51769.309472]  [c140b038] ? dump_stack+0x3e/0x4e

Processed: tagging 738020

2014-09-24 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 tags 738020 - patch
Bug #738020 [linux] usbutils: Wireless mouse stop
Removed tag(s) patch.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
738020: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738020
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: 
https://lists.debian.org/handler.s.c.141156277611673.transcr...@bugs.debian.org



Bug#733565: marked as done (SIX messages per on boot console should be TWO)

2014-09-24 Thread Debian Bug Tracking System
Your message dated Wed, 24 Sep 2014 13:48:13 +0100
with message-id 1411562893.3659.31.ca...@decadent.org.uk
and subject line Re: SIX messages per on boot console should be TWO
has caused the Debian Bug report #733565,
regarding SIX messages per on boot console should be TWO
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
733565: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733565
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: linux-image-3.12-1-686-pae

Currently any such devices as below that are attached during boot still
produce the below SIX messages per device when they should only produce
TWO:

# dmesg |egrep Caching\|Assuming
[3.960663] sd 3:0:0:0: [sdb] No Caching mode page found
[3.960701] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[3.978659] sd 3:0:0:0: [sdb] No Caching mode page found
[3.978694] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[3.998652] sd 3:0:0:0: [sdb] No Caching mode page found
[3.998689] sd 3:0:0:0: [sdb] Assuming drive cache: write through
[4.174630] sd 2:0:0:2: [sde] No Caching mode page found
[4.174669] sd 2:0:0:2: [sde] Assuming drive cache: write through
[4.196628] sd 2:0:0:2: [sde] No Caching mode page found
[4.196664] sd 2:0:0:2: [sde] Assuming drive cache: write through
[4.220624] sd 2:0:0:2: [sde] No Caching mode page found
[4.220661] sd 2:0:0:2: [sde] Assuming drive cache: write through

Please confirm that you also see the six messages right there on the
console stderr.
---End Message---
---BeginMessage---
Version: 3.15~rc5-1~exp1

Patch was applied upstream in 3.15-rc1.

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
   - Albert Einstein


signature.asc
Description: This is a digitally signed message part
---End Message---


Processed: fixed 721346 in 3.8-1~experimental.1

2014-09-24 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 fixed 721346 3.8-1~experimental.1
Bug #721346 [src:linux] linux-image-3.2.0-0.bpo.4-rt-686-pae: Xonar DSX not 
recognized although there is a functional driver (patch included).
Marked as fixed in versions linux/3.8-1~experimental.1.
 thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
721346: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721346
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: 
https://lists.debian.org/handler.s.c.141156322615182.transcr...@bugs.debian.org



Bug#745147: closed by Ben Hutchings b...@decadent.org.uk (Re: WARNING on removal of SCSI device which is still in use)

2014-09-24 Thread Luke Kenneth Casson Leighton
thanks for keeping an eye on this ben


On Wed, Sep 24, 2014 at 2:42 PM, Debian Bug Tracking System
ow...@bugs.debian.org wrote:

 Subject: Re: WARNING on removal of SCSI device which is still in use
 Version: 3.15~rc5-1~exp1

 This is supposed to be fixed in 3.15-rc1 by:

 commit e63ed0d7a98014fdfc2cfeb3f6dada313dcabb59
 Author: James Bottomley jbottom...@parallels.com
 Date:   Tue Jan 21 07:00:50 2014 -0800

 [SCSI] fix our current target reap infrastructure

 Ben.


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAPweEDwCvvHv2ishty+Nr-bH4sPOsfw=cugj37yvsdiacd+...@mail.gmail.com



Bug#762706: i915: blank screen on resume, logs 'failed to enable link training'

2014-09-24 Thread Matijs van Zuijlen
Package: src:linux
Version: 3.16.3-2
Severity: normal

On a regular basis, on resume, my laptop's screen stays blank. The
backlight turns on, but there is no image. Closing the laptop, waiting
for the backlight to turn off, and then opening the laptop again usually
remedies the problem.

The system log contains the following message:

  Sep 24 11:52:02 walnut kernel: [86794.556876] [drm:intel_dp_start_link_train] 
*ERROR* failed to enable link training

This is follewed by several copies of the following:

  Sep 24 11:52:02 walnut kernel: [86794.768312] [ cut here 
]
  Sep 24 11:52:02 walnut kernel: [86794.768363] WARNING: CPU: 3 PID: 22996 at 
/build/linux-P15SNz/linux-3.16.3/drivers/gpu/drm/i915/intel_dp.c:3125 
intel_dp_complete_link_train+0xed/0x310 [i915]()
  Sep 24 11:52:02 walnut kernel: [86794.768431] Modules linked in: nls_utf8 
nls_cp437 vfat fat ctr ccm cpufreq_powersave cpufreq_userspace cpufreq_stats 
cpufreq_conservative binfmt_misc snd_hda_codec_hdmi snd_hda_codec_cirrus 
snd_hda_codec_generic arc4 brcmsmac nf_conntrack_ipv4 nf_defrag_ipv4 xt_tcpudp 
xt_conntrack cordic brcmutil nf_conntrack b43 mac80211 iptable_filter ip_tables 
cfg80211 x_tables ssb mmc_core rng_core pcmcia pcmcia_core joydev iTCO_wdt 
iTCO_vendor_support applesmc input_polldev ecb uvcvideo btusb 
x86_pkg_temp_thermal intel_powerclamp snd_hda_intel bluetooth intel_rapl 
videobuf2_vmalloc snd_hda_controller videobuf2_memops videobuf2_core 
snd_hda_codec crc32_pclmul v4l2_common 6lowpan_iphc snd_hwdep videodev 
snd_pcm_oss bcm5974 rfkill ghash_clmulni_intel media snd_mixer_oss snd_pcm 
evdev snd_seq_midi snd_seq_midi_event snd_rawmidi aesni_intel aes_x86_64 lrw 
snd_seq gf128mul glue_helper snd_seq_device ablk_helper cryptd snd_timer bcma 
pcspkr i915 lpc_ich i2c_!
 i8!
   01 mfd_co
   re snd sbs drm_kms_helper sbshc soundcore battery drm shpchp i2c_algo_bit 
apple_bl i2c_core mei_me video mei ac button processor thermal_sys kvm_intel 
kvm coretemp loop fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache 
jbd2 ahci libahci sg sd_mod crc_t10dif crct10dif_generic ata_generic 
hid_generic usb_storage hid_apple usbhid hid ata_piix crct10dif_pclmul 
crct10dif_common crc32c_intel libata uhci_hcd ehci_pci ehci_hcd scsi_mod 
usbcore usb_common
  Sep 24 11:52:02 walnut kernel: [86794.768518] CPU: 3 PID: 22996 Comm: 
kworker/u16:94 Tainted: GW 3.16-2-amd64 #1 Debian 3.16.3-2
  Sep 24 11:52:02 walnut kernel: [86794.768520] Hardware name: Apple Inc. 
MacBookAir4,2/Mac-742912EFDBEE19B3, BIOS MBA41.88Z.0077.B0F.1201241549 
01/24/2012
  Sep 24 11:52:02 walnut kernel: [86794.768529] Workqueue: events_unbound 
async_run_entry_fn
  Sep 24 11:52:02 walnut kernel: [86794.768536]  0009 
81506188  81065707
  Sep 24 11:52:02 walnut kernel: [86794.768541]  88003697a0d8 
0001  88003697a118
  Sep 24 11:52:02 walnut kernel: [86794.768545]  88003697a0f3 
a04354ad 10044004 00810003212e
  Sep 24 11:52:02 walnut kernel: [86794.768547] Call Trace:
  Sep 24 11:52:02 walnut kernel: [86794.768557]  [81506188] ? 
dump_stack+0x41/0x51
  Sep 24 11:52:02 walnut kernel: [86794.768564]  [81065707] ? 
warn_slowpath_common+0x77/0x90
  Sep 24 11:52:02 walnut kernel: [86794.768590]  [a04354ad] ? 
intel_dp_complete_link_train+0xed/0x310 [i915]
  Sep 24 11:52:02 walnut kernel: [86794.768614]  [a0435737] ? 
intel_enable_dp+0x67/0x90 [i915]
  Sep 24 11:52:02 walnut kernel: [86794.768638]  [a043576e] ? 
g4x_enable_dp+0xe/0x20 [i915]
  Sep 24 11:52:02 walnut kernel: [86794.768664]  [a04158d9] ? 
ironlake_crtc_enable+0x4f9/0xf20 [i915]
  Sep 24 11:52:02 walnut kernel: [86794.768690]  [a03eb636] ? 
i915_gem_object_pin_to_display_plane+0x96/0x1b0 [i915]
  Sep 24 11:52:02 walnut kernel: [86794.768713]  [a03ec488] ? 
i915_gem_object_pin_fence+0x28/0xa0 [i915]
  Sep 24 11:52:02 walnut kernel: [86794.768740]  [a0418e97] ? 
__intel_set_mode+0x7d7/0x1560 [i915]
  Sep 24 11:52:02 walnut kernel: [86794.768766]  [a0403514] ? 
gen6_read32+0x64/0x120 [i915]
  Sep 24 11:52:02 walnut kernel: [86794.768773]  [8150a9ee] ? 
mutex_lock+0xe/0x2a
  Sep 24 11:52:02 walnut kernel: [86794.768799]  [a041dfb4] ? 
intel_modeset_setup_hw_state+0x824/0xd30 [i915]
  Sep 24 11:52:02 walnut kernel: [86794.768815]  [a036fb5a] ? 
drm_modeset_lock+0x2a/0xd0 [drm]
  Sep 24 11:52:02 walnut kernel: [86794.768830]  [a036fc41] ? 
drm_modeset_lock_all_crtcs+0x41/0x60 [drm]
  Sep 24 11:52:02 walnut kernel: [86794.768835]  [812e0420] ? 
pci_pm_thaw+0x90/0x90
  Sep 24 11:52:02 walnut kernel: [86794.768852]  [a03c537e] ? 
__i915_drm_thaw+0x11e/0x1a0 [i915]
  Sep 24 11:52:02 walnut kernel: [86794.768870]  [a03c5bd4] ? 
i915_resume+0x24/0x40 [i915]
  Sep 24 11:52:02 walnut kernel: [86794.768876]  [813a8a96] ? 

Upcoming stable point release (7.7)

2014-09-24 Thread Adam D. Barratt
Hi,

The next point release for wheezy (7.7) is scheduled for Saturday,
October 18th.  Stable NEW will be frozen during the preceding weekend.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1411585956.15708.2.ca...@jacala.jungle.funky-badger.org



Re: Uploading linux (3.2.63-1)

2014-09-24 Thread Moritz Mühlenhoff
Ben Hutchings b...@decadent.org.uk schrieb:

 --=-6AOvsZRHpAv99mjPeare
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable

 I intend to upload linux version 3.2.63-1 to stable-proposed-updates
 later this week.  This will include all the fixes that went into stable
 updates 3.2.61-63 inclusive, including fixes for these security issues:

 CVE-2014-3181HID/magicmouse: buffer overflow
 CVE-2014-3182HID/logitech-dj: out-of-bounds read
 CVE-2014-3183/3184/3185  USB/serial/whiteheat: multiple buffer overflows
 CVE-2014-3186HID/picolcd: buffer overflow
 CVE-2014-3601kvm: guest-controllable memory leak
 CVE-2014-4171shmem: reader can block hole punch indefinitely
 CVE-2014-4608lzo: integer overflow
 CVE-2014-5077sctp: remote denial of service
 CVE-2014-5471/5472   isofs: unbound recursion allowing stack overflow
 =20
 I also cherry-picked fixes for:

 CVE-2014-6410udf: infinite loop when processing indirect ICBs
 CVE-2014-6416/6417/6418  libceph: buffer overflow and related bugs

 If any of these look serious enough, I could also prepare a security
 update.

As discussed earlier, scheduling these for the next point update is fine.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/slrnm25p7o.33m@inutil.org



Bug#762390: Patch for hppa arch

2014-09-24 Thread Helge Deller

could you please temporarily add this hppa-specific patch to the debian
kernel sources?
...
diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
index 7187664..5db8882 100644
--- a/arch/parisc/Makefile
+++ b/arch/parisc/Makefile
@@ -48,7 +48,12 @@ cflags-y := -pipe

  # These flags should be implied by an hppa-linux configuration, but they
  # are not in gcc 3.2.
-cflags-y   += -mno-space-regs -mfast-indirect-calls
+cflags-y   += -mno-space-regs
+
+# -mfast-indirect-calls is only relevant for 32-bit kernels.


FYI, this patch has now been pushed upstream and scheduled for stable kernel 
series:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d26a7730b5874a5fa6779c62f4ad7c5065a94723

Helge


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54233be2.1020...@gmx.de



Bug#762768: /usr/sbin/update-initramfs: update-initramfs(8) and --help show -b as argument-less

2014-09-24 Thread Frédéric Brière
Package: initramfs-tools
Version: 0.116
Severity: minor
File: /usr/sbin/update-initramfs

Both the update-initramfs(8) manpage and update-initramfs --help show
the -b option without any argument, while it does require one.

(On a similar note, --help seems to imply that for the -k option, the
version argument is optional.)


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 18M Sep 21 21:30 /boot/initrd.img-3.14-2-amd64
-rw-r--r-- 1 root root 18M Sep 21 22:01 /boot/initrd.img-3.16-2-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.14-2-amd64 root=/dev/mapper/root ro

-- /proc/filesystems
ext3
ext2
ext4
fuseblk
vfat
udf
iso9660

-- lsmod
Module  Size  Used by
isofs  38963  0 
udf83702  0 
nls_utf8   12456  0 
nls_cp437  16553  0 
vfat   17135  0 
fat53794  1 vfat
nfs   187768  0 
lockd  79321  1 nfs
sunrpc228923  2 nfs,lockd
fscache45542  1 nfs
sha256_generic 16804  2 
ecb12737  0 
cbc12696  1 
act_police 12620  1 
sch_ingress12744  1 
cls_u3216992  6 
sch_sfq21302  3 
sch_cbq26257  1 
ipt_REJECT 12465  1 
xt_multiport   12518  2 
iptable_filter 12536  1 
ip_tables  26011  1 iptable_filter
x_tables   23015  4 ip_tables,xt_multiport,iptable_filter,ipt_REJECT
pci_stub   12429  1 
vboxpci18981  0 
vboxnetadp 25443  0 
vboxnetflt 23324  0 
vboxdrv   327732  3 vboxnetadp,vboxnetflt,vboxpci
binfmt_misc16949  1 
it87   34183  0 
hwmon_vid  12388  1 it87
pppoe  17364  2 
pppox  12594  1 pppoe
ppp_generic30354  6 pppoe,pppox
slhc   12531  1 ppp_generic
loop   26605  2 
fuse   78879  0 
ppdev  16782  0 
kvm_amd54863  0 
kvm   388172  1 kvm_amd
edac_mce_amd   21166  0 
pcspkr 12595  0 
serio_raw  12849  0 
k10temp12618  0 
edac_core  47369  0 
parport_pc 26300  0 
parport35749  2 ppdev,parport_pc
tuner_simple   17177  1 
tuner_types16409  1 tuner_simple
tuner  25658  1 
snd_hda_codec_hdmi 40955  1 
tda743212629  0 
tvaudio26633  0 
msp340034338  0 
snd_usb_audio 118831  1 
snd_usbmidi_lib23380  1 snd_usb_audio
snd_rawmidi26805  1 snd_usbmidi_lib
snd_seq_device 13132  1 snd_rawmidi
evdev  17445  6 
joydev 17063  0 
snd_hda_codec_realtek50301  1 
snd_hda_codec_generic59065  1 snd_hda_codec_realtek
bttv  126534  0 
snd_hda_intel  43768  9 
snd_hda_codec 100159  4 
snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel
snd_hwdep  13148  2 snd_usb_audio,snd_hda_codec
snd_bt87x  13400  1 
snd_pcm_oss44847  0 
radeon   1285920  4 
btcx_risc  12555  1 bttv
snd_mixer_oss  22042  1 snd_pcm_oss
snd_pcm84566  8 
snd_pcm_oss,snd_usb_audio,snd_bt87x,snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
tveeprom   20593  1 bttv
videobuf_dma_sg17248  1 bttv
videobuf_core  21832  2 bttv,videobuf_dma_sg
rc_core22331  1 bttv
v4l2_common12995  5 bttv,tuner,tda7432,msp3400,tvaudio
videodev  117963  6 bttv,tuner,tda7432,msp3400,tvaudio,v4l2_common
media  18303  1 videodev
ttm69624  1 radeon
drm_kms_helper 39892  1 radeon
i2c_piix4  16768  0 
drm   236561  6 ttm,drm_kms_helper,radeon
i2c_algo_bit   12751  2 bttv,radeon
i2c_core   28324  14 
drm,bttv,tuner,i2c_piix4,drm_kms_helper,tda7432,i2c_algo_bit,msp3400,tvaudio,v4l2_common,tveeprom,radeon,tuner_simple,videodev
snd_timer  26614  3 snd_pcm
snd61094  33 
snd_hda_codec_realtek,snd_pcm_oss,snd_usb_audio,snd_bt87x,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_rawmidi,snd_hda_codec_generic,snd_usbmidi_lib,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_mixer_oss
soundcore  13026  1 snd
wmi17339  0 
shpchp 31121  0 
acpi_cpufreq   17218  0 
processor  28221  1 acpi_cpufreq
thermal_sys27642  1 processor
button 12944  0 
ext4  473554  8 
crc16  12343  1 ext4
mbcache13082  1 ext4
jbd2   82560  1 ext4
xts   

Bug#652459: too little, too late?

2014-09-24 Thread Joey Hess
We're starting to have to work around this bug in d-i, by eg making
separate /usr a harder situation to get into when installing Debian.

My calendar says 10 days until freeze start. I sincerely hope someone
does something.

-- 
see shy jo


signature.asc
Description: Digital signature


Bug#652459: too little, too late?

2014-09-24 Thread Marco d'Itri
On Sep 25, Joey Hess jo...@debian.org wrote:

 My calendar says 10 days until freeze start. I sincerely hope someone
 does something.
Would anybody mind if I just uploaded straight to unstable a new 
initramfs-tools package with no concern at all for the maintainer's 
unexpressed wishes?

-- 
ciao,
Marco


signature.asc
Description: Digital signature