Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#58 Doesn't work in kernel 2.6.33 and higher

open
nobody
None
5
2010-05-02
2010-05-02
MadCatX
No

Since update to kernel 2.6.33.3 the module crashes while loading giving me "Killed (SIGKILL)" message in the terminal. Dmesg output looks always like this?

omnibook: Driver version 2.20090707-trunk.
omnibook: Unknown model.
omnibook: SH��H���<0t<1tM�����H��[�f�H�>H����q��¸ feature has no backend table, io_op not initialized.
omnibook: (null) feature has no backend table, io_op not initialized.
omnibook: (null) feature has no backend table, io_op not initialized.
omnibook: Begin table match of (null) feature.
BUG: unable to handle kernel paging request at 0000000000009800
IP: [<ffffffffa0bc11c9>] omnibook_probe+0x185/0x3c0 [omnibook]
PGD 11fb38067 PUD 11fb39067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/platform/coretemp.0/temp1_input
CPU 1
Modules linked in: omnibook(+) ipv6 coretemp sco bridge stp llc bnep l2cap bluetooth fuse ext2 joydev snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_hda_codec_realtek snd_pcm_oss iwlagn snd_mixer_oss snd_hda_intel snd_hda_codec snd_hwdep firewire_ohci iwlcore snd_pcm sdhci_pci psmouse snd_timer jmb38x_ms mac80211 sdhci mmc_core firewire_core iTCO_wdt toshiba_bluetooth battery ac snd soundcore snd_page_alloc video output button thermal cfg80211 rfkill led_class memstick serio_raw intel_agp i2c_i801 pcspkr crc_itu_t iTCO_vendor_support sg nvidia(P) i2c_core r8169 mii evdev cpufreq_powersave cpufreq_ondemand acpi_cpufreq freq_table processor rtc_cmos rtc_core rtc_lib ext4 mbcache jbd2 crc16 sr_mod sd_mod cdrom ahci libata scsi_mod

Pid: 6599, comm: modprobe Tainted: P 2.6.34-rc6-git1-ARCHMOD #1 KSRAA/Qosmio X300
RIP: 0010:[<ffffffffa0bc11c9>] [<ffffffffa0bc11c9>] omnibook_probe+0x185/0x3c0 [omnibook]
RSP: 0018:ffff8800a4cf9dc8 EFLAGS: 00010296
RAX: 0000000000000035 RBX: 0000000000000013 RCX: 000000000007ffff
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff814d6954
RBP: 0000000000000013 R08: 00000000ffffffff R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 4ec4ec4ec4ec4eda
R13: 0000000000009800 R14: 0000000000000000 R15: 0000000000009800
FS: 00007f7bb9922700(0000) GS:ffff880001700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000009800 CR3: 00000000a4ee0000 CR4: 00000000000406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 6599, threadinfo ffff8800a4cf8000, task ffff8800a8f1ca40)
Stack:
0000000000000000 ffffffffa0bbbd48 ffff880139084610 00000000ffffffed
<0> 0000000000000000 0000000000000000 0000000000d2cc10 ffffffff81204b14
<0> ffff880139084610 ffff880139084610 ffffffff81204cb0 ffffffff8120392c
Call Trace:
[<ffffffff81204b14>] ? driver_probe_device+0x84/0x180
[<ffffffff81204cb0>] ? __device_attach+0x0/0x60
[<ffffffff8120392c>] ? bus_for_each_drv+0x5c/0x90
[<ffffffff812049e5>] ? device_attach+0x85/0x90
[<ffffffff81204275>] ? bus_probe_device+0x25/0x40
[<ffffffff81202252>] ? device_add+0x4d2/0x5c0
[<ffffffff812064e8>] ? platform_device_add+0xe8/0x1b0
[<ffffffffa0bc1439>] ? omnibook_module_init+0x0/0x117 [omnibook]
[<ffffffffa0bc1527>] ? omnibook_module_init+0xee/0x117 [omnibook]
[<ffffffff810002e4>] ? do_one_initcall+0x34/0x1a0
[<ffffffff8106fc3c>] ? sys_init_module+0xdc/0x250
[<ffffffff81002deb>] ? system_call_fastpath+0x16/0x1b
Code: 89 f2 48 c7 c6 a4 89 bb a0 48 c7 c7 b0 98 bb a0 e8 31 29 71 e0 4d 85 ed 75 3d eb 16 41 ff c6 4d 63 fe 4d 6b ff 30 4f 8d 7c 3d 00 <41> 8b 07 85 c0 75 8a 48 6b db 68 48 c7 c6 a4 89 bb a0 48 8b 93
RIP [<ffffffffa0bc11c9>] omnibook_probe+0x185/0x3c0 [omnibook]
RSP <ffff8800a4cf9dc8>
CR2: 0000000000009800
---[ end trace 78319b4de18baeac ]---

I tried in 2.6.33.3 vanilla and with CK patches and in 2.6.34-rc6-git1 with the suggested patch for lcd.c. The results are always the same. In 2.6.33.2 it was OK.

Related

Bugs: #1

Discussion

<< < 1 2 3 > >> (Page 2 of 3)
  • MadCatX
    MadCatX
    2010-06-01

    I just tested it, disabling iwlagn and r8169 makes no difference.

     
  • Insomniak
    Insomniak
    2010-06-01

    Same problem, but i don't have realtek wifi card...
    I have ethernet realtek card and atheros wifi card.

    My model is Toshiba A300D and i run Archlinux x64 with kernel 2.6.33.

     
  • Insomniak
    Insomniak
    2010-06-05

    Can you share the new realtek driver ?

     
  • Eli Wapniarski
    Eli Wapniarski
    2010-06-07

    Yes, I can.... I received permission to do so. And I am attaching the file.

     
  • Eli Wapniarski
    Eli Wapniarski
    2010-06-07

    OK??? Maybe not.... How does one attache a file to the attached file section?

     
  • Insomniak
    Insomniak
    2010-06-07

    lol that's a good question...

    Maybe we need some specific rights to do so. Upload it somewhere, and let admins attach the file...

     
  • Ryan Martin
    Ryan Martin
    2011-01-13

    I've tracked this to an alignment issue in the initialization code. This
    module uses a section(.features) directive to register all of its features
    into a portion of the .data section, and then defines a start and end
    pointer via sections.lds which it pulls back into init.c. It then iterates
    over &_start_features_driver[i] to test all of the defined features, one at
    a time.

    The failed paging request appears to be happening because of unexpected
    linker behavior, possibly only on x86_64, and possibly due to a change in
    GNU ld or gcc since 2007. I used objdump -t on omnibook.ko, and found that
    while the sizeof(omnibook_feature) was 104, the alignment was sometimes 104
    and sometimes 108. This caused the array math in the feature loop to
    misaddress the struct omnibook_feature found in the .feature section,
    eventually leading to invalid calls and the above crash.

    Now, I'm not a kernel hacker, and I haven't done any C programming since
    college. I fixed this on my Toshiba Satellite L355D-S7901 running kernel
    2.6.35 on arch x86_64 by padding struct omnibook_feature to 128 bytes, via
    a char pad[24] at the end of the struct. Perhaps someone who is a more
    skilled C programmer or kernel hacker can think of a better way to make
    this work, and to guarantee that it works on both 32 and 64 bit
    architectures.

    Patches available at https://bugzilla.redhat.com/show_bug.cgi?id=669239

     
  • Rolf Eike Beer
    Rolf Eike Beer
    2011-01-13

    I have the same issue with the padding on x86, there I need 12 byte as padding. I suggest adding a "long pad[3]" at the end instead of the "char pad[24]".

     
  • Index.. Great idea :)

     
<< < 1 2 3 > >> (Page 2 of 3)