[Toybox] The cut -C test is failing because bionic's wcwidth() doesn't match glibc or musl.

[Rich Felker]

On Thu, Oct 28, 2021 at 02:41:56AM -0500, Rob Landley wrote:
> On 10/27/21 7:27 PM, enh wrote:
> >     and storage shouldn't be an issue
> >     either (Walmart is currently claiming to have a 2TB usb3 stick on sale for $12,
> >     and amazon says a 1TB sd card is $30. Can't vouch for either, but I bought a
> >     512G sd card at Target that works fine so far?)
> > 
> > and i'd strongly recommend against doing anything on an sd card --- the few
> > times i've thought i've killed my rpi400 have actually been asking it to do
> > something i/o intensive on an sd card. most of the time you don't notice they're
> > awful, but try something "medium heavy" like checking out the linux kernel onto
> > an sd card and, well, it isn't pretty...
> 
> Years ago Rich Felker found a bug in the raspberry pi sdcard driver (some kind
> of missing locking I think?) that would occasionally just STOMP the transaction
> and lobotomize the card. I have no idea if it ever got fixed.
> 
> Rich: did that fix ever go upstream?

It wasn't in the pi driver. It was in the high level SPI subsystem
logic. And it was fixed around the same time I found it. (IIRC the
subsystem maintainer wrote the fix once the issue was explained and so
it went upstream immediately.)

> (Pi had a terrible habit of eating sd cards which we made darn sure Turtle would
> not. We were using a pi as a VOIP server until it ate its SD card.)

There are still other reasons both can eat SD cards. Most shouldn't
happen without async loss of power. However one related issue (affects
my laptop's eMMC) I am aware of is that the kernel is overly strict
with the MMC-advertised timeout limits, and measures time incorrectly
(at next scheduling not immediately), such that a device that
advertises a 1ms timeout and responds in (a wrongly measured) 1.001ms
will be treated as having a fatal error, resulting in data loss.
There's a quirk flag to work around this on "known bad" devices, but
it should just be always on, because the issue is not device-specific
but a kernel logic bug.

Rich