On 2/7/21 12:15 PM, Dongli Zhang wrote:
> Is it possible that the issue is not due to this change?
Looks this issue does not related your change, from dmesg output, when issue
occurred, virtio was not loaded:
[ 502.508450] [ cut here ]
[ 502.511859] WARNING: CPU: 0
ocate is more than
>> PAGE_SZIE and when __GFP_RETRY_MAYFAIL is not explicitly set.
>>
>> Cc: Aruna Ramakrishna
>> Cc: Joe Jin
>> Signed-off-by: Dongli Zhang
>> ---
>> Changed since v1:
>> - To combine kzalloc() and vzalloc() as kvzalloc()
>>
On 4/28/20 10:25 AM, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 28, 2020 at 12:19:41PM +0200, Jürgen Groß wrote:
>> On 28.04.20 10:25, Peng Fan wrote:
>
> Adding Joe Jin.
>
> Joe, didn't you have some ideas on how this could be implemented?
>
>>>> Subje
Patch looks good to me.
Reviewed-by: Joe Jin
Thanks,
Joe
On 7/4/19 10:21 AM, Denis Efremov wrote:
> The function ftrace_set_clr_event is declared static and marked
> EXPORT_SYMBOL_GPL(), which is at best an odd combination. Because the
> function was decided to be a part of API, th
On 12/10/18 12:00 PM, Tim Chen wrote:
>> @@ -528,6 +538,9 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
>> dev_warn(hwdev, "swiotlb buffer is full (sz: %zd bytes)\n",
>> size);
>> return SWIOTLB_MAP_ERROR;
>> found:
>> +#ifdef CONFIG_DEBUG_FS
>> +io_tlb_used
er usage via debugfs would help the user estimate the size of
> swiotlb buffer to pre-allocate or analyze device driver memory leak issue.
>
> Signed-off-by: Dongli Zhang
Reviewed-by: Joe Jin
> ---
> Changed since v1:
> * init debugfs with late_initcall (suggested by Robi
On 12/9/18 4:37 PM, Dongli Zhang wrote:
> This patch uses io_tlb_used to help check whether swiotlb buffer is full.
> io_tlb_used is no longer used for only debugfs. It is also used to help
> optimize swiotlb_tbl_map_single().
>
> Suggested-by: Joe Jin
> Signed-off-by: Dongl
On 12/6/18 9:49 PM, Dongli Zhang wrote:
>
>
> On 12/07/2018 12:12 AM, Joe Jin wrote:
>> Hi Dongli,
>>
>> Maybe move d_swiotlb_usage declare into swiotlb_create_debugfs():
>
> I assume the call of swiotlb_tbl_map_single() might be frequent in some
> s
Hi Dongli,
Maybe move d_swiotlb_usage declare into swiotlb_create_debugfs():
void swiotlb_create_debugfs(void)
{
#ifdef CONFIG_DEBUG_FS
static struct dentry *d_swiotlb_usage = NULL;
if (d_swiotlb_usage)
return;
d_swiotlb_usage =
On 6/7/18 1:28 PM, Ben Hutchings wrote:
> On Mon, 2018-05-28 at 11:59 +0200, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> ----------
>>
>> From: Joe Jin
>>
>> commit 4855
On 6/7/18 1:28 PM, Ben Hutchings wrote:
> On Mon, 2018-05-28 at 11:59 +0200, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> ----------
>>
>> From: Joe Jin
>>
>> commit 4855
DMA heap.
This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
coherent alloc/dealloc check before swizzling the MFNs.".
Signed-off-by: Joe Jin <joe@oracle.com>
Tested-by: John Sobecki <john.sobe...@oracle.com>
Reviewed-by: Rzeszutek Wilk <kon
DMA heap.
This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
coherent alloc/dealloc check before swizzling the MFNs.".
Signed-off-by: Joe Jin
Tested-by: John Sobecki
Reviewed-by: Rzeszutek Wilk
Cc: sta...@vger.kernel.org
---
drivers/xen/swiotlb-xen.c | 2 +-
1 fi
On 5/17/18 12:10 PM, Greg KH wrote:
> On Thu, May 17, 2018 at 11:45:57AM -0700, Joe Jin wrote:
>> When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
>> but Dom Heap is increased by the same size. Tracing raidconfig we found
>> that the related io
On 5/17/18 12:10 PM, Greg KH wrote:
> On Thu, May 17, 2018 at 11:45:57AM -0700, Joe Jin wrote:
>> When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
>> but Dom Heap is increased by the same size. Tracing raidconfig we found
>> that the related io
DMA heap.
This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
coherent alloc/dealloc check before swizzling the MFNs.".
Signed-off-by: Joe Jin <joe@oracle.com>
Tested-by: John Sobecki <john.sobe...@oracle.com>
Reviewed-by: Rzeszutek Wilk <kon
DMA heap.
This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
coherent alloc/dealloc check before swizzling the MFNs.".
Signed-off-by: Joe Jin
Tested-by: John Sobecki
Reviewed-by: Rzeszutek Wilk
Cc: sta...@vger.kernel.org
---
drivers/xen/swiotlb-xen.c | 2 +-
1 fi
Hi James,
Can you please help to review the patch and comment it?
Thanks,
Joe
On 09/20/13 08:16, Joe Jin wrote:
> When do disk pull/insert test we encountered below:
>
> WARNING: at fs/sysfs/dir.c:455 sysfs_add_one+0xbc/0xe0()
> Hardware name: SUN FIRE X4370 M2 SERVER
> sysfs
Hi James,
Can you please help to review the patch and comment it?
Thanks,
Joe
On 09/20/13 08:16, Joe Jin wrote:
When do disk pull/insert test we encountered below:
WARNING: at fs/sysfs/dir.c:455 sysfs_add_one+0xbc/0xe0()
Hardware name: SUN FIRE X4370 M2 SERVER
sysfs: cannot create
the
possible duplicate entry to avoid the conflict when we add new one.
Cc: James Bottomley
Signed-off-by: Joe Jin
---
drivers/misc/enclosure.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/enclosure.c b/drivers/misc/enclosure.c
index 0e8df41..173974d 100644
--- a/drivers/misc
89a1351702ab360f ]---
This caused by duplicate device in enclosure list, we need to remove the
possible duplicate entry to avoid the conflict when we add new one.
Cc: James Bottomley james.bottom...@hansenpartnership.com
Signed-off-by: Joe Jin joe@oracle.com
---
drivers/misc/enclosure.c | 2 ++
1
evice:HDD10,
the index of component is not same then conflicted.
BTW, 6:0:27:0 and 7:0:27:0 are same disk.
>
>> > Cc: James Bottomley
>> > Signed-off-by: Joe Jin
>> > ---
>> > drivers/misc/enclosure.c | 7 +++
>> > 1 file changed, 7 insertions(+
for enclosure_device:HDD10,
the index of component is not same then conflicted.
BTW, 6:0:27:0 and 7:0:27:0 are same disk.
Cc: James Bottomley james.bottom...@hansenpartnership.com
Signed-off-by: Joe Jin joe@oracle.com
---
drivers/misc/enclosure.c | 7 +++
1 file changed, 7 insertions
On 09/09/13 21:41, Christoph Hellwig wrote:
>> Modules linked in: oracleacfs(P)(U) oracleadvm(P)(U) oracleoks(P)(U)
>
> Please reproduce without this weird crap loaded.
>
These modules is filesystem and will not impact enclosure.
Thanks,
Joe
--
To unsubscribe from this list: send the line
, multipath used, each LUN has 2 paths. when adding second
path enclousure did not check if will adding device's symlink existed or no.
Cc: James Bottomley
Signed-off-by: Joe Jin
---
drivers/misc/enclosure.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/misc/enclosure.c b/drivers
On 09/09/13 21:41, Christoph Hellwig wrote:
Modules linked in: oracleacfs(P)(U) oracleadvm(P)(U) oracleoks(P)(U)
Please reproduce without this weird crap loaded.
These modules is filesystem and will not impact enclosure.
Thanks,
Joe
--
To unsubscribe from this list: send the line
[8150fdc0] ? gs_change+0x13/0x13
---[ end trace 89a1351702ab360f ]---
During our test, multipath used, each LUN has 2 paths. when adding second
path enclousure did not check if will adding device's symlink existed or no.
Cc: James Bottomley james.bottom...@hansenpartnership.com
Signed-off-by: Joe Jin
bios or requests.
>
> Add a request-based (.map_rq) member to the error target_type and train
> dm_table_set_type() to prefer the md's established type (request-based
> or bio-based). If the md doesn't have an established type default to
> making the hybrid target bio-based.
S
-based (.map_rq) member to the error target_type and train
dm_table_set_type() to prefer the md's established type (request-based
or bio-based). If the md doesn't have an established type default to
making the hybrid target bio-based.
Signed-off-by: Joe Jin joe@oracle.com
Thanks,
Joe
" for there
is not map_rq for error target type.
Signed-off-by: Joe Jin
---
drivers/md/dm-target.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/md/dm-target.c b/drivers/md/dm-target.c
index 37ba5db..b690910 100644
--- a/drivers/md/dm-target.c
+++ b/drivers/md/dm-target.c
@@
On 08/21/13 23:06, Mike Snitzer wrote:
> On Wed, Aug 21 2013 at 10:48am -0400,
> Mikulas Patocka wrote:
>
>>
>>
>> On Wed, 21 Aug 2013, Joe Jin wrote:
>>
>>> commit a5664da "dm ioctl: make bio or request based device type immutable"
>&
commit a5664da "dm ioctl: make bio or request based device type immutable"
prevented "dmsetup wape_table" change the target type to "error".
-v2: setup md->queue even target type is "error".
Signed-off-by: Joe Jin
---
drivers/md/dm-io
commit a5664da "dm ioctl: make bio or request based device type immutable"
prevented "dmsetup wape_table" change the target type to "error".
Signed-off-by: Joe Jin
---
drivers/md/dm-ioctl.c | 6 +-
drivers/md/dm-table.c | 12
drivers/md/dm.h
commit a5664da dm ioctl: make bio or request based device type immutable
prevented dmsetup wape_table change the target type to error.
Signed-off-by: Joe Jin joe@oracle.com
---
drivers/md/dm-ioctl.c | 6 +-
drivers/md/dm-table.c | 12
drivers/md/dm.h | 1 +
3 files
commit a5664da dm ioctl: make bio or request based device type immutable
prevented dmsetup wape_table change the target type to error.
-v2: setup md-queue even target type is error.
Signed-off-by: Joe Jin joe@oracle.com
---
drivers/md/dm-ioctl.c | 4
drivers/md/dm-table.c | 12
On 08/21/13 23:06, Mike Snitzer wrote:
On Wed, Aug 21 2013 at 10:48am -0400,
Mikulas Patocka mpato...@redhat.com wrote:
On Wed, 21 Aug 2013, Joe Jin wrote:
commit a5664da dm ioctl: make bio or request based device type immutable
prevented dmsetup wape_table change the target type
target type.
Signed-off-by: Joe Jin joe@oracle.com
---
drivers/md/dm-target.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/md/dm-target.c b/drivers/md/dm-target.c
index 37ba5db..b690910 100644
--- a/drivers/md/dm-target.c
+++ b/drivers/md/dm-target.c
@@ -131,12 +131,19
On 08/16/13 20:43, Konrad Rzeszutek Wilk wrote:
> Could you tell me what has been happening without this patch?
Without this patch, Xen would not get pvhvm crash event, any config for
on_crash in guest configure file will not be triggered.
Thanks,
Joe
--
To unsubscribe from this list: send the
On 08/16/13 20:43, Konrad Rzeszutek Wilk wrote:
Could you tell me what has been happening without this patch?
Without this patch, Xen would not get pvhvm crash event, any config for
on_crash in guest configure file will not be triggered.
Thanks,
Joe
--
To unsubscribe from this list: send the
On 07/01/13 16:11, Ian Campbell wrote:
> On Mon, 2013-07-01 at 11:18 +0800, Joe Jin wrote:
>>> A workaround is to turn off O_DIRECT use by Xen as that ensures
>>> the pages are copied. Xen 4.3 does this by default.
>>>
>>> I believe fixes for this are
On 07/01/13 16:11, Ian Campbell wrote:
On Mon, 2013-07-01 at 11:18 +0800, Joe Jin wrote:
A workaround is to turn off O_DIRECT use by Xen as that ensures
the pages are copied. Xen 4.3 does this by default.
I believe fixes for this are in 4.3 and 4.2.2 if using the
qemu upstream DM. Note
On 07/01/13 16:11, Ian Campbell wrote:
> On Mon, 2013-07-01 at 11:18 +0800, Joe Jin wrote:
>>> A workaround is to turn off O_DIRECT use by Xen as that ensures
>>> the pages are copied. Xen 4.3 does this by default.
>>>
>>> I believe fixes for this are
On 07/01/13 16:11, Ian Campbell wrote:
On Mon, 2013-07-01 at 11:18 +0800, Joe Jin wrote:
A workaround is to turn off O_DIRECT use by Xen as that ensures
the pages are copied. Xen 4.3 does this by default.
I believe fixes for this are in 4.3 and 4.2.2 if using the
qemu upstream DM. Note
On 06/30/13 17:13, Alex Bligh wrote:
>
>
> --On 28 June 2013 12:17:43 +0800 Joe Jin wrote:
>
>> Find a similar issue
>> http://www.gossamer-threads.com/lists/xen/devel/265611 So copied to Xen
>> developer as well.
>
> I thought this sounded familiar. I ha
On 06/30/13 17:13, Alex Bligh wrote:
--On 28 June 2013 12:17:43 +0800 Joe Jin joe@oracle.com wrote:
Find a similar issue
http://www.gossamer-threads.com/lists/xen/devel/265611 So copied to Xen
developer as well.
I thought this sounded familiar. I haven't got the start
On 06/29/13 15:20, Eric Dumazet wrote:
> On Sat, 2013-06-29 at 07:36 +0800, Joe Jin wrote:
>> Hi Eric,
>>
>> The patch not fix the issue and panic as same as early I posted:
>>> BUG: unable to handle kernel paging request at 88006d9e8d48
>>> IP: [] memcp
On 06/29/13 15:20, Eric Dumazet wrote:
On Sat, 2013-06-29 at 07:36 +0800, Joe Jin wrote:
Hi Eric,
The patch not fix the issue and panic as same as early I posted:
BUG: unable to handle kernel paging request at 88006d9e8d48
IP: [812605bb] memcpy+0xb/0x120
PGD 1798067 PUD 1fd2067
eighbour code, because neigh_destroy() uses
> skb_queue_purge(>arp_queue) without holding neighbour lock,
> while other parts of the code assume neighbour rwlock is what
> protects arp_queue
>
> Convert all skb_queue_purge() calls to the __skb_queue_purge() variant
>
> Use __skb
kb_queue_head_init()
> to make clear we do not use arp_queue.lock
>
> And hold neigh->lock in neigh_destroy() to close the race.
>
> Reported-by: Joe Jin
> Signed-off-by: Eric Dumazet
> ---
> net/core/neighbour.c | 12 +++-
> 1 file changed, 7 inserti
arp_queue.lock
And hold neigh-lock in neigh_destroy() to close the race.
Reported-by: Joe Jin joe@oracle.com
Signed-off-by: Eric Dumazet eduma...@google.com
---
net/core/neighbour.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/net/core/neighbour.c b
protects arp_queue
Convert all skb_queue_purge() calls to the __skb_queue_purge() variant
Use __skb_queue_head_init() instead of skb_queue_head_init()
to make clear we do not use arp_queue.lock
And hold neigh-lock in neigh_destroy() to close the race.
Reported-by: Joe Jin joe
Find a similar issue http://www.gossamer-threads.com/lists/xen/devel/265611
So copied to Xen developer as well.
On 06/27/13 13:31, Eric Dumazet wrote:
> On Thu, 2013-06-27 at 10:58 +0800, Joe Jin wrote:
>> Hi,
>>
>> When we do fail over test with iscsi + multipath by reset t
Hi Eric,
Thanks for you response, will test it and get back to you.
Regards,
Joe
On 06/27/13 13:31, Eric Dumazet wrote:
> On Thu, 2013-06-27 at 10:58 +0800, Joe Jin wrote:
>> Hi,
>>
>> When we do fail over test with iscsi + multipath by reset the switches
>> on O
Hi Eric,
Thanks for you response, will test it and get back to you.
Regards,
Joe
On 06/27/13 13:31, Eric Dumazet wrote:
On Thu, 2013-06-27 at 10:58 +0800, Joe Jin wrote:
Hi,
When we do fail over test with iscsi + multipath by reset the switches
on OVM(2.6.39) we hit the panic:
BUG: unable
Find a similar issue http://www.gossamer-threads.com/lists/xen/devel/265611
So copied to Xen developer as well.
On 06/27/13 13:31, Eric Dumazet wrote:
On Thu, 2013-06-27 at 10:58 +0800, Joe Jin wrote:
Hi,
When we do fail over test with iscsi + multipath by reset the switches
on OVM(2.6.39
Hi,
When we do fail over test with iscsi + multipath by reset the switches
on OVM(2.6.39) we hit the panic:
BUG: unable to handle kernel paging request at 88006d9e8d48
IP: [] memcpy+0xb/0x120
PGD 1798067 PUD 1fd2067 PMD 213f067 PTE 0
Oops: [#1] SMP
CPU 7
Modules linked in: dm_nfs tun
Hi,
When we do fail over test with iscsi + multipath by reset the switches
on OVM(2.6.39) we hit the panic:
BUG: unable to handle kernel paging request at 88006d9e8d48
IP: [812605bb] memcpy+0xb/0x120
PGD 1798067 PUD 1fd2067 PMD 213f067 PTE 0
Oops: [#1] SMP
CPU 7
Modules linked
On 06/07/13 03:54, Rafael J. Wysocki wrote:
> Do you mean you set a limit in the BIOS setup and the kernel changed that
> limit
> on boot?
Sorry for the confusing.
The issue is when we disable hardcap before kernel boot up, after kernel bring
up, any changes of _PPC will update scaling_max_freq
On 06/06/13 19:06, Rafael J. Wysocki wrote:
> On Thursday, June 06, 2013 08:27:08 AM Joe Jin wrote:
>> On 06/06/13 04:40, Rafael J. Wysocki wrote:
>>> On Wednesday, June 05, 2013 08:52:52 AM Joe Jin wrote:
>>>> When _PPC changed dynamically the user_
On 06/06/13 19:06, Rafael J. Wysocki wrote:
On Thursday, June 06, 2013 08:27:08 AM Joe Jin wrote:
On 06/06/13 04:40, Rafael J. Wysocki wrote:
On Wednesday, June 05, 2013 08:52:52 AM Joe Jin wrote:
When _PPC changed dynamically the user_policy.max will not be updated,
this prevent CPU run
On 06/07/13 03:54, Rafael J. Wysocki wrote:
Do you mean you set a limit in the BIOS setup and the kernel changed that
limit
on boot?
Sorry for the confusing.
The issue is when we disable hardcap before kernel boot up, after kernel bring
up, any changes of _PPC will update scaling_max_freq
On 06/06/13 04:40, Rafael J. Wysocki wrote:
> On Wednesday, June 05, 2013 08:52:52 AM Joe Jin wrote:
>> When _PPC changed dynamically the user_policy.max will not be updated,
>> this prevent CPU run on the highest frequency.
>
> Why should the user setting be always related t
On 06/06/13 04:40, Rafael J. Wysocki wrote:
On Wednesday, June 05, 2013 08:52:52 AM Joe Jin wrote:
When _PPC changed dynamically the user_policy.max will not be updated,
this prevent CPU run on the highest frequency.
Why should the user setting be always related to the current maximum
When _PPC changed dynamically the user_policy.max will not be updated,
this prevent CPU run on the highest frequency.
Signed-off-by: Joe Jin
Cc: Rafael J. Wysocki
Cc: Viresh Kumar
---
drivers/acpi/processor_perflib.c | 17 -
1 file changed, 16 insertions(+), 1 deletion
When _PPC changed dynamically the user_policy.max will not be updated,
this prevent CPU run on the highest frequency.
Signed-off-by: Joe Jin joe@oracle.com
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Viresh Kumar viresh.ku...@linaro.org
---
drivers/acpi/processor_perflib.c | 17
Hi Yijing,
Thanks for your reference, the patch looks good for me, but I have no chance
to test it on customer's env.
Best Regards,
Joe
On 12/19/12 13:52, Yijing Wang wrote:
> On 2012/12/19 11:04, Joe Jin wrote:
>> Hi all,
>>
>> I backported mps commits and a
gt; Intel Corporation
> todd.fujin...@intel.com
> (503) 712-4565
>
>
> -Original Message-
> From: Ethan Zhao [mailto:ethan.ker...@gmail.com]
> Sent: Wednesday, November 28, 2012 7:10 PM
> To: Fujinaka, Todd
> Cc: Joe Jin; Ben Hutchings; Mary Mcgrath; net.
(503) 712-4565
-Original Message-
From: Ethan Zhao [mailto:ethan.ker...@gmail.com]
Sent: Wednesday, November 28, 2012 7:10 PM
To: Fujinaka, Todd
Cc: Joe Jin; Ben Hutchings; Mary Mcgrath; net...@vger.kernel.org;
e1000-de...@lists.sf.net; linux-kernel@vger.kernel.org; linux-pci
Hi Yijing,
Thanks for your reference, the patch looks good for me, but I have no chance
to test it on customer's env.
Best Regards,
Joe
On 12/19/12 13:52, Yijing Wang wrote:
On 2012/12/19 11:04, Joe Jin wrote:
Hi all,
I backported mps commits and ask customer pass pci=pcie_bus_peer2pee
On 11/28/12 02:10, Ben Hutchings wrote:
> On Tue, 2012-11-27 at 17:32 +, Fujinaka, Todd wrote:
>> Forgive me if I'm being too repetitious as I think some of this has
>> been mentioned in the past.
>>
>> We (and by we I mean the Ethernet part and driver) can only change the
>> advertised
On 11/28/12 02:10, Ben Hutchings wrote:
On Tue, 2012-11-27 at 17:32 +, Fujinaka, Todd wrote:
Forgive me if I'm being too repetitious as I think some of this has
been mentioned in the past.
We (and by we I mean the Ethernet part and driver) can only change the
advertised availability of a
On 11/27/12 00:23, Fujinaka, Todd wrote:
> If you look at the previous section, DevCap, you'll see that it's
> correctly advertising 256 bytes but the system is negotiating 128 for
> the link to the Ethernet controller. Things on the "other" side of the
> link are controlled outside of the e1000
On 11/27/12 00:23, Fujinaka, Todd wrote:
If you look at the previous section, DevCap, you'll see that it's
correctly advertising 256 bytes but the system is negotiating 128 for
the link to the Ethernet controller. Things on the other side of the
link are controlled outside of the e1000 driver.
On 11/20/12 16:59, Dave, Tushar N wrote:
> Have you power off the system completely after modifying eeprom? If not
> please do so.
Hi Tushar,
Seems not works for me, would you please help to check what is wrong of my
operations?
Original eeprom dump:
# ethtool -e eth3 | head -8
Offset
On 11/20/12 16:59, Dave, Tushar N wrote:
> Have you power off the system completely after modifying eeprom? If not
> please do so.
seems not works for me, would you please help to check what is wrong of my
operations?
Original eeprom dump:
# ethtool -e eth3 | head -8
Offset Values
On 11/20/12 16:59, Dave, Tushar N wrote:
Have you power off the system completely after modifying eeprom? If not
please do so.
seems not works for me, would you please help to check what is wrong of my
operations?
Original eeprom dump:
# ethtool -e eth3 | head -8
Offset Values
On 11/20/12 16:59, Dave, Tushar N wrote:
Have you power off the system completely after modifying eeprom? If not
please do so.
Hi Tushar,
Seems not works for me, would you please help to check what is wrong of my
operations?
Original eeprom dump:
# ethtool -e eth3 | head -8
Offset
On 11/16/12 04:26, Dave, Tushar N wrote:
>> Would you please help to fine the offset of max payload size in eeprom?
>> I'd like to have a try to modify it by ethtool.
>
> It is defined using bit 8 of word 0x1A.
> Bit value 0 = 128B , bit value 1 = 256B
Hi Tushar,
I checked one of my server
On 11/16/12 04:26, Dave, Tushar N wrote:
Would you please help to fine the offset of max payload size in eeprom?
I'd like to have a try to modify it by ethtool.
It is defined using bit 8 of word 0x1A.
Bit value 0 = 128B , bit value 1 = 256B
Hi Tushar,
I checked one of my server which Max
On 11/14/12 11:45, Dave, Tushar N wrote:
>> -Original Message-
>> From: Joe Jin [mailto:joe@oracle.com]
>> Sent: Tuesday, November 13, 2012 6:48 PM
>> To: Dave, Tushar N
>> Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux-
>> ker...@vger
On 11/14/12 11:45, Dave, Tushar N wrote:
-Original Message-
From: Joe Jin [mailto:joe@oracle.com]
Sent: Tuesday, November 13, 2012 6:48 PM
To: Dave, Tushar N
Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux-
ker...@vger.kernel.org; Mary Mcgrath
Subject: Re: 82571EB
On 11/09/12 04:35, Dave, Tushar N wrote:
> All devices in path from root complex to 82571, should have *same* max
> payload size otherwise it can cause hang.
> Can you double check this?
Hi Tushar,
Checked with hardware vendor and they said no way to modify the max payload
size
from BIOS,
On 11/09/12 04:35, Dave, Tushar N wrote:
All devices in path from root complex to 82571, should have *same* max
payload size otherwise it can cause hang.
Can you double check this?
Hi Tushar,
Checked with hardware vendor and they said no way to modify the max payload
size
from BIOS, can I
n,
Joe
> On Mon, 2012-07-09 at 16:51 +0800, Joe Jin wrote:
>> > I'm seeing a Unit Hang even with the latest e1000e driver 2.0.0 when
>> > doing scp test. this issue is easy do reproduced on SUN FIRE X2270 M2,
>> > just copy a big file (>500M) from another server wil
On Mon, 2012-07-09 at 16:51 +0800, Joe Jin wrote:
I'm seeing a Unit Hang even with the latest e1000e driver 2.0.0 when
doing scp test. this issue is easy do reproduced on SUN FIRE X2270 M2,
just copy a big file (500M) from another server will hit it at once.
All devices in path from root complex
Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
Stepping- SERR- FastB2B- DisINTx-
- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- http://www.oracle.com>
Joe Jin | Software Development Senior Manager | +8610.6106.5624
ORACLE | Linux and Virtualizatio
- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx-
+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
MAbort- SERR- PERR- INTx+
Would you please help to it?
Thanks in advance,
Joe
--
Oracle http://www.oracle.com
Joe Jin | Software Development Senior
Before use the request and response queue addr, make sure it has wrote
to the registers.
Signed-off-by: Joe Jin
Cc: Jitendra Kalsaria
Cc: Ron Mercer
---
drivers/net/ethernet/qlogic/qla3xxx.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet
Before use the request and response queue addr, make sure it has wrote
to the registers.
Signed-off-by: Joe Jin joe@oracle.com
Cc: Jitendra Kalsaria jitendra.kalsa...@qlogic.com
Cc: Ron Mercer ron.mer...@qlogic.com
---
drivers/net/ethernet/qlogic/qla3xxx.c | 9 +++--
1 file changed, 7
Before use the request and response queue addr, make sure it has wrote
to the registers.
Signed-off-by: Joe Jin
Cc: Jitendra Kalsaria
Cc: Ron Mercer
---
drivers/net/ethernet/qlogic/qla3xxx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c
b
Before use the request and response queue addr, make sure it has wrote
to the registers.
Signed-off-by: Joe Jin
Cc: Jitendra Kalsaria
Cc: Ron Mercer
---
drivers/net/ethernet/qlogic/qla3xxx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c
b
Before use the request and response queue addr, make sure it has wrote
to the registers.
Signed-off-by: Joe Jin joe@oracle.com
Cc: Jitendra Kalsaria jitendra.kalsa...@qlogic.com
Cc: Ron Mercer ron.mer...@qlogic.com
---
drivers/net/ethernet/qlogic/qla3xxx.c | 6 ++
1 file changed, 6
Before use the request and response queue addr, make sure it has wrote
to the registers.
Signed-off-by: Joe Jin joe@oracle.com
Cc: Jitendra Kalsaria jitendra.kalsa...@qlogic.com
Cc: Ron Mercer ron.mer...@qlogic.com
---
drivers/net/ethernet/qlogic/qla3xxx.c | 6 ++
1 file changed, 6
On 10/18/12 01:45, Jitendra Kalsaria wrote:
>
>
>> -Original Message-----
>> From: Joe Jin [mailto:joe@oracle.com]
>> Sent: Tuesday, October 16, 2012 11:32 PM
>> To: Ron Mercer; Jitendra Kalsaria; Dept-Eng Linux Driver
>> Cc: netdev; linux-ker
Make sure req_q_phy_addr write to the register.
Signed-off-by: Joe Jin
Cc: Ron Mercer
Cc: Jitendra Kalsaria
---
drivers/net/ethernet/qlogic/qla3xxx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c
b/drivers/net/ethernet/qlogic/qla3xxx.c
index
Make sure req_q_phy_addr write to the register.
Signed-off-by: Joe Jin joe@oracle.com
Cc: Ron Mercer ron.mer...@qlogic.com
Cc: Jitendra Kalsaria jitendra.kalsa...@qlogic.com
---
drivers/net/ethernet/qlogic/qla3xxx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net
On 10/18/12 01:45, Jitendra Kalsaria wrote:
-Original Message-
From: Joe Jin [mailto:joe@oracle.com]
Sent: Tuesday, October 16, 2012 11:32 PM
To: Ron Mercer; Jitendra Kalsaria; Dept-Eng Linux Driver
Cc: netdev; linux-kernel; Greg Marsden
Subject: [PATCH] qla3xxx: Ensure
On 07/15/12 11:42, Dave, Tushar N wrote:
>> -Original Message-
>> From: Joe Jin [mailto:joe@oracle.com]
>> Sent: Thursday, July 12, 2012 9:34 PM
>> To: Dave, Tushar N
>> Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux-
>> ker...@vge
On 07/15/12 11:42, Dave, Tushar N wrote:
-Original Message-
From: Joe Jin [mailto:joe@oracle.com]
Sent: Thursday, July 12, 2012 9:34 PM
To: Dave, Tushar N
Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux-
ker...@vger.kernel.org
Subject: Re: 82571EB: Detected Hardware
On 07/12/12 13:57, Dave, Tushar N wrote:
>> -Original Message-
>> From: Joe Jin [mailto:joe@oracle.com]
>> Sent: Wednesday, July 11, 2012 8:13 PM
>> To: Dave, Tushar N
>> Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux-
>> ker...@vge
1 - 100 of 179 matches
Mail list logo
