Hi,
The driver initially did not compile as it didn't seem to be in sync with recent RTnet changes. The attached patch
fixes this. (Being mainly "rtos_irq_t irq_handle" related stuff, and change of the definition of the
interrupthandler signatures, "pci_*state*" functions.)
This patch enables me to compile the driver, load and configure it. As I didn't have a second PC around
to test it, the RTnet functionality is untested. I'm posting this patch as is - there's still some tracing
calls which should be removed. If you prefer to have it cleaned up a little, I'll do that.
The attached patch is a cleaner version of the previous one: I removed the tracing statements involving
success and only kept additional failure messages. The changes which weren't necessary for compilation
or loading are removed.
Thanks for all your patches! Will look over it and apply them soon.
Setting up the device works, but doing a rtping to the configured device results in:
RTnet: registered rteth0 RTnet: host 0.0.0.120 unreachable
Strange host address. Please check if your routing table is already corrupted before the first rtping call.
Unable to handle kernel NULL pointer dereference at virtual address 0000000c
printing eip:
c012b845
*pde = 00000000
Oops: 0002 [#2]
PREEMPT
Modules linked in: rt_3c59x tdma rtmac rtnet rtai_rtdm rtai_native rtai_nucleus rtai_hal adeos iptable_filter ip_tables i2c_i801 hw_random uhci_hcd evdev psmouse loop wacom snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd snd_page_alloc
CPU: 0
EIP: 0060:[<c012b845>] Not tainted VLI
EFLAGS: 00010246 (2.6.10-nyx)
EIP is at prepare_to_wait+0x35/0xc0
eax: 00000008 ebx: d4551eb4 ecx: 00000000 edx: d4551ec0
esi: d9441a98 edi: 00000001 ebp: d9441a80 esp: d4551e6c
ds: 007b es: 007b ss: 0068
Process rtping (pid: 12594, threadinfo=d4550000 task=c2cafa80)
Stack: d4550000 000001f4 d4551eb4 e0c01a79 e0c0f6c0 000000d0 c13fb580 b7f75000
d9441a98 d9441aa4 00000000 c2cafa80 c012ba40 d4551ec0 d4551ec0 00000001
d4550000 cfb5fb7c 00000000 c2cafa80 c012ba40 d4551ec0 d4551ec0 b7f754e0
Call Trace:
[<e0c01a79>] rtpc_dispatch_call+0x179/0x320 [rtnet]
[<c012ba40>] autoremove_wake_function+0x0/0x60
[<c012ba40>] autoremove_wake_function+0x0/0x60
[<c01d7ec2>] copy_from_user+0x42/0x70
[<e0c04a40>] ping_complete_handler+0x0/0x30 [rtnet]
[<e0c04b70>] ipv4_ioctl+0x100/0x1c0 [rtnet]
[<e0c049e0>] ping_handler+0x0/0x60 [rtnet]
[<e0c04a40>] ping_complete_handler+0x0/0x30 [rtnet]
[<c01d7ec2>] copy_from_user+0x42/0x70
[<c0119c68>] local_bh_enable+0x8/0xa0
[<e0c00ea2>] rtnet_ioctl+0x122/0x170 [rtnet]
[<c016a36a>] sys_ioctl+0xca/0x230
[<c0102a53>] syscall_call+0x7/0x14
Code: 24 04 89 c6 89 7c 24 08 89 cf 83 22 fe e8 14 09 00 00 89 c1 a1 f4 45 34 c0 39 05 f8 45 34 c0 74 7b 8d 53 0c 39 53 0c 75 0d 8b 06 <89> 50 04 89 43 0c 89 72 04 89 16 8b 43 04 85 c0 74 0b b8 00 e0
<6>note: rtping[12594] exited with preempt_count 2
scheduling while atomic: rtping/0x00000002/12594
[<c02f468c>] schedule+0x60c/0x620
[<c01433f3>] unmap_page_range+0x53/0x80
[<c01435e1>] unmap_vmas+0x1c1/0x1f0
[<c0148353>] exit_mmap+0x83/0x1a0
[<c011202f>] mmput+0x2f/0xd0
[<c01171c3>] do_exit+0x183/0x5f0
[<c010457f>] die+0x1df/0x1e0
[<c0114c37>] printk+0x17/0x20
[<c010e944>] do_page_fault+0x244/0x5de
[<c0207bc2>] scrup+0xf2/0x110
[<c012c03f>] __adeos_handle_event+0x9f/0x120
[<c010e700>] do_page_fault+0x0/0x5de
[<c0103cd7>] error_code+0x2b/0x38
[<c012b845>] prepare_to_wait+0x35/0xc0
[<e0c01a79>] rtpc_dispatch_call+0x179/0x320 [rtnet]
[<c012ba40>] autoremove_wake_function+0x0/0x60
[<c012ba40>] autoremove_wake_function+0x0/0x60
[<c01d7ec2>] copy_from_user+0x42/0x70
[<e0c04a40>] ping_complete_handler+0x0/0x30 [rtnet]
[<e0c04b70>] ipv4_ioctl+0x100/0x1c0 [rtnet]
[<e0c049e0>] ping_handler+0x0/0x60 [rtnet]
[<e0c04a40>] ping_complete_handler+0x0/0x30 [rtnet]
[<c01d7ec2>] copy_from_user+0x42/0x70
[<c0119c68>] local_bh_enable+0x8/0xa0
[<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.
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.
...
@@ -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).
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).
Jan
------------------------------------------------------- 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
