Quantcast

malformed responce to READ_ELEMENT_STATUS ?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

malformed responce to READ_ELEMENT_STATUS ?

nstr22
Hi Mark, Our software experiences a problem with MHVTL library emulation and I believe I have traced it to a malformed response to a READ_ELEMENT_STATUS command with a particular bits combination. Here it is
opco /dev/sg3 -p0x66bc b8 14 00 00 ff ff 01 00 66 bc 00 00
executing: Read element status
status = 0x00
Good
duration = 92 ms
msg_status = 0x00 host_ = 0x0000 drv_ = 0x0000
info = 0x00
dxfer_len = 26300 (0x66bc)
resid     = 25940 (0x6554) -> 360 (0x168)
1.20 20060418

        0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
       -----------------------------------------------
0x0000  0 01  0 04  0  0 01 60 04 80  0 54  0  0 01 50   .......`...T...P
0x0010  0 01 09  0  0  0  0  0  0 81 04 07 56 4c 47 30   ............VLG0
0x0020 30 30 30 38 20 20 20 20 20 20 20 20 20 20 20 20   0008            
0x0030 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                   
0x0040 02 01  0 20 49 42 4d 20 20 20 20 20 55 4c 54 33   ... IBM     ULT3
0x0050 35 38 30 2d 54 44 33 20 20 20 20 20 58 59 5a 5a   580-TD3     XYZZ
0x0060 59 5f 45 31 20 20  0 02 09  0  0  0  0  0  0 81   Y_E1  ..........
0x0070 04 08 56 4c 47 30 30 30 30 39 20 20 20 20 20 20   ..VLG00009      
0x0080 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                   
0x0090 20 20 20 20 20 20 02 01  0 20 49 42 4d 20 20 20         ... IBM   
0x00a0 20 20 55 4c 54 33 35 38 30 2d 54 44 33 20 20 20     ULT3580-TD3   
0x00b0 20 20 58 59 5a 5a 59 5f 45 32 20 20  0 03 09  0     XYZZY_E2  ....
0x00c0  0  0  0  0  0 81 04 09 56 4c 47 30 30 30 31 30   ........VLG00010
0x00d0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                   
0x00e0 20 20 20 20 20 20 20 20 20 20 20 20 02 01  0 20               ... 
0x00f0 49 42 4d 20 20 20 20 20 55 4c 54 33 35 38 30 2d   IBM     ULT3580-
0x0100 54 44 33 20 20 20 20 20 58 59 5a 5a 59 5f 45 33   TD3     XYZZY_E3
0x0110 20 20  0 04 09  0  0  0  0  0  0 81 04 0a 56 4c     ............VL
0x0120 47 30 30 30 31 31 20 20 20 20 20 20 20 20 20 20   G00011          
0x0130 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                   
0x0140 20 20 02 01  0 20 49 42 4d 20 20 20 20 20 55 4c     ... IBM     UL
0x0150 54 33 35 38 30 2d 54 44 33 20 20 20 20 20 58 59   T3580-TD3     XY
0x0160 5a 5a 59 5f 45 34 20 20                           ZZY_E4  
I believe that byte count at offset 0x000e: should be 0x0158. This is the first time I am looking at mhvtl source code, but it looks to me that the problem comes from the call to sizeof_element() where it gets dvcid_len from smc_priv data
        return 16 + (voltag ? VOLTAG_LEN : 0) +
                (dvcid && (type == DATA_TRANSFER) ? smc_p->pm->dvcid_len : 0);
If dvcid_len is 34 the response would be valid. But it looks like it's 32. And the only library type where it's defined as 32 in default_smc
0 default_smc_pm.c  20 .dvcid_len = 32,
1 hp_smc_pm.c      115 .dvcid_len = 34,
2 ibm_smc_pm.c      22 .dvcid_len = 34,
3 overland_pm.c  105 .dvcid_len = 34,
4 scalar_pm.c       19 .dvcid_len = 34,
5 smc.h             25 uint32_t dvcid_len;
6 spectra_pm.c      39 .dvcid_len = 10,
7 stklxx_pm.c       20 .dvcid_len = 34,
What do you think? Meantime we are trying to reconfigure our mhvtl libraries with a different type, IBM for example, to see if it helps.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: malformed responce to READ_ELEMENT_STATUS ?

nstr22
Just an update. Our mhvtl libraries had been configured with a vendor id IEVTL. Don't ask me why. I do not know. But I believe this what made mhvtl to run with default_smc_pm.c configuration. When we reconfigured out libraries with STK vendor id, the problem's gone. And the response to that READ_ELEMENT_STATUS command has a correct byte count 0x0158.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: malformed responce to READ_ELEMENT_STATUS ?

Mark Harvey
Administrator
nstr22 wrote
Just an update. Our mhvtl libraries had been configured with a vendor id IEVTL. Don't ask me why. I do not know. But I believe this what made mhvtl to run with default_smc_pm.c configuration. When we reconfigured out libraries with STK vendor id, the problem's gone. And the response to that READ_ELEMENT_STATUS command has a correct byte count 0x0158.
OK, good to hear..

FWIW: The 'default' library emulation was pretty much the behaviour before I introduced the library personality module. Although there is a possibility I introduced a bug or two when I started on the library personality module.

I never use the default personality module - and I can see no real good reason to..
The STK and IBM emulations are the ones I've spent most time trying to get right.
Regards from Australia
Mark Harvey
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: malformed responce to READ_ELEMENT_STATUS ?

nstr22
Then maybe it would be a good idea to disallow using non-vetted vendor and product IDs? Because our testing department had no clue, that using 'IEVTL' string as vendor ID is not a good idea. I would not do it, but people may. And they will run into untested emulation as a result. Anyway, I confirm that our issue is closed. Libraries configured with STK work as expected.
Loading...