Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
ck-sources : All about choice !
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Wed May 08, 2013 9:51 am    Post subject: Reply with quote

thunderrd wrote:
We really don't want that now, do we?

++
CK wrote:
It gets tiresome watching the same code being rehashed in many different ways... "because this time we'll do it right".

_________________
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Wed May 15, 2013 9:42 pm    Post subject: Reply with quote

Following Bug 469686 and thanks to Markos Chandras, the ck-sources tree has been updated in order to :

- Push the 3.9.2 early release,

- 3.8.13 is also out as last release of the 3.8 stable branch.

- no-networkless {3.6.11-r2 / 3.7.10-r1 / 3.8.3} installs should be upgraded because of a couple of security related issues,
- Please note that 3.4.34 users should upgrade to 3.4.43 for the same reason.


About the 3.9.2 early release, please note that :
CK wrote:
There were some fairly dramatic CPU offline code changes to mainline (YET AGAIN!) and the changes to BFS to make it work were fairly significant so there may once again be issues with power off/reboot/suspend/hibernate.

Have already been observed :

- "Strange" output of vmstat after hibernation.
- Hangings on reboot depending on CONFIG_HZ value (getting worse with lower CONFIG_HZ).
_________________
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2404
Location: UK

PostPosted: Mon May 27, 2013 3:16 am    Post subject: Reply with quote

A bit late but it had to be said...

Holy crap, 3.9 is nice! Not only did it fix that radeon problem, it even supports UVD!
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Tue May 28, 2013 10:45 am    Post subject: Reply with quote

It Is Alreay Very Expensive to be Fair! => It is going to be even more expensive when being able to tune fairness

I make no doubt that all of us here around reading this thread, are well aware of the fact that ensuring fairness costs a big and highly variable amount of cpu time, this leading to *high* and highly variable latencies. And that it is almost certainly one of the most important reason why we do not want the CFS.

Now, from whatever project's management standpoint, we also know well the now *extreme* cost of offering the possibility for a system to sometimes :? more or less :? ignore :? THE boolean quality / property / characteristic the entire design is based on.
(OK... offering the possibility... without totally ruining the entire system I mean... :roll: )

Oh wait! something is still missing in order to completely end the tragedy... the main attraction for the show I mean :

Offering the end user a knob for adjusting a desired percentage of the boolean concept the system is built on ! :roll:

My post is unfair ? Of course not! It's only 66.6%-fair, which contributes to 50%-granting 99%-eternity to the BFS concept! :twisted:

You want now some 100%-real facts illustrating my 10%-trolling ?

Then welcome to the wake-affine tragedy

BTW, the entire thread is worth reading as renown scheduler devs (Ingo Molnar, Mike Galbraith...) are contributing.
_________________
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5720
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Tue May 28, 2013 3:07 pm    Post subject: Reply with quote

hm, I remember back in my head that at the beginning when CFS was introduced it was quite good

the longer it existed and the more features got added (to ensure fairness ???)

