kernel September 2007

kernel@lists.fedoraproject.org

18 participants
15 discussions

RFE: Switch usbhid.pb_fnmode to 2 for Macbook Pro users
by Christopher Brown 27 Sep '07

27 Sep '07

Hello, It would appear Macbook Pro users need to additionally press the fn key to make F1 - F10 work as expected under Linux. Therefore to switch to a vt they have to perform a wierd kind of hand twister to get it to work as it now requires Ctrl+Alt+Fn+F1. Macbook user Alexey Kuznetsov wrote to me and said: To solve this problem i send echo "2" to /sys/module/hid/parameters/pb_fnmode every time on boot. But i this is a good idea to set this feature by default for all fedora 7 users. I solve it by small startup service here is ti: #!/bin/bash # # chkconfig: 12345 90 01 # description: fix apple fn keys . /etc/init.d/functions echo "2">/sys/module/hid/parameters/pb_fnmode action "Starting the Mac Function keys fix:" to which I replied: " ... you can also just add: options usbhid pb_fnmode=2 to modprobe.conf and I think: usbhid.pb_fnmode=2 being added to the kernel parameters as well. I will post an RFE to the fedora-kernel list." Is it possible to enable this by default - the green lizards seem to have done so: https://bugzilla.novell.com/show_bug.cgi?id=220266 Cheers Chris -- http://www.chruz.com

3 2

IRC.
by Dave Jones 27 Sep '07

27 Sep '07

I've created a #fedora-kernel channel on freenode in response to the large number of /msg's I continue to get which really should be going to a wider audience. I expect it to be low-traffic, but it may be a worthwhile experiment to see if it helps any for triage, coordination etc. Dave -- http://www.codemonkey.org.uk

5 5

Fun with ALSA
by Chuck Ebbert 26 Sep '07

26 Sep '07

We should consider carrying the latest ALSA patchset in Fedora. That way we wouldn't be forever chasing bugs they have already fixed...

3 2

FC7 kernel not best confugured for kdump
by Richard J Moore 25 Sep '07

25 Sep '07

I've been checking out kdump on FC7. There are a couple of kernel config options cause the crash utility some issues. These are CONFIG_PHYSICAL_ALIGN=4MB and CONFIG_PHYSICAL_START=16MB. When the values differ on a reclocatable kernel we loose the ability to make line number references to the code addresses (vmlinux will have line numbers relative to START, kallsyms will reflect ALIGN). This wouldn't be the case if ALIGN and START were both 16MB. Is there is advantage in not doing that? If there isn't can we make a point of building future release kernels with the two values equal? Richard Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

1 0

Fedora 6/7 kernel update plans
by Chuck Ebbert 21 Sep '07

21 Sep '07

Fedora 6: leave on 2.6.22 until end-of-life There are so many workarounds and backwards-compatibility issues in there that it just doesn't seem worthwhile to upgrade. Fedora 7: update to 2.6.23 after Fedora 8 is released May as well update, the issues aren't nearly so great and users will probably want the latest kernel.

3 2

Enabling Secure Computing (SECCOMP)
by Chuck Ebbert 20 Sep '07

20 Sep '07

We have a bug report requesting that we enable SECCOMP: https://bugzilla.redhat.com/show_bug.cgi?id=295841 I suggest we enable it in Fedora 8 but leave it disabled in F7. That way we're not changing a config item in a stable release, and we don't have to carry patches to lower the feature's overhead and make its API match 2.6.23's.

4 4

PAE versus HIGHMEM64
by Thorsten Leemhuis 17 Sep '07

17 Sep '07

