Setting this to fix released but I do not know for sure. Sounds like it
was and this was back in Trusty, so I assume there would have been
updates if this did not get out.
** Changed in: linux (Ubuntu)
Status: Fix Committed => Fix Released
** Changed in: linux (Ubuntu)
Assignee: Stefa
** Changed in: opencompute
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1179774
Title:
ipmi kernel modules not detecting OCPv3 AMD Roadrunner BMC
To manage notif
So after some testing what I found was that after installing ipmitool a
reboot was required, after the reboot the ipmi_devintf module was
loaded.
When doing a first boot, only ipmi_si and ipmi_msghandler is loaded...
installing ipmitool complains that /dev/ipmi* doesn't exist. After
rebooting the
** Changed in: opencompute
Assignee: (unassigned) => David Duffey (david-duffey)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1179774
Title:
ipmi kernel modules not detecting OCPv3 AMD Roadrun
I tried the precise daily build (08-Aug-2013) which had the kernel
3.8.0-27-generic #40 for the installer... then after I rebooted
3.8.0-28-generic #41 was installed.
uname -a suggests the installer kernel was built/compiled on Fri Jul
19th?
Anyway, the BMC did not work (ipmitool lan print). I
If you could make sure which part of dmesg info related to the ipmi modules is
there before manual probing (well essentially right after boot as this should be
automatic). And maybe you could check which ipmi modules are loaded then.
And maybe compare whether there is any difference after manual pr
I would tend to agree as well, but the ipmi devices are not created if
I simply boot or reload the module and things like "ipmitool lan
print" do not work (until I run the script to initialize).
I can do some more poking around if you give ideas.
David
--
You received this bug notification beca
Comment #15 would mean to me that it _was_ discovered. The regspacing
and address of the pci discovery looks identical to the working case and
the last line says the module was initialized.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubunt
I've tested stock raring (3.8.0-19) and proposed (3.8.0-27-40) and the
ipmi interface doesn't work as I expected it to. I would like to see
this support included in 12.04.3 LTS.
Here is the relevant information from inserting the ipmi_si module:
Jul 12 17:04:45 ubuntu kernel: [ 16.947988] ipmi
If I use the script to manually load the ipmi driver (from comment #1)
the ipmi device works.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1179774
Title:
ipmi kernel modules not detecting OCPv3 AMD
1. Not necessarily for the sake of the ipmi support only. If it works
with the raring kernel it will work when the raring kernel becomes the
12.04.3 kernel. But I guess it make sense to get back to that as part of
an overall integration test. So when we have a fix for 2. and think that
kernel has
As long as it lands in the 12.04.3 LTS point release (August?), that is
okay, no need to backport.
I have two questions though.
1. I don't think I've tested this on stock raring. Should I test on
stock raring or on a daily 12.04.3 build to make sure this will land in
12.04.3?
2. Could you also
Probably should have stated that more explicit in previous comment. Is
there need for a backport into pre-3.7 kernels? Raring/13.04 should be
ok as it is 3.8.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/b
Ah ok, so it seems the basic support was already in for quite some time.
I am not remembering which kernel version was used in the failing case
but there seems to have been a change upstream about v3.7-rc2 which
allows detecting a different regspacing and the working output seems to
have detected a
Also here is the output of the ipmi_si module being loaded with the
stock kernel (failed) and the leann kernel (works)
failed:
Jun 25 09:38:42 precise2 kernel: [ 186.940809] IPMI System Interface driver.
Jun 25 09:38:42 precise2 kernel: [ 186.940857] ipmi_si :02:00.6: probing
via PCI
Jun 2
@ Stefan, brainfart on my side and missed the correct commands... here
is the correct output of lspci -vvvnn. Also note this is running on the
working kernel from comment #8, if that matters.
02:00.6 IPMI SMIC interface [0c07]: Broadcom Corporation Device [14e4:16b9]
(prog-if 01)
Subsyst
When testing a related bug for the tg3 driver
(https://bugs.launchpad.net/opencompute/+bug/1178899) using this kernel
(http://people.canonical.com/~ogasawara/lp1178899/) the ipmi_si module
successfully worked.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
On 25.06.2013 18:32, David Duffey wrote:
> Here is the output of lspci - on that device. Notice the address
> change... I'm guessing this may be because I removed an add-on PCI card
> in the process.
>
>
> 01:00.6 IPMI SMIC interface: Broadcom Corporation Device 16b9 (prog-if 01)
> Sub
Here is the output of lspci - on that device. Notice the address
change... I'm guessing this may be because I removed an add-on PCI card
in the process.
01:00.6 IPMI SMIC interface: Broadcom Corporation Device 16b9 (prog-if 01)
Subsystem: Broadcom Corporation Device 96b9
Cont
David, could you add (or replace above output) the output of "lspci
-vvvnn -s 02:00.6" so we can see all the id numbers. It seems the ipmi
part can be done by adding a pci id to the ipmi_si driver. Are we aware
of anybody else being on this already?
** Also affects: linux (Ubuntu)
Importance: U
20 matches
Mail list logo
