(2013/03/05 7:00), Don Dutile wrote:
On 03/03/2013 07:56 PM, Takao Indoh wrote:
(2013/01/23 9:47), Thomas Renninger wrote:
On Monday, January 21, 2013 10:11:04 AM Takao Indoh wrote:
(2013/01/08 4:09), Thomas Renninger wrote:
...
I tried the provided patches first on 2.6.32, then I verfied wi
On 03/03/2013 07:56 PM, Takao Indoh wrote:
(2013/01/23 9:47), Thomas Renninger wrote:
On Monday, January 21, 2013 10:11:04 AM Takao Indoh wrote:
(2013/01/08 4:09), Thomas Renninger wrote:
...
I tried the provided patches first on 2.6.32, then I verfied with 3.8-rc2
and in both cases the disk
(2013/01/23 9:47), Thomas Renninger wrote:
> On Monday, January 21, 2013 10:11:04 AM Takao Indoh wrote:
>> (2013/01/08 4:09), Thomas Renninger wrote:
> ...
>>> I tried the provided patches first on 2.6.32, then I verfied with 3.8-rc2
>>> and in both cases the disk is not detected anymore in
>>> res
(2013/01/29 10:14), Thomas Renninger wrote:
> On Thursday, January 24, 2013 09:23:14 AM Takao Indoh wrote:
>> (2013/01/23 9:47), Thomas Renninger wrote:
>>> On Monday, January 21, 2013 10:11:04 AM Takao Indoh wrote:
(2013/01/08 4:09), Thomas Renninger wrote:
>>> ...
>>>
> I tried the provi
On Thursday, January 24, 2013 09:23:14 AM Takao Indoh wrote:
> (2013/01/23 9:47), Thomas Renninger wrote:
> > On Monday, January 21, 2013 10:11:04 AM Takao Indoh wrote:
> >> (2013/01/08 4:09), Thomas Renninger wrote:
> > ...
> >
> >>> I tried the provided patches first on 2.6.32, then I verfied wi
(2013/01/23 9:47), Thomas Renninger wrote:
On Monday, January 21, 2013 10:11:04 AM Takao Indoh wrote:
(2013/01/08 4:09), Thomas Renninger wrote:
...
I tried the provided patches first on 2.6.32, then I verfied with 3.8-rc2
and in both cases the disk is not detected anymore in
reset_devices (ke
On Monday, January 21, 2013 10:11:04 AM Takao Indoh wrote:
> (2013/01/08 4:09), Thomas Renninger wrote:
...
> > I tried the provided patches first on 2.6.32, then I verfied with 3.8-rc2
> > and in both cases the disk is not detected anymore in
> > reset_devices (kexec'ed/kdump) case (but things wor
(2013/01/08 4:09), Thomas Renninger wrote:
On Friday, December 21, 2012 08:19:05 AM Yinghai Lu wrote:
On Fri, Nov 30, 2012 at 7:49 AM, MUNEDA Takahiro
wrote:
On Tue, 27 Nov 2012 09:42:20 +0900 (JST),
Takao Indoh wrote:
These patches reset PCIe devices at boot time to address DMA problem on
Hi Thomas,
(2013/01/09 11:32), Thomas Renninger wrote:
On Tuesday, January 08, 2013 09:27:55 AM Yinghai Lu wrote:
On Tue, Jan 8, 2013 at 8:50 AM, Thomas Renninger wrote:
megaraid_sas
can you check if your initrd for kdump kernel has that driver and
module that it depends on like
scsi sas tr
On Tuesday, January 08, 2013 09:27:55 AM Yinghai Lu wrote:
> On Tue, Jan 8, 2013 at 8:50 AM, Thomas Renninger wrote:
> > megaraid_sas
>
> can you check if your initrd for kdump kernel has that driver and
> module that it depends on like
> scsi sas transport etc ?
Removing the 5 patches and the d
On Tue, Jan 8, 2013 at 8:50 AM, Thomas Renninger wrote:
> megaraid_sas
can you check if your initrd for kdump kernel has that driver and
module that it depends on like
scsi sas transport etc ?
Thanks
Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Mon, Jan 7, 2013 at 4:42 PM, Thomas Renninger wrote:
> memmap=256M$3584M
may need to change to:
memmap=256M\$\$3584M
Thanks
Yinghai
--
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:/
On Monday, January 07, 2013 12:16:42 PM Yinghai Lu wrote:
> On Mon, Jan 7, 2013 at 11:09 AM, Thomas Renninger wrote:
> > e820: BIOS-provided physical RAM map:
> > BIOS-e820: [mem 0x0100-0x0009bfff] usable
> > BIOS-e820: [mem 0x0010-0xbd2e] usable
> > BIO
On Mon, Jan 7, 2013 at 11:09 AM, Thomas Renninger wrote:
> e820: BIOS-provided physical RAM map:
> BIOS-e820: [mem 0x0100-0x0009bfff] usable
> BIOS-e820: [mem 0x0010-0xbd2e] usable
> BIOS-e820: [mem 0xbd2f-0xbd31bfff] reserved
> BIOS-
On Fri, Nov 30, 2012 at 7:49 AM, MUNEDA Takahiro
wrote:
> On Tue, 27 Nov 2012 09:42:20 +0900 (JST),
> Takao Indoh wrote:
>
>> These patches reset PCIe devices at boot time to address DMA problem on
>> kdump with iommu. When "reset_devices" is specified, a hot reset is
>> triggered on each PCIe ro
Hi,
(2012/12/21 18:59), oliver yang wrote:
Hi Takao,
Because I want to config the kdump in our lab, I have some questions
about the backgroud of your patch.
1. Will you patch only work while IOMMU is enabled?
No. It always works when "reset_devices" is specified as boot parameter.
2. Lo
On Tue, 27 Nov 2012 09:42:20 +0900 (JST),
Takao Indoh wrote:
> These patches reset PCIe devices at boot time to address DMA problem on
> kdump with iommu. When "reset_devices" is specified, a hot reset is
> triggered on each PCIe root port and downstream port to reset its
> downstream endpoint.
>
These patches reset PCIe devices at boot time to address DMA problem on
kdump with iommu. When "reset_devices" is specified, a hot reset is
triggered on each PCIe root port and downstream port to reset its
downstream endpoint.
Background:
A kdump problem about DMA has been discussed for a long tim
18 matches
Mail list logo