Re: [PATCH] makedumpfile: shorten cyclic unnecessary-page scans

Hello Cliff, (2013/08/29 7:08), Cliff Wickman wrote: > From: Cliff Wickman > > > When the kernel free pages are not detectable with the 'buddy' method > we do a scan for free pages. > In cyclic mode that scan was performed over all of memory for each > cycle region. > > This patch records the pfn

Re: A few patches to consider

(2013/09/19 11:13), HATAYAMA Daisuke wrote: > (2013/09/18 12:00), Atsushi Kumagai wrote: >> (2013/08/30 10:33), HATAYAMA Daisuke wrote: >>> (2013/08/29 7:08), Cliff Wickman wrote: From: Cliff Wickman I am submitting 6 patches that I have found helpful in speeding the dump proce

Re: A few patches to consider

(2013/09/18 12:00), Atsushi Kumagai wrote: (2013/08/30 10:33), HATAYAMA Daisuke wrote: (2013/08/29 7:08), Cliff Wickman wrote: From: Cliff Wickman I am submitting 6 patches that I have found helpful in speeding the dump process or clarifying the progress report. They are not a series, and sho

Re: [PATCH 0/2] cache: fix cache logic not go into invalid state

Hello Kumagai-san, Could you review these patches? (2013/09/17 15:29), HATAYAMA Daisuke wrote: I faced failure of sadump phys_base calculation and found a bug in cache.c causes it. Due to the bug, cache_alloc() returns NULL forever throughout execution. The fix is the 2nd patch. During the inve

Re: [PATCH] intel-iommu: Quiesce devices before disabling IOMMU

On Tue, 2013-09-10 at 14:43 +0900, Takao Indoh wrote: > (2013/09/09 18:07), David Woodhouse wrote: > > If the driver is so broken that it cannot get the device working again > > after a fault, surely the driver needs to be fixed? > > Yes,this problem may be solved by fixing driver. Actually megara

Re: [PATCH 00/16] [RFC PATCH] Signed kexec support

Hello, as one of the developers of kexecboot, a kexec-based linux-as-bootloader, I'm following with interest this thread. FWIW since the beginning we are compiling kexec-tools statically against klibc for size constraints. We have 2.02 and 2.0.4 almost finished (some issue with purgatory in this

[PATCH v2] dump-dmesg: Understand >= v3.11-rc4 dmesg

Symbol name changed with the following commit: 62e32ac printk: rename struct log to struct printk_log Signed-off-by: Lubomir Rintel Cc: Louis Bouchard Cc: Masaki Tachibana Cc: Minoru Usui Cc: Daisuke Nishimura Cc: Atsushi Kumagai --- So, the change did make it into 3.11. Does this make sense

[RESEND PATCH] vmcore-dmesg: Understand >= v3.11-rc4 dmesg

Symbol name changed with the following commit: 62e32ac printk: rename struct log to struct printk_log Signed-off-by: Lubomir Rintel Cc: Simon Horman Cc: Vivek Goyal Cc: Joe Perches Signed-off-by: Lubomir Rintel --- I believe this can now be applied, as the change went into 3.11 kernel releas

Re: [BUG] [compressed kdump / SADUMP] makedumpfile header truncation error

- Original Message - > On 09/17/2013 09:23 PM, Dave Anderson wrote: > > > > > > - Original Message - > >> On 09/17/2013 03:33 PM, HATAYAMA Daisuke wrote: > >>> (2013/09/17 16:12), Jingbai Ma wrote: > On 09/17/2013 02:55 PM, HATAYAMA Daisuke wrote: > > int32_t, int64

Re: [BUG] [compressed kdump / SADUMP] makedumpfile header truncation error

On 09/17/2013 09:23 PM, Dave Anderson wrote: - Original Message - On 09/17/2013 03:33 PM, HATAYAMA Daisuke wrote: (2013/09/17 16:12), Jingbai Ma wrote: On 09/17/2013 02:55 PM, HATAYAMA Daisuke wrote: int32_t, int64_t, uint64_t, etc ... are parts of C99 standard: http://en.wikipedia.

Re: [PATCH v2] intel-iommu: Quiesce devices before disabling IOMMU

On 09/18/13 at 03:09pm, Takao Indoh wrote: > This patch quiesces devices before disabling IOMMU on boot to stop > ongoing DMA. In intel_iommu_init(), check context entries and if there > is entry whose present bit is set then reset corresponding device. > > When IOMMU is already enabled on boot, i