OS2World OLD-STATIC-BACKUP Forum

OS/2 - Technical => Hardware => Topic started by: Carlo_Warp on 2008.02.29, 22:21:56

Title: Slow boot process
Post by: Carlo_Warp on 2008.02.29, 22:21:56
During the boot process, eCS loads the Uniaudio driver and after that stops 30 seconds. I use eCS 2.0 RC 1and I already updated the Uniaudio driver to 1.1.4 RC5
Title: Re: Slow boot process
Post by: RobertM on 2008.02.29, 23:59:33
Quote from: Carlo_Warp on 2008.02.29, 22:21:56
During the boot process, eCS loads the Uniaudio driver and after that stops 30 seconds. I use eCS 2.0 RC 1and I already updated the Uniaudio driver to 1.1.4 RC5

Do you know what the next driver is that loads? I experience a similar delay on one of my machines and it ended up being the part of the boot process that sets up networking/DHCP. Using UniAudio and don't experience such a delay on the machine with a static IP  - though I do experience a delay during HPFS386 initialization (lots of spanned partitions to check).

-Rob
Title: Re: Slow boot process
Post by: kim on 2008.03.01, 01:04:51
Agree a good guess would be that the system has been set up to use dynamic IP; if not boot the system with ALT+F2 to see what drivers that might slow down the boot process.
Title: Re: Slow boot process
Post by: Pete on 2008.03.01, 02:47:38
Quote from: Carlo_Warp on 2008.02.29, 22:21:56
During the boot process, eCS loads the Uniaudio driver and after that stops 30 seconds. I use eCS 2.0 RC 1and I already updated the Uniaudio driver to 1.1.4 RC5


Hi

I did the update to 114RC5 on a system using an nVidia CK804/Realtek ALC850 sound combo. Result: No sound - and it was also impossible to start some apps, Seamonkey and SysInfo/2 amongst them. I also seem to recall the system pausing during boot for no obvious reason.

Opening a ticket about this resulted in me being told to try the uinaud16.sys RC4 file instead of the RC5 version. System sounds then worked but with a splutter and apps that had stopped working could now be used.

If RC5 seems to be working fine but the boot pause is not something you had prior to installing RC5 I suggest trying the uniaud16.sys file from RC4 to see if that cures the pause. If it does and the sound is not as good as RC4, "spitty" or "spluttery", backlevel the uniaud32.sys file and the \mmos2\dll\uniaud.dll file using the RC4 versions.

OTOH: Is this a dhcp pause?


Regards

Pete


Title: Re: Slow boot process
Post by: Carlo_Warp on 2008.03.01, 11:06:02
I put a REM before the FAT32 driver, but it didn't help. I still have about 30 seconds delay. The driver after the Uniaudio one is C:\OS2\EPW.EXE. I use an ADSL router/modem to acces the internet.

Quote from: RobertM on 2008.02.29, 23:59:33
Quote from: Carlo_Warp on 2008.02.29, 22:21:56
During the boot process, eCS loads the Uniaudio driver and after that stops 30 seconds. I use eCS 2.0 RC 1and I already updated the Uniaudio driver to 1.1.4 RC5

Do you know what the next driver is that loads? I experience a similar delay on one of my machines and it ended up being the part of the boot process that sets up networking/DHCP. Using UniAudio and don't experience such a delay on the machine with a static IP  - though I do experience a delay during HPFS386 initialization (lots of spanned partitions to check).

-Rob
Title: Re: Slow boot process
Post by: Radek on 2008.03.03, 11:15:16
I have experienced the same. The "cigar break" was even considerably longer than 30 sec and it also was just before EPW. The cigar break has been immediately cancelled after removing ACPI from my config.sys.
No other changes in config.sys, therefore, the problem seems to be ACPI related. At least, on my machine.
Title: Re: Slow boot process
Post by: Andi on 2008.03.03, 14:14:39
Quote from: Carlo_Warp on 2008.03.01, 11:06:02
I put a REM before the FAT32 driver, but it didn't help. I still have about 30 seconds delay. The driver after the Uniaudio one is C:\OS2\EPW.EXE. I use an ADSL router/modem to acces the internet.

config.sys is not executed line after line, but instead basedevs, devices, runs, sets.....

I'm also think it's DHCP. You can post your \mptn\bin\setup.cmd to verify this.

With ACPI sometimes it tooks forever to boot on may main machine (about 15 minutes). But this was as I'm using /NOI and /PIC. Deleting /NOI and using /PIC /SMP and there's no pause on boot anymore. But again, check at first if it's DHCP. If you do not like/know ALT-F2, you can create a file at the root directory of the boot drive named altf2on.$$$ which does the same (shows every driver which is loaded at boot up).

