Bug 1015

I suggest a fix along the lines of that done for the n450, but in the meta/cfg/kernel-cache/bsp scc file. You can use the new cfg/smp.scc fragment.

(In reply to comment #1)
> I suggest a fix along the lines of that done for the n450, but in the
> meta/cfg/kernel-cache/bsp scc file. You can use the new cfg/smp.scc fragment.

Do you know if the EMGD binary driver needs to be rebuilt in order to work on an SMP enabled system? I've tried enabling SMP on a test platform (with the kernel in laverne), everything seemed fine until it tried to load the binary kernel module which failed with "Invalid module format".

P.S. I would have attached the log files, but I do not have access to the platform anymore, sorry!...

I wouldn't have thought so, but I'm not sure. Tom any thoughts?

(In reply to comment #3)
> I wouldn't have thought so, but I'm not sure. Tom any thoughts?

The 'invalid module format' would suggest only a kernel mismatch, so yeah, looks like the module didn't get rebuilt to match the kernel.  The userspace stuff should be fine as is with SMP or not, anyway it's binary which we can't recompile in any case.

Marc, would you like to take a stab and submitting fixes for these? You mentioned no longer having access, if that is a permanent situation, we can work on pushing it through (just might be a bit longer).

(In reply to comment #5)
> Marc, would you like to take a stab and submitting fixes for these? You
> mentioned no longer having access, if that is a permanent situation, we can
> work on pushing it through (just might be a bit longer).

I can test it if you want to submit a patch but don't have the hardware, or I can submit a tested patch, etc, either way is fine with me...

(In reply to comment #6)
> (In reply to comment #5)
> > Marc, would you like to take a stab and submitting fixes for these? You
> > mentioned no longer having access, if that is a permanent situation, we can
> > work on pushing it through (just might be a bit longer).
> 
> I can test it if you want to submit a patch but don't have the hardware, or I
> can submit a tested patch, etc, either way is fine with me...

Darren, Tom,

I have again access to the platform, I will test a fix in the linux/wrs/cfg/kernel-cache/bsp/crownbay/crownbay.cfg file on my laverne build and I'll also try the new wrs/cfg/kernel-cache/cfg/smp.scc Darren was talking about.

Created attachment 145 [details]
Patch for SMP support on crownbay.

Tom, Darren,

Here's a small patch against master I've made to add SMP support to crownbay. Things compile fine and the .config file contains SMP stuff.

I wasn't able to test it on a live platform though because of bug #986.

(In reply to comment #9)
> Tom, Darren,
> 
> Here's a small patch against master I've made to add SMP support to crownbay.
> Things compile fine and the .config file contains SMP stuff.
> 
> I wasn't able to test it on a live platform though because of bug #986.

Hmm, I'm going to have the same problem testing this - looks like we need to figure out 986.

Created attachment 161 [details]
updated version of 145: Patch for SMP support on crownbay.

same as 145: Patch for SMP support on crownbay, but with srcrev part removed and a reject fixed

Finally was able to test this patch on new hardware, works fine.  Attached is a new version of the patch - essentially the same, but I updated the SRCREVs independently already so that doesn't have to be part of the patch.  Also fixed a small reject, the bbappend must have changed since then.

Anyway, if you want to submit the patch with those changes, I can pull it into master and then when I get the chance will migrate it over into the meta branch of the kernel repo.

before:

root@crownbay-noemgd:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 38
model name      : Genuine Intel(R) CPU        @ 1.30GHz
stepping        : 1
cpu MHz         : 1299.874
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov\

pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_per\
f
mon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr p\
d
cm movbe lahf_lm dts tpr_shadow vnmi
bogomips        : 2599.74
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 48 bits virtual
power management:

after:

root@crownbay-noemgd:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 38
model name      : Genuine Intel(R) CPU        @ 1.30GHz
stepping        : 1
cpu MHz         : 1300.175
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov\

pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_per\
f
mon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr p\
d
cm movbe lahf_lm dts tpr_shadow vnmi
bogomips        : 2600.35
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 38
model name      : Genuine Intel(R) CPU        @ 1.30GHz
stepping        : 1
cpu MHz         : 1300.175
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 1
initial apicid  : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov\

pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_per\
f
mon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr p\
d
cm movbe lahf_lm dts tpr_shadow vnmi
bogomips        : 2600.16
clflush size    : 64
cache_alignment : 64
address sizes   : 32 bits physical, 48 bits virtual
power management:

(In reply to comment #12)
> Finally was able to test this patch on new hardware, works fine.  Attached is a
> new version of the patch - essentially the same, but I updated the SRCREVs
> independently already so that doesn't have to be part of the patch.  Also fixed
> a small reject, the bbappend must have changed since then.
> 
> Anyway, if you want to submit the patch with those changes, I can pull it into
> master and then when I get the chance will migrate it over into the meta branch
> of the kernel repo.
> 
Tom,
Should I send my patch to the mailing list or attach it to the bug report? I see many people are sending patches on the mailing list, is this the preferred way?

(In reply to comment #13)
> (In reply to comment #12)
> > Finally was able to test this patch on new hardware, works fine.  Attached is a
> > new version of the patch - essentially the same, but I updated the SRCREVs
> > independently already so that doesn't have to be part of the patch.  Also fixed
> > a small reject, the bbappend must have changed since then.
> > 
> > Anyway, if you want to submit the patch with those changes, I can pull it into
> > master and then when I get the chance will migrate it over into the meta branch
> > of the kernel repo.
> > 
> Tom,
> Should I send my patch to the mailing list or attach it to the bug report? I
> see many people are sending patches on the mailing list, is this the preferred
> way?

Yeah, sending it to the list is preferred (yocto@yoctoproject.org).  Thanks!

Fixed by meta-intel commit 54a572b1d4d4bfd018fc969cc2a4e1c3ba66bb39.