| emmtee | Hi, I managed to rebuild a patched module by issuing sudo make drivers/net/ethernet/atheros/alx/alx.ko from the kernel source root, and it built alx.ko fine. A reboot doesn't seem to pick it up though. What I can't understand is that even if I move the original alx.ko out of its home in /lib/modules/.... , the alx module is still loading at boot??? Where is it reading alx.ko from if it is no longer in /lib/modules? | 00:18 |
|---|---|---|
| emmtee | Is there a cache? | 00:18 |
| === yuning_ is now known as yuning | ||
| apw | emmtee (N,BFTL), there is not a cache no, but there is an updates directory in lib/modules | 09:15 |
| decoder | hey | 15:24 |
| decoder | i wanted to report a strange issue we've been seeing with the 14.04 kernel lately | 15:24 |
| decoder | we're doing extensive fuzzing on the mozilla JS engine both on 14.04 and some old machines on 12.04 | 15:24 |
| decoder | recently, the developers turned on w^x, a feature to mark jit pages either as writable or executable (for security reasons) | 15:25 |
| decoder | since then we've been seeing unexplained crashes on one machine+kernel combination where hardware failure is highly unlikely | 15:25 |
| decoder | the crashes seem to be due to instruction pointer pointing at non-executable memory (I see kernel: [8453579.233671] js[23624]: segfault at f76c6000 ip 00000000f76c6000 sp 00000000ffffbfcc error 15) in dmesg and error 15 indicates typically an NX bit error | 15:26 |
| decoder | when we inspect core dumps, the memory pointed to is marked executable though | 15:26 |
| Odd_Bloke | Are release kernels and HWE kernels handled on the same SRU cadence? | 15:27 |
| Odd_Bloke | bjf: (^) | 15:27 |
| bjf | Odd_Bloke, yes | 15:27 |
| decoder | we hit this kind of bug only on one combination of hardware: an AMD opteron 6272 (32 core) machine with 14.04 | 15:27 |
| decoder | same hardware with 12.04 is fine | 15:27 |
| decoder | other hardware with 14.04 is fine | 15:27 |
| decoder | the hardware has ECC memory and doesnt show any errors, nor any other weird crashes indicating hardware failure | 15:28 |
| decoder | just nx problems | 15:28 |
| decoder | not necessarily related to ubuntu kernel changes, but i dont know where to start :) | 15:28 |
| apw | decoder, well if the page is correctly marked, that kind of implies the change in type was not migrated correctly to the CPU itself, those crashes are application level crashes right not the kernel exploding | 15:37 |
| apw | decoder, so i'd say its likley a lack of correct tlb flushing, which could easily be kernel and amd/intel specific | 15:38 |
| decoder | apw: yes, application level crash. though from the crash information it is then unexplainable why it crashed (instructions that cannot crash + instruction is on executable page according to coredump) | 16:07 |
| decoder | sounds reasonable | 16:07 |
| decoder | the page not being properly unmarked in the CPU would cause such a symptom | 16:07 |
| decoder | apw: do you think I should send this to lkml or is there anything we could try? | 16:07 |
| apw | decoder, well if you can figure out what the app is doing to change the permissions (mprotect perhaps) you may have some luck comparing the code that triggers for intel and amd | 16:18 |
| apw | decoder, though if it is a single AMD cpu (and other amd are not affected) it may be very hard to work out what semantic need we are not fulfilling | 16:19 |
| apw | after that a full specified report with as small as possibl reproduce by to upstream sounds appropriate | 16:19 |
| decoder | okay. that might get really hard. the JS engine is such a complex beast | 16:23 |
| decoder | and it's the JITs that use this feature | 16:23 |
| decoder | ill try to talk to the JS devs and see what we can come up with | 16:23 |
| === beisner- is now known as beisner | ||
| === `jpg_ is now known as `jpg | ||
| peaceful | hi cking, any news about kernel? :) | 19:44 |
| cking | peaceful, it needs to go through the SRU process, get built, regression tested and then releases, so it's another week or so at least | 19:45 |
| cking | *released | 19:45 |
| peaceful | cking, ah so next week the fix will be in the newest kernel? | 19:47 |
| cking | peaceful, perhaps week + a few days | 19:48 |
| peaceful | Does it pertain only ubuntu kernels or mainlain kernels? | 19:48 |
| cking | ubuntu kernels, and mainline if my fix gets pulled in, but maybe not until 4.6, it depends | 19:49 |
| peaceful | cking, ah ok | 19:49 |
| peaceful | pretty slow process | 19:49 |
| cking | peaceful, merging in thousands of patches per release takes effort | 19:50 |
| peaceful | cking, does it mean downloading ubuntu 15.10 and booting it will have my kernel fix? or not? | 19:50 |
| peaceful | cking, i wonder is there a way to download ubuntu 15.10 with older kernel, a kernel that works with my hardware? | 19:52 |
| cking | peaceful, no, because the CD image has to be respun for that, which we do for LTS releases only | 19:52 |
| peaceful | cking, okay | 19:52 |
| cking | as a "point release" | 19:52 |
| peaceful | cking, is there a way to replace ubuntu 15.10 iso kernel with other one of my preferance? | 19:52 |
| peaceful | So it's possible for me to boot it, install it and use older but working kernel like 3.13 for example | 19:53 |
| cking | peaceful, it's only 0's and 1's, so all is possible, but I don't know how | 19:53 |
| peaceful | i guess thats a no :) | 19:54 |
| cking | if you were to install vivid now, it would work because the ISO does not have the bug in the kernel, then wait for the fix to roll out, and pull in the new fixed kernel | 19:54 |
| peaceful | yeah trust 14.04 works | 19:55 |
| peaceful | cking, ok thanks for info :) Im leaving :) | 19:57 |
| * cking too it's way past my end of week (again) | 19:57 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!