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: <26892620-eac1-eed4-da46-da9f183d52b1@gmx.de>
Date:   Tue, 4 Oct 2016 23:54:24 +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 22:17, Andrey Korolyov wrote:
>> I'm super puzzled right now :-(
>>
> 
> There are three strawman` ideas out of head, down by a level of
> naiveness increase:
> - disk controller corrupts DMA chunks themselves, could be tested
> against usb stick/sd card with same fs or by switching disk controller
> to a legacy mode if possible, but cascading failure shown previously
> should be rather unusual for this,

I'll check out if this is possible somehow tomorrow.

> - SMP could be partially broken in such manner that it would cause
> overlapped accesses under certain conditions, may be checked with
> 'nosmp',

Unfortunately not:

  CC [M]  drivers/infiniband/core/multicast.o
  CC [M]  drivers/infiniband/core/mad.o
drivers/infiniband/core/mad.c: In function ‘ib_mad_port_close’:
drivers/infiniband/core/mad.c:3252:1: internal compiler error: Bus error
 }
 ^

nuc [~]: cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.8.0 root=UUID=f6a792b3-3027-4293-a118-f0df1de9b25c
ro ip=:::::eno1:dhcp nosmp

> - disk accesses and corresponding power spikes are causing partial
> undervoltage condition somewhere where bits are relatively freely
> flipping on paths without parity checking, though this could be
> addressed only to an onboard power distributor, not to power source
> itself.

Huh that sounds like "defective hardware" to me, wouldn't it?

Cheers and thank you for your help,
Johannes

--
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