Switch to DuckDuckGo Search
   September 27, 2019  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >

Toggle Join/Part | bottom
[00:01:38] <andyf> What was the consensus on inet/cc.h then? I just pushed https://illumos.org/rb/r/2348/diff/2#index_header
[00:02:12] *** jzu_ <jzu_!~jussi@pupu.jus.si> has joined #illumos
[00:03:55] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[00:04:37] <rmustacc> andyf: Well, in so far as no one disagreed with me and I had the most history, shipping it with guards.
[00:05:00] <rmustacc> I think?
[00:05:32] <andyf> There was talk about guarding the include itself, but I think in the end you said ship the header, guard it all
[00:05:48] <andyf> so that's what I've done, using the same guard that is around the tcp_s struct
[00:06:07] <rmustacc> Randy's solution didn't solve the problem.
[00:06:26] <rmustacc> Because lsof would just fall over it again.
[00:06:33] <rmustacc> Which is how I assume you got here.
[00:07:06] <andyf> yes, that's the package that didn't build, but I assume there could be others if they include ipclassifier.h or something around there
[00:07:24] <rmustacc> That software really shouldn't.
[00:07:45] <rmustacc> Hopefully your lsof is rebulit every time you build illumos.
[00:08:26] <_mjg> ugh
[00:08:32] <andyf> I see why you asked that, but I have no idea :)
[00:08:33] <_mjg> someone(tm) really needs to rewrite lsof
[00:08:40] <andyf> I thought lsof used pfiles these days
[00:08:43] <_mjg> it uses /dev/kmem on freebsd as well
[00:08:46] <andyf> but I never use it myself
[00:08:58] <rmustacc> _mjg: I'm glad my misery has company.
[00:09:07] <_mjg> i broke it myself at least twice
[00:09:14] <_mjg> since it includes kernel headers
[00:09:29] <_mjg> and defines _KERNEL
[00:09:32] <_mjg> funzies are to be had
[00:09:47] <rmustacc> andyf: No, it doesn't.
[00:09:56] <rmustacc> andyf: It basically opens up /dev/kmem and just goes around looking for things.
[00:10:05] <rmustacc> Hopefully read only.
[00:11:03] <andyf> oh :(.. then I wonder where I misread that
[00:11:28] <rmustacc> andyf: There was a variant of lsof that someone wrote a Joyent once that did pfiles on everything as a way to avoid passing through /dev/kmem into a zone.
[00:11:35] <rmustacc> Because that's something you never want to do.
[00:11:53] <rmustacc> (Unless you basically treat that zone as being in the GZ)
[00:12:26] <andyf> ah, that would explain it - I read it on a link that I got to from papertigers.. it was a Joyent bod I think
[00:13:07] <rmustacc> It's not the traditional lsof that you're building.
[00:13:25] <rmustacc> The rb bits there look good.
[00:13:31] <rmustacc> Thanks for doing that.
[00:15:31] <andyf> I read about lsof using pfiles at https://github.com/bahamas10/illumos-sockstat
[00:15:38] <andyf> and got the wrong end of the stick
[00:19:36] *** jessfraz_ <jessfraz_!~jessfraz@unaffiliated/jessfraz> has quit IRC (Remote host closed the connection)
[00:20:35] *** jessfraz_ <jessfraz_!~jessfraz@unaffiliated/jessfraz> has joined #illumos
[00:25:57] <yuripv> it's a bit weird: inet/tcp.h includes inet/cc.h which includes netinet/tcp.h
[00:26:04] <yuripv> why do we have 2 tcp.h? :)
[00:26:54] <rmustacc> yuripv: They're for different purposes.
[00:26:58] <rmustacc> And well, history.
[00:28:43] <rmustacc> Most of the netinet/* are about the protocol and are generally suitable for use in userland.
[00:29:11] <rmustacc> Most of the inet/* are where the kernel modules have headers for their internal implementation.
[00:29:29] <rmustacc> And excepting lsof style walking through kmem/mdb, shouldn't be used.
[00:29:55] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has joined #illumos
[00:31:43] <rmustacc> A bunch of the netinet/* stuff are also defined in RFCs, like the RFC 2553 IPv6 macros.
[00:37:59] *** andy_js <andy_js!~andy@97e29e78.skybroadband.com> has quit IRC (Quit: andy_js)
[00:44:54] *** ZOP <ZOP!~ZOP@phobos.wgops.com> has joined #illumos
[00:45:54] *** rkiene <rkiene!~rkiene@208.184.5.170> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
[00:47:02] *** ZOP_ <ZOP_!~ZOP@phobos.wgops.com> has quit IRC (Ping timeout: 276 seconds)
[01:08:09] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC ()
[01:27:10] *** _Tenchi_ <_Tenchi_!~phil@d-207-255-80-203.paw.cpe.atlanticbb.net> has quit IRC (Read error: Connection reset by peer)
[01:28:44] *** _Tenchi_ <_Tenchi_!~phil@d-207-255-80-203.paw.cpe.atlanticbb.net> has joined #illumos
[01:32:44] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[02:07:27] *** jemershaw <jemershaw!~jemershaw@c-76-99-32-145.hsd1.pa.comcast.net> has quit IRC (Remote host closed the connection)
[02:07:40] *** jemershaw <jemershaw!~jemershaw@c-76-99-32-145.hsd1.pa.comcast.net> has joined #illumos
[02:13:50] *** snuff-work <snuff-work!~snuff-wor@202-161-112-134.tpgi.com.au> has joined #illumos
[02:18:02] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC (Remote host closed the connection)
[02:30:02] *** atrius <atrius!~atrius@99-160-139-232.lightspeed.nsvltn.sbcglobal.net> has quit IRC (Ping timeout: 245 seconds)
[02:33:37] *** atrius <atrius!~atrius@99-160-139-232.lightspeed.nsvltn.sbcglobal.net> has joined #illumos
[02:38:09] *** alanc <alanc!~alanc@129.157.69.53> has quit IRC (Remote host closed the connection)
[02:38:36] *** alanc <alanc!~alanc@129.157.69.53> has joined #illumos
[02:40:41] *** atrius <atrius!~atrius@99-160-139-232.lightspeed.nsvltn.sbcglobal.net> has quit IRC (Ping timeout: 265 seconds)
[02:41:12] *** atrius <atrius!~atrius@2600:1700:22d1:518:34b6:9372:8292:83f5> has joined #illumos
[02:46:41] *** vaxsquid <vaxsquid!~vaxsquid@znc.banana.fish> has quit IRC (Quit: Coffee is for closers!)
[02:47:21] *** vaxsquid <vaxsquid!~vaxsquid@znc.banana.fish> has joined #illumos
[03:06:40] *** baojg <baojg!~baojg@162.243.44.213> has joined #illumos
[03:13:37] *** sarvet <sarvet!~o.o@i5387892D.versanet.de> has quit IRC (Quit: Leaving)
[03:20:00] *** ed209 <ed209!~ed209@165.225.128.67> has quit IRC (Remote host closed the connection)
[03:20:08] *** ed209 <ed209!~ed209@165.225.128.67> has joined #illumos
[03:23:21] *** AmyMalik is now known as Reinhilde
[03:39:39] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has quit IRC (Quit: jcea)
[04:33:56] <LeftWing> Well I'm pretty sure something in loader or early boot is broken now
[04:34:24] <LeftWing> I updated my OmniOS VM (on Digital Ocean) and it seems like the new loader triple faults
[07:05:00] <LeftWing> (to latest bloody, that is)
[08:07:12] <tsoome> hm?
[08:20:42] <tsoome> my patches are stuck it seems:D
[08:27:35] <andyf> LeftWing - we are seeing the same when booting the latest bloody under Hyper-V
[08:27:58] <LeftWing> andyf: Oh no!
[08:28:04] <andyf> LeftWing - 20190919 seems to work
[08:28:05] <tsoome> where it is blowing up?
[08:28:19] <LeftWing> At the point of "boot"
[08:28:23] <andyf> To get around it, you can press ESCAPE really early to get to the first loader prompt
[08:28:27] <andyf> then enter -t
[08:28:28] <LeftWing> it seems to start loading things and then just resets
[08:28:33] <andyf> LeftWing - Yep
[08:28:35] <LeftWing> andyf: Yeah, I used the old one
[08:28:45] <LeftWing> And was able to resurrect the VM
[08:28:52] <tsoome> boot -B prom_debug=true,kbm_debug=true
[08:29:04] <andyf> We actually think it might be the change I did to set the boot resolution... which doesn't make sense, but..
[08:29:08] <LeftWing> tsoome: Dies too early for that to be helpful
[08:29:43] <LeftWing> I guess if you use a /boot/loader from an old BE, it gets all the forth/config files from the old BE too?
[08:29:45] <andyf> Copying /boot/loader from a working BE is not enough
[08:29:50] <LeftWing> Interesting
[08:29:57] <andyf> but copying all of /boot fixes it
[08:30:23] <andyf> hadfl was working on it, I don't know how far he got before sleeping
[08:30:34] <LeftWing> Well I'm glad it is not just me! :D
[08:30:50] <andyf> It's bloody, it occasionally breaks :) Releases are awesome
[08:31:01] <andyf> I'm glad it is not just Hyper-V actually..
[08:31:10] <LeftWing> They seem to use QEMU/KVM on DO
[08:31:27] <tsoome> it does happen in qemu?
[08:31:35] <andyf> We can't replicate it on real hardware, nor under bhyve
[08:31:40] <andyf> I haven't tried kvm
[08:32:00] <tsoome> btw you can add -t to /boot/config
[08:32:28] <andyf> tsoome - there are so few changes since the working one - I can't see anything suspicious
[08:32:41] <tsoome> I think it is some stupid corner case
[08:33:02] <andyf> The only thing that's OmniOS-specific is some stuff I added to change the resolution of the framebuffer before boot (was planning to upstream later)
[08:33:12] <tsoome> I have received some reports but not any I can replicate and fix
[08:34:01] <tsoome> like https://www.illumos.org/issues/11746
[08:34:39] <LeftWing> I can try -t
[08:34:42] <tsoome> it is clearly about some memory corruption, but how to discover it...
[08:35:30] <andyf> What's the right name for that first loader prompt where one can enter -t? Is it stage2?
[08:35:57] <tsoome> depends on how you count, stage2 usually, yes
[08:36:15] <tsoome> boot2 prompt.)
[08:38:41] <LeftWing> OK, -t at the "boot:" prompt helps
[08:39:00] <tsoome> it does?
[08:39:06] <tsoome> ok…
[08:39:06] <LeftWing> yes
[08:39:13] <andyf> It helps on hyper-v too
[08:39:56] <tsoome> it means we get writes past FB memory.
[08:40:16] * Reinhilde fault
[08:40:42] * andyf tries booting under kvm
[08:41:44] <tsoome> or…. hrm, I wonder….
[08:45:45] <tsoome> those faults are with BIOS version… 11746 does seem to point to some sort of write issue related to FB, but what if reading in kernel/modules will write those modules into FB memory…
[08:50:47] <andyf> tsoome - I'm pretty sure that what has broken OmniOS is my screen resolution stuff in forth
[08:52:44] <tsoome> we are checking against the smap but we also need to consider FB memory
[08:54:09] <andyf> although this looks really wrong
[08:54:09] <andyf> https://paste.ec/paste/n9XznmFg#ltgabu9FDDyNz47jiDUaipPVJpCZTrFqKJnT0bQY1SS
[08:54:09] <tsoome> thats in usr/src/boot/sys/boot/i386/libi386/i386_copy.c :)
[08:54:52] <tsoome> ah, that is one trap you see there
[08:55:40] <tsoome> the trap is about compile mode and interpret mode, s” will take string from PAD space while interpreting.
[08:56:07] <tsoome> PAD space is fixed size statically allocated memory
[08:58:04] <tsoome> but if you define word as like: : XXX s” something” s” something1” ; then you will get 2 distinct strings on stack.
[08:58:23] <tsoome> https://paste.ec/paste/9MikF3Af#eUIR4as-1LHCSGpos+4O/hRcZrMOgxO9wduerS6Wqtw
[08:58:46] <andyf> ok, thanks, I won't worry about that then
[08:58:59] <tsoome> that is something confusing, yep
[08:59:24] <tsoome> pad space is often used as “scratch” memory
[09:00:07] <andyf> If it helps work out where the problem might be, running set_resolution seems to cause it
[09:00:09] <andyf> https://github.com/omniosorg/illumos-omnios/commit/c5ec292c5e9bacbdc00fc3fbafcb5f630300f59e#diff-41a7ef4a74ab4ad5ae28351214786af7R237
[09:00:21] <tsoome> s" /pad" environment? will get the size of pad space
[09:00:26] <andyf> (apart from the first comment being wrong and the last line should be 2drop, I can't see why)
[09:02:54] <andyf> hmm..using a word as you suggested still does not help me
[09:02:54] <andyf> https://paste.ec/paste/OXl8YPBm#qCeR-hLJ+QAVz2fbgvzSIysY722o6vRJIAL+THmCuLO
[09:03:27] <tsoome> em?
[09:05:19] <Reinhilde> a.
[09:05:21] <Reinhilde> q.
[09:09:32] <andyf> If I boot under bhyve, it all works
[09:09:49] <andyf> https://paste.ec/paste/MeHJ4Kq6#H0+354u31EokWm9LqLkETHzl11isYlY2FXK4IrDqXYv
[09:10:04] <tsoome> the crash happens once you start to boot the kernel?
[09:10:20] <andyf> yes, after the boot archive is loaded
[09:10:52] <tsoome> get me please framebuffer get output from such system. I wonder, what is FB address there
[09:11:25] <LeftWing> Do I run "framebuffer get" ?
[09:11:28] <tsoome> yes
[09:12:20] <andyf> https://paste.ec/paste/bUmyQ3ow#GEIFTPZ6J-r7er1puo9F63DCKHCUl9R9tYOtnIOkITj
[09:12:47] <tsoome> and smap ?
[09:13:02] <LeftWing> https://sysmgr.org/~jclulow/tmp/fbg.png
[09:13:26] <LeftWing> https://sysmgr.org/~jclulow/tmp/fbgandsmap.png
[09:13:51] <andyf> and https://paste.ec/paste/A4G56uum#6c6HxczTa1k04KDVOf4aTlV0pgPLnhujHBfenzDRwIC
[09:14:32] <tsoome> that seems to confirm my guess….
[09:16:20] <tsoome> smap_find() does check SMAP_TYPE_MEMORY (value 1), and if the fb is in fact mapped from SMAP_TYPE_MEMORY, we can have collision
[09:16:44] <tsoome> fortunately it is easy to add that check:)
[09:17:36] <Reinhilde> apparently I have a constitutively high heart rate (100) and constitutive prehypertension (128/73). this is confounded by blood pressure cuff anxiety
[09:18:08] <tsoome> Reinhilde: ouch.
[09:19:38] <andyf> tsoome - does that explain why I can't put any strings on the stack under qemu?
[09:19:57] <andyf> Under bhyve, immediate s" and compiled s" both work fin
[09:19:59] <andyf> +e
[09:20:11] <andyf> and under qemu, neither work
[09:20:41] <tsoome> am, thats something else:D
[09:24:40] <andyf> (tsoome, when you get a minute, could you please confirm if you're still happy with https://illumos.org/rb/r/2348/ ?)
[09:26:10] <tsoome> this header is not used by libfakekernel?
[09:27:07] <andyf> I guess not.. the guard I have added is the same one that is around 'struct tcp_s' in tcp.h
[09:27:18] <andyf> and the structures in cc.h are only referenced from that 'struct tcp_s'
[09:27:23] <tsoome> ok
[09:27:36] <andyf> I have a full build running
[09:27:49] <tsoome> yea, that was what I wanted to ask:D
[09:28:14] <tsoome> that fakekernel stuff can hurt such cases
[09:29:51] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-149.net.upcbroadband.cz> has joined #illumos
[09:32:26] *** BH23 <BH23!~BH23@193.117.206.132> has joined #illumos
[09:33:46] <tsoome> the s” word issue is that it has no well defined lifetime. it is assumed to be consumed “soon” after creation.
[09:35:05] <tsoome> basically, if you need to keep it for some time, it is better to allocate some space and set the value and then later to release the space.
[09:36:45] *** andy_js <andy_js!~andy@97e29e78.skybroadband.com> has joined #illumos
[09:42:59] *** nbhauke <nbhauke!~hauke@Dachstein.nt.e-technik.tu-darmstadt.de> has joined #illumos
[09:59:50] *** kev009 <kev009!~kev009@ip72-222-200-117.ph.ph.cox.net> has quit IRC (Remote host closed the connection)
[10:03:12] *** kev009 <kev009!~kev009@ip72-222-200-117.ph.ph.cox.net> has joined #illumos
[10:11:16] *** man_u <man_u!~manu@manu2.gandi.net> has joined #illumos
[10:22:13] <tsoome> ok, could you test https://illumos.org/rb/r/2350/
[10:33:42] <andyf> Yep!
[10:34:14] <tsoome> I can provide git format-patch if needed:D
[10:34:34] <andyf> The patch from RB should be fine for this,
[10:34:50] <andyf> and I can test in kvm at least
[11:21:50] <tsoome> btw, there is one more way to check - you can load modules manually or by entering start; then lsmod -s will show the addresses and hashes
[11:47:23] <Reinhilde> .../sbin/zpool cites GRUB as the reason ZFS pools on illumos cannot extend over two devices.
[11:47:27] <Reinhilde> at least, ZFS root pools.
[11:48:54] <Reinhilde> As I understand it, the FreeBSD loader (which OmniOS uses) has no problem with multi-device pools, so long as it knows where /boot/kernel/kernel is.
[12:00:06] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[12:03:41] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has quit IRC (Ping timeout: 276 seconds)
[12:07:04] *** tsoome <tsoome!~tsoome@148-52-235-80.sta.estpak.ee> has joined #illumos
[12:20:00] *** ed209 <ed209!~ed209@165.225.128.67> has quit IRC (Remote host closed the connection)
[12:20:08] *** ed209 <ed209!~ed209@165.225.128.67> has joined #illumos
[12:22:33] <andyf> tsoome - https://paste.ec/paste/FTLiL51R#sIvdNz4uQBkIgrd8Co15kkvpzQmZxJ2vLmZ7dHpS7Nw
[12:23:18] <andyf> it still does not boot :(
[12:28:59] <tsoome> ok.
[12:31:18] <tsoome> and no messages at all with boot -B prom_debug=true ?
[12:33:22] <tsoome> Reinhilde: you mean stripe? the old comments in sources are referring to grub because grub really does limit things, but it is not only grub, the multi-vdev boot pool needs kernel update too (LeftWing has patch in work).
[12:34:00] <Reinhilde> tsoome: i don't know if i mean zstripe or something else
[12:36:04] <tsoome> if you run zdb, you will see vdev_children: 1 at head, just before vdev_tree:
[12:37:22] <tsoome> if that number is not 1, we can not boot (except when that pool has spare or cache)
[12:37:41] <tsoome> bot loader can read it, but our kernel can not.
[12:37:51] <tsoome> s/bot/boot/
[12:39:47] <Reinhilde> that sucks major balls.
[12:40:17] <tsoome> that depends.
[12:40:42] <tsoome> that limit has been there since 2005
[12:40:55] <tsoome> (in public, that is)
[12:42:39] <andyf> tsoome no.. https://paste.ec/paste/0FANnM5T#DWPxijMw-3F9diwZr8yyEFGzO0eh9MA70gfphDm+myC
[12:42:51] <andyf> (sorry for the sporadic replies, I'm getting ready to leave to catch a flight)
[12:43:51] <tsoome> which VM setup is it? I only have plain qemu and it is ok...
[12:43:58] <Reinhilde> tsoome: is there any technical reason we can't boot when vdev_children>1
[12:44:11] <andyf> It's KVM, but I think it is hanging in my set_resolution word.. I'll try taking that out
[12:44:16] <tsoome> as i wrote, it is limit with out kernel
[12:44:25] <tsoome> our*
[12:45:25] <andyf> tsoome - yes, it's hanging there
[12:46:05] <tsoome> in your word?
[12:46:28] <andyf> well, if I redefine the word as just ': set_resolution 2drop ;', then it boots
[12:46:54] <tsoome> if you are on ok prompt, does framebuffer set xx work?
[12:47:01] <andyf> yes, that works fine
[12:47:15] <andyf> but not s" boot_resolution" set_resolution.
[12:47:25] <andyf> that seems to be because the string does not go on the stack
[12:47:47] <tsoome> you were using evaluate?
[12:48:05] <andyf> yes - s" framebuffer set " 2swap strcat evaluate
[12:48:38] <andyf> (works under bhyve, fwiw..)
[12:49:22] <tsoome> there is also other way, like: s” 1024x768” s” set” 2 framebuffer
[12:49:25] *** psarria <psarria!~psarria@209.red-79-146-100.dynamicip.rima-tde.net> has joined #illumos
[12:49:49] <Reinhilde> tsoome: yes, but is there a reason it has to be that way?
[12:49:57] *** psarria_ <psarria_!~psarria@209.red-79-146-100.dynamicip.rima-tde.net> has quit IRC (Ping timeout: 240 seconds)
[12:50:15] <Reinhilde> or is the limit only so because it can be made so
[12:50:22] <andyf> tsoome - I don't think framebuffer supports that way..
[12:50:39] <andyf> I know some of the commands work postfix..
[12:51:12] <tsoome> that is, you push the arguments to stack, then number of arguments then call the word. that will work with all “builtin” commands.
[12:51:56] <andyf> https://paste.ec/paste/AG5QTGEp#O08rXE6r+TdJXRqdMMIz7EV-Nf24UbxgRNys998+Vpy
[12:54:07] <tsoome> Reinhilde: the roots are from sparc world where you get device tree from prom; so they did build device name cache and kernel startup is using that cache, and is using device names from the pool label (see zdb output) to find the disks. To remove that limit, we need to enumerate visible disks and scan the content to build up the pool config (like boot loader is doing).
[12:54:38] <Reinhilde> ah
[12:55:20] <tsoome> andyf: yes, there there is a catch again about interpreting and compiling:) let me compose you an example:)
[12:55:50] <andyf> ok, works fine if I define a word
[12:55:59] <tsoome> yep.
[12:56:04] <andyf> thanks, I'll try that instead of evaluate
[12:57:18] <tsoome> it should be possible to get working with evalueate too, just needs to be careful..
[12:57:58] <tsoome> but, wait a sec, so in your case, was it always about that bad evaluate?
[12:58:29] <andyf> it's possible, yes
[12:58:38] <andyf> without the evaluate it is working fine, thank you
[12:59:01] <tsoome> ok, btw why do you want to change resolution that late?
[12:59:52] <Reinhilde> what sort of configuration, if even possible, would be needed to run kernel off UFS and then have the root pool be on ZFS (to theoretically allow for root pools that are not compliant)?
[13:00:17] <tsoome> Reinhilde: yes we can boot off of ufs. (or nfs)
[13:00:57] *** psarria <psarria!~psarria@209.red-79-146-100.dynamicip.rima-tde.net> has quit IRC (Ping timeout: 240 seconds)
[13:01:58] <tsoome> except that is not supported by tools like beadm and pkg (in oi, omnios), pkg still can be used but not in live root file system.
[13:02:11] <Reinhilde> tsoome: but can we have just /boot on ufs, and zfs for the rest of /?
[13:02:50] *** psarria <psarria!~psarria@209.red-79-146-100.dynamicip.rima-tde.net> has joined #illumos
[13:02:58] <tsoome> that is also possible, but does not really have much sense because of the overhead of maintaining such setup
[13:03:27] <Reinhilde> it is, interestingly, what i do on freebsd on my home computer (a relic of dual booting with debian)
[13:03:35] <tsoome> smartos has kernel and boot archive on pcfs for example (usb stick).
[13:04:33] <Reinhilde> (i load using GRUB instead of /boot/loader.efi)
[13:05:29] <tsoome> i see
[13:09:36] <tsoome> loader or grub in that sense is no difference really
[13:09:58] <tsoome> both can read ufs, pcfs and zfs
[13:10:46] <Reinhilde> is SMF intended to ever theoretically be able to run on any OS other than SunOS 5.10+?
[13:11:49] <tsoome> it is software - if you are ok with license, you can port it
[13:13:22] <tsoome> there are some concepts specific for SunOS (like contracts for processes), but those are porting issues anyhow.
[13:13:29] <Reinhilde> aye
[13:13:59] <Reinhilde> so either that'd need to be dropped, or contracts ported to the target kernel.
[13:14:06] <tsoome> the real life issue is actually not about porting, but if the operating system logic accept it.
[13:14:59] <Reinhilde> i feel like systemd was an attempt to port smf to linux without using any smf code. :/
[13:15:57] <Reinhilde> because 'cddl isn't compatible with gpl reeeeeeeeeEEE€'
[13:16:00] <tsoome> it certainly had some influences, but systemd is about something else than SMF
[13:16:19] <Reinhilde> aye.
[13:17:22] <tsoome> also the freebsd had some attempt to use launchd from osx, but it did not work out
[13:18:27] <tsoome> they have entire system built around rc scipts and you can not just push that aside.
[13:18:45] <Reinhilde> aye.
[13:19:44] <tsoome> in a way the SMF was introduced in right place at right time - it was possible to keep rc scripts when needed and gradually move to use new logic.
[14:05:20] <andyf> tsoome - because the loader menu and graphics looks best at 800x600, but I want to allow a better resolution for boot.
[14:05:20] <andyf> tsoome - It could be done earlier..
[14:05:27] *** BH23 <BH23!~BH23@193.117.206.132> has quit IRC (Ping timeout: 245 seconds)
[14:08:01] *** Teknix <Teknix!~pds@69.41.134.110> has quit IRC (Read error: Connection reset by peer)
[14:08:32] *** kev009 <kev009!~kev009@ip72-222-200-117.ph.ph.cox.net> has quit IRC (Read error: Connection reset by peer)
[14:09:10] *** Teknix <Teknix!~pds@69.41.134.110> has joined #illumos
[14:09:27] *** kev009 <kev009!~kev009@ip72-222-200-117.ph.ph.cox.net> has joined #illumos
[14:27:10] *** BH23 <BH23!~BH23@193.117.206.132> has joined #illumos
[14:33:21] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has joined #illumos
[14:38:35] *** merzo <merzo!~merzo@185.39.197.205> has joined #illumos
[14:52:46] *** yuripv <yuripv!~yuripv@217.146.82.119> has quit IRC (Quit: leaving)
[15:23:08] <tsoome> ok
[15:52:32] *** merzo <merzo!~merzo@185.39.197.205> has quit IRC (Ping timeout: 245 seconds)
[15:54:01] *** danmcd <danmcd!~danmcd@static-71-174-113-16.bstnma.fios.verizon.net> has quit IRC ()
[16:09:38] *** jcea <jcea!~Thunderbi@2001:41d0:1:8a82:7670:6e00:7670:6e00> has joined #illumos
[16:23:53] *** _alhazred <_alhazred!~Alex@mobile-access-bcee21-113.dhcp.inet.fi> has joined #illumos
[16:25:02] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has quit IRC (Ping timeout: 245 seconds)
[16:26:09] *** MilkmanDan <MilkmanDan!~dan@wilug/expat/MilkmanDan> has joined #illumos
[16:33:34] *** danmcd <danmcd!~danmcd@static-71-174-113-16.bstnma.fios.verizon.net> has joined #illumos
[16:40:24] *** Yogurt <Yogurt!~Yogurt@c-73-189-45-147.hsd1.ca.comcast.net> has joined #illumos
[16:41:58] <KungFuJesus> what is the proper way to blink an LED or otherwise alert a disk with an mpt_sas3 based controller connected to sas drives on a sas backplane?
[16:42:19] <KungFuJesus> I've found luxadm, cfgadm with the -x led option, and I think there might be a way of the proprietary LSI tools
[16:42:23] <KungFuJesus> which ones will actually work?
[16:44:30] <KungFuJesus> I haven't had any drives actually fail yet but I'm trying to figure out a procedure to replace them when they do
[16:46:46] *** _alhazred <_alhazred!~Alex@mobile-access-bcee21-113.dhcp.inet.fi> has quit IRC (Remote host closed the connection)
[16:47:13] *** _alhazred <_alhazred!~Alex@mobile-access-bcee21-113.dhcp.inet.fi> has joined #illumos
[16:47:55] *** Yogurt <Yogurt!~Yogurt@c-73-189-45-147.hsd1.ca.comcast.net> has quit IRC (Remote host closed the connection)
[16:49:36] *** Kurlon <Kurlon!~Kurlon@cpe-67-253-141-249.rochester.res.rr.com> has quit IRC (Remote host closed the connection)
[16:50:13] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[16:57:10] *** Yogurt <Yogurt!~Yogurt@c-73-189-45-147.hsd1.ca.comcast.net> has joined #illumos
[17:01:17] *** Yogurt <Yogurt!~Yogurt@c-73-189-45-147.hsd1.ca.comcast.net> has quit IRC (Ping timeout: 240 seconds)
[17:02:42] <LeftWing> KungFuJesus: Does the SAS backplane do SES or is it passive?
[17:03:01] <LeftWing> (Do you have any devices in "/dev/es"?)
[17:07:55] <tsoome> LeftWing: could you check if https://www.illumos.org/rb/r/2350/ does help your case or do we need to investigate more?
[17:19:56] *** yuripv <yuripv!~yuripv@217.146.82.119> has joined #illumos
[17:31:11] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-149.net.upcbroadband.cz> has quit IRC (Quit: Leaving.)
[17:32:21] <gitomat> [illumos-gate] 11752 inet/cc.h should be shipped -- Andy Fiddaman <omnios at citrus-it dot co.uk>
[17:32:51] <ptribble> Yikes! https://openjdk.java.net/jeps/362
[17:32:55] <tsoome> danmcd: ping:)
[17:35:00] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[17:35:51] <tsoome> ptribble: no developers means dead code means breaks on overall development. should be familiar for us too.
[17:39:58] <rmustacc> Folks need to get involved is what it means.
[17:40:14] <tsoome> yep
[17:40:19] <rmustacc> And help get all the openjdk enabling that jperkin has done back to them.
[17:40:21] <rmustacc> And others.
[17:40:52] <KungFuJesus> LeftWing: it has ses0-3
[17:40:53] <rmustacc> It's unclear if they know if there's actually a gcc port for us.
[17:47:04] <KungFuJesus> It's a bit weird that Solaris/x86 is being deprecated, I would think keeping the JVM maintained for that isn't as much effort as it is for SPARC
[17:48:11] <tsoome> it does not really matter if x86 or sparc, it needs developer for solaris..
[17:49:04] <KungFuJesus> Is Oracle attempting to keep it alive?
[17:49:09] <tsoome> no
[17:49:12] <yuripv> why should we care about solaris?
[17:49:38] <tsoome> oracle is sending out every signal the solaris is dead
[17:49:44] <rmustacc> If the plan is to rely on Oracle Solaris for something we need, that's not really a good plan.
[17:51:12] <rmustacc> The same way folks have stepped up for golang and other languages, folks need to step up for Java. There's no really other way around it.
[17:51:19] <KungFuJesus> LeftWing: how does one use fmtopo to make this work? Or will FMA just "work" and magically mark the drive as failed on the backplane? What if it it's not removed but I need to identify it?
[17:51:42] <andyf> rmustacc - you're right though, they might not know that we build it with gcc which should be easier to maintain at least
[17:52:09] <rmustacc> andyf: Well, or for example, easy ways to uild VMs, do CI, etc.
[17:52:18] <rmustacc> That's part of stuff that folks have worked on for things like postgres, golang, etc.
[17:52:30] <rmustacc> It's a number of things, but requires a group to reach out.
[17:53:16] <rmustacc> Unfortunately, I don't really see a simpler answer.
[17:53:33] <KungFuJesus> it also seems there's no ses-enclosure listed in fmtopo's output
[17:54:05] <rmustacc> KungFuJesus: Do you see disk nodes under bays?
[17:54:11] <rmustacc> The SES enclosure isn't listed directly?
[17:54:17] <rmustacc> *.
[17:54:50] <rmustacc> Because it's just a chip somewhere and not represnted in the hardware chassis (e.g. disks wouldn't be under the ses device, because they aren't physically)
[17:59:29] <gitomat> [illumos-gate] 11579 e1000g: cast between incompatible function types -- Toomas Soome <tsoome at me dot com>
[17:59:46] <tsoome> and thanks btw:)
[18:00:10] <KungFuJesus> rmustacc: /usr/lib/fm/fmd/fmtopo | grep -i ses
[18:00:13] <KungFuJesus> comes back empty
[18:00:33] <rmustacc> Right, you wouldn't find anything there.
[18:00:37] <rmustacc> At least, IIRC.
[18:00:46] <rmustacc> My question was do you see nodes called disks and bays.
[18:00:53] <rmustacc> yuripv: I'll take a look at 8993.
[18:00:55] <igork> yuripv: about your ping - do you have list of tests/reports what are done with testing 8993?
[18:01:37] <KungFuJesus> /usr/lib/fm/fmd/fmtopo | egrep -e '(disk|bay)'
[18:01:40] <KungFuJesus> comes back empty as well
[18:01:52] *** BH23 <BH23!~BH23@193.117.206.132> has quit IRC (Ping timeout: 264 seconds)
[18:01:53] <rmustacc> OK. Not sure off hand then.
[18:02:26] <rmustacc> May want to check if ses is actually enumerating anything with the sestopo command.
[18:02:39] <KungFuJesus> How is it supposed to work? Clearly FMA did some magic in the fishworks appliance (looks like there was some XML for that particular chassis) in order to show failed disks
[18:03:07] <rmustacc> Well, we always had per-system maps for a given platform that we used at Joyent.
[18:03:09] <KungFuJesus> ahhh, sestopo is not on here
[18:03:13] <rmustacc> But I don't recall if we had to call out SES directly.
[18:03:31] <rmustacc> In those maps.
[18:04:01] <yuripv> igork: what kind of list do you expect?
[18:04:45] <igork> yuripv: how you tested ? maybe you have some tests/steps? no info on bug report and rb
[18:04:57] <KungFuJesus> rmustacc: looks like sestopo is in system/io/tests?
[18:05:28] <igork> yuripv: i'm interested in your tests before and after your changes
[18:05:42] <yuripv> igork: acting as RTI advocate?
[18:05:52] <igork> nope
[18:06:05] <igork> just question
[18:06:24] <yuripv> well, we have regex tests in libc test suite, works for you?
[18:06:32] <KungFuJesus> I'm multipathed in this, so I'd expect ses0-ses3 to be identical with sestopo. Looks like it's finding these nodes: Element Type: ARRAY_DEVICE
[18:06:46] <igork> yuripv: i didn't try it
[18:06:59] <KungFuJesus> and expanders, and devices under the expanders
[18:07:02] <yuripv> igork: I mean, does it answer your question?
[18:07:27] <rmustacc> KungFuJesus: I would look at other maps for platforms and see if we need to call out SES directly in them. I don't recall what's in the default map.
[18:07:29] <igork> yuripv: if you can - put info to rb. yes - it is answer and just add results to bug report
[18:08:18] <KungFuJesus> rmustacc: so that's an interesting distinction - running fmtopo as root does list them
[18:08:53] <yuripv> igork: that's not helpful
[18:09:13] <rmustacc> KungFuJesus: Ah, well if you're not running fmtopo as root, you're definitely not going to see a lot.
[18:09:38] <KungFuJesus> ok, so given that I'm seeing bays in fmtopo, how is this supposed to work?
[18:09:50] <KungFuJesus> (bays+disks)
[18:09:57] <igork> yuripv: just show result about: you have no regressions before and after your changes
[18:10:25] <igork> the same list of tests what you used
[18:10:27] <rmustacc> KungFuJesus: In theory if you see bays, you should see LEDs under bays and disks nodes under the bays.
[18:10:33] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[18:12:51] <gitomat> [illumos-gate] 11716 loader: add memalign() -- Toomas Soome <tsoome at me dot com>
[18:12:54] <KungFuJesus> Yes, I do. And yes, I understand the bay numbers are _probably_ enough for me to identify where the failed disk is
[18:13:04] <KungFuJesus> however, how does it work with the LEDs?
[18:13:37] <KungFuJesus> because, 1.) blinken lights are cool, 2.) It's a lot easier to explain to somebody the disk LED that is blinking or a different color needs to be pulled
[18:13:45] <rmustacc> Well, do you see the led's listed under the nodes?
[18:13:49] <KungFuJesus> yep
[18:13:56] <rmustacc> OK, so you can use fmtopo to manually light them.
[18:14:08] <rmustacc> Though if ZFS fails the disk, FMA should turn it on automatically.
[18:14:43] <rmustacc> Can you gist one of your fmtopo LED blobs with the -V option?
[18:15:00] <KungFuJesus> they are listed as "indicator", I assume that's LED, right?
[18:15:38] <rmustacc> Yeah.
[18:16:20] <KungFuJesus> https://pastebin.com/T8DgcVka
[18:17:06] <rmustacc> If you do something like fmtopo -P facility.mode=uint32:1 hc://:product-id=SMC-SC846S:server-id=:chassis-id=5003048017d2467f/ses-enclosure=0/bay=20?indicator=ident
[18:17:11] <rmustacc> That should turn on the ident LED.
[18:17:19] <rmustacc> And similarly setting it to 0 should turn it off.
[18:17:59] <KungFuJesus> and FMA, when it faults a disk for too many errors, will set "fail" automatically?
[18:18:09] <rmustacc> It should, yes.
[18:18:16] <KungFuJesus> I wonder what ok2rm looks like on this
[18:18:17] <rmustacc> But if not you can always manually do it.
[18:19:47] <KungFuJesus> completely different ball game when using proper SAS stuff - man using the SATA controller with a plain old SATA backplane feels stupid now
[18:21:11] <KungFuJesus> there's also a "temp" sensor node, how does this interact with FMA?
[18:21:49] <rmustacc> KungFuJesus: So that's on the disk node, right?
[18:21:56] <KungFuJesus> yep
[18:22:06] <rmustacc> So there's something called the fru monitor which periodically looks at various things and the corresponding thresholds.
[18:22:19] <rmustacc> And will take action when various levels are tripped.
[18:22:45] <KungFuJesus> so this will show up in fmdump -e, -i, or -I? And which actions are taken and how do I configure it?
[18:22:52] <rmustacc> Though not all of them are necessairily actively monitored.
[18:22:59] <rmustacc> Like the CPU ones aren't today.
[18:23:09] <rmustacc> If you have an overtemp it will show up as an ereport, I believe.
[18:23:10] <KungFuJesus> fault management in solaris/illumos is so delightfully sophisticated and yet underdocumented
[18:23:17] <rmustacc> It is unfortunately, sorry.
[18:23:47] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 245 seconds)
[18:23:49] <rmustacc> I don't recall the behavior on overtemp.
[18:23:56] <rmustacc> It is enabled by default, so there's nothing to opt into.
[18:23:57] <KungFuJesus> ok, well I've found the super secret arguments (missing from the man page but in the -h help) with fmdump to get those hivals, info, and error logs
[18:24:23] <rmustacc> I think it uses the thresholds from the disk to determine what action to take.
[18:24:28] <KungFuJesus> it doesn't seem like faulting the device from the pool is the proper solution to it, but I'm not sure what else it could do
[18:26:51] *** man_u <man_u!~manu@manu2.gandi.net> has quit IRC (Quit: man_u)
[18:41:08] <gitomat> [illumos-gate] 11749 nfs4_end_*_seqid_sync() should call cv_signal() -- Marcel Telka <marcel at telka dot sk>
[18:44:33] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC (Remote host closed the connection)
[18:44:53] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[18:44:56] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC (Remote host closed the connection)
[18:45:43] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[18:46:39] *** Yogurt_ <Yogurt_!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[18:46:39] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC (Read error: Connection reset by peer)
[18:54:46] *** merzo <merzo!~merzo@185.39.197.205> has joined #illumos
[18:59:17] *** merzo <merzo!~merzo@185.39.197.205> has quit IRC (Ping timeout: 240 seconds)
[19:03:45] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has joined #illumos
[19:07:52] *** nbhauke <nbhauke!~hauke@Dachstein.nt.e-technik.tu-darmstadt.de> has quit IRC (Quit: nbhauke)
[19:08:33] <KungFuJesus> rmustacc: is ChipDie an indication that an expander chip has died for dual expanders?
[19:08:38] <KungFuJesus> If so, that's also pretty awesome
[19:09:16] <danmcd> @tsoome pardon my latency. I just saw this. Ouch.
[19:09:42] <tsoome> :=) np at all:)
[19:09:43] * danmcd sometimes cynically thinks the correct answer should be to trash poold in -gate.
[19:10:10] <danmcd> But rmustacc stated it properly, we need someone to step up. Someone who knows java. SHould we mention this on mailing lists?
[19:10:13] <danmcd> (I think we should.)
[19:13:41] <tsoome> the other question would be, does illumos == solaris in that specific case…
[19:14:02] <danmcd> Yeah, see efforts in go and Rust about how to address this.
[19:18:18] <danmcd> Sent to dev list, and even tweeted about it.
[19:20:28] <yuripv> (just IMO) trashing poold (and all of the java stuff) is good idea regardless of openjdk support; and keeping illumos (separate from solarish I guess) support sounds like a must
[19:20:30] <rmustacc> danmcd: I think the important tihng is to call folks to action and having someone be willing to organize effort.
[19:21:02] <danmcd> Agreed. My tweet said that explicitly, and my developer's list mail asks that at the bottom.
[19:21:15] <rmustacc> OK. That's good.
[19:25:43] <danmcd> https://twitter.com/kebesays/status/1177633425769058305
[19:48:03] *** _alhazred <_alhazred!~Alex@mobile-access-bcee21-113.dhcp.inet.fi> has quit IRC (Read error: Connection reset by peer)
[19:51:32] *** _alhazred <_alhazred!~Alex@mobile-access-bceec9-118.dhcp.inet.fi> has joined #illumos
[19:57:49] *** Yogurt_ <Yogurt_!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has quit IRC (Remote host closed the connection)
[19:59:18] *** Yogurt <Yogurt!~Yogurt@104-7-67-228.lightspeed.sntcca.sbcglobal.net> has joined #illumos
[19:59:35] <KungFuJesus> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms <-- what's funny is how long lived sparcv9 continues to be for them
[20:00:28] <KungFuJesus> are they trying to make a play to hook customers in with their fully proprietary stack, only?
[20:00:39] <danmcd> Wouldn't surprise me...
[20:01:12] <KungFuJesus> I mean don't get me wrong, I think SPARC hardware is cool, I just didn't think Oracle would bet the farm on it
[20:07:30] *** alanc <alanc!~alanc@129.157.69.53> has quit IRC (Remote host closed the connection)
[20:31:46] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has joined #illumos
[20:39:34] <gitomat> [illumos-gate] 11667 remove duplicate lz4 implementations -- Toomas Soome <tsoome at me dot com>
[20:44:51] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has quit IRC (Ping timeout: 240 seconds)
[20:47:02] *** sjorge <sjorge!~sjorge@unaffiliated/sjorge> has joined #illumos
[20:52:26] *** yuripv <yuripv!~yuripv@217.146.82.119> has quit IRC (Quit: leaving)
[21:01:11] *** jimklimov <jimklimov!~jimklimov@ip-86-49-254-149.net.upcbroadband.cz> has joined #illumos
[21:18:41] *** slx86 <slx86!~Thunderbi@92-110-137-173.cable.dynamic.v4.ziggo.nl> has joined #illumos
[21:22:29] *** slx86 <slx86!~Thunderbi@92-110-137-173.cable.dynamic.v4.ziggo.nl> has quit IRC (Client Quit)
[21:24:30] *** nbhauke <nbhauke!~hauke@p4FDECDF2.dip0.t-ipconnect.de> has joined #illumos
[21:45:23] *** nbhauke <nbhauke!~hauke@p4FDECDF2.dip0.t-ipconnect.de> has quit IRC (Quit: nbhauke)
[21:50:55] *** nbhauke <nbhauke!~hauke@p4FDECDF2.dip0.t-ipconnect.de> has joined #illumos
[22:00:19] *** _alhazred <_alhazred!~Alex@mobile-access-bceec9-118.dhcp.inet.fi> has quit IRC (Remote host closed the connection)
[22:00:46] *** _alhazred <_alhazred!~Alex@mobile-access-bceec9-118.dhcp.inet.fi> has joined #illumos
[22:03:43] * despair86 reads JEP362
[22:03:49] <despair86> y i k e s
[22:03:50] <despair86> i
[22:03:51] <despair86> k
[22:03:51] <despair86> e
[22:03:52] <despair86> s
[22:04:50] * despair86 uses liberica jdk
[22:13:17] <ptribble> Yeah, I sent a message to the Liberica folks to try and gauge their thoughts.
[22:13:41] <ptribble> They're far more advanced in their JDK support than either Zulu or Adopt
[22:14:01] <ptribble> who haven't really got past JDK8
[22:15:28] <rmustacc> Hopefully we can leverage some of the work that has also gone into all the pkgsrc stuff over the years which has recent JDKs, IIUC.
[22:20:00] *** ed209 <ed209!~ed209@165.225.128.67> has quit IRC (Remote host closed the connection)
[22:20:07] *** ed209 <ed209!~ed209@165.225.128.67> has joined #illumos
[22:22:14] <jperkin> for anyone interested, https://github.com/joyent/pkgsrc-joyent/tree/master/openjdk11 (and 9+10)
[22:23:34] <rmustacc> Maybe interested folks can work with that and openjdk upstream to try and get us back on track?
[22:23:56] <ptribble> Have you tried jdk13 yet? (Having a glitch or two there myself.)
[22:24:39] <jperkin> ptribble: no, sorry
[22:38:05] <despair86> i'm getting the latest liberica rn (i run a minecart server for some friends)
[22:38:26] <despair86> > no sun port
[22:38:32] * despair86 screams internally
[22:38:41] *** alanc <alanc!~alanc@129.157.69.36> has joined #illumos
[22:38:42] *** _alhazred <_alhazred!~Alex@mobile-access-bceec9-118.dhcp.inet.fi> has quit IRC (Remote host closed the connection)
[22:39:10] *** _alhazred <_alhazred!~Alex@mobile-access-bceec9-118.dhcp.inet.fi> has joined #illumos
[22:44:49] *** _alhazred <_alhazred!~Alex@mobile-access-bceec9-118.dhcp.inet.fi> has quit IRC (Remote host closed the connection)
[22:45:17] *** _alhazred <_alhazred!~Alex@mobile-access-bceec9-118.dhcp.inet.fi> has joined #illumos
[22:49:41] *** jfqd <jfqd!~jfqd@pD9E427D9.dip0.t-ipconnect.de> has quit IRC (Ping timeout: 268 seconds)
[22:50:19] *** jfqd <jfqd!~jfqd@p4FF69AE6.dip0.t-ipconnect.de> has joined #illumos
[22:58:04] *** yuripv <yuripv!~yuripv@217.146.82.119> has joined #illumos
[23:00:04] *** gh34 <gh34!~textual@cpe-184-58-181-106.wi.res.rr.com> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
[23:06:20] *** Kurlon <Kurlon!~Kurlon@bidd-pub-03.gwi.net> has quit IRC (Ping timeout: 268 seconds)
[23:14:44] <dsockwell> how much RAM does minecart use up these days
[23:16:27] <despair86> i have it capped to 8GB on a 9GB smartos container, and at peak, i've seen it go up to 5-6GB. the game itself can still fit in 1.5-2GB on 32-bit java, and the launcher itself sets the heap limit to 2GB by default
[23:18:03] *** clapont <clapont!~clapont@unaffiliated/clapont> has quit IRC (Ping timeout: 268 seconds)
[23:22:09] *** ptribble <ptribble!~ptribble@cpc92716-cmbg20-2-0-cust138.5-4.cable.virginm.net> has quit IRC (Quit: Leaving)
[23:35:27] <igork> does anyone know how to debug boot on sparc ?
[23:35:30] <igork> i can see: ERROR: Last Trap: Fast Data Access MMU Miss
[23:35:35] <igork> https://paste.dilos.org/?94b4c171d56fc411#/LyGWyg61rNJZrQR9pbNVPRp+WfsB7nxK+poh57lAJ4=
[23:35:50] <igork> first part - failed boot
[23:35:56] <wilbury> kernel failed to load
[23:36:03] <igork> next part - from line 28 - good boot
[23:36:54] <igork> wilbury: i know about kernel boot - but is it 'unix' failed to read boot archive or something else?
[23:37:09] <igork> it is build by gcc6 + SunAS
[23:38:06] <igork> i'm interested in steps how to try debug it
[23:42:49] <wilbury> ah, you have to specify a dataset to boot from
[23:42:56] <wilbury> or use boot -L to list possible datasets
[23:43:20] <wilbury> boot -L will list boot environments
[23:43:34] <igork> wilbury: i know how to boot to correct bootable BE. i try to debug new build
[23:44:56] *** clapont <clapont!~clapont@unaffiliated/clapont> has joined #illumos
[23:44:59] <wilbury> "ERROR: Last Trap: Fast Data Access MMU Miss" means that a required file can't be found or read.
[23:45:11] <igork> it is interest
[23:45:19] <gitomat> [illumos-gate] 11711 verify_pool missing from zfs-test suite -- Jerry Jelinek <jerry.jelinek at joyent dot com>
[23:45:19] <igork> how to try to identify - what the file?
[23:47:40] <wilbury> igork: problem with module /kernel/misc/sparcv9/ctf module
[23:48:16] <igork> why?
[23:49:12] <igork> take a look good boot - line 46 on my paste - it is line similar to bad boot at line 19
[23:50:18] <wilbury> try boot -vVkd
[23:50:58] <wilbury> or boot -vVkd -m verbose
[23:51:14] <wilbury> or even boot -vV -m verbose (without debugger)
[23:52:36] <igork> thanks, i'll try
[23:52:47] <igork> but i can't load new build to kmdb
[23:53:42] <wilbury> try even boot -kdv -m milestone=none
[23:55:10] <wilbury> which sysfw and ilom et al, do you have?
[23:55:18] <igork> yes
[23:55:19] <wilbury> 4.33.6.f
top

   September 27, 2019  
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | >