Bug#681280: kernel warning at .../net/sched/sch_generic.c:255 dev_watchdog - eth0 (sky2) transmit queue 0 timed out

[Julian Gilbey]

On Wed, Jul 11, 2012 at 11:16:39PM +0100, Julian Gilbey wrote:
> I've had numerous occasions in at least the last month (from kernel
> 3.2.19-1 or earlier - that's as far back as my logs go) when my
> machine has given a kernel error when trying to connect to a
> Windows-driven ethernet.  (I hadn't realised that it was a kernel
> issue until very recently.)  Below is a typical kernel log from boot
> until the "crash" occurred; my machine was connected to the ethernet
> during this process.  It is sporadic - it sometimes works fine and
> othertimes not at all, and it sometimes works and then stops working.

A followup on this bug.  I've started noticing it on my home network
with no Windows machine involved - it can occur within minutes of
booting.  The only machines present on the local network are two linux
boxes and a Netgear router.

   Julian


-- 
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/20120717071135.ga30...@d-and-j.net

Bug#681280: kernel warning at .../net/sched/sch_generic.c:255 dev_watchdog - eth0 (sky2) transmit queue 0 timed out

[Julian Gilbey]

On Wed, Jul 11, 2012 at 11:16:39PM +0100, Julian Gilbey wrote:
> I've had numerous occasions in at least the last month (from kernel
> 3.2.19-1 or earlier - that's as far back as my logs go) when my
> machine has given a kernel error when trying to connect to a
> Windows-driven ethernet.  (I hadn't realised that it was a kernel
> issue until very recently.)  Below is a typical kernel log from boot
> until the "crash" occurred; my machine was connected to the ethernet
> during this process.  It is sporadic - it sometimes works fine and
> othertimes not at all, and it sometimes works and then stops working.

A followup on this bug.  I've started noticing it on my home network
with no Windows machine involved - it can occur within minutes of
booting.  The only machines present on the local network are two linux
boxes and a Netgear router.

   Julian


-- 
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/20120717071210.gb30...@d-and-j.net

Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues

[Geert Uytterhoeven]

On Mon, Jul 16, 2012 at 10:56 PM, Linus Torvalds
 wrote:
> On Mon, Jul 16, 2012 at 12:26 PM,   wrote:
>> Some of the proposed ways to implement the minimum distro kernel would not
>> allow you to override the distro defaults because they would be implemented
>> by setting dependancies, not by selecting options that you as the user could
>> then unselect.
>
> The sanest thing to do is just a list of "select" statements. And in
> any case it would have to depend on the "distro config" entry, so EVEN
> THEN you could just create the Kconfig file, then edit out the distro
> config thing, and then do whatever you want.

Except that "select" is one of the ugliest things in Kconfig, as it
blindly sets a symbol
without checking if its dependencies are fulfilled.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


-- 
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/CAMuHMdWopF1MjHjNT_CAnu=ptu8x8oxyw4m+y2-xhehff2x...@mail.gmail.com

Processed: Re: Bug#681887: linux-image-3.2.0-2-amd64: system unresponsive during disk copy (seems locked up)

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 681887 src:linux 3.2.20-1
Bug #681887 [src] linux-image-3.2.0-2-amd64: system unresponsive during disk 
copy (seems locked up)
Warning: Unknown package 'src'
Bug reassigned from package 'src' to 'src:linux'.
No longer marked as found in versions 3.2.20-1.
Ignoring request to alter fixed versions of bug #681887 to the same values 
previously set
Bug #681887 [src:linux] linux-image-3.2.0-2-amd64: system unresponsive during 
disk copy (seems locked up)
Marked as found in versions linux/3.2.20-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
681887: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681887
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.13425347291952.transcr...@bugs.debian.org

Bug#647741: still occurs in 3.2.15-1

[Vincent Lefevre]

AFAIK, I haven't seen such a freeze for several weeks. If some bug
has been fixed in the kernel, it must be between 3.2.15 and 3.2.20.
The other possible change in the system I can see is that tmpfs is
no longer used for /tmp (after 2012-06-11).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20120717174906.ga20...@ypig.lip.ens-lyon.fr

Bug#670241: Updated qmi_wwan backport based on v3.2.19, including new device IDs from v3.5-rc1

[Bjørn Mork]

block 670241 by 681912
thanks

Please don't implement this just yet.  The ModemManager version in
wheezy may choke on the ports provided by the new driver.  Ref
https://bugzilla.redhat.com/show_bug.cgi?id=835153

