asus_eee/i2c driver fails w/NULL pointer exception on 1000HE

ChrisMX6 · **Posted:** Wed Jun 24, 2009 9:17 am

Hello fellow Eeebuntu users. I've just jumped into the Eee world, and loving it so far but it seems that support for my shiny new 1000HE is not entirely there.

The asus_eee module doesn't seem to be able to operate: with both the 2.6.28-12-netbook and 2.6.29-1-netbook kernels, there is an exception during boot.

Code:

[   11.510912] BUG: unable to handle kernel NULL pointer dereference at 0000000c
[   11.510926] IP: [<c03384ac>] i2c_smbus_xfer+0x1a/0x8b
[   11.510945] *pde = 00000000
[   11.510953] Oops: 0000 [#1] SMP
[   11.510961] last sysfs file: /sys/kernel/uevent_seqnum
[   11.510968] Modules linked in: asus_eee(+) i2c_i801 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi arc4 snd_seq_midi_event ecb snd_seq joydev snd_timer snd_seq_device ath9k serio_raw mac80211 cfg80211 snd psmouse pcspkr iTCO_wdt iTCO_vendor_support intel_agp led_class soundcore snd_page_alloc agpgart video output eeepc_laptop atl1e ehci_hcd uhci_hcd fuse
[   11.511049]
[   11.511057] Pid: 2463, comm: modprobe Not tainted (2.6.29-1-netbook #0array1) 1000HE
[   11.511065] EIP: 0060:[<c03384ac>] EFLAGS: 00010286 CPU: 0
[   11.511075] EIP is at i2c_smbus_xfer+0x1a/0x8b
[   11.511081] EAX: 00000000 EBX: f6b93f0a ECX: 00000000 EDX: 00000069
[   11.511088] ESI: 00000069 EDI: 00000000 EBP: f6b93ef0 ESP: f6b93ed4
[   11.511095]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   11.511103] Process modprobe (pid: 2463, ti=f6b92000 task=f6488000 task.ti=f6b92000)
[   11.511109] Stack:
[   11.511113]  c0157a86 f6b93fa0 c014b8f0 001ca018 f6b93f0a 00000069 f81d7130 f6b93f38
[   11.511131]  c0338656 00000001 00000000 00000005 f6b93f0a f81ca018 f81c9f74 f65ed0b0
[   11.511150]  f81ca630 0000000f f6b93f2c c0416300 f6b93f34 00000000 f81d6ff0 fffffffc
[   11.511171] Call Trace:
[   11.511176]  [<c0157a86>] ? stop_machine_destroy+0x3a/0x3c
[   11.511190]  [<c014b8f0>] ? load_module+0xc4e/0xdd1
[   11.511208]  [<c0338656>] ? i2c_smbus_read_block_data+0x28/0x52
[   11.511229]  [<c0416300>] ? mutex_lock+0xe/0x1e
[   11.511251]  [<f81d618a>] ? init_module+0x2f/0x4f [asus_eee]
[   11.511265]  [<c010113a>] ? _stext+0x4a/0x11d
[   11.511276]  [<f81d615b>] ? init_module+0x0/0x4f [asus_eee]
[   11.511294]  [<c013e40d>] ? __blocking_notifier_call_chain+0x40/0x4c
[   11.511315]  [<c014bbc4>] ? sys_init_module+0x87/0x186
[   11.511326]  [<c0102f6b>] ? sysenter_do_call+0x12/0x2f
[   11.511338]  [<c0410000>] ? cpuid4_cache_lookup+0x5c/0x2b7
[   11.511351] Code: ba 39 d0 7d ee 31 d2 8d 65 f4 89 d0 5b 5e 5f 5d c3 55 83 e1 14 89 e5 0f b7 c9 57 89 c7 56 0f b7 d2 53 83 ec 10 8a 45 0c 88 45 f3 <8b> 47 0c 83 78 04 00 0f be 45 08 89 4d ec 89 55 e8 89 45 e4 74
[   11.511453] EIP: [<c03384ac>] i2c_smbus_xfer+0x1a/0x8b SS:ESP 0068:f6b93ed4
[   11.511470] ---[ end trace 8204d4a7691066c3 ]---

The above output is from a fully-updated NBR 3.0.1 system, as of yesterday. The end result is that the driver is non-functional.

Code:

$ ls /proc/eee
ls: cannot access /proc/eee: No such file or directory

Can anyone help?

fewt · **Posted:** Wed Jun 24, 2009 1:15 pm

ChrisMX6 wrote:

Hello fellow Eeebuntu users. I've just jumped into the Eee world, and loving it so far but it seems that support for my shiny new 1000HE is not entirely there.

The asus_eee module doesn't seem to be able to operate: with both the 2.6.28-12-netbook and 2.6.29-1-netbook kernels, there is an exception during boot.

Code:

[   11.510912] BUG: unable to handle kernel NULL pointer dereference at 0000000c
[   11.510926] IP: [<c03384ac>] i2c_smbus_xfer+0x1a/0x8b
[   11.510945] *pde = 00000000
[   11.510953] Oops: 0000 [#1] SMP
[   11.510961] last sysfs file: /sys/kernel/uevent_seqnum
[   11.510968] Modules linked in: asus_eee(+) i2c_i801 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi arc4 snd_seq_midi_event ecb snd_seq joydev snd_timer snd_seq_device ath9k serio_raw mac80211 cfg80211 snd psmouse pcspkr iTCO_wdt iTCO_vendor_support intel_agp led_class soundcore snd_page_alloc agpgart video output eeepc_laptop atl1e ehci_hcd uhci_hcd fuse
[   11.511049]
[   11.511057] Pid: 2463, comm: modprobe Not tainted (2.6.29-1-netbook #0array1) 1000HE
[   11.511065] EIP: 0060:[<c03384ac>] EFLAGS: 00010286 CPU: 0
[   11.511075] EIP is at i2c_smbus_xfer+0x1a/0x8b
[   11.511081] EAX: 00000000 EBX: f6b93f0a ECX: 00000000 EDX: 00000069
[   11.511088] ESI: 00000069 EDI: 00000000 EBP: f6b93ef0 ESP: f6b93ed4
[   11.511095]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   11.511103] Process modprobe (pid: 2463, ti=f6b92000 task=f6488000 task.ti=f6b92000)
[   11.511109] Stack:
[   11.511113]  c0157a86 f6b93fa0 c014b8f0 001ca018 f6b93f0a 00000069 f81d7130 f6b93f38
[   11.511131]  c0338656 00000001 00000000 00000005 f6b93f0a f81ca018 f81c9f74 f65ed0b0
[   11.511150]  f81ca630 0000000f f6b93f2c c0416300 f6b93f34 00000000 f81d6ff0 fffffffc
[   11.511171] Call Trace:
[   11.511176]  [<c0157a86>] ? stop_machine_destroy+0x3a/0x3c
[   11.511190]  [<c014b8f0>] ? load_module+0xc4e/0xdd1
[   11.511208]  [<c0338656>] ? i2c_smbus_read_block_data+0x28/0x52
[   11.511229]  [<c0416300>] ? mutex_lock+0xe/0x1e
[   11.511251]  [<f81d618a>] ? init_module+0x2f/0x4f [asus_eee]
[   11.511265]  [<c010113a>] ? _stext+0x4a/0x11d
[   11.511276]  [<f81d615b>] ? init_module+0x0/0x4f [asus_eee]
[   11.511294]  [<c013e40d>] ? __blocking_notifier_call_chain+0x40/0x4c
[   11.511315]  [<c014bbc4>] ? sys_init_module+0x87/0x186
[   11.511326]  [<c0102f6b>] ? sysenter_do_call+0x12/0x2f
[   11.511338]  [<c0410000>] ? cpuid4_cache_lookup+0x5c/0x2b7
[   11.511351] Code: ba 39 d0 7d ee 31 d2 8d 65 f4 89 d0 5b 5e 5f 5d c3 55 83 e1 14 89 e5 0f b7 c9 57 89 c7 56 0f b7 d2 53 83 ec 10 8a 45 0c 88 45 f3 <8b> 47 0c 83 78 04 00 0f be 45 08 89 4d ec 89 55 e8 89 45 e4 74
[   11.511453] EIP: [<c03384ac>] i2c_smbus_xfer+0x1a/0x8b SS:ESP 0068:f6b93ed4
[   11.511470] ---[ end trace 8204d4a7691066c3 ]---

The above output is from a fully-updated NBR 3.0.1 system, as of yesterday. The end result is that the driver is non-functional.

Code:

$ ls /proc/eee
ls: cannot access /proc/eee: No such file or directory

Can anyone help?

We've been chasing this for a while, unfortunately since I don't have access to a 1000HE I have been unable to really troubleshoot it. I think the issue is that the kernel isn't exposing the clock generator to i2c, what I'm wondering though is if 2.6.30 corrects it.

There is a PPA for 2.6.30 if you'd like to test, I've been running it for a week or so with great success: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/

siege · **Posted:** Wed Jun 24, 2009 2:08 pm

fewt,

I had already got the new kernel trying to get video to work better (UXA) via the 'optimal' setting. That was a miserable failure on my box, but I'm certainly willing to download that kernel again to test for you. What commands/output would you like to see? I assume you'd want them at support@fewt.com? I have a 1000HA, rather than a 1000HE like ChrisMX6.

siege

ChrisMX6 · **Posted:** Wed Jun 24, 2009 2:19 pm

Fewt,

Yes I'll certainly give the generic 2.6.30 kernel a go and see how it behaves.

Thanks
Chris

fewt · **Posted:** Wed Jun 24, 2009 2:23 pm

siege wrote:

fewt,

I had already got the new kernel trying to get video to work better (UXA) via the 'optimal' setting. That was a miserable failure on my box, but I'm certainly willing to download that kernel again to test for you. What commands/output would you like to see? I assume you'd want them at support@fewt.com? I have a 1000HA, rather than a 1000HE like ChrisMX6.

siege

I mainly want to see dmesg, and to know if /proc/netbook/bus_control or /proc/eee/fsb exists (and has accurate information in the file).

ChrisMX6 · **Posted:** Wed Jun 24, 2009 3:17 pm

Still no luck on 2.6.30.

Dmesg extract:

Code:

[    9.805197] BUG: unable to handle kernel NULL pointer dereference at 0000000c
[    9.805358] IP: [<c03efca8>] i2c_smbus_xfer+0x28/0xc0
[    9.805468] *pde = 00000000
[    9.805558] Oops: 0000 [#1] SMP
[    9.805680] last sysfs file: /sys/kernel/uevent_seqnum
[    9.805746] Modules linked in: asus_eee(+) i2c_i801 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi joydev snd_seq_midi_event snd_seq snd_timer snd_seq_device iTCO_wdt iTCO_vendor_support snd psmouse serio_raw intel_agp soundcore snd_page_alloc pcspkr agpgart video output eeepc_laptop atl1e
[    9.807018]
[    9.807082] Pid: 1658, comm: modprobe Not tainted (2.6.30-020630-generic #020630) 1000HE
[    9.807173] EIP: 0060:[<c03efca8>] EFLAGS: 00010246 CPU: 1
[    9.807247] EIP is at i2c_smbus_xfer+0x28/0xc0
[    9.807312] EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000069
[    9.807380] ESI: 00000069 EDI: 00000000 EBP: f6869ebc ESP: f6869e98
[    9.807450]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[    9.807519] Process modprobe (pid: 1658, ti=f6868000 task=f697e380 task.ti=f6868000)
[    9.808635] Stack:
[    9.808693]  00000000 c06eed20 c17baee0 c06eed2c 00690100 00000202 f6869ed6 00000069
[    9.808973]  f8460340 f6869f04 c03f092f 00000001 00000000 00000005 f6869ed6 00000002
[    9.809048]  f688f2c0 00000001 f6869f04 c01b3dae f6869ef8 00000000 f845f1c0 f8460340
[    9.809048] Call Trace:
[    9.809048]  [<c03f092f>] ? i2c_smbus_read_block_data+0x3f/0x70
[    9.809048]  [<c01b3dae>] ? __vunmap+0x6e/0xd0
[    9.809048]  [<f845f1c0>] ? init_module+0x0/0x60 [asus_eee]
[    9.809048]  [<f845f1c0>] ? init_module+0x0/0x60 [asus_eee]
[    9.809048]  [<f845f1f2>] ? init_module+0x32/0x60 [asus_eee]
[    9.809048]  [<c010112b>] ? do_one_initcall+0x2b/0x150
[    9.809048]  [<c0189428>] ? tracepoint_module_notify+0x28/0x30
[    9.809048]  [<c05129dd>] ? notifier_call_chain+0x2d/0x60
[    9.809048]  [<c0154a5d>] ? __blocking_notifier_call_chain+0x4d/0x60
[    9.809048]  [<c0165b23>] ? sys_init_module+0x83/0x1c0
[    9.809048]  [<c0102ebc>] ? sysenter_do_call+0x12/0x28
[    9.810943] Code: 00 00 00 55 89 e5 83 ec 24 89 7d fc 89 c7 0f b6 45 08 89 5d f4 89 cb 89 75 f8 83 e3 14 66 89 55 ee 88 45 ed 0f b6 45 0c 88 45 ec <8b> 47 0c 8b 40 04 85 c0 74 50 8d 47 20 89 45 f0 e8 e3 f4 11 00
[    9.810943] EIP: [<c03efca8>] i2c_smbus_xfer+0x28/0xc0 SS:ESP 0068:f6869e98
[    9.810943] CR2: 000000000000000c
[    9.813454] ---[ end trace 9808a5575e843145 ]---

There's no /proc/netbook or /proc/eee. I'm happy to run whatever test code you need to find the cause, or to upload the whole dmesg somewhere.

Thanks
Chris

siege · **Posted:** Wed Jun 24, 2009 3:48 pm

fewt and Chris,

The same error is mentioned here: http://aur.archlinux.org/packages.php?d ... 1&ID=14774

I have no idea if their solution is applicable to Eeebuntu. Here's a quote: "A workaround seems to be to add

Code:

modprobe eee

to /etc/rc.local Then the module loads and works fine.

I'm still at work and cannot test myself.

siege

siege · **Posted:** Wed Jun 24, 2009 4:08 pm

Similar solution here:

http://www.nerdlogger.com/2008/05/asus- ... u-804.html

This one also unblacklists the module like fewt temporarily suggested in a nearby thread.

siege

fewt · **Posted:** Wed Jun 24, 2009 4:10 pm

siege wrote:

Similar solution here:

http://www.nerdlogger.com/2008/05/asus- ... u-804.html

Those are the same module as asus-eee.ko, and the source that I forked for netbook.ko. They all use i2c.

siege · **Posted:** Wed Jun 24, 2009 4:45 pm

fewt,

When you had me safely mv asus-eee.ko so that it would not interfere with netbook.ko, I noticed that asus-eee.ko was the only thing in its parent directory. However, netbook.ko was in a different directory and was not alone in there. I cannot remember either parent directory's name.

Does the parent directory (path) matter for the .ko files? Can more than one .ko file be in a single directory? Is it okay that asus-eee.ko and netbook.ko were in different directories?

siege

ChrisMX6 · **Posted:** Wed Jun 24, 2009 6:07 pm

siege wrote:

The same error is mentioned here: http://aur.archlinux.org/packages.php?d ... 1&ID=14774

"modprobe asus_eee" just hangs for me and doesn't return.

It's possible the patch mentioned at that page, affecting &proc_root, may do the job but that will take longer for me to attempt.

siege · **Posted:** Wed Jun 24, 2009 6:19 pm

ChrisMX6,

I'm not sure if you're using fewt's developmental utilities or the mainline ones... I'm using the developmental ones. Not sure which is preferable for this particular thread; probably the main ones.

siege

ChrisMX6 · **Posted:** Thu Jun 25, 2009 12:53 pm

I'm using the standard Eeebuntu 3.0.1 supplied utilities and drivers, plus whatever arrives as an automatic update from the repositories.

ChrisMX6 · **Posted:** Tue Jun 30, 2009 6:42 am

Fewt,

I've done some digging. I see that you already have the correction listed on the ArchLinux site, so that isn't it. But the reason for the NULL pointer exception is the combination of two bugs in eee_pll_init().

Code:

static void eee_pll_init(void) {
    eee_pll_smbus_client.adapter = i2c_get_adapter(0);

    // Fill the eee_pll_data buffer.
    eee_pll_read();
}

1. The call to i2c_get_adapter(0) fails to find the i2c smbus adapter.
2. There is no error checking of the return value, so there is a subsequent exception during eee_pll_read.

Bug 2 is easy to fix, but bug 1 is the important one. I don't know the root cause, and I know very little about I2C buses, but one possible cause is that it needs rewriting in a different way. To quote the code: "Note that this isn't really the "proper" way to use the I2C API...".

However another possibility, one that seems more likely to me, is that the I2C interface has been hidden by the BIOS. The file /usr/src/linux/Documentation/i2c/busses/i2c-i801 says:

Code:

If your system has an Intel ICH south bridge, but you do NOT see the
SMBus device at 00:1f.3 in lspci, and you can't figure out any way in the
BIOS to enable it, it means it has been hidden by the BIOS code. Asus is
well known for first doing this on their P4B motherboard, and many other
boards after that. Some vendor machines are affected as well.

Well, this is an Asus, and there's nothing at 00:1f.3, so perhaps that's the reason for the i2c_get_adapter fail. I am now way out of my depth, and have no idea of the correct way to solve this, or if it's something else, so Fewt could you help please?

Thanks,
Chris

fewt · **Posted:** Tue Jun 30, 2009 12:26 pm

ChrisMX6 wrote:

Fewt,

I've done some digging. I see that you already have the correction listed on the ArchLinux site, so that isn't it. But the reason for the NULL pointer exception is the combination of two bugs in eee_pll_init().

Code:

static void eee_pll_init(void) {
    eee_pll_smbus_client.adapter = i2c_get_adapter(0);

    // Fill the eee_pll_data buffer.
    eee_pll_read();
}

1. The call to i2c_get_adapter(0) fails to find the i2c smbus adapter.
2. There is no error checking of the return value, so there is a subsequent exception during eee_pll_read.

Bug 2 is easy to fix, but bug 1 is the important one. I don't know the root cause, and I know very little about I2C buses, but one possible cause is that it needs rewriting in a different way. To quote the code: "Note that this isn't really the "proper" way to use the I2C API...".

However another possibility, one that seems more likely to me, is that the I2C interface has been hidden by the BIOS. The file /usr/src/linux/Documentation/i2c/busses/i2c-i801 says:

Code:

If your system has an Intel ICH south bridge, but you do NOT see the
SMBus device at 00:1f.3 in lspci, and you can't figure out any way in the
BIOS to enable it, it means it has been hidden by the BIOS code. Asus is
well known for first doing this on their P4B motherboard, and many other
boards after that. Some vendor machines are affected as well.

Well, this is an Asus, and there's nothing at 00:1f.3, so perhaps that's the reason for the i2c_get_adapter fail. I am now way out of my depth, and have no idea of the correct way to solve this, or if it's something else, so Fewt could you help please?

Thanks,
Chris

You are absolutely correct, it's not the proper way to talk to use the i2c api (I just borrowed someone elses module, I don't know how to write it better yet). The SMBios is being hidden, you are correct on that also.

I tried unhiding it, but it doesn't seem to work on the ICH7. The she interface works just as well though it seems, I'm getting 9.4 hours out of my new HE using it.

asus_eee/i2c driver fails w/NULL pointer exception on 1000HE

Who is online