OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Setup & Installation => Topic started by: mcs_5 on August 24, 2016, 03:28:32 am

Title: eCS install problems on a recent mainboard
Post by: mcs_5 on August 24, 2016, 03:28:32 am
I have just attempted, unsuccessfully, to install eCS on a system based on an Asrock mini-itx mainboard. The board is a Q1900-ITX with a 4-core Celeron. The disk is a Samsung SSD connected to a SATA port controlled by the Intel chipset.

If I select the ACPI option in the boot menu, the system boots to the installer without complaints. The disk is detected with either the AHCI driver or the Dani driver, depending on the mode I select in the UEFI setup. But if I use AHCI, I'm unable to format partitions in HPFS format. If I try in a command line, I get the error that not enough memory is available to run format Formatting with JFS works. If I use ATA-mode, both HPFS and JFS formatting work.

But after the first install phase has completed, the disk in not bootable. Or not detected as bootable by the UEFI firmware?

I have tried with both eCS 2.1 and 2.2 beta, and the same thing happens. No error messages, but the system won't boot from the disk and complete the install. Any advice?
Title: Re: eCS install problems on a recent mainboard
Post by: rdunkle on August 24, 2016, 10:14:24 am
Perhaps if you enter the BIOS setup program and enable the CSM (Compatibility Support Module).  It is under the Boot icon in the BIOS setup. Then start the install again.
Title: Re: eCS install problems on a recent mainboard
Post by: mcs_5 on August 24, 2016, 12:51:44 pm
CSM is enabled - it was enabled in the default settings.

And I guess CSM would have to be enabled, for the eCS boot CD to work?
Title: Re: eCS install problems on a recent mainboard
Post by: Martin Iturbide on August 24, 2016, 03:01:30 pm
Hi Mikkel, welcome to the forums.

eCS cd boots on your  Asrock Q1900-ITX (http://www.asrock.com/mb/Intel/Q1900-ITX/index.es.asp), which seems a positive thing.

It is very strange that if you enable AHCI (on the BIOS and on the eCS boot menu) it does not want to format the drive.

After the first install phase you don't get anything on OS/2-eCS? The little square on top? You can not do an Alt+F1? or it shows the common message like there is no OS installed on the HDD and the BIOS  tries to boot from other source?

One wild guess would be to double check your install media. Sometimes I got very strange behavior from corrupted CDs.

My other guess will be to try if there any things on the UEFI secure boot on the BIOS and try to turn it off.

Maybe someone with more experience can share more thoughts.
Regards
Title: Re: eCS install problems on a recent mainboard
Post by: mcs_5 on August 24, 2016, 05:32:35 pm
I did some more testing. I found an old HP system in the junk pile at work (Core2 Duo CPU). I installed the Samsung disk, and it was still unbootable. If I force the system to boot from disk, all I get is a flashing cursor in the upper left corner.

I then tried re-installing eCS on the HP system, and I got the same thing. First phase of the install completes, but the disk remains unbootable.

Next step was to wipe the first MB of the disk, and create partitions using DFSee. DFSee did warn that the disk was not bootable, before I re-partitioned it. I then ran the installation on the HP system again, and now the install completes.

So whatever went wrong during the first install (something in the MBR I guess), was not fixed by subsequent installs.

But now it runs on the HP system, so I just have to try moving the disk back to the mini-ITX system...
Title: Re: eCS install problems on a recent mainboard
Post by: mcs_5 on August 24, 2016, 06:48:12 pm
Another update. I installed the latest ACPI, AHCI and USB drivers from Arca Noae while the disk was in the HP system. I then moved it to the system with the Asrock board. And it boots!

All four CPU cores are detected, and after installing the Realtek NIC driver, that seems to be working also.

But there is a weird problem I have never seen before. If I try to open a command line (windowed or fullscreen) it exits immediately. What could cause this?

If you try to open a DOS window, you get complaints about missing video support, but I have read about that somewhere before. That is not a huge problem, but having no command line access is ;)
Title: Re: eCS install problems on a recent mainboard
Post by: mcs_5 on August 24, 2016, 10:53:54 pm
It's not looking good...

If I enable AHCI mode, the system hangs for a long time after printing the line "Unicode translate table for CP 850 loaded."  If I leave the system alone at that point, I get a trap screen after some minutes.

In IDE/ATA mode the system works better, but very slowly. Danis506 runs the disk in PIO4 mode (because the controller is not recognized?), which results in the stellar read/write speed of 2MB/s according to SysBench...

I thought the NIC was working, but the driver is just installed without error messages. But if I try to transfer data (ping etc.) no packets actually get through. I have tried the MMRE, R8169 and R8110 drivers. They all install, but none of them actually work. According to PCI.EXE, the NIC is a 10EC:8168.

No USB ports work. The drivers report that no USB controllers are found during boot. According to the docs the board should include both USB2 and USB3 ports, but the USB2 ports are not discovered .

But some change I made (removing the command line options of ACPI.PSD? changing NIC drivers?), made the command line work again.

I guess I should look for a board that works better ;)

But are there any relevant tests I should perform, to get some feedback for the driver developers?
Title: Re: eCS install problems on a recent mainboard
Post by: Lars on August 25, 2016, 06:40:57 pm
For AHCI:
1) make sure it's set to AHCI in BIOS
2) use OS2AHCI.ADD (of course)
3) try the /!R for OS2AHCI.ADD. I already had to specify this switch on installation. It prevents reset of the SATA ports on system start.

For OS2AHCI.ADD you can also try /F and /N switches. These switches should improve performance (enable command queuing, force usage of disk HW cache).

Lars
Title: Re: eCS install problems on a recent mainboard
Post by: Roderick Klein on August 27, 2016, 10:49:33 pm
It's not looking good...

If I enable AHCI mode, the system hangs for a long time after printing the line "Unicode translate table for CP 850 loaded."  If I leave the system alone at that point, I get a trap screen after some minutes.

In IDE/ATA mode the system works better, but very slowly. Danis506 runs the disk in PIO4 mode (because the controller is not recognized?), which results in the stellar read/write speed of 2MB/s according to SysBench...

I thought the NIC was working, but the driver is just installed without error messages. But if I try to transfer data (ping etc.) no packets actually get through. I have tried the MMRE, R8169 and R8110 drivers. They all install, but none of them actually work. According to PCI.EXE, the NIC is a 10EC:8168.

No USB ports work. The drivers report that no USB controllers are found during boot. According to the docs the board should include both USB2 and USB3 ports, but the USB2 ports are not discovered .

But some change I made (removing the command line options of ACPI.PSD? changing NIC drivers?), made the command line work again.

I guess I should look for a board that works better ;)

But are there any relevant tests I should perform, to get some feedback for the driver developers?

It's not looking good...

If I enable AHCI mode, the system hangs for a long time after printing the line "Unicode translate table for CP 850 loaded."  If I leave the system alone at that point, I get a trap screen after some minutes.

In IDE/ATA mode the system works better, but very slowly. Danis506 runs the disk in PIO4 mode (because the controller is not recognized?), which results in the stellar read/write speed of 2MB/s according to SysBench...

I thought the NIC was working, but the driver is just installed without error messages. But if I try to transfer data (ping etc.) no packets actually get through. I have tried the MMRE, R8169 and R8110 drivers. They all install, but none of them actually work. According to PCI.EXE, the NIC is a 10EC:8168.

No USB ports work. The drivers report that no USB controllers are found during boot. According to the docs the board should include both USB2 and USB3 ports, but the USB2 ports are not discovered .

But some change I made (removing the command line options of ACPI.PSD? changing NIC drivers?), made the command line work again.

I guess I should look for a board that works better ;)

But are there any relevant tests I should perform, to get some feedback for the driver developers?

