Open jyizheng opened 9 years ago
@jyizheng I can't reproduce the travis CI issue, which said the followings.
https://travis-ci.org/libos-nuse/net-next-nuse/builds/68581850#L2497
type = 0
failed to get interface status
ioctl: No such device
err ioctl for assign address venet0 for link -22
ioctl: No such device
err ioctl for assign netmask 255.255.255.0 for link -99
Segmentation fault
/bin/ls: cannot access /tmp/rump-server-nuse.*: No such file or directory
chmod: cannot access `/tmp/rump-server-nuse.': No such file or directory
The command "./tools/testing/libos/nuse-test.sh" exited with 1.
mine is Fedora 21 x86_64. It only happened with optimized build (default one, OPT=yes).
could you please let me know the stack trace obtained by gdb ?
sudo gdb -c core /bin/ping then backtrace
on the gdb prompt ?
First of all, I need to confirm whether I have set the nuse.conf file correctly. "ifconfig" result of my machine is below.
yjiao@rowlf:/home/yjiao/net-next-nuse/arch/lib/tools$ ifconfig
eth0 Link encap:Ethernet HWaddr bc:ae:c5:6b:49:91
inet addr:130.245.153.8 Bcast:130.245.153.255 Mask:255.255.255.0
inet6 addr: fe80::beae:c5ff:fe6b:4991/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:803144 errors:0 dropped:0 overruns:0 frame:0
TX packets:357246 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1015243408 (1.0 GB) TX bytes:26940095 (26.9 MB)
eth0:0 Link encap:Ethernet HWaddr bc:ae:c5:6b:49:91
inet addr:192.168.99.200 Bcast:192.168.99.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:15236 errors:0 dropped:0 overruns:0 frame:0
TX packets:15236 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4709575 (4.7 MB) TX bytes:4709575 (4.7 MB)
"route -n":
yjiao@rowlf:/home/yjiao/net-next-nuse/arch/lib/tools$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 130.245.153.1 0.0.0.0 UG 0 0 0 eth0 130.245.153.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0 192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
My nuse.conf file looks like this: 1 interface eth0 2 address 130.245.153.8 3 netmask 255.255.255.0 4 # if macaddr is not specified, random mac addr is used. 5 viftype TAP 6 7 #interface p1p1 8 # address 172.16.0.1 9 # netmask 255.255.255.0 10 # macaddr 00:01:01:01:01:01 11 # if viftype is not specified, defualt raw socket is used. 12 13 #route 14 # network 130.245.153.0 15 # netmask 255.255.255.0 16 # gateway 130.245.153.1 17 18 route 19 network 0.0.0.0 20 netmask 0.0.0.0 21 gateway 130.245.153.1
With this configuration file, I cannot run "ping google", for which the terminal got stuck without return with message below: tap_alloc: alloc tap interface nuse-eth0 mac address for eth0 is randomized 02:00:e0:c4:05:5c nuse syscall proxy start at unix:///tmp/rump-server-nuse.28764 PING 130.245.153.1 (130.245.153.1) 56(84) bytes of data.
>5 viftype TAP
This line should be viftype RAW
to ping www.google.com.
viftype TAP is to join existing bridge interface.
Is it possible for you to log on my machine to diagnose the problem? I can create an account for you on my machine.
On Mon, Jun 29, 2015 at 1:48 PM, Hajime Tazaki notifications@github.com wrote:
5 viftype TAP
This line should be viftype RAW to ping www.google.com. viftype TAP is to join existing bridge interface.
— Reply to this email directly or view it on GitHub https://github.com/libos-nuse/net-next-nuse/pull/47#issuecomment-116773777 .
before creating an account for me, please check the followings:
ulimit -c unlimited
Cannot pass the test due to things related to "rumpns_oom_lock".
Cannot pass the test due to things related to "rumpns_oom_lock".
@jyizheng 'rumpns_' is a prefix introduced by recently. See 751adb6cd217bca14d4ec93d2a686c771ab89ffd commit.
it basically says the symbol 'oom_lock' is not included though it's referred by someone. maybe adding mm/oom_kill.o into your arch/lib/Makefile would be the first step.
I see. page_alloc.c is using oom_lock now. I will try to fix it.
On Tue, Sep 1, 2015 at 7:38 PM, Hajime Tazaki notifications@github.com wrote:
Cannot pass the test due to things related to "rumpns_oom_lock".
@jyizheng https://github.com/jyizheng 'rumpns_' is a prefix introduced by recently. See 751adb6 https://github.com/libos-nuse/net-next-nuse/commit/751adb6cd217bca14d4ec93d2a686c771ab89ffd commit.
it basically says the symbol 'oom_lock' is not included though it's referred by someone. maybe adding mm/oom_kill.o into your arch/lib/Makefile would be the first step.
— Reply to this email directly or view it on GitHub https://github.com/libos-nuse/net-next-nuse/pull/47#issuecomment-136892485 .
I still have the problem below.
The command "make clean ARCH=lib V=1 && make library ARCH=lib OPT=no V=1" exited with 0.
$ ./tools/testing/libos/nuse-test.sh
ping: symbol lookup error: ../../../liblinux.so: undefined symbol: rumpns__end
The command "./tools/testing/libos/nuse-test.sh" exited with 127.
On Tue, Sep 1, 2015 at 9:52 PM, Andy Joe jyizheng@gmail.com wrote:
I see. page_alloc.c is using oom_lock now. I will try to fix it.
On Tue, Sep 1, 2015 at 7:38 PM, Hajime Tazaki notifications@github.com wrote:
Cannot pass the test due to things related to "rumpns_oom_lock".
@jyizheng https://github.com/jyizheng 'rumpns_' is a prefix introduced by recently. See 751adb6 https://github.com/libos-nuse/net-next-nuse/commit/751adb6cd217bca14d4ec93d2a686c771ab89ffd commit.
it basically says the symbol 'oom_lock' is not included though it's referred by someone. maybe adding mm/oom_kill.o into your arch/lib/Makefile would be the first step.
— Reply to this email directly or view it on GitHub https://github.com/libos-nuse/net-next-nuse/pull/47#issuecomment-136892485 .
I still have the problem below. (snip) $ ./tools/testing/libos/nuse-test.sh
ping: symbol lookup error: ../../../liblinux.so: undefined symbol: rumpns__end
I fixed this issue (359e2da2d7913513f08abb8cc247c8a73c62c9ee). please pull the latest net-next-nuse/master to your branch. you may face another unresolved symbol 'smp_store_mb' which you may need to fix it in your branch.
Finally passed!
@jyizheng I put review comments on your patch. please take a look at and apply them if it's fine.
@jyIzheng thanks for the update. I put comments again to your files.
I think we need a couple of rounds to clean up more. for your particular pull request,
I briefly memorized the general guideline for a pull request for this project.
https://github.com/libos-nuse/net-next-nuse/wiki/Pull-request-guideline
thank you for your time.
@jyizheng I've commented on your patch.
I would remind the followings again: please update them as well.
- change PR's title in order to understand what this patch does,
- close unneeded PR (#45,#46).
Updated my code again and renamed the pull request and deleted the old ones.
thanks @jyizheng, I've tried to play locally with your patch. I was wondering what is the expected behavior with this ? can we have any specifics from an execution ? (I meant I'd like to add a test, like in tools/testing/libos/nuse-test.sh for instance to ensure this feature is working or not.)
I agree. I think I can write a test case that calling APIs in page_alloc.c directly for memory allocation and then do some arithmetic operation. Is this good enough?
On Tue, Sep 8, 2015 at 1:05 AM, Hajime Tazaki notifications@github.com wrote:
thanks @jyizheng https://github.com/jyizheng, I've tried to play locally with your patch. I was wondering what is the expected behavior with this ? can we have any specifics from an execution ? (I meant I'd like to add a test, like in tools/testing/libos/nuse-test.sh for instance to ensure this feature is working or not.)
— Reply to this email directly or view it on GitHub https://github.com/libos-nuse/net-next-nuse/pull/47#issuecomment-138435711 .
I agree. I think I can write a test case that calling APIs in page_alloc.c directly for memory allocation and then do some arithmetic operation. Is this good enough?
Great !
Where do you want me to add the test? I don't have the scripts for testing.
Best, Yizheng
On Wed, Sep 9, 2015 at 10:44 AM, Hajime Tazaki notifications@github.com wrote:
I agree. I think I can write a test case that calling APIs in page_alloc.c directly for memory allocation and then do some arithmetic operation. Is this good enough?
Great !
— Reply to this email directly or view it on GitHub https://github.com/libos-nuse/net-next-nuse/pull/47#issuecomment-138933419 .
What about creating a program in tools/testing/libos and calling from nuse-test.sh ?