Re: [PATCH] mm,vmscan: only loop back if compaction would fail in all zones
On Sun, 25 Nov 2012 23:10:41 -0500, Johannes Weiner said: > From: Johannes Weiner > Subject: [patch] mm: vmscan: fix endless loop in kswapd balancing > > Kswapd does not in all places have the same criteria for when it > considers a zone balanced. This leads to zones being not reclaimed > because they are considered just fine and the compaction checks to > loop over the zonelist again because they are considered unbalanced, > causing kswapd to run forever. > > Add a function, zone_balanced(), that checks the watermark and if > compaction has enough free memory to do its job. Then use it > uniformly for when kswapd needs to check if a zone is balanced. > > Signed-off-by: Johannes Weiner > --- > mm/vmscan.c | 27 ++- > 1 file changed, 18 insertions(+), 9 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 48550c6..3b0aef4 100644 > + if (COMPACTION_BUILD && order && !compaction_suitable(zone, order)) > + return false; Applying to next-20121117,I had to hand-patch for this other apkm patch: ./Next/merge.log:Applying: mm: use IS_ENABLED(CONFIG_COMPACTION) instead of COMPACTION_BUILD Probably won't be till tomorrow before I know if this worked, it seems to take a while before the kswapd storms start hitting (appears to be a function of uptime - see almost none for 8-16 hours, after 24-30 hours I'll be having a spinning kswapd most of the time). pgpVzL1MnwzTe.pgp Description: PGP signature
Re: next-20130128 lockdep whinge in sys_swapon()
On Mon, 04 Feb 2013 10:46:38 +0900, Minchan Kim said: > Could you test this patch? > > From 81cae17c55ade897a7e06b01c864f1c250b40f8b Mon Sep 17 00:00:00 2001 > From: Minchan Kim > Date: Mon, 4 Feb 2013 10:43:32 +0900 > Subject: [PATCH] mm: Get rid of lockdep whinge on sys_swapon > > [1] forgot to initialize spin_lock so lockdep is whingeing > about it. This patch fixes it. > > [1] 0f181e0e4, swap: add per-partition lock for swapfile > > Cc: Shaohua Li > Reported-by: Valdis Kletnieks > Signed-off-by: Minchan Kim I applied this to a next-20130128, and lockdep doesn't complain about swapon(). Feel free to add a 'Tested-By:' to the patch and push it upstream... pgpBEpZg_pp7R.pgp Description: PGP signature
Re: next-20130117 - kernel BUG with aio
On Thu, 31 Jan 2013 16:37:27 -0800, Kent Overstreet said: > On Thu, Jan 31, 2013 at 01:59:52PM -0800, Andrew Morton wrote: > > Did this get fixed? > With the patches I sent you, yes - not seeing a new linux-next tree yet? Well, it's a mixed bag at my end. Finally got a chance to do some more testing, and: 1) next-20130128 didn't show anything in dmesg, but my VirtualBox Windows 7 images appear to livelock on the way up - the Windows throbber would keep going, but it never made any actual progress towards booting. (Part of the delay was fixing a next-20121224 environment, and then discovering it took Windows *two* reboot cycles to get its act back together after getting into that hung state). 2_ next-20130128 plus the following 3 patches: Subject: [PATCH 1/3] aio: Fix a null pointer deref in batch_complete_aio Subject: [PATCH 3/3] aio-use-cancellation-list-lazily-fix Subject: [PATCH 2/3] aio-kill-ki_retry-fix-fix VirtualBox appears to be functional (I did 2 complete boot/shutdown sequences of both a 32-bit and 64-bit Win7 Enterprise image). *HOWEVER*, I saw 3 of these in dmesg: [ 668.278624] WARNING: at fs/aio.c:348 put_ioctx+0x1c0/0x241() [ 668.278652] Call Trace: [ 668.278660] [] warn_slowpath_common+0x7c/0x96 [ 668.278665] [] warn_slowpath_null+0x15/0x17 [ 668.278669] [] put_ioctx+0x1c0/0x241 [ 668.278673] [] sys_io_destroy+0x4c/0x5c [ 668.278679] [] system_call_fastpath+0x16/0x1b and the code there says: WARN_ON(atomic_read(&ctx->reqs_available) > ctx->nr); which leaves me wondering exactly how we exited the while loop just above - is the intention that it loop until reqs_available == ctx->nr exactly? Looks like if 'avail' is anything other than exactly 1 in that while loop, we can be at a state where reqs_avail == (ctx->nr -1), get 'avail=2', do the atomic_add, fall out of the loop, and trigger the WARN_ON. Damned if I see how that can happen though pgpECgywwbEgu.pgp Description: PGP signature
Re: next-20130117 - kernel BUG with aio
On Tue, 05 Feb 2013 09:20:15 -0800, Kent Overstreet said: > On Tue, Feb 05, 2013 at 10:53:00AM -0500, valdis.kletni...@vt.edu wrote: > > On Thu, 31 Jan 2013 16:37:27 -0800, Kent Overstreet said: > > > On Thu, Jan 31, 2013 at 01:59:52PM -0800, Andrew Morton wrote: > > > > Did this get fixed? > > > > > With the patches I sent you, yes - not seeing a new linux-next tree yet? > > > > Well, it's a mixed bag at my end. Finally got a chance to do some more > > testing, and: > > > > 1) next-20130128 didn't show anything in dmesg, but my VirtualBox Windows 7 > > images appear to livelock on the way up - the Windows throbber would keep > > going, but it never made any actual progress towards booting. (Part of the > > delay was fixing a next-20121224 environment, and then discovering it > > took Windows *two* reboot cycles to get its act back together after getting > > into that hung state). > > > > 2_ next-20130128 plus the following 3 patches: > > > > Subject: [PATCH 1/3] aio: Fix a null pointer deref in batch_complete_aio > > Subject: [PATCH 3/3] aio-use-cancellation-list-lazily-fix > > Subject: [PATCH 2/3] aio-kill-ki_retry-fix-fix > > The "smoosh struct kiocb" patch also needs to be dropped. That causes > aio_rw_vect_retry() to check ki_nbytes/ki_left after they've been > overwritten by aio_complete(), which causes it to return an error when > it shouldn't have, which causes aio_run_iocb() to double complete the > iocb causing put_reqs_available() to be called twice and the count > screwed up. Unfortunately, that's not a clean slam-dunk revert: [/usr/src/linux-next] patch -p1 -R --dry-run < ~/Downloads/32-32-aio-Smoosh-struct-kiocb.patch checking file fs/aio.c Hunk #1 FAILED at 570. Hunk #2 FAILED at 634. Hunk #3 FAILED at 1246. 3 out of 3 hunks FAILED checking file include/linux/aio.h Hunk #1 succeeded at 31 (offset 11 lines). Looks like the above 3 patches introduce conflicts. Not sure what the proper resolution is for some of it. For the first hunk, the smoosh patch has near line 590: - atomic_set(&req->ki_users, 1); + memset(req, 0, offsetof(struct kiocb, ki_ctx)); req->ki_ctx = ctx; + atomic_set(&req->ki_users, 1); return req; but after the 3 patches, I have: memset(req, 0, offsetof(struct kiocb, ki_ctx)); req->ki_ctx = ctx; atomic_set(&req->ki_users, 2); return req; Easy to fix, except that '2' is too magical for me to understand, so I'm not sure I want to smash it to a 1 to make the revert easier. :) pgpXc1R2ESUQf.pgp Description: PGP signature
Re: next-20130117 - kernel BUG with aio
On Tue, 05 Feb 2013 09:20:15 -0800, Kent Overstreet said: > The "smoosh struct kiocb" patch also needs to be dropped. That causes > aio_rw_vect_retry() to check ki_nbytes/ki_left after they've been > overwritten by aio_complete(), which causes it to return an error when > it shouldn't have, which causes aio_run_iocb() to double complete the > iocb causing put_reqs_available() to be called twice and the count > screwed up. Hooray! linux-next-20130206 builds, boots, and VirtualBox 4.2.6 runs without producing any kernel messages. Feel free to add the following as appropriate to this version of the patch series: Reported-By: Valdis Kletnieks Tested-By: Valdis Kletnieks pgpGD5YRIwtzr.pgp Description: PGP signature
next-20130206 cpufreq - WARN in sysfs_add_one
Seen in dmesg. next-20130128 was OK. Haven't done a bisect, but can do so if the offender isn't obvious... [2.567662] netconsole: network logging started [2.581661] [ cut here ] [2.581670] WARNING: at fs/sysfs/dir.c:536 sysfs_add_one+0x91/0xa5() [2.581673] Hardware name: Latitude E6500 [2.581676] sysfs: cannot create duplicate filename '/devices/system/cpu/cpufreq/ondemand' [2.581678] Modules linked in: [2.581684] Pid: 1, comm: swapper/0 Tainted: GW 3.8.0-rc6-next-20130206 #57 [2.581687] Call Trace: [2.581693] [] ? sysfs_add_one+0x91/0xa5 [2.581700] [] warn_slowpath_common+0x7c/0x96 [2.581706] [] warn_slowpath_fmt+0x47/0x49 [2.581711] [] sysfs_add_one+0x91/0xa5 [2.581716] [] create_dir+0x6b/0xa4 [2.581721] [] sysfs_create_subdir+0x17/0x19 [2.581727] [] internal_create_group+0xd4/0x1df [2.581732] [] sysfs_create_group+0xe/0x10 [2.581739] [] cpufreq_governor_dbs+0x209/0x475 [2.581744] [] od_cpufreq_governor_dbs+0x15/0x17 [2.581750] [] __cpufreq_governor+0x61/0xb5 [2.581755] [] __cpufreq_set_policy+0x104/0x140 [2.581761] [] cpufreq_add_dev_interface+0x217/0x261 [2.581767] [] ? cpufreq_update_policy+0x133/0x133 [2.581773] [] cpufreq_add_dev+0x222/0x2d7 [2.581780] [] subsys_interface_register+0xa3/0xd7 [2.581786] [] ? _raw_spin_unlock_irqrestore+0x72/0x80 [2.581792] [] cpufreq_register_driver+0x9c/0x13b [2.581799] [] ? cpufreq_gov_dbs_init+0x2c/0x2c [2.581805] [] acpi_cpufreq_init+0x7b/0x185 [2.581811] [] do_one_initcall+0x7a/0x130 [2.581817] [] kernel_init_freeable+0x15e/0x1df [2.581822] [] ? do_early_param+0x88/0x88 [2.581828] [] ? rest_init+0x12c/0x12c [2.581833] [] kernel_init+0x9/0xd1 [2.581839] [] ret_from_fork+0x7c/0xb0 [2.581844] [] ? rest_init+0x12c/0x12c [2.581847] ---[ end trace a0eea8e0db3a3905 ]--- [2.585909] ALSA device list: [2.585913] #0: HDA Intel at 0xf6fdc000 irq 48 [2.590781] Freeing unused kernel memory: 852k freed pgpB5CUjEu16m.pgp Description: PGP signature
Re: next-20130206 cpufreq - WARN in sysfs_add_one
On Wed, 06 Feb 2013 22:24:39 +0100, "Rafael J. Wysocki" said: > On Wednesday, February 06, 2013 12:44:35 PM Valdis Kletnieks wrote: > > Seen in dmesg. next-20130128 was OK. Haven't done a bisect, but can > > do so if the offender isn't obvious... > > I suppose this is 73bf0fc "cpufreq: Don't remove sysfs link for policy->cpu". > > Can you test the linux-pm.git/pm-cpufreq branch alone, please, and see > if that's this one (top-most commit)? Color me mystified. I can't find that commit by either number or the description: [/usr/src/linux-next] git log | egrep -i 'cpufreq.*remove.*link' [/usr/src/linux-next] git log | grep -i 73bf0fc [/usr/src/linux-next] Was that a very recent commit that may have gotten pushed too late for the next-20130206 merge? pgpXAg3Xi6a9E.pgp Description: PGP signature
Re: pr_info not printing message in /var/log/messages
On Thu, 07 Feb 2013 23:20:27 +0530, anish kumar said: > Other insteresting standard logs managed by syslog > are /var/log/auth.log, /var/log/mail.log. Other interesting *common* logs, as shipped pre-configured by some distros. They are hardly a "standard" (unless the definitions of these managed to sneak into Posix or the LSB or similar while I wasn't looking). pgpGcX_H_no0M.pgp Description: PGP signature
Re: next-20130206 cpufreq - WARN in sysfs_add_one
On Thu, 07 Feb 2013 13:11:52 +0530, Viresh Kumar said: > First of all i want to confirm something about your system. I am sure it is a > multi-policy system (or multi cluster system). i.e. there are more than one > clock line for different cpus ? And so multiple struct policy exist > simultaneously. Hmm.. it's a bog-standard Dell Latitude E6500 laptop, with a single Core2 Duo P8700 CPU (one die, 2 cores, no HT). It's apparently able to clock both cores at different speeds (one core running busy at 2540mhz and the other idling at 800mhz), if that's what you mean by multiple clock lines. In any case, next-20130206 complained, and with this patch added I see nothing in dmesg and cpufreq is acting properly on both cores, so: Tested-By: Valdis Kletnieks (btw - I had to hand-apply your patch, as it showed up white-space damaged. Three lines wrapped, and tabs converted to spaces). pgpgR4nEeJJ_l.pgp Description: PGP signature
Re: [patch] TTY: synclink, small cleanup in dtr_rts()
On Sun, 27 Jan 2013 23:19:47 +0300, Dan Carpenter said: > Yeah. I think it would be, but adding bitflags together instead of > doing bitwise ORs is very common as well. The fact it's common doesn't mean it's good programming practice, or even correct. Consider: #define F_FOO 0x01 #define F_BAR 0x02 #define F_BAZ 0x04 unsigned int flags = F_FOO; ... flags |= F_BAR; Now some time later, another code path does this: flags += F_FOO; If it was another |, it would be a no harm no foul class of bug. But how long is it going to take you to figure out who set F_BAZ? I wonder if there's a way to write a coccinelle patch to find places where we do arithmetic operations on bitmasks pgpz7yUVpK98R.pgp Description: PGP signature
Re: boot warnings due to swap: make each swap partition have one address_space
On Sun, 27 Jan 2013 13:40:40 -0800, Hugh Dickins said: > My reservations so far would be: how many installations actually have > more than one swap area, so is it a good tradeoff to add more overhead > to help those at the (slight) expense of everyone else? The increasingly > ugly page_mapping() worries me, and the static array of swapper_spaces > annoys me a little. Right now, probably few. But the number may go up a lot if the whole 'zram-for-swapspace' thing catches on and/or ships in a distro... pgpqA5wagdB_3.pgp Description: PGP signature
next-20130128 lockdep whinge in sys_swapon()
Seen in my linux-next dmesg. I'm suspecting commit ac07b1ffc: commit ac07b1ffc27d575013041fb5277dab02c661d9c2 Author: Shaohua Li Date: Thu Jan 24 13:13:50 2013 +1100 swap: add per-partition lock for swapfile as (a) it was OK in -20130117, and (b) 'git blame mm/swapfile.c | grep 2013' shows that commit as the vast majority of changes. [ 42.498669] INFO: trying to register non-static key. [ 42.498670] the code is fine but needs lockdep annotation. [ 42.498671] turning off the locking correctness validator. [ 42.498674] Pid: 1035, comm: swapon Not tainted 3.8.0-rc5-next-20130128 #52 [ 42.498675] Call Trace: [ 42.498681] [] register_lock_class+0x103/0x2ad [ 42.498685] [] ? __list_add_rcu+0xc4/0xdf [ 42.498688] [] __lock_acquire+0x108/0xd63 [ 42.498691] [] ? trace_preempt_on+0x12/0x2f [ 42.498695] [] ? sub_preempt_count+0x31/0x43 [ 42.498699] [] ? sys_swapon+0x6f9/0x9d9 [ 42.498701] [] lock_acquire+0xc7/0x14a [ 42.498703] [] ? sys_swapon+0x725/0x9d9 [ 42.498706] [] _raw_spin_lock+0x34/0x41 [ 42.498708] [] ? sys_swapon+0x725/0x9d9 [ 42.498710] [] sys_swapon+0x725/0x9d9 [ 42.498712] [] ? trace_hardirqs_on_caller+0x149/0x165 [ 42.498715] [] system_call_fastpath+0x16/0x1b [ 42.498719] Adding 2097148k swap on /dev/mapper/vg_blackice-swap. Priority:-1 extents:1 across:2097148k Somebody care to sprinkle the appropriate annotations on that code? pgputFVL40ecB.pgp Description: PGP signature
Re: next-20130117 - kernel BUG with aio
On Wed, 23 Jan 2013 20:10:03 +0800, Hillf Danton said: > Try again? > --- > > --- a/fs/aio.cTue Jan 22 21:37:54 2013 > +++ b/fs/aio.cWed Jan 23 20:06:14 2013 Now seeing this: [ 2941.495370] [ cut here ] [ 2941.495379] WARNING: at fs/aio.c:336 put_ioctx+0x1cb/0x252() Same warn location, but different traceback? [ 2941.495407] Call Trace: [ 2941.495415] [] warn_slowpath_common+0x7e/0x97 [ 2941.495419] [] warn_slowpath_null+0x15/0x17 [ 2941.495423] [] put_ioctx+0x1cb/0x252 [ 2941.495428] [] ? sub_preempt_count+0x33/0x46 [ 2941.495433] [] ? abort_exclusive_wait+0x89/0x89 [ 2941.495438] [] kill_ioctx_work+0x27/0x2b [ 2941.495443] [] process_one_work+0x26f/0x4be [ 2941.495447] [] ? process_one_work+0x1a9/0x4be [ 2941.495453] [] ? spin_lock_irq+0x9/0xb [ 2941.495457] [] worker_thread+0x1b6/0x28e [ 2941.495461] [] ? rescuer_thread+0x1a5/0x1a5 [ 2941.495466] [] kthread+0x9d/0xa5 [ 2941.495471] [] ? __kthread_parkme+0x60/0x60 [ 2941.495475] [] ret_from_fork+0x7c/0xb0 [ 2941.495479] [] ? __kthread_parkme+0x60/0x60 [ 2941.495483] ---[ end trace 8e545cd216c853ec ]--- Obviously VirtualBox 4.2.6 on my laptop is going out of its way to get indigestion at this patch series. :) pgpDTJaDIY9S5.pgp Description: PGP signature
Re: [RFC] Hack to use mkdir/rmdir in debugfs
On Tue, 22 Jan 2013 23:44:09 -0500, Steven Rostedt said:
> Again, I want to stress that this doesn't touch the debugfs code. Here's
> the real change that I've been testing. It includes the code for the
> "new" and "free" files but those are not created because of an early
> 'return' I added. Notice that it's all contained in
> kernel/trace/trace.c.
So I was looking through here, and something caught my eye
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 253cb51..851eb4a 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> +static int instance_mkdir (struct inode *inode, struct dentry *dentry, umode
_t mode)
> +{
> + struct dentry *parent;
> + int ret;
> +
> + /* Paranoid: Make sure the parent is the "instances" directory */
> + parent = hlist_entry(inode->i_dentry.first, struct dentry, d_alias);
> + if (WARN_ON_ONCE(parent != trace_instance_dir))
> + return -ENOENT;
> +
> + /*
> + * The inode mutex is locked, but debugfs_create_dir() will also
> + * take the mutex. As the instances directory can not be destroyed
> + * or changed in any other way, it is safe to unlock it, and
> + * let the dentry try. If two users try to make the same dir at
> + * the same time, then the new_instance_create() will determine the
> + * winner.
> + */
> + mutex_unlock(&inode->i_mutex);
> +
> + ret = new_instance_create(dentry->d_iname);
> +
> + mutex_lock(&inode->i_mutex);
> +
> + return ret;
> +}
> +
> +static int instance_rmdir(struct inode *inode, struct dentry *dentry)
> +{
> + struct dentry *parent;
> + int ret;
> +
> + /* Paranoid: Make sure the parent is the "instances" directory */
> + parent = hlist_entry(inode->i_dentry.first, struct dentry, d_alias);
> + if (WARN_ON_ONCE(parent != trace_instance_dir))
> + return -ENOENT;
> +
> + /* The caller did a dget() on dentry */
> + mutex_unlock(&dentry->d_inode->i_mutex);
> +
> + /*
> + * The inode mutex is locked, but debugfs_create_dir() will also
> + * take the mutex. As the instances directory can not be destroyed
> + * or changed in any other way, it is safe to unlock it, and
> + * let the dentry try. If two users try to make the same dir at
> + * the same time, then the instance_delete() will determine the
> + * winner.
> + */
> + mutex_unlock(&inode->i_mutex);
Looks like the rmdir comment was slice-n-miced from the mkdir one?
What exactly *are* the race condition rules here, especially for mkdir
racing against an rmdir?
pgpK8IjGoiDPc.pgp
Description: PGP signature
Re: [Consult] Plan: personal contributes plan for 2013
On Wed, 23 Jan 2013 19:32:41 +0800, Chen Gang said: > Plan Details: > > 10 patches per month: (at least) Even Dave Miller only averages 12-15 patches a month, and he does it for a living, and they're all in the one part of the kernel he maintains. It's going to be a really hard time for a newcomer to get up to speed enough to produce a useful and usable patch every 3 days on the average, especially across multiple areas of the kernel. More realistic goal: 1) Get a patch accepted. 2) Get another patch accepted. 3) Re-evaluate how many patches you can actually do. pgpcb4Il6vrWc.pgp Description: PGP signature
Web10g TCP statistics patch - mainlining into kernel?
I had a user who's working on tuning high-performance network file systems what the chances of upstreaming the Web10G patch to provide the RFC4898 TCP Extended Statistics MIB via netlink. Yes, it's a tad on the intrusive side, and there's performance costs attached - but so are a lot of *other* things that people use all the time for kernel debugging, and it's a zero-hit thing for people who don't choose to configure it into their kernel. The added detailed status available from this will be useful for people who are doing tuning and development (consider how useful this would have been for the people who wrote the codel line discipline as part of the bufferbloat project). I'm willing to do the not-so-heavy lifting of getting the existing patch cleaned up to upstream standards and sheparded through the process, if there's any interest at all pgpx0TnJaVrV1.pgp Description: PGP signature
Re: [Web10g-user] Web10g TCP statistics patch - mainlining into kernel?
On Fri, 25 Jan 2013 10:38:59 -0800, Dominic Hamon said: > Hello Valdis > > I actually just finished patching a fork from the kernel github repo here: > https://github.com/dominic-mlab/linux with a view to pushing it up. I > haven't pushed a patch upstream before, so any guidance is welcome. A quick browse over that git repo looks like it's unfortunately a tad busticated - you've apparently got development on the 'master' branch, instead of starting a separate branch. This effectively means that it can't be easily pulled upstream. Fortunately, you only have one commit against it so far, so you can probably recover by rejecting that commit so you're back to a Linus tree, and then create a branch and do subsequent development there. Question for the netdev people - you prefer pull requests based off a Linus tree, or linux-next, davem/(net,net-next), or some other tree? pgpzc7kUuoQYm.pgp Description: PGP signature
Re: [Web10g-user] Web10g TCP statistics patch - mainlining into kernel?
On Fri, 25 Jan 2013 14:34:57 -0500, rapier said: > My name is Chris Rapier and I'm on the Web10G dev team. We are > interested in moving this into consideration for the mainline Linux > kernel, in fact it's the primary goal of this project. We haven't > brought this to the linux kernel community as of yet as we've not > completed the quantification of performance/memory impact versus a > vanilla baseline as of yet. I already looked over the patch and it looks *fairly* sane. Having said that, the best way to proceed for the performance side is probably to get some rough ballpark numbers and then get the patch into a state that's upstream-able before doing the final measurements (because there's actually a high likelihood that the final numbers will end up being dependent on the exact details of the patch, plus having more eyeballs on it from the netdev side may shake out better approaches). Sorry if you've already done all that - I didn't see much evidence of it from the web10g-user archives... pgpYHZzdZ8fvb.pgp Description: PGP signature
Re: [PATCH] [x86]: Compiler Option Os is better on latest x86
On Fri, 25 Jan 2013 09:11:01 -0500, ling.ma.prog...@gmail.com said: > Based on above reasons, we compiled linux kernel 3.6.9 with O2 and Os > respectively. The results show Os improve performance netperf 4.8%, > 2.7% for volano as below Am I allowed to NAK this? What the numbers given so far *actually* show is 4.8% more instructions executed, *not* 4.8% better performance. I'm having a *very* hard time convincing myself that what we're seeing isn't simply the expected behavior of loops *not* being unrolled and similar non-optimizations done by -Os, so more instructions get executed to do the same amount of work. Rather than "run for 10 seconds and count instructions", can we "run for 50,000 syscalls and count clock time" or similar that shows an *actual* improvement? pgpZXQFuHkHPj.pgp Description: PGP signature
kernel/signal.c - fix suboptimal printk usage
Several printk's were missing KERN_INFO and KERN_CONT flags.
In addition, a printk that was outside a #if/#endif should have
been inside, which would result in stray blank line on non-x86 boxes.
Signed-off-by: Valdis Kletnieks
--- linux-next/kernel/signal.c.orig 2013-02-15 19:09:29.451843219 -0500
+++ linux-next/kernel/signal.c 2013-02-18 14:04:33.423065822 -0500
@@ -1157,11 +1157,11 @@ static int send_signal(int sig, struct s
static void print_fatal_signal(int signr)
{
struct pt_regs *regs = signal_pt_regs();
- printk("%s/%d: potentially unexpected fatal signal %d.\n",
+ printk(KERN_INFO "%s/%d: potentially unexpected fatal signal %d.\n",
current->comm, task_pid_nr(current), signr);
#if defined(__i386__) && !defined(__arch_um__)
- printk("code at %08lx: ", regs->ip);
+ printk(KERN_INFO "code at %08lx: ", regs->ip);
{
int i;
for (i = 0; i < 16; i++) {
@@ -1169,11 +1169,11 @@ static void print_fatal_signal(int signr
if (get_user(insn, (unsigned char *)(regs->ip + i)))
break;
- printk("%02x ", insn);
+ printk(KERN_CONT "%02x ", insn);
}
}
+ printk(KERN_CONT "\n");
#endif
- printk("\n");
preempt_disable();
show_regs(regs);
preempt_enable();
pgpEQNtUbUBkN.pgp
Description: PGP signature
next-20130206 x86_64- high CPU usage, spinlock issue
Over the weekend, I had a number of occurrences of my laptop becoming unresponsive for periods of up to several minutes. gkrellm monitors showed near 100% system time for both CPUs (and the way X and other userspace programs were behaving was consistent with them being starved for CPU for extended periods - at one point gkrellm was unable to update the display for over 4 minutes). The problem would hit, everything would get sluggish/stop for anywhere from 15 seconds or so to several minutes - and then it would just as mysteriously go away for no apparent reason, only to return a bit later... The only other clue I was able to get was running 'perf top' to see where the CPU was going - anytime the kernel was in this state, I'd see the top two entries were consistently delay_tsc and do_raw_read_lock: 25.29% [kernel][k] delay_tsc 23.47% [kernel][k] do_raw_read_lock 8.01% [kernel][k] ext4_es_reclaim_extents_count 7.44% [kernel][k] ftrace_likely_update 2.80% [kernel][k] lock_release 2.79% [kernel][k] do_raw_read_unlock 2.65% [kernel][k] lock_acquire 15.33% [kernel][k] delay_tsc 14.02% [kernel][k] do_raw_read_lock 6.80% libc-2.17.so[.] re_search_internal 5.55% libmagic.so.1.0.0 [.] 0xaf9a 5.16% [kernel][k] ftrace_likely_update 4.79% [kernel][k] ext4_es_reclaim_extents_count 22.94% [kernel][k] delay_tsc 19.84% [kernel][k] do_raw_read_lock 6.92% [kernel][k] ext4_es_reclaim_extents_count 6.79% [kernel][k] ftrace_likely_update 2.62% libc-2.17.so[.] re_search_internal I'm not sure why ext4_es-reclaim_extents_count appears a lot - the workload that was running at the time was seeing some memory pressure due to a large Firefox process, and a 'find | xargs file' command causing a lot of inode and data read I/O, but there shouldn't have been a lot of reclaims of extents as not much was being written anyplace? I can try to reproduce the issue - any suggestions how to efficiently tell who/what is doing the contending in do_raw_read_lock? pgprst4VpzUOb.pgp Description: PGP signature
Wonky PS2-USB converter issues...
Quite some time ago, I posted about a problematic PS2-USB converter that I used to connect an old PS2-connector keyboard to my laptop dock, where the keyboard wouldn't be recognized at boot unless I unplugged and reconnected it. Well, I've recently figured out (partly by obtaining a converter from a different vendor) that the converters both work correctly when plugged into a USB port that's physically on my Dell Latitude laptop - but they have issues and require a reconnect cycle when plugged into the docking station for the laptop. (It took a long time to figure this out, because *of course* you plug this sort of stuff into the docking station specifically so you don't have to plug it in every morning). So obviously, it isn't the converter that is the problem, but the docking station is doing "something stupid". Anybody have suggestions on figuring out what it's doing wrong? pgprKj6eZe38H.pgp Description: PGP signature
Re: Wonky PS2-USB converter issues...
On Wed, 20 Feb 2013 16:07:49 -0800, Greg Kroah-Hartman said: > PS-2 connectors can not normally handle hotplugging, the protocol > doesn't allow it, and for some unlucky devices, it could actually fry > the motherboard or the PS-2 device. > > So that's probably the issue here, the device just doesn't support it, > sorry. You mis-understood the problem. This works: PS/2 keyboard plugged into this device: Bus 006 Device 002: ID 0e8f:0020 GreenAsia Inc. USB to PS/2 Adapter USB side of device plugged into USB port on the Latitude laptop. Power up, boot - the keyboard works. If you plug the USB side of the GreenAsia adapter into a USB slot on the dock, the keyboard is dead and not recognized by the system. However, replugging the USB, or unplug/plug the PS/2 side, and it becomes recognized and starts working. This tells me that the dock is doing something busted with USB that the laptop does correctly, and not enumerating devices until something happens to whack it upside the head. I was hoping to identify it and maybe quirk it. pgpnMBk2nq6Ub.pgp Description: PGP signature
Re: ndiswrapper and GPL-only symbols redux
On Wed, 30 Jan 2008 14:43:27 EST, Lennart Sorensen said: > On Wed, Jan 30, 2008 at 08:45:38PM +0200, Adrian Bunk wrote: > > http://www.jbb.de/judgment_dc_munich_gpl.pdf > > http://www.jbb.de/judgment_dc_frankfurt_gpl.pdf > > Good point. They seem to be the place that actually has enforced the > GPL. An alternate reading is that it's the only place that has a legal system so whacked that a case actually went to trial rather than the offending party just going "Oh foo.. yeah, that *is* what it says, we better comply in one way or another"... It all depends what sort of legal system you have/want - I saw a statistic for our local police department that said that 98% of all their cases last year ended in plea agreements before going to trial (although to be fair, that includes traffic violations where the driver just paid the fine before the trial date came up and similar minor cases). If things actually go to trial all the time, things get even more bogged down than they already are... pgpExNBoWuctk.pgp Description: PGP signature
Re: 2.6.24-mm1
On Sun, 03 Feb 2008 17:16:34 PST, Andrew Morton said: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24/2.6.24-mm1/ Builds, boots, mostly seems to run for limited testing. One note - the following commit(s) (and related CPA reworking) broke the NVidia binary driver (which is OK, I can fix *that* part). But can somebody explain if this should have seen a trip through the -mm tree before it hit mainstream? I didn't see these in 24-rc8-mm1: commit af1e6844d60057774910a2d08bd75b67d73ba7d5 Author: Thomas Gleixner <[EMAIL PROTECTED]> Date: Wed Jan 30 13:34:08 2008 +0100 x86: cpa: rename global_flush_tlb() to cpa_flush_all() commit d1028a154c65d7fadd1b2d0276c077014d401ec7 Author: Arjan van de Ven <[EMAIL PROTECTED]> Date: Wed Jan 30 13:34:07 2008 +0100 x86: make various pageattr.c functions static pgpwJbqtirz0L.pgp Description: PGP signature
Re: [PATCH] regmap: silence GCC warning
On Mon, 01 Oct 2012 11:03:21 +0100, Mark Brown said:
> On Sun, Sep 30, 2012 at 12:15:55PM +0200, Paul Bolle wrote:
> > Building regmap.o triggers this GCC warning:
> > drivers/base/regmap/regmap.c: In function âregmap_raw_readâ:
> > drivers/base/regmap/regmap.c:1172:6: warning: âretâ may be used
> > uninitialized in this function [-Wmaybe-uninitialized]
> >
> > It seems 'ret' should always be set when this function returns. See, the
> > else-branch can leave 'ret' uninitialized only if 'val_count' is zero.
> > But if 'val_count' is zero regmap_volatile_range() will return true.
I've not dug into it that deeply - is there a way that gcc is able to intuit
this fact and use it for flow analysis? If not, it's not going to be able to
include that information in its analysis.
> > That implies that 'ret' will be set in the if-branch. ('val_count' could
> > be zero if 'val_len' is, for example, zero. That would be useless input,
> > however.)
But gcc doesn't know what "useless input" means, semantically.
> > Anyhow, initializing 'ret' to -EINVAL silences GCC and is harmless.
>
> Have you reported this bug in GCC? Their flow analyis just seems to
> keep on getting worse and worse.
I'm not convinced that it's at fault in this particular case...
pgpxWnEN9X2Ta.pgp
Description: PGP signature
Re: Out of memory on 3.5 kernels
On Wed, 03 Oct 2012 23:23:11 +0200, Nico Schottelius said: > does anyone of you have a clue so far what may be causing the huge > slab usage? > > I've just found an interesting detail: umounting and cryptsetup > luksClosing frees up the used memory (not sure which one was freeing > up) For what it's worth, I'm seeing a similar problem in linux-next on my laptop - trying to run a backup to an external hard drive that has a LUKS partition on it will OOM. (For some reason having the external LUKS partition is much more problematic than the LVM-on-LUKS on the internal drive) I've started bisecting, and gotten this far: % git bisect log git bisect start # bad: [1aa44772a621e8547dc4db41b47c747469fe0ea3] Add linux-next specific files for 20121001 git bisect bad 1aa44772a621e8547dc4db41b47c747469fe0ea3 # good: [fea7a08acb13524b47711625eebea40a0ede69a0] Linux 3.6-rc3 git bisect good fea7a08acb13524b47711625eebea40a0ede69a0 # good: [526c4d73327f56f83da8b8088fd0b3c7be38c7ae] Merge remote-tracking branch 'regulator/for-next' git bisect good 526c4d73327f56f83da8b8088fd0b3c7be38c7ae # good: [961d70d88557405c5b7302c7d87752566468f035] Merge remote-tracking branch 'tty/tty-next' git bisect good 961d70d88557405c5b7302c7d87752566468f035 (That's as far as I've gotten that I trust, the next bisect hits a different problem where connecting the hard drive and *starting* cryptLuks hangs the machine hard, so I'll have to finish bisecting that problem first, then return to bisecting this one) I admit not being sure why you see it on a 3.5 kernel, but I only see it on stuff that's after 3.6-rc3. pgpq6wV20U4GX.pgp Description: PGP signature
Re: Linux 3.5-rc7
On Sun, 30 Sep 2012 14:54:07 +0200, Uwaysi Bin Kareem said: > Compiled 3.6-rc7, with a hz timer of 3956 for a "natural" psychovisual > profile jitter level in OpenGL, and a shaved config for minimal jitter. I'll bite - how did you measure the difference between 3956 and 4000? The other stuff in your note sounds sane, but I'm having a hard time believing that 3956 was arrived at in any sort of systematic or measured way - it smells like cargo cult programming to me... pgpf6TvAnh1w8.pgp Description: PGP signature
Re: [PATCH] MM: Support more pagesizes for MAP_HUGETLB/SHM_HUGETLB v6
On Mon, 22 Oct 2012 08:36:33 -0700, Andi Kleen said: > Thinking about it more PowerPC has a 16GB page, so we probably > need to move this to prot. Gaak - is that a typo? If not, what is the use case - allowing a small number of pages to cover all memory, with big wins on TLB hit ratios? I certainly can't see it as a sane primitive for a virtual memory design that does paging/swapping? pgpkfVdjjgwsa.pgp Description: PGP signature
Re: [PATCH 000/193] remove CONFIG_EXPERIMENTAL
On Tue, 23 Oct 2012 13:01:13 -0700, Kees Cook said: > This config item has not carried much meaning for a while now and is > almost always enabled by default (especially in distro builds). As agreed > during the Linux kernel summit, it should be removed. > > As such, this is the patch series for removing CONFIG_EXPERIMENTAL, > with the hopes of all the various maintainers pulling these changes into > their trees. I'm carrying the first patch (that makes CONFIG_EXPERIMENTAL > "default y") in my linux-next tree, so builds there will see the impact > immediately. Has anybody tested what happens if you're doing a git bisect that ends up crossing back and forth across the commit for this? I've been burned before when stuff evaporates out of my .config during a bisect when an option grows/loses a 'depends on' clause. pgpncurtuHQsH.pgp Description: PGP signature
Re: [PATCH] USB: mark USB drivers as being GPL only
On Sun, 10 Feb 2008 05:50:17 +0100, Marcel Holtmann said: > go ahead and create an application that uses a GPL only library. Then > ask a lawyer if it is okay to distribute your application in binary only > form without making the source code available (according to the GPL). > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfLibraryIsGPL > > http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#LinkingWithGPL What happens if I ship a binary-only program that uses *either* a GPL library or a custom library with the same API? "If you don't have the Frobozz-Foo library, you'll have to supply your own work-alike" (Note that this is in fact the *usual* case - very few programs actually check that they are linking against a Genuine GPL(tm) library, they just want the *API*, so providing a work-alike is sufficient) pgpH13BophsVN.pgp Description: PGP signature
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said: > Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are appearing > to > indicate its not a problem until some distro actually ships a kernel with the > changes that broke it. That could be months or even a year plus. Actually following the NVidia forums indicates otherwise: http://www.nvnews.net/vbulletin/showthread.php?t=107144 I expect Zander will be posting a patch rather soonish, for some value of soonish. And if you're running a -rc or -mm kernel, patching the 169.09 drivers should be well within your abilities -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Thu, 14 Feb 2008 12:32:29 PST, Greg KH said: > How about "weeks". Both Fedora and openSUSE's next release is going to > be based on 2.6.25, and the first round of -rc1 kernels should be > showing up in their trees in a few days. So for this instance, I think > you will be fine :) a few days == *NOW* kernel-2.6.25-0.40.rc1.git2.fc9.x86_64 is in Fedora Rawhide already. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Announce: Linux-next (Or Andrew's dream :-))
On Fri, 15 Feb 2008 04:26:45 EST, Gene Heskett said: > On Friday 15 February 2008, [EMAIL PROTECTED] wrote: > >On Thu, 14 Feb 2008 13:32:02 EST, Gene Heskett said: > >> Nvidia vs 2.6.25-rc1 being a case in point, and they (nvidia) are > >> appearing to indicate its not a problem until some distro actually ships a > >> kernel with the changes that broke it. That could be months or even a > >> year plus. > > > >Actually following the NVidia forums indicates otherwise: > > > >http://www.nvnews.net/vbulletin/showthread.php?t=107144 > > > >I expect Zander will be posting a patch rather soonish, for some value of > >soonish. And if you're running a -rc or -mm kernel, patching the 169.09 > >drivers should be well within your abilities > > Not so for the binaries, existing patches do make it compile but it still > upchucks someplace in the binary, or was this time yesterday. Umm.. if you actually *read* the mentioned thread, you'll see that "existing patches" are known to be incomplete, complete with the "upchucks in the binary" (mentioned at entry number 9 of the thread), and that Zander already knows about it (entry #11), and has apparently one remaining issue left to resolve (entries #32 and #36). And entry #36 is what the NVidia engineer doing the work was thinking about 20 hours ago. Interpret it as you will... pgpL0bWoIfZJW.pgp Description: PGP signature
isofs - Re: 2.6.24-mm1 bugs
On Fri, 15 Feb 2008 12:43:45 +0100, Miklos Szeredi said: > I'm trying out 2.6.24-mm1 on my work laptop (T60), and generally it > - mounting isofs always results in an empty directory I hit this in 24-rc8-mm1, and bisected it down to iget-stop-isofs-from-using-read_inode-fix-2.patch Apparently it got broken way back in 24-rc6-mm1. And that directory is *really* empty - even . and .. are missing. :) pgpMCRyqCMqrQ.pgp Description: PGP signature
Re: x86-32-config: why is pc-speaker an input device?
On Fri, 15 Feb 2008 13:19:11 PST, Linda Walsh said: > I'm wondering how the generic, builtin PC-Speaker (config option > "INPUT_PCSPKR") can be used as an input device. > > If it can not be used for input, why is it under the input config section: > > "Device Drivers" > + -> "Input Device Support" > + -> "Miscellaneous devices" > + -> "PC Speaker Support" > > When booting, it is "enumerated" as an input device: (from dmesg) > > input: PC Speaker as /devices/platform/pcspkr/input/input2 > > Just trying to figure out the rationale behind the choice... The last time around for this question, I was half-paying attention, and the rationale sounded like "We had an input device framework, no output device framework, and too many bad shrooms to do something comprehensible". (This is such a *frequent* FAQ, even all the time since 2.6.0 escaped, that maybe we need to add a 3-4 line explain to the Kconfig 'help' stanza for CONFIG_INPUT_PCSPKR - although for some reason, INPUT_SPARCSPKR and INPUT_M68K_BEEP don't seem to cause the same questions) pgphYLjFTIIzJ.pgp Description: PGP signature
Re: Driver removals
On Fri, 15 Feb 2008 20:08:13 EST, Bill Davidsen said: > can never make you see why technological extortion is evil. People have > always moved to new drivers without pushing because they were *better*, > guess that model is dead. And the drivers get better because the Code Fairy comes and sprinkles magic bugfix dust all over them? And the Code Fairy knows where to sprinkle bugfix dust because it can see where the Bugreport Fairy sprinkled Bugreport Dust? Yes, people will move without pushing when the drivers are better. However, remember that a major cultural motivation for the GPL is the concept of "give back". And if a user can't be bothered to even give back enough to say "wow, this blows, my Frobnozz9800 doesn't work with this driver", that's a problem with the user. They're getting it for free, they should at least give the developers the kindness of a bug report if something is broken... pgp9oUXSku79J.pgp Description: PGP signature
Weirdness with EFI boot and partition tables...
So I'm trying to debug a problem with my Dell Latitude booting in EFI mode, that looks like a "can't find the initrd", when I stumbled across this: <4>[2.831325] VFS: Cannot open root device "mapper/turing--police-froot" or unknown-block(0,0): error -6 <4>[2.831329] Please append a correct "root=" boot option; here are the available partitions: <4>[2.831338] 0800 488386584 sda driver: sd <4>[2.831344] 0801 305368 sda1 5288e82d-f5e3-4f57-a7f9-e29f87149240 <4>[2.831348] 0802 3150112 sda2 42eb87e8-1e6a-477e-8b66-2255ac98b27d <4>[2.831351] 0803 512000 sda3 6c7a5919-61bc-498e-b26a-9c2aa27e65d1 <4>[2.831355] 0805 293795840 sda5 52e421a3-78df-48ac-877f-9362b50af20f <4>[2.831358] 0806 4100096 sda6 ebaf21a2-a1aa-4685-8788-e962b6aad18c <4>[2.831364] 0b00 1048575 sr0 driver: sr Note the entry for sda6. Boot a Fedora kernel, and: # fdisk -l /dev/sda WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion. Disk /dev/sda: 500.1 GB, 500107862016 bytes, 976773168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk label type: gpt # Start EndSize TypeName 116072 626807 298.2M Linux filesyste Linux filesystem 2 626808 6927031 3G Microsoft basic Microsoft basic data 3 6928384 7952383500M Linux filesyste Linux filesystem 5 7954432595546111 280.2G Linux LVM Linux LVM 6595546112976773134 181.8G Linux LVM Linux LVM Any ideas why the size discrepancy? (No, this probably not relevant to my original issue - my root is on the LVM on sda5, which is OK, and the problem is the initrd doesn't fire up at all) pgpBQPQq2kywS.pgp Description: PGP signature
Re: [PATCH] Modification of the diffconfig script to support python 3.x and 2.7
On Thu, 04 Jul 2013 20:19:03 -0400, Mike Pagano said:
I'm not a snake-language person, but...
> Modification of the diffconfig script to support both python 2.7 and 3.2.
> Added a small change to gracefully exit if the default config files are not
> present. (.config and .config.old)
>
> Diffconfig is a utility script for comparing kernel configuration files.
>
> Signed-off-by: Mike Pagano
> ---
> scripts/diffconfig | 32 +++-
> 1 file changed, 19 insertions(+), 13 deletions(-)
>
> diff --git a/scripts/diffconfig b/scripts/diffconfig
> index b91f3e3..45a4ba4 100755
> --- a/scripts/diffconfig
> +++ b/scripts/diffconfig
> @@ -10,7 +10,7 @@
> import sys, os
>
> def usage():
> -print """Usage: diffconfig [-h] [-m] [ ]
> +print ("""Usage: diffconfig [-h] [-m] [ ]
Is this hunk missing a ) at the end of the line?
pgpNSDVuoEvq3.pgp
Description: PGP signature
next-20130709 DMAR issues
Dell Latitude E6530. Seeing a new error message crop up in next-0709 that wasn't there with 0703. Particularly odd, last person to touch dmar.c was on 05/20/2013, so no smoking guns there... egrep -i 'dmar|linux ver' /var/log/messages gives me: Jul 9 21:47:15 turing-police kernel: [0.00] Linux version 3.10.0-next-20130703 (val...@turing-police.cc.vt.edu) (gcc version 4.8.1 20130612 (Red Hat 4.8.1-2) (GCC) ) #99 SMP PREEMPT Wed Jul 3 17:40:09 EDT 2013 Jul 9 21:47:15 turing-police kernel: [0.00] ACPI: DMAR cb7fd298 00080 (v01 INTEL SNB 0001 INTL 0001) Jul 9 21:47:15 turing-police kernel: [0.021530] dmar: Host address width 36 Jul 9 21:47:15 turing-police kernel: [0.021536] dmar: DRHD base: 0x00fed9 flags: 0x1 Jul 9 21:47:15 turing-police kernel: [0.021569] dmar: IOMMU 0: reg_base_addr fed9 ver 1:0 cap c9008020660262 ecap f0105a Jul 9 21:47:15 turing-police kernel: [0.021576] dmar: RMRR base: 0x00ce761000 end: 0x00ce780fff Jul 9 21:47:15 turing-police kernel: [1.023235] DMAR: No ATSR found That's what it usually says. But now I have: Jul 10 12:20:19 turing-police kernel: [0.00] Linux version 3.10.0-next-20130709 (val...@turing-police.cc.vt.edu) (gcc version 4.8.1 20130612 (Red Hat 4.8.1-2) (GCC) ) #100 SMP PREEMPT Tue Jul 9 16:01:59 EDT 2013 Jul 10 12:20:19 turing-police kernel: [0.00] ACPI: DMAR cb7fd298 00080 (v01 INTEL SNB 0001 INTL 0001) Jul 10 12:20:19 turing-police kernel: [0.021453] dmar: Host address width 36 Jul 10 12:20:19 turing-police kernel: [0.021456] dmar: DRHD base: 0x00fed9 flags: 0x1 Jul 10 12:20:19 turing-police kernel: [0.021485] dmar: IOMMU 0: reg_base_addr fed9 ver 1:0 cap c9008020660262 ecap f0105a Jul 10 12:20:19 turing-police kernel: [0.021487] dmar: RMRR base: 0x00ce761000 end: 0x00ce780fff Jul 10 12:20:19 turing-police kernel: [0.021575] dmar: DRHD: handling fault status reg 2 Jul 10 12:20:19 turing-police kernel: [0.021583] dmar: DMAR:[DMA Read] Request device [00:1f.2] fault addr ce71d000 Jul 10 12:20:19 turing-police kernel: [0.021583] DMAR:[fault reason 06] PTE Read access is not set Jul 10 12:20:19 turing-police kernel: [1.034643] DMAR: No ATSR found Now I have 3 extra messages talking about handling a fault status. lspci says 00:1f.2 is: 00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) I found similar in a thread here: http://lkml.indiana.edu/hypermail/linux/kernel/1212.1/02319.html which ended with Don Dutile saying: "DMAR table does not have an entry for this device to this region. Once the driver reconfigs/resets the device to stop polling bios-boot cmd rings and use (new) OS (dma-mapped) rings, there's a period of time during this transition that the hw is babbling away to an area that is no longer mapped." But I'm not convinced this is the same issue - why did it change between 0703 and 0709, when I haven't updated the firmware. No relevant .config changes between the two, either. If this doesn't ring any bells, I'l go do the bisect thing... pgphOgNqz1VgA.pgp Description: PGP signature
Oddness in security/Makefile
Seen in security/Makefile: % git blame security/Makefile ... ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 15) ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 16) # Object file lists da31894e (Eric Paris 2008-08-22 11:35:57 -0400 17) obj-$(CONFIG_SECURITY) += security.o capability.o da31894e (Eric Paris 2008-08-22 11:35:57 -0400 18) obj-$(CONFIG_SECURITYFS)+= inode.o ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 19) # Must precede capability.o in order to stack properly. ^1da177e (Linus Torvalds 2005-04-16 15:20:36 -0700 20) obj-$(CONFIG_SECURITY_SELINUX) += selinux/built-in.o 5915eb53 (Miklos Szeredi 2008-07-03 20:56:05 +0200 21) obj-$(CONFIG_SECURITY_SMACK)+= smack/built-in.o ... What's wrong with this picture? Line 19 looks more than slightly confused, and it has been for several years pgpBBix2kYIwi.pgp Description: PGP signature
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 09 Sep 2013 11:49:34 -0400, Matthew Garrett said: > So, this is my final attempt at providing the functionality I'm interested > in without inherently tying it to Secure Boot. There's strong parallels > between the functionality that I'm interested in and the BSD securelevel > interface, so here's a trivial implementation. Although all the individual patches look like sane and reasonable things to do, I'm not at all convinced that sticking them all under control of one flag is really the right way to do it. In particular, there probably needs to be some re-thinking of the kexec, signed-module, and secure-boot stuff, as it's still a moving target. > So, this is my final attempt at providing the functionality I'm interested > in without inherently tying it to Secure Boot. You may as well bite the bullet on this one, and tie it together. Without Secure Boot, by the time your code runs it's already too late. That's the whole point of Secure Boot, after all. pgpjpp8r8wkSW.pgp Description: PGP signature
Re: [PATCH 00/12] One more attempt at useful kernel lockdown
On Mon, 09 Sep 2013 11:25:38 -0700, David Lang said: > Given that we know that people want signed binaries without blocking kexec, > you > should have '1' just enforce module signing and '2' (or higher) implement a > full > lockdown including kexec. > Or, eliminate the -1 permanently insecure option and make this a bitmask, if > someone wants to enable every possible lockdown, have them set it to "all > 1's", > define the bits only as you need them. This strikes me as much more workable than one big sledgehammer. pgps5lImHblTw.pgp Description: PGP signature
Re: [dm-devel] [RFC] dm-lc: plan to go to staging
On Fri, 30 Aug 2013 21:33:29 +0900, Akira Hayakawa said: > Candidates: > 1) logcache > Not too long but explaining enough > but looks little bit dull to me. Descriptive but dull naming is a much underrated quality in software packages. Consider the package HarfBuzz. As my daughter put it, "Sounds like a bad coffee name". rpm -qi harfbuzz says: Description : HarfBuzz is an implementation of the OpenType Layout engine. (And don't get me started on the people who name packages enca, fros, serd, yajl, or yaml. We aren't using ASR-33's anymore, brevity isn't as crucial :) dm-logcache works just fine for me as a name for this. Or dm-lcache. pgpCkCGNa0uB8.pgp Description: PGP signature
Re: [PATCH] regmap: silence GCC warning
On Wed, 03 Oct 2012 09:23:36 +0200, Paul Bolle said: > By the way, GCC doesn't warn if I add an early check whether 'val_count' > is non-zero: > > diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c > index c241ae2..d41527b 100644 > --- a/drivers/base/regmap/regmap.c > +++ b/drivers/base/regmap/regmap.c > @@ -1171,6 +1171,8 @@ int regmap_raw_read(struct regmap *map, unsigned int > reg, void *val, > unsigned int v; > int ret, i; > > + if (!val_count) > + return -EINVAL; > That is another way to silence GCC here. That's probably a preferable approach - that way, if a bogus val_count gets passed in, the caller will be informed of the fact. Which is a lot better than just papering over the warning. pgpfYqH7jx650.pgp Description: PGP signature
Re: [PATCH v2 00/11] introduce random32_get_bytes() and random32_get_bytes_state()
On Sun, 04 Nov 2012 00:43:31 +0900, Akinobu Mita said: > This patchset introduces new functions into random32 library for > getting the requested number of pseudo-random bytes. > > Before introducing these new functions into random32 library, > prandom32() and prandom32_seed() with "prandom32" prefix are > renamed to random32_state() and srandom32_state() respectively. > > The purpose of this renaming is to prevent some kernel developers > from assuming that prandom32() and random32() might imply that only > prandom32() was the one using a pseudo-random number generator by > prandom32's "p", and the result may be a very embarassing security > exposure. Out of curiosity, why the '32'? I'm just waiting for some kernel developer to do something stupid with this on a 64-bit arch because they think it's a 32-bit API. ;) Should we bite the bullet and lose the 32, as long as we're churning the code *anyhow*? pgpJAuZEgbFx9.pgp Description: PGP signature
Re: [ANNOUNCE] 3.6.5-rt14
On Sat, 03 Nov 2012 20:04:58 +0100, Ove Karlsen said: > And have you given consideration to the fact that most distros and OS > grow with some levels of bloat, and everyone can`t be an expert, so > maybe one shold consider a (scheduler) queue for "bloat", and one queue > for main app, so that even bloated distros can run with the jitteramount > of a highly specialized distro? (for instance > mainapp,service1,mainapp,service2,mainapp,service3), if bloat is on > queue 2. Or is thins kind of thinking already in batch, or idle? So how does the kernel know which one is your "main app", and which one is "bloat"? Hint - you can't base it on "the main app is the one using OpenGL" or similar rule, as there may be multiple processes doing that, and you may consider one of them to be bloat - and *I* might consider that one to be the *important* one. Or even your definition may change around during the day - if you're running Doom3, an OpenGL-capable window manager is probably "bloat", but once you exit Doom3 and start working with multiple windows again, suddenly you're going to want that window manager to be the "important" process again... pgp3SOV39mT2V.pgp Description: PGP signature
Re: [RFC] Second attempt at kernel secure boot support
On Tue, 06 Nov 2012 03:12:19 +, Matthew Garrett said: > On Mon, Nov 05, 2012 at 06:46:32PM -0800, Eric W. Biederman wrote: > > You have it backwards. The conclusion here is that having a case where > > a non-interactive install is possible is not a given. > > I deal with customers who perform non-interactive installs. The fact > that you don't care about that use case is entirely irrelevant to me, > because you're not the person that I am obliged to satisfy. You *do* realize that the fact you have some set of customers who perform non-interactive installs does *not* imply that being able to do so is a given, right? The fact it is available and doable for your customers does *not* mean it's available and doable in general. There's a big difference between "the design has to deal with the fact that some customers can do this on some subsets of hardware" and "the design is free to assume that this is doable". pgppwjMUVeMFW.pgp Description: PGP signature
IRQ_FORCED_THREADING - possible build issue?
While trying to clean old cruft out of grub.conf, I
chased down a 'threadirqs' parameter.
kernel/irq/manage.c has this in it:
#ifdef CONFIG_IRQ_FORCED_THREADING
__read_mostly bool force_irqthreads;
static int __init setup_forced_irqthreads(char *arg)
{
force_irqthreads = true;
return 0;
}
early_param("threadirqs", setup_forced_irqthreads);
#endif
but the references to that variable in irq_thread() and
irq_setup_forced_threading() and elsewhere don't seem to
be similarly guarded. This can lead to a compile error if
IRQ_FORCED_THREADING isn't in the .config. Is this actually
being forced on all archs now? If so, the ifdef/endif is
probably superfluous. If not, what happens on archs that
don't force it?
(I tried to build-test it for myself and see, but apparently X86
selects the symbol and I haven't managed to figure out how to
get a compile that doesn't define it. Kbuild kept re-running config
and re-setting it. 'make ARCH=something allnoconfig' for some
value of something that doesn't do it?)
pgpaEJCJikKGA.pgp
Description: PGP signature
Re: [PATCH 8/9] x86: ramdisk info print with high bits.
On Fri, 16 Nov 2012 11:32:50 -0800, Yinghai Lu said: > On Fri, Nov 16, 2012 at 11:21 AM, Yinghai Lu wrote: > > or you prefer to cast them to pointer and use %pR for them all? > > > > or fix printk to add extra 2 for "0x" when # is found? > > looks like we have lots of %#010llx or %#010Lx there in arch/x86. > > We need to fix printk to make it acting like %pR ? I'd prefer fixing the code to use %pR - when I'm looking at the code, that tells me more about the intended semantics than $# does. But I'm basically just a crash test dummy here - the x86 maintainers of course get to make the decision what they'd prefer to have. pgpD6hjuylbzS.pgp Description: PGP signature
Re: [PATCH] Revert "mm: remove __GFP_NO_KSWAPD"
On Fri, 16 Nov 2012 11:51:24 -0800, Andrew Morton said: > On Fri, 16 Nov 2012 14:14:47 -0500 > Josh Boyer wrote: > > > > The temptation is to supply a patch that checks if kswapd was woken for > > > THP and if so ignore pgdat->kswapd_max_order but it'll be a hack and not > > > backed up by proper testing. As 3.7 is very close to release and this is > > > not a bug we should release with, a safer path is to revert "mm: remove > > > __GFP_NO_KSWAPD" for now and revisit it with the view to ironing out the > > > balance_pgdat() logic in general. > > > > > > Signed-off-by: Mel Gorman > > > > Does anyone know if this is queued to go into 3.7 somewhere? I looked > > a bit and can't find it in a tree. We have a few reports of Fedora > > rawhide users hitting this. > > Still thinking about it. We're reverting quite a lot of material > lately. > mm-revert-mm-vmscan-scale-number-of-pages-reclaimed-by-reclaim-compaction-based-on-failures.patch > and revert-mm-fix-up-zone-present-pages.patch are queued for 3.7. > > I'll toss this one in there as well, but I can't say I'm feeling > terribly confident. How is Valdis's machine nowadays? I admit possibly having lost the plot. With the two patches you mention stuck on top of next-20121114, I'm seeing less kswapd issues but am still tripping over them on occasion. It seems to be related to uptime - I don't see any for a few hours, but they become more frequent. I was seeing quite a few of them yesterday after I had a 30-hour uptime. I'll stick Mel's "mm: remove __GFP_NO_KSWAPD" patch on this evening and let you know what happens (might be a day or two before I have definitive results, as usualally my laptop gets rebooted twice a day). pgpPQccSwp95r.pgp Description: PGP signature
Re: next-20130607 BUG: sleeping function called from invalid context at lib/idr.c:424
On Tue, 11 Jun 2013 11:38:20 -0700, Davidlohr Bueso said: > > Looking at 'git blame', I see a bunch of patches from Davidlohr Bueso on > > 06/07 > > that hit ipc/util.c and friends. > > Yeah, this is my fault. It was originally reported by Fengguang: > http://www.spinics.net/lists/kernel/msg1545633.html#.UbYI9qqdmV8 > > Sasha proposed a fix to use GFP_ATOMIC in idr_preload instead of > GFP_KERNEL: > > http://lkml.org/lkml/2013/6/10/322 Confirming that Sasha's proposed fix eliminates the BUG in my kernel, so if GFP_ATOMIC is acceptable otherwise, feel free to stick a Tested-By: on it of you like. pgp78C0TCvfme.pgp Description: PGP signature
next-20130607 BUG: sleeping function called from invalid context at lib/idr.c:424
Tried to boot next-20130607, got this during early boot. -0603 is OK, so
whatever did it is a recent patch. Not sure who's fault it is, as idr_preload()
has been there since February, apparently something in the SyS_semget()
path has been changed...
Looking at 'git blame', I see a bunch of patches from Davidlohr Bueso on 06/07
that hit ipc/util.c and friends.
[ 17.332871] BUG: sleeping function called from invalid context at
lib/idr.c:424
[ 17.333013] in_atomic(): 0, irqs_disabled(): 0, pid: 231, name:
systemd-cryptse
[ 17.333135] 2 locks held by systemd-cryptse/231:
[ 17.333226] #0: (&ids->rw_mutex){+.}, at: []
ipcget+0x58/0x162
[ 17.333650] #1: (rcu_read_lock){.+.+..}, at: []
rcu_read_lock+0x0/0x6c
[ 17.334103] CPU: 0 PID: 231 Comm: systemd-cryptse Not tainted
3.10.0-rc4-next-20130607 #79
[ 17.334227] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A11
03/12/2013
[ 17.334347] 8801254e3e18 815ebdd7
88012545ecc0
[ 17.334706] 8801254e3e40 8105b59b 8801262a1600
81a3ee28
[ 17.335088] 00d0 8801254e3e70 812377ec
8801262a1618
[ 17.335445] Call Trace:
[ 17.335535] [] dump_stack+0x4f/0x9a
[ 17.335633] [] __might_sleep+0x19e/0x1a5
[ 17.335730] [] idr_preload+0xb7/0x15c
[ 17.335827] [] ipc_addid+0x3a/0x168
[ 17.335924] [] newary+0xa5/0x1b7
[ 17.336040] [] ipcget+0x13c/0x162
[ 17.336139] [] SyS_semget+0x5d/0x69
[ 17.336233] [] ? semctl_nolock.constprop.15+0x240/0x240
[ 17.336332] [] ? sysvipc_sem_proc_show+0x9b/0x9b
[ 17.336430] [] ? __ticket_spin_is_locked+0x11/0x11
[ 17.336529] [] system_call_fastpath+0x16/0x1b
[ 17.344508] bio: create slab at 1
pgpnTIIMJGHuW.pgp
Description: PGP signature
next-20130607 BUG: Bad page state in process systemd pfn:127643
(This may or may not be collateral damage from my previous e-mail regarding a BUG at lib/idr.c:424) Saw several of these booting next-20130607 before it even got to a single-user prompt. -0603 is OK, so whatever did it is a recent patch. Several people touched mm/page_alloc.c on 06/07, have CC'ed them. [ 18.302903] BUG: Bad page state in process systemd pfn:127643 [ 18.303005] page:ea000409dea8 count:0 mapcount:0 mapping: (null) index:0xd [ 18.303127] page flags: 0x404c(referenced|uptodate|active) [ 18.303543] Modules linked in: [ 18.303691] CPU: 1 PID: 1 Comm: systemd Not tainted 3.10.0-rc4-next-20130607 #79 [ 18.303810] Hardware name: Dell Inc. Latitude E6530/07Y85M, BIOS A11 03/12/2013 [ 18.303929] 88012d0cfbe0 815ebdd7 ea000409dea8 [ 18.304306] 88012d0cfbf8 810d615e ea000409dea8 88012d0cfc38 [ 18.304658] 810d6248 0001 404c ea000409dea8 [ 18.305012] Call Trace: [ 18.305101] [] dump_stack+0x4f/0x9a [ 18.305198] [] bad_page+0xd8/0xf1 [ 18.305300] [] free_pages_prepare+0xd1/0x1a9 [ 18.305396] [] free_hot_cold_page+0x1f/0x103 [ 18.305494] [] free_hot_cold_page_list+0x6c/0xc1 [ 18.305591] [] release_pages+0x187/0x196 [ 18.305689] [] __pagevec_release+0x1b/0x25 [ 18.305787] [] pagevec_release+0xe/0x10 [ 18.305884] [] truncate_inode_pages_range+0x19e/0x420 [ 18.305982] [] truncate_inode_pages+0xd/0xf [ 18.306082] [] evict+0xf6/0x1a8 [ 18.306177] [] iput+0x1bc/0x1c9 [ 18.306353] [] do_unlinkat+0x137/0x1a6 [ 18.306452] [] ? trace_hardirqs_on_caller+0x17d/0x199 [ 18.306554] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 18.306651] [] SyS_unlinkat+0x1d/0x29 [ 18.306746] [] system_call_fastpath+0x16/0x1b [ 18.306914] Disabling lock debugging due to kernel taint Hit a whole stream of these - identical tracebacks for different pfn's. Almost continuous and in order, but not quite. [ 18.302903] BUG: Bad page state in process systemd pfn:127643 [ 18.307011] BUG: Bad page state in process systemd pfn:127642 [ 18.310766] BUG: Bad page state in process systemd pfn:127641 [ 18.319703] BUG: Bad page state in process systemd pfn:127640 [ 18.323423] BUG: Bad page state in process systemd pfn:12763f [ 18.327138] BUG: Bad page state in process systemd pfn:12763e [ 18.330855] BUG: Bad page state in process systemd pfn:12763d [ 18.334574] BUG: Bad page state in process systemd pfn:12763c [ 18.338279] BUG: Bad page state in process systemd pfn:12763b [ 18.347197] BUG: Bad page state in process systemd pfn:12763a [ 18.350913] BUG: Bad page state in process systemd pfn:127639 [ 18.354635] BUG: Bad page state in process systemd pfn:127638 [ 18.358346] BUG: Bad page state in process systemd pfn:127637 [ 18.362058] BUG: Bad page state in process systemd pfn:127636 [ 18.370971] BUG: Bad page state in process systemd pfn:127651 [ 18.374690] BUG: Bad page state in process systemd pfn:127650 [ 18.378400] BUG: Bad page state in process systemd pfn:12764f [ 18.382101] BUG: Bad page state in process systemd pfn:12764e [ 18.385811] BUG: Bad page state in process systemd pfn:12764d [ 18.394732] BUG: Bad page state in process systemd pfn:12764c [ 18.398433] BUG: Bad page state in process systemd pfn:12764b [ 18.402173] BUG: Bad page state in process systemd pfn:12764a [ 18.405885] BUG: Bad page state in process systemd pfn:127649 [ 18.409601] BUG: Bad page state in process systemd pfn:127648 [ 18.413318] BUG: Bad page state in process systemd pfn:127647 [ 18.422216] BUG: Bad page state in process systemd pfn:127646 [ 18.425928] BUG: Bad page state in process systemd pfn:127645 [ 18.429633] BUG: Bad page state in process systemd pfn:127644 [ 18.433343] BUG: Bad page state in process systemd pfn:12765f [ 18.437049] BUG: Bad page state in process systemd pfn:12765e [ 18.445974] BUG: Bad page state in process systemd pfn:12765d [ 18.449701] BUG: Bad page state in process systemd pfn:12765c [ 18.453405] BUG: Bad page state in process systemd pfn:12765b [ 18.457123] BUG: Bad page state in process systemd pfn:12765a [ 18.460827] BUG: Bad page state in process systemd pfn:127659 [ 18.464549] BUG: Bad page state in process systemd pfn:127658 [ 18.473475] BUG: Bad page state in process systemd pfn:127657 [ 18.477187] BUG: Bad page state in process systemd pfn:127656 [ 18.480893] BUG: Bad page state in process systemd pfn:127655 [ 18.484608] BUG: Bad page state in process systemd pfn:127654 [ 18.488326] BUG: Bad page state in process systemd pfn:127653 [ 18.497245] BUG: Bad page state in process systemd pfn:127652 [ 18.500956] BUG: Bad page state in process systemd pfn:12766d [ 18.504687] BUG: Bad page state in process systemd pfn:12766c [ 18.508412] BUG: Bad page state in process systemd pfn:12766b [ 18.512127] BUG: Bad page sta
Re: [merged] memstick-add-support-for-legacy-memorysticks.patch removed from -mm tree
On Mon, 08 Jul 2013 03:41:42 +0300, Maxim Levitsky said:
> +/* Debug test to validate free block counts */
> +#ifdef DEBUG
> +static int msb_validate_used_block_bitmap(struct msb_data *msb)
> +{
Is there a reason this should be inside a #ifdef DEBUG with no
easy way to select DEBUG? Maybe CONFIG_MS_BLOCK_DEBUG similar to
the way other subsystems allow configuring additional debug code?
pgpvkyqvFxXCw.pgp
Description: PGP signature
Re: mmotm 2013-06-27-16-36 uploaded (wait event common)
On Thu, 27 Jun 2013 22:30:41 -0700, Randy Dunlap said: > + __ret = __wait_no_timeout(tout) ?: (tout) ?: 1; Was this trying to do a wait_ho_timeout(!!tout) or something? pgpc10X8PW5FX.pgp Description: PGP signature
Re: linux-next: Tree for Jun 28 [ BISECTED: rsyslog/imklog: High CPU usage ]
On Sun, 30 Jun 2013 20:19:45 +0200, Oleg Nesterov said:
>
> Not only "__wait_no_timeout(tout) ?:" was wrong, I didn't bother
> to recheck this logic even after I got the "warning: the omitted
> middle operand in ?:" reports.
>
> Sedat, thanks you very much! Any chance you can try the patch below?
I'm not Sedat, but I had the same problem with rsyslog going nuts,
and I can confirm that the patch fixes the problem. (Had to hand-apply
it, there was some difference of opinion regarding { } on an else)
Feel free to toss on a Tested-By: if this becomes a separate commit...
pgpBPqMaPG0E2.pgp
Description: PGP signature
next-20130325 - INFO: trying to register non-static key.
Seen in the dmesg for next-20130325, but looks like it's been doing it since at least next-20130218. [ 50.162584] dell_wmi: Received unknown WMI event (0x11) [ 51.167629] INFO: trying to register non-static key. [ 51.167636] the code is fine but needs lockdep annotation. [ 51.167639] turning off the locking correctness validator. [ 51.167644] Pid: 594, comm: kworker/0:3 Tainted: GW O 3.9.0-rc4-next-20130325 #67 [ 51.167646] Call Trace: [ 51.167656] [] register_lock_class+0x108/0x2ba [ 51.167662] [] __lock_acquire+0x126/0xde2 [ 51.167667] [] ? __lock_acquire+0x5f1/0xde2 [ 51.167671] [] lock_acquire+0xc7/0x14a [ 51.167677] [] ? process_one_work+0x1fd/0x4ae [ 51.167681] [] process_one_work+0x269/0x4ae [ 51.167686] [] ? process_one_work+0x1fd/0x4ae [ 51.167691] [] worker_thread+0x2d6/0x3dc [ 51.167696] [] ? rescuer_thread+0x343/0x343 [ 51.167701] [] kthread+0x9d/0xa5 [ 51.167706] [] ? __kthread_parkme+0x60/0x60 [ 51.167712] [] ret_from_fork+0x7c/0xb0 [ 51.167717] [] ? __kthread_parkme+0x60/0x60 'git blame' doesn't seem to shout anything. Commit 112202d90 touched code in that area semi-recently, but I don't actually see a problem with it. (I admit not being sure how long this has been an issue - discovered I had a local config screw-up that meant lockdep wasn't on for quite some time). pgpUcSV_ps2gY.pgp Description: PGP signature
Re: [PATCH] zram percpu implementation
On Wed, 17 Jul 2013 00:27:34 +0530, mani said:
> This patch will create a percpu structures compression algo.
> 1. Takes extra memory for workspace buffers.
> I haven't seen any performance gain with this need to find the
> root cause.
My first guess is that the higher-level zram stuff is submitting
its requests sequentially, so there's very few occasions where more
than one page is waiting for (de)compression handling at the same time.
You change the logic of zram_bvec_(read/write) - but what you'd need to
change is the code that *calls* it so that there's multiple bvec_* calls
in flight at the same time.
+for_each_possible_cpu(cpu) {
+printk(KERN_EMERG"[%s] Initializing for each core %d\n", cpu);
KERN_EMERG? No. Absolutely not.
pgpolxX2mp89x.pgp
Description: PGP signature
Re: next-20130709 DMAR issues
On Fri, 12 Jul 2013 14:14:20 +0200, Ingo Molnar said: > > (Cc:-ed a few DMAR people.) Sorry for the slow reply, missed this in the lkml firehose. For whatever reason, the damned problem seems to have evaporated: % egrep -i 'dmar|Linux vers' /var/log/messages-20130714 Jul 11 18:54:15 turing-police kernel: [0.00] Linux version 3.10.0-next-20130709 (val...@turing-police.cc.vt.edu) (gcc version 4.8.1 20130612 (Red Hat 4.8.1-2) (GCC) ) #100 SMP PREEMPT Tue Jul 9 16:01:59 EDT 2013 Jul 11 18:54:15 turing-police kernel: [0.00] ACPI: DMAR cb7fd298 00080 (v01 INTEL SNB 0001 INTL 0001) Jul 11 18:54:15 turing-police kernel: [0.021632] dmar: Host address width 36 Jul 11 18:54:15 turing-police kernel: [0.021638] dmar: DRHD base: 0x00fed9 flags: 0x1 Jul 11 18:54:15 turing-police kernel: [0.021669] dmar: IOMMU 0: reg_base_addr fed9 ver 1:0 cap c9008020660262 ecap f0105a Jul 11 18:54:15 turing-police kernel: [0.021677] dmar: RMRR base: 0x00ce761000 end: 0x00ce780fff Jul 11 18:54:15 turing-police kernel: [0.021775] dmar: DRHD: handling fault status reg 2 Jul 11 18:54:15 turing-police kernel: [0.021782] dmar: DMAR:[DMA Read] Request device [00:1f.2] fault addr ce71d000 Jul 11 18:54:15 turing-police kernel: [0.021782] DMAR:[fault reason 06] PTE Read access is not set Jul 11 18:54:15 turing-police kernel: [1.002171] DMAR: No ATSR found Jul 11 22:12:39 turing-police kernel: [0.00] Linux version 3.10.0-next-20130709 (val...@turing-police.cc.vt.edu) (gcc version 4.8.1 20130612 (Red Hat 4.8.1-2) (GCC) ) #100 SMP PREEMPT Tue Jul 9 16:01:59 EDT 2013 Jul 11 22:12:39 turing-police kernel: [0.00] ACPI: DMAR cb7fd298 00080 (v01 INTEL SNB 0001 INTL 0001) Jul 11 22:12:39 turing-police kernel: [0.021376] dmar: Host address width 36 Jul 11 22:12:39 turing-police kernel: [0.021382] dmar: DRHD base: 0x00fed9 flags: 0x1 Jul 11 22:12:39 turing-police kernel: [0.021414] dmar: IOMMU 0: reg_base_addr fed9 ver 1:0 cap c9008020660262 ecap f0105a Jul 11 22:12:39 turing-police kernel: [0.021422] dmar: RMRR base: 0x00ce761000 end: 0x00ce780fff Jul 11 22:12:39 turing-police kernel: [1.034107] DMAR: No ATSR found Damned if I know what changed - same kernel booted at 18:54 hit the issue, but at 22:12 it had gone into hiding, and I haven't seen it since. (And the laptop gets booted twice a day most days - once at arrival at office, and once when I get home, and it had been doing it consistently at both locations for several days.) Definitely well into "things that go bump in the night" category. pgprsmtMiIPh5.pgp Description: PGP signature
Re: next-20130709 DMAR issues
On Mon, 15 Jul 2013 10:32:17 +0800, "Li, Zhen-Hua" said: > I have met a bug with the same error message, its cause was that the bios > did not allocate RMRR/DRHD(can't remember which one) for the device. I think I posted a link to that same bug report. The problem is that if the BIOS wasn't allocating it before, it isn't allocating it now, because it's still the same A11 bios that Dell shipped it with. And now I'm not sure which is more confusing - that it was OK in -0703 and borked in -0709, or that between two successive boots of the same -0709 kernel it cleared itself up pgpvubatb38Ku.pgp Description: PGP signature
next-20130730 - Seen in drivers/staging/lustre/lnet/Kconfig
What's wrong with this picture? config LNET_MAX_PAYLOAD int "Lustre lnet max transfer payload (default 2MB)" depends on LUSTRE_FS default "1048576" pgpVfPeZQgyEs.pgp Description: PGP signature
Stupid linux-next git question...
OK... So I have (as usual) found some issues in linux-next, so I'm looking at 3 bisects. I already know that bisecting between (say) next-20130715 and next-20130730 won't work, but bisecting between the 3.11-rc1 base of next-20130715 and next-20130730 *will* work. Question 1: Does bisecting between "the HEAD of Linus's tree when a given next- is built" and "some later next-" work? (basically, I know that anything in Linus's tree as of -0715 is 'Good', so I'd rather start from there than from 3.11-rc1 to save several bisects). Question 2: If that works, how do I determine the commit ID to feed to 'git bisect good'? I *hope* this in Next/merge.log is the magic I'm looking for: $ git reset --hard stable HEAD is now at 6c504ec Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux Merging origin/master (5ae90d8 Linux 3.11-rc3) pgpWG3pNoH7NS.pgp Description: PGP signature
next-20130805 - compile errors in drivers/staging/lustre/lustre/llite/file.c
Not sure how this train wreck happened - 'git log' shows the last patch to touch include/linux/aio.h was some stuff of Kent's back in May, and 'git blame' says the 2 lines of code that died were added on 2013-05-02. It compiled when I build next-0730. And yet, this morning, I get this building -0805: CC [M] drivers/staging/lustre/lustre/llite/file.o drivers/staging/lustre/lustre/llite/file.c: In function 'll_file_read': drivers/staging/lustre/lustre/llite/file.c:1012:7: error: 'struct kiocb' has no member named 'ki_left' kiocb->ki_left = count; ^ drivers/staging/lustre/lustre/llite/file.c: In function 'll_file_write': drivers/staging/lustre/lustre/llite/file.c:1071:7: error: 'struct kiocb' has no member named 'ki_left' kiocb->ki_left = count; ^ make[5]: *** [drivers/staging/lustre/lustre/llite/file.o] Error 1 Any ideas? Only thing I can think of is that Kent's stuff went into some tree in May, but only surfaced in linux-next in the last little bit... pgpbVLX7iqYRL.pgp Description: PGP signature
Re: zswap: How to determine whether it is compressing swap pages?
On Thu, 18 Jul 2013 20:43:40 +0800, Bob Liu said: > Could you make some test by kernel compiling? Something like kernbench. > During my testing, I found that the swap ins/outs operations reduced but > the kernel compile time didn't reduce accordingly. If your kernel source tree is cache-cold, the swap in/out activity is probably hidden and ahrd to notice among all the disk I/O to read the source in. pgpDmx78NKocX.pgp Description: PGP signature
Query regarding PTP_1588_CLOCK
In drivers/net/ethernet/intel/Kconfig, we see this: config E1000E tristate "Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support" depends on PCI && (!SPARC32 || BROKEN) select CRC32 select PTP_1588_CLOCK ---help--- Is there a reason for the PTP_1588_CLOCK select? That ends up forcing the PTP and PPS stuff into the kernel as well - and I don't use any of it. pgpwyKc7xlL3B.pgp Description: PGP signature
Re: [PATCH]: Definition for loglevel in KERN_OOPS
On Tue, 28 May 2013 20:00:45 -0400, Christopher Sacchi said: > This patch is for linux-3.10-rc2 and adds the definition for > KERN_OOPS (it can be used for whenever kernel oops occur) in > for . It is below the > double-dashes. OK, I'll bite. 1) Where in the kernel will this actually get used? 2) Are there any matching patches for userspace tools like syslog to make it useful? 3) Was it intenional that you added this: +#define KERN_OOPS KERN_SOH "2" /* kernel oops condition */ instead of +#define KERN_OOPS KERN_CRIT 4) How does a syslog daemon distringuish between KERN_CRIT and KERN_OOPS? In other words - why do we need this patch? pgpknj0X0wiwT.pgp Description: PGP signature
Re: Weird disk idling
On Sun, 26 May 2013 16:58:59 +0800, ethan said: > Fred£¬ > How do you know the disk is completely idle ? Actually, my first question was "How do you know the disk is *spinning*?" A second or two delay sounds suspiciously like a spun-down disk in powersave move pgpsOF7D6aAkH.pgp Description: PGP signature
Re: Stupid VFS name lookup interface..
On Sun, 26 May 2013 08:02:51 -0400, "Theodore Ts'o" said: > Have any of the arguments over the proper security models changed over > or have gotten resolved over the past six years, while I haven't been > looking? Doubtful, because the security models are addressing different threat models. If you can't agree on what you're trying to secure against, there can be no agreement on how to do the securing. pgpZTTuqxxtRr.pgp Description: PGP signature
Re: [procfs] BUG: sleeping function called from invalid context at mm/slub.c:925
On Thu, 07 Mar 2013 22:12:24 +0800, Fengguang Wu said:
> I got the below dmesg and the first bad commit is
>
> commit a21813be23329e2788164eab532e79cb0e513cfc
> Author: Nathan Zimmer
> Date: Sat Mar 2 15:25:37 2013 +1100
>
> procfs: improve scaling in proc
> [ 78.994163] atkbd: probe of serio1 rejects match -19
> [ 79.196148] Freeing unused kernel memory: 664k freed
> [ 80.786460] BUG: sleeping function called from invalid context at
> /c/kernel-tests/src/tip/mm/slub.c:925
I'm seeing a very similar issue on SLAB in next-20130306.
x86_64 on a 2-core Dell Latitude laptop. Haven't bisected yet.
[9.295661] #0: HDA Intel at 0xf6fdc000 irq 50
[9.324345] Freeing unused kernel memory: 968k freed
[9.350431] Write protecting the kernel read-only data: 10240k
[9.377094] Freeing unused kernel memory: 20k freed
[9.404963] Freeing unused kernel memory: 412k freed
[9.439653] BUG: sleeping function called from invalid context at
mm/slab.c:3056
[9.505448] in_atomic(): 0, irqs_disabled(): 0, pid: 1, name: systemd
[9.531235] 2 locks held by systemd/1:
[9.557046] #0: (rcu_read_lock){.+.+.+}, at: []
rcu_read_lock+0x0/0x6c
[9.583626] #1: (rcu_read_lock){.+.+.+}, at: []
rcu_read_lock+0x0/0x6c
[9.609793] Pid: 1, comm: systemd Not tainted 3.9.0-rc1-next-20130306 #63
[9.636291] Call Trace:
[9.662218] [] __might_sleep+0x19e/0x1a5
[9.687970] []
cache_alloc_debugcheck_before.isra.40+0x1d/0x1f
[9.713908] [] kmem_cache_alloc_trace+0x35/0xec
[9.740070] [] ? cmdline_proc_open+0x17/0x17
[9.765894] [] ? single_open+0x8f/0x8f
[9.791251] [] single_open+0x2c/0x8f
[9.816509] [] cmdline_proc_open+0x15/0x17
[9.841728] [] proc_reg_open+0xcb/0x143
[9.866926] [] ? proc_tty_unregister_driver+0x2d/0x2d
[9.891936] [] ? proc_reg_release+0x157/0x157
[9.917044] [] do_dentry_open+0x1d2/0x2ff
[9.941631] [] finish_open+0x62/0x74
[9.966347] [] do_last+0x9aa/0xb79
[9.990594] [] path_openat+0x105/0x45e
[ 10.014748] [] ? ac_get_obj.constprop.59+0x38/0x1b6
[ 10.038753] [] do_filp_open+0x37/0xc8
[ 10.062789] [] ? _raw_spin_unlock+0x58/0x64
[ 10.086744] [] ? __alloc_fd+0x175/0x187
[ 10.110608] [] do_sys_open+0x81/0x129
[ 10.134379] [] SyS_open+0x19/0x1b
[ 10.158447] [] system_call_fastpath+0x16/0x1b
[ 10.182213]
pgp6QdySzrUWY.pgp
Description: PGP signature
Re: [procfs] BUG: sleeping function called from invalid context at mm/slub.c:925
On Thu, 07 Mar 2013 13:37:00 -0600, Nathan Zimmer said: > I believe this should be fixed v5 of my patch. > http://marc.info/?l=linux-kernel&m=136242660312006&w=2 > > Alternatively the patch posted by Konstantin to fix up the current > linux-next. > http://marc.info/?l=linux-kernel&m=136264090218634&w=2 System boots and lives much longer on next-20130306 with Konstantin's patch. If your v5 is equivalent to Konstantin's, feel free to stick my Tested-By: on it. Now to figure out why udevd was able to cause a paging issue in avc_has_perm_noaudit() - it appears totally unrelated to the above issue. pgpZ43X2A8o_H.pgp Description: PGP signature
next-20130306 - BUG: unable to handle kernel paging reques in avc_has_perm_noaudit
Seeing this in next-20130306: [ 180.958482] BUG: unable to handle kernel paging request at ffe0 [ 180.958488] IP: [] avc_has_perm_noaudit+0xbf/0x1bc [ 180.958506] Pid: 1910, comm: systemd-udevd Tainted: G O 3.9.0-rc1-next-20130306-dirty #64 Dell Inc. Latitude E6500 [ 180.958537] [] avc_has_perm_flags+0x32/0xe4 [ 180.958540] [] ? mark_lock+0x2e/0x225 [ 180.958543] [] avc_has_perm+0xf/0x11 [ 180.958546] [] selinux_inode_rename+0x84/0x138 [ 180.958549] [] ? __kmalloc_track_caller+0x107/0x119 [ 180.958552] [] security_inode_rename+0x6f/0x7a [ 180.958556] [] vfs_rename+0x1e2/0x36a [ 180.958558] [] SYSC_renameat+0x1ed/0x282 [ 180.958562] [] ? mntput+0x49/0x50 [ 180.958566] [] ? __read_seqcount_retry.constprop.21+0x20/0x25 [ 180.958568] [] ? current_kernel_time+0x2a/0x41 [ 180.958572] [] ? __audit_syscall_entry+0xf9/0x125 [ 180.958575] [] SyS_renameat+0x9/0xb [ 180.958577] [] SyS_rename+0x16/0x1b [ 180.958581] [] system_call_fastpath+0x16/0x1b Most suspicious-looking recent commit in git log: ommit 65dff759d2948cf18e2029fc5c0c595b8b7da3a5 Author: Li Zefan Date: Fri Mar 1 15:01:56 2013 +0800 cgroup: fix cgroup_path() vs rename() race rename() will change dentry->d_name. The result of this race can be worse than seeing partially rewritten name, but we might access a stale pointer because rename() will re-allocate memory to hold a longer name. I admit not having any clue what crazy antics systemd was trying to do at the time. If this doesn't ring a bell, I'll go bisect it. pgpCYyk7l4BP6.pgp Description: PGP signature
Re: next-20130306 - BUG: unable to handle kernel paging reques in avc_has_perm_noaudit
On Fri, 08 Mar 2013 11:15:47 +0800, Li Zefan said: > I don't think so. The commit changes cgroup_rename(), but the above stack > doesn't > sugguest it was renaming a cgroup directory. OK.. I'll go bisect it then. pgpU06fdN8tCJ.pgp Description: PGP signature
Re: [PATCH -mmotm] scsi: fix the wrong position of the comment
On Sun, 10 Mar 2013 17:09:50 +0900, Akinobu Mita said:
> This fixes the wrong position of the comment introduced by
> scsi-rename-random32-to-prandom_u32.patch in the -mm tree.
>
> Signed-off-by: Akinobu Mita
> Cc: "James E.J. Bottomley"
> Cc: Andrew Vasquez
> ---
> drivers/scsi/qla2xxx/qla_attr.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_attr.c b/drivers/scsi/qla2xxx/qla_attr.c
> index 04bf7b8..e44d47e 100644
> --- a/drivers/scsi/qla2xxx/qla_attr.c
> +++ b/drivers/scsi/qla2xxx/qla_attr.c
> @@ -1939,13 +1939,13 @@ qla24xx_vport_delete(struct fc_vport *fc_vport)
> }
>
> /* No pending activities shall be there on the vha now */
> - if (ql2xextended_error_logging & ql_dbg_user)
> - msleep(prandom_u32() % 10);
> + if (ql2xextended_error_logging & ql_dbg_user) {
> /*
>* Just to see if something falls on the net we have placed
>* below
>*/
> -
> + msleep(prandom_u32() % 10);
> + }
> BUG_ON(atomic_read(&vha->vref_count));
As others have noted, the msleep is potentially a crock. However,
this particular patch is also incorrect - the *real* problem is
that the 4 line comment connected to the BUG_ON is mis-indented.
The patch *should* make it look like this:
/* No pending activities shall be there on the vha now */
if (ql2xextended_error_logging & ql_dbg_user)
msleep(prandom_u32() % 10);
/*
* Just to see if something falls on the net we have placed
* below
*/
BUG_ON(atomic_read(&vha->vref_count));
And a different patch should fix the msleep issue.
pgpzZXwStiasA.pgp
Description: PGP signature
Re: Complaint - pid-owner Support Removed (CONFIG_NETFILTER_XT_MATCH_OWNER)
On Tue, 31 Jul 2012 12:41:21 +1000, NeilBrown said: > On Mon, 30 Jul 2012 21:22:10 +0200 "C. Schmid" > wrote: > > i want to complain about the removal of the --pid-owner Support for > > iptables. > > As far as i understand it this support was just removed without replacement. > > Yes, 7 years ago. > "Unfixably broken" Even *before* it was removed, it declared itself "broken on SMP" (which is a good hint on exactly *why* it was unfixable), and why it's not applicable to most modern desktop systems anyhow - even an iPad is a dual-core. And to be honest, the "Linux only cares about big iron not the desktop" is a total red herring - if anything, many laptops *are* essentially a single-user environment, while big iron boxes are even *more* concerned about per-user issues. I just checked one of the compute clusters across the hall, 1100+ actual users defined. How often do desktops/laptops have that many real live users? pgp9emhwKtjbv.pgp Description: PGP signature
Re: Gaming and the kernel
On Sat, 04 Aug 2012 10:51:49 +1000, Chris Jones said: > documentation, hopefully things will work out. And this might actually > be the kick in the rear-end that AMD and NVIDIA need to get into gear > and start developer some useful and Windows equivalent hardware drivers > for ALL their cards for Linux. The truly ironic part is that the current NVidia binary blob driver that everybody dislikes so much *IS* the "Windows equivalent" driver (in fact, it's the same driver, with a Linux shim layer wrapped around it). You can flame them for having a non-GPL binary blob, but you can't flame NVidia for not having equivalent drivers... pgpalpgUrHJMp.pgp Description: PGP signature
Re: Driver removals
On Sat, 16 Feb 2008 08:39:08 +0100, Willy Tarreau said: > I don't understand why kernel developers always think that users spend > their whole time testing their new stuff. That is mostly true for a lot > of desktop users, but definitely not for servers. On a server, you may > *ignore* that a new driver exists for years. The basic make oldconfig > does the stuff right. Been there, done that. We got a number of boxes that sit there for ages between reboots and even longer between upgrades. Deploying Solaris 10 was like a 2-year process for some of our boxes (when the boxes are running the Oracle databases that house the enterprise business systems, and your organizational budget is pushing the $1B/year mark, everybody gets *really* cautious to avoid a CLM while upgrading... ;) And we may actually manage to finally kill off our last AIX 4.3.3 box this quarter (4.3.3 was released all the way back in Sep 1999, and EOL'ed back in 2004 - don't ask. :) Of course, the difference is that we *expect* that there's a good chance that if we try to subject that sort of box to 3 year's worth of updates, there's a good chance we'll discover that some driver has been EOL'ed or otherwise problematic on now-ancient hardware... (And yes, there's a *lot* of risk-management going on centered around "What if we have to patch Server23 for a critical kernel security issue?". Of course, if it was actually *feasible* to blindly upgrade-and-reboot twice a month, the job could be done by a much less expensive patch monkey, so it's good job security ;) pgpJDlbRfgsr5.pgp Description: PGP signature
Re: [PATCH] linux/hdsmart.h: fix goofups
On Sun, 17 Feb 2008 12:17:20 EST, "Robert P. J. Day" said: > if that header file isn't used by any kernel code, why bother having a > check for __KERNEL__ in the first place? it's being exported to > userspace unchecked: > > include/linux/Kbuild:header-y += hdsmart.h > > so why not just toss that check entirely? otherwise, you're going to > get a header file exported to userspace that has a superfluous > __KERNEL__ test in it. Umm... if the kernel isn't using it, why are we bothering to export it to userspace at all? Or is the kernel using something *else* that should be going to userspace instead? pgpNeJqmI4gl1.pgp Description: PGP signature
Re: tbench regression in 2.6.25-rc1
On Mon, 18 Feb 2008 16:12:38 +0800, "Zhang, Yanmin" said: > I also think __refcnt is the key. I did a new testing by adding 2 unsigned > long > pading before lastuse, so the 3 members are moved to next cache line. The > performance is > recovered. > > How about below patch? Almost all performance is recovered with the new patch. > > Signed-off-by: Zhang Yanmin <[EMAIL PROTECTED]> Could you add a comment someplace that says "refcnt wants to be on a different cache line from input/output/ops or performance tanks badly", to warn some future kernel hacker who starts adding new fields to the structure? pgpydfJZxFPCt.pgp Description: PGP signature
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said: > I know two fb drivers which use endianess information (pm2fb and s3c2410fb). > Both resolve endianess at driver level. Actually, both handle it by setting > special > bits so the graphics chip itself reorder bytes to transform foreign > endianess. > I understand that this patch is for chips which cannot reorder bytes by > themselves. Does anybody know of such a chip that's actually available in the wild? Or are we writing drivers for speculative possible chips? pgpLWgoEkfmgB.pgp Description: PGP signature
Re: [PATCH 1/5] signal(x86_32): Improve the signal stack overflow check
On Mon, 18 Feb 2008 18:22:05 +0800, Shi Weihua said: > - /* > - * If we are on the alternate signal stack and would overflow it, don't. notice this ^ > - * Return an always-bogus address instead so we will die with SIGSEGV. > + * If we are on the alternate signal stack and would > + * overflow it, don't return an always-bogus address missing here ^ > + * instead so we will die with SIGSEGV. "don't. Return" is a vastly different semantic than "don't return". I think the same comment error was cut-n-pasted into all 5 patches... pgpwGyJurkz2C.pgp Description: PGP signature
Re: [PATCH 1/3] Fix Unlikely(x) == y
On Mon, 18 Feb 2008 14:27:10 GMT, David Howells said: > __builtin_expect() is useful on FRV where you _have_ to give each branch and > conditional branch instruction a measure of probability whether the branch > will be taken. What does gcc do the 99.998% of the time we don't have likely/unlikely coded? pgpWApIZ5dLzV.pgp Description: PGP signature
Re: [PATCH] do_signal_stop: use signal_group_exit()
On Sun, 17 Feb 2008 21:11:14 MST, Eric W. Biederman said: > Oleg Nesterov <[EMAIL PROTECTED]> writes: > > On 02/16, Oleg Nesterov wrote: > >> On 02/15, Andrew Morton wrote: > >> > : BUG: unable to handle kernel paging request at 00200200 > >> > : Call Trace: > >> > : [] ? release_task+0x152/0x2e5 > >> > : [] ? do_wait+0x6c7/0xa1c > >> > : [] ? default_wake_function+0x0/0xe > >> > : [] ? sys_rt_sigaction+0x7a/0x98 > >> > : [] ? sys_wait4+0x8a/0xa1 > >> > : [] ? system_call_after_swapgs+0x7b/0x80 > Thanks. Looks like we need to grab a lock there. > At a quick skim I think we need the tty lock. *ping* - Any further activity on this one? I got bit by it as well on the very first attempted boot of 25-rc2-mm1, the instant it tried to leave single-user and go multi-user. pgpgv8e1NFpVN.pgp Description: PGP signature
Re: vfat32 Free Cluster Count Update
On Tue, 19 Feb 2008 19:23:12 +0900, OGAWA Hirofumi said: > I'll dig it more, later. And for right now, please run "df" command, it > will fix free cluster count. Wow, that's a real kick in the head for all of us who have a mental concept of 'df' being basically a read-only program, and "fixing counts" to be more the job of 'fsck' :) (Or is 'df' simply a known way to force execution of a code path that ends up fixing the counts as a side-effect?) pgpO2fGtyPaPL.pgp Description: PGP signature
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
On Tue, 19 Feb 2008 04:05:30 PST, Andrew Morton said: > On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller <[EMAIL PROTECTED] > wrote: > > That's not an issue in my case. The SM50x can be connected to > > either an PCI or some Local/CPU-whateverbus IF. > > I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses. > > If the sm501 is attached to the MPC85xx' PCI like any other video card, > > the PCI config-space is can be accessed as usual, whereas the framebuffer > > memory area is byte-swapped compared to other common video cards. > Anyway, my head is now officially spinning. Did anyone actually have a > reason why we shouldn't proceed with Anton's patch? Clemens answered my question regarding the real-life existence of hardware that would benefit. I'd say if Anton's patch works on Clemens' hardware and otherwise passes review, we should proceed... pgp99HssnjMXj.pgp Description: PGP signature
Re: Improve init/Kconfig help descriptions [PATCH 4/9]
On Wed, 20 Feb 2008 01:38:55 +1100, Nick Andrew said: > + Enable an auditing infrastructure that can be used with another > + kernel subsystem, such as Security-Enhanced Linux (SELinux), > + which requires this option for logging of AVC messages output. > + > + AVC refers to Access Vector Cache, a subsystem used by SELinux > + to improve performance of the security checking by caching > + previous access decisions. This paragraph can be dropped, as the reasons that SELinux denial messages are tagged with 'avc' are mostly historical. If you want to expand on anything in here, explain that 'AVC' messages are interesting because they indicate some sort of security rule denial. So - if you don't enable auditing, your security messages end up in the kernel syslog. If you enable auditing, they end up in the audit logs. Explaining *that* clearly would be a lot more useful than explaining what avc originally stood for.. ;) pgpfqLD9e6x5N.pgp Description: PGP signature
Re: Where to put adapters, /proc is cool
On Tue, 19 Feb 2008 14:39:45 EST, Karl Dahlke said: > Really, /proc is the only place for these virtual files that interact > directly with the kernel and/or its modules; > I just wanted a fixed place under /proc for adapters to live, > like sys ttys scsi net, and so on. There's an awful lot of stuff under /dev for virtual files and similar. For starters, look at /dev/null, /dev/kmsg, all the dm/md stuff in /dev/mapper, all the PTY stuff etc etc... pgpT8bGghjVyF.pgp Description: PGP signature
Re: 2.6.24-mm1
On Tue, 05 Feb 2008 09:01:24 PST, Arjan van de Ven said: > [EMAIL PROTECTED] wrote: > > On Sun, 03 Feb 2008 17:16:34 PST, Andrew Morton said: > >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24/2.6.24-mm1/ > > > > Builds, boots, mostly seems to run for limited testing. > > > > One note - the following commit(s) (and related CPA reworking) broke the > > NVidia > > binary driver (which is OK, I can fix *that* part). But can somebody > > explain > > if this should have seen a trip through the -mm tree before it hit > > mainstream? > > I didn't see these in 24-rc8-mm1: > > well that depends on which -mm you tried; I'm sure the mm kernel of the day > had it for a while. I looked around on www.kernel.org, and I found this directory: http://www.kernel.org/pub/linux/kernel/people/akpm/mm/ but the most recent is: broken-out-2007-11-20-01-45.tar.bz2 20-Nov-2007 09:45 3.4M 24-rc8-mm1 came out on Jan 17, only a week before 2.6.24 came out and the merge window opened. Since this stuff wasn't in there in rc8-mm1, but did go into Linus's tree on Jan 30, it had at best 2 weeks for testing by whoever pulled the git-x86 tree in that timespan... > I don't think it's a realistic expectation to delay every bugfix and arch > patch until Andrew > gets around to releasing an -mm, not do I see the point of that, what would > have been different? A bugfix? commit 9af993a92623e022c176459fa6607a564b9a7eaf Author: Ingo Molnar <[EMAIL PROTECTED]> Date: Wed Jan 30 13:34:09 2008 +0100 x86: make ioremap() UC by default Yes! A mere 120 c_p_a() fixing and rewriting patches later, we are now confident that we can enable UC by default for ioremap(), on x86 too. That's one hell of a patch series for a "bugfix" that goes straight-to-mainline. pgpalI1dNinor.pgp Description: PGP signature
Re: 2.6.24-mm1
On Tue, 05 Feb 2008 11:50:11 PST, Arjan van de Ven said: > > A bugfix? > > yes it was a really painful bugfix, but still. I'm not saying that it wasn't needed, it *was* a busticated API. > I'll repeat the question. What would waiting for an -mm release have bought > for this bugfix? > Answer: nothing more than what was done on Linus git. Just wondering what happened to the "large changes should percolate in -mm for a bit beforehand" concept. We've seen a lot of patchsets that totalled up to a *lot* less intrusiveness get pushed off with "This needs to cook in -mm for a while". pgpGymvn0wtVw.pgp Description: PGP signature
Re: [PATCH mm] stop c_p_a corrupting the pds
On Tue, 05 Feb 2008 22:27:21 GMT, Hugh Dickins said: > When change_page_attr splits a large page on x86_32 (without PAE), it is > currently corrupting every process's page directory: fix that by removing > the thinko which passes down a physical instead of a virtual address - > this version of the patch being the hotfix for 2.6.24-mm1. > > Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]> I *knew* there was a reason we should have had this patch series in -mm for a while. :) pgpp66He9KgMJ.pgp Description: PGP signature
Re: [PATCH] USB: mark USB drivers as being GPL only
On Wed, 06 Feb 2008 22:12:54 +0100, Christer Weinigel said: > If I use an in kernel API, but from a piece of code which is external > to the kernel, is that really a derived work? If you say it is, do you > realise that you are advocating something which is very close to an API > copyright, something which I think most open source people are very > adverse to. And in fact, at least in the US, current case law states that when there's only one practical way to write something (which is the case in an API, you either code it the way the API says or you don't get a correctly functioning program), it's not copyrightable. See "scenes a faire" in http://www.copyright-laws.com/pgs/protect-rights.html pgpUzlJpkentR.pgp Description: PGP signature
Re: [PATCH] USB: mark USB drivers as being GPL only
On Fri, 08 Feb 2008 10:15:01 +0100, Marcel Holtmann said: > And while you are talking to a lawyer. Ask him/her if it is okay to > create a binary only application that uses a GPL library. Tell him/her It's perfectly legal to create such an application. It only gets interesting if you *distribute* it... (And yes, this is where you *have* to be pedantic about the wording used)... pgpf4cJYxedYU.pgp Description: PGP signature
Re: [RFC] Simplifying kernel configuration for distro issues
On Thu, 19 Jul 2012 13:56:50 -0400, Josh Boyer said: > On Thu, Jul 19, 2012 at 01:33:42PM -0400, Steven Rostedt wrote: > > 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. I do a 'yum update', and my system won't boot, and the first thing I think of is "What the fsck did Lennart add as a systemd requirement *this* time?" :) pgphZDpb1q6Gx.pgp Description: PGP signature
Re: [RFC][PATCH v2 0/3] efi_pstore: avoid losing critical message
On Thu, 19 Jul 2012 21:11:44 -, Seiji Aguchi said: > [Solution] >To avoid losing a critical message, this patchset is based on a following > concept. > - A basic policy is _not_ to overwrite existing entries. > > - However, if kernel panics while a system is rebooting, a critical > message >can't be saved by the policy above. >(In this case, panic message is critical.) OK, system boots in "overwrite mode", and when done booting, we go into "non-overwrite mode". Makes sense to me. Only part I'm missing is how/when/why we leave overwrite mode - what makes the change, and how? (If I missed an ioctl or /sys entry or something that userspace toggles to say "I'll take care of it from here", please point me at it and I'll go re-read after I find some more caffeine ;) pgplxcGq2kl6J.pgp Description: PGP signature
Re: 0xB16B00B5? Really? (was Re: Move hyperv out of the drivers/staging/ directory)
On Fri, 20 Jul 2012 17:03:59 +0200, richard -rw- weinberger said: > On Fri, Jul 20, 2012 at 4:00 PM, KY Srinivasan wrote: > > Thank you for your interest in fixing this problem. When we decide to > > change this > > ID, we will conform to the MSFT guidelines on constructing this guest ID. > > > > I'm wondering why it hasn't been conform to the MSFT guidelines from > the very beginning on? It's a lot easier to sneak something cute into code when it isn't maintained in git repositories and mailing lists readable by everybody and their pet llama. I'll admit to not doing a *lot* of extensive review, but I try to at least read Kconfig patches (mostly out of self-defense so when I do a 'make oldconfig' I get presented with something useful ;) - and it's amazing how often I spot issues in stuff that's presumably already had several pair of eyeballs look at it already. Probably what happened - some programmer had a 60 hour week, wrote the code on a Friday and had a sudden attack of the sillies, and it went through a code review meeting, but they had to cover 800 lines of code in a one-hour meeting so nobody looked *too* close... pgpp8nmLjNzbq.pgp Description: PGP signature
Re: 3.5-rc5: radeon acceleration regression on Transmeta system
On Mon, 09 Jul 2012 14:30:40 +0300, Meelis Roos said: > It's actually more complicated than that. Old kernel images started > misbehaving from around 2.6.35-rc5 and any kernel older than that was > OK. When I recompiled the older kernels with squeeze gcc (migh have been > lenny gcc before, or different answers to make oldconfig), anything from > current git down to 2.6.33 is broken with radeon.modeset=1 and works (I What releases of GCC were those? I'm chasing an issue where compiling with 4.7.[01] breaks but 4.6.2 is OK, wondering if we're chasing the same thing. pgpQWlCfIUmGr.pgp Description: PGP signature
Re: btrfs userspace question - where's the utility to dump/restore?
On Thu, 17 Jan 2013 22:18:19 +, Hugo Mills said: > On Thu, Jan 17, 2013 at 03:05:35PM -0500, Valdis Kletnieks wrote: > > So I'm looking at playing with btrfs, and I start looking at the > > userspace pieces I'll need. What I can't find is an equivalent > > of the ext[34] "dump/restore" package to dump data to an external > > backup device. Is 'tar cf --acls --selinux --xattrs /external/fs.dump' > > as good as it gets, or is something else recommended? > >tar doesn't handle reflinks(+), so the above won't quite give you a > complete duplicate. In the btrfs tool, there's send/receive, which > should(*) be sufficient to deal with reflinks. So I decided to try it out on the filesystem that I stash all my music (mostly because I can survive without that filesystem if I trash it, and I have a known good backup). Apparently, send/receive isn't in the manpage, which is why I didn't see it. Fortunately, there's --help [~] btrfs send --help usage: btrfs send btrfs send [-v] [-i ] [-p ] Send the subvolume to stdout. [~] btrfs send -v /mp3 > /disk2/backups/mp3.btrfs ERROR: /mp3 is not read-only. [~] mount -o remount,ro /mp3 [~] btrfs send -v /mp3 >| /disk2/backups/mp3.btrfs ERROR: /mp3 is not read-only. Bah. Obviously this isn't anywhere near as easy as it is for ext4. /me wanders off to find more caffeine... pgp3mpfmuo5PP.pgp Description: PGP signature
next-20130117 - kernel BUG with aio
Am seeing a reproducible BUG in the kernel with next-20130117 whenever I fire up VirtualBox. Unfortunately, I hadn't done that in a while, so the last 'known good' kernel was next-20121203. I'm strongly suspecting one of Kent Overstreet's 32 patches against aio, because 'git blame' shows those landing on Jan 12, and not much else happening to fs/aio.c in ages. The stack traceback ring any bells before I go to bisect this? [ 327.375581] BUG: sleeping function called from invalid context at arch/x86/mm/fault.c:1138 [ 327.375588] in_atomic(): 0, irqs_disabled(): 1, pid: 2096, name: AioMgr0-N [ 327.375590] INFO: lockdep is turned off. [ 327.375593] irq event stamp: 0 [ 327.375595] hardirqs last enabled at (0): [< (null)>] (null) [ 327.375599] hardirqs last disabled at (0): [] copy_process.part.40+0x565/0x14be [ 327.375607] softirqs last enabled at (0): [] copy_process.part.40+0x565/0x14be [ 327.375611] softirqs last disabled at (0): [< (null)>] (null) [ 327.375616] Pid: 2096, comm: AioMgr0-N Tainted: P O 3.8.0-rc3-next-20130117-dirty #49 [ 327.375618] Call Trace: [ 327.375624] [] ? print_irqtrace_events+0x9d/0xa1 [ 327.375630] [] __might_sleep+0x19f/0x1a7 [ 327.375635] [] __do_page_fault+0x2a4/0x57c [ 327.375641] [] ? invalidate_inode_pages2_range+0x2e0/0x2f8 [ 327.375645] [] ? ext4_direct_IO+0x224/0x3c2 [ 327.375650] [] ? noalloc_get_block_write+0x57/0x57 [ 327.375654] [] ? ext4_readpages+0x41/0x41 [ 327.375659] [] ? time_hardirqs_off+0x1b/0x2f [ 327.375663] [] ? error_sti+0x5/0x6 [ 327.375667] [] ? trace_hardirqs_off_caller+0x1f/0x9e [ 327.375672] [] ? trace_hardirqs_off_thunk+0x3a/0x3c [ 327.375676] [] do_page_fault+0x9/0xb [ 327.375680] [] page_fault+0x22/0x30 [ 327.375685] [] ? kioctx_ring_unlock+0xd/0x5f [ 327.375689] [] batch_complete_aio+0x1c6/0x212 [ 327.375694] [] ? ext4_unwritten_wait+0x98/0x98 [ 327.375697] [] aio_complete_batch+0x125/0x132 [ 327.375702] [] ? ext4_unwritten_wait+0x98/0x98 [ 327.375705] [] do_io_submit+0x781/0x84b [ 327.375710] [] sys_io_submit+0xb/0xd [ 327.375715] [] system_call_fastpath+0x16/0x1b (and that BUG cascades into a second one: [ 327.375724] BUG: unable to handle kernel NULL pointer dereference at 0250 [ 327.375729] IP: [] kioctx_ring_unlock+0xd/0x5f [ 327.375733] PGD d0d36067 PUD da749067 PMD 0 [ 327.375740] Oops: 0002 [#1] PREEMPT SMP ... [ 327.375829] Call Trace: [ 327.375833] [] batch_complete_aio+0x1c6/0x212 [ 327.375838] [] ? ext4_unwritten_wait+0x98/0x98 [ 327.375842] [] aio_complete_batch+0x125/0x132 [ 327.375846] [] ? ext4_unwritten_wait+0x98/0x98 [ 327.375850] [] do_io_submit+0x781/0x84b [ 327.375855] [] sys_io_submit+0xb/0xd [ 327.375859] [] system_call_fastpath+0x16/0x1b [ 327.375861] Code: 00 50 48 8d 5f 90 48 81 c7 98 01 00 00 e8 0e 9c f0 ff 48 89 df e8 87 fd ff ff 58 5b 5d c3 55 48 89 e5 41 54 41 89 f4 53 48 89 fb <89> b3 50 02 00 00 48 8b 47 50 48 8b 38 e8 37 f9 ff ff 44 89 60 [ 327.375937] RIP [] kioctx_ring_unlock+0xd/0x5f [ 327.375942] RSP [ 327.375944] CR2: 0250 [ 327.375949] ---[ end trace b119850056dcfba4 ]--- pgp_6YQOcabUH.pgp Description: PGP signature
Re: next-20130117 - kernel BUG with aio
On Tue, 22 Jan 2013 21:43:27 +0800, Hillf Danton said:
> On Mon, Jan 21, 2013 at 9:24 PM, Valdis Kletnieks
> wrote:
> > Am seeing a reproducible BUG in the kernel with next-20130117
> > whenever I fire up VirtualBox. Unfortunately, I hadn't done that
> > in a while, so the last 'known good' kernel was next-20121203.
> >
> > I'm strongly suspecting one of Kent Overstreet's 32 patches against aio,
> > because 'git blame' shows those landing on Jan 12, and not much else
> > happening to fs/aio.c in ages.
> >
> Take a try?
> ---
> --- a/fs/aio.cTue Jan 22 21:37:54 2013
> +++ b/fs/aio.cTue Jan 22 21:43:58 2013
> @@ -683,6 +683,9 @@ static inline void kioctx_ring_unlock(st
> {
> struct aio_ring *ring;
>
> + if (!ctx)
> + return;
> +
> smp_wmb();
> /* make event visible before updating tail */
Well, things are improved - at least now it doesn't BUG :)
[ 534.879083] [ cut here ]
[ 534.879094] WARNING: at fs/aio.c:336 put_ioctx+0x1cb/0x252()
[ 534.879121] Call Trace:
[ 534.879129] [] warn_slowpath_common+0x7e/0x97
[ 534.879133] [] warn_slowpath_null+0x15/0x17
[ 534.879137] [] put_ioctx+0x1cb/0x252
[ 534.879142] [] ? __wake_up+0x3f/0x48
[ 534.879146] [] ? kill_ioctx_work+0x27/0x2b
[ 534.879150] [] sys_io_destroy+0x40/0x50
[ 534.879156] [] system_call_fastpath+0x16/0x1b
[ 534.879159] ---[ end trace a2c46a8bc9058404 ]---
Hopefully that tells you and Kent something. :)
pgpCB73Sy7pgh.pgp
Description: PGP signature
Re: kswapd0: wxcessive CPU usage
On Thu, 11 Oct 2012 10:52:28 +0200, Jiri Slaby said: > Hi, > > with 3.6.0-next-20121008, kswapd0 is spinning my CPU at 100% for 1 > minute or so. > [] ? put_super+0x25/0x40 > [] ? grab_super_passive+0x24/0xa0 > [] ? prune_super+0x149/0x1b0 > [] ? shrink_slab+0xa1/0x2d0 > [] ? kswapd+0x66d/0xb60 > [] ? try_to_free_pages+0x180/0x180 > [] ? kthread+0xc0/0xd0 > [] ? kthread_create_on_node+0x130/0x130 > [] ? ret_from_fork+0x7c/0x90 > [] ? kthread_create_on_node+0x130/0x130 I don't know what it is, I haven't finished bisecting it - but I can confirm that I started seeing the same problem 2 or 3 weeks ago. Note that said call trace does *NOT* require a suspend - I don't do suspend on my laptop and I'm seeing kswapd burn CPU with similar traces. # cat /proc/31/stack [] grab_super_passive+0x44/0x76 [] prune_super+0x3a/0x13c [] shrink_slab+0x95/0x301 [] kswapd+0x5c8/0x902 [] kthread+0x9d/0xa5 [] ret_from_fork+0x7c/0x90 [] 0x # cat /proc/31/stack [] put_super+0x29/0x2d [] drop_super+0x1b/0x20 [] prune_super+0x12a/0x13c [] shrink_slab+0x95/0x301 [] kswapd+0x5c8/0x902 [] kthread+0x9d/0xa5 [] ret_from_fork+0x7c/0x90 [] 0x So at least we know we're not hallucinating. :) pgps32HeZs9tF.pgp Description: PGP signature
