Re: kdump regression compared to v2.6.35

2010-08-29 Thread caiqian
Further bisect indicated this bad commit from the merge. Given kdump kernel was running with maxcpus=1, I guess this work caused fs/bio.c hung in the workqueue on UP. Reverted the whole merge let kdump work again. commit e22bee782b3b00bd4534ae9b1c5fb2e8e6573c5c Author: Tejun Heo Date: Tue Jun

Re: kdump regression compared to v2.6.35

2010-08-29 Thread Tejun Heo
On 08/29/2010 09:01 AM, caiq...@redhat.com wrote: > Further bisect indicated this bad commit from the merge. Given kdump > kernel was running with maxcpus=1, I guess this work caused fs/bio.c > hung in the workqueue on UP. Reverted the whole merge let kdump work > again. Can you please pull from t

Re: kdump regression compared to v2.6.35

2010-08-29 Thread CAI Qian
- "Tejun Heo" wrote: > On 08/29/2010 09:01 AM, caiq...@redhat.com wrote: > > Further bisect indicated this bad commit from the merge. Given kdump > > kernel was running with maxcpus=1, I guess this work caused fs/bio.c > > hung in the workqueue on UP. Reverted the whole merge let kdump work

Re: kdump regression compared to v2.6.35

2010-08-29 Thread Tejun Heo
Hello, On 08/29/2010 01:24 PM, CAI Qian wrote: >> On 08/29/2010 09:01 AM, caiq...@redhat.com wrote: >>> Further bisect indicated this bad commit from the merge. Given kdump >>> kernel was running with maxcpus=1, I guess this work caused fs/bio.c >>> hung in the workqueue on UP. Reverted the whole

Re: kdump regression compared to v2.6.35

2010-08-29 Thread caiqian
- "Tejun Heo" wrote: > Hello, > > On 08/29/2010 01:24 PM, CAI Qian wrote: > >> On 08/29/2010 09:01 AM, caiq...@redhat.com wrote: > >>> Further bisect indicated this bad commit from the merge. Given kdump > >>> kernel was running with maxcpus=1, I guess this work caused > fs/bio.c > >>> hung

Re: kdump regression compared to v2.6.35

2010-08-29 Thread CAI Qian
- caiq...@redhat.com wrote: > - "Tejun Heo" wrote: > > > Hello, > > > > On 08/29/2010 01:24 PM, CAI Qian wrote: > > >> On 08/29/2010 09:01 AM, caiq...@redhat.com wrote: > > >>> Further bisect indicated this bad commit from the merge. Given > kdump > > >>> kernel was running with maxcpus

Re: kdump regression compared to v2.6.35

2010-08-29 Thread Tejun Heo
On 08/29/2010 01:56 PM, CAI Qian wrote: > It is easy to reproduce by passing maxcpus=1 to the first kernel. Do you mean booting w/ maxcpus=1 hangs the first kernel even w/o kdump? Thanks. -- tejun ___ kexec mailing list kexec@lists.infradead.org http

Re: kdump regression compared to v2.6.35

2010-08-29 Thread CAI Qian
- "Tejun Heo" wrote: > On 08/29/2010 01:56 PM, CAI Qian wrote: > > It is easy to reproduce by passing maxcpus=1 to the first kernel. > > Do you mean booting w/ maxcpus=1 hangs the first kernel even w/o > kdump? Yes, here was the log, Linux version 2.6.36-rc2-mm1-orig+ (r...@intel-s3e36-01.

Re: kdump regression compared to v2.6.35

2010-08-29 Thread Tejun Heo
Hello, On 08/29/2010 02:03 PM, CAI Qian wrote: > > - "Tejun Heo" wrote: > >> On 08/29/2010 01:56 PM, CAI Qian wrote: >>> It is easy to reproduce by passing maxcpus=1 to the first kernel. >> >> Do you mean booting w/ maxcpus=1 hangs the first kernel even w/o >> kdump? > Yes, here was the log

Re: kdump regression compared to v2.6.35

2010-08-29 Thread CAI Qian
- "Tejun Heo" wrote: > Hello, > > On 08/29/2010 02:03 PM, CAI Qian wrote: > > > > - "Tejun Heo" wrote: > > > >> On 08/29/2010 01:56 PM, CAI Qian wrote: > >>> It is easy to reproduce by passing maxcpus=1 to the first kernel. > >> > >> Do you mean booting w/ maxcpus=1 hangs the first k