psin & sin freeze

I’m running a fresh 6.2NC system. If I try to run sin or psin, they
freeze up.

Pidin shows sin or psin is REPLY blocked on io-net.

It will stay this way indefinitely. It doesn’t disrupt the rest of the
system in any way.

Slay and kill are powerless to stop them.

Is this a known problem?

Is there something I can do to fix it?

\

Bill Caroselli
Q-TPS Consulting
(626) 824-7983

Bill Caroselli wrote:

I’m running a fresh 6.2NC system. If I try to run sin or psin, they
freeze up.

Pidin shows sin or psin is REPLY blocked on io-net.

It will stay this way indefinitely. It doesn’t disrupt the rest of the
system in any way.

Slay and kill are powerless to stop them.

Is this a known problem?

Is there something I can do to fix it?

if you run the io-net slay before sin/psin
then try again.if this works this is probably
the network driver.you can use a different NIC
or try to load the latest patches.

sevgin wrote:

Bill Caroselli wrote:

I’m running a fresh 6.2NC system. If I try to run sin or psin, they
freeze up.

Pidin shows sin or psin is REPLY blocked on io-net.

It will stay this way indefinitely. It doesn’t disrupt the rest of
the system in any way.

Slay and kill are powerless to stop them.

Is this a known problem?

Is there something I can do to fix it?



if you run the io-net slay before sin/psin
then try again.if this works this is probably
the network driver.you can use a different NIC
or try to load the latest patches.

OK Sports fans, it’s official.

If I slay io-net, both sin and psin work fine. I’m running:

pidin -Pio-net me

pid tid name prio STATE code data stack
77839 1 sbin/io-net 10o SIGWAITINFO 56K 320K 8192(516K)*
77839 2 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 3 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 4 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 5 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 6 sbin/io-net 20o RECEIVE 56K 320K 4096(132K)
77839 7 sbin/io-net 21r RECEIVE 56K 320K 4096(132K)
ldqnx.so.2 @b0300000 300K 16K
npm-tcpip.so @b8200000 220K 52K
devn-sis9.so @b8244000 48K 4096

find / -xdev -name devn-sis9.so -exec ls -lL {}

-rwxrwxr-x 1 root root 50052 May 02 2002 /lib/dll/devn-sis9.so
-rwxrwxr-x 1 root root 50052 May 02 2002 /x86/lib/dll/devn-sis9.so

find / -xdev -name npm-tcpip.so -exec ls -lL {}

-rwxrwxr-x 1 root root 232668 May 02 2002 /lib/dll/npm-tcpip.so
-rwxrwxr-x 1 root root 232668 May 02 2002 /x86/lib/dll/npm-tcpip.so

find / -xdev -name ldqnx.so.2 -exec ls -lL {}

-rwxrwxr-x 1 root root 420640 May 02 2002 /x86/usr/lib/ldqnx.so.2
-rwxrwxr-x 1 385 root 319488 May 02 2002 /usr/lib/ldqnx.so.2

This NIC is on the motherboard and it appears to work rather well, the
current problem notwithstanding. I’d rather not replace it.

Is there a newer driver I can download? From where?

\

Bill Caroselli
Q-TPS Consulting
(626) 824-7983

Please post the output from ‘pci -v’ as well as the motherboard make and
type. Also the output from nicinfo with the driver running would help.

Previously, Bill Caroselli wrote in qdn.public.qnxrtp.applications:

sevgin wrote:
Bill Caroselli wrote:

I’m running a fresh 6.2NC system. If I try to run sin or psin, they
freeze up.

Pidin shows sin or psin is REPLY blocked on io-net.

It will stay this way indefinitely. It doesn’t disrupt the rest of
the system in any way.

Slay and kill are powerless to stop them.

Is this a known problem?

Is there something I can do to fix it?



if you run the io-net slay before sin/psin
then try again.if this works this is probably
the network driver.you can use a different NIC
or try to load the latest patches.

OK Sports fans, it’s official.

If I slay io-net, both sin and psin work fine. I’m running:

