[illumos-gate] 15640 name resolution failure on destination hosts with multiple AAAA records -- Andy Fiddaman <illumos⊙fn>

i was told to come here for this question: if you cover UNIX, what UNIX version did the NeXTCube run? (NeXTCube as in Steve Jobs's NeXT)

that's not really on-topic here, but the answer is their own custom Unix, named NeXTSTEP, based on BSD & Mach: en.wikipedia.org/wiki/NeXTSTEP

it evolved to become MacOS now

alanc: is there a channel that i can get more info on that?

I really don't know

There's a whole thread of history @cosmicwonder you can unravel starting with that NeXTSTEP article.

[illumos-gate] 15687 Remove compiler flags that only mean something to Sun Studio -- Richard Lowe <richlowe⊙rn>

I'm scared of this one, back it out if there's trouble.

(I know there's a process, but consider "talking to me about it" dealt with)

Building -gate locally, and running a not-yet-pushed SmartOS merge, richlowe.

You said you generated no wsdiff... this pleases me and makes me thing we shouldn't be too worried. The proof, however, IS in the pudding, so I'll let you know.

s/thing/think/^^

whete is this pudding making feature in illumos?

*where

richlowe - I'll get that pulled into helios in a bit which will give it a spin

we mostly make sausage

we're trying to setup a new system and it fails to boot SmartOS because services timeout when they execute devfsadm

Booting it with milesystone=none gets us a shell and it looks like it might be related to ahci timeouts: frupic.frubar.net/shots/43465.png

There seem to be three ahci controllers (1x pci1b21,1062 ASMedia + 2x pci197b,0 JMicron) about which I haven't found out much yet

Any suggestions for debugging this further? If it might be just one bad disk, isolating that would be cool. If it's related to a controller that needs a workaround I can try to dig in and test things

boot the kernel debugger and load one module at a time maybe?

There are at least two loops that drv_usecwait() in the ahci_software_reset().

If you have a known-good disk, boot this new system with only the disk (and the USB or ISO) to see what happens.

sjorge: sadly, it only makes blood pudding, not sweet dessert pudding

@richlowe --> both my local -gate build (on OmniOS '046, both -nd and -DEBUG) plus the illumos part of smartos-live (non-DEBUG only, but can try later on DEBUG) build.

@alanc & @sjorge ==> My dogs both perked up also when I said pudding, FWIW.

(Normally one dog is with W and one with me but W was down here so we had both dogs, and I was literally quoting proof-in-the-pudding about the Rich push to her...)

Your dogs would probably enjoy a good blood pudding though

wiedi: I think you can blacklist ahci from attaching to things?

but I'm not certain anymore

can I do that only for one of the controllers?

I thought so, but now I'm not sure.

it might be I was thinking of the sata blacklist, but I remember when ahci was new and spotty

and I could swear we had a way to make it go away and see what happened.

wiedi: My general approach when that happens is if this is rerpdoucible, when I hit the state where it's been going on for a non-trivial time is to inject an NMI and look at the system in kmdb.

maybe we just told people to turn it off in the bios, back when that was a thing.

based on the manual page being awful, but saying that

frupic.frubar.net/shots/43477.png sadly looks like it's not isolated to one controller or disk

freebsd seems to have a quirks thing for jmicron: github.com/freebsd/freebsd-src/blob…b99dc7/sys/dev/ahci/ahci_pci.c#L427

@richlowe -DEBUG SmartOS passed through its illumos portion with your Makefile fixes w/o issue as well.

And yes @alanc they probably would (in spite of their respective sweet-tempered, but distinct, natures.)

wiedi: I have a disturbing workaround cribbed from linux for a jmicron controller in one of my machines.

sounds promising, I'll take it :D

the freebsd quirks thing seems to be "ew, don't touch it" rather than anything functional.

they have a few more further up (AHCI_Q_NOFORCE | AHCI_Q_1CH) and throughout the file, not sure yet what they all do yet

ah, I already shared it -- illumos.org/issues/1648

→ BUG 1648: JMicron JMB363: switch from RAID to AHCI mode (New)

that might not be your issue.

if your machine catches fire from it don't blame me :-)

hm yep sounds a bit different, here it already shows up as ahci

probably not the same underlying issue.

is it an actual bad disk?

the sd default timeouts + retries are pretty ridiculous for anything made in this millennium

(IIRC, it will try for around 20 minutes per disk before giving up)

now it seems unlikely to be a bad disk since the timeouts happen with both jmicron controllers and on different ports

illumos.org/issues/14693 seems similar

→ BUG 14693: JMicron JMB585 AHCI SATA controller: System panics when trying to write data on pool (New)

that might also be worth lodging an issue

basically sd will keep retrying for so long that it can trip the deadman timer

or it can

(this can be annoying for problematic disks since it'd probably be better to try to just fault the disk if we can)

yep, I've had this in the past where pulling a disk made things better so this was a first thought. Unfortunately this time it looks like it won't be that easy ;)

there's some other fun things i'm trying to fix

like if you resilver a disk in a large pool (in terms of devices)... if one of the top level vdevs is slower, it can cause some 'fun' pathologies

(the scrub prefetch can end up causing an absolutely massive backlog of I/O on a disk)

that itself can trigger the deadman timer due to some other pathologies

wiedi: are you able to run 'mdb -k' or are things far too bad for that?

@richlowe very few diffs from wsdiff and NONE of them are your fault (some/most of them are OUR fault... looking at you libzdoor!!!!). I'm pushing this merge of fenix illumos#15687 into illumos-joyent.

BUG 15687: Remove compiler flags that only mean something to Sun Studio (Closed)

↳ illumos.org/issues/15687 | code.illumos.org/c/illumos-gate/+/2876