Re: A USB HDD is trouble outbreak in debian7.7
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=ensl=jau=http://ja.wikipedia.org/wiki/GLAN_Tankprev=search http://ja.wikipedia.org/wiki/LAN_Tank http://translate.google.co.jp/translate?hl=ensl=jau=http://ja.wikipedia.org/wiki/GLAN_Tankprev=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=ensl=jau=http://ja.wikipedia.org/wiki/GLAN_Tankprev=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/msg3.html 簡単に考えたら、
Re: A USB HDD is trouble outbreak in debian7.7
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=ensl=jau=http://ja.wikipedia.org/wiki/GLAN_Tankprev=search http://ja.wikipedia.org/wiki/LAN_Tank http://translate.google.co.jp/translate?hl=ensl=jau=http://ja.wikipedia.org/wiki/GLAN_Tankprev=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=ensl=jau=http://ja.wikipedia.org/wiki/GLAN_Tankprev=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/msg3.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/CAAr43iOLR5ibR-VFQE4gx9afV3gWMm+kHT=suesylrvd1gm...@mail.gmail.com
Re: A USB HDD is trouble outbreak in debian7.7
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=ensl=jau=http://ja.wikipedia.org/wiki/GLAN_Tankprev=search http://ja.wikipedia.org/wiki/LAN_Tank http://translate.google.co.jp/translate?hl=ensl=jau=http://ja.wikipedia.org/wiki/GLAN_Tankprev=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=ensl=jau=http://ja.wikipedia.org/wiki/GLAN_Tankprev=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/msg3.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管理者の
A USB HDD is trouble outbreak in debian7.7
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. 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. -- 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/blu436-smtp175514212f285f17ac4c90f1...@phx.gbl