the more sluggishness I noticed compared to RSDL and/or RFS (or what the previous names were - can't remember anymore since I did a springclean some weeks ago with patchsets, etc.)


so what in essence does this mean ?

currently the kernel is trying very often to ensure fairness which in turn leads to low throughput +/- high latencies ?
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.3.0-r2
2.6.37.2_plus_v1: BFS, CFS,THP,compaction, zcache or TOI
Hardcore Linux user since 2004 :D
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1159

PostPosted: Tue May 28, 2013 6:13 pm    Post subject: Reply with quote

Ant P. wrote:
A bit late but it had to be said...

Holy crap, 3.9 is nice!
Yes, linux-3.9.4-bfs runs very well! (I didn't use linux-3.8-bfs) And the stable-queue patches for linux-3.8-ff showed a very beta nature of that release compared to linux-3.9 now. I am very pleased :)
Time for kernel.org for another new LTS !
_________________
fun2gen2
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Tue May 28, 2013 7:29 pm    Post subject: Reply with quote

kernelOfTruth wrote:
so what in essence does this mean ?
currently the kernel is trying very often to ensure fairness which in turn leads to low throughput +/- high latencies ?

In essence ? Well... in essence... things are much worse than that.

1/ You get a whole machine rowing in the direction of fairness.
2/ Because you realize that this is not always optimal, you introduce components capable of rowing in the opposite direction.
Fair enough! After all... why not ?
3/ Because rowing in the opposite direction, requires important efforts (overheads), efforts that will sometimes be thankless.
And of course, the result becomes highly workload dependent.

Speaking of these particular components, it is reported that they appear capable of boosting by up to 15% the performances of some workloads while... damaging others by up to... 40% 8O

4/ OK then, instead of realizing that the implementation of such a component rowing the opposite direction is an error on principle, you imagine to limit the activity of the component with some kind of timeout and because you cant' know the appropriate value for the threshold (of course... there is no appropriate value) and because it is as easy to implement an umpteen user tuneable as hardcoding a value... you :

Leave to the user the belief he can expect a +15% win, leave to the user the risk to drop everything by 40% and... more probably... to screw everything down by an amount of (15-40)/2 = 12,5% !!!

Funny isn't it ?
Yes... fortunately Mike Galbraith provides sometimes funny images of the reality :
Quote:
the hardest working load component is the mother of all work, the (singular) server. Any time 'mom' is not continuously working her little digital a$$ off to keep all those kids fed, you have a performance problem on your hands, the entire load stalls, lives and dies with one and only 'mom'.

_________________
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1159

PostPosted: Tue May 28, 2013 10:17 pm    Post subject: Reply with quote

I guess the unbeatable fair scheduler takes a hundred percentage of overhead !
_________________
fun2gen2
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Thu Jun 06, 2013 9:47 am    Post subject: Reply with quote

ulenrich wrote:
Time for kernel.org for another new LTS !

As long as no one volunteers for maintaining and Greg K-H cannot maintain more than 2 LTS concurrently, I'm afraid you'll have to wait for 3.0's EOL before enjoying a new LTS branch.
That is to say october 2013, in other words... 3.12 ?
_________________
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Tue Jun 25, 2013 10:54 am    Post subject: Reply with quote

Following Bug 472842 and thanks to Sergey Popov, the ck-sources tree has been updated in order to :

- Push the 3.9.7 release,

Please note that, as justified in the bug :

- I implemented a very trivial patch in order to prevent users from selecting the "Full dynticks CPU time accounting" AKA CONFIG_VIRT_CPU_ACCOUNTING_GEN kernel configuration option.

How comes that such a considerable amount of people "working on the full dynticks subsystem development" choose the ck-sources package, will remain a mystery to me... :roll:

Please also note that from this release, and thanks to the genpatches, the ck-sources offer the BFQ I/O scheduler as a possible choice.
_________________
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2404
Location: UK

PostPosted: Tue Jun 25, 2013 3:12 pm    Post subject: Reply with quote

Wow, I just checked and I've been running deadline on a spinny disk for these past few weeks. Might explain why my browser takes a year to start up... :lol:
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2404
Location: UK

PostPosted: Fri Jul 12, 2013 9:33 pm    Post subject: Reply with quote

I've just been looking at the 3.11 radeon drm patches, looks like they finally added a good dynpm implementation. Some of the user replies there suggest it does as good a job as the windows binary driver.

Just in time for summer to have already ended... when I *want* my computer to be a space heater again :D
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Sat Jul 13, 2013 8:36 am    Post subject: Reply with quote

Ant P. wrote:
Just in time for summer to have already ended... when I *want* my computer to be a space heater again :D

:D
AFAIK, David Airlie is living in Brisbane...
:twisted:
_________________
Back to top
View user's profile Send private message
thunderrd
n00b
n00b


Joined: 20 Aug 2010
Posts: 36

PostPosted: Sun Jul 21, 2013 4:31 pm    Post subject: Reply with quote

Regarding 3.9.7, I have something strange happening.

Here is the relevant section of the dmesg of the 3.9.2 kernel:
Code:
[    0.000000] Linux version 3.9.2-ck (root@Q6600) (gcc version 4.7.3 (Gentoo 4.7.3 p1.0, pie-0.5.5) ) #1 SMP PREEMPT Mon May 27 23:04:48 ICT 2013
[    0.000000] Command line: root=/dev/sda4 rootfstype=ext4 video=uvesafb:1280x1024-32@60,mtrr:3,ywrap
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000cff6ffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000cff70000-0x00000000cff87fff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000cff88000-0x00000000cffcffff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000cffd0000-0x00000000cfffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000001afffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.5 present.
[    0.000000] DMI: System manufacturer System Product Name/P5Q PRO TURBO, BIOS 0602    08/04/2009
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] e820: last_pfn = 0x1b0000 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-DFFFF write-protect
[    0.000000]   E0000-EFFFF write-through
[    0.000000]   F0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 1B0000000 mask FF0000000 uncachable
[    0.000000]   1 base 1C0000000 mask FC0000000 uncachable
[    0.000000]   2 base 000000000 mask E00000000 write-back
[    0.000000]   3 base 0D0000000 mask FF0000000 uncachable
[    0.000000]   4 base 0E0000000 mask FE0000000 uncachable
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] original variable MTRRs
[    0.000000] reg 0, base: 6912MB, range: 256MB, type UC
[    0.000000] reg 1, base: 7GB, range: 1GB, type UC
[    0.000000] reg 2, base: 0GB, range: 8GB, type WB
[    0.000000] reg 3, base: 3328MB, range: 256MB, type UC
[    0.000000] reg 4, base: 3584MB, range: 512MB, type UC
[    0.000000] total RAM covered: 6144M
[    0.000000] Found optimal setting for mtrr clean up
[    0.000000]  gran_size: 64K    chunk_size: 64K    num_reg: 6     lose cover RAM: 0G
[    0.000000] New variable MTRRs
[    0.000000] reg 0, base: 0GB, range: 2GB, type WB
[    0.000000] reg 1, base: 2GB, range: 1GB, type WB
[    0.000000] reg 2, base: 3GB, range: 256MB, type WB
[    0.000000] reg 3, base: 4GB, range: 2GB, type WB
[    0.000000] reg 4, base: 6GB, range: 512MB, type WB
[    0.000000] reg 5, base: 6656MB, range: 256MB, type WB
[    0.000000] e820: update [mem 0xd0000000-0xffffffff] usable ==> reserved
[    0.000000] e820: last_pfn = 0xcff70 max_arch_pfn = 0x400000000
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] BRK [0x0173f000, 0x0173ffff] PGTABLE
[    0.000000] BRK [0x01740000, 0x01740fff] PGTABLE
[    0.000000] BRK [0x01741000, 0x01741fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x1afe00000-0x1afffffff]
[    0.000000]  [mem 0x1afe00000-0x1afffffff] page 2M
[    0.000000] BRK [0x01742000, 0x01742fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x1ac000000-0x1afdfffff]
[    0.000000]  [mem 0x1ac000000-0x1afdfffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x180000000-0x1abffffff]
[    0.000000]  [mem 0x180000000-0x1abffffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x00100000-0xcff6ffff]
[    0.000000]  [mem 0x00100000-0x001fffff] page 4k
[    0.000000]  [mem 0x00200000-0xcfdfffff] page 2M
[    0.000000]  [mem 0xcfe00000-0xcff6ffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
[    0.000000]  [mem 0x100000000-0x17fffffff] page 2M
[    0.000000] BRK [0x01743000, 0x01743fff] PGTABLE
[    0.000000] ACPI: RSDP 00000000000fb160 00014 (v00 ACPIAM)
[    0.000000] ACPI: RSDT 00000000cff70000 0003C (v01 A_M_I_ OEMRSDT  08000904 MSFT 00000097)
[    0.000000] ACPI: FACP 00000000cff70200 00084 (v02 A_M_I_ OEMFACP  08000904 MSFT 00000097)
[    0.000000] ACPI: DSDT 00000000cff70440 0AEE4 (v01  A1276 A1276001 00000001 INTL 20060113)
[    0.000000] ACPI: FACS 00000000cff88000 00040
[    0.000000] ACPI: APIC 00000000cff70390 0006C (v01 A_M_I_ OEMAPIC  08000904 MSFT 00000097)
[    0.000000] ACPI: MCFG 00000000cff70400 0003C (v01 A_M_I_ OEMMCFG  08000904 MSFT 00000097)
[    0.000000] ACPI: OEMB 00000000cff88040 00089 (v01 A_M_I_ AMI_OEM  08000904 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000cff7b330 00038 (v01 A_M_I_ OEMHPET  08000904 MSFT 00000097)
[    0.000000] ACPI: OSFR 00000000cff7b370 000B0 (v01 A_M_I_ OEMOSFR  08000904 MSFT 00000097)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000]  [ffffea0000000000-ffffea0006bfffff] PMD -> [ffff8801a9600000-ffff8801af5fffff] on node 0
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x1afffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0xcff6ffff]
[    0.000000]   node   0: [mem 0x100000000-0x1afffffff]
[    0.000000] On node 0 totalpages: 1572622
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 21 pages reserved
[    0.000000]   DMA zone: 3998 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 13246 pages used for memmap
[    0.000000]   DMA32 zone: 847728 pages, LIFO batch:31
[    0.000000]   Normal zone: 11264 pages used for memmap
[    0.000000]   Normal zone: 720896 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000
[    0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs


and here is the 3.9.7 kernel:
Code:
[    0.000000] Linux version 3.9.7-ck (root@Q6600) (gcc version 4.7.3 (Gentoo 4.7.3 p1.0, pie-0.5.5) ) #5 SMP PREEMPT Sun Jul 21 23:08:01 ICT 2013
[    0.000000] Command line: root=/dev/sda4 rootfstype=ext4 video=uvesafb:1280x1024-32@60,mtrr:3,ywrap
[    0.000000] KERNEL supported cpus:
[    0.000000]   Intel GenuineIntel
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000cff6ffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000cff70000-0x00000000cff87fff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000cff88000-0x00000000cffcffff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000cffd0000-0x00000000cfffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000001afffffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] SMBIOS 2.5 present.
[    0.000000] DMI: System manufacturer System Product Name/P5Q PRO TURBO, BIOS 0602    08/04/2009
[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] e820: last_pfn = 0x1b0000 max_arch_pfn = 0x400000000
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000]   00000-9FFFF write-back
[    0.000000]   A0000-BFFFF uncachable
[    0.000000]   C0000-DFFFF write-protect
[    0.000000]   E0000-EFFFF write-through
[    0.000000]   F0000-FFFFF write-protect
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 1B0000000 mask FF0000000 uncachable
[    0.000000]   1 base 1C0000000 mask FC0000000 uncachable
[    0.000000]   2 base 000000000 mask E00000000 write-back
[    0.000000]   3 base 0D0000000 mask FF0000000 uncachable
[    0.000000]   4 base 0E0000000 mask FE0000000 uncachable
[    0.000000]   5 disabled
[    0.000000]   6 disabled
[    0.000000]   7 disabled
[    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[    0.000000] original variable MTRRs
[    0.000000] reg 0, base: 6912MB, range: 256MB, type UC
[    0.000000] reg 1, base: 7GB, range: 1GB, type UC
[    0.000000] reg 2, base: 0GB, range: 8GB, type WB
[    0.000000] reg 3, base: 3328MB, range: 256MB, type UC
[    0.000000] reg 4, base: 3584MB, range: 512MB, type UC
[    0.000000] total RAM covered: 6144M
[    0.000000] *BAD*gran_size: 64K    chunk_size: 64K    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 128K    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 256K    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 512K    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 1M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 2M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64K    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 128K    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 256K    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 512K    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 1M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 2M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128K    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 256K    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 512K    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 1M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 2M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256K    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 512K    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 1M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 2M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 512K    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 1M    chunk_size: 1M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 1M    chunk_size: 2M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 1M    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 1M    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 1M    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 1M    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 1M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 1M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 1M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 1M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 1M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 1M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 2M    chunk_size: 2M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 2M    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 2M    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 2M    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 2M    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 2M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 2M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 2M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 2M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 2M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 2M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 4M    chunk_size: 4M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 4M    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 4M    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 4M    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 4M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 4M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 4M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 4M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 4M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 4M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 8M    chunk_size: 8M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 8M    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 8M    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 8M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 8M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 8M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 8M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 8M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 8M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 16M    chunk_size: 16M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 16M    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 16M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 16M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 16M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 16M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 16M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 16M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 32M    chunk_size: 32M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 32M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 32M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 32M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 32M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 32M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 32M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64M    chunk_size: 64M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 64M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128M    chunk_size: 128M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 128M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256M    chunk_size: 256M    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256M    chunk_size: 512M    num_reg: 7     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256M    chunk_size: 1G    num_reg: 6     lose cover RAM: -0G
[    0.000000] *BAD*gran_size: 256M    chunk_size: 2G    num_reg: 6     lose cover RAM: -0G
[    0.000000]  gran_size: 512M    chunk_size: 512M    num_reg: 4     lose cover RAM: 512M
[    0.000000]  gran_size: 512M    chunk_size: 1G    num_reg: 5     lose cover RAM: 512M
[    0.000000]  gran_size: 512M    chunk_size: 2G    num_reg: 5     lose cover RAM: 512M
[    0.000000]  gran_size: 1G    chunk_size: 1G    num_reg: 3     lose cover RAM: 1G
[    0.000000]  gran_size: 1G    chunk_size: 2G    num_reg: 3     lose cover RAM: 1G
[    0.000000]  gran_size: 2G    chunk_size: 2G    num_reg: 2     lose cover RAM: 2G
[    0.000000] mtrr_cleanup: can not find optimal value
[    0.000000] please specify mtrr_gran_size/mtrr_chunk_size
[    0.000000] e820: update [mem 0xd0000000-0xffffffff] usable ==> reserved
[    0.000000] e820: last_pfn = 0xcff70 max_arch_pfn = 0x400000000
[    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] BRK [0x0173f000, 0x0173ffff] PGTABLE
[    0.000000] BRK [0x01740000, 0x01740fff] PGTABLE
[    0.000000] BRK [0x01741000, 0x01741fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x1afe00000-0x1afffffff]
[    0.000000]  [mem 0x1afe00000-0x1afffffff] page 2M
[    0.000000] BRK [0x01742000, 0x01742fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x1ac000000-0x1afdfffff]
[    0.000000]  [mem 0x1ac000000-0x1afdfffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x180000000-0x1abffffff]
[    0.000000]  [mem 0x180000000-0x1abffffff] page 2M
[    0.000000] init_memory_mapping: [mem 0x00100000-0xcff6ffff]
[    0.000000]  [mem 0x00100000-0x001fffff] page 4k
[    0.000000]  [mem 0x00200000-0xcfdfffff] page 2M
[    0.000000]  [mem 0xcfe00000-0xcff6ffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x100000000-0x17fffffff]
[    0.000000]  [mem 0x100000000-0x17fffffff] page 2M
[    0.000000] BRK [0x01743000, 0x01743fff] PGTABLE
[    0.000000] ACPI: RSDP 00000000000fb160 00014 (v00 ACPIAM)
[    0.000000] ACPI: RSDT 00000000cff70000 0003C (v01 A_M_I_ OEMRSDT  08000904 MSFT 00000097)
[    0.000000] ACPI: FACP 00000000cff70200 00084 (v02 A_M_I_ OEMFACP  08000904 MSFT 00000097)
[    0.000000] ACPI: DSDT 00000000cff70440 0AEE4 (v01  A1276 A1276001 00000001 INTL 20060113)
[    0.000000] ACPI: FACS 00000000cff88000 00040
[    0.000000] ACPI: APIC 00000000cff70390 0006C (v01 A_M_I_ OEMAPIC  08000904 MSFT 00000097)
[    0.000000] ACPI: MCFG 00000000cff70400 0003C (v01 A_M_I_ OEMMCFG  08000904 MSFT 00000097)
[    0.000000] ACPI: OEMB 00000000cff88040 00089 (v01 A_M_I_ AMI_OEM  08000904 MSFT 00000097)
[    0.000000] ACPI: HPET 00000000cff7b330 00038 (v01 A_M_I_ OEMHPET  08000904 MSFT 00000097)
[    0.000000] ACPI: OSFR 00000000cff7b370 000B0 (v01 A_M_I_ OEMOSFR  08000904 MSFT 00000097)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000]  [ffffea0000000000-ffffea0006bfffff] PMD -> [ffff8801a9600000-ffff8801af5fffff] on node 0
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x00001000-0x00ffffff]
[    0.000000]   DMA32    [mem 0x01000000-0xffffffff]
[    0.000000]   Normal   [mem 0x100000000-0x1afffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x00001000-0x0009efff]
[    0.000000]   node   0: [mem 0x00100000-0xcff6ffff]
[    0.000000]   node   0: [mem 0x100000000-0x1afffffff]
[    0.000000] On node 0 totalpages: 1572622
[    0.000000]   DMA zone: 64 pages used for memmap
[    0.000000]   DMA zone: 21 pages reserved
[    0.000000]   DMA zone: 3998 pages, LIFO batch:0
[    0.000000]   DMA32 zone: 13246 pages used for memmap
[    0.000000]   DMA32 zone: 847728 pages, LIFO batch:31
[    0.000000]   Normal zone: 11264 pages used for memmap
[    0.000000]   Normal zone: 720896 pages, LIFO batch:31
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
[    0.000000] ACPI: IOAPIC (id[0x04] address[0xfec00000] gsi_base[0])
[    0.000000] IOAPIC[0]: apic_id 4, version 32, address 0xfec00000, GSI 0-23
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000
[    0.000000] smpboot: Allowing 4 CPUs, 0 hotplug CPUs


Note the *BAD*gran_size messages. I made no changes in the .config from 3.9.2 to 3.9.7; I ran make oldconfig and answered no the the 'NEW" stuff [BFQ and the RTC options].

The memory is good, there is no hardware problem. I can boot to 3..9.2 with no errors, but 3.9.7, built with the same .config, yields the above. What else, other then BFQ and the RTC options, could be different and cause the errors? I can eliminate the errors by manually specifying mtrr gran size and chunk size 512M on the boot line, but it effectively causes loss of use of 500MB of memory, so that is certainly not desirable.
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Sun Jul 21, 2013 4:57 pm    Post subject: Reply with quote

thunderrd wrote:
Regarding 3.9.7, I have something strange happening.
Note the *BAD*gran_size messages. I made no changes in the .config from 3.9.2 to 3.9.7;

Could this be kot's troubles related ?
_________________
Back to top
View user's profile Send private message
thunderrd
n00b
n00b


Joined: 20 Aug 2010
Posts: 36

PostPosted: Mon Jul 22, 2013 3:50 am    Post subject: Reply with quote

I'm not sure if it is the same, since I don't know if he was using 3.9.2 previously with no problems. It does appear to be related, though, and after more research I see that people have been noticing it since 3.9.5.

3.9.7 isn't a must for me, so I guess it would be most prudent to wait for 3.10, since Linus is throwing profanities around to get the code right on that one. :)

All kidding aside, it looks like the patches will go into 3.10, so rather than go crazy patching manually, I'll just wait.
Back to top
View user's profile Send private message
thunderrd
n00b
n00b


Joined: 20 Aug 2010
Posts: 36

PostPosted: Tue Jul 23, 2013 3:23 pm    Post subject: Reply with quote

Interestingly enough, as an experiment I downloaded a 3.10 source tarball from LKA and patched it with 3.10-sched-bfs-440.patch

Then I compiled it with the current options and the error does not exist. I don't know what that means; either the issue is solved for 3.10 [and the 3.10.x ck-sources will also be OK], or it was present only in the ck-sources package for >3.9.2, or the issue is caused by some other patch that is present in ck-sources-3.9.7.
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Tue Jul 23, 2013 3:46 pm    Post subject: Reply with quote

thunderrd wrote:
Interestingly enough, as an experiment I downloaded a 3.10 source tarball from LKA and patched it with 3.10-sched-bfs-440.patch

Then I compiled it with the current options and the error does not exist. I don't know what that means; either the issue is solved for 3.10 [and the 3.10.x ck-sources will also be OK], or it was present only in the ck-sources package for >3.9.2, or the issue is caused by some other patch that is present in ck-sources-3.9.7.

You mean you downloaded a 3.10.2 ?
If the problem you experimented is the same than the one I had pointed to, nothing abnormal in the fact that 3.10.2 is OK with that. The problem was fixed in 3.10-rc7 and the fix went backported to 3.9.8

