[oi-dev] gcc version for kernel modules

[Jean-Pierre André]

I am preparing an update to the fuse kernel module. Best if using
the same compiler as the kernel, and gcc7 is currently enforced.

Is this still the correct version ?

Regards,

Jean-Pierre


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Happy birthday Micral N!

[Jean-Pierre André]

Hi Aurélien,

FYI, I used a Micral M version, which was a multiprocessor one,
with four 8080 processors at 2MHz.

Jean-Pierre

aurelien.larc...@gmail.com wrote on 1/15/23 9:57 PM:

Hello,
Nothing related to OpenIndiana or illumos but today 15th of January is the 50th 
anniversary of the Micral N:

https://en.m.wikipedia.org/wiki/Micral

I just thought it would be interesting to those who like trivia about computer 
history.

Kind regards,

Aurélien
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev





___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Panic on using fuse with todays "pkg update"

[Jean-Pierre André]

Gordon Ross wrote on 9/13/22 1:01 AM:

Or improve its portability (does it really need to look inside proc_t?)


This is only needed to get the pid of the current process, through
"curproc->p_pidp->pid_id", with curproc defined as threadp()->t_procp
The pid is passed to user level so that it can determine the credentials
of the caller (e.g. the list of groups to which it belongs).

A reasonable way is to define a curpid() system function (not a macro
nor an inliner), similar to vn_is_opened() or vn_has_other_opens()
which are used to hide the locations of v_rdcnt and v_wrcnt located
in struct vnode beyond the immutable locations.

There would also be other fields to consider, in particular p_rctls
from struct proc.

Jean-Pierre




On Mon, Sep 12, 2022 at 7:00 PM Gordon Ross  wrote:


We could integrate fuse into illumos to avoid that kind of thing.

On Mon, Sep 12, 2022 at 5:02 AM Jean-Pierre André
 wrote:


IMHO this is the culprit :

--- ../oi-include/sys/thread.h  2020-11-19 19:37:31.170054900 +0100
+++ thread.h.2  2022-09-12 10:48:43.877644300 +0200
@@ -158,7 +158,6 @@
  struct _kthread *t_intr; /* interrupted (pinned) thread */
  uint64_tt_intr_start;   /* timestamp when time slice
began */
  kt_did_tt_did;  /* thread id for kernel debuggers */
-   caddr_t t_tnf_tpdp; /* Trace facility data pointer */
  struct _kcpc_ctx *t_cpc_ctx;/* performance counter context */
  struct _kcpc_set *t_cpc_set;/* set this thread has bound */

Which changes the location of t_procp a few lines below in
struct _kthread

So have to recompile and set dependency for this to not occur again.

Jean-Pierre


Jean-Pierre André wrote on 9/12/22 8:56 AM:

This is accessing t_procp->p_pidp, so it looks very much like the
kernel has been recompiled after  or 
have been changed, without the fuse kernel module being recompiled
(or at least being downloaded).

You probably only need to recompile with current headers and download.

This has already occurred before. Where is the dependency preventing
this from occurring missing ?

Jean-Pierre

Stephan Althaus wrote on 9/11/22 10:13 PM:

Hello!

I made a pkg update today, and was surprised to get a panic on using
my fuse file system "exfat" on USB3, which i use for 1-2 years now.

Maybe some illumos patch is causing this (?)

I have build the exfat bits on the new BE, to no success..


$ fmdump -Vp -u a9df4d73-dc1f-e33a-e733-af1e5693a9fc
TIME UUID SUNW-MSG-ID
Sep 11 2022 19:52:06.085966000 a9df4d73-dc1f-e33a-e733-af1e5693a9fc
SUNOS-8000-KL

TIME CLASS ENA
Sep 11 19:52:04.1840 ireport.os.sunos.panic.savecore_failure
0x
Sep 11 19:52:03.9741 ireport.os.sunos.panic.dump_pending_on_device
0x

nvlist version: 0
  version = 0x0
  class = list.suspect
  uuid = a9df4d73-dc1f-e33a-e733-af1e5693a9fc
  code = SUNOS-8000-KL
  diag-time = 1662918725 999156
  de = fmd:///module/software-diagnosis
  fault-list-sz = 0x1
  fault-list = (array of embedded nvlists)
  (start fault-list[0])
  nvlist version: 0
  version = 0x0
  class = defect.sunos.kernel.panic
  certainty = 0x64
  asru =
sw:///:path=/var/crash/dell/.a9df4d73-dc1f-e33a-e733-af1e5693a9fc
  resource =
