On 03/17/2016 08:36 AM, Bjoern Voigt wrote:

Anton Aylward wrote:

...

regular readers will recall that I've mentioned before:

I'm on 13.1 and few leading repositories, one of which is Kernel_Stable. [....]

I'd advise anyone who has the spare resources or inclination to try the 4.x series kernels. At the very least, they have updates to BtrFS that offer stability an improvement over the 3.x series.

I am happy with the Kernel:stable repository on x86_64 since many years and especially with Kernel 4.5 too.

32Bit users currently should not use the Kernel:stable repository. The kernels are broken and will not boot on 32Bit openSUSE installations as reported here: https://bugzilla.suse.com/show_bug.cgi?id=971385

A bugfix is currently prepared here: https://bugzilla.suse.com/show_bug.cgi?id=970239

Thank you for that. My collection of SPF discardware i586 machines ave been off net while I try to get them to do VM-things that they weren't built for :-) I'll defer putting them back on-net for a while :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/03/16 02:24, Per Jessen wrote:

Anton Aylward wrote:

...

regular readers will recall that I've mentioned before:

I'm on 13.1 and few leading repositories, one of which is Kernel_Stable.

I've just upgraded to 4.5 and yes it is an improvement in many ways. Funny, in the last 30min I've also just installed 4.5, but saw no immediate improvements :-) I had hoped it might fix my graphics problem.

I've been using 4.5 for the past few days -- or since it became available -- and I haven't noticed any whizz-bang, super-dooper speed-ups :-) . "Its' all in the mind, you know." as the announcer used to say at the end of an episode of _The Goon Show_ starring Harry Secombe, Peter Sellers and Spike Milligan :-) . BC -- Using openSUSE 13.2, KDE 4.14.9 & kernel 4.5.0-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 03/18/2016 06:06 AM, Basil Chupin wrote:

...

On 18/03/16 02:24, Per Jessen wrote:

...

Anton Aylward wrote:

...

regular readers will recall that I've mentioned before:

I'm on 13.1 and few leading repositories, one of which is Kernel_Stable.

I've just upgraded to 4.5 and yes it is an improvement in many ways. Funny, in the last 30min I've also just installed 4.5, but saw no immediate improvements :-) I had hoped it might fix my graphics problem.

I've been using 4.5 for the past few days -- or since it became available -- and I haven't noticed any whizz-bang, super-dooper speed-ups :-) .

I don't think anyone claimed there was "whizz-bang, super-dooper speed-ups".

Kinda depends on how one interprets $SUBJ :-) -- Per Jessen, Zürich (8.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/03/16 22:37, Anton Aylward wrote:

On 03/18/2016 07:28 AM, Per Jessen wrote:

...

Anton Aylward wrote:

...

I don't think anyone claimed there was "whizz-bang, super-dooper speed-ups". Kinda depends on how one interprets $SUBJ :-) For some of us, stability (in its various guises[1]) is important as well.

[1] e.g reliability, predictability, stability

But what about Liberty, Equality and Fraternity? BC -- Using openSUSE 13.2, KDE 4.14.9 & kernel 4.5.0-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/03/16 21:36, Anton Aylward wrote:

...

On 18/03/16 02:24, Per Jessen wrote:

...

Anton Aylward wrote:

...

regular readers will recall that I've mentioned before:

I'm on 13.1 and few leading repositories, one of which is Kernel_Stable.

I've just upgraded to 4.5 and yes it is an improvement in many ways. Funny, in the last 30min I've also just installed 4.5, but saw no immediate improvements :-) I had hoped it might fix my graphics problem. I've been using 4.5 for the past few days -- or since it became available -- and I haven't noticed any whizz-bang, super-dooper speed-ups :-) . I don't think anyone claimed there was "whizz-bang, super-dooper speed-ups". Perhaps over the 3.x series, as many kernel locks have been either improved or eliminated in favour of smoother networking, smoother

On 03/18/2016 06:06 AM, Basil Chupin wrote: process switching. There's a series of gradual but systemic improvements. Many are for specific hardware.

In general terms I am sure that I am going to disagree with you. But I will just add this one little point: when Leap of Faith was introduced also came the change in the kernel which went from kernel-desktop to desktop-default, and that time there were statements made in the kernel related lists that nobody should (hopefully) notice the change in the kernel. Well, from my point of view *I* have noticed the change in the way the kernel behaves. Perhaps not too mind-bogling for most people, but I have noticed that when compiling/installing the nVidia driver to suit a newly installed kernel the compiler/installer "hiccups" a couple of times whereas before the change from -dedktop to -default the start of the compilation/installation process was fast and smooth and without any "hiccups". BC -- Using openSUSE 13.2, KDE 4.14.9 & kernel 4.5.0-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 18.03.2016 um 13:42 schrieb Anton Aylward:

There has always been a debate over this, it goes along way back.

I noticed that UI applications hang for a few seconds when there is a lot of disk activity. Some of those are games, where it's a PITA. How can I reduce priority for I/O operations? Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dne neděle 20. března 2016 0:31:03 CET, Anton Aylward napsal(a):

On 03/19/2016 06:25 PM, Aaron Digulla wrote:

...

Am 18.03.2016 um 13:42 schrieb Anton Aylward:

...

There has always been a debate over this, it goes along way back.

I noticed that UI applications hang for a few seconds when there is a lot of disk activity. Some of those are games, where it's a PITA.

How can I reduce priority for I/O operations?

Why is there disk activity?

If the disk activity is the game itself causing the activity, possibly because it is paging or its access a database for image, texture or a temp file as part of its rendering, then reducing the disk IO priority will be counter-productive. In fact you might want to increase that so as to make the game more responsive.

Then again, maybe you need more real memory or a GPU with more memory or a better/different graphics driver, or have x11 configured differently for the driver you do have.

If its some other background process you might look to see if that process is needed. You might be able to justify, for example, disabling CRON, or not allowing incoming email to be accepted and processed.

If You are on KDE4/5 and You have Baloo running, turn it off temporally (balooctl stop; kilall -SIGTERM baloo_file; killall -SIGTERM baloo_file_extractor) or forever (balooctl disable). Or suffer and let it run overnight until the indexing is done. It can cause huge I/O and cause other applications to hang terribly. When files are indexed, it is not that terrible.

There are various tools available to determine what is going on in the machine, many of them, but which one to use and how to interpret the results gets into the realm of TL;DR and maybe you need to visit the Web for all that.

ps, vmstat, nice, htop, fuser, lsof, iotop, iostat, ionice -- Vojtěch Zeisek

Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/

On 03/20/2016 03:45 PM, John Andersen wrote:

Don't paint Baloo with Nepomuk's paintbrush.

+1 Use actual measurements. Look to the evidence. There are, as I've said, tools that will let you see what IO is *really* going on, what processes are doing IO. Make use of them. Take action based on evidence. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 20.03.2016 um 05:31 schrieb Anton Aylward:

On 03/19/2016 06:25 PM, Aaron Digulla wrote:

...

Am 18.03.2016 um 13:42 schrieb Anton Aylward:

...

There has always been a debate over this, it goes along way back. I noticed that UI applications hang for a few seconds when there is a lot of disk activity. Some of those are games, where it's a PITA.

How can I reduce priority for I/O operations? Why is there disk activity?

I was restoring 100+ GB from a backup. I'd prefer is the process with the focus wouldn't get disturbed by other processes. That feels like a good heuristic. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/20/2016 03:39 PM, Aaron Digulla wrote:

I'd prefer is the process with the focus wouldn't get disturbed by other processes. That feels like a good heuristic.

In absolute terms what you're asking for is OS8, CP/M, or early MS-DOS, that is a single talks "operating system'. In the days of the TTY a single user UNIX would give priority to keybaord interrupts, and in the return from the interrupt the scheduler would let the process blocked waiting for the keystroke (an editor perhaps) wake up and process the input. Those days are long gone. By the time the Consent Decree let UNIX source be available and ported to the early 16-bit micros UNIX was already doing a lot of multi-tasking. Cron was running; it was supporting email scheduling, certainly UUCP, perhaps some form of networking - that was definite even for BSD by the begining of the 1980s. That was 30 years ago or more. Try running 'ps' right now to see how many processes and threads your machine is handling. # ps -ef | wc -l 314 # ps -uanton | wc -l 60 And that latter figure is with only FOUR actual user applications running under KDE .. well five if you count this edit window separately. Occasionally Thunderbird will wake up for each of the accounts i have and check to see if there is more mail waiting. That's more IO. So really what you're asking for is a single tasking OS. Well perhaps that's what you do have. Perhaps you only have a singe CPU/core and it can do only one thing at a time and the scheduler has it switching backwards and forwards. "Faster than the eye can see." Perhaps you could explain why you were playing a game while restoring a 100K backup? Do you do this often? Is that why its something critical? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/21/2016 08:10 AM, Dave Howorth wrote:

