Re: [gentoo-user] emerge times blown out
Adam Carter wrote: > > Does that info help? > > > My reason for asking is that i'm seeing this across multiple systems, > 2 AMD, 1 Intel, who's configuration hasn't really changed and while > there is some variance there has been a step change late December / > early January. Another example > > Sat Nov 26 14:34:50 2022 >>> sys-apps/systemd-252.2 > merge time: 2 minutes and 19 seconds. > > Sat Dec 10 20:59:29 2022 >>> sys-apps/systemd-252.3 > merge time: 1 minute and 54 seconds. > > Wed Dec 14 13:56:52 2022 >>> sys-apps/systemd-252.3 > merge time: 2 minutes and 56 seconds. > > Wed Dec 21 20:08:36 2022 >>> sys-apps/systemd-252.4 > merge time: 3 minutes and 7 seconds. > > Tue Jan 3 22:29:43 2023 >>> sys-apps/systemd-252.4 > merge time: 12 minutes and 42 seconds. > > Thu Jan 12 14:56:32 2023 >>> sys-apps/systemd-252.4-r1 > merge time: 22 minutes and 12 seconds. > > Sat Jan 21 12:00:06 2023 >>> sys-apps/systemd-252.4-r1 > merge time: 12 minutes and 3 seconds. > > Mon Jan 30 15:41:44 2023 >>> sys-apps/systemd-252.5 > merge time: 21 minutes and 45 seconds. > > Fri Feb 17 21:18:21 2023 >>> sys-apps/systemd-252.6 > merge time: 22 minutes and 18 seconds. The ones I listed before also jumped in compile times. As I said tho, I don't know if other things compiling affected that time. Still, it does seem to have increased but I remember when I was on my old single core rig with just a few GBs of memory. As time goes by, software gets bigger therefore takes longer to compile. Yours from the 4th to the 6th in the list sure does increase. That's 8 to 10 times longer roughly. That's a large difference. A true test, emerge something interesting all by itself. See what it comes closest to, the old times or the newer and longer times. I suspect this is changes in features of software and could even be related to gcc or some other tool compiling uses. It is a interesting jump. I don't think you are alone in this. Maybe someone else will post their info. For those interested, genlop -t is how to get this info. BTW, I don't use systemd so I can't list mine. ;-) Dale :-) :-)
Re: [gentoo-user] emerge times blown out
> > Does that info help? > > My reason for asking is that i'm seeing this across multiple systems, 2 AMD, 1 Intel, who's configuration hasn't really changed and while there is some variance there has been a step change late December / early January. Another example Sat Nov 26 14:34:50 2022 >>> sys-apps/systemd-252.2 merge time: 2 minutes and 19 seconds. Sat Dec 10 20:59:29 2022 >>> sys-apps/systemd-252.3 merge time: 1 minute and 54 seconds. Wed Dec 14 13:56:52 2022 >>> sys-apps/systemd-252.3 merge time: 2 minutes and 56 seconds. Wed Dec 21 20:08:36 2022 >>> sys-apps/systemd-252.4 merge time: 3 minutes and 7 seconds. Tue Jan 3 22:29:43 2023 >>> sys-apps/systemd-252.4 merge time: 12 minutes and 42 seconds. Thu Jan 12 14:56:32 2023 >>> sys-apps/systemd-252.4-r1 merge time: 22 minutes and 12 seconds. Sat Jan 21 12:00:06 2023 >>> sys-apps/systemd-252.4-r1 merge time: 12 minutes and 3 seconds. Mon Jan 30 15:41:44 2023 >>> sys-apps/systemd-252.5 merge time: 21 minutes and 45 seconds. Fri Feb 17 21:18:21 2023 >>> sys-apps/systemd-252.6 merge time: 22 minutes and 18 seconds.
Re: [gentoo-user] emerge times blown out
Adam Carter wrote: > I have three systems (all ~arch) and the emerge times have blown out > on all of them across all packages. Worst example appears to be; > > Fri Dec 23 13:11:44 2022 >>> net-libs/webkit-gtk-2.38.3-r410 > merge time: 37 minutes and 8 seconds. > > Fri Dec 23 13:43:08 2022 >>> net-libs/webkit-gtk-2.38.3 > merge time: 31 minutes and 24 seconds. > > Sat Feb 4 21:16:40 2023 >>> net-libs/webkit-gtk-2.38.4-r410 > merge time: 6 hours, 53 minutes and 28 seconds. > > Sun Feb 5 04:17:12 2023 >>> net-libs/webkit-gtk-2.38.4 > merge time: 7 hours and 32 seconds. > > Is anyone else seeing this? A lot of this will obviously depend on CPU speed, number of cores/threads, amount of memory and also, is it compiling on its own or are other packages also being compiled and taking up CPU time or other things using CPU time as well. Here, AMD CPU at 4GHz with 8 cores. 32GBs of memory and most packages built on tmpfs, except large packages. This is a recent few examples. Sat Aug 6 06:34:31 2022 >>> net-libs/webkit-gtk-2.36.5-r1 merge time: 1 hour, 39 minutes and 13 seconds. Sun Aug 21 16:04:23 2022 >>> net-libs/webkit-gtk-2.36.6 merge time: 3 hours, 41 minutes and 44 seconds. Sat Sep 3 22:29:36 2022 >>> net-libs/webkit-gtk-2.36.7 merge time: 2 hours, 41 minutes and 7 seconds. I left out binary emerges and such. Oldest at top, newest at bottom. I suspect for the middle and most likely the bottom one, there was another package compiling as well. It's possible the top one was either on its own part or all of the time. It's really hard to compare these things. Even if our rigs are close in speed/power/whatever, there can still be a lot of things that affect the compile time. I run KDE, watch TV from computer, have torrent software that runs basically 24/7 plus other stuff running. If you for example use Fluxbox and have little else running, even with the same CPU and memory, compile times will vary. Does that info help? Dale :-) :-)
[gentoo-user] emerge times blown out
I have three systems (all ~arch) and the emerge times have blown out on all of them across all packages. Worst example appears to be; Fri Dec 23 13:11:44 2022 >>> net-libs/webkit-gtk-2.38.3-r410 merge time: 37 minutes and 8 seconds. Fri Dec 23 13:43:08 2022 >>> net-libs/webkit-gtk-2.38.3 merge time: 31 minutes and 24 seconds. Sat Feb 4 21:16:40 2023 >>> net-libs/webkit-gtk-2.38.4-r410 merge time: 6 hours, 53 minutes and 28 seconds. Sun Feb 5 04:17:12 2023 >>> net-libs/webkit-gtk-2.38.4 merge time: 7 hours and 32 seconds. Is anyone else seeing this?
Re: [gentoo-user] Re: my 5.15.93 kernel keeps rebooting
My problem is that the sender aborts netconsole, so there is nothing to receive. On Fri, 17 Feb 2023 15:13:52 -0500, Mark Knecht wrote: > > [1 ] > On Fri, Feb 17, 2023 at 12:03 PM John Covici wrote: > > > Well, some progress, but no joy. I found actual messages from > > netconsole and it seems no matter what device I put for the source, > > netconsole says it doesn't exist. I tried my eno1, and also eth0 and > > eth1. In my normal boot sequence, I see that udev renamed eth1 to > > eno1, but netconsole still said it does not exist. So, I may have to > > use the serial console method, I have to find my cables for that. I > > did also try to add net.ifnames=0 to my boot options, but no joy > > there. > > > > -- > > Your life is like a penny. You're going to lose it. The question is: > > How do > > you spend it? > > > > John Covici wb2una > > cov...@ccs.covici.com > > John, >I did a bad job at trying to point you in this direction the other day, > and in my testing I'm not sure how well it works. However another > option you might investigate is on the receiving end you can > apparently set the transmitter's IP address by using the > transmitter's mac address. Supposedly you would execute > something like the following, with extra spaces added > for readability: > > sudo arp -s 192.168.86.244 90:e6:ba:10:a3:e7 temp > > which supposedly says 'when you see a packet with this > mac address associate it with this IP address'. The temp > part says don't add it to the permanent tables. > > After executing this you are supposed to be able to use tools > that filter by IP address but I didn't have great results. > > Hope this helps, > Mark > [2 ] -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
Re: [gentoo-user] Re: my 5.15.93 kernel keeps rebooting
On Fri, Feb 17, 2023 at 12:03 PM John Covici wrote: > Well, some progress, but no joy. I found actual messages from > netconsole and it seems no matter what device I put for the source, > netconsole says it doesn't exist. I tried my eno1, and also eth0 and > eth1. In my normal boot sequence, I see that udev renamed eth1 to > eno1, but netconsole still said it does not exist. So, I may have to > use the serial console method, I have to find my cables for that. I > did also try to add net.ifnames=0 to my boot options, but no joy > there. > > -- > Your life is like a penny. You're going to lose it. The question is: > How do > you spend it? > > John Covici wb2una > cov...@ccs.covici.com John, I did a bad job at trying to point you in this direction the other day, and in my testing I'm not sure how well it works. However another option you might investigate is on the receiving end you can apparently set the transmitter's IP address by using the transmitter's mac address. Supposedly you would execute something like the following, with extra spaces added for readability: sudo arp -s 192.168.86.244 90:e6:ba:10:a3:e7 temp which supposedly says 'when you see a packet with this mac address associate it with this IP address'. The temp part says don't add it to the permanent tables. After executing this you are supposed to be able to use tools that filter by IP address but I didn't have great results. Hope this helps, Mark
Re: [gentoo-user] Re: my 5.15.93 kernel keeps rebooting
On Thu, 16 Feb 2023 12:37:51 -0500, Laurence Perkins wrote: > > > > >-Original Message- > >From: John Covici > >Sent: Wednesday, February 15, 2023 7:20 AM > >To: gentoo-user@lists.gentoo.org > >Subject: Re: [gentoo-user] Re: my 5.15.93 kernel keeps rebooting > > > >On Wed, 15 Feb 2023 09:50:27 -0500, > >Grant Edwards wrote: > >> > >> On 2023-02-14, Rich Freeman wrote: > >> > >> > Where are you getting this from, the system log/journal? This > >> > doesn't seem like a clean shutdown, so if it is a kernel PANIC I > >> > wouldn't expect the most critical info to be in the log (since it > >> > will stop syncing to protect the filesystem). The details you need > >> > probably will be displayed on the console briefly. You can also > >> > enable a network console, which will send the dmesg output > >> > continuously over UDP to another device. This won't be interrupted > >> > by a PANIC unless there is some issue with the hardware or networking > >> > stack. > >> > >> If you've got a serial port[1], you could also set up serial logging. > >> Though using serial ports have become a bit of a lost art, the serial > >> console code in the kernel is pretty carefully designed to be the last > >> man standing when things start to die. It's possible (though I > >> wouldn't say probable) that a serial console will be able to show you > >> stuff closer to the event horizon than a network console can. > >> > >> Anyway, since still I'm in the serial port business (yes, there are > >> still plenty of people using serial ports in industrial settings) I > >> had to mention it... > >> > >> [1] For this purpose you want a plain old UART on the motherboard type > >> seial port. You'd be surprised how many motherboards still have > >> them. Even though they're never brought out to a DB9 connector on > >> the back panel, there's often an 8-pin header on the edge of the > >> board somewhere, so you'd need one of these: > >> > >> > >> https://www.amazon.com/C2G-27550-Adapter-Bracket-Motherboards/dp/B0002 > >> J27R8/ > > > >I do have one which I use for my speech synthesizer. I also have one on my > >other box which I could hook up -- if I can find my null modem cable. I > >think I will try the netconsole first and the serial console if that does > >not work. > > > >Thanks for the hint. > > > > > https://wiki.gentoo.org/wiki/Kernel_Crash_Dumps is another option if you're > somehow not getting enough information out of the console. More complex to > set up, but you can take an actual debugger to the result and hopefully find > out exactly what's going on. Well, some progress, but no joy. I found actual messages from netconsole and it seems no matter what device I put for the source, netconsole says it doesn't exist. I tried my eno1, and also eth0 and eth1. In my normal boot sequence, I see that udev renamed eth1 to eno1, but netconsole still said it does not exist. So, I may have to use the serial console method, I have to find my cables for that. I did also try to add net.ifnames=0 to my boot options, but no joy there. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
