Re: I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI

[Chris Bennett]

On Sat, Jul 29, 2023 at 07:41:18PM +, Philipp Buehler wrote:
> Am 29.07.2023 21:29 schrieb Chris Bennett:
> > The other IP's are randomly missing or give this:
> > 
> > link#2 UHLc   0  450 - 3 em1
> > 

Hi,
I'm happy. I practiced on the other server until I was sure, then I
changed the first server over to the new way. I got one link#2 on the
last IP, so I aliased that one in too and rebooted. Everything is great.

What does link#2 mean in a more literal sense?

Tomorrow all I have to do is new DNS records and swap the IP addresses
for the other server.
Tell them to switch me over to the new IP's and I'm done.

I have no idea what the network problem was, but I leave my desktop on
24/7.
It crashed for the first time ever. Most likely it was the problem.

Thank you for the education. I fully approve of getting little pieces at
a time. Change this. Doesn't work. Study it carefully. Post again. More
problems. Then more help.
I have always liked OpenBSD's policy of not giving information to just
copy/paste.

Now I need to go make a donation.
Have a great day.

-- 
Chris

Re: I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI

[Chris Bennett]

On Sat, Jul 29, 2023 at 07:41:18PM +, Philipp Buehler wrote:
> Oh, you need an alias for each IP that should be bound on em1
> so, like:
> # cat /etc/hostname.em1
> inet 103.103.103.170/29
> inet alias 103.103.103.171/32
> inet alias 103.103.103.172/32
> inet alias 103.103.103.173/32
> inet alias 103.103.103.174/32
> 

This seemed to work.
The network is very strange for me.
Not sure if my hotspot is bad or if they are having network problems at
the company. New network, new problems?

I will get back later if this is a real problem or not.

I was reading route manpage. Next is netstart script and manpage.

Thanks. I really appreciate it.

Chris Bennett

> 
> mygate and netstart has a manpage, as there is 'hostname.if' to read :)
> 
> PS: pointless to use '-x'; just a lot of debug noise
> 
> -- 
> pb
> 

-- 

Re: I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI

[Philipp Buehler]

Am 29.07.2023 21:29 schrieb Chris Bennett:

The other IP's are randomly missing or give this:

link#2 UHLc   0  450 - 3 em1

Each route flush;sh -x /etc/nestart   or a reboot changes the result.


Oh, you need an alias for each IP that should be bound on em1
so, like:
# cat /etc/hostname.em1
inet 103.103.103.170/29
inet alias 103.103.103.171/32
inet alias 103.103.103.172/32
inet alias 103.103.103.173/32
inet alias 103.103.103.174/32

# cat /etc/mygate
103.103.103.169

mygate and netstart has a manpage, as there is 'hostname.if' to read :)

PS: pointless to use '-x'; just a lot of debug noise

--
pb

Re: I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI

[Chris Bennett]

On Sat, Jul 29, 2023 at 06:18:40PM +, Philipp Buehler wrote:
> Am 29.07.2023 20:04 schrieb Chris Bennett:
> > inet 103.103.103.168/29
> 
> That's wrong, you put the "first" IP-address you want to
> use/have on em1. So that would be 170/29
> 

Well, that half-worked. 
Always get ...170, works.
ssh works. autossh with -M no longer works except with autossh -M 0
...169 is the gateway. ...175 is broadcast.

The other IP's are randomly missing or give this:

link#2 UHLc   0  450 - 3 em1

Each route flush;sh -x /etc/nestart   or a reboot changes the result.

I just tried mygate at ...174. No good.

> (168 is this network's BSD-broadcast or "net address")
> 
> 
> > /etc/mygate is
> > 103.103.103.169
> Cannot forsee what your ISP provides as the gateway, but
> likely that's correct.
> 

Feel free to offer me a good man page to start with. Coffee is working.

-- 
Chris Bennett

Re: I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI

[Philipp Buehler]

Am 29.07.2023 20:04 schrieb Chris Bennett:

inet 103.103.103.168/29


That's wrong, you put the "first" IP-address you want to
use/have on em1. So that would be 170/29

(168 is this network's BSD-broadcast or "net address")



/etc/mygate is
103.103.103.169

Cannot forsee what your ISP provides as the gateway, but
likely that's correct.

All names (hosts,myname) is not directly relevant to IP networking.
Do not put names in mygate (just a sidenote).



ifconfig gave 103.103.103.168 as the IP address
route -n show gave 103.103.103.168 as the gateway.

Likely a config from the errornous hostname.if entry, see above.



I did not change or remove what's in /etc/hostname which is at
103.103.103.170. Does that matter?

hosts I assume? That might be relevant to apache, but not the
networking (reachability) itself.

--
pb

Re: I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI

[Chris Bennett]

On Sat, Jul 29, 2023 at 04:34:17AM +, Philipp Buehler wrote:
> 
> To save mindboggling counting of 'f' or similar, just write this to
> /etc/hostname.em1
> inet 108.181.26.178/28
> The ifconfig called from netstart will figure it out ;-) That's a headups
> for everybody, so cc misc@.
> 

Hmm, I also have a newer server with the same company that does have a
usable IPMI. I also have to change IP's with it too.
It is running -current from a few weeks ago, so this is a fictional
address except for the last three digits (168)

103.103.103.168/29

Right now, I have my first IP I'm using at 103.103.103.170

I put into /etc/hostname.em1:

inet 103.103.103.168/29

/etc/mygate is
103.103.103.169

/etc/myname is
network-moron.com

I did not change /etc/hosts which just has the addresses from
103.103.103.170 to 103.103.103.175 added.

I rebooted, but couldn't ping the server at any address.

In IPMI, there were no network problems on the boot screen, but apache2
failed to start.

ifconfig gave 103.103.103.168 as the IP address
route -n show gave 103.103.103.168 as the gateway.

For the heck of it, I changed /etc/mygate to 103.103.103.168,
just to see if that provided any useful information.
Same failed outcome, as I expected.

.later

I tried every obvious variation I could think of.
Nothing works except what I used on the other server.

A couple of years ago I tried to do what you suggested with a script to
swap back in the old hostname and reboot. I couldn't ever get it to work
Since what I had worked (not what I really wanted to use with the
aliases), I just blew it off.

I took a good while with my brain in sludge mode last night to change
some essential passwords and shut off imap, etc.
I still lacking enough sleep. Having coffee, going to eat and probably
go back to bed. I just wanted to try this out while I could.
I wanted to post about this and then RTFM's later with a clear head.

I did not change or remove what's in /etc/hostname which is at
103.103.103.170. Does that matter?


-- 
Chris Bennett

Re: I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI 11 Perhaps they just don't have a proper setup or are not using it.

[Chris Bennett]

On Sat, Jul 29, 2023 at 04:34:17AM +, Philipp Buehler wrote:
> Moin Chris,
> 
> Am 29.07.2023 04:17 schrieb Chris Bennett:
> > The network is 108.181.26.176/28.
> > 
> > Right now,the first IP is 108.181.26.178 and the last regular address is
> > 108.181.26.190, which might be wrong. I'm too tired to read any more
> > man pages or web pages. I needed more than 2hrs of sleep.
> > I'm super worn out, so forgive my mistakes.
> > 
> > Any help appreciated. I don't want the next syspatch reboot to fail.
> 
> To save mindboggling counting of 'f' or similar, just write this to
> /etc/hostname.em1
> inet 108.181.26.178/28
> The ifconfig called from netstart will figure it out ;-) That's a headups
> for everybody, so cc misc@.
> 

Yes, there was a big delay when he put in one f too few.

Besides changing IP ranges, they also just started pushing a single IP
address that serves as everything, but also a different checkbox for the
same thing for Linux only.
I know essentially nothing about Linux besides the fact that I quickly
tried several, but I didn't like them. I then ran into something
mentioning OpenBSD. After reading the website, I saw that OpenBSD was
and has been an excellent choice. No regrets.
I already know from experience that if I asked them for any details
about that networking change, I would NOT get a useful answer.

After I got to multiple days, my goal had to be getting able to ssh in
and start fixing things.
Security through obscurity does not work. So I think it is well worth it
to show and get help. I am so tired right now, that my Dad had a problem
with sound using YouTube on a Firestick. I couldn't tell him even the
simplest step, so I just had him reboot it.

I'm going to kill everything that has outside access, get a good night's
sleep and then change every password for inside stuff and all emails.
Then I'm going to carefully read every man page, etc. until I understand
everything fully. Now is the right time for this. Until recently, I only
had a laptop stuck at 6.6 and a lousy phone hotspot or an even crappier
access to almost useless wifi in places like libraries. Two used
computers and a really great phone hotspot make everything good now.

Thank you very much.

> The current ifconfig em1 shows a bit wild setup for 108.181.26.179; but that
> 
> is likely unintended and the wrong mask/bc will be gone with the above
> setting.
> 
> The route output shows several hosts in 108.136/108.137 ranges where there
> is no corresponding setup given.
> 
> But to reach the system via 108.181.26.178 again, this looks sound.
> 
> HTH,
> -- 
> pb
> 
> PS:
> tyo# cat /etc/hostname.vlan1
> vlandev vio0
> inet 108.181.26.178/28
> tyo# sh /etc/netstart vlan1
> tyo# ifconfig vlan1
> vlan1: flags=8843 mtu 1500
>   lladdr fe:e1:bb:6e:63:36
>   index 7 priority 0 llprio 3
>   encap: vnetid none parent vio0 txprio packet rxprio outer
>   groups: vlan
>   media: Ethernet autoselect
>   status: active
>   inet 108.181.26.178 netmask 0xfff0 broadcast 108.181.26.191
> PPS: to check quickly on reachability of a gateway directly:
> ping -I 108.181.26.178 -t 1 108.181.26.177
> and check arp table accordingly

I will try this right now and save this email in the mailbox for
important things to keep long term.

-- 
Chris Bennett

Re: I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI

[Chris Bennett]

On Sat, Jul 29, 2023 at 03:45:36AM +, All wrote:
> Your network has first usable IP address 108.181.26.177, not
> 108.181.26.178. Also, your broadcast address is 108.181.26.191 and not
> 108.181.26.190
> 

Yes, I had things setup with 108.181.26.177 as the first IP, but they
changed it. It was extremely frustrating to watch someone making changes
that I did not request. They also don't seem to have the capability to
read the support messages I sent them while actually making incorrect
changes.
Perhaps they just don't have a proper setup or are not using it.
I could see what they were doing by refreshing the IPMI preview screen.
But that really is just a poor set of images. It did let me see the
contents of files if I refreshed the image at just the right moment.
Getting them to type sh -x /etc/netstart or reboot despite giving them
detailed instructions beforehand. It took about 1 1/2hrs to get someone
to finally type sh /etc/netstart after doing all of the above.

But I have never worked in that field, so I really don't know what goes
on in their server farms.
There was another issue that I did not know how to deal with. I will
mention that in replying to another in this thread.

-- 
Chris Bennett

Re: I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI

[Philipp Buehler]

Moin Chris,

Am 29.07.2023 04:17 schrieb Chris Bennett:

The network is 108.181.26.176/28.

Right now,the first IP is 108.181.26.178 and the last regular address 
is

108.181.26.190, which might be wrong. I'm too tired to read any more
man pages or web pages. I needed more than 2hrs of sleep.
I'm super worn out, so forgive my mistakes.

Any help appreciated. I don't want the next syspatch reboot to fail.


To save mindboggling counting of 'f' or similar, just write this to 
/etc/hostname.em1

inet 108.181.26.178/28
The ifconfig called from netstart will figure it out ;-) That's a 
headups for everybody, so cc misc@.


The current ifconfig em1 shows a bit wild setup for 108.181.26.179; but 
that


is likely unintended and the wrong mask/bc will be gone with the above 
setting.


The route output shows several hosts in 108.136/108.137 ranges where 
there

is no corresponding setup given.

But to reach the system via 108.181.26.178 again, this looks sound.

HTH,
--
pb

PS:
tyo# cat /etc/hostname.vlan1
vlandev vio0
inet 108.181.26.178/28
tyo# sh /etc/netstart vlan1
tyo# ifconfig vlan1
vlan1: flags=8843 mtu 1500
lladdr fe:e1:bb:6e:63:36
index 7 priority 0 llprio 3
encap: vnetid none parent vio0 txprio packet rxprio outer
groups: vlan
media: Ethernet autoselect
status: active
inet 108.181.26.178 netmask 0xfff0 broadcast 108.181.26.191
PPS: to check quickly on reachability of a gateway directly:
ping -I 108.181.26.178 -t 1 108.181.26.177
and check arp table accordingly

Re: I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI

[All]

t acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P8)
acpiprt4 at acpi0: bus 3 (P0P9)
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
acpicmos0 at acpi0
com2 at acpi0 UAR3 addr 0x3e8/0x8 irq 5: ns16550a, 16 byte fifo
acpibtn0 at acpi0: PWRB
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
ipmi at mainbus0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 4 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 4 int 19
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 4 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 
00:25:90:6c:43:42
ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
em1 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 
00:25:90:6c:43:43
uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 23
uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 4 int 19
uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x02: apic 4 int 18
ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x02: apic 4 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92
pci4 at ppb3 bus 4
vga1 at pci4 dev 4 function 0 "Matrox MGA G200eW" rev 0x0a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 31 function 0 "Intel 82801IR LPC" rev 0x02
ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.2
ahci0: port 0: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  naa.50014ee6acc1fb45
sd0: 476940MB, 512 bytes/sector, 976773168 sectors
ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 4 int 18
iic0 at ichiic0
lm1 at iic0 addr 0x2d: W83627DHG
spdmem0 at iic0 addr 0x51: 4GB DDR3 SDRAM PC3-10600 SO-DIMM
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb6 at uhci4: USB revision 1.0
uhub6 at usb6 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb7 at uhci5: USB revision 1.0
uhub7 at usb7 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: W83627DHG rev 0x25
lm2 at wbsio0 port 0xca0/8: W83627DHG
lm1: disabling sensors due to alias with lm2
uhidev0 at uhub4 port 2 configuration 1 interface 0 "Winbond Electronics Corp 
Hermon USB hidmouse Device" rev 1.10/0.01 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
uhidev1 at uhub4 port 2 configuration 1 interface 1 "Winbond Electronics Corp 
Hermon USB hidmouse Device" rev 1.10/0.01 addr 2
uhidev1: iclass 3/1
ukbd0 at uhidev1: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (b4791705815c7b9f.a) swap on sd0b dump on sd0b

I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI

[Chris Bennett]

re 1, package 0
ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P8)
acpiprt4 at acpi0: bus 3 (P0P9)
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
acpicmos0 at acpi0
com2 at acpi0 UAR3 addr 0x3e8/0x8 irq 5: ns16550a, 16 byte fifo
acpibtn0 at acpi0: PWRB
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpicpu2 at acpi0: C1(@1 halt!)
acpicpu3 at acpi0: C1(@1 halt!)
ipmi at mainbus0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 4 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 4 int 19
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 4 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
em0 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 
00:25:90:6c:43:42
ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
em1 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 
00:25:90:6c:43:43
uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 23
uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 4 int 19
uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x02: apic 4 int 18
ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x02: apic 4 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92
pci4 at ppb3 bus 4
vga1 at pci4 dev 4 function 0 "Matrox MGA G200eW" rev 0x0a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 31 function 0 "Intel 82801IR LPC" rev 0x02
ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.2
ahci0: port 0: 3.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  naa.50014ee6acc1fb45
sd0: 476940MB, 512 bytes/sector, 976773168 sectors
ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 4 int 18
iic0 at ichiic0
lm1 at iic0 addr 0x2d: W83627DHG
spdmem0 at iic0 addr 0x51: 4GB DDR3 SDRAM PC3-10600 SO-DIMM
usb2 at uhci0: USB revision 1.0
uhub2 at usb2 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb3 at uhci1: USB revision 1.0
uhub3 at usb3 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb4 at uhci2: USB revision 1.0
uhub4 at usb4 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb5 at uhci3: USB revision 1.0
uhub5 at usb5 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb6 at uhci4: USB revision 1.0
uhub6 at usb6 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
usb7 at uhci5: USB revision 1.0
uhub7 at usb7 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 
addr 1
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: W83627DHG rev 0x25
lm2 at wbsio0 port 0xca0/8: W83627DHG
lm1: disabling sensors due to alias with lm2
uhidev0 at uhub4 port 2 configuration 1 interface 0 "Winbond Electronics Corp 
Hermon USB hidmouse Device" rev 1.10/0.01 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
uhidev1 at uhub4 port 2 configuration 1 interface 1 "Winbond Electronics Corp 
Hermon USB hidmouse Device" rev 1.10/0.01 addr 2
uhidev1: iclass 3/1
ukbd0 at uhidev1: 8 variable keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (b4791705815c7b9f.a) swap on sd0b dump on sd0b

Re: 6.7 trouble reaching ipmi on supermicro atom

[Stuart Henderson]

On 2020-06-28, obs...@loopw.com  wrote:
>
>
>> On Jun 11, 2020, at 10:31 AM, obs...@loopw.com wrote:
>> 
>> I didn’t have to bisect! Woo! While ipmitool no longer seems to function, 
>> once I enable ipmi in my running kernel I can successfully reboot a 6.7 
>> ipmi-of-this-vintage system now - where previously, from 6.6 going back into 
>> late 4.x land, these systems would hang on reboot until I reset the BMC. 
>
> I stand corrected - the BMC was reset recently enough that I was fooled into 
> thinking everything was great with the system.  Effectively, enabling ipmi in 
> the kernel in 6.7 doesnt let ipmitool attach to the ipmi I have, thus making 
> them quasi-not-so-useful boards with 6.7 as is. When I get time I will bisect 
> the 6.7 changes, I guess. Note that they ran 5.2 through 6.6 and let me 
> attach ipmitool.  Supermicro X7SPE-HF-D525 for those interested, dmesg output 
> is posted at the start of this thread.  


/dev/ipmi access should be fixed in -current now thanks to a report
from a user who spent the time to bisect.

Re: 6.7 trouble reaching ipmi on supermicro atom

[obsdml]

> On Jun 11, 2020, at 10:31 AM, obs...@loopw.com wrote:
> 
> I didn’t have to bisect! Woo! While ipmitool no longer seems to function, 
> once I enable ipmi in my running kernel I can successfully reboot a 6.7 
> ipmi-of-this-vintage system now - where previously, from 6.6 going back into 
> late 4.x land, these systems would hang on reboot until I reset the BMC. 

I stand corrected - the BMC was reset recently enough that I was fooled into 
thinking everything was great with the system.  Effectively, enabling ipmi in 
the kernel in 6.7 doesnt let ipmitool attach to the ipmi I have, thus making 
them quasi-not-so-useful boards with 6.7 as is. When I get time I will bisect 
the 6.7 changes, I guess. Note that they ran 5.2 through 6.6 and let me attach 
ipmitool.  Supermicro X7SPE-HF-D525 for those interested, dmesg output is 
posted at the start of this thread.  

Re: 6.7 trouble reaching ipmi on supermicro atom

[obsdml]

> On May 31, 2020, at 6:07 PM, obs...@loopw.com wrote:
> 
> ipmitool is timing out on my system with the kernel driver loaded, where I 
> havent seen this in previous releases.
> 
> I looked at the changes in 6.7 for ipmi.c, there's a number of them (thank 
> you!)  My intention is to bisect for which change may have caused this, but 
> if someone knows what’s going on, I’m all ears.

I didn’t have to bisect! Woo! While ipmitool no longer seems to function, once 
I enable ipmi in my running kernel I can successfully reboot a 6.7 
ipmi-of-this-vintage system now - where previously, from 6.6 going back into 
late 4.x land, these systems would hang on reboot until I reset the BMC.  I no 
longer have to create a custom /etc/rc.shutdown and other things that did evil 
stuff like reset the bmc just before rebooting the box in order to avoid a 
lockup.  Oh right, my point:

THANK YOU FOR FIXING UP THE IPMI CODE! THANK YOU!

6.7 trouble reaching ipmi on supermicro atom

[obsdml]

ipmitool is timing out on my system with the kernel driver loaded, where I 
havent seen this in previous releases.

I looked at the changes in 6.7 for ipmi.c, there's a number of them (thank 
you!)  My intention is to bisect for which change may have caused this, but if 
someone knows what’s going on, I’m all ears.


This behavior has happened on two systems that I've tried so far:

cobalt# ipmitool sel
Unable to send command: Device busy
Get Device ID command failed
No data available
Unable to send command: Device busy
No valid response received
No data available
Get SEL Info command failed


I loaded ipmi in this kernel as I have in previous releases, seems to be 
present:

cobalt# echo find ipmi | config -e -o /bsd.test /bsd
OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020

r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Enter 'help' for information
ukc> find ipmi
447 ipmi0 at acpi0 flags 0x0
448 ipmi0 at mainbus0 apid -1 flags 0x0
ukc> config: eof


OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020

r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4277665792 (4079MB)
avail mem = 4135411712 (3943MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9ac00 (19 entries)
bios0: vendor American Megatrends Inc. version "1.2b" date 07/19/13
bios0: Supermicro X7SPA-HF
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET EINJ BERT ERST HEST
acpi0: wakeup devices P0P1(S4) USB0(S4) USB1(S4) USB2(S4) USB5(S4) EUSB(S4) 
USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) P0P5(S4) P0P6(S4) P0P7(S4) 
P0P8(S4) P0P9(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.91 MHz, 06-1c-0a
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 166MHz
cpu0: mwait min=64, max=64, C-substates=0.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.68 MHz, 06-1c-0a
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 3 pa 0xfec0, version 20, 24 pins, remapped
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 4 (P0P1)
acpiprt2 at acpi0: bus 1 (P0P4)
acpiprt3 at acpi0: bus 2 (P0P8)
acpiprt4 at acpi0: bus 3 (P0P9)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
acpicmos0 at acpi0
acpibtn0 at acpi0: PWRB
ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca2/2 spacing 1
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Pineview DMI" rev 0x02
uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 16
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 21
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 3 int 19
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 3 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 
addr 1
ppb0 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 3 int 16, address 
00:1b:21:88:9f:20
em1 at pci1 dev 0 function 1 "Intel 82571EB" rev 0x06: apic 3 int 17, address 
00:1b:21:88:9f:21
ppb1 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: msi
pci2 at ppb1 bus 2
em2 at pci2 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 
00:25:90:0a:40:72
ppb2 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: msi
pci3 at ppb2 bus 3
em3 at pci3 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 
00:25:90:0a:40:73
uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 3 int 23
uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 3 int 19
uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x02: apic 3 int 18
ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x02: apic 3 int 23
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 

Re: OpenBSD and IPMI

[Rupert Gallagher]

I extend the question to Intel ME (similar to IPMI), cloud hosting (direct 
access to hardware by sysadmins) and virtual machines. I think the answer is 
default encryption of both disk and ram.

On Fri, Mar 9, 2018 at 14:11, Denis  wrote:

> By reading this article 
> blog.rapid7.com/2013/07/02/a-penetration-testers-guide-to-ipmi/ my hair 
> raised.  How to OpenBSD security withstands against IPMI holed solution from 
> top hardware vendors? Best ways to prevent potential risks for OpenBSD over 
> IPMI? Thanks

Re: OpenBSD and IPMI

[Stuart Henderson]

On 2018-03-09, Consus  wrote:
> On 16:11 Fri 09 Mar, Denis wrote:
>> By reading this article
>> blog.rapid7.com/2013/07/02/a-penetration-testers-guide-to-ipmi/ my hair
>> raised. 
>> 
>> How to OpenBSD security withstands against IPMI holed solution from top
>> hardware vendors?
>> 
>> Best ways to prevent potential risks for OpenBSD over IPMI?
>
> Make your IPMI network private.
>
>

And beware, some machines failover to sharing with a main nic if nothing's
connected to the management nic, and have a common default password.

Re: OpenBSD and IPMI

[Consus]

On 16:11 Fri 09 Mar, Denis wrote:
> By reading this article
> blog.rapid7.com/2013/07/02/a-penetration-testers-guide-to-ipmi/ my hair
> raised. 
> 
> How to OpenBSD security withstands against IPMI holed solution from top
> hardware vendors?
> 
> Best ways to prevent potential risks for OpenBSD over IPMI?

Make your IPMI network private.

Re: OpenBSD and IPMI

[Kapetanakis Giannis]

On 09/03/18 15:11, Denis wrote:
> By reading this article
> blog.rapid7.com/2013/07/02/a-penetration-testers-guide-to-ipmi/ my hair
> raised. 
> 
> How to OpenBSD security withstands against IPMI holed solution from top
> hardware vendors?
> 
> Best ways to prevent potential risks for OpenBSD over IPMI?
> 
> Thanks

The OS has nothing to do with a onboard-device running it's own firmware and 
having direct access to network.

Look for how you can secure/disable lom/drac/bmc whatever itself or the network 
that is given access to.

G

Re: OpenBSD and IPMI

[Janne Johansson]

2018-03-09 14:11 GMT+01:00 Denis :

> By reading this article
> blog.rapid7.com/2013/07/02/a-penetration-testers-guide-to-ipmi/ my hair
> raised. 
>
> How to OpenBSD security withstands against IPMI holed solution from top
> hardware vendors?
>

TOP hardware vendors name it LOM or ILO or Drac instead, then you are safe
from IPMI holes. ;)

-- 
May the most significant bit of your life be positive.

OpenBSD and IPMI

[Denis]

By reading this article
blog.rapid7.com/2013/07/02/a-penetration-testers-guide-to-ipmi/ my hair
raised. 

How to OpenBSD security withstands against IPMI holed solution from top
hardware vendors?

Best ways to prevent potential risks for OpenBSD over IPMI?

Thanks

Re: IPMI still requires Java! I'm screwed.

[Stuart Henderson]

On 2017-12-21, Robert Blacquiere  wrote:
> On Thu, Dec 21, 2017 at 08:50:02AM +0300, kasak wrote:
>
>> > 
>> Look at the newest servers with aspeed ast2500, such as supermicro x11 
>> platforms, they are manageable through html5. If you still need to manage 
>> your server try jdk-1.8.0.144v0.tgz package from ports
>> 
> You could also try running linux in vm with icedtea-Web plugin for
> firefox on linux. That seems to work with older SuperMicro machines
> without much issues. Also the bundled IPMIviewer for linux works fine. 

Some of these work with the version of noVNC ("bmc-support" branch)
that is in ports.

Re: Solved IPMI, but I can't get onto network to outside

[Chris Bennett]

switched to em1, no problem.
em0 is clearly defective.

Thanks for the help!

Chris Bennett

Re: Solved IPMI, but I can't get onto network to outside

[Chris Bennett]

>  Original Message 
> Subject: Re: Solved IPMI, but I can't get onto network to outside
> From: Scott Nicholas 
> Date: Thu, December 21, 2017 2:41 pm
> To: Chris Bennett 
> Cc: ed...@pettijohn-web.com, misc@openbsd.org
> 
> 
> On Dec 21, 2017 2:58 PM, "Chris Bennett" 
> wrote:
> 
> 
> 
> > ---- Original Message 
> > Subject: Re: Solved IPMI, but I can't get onto network to outside
> > From: ed...@pettijohn-web.com
> > Date: Thu, December 21, 2017 1:42 pm
> > To: Chris Bennett 
> > Cc: misc@openbsd.org
> >
> >
> > On Dec 21, 2017 12:57 PM, Chris Bennett 
> wrote:
> > >
> > > OK, I've not had this setup before and I can't get it
> > > to work. I am not sure what to move or which commands
> > > to use to investigate. I.E. I don't know how to
> > > interpret what I see from them.
> > >
> > > I got this from support:
> > >
> > > I have checked the prefix routing and I dont see any issue with
> > > networking.
> > > You have assigned the below prefix. Please check and configure as per,
> > >
> > > IP: 104.217.196.248/29
> > > Gateway: 104.217.196.249
> > > Netmask: 255.255.255.248
> > >
> >
> > What is your network interface?
> >
> 
> I have two, em0 and em1
> 
> em0:
> inet 104.217.196.248 255.255.255.248
> 
> And I admit I really don't see what IP addresses I get
> with 104.217.196.248/29.
> Especially confusing with 104.217.196.249 as the gateway address
> 
> Chris Bennett
> 
> 
> You get 6 addresses from that, but one is used by the gateway. Use
> 104.217.196.250 to 254 for your devices.
> 
> em0:
> inet 104.217.196.250 255.255.255.248 104.217.196.255
> 

Even after a reboot, this fails to work.
Is there something I am missing or do I need to kick this back
to support?

Thanks,
Chris Bennett

Re: Solved IPMI, but I can't get onto network to outside

[Scott Nicholas]

On Dec 21, 2017 2:58 PM, "Chris Bennett" 
wrote:



>  Original Message 
> Subject: Re: Solved IPMI, but I can't get onto network to outside
> From: ed...@pettijohn-web.com
> Date: Thu, December 21, 2017 1:42 pm
> To: Chris Bennett 
> Cc: misc@openbsd.org
>
>
> On Dec 21, 2017 12:57 PM, Chris Bennett 
wrote:
> >
> > OK, I've not had this setup before and I can't get it
> > to work. I am not sure what to move or which commands
> > to use to investigate. I.E. I don't know how to
> > interpret what I see from them.
> >
> > I got this from support:
> >
> > I have checked the prefix routing and I dont see any issue with
> > networking.
> > You have assigned the below prefix. Please check and configure as per,
> >
> > IP: 104.217.196.248/29
> > Gateway: 104.217.196.249
> > Netmask: 255.255.255.248
> >
>
> What is your network interface?
>

I have two, em0 and em1

em0:
inet 104.217.196.248 255.255.255.248

And I admit I really don't see what IP addresses I get
with 104.217.196.248/29.
Especially confusing with 104.217.196.249 as the gateway address

Chris Bennett


You get 6 addresses from that, but one is used by the gateway. Use
104.217.196.250 to 254 for your devices.

em0:
inet 104.217.196.250 255.255.255.248 104.217.196.255


Regards,
Scott

Re: Solved IPMI, but I can't get onto network to outside

[Paul B. Henson]

On Thu, Dec 21, 2017 at 12:52:33PM -0700, Chris Bennett wrote:

> > > IP: 104.217.196.248/29
> > > Gateway: 104.217.196.249
> > > Netmask: 255.255.255.248
> > >
> > 
> > What is your network interface?
> > 
> 
> I have two, em0 and em1
> 
> em0:
> inet 104.217.196.248 255.255.255.248
> 
> And I admit I really don't see what IP addresses I get
> with 104.217.196.248/29.

That's not the IP address you're supposed to use, that's the subnet
they've allocated you.

See:

http://www.subnet-calculator.com/subnet.php

104.217.196.248 is the network address, you can't assign that to an
actual host. The usable IP addresses in that subnet are
104.217.196.249-104.217.196.254, 104.217.196.249 is your gateway, so
that leaves you 104.217.196.250-104.217.196.254 to assign to your
systems. 104.217.196.255 is the broadcast address for the subnet.

Update your hostname.em0 to use 104.217.196.250 and make sure your
/etc/mygate file contains 104.217.196.249.

Re: Solved IPMI, but I can't get onto network to outside

[Chris Bennett]

>  Original Message 
> Subject: Re: Solved IPMI, but I can't get onto network to outside
> From: "Chris Bennett" 
> Date: Thu, December 21, 2017 1:52 pm
> To: ed...@pettijohn-web.com
> Cc: misc@openbsd.org
> 
> 
> >  Original Message 
> > Subject: Re: Solved IPMI, but I can't get onto network to outside
> > From: ed...@pettijohn-web.com
> > Date: Thu, December 21, 2017 1:42 pm
> > To: Chris Bennett 
> > Cc: misc@openbsd.org
> > 
> > 
> > On Dec 21, 2017 12:57 PM, Chris Bennett  
> > wrote:
> > >
> > > OK, I've not had this setup before and I can't get it
> > > to work. I am not sure what to move or which commands
> > > to use to investigate. I.E. I don't know how to
> > > interpret what I see from them.
> > >
> > > I got this from support:
> > >
> > > I have checked the prefix routing and I dont see any issue with
> > > networking.
> > > You have assigned the below prefix. Please check and configure as per,
> > >
> > > IP: 104.217.196.248/29
> > > Gateway: 104.217.196.249
> > > Netmask: 255.255.255.248
> > >
> > 
> > What is your network interface?
> > 
> 
> I have two, em0 and em1
> 
> em0:
> inet 104.217.196.248 255.255.255.248
> 
> And I admit I really don't see what IP addresses I get
> with 104.217.196.248/29.
> Especially confusing with 104.217.196.249 as the gateway address
> 
> Chris Bennett


OK, I can ping the router address from windows, but not my addresses
Chris Bennett

Re: Solved IPMI, but I can't get onto network to outside

[Chris Bennett]

>  Original Message 
> Subject: Re: Solved IPMI, but I can't get onto network to outside
> From: ed...@pettijohn-web.com
> Date: Thu, December 21, 2017 1:42 pm
> To: Chris Bennett 
> Cc: misc@openbsd.org
> 
> 
> On Dec 21, 2017 12:57 PM, Chris Bennett  
> wrote:
> >
> > OK, I've not had this setup before and I can't get it
> > to work. I am not sure what to move or which commands
> > to use to investigate. I.E. I don't know how to
> > interpret what I see from them.
> >
> > I got this from support:
> >
> > I have checked the prefix routing and I dont see any issue with
> > networking.
> > You have assigned the below prefix. Please check and configure as per,
> >
> > IP: 104.217.196.248/29
> > Gateway: 104.217.196.249
> > Netmask: 255.255.255.248
> >
> 
> What is your network interface?
> 

I have two, em0 and em1

em0:
inet 104.217.196.248 255.255.255.248

And I admit I really don't see what IP addresses I get
with 104.217.196.248/29.
Especially confusing with 104.217.196.249 as the gateway address

Chris Bennett

Re: Solved IPMI, but I can't get onto network to outside

[edgar]

On Dec 21, 2017 12:57 PM, Chris Bennett  
wrote:
>
> OK, I've not had this setup before and I can't get it
> to work. I am not sure what to move or which commands
> to use to investigate. I.E. I don't know how to
> interpret what I see from them.
>
> I got this from support:
>
> I have checked the prefix routing and I dont see any issue with
> networking.
> You have assigned the below prefix. Please check and configure as per,
>
> IP: 104.217.196.248/29
> Gateway: 104.217.196.249
> Netmask: 255.255.255.248
>

What is your network interface?

hostname.if(5)

/etc/mygate
104.217.196.249

> You can use below nameserver,
>
> nameserver 8.8.8.8
> nameserver 8.8.4.4
> nameserver 208.87.241.170
> nameserver 198.13.100.82
>
> Chris Bennett
>
>
>

Solved IPMI, but I can't get onto network to outside

[Chris Bennett]

OK, I've not had this setup before and I can't get it
to work. I am not sure what to move or which commands
to use to investigate. I.E. I don't know how to
interpret what I see from them.

I got this from support:

I have checked the prefix routing and I dont see any issue with
networking.
You have assigned the below prefix. Please check and configure as per,

IP: 104.217.196.248/29
Gateway: 104.217.196.249
Netmask: 255.255.255.248

You can use below nameserver,

nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 208.87.241.170
nameserver 198.13.100.82

Chris Bennett

Re: IPMI still requires Java! I'm screwed.

[x9p]

On Thu, December 21, 2017 1:22 pm, Robert Blacquiere wrote:
...
> You could also try running linux in vm with icedtea-Web plugin for
> firefox on linux. That seems to work with older SuperMicro machines
> without much issues. Also the bundled IPMIviewer for linux works fine.
> The main issue is with the IPMI (from ATEN) is it uses iKVM.jar which is
> not supported for a lot of OS-ses.
>
> Regards
>
> Robert
>
>

true. VMD+alpine+x11vnc runs in probably very old/crappy hardware, dunno if 
will run the jar
though.
in the past i preferred HP servers with iLO remote management.

cheers.

--
x9p | PGP : 0x03B50AF5EA4C8D80 / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 
E7EE

Re: IPMI still requires Java! I'm screwed.

[Chris Bennett]

>  Original Message 
> Subject: Re: IPMI still requires Java! I'm screwed.
> From: "Alceu R. de Freitas Jr." 
> Date: Thu, December 21, 2017 11:04 am
> To: misc@openbsd.org
> 
> 
> I'm a bit late to answer, but maybe you could check with the manufacturer?
> Java applets are gone... Oracle will not support them anymore due security 
> issues, so maybe the manufacturer could give you a hand on this.
> If they don't, maybe you could try some reverse engineering? Unless the 
> manufacturer spent time (and money) running the Java applet into some code 
> obfuscation software, there are good chances you can checkout what's the code 
> does. Or even using a network sniffer, whatever seems to be easier.
> Of course, none of those are easy/fast ways to get your trouble resolved. 
> That's why sucks to buy things with proprietary code attached. If they decide 
> to not support the product anymore, you're screwed.
> Em quinta-feira, 21 de dezembro de 2017 14:33:27 BRST, Robert Blacquiere 
>  escreveu:  
>  
>  On Thu, Dec 21, 2017 at 08:50:02AM +0300, kasak wrote:
> 
> > > 
> > Look at the newest servers with aspeed ast2500, such as supermicro x11 
> > platforms, they are manageable through html5. If you still need to manage 
> > your server try jdk-1.8.0.144v0.tgz package from ports
> > 
> You could also try running linux in vm with icedtea-Web plugin for
> firefox on linux. That seems to work with older SuperMicro machines
> without much issues. Also the bundled IPMIviewer for linux works fine. 
> The main issue is with the IPMI (from ATEN) is it uses iKVM.jar which is
> not supported for a lot of OS-ses.
> 
> Regards
> 
> Robert


Right now,I only have access to an old laptop a friend is letting me use
that runs Windows 7. It is too broken to change OS.

I finally did find a way to get things to work.
The Firefox ESR 32bit still allows Java. Mozilla is going to drop this
ESR
If you install Java 7, it has the medium security option still.
So it works. Really lousy internet connection here. I really pointed
this out to the owner and he says he is going to call the company.
I still can't get the server to connect over the network itself.
I did manage to finally install base plus the bsd's.
I'm going to start a new thread about this problem.

Chris Bennett

Re: IPMI still requires Java! I'm screwed.

[Alceu R. de Freitas Jr.]

 I'm a bit late to answer, but maybe you could check with the manufacturer?
Java applets are gone... Oracle will not support them anymore due security 
issues, so maybe the manufacturer could give you a hand on this.
If they don't, maybe you could try some reverse engineering? Unless the 
manufacturer spent time (and money) running the Java applet into some code 
obfuscation software, there are good chances you can checkout what's the code 
does. Or even using a network sniffer, whatever seems to be easier.
Of course, none of those are easy/fast ways to get your trouble resolved. 
That's why sucks to buy things with proprietary code attached. If they decide 
to not support the product anymore, you're screwed.
Em quinta-feira, 21 de dezembro de 2017 14:33:27 BRST, Robert Blacquiere 
 escreveu:  
 
 On Thu, Dec 21, 2017 at 08:50:02AM +0300, kasak wrote:

> > 
> Look at the newest servers with aspeed ast2500, such as supermicro x11 
> platforms, they are manageable through html5. If you still need to manage 
> your server try jdk-1.8.0.144v0.tgz package from ports
> 
You could also try running linux in vm with icedtea-Web plugin for
firefox on linux. That seems to work with older SuperMicro machines
without much issues. Also the bundled IPMIviewer for linux works fine. 
The main issue is with the IPMI (from ATEN) is it uses iKVM.jar which is
not supported for a lot of OS-ses.

Regards

Robert

  

Re: IPMI still requires Java! I'm screwed.

[Robert Blacquiere]

On Thu, Dec 21, 2017 at 08:50:02AM +0300, kasak wrote:

> > 
> Look at the newest servers with aspeed ast2500, such as supermicro x11 
> platforms, they are manageable through html5. If you still need to manage 
> your server try jdk-1.8.0.144v0.tgz package from ports
> 
You could also try running linux in vm with icedtea-Web plugin for
firefox on linux. That seems to work with older SuperMicro machines
without much issues. Also the bundled IPMIviewer for linux works fine. 
The main issue is with the IPMI (from ATEN) is it uses iKVM.jar which is
not supported for a lot of OS-ses.

Regards

Robert

Re: IPMI still requires Java! I'm screwed.

[Maxim Bourmistrov]

Yepp.
I have
bios0: Supermicro X10DRT-PT
With latest IPMI firmware and have html5.


> 21 dec. 2017 kl. 12:00 skrev kasak :
> 
> 
>> 21 дек. 2017 г., в 12:16, Maxim Bourmistrov  
>> написал(а):
>> 
>> 
>> Even X10 can be upgraded to get in html5.
>> 
>>> 21 dec. 2017 kl. 06:50 skrev kasak :
>>> 
>>> 
>>>> 21 дек. 2017 г., в 0:03, Chris Bennett  
>>>> написал(а):
>>>> 
>>>> I found a new server that uses IPMI and offers using it
>>>> to setup your own custom OS. So I bought in.
>>>> 
>>>> Damn thing requires Java.
>>>> They offered me some pretty worthless advice on using
>>>> Java.
>>>> 
>>>> I'm screwed into having to use Windows 7.
>>>> I've tried the Firefox ESR 32bit that supports Java.
>>>> Nope.
>>>> Opera. Nope
>>>> Edge. Nope
>>>> Chrome. Nope, including trying to use IEtab
>>>> 
>>>> Is it actually possible to get any web browser to 
>>>> open a Java applet?
>>>> 
>>>> I'm using a friends laptop and it can't stay on while
>>>> in the BIOS or after booting OpenBSD just to the point
>>>> of running memtest.
>>>> 
>>>> I'm a bit confused about what to do.
>>>> They offer IPMI that won't work without Java.
>>>> 
>>>> Is this even anything more than a scam??
>>>> I don't know squat about windows other than it sucks.
>>>> 
>>>> 
>>>> Serious question:
>>>> Is it acceptable practice to offer remote access that
>>>> cannot be used?
>>>> 
>>>> 
>>>> 
>>> Look at the newest servers with aspeed ast2500, such as supermicro x11 
>>> platforms, they are manageable through html5. If you still need to manage 
>>> your server try jdk-1.8.0.144v0.tgz package from ports
>>> 
>> 
> Just by updating firmware?  What a pity, Asus hasn’t upgraded firmwares to 
> support html5, I have some of them in usage with p10 platforms

Re: IPMI still requires Java! I'm screwed.

[kasak]

> 21 дек. 2017 г., в 12:16, Maxim Bourmistrov  
> написал(а):
> 
> 
> Even X10 can be upgraded to get in html5.
> 
>> 21 dec. 2017 kl. 06:50 skrev kasak :
>> 
>> 
>>> 21 дек. 2017 г., в 0:03, Chris Bennett  
>>> написал(а):
>>> 
>>> I found a new server that uses IPMI and offers using it
>>> to setup your own custom OS. So I bought in.
>>> 
>>> Damn thing requires Java.
>>> They offered me some pretty worthless advice on using
>>> Java.
>>> 
>>> I'm screwed into having to use Windows 7.
>>> I've tried the Firefox ESR 32bit that supports Java.
>>> Nope.
>>> Opera. Nope
>>> Edge. Nope
>>> Chrome. Nope, including trying to use IEtab
>>> 
>>> Is it actually possible to get any web browser to 
>>> open a Java applet?
>>> 
>>> I'm using a friends laptop and it can't stay on while
>>> in the BIOS or after booting OpenBSD just to the point
>>> of running memtest.
>>> 
>>> I'm a bit confused about what to do.
>>> They offer IPMI that won't work without Java.
>>> 
>>> Is this even anything more than a scam??
>>> I don't know squat about windows other than it sucks.
>>> 
>>> 
>>> Serious question:
>>> Is it acceptable practice to offer remote access that
>>> cannot be used?
>>> 
>>> 
>>> 
>> Look at the newest servers with aspeed ast2500, such as supermicro x11 
>> platforms, they are manageable through html5. If you still need to manage 
>> your server try jdk-1.8.0.144v0.tgz package from ports
>> 
> 
Just by updating firmware?  What a pity, Asus hasn’t upgraded firmwares to 
support html5, I have some of them in usage with p10 platforms

Re: IPMI still requires Java! I'm screwed.

[Maxim Bourmistrov]

Even X10 can be upgraded to get in html5.
 
> 21 dec. 2017 kl. 06:50 skrev kasak :
> 
> 
>> 21 дек. 2017 г., в 0:03, Chris Bennett  
>> написал(а):
>> 
>> I found a new server that uses IPMI and offers using it
>> to setup your own custom OS. So I bought in.
>> 
>> Damn thing requires Java.
>> They offered me some pretty worthless advice on using
>> Java.
>> 
>> I'm screwed into having to use Windows 7.
>> I've tried the Firefox ESR 32bit that supports Java.
>> Nope.
>> Opera. Nope
>> Edge. Nope
>> Chrome. Nope, including trying to use IEtab
>> 
>> Is it actually possible to get any web browser to 
>> open a Java applet?
>> 
>> I'm using a friends laptop and it can't stay on while
>> in the BIOS or after booting OpenBSD just to the point
>> of running memtest.
>> 
>> I'm a bit confused about what to do.
>> They offer IPMI that won't work without Java.
>> 
>> Is this even anything more than a scam??
>> I don't know squat about windows other than it sucks.
>> 
>> 
>> Serious question:
>> Is it acceptable practice to offer remote access that
>> cannot be used?
>> 
>> 
>> 
> Look at the newest servers with aspeed ast2500, such as supermicro x11 
> platforms, they are manageable through html5. If you still need to manage 
> your server try jdk-1.8.0.144v0.tgz package from ports
> 

Re: IPMI still requires Java! I'm screwed.

[Lyndon Nerenberg]

We manage to deal with all our servers using the IPMI serial console redirect.  
You might need to set it up in the BIOS once, although we've not had to do that 
in ages.  You do have to create the IPMI remote login/password, but you need 
that anyway if you're trying to use the web/java console.

--lyndon

Re: IPMI still requires Java! I'm screwed.

[kasak]

> 21 дек. 2017 г., в 0:03, Chris Bennett  
> написал(а):
> 
> I found a new server that uses IPMI and offers using it
> to setup your own custom OS. So I bought in.
> 
> Damn thing requires Java.
> They offered me some pretty worthless advice on using
> Java.
> 
> I'm screwed into having to use Windows 7.
> I've tried the Firefox ESR 32bit that supports Java.
> Nope.
> Opera. Nope
> Edge. Nope
> Chrome. Nope, including trying to use IEtab
> 
> Is it actually possible to get any web browser to 
> open a Java applet?
> 
> I'm using a friends laptop and it can't stay on while
> in the BIOS or after booting OpenBSD just to the point
> of running memtest.
> 
> I'm a bit confused about what to do.
> They offer IPMI that won't work without Java.
> 
> Is this even anything more than a scam??
> I don't know squat about windows other than it sucks.
> 
> 
> Serious question:
> Is it acceptable practice to offer remote access that
> cannot be used?
> 
> 
> 
Look at the newest servers with aspeed ast2500, such as supermicro x11 
platforms, they are manageable through html5. If you still need to manage your 
server try jdk-1.8.0.144v0.tgz package from ports

Re: IPMI still requires Java! I'm screwed.

[Torsten]

NO,
Just download ipmiview from SM and use the build in viewer and all is OK
The power can still be managed  with the web site.

IPMI vire requires java.exe on your PC but rund independently of any browser
T


-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of Chris 
Bennett
Sent: 20 December 2017 21:04
To: misc@openbsd.org
Subject: IPMI still requires Java! I'm screwed.

I found a new server that uses IPMI and offers using it to setup your own 
custom OS. So I bought in.

Damn thing requires Java.
They offered me some pretty worthless advice on using Java.

I'm screwed into having to use Windows 7.
I've tried the Firefox ESR 32bit that supports Java.
Nope.
Opera. Nope
Edge. Nope
Chrome. Nope, including trying to use IEtab

Is it actually possible to get any web browser to open a Java applet?

I'm using a friends laptop and it can't stay on while in the BIOS or after 
booting OpenBSD just to the point of running memtest.

I'm a bit confused about what to do.
They offer IPMI that won't work without Java.

Is this even anything more than a scam??
I don't know squat about windows other than it sucks.


Serious question:
Is it acceptable practice to offer remote access that cannot be used?

IPMI still requires Java! I'm screwed.

[Chris Bennett]

I found a new server that uses IPMI and offers using it
to setup your own custom OS. So I bought in.

Damn thing requires Java.
They offered me some pretty worthless advice on using
Java.

I'm screwed into having to use Windows 7.
I've tried the Firefox ESR 32bit that supports Java.
Nope.
Opera. Nope
Edge. Nope
Chrome. Nope, including trying to use IEtab

Is it actually possible to get any web browser to 
open a Java applet?

I'm using a friends laptop and it can't stay on while
in the BIOS or after booting OpenBSD just to the point
of running memtest.

I'm a bit confused about what to do.
They offer IPMI that won't work without Java.

Is this even anything more than a scam??
I don't know squat about windows other than it sucks.


Serious question:
Is it acceptable practice to offer remote access that
cannot be used?

Re: ipmi driver broken

[Paul B. Henson]

> 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

[Paul B. Henson]

> 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

[Ted Unangst]

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

[Theo de Raadt]

> 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

[Paul B. Henson]

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

[Predrag Punosevac]

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

[Paul B. Henson]

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...

no SDRs IPMI disabled?

[Paul B. Henson]

I just installed 5.9 on a Supermicro X11SSL-F board, and tried to enable
the ipmi driver. During boot, it shows:

ipmi0 at mainbus0: version 2.0 interface KCS iobase 0xca2/2 spacing 1
iic0: skipping sensors to avoid ipmi0 interactions
ipmi0: get header fails
ipmi0: no SDRs IPMI disabled
ipmi at mainbus0 not configured

Any suggestions on how to make this work? The full dmesg is:


OpenBSD 5.9 (GENERIC.MP) #1888: Fri Feb 26 01:20:19 MST 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16976416768 (16189MB)
avail mem = 16457711616 (15695MB)
User Kernel Config
UKC> enable ipmi
401 ipmi0 enabled
UKC> quit
Continuing...
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x7fb95000 (59 entries)
bios0: vendor American Megatrends Inc. version "1.0b" date 12/29/2015
bios0: Supermicro Super Server
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG HPET SSDT LPIT SSDT SSDT SSDT 
DBGP DBG2 SSDT SSDT UEFI SSDT DMAR EINJ ERST BERT HEST
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) 
PXSX(S4) RP13(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU E3-1240L v5 @ 2.10GHz, 2100.85 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU E3-1240L v5 @ 2.10GHz, 2100.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Xeon(R) CPU E3-1240L v5 @ 2.10GHz, 2100.00 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Xeon(R) CPU E3-1240L v5 @ 2.10GHz, 2100.00 MHz
cpu3: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
cpu4 at mainbus0: apid 1 (application processor)
cpu4: Intel(R) Xeon(R) CPU E3-1240L v5 @ 2.10GHz, 2100.00 MHz
cpu4: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu4: 256KB 64b/line 8-way L2 cache
cpu4: smt 1, core 0, package 0
cpu5 at mainbus0: apid 3 (application processor)
cpu5: Intel(R) Xeon(R) CPU E3-1240L v5 @ 2.10GHz, 2100.00 MHz
cpu5: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,

Re: Supermicro X8SIL-F ipmi and lm issue

[Alexey Suslikov]

Atanas Vladimirov  bsdbg.net> writes:

> I observe strange behavior with Supermicro X8SIL-F. Latest BIOS and IPMI 
> firmware.
> Only one FAN is present (CPU FAN).
> After some time of normal work IPMI start to report errors with one (or 
> more) fans (low speed or not present).
> 'systat sensors' shows wrong or missing data for same fan.
> I tryed to disable lm after reading [0] and it works for me.
> Can this be ACPI related?

known issue. there's some sort of malfunction with wbsio/wbng and
maybe others. if sensors chip is iic-based even weirder things can
happen.

http://thread.gmane.org/gmane.os.openbsd.tech/21491/

Supermicro X8SIL-F ipmi and lm issue

[Atanas Vladimirov]

Hi,
I observe strange behavior with Supermicro X8SIL-F. Latest BIOS and IPMI 
firmware.

Only one FAN is present (CPU FAN).
After some time of normal work IPMI start to report errors with one (or 
more) fans (low speed or not present).

'systat sensors' shows wrong or missing data for same fan.
I tryed to disable lm after reading [0] and it works for me.
Can this be ACPI related?

Also sometimes 'spdmem' is not configured:

-"eeprom" at iic0 addr 0x50 not configured
-"eeprom" at iic0 addr 0x52 not configured
+spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM ECC PC3-10600 with thermal 
sensor
+spdmem1 at iic0 addr 0x52: 2GB DDR3 SDRAM ECC PC3-10600 with thermal 
sensor


[0] http://marc.info/?l=openbsd-misc&m=144433700723961&w=2

 ~$ systat se
1 usersLoad 1.06 1.06 0.82 Tue Oct 13 
12:56:25 2015


SENSOR  VALUE  STATUS  
DESCRIPTION

cpu0.temp0 38.00 degC
sdtemp0.temp0  34.12 degC
sdtemp1.temp0  34.12 degC
softraid0.drive0   onlineOKsd2
nmea0.indicator0   OnOKSignal
nmea0.timedelta0   601.000 usOKGPS
nmea0.angle0  42.6884 degreesOKLatitude
nmea0.angle1  23.3281 degreesOKLongitude

diff:

--- dmesg_with_lm   Fri Oct  9 22:15:02 2015
+++ dmesg_without_lmSat Oct 10 04:13:34 2015
@@ -1,4 +1,4 @@
-OpenBSD 5.8-current (GENERIC.MP) #1447: Fri Oct  9 06:33:19 MDT 2015
+OpenBSD 5.8-current (GENERIC.MP) #1448: Fri Oct  9 12:53:17 MDT 2015
 
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

 real mem = 4269342720 (4071MB)
 avail mem = 4135829504 (3944MB)
@@ -15,7 +15,7 @@
 acpitimer0 at acpi0: 3579545 Hz, 24 bits
 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
 cpu0 at mainbus0: apid 0 (boot processor)
-cpu0: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2400.31 MHz
+cpu0: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2400.29 MHz
 cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR

 cpu0: 256KB 64b/line 8-way L2 cache
 cpu0: smt 0, core 0, package 0
@@ -103,8 +103,8 @@
 iic0 at ichiic0
 sdtemp0 at iic0 addr 0x18: cat34ts02
 sdtemp1 at iic0 addr 0x1a: cat34ts02
-"eeprom" at iic0 addr 0x50 not configured
-"eeprom" at iic0 addr 0x52 not configured
+spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM ECC PC3-10600 with thermal 
sensor
+spdmem1 at iic0 addr 0x52: 2GB DDR3 SDRAM ECC PC3-10600 with thermal 
sensor

 isa0 at pcib0
 isadma0 at isa0
 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
@@ -117,7 +117,7 @@
 pcppi0 at isa0 port 0x61
 spkr0 at pcppi0
 wbsio0 at isa0 port 0x2e/2: W83627DHG rev 0x25
-lm1 at wbsio0 port 0xa10/8: W83627DHG
+wbsio0 port 0xa10/2 not configured
 uhub2 at uhub0 port 1 "Intel Rate Matching Hub" rev 2.00/0.00 addr 2
 uhidev0 at uhub2 port 2 configuration 1 interface 0 "Winbond 
Electronics Corp Hermon USB hidmouse Device" rev 1.10/0.01 addr 3

 uhidev0: iclass 3/1


dmesg with lm enabled:

OpenBSD 5.8-current (GENERIC.MP) #1447: Fri Oct  9 06:33:19 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4269342720 (4071MB)
avail mem = 4135829504 (3944MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9f000 (70 entries)
bios0: vendor American Megatrends Inc. version "1.2a" date 06/27/2012
bios0: Supermicro X8SIL
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP APIC MCFG OEMB HPET GSCI SSDT EINJ BERT ERST 
HEST
acpi0: wakeup devices P0P1(S4) P0P3(S4) P0P4(S4) P0P5(S4) P0P6(S4) 
BR1E(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) 
USB5(S4) USB6(S4) GBE_(S4) [...]

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2400.31 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR

cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Xeon(R) CPU X3430 @ 2.40GHz, 2400.00 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-

Re: Keyboard through IPMI lag/skipping keys

[Federico Giannici]

On 10/22/14 12:18, Stuart Henderson wrote:

Since OpenBSD doesn't have dual serial+tty consoles, you won't see much
on the monitor after rebooting with that in boot.conf - if you need to
skip this, hold ctrl down during boot (specifically, it needs to be
down at the point where the boot loader starts up), this tells the
boot loader not to load boot.conf.



For me this is the only problem of adopting your solution. We need the 
ability for people to eventually access the machine locally (with its 
monitor and keyboard) and see what is the situation.


Do you know of any work been done on solving this limitation and 
allowing a double access to the machine (via SOL and via local 
monitor/keyboard)?


Thanks.

P.S.
Thank you for this email, I found it very very useful. Thanks again!

Re: Keyboard through IPMI lag/skipping keys

[Stuart Henderson]

Replying on-list to an off-list email.

> Are you suggesting that I run a 9pin serial port to the machine
> for console admin?

That is one option, and if you can do it, it's a simple and pretty
trustworthy way to do things, whereas the embedded system handling
IPMI is...not great ;-) However that's not what I was suggesting
here.

First off, as mentioned in my earlier post; I very strongly
recommend using the dedicated lan port and a private network, or
at least plugged into a switch port that's on a management vlan.
These devices are absolutely not suitable for being exposed to
internet traffic.

An aside ...

   Default credentials on the supermicros are ADMIN/ADMIN. On the
   ones I have seen recently, if you do not connect up the management
   network port, *BY DEFAULT THEY RUN MANAGEMENT ON THE FIRST _MAIN_
   NETWORK PORT* with the well known and simple password. (I mention
   this specifically as some readers may think IPMI is a risk and
   should be ignored - wrong - in this case it is a risk and must
   be handled, so better to describe a bit more :-)

To change the lan port, on mine, you need to connect to the controller
with the java crapware and there's an option to use the dedicated lan
port only. Why A) this isn't the default anyway, and B) you can't do
this and change the password from the bios setup screen, is a mystery.

... so, back to serial over lan.

You can redirect a serial port so instead of being routed to a physical
port on the motherboard, is routed to the IPMI BMC (controller), which
allows you to access it over the network. No physical serial port is
used. Apart from sidestepping the laggy keyboard problem on some
systems, this also lets you copy kernel messages in text form,
scrollback, etc.

Speaking for the X10 series (earlier ones and other vendor BIOSes
will be somewhat similar) you go to "super IO configuration", "serial
port 1 configuration" and set "serial port 2 attribute" [sic;
consistency is not a strong point!] to "SOL".

Then in "serial port console redirection" set COM2/SOL to "enabled"
and go to settings, set the speed (I would use 115200), and in X10*
there's a silly 100x31 console option that I disable. Make sure
"redirection after POST" is at least set to "boot loader" (on X10*
it's ok to use "always enable", on some other systems it must be
set to boot loader only). There's also a Windows EMS option which
I ignore. (doesn't apply to OP but for the benefit of anyone else
reading who didn't set up the IPMI BMC, configure network on that
too).

The above is enough to get BIOS screens and the boot loader showing up,
and you can check that in various ways. If you have a machine (Windows
etc) that can fully run the java extensions, you can access SOL over
the web interface or via IPMIView. If you have the standard open-source
ipmitool installed you can "ipmitool -I lanplus -H % -U ADMIN -P ADMIN
sol activate" (I run this from conserver to manage multi-user access
and to log output in case of kernel crashes). Or you can ssh to the
BMC - expect it to be slow to connect - and type "start /system1/sol1"
(this command is common to most BMCs). On mine you use [cr] [esc] T
to exit this mode (this sequence is likely to differ between BMCs).

(I can also "start /system1/pwrmgtsvc1" and "stop /system1/pwrmgtsvc1"
to turn the machine on/off - for some other vendors just "start /system1"
works, or maybe something else; dig around with show / cd / help.
Usually less hassle than the web interface)..

When you've confirmed you can see the BIOS screens you can try the
OpenBSD side - for a test just type "stty com1 115200" and "set tty
com1" at the boot loader prompt, and "boot", you should see boot
messages appear on the sol. You won't get a login prompt at the end yet.
If that works OK you can add "stty com1 115200" and "set tty com1" to
/etc/boot.conf and enable a getty (login prompt) on the port by editing
/etc/ttys (change tty01 to "std.115200" and "vt220 on secure").

Since OpenBSD doesn't have dual serial+tty consoles, you won't see much
on the monitor after rebooting with that in boot.conf - if you need to
skip this, hold ctrl down during boot (specifically, it needs to be
down at the point where the boot loader starts up), this tells the
boot loader not to load boot.conf.

Re: Keyboard through IPMI lag/skipping keys

[Stuart Henderson]

On 2014-10-13, Justin Winch  wrote:
> I have a very irritating problem with the keyboard lag through IPMI on a
> supermicro X9DRT.  If i install centos I do not have the lag/missed keystrokes
> and also I do not have this problem with any of my other hardware running
> openbsd.  Some keystrokes dont get logged others are logged twice.
>
> System-->
> http://www.supermicro.com/products/system/2U/6027/SYS-6027TR-DTRF.cfm
> dmesg -->
> http://img.photobucket.com/albums/v641/2muchricemakesmesick/dmesgmaster.png~o
> riginal
>
> Can someone please tell me how I can fix this?  It pretty much makes the
> system useless.
>
> Thanks in advance
>
>

Do you actually need keyboard?

I haven't tried it with X9 but I've just setup some X10 (A1SAi) with
serial-over-lan (console redirect on com1, redirect after POST -> boot
loader), it's much easier to work with than the java-plus-binary-module
rubbish.

As far as the OpenBSD side goes, if you 'stty com1 115200' and 'set tty com1'
in the boot loader when you install, the installer will prompt you to run
a console on that port automatically - otherwise if you've already installed,
you can add the stty/set lines to /etc/boot.conf and run a getty on tty01
in /etc/ttys.

Connect with "ipmitool -I lanplus -H hostname -U ADMIN -P ADMIN sol activate".

Private network on the management lan port of course, *never* expose crappy
BMC hardware to the internet! I run conserver on a host with a private network
to BMCs, which runs the above command to connect to the consoles, which logs
and manages access to them (and I recently added some config snippets for
this to the port in -current).

Re: Keyboard through IPMI lag/skipping keys

[Justin Winch]

Thanks for the reply.  I am actually on the latest version.  Like I said I do
not have this problem with windows or centos linux.


> Subject: Re: Keyboard through IPMI lag/skipping keys
> From: m...@alumni.chalmers.se
> Date: Mon, 13 Oct 2014 07:47:47 +0200
> CC: misc@openbsd.org
> To: flas...@hotmail.com
>
> Tried upgrade to a newer IPMI firmware?
>
>
> > On 13 okt 2014, at 02:11, Justin Winch  wrote:
> >
> > I have a very irritating problem with the keyboard lag through IPMI on a
> > supermicro X9DRT.  If i install centos I do not have the lag/missed
keystrokes
> > and also I do not have this problem with any of my other hardware running
> > openbsd.  Some keystrokes dont get logged others are logged twice.
> >
> > System-->
> > http://www.supermicro.com/products/system/2U/6027/SYS-6027TR-DTRF.cfm
> > dmesg -->
> >
http://img.photobucket.com/albums/v641/2muchricemakesmesick/dmesgmaster.png~o
> > riginal
> >
> > Can someone please tell me how I can fix this?  It pretty much makes the
> > system useless.
> >
> > Thanks in advance

Re: Keyboard through IPMI lag/skipping keys

[mxb]

Tried upgrade to a newer IPMI firmware?


> On 13 okt 2014, at 02:11, Justin Winch  wrote:
> 
> I have a very irritating problem with the keyboard lag through IPMI on a
> supermicro X9DRT.  If i install centos I do not have the lag/missed keystrokes
> and also I do not have this problem with any of my other hardware running
> openbsd.  Some keystrokes dont get logged others are logged twice.
> 
> System-->
> http://www.supermicro.com/products/system/2U/6027/SYS-6027TR-DTRF.cfm
> dmesg -->
> http://img.photobucket.com/albums/v641/2muchricemakesmesick/dmesgmaster.png~o
> riginal
> 
> Can someone please tell me how I can fix this?  It pretty much makes the
> system useless.
> 
> Thanks in advance

Keyboard through IPMI lag/skipping keys

[Justin Winch]

I have a very irritating problem with the keyboard lag through IPMI on a
supermicro X9DRT.  If i install centos I do not have the lag/missed keystrokes
and also I do not have this problem with any of my other hardware running
openbsd.  Some keystrokes dont get logged others are logged twice.

System-->
http://www.supermicro.com/products/system/2U/6027/SYS-6027TR-DTRF.cfm
dmesg -->
http://img.photobucket.com/albums/v641/2muchricemakesmesick/dmesgmaster.png~o
riginal

Can someone please tell me how I can fix this?  It pretty much makes the
system useless.

Thanks in advance

Re: IPMI SOL serial console wedges

[Paul B. Henson]

On Mon, Nov 25, 2013 at 12:09:33PM +, Stuart Henderson wrote:

> > How come freebsd dynamically detects the correct irq, but openbsd has it 
> > hardcoded?
> 
> linux and freebsd kernels use acpi to configure isa serial ports, openbsd
> uses static allocations.

Ah, ok; now that I know what's going on it's easy enough to fix, but it
was kinda confusing until I figured out the OS's that were working were
using a different interrupt.

> if you're wondering about the behaviour where you get the kernel
> messages, and it only stalls later, it just isn't looking at interrupts
> from the com port until that point.

Hmm, I saw kernel messages even after it stalled. All the initial kernel
messages were printed, then the first 16 chars from userspace, then
nothing else from userspace, but if I did something that resulted in kernel
messages (for example, plugging/unplugging the virtual usb cd) those
messages still came. 

> when enough chars have been sent to fill the buffer, we wait for an
> interrupt to say that it's ok to transmit again, but in your case,
> it's looking for the interrupt on the wrong pin so that interrupt
> it won't be seen.

Just userspace uses the interrupt? The kernel just pushes out characters
without waiting for a confirmation the fifo cleared?

Thanks much for the explanation...

Re: IPMI SOL serial console wedges

[Stuart Henderson]

On 2013-11-24, Paul B. Henson  wrote:
> erase ^?, werase
  1234567890123456

16 chars, because of the 16 byte buffer in the uart.

> com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
 ^^
when enough chars have been sent to fill the buffer, we wait for an
interrupt to say that it's ok to transmit again, but in your case,
it's looking for the interrupt on the wrong pin so that interrupt
it won't be seen.

Re: IPMI SOL serial console wedges

[Stuart Henderson]

On 2013-11-24, Paul B. Henson  wrote:
> Back on topic to my actual problem, it looks like the IPMI SOL com2 is 
> actually using IRQ 10 rather than 5, which both linux and freebsd detect:
>
> [2.324044] 00:0e: ttyS2 at I/O 0x3e8 (irq = 10) is a 16550A
> uart2: <16550 or compatible> port 0x3.8-0x3ef irq 10 on acpi0

> How come freebsd dynamically detects the correct irq, but openbsd has it 
> hardcoded?

linux and freebsd kernels use acpi to configure isa serial ports, openbsd
uses static allocations.

if you're wondering about the behaviour where you get the kernel
messages, and it only stalls later, it just isn't looking at interrupts
from the com port until that point.

Re: IPMI SOL serial console wedges

[Paul B. Henson]

On Sun, Nov 24, 2013 at 04:10:23PM -0800, Paul B. Henson wrote:
>
> I suppose the installer kernel could be fixed the same way, but at least
> for this initial install it's not worth it, I'll just install with the
> kvm head, fix the installed kernel, and then go serial from there. 

Actually, it turned out to be pretty easy to fix the installer. The BIOS
redirection works for the initial bootloader, so you can use that to
switch the bootloader to use com2, then just boot '-c' to pop up the
inkernel editor to fix the irq, and then it all works from there...
Sweet..

Re: IPMI SOL serial console wedges

[Paul B. Henson]

On Sun, Nov 24, 2013 at 12:16:52AM -0800, Paul B. Henson wrote:

> com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
> com2: console
> [...]
> root on rd0a swap on rd0b dump on rd0b
> erase ^?, werase
> 
> Every time, it wedges up at this spot. The console still works for
> kernel messages though, if I unplug the ipmi virtual cd, I see that:
[...] 
> It looks like as soon as userspace touches the console, it freezes up.

Well, it turns out the IPMI SOL com2 uses irq 10 for whatever reason
rather than irq 5. Both linux and freebsd successfully detect this:

[2.324044] 00:0e: ttyS2 at I/O 0x3e8 (irq = 10) is a 16550A
uart2: <16550 or compatible> port 0x3.8-0x3ef irq 10 on acpi0

However, openbsd tries to use irq 5, which doesn't turn out so well. I'm
guessing the kernel doesn't use the irq, which is why those messages
still work, but userspace craps out when it tries to use the wrong irq.

I tweaked the kernel with config -e to change the irq for com2 to 10,
and it now works fine:

com2 at isa0 port 0x3e8/8 irq 10: ns16550a, 16 byte fifo
com2: console
[...]
root on sd2a (b158108c15640a28.a) swap on sd2b dump on sd2b
Automatic boot in progress: starting file system checks.
setting tty flags
pf enabled

I suppose the installer kernel could be fixed the same way, but at least
for this initial install it's not worth it, I'll just install with the
kvm head, fix the installed kernel, and then go serial from there.

Is there any particular reason openbsd can't dynamically detect the irq?

Re: IPMI SOL serial console wedges

[Paul B. Henson]

On 11/24/2013 2:00 PM, Theo de Raadt wrote:


Well, I can't say it's the greatest implementation ever, but arguably it
doesn't seem much worse than on my Sun or IBM servers.

[...]

You just cannot compare this to what Sun did, by (almost always) using
a seperate ethernet port. Probably still crap, but at least there was
some attempt to provide isolation.


Actually, my supermicro boxes have a separate dedicated IPMI ethernet 
port. Only some, not all, supermicro boards use that stupid bridged 
design that shares a single port for both the primary system ethernet 
and IPMI ethernet.



Is it still "arguably" fine?


What exactly are we arguing about again? My specific statement was not 
that IPMI was "fine", nor even that it wasn't a piece of Swiss cheese; 
it was that the supermicro implementation is arguably not worse than 
other manufacturers. Of the articles referenced, the majority of the 
problems mentioned are in the base IPMI spec, while there were a couple 
of issues specific to supermicro, for the most part all vendors of IPMI 
hardware have the same underlying issues, and I'm sure other vendors 
have their own specific problems as well.


If you want to argue that overall IPMI is a sucky specification, and 
vendors in general have done a crap job of implementing it, you'll have 
to find somebody else to argue with, because I don't disagree with you. 
If you want to argue that supermicro in specific has done to a 
significant extent a crappier job, well, I think you need a bit more 
evidence.



The exact same IPMI SOL works fine under linux and illumos, so it
doesn't necessarily seem an underlying fault in the implementation. I
guess I could try booting freebsd on it and see if that works.


"works fine"


Yes, the IPMI SOL "works fine". You can configure it to be a serial 
console, and the OS boots and functions correctly and successfully. 
Whether or not IPMI as a platform is a good idea or a secure 
implementation is really orthogonal to whether or not an OS can use a 
serial port.


Back on topic to my actual problem, it looks like the IPMI SOL com2 is 
actually using IRQ 10 rather than 5, which both linux and freebsd detect:


[2.324044] 00:0e: ttyS2 at I/O 0x3e8 (irq = 10) is a 16550A
uart2: <16550 or compatible> port 0x3.8-0x3ef irq 10 on acpi0

I assume even if this were a physical serial port it would have the same 
problem, again nothing to do with IPMI. I'm going to try installing off 
the vga head again, and then tweaking the kernel to use irq 10 for com2 
rather than 5, and hopefully that will let me use the port as the serial 
console for the installed OS. If that works, presumably the installer 
could be fixed to work too, but that's probably more trouble than it's 
worth.


How come freebsd dynamically detects the correct irq, but openbsd has it 
hardcoded?



Similar issues exist on Dell BMC, documented elsewhere, you just need
to search.


Yep, IPMI kinda sucks. Not just on supermicro.


In fact it is unlikely that there are PC server-class
machines that have a safe primary ethernet port.  It is possible they
all have such problems built in ("oops").


Are you talking about systems where the bmc shares a physical port with 
the OS? That's not what I have.



It is really amazing that so many people prefer to remain blissfully
unaware.


Of what? Potential issues with IPMI? No unawareness here… My boxes all 
have separate dedicated IPMI ports, all segregated onto a private 
network that sees no public traffic. Is it perfect? No. From a risk 
management/cost effectiveness assessment perspective for my specific 
deployment, is it better than not using it? Yes...

Re: IPMI SOL serial console wedges

[Theo de Raadt]

> > Supermicro IPMI is crap. Use normal serial console and add a power strip
> > which you can manage via ethernet to poweroff/power cycle the server.
> 
> Well, I can't say it's the greatest implementation ever, but arguably it
> doesn't seem much worse than on my Sun or IBM servers.

http://news.softpedia.com/news/Rapid7-Researchers-Discover-Vulnerabilities-in-Supermicro-IPMI-Firmware-398010.shtml
http://www.darkreading.com/management/new-gaping-security-holes-found-exposing/240157724

[and many many more articles, if you just dug instead of saying "arguably"]

My favorite part is that on some Supermicro machines you have an
option to turn it off, but it actually doesn't turn off.  Just
awesome!  We can come up with plausible reasons why that is so,
because we read the news.  Must be interesting where those machines
end up.

You just cannot compare this to what Sun did, by (almost always) using
a seperate ethernet port.  Probably still crap, but at least there was
some attempt to provide isolation.  At least you can build your own
isolation in some way, if you feel compelled to use it.  Must be great
when people throw a full rack of those machines into a seperate vlan,
and one vulnerable machine can screw the others, though.  Lessons are
just never learned.

Is it still "arguably" fine?

> The exact same IPMI SOL works fine under linux and illumos, so it
> doesn't necessarily seem an underlying fault in the implementation. I
> guess I could try booting freebsd on it and see if that works.

"works fine"

> If I used a regular serial console, I'd need a terminal server to access
> it remotely, I'd rather just get this working and avoid the extra parts.

"avoid the extra parts" versus "avoid the holes".

Similar issues exist on Dell BMC, documented elsewhere, you just need
to search.  In fact it is unlikely that there are PC server-class
machines that have a safe primary ethernet port.  It is possible they
all have such problems built in ("oops").

It is really amazing that so many people prefer to remain blissfully
unaware.

Yummy, "ASF" driver injection/sniffing, IPMI buffer overflows, BMC
cpus without MMUs, SMI, SMIBIOS, shared I2C bus access

Re: IPMI SOL serial console wedges

[Paul B. Henson]

On Sun, Nov 24, 2013 at 04:13:27PM -0500, Jiri B wrote:

> Supermicro IPMI is crap. Use normal serial console and add a power strip
> which you can manage via ethernet to poweroff/power cycle the server.

Well, I can't say it's the greatest implementation ever, but arguably it
doesn't seem much worse than on my Sun or IBM servers.

The exact same IPMI SOL works fine under linux and illumos, so it
doesn't necessarily seem an underlying fault in the implementation. I
guess I could try booting freebsd on it and see if that works.

If I used a regular serial console, I'd need a terminal server to access
it remotely, I'd rather just get this working and avoid the extra parts.

I see com2 was actually disabled by default until recently, were there
historically problems using com2 under openbsd? Does anybody have a
serial console working on a physical com2 port? Maybe it's not the SOL
at all but just being com2 that's causing the problem. Unfortunately
there doesn't seem to be any way to make the SOL port use a different
ioport/irq :(.

Re: IPMI SOL serial console wedges

[Jiri B]

On Sun, Nov 24, 2013 at 12:40:31PM -0800, Paul B. Henson wrote:
> On Sun, Nov 24, 2013 at 09:54:41AM +0100, Sebastian Benoit wrote:
> 
> > in the bios, you can set the onboard serial ports irq to some higher value.
> > that way, the ipmi console will become com0.
> > 
> > (not tried on that board, only on newer supermicros that dont have the
> > serial port on the outside anymore).
> 
> Hmm, no joy. I tried disabling both the physical serial ports, but the
> SOL port stayed on the com2 ioport/irq. That completely broke the
> bootloader, as it showed only com0, and when I told it to use it
> presumably it tried the standard com0 ioport/irq. I tried setting the
> bios to use the com1 ioport/irq for com0 and the com2 for com1 in the
> hopes the SOL port would notice their was a conflict and use something
> else, but nope, it still didn't work. I don't see anyway to set the SOL
> port ioport/irq, I fear it's hardcoded.
> 
> It's weird that the kernel uses com2 as a console fine but then userland
> borks it. The SOL port works fine as a console when I boot linux on the
> box, so either there's an openbsd bug with it or linux must be
> implementing some workaround for a problem.
> 
> Thanks anyway...

Supermicro IPMI is crap. Use normal serial console and add a power strip
which you can manage via ethernet to poweroff/power cycle the server.

jirib

Re: IPMI SOL serial console wedges

[Paul B. Henson]

On Sun, Nov 24, 2013 at 09:54:41AM +0100, Sebastian Benoit wrote:

> in the bios, you can set the onboard serial ports irq to some higher value.
> that way, the ipmi console will become com0.
> 
> (not tried on that board, only on newer supermicros that dont have the
> serial port on the outside anymore).

Hmm, no joy. I tried disabling both the physical serial ports, but the
SOL port stayed on the com2 ioport/irq. That completely broke the
bootloader, as it showed only com0, and when I told it to use it
presumably it tried the standard com0 ioport/irq. I tried setting the
bios to use the com1 ioport/irq for com0 and the com2 for com1 in the
hopes the SOL port would notice their was a conflict and use something
else, but nope, it still didn't work. I don't see anyway to set the SOL
port ioport/irq, I fear it's hardcoded.

It's weird that the kernel uses com2 as a console fine but then userland
borks it. The SOL port works fine as a console when I boot linux on the
box, so either there's an openbsd bug with it or linux must be
implementing some workaround for a problem.

Thanks anyway...


> Paul B. Henson(hen...@acm.org) on 2013.11.24 00:16:52 -0800:
> > I've got a supermicro X9SCL-F board with ipmi support, and I'm trying to
> > use it for the serial console. It shows up as a third com port. After
> > booting the latest install cd, I run the usual "stty com2 115200" and
> > "set tty com2", and then boot. The kernel messages show up fine, and
> > then the output just stops:
> > 
> > com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
> > com2: console
> > [...]
> > root on rd0a swap on rd0b dump on rd0b
> > erase ^?, werase
> > 
> > Every time, it wedges up at this spot. The console still works for
> > kernel messages though, if I unplug the ipmi virtual cd, I see that:
> > 
> > erase ^?, werasesd2 detached
> > scsibus1 detached
> > umass0 detached
> > 
> > I tried installing it via the kvm head and configuring the serial
> > console for the installed OS, same problem, it spews all the kernel
> > messages and then:
> > 
> > com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
> > com2: console
> > [...]
> > root on sd2a (b158108c15640a28.a) swap on sd2b dump on sd2b
> > Automatic boot i
> > 
> > Wedges up. Again, the kernel still works, if I plug in the virtual cd:
> > 
> > utomatic boot iumass0 at uhub2 port 1 configuration 1 interface 0 "Ours
> > Technology product 0x" rev 2.00/2.00 addr 4
> > umass0: using SCSI over Bulk-Only
> > scsibus3 at umass0: 2 targets, initiator 0
> > 
> > I see the messages. Interesting, the box ends up starting the network
> > and lets me log in via ssh, and when I do, there are *no* getty
> > processes at all. And if I try to reboot from the ssh login, ssh stops
> > responding, but it never reboots and I have to hard reset it.
> > 
> > It looks like as soon as userspace touches the console, it freezes up.
> > Nothing from userspace ever gets printed, and I can't type anything on
> > it. But kernel messages still show up.
> > 
> > The BIOS has the option to either enable or disable legacy redirection
> > after POST, I've tried it both ways with no difference. I can boot linux
> > and use the ipmi serial console just fine, seeing both the kernel output
> > and userspace output, getting a login prompt, and interacting with no
> > issues, so the underlying SOL is functional.
> > 
> > Any ideas what's going on or what I could try to fix or debug it?
> > 
> > Thanks much...
> > 
> 
> -- 

IPMI SOL serial console wedges

[Paul B. Henson]

I've got a supermicro X9SCL-F board with ipmi support, and I'm trying to
use it for the serial console. It shows up as a third com port. After
booting the latest install cd, I run the usual "stty com2 115200" and
"set tty com2", and then boot. The kernel messages show up fine, and
then the output just stops:

com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
com2: console
[...]
root on rd0a swap on rd0b dump on rd0b
erase ^?, werase

Every time, it wedges up at this spot. The console still works for
kernel messages though, if I unplug the ipmi virtual cd, I see that:

erase ^?, werasesd2 detached
scsibus1 detached
umass0 detached

I tried installing it via the kvm head and configuring the serial
console for the installed OS, same problem, it spews all the kernel
messages and then:

com2 at isa0 port 0x3e8/8 irq 5: ns16550a, 16 byte fifo
com2: console
[...]
root on sd2a (b158108c15640a28.a) swap on sd2b dump on sd2b
Automatic boot i

Wedges up. Again, the kernel still works, if I plug in the virtual cd:

utomatic boot iumass0 at uhub2 port 1 configuration 1 interface 0 "Ours
Technology product 0x" rev 2.00/2.00 addr 4
umass0: using SCSI over Bulk-Only
scsibus3 at umass0: 2 targets, initiator 0

I see the messages. Interesting, the box ends up starting the network
and lets me log in via ssh, and when I do, there are *no* getty
processes at all. And if I try to reboot from the ssh login, ssh stops
responding, but it never reboots and I have to hard reset it.

It looks like as soon as userspace touches the console, it freezes up.
Nothing from userspace ever gets printed, and I can't type anything on
it. But kernel messages still show up.

The BIOS has the option to either enable or disable legacy redirection
after POST, I've tried it both ways with no difference. I can boot linux
and use the ipmi serial console just fine, seeing both the kernel output
and userspace output, getting a login prompt, and interacting with no
issues, so the underlying SOL is functional.

Any ideas what's going on or what I could try to fix or debug it?

Thanks much...

ipmi(4) and acpi(4) - ACPI IPMI Operation Region

[Alexey E. Suslikov]

hi there.

i saw there was (again) question about ipmi(4) being
disabled while acpi(4) is running.

fyi, there is a new thingy which allows IPMI run on top
of ACPI - ACPI IPMI Operation Region.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff543825%28v=vs.85%29.aspx

http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf

per MS article, it is relatively new (only available
on Win7 and up).

not sure about motherboard firmwares support, but spec
itself is definitely there, waiting for someone to
implement it ;)

so it's at least theoretically possible to have ipmi(4)
either at apic(4), or at mainbus(4).

cheers,
alexey

Re: Advice on adding com2 to (amd64) GENERIC; enabling easier IPMI SOL with SuperMicro boards

[Rogier Krieger]

On Sat, Apr 6, 2013 at 1:35 AM, Ted Unangst  wrote:
> I guess you missed the subsequent put back yesterday. :)

Guilty as charged.


> [...] com2 renumbers any other pci attached com ports from the likes of
puc.

I suppose for those running tools such as conserver, this would mean
changing the config lines that carry the 'baseport' values. In case it's
helpful, I've added the following snippet for faq/current.html to warn
unsuspecting serial users.

Regards,

Rogier



Index: current.html
===
RCS file: /cvs/www/faq/current.html,v
retrieving revision 1.373
diff -u -r1.373 current.html
--- current.html 28 Mar 2013 21:49:08 - 1.373
+++ current.html 6 Apr 2013 09:01:26 -
@@ -54,6 +54,7 @@
 2013/03/10 - fontconfig update
 2013/03/11 - pf translation counter added
 2013/03/25 - Perl update
+2013/04/05 - amd64 adds com2 and com3 to
GENERIC

 
 
@@ -562,6 +563,15 @@
 of this being committed and rely on such packages, you might like to wait
 for updated packages to become available to save the trouble of building
 them yourself.
+
+
+
+2013/04/05 - amd64 adds com2 and com3 to GENERIC
+OpenBSD/amd64 GENERIC and GENERIC.MP kernels now include the com2 (COM3)
+and com3 (disabled by default) devices that were commented out before. This
+may cause the renumbering of serial ports on other devices such as puc(4).
+Users of the conserver port may want to use the 'portbase' and
'devicesubst'
+settings to easily adjust their configuration.

 
 

Re: Advice on adding com2 to (amd64) GENERIC; enabling easier IPMI SOL with SuperMicro boards

[Ted Unangst]

On Sat, Apr 06, 2013 at 01:16, Rogier Krieger wrote:
> Out of curiosity, after seeing the commit and subsequent backing out of
> this change, what'd be the expected issues with enabling com2 that require
> more thought?

I guess you missed the subsequent put back yesterday. :)

The main issue was that adding com2 renumbers any other pci attached com ports
from the likes of puc. In the end, we decided that wasn't such a big deal and
even com3 was added (in a disabled state, because the ioport issue is somewhat
complicated).

Re: Advice on adding com2 to (amd64) GENERIC; enabling easier IPMI SOL with SuperMicro boards

[Rogier Krieger]

Out of curiosity, after seeing the commit and subsequent backing out of
this change, what'd be the expected issues with enabling com2 that require
more thought?

Regards,

Rogier




On Sat, Mar 30, 2013 at 8:01 AM, Ted Unangst  wrote:

> On Sat, Mar 30, 2013 at 02:06, Rogier Krieger wrote:
>
> > The GENERIC kernel config has commented out com2 (at isa0, addr 0x3e8,
> > irq 5) and I assume this is not without reason. I've been unable to
> > find that reason in source changes, but perhaps someone here knows. On
> > i386, it is present.
>
> I am guessing this is an oversight. i386 runs on the same machines, so
> if com2 were causing trouble it would be disabled there too.
>



-- 
If you don't know where you're going, any road will get you there.

Re: Advice on adding com2 to (amd64) GENERIC; enabling easier IPMI SOL with SuperMicro boards

[Ted Unangst]

On Sat, Mar 30, 2013 at 02:06, Rogier Krieger wrote:

> The GENERIC kernel config has commented out com2 (at isa0, addr 0x3e8,
> irq 5) and I assume this is not without reason. I've been unable to
> find that reason in source changes, but perhaps someone here knows. On
> i386, it is present.

I am guessing this is an oversight. i386 runs on the same machines, so
if com2 were causing trouble it would be disabled there too.

Advice on adding com2 to (amd64) GENERIC; enabling easier IPMI SOL with SuperMicro boards

[Rogier Krieger]

Dear list,

in an attempt to save on serial cabling for our machines, I'm trying
to see if IPMI Serial over Lan (SOL) works as advertised.

For our Dell boxes, things seem to work, but our SuperMicro boards
(X7SPA-HF and X8ST3-F) require extra work. The latter seem to insist
on using com2 (i.e. COM3 in BIOS), which isn't present by default in
GENERIC[.MP]. Obviously, adding this creates a bit of hassle and the
risk of the com2 device being unavailable should I ever forget to add
it back after upgrades.

The GENERIC kernel config has commented out com2 (at isa0, addr 0x3e8,
irq 5) and I assume this is not without reason. I've been unable to
find that reason in source changes, but perhaps someone here knows. On
i386, it is present.

In summary, would the following be acceptable?

Regards,

Rogier


Index: GENERIC
===
RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
retrieving revision 1.338
diff -u -r1.338 GENERIC
--- GENERIC 15 Mar 2013 09:10:52 -  1.338
+++ GENERIC 30 Mar 2013 01:04:54 -
@@ -315,7 +315,7 @@

 com0   at isa? port 0x3f8 irq 4# standard PC serial ports
 com1   at isa? port 0x2f8 irq 3
-#com2  at isa? port 0x3e8 irq 5
+com2   at isa? port 0x3e8 irq 5
 #com3  at isa? port 0x2e8 irq 9# (conflicts with some video cards)

 com*   at pcmcia?  # PCMCIA modems/serial ports

IPMI local access

[Manuel Guesdon]

Hi,

I've seen BMC local access seems impossible:
  http://www.mail-archive.com/misc@openbsd.org/msg93376.html
Is it really impossible or did I missed some point ?
Is there a reason for not implementing a local driver
as /usr/src/sys/dev/ipmi.c seems to contain all the code needed to interact
with bmc ?


Manuel 

--
__
Manuel Guesdon - OXYMIUM

Re: using ipmi locally under openbsd

[Imre Oolberg]

Hi!

Thanks for the quick and clear relpy! Actually it isn't a problem, i
could just boot this computer once up with some other os and configure
appropriate settings into ipmi and use it from there again with OpenBSD,
i just wanted to be sure that i didnt miss something obvious. Thanks again!


Imre

Stuart Henderson wrote:
> ipmi(4) doesn't support the interface needed for local access
> with ipmitool/freeipmi etc.
>
>
> On 2010-07-19, Imre Oolberg  wrote:
>   
>> Hallo!
>>
>> First of all, I am not a seasoned ipmi user, i rather resently found out
>> about this possibility to control computers. I would like to ask how to
>> use ipmitool to control local computer's ipmi facilities from within
>> OpenBSD. This computer is IBM System x3550 M2 and here is where i stand
>>
>> 1. i searched archives and found that in the first place ipmi should be
>> enabled in kernel, so i did
>>
>> ukc> enable ipmi
>>
>> and it says in dmesg
>>
>> ipmi0 at mainbus0: version 2.0 interface KCS iobase 0xca2/2 spacing 1
>> ...
>> iic0: skipping sensors to avoid ipmi0 interactions
>>
>> and obviously thanks to this change appeared into sysctl lot of entries
>> like this
>>
>> # sysctl hw.sensors.ipmi0
>> hw.sensors.ipmi0.temp0=22.00 degC (Ambient Temp), OK
>> hw.sensors.ipmi0.fan0=4081 RPM (Fan 1A Tach), OK
>> hw.sensors.ipmi0.fan1=2784 RPM (Fan 1B Tach), OK
>> hw.sensors.ipmi0.fan2=4081 RPM (Fan 2A Tach), OK
>> hw.sensors.ipmi0.fan3=2880 RPM (Fan 2B Tach), OK
>> ..
>> hw.sensors.ipmi0.indicator0=On (Power Supply 1), OK
>> hw.sensors.ipmi0.indicator1=On (Power Supply 2), OK
>>
>> 2. then i installed from ports ipmitool since binary packaged didnt have
>> open interface enabled
>>
>> 3. when i run ipmitool i get message about missing device
>>
>> # ipmitool mc info  
>> Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No
>> such file or directory
>> Get Device ID command failed
>>
>> I guess that the computer's ipmi system in itself is working all right,
>> at the moment in its default configuration, since in addition to the
>> above mentioned sysctl values i can also issue from another computer for
>> example
>>
>> # ipmitool -I lanplus -H 10.0.25.138 -U USERID -P xxx mc info
>>
>> and in return i get an answer as expected.
>>
>> If somebody could suggest how to proceed to make ipmitool locally work,
>> i would be very interested!
>>
>>
>> Best regards,
>>
>> Imre
>>
>> PS I also tried freeipmi binary package, it says
>>
>> # bmc-config
>> --checkout   
>>   
>>
>> ipmi_open_inband: driver path required

Re: using ipmi locally under openbsd

[Stuart Henderson]

ipmi(4) doesn't support the interface needed for local access
with ipmitool/freeipmi etc.


On 2010-07-19, Imre Oolberg  wrote:
> Hallo!
>
> First of all, I am not a seasoned ipmi user, i rather resently found out
> about this possibility to control computers. I would like to ask how to
> use ipmitool to control local computer's ipmi facilities from within
> OpenBSD. This computer is IBM System x3550 M2 and here is where i stand
>
> 1. i searched archives and found that in the first place ipmi should be
> enabled in kernel, so i did
>
> ukc> enable ipmi
>
> and it says in dmesg
>
> ipmi0 at mainbus0: version 2.0 interface KCS iobase 0xca2/2 spacing 1
> ...
> iic0: skipping sensors to avoid ipmi0 interactions
>
> and obviously thanks to this change appeared into sysctl lot of entries
> like this
>
> # sysctl hw.sensors.ipmi0
> hw.sensors.ipmi0.temp0=22.00 degC (Ambient Temp), OK
> hw.sensors.ipmi0.fan0=4081 RPM (Fan 1A Tach), OK
> hw.sensors.ipmi0.fan1=2784 RPM (Fan 1B Tach), OK
> hw.sensors.ipmi0.fan2=4081 RPM (Fan 2A Tach), OK
> hw.sensors.ipmi0.fan3=2880 RPM (Fan 2B Tach), OK
> ..
> hw.sensors.ipmi0.indicator0=On (Power Supply 1), OK
> hw.sensors.ipmi0.indicator1=On (Power Supply 2), OK
>
> 2. then i installed from ports ipmitool since binary packaged didnt have
> open interface enabled
>
> 3. when i run ipmitool i get message about missing device
>
> # ipmitool mc info  
> Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No
> such file or directory
> Get Device ID command failed
>
> I guess that the computer's ipmi system in itself is working all right,
> at the moment in its default configuration, since in addition to the
> above mentioned sysctl values i can also issue from another computer for
> example
>
> # ipmitool -I lanplus -H 10.0.25.138 -U USERID -P xxx mc info
>
> and in return i get an answer as expected.
>
> If somebody could suggest how to proceed to make ipmitool locally work,
> i would be very interested!
>
>
> Best regards,
>
> Imre
>
> PS I also tried freeipmi binary package, it says
>
> # bmc-config
> --checkout
>  
>
> ipmi_open_inband: driver path required

using ipmi locally under openbsd

[Imre Oolberg]

Hallo!

First of all, I am not a seasoned ipmi user, i rather resently found out
about this possibility to control computers. I would like to ask how to
use ipmitool to control local computer's ipmi facilities from within
OpenBSD. This computer is IBM System x3550 M2 and here is where i stand

1. i searched archives and found that in the first place ipmi should be
enabled in kernel, so i did

ukc> enable ipmi

and it says in dmesg

ipmi0 at mainbus0: version 2.0 interface KCS iobase 0xca2/2 spacing 1
...
iic0: skipping sensors to avoid ipmi0 interactions

and obviously thanks to this change appeared into sysctl lot of entries
like this

# sysctl hw.sensors.ipmi0
hw.sensors.ipmi0.temp0=22.00 degC (Ambient Temp), OK
hw.sensors.ipmi0.fan0=4081 RPM (Fan 1A Tach), OK
hw.sensors.ipmi0.fan1=2784 RPM (Fan 1B Tach), OK
hw.sensors.ipmi0.fan2=4081 RPM (Fan 2A Tach), OK
hw.sensors.ipmi0.fan3=2880 RPM (Fan 2B Tach), OK
..
hw.sensors.ipmi0.indicator0=On (Power Supply 1), OK
hw.sensors.ipmi0.indicator1=On (Power Supply 2), OK

2. then i installed from ports ipmitool since binary packaged didnt have
open interface enabled

3. when i run ipmitool i get message about missing device

# ipmitool mc info  
Could not open device at /dev/ipmi0 or /dev/ipmi/0 or /dev/ipmidev/0: No
such file or directory
Get Device ID command failed

I guess that the computer's ipmi system in itself is working all right,
at the moment in its default configuration, since in addition to the
above mentioned sysctl values i can also issue from another computer for
example

# ipmitool -I lanplus -H 10.0.25.138 -U USERID -P xxx mc info

and in return i get an answer as expected.

If somebody could suggest how to proceed to make ipmitool locally work,
i would be very interested!


Best regards,

Imre

PS I also tried freeipmi binary package, it says

# bmc-config
--checkout  
   

ipmi_open_inband: driver path required

Is SOL redirection on OpenBSD IPMI kernel enable is possible with Winbond WPCM450 BMC?

[Daniel Ouellet]

Hi,

I have been digging a lots of reading in the last few days and I start 
to wonder if I am not running in a dead end.


I am testing the remote management capability. I got nice serial console 
access working very well based on the FAQ 7.6.


I also got the IMPI enable in kernel and get plenty of sensors reading.

I continue to play with the IPMI/BMC and got the packages "impitool" for 
my OpenBSD box and configure the access and all to that test box good.


I can even have a nice shell to the IMPI over TCP on that box too.

I can do changes for the TCP, do power cycle, reboot, monitoring, etc. 
Bunch of fun stuff. Get all the sensors over tcp good, or better yet on 
the local shell as well via the ipmitool package.


I try to read the IPMI 2.0 and 1.5 specs from Intel here:

http://www.intel.com/design/servers/ipmi/spec.htm

Pretty long stuff I must admit. Didn't read all for sure.

Various other documents there and look like SOL, ISOL, TSOL are all 
available on the shell to as well as over LAN, but pass that I hit a wall.


I know it does work for the box I am testing with as I get that remote 
console via their web access with java and all like Sun if you are 
familiar with that. It's cool, but I really like the CLI instead of the 
blotted java stuff.


What I am trying to do is to see if I can actually get console 
redirection, or serial redirection to that IPMI shell or not, or better 
yet to a remote connection, but I start to think that it may not be 
possible without a FULL iLOM like processor optional board may be? But 
with a local shell already and all, I would think it may be possible to 
do specially that the web interface to the IMPI/BCM allow all that I 
would need to do and more.


Reading all the specs and what ever I could put my hands on via google, 
I thought that it would be possible. But I am so close I can have the 
shell in impi using the impitool and issue the SOL activate command and 
looks like it may go do something, but then I just can't pass that.


I don't know what else I could read to get that going and start to think 
that may be it can't be done, or I haven't found the right info yet.


Anyone have a clue stick may be, or simply a NO answer so that I would 
stop pulling what ever hair I still have left?


Obviously I can't say how to connect the OpenBSD console to IPMI, like I 
can do the serial to the COM1 via the stty and tty, etc.


Based on the specs of IPMI I would think it should be possible.

But is it?

I would very much appreciate a pointer, may be a URL to some other good 
docs that I may have not find yet, or even a simple "no", that's not 
possible to do at all with may be some meat details as to why so that I 
understand would be great!


I just fell there is a very stupid thing I am not doing right, but I 
can't find it!


The specs of the box say clearly that KVM-over-LAN is supported, virtual 
media over LAN, witch I really don't care for, but may be nice to play 
with. If I ever need that, then may be at that time I would use the java 
stuff, but for most of the time, why go that far.


dmesg below if that's of any value.

The box is this one if that needed too.

http://www.supermicro.com/products/system/1U/5015/SYS-5015A-PHF.cfm

Thanks for your time.

Best,

Daniel

=
OpenBSD 4.7 (GENERIC.MP) #130: Wed Mar 17 20:48:50 MDT 2010
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 3219652608 (3070MB)
avail mem = 3126497280 (2981MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x9ac00 (19 entries)
bios0: vendor American Megatrends Inc. version "1.0b" date 01/19/2010
bios0: Supermicro X7SPA-HF
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET EINJ BERT ERST HEST
acpi0: wakeup devices P0P1(S4) PS2K(S4) PS2M(S4) USB0(S4) USB1(S4) 
USB2(S4) USB5(S4) EUSB(S4) USB3(S4) USB4(S4) USB6(S4) USBE(S4) P0P4(S4) 
P0P5(S4) P0P6(S4) P0P7(S4) P0P8(S4) P0P9(S4) GBE_(S4) SLPB(S4)

acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.89 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,CX16,xTPR,NXE,LONG

cpu0: 512KB 64b/line 8-way L2 cache
cpu0: apic clock running at 166MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.67 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,TM2,CX16,xTPR,NXE,LONG

cpu1: 512KB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Atom(TM) CPU D510 @ 1.66GHz, 1666.67 MHz
cpu2: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMO

Re: HP IPMI

[Stuart Henderson]

On 2009-12-17, Pete Vickers  wrote:
> Is the IPMI abstraction (mentioned in ipmi(4)) such that support for  
> additional devices is little more than adding PCI vendor/product id to  
> the attach code? or is a proprietary interface ?

You probably just have to enable the driver, I imagine it will attach
straight away. 'config -ef /bsd' and 'enable ipmi'.

HP IPMI

[Pete Vickers]

Hi,

I have a HP (Compaq) ProLiant DL380 G5 which, according to dmesg,  
incorporates IPMI.


# grep IPMI /var/run/dmesg.boot
"Hewlett-Packard IPMI" rev 0x00 at pci16 dev 4 function 6 not configured

# pcidump -v 1:4:6
Domain /dev/pci:
 1:4:6: Hewlett-Packard IPMI
0x: Vendor ID: 103c Product ID: 3302
0x0004: Command: 0002 Status ID: 0290
0x0008: Class: 0c Subclass: 07 Interface: 01 Revision: 00
0x000c: BIST: 00 Header Type: 80 Latency Timer: 00 Cache Line  
Size: 00

0x0010: BAR mem 32bit addr: 0xf7ef
0x0014: BAR empty ()
0x0018: BAR empty ()
0x001c: BAR empty ()
0x0020: BAR empty ()
0x0024: BAR empty ()
0x0028: Cardbus CIS: 
0x002c: Subsystem Vendor ID: 103c Product ID: 3305
0x0030: Expansion ROM Base Address: 
0x0038: 
0x003c: Interrupt Pin: 01 Line: 05 Min Gnt: 00 Max Lat: 00
0x00f0: Capability 0x01: Power Management


Is the IPMI abstraction (mentioned in ipmi(4)) such that support for  
additional devices is little more than adding PCI vendor/product id to  
the attach code? or is a proprietary interface ?


/Pete


# sysctl hw
hw.machine=i386
hw.model=Intel(R) Xeon(R) CPU E5440 @ 2.83GHz ("GenuineIntel" 686-class)
hw.ncpu=1
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=sd0,cd0
hw.diskcount=2
hw.sensors.acpitz0.temp0=8.30 degC (zone temperature)
hw.sensors.cpu0.temp0=38.00 degC
hw.sensors.ciss0.drive0=online (sd0), OK
hw.cpuspeed=2834
hw.vendor=HP
hw.product=ProLiant DL380 G5
hw.serialno=CZC8100BSS
hw.uuid=34353835-3633-435a-4338-313030425353
hw.physmem=3487485952
hw.usermem=3487473664

(entire dmesg already forwarded to dmesg@ )

Re: ipmi support on a Dell PowerEdge SC1425

[Remco]

Dave Wilson wrote:

> ... isn't working, at least not for me.
> 
> Google has found me this sample dmesg from 4.0:
>
http://www.armorlogic.com/openbsd_information_server_compatibility_list.html?action=detail&id=dsc1425
> 
> And this from Marco Peereboom announcing ipmi support:
> http://marc.info/?l=openbsd-misc&m=112993650617151&w=2
> 
> but under my amd64 install of 4.4 I get 'not configured'.
> 
> My current theory is that I've done something dumb.
> 
> Anyone care to tell me what it is?
> 
> Dave W

It's not enabled by default. (not sure why)

To try it you need to enable ipmi in the kernel.
Either by using the config option (-c) at the boot prompt and typing 'enable
ipmi' to try it out at that particular boot (see boot(8), boot_config(8)),
or by using config(8) to enable it persistently at every boot.

Re: ipmi support on a Dell PowerEdge SC1425

[Marco Peereboom]

It is disabled by default because some boxes have issues with it.  Read
config(8) and enable it in your kernel.

On Fri, Apr 17, 2009 at 01:20:21PM +0100, Dave Wilson wrote:
> ... isn't working, at least not for me.
> 
> Google has found me this sample dmesg from 4.0:
> http://www.armorlogic.com/openbsd_information_server_compatibility_list.html?action=detail&id=dsc1425
> 
> And this from Marco Peereboom announcing ipmi support:
> http://marc.info/?l=openbsd-misc&m=112993650617151&w=2
> 
> but under my amd64 install of 4.4 I get 'not configured'.
> 
> My current theory is that I've done something dumb.
> 
> Anyone care to tell me what it is?
> 
> Dave W
> 
> 
> 
> OpenBSD 4.4-stable (GENERIC) #0: Tue Jan 27 09:34:13 GMT 2009
> r...@constantine:/usr/src/sys/arch/amd64/compile/GENERIC
> real mem = 523399168 (499MB)
> avail mem = 507768832 (484MB)
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfa850 (75 entries)
> bios0: vendor Dell Computer Corporation version "A03" date 01/04/2006
> bios0: Dell Computer Corporation PowerEdge SC1425
> acpi0 at bios0: rev 0
> acpi0: tables DSDT FACP APIC SPCR HPET MCFG
> acpi0: wakeup devices PCI0(S5) PALO(S5) PXH_(S5) PXHB(S5) PXHA(S5) PICH(S5)
> acpitimer0 at acpi0: 3579545 Hz, 24 bits
> acpihpet0 at acpi0: 14318179 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpiprt1 at acpi0: bus 1 (PALO)
> acpiprt2 at acpi0: bus 3 (PXHB)
> acpiprt3 at acpi0: bus 2 (PXHA)
> acpiprt4 at acpi0: bus 4 (PICH)
> acpicpu0 at acpi0
> ipmi at mainbus0 not configured
> cpu0 at mainbus0: (uniprocessor)
> cpu0: Intel(R) Xeon(TM) CPU 3.20GHz, 3200.49 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,NXE,LONG
> cpu0: 2MB 64b/line 8-way L2 cache
> pci0 at mainbus0 bus 0: configuration mode 1
> pchb0 at pci0 dev 0 function 0 "Intel E7520 Host" rev 0x09
> ppb0 at pci0 dev 2 function 0 "Intel E7520 PCIE" rev 0x09
> pci1 at ppb0 bus 1
> ppb1 at pci1 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09
> pci2 at ppb1 bus 2
> em0 at pci2 dev 4 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq
> 15, address 00:15:c5:5d:a0:ba
> ppb2 at pci1 dev 0 function 2 "Intel PCIE-PCIE" rev 0x09
> pci3 at ppb2 bus 3
> uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: irq 15
> uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0x02: irq 14
> ehci0 at pci0 dev 29 function 7 "Intel 82801EB/ER USB2" rev 0x02: irq 11
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
> ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xc2
> pci4 at ppb3 bus 4
> em1 at pci4 dev 3 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq
> 6, address 00:15:c5:5d:a0:bb
> vga1 at pci4 dev 13 function 0 "ATI Radeon VE QY" rev 0x00
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> drm at vga1 unsupported
> pcib0 at pci0 dev 31 function 0 "Intel 82801EB/ER LPC" rev 0x02
> pciide0 at pci0 dev 31 function 1 "Intel 82801EB/ER IDE" rev 0x02: DMA,
> channel 0 configured to compatibility, channel 1 configured to compatibility
> pciide0: channel 0 ignored (disabled)
> pciide0: channel 1 ignored (disabled)
> pciide1 at pci0 dev 31 function 2 "Intel 82801EB SATA" rev 0x02: DMA,
> channel 0 configured to native-PCI, channel 1 configured to native-PCI
> pciide1: using irq 10 for native-PCI interrupt
> wd0 at pciide1 channel 0 drive 0: 
> wd0: 16-sector PIO, LBA48, 76293MB, 15625 sectors
> wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
> usb1 at uhci0: USB revision 1.0
> uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> usb2 at uhci1: USB revision 1.0
> uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
> isa0 at pcib0
> isadma0 at isa0
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> pckbc0 at isa0 port 0x60/5
> pckbd0 at pckbc0 (kbd slot)
> pckbc0: using irq 1 for kbd slot
> wskbd0 at pckbd0: console keyboard, using wsdisplay0
> pcppi0 at isa0 port 0x61
> midi0 at pcppi0: 
> spkr0 at pcppi0
> mtrr: Pentium Pro MTRR support
> uhidev0 at uhub2 port 2 configuration 1 interface 0 "CHICONY HP Basic
> USB Keyboard" rev 1.10/3.00 addr 2
> uhidev0: iclass 3/1
> ukbd0 at uhidev0: 8 modifier keys, 6 key codes
> wskbd1 at ukbd0 mux 1
> wskbd1: connecting to wsdisplay0
> softraid0 at root
> root on wd0a swap on wd0b dump on wd0b

ipmi support on a Dell PowerEdge SC1425

[Dave Wilson]

... isn't working, at least not for me.

Google has found me this sample dmesg from 4.0:
http://www.armorlogic.com/openbsd_information_server_compatibility_list.html?action=detail&id=dsc1425

And this from Marco Peereboom announcing ipmi support:
http://marc.info/?l=openbsd-misc&m=112993650617151&w=2

but under my amd64 install of 4.4 I get 'not configured'.

My current theory is that I've done something dumb.

Anyone care to tell me what it is?

Dave W



OpenBSD 4.4-stable (GENERIC) #0: Tue Jan 27 09:34:13 GMT 2009
r...@constantine:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 523399168 (499MB)
avail mem = 507768832 (484MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xfa850 (75 entries)
bios0: vendor Dell Computer Corporation version "A03" date 01/04/2006
bios0: Dell Computer Corporation PowerEdge SC1425
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP APIC SPCR HPET MCFG
acpi0: wakeup devices PCI0(S5) PALO(S5) PXH_(S5) PXHB(S5) PXHA(S5) PICH(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PALO)
acpiprt2 at acpi0: bus 3 (PXHB)
acpiprt3 at acpi0: bus 2 (PXHA)
acpiprt4 at acpi0: bus 4 (PICH)
acpicpu0 at acpi0
ipmi at mainbus0 not configured
cpu0 at mainbus0: (uniprocessor)
cpu0: Intel(R) Xeon(TM) CPU 3.20GHz, 3200.49 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,NXE,LONG
cpu0: 2MB 64b/line 8-way L2 cache
pci0 at mainbus0 bus 0: configuration mode 1
pchb0 at pci0 dev 0 function 0 "Intel E7520 Host" rev 0x09
ppb0 at pci0 dev 2 function 0 "Intel E7520 PCIE" rev 0x09
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09
pci2 at ppb1 bus 2
em0 at pci2 dev 4 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq
15, address 00:15:c5:5d:a0:ba
ppb2 at pci1 dev 0 function 2 "Intel PCIE-PCIE" rev 0x09
pci3 at ppb2 bus 3
uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: irq 15
uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0x02: irq 14
ehci0 at pci0 dev 29 function 7 "Intel 82801EB/ER USB2" rev 0x02: irq 11
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb3 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xc2
pci4 at ppb3 bus 4
em1 at pci4 dev 3 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq
6, address 00:15:c5:5d:a0:bb
vga1 at pci4 dev 13 function 0 "ATI Radeon VE QY" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
drm at vga1 unsupported
pcib0 at pci0 dev 31 function 0 "Intel 82801EB/ER LPC" rev 0x02
pciide0 at pci0 dev 31 function 1 "Intel 82801EB/ER IDE" rev 0x02: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 ignored (disabled)
pciide0: channel 1 ignored (disabled)
pciide1 at pci0 dev 31 function 2 "Intel 82801EB SATA" rev 0x02: DMA,
channel 0 configured to native-PCI, channel 1 configured to native-PCI
pciide1: using irq 10 for native-PCI interrupt
wd0 at pciide1 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 76293MB, 15625 sectors
wd0(pciide1:0:0): using PIO mode 4, Ultra-DMA mode 5
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1
usb2 at uhci1: USB revision 1.0
uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: 
spkr0 at pcppi0
mtrr: Pentium Pro MTRR support
uhidev0 at uhub2 port 2 configuration 1 interface 0 "CHICONY HP Basic
USB Keyboard" rev 1.10/3.00 addr 2
uhidev0: iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes
wskbd1 at ukbd0 mux 1
wskbd1: connecting to wsdisplay0
softraid0 at root
root on wd0a swap on wd0b dump on wd0b

Re: Dell R200 ipmi

[Jean-Gérard Pailloncy]

> The Dell Poweredge R200 has a ipmi board but
>> ipmi at mainbus0 not configured
>
> Is there some new stuff in current to support the ipmi on R200 ?
> especially the watchdog feature. Or patch waiting to be tested ?

Thank for the information. I enabled ipmi in the kernel with config.

A related question:
I have a R200 and a soekris.
On both box, I launch watchdogd.
On both the same output:
# sysctl kern.watchdog
kern.watchdog.period=30
kern.watchdog.auto=0

But if i do
# kill -STOP 
the soekris reboot and not the R200

On the R200, if I do
# sysctl -w kern.watchdog.auto=1
then
# kill -STOP 
then the R200 reboot too.

Any explanation ? Or is it a bug ?

JG

Re: Dell R200 ipmi

[Stuart Henderson]

On 2008-10-06, Jean-Girard Pailloncy <[EMAIL PROTECTED]> wrote:
> The Dell Poweredge R200 has a ipmi board but
>> ipmi at mainbus0 not configured
>
> Is there some new stuff in current to support the ipmi on R200 ?
> especially the watchdog feature. Or patch waiting to be tested ?

ipmi is compiled-in to GENERIC but marked as disabled, due to a
problem on some machines. You can try "boot -c" at the boot loader
and "enable ipmi" then, if it works, edit the on-disk kernel with
"config -e".

Dell R200 ipmi

[Jean-Gérard Pailloncy]

Hi,

The Dell Poweredge R200 has a ipmi board but
> ipmi at mainbus0 not configured

Is there some new stuff in current to support the ipmi on R200 ?
especially the watchdog feature. Or patch waiting to be tested ?

JG

Re: ipmi not working on poweredge 2850

[Jörg Streckfuß]

Am Mon, 14 Jul 2008 22:03:59 +0200
schrieb Ariane van der Steldt <[EMAIL PROTECTED]>:

> On Mon, Jul 14, 2008 at 05:09:10PM +0200, J??rg Streckfu?? wrote:
> > today i tried to read the esm log on a poweredge 2850 running OpenBSD 4.3
> > stable.
> >
> > In the past i could see much more output from the internal sensors than
only
> > the raid sensor
> >
> > 
> > [EMAIL PROTECTED] root # sysctl hw.sensors
> > hw.sensors.ami0.drive0=online (sd0), OK
> > 
> >
> > the dmesg says that impi is not configured. Is there a way to turn it on?
>
> Heh, I happen to have played alot with that recently :P
> You only have to turn it on in your kernel, using the config binary.
>
> config -e -f /bsd
> enable ipmi
> quit
>
> And you're all set (after a reboot).
>
> Ciao,
> Ariane

Thanks, that was excactly what i was searching for.

Regards,

Joerg

--
Dipl.-Ing. (FH) Joerg Streckfuss, Phone: +49 40 808077-631

DFN-CERT Services GmbH, https://www.dfn-cert.de/, Phone  +49 40 808077-555
Sitz / Register: Hamburg, AG Hamburg, HRB 88805,  Ust-IdNr.:  DE 232129737
SachsenstraCe 5, 20097 Hamburg/Germany, CEO: Dr. Klaus-Peter Kossakowski

[demime 1.01d removed an attachment of type application/pkcs7-signature which 
had a name of smime.p7s]

Re: ipmi not working on poweredge 2850

[Ariane van der Steldt]

On Mon, Jul 14, 2008 at 05:09:10PM +0200, J??rg Streckfu?? wrote:
> today i tried to read the esm log on a poweredge 2850 running OpenBSD 4.3
> stable.
> 
> In the past i could see much more output from the internal sensors than only
> the raid sensor
> 
> 
> [EMAIL PROTECTED] root # sysctl hw.sensors
> hw.sensors.ami0.drive0=online (sd0), OK
> 
> 
> the dmesg says that impi is not configured. Is there a way to turn it on?

Heh, I happen to have played alot with that recently :P
You only have to turn it on in your kernel, using the config binary.

config -e -f /bsd
enable ipmi
quit

And you're all set (after a reboot).

Ciao,
Ariane

ipmi not working on poweredge 2850

[Jörg Streckfuß]

Hi list,

today i tried to read the esm log on a poweredge 2850 running OpenBSD 4.3
stable.

In the past i could see much more output from the internal sensors than only
the raid sensor


[EMAIL PROTECTED] root # sysctl hw.sensors
hw.sensors.ami0.drive0=online (sd0), OK


the dmesg says that impi is not configured. Is there a way to turn it on?

Kind regards,

Joerg
dmesg:
OpenBSD 4.3 (GENERIC) #698: Wed Mar 12 11:07:05 MDT 2008
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Xeon(TM) CPU 3.00GHz ("GenuineIntel" 686-class) 3 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR
real mem  = 1073053696 (1023MB)
avail mem = 1029550080 (981MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 10/03/06, BIOS32 rev. 0 @ 0xffe90,
SMBIOS rev. 2.3 @ 0xf9920 (87 entries)
bios0: vendor Dell Computer Corporation version "A06" date 10/03/2006
bios0: Dell Computer Corporation PowerEdge 2850
acpi0 at bios0: rev 0
acpi0: tables DSDT FACP APIC SPCR HPET MCFG
acpi0: wakeup devices PCI0(S5) PALO(S5) PBLO(S5) VPR0(S5) PBHI(S5) VPR1(S5)
PICH(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PALO)
acpiprt2 at acpi0: bus 2 (DOBA)
acpiprt3 at acpi0: bus 3 (DOBB)
acpiprt4 at acpi0: bus 4 (PBLO)
acpiprt5 at acpi0: bus 5 (PBHI)
acpiprt6 at acpi0: bus 6 (PXB1)
acpiprt7 at acpi0: bus 7 (PXB2)
acpiprt8 at acpi0: bus 8 (VPR1)
acpiprt9 at acpi0: bus 9 (PXC1)
acpiprt10 at acpi0: bus 11 (PXC2)
acpiprt11 at acpi0: bus 14 (PICH)
acpicpu0 at acpi0
bios0: ROM list: 0xc/0xb000! 0xcb000/0x2200 0xec000/0x4000!
ipmi at mainbus0 not configured
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel E7520 Host" rev 0x09
ppb0 at pci0 dev 2 function 0 "Intel E7520 PCIE" rev 0x09
pci1 at ppb0 bus 1
ppb1 at pci1 dev 0 function 0 "Intel IOP332 PCIE-PCIX" rev 0x06
pci2 at ppb1 bus 2
ami0 at pci2 dev 14 function 0 "Dell PERC 4e/Di" rev 0x06: irq 7
ami0: Dell 16d, 32b, FW 522D, BIOS vH430, 256MB RAM
ami0: 2 channels, 0 FC loops, 1 logical drives
scsibus0 at ami0: 40 targets
sd0 at scsibus0 targ 0 lun 0:  SCSI2 0/direct fixed
sd0: 139900MB, 17834 cyl, 255 head, 63 sec, 512 bytes/sec, 286515200 sec
total
scsibus1 at ami0: 16 targets
safte0 at scsibus1 targ 6 lun 0:  SCSI2 3/processor
fixed
scsibus2 at ami0: 16 targets
ppb2 at pci1 dev 0 function 2 "Intel IOP332 PCIE-PCIX" rev 0x06
pci3 at ppb2 bus 3
ppb3 at pci0 dev 4 function 0 "Intel E7520 PCIE" rev 0x09
pci4 at ppb3 bus 4
ppb4 at pci0 dev 5 function 0 "Intel E7520 PCIE" rev 0x09
pci5 at ppb4 bus 5
ppb5 at pci5 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09
pci6 at ppb5 bus 6
em0 at pci6 dev 7 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq 11,
address 00:18:8b:30:f1:72
ppb6 at pci5 dev 0 function 2 "Intel PCIE-PCIE" rev 0x09
pci7 at ppb6 bus 7
em1 at pci7 dev 8 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: irq 3,
address 00:18:8b:30:f1:73
ppb7 at pci0 dev 6 function 0 "Intel E7520 PCIE" rev 0x09
pci8 at ppb7 bus 8
ppb8 at pci8 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09
pci9 at ppb8 bus 9
ppb9 at pci9 dev 4 function 0 "Intel S21152BB PCI-PCI" rev 0x00
pci10 at ppb9 bus 10
ste0 at pci10 dev 4 function 0 "D-Link Systems 550TX" rev 0x15: irq 7, address
00:0d:88:68:30:f4
ukphy0 at ste0 phy 1: Generic IEEE 802.3u media interface, rev. 0: OUI
0x0090c3, model 0x0004
ste1 at pci10 dev 5 function 0 "D-Link Systems 550TX" rev 0x15: irq 10,
address 00:0d:88:68:30:f5
ukphy1 at ste1 phy 1: Generic IEEE 802.3u media interface, rev. 0: OUI
0x0090c3, model 0x0004
ste2 at pci10 dev 6 function 0 "D-Link Systems 550TX" rev 0x15: irq 11,
address 00:0d:88:68:30:f6
ukphy2 at ste2 phy 1: Generic IEEE 802.3u media interface, rev. 0: OUI
0x0090c3, model 0x0004
ste3 at pci10 dev 7 function 0 "D-Link Systems 550TX" rev 0x15: irq 3, address
00:0d:88:68:30:f7
ukphy3 at ste3 phy 1: Generic IEEE 802.3u media interface, rev. 0: OUI
0x0090c3, model 0x0004
ppb10 at pci8 dev 0 function 2 "Intel PCIE-PCIE" rev 0x09
pci11 at ppb10 bus 11
ppb11 at pci11 dev 2 function 0 "Intel S21152BB PCI-PCI" rev 0x00
pci12 at ppb11 bus 12
ste4 at pci12 dev 4 function 0 "D-Link Systems 550TX" rev 0x15: irq 11,
address 00:0d:88:68:31:00
ukphy4 at ste4 phy 1: Generic IEEE 802.3u media interface, rev. 0: OUI
0x0090c3, model 0x0004
ste5 at pci12 dev 5 function 0 "D-Link Systems 550TX" rev 0x15: irq 3, address
00:0d:88:68:31:01
ukphy5 at ste5 phy 1: Generic IEEE 802.3u media interface, rev. 0: OUI
0x0090c3, model 0x0004
ste6 at pci12 dev 6 function 0 "D-Link Systems 550TX" rev 0x15: irq 7, address
00:0d:88:68:31:02
ukphy6 

Re: ilo (ipmi) and serial console redirection

[Steve Shockley]

Markus Hennecke wrote:
Doesn't the bootloader number the com ports from zero on? AFAIR I could 
set the bootloader on a DL 385 to use the ILO com port via setting up 
com1 in boot.conf. This is a few month since I did that and I have no 
physical access to that machine now, so I can't look at it further.


The DL1xx has a very different ILO than the other HP servers.  I don't 
have any of those, so I can't comment on the problem.

Re: ilo (ipmi) and serial console redirection

[Markus Hennecke]

On Fri, 30 Nov 2007, holger glaess wrote:


of cause , i try to setup com2 but the system says at bootpromt "com port is
not aviable" , but if the kernel
already loaded the com port is aviable.

there is no setting options at the bios to change the com port from the ipmi
board.


Doesn't the bootloader number the com ports from zero on? AFAIR I could 
set the bootloader on a DL 385 to use the ILO com port via setting up com1 
in boot.conf. This is a few month since I did that and I have no physical 
access to that machine now, so I can't look at it further.


Best Regards,
   Markus

Re: ilo (ipmi) and serial console redirection

[holger glaess]

hi

of cause , i try to setup com2 but the system says at bootpromt "com port is
not aviable" , but if the kernel
already loaded the com port is aviable.

there is no setting options at the bios to change the com port from the ipmi
board.

holger

-Urspr|ngliche Nachricht-
Von: "Stijn" <[EMAIL PROTECTED]>
Gesendet: 29.11.07 22:40:22
An: holger glaess <[EMAIL PROTECTED]>
Betreff: Re: ilo (ipmi) and serial console redirection


Hi,

At the boot> prompt can you enter "set tty com2"? Does it redirect
correctly now? If so add the command to /etc/boot.conf.

You have to take care on how to setup the ilo in bios. I don't have a
system around here, but I remember openbsd and ilo fighting over a com
port. Setting the correct bios settings allowed me to redirect console
to a specific com port.

HTH,
Stijn

holger glaess wrote:
> hi
>
> i try to setup the last days the console redirection on al HP DL 145 G2
with ipmi board ( ilo standard )
>
> the most works i see the post bios output and the first lines of der boot
console of openbsd but there is a first error message
> that the com0 is not aviable and this ist true.
>
> the ipmi / ilo hardware together with the hp box redirect everything to com2
and it is not possible to chnage the com port by hardware.
>
> is there an existing solution to change the existing limit of openbsd that h
is able to use other com ports than com0 .
> ( at the openbsd faq is written that on amd64 / i386 systems only possible
to use the com0 port )
>
> any suggest for me ?
>
> holger

ilo (ipmi) and serial console redirection

[holger glaess]

hi

i try to setup the last days the console redirection on al HP DL 145 G2  with 
ipmi board ( ilo standard )

the most works i see the post bios output and the first lines of der boot 
console of openbsd but there is a first error message 
that the com0 is not aviable and this ist true.

the ipmi / ilo hardware together with the hp box redirect everything to com2 
and it is not possible to chnage the com port by hardware.

is there an existing solution to change the existing limit of openbsd that h is 
able to use other com ports than com0 .
( at the openbsd faq is written that on amd64 / i386 systems only possible to 
use the com0 port )

any suggest for me ?

holger

Re: IPMI

[Peter N. M. Hansteen]

"Karl Sjodahl - dunceor" <[EMAIL PROTECTED]> writes:

> You can also comment it our in your config and build a new kernel if
> you want it to stay more permanantly.

You can also use config -e to edit the kernel binary as described in
the FAQ, , quicker than a
kernel rebuild.

-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.datadok.no/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: IPMI

[Karl Sjodahl - dunceor]

On Nov 12, 2007 1:10 PM, Kleber Rocha <[EMAIL PROTECTED]> wrote:
> How I would disable the ipmi?
> I get this error on my system, /bsd: ipmi0: error code: ff when
> watchdog is running
>
>
> Thanks
>
>

Just boot with boot -c so you get into UKC.
Then disable ipmi with 'disable ipmi'.
You can also comment it our in your config and build a new kernel if
you want it to stay more permanantly.

BR
dunceor

IPMI

[Kleber Rocha]

How I would disable the ipmi?
I get this error on my system, /bsd: ipmi0: error code: ff when
watchdog is running


Thanks

Re: ipmi delay in 4.0 snapshot

[Marco Peereboom]

Delay is normal.  The communication with the BMC is quite slow and during the
first boot it goes out and talks to all devices so it'll incur maximum penalty
time wise.  Subsequent reads and writes to the BMC are faster.  Since this only
happens upon boot I don't think it is that important.  I did think about
deferring the initial reads until later but then you could end up with an
incomplete sensor list and/or invalid readings.

On Wed, Sep 27, 2006 at 11:52:27AM -0500, [EMAIL PROTECTED] wrote:
> Hello,
> 
> I noticed that when booting a Sun Fire V20z with a recent 4.0 snapshot,
> the kernel hangs for about 17 seconds right after "ipmi0 at mainbus0".
> The box boots successfully, and impi seems to be working fine.
> 
> Not sure if the delay is normal or not; just wanted to report it. This
> happens with both bsd and bsd.mp kernels.
> 
> --
> David
> 
> 
> OpenBSD 4.0 (GENERIC.MP) #967: Sat Sep 16 20:38:15 MDT 2006
> [EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> real mem = 2146480128 (2096172K)
> avail mem = 1834668032 (1791668K)
> using 22937 buffers containing 214855680 bytes (209820K) of memory
> mainbus0 (root)
> bios0 at mainbus0: SMBIOS rev. 2.31 @ 0xefc10 (44 entries)
> bios0: Sun Microsystems Sun Fire V20z
> ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca2/2 spacing 1
> mainbus0: Intel MP Specification (Version 1.4) (SUN  SunFire V20z)
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD Opteron(tm) Processor 248, 2193.17 MHz
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
> CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
> cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
> 64b/line 16-way L2 cache
> cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully
> associative
> cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully
> associative
> cpu0: apic clock running at 199MHz
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD Opteron(tm) Processor 248, 2192.84 MHz
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
> CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
> cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
> 64b/line 16-way L2 cache
> cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully
> associative
> cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully
> associative
> mpbios: bus 0 is type PCI
> mpbios: bus 1 is type PCI
> mpbios: bus 2 is type PCI
> mpbios: bus 3 is type PCI
> mpbios: bus 4 is type ISA
> ioapic0 at mainbus0 apid 2 pa 0xfec0, version 11, 24 pins
> ioapic1 at mainbus0 apid 3 pa 0xfd00, version 11, 4 pins
> ioapic2 at mainbus0 apid 4 pa 0xfd001000, version 11, 4 pins
> pci0 at mainbus0 bus 0: configuration mode 1
> ppb0 at pci0 dev 6 function 0 "AMD 8111 PCI-PCI" rev 0x07
> pci1 at ppb0 bus 1
> ohci0 at pci1 dev 0 function 0 "AMD 8111 USB" rev 0x0b: apic 2 int 19
> (irq 11), version 1.0, legacy support
> usb0 at ohci0: USB revision 1.0
> uhub0 at usb0
> uhub0: AMD OHCI root hub, rev 1.00/1.00, addr 1
> uhub0: 3 ports with 3 removable, self powered
> ohci1 at pci1 dev 0 function 1 "AMD 8111 USB" rev 0x0b: apic 2 int 19
> (irq 11), version 1.0, legacy support
> usb1 at ohci1: USB revision 1.0
> uhub1 at usb1
> uhub1: AMD OHCI root hub, rev 1.00/1.00, addr 1
> uhub1: 3 ports with 3 removable, self powered
> vga1 at pci1 dev 5 function 0 "Trident Blade 3D" rev 0x3a
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> pcib0 at pci0 dev 7 function 0 "AMD AMD8111 LPC" rev 0x05
> pciide0 at pci0 dev 7 function 1 "AMD 8111 IDE" rev 0x03: DMA, channel 0
> configured to compatibility, channel 1 configured to compatibility
> pciide0: channel 0 disabled (no drives)
> atapiscsi0 at pciide0 channel 1 drive 0
> scsibus0 at atapiscsi0: 2 targets
> cd0 at scsibus0 targ 0 lun 0:  SCSI0 5/cdrom
> removable
> cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
> amdpm0 at pci0 dev 7 function 3 "AMD 8111 Power" rev 0x05: rng active
> iic0 at amdpm0: disabled to avoid ipmi0 interactions
> ppb1 at pci0 dev 10 function 0 "AMD 8131 PCIX" rev 0x12
> pci2 at ppb1 bus 2
> bge0 at pci2 dev 2 function 0 "Broadcom BCM5704C" rev 0x03, BCM5704 A3
> (0x2003): apic 3 int 1 (irq 5), address 00:09:3d:13:32:8b
> brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
> bge1 at pci2 dev 2 function 1 "Broadcom BCM5704C" rev 0x03, BCM5704 A3
> (0x2003): apic 3 int 2 (irq 3), address 00:09:3d:13:32:8c
> brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
> mpi0 at pci2 dev 4 function 0 "Symbios Logic 53c1030" rev 0x08: apic 3
> int 3 (irq 11)
> scsibus1 at mpi0: 16 targets
> sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct
> fixed
> sd0: 70007MB, 90774 cyl, 2 head, 789 sec, 512 bytes/sec, 143374744 sec
> total
> sd1 at scsibus1 targ 1 lun 0:  SCSI3 0/direct
> fixed
> sd1: 70136MB, 78753 cyl, 2 head, 911 sec, 512 b

ipmi delay in 4.0 snapshot

[DAlten]

Hello,

I noticed that when booting a Sun Fire V20z with a recent 4.0 snapshot,
the kernel hangs for about 17 seconds right after "ipmi0 at mainbus0".
The box boots successfully, and impi seems to be working fine.

Not sure if the delay is normal or not; just wanted to report it. This
happens with both bsd and bsd.mp kernels.

--
David


OpenBSD 4.0 (GENERIC.MP) #967: Sat Sep 16 20:38:15 MDT 2006
[EMAIL PROTECTED]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2146480128 (2096172K)
avail mem = 1834668032 (1791668K)
using 22937 buffers containing 214855680 bytes (209820K) of memory
mainbus0 (root)
bios0 at mainbus0: SMBIOS rev. 2.31 @ 0xefc10 (44 entries)
bios0: Sun Microsystems Sun Fire V20z
ipmi0 at mainbus0: version 1.5 interface KCS iobase 0xca2/2 spacing 1
mainbus0: Intel MP Specification (Version 1.4) (SUN  SunFire V20z)
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Opteron(tm) Processor 248, 2193.17 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
64b/line 16-way L2 cache
cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully
associative
cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully
associative
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD Opteron(tm) Processor 248, 2192.84 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW
cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB
64b/line 16-way L2 cache
cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully
associative
cpu1: DTLB 32 4KB entries fully associative, 8 4MB entries fully
associative
mpbios: bus 0 is type PCI
mpbios: bus 1 is type PCI
mpbios: bus 2 is type PCI
mpbios: bus 3 is type PCI
mpbios: bus 4 is type ISA
ioapic0 at mainbus0 apid 2 pa 0xfec0, version 11, 24 pins
ioapic1 at mainbus0 apid 3 pa 0xfd00, version 11, 4 pins
ioapic2 at mainbus0 apid 4 pa 0xfd001000, version 11, 4 pins
pci0 at mainbus0 bus 0: configuration mode 1
ppb0 at pci0 dev 6 function 0 "AMD 8111 PCI-PCI" rev 0x07
pci1 at ppb0 bus 1
ohci0 at pci1 dev 0 function 0 "AMD 8111 USB" rev 0x0b: apic 2 int 19
(irq 11), version 1.0, legacy support
usb0 at ohci0: USB revision 1.0
uhub0 at usb0
uhub0: AMD OHCI root hub, rev 1.00/1.00, addr 1
uhub0: 3 ports with 3 removable, self powered
ohci1 at pci1 dev 0 function 1 "AMD 8111 USB" rev 0x0b: apic 2 int 19
(irq 11), version 1.0, legacy support
usb1 at ohci1: USB revision 1.0
uhub1 at usb1
uhub1: AMD OHCI root hub, rev 1.00/1.00, addr 1
uhub1: 3 ports with 3 removable, self powered
vga1 at pci1 dev 5 function 0 "Trident Blade 3D" rev 0x3a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 7 function 0 "AMD AMD8111 LPC" rev 0x05
pciide0 at pci0 dev 7 function 1 "AMD 8111 IDE" rev 0x03: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0:  SCSI0 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
amdpm0 at pci0 dev 7 function 3 "AMD 8111 Power" rev 0x05: rng active
iic0 at amdpm0: disabled to avoid ipmi0 interactions
ppb1 at pci0 dev 10 function 0 "AMD 8131 PCIX" rev 0x12
pci2 at ppb1 bus 2
bge0 at pci2 dev 2 function 0 "Broadcom BCM5704C" rev 0x03, BCM5704 A3
(0x2003): apic 3 int 1 (irq 5), address 00:09:3d:13:32:8b
brgphy0 at bge0 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
bge1 at pci2 dev 2 function 1 "Broadcom BCM5704C" rev 0x03, BCM5704 A3
(0x2003): apic 3 int 2 (irq 3), address 00:09:3d:13:32:8c
brgphy1 at bge1 phy 1: BCM5704 10/100/1000baseT PHY, rev. 0
mpi0 at pci2 dev 4 function 0 "Symbios Logic 53c1030" rev 0x08: apic 3
int 3 (irq 11)
scsibus1 at mpi0: 16 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct
fixed
sd0: 70007MB, 90774 cyl, 2 head, 789 sec, 512 bytes/sec, 143374744 sec
total
sd1 at scsibus1 targ 1 lun 0:  SCSI3 0/direct
fixed
sd1: 70136MB, 78753 cyl, 2 head, 911 sec, 512 bytes/sec, 143638992 sec
total
mpi0: target 0 Sync at 160MHz width 16bit offset 63 QAS 1 DT 1 IU 1
mpi0: target 1 Sync at 160MHz width 16bit offset 127 QAS 1 DT 1 IU 1
aapic0 at pci0 dev 10 function 1 "AMD 8131 PCIX IOAPIC" rev 0x01
ppb2 at pci0 dev 11 function 0 "AMD 8131 PCIX" rev 0x12
pci3 at ppb2 bus 3
aapic1 at pci0 dev 11 function 1 "AMD 8131 PCIX IOAPIC" rev 0x01
pchb0 at pci0 dev 24 function 0 "AMD AMD64 HyperTransport" rev 0x00
pchb1 at pci0 dev 24 function 1 "AMD AMD64 Address Map" rev 0x00
pchb2 at pci0 dev 24 function 2 "AMD AMD64 DRAM Cfg" rev 0x00
pchb3 at pci0 dev 24 function 3 "AMD AMD64 Misc Cfg" rev 0x00
pchb4 at pci0 dev 25 function 0 "AMD AMD64 HyperTransport" rev 0x00
pchb5

Re: Missing ipmi sensors on current

[Stuart Henderson]

On 2006/06/16 19:07, Nicholas Young wrote:
> On Fri, Jun 16, 2006 at 09:44:08AM +0100, Stuart Henderson wrote:
> > On 2006/06/16 17:54, Nicholas Young wrote:
> > > After rebooting with the new kernel the ipmi card which is a Tyan Taro
> > > M3289 is no longer being configured.
> > 
> > http://marc.theaimsgroup.com/?l=openbsd-cvs&m=114912246701017&w=2
> 
> Thanks, I had a look at cvs for ipmi.c should have checked harder.
> Is ipmi problematic for stable or just with the recent changes?

I don't know myself, the only board I have with an ipmi card (supermicro
aplus H8SSL) has it attached somewhere I can't find so I haven't used ipmi
on OpenBSD yet.

This reminds me, does anyone remember why the initial ASF support got
backed-out from bge(4)?