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.
First off I am very pleased to report that your omnibook works with Toshiba Qosmio x500-s1801 with parameters userset=1 ectype=12.
However, I just upgraded from Fedora 12 to 13 along with the kmod and akmod modules from rpmfusion. The versions of the relevant rpms are:
rpm -qa | grep omnibook
kmod-omnibook-2.6.33.4-95.fc13.x86_64-2.20090714-0.4.svn288.fc13.6.x86_64
omnibook-2.20090714-0.5.svn288.fc13.noarch
akmod-omnibook-2.20090714-0.4.svn288.fc13.5.x86_64
kmod-omnibook-2.6.32.12-115.fc12.x86_64-2.20090714-0.4.svn288.fc13.5.x86_64
kmod-omnibook-2.20090714-0.4.svn288.fc13.6.x86_64
The current version of the kernel is: 2.6.33.4-95.fc13.x86_64
When I boot into: 2.6.32.12-115.fc12.x86_64
All is well.
Also, bug reported at rpmfusion at:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=1236
and mentioned at:
https://bugzilla.redhat.com/show_bug.cgi?id=581369
Thanks for your attention on this matter.
Could you post your dmesg output here? I'm curious to see if it will be anything alike mine.
As you can see from my dmesg output, the driver doesn't crash. It just doesn't work :(
omnibook: Driver version 2.20090707-trunk.
omnibook: Forced load with EC type 12.
omnibook: Begin table match of ac feature.
omnibook: Returning table entry nr 0.
omnibook: Begin table match of battery feature.
omnibook: Returning table entry nr 0.
omnibook: Begin table match of blank feature.
omnibook: Try to init cdimode
omnibook: Fail to find a supported LPC I/O bridge, please report
omnibook: Backend compal init failed, skipping entry.
omnibook: Returning table entry nr 1.
omnibook: LCD backlight turn off at console blanking is enabled.
omnibook: Begin table match of bluetooth feature.
omnibook: Try to init ACPI backend
omnibook: ACPI EC device found
omnibook: hook_connect for device AT Translated Set 2 keyboard.
omnibook: Enabling Toshiba Bluetooth ACPI device.
omnibook: ACPI backend init OK
omnibook: Returning table entry nr 0.
omnibook: BTST raw_state: c1
omnibook: Begin table match of cooling feature.
omnibook: CDI backend init already failed, skipping.
omnibook: Backend compal init failed, skipping entry.
omnibook: Match failed: disabling cooling.
omnibook: Begin table match of display feature.
omnibook: ACPI backend has already been initialized
omnibook: Returning table entry nr 0.
omnibook: Init function of display failed with error -19.
omnibook: Trying to dispose ACPI backend
omnibook: Begin table match of hotkeys feature.
omnibook: CDI backend init already failed, skipping.
omnibook: Backend compal init failed, skipping entry.
omnibook: Match failed: disabling hotkeys.
omnibook: dmi feature has no backend table, io_op not initialized.
omnibook: version feature has no backend table, io_op not initialized.
omnibook: Begin table match of lcd feature.
omnibook: CDI backend init already failed, skipping.
omnibook: Backend compal init failed, skipping entry.
omnibook: Returning table entry nr 2.
omnibook: Begin table match of temperature feature.
omnibook: Returning table entry nr 0.
omnibook: Begin table match of touchpad feature.
omnibook: CDI backend init already failed, skipping.
omnibook: Backend compal init failed, skipping entry.
omnibook: Match failed: disabling touchpad.
omnibook: Begin table match of wifi feature.
omnibook: ACPI backend has already been initialized
omnibook: Returning table entry nr 0.
omnibook: BTST raw_state: c1
omnibook: Begin table match of throttling feature.
omnibook: ACPI backend has already been initialized
omnibook: Returning table entry nr 0.
omnibook: Enabled features: ac battery blank bluetooth dmi version lcd temperature wifi throttling.
I need to make a correction
The output below should have had a additional line after the omnibook ACPIEC device line and should look like this.
That's what you get for the not paying attention to ones grep :)
omnibook: ACPI EC device found
input: Omnibook ACPI scancode generator as /devices/virtual/input/input10
omnibook: hook_connect for device AT Translated Set 2 keyboard
Seems to be working again with:
kernel-2.6.33.5-112.fc13.x86_64
kmod-omnibook-2.6.33.5-112.fc13.x86_64-2.20090714-0.4.svn288.fc13.7.x86_64
omnibook-2.20090714-0.5.svn288.fc13.noarch
akmod-omnibook-2.20090714-0.4.svn288.fc13.5.x86_64
kmod-omnibook-2.6.32.12-115.fc12.x86_64-2.20090714-0.4.svn288.fc13.5.x86_64
I spoke too soon. And I found out what's causing this. And I have no way to know who the real culprit is. But, it turns out that the omnibook drivers were working all along. However, there seems to be somekind of comflict between the omnibook driver and drivers supplied by realtek for the 8192 wifi card. If I do not have the wifi driver installed, then bluetooth is working just fine. Once the wifi driver is installed, bluetooth seems to be working but the computer and my bluetooth devices don't seem to want to communicate properly with each other. What I mean by that, is that bluettooth seems to recognize that there is a device but I can't get passed that stage. How I know that, is if I delete the device and then try to create a new relationship I can see the mac addess of the device but then I do not see bluetooth recognizing the name of the device and bluetooth reports that it fails to establish a connection.
The realtek driver can be found at:
http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=48&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true#RTL8192SU
Opps the link should read
http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PNid=48&PFid=48&Level=5&Conn=4&DownTypeID=3&GetDown=false&Downloads=true#RTL8192SE
I've reported the problem to tech support over at realtek via email.
You might be on to something, but this problem is definitely not specific to Realtek 8192 module. I have Intel Wifi 5100 (module iwlagn) and Realtek R8168B network adapter (module r8169). I will try to disable both of these modules to see if it makes any difference.
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 :)
This is fixed in the latest revision in the omnibook git repo, see http://sourceforge.net/projects/omnibook/develop for the git link.