[libre-riscv-dev] daily kan-ban update 29jun2020

Jacob Lifshay programmerjake at gmail.com
Tue Jun 30 01:13:20 BST 2020

On Mon, Jun 29, 2020, 16:42 Luke Kenneth Casson Leighton <lkcl at lkcl.net>

> On Tuesday, June 30, 2020, Jacob Lifshay <programmerjake at gmail.com> wrote:
> > spent several days figuring out why my home file server was randomly
> > deadlocking, tried switching to a different version of glusterfs, finally
> > figured out that I needed to tell linux to use the generic usb-storage
> > driver instead of the uas driver for my 2 new 8TB usb hdds since they
> > apparently don't correctly implement USB.
> argh! don't tell me... usb3 and it's proprietary firmware?

yes, unfortunately

> >  Finally finished copying 5TB of
> > files after 3 days, now to checksum them...
> >
> > today:
> > helped my roommate figure out why his old computer was randomly
> > segfaulting, finally tried running memtest86 and discovered that there
> were
> > bit errors in the connection between one of the ram sticks and the cpu.
> oops... are they identical or were they bought as a "pair"?

as far as I know, it's 4 identical sticks of 8GB ddr3 ram, so 32GB total.
They've been there a long time, so it's likely they just worked their way
out of the sockets over the years. another possible explanation is one of
the pcbs cracked, which I'm hoping is not the case.

> > no
> > wonder. will later be resocketing them once we get some thermal paste
> since
> > I can't find mine.
>  somewhere in the BIOS it may be possible to set DRAM timing and/or slow
> them down.  at least, that was possible with older motherboards.

I highly doubt it's caused by unsupported timings, since they apparently
worked fine when initially installed many years ago. Will try that if
resocketing them fails.


More information about the libre-riscv-dev mailing list