On 2016-03-20 20:25, Anton Aylward wrote:

...

In the days of the TTY a single user UNIX would give priority to keybaord interrupts, and in the return from the interrupt the scheduler would let the process blocked waiting for the keystroke (an editor perhaps) wake up and process the input.

Those days are long gone. By the time the Consent Decree let UNIX source be available and ported to the early 16-bit micros UNIX was already doing a lot of multi-tasking.

I'm not sure what you meant here. It seems to imply there was a time when UNIX was not multitasking, let alone multiuser. When was that?

Even UNICS was multiprocessing, wasn't it?

I'm not sure about UNICS, but UNIX was multi-user/multi-tasking right from the start, as far as I know. My first experience was with SysV-R2 in the early 1980's, if memory serves, and it supported multiple users via RS-232 connected CRT's. It was even real-time (MASSCOMP) and had a bank of A/D and D/A converters. Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/21/2016 11:10 AM, Dave Howorth wrote:

On 2016-03-20 20:25, Anton Aylward wrote:

...

In the days of the TTY a single user UNIX would give priority to keybaord interrupts, and in the return from the interrupt the scheduler would let the process blocked waiting for the keystroke (an editor perhaps) wake up and process the input.

Those days are long gone. By the time the Consent Decree let UNIX source be available and ported to the early 16-bit micros UNIX was already doing a lot of multi-tasking.

I'm not sure what you meant here. It seems to imply there was a time when UNIX was not multitasking, let alone multiuser. When was that?

In absolute terms, yes, probably V1 or V2. The point I'm trying to make is that the Linux we run today is a long way removed from the UNIX that the public first say back in the 1970s. We're running a LOT of other threads and processes, we're networked and dealing with other IO sources. We're dealing with a lot more asynchronous events. The V6/v7 UNIX was very simple. You only have to read the Lyon's book to appreciate that. We can argue about the differences between multi-tasking and multi-processing, but lets recall to start with that even back in the days of PC-DOS 1.1 there was a add-in that sat on the keyboard interrupt vector that let something else run while waiting for a keystroke. The real difference between that and UNIX V6/V7 was that UNIX had a proper scheduler and process priority queue and saved task state and could dynamically create (and destroy) processes while others were running. That's REAL multiprocessing! All DOS had was the Transient Programme Area and a primitive loader. A one-at-a-time approach. That model dates back to OS8 and to a large degree DEC continued that though into the VAX, where, in effect, there was a 'stack' of TPAs. we saw a similar thing with some S-100 machines based around the 8080 and Z80 where the 'stack' was switched by hardware. The virtual memory just added a layer on top of that. IIR VAX really wasn't good at dynamic process creation/destruction. You had to have a special privileged for that, whereas the fork and/or execl is quite normal in UNIX/Linux.

Even UNICS was multiprocessing, wasn't it?

Do you mean MULTICS? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/21/2016 12:58 PM, Dave Howorth wrote:

[ Big Snip ]

and one of the first components to be built, before the operating system (UNICS) was completed, was the notion of process. Ritchie may explain what you're talking about when he says the machine was not multiprogrammed, meaning that it swapped out one program before swapping in and running another. But it was multitasking in that multiple programs could be executing, with all but one waiting for the CPU.

I fully agree that Linux today is very different to UNIX in the 70s but that's mainly in terms of hardware capabilities (capacities and speeds) and software developments to exploit those capabilities.

I think that there's more to it than that. One of the things about K&R UNIX was that it was small in scale. The emphasised that the small tables such as the list of processes, list of inodes, list of open files and more, all worked with a simple linear search because they weren't big enough to warrant anything more. But then UNIX hit Berkeley and all of a sudden the machine had thousands of accounts, so just doing 'ls -l' took a couple of minutes. A new algorithm for the password file was needed. So many of the fundamental were not scalable. Another thing that came out of Berkeley was "select()" Before than all IO was blocking. That led to the development of the concept that a process has no limits any longer on the number of files it could open and watch.

The big attraction of UNIX initially was that it could run multiple processes,

So could many other machines and operating systems. The thing about UNIX was that it could do it with very few resources.

Plus it came with oodles of software.

That too, but it also broke away from the monolithic model of one program that did it all, which rapidly led 'pipes and filters', which was quite revolutionary, as it meant there was scripting power of a very different order from the "Job Execution Language" of the mainframes.

Maybe I missed the point. UNIX was a real operating system; DOS wasn't.

Many weren't. I was taught and still believe that a real OS is a resource manager. That means it must also do access control! There were no shortage of 'toys' that allowed multi-programming and did job scheduling. Heck, I wrote some myself, even in FORTH! We now see Linux doing real OS things with CGROUPS. Real resource management!

...

...

Even UNICS was multiprocessing, wasn't it?

Do you mean MULTICS?

No, MULTICS was clearly multi-user, multi-tasking, multi-processing and earlier. UNICS was the precursor to UNIX. Ritchie says it had exactly two processes - one for each terminal - so that may be what you're thinking of.

Maybe. All I wrote was from memory, and that, what, 40 years ago. I should have used google a bit :-) The use I made of V5 was just for part of a course and that was an option and I got credit for the taking option and any notes I made are long gone. Only a couple of texts from my university days made it across the Atlantic with me an they haven't been opened in decades. I ought to sell them. Come to that, neither have my Tannenbaums or Stevens or a pike of books on languages like Smalltalk. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 20.03.2016 um 21:25 schrieb Anton Aylward:

...

I'd prefer is the process with the focus wouldn't get disturbed by other processes. That feels like a good heuristic. In absolute terms what you're asking for is OS8, CP/M, or early MS-DOS,

On 03/20/2016 03:39 PM, Aaron Digulla wrote: that is a single talks "operating system'.

No, what I'm asking for is an OS which doesn't feel laggy. I have a supercomputer under my desk and neither Windows nor Linux are able to make it feel "snappy". That's sad. Some heavy parallel process runs away with your CPU? Well, we're too lazy/dump/careless to configure ssh or other measure in such a way that you can stop it. Just switch off the computer... and hope for the best. It's 2016, guys. Computers should start to heal themselves by now. Anything hogs the CPU? Maybe reserve 10% for other processes just in case the user might want to do something else. Browser plugin makes the browser unusable? How about a useful error message. X11 hangs in a deadlock? How about some real-time deadlock detection. Or dead-lock free code. But no. It's much easier to build a system which doesn't save log messages somewhere in RAM when hibernate fails so an automated tool could collect them. Instead, even professionals have to stab in the dark to figure out what might be going on. I understand that people like me are part of the problem. Instead of inventing programming languages that make it hard to write bad code by forcing the feeble human brain to juggle tons of information, we're lazy. It's easier to have thousands of developers spend days of their lives to debug a broken language design than to spend a week and do it right. But again. It's 2016. It's time to think about way to make life more simple automatically. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 25.03.2016 18:53, Anton Aylward wrote:

On 03/25/2016 01:25 PM, Aaron Digulla wrote:

...

Am 20.03.2016 um 21:25 schrieb Anton Aylward:

...

...

I'd prefer is the process with the focus wouldn't get disturbed by other processes. That feels like a good heuristic. In absolute terms what you're asking for is OS8, CP/M, or early MS-DOS,

On 03/20/2016 03:39 PM, Aaron Digulla wrote: that is a single talks "operating system'. No, what I'm asking for is an OS which doesn't feel laggy. I have a supercomputer under my desk and neither Windows nor Linux are able to make it feel "snappy". That's sad. Yes, the kernel scheduler may have an influence, but my experimentation with a desktop system that isn't also doing much in the way of 'server' stuff is that trying to tune the scheduler is a a waste of time.

I just wanted to look at the kernel because my favorite game started to act up when I upgraded my *-desktop to a *-default kernel when I went from 3.6 (I think) to a 4.x. Another sad fact: It's very hard to tell why a system is feeling laggy. Is it the graphics driver? Memory subsystem? Some other process or thread that hogs the CPU? A lot of code seems to come from "we must not waste a single CPU cycle". It would be nice if kernel developer started to look at self-healing code which checks for certain "odd" conditions and then collect the data necessary to solve them when they occur. Case in point: My hibernate issues with 4.5. I could probably set up a serial console. I could probably add a second computer to process the data. And then I could spend a couple of days to try to find the issue, if I had some help. With modern systems becoming ever more complex, I don't see this happening. I'm spoiled by smartphones which just work (most of the time). They have background processes which track the health of the system and report issues back to the developers without me even noticing. I know that the technology is also abused to track people (which buttons do they press and how long, etc). A way to turn this on and off would be nice. But as more non-technical people are dragged into this and as the technical people are losing their footing, software has to become smarter, more resilient and easy to debug -> a software needs to monitor the system state, enable logging for detected problems and then notify the user that something needs attention.

Don't you ever wonder why some of us get pizzed off at newbies who could have found the answer by a simple 'go google!"?

To ask google, you need to know what to ask. If you have a black screen, there is little that a newbie can do. If the software says "there was an error" or "error #23987453", that doesn't help. Then we have nice graphical error dialogs where you can't copy&paste. And lastly, Google will just dump a lot of text in your lap. If I put myself into it, I can find what I need. It just takes some time. Then it takes time to try various fixes until I find one that works. Then it takes time to write that down, in case it happens again. I'm too old to spend my time freely. So instead of blaming the newbie for their lack of knowledge and interest, I'd prefer an approach where newbies wouldn't have to get as far as complaining. Human brains simply work the opposite way: Stress goes up and intellectual prowess goes down. Up to a point where you're so frustrated that you can't think anymore. If you feel "pizzed" about the way every brain works, you're doomed. The human brain won't change in the next 100 years. Software has to give. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/03/16 21:31, Anton Aylward wrote:

On 03/17/2016 05:50 PM, John Andersen wrote:

...

On 03/17/2016 05:04 AM, Anton Aylward wrote:

...

regular readers will recall that I've mentioned before:

I'm on 13.1 and few leading repositories, one of which is Kernel_Stable. Precisely where did you get this? compile yourself, or from Opensuse repositories? I've posted the URL for kernel_Stable here quite a number of time, but I'll do so again:

http://download.opensuse.org/repositories/Kernel:/stable/standard/

There, nothing odd of obscure about that, is there?

Oh Anton, you 'obscure' and 'odd' man, you! :-D . There is one BIG difference between "kernel_Stable" and ".../repositories/Kernel:/stable/standard"! :-D BC -- Using openSUSE 13.2, KDE 4.14.9 & kernel 4.5.0-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen wrote:

On 03/17/2016 05:04 AM, Anton Aylward wrote:

...

regular readers will recall that I've mentioned before:

I'm on 13.1 and few leading repositories, one of which is Kernel_Stable.

Precisely where did you get this? compile yourself, or from Opensuse repositories?

In my case, from openSUSE KOTD: https://en.opensuse.org/openSUSE:Kernel_of_the_day -- Per Jessen, Zürich (8.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/03/16 22:31, Per Jessen wrote:

John Andersen wrote:

...

On 03/17/2016 05:04 AM, Anton Aylward wrote:

...

regular readers will recall that I've mentioned before:

I'm on 13.1 and few leading repositories, one of which is Kernel_Stable. Precisely where did you get this? compile yourself, or from Opensuse repositories? In my case, from openSUSE KOTD:

https://en.opensuse.org/openSUSE:Kernel_of_the_day

No, Per, use the kernel from- download.opensuse.org/repositories/Kernel:/stable/standard/ As I understand it, whatever is in HEAD is equivalent to what used to be in FACTORY -- pre-pre-tested offering. BC -- Using openSUSE 13.2, KDE 4.14.9 & kernel 4.5.0-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 03/18/2016 08:04 AM, Basil Chupin wrote:

...

On 18/03/16 22:31, Per Jessen wrote:

...

John Andersen wrote:

...

On 03/17/2016 05:04 AM, Anton Aylward wrote:

...

regular readers will recall that I've mentioned before:

I'm on 13.1 and few leading repositories, one of which is Kernel_Stable. Precisely where did you get this? compile yourself, or from Opensuse repositories? In my case, from openSUSE KOTD:

https://en.opensuse.org/openSUSE:Kernel_of_the_day

No, Per, use the kernel from-

download.opensuse.org/repositories/Kernel:/stable/standard/

As I understand it, whatever is in HEAD is equivalent to what used to be in FACTORY -- pre-pre-tested offering.

Indeed. Stable means .. reliability, predictability, stability

I rarely have reason to dabble with the bleeding edge stuff - in this case I was hoping for a graphics issue to have been fixed. It just happened to coincide with Anton's announcement in $SUBJ. Otherwise stable for me is 3.16, or 2.6.22 on my workstation :-) -- Per Jessen, Zürich (10.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

20.03.2016 01:20, Aaron Digulla пишет:

Am 17.03.2016 um 13:04 schrieb Anton Aylward:

...

regular readers will recall that I've mentioned before:

I'm on 13.1 and few leading repositories, one of which is Kernel_Stable.

I'm on 13.2 and updated 4.5.0-2.2 and I'm not so happy with it.

With 4.4 and 4.5, suspend is broken in some odd way. The machine will suspend once. When I suspend again, it will crash during resume. This might be because of a weird grub2 issue where grub will select the second entry (advanced options) and then the second entry in that menu.

Do you mean suspend to RAM (which is usually implied by using unqualified "suspend") or suspend to disk (which is normally called "hibernation" to disambiguate it)? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 20.03.2016 um 12:58 schrieb Anton Aylward:

On 03/20/2016 01:52 AM, Andrei Borzenkov wrote:

...

20.03.2016 01:20, Aaron Digulla пишет:

...

I'm on 13.2 and updated 4.5.0-2.2 and I'm not so happy with it.

With 4.4 and 4.5, suspend is broken in some odd way. The machine will suspend once. When I suspend again, it will crash during resume. This might be because of a weird grub2 issue where grub will select the second entry (advanced options) and then the second entry in that menu.

Do you mean suspend to RAM (which is usually implied by using unqualified "suspend") Which, once again, brings up the issue of how much RAM

If Hibernate didn't have enough swap, I'd expect it to abort with a useful error message instead of crashing and ruining my data.

...

or suspend to disk (which is normally called "hibernation" to disambiguate it)? Which brings up the issue of (a) swap space. How is that configured? Is it a real/primary partition or not; and (b) how much of this is dealt with at the user/application level and how much at the kernel level?

Hibernate worked flawlessly with the stock 3.x kernels that come with 13.2. Recently, I switched to 4.x to fix issues with USB3 and the NVIDIA driver installer. I think the main point is that I'm very happy with Linux and openSUSE overall. I've made it my main OS some 15 years ago and I didn't regret it (often) since. But there are a few points (hibernate, power management, 3D drivers, USB3) where I feel pain. All these areas are notoriously complex. Developers in those areas are more developers rather than users ("useful error messages? who needs that??? It's fun to run blindly in the dark!"). It's so incredibly frustrating, especially when you're me (https://stackoverflow.com/users/34088/aaron-digulla) Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am 20.03.2016 um 06:52 schrieb Andrei Borzenkov:

20.03.2016 01:20, Aaron Digulla пишет:

...

Am 17.03.2016 um 13:04 schrieb Anton Aylward:

...

regular readers will recall that I've mentioned before:

I'm on 13.1 and few leading repositories, one of which is Kernel_Stable. I'm on 13.2 and updated 4.5.0-2.2 and I'm not so happy with it.

With 4.4 and 4.5, suspend is broken in some odd way. The machine will suspend once. When I suspend again, it will crash during resume. This might be because of a weird grub2 issue where grub will select the second entry (advanced options) and then the second entry in that menu.

Do you mean suspend to RAM (which is usually implied by using unqualified "suspend") or suspend to disk (which is normally called "hibernation" to disambiguate it)?

I'm hibernating. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/20/2016 12:56 PM, Andrei Borzenkov wrote:

20.03.2016 22:40, Aaron Digulla пишет:

...

Am 20.03.2016 um 06:52 schrieb Andrei Borzenkov:

...

20.03.2016 01:20, Aaron Digulla пишет:

...

Am 17.03.2016 um 13:04 schrieb Anton Aylward:

...

regular readers will recall that I've mentioned before:

I'm on 13.1 and few leading repositories, one of which is Kernel_Stable. I'm on 13.2 and updated 4.5.0-2.2 and I'm not so happy with it.

With 4.4 and 4.5, suspend is broken in some odd way. The machine will suspend once. When I suspend again, it will crash during resume. This might be because of a weird grub2 issue where grub will select the second entry (advanced options) and then the second entry in that menu.

Do you mean suspend to RAM (which is usually implied by using unqualified "suspend") or suspend to disk (which is normally called "hibernation" to disambiguate it)?

I'm hibernating.

In this case if grub2 picks the wrong kernel, this is a bug that at least needs investigating. Script that tries to detect which kernel to use is part of pm-utils I believe (in 13.2); consider opening bug report and posting number here.

Uninstall pm-utils. No longer needed. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/20/2016 01:04 PM, Andrei Borzenkov wrote:

20.03.2016 22:59, John Andersen пишет:

...

On 03/20/2016 12:56 PM, Andrei Borzenkov wrote:

...

20.03.2016 22:40, Aaron Digulla пишет:

...

Am 20.03.2016 um 06:52 schrieb Andrei Borzenkov:

...

20.03.2016 01:20, Aaron Digulla пишет:

...

Am 17.03.2016 um 13:04 schrieb Anton Aylward: > regular readers will recall that I've mentioned before: > > I'm on 13.1 and few leading repositories, one of which is Kernel_Stable. I'm on 13.2 and updated 4.5.0-2.2 and I'm not so happy with it.

