I still hold out I'll get to "know the guy who killed X11"

with the stake, and the ritual

you cannot kill the undead richlowe

[illumos-gate] 16981 pbchk should probably bail early on long commit series -- iximeow <illumos⊙in>

[illumos-gate] 16982 pbchk could have a better user agent -- iximeow <illumos⊙in>

New record with zfstest: Results Summary

PASS 1286

SKIP 1

Note: flip-flops are still there, just this time they are at PASS side:)

I'm looking at filesystem stuff tonight :)

tsoome - that's brilliant!

Hey, I'm sure this has come up a million times so I'm really not trying to offend by asking this: How close is the illumos ZFS implementation tracking OpenZFS?

[illumos-gate] 16977 t4nex should be cstyle clean -- Patrick Mooney <pmooney⊙pc>

tsoome: thank you for your work fixing flakey tests!

sommerfeld its necessity, without testkit there is little hard to try to prove we are good (as much as the tests *can* prove).

tsoome: nice

i can hopefully retire my list of 'known to fail' zfs tests

which will be nice

they take like 6-8 hours to run

perhaps a silly question, but when an NMI received is there any other additional context/info surrounding it that can be examined?

we still do have several flipping, like l2arc ones, which do need l2arc fixes.

am.. surrounding it? like other threads currently on CPU?

more about what caused it? e.g. you can manually trigger one, but are there other things that would generate one (and if so, is there any way to distinguish between them)?

Not architecturally.

there's a lab box (not our lab) where an NMI is occurring about once a day.. we suspect it's something in the lab doing this, but don't want to dismiss other possibilities if such could exist

The answer is going to be processor/board specific.

There are definitely other things like still have old school PCI errors enabled or parts of the I/O APIC redirection table.

ON some processors SMI's can lead to NMIs too.

[illumos-gate] 16760 Source code contains man page cross-reference errata -- Chris Fraire <cfraire⊙mc>

[illumos-gate] 16674 dev_err(9f) doesn't do anything useful with CE_PANIC -- Robert Mustacchi <rm⊙fo>

hurray

[illumos-gate] 17008 ZTS: left over file /var/tmp/file.pidnum -- Toomas Soome <tsoome⊙mc>

jbk: I assume the machine has a BMC or whatever?

Are there audit logs or whatever for IPMI actions in there?

(Does it stop happening if you unplug or wall off the BMC for a few days haha)

a subtle but good idea

I've always been sceptical of machines where NMIs just happen from time to time, motivating that Linux message about "haha, nmi, continuing" or whatever

While anything is possible I would always blame a BMC first lol

yes, I was always trying to get from Keith the _specifics_ of whatever machine generated one during boot, and made our NMI handling suck

Yeah I have no data

if it was like, one of Sun's x86 blades I'm absolutely willing to say "We should NMI properly, and if that backfires we'll undo it again"

and say sorry a lot

v. if it's actually a thing that happens to normal people, and we can really see that being true

joeaveragedev . o O ( NMI? Not My Interrupt )