pidin -Pio-net me

pid tid name prio STATE code data stack
77839 1 sbin/io-net 10o SIGWAITINFO 56K 320K 8192(516K)*
77839 2 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 3 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 4 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 5 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 6 sbin/io-net 20o RECEIVE 56K 320K 4096(132K)
77839 7 sbin/io-net 21r RECEIVE 56K 320K 4096(132K)
ldqnx.so.2 @b0300000 300K 16K
npm-tcpip.so @b8200000 220K 52K
devn-sis9.so @b8244000 48K 4096

find / -xdev -name devn-sis9.so -exec ls -lL {}

-rwxrwxr-x 1 root root 50052 May 02 2002 /lib/dll/devn-sis9.so
-rwxrwxr-x 1 root root 50052 May 02 2002 /x86/lib/dll/devn-sis9.so

find / -xdev -name npm-tcpip.so -exec ls -lL {}

-rwxrwxr-x 1 root root 232668 May 02 2002 /lib/dll/npm-tcpip.so
-rwxrwxr-x 1 root root 232668 May 02 2002 /x86/lib/dll/npm-tcpip.so

find / -xdev -name ldqnx.so.2 -exec ls -lL {}

-rwxrwxr-x 1 root root 420640 May 02 2002 /x86/usr/lib/ldqnx.so.2
-rwxrwxr-x 1 385 root 319488 May 02 2002 /usr/lib/ldqnx.so.2

This NIC is on the motherboard and it appears to work rather well, the
current problem notwithstanding. I’d rather not replace it.

Is there a newer driver I can download? From where?

\

Bill Caroselli
Q-TPS Consulting
(626) 824-7983

Hugh Brown wrote:

Please post the output from ‘pci -v’ as well as the motherboard make and

If I slay io-net, both sin and psin work fine. I’m running:

pidin -Pio-net me

pid tid name prio STATE code data stack
77839 1 sbin/io-net 10o SIGWAITINFO 56K 320K 8192(516K)*
77839 2 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 3 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 4 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 5 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 6 sbin/io-net 20o RECEIVE 56K 320K 4096(132K)
77839 7 sbin/io-net 21r RECEIVE 56K 320K 4096(132K)
ldqnx.so.2 @b0300000 300K 16K
npm-tcpip.so @b8200000 220K 52K
devn-sis9.so @b8244000 48K 4096

find / -xdev -name devn-sis9.so -exec ls -lL {}

-rwxrwxr-x 1 root root 50052 May 02 2002 /lib/dll/devn-sis9.so
-rwxrwxr-x 1 root root 50052 May 02 2002 /x86/lib/dll/devn-sis9.so

find / -xdev -name npm-tcpip.so -exec ls -lL {}

-rwxrwxr-x 1 root root 232668 May 02 2002 /lib/dll/npm-tcpip.so
-rwxrwxr-x 1 root root 232668 May 02 2002 /x86/lib/dll/npm-tcpip.so

find / -xdev -name ldqnx.so.2 -exec ls -lL {}

-rwxrwxr-x 1 root root 420640 May 02 2002 /x86/usr/lib/ldqnx.so.2
-rwxrwxr-x 1 385 root 319488 May 02 2002 /usr/lib/ldqnx.so.2

This NIC is on the motherboard and it appears to work rather well, the
current problem notwithstanding. I’d rather not replace it.

Is there a newer driver I can download? From where?

pci -v

PCI version = 2.10

Class = Bridge (Host/PCI)
Vendor ID = 10b9h, Acer Labs Inc.
Device ID = 1621h, M1621 Aladdin-Pro II Northbridge
PCI index = 0h
Class Codes = 060000h
Revision ID = 4h
Bus number = 0
Device number = 0
Function num = 0
Status Reg = 2410h
Command Reg = 6h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = NC
Interrupt line = 0
Capabilities Pointer = b0h
Capability ID = 2h
Capabilities = 10h - 1b000203h
Capability ID = 1h
Capabilities = 1h - 0h