As far as gentoo is concerned, 3.4.54 and 3.9.11 should be on their way to portage.
_________________
Back to top
View user's profile Send private message
thunderrd
n00b
n00b


Joined: 20 Aug 2010
Posts: 36

PostPosted: Tue Jul 23, 2013 4:04 pm    Post subject: Reply with quote

aCOSwt wrote:

You mean you downloaded a 3.10.2 ?


As far as gentoo is concerned, 3.4.54 and 3.9.11 should be on their way to portage.


Eric, yes, it was 3.10.2.

So, if I understand you correctly, gentoo packages >3.9.8 will have the fix. What is the next planned ck- package?
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Tue Jul 23, 2013 4:37 pm    Post subject: Reply with quote

thunderrd wrote:
So, if I understand you correctly, gentoo packages >3.9.8 will have the fix.

Yes indeed if the problem you faced was the one I had pointed to.
thunderrd wrote:
What is the next planned ck- package?

As I said 3.4.54 and 3.9.11 are on their way to portage

As far as 3.10 is concerned... mhhh... I have experienced multiple problems with this branch. Mainly ACPI centered.
And considering I do not quite like experiencing ACPI troubles at this time of the year... :D
Moreover, inferring the -rc grade of first 3.10 stable from Greg's comments and understanding he would backport less than a tenth of his 200 patches on 3.10.1...
Well...
I'll wait for 3.10.3 before coming back to work on 3.10
_________________
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Tue Jul 23, 2013 4:51 pm    Post subject: Reply with quote

