linux-ext4 - Re: Frequent ext4 oopses with 4.4.0 on Intel NUC6i3SYB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <de0e04f0-3eb1-5224-fc13-5ce5ee654bb9@gmx.de>
Date:   Tue, 4 Oct 2016 21:02:27 +0200
From:   Johannes Bauer <dfnsonfsduifb@....de>
To:     Andrey Korolyov <andrey@...l.ru>
Cc:     Jan Kara <jack@...e.cz>, linux-ext4@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: Frequent ext4 oopses with 4.4.0 on Intel NUC6i3SYB

On 04.10.2016 20:45, Andrey Korolyov wrote:
> On Tue, Oct 4, 2016 at 8:32 PM, Johannes Bauer <dfnsonfsduifb@....de> wrote:
>> On 04.10.2016 18:50, Johannes Bauer wrote:
>>
>>> Uhh, that sounds painful. So I'm following Ted's advice and building
>>> myself a 4.8 as we speak.
>>
>> Damn bad idea to build on the instable target. Lots of gcc segfaults and
>> weird stuff, even without a kernel panic. The system appears to be
>> instable as hell. Wonder how it can even run and how much of the root fs
>> is already corrupted :-(
>>
>> Rebuilding 4.8 on a different host.
> 
> Looks like a platform itself is somewhat faulty: [1].

Thanks for the hint, I'll post there as well. The device is less than 4
weeks old, so it's still under full warranty. Maybe it really is the HW
and I'll return it.

> Also please bear
> in mind that standalone memory testers would rather not expose certain
> classes of memory failures, I`d suggest to test allocator`s work
> against gcc runs on tmpfs, almost same as you did before. Frequency of
> crashes due to wrong pointer contents of an fs cache is most probably
> a direct outcome from its relative memory footprint.

I will and did, but strangely some kernel building on /dev/shm worked
really nice. I Ctrl-Ced, rebooted for good measure and rsynced the 4.8.0
on the device. Then, I tried to update-initramfs:

nuc [/lib/modules]: update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.4.0-21-generic
modinfo: ERROR: could not get modinfo from 'qla3xxx': Invalid argument
Segmentation fault
Segmentation fault
modinfo: ERROR: could not get modinfo from 'mpt3sas': Invalid argument
modinfo: ERROR: could not get modinfo from 'pktcdvd': No such file or
directory
Bus error
Bus error
Bus error
Bus error
Bus error
Bus error
Bus error
Bus error
Bus error
Bus error
Bus error
Bus error
[...]
Segmentation fault
Segmentation fault
Segmentation fault
Segmentation fault
update-initramfs: failed for /boot/initrd.img-4.4.0-21-generic with 139.

update-initramfs causes heavy disk I/O, so really maybe it's something
with the disk driver. As of now I really can't get 4.8.0 to even get to
a point where it'd be bootable.

I'll continue fighting on all fronts and report as soon as I learn more.
Thanks for the help, it is very much appreciated.

Cheers,
Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html