Class = Bridge (PCI/PCI)
Vendor ID = 10b9h, Acer Labs Inc.
Device ID = 5247h, M1621 Aladdin V built-in PCI-to-PCI bridge
PCI index = 0h
Class Codes = 060400h
Revision ID = 1h
Bus number = 0
Device number = 1
Function num = 0
Status Reg = 0h
Command Reg = 7h
Header type = 1h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
Primary Bus Number = 0h
Secondary Bus Number = 1h
Subordinate Bus Number = 1h
Secondary Latency Timer = 0h
I/O Base = b0h
I/O Limit = b0h
Secondary Status = a000h
Memory Base = dde0h
Memory Limit = dfe0h
Prefetchable Memory Base = d1c0h
Prefetchable Memory Limit= d5c0h
Prefetchable Base Upper 32 Bits = 0h
Prefetchable Limit Upper 32 Bits = 0h
I/O Base Upper 16 Bits = ffffh
I/O Limit Upper 16 Bits = ffffh
Bridge Control = 10ns
PCI Int Pin = NC
Interrupt line = 0

Class = Serial Bus (Universal Serial Bus)
Vendor ID = 10b9h, Acer Labs Inc.
Device ID = 5237h, M5237 USB Host Controller
PCI index = 0h
Class Codes = 0c0310h
Revision ID = 3h
Bus number = 0
Device number = 2
Function num = 0
Status Reg = 290h
Command Reg = 117h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 40h
Cache Line Size= 8h un-cacheable
PCI Mem Address = dffff000h 32bit length 4096 enabled
Max Lat = 80ns
Min Gnt = 0ns
PCI Int Pin = INT A
Interrupt line = 10
Capabilities Pointer = 60h
Capability ID = 1h
Capabilities = 2h - 0h

Class = Bridge (PCI/ISA)
Vendor ID = 10b9h, Acer Labs Inc.
Device ID = 1533h, M1533 PCI South Bridge
PCI index = 0h
Class Codes = 060100h
Revision ID = c3h
Bus number = 0
Device number = 7
Function num = 0
Status Reg = 200h
Command Reg = fh
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 0h
Cache Line Size= 0h
Max Lat = 0ns
Min Gnt = 0ns
PCI Int Pin = NC
Interrupt line = 0

Class = Multimedia (Audio)
Vendor ID = 13f6h, C-Media Electronics Inc.
Device ID = 111h, CMI8738/PCI-6CH C3DX PCI Audio Chip
PCI index = 0h
Class Codes = 040100h
Revision ID = 10h
Bus number = 0
Device number = 12
Function num = 0
Status Reg = 210h
Command Reg = 105h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 40h
Cache Line Size= 0h
PCI IO Address = dc00h length 256 enabled
Subsystem Vendor ID = 13f6h
Subsystem ID = 111h
Max Lat = 24ns
Min Gnt = 2ns
PCI Int Pin = INT A
Interrupt line = 11
Capabilities Pointer = c0h
Capability ID = 1h
Capabilities = 602h - 0h

Class = Network (Ethernet)
Vendor ID = 1039h, Silicon Integrated System
Device ID = 900h, SiS900 Fast Ethernet/Home Networking Ctrlr
PCI index = 0h
Class Codes = 020000h
Revision ID = 2h
Bus number = 0
Device number = 14
Function num = 0
Status Reg = 290h
Command Reg = 107h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 40h
Cache Line Size= 0h
PCI IO Address = d800h length 256 enabled
PCI Mem Address = dfffe000h 32bit length 4096 enabled
Subsystem Vendor ID = 1039h
Subsystem ID = 900h
PCI Expansion ROM = dffc0000h length 131072 disabled
Max Lat = 11ns
Min Gnt = 52ns
PCI Int Pin = INT A
Interrupt line = 12
Capabilities Pointer = 40h
Capability ID = 1h
Capabilities = fe02h - 0h

