Re: [PATCHv5] mm: Fix calculation of dirtyable memory
* Sonny Rao [2012-11-19 10:44]: > Damien, thanks for testing and finding that bug. If you could, please > give this version a try, thanks. Tried it for a few hours (as soon as the min/max problem was suggested on the list) and the previous problems disappeared. -- Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: udevd cannot modprobe snd-hda-intel with 3.9.8
* Marc Haber [130701 17:50]: > The issue does not appear when one uses a Debian kernel, or uses the > configuration that Debian uses for its kernels to build a vanilla > kernel.org kernel. This has, after a gazillion of reoboots and > experimenting with man different blacklist entries and kernel > configuration, led me to the fact that this bug does not show if the > kernel is compiled with CONFIG_SND_SUPPORT_OLD_API=y. > So it was my error to dump backwards compatibility and to remove the > old api support. I have now set CONFIG_SND_SUPPORT_OLD_API=y again and > everything is fine. Even with this option, I get the problem, so this is not enough... -- Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [BUG] 3.10.[01] modprobe snd-... hangs
* Takashi Iwai [2013-07-16 08:43]: > At Tue, 16 Jul 2013 15:11:51 +0930, > Rusty Russell wrote: > > Philipp Matthias Hahn writes: > > > Hello, > > > My x86_64 systems has some trouble loading some ALSA snd-* modules since > > > the upgrade to 3.10.[01]: Several automatic modprobe calls hang, but > > > loading snd-intel-hda and snd-audio-usb by hand still works. > > Not a known problem to me, at least. Perhaps it's a dep loop somehow. > I remember that someone reported it being Debian specific snd-seq-oss > loading stuff. There is also additional information here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660803 -- Damien Wyart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix env->src_cpu for active migration
Hi,
I tested this on top of 3.8-rc7 and this made the machine (x86_64, Core
i7 920) unable to boot (very early as nothing at all is displayed on
screen). Nothing in the kernel log (after booting with a working
kernel).
Double-checked by just backing out only this patch and this made the
machine boot again.
Damien
> need_active_balance uses env->src_cpu which is set only if there is more
> than 1 task on the run queue. We must set the src_cpu field unconditionnally
> otherwise the test "env->src_cpu > env->dst_cpu" will always fail if there is
> only 1 task on the run queue
>
> Signed-off-by: Vincent Guittot
> ---
> kernel/sched/fair.c |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 81fa536..32938ea 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -5044,6 +5044,10 @@ redo:
>
> ld_moved = 0;
> lb_iterations = 1;
> +
> + env.src_cpu = busiest->cpu;
> + env.src_rq= busiest;
> +
> if (busiest->nr_running > 1) {
> /*
>* Attempt to move tasks. If find_busiest_group has found
> @@ -5052,8 +5056,6 @@ redo:
>* correctly treated as an imbalance.
>*/
> env.flags |= LBF_ALL_PINNED;
> - env.src_cpu = busiest->cpu;
> - env.src_rq= busiest;
> env.loop_max = min(sysctl_sched_nr_migrate,
> busiest->nr_running);
>
> update_h_load(env.src_cpu);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix env->src_cpu for active migration
* Vincent Guittot [2013-02-13 13:08]: > Damien, > Regarding your sched_domain config and especially the flags field, you > should not be impacted by my patch because > - need_active_balance is the only new place that use env->src_cpu in > the load_balance function > - and your machine will never test the condition: "env->src_cpu > > env->dst_cpu" in need_active_balance because SD_ASYM_PACKING is not > set in your config > Have you tested the patch with others that could have modified the > load_balance function ? Yes, sorry, I should have been more precise in my initial report: your patch was not applied on top of vanilla 3.8-rc7, but a few other patches were also present. Seems the ones impacting load_balance are from Frederic's nohz work (http://git.kernel.org/?p=linux/kernel/git/frederic/linux-dynticks.git;a=shortlog;h=refs/heads/3.8-rc6-nohz4) The patches from there modifying load_balance are: - "sched: Update nohz rq clock before searching busiest group on load balancing" - "sched: Update clock of nohz busiest rq before balancing" In this test, I did not use any kernel parameter related to this patchset (full_nohz, etc.). I am adding Frederic in Cc, not sure if the breakage is to be investigated on your side or his... Thanks for your explanations, -- Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix env->src_cpu for active migration
* Vincent Guittot [2013-02-13 18:49]: > I have look into Frederic's tree but i didn't find any reason that > could explain your problem. May be Frederic will have some ideas > I have also tested his branch with and without my patch and both > kernel are booting (on an ARM platform without using the full_nohz > feature ). I have faced a conflict when i have applied my patch on his > branch as we insert code at the same place. You should have faced the > same conflict. How have you solved it ? Bingo, that was the problem in my setup: as the patch was applied through a script with others, I had missed the error message about the conflict (I have also another conflict which can be safely ignored so the new one did not catch my eye)... So the patch was only half-applied, and the final code is broken. How did you solve the conflict (I am not a scheduler expert)? I can retry running the patched kernel with your resolution, to check if everything is ok. Thanks and sorry for this, -- Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched: fix env->src_cpu for active migration
> Bingo, that was the problem in my setup: as the patch was applied
> through a script with others, I had missed the error message about the
> conflict (I have also another conflict which can be safely ignored so
> the new one did not catch my eye)... So the patch was only
> half-applied, and the final code is broken.
> How did you solve the conflict (I am not a scheduler expert)? I can
> retry running the patched kernel with your resolution, to check if
> everything is ok.
After looking a bit more, the conflict resolution seemed straighforward,
so I gave it a go. The attached version booted fine, so the initial
problem was purely PEBCAK... Sorry for the noise!
--
Damien
--- a/kernel/sched/fair.c 2013-02-06 20:49:17.447613049 +0100
+++ b/kernel/sched/fair.c 2013-02-13 20:52:37.409507417 +0100
@@ -5060,6 +5060,10 @@
ld_moved = 0;
lb_iterations = 1;
clock_updated = 0;
+
+ env.src_cpu = busiest->cpu;
+ env.src_rq= busiest;
+
if (busiest->nr_running > 1) {
/*
* Attempt to move tasks. If find_busiest_group has found
@@ -5068,8 +5072,6 @@
* correctly treated as an imbalance.
*/
env.flags |= LBF_ALL_PINNED;
- env.src_cpu = busiest->cpu;
- env.src_rq= busiest;
env.loop_max = min(sysctl_sched_nr_migrate, busiest->nr_running);
update_h_load(env.src_cpu);
Re: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7
Hello, * Ingo Molnar <[EMAIL PROTECTED]> [2007-11-19 16:17]: > By popular demand, here is release -v24 of the CFS scheduler patch. It > is a full backport of the latest & greatest scheduler code to > v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7. The patches can be > downloaded from the usual place: > http://people.redhat.com/mingo/cfs-scheduler/ > As usual, any sort of feedback, bugreport, fix and suggestion is more > than welcome! Testing sched-cfs-v2.6.24-rc3-v24.patch on top of 2.6.24-rc3-git1 (ignored the two "already applied" messages coming from git1 commits), I get a 1.00 minimum load in top, coming from the load_balance_mo thread staying in D-state. I get this on 2 different computers with similar configs, so I am attaching one of them here. -- Damien Wyart # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc3-git1-cfs-v24-20112007dw # Tue Nov 20 10:20:40 2007 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=15 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_VSMP is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CO
Re: writeout stalls in current -git
Hello, > > > Ok, so it's not synchronous writes that we are doing - we're just > > > submitting bio's tagged as WRITE_SYNC to get the I/O issued > > > quickly. The "synchronous" nature appears to be coming from higher > > > level locking when reclaiming inodes (on the flush lock). It > > > appears that inode write clustering is failing completely so we > > > are writing the same block multiple times i.e. once for each inode > > > in the cluster we have to write. > > Works for me. The only remaining stalls are sub second and look > > completely valid, considering the amount of files being removed. > > > Tested-by: Torsten Kaiser <[EMAIL PROTECTED]> * David Chinner <[EMAIL PROTECTED]> [2007-11-08 11:38]: > Great - thanks for reporting the problem and testing the fix. This patch has not yet made its way into 2.6.24 (rc3). Is it intended? Maybe the fix can wait for 2.6.25, but wanted to make sure... -- Damien Wyart - 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: [patch/backport] CFS scheduler, -v24, for v2.6.24-rc3, v2.6.23.8, v2.6.22.13, v2.6.21.7
> > Testing sched-cfs-v2.6.24-rc3-v24.patch on top of 2.6.24-rc3-git1 > > (ignored the two "already applied" messages coming from git1 > > commits), I get a 1.00 minimum load in top, coming from the > > load_balance_mo thread staying in D-state. I get this on 2 different > > computers with similar configs, so I am attaching one of them here. * Ingo Molnar <[EMAIL PROTECTED]> [071120 13:55]: > does the patch below fix that problem for you? Yes, it does. Thanks for your answer. Damien > Index: linux/kernel/sched.c > === > --- linux.orig/kernel/sched.c > +++ linux/kernel/sched.c > @@ -7138,7 +7138,7 @@ static int load_balance_monitor(void *un > else if (timeout < sysctl_sched_max_bal_int_shares) > timeout *= 2; > > - msleep(timeout); > + msleep_interruptible(timeout); > } > > return 0; > - 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/
Important regression with XFS update for 2.6.24-rc6
Hello, As a follow-up to <http://marc.info/?l=linux-kernel&m=119796120524618&w=2> (LKML seems down right now so I am not linking to it), I have detected an important problem with these two patches: after applying them by hand (downloaded them raw from SGI's gitweb) on top of 2.6.24-rc5-git5 (they have not yet been pulled into mainline by Linux as of this morning) for testing purposes, I noticed upon reboot that "ls -l" on directories with many files and subdirectories (around 5000 entries) takes several hundreds of MB in RAM and then dies with "memory exhausted" error. I also noticed that ldconfig takes a lot of time to complete, and firefox seems also to eat much more memory than usual. Reverting the two patches (going back to vanilla rc5-git5) makes these problems go away. I am not able to test right now if only one of the patches is bogus or if both of them are concerned. As the symptoms are easy to reproduce, I guess this is some kind of brown paper bag bug and will be easy for XFS experts to spot. Best, -- Damien Wyart -- 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: Important regression with XFS update for 2.6.24-rc6
* David Chinner <[EMAIL PROTECTED]> [071218 13:24]: > Ok. I haven't noticed anything wrong with directories up to about > 250,000 files in the last few days. The ls -l I just did on > a directory with 15000 entries (btree format) used about 5MB of RAM. > extent format directories appear to work fine as well (tested 500 > entries). Ok, nice to know the problem is not so frequent. > Can you: > a) isolate the problem to one patch or the other. My guess > would be the directory mod, but. Yes, it is indeed the directory patch. But even if I still sometimes get huge memory usage with ls (using the patched kernel), this is quite rare, and the problem is now mainly getting entries in the listing repeated, and the ls process taking longer than without the patch. But this is mainly after booting. I guess the cache plays a role and even using drop_caches, I can't reproduce the problem. Only on fresh reboot do I get it systematically, but much less often the memory problem. And as said earlier, after fresh boot on rc5-git5 without the directory patch, the ls -l goes normal (no repeated entries). > b) show your working ;) Sorry, I forgot this part in my initial report. > - what platform (i386, x86_64, etc) i386. > - what debug options Nothing special, the kernel has 4K stacks, and xfs partitions are mounted with noatime,nodiratime. > - commands and output that shows the problem It is mainly "ls -l" in a quite crowded directory. > - strace of ls -l going bad > - xfs_info from filesystem in question I have put the files at http://damien.wyart.free.fr/xfs/ strace_xfs_problem.1.gz and strace_xfs_problem.2.gz have been created with the problematic kernel, and are quite bigger than strace_xfs_problem.normal.gz, which has been created with the vanilla rc5-git5. There is also xfs_info. I can provide further details if needed (maybe kernel config, but nothing special on the xfs side), but I confirm the behavior is different with and without the directory patch (041388b54ed95cd169546bd83bacd08ee32bd7ea on oss.sgi), and doesn't look normal with the patch. -- Damien Wyart -- 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: Important regression with XFS update for 2.6.24-rc6
* David Chinner <[EMAIL PROTECTED]> [071219 11:45]: > Can someone pass me a brown paper bag, please? My first impression on this bug was not so wrong, after all ;-) > That also explains why we haven't seen it - it requires the user > buffer to fill on the first entry of a backing buffer and so it is > largely dependent on the pattern of name lengths, page size and > filesystem block size aligning just right to trigger the problem. I guess I was lucky to trigger it quite easily... > Can you test this patch, Damien? Works fine, all the bad symptoms have disappeared and strace output is normal. So you can add: Tested-by: Damien Wyart <[EMAIL PROTECTED]> -- Damien -- 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: pci=assign-busses
Hello, Another report of the same kind. Box is an HP/Compaq nx7400. Before/after use of pci= option dmesgs attached. -- Damien Wyart Jul 23 11:41:06 dalpdw2 kernel: Linux version 2.6.23-rc1-23072007dw ([EMAIL PROTECTED]) (gcc version 4.1.3 20070629 (prerelease) (Debian 4.1.2-13)) #1 SMP Mon Jul 23 09:21:55 CEST 2007 Jul 23 11:41:06 dalpdw2 kernel: BIOS-provided physical RAM map: Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: - 0009fc00 (usable) Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: 0009fc00 - 000a (reserved) Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: 000e - 0010 (reserved) Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: 0010 - 5f7d (usable) Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: 5f7d - 5f7e5600 (reserved) Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: 5f7e5600 - 5f7f8000 (ACPI NVS) Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: 5f7f8000 - 5f80 (reserved) Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: fec0 - fec01000 (reserved) Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: fed2 - fed9b000 (reserved) Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: feda - fedc (reserved) Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: fee0 - fee01000 (reserved) Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: ffb0 - ffc0 (reserved) Jul 23 11:41:06 dalpdw2 kernel: BIOS-e820: fff0 - 0001 (reserved) Jul 23 11:41:06 dalpdw2 kernel: 631MB HIGHMEM available. Jul 23 11:41:06 dalpdw2 kernel: 896MB LOWMEM available. Jul 23 11:41:06 dalpdw2 kernel: Entering add_active_range(0, 0, 391120) 0 entries of 256 used Jul 23 11:41:06 dalpdw2 kernel: Zone PFN ranges: Jul 23 11:41:06 dalpdw2 kernel: DMA 0 -> 4096 Jul 23 11:41:06 dalpdw2 kernel: Normal 4096 -> 229376 Jul 23 11:41:06 dalpdw2 kernel: HighMem229376 -> 391120 Jul 23 11:41:06 dalpdw2 kernel: Movable zone start PFN for each node Jul 23 11:41:06 dalpdw2 kernel: early_node_map[1] active PFN ranges Jul 23 11:41:06 dalpdw2 kernel: 0:0 -> 391120 Jul 23 11:41:06 dalpdw2 kernel: On node 0 totalpages: 391120 Jul 23 11:41:06 dalpdw2 kernel: DMA zone: 32 pages used for memmap Jul 23 11:41:06 dalpdw2 kernel: DMA zone: 0 pages reserved Jul 23 11:41:06 dalpdw2 kernel: DMA zone: 4064 pages, LIFO batch:0 Jul 23 11:41:06 dalpdw2 kernel: Normal zone: 1760 pages used for memmap Jul 23 11:41:06 dalpdw2 kernel: Normal zone: 223520 pages, LIFO batch:31 Jul 23 11:41:06 dalpdw2 kernel: HighMem zone: 1263 pages used for memmap Jul 23 11:41:06 dalpdw2 kernel: HighMem zone: 160481 pages, LIFO batch:31 Jul 23 11:41:06 dalpdw2 kernel: Movable zone: 0 pages used for memmap Jul 23 11:41:06 dalpdw2 kernel: DMI 2.4 present. Jul 23 11:41:06 dalpdw2 kernel: ACPI: RSDP 000F7BD0, 0024 (r2 HP) Jul 23 11:41:06 dalpdw2 kernel: ACPI: XSDT 5F7E57C4, 0074 (r1 HPQOEM SLIC-MPC 1 HP 1) Jul 23 11:41:06 dalpdw2 kernel: ACPI: FACP 5F7E5684, 00F4 (r4 HP 30A2 3 HP 1) Jul 23 11:41:06 dalpdw2 kernel: ACPI: DSDT 5F7E5AC0, F9BB (r1 HP nx7400 1 MSFT 10E) Jul 23 11:41:06 dalpdw2 kernel: ACPI: FACS 5F7F7E80, 0040 Jul 23 11:41:06 dalpdw2 kernel: ACPI: SLIC 5F7E5838, 0176 (r1 HPQOEM SLIC-MPC 1 HP 1) Jul 23 11:41:06 dalpdw2 kernel: ACPI: HPET 5F7E59B0, 0038 (r1 HP 30A2 1 HP 1) Jul 23 11:41:06 dalpdw2 kernel: ACPI: APIC 5F7E59E8, 0068 (r1 HP 30A2 1 HP 1) Jul 23 11:41:06 dalpdw2 kernel: ACPI: MCFG 5F7E5A50, 003C (r1 HP 30A2 1 HP 1) Jul 23 11:41:06 dalpdw2 kernel: ACPI: TCPA 5F7E5A8C, 0032 (r2 HP 30A2 1 HP 1) Jul 23 11:41:06 dalpdw2 kernel: ACPI: SSDT 5F7F547B, 0326 (r1 HP HPQSAT 1 MSFT 10E) Jul 23 11:41:06 dalpdw2 kernel: ACPI: SSDT 5F7F5FB4, 025F (r1 HP Cpu0Tst 3000 INTL 20060317) Jul 23 11:41:06 dalpdw2 kernel: ACPI: SSDT 5F7F6213, 00A6 (r1 HP Cpu1Tst 3000 INTL 20060317) Jul 23 11:41:06 dalpdw2 kernel: ACPI: SSDT 5F7F62B9, 04D7 (r1 HPCpuPm 3000 INTL 20060317) Jul 23 11:41:06 dalpdw2 kernel: ACPI: PM-Timer IO Port: 0x1008 Jul 23 11:41:06 dalpdw2 kernel: ACPI: Local APIC address 0xfee0 Jul 23 11:41:06 dalpdw2 kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Jul 23 11:41:06 dalpdw2 kernel: Processor #0 6:15 APIC version 20 Jul 23 11:41:06 dalpdw2 kernel: ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Jul 23 11:41:06 dalpdw2 kernel: Processor #1 6:15 APIC version 20 Jul 23 11:41:06 dalpdw2 kernel: ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) Jul 23 11:41:06 dalpdw2 kernel: ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) Jul 23 11:41:06 dalpdw2 kernel: ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) Jul 23 11:41:06 dalpdw2 ke
Re: Linux 2.6.21-rc2
* Linus Torvalds <[EMAIL PROTECTED]> [070228 06:16]: > Anyway, I really hope the thing starts calming down now, and everybody > should take a hard look at the regressions lists that Adrian has > started sending out. We already fixed some of them, but there is more > to go.. Ingo's patch correcting a bug in the SMT scheduler (http://lkml.org/lkml/2007/2/26/103) seems to have been missed. It is quite important when using dynticks. -- Damien Wyart - 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: 2.6.20-rc1-mm1
> > Also, I got panics when unmounting reiser4 filesystems with > > 2.6.20-rc1-mm1 but I guess this is related to your waring about > > reiser4 being broken in 2.6.19-mm1 (even if it is not listed in > > notes for 2.6.20-rc1-mm1)... I attach dmesg and config, but the > > reiser4 panics did not get logged and I am not able to reboot on > > 2.6.20-rc1-mm1 right now. For the moment, I mainly wanted to report > > the xfs messages which seems a bit suspect. > The reiser4 failure is unexpected. Could you please see if you can > capture a trace, let the people at [EMAIL PROTECTED] know? Ok, I've handwritten the messages, here they are : reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom (fs/reiser4/txmngr.c:1087) (zam-597) write log failed (-5) [ got 2 copies of them because I have 2 reiser4 fs) I got them mainly when I try to reboot or halt the machine, and the process doesn't finish, the computer gets stuck after the reiser4 messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. -- Damien Wyart - 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: 2.6.20-rc1-mm1
> > > The reiser4 failure is unexpected. Could you please see if you can > > > capture a trace, let the people at [EMAIL PROTECTED] know? > > Ok, I've handwritten the messages, here they are : > > reiser4 panicked cowardly : reiser4[umount(2451)] : commit_current_atom > > (fs/reiser4/txmngr.c:1087) (zam-597) > > write log failed (-5) > > [ got 2 copies of them because I have 2 reiser4 fs) > > I got them mainly when I try to reboot or halt the machine, and the > > process doesn't finish, the computer gets stuck after the reiser4 > > messages. This is only with 2.6.20-mm1, not 2.6.19-rc6-mm2. * Laurent Riffard <[EMAIL PROTECTED]> [2006-12-18 09:03]: > fix-sense-key-medium-error-processing-and-retry.patch seems to be the > culprit. > Reverting it fix those reiser4 panics for me. Damien, could you confirm > please ? Yes, this fixes it too on my side. Thanks for this tracking ! -- Damien Wyart - 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: 2.6.20-rc5: known unfixed regressions
* Adrian Bunk <[EMAIL PROTECTED]> [070113 08:11]:
> This still leaves the old regressions we have not yet fixed...
> This email lists some known regressions in 2.6.20-rc5 compared to 2.6.19.
> Subject: BUG: scheduling while atomic: hald-addon-stor/...
> cdrom_{open,release,ioctl} in trace
> References : http://lkml.org/lkml/2006/12/26/105
> http://lkml.org/lkml/2006/12/29/22
> http://lkml.org/lkml/2006/12/31/133
> Submitter : Jon Smirl <[EMAIL PROTECTED]>
> Damien Wyart <[EMAIL PROTECTED]>
> Aaron Sethman <[EMAIL PROTECTED]>
> Status : unknown
I have not seen the problem since using rc3, so I guess it is ok now.
Maybe the commit 9414232fa0cc28e2f51b8c76d260f2748f7953fc has fixed the
problem, but I am not 100% sure.
--
Damien Wyart
-
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/
2.6.22-rc2 and libata/shutdown
Hello, After trying 2.6.22-rc2, I noticed the warning message from libata about upgrading shutdown(8). First, I have two SATA disks, and get the warning for only one of them. Second, I double-checked the source of shutdown for my distro (Debian unstable), and do not see anything related to issueing STANDBYNOW. So, is the warning bogus, or could something else trigger the problem on one disk only (if getting only one message means that the problem is only detected on one disk). As these messages come very late in the shutdown process, I do not have an easy way to reproduce them. Thanks in advance, -- Damien Wyart - 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: [patch] CFS scheduler, -v8
Hello, * Ingo Molnar <[EMAIL PROTECTED]> [2007-05-03 15:02]: > great! So it seems -v8 does improve OpenGL handling too :-) What are your thoughts/plans concerning merging CFS into mainline ? Is it a bit premature to get it into 2.6.22 ? I remember Linus was ok to change the default scheduler rapidly (the discussion was about sd at that time) to get more testing than in -mm. -- Damien Wyart - 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/
ACPI power off regression in 2.6.23-rc8 (NOT in rc7)
Hello, After testing rc8, I noticed that I couldn't power off the computer directly, it only got halted and I had to press the power button manually. Just before displaying "System halted", the following message is displayed: ACPI : PCI interrupt for device :02:08.0 disabled I had to first revert 5a50fe709d527f31169263e36601dd83446d5744 then f216cc3748a3a22c2b99390fddcdafa0583791a2 (handling of Sx states) to recover previous behaviour. Attached are the dmesg for rc7, rc8 and rc8 with the two patches reverted. -- Damien Wyart Linux version 2.6.23-rc7-24092007dw ([EMAIL PROTECTED]) (gcc version 4.2.1 (Debian 4.2.1-5)) #1 SMP Mon Sep 24 07:35:33 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 7ff74000 (usable) BIOS-e820: 7ff74000 - 7ff76000 (ACPI NVS) BIOS-e820: 7ff76000 - 7ff97000 (ACPI data) BIOS-e820: 7ff97000 - 8000 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fecf - fecf1000 (reserved) BIOS-e820: fed2 - fed9 (reserved) BIOS-e820: fee0 - fee1 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 1151MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000fe710 Entering add_active_range(0, 0, 524148) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 HighMem229376 -> 524148 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 524148 On node 0 totalpages: 524148 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 2302 pages used for memmap HighMem zone: 292470 pages, LIFO batch:31 Movable zone: 0 pages used for memmap DMI 2.3 present. ACPI: RSDP 000FEB90, 0014 (r0 DELL ) ACPI: RSDT 000FD1CA, 0034 (r1 DELL8300 8 ASL61) ACPI: FACP 000FD1FE, 0074 (r1 DELL8300 8 ASL61) ACPI: DSDT FFFC6E75, 2426 (r1 DELLdt_ex 1000 MSFT 10D) ACPI: FACS 7FF74000, 0040 ACPI: SSDT FFFC929B, 00A7 (r1 DELLst_ex 1000 MSFT 10D) ACPI: APIC 000FD272, 006C (r1 DELL8300 8 ASL61) ACPI: BOOT 000FD2DE, 0028 (r1 DELL8300 8 ASL61) ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:3 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:3 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x01] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 8800 (gap: 8000:7ec0) Built 1 zonelists in Zone order. Total pages: 520054 Kernel command line: root=/dev/sdb2 ro vga=0x307 selinux=0 elevator=cfq video=vesafb:mtrr:3 mapped APIC to b000 (fee0) mapped IOAPIC to a000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c0425000 soft=c0423000 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2992.558 MHz processor. Console: colour dummy device 80x25 console [tty0] enabled Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 2074780k/2096592k available (2175k kernel code, 20712k reserved, 815k data, 192k init, 1179088k highmem) virtual kernel memory layout: fixmap : 0xfff9b000 - 0xf000 ( 400 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xf880 - 0xff7fe000 ( 111 MB) lowmem : 0xc000 - 0xf800 ( 896 MB) .init : 0xc03f - 0xc042 ( 192 kB) .data : 0xc031ff34 - 0xc03ebd04 ( 815 kB) .text : 0xc010 - 0xc031ff34 (2175 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=22, HWalign=64, Order=0-1, MinObjects=4, CPUs=2, Nodes=1 Calibrating delay using timer specific routine.. 5987.54 BogoMIPS (lpj=2993774) Mount-cache hash table entries: 512 CPU: After generic identify, caps: bfebfbff 041d monitor/mwait feature present. using mwait in idle threads. CPU
Re: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)
Hello, > On 9/25/07, Alexey Starikovskiy <[EMAIL PROTECTED]> wrote: > > Do you have CONFIG_ACPI_SLEEP enabled in your .config? * Torsten Kaiser <[EMAIL PROTECTED]> [2007-09-25 11:08]: > I'm answering that too, because I suspect that my "2.6.23-rc7-mm1 does > not power off"-error might have the same cause. > No, I do not have CONFIG_ACPI_SLEEP set, > because I do not have CONFIG_PM_SLEEP set, > because I do not want SUSPEND and/or HIBERNATION. Same answer from my side: I do not have CONFIG_ACPI_SLEEP for the same reason (and this worked fine without them in rc7). I do not think these settings should have changed between rc7 and rc8. -- Damien Wyart - 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: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)
> > No, I do not have CONFIG_ACPI_SLEEP set, > > because I do not have CONFIG_PM_SLEEP set, > > because I do not want SUSPEND and/or HIBERNATION. > Same answer from my side: I do not have CONFIG_ACPI_SLEEP for the same > reason (and this worked fine without them in rc7). I do not think > these settings should have changed between rc7 and rc8. Also, another test I just did: on another computer, rc8 is fine regarding ACPI power off, even if CONFIG_ACPI_SLEEP is not set. I can provide config if needed. Best, -- Damien Wyart - 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: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)
> On the box that fails to power off, can you please test -rc8 with these two > commits reverted: > commit 5a50fe709d527f31169263e36601dd83446d5744 > ACPI: suspend: consolidate handling of Sx states addendum > commit f216cc3748a3a22c2b99390fddcdafa0583791a2 > ACPI: suspend: consolidate handling of Sx states. > and see if it works? I had done these tests in the first place (see my first mail), so yes, reverting makes the box power off fine. Will test this evening the patch you pointed in your next message. -- Damien Wyart - 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: ACPI power off regression in 2.6.23-rc8 (NOT in rc7)
> Will test this evening the patch you pointed in your next message. Ok, with both patches (including the very latest one from Alexey --- tried the "stylistically correct" one), machine halts fine again. Thanks to all for having looked at this! -- Damien Wyart - 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: [git pull] vfs.git bits and pieces
> > BTW, something odd happened to mm/memory.c - either a mangled patch > > or a lost followup: > > commit ea1e7ed33708 > > mm: create a separate slab for page->ptl allocation > > Fair enough, and yes, it does create that separate slab. The problem > > is, it's still using kmalloc/kfree for those beasts - > > page_ptl_cachep isn't used at all... * Linus Torvalds [2013-11-20 14:33]: > Ok, it looks straightforward enough to just replace the kmalloc/kfree > with using a slab allocation using the page_ptl_cachep pointer. I'd do > it myself, but I would like to know how it got lost? Also, much > testing to make sure the cachep is initialized early enough. The initial sending had the proper hunks at the end, so something really got lost afterwards... https://lkml.org/lkml/2013/10/22/129 -- Damien Wyart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Machine freeze on latest Linus kernel, seems related to nouveau
Hi, I am running the latest kernel from Linus. Once yesterday and once today, I got a freeze of my machine. The first time, I could reboot with sysrq, but not the second one (completely unresponsive). The first time,, there was nothng in the logs, but today, I got some traces which I attach to this email. I can provide more details if needed ; the card is GeForce 9600 GT and the OS Debian Sid. Thanks in advance for any feedback. Damien Wyart May 16 08:30:27 brouette kernel: BUG: unable to handle kernel paging request at c9001590 May 16 08:30:27 brouette kernel: IP: [] iowrite32+0x38/0x40 May 16 08:30:27 brouette kernel: PGD 1b880f067 PUD 1b8850067 PMD b979e067 PTE 0 May 16 08:30:27 brouette kernel: Oops: 0002 [#1] PREEMPT SMP May 16 08:30:27 brouette kernel: Modules linked in: nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_dscp xt_mark cls_flow cls_fw sch_sfq sch_htb xt_helper xt_length nf_conntrack_ftp nf_conntrack ip6table_mangle ip6_tables iptable_mangle ip_tables x_tables cpufreq_powersave cpufreq_userspace cpufreq_conservative deadline_iosched binfmt_misc snd_usb_audio snd_usbmidi_lib snd_hwdep hid_roccat_konepure hid_roccat hid_roccat_common hid_generic usbhid nouveau snd_hda_codec_realtek snd_hda_codec_generic snd_ca0106 wmi snd_ac97_codec video ac97_bus snd_seq_dummy snd_seq_midi i2c_algo_bit snd_seq_oss ttm snd_seq_midi_event drm_kms_helper snd_seq drm i2c_core snd_rawmidi backlight snd_seq_device snd_hda_intel sr_mod ehci_pci snd_hda_controller uhci_hcd pcspkr ehci_hcd cdrom usbcore snd_hda_codec snd_pcm_oss snd_mixer_oss nvidiafb snd_pcm snd_timer vgastate evdev usb_common acpi_cpufreq loop fuse autofs4 May 16 08:30:27 brouette kernel: CPU: 3 PID: 31253 Comm: plugin-containe Tainted: P O 3.15.0-rc5 #1 May 16 08:30:27 brouette kernel: Hardware name: System manufacturer System Product Name/P6T SE, BIOS 080803/08/2010 May 16 08:30:27 brouette kernel: task: 8800baa2f1c0 ti: 880171aa task.ti: 880171aa May 16 08:30:27 brouette kernel: RIP: 0010:[] [] iowrite32+0x38/0x40 May 16 08:30:27 brouette kernel: RSP: 0018:880171aa1ba0 EFLAGS: 00010292 May 16 08:30:27 brouette kernel: RAX: 880055737600 RBX: 88016d934600 RCX: May 16 08:30:27 brouette kernel: RDX: c9001590 RSI: c9001590 RDI: May 16 08:30:27 brouette kernel: RBP: 880171aa1ba8 R08: a054de60 R09: May 16 08:30:27 brouette kernel: R10: R11: 000f R12: 00060004 May 16 08:30:27 brouette kernel: R13: R14: 880171aa1be8 R15: May 16 08:30:27 brouette kernel: FS: 7f02048fca40() GS:8801bfc6() knlGS: May 16 08:30:27 brouette kernel: CS: 0010 DS: ES: CR0: 80050033 May 16 08:30:27 brouette kernel: CR2: c9001590 CR3: b0ee5000 CR4: 07e0 May 16 08:30:27 brouette kernel: Stack: May 16 08:30:27 brouette kernel: a047ee3f 880171aa1bb8 a047bf25 880171aa1c18 May 16 08:30:27 brouette kernel: a047c1c6 010071aa1be0 a0561bb0 1de8d000 May 16 08:30:27 brouette kernel: 880055737600 8800b9500200 8800bb263440 May 16 08:30:27 brouette kernel: Call Trace: May 16 08:30:27 brouette kernel: [] ? nouveau_barobj_wr32+0xf/0x20 [nouveau] May 16 08:30:27 brouette kernel: [] _nouveau_gpuobj_wr32+0x25/0x30 [nouveau] May 16 08:30:27 brouette kernel: [] nouveau_gpuobj_create_+0x1c6/0x2c0 [nouveau] May 16 08:30:27 brouette kernel: [] nouveau_engctx_create_+0x24f/0x2a0 [nouveau] May 16 08:30:27 brouette kernel: [] nv50_graph_context_ctor+0x3c/0x80 [nouveau] May 16 08:30:27 brouette kernel: [] nouveau_object_ctor+0x2d/0xc0 [nouveau] May 16 08:30:27 brouette kernel: [] nouveau_object_new+0xeb/0x200 [nouveau] May 16 08:30:27 brouette kernel: [] nouveau_abi16_ioctl_grobj_alloc+0x68/0xe0 [nouveau] May 16 08:30:27 brouette kernel: [] drm_ioctl+0x1d8/0x5d0 [drm] May 16 08:30:27 brouette kernel: [] ? nouveau_abi16_ioctl_channel_free+0xa0/0xa0 [nouveau] May 16 08:30:27 brouette kernel: [] ? do_mmap_pgoff+0x2c2/0x390 May 16 08:30:27 brouette kernel: [] nouveau_drm_ioctl+0x9/0x10 [nouveau] May 16 08:30:27 brouette kernel: [] do_vfs_ioctl+0x2e0/0x4c0 May 16 08:30:27 brouette kernel: [] ? __fget+0x69/0xb0 May 16 08:30:27 brouette kernel: [] SyS_ioctl+0x81/0xa0 May 16 08:30:27 brouette kernel: [] system_call_fastpath+0x16/0x1b May 16 08:30:27 brouette kernel: Code: 81 fe 00 00 01 00 76 0b 0f b7 d6 89 f8 ef c3 0f 1f 40 00 55 48 c7 c6 9a a9 59 81 48 89 d7 48 89 e5 e8 1d fe ff ff 5d c3 0f 1f 00 <89> 3e c3 0f 1f 44 00 00 48 81 ff ff ff 03 00 77 37 48 81 ff 00 May 16 08:30:27 brouette kernel: RIP [] iowrite32+0x38/0x40 May 16 08:30:27 brouette kernel: RSP May 16 08:30:27 brouette kernel: CR2: c9001590 May 16 08:30:27 brouette kernel: ---[ end trace 3669ad1ce8
Re: Machine freeze on latest Linus kernel, seems related to nouveau
Hi; After further tests, I can reproduce the problem on 3.14.4 also, mainly by visiting the following URL with Firefox (29.0.1) : http://lavieestmaloptimisee.blogspot.fr/ Firefox becomes unresponsive and I get some messages in the kernel log : May 17 20:01:36 brouette kernel: BUG: unable to handle kernel paging request at c9001530 May 17 20:01:36 brouette kernel: IP: [] iowrite32+0x38/0x40 May 17 20:01:36 brouette kernel: PGD 1b880f067 PUD 1b8850067 PMD 1b6cfd067 PTE 0 May 17 20:01:36 brouette kernel: Oops: 0002 [#1] PREEMPT SMP May 17 20:01:36 brouette kernel: Modules linked in: usb_storage nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_dscp xt_mark cls_flow cls_fw sch_sfq sch_htb xt_helper xt_length nf_conntrack_ftp nf_conntrack ip6table_mangle ip6_tables iptable_mangle ip_tables x_tables cpufreq_powersave cpufreq_userspace cpufreq_conservative deadline_iosched binfmt_misc hid_roccat_konepure hid_roccat hid_roccat_common hid_generic snd_usb_audio snd_usbmidi_lib usbhid snd_hwdep nouveau snd_hda_codec_realtek snd_hda_codec_generic wmi snd_ca0106 video i2c_algo_bit snd_ac97_codec ac97_bus snd_seq_dummy snd_seq_midi snd_seq_oss ttm snd_seq_midi_event drm_kms_helper snd_seq drm i2c_core backlight snd_rawmidi snd_hda_intel snd_hda_codec snd_seq_device sr_mod snd_pcm_oss pcspkr cdrom nvidiafb snd_mixer_oss vgastate snd_pcm snd_timer ehci_pci uhci_hcd ehci_hcd usbcore evdev usb_common acpi_cpufreq loop fuse autofs4 May 17 20:01:36 brouette kernel: CPU: 1 PID: 12671 Comm: plugin-containe Tainted: P O 3.14.4 #1 May 17 20:01:36 brouette kernel: Hardware name: System manufacturer System Product Name/P6T SE, BIOS 080803/08/2010 May 17 20:01:36 brouette kernel: task: 8800ba42a160 ti: 8801ac584000 task.ti: 8801ac584000 May 17 20:01:36 brouette kernel: RIP: 0010:[] [] iowrite32+0x38/0x40 May 17 20:01:36 brouette kernel: RSP: 0018:8801ac585b90 EFLAGS: 00010292 May 17 20:01:36 brouette kernel: RAX: 8800813e65a0 RBX: 8801b5aed600 RCX: May 17 20:01:36 brouette kernel: RDX: c9001530 RSI: c9001530 RDI: May 17 20:01:36 brouette kernel: RBP: 8801ac585b98 R08: a0423100 R09: May 17 20:01:36 brouette kernel: R10: R11: 000f R12: 00060004 May 17 20:01:36 brouette kernel: R13: R14: 8801ac585bd8 R15: May 17 20:01:36 brouette kernel: FS: 7f1767d15a40() GS:8801bfc2() knlGS: May 17 20:01:36 brouette kernel: CS: 0010 DS: ES: CR0: 80050033 May 17 20:01:36 brouette kernel: CR2: c9001530 CR3: 00019d752000 CR4: 07e0 May 17 20:01:36 brouette kernel: Stack: May 17 20:01:36 brouette kernel: a036be6f 8801ac585ba8 a0368f25 8801ac585c08 May 17 20:01:36 brouette kernel: a03691c6 010077359400 a0443ff0 1de8d000 May 17 20:01:36 brouette kernel: 8800813e65a0 8801b5aed700 880165e83740 May 17 20:01:36 brouette kernel: Call Trace: May 17 20:01:36 brouette kernel: [] ? nouveau_barobj_wr32+0xf/0x20 [nouveau] May 17 20:01:36 brouette kernel: [] _nouveau_gpuobj_wr32+0x25/0x30 [nouveau] May 17 20:01:36 brouette kernel: [] nouveau_gpuobj_create_+0x1c6/0x2c0 [nouveau] May 17 20:01:36 brouette kernel: [] nouveau_engctx_create_+0x24f/0x2a0 [nouveau] May 17 20:01:36 brouette kernel: [] nv50_graph_context_ctor+0x3c/0x80 [nouveau] May 17 20:01:36 brouette kernel: [] nouveau_object_ctor+0x2d/0xc0 [nouveau] May 17 20:01:36 brouette kernel: [] nouveau_object_new+0xeb/0x200 [nouveau] May 17 20:01:36 brouette kernel: [] nouveau_abi16_ioctl_grobj_alloc+0x6b/0xe0 [nouveau] May 17 20:01:36 brouette kernel: [] drm_ioctl+0x4c2/0x5f0 [drm] May 17 20:01:36 brouette kernel: [] ? do_mmap_pgoff+0x2c2/0x380 May 17 20:01:36 brouette kernel: [] nouveau_drm_ioctl+0x9/0x10 [nouveau] May 17 20:01:36 brouette kernel: [] do_vfs_ioctl+0x2e0/0x4c0 May 17 20:01:36 brouette kernel: [] ? __fget+0x69/0xb0 May 17 20:01:36 brouette kernel: [] SyS_ioctl+0x81/0xa0 May 17 20:01:36 brouette kernel: [] system_call_fastpath+0x16/0x1b May 17 20:01:36 brouette kernel: Code: 81 fe 00 00 01 00 76 0b 0f b7 d6 89 f8 ef c3 0f 1f 40 00 55 48 c7 c6 e1 9e 58 81 48 89 d7 48 89 e5 e8 1d fe ff ff 5d c3 0f 1f 00 <89> 3e c3 0f 1f 44 00 00 48 81 ff ff ff 03 00 77 37 48 81 ff 00 May 17 20:01:36 brouette kernel: RIP [] iowrite32+0x38/0x40 May 17 20:01:36 brouette kernel: RSP May 17 20:01:36 brouette kernel: CR2: c9001530 May 17 20:01:36 brouette kernel: ---[ end trace e4c3bdfb0b08f505 ]--- Thanks in advance for any help. Best Damien Wyart On Fri, May 16, 2014 at 10:05 AM, Damien Wyart wrote: > Hi, > > I am running the latest kernel from Linus. Once yesterday and once > today, I got a freeze of my machine. The first time, I could reboot > with sysrq, but not the second one (completely unresponsive). The
BUG when trying to use deadline iosched in 3.16-rc1
Hi, While testing 3.16-rc1, I got this error: Jun 21 11:19:03 brouette kernel: kernel tried to execute NX-protected page - exploit attempt? (uid: 0) Jun 21 11:19:03 brouette kernel: BUG: unable to handle kernel paging request at 8171a1f8 Jun 21 11:19:03 brouette kernel: IP: [] elv_register+0x0/0x197 Jun 21 11:19:03 brouette kernel: PGD 163d067 PUD 163e063 PMD 1b887f063 PTE 8171a163 Jun 21 11:19:03 brouette kernel: Oops: 0011 [#1] PREEMPT SMP Jun 21 11:19:03 brouette kernel: Modules linked in: deadline_iosched(+) binfmt_misc hid_roccat_konepure hid_roccat hid_roccat_common hid_generic snd_usb_audio snd_usbmidi_lib usbhid snd_hwdep snd_hda_codec_realtek snd_hda_codec_generic nouveau wmi snd_ca0106 video snd_ac97_codec i2c_algo_bit ttm snd_seq_dummy ac97_bus snd_seq_midi drm_kms_helper snd_seq_oss drm snd_seq_midi_event i2c_core snd_seq pcspkr sr_mod backlight snd_hda_intel snd_rawmidi snd_hda_controller cdrom snd_hda_codec snd_seq_device snd_pcm_oss snd_mixer_oss uhci_hcd ehci_pci snd_pcm ehci_hcd nvidiafb snd_timer usbcore vgastate usb_common evdev acpi_cpufreq loop fuse autofs4 Jun 21 11:19:03 brouette kernel: CPU: 1 PID: 2410 Comm: modprobe Tainted: P O 3.16.0-rc1 #1 Jun 21 11:19:03 brouette kernel: Hardware name: System manufacturer System Product Name/P6T SE, BIOS 080803/08/2010 Jun 21 11:19:03 brouette kernel: task: 8801b7c25b00 ti: 8801b4224000 task.ti: 8801b4224000 Jun 21 11:19:03 brouette kernel: RIP: 0010:[] [] elv_register+0x0/0x197 Jun 21 11:19:03 brouette kernel: RSP: 0018:8801b4227d60 EFLAGS: 00010246 Jun 21 11:19:03 brouette kernel: RAX: 8801b55a2101 RBX: 81641040 RCX: 03be0001 Jun 21 11:19:03 brouette kernel: RDX: 03bde001 RSI: 815a9f0d RDI: a103b880 Jun 21 11:19:03 brouette kernel: RBP: 8801b4227d68 R08: 000148e0 R09: Jun 21 11:19:03 brouette kernel: R10: 0012 R11: 00011c00 R12: 8801b55a2980 Jun 21 11:19:03 brouette kernel: R13: R14: a103d000 R15: a103ba40 Jun 21 11:19:03 brouette kernel: FS: 7f50c9669700() GS:8801bfc2() knlGS: Jun 21 11:19:03 brouette kernel: CS: 0010 DS: ES: CR0: 8005003b Jun 21 11:19:03 brouette kernel: CR2: 8171a1f8 CR3: 0001b7b1c000 CR4: 07e0 Jun 21 11:19:03 brouette kernel: Stack: Jun 21 11:19:03 brouette kernel: a103d010 8801b4227dd8 810002c4 0001 Jun 21 11:19:03 brouette kernel: 0001 a103ba40 8801b4227db8 810ed74a Jun 21 11:19:03 brouette kernel: 8801b4227ef8 a103ba58 a103ba90 8801b4227ef8 Jun 21 11:19:03 brouette kernel: Call Trace: Jun 21 11:19:03 brouette kernel: [] ? deadline_init+0x10/0x12 [deadline_iosched] Jun 21 11:19:03 brouette kernel: [] do_one_initcall+0x84/0x1c0 Jun 21 11:19:03 brouette kernel: [] ? __vunmap+0x9a/0x100 Jun 21 11:19:03 brouette kernel: [] load_module+0x19bc/0x2160 Jun 21 11:19:03 brouette kernel: [] ? symbol_put_addr+0x40/0x40 Jun 21 11:19:03 brouette kernel: [] SyS_finit_module+0x76/0x80 Jun 21 11:19:03 brouette kernel: [] system_call_fastpath+0x16/0x1b Jun 21 11:19:03 brouette kernel: Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jun 21 11:19:03 brouette kernel: RIP [] elv_register+0x0/0x197 Jun 21 11:19:03 brouette kernel: RSP Jun 21 11:19:03 brouette kernel: CR2: 8171a1f8 Jun 21 11:19:03 brouette kernel: ---[ end trace 5bbf40f5ac5f66e3 ]--- Jun 21 11:19:03 brouette kernel: elevator: type deadline not found Jun 21 11:19:03 brouette kernel: elevator: switch to deadline My startup scripts do this: echo "noop" > /sys/block/sda/queue/scheduler echo "deadline" > /sys/block/sdb/queue/scheduler echo "noop" > /sys/block/sdc/queue/scheduler echo "deadline" > /sys/block/sdd/queue/scheduler And the relevant part of my .config: CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_DEFAULT_IOSCHED="cfq" Maybe related to b5097e956a ? No problem with 3.15. Thanks, -- Damien Wyart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG when trying to use deadline iosched in 3.16-rc1
Hi, While testing 3.16-rc1, I got this error: Jun 21 11:19:03 brouette kernel: kernel tried to execute NX-protected page - exploit attempt? (uid: 0) Jun 21 11:19:03 brouette kernel: BUG: unable to handle kernel paging request at 8171a1f8 Jun 21 11:19:03 brouette kernel: IP: [] elv_register+0x0/0x197 Jun 21 11:19:03 brouette kernel: PGD 163d067 PUD 163e063 PMD 1b887f063 PTE 8171a163 Jun 21 11:19:03 brouette kernel: Oops: 0011 [#1] PREEMPT SMP Jun 21 11:19:03 brouette kernel: Modules linked in: deadline_iosched(+) binfmt_misc hid_roccat_konepure hid_roccat hid_roccat_common hid_generic snd_usb_audio snd_usbmidi_lib usbhid snd_hwdep snd_hda_codec_realtek snd_hda_codec_generic nouveau wmi snd_ca0106 video snd_ac97_codec i2c_algo_bit ttm snd_seq_dummy ac97_bus snd_seq_midi drm_kms_helper snd_seq_oss drm snd_seq_midi_event i2c_core snd_seq pcspkr sr_mod backlight snd_hda_intel snd_rawmidi snd_hda_controller cdrom snd_hda_codec snd_seq_device snd_pcm_oss snd_mixer_oss uhci_hcd ehci_pci snd_pcm ehci_hcd nvidiafb snd_timer usbcore vgastate usb_common evdev acpi_cpufreq loop fuse autofs4 Jun 21 11:19:03 brouette kernel: CPU: 1 PID: 2410 Comm: modprobe Tainted: P O 3.16.0-rc1 #1 Jun 21 11:19:03 brouette kernel: Hardware name: System manufacturer System Product Name/P6T SE, BIOS 080803/08/2010 Jun 21 11:19:03 brouette kernel: task: 8801b7c25b00 ti: 8801b4224000 task.ti: 8801b4224000 Jun 21 11:19:03 brouette kernel: RIP: 0010:[] [] elv_register+0x0/0x197 Jun 21 11:19:03 brouette kernel: RSP: 0018:8801b4227d60 EFLAGS: 00010246 Jun 21 11:19:03 brouette kernel: RAX: 8801b55a2101 RBX: 81641040 RCX: 03be0001 Jun 21 11:19:03 brouette kernel: RDX: 03bde001 RSI: 815a9f0d RDI: a103b880 Jun 21 11:19:03 brouette kernel: RBP: 8801b4227d68 R08: 000148e0 R09: Jun 21 11:19:03 brouette kernel: R10: 0012 R11: 00011c00 R12: 8801b55a2980 Jun 21 11:19:03 brouette kernel: R13: R14: a103d000 R15: a103ba40 Jun 21 11:19:03 brouette kernel: FS: 7f50c9669700() GS:8801bfc2() knlGS: Jun 21 11:19:03 brouette kernel: CS: 0010 DS: ES: CR0: 8005003b Jun 21 11:19:03 brouette kernel: CR2: 8171a1f8 CR3: 0001b7b1c000 CR4: 07e0 Jun 21 11:19:03 brouette kernel: Stack: Jun 21 11:19:03 brouette kernel: a103d010 8801b4227dd8 810002c4 0001 Jun 21 11:19:03 brouette kernel: 0001 a103ba40 8801b4227db8 810ed74a Jun 21 11:19:03 brouette kernel: 8801b4227ef8 a103ba58 a103ba90 8801b4227ef8 Jun 21 11:19:03 brouette kernel: Call Trace: Jun 21 11:19:03 brouette kernel: [] ? deadline_init+0x10/0x12 [deadline_iosched] Jun 21 11:19:03 brouette kernel: [] do_one_initcall+0x84/0x1c0 Jun 21 11:19:03 brouette kernel: [] ? __vunmap+0x9a/0x100 Jun 21 11:19:03 brouette kernel: [] load_module+0x19bc/0x2160 Jun 21 11:19:03 brouette kernel: [] ? symbol_put_addr+0x40/0x40 Jun 21 11:19:03 brouette kernel: [] SyS_finit_module+0x76/0x80 Jun 21 11:19:03 brouette kernel: [] system_call_fastpath+0x16/0x1b Jun 21 11:19:03 brouette kernel: Code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Jun 21 11:19:03 brouette kernel: RIP [] elv_register+0x0/0x197 Jun 21 11:19:03 brouette kernel: RSP Jun 21 11:19:03 brouette kernel: CR2: 8171a1f8 Jun 21 11:19:03 brouette kernel: ---[ end trace 5bbf40f5ac5f66e3 ]--- Jun 21 11:19:03 brouette kernel: elevator: type deadline not found Jun 21 11:19:03 brouette kernel: elevator: switch to deadline My startup scripts do this: echo "noop" > /sys/block/sda/queue/scheduler echo "deadline" > /sys/block/sdb/queue/scheduler echo "noop" > /sys/block/sdc/queue/scheduler echo "deadline" > /sys/block/sdd/queue/scheduler And the relevant part of my .config: CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_DEADLINE=m CONFIG_IOSCHED_CFQ=y CONFIG_CFQ_GROUP_IOSCHED=y CONFIG_DEFAULT_IOSCHED="cfq" Maybe related to b5097e956a ? No problem with 3.15. Thanks, -- Damien Wyart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG when trying to use deadline iosched in 3.16-rc1
> It seems you're right. I didn't know that parameter could be updated > dynamically. > In that case, adding __init to elv_register was a bad idea because it's no > more > reliable. Could you revert that patch Jens ? I confirm that reverting locally makes the problem go away. Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Nouveau] Machine freeze on latest Linus kernel, seems related to nouveau
Hi, On Sat, May 17, 2014 at 8:33 PM, Ilia Mirkin wrote: > Amazing. I get the same thing in chrome on my setup (G96). [...] > This is on top of a 3.15-rc5+ kernel. > Normally these things are very hard to debug because they're > ~impossible to reproduce. However this website seems to do the trick > (I'm guessing with the help of the youtube embeds). > Ben, any advice on debugging? (Or even better, an idea as to what's > wrong... I seem to recall this happening a lot a while back and then > it magically fixed itself for a while...) Any news on this topic? I did not see a followup to the initial thread... Thanks, Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes
> > I had an unstable system when running latest Linus tree with Tejun's > > patch applied on top. Nothing fishy in the logs after rebooting without > > the patch, but remote access with ssh when patch applied did not work > > (as if /home partition could not be read). This system has / as ext4 and > > other partitions (including /home) as XFS. Trying to login on tty > > instead of X resulted in hang of X. I could reboot with sysrq, but can't > > do further tests at the moment. > > Back to same tree without the patch resulted in normal system. > > So just a heads up the patch doesn't seem OK in its current state. Hi Tejun, > Have you been able to reproduce the failure? That sounds like an > unlikely failure mode for the patch. Unfortunately (as it would be nice to understand what happened), no. I reapplied the patch on top of rc7 and could not reproduce the unstability after several reboots. I will continue running with the patch and report if anything strange appears again... -- Damien -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH block/for-linus] writeback: fix syncing of I_DIRTY_TIME inodes
> On Thu 13-08-15 18:44:15, Tejun Heo wrote:
> > e79729123f63 ("writeback: don't issue wb_writeback_work if clean")
> > updated writeback path to avoid kicking writeback work items if there
> > are no inodes to be written out; unfortunately, the avoidance logic
> > was too aggressive and made sync_inodes_sb() skip I_DIRTY_TIME inodes.
> > This patch fixes the breakage by
> > * Removing bdi_has_dirty_io() shortcut from bdi_split_work_to_wbs().
> > The callers are already testing the condition.
> > * Removing bdi_has_dirty_io() shortcut from sync_inodes_sb() so that
> > it always calls into bdi_split_work_to_wbs().
> > * Making bdi_split_work_to_wbs() consider the b_dirty_time list for
> > WB_SYNC_ALL writebacks.
> > Signed-off-by: Tejun Heo
> > Fixes: e79729123f63 ("writeback: don't issue wb_writeback_work if clean")
> > Cc: Ted Ts'o
> > Cc: Jan Kara
* Jan Kara [2015-08-14 13:14]:
> So the patch looks good to me. But the fact that is fixes Eryu's problem
> means there is something fishy going on. Either inodes get wrongly attached
> to b_dirty_time list or bdi_has_dirty_io() somehow misbehaves only
> temporarily and we don't catch it with the debug patch.
> Can we add a test to wb_has_dirty_io() to also check whether it matches
> bdi_has_dirty_io()? Since Eryu doesn't use lazytime (I assume, Eryu, please
> speak up if you do), we could also warn if b_dirty_time lists get
> non-empty. Hmm?
Hi,
I had an unstable system when running latest Linus tree with Tejun's
patch applied on top. Nothing fishy in the logs after rebooting without
the patch, but remote access with ssh when patch applied did not work
(as if /home partition could not be read). This system has / as ext4 and
other partitions (including /home) as XFS. Trying to login on tty
instead of X resulted in hang of X. I could reboot with sysrq, but can't
do further tests at the moment.
Back to same tree without the patch resulted in normal system.
So just a heads up the patch doesn't seem OK in its current state.
Cheers
Damien
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Current git has USB keyboard and mouse unusable
Hi, Having compiled a kernel today (bfc1168de949c in Linus' tree), I noticed keyboard and mouse were not working at all (stuck at X DM level). After digging a bit, I realized only one change in the recent input commits was quite general, and bingo, reverting "allow matching device IDs on property bits" (8724ecb072293f109) made input work again. I did not find anything special in the logs for the bad kernel... Should that commit be reverted for now? Maybe other people will be able to reproduce it? Thanks Damien
Re: Current git has USB keyboard and mouse unusable
>> Should that commit be reverted for now? Maybe other people will be >> able to reproduce it? On Sun, Oct 22, 2017 at 6:37 PM, Dmitry Torokhov wrote: > Hm, that is not good. A few question before we decide to revert: > - do your devices work on text console? Yes, they do. > - can you post /proc/bus/input/devices to see if event handlers bind > to the device? Attaching the "good" and "bad" versions ; some handlers look empty in the bad version. > - is evdev driver in your kernel compiled as a module? Yes, it is. Damien I: Bus=0019 Vendor= Product=0001 Version= N: Name="Power Button" P: Phys=PNP0C0C/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 U: Uniq= H: Handlers=kbd B: PROP=0 B: EV=3 B: KEY=10 0 I: Bus=0019 Vendor= Product=0001 Version= N: Name="Power Button" P: Phys=LNXPWRBN/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 U: Uniq= H: Handlers=kbd B: PROP=0 B: EV=3 B: KEY=10 0 I: Bus=0010 Vendor=001f Product=0001 Version=0100 N: Name="PC Speaker" P: Phys=isa0061/input0 S: Sysfs=/devices/platform/pcspkr/input/input5 U: Uniq= H: Handlers=kbd B: PROP=0 B: EV=40001 B: SND=6 I: Bus= Vendor= Product= Version= N: Name="HDA Intel Front Mic" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1b.0/sound/card0/input6 U: Uniq= H: Handlers= B: PROP=0 B: EV=21 B: SW=10 I: Bus= Vendor= Product= Version= N: Name="HDA Intel Rear Mic" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1b.0/sound/card0/input7 U: Uniq= H: Handlers= B: PROP=0 B: EV=21 B: SW=10 I: Bus= Vendor= Product= Version= N: Name="HDA Intel Line" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1b.0/sound/card0/input8 U: Uniq= H: Handlers= B: PROP=0 B: EV=21 B: SW=2000 I: Bus= Vendor= Product= Version= N: Name="HDA Intel Line Out Front" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1b.0/sound/card0/input9 U: Uniq= H: Handlers= B: PROP=0 B: EV=21 B: SW=40 I: Bus= Vendor= Product= Version= N: Name="HDA Intel Line Out Surround" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1b.0/sound/card0/input10 U: Uniq= H: Handlers= B: PROP=0 B: EV=21 B: SW=40 I: Bus= Vendor= Product= Version= N: Name="HDA Intel Line Out CLFE" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1b.0/sound/card0/input11 U: Uniq= H: Handlers= B: PROP=0 B: EV=21 B: SW=40 I: Bus= Vendor= Product= Version= N: Name="HDA Intel Line Out Side" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1b.0/sound/card0/input12 U: Uniq= H: Handlers= B: PROP=0 B: EV=21 B: SW=40 I: Bus= Vendor= Product= Version= N: Name="HDA Intel Front Headphone" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1b.0/sound/card0/input13 U: Uniq= H: Handlers= B: PROP=0 B: EV=21 B: SW=4 I: Bus=0003 Vendor=1e7d Product=2dbe Version=0100 N: Name="ROCCAT ROCCAT Kone Pure" P: Phys=usb-:00:1d.2-1/input0 S: Sysfs=/devices/pci:00/:00:1d.2/usb8/8-1/8-1:1.0/0003:1E7D:2DBE.0002/input/input14 U: Uniq= H: Handlers=kbd mouse0 B: PROP=0 B: EV=1f B: KEY=3007f 0 0 48317aff32d bf56 1f0001 130c130b17c000 267bfad9415fed 9e16804400 1002 B: REL=1c3 B: ABS=f01 B: MSC=10 I: Bus=0003 Vendor=1e7d Product=2dbe Version=0111 N: Name="ROCCAT ROCCAT Kone Pure" P: Phys=usb-:00:1d.2-1/input1 S: Sysfs=/devices/pci:00/:00:1d.2/usb8/8-1/8-1:1.1/0003:1E7D:2DBE.0003/input/input15 U: Uniq= H: Handlers=sysrq kbd B: PROP=0 B: EV=120013 B: KEY=e080ffdf01cf fffe B: MSC=10 B: LED=1f I: Bus=0003 Vendor=0853 Product=0119 Version=0111 N: Name="Topre Corporation Realforce 105U" P: Phys=usb-:00:1d.2-2/input0 S: Sysfs=/devices/pci:00/:00:1d.2/usb8/8-2/8-2:1.0/0003:0853:0119.0004/input/input16 U: Uniq= H: Handlers=sysrq kbd B: PROP=0 B: EV=120013 B: KEY=10007 ff9f207ac14057ff febeffdfffef fffe B: MSC=10 B: LED=1f I: Bus=0019 Vendor= Product=0001 Version= N: Name="Power Button" P: Phys=PNP0C0C/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 U: Uniq= H: Handlers=kbd event0 B: PROP=0 B: EV=3 B: KEY=10 0 I: Bus=0019 Vendor= Product=0001 Version= N: Name="Power Button" P: Phys=LNXPWRBN/button/input0 S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 U: Uniq= H: Handlers=kbd event1 B: PROP=0 B: EV=3 B: KEY=10 0 I: Bus=0010 Vendor=001f Product=0001 Version=0100 N: Name="PC Speaker" P: Phys=isa0061/input0 S: Sysfs=/devices/platform/pcspkr/input/input5 U: Uniq= H: Handlers=kbd event2 B: PROP=0 B: EV=40001 B: SND=6 I: Bus= Vendor= Product= Version= N: Name="HDA Intel Front Mic" P: Phys=ALSA S: Sysfs=/devices/pci:00/:00:1b.0/sound/card0/input6 U: Uniq= H: Handlers=event3 B: PROP=0 B: EV=21 B: SW=10 I: Bus= Vendor= Product= Version= N: Name="HDA Intel Rear Mic" P: Phys=ALSA S: Sysfs=/devices/pci:00/
Re: Current git has USB keyboard and mouse unusable
>>> - is evdev driver in your kernel compiled as a module? >> Yes, it is. > OK, so this must be module loading issue that I missed. Just to > confirm, if you "modprobe evdev" it all starts to work? Yes, I confirm loading the module by hand makes everything work ok. Thanks for your replies! Damien
