illumos may already have a few bugs he created, that you inherited from Solaris/OpenSolaris long ago

Having recently setup a "real" machine, I find myself faced with questions about which clock to keep in which time zone etc.

Anyone have pointers to suggestions on what to do here? H/W clock GMT? Local?

I don't remember what's convenient, and did not find any notes on that with a quick look.

Oh. man rtc.8

gwr: I would be inclined to keep the RTC in UTC

Even if the system is nominally otherwise in a local timezone in /etc/default/init

rtc -u seems to be busted. no /etc/rtc_config

What does "rtc" say to you

# rtc -c

rtc: cannot open /etc/rtc_config: errno = 2

yes but just "rtc" though

Without arguments, rtc displays the currently configured time zone string for the RTC.

# rtc

GMT

Yes.

I would probably leave it alone then

I suspect this tool does not work correctly if the installer did not do something with "rtc -z ..." perhaps

gwr: process_rtc_config_file() in the kernel appears to just return an offset of 0 if the file is absent, which means your RTC is in UTC by default effectively

FWIW I don't see any mention of rtc or rtc_config in github.com/omniosorg/kayak which I believe contains the OmniOS installer

Whereas caiman (the installer for OI) does this: github.com/OpenIndiana/slim_source/…ext_install/ti_install.py#L472-L480

Which I expect is what the old violently colourful "is your machine part of a subnet?" installer also did

So I can just set the time and the RTC will be GMT?

I believe so yes

thx

I have not really thought about the RTC in ... many years

We don't that often setup real h/w anymore :)

You want NTP anyway

I mean, I look after a lot of physical machines

I just don't think I have consciously considered what was in the RTC since probably the Solaris era when it would break sometimes because the default was a dumb default for Windows compatibility

(and if that cron job didn't run properly after DST changes, things would be screwy)

And people tend to forget: Things change in Windows too, across releases

I assume so!

pfexec mdb -ke 'gmt_lag/D' -- if this tells you 0 I would imagine you are in UTC for sure

Here

's another admin question. With two interfaces, one on a private (non-routed) net, and another on a net that I want my default route to go on, both interfaces end up adding a default route.

They're both DHCP?

The extenral one is DHCP, the internal one is static.

I'm not sure why the static one would have a default route?

The static IF seems to want to add a default route when ipadm brings it up.

Are you using physical:nwam or physical:default

default

do you maybe have a default route in /etc/defaultrouter

and you'r seeing that + whatever DHCP supplies?

yeah or do you have routes in /etc/inet/static_routes ?

I suppose "route -np show" is the way to answer that last question technically

Hm. There are two there. Not sure how they get there.

"route -p add" or some installer machinery?

You can "route -p delete ..." stuff you see in "route -p show" etc

You might also want to check with routeadm that "IPv4 routing" is disabled

see also illumos.org/issues/14006

→ BUG 14006: ipv4-routing should not be enabled by default (New)

This seems to happen on all my Mac/Fusion VMs, where one net is the external one, and the other "VMs-only"

I don't see evidence of routed activity, but I might not have noticed.

routeadm says it's all disabled

That's good

If there are persistent routes they must have been added by you or by some tool

The bogus default route appears to come back after a reboot.

Perhaps there is some vmtools thing doing it?

maybe.

Anyone here doing "onu"-style illumos gate installs on OmniOS? (see other chat)

#omnios

qwr the in.routed is not running, i hope?:)

if routeadm says ipv4 routing is off then it should indeed not be running

yea, just it does not hurt to verify the actual process table:D

Greetings.

I'm trying to get some movement on illumos.org/issues/15302

→ BUG 15302: broadcom 3108 kernel driver update (New)

The newer broadcom boards (at least, the one we got) don't like the current driver.

I've got a card I can send to a dev who wants to work on the problem. (The one we had to replace so our new fileserver would actually work.)

As discussed on #omnios, this is likely another incremental (but likely nontrivial) update to mr_sas(4D). FreeBSD's moral equivalent might have enough to help whomever's interested in doing the work.

It also helps for companies using those parts or with relationships to get access to NDA docs. I am not using any HBAs, so that cannot be me.

oh, and note that if you discover that your RTC had been set in a non-GMT timezone, be aware that "rtc -z UTC" will step the system clock rather than the TOD clock so be alert for the ensuing oddities...

Feb 9 18:51:46 hydra sshd[37450]: [ID 800047 auth.crit] fatal: Timeout before authentication for 218.92.0.211 port 20621

Feb 9 14:53:41 hydra genunix: [ID 514117 kern.warning] WARNING: Time of Day clock error: reason [Reversed by 0x383f]. -- Stopped tracking Time Of Day clock.

(see log from yesterday)

Well, I came here to ask a question, decided to do my due diligence, researched a bit more, and found the answer to my question. apparently illumos doesn't have support for sd cards?

not in x86 branch

Hmm?

err are you sure?

blkdev was added for sdcards I thought

originally

I think we do with a standard controller.

Really?

Well mine didn't work IIRC

I found this from four months ago, illumos.org/issues/13843

→ BUG 13843: USB errors: slot in wrong state: 19 (New)

wait wrong one

ah, if it's via USB xhci then it should be supported.

never mind, I lost it

There may be bugs, but the standard sd controller enumerates at least on some platforms.

no, it's a microsd, and I also tried emmc. I may have omitted important information.

and I lost track of the bug I was looking at.

Don't you hate it when the bugs hide in the dark corners?

at any rate, the issue I was originally going to ask would be where mmc block devices would appear, because I don't know and I couldn't find anything that looks like one strolling through devices.

Will a RAID drive get those bugs hiding in dark corners?

Do we have a x86 emmc driver? I know ARM has drivers.

toasterson: Depends on the controller and how things shake out. So ultimately, what deivce in what controller.

jperkin: danmcd asked you to test ld stuff for me, right?

[illumos-gate] 15362 vtfontcvt: error: unused parameter 'stream' -- Toomas Soome <tsoome⊙mc>

rmustacc: ah, good to know

toasterson: Don't want to claim things exist that don't, but to understanding what interface it's being made visible via on x86 is pretty important for getting the appropriate support.

I am still trying to get the lay of the land in what kinds of support we have for devices and what is needed. My assumption was that eMMC was Embedded only so x86 is not something I would expect. But then again the protocol is old enough that we could have support.

Ultimately with emmc and sd and others it's not the protocol, but the controller.

SInce all maps to either DMA or USB?

Not necessairily.

modulo some other protocols I guess but in more general how are protocols mapped to needed drivers?

I mean, the problem is that it's not about the protocol, but the *controller* for that protocol.

For example, SPI is a protocol, but there are hundreds of different SPI controllers.

The protocol is the boring part because with rare exceptions when bit-banging we never are speaking a raw protocol.

Rather we're sending commands to something that does instead.

Yeah but we also need to talk to that something I assume

Right, that's the important part.

So with what spec do we talk to that something?

Well, generally there's not a guarantee of a spec.

But right now the sdcard driver we have attache to a PCI class code.

So it binds to the class that represents some standard sd host controller: sdcard.org/developers/sd-standard-overview/host-controllers.

But embedded systems generally don't use a standard PCI based interface. Same how they don't for USB.

Ahhhh, ok so then there are differences there. But I guess it's a register and DMA address space changes

well, every controller is different.

Embedded devices have memory mapped periperhals.

Which may or may not have anything to do with DMA.

Then again, even an AMD server chip also has memory mapped periperhals like an i2c controller.

So an AMD and ARM SoC have Memory mapped peripherals. and if thigs are attached there then it's DMA?

and PCI for the devices attached there

DMA is independent of memory mapped peripherals.

Ah, so memory mapped peripherals are controlled by writing data to a memory address but are not mapped to RAM? Is that right?

[illumos-gate] 15346 Handling of errstring in libcfgadm should follow man page -- Dan Cross <cross⊙oc>

[illumos-gate] 14309 smb(5) out of sync with cmd/smbsrv/smbd/server.xml after 1122 and 11033 -- Bill Sommerfeld <sommerfeld⊙ame>

[illumos-gate] 15353 find -useracl/-groupacl ignores id type of acl entry resulting in false positive matches -- Bill Sommerfeld <sommerfeld⊙ame>

toasterson: The way I think about it is that the processor has physical address space.

Some of that address space is backed by memory (DRAM, SRAM, etc.).

Other portions are backed by hardware peripherals. For example, on x86 you have the local apic up there.

A large chunk of it on servers is carved up for dynamic assignment to PCI and PCIe devices.

oversimplifying wildly, DMA moves data between memory and an I/O device without the CPU doing loads & stores to move it. So instead of storing characters one at a time to a memory mapped address of a UART, you instead store the I/O bus address of a chunk of memory and its length to a couple device registers and tell the device to go get it/put it.

[illumos-gate] 15375 loader.efi: we have duplicate command_lszfs -- Toomas Soome <tsoome⊙mc>

THat clears things up thanks.

[illumos-gate] 14892 pollhead lifetime too short in signalfd -- Patrick Mooney <pmooney⊙pc>

Thanks danmcd and co. for helping test those signalfd bits