Class = Mass Storage (IDE)
Vendor ID = 10b9h, Acer Labs Inc.
Device ID = 5229h, M1543 Southbridge EIDE Controller
PCI index = 0h
Class Codes = 0101fah
Revision ID = c2h
Bus number = 0
Device number = 15
Function num = 0
Status Reg = 290h
Command Reg = 5h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 20h
Cache Line Size= 0h
PCI IO Address = ffa0h length 16 enabled
Subsystem Vendor ID = 10b9h
Subsystem ID = 5229h
Max Lat = 4ns
Min Gnt = 2ns
PCI Int Pin = INT A
Interrupt line = 0
Capabilities Pointer = 60h
Capability ID = 1h
Capabilities = 2h - 0h

Class = Display (VGA)
Vendor ID = 10deh, Nvidia Corporation
Device ID = a0h, RIVA TNT2 Aladdin
PCI index = 0h
Class Codes = 030000h
Revision ID = 20h
Bus number = 1
Device number = 0
Function num = 0
Status Reg = 2b0h
Command Reg = 6h
Header type = 0h Single-function
BIST = 0h Build-in-self-test not supported
Latency Timer = 40h
Cache Line Size= 0h
PCI Mem Address = de000000h 32bit length 16777216 enabled
PCI Mem Address = d2000000h prefetchable 32bit length 33554432 enabled
PCI Expansion ROM = dfef0000h length 65536 disabled
Max Lat = 1ns
Min Gnt = 5ns
PCI Int Pin = INT A
Interrupt line = 0
Capabilities Pointer = 60h
Capability ID = 1h
Capabilities = 1h - 0h
Capability ID = 2h
Capabilities = 10h - 1f000203h


The computer is from Polywell. I don’t know the motherboard. It’s a
19" rack mount. There are no identifying labels on the outside (except
Polywell). I’ll reboot and look.

OK. I just rebooted. It doesn’t really identify itself. It does show
that it uses an AMI BIOS. Not much help there though. Sorry.


Bill Caroselli
Q-TPS Consulting
(626) 824-7983

Responded via e-mail. Bug fixed in driver.

Previously, Bill Caroselli wrote in qdn.public.qnxrtp.applications:

Hugh Brown wrote:
Please post the output from ‘pci -v’ as well as the motherboard make and

If I slay io-net, both sin and psin work fine. I’m running:

pidin -Pio-net me

pid tid name prio STATE code data stack
77839 1 sbin/io-net 10o SIGWAITINFO 56K 320K 8192(516K)*
77839 2 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 3 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 4 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 5 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 6 sbin/io-net 20o RECEIVE 56K 320K 4096(132K)
77839 7 sbin/io-net 21r RECEIVE 56K 320K 4096(132K)
ldqnx.so.2 @b0300000 300K 16K
npm-tcpip.so @b8200000 220K 52K
devn-sis9.so @b8244000 48K 4096

find / -xdev -name devn-sis9.so -exec ls -lL {}

-rwxrwxr-x 1 root root 50052 May 02 2002 /lib/dll/devn-sis9.so
-rwxrwxr-x 1 root root 50052 May 02 2002 /x86/lib/dll/devn-sis9.so

find / -xdev -name npm-tcpip.so -exec ls -lL {}

-rwxrwxr-x 1 root root 232668 May 02 2002 /lib/dll/npm-tcpip.so
-rwxrwxr-x 1 root root 232668 May 02 2002 /x86/lib/dll/npm-tcpip.so

find / -xdev -name ldqnx.so.2 -exec ls -lL {}

-rwxrwxr-x 1 root root 420640 May 02 2002 /x86/usr/lib/ldqnx.so.2
-rwxrwxr-x 1 385 root 319488 May 02 2002 /usr/lib/ldqnx.so.2

This NIC is on the motherboard and it appears to work rather well, the
current problem notwithstanding. I’d rather not replace it.

Is there a newer driver I can download? From where?

[snip]

Hi,
I’d like to know why psin is so irritating!
This tool was almost impossible to use in 6.1 (frezzing, eating memory)
for many reasons, and I see it still the case in 6.2!

Hopefully pidin still exists!

regards,
Alain.

