Doesn't work in kernel 2.6.33 and higher
Status: Alpha
Brought to you by:
math_b
Menu
▾
▴
#58 Doesn't work in kernel 2.6.33 and higher
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.
I just tested it, disabling iwlagn and r8169 makes no difference.
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.
After reporting the problem with Realtek, I received a new driver from them via email which does not seem to be yet posted on their website. I have asked for permission to post it. After installing them all was well. Everything seems to be working the way it should.
The version of the omnibook drivers that is being distributed at rpmfusion (Fedora distros) dated 20090714 and the source RPM contains a couple of patches...
Which contains the a300 patch at:
https://sourceforge.net/tracker/?func=detail&aid=2841062&group_id=174260&atid=868544
and the "warning " patch at
https://sourceforge.net/tracker/?func=detail&aid=2703528&group_id=174260&atid=868544
Everything seems to be OK.
Dunno if this helps, but I hope so.
Can you share the new realtek driver ?
Yes, I can.... I received permission to do so. And I am attaching the file.
OK??? Maybe not.... How does one attache a file to the attached file section?
lol that's a good question...
Maybe we need some specific rights to do so. Upload it somewhere, and let admins attach the file...
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
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 :)