[haiku] Re: Minor issues with Haiku on Asus Z97-PRO with Intel 4790K

  • From: Adrien Destugues <pulkomandy@xxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Sun, 12 Apr 2015 09:18:58 +0200

On Sat, Apr 11, 2015 at 07:50:46PM -0700, Chris Hanson wrote:

Thanks for all the detailed help! I can't believe I forgot to mention that
I'd installed a “nightly” from yesterday (hrev49020, the x86_gcc2_hybrid for
the moment[1]). I'll work on opening proper issues in the tracker.

In the meantime, it looks like the Intel I218-V used by my chipset should
already be should be supported by the ipro1000 driver, but it looks like my
system is trying to use the pegasus driver. Is there an easy way to say “try
loading this driver” from the command line, a la kextload in Darwin?

Our driver architecture is a bit different than what is used on other
systems, I think. There is no way to force loading of a driver. On boot,
all drivers will be loaded and will check the PCI (USB, …) device list
to see if there is some hardware they can handle. If not, they will
unload themselves. This explains why you see other drivers (eg. the
pegasus one) logging things to the syslog.

To load a driver, all you need to do is installing it in the right
directory. The driver must go in
and a symlink to it in /system/non-packaged/add-ons/kernel/drivers/dev/net/.
Drivers installed this way should be loaded immediately without need for
a reboot, IIRC.

-- Chris

[1] Should Ibother with this, or just dive into the x86_64 builds if I don't
care about BeOS R5 binary compatibility? It's too bad the work on fat
binaries never made it into the mainline, I'd be happy to sacrifice a little
storage to using the best available architecture for anything in particular,
rather than run everything as a single architecture.

The gcc2hybrid build is the most supported one. This means there are
more packages available in the repositories, and some more drivers
available (mostly for 1990 era hardware), which we didn't make 64-bit
compliant yet.

The fat binary support is orthogonal to this, the gcc2hybrid install can
run gcc2 and gcc4 compiled applications just fine (packages suffixed
with _x86 are built with gcc4). These are already 2 different

Running 32 and 64 bit applications side by side is not a problem of
putting both versions in a single ELF file as fat binaries would do. It
is a problem of making the 64-bit kernel able to process syscalls using
32-bit pointers, and convert them back to 64-bit ones for internal

So, x86_64 is fine if you don't mind using haikuporter from time to time
to compile the missing apps (or asking the devs on IRC to do it). This
problem will solve itself when we automate the process of populating the
package repository. At this point the bots doing the work will treat all
the architectures equally.


Other related posts: