• 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

Very odd Networking / Internet issue

Started by craigm, 2010.07.29, 17:21:16

Previous topic - Next topic

craigm

Ok...weird situation here:

When eCS 2.0 boots up everything runs very smoothly. I can get on the Internet and things are fast, life is good.

I run three programs on the Internet most of the time:

1. Firefox - ver 3.5.3
2. FTP Browser - 1.71
3. GTIRC - Ver - 3.00

After 30 minutes (to the second), Anything that is on the Internet loses connection and I go no where. The very weird thing is that GTIRC still works!?!? I still can have and receive conversations will people for hours. The only way I can get Firefox and FTP Browser working again is to reboot, then the clock starts again until 30 min elapses, then I have to reboot again if I want to surf.

Sorry...this one is weird, not sure where to even start.

Saijin_Naib

I think I may have seen this issue before...
Run down your hardware and software specs for me please.

craigm

I have attached a picture of my info, I hope this helps.

Besides what is listed, I have a Linksys router (WRT54G) and I have DSL with ATT.

My nextwork card is a Realtec chipset 8139/8130/x810 Fast Eithernet adapter.

Thanks!

RobertM

(2) Try the RTL8139 adapter driver on Hobbes.
(1) Ensure the RTL8139 does not share an IRQ.

Best,
Rob


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


warpcafe

Hi,

based on what you explained (GTIRC still works, the others not), my first guess would be: GTIRC is to blame. :)

Okay, seriously:
What happens if you run only Firefox and/or the FTP browser - but not GTIRC?
Also, does the order in which the programs are started (if all 3 are started) make a difference?

HTH,
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

Saijin_Naib

You don't happen to have GenMac/Xwlan installed do you?

I seem to remember hearing that they exhibited similar issues.

craigm

Saijin_Naib,

I don't think I have them installed since I have never heard of those programs...

&

warpcafe ,

For a month or more I only had Firefox running. I then installed GTIRC and noticed it working after the 30 min limit. The reason I installed FTP Browser was because I was doing my FTP though firefox, when GTIRC was lasting longer than 30 min I thought it was a Firefox problem so I installed FTP Browser, unfortunately it also has the same problem with losing connection after 30 min.

&

RobertM,

I go my network driver from hobbies and the driver you suggested is what I use.

Where can I see if there is an IRQ Conflict?

Thanks again everyone!

Saijin_Naib

IRQ conflict should show up in the Hardware Manager.
Or check IRQMon v1.1, it is what I was using to track down issues on an install.
http://hobbes.nmsu.edu/h-viewer.php?dir=/pub/os2/util/system&file=irqmon11.zip&backto=%2Fh-search.php%3Fkey%3DIRQ%26pushbutton%3DSearch

craigm

I installed that IRQ software and it pegged my CPU!!!

I was able to take a picture of it before I REMed it out in the config.sys

Saijin_Naib

Well, it doesn't look like anything is sharing in the low IRQ range.

Do you have UniAud installed for sound driver?

ivan

For a start IRQMon is not the correct program to find our what IRQs have been allocated - it only monitors the use of IRQs and you have to supply the names of the devices to the program.

You need to go to a command prompt and use RMVIEW /IRQ it will give something like the following from one of my systems:

[C:\]>rmview /irq
RMVIEW: Physical view
  IRQ Level =  0  PCI Pin = NONE  Flg = EXCLUSIVE    TIMER_CH_0
  IRQ Level =  1  PCI Pin = NONE  Flg = EXCLUSIVE    KBD_0 Keyboard Controller
  IRQ Level =  2  PCI Pin = NONE  Flg = EXCLUSIVE    PIC_1
  IRQ Level =  4  PCI Pin = NONE  Flg = MULTIPLEXED  SERIAL_0 Serial Controller
  IRQ Level =  6  PCI Pin = NONE  Flg = MULTIPLEXED  FLOPPY_0 Floppy Controller
  IRQ Level =  7  PCI Pin = A     Flg = SHARED       ETHERNET_0 Realtek 8100B/81
39D
  IRQ Level =  8  PCI Pin = NONE  Flg = EXCLUSIVE    RTC
  IRQ Level =  9  PCI Pin = A     Flg = SHARED       OHCI Compliant USB Host Con
troller
  IRQ Level = 10  PCI Pin = A     Flg = SHARED       IDE_2 xATA Controller
  IRQ Level = 10  PCI Pin = B     Flg = SHARED       OHCI Compliant USB Host Con
troller
  IRQ Level = 11  PCI Pin = C     Flg = SHARED       EHCI Compliant USB Host Con
troller
  IRQ Level = 12  PCI Pin = NONE  Flg = EXCLUSIVE    AUX_0 PS/2 Auxiliary Device
Controller
  IRQ Level = 14  PCI Pin = NONE  Flg = EXCLUSIVE    IDE_0 xATA Controller
  IRQ Level = 15  PCI Pin = NONE  Flg = EXCLUSIVE    IDE_1 xATA Controller

Notice the Realtek NIC is flagged as a shared IRQ and will do so without problems - I'm using the same driver as you.

That being said there is a possibility that it might be sharing with something on your system that does not like sharing and hence a possible conflict.

The sound driver might be the problem but I am using it on the above system (IRQ 3) without problems.

ivan

RobertM

#11
Quote from: ivan on 2010.07.30, 16:13:50

RMVIEW: Physical view
 IRQ Level =  7  PCI Pin = A     Flg = SHARED       ETHERNET_0 Realtek 8100B/8139D


Notice the Realtek NIC is flagged as a shared IRQ and will do so without problems - I'm using the same driver as you.

That being said there is a possibility that it might be sharing with something on your system that does not like sharing and hence a possible conflict.

ivan

My first suggestion, (Ivan is correct. The Realtek supports sharing, BUT (sorry I wasnt clear), whatever may be sharing with it may not), is to disable print support.

If memory serves, LPT1 (on non-IBM systems) uses IRQ 7. On some motherboards, IRQ7 will be "reserved" but not used and sometimes causes issues with using another device on that IRQ (depends on the motherboard BIOS/chipset/controller implementation). What this means is that though it does not show up in the OS as being used, the mobo implementation is still "monitoring" or "holding on to" it instead of fully freeing it for other devices.

Better yet would be to move the RTL8139 off IRQ7. I've got a few older HP/Compaq boards that refuse to fully respect certain BIOS settings (and either semi-use an IRQ or semi-use some other resource, or remap a resource regardless of BIOS setting (which can be confirmed on them by changing a certain resource value, saving the BIOS, rebooting, then viewing the BIOS' "report screen" of where things have been assigned - and no, I am not talking about add-ons here, I am talking about things hard-wired to the mobo)). I had this problem with a sound card that kept getting assigned the same IRQ as an onboard COM port. Disabling the com port (and thus it's use of the IRQ) still caused IRQ sharing type issues. Forcing the sound card elsewhere eliminated those issues, since nothing I did seemed to get the mobo to totally let go of the IRQ.

While that may not be the problem, it is a possible place to start. Without knowing the specifics of the hardware, it's hard to know if this is the problem, but it is an easy one to rule out via ensuring that the RTL8139 is not using any IRQ that the mobo itself would generally use for something built into it.


Now, there are other possible scenarios... (least likely) involving order that the hardware is initialized in OS/2's startup (usually this will cause the machine to hang on boot though, or a particular device not to initialize - hence least likely scenario), (seen it happen, but not often) some screwed up TCP setting that is causing a resource/buffer/socket issue (I have seen this caused by a "mix and match" TCP installation where code levels are not matching - this is rare and unlikely unless you applied certain patches without their prerequisite patches/updates).

Or of course, the card itself could be failing and causing issues.

Interestingly, it seems only certain traffic is being affected, which would tend to lead towards an issue with how certain apps are "interacting" with the driver/TCPIP stack.

That brings me to ask the following: Are you using DHCP? If so, can you instead assign a static IP address to the card/machine, and try the tests again? I am wondering if 30 minutes is when DHCP is checking it's IP lease...

Best,
Robert


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


Saijin_Naib

I believe the DHCP client is set to renew its lease on an hourly or bi-hourly rate. I'd have to re-check though. The DHCP Client tool in Settings\Network\??? should tell you. It'll also show you all the requests, etc if you turn to to the verbose mode.

craigm

Here is what I pull from RMVIEW /IRQ:

IRQ Level =  2  PCI Pin = NONE  Flg = EXCLUSIVE    PIC_1
  IRQ Level =  5  PCI Pin = D     Flg = SHARED       UHCI Compliant USB Host Con
troller
  IRQ Level =  5  PCI Pin = D     Flg = SHARED       UHCI Compliant USB Host Con
troller
  IRQ Level =  5  PCI Pin = C     Flg = SHARED       EHCI Compliant USB Host Con
troller
  IRQ Level =  6  PCI Pin = NONE  Flg = MULTIPLEXED  FLOPPY_0 Floppy Controller
  IRQ Level =  8  PCI Pin = NONE  Flg = EXCLUSIVE    RTC
  IRQ Level =  9  PCI Pin = A     Flg = SHARED       ETHERNET_0 Realtek 8100B/81
39D
  IRQ Level =  9  PCI Pin = NONE  Flg = SHARED       ACPI Interface
  IRQ Level = 10  PCI Pin = B     Flg = SHARED       OHCI Compliant USB Host Con
troller
  IRQ Level = 10  PCI Pin = A     Flg = SHARED       Sound Fusion CS46xx
  IRQ Level = 11  PCI Pin = A     Flg = SHARED       OHCI Compliant USB Host Con
troller
  IRQ Level = 14  PCI Pin = NONE  Flg = EXCLUSIVE    IDE_0 xATA Controller
  IRQ Level = 15  PCI Pin = NONE  Flg = EXCLUSIVE    IDE_1 xATA Controller
  IRQ Level = 44  PCI Pin = NONE  Flg = EXCLUSIVE    ACPI Interface
  IRQ Level = 45  PCI Pin = NONE  Flg = EXCLUSIVE    ACPI Interface
  IRQ Level = 46  PCI Pin = NONE  Flg = EXCLUSIVE    ACPI Interface
  IRQ Level = 47  PCI Pin = NONE  Flg = EXCLUSIVE    ACPI Interface

I am not using a static IP address, I guess I am confused about why GTIRC will work but not anything else...I would think nothing would work or it all would work. I am reading the other posts not and will reply soon.

RobertM

#14
QuoteWhen eCS 2.0 boots up everything runs very smoothly. I can get on the Internet and things are fast, life is good.

I run three programs on the Internet most of the time:

1. Firefox - ver 3.5.3
2. FTP Browser - 1.71
3. GTIRC - Ver - 3.00

After 30 minutes (to the second), Anything that is on the Internet loses connection and I go no where. The very weird thing is that GTIRC still works!?!? I still can have and receive conversations will people for hours. The only way I can get Firefox and FTP Browser working again is to reboot, then the clock starts again until 30 min elapses, then I have to reboot again if I want to surf.

I thought of a few things.




(1) IRC uses TCP like most other things you are using (as opposed to UDP, etc) - I don't see how it specifically would be a problem.
 (1a) After 30 minutes, when the problem occurs, if you close GTIRC and restart it, will it work?
        If not, then it too isn't immune, and simply is working in your previous tests because it still
        has it's sockets open and active. That would mean that the programs are having problems
        creating new sockets.





(2) I have had similar problems on Windows running Firefox. I never did figure out why, but since I upgraded Firefox, I have not had that issue anymore. Perhaps there is something buggy in the 3.5.x release(s) that causes this? I was running a 3.5.x (not sure which .x) version on Windows when this problem would crop up. It wasn't like clockwork, but it happened every time I surfed for a bit.





(3) Do you have NetBIOS over TCP/IP enabled? If so (and you don't need it), perhaps try disabling it and see what happens. I *DO* know, without a doubt, that my OS/2 machines, with or without that enabled, spend a lot of time ignoring all sorts of requests from my one Windows box. Not sure how that can affect an OS/2 or eComstation box, but perhaps it is causing an issue.





(4) You can test for certain things that may be causing problems (for instance, something causing the scenario in #1 above) by (from a command prompt) running:

netstat -m
- Check (usually) the last two entries for anything greater than a single digit number
  (mbufs: buffers used/allocated by your card and the networking subsystem to buffer/handle I/O)
  - dangerous to change these values unless you like trap errors and such, but they would be changed
     in the socketsk.sys entry in config.sys

netstat -s
- Check to see how many entries... if you have a massive list, something is wrong
  (sockets connected: for instance, well... anything that uses the Internet or a TCP/UDP based intra/internet)

netstat -l
- Check to see how many entries... if you have a massive list, something is wrong
  (open sockets in listen mode: for instance server daemons, IRC clients, etc)





(5) You can check your TCPIP config (tcpconfig2 from the commandline in older versions of eCS and OS/2 - or the TCPIP Config icon in most versions) and ensure (Network -> Advanced Options):
- (Page 1 on original style notebook)
  Broadcast: blank (these are configured under routing)
  Destination: blank (these are configured under routing)
  Metric Count: 1 (usually - 1 will work for 99% of every scenario)
  Max. Transm. Unit: 1500 (unless token ring or you know what you are doing)
  - values greater than 1500 will cause all sorts of weird issues with various NIC drivers/cards

- (Page 2 on original style notebook)
  I generally have nothing checked
  - Changing things like icmp redirects and such can cause interesting problems on certain setups/networks




Best,
Robert


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