Title: Re: Slow boot process
Post by: warpcafe on 2008.03.03, 14:46:13
Hi,

I also agree that my first guess would be some part of networking.
One more question: Is there any WiFi NIC detected and/or are you using GenMac driver(s)?
Reason: I had the problem that everything works fine with my notebook until netbind is executed and fails to connect correctly with the GenMac-driven WiFi... so my question is just to exclude WiFi and GenMac from the list of possible causes...

To finally determine what driver is loading/loaded when the problem happens do the following (Alt-F2 method):
When eCS is booting, you'll have a small white rectangle in the upper left of the (otherwise black) screen. (Also known as the "boot blob"). THAT is the moment to press Alt+F2. The boot process will continue and show all drivers that are loading...

Regards,
Thomas
Title: Re: Slow boot process
Post by: Radek on 2008.03.03, 15:21:31
It was the "Alt-F2" method which denounced the "epw" line. Therefore, EPW or the driver loaded just before or just after it (I am not sure now, whether the stop was on the EPW line or whether EPW was the first line after the stop). I am sure that Carlo did the same.
DHCP should print the time remaining for the search. Therefore, DHCP caused delay should be identified easily. Also, you should get the "Press Enter ..." message after unsuccessful DHCP search.
Title: Re: Slow boot process
Post by: Carlo_Warp on 2008.03.03, 21:08:21
I've attached the file \mptn\bin\setup.cmd

Quote from: Andi on 2008.03.03, 14:14:39
Quote from: Carlo_Warp on 2008.03.01, 11:06:02
I put a REM before the FAT32 driver, but it didn't help. I still have about 30 seconds delay. The driver after the Uniaudio one is C:\OS2\EPW.EXE. I use an ADSL router/modem to acces the internet.

config.sys is not executed line after line, but instead basedevs, devices, runs, sets.....

I'm also think it's DHCP. You can post your \mptn\bin\setup.cmd to verify this.

With ACPI sometimes it tooks forever to boot on may main machine (about 15 minutes). But this was as I'm using /NOI and /PIC. Deleting /NOI and using /PIC /SMP and there's no pause on boot anymore. But again, check at first if it's DHCP. If you do not like/know ALT-F2, you can create a file at the root directory of the boot drive named altf2on.$$$ which does the same (shows every driver which is loaded at boot up).


Title: Re: Slow boot process
Post by: Carlo_Warp on 2008.03.03, 21:11:54
I don't have any WIFi NIC, but I do use the Genmac driver (file 20040127.zip) for the Nforce 2 chipset.

Quote from: warpcafe on 2008.03.03, 14:46:13
Hi,

I also agree that my first guess would be some part of networking.
One more question: Is there any WiFi NIC detected and/or are you using GenMac driver(s)?
Reason: I had the problem that everything works fine with my notebook until netbind is executed and fails to connect correctly with the GenMac-driven WiFi... so my question is just to exclude WiFi and GenMac from the list of possible causes...

To finally determine what driver is loading/loaded when the problem happens do the following (Alt-F2 method):
When eCS is booting, you'll have a small white rectangle in the upper left of the (otherwise black) screen. (Also known as the "boot blob"). THAT is the moment to press Alt+F2. The boot process will continue and show all drivers that are loading...

Regards,
Thomas
Title: Re: Slow boot process
Post by: warpcafe on 2008.03.04, 15:03:28
Hi,

Quote from: Carlo_Warp on 2008.03.03, 21:08:21
I've attached the file \mptn\bin\setup.cmd

thanks! ...yeah, ok. The relevant part is
dhcpstrt -i lan0 -d 0
which means interface lan0 is set up for DHCP and the DHCP client waits for 0 seconds to get an IP.
That again means that it (the DHCP client) continues to get an IP in the background and it should not cause any kind of wait/break during bootup.
But I wonder... isn't there any kind of "press Enter to continue"-message during the bootup?

Just for the fun of it... how about editing your setup.cmd and
- put a REM in front of the "dhcpstrt..."-line (meaning it should read "REM dhcpstrt..." afterwards)
- add a new line that reads "ifconfig lan0 169.254.0.1 netmask 255.255.255.0" (without quotes)
save the file and (re-)boot the machine?

