-git/scripts/kconfig/menu.c:586:18: warning: ‘jump’ may be
used uninitialized in this function [-Wmaybe-uninitialized]
/usr/local/src/linux-git/scripts/kconfig/menu.c:547:19: note: ‘jump’ was
declared here
The following patch seems to fix that:
Signed-off-by: Christian Kujau li...@nerdbynature.de
On Sun, 27 Oct 2013 at 18:28, Christian Kujau wrote:
While doing make oldconfig on 3.12-rc7 with gcc-4.7.2 (Debian), the
following warning is printed:
HOSTCC scripts/kconfig/zconf.tab.o
In file included from scripts/kconfig/zconf.tab.c:2537:0:
/usr/local/src/linux-git/scripts/kconfig
Christian Kujau wrote:
>Vasiliy Kulikov
>"pgrep sgid-program" returned nothing but "kill pics off stiff program"
Gaah, that should read "kill pid-of-sgid-program", sorry.
C.
--
To unsubscribe from this list: send the line "unsubscribe linux-k
Vasiliy Kulikov wrote:
>> But still, I wonder if this is
>> intended behaviour.
>
>Yes.
>
>If you think such side channel attacks are something you don't care,
>just turn hidepid off. That's why it is an option.
>
>If you want to turn it off for some users, use gid=XXX.
Maybe my initial
Vasiliy Kulikov seg...@openwall.com wrote:
But still, I wonder if this is
intended behaviour.
Yes.
If you think such side channel attacks are something you don't care,
just turn hidepid off. That's why it is an option.
If you want to turn it off for some users, use gid=XXX.
Maybe my
Christian Kujau li...@nerdbynature.de wrote:
Vasiliy Kulikov seg...@openwall.com
pgrep sgid-program returned nothing but kill pics off stiff program
Gaah, that should read kill pid-of-sgid-program, sorry.
C.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Sun, 8 Sep 2013 at 23:42, Eric W. Biederman wrote:
> I don't have a clue why anyone would want to hide processes, and make
> their own lives more difficult.
Oh, there are plenty of usescases, I'm sure. And I for one am thankful
that this process hiding option made it into the kernel. Or, to
On Sun, 8 Sep 2013 at 23:42, Eric W. Biederman wrote:
I don't have a clue why anyone would want to hide processes, and make
their own lives more difficult.
Oh, there are plenty of usescases, I'm sure. And I for one am thankful
that this process hiding option made it into the kernel. Or, to
Hi,
I was wondering why I cannot see processes that were started from SGID
programs:
$ grep ^proc /proc/mounts
proc /proc proc rw,nosuid,nodev,noexec,relatime,hidepid=2 0 0
$ ls -n `which ssh-agent`
-rwxr-sr-x 1 0 103 132748 Feb 8 2013 /usr/bin/ssh-agent
$
Hi,
I was wondering why I cannot see processes that were started from SGID
programs:
$ grep ^proc /proc/mounts
proc /proc proc rw,nosuid,nodev,noexec,relatime,hidepid=2 0 0
$ ls -n `which ssh-agent`
-rwxr-sr-x 1 0 103 132748 Feb 8 2013 /usr/bin/ssh-agent
$
Since no one objected[0] and Nico kinda approved of my suggestion to
remove "git update-index", I propose the 2nd version of this patch
for 3.11 (Linux, that is)
[0] https://lkml.org/lkml/2013/6/9/185
---
Signed-off-by: Christian Kujau
Cc: Nico Schottelius
I just stumb
Since no one objected[0] and Nico kinda approved of my suggestion to
remove git update-index, I propose the 2nd version of this patch
for 3.11 (Linux, that is)
[0] https://lkml.org/lkml/2013/6/9/185
---
Signed-off-by: Christian Kujau li...@nerdbynature.de
Cc: Nico Schottelius nico
Hi,
I just stumbled across another[0] issue when scripts/setlocalversion
operates on a write-protected source tree. Back then[0] the source tree
was on an read-only NFS share, so "test -w" was introduced before "git
update-index" was run.
This time, the source tree is on read/write NFS share,
Hi,
I just stumbled across another[0] issue when scripts/setlocalversion
operates on a write-protected source tree. Back then[0] the source tree
was on an read-only NFS share, so test -w was introduced before git
update-index was run.
This time, the source tree is on read/write NFS share, but
Hi,
after upgrading from 3.8.0-rc7 to 3.9.0-rc1, the following message appears
after booting and after dm-crypt (LUKS) partitions are mounted and
exported via NFS:
---
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning
Hi,
after upgrading from 3.8.0-rc7 to 3.9.0-rc1, the following message appears
after booting and after dm-crypt (LUKS) partitions are mounted and
exported via NFS:
---
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning
forwarding to lkml, not sure how many people read b43-dev...
Hi,
while playing around with this BCM4306 (b43) wifi NIC (and reporting some
lockdep issues, [0]), I noticed that the chip could be used as a HWRNG and
driver support for this has been added years ago - great, I never knew!
But
forwarding to lkml, not sure how many people read b43-dev...
Hi,
while playing around with this BCM4306 (b43) wifi NIC (and reporting some
lockdep issues, [0]), I noticed that the chip could be used as a HWRNG and
driver support for this has been added years ago - great, I never knew!
But
Hi,
similar to what I reported earlier [0] for 3.8.0-rc1, this happens during
"ifup wlan0" (which in effect starts wpa_supplicant to bring up a Broadcom
b43 wifi network interface). The interface is working though and continues
to work over several ifup/ifdown iterations.
The backtrace looks
On Sun, 27 Jan 2013 at 14:56, Christian Kujau wrote:
> Hm, is there no chance to get this into 3.8? I've been running with this
> patch applied since 3.7-rc7 and it got rid of this
> "MAX_STACK_TRACE_ENTRIES too low" message. I've just upgraded to 3.8-rc5
> and it's
On Sun, 27 Jan 2013 at 14:56, Christian Kujau wrote:
Hm, is there no chance to get this into 3.8? I've been running with this
patch applied since 3.7-rc7 and it got rid of this
MAX_STACK_TRACE_ENTRIES too low message. I've just upgraded to 3.8-rc5
and it's still not in mainline :-\
Hah! I
Hi,
similar to what I reported earlier [0] for 3.8.0-rc1, this happens during
ifup wlan0 (which in effect starts wpa_supplicant to bring up a Broadcom
b43 wifi network interface). The interface is working though and continues
to work over several ifup/ifdown iterations.
The backtrace looks
On Tue, 15 Jan 2013 at 14:59, Li Zhong wrote:
> FYI, it is already in the next of ppc tree
> http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=shortlog;h=refs/heads/next
>
> I guess it would get into 3.9, at least.
Hm, is there no chance to get this into 3.8? I've been running with
On Tue, 15 Jan 2013 at 14:59, Li Zhong wrote:
FYI, it is already in the next of ppc tree
http://git.kernel.org/?p=linux/kernel/git/benh/powerpc.git;a=shortlog;h=refs/heads/next
I guess it would get into 3.9, at least.
Hm, is there no chance to get this into 3.8? I've been running with this
On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote:
> On Tue, 2012-11-27 at 19:22 -0800, Christian Kujau wrote:
> > On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote:
> > > the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
> >
> > I found the followin
On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote:
On Tue, 2012-11-27 at 19:22 -0800, Christian Kujau wrote:
On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote:
the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
I found the following on patchwork, but this seems to deal
On Sun, 23 Dec 2012 at 13:34, Christian Kujau wrote:
> On Sat, 22 Dec 2012 at 16:28, Maciej Rutecki wrote:
> > Got during suspend to disk:
>
> I got a similar message on a powerpc G4 system, right after bootup (no
> suspend involved):
>
> http://nerdbynature.
On Sun, 23 Dec 2012 at 13:34, Christian Kujau wrote:
On Sat, 22 Dec 2012 at 16:28, Maciej Rutecki wrote:
Got during suspend to disk:
I got a similar message on a powerpc G4 system, right after bootup (no
suspend involved):
http://nerdbynature.de/bits/3.8.0-rc1/
FWIW, this is still
On Sat, 22 Dec 2012 at 16:28, Maciej Rutecki wrote:
> Got during suspend to disk:
I got a similar message on a powerpc G4 system, right after bootup (no
suspend involved):
http://nerdbynature.de/bits/3.8.0-rc1/
[ 97.803049] ==
[
On Sat, 22 Dec 2012 at 16:28, Maciej Rutecki wrote:
Got during suspend to disk:
I got a similar message on a powerpc G4 system, right after bootup (no
suspend involved):
http://nerdbynature.de/bits/3.8.0-rc1/
[ 97.803049] ==
[
On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote:
> On Tue, 2012-11-27 at 19:22 -0800, Christian Kujau wrote:
> > On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote:
> > > the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
> >
> > I found the followin
On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote:
On Tue, 2012-11-27 at 19:22 -0800, Christian Kujau wrote:
On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote:
the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
I found the following on patchwork, but this seems to deal
On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote:
> Would you please help to try the following fix? I don't have a powerpc32
> machine for test...
I've just applied this to 3.7-rc7 and booted the machine. I don't know how
to trigger this bug, so it might take a while until it happens again - or
On Wed, 28 Nov 2012 at 16:41, Li Zhong wrote:
Would you please help to try the following fix? I don't have a powerpc32
machine for test...
I've just applied this to 3.7-rc7 and booted the machine. I don't know how
to trigger this bug, so it might take a while until it happens again - or
not,
On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote:
> the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
I found the following on patchwork, but this seems to deal with powerpc64
only, while this PowerBook G4 of mine is powerpc32:
http://patchwork.ozlabs.org/patch/193
Hi,
the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
[40007.339487] [sched_delayed] sched: RT throttling activated
[69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low!
[69731.390371] turning off the locking correctness validator.
[69731.391942] Call Trace:
[69731.393525]
Hi,
the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
[40007.339487] [sched_delayed] sched: RT throttling activated
[69731.388717] BUG: MAX_STACK_TRACE_ENTRIES too low!
[69731.390371] turning off the locking correctness validator.
[69731.391942] Call Trace:
[69731.393525]
On Tue, 27 Nov 2012 at 19:06, Christian Kujau wrote:
the same thing[0] happened again in 3.7-rc7, after ~20h uptime:
I found the following on patchwork, but this seems to deal with powerpc64
only, while this PowerBook G4 of mine is powerpc32:
http://patchwork.ozlabs.org/patch/193414
Hi,
after upgrading from 3.6.0-08492-gd43 to 3.7.0-rc4 and running it for a
day or so, this happened:
[27148.965634] BUG: MAX_STACK_TRACE_ENTRIES too low!
[27148.967356] turning off the locking correctness validator.
[27148.968967] Call Trace:
[27148.970577] [ec633d00] [c0009064]
Hi,
after upgrading from 3.6.0-08492-gd43 to 3.7.0-rc4 and running it for a
day or so, this happened:
[27148.965634] BUG: MAX_STACK_TRACE_ENTRIES too low!
[27148.967356] turning off the locking correctness validator.
[27148.968967] Call Trace:
[27148.970577] [ec633d00] [c0009064]
[Cc'ed lkml, hence the full-quote]
On Fri, 12 Oct 2012 at 08:33, Dave Chinner wrote:
> On Thu, Oct 11, 2012 at 11:13:14AM -0700, Christian Kujau wrote:
> > Hi,
> >
> > since Linux 3.5 I'm seeing these "inconsistent lock state" lockdep
> > warnings [0
[Cc'ed lkml, hence the full-quote]
On Fri, 12 Oct 2012 at 08:33, Dave Chinner wrote:
On Thu, Oct 11, 2012 at 11:13:14AM -0700, Christian Kujau wrote:
Hi,
since Linux 3.5 I'm seeing these inconsistent lock state lockdep
warnings [0]. They show up in 3.6 as well [1]. I was being told[2
On Thu, 12 Jul 2012 at 17:56, Li Zhong wrote:
> On Wed, 2012-07-11 at 15:50 -0700, Dan Williams wrote:
> > On Wed, Jul 11, 2012 at 3:42 PM, Andrew Morton
> > wrote:
> > > The patch is fairly wordwrapped - please fix up your email client.
> > >
> > > More seriously, it does not apply to linux-next
On Thu, 12 Jul 2012 at 17:56, Li Zhong wrote:
On Wed, 2012-07-11 at 15:50 -0700, Dan Williams wrote:
On Wed, Jul 11, 2012 at 3:42 PM, Andrew Morton
a...@linux-foundation.org wrote:
The patch is fairly wordwrapped - please fix up your email client.
More seriously, it does not apply to
On Mon, 18 Feb 2008, Sergio Luis wrote:
if you select Y here it will prompt you about the lguest
hypervisor, the code in question, the one you want to build, and you
will then be able to select it as a module, if you want, or built-in
into the kernel.
Ah, thanks for the clarification. And
On Mon, 18 Feb 2008, Sergio Luis wrote:
if you select Y here it will prompt you about the lguest
hypervisor, the code in question, the one you want to build, and you
will then be able to select it as a module, if you want, or built-in
into the kernel.
Ah, thanks for the clarification. And
On Sun, 17 Feb 2008, Sergio Luis wrote:
oops. sorry, I just realized I missed the makefile part. I changed
the config symbol to CONFIG_LGUEST_HYPERVISOR so I should change it on
the makefile as well. reposting an updated patch for testing:
Hm, now I cannot select LGUEST as a module any more:
On Sun, 17 Feb 2008, Sergio Luis wrote:
oops. sorry, I just realized I missed the makefile part. I changed
the config symbol to CONFIG_LGUEST_HYPERVISOR so I should change it on
the makefile as well. reposting an updated patch for testing:
Hm, now I cannot select LGUEST as a module any more:
On Sun, 17 Feb 2008, allied internet ag- Stefan Priebe wrote:
One week ago we upgraded about 300 servers from 2.6.20.20 to 2.6.24.2.
Did you test with *one* server before upgrading all 300? If not, please do
and try to upgrade in smaller steps, e.g. 2.6.20->2.6.21 and see when it
breaks. Add
On Sun, 17 Feb 2008, Sergio Luis wrote:
It doesn't fix the problem totally. If we select
Virtualization->Linux hypervisor example code (CONFIG_LGUEST)
as a module, we will get the same build errors,
Confirmed, the build errors persist with CONFIG_LGUEST=m and Rusty's patch
applied.
thanks,
On Sun, 17 Feb 2008, Sergio Luis wrote:
It doesn't fix the problem totally. If we select
Virtualization-Linux hypervisor example code (CONFIG_LGUEST)
as a module, we will get the same build errors,
Confirmed, the build errors persist with CONFIG_LGUEST=m and Rusty's patch
applied.
thanks,
On Sun, 17 Feb 2008, allied internet ag- Stefan Priebe wrote:
One week ago we upgraded about 300 servers from 2.6.20.20 to 2.6.24.2.
Did you test with *one* server before upgrading all 300? If not, please do
and try to upgrade in smaller steps, e.g. 2.6.20-2.6.21 and see when it
breaks. Add
Hi,
just FYI, upgrading to -rc8 gave the following messages in kern.log in
the morning hours, when the backups were run:
===
[ INFO: possible circular locking dependency detected ]
2.6.24-rc8 #2
Hi,
just FYI, upgrading to -rc8 gave the following messages in kern.log in
the morning hours, when the backups were run:
===
[ INFO: possible circular locking dependency detected ]
2.6.24-rc8 #2
On Sat, 5 Jan 2008, Davide Libenzi wrote:
A solution may be to move the call to ep_poll_safewake() (that'd become a
simple wake_up()) inside a tasklet or whatever is today trendy for delayed
work. But his kinda scares me to be honest, since epoll has already a
bunch of places where it could be
On Sat, 5 Jan 2008, Davide Libenzi wrote:
A solution may be to move the call to ep_poll_safewake() (that'd become a
simple wake_up()) inside a tasklet or whatever is today trendy for delayed
work. But his kinda scares me to be honest, since epoll has already a
bunch of places where it could be
hi,
a few minutes after upgrading from -rc5 to -rc6 I got:
[ 1310.670986] =
[ 1310.671690] [ INFO: possible recursive locking detected ]
[ 1310.672097] 2.6.24-rc6 #1
[ 1310.672421] -
[ 1310.672828]
On Tue, 4 Dec 2007, Ingo Molnar wrote:
thanks for the patch and the extensive description. I've applied this to
x86.git. Do you agree that this has no urgency for v2.6.24 and is thus
v2.6.25 material?
Pardon my ignorance, but: aren't we in -rc already? I was under the
assumption that during
On Tue, 4 Dec 2007, Ingo Molnar wrote:
thanks for the patch and the extensive description. I've applied this to
x86.git. Do you agree that this has no urgency for v2.6.24 and is thus
v2.6.25 material?
Pardon my ignorance, but: aren't we in -rc already? I was under the
assumption that during
On Sun, 25 Nov 2007, Christoph Hellwig wrote:
This patch does exactly that and reverts xfs_file_readdir to what's
basically the 2.6.23 version minus the uio and vnops junk.
Thanks, works here too (without nordirplus as a mountoption).
Am I supposed to close the bug[0] or do you guys want to
On Sun, 25 Nov 2007, Christoph Hellwig wrote:
This patch does exactly that and reverts xfs_file_readdir to what's
basically the 2.6.23 version minus the uio and vnops junk.
Thanks, works here too (without nordirplus as a mountoption).
Am I supposed to close the bug[0] or do you guys want to
On Sun, 18 Nov 2007, Justin Piszcz wrote:
I wonder why so few people are seeing this, I'd have assumed that
NFSv3 && XFS is not sooo exotic...
Still on 2.6.23.x here (also use nfsv3 + xfs).
So, it's the "too few people are testing -rc kernels" issue again :(
Christian.
--
BOFH excuse #118:
On Fri, 16 Nov 2007, Chris Wedgwood wrote:
Oops, I meant it for NFSD... and I'm somewhat serious. I'm not
saying it's a good long term solution, but a potentially safer
short-term workaround.
I've opened http://bugzilla.kernel.org/show_bug.cgi?id=9400 to track this
one (and to not forget
On Fri, 16 Nov 2007, Chris Wedgwood wrote:
Oops, I meant it for NFSD... and I'm somewhat serious. I'm not
saying it's a good long term solution, but a potentially safer
short-term workaround.
I've opened http://bugzilla.kernel.org/show_bug.cgi?id=9400 to track this
one (and to not forget
On Sun, 18 Nov 2007, Justin Piszcz wrote:
I wonder why so few people are seeing this, I'd have assumed that
NFSv3 XFS is not sooo exotic...
Still on 2.6.23.x here (also use nfsv3 + xfs).
So, it's the too few people are testing -rc kernels issue again :(
Christian.
--
BOFH excuse #118:
the
On Fri, November 16, 2007 01:34, Chris Wedgwood wrote:
> I'm not sure what you're doing here, but a viable work-around for now
> might be to use nfsv2 mounts, something like
>
> mount -o vers=2 ...
> or to keep v3 and disable readdirplus doing something like:
> mount -o vers=3,nordirplus ...
OK,
On Fri, November 16, 2007 01:34, Chris Wedgwood wrote:
I'm not sure what you're doing here, but a viable work-around for now
might be to use nfsv2 mounts, something like
mount -o vers=2 ...
or to keep v3 and disable readdirplus doing something like:
mount -o vers=3,nordirplus ...
OK, I'll
On Thu, 15 Nov 2007, Christian Kujau wrote:
Upon accessing the /data/sub part of the CIFS share, the client hung, waiting
for the server to respond (the [cifs] kernel thread on the client was
spinning, waiting for i/o). On the server, similar things as with the nfsd
processes happened
Turns
On Thu, November 15, 2007 08:51, Christian Kujau wrote:
> Since NFS was not working (the nfsd processes were already in D state),
> to mount a CIFS share from the very same server (and the same client).
That should read:
Since NFS was not working (the nfsd processes were already in D sta
On Wed, 14 Nov 2007, Christian Kujau wrote:
Yes, the nfsd process only got stuck when I did ls(1) (with or without -l) on
a NFS share which contained a XFS partition.
Since NFS was not working (the nfsd processes were already in D state), to
mount a CIFS share from the very same server
On Wed, 14 Nov 2007, Christian Kujau wrote:
Yes, the nfsd process only got stuck when I did ls(1) (with or without -l) on
a NFS share which contained a XFS partition.
Since NFS was not working (the nfsd processes were already in D state), to
mount a CIFS share from the very same server
On Thu, November 15, 2007 08:51, Christian Kujau wrote:
Since NFS was not working (the nfsd processes were already in D state),
to mount a CIFS share from the very same server (and the same client).
That should read:
Since NFS was not working (the nfsd processes were already in D state), I
On Thu, 15 Nov 2007, Christian Kujau wrote:
Upon accessing the /data/sub part of the CIFS share, the client hung, waiting
for the server to respond (the [cifs] kernel thread on the client was
spinning, waiting for i/o). On the server, similar things as with the nfsd
processes happened
Turns
On Wed, 14 Nov 2007, Chris Wedgwood wrote:
After some bisection pain (sg broken in the middle and XFS not
compiling in other places) the regression seems to be:
commit 051e7cd44ab8f0f7c2958371485b4a1ff64a8d1b
Author: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Tue Aug 28 13:58:24
On Wed, 14 Nov 2007, J. Bruce Fields wrote:
On Wed, Nov 14, 2007 at 09:43:40AM +0200, Benny Halevy wrote:
I wonder if this is a similar hang to what Christian was seeing here:
http://lkml.org/lkml/2007/11/13/319
Ah, thanks for noticing that. Christian Kujau, is /data an xfs
partition
On Wed, 14 Nov 2007, J. Bruce Fields wrote:
On Wed, Nov 14, 2007 at 09:43:40AM +0200, Benny Halevy wrote:
I wonder if this is a similar hang to what Christian was seeing here:
http://lkml.org/lkml/2007/11/13/319
Ah, thanks for noticing that. Christian Kujau, is /data an xfs
partition
On Wed, 14 Nov 2007, Chris Wedgwood wrote:
After some bisection pain (sg broken in the middle and XFS not
compiling in other places) the regression seems to be:
commit 051e7cd44ab8f0f7c2958371485b4a1ff64a8d1b
Author: Christoph Hellwig [EMAIL PROTECTED]
Date: Tue Aug 28 13:58:24 2007
On Tue, 13 Nov 2007, Christian Kujau wrote:
Ah, I forgot about that. Will do as soon as I get a working kernel again. I'm
in the middle of git-bisecting and I had to mark the last 2 versions as "bad"
but only because they 1) Oopsed during boot or 2) could not load the kernel
ima
On Tue, 13 Nov 2007, Andrew Morton wrote:
There are a number of process things we _could_ do. Like
- have bugfix-only kernel releases
Adrian Bunk does (did?) this with 2.6.16.x, although it always seemed to
me like an unrewarded one man show. AFAIK not even the big distros are
begging for
On Tue, 13 Nov 2007, J. Bruce Fields wrote:
Could you get a sysrq-T trace? (First get the [nfsd] processes in [D]
Ah, I forgot about that. Will do as soon as I get a working kernel again.
I'm in the middle of git-bisecting and I had to mark the last 2 versions
as "bad" but only because they
On Tue, 13 Nov 2007, Andrew Morton wrote:
I think that we're fairly good about working the regressions in
Adrian/Michal/Rafael's lists but once Linus releases 2.6.x we tend to let
the unsolved ones slide, and we don't pay as much attention to the
regressions which 2.6.x testers report.
Can't
Hi there,
I noticed that I cannot use kernel nfsd any more with 2.6.24-rc2, last
working kernel as of now is 2.6.23.1. First I was using nfsv4 but
switching to nfsv3 did not help either: exported shares can be mounted
(client: 2.6-git/powerpc32, nfs-common-1.1.1~git-20070709-3ubuntu1), but
Hi there,
I noticed that I cannot use kernel nfsd any more with 2.6.24-rc2, last
working kernel as of now is 2.6.23.1. First I was using nfsv4 but
switching to nfsv3 did not help either: exported shares can be mounted
(client: 2.6-git/powerpc32, nfs-common-1.1.1~git-20070709-3ubuntu1), but
On Tue, 13 Nov 2007, Andrew Morton wrote:
I think that we're fairly good about working the regressions in
Adrian/Michal/Rafael's lists but once Linus releases 2.6.x we tend to let
the unsolved ones slide, and we don't pay as much attention to the
regressions which 2.6.x testers report.
Can't
On Tue, 13 Nov 2007, J. Bruce Fields wrote:
Could you get a sysrq-T trace? (First get the [nfsd] processes in [D]
Ah, I forgot about that. Will do as soon as I get a working kernel again.
I'm in the middle of git-bisecting and I had to mark the last 2 versions
as bad but only because they
On Tue, 13 Nov 2007, Andrew Morton wrote:
There are a number of process things we _could_ do. Like
- have bugfix-only kernel releases
Adrian Bunk does (did?) this with 2.6.16.x, although it always seemed to
me like an unrewarded one man show. AFAIK not even the big distros are
begging for
On Tue, 13 Nov 2007, Christian Kujau wrote:
Ah, I forgot about that. Will do as soon as I get a working kernel again. I'm
in the middle of git-bisecting and I had to mark the last 2 versions as bad
but only because they 1) Oopsed during boot or 2) could not load the kernel
image:
Same again
On Sun, 2 Sep 2007, Stephen Hemminger wrote:
Vendor module calls kernel api incorrectly. dev_set_promiscuity requires
that the calling thread hold rtnl mutex (ie call rtnl_lock). It's their bug,
netdev doesn't want to hear about it.
OK, that's all I needed to know. Thank you both for your
Wow, I should really update more often. Skipping the last -rc versions
AND adding a new device (zd1211rw) to the box turns out to be quite
interesting ([0],[1]).
However, this time loading of a (proprietary) module is involved. Knowing
that lkml cannot really help here (and I should contact
Hi,
after upgrading to 2.6.23-rc5 (and applying davem's fix [0]), lockdep
was quite noisy when I tried to shape my external (wireless) interface:
[ 6400.534545] FahCore_78.exe/3552 just changed the state of lock:
[ 6400.534713] (>ingress_lock){-+..}, at: []
netif_receive_skb+0x2d5/0x3c0
[
On Sun, 2 Sep 2007, Herbert Xu wrote:
You want this patch (by davem).
I applied the patch and the box is up for 1hr now. Since I was able to
reproduce the oops pretty reliable with this bittorrent thingy, I
did the same a few times now, but the box did NOT crash :)
Unfortunately people
On Sun, 2 Sep 2007, Herbert Xu wrote:
You want this patch (by davem).
I applied the patch and the box is up for 1hr now. Since I was able to
reproduce the oops pretty reliable with this bittorrent thingy, I
did the same a few times now, but the box did NOT crash :)
Unfortunately people
Hi,
after upgrading to 2.6.23-rc5 (and applying davem's fix [0]), lockdep
was quite noisy when I tried to shape my external (wireless) interface:
[ 6400.534545] FahCore_78.exe/3552 just changed the state of lock:
[ 6400.534713] (dev-ingress_lock){-+..}, at: [c038d595]
Wow, I should really update more often. Skipping the last -rc versions
AND adding a new device (zd1211rw) to the box turns out to be quite
interesting ([0],[1]).
However, this time loading of a (proprietary) module is involved. Knowing
that lkml cannot really help here (and I should contact
On Sun, 2 Sep 2007, Stephen Hemminger wrote:
Vendor module calls kernel api incorrectly. dev_set_promiscuity requires
that the calling thread hold rtnl mutex (ie call rtnl_lock). It's their bug,
netdev doesn't want to hear about it.
OK, that's all I needed to know. Thank you both for your
Hi,
today I switched from 2.6.22.3 to 2.6.23-rc5 (skipped quite a few -rc
versions due to lack of time), and the box keeps panicking under certain
circumstances. I suspected disk related problems, because: when the box
is up, I usually resume ~10 bittorrent files. When doing this, each
file
Hi,
today I switched from 2.6.22.3 to 2.6.23-rc5 (skipped quite a few -rc
versions due to lack of time), and the box keeps panicking under certain
circumstances. I suspected disk related problems, because: when the box
is up, I usually resume ~10 bittorrent files. When doing this, each
file
On Fri, 13 Jul 2007, Christian Kujau wrote:
Ah, this seem to have fixed http://lkml.org/lkml/2007/7/8/21 and really
looks promising, I'll try 2.6.22-git2 now.
for the record: running 2.6.22-git3 now and the Oopses went away ;)
thanks,
Christian.
--
BOFH excuse #352:
The cables
On Thu, 12 Jul 2007, Nathan Lynch wrote:
Have you tried 2.6.22? Linus committed a utimensat-related oops fix
right before releasing it:
Ah, this seem to have fixed http://lkml.org/lkml/2007/7/8/21 and really
looks promising, I'll try 2.6.22-git2 now.
thanks,
Christian.
--
BOFH excuse #208:
On Thu, 12 Jul 2007, Nathan Lynch wrote:
Have you tried 2.6.22? Linus committed a utimensat-related oops fix
right before releasing it:
Ah, this seem to have fixed http://lkml.org/lkml/2007/7/8/21 and really
looks promising, I'll try 2.6.22-git2 now.
thanks,
Christian.
--
BOFH excuse #208:
101 - 200 of 304 matches
Mail list logo