The first question that comes to mind ? Post *what* the trap screen mentioned. Did it it mention what driver (module the kernel posted when you had the OS2ACHI driver installed. Since netbind.exe has already loaded (I think) it should have already written some info to disc OS/2. Do you have earlymeminit=true in your config.sys.
If not your kernel memory to load drivers might get exhausted to fast.

Did a DOS command line not work or an OS/2 command line. You could try loading ACPI.PSD with the option /MAXCPU=1 and see if that fixes the problem. Infact removing the PSD and loading the system in PIC mode might introduce some other issue's if this computer only operated correctly running in APIC mode.

Just some off my thoughts.

Roderick Klein
Title: Re: eCS install problems on a recent mainboard
Post by: Andreas Schnellbacher on August 28, 2016, 01:06:50 am
Additionally to that what Roderick wrote, you could test the parameter /VW (virtual wire) for ACPI. That is required for quite some mainboards to work.
Title: Re: eCS install problems on a recent mainboard
Post by: mcs_5 on August 30, 2016, 05:38:23 pm
The first question that comes to mind ? Post *what* the trap screen mentioned. Did it it mention what driver (module the kernel posted when you had the OS2ACHI driver installed.

It's not one of the "usual" trap screens I have seen many times. It does not mention a driver. Here's what's printed:

Code: [Select]
The system detected an internal processing error at
location ##1800:1b4e - 0003:1b4e
60000, 2008

10860673
Internal revision 14.105_SMP


Quote
Since netbind.exe has already loaded (I think) it should have already written some info to disc OS/2.

Where should I look for that info?


Quote
Do you have earlymeminit=true in your config.sys.
If not your kernel memory to load drivers might get exhausted to fast.

Yes. I have not changed the default settings.


Quote
Did a DOS command line not work or an OS/2 command line. You could try loading ACPI.PSD with the option /MAXCPU=1 and see if that fixes the problem. Infact removing the PSD and loading the system in PIC mode might introduce some other issue's if this computer only operated correctly running in APIC mode.

It was the OS/2 command line that did not work at all. But some change I made fixed it. I will try some of the other suggestions here also.

Mikkel
Title: Re: eCS install problems on a recent mainboard
Post by: mcs_5 on August 30, 2016, 10:34:25 pm
I have tried some different AHCI/ACPI combinations now.

/VW on ACPI.PSD works in ATA mode. In AHCI mode the system still hangs, with the same trap screen.

In PIC mode, both ATA and AHCI mode works - but without SMP of course.

I got performance in ATA mode improved also. I noticed that the driver does not recognize the controller, but If I add /GBM to the DANIS506.ADD line, I get much improved performance. Throughput increases from about 2MB/s to about 150MB/s.

I ran some SysBench tests. PM, DIVE and memory benchmarks stay about the same in PIC, VW and default ACPI mode. But the CPU tests get a remarkable boost in ACPI/SMP mode. In PIC mode I get 1738/133 (integer/float) and in ACPI/SMP mode 6791/466! Does SysBench run the tests multithreaded, or does ACPI do some "magic" tuning?

But without USB and networking, the system is still not entirely useful ;)
Title: Re: eCS install problems on a recent mainboard
Post by: Neil Waldhauer on September 02, 2016, 03:44:03 pm
Ouch. That is pretty slow for a modern computer.

Yes, Sysbench runs CPU test multi-threaded. Most OS/2 usage is single threaded, so the higher speed for four cores can be pretty misleading.

My three generations back (but still available new) computer is running more than twice the speed for i7 and nearly twice for dual core celeron. By the way, Celeron all the way for OS/2. i7 gave very little additional performance for a lot of additional money.
Title: Re: eCS install problems on a recent mainboard
Post by: OS4User on September 02, 2016, 06:05:04 pm
... i7 gave very little additional performance...

Try to compare DIVE -> Video bus bandwidth on Celeron and on i7.
This mark is most important for screen update speed in Panorama.
Title: Re: eCS install problems on a recent mainboard
Post by: Roderick Klein on September 02, 2016, 09:35:25 pm
The first question that comes to mind ? Post *what* the trap screen mentioned. Did it it mention what driver (module the kernel posted when you had the OS2ACHI driver installed.

It's not one of the "usual" trap screens I have seen many times. It does not mention a driver. Here's what's printed:

Code: [Select]
The system detected an internal processing error at
location ##1800:1b4e - 0003:1b4e
60000, 2008

10860673
Internal revision 14.105_SMP


Quote
Since netbind.exe has already loaded (I think) it should have already written some info to disc OS/2.

Where should I look for that info?


Quote
Do you have earlymeminit=true in your config.sys.
If not your kernel memory to load drivers might get exhausted to fast.

Yes. I have not changed the default settings.


Quote
Did a DOS command line not work or an OS/2 command line. You could try loading ACPI.PSD with the option /MAXCPU=1 and see if that fixes the problem. Infact removing the PSD and loading the system in PIC mode might introduce some other issue's if this computer only operated correctly running in APIC mode.

It was the OS/2 command line that did not work at all. But some change I made fixed it. I will try some of the other suggestions here also.

Mikkel

Oke with such a TRAP I guess you need open a support ticket at Arca Noae. While  a module name in a TRAP is not always a reliable method, but you might get a hint which module potentially caused the trap.

Which category the ticket would need to be opened at AN I do not. But this trap occurs when you boot with OS2AHCI driver ? Open a ticket then for that, that is if you want to see if this defect can be fixed.

I guess the TRAP is beyond the skillset of the members in this forum. In fact I would not be surprised if a memory dump MIGHT be needed to find out why this TRAP occurs.

Roderick Klein
Title: Re: eCS install problems on a recent mainboard
Post by: mcs_5 on September 03, 2016, 12:20:53 am
Ouch. That is pretty slow for a modern computer.

Yes, but this is a 10W CPU.  I'm looking for a replacement for an 8-year old system with a 100W+ CPU. Something quiet with low power consumption. I don't think it will be much slower (if it is at all), than the system it's meant to replace.


Quote
Yes, Sysbench runs CPU test multi-threaded. Most OS/2 usage is single threaded, so the higher speed for four cores can be pretty misleading.

The system runs multi-threaded software like Weasel and Goserve, so the extra cores do come in handy. But yes. A 12-core system would be a waste - 2-4 cores are useable.
Title: Re: eCS install problems on a recent mainboard
Post by: OS4User on September 03, 2016, 09:08:13 am

Code: [Select]
The system detected an internal processing error at
location ##1800:1b4e - 0003:1b4e
60000, 2008

10860673
Internal revision 14.105_SMP

It is not "Trap", it is "Panic" -  kernel recognized condition in which it is impossible to continue execution of its own code.

Shown Panic is called "DevHlp Usage Error" and in the original kernel it may happen for quite a few reasons.

At the same time, I saw a positive report about running OS/2 on similar mobo  - Asrock Q1900B-ITX (I do not know how important the letter "B" is) but with OS/4 kernel http://www.os2world.com/wiki/index.php/Phoenix_OS/4#OS.2F4_Tested_Hardware_List (http://www.os2world.com/wiki/index.php/Phoenix_OS/4#OS.2F4_Tested_Hardware_List)

I do not think that it was working because of using OS/4  - so keep trying to change you settings.
Title: Re: eCS install problems on a recent mainboard
Post by: mcs_5 on September 27, 2016, 08:50:11 pm
At the same time, I saw a positive report about running OS/2 on similar mobo  - Asrock Q1900B-ITX (I do not know how important the letter "B" is) but with OS/4 kernel http://www.os2world.com/wiki/index.php/Phoenix_OS/4#OS.2F4_Tested_Hardware_List (http://www.os2world.com/wiki/index.php/Phoenix_OS/4#OS.2F4_Tested_Hardware_List)

I do not think that it was working because of using OS/4  - so keep trying to change you settings.

This report does not mention USB, which is one of the problems I had left.

The J1900 mainboard is now in a FreeBSD system. The NIC works fine, using the same "re" driver that the Arca Noae MMRE driver is based on - which is slightly weird...

I bought two new mainboards to test - I hope to eventually find one that works completely :)

These two are ASRocks again - I have no particular like/dislike for ASRock, but my supplier Reichelt stocks a lot of them. They are the C70M1 and the QC5000M-ITX/PH. Both are based on AMD APUs, but the C70M1 is very cheap, and not very fast.

The good news first: The C70M1 system booted without any problems! Both the MMRE and the R8169 NIC drivers work. USB seems to work also. AHCI and ACPI works with default settings. The only thing not working (I haven't tested stuff like audio), is the PS/2 combo port. Connecting a keyboard works, but if you connect both keyboard and mouse neither work - but this is clearly a hardware problem, as the problem is also present in the setup utility.

The not so good news: The QC5000 system also boots (with both keyboard and mouse working), but networking is flaky. If you ping another local system, you get 15-20% dropped packets, and some take 2-3 seconds to get through. According to acpistat the systems runs in VW-mode, meaning nearly everything is on one shared (low) IRQ. I guess that could be the cause of the network drop-outs?
According to a changelog document on Arca Noae's website, the later ACPI drivers automatically switch to VW-mode, when they encounter a non-supported system configuration.

The C70 is about half as fast as the QC5000 (per core), so I would like to get the faster system running... The SysBench numbers (int/float) are 1911/129 for the C70 (dual core) and 6817/400 for the QC5000 (quad core) - so the QC5000 is about the same speed as the J1900.
Title: Re: eCS install problems on a recent mainboard
Post by: Doug Bissett on September 27, 2016, 10:00:35 pm
Quote
The not so good news: The QC5000 system also boots (with both keyboard and mouse working), but networking is flaky. If you ping another local system, you get 15-20% dropped packets, and some take 2-3 seconds to get through. According to acpistat the systems runs in VW-mode, meaning nearly everything is on one shared (low) IRQ. I guess that could be the cause of the network drop-outs?

IRQ usage, or VW mode, is not likely to cause network drop-out problems, although I have never seen a case where ACPI would drop back to VW mode.

I had a problem using a plug in PCI card, with a Realtek 8169 on it, when using the R8169 driver. It would work fine, for about a minute, then it got really slow. PING dropped packets, and if you looked at the data that was returned, the packets were returned out of order. The latest MMRE driver fixed the problem, for me.
Title: Re: eCS install problems on a recent mainboard
Post by: Dave Yeo on September 28, 2016, 04:30:21 am
I had a Realtek PCI card that would work for a few minutes, getting slower and slower and then stop working. I moved it to a PCI slot with a dedicated IRQ and that fixed the problem.
My understanding of Realtek network cards/chips is that they use the CPU more then other network chips, which is one reason for their crappy performance.
Title: Re: eCS install problems on a recent mainboard
Post by: mcs_5 on September 28, 2016, 03:52:14 pm
My understanding of Realtek network cards/chips is that they use the CPU more then other network chips, which is one reason for their crappy performance.

This is a problem with some of them at least. This is also why I suspect sharing the IRQ with every other device in the system, could cause problems. If the interrupts are not serviced fast enough, some packets could get lost in the (probably too small) buffers.
Title: Re: eCS install problems on a recent mainboard
Post by: Pete on September 30, 2016, 05:28:04 pm
Hi All

@Mikkel

I'm running a Gigabyte 990FXA-UD3 mainboard which has an onboard Realtek RTL8168 using the current Arca Noae r8169.os2 driver which works fine. I have read somewhere, possibly within these forums, that success with the Realtek nics can depend on the Revision number; this nic is a 10ECh:8168h and is Revision 006 - only discovered by running the Windows Device Manager. I suspect the Revision number is related to some sort of change to the nic hardware.

It may be that I am lucky in that the nic shares IRQ10 with only 3 other devices.


@Doug

Prior to very recent releases of ACPI this mainboard actually required the /VW parameter on the acpi config.sys line to avoid hardware problems including the nic suddenly stopping working. The later versions of ACPI do not need the /VW parameter as the driver works out if the system needs to work in VW mode and switches to it if necessary - as with this mainboard. If I remember correctly VW mode limits the number of IRQs available to either equal to or less than the maximum number of IRQs that OS/2 can handle - I think I read somewhere that is 32. So, Yes, current ACPI drops back to VW mode if necessary.



Regards

Pete


Title: Re: eCS install problems on a recent mainboard
Post by: Andreas Schnellbacher on September 30, 2016, 06:45:41 pm
So, Yes, current ACPI drops back to VW mode if necessary.
Unfortunately not for every hardware: My board requires /VW to work. I have a MSI A88X-G41 PC Mate.

Moreover, David's Realtek driver doesn't work here. Newer version won't get an IRQ assigned (see \ibmcom\lantran.log). One older version has good transfer rates, but connected extremely slow -- useless for web pages.
Title: Re: eCS install problems on a recent mainboard
Post by: Doug Bissett on September 30, 2016, 11:10:13 pm
Quote
I'm running a Gigabyte 990FXA-UD3 mainboard which has an onboard Realtek RTL8168 using the current Arca Noae r8169.os2 driver which works fine.

You should try the MMRE driver. It works with all of my Realtek gigabit NICS.

Quote
If I remember correctly VW mode limits the number of IRQs available to either equal to or less than the maximum number of IRQs that OS/2 can handle - I think I read somewhere that is 32.

I believe that VW just uses the lower 16 IRQs. whether that is what your main board needs, or not, I don't know.

Quote
Moreover, David's Realtek driver doesn't work here. Newer version won't get an IRQ assigned (see \ibmcom\lantran.log).

MMRE is from the BSD driver. It works for every Realtek gigabit NIC that I have  (6 of them). R8169 is from Linux (Red Hat, I think), and it won't work with two of them. I hope you submitted a problem report, so the problem can be fixed. It seems that MMRE will be used going forward.

FWIW, Realtek NICs are not very good, but motherboard builders like them because they are cheap. It has been my experience, that Intel NICs are the way to go for reliability, and performance.
Title: Re: eCS install problems on a recent mainboard
Post by: Andreas Schnellbacher on October 02, 2016, 08:48:40 pm
MMRE is from the BSD driver. It works for every Realtek gigabit NIC that I have  (6 of them). R8169 is from Linux (Red Hat, I think), and it won't work with two of them. I hope you submitted a problem report, so the problem can be fixed. It seems that MMRE will be used going forward.
In the past David said that he doesn't own a Realtek device and that therefore it's not well supported. IIRC, he just made the driver compile with his toolkit and the newest Free BSD sources. See the bugtracker for details.
Title: Re: eCS install problems on a recent mainboard
Post by: Doug Bissett on October 02, 2016, 10:45:49 pm
Quote
In the past David said that he doesn't own a Realtek device and that therefore it's not well supported. IIRC, he just made the driver compile with his toolkit and the newest Free BSD sources. See the bugtracker for details.

I believe that David has a few Realtek devices now. The statement that he just compiled from the BSD driver source seems to be true for all of the drivers, not just the Realtek versions. I also use the E1000B driver, for Intel, and the MMLEM driver, for use with virtual machines (VBOX), and they work well too.

From what i understand, the sources for Linux have been incorporated into the Linux Kernel, so it has become very difficult to simply lift that code, and make it work for OS/2. The BSD sources are much more user friendly, so that will be where we get future NIC drivers.
Title: Re: eCS install problems on a recent mainboard
Post by: Paul Smedley on October 02, 2016, 10:49:10 pm
From what i understand, the sources for Linux have been incorporated into the Linux Kernel, so it has become very difficult to simply lift that code, and make it work for OS/2. The BSD sources are much more user friendly, so that will be where we get future NIC drivers.

The same as the above happened with ALSA - makes it very difficult to support new sound devices on OS/2.

Cheers,

Paul
Title: Re: eCS install problems on a recent mainboard
Post by: Pete on October 11, 2016, 03:23:47 pm
Hi All

Following Dougs recommendation I decided to give the MMRE driver a try so Changed nic driver from R8169 to MMRE and rebooted.  After a short period of use the system locked up - no idea why - and required a press of the Reset button to restart. After the restart I had no nic connectivity. I tried another reboot - still no connectivity; driver shows as loaded but ping fails to contact any ip address.

To check the problem was not hardware failure I booted my Windows7 installation. No problem with the nic, all works fine.

I rebooted into eCS2.1+ and the nic worked fine and has since, 3 days, with no unexplained lockups.

I am wondering if booting Windows7 reset something in the hardware making it more "OS/2 friendly"? - Might be worth a try for those people with Realtek nics that load and do not work.


I see the latest ACPI supports 64 interrupts removing the need for switching to /VW mode which may help with problems mentioned in this discussion.


Regards

Pete
Title: Re: eCS install problems on a recent mainboard
Post by: Doug Bissett on October 11, 2016, 07:47:50 pm
Quote
Following Dougs recommendation I decided to give the MMRE driver a try so Changed nic driver from R8169 to MMRE and rebooted.  After a short period of use the system locked up - no idea why - and required a press of the Reset button to restart. After the restart I had no nic connectivity. I tried another reboot - still no connectivity; driver shows as loaded but ping fails to contact any ip address.

To check the problem was not hardware failure I booted my Windows7 installation. No problem with the nic, all works fine.

I rebooted into eCS2.1+ and the nic worked fine and has since, 3 days, with no unexplained lockups.

I am wondering if booting Windows7 reset something in the hardware making it more "OS/2 friendly"? - Might be worth a try for those people with Realtek nics that load and do not work.

Did you use the 1005 version., or the 1008 version. The 1005 version has a problem that caused a TRAP 0008 when it loaded, for me. Apparently all of the 1005 drivers have the same problem, so be sure to update if necessary.
Title: Re: eCS install problems on a recent mainboard
Post by: Pete on October 12, 2016, 12:55:17 am
Hi Doug

Using the latest MMRE from https://www.arcanoae.com/new-multimac-nic-driver-package-20161008-released/

Regards

Pete
Title: Re: eCS install problems on a recent mainboard
Post by: Doug Bissett on October 12, 2016, 08:17:41 am
A few years ago, I had a similar problem with the first Realtek driver. It would run for a few minutes, then turn off the cable interface (look at the indicators on your router). The only way to get it turned back on, was to totally power off the machine (pull the cord, and battery). Even windows wouldn't turn it back on. It seemed to work, just like a NIC with no cable attached. However, that doesn't sound like what you describe, and I haven't seen that trick again. See what happens, I guess.