+++ This bug was initially created as a clone of Bug #211920 +++ Description of problem: Kernel oops when loading ipmi_si module on Supermicro H8DMR-82 that doesn't have an IPMI card. Version-Release number of selected component (if applicable): 2.6.9-42.0.3.ELsmp (x86_64) How reproducible: Every time Steps to Reproduce: 1. modprobe ipmi_si 2. 3. Actual results: Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP: [<0000000000000000>] PML4 11ab7a067 PGD 11a663067 PMD 0 Oops: 0010 [1] SMP CPU 0 Modules linked in: ipmi_si ipmi_msghandler nfsd exportfs md5 ipv6 parport_pc lpd Pid: 4129, comm: modprobe Not tainted 2.6.9-42.0.3.ELsmp RIP: 0010:[<0000000000000000>] [<0000000000000000>] RSP: 0000:000001011a7b5e70 EFLAGS: 00010202 RAX: 00000100dfe6a800 RBX: 00000000ffffffed RCX: 0000010000012000 RDX: 0000000000000202 RSI: 000001011c093030 RDI: 00000100dfe6a800 RBP: 0000000000000000 R08: 000001011a7b4000 R09: 0000000000000008 R10: 0000000000000000 R11: 0000000000000002 R12: ffffffffa0226d20 R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffa0226ba0 FS: 0000002a958a0b00(0000) GS:ffffffff804e5180(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000000 CR3: 0000000000101000 CR4: 00000000000006e0 Process modprobe (pid: 4129, threadinfo 000001011a7b4000, task 000001011c093030) Stack: ffffffffa021f205 000001011a7b5f08 0000000000000002 000000000000000f 00000100dfe6a800 0000000000000000 0000000000000c58 00000000000fad30 000001011a7b5f08 ffffffffa0226d20 Call Trace:<ffffffffa021f205>{:ipmi_si:init_one_smi+3801} <ffffffffa0228363>{:i <ffffffff8014fd19>{sys_init_module+278} <ffffffff8011026a>{system_call+1 Code: Bad RIP value. RIP [<0000000000000000>] RSP <000001011a7b5e70> CR2: 0000000000000000 <0>Kernel panic - not syncing: Oops Expected results: modprobe to fail cleanly as there is no IPMI card in the system Additional info: -- Additional comment from james-p on 2006-10-24 12:08 EST -- Created an attachment (id=139237) Patch to fix oops in ipmi_si module Just before the oops, it prints: ipmi_si: Found SMBIOS-specified state machine at memory address 0x0, slave address 0x0 Could not set up I/O space Having a look at the code, it fails in init_one_smi() at: new_smi->io_cleanup(new_smi); This is because new_smi->io_cleanup is not set because port_setup() and mem_setup() can return with an error before info->io_cleanup is set ... The attached patch, I believe, fixes this - well it works for me in this case -- Additional comment from peterm on 2006-10-24 15:14 EST -- Fixed in 2.6.18.1, already fixed in R5, will look into getting this fixed in R4.5. -- Additional comment from peterm on 2006-11-10 16:37 EST -- Created an attachment (id=140938) Patch which follows upstream direction. Patch against latest R4.5 devel tree. -- Additional comment from pm-rhel on 2006-11-10 18:05 EST -- This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. -- Additional comment from jturner on 2006-11-21 07:45 EST -- QE ack for 4.5. -- Additional comment from jbaron on 2006-12-11 17:08 EST -- committed in stream U5 build 42.30. A test kernel with this patch is available from http://people.redhat.com/~jbaron/rhel4/
Following up with a R3.9 version of the patch, devel ACK for R3.9.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
A fix for this problem has just been committed to the RHEL3 U9 patch pool this evening (in kernel version 2.4.21-47.5.EL).
QE ack for RHEL3.9.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2007-0436.html