RFE: Switch usbhid.pb_fnmode to 2 for Macbook Pro users
by Christopher Brown
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
16 years, 2 months
IRC.
by Dave Jones
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
16 years, 2 months
Fun with ALSA
by Chuck Ebbert
We should consider carrying the latest ALSA patchset in Fedora.
That way we wouldn't be forever chasing bugs they have already
fixed...
16 years, 2 months
FC7 kernel not best confugured for kdump
by Richard J Moore
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
16 years, 2 months
Fedora 6/7 kernel update plans
by Chuck Ebbert
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.
16 years, 2 months
PAE versus HIGHMEM64
by Thorsten Leemhuis
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...
> [...]
> + * 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...
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
16 years, 2 months
CONFIG_DEBUG_STACKOVERFLOW hurts
by Eric Sandeen
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
16 years, 2 months
bugzilla triage.
by Dave Jones
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
16 years, 2 months
New kernel option in F8/devel: libata.pata_dma
by Chuck Ebbert
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.
16 years, 2 months