Hugh Brown a écrit:

Responded via e-mail. Bug fixed in driver.

Previously, Bill Caroselli wrote in qdn.public.qnxrtp.applications:


Hugh Brown wrote:


Please post the output from ‘pci -v’ as well as the motherboard make and


If I slay io-net, both sin and psin work fine. I’m running:

pidin -Pio-net me

pid tid name prio STATE code data stack
77839 1 sbin/io-net 10o SIGWAITINFO 56K 320K 8192(516K)*
77839 2 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 3 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 4 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 5 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 6 sbin/io-net 20o RECEIVE 56K 320K 4096(132K)
77839 7 sbin/io-net 21r RECEIVE 56K 320K 4096(132K)
ldqnx.so.2 @b0300000 300K 16K
npm-tcpip.so @b8200000 220K 52K
devn-sis9.so @b8244000 48K 4096

find / -xdev -name devn-sis9.so -exec ls -lL {}

-rwxrwxr-x 1 root root 50052 May 02 2002 /lib/dll/devn-sis9.so
-rwxrwxr-x 1 root root 50052 May 02 2002 /x86/lib/dll/devn-sis9.so

find / -xdev -name npm-tcpip.so -exec ls -lL {}

-rwxrwxr-x 1 root root 232668 May 02 2002 /lib/dll/npm-tcpip.so
-rwxrwxr-x 1 root root 232668 May 02 2002 /x86/lib/dll/npm-tcpip.so

find / -xdev -name ldqnx.so.2 -exec ls -lL {}

-rwxrwxr-x 1 root root 420640 May 02 2002 /x86/usr/lib/ldqnx.so.2
-rwxrwxr-x 1 385 root 319488 May 02 2002 /usr/lib/ldqnx.so.2

This NIC is on the motherboard and it appears to work rather well, the
current problem notwithstanding. I’d rather not replace it.

Is there a newer driver I can download? From where?



[snip]
\

Hugh Brown <hsbrown@qnx.com> wrote:

Responded via e-mail. Bug fixed in driver.

The new SIS9 driver works perfectly and doesn’t interfere with sin or
psin. Thanks Hugh.


The shelf on the right side of the screen has a System Monitor that
implies that it displays network activity. It does not on my system
with this SIS9 driver. Hugh said that the driver IS doing it’s part.

Does anyone else know what might prevent this indicator from
displaying any activity even when the network activity is fairly
heavy?

Bill Caroselli <qtps@earthlink.net> wrote:

Hugh Brown <> hsbrown@qnx.com> > wrote:
Responded via e-mail. Bug fixed in driver.

The new SIS9 driver works perfectly and doesn’t interfere with sin or
psin. Thanks Hugh.



The shelf on the right side of the screen has a System Monitor that
implies that it displays network activity. It does not on my system
with this SIS9 driver. Hugh said that the driver IS doing it’s part.

Does anyone else know what might prevent this indicator from
displaying any activity even when the network activity is fairly
heavy?

Do the packet counts reported by ‘nicinfo’ look correct?

-seanb

Sean Boudreau <seanb@node25.ott.qnx.com> wrote:

Bill Caroselli <> qtps@earthlink.net> > wrote:

The shelf on the right side of the screen has a System Monitor that
implies that it displays network activity. It does not on my system
with this SIS9 driver. Hugh said that the driver IS doing it’s part.

Does anyone else know what might prevent this indicator from
displaying any activity even when the network activity is fairly
heavy?

Do the packet counts reported by ‘nicinfo’ look correct?

Yes, the packet counts do appear to be incrementing appropriately.

Hugh Brown <hsbrown@qnx.com> wrote:
HB > Responded via e-mail. Bug fixed in driver.

Hi Hugh.

It’s back!
I upgraded from 6.20 to 6.21 and the devn-sis9.so driver has the same
bug as reported earlier. Can you re-post the fixed driver?

I have to say, QSSL seems to have a lousy track record in getting
bug fixes INTO the next release. It would be nice if they had
someone responsible for getting fixed software into the releases.

