[illumos-gate] 15583 Panic due to assertion failure when dumping userland process core -- Andy Fiddaman <illumos⊙fn>

My brain skipped the 'process core' bit and I was like well dumping the entire userland will surely cause panics :D

Heh. This is an unlikely edge case, and a non-default configuration, but a core dumping userland process is not supposed to take the kernel with it.

[illumos-gate] 15507 smbd logging every 5 sec. after join failure -- Gordon Ross <gwr⊙rc>

[illumos-gate] 15579 smbsrv: smb_server_listener() error messages need review -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 15602 loader: gzipfs should follow NFSREAD_MAX_SIZE -- Toomas Soome <tsoome⊙mc>

rmustacc: can you think of any reason _not_ to add ufm support to sd.c? I know some of the other properties have the FW info, but it'd be nice to have (as much as possible) a way to get the info with the same API

(I suppose a reason other than not wanting to touch a 30,000 line .c file :P)

There's no particular reason, but it depends mostly on where you want to perform processing and it's pretty easy for topo to create it itself.

Also, given there are already fwflash plugins, perhaps slightly more limited value since we don't have a write path through the ufm subsystem yet.

But off hand, probably worth exploring a bit.

I'm not sure we actually have a full set of fwflash bits for a lot of stuff

We don't.

ptribble: FYI: libffi/libffi #778

(upgrading libffi broke GNOME 41 on SPARC for us, we've had to make it build with the old version for now)

Thanks! Oh joy, another incompatibility.

Has anyone seen this at boot time? I think it's new with some PCIe changes:

WARNING: pci_lcap_locate: unexpected pci header type:40

That byte changes on me from machine to machine, but remains unchanged across reboots.

I haven't, but I think it's from 14195 (fenix?)

fenix illumos#14195

BUG 14195: pci_cap_locate and pci_xcap_locate need additional bounds (Closed)

↳ illumos.org/issues/14195 | code.illumos.org/c/illumos-gate/+/2190

And to be fair, it only manifests on the three identical pieces of SuperMicro HW that are 1U Haswell-E servers.

The Haswell client (Xeon-E3 to be pedantic) does NOT issue this error.

So my money is on HW flake, but if it piques the interest of anyone who knows PCIe, I figured sharing was better than not.

to be clear, I don't think robert introduced it. I just can't think of other ways it could be new

I don't think he introduce it either. I think the flaky-HW's flakiness is just More Visible now.

I'm hoping for, "Oh cool, we detected X now where we didn't used to!"

If we can do a pcieadm save-cfgspace and indicate which devices, I can invesetigate it.

Easy peasy...

I'm not sure which device it's referring to.

MD5 == 54078b32e0bff698fe907bcbdd9f5b3f

Don't break your back over it. I'm honestly thinking this is one of those things where new improvements in SW find old crud in HW.

[illumos-gate] 15584 misc. components use headers from the build machine -- Richard Lowe <richlowe⊙rn>

every second of gitomat latency makes me slightly more scared

lol sorry

clearly we need to start routing gitomat messages over uucp via kremvax so rich knows to expect long delays

haha

github!att!ftmeade!bletchley!kremvax!ccpvax!libera

@uucp.Berkeley.EDU

That was a blast, or should I say bang, from the past.

One of my ancient .signatures had an estimate bang-path to reach me, but even in the late-80s RFC 822 was working well enough I never used UUCP save for USENET and rn(1) and NNTP hid that well enough.

I don't think I ever had a bang path in my .signature, but I did have a bitnet address listed for a while

by the late 80's the USENET core mostly wasn't using UUCP any more. Bang-paths were still used with NNTP to trace the path of a message as it was flooded through the network.

My mid-80s .sign had hp-pcd!orstcs!nomad - I don't think there was anything in front of hp-pcd but that was long, long ago.

I somewhere have some ancient mailing lists archives -- including a young sommerfeld if I remember -- where mail systems were still trying to interoperate and chewing up eachother's addresses

email: it used to be even worse

Not worse, just differently sucky. (I think I was too young for UUNET and BITNET to be part of my daily driving.)

Tell someone from 1989 about HTML email and top-posting culture, e.g.

I remember running pathalias and being absolutely amazed it worked.

When I first joined the Interneted world I was in the CS department. We were part of CSnet Phonenet. They would call us a few times a day to deliver our @addressed email.

In order to get email from the computing center (which was on bitnet) to the CS department, a distance of several hundred feet, it had to go from Oregon to New York, through a bitnet|internet gateway, to CSnet, then eventually was delivered to us.

Time critical email was not a thing.