Bug#1051892: firmware-nonfree: CVE-2022-27635 CVE-2022-36351 CVE-2022-38076 CVE-2022-40964 CVE-2022-46329

[Moritz Mühlenhoff]

Source: firmware-nonfree
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerabilities were published for firmware-nonfree, all
fixed in linux-firmware/20230804 :

CVE-2022-27635[0]:
| Improper access control for some Intel(R) PROSet/Wireless WiFi and
| Killer(TM) WiFi software may allow a privileged user to potentially
| enable escalation of privilege via local access.

CVE-2022-36351[1]:
| Improper input validation in some Intel(R) PROSet/Wireless WiFi and
| Killer(TM) WiFi software may allow an unauthenticated user to
| potentially enable denial of service via adjacent access.

CVE-2022-38076[2]:
| Improper input validation in some Intel(R) PROSet/Wireless WiFi and
| Killer(TM) WiFi software may allow an authenticated user to
| potentially enable escalation of privilege via local access.

CVE-2022-40964[3]:
| Improper access control for some Intel(R) PROSet/Wireless WiFi and
| Killer(TM) WiFi software may allow a privileged user to potentially
| enable escalation of privilege via local access.

CVE-2022-46329[4]:
| Protection mechanism failure for some Intel(R) PROSet/Wireless WiFi
| software may allow a privileged user to potentially enable
| escalation of privilege via local access.

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-27635
https://www.cve.org/CVERecord?id=CVE-2022-27635
[1] https://security-tracker.debian.org/tracker/CVE-2022-36351
https://www.cve.org/CVERecord?id=CVE-2022-36351
[2] https://security-tracker.debian.org/tracker/CVE-2022-38076
https://www.cve.org/CVERecord?id=CVE-2022-38076
[3] https://security-tracker.debian.org/tracker/CVE-2022-40964
https://www.cve.org/CVERecord?id=CVE-2022-40964
[4] https://security-tracker.debian.org/tracker/CVE-2022-46329
https://www.cve.org/CVERecord?id=CVE-2022-46329

Please adjust the affected versions in the BTS as needed.

Re: Information About The Linux Kernel Maintenance In Debian

[Moritz Mühlenhoff]

Hi Federico!

> I'm a CERN employee currently evaluating Debian as a possible solution for our
> systems in use to control particle accelerators. I would like to know more 
> about
> how the Debian community handles the Linux kernel integration. In particular, 
> I
> can't easily find the following information:

Cool, if you have more specific followup questions, don't hesitate to ask.

> - Criteria to select a kernel version for a Debian release. It looks to me you
>are following LTS releases, but as you know kernel LTS is a moving target 
> in
>terms of duration. So, how you choose?

Debian releases happen every two years at approximately the end of the second
quarter of uneven years. kernel.org LTS releases are usually announced/picked
by end of each calendar year and the latest kernel.org LTS gets picked as the
kernel version for Debian. Debian 9 has 4.9.x, Debian 10 had 4.19.x, Debian
11 and 5.10 and Debian 12 will have 6.1.

> - How much a Debian kernel diverges from kernel.org release overtime?

Not much, you can have a look yourself for the current patches applied
to the 6.1.27 kernel which will be part of the initial Debian 12 release
(and future updates will rebase to 6.1.x LTS releases):
https://salsa.debian.org/kernel-team/linux/-/tree/sid/debian/patches

Anything in bugfix are cherrypicked bugfixes, debian/ contains a small
set of Debian-specific patches (for narrow toolchain or software freedom
issues) and feature contains a small set of backports (e.g. currently
for improved support for some non-x86 systems). In the past that also
included backported support for some NICs or RAID controllers (but these
usually only appear later in a release cycle).

> - I see you explain how to build and run any kernel from kernel.org, but I do
>not see and discouragement in doing so. Is this because you do not see any
>known incompatibilities ?

Generally running a patched or bespoke kernel is supported. It's mostly
a matter of people power to do it properly (since one needs to rebase to
security updates and applying custom patches might need rebases if underlying
kernel code for updated).

Some parts of the OS (e.g. systemd) expectsa given set of kernel
features to be present to operate properly, but usually these are
quite common and unlikely to be absent in custom configs anyway.

If you start with the current Debian kernel config as a base (found
under /boot/config-VERSION) you won't run into any surprises.

Cheers,
Moritz

Bug#1028451: 2nd DisplayPort doesn't get video

[Moritz Mühlenhoff]

Am Mon, Jan 16, 2023 at 12:46:37PM + schrieb Didier 'OdyX' Raboud:
> > I understand that would be annoying for you, but I don't think that it would
> > affect the majority of our users.
> 
> Hrm. More and more laptops come with usb-c only, and dongles/docks become more
> and more common.
> 
> It's clearly a serious regression, as such setups "just worked" with 6.0.

Not moving to 6.1.x (which is most likely the next Linux kernel LTS) is by far
a worse regression since it applies to every single Debian system.

As a community distro without paid, full time kernel maintainers we can't
just randomly stick to an older kernel tree and decide to assess/backport
hundreds of patches sent to stable@ every week.

Cheers,
Moritz

Re: Arch qualification for bookworm: call for DSA, Security, toolchain concerns

[Moritz Mühlenhoff]

Am Wed, Jun 22, 2022 at 10:05:37AM +0200 schrieb Graham Inggs:
> Hi,
> 
> As part of the interim architecture qualification for bookworm, we
> request that DSA, the security team, Wanna build, and the toolchain
> maintainers review and update their list of known concerns for bookworm
> release architectures.

> In particular, we would like to hear any new concerns for riscv64
> (see below).

There are no concerns für riscv64, but the quickly vaninishing
upstream support for i386 and the lack of active porters make i386
problematic from the Security Team's point of view.

For packages where new upstream releases are being introduced
this makes it extra brittle: Firefox/buster fails to compile due
to toolchain issues (triggers an ICE in GCC) for almost a year
now (since the update to ESR91) and for Chromium there have
also been random build failures (e.g. #1011096) and for Chromium
current releases no longer officially i386, quoting from the
chromium 102.0.5005.115-1 changelog entry:

| - debianization/support-i386.patch - re-enable support for i386 builds.
| Upstream no longer officially supports i386 builds on linux, so we
| are on our own here.

Essentially that means that noone can expect to have consistent security
updates when running i386 for the two main browsers.

These two specific issues could very well be addressed by dropping
i386 from the archs for Firefox/Thunderbird/Chromium, but Chromium
also spreads into the Qt web packages.

But there are also issues in software not following new upstream
releases in stable, e.g. #1006935 or 1009855 which broke Samba
in stable.

In addition there's also the issues with late or missing upstream
support for the quartely speculation attacks Ben has already mentioned.

Cheers,
Moritz

Re: Bug#990411: systemd: set kernel.unprivileged_bpf_disabled = 1

[Moritz Mühlenhoff]

Am Wed, Jun 30, 2021 at 08:33:01PM +0200 schrieb Tomas Pospisek:
> reassign 990411 linux-image-5.10.0-7-amd64
> 
> -
> 
> Thanks Michael, reassigning as proposed. Though I'm wondering (and not
> finding) whether there would be a more general package to assign this ticket
> to (such as linux-image-5.x or something).
> 
> Any thoughts on this problem in the security or the kernel team?

I agree it makes sense to disable it by default, but the ultimate
decision is up to the kernel team

Cheers,
Moritz

Bug#816176: linux-image-4.3.0-0.bpo.1-amd64: xhci_hub_control causes abnormally high CPU usage when no USB devices attached

[Moritz Mühlenhoff]

Am Tue, Sep 25, 2018 at 08:19:13PM +0200 schrieb Yves-Alexis Perez:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sun, 28 Feb 2016 12:19:43 +0100 Anders Nylander 
> wrote:
> 
> > Following the removal of of the USB device, I noticed very high CPU usage
> > being caused by kworker and ksoftirqd.
> > Using perf to log 10s of data and then reading the report, I noticed that
> > xhci_hcd/xhci_hub_control was generating a LOT of work for the kworker
> > (~42%).
> 
> I'm experiencing a very similar behavior on my ThinkPad X250 attached to a
> dock. It doesn't happen every time I resume, but quite often these days (on
> 4.18.8-1). Unplugging an USB3 disk plugged to the dock fixed the problem for
> me, and replugging it worked as well, so maybe there's some kind of loop I
> managed to break with that.
> 
> I also noticed https://bugzilla.redhat.com/show_bug.cgi?id=1325488 on the
> exact same setup, but there's no other info there.
> 
> I'll try to dig upstream, but unfortunately it's not that easily reproducible
> here.

Is that still an issue with current kernels?

Cheers,
Moritz

Re: bubblewrap: needs transition to non-setuid to accompany linux/5.10.x

[Moritz Mühlenhoff]

Am Mon, Dec 21, 2020 at 06:55:36PM + schrieb Simon McVittie:
> Package: bubblewrap
> Version: 0.4.1-1
> Severity: important
> Tags: security
> X-Debbugs-Cc: debian-kernel@lists.debian.org, t...@security.debian.org
> The simplest and most robust thing would be for bubblewrap to depend on
> procps, and ship a file /usr/lib/sysctl.d/50-bubblewrap.conf containing:
> 
> kernel.unprivileged_userns_clone=1

Why is this needed, given that anyone running a default bullseye kernel will 
have
that setting by default? Is this for the upgrade case before someone has 
rebooted
into the new kernel?

I would keep it simple: Make bubblewrap unconditionally depend on
unprivileged_userns_clone=1 and bail out with an error message if that's not 
the case.
There's a fair number of non-server use cases where it makes sense to disable
unprivileged user namespaces, but it seems like a fair tradeoff for bubblewrap
to simply depend on them being available.

Cheers,
Moritz

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Moritz Mühlenhoff]

On Sun, Nov 08, 2020 at 12:36:50PM +0200, Adrian Bunk wrote:
> On Fri, Jul 10, 2020 at 06:13:58PM +0100, Ben Hutchings wrote:
> > I don't know if this should be a blocker, but the MIPS builders are
> > still extremely slow for kernel builds.  In the worst case (mipsel:
> > mipsel-aql-{01,02}) it takes about 41 hours, which is 3 times longer
> > than the next slowest group of builders (armhf: hasse, henze, holby).
> > This can be a problem for getting security updates out promptly.
> 
> 12:32 < aurel32> starting now, eberlin, mipsel-aql-01 and mipsel-aql-02 
>  do not build security anymore
> 
> (The 7 faster buildds continue to build security.)

Thanks Aurelien, this is really nice and will be quite helpful for big packages.

Cheers,
Moritz

Bug#970984: linux-image-5.8.0-2-amd64: Please replace console scrollback

[Moritz Mühlenhoff]

On Fri, Sep 25, 2020 at 07:33:49PM -0400, Asher Gordon wrote:
> Package: src:linux
> Version: 5.8.10-1
> Severity: normal
> X-Debbugs-Cc: Asher Gordon 
> 
> Dear Maintainer,
> 
> After upgrading to linux-image-5.8.0-2, I noticed that scrollback is no
> longer available in the console. A quick look at the changelog
> ('apt changelog linux-image-amd64') indicates that this was done to fix
> CVE-2020-14390. Surely however, there must be a better way to fix this
> than simply removing this code entirely?
> 
> It is pretty annoying not having scrollback, and I'm sure I'm not the
> only one who would like scrollback replaced.

Yeah, I'm also bitten by this for my day-to-day workflows, but unfortunately
this was removed upstream, this is not a Debian-specific patch, so this
needs to be fixed upstream, before it becomes available in Debian again.

Cheers,
Moritz

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Moritz Mühlenhoff]

Paul Gevers wrote:
> As part of the interim architecture qualification for bullseye, we
> request that DSA, the security team, Wanna build, and the toolchain
> maintainers review and update their list of known concerns for bullseye
> release architectures.

There's nothing really of concern from the security team PoV, we don't
withhold security updates due to missing archs, so the worst case is that
some archs are outdated (happens to openjdk from time to time).

> Whilst porters remain ultimately responsible for ensuring the
> architectures are ready for release, we do expect that you / your team
> are willing to assist with clarifications of the concerns and to apply
> patches/changes in a timely manner to resolve the concerns.

I think the porter requirement for i386 should no longer be waived (the
current wiki page still says so).

i386 is legacy hardware for a long time and increasingly starts to lose
upstream support (and most other distros ceased support a well). If there
people who care about i386 for whatever reason, they should form a
debian-i386@ porter list which offers to fix i386-specific issues.

Cheers,
Moritz

Bug#962134: add Sound Open Firmware

[Moritz Mühlenhoff]

On Wed, Jun 03, 2020 at 05:25:21PM +0200, Marek Straka wrote:
> Package: firmware-linux-nonfree
> Version: 20190717-2
> Severity: normal
> 
> 
> Add Sound Open Firmware:
> https://github.com/thesofproject/sof-bin
> https://www.sofproject.org/

This is free software and could go into main or am I missing something?

Cheers,
Moritz

Bug#898446: Please reconsider enabling the user namespaces by default

[Moritz Mühlenhoff]

On Mon, Mar 30, 2020 at 10:56:48AM +0100, Simon McVittie wrote:
> On Fri, 11 May 2018 at 20:44:50 +0200, Laurent Bigonville wrote:
> > Firefox (and probably other applications) are using user namespaces these
> > days to enhance the security.
> > 
> > Debian is disabling these since 2013, the original patch states it's a
> > short term solution, but we are here 5 years later and they are still
> > disabled.
> > 
> > Apparently debian (and ubuntu) and arch are the only distributions
> > disabling the user namespaces.
> 
> A cross-distro status update:
> 
> - Debian still disables user namespaces by default with our
>   /proc/sys/kernel/unprivileged_userns_clone patch.
> 
> - Ubuntu now enables user namespaces by default. I think they still apply
>   the /proc/sys/kernel/unprivileged_userns_clone patch, but with the
>   default flipped?
> 
> - Arch Linux now enables user namespaces in their default kernel. There
>   is a non-default kernel, "linux-hardened", which applies the same patch
>   as Debian.
> 
> - Apparently RHEL 7 also disables user namespaces, although instead of
>   patching in a new sysctl, they set /proc/sys/user/max_user_namespaces
>   to 0 (which is an upstream thing since Linux 4.9).
> 
> On Sun, 13 May 2018 at 22:57:56 +0200, Moritz Mühlenhoff wrote:
> > Ben Hutchings wrote:
> > > And this still mitigates a significant fraction of the security issues
> > > found in the kernel.
> > 
> > A quite significant fraction; on average this neutralises a root privilege
> > escalation every month or so. This is really not something that we should
> > re-enable any time soon.
> 
> Is this still the case, or has the status of user namespaces settled down?