Oh hell. Let me babble a little more. Us old timers all remember when
we could post a problem on QUICS and hours later there was a beta
version of that software that we could download and try. QSSL has
presented many arguments as to why that is impracticle to do anymore.
I’ll agree. As large as you are now, it probibly is impracticle.
But one of the arguments has always been that these controlled releases
are more reliable. But the statistics speak for them selves. They’re
not. And, the new releases are way too few and far between!

The last several years you’ve been averaging less than a release a year.
A year is way too long for a customer or potential customer to hear,
“Oh yeah. That’s been fixed internally. You’ll get it in the next
release.” And then teh next release comes out and that thing that was
fixed a year ago never made it into the latest release. This doesn’t
exactly exude confidence for the customers.

QSSL can ignore this, as they have done now for years. But it is a
real problem. Does anyone else agree? If so, say so!


HB > Previously, Bill Caroselli wrote in qdn.public.qnxrtp.applications:

Hugh Brown wrote:
Please post the output from ‘pci -v’ as well as the motherboard make and

If I slay io-net, both sin and psin work fine. I’m running:

pidin -Pio-net me

pid tid name prio STATE code data stack
77839 1 sbin/io-net 10o SIGWAITINFO 56K 320K 8192(516K)*
77839 2 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 3 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 4 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 5 sbin/io-net 10o RECEIVE 56K 320K 4096(68K)
77839 6 sbin/io-net 20o RECEIVE 56K 320K 4096(132K)
77839 7 sbin/io-net 21r RECEIVE 56K 320K 4096(132K)
ldqnx.so.2 @b0300000 300K 16K
npm-tcpip.so @b8200000 220K 52K
devn-sis9.so @b8244000 48K 4096

find / -xdev -name devn-sis9.so -exec ls -lL {}

-rwxrwxr-x 1 root root 50052 May 02 2002 /lib/dll/devn-sis9.so
-rwxrwxr-x 1 root root 50052 May 02 2002 /x86/lib/dll/devn-sis9.so

find / -xdev -name npm-tcpip.so -exec ls -lL {}

-rwxrwxr-x 1 root root 232668 May 02 2002 /lib/dll/npm-tcpip.so
-rwxrwxr-x 1 root root 232668 May 02 2002 /x86/lib/dll/npm-tcpip.so

find / -xdev -name ldqnx.so.2 -exec ls -lL {}

-rwxrwxr-x 1 root root 420640 May 02 2002 /x86/usr/lib/ldqnx.so.2
-rwxrwxr-x 1 385 root 319488 May 02 2002 /usr/lib/ldqnx.so.2

This NIC is on the motherboard and it appears to work rather well, the
current problem notwithstanding. I’d rather not replace it.

Is there a newer driver I can download? From where?

HB > [snip]

Bill Caroselli <qtps@earthlink.net> wrote:
BC > Hugh Brown <hsbrown@qnx.com> wrote:
BC > HB > Responded via e-mail. Bug fixed in driver.

BC > Hi Hugh.

BC > It’s back!
BC > I upgraded from 6.20 to 6.21 and the devn-sis9.so driver has the same
BC > bug as reported earlier. Can you re-post the fixed driver?

I still have the e-mail tht you sent me with the fixed sis9 driver.
It does work with 6.21. Good.

I hope someone from QSSL replies to the issue of loosing fixes in the
upgrades.

Bill Caroselli <qtps@earthlink.net> wrote:

QSSL can ignore this, as they have done now for years. But it is a
real problem. Does anyone else agree? If so, say so!

I agree, though I must admit, that the individual support (at least
via the German office) has become a great help and very reliable in
the last years.

But from my point of view it is quite inefficient to solve all
problems individually and not to spread the information in the NGs,
specially when things have to be re-fixed after every new release
(german keyboard driver, in my case).

So I often think of the good old times, too :slight_smile:


| / | __ ) | Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |/| | _ _
\ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |
) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld

Hugh Brown <hsbrown@qnx.com> wrote:

Responded via e-mail. Bug fixed in driver.

