Re: kern/57992: urtwn (and athn) driver lost network when WIFI router changes channel
El domingo, 3 de marzo de 2024, Michael van Elst escribió: > The following reply was made to PR kern/57992; it has been noted by GNATS
Re: EXT MAIL : Re: USB install is slow
On Fri, Mar 08, 2024 at 03:52:15PM +, Derrick Lobo wrote: > I ended just untaring the sets and running etcupdate as that was much > quicker Huh? If that was much quicker (you were running the same kernel, from the install image?) - where did the upgrade spend all the additional time? Extracting sets should be the major part, plus a bit of "postinstall" where it hashes all the (new with -10) SSL certificates (and the script doing so is suboptimal). Neither should take even close to 10 minutes on amd64 hardware from the last 10 years or so. Martin
RE: EXT MAIL : Re: USB install is slow
Most of the time was spent downloading the tarfile and extracting from the USB once the files are download the install completes quickly -Original Message- From: Martin Husemann Sent: Friday, March 8, 2024 10:57 AM To: Derrick Lobo Cc: netbsd-users@netbsd.org Subject: Re: EXT MAIL : Re: USB install is slow On Fri, Mar 08, 2024 at 03:52:15PM +, Derrick Lobo wrote: > I ended just untaring the sets and running etcupdate as that was much > quicker Huh? If that was much quicker (you were running the same kernel, from the install image?) - where did the upgrade spend all the additional time? Extracting sets should be the major part, plus a bit of "postinstall" where it hashes all the (new with -10) SSL certificates (and the script doing so is suboptimal). Neither should take even close to 10 minutes on amd64 hardware from the last 10 years or so. Martin
Re: EXT MAIL : Re: USB install is slow
On Fri, Mar 08, 2024 at 04:57:00PM +0100, Martin Husemann wrote: > On Fri, Mar 08, 2024 at 03:52:15PM +, Derrick Lobo wrote: > > I ended just untaring the sets and running etcupdate as that was much > > quicker > > Huh? If that was much quicker (you were running the same kernel, from the > install image?) - where did the upgrade spend all the additional time? > Extracting sets should be the major part, plus a bit of "postinstall" where > it hashes all the (new with -10) SSL certificates (and the script doing so > is suboptimal). Neither should take even close to 10 minutes on amd64 hardware > from the last 10 years or so. A shot in the dark: there is a problem report on pkgsrc mailing list linked with tar and extended attributes. In the 10.* series, extended attributes have been added to libc (man 3 acl). Furthermore, modifications have been made, concerning extended attributes, to UFS (with a problem of incompatibility). Possible culprit: tar and extended attributes (libc, kernel, filesystem), involving acrobatics costing a lot of time. -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
RE: EXT MAIL : Re: USB install is slow
Hi Thierry Manual untar seems fine no issues at all. This seems more like copying the file between usb to the local drive as I see stalls when the file is copied over I am hoping someone can reproduce this issue I have reproduced this on 6 servers.. most of them supermicros 1 was a lanner device -Original Message- From: tlaro...@kergis.com Sent: Friday, March 8, 2024 2:43 PM To: Martin Husemann Cc: Derrick Lobo ; netbsd-users@netbsd.org Subject: Re: EXT MAIL : Re: USB install is slow On Fri, Mar 08, 2024 at 04:57:00PM +0100, Martin Husemann wrote: > On Fri, Mar 08, 2024 at 03:52:15PM +, Derrick Lobo wrote: > > I ended just untaring the sets and running etcupdate as that was > > much quicker > > Huh? If that was much quicker (you were running the same kernel, from > the install image?) - where did the upgrade spend all the additional time? > Extracting sets should be the major part, plus a bit of "postinstall" > where it hashes all the (new with -10) SSL certificates (and the > script doing so is suboptimal). Neither should take even close to 10 > minutes on amd64 hardware from the last 10 years or so. A shot in the dark: there is a problem report on pkgsrc mailing list linked with tar and extended attributes. In the 10.* series, extended attributes have been added to libc (man 3 acl). Furthermore, modifications have been made, concerning extended attributes, to UFS (with a problem of incompatibility). Possible culprit: tar and extended attributes (libc, kernel, filesystem), involving acrobatics costing a lot of time. -- Thierry Laronde http://www.kergis.com/ http://kertex.kergis.com/ Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
dmesg error "source can't be determined: dst=x.x.x.x" for aliased address
Hi All After upgrading to netbsd10 rc5 I see the following errors on dmesg all the ips listed are aliased address on the same device we never got these error as same hardware was upgraded from 8 to 9.3 year/s ago and now to 10 rc5. The Aliased ip come through a startup script, they are not aliased on /etc/ifconfig.xxx dmesg [ 11871.345173] source can't be determined: dst=192.168.60.189 [ 11873.084999] source can't be determined: dst=192.168.60.194 [ 11895.972879] source can't be determined: dst=192.168.60.189 [ 11896.972799] source can't be determined: dst=192.168.60.189 [ 11897.972702] source can't be determined: dst=192.168.60.189 [ 11898.602649] source can't be determined: dst=192.168.60.194 [ 11941.628650] source can't be determined: dst=192.168.60.189 [ 11942.628556] source can't be determined: dst=192.168.60.189 [ 11943.628465] source can't be determined: dst=192.168.60.189 [ 11945.298311] source can't be determined: dst=192.168.60.194 -bash-5.2$ ifconfig -a wm0: flags=0x8843 mtu 1500 capabilities=0x7ff80 capabilities=0x7ff80 capabilities=0x7ff80 enabled=0 ec_capabilities=0x7 ec_enabled=0x2 address: 0c:c4:7a:33:2c:6c media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause) status: active inet6 fe80::ec4:7aff:fe33:2c6c%wm0/64 flags 0 scopeid 0x1 inet 192.168.60.238/24 broadcast 192.168.60.255 flags 0 inet 192.168.60.189/24 broadcast 192.168.60.255 flags 0 inet 192.168.60.194/24 broadcast 192.168.60.255 flags 0 wm1: flags=0x8802 mtu 1500 capabilities=0x7ff80 capabilities=0x7ff80 capabilities=0x7ff80 enabled=0 ec_capabilities=0x7 ec_enabled=0x2 address: 0c:c4:7a:33:2c:6d media: Ethernet autoselect (none) status: no carrier lo0: flags=0x8049 mtu 33624 status: active inet6 ::1/128 flags 0x20 inet6 fe80::1%lo0/64 flags 0 scopeid 0x3 inet 127.0.0.1/8 flags 0 cat /etc/if* 192.168.60.238 netmask 0xff00 media autoselect
Re: EXT MAIL : Re: USB install is slow
On Fri, Mar 08, 2024 at 08:18:14PM +, Derrick Lobo wrote: > Hi Thierry > > Manual untar seems fine no issues at all. This seems more like > copying the file between usb to the local drive as I see stalls when > the file is copied over But you said the time was spent in the download mostly - and I am totally confused what times you are comparing against which. The sets should be on the install usb medium, so no download is necessary. The download speed itself may vary widely and is totaly outside of our controll. When you say untarring the sets is fast, is that after copying them from the USB stick to hard disk or untarring from the USB source directly? Martin
Re: USB install is slow
Derrick Lobo wrote: Hi All I have noticed the USB install taking way too long anyone else noticed it Based on regular instructions I used the usb installer rawrite32 to create a usb install stick The installs for all netbsd10-rcx have been taking roughly 25 minutes, when I do an upgrade from 9.. with version 9.3 and below the upgrade via usb used to be until 5 minutes.. is this a bug or am I doing something wrong.. and has anyone else noticed this.. Derrick What kind of CPU do you have?
Re: dmesg error "source can't be determined: dst=x.x.x.x" for aliased address
On Fri, Mar 08, 2024 at 03:59:10PM +, Derrick Lobo wrote: > wm0: flags=0x8843 mtu 1500 [..] > inet6 fe80::ec4:7aff:fe33:2c6c%wm0/64 flags 0 scopeid 0x1 > inet 192.168.60.238/24 broadcast 192.168.60.255 flags 0 > inet 192.168.60.189/24 broadcast 192.168.60.255 flags 0 > inet 192.168.60.194/24 broadcast 192.168.60.255 flags 0 I have a very similar network setup running RC5 and working just fine. In my case the first address is added via "ifconfig $if $addr" and the additional ones via "ifconfig $if inet alias $addr" Martin