Following BUG 477916 and thanks to Tom Wijsman, the ck-sources tree has been updated.

3.9 users should upgrade to 3.9.11,
3.4 users should upgrade to 3.4.54
_________________
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1159

PostPosted: Tue Jul 23, 2013 9:25 pm    Post subject: Reply with quote

aCOSwt wrote:
Moreover, inferring the -rc grade of first 3.10 stable from Greg's comments and understanding he would backport less than a tenth of his 200 patches on 3.10.1...
Well...
I'll wait for 3.10.3 before coming back to work on 3.10

Isn't it better to wait for 3.10.6 or something? Let me explain: Greg for long is angry about the BETA quality of .0 kernel releases. In the last discussion it turns out: Kernel devs fear Linus rejecting code in the late run of a release. They hold back important work. Slowly it then gets included into releases of .1 .2 and .3. But these patches are not anywhere tested at this point. This may lead to the fact the very first stable and tested kernel is a point.six :( :( :( :( :( :(

I'm following newest kernel releases for quiet a long time now. I would surely get a rich man if I could bet about it: Also if one release gets stable quality at point.five and two out of ten get stable at point.seven or eight, in the long run I won my bet.
_________________
fun2gen2
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Tue Jul 23, 2013 11:23 pm    Post subject: Reply with quote

ulenrich wrote:
Isn't it better to wait for 3.10.6 or something? Let me explain...

:D Let me explain : In one word : Holidays!

You'll certainly have noticed than, since I maintain this package, I've never rushed on early releases and essentially concentrate on high release numbers. You'll certainly have noticed as well the color code I use when announcing version bumps.

I think that the gentoo's sys-kernel/ck-sources is the only package offering high release numbers with the ck patchset. That is it's originality, I leave to others the passion of high version numbers. (no disrespect)

I think that 3.9.2 is the earliest release I have made and this was because I knew that Ant P. needed something to replace his non-working 3.8

This time I will target 3.10.3 only because... I expect being far away from keyboards in August and, as a consequence,... be back in 3.10.7 times.

Because there are users of the ck-sources package who believe in the virtues of rolling releases, who are eager to test new versions, and that is also nice, I just feel I could not abandon them without biscuits until 3.10.7 is out, could I ?
ulenrich wrote:
This may lead to the fact the very first stable and tested kernel is a point.six

Hmmm... This can also make so a 3.9.7 shows regressions toward a 3.9.2...
This probably "because this time we'll do it right".
_________________
Back to top
View user's profile Send private message
TomWij
Developer
Developer


Joined: 04 Jul 2012
Posts: 1551

PostPosted: Tue Jul 23, 2013 11:39 pm    Post subject: Reply with quote

ulenrich wrote:
Isn't it better to wait for 3.10.6 or something? Let me explain: Greg for long is angry about the BETA quality of .0 kernel releases.


As rc versions come packed with new features, releases like .0 can be problematic in terms of stability; after a few releases, quite some patches / fixes have landed to fix the introduced bugs and things become more stable. For this reason, on Gentoo, we stabilize the end of a branch (eg. 3.8.13 stable, 3.9.11 to stabilize very soon); out of branch ends available, the versions near the end of a recent branch look the most stable to us.

ulenrich wrote:
In the last discussion it turns out: Kernel devs fear Linus rejecting code in the late run of a release. They hold back important work.


Yes and no; some developers also end up being late with their changes, so they don't make it in time for the rc kernels and rather push things through to stable. They (Linus and Greg) are putting an end to this style.

aCOSwt wrote:
You'll certainly have noticed than, since I maintain this package, I've never rushed on early releases and essentially concentrate on high release numbers. You'll certainly have noticed as well the color code I use when announcing version bumps.


Good idea.

aCOSwt wrote:
This time I will target 3.10.3 only because... I expect being far away from keyboards in August and, as a consequence,... be back in 3.10.7 times.


As a heads up (not sure if you follow stable ML), the patches are now under review and test answers are expected by Friday; so, I expect this release to land around Saturday.

aCOSwt wrote:
Because there are users of the ck-sources package who believe in the virtues of rolling releases, who are eager to test new versions, and that is also nice, I just feel I could not abandon them without biscuits until 3.10.7 is out, could I?


Sometimes you have to, you could look for someone to take care of it for you; if you can find someone...

aCOSwt wrote:
Hmmm... This can also make so a 3.9.7 shows regressions toward a 3.9.2...
This probably "because this time we'll do it right".


But that's a lot less likely than the way 3.9.2 shows regressions over 3.8.13; the amount of patches on 5 releases is rather minimal, if you calculate the percentage a patch is a regression you'll find maybe one, two, three or four commits or so; most of which only affect some users. Compare that to all the new functionality, rewrites and so on that comes with a 3.9; a lot of regressions are to be find therein, which is what the patches end up dealing with. So, a kernel that really gets things right might be 3.4.54; but then again, perhaps it contains some regressions that only new functionality or a rewrite could solve...

Picking the right kernel version to push / stabilize / run, it's a whole fun debate on its own; there's some agreement and disagreement, I think there are certainly people that would advocate the opposite...
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Wed Jul 24, 2013 9:24 am    Post subject: Reply with quote

TomWij wrote:

aCOSwt wrote:
Because there are users of the ck-sources package who believe in the virtues of rolling releases, who are eager to test new versions, and that is also nice, I just feel I could not abandon them without biscuits until 3.10.7 is out, could I?

Sometimes you have to, you could look for someone to take care of it for you; if you can find someone...

The fact here is that 3.10-ck will... whisper it not... need a local patch.
Of course I know half a dozen of guys capable of taking care of the package for me, but...
Hmmm... how could I say... :
No one of them feel capable of the actually considerable amount of energy usually needed to make a patch find its way to the files directory... :wink:
_________________
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9  Next
Page 6 of 9

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum