On Wed, 01 Mar 2017 11:20:22 -0800 James Bottomley <james.bottom...@hansenpartnership.com> wrote:
> On Wed, 2017-03-01 at 10:57 -0800, James Bottomley wrote: > > On Wed, 2017-03-01 at 10:48 -0800, Stephen Hemminger wrote: > > > On Tue, 28 Feb 2017 22:20:58 -0800 > > > James Bottomley <j...@linux.vnet.ibm.com> wrote: > > > > > > > On Tue, 2017-02-28 at 17:25 -0800, Stephen Hemminger wrote: > > > > > [ 1.346023] hv_storvsc: IO cmd 0x12 0x0 0x0 scsi status 0x0 > > > > > srb > > > > > status 0x20 length 36 > > > > > [ 1.352913] inquiry data: 00000000: 00 aa be f1 5c 98 ff ff > > > > > f0 > > > > > 64 > > > > > 02 89 ff ff ff ff > > > > > [ 1.356543] inquiry data: 00000010: 00 00 00 00 00 00 00 00 > > > > > 00 > > > > > 00 > > > > > 00 00 00 00 00 00 > > > > > [ 1.359996] inquiry data: 00000020: 00 00 00 00 > > > > > [ 1.361835] scsi host1: scsi scan: INQUIRY result too short > > > > > (5), > > > > > using 36 > > > > > [ 1.361888] hv_storvsc: IO cmd 0xa0 0x0 0x0 scsi status 0x0 > > > > > srb > > > > > status 0x1 length 16 > > > > > [ 1.362307] hv_storvsc: IO cmd 0x12 0x0 0x0 scsi status 0x0 > > > > > srb > > > > > status 0x1 length 36 > > > > > [ 1.362308] inquiry data: 00000000: 00 23 34 f1 5c 98 ff ff > > > > > f0 > > > > > 64 > > > > > 02 89 ff ff ff ff > > > > > [ 1.362309] inquiry data: 00000010: 00 00 00 00 00 00 00 00 > > > > > 00 > > > > > 00 > > > > > 00 00 00 00 00 00 > > > > > [ 1.362309] inquiry data: 00000020: 00 00 00 00 > > > > > [ 1.377423] scsi 1:0:0:1: Direct-Access > > > > > > > > > > > > > > > PQ: 0 ANSI: 0 > > > > > > > > Well, this pinpoints the fault to the block uncopy, I think. The > > > > Inquiry data is clearly correct in the page frame, so it's not > > > > getting > > > > copied to the scsi_execute() buffer for some reason. > > > > > > > > James > > > > > > > > > > Why do I see different sense data on good (4.10) versus bad (4.11) > > > > > > Good 4.10 initial INQUIRY buffer > > > [ 1.012413] data: 00000000: 00 2e 64 71 db 97 ff ff f0 94 62 96 > > > ff > > > ff ff ff > > > [ 1.012413] data: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 > > > 00 > > > 00 00 00 > > > [ 1.012414] data: 00000020: 00 00 00 00 > > > > > > Bad 4.11 initial INQUIRY buffer > > > [ 1.218159] data: 00000000: 00 00 05 02 1f 00 00 02 4d 73 66 74 > > > 20 > > > 20 20 20 > > > [ 1.225654] data: 00000010: 56 69 72 74 75 61 6c 20 44 69 73 6b > > > 20 > > > 20 20 20 > > > [ 1.242930] data: 00000020: 31 2e 30 20 > > > > > > Is the kmap_atomic looking at the right place? > > > > Actually, the 4.11 data looks good. You can tell from the string at > > byte 8. It's rubbish in the 4.10 one and 'Msft ' in the 4.11 one (I > > assume you just reversed the cut and paste). > > > > These should be the page physical addresses you sent down to the > > hypervisor, so kmap should work. Perhaps print out the physical page > > address so we see what we're getting. > > Another possible explanation is non zero sg->offset, in which case you > might not see the INQUIRY data because you start at the beginning of > the page. This shouldn't happen because you specify no alignment > override in the driver, so we should start the INQUIRY buffer on a new > page and copy the data back to the real buffer, but perhaps that's what > changed. Dumping more data from 4.9, 4.10 and 4.11
