Re: [PATCH] mm: thp: Add new kernel parameters transparent_hugepage_defrag/khugepaged_defrag

d/upstart service or put the command to set up defrag inside > > > /etc/rc.local. > > > > > > Signed-off-by: Gavin Guo > > > > Well, maybe isntead of adding these handlers, we could extend the new boot > > parameter sysctl support (handling procfs /proc/

[PATCH] mm: thp: Add new kernel parameters transparent_hugepage_defrag/khugepaged_defrag

There is no way to set up the defrag options in boot time. And it's useful to set it up by default instead of making it work by a systemd/upstart service or put the command to set up defrag inside /etc/rc.local. Signed-off-by: Gavin Guo --- .../admin-guide/kernel-parameters.txt | 18

Re: srcu hung task panic

On Tue, Oct 23, 2018 at 10:14 PM Paul E. McKenney wrote: > > On Mon, Oct 22, 2018 at 8:11 AM Krein, Dennis wrote: > > Hi Paul, > > > > My name is Dennis Krein - I am a software engineer at Netapp/Solidfire. I > > was referred to you by a tech lead in my departement, Marshalll McMullen. > > We

Re: srcu hung task panic

On Tue, Oct 23, 2018 at 10:14 PM Paul E. McKenney wrote: > > On Mon, Oct 22, 2018 at 8:11 AM Krein, Dennis wrote: > > Hi Paul, > > > > My name is Dennis Krein - I am a software engineer at Netapp/Solidfire. I > > was referred to you by a tech lead in my departement, Marshalll McMullen. > > We

Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

On Fri, Nov 3, 2017 at 6:59 PM, Hannes Reinecke <h...@suse.de> wrote: > On 11/03/2017 04:38 AM, Gavin Guo wrote: >> On Sat, Oct 28, 2017 at 11:35 AM, Gavin Guo <gavin@canonical.com> wrote: >>> On Fri, Oct 27, 2017 at 10:53 PM, Hannes Reinecke <h...@suse.de>

Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

On Fri, Nov 3, 2017 at 6:59 PM, Hannes Reinecke wrote: > On 11/03/2017 04:38 AM, Gavin Guo wrote: >> On Sat, Oct 28, 2017 at 11:35 AM, Gavin Guo wrote: >>> On Fri, Oct 27, 2017 at 10:53 PM, Hannes Reinecke wrote: >>>> On 10/27/2017 04:02 PM, Gavin Guo wrote: >

Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

On Sat, Oct 28, 2017 at 11:35 AM, Gavin Guo <gavin@canonical.com> wrote: > On Fri, Oct 27, 2017 at 10:53 PM, Hannes Reinecke <h...@suse.de> wrote: >> On 10/27/2017 04:02 PM, Gavin Guo wrote: >>> Hi Hannes, >>> >>> Thank you for looking

Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

On Sat, Oct 28, 2017 at 11:35 AM, Gavin Guo wrote: > On Fri, Oct 27, 2017 at 10:53 PM, Hannes Reinecke wrote: >> On 10/27/2017 04:02 PM, Gavin Guo wrote: >>> Hi Hannes, >>> >>> Thank you for looking into the issue. If there is anything I can help >>&

Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

On Fri, Oct 27, 2017 at 10:53 PM, Hannes Reinecke <h...@suse.de> wrote: > On 10/27/2017 04:02 PM, Gavin Guo wrote: >> Hi Hannes, >> >> Thank you for looking into the issue. If there is anything I can help >> to test the patch? I appreciate your help. Thank you. &

Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

On Fri, Oct 27, 2017 at 10:53 PM, Hannes Reinecke wrote: > On 10/27/2017 04:02 PM, Gavin Guo wrote: >> Hi Hannes, >> >> Thank you for looking into the issue. If there is anything I can help >> to test the patch? I appreciate your help. Thank you. >> > If you h

Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

Hi Hannes, Thank you for looking into the issue. If there is anything I can help to test the patch? I appreciate your help. Thank you. On Fri, Oct 6, 2017 at 9:08 AM, Gavin Guo <gavin@canonical.com> wrote: > On Mon, Oct 2, 2017 at 10:32 PM, Hannes Reinecke <h...@suse.de> wro

Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

Hi Hannes, Thank you for looking into the issue. If there is anything I can help to test the patch? I appreciate your help. Thank you. On Fri, Oct 6, 2017 at 9:08 AM, Gavin Guo wrote: > On Mon, Oct 2, 2017 at 10:32 PM, Hannes Reinecke wrote: >> On 09/27/2017 09:33 AM, Gavin

Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

On Mon, Oct 2, 2017 at 10:32 PM, Hannes Reinecke <h...@suse.de> wrote: > On 09/27/2017 09:33 AM, Gavin Guo wrote: >> There is a problem in the latest upstream kernel with the device: >> >> $ grep -i lsi lspci >> 03:00.0 Serial Attached SCSI controller [0107]: LSI

Re: mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

On Mon, Oct 2, 2017 at 10:32 PM, Hannes Reinecke wrote: > On 09/27/2017 09:33 AM, Gavin Guo wrote: >> There is a problem in the latest upstream kernel with the device: >> >> $ grep -i lsi lspci >> 03:00.0 Serial Attached SCSI controller [0107]: LSI Logic / Symbios &g

mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

There is a problem in the latest upstream kernel with the device: $ grep -i lsi lspci 03:00.0 Serial Attached SCSI controller [0107]: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS [1000:0054] (rev 01) The device is simulated by the VMware ESXi 5.5 When hotplugging a new disk to the

mptsas driver cannot detect hotplugging disk with the LSI SCSI SAS1068 controller in Ubuntu guest on VMware

There is a problem in the latest upstream kernel with the device: $ grep -i lsi lspci 03:00.0 Serial Attached SCSI controller [0107]: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS [1000:0054] (rev 01) The device is simulated by the VMware ESXi 5.5 When hotplugging a new disk to the

[kvm-unit-tests PATCH] Makefile: Disable PIE as GCC enables it by default from 6.2.0-7

buntu.com/YakketyYak/ReleaseNotes#GCC Signed-off-by: Gavin Guo <gavin@canonical.com> Signed-off-by: Hsiangkai Wang <hsiang...@gmail.com> Signed-off-by: Cole Wang <cole...@gmail.com> Tested-by: Po-Hsu Lin <po-hsu@canonical.com> --- Makefile | 4 1 file changed, 4 ins

[kvm-unit-tests PATCH] Makefile: Disable PIE as GCC enables it by default from 6.2.0-7

buntu.com/YakketyYak/ReleaseNotes#GCC Signed-off-by: Gavin Guo Signed-off-by: Hsiangkai Wang Signed-off-by: Cole Wang Tested-by: Po-Hsu Lin --- Makefile | 4 1 file changed, 4 insertions(+) diff --git a/Makefile b/Makefile index a32333b0928e..4c9fbfbb6714 100644 --- a/Makefile +++ b/Makef

Re: ioatdma(Intel(R) I/OAT DMA Engine init failed)

On Fri, May 20, 2016 at 6:17 AM, Yinghai Lu wrote: > On Thu, May 19, 2016 at 1:17 PM, Jiang, Dave wrote: >>> > > And I checked the config and found the CONFIG_PCI_MMCONFIG=y. The >>> > > following string also can be observed in the dmesg: >>> > > >>> > >

Re: ioatdma(Intel(R) I/OAT DMA Engine init failed)

On Fri, May 20, 2016 at 6:17 AM, Yinghai Lu wrote: > On Thu, May 19, 2016 at 1:17 PM, Jiang, Dave wrote: >>> > > And I checked the config and found the CONFIG_PCI_MMCONFIG=y. The >>> > > following string also can be observed in the dmesg: >>> > > >>> > > [1.419853] PCI: MMCONFIG for domain

Re: ioatdma(Intel(R) I/OAT DMA Engine init failed)

On Tue, May 17, 2016 at 6:06 PM, Vinod Koul <vinod.k...@intel.com> wrote: > On Mon, May 16, 2016 at 06:08:20PM +0800, Gavin Guo wrote: >> The following error messages can be observed on the Intel Haswell-E >> chipset with v3.13 kernel. After the analysis, I found ther

Re: ioatdma(Intel(R) I/OAT DMA Engine init failed)

On Tue, May 17, 2016 at 6:06 PM, Vinod Koul wrote: > On Mon, May 16, 2016 at 06:08:20PM +0800, Gavin Guo wrote: >> The following error messages can be observed on the Intel Haswell-E >> chipset with v3.13 kernel. After the analysis, I found there is no >> difference in the

ioatdma(Intel(R) I/OAT DMA Engine init failed)

The following error messages can be observed on the Intel Haswell-E chipset with v3.13 kernel. After the analysis, I found there is no difference in the logic of these error messages in the current upstream kernel. I also searched the git log and can't find any commit which is fix to the

ioatdma(Intel(R) I/OAT DMA Engine init failed)

The following error messages can be observed on the Intel Haswell-E chipset with v3.13 kernel. After the analysis, I found there is no difference in the logic of these error messages in the current upstream kernel. I also searched the git log and can't find any commit which is fix to the

[tip:sched/urgent] sched/numa: Fix use-after-free bug in the task_numa_compare

Commit-ID: 1dff76b92f69051e579bdc131e01500da9fa2a91 Gitweb: http://git.kernel.org/tip/1dff76b92f69051e579bdc131e01500da9fa2a91 Author: Gavin Guo AuthorDate: Wed, 20 Jan 2016 12:36:58 +0800 Committer: Ingo Molnar CommitDate: Fri, 22 Jan 2016 13:51:04 +0100 sched/numa: Fix use-after

[tip:sched/urgent] sched/numa: Fix use-after-free bug in the task_numa_compare

Commit-ID: 1dff76b92f69051e579bdc131e01500da9fa2a91 Gitweb: http://git.kernel.org/tip/1dff76b92f69051e579bdc131e01500da9fa2a91 Author: Gavin Guo <gavin@canonical.com> AuthorDate: Wed, 20 Jan 2016 12:36:58 +0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Fri, 22

[tip:sched/urgent] sched/numa: Fix use-after-free bug in the task_numa_compare

Commit-ID: 854c0defeaf069798feb2335d4fafb107facae7c Gitweb: http://git.kernel.org/tip/854c0defeaf069798feb2335d4fafb107facae7c Author: Gavin Guo AuthorDate: Wed, 20 Jan 2016 12:36:58 +0800 Committer: Ingo Molnar CommitDate: Thu, 21 Jan 2016 19:45:15 +0100 sched/numa: Fix use-after

[tip:sched/urgent] sched/numa: Fix use-after-free bug in the task_numa_compare

Commit-ID: 854c0defeaf069798feb2335d4fafb107facae7c Gitweb: http://git.kernel.org/tip/854c0defeaf069798feb2335d4fafb107facae7c Author: Gavin Guo <gavin@canonical.com> AuthorDate: Wed, 20 Jan 2016 12:36:58 +0800 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Thu, 21

Re: Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push

Hi Dave, On Mon, Aug 31, 2015 at 3:33 PM, Gavin Guo wrote: > On Sun, Aug 30, 2015 at 6:31 AM, Dave Chinner wrote: >> On Fri, Aug 28, 2015 at 08:54:04PM +0800, Gavin Guo wrote: >>> On Wed, Jul 8, 2015 at 7:37 AM, Dave Chinner wrote: >>> > On Tue, Jul 07, 2015

Re: Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push

Hi Dave, On Mon, Aug 31, 2015 at 3:33 PM, Gavin Guo <gavin@canonical.com> wrote: > On Sun, Aug 30, 2015 at 6:31 AM, Dave Chinner <da...@fromorbit.com> wrote: >> On Fri, Aug 28, 2015 at 08:54:04PM +0800, Gavin Guo wrote: >>> On Wed, Jul 8, 2015 at 7:37 AM, Dav

Re: Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push

On Sun, Aug 30, 2015 at 6:31 AM, Dave Chinner wrote: > On Fri, Aug 28, 2015 at 08:54:04PM +0800, Gavin Guo wrote: >> On Wed, Jul 8, 2015 at 7:37 AM, Dave Chinner wrote: >> > On Tue, Jul 07, 2015 at 05:29:43PM +0800, Gavin Guo wrote: >> >> Hi all, >

Re: Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push

On Sun, Aug 30, 2015 at 6:31 AM, Dave Chinner <da...@fromorbit.com> wrote: > On Fri, Aug 28, 2015 at 08:54:04PM +0800, Gavin Guo wrote: >> On Wed, Jul 8, 2015 at 7:37 AM, Dave Chinner <da...@fromorbit.com> wrote: >> > On Tue, Jul 07, 2015 at 05:29:43PM +0800,

Re: Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push

On Wed, Jul 8, 2015 at 7:37 AM, Dave Chinner wrote: > On Tue, Jul 07, 2015 at 05:29:43PM +0800, Gavin Guo wrote: >> Hi all, >> >> Recently, we observed that there is the error message in >> Ubuntu-3.13.0-48.80: >> >> "XFS: possible memory al

Re: Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push

On Wed, Jul 8, 2015 at 7:37 AM, Dave Chinner da...@fromorbit.com wrote: On Tue, Jul 07, 2015 at 05:29:43PM +0800, Gavin Guo wrote: Hi all, Recently, we observed that there is the error message in Ubuntu-3.13.0-48.80: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x8250

Re: Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push

Hi Dave, On Wed, Jul 8, 2015 at 7:37 AM, Dave Chinner wrote: > On Tue, Jul 07, 2015 at 05:29:43PM +0800, Gavin Guo wrote: >> Hi all, >> >> Recently, we observed that there is the error message in >> Ubuntu-3.13.0-48.80: >> >> "XFS: possible memory al

Re: Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push

Hi Dave, On Wed, Jul 8, 2015 at 7:37 AM, Dave Chinner da...@fromorbit.com wrote: On Tue, Jul 07, 2015 at 05:29:43PM +0800, Gavin Guo wrote: Hi all, Recently, we observed that there is the error message in Ubuntu-3.13.0-48.80: XFS: possible memory allocation deadlock in kmem_alloc (mode

Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push

t the plan. Thanks, Gavin Guo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Possible memory allocation deadlock in kmem_alloc and hung task in xfs_log_commit_cil and xlog_cil_push

. Thanks, Gavin Guo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: commit 4066c33d0308f8 breaks booting under KVM

On Mon, Jun 29, 2015 at 10:01 PM, Christoph Lameter wrote: > > On Fri, 26 Jun 2015, Linus Torvalds wrote: > > > Does reverting it fix everything? I'll give people another day or so to see > > if they can see what's wrong, but I guess I'll just revert if no fix end up > > being forthcoming.. > >

Re: commit 4066c33d0308f8 breaks booting under KVM

On Mon, Jun 29, 2015 at 10:01 PM, Christoph Lameter c...@linux.com wrote: On Fri, 26 Jun 2015, Linus Torvalds wrote: Does reverting it fix everything? I'll give people another day or so to see if they can see what's wrong, but I guess I'll just revert if no fix end up being forthcoming..

[PATCH v3] mm/slab_common: Support the slub_debug boot option on specific object size

s. - Add the KMALLOC_LOOP_LOW as the for loop start index to initialize the kmalloc_caches object. v1->v2 - Adopted suggestion from Christoph to delete the dynamic name creation for kmalloc_caches. Signed-off-by: Gavin Guo --- include/linux/slab.h | 22 +++ mm/slab_commo

Re: [PATCH v2] mm/slab_common: Support the slub_debug boot option on specific object size

Hi Rasmus, On Thu, Apr 23, 2015 at 5:55 PM, Rasmus Villemoes wrote: > On Wed, Apr 22 2015, Gavin Guo wrote: > >> /* >> + * The kmalloc_names is for temporary usage to make >> + * slub_debug=,kmalloc-xx option work in the boot time. The >> + * k

Re: [PATCH v2] mm/slab_common: Support the slub_debug boot option on specific object size

Hi Rasmus, On Thu, Apr 23, 2015 at 5:55 PM, Rasmus Villemoes li...@rasmusvillemoes.dk wrote: On Wed, Apr 22 2015, Gavin Guo gavin@canonical.com wrote: /* + * The kmalloc_names is for temporary usage to make + * slub_debug=,kmalloc-xx option work in the boot time

[PATCH v3] mm/slab_common: Support the slub_debug boot option on specific object size

the KMALLOC_LOOP_LOW as the for loop start index to initialize the kmalloc_caches object. v1-v2 - Adopted suggestion from Christoph to delete the dynamic name creation for kmalloc_caches. Signed-off-by: Gavin Guo gavin@canonical.com --- include/linux/slab.h | 22 +++ mm/slab_common.c

Re: [PATCH v2] mm/slab_common: Support the slub_debug boot option on specific object size

On Thu, Apr 23, 2015 at 5:00 AM, Andrew Morton wrote: > On Wed, 22 Apr 2015 16:33:38 +0800 Gavin Guo wrote: > >> The slub_debug=PU,kmalloc-xx cannot work because in the >> create_kmalloc_caches() the s->name is created after the >> create_kmalloc_cache()

[PATCH v2] mm/slab_common: Support the slub_debug boot option on specific object size

set up a kmalloc_names string array for the initialization purpose and delete the dynamic name creation of kmalloc_caches. v1->v2 - Adopted suggestion from Christoph to delete the dynamic name creation for kmalloc_caches. Signed-off-by: Gavin Guo --- mm/slab_comm

Re: [PATCH v2] mm/slab_common: Support the slub_debug boot option on specific object size

On Thu, Apr 23, 2015 at 5:00 AM, Andrew Morton a...@linux-foundation.org wrote: On Wed, 22 Apr 2015 16:33:38 +0800 Gavin Guo gavin@canonical.com wrote: The slub_debug=PU,kmalloc-xx cannot work because in the create_kmalloc_caches() the s-name is created after the create_kmalloc_cache

[PATCH v2] mm/slab_common: Support the slub_debug boot option on specific object size

a kmalloc_names string array for the initialization purpose and delete the dynamic name creation of kmalloc_caches. v1-v2 - Adopted suggestion from Christoph to delete the dynamic name creation for kmalloc_caches. Signed-off-by: Gavin Guo gavin@canonical.com --- mm/slab_common.c | 41

Re: [PATCH] mm/slab_common: Support the slub_debug boot option on specific object size

Hi Christoph, On Mon, Apr 20, 2015 at 11:40 PM, Christoph Lameter wrote: > On Sat, 18 Apr 2015, Gavin Guo wrote: > >> The slub_debug=PU,kmalloc-xx cannot work because in the >> create_kmalloc_caches() the s->name is created after the >> create_kmalloc_cache()

Re: [PATCH] mm/slab_common: Support the slub_debug boot option on specific object size

Hi Christoph, On Mon, Apr 20, 2015 at 11:40 PM, Christoph Lameter c...@linux.com wrote: On Sat, 18 Apr 2015, Gavin Guo wrote: The slub_debug=PU,kmalloc-xx cannot work because in the create_kmalloc_caches() the s-name is created after the create_kmalloc_cache() is called. The name is NULL

[PATCH] mm/slab_common: Support the slub_debug boot option on specific object size

set up a temporary kmalloc_names string array for the initialization purpose. After the kmalloc_caches are already it can be used to create s->name in the kasprintf. Signed-off-by: Gavin Guo --- mm/slab_common.c | 29 ++--- 1 file changed, 26 insertions(+), 3 deletions(-) d

[PATCH] mm/slab_common: Support the slub_debug boot option on specific object size

a temporary kmalloc_names string array for the initialization purpose. After the kmalloc_caches are already it can be used to create s-name in the kasprintf. Signed-off-by: Gavin Guo gavin@canonical.com --- mm/slab_common.c | 29 ++--- 1 file changed, 26 insertions(+), 3

Re: General protection fault in iscsi_rx_thread_pre_handler

Hi Nicholas, On Mon, Feb 16, 2015 at 6:52 PM, Gavin Guo wrote: > Hi Nicholas, > > On Thu, Feb 12, 2015 at 3:16 PM, Nicholas A. Bellinger > wrote: >> Hi Gavin, >> >> On Tue, 2015-02-03 at 08:28 +0800, Gavin Guo wrote: >>> Hi Nicholas, >>> >&

Re: General protection fault in iscsi_rx_thread_pre_handler

Hi Nicholas, On Thu, Feb 12, 2015 at 3:16 PM, Nicholas A. Bellinger wrote: > Hi Gavin, > > On Tue, 2015-02-03 at 08:28 +0800, Gavin Guo wrote: >> Hi Nicholas, >> >> On Sun, Feb 1, 2015 at 11:47 AM, Gavin Guo wrote: >> > Hi Nicholas, >> > &

Re: General protection fault in iscsi_rx_thread_pre_handler

Hi Nicholas, On Thu, Feb 12, 2015 at 3:16 PM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: Hi Gavin, On Tue, 2015-02-03 at 08:28 +0800, Gavin Guo wrote: Hi Nicholas, On Sun, Feb 1, 2015 at 11:47 AM, Gavin Guo gavin@canonical.com wrote: Hi Nicholas, On Sat, Jan 31, 2015 at 6

Re: General protection fault in iscsi_rx_thread_pre_handler

Hi Nicholas, On Mon, Feb 16, 2015 at 6:52 PM, Gavin Guo gavin@canonical.com wrote: Hi Nicholas, On Thu, Feb 12, 2015 at 3:16 PM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: Hi Gavin, On Tue, 2015-02-03 at 08:28 +0800, Gavin Guo wrote: Hi Nicholas, On Sun, Feb 1, 2015 at 11:47

Re: General protection fault in iscsi_rx_thread_pre_handler

Hi Nicholas, On Sun, Feb 1, 2015 at 11:47 AM, Gavin Guo wrote: > Hi Nicholas, > > On Sat, Jan 31, 2015 at 6:53 AM, Nicholas A. Bellinger > wrote: >> On Fri, 2015-01-23 at 09:30 +0800, Gavin Guo wrote: >>> Hi Nicholas, >>> >>> On Fri, Jan 23, 2015

Re: General protection fault in iscsi_rx_thread_pre_handler

Hi Nicholas, On Sun, Feb 1, 2015 at 11:47 AM, Gavin Guo gavin@canonical.com wrote: Hi Nicholas, On Sat, Jan 31, 2015 at 6:53 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: On Fri, 2015-01-23 at 09:30 +0800, Gavin Guo wrote: Hi Nicholas, On Fri, Jan 23, 2015 at 1:35 AM, Nicholas

Re: General protection fault in iscsi_rx_thread_pre_handler

Hi Nicholas, On Sat, Jan 31, 2015 at 6:53 AM, Nicholas A. Bellinger wrote: > On Fri, 2015-01-23 at 09:30 +0800, Gavin Guo wrote: >> Hi Nicholas, >> >> On Fri, Jan 23, 2015 at 1:35 AM, Nicholas A. Bellinger >> wrote: >> > On Thu, 2015-01-22 at 23:56 +080

Re: General protection fault in iscsi_rx_thread_pre_handler

Hi Nicholas, On Sat, Jan 31, 2015 at 6:53 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: On Fri, 2015-01-23 at 09:30 +0800, Gavin Guo wrote: Hi Nicholas, On Fri, Jan 23, 2015 at 1:35 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: On Thu, 2015-01-22 at 23:56 +0800, Gavin Guo

Re: General protection fault in iscsi_rx_thread_pre_handler

Hi Nicholas, On Fri, Jan 23, 2015 at 1:35 AM, Nicholas A. Bellinger wrote: > On Thu, 2015-01-22 at 23:56 +0800, Gavin Guo wrote: >> Hi Nicolas, >> >> On Thu, Jan 22, 2015 at 5:50 PM, Nicholas A. Bellinger >> wrote: >> > Hi Gavin, >> > >> &

Re: General protection fault in iscsi_rx_thread_pre_handler

Hi Nicolas, On Thu, Jan 22, 2015 at 5:50 PM, Nicholas A. Bellinger wrote: > Hi Gavin, > > On Thu, 2015-01-22 at 06:38 +0800, Gavin Guo wrote: >> Hi all, >> >> The general protection fault screenshot is attached. >> >> Summary: >> The kernel is

Re: General protection fault in iscsi_rx_thread_pre_handler

Hi Nicolas, On Thu, Jan 22, 2015 at 5:50 PM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: Hi Gavin, On Thu, 2015-01-22 at 06:38 +0800, Gavin Guo wrote: Hi all, The general protection fault screenshot is attached. Summary: The kernel is Ubuntu-3.13.0-39.66. I've done basic analysis

Re: General protection fault in iscsi_rx_thread_pre_handler

Hi Nicholas, On Fri, Jan 23, 2015 at 1:35 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: On Thu, 2015-01-22 at 23:56 +0800, Gavin Guo wrote: Hi Nicolas, On Thu, Jan 22, 2015 at 5:50 PM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: Hi Gavin, On Thu, 2015-01-22 at 06:38 +0800

Re: About the reboot hang issue with EHCI driver on the Baytrail platform

Hi Alan, On Wed, Aug 27, 2014 at 10:38 PM, Alan Stern wrote: > On Wed, 27 Aug 2014, Gavin Guo wrote: > >> > Still, why not use the BIOS setting to disable EHCI? >> >> It's hardware enablement policy. By default, we can't change the BIOS >> setting to make th

Re: About the reboot hang issue with EHCI driver on the Baytrail platform

Hi Alan, On Wed, Aug 27, 2014 at 10:38 PM, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 27 Aug 2014, Gavin Guo wrote: Still, why not use the BIOS setting to disable EHCI? It's hardware enablement policy. By default, we can't change the BIOS setting to make the bug disappear until we

Re: About the reboot hang issue with EHCI driver on the Baytrail platform

Hi Alan, On Wed, Aug 27, 2014 at 1:26 AM, Alan Stern wrote: > On Wed, 27 Aug 2014, Gavin Guo wrote: > >> >> And IIRC, there is only one host controller within >> >> EHCI and XHCI can be enabled in the Baytrail platform. I'm also trying >> >> to find out

Re: About the reboot hang issue with EHCI driver on the Baytrail platform

Hi Alan, On Tue, Aug 26, 2014 at 11:38 PM, Alan Stern wrote: > On Tue, 26 Aug 2014, Gavin Guo wrote: > >> Hi, >> >> I found that in the Baytrail-m platform if the "USB3.0 Configuration >> in Pre-OS" is set to Auto in the BIOS, the system will boot with &g

About the reboot hang issue with EHCI driver on the Baytrail platform

Hi, I found that in the Baytrail-m platform if the "USB3.0 Configuration in Pre-OS" is set to Auto in the BIOS, the system will boot with EHCI-enabled. And test reboot 200 times. It sometimes hang in the shutdown process "ehci-pci :00:1d.0: shutdown." I also found that sometimes hang in the

About the reboot hang issue with EHCI driver on the Baytrail platform

Hi, I found that in the Baytrail-m platform if the USB3.0 Configuration in Pre-OS is set to Auto in the BIOS, the system will boot with EHCI-enabled. And test reboot 200 times. It sometimes hang in the shutdown process ehci-pci :00:1d.0: shutdown. I also found that sometimes hang in the

Re: About the reboot hang issue with EHCI driver on the Baytrail platform

Hi Alan, On Tue, Aug 26, 2014 at 11:38 PM, Alan Stern st...@rowland.harvard.edu wrote: On Tue, 26 Aug 2014, Gavin Guo wrote: Hi, I found that in the Baytrail-m platform if the USB3.0 Configuration in Pre-OS is set to Auto in the BIOS, the system will boot with EHCI-enabled. And test reboot

Re: About the reboot hang issue with EHCI driver on the Baytrail platform

Hi Alan, On Wed, Aug 27, 2014 at 1:26 AM, Alan Stern st...@rowland.harvard.edu wrote: On Wed, 27 Aug 2014, Gavin Guo wrote: And IIRC, there is only one host controller within EHCI and XHCI can be enabled in the Baytrail platform. I'm also trying to find out the kernel parameters

[PATCH v2 0/1][RESEND] Fixes to the USB 3.0 detection as 2.0 on AMD platform

ed-by instead. So, I resent the v2 patch again. Gavin Guo (1): usb: Check if port status is equal to RxDetect drivers/usb/core/hub.c | 19 +++ 1 file changed, 19 insertions(+) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" i

[PATCH v2 1/1][RESEND] usb: Check if port status is equal to RxDetect

to Disabled state), it's reasonable to check the port status before really executing hub_usb3_port_disable(). Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.) Signed-off-by: Gavin Guo Acked-by: Alan Stern Cc: --- drivers/usb/core/hub.c | 19 +++ 1 file changed, 19

[PATCH v2 1/1] usb: Check if port status is equal to RxDetect

to Disabled state), it's reasonable to check the port status before really executing hub_usb3_port_disable(). Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.) Signed-off-by: Gavin Guo Signed-off-by: Alan Stern Cc: --- drivers/usb/core/hub.c | 19 +++ 1 file changed, 19

[PATCH v2 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform

v1 -> v2: According to Alan's advice in: https://lkml.org/lkml/2014/7/15/315 - Fixes the coding style. - Modify the debug messages to "Not disabling port; link state is RxDetect" to make it more expressive. Gavin Guo (1): usb: Check if port status is equal to RxDetect drivers/u

[PATCH v2 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform

v1 - v2: According to Alan's advice in: https://lkml.org/lkml/2014/7/15/315 - Fixes the coding style. - Modify the debug messages to Not disabling port; link state is RxDetect to make it more expressive. Gavin Guo (1): usb: Check if port status is equal to RxDetect drivers/usb/core/hub.c | 19

[PATCH v2 1/1] usb: Check if port status is equal to RxDetect

to Disabled state), it's reasonable to check the port status before really executing hub_usb3_port_disable(). Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.) Signed-off-by: Gavin Guo gavin@canonical.com Signed-off-by: Alan Stern st...@rowland.harvard.edu Cc: sta...@vger.kernel.org

[PATCH v2 1/1][RESEND] usb: Check if port status is equal to RxDetect

to Disabled state), it's reasonable to check the port status before really executing hub_usb3_port_disable(). Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.) Signed-off-by: Gavin Guo gavin@canonical.com Acked-by: Alan Stern st...@rowland.harvard.edu Cc: sta...@vger.kernel.org

[PATCH v2 0/1][RESEND] Fixes to the USB 3.0 detection as 2.0 on AMD platform

, I resent the v2 patch again. Gavin Guo (1): usb: Check if port status is equal to RxDetect drivers/usb/core/hub.c | 19 +++ 1 file changed, 19 insertions(+) -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord

Re: [PATCH 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform

Hi Greg, On Sat, Jul 12, 2014 at 8:04 AM, Greg KH wrote: > On Sat, Jul 12, 2014 at 07:32:34AM +0800, Gavin Guo wrote: >> Hi all, >> >> On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo wrote: >> > Hi Sarah and Mathias, >> > >> > As t

Re: [PATCH 1/1] usb: Check if port status is equal to RxDetect

Hi all, On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo wrote: > When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller > [1022:7814], the second hotplugging will experience the USB 3.0 pen > drive is recognized as high-speed device. After bisecting the kernel, > I foun

Re: [PATCH 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform

Hi all, On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo wrote: > Hi Sarah and Mathias, > > As the discussion in http://comments.gmane.org/gmane.linux.usb.general/107011, > I found that [AMD] FCH USB XHCI Controller [1022:7814] the USB 3.0 disk > can't work in SuperSpeed after several t

[PATCH 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform

some advice, or if there is any thing I missed. Thanks, Gavin Gavin Guo (1): usb: Check if port status is equal to RxDetect drivers/usb/core/hub.c | 19 +++ 1 file changed, 19 insertions(+) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-k

[PATCH 1/1] usb: Check if port status is equal to RxDetect

to Disabled state), it's reasonable to check the port status before really executing hub_usb3_port_disable(). Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.) Signed-off-by: Gavin Guo --- drivers/usb/core/hub.c | 19 +++ 1 file changed, 19 insertions(+) diff --git

[PATCH 1/1] usb: Check if port status is equal to RxDetect

to Disabled state), it's reasonable to check the port status before really executing hub_usb3_port_disable(). Fixes: 41e7e056cdc6 (USB: Allow USB 3.0 ports to be disabled.) Signed-off-by: Gavin Guo gavin@canonical.com --- drivers/usb/core/hub.c | 19 +++ 1 file changed, 19 insertions

[PATCH 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform

some advice, or if there is any thing I missed. Thanks, Gavin Gavin Guo (1): usb: Check if port status is equal to RxDetect drivers/usb/core/hub.c | 19 +++ 1 file changed, 19 insertions(+) -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: [PATCH 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform

Hi all, On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo gavin@canonical.com wrote: Hi Sarah and Mathias, As the discussion in http://comments.gmane.org/gmane.linux.usb.general/107011, I found that [AMD] FCH USB XHCI Controller [1022:7814] the USB 3.0 disk can't work in SuperSpeed after

Re: [PATCH 1/1] usb: Check if port status is equal to RxDetect

Hi all, On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo gavin@canonical.com wrote: When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller [1022:7814], the second hotplugging will experience the USB 3.0 pen drive is recognized as high-speed device. After bisecting the kernel, I

Re: [PATCH 0/1] Fixes to the USB 3.0 detection as 2.0 on AMD platform

Hi Greg, On Sat, Jul 12, 2014 at 8:04 AM, Greg KH gre...@linuxfoundation.org wrote: On Sat, Jul 12, 2014 at 07:32:34AM +0800, Gavin Guo wrote: Hi all, On Fri, Jul 11, 2014 at 2:22 PM, Gavin Guo gavin@canonical.com wrote: Hi Sarah and Mathias, As the discussion in http