On Thu, 1 Apr 2021, Paul E. McKenney wrote:
> +# This script knows only English.
> +LANG=en_US.UTF-8; export LANG
This, too, will only work if en_US.UTF-8 is installed . Check with "locale
-a" if it is. Also, Perl will complain loudly if the language is not
installed (try: "LANG=en_US.UTF-9
Hi,
while looking through boot messages I came across the following on a
Lenovo T470 laptop with Linux 5.8:
acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910
(first instance was on PNP0C14:01)
acpi PNP0C14:03: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910
On Tue, 14 Jul 2020, Jonathan Corbet wrote:
> > N: Derrick J. Brashear
> > E: sha...@dementia.org
> > -W: http://www.dementia.org/~shadow
That particular entry moved to:
W: http://www.contrib.andrew.cmu.edu/~shadow/
(The https version only supports TLSv1, and Firefox balks)
Otherwise, what
On Tue, 23 Jun 2020, Kees Cook wrote:
> > If you run something with exec stack after the message
> > you shouldn't get it second time.
>
> If you want to reset this flag, you can do:
> # echo 1 > /sys/kernel/debug/clear_warn_once
Thanks. Although, I tend to not mount
On Sat, 4 Jan 2020, Christian Kujau wrote:
> On Sun, 29 Dec 2019, Linus Torvalds wrote:
> > > When file systems are remounted a couple of times per day (e.g. rw/ro
> > > for backup
> > > purposes), dmesg gets flooded with these messages. Chang
On Wed, 24 Jun 2020, Alexey Dobriyan wrote:
> BTW this bug was exactly the one described in the changelog:
> compiling assembly brings executable stack by default:
Great, thanks for the pointer, will wait until this lands in Arch. My
search engine brought up the lkml discussion though, no the
On Wed, 24 Jun 2020, Alexey Dobriyan wrote:
> > > process '/usr/bin/rsync' started with executable stack
> > > But I can't reproduce this message,
>
> This message is once-per-reboot.
Interesting, thanks. Now I know why I cannot reproduce this. I still
wonder what made rsync trigger this
On Tue, 23 Jun 2020, Kees Cook wrote:
> > $ checksec --format=json --extended --file=`which rsync` | jq
> > {
> > "/usr/bin/rsync": {
> > "relro": "full",
> > "canary": "yes",
> > "nx": "no",
> ^^
>
> It is, indeed, marked executable, it seems. What distro is this?
Hi,
exactly this[0] happened today, on a 5.6.5 kernel:
process '/usr/bin/rsync' started with executable stack
But I can't reproduce this message, and rsync (v3.2.0, not exactly
abandonware) runs several times a day, so to repeat Andrew's questions[0]
from last year:
> What are poor users
On Fri, 5 Jun 2020, Andrew Cooper wrote:
> PVH domains don't have the emulated platform device, so Linux will be
> finding ~0 when it goes looking in config space.
>
> The diagnostic should be skipped in that case, to avoid giving the false
> impression that something is wrong.
Understood,
linux/kernel/git/xen/tip.git/commit/?h=for-linus-5.8=c54b071c192dfe8061336f650ceaf358e6386e0b
Applied that manually and now the system boots even with vcpus < maxvcpus.
So, if this still matters:
Tested-by: Christian Kujau
Thank you for your response, and the fix!
Christian.
--
B
Hi,
I'm running a small Xen PVH domain and upgrading from vanilla 5.6.0 to
5.7.0 caused the splat below, really early during boot. The configuration
has not changed, all new "make oldconfig" prompts have been answered with
"N". Old and new config, dmesg are here:
On Wed, 13 May 2020, Patrick Donnelly wrote:
> However, it seems odd that this depends on the owner of the directory.
> i.e. this protection only seems to be enforced if the sticky directory
> is owned by root. That's expected?
According to the documentation[0] this appears to be intentional:
On Tue, 12 May 2020, kernel test robot wrote:
> FYI, we noticed a -71.8% regression of netperf.Throughput_total_tps due to
> commit:
As noted in this report, netperf is used to "measure various aspect of
networking performance". Are we sure the bisect is correct? JFS is a
filesystem and is not
While compiling mainline with gcc-9.1.1 the following warning is emitted:
===
../arch/x86/kernel/ptrace.c: In function ‘set_segment_reg’:
../arch/x86/kernel/ptrace.c:202:6: warning: this statement may fall
through [-Wimplicit-fallthrough=]
Hi David,
On Tue, 12 Mar 2019, David Howells wrote:
> > My /usr/local/src mount was mounted with vers=4.2 (default), while
> > nfstest_cache was mounting its test-mount with vers=4.1! Apart from the
> > different rsize/wsize values, the version number stood out. And indeed,
> > when I mount my
On Mon, 11 Mar 2019, David Howells wrote:
> I've a couple more patches for you - one a bugfix and one that will print more
> information. They don't actually affect the problem you're seeing. I'll post
> them as replies to this message.
Thanks for the patches. I've applied all three to v5.0 and
On Fri, 8 Mar 2019, Christian Kujau wrote:
> Running Linux v5.0 with this patch applied does indeed still produce the
> "Duplicate cookie detected" messages, but I only ever see wrq=0 when
> running nfstest_cache:
>
>https://paste.fedoraproject.org/paste/dkav0FQz
On Fri, 8 Mar 2019, David Howells wrote:
> See the attached for a patch that helps with certain kinds of collision,
> though I can't see that it should help with what you're seeing since the
> RELINQUISHED flag isn't set on the old cookie (fl=222, but 0x10 isn't in
> there). You can monitor the
On Fri, 8 Mar 2019, David Howells wrote:
> > $ mount | grep nfs4
> > nfs:/usr/local/src on /usr/local/src type nfs4
> > (ro,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.56.139,local_lock=none,addr=192.168.0.115)
> >
> >
On Wed, 6 Mar 2019, David Howells wrote:
> I can reproduce a slightly different problem by setting off ~6000 parallel
> processes, each reading its own individual directory of files.
Ususually I only see it shortly after mount, and only once, but I too can
reproduce it with NFStest ([0], and
Hi,
ever since ec0328e46d6e ("fscache: Maintain a catalogue of allocated
cookies") was commited, people are seeing[0] those "Duplicate cookie
detected" messages in syslog, see below. NFS and CIFS mounts appear to
continue to work, but these messsages are new and I too am wondering if
this is
:#define __addr_ok(addr) \
If so, would simly removing it do the trick or is there more magic
involved? I don't have that many cross-compilers though and it's not even
build-tested:
commit f899653c64cce05fde426d0298cd67670f8ab8e2
Author: Christian Kujau
Date: Sun Mar 3 22:43:09
Hi,
I'm running an Ubuntu "mainline" kernel[0] as a Xen 4.11.1 DomU (PV) and
ever since upgrading to Linux 5.0-rcX I get these WARNING messages shown
below. Going back in my logs[1] I can see that I got a similar messages
for v4.20 too, but with v5.0 they appear more often and upgrading from
aps the real problem there is an
> > incorrectly configured NFS setup (uid/gid mismatch between NFS
> > client/server, or permissions mismatch between mount options and NFS
> > server?). Christian Kujau: can you speak to that?
> >
> > Well, we could also make our
aps the real problem there is an
> > incorrectly configured NFS setup (uid/gid mismatch between NFS
> > client/server, or permissions mismatch between mount options and NFS
> > server?). Christian Kujau: can you speak to that?
> >
> > Well, we could also make our
On Fri, 17 Aug 2018, Kees Cook wrote:
> On Thu, Aug 16, 2018 at 11:56 PM, Christian Kujau
> wrote:
> > On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
> >> Bart Massey reported what turned out to be a usercopy whitelist false
> >> positive in JFS when symli
On Fri, 17 Aug 2018, Kees Cook wrote:
> On Thu, Aug 16, 2018 at 11:56 PM, Christian Kujau
> wrote:
> > On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
> >> Bart Massey reported what turned out to be a usercopy whitelist false
> >> positive in JFS when symli
On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
> Bart Massey reported what turned out to be a usercopy whitelist false
> positive in JFS when symlink contents exceeded 128 bytes. The inline
> inode data (i_inline) is actually designed to overflow into the "extended
So, this may be a
On Fri, 3 Aug 2018, Kees Cook via Jfs-discussion wrote:
> Bart Massey reported what turned out to be a usercopy whitelist false
> positive in JFS when symlink contents exceeded 128 bytes. The inline
> inode data (i_inline) is actually designed to overflow into the "extended
So, this may be a
On Thu, 26 Jul 2018, Gao Xiang wrote:
> EROFS file system is a read-only file system with compression
> support designed for certain devices (especially embeded
> devices) with very limited physical memory and lots of memory
Out of curiousity, and as Richard already asked[0] - what about existing
On Thu, 26 Jul 2018, Gao Xiang wrote:
> EROFS file system is a read-only file system with compression
> support designed for certain devices (especially embeded
> devices) with very limited physical memory and lots of memory
Out of curiousity, and as Richard already asked[0] - what about existing
On Thu, 4 Jan 2018, Tom Hromatka wrote:
> > > [0.00] [ cut here ]
> > > [0.00] XSAVE consistency problem, dumping leaves
> > I think this is a vbox issue, with virtualbox not exposing all the
> > xsave state, so that when the kernel adds up the xsave areas,
On Thu, 4 Jan 2018, Tom Hromatka wrote:
> > > [0.00] [ cut here ]
> > > [0.00] XSAVE consistency problem, dumping leaves
> > I think this is a vbox issue, with virtualbox not exposing all the
> > xsave state, so that when the kernel adds up the xsave areas,
Hi,
this just happened on an i686 machine of mine:
[ cut here ]
WARNING: CPU: 1 PID: 1384 at lib/iov_iter.c:695 copy_page_to_iter+0x240/0x3b0
Modules linked in: xfs algif_skcipher af_alg uas nfsv4 dns_resolver nfs
nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject
Hi,
this just happened on an i686 machine of mine:
[ cut here ]
WARNING: CPU: 1 PID: 1384 at lib/iov_iter.c:695 copy_page_to_iter+0x240/0x3b0
Modules linked in: xfs algif_skcipher af_alg uas nfsv4 dns_resolver nfs
nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject
On Fri, 20 Oct 2017, huang ying wrote:
> > 4 May < Linux version 4.11.2-1-ARCH
> > 4 Jun < Linux version 4.11.3-1-ARCH
> > 7 Jul < Linux version 4.11.9-1-ARCH
> > 4 Aug < Linux version 4.12.8-2-ARCH
> > 24 Sep < Linux version 4.12.13-1-ARCH
> > 158 Oct <
On Fri, 20 Oct 2017, huang ying wrote:
> > 4 May < Linux version 4.11.2-1-ARCH
> > 4 Jun < Linux version 4.11.3-1-ARCH
> > 7 Jul < Linux version 4.11.9-1-ARCH
> > 4 Aug < Linux version 4.12.8-2-ARCH
> > 24 Sep < Linux version 4.12.13-1-ARCH
> > 158 Oct <
Hi,
every now and then (and more frequently now) I receive the following
message on this Atom N270 netbook:
swap_info_get: Bad swap offset entry 0200f8a7
This started to show up a few months ago but appears to happen more
frequently now:
4 May < Linux version 4.11.2-1-ARCH
4
Hi,
every now and then (and more frequently now) I receive the following
message on this Atom N270 netbook:
swap_info_get: Bad swap offset entry 0200f8a7
This started to show up a few months ago but appears to happen more
frequently now:
4 May < Linux version 4.11.2-1-ARCH
4
On Mon, 15 May 2017, Konstantin Ryabitsev via RT wrote:
> On 2017-05-15 14:34:56, francoisvalen...@gmail.com wrote:
> > It doesn't work with Firefox-53.0. After quite a long time while
> > firefox
> > uses 100% of CPU, I finally get a text file and not a gzip file of the
> > patch for 4.12-rc1. It
On Mon, 15 May 2017, Konstantin Ryabitsev via RT wrote:
> On 2017-05-15 14:34:56, francoisvalen...@gmail.com wrote:
> > It doesn't work with Firefox-53.0. After quite a long time while
> > firefox
> > uses 100% of CPU, I finally get a text file and not a gzip file of the
> > patch for 4.12-rc1. It
On Mon, 15 May 2017, Konstantin Ryabitsev via RT wrote:
> On 2017-05-15 14:34:56, francoisvalen...@gmail.com wrote:
> > It doesn't work with Firefox-53.0. After quite a long time while
> > firefox
> > uses 100% of CPU, I finally get a text file and not a gzip file of the
> > patch for 4.12-rc1. It
On Mon, 15 May 2017, Konstantin Ryabitsev via RT wrote:
> On 2017-05-15 14:34:56, francoisvalen...@gmail.com wrote:
> > It doesn't work with Firefox-53.0. After quite a long time while
> > firefox
> > uses 100% of CPU, I finally get a text file and not a gzip file of the
> > patch for 4.12-rc1. It
On Mon, 13 Feb 2017, Kees Cook wrote:
> Okay, cool. Thanks. (Also, where does "setpriv" live? I must need a
> new set of util-linux or something?)
Indeed, a newer version of util-linux[0] should do, although
Debian/testing appears to have an extra package just for "setpriv":
On Mon, 13 Feb 2017, Kees Cook wrote:
> Okay, cool. Thanks. (Also, where does "setpriv" live? I must need a
> new set of util-linux or something?)
Indeed, a newer version of util-linux[0] should do, although
Debian/testing appears to have an extra package just for "setpriv":
Hi,
while the LZ4 and LZ4HC module appears to be available on PowerPC 32-bit
(it's a PowerBook G4), I get these warnings below during module load. The
lzo module is working just fine and I'm using it extensively for ZRAM on
that machine.
Is this a configuration[0] error or is LZ4 just not
Hi,
while the LZ4 and LZ4HC module appears to be available on PowerPC 32-bit
(it's a PowerBook G4), I get these warnings below during module load. The
lzo module is working just fine and I'm using it extensively for ZRAM on
that machine.
Is this a configuration[0] error or is LZ4 just not
anary within current task_struct from there.
>
> fixes: 6533b7c16ee57 ("powerpc: Initial stack protector
> (-fstack-protector) support")
> Reported-by: Christian Kujau <li...@nerdbynature.de>
>
> Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr>
> ---
> C
anary within current task_struct from there.
>
> fixes: 6533b7c16ee57 ("powerpc: Initial stack protector
> (-fstack-protector) support")
> Reported-by: Christian Kujau
>
> Signed-off-by: Christophe Leroy
> ---
> Christian, can you test it ?
>
> arch/powerpc/i
Hi,
after upgrading this powerpc32 box from 4.10-rc2 to -rc4, the message
below occured a few hours after boot. Full dmesg and .config:
http://nerdbynature.de/bits/4.10-rc4/
Any ideas?
Thanks,
Christian.
Faulting instruction address: 0xc02d4584
Oops: Kernel access of bad area, sig: 11
Hi,
after upgrading this powerpc32 box from 4.10-rc2 to -rc4, the message
below occured a few hours after boot. Full dmesg and .config:
http://nerdbynature.de/bits/4.10-rc4/
Any ideas?
Thanks,
Christian.
Faulting instruction address: 0xc02d4584
Oops: Kernel access of bad area, sig: 11
ing the same with GCC 5.2.0 works, even for
CC_STACKPROTECTOR_STRONG=y and the system boots just fine.
So, with that limitation, feel free to add:
Tested-by: Christian Kujau <li...@nerdbynature.de>
Thanks for the fix!
Christian.
$ gcc --version | head -1
gcc-4.9.real (Debian 4.9.2-
ing the same with GCC 5.2.0 works, even for
CC_STACKPROTECTOR_STRONG=y and the system boots just fine.
So, with that limitation, feel free to add:
Tested-by: Christian Kujau
Thanks for the fix!
Christian.
$ gcc --version | head -1
gcc-4.9.real (Debian 4.9.2-10) 4.9.2
$ g
Hi,
booting v4.10-rc2 on this PowerPC G4 machine prints the following early
on, but then continues to boot and the machine is running fine so far:
BUG: key ef0ba7d0 not in .data!
DEBUG_LOCKS_WARN_ON(1)
[ cut here ]
WARNING: CPU: 0 PID: 1 at
Hi,
booting v4.10-rc2 on this PowerPC G4 machine prints the following early
on, but then continues to boot and the machine is running fine so far:
BUG: key ef0ba7d0 not in .data!
DEBUG_LOCKS_WARN_ON(1)
[ cut here ]
WARNING: CPU: 0 PID: 1 at
On Thu, 15 Dec 2016, Jason A. Donenfeld wrote:
> > I'd still drop the "24" unless you really think we're going to have
> > multiple variants coming into the kernel.
>
> Okay. I don't have a problem with this, unless anybody has some reason
> to the contrary.
What if the 2/4-round version falls
On Thu, 15 Dec 2016, Jason A. Donenfeld wrote:
> > I'd still drop the "24" unless you really think we're going to have
> > multiple variants coming into the kernel.
>
> Okay. I don't have a problem with this, unless anybody has some reason
> to the contrary.
What if the 2/4-round version falls
On Wed, 23 Nov 2016, Michael Ellerman wrote:
> That's nothing powerpc specific AFAICS, does this fix it?
Hm, so s/printk/pr_cont/ - but not in all places? But yeah, this fixes it
for me, at least on x86.
Tested-by: Christian Kujau <li...@nerdbynature.de>
Thank you!
Christian.
&g
On Wed, 23 Nov 2016, Michael Ellerman wrote:
> That's nothing powerpc specific AFAICS, does this fix it?
Hm, so s/printk/pr_cont/ - but not in all places? But yeah, this fixes it
for me, at least on x86.
Tested-by: Christian Kujau
Thank you!
Christian.
>
> cheers
>
> d
The "Locking API testsuite" output during bootup (with
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y) on this PowerPC system looks
mangled, possibly related to the recent printk changes (4bcc595ccd80,
"printk: reinstate KERN_CONT for printing continuation lines"). Before
(e.g. with v4.6) it looked like
The "Locking API testsuite" output during bootup (with
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y) on this PowerPC system looks
mangled, possibly related to the recent printk changes (4bcc595ccd80,
"printk: reinstate KERN_CONT for printing continuation lines"). Before
(e.g. with v4.6) it looked like
For some time now, I always[0] receive a lockdep warning when there's some
disk I/O on the system. But recently the warning looks kinda mangled,
I suspect the recent printk change (4bcc595ccd80, "printk: reinstate
KERN_CONT for printing continuation lines") to be the reason for that.
In previous
For some time now, I always[0] receive a lockdep warning when there's some
disk I/O on the system. But recently the warning looks kinda mangled,
I suspect the recent printk change (4bcc595ccd80, "printk: reinstate
KERN_CONT for printing continuation lines") to be the reason for that.
In previous
[re-send]
On Mon, 8 Aug 2016, frank paulsen wrote:
> in 4.8-rc1 "make bindeb-pkg O=../debian" fails:
> | find: `scripts/gcc-plugins': No such file or directory
> | /usr/src/linus/scripts/package/Makefile:97: recipe for target
> 'bindeb-pkg' failed
>
> this is due to a missing directory
[re-send]
On Mon, 8 Aug 2016, frank paulsen wrote:
> in 4.8-rc1 "make bindeb-pkg O=../debian" fails:
> | find: `scripts/gcc-plugins': No such file or directory
> | /usr/src/linus/scripts/package/Makefile:97: recipe for target
> 'bindeb-pkg' failed
>
> this is due to a missing directory
Hi,
since 22cba31bae ("Documentation/sphinx: add basic working Sphinx
configuration and build") the following warning is emitted when running
"make help":
$ make help > /dev/null
Documentation/Makefile.sphinx:17: The 'sphinx-build' command was not
found. Make sure you have Sphinx installed
Hi,
since 22cba31bae ("Documentation/sphinx: add basic working Sphinx
configuration and build") the following warning is emitted when running
"make help":
$ make help > /dev/null
Documentation/Makefile.sphinx:17: The 'sphinx-build' command was not
found. Make sure you have Sphinx installed
On Wed, 6 Apr 2016, e...@abdsec.com wrote:
> First, I wrote your attached patch, but then I thought zeroing other
> /proc/iomem values would be better. So I changed it.
On my systems, /proc/iomem, /proc/ioports and others get their
world-readable bits removed during bootup - I guess that would
On Wed, 6 Apr 2016, e...@abdsec.com wrote:
> First, I wrote your attached patch, but then I thought zeroing other
> /proc/iomem values would be better. So I changed it.
On my systems, /proc/iomem, /proc/ioports and others get their
world-readable bits removed during bootup - I guess that would
Hello,
sometimes the Wifi adapter (Wireless-N 2230) in this Lenovo Thinkpad E431
"disappears" and cannot be fixed by re-loading the iwlwifi kernel module
either. Only a reboot will do.
When I was running 3.16.0-4-amd64 from Debian/stable, I noticed the
following message, but only _once_ and
Hello,
sometimes the Wifi adapter (Wireless-N 2230) in this Lenovo Thinkpad E431
"disappears" and cannot be fixed by re-loading the iwlwifi kernel module
either. Only a reboot will do.
When I was running 3.16.0-4-amd64 from Debian/stable, I noticed the
following message, but only _once_ and
On Thu, 20 Aug 2015, Junesung Lee wrote:
> The word "filesystem" is being used without the space.
I think both versions are acceptable:
https://en.wiktionary.org/wiki/file_system
Even though the version w/o the space appears to be more common in the
source:
$ git grep file\ system | wc -l
On Thu, 20 Aug 2015, Junesung Lee wrote:
The word filesystem is being used without the space.
I think both versions are acceptable:
https://en.wiktionary.org/wiki/file_system
Even though the version w/o the space appears to be more common in the
source:
$ git grep file\ system | wc -l
1473
On August 8, 2015 1:57:05 AM PDT, Denis Kirjanov wrote:
>On 8/7/15, Christian Kujau wrote:
>> Hi,
>>
>> this PowerBook G4 was running 3.16 for a while but now I wanted to
>upgrade
>> to latest mainline. However, durin
On August 8, 2015 1:57:05 AM PDT, Denis Kirjanov k...@linux-powerpc.org wrote:
On 8/7/15, Christian Kujau li...@nerdbynature.de wrote:
Hi,
this PowerBook G4 was running 3.16 for a while but now I wanted to
upgrade
to latest mainline. However, during bootup the following happens
Hi,
this PowerBook G4 was running 3.16 for a while but now I wanted to upgrade
to latest mainline. However, during bootup the following happens:
===
[2.237102] ata1: PATA max UDMA/100 irq 39
[2.401708] ata1.00: ATA-8: SAMSUNG HM061GC, LR100-10, max UDMA/100
[
Hi,
this PowerBook G4 was running 3.16 for a while but now I wanted to upgrade
to latest mainline. However, during bootup the following happens:
===
[2.237102] ata1: PATA max UDMA/100 irq 39
[2.401708] ata1.00: ATA-8: SAMSUNG HM061GC, LR100-10, max UDMA/100
[
led
make[2]: *** [deb-pkg] Error 1
In scripts/package/builddeb it tries to construct an email address (that
can be queried in /proc/version later on) but with no network,
the "hostname -f" fails. The following patch falls back to just use the
shortname if we cannot determine our FQDN.
Sign
]: *** [deb-pkg] Error 1
In scripts/package/builddeb it tries to construct an email address (that
can be queried in /proc/version later on) but with no network,
the hostname -f fails. The following patch falls back to just use the
shortname if we cannot determine our FQDN.
Signed-off-by: Christian Kujau
On Tue, 19 Aug 2014 at 20:13, Cong Wang wrote:
> On Tue, Aug 19, 2014 at 7:50 PM, Jiang Liu wrote:
> > Hi Kujau,
> > It seems like a different issue, something wrong with
> > void nfs_fs_proc_net_exit(struct net *net)
>
> http://marc.info/?l=linux-nfs=140821782107427=2
Thanks, that
Hi,
the warning below appeared while booting 3.17.0-rc1. I haven't seen the
warning before, but found a recent report on oops.kernel.org:
http://oops.kernel.org/oops/warning-at-fs-proc-generic-c521-remove_proc_entry0x18f-0x1a0/
and also reports from July 2014, where the issue was reported to
Hi,
the warning below appeared while booting 3.17.0-rc1. I haven't seen the
warning before, but found a recent report on oops.kernel.org:
http://oops.kernel.org/oops/warning-at-fs-proc-generic-c521-remove_proc_entry0x18f-0x1a0/
and also reports from July 2014, where the issue was reported to
On Tue, 19 Aug 2014 at 20:13, Cong Wang wrote:
On Tue, Aug 19, 2014 at 7:50 PM, Jiang Liu jiang@linux.intel.com wrote:
Hi Kujau,
It seems like a different issue, something wrong with
void nfs_fs_proc_net_exit(struct net *net)
http://marc.info/?l=linux-nfsm=140821782107427w=2
fix was attempted in November 2012, but dismissed as
rtc-sec.c
was still being worked on. Alas, it's still not there.
"MAINTAINERS: fix drivers/rtc/rtc-sec.c"
http://lkml.iu.edu/hypermail/linux/kernel/1211.2/04820.html
Cc: Sangbeom Kim
Cc: Cesar Eduardo Bar
/linux/kernel/1211.2/04820.html
Cc: Sangbeom Kim sbki...@samsung.com
Cc: Cesar Eduardo Barros ces...@cesarb.eti.br
Signed-off-by: Christian Kujau li...@nerdbynature.de
diff --git a/MAINTAINERS b/MAINTAINERS
index 7e2eb4c..7831e8d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1303,8
On Fri, 14 Feb 2014 at 12:14, Dave Chinner wrote:
> > OK, so the "possible irq lock inversion dependency detected" is a lockdep
> > regression, as you explained in the xfs-list thread. What about the
> > "RECLAIM_FS-safe -> RECLAIM_FS-unsafe lock order detected" warning - I
> > haven't seen it
On Fri, 14 Feb 2014 at 09:26, Dave Chinner wrote:
> > after upgrading from 3.13-rc8 to 3.14.0-rc2 on this PowerPC G4 machine,
> > the WARNING below was printed.
> >
> > Shortly after, a lockdep warning appeared (possibly related to my
> > post to the XFS list yesterday[0]).
>
> Unlikely.
OK,
On Thu, 13 Feb 2014 at 11:53, Christian Kujau wrote:
> after upgrading from 3.13-rc8 to 3.14.0-rc2 on this PowerPC G4 machine,
> the WARNING below was printed.
>
> Shortly after, a lockdep warning appeared (possibly related to my
> post to the XFS list yesterday[0]).
Sigh, only
Hi,
after upgrading from 3.13-rc8 to 3.14.0-rc2 on this PowerPC G4 machine,
the WARNING below was printed.
Shortly after, a lockdep warning appeared (possibly related to my
post to the XFS list yesterday[0]).
Even later in the log an out-of-memory error appeared, that may or may not
be
Hi,
after upgrading from 3.13-rc8 to 3.14.0-rc2 on this PowerPC G4 machine,
the WARNING below was printed.
Shortly after, a lockdep warning appeared (possibly related to my
post to the XFS list yesterday[0]).
Even later in the log an out-of-memory error appeared, that may or may not
be
On Thu, 13 Feb 2014 at 11:53, Christian Kujau wrote:
after upgrading from 3.13-rc8 to 3.14.0-rc2 on this PowerPC G4 machine,
the WARNING below was printed.
Shortly after, a lockdep warning appeared (possibly related to my
post to the XFS list yesterday[0]).
Sigh, only _after_ sending
On Fri, 14 Feb 2014 at 09:26, Dave Chinner wrote:
after upgrading from 3.13-rc8 to 3.14.0-rc2 on this PowerPC G4 machine,
the WARNING below was printed.
Shortly after, a lockdep warning appeared (possibly related to my
post to the XFS list yesterday[0]).
Unlikely.
OK, so the
On Fri, 14 Feb 2014 at 12:14, Dave Chinner wrote:
OK, so the possible irq lock inversion dependency detected is a lockdep
regression, as you explained in the xfs-list thread. What about the
RECLAIM_FS-safe - RECLAIM_FS-unsafe lock order detected warning - I
haven't seen it again though,
I noticed that my machine locks up quite often with 3.13.-rc3.
PowerPC G4 again, but this machine was pretty much rock solid until now:
when there's lots of disk I/O going on, the system locks up, but not
entirely: the calltrace is still written to netconsole (but not to its
local disk) and
I noticed that my machine locks up quite often with 3.13.-rc3.
PowerPC G4 again, but this machine was pretty much rock solid until now:
when there's lots of disk I/O going on, the system locks up, but not
entirely: the calltrace is still written to netconsole (but not to its
local disk) and
On Sun, 8 Dec 2013 at 22:14, Sasha Levin wrote:
> So how would you suggest to deal with the execution issue in procfs?
Files will not be executable by itsself if /proc is mounted with noexec,
as some distributions now do by default.
C.
--
BOFH excuse #14:
sounds like a Windows problem, try
On Sun, 8 Dec 2013 at 22:14, Sasha Levin wrote:
So how would you suggest to deal with the execution issue in procfs?
Files will not be executable by itsself if /proc is mounted with noexec,
as some distributions now do by default.
C.
--
BOFH excuse #14:
sounds like a Windows problem, try
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
/src/linux-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
1 - 100 of 304 matches
Mail list logo