I've opened a bug against ModemManager requesting the addition of the
upstream workaround, and am now blocking this bug against it.  Better
not include the driver until we sure it won't trigger any ModemManager
regressions.

Feel free to close this bug with a wontfix if you like.  After all, the
qmi_wwan driver will never be very useful in wheezy, given that the
modemmanager package is frozen on a version too old to ever gain QMI
support.

And thanks for delaying this until Fedora sorted out the worst problems
:-)  That's wise.


Bjørn


--
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/87txx6jmh7@nemi.mork.no

Processed: Re: Bug#670241: Updated qmi_wwan backport based on v3.2.19, including new device IDs from v3.5-rc1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 670241 by 681912
Bug #670241 [linux-2.6] linux-2.6: Backporting the qmi_wwan driver to the 
Debian 3.2/wheezy kernels
670241 was not blocked by any bugs.
670241 was not blocking any bugs.
Added blocking bug(s) of 670241: 681912
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
670241: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670241
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.13425484859791.transcr...@bugs.debian.org

Bug#647741: still occurs in 3.2.15-1

[Jonathan Nieder]

Hi,

Vincent Lefevre wrote:

> AFAIK, I haven't seen such a freeze for several weeks. If some bug
> has been fixed in the kernel, it must be between 3.2.15 and 3.2.20.
> The other possible change in the system I can see is that tmpfs is
> no longer used for /tmp (after 2012-06-11).

Could you be convinced to reenable tmpfs for /tmp again, so we can
see if that's the cause of the change?  (Unfortunately I suspect it
is.)

If "no", that's fine, of course. :)

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/20120717181125.GK3071@burratino

Bug#670241: Updated qmi_wwan backport based on v3.2.19, including new device IDs from v3.5-rc1

[Ben Hutchings]

On Tue, Jul 17, 2012 at 08:01:24PM +0200, Bjørn Mork wrote:
> block 670241 by 681912
> thanks
> 
> Please don't implement this just yet.  The ModemManager version in
> wheezy may choke on the ports provided by the new driver.  Ref
> https://bugzilla.redhat.com/show_bug.cgi?id=835153
> 
> I've opened a bug against ModemManager requesting the addition of the
> upstream workaround, and am now blocking this bug against it.  Better
> not include the driver until we sure it won't trigger any ModemManager
> regressions.
> 
> Feel free to close this bug with a wontfix if you like.  After all, the
> qmi_wwan driver will never be very useful in wheezy, given that the
> modemmanager package is frozen on a version too old to ever gain QMI
> support.
 
How large are the required changes to ModemManager?  New hardware
support is a perfectly good reason for a freeze exception, whichever
package it's in.

Ben.

> And thanks for delaying this until Fedora sorted out the worst problems
> :-)  That's wise.

-- 
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/20120717183748.gw1...@decadent.org.uk

Bug#670241: Updated qmi_wwan backport based on v3.2.19, including new device IDs from v3.5-rc1

[Bjørn Mork]

Ben Hutchings  writes:
> On Tue, Jul 17, 2012 at 08:01:24PM +0200, Bjørn Mork wrote:
>
>> Feel free to close this bug with a wontfix if you like.  After all, the
>> qmi_wwan driver will never be very useful in wheezy, given that the
>> modemmanager package is frozen on a version too old to ever gain QMI
>> support.
>  
> How large are the required changes to ModemManager?  

Huge.

The next version (0.6) will use a completely new D-Bus API making it
incompatible with the current NetworkManager and any other ModemManager
users. Ref http://www.freedesktop.org/wiki/ModemManager06

And the QMI support might even not be ready for 0.6.  It's currently
being developed in a separate branch and not yet fully operational.

> New hardware
> support is a perfectly good reason for a freeze exception, whichever
> package it's in.

Sure, and I appreciate that.  But do note that this driver does not add
support for any new USB device.  All supported modems are composite
devices having at least one serial port supporting PPP.  This means that
the driver isn't critical for basic device support.  It only adds
support for another device function, which most users will see as
redundant.


Bjørn


--
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/87pq7ujj48@nemi.mork.no

Re: [PATCH] scripts/package/builddeb: upgrade to current practices

[Jonathan Nieder]

Hi,

Martin-Éric Racine wrote:

> Signed-off-by: Martin-Éric Racine 

Thanks.  This patch does many things at once instead of the usual
practice of "one patch per logical change", but oh well.

[...]
> --- a/scripts/package/builddeb
> +++ b/scripts/package/builddeb
> @@ -79,9 +79,9 @@ fwdir="$objtree/debian/fwtmp"
>  kernel_headers_dir="$objtree/debian/hdrtmp"
>  libc_headers_dir="$objtree/debian/headertmp"
>  packagename=linux-image-$version
> -fwpackagename=linux-firmware-image
>  kernel_headers_packagename=linux-headers-$version
>  libc_headers_packagename=linux-libc-dev
> +fwpackagename=firmware-linux

Micronit: any reason the lines are reordered here?

> @@ -188,17 +188,17 @@ This is a packacked upstream version of the Linux 
> kernel.
>  The sources may be found at most Linux ftp sites, including:
>  ftp://ftp.kernel.org/pub/linux/kernel
>  
> -Copyright: 1991 - 2009 Linus Torvalds and others.
> +Copyright: 1991-2012 Linus Torvalds and others.
>  
> -The git repository for mainline kernel development is at:
> -git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> +The GIT repository for mainline kernel development is at:
> +git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

I personally like to spell it as "Git". ;-)

[...]
> @@ -273,6 +273,9 @@ if [ -e "$tmpdir/lib/firmware" ]; then
>  
>  Package: $fwpackagename
>  Architecture: all
> +Conflicts: firmware-linux-free, firmware-linux-nonfree
> +Provides: firmware-linux-free, firmware-linux-nonfree
> +Replaces: firmware-linux-free, firmware-linux-nonfree

I assume you mean Breaks+Replaces.  Do the files actually overlap,
or is this change being overly cautious?  I would expect the files
not to overlap because the package build with deb-pkg puts firmware
in a versioned subdirectory "/lib/firmware/".

Hope that helps,
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/20120717193951.GA15208@burratino

Re: [PATCH] scripts/package/builddeb: upgrade to current practices

[Martin-Éric Racine]

2012/7/17 Jonathan Nieder :
> Hi,
>
> Martin-Éric Racine wrote:
>
>> Signed-off-by: Martin-Éric Racine 
>
> Thanks.  This patch does many things at once instead of the usual
> practice of "one patch per logical change", but oh well.
>
> [...]
>> --- a/scripts/package/builddeb
>> +++ b/scripts/package/builddeb
>> @@ -79,9 +79,9 @@ fwdir="$objtree/debian/fwtmp"
>>  kernel_headers_dir="$objtree/debian/hdrtmp"
>>  libc_headers_dir="$objtree/debian/headertmp"
>>  packagename=linux-image-$version
>> -fwpackagename=linux-firmware-image
>>  kernel_headers_packagename=linux-headers-$version
>>  libc_headers_packagename=linux-libc-dev
>> +fwpackagename=firmware-linux
>
> Micronit: any reason the lines are reordered here?

Mostly to differenciate between versioned and non-versioned package targets.

>> @@ -188,17 +188,17 @@ This is a packacked upstream version of the Linux 
>> kernel.
>>  The sources may be found at most Linux ftp sites, including:
>>  ftp://ftp.kernel.org/pub/linux/kernel
>>
>> -Copyright: 1991 - 2009 Linus Torvalds and others.
>> +Copyright: 1991-2012 Linus Torvalds and others.
>>
>> -The git repository for mainline kernel development is at:
>> -git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> +The GIT repository for mainline kernel development is at:
>> +git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>
> I personally like to spell it as "Git". ;-)

That works for me too. Actually, what's the official spelling for it?

> [...]
>> @@ -273,6 +273,9 @@ if [ -e "$tmpdir/lib/firmware" ]; then
>>
>>  Package: $fwpackagename
>>  Architecture: all
>> +Conflicts: firmware-linux-free, firmware-linux-nonfree
>> +Provides: firmware-linux-free, firmware-linux-nonfree
>> +Replaces: firmware-linux-free, firmware-linux-nonfree
>
> I assume you mean Breaks+Replaces.  Do the files actually overlap,
> or is this change being overly cautious?  I would expect the files
> not to overlap because the package build with deb-pkg puts firmware
> in a versioned subdirectory "/lib/firmware/".

AFAIK they would overlap, hence the Conflicts.

Martin-Éric


--
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/CAPZXPQc02onTb_RmgfpW+A4=N_huZW1FUYdjJ=nt0y3pq...@mail.gmail.com