Can I get this driver, as well (we’ve got a similar problem here).

The driver doesn’t recognize the MAC address, but manual assignment
works (see nicinfo output below). And ‘psin’ and ‘sin’ block, too.

TIA,

Karsten.



SiS900 Ethernet Controller
Physical Node ID … 000000 000000
Current Physical Node ID … 0000E2 37107C
Media Rate … 100.00 Mb/s half-duplex UTP
MTU … 1514
Lan … 0
I/O Port Range … 0x9000 → 0x90FF
Hardware Interrupt … 0xA
Promiscuous … Disabled
Multicast … Enabled

Total Packets Txd OK … 4457258
Total Packets Txd Bad … 0
Total Packets Rxd OK … 5758046
Total Rx Errors … 4530

Total Bytes Txd … 449361067
Total Bytes Rxd … 1208373896

Tx Collision Errors … 171348
Tx Collisions Errors (aborted) … 0
Carrier Sense Lost on Tx … 0
FIFO Underruns During Tx … 0
Tx deferred … 148215
Out of Window Collisions … 0
FIFO Overruns During Rx … 0
Alignment errors … 4499
CRC errors … 759


| / | __ ) | Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |/| | _ _
\ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |
) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld

Previously, Karsten.Hoffmann@mbs-software.de wrote in qdn.public.qnxrtp.applications:

Hugh Brown <> hsbrown@qnx.com> > wrote:
Responded via e-mail. Bug fixed in driver.

Can I get this driver, as well (we’ve got a similar problem here).

The driver doesn’t recognize the MAC address, but manual assignment
works (see nicinfo output below). And ‘psin’ and ‘sin’ block, too.

The new driver is at http://developers.qnx.com

TIA,

Karsten.



SiS900 Ethernet Controller
Physical Node ID … 000000 000000
Current Physical Node ID … 0000E2 37107C
Media Rate … 100.00 Mb/s half-duplex UTP
MTU … 1514
Lan … 0
I/O Port Range … 0x9000 → 0x90FF
Hardware Interrupt … 0xA
Promiscuous … Disabled
Multicast … Enabled

Total Packets Txd OK … 4457258
Total Packets Txd Bad … 0
Total Packets Rxd OK … 5758046
Total Rx Errors … 4530

Total Bytes Txd … 449361067
Total Bytes Rxd … 1208373896

Tx Collision Errors … 171348
Tx Collisions Errors (aborted) … 0
Carrier Sense Lost on Tx … 0
FIFO Underruns During Tx … 0
Tx deferred … 148215
Out of Window Collisions … 0
FIFO Overruns During Rx … 0
Alignment errors … 4499
CRC errors … 759


| / | __ ) | > Karsten.Hoffmann@mbs-software.de > MBS-GmbH
| |/| | _ _
\ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |
) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld

Hugh Brown <hsbrown@qnx.com> wrote:

The new driver is at > http://developers.qnx.com

Thanks!

FYI:

Blocking is gone, but the automatic detection of the MAC address
still doesn’t work; manual override is OK.

‘netinfo’ output follows:


SiS900 Ethernet Controller
Physical Node ID … 000000 000000
Current Physical Node ID … 0000E2 37107C
Media Rate … 100.00 Mb/s half-duplex UTP
MTU … 1514
Lan … 0
I/O Port Range … 0x9000 → 0x90FF
Hardware Interrupt … 0xa
Promiscuous … Disabled
Multicast … Enabled
Total Packets Txd OK … 10081
Total Packets Txd Bad … 0
Total Packets Rxd OK … 11256
Total Rx Errors … 15

Total Bytes Txd … 1177283
Total Bytes Rxd … 1054107

Tx Collision Errors … 277
Tx Collisions Errors (aborted) … 0
Carrier Sense Lost on Tx … 0
FIFO Underruns During Tx … 0
Tx deferred … 427
Out of Window Collisions … 0
FIFO Overruns During Rx … 0
Alignment errors … 15
CRC errors … 1