It think we should still keep it disabled for Bullseye, there's still a good
rate of local privilege escalation vulnerabilities in core code with
unpriv usernamespaces. We could enable it after the Bullseye release and
tally security issues enabled by unpriv namespaces and then make a
decision after a year or so.

Cheers,
Moritz

Re: Bug#917941: Installation Buster on HP 17-by Notebook

[Moritz Mühlenhoff]

On Thu, Jan 03, 2019 at 05:21:05PM +0100, Cyril Brulebois wrote:
> 
>  1. 
> https://github.com/endlessm/linux/tree/master/drivers/net/wireless/rtl8821ce
> 
> So I guess there's not much we can do on the debian-installer side, we
> would need to get this module merged into our linux source package to
> make use of it, and I don't think the kernel team would add random out
> of tree modules. ISTR backporting drivers is something that happens, so
> we might get this module supported in a later 4.19.x release, once it
> reaches mainline and someone backports it?
> 
> Cc'ing kernel team to make sure I'm not entirely wrong here. Maybe also
> steal this bug away from installation-reports and have it retitled “no
> support for rtl8821ce” or something similar?

An official driver for Realtek 802.11ac chips was added to Linux 5.2
(rtw88) which is maintained by Realtek staff. Unfortunately it currently
only supports the RTL8822 chips, but the initial commit for 5.2 mentioned
that also want to add support for RTL8821.

Cheers,
Moritz

Bug#924349: linux-image-4.19.0-2-amd64: IPv6 reverse path filtering incorrectly removes IPv6 traffic from bridge

[Moritz Mühlenhoff]

On Sun, Apr 14, 2019 at 09:53:12AM +0200, Ralf Jung wrote:
> Hi Salvatore,
> 
> >> A self-compiled upstream 4.20.14 kernel does not show this problem, but the
> >> latest kernel in testing still does.
> > 
> > have you tried to isolate the fixing commit for this issue?
> 
> No, I have not.
> We are having a string of weird issues in our network (that we run in our free
> time) so far this year so all the time I had went into debugging this and 
> other
> issues.
> 
> Would it be helpful for you to know the fixing commit?

If the fixing commit can be identified and if it's not too intrusive to
backport, it could be considered for the 4.19 stable backports and would
thus be fixed in Buster (as buster is following the 4.19.x kernels both
in the freeze and during the lifetime of the buster stable release.

Cheers,
Moritz

Re: Newer kernel for jessie backports

[Moritz Mühlenhoff]

>
> In jessie backports there is currently a 4.9 kernel 
> (4.9.110-3+debu5~deb8u1) which is based on stretch 4.9.110-3+deb9u2. Since 
> stretch now has 4.9.144-3.1 are there any plans to make a 
> 4.9.144-3.1~deb8u1 for jessie?
>
> I have a piece of hardware that requires the newer kernel but will sadly 
> not be able to upgrade to stretch for a few months.
>
> Is there something I can do to help this along?

This kernel is maintained through Debian LTS now, please contact
debian-...@lists.debian.org instead.

Cheers,
Moritz

Re: Upcoming stable point release (9.8)

[Moritz Mühlenhoff]

Ben Hutchings  schrieb:
> As there isn't much time left before the point release, I am inclined
> to make one more upload based on 4.9.144 that just fixes the ceph
> regression and any other known recent regressions.

+1

And FWIW, I've tested 4.9.144-1 on a number of systems and didn't run
into any regressions (not using ceph).

Cheers,
Moritz

Bug#891067: Backport of Perc 740/840 for Stretch

[Moritz Mühlenhoff]

On Sun, Sep 16, 2018 at 03:48:50PM +, Phil Lavin wrote:
> We have some spare hardware with a H740P installed. Would having access to 
> the IDRAC to run some tests help?

Simply install the new kernel and let us know if everything works as expected,
no need for IDRAC access.

The updated kernel is now also available in stretch-proposed-updates, which
can be added via the following apt source:

deb http://ftp.debian.org/debian/ stretch-proposed-updates main

Cheers,
Moritz
 

Re: driver fix pull from latest kernel and backport.

[Moritz Mühlenhoff]

Sri Reddy  schrieb:
> I'm using debian stretch and  we find a fix for a specific device in latest
> kernel tree(4.19)
>
> https://github.com/torvalds/linux/commit/851a15114895c5bce163a6f2d57e0aa4658a1be4#diff-5f28e56418c0a55eab1cfe342df922a2
>
> How to request this change into debian kernel and backport it to stretch
> (4.9)?

This patch was CCed to sta...@vger.kernel.org and got merged into 4.9.128,
it will reach the stretch kernel when it's updated to 4.9.128 or later.

Cheers,
Moritz

Bug#907911: linux: Resetting chip after gpu hang (crash dump) when zooming on the opencaching.de map

[Moritz Mühlenhoff]

On Tue, Sep 04, 2018 at 04:35:07PM +, Thorsten Glaser wrote:
> forwarded 907911 https://bugs.freedesktop.org/show_bug.cgi?id=107824
> thanks
> 
> Ben Hutchings dixit:
> 
> >Please can you also report this upstream as requested in the error
> 
> According to DevRef §3.1.4 that’s your job as maintainer

I've filed #908155 against developers-reference to fix this.

Cheers,
Moritz

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Moritz Mühlenhoff]

On Fri, Jun 29, 2018 at 10:33:16PM +0100, Ben Hutchings wrote:
> On Fri, 2018-06-29 at 22:31 +0200, Moritz Mühlenhoff wrote:
> > Niels Thykier wrote:
> > > If the issues and concerns from you or your team are not up to date,
> > > then please follow up to this email (keeping debian-release@l.d.o and
> > > debian-ports@l.d.o in CC to ensure both parties are notified).
> > 
> > Two issues that we discussed at the recent Security Team sprint wrt
> > problems affecting buster:
> > 
> > (1) Linux upstream security support for i386 seems at risk at this point.
> > E.g. KPTI for i386 still isn't merged in Linux master half a year later 
> > after
> > the public Meltdown disclosure in early January (and the development of KPTI
> > started months before that). Someone at SuSE actually developed patches
> > as an older SLES release using Linux 3.0 (!) still supports i386, but that
> > will also EOL at some point and if we don't have the manpower to
> > develop upstream fixes for future i386-specific flaws.
> > 
> > It's not a strict blocker, but we wanted to raise the discussion whether
> > it still makes sense to ship 32 bit kernels for buster, which means with
> > support until ~ 2022.
> [...]
> 
> The lack of Meltdown mitigation on i386 is concerning, though I remain
> somewhat hopeful that it will get fixes eventually.  A quick look
> through kernel-sec finds maybe 3 other i386-specific issues in the last
> 5 years (CVE-2013-0190, CVE-2014-4508, CVE-2016-3672), and none of the
> fixes were difficult to backport.

Fair enough. Ultimately it's your call, but we wanted to raise it due to
the long term perspective upstream.

> It's worth noting that Meltdown also never got mitigated for any of the
> other affected architectures (at least ppc64el and s390x) in jessie,
> despite being addressed upstream.  So I don't think it makes sense to
> pick on i386 as being particularly vulnerable.

Well, the difference is that 99% of users still installing a buster system
with i386 are doing it out of ignorance and would otherwise be protected
if they'd picked amd64. For ppc64el and s390x no such alternative exists.

Cheers,
Moritz

Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Moritz Mühlenhoff]

Niels Thykier wrote:
> If the issues and concerns from you or your team are not up to date,
> then please follow up to this email (keeping debian-release@l.d.o and
> debian-ports@l.d.o in CC to ensure both parties are notified).

Two issues that we discussed at the recent Security Team sprint wrt
problems affecting buster:

(1) Linux upstream security support for i386 seems at risk at this point.
E.g. KPTI for i386 still isn't merged in Linux master half a year later after
the public Meltdown disclosure in early January (and the development of KPTI
started months before that). Someone at SuSE actually developed patches
as an older SLES release using Linux 3.0 (!) still supports i386, but that
will also EOL at some point and if we don't have the manpower to
develop upstream fixes for future i386-specific flaws.

It's not a strict blocker, but we wanted to raise the discussion whether
it still makes sense to ship 32 bit kernels for buster, which means with
support until ~ 2022.

(2) Not an architectual issue, but a cross-arch problem: Buster is
reaching a critical mass of applications written in Go and our tooling
for security updates is absolutely not in a position to deal with it's
approach to link everything statically:

dak on ftpmaster and security-master don't share tarballs, IOW the
first time an application is updated in foo-security it's needs an
upload including the orig tarball. That's somewhat manageable for
standard security updates, but if we'd need to recompile all reverse
deps with individual source uploads (which would be dozens to hundreds
of packages if it's e.g. in Golang itself), it ends up being total
madness.

To be able to support Go-based applications in buster-security we
need tooling which
- detects which packages need a rebuild if a given Go package has been
  fixed.
- handles the actual rebuilds and sharing tarballs between security-master
  and ftp-master is an automated manner

Cheers,
Moritz

Bug#898446: Please reconsider enabling the user namespaces by default

[Moritz Mühlenhoff]

Ben Hutchings wrote:
> And this still mitigates a significant fraction of the security issues
> found in the kernel.

A quite significant fraction; on average this neutralises a root privilege
escalation every month or so. This is really not something that we should
re-enable any time soon.

Cheers,
Moritz

Re: [stretch] ABI bump for 4.9 with retpoline support?

[Moritz Mühlenhoff]

On Sat, Feb 17, 2018 at 08:57:42PM +0100, Yves-Alexis Perez wrote:
> On Sat, 2018-02-17 at 19:51 +, Ben Hutchings wrote:
> > I think we should bump ABI again.
> 
> Thanks for the feedback. I'll do that and remove all the ABI reverts and
> ignores.
> 
> >   We should also do the equivalent of
> > these changes in sid, with s/gcc-7/gcc-6/.
> > 
> >   * [x86] Add versioned build-dependency on gcc-7 for retpoline support
> >   * [x86] linux-compiler-gcc-7-x86: Add versioned dependency on gcc-7 for
> > retpoline support
> >   * [x86] linux-headers: Depend on updated linux-compiler-gcc-7-x86
> 
> I did the linux-compiler-gcc-6-x86 one but not the other two, Will do as well.
> 
> Should we upload this one through security-master (for the CVE-2017-5715 fix)
> or through stretch-pu again?

I'd say via security.debian.org, to get the CVE-2017-5715 fix out to users.

At this point it seems that for spectre/v1 it will take quite some until all
the affected code paths are identified, so maybe these will rather trickle in
piece by piece now array_index_nospec() has landed.

Cheers,
Moritz

Bug#890424: Patches for Meltdown on Power

[Moritz Mühlenhoff]

On Wed, Feb 14, 2018 at 04:07:29PM +0100, Frédéric Bonnard wrote:
> Source: linux
> Source-Version: 4.9.65-3+deb9u2
> Tags: patch
> 
> --
> 
> Hi,
> beginning January a patch series has been sent on the LKML which include
> a patch to prevent the Meltdown vulnerability on some Power machines :
> https://lkml.org/lkml/2018/1/8/649
> This series has been upstreamed and a few days ago, the backport to 4.9
> stable kernel been included :
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-4.9.y=grep=powerpc
> 
> powerpc/64s: Allow control of RFI flush via debugfs
> powerpc/64s: Wire up cpu_show_meltdown()
> powerpc/powernv: Check device-tree for RFI flush settings
> powerpc/pseries: Query hypervisor for RFI flush settings
> powerpc/64s: Support disabling RFI flush with no_rfi_flush and nopti
> powerpc/64s: Add support for RFI flush of L1-D cache
> powerpc/64s: Convert slb_miss_common to use RFI_TO_USER/KERNEL
> powerpc/64: Convert the syscall exit path to use RFI_TO_USER/KERNEL
> powerpc/64: Convert fast_exception_return to use RFI_TO_USER/KERNEL
> powerpc/64: Add macros for annotating the destination of rfid/hrfid
> powerpc/pseries: Add H_GET_CPU_CHARACTERISTICS flags & wrapper
> 
> This will be available in 4.9.81 but given the CVE associated (
> https://security-tracker.debian.org/tracker/CVE-2017-5754 ) it may be
> included in debian stable 4.9.65-3+deb9u2 maybe ?
> Regards,

We're rebasing to the latest 4.9.x kernel from time to time (current
s-p-u has 4.9.80, but we'll probably update again), so this will also
reach stretch at some point. 

Cheers,
Moritz

Re: enforce fs.protected_hardlinks in sysctl.d by default

[Moritz Mühlenhoff]

Antoine Beaupré wrote:
> There are, however, people *not* running Debian-built kernels, and
> sometimes for good reasons. This is a configuration that we should
> still support.

Is it supported, but it's also clearly documented that people need to
enable this sysctl for custom kernels:
https://www.debian.org/releases/jessie/amd64/release-notes/ch-whats-new.en.html#security

> Incidentally, I wonder if we should remove the patch we have on the
> Debian kernels to change the defaults, and instead rely on the
> sysctl. I have added the kernel team in CC to have their input.

Why revert the kernel? That doesn't buy us anything. It would be
better to ask upstream to revisit this decision (e.g. by contacting
KSPP mailing list). I suppose that SuSE, Ubuntu and Red Hat have
are shipping similar patches/defaults, so it's probably safe to say
that those protections are now the status quo (as opposed to five
years ago when that feature was freshly introduced).

Cheers,
Moritz

Re: Kernel version for stretch

[Moritz Mühlenhoff]

On Thu, Jan 28, 2016 at 08:15:30PM +, Ben Hutchings wrote:
> On Thu, 2016-01-28 at 20:01 +0100, Moritz Mühlenhoff wrote:
> > Ben Hutchings <b...@decadent.org.uk> wrote:
> > > For stretch, I would very much like to choose a kernel version for
> > > stretch that gets longterm maintenance by Greg Kroah-Hartman. That
> > > lasts 2 years from release, after which someone else (maybe me) can
> > > take over.
> > 
> > Luis Henriques and Kamal Mostafa maintain the ckt stable kernels
> > for Ubuntu-non-LTS releases for two years.
> 
> Not in general; it can be as little as 12 months (e.g. 3.11-ckt).

I would need to confirm that, but AFAICS the non-LTS kernels after 3.11 are
all maintained for two years (since they are now made available at "hardware
enablement kernels" for the Ubuntu LTS releases.

> > We could base the stretch kernel on the underlying ckt kernel
> > series used for Ubuntu 16.04 or 16.10?
> 
> Given the politics involved, I would rather not do that twice in a row.

Ok.

Cheers,
Moritz

Re: Kernel version for stretch

[Moritz Mühlenhoff]

Ben Hutchings  wrote:
> For stretch, I would very much like to choose a kernel version for
> stretch that gets longterm maintenance by Greg Kroah-Hartman. That
> lasts 2 years from release, after which someone else (maybe me) can
> take over.

Luis Henriques and Kamal Mostafa maintain the ckt stable kernels
for Ubuntu-non-LTS releases for two years.

We could base the stretch kernel on the underlying ckt kernel
series used for Ubuntu 16.04 or 16.10?

Cheers,
Moritz

Re: Debian 8/jessie - SECCOMP_FILTER_FLAG_TSYNC [PATH]

[Moritz Mühlenhoff]

Kees Cook k...@debian.org schrieb:
 Thanks for doing this backport! It looks like it's missing one bug fix
 patch, though:

 https://git.kernel.org/linus/69f6a34bdeea4fec50bb90619bc9602973119572

 This is needed or some architectures in UP mode will hang when creating
 the init process.

 Also, this add the syscall for ARM:

 https://git.kernel.org/linus/839669714f0a85d677283690e6e164fb698ce206

 And MIPS:

 https://git.kernel.org/linus/8855d608c145c1ca0e26f4da00741080bb49d80d

 And a fix for ARM ptrace when changing the syscall during seccomp:

 https://git.kernel.org/linus/42309ab450b608ddcfafa90e4cfa93a5001ecfba

Kees, could you submit these fixes to the 3.16.ckt-X stable tree?

This way it will enter future jessie updates and the respective
Ubuntu release based on 3.16.

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/slrnmfrse9.er9@inutil.org

Re: stable-security upload of linux

[Moritz Mühlenhoff]

On Sun, Feb 22, 2015 at 09:12:27PM +, Ben Hutchings wrote:
 On Sat, 2015-02-21 at 17:43 +, Ben Hutchings wrote:
  There are several unembargoed CVEs affecting linux in wheezy, and a few
  remaining regressions from the last two updates.
  
  I've prepared a security update (version 3.2.65-1+deb7u2) that addresses
  most of these.  Let me know whether it's OK to upload this.
 
 I'm putting together a DSA text for this now.

Bummer, I had already written one yesterday afternoon, but forgot
about the svn.

I've mostly used yours now with some changes of myself merged in
(e.g. crediting the people who discovered it).

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/20150223173957.GA2395@pisco.westfalen.local

Re: retiring from security team

[Moritz Mühlenhoff]

On Fri, Sep 26, 2014 at 02:02:35PM -0600, dann frazier wrote:
 hey,
  I've been unable to find time to work on kernel security updates for
 some time now and - since I don't see that changing - it is time I
 officially retire from the team. DSA, please remove me from the
 appropriate groups.
 
  Thanks to Martin  Moritz for helping me get started with my first
 DSAs in '05, '06 (woody was painful[1]), to Ben, Moritz and Salvatore
 for keeping the kernel DSAs coming since I started slacking, and to
 the rest of you for continuing to help keep my computers secure :)

Thanks for all the work over the years! I had almost forgotten how
intricate woody kernel updates were at the time :-)

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/20140927090951.GA3359@pisco.westfalen.local

Re: Uploading linux (3.2.63-1)

[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

Re: Kernel version for jessie

[Moritz Mühlenhoff]

Ben Hutchings b...@decadent.org.uk schrieb:
 Ubuntu 14.10 is planned to use Linux 3.16, in which case Ubuntu will
 maintain a 3.16-stable branch (not blessed by kernel.org, but still
 following the same rules).

 So we have a choice between:

 Linux 3.14-stable
 - Supported by Greg for about 2 years after release (March 2014)
 - As an official kernel.org branch, it is likely to get some more
   testing and review, and more backports from upstream maintainers

 Linux 3.16-stable
 - Supported by Ubuntu kernel team for about 15-18 months after distro
   release (October 2014)
 - Will support more current hardware and need fewer driver backports

 Both of these will be supported until about the same time that wheezy
 reaches EOL, which is when I intend to stop maintaining 3.2-stable.  At
 that point, I would be prepared to take over maintainership of either of
 the newer branches.

 There's not an obvious winner out of these two options, but we should
 choose fairly soon.  Please speak up with arguments either way.

If there's a firm commitment by Canonical to maintain a 3.16 branch
we should use that tree. This will provide the 32/64 bit UEFI changes
from 3.15.

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/slrnlskel1.2ho@inutil.org

Re: Kernel version for jessie

[Moritz Mühlenhoff]

Ben Hutchings b...@decadent.org.uk schrieb:

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

 Based on a linear regression of Linux release dates since 3.2, I
 extrapolated that the latest stable release at freeze time will likely
 be 3.17: http://www.decadent.org.uk/ben/tmp/linux-release-dates.svg.
 However, there will be little time for any necessary but disruptive
 fixes or packaging changes before the freeze.

 The earlier we freeze the kernel, the more work will be required to
 backport fixes and hardware enablement during the jessie support period.
 So I think that 3.16 would be the best fit.

 It is also very unlikely that a PREEMPT_RT patchset will be available
 for 3.15 or 3.17, but there probably will be one for 3.16.

 I won't have time to take on maintenance of another longterm stable
 branch besides 3.2, so I think it is important that the version we use
 can be based on a longterm stable branch maintained by someone else.  On
 that basis, I would like to propose to Greg K-H that his next longterm
 branch be based on 3.16.

 Does anyone disagree with that?

Sounds good to me.

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/slrnlm6pvd.28c@inutil.org

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Moritz Mühlenhoff]

Ben Hutchings b...@decadent.org.uk schrieb:
 There was a recent discussion on -private where I think there was some
 consensus that a grsecurity kernel package could be included in Debian
 as a separate source package.

Ack. Quoting myself from the thread on -private for public discussion:

| If grsec is introduced, then it needs to be separate source package to
| remain as close to upstream as possible (modulo DFSG firmware bits).
| 
| If it is a different source package (and not building linux-libc-dev)
| I don't see much of a problem if the grsec kernel is two or three
| revisions behind src:linux. 
|
| As far as security triage for grsec is concerned it will be sufficient to
| follow the grsec releases in stable. Ubuntu 14.04 LTS will be based on
| 3.13, so all important bugfixes will land in 3.13.x longterm (plus
| several vulnerabilities will be moot in grsec)

As for the proposal on amd64-hardened:

I would prefer if we focus on the hardening features available for
all (making everyone profit from enhanced security). Some of the
plans mentioned in 
https://lists.debian.org/debian-devel-announce/2014/03/msg4.html
could use someone driving the effort to speed things up:

- GCC 4.9 has been released today, organise an archive rebuild with
  gcc-defaults pointing to 4.9 and dpkg-buildflags emitting
  -fstack-protector-strong

- Work on hidepid=1 by default, post debs for people to test-drive and
  fixup regressions in userland

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/slrnlldj9o.2ie@inutil.org

Re: Bug#605090: Proposing amd64-hardened architecture for Debian

[Moritz Mühlenhoff]

Moritz Mühlenhoff j...@inutil.org schrieb:
 all (making everyone profit from enhanced security). Some of the
 plans mentioned in 
 https://lists.debian.org/debian-devel-announce/2014/03/msg4.html
 could use someone driving the effort to speed things up:

Also:
- Work on rootless Xorg for jessie (http://lwn.net/Articles/590296/).

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/slrnlldjlj.316@inutil.org

Bug#593183: broken rt2860 support after upgrade to 2.6.32-18 from -16

[Moritz Mühlenhoff]

On Thu, Jul 18, 2013 at 10:57:24AM -0700, Jonathan Nieder wrote:
 Hi,
 
 Moritz Muehlenhoff wrote:
  On Thu, Jan 19, 2012 at 01:23:31AM -0600, Raphael Geissert wrote:
  On 27 November 2011 01:09, Jonathan Nieder jrnie...@gmail.com wrote:
  Raphael Geissert wrote:
 
  I just tried with a visible AP (using the same crypto settings) and it 
  works.
  So, the changes to the module appear to only break support for hidden 
  APs.
 
  Thanks for finding this.  As Ben mentioned, Realtek's original
  rt2860sta driver was abandoned in favor of rt2800pci from the rt2x00
  project[*] (the usual risk of using a staging driver).
 [...]
  Has this been tracked down or shall we go ahead and close the bug?
 
 It's not serious enough to fix in oldstable.  Thanks for asking.

Of course it wouldn't warrant a fix in oldstable, but I don't see any
confirmation that this is fixed in Wheezy? That's why I asked.

Cheers,
Moritz


-- 
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/20130718182243.GA7744@pisco.westfalen.local

Bug#712999: linux-image-3.9-1-amd64: Unable to find LVM volume

[Moritz Mühlenhoff]

On Tue, Jul 09, 2013 at 08:09:47PM -0400, A. Maitland Bottoms wrote:
 I think I was just bit by this bug.
 
 Getting from wheezy-backports today,
 initramfs-tools   0.112~bpo70+1
 linux-image-3.9-0.bpo.1-amd64 3.9.6-1~bpo70+1
 
 I found that adding rootdelay=1 to the grub boot kernel argument list
 was enough to get linux-image-3.9-0.bpo.1-amd64 to boot.
 
 My system is AMD64 Phenom II with 6.0 Gbps SATA and SSD,
 I suppose too fast for the kernel lvm finding logic without
 the rootdelay parameter set. (Then again, stock wheezy
 linux-image-3.2.0-4-amd64 3.2.46-1 boots just fine
 without that parameter sepecified.)

I can confirm this as well: I tried installing 10-pre7 on four
different systems, which could run/boot with the Wheezy 3.2 kernel
and two out of the four needed at least a rootdelay of 1.

Cheers,
Moritz


-- 
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/20130714163012.GA4736@pisco.westfalen.local

Bug#678731: linux-2.6: Please build dummy_hcd and g_mass_storage modules

[Moritz Mühlenhoff]

On Thu, Jun 28, 2012 at 09:48:19PM +0200, intrigeri wrote:
 Hi,
 
 berta...@ptitcanardnoir.org wrote (27 Jun 2012 11:00:22 GMT) :
  On Wed, Jun 27, 2012 at 04:32:31AM +0100, Ben Hutchings wrote:
 
  Yes, but I think it would make more sense to emulate a USB storage
  device in qemu rather than the host kernel.
 
 I do agree.
 
 bertagaz and I have spent a bit more time testing and comparing the
 available options. Our results are summed up there:
 https://tails.boum.org/todo/automated_builds_and_tests/USB/
 
 tl;dr -- as far as Wheezy is concerned:
   * qemu-kvm emulates just fine a USB 2.0 mass storage device, and
 knows how to boot from it; personally, I'd rather use that than
 a dedicated kernel module.
   * with qemu-kvm on the command-line: no need for an additional
 kernel module
   * with a libvirt stack: a missing interface in some abstraction
 layer makes it a pain to use the qemu-kvm USB emulation of
 removable mass storage devices.

How's the state of affairs with libvirt 1.1 from unstable?

Cheers,
Moritz


-- 
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/20130708162252.GA6647@pisco.westfalen.local

Bug#606713: Closing

[Moritz Mühlenhoff]

On Sat, Jun 29, 2013 at 01:35:37PM +0800, Paul Wise wrote:
 Control: reopen -1
 Control: reassign -1 src:linux
 
 On Thu, 2013-06-27 at 19:42 +0200, Moritz Mühlenhoff wrote:
 
  We don't have the resources to reproduce the complete backlog of all older 
  kernel
  bugs, so we're closing this bug for now. If you can reproduce the bug with 
  Debian Wheezy
  or a more recent kernel from testing or unstable, please reopen the bug by 
  sending
  a mail to cont...@bugs.debian.org with the following three commands 
  included in the
  mail:
 
 I can still reproduce this bug with Linux from testing, attached the
 debug tarball for Linux 3.9. Please Let me know if there is any other
 information I can add to the bug to help fix the issue.

Please test whether it's still reproducible with the kernel from 
experimental. If so, please report this upstream at http://bugzilla.kernel.org, 
product ACPI and component Power-Other.

The reason why we ask you to file this bug report yourself is because
the kernel maintainers for that component will have questions specific
to your setup/hardware.

Once you've filed the bug, please mark the bug as forwarded.

If a fix is found upstream, we can then proceed and investigate,
whether the change is backportable to the kernel in Debian 7.x
(Wheezy).

Cheers,
Moritz


-- 
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/20130705181055.GA7949@pisco.westfalen.local

Re: Linux 3.2 in wheezy

[Moritz Mühlenhoff]

Ben Hutchings b...@decadent.org.uk schrieb:
 But practically this means that we have to either carry
 the featureset indefinitely or disappoint users by removing it in a
 later release.  (See the complaints about removing OpenVZ in wheezy
 despite 4 years' advance notice of this.)

That's not really comparable: Dropping a virtualisation flavour
leaves people with OS guests they can no longer operate, while
dropping grsec at a later point only makes them fall back to standard
Linux security (if we set GRKERNSEC_NO_RBAC=y)

Cheers,
Moritz


-- 
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/slrnjidtsd.5q0@inutil.org

Re: Linux kernel version for wheezy

[Moritz Mühlenhoff]

Ben Hutchings b...@decadent.org.uk schrieb:

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

 If I don't hear any objections from the kernel team in the next week,
 I'm going to assume that everyone is happy to go with Linux 3.2.

 The decision needs to be communicated to Debian developers in general
 (d-d-a) and to Greg Kroah-Hartman in his capacity as organiser of
 stable/longterm series.  If we go with 3.2 then we will also want to
 work closely with the Ubuntu kernel maintainers.

Despite my initial preference to go with 3.3/3.4 I think that's
the best option. There's nothing mouth-watering in 3.3 and the
time frame between the release of 3.2 and the Wheezy release will
be similar to the interval between 2.6.32 and Squeeze.

Cheers,
Moritz



-- 
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/slrnjho3rp.3oo@inutil.org

Re: [Fwd: Latest kernel stable/longterm status]

[Moritz Mühlenhoff]

Ben Hutchings b...@decadent.org.uk schrieb:

 --=-GV+LLjr9UIrWlGGcGT1j
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable

 We need to make a decision soon on whether we will use Linux 3.2 for
 wheezy or wait for a later release.  Whichever one we choose, we need to
 make sure someone (possibly one of us) maintains a longterm branch for
 it.  I am strongly disinclined to choose a version that puts us on our
 own, and therefore I would prefer to use Linux 3.2 along with Ubuntu.

What's Ubuntu's policy on backporting drivers?

If it's a common tree for Ubuntu and Debian we could keep 
stable bugfixes plus drivers backports in a common tree
instead of the model in Squeeze, where backported drivers
were added on top of 2.6.32.

Cheers,
Moritz


-- 
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/slrnjhbimo.iir@inutil.org

Re: Bug#652014: Linux 3.2: Enable Hyper-V kernel modules

[Moritz Mühlenhoff]

Ben Hutchings b...@decadent.org.uk schrieb:

 Could this be taken as an opportunity to enable them in the default
 kernel image in experimental (i386, amd64) allowing testing with Debian?=
=20
 Currently they are not unloadable, if that is a problem, I know there is=
=20
 a patch floating in the upstream.

 Do you have a reference for that?  (Commit hash, message ID, URL...)

http://permalink.gmane.org/gmane.linux.kernel/1227920 

Cheers,
Moritz


-- 
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/slrnjeiecf.3vd@inutil.org

Bug#644604:

[Moritz Mühlenhoff]

On Fri, Oct 14, 2011 at 02:22:37PM +0100, Ian Campbell wrote:
 On Fri, 2011-10-14 at 14:11 +0200, Mauro wrote:
  Hello, sorry for bother.
  I've exactly the same problem explained in the bug but with xen 4.0.1
  distributed with squeeze.
  I can't do live migrations too.
  Sorry for question but when do you think you can solve the bug?
 
 I sent out a fix on Monday[0] but haven't heard from the upstream
 maintainers yet. I'll chase them up.

We fixed that at work by reverting the following patch from 2.6.32.42,
which is sufficient to fix the regression:

commit 652c98bac315a2253628885f05cfd5f30b553ae5
Author: Thomas Gleixner t...@linutronix.de
Date:   Sat Feb 5 20:08:59 2011 +

xen: Use IRQF_FORCE_RESUME

commit 676dc3cf5bc36a9e129a3ad8fe3bd7b2ebf20f5d upstream.

Mark the IRQF_NO_SUSPEND interrupts IRQF_FORCE_RESUME and remove the extra
walk through the interrupt descriptors.

Signed-off-by: Thomas Gleixner t...@linutronix.de
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Signed-off-by: Stefan Bader stefan.ba...@canonical.com
Signed-off-by: Greg Kroah-Hartman gre...@suse.de

Cheers,
Moritz



-- 
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/20111014160856.GA3947@pisco.westfalen.local

Bug#614622: linux-image-2.6.37-1-686: atl2 NIC claims NO CARRIER after suspend/resume; rmmod+insmod fixes the problem

[Moritz Mühlenhoff]

On Wed, Aug 03, 2011 at 07:15:02PM -0400, Daniel Kahn Gillmor wrote:
 On 07/29/2011 11:20 AM, Moritz Mühlenhoff wrote:
  On Tue, Feb 22, 2011 at 09:06:44PM -0500, Daniel Kahn Gillmor wrote:
  I run this machine every day, connect it to multiple wired networks, and
  have a usage pattern of suspend-to-ram at least twice a day.  I never
  saw this problem until i was running 2.6.37-1.
 
  I don't think i was simply lucky with the previous versions.
  
  Does this still occur with more recent kernels, e.g. 3.0?
 
 I'm now running 3.0 (3.0.0-1-686-pae), and i see the same misbehavior.
 
 Plugging/unplugging the network cable does not resolve the no-carrier
 state; power cycling the peer switch does not resolve it.
 
 Removing and re-loading atl2.ko does resolve it.
 
 Sorry to be the bearer of bad news :(

Please report this upstream at http://bugzilla.kernel.org, product Drivers
and component Networking.

The reason why we ask you to file this bug report yourself is because
the kernel maintainers for that component will have questions specific
to your setup/hardware.

Once you've filed the bug, please send us the bugnumber or mark the bug
as forwarded yourself.

Cheers,
Moritz



-- 
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/20110808172632.GB4418@pisco.westfalen.local

Bug#586289: linux-image-2.6.32-5-486: Driver pegasus freeze networking very often so one must reboot to get it to work again

[Moritz Mühlenhoff]

Hi,

On Sat, Jul 30, 2011 at 03:54:10PM +0200, Csanyi Pal wrote:
 Hi,
 
 Moritz Mühlenhoff j...@inutil.org writes:
 
  On Fri, Jun 18, 2010 at 09:15:10AM +0200, Paul Chany wrote:
  Package: linux-2.6
  Version: 2.6.32-15
  Severity: grave
  Tags: squeeze
  Justification: renders package unusable
 
  the driver pegasus freeze networking very often so one must to reboot
  to get networking work again. At reboot the system hang and one can 
  see a message like:
  [5952.880465] pegasus 1-1:1.0: update_eth_regs_async, status -22
  

[..]

  Does this still occur with more recent kernels?
 
 Yes, on my old laptop where I use an USB2.0/Ethernet adapter, and the
 kernel is:
 2.6.38-2-486 because I'm running Debian SID on that laptop.

Ok. Since sid is already at version 3.0 by now, please retest. If it still 
occurs
- which is very likely, but the upstream developers will need to have the
test result against the latest version -, please file this upstream at 
http://bugzilla.kernel.org, product Drivers and component Networking.

The reason why we ask you to file this bug report yourself is because
the kernel maintainers for that component will have questions specific
to your setup/hardware.

If a fix is found upstream, we can then proceed and investigate,
whether the change is backportable to the kernel in Debian 6.0
(Squeeze).

Cheers,
Moritz




-- 
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/20110731151815.GA3778@pisco.westfalen.local

Bug#588602: xserver-xorg-video-radeon: xpress 200m 5955 = resume from suspend fails with KMS enabled

[Moritz Mühlenhoff]

On Mon, May 31, 2010 at 05:15:41PM -0400, Andres Cimmarusti wrote:
 Package: xserver-xorg-video-radeon
 Version: 1:6.13.0-2
 Severity: important
 Tags: squeeze
 
 When I try suspending using KMS my computer (an HP Pavilion dv5035nr laptop)
 does not resume. Furthermore I've tried logging into it remotely to obtain a
 backtrace from X with no success (following this procedure:
 http://ubuntuforums.org/showthread.php?t=1228332). I'm letting NetworkManager
 handle my network interfaces, however, I also tried using dhcp directly in the
 /etc/network/interfaces file.
 
 Unfortunately as soon as the resuming process starts (and fails) I am unable 
 to
 establish a connection the laptop (wired or wireless). On top of this, upon
 hard reboot I have no network connectivity (if managed by network manager):
 http://mail.gnome.org/archives/networkmanager-list/2010-March/msg00123.html
 The workaround for the last bit has been to erase the stale file and reboot.
 
 When using UMS the resume process happens perfectly.
 I don't know how else to get a backtrace. The laptop screen is completely 
 blank
 so I can't switch to another session.
 I've marked this bug as important because suspend/hibernate are almost
 essential features in a laptop.

Does this still occur in current sid/testing?

Cheers,
Moritz



-- 
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/20110730093704.GA4173@pisco.westfalen.local

Bug#587763: linux-image-2.6.32-5-amd64: scary messages from JBD when manipulating quotas on ext4

[Moritz Mühlenhoff]

On Thu, Jul 01, 2010 at 03:29:52PM +0200, Laurent Bonnaud wrote:
 Package: linux-2.6
 Version: 2.6.32-15
 Severity: important
 
 
 Hi,
 
 here is how to reproduce this bug:
 
 1. set up quotas on an ext4 filesystem
 2. use edquota to change the quotas of some user
 
 Actual result: the kernel outputs this scary message:
 
 [  399.792052] JBD: Spotted dirty metadata buffer (dev = sdb1, blocknr =
 34816). There's a risk of filesystem corruption in case of system crash.
 
 Expected result: 
  - no scary message
  - no filesystem corruption
  - changed quotas

This might have been fixed in 2.6.32.17 (and thus in Debian revision
2.6.32-19 for Squeeze and 2.6.33 for sid). Can you confirm?

Cheers,
Moritz



-- 
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/20110730094256.GA4476@pisco.westfalen.local

Bug#586289: linux-image-2.6.32-5-486: Driver pegasus freeze networking very often so one must reboot to get it to work again

[Moritz Mühlenhoff]

On Fri, Jun 18, 2010 at 09:15:10AM +0200, Paul Chany wrote:
 Package: linux-2.6
 Version: 2.6.32-15
 Severity: grave
 Tags: squeeze
 Justification: renders package unusable
 
 Hi,
 
 the driver pegasus freeze networking very often so one must to reboot 
 to get networking work again. At reboot the system hang and one can 
 see a message like:
 [5952.880465] pegasus 1-1:1.0: update_eth_regs_async, status -22
 
 At this point one must press the Reset button of the PC Box because 
 the system hangs forever.

Sorry for the late reply.

Does this still occur with more recent kernels?

Cheers,
Moritz



-- 
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/20110730094506.GA4760@pisco.westfalen.local

Bug#630566: linux-source-2.6.39: 2.6.39-2 : bluetooth broken

[Moritz Mühlenhoff]

On Thu, Jun 16, 2011 at 01:54:50AM +0200, Tom Jägermeister wrote:
 Am Mittwoch, 15. Juni 2011, 13:26:50 schrieben Sie:
  
  did you try 3.0-rc2 in experimental?
  
  thanks
 
 I tried it now and the problem is the same (same error).
 
 btw. I had trouble to compile the 3.0 kernel. I needed to remove the modules 
 apm and lguest. It also uses much more ram than 2.6.39. Probably it needs an 
 updated kernel-package and some more work but that has nothing to do with the 
 bluetooth problem of course.

Please try the kernel image from unstable (e.g. linux-image-3.0.0-1-amd64)
and bluez from unstable.

Cheers,
Moritz



-- 
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/20110730094841.GA5178@pisco.westfalen.local

Bug#633526: [vserver] Bug#633526: vserver kernel breaks ssh public_key authentication on NFS

[Moritz Mühlenhoff]

On Tue, Jul 12, 2011 at 11:04:53PM +0200, Herbert Poetzl wrote:
 On Tue, Jul 12, 2011 at 04:27:55AM +0100, Ben Hutchings wrote:
  Does anyone understand this problem or have an idea of how to
  investigate it?
 
 I do not really understand the problem (yet) here are some
 questions:
 
  - NFS server is Linux-VServer patched? (yes, no)
if so then:
+ NFS server has NFS tagging enabled? (yes, no)
+ filesystem exported is tagged? (yes, no)
  if so then:
  * what tagging and what filesystem is used?
   
  - NFS client is Linux-VServer patched? (yes, no)
   + if so then NFS client has NFS tagging enabled? (yes, no)

Harald, did you see the followup questions?

Cheers,
Moritz



-- 
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/20110730100202.GA5902@pisco.westfalen.local

Bug#608278: linux-image-2.6.32-5-amd64: Random general protection faults at boot

[Moritz Mühlenhoff]

On Mon, Jan 03, 2011 at 08:32:26PM +, Ben Hutchings wrote:
 On Mon, 2011-01-03 at 15:19 +0100, Andrea Spadaccini wrote:
  Hi,
  
   This is presumably caused by a bug in rtl8187.  However, it is not a
   general protection fault so there may be two different bugs here.
  
   Yes, the GPF is around sec 30. After that bug, I blacklisted rtl8187,
   and resulted in the other GPFs at boot time that are not logged.
  
   Can you try blacklisting the radeon driver?
  
  If I blacklist the radeon driver, I don't get any GPFs anymore.
  
  I did 10 reboots, and no problems.
  
  Can I help you anymore in diagnosing the problem?
 
 Please test the package of Linux 2.6.37-rc7 from experimental, with
 radeon enabled again.

Did you test with a more recent kernel?

Cheers,
Moritz



-- 
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/20110730101052.GA6186@pisco.westfalen.local

Bug#600286: linux-image-2.6.32-5-amd64: atl1c driver hangs after NETDEV WATCHDOG: eth0 (atl1c): transmit queue 0 timed out

[Moritz Mühlenhoff]

On Sun, Oct 17, 2010 at 02:38:22AM +0100, Ben Hutchings wrote:
 I have no idea why the kernel sent such large packets. According to
 ifconfig eth0, the MTU is 1500 bytes. Is it supposed to work like
 that, or is this another bug?
 [...]
 
 This driver and hardware implement TCP Segmentation Offload (TSO), which
 means the kernel can provide oversized pseudo-packets that are turned
 into multiple packets on the wire.
 
 I did notice a later bug fix to this driver which might possibly address
 the bug you're seeing.  Please can you test the attached patch,
 following the instructions at
 http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official.

Niels, did you try the patch or has this been resolved in more recent kernels?

Cheers,
Moritz



-- 
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/20110730101423.GA6580@pisco.westfalen.local

Bug#552706: BUG: soft lockup - CPU#0 stuck for 61s! - :nfs:nfs_access_cache_shrinker

[Moritz Mühlenhoff]

On Wed, Feb 24, 2010 at 01:43:59PM +0100, Bernd Zeimetz wrote:
 Moritz Muehlenhoff wrote:
  Does this error still occur with 2.6.26-21 from the latest point
  update, which introduced two patches which might have fixed this error?
 
 We'll give it a try as soon as time permits, the machine is turned off right 
 now
 and other models are in production and not using NFS.

Any update?

Cheers,
Moritz



-- 
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/20110730122712.GA7418@pisco.westfalen.local

Bug#554214: linux-image-2.6.31-1-amd64: RaLink RT2561/RT61 wireless card stopped working in 2.6.31

[Moritz Mühlenhoff]

On Tue, Oct 12, 2010 at 02:03:21AM +0100, Ben Hutchings wrote:
 On Wed, 2009-11-11 at 21:57 +0100, Michal Kašpar wrote:
  I've added it as a comment to
  http://bugzilla.kernel.org/show_bug.cgi?id=14460 as it seems quite
  similar.
 
 That's now (finally) marked as fixed, but the fix involved a change to
 AMD bus setup whereas I see you were using an Intel-based system.  I
 think you must have found a different bug.  Has this been fixed by a
 later Debian package version?

Michal, were you able to test this?

Cheers,
Moritz



-- 
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/20110730122840.GA7634@pisco.westfalen.local

Bug#499752: linux-image-2.6.26-1-686: Seagate STT20000A no longer works in 2.6.26

[Moritz Mühlenhoff]

On Sun, Mar 15, 2009 at 09:35:08AM +0100, Mark de Wever wrote:
 forwarded 499752 http://bugzilla.kernel.org/show_bug.cgi?id=12874
 thanks
 
 Hi Moritz,
 
  If the bug persists in 2.6.28, please file a bug report at 
  bugzilla.kernel.org and send the bug number to this buglog.
 
 Sorry took a bit longer, I was quite busy the last few weeks. The
 problem still exists in 2.6.29-rc7 and I reported the bug upstream.

The upstream report doesn't seem to have led to anything.

Does it still fail with current kernels?

Cheers,
Moritz



-- 
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/20110729144650.GA20695@pisco.westfalen.local

Bug#503029: problem recognized

[Moritz Mühlenhoff]

On Fri, Dec 26, 2008 at 12:57:25AM +0100, Moritz Muehlenhoff wrote:
 forwarded 503029 http://bugzilla.kernel.org/show_bug.cgi?id=12297
 thanks
 
 On Fri, Dec 26, 2008 at 12:33:59AM +0100, Radek Warowny wrote:
   There have been no related changes to the analog joystick driver up
   to 2.6.28. Could you report this at http://bugzilla.kernel.org and
   send the bug number to this bug?
  
  I have registered the bug at the http://bugzilla.kernel.org, the bug
  number is 10739.
 
 ITYM #12297, marking as forwarded.

Unfortunately there was no reaction from the kernel developers. Does
the bug still persist with a current kernel?

Cheers,
Moritz



-- 
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/20110729145106.GA21347@pisco.westfalen.local

Bug#11922: closed by maximilian attems m...@stro.at (Re: Bug#11922: I/O error on blank tapes)

[Moritz Mühlenhoff]

On Sat, Feb 09, 2008 at 03:05:38PM +, Ian Jackson wrote:
 reopen 11922
 thanks
 
 Debian Bug Tracking System writes (Bug#11922 closed by maximilian attems 
 m...@stro.at (Re:   Bug#11922: I/O error on blank tapes)):
  On Tue, 05 Feb 2008, Kai Makisara wrote:
   This is not a bug, it is a feature. There is _nothing_ on the tape and if 
   you try to read something, you get an error. The same thing applies to 
   reading after the last filemark. Note that after writing a filemark at 
   the 
   beginning of the tape, the situation is different. Now there is a file 
   and 
   the normal EOF semantics apply although there still is no data.
 
 If one takes this view, then the program which is reading the tape
 should get EOF.  Obviously I disagree with that view.  I think it's
 appropriate for the driver to give EIO in this case but ...
 
   I admit that the error return could be more descriptive but the st driver 
   tries to be compatible with other Unices.
 
 ... IMO anything that gives EIO should also generate a log message to
 say why.
 
 This bug report is not about the errno value passed to the userland
 program, but about the lack of a log message.

If you want to see that changed, please report this upstream. Otherwise
it just clutters the Debian kernel bugs, which are already too hard
to handle.

Cheers,
Moritz



-- 
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/20110729150259.GA22810@pisco.westfalen.local

Bug#522773: possible solutions for __unused problem

[Moritz Mühlenhoff]

On Sun, Jun 19, 2011 at 07:09:37PM +, Thorsten Glaser wrote:
 Ben Hutchings dixit:
 
 The use of __undefined in the BSDs predates use of it by
 both Linux and GNU. (But when using this argumentation
 style, we’d probably better take this upstream… except
 that upstream may not be helping…)

We already asked you back in September 2009 to report this upstream.

If you don't think that will help, we can just close the bug, then. 

Cheers,
Moritz



-- 
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/20110729150817.GA23022@pisco.westfalen.local

Bug#590327: linux-image-2.6.32-5-amd64: Unbalanced enable for IRQ 19

[Moritz Mühlenhoff]

On Fri, Jul 30, 2010 at 02:07:15AM +0200, Jan Echternach wrote:
 On Thu, Jul 29, 2010 at 06:02:41PM +0100, Ben Hutchings wrote:
  Let us know the bug number or URL so that we can track it.
 
 https://bugzilla.kernel.org/show_bug.cgi?id=16481

Does this still occur with current kernels?

Cheers,
Moritz



-- 
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/20110729151848.GA24689@pisco.westfalen.local

Bug#614622: linux-image-2.6.37-1-686: atl2 NIC claims NO CARRIER after suspend/resume; rmmod+insmod fixes the problem

[Moritz Mühlenhoff]

On Tue, Feb 22, 2011 at 09:06:44PM -0500, Daniel Kahn Gillmor wrote:
 On 02/22/2011 08:14 PM, Ben Hutchings wrote:
  This bug report was made against Debian's package of Linux 2.6.37:
  [...]
  I don't see any changes to this driver between 2.6.37-rc4 (the first
  version we built as '2.6.37-trunk-686') and 2.6.37, so I think Daniel
  just had good luck with the earlier versions.
 
 I was running 2.6.37-1~experimental.1, fwiw, since 2011-01-09.  I don't
 think that was based off of rc4, because i was running
 2.6.37~rc5-1~experimental.3 before that since 2010-12-16.
 
 so the dates are:
 
  2010-12-16: start running 2.6.37~rc5-1~experimental.3
  2011-01-09: start running 2.6.37-1~experimental.1
  2011-02-17: start running 2.6.37-1
 
 I run this machine every day, connect it to multiple wired networks, and
 have a usage pattern of suspend-to-ram at least twice a day.  I never
 saw this problem until i was running 2.6.37-1.
 
 I don't think i was simply lucky with the previous versions.

Does this still occur with more recent kernels, e.g. 3.0?

Cheers,
Moritz



-- 
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/20110729152021.GA24903@pisco.westfalen.local

Bug#620480: linux-image-2.6.38-2-amd64: xserver rendering errors on 945GM/GMS

[Moritz Mühlenhoff]

On Sat, Apr 02, 2011 at 10:53:36AM +0200, Wolfram Quester wrote:
 Package: linux-image-2.6.38-2-amd64
 Version: 2.6.38-2
 Severity: normal
 
 Hi altogether,
 
 since I updated yesterday I get rendering errors mainly of fonts in
 gnome-terminal. A typical distortion which occurred while typing this email is
 shown in the attached screenshot.
 For me this looks similar to the distortions I reported in bug 589075.
 I can wipe away the distortions by unfolding a menu or moving an other 
 window
 over them.
 
 Since the update yesterday didn't affect xserver-xorg-video-intel and it goes
 away when I downgrade the kernel to 2.6.37, I report this against
 linux-image-2.6.38-2-amd64. 

Does this still occur with current Xorg/kernels?

Cheers,
Moritz 



-- 
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/20110729152338.GA25126@pisco.westfalen.local

Bug#588196: b43: does not join multicast groups

[Moritz Mühlenhoff]

On Thu, Jul 15, 2010 at 03:45:01PM +0200, Michael Büsch wrote:
 On 07/15/2010 10:51 AM, Simon Richter wrote:
 The same applies to receiving. The RX queue is also dropped on switch
 from DMA to PIO.
 
 Sure, but the packet is repeated every ten seconds. The problem is that
 none of those packets is received, even long after the switch to PIO.
 
 The filter flags are not updated because (as I already said) the reinit
 happens without mac80211's knowledge.
 
 The actual switch from DMA to PIO mode completely reinitializes
 the hardware and drops all queues.
 
 Would it be possible to reinitialize the multicast filter at this point?
 
 Yeah everything is possible.
 I'd rather like to see the actual _problem_ fixed instead of
 continuing to waste hours and hours on the hackish workaround.
 So in the end the workaround (aka PIO fallback) can be removed.
 
 If this problem is fixed, the next one will show up. (For example
 the fact that the PIO fallback won't work on an AP, too, for these
 reasons).
 
 Please work on fixing up the PCI core code, which most likely
 causes the problem, instead of extending the workaround hack.

Does this still occur with more recent kernels?

Cheers,
Moritz



-- 
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/20110729153645.GA26500@pisco.westfalen.local

Bug#580927: linux-image-2.6.32-5-openvz-686: Uncharging too much ... res shmpages ub

[Moritz Mühlenhoff]

On Sun, May 09, 2010 at 11:27:08PM +0200, Achim Schaefer wrote:
 Package: linux-2.6
 Version: 2.6.32-12
 Severity: normal
 Tags: sid upstream
 
 Hi,
 
 I get quite a lot of the messages you can find under kernel.log-)
 
 I think the upstream bug is:
 http://bugzilla.openvz.org/show_bug.cgi?id=1299
 But I don't know how to tell bts...

Ola,
this has been fixed upstream. Should we add the patch to a Squeeze point update?

Cheers,
Moritz



-- 
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/20110729154704.GA27464@pisco.westfalen.local

Re: Uploading linux-2.6 (3.0.0-1)

[Moritz Mühlenhoff]

Ben Hutchings b...@decadent.org.uk schrieb:

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

 On Sun, 2011-07-24 at 17:24 +0200, Yves-Alexis Perez wrote:
 On sam., 2011-07-23 at 15:05 +0200, Ben Hutchings wrote:
  If it's ready in time, we may also be able to add an 'rt' (real-time)
  featureset, initially for amd64 only.
 =20
=20
 So featuresets are still somewhat supported / acceptable?

 They are still possible.  I think we don't really want long-lived
 featuresets and will be more open to features that look likely to be
 merged upstream.  The PREEMPT_RT patches are steadily being merged and I
 would expect to be able to provide rt flavours without use of a
 featureset patch in wheezy+1.

So, how to we proceed with the grsec flavour? We didn't come to
a real conclusion wrt to it.

I still very much want to see it merged and I'm still willing to
contribute to the maintenance, as is apparently Yves-Alexis (that's
what I'm reading of his question).

grsec will be long-lived since I don't think upstream will turn
sensible anytime soon. OTOH, if at some point Brad and the other
people behind grsecurity discontinue it, this would be a less severe
regression since the stoppage of providing a virtualisation flavour
like openvz.

Cheers,
Moritz









 Ben.

 --=20
 Ben Hutchings
 I'm always amazed by the number of people who take up solipsism because
 they heard someone else explain it. - E*Borg on alt.fan.pratchett

 --=-oAGGyietHuyp77ujkKt4
 Content-Type: application/pgp-signature; name=signature.asc
 Content-Description: This is a digitally signed message part


 --=-oAGGyietHuyp77ujkKt4--




-- 
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/slrnj2ov7g.mfp@inutil.org

Re: Next upload to unstable

[Moritz Mühlenhoff]

Ben Hutchings b...@decadent.org.uk schrieb:

 --=-Wk45Ah+XpS5md1taqRO7
 Content-Type: text/plain; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable

 There are some security fixes in 2.6.39.3 but I'm not sure how important
 they are.  Dann, Moritz, any opinion?

 If they're not that important then let's wait for 2.6.39-3 to transition
 to testing (which should happen on Thursday) before making another
 upload.

It's just one new issue, most of the fixes from 2.6.39.3 have been
applied to 2.6.39-3 before.

Let's migrate 3.6.39 to testing first.

Cheers,
Moritz


-- 
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/slrnj1rp7r.3f9@inutil.org

Bug#627700: New Intel Ethernet adapters (e1000e driver)

[Moritz Mühlenhoff]

Hi,

   In this kernel version, the e1000e driver is missing support for
   i82567V-4 and i82579 and important bug fixes for i82577, i82578 and
   i82583.
 
  Here's our test results for the previously unsupported 82579V card:

 Thanks.

 [...]

Additional test results for a different system with a previously unsupported 
Intel 82577 card:

00:19.0 Ethernet controller: Intel Corporation Device 1503 (rev 04)
Subsystem: Fujitsu Limited. Device 161c
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 27
Region 0: Memory at e260 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at e262b000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at 3080 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ 
Queue=0/0 Enable+
Address: fee0f00c  Data: 41b9
Capabilities: [e0] PCIe advanced features ?
Kernel driver in use: e1000e
Kernel modules: e1000e

   1. If the driver tries to load firmware (only required for some chips),
 does this work once the firmware file(s) are installed? 

No firmware is being loaded.

   2. Can you receive and transmit VLAN-tagged frames after creating a VLAN
   interface? 

The tests outlined in #627704 were successful.

   3. Does the interface work after suspend and resume?

I couldn't test this.

  4. Does the interface work after removing the cable for 10 seconds and
  reinserting it?

No problems occurred.

  5. Does multicast configuration work? (IPv6 autoconfiguration or mDNS will 
cover this.)

avahi-browse --all worked fine.

   6. Can the interface send and receive TCP/IP across a LAN at the same
   speed, before and after these changes? (Use e.g. netperf to test this, but
   don't forget to remove the netperf package after use.)

See below.

   7. Are any warnings or errors logged by the kernel during the preceding 
tests?

None.

 Since the card was previously unsupported I cannot compare it to the
  previous state. The performance of large file copies was quite ok.
 
  root@lynx:~# netperf
  TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost
  (127.0.0.1) port 0 AF_INET : demo
  Recv   SendSend
  Socket Socket  Message  Elapsed
  Size   SizeSize Time Throughput
  bytes  bytes   bytessecs.10^6bits/sec
 
   87380  16384  1638410.0024326.17

 Well you have a very fast loopback interface...

Ah...

With real world usage the performance was as expected, copying files over scp 
gives a throughput of 60-70 megabytes per second for both systems, with the 
CPU power of the remote host being the apparent bottleneck.

Cheers,
Moritz
-- 
Moritz Mühlenhoff muehlenh...@univention.de
Open Source Software Engineer and Consultant
Univention GmbH  Linux for Your Business fon: +49 421 22 232- 0
Mary-Somerville-Str.1  28359 Bremen  fax: +49 421 22 232-99
http://www.univention.de



--
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/201107111001.56225.muehlenh...@univention.de

Bug#627700: New Intel Ethernet adapters (e1000e driver)

[Moritz Mühlenhoff]

Hi,

 In this kernel version, the e1000e driver is missing support for
 i82567V-4 and i82579 and important bug fixes for i82577, i82578 and
 i82583.

Here's our test results for the previously unsupported 82579V card:

lspci -vv:

00:19.0 Ethernet controller: Intel Corporation Device 1503 (rev 05)
Subsystem: Intel Corporation Device 2002
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 27
Region 0: Memory at fe70 (32-bit, non-prefetchable) [size=128K]
Region 1: Memory at fe728000 (32-bit, non-prefetchable) [size=4K]
Region 2: I/O ports at f040 [size=32]
Capabilities: [c8] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=1 PME-
Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ 
Queue=0/0 Enable+
Address: feeff00c  Data: 41c1
Capabilities: [e0] PCIe advanced features ?
Kernel driver in use: e1000e
Kernel modules: e1000e

lspci -n

00:19.0 0200: 8086:1503 (rev 05)


   1. If the driver tries to load firmware (only required for some chips),
 does this work once the firmware file(s) are installed? 

No firmware is being loaded.

   2. Can you receive and transmit VLAN-tagged frames after creating a VLAN
   interface? 

The tests outlined in #627704 were successful.

   3. Does the interface work after suspend and resume?

I couldn't test this; suspend doesn't work properly on that system.

  4. Does the interface work after removing the cable for 10 seconds and 
reinserting it?

That worked fine.

  5. Does multicast configuration work? (IPv6 autoconfiguration or mDNS will 
cover this.)

avahi-browse --all worked fine.

   6. Can the interface send and receive TCP/IP across a LAN at the same 
speed, before and after these changes? (Use e.g. netperf to test this, but 
don't forget to remove the netperf package after use.)

Since the card was previously unsupported I cannot compare it to the previous 
state. The performance of large file copies was quite ok.

root@lynx:~# netperf 
TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to localhost (127.0.0.1) 
port 0 AF_INET : demo
Recv   SendSend  
Socket Socket  Message  Elapsed  
Size   SizeSize Time Throughput  
bytes  bytes   bytessecs.10^6bits/sec  

 87380  16384  1638410.0024326.17   

   7. Are any warnings or errors logged by the kernel during the preceding 
tests?

None.

Cheers,
Moritz
-- 
Moritz Mühlenhoff muehlenh...@univention.de
Open Source Software Engineer and Consultant
Univention GmbH  Linux for Your Business fon: +49 421 22 232- 0
Mary-Somerville-Str.1  28359 Bremen  fax: +49 421 22 232-99
http://www.univention.de



--
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/201107011123.30009.muehlenh...@univention.de

Bug#629825: linux-image-2.6.38-2-amd64: wireless is disabled by hardware switch

[Moritz Mühlenhoff]

On Wed, Jun 08, 2011 at 01:24:26PM -0400, Houmehr Aghabozorgi wrote:
 Package: linux-2.6
 Version: 2.6.38-5
 Severity: important
 
 I have intel 5300 agn card. this testing install and booting under kernel .32
 the wireless card works as expected. Booting under .38 the card is listed as
 wireless is  disabled by hardware switch. Debian IRC suggested installing
 firmware-iwlwifi from sid, which i tried and it is the same result.

What's the output of rfkill list with both kernels?

Cheers,
Moritz



-- 
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/20110608201514.GA5736@pisco.westfalen.local

Bug#627704: Realtek Ethernet adapters (r8169 driver)

[Moritz Mühlenhoff]

On Mon, May 23, 2011 at 11:43:26AM -0700, Ben Hutchings wrote:
 Package: linux-2.6
 Version: 2.6.32-34
 Severity: important
 
 The r8169 driver in this kernel version is missing important bug fixes
 for the RTL8102E and RTL8168DP.

The card revision was already supported with the initial Squeeze kernel
and everything is still working fine with the updated kernel for the
following device:

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI 
Express Gigabit Ethernet controller (rev 02)
Subsystem: Giga-byte Technology GA-EP45-DS5 Motherboard
Flags: bus master, fast devsel, latency 0, IRQ 26
I/O ports at c000 [size=256]
Memory at e151 (64-bit, prefetchable) [size=4K]
Memory at e150 (64-bit, prefetchable) [size=64K]
[virtual] Expansion ROM at e152 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable+ Count=1/2 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 01
Capabilities: [b0] MSI-X: Enable- Count=2 Masked-
Capabilities: [d0] Vital Product Data
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Virtual Channel
Capabilities: [160] Device Serial Number 12-34-56-78-12-34-56-78
Kernel driver in use: r8169

Cheers,
Moritz



-- 
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/20110528091122.GA3566@pisco.westfalen.local

Bug#627763: linux-image-2.6.38-2-amd64: suspend to disk locks up box when not enough swap available

[Moritz Mühlenhoff]

On Tue, May 24, 2011 at 11:52:43AM +0200, Michal Suchanek wrote:
 Package: linux-2.6
 Version: 2.6.38-4
 Severity: important
 
 
 When suspending to disk with not enough space available the system locks
 up on the snapshotting system screen.
 
 I guess this is a regression, there used to be a check in place that
 would immediately resume the system if there waas not enough space to
 save the whole system image.

Please retest with 2.6.39-1 from unstable.

Cheers,
Moritz



-- 
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/20110528091317.GA3870@pisco.westfalen.local

Bug#627669: linux-image-2.6.38-2-amd64: [brcm80211] oops on iwlist wlan0 scanning

[Moritz Mühlenhoff]

On Mon, May 23, 2011 at 03:00:07PM +0200, Helmut Grohne wrote:
 Package: linux-image-2.6.38-2-amd64
 Version: 2.6.38-5
 Severity: normal
 
 I do know that brcm80211 comes from the staging tree. Nevertheless I
 hereby document one of its problems.

Please retest with 2.6.39-1 from unstable.

Cheers,
Moritz



-- 
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/20110524164657.GA3742@pisco.westfalen.local

Bug#586270: linux-image-2.6.32-5-686: evo n610c compaq laptop fails to go into suspend mode

[Moritz Mühlenhoff]

On Thu, Jun 17, 2010 at 08:24:17PM -0400, Andres Cimmarusti wrote:
 Package: linux-2.6
 Version: 2.6.32-15
 Severity: important
 Tags: sid squeeze
 
 After recent updates, I can no longer successfully go into suspend moved with 
 this
 laptop. The kernel log shows several backtraces.

Sorry for the late followup.

Does this still occur with more recent kernels, i.e. the final Squeeze kernel or
more recent versions from backports/testing/sid?

Cheers,
Moritz



-- 
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/20110505204741.GA27454@pisco.westfalen.local

Bug#577438: base: b43 driver won't work anymore

[Moritz Mühlenhoff]

tags 577438 moreinfo
thanks

On Sun, Apr 11, 2010 at 06:01:24PM +0200, Eric Viseur wrote:
 Package: base
 Severity: important
 
 b43 driver won't work anymore with bcm4318 chip.  I installed the correct 
 firmware using b43-fwcutter.  Worked like a charm with Lenny and early 
 Squeeze kernels, stopped working with 2.6.32.
 I have no errors in dmesg : the chip just starts, then the links goes down 
 and neither network-manager or wireless-tools see any networks.

Is this resolved in the final Squeeze kernel (or later ones)?

Cheers,
Moritz



-- 
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/20110430172130.GA3655@pisco.westfalen.local

Bug#623308: linux-image-2.6.38-2-amd64: Lenovo X200 laptop fails to power down under 2.6.38

[Moritz Mühlenhoff]

On Fri, Apr 29, 2011 at 05:01:37PM +1000, Jason White wrote:
 Moritz Mühlenhoff j...@inutil.org wrote:
  On Mon, Apr 25, 2011 at 11:29:13AM +1000, Jason White wrote:
   Laptop-mode appears to be the cause; can you reproduce the bug by 
   enabling it
   on your X200?
  
  How did you activate the laptop mode on your system?
  
  If I install laptop-mode-tools, the system still powers down just fine.
  laptop-mode is deactivated as part of the shutdown sequence, though.
 
 Laptop-mode was enabled on my system in the same way, namely by installing
 laptop-mode-tools. It should be disabled during the shutdown by the init
 script.
 
 I will post a follow-up if I can narrow down the cause further.

FWIW, my X200 is one of the last revisions sold, e.g. the BIOS date
is from 2010-03-11, so there might be differences in hardware if you own
an earlier model.

Cheers,
Moritz




-- 
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/20110429224350.GA3142@pisco.westfalen.local

Bug#623808: Please activate RT33XX options

[Moritz Mühlenhoff]

tags 623808 moreinfo
thanks

On Sat, Apr 23, 2011 at 03:35:21PM +0800, Thomas Goirand wrote:
 Package: linux-2.6
 Version: 2.6.38-3
 Severity: wishlist
 Tags: sid
 
 Hi,
 
 As there was not follow-up on my email to the list, I'm sending this
 bug report, in the hope that it will bring attention to the kernel team.
 
 I have an old laptop with a bad internal WiFi board, so I bought a newer
 RaLink driver. To make it work, I had to add the option rt2800usb -
 Include support for rt33xx devices (EXPERIMENTAL) and rt2800usb -
 Include support for rt35xx devices (EXPERIMENTAL). These are not
 activated in your build (I've just checked).
 
 I believe that one of the most important point of running a backported
 kernel is to have such drivers for newer hardware. Could you please
 include the option above? The options to activate are as below:
 
 CONFIG_RT2800PCI_RT33XX
 CONFIG_RT2800PCI_RT35XX
 CONFIG_RT2800USB_RT33XX
 CONFIG_RT2800USB_RT35XX

These options currently carry the disclaimer:

| Support for these devices is non-functional at the moment and is
| intended for testers and developers.

Did you successfully test them?

Cheers,
Moritz



-- 
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/20110429225551.GA4236@pisco.westfalen.local

Bug#617508: patch available

[Moritz Mühlenhoff]

Rik Theys wrote:

 On 04/15/2011 05:49 AM, Ben Hutchings wrote:
 Please consider adding this patch to a ((old)stable) kernel update.
 
 I don't think this is sufficiently critical for an oldstable update.
 For stable, yes, we'll consider it once it's accepted upstream.  Please
 let us know when that happens.
 
 It looks like the patch is now in Linus' git tree.
 
 Commit id is 1574dff8996ab1ed92c09012f8038b5566fce313
 
 It's definitely in the 2.6.39-rc4-git4 patch.

Greg,
please merge 1574dff8996ab1ed92c09012f8038b5566fce313 for 2.6.32 long term
(should also apply for all following long term kernels)

For details please see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617508

Cheers,
Moritz



-- 
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/20110429230946.GA4512@pisco.westfalen.local

Bug#512779: linux-image-2.6.26-1-amd64: XFS internal error / xfs_force_shutdown

[Moritz Mühlenhoff]

On Fri, Jan 23, 2009 at 05:48:45PM +0100, Bastian Scholz wrote:
 Package: linux-image-2.6.26-1-amd64
 Version: 2.6.26-12
 Severity: important
 
 
 In the last three month I had around five crashes with my XFS filesystem
 
 # dmesg
 snip
 [7688274.093948] Filesystem dm-2: XFS internal error xfs_trans_cancel at 
 line
 1163 of file fs/xfs/xfs_trans.c.  Caller 0xa01b59bb
 [7688274.093976] Pid: 32049, comm: rsnapshot Not tainted 2.6.26-1-amd64 #1
 [7688274.093987]
 [7688274.093988] Call Trace:
 [7688274.094051]  [a01b59bb] :xfs:xfs_link+0x2c1/0x2d2
 [7688274.094092]  [a01af9be] :xfs:xfs_trans_cancel+0x55/0xed
 [7688274.094130]  [a01b59bb] :xfs:xfs_link+0x2c1/0x2d2
 [7688274.094166]  [a01b0151] :xfs:xfs_trans_unlocked_item+0x24/0x3d
 [7688274.094189]  [802ab124] d_instantiate+0x52/0x67
 [7688274.094227]  [a01bea66] :xfs:xfs_vn_link+0x41/0x97
 [7688274.094246]  [802a201a] vfs_link+0x128/0x1c1
 [7688274.094261]  [802a4d9e] sys_linkat+0xe1/0x143
 [7688274.094304]  [8020be9a] system_call_after_swapgs+0x8a/0x8f
 [7688274.094326]
 [7688274.094334] xfs_force_shutdown(dm-2,0x8) called from line 1164 of file 
 fs/x
 fs/xfs_trans.c.  Return address = 0xa01af9d7
 [7688274.108381] Filesystem dm-2: Corruption of in-memory data detected.  
 Shutting down filesystem: dm-2
 [7688274.108407] Please umount the filesystem, and rectify the problem(s)
 [7688278.316256] Filesystem dm-2: xfs_log_force: error 5 returned.
 /snip
 
 Filesystem setup is XFS on luks on lvm on mdraid5.
 Filesystem size is 600G, raid5 is around 932G

Did you upgrade to Squeeze in the mean time? Has this been resolved in the
current kernel version?

Cheers,
Moritz



-- 
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/20110429232055.GA5516@pisco.westfalen.local

Re: Introduction and greetings

[Moritz Mühlenhoff]

Jeremiah Foster jerem...@jeremiahfoster.com schrieb:

 On Apr 24, 2011, at 18:30, Moritz Mühlenhoff wrote:

 Jeremiah C. Foster jerem...@jeremiahfoster.com schrieb:

 So the start might be to look through the BTS, find kernel bugs that were 
 forwarded and if it looks like they are dormant, see if they can be brought 
 to life?

Yes, and it there's no reaction from the submitter they can also be closed
(in Debian and upstream), no need to keep old bugs cluttering the BTSes.

Cheers,
Moritz


-- 
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/slrnirebfd.2qp@inutil.org

Bug#623308: linux-image-2.6.38-2-amd64: Lenovo X200 laptop fails to power down under 2.6.38

[Moritz Mühlenhoff]

On Mon, Apr 25, 2011 at 11:29:13AM +1000, Jason White wrote:
 Laptop-mode appears to be the cause; can you reproduce the bug by enabling it
 on your X200?

How did you activate the laptop mode on your system?

If I install laptop-mode-tools, the system still powers down just fine.
laptop-mode is deactivated as part of the shutdown sequence, though.

Cheers,
Moritz



-- 
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/20110426214732.GA2980@pisco.westfalen.local

Bug#623308: linux-image-2.6.38-2-amd64: Lenovo X200 laptop fails to power down under 2.6.38

[Moritz Mühlenhoff]

On Tue, Apr 19, 2011 at 05:53:32PM +1000, Jason White wrote:
 Package: linux-2.6
 Version: 2.6.38-3
 Severity: normal
 
 
 After upgrading to 2.6.38-2-amd64, my Lenovo X200 laptop reboots instead of
 powering down when I run the poweroff command (or equivalently shutdown -h
 now). That is, the ordinary reboot/shutdown sequence takes place until the
 moment at which the machine should power off, but it returns to the BIOS
 screen and reboots instead.
 
 Reverting to 2.6.32-5 avoids the regression.

Hmm. I'm having a X200 myself and it powers down just fine with the current
sid kernel.

Cheers,
Moritz



-- 
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/20110424162648.GA2409@pisco.westfalen.local

Re: Introduction and greetings

[Moritz Mühlenhoff]

Jeremiah C. Foster jerem...@jeremiahfoster.com schrieb:
 Hi!

 My name is Jeremiah Foster and I thought I'd join this list to
 learn more about the process of creating a kernel for Debian.

 I thought I'd lurk at first, though I may have a question or two
 since I'd like to get to work creating a kernel for the TrimSlice.
 (The TrimSlice is a Tegra2 board.)

 I'm happy to do QA tasks and documentation (I'm a native English
 speaker and speak Swedish) so I'll try to contribute where I can.

Feel free to help with the bug triage if you're interested.
E.g. by repoking the status of forwarded bugs. If a bug is producible
with the upstream kernel and the Debian kernel doesn't deviate patchwise
we ask people to report it at bugzilla.kernel.org. This often leads to
the issue being fixed upstream, but sometimes there is no upstream
reaction. 

You could ping the submitters if the issue been resolved in the mean
time - without the Bugzilla status being updated - or if it's still
present. It makes sense to reraise the issue upstream in such a case.

Cheers,
Moritz



-- 
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/slrnir8k1q.25i@inutil.org

Bug#593421: Bug not found in version 2.6.32-19

[Moritz Mühlenhoff]

On Sun, Sep 26, 2010 at 11:12:09PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
 On Dom 26 Sep 2010 22:52:19 Ben Hutchings escribió:
  On Tue, 2010-09-21 at 23:46 -0300, Lisandro Damián Nicanor Pérez Meyer
  
  wrote:
   I just installed linux-image-2.6.32-5-amd64_2.6.32-19_amd64.deband I
   can't find the bug, so it has been introduced in 2.6.32-20.
  
  There have been some drm (kernel video driver) fixes since; can you try
  2.6.32-23?
  
  Ben.
 
 I have already tried it on Friday without luck :-( The symptoms are the same: 
 blank screen with backlight enabled. Once I plug an external monitor the LCD 
 comes alive.
 
 Thanks for asking non the less :-)

Does this bug still occur with the final version of the Linux kernel/Xorg ? 

Cheers,
Moritz




-- 
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/20110423192233.GA4458@pisco.westfalen.local

Bug#596468: linux-image-2.6.32-5-openvz-amd64: Keyspan USA-49WG USB-Serial 4th Port Doesn't Work

[Moritz Mühlenhoff]

On Wed, Dec 29, 2010 at 09:35:30PM +, Ben Hutchings wrote:
 On Wed, 2010-12-29 at 14:05 -0500, Steaphan Greene wrote:
  On 12/29/2010 09:10 AM, Ben Hutchings wrote:
   On Wed, 2010-12-29 at 03:55 -0500, Steaphan Greene wrote:
   On 12/26/2010 06:46 AM, Moritz Muehlenhoff wrote:
   Could you try to reproduce this with a current 2.6.37-rcX
   kernel from experimental?
  
   The kernel is available from packages.debian.org. If the error can
   still be reproduced, we should report it upstream.
  
   Unfortunately, 2.6.37-rc7-amd64 has an even greater problem, which
   prevents me from testing it.  The error I am now encountering seems to
   be the one discussed here:
  
https://bugzilla.kernel.org/show_bug.cgi?id=23012
   [...]
   
   That was fixed in 2.6.37-rc5.
  
  ...then it has been re-introduced, or a new bug which causes the same
  behavior for at least my keyspan device has cropped up in -rc7.  All
  access attempts to all of the 4 ports of my device with 2.6.37-rc7
  failed with a Resource Temporarily Unavailable error.
 
 Please add that information on bugzilla.kernel.org.

Steaphan,
it seems you didn't followup in the kernel.org bugzilla. Is this fixed
in current kernels from sid or testing?

Cheers,
Moritz



-- 
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/20110423194123.GA5687@pisco.westfalen.local

Bug#578477: crashes after several days of use

[Moritz Mühlenhoff]

tags 578477 moreinfo
thanks

On Tue, Apr 20, 2010 at 09:21:02AM +0200, Simon Richter wrote:
 Package: linux-2.6
 Version: 2.6.32-9
 Severity: important
 Tags: sid
 
 Hi,
 
 I am experiencing strange crashes after a few days of use. These appear
 to be related to LVM.
 
 Serial console output from the crash looks like this:

Does this still occur with more recent kernels?

Cheers,
Moritz



-- 
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/20110422213511.GA3049@pisco.westfalen.local

Bug#579858: xserver-xorg-video-nouveau: X fails to find nouveau device

[Moritz Mühlenhoff]

tags 579858 moreinfo
thanks

On Sat, May 01, 2010 at 11:35:33PM +0530, Ritesh Raj Sarraf wrote:
 Package: xserver-xorg-video-nouveau
 Version: 1:0.0.15+git20100329+7858345-3
 Severity: important
 
 Hi,
 
 I have been trying to configure nouveau for my nvidia card but looks like I 
 have a very preliminary problem
 for which I did not find a solution yet.
 
 
 X fails complaining that it could not find any of the device in /dev/dri/cardN
 On my box, even with nvidia.ko loaded, I do not have the /dev/dri/ folder at 
 all.
 
 
 Any ideas on where I should start investigating ?
 I did manually load the nouveau.ko driver as it does not autoload.
 
 Is it because of a missing udev rule ?

Does this still occur with more recent kernels?

Cheers,
Moritz



-- 
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/20110422213641.GA3270@pisco.westfalen.local

Bug#581525: rt2860: rt2860 doesn't connect to WPA2 networks

[Moritz Mühlenhoff]

tags 581525 moreinfo
thanks

On Thu, May 13, 2010 at 02:31:34PM +0200, Miguel Angel Fraile wrote:
 Package: linux-2.6
 Version: 2.6.32-5
 Severity: important
 File: rt2860
 
 It seems it's not possible to connect to WPA2 wireless networks with the 
 squeezix version of the rt2860 module.
 
 I've tested it with both network-manager and wicd. Both of them are unable to 
 authenticate with the correct password.
 
 Both have NO problems to connect to WPA-PSK networks.
 
 Tested with a Buffalo WZR-HP-G300NH router. No problem connecting to that 
 WPA2 network with other devices.
 
 The router encryption is set to WPA/WPA2-Mixed TKIP+AES, using a preshared 
 key.
 
 Tested also after updating the rt2860 firmware-ralink to the Debian SID 
 version (v0.24). No luck, either.

Does this still occur with the final Squeeze kernel or more recent kernels?

Cheers,
Moritz



-- 
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/20110422213830.GA3488@pisco.westfalen.local

Bug#516785: Sun Fire 480R booting now [Was: Re: linux-image-2.6.26-1-sparc64-smp: [sparc] SunFire480R cassini network driver kernel panic]

[Moritz Mühlenhoff]

Hermann Lauer wrote:
  Just found the initcall_debug=1 ignore_loglevel suggested by davem
  during the last debugging session with this machine.
  
  Tail of the output is below for completeness, thought I feel
  I should try the latest stable vanilla kernel when time permits.
 
 2.6.38.2 vanilla compiled under squeeze is booting and running fine 
 since around an hour here on a 480R. Also on 880 it is running
 with minor glitches so far.
 
 Thanks to all the sparc linux people for this good release.
 
 For the debian sparc list: Hoping that wheezy will get a 2.6.38 kernel.

A 2.6.38 based kernel image is already available in wheezy/testing

Please test it and report, if it also works.

Cheers,
Moritz



-- 
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/20110413190127.GA5997@pisco.westfalen.local

Bug#600656: linux-image-2.6.32-5-amd64: Crash after nullpointer dereference during gparted reading a disk

[Moritz Mühlenhoff]

On Wed, Nov 10, 2010 at 02:20:00AM +, Ben Hutchings wrote:
 On Wed, 2010-11-10 at 00:41 +0200, Andreas Feldner wrote:
  Hi Ben,
  
  somehow netconsole doesn't do anything for me. But it turned out the the 
  system behaviour is not exactly reproducible and anyway I can see the 
  messages 
  on screen if X is not started (because nvidia module banned ;-) ).
  
  So, here I have the following error message, hope that helps!
 [...]
 
 OK, this looks really weird.  I looked for reports of similar crashes
 and found http://lkml.org/lkml/2009/11/11/302 which apparently turned
 out to be due to a hardware fault.
 
 Could you test Linux 2.6.36 as packaged in experimental?  If that has
 the same problem, try running memtest86+ for a while to check whether
 this is due to bad RAM.  I suspect it isn't, but we have to check.

Andreas, did you test later kernels (now also in unstable) and memtest?

Cheers,
Moritz



-- 
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/20110401193501.GA11579@pisco.westfalen.local

Bug#504584: [kernel] mount.cifs fails to mount MS DFS shares (object is remote)

[Moritz Mühlenhoff]

tags 504584 moreinfo
thanks

On Wed, Nov 05, 2008 at 12:35:05PM +0100, ulrich.me...@ulmeco.ch wrote:
 Package: kernel
 Version: 2.6.26
 Severity: important
 
 --- Please enter the report below this line. ---
 unable to mount microsoft dfs share
 
 as root:
 mount -t cifs -o credentials=/root/user.txt -o workgroup=WG -o rw
 //test.domain.de/DB_001/Project/BO2 /root/bo2
 
 error message: object is remote
 
 the same share can be accessed using smbclient.
 
 (Ubuntu 8.1 with 2.6.27 does not work either)

Does is work with more recent kernels, e.g. the version from Debian
Squeeze (6.0)?

Cheers,
Moritz



-- 
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/20110401200416.GA14548@pisco.westfalen.local

Bug#510471: sata hd freezes with heavy load

[Moritz Mühlenhoff]

tags 510471 moreinfo
thanks

On Fri, Jan 02, 2009 at 10:14:56AM +0100, Luigi Pizzirani wrote:
 Package: linux-source-2.6.26
 Version: 2.6.26-12
 Severity: important
 
 
 -- no debconf information
 
 Info related to this bug in my dmesg:
 
 scsi 0:0:0:0: Direct-Access ATA  SAMSUNG HM121HI  LZ10 PQ: 0 ANSI: 5
 
 ata1.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x6 frozen
 [   68.392430] ata1.00: cmd 60/90:00:69:f3:3b/00:00:0c:00:00/40 tag 0 ncq 
 73728 in
 [   68.392432]  res 40/00:fe:00:00:00/00:00:00:00:00/40 Emask 0x4 
 (timeout)
 [   68.392437] ata1.00: status: { DRDY }
 [   68.392446] ata1.00: cmd 60/10:08:4e:74:cd/00:00:03:00:00/40 tag 1 ncq 
 8192 in
 [   68.392448]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 
 (timeout)
 [   68.392455] ata1.00: status: { DRDY }
 [   68.392463] ata1.00: cmd 60/14:10:7e:ba:cc/00:00:03:00:00/40 tag 2 ncq 
 10240 in
 [   68.392466]  res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 
 (timeout)
 [   68.392472] ata1.00: status: { DRDY }
 [   68.392480] ata1: hard resetting link
 [   68.697415] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
 [   68.702840] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
 [   68.702840] ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out
 [   68.702840] ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded
 [   68.702840] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
 [   68.713986] ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out
 [   68.713994] ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out
 [   68.714701] ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded
 [   68.714709] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 filtered out
 [   68.718848] ata1.00: configured for UDMA/133
 [   68.730700] ata1.00: configured for UDMA/133
 [   68.730700] ata1: EH complete

Sorry for the late reply.

Does this error still occur with more recent kernels, e.g. the kernel
from Debian 6.0 (squeeze)?

Cheers,
Moritz





-- 
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/20110401193901.GA11990@pisco.westfalen.local

Bug#516785: linux-image-2.6.26-1-sparc64-smp: [sparc] SunFire480R cassini network driver kernel panic

[Moritz Mühlenhoff]

On Mon, Mar 01, 2010 at 12:30:05PM +0100, Hermann Lauer wrote:
 On Wed, Jan 13, 2010 at 09:29:25AM +0100, Hermann Lauer wrote:
  I tried again with vanilla 2.6.32 (2.6.27-2.6.31 are unusable due to a 
  kernel
  memory corruption bug), the driver is still crashing my Sunfire V480R.
 
 Tried today vanilla 2.6.33, then did a:
 
 # modprobe -v cassini cassini_debug=-1
 insmod /lib/modules/2.6.33/kernel/drivers/net/cassini.ko cassini_debug=-1
 
 In kern.log the messages appeared:
 
 Mar  1 12:17:14 tantalus kernel: cassini.c:v1.6 (21 May 2008)
 Mar  1 12:17:14 tantalus kernel: PCI: Enabling device: (0002:00:02.0), cmd 146
 Mar  1 12:17:15 tantalus kernel: cassini: MAC address not found in ROM VPD
 Mar  1 12:17:15 tantalus kernel: eth0: Sun Cassini+ (64bit/33MHz PCI/Cu) 
 Ethernet[24] 08:00:20:cb:31:01
 Mar  1 12:17:15 tantalus kernel: PCI: Enabling device: (0003:00:01.0), cmd 146
 Mar  1 12:17:15 tantalus kernel: cassini: MAC address not found in ROM VPD
 Mar  1 12:17:15 tantalus kernel: udev: renamed network interface eth0 to eth15
 Mar  1 12:17:15 tantalus kernel: eth0: Sun Cassini+ (64bit/66MHz PCI/Cu) 
 Ethernet[30] 08:00:20:bc:c7:b7
 Mar  1 12:17:15 tantalus kernel: udev: renamed network interface eth0 to eth16
 Mar  1 12:20:48 tantalus kernel: eth15: Link up at 1000 Mbps, full-duplex.
 Mar  1 12:20:48 tantalus kernel: eth15: TX pause enabled
 Mar  1 12:20:59 tantalus kernel: eth15: no IPv6 routers present
 
 As before, setting up the interface with ifconfig works.
 After sending out 68 pings the machine crashed with the usual 
 Hardware FATAL RESET.
 
 What can be done to debug this further ?

Is this fixed in later kernels, e.g. the 2.6.38 from Debian unstable?

If so and the fix can be isolated we can fix it in 2.6.32 for Squeeze.

Cheers,
Moritz



-- 
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/20110401194206.GA12436@pisco.westfalen.local

Bug#518643: Same problem found in 2.6.26-2-amd64

[Moritz Mühlenhoff]

tags 518643 moreinfo
thanks

On Fri, Aug 14, 2009 at 09:13:53AM +0200, Eneko Lacunza wrote:
 Hi,
 
 We experienced a similar lockup tonight.

Sorry for the late reply.

The KVM version from Lenny is very old. Did you upgrade to something
more recent since then, e.g. to Debian 6.0 (Squeeze)?

Cheers,
Moritz



-- 
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/20110401194433.GA12792@pisco.westfalen.local

Bug#617364: linux-2.6: lseek() over NFS is returning an incorrect file length under some, circumstances

[Moritz Mühlenhoff]

On Tue, Mar 08, 2011 at 02:30:32PM +0100, Bernd Zeimetz wrote:
 Package: linux-2.6
 Severity: important
 Tags: patch
 
 Due to a NFS attribute revalidation problem it might happen that
 lseek(fd, 0, SEEK_END) returns a stale file size.
 
 Please see https://bugzilla.redhat.com/show_bug.cgi?id=672981 and
 http://archives.postgresql.org/pgsql-hackers/2011-01/msg02611.php for
 details. It would be appreciated if the bug could be fixed in the next
 point-releases for Lenny and Squeeze.
 
 Thanks and cheers,

The ideal way to get this fixed in Squeeze is to get the patches
merged into the 2.6.32 long term kernel, on which Squeeze is based.

Could you check back with Joe Conway and ask for commits IDs of the
upstream fixes?

Cheers,
Moritz



-- 
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/20110401195427.GA13123@pisco.westfalen.local

Re: Bug#605090: Updated patch

[Moritz Mühlenhoff]

Bastian Blank wa...@debian.org schrieb:
   As I already pointed out on the first mail, Brad Sprengler has already
   said he wasn't interested in upstreaming stuff.
  What Brad wants or don't want is irrelevant here. While the patch policy
  for the main kernel is rather strict, other featuresets can incorporate
  more changes. However this is no free ticket to push anything into it.

 Okay. Then I set the rules:
 * The patch must be minimal. This means:
   - Arbitrary fixes must go to mainline.
   - No style changes in random code.

Sorry, it's not up to you to impose rules single-handedly.

There are efforts by Kees and others to mainline some of the more general 
bits of grsecurity, but that's not a reason to postpone a grsec flavour.

Cheers,
Moritz


-- 
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/slrnil8r9d.guj@inutil.org

Re: For discussion: security support strategy for the wheezy kernel

[Moritz Mühlenhoff]

Michael Gilbert michael.s.gilb...@gmail.com schrieb:
 Hi,

 So, my proposal in a nutshell is to only upload upstream 2.6.32 point
 releases to wheezy/sid for the next 12-18 months.  At that time,
 reevaluate and determine what the next longterm cadence kernel will be,
 and then once that is reasonable stabilized in experimental, finally
 upload it to unstable for the final stages of wheezy development
 (perhaps a few months before the freeze).

No way. The idea of unstable is to get the current upstream code in
shape and that won't be achieved with staying with an old kernel.

Whatever the technical solution to testing-security kernel might be,
it needs to be based on following the upstream kernel development.

Cheers,
Moritz


-- 
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/slrnil0dh0.3dh@inutil.org

Re: Bug#605090: Updated patch

[Moritz Mühlenhoff]

maximilian attems m...@stro.at schrieb:
 On Tue, 18 Jan 2011, Yves-Alexis Perez wrote:

 
 Kernel team, what do you think? Could the patches be merged against
 trunk? Config might still need some reviewing but that can be done once
 people start testing the packages.

 What follows is my personal view, in short what I miss most is an
 assessement of the involved cost of this specific feature branch.

 first of all merging a patch that deviates from mainline for an
 eternety and shows zero interest of upstream merging is not a 
 good candidate. You get longterm plenty of cost versus allmost
 no benefit. I'm quite unsure that this patch benefits Debian.

I disagree, the benefit is substantial.

From a distant past look it was in fact quite untastefull.

 The second trouble is that I question your understanding of this patch.
 (viewing the way you answered waldi's questions).

 Third beside security theatre what is gained by it?

What you call theatre is likely the most important decision factor
for most people running Linux professionally.

 Fourth why not invest the time for Wheezy and have finally the mainline
 and security backed SELinux ready. This seems like a much better time
 investment.

SELinux is mostly orthogonal to what grsecurity provides.

 Fifth the ninties are over, an upstream that still doesn't use an VSC
 seems very untrustworthy.

That's silly. If there's anyone who has credible understanding of
Linux kernel security then it's Brad and the PAX team.

Cheers,
Moritz


-- 
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/slrnik3kng.2mb@inutil.org

Re: Bug#605090: Updated patch

[Moritz Mühlenhoff]

Yves-Alexis Perez yves-alexis.pe...@ssi.gouv.fr schrieb:

 --=-KjsYf+tOZ/2izKTMlp2F
 Content-Type: multipart/mixed; boundary==-3ZyLUHkRGZaAINeXRTe3


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

 On mar., 2011-01-04 at 12:25 +0100, Yves-Alexis Perez wrote:
 I've put updated patches on
 http://molly.corsac.net/~corsac/debian/kernel-grsec/patches/ (kernel is
 built but not uploaded to packages/ since it's quite huge, will do that
 at one point. Patches are attached to that mail too.=20
=20
 The first one (add-grsecurity-featureset) is against the debian kernel
 svn tree and add the featureset, while the second (debian-grsecurity) is
 against the grsecurity upstream patch and adapts it to the current
 debian kernel sources (removes the stuff already backported by the
 kernel team etc.).=20
 I expect it to be really smaller for 2.6.37.=20

 I've started working on 2.6.37 since Brad Sprengler recently released
 the grsecurity patch for that kernel.

 Kernel team, what do you think? Could the patches be merged against
 trunk? Config might still need some reviewing but that can be done once
 people start testing the packages.

I'm interested in helping out with maintaining the grsec flavour for Wheezy,
but won't have time to start to work on it until February.

Cheers,
Moritz


-- 
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/slrnijepkn.4cc@inutil.org

CVE-2010-4075/CVE-2010-4076/CVE-2010-4077

[Moritz Mühlenhoff]

What shall we do with CVE-2010-4075, CVE-2010-4076, CVE-2010-4077
at this point of the freeze?

Should be fixed by d281da7ff6f70efca0553c288bb883e8605b3862
and 0587102cf9f427c185bfdeb2cef41e13ee0264b1 , but would change
the ABI. 

We could postpone it to a later point update, where we change the
ABI along with more serious issues requiring an ABI bump?

Cheers,
Moritz


-- 
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/slrnij12a7.52c@inutil.org

Bug#440676: nfs-kernel-server: Simultaneous transfer on mirrored nfs mounts causes service freezes

[Moritz Mühlenhoff]

severity 440676 important
thanks

Jeffrey B. Green:
  A very similar behaviour can be reproduced with i386 as well (with the
  Etch versions of  the Linux kernel and nfs-kernel-server):
  We have a setup where a block device is replicated with drbd. On this
  device an ext3 partition has been created, which is exported over NFS.
  Reading from the NFS share works fairly well, however concurrent writes
  to the share lead to lockups. The client processes copying data to the
  share are stalling and sometimes the system is locked up requiring a hard
  reboot.
 
  This is reproducable with both NFS over UDP and NFS over TCP.

 Actually, the incident is primarily on i386 machines. Sorry about the
 report being a bit deceptive by submitting from my standard work machine
 which is a powerpc. The powerpc kernel may not exhibit this behavior.

Could you please test the attached patch from RHEL5 and report if it resolves
the problem for you?

Instructions on how to compile a modified kernel can be found at
http://wiki.debian.org/DebianKernelCustomCompilation

Cheers,
Moritz
-- 
Moritz Muehlenhoff [EMAIL PROTECTED] fon: +49 421 22 232- 0
DevelopmentLinux for Your Business   fax: +49 421 22 232-99
Univention GmbHhttp://www.univention.de/   mobil: +49 175 22 999 23
From: Steve Dickson [EMAIL PROTECTED]
Subject: [RHEL5][PATCH] NFS: system stall on NFS stress under high memory  pressure
Date: Fri, 15 Dec 2006 08:41:22 -0500
Bugzilla: 213137
Message-Id: [EMAIL PROTECTED]
Changelog: NFS: system stall on NFS stress under high memory  pressure


The following 3 attached patches solve an NFS hang that an number
of upstream and RHEL5 user saw... The hang, which was introduced
in the 2.6.11 kernel, was caused by an RPC task continuously
getting ignored due the a certain combination of task states.
This state combination only seem to happen when there
was memory pressure

The upstream email thread is at:
http://sourceforge.net/mailarchive/message.php?msg_id=37252769

The bz is:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=213137

These patch have been tested by a number of upstream people,
as well as locally on a RHEL5 B2 kernel...

steved.

The sunrpc scheduler contains a race condition that can let an RPC
task end up being neither running nor on any wait queue. The race takes
place between rpc_make_runnable (called from rpc_wake_up_task) and
__rpc_execute under the following condition:
First __rpc_execute calls tk_action which puts the task on some wait
queue. The task is dequeued by another process before __rpc_execute
continues its execution. While executing rpc_make_runnable exactly after
setting the task `running' bit and before clearing the `queued' bit
__rpc_execute picks up execution, clears `running' and subsequently
both functions fall through, both under the false assumption somebody
else took the job.

Swapping rpc_test_and_set_running with rpc_clear_queued in
rpc_make_runnable fixes that hole. This introduces another possible
race condition that can be handled by checking for `queued' after
setting the `running' bit.

Bug noticed on a 4-way x86_64 system under XEN with an NFSv4 server
on the same physical machine, apparently one of the few ways to hit
this race condition at all.

Cc: Trond Myklebust [EMAIL PROTECTED]
Cc: J. Bruce Fields [EMAIL PROTECTED]
Signed-off-by: Christophe Saout [EMAIL PROTECTED]

--- linux-2.6.18.i686/net/sunrpc/sched.c.orig	2006-09-19 23:42:06.0 -0400
+++ linux-2.6.18.i686/net/sunrpc/sched.c	2006-12-05 07:28:24.251992000 -0500
@@ -302,13 +302,15 @@ EXPORT_SYMBOL(__rpc_wait_for_completion_
  */
 static void rpc_make_runnable(struct rpc_task *task)
 {
-	int do_ret;
-
 	BUG_ON(task-tk_timeout_fn);
-	do_ret = rpc_test_and_set_running(task);
 	rpc_clear_queued(task);
-	if (do_ret)
+	if (rpc_test_and_set_running(task))
+		return;
+	/* We might have raced */
+	if (RPC_IS_QUEUED(task)) {
+		rpc_clear_running(task);
 		return;
+	}
 	if (RPC_IS_ASYNC(task)) {
 		int status;
 

Fix a second potential rpc_wakeup race...

Signed-off-by: Trond Myklebust [EMAIL PROTECTED]
---

--- linux-2.6.18.i686/fs/nfs/nfs4proc.c.orig	2006-12-06 10:00:51.31643 -0500
+++ linux-2.6.18.i686/fs/nfs/nfs4proc.c	2006-12-12 12:07:21.607308000 -0500
@@ -636,7 +636,7 @@ static int _nfs4_proc_open_confirm(struc
 		smp_wmb();
 	} else
 		status = data-rpc_status;
-	rpc_release_task(task);
+	rpc_put_task(task);
 	return status;
 }
 
@@ -742,7 +742,7 @@ static int _nfs4_proc_open(struct nfs4_o
 		smp_wmb();
 	} else
 		status = data-rpc_status;
-	rpc_release_task(task);
+	rpc_put_task(task);
 	if (status != 0)
 		return status;
 
@@ -3059,7 +3059,7 @@ static int _nfs4_proc_delegreturn(struct
 		if (status == 0)
 			nfs_post_op_update_inode(inode, data-fattr);
 	}
-	rpc_release_task(task);
+	rpc_put_task(task);
 	return status;
 }
 
@@ -3306,7 +3306,7 @@ static int nfs4_proc_unlck(struct nfs4_s
 	if (IS_ERR(task))
 		goto out;