On 01/31/2013 11:28 AM, Shuah Khan wrote:
> On Mon, Jan 28, 2013 at 8:44 PM, Yinghai Lu wrote:
>> On Mon, Jan 28, 2013 at 6:27 PM, Shuah Khan wrote:
>>> On Thu, Jan 24, 2013 at 2:50 PM, Yinghai Lu wrote:
>>>
>>> Your for-x86-boot git boots on AMD system I have. However, with
>>> memmap=4095$1M
On Mon, Jan 28, 2013 at 8:44 PM, Yinghai Lu wrote:
> On Mon, Jan 28, 2013 at 6:27 PM, Shuah Khan wrote:
>> On Thu, Jan 24, 2013 at 2:50 PM, Yinghai Lu wrote:
>>
>> Your for-x86-boot git boots on AMD system I have. However, with
>> memmap=4095$1M option, it panics very early in boot. I don't
On Mon, Jan 28, 2013 at 8:44 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Jan 28, 2013 at 6:27 PM, Shuah Khan shuahk...@gmail.com wrote:
On Thu, Jan 24, 2013 at 2:50 PM, Yinghai Lu ying...@kernel.org wrote:
Your for-x86-boot git boots on AMD system I have. However, with
memmap=4095$1M
On 01/31/2013 11:28 AM, Shuah Khan wrote:
On Mon, Jan 28, 2013 at 8:44 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Jan 28, 2013 at 6:27 PM, Shuah Khan shuahk...@gmail.com wrote:
On Thu, Jan 24, 2013 at 2:50 PM, Yinghai Lu ying...@kernel.org wrote:
Your for-x86-boot git boots on AMD
On Mon, Jan 28, 2013 at 6:27 PM, Shuah Khan wrote:
> On Thu, Jan 24, 2013 at 2:50 PM, Yinghai Lu wrote:
>
> Your for-x86-boot git boots on AMD system I have. However, with
> memmap=4095$1M option, it panics very early in boot. I don't have
> physical access to the console and I will try to get
On Thu, Jan 24, 2013 at 2:50 PM, Yinghai Lu wrote:
> On Thu, Jan 24, 2013 at 11:22 AM, Shuah Khan wrote:
>>>
>>> I still have the AMD system I tested earlier versions of this work. I
>>> started compiles with these patches on 3.7 and will let you know the
>>> status.
>>
>> Tested 3.8-rc4 with
On Thu, Jan 24, 2013 at 2:50 PM, Yinghai Lu ying...@kernel.org wrote:
On Thu, Jan 24, 2013 at 11:22 AM, Shuah Khan shuahk...@gmail.com wrote:
I still have the AMD system I tested earlier versions of this work. I
started compiles with these patches on 3.7 and will let you know the
status.
On Mon, Jan 28, 2013 at 6:27 PM, Shuah Khan shuahk...@gmail.com wrote:
On Thu, Jan 24, 2013 at 2:50 PM, Yinghai Lu ying...@kernel.org wrote:
Your for-x86-boot git boots on AMD system I have. However, with
memmap=4095$1M option, it panics very early in boot. I don't have
physical access to the
On Thu, Jan 24, 2013 at 11:22 AM, Shuah Khan wrote:
>>
>> I still have the AMD system I tested earlier versions of this work. I
>> started compiles with these patches on 3.7 and will let you know the
>> status.
>
> Tested 3.8-rc4 with the patches on AMD system with IOMMU on. Looks
> good. I can't
On Thu, Jan 24, 2013 at 9:51 AM, Shuah Khan wrote:
> On Thu, Jan 24, 2013 at 8:39 AM, Konrad Rzeszutek Wilk
> wrote:
>> On Fri, Jan 18, 2013 at 10:55:35AM -0500, Konrad Rzeszutek Wilk wrote:
>>> On Mon, Jan 14, 2013 at 10:19:22PM -0800, Yinghai Lu wrote:
>>> > On Fri, Jan 11, 2013 at 9:49 AM,
On Thu, Jan 24, 2013 at 8:39 AM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Jan 18, 2013 at 10:55:35AM -0500, Konrad Rzeszutek Wilk wrote:
>> On Mon, Jan 14, 2013 at 10:19:22PM -0800, Yinghai Lu wrote:
>> > On Fri, Jan 11, 2013 at 9:49 AM, Yinghai Lu wrote:
>> > > On Fri, Jan 11, 2013 at 8:52 AM,
On Fri, Jan 18, 2013 at 10:55:35AM -0500, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 14, 2013 at 10:19:22PM -0800, Yinghai Lu wrote:
> > On Fri, Jan 11, 2013 at 9:49 AM, Yinghai Lu wrote:
> > > On Fri, Jan 11, 2013 at 8:52 AM, Yinghai Lu wrote:
> > >>>
> > >>> I need to check this patch out and
On Fri, Jan 18, 2013 at 10:55:35AM -0500, Konrad Rzeszutek Wilk wrote:
On Mon, Jan 14, 2013 at 10:19:22PM -0800, Yinghai Lu wrote:
On Fri, Jan 11, 2013 at 9:49 AM, Yinghai Lu ying...@kernel.org wrote:
On Fri, Jan 11, 2013 at 8:52 AM, Yinghai Lu ying...@kernel.org wrote:
I need to check
On Thu, Jan 24, 2013 at 8:39 AM, Konrad Rzeszutek Wilk
kon...@kernel.org wrote:
On Fri, Jan 18, 2013 at 10:55:35AM -0500, Konrad Rzeszutek Wilk wrote:
On Mon, Jan 14, 2013 at 10:19:22PM -0800, Yinghai Lu wrote:
On Fri, Jan 11, 2013 at 9:49 AM, Yinghai Lu ying...@kernel.org wrote:
On Fri,
On Thu, Jan 24, 2013 at 9:51 AM, Shuah Khan shuahk...@gmail.com wrote:
On Thu, Jan 24, 2013 at 8:39 AM, Konrad Rzeszutek Wilk
kon...@kernel.org wrote:
On Fri, Jan 18, 2013 at 10:55:35AM -0500, Konrad Rzeszutek Wilk wrote:
On Mon, Jan 14, 2013 at 10:19:22PM -0800, Yinghai Lu wrote:
On Fri,
On Thu, Jan 24, 2013 at 11:22 AM, Shuah Khan shuahk...@gmail.com wrote:
I still have the AMD system I tested earlier versions of this work. I
started compiles with these patches on 3.7 and will let you know the
status.
Tested 3.8-rc4 with the patches on AMD system with IOMMU on. Looks
good.
On Mon, Jan 14, 2013 at 10:19:22PM -0800, Yinghai Lu wrote:
> On Fri, Jan 11, 2013 at 9:49 AM, Yinghai Lu wrote:
> > On Fri, Jan 11, 2013 at 8:52 AM, Yinghai Lu wrote:
> >>>
> >>> I need to check this patch out and then also test-run them on IA64,
> >>> AMD-VI, Calgary-X
> >>> GART and Intel
On Mon, Jan 14, 2013 at 10:19:22PM -0800, Yinghai Lu wrote:
On Fri, Jan 11, 2013 at 9:49 AM, Yinghai Lu ying...@kernel.org wrote:
On Fri, Jan 11, 2013 at 8:52 AM, Yinghai Lu ying...@kernel.org wrote:
I need to check this patch out and then also test-run them on IA64,
AMD-VI, Calgary-X
On Fri, Jan 11, 2013 at 9:49 AM, Yinghai Lu wrote:
> On Fri, Jan 11, 2013 at 8:52 AM, Yinghai Lu wrote:
>>>
>>> I need to check this patch out and then also test-run them on IA64, AMD-VI,
>>> Calgary-X
>>> GART and Intel VT-d to make a sanity test.
>>
>> that will be great, and please check
On Fri, Jan 11, 2013 at 9:49 AM, Yinghai Lu ying...@kernel.org wrote:
On Fri, Jan 11, 2013 at 8:52 AM, Yinghai Lu ying...@kernel.org wrote:
I need to check this patch out and then also test-run them on IA64, AMD-VI,
Calgary-X
GART and Intel VT-d to make a sanity test.
that will be great,
On Fri, Jan 11, 2013 at 8:52 AM, Yinghai Lu wrote:
>>
>> I need to check this patch out and then also test-run them on IA64, AMD-VI,
>> Calgary-X
>> GART and Intel VT-d to make a sanity test.
>
> that will be great, and please check attached two patches, or you want
> to me update
> for-x86-boot
On Fri, Jan 11, 2013 at 8:35 AM, Konrad Rzeszutek Wilk
wrote:
> On Thu, Jan 10, 2013 at 03:07:10PM -0800, Yinghai Lu wrote:
>
> I'm the frontline maintainer of swiotlb and related stuff so if you want to
> follow
> the proper protocol you should wait until I give you my Ack.
Sure.
>
> I need
On Thu, Jan 10, 2013 at 03:07:10PM -0800, Yinghai Lu wrote:
> On Wed, Jan 9, 2013 at 1:15 PM, Yinghai Lu wrote:
> > On Wed, Jan 9, 2013 at 1:00 PM, Eric W. Biederman
> > wrote:
> >> Yinghai Lu writes:
> >>
> >>> please check updated attached. It should address all your request.
> >>
> >> There
On Thu, Jan 10, 2013 at 03:07:10PM -0800, Yinghai Lu wrote:
On Wed, Jan 9, 2013 at 1:15 PM, Yinghai Lu ying...@kernel.org wrote:
On Wed, Jan 9, 2013 at 1:00 PM, Eric W. Biederman ebied...@xmission.com
wrote:
Yinghai Lu ying...@kernel.org writes:
please check updated attached. It should
On Fri, Jan 11, 2013 at 8:35 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Thu, Jan 10, 2013 at 03:07:10PM -0800, Yinghai Lu wrote:
I'm the frontline maintainer of swiotlb and related stuff so if you want to
follow
the proper protocol you should wait until I give you my Ack.
On Fri, Jan 11, 2013 at 8:52 AM, Yinghai Lu ying...@kernel.org wrote:
I need to check this patch out and then also test-run them on IA64, AMD-VI,
Calgary-X
GART and Intel VT-d to make a sanity test.
that will be great, and please check attached two patches, or you want
to me update
On Thu, Jan 10, 2013 at 3:15 PM, Eric W. Biederman
wrote:
> My biggest question was really why you didn't set no_iotlb
> sooner. But shrug I didn't see any real issue with the code except
> for it being silly.
how about attached one?
removed the swiotlb_init_with_default_size(), and logic
Yinghai Lu writes:
> On Wed, Jan 9, 2013 at 1:15 PM, Yinghai Lu wrote:
>> On Wed, Jan 9, 2013 at 1:00 PM, Eric W. Biederman
>> wrote:
>>> Yinghai Lu writes:
>>>
please check updated attached. It should address all your request.
>>>
>>> There is one significant bug that I can see.
>>>
On Wed, Jan 9, 2013 at 1:15 PM, Yinghai Lu wrote:
> On Wed, Jan 9, 2013 at 1:00 PM, Eric W. Biederman
> wrote:
>> Yinghai Lu writes:
>>
>>> please check updated attached. It should address all your request.
>>
>> There is one significant bug that I can see.
>>
>> swiotlb_print_info tests
On Wed, Jan 9, 2013 at 1:15 PM, Yinghai Lu ying...@kernel.org wrote:
On Wed, Jan 9, 2013 at 1:00 PM, Eric W. Biederman ebied...@xmission.com
wrote:
Yinghai Lu ying...@kernel.org writes:
please check updated attached. It should address all your request.
There is one significant bug that I
Yinghai Lu ying...@kernel.org writes:
On Wed, Jan 9, 2013 at 1:15 PM, Yinghai Lu ying...@kernel.org wrote:
On Wed, Jan 9, 2013 at 1:00 PM, Eric W. Biederman ebied...@xmission.com
wrote:
Yinghai Lu ying...@kernel.org writes:
please check updated attached. It should address all your request.
On Thu, Jan 10, 2013 at 3:15 PM, Eric W. Biederman
ebied...@xmission.com wrote:
My biggest question was really why you didn't set no_iotlb
sooner. But shrug I didn't see any real issue with the code except
for it being silly.
how about attached one?
removed the
On Wed, Jan 9, 2013 at 1:00 PM, Eric W. Biederman wrote:
> Yinghai Lu writes:
>
>> please check updated attached. It should address all your request.
>
> There is one significant bug that I can see.
>
> swiotlb_print_info tests no_iotlb_memory but no_iotlb_memory is set
> after
Yinghai Lu writes:
> please check updated attached. It should address all your request.
There is one significant bug that I can see.
swiotlb_print_info tests no_iotlb_memory but no_iotlb_memory is set
after swiotlb_init_with_tlb returns.
Eric
--
To unsubscribe from this list: send the line
On Wed, Jan 9, 2013 at 10:01 AM, Shuah Khan wrote:
> After several revisions, I am loosing track. Could you please write a
> change log and explain the change to the existing behavior. If you
> could addresses the following areas, it will be easier figure if we
> are missing something (if any):
>
On Wed, Jan 9, 2013 at 10:27 AM, Yinghai Lu wrote:
> On Wed, Jan 9, 2013 at 5:24 AM, Konrad Rzeszutek Wilk
> wrote:
>> On Tue, Jan 08, 2013 at 05:12:02PM -0800, Yinghai Lu wrote:
>>> On Tue, Jan 8, 2013 at 5:07 PM, Yinghai Lu wrote:
>>> > On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman
>>>
On Wed, Jan 9, 2013 at 5:24 AM, Konrad Rzeszutek Wilk
wrote:
> On Tue, Jan 08, 2013 at 05:12:02PM -0800, Yinghai Lu wrote:
>> On Tue, Jan 8, 2013 at 5:07 PM, Yinghai Lu wrote:
>> > On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman
>> > wrote:
>> >
>> >>
>> >> So instead we need to say?
>> >>
On Tue, Jan 08, 2013 at 05:12:02PM -0800, Yinghai Lu wrote:
> On Tue, Jan 8, 2013 at 5:07 PM, Yinghai Lu wrote:
> > On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman
> > wrote:
> >
> >>
> >> So instead we need to say?
> >>
> >> + if (no_iotlb_memory)
> >> + panic("Cannot
On Tue, Jan 08, 2013 at 04:58:14PM -0800, Eric W. Biederman wrote:
> Konrad Rzeszutek Wilk writes:
>
> > On Tue, Jan 08, 2013 at 03:40:11PM -0800, Yinghai Lu wrote:
> >> On Mon, Jan 7, 2013 at 7:50 PM, Yinghai Lu wrote:
> >> > On Mon, Jan 7, 2013 at 7:13 PM, Eric W. Biederman
> >> > wrote:
>
On Tue, Jan 08, 2013 at 04:58:14PM -0800, Eric W. Biederman wrote:
Konrad Rzeszutek Wilk konrad.w...@oracle.com writes:
On Tue, Jan 08, 2013 at 03:40:11PM -0800, Yinghai Lu wrote:
On Mon, Jan 7, 2013 at 7:50 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Jan 7, 2013 at 7:13 PM, Eric W.
On Tue, Jan 08, 2013 at 05:12:02PM -0800, Yinghai Lu wrote:
On Tue, Jan 8, 2013 at 5:07 PM, Yinghai Lu ying...@kernel.org wrote:
On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman ebied...@xmission.com
wrote:
So instead we need to say?
+ if (no_iotlb_memory)
+
On Wed, Jan 9, 2013 at 5:24 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Tue, Jan 08, 2013 at 05:12:02PM -0800, Yinghai Lu wrote:
On Tue, Jan 8, 2013 at 5:07 PM, Yinghai Lu ying...@kernel.org wrote:
On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman ebied...@xmission.com
wrote:
On Wed, Jan 9, 2013 at 10:27 AM, Yinghai Lu ying...@kernel.org wrote:
On Wed, Jan 9, 2013 at 5:24 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Tue, Jan 08, 2013 at 05:12:02PM -0800, Yinghai Lu wrote:
On Tue, Jan 8, 2013 at 5:07 PM, Yinghai Lu ying...@kernel.org wrote:
On Tue,
On Wed, Jan 9, 2013 at 10:01 AM, Shuah Khan shuahk...@gmail.com wrote:
After several revisions, I am loosing track. Could you please write a
change log and explain the change to the existing behavior. If you
could addresses the following areas, it will be easier figure if we
are missing
Yinghai Lu ying...@kernel.org writes:
please check updated attached. It should address all your request.
There is one significant bug that I can see.
swiotlb_print_info tests no_iotlb_memory but no_iotlb_memory is set
after swiotlb_init_with_tlb returns.
Eric
--
To unsubscribe from this
On Wed, Jan 9, 2013 at 1:00 PM, Eric W. Biederman ebied...@xmission.com wrote:
Yinghai Lu ying...@kernel.org writes:
please check updated attached. It should address all your request.
There is one significant bug that I can see.
swiotlb_print_info tests no_iotlb_memory but no_iotlb_memory
Yinghai Lu writes:
> On Tue, Jan 8, 2013 at 5:07 PM, Yinghai Lu wrote:
>> On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman
>> wrote:
>>
>>>
>>> So instead we need to say?
>>>
>>> + if (no_iotlb_memory)
>>> + panic("Cannot allocate SWIOTLB buffer");
>>> +
>>>
>>> Which is
On Tue, Jan 8, 2013 at 5:07 PM, Yinghai Lu wrote:
> On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman
> wrote:
>
>>
>> So instead we need to say?
>>
>> + if (no_iotlb_memory)
>> + panic("Cannot allocate SWIOTLB buffer");
>> +
>>
>> Which is just making the panic a little
On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman wrote:
>
> So instead we need to say?
>
> + if (no_iotlb_memory)
> + panic("Cannot allocate SWIOTLB buffer");
> +
>
> Which is just making the panic a little later than it used to be and
> seems completely reasonable.
yes,
Konrad Rzeszutek Wilk writes:
> On Tue, Jan 08, 2013 at 03:40:11PM -0800, Yinghai Lu wrote:
>> On Mon, Jan 7, 2013 at 7:50 PM, Yinghai Lu wrote:
>> > On Mon, Jan 7, 2013 at 7:13 PM, Eric W. Biederman
>> > wrote:
>> >> I meant we should detect failure to allocate bounce buffers in in
>> >>
On Tue, Jan 8, 2013 at 4:43 PM, Konrad Rzeszutek Wilk
wrote:
> The swiotlb_full check I don't believe is neccessary. You won't ever get
> to that unless swiotlb_map_page has at least provided a bounce buffer.
yes, the code get there, when I boot the kernel with
"memmap=4095M$1M intel_iommu=off"
On Tue, Jan 08, 2013 at 03:40:11PM -0800, Yinghai Lu wrote:
> On Mon, Jan 7, 2013 at 7:50 PM, Yinghai Lu wrote:
> > On Mon, Jan 7, 2013 at 7:13 PM, Eric W. Biederman
> > wrote:
> >> I meant we should detect failure to allocate bounce buffers in in
> >> swiotlb_init() instead of panicing.
> >>
>
Yinghai Lu writes:
> On Mon, Jan 7, 2013 at 7:50 PM, Yinghai Lu wrote:
>> On Mon, Jan 7, 2013 at 7:13 PM, Eric W. Biederman
>> wrote:
>>> I meant we should detect failure to allocate bounce buffers in in
>>> swiotlb_init() instead of panicing.
>>>
>>> I meant swiotlb_map_single() should
On Mon, Jan 7, 2013 at 7:50 PM, Yinghai Lu wrote:
> On Mon, Jan 7, 2013 at 7:13 PM, Eric W. Biederman
> wrote:
>> I meant we should detect failure to allocate bounce buffers in in
>> swiotlb_init() instead of panicing.
>>
>> I meant swiotlb_map_single() should either panic or simply fail.
>>
>>
On Mon, Jan 7, 2013 at 7:50 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Jan 7, 2013 at 7:13 PM, Eric W. Biederman ebied...@xmission.com
wrote:
I meant we should detect failure to allocate bounce buffers in in
swiotlb_init() instead of panicing.
I meant swiotlb_map_single() should
Yinghai Lu ying...@kernel.org writes:
On Mon, Jan 7, 2013 at 7:50 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Jan 7, 2013 at 7:13 PM, Eric W. Biederman ebied...@xmission.com
wrote:
I meant we should detect failure to allocate bounce buffers in in
swiotlb_init() instead of panicing.
I
On Tue, Jan 08, 2013 at 03:40:11PM -0800, Yinghai Lu wrote:
On Mon, Jan 7, 2013 at 7:50 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Jan 7, 2013 at 7:13 PM, Eric W. Biederman ebied...@xmission.com
wrote:
I meant we should detect failure to allocate bounce buffers in in
swiotlb_init()
On Tue, Jan 8, 2013 at 4:43 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
The swiotlb_full check I don't believe is neccessary. You won't ever get
to that unless swiotlb_map_page has at least provided a bounce buffer.
yes, the code get there, when I boot the kernel with
Konrad Rzeszutek Wilk konrad.w...@oracle.com writes:
On Tue, Jan 08, 2013 at 03:40:11PM -0800, Yinghai Lu wrote:
On Mon, Jan 7, 2013 at 7:50 PM, Yinghai Lu ying...@kernel.org wrote:
On Mon, Jan 7, 2013 at 7:13 PM, Eric W. Biederman ebied...@xmission.com
wrote:
I meant we should detect
On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman ebied...@xmission.com wrote:
So instead we need to say?
+ if (no_iotlb_memory)
+ panic(Cannot allocate SWIOTLB buffer);
+
Which is just making the panic a little later than it used to be and
seems completely
On Tue, Jan 8, 2013 at 5:07 PM, Yinghai Lu ying...@kernel.org wrote:
On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman ebied...@xmission.com
wrote:
So instead we need to say?
+ if (no_iotlb_memory)
+ panic(Cannot allocate SWIOTLB buffer);
+
Which is just making the
Yinghai Lu ying...@kernel.org writes:
On Tue, Jan 8, 2013 at 5:07 PM, Yinghai Lu ying...@kernel.org wrote:
On Tue, Jan 8, 2013 at 4:58 PM, Eric W. Biederman ebied...@xmission.com
wrote:
So instead we need to say?
+ if (no_iotlb_memory)
+ panic(Cannot allocate SWIOTLB
On Mon, Jan 7, 2013 at 7:13 PM, Eric W. Biederman wrote:
> I meant we should detect failure to allocate bounce buffers in in
> swiotlb_init() instead of panicing.
>
> I meant swiotlb_map_single() should either panic or simply fail.
>
> If I have read lib/swiotlb.c correctly the only place we
Yinghai Lu writes:
> On Mon, Jan 7, 2013 at 6:22 PM, Eric W. Biederman
> wrote:
>> Yinghai I sat down and read your patch and the approach you are taking
>> is totally wrong.
>
> Thanks for check the patch, did you check v3?
I looked at the version of the patch you had as an attachment. I
Konrad Rzeszutek Wilk writes:
> On Mon, Jan 07, 2013 at 06:22:51PM -0800, Eric W. Biederman wrote:
>> Shuah Khan writes:
>>
>> > On Mon, Jan 7, 2013 at 8:26 AM, Konrad Rzeszutek Wilk
>> > wrote:
>> >> On Fri, Jan 04, 2013 at 02:10:25PM -0800, Yinghai Lu wrote:
>> >>> On Fri, Jan 4, 2013 at
On Mon, Jan 7, 2013 at 6:22 PM, Eric W. Biederman wrote:
> Yinghai I sat down and read your patch and the approach you are taking
> is totally wrong.
Thanks for check the patch, did you check v3?
>
> The problem is that swiotlb_init() in lib/swiotlb.c does not know how to
> fail without
On Mon, Jan 07, 2013 at 06:22:51PM -0800, Eric W. Biederman wrote:
> Shuah Khan writes:
>
> > On Mon, Jan 7, 2013 at 8:26 AM, Konrad Rzeszutek Wilk
> > wrote:
> >> On Fri, Jan 04, 2013 at 02:10:25PM -0800, Yinghai Lu wrote:
> >>> On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan wrote:
> >>> >
Shuah Khan writes:
> On Mon, Jan 7, 2013 at 8:26 AM, Konrad Rzeszutek Wilk
> wrote:
>> On Fri, Jan 04, 2013 at 02:10:25PM -0800, Yinghai Lu wrote:
>>> On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan wrote:
>>> > Pani'cing the system doesn't sound like a good option to me in this
>>> > case. This
On Mon, Jan 7, 2013 at 12:32 PM, Yinghai Lu wrote:
>> 2). The check for 1MB is suspect. Why only 1MB? You mentioned it is
>> b/c of crashkernel_low=72M (which I am not seeing in v3.8
>> kernel-parameters.txt?
>> Is that part of your mega-patchset?). Anyhow, there seems to be a
>>
On Mon, Jan 7, 2013 at 7:26 AM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Jan 04, 2013 at 02:10:25PM -0800, Yinghai Lu wrote:
>> On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan wrote:
>> > Pani'cing the system doesn't sound like a good option to me in this
>> > case. This change to disable swiotlb is
> Also, since IOMMU drivers can no longer assume swiotlb is allocated
> enough_mem_for_swiotlb() check fails, AMD IOMMU or another other iommu
> driver can't simply rely on changing swiotlb=1 and assuming the buffer
> is there.
>
> As Konrad suggested, a hook is needed, however, I think the
On Mon, Jan 7, 2013 at 8:26 AM, Konrad Rzeszutek Wilk
wrote:
> On Fri, Jan 04, 2013 at 02:10:25PM -0800, Yinghai Lu wrote:
>> On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan wrote:
>> > Pani'cing the system doesn't sound like a good option to me in this
>> > case. This change to disable swiotlb is
On Fri, Jan 04, 2013 at 02:10:25PM -0800, Yinghai Lu wrote:
> On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan wrote:
> > Pani'cing the system doesn't sound like a good option to me in this
> > case. This change to disable swiotlb is made for kdump. However, with
> > this change several system fail to
On Fri, Jan 04, 2013 at 02:10:25PM -0800, Yinghai Lu wrote:
On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan shuahk...@gmail.com wrote:
Pani'cing the system doesn't sound like a good option to me in this
case. This change to disable swiotlb is made for kdump. However, with
this change several
On Mon, Jan 7, 2013 at 8:26 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Fri, Jan 04, 2013 at 02:10:25PM -0800, Yinghai Lu wrote:
On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan shuahk...@gmail.com wrote:
Pani'cing the system doesn't sound like a good option to me in this
case. This
Also, since IOMMU drivers can no longer assume swiotlb is allocated
enough_mem_for_swiotlb() check fails, AMD IOMMU or another other iommu
driver can't simply rely on changing swiotlb=1 and assuming the buffer
is there.
As Konrad suggested, a hook is needed, however, I think the logic to
On Mon, Jan 7, 2013 at 7:26 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Fri, Jan 04, 2013 at 02:10:25PM -0800, Yinghai Lu wrote:
On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan shuahk...@gmail.com wrote:
Pani'cing the system doesn't sound like a good option to me in this
case. This
On Mon, Jan 7, 2013 at 12:32 PM, Yinghai Lu ying...@kernel.org wrote:
2). The check for 1MB is suspect. Why only 1MB? You mentioned it is
b/c of crashkernel_low=72M (which I am not seeing in v3.8
kernel-parameters.txt?
Is that part of your mega-patchset?). Anyhow, there seems to be
Shuah Khan shuahk...@gmail.com writes:
On Mon, Jan 7, 2013 at 8:26 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Fri, Jan 04, 2013 at 02:10:25PM -0800, Yinghai Lu wrote:
On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan shuahk...@gmail.com wrote:
Pani'cing the system doesn't sound
On Mon, Jan 07, 2013 at 06:22:51PM -0800, Eric W. Biederman wrote:
Shuah Khan shuahk...@gmail.com writes:
On Mon, Jan 7, 2013 at 8:26 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Fri, Jan 04, 2013 at 02:10:25PM -0800, Yinghai Lu wrote:
On Fri, Jan 4, 2013 at 1:02 PM, Shuah
On Mon, Jan 7, 2013 at 6:22 PM, Eric W. Biederman ebied...@xmission.com wrote:
Yinghai I sat down and read your patch and the approach you are taking
is totally wrong.
Thanks for check the patch, did you check v3?
The problem is that swiotlb_init() in lib/swiotlb.c does not know how to
fail
Konrad Rzeszutek Wilk konrad.w...@oracle.com writes:
On Mon, Jan 07, 2013 at 06:22:51PM -0800, Eric W. Biederman wrote:
Shuah Khan shuahk...@gmail.com writes:
On Mon, Jan 7, 2013 at 8:26 AM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Fri, Jan 04, 2013 at 02:10:25PM -0800,
Yinghai Lu ying...@kernel.org writes:
On Mon, Jan 7, 2013 at 6:22 PM, Eric W. Biederman ebied...@xmission.com
wrote:
Yinghai I sat down and read your patch and the approach you are taking
is totally wrong.
Thanks for check the patch, did you check v3?
I looked at the version of the patch
On Mon, Jan 7, 2013 at 7:13 PM, Eric W. Biederman ebied...@xmission.com wrote:
I meant we should detect failure to allocate bounce buffers in in
swiotlb_init() instead of panicing.
I meant swiotlb_map_single() should either panic or simply fail.
If I have read lib/swiotlb.c correctly the
On Fri, Jan 4, 2013 at 9:10 PM, Yinghai Lu wrote:
> On Fri, Jan 4, 2013 at 6:02 PM, Shuah Khan wrote:
>> I applied your patch to 3.6.11 and changed the panic() to pr_info()
>> and also changed enough_mem_for_swiotlb() to always return false to
>> simulate not enough memory condition as this
On Fri, Jan 4, 2013 at 9:10 PM, Yinghai Lu ying...@kernel.org wrote:
On Fri, Jan 4, 2013 at 6:02 PM, Shuah Khan shuahk...@gmail.com wrote:
I applied your patch to 3.6.11 and changed the panic() to pr_info()
and also changed enough_mem_for_swiotlb() to always return false to
simulate not enough
On Fri, Jan 4, 2013 at 6:02 PM, Shuah Khan wrote:
> I applied your patch to 3.6.11 and changed the panic() to pr_info()
> and also changed enough_mem_for_swiotlb() to always return false to
> simulate not enough memory condition as this system does have enough
> memory.
>
> So at least on this
On Fri, Jan 4, 2013 at 4:55 PM, Yinghai Lu wrote:
> On Fri, Jan 4, 2013 at 3:21 PM, Shuah Khan wrote:
>
>> Please see attached dmesg for full log. I can do some testing on this
>> system with your patch if you would like.
>
> That would be great.
>
> Please try
>
On Fri, Jan 4, 2013 at 3:21 PM, Shuah Khan wrote:
> Please see attached dmesg for full log. I can do some testing on this
> system with your patch if you would like.
That would be great.
Please try
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-x86-boot
or just
On Fri, Jan 4, 2013 at 2:56 PM, Shuah Khan wrote:
>
> AMD IOMMU driver is using this lever to leave swiotlb enabled when it
> detects devices that can't be supported by iommu. My concern is that
> this change for kdump removes that handshake ability between iommu and
> swiolb.
No, it does not
On Fri, Jan 4, 2013 at 2:47 PM, Eric W. Biederman wrote:
> Yinghai Lu it looks like your autodetection of the problem case in this
> patch is problematic and needs a rethink. My quick skim says you are
> trying to detect failure too early in the code. Furthermore having
> kexec on panic sized
On Fri, Jan 4, 2013 at 3:47 PM, Eric W. Biederman wrote:
> Shuah Khan writes:
>
>> On Fri, Jan 4, 2013 at 3:10 PM, Yinghai Lu wrote:
>>> On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan wrote:
Pani'cing the system doesn't sound like a good option to me in this
case. This change to disable
Shuah Khan writes:
> On Fri, Jan 4, 2013 at 3:10 PM, Yinghai Lu wrote:
>> On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan wrote:
>>> Pani'cing the system doesn't sound like a good option to me in this
>>> case. This change to disable swiotlb is made for kdump. However, with
>>> this change several
On Fri, Jan 4, 2013 at 2:26 PM, Shuah Khan wrote:
> However, I think regression on existing behavior with a
> panic is a bit of a big hammer. Thie change causes panic on systems
> even when kdump is not enabled, if I understand it correctly.
I don't think so.
+static bool __init
On Fri, Jan 4, 2013 at 3:10 PM, Yinghai Lu wrote:
> On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan wrote:
>> Pani'cing the system doesn't sound like a good option to me in this
>> case. This change to disable swiotlb is made for kdump. However, with
>> this change several system fail to boot, unless
On Fri, Jan 4, 2013 at 1:02 PM, Shuah Khan wrote:
> Pani'cing the system doesn't sound like a good option to me in this
> case. This change to disable swiotlb is made for kdump. However, with
> this change several system fail to boot, unless crashkernel_low=72M is
> specified.
this patchset is
On Fri, Jan 4, 2013 at 1:34 PM, Yinghai Lu wrote:
> On Fri, Jan 4, 2013 at 9:50 AM, Shuah Khan wrote:
>>
>> This change doesn't take into account what swiolb was when
>> pci_swiotlb_detect_override() is called. Instead of returning
>> use_swiotlb like the original code did, it returns swiotlb
On Fri, Jan 4, 2013 at 9:50 AM, Shuah Khan wrote:
>
> This change doesn't take into account what swiolb was when
> pci_swiotlb_detect_override() is called. Instead of returning
> use_swiotlb like the original code did, it returns swiotlb which could
> be zero, if !enough_mem_for_swiotlb().
>
>
On Fri, Jan 4, 2013 at 8:05 AM, Konrad Rzeszutek Wilk
wrote:
>> +static bool __init enough_mem_for_swiotlb(void)
>> +{
>> + /* do we have less than 1M RAM under 4G ? */
>
> And why 1MB? The default size is 64MB.
because kdump scripts will use memmap=exact,.. to add range below 1M
to get
On Thu, Jan 3, 2013 at 5:48 PM, Yinghai Lu wrote:
> Normal boot path on system with iommu support:
> swiotlb buffer will be allocated early at first and then try to initialize
> iommu, if iommu for intel or amd could setup properly, swiotlb buffer
> will be freed.
>
> The early allocating is with
1 - 100 of 118 matches
Mail list logo