sw:///:path=/var/crash/dell/.a9df4d73-dc1f-e33a-e733-af1e5693a9fc
  savecore-succcess = 0
  failure-reason = pwrite: No such device or address
  os-instance-uuid = a9df4d73-dc1f-e33a-e733-af1e5693a9fc
  panicstr = BAD TRAP: type=e (#pf Page fault)
rp=fe003d79e850 addr=4 occurred in module "fuse" due to a NULL
pointer dereference
  panicstack = unix:die+c6 () | unix:trap+10f7 () |
unix:cmntrap+e9 () | fuse:get_filehandle+52d () | fuse:fuse_open+6e ()
| genunix:fop_open+96 () | genunix:vn_openat+20c () |
genunix:copen+421 () | genunix:openat+29 () |
unix:brand_sys_syscall+1fe () |
  crashtime = 1662918635
  panic-time = 11 September 2022 at 19:50:35 CEST CEST
  (end fault-list[0])

  fault-status = 0x1
  severity = Major
  __ttl = 0x1
  __tod = 0x631e2046 0x51fbcb0

Greetings,

Stephan


___



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Panic on using fuse with todays "pkg update"

[Jean-Pierre André]

IMHO this is the culprit :

--- ../oi-include/sys/thread.h  2020-11-19 19:37:31.170054900 +0100
+++ thread.h.2  2022-09-12 10:48:43.877644300 +0200
@@ -158,7 +158,6 @@
struct _kthread *t_intr; /* interrupted (pinned) thread */
uint64_tt_intr_start;   /* timestamp when time slice 
began */

kt_did_tt_did;  /* thread id for kernel debuggers */
-   caddr_t t_tnf_tpdp; /* Trace facility data pointer */
struct _kcpc_ctx *t_cpc_ctx;/* performance counter context */
struct _kcpc_set *t_cpc_set;/* set this thread has bound */

Which changes the location of t_procp a few lines below in
struct _kthread

So have to recompile and set dependency for this to not occur again.

Jean-Pierre


Jean-Pierre André wrote on 9/12/22 8:56 AM:

This is accessing t_procp->p_pidp, so it looks very much like the
kernel has been recompiled after  or 
have been changed, without the fuse kernel module being recompiled
(or at least being downloaded).

You probably only need to recompile with current headers and download.

This has already occurred before. Where is the dependency preventing
this from occurring missing ?

Jean-Pierre

Stephan Althaus wrote on 9/11/22 10:13 PM:

Hello!

I made a pkg update today, and was surprised to get a panic on using 
my fuse file system "exfat" on USB3, which i use for 1-2 years now.


Maybe some illumos patch is causing this (?)

I have build the exfat bits on the new BE, to no success..


$ fmdump -Vp -u a9df4d73-dc1f-e33a-e733-af1e5693a9fc
TIME UUID SUNW-MSG-ID
Sep 11 2022 19:52:06.085966000 a9df4d73-dc1f-e33a-e733-af1e5693a9fc 
SUNOS-8000-KL


   TIME CLASS ENA
   Sep 11 19:52:04.1840 ireport.os.sunos.panic.savecore_failure 
0x
   Sep 11 19:52:03.9741 ireport.os.sunos.panic.dump_pending_on_device 
0x


nvlist version: 0
 version = 0x0
 class = list.suspect
 uuid = a9df4d73-dc1f-e33a-e733-af1e5693a9fc
 code = SUNOS-8000-KL
 diag-time = 1662918725 999156
 de = fmd:///module/software-diagnosis
 fault-list-sz = 0x1
 fault-list = (array of embedded nvlists)
 (start fault-list[0])
 nvlist version: 0
 version = 0x0
 class = defect.sunos.kernel.panic
 certainty = 0x64
 asru = 
sw:///:path=/var/crash/dell/.a9df4d73-dc1f-e33a-e733-af1e5693a9fc
 resource = 
sw:///:path=/var/crash/dell/.a9df4d73-dc1f-e33a-e733-af1e5693a9fc

 savecore-succcess = 0
 failure-reason = pwrite: No such device or address
 os-instance-uuid = a9df4d73-dc1f-e33a-e733-af1e5693a9fc
 panicstr = BAD TRAP: type=e (#pf Page fault) 
rp=fe003d79e850 addr=4 occurred in module "fuse" due to a NULL 
pointer dereference
 panicstack = unix:die+c6 () | unix:trap+10f7 () | 
unix:cmntrap+e9 () | fuse:get_filehandle+52d () | fuse:fuse_open+6e () 
| genunix:fop_open+96 () | genunix:vn_openat+20c () | 
genunix:copen+421 () | genunix:openat+29 () | 
unix:brand_sys_syscall+1fe () |

 crashtime = 1662918635
 panic-time = 11 September 2022 at 19:50:35 CEST CEST
 (end fault-list[0])

 fault-status = 0x1
 severity = Major
 __ttl = 0x1
 __tod = 0x631e2046 0x51fbcb0

Greetings,

Stephan


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Panic on using fuse with todays "pkg update"

[Jean-Pierre André]

This is accessing t_procp->p_pidp, so it looks very much like the
kernel has been recompiled after  or 
have been changed, without the fuse kernel module being recompiled
(or at least being downloaded).

You probably only need to recompile with current headers and download.

This has already occurred before. Where is the dependency preventing
this from occurring missing ?

Jean-Pierre

Stephan Althaus wrote on 9/11/22 10:13 PM:

Hello!

I made a pkg update today, and was surprised to get a panic on using my 
fuse file system "exfat" on USB3, which i use for 1-2 years now.


Maybe some illumos patch is causing this (?)

I have build the exfat bits on the new BE, to no success..


$ fmdump -Vp -u a9df4d73-dc1f-e33a-e733-af1e5693a9fc
TIME UUID SUNW-MSG-ID
Sep 11 2022 19:52:06.085966000 a9df4d73-dc1f-e33a-e733-af1e5693a9fc 
SUNOS-8000-KL


   TIME CLASS ENA
   Sep 11 19:52:04.1840 ireport.os.sunos.panic.savecore_failure 
0x
   Sep 11 19:52:03.9741 ireport.os.sunos.panic.dump_pending_on_device 
0x


nvlist version: 0
     version = 0x0
     class = list.suspect
     uuid = a9df4d73-dc1f-e33a-e733-af1e5693a9fc
     code = SUNOS-8000-KL
     diag-time = 1662918725 999156
     de = fmd:///module/software-diagnosis
     fault-list-sz = 0x1
     fault-list = (array of embedded nvlists)
     (start fault-list[0])
     nvlist version: 0
     version = 0x0
     class = defect.sunos.kernel.panic
     certainty = 0x64
     asru = 
sw:///:path=/var/crash/dell/.a9df4d73-dc1f-e33a-e733-af1e5693a9fc
     resource = 
sw:///:path=/var/crash/dell/.a9df4d73-dc1f-e33a-e733-af1e5693a9fc

     savecore-succcess = 0
     failure-reason = pwrite: No such device or address
     os-instance-uuid = a9df4d73-dc1f-e33a-e733-af1e5693a9fc
     panicstr = BAD TRAP: type=e (#pf Page fault) 
rp=fe003d79e850 addr=4 occurred in module "fuse" due to a NULL 
pointer dereference
     panicstack = unix:die+c6 () | unix:trap+10f7 () | 
unix:cmntrap+e9 () | fuse:get_filehandle+52d () | fuse:fuse_open+6e () | 
genunix:fop_open+96 () | genunix:vn_openat+20c () | genunix:copen+421 () 
| genunix:openat+29 () | unix:brand_sys_syscall+1fe () |

     crashtime = 1662918635
     panic-time = 11 September 2022 at 19:50:35 CEST CEST
     (end fault-list[0])

     fault-status = 0x1
     severity = Major
     __ttl = 0x1
     __tod = 0x631e2046 0x51fbcb0

Greetings,

Stephan


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Porting an exFAT driver

[Jean-Pierre André]

John Howard wrote on 12/14/21 7:46 PM:
Microsoft's exFAT is not royalty-free.  Distributers of devices pay 
Microsoft.  Microsoft still owns submarine patents on exFAT.  We 
old-timers have been down that road before.  It is true Microsoft 
published the specification in 2019 and SDXC flash device organization 
standardizes on it.


AFAIK exFAT is now free to open source implementations, but I have
not taken a lawyer advice. I leave it to the OpenIndiana community
to decide whether there is a place for exFAT in its ecosystem.

I have no personal interest in it, I ported this exFAT implementation
only because I had to reboot on Windows to play a presentation by a
colleague on a USB key. A real-life situation.

Jean-Pierre



It would be better to support FAT+ draft 2.  (See Wikipedia on FAT ref. 
34).  FAT+ simply uses 38 bits for file size so up to 256 GiB is 
supported.  The existing PCFS should be modified to at least be FAT+ 
aware.  DR-DOS and FDOS support FAT+.


Neither exFAT nor FAT+ provide journaling.  Microsoft's patents expired 
on FAT32 and VFAT Long File Names.  That is why exFAT 64 bit file size 
support now exists.  Just a useless waste of resources.



On 4:58AM, Tue, Dec 14, 2021 Jean-Pierre André 
mailto:jean-pierre.an...@wanadoo.fr> wrote:


I have been trying to package for OpenIndiana a driver and utilities
developed by Andrew Nayenko and licensed as GPL2 for the exFAT file
system promoted by Microsoft as a replacement for FAT.

The packaging went fine locally (by gmake publish), but the pull
request check fails on :

aclocal: error: aclocal: file '/usr/share/aclocal/wxwin.m4' does not
exist
(see https://github.com/OpenIndiana/oi-userland/pull/7389)

I have no idea of what triggers this, and as this does not occur
locally, I cannot make my own tries. I suspect having a difference of
versions in my autotools (fully updated). I also suspected the use of
the deprecated macro AC_PROG_CC_C99 had something do do with that,
but removing it does not bring any change.

I am at a loss over what else I could try, so I am giving up until
somebody points me at what I am doing wrong.

Jean-Pierre




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Porting an exFAT driver

[Jean-Pierre André]

On 12/14/21 12:09 PM, Udo Grabowski (IMK) wrote:



On 14/12/2021 11:58, Jean-Pierre André wrote:

I have been trying to package for OpenIndiana a driver and utilities
developed by Andrew Nayenko and licensed as GPL2 for the exFAT file
system promoted by Microsoft as a replacement for FAT.

The packaging went fine locally (by gmake publish), but the pull
request check fails on :

aclocal: error: aclocal: file '/usr/share/aclocal/wxwin.m4' does not 
exist

(see https://github.com/OpenIndiana/oi-userland/pull/7389)

I have no idea of what triggers this, and as this does not occur
locally, I cannot make my own tries. I suspect having a difference of
versions in my autotools (fully updated). I also suspected the use of
the deprecated macro AC_PROG_CC_C99 had something do do with that,
but removing it does not bring any change.

I am at a loss over what else I could try, so I am giving up until
somebody points me at what I am doing wrong.


That missing file is part of the wxwidgets package. Somewhere in
library/graphics (don't know the most recent/present name).



Yes, apparently, but this exFAT package has nothing to do with
graphics, and the package checker server is supposed to have all
the libraries needed for running the checks.

Anyway I do not see how I could have inadvertently inserted such a
requirement - unless I misinterpret the meaning of the error.

Jean-Pierre

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] Porting an exFAT driver

[Jean-Pierre André]

I have been trying to package for OpenIndiana a driver and utilities
developed by Andrew Nayenko and licensed as GPL2 for the exFAT file
system promoted by Microsoft as a replacement for FAT.

The packaging went fine locally (by gmake publish), but the pull
request check fails on :

aclocal: error: aclocal: file '/usr/share/aclocal/wxwin.m4' does not exist
(see https://github.com/OpenIndiana/oi-userland/pull/7389)

I have no idea of what triggers this, and as this does not occur
locally, I cannot make my own tries. I suspect having a difference of
versions in my autotools (fully updated). I also suspected the use of
the deprecated macro AC_PROG_CC_C99 had something do do with that,
but removing it does not bring any change.

I am at a loss over what else I could try, so I am giving up until
somebody points me at what I am doing wrong.

Jean-Pierre


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] ntfsprogs update check

[Jean-Pierre André]

Alexander Pyhalov via oi-dev wrote:

Hi.

Can somebody test ntfsprogs update 
(https://github.com/OpenIndiana/oi-userland/pull/5662 ) ? At least, that ntfs 
partitions are still readable?
I've found that all my usb sticks are fat-formatted, so I can't easily test it.


You then have a good testbed to check mkntfs, which is one of the
ntfsprogs :

mkntfs -f -s512 -c4096 -L test /dev/dsk/c.t.d.p1

Jean-Pierre



С уважением,
Александр Пыхалов,
программист отдела телекоммуникационной инфраструктуры
управления информационно-коммуникационной инфраструктуры ЮФУ




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Building openjdk-8-162 with gcc-6 on SPARC

[Jean-Pierre André]

Gary Mills wrote:

I'm attempting to build openjdk-8-162 with gcc-6 on SPARC hardware.  I
finally got a successful gmake build, but a failure with gmake
install.  The error was this one:

 Error occurred during initialization of VM
 java.lang.StackOverflowError
 at java.lang.Object.(Object.java:41)

All newly-build java applications produce the same error.  With a
search on the web, I found exactly the same error for linux.  The bug
apparently affected all architectures except x86.  It appeared because
of increased optimization in later versions of gcc.  This is the linux
patch:

diff --git a/src/os_cpu/linux_zero/vm/os_linux_zero.cpp 
b/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
--- jdk8/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
+++ jdk8/hotspot/src/os_cpu/linux_zero/vm/os_linux_zero.cpp
@@ -55,8 +55,8 @@
  #include "utilities/vmError.hpp"
  
  address os::current_stack_pointer() {

-  address dummy = (address) 
-  return dummy;
+  // return the address of the current function
+  return (address)__builtin_frame_address(0);
  }
  
  frame os::get_sender_for_C_frame(frame* fr) {


This, of course, has no effect on OI.  During the build, OI is
detected as solaris.  The equivalent function for solaris-sparc, in
openjdk/hotspot/src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp,
has this code:

 address os::current_stack_pointer() {
   volatile int dummy;
   address sp = (address) + 8; //  need to confirm if this is 
right
   return sp;
 }

I assume that it's also compiled incorrectly because of the increased
optimization, but I don't know how to correct it.  I'm also concerned
about the comment.  Is it right?


A simple way to avoid this kind of optimization, is to put the
function in its own file, so that the compiler cannot know it
can be inlined. Compiling the function itself may however cause
an error for returning a pointer to a freed location.

Jean-Pierre



Has anybody else built openjdk for SPARC with gcc?  How did you fix
this bug?






___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] I created an OpenIndiana port of UXP/New Moon out of boredom.

[Jean-Pierre André]

Congratulations. A useful alternative to Firefox as its resource
needs are getting out of control.

Jean-Pierre


Jeremy Andrews wrote:
I wanted to post this story somewhere in case anyone finds it 
interesting, it's OpenIndiana-related, and I don't really have a blog. 
The TL;DR version is that I've got UXP/New Moon working on OI, with all 
my changes visible in a public GitHub repository, but I haven't yet 
obtained permission to use the official branding (which would be Pale 
Moon branding in this case, and it might be difficult because they 
haven't shown interest in officially supporting Solaris and OI), and 
find the requirements involved in packaging it for OI confusing because 
it seems like the documentation expects me to do it a specific way that 
involves downloading the whole oi-userland tree and supplying patches 
and links to upstream code, and it's not really clear what I should do 
at this stage.


So, about this time last month, I was looking for something to distract 
myself from a stressful situation in real life and keep my mind 
occupied. I was looking at the Pale Moon source code and noticed they'd 
just removed Solaris support. So I was thinking to myself, "How hard 
would it be to add it back in and then make the program actually compile 
and run?" So I simply installed OpenIndiana in a virtual machine and got 
to work despite having no real experience with Solaris, Firefox, or Pale 
Moon. The only thing I knew about Solaris going in is that it's the 
"other" Unix they offered on x86 systems at my college besides Linux so 
that they could teach about POSIX compliance, avoiding "Linuxisms," and 
say that they teach Unix and not just Linux. I wasn't able to stick with 
my degree because of Calculus, but I always wondered what working with 
it would have been like.


There were five things I learned that were encouraging to me early on.

1. Oracle Solaris and the illumos distributions build Firefox with GCC 
now, and haven't used Sun Studio to do so in ages, so all the code that 
makes those assumptions is outdated. In fact, most of OpenIndiana is 
built with GCC 7 specifically. They do use their own linker, but I knew 
going in I wouldn't have to deal with any clang weirdness.


2. Most of the GNU toolchain is available, but you have to prefix 
commands with "g" to get the GNU version instead of the Solaris version.


3. Mozilla regards Solaris as a Tier 2 or 3 platform, and a ton of 
high-quality patches for it were created during or just after the 
Firefox 52ESR lifecycle by Mozilla at the request of an incredibly 
overworked Oracle employee trying to get the biggest Solaris issues 
fixed upstream.


4. All of the UXP project's major dependencies, like SQLite, NSS, NSPR, 
libevent, libffi, and other libraries are available and more or less 
up-to-date on Solaris and OI. NSS and NSPR have been on it since the 
beginning, with Netscape getting involved with Sun/Java offerings early 
on to power their server products back in the day.


5. Solaris and Linux are both based on System V in some form or other, 
unlike the BSDs. I've seen code in here with a 1989 AT copyright 
notice attached, because it is actually System V Unix code from Bell 
Labs. So there's a lot of overlap in the design, and a lot of POSIX 
functionality to fall back on where the differences lie.


So after I got the system up and running, I tried to load a mozconfig 
file... and hit my first error before ever starting the build. Turns out 
that Solaris uses Ksh, and while Bash is available, it's hard to 
convince it to execute a script as a Bash script with all Bash features 
rather than a version limited to Ksh features. Anyway, it turned out 
Mozilla actually made a patch to remove the "Bash localism," and the 
mozconfig loader is now POSIX compliant (which it should have been in 
the first place). That was the first patch I applied.


 From there, it was mostly a matter of applying build system patches so 
the build system would recognize Solaris. 90% of the time, it would take 
the same code as Linux, and it was like FreeBSD the other 10% of the 
time, basically. One theme that kept coming up was that I had to replace 
several memory-related functions like malign and madvise with 
posix_malign and posix_madvise, because Solaris has versions of those 
functions that take different arguments like caddr_t. This had to be 
ifdefed only because apparently a few versions of Linux don't actually 
have posix_malign and only have the regular version with the POSIX 
syntax. I would say that this was the most common unexpected compile 
error I kept getting caught by, some "malign" or "madvise" function 
somewhere in the code I forgot to change.


The build issue that consumed most of my time was figuring out why I was 
getting text relocations and .eh_frame issues in libxul.so. I learned 
everything I could about linkers and the ELF file format, and about 
libxul.so. Even to the point of reading Mike Hommey's blog and 

Re: [oi-dev] Change in video driver ABI

[Jean-Pierre André]

Gary Mills wrote:

On Mon, Jun 05, 2017 at 09:24:26AM +0200, Jean-Pierre André wrote:

Yesterday I upgraded a Hipster installation from April 2016
to the latest state (by starting a pkg update).

I apparently could not boot beyond the single user mode, but
the real reason appears to lie in a change in the video driver
ABI.


I had a similar problem, and have partially solved it.  I had an AMD
Athlon system with an NVIDIA GeForce 6200 LE video card.  It was
running OI Hipster installed from the 20160421 ISO.  I had installed
NVIDIA-Solaris-x86-304.132 to get it to recognize the video card.
When I upgraded to the current Hipster in a new BE, the BE failed to
boot.

I couldn't find a way to uninstall the Nvidia software I had
installed, but I was able to boot an old BE that I made before I
installed the software.  It was using the VESA driver for that video
card, but otherwise everything ran normally.


Uninstalling the driver should be straightforward :
the install script first only does a "pkgrm" to remove
the former version (before doing a "pkgadd" to install
the requested one).



Then I replaced the video card with a new low-end one that seemed
current.  It was an Nvidia card with a GT730 GPU.  The cost was less
than $100.  Hipster recognized that card.  It described my monitor
correctly and set the resolution to the monitor's default.  The Nvidia
X Server Settings GUI worked.

That system is still running Hipster from 2016, but I'm ready to try
the upgrade again.


So you are also back to square one. I took a simpler
approach by restoring the whole system from a backup.
My understanding is that irreversible changes have been
made somewhere (dead symlinks have been found, so some
newly required feature is probably not available in older
drivers).

And I have to give up upgrading.



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Installing nVidia drivers produces error

[Jean-Pierre André]

Ren Kararou wrote:

Hey guys, running the Solaris nVidia drivers installer (384.59) produces
errors while removing /var/sadm/pkg/NVDAgraphics (and if it got there,
probably also NVDAgraphicsr).  I will happily send an error log upon
request, but I would love some help with the issue.


As my nvidia graphics card is not supported by Hipster,
I had to use an older driver designed for Solaris.
I first had to uninstall the one shipped with Hipster, then
unpack the package for Solaris, and start its installer :

pkg uninstall pkg:/driver/graphics/nvidia \
 pkg:/x11/server/xorg/driver/xorg-video
sh ./NVIDIA-Solaris-x86-304.125.run -x
cd NVIDIA-Solaris-x86-304.125
sh ./install

However this driver (and more recent ones) is not
compatible with recent Hipster, so I cannot upgrade
any more...



Thanks,
Ren

--

The Universe
辛狼蓮





___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Change in video driver ABI

[Jean-Pierre André]

Aurélien Larcher wrote:



On Tue, Jun 6, 2017 at 5:00 PM, Jean-Pierre André
<jean-pierre.an...@wanadoo.fr <mailto:jean-pierre.an...@wanadoo.fr>> wrote:


[...]


 Good point. However the video driver uses other system
 interfaces (interrupts, virtual memory, etc.), and as the
 video drivers versions compatible with both the new and the
 old Xorg run properly with old kernels and not the new one,
 some interface must have changed...

 This leaves me with no much hope for a solution.


Could you check that symlinks to libGL.so are in place?


Where are you expecting those symlinks to be present ?


See
https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/x11/ogl-select/files/nvidia_vendor_select



I can confirm the symlinks to be present, but there is
no target libEGL.so.1 :

$ ls -lR /var/run/opengl/lib
/var/run/opengl/lib:
total 32
lrwxrwxrwx   1 root root   5 Jun  6 17:38 64 -> amd64
drwxr-xr-x   2 root root 252 Jun  6 17:38 amd64
lrwxrwxrwx   1 root root  31 Jun  6 17:38 libEGL.so.1 -> 
/usr/X11/lib/NVIDIA/libEGL.so.1
lrwxrwxrwx   1 root root  30 Jun  6 17:38 libGL.so.1 -> 
/usr/X11/lib/NVIDIA/libGL.so.1


/var/run/opengl/lib/amd64:
total 16
lrwxrwxrwx   1 root root  37 Jun  6 17:38 libEGL.so.1 -> 
/usr/X11/lib/NVIDIA/amd64/libEGL.so.1
lrwxrwxrwx   1 root root  36 Jun  6 17:38 libGL.so.1 -> 
/usr/X11/lib/NVIDIA/amd64/libGL.so.1


$ ls -lRL /var/run/opengl/lib
/var/run/opengl/lib:
/var/run/opengl/lib/libEGL.so.1: No such file or directory
total 1813
drwxr-xr-x   2 root root 252 Jun  6 17:38 64
drwxr-xr-x   2 root root 252 Jun  6 17:38 amd64
-rw-r--r--   1 root bin   823456 Jan 17 23:43 libGL.so.1

/var/run/opengl/lib/64:
/var/run/opengl/lib/64/libEGL.so.1: No such file or directory
total 2309
-rw-r--r--   1 root bin  1068048 Jan 18 00:12 libGL.so.1

/var/run/opengl/lib/amd64:
/var/run/opengl/lib/amd64/libEGL.so.1: No such file or directory
total 2309
-rw-r--r--   1 root bin  1068048 Jan 18 00:12 libGL.so.1


$ ls -lRL /var/run/opengl/server/libglx.so
-rw-r--r--   1 root bin  8402880 Jan 17 23:46 
/var/run/opengl/server/libglx.so






Also is there a libEGLso in this driver?


I am currently not using the ailing configuration, but
I can examine the install script (which does not do much
more than a recursive directory copy).

In the source tree there is a couple of libGL.so.1 (for
32bit and 64bit), but no libEGL* and no symlinks. In the
postinstall script symlinks are created for libwfb.so
(also symlinks created in the device tree).

I will reboot when I know where to look for symlinks.

Jean-Pierre

I think ogl-select expects it now, but if it is not present that
could
cause issues.


 Jean-Pierre





___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Change in video driver ABI

[Jean-Pierre André]

Aurélien Larcher wrote:



On Tue, Jun 6, 2017 at 10:45 AM, Jean-Pierre André
<jean-pierre.an...@wanadoo.fr <mailto:jean-pierre.an...@wanadoo.fr>> wrote:

Alan Coopersmith wrote:

On 06/ 5/17 12:24 AM, Jean-Pierre André wrote:

[   312.529]  WARNING WARNING WARNING WARNING

[   312.529] This server has a video driver ABI version of
20.0 that
is not
supported by this NVIDIA driver.  Please check
http://www.nvidia.com/ for driver updates or downgrade to an X
server with a supported driver ABI.
[   312.529]
=

Are the recent changes in the video ABI in line with the
changes to Solaris ?


The ABI in question is entirely controlled by the Xorg server
and changes
between Xorg releases.  Neither Solaris nor OpenIndiana controls it
independently - it's a matter of matching Nvidia versions to
Xorg versions
regardless of the underlying OS.


Good point. However the video driver uses other system
interfaces (interrupts, virtual memory, etc.), and as the
video drivers versions compatible with both the new and the
old Xorg run properly with old kernels and not the new one,
some interface must have changed...

This leaves me with no much hope for a solution.


Could you check that symlinks to libGL.so are in place?


Where are you expecting those symlinks to be present ?


Also is there a libEGLso in this driver?


I am currently not using the ailing configuration, but
I can examine the install script (which does not do much
more than a recursive directory copy).

In the source tree there is a couple of libGL.so.1 (for
32bit and 64bit), but no libEGL* and no symlinks. In the
postinstall script symlinks are created for libwfb.so
(also symlinks created in the device tree).

I will reboot when I know where to look for symlinks.

Jean-Pierre


I think ogl-select expects it now, but if it is not present that could
cause issues.


Jean-Pierre





___
oi-dev mailing list
oi-dev@openindiana.org <mailto:oi-dev@openindiana.org>
https://openindiana.org/mailman/listinfo/oi-dev
<https://openindiana.org/mailman/listinfo/oi-dev>




--
---
Praise the Caffeine embeddings


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev






___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Change in video driver ABI

[Jean-Pierre André]

Alan Coopersmith wrote:

On 06/ 5/17 12:24 AM, Jean-Pierre André wrote:

[   312.529]  WARNING WARNING WARNING WARNING

[   312.529] This server has a video driver ABI version of 20.0 that
is not
supported by this NVIDIA driver.  Please check
http://www.nvidia.com/ for driver updates or downgrade to an X
server with a supported driver ABI.
[   312.529]
=

Are the recent changes in the video ABI in line with the
changes to Solaris ?


The ABI in question is entirely controlled by the Xorg server and changes
between Xorg releases.  Neither Solaris nor OpenIndiana controls it
independently - it's a matter of matching Nvidia versions to Xorg versions
regardless of the underlying OS.



Good point. However the video driver uses other system
interfaces (interrupts, virtual memory, etc.), and as the
video drivers versions compatible with both the new and the
old Xorg run properly with old kernels and not the new one,
some interface must have changed...

This leaves me with no much hope for a solution.

Jean-Pierre




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Change in video driver ABI

[Jean-Pierre André]

Aurélien Larcher wrote:



On Mon, Jun 5, 2017 at 11:32 AM, Jean-Pierre André
<jean-pierre.an...@wanadoo.fr <mailto:jean-pierre.an...@wanadoo.fr>> wrote:

Aurélien Larcher wrote:



On Mon, Jun 5, 2017 at 9:48 AM, Jean-Pierre André
<jean-pierre.an...@wanadoo.fr
<mailto:jean-pierre.an...@wanadoo.fr>
<mailto:jean-pierre.an...@wanadoo.fr
<mailto:jean-pierre.an...@wanadoo.fr>>> wrote:

 Aurélien Larcher wrote:



 On Mon, Jun 5, 2017 at 9:35 AM, Jean-Pierre André
 <jean-pierre.an...@wanadoo.fr
<mailto:jean-pierre.an...@wanadoo.fr>
 <mailto:jean-pierre.an...@wanadoo.fr
<mailto:jean-pierre.an...@wanadoo.fr>>
 <mailto:jean-pierre.an...@wanadoo.fr
<mailto:jean-pierre.an...@wanadoo.fr>
 <mailto:jean-pierre.an...@wanadoo.fr
<mailto:jean-pierre.an...@wanadoo.fr>>>> wrote:

  Jean-Pierre André wrote:


 [...]


  Update : I see the following comment for
 NVIDIA-Solaris-x86-304.135
  "Added support for X.Org xserver ABI 23
(xorg-server 1.19)"

  Is that the new ABI used by Xorg on OpenIndiana ?


 One always needs to update to a driver version
supported by the
 current
 Xorg.
 We updated to 1.18 (ABI == 20) and soon we will update
to 1.19
 (ABI ==
 23), so you should install the driver you mention.


 Ok, thanks. In the Nvidia changelog, I see that
 NVIDIA-Solaris-x86-304.131 has support for ABI 20,
 so I am to try this one.


The support is backward compatible, so the latest will work as well.


So I tried :
- NVIDIA-Solaris-x86-304.131
- NVIDIA-Solaris-x86-304.132
- NVIDIA-Solaris-x86-304.135

The first couple of them use ABI 20, and the last one
uses ABI 23.

They run successfully with the initial BE, and they all
fail the same way with the updated BE. When switching to
graphics mode, I get a black screen with a winking cursor
on the top left. The keyboard and mouse are probably not
working (but I can connect through ssh to find out what
is going on).

There are a lot of differences in the Xorg.log. Below are
the main the differences for NVIDIA-Solaris-x86-304.135
running on the working BE and on the updated BE (so the
driver is the same, but Xorg is different).

I have put all the differences on
http://jp-andre.pagesperso-orange.fr/Xorg.5jun.zip
<http://jp-andre.pagesperso-orange.fr/Xorg.5jun.zip>

A lot of missing initializations, such as

< [] Initializing built-in extension Generic Event Extension
< [] Initializing built-in extension SHAPE
< [] Initializing built-in extension MIT-SHM
< [] Initializing built-in extension XInputExtension
< [] Initializing built-in extension XTEST
(and 22 more similar lines)

Missing report about module tsol (it was expected to fail,
but the point here is the loading was not even tried).

< [] Loading extension SolarisIA
< [] (II) LoadModule: "xtsol"
< [] (WW) Warning, couldn't open module xtsol
< [] (II) UnloadModule: "xtsol"
< [] (II) Unloading xtsol
< [] (EE) Failed to load module "xtsol" (module does not exist, 0)

EDID information not taken into account :

< [] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the
EDID for display
< [] (**) NVIDIA(0): device IQT L70S (CRT-0) (Using EDID
frequencies has been
< [] (**) NVIDIA(0): enabled on all display devices.)

This looks much like some package is missing.


I was saying that because several xorg functions were
not activated (initializations, processing of EDID), which
could means they were not called.

Anyway there are the same list of xorg packages in the
working BE and the updated one.



Since the driver is binary, the only thing I can offer for now I to
provide a build of Xorg 1.19 that you could try out, ... but maybe it is
just that nvidia drivers are broken for your model.


I would not blame the driver, as all versions tried behave
properly with the initial BE. Also I can imagine the
interface between the driver and xorg has been tested on
other configurations, so the issue must be elsewhere.

I am keeping the configuration as is until somebody has
something else to suggest or you have an updated Xorg.
No need to rush it out, I will use the working BE in the
meantime.

Thank you for your help.

Jean-Pierre




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Change in video driver ABI

[Jean-Pierre André]

Aurélien Larcher wrote:



On Mon, Jun 5, 2017 at 9:48 AM, Jean-Pierre André
<jean-pierre.an...@wanadoo.fr <mailto:jean-pierre.an...@wanadoo.fr>> wrote:

Aurélien Larcher wrote:



On Mon, Jun 5, 2017 at 9:35 AM, Jean-Pierre André
<jean-pierre.an...@wanadoo.fr
<mailto:jean-pierre.an...@wanadoo.fr>
<mailto:jean-pierre.an...@wanadoo.fr
<mailto:jean-pierre.an...@wanadoo.fr>>> wrote:

 Jean-Pierre André wrote:


[...]


 Update : I see the following comment for
NVIDIA-Solaris-x86-304.135
 "Added support for X.Org xserver ABI 23 (xorg-server 1.19)"

 Is that the new ABI used by Xorg on OpenIndiana ?


One always needs to update to a driver version supported by the
current
Xorg.
We updated to 1.18 (ABI == 20) and soon we will update to 1.19
(ABI ==
23), so you should install the driver you mention.


Ok, thanks. In the Nvidia changelog, I see that
NVIDIA-Solaris-x86-304.131 has support for ABI 20,
so I am to try this one.


The support is backward compatible, so the latest will work as well.



So I tried :
- NVIDIA-Solaris-x86-304.131
- NVIDIA-Solaris-x86-304.132
- NVIDIA-Solaris-x86-304.135

The first couple of them use ABI 20, and the last one
uses ABI 23.

They run successfully with the initial BE, and they all
fail the same way with the updated BE. When switching to
graphics mode, I get a black screen with a winking cursor
on the top left. The keyboard and mouse are probably not
working (but I can connect through ssh to find out what
is going on).

There are a lot of differences in the Xorg.log. Below are
the main the differences for NVIDIA-Solaris-x86-304.135
running on the working BE and on the updated BE (so the
driver is the same, but Xorg is different).

I have put all the differences on
http://jp-andre.pagesperso-orange.fr/Xorg.5jun.zip

A lot of missing initializations, such as

< [] Initializing built-in extension Generic Event Extension
< [] Initializing built-in extension SHAPE
< [] Initializing built-in extension MIT-SHM
< [] Initializing built-in extension XInputExtension
< [] Initializing built-in extension XTEST
(and 22 more similar lines)

Missing report about module tsol (it was expected to fail,
but the point here is the loading was not even tried).

< [] Loading extension SolarisIA
< [] (II) LoadModule: "xtsol"
< [] (WW) Warning, couldn't open module xtsol
< [] (II) UnloadModule: "xtsol"
< [] (II) Unloading xtsol
< [] (EE) Failed to load module "xtsol" (module does not exist, 0)

EDID information not taken into account :

< [] (**) NVIDIA(0): Using HorizSync/VertRefresh ranges from the EDID 
for display
< [] (**) NVIDIA(0): device IQT L70S (CRT-0) (Using EDID frequencies 
has been

< [] (**) NVIDIA(0): enabled on all display devices.)

This looks much like some package is missing.

Jean-Pierre



Jean-Pierre


Kind regards

Aurélien





___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Change in video driver ABI

[Jean-Pierre André]

Aurélien Larcher wrote:



On Mon, Jun 5, 2017 at 9:35 AM, Jean-Pierre André
<jean-pierre.an...@wanadoo.fr <mailto:jean-pierre.an...@wanadoo.fr>> wrote:

    Jean-Pierre André wrote:



[...]



Update : I see the following comment for NVIDIA-Solaris-x86-304.135
"Added support for X.Org xserver ABI 23 (xorg-server 1.19)"

Is that the new ABI used by Xorg on OpenIndiana ?


One always needs to update to a driver version supported by the current
Xorg.
We updated to 1.18 (ABI == 20) and soon we will update to 1.19 (ABI ==
23), so you should install the driver you mention.


Ok, thanks. In the Nvidia changelog, I see that
NVIDIA-Solaris-x86-304.131 has support for ABI 20,
so I am to try this one.

Jean-Pierre



Kind regards

Aurélien





___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Change in video driver ABI

[Jean-Pierre André]

Jean-Pierre André wrote:

Yesterday I upgraded a Hipster installation from April 2016
to the latest state (by starting a pkg update).

I apparently could not boot beyond the single user mode, but
the real reason appears to lie in a change in the video driver
ABI. The Xorg log shows :

[   311.868] (II) Module glx: vendor="NVIDIA Corporation"
[   311.868]compiled for 4.0.2, module version = 1.0.0
[   311.868]Module class: X.Org Server Extension
[   311.868] (II) NVIDIA GLX Module  304.125  Mon Dec  1 21:04:29 PST 2014
[   312.362] (II) LoadModule: "nvidia"
[   312.435] (II) Loading /usr/X11/lib/modules/drivers/amd64/nvidia_drv.so
[   312.525] (II) Module nvidia: vendor="NVIDIA Corporation"
[   312.526]compiled for 4.0.2, module version = 1.0.0
[   312.526]Module class: X.Org Video Driver
[   312.529]  WARNING WARNING WARNING WARNING

[   312.529] This server has a video driver ABI version of 20.0 that is not
supported by this NVIDIA driver.  Please check
http://www.nvidia.com/ for driver updates or downgrade to an X
server with a supported driver ABI.
[   312.529]
=
[   312.529] (EE) NVIDIA: Use the -ignoreABI option to override this check.

This is with an Nvidia video "GeForce 6150 LE" not supported
by former nvidia drivers shipped with OpenIndiana, so I had
to use a legacy driver for Solaris. The one I was using is
NVIDIA-Solaris-x86-304.125, and on the Nvidia site there is
a newer NVIDIA-Solaris-x86-304.135.run which I have not tried
yet.


Update : I see the following comment for NVIDIA-Solaris-x86-304.135
"Added support for X.Org xserver ABI 23 (xorg-server 1.19)"

Is that the new ABI used by Xorg on OpenIndiana ?




Are the recent changes in the video ABI in line with the
changes to Solaris ?

Jean-Pierre





___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] Change in video driver ABI

[Jean-Pierre André]

Yesterday I upgraded a Hipster installation from April 2016
to the latest state (by starting a pkg update).

I apparently could not boot beyond the single user mode, but
the real reason appears to lie in a change in the video driver
ABI. The Xorg log shows :

[   311.868] (II) Module glx: vendor="NVIDIA Corporation"
[   311.868]compiled for 4.0.2, module version = 1.0.0
[   311.868]Module class: X.Org Server Extension
[   311.868] (II) NVIDIA GLX Module  304.125  Mon Dec  1 21:04:29 PST 2014
[   312.362] (II) LoadModule: "nvidia"
[   312.435] (II) Loading /usr/X11/lib/modules/drivers/amd64/nvidia_drv.so
[   312.525] (II) Module nvidia: vendor="NVIDIA Corporation"
[   312.526]compiled for 4.0.2, module version = 1.0.0
[   312.526]Module class: X.Org Video Driver
[   312.529]  WARNING WARNING WARNING WARNING 


[   312.529] This server has a video driver ABI version of 20.0 that is not
supported by this NVIDIA driver.  Please check
http://www.nvidia.com/ for driver updates or downgrade to an X
server with a supported driver ABI.
[   312.529] 
=

[   312.529] (EE) NVIDIA: Use the -ignoreABI option to override this check.

This is with an Nvidia video "GeForce 6150 LE" not supported
by former nvidia drivers shipped with OpenIndiana, so I had
to use a legacy driver for Solaris. The one I was using is
NVIDIA-Solaris-x86-304.125, and on the Nvidia site there is
a newer NVIDIA-Solaris-x86-304.135.run which I have not tried
yet.

Are the recent changes in the video ABI in line with the
changes to Solaris ?

Jean-Pierre


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI 2017-05 snapshot: AMD Athlon 64 (K8) compatibility issues

[Jean-Pierre André]

Hi,

Thank you for your reply. Below I am adding a few comments
about it.

However, the issue is not what I thought, so I am to open
a new thread about it.

Toomas Soome wrote:



On 4. juuni 2017, at 20:13, Jean-Pierre André
<jean-pierre.an...@wanadoo.fr <mailto:jean-pierre.an...@wanadoo.fr>>
wrote:

Jean-Pierre André wrote:

ken mays via oi-dev wrote:

On that note, be aware of prior notice on AMD64 Athlon 64-based
computers and the use of software from:


I have such a computer, which I intended to upgrade to 2017.04

Is booting on a live-usb a valid test for presence/absence of
further problems ahead ? (IOW is the problem in the new loader or
in the kernel ?)


As nobody told whether the issue lies within the new loader or
in the kernel, and bug #8169 pointed at an issue in the loader,
I tried updating the current installation with the grub loader
kept in place (BE_HAS_GRUB=true in /etc/default/be).

After the update, I can only boot into the new BE in single user
mode. Two kinds of errors are displayed :

1) svc:/system/metainit: default:
   method "lib/svc/method/svc-metainit"
   failed with exit status 127
(shown three times then transitioned to maintenance).



thats issue about SMF, just run svccfg delete
svc:/system/metainit:default - it does not affect booting.


Done. On reboot the warning disappears.



2) APIC Error interrupt on CPU 1. Status 0 = 0, Status 1 = 80
This second error is traditional on this computer and is
normally avoided by the boot option "acpi-user-options=0x2"
which was in place.


you can always test by: ok boot -B acpi-user-options=0x2 , or check the
loader options menu;

also prtconf -v and tr ‘\0’ ‘\n’ < /system/boot/environment  from OS.

This issue is worth to be filed in illumos.org/issues
<http://illumos.org/issues> if not done already.


The prtconf output shows some possibly related differences :

-name='acpi-status' type=int items=1
-value=0013
+name='acpi-enum' type=string items=1
+value='off'
 name='acpi-user-options' type=int items=1
-value=0008
+value=0002

It at least shows the acpi-user-options is taken into account
(the values 2 and 8 were known to work and the difference
above only means I tried both values).

I thought the APIC error meant the CPU1 did not receive any
interrupts, but apparently both CPUs are running.

I could not find any file in /system/boot and I could not
guess which file you really meant. I issued the command "set"
to get the current environment, but I did not see anything
noteworthy.



Are these the errors which I was warned against ?

Have they something to do with bug #8169 ?

Do they mean I am kicked out, or is there a way to update
to the latest state before the bug was created ?


8169 is fixed in later builds, it was unfortunate the ISO’s got
published just a bit before the issue and the fix. However, the 8169 is
only affecting systems with ACPI v1 and only if you boot the latest
iso/usb, pkg update will give you the fix. The 8169 does make kernel
startup to fail as the boot loader was passing wrong size for ACPI table
- if you got the single user, you are not affected.

However, if you did end up in single user mode, it means that some
essential service did fail for some reason, does svcs -vx reveal anything?

rgds,
toomas







___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI 2017-05 snapshot: AMD Athlon 64 (K8) compatibility issues

[Jean-Pierre André]

Jean-Pierre André wrote:

ken mays via oi-dev wrote:

On that note, be aware of prior notice on AMD64 Athlon 64-based
computers and the use of software from:


I have such a computer, which I intended to upgrade to 2017.04

Is booting on a live-usb a valid test for presence/absence of
further problems ahead ? (IOW is the problem in the new loader or
in the kernel ?)


As nobody told whether the issue lies within the new loader or
in the kernel, and bug #8169 pointed at an issue in the loader,
I tried updating the current installation with the grub loader
kept in place (BE_HAS_GRUB=true in /etc/default/be).

After the update, I can only boot into the new BE in single user
mode. Two kinds of errors are displayed :

1) svc:/system/metainit: default:
method "lib/svc/method/svc-metainit"
failed with exit status 127
(shown three times then transitioned to maintenance).

2) APIC Error interrupt on CPU 1. Status 0 = 0, Status 1 = 80
This second error is traditional on this computer and is
normally avoided by the boot option "acpi-user-options=0x2"
which was in place.

Are these the errors which I was warned against ?

Have they something to do with bug #8169 ?

Do they mean I am kicked out, or is there a way to update
to the latest state before the bug was created ?

Jean-Pierre



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI 2017-05 snapshot: AMD Athlon 64 (K8) compatibility issues

[Jean-Pierre André]

ken mays via oi-dev wrote:

On that note, be aware of prior notice on AMD64 Athlon 64-based
computers and the use of software from:


I have such a computer, which I intended to upgrade to 2017.04

Is booting on a live-usb a valid test for presence/absence of
further problems ahead ? (IOW is the problem in the new loader or
in the kernel ?)

Jean-Pierre



http://dlc.openindiana.org/isos/hipster/20170502/

~ Ken



On Friday, May 5, 2017, 4:36:35 PM PDT, Adam Števko
 wrote:
Hey Ken,

there is no 2017.05 snapshot, onlt 2017.04, which was released on 2 May.

Cheers,
Adam


On May 5, 2017, at 5:04 PM, ken mays via oi-dev
> wrote:

Hello,

If you are using AMD Athlon 64 (K8) CPUs, it is possible that the
current release of OI 2017.05 snapshot will not boot fully.
Please bug report if you are using those specific CPUs.

Otherwise, all previous OI snapshots were tested as working.

~ Ken






___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] USB installation instructions

[Jean-Pierre André]

Toomas Soome wrote:



On 21. nov 2016, at 13:12, Jean-Pierre André
<jean-pierre.an...@wanadoo.fr <mailto:jean-pierre.an...@wanadoo.fr>>
wrote:



[...]


In the boot options screen, there are 4 different ACPI settings.
Would this achieve the same thing?


Are you not assuming the user gets a screen with options ?
(I only get a "I" on top left of screen).




Ou, you have usb image, trying to boot and never get to loader screen
itself, only have spinner at upper left corner?


Ok, what I thought was an "I" must be a "|" not followed
by / \ etc.


if so, the acpi options wont make any difference there yet, those are
for kernel.


Correct, I have tried with no success.

So the loader is relying on some acpi behavior which did
not matter to grub.


if the first spinner appears, you have the boot loader stage1 running,
and it should start the loader itself. If not, reboot (as its probably
hung or something), when spinner appears, press a key and you should get
the prompt.


Rebooted twice. No reaction to keyboard (this is
a USB keyboard, no serial line on this computer).

Note : this is a computer on which OpenIndiana had
been installed from USB key with an appropriate
grub option.


from it you can verify what devices are visible by entering on boot:  status
and to see if it is able to list current boot directory content boot: ?boot
note the prompt there is really limited and you can not use arrow keys.

but thats just for very basic diagnostics, just to verify what your bios
did make available… if the loader itself is never started, your
secondary option is to check with cd, and other than that will require
more debugging and/or more recent build depending on what is the root
cause. Absolutely no messages from the loader does smell pretty bad, it
means something is gone wrong at very early…


Adding a file to a CD requires regenerating a bootable CD.
Much more complex than a ufs partition on a USB key.

Moreover if the loader has some acpi expectation, it
will be the same from a CD... and on the installed loader.

Is there a way to activate grub on the key ?

I will probably give up, but I am open to help you
debugging the issue.

Jean-Pierre



rgds,
toomas





___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] USB installation instructions

[Jean-Pierre André]

Michael Kruger wrote:

On 11/21/2016 05:44 AM, Toomas Soome wrote:



On 21. nov 2016, at 12:39, Jean-Pierre André
<jean-pierre.an...@wanadoo.fr> wrote:

Aurélien Larcher wrote:

Hello,
the download page points to the following instructions which are
outdated:

https://wiki.openindiana.org/oi/Installing+OpenIndiana


I have a computer on which a boot option like
-B acpi-user-options=0x2 is required.

I have copied the latest image to a USB key, and I am
sure I did it correctly, as I have used it to install on
another computer.

I could not find where to insert the required option on
the USB key. I could not find where the new loader is
and where its boot options are. The grub files are on
/boot/grub but I cannot find an initialized menu, so
I cannot even tell which loader is in use.

What am I supposed to do ?

Jean-Pierre




echo “acpi-user-options=2” > usbmountpoint/boot/conf.d/acpi


Ok, will try


this will make it default for your stick.

rgds,
toomas


The docs website has been updated with screen shots of the new boot
loader, which show the various boot options.

http://docs.openindiana.org/handbook/getting-started/#booting-openindiana-installer-media


In the boot options screen, there are 4 different ACPI settings.
Would this achieve the same thing?


Are you not assuming the user gets a screen with options ?
(I only get a "I" on top left of screen).



