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 PID:
ize to allocate 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?
>
>>>> Subj
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: Dongli Z
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 = debugfs_create_dir("swiotl
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
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 ioctl()
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
remove 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/dr
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
>> > Signed-off-by: Joe Jin
>> > ---
>> > drivers/misc/enclosure.c | 7 +++
>> > 1 file cha
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 "u
g 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
Signed-off-by: Joe Jin
---
drivers/misc/enclosure.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/misc/enclos
ing either 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
t; 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
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 l
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
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/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
neighbour code, because neigh_destroy() uses
> skb_queue_purge(&neigh->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
>
>
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
> Signed-off-by: Eric Dumazet
> ---
> net/core/neighbour.c | 12 +++-
> 1 file changed,
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,
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 n
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_policy.max
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
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
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
AD)
> 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;
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 availab
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 dr
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/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
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/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
again,
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 ano
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 Virtualization
No.
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
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
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
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/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
On 07/12/12 11:07, Dave, Tushar N wrote:
>> -Original Message-
>> From: Joe Jin [mailto:joe@oracle.com]
>> Sent: Wednesday, July 11, 2012 7:58 PM
>> To: Dave, Tushar N
>> Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux-
>> ker...@vge
On 07/12/12 10:52, Dave, Tushar N wrote:
> What is the exact error messages in BIOS log?
Error message from BIOS event log:
07/12/12 05:54:00
PCI Express Non-Fatal Error
Thanks,
Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord..
On 07/12/12 02:51, Dave, Tushar N wrote:
>
> Joe,
>
> I see couple of errors in lspci output.
> Device capability status register shows UnCorrectable PCIe error. This means
> there is certainly something went wrong. The only way to recover from
> Uncorrectable errors is reset.
>
> Dev
On 07/11/12 15:50, Dave, Tushar N wrote:
> Device status and AER sections show some errors that looks little suspicious
> to me but I'm not too sure. I will get back tomorrow.
>
Thanks a lot, Tushar!
Joe
--
Oracle <http://www.oracle.com>
Joe Jin | Software Develo
On 07/11/12 15:37, Dave, Tushar N wrote:
>> -Original Message-
>> From: Joe Jin [mailto:joe@oracle.com]
>> Sent: Wednesday, July 11, 2012 12:18 AM
>> To: Dave, Tushar N
>> Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux-
>> ker...@vge
On 07/11/12 15:11, Dave, Tushar N wrote:
>> -Original Message-
>> From: Joe Jin [mailto:joe@oracle.com]
>> Sent: Tuesday, July 10, 2012 10:03 PM
>> To: Dave, Tushar N
>> Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux-
>> ker...@vge
On 07/11/12 12:05, Dave, Tushar N wrote:
> When you said you had this issue with RHEL5 and RHEL6 drivers, have you
> install RHEl5/6 kernel and reproduced it? If so I think I should install
> RHEL6 and try reproduce it locally!
>
Yes I reproduced this on both RHEL5 and RHEL6.
So far I tried to
On 07/11/12 11:22, Dave, Tushar N wrote:
> Thanks for info. I see that hang occurs right when HW processing first TX
> descriptor with TSO.
> Would you be able to reproduce issue with TSO off? Disable TSO by 'ethtool
> -K ethx tso off'
> Let all debug enabled as it is, that will help us debug f
On 07/11/12 03:02, Dave, Tushar N wrote:
>> -Original Message-
>> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org]
>> On Behalf Of Joe Jin
>> Sent: Tuesday, July 10, 2012 12:40 AM
>> To: Joe Jin
>> Cc: e1000-de...@lists.sf.net; n
count)) {
<--- snip --->
1487 }
I checked all driver codes I did not found anywhere will set the upper.data
with
E1000_TXD_STAT_DD, I guess upper.data be set by hardware?
If OS is 32bit system, what which happen?
Thanks in advance,
Joe
On 07/09/12 16:51, Joe Jin wrote:
> Hi
On 07/09/12 17:21, Eric Dumazet wrote:
> On Mon, 2012-07-09 at 16:51 +0800, Joe Jin wrote:
>> Hi list,
>>
>> 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
&g
Hi list,
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.
Would you please help on this?
device info:
# lspci -s 05:00.0
05:00.0 Ethe
> Does a patch like this work? I don't have any test-cases, but it would be
> good to have something like this tested and passed back with proper
> explanations and sign-offs.
Yes it work find after apply the patch, thanks.
Joe
-
To unsubscribe from this list: send the line "unsubscribe linux-k
> Okay. Here is the fix for the problem.
It work fine, thanks.
> Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]>
Acked-by: Joe Jin <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
> Hmm.. in this config file, whats causing DIO to panic ? Which test actually
> passing faulty buffer ?
>
By my testing, just defined job3 and job10 will also get the panic, but if
only have one of them, panic will not appear. the faulty buffer maybe passed
by mmap.
Thanks,
Joe
-
To unsubscribe
> Well, I'm having a heck of a time getting this to fail. It looks
> possible, though. Joe, were you guys able to narrow it down to a
> reproducible test case? Do you have any oops output messages from
> the crashes?
Zach, it easy to reproduce through fio with following config file
# cat
> I tested Andrew's patch and panic was gone but got few ENOTBLK.
> So I tried with Joe's patch , both panic and ENOTBLK are gone now.
> But in Joe's patch if (ret == -ENOTBLK && (rw & WRITE)), dio_cleanup(dio)
> was not getting called because of break. So I moved dio_cleanup just
> after if (ret)
> If you are sure the problem is caused by EFAULT or ENOMEM , why not:
To this issue(wengang have posted the background), I hit it for
do_direct_IO() return EFAULT caused the panic, however, the function
not only return these critical errors, maybe other error return like
EIO.
Thanks,
Joe
-
To u
> I think we still want to run dio_cleanup() if do_direct_IO() failed?
> Otherwise we can leak pages.
>
> And there's nothing special about EFAULT or ENOMEM here: if do_direct_IO()
> returns any error then that's it: we bale out, yes?
>
Yes, I think we'll out from here if get EFAULT/ENOMEM erro
ers, at this point, kernel will panic.
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
---
--- linux-2.6.22/fs/direct-io.c.orig2007-07-26 11:32:27.0 +0800
+++ linux-2.6.22/fs/direct-io.c 2007-07-26 11:33:58.0 +0800
@@ -1031,7 +1031,9 @@ direct_io_worker(int rw, struct
Sorry for I use a unclean kernel tree, the panic have gone ;)
also, I will testing it again with other server, if I hit it I'll let you know.
Thanks,
Joe
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
> >
> > That is... surprising to me.
>
> To me also. I'd like to double-check the code which Joe actually
> tested, please - have a sneaking suspicion that the 2.6.22 version
> of that function was tested ;)
Maybe I make a fault? I'll testing it again then give you a report.
Thank,
Joe
-
To un
On 2007-07-18 05:49, Hugh Dickins wrote:
> On Wed, 18 Jul 2007, Joe Jin wrote:
> >
> > With your patch, I have reproduced the panic:
>
> That is... surprising to me. (I hadn't been able to reproduce it with
> or without the patches: maybe I just need to try har
With your patch, I have reproduced the panic:
Unable to handle kernel paging request at 186a RIP:
[] __alloc_pages+0x2f/0x2c3
PGD 72595067 PUD 72594067 PMD 0
Oops: [1] SMP
CPU 0
Modules linked in: xt_tcpudp iptable_filter ip_tables x_tables cpufreq_ondemand
dm_mirror dm_mul
>
> Patch gone too ;) I deleted it. I was hoping that you'd send me the final
> finished product (please).
>
Ha.., the patch against 2.6.22, at your patch have use htlb_alloc_mask, but I
cannot found it at 2.6.22 kernel tree, I think you must use difference kernel
tree :)
Thanks,
Joe
--- linu
>
> if (nid > MAX_NUMNODES) then that is a bug and we should report it (doing
> this via a BUG() is OK) rather than quietly covering it up.
I have create a patch to check if nid > MAX_NUMNODES, please apply it
thanks
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
---
--- linux
> >
> > The patch looks good for this bug, thanks :)
>
> If you have time could you test it and sent it back at me please?
>
Test passed and panic gone.
thanks.
> > if other caller give a invalid nid to alloc_pages_node(), __alloc_pages
> > will crash again.
>
> That would be a buggy caller,
On 2007-07-12 22:18, Andrew Morton wrote:
> On Fri, 13 Jul 2007 10:45:07 +0800 Joe Jin <[EMAIL PROTECTED]> wrote:
>
> > This patch add nid sanity check on alloc_pages_node().
> > While two process change nr_hugepages at a system, alloc_fresh_huge_page()
> > been
epages
done
Run the script at _two_ difference terminal, after a short time, a kernel panic
info will print.
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
---
--- linux-2.6.22/include/linux/gfp.h.orig 2007-07-12 15:06:23.0
+0800
+++ linux-2.6.22/include/linux/gfp.h2007-07-12
> The 2.6.9 base is very old in mainline terms. Are you sure the bug hasn't
> been fixed in mainline by other means?
I cannot confirm if it have fixed in latest kernel, the server is a
production system, it's hard to debug it and try reproduce.
-
To unsubscribe from this list: send the line "uns
>
> This is a bug actually in the megaraid.
Aha, I'll track it.
>
> And this is a direct command submission path: it already passed both
> online check gates in this path *after* the device was offlined, so
> adding a third won't fix this.
Yeah, I have notice that, however, from the logs, th
> What's the error you're trying to fix? scsi_dispatch_cmd() is only
> called from scsi_request_fn() which already has an equivalent of this
> check in it just prior to calling dispatch.
Yeah, I have saw the cheking at scsi_request_fn(), recently we got a crash
info as following at rhel4 2.6.9-42
While a scsi device hw error occured, device's status maybe setting
to SDEV_OFFLINE, So at scsi_dispatch_cmd function, we should checking
if device have offline, if yes, do nothing and just return error to
user directly.
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
--
--- linux-2.6.21-
()
called first, then call addrconf_init().
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
--- linux-2.6.20/net/ipv6/af_inet6.c.orig 2007-02-09 14:05:10.0
+0800
+++ linux-2.6.20/net/ipv6/af_inet6.c2007-02-09 14:21:54.0 +0800
@@ -930,25 +930,28 @@
{
/* First
Hi,
I have a question, while a general protection occured, do_general_protection()
should be called, to other faults, it always set siginfo struct, but at this
function, it just send a SIGSEGV by force_sig() call but not create a siginfo
struct, at send_signal(), it check the siginfo's value and
This patch replace kmalloc() + memset() pairs with the appropriate
kzalloc().
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
--- drivers/net/slip.c.orig 2007-01-16 14:21:52.0 +0800
+++ drivers/net/slip.c 2007-01-16 14:23:07.0 +0800
@@ -1343,15 +1343,12 @@
> Hi Joe,
>
> On 1/12/07, joe jin <[EMAIL PROTECTED]> wrote:
> > @@ -788,7 +786,7 @@ static int rlb_initialize(struct bonding
> >
> > spin_lock_init(&(bond_info->rx_hashtbl_lock));
> >
> > - new_hashtbl = kmalloc(size, GFP_KERNEL)
This patch replace kmalloc() + memset() pairs with the appropriate
kzalloc() calls.
Signed-off-by: Joe Jin <[EMAIL PROTECTED]>
--
diff -urNp old/drivers/net/bonding/bond_alb.c
new/drivers/net/bonding/bond_alb.c
--- old/drivers/net/bonding/bond_alb.c 2006-11-30 05:57:37.0
+0800
+
On 1/6/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
On Thu, Dec 21, 2006 at 11:07:27AM +0800, Joe Jin wrote:
Thanks for your report.
Is this issue still present in kernel 2.6.20-rc3?
And was it already present in kernel 2.6.19?
It is not occur again, just appeared this time.
At 2.6.19
94 matches
Mail list logo