With 4.4 and 4.5, suspend is broken in some odd way. The machine will suspend once. When I suspend again, it will crash during resume. This might be because of a weird grub2 issue where grub will select the second entry (advanced options) and then the second entry in that menu.

Do you mean suspend to RAM (which is usually implied by using unqualified "suspend") or suspend to disk (which is normally called "hibernation" to disambiguate it)?

I'm hibernating.

In this case if grub2 picks the wrong kernel, this is a bug that at least needs investigating. Script that tries to detect which kernel to use is part of pm-utils I believe (in 13.2); consider opening bug report and posting number here.

Uninstall pm-utils. No longer needed.

Please explain what replaces it for the purpose discussed here.

Apparently handled all by systemd, via acpi, HOWEVER: systemd will attempt to use pm-utils scripts if it finds them, The maintainer of pm-utils posted his intent to stop maintiaing them back in 2013. He even stated pm-utils are flaky at best when systemd is in use. https://lists.opensuse.org/opensuse-factory/2013-11/msg00911.html There was a bug report requesting the removal of pm-utils scripts so that systemd would not find them and try to work with them: https://lists.opensuse.org/opensuse-bugs/2014-11/msg03640.html The Arch Wiki covers this in some detail - and seems to be accurate for 13.2 as well: https://wiki.archlinux.org/index.php/Power_management#Power_management_with_... Settings for overriding the systemd defaults appear in /etc/systemd/logind.conf but these are all commented out, because, (at least in the majority of cases) the defaults are good enough. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 3/20/2016 8:21 PM, Andrei Borzenkov wrote:

20.03.2016 23:44, John Andersen пишет:

...

On 03/20/2016 01:04 PM, Andrei Borzenkov wrote:

...

20.03.2016 22:59, John Andersen пишет:

...

On 03/20/2016 12:56 PM, Andrei Borzenkov wrote:

...

20.03.2016 22:40, Aaron Digulla пишет:

...

Am 20.03.2016 um 06:52 schrieb Andrei Borzenkov: > 20.03.2016 01:20, Aaron Digulla пишет: >> Am 17.03.2016 um 13:04 schrieb Anton Aylward: >>> regular readers will recall that I've mentioned before: >>> >>> I'm on 13.1 and few leading repositories, one of which is Kernel_Stable. >> I'm on 13.2 and updated 4.5.0-2.2 and I'm not so happy with it. >> >> With 4.4 and 4.5, suspend is broken in some odd way. The machine will >> suspend once. When I suspend again, it will crash during resume. This >> might be because of a weird grub2 issue where grub will select the >> second entry (advanced options) and then the second entry in that menu. >> > Do you mean suspend to RAM (which is usually implied by using > unqualified "suspend") or suspend to disk (which is normally called > "hibernation" to disambiguate it)?

I'm hibernating.

In this case if grub2 picks the wrong kernel, this is a bug that at least needs investigating. Script that tries to detect which kernel to use is part of pm-utils I believe (in 13.2); consider opening bug report and posting number here.

Uninstall pm-utils. No longer needed.

Please explain what replaces it for the purpose discussed here.

Apparently handled all by systemd, via acpi,

Setting default bootloader (grub2) menu entry to use on next boot? Are you sure you understand what we are talking about?

Quite. This is a well known issue. The script in pm-utils has been the source of a lot of problems on resume. Simply delete the package, and let systemd figure it out. I went through weeks with this same problem. After extensive searching it was found that pm-utils gets it wrong, especially when systemd is involved. Simply uninstalling pm-utils, and letting systemd handle all aspects of hibernate and resume seems to solve this problem. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/21/2016 01:21 AM, Aaron Digulla wrote:

Does systemd somehow log problems during hibernate?

I don't know, I never checked, but I imagine it logs as normal up to the point where the system is stopped, and then picks up again upon resume. I don't know if it flushes any in-flight logging to disk before hibernate. Certainly nothing is logged WHILE it is in the state of hibernation. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, Mar 24, 2016 at 11:49 AM, Aaron Digulla wrote:

Am Montag, 21. März 2016 09:21 CET, "Aaron Digulla" schrieb:

...

Am Montag, 21. März 2016 05:47 CET, John M Andersen schrieb:

...

...

...

...

...

> Uninstall pm-utils. No longer needed. Please explain what replaces it for the purpose discussed here. Apparently handled all by systemd, via acpi, Setting default bootloader (grub2) menu entry to use on next boot? Are you sure you understand what we are talking about? Quite.

This is a well known issue.

