Sagi Grimberg 于2021年1月14日周四 上午6:13写道：
>
>
> >> The nvme spec(1.4a, figure 248) says:
> >> "A value smaller than 9 (i.e., 512 bytes) is not supported."
> >>
> >> Signed-off-by: Li Feng
> >> ---
> >> drivers/nvme/host/core.c | 6 ++
> >> 1 file changed, 6 insertions(+)
> >>
> >> diff --git
Hi Martin,
I use the nvme-tcp as the host, the target is spdk nvme-tcp target,
and set a wrong block size(i.g. bs=8), then the host prints this oops:
[ 63.153018] nvme nvme0: creating 3 I/O queues.
[ 63.181644] nvme nvme0: mapped 3/0/0 default/read/poll queues.
[ 63.185568] nvme nvme0: new
I'm sorry, ignore this one.
Li Feng 于2021年1月12日周二 下午11:30写道：
>
> If the physical_block_size and io_min is less than a sector, the
> 'granularity >> SECTOR_SHIFT' will be zero.
>
> Signed-off-by: Li Feng
> ---
> include/linux/blkdev.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git
Hi Experts,
Consider accessing a "bad" disk, if the user process submits a
'read/write' request to the kernel through libaio,
and the kernel doesn't return the IO, because the underlay disk is
bad, and IO is stuck for a long time.
When the IO is a 'read', the user-space process has its own
Oh, the trouble maker has been found.
A background program call 'udevadm retrigger' periodically.
Closed.
Feng Li 于2020年5月20日周三 下午2:47写道：
>
> Hi expert,
>
> I could see my CentOS7, `udevadm monitor` reports this log very fast:
>
> UDEV [14258.464055] change
> /devices/
Hi expert,
I could see my CentOS7, `udevadm monitor` reports this log very fast:
UDEV [14258.464055] change
/devices/LNXSYSTM:00/device:00/ACPI0004:01/LNXCPU:4d (acpi)
KERNEL[14258.464065] add /module/acpi_cpufreq (module)
KERNEL[14258.471130] remove /module/acpi_cpufreq (module)
UDEV
Just Ping.
This is a very serious issue. The OS boot from this raid controller
couldn't find bock devices after installing OS.
I think this patch should be merged asap.
Feng Li 于2018年10月12日周五 上午11:13写道：
>
> I use 'HPE Smart Array E208i-a SR Gen10 Controller', and pass through
>
Just Ping.
This is a very serious issue. The OS boot from this raid controller
couldn't find bock devices after installing OS.
I think this patch should be merged asap.
Feng Li 于2018年10月12日周五 上午11:13写道：
>
> I use 'HPE Smart Array E208i-a SR Gen10 Controller', and pass through
>
mance
downgrade is still obvious.
Could anyone give some help about this issue?
Feng Li 于2018年10月1日周一 下午10:58写道：
>
> Hi Dave,
> My comments are in-line.
>
> Dr. David Alan Gilbert 于2018年10月1日周一 下午7:41写道：
> >
> > * Feng Li (lifeng1...@gmail.com) wrote:
> > > Hi,
>
mance
downgrade is still obvious.
Could anyone give some help about this issue?
Feng Li 于2018年10月1日周一 下午10:58写道：
>
> Hi Dave,
> My comments are in-line.
>
> Dr. David Alan Gilbert 于2018年10月1日周一 下午7:41写道：
> >
> > * Feng Li (lifeng1...@gmail.com) wrote:
> > > Hi,
>
[kernel.kallsyms]
[k] sys_recvfrom
+ 78.92% 0.00% zbs-chunkd [kernel.kallsyms]
[k] system_call_fastpath
+ 78.92%78.92% zbs-chunkd [kernel.kallsyms]
[k] copy_user_enhanced_fast_string
+ 78.92% 0.00% zbs-chunkd libpthread-2.17.so
[.] __libc_recv
--
Thanks an
[kernel.kallsyms]
[k] sys_recvfrom
+ 78.92% 0.00% zbs-chunkd [kernel.kallsyms]
[k] system_call_fastpath
+ 78.92%78.92% zbs-chunkd [kernel.kallsyms]
[k] copy_user_enhanced_fast_string
+ 78.92% 0.00% zbs-chunkd libpthread-2.17.so
[.] __libc_recv
--
Thanks an
gt;> also disappeared.
> patch applied successfully and the panic has disappeared, so your fix works.
>
> Regards,
> Sumit Rai
>
>> On Jul 18, 2016, at 7:49 AM, Feng Li <lifeng1...@gmail.com> wrote:
>>
>> Hi Sumit,
>>
>> I have tested and th
gt; patch applied successfully and the panic has disappeared, so your fix works.
>
> Regards,
> Sumit Rai
>
>> On Jul 18, 2016, at 7:49 AM, Feng Li wrote:
>>
>> Hi Sumit,
>>
>> I have tested and the oops is disappeared.
>>
>> Could you double chec
09
> 49 8b 87 48 05 00 00 <4c> 8b b0 f8 01 00 00 49 8b 87 10 05 00 00 ff 90 98 00
> 00 00 41
> [ 862.784811] RIP []
> iscsi_target_login_thread+0x724/0xfa0 [iscsi_target_mod]
> [ 862.784819] RSP
> [ 862.784820] CR2: 01f8
> [ 862.784823] ---[ end trace 7e
t; 8b b0 f8 01 00 00 49 8b 87 10 05 00 00 ff 90 98 00
> 00 00 41
> [ 862.784811] RIP []
> iscsi_target_login_thread+0x724/0xfa0 [iscsi_target_mod]
> [ 862.784819] RSP
> [ 862.784820] CR2: 01f8
> [ 862.784823] ---[ end trace 7e41630f165c8027 ]--
[ 1549.332632] iSCSI Login timeout on Network Portal 10.182.70.68:3260
> [ 1549.338432] iSCSI Login negotiation failed.
> [ 1564.358423] iSCSI Login timeout on Network Portal 10.182.70.68:3260
> [ 1564.362443] iSCSI Login negotiation failed.
>
> 2016-07-12 6:15 GMT+08:00 Feng Li <
1f8
> [ 1404.917670] ---[ end trace d29d8c681ab2bdfb ]---
> [ 1419.859690] iSCSI Login timeout on Network Portal 10.182.70.69:3260
> [ 1479.832056] iSCSI Login timeout on Network Portal 10.182.70.68:3260
> [ 1479.835739] iSCSI Login negotiation failed.
> [ 1549.332632] iSCSI Login t
From: Feng Li <lifeng1...@gmail.com>
In MC/S scenario, the conn->sess has been set NULL in
iscsi_login_non_zero_tsih_s1 when the second connection comes here,
then kernel panic.
The conn->sess will be assigned in iscsi_login_non_zero_tsih_s2. So
we should check whether it's NULL be
From: Feng Li
In MC/S scenario, the conn->sess has been set NULL in
iscsi_login_non_zero_tsih_s1 when the second connection comes here,
then kernel panic.
The conn->sess will be assigned in iscsi_login_non_zero_tsih_s2. So
we should check whether it's NULL before calling.
Signed-off-by
Hi experts,
I need your help. I have written a simple driver on S3C6410 arm board. I
define my resource.
static struct resource inkprinter_resources[] = {
[0] = {
.start= S3C64XX_PA_INKPRINTER,
.end= S3C64XX_PA_INKPRINTER + S3C64XX_SZ_INKPRINTER,
.flags=
Hi experts,
I need your help. I have written a simple driver on S3C6410 arm board. I
define my resource.
static struct resource inkprinter_resources[] = {
[0] = {
.start= S3C64XX_PA_INKPRINTER,
.end= S3C64XX_PA_INKPRINTER + S3C64XX_SZ_INKPRINTER,
.flags=
22 matches
Mail list logo