Bug#670241: marked as done (linux-2.6: Backporting the qmi_wwan driver to the Debian 3.2/wheezy kernels)

[Debian Bug Tracking System]

Your message dated Tue, 17 Jul 2012 20:44:46 +0100
with message-id <20120717194446.gx1...@decadent.org.uk>
and subject line Re: Bug#670241: Updated qmi_wwan backport based on v3.2.19, 
including new device IDs from v3.5-rc1
has caused the Debian Bug report #670241,
regarding linux-2.6: Backporting the qmi_wwan driver to the Debian 3.2/wheezy 
kernels
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.)


-- 
670241: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670241
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-2.6
Version: 3.2.15-1
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Please add the qmi_wwan driver from current (v3.4-rc)
mainline to the Debian linux-3.2 based kernels. This
is as simple as cherry-picking the commits listed below in
the listed order.  I've verified that the list applies
cleanly on top of v3.2.16 and that it produces the expected
result.

CONFIG_USB_NET_QMI_WWAN must of course be enabled after
adding the driver.  No other CONFIG changes are necessary.


The first batch updates the existing cdc-wdm driver to the
version in v3.4-rc4, except for the module_usb_driver()
changes from commit 65db43054.  That commit touches a large
number of unrelated drivers, and all listed commits apply
cleanly without it, so I believe it's best ignored. The
other changes are necessary to add the subdriver interface
used by the qmi_wwan driver.

The second batch is just a single bugfix for the sierra
driver, which is necessary to allow the qmi_wwan driver
to support some Sierra Wireless devices.  This could have
gone to stable/linux-3.2.y but I did't submit it there as
it is mostly irrelevant without the qmi_wwan driver.

The third batch adds the new qmi_wwan driver as it will appear
in v3.4-rc5.  The driver has been stabilizing for a while,
and I don't expect any major changes to it in the near future.

Thanks for considering this.  Let me know if there are any
problems with this request.



1) add subdriver support to cdc-wdm

19b85b3 USB: cdc-wdm: no need to fill the in request URB every time it's 
submitted
8143a89 USB: cdc-wdm: kill the now unnecessary bMaxPacketSize0 field and udev 
variable
820c629 USB: cdc-wdm: avoid printing odd-looking "cdc-wdm-176" names
fec67b4 usb: cdc-wdm: Add device-id for Huawei 3G/LTE modems
8804420 usb: cdc-wdm: make reset work with blocking IO
8457d99 USB: cdc-wdm: no need to use usb_alloc_coherent
0dffb48 usb: cdc-wdm: split out reusable parts of probe
b0c1386 usb: cdc-wdm: adding list lookup indirection
3cc3615 usb: cdc-wdm: adding usb_cdc_wdm_register subdriver support


2) prevent sierra from binding to QMI/wwan interfaces

749541d USB: sierra: avoid QMI/wwan interface on MC77xx


3) add qmi_wwan driver

423ce8c net: usb: qmi_wwan: New driver for Huawei QMI based WWAN devices
c3ecb08 net: qmi_wwan: support devices having a shared QMI/wwan interface
b086cf0 net: qmi_wwan: add Gobi and Pantech UML290 device IDs
11207b6 net: qmi_wwan: add support for ZTE MF820D
1aa35a2 USB: qmi_wwan: Add ZTE (Vodafone) K3565-Z and K4505-Z net interfaces
dbb6d09 USB: qmi_wwan: Add ZTE (Vodafone) K3570-Z and K3571-Z net interfaces
3bc17d1 net: qmi_wwan: support Sierra Wireless MC77xx devices in QMI mode



Bjørn

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk+Wig0ACgkQ10rqkowbIskgBQCdF9SobH3sjMjNPNjgc19OW6iD
fusAn2aPg1yICRWvKCjrc5ZIGlCQjKOV
=aDUe
-END PGP SIGNATURE-


--- End Message ---
--- Begin Message ---
On Tue, Jul 17, 2012 at 09:13:59PM +0200, Bjørn Mork wrote:
> Ben Hutchings  writes:
[...]
> > New hardware
> > support is a perfectly good reason for a freeze exception, whichever
> > package it's in.
> 
> Sure, and I appreciate that.  But do note that this driver does not add
> support for any new USB device.  All supported modems are composite
> devices having at least one serial port supporting PPP.  This means that
> the driver isn't critical for basic device support.  It only adds
> support for another device function, which most users will see as
> redundant.
 
