From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f65.google.com ([209.85.222.65]) by ewsd; Mon Jun 17 01:01:29 EDT 2019 Received: by mail-ua1-f65.google.com with SMTP id 89so2238657uab.3 for <9front@9front.org>; Sun, 16 Jun 2019 22:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=1d7I2TVBZb3sgN64mjYKhjUFCfztOE+yZ2NLoE4e9kY=; b=nMJZEKlhseYCbyCMlybkfyehVq1AbsRJt2je7C2P6fPnaKokzr6UzyQo/6PP0GiDjh OtxpKB4BpT2+gXhVsgUlYJ0Dw2+Scjpthebl5HuhN4JhJS5HwmMECUwfnSkpmSvWsoRc Pa2ZFh5DJtXu4Co2y5Wftf2OEU+hVo0+vq4gZTycC9zqvieR8zQEKtCBR+tVfhwEsaW8 BBiXY0wLVNCR+UIyPE4qHFYpSptyLEj6cMiVEUNxGSJGKD3Dvbun8u9vs/5POcWvrZMJ K59t8Z1eXYaSRd9GlVJv2rPKAG0vhWKK/tkRXxBzxt+jRM1UpSkXVycFtw6rFozqde6U I81A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=1d7I2TVBZb3sgN64mjYKhjUFCfztOE+yZ2NLoE4e9kY=; b=FfRY36xCj91Y+MIzRds9jvCzy5gLtyYdAlFVWn0ENRPKVrhz/3HKafMdHxsaRFsHdp ihfvKzONfJJydmzroQeZJKLnr0kwGeRitLb/+oQgf9mZPTYL9Qk2xTVcmxrK/uQDRp1r UCS+9xGO/+48lk46IfZlJLVyikcxcNePBuHnHGgumgA753Gat24e8JxamKRlENIBIa8d 29RH1uUfmsUDOMRQkGk/BcV24ZHKwS6AnD3Rc3XGw+o77teqlshjpQG4KbyaJay0UTFr Ujw/NLRT1kVlMQhlZyElSeSCyC9NvDIl2uArzvmh70zyYvweLy2PcNnZ4C6mMl7Nizug Rwwg== X-Gm-Message-State: APjAAAUdTM/3L9+sp50TbG+u4jJllgvAKR9oSBVQLQdtih9IPwhuPxmP EEaeWMON4vvKlrtCx1Qk/2zkxjPU5gWff8h/s/JazeS+ X-Google-Smtp-Source: APXvYqyY/lZLMgSAL3hgnaersGEh2BJdhVpXk3sl4dB+0jrCsOJlIbvEOwJPhyxSb3HobluAe0OF+WqhxH58/8Pa2Dk= X-Received: by 2002:ab0:22c3:: with SMTP id z3mr7711869uam.51.1560747686120; Sun, 16 Jun 2019 22:01:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?7Je87KSA7ZiB?= Date: Mon, 17 Jun 2019 14:01:15 +0900 Message-ID: Subject: Re: [9front] Need help with configuring the Internet To: 9front@9front.org Content-Type: text/plain; charset="UTF-8" List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: flexible shared module-aware persistence wrapper-scale factory Oh, then I should explain the whole situation first. The initial installation was complete, except the confignet part, which returned the message "Could not find ethernet card" Which results in cat /net/ndb returning nothing (ndb seems to be a blank file for now..). Ori suggested that I looked into the output of "pci -v", which had the following output: 0.31.6: net 02.00.00 8086/15bc 11 0:a1100000 131072 Intel Corporation Ethernet Connection (7) I219-V Which led to the patch by ori: diff -r b703b47e2940 sys/src/9/pc/ether82563.c --- a/sys/src/9/pc/ether82563.c Sat Jun 08 15:56:03 2019 +0930 +++ b/sys/src/9/pc/ether82563.c Mon Jun 10 08:50:44 2019 -0700 @@ -1987,6 +1987,7 @@ case 0x1570: /* i219-v */ case 0x15b8: /* i219-v */ case 0x15b9: /* i219-lm */ + case 0x15bc: /* i219-v */ case 0x15d6: /* i219-v */ case 0x15d7: /* i219-lm */ case 0x15d8: /* i219-v */ Of course, to configure the net properly again, I needed to redo the missing install steps again. Apparently, the scripts were in /bin/inst, so I thought that running "main" here will allow me to redo the missing installation part again. This is where I'm getting the "Could not find ethernet card" message.. That's where I might have been wrong, though. Ori told me the script locations, but he also said he never tried it himself.. and also running "main" was my idea (he told me to run ndbsetup, but I just assumed "main" -> "confignet" will do it for me). Part of that was that running ndbsetup directly didn't really work.. But I'm probably using the scripts wrong anyways. Also to note that 0x15bc isn't on the working hardware list (for ethernet card). Ori suggested that it might just be a missing id, so adding case 0x15bc MIGHT work, although we needed to try it. I at least expected confignet to recognize the ethernet card though.. but I might be wrong here again. I'm looking in to the scripts for right now, although I'm having a bit trouble with the acme editor.. (I'm not used to it at the current moment.. haha) Thanks, Joonhyeok Yeom. On Mon, Jun 17, 2019 at 1:20 PM wrote: > > > I followed your instructions until reboot. What I usually do > > for reboot is just hit ctrl+alt+del, then wait a few seconds until Plan9 > > Console pops up. Is this not the right way to reboot the system? > > I saw this method somewhere on the Internet although I can't recall where. > > its fine for a netbooted terminal. for a fileserver or a terminal > with a local disk, this can cause filesystem corruption. the way to > reboot a machine with disk is fshalt(8). > > > Other than that, echo $objtype returns amd64 (I did change plan9.ini > > to point to amd64), > > and also the short terminal output that pops up before Plan9 Console > > does say boot=9pc64 somewhere in the middle. So up to this point, I'm > > assuming the > > kernel file loaded is 64-bit Intel... > > looks good. > > > Anyways, the Internet still does not work.. > > i have not followed that coversation. > > > Running /bin/inst/main, then typing in 'confignet' returns "Could not > find ethernet card". > > i dont understand, you already have a installation? theres no official > amd64 install disk. if you just want to see what ethernet devices have > been detected you can just do: > > ls /net/ether* > > to get ip by dhcp on the first interface, you run: > > ip/ipconfig > > > I checked the line for ether82563.c at line 1986 (this is where I > > modified, according to ori's solution) > > if you are unsure, you can put a "print("XXX\n");" statement there > before the: "return i219;": > > how was the 0x15bc device id determined? > > > and the line is still there (case 0x15bc:), so I believe the changes > > applied, although it's hard for me > > to check if it applied to the kernel binary I'm currently running it with. > > ... add a print statement is the best test here... you can disassemble > kernel binary and check, but it is unclear if that is the actual binary > being run. > > > Maybe merely adding a case wasn't enough to get rid of the "Could not > > find ethernet card"? > > Although I expected at least some other error message when I applied > > this change... > > possible, check the kernel prints: > > cat /dev/kmesg > > -- > cinap