Wspominałem już o tym błędzie tutaj. Zdaje się, że dotyczy tylko architektury ramips. Było już kilka nieudanych prób jego poprawienia.

@Cezary, może dałoby radę w kolejnych buildach dla Xiaomi R3G przejść tymczasowo na kernel 4.4 do czasu poprawienia tego błędu? Póki co wszyscy testujący potwierdzają, że na 4.4 jest OK.

Można to zrobić samemu i wziąć za ewentualne fuckupy odpowiedzialność ;-).

Ludzie niestety jak coś dostaną "od tak" - to nawet mimo ostrzeżeń - jak coś pójdzie nie tak, mają pretensje do dobroczyńcy (rozumiem Cię, Cezary :-). U mnie jak na razie działa, ale jak coś się wywali to przepnę tymczasowo modem do kompa i nic wielkiego się nie stanie. Bardziej mi zależy na bezpieczeństwie danych na dysku.

Cezary, a widziałeś ten wpis?
http://blog.csdn.net/qidi_huang/article … s/78110438

Choć w trakcie komilacji w różnych wariantach wyszło mi, że w jednym przypadku ustawienie optymalizacji -O3 na 4.9 poprawiło o tyle sytuację, że czasem dawał radę zapisać plik. Oczywiście dalej jest to rozwiązanie niestabilne, wiec nieakceptowalne. Niestety przy kolejnych próbach kernel1.bin robił się większy niż 2MB i bootloader odmawiał rozpakowania go (LZMA Error) i musiałem wrócić do -Os. Ale z tego może być wniosek, że kernel/moduł/sterownik się nie wyrabia z zapisem, a brakuje kontroli, która by go zatrzymała... Jakiś wyścig może.

Próbowałem zanim oficjalnie przeszli na 7-kę i nie zadziałało. Poprawili też obsługę DMA (a właściwie przywrócili patch, który wcześniej przestał działać - co by wyjaśniało dlaczego kiedyś było lepiej), ale w opisie commitu piszą o sieciach, nie dyskach, wiec nie wiem czy to jest to.

Przerzuciłeś 6GB w dużych czy małych plikach? U mnie mały piki (nawet w dużych ilościach) szły problemy. Stawiały się dopiero 200MB+. Daj znać, bo chętnie wrócę o kernela 4.14/4.9. A nie mam teraz czasu na eksperymenty z
kompilacją (wybacz Cezary, potrzebuję FPU emulation , więc trzymam się 4.4 na razie.

To już jest podstawa, żeby spróbować. Też często przerzucam kilku-gigowe pliki (wideo z kamery). Dzięki. Dawaj znać, a ja dziś zapuszczę kompilację.

U mnie jak na razie przeciągnięte 20 GB w plikach po 2-3 GB. Strumień niezbyt szybki, bo równolegle 6x200 KB/s. Póki co wszystko bez błędów. Poprzednio sypało się już na jednym pliku przy 200 KB/s. Reasumując - ruter na razie nie wraca do szuflady ale zachowuję czujność.

EDIT:
44 GB (1,2 MB/s) i nadal bez błędów.

Hej wszystkim,
Widzę że Cezary wrzucił nowa kompilacje z r6501 - jak tam mają się w niej opisywane problemy z dyskiem?
Nie ściągnąłem sobie wersji r6427.

Mi tak HUB siał po 2.4. Polecam obłożyć folią aluminiową, albo wsadzić w metalową puszkę. Jak jeszcze słabo to podłączyć ekran do uziemienia.

Kolejne podejście do rozwiązania problemu. Wygląda obiecująco. Tylko nie znam się na tyle na architekturach w OpenWrt aby stwierdzić czy poprawka trafi też do gałęzi ramips?

Super, dzięki Cezary za rozjaśnienie. To będzie można niedługo się przekonać czy poprawka zadziała. Choć akurat u mnie już od ponad miesiąca nie było uszkodzonych plików i ruter działa "produkcyjnie" 24/7 no ale ja nie testowałem na poważniejszych transferach.