Kernel prepatch 3.10-rc1 [LWN.net]

Linus has announced the 3.10-rc1 kernel prepatch and the closure of the merge window for this development cycle. All told, nearly 12,000 changesets were pulled into the mainline during the merge window, making it the busiest such ever. See this article (subscribers only) for a summary of changes merged since last week's merge window update.

to post comments

Kernel prepatch 3.10-rc1

Posted May 12, 2013 22:52 UTC (Sun) by theophrastus (guest, #80847) [Link] (7 responses)

fairly esoteric, and only upon those suffering with NVIDIA graphics cards but between 3.9.0-rc6 and 3.10-rc1 the nvidia module 304.88 breaks with:

In function ‘nv_i2c_del_adapter’ error: void value not ignored as it ought to be

which if one attempts the patch from here:
https://devtalk.nvidia.com/default/topic/543728/building-...

then a circular mess associated with a (recent?) transition from create_proc_entry() to proc_create() is triggered. which at least i'm currently too dumb to solve (where does the new 4th argument come from?)

ah well... it's an "-rc"

Kernel prepatch 3.10-rc1

Posted May 13, 2013 6:17 UTC (Mon) by bosyber (guest, #84963) [Link] (6 responses)

See last weeks "what's coing for 3.10" article, and specifically Al Viro's comment to add to that about these proc changes.

Kernel prepatch 3.10-rc1

Posted May 13, 2013 14:59 UTC (Mon) by theophrastus (guest, #80847) [Link] (5 responses)

That certainly should have sent me a warning: "create_proc_entry()/create_proc_read_entry() are killed off; use proc_create()" unfortunately, i've been unable to discover: "how to re-write your (module) code to accommodate a shift to proc_create() ..for dummies"

well, no one said keeping up with kernel upgrades is easy; but does remain an interesting challenge.

if anyone knows of a linux friendly (non-NVIDIA non-gaming) video card that doesn't always have to play code catch-up with the kernel, it would be grand to told the brand. thank you.

Kernel prepatch 3.10-rc1

Posted May 13, 2013 18:24 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (2 responses)

Do you need a discrete chip set? If not, I've had no (graphics) issues running Rawhide with Ivy Bridge. I've been able to run Trine 2 on it just fine.

Kernel prepatch 3.10-rc1

Posted May 13, 2013 19:33 UTC (Mon) by theophrastus (guest, #80847) [Link] (1 responses)

You're referring to on-CPU HD 4000 graphics? That might be a solution for another machine i've been looking to upgrade; but currently i think there's a bit more life in my main intel-i5 (760), so i need PCI video card.

have you built dkms modules for the ivy-bridge graphics? no stability problems there?

Kernel prepatch 3.10-rc1

Posted May 13, 2013 20:34 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

Yes. I just use the stock Fedora kernel (well, the -nodebug repository since I ride Rawhide all the time these days). I have the extra modules package installed for the 360's gamepad drivers, but that's it. I upgraded from a Core 2 Duo, and the jump has been very nice.

For a PCI card, the Radeon HD 5870 has been chugging for ~3 years at $DAYJOB with 3 monitors just fine. I don't game on it, but it's at least been stable for OpenGL stuff (with 3 monitors). It also has preliminary OpenCL support too if you build your own mesa/LLVM stack. The 6570 I purchased to replace it has had less luck though[1] (I'll have to retest again soon).

[1]https://bugzilla.redhat.com/show_bug.cgi?id=818728

Kernel prepatch 3.10-rc1

Posted May 14, 2013 18:15 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

I've had no problems at all using the free (Gallium) drivers with my ATI Radeon BARTS / Northern Islands / 68xx chipset (other than figuring out what the heck it is from its millions of distinct names).

Kernel prepatch 3.10-rc1

Posted May 14, 2013 19:10 UTC (Tue) by theophrastus (guest, #80847) [Link]

yes indeed!
the mapping of chip-set/maker/model-number/revision/box-name to a specific device that will function with a particular driver (if binary then to a particular set of CPU and libraries) has got to be one of the most bramble-bush paths in all of linux-dom. a thousand thanks to the few web-sites that attempt to list them with all their details.

by-the-bye, i've given up trying the nvidia/blob dkms approach for current kernels (3.9 and beyond). i'm running nouveau (and trying to ignore all the frequent: "Failed to open VDPAU backend libvdpau_nouveau.so: cannot open shared object file: No such file or directory" which seem to serve only to annoy). it seems ok, and hey, it compiles.

Kernel prepatch 3.10-rc1

Posted May 13, 2013 9:31 UTC (Mon) by sickpig (guest, #28685) [Link] (2 responses)

my git-foo is quite poor, so I'm not able to verify if
Rik Van Riel's work(*) to make sysv semaphore more
scalable went in.

thanks in advance to anyone who will able give me
a response :)

(*) https://lwn.net/Articles/543659/

sysv semaphore scalability

Posted May 13, 2013 10:30 UTC (Mon) by jamieiles (guest, #72405) [Link] (1 responses)

Yes, it looks like it to me:

git log v3.9..v3.10-rc1 --grep="ipc,sem: fine grained locking for semtimedop" -- ipc/sem.c

commit 6062a8dc0517bce23e3c2f7d2fea5e22411269a3
Author: Rik van Riel <riel@surriel.com>
Date: Tue Apr 30 19:15:44 2013 -0700

ipc,sem: fine grained locking for semtimedop

...

sysv semaphore scalability

Posted May 13, 2013 10:51 UTC (Mon) by sickpig (guest, #28685) [Link]

many thanks Jamie !

And still no overlayfs

Posted May 14, 2013 13:23 UTC (Tue) by rfrancoise (subscriber, #15508) [Link]

One thing that did not make it into v3.10-rc1 is overlayfs, despite Linus's request...

Kernel prepatch 3.10-rc1

Posted May 16, 2013 0:08 UTC (Thu) by nowster (subscriber, #67) [Link] (3 responses)

And weirdness with ps possibly related to procfs or NOHZ changes:

$ ps -u
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
pm       14902  733  0.1  24500  7088 pts/1    Ss+  00:34 181:35 -bash
pm       15375 12600  0.1 24484  7076 pts/0    Ss   00:58  71:24 -bash

top also reports all process as using 0%, 100%, 200% (up to the number of CPUs available × 100%), and vmstat reports 100% system and 0% for everything else.

Kernel prepatch 3.10-rc1

Posted May 16, 2013 0:32 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

I'm not sure this is a change.

Top has reported processes using >100% cpu on multi core machines for years

vmstat scales it's usage based on 100% of total cpu power, no matter how many CPUs in the system.

now, if the stats are now incorrect, that could be related to the changes. My understanding is that issues like this are somewhat expected from the NOHZ changes and they are working to find and fix them as things get more widespread testing to flush out problem cases.

Kernel prepatch 3.10-rc1

Posted May 16, 2013 0:45 UTC (Thu) by nowster (subscriber, #67) [Link] (1 responses)

Like many of your recent posts, this one assumes the original poster is an idiot.

top is reporting integer multiples of 100% only, vmstat is pegged on 100% sys, and ps is reporting total fiction. This feels like either a format change for the procfs stats or a problem in the scheduler's reporting.

Kernel prepatch 3.10-rc1

Posted May 16, 2013 0:53 UTC (Thu) by dlang (guest, #313) [Link]

the example posted shows cpu results that are not multiples of 100%, so we are not seeing quite the same thing here.

assuming ignorance is not the same as assuming someone is an idiot. When I first ran across the >100% cpu and inconsistant between different tools other people had known about it for years, but it looked like a bug to me, so I see no reason why other folks could not be in the same situation today.

But as I said, it's not at all surprising to see bugs in the scheduler's reporting of time with the NOHZ changes, I seem to remember that the article talking about them indicated that they were still working to nail down and fix bugs in the reporting side.