| / | __ ) | Karsten.Hoffmann@mbs-software.de MBS-GmbH
| |/| | _ _
\ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |
) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld

Previously, Karsten.Hoffmann@mbs-software.de wrote in qdn.public.qnxrtp.applications:

Hugh Brown <> hsbrown@qnx.com> > wrote:

The new driver is at > http://developers.qnx.com


Thanks!

FYI:

Blocking is gone, but the automatic detection of the MAC address
still doesn’t work; manual override is OK.

What sis900 card do you have? Is this a PCI card or is it integrated on
the motherboard? The output of ‘pci -v’ would also help.

‘netinfo’ output follows:


SiS900 Ethernet Controller
Physical Node ID … 000000 000000
Current Physical Node ID … 0000E2 37107C
Media Rate … 100.00 Mb/s half-duplex UTP
MTU … 1514
Lan … 0
I/O Port Range … 0x9000 → 0x90FF
Hardware Interrupt … 0xa
Promiscuous … Disabled
Multicast … Enabled
Total Packets Txd OK … 10081
Total Packets Txd Bad … 0
Total Packets Rxd OK … 11256
Total Rx Errors … 15

Total Bytes Txd … 1177283
Total Bytes Rxd … 1054107

Tx Collision Errors … 277
Tx Collisions Errors (aborted) … 0
Carrier Sense Lost on Tx … 0
FIFO Underruns During Tx … 0
Tx deferred … 427
Out of Window Collisions … 0
FIFO Overruns During Rx … 0
Alignment errors … 15
CRC errors … 1


| / | __ ) | > Karsten.Hoffmann@mbs-software.de > MBS-GmbH
| |/| | _ _
\ Phone : +49-2151-7294-38 Karsten Hoffmann
| | | | |
) |__) | Fax : +49-2151-7294-50 Roemerstrasse 15
|| ||// Mobile: +49-172-3812373 D-47809 Krefeld

Karsten.Hoffmann@mbs-software.de wrote:
KHmsd > Bill Caroselli <qtps@earthlink.net> wrote:

QSSL can ignore this, as they have done now for years. But it is a
real problem. Does anyone else agree? If so, say so!

KHmsd > I agree, though I must admit, that the individual support (at least
KHmsd > via the German office) has become a great help and very reliable in
KHmsd > the last years.

Absolutely correct! I have to give credit where credit is due.

I’ll even go one step further. As an old timer I’m used to the great
support coming from QSSL. For a couple of years that level of support
had slipped. But the good news is that it is back up to it’s old
excellent levels. Kudos QNX!

Hugh Brown <hsbrown@qnx.com> wrote:
HB > Previously, Karsten.Hoffmann@mbs-software.de wrote in qdn.public.qnxrtp.applications:

Hugh Brown <> hsbrown@qnx.com> > wrote:
Responded via e-mail. Bug fixed in driver.

Can I get this driver, as well (we’ve got a similar problem here).

The driver doesn’t recognize the MAC address, but manual assignment
works (see nicinfo output below). And ‘psin’ and ‘sin’ block, too.

HB > The new driver is at http://developers.qnx.com

I don’t see the new driver. Where do I go from this page. I checked
everything under the 6.2 entry.

Previously, Bill Caroselli wrote in qdn.public.qnxrtp.applications:

Hugh Brown <> hsbrown@qnx.com> > wrote:
HB > Previously, > Karsten.Hoffmann@mbs-software.de > wrote in qdn.public.qnxrtp.applications:
Hugh Brown <> hsbrown@qnx.com> > wrote:
Responded via e-mail. Bug fixed in driver.

Can I get this driver, as well (we’ve got a similar problem here).

The driver doesn’t recognize the MAC address, but manual assignment
works (see nicinfo output below). And ‘psin’ and ‘sin’ block, too.


HB > The new driver is at > http://developers.qnx.com

I don’t see the new driver. Where do I go from this page. I checked
everything under the 6.2 entry.

Under the Fixes section, look at the Next page and you will see a
devn-sis9.so as well as a new nicinfo.