freeipmi-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freeipmi-users] problem with freeipmi 0.5.3 and intel SE7221B


From: Bala.A
Subject: Re: [Freeipmi-users] problem with freeipmi 0.5.3 and intel SE7221BK1-E
Date: Mon, 21 Jan 2008 04:10:10 -0800 (PST)
User-agent: SquirrelMail/1.4.9a

dmidecode code is used inside device probing.  If there is a difference in
ipmi-locate and latest dmidecode output, then we need to update our
dmidecode device probing code.

Regards,
Bala
---
Free as in freedom
http://www.gnu.org/


> I don't think this would be a kernel related issue.  Bala, you have any
> ideas?
>
> Al
>
>> Any more ideas? Have there been any important kernel changes that
>> should cause me to try to upgrade to 2.6.24?
>>
>> Chris
>>
>>
>>
>> On Jan 17, 2008 11:44 AM, Chris Morgan <address@hidden> wrote:
>>>
>>> On Jan 17, 2008 11:36 AM, Albert Chu <address@hidden> wrote:
>>> >
>>> >
>>> > > Hi Bala. Thank you for replying.
>>> > >
>>> > > On Jan 16, 2008 11:10 PM, Bala.A <address@hidden> wrote:
>>> > >>
>>> > >> Hi,
>>> > >>
>>> > >> Please find inline replies
>>> > >>
>>> > >> >
>>> > >> > # ipmi-locate
>>> > >> > Probing KCS device using DMIDECODE... FAILED
>>> > >> >
>>> > >> > Probing SMIC device using DMIDECODE... FAILED
>>> > >> >
>>> > >> > Probing BT device using DMIDECODE... FAILED
>>> > >> >
>>> > >> > Probing SSIF device using DMIDECODE... done
>>> > >> > IPMI Version: 1.5
>>> > >> > IPMI locate driver: DMIDECODE
>>> > >> > IPMI interface: SSIF
>>> > >> > BMC driver device: /dev/i2c-0
>>> > >> > BMC SMBUS slave address: 42
>>> > >> > Register spacing: 1
>>> > >> >
>>> > >> > Probing KCS device using SMBIOS... FAILED
>>> > >> > Probing SMIC device using SMBIOS... FAILED
>>> > >> > Probing BT device using SMBIOS... FAILED
>>> > >> >
>>> > >> > Probing SSIF device using SMBIOS... done
>>> > >> > IPMI Version: 1.5
>>> > >> > IPMI locate driver: SMBIOS
>>> > >> > IPMI interface: SSIF
>>> > >> > BMC driver device: /dev/i2c-0
>>> > >> > BMC SMBUS slave address: 84
>>> > >> > Register spacing: 1
>>> > >> >
>>> > >>
>>> > >> Please try the following commands and let me know they work or not
>>> > >>
>>> > >> bmc-info --no-probing -D SSIF --driver-address=42
>>> > >> --driver-device=/dev/i2c-0  --register-spacing=1
>>> > >>
>>> > >> bmc-info --no-probing -D SSIF --driver-address=84
>>> > >> --driver-device=/dev/i2c-0  --register-spacing=1
>>> > >>
>>> > >
>>> > >
>>> > > address@hidden:~# ls /dev/i2c*
>>> > > /dev/i2c-0
>>> > >
>>> > > address@hidden:~# lsmod | grep i2c
>>> > > i2c_i801               10128  0
>>> > > i2c_dev                 8708  0
>>> > > i2c_core               26112  2 i2c_i801,i2c_dev
>>> > >
>>> > > address@hidden:~# lspci
>>> > > 00:00.0 Host bridge: Intel Corporation E7220/E7221 Memory
>>> Controller
>>> > > Hub (rev 05)
>>> > > 00:02.0 VGA compatible controller: Intel Corporation E7221
>>> Integrated
>>> > > Graphics Controller (rev 05)
>>> > > 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
>>> > > Family) PCI Express Port 1 (rev 03)
>>> > > 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW
>>> (ICH6
>>> > > Family) USB UHCI #1 (rev 03)
>>> > > 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW
>>> (ICH6
>>> > > Family) USB UHCI #2 (rev 03)
>>> > > 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW
>>> (ICH6
>>> > > Family) USB UHCI #3 (rev 03)
>>> > > 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW
>>> (ICH6
>>> > > Family) USB2 EHCI Controller (rev 03)
>>> > > 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3)
>>> > > 00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC
>>> > > Interface Bridge (rev 03)
>>> > > 00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW
>>> (ICH6
>>> > > Family) IDE Controller (rev 03)
>>> > > 00:1f.2 IDE interface: Intel Corporation 82801FR/FRW (ICH6R/ICH6RW)
>>> > > SATA Controller (rev 03)
>>> > > 00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6
>>> Family)
>>> > > SMBus Controller (rev 03)
>>> > > 01:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit
>>> > > Ethernet Controller (rev 05)
>>> > > 02:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI
>>> > > Bridge A (rev 09)
>>> > > 02:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI
>>> > > Bridge B (rev 09)
>>> > > 04:03.0 Ethernet controller: Intel Corporation 82541GI Gigabit
>>> > > Ethernet Controller (rev 05)
>>> > >
>>> > > address@hidden:~# bmc-info --no-probing -D SSIF --driver-address=42
>>> > > --driver-device=/dev/i2c-0 --register-spacing=1
>>> > > ipmi-ssif-api-udm.c: 81: ipmi_ssif_cmd_udm: errnum (4): expression
>>> failed
>>> > > ipmi_cmd_get_device_id: permission denied
>>> > >
>>> > > address@hidden:~# bmc-info --no-probing -D SSIF --driver-address=84
>>> > > --driver-device=/dev/i2c-0 --register-spacing=1
>>> > > ipmi-ssif-api-udm.c: 81: ipmi_ssif_cmd_udm: errnum (4): expression
>>> failed
>>> > > ipmi_cmd_get_device_id: permission denied
>>> >
>>> > Bala, FYI line 81 is a call to 'ipmi_ssif_write'.
>>> >
>>> > errnum 4 in the ssif lib is IPMI_SSIF_CTX_ERR_PERMISSION.
>>> >
>>> > the errnum seems to be  set via this code chunk:
>>> >
>>> >   if (buf_len <= IPMI_I2C_SMBUS_BLOCK_MAX)
>>> >     {
>>> >       count = ipmi_ssif_single_part_write (ctx->device_fd,
>>> >                                            buf,
>>> >                                            buf_len);
>>> >     }
>>> >   else
>>> >     {
>>> >       count = ipmi_ssif_multi_part_write (ctx->device_fd,
>>> >                                           buf,
>>> >                                           buf_len);
>>> >     }
>>> >
>>> >   if (count < 0)
>>> >     {
>>> >       if (errno == EACCES || errno == EPERM)
>>> >         ctx->errnum = IPMI_SSIF_CTX_ERR_PERMISSION;
>>> >       else
>>> >         ERR_LOG(ctx->errnum = IPMI_SSIF_CTX_ERR_SYSTEM_ERROR);
>>> >       goto cleanup;
>>> >     }
>>> >
>>> > tracing this into the deeper write calls, the errno is coming from
>>> the
>>> > core ioctl() call for ssif.
>>> >
>>> > It looks like Chris is root above, so EACCES is not the likely
>>> returned
>>> > errno, EPERM = "Operation Not Permitted" is.  So the question is why
>>> is
>>> > the ioctl not allowed.
>>> >
>>> > Chris, does anything interesting show up in the 'dmesg' logs?
>>> >
>>>
>>> You know I checked to see if there might have been something going on
>>> but this is the end of dmesg:
>>>
>>> ...
>>> [   67.895740] input: Power Button (CM) as /class/input/input3
>>> [   67.895768] ACPI: Power Button (CM) [PWRB]
>>> [   68.882998] NET: Registered protocol family 10
>>> [   68.883919] lo: Disabled Privacy Extensions
>>> [   79.554513] eth0: no IPv6 routers present
>>> [  381.528584] i2c /dev entries driver
>>> [  386.804841] ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 19 (level,
>>> low) -> IRQ 20
>>>
>>> Chris
>>>
>>
>
>
> --
> Albert Chu
> address@hidden
> 925-422-5311
> Computer Scientist
> High Performance Systems Division
> Lawrence Livermore National Laboratory
>






reply via email to

[Prev in Thread] Current Thread [Next in Thread]