Thanks,

Michael

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev





___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] USB installation instructions

[Jean-Pierre André]

Aurélien Larcher wrote:

Hello,
the download page points to the following instructions which are outdated:

https://wiki.openindiana.org/oi/Installing+OpenIndiana


I have a computer on which a boot option like
-B acpi-user-options=0x2 is required.

I have copied the latest image to a USB key, and I am
sure I did it correctly, as I have used it to install on
another computer.

I could not find where to insert the required option on
the USB key. I could not find where the new loader is
and where its boot options are. The grub files are on
/boot/grub but I cannot find an initialized menu, so
I cannot even tell which loader is in use.

What am I supposed to do ?

Jean-Pierre



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] intel driver and old video chipsets

[Jean-Pierre André]

Aurélien Larcher wrote:



On Fri, Nov 4, 2016 at 9:21 AM, Jean-Pierre André
<jean-pierre.an...@wanadoo.fr <mailto:jean-pierre.an...@wanadoo.fr>> wrote:

Alexander Pyhalov wrote:

Hello.

It's a known issue that current intel drm driver in OI fails to work
with old Intel video adapters, like Intel g945 and similar.
Do we have a list of such devices and their pci ids?
Can we remove corresponding pci ids from

https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/openindiana/drm/drm.p5m#L31

<https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/openindiana/drm/drm.p5m#L31>
?


The new intel driver accepts my graphics adapter shown as
8086:116 so this one should be kept in the list.


This PCI id corresponds to Sandy Bridge and was not removed: all gen 6/7
were kept.

Do you have any sporadic GPU hang to report?


During a fresh install from live USB, bad horizontal
lines showed and disappeared, but I did not notice
any during normal operation.


You can run glxgears in non-synchronized mode to check it:

$ vblank_mode=0 glxgears


It showed normally (at 2000fps, not bad, though 3000 on
Linux), but it sometimes halted for a second or two.
Maybe this is related to some unrelated task starting.


Could you add a comment in the following table?

https://wiki.openindiana.org/oi/Intel+KMS+driver


Sorry, too high a hurdle for a sporadic usage...

Computer : HP Notebook envy 4
Graphics : Intel (id 8086:116.103c.1894)
Comment : Hipster 10-2016 "vanilla install" works
at 1366x768 resolution (glxgears at 2000fps).



With the vesa driver, Fn+F2 / Fn+F3 showed an on-screen
brightness control (with no effect on actual brightness),
but with the intel driver I do not get this control, so I
think there were inappropriate hooks with vesa and the hooks
are missing with Intel.



FIY, when it comes to my Thinkpads hot keys are managed in Linux by
evdev and are otherwise totally ignored since OI does not support it
(for instance you can check with xev) so xmodmap would not even help.

xf86-video-intel provides a backlight tool but I have not used it.


There is indeed an xf86-video-backlight-helper, probably
meant to be called from the desktop environment GUI, but
I do not know how I can start it.

For now I am just using "xrandr --brightness", which just
reduces the color space, not exactly what I want.

And an annoying thing which I did not have with the vesa
driver : something is hijacking the "Shift+F5" key. I was
customary with this with Nvidia drivers, but not on this
computer (nor virtual ones). What is the hijacker and how
can I get rid of it ?

Jean-Pierre




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] FLAG DAY: Provide loader menu additions for boot image.

[Jean-Pierre André]

Toomas Soome wrote:


Support for specifying loader configuration on installation media was added to 
distribution constructror.

This support consists several components.

1. loader configuration script for distribution manifest:


I do not see information about which file systems are supported
by the loader.

Is dual (triple) booting on Windows (ntfs) and Linux (ext2)
supported by the loader (or planned to be supported) ?

Jean-Pierre


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] intel driver and old video chipsets

[Jean-Pierre André]

Alexander Pyhalov wrote:

Hello.

It's a known issue that current intel drm driver in OI fails to work
with old Intel video adapters, like Intel g945 and similar.
Do we have a list of such devices and their pci ids?
Can we remove corresponding pci ids from
https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/openindiana/drm/drm.p5m#L31
?


The new intel driver accepts my graphics adapter shown as
8086:116 so this one should be kept in the list.

However I cannot find a way to dim the lights. The brightness
is stuck at the maximum level, which is unbearable.

The functions keys for adjusting the brighness (Fn+F2 / Fn+F3)
have no effect. I guess I have to hook something to the
functions keys, but how can I do that ?

With Gnome, there was a brighness control under "Power
Management", which worked at least on Nvidia graphics, but
there is no power management any more with Mate.

Please point me at proper documentation for adjusting the
brighness.



Will it solve the problem? I mean, will Xorg fall back to vesa and
handle such devices as earlier?


With the vesa driver, Fn+F2 / Fn+F3 showed an on-screen
brightness control (with no effect on actual brightness),
but with the intel driver I do not get this control, so I
think there were inappropriate hooks with vesa and the hooks
are missing with Intel.

Jean-Pierre



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] libfuse update

[Jean-Pierre André]

Alexander Pyhalov wrote:

On 08/26/16 12:52 PM, Alexander Pyhalov wrote:


No surprise, as it's 755. On Linux I see 666. What is correct approach
here? Should we somehow honor console user?



Pardon, 600.



And next thing which I receive is

/usr/lib/fs/fusermount.bin: mount failed: Not owner


I do not what this file is for, presumably for mounting
as a plain user (which I never do).

I have it as /usr/lib/fs/fuse/fusermount.bin
with permissions 0555 owned by root:bin

Jean-Pierre




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] libfuse update

[Jean-Pierre André]

Alexander Pyhalov wrote:

On 08/26/16 12:27 PM, Jean-Pierre André wrote:

Adam Števko wrote:

Hi,


[...]


By the way, I sent several patches to libfuse to Adam
last may. Did you take them into account ?


Patches have been delivered since May:
https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/library/libfuse/patches


Though, I have to go through our communication and check if that’s
all. I recall I haven’t applied everything.



I do not see the one I sent you on May 5th about permissions
to set timestamps on files, and I do not remember anybody
having objections about it (this has been in fuse-lite and
used by ntfs-3g for years).

I attach it again, just in case.



BTW, when I run just-compiled /usr/lib/gvfs-fuse-daemon, I receive
/dev/fuse: Permission denied.

No surprise, as it's 755. On Linux I see 666. What is correct approach
here? Should we somehow honor console user?




/dev/fuse is the interface with the kernel module, created
when the module is installed. I have always seen it with
permissions 0666 to owner root:sys

add_drv -m 'fuse 0666 root sys' fuse
ln -s /devices/pseudo/fuse@0:fuse /dev/fuse

(See http://jp-andre.pagesperso-orange.fr/openindiana-ntfs-3g.html)

Jean-Pierre



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] libfuse update

[Jean-Pierre André]

Adam Števko wrote:

Hi,


[...]


By the way, I sent several patches to libfuse to Adam
last may. Did you take them into account ?


Patches have been delivered since May: 
https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/components/library/libfuse/patches
Though, I have to go through our communication and check if that’s all. I 
recall I haven’t applied everything.



I do not see the one I sent you on May 5th about permissions
to set timestamps on files, and I do not remember anybody
having objections about it (this has been in fuse-lite and
used by ntfs-3g for years).

I attach it again, just in case.

Jean-Pierre


Adam



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev



--- fuse.c.ref	2016-05-05 11:24:20.432471400 +0200
+++ fuse.c	2016-05-05 11:26:24.508680800 +0200
@@ -1462,6 +1462,29 @@
 else
 err = fuse_fs_truncate(f->fs, path, attr->st_size);
 }
+#ifdef HAVE_UTIMENSAT
+if (!err &&
+(valid & (FUSE_SET_ATTR_ATIME | FUSE_SET_ATTR_MTIME))) {
+struct timespec tv[2];
+
+tv[0].tv_sec = 0;
+tv[1].tv_sec = 0;
+tv[0].tv_nsec = UTIME_OMIT;
+tv[1].tv_nsec = UTIME_OMIT;
+
+if (valid & FUSE_SET_ATTR_ATIME_NOW)
+tv[0].tv_nsec = UTIME_NOW;
+else if (valid & FUSE_SET_ATTR_ATIME)
+tv[0] = attr->st_atim;
+
+if (valid & FUSE_SET_ATTR_MTIME_NOW)
+tv[1].tv_nsec = UTIME_NOW;
+else if (valid & FUSE_SET_ATTR_MTIME)
+tv[1] = attr->st_mtim;
+
+err = fuse_fs_utimens(f->fs, path, tv);
+} else
+#endif
 if (!err && (valid & (FUSE_SET_ATTR_ATIME | FUSE_SET_ATTR_MTIME)) ==
 (FUSE_SET_ATTR_ATIME | FUSE_SET_ATTR_MTIME)) {
 struct timespec tv[2];
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] libfuse update

[Jean-Pierre André]

Alexander Pyhalov wrote:

On 08/26/16 09:52 AM, Jean-Pierre André wrote:


What is the need ? AKAIK gvfs is related to Gnome and
is not supported on Linux any more.


I see the following fuse-related errors, trying to compile gvfs with
fuse support


error: 'struct fuse_conn_info' has no member named 'want'


This field exists in fuse 2.7, it is declared in the fuse-lite
library used by ntfs-3g.


error: 'FUSE_CAP_ATOMIC_O_TRUNC' undeclared


This is one of the bits going into the field "want". Is is
about the file system telling it supports the O_TRUNC as an
argument of open()... which current fuse expects anyway.

Both can be easily added to fuse_common.h, but this will
not make libfuse to 2.8.

Patch proposal attached.

By the way, I sent several patches to libfuse to Adam
last may. Did you take them into account ?

Jean-Pierre



As I see, gvfs is still supported:
http://ftp.gnome.org/pub/GNOME/sources/gvfs/





