Question on setup ENP2505, urgent!
Hello, I got a ENP2505 board from my supervisor. He joined the intel IXA university program. But when I tried to setup this board according to the IXA Education Workstation Setup Guide, I always failed in Section 7. After I finished install software for ENP2505 and tried to boot the board using " ./bootixp " boot script, the board always entered a Cygmon environment and also I can not see the message "Finished ENP-2505 driver install" as mentioned in this guide. Then I tried to ping the board in another terminal window, it failed. I thought it's true. Because actually the Linux system do unknow the board currently. So, is there anybody know which options I should choose before I boot the enp2505 board. VxWorks, System Monitor or Cygnmon mode in this step? Do u know what's the problem? best, feng
Hi, When I type the command " get ixp1200 ixp1200.archive.0305 ", the system returns a message said, this command is successfully served, and a seperate message of this result is sent to me. But, even after a hour later, I can still not see any new message come from this server. Is there anybody know why? best, feng tang
I found the bootixp script to be incorrect when setting up the ENP2505 and ending up modifying it a bit so it would actually work. I have attached the version I use. Also, note that you need to be running the same kernel the pciDG modues were compiled with, else they will not load correctly (at least I have had issues in the past). Cy On Tue, 2003-05-13 at 10:22, feng wrote:
Hello, I got a ENP2505 board from my supervisor. He joined the intel IXA university program. But when I tried to setup this board according to the IXA Education Workstation Setup Guide, I always failed in Section 7. After I finished install software for ENP2505 and tried to boot the board using " ./bootixp " boot script, the board always entered a Cygmon environment and also I can not see the message "Finished ENP-2505 driver install" as mentioned in this guide. Then I tried to ping the board in another terminal window, it failed. I thought it's true. Because actually the Linux system do unknow the board currently. So, is there anybody know which options I should choose before I boot the enp2505 board. VxWorks, System Monitor or Cygnmon mode in this step? Do u know what's the problem? best, feng
Hi, I am trying to develop write a packet receive code for IXP1200. I am using a scheduler-worker paradigm to do the receive. i.e, my scheduler is in microengine 0 and one of its thread (thread 0) checks for availability of packet in any of the ports. I have 2 microengines doing the packet receive and so there are 8 threads for 8 ports, one thread per port. Two other microengines do the transmit (and one ue is free) Actually the code works for packets of length = 64 bytes. (i.e length of one chunk). But when the size of the packet increases, the data read from the FIFO is corrupt. I can give more details on this if anyone is interested. /* some of the details that could be of interest at this time: 1) I am not using autopush. My scheduler reads the rcv_rdy_lo register. 2) The scheduler constructs the rcv_req with the thread id responsible for that port. 3) The reading of rcv_cntl is done by the worker after it gets the start_receive signal 4) The worker read the packet and processes it. 5) The packet that gets corrupt is usually the first workd of the IP packet (version, etc) */ Thanks a lot. Jagan.
Hi Jagan, Have you handled the case that your scheduler thread (tid = 0 on ME 0) is not running so fast that it reads stale rcv-rdy bits? This is now a well documented architecture problem with slow ports on the IXP1200 and is explained in IXP1200 Programming book. (I wasted a hell lot of time debugging this one before it was discussed in the book). If that is the problem, try slowing down your code by adding delay loops in your scheduler thread. Your description that things work fine for 64 byte packets, but not for larger packets seem to indicate that this could be a problem. Assuming, the bulk of your processing code runs when an EOP mpacket is handled (once your entire packet is in the SDRAM), it is likely that things are fine for 64 byte packets, since every mpkt is an EOP, so you do enough processing before polling the rcv-rdy bits. However for larger packets, for SOP/MOP mpkts, the turnaround time could be small, and your sched. thread could be reading stale recv. ready bits. -- abhijeet On Thu, 22 May 2003, Jagannathan Iyer Venkatesan wrote:
Hi,
I am trying to develop write a packet receive code for IXP1200. I am using a scheduler-worker paradigm to do the receive. i.e, my scheduler is in microengine 0 and one of its thread (thread 0) checks for availability of packet in any of the ports. I have 2 microengines doing the packet receive and so there are 8 threads for 8 ports, one thread per port. Two other microengines do the transmit (and one ue is free)
Actually the code works for packets of length = 64 bytes. (i.e length of one chunk). But when the size of the packet increases, the data read from the FIFO is corrupt. I can give more details on this if anyone is interested.
/* some of the details that could be of interest at this time: 1) I am not using autopush. My scheduler reads the rcv_rdy_lo register. 2) The scheduler constructs the rcv_req with the thread id responsible for that port. 3) The reading of rcv_cntl is done by the worker after it gets the start_receive signal 4) The worker read the packet and processes it. 5) The packet that gets corrupt is usually the first workd of the IP packet (version, etc) */
Thanks a lot. Jagan.
Hi Abhijeet, Thanks for your email. I am aware of the problem you had talked about. In fact there is a delay that I have introduced in the scheduler whehever the scheduler reads the rcv-rdy bits. But again, there is a chance that the data transfer is slower than the delay I had introduced. I also tried another handshake method between the scheduler and worker using inter_thread signal. But with that model, my scheduler hangs for ever to get a signal from the worker. There is a race condition which I am hypothising on the basis of "missed" signal. The schduler does something like : ... write_receive_request() wait for interthread_signal() ... The worker does somethingg like : read_rv_cntl() signal(scheduler) read the data from the fifo() Now, the problem here is, apart from the scheduler and the worker, there is the hardware which singals the worker of the availability of the packet. Now, if the signal by the worker was sent before the scheduler can execute the ctx_arb [inter_thread], then I felt the singal is missed for good and the scheduler will wait for ever. Can you tell me if the concept of missed signal is valid ? Thanks. Jagan. On Thu, 22 May 2003, Abhijeet Joglekar wrote:
Hi Jagan,
Have you handled the case that your scheduler thread (tid = 0 on ME 0) is not running so fast that it reads stale rcv-rdy bits? This is now a well documented architecture problem with slow ports on the IXP1200 and is explained in IXP1200 Programming book. (I wasted a hell lot of time debugging this one before it was discussed in the book).
If that is the problem, try slowing down your code by adding delay loops in your scheduler thread.
Your description that things work fine for 64 byte packets, but not for larger packets seem to indicate that this could be a problem. Assuming, the bulk of your processing code runs when an EOP mpacket is handled (once your entire packet is in the SDRAM), it is likely that things are fine for 64 byte packets, since every mpkt is an EOP, so you do enough processing before polling the rcv-rdy bits. However for larger packets, for SOP/MOP mpkts, the turnaround time could be small, and your sched. thread could be reading stale recv. ready bits.
-- abhijeet
On Thu, 22 May 2003, Jagannathan Iyer Venkatesan wrote:
Hi,
I am trying to develop write a packet receive code for IXP1200. I am using a scheduler-worker paradigm to do the receive. i.e, my scheduler is in microengine 0 and one of its thread (thread 0) checks for availability of packet in any of the ports. I have 2 microengines doing the packet receive and so there are 8 threads for 8 ports, one thread per port. Two other microengines do the transmit (and one ue is free)
Actually the code works for packets of length = 64 bytes. (i.e length of one chunk). But when the size of the packet increases, the data read from the FIFO is corrupt. I can give more details on this if anyone is interested.
/* some of the details that could be of interest at this time: 1) I am not using autopush. My scheduler reads the rcv_rdy_lo register. 2) The scheduler constructs the rcv_req with the thread id responsible for that port. 3) The reading of rcv_cntl is done by the worker after it gets the start_receive signal 4) The worker read the packet and processes it. 5) The packet that gets corrupt is usually the first workd of the IP packet (version, etc) */
Thanks a lot. Jagan.
But again, there is a chance that the data transfer is slower than the delay I had introduced.
Just try playing with the delay value a little to see if that helps.
Now, the problem here is, apart from the scheduler and the worker, there is the hardware which singals the worker of the availability of the packet. Now, if the signal by the worker was sent before the scheduler can execute the ctx_arb [inter_thread], then I felt the singal is missed for good and the scheduler will wait for ever. Can you tell me if the concept of missed signal is valid ?
Yes, I think that there is a race condition here, as you described above, and the signal can be missed. However, even if the signal is not missed, this method still does not seem to guarantee that the rcv-rdy bits will not be stale. Note that there is still some delay between the worker thread reading the rcv_cntl register and signalling the scheduler to go ahead, and the FBI sampling the ports and refreshing the rcv_rdy bits. The FBI does not clear off the rcv_rdy bit after moving data from the port to the fifo, it overwrites it with the new bits when it samples the ports again. So, I think you just narrowed the window, but the bits could still be stale. So even with this handshake method, you would still need a delay loop before the scheduler reads the bits again (assuming the turnaround time is quick).
participants (5)
-
Abhijeet Joglekar -
Cyrus Hall -
feng -
Feng Tang
-
Jagannathan Iyer Venkatesan