>> I think i can go to a date based black list, that removes the manual
>> step. System running firmware before certain date assumes we need
>> to do the work around. If firmware is newer than that date, we don't
>> use the workaround. Blacklist overrides and allows current behavior
>> for new firm
On Mon, Nov 18, 2013 at 5:32 PM, H. Peter Anvin wrote:
> On 11/15/2013 10:30 AM, Vivek Goyal wrote:
>>
>> And IOMMU support is very flaky with kdump. And IOMMU's can be turned
>> off at command line. And that would force one to remove crahkernel_low=0.
>> So change of one command line option force
On 11/15/2013 10:30 AM, Vivek Goyal wrote:
>
> And IOMMU support is very flaky with kdump. And IOMMU's can be turned
> off at command line. And that would force one to remove crahkernel_low=0.
> So change of one command line option forces change of another. It is
> complicated.
>
> Also there are
On Mon, Nov 18, 2013 at 11:34:04AM -0800, Yinghai Lu wrote:
> On Mon, Nov 18, 2013 at 7:32 AM, Vivek Goyal wrote:
> >> You may need bunch of PCIe cards installed.
> >>
> >> The system with 6TiB + 16 PCIe cards, second kernel OOM.
> >> The system with 4.5TiB + 16 PCIe cards, second kernel works wit
On Mon, Nov 18, 2013 at 7:32 AM, Vivek Goyal wrote:
>> You may need bunch of PCIe cards installed.
>>
>> The system with 6TiB + 16 PCIe cards, second kernel OOM.
>> The system with 4.5TiB + 16 PCIe cards, second kernel works with vmcore
>> dumped.
>
> What's the distro you are testing with? Do yo
On Mon, Nov 18, 2013 at 10:29:18AM -0800, H. Peter Anvin wrote:
> On 11/18/2013 07:22 AM, Vivek Goyal wrote:
> >
> > And if that's true, then reserving 72M extra due to crashkernel=X,high
> > should not be a big issue in KVM guests. It will still be an issue on
> > physical servers though.
> >
>
On 11/18/2013 07:22 AM, Vivek Goyal wrote:
>
> And if that's true, then reserving 72M extra due to crashkernel=X,high
> should not be a big issue in KVM guests. It will still be an issue on
> physical servers though.
>
Yes, but there it is a single instance and not a huge amount of RAM.
On Fri, Nov 15, 2013 at 12:13:08PM -0700, jerry.hoem...@hp.com wrote:
[..]
> > Is it possible to fix it the way hpa suggested?
>
> I think the changes to enable ,high is a step in the
> right direction. its an improvement But it is still green.
>
> We are having lots more problems w/ upst
On Fri, Nov 15, 2013 at 02:24:25PM -0800, Yinghai Lu wrote:
> On Fri, Nov 15, 2013 at 10:03 AM, Vivek Goyal wrote:
> > On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
>
> >> I have one system with 6TiB memory, kdump does not work even
> >> crashkernel=512M in legacy mode. ( it only wo
On Fri, Nov 15, 2013 at 2:55 PM, wrote:
>> You may need bunch of PCIe cards installed.
>>
>> The system with 6TiB + 16 PCIe cards, second kernel OOM.
>> The system with 4.5TiB + 16 PCIe cards, second kernel works with vmcore
>> dumped.
>
> Yinghai,
>
> Your original email said you were using "le
On Fri, Nov 15, 2013 at 02:24:25PM -0800, Yinghai Lu wrote:
> On Fri, Nov 15, 2013 at 10:03 AM, Vivek Goyal wrote:
> > On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
>
> >> I have one system with 6TiB memory, kdump does not work even
> >> crashkernel=512M in legacy mode. ( it only wo
On Fri, Nov 15, 2013 at 10:03 AM, Vivek Goyal wrote:
> On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
>> I have one system with 6TiB memory, kdump does not work even
>> crashkernel=512M in legacy mode. ( it only work on system with
>> 4.5TiB).
>
> Recently I tested one system with 6T
On 11/15/2013 10:46 AM, H. Peter Anvin wrote:
> On 11/15/2013 10:30 AM, Vivek Goyal wrote:
>>
>> I agree taking assistance of hypervisor should be useful.
>>
>> One reason we use kdump for VM too because it makes life simple. There
>> is no difference in how we configure, start and manage crash dum
On Fri, Nov 15, 2013 at 07:24:17AM +0100, Ingo Molnar wrote:
>
> * jerry.hoem...@hp.com wrote:
>
> > On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
> > > On Thu, Nov 14, 2013 at 8:04 PM, wrote:
> > > > Making this issue a quirk will be a lot more practical. Its a small,
> > >
On 11/15/2013 10:30 AM, Vivek Goyal wrote:
>
> I agree taking assistance of hypervisor should be useful.
>
> One reason we use kdump for VM too because it makes life simple. There
> is no difference in how we configure, start and manage crash dumps
> in baremetal or inside VM. And in practice hav
On Fri, Nov 15, 2013 at 09:40:49AM -0800, H. Peter Anvin wrote:
> On 11/15/2013 09:33 AM, Yinghai Lu wrote:
> >
> > If the system support intel IOMMU, we only need to that 72M for SWIOTLB
> > or AMD workaround.
> > If the user really care that for intel iommu enable system, they could use
> > "cra
On Thu, Nov 14, 2013 at 10:59:05PM -0800, H. Peter Anvin wrote:
> On 11/14/2013 10:55 PM, Yinghai Lu wrote:
> >
> > Why just asking distros to append ",high" in their installation
> > program for 64bit by default?
> >
> [...]
> >
> > What is hpa's suggestion?
> >
>
> Pretty much what you just
On Fri, Nov 15, 2013 at 09:33:41AM -0800, Yinghai Lu wrote:
[..]
> > I think crashkernel=X,high is not a good default choice for distros.
> > Reserving memory high reserves 72MB (or more) low memory for swiotlb. We
> > work hard to keep crashkernel memory amount low and currently reserve
> > 128M
On 11/15/2013 09:33 AM, Yinghai Lu wrote:
>
> If the system support intel IOMMU, we only need to that 72M for SWIOTLB
> or AMD workaround.
> If the user really care that for intel iommu enable system, they could use
> "crashkernel=0,low" to have that 72M back.
>
> and that 72M is under 4G instead
On Fri, Nov 15, 2013 at 6:07 AM, Vivek Goyal wrote:
> On Thu, Nov 14, 2013 at 10:59:05PM -0800, H. Peter Anvin wrote:
>> On 11/14/2013 10:55 PM, Yinghai Lu wrote:
>> >
>> > Why just asking distros to append ",high" in their installation
>> > program for 64bit by default?
>> >
>> [...]
>> >
>> > Wh
On Thu, Nov 14, 2013 at 10:59:05PM -0800, H. Peter Anvin wrote:
> On 11/14/2013 10:55 PM, Yinghai Lu wrote:
> >
> > Why just asking distros to append ",high" in their installation
> > program for 64bit by default?
> >
> [...]
> >
> > What is hpa's suggestion?
> >
>
> Pretty much what you just
On 11/15/13 2:50 AM, jerry.hoem...@hp.com wrote:
One already has to specify command line arguments to enable kdump.
Yes, so what?
The problem with your patch is that now to enable kdump, I have to know
that there's a second command line option and if my firmware is "broken"
or not. The form
On 11/14/2013 10:55 PM, Yinghai Lu wrote:
>
> Why just asking distros to append ",high" in their installation
> program for 64bit by default?
>
[...]
>
> What is hpa's suggestion?
>
Pretty much what you just said ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Thu, Nov 14, 2013 at 10:24 PM, Ingo Molnar wrote:
>
> * jerry.hoem...@hp.com wrote:
>
>> On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
>> > On Thu, Nov 14, 2013 at 8:04 PM, wrote:
>> > > Making this issue a quirk will be a lot more practical. Its a small,
>> > > focused
>>
* jerry.hoem...@hp.com wrote:
> On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
> > On Thu, Nov 14, 2013 at 8:04 PM, wrote:
> > > Making this issue a quirk will be a lot more practical. Its a small,
> > > focused
> > > change whose implications are limited and more easily under
On Thu, Nov 14, 2013 at 08:44:04PM +0200, Pekka Enberg wrote:
> On Thu, Nov 14, 2013 at 8:04 PM, wrote:
> > Making this issue a quirk will be a lot more practical. Its a small,
> > focused
> > change whose implications are limited and more easily understood.
>
> There's nothing practical with
On 11/14/2013 10:44 AM, Pekka Enberg wrote:
> On Thu, Nov 14, 2013 at 8:04 PM, wrote:
>> Making this issue a quirk will be a lot more practical. Its a small, focused
>> change whose implications are limited and more easily understood.
>
> There's nothing practical with requiring users to pass a
On Thu, Nov 14, 2013 at 8:04 PM, wrote:
> Making this issue a quirk will be a lot more practical. Its a small, focused
> change whose implications are limited and more easily understood.
There's nothing practical with requiring users to pass a kernel option
to make kdump work. It's a workaroun
On Thu, Nov 14, 2013 at 10:24:17AM +0200, Pekka Enberg wrote:
> Hi Jerry,
>
> On Thu, Nov 14, 2013 at 1:57 AM, wrote:
> > I will still point out that as currently used, efi_reserve_boot_services
> > is wrong. A work around for firmware bugs on one platform shouldn't be
> > breaking platforms th
On Wed, Nov 13, 2013 at 02:49:42PM -0800, H. Peter Anvin wrote:
[..]
> In other words, allocating the crashkernel high has ALL the advantages,
> plus a few more, and NONE of the disadvantages.
It allocates low memory for swiotlb. So that extra 72M allocation is the
disadvantage. With so many virt
Hi Jerry,
On Thu, Nov 14, 2013 at 1:57 AM, wrote:
> I will still point out that as currently used, efi_reserve_boot_services
> is wrong. A work around for firmware bugs on one platform shouldn't be
> breaking platforms that don't have that bug. Its just much less likely
> to cause problems wit
On Wed, Nov 13, 2013 at 04:05:50PM -0800, H. Peter Anvin wrote:
> On 11/13/2013 03:57 PM, jerry.hoem...@hp.com wrote:
> >
> > I think i can go to a date based black list, that removes the manual
> > step. System running firmware before certain date assumes we need
> > to do the work around. If f
On 11/13/2013 03:57 PM, jerry.hoem...@hp.com wrote:
>
> I think i can go to a date based black list, that removes the manual
> step. System running firmware before certain date assumes we need
> to do the work around. If firmware is newer than that date, we don't
> use the workaround. Blacklist
On Wed, Nov 13, 2013 at 02:49:42PM -0800, H. Peter Anvin wrote:
> On 11/13/2013 02:45 PM, jerry.hoem...@hp.com wrote:
> >
> > The changes in 3.9 to allow crash kernel to be allocated high helps.
> > But as you say, the default is still to allocate crash kernel low and
> > still susceptible to thi
On 11/13/2013 02:45 PM, jerry.hoem...@hp.com wrote:
>
> The changes in 3.9 to allow crash kernel to be allocated high helps.
> But as you say, the default is still to allocate crash kernel low and
> still susceptible to this problem. So, a kdump expert can work around it.
> But, not everyone is
On Tue, Nov 12, 2013 at 10:58:42AM -0800, H. Peter Anvin wrote:
> The problem with the crashkernel is that it by default has to sit very low in
> memory because the tools don't know if the crashkernel is me enough to sit
> anywhere. That is the real fix.
The changes in 3.9 to allow crash kerne
On Tue, Nov 12, 2013 at 08:48:51PM +0200, Pekka Enberg wrote:
> Hi Jerry,
>
> On Tue, Nov 12, 2013 at 7:55 PM, wrote:
> > My change does not address platforms that have misbehaving firmware.
> > It just allows platforms that don't have this issue to avoid issues
> > that the call to efi_reserve_
The problem with the crashkernel is that it by default has to sit very low in
memory because the tools don't know if the crashkernel is me enough to sit
anywhere. That is the real fix.
Jerry Hoemann wrote:
>Some platform have firmware that violates UEFI spec and access boot
>service
>code or d
Hi Jerry,
On Tue, Nov 12, 2013 at 7:55 PM, wrote:
> My change does not address platforms that have misbehaving firmware.
> It just allows platforms that don't have this issue to avoid issues
> that the call to efi_reserve_boot_services presents.
The problem I have with your patch is that it (1)
On Tue, Nov 12, 2013 at 12:37:29PM +0200, Pekka Enberg wrote:
> On Tue, Nov 12, 2013 at 4:15 AM, Jerry Hoemann wrote:
> > Some platform have firmware that violates UEFI spec and access boot service
> > code or data segments after the system has called Exit Boot Services.
> > The call to efi_reserv
On Tue, Nov 12, 2013 at 4:15 AM, Jerry Hoemann wrote:
> Some platform have firmware that violates UEFI spec and access boot service
> code or data segments after the system has called Exit Boot Services.
> The call to efi_reserve_boot_services in setup_arch is a work around to
> avoid using boot s
41 matches
Mail list logo