On 15.09.2007 18:27, fedorawiki-noreply(a)fedoraproject.org wrote: > You have subscribed to a wiki page or wiki category on "Fedora > Project Wiki" for change notification. > > The following page has been changed by PaulFrields: > http://fedoraproject.org/wiki/Docs/Beats/Kernel?action=diff&rev2=112&rev1=1… > [...] > + * The kernel-PAE, for use in 32-bit x86 systems with more > than 4GB of RAM, or with CPUs that have a NX (No eXecute) feature. > This kernel support both uniprocessor and multi-processor systems. > Configured sources are available in the `kernel-PAE-devel` package. This reminded me of: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h… Quoting Patch description: > i386: divorce CONFIG_X86_PAE from CONFIG_HIGHMEM64G > > PAE is useful for more than supporting more than 4GB RAM. It supports > expanded swapspace and NX executable protections. Some users may want NX > or expanded swapspace support without the overhead or instability of > highmem. For these reasons, the following patch divorces CONFIG_X86_PAE > from CONFIG_HIGHMEM64G. Which brings me to the point why I'm writing this mail: should we enable PAE by default after F8 is out and ship a HIGHMEM64G-Kernel instead on x86-32? Then normal users on x86-32 can benefit from NX by default. Or is that considered "not worth the trouble because we ship execshield already"? Further: Does PAE-by-default still make lots of machines unbootable (I doubt that for newer machines, as some-well-known-other-os enables PAE since its service pack 2 by default iirc)? If we suspect it still does: could we fix that by some kind of automatic "if machine is newer than ${year}" check in the kernel? Just wondering. CU knurd

2 2

CONFIG_DEBUG_STACKOVERFLOW hurts
by Eric Sandeen 17 Sep '07

17 Sep '07

I sent this same message to LKML a while ago, but thought I'd get it a more targeted audience: ========================= Noticed today that the combination of 4KSTACKS and DEBUG_STACKOVERFLOW config options is a bit deadly. DEBUG_STACKOVERFLOW warns in do_IRQ if we're within THREAD_SIZE/8 of the end of useable stack space, or 512 bytes on a 4k stack. If we are, then it goes down the dump_stack path, which uses most, if not all, of the remaining stack, thereby turning a well-intentioned warning into a full-blown catastrophe. The callchain from the warning looks something like this, with stack usage shown as found on my x86 box: 4 dump_stack 4 show_trace 8 show_trace_log_lvl 4 dump_trace print_context_stack 12 print_trace_address print_symbol 232 __print_symbol 164 sprint_symbol 20 printk ___ 448 448 bytes to tell us that we're within 512 bytes (or less) of certain doom... and I think there's call overhead on top of that? The large stack usage in those 2 functions is due to big char arrays, of size KSYM_NAME_LEN (128 bytes) and KSYM_SYMBOL_LEN (223 bytes). IOW, the stack warning effectively reduces useful stack left in our itty bitty 4k stacks by over 10%. ... ========================= In light of this, I'd like to propose that we turn off DEBUG_STACKOVERFLOW in Fedora, at least on x86/4KSTACKS. I think it does more harm than good; the warning is going to turn deadly most of the time. I also had sent a patch to LKML to print whether or not the stack was overflowing, or had ever overflowed, on a kernel panic. It's not yet been merged. ... any comments? I can file a bug but thought some discussion might be in order. Thanks, -Eric

3 12

bugzilla triage.
by Dave Jones 16 Sep '07

16 Sep '07

The current state of bugzilla for the kernel is pretty depressing. Counting in all the bugs we never fixed for FC5 (a lot of which are probably still valid for everything through to rawhide), there are around 1600 open bugs. In an attempt to disperse some of the 'triage' type work to volunteers, I've started a page at http://fedoraproject.org/wiki/KernelBugTriage with some simple things that people can do to help out. Any additions/improvements welcomed. Dave -- http://www.codemonkey.org.uk

2 1

New kernel option in F8/devel: libata.pata_dma
by Chuck Ebbert 12 Sep '07

12 Sep '07

I just checked in a patch from Alan that allows selectively disabling DMA on libata PATA drives: libata.pata_dma= [LIBATA] libata.pata_dma=0 Disable all PATA DMA like old IDE libata.pata_dma=1 Disk DMA only libata.pata_dma=2 ATAPI DMA only libata.pata_dma=4 CF DMA only These can be combined, e.g. libata.pata_dma=3 will enable DMA on disks and ATAPI devices (mainly CD-ROM) while leaving it disabled on Compact Flash. This should allow installation on systems where DMA doesn't work, so the problem can be fixed later by a kernel update.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel September 2007