Re: Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

[Vincent Lefevre]

On 2012-07-20 08:31:19 +0200, Julien Cristau wrote:
> Sounds like you have slowkeys enabled.
> http://who-t.blogspot.fr/2012/06/xkb-slowkeys.html

So, it would seem that some part of the system would enable SlowKeys
in my back for one of the keyboards (I recall that when this happens
while I'm using the USB keyboard, only the USB keyboard is affected,
not the laptop keyboard).

If there a way to know whether SlowKeys is enabled, for each available
keyboard? (Note: I'm not using GNOME, and even GNOME would be useless
because according to what I see on this page, it cannot differentiate
keyboards.)

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


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120720065857.ga4...@xvii.vinc17.org

Re: Bug#677173: 3.2.19-1: after some time, the USB keyboard no longer works

[Julien Cristau]

On Fri, Jul 20, 2012 at 01:40:52 +0200, Vincent Lefevre wrote:

> On 2012-07-14 21:38:05 +0200, Vincent Lefevre wrote:
> > So, it seems that when the problem occurs, the keyboard modifiers may
> > still be working with clicks (to be confirmed).
> 
> Forget that. The problem is the following: a keypress is taken into
> account only if the key is kept pressed for about half a second (key
> modifiers are generally pressed at least that time when used as a
> combination with a click, that's why they appear to be working as
> usual), a bit like the Power button needs to be pressed for some time
> to be taken into account. If a normal key is pressed long enough, it
> repeats until it is released, as usual.
> 
Sounds like you have slowkeys enabled.
http://who-t.blogspot.fr/2012/06/xkb-slowkeys.html

Cheers,
Julien


signature.asc
Description: Digital signature

Re: [RFC] Simplifying kernel configuration for distro issues

[david]

On Thu, 19 Jul 2012, Ben Hutchings wrote:


On Thu, Jul 19, 2012 at 06:30:47PM +0100, Alan Cox wrote:


For the end user case you need the distro to plonk the right file in the
right place and be done with it, once they do that the rest is
bikeshedding a ten line Makefile rule.


This might work well for future releases; is there not a need to
make this work for past releases too?


This approach can work for any 3.x kernel version with any distro. The 
distro provides the file, with a new kernel version you do "make 
distconfig', with something prior to when this is added you do 'cp 
/etc/kconfig/filename .config ; make oldconfig' instead.


the make oldconfig papers over a LOT of differences between the kernel 
that the distro built with and the kernel the user is trying to compile.


David Lang


--
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/alpine.deb.2.02.1207191942250.20...@asgard.lang.hm

Re: 3.2.19-1: after some time, the USB keyboard no longer works

[Vincent Lefevre]

On 2012-07-14 21:38:05 +0200, Vincent Lefevre wrote:
> So, it seems that when the problem occurs, the keyboard modifiers may
> still be working with clicks (to be confirmed).

Forget that. The problem is the following: a keypress is taken into
account only if the key is kept pressed for about half a second (key
modifiers are generally pressed at least that time when used as a
combination with a click, that's why they appear to be working as
usual), a bit like the Power button needs to be pressed for some time
to be taken into account. If a normal key is pressed long enough, it
repeats until it is released, as usual.

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


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120719234052.ga31...@xvii.vinc17.org

Re: [RFC] Simplifying kernel configuration for distro issues

[Steven Rostedt]

On Thu, 2012-07-19 at 18:35 -0400, Josh Boyer wrote:

> > >2... yeah.  I don't really know if that is going to pan out, but I am
> > >ever hopeful.  I'd be mostly concerned with people that are coding
> > >userspace applications using every whiz-bang kernel feature.  Or not
> > >paying attention at all to the kernel after the initial file creation
> > >and the options going stale (don't follow renames, etc).
> > 
> > it would be determined by the distro maintainers who maintain the
> > kernel config for that distro.
> 
> Erm... not in Steven's scheme.  At least I don't think distro kernel
> maintainers are going to willingly crawl through every application
> package that might depend on a kernel feature being enabled and maintain
> those files across X number of packages.

Correct. If we keep the selects in the kernel proper, then it would be
the kernel maintainer to make sure it works for the necessary
applications.

If we have a directory called /usr/share/Linux/Kconfig.d/ then the
individual packages could add their needed selects. Now this wouldn't be
for the average package. We don't need emacs developers adding any
configs here. It's just for those packages that are already tightly
coupled with the kernel (systemd, iptables, SELinux tools, etc).

-- Steve



-- 
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/1342738194.12353.80.ca...@gandalf.stny.rr.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Josh Boyer]

On Thu, Jul 19, 2012 at 02:04:11PM -0700, da...@lang.hm wrote:
> On Thu, 19 Jul 2012, Josh Boyer wrote:
> 
> >On Thu, Jul 19, 2012 at 02:13:40PM -0400, Steven Rostedt wrote:
> >>On Thu, 2012-07-19 at 13:56 -0400, Josh Boyer wrote:
> >>
> >>>Distros aren't stationary things.
> >>
> >>Exactly my point.
> >>
> >>>  I mean, some of them certainly aim
> >>>for that goal, but userspace and kernels get upgraded all the time.  So
> >>>if this distro-Kconfig file is provided by some package _other_ than the
> >>>kernel the distros are going to have a bit of a hassle keeping track of
> >>>it.
> >>
> >>How about a directory called /usr/share/Linux/Kconfig.d/
> >>
> >>Then have anything installed that needs to work correctly put in its
> >>minimum (must have) requirement configs of the kernel.
> >>
> >>Say you are running Debian, and decide to try out systemd. If you set up
> >>your system to run that it would add a file called:
> >>
> >>/usr/share/Linux/Kconfig.d/systemd.conf
> >>
> >>or something, and this would select things like CGROUPS and the like. We
> >>could make the kernel build select all, or individual files in this
> >>directory. All for the 'make my distro work' or individual for a 'I want
> >>part of my distro to work' option.
> >
> >That sounds like a pretty good idea, aside from the fact that now your
> >config is determined by 1) what is currently installed on your system
> >and 2) people that don't maintain the kernel.
> >
> >1 is obviously a great thing once you have a stable working set of
> >packages you use daily, but wouldn't it kind of suck to have to rebuild
> >the kernel just to install some new package?  I mean... say you wanted
> >to now use an NFS mount, but you didn't have nfs-utils previously
> >installed.  So you install it, and it plops the kconfig file in
> >/usr/share but oops, you have to rebuild the kernel and reboot because
> >that module isn't built.  Of course I'm extrapolating possibly the worst
> >usage case here, but it will still happen.
> 
> the alturnative to this is what? compile everything just in case you
> need it some time in the future?

Why do people swing from one extreme to another so quickly?  Surely
there is some middle ground.

> we already have some tools (vmware) that check for the proper kernel
> config when they startup, and if the appropriate stuff isn't there
> they ask for the root password and compile the modules.
> 
> >2... yeah.  I don't really know if that is going to pan out, but I am
> >ever hopeful.  I'd be mostly concerned with people that are coding
> >userspace applications using every whiz-bang kernel feature.  Or not
> >paying attention at all to the kernel after the initial file creation
> >and the options going stale (don't follow renames, etc).
> 
> it would be determined by the distro maintainers who maintain the
> kernel config for that distro.

Erm... not in Steven's scheme.  At least I don't think distro kernel
maintainers are going to willingly crawl through every application
package that might depend on a kernel feature being enabled and maintain
those files across X number of packages.

josh


-- 
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/20120719223519.gi8...@zod.bos.redhat.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Geert Uytterhoeven]

On Thu, Jul 19, 2012 at 8:22 PM, Josh Boyer  wrote:
> On Thu, Jul 19, 2012 at 08:20:36PM +0200, Paul Bolle wrote:
>> On Thu, 2012-07-19 at 13:19 -0400, Josh Boyer wrote:
>> > kconfig already spits out warnings for symbols being selected that
>> > don't exist.
>>
>> Does it? Since when does it do that? Or do you mean select in a more
>> general way (not just meaning Kconfig's "select" statement)?
>
> I believe Alan was more correct than me when he said it was 'make
> oldconfig' that produced the warnings.

Indeed, no warnings for all these remaining "select MISC_DEVICES"
(patch sent to remove these).

Gr{oetje,eeting}s,

Geert

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

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


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/camuhmdvib6eclzx12ph8kqt6aetrxmmma1kb-bsdf2qmtxk...@mail.gmail.com

Re: [RFC] Simplifying kernel configuration for distro issues

[david]

On Thu, 19 Jul 2012, Josh Boyer wrote:


On Thu, Jul 19, 2012 at 02:13:40PM -0400, Steven Rostedt wrote:

On Thu, 2012-07-19 at 13:56 -0400, Josh Boyer wrote:


Distros aren't stationary things.


Exactly my point.


  I mean, some of them certainly aim
for that goal, but userspace and kernels get upgraded all the time.  So
if this distro-Kconfig file is provided by some package _other_ than the
kernel the distros are going to have a bit of a hassle keeping track of
it.


How about a directory called /usr/share/Linux/Kconfig.d/

Then have anything installed that needs to work correctly put in its
minimum (must have) requirement configs of the kernel.

Say you are running Debian, and decide to try out systemd. If you set up
your system to run that it would add a file called:

/usr/share/Linux/Kconfig.d/systemd.conf

or something, and this would select things like CGROUPS and the like. We
could make the kernel build select all, or individual files in this
directory. All for the 'make my distro work' or individual for a 'I want
part of my distro to work' option.


That sounds like a pretty good idea, aside from the fact that now your
config is determined by 1) what is currently installed on your system
and 2) people that don't maintain the kernel.

1 is obviously a great thing once you have a stable working set of
packages you use daily, but wouldn't it kind of suck to have to rebuild
the kernel just to install some new package?  I mean... say you wanted
to now use an NFS mount, but you didn't have nfs-utils previously
installed.  So you install it, and it plops the kconfig file in
/usr/share but oops, you have to rebuild the kernel and reboot because
that module isn't built.  Of course I'm extrapolating possibly the worst
usage case here, but it will still happen.


the alturnative to this is what? compile everything just in case you need 
it some time in the future?


we already have some tools (vmware) that check for the proper kernel 
config when they startup, and if the appropriate stuff isn't there they 
ask for the root password and compile the modules.



2... yeah.  I don't really know if that is going to pan out, but I am
ever hopeful.  I'd be mostly concerned with people that are coding
userspace applications using every whiz-bang kernel feature.  Or not
paying attention at all to the kernel after the initial file creation
and the options going stale (don't follow renames, etc).


it would be determined by the distro maintainers who maintain the kernel 
config for that distro.


David Lang


--
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/alpine.deb.2.02.1207191357360.20...@asgard.lang.hm

Re: [RFC] Simplifying kernel configuration for distro issues

[Ben Hutchings]

On Thu, Jul 19, 2012 at 06:30:47PM +0100, Alan Cox wrote:
> 
> > Well, yes.  I was thinking it would be more like:
> > 
> > distro/Kconfig.fedora
> > menuconfig FEDORA
> > if FEDORA
> > config FEDORA_16
> >select WHATEVER
> > config FEDORA_17
> 
> Nope you need
> 
> distro/everyarchtheyship/everykernelvarianttkeyship(smp,largemem,arm
> boards)/Kconfig
> 
> which for some distros is over 20 per release and the end user wouldn't
> have a cat in hells chance of knowing which to pick.

20?  Debian's kernel package currently lists 17 architectures (11
source architectures) and 44 variants (excluding PREEMPT_RT and s390
install tape).  (But 'only' 31 will be in the next release, as even
Debian is capable of letting go of an architecture.)

But, assuming a native build (a whole weekend's worth of fun on m68k!)
we already know the target architecture and most of the other
variations can be chosen automatically similarly to localmodconfig.
We already do something like that (choosing between the pre-built
variants) at distribution install time, after all.

> For the end user case you need the distro to plonk the right file in the
> right place and be done with it, once they do that the rest is
> bikeshedding a ten line Makefile rule.
 
This might work well for future releases; is there not a need to
make this work for past releases too?

Ben.

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


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120719211357.gz1...@decadent.org.uk

Processed: Re: Bug#682144: linux-image-3.2.0-3-amd64: flash videos unviewable, invalid command stream on radeon

[Debian Bug Tracking System]

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

> reassign 682144 src:linux 3.2.21-3
Bug #682144 [src] linux-image-3.2.0-3-amd64: flash videos unviewable, invalid 
command stream on radeon
Warning: Unknown package 'src'
Bug reassigned from package 'src' to 'src:linux'.
No longer marked as found in versions 3.2.21-3.
Ignoring request to alter fixed versions of bug #682144 to the same values 
previously set
Bug #682144 [src:linux] linux-image-3.2.0-3-amd64: flash videos unviewable, 
invalid command stream on radeon
Marked as found in versions linux/3.2.21-3.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
682144: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682144
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.134273219214340.transcr...@bugs.debian.org

Bug#679750: Lenovo G360: ALPS Touchpad Recognized as "PS/2 Generic Mouse"(with newly dmesg information)

[Seth Forshee]

On Sun, Jul 15, 2012 at 10:15:57AM +0800, littlebat wrote:
> In the Windows 7 guest OS, the touchpad "Lenovo pointing device"
> disappeared from the hardwares list. And, the log file in Ubuntu 11.10
> has the content below: 
> y@y-PC:~$ cat ./psmouse-reverse/reverse.log 
> S ff
> R fe
> S ff
> R fe
> S ff
> R fe
> S ed
> R fe

>From the outset this doesn't look right. When reset is sent (0xff) the
touchpad should respond with and acknowledge (0xfa) and a couple more
bytes. Something obviously isn't working right, but I'm not sure what.

The only suggestion I have is to start debugging and try to see what's
going wrong. Is the data from the guest OS getting to the hardware okay,
and vice versa? Are you sure you've got the correct device?

Seth


-- 
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/20120719194740.GA21315@ubuntu-530U

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

[Konrad Rzeszutek Wilk]

On Thu, Jul 19, 2012 at 07:53:10PM +0200, Borislav Petkov wrote:
> On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote:
> > On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov  wrote:
> > >
> > > Seriously, this helps only in the cases where the stuff the distro
> > > actually needs is in modules. So, there probably are obscure situations
> > > where you need to enable stuff which is bool and not M.
> > 
> > Sadly, not obscure at all.
> > 
> > Most of the *drivers* are modules, but most of the "distro config"
> > options are indeed booleans (or, if tristate, =y).
> > 
> > Even driver-wise, there are some things that are often =y, even though
> > you generally don't want them.
> 
> Tell me about it. I'm always pissed off when someone thinks his stuff is
> very important and sets his sacred option to be =y/=m by default so the
> wider audience can at least compile-test it while the majority of the
> machines don't actually need it.
> 
> A more coarse-grained config where most of the stuff is off by default
> could take care of that probably.
> 
> > PCMCIA? Not even *laptops* have that shit any more, but having
> > built-in cardbus support almost certainly helps in a distro kernel for
> > booting of certain odder cases.
> 
> Yeah, distros need the one-size-fits-all thing so they have to enable
> *everything*.
> 
> > Xen support? Odd partition tables? All the different AGP versions?
> > Many of us couldn't care less, but again, it makes sense in the actual
> > distro kernel, even if it does *not* necessarily make sense in a
> > personalized one.
> 
> Yep.

I proposed something that would solve some of this - but not during
compile time but rather during boot-time
[http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/99.html]
(interestingly enough hpa was first to propose it 10 years ago :-)

The goal is turn built-in components in well, unloadable components.
That way you won't have at least that much stuff laying around not being
used. Not the full silver bullet, but at least it gets some of this
stuff out of the way and you don't have to worry about the extra
stuff that was built-in.


-- 
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/20120719184249.ga6...@phenom.dumpdata.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Paul Bolle]

On Thu, 2012-07-19 at 20:49 +0200, Geert Uytterhoeven wrote:
> > I believe Alan was more correct than me when he said it was 'make
> > oldconfig' that produced the warnings.
> 
> Kconfig does spit out warnings for selecting things with unmet dependencies.
> But does anyone care?
> 
> [...checking logs...]
> 
> Oh, only 12 warnings in the v3.5-rc7 builds. Not that bad as my gut feeling
> said...

Well, that's yet another issue but anyhow. That number of warnings
should presumably drop to (almost) zero if those weren't warnings but
errors. Has that ever been tried?


Paul Bolle


-- 
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/1342724136.26179.44.camel@x61.thuisdomein

Re: [RFC] Simplifying kernel configuration for distro issues

[Josh Boyer]

On Thu, Jul 19, 2012 at 02:13:40PM -0400, Steven Rostedt wrote:
> On Thu, 2012-07-19 at 13:56 -0400, Josh Boyer wrote:
> 
> > Distros aren't stationary things.
> 
> Exactly my point.
> 
> >   I mean, some of them certainly aim
> > for that goal, but userspace and kernels get upgraded all the time.  So
> > if this distro-Kconfig file is provided by some package _other_ than the
> > kernel the distros are going to have a bit of a hassle keeping track of
> > it.
> 
> How about a directory called /usr/share/Linux/Kconfig.d/
> 
> Then have anything installed that needs to work correctly put in its
> minimum (must have) requirement configs of the kernel.
> 
> Say you are running Debian, and decide to try out systemd. If you set up
> your system to run that it would add a file called:
> 
> /usr/share/Linux/Kconfig.d/systemd.conf
> 
> or something, and this would select things like CGROUPS and the like. We
> could make the kernel build select all, or individual files in this
> directory. All for the 'make my distro work' or individual for a 'I want
> part of my distro to work' option.

That sounds like a pretty good idea, aside from the fact that now your
config is determined by 1) what is currently installed on your system
and 2) people that don't maintain the kernel.

1 is obviously a great thing once you have a stable working set of
packages you use daily, but wouldn't it kind of suck to have to rebuild
the kernel just to install some new package?  I mean... say you wanted
to now use an NFS mount, but you didn't have nfs-utils previously
installed.  So you install it, and it plops the kconfig file in
/usr/share but oops, you have to rebuild the kernel and reboot because
that module isn't built.  Of course I'm extrapolating possibly the worst
usage case here, but it will still happen.

2... yeah.  I don't really know if that is going to pan out, but I am
ever hopeful.  I'd be mostly concerned with people that are coding
userspace applications using every whiz-bang kernel feature.  Or not
paying attention at all to the kernel after the initial file creation
and the options going stale (don't follow renames, etc).


> > Upgraded the kernel within the confines of that distro, right?  So you
> > go back to what was already installed and working.  You don't go back
> > arbitrarily far just to see what happens.  I would think a reasonably
> > crafted distro config would work in those scenarios.
> 
> A reasonable one, but still not the minimum.

The definition of minimum seems to be what we're disagreeing on.  I'm
approaching it from "minimum for a default install of the distro
release".  OK, that and maybe a few common case usages (like NFS, CIFS,
etc).  You seem to be approaching it from literally bare minimum.

> One issue with Linus's proposal is that he's asking us to focus on the
> 99%. But the 99% of who? Because 99% of Linux users do not compile their
> own kernels, so he must be asking about the 99% of Linux users that
> compile their own kernels. This 99% does not just simply compile their
> kernels, but only want to compile the absolutely necessary stuff. That
> is, they want their kernels not to include anything they are not using.
> 
> A reasonable config would probably need to include a lot that's not
> used.

Perhaps.  I thought getting it reasonable would benefit more people,
even at the cost of some smaller bloat than bare minimum.  I don't think
either of us are really wrong, it's more a matter of who is really going
to use this and why I guess.

josh


-- 
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/20120719183645.gh8...@zod.bos.redhat.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Geert Uytterhoeven]

On Thu, Jul 19, 2012 at 8:22 PM, Josh Boyer  wrote:
> On Thu, Jul 19, 2012 at 08:20:36PM +0200, Paul Bolle wrote:
>> On Thu, 2012-07-19 at 13:19 -0400, Josh Boyer wrote:
>> > kconfig already spits out warnings for symbols being selected that
>> > don't exist.
>
>> Does it? Since when does it do that? Or do you mean select in a more
>> general way (not just meaning Kconfig's "select" statement)?
>
> I believe Alan was more correct than me when he said it was 'make
> oldconfig' that produced the warnings.

Kconfig does spit out warnings for selecting things with unmet dependencies.
But does anyone care?

[...checking logs...]

Oh, only 12 warnings in the v3.5-rc7 builds. Not that bad as my gut feeling
said...

warning: (ETRAX_USB_HOST && MOUSE_APPLETOUCH && MOUSE_BCM5974 &&
MOUSE_SYNAPTICS_USB && JOYSTICK_XPAD && TABLET_USB_ACECAD &&
TABLET_USB_AIPTEK && TABLET_USB_HANWANG && TABLET_USB_KBTAB &&
TABLET_USB_WACOM && TOUCHSCREEN_USB_COMPOSITE && INPUT_ATI_REMOTE2 &&
INPUT_KEYSPAN_REMOTE && INPUT_POWERMATE && INPUT_YEALINK &&
INPUT_CM109) selects USB which has unmet direct dependencies
(USB_SUPPORT && USB_ARCH_HAS_HCD): 10 warnings in 2 logs
warning: (IWLWIFI && IWLEGACY && ATH5K && ATH9K && ATH9K_HTC &&
CARL9170_LEDS) selects MAC80211_LEDS which has unmet direct
dependencies (NET && WIRELESS && MAC80211 && LEDS_CLASS): 10 warnings
in 2 logs
warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP
&& KMEMCHECK) selects FRAME_POINTER which has unmet direct
dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 ||
SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS): 10
warnings in 2 logs
warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC && MTD_NAND_FSL_UPM)
selects FSL_LBC which has unmet direct dependencies (FSL_SOC): 9
warnings in 2 logs
warning: (SINGLE_MEMORY_CHUNK) selects NEED_MULTIPLE_NODES which has
unmet direct dependencies (DISCONTIGMEM || NUMA): 9 warnings in 2 logs
warning: (COMPAT) selects COMPAT_BINFMT_ELF which has unmet direct
dependencies (COMPAT && BINFMT_ELF): 3 warnings in 1 logs
warning: (DRM) selects DMA_SHARED_BUFFER which has unmet direct
dependencies (EXPERIMENTAL): 3 warnings in 1 logs
warning: (DRM_RADEON_KMS && DRM_I915 && STUB_POULSBO && FB_BACKLIGHT
&& USB_APPLEDISPLAY && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP &&
THINKPAD_ACPI && EEEPC_LAPTOP && ACPI_CMPC && SAMSUNG_Q10 &&
APPLE_GMUX) selects BACKLIGHT_CLASS_DEVICE which has unmet direct
dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT): 3 warnings in 1
logs
warning: (IA64) selects PM which has unmet direct dependencies
(PM_SLEEP || PM_RUNTIME): 4 warnings in 1 logs
warning: (MOUSE_APPLETOUCH && MOUSE_BCM5974 && MOUSE_SYNAPTICS_USB &&
JOYSTICK_XPAD && TABLET_USB_ACECAD && TABLET_USB_AIPTEK &&
TABLET_USB_HANWANG && TABLET_USB_KBTAB && TABLET_USB_WACOM &&
TOUCHSCREEN_USB_COMPOSITE && INPUT_ATI_REMOTE2 && INPUT_KEYSPAN_REMOTE
&& INPUT_POWERMATE && INPUT_YEALINK && INPUT_CM109 && RC_ATI_REMOTE &&
IR_IMON && IR_MCEUSB && IR_REDRAT3 && IR_STREAMZAP && DRM_USB) selects
USB which has unmet direct dependencies (USB_SUPPORT &&
USB_ARCH_HAS_HCD): 5 warnings in 1 logs
warning: (PLATFORM_AT32AP) selects HAVE_NET_MACB which has unmet
direct dependencies (NETDEVICES && ETHERNET): 3 warnings in 1 logs
warning: (PREEMPT && DEBUG_ATOMIC_SLEEP) selects PREEMPT_COUNT which
has unmet direct dependencies (COLDFIRE): 5 warnings in 1 logs

Gr{oetje,eeting}s,

Geert

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

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


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/camuhmdwunmatvf3sefwbtrfczwy01rdzvcx_htwe2q62rpc...@mail.gmail.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Josh Boyer]

On Thu, Jul 19, 2012 at 08:20:36PM +0200, Paul Bolle wrote:
> On Thu, 2012-07-19 at 13:19 -0400, Josh Boyer wrote:
> > kconfig already spits out warnings for symbols being selected that
> > don't exist.
> 
> Does it? Since when does it do that? Or do you mean select in a more
> general way (not just meaning Kconfig's "select" statement)?

I believe Alan was more correct than me when he said it was 'make
oldconfig' that produced the warnings.

josh


-- 
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/20120719182235.gg8...@zod.bos.redhat.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Paul Bolle]

On Thu, 2012-07-19 at 13:19 -0400, Josh Boyer wrote:
> kconfig already spits out warnings for symbols being selected that
> don't exist.

Does it? Since when does it do that? Or do you mean select in a more
general way (not just meaning Kconfig's "select" statement)?


Paul Bolle


-- 
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/1342722036.26179.40.camel@x61.thuisdomein

Re: [RFC] Simplifying kernel configuration for distro issues

[Steven Rostedt]

On Thu, 2012-07-19 at 13:56 -0400, Josh Boyer wrote:

> Distros aren't stationary things.

Exactly my point.

>   I mean, some of them certainly aim
> for that goal, but userspace and kernels get upgraded all the time.  So
> if this distro-Kconfig file is provided by some package _other_ than the
> kernel the distros are going to have a bit of a hassle keeping track of
> it.

How about a directory called /usr/share/Linux/Kconfig.d/

Then have anything installed that needs to work correctly put in its
minimum (must have) requirement configs of the kernel.

Say you are running Debian, and decide to try out systemd. If you set up
your system to run that it would add a file called:

/usr/share/Linux/Kconfig.d/systemd.conf

or something, and this would select things like CGROUPS and the like. We
could make the kernel build select all, or individual files in this
directory. All for the 'make my distro work' or individual for a 'I want
part of my distro to work' option.



> Upgraded the kernel within the confines of that distro, right?  So you
> go back to what was already installed and working.  You don't go back
> arbitrarily far just to see what happens.  I would think a reasonably
> crafted distro config would work in those scenarios.

A reasonable one, but still not the minimum.

One issue with Linus's proposal is that he's asking us to focus on the
99%. But the 99% of who? Because 99% of Linux users do not compile their
own kernels, so he must be asking about the 99% of Linux users that
compile their own kernels. This 99% does not just simply compile their
kernels, but only want to compile the absolutely necessary stuff. That
is, they want their kernels not to include anything they are not using.

A reasonable config would probably need to include a lot that's not
used.

-- Steve



-- 
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/1342721620.12353.75.ca...@gandalf.stny.rr.com

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

[Borislav Petkov]

On Thu, Jul 19, 2012 at 01:57:26PM -0400, Steven Rostedt wrote:
> Yes, I know you know this already, as we discussed it in a pub over a
> beer (choir practice). But this is a public forum on LKML (the church),
> where I now have an audience of heathens. Convert! Convert! You are all
> sinners!

Ah, gotcha.

[ … ]

> But this still doesn't solve Linus's initial request. That would be a
> single option that makes your distro boot, and work well. Again, that
> option wont have the drivers needed, but it will enable all the core
> infrastructure that you need.

Oh I'm being additive here. You'll have feature profiles for the stuff
we talk above and distro profiles which solve Linus' issue. Basically
one coarse-grained config option will either select a feature which has
a lot of small subfeatures of which some are sane and want to be enabled
by default when selecting the topfeature.

Or a distro-specific feature which could itself select other
topfeatures.

I haven't tried this in reality to actually be able to say that a
tree-like configure approach would actually make sense and work. It
sounds like a nice idea though, especially having the hierarchical
structure. :)

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551


-- 
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/20120719180914.gg23...@aftab.osrc.amd.com

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

[Steven Rostedt]

On Thu, 2012-07-19 at 19:34 +0200, Borislav Petkov wrote:

> > I can pass the above to a allnoconfig, and the box will boot and allow
> > ssh. Note, the reason for the serial config, is that this ktest run uses
> > a serial port to see if the box booted. If the serial isn't there, then
> > it thinks it failed.
> 
> I agree with all this and you've explained this to me live already so
> you're preaching to the choir.

Yes, I know you know this already, as we discussed it in a pub over a
beer (choir practice). But this is a public forum on LKML (the church),
where I now have an audience of heathens. Convert! Convert! You are all
sinners!

> 
> But it would be a lot faster/easier if users can select, let's call'em
> "profiles" which are not mutually exclusive and can speed up the
> configuration process. They can either be distro-specific or generic,
> selecting certain features you need.
> 
> So configuring your kernel would be like shopping without paying too
> much attention to details. Let's look into the head of a person doing a
> config like that and read some of her thoughts :):
> 
> "Hm, ok, this new configurator is cool, a lot faster I gotta say... So,
> what do I need, ah, yes, it is an AMD laptop so from vendors I select
> AMD, then I probably need ext4, then I'd like to do packet filtering
> so I should enable iptables.. Oh, I'd like to do tracing too so let's
> enable tracing and trust Steven with the options he's added by default,
> then I need ahci, I'd also like to do encrypted partitions so I'll
> enable device mapper with crypto... "
> 
> So all those things could be selectable from that profiles menu without
> having to go through the gazillion of little suboptions and having to
> read help (which is sometimes completely helpless) and figure out do I
> need it or not.
> 
> And this would simplify configuration a lot. IMHO, anyway.
> 

I totally agree with this. It would be nice to have a profile list where
you can pick and chose what you have installed:

network
nfs
ext3
serial
xen
kvm
etc etc

Where you can pick and choose what general features you want and it
selects all the core infrastructure to get those features usable. It
wouldn't select the device modules needed, you will still need to select
what hardware you have. But it gets most of the work done for you.

But this still doesn't solve Linus's initial request. That would be a
single option that makes your distro boot, and work well. Again, that
option wont have the drivers needed, but it will enable all the core
infrastructure that you need.

Going with my /usr/share/Linux/Kconfig, this could use the profile
options as well. And just select those that are required. But then
again, Linus did want a minimum selection of stuff.

Side note (again), IIRC, "select" has a bug. If you have Config X
selecting config Y but Y depends on Z, if you enable X, it will enable Y
without enabling Z. I think there were some patches to address this, but
I don't remember.

-- Steve



-- 
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/1342720646.12353.67.ca...@gandalf.stny.rr.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Josh Boyer]

On Thu, Jul 19, 2012 at 01:33:42PM -0400, Steven Rostedt wrote:
> On Thu, 2012-07-19 at 13:19 -0400, Josh Boyer wrote:
> 
> > > What about older kernels? Say you installed Fedora 18 with an older
> > > kernel that doesn't know what to select? Having the distro tell the
> > > kernel what it needs seems to me the easiest for the 99% case.
> > 
> > How is the above not telling the kernel what it needs?  I'm confused how
> > the location of such a file makes it's functionality and usefulness
> > differ...  Quite possible I missed what you meant originally, but it
> > sounds like we're talking about the same thing?
> 
> The point is, the user wont have to think "What distro am I running? and
> what version am I running?". I don't even know what version of the disto
> I'm currently running (Debian testing).
>
> The point is, the current running distro supplies what is needed from
> the kernel in order to work properly. The user does not need to 'select'
> it. They would only have to select a 'add my distro min configs'.

Distros aren't stationary things.  I mean, some of them certainly aim
for that goal, but userspace and kernels get upgraded all the time.  So
if this distro-Kconfig file is provided by some package _other_ than the
kernel the distros are going to have a bit of a hassle keeping track of
it.

> A developer working with a user could just say, "select disto config"
> without needing to know what distro the user has.
> 
> What happens if someone does a yum update, and the kernel requirement
> changes slightly. The yum update should update
> this /usr/share/Linux/Kconfig. But it's still set at Fedora X. The
> kernel can not be updated for these slight changes.

I'm not quite following what you mean in the yum update case, sorry.

> > Also, I'm not very convinced the 99% are going to be wanting to install
> > shiny new versions of a distro with a kernel older than what the distro
> > ships with.  I could be very wrong, but it seems like in-general the
> > whole premise of this RFC was geared towards using new kernels on
> > distros.
> 
> There are times when the update breaks something. A user may backport to
> an older kernel where their Gizmo worked. I've done this to get webcams
> working. I know I'm not the 99%, but the rational for my operation was a
> 99% thing to do: Crap, I upgraded my kernel and now my webcam doesn't
> work. Oh well, download an older version and boot that one.

Upgraded the kernel within the confines of that distro, right?  So you
go back to what was already installed and working.  You don't go back
arbitrarily far just to see what happens.  I would think a reasonably
crafted distro config would work in those scenarios.

josh


-- 
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/20120719175649.gf8...@zod.bos.redhat.com

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

[Borislav Petkov]

On Thu, Jul 19, 2012 at 10:06:44AM -0700, Linus Torvalds wrote:
> On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov  wrote:
> >
> > Seriously, this helps only in the cases where the stuff the distro
> > actually needs is in modules. So, there probably are obscure situations
> > where you need to enable stuff which is bool and not M.
> 
> Sadly, not obscure at all.
> 
> Most of the *drivers* are modules, but most of the "distro config"
> options are indeed booleans (or, if tristate, =y).
> 
> Even driver-wise, there are some things that are often =y, even though
> you generally don't want them.

Tell me about it. I'm always pissed off when someone thinks his stuff is
very important and sets his sacred option to be =y/=m by default so the
wider audience can at least compile-test it while the majority of the
machines don't actually need it.

A more coarse-grained config where most of the stuff is off by default
could take care of that probably.

> PCMCIA? Not even *laptops* have that shit any more, but having
> built-in cardbus support almost certainly helps in a distro kernel for
> booting of certain odder cases.

Yeah, distros need the one-size-fits-all thing so they have to enable
*everything*.

> Xen support? Odd partition tables? All the different AGP versions?
> Many of us couldn't care less, but again, it makes sense in the actual
> distro kernel, even if it does *not* necessarily make sense in a
> personalized one.

Yep.

> So doing "make allmodconfig" is certainly a workable thing (modulo the
> modules that you need for stuff you hadn't happened to use), but it's
> not wonderful.

Oh and I always aim to build distro kernels on a big machine -
allmodconfig build is no fun on a tiny laptop. So would it be better
to have better profiled kernels, obviating the need for an almost full
build? Hell yeah!

> I also hate having to enable support for modules. A non-modular build
> is quicker to build and avoids some security issues. Some drivers
> don't work well built-in (they load firmware etc too early), but imho
> it's worth doing if you can, and it's something we should make easy
> for people to do because of the security side (of course, per-build
> randomly generated keys and signed modules with the keys deleted after
> the build would be reasonably equivalent from a security standpoint,
> but we're not there yet).

Agreed.

So there are some not-so-obscure situations, judging by your examples
above. Ho-humm.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551


-- 
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/20120719175310.gf23...@aftab.osrc.amd.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Josh Boyer]

On Thu, Jul 19, 2012 at 06:30:47PM +0100, Alan Cox wrote:
> 
> > Well, yes.  I was thinking it would be more like:
> > 
> > distro/Kconfig.fedora
> > menuconfig FEDORA
> > if FEDORA
> > config FEDORA_16
> >select WHATEVER
> > config FEDORA_17
> 
> Nope you need
> 
> distro/everyarchtheyship/everykernelvarianttkeyship(smp,largemem,arm
> boards)/Kconfig
> 
> which for some distros is over 20 per release and the end user wouldn't
> have a cat in hells chance of knowing which to pick.

I wasn't include arch-specific options in the "minimal distro config"
stuff.  That doesn't seem minimal to me.  I was thinking more along the
lines of "distro X needs CGROUPS, SELINUX, HOTPLUG, DEVTMPFS, namespace
stuff".  Stuff that they need that is basically architecture
independent that the distro userspace needs.

Having the distro provide files that select architecture specific
options and variations of that really doesn't seem any better than what
most of them do already, which is just ship the whole damn config file
in /boot (or some other location).

> For the end user case you need the distro to plonk the right file in the
> right place and be done with it, once they do that the rest is
> bikeshedding a ten line Makefile rule.

If people want the distros to plonk some architecture+distro specific
minimal config file down as part of the packaging, I guess that's a
thing that could be done.  I'd honestly wonder if maintaining X number
of those in the packaging is something the distro maintainers would
really like to do, but one can always hope.

josh


-- 
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/20120719173800.ge8...@zod.bos.redhat.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Alan Cox]

> > kconfig already spits out warnings for symbols being selected that
> > don't exist.
> 
> We can make these even bigger :-)   Add lots of stars (*) around them!

Make oldconfig already handles this just fine

Alan


-- 
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/20120719184118.03cb3...@pyramind.ukuu.org.uk

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

[Borislav Petkov]

On Thu, Jul 19, 2012 at 01:02:46PM -0400, Steven Rostedt wrote:
> This is why I created the make-min-config in ktest. It keeps on
> disabling configs to see what the machine needs to boot (and optionally
> run some test), and what configs it can disable. It does not touch the
> multi options though.
> 
> It creates two configs. One that has the configs that it can't turn off
> (still enabled with a make allnoconfig, or selected by something that it
> must have), and a config that just has the configs that 'if I disable
> this, the box doesn't boot'.
> 
> Here's an example:
> 
> For my min-config files with the configs that couldn't be turned off:
> 
> $ wc -l config-min*
>   117 config-min
>   139 config-min-net
> 
> The config-min will get the box to boot (no network). The -net, adds
> enough to ssh to the box.
> 
> $ wc -l config-skip*
>  11 config-skip
>  14 config-skip-net
> 
> The above are the configs that ktest found if it disabled, would not
> boot (or ssh).
> 
> $ cat config-skip-net
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SATA_AHCI=y
> CONFIG_E1000=y
> CONFIG_QUOTA=y
> CONFIG_ATA=y
> CONFIG_UNIX=y
> CONFIG_INET=y
> CONFIG_DEVTMPFS=y
> CONFIG_EXT4_FS=y
> CONFIG_DEVTMPFS_MOUNT=y
> CONFIG_SERIAL_8250=y
> CONFIG_BLK_DEV_SD=y
> CONFIG_NET=y
> CONFIG_NETDEVICES=y
> 
> I can pass the above to a allnoconfig, and the box will boot and allow
> ssh. Note, the reason for the serial config, is that this ktest run uses
> a serial port to see if the box booted. If the serial isn't there, then
> it thinks it failed.

I agree with all this and you've explained this to me live already so
you're preaching to the choir.

But it would be a lot faster/easier if users can select, let's call'em
"profiles" which are not mutually exclusive and can speed up the
configuration process. They can either be distro-specific or generic,
selecting certain features you need.

So configuring your kernel would be like shopping without paying too
much attention to details. Let's look into the head of a person doing a
config like that and read some of her thoughts :):

"Hm, ok, this new configurator is cool, a lot faster I gotta say... So,
what do I need, ah, yes, it is an AMD laptop so from vendors I select
AMD, then I probably need ext4, then I'd like to do packet filtering
so I should enable iptables.. Oh, I'd like to do tracing too so let's
enable tracing and trust Steven with the options he's added by default,
then I need ahci, I'd also like to do encrypted partitions so I'll
enable device mapper with crypto... "

So all those things could be selectable from that profiles menu without
having to go through the gazillion of little suboptions and having to
read help (which is sometimes completely helpless) and figure out do I
need it or not.

And this would simplify configuration a lot. IMHO, anyway.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551


-- 
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/20120719173415.ge23...@aftab.osrc.amd.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Steven Rostedt]

On Thu, 2012-07-19 at 13:19 -0400, Josh Boyer wrote:

> > What about older kernels? Say you installed Fedora 18 with an older
> > kernel that doesn't know what to select? Having the distro tell the
> > kernel what it needs seems to me the easiest for the 99% case.
> 
> How is the above not telling the kernel what it needs?  I'm confused how
> the location of such a file makes it's functionality and usefulness
> differ...  Quite possible I missed what you meant originally, but it
> sounds like we're talking about the same thing?

The point is, the user wont have to think "What distro am I running? and
what version am I running?". I don't even know what version of the disto
I'm currently running (Debian testing).

The point is, the current running distro supplies what is needed from
the kernel in order to work properly. The user does not need to 'select'
it. They would only have to select a 'add my distro min configs'.

A developer working with a user could just say, "select disto config"
without needing to know what distro the user has.

What happens if someone does a yum update, and the kernel requirement
changes slightly. The yum update should update
this /usr/share/Linux/Kconfig. But it's still set at Fedora X. The
kernel can not be updated for these slight changes.

> 
> Also, I'm not very convinced the 99% are going to be wanting to install
> shiny new versions of a distro with a kernel older than what the distro
> ships with.  I could be very wrong, but it seems like in-general the
> whole premise of this RFC was geared towards using new kernels on
> distros.

There are times when the update breaks something. A user may backport to
an older kernel where their Gizmo worked. I've done this to get webcams
working. I know I'm not the 99%, but the rational for my operation was a
99% thing to do: Crap, I upgraded my kernel and now my webcam doesn't
work. Oh well, download an older version and boot that one.

> 
> > Also, if something isn't supported by the older kernel, it would warn
> > the user about it. That way the user can be told that their older kernel
> > won't work with this version of the distro. And there wont be as many
> > surprises. If the user is told "your init wont work with this kernel"
> > before they compile it, then they shouldn't complain if they decide to
> > install this older kernel and their box doesn't boot.
> 
> kconfig already spits out warnings for symbols being selected that
> don't exist.

We can make these even bigger :-)   Add lots of stars (*) around them!

-- Steve



-- 
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/1342719222.12353.58.ca...@gandalf.stny.rr.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Alan Cox]

> Well, yes.  I was thinking it would be more like:
> 
> distro/Kconfig.fedora
>   menuconfig FEDORA
>   if FEDORA
>   config FEDORA_16
>  select WHATEVER
>   config FEDORA_17

Nope you need

distro/everyarchtheyship/everykernelvarianttkeyship(smp,largemem,arm
boards)/Kconfig

which for some distros is over 20 per release and the end user wouldn't
have a cat in hells chance of knowing which to pick.

For the end user case you need the distro to plonk the right file in the
right place and be done with it, once they do that the rest is
bikeshedding a ten line Makefile rule.

Alan


-- 
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/20120719183047.69de3...@pyramind.ukuu.org.uk

Re: [RFC] Simplifying kernel configuration for distro issues

[Josh Boyer]

On Thu, Jul 19, 2012 at 12:08:08PM -0400, Steven Rostedt wrote:
> On Thu, 2012-07-19 at 11:45 -0400, Josh Boyer wrote:
> > Of course the kbuild system would need to verify that the selects exist,
> > > and perhaps warn if they do not. But the nice thing about this is that
> > > you would get the minconfig for the system you are running. When the
> > > system is updated to a new version, the minconfig would be updated too.
> > > The list of selects would not have to live in the kernel, nor would the
> > > kernel need to maintain the list for N+1 different distributions.
> > 
> > Is there a reason you don't want distro maintainers to maintain these
> > files in the upstream git tree?  (You said "the kernel need to
> > maintain", but I would expect the distro maintainers to be doing that
> > work.)
> > 
> > I think it would actually be beneficial to maintain them upstream
> > instead of in distro kernel packaging.  You'd be able to track the
> > history of changes with git.  You would see for a given kernel
> > version what options are set for each distro (e.g. F17 can support
> > NEW_FOO_THING but F16 userspace can't so it doesn't select that).
> > Perhaps most importantly, it provides a consolidated view of what
> > options various distros are setting and allows the distro maintainers to
> > easily do comparisons.
> 
> Then we'll have a list of options in each kernel:
> 
>  Fedora 16
>  Fedora 17
>  Fedora 18
>  [...]
>  Debian x
>  Debian x+1
>  Debian x+2
>  [...]
>  Ubuntu y
>  Ubuntu y+1
>  [...]

Well, yes.  I was thinking it would be more like:

distro/Kconfig.fedora
menuconfig FEDORA
if FEDORA
config FEDORA_16
   select WHATEVER
config FEDORA_17
...

distro/Kconfig.debian
menuconfig DEBIAN
if DEBIAN
config DEBIAN_X
...

etc.

Not one giant distro file with a bunch of varying distros doing a bunch
of selects.  But in general, yes there would be options for each
supported distro release.

> What about older kernels? Say you installed Fedora 18 with an older
> kernel that doesn't know what to select? Having the distro tell the
> kernel what it needs seems to me the easiest for the 99% case.

How is the above not telling the kernel what it needs?  I'm confused how
the location of such a file makes it's functionality and usefulness
differ...  Quite possible I missed what you meant originally, but it
sounds like we're talking about the same thing?

Also, I'm not very convinced the 99% are going to be wanting to install
shiny new versions of a distro with a kernel older than what the distro
ships with.  I could be very wrong, but it seems like in-general the
whole premise of this RFC was geared towards using new kernels on
distros.

> Also, if something isn't supported by the older kernel, it would warn
> the user about it. That way the user can be told that their older kernel
> won't work with this version of the distro. And there wont be as many
> surprises. If the user is told "your init wont work with this kernel"
> before they compile it, then they shouldn't complain if they decide to
> install this older kernel and their box doesn't boot.

kconfig already spits out warnings for symbols being selected that
don't exist.

josh


-- 
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/20120719171918.gd8...@zod.bos.redhat.com

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

[Linus Torvalds]

On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov  wrote:
>
> Seriously, this helps only in the cases where the stuff the distro
> actually needs is in modules. So, there probably are obscure situations
> where you need to enable stuff which is bool and not M.

Sadly, not obscure at all.

Most of the *drivers* are modules, but most of the "distro config"
options are indeed booleans (or, if tristate, =y).

Even driver-wise, there are some things that are often =y, even though
you generally don't want them. PCMCIA? Not even *laptops* have that
shit any more, but having built-in cardbus support almost certainly
helps in a distro kernel for booting of certain odder cases.

Xen support? Odd partition tables? All the different AGP versions?
Many of us couldn't care less, but again, it makes sense in the actual
distro kernel, even if it does *not* necessarily make sense in a
personalized one.

