Re: [Wg-test-framework] linux 3.14.34 failure to detect disks on C600 storage controller

["Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>]

I'm not sure why you think there's a driver problem.  We've demonstrated that 
the 3.16 kernel works properly so that indicates to me that the code is 
correct.  It's possible that the 3.14 driver had a bug that was fixed in 3.16 
but even if that is the case then the response from the driver people will be 
`it's fixed, use 3.16'.

I think there is value in trying my experiment of building a 3.14 kernel based 
upon a working 3.16 config file:

        1)  If the resulting 3.14 kernel works then it proves that we are not 
fighting a driver bug (my suspicion)
        2)  I think the two 3.14 config files will be close enough that we can 
identify the necessary config options

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786

-----Original Message-----
From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx] 
Sent: Friday, April 17, 2015 10:12 AM
To: Dugger, Donald D
Cc: Ian Campbell; wg-test-framework@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [Wg-test-framework] linux 3.14.34 failure to detect disks on C600 
storage controller

Dugger, Donald D writes ("RE: [Wg-test-framework] linux 3.14.34 failure to 
detect disks on C600 storage controller"):
> Well, another possibility is that the Debian 3.16 kernel has something 
> builtin with `=y' that is needed, that wouldn't show up in the modules list.

That might be the case.

> Another thing you can try is to take the config file from the Debian 3.16 
> kernel and use it as the base to make your 3.14 kernel.  Just copy that 
> config file to `.config', do a `make oldconfig', answer any questions that 
> come up, build and see if that kernel works.  3.16 isn't that far away from 
> 3.14 so there hopefully aren't any major changes in the configs between the 
> two.

I know how to build kernels, thank you.

I could try this, but even if it fingers the configuration it wouldn't tell us 
which specific option works around what I think is probably driver bug.

I am already chasing down and trying to work around several other driver and 
kernel bugs affecting various machines in the new test setup.  For example, the 
swiotlb-related problem with Broadcom's tg3 driver.  Broadcom have been 
providing engineering support for that.

Can you please get in touch with someone technical at Intel and have them help 
investigate ?

Obviously it is in Intel's interests to get this problem fixed, not just in 
general (since it's a driver for Intel hardware) but specifically in the 
context of osstest and Xen: these machines are not going into the test pool 
until we can get them to work, and as a result we are not testing Xen on them.

Thanks,
Ian.

_______________________________________________
Wg-test-framework mailing list
Wg-test-framework@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/wg-test-framework