Hallo, There are a couple of problems and questions which I have while evaluating Vera's software and reading the Princeton papers. I appreciate advice. 1)I tested the software sgo on several machines. One persistent problem is that "sgo X.srec" could only execute once. The subsequent execution would lead to segmentation fault of sgo and the machine would normally freeze. If "sgo X.srec" is used, I got the following errors: +++runIXP1200:signal=0xffffffff expecting entry address(0xC1002000) +++IXP1200 is not a mem target on pri PCI and ...not a bus master on pri PCI. If "sgo -r X.srec" is used, more errors pop up: +++Unable to handle kernel NULL pointer dereference at virtual address 00000000 +++printing eip:00000000 +++*pde:00000000 +++Oops:00000000 +++CPU:0 +++EIP:0010:{<00000000>} +++Eflags:00010097 +++eax ffffe0c ebx:00027396 ecx:c02bb54e0 edx:0x1d +++esi:d1bfc960 edi:0x5622 ebp:c5479b38 esp:c5479b10 +++Process sgo (pid:1497, stackpage=c5479000) +++Call Trace.... +++Bad EIP +++hda:lost interrupt I tried resetting the board first, like using the minicom reset as well as the reset pins on the ixp before repeating the above commands. But I still have the same segmentation fault and bad EIP problem. 2)How does one create the vth0,.... device interface on Pentium as described in the paper ? Will the forwarder's admission control that runs on Pentium be included in future release ? 3)Say, I have a simple receiver and sender set-up 10.60.0.38--->[Port 1]Vera[Port 0]--->192.168.133.147 My routing cache's content is : {"10.60.0.38", "192.168.133.147", "00:80:C7:F6:3A:BB", "00:E0:29:00:8C:AE",0x00} "192.168.133.147", "10.60.0.38", "00:E0:29:00:8C:AE", "00:80:C7:F6:3A:BB",0x01} It seems that my ping packets got forwarded but the acknowledgement did not come back. Then, I used a traffic generator and it could be observed that IP packets get forwarded by IXP1200 as normal but did not get transmitted out of the port. The uengines were polling the sa queue. For each packet, they did the ipmm_packet_read:Reading 64 (out of 64) bytes...at say address 0x00284400 and ended with ipmm_packet_write to the same address 0x00284400. Also, packets could only be transmitted out at port 0 using the command keys at the minicom but not port 1. how could I make my ping work ? 4) Each port has 16 queues. How are they organized ? ie. starting from which address ? Thank You very much and kind regards, cheewei
On Thu, Jan 31, 2002 at 07:55:15PM +0800, Tan Chee Wei wrote:
There are a couple of problems and questions which I have while evaluating Vera's software and reading the Princeton papers. I appreciate advice. 1)I tested the software sgo on several machines. One persistent problem is that "sgo X.srec" could only execute once. The subsequent execution would lead to segmentation fault of sgo and the machine would normally freeze. If "sgo X.srec" is used, I got the following errors:
+++runIXP1200:signal=0xffffffff expecting entry address(0xC1002000) +++IXP1200 is not a mem target on pri PCI and ...not a bus master on pri PCI.
If "sgo -r X.srec" is used, more errors pop up:
+++Unable to handle kernel NULL pointer dereference at virtual address 00000000
Are you running pcirestore after you reset the board? The cycle should be: 1. Boot the entire system 2. Load the vera.o module 3. Run your code (sgo X.srec) 4. Reset the ixp1200 board - if your program returns to minimon you can use Ctrl-R - otherwise, use the reset pin 5. Run pcirestore 6. Go to step 3. When you load the vera.o module the first time, it records the settings of the PCI configuration registers on the IXP1200 board. Each time you reset the board, the board's configuration is lost and it will not respond to normal bus accesses. However, Linux is not aware of this and any attempt to access the board in an unconfigured state will hang or crash the system. The pcirestore command restores the saved settings to the values it recorded when the module was first loaded. Due to a known issue with the IXP1200, you cannot reliably reset the chip with a write to its reset register from the PCI bus. This is what the '-r' option to sgo tries to do. Some users have reported that it works, others report that it does not. My advice is to not use the '-r' option.
2)How does one create the vth0,.... device interface on Pentium as described in the paper? Will the forwarder's admission control that runs on Pentium be included in future release?
The released code doesn't create the vth devices. It's definitely on our "to do" list. We don't have an estimated release date at this time. Scott
Cheewei, 3) There are several possibilities: a) The ETHsrc and ETHdst entries in the cache refer to the addresses to be put on the packet. If the ETHdst address does not match the computer to receive the packet the ping might not be recorded. b) There might not be any microengines servicing the ports. What are the XMT_UE_BASE, XMT_CTX values in Libixprouter/common/src/config.h Note that the fact that for each packet the SA reads and writes the packet means that the microengines are missing in the cache. Are you really sure that the packets were forwarded? (Did you see them in a tcpdump on the receiving machine?) If you turn on debugging on the RCV and XMT microengines (change the value of the _DEBUG to 1 on the first line in rcv.uc, ipmm.uc, and xmt.uc) what do you see per packet? 4) I don't quite understand the question. It is possible to change the algorithm by which the transmit thread decides which queue to service, but by default the first queue with a packet in it is serviced. Is this what you meant? Or did you refer to the layout in memory? I hope this helps somewhat. More questions are always welcome. Zuki -- Yitzchak Gottlieb zuki@CS.Princeton.EDU On Thu, 31 Jan 2002, Tan Chee Wei wrote:
Hallo,
There are a couple of problems and questions which I have while evaluating Vera's software and reading the Princeton papers. I appreciate advice. <----- SNIP ------> 3)Say, I have a simple receiver and sender set-up 10.60.0.38--->[Port 1]Vera[Port 0]--->192.168.133.147
My routing cache's content is : {"10.60.0.38", "192.168.133.147", "00:80:C7:F6:3A:BB", "00:E0:29:00:8C:AE",0x00} "192.168.133.147", "10.60.0.38", "00:E0:29:00:8C:AE", "00:80:C7:F6:3A:BB",0x01}
It seems that my ping packets got forwarded but the acknowledgement did not come back. Then, I used a traffic generator and it could be observed that IP packets get forwarded by IXP1200 as normal but did not get transmitted out of the port. The uengines were polling the sa queue. For each packet, they did the ipmm_packet_read:Reading 64 (out of 64) bytes...at say address 0x00284400 and ended with ipmm_packet_write to the same address 0x00284400. Also, packets could only be transmitted out at port 0 using the command keys at the minicom but not port 1. how could I make my ping work ?
4) Each port has 16 queues. How are they organized ? ie. starting from which address ?
Thank You very much and kind regards, cheewei
participants (3)
-
Scott C. Karlin -
Tan Chee Wei -
Yitzchak M. Gottlieb