Re: [gentoo-user] kworker using 100% cpu
On Tuesday, 5 March 2019 8:53:30 PM AEDT Mick wrote: > Hi Andreas, > > On Monday, 4 March 2019 19:44:19 GMT Andreas Fink wrote: > > Hello, > > I have a problem which uses 100% of one cpu core on my HP-15-bs114ng > > notebook. > > I had come across the same problem on a mid-2014 MacBook Pro: > > https://archives.gentoo.org/gentoo-user/message/ > 417dfa5af8e9fb76a66fe4816bdc7c44 > > > I figured out already that it is somehow related to ACPI > > interrupts, since the following command will return the system to normal: > > echo disable > /sys/firmware/acpi/interrupts/gpe16 > > Yes, I had to do the same and repeat after each boot. I can't recall if I > added this in a script so I didn't have to run it manually each time. /etc/sysctl.conf is interpreted at boot as an automatic way of doing this, instead of using hand made scripts. -- Reverend Paul Colquhoun, ULC. http://andor.dropbear.id.au/ Asking for technical help in newsgroups? Read this first: http://catb.org/~esr/faqs/smart-questions.html#intro
Re: [gentoo-user] KDE plasma upgrade heads up for possible problem
On 3/5/19 8:34 PM, Philip Webb wrote: 190305 Michael Cook wrote: On 3/5/19 7:47 PM, Dale wrote: I just did a KDE plasma upgrade to 5.15. I ran into a slight problem that may or may not affect others so I wanted to give a heads up -- snip -- Doing a revdep-rebuild.sh found the issue for me. Note the newer version of this script without .sh did not find the issue. So what was the actual problem & how did you solve it ?? Don't just leave us in suspense (sigh). /usr/lib64/qt5/qml/QtQuick/XmlListModel/libqmlxmllistmodelplugin.so (symbol _ZN3QV46Object12insertMemberEPNS_6StringEPKNS_8PropertyENS_18PropertyAttributesE version Qt_5_PRIVATE_API not defined in file libQt5Qml.so.5 with link time reference) dev-qt/qtxmlpatterns was also updated, must have built/linked against old libs due to using --jobs
Re: [gentoo-user] KDE plasma upgrade heads up for possible problem
Michael Cook wrote: > On 3/5/19 7:47 PM, Dale wrote: >> Howdy, >> >> I just did a KDE plasma upgrade to 5.15. I ran into a slight problem >> that may or may not affect others so I wanted to give a heads up just in >> case. Everything builds fine. I had no compile or install failures. >> What I did run into tho was a missing or more likely crashed >> kicker/panel/thingy that is at the bottom of my screen. It's the thing >> that has the clock, desktop switcher, clip board and the K menu as >> well. I never can remember what they call that this week. Anyway, when >> I logged in, it came up for just a second or two and then disappeared. >> Obviously, you can't switch desktops in the normal way but if you use >> the ctrl and functions keys, it doesn't act or look like it normally >> should since there doesn't appear to be any background at all. Example, >> I have Kpatience on desktop 6. If I switch to it with the ctrl function >> keys, I can play the game normally. However, if I switch to what at >> startup is a empty desktop, #5 for example, the game still shows but >> doesn't work. If I switch back to desktop 6, it works as it should >> again. Whatever it is, it doesn't redraw the screen when you switch if >> you don't have something already running there. Other programs behaved >> in a similar way. It makes it look like all desktops are on one desktop >> yet switching still works. It's plenty weird. Also, there is no K menu >> so you can't start any programs that doesn't open from a saved session >> on login. Trust me, if you run into this, you won't miss it. Even if >> you don't notice the panel thingy at the bottom missing, you will notice >> the rest. It gets in your face and yells loudly that something ain't >> right. lol >> >> What little bit of error I found mentioned something about a missing >> input. To be honest tho, I'm not sure it was related to what I saw >> happening. None of the errors looked like a complete failure but more >> as a informational type message. Sort of like video drivers that have >> the "--" or "II". They show something didn't work as expected but it >> found a way around it or works without it. >> >> I don't have enough info to file a bug. The way I fixed it, I did a >> emerge -e world. It might be that a emerge -ek would fix it but to be >> sure, I let it recompile everything. It didn't quite finish when I >> tried to login and it worked normally. If I had a clue what package it >> was that was causing this, I'd certainly file a bug but it could be any >> number of packages. I suspect it is a dependency myself. Something >> needed to be rebuilt but wasn't for some reason. >> >> I hope no one runs into this but if you do, make sure you at least have >> a back up GUI installed, even if it doesn't give you anything but the >> basics, at least you have a GUI. You may also want to make sure you >> have time to deal with this just in case you do run into this problem. >> Having something so you can go back to 5.14 easily may work as well. >> >> Best of luck to all. I hope no one else hits this. It was plenty >> weird. >> >> Dale >> >> :-) :-) >> >> > Doing a revdep-rebuild.sh found the issue for me. (Note the newer > version of this script without .sh did not find the issue) > > Dang, I forgot about that command. I may could have used that and had the info needed to file a bug report so that the ebuild could be changed/updated. That may prevent others from getting stuck. I haven't used that command in a long long time. It's been years I would guess. Maybe that will help others if they run into this. Dale :-) :-)
Re: [gentoo-user] KDE plasma upgrade heads up for possible problem
190305 Michael Cook wrote: > On 3/5/19 7:47 PM, Dale wrote: >> I just did a KDE plasma upgrade to 5.15. I ran into a slight problem > > that may or may not affect others so I wanted to give a heads up -- snip -- > Doing a revdep-rebuild.sh found the issue for me. > Note the newer version of this script without .sh did not find the issue. So what was the actual problem & how did you solve it ?? Don't just leave us in suspense (sigh). -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] KDE plasma upgrade heads up for possible problem
On 3/5/19 7:47 PM, Dale wrote: Howdy, I just did a KDE plasma upgrade to 5.15. I ran into a slight problem that may or may not affect others so I wanted to give a heads up just in case. Everything builds fine. I had no compile or install failures. What I did run into tho was a missing or more likely crashed kicker/panel/thingy that is at the bottom of my screen. It's the thing that has the clock, desktop switcher, clip board and the K menu as well. I never can remember what they call that this week. Anyway, when I logged in, it came up for just a second or two and then disappeared. Obviously, you can't switch desktops in the normal way but if you use the ctrl and functions keys, it doesn't act or look like it normally should since there doesn't appear to be any background at all. Example, I have Kpatience on desktop 6. If I switch to it with the ctrl function keys, I can play the game normally. However, if I switch to what at startup is a empty desktop, #5 for example, the game still shows but doesn't work. If I switch back to desktop 6, it works as it should again. Whatever it is, it doesn't redraw the screen when you switch if you don't have something already running there. Other programs behaved in a similar way. It makes it look like all desktops are on one desktop yet switching still works. It's plenty weird. Also, there is no K menu so you can't start any programs that doesn't open from a saved session on login. Trust me, if you run into this, you won't miss it. Even if you don't notice the panel thingy at the bottom missing, you will notice the rest. It gets in your face and yells loudly that something ain't right. lol What little bit of error I found mentioned something about a missing input. To be honest tho, I'm not sure it was related to what I saw happening. None of the errors looked like a complete failure but more as a informational type message. Sort of like video drivers that have the "--" or "II". They show something didn't work as expected but it found a way around it or works without it. I don't have enough info to file a bug. The way I fixed it, I did a emerge -e world. It might be that a emerge -ek would fix it but to be sure, I let it recompile everything. It didn't quite finish when I tried to login and it worked normally. If I had a clue what package it was that was causing this, I'd certainly file a bug but it could be any number of packages. I suspect it is a dependency myself. Something needed to be rebuilt but wasn't for some reason. I hope no one runs into this but if you do, make sure you at least have a back up GUI installed, even if it doesn't give you anything but the basics, at least you have a GUI. You may also want to make sure you have time to deal with this just in case you do run into this problem. Having something so you can go back to 5.14 easily may work as well. Best of luck to all. I hope no one else hits this. It was plenty weird. Dale :-) :-) Doing a revdep-rebuild.sh found the issue for me. (Note the newer version of this script without .sh did not find the issue)
[gentoo-user] KDE plasma upgrade heads up for possible problem
Howdy, I just did a KDE plasma upgrade to 5.15. I ran into a slight problem that may or may not affect others so I wanted to give a heads up just in case. Everything builds fine. I had no compile or install failures. What I did run into tho was a missing or more likely crashed kicker/panel/thingy that is at the bottom of my screen. It's the thing that has the clock, desktop switcher, clip board and the K menu as well. I never can remember what they call that this week. Anyway, when I logged in, it came up for just a second or two and then disappeared. Obviously, you can't switch desktops in the normal way but if you use the ctrl and functions keys, it doesn't act or look like it normally should since there doesn't appear to be any background at all. Example, I have Kpatience on desktop 6. If I switch to it with the ctrl function keys, I can play the game normally. However, if I switch to what at startup is a empty desktop, #5 for example, the game still shows but doesn't work. If I switch back to desktop 6, it works as it should again. Whatever it is, it doesn't redraw the screen when you switch if you don't have something already running there. Other programs behaved in a similar way. It makes it look like all desktops are on one desktop yet switching still works. It's plenty weird. Also, there is no K menu so you can't start any programs that doesn't open from a saved session on login. Trust me, if you run into this, you won't miss it. Even if you don't notice the panel thingy at the bottom missing, you will notice the rest. It gets in your face and yells loudly that something ain't right. lol What little bit of error I found mentioned something about a missing input. To be honest tho, I'm not sure it was related to what I saw happening. None of the errors looked like a complete failure but more as a informational type message. Sort of like video drivers that have the "--" or "II". They show something didn't work as expected but it found a way around it or works without it. I don't have enough info to file a bug. The way I fixed it, I did a emerge -e world. It might be that a emerge -ek would fix it but to be sure, I let it recompile everything. It didn't quite finish when I tried to login and it worked normally. If I had a clue what package it was that was causing this, I'd certainly file a bug but it could be any number of packages. I suspect it is a dependency myself. Something needed to be rebuilt but wasn't for some reason. I hope no one runs into this but if you do, make sure you at least have a back up GUI installed, even if it doesn't give you anything but the basics, at least you have a GUI. You may also want to make sure you have time to deal with this just in case you do run into this problem. Having something so you can go back to 5.14 easily may work as well. Best of luck to all. I hope no one else hits this. It was plenty weird. Dale :-) :-)
Re: [gentoo-user] Question about bird init script
On 3/5/19 11:24 AM, Alarig Le Lay wrote:
>
> The client doesn’t care about the configuration file, only about the
> socket.
Oh, sorry, I was reading the wrong part of the man page.
It looks like you *can* specify which config file to check, but in a
different way:
configure check ["config file"]
Read and parse given config file, but do not use it. useful for
checking syntactic and some semantic validity of an config file.
So you'd want something like "configure check ${CONF_FILE}" I guess.
That way if you ever have two instances of bird running, reloading the
second instance won't check the config file for the first instance.
And "-r" was a good idea.
Re: [gentoo-user] Question about bird init script
Thanks for you help!
I just did one think differently, I explain it inline.
I will run bird 2.0.4 on my lab for the rest of the week, then I will
upgrade the production network gradually. I will propose my script to
the tree if it all succeeds.
On mar. 5 mars 10:01:08 2019, Michael Orlitzky wrote:
> On 3/5/19 6:03 AM, Alarig Le Lay wrote:
> > Okay, I tried to write another script:
> > https://git.grifon.fr/alarig/SwordArMor-gentoo-overlay/src/branch/master/net-misc/bird/files/initd-bird-2
> >
> > I deleted things, but added others. I’m not sure if I respect all the
> > openrc standards as I’m not very comfortable with it.
>
> That's OK, it already looks a lot better. And it works, which is nice =)
Hehe :)
> You probably want to specify the config file in check_run(). You might
> refactor the command_args as follows,
>
> client_args="-c ${CONF_FILE} -s ${SOCK}"
> command_args="${client_args} -P ${pidfile}"
>
> and then in check_run, you can use "birdc ${client_args}..."
The client doesn’t care about the configuration file, only about the
socket. However, I factored the socket and then added -r to restrict
read-only commands, in order to avoid protocol disabling during the
check.
“Option -r can be used to enable a restricted mode of BIRD client, which
allows just read-only commands (show ...).”
-- https://bird.network.cz/?get_doc&v=20&f=bird-4.html
client_args="-s ${SOCK}"
command_args="${client_args} -c ${CONF_FILE} -P ${pidfile}"
client_args="${client_args} -r"
I also factored my `birdc config check` command in check_run().
--
Alarig
Re: [gentoo-user] Question about bird init script
On 3/5/19 6:03 AM, Alarig Le Lay wrote:
> Okay, I tried to write another script:
> https://git.grifon.fr/alarig/SwordArMor-gentoo-overlay/src/branch/master/net-misc/bird/files/initd-bird-2
>
> I deleted things, but added others. I’m not sure if I respect all the
> openrc standards as I’m not very comfortable with it.
That's OK, it already looks a lot better. And it works, which is nice =)
>
> I added a check_run() function because I want to use the bird config
> parser if it’s running.
You probably want to specify the config file in check_run(). You might
refactor the command_args as follows,
client_args="-c ${CONF_FILE} -s ${SOCK}"
command_args="${client_args} -P ${pidfile}"
and then in check_run, you can use "birdc ${client_args}..."
>
> I added my own stop() function because bird has to wait for all the
> sessions to be closed before killing the process.
There's a "retry" variable that you can set at the top-level:
retry Retry schedule to use when stopping the daemon. It can
either be a timeout in seconds or multiple signal/time‐
out pairs (like SIGTERM/5).
(from "man openrc-run")
The default stop() function will use that, so you shouldn't need to
write your own stop() if you set "retry=15".
>
> I’m open to your comments and improvements :)
>
The checkconfig() function isn't used any more, so it can be deleted. So
long as bird crashes with an error like "no config file!" when the file
is missing, I don't think you need to check for it yourself.
These days /var/run is simply a symlink to /run, so those two paths can
be shortened.
Once you've used it for a while and are confident that everything works,
please file a bug to include the improved script in the tree!
Re: [gentoo-user] Question about bird init script
Okay, I tried to write another script: https://git.grifon.fr/alarig/SwordArMor-gentoo-overlay/src/branch/master/net-misc/bird/files/initd-bird-2 I deleted things, but added others. I’m not sure if I respect all the openrc standards as I’m not very comfortable with it. I added a check_run() function because I want to use the bird config parser if it’s running. I added my own stop() function because bird has to wait for all the sessions to be closed before killing the process. I don’t know if I should make the configuration file and the sock file configurable with /etc/conf.d/bird I’m open to your comments and improvements :) My script behave like this: judicael-ovpn2 ~ # ps aux | grep bird root 3928 0.0 0.3 25752 7944 pts/1S+ Mar04 0:04 vim /etc/init.d/bird root 5250 0.0 0.1 10860 2052 pts/3S+ 11:31 0:00 grep --colour=auto bird judicael-ovpn2 ~ # rc-service bird start * Starting bird ... [ ok ] judicael-ovpn2 ~ # ps aux | grep bird root 3928 0.0 0.3 25752 7944 pts/1S+ Mar04 0:04 vim /etc/init.d/bird root 5383 62.8 1.8 42184 37080 ?Rs 11:31 0:03 /usr/sbin/bird -c /etc/bird.conf -s /var/run/bird.ctl -P /var/run/bird.pid root 5400 0.0 0.1 10860 2236 pts/3S+ 11:31 0:00 grep --colour=auto bird judicael-ovpn2 ~ # birdc 'sh pr' BIRD 2.0.4 ready. Name Proto Table State Since Info device1Device ---up 11:31:26.782 direct1Direct ---up 11:31:26.782 kernel_ipv4 Kernel master4up 11:31:26.782 kernel_ipv6 Kernel master6up 11:31:26.782 ibgp_nominoe_ipv4 BGP---up 11:31:28.777 Established ibgp_nominoe_ipv6 BGP---up 11:31:28.205 Established ibgp_budic_ipv4 BGP---up 11:31:30.703 Established ibgp_budic_ipv6 BGP---up 11:31:28.614 Established ospf_ipv4 OSPF master4up 11:31:26.782 Running ospf_ipv6 OSPF master6up 11:31:26.782 Running judicael-ovpn2 ~ # rc-service bird reload * Reloading BIRD ... [ ok ] judicael-ovpn2 ~ # rc-service bird restart * Stopping BIRD ... * Starting bird ... [ ok ] judicael-ovpn2 ~ # rc-service bird status * status: started So basically it works, and the error check as well: judicael-ovpn2 ~ # echo 'ezf' >> /etc/bird.conf judicael-ovpn2 ~ # rc-service bird reload * /etc/bird.conf:121:1 syntax error, unexpected SYM judicael-ovpn2 ~ # rc-service bird restart * Caching service dependencies ... [ ok ] * /etc/bird.conf:121:1 syntax error, unexpected SYM * ERROR: bird failed to stop judicael-ovpn2 ~ # sed -i '$d' /etc/bird.conf judicael-ovpn2 ~ # rc-service bird reload * Reloading BIRD ... [ ok ] -- Alarig
Re: [gentoo-user] kworker using 100% cpu
Hi Andreas, On Monday, 4 March 2019 19:44:19 GMT Andreas Fink wrote: > Hello, > I have a problem which uses 100% of one cpu core on my HP-15-bs114ng > notebook. I had come across the same problem on a mid-2014 MacBook Pro: https://archives.gentoo.org/gentoo-user/message/ 417dfa5af8e9fb76a66fe4816bdc7c44 > I figured out already that it is somehow related to ACPI > interrupts, since the following command will return the system to normal: > echo disable > /sys/firmware/acpi/interrupts/gpe16 Yes, I had to do the same and repeat after each boot. I can't recall if I added this in a script so I didn't have to run it manually each time. > The content of this "file" is the following: > 3749821 STS disabled unmasked > > The first column is the number of interrupts, that happened, which is very > high, hence the 100% cpu usage in one kworker process. > > My question would be the following now: > 1. What could be the side effects of disabling this interrupt? I did not discover any side effects. The CPU would return back to normal and the overheating problem went away. This does not mean some key functionality was not affected, but I never discovered anything relevant. I did not debug the kernel at the time to bottom out what exactly caused this. > 2. What could trigger the interrupt? I don't know. I only had this MacBook Pro for a few months, so I never got to the bottom of it. > 3. How can this be debugged further and reported, i.e. who would be able to > fix it? Have a look here: https://lkml.org/lkml/2011/3/31/144 Then it will need to be reported to BGO and perhaps upstream to kernel devs. > (This happens on all kernels, since I have the notebook, i.e. >= 4.17) If your HP notebook's MoBo or CPU are similar to my 2014 MacBook Pro, then this has been a problem at least since the 3.x series kernel. I hope you get to the bottom of it. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