--- fuse_common.h.old	2010-06-15 16:46:54.0 +0200
+++ fuse_common.h.new	2016-08-26 10:11:15.146085700 +0200
@@ -110,11 +110,23 @@
 unsigned max_readahead;
 
 /**
+ * Capability flags, that the filesystem wants to enable
+ */
+unsigned int want;
+/**
  * For future use.
  */
-unsigned reserved[27];
+unsigned reserved[26];
 };
 
+/**
+ * Capability bits for 'fuse_conn_info.capable' and 'fuse_conn_info.want'
+ *
+ * FUSE_CAP_ATOMIC_O_TRUNC: filesystem handles the O_TRUNC open flag
+ */
+#define FUSE_CAP_ATOMIC_O_TRUNC	(1 << 3)
+
+
 struct fuse_session;
 struct fuse_chan;
 
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] libfuse update

[Jean-Pierre André]

Alexander Pyhalov wrote:

Hi.
Has someone looked at libfuse update? Even our ancient gvfs requires at
least 2.8...


Version 2.8 added ioctl() and poll(), both require
significant updates to the fuse kernel module.

IMHO ioctl() can be added with reasonable effort, it
is available in the fuse-lite library shipped with
ntfs-3g, but the kernel module part has to be created
from scratch.

poll() is more complex, I would not try unless there
is a demand from someone who is blocked and has a real
situation for testing.

What is the need ? AKAIK gvfs is related to Gnome and
is not supported on Linux any more.

Jean-Pierre



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Mate is here (as well as new test ISOs)

[Jean-Pierre André]

Jean-Pierre André wrote:

Alexander Pyhalov wrote:

ken mays via oi-dev писал 16.08.2016 20:18:

[...]

2. Support for NTFS/exFAT-formatted storage USB devices. We can do
this by including the Tuxera NTFS/exFAT and/or FOSS fuse support.


We have system/file-system/ntfsprogs with fuse support.



If you need help for this, please ask... But you will
have to tell me how to make a plugged-in device to
show in /dev/dsk, so that it can be mounted.


When plugging-in and ntfs usb key, it does show in
/devices (at a location uneasy to guess), and can be
mounted just fine.

Where is the piece of code which creates an entry
in /media and mounts vfat USB keys ?

Jean-Pierre




___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Mate is here (as well as new test ISOs)

[Jean-Pierre André]

Alexander Pyhalov wrote:

ken mays via oi-dev писал 16.08.2016 20:18:

[...]

2. Support for NTFS/exFAT-formatted storage USB devices. We can do
this by including the Tuxera NTFS/exFAT and/or FOSS fuse support.


We have system/file-system/ntfsprogs with fuse support.



If you need help for this, please ask... But you will
have to tell me how to make a plugged-in device to
show in /dev/dsk, so that it can be mounted.

Jean-Pierre



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] ext2 on OI Hipster 20151003 follow-up

[Jean-Pierre André]

Bruce Lilly wrote:

On Wed, Oct 14, 2015 at 12:40 PM, Jean-Pierre André
<jean-pierre.an...@wanadoo.fr> wrote:


What is this file mode changing about ?


See http://openindiana.org/pipermail/oi-dev/2015-October/003804.html


Depends on your use case...

If you do not want to define the user mapping to
Windows, you just have to mount with option
fmask=0111 to hide the execution right.

If you want the rights interoperable with Windows,
you have to bear the Windows rules, which usually
define an inherited execution right for files created
by Windows. You can however define an inheritance
rule in the parent directory so that files created
by Windows in that directory do not have the
execution right. You can even make this rule
inheritable to inner directories, to only have to
set the rule on the root directory. This is only
for files created by Windows, for files created by
OpenIndiana the Posix rules apply.

Jean-Pierre




___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [HEADSUP] X server update in OpenIndiana Hipster

[Jean-Pierre André]

Hi Nikola,

Nikola M wrote:


On 03/ 3/15 04:31 PM, Jean-Pierre André wrote:

Hi Ken,

ken mays via oi-dev wrote:

Hello,

The lockdown (pkg freeze) is needed mainly on the XServer and Intel
driver.
You need to maintain Intel driver's 2.6.3 or 2.9.1 for XServer 1.7.7.


I assume you mean Intel driver 2.9.1 is compatible with
current Xorg server 1.7.7, but where is it to be found ?

The latest hipster ships with 2.99.917 (not compatible
with Xorg) and older one shipped with 2.6.3 (probably
not compatible with my hardware). An intermediate
version compatible with both Xorg server and hardware
would be nice...


Hi Jean-Pierre,

Could you please also state what is your hardware, brand, model,
configuration and grahics card/integrated graphics model (included in
motherboard, chipset or inside cpu).


scanpci shows :

pci bus 0x cardnum 0x02 function 0x00: vendor 0x8086 device 0x0116
 Intel Corporation 2nd Generation Core Processor Family Integrated 
Graphics Controller

 CardVendor 0x103c card 0x1894 (Hewlett-Packard Company, Card unknown)

On Windows 7 the card is displayed as Intel(R) HD Graphics 3000

Note : https://www.illumos.org/issues/5670 (from Ken) mentions
Intel HD Graphics: 2000-6000 to be supported by the Intel
driver not ported to OI, which gives hope for the future.

Xorg.0.log shows on Hipster (any 2014 versions) :

(II) Module intel: vendor=X.Org Foundation
compiled for 1.7.7, module version = 2.6.3
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 6.0
(II) LoadModule: vesa
(II) Loading /usr/lib/xorg/modules/drivers/amd64/vesa_drv.so
(II) Module vesa: vendor=X.Org Foundation
compiled for 1.7.7, module version = 2.3.0
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 6.0
...
(II) UnloadModule: intel
(II) Unloading /usr/lib/xorg/modules/drivers/amd64/intel_drv.so

So Xorg tries to use the Intel driver 2.6.3 and gives up.
The vesa driver is used instead, which is not bad (I need
no 3D). The only problem is that I cannot adjust the
brightness, and maximum brightness is unbearable, hence
my initial question.



How it behaves in hipster-2014.1 and maybe booting from live 20141010
DVD/USB?


Same result (no surprise, this is the same driver
and same xorg server).


Idea of freezing X and intel driver is if you freeze it in a working
state, before one updates rest of the system to hipster-2015 for testing
for new bugs. (Works for me for older intel graphics, e.g. 945)


I also tested hipster 2015. The Intel driver fails
because of undefined symbol RegionEmptyData. This is
probably the signature of Xorg server being incompatible
with Intel driver 99.99.917


If also in hipster-2014.1 you do not have your graphics working
correctly (explain how it works, does it display with low
resolution/VESA or something) you can then try installing/booting from
live DVDs of older Openindiana /dev and Hipster release DVDs.


Unfortunately this computer is not old enough (about
two years and a half), and it has always fallen back
to using the vesa driver. This appears to just be
caused by an unsupported graphic model.

I have also tried to configure /etc/X11/xorg.conf to
reject the vesa driver. This has only led to having no
graphics at all.


If with no previous release it worked for you, see that you report a bug
on it, too.
https://www.illumos.org/projects/openindiana/issues


The conclusion will be to wait for the new Xorg
server...

Ken mentioned an Intel driver 2.9.1 which I could test
if I found it somewhere.

For now, having a way to adjust the brightness through
the vesa driver would be enough.

Jean-Pierre



___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [HEADSUP] X server update in OpenIndiana Hipster

[Jean-Pierre André]

Hi Ken,

ken mays via oi-dev wrote:

Hello,

The lockdown (pkg freeze) is needed mainly on the XServer and Intel driver.
You need to maintain Intel driver's 2.6.3 or 2.9.1 for XServer 1.7.7.


I assume you mean Intel driver 2.9.1 is compatible with
current Xorg server 1.7.7, but where is it to be found ?

The latest hipster ships with 2.99.917 (not compatible
with Xorg) and older one shipped with 2.6.3 (probably
not compatible with my hardware). An intermediate
version compatible with both Xorg server and hardware
would be nice...

Jean-Pierre



If you've updated to hipster-2014.1, you've done well enough.

Thanks,
Ken




On Monday, March 2, 2015 6:43 AM, Nikola M minik...@gmail.com wrote:



On 02/28/15 04:22 PM, Jean-Pierre André wrote:
  Hi Alexander,
 
  Alexander Pyhalov wrote:
  [...]
  I think we can look at downgrading
  intel drivers to something like 2.9 (or even 2.6) which still supported
  UMS until KMS work is ready. I don't know how much work it'll take to
  make this crap work with new Xorg server, so no promises on time frame
  for now. Until then you can use vesa.
 
  I have a computer with Intel graphics and Hipster
  20140701 installed. Xorg refuses to use intel_drv.so
  and falls back on using vesa_drv.so, I understand
  this is not going to improve soon.
 
  The fall back to vesa is totally unusable because the
  brigthness is forced to maximum and hurts the eyes and
  the slider for brightness on Power Management has no
  effect.
 
  Is there another way to adjust the brightness level with
  the vesa driver ?
 
  Jean-Pierre
Hello, Jean-Pierre,

I found a workaround that could be used, if everyone declares that newer
packages in hipster-2015
will not depend on newer X and Intel driver that is non working yet.
(and that could allow testing if it is needed when things improve.

You update to latest hipster-2014.1 or install from 20141010 ISO if it
is new install,
or in a working BE for your intel hardware,
and you enter: (with pfexec or sudo)
pfexec pkg freeze consolidation/X/X-incorporation
pfexec pkg freeze x11/server/xorg/driver/xorg-video-intel

And then add new repository (pkg set-publisher-g , -G to remove old) if
needed, and update (pkg update -v).

That way , if new packages you have installed does not depend on newer X
and intel driver that does not work, you get same packages as
hipster-2015 except X and intel driver consolidations.
And hopefully newer packages won't depend on them, until it is once
solved in illumos and you unfreeze them.



___
oi-dev mailing list
oi-dev@openindiana.org mailto:oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev




___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev






___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [HEADSUP] X server update in OpenIndiana Hipster

[Jean-Pierre André]

Hi Alexander,

Alexander Pyhalov wrote:
[...]

I think we can look at downgrading
intel drivers to something like 2.9 (or even 2.6) which still supported
UMS until KMS work is ready. I don't know how much work it'll take to
make this crap work with new Xorg server, so no promises on time frame
for now. Until then you can use vesa.


I have a computer with Intel graphics and Hipster
20140701 installed. Xorg refuses to use intel_drv.so
and falls back on using vesa_drv.so, I understand
this is not going to improve soon.

The fall back to vesa is totally unusable because the
brigthness is forced to maximum and hurts the eyes and
the slider for brightness on Power Management has no
effect.

Is there another way to adjust the brightness level with
the vesa driver ?

Jean-Pierre


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] oi_151a9 roadmap planning

[Jean-Pierre André]

Hi,

maybird1...@yahoo.com wrote:

Hi Jean-Pierre,

1. Submit hardware issues here (dev only) so we know or file a
feature/bug request.


I would like at least https://www.illumos.org/issues/4097
to be addressed.

Another computer just displays
APIC Error interrupt on CPU 0. Status 0 = 0, Status 1 = 80
when trying to boot OpenIndiana, but I take this as not
fixable.

On the the only compute I can use, I have spent a lot of
time solving https://www.illumos.org/issues/3367 and Jim
Klimov has helped me, but I have never been able to provide
support for WPA encryption. I will try again if somebody
helps me (I will provide more efforts if the issue 4097
is addressed).



2. Ask oi-userland team for IPS integration of your software. FUSE was
in sfe repository.


I got them integrated by Milan two years ago, but he is
so busy... Also wait a few days, a new version is coming.



~ Ken Mays

Sent from Yahoo Mail on Android
https://overview.mail.yahoo.com/mobile/?.src=Android



*From: * Jean-Pierre André jean-pierre.an...@wanadoo.fr;
*To: * oi-dev@openindiana.org;
*Subject: * Re: [oi-dev] oi_151a9 roadmap  planning
*Sent: * Thu, Feb 13, 2014 7:42:54 AM

Hi,

Alan Coopersmith wrote:
  On 02/12/14 12:41 PM, Peter Tribble wrote:
  (Ideally, you want other communities to build and distribute software
  for you. That's one area where IPS is a huge obstacle - all this
  repository stuff is an intolerable burden on third parties,
 
  Nearly all package systems have repositories, what makes IPS more
  intolerable
  than the rest?  (Or had you just not noticed that support for package
  archives,
  basically tarball versions of IPS packages, was added to IPS in years
past?

Oh, great, I did not know.

I have three computers, but the hardware for two of them is
not supported by OI. I can only install OI on third one,
but the WiFi network access is not supported.

So, basically I have to download through Windows or Linux,
but I do not known how to ftp or wget an update, or
anything which is not available in an ISO, from an IPS ?

I am the maintainer of ntfs-3g. How should I deposit an IPS
package on a plain web server I do not control ?
(see http://jp-andre.pagesperso-orange.fr/openindiana-ntfs-3g.html)



  It wasn't there in the 0.1 version used in the initial OpenSolaris
  releases,
  but that was what the kids today call Minimum Viable Product not the
  intended
  final state of features.)
 
  http://docs.oracle.com/cd/E26502_01/html/E21383/pkgcreate.html#gluem
 



___
oi-dev mailing list
oi-dev@openindiana.org javascript:return
http://openindiana.org/mailman/listinfo/oi-dev



___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev






___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] oi_151a9 roadmap planning

[Jean-Pierre André]

Hi,

Alan Coopersmith wrote:

On 02/12/14 12:41 PM, Peter Tribble wrote:

(Ideally, you want other communities to build and distribute software
for you. That's one area where IPS is a huge obstacle - all this
repository stuff is an intolerable burden on third parties,


Nearly all package systems have repositories, what makes IPS more
intolerable
than the rest?   (Or had you just not noticed that support for package
archives,
basically tarball versions of IPS packages, was added to IPS in years past?


Oh, great, I did not know.

I have three computers, but the hardware for two of them is
not supported by OI. I can only install OI on third one,
but the WiFi network access is not supported.

So, basically I have to download through Windows or Linux,
but I do not known how to ftp or wget an update, or
anything which is not available in an ISO, from an IPS ?

I am the maintainer of ntfs-3g. How should I deposit an IPS
package on a plain web server I do not control ?
(see http://jp-andre.pagesperso-orange.fr/openindiana-ntfs-3g.html)



It wasn't there in the 0.1 version used in the initial OpenSolaris
releases,
but that was what the kids today call Minimum Viable Product not the
intended
final state of features.)

http://docs.oracle.com/cd/E26502_01/html/E21383/pkgcreate.html#gluem





___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Resignation as OI Lead

[Jean-Pierre André]

Milan Jurik wrote:

Hi,



[...]
This crap I heard for years inside Sun. Rumor say half of laptops used 
by Sun employees (and paid by Sun) were Macs in last year. And the 
most of core developers were not using Solaris on their laptops. With 
very same excuse. Now the question - why should new ideas grow on 
system in VM and not in platform you are using daily? Why should 
others use my system if even I am using it only to compile code?


Just wanting to mention only the happy few can compile
code on OpenIndiana. I could not even find the basic headers
(stdio.h, etc.) for OpenIndiana downloadable anonymously
(whatever the license).

Think of why no open developer has ported LibreOffice,
whose original design comes AFAIK from Sun.

Regards

Jean-Pierre


___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Resignation as OI Lead

[Jean-Pierre André]

Hi Yuri,

Yuri Pankov wrote:

On Fri, 31 Aug 2012 16:28:46 +0200, Jean-Pierre André wrote:

Milan Jurik wrote:

Hi,



[...]

This crap I heard for years inside Sun. Rumor say half of laptops used
by Sun employees (and paid by Sun) were Macs in last year. And the
most of core developers were not using Solaris on their laptops. With
very same excuse. Now the question - why should new ideas grow on
system in VM and not in platform you are using daily? Why should
others use my system if even I am using it only to compile code?


Just wanting to mention only the happy few can compile
code on OpenIndiana. I could not even find the basic headers
(stdio.h, etc.) for OpenIndiana downloadable anonymously
(whatever the license).

Think of why no open developer has ported LibreOffice,
whose original design comes AFAIK from Sun.


$ pkg search stdio.h
INDEX  ACTION VALUE   PACKAGE
basename   file   opt/gcc/4.4.4/include/c++/4.4.4/tr1/stdio.h

[...]

Great ! it works !

My fault, I am so stupid...

Regards

Jean-Pierre



___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] ntfs-3g and fuse

[Jean-Pierre André]

Hi Milan,

Milan Jurik wrote:

Hi Jean-Pierre,

On 21.08.2012 11:13, Jean-Pierre André wrote:

Hi,


[...]
Jean-Pierre Four years ago, a bug was reported about ntfs-3g on 
OpenSolaris :

http://lists.gnu.org/archive/html/bug-coreutils/2008-08/msg00065.html

This bug was analyzed to be a fuse kernel module bug, but nobody 
apparently
fixed it at the time. This was one of the bugs I fixed last January : 
it was

just caused by fuse not returning the error code to the caller.

I have just noticed that the fuse kernel module was recompiled on sfe on
August 6th, and this is just recompiling the buggy version, with no 
value

added to anybody. It is very buggy and looks like it has never been
debugged. I had to make about 40 fixes.



It should contain few fixes from 
http://src.opensolaris.cz/source/xref/spec-files-extra/patches/fuse-01-jean-pierre.diff 
already but I was busy with fixing other things before I can look at 
your latest version of it. My fault and I plan to fix it soon. 


Well, good news if you spare some time on it.
I can help, of course.

It would be nice if the full history of my changes is
preserved. This is in
http://jp-andre.pagesperso-orange.fr/fuse-kernel-updates.zip

It would be even be nicer if this was put on a source management
repository. I would have put it on sourceforge as git, but
this is probably not allowed by the CDDL license.

Regards

Jean-Pierre



___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] ntfs-3g and fuse

[Jean-Pierre André]

Hi,

I am now releasing the fuse kernel module for OpenIndiana. Ntfs-3g
now fully passes the standard tests with this kernel module and without
need of the workarounds I had to insert earlier to cope with the bad
behavior of the fuse kernel module originated from OpenSolaris.

A few optimizations would still be useful. I might have a look at them
if there is enough demand.

Available on http://b.andre.pagesperso-orange.fr/openindiana-ntfs-3g.html
are three packages ready for use :

- a full ntfs-3g package in 32-bit mode with the fuse-lite library
  and ntfsprogs
- a full ntfs-3g package in 64-bit mode with the fuse-lite library
  and ntfsprogs
- a fuse kernel module package for both the 32-bit and 64-bit modes

The raw source files (not packaged according to OpenIndiana
standards) are also available there.

I am keeping these files available on line for some time. I also keep
the change sets available to whoever enters the source code of the
fuse kernel module into a public source code management
repository.

Enjoy,

Jean-Pierre


Jean-Pierre André wrote:

Hi,

Milan Jurik wrote:

Hi Jean-Pierre,

Jean-Pierre ANDRE píše v út 24. 01. 2012 v 15:16 +0100:

Hi,

As a maintainer of ntfs-3g, I have received bug reports on 
OpenIndiana. Digging into them, I found there were almost all caused 
by the buggy fuse kernel module, which nobody seems to care about. 
So I had to do it myself




___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] ntfs-3g and fuse

[Jean-Pierre André]

Hi,

Milan Jurik wrote:

Hi Jean-Pierre,

Jean-Pierre ANDRE píše v út 24. 01. 2012 v 15:16 +0100:
   

Hi,

As a maintainer of ntfs-3g, I have received bug reports on OpenIndiana. Digging 
into them, I found there were almost all caused by the buggy fuse kernel 
module, which nobody seems to care about. So I had to do it myself
 


I think I have now finished the first level debugging of
the fuse kernel module

With the fixes, ntfs-3g passes the Posix file system test
http://www.tuxera.com/community/posix-test-suite/
except for a single test :

Failed Test   Stat Wstat Total Fail  List of 
Failed

---
/home/linux/fstest/pjd-fstest/tests/open/31  2
Failed 1/191 test scripts. 1/1964 subtests failed.
Files=191, Tests=1964, 351 wallclock secs (19.50 cusr + 99.55 csys = 
119.05 CPU)

Failed 1/191 test programs. 1/1964 subtests failed.

The test which fails is the test for opening a fifo
named by ntfs-3g. Obviously this opening should be
bounced elsewhere, but I have no idea where

There are a few other obscure things, which I cannot
clarify without the help of a Solaris VFS expert.
Reviewing of the code by a Solaris developer would
also be useful : there were a lot of memory leaks,
missing lockings, and forgotten unlockings. There
were obvious deficiencies in the quality management
of the initial version.

In the meantime, I consider the result as a release
candidate.

Please see http://b.andre.pagesperso-orange.fr/openindiana-ntfs-3g.html

By the way, where is the official OpenIndiana source
repository for this ? I saw Milan posting the patches,
but is not clear to me against what the patches were.
I can provide a list of patches per fix for a source
repository management.

Regards

Jean-Pierre




___
oi-dev mailing list
oi-dev@openindiana.org
http://openindiana.org/mailman/listinfo/oi-dev