• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Slow boot process

Started by Carlo_Warp, 2008.02.29, 22:21:56

Previous topic - Next topic

Carlo_Warp

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

RobertM

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


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


kim

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.

Pete

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



Carlo_Warp

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

Radek

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.

Andi

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).


warpcafe

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
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

Radek

#8
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.

Carlo_Warp

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).



Carlo_Warp

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

warpcafe

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
"It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that"
- G.H. Hardy

Carlo_Warp

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

Andi

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.

Carlo_Warp

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.