Hi Jan!
Jan Kiszka wrote:
Thanks for all your patches! Will look over it and apply them soon.
Thanks!
[<e0c00ea2>] rtnet_ioctl+0x122/0x170 [rtnet] [<c016a36a>] sys_ioctl+0xca/0x230 [<c0102a53>] syscall_call+0x7/0x14
Very strange. But before accusing the 3com driver, please also try if rtping on the rt_loopback device works - just to exclude that it's a fundamental problem with RTnet over fusion.
I remember that rtping on the rt_loopback device worked _before_ I pinged the rteth0. Afterwards it gave oopses.
Do you ping against an existing remote station or just for testing the xmit path? If the latter is true, a potential bug may reside in the xmit routine or the xmit irq of the 3c59x.
To the local IP address for testing the xmit path.
...
@@ -1158,7 +1163,7 @@
vp->rx_ring = pci_alloc_consistent(pdev, sizeof(struct boom_rx_desc) * RX_RING_SIZE
+ sizeof(struct boom_tx_desc) * TX_RING_SIZE,
&vp->rx_ring_dma);
- retval = -ENOMEM;
+ retval = -ENOMEM; // XXX: Is this supposed to happen? P.I.
if (vp->rx_ring == 0)
goto free_region;
BTW, this is a "typical" code pattern produced by someone with assembler knowledge. The compiler can easily translate it to:
... move -ENOMEM, <return-register> compare <vp->rx_ring>, 0 branch_if_zero free_region ...
In contrast to:
if (vp->rx_ring==0) { retval = -ENOMEM; goto free_region; }
which /may/ be translated to:
... compare <vp->rx_ring>, 0 branch_if_non_zero skip move -ENOMEM, <return-register> branch free_region skip: ...
For the first version, the processor will only have to leave the sequential code path if the seldom error actually occured. This can avoid branch predition misses (the CPU may assume the sequential path as more likely), and it improves the code locality for the typical case (less i-cache misses).
Ah! Thanks for the explanation!
This said, current gcc may already have built-in automatisms to detect that the second version may better be converted into the first one. Alternatively, you may put a "likely" or "unlikely" (kernel macros for gcc-specific attributes) in front of the if condition ("if (unlikely(xxx)) do_yyy;") helping to detect the typical case and even mark it in the machine code (at least for most RISC-archs, x86 to not support it).
Yes, I had seen these if(likely()...) and if(unlikely()...)'s before and I do prefer these -even though they are GCC specific- routines as they are clearer imho.
With friendly regards, Takis
-- K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group http://people.mech.kuleuven.ac.be/~pissaris/
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ RTnet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-users
