<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: dswifi bug found and patched</title>
	<atom:link href="http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/</link>
	<description>Everything is hackable</description>
	<lastBuildDate>Sat, 04 Feb 2012 13:41:22 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Stephen</title>
		<link>http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/comment-page-1/#comment-2069</link>
		<dc:creator>Stephen</dc:creator>
		<pubDate>Fri, 10 Nov 2006 23:59:49 +0000</pubDate>
		<guid isPermaLink="false">http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/#comment-2069</guid>
		<description>Hi JT,
Oddly enough, some of this has already come up in discussion about the wifi library, so a while ago a DC_FlushAll() was added right after the 2 lines you mention.
I entirely hadn&#039;t considered that the buffer would be unaligned and the previous/next cache lines would pose a problem, but indeed they could. I&#039;ve now fixed this by adding padding to the start/end of the struct and the changes are in CVS now. (though, of note, cache lines are 32 bytes)
Thanks for your observations :)</description>
		<content:encoded><![CDATA[<p>Hi JT,<br />
Oddly enough, some of this has already come up in discussion about the wifi library, so a while ago a DC_FlushAll() was added right after the 2 lines you mention.<br />
I entirely hadn&#8217;t considered that the buffer would be unaligned and the previous/next cache lines would pose a problem, but indeed they could. I&#8217;ve now fixed this by adding padding to the start/end of the struct and the changes are in CVS now. (though, of note, cache lines are 32 bytes)<br />
Thanks for your observations :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JT</title>
		<link>http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/comment-page-1/#comment-2059</link>
		<dc:creator>JT</dc:creator>
		<pubDate>Fri, 10 Nov 2006 14:01:39 +0000</pubDate>
		<guid isPermaLink="false">http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/#comment-2059</guid>
		<description>Dude,
I think I found another little &quot;buglet&quot; that may cause some grief.

I&#039;ve been playing with the source to DSWifi and the Lib test demo you posted.

I was having some strange crashs / deadlock situations when the Arm7 &amp; 9 are trying to Sync after the call to Wifi_Init(int flags) on the arm9, I think I&#039;ve tracked it down to the following lines IN Wifi_Init()

erasemem(&amp;Wifi_Data_Struct,sizeof(Wifi_Data_Struct));

WifiData = (Wifi_MainStruct *) (((u32)&amp;Wifi_Data_Struct) &#124; 0x00400000); // should prevent the cache from eating us alive.

The problem (as I see it) is that although the erasemem function works ok, the result is still in the Arm9 cache and hasn&#039;t been written back to main memory yet, depending on the amount of data or operations kicking around this could be quite a while.  To fix this problem either move the erasemem call to AFTER the assignment of the WifiData pointer and pass that to erasemem OR fully flush the cache as the last line to erasemem - both seem to work.

I also suspect that as the cache lines are 64 bytes wide, ** potentially ** another problem could arise from a variable that happens to sit within either 64 bytes either side of Wifi_Data_Struct might also cause problems when it drops out of the cache - I&#039;d fix that by embedding Wifi_Data_Struct within another structure that&#039;s got at least 64bytes of padding on either side.

Hope this helps and keep up the good work!

JT.</description>
		<content:encoded><![CDATA[<p>Dude,<br />
I think I found another little &#8220;buglet&#8221; that may cause some grief.</p>
<p>I&#8217;ve been playing with the source to DSWifi and the Lib test demo you posted.</p>
<p>I was having some strange crashs / deadlock situations when the Arm7 &amp; 9 are trying to Sync after the call to Wifi_Init(int flags) on the arm9, I think I&#8217;ve tracked it down to the following lines IN Wifi_Init()</p>
<p>erasemem(&amp;Wifi_Data_Struct,sizeof(Wifi_Data_Struct));</p>
<p>WifiData = (Wifi_MainStruct *) (((u32)&amp;Wifi_Data_Struct) | 0&#215;00400000); // should prevent the cache from eating us alive.</p>
<p>The problem (as I see it) is that although the erasemem function works ok, the result is still in the Arm9 cache and hasn&#8217;t been written back to main memory yet, depending on the amount of data or operations kicking around this could be quite a while.  To fix this problem either move the erasemem call to AFTER the assignment of the WifiData pointer and pass that to erasemem OR fully flush the cache as the last line to erasemem &#8211; both seem to work.</p>
<p>I also suspect that as the cache lines are 64 bytes wide, ** potentially ** another problem could arise from a variable that happens to sit within either 64 bytes either side of Wifi_Data_Struct might also cause problems when it drops out of the cache &#8211; I&#8217;d fix that by embedding Wifi_Data_Struct within another structure that&#8217;s got at least 64bytes of padding on either side.</p>
<p>Hope this helps and keep up the good work!</p>
<p>JT.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gdpasmini</title>
		<link>http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/comment-page-1/#comment-1935</link>
		<dc:creator>gdpasmini</dc:creator>
		<pubDate>Mon, 30 Oct 2006 17:13:38 +0000</pubDate>
		<guid isPermaLink="false">http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/#comment-1935</guid>
		<description>Actually, i really don&#039;t know why that return NULL.. I hoped you would know ! ;-)

I have an other problem, i didn&#039;t succeed to remove  the traces. So i have all the time informations about packets sent and received...

Could you tell me how i could to remove it ?

Thank you !</description>
		<content:encoded><![CDATA[<p>Actually, i really don&#8217;t know why that return NULL.. I hoped you would know ! ;-)</p>
<p>I have an other problem, i didn&#8217;t succeed to remove  the traces. So i have all the time informations about packets sent and received&#8230;</p>
<p>Could you tell me how i could to remove it ?</p>
<p>Thank you !</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephen</title>
		<link>http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/comment-page-1/#comment-1895</link>
		<dc:creator>Stephen</dc:creator>
		<pubDate>Fri, 27 Oct 2006 19:21:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/#comment-1895</guid>
		<description>Twan: unfortunate :\ hopefully the next wifi lib will work better for you; there may be some small configuration thing causing problems but I don&#039;t have enough info to troubleshoot it.

gdpasmini: hiya; I have not encountered this problem, and I&#039;ve written some test code that pushes my malloc code pretty far. I would need more information to even have an idea of what&#039;s going wrong for you.</description>
		<content:encoded><![CDATA[<p>Twan: unfortunate :\ hopefully the next wifi lib will work better for you; there may be some small configuration thing causing problems but I don&#8217;t have enough info to troubleshoot it.</p>
<p>gdpasmini: hiya; I have not encountered this problem, and I&#8217;ve written some test code that pushes my malloc code pretty far. I would need more information to even have an idea of what&#8217;s going wrong for you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gdpasmini</title>
		<link>http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/comment-page-1/#comment-1888</link>
		<dc:creator>gdpasmini</dc:creator>
		<pubDate>Fri, 27 Oct 2006 16:19:47 +0000</pubDate>
		<guid isPermaLink="false">http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/#comment-1888</guid>
		<description>Hi !

Congratulation for the wifi lib ! But il tried to use your malloc code and i sometimes wHeapAlloc return NULL without any error...

Did you already see this bug ?</description>
		<content:encoded><![CDATA[<p>Hi !</p>
<p>Congratulation for the wifi lib ! But il tried to use your malloc code and i sometimes wHeapAlloc return NULL without any error&#8230;</p>
<p>Did you already see this bug ?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Twan</title>
		<link>http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/comment-page-1/#comment-1870</link>
		<dc:creator>Twan</dc:creator>
		<pubDate>Fri, 27 Oct 2006 09:42:23 +0000</pubDate>
		<guid isPermaLink="false">http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/#comment-1870</guid>
		<description>oh, but there I forgot to tell you something: Im using a DS Lite, but my sister has a normal DS and can connect with BeUP without problems. And she uses exactly the same wifi settings...</description>
		<content:encoded><![CDATA[<p>oh, but there I forgot to tell you something: Im using a DS Lite, but my sister has a normal DS and can connect with BeUP without problems. And she uses exactly the same wifi settings&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Twan</title>
		<link>http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/comment-page-1/#comment-1869</link>
		<dc:creator>Twan</dc:creator>
		<pubDate>Fri, 27 Oct 2006 09:31:59 +0000</pubDate>
		<guid isPermaLink="false">http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/#comment-1869</guid>
		<description>Well, that&#039;s still some good news, at last :p I&#039;ll be waiting for your next version then. Thanks for the info.</description>
		<content:encoded><![CDATA[<p>Well, that&#8217;s still some good news, at last :p I&#8217;ll be waiting for your next version then. Thanks for the info.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Stephen</title>
		<link>http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/comment-page-1/#comment-1868</link>
		<dc:creator>Stephen</dc:creator>
		<pubDate>Fri, 27 Oct 2006 08:13:59 +0000</pubDate>
		<guid isPermaLink="false">http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/#comment-1868</guid>
		<description>eli: unfortuantely the lack of ad-hoc mode in the recent versions has been due to the hardware making it very difficult to do ad-hoc; I have yet to find a good way to do it.

Twan: Hiya, unfortunately I can say with great certainty that this wasn&#039;t your problem; the bug I&#039;m speaking of only infrequently affects UDP communications, where BeUP uses TCP for it&#039;s communication, so it would be unaffected by this bug. There are a few inconsistencies that make certain types of wifi setups difficult to deal with in this version, but the next version will make a much greater effort to connect correctly in any situation.</description>
		<content:encoded><![CDATA[<p>eli: unfortuantely the lack of ad-hoc mode in the recent versions has been due to the hardware making it very difficult to do ad-hoc; I have yet to find a good way to do it.</p>
<p>Twan: Hiya, unfortunately I can say with great certainty that this wasn&#8217;t your problem; the bug I&#8217;m speaking of only infrequently affects UDP communications, where BeUP uses TCP for it&#8217;s communication, so it would be unaffected by this bug. There are a few inconsistencies that make certain types of wifi setups difficult to deal with in this version, but the next version will make a much greater effort to connect correctly in any situation.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Twan</title>
		<link>http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/comment-page-1/#comment-1864</link>
		<dc:creator>Twan</dc:creator>
		<pubDate>Thu, 26 Oct 2006 20:33:58 +0000</pubDate>
		<guid isPermaLink="false">http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/#comment-1864</guid>
		<description>Hi, although I don&#039;t understand everything you are talking about.. I am pretty sure I am 1 of the 30000 you mentioned.
I can&#039;t connect with the homebrew BeUP on my DS Lite. I&#039;ve been trough all forums and tips and finaly the creator of BeUP told me I might own one of the very few DS&#039;s thats not compataible with the SgStair&#039;s library. That lead me to you! So if I understand it right, the maker of BeUP will have to implement this update of yours in his program, and then it will work on my DS?</description>
		<content:encoded><![CDATA[<p>Hi, although I don&#8217;t understand everything you are talking about.. I am pretty sure I am 1 of the 30000 you mentioned.<br />
I can&#8217;t connect with the homebrew BeUP on my DS Lite. I&#8217;ve been trough all forums and tips and finaly the creator of BeUP told me I might own one of the very few DS&#8217;s thats not compataible with the SgStair&#8217;s library. That lead me to you! So if I understand it right, the maker of BeUP will have to implement this update of yours in his program, and then it will work on my DS?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: eli</title>
		<link>http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/comment-page-1/#comment-1863</link>
		<dc:creator>eli</dc:creator>
		<pubDate>Thu, 26 Oct 2006 20:21:40 +0000</pubDate>
		<guid isPermaLink="false">http://blog.akkit.org/2006/10/25/dswifi-bug-found-and-patched/#comment-1863</guid>
		<description>How big of a &lt;strike&gt;bribe&lt;/strike&gt; donation would it take for that decision to end up ad hoc mode?</description>
		<content:encoded><![CDATA[<p>How big of a <strike>bribe</strike> donation would it take for that decision to end up ad hoc mode?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