So doing "make allmodconfig" is certainly a workable thing (modulo the
modules that you need for stuff you hadn't happened to use), but it's
not wonderful.

I also hate having to enable support for modules. A non-modular build
is quicker to build and avoids some security issues. Some drivers
don't work well built-in (they load firmware etc too early), but imho
it's worth doing if you can, and it's something we should make easy
for people to do because of the security side (of course, per-build
randomly generated keys and signed modules with the keys deleted after
the build would be reasonably equivalent from a security standpoint,
but we're not there yet).

  Linus


-- 
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/CA+55aFxX41pGnHcc17A=vbnw+03lewkwatizwobbpgd9ap3...@mail.gmail.com

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

[Steven Rostedt]

On Thu, 2012-07-19 at 18:48 +0200, Borislav Petkov wrote:

> > Also, if you are building on another box than what the kernel is for,
> > you can go to that box and run 'lsmod > /tmp/lsmod'. Copy that file to
> > the build machine (into /tmp/lsmod), and then run
> > 'make LSMOD=/tmp/lsmod localmodconfig', and this will remove the modules
> > not used by the target box.
> 
> Seriously, this helps only in the cases where the stuff the distro
> actually needs is in modules. So, there probably are obscure situations
> where you need to enable stuff which is bool and not M. Hopefully those
> cases are seldom enough so thanks for this, I'll try that the next time.
> 

This is why I created the make-min-config in ktest. It keeps on
disabling configs to see what the machine needs to boot (and optionally
run some test), and what configs it can disable. It does not touch the
multi options though.

It creates two configs. One that has the configs that it can't turn off
(still enabled with a make allnoconfig, or selected by something that it
must have), and a config that just has the configs that 'if I disable
this, the box doesn't boot'.

Here's an example:

For my min-config files with the configs that couldn't be turned off:

$ wc -l config-min*
  117 config-min
  139 config-min-net

The config-min will get the box to boot (no network). The -net, adds
enough to ssh to the box.

$ wc -l config-skip*
 11 config-skip
 14 config-skip-net

The above are the configs that ktest found if it disabled, would not
boot (or ssh).

$ cat config-skip-net
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SATA_AHCI=y
CONFIG_E1000=y
CONFIG_QUOTA=y
CONFIG_ATA=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_DEVTMPFS=y
CONFIG_EXT4_FS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_SERIAL_8250=y
CONFIG_BLK_DEV_SD=y
CONFIG_NET=y
CONFIG_NETDEVICES=y

I can pass the above to a allnoconfig, and the box will boot and allow
ssh. Note, the reason for the serial config, is that this ktest run uses
a serial port to see if the box booted. If the serial isn't there, then
it thinks it failed.

-- Steve



-- 
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/1342717366.12353.48.ca...@gandalf.stny.rr.com

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

[Borislav Petkov]

On Thu, Jul 19, 2012 at 10:42:17AM -0400, Steven Rostedt wrote:
> On Sat, Jul 14, 2012 at 07:48:27PM +0200, Borislav Petkov wrote:
> > 
> > Let's have an example: when I have to build upstream on a distro here,
> > I take the distro config and use it despite that it takes a long time
> > to build since everything is module - it is still better for me to
> > wait that one time instead of doing a dozen of trial and errors after
> > forgetting a config option each time.
> 
> This is where 'make localmodconfig' does help. It can remove a lot of
> modules for you. And I just recently fixed a bug in the tool that it now
> removes even more modules (The fix is in linux-next).

Even more modules? When is enough, enough? :-)

> Also, if you are building on another box than what the kernel is for,
> you can go to that box and run 'lsmod > /tmp/lsmod'. Copy that file to
> the build machine (into /tmp/lsmod), and then run
> 'make LSMOD=/tmp/lsmod localmodconfig', and this will remove the modules
> not used by the target box.

Seriously, this helps only in the cases where the stuff the distro
actually needs is in modules. So, there probably are obscure situations
where you need to enable stuff which is bool and not M. Hopefully those
cases are seldom enough so thanks for this, I'll try that the next time.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551


-- 
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/20120719164807.gd23...@aftab.osrc.amd.com

[bts-link] source package src:linux

[bts-link-upstream]

#
# bts-link upstream status pull for source package src:linux
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#

user bts-link-upstr...@lists.alioth.debian.org

# remote status report for #680707 (http://bugs.debian.org/680707)
# Bug title: Asus P5NSLI: lockup on resume from suspend
#  * http://bugzilla.kernel.org/show_bug.cgi?id=43641
#  * remote status changed: RESOLVED -> CLOSED
usertags 680707 - status-RESOLVED
usertags 680707 + status-CLOSED

thanks


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120719164044.3284.50572.btsl...@busoni.debian.org

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

[Michal Marek]

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

But for the few options Linus proposed (TMPFS, TMPFS_POSIX_*,
DEVTMPFS(_MOUNT)), the amount of additional dependencies is reasonable.
For something more advanced like 'build me a kernel for a laptop with
$VENDOR hardware', we would need a better dependency solver, indeed.

Michal


-- 
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/50082f44.7070...@suse.cz

Re: [RFC] Simplifying kernel configuration for distro issues

[Steven Rostedt]

On Thu, 2012-07-19 at 08:43 -0700, Linus Torvalds wrote:
> On Thu, Jul 19, 2012 at 8:26 AM, Steven Rostedt  wrote:
> >
> > Side note, and this is for the 1%. If you want a true minconfig for your
> > system, ktest can do that for you.
> 
> Try it, it's actually much harder than it seems. Like allmodconfig, it
> handles the minimum hardware well, but it tends to handle the subtle
> issues really badly.
> 
> Many config options cause *very* subtle failures that are almost
> impossible to see. Like firewalls not loading correctly (and leaving
> the machine completely open), or just stuff that you didn't happen to
> test (USB sticks, printers, certain programs) not working. Not having
> the right audit options will make things still "work", but you'll get
> warnings at bootup, and who knows what that causes etc etc.
> 
> These kinds of things are exactly why I'd like to have a distro config.

This is why it was more of a side note, and for the 1%. If there's
things you have tests for, to confirm that they work, you could add
those to the TEST option, and the config generated will guarantee to fix
them.

But as you stated, there's lots of subtle things that can go wrong. I
was just posting this as a plug for ktest ;-)

For what you want, I think having the distro supply
a /usr/share/Linux/Kconfig that the linux build system can use would be
very helpful.

-- Steve



-- 
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/1342714322.12353.36.ca...@gandalf.stny.rr.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Steven Rostedt]

On Thu, 2012-07-19 at 11:45 -0400, Josh Boyer wrote:
> Of course the kbuild system would need to verify that the selects exist,
> > and perhaps warn if they do not. But the nice thing about this is that
> > you would get the minconfig for the system you are running. When the
> > system is updated to a new version, the minconfig would be updated too.
> > The list of selects would not have to live in the kernel, nor would the
> > kernel need to maintain the list for N+1 different distributions.
> 
> Is there a reason you don't want distro maintainers to maintain these
> files in the upstream git tree?  (You said "the kernel need to
> maintain", but I would expect the distro maintainers to be doing that
> work.)
> 
> I think it would actually be beneficial to maintain them upstream
> instead of in distro kernel packaging.  You'd be able to track the
> history of changes with git.  You would see for a given kernel
> version what options are set for each distro (e.g. F17 can support
> NEW_FOO_THING but F16 userspace can't so it doesn't select that).
> Perhaps most importantly, it provides a consolidated view of what
> options various distros are setting and allows the distro maintainers to
> easily do comparisons.

Then we'll have a list of options in each kernel:

 Fedora 16
 Fedora 17
 Fedora 18
 [...]
 Debian x
 Debian x+1
 Debian x+2
 [...]
 Ubuntu y
 Ubuntu y+1
 [...]

What about older kernels? Say you installed Fedora 18 with an older
kernel that doesn't know what to select? Having the distro tell the
kernel what it needs seems to me the easiest for the 99% case.

Also, if something isn't supported by the older kernel, it would warn
the user about it. That way the user can be told that their older kernel
won't work with this version of the distro. And there wont be as many
surprises. If the user is told "your init wont work with this kernel"
before they compile it, then they shouldn't complain if they decide to
install this older kernel and their box doesn't boot.

-- Steve



-- 
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/1342714088.12353.33.ca...@gandalf.stny.rr.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Josh Boyer]

