Aravind Parchuri wrote:
> Command with 32896 bytes:
>
> Mar 12 11:02:33 ITX000c292c3c8d kernel: iscsi: mgmtpdu [op 0x40 hdr->itt
> 0x datalen 0]
> Mar 12 11:02:33 ITX000c292c3c8d kernel: iscsi: mtask deq [cid 0 state 4
> itt 0xa05]
> Mar 12 11:03:03 ITX000c292c3c8d kernel: iscsi: mgmtpdu [
[EMAIL PROTECTED] wrote:
Aravind Parchuri wrote:
[EMAIL PROTECTED] wrote:
Aravind Parchuri wrote:
My log messages were getting all mixed up, so I cleaned up my little
test to send just one command at a time. It actually looks like the mid
layer passes the command through to open-iscsi with
Aravind Parchuri wrote:
> [EMAIL PROTECTED] wrote:
>> Aravind Parchuri wrote:
>>
>>> My log messages were getting all mixed up, so I cleaned up my little
>>> test to send just one command at a time. It actually looks like the mid
>>> layer passes the command through to open-iscsi with the right
[EMAIL PROTECTED] wrote:
> Aravind Parchuri wrote:
>
>> My log messages were getting all mixed up, so I cleaned up my little
>> test to send just one command at a time. It actually looks like the mid
>> layer passes the command through to open-iscsi with the right size the
>> first time, but the
Aravind Parchuri wrote:
> My log messages were getting all mixed up, so I cleaned up my little
> test to send just one command at a time. It actually looks like the mid
> layer passes the command through to open-iscsi with the right size the
> first time, but then it sends a second command with req
FYI, commenting out the sector roundup in sg_build_indirect ( blk_size =
(blk_size + SG_SECTOR_MSK) & (~SG_SECTOR_MSK); ) made everything work
fine with my test and open-iscsi in general. I'm sure there's a
glaringly obvious reason for that roundup (one that I'm unaware of), so
I presume this i
My log messages were getting all mixed up, so I cleaned up my little
test to send just one command at a time. It actually looks like the mid
layer passes the command through to open-iscsi with the right size the
first time, but then it sends a second command with request_bufflen = 0.
I can ver
Aravind Parchuri wrote:
> The patch has some problem. While ioctls with dxfer_len < 32k still make
> it through properly, the problematic ones now show up in open-iscsi's
> queuecommand with request_bufflen = 0. I'm not sure what the problem is
> now.
>
Could you send the sg and iscsi log output
The patch has some problem. While ioctls with dxfer_len < 32k still make
it through properly, the problematic ones now show up in open-iscsi's
queuecommand with request_bufflen = 0. I'm not sure what the problem is now.
Aravind.
[EMAIL PROTECTED] wrote:
Aravind Parchuri wrote:
In fact, ev
Aravind Parchuri wrote:
> In fact, even with the newer kernel, all commands smaller than 32k make
> it through with the right size, which leads me to think it's something
> to do with the scatter-gather list. I'm not particularly familiar with
> the scsi code, but inside scsi_execute_async, in scsi
While trying to fire WRITE BUFFER commands to an iscsi target, we found
that if the command is larger than 32kB, it gets rounded up to the next
sector before it reaches the LLD (in this case, open-iscsi). If this is
expected behavior, please disregard the rest of the message.
Unfortunately, I h
11 matches
Mail list logo
