(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
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
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/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
(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
>>>
(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
(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
(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 provided patches first on
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
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 with
3.8-rc2
(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
(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
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
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 work fine
(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
(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
muneda.takah...@jp.fujitsu.com wrote:
On Tue, 27 Nov 2012 09:42:20 +0900 (JST),
Takao Indoh indou.ta...@jp.fujitsu.com wrote:
These patches
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
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
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 Tue, Jan 8, 2013 at 8:50 AM, Thomas Renninger tr...@suse.de 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
On Tuesday, January 08, 2013 09:27:55 AM Yinghai Lu wrote:
On Tue, Jan 8, 2013 at 8:50 AM, Thomas Renninger tr...@suse.de 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
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 tr...@suse.de wrote:
megaraid_sas
can you check if your initrd for kdump kernel has that driver and
module that it depends on
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
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
> >
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
>
On Mon, Jan 7, 2013 at 11:09 AM, Thomas Renninger tr...@suse.de wrote:
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0100-0x0009bfff] usable
BIOS-e820: [mem 0x0010-0xbd2e] usable
BIOS-e820: [mem 0xbd2f-0xbd31bfff]
On Monday, January 07, 2013 12:16:42 PM Yinghai Lu wrote:
On Mon, Jan 7, 2013 at 11:09 AM, Thomas Renninger tr...@suse.de wrote:
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x0100-0x0009bfff] usable
BIOS-e820: [mem 0x0010-0xbd2e] usable
On Mon, Jan 7, 2013 at 4:42 PM, Thomas Renninger tr...@suse.de 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
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
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.
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.
On Fri, Nov 30, 2012 at 7:49 AM, MUNEDA Takahiro
muneda.takah...@jp.fujitsu.com wrote:
On Tue, 27 Nov 2012 09:42:20 +0900 (JST),
Takao Indoh indou.ta...@jp.fujitsu.com wrote:
These patches reset PCIe devices at boot time to address DMA problem on
kdump with iommu. When reset_devices is
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.
On Tue, 27 Nov 2012 09:42:20 +0900 (JST),
Takao Indoh indou.ta...@jp.fujitsu.com 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
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
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
36 matches
Mail list logo