Jan Kiszka wrote: > Karl Reichert wrote: > > Jan Kiszka wrote: > >> Karl Reichert wrote: > >>> Jan Kiszka wrote: > >>>> Karl Reichert wrote: > >>>>> Very good news: I found the reason for this behavoir/bug now! > >>>>> > >>>>> I'm using the attaced rtnet_start script to start the slave (can't > use > >>>> the provided one because I don't want RTcfg). > >>>>> The last command is 'tdmacfg rteth0 slot 0 2300 -s 100 -l rtnet.log' > >>>>> > >>>>> If I use this script as attached, I get this weird behavoir that the > >>>> slave request and calibration reply in a cycle from the past. > >>>>> If I comment this last comment and enter it manually on console > (after > >>>> sucessfull run of rtnet_start), everything works fine. Also a 'sleep > 3' > >>>> between the last command and the precending works fine. > >>>> > >>>> Private follow-up discussion revealed that this is most problably the > >>>> same issue as already described here: > >>>> > >>>> http://article.gmane.org/gmane.linux.real-time.rtnet.user/1891/ > >>>> > >>>> i.e. it is rt_e1000-specific. > >>> Seems like. I would suggest that I remove my wiki entry which said > >>> this is a tdmacfg issue and create a new which deals about rt_e1000. > >>> There I will describe the workaround so that other rt_e1000 users > won't > >>> face the same issues. > >> Ack. > > > > Please see http://www.xenomai.org/index.php/RTnet:rt_e1000 and edit if > needed. > > > >>> Do you agree? Or do you think this is sth that needs a change on > >>> rt_e1000 driver sourcecode? > >> Well, the ultimate and most comfortable solution would be inside the > >> driver - if nothing helps a delays before returning from the open > handler. > >> > >> Sigh, I just re-read my last mail on this issue > >> (http://thread.gmane.org/gmane.linux.real-time.rtnet.user/1891). > >> Obviously, nothing happened to this know issue for more than a year > now. > >> > >> OK, if this slow line setup of the [rt_]e1000 is a common issue, we > >> really need that msleep in the setup path, something like this: > >> > >> Index: drivers/e1000/e1000_main.c > >> =================================================================== > >> --- drivers/e1000/e1000_main.c (Revision 1136) > >> +++ drivers/e1000/e1000_main.c (Arbeitskopie) > >> @@ -1202,6 +1202,9 @@ e1000_open(struct rtnet_device *netdev) > >> e1000_check_mng_mode(&adapter->hw)) > >> e1000_get_hw_control(adapter); > >> > >> + /* Wait for the hardware to come up */ > >> + msleep(2000); > >> + > >> return E1000_SUCCESS; > >> > >> err_up: > >> > >> > >> Does it work for you (alternatively, using msleep(3000))? > >> > > > > msleep(2000) already works (no more sleep in startup script needed), but > I would suggest to use msleep(3000). I own two cards, one works with > msleep(2000), the other one needs msleep(3000). So it seems sleeping 2000 ms > is > very short, but stick to 3000 ms. > > I finally committed msleep(3000), will be part of next release (0.9.10).
Added this information to wiki page. > > > > If you add this patch to current RTnet version (SVN version), please > edit the created wiki page (mark as obsolete or sth similiar). Thanks! > > > Is this page already reference by some other page? I didn't find > anything. However, maybe we could create a "known issues (with/without > fixes)" out of it. No, it is not. I don't have a clue where I should link it. This known issue page ... could be a good idea. I guess you are thinking about a page with an overview to known issues/bugs and links to their workarounds?! I could create such, but what else known issues are out there? Is there any overview available? Karl -- von Karl Reichert Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ RTnet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-users