The script in pm-utils has been the source of a lot of problems on resume. Simply delete the package, and let systemd figure it out. I have pm-utils installed. I'll try without it tonight and let you know my results.

I've hibernated and resumed several times over the past few days and I can confirm that pm-utils caused my problems.

Does it also work if you boot using non-default (i.e. the very first) menu entry in bootloader? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/19/2016 06:20 PM, Aaron Digulla wrote:

Am 17.03.2016 um 13:04 schrieb Anton Aylward:

...

regular readers will recall that I've mentioned before:

I'm on 13.1 and few leading repositories, one of which is Kernel_Stable.

I'm on 13.2 and updated 4.5.0-2.2 and I'm not so happy with it.

With 4.4 and 4.5, suspend is broken in some odd way. The machine will suspend once. When I suspend again, it will crash during resume.

That doesn't sound like "suspend to RAM" so much as "hibernate to disk". <quote src="http://askubuntu.com/questions/3369/what-is-the-difference-between-hibernate-and-suspend"> The power-management scripts use these terms: suspend -- suspend to ram; some folks call this "sleep" resume -- restart after suspend to ram; does not use grub hibernate -- suspend to disk; includes power-off, looks like shutdown thaw -- restart after suspend to disk; includes a trip through grub </quote>

This might be because of a weird grub2 issue where grub will select the second entry (advanced options) and then the second entry in that menu.

If GRUB is involved then its "hibernate-to-disk". Perhaps the problem is that you're using hibernate when you ought to be using suspend? https://en.opensuse.org/SDB:Suspend_to_RAM Which gets back to 'use case'. Is this just shutting the laptop lid when going off to the bathroom or to get a coffee refill? Or are you closing the laptop down for the night and expect to restart exactly where you were again in the morning? Well, I use KDE4 and I can run "shutdown -h -P now" and when I log in the next morning KDE4 brings up exactly the same set of applications. The downside is that if I had a LibreOffice document open its not open again at the same place, if I had a ssh session its not open to the remote machine again. But since 98% of the time its mail and browser and file manager and a bunch of terminal sessions under Konsole, that's OK. 1% of the time its something like LibreOffice or some other editor where I can "open last document" in a couple of clicks. If, as you imply, this is a gaming laptop, and you want to continue where you left off in the game then I really think you're talking about "suspend to RAM". Or should be. In which case grub etc is irrelevant and "you're doing it all wrong".

Which means I suspend with 4.5 and then Grub happily boots into 4.4 ...

Now how did you get to that.

But it also fails when I manually select the first option of the Grub2 menu. So there must be another issue somewhere.

Are you talking 'always'? Then there's something wrong with that entry. you'd have to give us details. It may simply be that some file is missing or there is a typo.

A minor annoyance is that the computer doesn't power down after suspend. I have to flip the switch.

We're back to the 'suspend' vs 'hibernate' issue. Have you tried this manually with and without the GUI running, that is in each of: # systemctl isolate graphical.target # systemctl isolate multi-user.target running from a VT as root # pm-suspend Recall that suspend stops operation of all applications and system state is saved in RAM, the machine go into a low-power mode, in this state, the system still requires power . Various triggers can resume the machine, among them pressing a key or quickly pressing and releasing the power button. and # pm-hibernate Recall that hibernate Moves the contents of memory into swap, tells the bootloader to boot directly into the appropriate kernel, and shuts the machine down, in this state, the system does not require power. You turn on the machine by powering up, which causes the kernel to reload the contents of memory from swap. There is a reason I ask you to try this with and without the GUI. Suspending and saving the contents of the graphical card is quite another matter! The larger, the more powerful the card, the more involved (aka complex, aka problem prone) it will be for both these operations. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On March 25, 2016 7:11:11 AM PDT, Anton Aylward wrote:

A few people have asked a 'so what?' question, what is there about the 4.x series that is of any improvement, any value>

Fair enough, but lets face it, we have different contexts so some may apply to your specific needs, some many not.

As I've said, many of the improvements are to the kernel, not the user side of things, and are to do with integrity and smooth running rather than 'blinding speed'. This is the kernel we're talking about!

http://kernelnewbies.org/Linux_4.0 http://kernelnewbies.org/Linux_4.1 http://kernelnewbies.org/Linux_4.2 4.3 was a merge ... mostly about hardware http://kernelnewbies.org/Linux_4.4 .... most notably locks were removed from the TCP listener making it faster http://kernelnewbies.org/Linux_4.5

Of course YMMV.

Which of these are Long Term Support kernels? -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org