Thank you for the clarification. I guess I misread those wikipedia pages. Reading it now, it looks like maybe the page author was recommending booting the MAKAI distribution on a PC to use as a base for installing the GLANTANK firmware?
And was GLANTANK supposed to be a customizable NAS, as I described it? Or am I completely lost? -- Joel Rees On Tue, Jan 6, 2015 at 10:53 AM, kinneko <kinn...@gmail.com> wrote: > Hi, all. > > I think, the hardware of GLANTANK is obsolete. > The useful life of this product was end. > XScale can't get support of Intel and no one maintains that. > > Intel XScale IOP Linux > http://xscaleiop.sourceforge.net/ > http://sourceforge.net/projects/xscaleiop/files/ > > MAKAI is unrelated to NAS and ARM. > MAKAI is self-rebuildable LiveCD project. > MAKAI supports x86, ONLY. > It's Minimal system and not include NAS manager. > > This problem seems to have 2 problems. > - XScale: The DMA function of XScale is not good. Intel failed to support it. > - Hard drive: There may be also a problem with function of a JBOD controller. > > > 2015-01-06 9:43 GMT+09:00 Joel Rees <joel.r...@gmail.com>: >> GLANTANK is a gigabit version of LANTANK. IO-DATA's child company >> Chousensha (Challenger) produced these in response to the Kurobako >> (with which some here may be familiar). >> >> http://ja.wikipedia.org/wiki/GLAN_Tank >> http://translate.google.co.jp/translate?hl=en&sl=ja&u=http://ja.wikipedia.org/wiki/GLAN_Tank&prev=search >> >> http://ja.wikipedia.org/wiki/LAN_Tank >> http://translate.google.co.jp/translate?hl=en&sl=ja&u=http://ja.wikipedia.org/wiki/GLAN_Tank&prev=search >> >> These are customizable NAS units, apparently running a customized >> debian (MAKAI -- MAKe Again ISO Image) internally. >> >> http://makai.sourceforge.jp/wiki/index.php?FrontPage >> http://translate.google.co.jp/translate?hl=en&sl=ja&u=http://ja.wikipedia.org/wiki/GLAN_Tank&prev=search >> >> LANTANK had an SH4 cpu, but the GLANTANK has an ARM (XScale). >> >> On Mon, Jan 5, 2015 at 9:22 AM, Jun Itou <itou_...@infoseek.jp> wrote: >>> I managed debian 7 by the following constitution. >>> >>> Body) I-O DATA GLANTANK 2.0TB (500GB * 4 RAID0, iop32x) >>> USB1) I-O DATA HDZ-UES 2.0TB (500GB * 4 JBOD) >>> USB2) I-O DATA HDZ-UES 1.0TB (250GB * 4 JBOD) >>> USB3) I-O DATA HDZ-UES 1.0TB (250GB * 4 JBOD) >>> USB4) I-O DATA HDW-UE 1.0TB (500GB * 2 JBOD) >>> >>> After making 7.7 from debian 7.6, malfunction occurred. >>> >>> 1) A sector error occurs when I do mount and becomes the lead only >>> 2) I fail in synchronization of the file system when I do fdisk >>> >>> I gave following tests to cut a problem into pieces. >>> >>> 1) I do operation same as GLANTANK in x64 environment whether it is a >>> problem of the hardware. >>> -> Because the same problem occurs with both, it is not peculiar to >>> hardware. >>> >>> 2) I confirm whether it is the problem of the HDD of USB1 - 4 with the >>> test tool of the HDD maker. >>> -> Because the HDD of all passed a test, it is not a problem of USB1 - >>> 4. >>> >>> 3) I do the same operation in Fedora whether it is a problem peculiar to >>> debian. >>> -> Because it reappeared in Fedora, I conclude it to be a problem of >>> kernel. >>> >>> 4) I change a version of kernel on debian and do the same operation. >>> -> 3.2.62 : It does not reappear >>> 3.2.63 ~ : Reappear >>> 3.18.0 ~ : Reappear >>> >>> 5) I report it to kernel.org and do the same operation after enforcement >>> in the end run which there was of the answer. >>> -> Please refer to https://bugzilla.kernel.org/show_bug.cgi?id=89511. >> >> The summary here is that the GLANTANK seems not to like the >> SYNCHRONIZE CACHE command. >> >> 話をまとめると GLANTANK が SYNCHRONIZE CACHE の命令に応じないようです。 >> >> https://bugzilla.kernel.org/show_bug.cgi?id=89511#c35 >> >> Alan Stern says that the kernel should be able to handle this in 3.18 >> or later, but Jun indicates that 3.18 does not handle it yet. >> >> スターン氏によると、カーネルの 3.18 なら対処できるであろう、ということでした。その反面、 JunItou の結果はそうではなかった。 >> >>> It is to say that my USB HDD cannot support the change of this journal >>> function in conclusion. >>> I make kernel latest or seem to but make a USB HDD a different one if I >>> continue managing it by the present constitution. >>> >>> I knew that it was not developed debian 8 for GLANTANK by a document. >>> Because there is no help for it, I think to manage it without formating >>> ext2, and using the journal function. >>> >>> ※In addition, one of file system is destroyed when an error happens as for >>> this malfunction even once. >>> I hope that it reappears and is not given a test with the contained HDD >>> of important data. >>> >>> ※Because the funny grammar is machine translation; a pardon >>> >>> That's all. >> >> I'm thinking that the best place to fix this would be in the MAKAI >> community, but, as I check back in the Japanese list from last month, >> it looks like Jun has already tried contacting them. And that >> community seems to be an abandoned sourceforge.jp project, completely >> untouched since 2010. And the Makai project doesn't seem to have a >> place to post bugs. >> >> https://lists.debian.org/debian-japanese/2014/12/msg00003.html >> >> 簡単に考えたら、 >> MAKAIのコミュニティに連絡した方が速い、かな？と思うけど、先月の日本のメールリスとを見直したら、もう、連絡されているのではないですか？それに、2010年からはプロジェクトが完全ほったらかしの様子ですね。さらに、バッグの窓口がなさそうです。 >> >> it appears that last month I seem to have found something that made it >> look to me like the once-maintainer of MAKAI, kin-neko, has >> more-or-less washed his hands of a ten-year-old project that never >> developed a self-sustaining community. I don't remember where I found >> that, however. >> >> 先月の投稿に、僕がどこかで見つけた情報のため、 MAKAI管理者の kinneko >> は十年前の世界の遺跡のように、手放しの姿勢となっているように思いました。コミュニティが成立できなかったためでしょう。ただし、その情報はどこで手に入れたかは覚えていません。 >> >> Anybody here in user, arm, or embedded (or d-japanese) have a suggestion? >> >> Joel Rees >> >> Be careful when you look at conspiracy. >> Look first in your own heart, >> and ask yourself if you are not your own worst enemy. >> Arm yourself with knowledge of yourself, as well. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iMTh6Nr7xCvWe3tB3uZb=4y3ol2b-ylmgo6rhxccqh...@mail.gmail.com
