2.6.20-1.2925 hangs after unmounting old proc and sys
by Daniel Kirsten
Hallo,
my compiled 2.6.20-1.2925 kernel does not boot.
It hangs after unmounting the old proc and
sys filesystems. However, I can still use
Ctrl+Alt+Del to reboot.
Maybe, the problem is related to Selinux.
My compiled kernels 2.6.19-1.2895 and 2.6.19-1.2911
worked fine, and I did not change the kernel
configuration.
The Fedora-kernels 2.6.19-1.2895, 2.6.19-1.2911 and
2.6.20-1.2925 also work.
Best regards, Daniel
17 years
2.6 kernel, switch/case statement and stack usage
by Constantine Gavrilov
Hello:
I have run into an annoying problem writing some kernel code in AS 4
update 4 environment. I was seeing stack overflows and found the problem.
Some not very long case/switch cases (15-25 statements) are compiled by
gcc compiler to use between 500 and 2000 bytes of stack space. This even
for using enums that run from 0 to N without holes (in which case gcc
optimizer is supposed to generate a table). Kbuild is used to build all
code, I do not use stack variables at all (except for 2 or 3 ints and
function args), and some of the code is even as simple as calling a
separate function for each case statement.
Re-writing the code to use a call function table for consecutive enums
solved the problem in that specific code -- nearly 0 stack usage. But
there is also code that uses kernel non-consecutive enums and does not
necessarily call functions for case entries (these are also most
problematic places where compiler "eats" up to 2 KB of stack). Writing
my own hash implementation and jump table instead of switch/case
statement seems an annoying ugly hack to me even though I can do it.
Is it a known gcc/kernel 4K stack limitation (i.e. switch/case is a
problem in 2.6 with 4K stack)? Is there an option to tell gcc "stack is
small, do not over-use it" ?
My concern is that there is core kernel code affected by this. I do not
think the problem is specific to AS 4, but will show up in Fedora as well.
I am sure there is no mistake, and the problem is switch/case construct
and not what is under case (this has been verified). BTW, using if/else
if/else if generates nearly identical code and does not solve the stack
usage problem.
Comments?
--
----------------------------------------
Constantine Gavrilov
Kernel Developer
Qlusters Software Ltd
1 Azrieli Center, Tel-Aviv
Phone: +972-3-6081977
Fax: +972-3-6081841
----------------------------------------
17 years
What use is the kernel-debuginfo package?
by Chuck Ebbert
I can't get a combined source/disassembly listing from objdump
using the kernel-debuginfo package:
1) objdump has no clue how to use the separate debug info:
http://sourceware.org/bugzilla/show_bug.cgi?id=4030
No activity, bug is unassigned.
2) The path to the debug info is wrong anyway. In fact, there _is_
no path info in the .gnu_debuglink section of the kernel modules:
$ objdump -j .gnu_debuglink -D ahci.ko
ahci.ko: file format elf32-i386
Disassembly of section .gnu_debuglink:
00000000 <.gnu_debuglink>:
0: 61 popa
1: 68 63 69 2e 6b push $0x6b2e6963
6: 6f outsl %ds:(%esi),(%dx)
7: 2e 64 65 62 75 67 bound %esi,%cs:%fs:%gs:0x67(%ebp)
d: 00 00 add %al,(%eax)
f: 00 21 add %ah,(%ecx)
11: 25 .byte 0x25
12: 80 .byte 0x80
13: c9 leave
This decodes to "ahci.ko.debug" plus a checksum, but it should read
"/usr/lib/debug/lib/modules/2.6.20-1.2925.fc6/kernel/drivers/ata/ahci.ko.debug"
So my question is, who uses this debug info and how do they use it???
17 years
sparse checking
by Jon Masters
Red Hat Buildsystem wrote:
> Package: kernel-2.6.20-1.3010.fc7
> Tag: dist-fc7
> Status: failed
> Built by: davej
> ID: 58684
> Started: Thu, 22 Mar 2007 01:48:43 EDT
> Finished: Thu, 22 Mar 2007 02:11:24 EDT
> Changelog:
> * Thu Mar 22 2007 Dave Jones <davej(a)redhat.com>
> - Check source with sparse during build.
Very cool.
Jon.
17 years
2.6.20-1.2999.fc7 and suspend
by Bill Peck
Suspend to ram does not work with 2.6.20-1.2999.fc7 on an Asus Pundit
P3-PH5, Dual core Intel.
I know desktops aren't specifically supported but suspend/resume does
work on this with 2.6.20-1.2925.fc6.
I'll open a proper BZ if this is expected to work at this time.
17 years