This assigns a static IP to your lan0 interface and will tell us if there is any problem with DHCP (because now, DHCP wouldn't be used any more)... To revert, simply re-edit the setup.cmd, delete the added "ifconfig"-line and remove the "REM" in front of the dhcpstrt -line.

Alternatively, you could also change the "-d 0" part in the above line to "-d 10" for example.
This would enable 10 seconds of delay for the DHCP client to get an IP from the DHCP server (if there's any) and will show you a "countdown"-style message with a "press Enter to continue" afterwards if the client didn't get an IP assigned. If there's no "press enter..." message shown, it means that the DHCP request would have been successful and that DHCP is not an issue but the lockup happens later.

I am sorry if that is all in vain and EPW.EXE really turns out to be the culprit... but let's see. ;-)

One more question:
Is the genmac wrapper helper driver the first line in your config.sys?
(IIRC it's something with "helperw.sys" or similar, sorry, don't have eCS machine at hand...)
While we're at it - why not simply post your entire config.sys?

regards,
Thomas
Title: Re: Slow boot process
Post by: Carlo_Warp on 2008.03.04, 21:24:02
Here is my Config.Sys. There is no message like "press Enter to continue" during the boot process. I will try you othre advices later.


Quote from: warpcafe on 2008.03.04, 15:03:28
Hi,

Quote from: Carlo_Warp on 2008.03.03, 21:08:21
I've attached the file \mptn\bin\setup.cmd

thanks! ...yeah, ok. The relevant part is
dhcpstrt -i lan0 -d 0
which means interface lan0 is set up for DHCP and the DHCP client waits for 0 seconds to get an IP.
That again means that it (the DHCP client) continues to get an IP in the background and it should not cause any kind of wait/break during bootup.
But I wonder... isn't there any kind of "press Enter to continue"-message during the bootup?

Just for the fun of it... how about editing your setup.cmd and
- put a REM in front of the "dhcpstrt..."-line (meaning it should read "REM dhcpstrt..." afterwards)
- add a new line that reads "ifconfig lan0 169.254.0.1 netmask 255.255.255.0" (without quotes)
save the file and (re-)boot the machine?

This assigns a static IP to your lan0 interface and will tell us if there is any problem with DHCP (because now, DHCP wouldn't be used any more)... To revert, simply re-edit the setup.cmd, delete the added "ifconfig"-line and remove the "REM" in front of the dhcpstrt -line.

Alternatively, you could also change the "-d 0" part in the above line to "-d 10" for example.
This would enable 10 seconds of delay for the DHCP client to get an IP from the DHCP server (if there's any) and will show you a "countdown"-style message with a "press Enter to continue" afterwards if the client didn't get an IP assigned. If there's no "press enter..." message shown, it means that the DHCP request would have been successful and that DHCP is not an issue but the lockup happens later.

I am sorry if that is all in vain and EPW.EXE really turns out to be the culprit... but let's see. ;-)

One more question:
Is the genmac wrapper helper driver the first line in your config.sys?
(IIRC it's something with "helperw.sys" or similar, sorry, don't have eCS machine at hand...)
While we're at it - why not simply post your entire config.sys?

regards,
Thomas
Title: Re: Slow boot process
Post by: Andi on 2008.03.05, 14:11:28
From your config.sys I see, it is already sorted. So possible candidates for this hang are midimon.exe or epwrout.exe. First I would try to change the following lines in that way -

REM RUN=C:\MMOS2\mididmon.exe
REM RUN=C:\MMOS2\mmhelpdd.exe
REM RUN=C:\MMOS2\qrymmcd.exe

Second I would try to put a rem in front of RUN=C:\OS2\EPWROUT.EXE 1 too.

And yes, the RUN=C:\ECS\SYSTEM\GENMAC\DRIVER\HELPERW.EXE line should be one of the first lines in the config.sys usually immediate below the unicode.sys. At least this was true for older genmac versions.
Title: Re: Slow boot process
Post by: Carlo_Warp on 2008.03.05, 22:30:44
I did what you suggested, but there is still the 30 seconds stop. Now I can apply the suggestions of Warpcafe.

Quote from: Andi on 2008.03.05, 14:11:28
From your config.sys I see, it is already sorted. So possible candidates for this hang are midimon.exe or epwrout.exe. First I would try to change the following lines in that way -

REM RUN=C:\MMOS2\mididmon.exe
REM RUN=C:\MMOS2\mmhelpdd.exe
REM RUN=C:\MMOS2\qrymmcd.exe

Second I would try to put a rem in front of RUN=C:\OS2\EPWROUT.EXE 1 too.

And yes, the RUN=C:\ECS\SYSTEM\GENMAC\DRIVER\HELPERW.EXE line should be one of the first lines in the config.sys usually immediate below the unicode.sys. At least this was true for older genmac versions.

Title: Re: Slow boot process
Post by: Andi on 2008.03.06, 13:45:14
Maybe there are other \MMOS2 und uniaud instances in the config.sys which you can try to REM out. This would make absolutly clear, that the problem is or is not audio related.

On the other hand, does your network even work after boot? If not, it is most likely a network timeout it think.  The \ibmcom\lantran.log maybe gives some hints in this case.
Title: Re: Slow boot process
Post by: Carlo_Warp on 2008.03.06, 23:14:41
I have attached my Lantran.log file. I will try more solutions later.

Quote from: Andi on 2008.03.06, 13:45:14
Maybe there are other \MMOS2 und uniaud instances in the config.sys which you can try to REM out. This would make absolutly clear, that the problem is or is not audio related.

On the other hand, does your network even work after boot? If not, it is most likely a network timeout it think.  The \ibmcom\lantran.log maybe gives some hints in this case.
Title: Re: Slow boot process
Post by: Carlo_Warp on 2008.03.07, 22:16:48
I applied your suggestion; I put a Rem in front of dhcpstart and I added the new line ifconfig lan0 169.254.0.1 netmask 255.255.255.0 but my router was unable to connect to the internet.

Quote from: warpcafe on 2008.03.04, 15:03:28

Just for the fun of it... how about editing your setup.cmd and
- put a REM in front of the "dhcpstrt..."-line (meaning it should read "REM dhcpstrt..." afterwards)
- add a new line that reads "ifconfig lan0 169.254.0.1 netmask 255.255.255.0" (without quotes)
save the file and (re-)boot the machine?

This assigns a static IP to your lan0 interface and will tell us if there is any problem with DHCP (because now, DHCP wouldn't be used any more)... To revert, simply re-edit the setup.cmd, delete the added "ifconfig"-line and remove the "REM" in front of the dhcpstrt -line.
Title: Re: Slow boot process
Post by: RobertM on 2008.03.07, 22:37:24
If you have a Windows machine on the network, see what it's IP address is (IPCONFIG at a commandline will tell you). Try either using TCPCFG2 or the line above to create a static IP entry (and associated routing info) to correspond with an IP in that same IP block that is not used...

For instance, if your Windows machine is 192.168.1.10 try:
ifconfig lan0 192.168.1.150 netmask 255.255.255.0

or set up the info in TCPCFG2 for "static IP" filling in that number and netmask in the appropriate fields, and then create a routing entry on the appropriate tab for the router (which should be 192.168.1.1 in that example).

Hope that helps...
-Robert

Quote from: Carlo_Warp on 2008.03.07, 22:16:48
I applied your suggestion; I put a Rem in front of dhcpstart and I added the new line ifconfig lan0 169.254.0.1 netmask 255.255.255.0 but my router was unable to connect to the internet.

Quote from: warpcafe on 2008.03.04, 15:03:28

Just for the fun of it... how about editing your setup.cmd and
- put a REM in front of the "dhcpstrt..."-line (meaning it should read "REM dhcpstrt..." afterwards)
- add a new line that reads "ifconfig lan0 169.254.0.1 netmask 255.255.255.0" (without quotes)
save the file and (re-)boot the machine?

This assigns a static IP to your lan0 interface and will tell us if there is any problem with DHCP (because now, DHCP wouldn't be used any more)... To revert, simply re-edit the setup.cmd, delete the added "ifconfig"-line and remove the "REM" in front of the dhcpstrt -line.
Title: Re: Slow boot process
Post by: Pete on 2008.03.07, 23:37:23
Quote from: Carlo_Warp on 2008.03.06, 23:14:41
I have attached my Lantran.log file. I will try more solutions later.


Hi

Your lantran.log has 2 errors showing that suggest there is a problem:-

SYS0318: Message file \MPTN.MSG cannot be found for message  0001.

SYS0318: Message file \MPTN.MSG cannot be found for message  0003.


That message file, mptn.msg, should be in [BootDrive]:\mptn\bin - change [BootDrive] to whatever is correct for your system.

Does the config.sys file have a PATH entry for [BootDrive]:\MPTN\BIN; ? - it should have.

Knowing what the above errors are may be of help  :-)

Regards

Pete
Title: Re: Slow boot process
Post by: Carlo_Warp on 2008.03.08, 15:11:56
Finally I got an unexpected solution!

I decided to install the last Amouse driver and after the reboot I never had the 30 seconds pause again.
The problem was the mouse driver...

Thank you for your suggestions related to the network.




Hi

Your lantran.log has 2 errors showing that suggest there is a problem:-

SYS0318: Message file \MPTN.MSG cannot be found for message  0001.

SYS0318: Message file \MPTN.MSG cannot be found for message  0003.


That message file, mptn.msg, should be in [BootDrive]:\mptn\bin - change [BootDrive] to whatever is correct for your system.

Does the config.sys file have a PATH entry for [BootDrive]:\MPTN\BIN; ? - it should have.

Knowing what the above errors are may be of help  :-)

Regards

Pete
[/quote]