If I had a nickel for every time the `mod_uninstall_daemon` got me on DEBUG bits I'd certainly have enough to buy a burrito at this point.

i wonder if it could be a bit more verbose to remind you it's doing stuff

oh I'm not complaining, it found a bug, as it usually does when I run into it, just thought it was funny

i forget than wonder what was wrong that the driver is gone :)

or 'why was it unloading?..... oh'

rzezeski: told me that zig is better than C jbk.... what cha think about that?

:P

i've not used zig yet, so I cannot say...

i mean all languages (even rust) has its warts

and better is a bit subjective... i tend to go more with, given the constraints present, which language is going to be the best fit for the problem?'

jbk.... you gotta get on youtube....Jai 4 life

i mean.. i once wrote a GUI desktop app in java(!) because it needed to be a desktop app, and java was the only language that had the necessary libraries (and there wasn't enough time to port or rewrite those in some other language)

java normally wouldn't be my first choice for a desktop application

but in that case, it was the most pragmatic choice

what really annoys me is trying to force the use of a particular language when it's a really bad fit

hmm... this is interesting... reddit.com/r/illumos/comments/1mf7r…unable_to_boot_illumos_via_live_usb -- i think we always forcibly try to load the kb8042 driver

only if you have one?

look at plat_kbdpath() though -- you end up always trying to attach the hard coded isa device

if I remember, absent weird configuration for bad computers, we attach to the node acpi (and maybe isa pnp?) would enumerate

and looking at consconfig_state_init(), I haven't been able to find where anything would actually automatically set (vs putting something in /etc/system) consconfig_usb_kb_path or usb_kb_path)

which seems to be the only way to avoid calling plat_kbdpath()

the XXX comment there is kind of hinting too. From another hand, however, if there is no hardware, kb8042 should not hung the system...

though... i guess.. I can't recall offhand.. does verbose boot print the device<INST> is <PATH> message after attach completes?

or before?

jbk: I feel like it prints the message _after_ attach

and that this is a classic red herring

that's what I was wondering...

as a side note, am i correct in thinking that prtdiag -v is misinterpreting the ranges properties for PCI devices when it displays the Range Specifications? everything I've looked at it, I can't believe that the output is in fact correct

jbk: I don't think I get that sort of output on my systems

What does it look like?

oh, prtconf not prtdiag?

err yeah

it's friday :)

brain is shutting down

Which part of it do you think is incorrect

richlowe might have opinions about this, I feel

Yeah, there is an issue here. Let me find a write up.

I think I have notes from Keith somewhere.

Though maybe it's Rich.

Ah, it was andyf, my mistake.

→ BUG 12914: prtconf fails to decode PCI ranges property (New)

I believe andyf probably has more context on things in terms of what we were seeing.