| --- Log opened Fri Jan 17 00:00:57 2014 | ||
| olofk_ | Linkedin recommended me to join the group "Interior Design Professionals". They apparently have more confidence in my skills than my girlfriend has :) | 06:27 |
|---|---|---|
| olofk_ | oh.. or perhaps the mean I should join the group to learn a few things :( | 06:28 |
| stekern | haha | 06:33 |
| stekern | for some reason, my wife was logged in as me on youtube, so now it suggests all sorts of odd things for me to watch... | 06:35 |
| olofk_ | I'm not using youtube that much, so after I watched a demo of the Jolla phone in Finnish a while ago I'm only getting suggestions from Google for Finnish stuff (haven't got a clue what it's about, guessing ice hockey) | 07:05 |
| blueCmd_ | olofk: try www.google.com/ads/preferences | 08:39 |
| blueCmd_ | it usually tells you who it thinks you are | 08:39 |
| jonibo | stekern: the "generic" syscall stuff should all be in uClibc... but openrisc hasn't been adapted to it yet | 09:34 |
| jonibo | vfork should not be needed... bug if it is as it's behind a DEPRECATED define in the kernel header | 09:34 |
| jonibo | while you're at it, can you make the syscall interface in the openrisc port clobber "memory"...? | 09:34 |
| jonibo | i'm seeing strange behaviour on syscall return where the arg registers are being handled as call-saved... at least it appears that way, but I wonder if it's not just a matter of addnig the "memory" clobber | 09:35 |
| jonibo | i need to push my syscall handling rework to you for testing, since you seem to be looking at the linux code far more than me these days... sigh, need more time | 09:36 |
| jonibo | anyway, it would be good if you (or anybody) could finish off moving uClibc to the generic syscalls so that we can drop supporting the legacy syscalls from our tree... they're not upstream so it's just an annoying diff that causes confusion | 09:42 |
| jonibo | from the Linux kernel tree, I mean | 09:42 |
| jonibo | anyway, did I ansewr your question? | 09:43 |
| stekern | jonibo: yes, and I think most became clear already yesterday, I posted this: http://lists.uclibc.org/pipermail/uclibc/2014-January/048184.html | 09:51 |
| stekern | I'll take a look at the memory clobber | 09:52 |
| stekern | but what I'm really doing is that I've undertaken a "small" hobbyproject of writing a Linux port to a cpu called eco32 from scratch | 09:53 |
| jonibo | thanks for posting that patch | 09:54 |
| jonibo | yeah, I heard about your eco32 port... awesome | 09:54 |
| jonibo | glad you're using openrisc as a template and happy if you can fix up some openrisc cruft along the way | 09:55 |
| stekern | I'm using the openrisc port a lot as reference though, so anything I found that doesn't seem right I step into openrisc mode and look it up ;) | 09:55 |
| jonibo | i know upstream Linux wants more "generic" arch code so anything you find that looks essentially the same across a bunch of archs is a candidate for moving to generic headers/libs | 09:56 |
| stekern | right | 09:57 |
| jonibo | and if you figure out how memblock is supposed to work in place of bootmem, let me know... we need to move openrisc to memblock but I don't quite grok the interface... bootmem is deprecated | 09:59 |
| maxpaln | trying to debug a basic ethernet issue - the Linux kernel won't respond to pings | 09:59 |
| maxpaln | from the Linux kernel I can ping a machine connected directly via cross over cable | 10:00 |
| maxpaln | I don't get a response but I can see the Rx packet count increasing on the machine being pinged as the pings are sent | 10:01 |
| maxpaln | using ifconfig I can see the Tx and Rx packet counters increasing on the ORSOC board as well | 10:02 |
| maxpaln | But Ping just responds with 0 packets received (on the ORSOC board) | 10:03 |
| stekern | jonibo: sure, I'll take a look at that too | 10:03 |
| maxpaln | I haven't completely ruled out that there maybe a HW problem but the fact that packets are Tx'ing and Rx'ing is giving me confidence. I am currently thinking this is a Linux issue | 10:03 |
| maxpaln | hmmm, odd - I am not seeing any of my posts appear in the stream | 10:08 |
| maxpaln | ah. that one appeared! | 10:08 |
| maxpaln | I was trying to say "/proc/sys/net/ipv4/icmp_echo_ignore_all" is set to 0 | 10:08 |
| stekern | maxpaln: you quit/joined a couple of times there, network issues perhaps | 10:08 |
| maxpaln | yeah, maybe | 10:08 |
| maxpaln | The IP addresses look correct to me (not an expert but I think they *should* be able to talk to one another | 10:09 |
| maxpaln | The ORSOC board can ping it's own address (192.168.1.100) | 10:15 |
| maxpaln | and the loopback address (127.0.0.1 | 10:15 |
| stekern | have you tried inspecting the traffic with wireshark or similar? | 10:15 |
| maxpaln | nope - not used wireshark before | 10:16 |
| maxpaln | let me look into it | 10:16 |
| maxpaln | ok, so I can see thee ping requests arriving from the ORSOC board | 10:30 |
| maxpaln | I can't see a way to repeat that test on the ORSOC board though | 10:30 |
| _franck_web_ | can you see the ARP reply from your machine ? | 10:35 |
| _franck_web_ | I mean ICMP (ping) reply | 10:35 |
| jonibo | maxpain: this is a longshot, especially since things seem to work for you with pings arriving from the board, but do you have the WISHBONE_BUS_BIG_ENDIAN (something like that) config option set in your kernel config? upstream kernel is missing this altogether and probably won't work... are you using kerne lfrom openrisc.net? | 10:35 |
| maxpaln | ok, two questions - | 10:36 |
| maxpaln | jonibo: will check - I am using the openrisc kernel (can't remember the link) | 10:36 |
| _franck_web_ | maxpaln: of course you can see it because you RX count increments | 10:37 |
| jonibo | kernel from openrisc.net should work... | 10:37 |
| jonibo | upstream kernel driver for ethernet mac is missing endianess fix | 10:37 |
| jonibo | but like I said, if you can see packets going out then it's probably fine... i'm just guess here | 10:38 |
| maxpaln | _franck_web_: On my PC (which is a Windows-7 laptop) I can see the Rx packet count increasing with each ping sent from the ORSOC board | 10:39 |
| maxpaln | unfortunately, on the ORSOC board the Rx packet count increases regardless of what is happening on the Windows machine - I am guessing windows is constantly sending traffic out over the link to assess the network etc. | 10:39 |
| maxpaln | so it is difficult to say for certain that the ORSOC board is 'receiving' any ping packets | 10:40 |
| maxpaln | jonibo: cat marvell_phy_and_spi.config | grep ENDIAN | 10:41 |
| maxpaln | CONFIG_WISHBONE_BUS_BIG_ENDIAN=y | 10:41 |
| _franck_web_ | in wireshark, you should see ping reply after you received ping request | 10:41 |
| jonibo | ok, and your drivers/net/ethernet/ethoc.c uses that config option? | 10:42 |
| jonibo | ethoc.c, not sure path is correct there | 10:42 |
| jonibo | if yes, you're fine | 10:42 |
| maxpaln | jonibo: there are several #ifdef CONFIG_WISHBONE_BUS_BIG_ENDIAN in ethoc.c (you had the path right) | 10:43 |
| jonibo | ok, perfect | 10:43 |
| _franck_web_ | maxpaln: in wireshark/filter type: "icmp || arp" and apply | 10:44 |
| _franck_web_ | you should see arp and ping request reply | 10:44 |
| maxpaln | _franck_web_: checking that now | 10:45 |
| maxpaln | ok, gettting somewhere | 10:47 |
| maxpaln | so the request comes through (fromt he ORSOC board) but no reply is sent | 10:48 |
| maxpaln | repeating the same test using another laptop (windows XP) with the IP address configured the same yields the expected reply after the request | 10:49 |
| maxpaln | I shoudl say the XP laptop replaces the ORSOC board | 10:50 |
| maxpaln | also, very interesting - once I plug in the ORSOC board Wireshark shows a steady stream of ARPs with the destination of Braodcast requesting "WHo is 192.168.1.254" | 10:51 |
| maxpaln | going to recheck IP settings on the ORSOC board | 10:52 |
| _franck_web_ | you should inspect the ping request content | 10:54 |
| maxpaln | ok, [should highlight that I'm not an expert here!] | 10:55 |
| _franck_web_ | look at mac addresses | 10:56 |
| maxpaln | I was just checking those | 10:56 |
| _franck_web_ | and IPs | 10:56 |
| maxpaln | well, the MAC addresses and IP addresses for the destination and source look correct | 10:57 |
| maxpaln | but Wireshark is telling me that the 'Header checksum' is incorrect | 10:57 |
| maxpaln | not really sure if that would prevent the reply though | 10:58 |
| _franck_web_ | well I thin k that would | 10:59 |
| maxpaln | ok, I trust you :-) | 11:00 |
| _franck_web_ | you could save the wireshark log session and share it | 11:01 |
| _franck_web_ | I can take a look | 11:02 |
| maxpaln | good suggestion | 11:02 |
| maxpaln | ok, you should be able to get it here | 11:05 |
| maxpaln | https://www.dropbox.com/s/0zmvim6yhtph44a/wireshark_log.pcapng | 11:05 |
| _franck_web_ | the CRC problem is definitely bad | 11:10 |
| _franck_web_ | plus I can't see ARP reply | 11:11 |
| _franck_web_ | you should put your board the same ip mask: 192.168.254.x | 11:12 |
| maxpaln | everything is at 192.168.1.X at the moment | 11:12 |
| _franck_web_ | ah ok, so the ARP request is not coming from the ping | 11:13 |
| _franck_web_ | at some point you should have "Who has 192.168.1.81? Tell 192.168.1.100" | 11:14 |
| maxpaln | ok | 11:15 |
| _franck_web_ | and then Dell_38... is at 192.168.1.81 | 11:15 |
| maxpaln | the IP address of the ORSOC is the defaul at the moment - I am just setting to static with equivalent values | 11:15 |
| _franck_web_ | do you have "arp" command on your board ? | 11:16 |
| maxpaln | good question - you're going to ask one I know the answer to soon :-) | 11:17 |
| maxpaln | # arp | 11:17 |
| maxpaln | ? (192.168.1.81) at <incomplete> on eth0 | 11:17 |
| _franck_web_ | (anyway, the ARP is not the problem since your ping has correct MACs) | 11:18 |
| _franck_web_ | <incomplete> ? | 11:18 |
| maxpaln | ok, so now I've set the ip address statically | 11:19 |
| maxpaln | each ping request is followed by an ARP request "who has 192.168.1.254? tell 192.168.1.81" | 11:20 |
| maxpaln | and arp now returns | 11:20 |
| maxpaln | # arp | 11:21 |
| maxpaln | ? (192.168.1.81) at 5c:26:0a:38:57:d2 [ether] on eth0 | 11:21 |
| blueCmd_ | 192.168.1.254 sounds like it's trying to route something | 11:21 |
| _franck_web_ | lunch time | 11:22 |
| maxpaln | <agreed - well, elevenses here but still agreed> | 11:22 |
| maxpaln | once last thing - here is the static IP details | 11:22 |
| maxpaln | # cat /etc/network/interfaces | 11:22 |
| maxpaln | auto lo | 11:22 |
| maxpaln | iface lo inet loopback | 11:22 |
| maxpaln | auto eth0 | 11:22 |
| maxpaln | #iface eth0 inet dhcp | 11:22 |
| maxpaln | iface eth0 inet static | 11:22 |
| maxpaln | address 192.168.1.101 | 11:22 |
| maxpaln | network 192.168.1.0 | 11:22 |
| maxpaln | netmask 255.255.255.0 | 11:22 |
| maxpaln | broadcast 192.168.1.255 | 11:22 |
| maxpaln | gateway 192.168.1.1 | 11:22 |
| maxpaln | (in case I have made a mistake) | 11:22 |
| blueCmd_ | hah, you should use paste.se or something | 11:22 |
| blueCmd_ | can you paste output of 'ip ro' ? | 11:23 |
| maxpaln | ah, yeah - I was shown that yesterday (probably by _frank_web_ - very cool, must use more often!) | 11:23 |
| blueCmd_ | also 'ip ro get <the other ip>' | 11:23 |
| maxpaln | only 3 lines - will paste straight here: | 11:23 |
| maxpaln | # ip ro | 11:23 |
| maxpaln | default via 192.168.1.1 dev eth0 | 11:23 |
| maxpaln | 192.168.1.0/24 dev eth0 src 192.168.1.100 | 11:23 |
| maxpaln | # ip ro get 192.168.1.81 | 11:24 |
| maxpaln | 192.168.1.81 dev eth0 src 192.168.1.100 | 11:24 |
| maxpaln | interestingly, when I set the static IP I changed the address of the ORSOC board to 192.168.1.101 - but the two pastes above reference 192.168.1.100! | 11:26 |
| maxpaln | nothing is at .100 now | 11:26 |
| maxpaln | hmmm, none of this really explains why the packets have incorrect header checksum! | 11:28 |
| maxpaln | time for a cuppa - be back in 5 | 11:28 |
| blueCmd_ | checksums can be offloaded so don't assume that's a problem | 11:28 |
| maxpaln | ok, back in the room | 11:34 |
| maxpaln | understood re checksums - will mark that for follow-up | 11:34 |
| maxpaln | ok, so after each ping request I can see an ARP from the PC to find out "Who has" the default gateway address | 11:44 |
| maxpaln | I guess this means that the PC doesn't know how to find the ORSOC board | 11:44 |
| maxpaln | there is no router - laptop and ORSOC board are connected directly via crossover cable | 11:45 |
| blueCmd_ | maxpaln: you have to desribe your setup better. what is the configuration on your computer which I assume you are trying to ping from the board? | 11:47 |
| maxpaln | ok, no worries | 11:48 |
| maxpaln | by configuration do you mean IP address config? | 11:48 |
| blueCmd_ | yes | 11:48 |
| blueCmd_ | idealy "ip ro" output of both machines | 11:48 |
| maxpaln | ok, here is the paste from the ipconfig output for the Local Area Connection | 11:49 |
| maxpaln | http://pastie.org/8642006 | 11:49 |
| blueCmd_ | is that your ONLY connection? | 11:49 |
| maxpaln | there are plenty of connections from the ipconfig output - I'll paste them all | 11:49 |
| blueCmd_ | thanks | 11:50 |
| maxpaln | http://pastie.org/8642009 | 11:50 |
| blueCmd_ | yes so that's your problem | 11:50 |
| maxpaln | ah, ok | 11:50 |
| blueCmd_ | you are using the same network for both connections | 11:50 |
| blueCmd_ | so when the packet arrives to your computer it does not know where to send it | 11:51 |
| blueCmd_ | it will probably default to send the answer out on your wifi | 11:51 |
| maxpaln | but if I disable the wifi the problem still exists | 11:51 |
| blueCmd_ | but ARP are link local so that is still correct | 11:51 |
| blueCmd_ | just change the network to 192.168.2.100 and 192.168.2.101 | 11:51 |
| maxpaln | ok, will give it a go | 11:51 |
| blueCmd_ | 100 for your computer and 101 for the board for example | 11:51 |
| maxpaln | no worries | 11:52 |
| maxpaln | ok, so now my limited understanding of netmasks means I am not confident that I have set the IP addresses correctly! [rubbish I know - really should have more attention at uni] | 12:00 |
| maxpaln | here are the settings on the ORSOC board: | 12:01 |
| maxpaln | http://pastie.org/8642031 | 12:01 |
| maxpaln | similarly for the PC: | 12:02 |
| maxpaln | http://pastie.org/8642032 | 12:02 |
| maxpaln | These look correct to me - but ping still doesn't work | 12:02 |
| maxpaln | but I am no longer seeing the ARP requests for 'who has 192.168.1.1' - so perhaps we are one step closer! | 12:03 |
| jonibo | your broadcast address should be 192.168.3.255... but that's certainly not your problem | 12:14 |
| jonibo | you had several NIC's on your PC? what addresses/netmasks are set for hte other NICs? | 12:15 |
| maxpaln | updated paste of the ipconfig /all output here: | 12:16 |
| maxpaln | http://pastie.org/8642067 | 12:16 |
| jonibo | i'm not familiar with the "network" field that you're setting on the Linux side, but it doesn't match the netmask you're setting | 12:16 |
| jonibo | ok, you have overlapping network between the NIC and wifi | 12:18 |
| maxpaln | ah, of course | 12:18 |
| maxpaln | netmask should be .253.0 | 12:18 |
| maxpaln | (I think) | 12:18 |
| jonibo | why not make life easy for yourself and use 255.255.255.0 everywhere? | 12:18 |
| jonibo | netmask should be .254.0... | 12:18 |
| jonibo | but .255.0 _everywhere_ is problably the way to go | 12:19 |
| maxpaln | really? now I know I don't understand this - | 12:19 |
| maxpaln | :-) | 12:19 |
| maxpaln | the Wifi uses 192.168.1.X | 12:19 |
| maxpaln | so I shifted the LAN to 192.168.2.X - | 12:20 |
| jonibo | but you set LAN network size to 22 bits and wifi net to 24 bits | 12:20 |
| jonibo | if you set LAN netmask to 255.255.255.0 then you'll actually have separate networks | 12:20 |
| maxpaln | yep - you've just confirmed it, I REALLY don't understand how that works (what is it they say about a little knowledge...) | 12:21 |
| maxpaln | so I am going to trust you :-) | 12:21 |
| maxpaln | and do some reading offline | 12:21 |
| maxpaln | ok, I have set the netmask to 255.255.255.0 on both PC and board and set IP addresses to 192.168.2.100 and .101 on PC and board respectively | 12:27 |
| maxpaln | and now I can see the ping request on the PC | 12:28 |
| maxpaln | I can see thw ARP for "who has 192.168.2.101" from the PC | 12:28 |
| maxpaln | and I can (for the first time) see the board respond with an ARP to say that 192.168.2.101 is at <MAC address> | 12:29 |
| maxpaln | this is progress - but still no Ping reply! | 12:29 |
| jonibo | ping from PC to board of board to PC? | 12:30 |
| jonibo | neither works? | 12:30 |
| maxpaln | correct - neither works | 12:30 |
| maxpaln | I get more useful info from board to PC - because I can use Wireshark (thanks _franck_web_) to view the packets | 12:31 |
| jonibo | your sniffing the PC side... do you see the ping request coming in? | 12:32 |
| maxpaln | yep, definitely | 12:32 |
| jonibo | ok, and the pong giong out? | 12:33 |
| maxpaln | nope - no ping reply is sent | 12:33 |
| jonibo | windows firewall? | 12:33 |
| maxpaln | if I replace the board with another laptop I can ping successfully | 12:33 |
| jonibo | the problem would be on the windows side if you're seeing the ping request but no pong is sent as a response... | 12:33 |
| jonibo | ok | 12:34 |
| maxpaln | but it's a good point - mayeb the firewall treats the board different to another laptop, worth a quick try | 12:34 |
| maxpaln | nope - no success | 12:35 |
| maxpaln | one point worth making - when I ping from the board, wireshark shows a LOT of ARPs from thge board for random IP addresses within 192.168. | 12:36 |
| maxpaln | fpor example 192.168.204.80 or 192.168.51.120 | 12:36 |
| maxpaln | might not be relevant but it happens as part of the ping process which seems weird | 12:36 |
| _franck_web_ | on your PC machine "arp -a" | 12:36 |
| maxpaln | wierd | 12:36 |
| _franck_web_ | and check is 192.168.1.101 is here | 12:37 |
| maxpaln | welll, we've switched to 192.168.2.X (jonibo highlighted a conflict with the wifi) | 12:38 |
| maxpaln | but it isn't there: | 12:38 |
| maxpaln | http://pastie.org/private/opv7sbhmwhwrvaptcbktfw | 12:38 |
| _franck_web_ | it is, line 5 | 12:39 |
| maxpaln | ah, ok - wasn't reading it corrtcely - I see it now | 12:39 |
| _franck_web_ | so the ping know where to send the reply.... | 12:39 |
| blueCmd_ | did you have an ipconfig /all somewhere? | 12:40 |
| maxpaln | this is new progress - freshly achieved thanks for jonibo and the resolution of the ip conflict with wifi | 12:40 |
| maxpaln | blueCmd: here is a fresh paste: | 12:41 |
| maxpaln | http://pastie.org/private/hs93booygcqspj0tjm5ha | 12:41 |
| blueCmd_ | as well as an 'ip addr', 'ip ro' and 'ip ro get 192.168.2.100' from the board | 12:41 |
| blueCmd_ | also 'arp -n' | 12:41 |
| maxpaln | the commands output from the board: http://pastie.org/private/1n6np0rfiouxwmzsb98w | 12:42 |
| blueCmd_ | that's not the MAC the WIndows machine has seen 192.168.2.101 | 12:44 |
| _franck_web_ | good catch blueCmd_ | 12:44 |
| maxpaln | oooh, you're right | 12:45 |
| maxpaln | ip addr | 12:45 |
| blueCmd_ | _franck_web_: thanks, | 12:45 |
| blueCmd_ | but it's weird | 12:45 |
| maxpaln | ooops, wrong window in focus! | 12:45 |
| blueCmd_ | I would reboot the Windows machine. Beause of reasons, and it's Windows | 12:46 |
| _franck_web_ | maxpaln: double check the ARP reply from your board to see it's MAC address | 12:46 |
| maxpaln | the ARP reply? | 12:47 |
| maxpaln | ah, you mean in Wireshark | 12:47 |
| _franck_web_ | in wireshark | 12:47 |
| maxpaln | ok - yeah - it's the same as the board | 12:47 |
| maxpaln | I just checked that | 12:47 |
| blueCmd_ | did you reboot the board recently? | 12:47 |
| _franck_web_ | or you can clear the windows arp cache | 12:47 |
| maxpaln | nope - not in a while | 12:47 |
| maxpaln | let me do that - give me an hour (only joking) | 12:48 |
| maxpaln | be back online in 5 mins or so | 12:48 |
| blueCmd_ | ok. I know the kernel randomly generates MAC for ethoc, but if you haven't rebooted that should be fine | 12:48 |
| maxpaln | yeah - a new MAC gets assigned to the ETH interface each time | 12:49 |
| _franck_web_ | arp -d 192.168.2.101 | 12:49 |
| maxpaln | I was just thinking the same | 12:49 |
| maxpaln | denied: The ARP entry deletion failed: The requested operation requires elevation. | 12:49 |
| maxpaln | [frickin windows] | 12:49 |
| maxpaln | ok - done | 12:50 |
| maxpaln | so a fresh arp -a shows no entry for 192.168.2.101 (as expected) | 12:50 |
| _franck_web_ | if you ping from the board you should have a new ARP request/reply | 12:50 |
| _franck_web_ | and arp -a should show you the good MAC | 12:51 |
| maxpaln | ok, this is wierd - now the ping request isn't arriving at the PC | 12:52 |
| maxpaln | I am getting a lot of 'Broadcast' ARPs for random IP addresses within 192.168. by the Board | 12:53 |
| maxpaln | and NO entry in the ARP table on the PC | 12:56 |
| maxpaln | ok, I am going to reboot the PC - because its windows | 12:59 |
| _franck_web_ | ok | 12:59 |
| maxpaln | I'll be back online shortly - the sudden lack of requests is odd, maybe a cold reboot will help | 13:00 |
| maxpaln | you're help is very appreciated BTW - hopefully I can repay later | 13:01 |
| maxpaln | right - finally closed everything down | 13:04 |
| maxpaln | be back online shortly | 13:04 |
| maxpaln | ok ,back online | 13:25 |
| maxpaln | back with some sensible behaviour now | 13:34 |
| maxpaln | pings are still not working | 13:35 |
| maxpaln | but the requests from the board are arriving at the PC now | 13:35 |
| maxpaln | but I am still very confused about the constant stream of ARPs from the board for random IP addresses | 13:35 |
| maxpaln | here is a log from Wireshark - you can see the steady stream of ARPs: | 13:36 |
| maxpaln | https://www.dropbox.com/s/i4y2qxembsbr5ve/ping_from_board_constant_ARPs_for_random_ip_addresses.pcapng | 13:36 |
| maxpaln | just spotted that on the PC the ARP entry for the board is still wrong | 13:38 |
| maxpaln | I didn't make a note of the settings before but the way in which it is wrong looks very similar to last time (first 2 bytes correct then the remaining 4 incorrect): | 13:40 |
| maxpaln | http://pastie.org/private/5vsvqxr3tumuniduwlra | 13:40 |
| maxpaln | somewhat predictably - the MAC address in the packet sent by the Board is also incorrect | 13:42 |
| maxpaln | (maybe it was before too - with the first few bytes being correct perhaps I gave it a cursory glance rather than a good comparisoin | 13:43 |
| _franck_web_ | indeed this ARP requests are weird | 13:44 |
| maxpaln | ok, a correction | 13:45 |
| maxpaln | having looked at the log further I can see there is a mixture of pings from the PC and from the Board (I tried both) | 13:46 |
| maxpaln | the ping fromthe board is correct - it contains the correct MAC address | 13:46 |
| _franck_web_ | look at that, your board mac address in the PC arp table: 8e-2e-c0-a8-02-66 | 13:46 |
| _franck_web_ | c0-a8-02-66 = 192.168.2.102 | 13:47 |
| maxpaln | yep, I saw that | 13:47 |
| maxpaln | I think I can reliably cause that to happen | 13:47 |
| maxpaln | by removing the entry from the ARP table than pinging the board from the PC | 13:48 |
| maxpaln | let me try | 13:48 |
| maxpaln | i'll capture the log in wireshark | 13:48 |
| _franck_web_ | great | 13:48 |
| _franck_web_ | who is .102 ? | 13:49 |
| maxpaln | ok, here is log - it happened exactly as I expected | 13:50 |
| maxpaln | https://www.dropbox.com/s/u284nb3om9o9hgw/pping_from_pc_with_incorrect_arp_returned_for_board.pcapng | 13:50 |
| maxpaln | .102 is the board | 13:50 |
| maxpaln | the ARP request for 192.168.2.102 returns an incorrect MAC address | 13:50 |
| maxpaln | I presume this is the board responding - | 13:50 |
| maxpaln | more specifically it is the hardware in the board | 13:51 |
| maxpaln | rather than the kernel (If I understand how the ARP is handled) | 13:51 |
| maxpaln | so the Ping from the PC has an incorrect MAC address so it never arrives at the board | 13:52 |
| maxpaln | the ping from board makes it to the PC but the PC has an incorrect arp entry for that MAC address | 13:52 |
| maxpaln | I would have thought we'd still see a Ping reply but with the wrong mac address but maybe I'm wrong | 13:53 |
| _franck_web_ | me too | 13:53 |
| _franck_web_ | but still, there is a problem here in the ARP | 13:53 |
| maxpaln | agreed | 13:54 |
| maxpaln | the question is where is the incorrect mac address response being generated when the arp request is sent out | 13:54 |
| _franck_web_ | now you need to dive into the Kernel | 13:54 |
| maxpaln | ok, you think its a kernel issue rather than ORSOC HW? | 13:55 |
| _franck_web_ | I would print the arp packet in the driver tx routine | 13:56 |
| olofk_ | _franck_web_: Thanks for the CPP patch for or1k-elf-loader btw. | 13:56 |
| maxpaln | I guess it must be in the kernel thinking about it - ARP isn't part of the HW laye | 13:56 |
| maxpaln | layer | 13:56 |
| _franck_web_ | no it's not | 13:57 |
| maxpaln | ok, in I dive | 13:57 |
| maxpaln | i'll come up for air periodically | 13:57 |
| _franck_web_ | but who knows, my be some fifo over/underrun somewhere.... | 13:57 |
| maxpaln | [shudders] | 13:58 |
| _franck_web_ | olofk_: when you have time, please comment: https://github.com/fjullien/orpsoc/commit/a82b38838bdf8cc1948e2a48892166d0b59169e7 | 13:58 |
| _franck_web_ | maxpaln: me be hardware; if you look at ICMP with bad crc, you can see that CRC = last two bytes of src address :) | 14:00 |
| maxpaln | aha | 14:03 |
| maxpaln | and interestingly, I decided to reboot the linux kernel a few times and get a few sets of mac addresses (good from board and bad from PC for comparison) | 14:03 |
| _franck_web_ | maxpaln: print skb->data in ethoc_start_xmit | 14:05 |
| maxpaln | I have two sets and in both cases the upper four bytes are almost identical in the PC arp table: C0-A8-02-66 and C0-A8-02-67 | 14:05 |
| olofk_ | olofk: Yeah, I have looked at it briefly and it seems fine, but I will look at it more closely when I have time | 14:11 |
| olofk_ | I mean _franck_web_ of course | 14:13 |
| olofk_ | That wasn't meant to be a note to self :) | 14:13 |
| maxpaln | _franck_web_: hmmm, might need a little guidance here - I tried looking for the definition of sk_buff to see what type to print | 14:29 |
| maxpaln | all I found was an empty definition in phy.h - and trying to trace the call to ethoc_start_xmit didn't get me anywhere. | 14:30 |
| maxpaln | I took a guess at type char * and did a print with %s as the type and it results in this: | 14:30 |
| maxpaln | # net eth0: skb->data is \& | 14:30 |
| maxpaln | 8WÒ®m` | 14:30 |
| juliusb_ | greetings | 14:32 |
| _franck_web_ | print for (i = 0 ; i < skb->len; i++) | 14:32 |
| maxpaln | :-) thanks | 14:32 |
| juliusb_ | looks like the irc logs are down (and my high-impact home page) | 14:32 |
| _franck_web_ | skb->data[i] | 14:32 |
| _franck_web_ | %x | 14:32 |
| _franck_web_ | juliusb_: hello | 14:32 |
| juliusb_ | hmm actually, no, it's fine from my phone. OK something up with my web browser at work | 14:33 |
| juliusb_ | _franck_web_: salut! :) how are you? | 14:33 |
| juliusb_ | happy new year all, by the way | 14:33 |
| juliusb_ | belatedly | 14:33 |
| _franck_web_ | right, happy new year :) | 14:35 |
| juliusb_ | what's been going down? | 14:36 |
| juliusb_ | ... aside from the number lines contributed to OpenRISC-related projects and IRC lately :( | 14:37 |
| _franck_web_ | well, we are still spending your time on thing that nobody cares and won't make us rich :) | 14:38 |
| olofk_ | Hi juliusb_ Good to see you | 14:38 |
| olofk_ | Are the logs down? That's not good... .it's where I usually go to find out the syntax for git fetch | 14:39 |
| maxpaln | (pretty new to this but I've been adding more than my fair share of lines to the log I think :-) ) | 14:41 |
| maxpaln | _franck_web_: here is the output - not sure if the format is helpful or not but I wasn't sure what to expect (I captured the HW address too for reference): | 14:42 |
| maxpaln | http://pastie.org/private/qhsk3uogo1goynguthtorq | 14:42 |
| _franck_web_ | maxpaln: this is frame, compare with wireshark | 14:46 |
| maxpaln | ah, ok | 14:46 |
| _franck_web_ | http://pastie.org/private/xi1xxvmrkadaw6ocppvhw would be easier to read | 14:46 |
| maxpaln | well, crucially bytes 24-27 are different | 14:49 |
| _franck_web_ | you can filter ARP frames with skb->data[12] == 8 && skb->data[13] == 6 | 14:49 |
| _franck_web_ | so there are good in the printk and not good in wireshark ? | 14:50 |
| olofk_ | juliusb_: Lots of stuff going on. From the top of my head: maxpaln running ORPSoCv2 on Lattice, blueCmd_ working on glibc and making debs for the toolchain, _franck_web_ and I are improving orpsocv3, jonibo and stekern are fixing linux stuff | 14:50 |
| olofk_ | Probabyl a lot more that I forgot right now | 14:50 |
| maxpaln | realised I might have been looking at an old wireshark log | 14:50 |
| maxpaln | let me doubel check and confirm | 14:50 |
| maxpaln | but I think that is correct | 14:50 |
| maxpaln | ok, confirmed - the printk contains the correct MAC address (or at least a MAC address consistent with that reported by ifconfig) and wireshark contains incorrect data | 14:55 |
| _franck_web_ | ok, so now you can close the Linux source files :) | 14:56 |
| maxpaln | interestingly, the ethernet frame has the correct MAC address but the ARP section of the packet contains the wrong MAC address | 14:57 |
| maxpaln | ok, closing the source files :-) | 14:57 |
| _franck_web_ | the ARP and ICMP frame are corrupted the same way | 14:57 |
| maxpaln | ok | 14:59 |
| maxpaln | well, the ethernet frame contains the correct HW address in both ARP and ICMP packets | 15:04 |
| maxpaln | I see what you are saying - the checksum bytes in the ICMP (which are incorrect) are in bytes 24 and 25, which is also where the HW address is sent in the ARP packet | 15:09 |
| maxpaln | oooh, tricky one - over the to Verilog... | 15:12 |
| maxpaln | so the most likely culprit is probably the memories - according to our tools the rest of the ETHMAC block is just implemented via straightforward logic (i.e. no distributed memory and so on). | 15:17 |
| maxpaln | the ETHMAC instantiates 4 block RAMs, 3 as FIFOs (two Rx and 1 Tx) and 1 as a BD_RAM | 15:18 |
| maxpaln | ok, I can see there are some technology specific mappings in the BD_RAM, I'll take a look and see if I can see what sort of memories are used in the Xilinx or Altera versions - maybe there's a latency issue or something similar | 15:22 |
| _franck_web_ | yeah, might be | 15:22 |
| maxpaln | hmmm, might be onto something here - | 15:31 |
| juliusb_ | olofk_: nah website is actually OK, fortunately. It is a rich mine of git-related commands, I agree :) | 15:32 |
| juliusb_ | sounds good | 15:33 |
| juliusb_ | I was contacted about running another chiphack at some point, so I'll still be active spreading the OpenRISC gospel | 15:33 |
| maxpaln | the BD_RAM has been inferred as a dual port RAM by Synplify - not sure why. But it should be a single port - there is a likely conflict with both ports accessing the same memory space simultaneously | 15:33 |
| maxpaln | I'll modify and rebuild the HW | 15:34 |
| olofk | juliusb_: Sounds like fun. Give me a shout if you want an extra hand. It would be fun to come over if I can make the time | 18:15 |
| olofk | _franck_: I'm starting reviewing your patch now and writing down what I find | 18:22 |
| olofk | Instead of using Launcher with bash as the first argument, you can set shell=True as a parameter | 18:22 |
| olofk | in modelsim.py there's a new import subprocess that's not needed | 18:27 |
| olofk | Other than that, it looks all good. I could make the changes and apply the patch if you like | 18:29 |
| olofk | ok, I've amended the changes. Should I push it? | 18:42 |
| _franck_ | olofk: did you do something about the VERILATOR_ROOT variable ? | 18:58 |
| _franck_ | olofk: we should have a "next" branch in the orpsoc repo | 18:59 |
| _franck_ | so we could push new feature and test it before we push to master | 19:00 |
| _franck_ | I did not test a core simulation with verilator. I only worked on or1200-generic system | 19:02 |
| _franck_ | olofk: ok, you were talking about the script patches.... | 20:13 |
| _franck_ | so yes you can apply this one | 20:13 |
| --- Log closed Sat Jan 18 00:00:59 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!