Re: git https issue
On Fri, Aug 10, 2018 at 6:01 PM, Riccardo Mottola wrote: > Hi Matthew, > > > On 05/08/2018 19:44, matthew sporleder wrote: >> >> On Sun, Aug 5, 2018 at 7:57 AM, Riccardo Mottola >> wrote: >>> >>> Hi Matthew, >>> >>> >>> On 30/07/2018 22:18, matthew sporleder wrote: Does it hang or finish? GIT_CURL_VERBOSE or --verbose ? >>> >>> >>> it finishes without doing anything, I added --verbose: >>> >>> $ git clone --verbose https://github.com/github/debug-repo >>> /tmp/debug-repo-http >>> Cloning into '/tmp/debug-repo-http'... >>> $ >>> >>> no output... the variable helps though: >>> >>> narsil$ git clone --verbose https://github.com/github/debug-repo >>> /tmp/debug-repo-http >>> Cloning into '/tmp/debug-repo-http'... >>> * Couldn't find host github.com in the .netrc file; using defaults >>> * Trying 192.30.253.113... >>> * TCP_NODELAY set >>> * Connected to github.com (192.30.253.113) port 443 (#0) >>> * ALPN, offering http/1.1 >>> * Cipher selection: >>> ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH >>> * successfully set certificate verify locations: >>>CAfile: none >>>CApath: /etc/openssl/certs >>> >>> >>> where is the issue?? a missing cert? can I force reinstalling >>> certificates? >>> >>> Riccardo >>> >>> >> >> >> When I do it: >> tmp $ GIT_CURL_VERBOSE=1 git clone --verbose >> https://github.com/github/debug-repo >> Cloning into 'debug-repo'... >> * Couldn't find host github.com in the .netrc file; using defaults >> * Trying 192.30.253.112... >> * TCP_NODELAY set >> * Connected to github.com (192.30.253.112) port 443 (#0) >> * Cipher selection: >> ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH >> * successfully set certificate verify locations: >> * CAfile: none >>CApath: /etc/openssl/certs >> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 >> * Server certificate: >> * subject: businessCategory=Private Organization; >> 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; >> serialNumber=5157550; C=US; ST=California; L=San Francisco; O=GitHub, >> Inc.; CN=github.com >> * start date: May 8 00:00:00 2018 GMT >> * expire date: Jun 3 12:00:00 2020 GMT >> * subjectAltName: host "github.com" matched cert's "github.com" >> * issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 >> Extended Validation Server CA >> * SSL certificate verify ok. >>> >>> GET /github/debug-repo/info/refs?service=git-upload-pack HTTP/1.1 >> >> Host: github.com >> User-Agent: git/2.14.1 >> Accept: */* >> Accept-Encoding: gzip >> Accept-Language: en-US, *;q=0.9 >> Pragma: no-cache >> >> < HTTP/1.1 200 OK >> < Server: GitHub Babel 2.0 >> < Content-Type: application/x-git-upload-pack-advertisement >> < Transfer-Encoding: chunked >> < Expires: Fri, 01 Jan 1980 00:00:00 GMT >> < Pragma: no-cache >> < Cache-Control: no-cache, max-age=0, must-revalidate >> < Vary: Accept-Encoding >> < X-GitHub-Request-Id: C495:6D8D:17611E4:288C91B:5B673724 >> < X-Frame-Options: DENY >> < >> * Connection #0 to host github.com left intact >> POST git-upload-pack (165 bytes) >> * Couldn't find host github.com in the .netrc file; using defaults >> * Found bundle for host github.com: 0x7f7ff7b2e200 [can pipeline] >> * Re-using existing connection! (#0) with host github.com >> * Connected to github.com (192.30.253.112) port 443 (#0) >>> >>> POST /github/debug-repo/git-upload-pack HTTP/1.1 >> >> Host: github.com >> User-Agent: git/2.14.1 >> Accept-Encoding: gzip >> Content-Type: application/x-git-upload-pack-request >> Accept: application/x-git-upload-pack-result >> Content-Length: 165 >> >> * upload completely sent off: 165 out of 165 bytes >> < HTTP/1.1 200 OK >> < Server: GitHub Babel 2.0 >> < Content-Type: application/x-git-upload-pack-result >> < Transfer-Encoding: chunked >> >> > > indeed, quite a different output, but where is the issue? I do wonder? > > Just to be sure, I installed > http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/8.0_2018Q1/All/mozilla-rootcerts-openssl-2.1.tgz > so I have fresh certificates (the old one remained in /etc/openssl/certs > after upgrade) > > but it did not help. What else could I missing? I bet it is a configuration > issue > > Thank you > > Riccardo I think the GIT_CURL_VERBOSE=1 is going to give you the answer.
Re: git https issue
Hi Matthew, On 05/08/2018 19:44, matthew sporleder wrote: On Sun, Aug 5, 2018 at 7:57 AM, Riccardo Mottola wrote: Hi Matthew, On 30/07/2018 22:18, matthew sporleder wrote: Does it hang or finish? GIT_CURL_VERBOSE or --verbose ? it finishes without doing anything, I added --verbose: $ git clone --verbose https://github.com/github/debug-repo /tmp/debug-repo-http Cloning into '/tmp/debug-repo-http'... $ no output... the variable helps though: narsil$ git clone --verbose https://github.com/github/debug-repo /tmp/debug-repo-http Cloning into '/tmp/debug-repo-http'... * Couldn't find host github.com in the .netrc file; using defaults * Trying 192.30.253.113... * TCP_NODELAY set * Connected to github.com (192.30.253.113) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: CAfile: none CApath: /etc/openssl/certs where is the issue?? a missing cert? can I force reinstalling certificates? Riccardo When I do it: tmp $ GIT_CURL_VERBOSE=1 git clone --verbose https://github.com/github/debug-repo Cloning into 'debug-repo'... * Couldn't find host github.com in the .netrc file; using defaults * Trying 192.30.253.112... * TCP_NODELAY set * Connected to github.com (192.30.253.112) port 443 (#0) * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: none CApath: /etc/openssl/certs * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 * Server certificate: * subject: businessCategory=Private Organization; 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; serialNumber=5157550; C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com * start date: May 8 00:00:00 2018 GMT * expire date: Jun 3 12:00:00 2020 GMT * subjectAltName: host "github.com" matched cert's "github.com" * issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA * SSL certificate verify ok. GET /github/debug-repo/info/refs?service=git-upload-pack HTTP/1.1 Host: github.com User-Agent: git/2.14.1 Accept: */* Accept-Encoding: gzip Accept-Language: en-US, *;q=0.9 Pragma: no-cache < HTTP/1.1 200 OK < Server: GitHub Babel 2.0 < Content-Type: application/x-git-upload-pack-advertisement < Transfer-Encoding: chunked < Expires: Fri, 01 Jan 1980 00:00:00 GMT < Pragma: no-cache < Cache-Control: no-cache, max-age=0, must-revalidate < Vary: Accept-Encoding < X-GitHub-Request-Id: C495:6D8D:17611E4:288C91B:5B673724 < X-Frame-Options: DENY < * Connection #0 to host github.com left intact POST git-upload-pack (165 bytes) * Couldn't find host github.com in the .netrc file; using defaults * Found bundle for host github.com: 0x7f7ff7b2e200 [can pipeline] * Re-using existing connection! (#0) with host github.com * Connected to github.com (192.30.253.112) port 443 (#0) POST /github/debug-repo/git-upload-pack HTTP/1.1 Host: github.com User-Agent: git/2.14.1 Accept-Encoding: gzip Content-Type: application/x-git-upload-pack-request Accept: application/x-git-upload-pack-result Content-Length: 165 * upload completely sent off: 165 out of 165 bytes < HTTP/1.1 200 OK < Server: GitHub Babel 2.0 < Content-Type: application/x-git-upload-pack-result < Transfer-Encoding: chunked indeed, quite a different output, but where is the issue? I do wonder? Just to be sure, I installed http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/i386/8.0_2018Q1/All/mozilla-rootcerts-openssl-2.1.tgz so I have fresh certificates (the old one remained in /etc/openssl/certs after upgrade) but it did not help. What else could I missing? I bet it is a configuration issue Thank you Riccardo
Re: Smooth ThinkPad installation
Riccardo Mottola wrote: > ß Is really used a lot in the messages. Maybe the font can be > expanded? how? I think ö was present: some special characters > displayed. Well, old VGA fonts could be modified with pcvt-utils, at least that's what the guide says. This "high-res" font is kinda built-in into drm(4) (correct me if I'm wrong), that's why you can't change it with wsfontload(8). -- caóc
Re: curses(3) handling of UTF-8 in various programs
Leonardo Taccari wrote:
> Hello Cág, Brett and netbsd-users@!
> (I'll reply to both emails here)
Hello Leonardo!
> At least regarding the noice problem, that's just a kludge but a
> possible patch that workaround the problem is attached in this email
> (it can be used as a LOCALPATCHES for sysutils/noice).
> Most printw() calls in noice seems easy to be changed to addstr() ones
> and with them the single bytes are output as-is (IIUC!).
I guess I'll contact upstream about that.
I mentioned moc (Music On Console) that it showed question marks instead
of UTF-8 characters, turns out if you fake ncurses it shows stuff
properly. I'll push it to pkgsrc when I'll stop being lazy ;)
I've got way too much new software so it'd be greedy not to share :)
> The following code should be enough to reproduce what happens in
> noice via argv[]:
>
>#include
>#include
>
>int
>main(int argc, char *argv[])
>{
>int i;
>
>setlocale(LC_ALL, "");
>
>initscr();
>for (i = 1; i < argc; i++)
>printw("%s\n", argv[i]);
>getch();
>endwin();
>
>return 0;
>}
Can we consider this a curses bug?
Thanks for your time and efforts!
--
caóc
Re: Smooth ThinkPad installation
Hi, Riccardo Mottola wrote: > very nice! Only glitch? I choose german as a language and I noticed > that while Umlauts kame out, the ß was not printed out replaced with a > space instead. > > so e.g. Größe displayed as Grö e. Is that on the tty? The font is missing a few characters, ß is one, and ð æ ö are some of the others. -- caóc
Re: NetBSD block vs raw disk I/O
2018-08-10 11:35 GMT+02:00 Sad Clouds : > localhost# dd if=/dev/rsd0d of=/dev/null bs=1m count=1 > 1+0 records in > 1+0 records out > 1048576 bytes transferred in 11.749 secs (892481062 bytes/sec) > > localhost# dd if=/dev/sd0d of=/dev/null bs=1m count=1 > 1+0 records in > 1+0 records out > 1048576 bytes transferred in 196.552 secs (53348528 bytes/sec) > > Any ideas why block device I/O is so abysmal? Is this something > specific to NetBSD? There is some experimental code on -current to optimize one part of the read/write-based I/O, supported on amd64. You can just boot a -current kernel (for example one from daily builds) to single user, and enable the code by escaping to DDB and setting variable ubc_direct to 1 (ctrl-alt-esc will give you DDB prompt, then 'w ubc_direct 1'), then 'continue' in DDB, then run your dd command. Jaromir
Re: PCI passthrough not working with bhyve and NetBSD
MSI and MSI-X themselves are supported on amd64, though not every driver use it. Both wm(4) and bge(4) however do support it and use it, so should work. Maybe there is either some misunderstanding about the MSI support (e.g. our PCI subsystem doesn't detect it), or the PCI probe code tries to allocate (and fails) the INTx interrupt regardless of MSI. Jaromir 2018-08-10 0:34 GMT+02:00 Farid Joubbi : > I think I know the cause of the problem. > I posted this same question on the FreeBSD virtualization list, and received > this reply which sounds plausible: > > You have to use MSI interrupts for pass-through devices for bhyve. Those > errors look as if the guests are trying to use legacy INTx interrupts. > > I found this paper explaining the problem with the lack of MSI-X support: > > https://www.netbsd.org/gallery/presentations/ozaki-r/2015_AsiaBSDCon/ABC2015-P4C-paper.pdf > > The paper is three years old. What is the state of MSI in NetBSD now? > Is my problem due to lack of MSI support, or is the support there but not > used? > > > On Sun, Jul 15, 2018, 21:00 Farid Joubbi wrote: >> >> I have current installed on it now. >> It has both the Intel and Broadcom NICs with passthrough as well as the >> virtual NIC from bhyve. >> The virtual NIC works nice. I used it to fetch the installation sets. >> >> From dmesg: >> [ 1.0448813] virtio1 at pci0 dev 5 function 0 >> [ 1.0448813] virtio1: Virtio Network Device (rev. 0x00) >> [ 1.0448813] vioif0 at virtio1: Features: >> 0x11010020 >> [ 1.0448813] vioif0: Ethernet address 58:9c:fc:0b:96:50 >> [ 1.0448813] virtio1: config interrupting at msix0 vec 0 >> [ 1.0448813] virtio1: queues interrupting at msix0 vec 1 >> [ 1.0448813] wm0 at pci0 dev 6 function 0: 82576 quad-1000BaseT Ethernet >> (rev. 0x01) >> [ 1.0448813] wm0: interrupting at msi1 vec 0 >> [ 1.0448813] wm0: Ethernet address 00:1b:21:84:e9:ed >> [ 1.0448813] igphy0 at wm0 phy 1: i82566 10/100/1000 media interface, >> rev. 1 >> [ 1.0448813] igphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, >> 1000baseT, 1000baseT-FDX, auto >> [ 1.0448813] bge0 at pci0 dev 7 function 0: Broadcom BCM5720 Gigabit >> Ethernet >> [ 1.0448813] bge0: APE firmware NCSI 1.4.12.0 >> [ 1.0448813] bge0: interrupting at msi2 vec 0 >> [ 1.0448813] bge0: HW config 002b1094, 6014, 0002aa38, >> 000c >> [ 1.0448813] bge0: ASIC BCM5720 A0 (0x572), Ethernet address >> 3c:a8:2a:e4:bc:eb >> [ 1.0448813] bge0: no PHY found! >> [ 1.0448813] pcib0 at pci0 dev 31 function 0: vendor 8086 product 7000 >> (rev. 0x00) >> [ 1.0448813] isa0 at pcib0 >> [ 1.0448813] com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo >> [ 1.0448813] com0: console >> [ 1.0448813] com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo >> [ 1.5402764] WARNING: 1 error while detecting hardware; check system >> log. >> >> >> The intel NIC is connected at the moment. >> It should receive an address with DHCP. >> >> localhost# ifconfig >> vioif0: flags=0x8943 mtu >> 1500 >> ec_capabilities=1 >> ec_enabled=0 >> address: 58:9c:fc:0b:96:50 >> inet6 fe80::5a9c:fcff:fe0b:9650%vioif0/64 flags 0x0 scopeid 0x1 >> wm0: flags=0x8843 mtu 1500 >> capabilities=7ff80 >> >> capabilities=7ff80 >> capabilities=7ff80 >> enabled=0 >> ec_capabilities=7 >> ec_enabled=0 >> address: 00:1b:21:84:e9:ed >> media: Ethernet autoselect (1000baseT >> full-duplex,flowcontrol,rxpause,txpause) >> status: active >> inet 169.254.58.45/16 broadcast 169.254.255.255 flags 0x0 >> inet6 fe80::220e:9ccf:9196:97d1%wm0/64 flags 0x0 scopeid 0x2 >> bge0: flags=0x8802 mtu 1500 >> >> capabilities=3f80 >> capabilities=3f80 >> enabled=0 >> ec_capabilities=7 >> ec_enabled=0 >> address: 3c:a8:2a:e4:bc:eb >> media: Ethernet manual (none) >> lo0: flags=0x8049 mtu 33624 >> inet 127.0.0.1/8 flags 0x0 >> inet6 ::1/128 flags 0x20 >> inet6 fe80::1%lo0/64 flags 0x0 scopeid 0x4 >> localhost# >> >> rc.conf: >> dhcpcd=YES >> dhcpcd_flags="-qM wm0" >> >> Any help would be much appreciated. >> If I'm able to get one of the physical NICs to work somehow, I could give >> anyone here willing to help debug SSH access to the server. >> >> >> On Sun, Jul 15, 2018 at 1:49 PM wrote: >>> >>> "Farid Joubbi" wrote: >>> => I tried the install CD for the latest HEAD-201807121210Z. >>> => It can see both the NICs, but they don't work. >>> => Trying to configure them with DHCP, it looks as if the NIC is sending >>> a >>> => DISCOVERY but timing out never receiving anything back (I doubt that >>> it is >>> => actually sending anything on the wire). >>> => Then it constantly throws this on the console: "wm0: device timeout >>> (lost >>> => interrupt)". >>> >>>That sounds like the kernel missing interrupts from the NIC, in which >>> case it may actually be sending out the requests but
Re: curses(3) handling of UTF-8 in various programs
Hello Cág, Brett and netbsd-users@!
(I'll reply to both emails here)
Cág writes:
> [...]
> I don't understand whether it's a curses(3) thing or a program bug, but
> linking against ncursesw makes noice display the name correctly.
> [...]
At least regarding the noice problem, that's just a kludge but a
possible patch that workaround the problem is attached in this email
(it can be used as a LOCALPATCHES for sysutils/noice).
Most printw() calls in noice seems easy to be changed to addstr() ones
and with them the single bytes are output as-is (IIUC!).
Brett Lymn writes:
> [...]
> More than likely an application bug but one that is hidden by the
> behaviour of ncursss. It is hard to say without looking at the code but
> it could be something in the terminal initialisation or environment that
> is changing what is on the screen... The complicating factor in some
> situations is the differences in the interpretation done by the terminal
> doing the display (though, in this case I don't think this applies).
> [...]
The following code should be enough to reproduce what happens in
noice via argv[]:
#include
#include
int
main(int argc, char *argv[])
{
int i;
setlocale(LC_ALL, "");
initscr();
for (i = 1; i < argc; i++)
printw("%s\n", argv[i]);
getch();
endwin();
return 0;
}
$NetBSD$
Directly use addstr() instead of printw() in order to output every
bytes without any transformation (and hence also correctly displaying
Unicode characters).
--- noice.c.orig 2018-08-10 18:55:47.299592935 +0200
+++ noice.c 2018-08-10 19:01:15.778111428 +0200
@@ -293,7 +293,8 @@
printmsg(char *msg)
{
move(LINES - 1, 0);
- printw("%s\n", msg);
+ addstr(msg);
+ addstr("\n");
}
/* Display warning as a message */
@@ -324,7 +325,7 @@
printprompt(char *str)
{
clearprompt();
- printw(str);
+ addstr(str);
}
/* Returns SEL_* if key is bound and 0 otherwise.
@@ -428,10 +429,16 @@
if (strlen(name) > maxlen)
name[maxlen] = '\0';
- if (cm == 0)
- printw("%s%s\n", active ? CURSR : EMPTY, name);
- else
- printw("%s%s%c\n", active ? CURSR : EMPTY, name, cm);
+ if (cm == 0) {
+ addstr(active ? CURSR : EMPTY );
+ addstr(name);
+ addstr("\n");
+ } else {
+ addstr(active ? CURSR : EMPTY);
+ addstr(name);
+ addch(cm);
+ addstr("\n");
+ }
}
int
Re: NetBSD block vs raw disk I/O
cryintotheblue...@gmail.com (Sad Clouds) writes: >Reading from the virtual RAID drive gives throughput of 892MB/sec for >raw device, but only 53MB/sec for block device. This is NetBSD-8 >Any ideas why block device I/O is so abysmal? Is this something >specific to NetBSD? When using the block device, everything is funneled through the classic buffer cache. The buffer size is retrieved from the disklabel and defaults to 2kbyte only. Finally, reads are done synchronously without significant read-ahead. This is specific to NetBSD, but it is hardly used because file I/O is done by the virtual memory system, bypassing the classic buffer cache. So there is no incentive to improve the situation as it also requires a redesign of the buffer cache and some people would rather get rid of the block device interface. So, just don't use it. In particular not for benchmarks :) -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
NetBSD block vs raw disk I/O
Hello, I have LSI RAID card with 2 RADI0 SSD drives sd0 at scsibus0 target 0 lun 0: disk fixed sd0: fabricating a geometry sd0: 952 GB, 975744 cyl, 64 head, 32 sec, 512 bytes/sect x 1998323712 sectors Reading from the virtual RAID drive gives throughput of 892MB/sec for raw device, but only 53MB/sec for block device. This is NetBSD-8 localhost# dd if=/dev/rsd0d of=/dev/null bs=1m count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 11.749 secs (892481062 bytes/sec) localhost# dd if=/dev/sd0d of=/dev/null bs=1m count=1 1+0 records in 1+0 records out 1048576 bytes transferred in 196.552 secs (53348528 bytes/sec) Any ideas why block device I/O is so abysmal? Is this something specific to NetBSD?
Re: man.netbsd.org is down
from David H. Gutteridge: > I thought I'd mention it seems man.netbsd.org (a.k.a. netbsd.gw.com) > has been down for at least the last two days. (I happened to notice > because I have occasion to check NetBSD man pages while I don't have > access to a NetBSD machine.) I tried and also got no response from man.netbsd.org Tom
Re: PCI passthrough not working with bhyve and NetBSD
I think I know the cause of the problem. I posted this same question on the FreeBSD virtualization list, and received this reply which sounds plausible: You have to use MSI interrupts for pass-through devices for bhyve. Those errors look as if the guests are trying to use legacy INTx interrupts. I found this paper explaining the problem with the lack of MSI-X support: https://www.netbsd.org/gallery/presentations/ozaki-r/2015_AsiaBSDCon/ABC2015-P4C-paper.pdf The paper is three years old. What is the state of MSI in NetBSD now? Is my problem due to lack of MSI support, or is the support there but not used? On Sun, Jul 15, 2018, 21:00 Farid Joubbi wrote: > I have current installed on it now. > It has both the Intel and Broadcom NICs with passthrough as well as the > virtual NIC from bhyve. > The virtual NIC works nice. I used it to fetch the installation sets. > > From dmesg: > [ 1.0448813] virtio1 at pci0 dev 5 function 0 > [ 1.0448813] virtio1: Virtio Network Device (rev. 0x00) > [ 1.0448813] vioif0 at virtio1: Features: > 0x11010020 > [ 1.0448813] vioif0: Ethernet address 58:9c:fc:0b:96:50 > [ 1.0448813] virtio1: config interrupting at msix0 vec 0 > [ 1.0448813] virtio1: queues interrupting at msix0 vec 1 > [ 1.0448813] wm0 at pci0 dev 6 function 0: 82576 quad-1000BaseT Ethernet > (rev. 0x01) > [ 1.0448813] wm0: interrupting at msi1 vec 0 > [ 1.0448813] wm0: Ethernet address 00:1b:21:84:e9:ed > [ 1.0448813] igphy0 at wm0 phy 1: i82566 10/100/1000 media interface, > rev. 1 > [ 1.0448813] igphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseT, 1000baseT-FDX, auto > [ 1.0448813] bge0 at pci0 dev 7 function 0: Broadcom BCM5720 Gigabit > Ethernet > [ 1.0448813] bge0: APE firmware NCSI 1.4.12.0 > [ 1.0448813] bge0: interrupting at msi2 vec 0 > [ 1.0448813] bge0: HW config 002b1094, 6014, 0002aa38, > 000c > [ 1.0448813] bge0: ASIC BCM5720 A0 (0x572), Ethernet address > 3c:a8:2a:e4:bc:eb > [ 1.0448813] bge0: no PHY found! > [ 1.0448813] pcib0 at pci0 dev 31 function 0: vendor 8086 product 7000 > (rev. 0x00) > [ 1.0448813] isa0 at pcib0 > [ 1.0448813] com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo > [ 1.0448813] com0: console > [ 1.0448813] com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo > [ 1.5402764] WARNING: 1 error while detecting hardware; check system log. > > > The intel NIC is connected at the moment. > It should receive an address with DHCP. > > localhost# ifconfig > vioif0: flags=0x8943 mtu > 1500 > ec_capabilities=1 > ec_enabled=0 > address: 58:9c:fc:0b:96:50 > inet6 fe80::5a9c:fcff:fe0b:9650%vioif0/64 flags 0x0 scopeid 0x1 > wm0: flags=0x8843 mtu 1500 > capabilities=7ff80 > capabilities=7ff80 > capabilities=7ff80 > enabled=0 > ec_capabilities=7 > ec_enabled=0 > address: 00:1b:21:84:e9:ed > media: Ethernet autoselect (1000baseT > full-duplex,flowcontrol,rxpause,txpause) > status: active > inet 169.254.58.45/16 broadcast 169.254.255.255 flags 0x0 > inet6 fe80::220e:9ccf:9196:97d1%wm0/64 flags 0x0 scopeid 0x2 > bge0: flags=0x8802 mtu 1500 > > capabilities=3f80 > capabilities=3f80 > enabled=0 > ec_capabilities=7 > ec_enabled=0 > address: 3c:a8:2a:e4:bc:eb > media: Ethernet manual (none) > lo0: flags=0x8049 mtu 33624 > inet 127.0.0.1/8 flags 0x0 > inet6 ::1/128 flags 0x20 > inet6 fe80::1%lo0/64 flags 0x0 scopeid 0x4 > localhost# > > rc.conf: > dhcpcd=YES > dhcpcd_flags="-qM wm0" > > Any help would be much appreciated. > If I'm able to get one of the physical NICs to work somehow, I could give > anyone here willing to help debug SSH access to the server. > > > On Sun, Jul 15, 2018 at 1:49 PM wrote: > >> "Farid Joubbi" wrote: >> => I tried the install CD for the latest HEAD-201807121210Z. >> => It can see both the NICs, but they don't work. >> => Trying to configure them with DHCP, it looks as if the NIC is sending a >> => DISCOVERY but timing out never receiving anything back (I doubt that >> it is >> => actually sending anything on the wire). >> => Then it constantly throws this on the console: "wm0: device timeout >> (lost >> => interrupt)". >> >>That sounds like the kernel missing interrupts from the NIC, in which >> case it may actually be sending out the requests but failing to see the >> replies. Perhaps posting the dmesg, or at least the lines about the >> NICs, could help. >> >> Gary Duzan >> >> >> => On Sat, Jul 14, 2018 at 8:34 PM Farid Joubbi >> wrote: >> => >> =>> I have a working configuration for NetBSD on bhyve. It's not a problem >> =>> with vm-bhyve https://github.com/churchers/vm-bhyve >> =>> >> =>> NetBSD 7.1.2 does not initiate the bge0 nor wm0 at all under bhyve, >> as I >> =>> wrote earlier. >> =>> It seems to run perfectly fine other than that.
man.netbsd.org is down
Hi, I thought I'd mention it seems man.netbsd.org (a.k.a. netbsd.gw.com) has been down for at least the last two days. (I happened to notice because I have occasion to check NetBSD man pages while I don't have access to a NetBSD machine.) Regards, Dave
Re: poweroff and shutdown -p now only reboot my machine
Just to get this here. I've moved the SSD drive containing NetBSD to another machine and both commands are working properly. Regards Den mån 30 juli 2018 16:29Pedro Pinho skrev: > Ok! I've checked hp's webpage. > No BIOS updates available under Linux. Of course, there's no reference to > any BSD. > There're updates available to both BIOS and firmware under Windows, but I > don't have any Windows machine. > I can try to make a DOS bootable USB and boot in UEFI mode to try to > update the BIOS, but I won't be able to do this before earliest next week
