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

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

Well, according to the attached email you booted the Debian 3.16 kernel 
successfully which means you should be able to extract a working 3.16 config 
file to use as the base to create a 3.14 kernel.  Anyway, I'll look at your 3.2 
& 3.14 config files to see if anything pops out (I'm at a conference, probably 
won't be able to get to this until tomorrow).

--
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: Wednesday, April 22, 2015 7:52 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"):
> So you have two config files for 3.14, one the original that doesn't 
> work and one that was based upon the Debian 3.16 kernel that does.  
> Can you send me a copy of those two config files,

Not exactly.  What we have is:

  3.14.36 fails with osstest config
    failing config here
      
http://logs.test-lab.xenproject.org/osstest/logs/50472/build-amd64-pvops/build/
    which I have copied here so that it survives the osstest log expiry
      http://xenbits.xen.org/people/iwj/2015/50472.build-amd64-pvops.config
    (This is very similar to the 3.14.34 osstest config which I
    supplied a URL for previously.)

  3.14.36 success with config based on Debian's 3.2.0-4 [1]
    successful config in my previous email but I have saved a copy
    here too in case that's more convenient.
      http://xenbits.xen.org/people/iwj/2015/chardonnay-debian-based-config

> it should be possible to identify the difference that is causing the problem.

iwj@xenbits:~/public_html/2015$ diff -u 50472.build-amd64-pvops.config 
chardonnay-debian-based-config | egrep '^\+CONFIG' | wc -l
2754
iwj@xenbits:~/public_html/2015$ diff -u 50472.build-amd64-pvops.config 
chardonnay-debian-based-config | egrep '^\-CONFIG' | wc -l
317

Good luck.

Thanks,
Ian.

[1] This kernel was generated as follows:
  1. clone 3.14.36
  2. copy Debian's 3.2.0-4 out of /boot into .config
  3. run the osstest enable-xen-config script to adjust options
     that osstest thinks it wants
  4. yes '' |make oldconfig
This is very similar to the osstest config generation process; the difference 
is that osstest uses `make defconfig' for step 2, which of course is very 
different from Debian's setup.

--- Begin Message ---

• To: "Dugger, Donald D" <donald.d.dugger@xxxxxxxxx>, "wg-test-framework@xxxxxxxxxxxxxxxxxxxx" <wg-test-framework@xxxxxxxxxxxxxxxxxxxx>
• From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
• Date: Thu, 16 Apr 2015 18:40:00 +0000
• Thread-index: AQHQeHTOidcV7swTU0eAjzv5i+j3DQ==
• Thread-topic: linux 3.14.34 failure to detect disks on C600 storage controller

Ian Jackson writes ("RE: linux 3.14.34 failure to detect disks on C600 storage 
controller"):
> Dugger, Donald D writes ("RE: linux 3.14.34 failure to detect disks on C600 
> storage controller"):
> > I still think it's the initfs.  There's a lot of magic that happens when 
> > creating the initfs and I've been burned by the magic getting confused in 
> > the past.
> >
> > I guess I need to understand your build process better.  If you are 
> > building a kernel on machine A and then booting on machine B you can get 
> > hit by subtle issues in the build process.  The biggest issue is that, when 
> > creating the initfs, by default the system identifies which kernel modules 
> > to include in the initfs based upon what kernel modules are currently 
> > loaded on the build machine.  If your build machine, for example, is using 
> > IDE disks and the target machine is running SCSI expect to have problems.
>
> The initramfs is built on the target machine.  So I don't think this
> can be relevant.
>
> > On a related note, I've run into issues where Linux has split a module into 
> > 2 separate modules which confuses the initfs magic and required manual 
> > intervention.
>
> That would be a potential cause.
>
> > Another thing to try is to upgrade the Debian kernel on this machine.  You 
> > say that Debian wheezy running 3.2 works, can you just update the that 
> > machine to sid (which uses the 3.16) kernel and then see what modules are 
> > needed, that might tell us what's wrong.
>
> I can try this.

Debian's 3.16:

(initramfs) cat /proc/partitions
major minor  #blocks  name

   8        0  976762584 sda
   8        1     291840 sda1
   8        2          1 sda2
   8        5  976467968 sda5
 254        0    1949696 dm-0
(initramfs) lsmod
Module                  Size  Used by    Not tainted
usbhid                 44460  0
hid                   102264  1 usbhid
ohci_hcd               42982  0
uhci_hcd               43499  0
ehci_hcd               69837  0
usbcore               195340  4 usbhid,ohci_hcd,uhci_hcd,ehci_hcd
usb_common             12440  1 usbcore
dm_mod                 89373  2
sg                     29973  0
sd_mod                 44356  2
crc_t10dif             12431  1 sd_mod
crct10dif_common       12356  1 crc_t10dif
isci                  122261  1
ahci                   33291  0
libsas                 72596  1 isci
libahci                27158  1 ahci
libata                177457  3 ahci,libsas,libahci
scsi_transport_sas     33531  2 isci,libsas
e1000e                203664  0
ptp                    17692  1 e1000e
crc32c_intel           21809  0
pps_core               17225  1 ptp
scsi_mod              191405  6 sg,sd_mod,isci,libsas,libata,scsi_transport_sas
(initramfs)

The only module there that I can't load in my 3.14.36 is crc32c_intel.
That's CONFIG_CRYPTO_CRC32C_INTEL which I will try enabling.

Ian.

--- End Message ---

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