do we support any pre-2000 x86 hardware at this point?

no

that implies specific meaning for "support"

but the borderline is 64-bit/long mode support.

that puts us in 2003, or perhaps 2001 if you want to account for prototype systems :)

it appears the RTC on recent HPE systems aren't returning a century value anymore

which results in that error message I pasted yesterday...

of course this is in a lab, and it's apparently impossible to actually send F1-A through all the various layers, and can't turn on IPMI, so trying to debug while userland seems to crap itself after booting is proving challening..

why I was hoping there was an easy way to change the kmdb trigger

hrm.. what is the loader syntax to prevent a driver from loading, just `set disable-XXXX=1` ?

WTF, HPE?

that or we've somehow missed something -- though all the bits I could find on the RTC and looking at the source suggest we're doing things correctly

but I know that warning is probably going to generate calls... we can certainly mute it in our distro, but if it's something common enough now, i wonder if that check could just go away altogether

also, their megaraid card seems as bad as the other...

Woodstock: if i built the lmrc driver to have it skip the raid iport altogether, can you think of anything that'd otherwise break? (i.e. would it put the driver into some strange state, or will it just act like there's no raid volumes)?

[illumos-gate] 17675 concurrent devnet creation, link kstat read, and process fork deadlocks -- Kyle Simpson <kyle⊙oc>

jbk: that should work, if your card exposes drives on the physical iport

jbk yes

[illumos-gate] 17681 mdb `::whatis` on kernel dump is SUPER NOISY. -- Andy Fiddaman <illumos⊙fn>

bells and whistles, but the wrong kind

Well, I broke it so I get to fix it I suppose..

i should try to re-test and RTI my fixes for the genunix mdb module...

andyf: just joking about the "SUPER NOISY" bit :)

ok this is strange....

has anyone tried to boot illumos on ah HP DL380 Gen12? I thought maybe it was an issue with the lmrc driver, but I think this lab box I have access to has some sort of interrupt problem (which could be busted hardware, but could also be us not supporting something)

i managed to figure out via SSH to the iLO to send an NMI, and it works the first time for kmdb, but if you :c, and try again it doesn't work (not even an 'NMI received' message)

and other drivers appear to be blocked in attach waiting more or less for an interrupt to indicate a response is ready (i.e. mlxcx)

are you on the distro mailing lists?

because that is a model name that sounds familiar, but I don't know why

I think just smartos

it's familiar because everyone so often someone has emailed the omnios list about the DL380 in various generations

s/one//

so not relevant, except as a datapoint that people sure do disproportionately talk about them

me, I'd buy the model nobody had ever asked me about (and then probably get a vicious one like jclulow did, haha)

hrm.. ::prtconf shows a lot of 'pci8086,0' children off of various npe parents... can't remember of that's normal (the ,0 seems like it might not be right)

as best as I recall, a 0 valued there is a valid value

at the pci level

but rmustacc is far more the expert

I just don't think _we_ can mess up such that we get a vid and no pid

unless the subsystem magic confuses things

subsystem things DO get confusing.

in arm64-gate the aarch64 port has rmustacc's new-style naming, which I think makes it clearer

but incompatible :(

hrm... was able to try a second system... same deal...

so it has 2 CPUs (64 cores/ea)... and it's using the x2apic which ISTR in the past had some issues, but I can't recall the specifics (or if they were ever fixed)... at least with supermicro...

@richlowe check your DM, pardon my latency.

hrm.. probably a red herring, but 'Bad completion code for GET_DEVICE_ID: 212' -- which seems to be from the ipmi driver

yeah

i'll see if anyone else has run into anything...