Re: ipmi driver broken
> From: Ted Unangst > Sent: Wednesday, June 28, 2017 8:50 PM > > i'm afraid i won't make a very good ipmi maintainer, but i think i applied the > patch in the right spot. Cool, thanks; much appreciated.
Re: ipmi driver broken
> From: Theo de Raadt > Sent: Wednesday, June 28, 2017 8:41 PM > > If you want it working, you will need to get it fixed. On all > machines, so that we can renable it. I definitely don't want to be one of those entitled people demanding work from developers without providing anything that you trounce upon ;). But that's a bit of a big ask, make it work on all machines? I've got four different models of supermicro servers that I certainly can do testing on, although as I said, on these particular servers as far as I can tell (other than the watchdog) the driver seems to work fine. > Let me explain how we work. I understand; really, I'm not asking you guys to invest a significant amount of effort in improving the driver, or even technically "fixing" any new issues or problems with it. I was only kindly requesting that you put back a line that appears to have accidentally been deleted a few revisions ago that broke it. So unless you're intentionally sabotaging it in preparation for the ritual sacrifice :)? It's too bad nobody else finds value in it; it provides sensors that aren't otherwise available, provides access to the system event log for event data, allows access to the management interface without needing to go through the network, and ideally would allow access to the hardware watchdog. Unfortunately I don't have expertise in low level hardware device driver development so while I could be a tester I can't be a primary maintainer. So if you guys end up scrapping it, I will be sad but that's the way it is. But until then, given it works for me, it doesn't hurt to use it :). Or to ask for one line to be put back so it would work in the shipped kernel; unless I suppose said request results in it getting scrapped ;). Thanks.
Re: ipmi driver broken
Paul B. Henson wrote: > After applying this and installing the resulting kernel, ipmi worked > fine. I skipped 6.0, but just updated my boxes to 6.1, and see the same > ipmi failures. It looks like this fix hasn't been applied, the code in > head is still missing this line. I applied it again to my 6.1 kernel and > it still seems to make ipmi work fine as far as I can tell. > > Is there anyone maintaining ipmi or someone with commit privs that might > be kind enough to apply this so the next release version would have > working ipmi? i'm afraid i won't make a very good ipmi maintainer, but i think i applied the patch in the right spot.
Re: ipmi driver broken
> Anyway, thanks for the thoughts; but I do still want a working ipmi :). > No biggie to add one line and recompile the kernel, but it would be nice > to get fixed. It's still disabled by default out of the box, you have to > explicitly reconfigure your kernel to enable it. If you want it working, you will need to get it fixed. On all machines, so that we can renable it. Or the process you just described will go terribly wrong soon. Let me explain how we work. When we disable something -- as ipmi was handled -- it means we have give up on trying to fix it. This code was locking up some machines and noone cared enough to find the problem and fix it permanently. However, if code is disabled it also means people suddenly aren't using it, being exposed to the bug, and caring about it. Obviously a majority of users don't use this code. Also that means a majority of developers aren't using it. I'd say that number is ZERO. So in more than 5 years, noone has arrived to take care for it. But someone needs to care for every piece of code in our tree. Indications are noone will take care of ipmi.c So before long, the tedu will arrive with his scythe and take the code to the other world. I predict it won't be long before the code we don't use, don't maintain, and which noone else maintains is gone. Actually, this may summon the tedu...
Re: ipmi driver broken
On Wed, Jun 28, 2017 at 06:31:34PM -0400, Predrag Punosevac wrote: > My understanding is that ipmi driver used by ipmitool is disabled > intensionally due to the security problems. IPMI pose a grave security > risk. IPMI on the SP is available whether or not the openbsd driver is enabled or in use; my understanding as to why it's disabled by default it that it's not necessarily considered stable. I've never had an issue with it, at least not for the limited use I make of it. > As you probably know OpenBSD comes with its own sensoring > framework. You probably want to check out Yes; I actually want the ipmi driver loaded so it can supply data to said framework: hw.sensors.ipmi0.temp0=34.00 degC (System Temp), OK hw.sensors.ipmi0.temp1=40.00 degC (Peripheral Temp), OK hw.sensors.ipmi0.fan0=4875 RPM (FAN 1), OK hw.sensors.ipmi0.fan1=3000 RPM (FAN 2), OK hw.sensors.ipmi0.fan2=3150 RPM (FAN 3), OK hw.sensors.ipmi0.fan3=5100 RPM (FAN 4), OK hw.sensors.ipmi0.fan4=3300 RPM (FAN A), OK hw.sensors.ipmi0.volt0=0.71 VDC (Vcore), OK hw.sensors.ipmi0.volt1=3.23 VDC (3.3VCC), OK hw.sensors.ipmi0.volt2=12.14 VDC (12V), OK hw.sensors.ipmi0.volt3=1.53 VDC (VDIMM), OK hw.sensors.ipmi0.volt4=4.99 VDC (5VCC), OK hw.sensors.ipmi0.volt5=-12.49 VDC (-12V), OK hw.sensors.ipmi0.volt6=3.17 VDC (VBAT), OK hw.sensors.ipmi0.volt7=3.36 VDC (VSB), OK hw.sensors.ipmi0.volt8=3.23 VDC (AVCC), OK hw.sensors.ipmi0.indicator0=Off (Chassis Intru), OK There's more sensor data available via the IPMI interface than the kernel supplies without it. It's also useful to be able to view the SEL without having to loop over the network to the SP management IP. On my linux boxes I also use the ipmi hardware watchdog, but last time I tried that on openbsd it just kept rebooting continuously 8-/. Guess that's one of the parts that's not stable :), but I can't remember the last time one of my openbsd boxes wedged up anyway. Anyway, thanks for the thoughts; but I do still want a working ipmi :). No biggie to add one line and recompile the kernel, but it would be nice to get fixed. It's still disabled by default out of the box, you have to explicitly reconfigure your kernel to enable it.
Re: ipmi driver broken
Paul B. Henson wrote: > I noticed back when I upgraded to 5.9 the ipmi driver stopped working, > it just said: > > ipmi0: get header fails > ipmi0: no SDRs IPMI disabled > > I found the following post at the time which appeared to point out the > issue and suggest a fix: > > http://openbsd-archive.7691.n7.nabble.com/fix-for-quot-ipmi0-get-header-fails-quot-td299427.html > > After applying this and installing the resulting kernel, ipmi worked > fine. I skipped 6.0, but just updated my boxes to 6.1, and see the same > ipmi failures. It looks like this fix hasn't been applied, the code in > head is still missing this line. I applied it again to my 6.1 kernel > and it still seems to make ipmi work fine as far as I can tell. > Is there anyone maintaining ipmi or someone with commit privs that > might be kind enough to apply this so the next release version would > have working ipmi? > > Thanks much... My understanding is that ipmi driver used by ipmitool is disabled intensionally due to the security problems. IPMI pose a grave security risk. As you probably know OpenBSD comes with its own sensoring framework. You probably want to check out http://man.openbsd.org/OpenBSD-6.1/sensorsd http://man.openbsd.org/OpenBSD-6.1/sensorsd.conf.5 Sensorsd comes with appropriate MIBs files the native SNMP daemon and it really easy to poll with SNMP walk. I have really nice charts coming out of LibreNMS. For instant report check out this # sysctl hw.sensors hw.sensors.cpu0.temp0=27.00 degC hw.sensors.lm2.temp0=47.00 degC hw.sensors.lm2.temp1=47.00 degC hw.sensors.lm2.temp2=31.00 degC hw.sensors.lm2.volt0=1.16 VDC (VCore) hw.sensors.lm2.volt1=6.86 VDC (+12V) hw.sensors.lm2.volt2=3.31 VDC (+3.3V) hw.sensors.lm2.volt3=3.30 VDC (+3.3V) hw.sensors.lm2.volt4=-10.54 VDC (-12V) hw.sensors.lm2.volt5=1.26 VDC hw.sensors.lm2.volt6=1.86 VDC hw.sensors.lm2.volt7=3.30 VDC (3.3VSB) hw.sensors.lm2.volt8=1.59 VDC (VBAT) and compare to Linux root@ari$ ipmitool sdr CPU1 Temp| 50 degrees C | ok CPU2 Temp| 51 degrees C | ok CPU3 Temp| 69 degrees C | ok CPU4 Temp| 62 degrees C | ok System Temp | 29 degrees C | ok Peripheral Temp | 44 degrees C | ok PCH Temp | 49 degrees C | ok FAN1 | no reading| ns FAN2 | no reading| ns FAN3 | 4800 RPM | ok FAN4 | 4800 RPM | ok FAN5 | 4650 RPM | ok FAN6 | no reading| ns FAN7 | no reading| ns FAN8 | no reading| ns FAN9 | no reading| ns FAN10| no reading| ns VTT | 0.99 Volts| ok CPU1 Vcore | 1.06 Volts| ok CPU2 Vcore | 1.06 Volts| ok CPU3 Vcore | 1.06 Volts| ok CPU4 Vcore | 1.06 Volts| ok VDIMM ABCD | 1.38 Volts| ok VDIMM EFGH | 1.38 Volts| ok VDIMM JKLM | 1.38 Volts| ok VDIMM NPRT | 1.38 Volts| ok 3.3V | 3.36 Volts| ok +3.3VSB | 3.26 Volts| ok 12V | 11.87 Volts | ok VBAT | 3.22 Volts| ok Chassis Intru| 0x01 | ok PS1 Status | 0x01 | ok PS2 Status | 0x01 | ok My favorite remote telemetry daemon Collectd has an IPMI plug-in but it is not functional on OpenBSD as you can see by reading configuration file (has double ## in front of the plug-in which means not available). Hopefully this will give you something to look at if the reporting is what you are looking for. If you actually want to control machines remotely via IPMI that is probably different story. Cheers, Predrag
ipmi driver broken
I noticed back when I upgraded to 5.9 the ipmi driver stopped working, it just said: ipmi0: get header fails ipmi0: no SDRs IPMI disabled I found the following post at the time which appeared to point out the issue and suggest a fix: http://openbsd-archive.7691.n7.nabble.com/fix-for-quot-ipmi0-get-header-fails-quot-td299427.html After applying this and installing the resulting kernel, ipmi worked fine. I skipped 6.0, but just updated my boxes to 6.1, and see the same ipmi failures. It looks like this fix hasn't been applied, the code in head is still missing this line. I applied it again to my 6.1 kernel and it still seems to make ipmi work fine as far as I can tell. Is there anyone maintaining ipmi or someone with commit privs that might be kind enough to apply this so the next release version would have working ipmi? Thanks much...
