On 06/29/2005 06:19 PM Wolfgang Grandegger wrote:
> On 06/29/2005 06:03 PM Jan Kiszka wrote:
>> Wolfgang Grandegger wrote:
>>>>
>>>>When did you last update your SVN checkout, i.e. which revision do you
>>>>use? Yesterday I fixed an ugly bug in the reception path that was
>>>>introduced after 0.8.2 release.
>>>
>>> Today at 16:14:
>>>
>>> /temp/rtai$ ls -ld trunk/
>>> drwxr-xr-x 4 wolf badboys 4096 Jun 29 16:14 trunk/
>>>
>>> ~$ dmesg|tail
>>> ...
>>> *** RTnet 0.8.3 - built on Jun 29 2005 17:00:29 ***
>>>
>>
>> Damn, would have been too easy. :)
>>
>>> I'm going to update to a more recent version of RTAI/fusion. What
>>> version do you recommend?
>>>
>>
>> I'm typically testing against CVS, but at least anything with a 0.8 in
>> front should not cause troubles by itself. 0.7.3 is really a bit
>> "out-of-date".
>>
>> But let's have a look at your kernel console again:
>>
>>> RTmac/TDMA: init time division multiple access control mechanism
>>> RTDM: registered named device TDMA0
>>> divert: not allocating divert_blk for non-ethernet device vnic0
>>> RTAI: RTAI: suspending kernel thread ce725380 ('ce725380') at 0xc013b117
>>> after exception #14
>>
>> Please identify which thread is being supended, i.e. which module owned
>> it. RTcfg? Maybe there is problem in the transmission path, maybe even
>> in your driver? ;) And try to find out which module/function is behind
>> the crash address.
>>
>>> vnic0: no IPv6 routers present
>>> RTnet: host 10.0.0.2 unreachable
>>> RTnet: host 10.0.0.2 unreachable
>>> divert: no divert_blk to free, vnic0 not ethernet
>>> RTAI: RTAI: suspending kernel thread e0ac5c40 ('e0ac5c40') at 0xc013b117
>>> after exception #13
>>
>> Same address here, looks like the same bug.
>
> I'm already investigating. Also the following command does not return:
>
> $ rtroute solicit 10.0.0.2 dev rteth0
>
> and it thoughs the above exception:
>
> /temp/rtai/fusion-0.7.3/include/nucleus/asm-i386$ cat /proc/rtai/sched
> CPU PID NAME PRI TIMEOUT STATUS
> 0 0 ROOT 0 0 0x00140080 - fpu
> 0 0 e0a07880 98 0 0x00000081 - ssp
> 0 0 e0a08240 1 0 0x00000082 - pnd
>
> Obviously the marked thread is making the trouble, which is started when
> rtnet.ko is loaded.
>
> Unfortunately, none of this is "my" software. I'm afraid, that the
> experimental driver 3c59x is the source of trouble.
>
> Wolfgang.
I was rigt, The problem is with "frags" in rt_3c59.c":
for (i = 0; i < skb_shinfo(skb)->nr_frags; i++) {
skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
vp->tx_ring[entry].frag[i+1].addr =
// *** RTnet: page mapping correct? Or is this code never used?
cpu_to_le32(pci_map_single(vp->pdev,
(void*)page_address(frag->page) +
frag->page_offset,
frag->size, PCI_DMA_TODEVICE));
What memory is actually used for the RTnet skb's?
Wolfgang.
>>
>> Jan
>>
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> RTnet-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/rtnet-users
>
>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
RTnet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rtnet-users