On Thu, Jul 19, 2012 at 11:26:18AM -0400, Steven Rostedt wrote:
> On Fri, Jul 13, 2012 at 02:17:30PM -0700, Linus Torvalds wrote:
> > 
> > The *two* requirements (and they're really the same theme) I
> > personally think we should have for this are
> > 
> >  -  I think every single "select" for these things should come with a
> > comment about what it is about and why the distro needs it (to show
> > there was some thought involved and not just a blind "took it from the
> > distro config")
> 
> What about expanding on Alan's idea. I'm guessing that 99% of the users
> build the kernel for the box that they are running. If this is the case,
> perhaps we can get the distros to add a:
> 
>   /usr/share/Linux/Kconfig
> 
> And this Kconfig would have something like:
> 
> bool "Distro X config"
>  select A
>  select B
>  select C
>  [...]
> 
> Perhaps with a comment for each select. Or have the comments in the help
> section.
> 
> Then have the kernel kbuild system check if this file exists and include
> it.
> 
> Of course the kbuild system would need to verify that the selects exist,
> and perhaps warn if they do not. But the nice thing about this is that
> you would get the minconfig for the system you are running. When the
> system is updated to a new version, the minconfig would be updated too.
> The list of selects would not have to live in the kernel, nor would the
> kernel need to maintain the list for N+1 different distributions.

Is there a reason you don't want distro maintainers to maintain these
files in the upstream git tree?  (You said "the kernel need to
maintain", but I would expect the distro maintainers to be doing that
work.)

I think it would actually be beneficial to maintain them upstream
instead of in distro kernel packaging.  You'd be able to track the
history of changes with git.  You would see for a given kernel
version what options are set for each distro (e.g. F17 can support
NEW_FOO_THING but F16 userspace can't so it doesn't select that).
Perhaps most importantly, it provides a consolidated view of what
options various distros are setting and allows the distro maintainers to
easily do comparisons.

josh


-- 
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/20120719154521.gc8...@zod.bos.redhat.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Linus Torvalds]

On Thu, Jul 19, 2012 at 8:26 AM, Steven Rostedt  wrote:
>
> Side note, and this is for the 1%. If you want a true minconfig for your
> system, ktest can do that for you.

Try it, it's actually much harder than it seems. Like allmodconfig, it
handles the minimum hardware well, but it tends to handle the subtle
issues really badly.

Many config options cause *very* subtle failures that are almost
impossible to see. Like firewalls not loading correctly (and leaving
the machine completely open), or just stuff that you didn't happen to
test (USB sticks, printers, certain programs) not working. Not having
the right audit options will make things still "work", but you'll get
warnings at bootup, and who knows what that causes etc etc.

These kinds of things are exactly why I'd like to have a distro config.

   Linus


-- 
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/CA+55aFzTq2CNxPa3X+N=bifgifrmwbewqjzlvfafdyswxqc...@mail.gmail.com

Re: [RFC] Simplifying kernel configuration for distro issues

[Steven Rostedt]

On Fri, Jul 13, 2012 at 02:17:30PM -0700, Linus Torvalds wrote:
> 
> The *two* requirements (and they're really the same theme) I
> personally think we should have for this are
> 
>  -  I think every single "select" for these things should come with a
> comment about what it is about and why the distro needs it (to show
> there was some thought involved and not just a blind "took it from the
> distro config")

What about expanding on Alan's idea. I'm guessing that 99% of the users
build the kernel for the box that they are running. If this is the case,
perhaps we can get the distros to add a:

  /usr/share/Linux/Kconfig

And this Kconfig would have something like:

bool "Distro X config"
 select A
 select B
 select C
 [...]

Perhaps with a comment for each select. Or have the comments in the help
section.

Then have the kernel kbuild system check if this file exists and include
it.

Of course the kbuild system would need to verify that the selects exist,
and perhaps warn if they do not. But the nice thing about this is that
you would get the minconfig for the system you are running. When the
system is updated to a new version, the minconfig would be updated too.
The list of selects would not have to live in the kernel, nor would the
kernel need to maintain the list for N+1 different distributions.


> 
>  - It should be about *minimal* settings. I'd rather have too few
> things and the occasional complaint about "oh, it didn't work because
> it missed XYZ" than have it grow to contain all the options just
> because somebody decided to just add random things until things
> worked.

Side note, and this is for the 1%. If you want a true minconfig for your
system, ktest can do that for you. You can set it up to run a test to
create a minimum config that will boot (and optionally run some test you
specify). It turns off configs in order of importance (chooses those
that select a lot, or are depended on most, first), and sees if it can
boot without the config. The end result can be rather a very small set
of configs.

See tools/testing/ktest/examples/include/min-config.conf for more
details.

-- Steve

> 
> Other than that, even if it only gets you *closer* to a kernel that
> works with that distro, I think it doesn't have to be all that
> perfect. Because the alternative is what we have now.
> 
>Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


-- 
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/20120719152618.gd16...@home.goodmis.org

Bug#682007: linux-image-3.2.0-0.bpo.2-amd64: NULL pointer dereference in __fscache_read_or_alloc_pages

[Ben Hutchings]

On Thu, Jul 19, 2012 at 09:03:26AM -0500, Brian Kroth wrote:
> Ben Hutchings  2012-07-19 13:32:
> >On Thu, 2012-07-19 at 13:37 +0200, Bastian Blank wrote:
> >>On Wed, Jul 18, 2012 at 11:16:33AM -0500, Brian Kroth wrote:
> >>> ** Tainted: PO (4097)
> >>>  * Proprietary module has been loaded.
> >>>  * Out-of-tree module has been loaded.
> >>
> >>> 21:04:00 kefka [187206.183487] Pid: 20810, comm: MATLAB Tainted: P
> >>> O 3.2.0-0.bpo.2-amd64 #1
> >>
> >>We don't support proprietary stuff. Please remove and try again.
> >
> >To be clear, Bastian is referring to the proprietary kernel module
> >(nvidia).
> 
> Ok.  The driver is required for some third party engineering
> software we have to run, but I can rig a spare machine to run some
> of these other jobs without it for a bit.  I'll report back if/when
> I have a new panic.
>
> I will note though that the driver comes from the debian provided
> packages (albeit from backports instead of stable).

I realise that, but it's not part of Debian proper and none of us
signed up to debug drivers that don't come with source.

Ben.

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


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120719152127.gy1...@decadent.org.uk

Bug#682116: linux-image-3.2.0-0.bpo.2-amd64: NULL pointer dereference related to nfs/cachefilesd

[Raoul Bhatia [IPAX]]

Package: src:linux
Version: 3.2.20-1~bpo60+1
Severity: important


I'm seeing an error much like the one reported as bug #682007.

The setup seems quite similar:
1. NFS server exports an nfsv4 share:
   /data/export
192.168.100.0/24(rw,async,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=1000,anonuid=65534,anongid=65534)
2. the client mounts the share:
   192.168.100.200:/data/export on /data/www type nfs 
(rw,nosuid,nodev,nodiratime,relatime,timeo=15,fsc,vers=4,addr=192.168.100.200,clientaddr=192.168.100.109)
3. we use cachefilesd to increase the performance. The cache resides on a 
dedicated lvm partition formatted with xfs:
   Filesystem   Size  Used Avail Use% Mounted on
   /dev/mapper/vg4-nfscache  20G   14G  6.4G  69% /data/nfscache



This is reproducable using "grep -r abc *" inside a directory with
   9541 files (no sym- or hardlinks, no block or character special files) in
   1524 directories
(PHP MODX installation)


The full output from /var/log/syslog :

Jul 19 16:40:31 wc01 kernel: [44550.980065] 
Jul 19 16:40:31 wc01 kernel: [44550.984601] CacheFiles: Error: Overlong wait 
for old active object to go away
Jul 19 16:40:31 wc01 kernel: [44550.989460] object: OBJ1c3d6
Jul 19 16:40:31 wc01 kernel: [44550.993923] objstate=OBJECT_LOOKING_UP fl=0 
wbusy=2 ev=0[7b]
Jul 19 16:40:31 wc01 kernel: [44550.998330] ops=0 inp=0 exc=0
Jul 19 16:40:31 wc01 kernel: [44551.002598] parent=8802356b9c00
Jul 19 16:40:32 wc01 kernel: [44551.006733] cookie=8800a99132b8 
[pr=880435456588 nd=88020b3f7040 fl=7]
Jul 19 16:40:32 wc01 kernel: [44551.010845] key=[16] 
'01000101e8033484d6633aa75132'
Jul 19 16:40:32 wc01 kernel: [44551.014987] xobject: OBJ1c3d5
Jul 19 16:40:32 wc01 kernel: [44551.018841] xobjstate=OBJECT_RECYCLING fl=0 
wbusy=2 ev=20[3]
Jul 19 16:40:32 wc01 kernel: [44551.022711] xops=0 inp=0 exc=0
Jul 19 16:40:32 wc01 kernel: [44551.026476] xparent=8802356b9c00
Jul 19 16:40:32 wc01 kernel: [44551.030137] xcookie=NULL
Jul 19 16:40:32 wc01 kernel: [44551.200193] BUG: unable to handle kernel NULL 
pointer dereference at 0040
Jul 19 16:40:32 wc01 kernel: [44551.201859] [kworke] unexpected submission 
OPa7bd5 [OBJ1c4e7 OBJECT_LOOKING_UP]
Jul 19 16:40:32 wc01 kernel: [44551.201917] [kworke] objstate=OBJECT_LOOKING_UP 
[OBJECT_LOOKING_UP]
Jul 19 16:40:32 wc01 kernel: [44551.201926] [kworke] objflags=2
Jul 19 16:40:32 wc01 kernel: [44551.201928] [kworke] objevent=0 
[fffb]
Jul 19 16:40:32 wc01 kernel: [44551.201930] [kworke] ops=0 inp=0 exc=0
Jul 19 16:40:32 wc01 kernel: [44551.201936] Pid: 553, comm: kworker/7:2 
Tainted: G  D  3.2.0-0.bpo.2-amd64 #1
Jul 19 16:40:32 wc01 kernel: [44551.201938] Call Trace:
Jul 19 16:40:32 wc01 kernel: [44551.202150]  [] ? 
fscache_submit_op+0x3ab/0x3fc [fscache]
Jul 19 16:40:32 wc01 kernel: [44551.202162]  [] ? 
__fscache_write_page+0x1e1/0x290 [fscache]
Jul 19 16:40:32 wc01 kernel: [44551.202183]  [] ? 
rpc_put_task+0xa/0xa [sunrpc]
Jul 19 16:40:32 wc01 kernel: [44551.202217]  [] ? 
__nfs_readpage_to_fscache+0x4e/0xce [nfs]
Jul 19 16:40:32 wc01 kernel: [44551.202305]  [] ? 
nfs_readpage_release+0x2e/0x87 [nfs]
Jul 19 16:40:32 wc01 kernel: [44551.202319]  [] ? 
nfs_readpage_release_full+0x31/0x48 [nfs]
Jul 19 16:40:32 wc01 kernel: [44551.202328]  [] ? 
process_one_work+0x1cc/0x2ea
Jul 19 16:40:32 wc01 kernel: [44551.202333]  [] ? 
worker_thread+0x12d/0x247
Jul 19 16:40:32 wc01 kernel: [44551.202337]  [] ? 
process_one_work+0x2ea/0x2ea
Jul 19 16:40:32 wc01 kernel: [44551.202341]  [] ? 
process_one_work+0x2ea/0x2ea
Jul 19 16:40:32 wc01 kernel: [44551.202347]  [] ? 
kthread+0x7a/0x82
Jul 19 16:40:32 wc01 kernel: [44551.202355]  [] ? 
kernel_thread_helper+0x4/0x10
Jul 19 16:40:32 wc01 kernel: [44551.202358]  [] ? 
kthread_worker_fn+0x147/0x147
Jul 19 16:40:32 wc01 kernel: [44551.202362]  [] ? 
gs_change+0x13/0x13
Jul 19 16:40:32 wc01 kernel: [44551.234197] [kworke] preemptive burial: OBJd29e 
[OBJECT_RECYCLING] 88041ce02440
Jul 19 16:40:32 wc01 kernel: [44551.204008] IP: [] 
__fscache_read_or_alloc_pages+0x194/0x262 [fscache]
Jul 19 16:40:32 wc01 kernel: [44551.204008] PGD 37ef32067 PUD 384533067 PMD 0 
Jul 19 16:40:32 wc01 kernel: [44551.204008] Oops:  [#3] SMP 
Jul 19 16:40:32 wc01 kernel: [44551.204008] CPU 1 
Jul 19 16:40:32 wc01 kernel: [44551.204008] Modules linked in: xt_TCPMSS 
act_police cls_flow cls_fw cls_u32 sch_htb sch_hfsc sch_ingress sch_sfq bridge 
xt_time xt_connlimit xt_realm xt
_addrtype iptable_raw xt_comment xt_recent xt_policy ipt_ULOG ipt_REJECT 
ipt_REDIRECT ipt_NETMAP ipt_MASQUERADE ipt_ECN ipt_ecn ipt_CLUSTERIP ipt_ah 
nf_nat_tftp nf_nat_snmp_basic nf_co
nntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 
nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane 
nf_conntrack_tftp nf_conntrack_sip nf_
conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre 
nf_conntrack_netlink nf_conntrack

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

[Steven Rostedt]

On Sat, Jul 14, 2012 at 07:48:27PM +0200, Borislav Petkov wrote:
> 
> Let's have an example: when I have to build upstream on a distro here,
> I take the distro config and use it despite that it takes a long time
> to build since everything is module - it is still better for me to
> wait that one time instead of doing a dozen of trial and errors after
> forgetting a config option each time.

This is where 'make localmodconfig' does help. It can remove a lot of
modules for you. And I just recently fixed a bug in the tool that it now
removes even more modules (The fix is in linux-next).

Also, if you are building on another box than what the kernel is for,
you can go to that box and run 'lsmod > /tmp/lsmod'. Copy that file to
the build machine (into /tmp/lsmod), and then run
'make LSMOD=/tmp/lsmod localmodconfig', and this will remove the modules
not used by the target box.

-- Steve


-- 
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/20120719144217.gc16...@home.goodmis.org

Bug#682007: linux-image-3.2.0-0.bpo.2-amd64: NULL pointer dereference in __fscache_read_or_alloc_pages

[Brian Kroth]

Ben Hutchings  2012-07-19 13:32:

On Thu, 2012-07-19 at 13:37 +0200, Bastian Blank wrote:

On Wed, Jul 18, 2012 at 11:16:33AM -0500, Brian Kroth wrote:
> ** Tainted: PO (4097)
>  * Proprietary module has been loaded.
>  * Out-of-tree module has been loaded.

> 21:04:00 kefka [187206.183487] Pid: 20810, comm: MATLAB Tainted: P
> O 3.2.0-0.bpo.2-amd64 #1

We don't support proprietary stuff. Please remove and try again.


To be clear, Bastian is referring to the proprietary kernel module
(nvidia).


Ok.  The driver is required for some third party engineering software we 
have to run, but I can rig a spare machine to run some of these other 
jobs without it for a bit.  I'll report back if/when I have a new panic.


I will note though that the driver comes from the debian provided 
packages (albeit from backports instead of stable).


Thanks,
Brian


signature.asc
Description: Digital signature

Bug#682007: linux-image-3.2.0-0.bpo.2-amd64: NULL pointer dereference in __fscache_read_or_alloc_pages

[Ben Hutchings]

On Thu, 2012-07-19 at 13:37 +0200, Bastian Blank wrote:
> On Wed, Jul 18, 2012 at 11:16:33AM -0500, Brian Kroth wrote:
> > ** Tainted: PO (4097)
> >  * Proprietary module has been loaded.
> >  * Out-of-tree module has been loaded.
> 
> > 21:04:00 kefka [187206.183487] Pid: 20810, comm: MATLAB Tainted: P
> > O 3.2.0-0.bpo.2-amd64 #1
> 
> We don't support proprietary stuff. Please remove and try again.

To be clear, Bastian is referring to the proprietary kernel module
(nvidia).

Ben.

-- 
Ben Hutchings
DNRC Motto:  I can please only one person per day.
Today is not your day.  Tomorrow isn't looking good either.


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

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

[Ben Hutchings]

On Thu, 2012-07-19 at 11:12 +0200, Lesław Kopeć wrote:
> On 07/18/2012 01:25 AM, Jonathan Nieder wrote:
> > Anders Boström wrote:
> > 
> >> Starting with 3.2.17-1, the CPU load accounting is broken when the
> >> computer is idle. The CPU load is reported as >0.50 when
> >> idle. 3.2.16-1 don't suffer from this problem.
> >>
> >> Suspected patch is the upstream patch
> >> "sched: Fix nohz load accounting -- again!"
> >> commit 5e2d50da11f0e6ec3ce8fe658d7c83b0b4346c68 to 3.2 and
> >> originating from c308b56b5398779cd3da0f62ab26b0453494c3d4 .
> > 
> > Please test the attached patch against a 3.2.y kernel, for example
> > following the instructions below:
> 
> Good news everyone. I have tested kernel 3.2.21 and the attached patch
> (based on 5167e8d I presume) seems to be fixing all the load average
> oddities. I've compiled following kernels:
> 
> * 3.2.21-hz   (CONFIG_NO_HZ=n)
> * 3.2.21-no-hz(CONFIG_NO_HZ=y)
> * 3.2.21-no-hz-5167e8d(CONFIG_NO_HZ=y) + attached patch
> 
> The load reported by 3.2.21-hz and 3.2.21-no-hz-5167e8d is exactly the
> same under different CPU usage. Without the patch the tickless kernel
> tends to show lower load values than what you would expect.
> 
> I can't say much for the case when load is too high on an idle machine,
> because I haven't been able to reproduce the problem in the first place.
> 
> To summarize: the bug is present in unpatched kernel and fixed by
> applying the attached patch. No nasty side effects noticed.

This is in the review queue for Linux 3.2.24.  I'm hesistant to apply it
until it's been through the stable review process (probably early next
week).  But, if there's no objection to it there, it will end up in
Debian pretty soon.

Ben.

-- 
Ben Hutchings
DNRC Motto:  I can please only one person per day.
Today is not your day.  Tomorrow isn't looking good either.


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

Bug#673107: kirkwood: TCP checksum errors when using MTU 9000

[Ben Hutchings]

On Thu, 2012-07-19 at 10:43 +0200, Damien Martins wrote:
> Same behaviour :/
> 
> dmesg shows :
[...]

MTU of 9000 requires 4 contiguous pages of memory for each packet.  On a
machine with only 256 MB of memory, that tends to be hard to find.  This
is not a bug.

Are the checksum errors gone?

Ben.

-- 
Ben Hutchings
DNRC Motto:  I can please only one person per day.
Today is not your day.  Tomorrow isn't looking good either.


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

Bug#682007: linux-image-3.2.0-0.bpo.2-amd64: NULL pointer dereference in __fscache_read_or_alloc_pages

[Bastian Blank]

On Wed, Jul 18, 2012 at 11:16:33AM -0500, Brian Kroth wrote:
> ** Tainted: PO (4097)
>  * Proprietary module has been loaded.
>  * Out-of-tree module has been loaded.

> 21:04:00 kefka [187206.183487] Pid: 20810, comm: MATLAB Tainted: P
> O 3.2.0-0.bpo.2-amd64 #1

We don't support proprietary stuff. Please remove and try again.


-- 
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/20120719113721.ga31...@wavehammer.waldi.eu.org

Bug#682063: marked as done (firmware-iwlwifi: Version 0.36 breaks firmware loading)

[Debian Bug Tracking System]

Your message dated Thu, 19 Jul 2012 12:08:01 +0100
with message-id <1342696081.11373.106.ca...@deadeye.wl.decadent.org.uk>
and subject line Re: Bug#682063: firmware-iwlwifi: Version 0.36 breaks firmware 
loading
has caused the Debian Bug report #682063,
regarding firmware-iwlwifi: Version 0.36 breaks firmware loading
to be marked as done.

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

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


-- 
682063: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682063
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: firmware-iwlwifi
Version: 0.36
Severity: important

Hello,

With the version 0.36 of firmware-iwlwifi fails to load the iwlagn module with 
the error:
Jul 19 08:39:23 pomegues kernel: [ 1241.775811] iwlagn :01:00.0: request 
for firmware file 'iwlwifi-6000g2b-5.ucode' failed.
Jul 19 08:39:23 pomegues kernel: [ 1241.779455] iwlagn :01:00.0: request 
for firmware file 'iwlwifi-6000g2b-4.ucode' failed.

Rollback to 0.35 fixes the problem.

Thanks for your work,
Sylvestre


PS: modinfo iwlagn gives:
# modinfo iwlagn
filename:   
/lib/modules/3.1.0-1-amd64/kernel/drivers/net/wireless/iwlwifi/iwlagn.ko
license:GPL
author: Copyright(c) 2003-2011 Intel Corporation 
version:in-tree:
description:Intel(R) Wireless WiFi Link AGN driver for Linux
firmware:   iwlwifi-5150-2.ucode
firmware:   iwlwifi-5000-5.ucode
firmware:   iwlwifi-6000g2b-5.ucode
firmware:   iwlwifi-6000g2a-5.ucode
firmware:   iwlwifi-6050-5.ucode
firmware:   iwlwifi-6000-4.ucode
firmware:   iwlwifi-100-5.ucode
firmware:   iwlwifi-1000-5.ucode
firmware:   iwlwifi-135-5.ucode
firmware:   iwlwifi-105-5.ucode
firmware:   iwlwifi-2030-5.ucode
firmware:   iwlwifi-2000-5.ucode
srcversion: B3B67A8BF067C2881E7C1F8
alias:  pci:v8086d0892sv*sd0466bc*sc*i*
alias:  pci:v8086d0893sv*sd0266bc*sc*i*
alias:  pci:v8086d0892sv*sd0066bc*sc*i*
alias:  pci:v8086d0892sv*sd0462bc*sc*i*
alias:  pci:v8086d0893sv*sd0262bc*sc*i*
alias:  pci:v8086d0892sv*sd0062bc*sc*i*
alias:  pci:v8086d0894sv*sd0426bc*sc*i*
alias:  pci:v8086d0895sv*sd0226bc*sc*i*
alias:  pci:v8086d0894sv*sd0026bc*sc*i*
alias:  pci:v8086d0894sv*sd0422bc*sc*i*
alias:  pci:v8086d0895sv*sd0222bc*sc*i*
alias:  pci:v8086d0894sv*sd0022bc*sc*i*
alias:  pci:v8086d088Esv*sd4466bc*sc*i*
alias:  pci:v8086d088Fsv*sd4266bc*sc*i*
alias:  pci:v8086d088Esv*sd4066bc*sc*i*
alias:  pci:v8086d088Esv*sd4464bc*sc*i*
alias:  pci:v8086d088Fsv*sd4264bc*sc*i*
alias:  pci:v8086d088Esv*sd4064bc*sc*i*
alias:  pci:v8086d088Esv*sd4460bc*sc*i*
alias:  pci:v8086d088Fsv*sd4260bc*sc*i*
alias:  pci:v8086d088Esv*sd4060bc*sc*i*
alias:  pci:v8086d0887sv*sd4466bc*sc*i*
alias:  pci:v8086d0888sv*sd4266bc*sc*i*
alias:  pci:v8086d0887sv*sd4066bc*sc*i*
alias:  pci:v8086d0887sv*sd4462bc*sc*i*
alias:  pci:v8086d0888sv*sd4262bc*sc*i*
alias:  pci:v8086d0887sv*sd4062bc*sc*i*
alias:  pci:v8086d0890sv*sd4426bc*sc*i*
alias:  pci:v8086d0891sv*sd4226bc*sc*i*
alias:  pci:v8086d0890sv*sd4026bc*sc*i*
alias:  pci:v8086d0890sv*sd4422bc*sc*i*
alias:  pci:v8086d0891sv*sd4222bc*sc*i*
alias:  pci:v8086d0890sv*sd4022bc*sc*i*
alias:  pci:v8086d0896sv*sd5027bc*sc*i*
alias:  pci:v8086d0896sv*sd5025bc*sc*i*
alias:  pci:v8086d0897sv*sd5017bc*sc*i*
alias:  pci:v8086d0897sv*sd5015bc*sc*i*
alias:  pci:v8086d0896sv*sd5007bc*sc*i*
alias:  pci:v8086d0896sv*sd5005bc*sc*i*
alias:  pci:v8086d08AEsv*sd1027bc*sc*i*
alias:  pci:v8086d08AEsv*sd1025bc*sc*i*
alias:  pci:v8086d08AFsv*sd1017bc*sc*i*
alias:  pci:v8086d08AFsv*sd1015bc*sc*i*
alias:  pci:v8086d08AEsv*sd1007bc*sc*i*
alias:  pci:v8086d08AEsv*sd1005bc*sc*i*
alias:  pci:v8086d0084sv*sd1316bc*sc*i*
alias:  pci:v8086d0084sv*sd1216

Bug#682063: firmware-iwlwifi: Version 0.36 breaks firmware loading

[Bjørn Mork]

Sylvestre Ledru  writes:

> Package: firmware-iwlwifi
> Version: 0.36
> Severity: important
>
> Hello,
>
> With the version 0.36 of firmware-iwlwifi fails to load the iwlagn module 
> with the error:
> Jul 19 08:39:23 pomegues kernel: [ 1241.775811] iwlagn :01:00.0: request 
> for firmware file 'iwlwifi-6000g2b-5.ucode' failed.
> Jul 19 08:39:23 pomegues kernel: [ 1241.779455] iwlagn :01:00.0: request 
> for firmware file 'iwlwifi-6000g2b-4.ucode' failed.
>
> Rollback to 0.35 fixes the problem.
>
> Thanks for your work,
> Sylvestre
>
>
> PS: modinfo iwlagn gives:
> # modinfo iwlagn
> filename:   
> /lib/modules/3.1.0-1-amd64/kernel/drivers/net/wireless/iwlwifi/iwlagn.ko

Your kernel is not in the archive.  The firmware-iwlwifi package support
all kernels in squeeze, wheezy and sid. You need to keep track of the
necessary firmware yourself if you want to run other kernel versions.


Bjørn


--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipdkujtc@nemi.mork.no

Re: Time to upload linux (3.2.23-1)?

[Cyril Brulebois]

Ben Hutchings  (19/07/2012):
> There are various fairly important fixes pending for linux.  When would
> be a good time to upload these?

Provided the ABI doesn't change, feel free to upload at any time.

Mraw,
KiBi.


signature.asc
Description: Digital signature

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

[Lesław Kopeć]

On 07/18/2012 01:25 AM, Jonathan Nieder wrote:
> Anders Boström wrote:
> 
>> Starting with 3.2.17-1, the CPU load accounting is broken when the
>> computer is idle. The CPU load is reported as >0.50 when
>> idle. 3.2.16-1 don't suffer from this problem.
>>
>> Suspected patch is the upstream patch
>> "sched: Fix nohz load accounting -- again!"
>> commit 5e2d50da11f0e6ec3ce8fe658d7c83b0b4346c68 to 3.2 and
>> originating from c308b56b5398779cd3da0f62ab26b0453494c3d4 .
> 
> Please test the attached patch against a 3.2.y kernel, for example
> following the instructions below:

Good news everyone. I have tested kernel 3.2.21 and the attached patch
(based on 5167e8d I presume) seems to be fixing all the load average
oddities. I've compiled following kernels:

* 3.2.21-hz (CONFIG_NO_HZ=n)
* 3.2.21-no-hz  (CONFIG_NO_HZ=y)
* 3.2.21-no-hz-5167e8d  (CONFIG_NO_HZ=y) + attached patch

The load reported by 3.2.21-hz and 3.2.21-no-hz-5167e8d is exactly the
same under different CPU usage. Without the patch the tickless kernel
tends to show lower load values than what you would expect.

I can't say much for the case when load is too high on an idle machine,
because I haven't been able to reproduce the problem in the first place.

To summarize: the bug is present in unpatched kernel and fixed by
applying the attached patch. No nasty side effects noticed.

-- 
Lesław Kopeć



signature.asc
Description: OpenPGP digital signature

Bug#673107: kirkwood: TCP checksum errors when using MTU 9000

[Damien Martins]

Same behaviour :/

dmesg shows :

"[  619.869032] [] (unwind_backtrace+0x0/0xdc) from
[] (__alloc_pages_nodemask+0x4dc/0x57c)
[  619.878846] [] (__alloc_pages_nodemask+0x4dc/0x57c) from
[] (__get_free_pages+0x14/0x44)
[  619.888727] [] (__get_free_pages+0x14/0x44) from
[] (__kmalloc_track_caller+0x40/0x19c)
[  619.898526] [] (__kmalloc_track_caller+0x40/0x19c) from
[] (__alloc_skb+0x50/0x10c)
[  619.907976] [] (__alloc_skb+0x50/0x10c) from []
(dev_alloc_skb+0x1c/0x44)
[  619.916599] [] (dev_alloc_skb+0x1c/0x44) from []
(rxq_refill+0x7c/0x144 [mv643xx_eth])
[  619.926363] [] (rxq_refill+0x7c/0x144 [mv643xx_eth]) from
[] (mv643xx_eth_poll+0x5e4/0x68c [mv643xx_eth])
[  619.937757] [] (mv643xx_eth_poll+0x5e4/0x68c [mv643xx_eth])
from [] (net_rx_action+0x90/0x208)
[  619.948171] [] (net_rx_action+0x90/0x208) from []
(__do_softirq+0xc0/0x1a8)
[  619.956920] [] (__do_softirq+0xc0/0x1a8) from []
(irq_exit+0x40/0x94)
[  619.965108] [] (irq_exit+0x40/0x94) from []
(asm_do_IRQ+0x70/0x8c)
[  619.973079] [] (asm_do_IRQ+0x70/0x8c) from []
(__irq_svc+0x34/0x80)
[  619.981114] Exception stack(0xd5393d50 to 0xd5393d98)
[  619.986220] 3d40: 401a5d20
401a6000 0875 1000
[  619.994399] 3d60:  d5393d9c  d358e268 0001
d57dcd80 401a5000 d57dcd80
[  620.002613] 3d80: d7894cdc d5393d98 c00309d4 c00327c4 0013 
[  620.009295] [] (__irq_svc+0x34/0x80) from []
(feroceon_flush_user_cache_range+0x24/0x40)
[  620.019190] [] (feroceon_flush_user_cache_range+0x24/0x40)
from [] (0xd74e9c70)
[  620.028258] Mem-info:
[  620.030531] Normal per-cpu:
[  620.033325] CPU0: hi:   90, btch:  15 usd:  80
[  620.038175] active_anon:12271 inactive_anon:12281 isolated_anon:0
[  620.038191]  active_file:10174 inactive_file:9996 isolated_file:0
[  620.038208]  unevictable:0 dirty:26 writeback:0 unstable:0
[  620.038223]  free:13631 slab_reclaimable:1922 slab_unreclaimable:993
[  620.038240]  mapped:5751 shmem:164 pagetables:506 bounce:0
[  620.067688] Normal free:54524kB min:2032kB low:2540kB high:3048kB
active_anon:49084kB inactive_anon:49124kB active_file:40696kB
inactive_file:39984kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:259072kB mlocked:0kB dirty:104kB
writeback:0kB mapped:23004kB shmem:656kB slab_reclaimable:7688kB
slab_unreclaimable:3972kB kernel_stack:1592kB pagetables:2024kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
[  620.107406] lowmem_reserve[]: 0 0
[  620.110742] Normal: 12503*4kB 548*8kB 4*16kB 2*32kB 0*64kB 0*128kB
0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 54524kB
[  620.121725] 21208 total pagecache pages
[  620.125551] 872 pages in swap cache
[  620.129078] Swap cache stats: add 1865, delete 993, find 362/382
[  620.135074] Free swap  = 973040kB
[  620.138422] Total swap = 979832kB
[  620.153822] 65536 pages of RAM
[  620.156937] 14150 free pages
[  620.159818] 1618 reserved pages
[  620.162955] 2110 slab pages
[  620.165783] 34061 pages shared
[  620.168840] 872 pages swap cached

--
Regards,
Damien Martins


--
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/5007c8ab.4080...@makelofine.org

Bug#682063: firmware-iwlwifi: Version 0.36 breaks firmware loading

[Sylvestre Ledru]

Package: firmware-iwlwifi
Version: 0.36
Severity: important

Hello,

With the version 0.36 of firmware-iwlwifi fails to load the iwlagn module with 
the error:
Jul 19 08:39:23 pomegues kernel: [ 1241.775811] iwlagn :01:00.0: request 
for firmware file 'iwlwifi-6000g2b-5.ucode' failed.
Jul 19 08:39:23 pomegues kernel: [ 1241.779455] iwlagn :01:00.0: request 
for firmware file 'iwlwifi-6000g2b-4.ucode' failed.

Rollback to 0.35 fixes the problem.

Thanks for your work,
Sylvestre


PS: modinfo iwlagn gives:
# modinfo iwlagn
filename:   
/lib/modules/3.1.0-1-amd64/kernel/drivers/net/wireless/iwlwifi/iwlagn.ko
license:GPL
author: Copyright(c) 2003-2011 Intel Corporation 
version:in-tree:
description:Intel(R) Wireless WiFi Link AGN driver for Linux
firmware:   iwlwifi-5150-2.ucode
firmware:   iwlwifi-5000-5.ucode
firmware:   iwlwifi-6000g2b-5.ucode
firmware:   iwlwifi-6000g2a-5.ucode
firmware:   iwlwifi-6050-5.ucode
firmware:   iwlwifi-6000-4.ucode
firmware:   iwlwifi-100-5.ucode
firmware:   iwlwifi-1000-5.ucode
firmware:   iwlwifi-135-5.ucode
firmware:   iwlwifi-105-5.ucode
firmware:   iwlwifi-2030-5.ucode
firmware:   iwlwifi-2000-5.ucode
srcversion: B3B67A8BF067C2881E7C1F8
alias:  pci:v8086d0892sv*sd0466bc*sc*i*
alias:  pci:v8086d0893sv*sd0266bc*sc*i*
alias:  pci:v8086d0892sv*sd0066bc*sc*i*
alias:  pci:v8086d0892sv*sd0462bc*sc*i*
alias:  pci:v8086d0893sv*sd0262bc*sc*i*
alias:  pci:v8086d0892sv*sd0062bc*sc*i*
alias:  pci:v8086d0894sv*sd0426bc*sc*i*
alias:  pci:v8086d0895sv*sd0226bc*sc*i*
alias:  pci:v8086d0894sv*sd0026bc*sc*i*
alias:  pci:v8086d0894sv*sd0422bc*sc*i*
alias:  pci:v8086d0895sv*sd0222bc*sc*i*
alias:  pci:v8086d0894sv*sd0022bc*sc*i*
alias:  pci:v8086d088Esv*sd4466bc*sc*i*
alias:  pci:v8086d088Fsv*sd4266bc*sc*i*
alias:  pci:v8086d088Esv*sd4066bc*sc*i*
alias:  pci:v8086d088Esv*sd4464bc*sc*i*
alias:  pci:v8086d088Fsv*sd4264bc*sc*i*
alias:  pci:v8086d088Esv*sd4064bc*sc*i*
alias:  pci:v8086d088Esv*sd4460bc*sc*i*
alias:  pci:v8086d088Fsv*sd4260bc*sc*i*
alias:  pci:v8086d088Esv*sd4060bc*sc*i*
alias:  pci:v8086d0887sv*sd4466bc*sc*i*
alias:  pci:v8086d0888sv*sd4266bc*sc*i*
alias:  pci:v8086d0887sv*sd4066bc*sc*i*
alias:  pci:v8086d0887sv*sd4462bc*sc*i*
alias:  pci:v8086d0888sv*sd4262bc*sc*i*
alias:  pci:v8086d0887sv*sd4062bc*sc*i*
alias:  pci:v8086d0890sv*sd4426bc*sc*i*
alias:  pci:v8086d0891sv*sd4226bc*sc*i*
alias:  pci:v8086d0890sv*sd4026bc*sc*i*
alias:  pci:v8086d0890sv*sd4422bc*sc*i*
alias:  pci:v8086d0891sv*sd4222bc*sc*i*
alias:  pci:v8086d0890sv*sd4022bc*sc*i*
alias:  pci:v8086d0896sv*sd5027bc*sc*i*
alias:  pci:v8086d0896sv*sd5025bc*sc*i*
alias:  pci:v8086d0897sv*sd5017bc*sc*i*
alias:  pci:v8086d0897sv*sd5015bc*sc*i*
alias:  pci:v8086d0896sv*sd5007bc*sc*i*
alias:  pci:v8086d0896sv*sd5005bc*sc*i*
alias:  pci:v8086d08AEsv*sd1027bc*sc*i*
alias:  pci:v8086d08AEsv*sd1025bc*sc*i*
alias:  pci:v8086d08AFsv*sd1017bc*sc*i*
alias:  pci:v8086d08AFsv*sd1015bc*sc*i*
alias:  pci:v8086d08AEsv*sd1007bc*sc*i*
alias:  pci:v8086d08AEsv*sd1005bc*sc*i*
alias:  pci:v8086d0084sv*sd1316bc*sc*i*
alias:  pci:v8086d0084sv*sd1216bc*sc*i*
alias:  pci:v8086d0083sv*sd1326bc*sc*i*
alias:  pci:v8086d0083sv*sd1226bc*sc*i*
alias:  pci:v8086d0083sv*sd1306bc*sc*i*
alias:  pci:v8086d0083sv*sd1206bc*sc*i*
alias:  pci:v8086d0084sv*sd1315bc*sc*i*
alias:  pci:v8086d0084sv*sd1215bc*sc*i*
alias:  pci:v8086d0083sv*sd1325bc*sc*i*
alias:  pci:v8086d0083sv*sd1225bc*sc*i*
alias:  pci:v8086d0083sv*sd1305bc*sc*i*
alias:  pci:v8086d0083sv*sd1205bc*sc*i*
alias:  pci:v8086d0886sv*sd1317bc*sc*i*
alias:  pci:v8086d0886sv*sd1315bc*sc*i*
alias:  pci:v8086d0885sv*sd1327bc*sc*i*
alias:  pci:v8086d0885sv*sd1325bc*sc*i*
alias:  pci:v8086d0885sv*sd1307bc*sc*i*

Bug#681743: i915: display backlight brightness initially set to zero on boot

[Gedalya]

Tested 3.5.0-rc7+, boots up the same way, with the backlight off. Adding
i915.invert_brightness=1 makes it turn the brightness up to the maximum
as expected, however this is pretty ugly. Without this parameter, I can
just turn the brightness up with the fn keys and I get the nice
on-screen indicator from GNOME. However with invert_brightness I need to
turn it _up_, with the indicator showing it going up, in order to get it
down, and vice versa.
Anyway, I guess the desired result is that it should "just work" without
having to do special workarounds.


On Mon, 2012-07-16 at 06:45 -0500, Jonathan Nieder wrote:
> Those commits are both in 3.5-rc1,
> so if you get a chance to test 3.5-rc1 or newer, that would also be
> useful.
> 
> 


-- 
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/1342681054.3341.2.ca...@dml.gedalya.net

Bug#680278: not specific to linux-image-3.2.0-3-686-pae

[S. G.]

Same problem here with linux-image-3.2.0-3-amd64, Version 3.2.21-3. So
this bug does not seem to be specific to the binary package.


-- 
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/1342680911.5462.4.camel@t500sg