OK, then I'm closing this as not needed.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus--- End Message ---

Re: [PATCH] scripts/package/builddeb: upgrade to current practices

[maximilian attems]

On Tue, Jul 17, 2012 at 10:46:23PM +0300, Martin-Éric Racine wrote:
> 2012/7/17 Jonathan Nieder :
> >>
> >>  Package: $fwpackagename
> >>  Architecture: all
> >> +Conflicts: firmware-linux-free, firmware-linux-nonfree
> >> +Provides: firmware-linux-free, firmware-linux-nonfree
> >> +Replaces: firmware-linux-free, firmware-linux-nonfree
> >
> > I assume you mean Breaks+Replaces.  Do the files actually overlap,
> > or is this change being overly cautious?  I would expect the files
> > not to overlap because the package build with deb-pkg puts firmware
> > in a versioned subdirectory "/lib/firmware/".
> 
> AFAIK they would overlap, hence the Conflicts.

This is wrong and properly fixed in -next.

-- 
maks


-- 
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/20120717212305.gv28...@vostochny.stro.at

Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2

[Peter Colberg]

Hi,

On Wed, Jul 04, 2012 at 10:39:49AM -0500, Jonathan Nieder wrote:
> Hi again,
> 
> Peter Colberg wrote:
> 
> > cd9dde44f47501394b9f0715b6a36a92aa74c0d0 is the first bad commit
> 
> How about the attached patch --- does it work against the linux-3.2.y
> branch?
> 
> Grateful,
> Jonathan

> From: Jesse Barnes 
> Date: Thu, 21 Jun 2012 15:13:50 -0700
> Subject: drm/i915: prefer wide & slow to fast & narrow in DP configs
> 
> commit 684aaa646f90f5ee07799d52d0735625756e607b upstream.
> 
> High frequency link configurations have the potential to cause trouble
> with long and/or cheap cables, so prefer slow and wide configurations
> instead.  This patch has the potential to cause trouble for eDP
> configurations that lie about available lanes, so if we run into that we
> can make it conditional on eDP.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801
> Tested-by: pe...@colberg.org
> Signed-off-by: Jesse Barnes 
> Signed-off-by: Daniel Vetter 
> Signed-off-by: Jonathan Nieder 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index d4c4937067fb..fae2050324bc 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -708,8 +708,8 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
> drm_display_mode *mode,
>  
>   bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
>  
> - for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
> - for (clock = 0; clock <= max_clock; clock++) {
> + for (clock = 0; clock <= max_clock; clock++) {
> + for (lane_count = 1; lane_count <= max_lane_count; lane_count 
> <<= 1) {
>   int link_avail = 
> intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
>  
>   if (intel_dp_link_required(mode->clock, bpp)
> -- 
> 1.7.11.rc3

I tested upstream linux 3.2.23 with the above patch applied, and
the display is working fine, i.e. it comes up in maximum, native
resolution even after power-cycling the display.

Regards,
Peter


-- 
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/20120717221021.GA4476@alcyone

Bug#658662: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2

[Jonathan Nieder]

tags 658662 = upstream patch
quit

Peter Colberg wrote:
> On Wed, Jul 04, 2012 at 10:39:49AM -0500, Jonathan Nieder wrote:

>> From: Jesse Barnes 
>> Date: Thu, 21 Jun 2012 15:13:50 -0700
>> Subject: drm/i915: prefer wide & slow to fast & narrow in DP configs
[...]
> I tested upstream linux 3.2.23 with the above patch applied, and
> the display is working fine, i.e. it comes up in maximum, native
> resolution even after power-cycling the display.

Nice to hear.

The patch is in linux-next but still not in Linus's tree, so I guess
we'll have to wait before this can be applied to the 3.2.y tree.

Kernel team: please consider the attached patch for wheezy in the
meantime.

Thanks,
Jonathan
Index: 
debian/patches/bugfix/x86/drm-i915-prefer-wide-slow-to-fast-narrow-in-DP-confi.patch
===
--- 
debian/patches/bugfix/x86/drm-i915-prefer-wide-slow-to-fast-narrow-in-DP-confi.patch
(revision 0)
+++ 
debian/patches/bugfix/x86/drm-i915-prefer-wide-slow-to-fast-narrow-in-DP-confi.patch
(working copy)
@@ -0,0 +1,39 @@
+From: Jesse Barnes 
+Date: Thu, 21 Jun 2012 15:13:50 -0700
+Subject: drm/i915: prefer wide & slow to fast & narrow in DP configs
+
+commit 2514bc510d0c3aadcc5204056bb440fa36845147 upstream.
+
+High frequency link configurations have the potential to cause trouble
+with long and/or cheap cables, so prefer slow and wide configurations
+instead.  This patch has the potential to cause trouble for eDP
+configurations that lie about available lanes, so if we run into that we
+can make it conditional on eDP.
+
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801
+Tested-by: pe...@colberg.org
+Signed-off-by: Jesse Barnes 
+Signed-off-by: Daniel Vetter 
+Signed-off-by: Jonathan Nieder 
+---
+ drivers/gpu/drm/i915/intel_dp.c |4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
+index d4c4937067fb..fae2050324bc 100644
+--- a/drivers/gpu/drm/i915/intel_dp.c
 b/drivers/gpu/drm/i915/intel_dp.c
+@@ -708,8 +708,8 @@ intel_dp_mode_fixup(struct drm_encoder *encoder, struct 
drm_display_mode *mode,
+ 
+   bpp = adjusted_mode->private_flags & INTEL_MODE_DP_FORCE_6BPC ? 18 : 24;
+ 
+-  for (lane_count = 1; lane_count <= max_lane_count; lane_count <<= 1) {
+-  for (clock = 0; clock <= max_clock; clock++) {
++  for (clock = 0; clock <= max_clock; clock++) {
++  for (lane_count = 1; lane_count <= max_lane_count; lane_count 
<<= 1) {
+   int link_avail = 
intel_dp_max_data_rate(intel_dp_link_clock(bws[clock]), lane_count);
+ 
+   if (intel_dp_link_required(mode->clock, bpp)
+-- 
+1.7.10.4
+
Index: debian/patches/series
===
--- debian/patches/series   (revision 19261)
+++ debian/patches/series   (working copy)
@@ -379,3 +379,5 @@
 features/all/fermi-accel/drm-nouveau-oops-increase-channel-dispc_vma-to-4.patch
 features/all/fermi-accel/drm-nvd0-disp-ignore-clock-set-if-no-pclk.patch
 features/all/fermi-accel/drm-nouveau-bump-version-to-1.0.0.patch
+
+bugfix/x86/drm-i915-prefer-wide-slow-to-fast-narrow-in-DP-confi.patch
Index: debian/changelog
===
--- debian/changelog(revision 19261)
+++ debian/changelog(working copy)
@@ -38,6 +38,10 @@
 - Refactor sub-channel use
 - Bump version to 1.0.0
 
+  [ Jonathan Nieder ]
+  * [x86] drm/i915: prefer wide & slow to fast & narrow in DP configs
+(Closes: #658662)
+
  -- Ben Hutchings   Fri, 29 Jun 2012 15:01:22 +0100
 
 linux (3.2.21-3) unstable; urgency=low

Processed: Re: drm/i915: no signal via DisplayPort on Sandy Bridge since Linux 3.2

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 658662 = upstream patch
Bug #658662 [linux-2.6] drm/i915: no signal via DisplayPort on Sandy Bridge 
since Linux 3.2
Removed tag(s) moreinfo and fixed-upstream.
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
658662: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658662
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.1342564162932.transcr...@bugs.debian.org

Bug#647741: still occurs in 3.2.15-1

[Vincent Lefevre]

Hi,

On 2012-07-17 13:11:25 -0500, Jonathan Nieder wrote:
> Vincent Lefevre wrote:
> > AFAIK, I haven't seen such a freeze for several weeks. If some bug
> > has been fixed in the kernel, it must be between 3.2.15 and 3.2.20.
> > The other possible change in the system I can see is that tmpfs is
> > no longer used for /tmp (after 2012-06-11).
> 
> Could you be convinced to reenable tmpfs for /tmp again, so we can
> see if that's the cause of the change?  (Unfortunately I suspect it
> is.)

I've reverted to tmpfs for /tmp. I haven't seen any problem yet,
but my laptop isn't currently under "normal" conditions. I may
have more information in a few days, or more likely at the end
of the month. If the problem doesn't reappear, I'll revert to
the Linux kernel 3.2.15.

Something else that has changed on 2012-06-19: I've upgraded
to Subversion 1.7.x, which means fewer disk accesses. But the
problem seemed to be unrelated to the use of Subversion.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20120717223850.ga7...@ypig.lip.ens-lyon.fr

Bug#647741: still occurs in 3.2.15-1

[Jonathan Nieder]

Vincent Lefevre wrote:

> I've reverted to tmpfs for /tmp. I haven't seen any problem yet,
> but my laptop isn't currently under "normal" conditions. I may
> have more information in a few days, or more likely at the end
> of the month. If the problem doesn't reappear, I'll revert to
> the Linux kernel 3.2.15.

Very helpful, thanks.

> Something else that has changed on 2012-06-19: I've upgraded
> to Subversion 1.7.x, which means fewer disk accesses. But the
> problem seemed to be unrelated to the use of Subversion.

Right, I wouldn't expect that to make the difference unless the main
source of load on this machine is from acting as an svn server.

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/20120717225249.GC25325@burratino

Re: [PATCH] scripts/package/builddeb: upgrade to current practices

[Jonathan Nieder]

Martin-Éric Racine wrote:

>  Could you tell us exactly what
> you did differently and why?

At least the "what" should be answerable by looking at what is in
linux-next.


--
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/20120717232741.GE25325@burratino

Bug#674153: [3.2.16 -> 3.2.17 regression] High reported CPU load when idle

[Jonathan Nieder]

tags 674153 = upstream patch moreinfo
quit

Hi again,

Anders Boström wrote:

> Starting with 3.2.17-1, the CPU load accounting is broken when the
> computer is idle. The CPU load is reported as >0.50 when
> idle. 3.2.16-1 don't suffer from this problem.
>
> Suspected patch is the upstream patch
> "sched: Fix nohz load accounting -- again!"
> commit 5e2d50da11f0e6ec3ce8fe658d7c83b0b4346c68 to 3.2 and
> originating from c308b56b5398779cd3da0f62ab26b0453494c3d4 .

Please test the attached patch against a 3.2.y kernel, for example
following the instructions below:

 0. prerequisites:

apt-get install git build-essential

 1. get the kernel history, if you don't already have it:

git clone \
  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

 2. fetch point releases:

cd linux
git remote add stable \
  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git fetch stable

 3. configure, build, test:

git checkout stable/linux-3.2.y
cp /boot/config-$(uname -r) .config; # current configuration
scripts/config --disable DEBUG_INFO
make localmodconfig; # optional: minimize configuration
make deb-pkg; # optionally with -j for parallel build
dpkg -i ../; # as root
reboot
... test test test ...

Hopefully that will reproduce the bug.  So

 4. try the patch:

cd linux
git am -3sc /path/to/the/patch
dpkg -i ../; # as root
reboot
... test test test ...

Hope that helps,
Jonathan
From: Peter Zijlstra 
Date: Fri, 22 Jun 2012 15:52:09 +0200
Subject: sched/nohz: Rewrite and fix load-avg computation -- again

commit 5167e8d5417bf5c322a703d2927daec727ea40dd upstream.

Thanks to Charles Wang for spotting the defects in the current code:

 - If we go idle during the sample window -- after sampling, we get a
   negative bias because we can negate our own sample.

 - If we wake up during the sample window we get a positive bias
   because we push the sample to a known active period.

So rewrite the entire nohz load-avg muck once again, now adding
copious documentation to the code.

Reported-and-tested-by: Doug Smythies 
Reported-and-tested-by: Charles Wang 
Signed-off-by: Peter Zijlstra 
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: sta...@kernel.org
Link: http://lkml.kernel.org/r/1340373782.18025.74.camel@twins
[ minor edits ]
Signed-off-by: Ingo Molnar 
Signed-off-by: Jonathan Nieder 
---
 include/linux/sched.h|8 ++
 kernel/sched.c   |  276 ++
 kernel/sched_idletask.c  |1 -
 kernel/time/tick-sched.c |2 +
 4 files changed, 213 insertions(+), 74 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 1c4f3e9b9bc5..5afa2a345ab1 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1892,6 +1892,14 @@ static inline int set_cpus_allowed_ptr(struct 
task_struct *p,
 }
 #endif
 
+#ifdef CONFIG_NO_HZ
+void calc_load_enter_idle(void);
+void calc_load_exit_idle(void);
+#else
+static inline void calc_load_enter_idle(void) { }
+static inline void calc_load_exit_idle(void) { }
+#endif /* CONFIG_NO_HZ */
+
 #ifndef CONFIG_CPUMASK_OFFSTACK
 static inline int set_cpus_allowed(struct task_struct *p, cpumask_t new_mask)
 {
diff --git a/kernel/sched.c b/kernel/sched.c
index 576a27fa5efc..52ac69b6d4c7 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -1885,7 +1885,6 @@ static void double_rq_unlock(struct rq *rq1, struct rq 
*rq2)
 
 #endif
 
-static void calc_load_account_idle(struct rq *this_rq);
 static void update_sysctl(void);
 static int get_update_sysctl_factor(void);
 static void update_cpu_load(struct rq *this_rq);
@@ -3401,11 +3400,73 @@ unsigned long this_cpu_load(void)
 }
 
 
+/*
+ * Global load-average calculations
+ *
+ * We take a distributed and async approach to calculating the global load-avg
+ * in order to minimize overhead.
+ *
+ * The global load average is an exponentially decaying average of nr_running +
+ * nr_uninterruptible.
+ *
+ * Once every LOAD_FREQ:
+ *
+ *   nr_active = 0;
+ *   for_each_possible_cpu(cpu)
+ * nr_active += cpu_of(cpu)->nr_running + cpu_of(cpu)->nr_uninterruptible;
+ *
+ *   avenrun[n] = avenrun[0] * exp_n + nr_active * (1 - exp_n)
+ *
+ * Due to a number of reasons the above turns in the mess below:
+ *
+ *  - for_each_possible_cpu() is prohibitively expensive on machines with
+ *serious number of cpus, therefore we need to take a distributed approach
+ *to calculating nr_active.
+ *
+ *\Sum_i x_i(t) = \Sum_i x_i(t) - x_i(t_0) | x_i(t_0) := 0
+ *  = \Sum_i { \Sum_j=1 x_i(t_j) - x_i(t_j-1) }
+ *
+ *So assuming nr_active := 0 when we start out -- true per definition, we
+ *can simply take per-cpu deltas and fold those into a global accumulate
+ *to obtain the same result. See calc_load_fold_active().
+ *
+ *Furthermore, in order to avoid synchronizing al

Processed: Re: [3.2.16 -> 3.2.17 regression] High reported CPU load when idle

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 674153 = upstream patch moreinfo
Bug #674153 [linux-2.6] linux-image-3.2.0-2-amd64: High CPU load when idle
Added tag(s) moreinfo and patch.
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
674153: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674153
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.134256757217774.transcr...@bugs.debian.org

Re: [PATCH] scripts/package/builddeb: upgrade to current practices

[Martin-Éric Racine]

2012/7/18 maximilian attems :
> On Tue, Jul 17, 2012 at 10:46:23PM +0300, Martin-Éric Racine wrote:
>> 2012/7/17 Jonathan Nieder :
>> >>
>> >>  Package: $fwpackagename
>> >>  Architecture: all
>> >> +Conflicts: firmware-linux-free, firmware-linux-nonfree
>> >> +Provides: firmware-linux-free, firmware-linux-nonfree
>> >> +Replaces: firmware-linux-free, firmware-linux-nonfree
>> >
>> > I assume you mean Breaks+Replaces.  Do the files actually overlap,
>> > or is this change being overly cautious?  I would expect the files
>> > not to overlap because the package build with deb-pkg puts firmware
>> > in a versioned subdirectory "/lib/firmware/".
>>
>> AFAIK they would overlap, hence the Conflicts.
>
> This is wrong and properly fixed in -next.

Max,

Exactly what is wrong with this fix? Could you tell us exactly what
you did differently and why?

Martin-Éric


--
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/CAPZXPQfBPXaRtK3QdY_PA=3grruz9+y3au-2avedvtwn8to...@mail.gmail.com

Bug#606964:

[Lorenzo Milesi]

I'm running into a similar issue with a Debian6 system fully updated (standard 
and -updates repos).
It's an IBM x3850, 16G of ram
I tried setting max_dom0_mem like stated here [1] but didn't solve the issue, 
the server reboots after scrubbing free ram. Still hadn't chance to connect a 
serial console.

I also tried setting:
GRUB_CMDLINE_XEN="dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin"
but no go.

Any other possible workaround?
I few months ago I installed two other servers with Debian6 and much more ram 
and didn't face the issue. 

[1] http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1698#c4
-- 
Lorenzo Milesi - lorenzo.mil...@yetopen.it

GPG/PGP Key-Id: 0xE704E230 - http://keyserver.linux.it


-- 
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/1072254951.33983.1342592898230.javamail.r...@yetopen.it