Hi,
I’ve got a Samba server on Solaris which mounts fine under QNX, and I
can read/write files to my heart’s content, however after while the
mount ‘freezes’ and no reads or writes work. The OS is otherwise unaffected.
The Samba server works great with a Mac, and this problem does not
occur, so I’m happy to lay the blame at the door of QSS. This problem
plagued me on 6.2.1 and remains on 6.3, is there a fix or a workaround
anyone knows about? I’ve tried this on two different QNX machines, same
result.
Hi,
I’ve got a Samba server on Solaris which mounts fine under QNX, and
I can read/write files to my heart’s content, however after while the
mount ‘freezes’ and no reads or writes work. The OS is otherwise
unaffected.
Can you provide any more information about the state of the system when
this happens? What sort of load is the system experiencing when it
fails? What output do you see (if any) if you try to read/write from
the mountpoint?
Can you post the output of pidin on this system when the problem has
occurred?
Hi,
I’ve got a Samba server on Solaris which mounts fine under QNX,
and I can read/write files to my heart’s content, however after while
the mount ‘freezes’ and no reads or writes work. The OS is otherwise
unaffected.
Can you provide any more information about the state of the system when
this happens? What sort of load is the system experiencing when it
fails? What output do you see (if any) if you try to read/write from
the mountpoint?
Can you post the output of pidin on this system when the problem has
occurred?
Barry, thanks for the interest, to answer your questions:
State of the system is a fresh reboot on my laptop or my desktop, not
running anything terribly unusual. Load is practically zero, just a bit
of web browsing.
I mount the drive, leave it five minutes, come back and do ‘ls’ on a
directory, the terminal freezes, no error. The same ‘ls’ works fine if I
do it a few seconds after mounting.
Just another note, after a few hours I came to my laptop, ‘ls’ was still
trying, still no errors. But browsed a few websites, opened a few apps,
and next time I looked, ‘ls’ had listed the directory like nothing had
ever gone wrong.
I’ve now left it another 5 minutes, and it’s frozen again! To make
matters a little more interesting, if I select the bash process
containing the ‘ls’ command in ‘psin’ to slay it, psin crashes instantly.
After a bit of experimentation it seems if left unattended, Samba mounts
will stop responding after less than 5 minutes, but it seems that once
frozen it can be sometimes be ‘woken up’ by attempting to touch a file
into it, ‘cd’ into it’s parent directory, or maybe try to view the
parent directory in a file requester. Sometime this will work, sometimes
not.
For reference, this is pidin when the mount has woken up and working OK:
I have also seen this on a very regular basis. It is a bug and needs to
be fixed. I have however found a circumvention.
When this happens I open another pterm and do another ‘ls’ of the
mounted directory. Often times the second attempt doesn’t free anything
up. But then when I do a third ‘ls’ that frees up all the pending requests.
This IS a pain in the a**. But at least you don’t have to reboot to
solve the problem.
slaying and restarting fs-cifs does the same job …
Regards
Armin
Garry <> asdf34sdg@sdfasdf3.com> > wrote:
G > State of the system is a fresh reboot on my laptop or my desktop, not
G > running anything terribly unusual. Load is practically zero, just a bit
G > of web browsing.
G > I mount the drive, leave it five minutes, come back and do ‘ls’ on a
G > directory, the terminal freezes, no error. The same ‘ls’ works fine if I
G > do it a few seconds after mounting.
G > pidin output:
G > pid tid name prio STATE Blocked
G > 1 1 /sys/procnto-instr 0f READY
G > 1 2 /sys/procnto-instr 255r RECEIVE 1
G > 1 3 /sys/procnto-instr 11r RECEIVE 1
G > 1 4 /sys/procnto-instr 10r RUNNING
G > 1 5 /sys/procnto-instr 10r RECEIVE 1
G > 1 6 /sys/procnto-instr 12r RECEIVE 1
G > 1 7 /sys/procnto-instr 10r RECEIVE 1
G > 1 8 /sys/procnto-instr 10r RECEIVE 1
G > 1 9 /sys/procnto-instr 10r RECEIVE 1
G > 1 10 /sys/procnto-instr 10r RECEIVE 1
G > 2 1 sbin/tinit 10o REPLY 1
G > 3 1 proc/boot/slogger 12o RECEIVE 1
G > 5 1 proc/boot/pci-bios 12o RECEIVE 1
G > 6 1 roc/boot/devb-eide 10o SIGWAITINFO
G > 6 2 roc/boot/devb-eide 21r RECEIVE 1
G > 6 3 roc/boot/devb-eide 21r RECEIVE 4
G > 6 4 roc/boot/devb-eide 10o RECEIVE 10
G > 6 6 roc/boot/devb-eide 10o RECEIVE 7
G > 6 7 roc/boot/devb-eide 10o RECEIVE 7
G > 6 8 roc/boot/devb-eide 10o RECEIVE 7
G > 6 9 roc/boot/devb-eide 10o RECEIVE 7
G > 7 1 proc/boot/devc-con 15o RECEIVE 1
G > 4104 2 sbin/pipe 10o RECEIVE 1
G > 4104 3 sbin/pipe 10o RECEIVE 1
G > 4104 4 sbin/pipe 10o RECEIVE 1
G > 4104 5 sbin/pipe 10o RECEIVE 1
G > 12292 1 sbin/mqueue 10o RECEIVE 1
G > 40969 1 sbin/enum-devices 10o REPLY 4104
G > 65548 1 sbin/devp-pccard 21o RECEIVE 1
G > 65549 1 sbin/enum-pccard 29f RECEIVE 1
G > 73738 1 sbin/io-audio 10o SIGWAITINFO
G > 73738 2 sbin/io-audio 10o RECEIVE 1
G > 73738 3 sbin/io-audio 10o RECEIVE 1
G > 73738 4 sbin/io-audio 10o RECEIVE 1
G > 73738 5 sbin/io-audio 50r INTR
G > 90123 1 sbin/devc-par 10o RECEIVE 1
G > 90123 2 sbin/devc-par 9r CONDVAR 80519e8
G > 106513 1 usr/sbin/spooler 10o NANOSLEEP
G > 114704 1 sbin/devb-fdc 10o SIGWAITINFO
G > 114704 2 sbin/devb-fdc 21r RECEIVE 1
G > 114704 3 sbin/devb-fdc 10o RECEIVE 7
G > 114704 4 sbin/devb-fdc 10o RECEIVE 4
G > 114704 5 sbin/devb-fdc 10o RECEIVE 4
G > 114704 6 sbin/devb-fdc 10o RECEIVE 4
G > 114706 1 sbin/devc-pty 10o RECEIVE 1
G > 118803 1 usr/sbin/random 10o SIGWAITINFO
G > 118803 2 usr/sbin/random 10o RECEIVE 1
G > 118803 3 usr/sbin/random 10o NANOSLEEP
G > 131092 1 usr/sbin/dumper 10o RECEIVE 1
G > 151574 1 sbin/io-net 10o SIGWAITINFO
G > 151574 2 sbin/io-net 20o RECEIVE 5
G > 151574 3 sbin/io-net 10o RECEIVE 1
G > 151574 4 sbin/io-net 10o RECEIVE 1
G > 151574 5 sbin/io-net 21r RECEIVE 19
G > 151574 6 sbin/io-net 10o RECEIVE 1
G > 213006 1 bin/login 10o REPLY 7
G > 213007 1 bin/login 10o REPLY 7
G > 213013 1 bin/login 10o REPLY 7
G > 258073 1 /photon/bin/Photon 12r RECEIVE 1
G > 286746 1 /photon/bin/phfont 10o JOIN 2
G > 286746 2 /photon/bin/phfont 10o RECEIVE 1
G > 299035 1 ton/bin/fontsleuth 10o RECEIVE 1
G > 299035 2 ton/bin/fontsleuth 10o SIGWAITINFO
G > 299035 3 ton/bin/fontsleuth 6o RECEIVE 1
G > 299035 4 ton/bin/fontsleuth 10o RECEIVE 1
G > 327710 1 on/bin/io-graphics 12r RECEIVE 1
G > 327710 2 on/bin/io-graphics 12r REPLY 299035
G > 327710 3 on/bin/io-graphics 12r REPLY 258073
G > 348189 1 ton/bin/devi-hirun 15o RECEIVE 1
G > 348189 2 ton/bin/devi-hirun 15o REPLY 7
G > 348189 3 ton/bin/devi-hirun 12o SIGWAITINFO
G > 360471 1 bin/login 10o REPLY 7
G > 466972 1 usr/photon/bin/pwm 10r RECEIVE 1
G > 512032 1 r/photon/bin/shelf 10r RECEIVE 1
G > 512032 2 r/photon/bin/shelf 10r CONDVAR 806cebc
G > 548897 1 photon/bin/bkgdmgr 10r RECEIVE 1
G > 548898 1 hoton/bin/wmswitch 10r RECEIVE 2
G > 548899 1 r/photon/bin/saver 10r RECEIVE 1
G > 577572 1 /X11R6/bin/XPhoton 10r SIGWAITINFO
G > 643103 1 bin/sh 10r SIGSUSPEND
G > 688152 1 ozilla/mozilla-bin 10r RECEIVE 1
G > 688152 2 ozilla/mozilla-bin 10r SIGWAITINFO
G > 688152 3 ozilla/mozilla-bin 10r RECEIVE 4
G > 688152 5 ozilla/mozilla-bin 10r CONDVAR 8149a00
G > 688152 9 ozilla/mozilla-bin 10r CONDVAR 89cb93c
G > 692261 1 c/gcc_ntox86/GTerm 10r RECEIVE 1
G > 692263 1 bin/sh 10r SIGSUSPEND
G > 704550 1 opt/bin/bash 10r REPLY 114706
G > 765993 1 bin/sh 10r SIGSUSPEND
G > 770088 1 opt/bin/bash 10r REPLY 1
G > 802858 1 bin/sh 10r SIGSUSPEND
G > 811051 1 opt/bin/bash 10r REPLY 1
G > 819245 1 usr/sbin/fs-cifs 10r RECEIVE 1
G > 819245 2 usr/sbin/fs-cifs 10r REPLY 151574
G > 819245 3 usr/sbin/fs-cifs 10r RECEIVE 1
G > 819245 4 usr/sbin/fs-cifs 10r RECEIVE 1
G > 852014 1 bin/sh 10r SIGSUSPEND
G > 856108 1 opt/bin/bash 10r REPLY 1
G > 901167 1 bin/ls 10r REPLY 819245
G > 921648 1 bin/pidin 10r REPLY 1
G > I ran pidin a few times with gaps of a few minutes, the state of the
G > fs-cifs threads is always the same.
G > I’d love to use Samba to share directories between my Sun and my QNX
G > laptop and desktop, so any help is much appreciated.
G > If it matters, my desktop is wired 100baseT ethernet, and the laptop is
G > 802.11g.
I have also seen this on a very regular basis. It is a bug and needs to
be fixed. I have however found a circumvention.
When this happens I open another pterm and do another ‘ls’ of the
mounted directory. Often times the second attempt doesn’t free anything
up. But then when I do a third ‘ls’ that frees up all the pending requests.
This IS a pain in the a**. But at least you don’t have to reboot to
solve the problem.
Garry <asdf34sdg@sdfasdf3.com> wrote:
G > State of the system is a fresh reboot on my laptop or my desktop, not
G > running anything terribly unusual. Load is practically zero, just a bit
G > of web browsing.
G > I mount the drive, leave it five minutes, come back and do ‘ls’ on a
G > directory, the terminal freezes, no error. The same ‘ls’ works fine if I
G > do it a few seconds after mounting.
G > pidin output:
G > pid tid name prio STATE Blocked
G > 1 1 /sys/procnto-instr 0f READY
G > 1 2 /sys/procnto-instr 255r RECEIVE 1
G > 1 3 /sys/procnto-instr 11r RECEIVE 1
G > 1 4 /sys/procnto-instr 10r RUNNING
G > 1 5 /sys/procnto-instr 10r RECEIVE 1
G > 1 6 /sys/procnto-instr 12r RECEIVE 1
G > 1 7 /sys/procnto-instr 10r RECEIVE 1
G > 1 8 /sys/procnto-instr 10r RECEIVE 1
G > 1 9 /sys/procnto-instr 10r RECEIVE 1
G > 1 10 /sys/procnto-instr 10r RECEIVE 1
G > 2 1 sbin/tinit 10o REPLY 1
G > 3 1 proc/boot/slogger 12o RECEIVE 1
G > 5 1 proc/boot/pci-bios 12o RECEIVE 1
G > 6 1 roc/boot/devb-eide 10o SIGWAITINFO
G > 6 2 roc/boot/devb-eide 21r RECEIVE 1
G > 6 3 roc/boot/devb-eide 21r RECEIVE 4
G > 6 4 roc/boot/devb-eide 10o RECEIVE 10
G > 6 6 roc/boot/devb-eide 10o RECEIVE 7
G > 6 7 roc/boot/devb-eide 10o RECEIVE 7
G > 6 8 roc/boot/devb-eide 10o RECEIVE 7
G > 6 9 roc/boot/devb-eide 10o RECEIVE 7
G > 7 1 proc/boot/devc-con 15o RECEIVE 1
G > 4104 2 sbin/pipe 10o RECEIVE 1
G > 4104 3 sbin/pipe 10o RECEIVE 1
G > 4104 4 sbin/pipe 10o RECEIVE 1
G > 4104 5 sbin/pipe 10o RECEIVE 1
G > 12292 1 sbin/mqueue 10o RECEIVE 1
G > 40969 1 sbin/enum-devices 10o REPLY 4104
G > 65548 1 sbin/devp-pccard 21o RECEIVE 1
G > 65549 1 sbin/enum-pccard 29f RECEIVE 1
G > 73738 1 sbin/io-audio 10o SIGWAITINFO
G > 73738 2 sbin/io-audio 10o RECEIVE 1
G > 73738 3 sbin/io-audio 10o RECEIVE 1
G > 73738 4 sbin/io-audio 10o RECEIVE 1
G > 73738 5 sbin/io-audio 50r INTR
G > 90123 1 sbin/devc-par 10o RECEIVE 1
G > 90123 2 sbin/devc-par 9r CONDVAR 80519e8
G > 106513 1 usr/sbin/spooler 10o NANOSLEEP
G > 114704 1 sbin/devb-fdc 10o SIGWAITINFO
G > 114704 2 sbin/devb-fdc 21r RECEIVE 1
G > 114704 3 sbin/devb-fdc 10o RECEIVE 7
G > 114704 4 sbin/devb-fdc 10o RECEIVE 4
G > 114704 5 sbin/devb-fdc 10o RECEIVE 4
G > 114704 6 sbin/devb-fdc 10o RECEIVE 4
G > 114706 1 sbin/devc-pty 10o RECEIVE 1
G > 118803 1 usr/sbin/random 10o SIGWAITINFO
G > 118803 2 usr/sbin/random 10o RECEIVE 1
G > 118803 3 usr/sbin/random 10o NANOSLEEP
G > 131092 1 usr/sbin/dumper 10o RECEIVE 1
G > 151574 1 sbin/io-net 10o SIGWAITINFO
G > 151574 2 sbin/io-net 20o RECEIVE 5
G > 151574 3 sbin/io-net 10o RECEIVE 1
G > 151574 4 sbin/io-net 10o RECEIVE 1
G > 151574 5 sbin/io-net 21r RECEIVE 19
G > 151574 6 sbin/io-net 10o RECEIVE 1
G > 213006 1 bin/login 10o REPLY 7
G > 213007 1 bin/login 10o REPLY 7
G > 213013 1 bin/login 10o REPLY 7
G > 258073 1 /photon/bin/Photon 12r RECEIVE 1
G > 286746 1 /photon/bin/phfont 10o JOIN 2
G > 286746 2 /photon/bin/phfont 10o RECEIVE 1
G > 299035 1 ton/bin/fontsleuth 10o RECEIVE 1
G > 299035 2 ton/bin/fontsleuth 10o SIGWAITINFO
G > 299035 3 ton/bin/fontsleuth 6o RECEIVE 1
G > 299035 4 ton/bin/fontsleuth 10o RECEIVE 1
G > 327710 1 on/bin/io-graphics 12r RECEIVE 1
G > 327710 2 on/bin/io-graphics 12r REPLY 299035
G > 327710 3 on/bin/io-graphics 12r REPLY 258073
G > 348189 1 ton/bin/devi-hirun 15o RECEIVE 1
G > 348189 2 ton/bin/devi-hirun 15o REPLY 7
G > 348189 3 ton/bin/devi-hirun 12o SIGWAITINFO
G > 360471 1 bin/login 10o REPLY 7
G > 466972 1 usr/photon/bin/pwm 10r RECEIVE 1
G > 512032 1 r/photon/bin/shelf 10r RECEIVE 1
G > 512032 2 r/photon/bin/shelf 10r CONDVAR 806cebc
G > 548897 1 photon/bin/bkgdmgr 10r RECEIVE 1
G > 548898 1 hoton/bin/wmswitch 10r RECEIVE 2
G > 548899 1 r/photon/bin/saver 10r RECEIVE 1
G > 577572 1 /X11R6/bin/XPhoton 10r SIGWAITINFO
G > 643103 1 bin/sh 10r SIGSUSPEND
G > 688152 1 ozilla/mozilla-bin 10r RECEIVE 1
G > 688152 2 ozilla/mozilla-bin 10r SIGWAITINFO
G > 688152 3 ozilla/mozilla-bin 10r RECEIVE 4
G > 688152 5 ozilla/mozilla-bin 10r CONDVAR 8149a00
G > 688152 9 ozilla/mozilla-bin 10r CONDVAR 89cb93c
G > 692261 1 c/gcc_ntox86/GTerm 10r RECEIVE 1
G > 692263 1 bin/sh 10r SIGSUSPEND
G > 704550 1 opt/bin/bash 10r REPLY 114706
G > 765993 1 bin/sh 10r SIGSUSPEND
G > 770088 1 opt/bin/bash 10r REPLY 1
G > 802858 1 bin/sh 10r SIGSUSPEND
G > 811051 1 opt/bin/bash 10r REPLY 1
G > 819245 1 usr/sbin/fs-cifs 10r RECEIVE 1
G > 819245 2 usr/sbin/fs-cifs 10r REPLY 151574
G > 819245 3 usr/sbin/fs-cifs 10r RECEIVE 1
G > 819245 4 usr/sbin/fs-cifs 10r RECEIVE 1
G > 852014 1 bin/sh 10r SIGSUSPEND
G > 856108 1 opt/bin/bash 10r REPLY 1
G > 901167 1 bin/ls 10r REPLY 819245
G > 921648 1 bin/pidin 10r REPLY 1
G > I ran pidin a few times with gaps of a few minutes, the state of the
G > fs-cifs threads is always the same.
G > I’d love to use Samba to share directories between my Sun and my QNX
G > laptop and desktop, so any help is much appreciated.
G > If it matters, my desktop is wired 100baseT ethernet, and the laptop is
G > 802.11g.
G > Thanks a lot
G > Garry
–
Bill Caroselli – Q-TPS Consulting
1-(708) 308-4956 <== Note: New Number qtps@earthlink.net
Is this just a UNIX Samba problem? Do Windows shares work OK?
EH > There is the ported Samba package that, I presume, is completely
EH > independent from QSS’s fs-cifs. It’s in the public repository, give it
EH > a try.
The Samba package you refer to is a QNX server package.
fs-cifs is a QNX client for a Samba server.
I have also seen this on a very regular basis. It is a bug and needs to
be fixed. I have however found a circumvention.
When this happens I open another pterm and do another ‘ls’ of the
mounted directory. Often times the second attempt doesn’t free
anything up. But then when I do a third ‘ls’ that frees up all the
pending requests.
This IS a pain in the a**. But at least you don’t have to reboot to
solve the problem.
slaying and restarting fs-cifs does the same job …
Regards
Armin
Bill & Armin,
Thanks for the tips, but I really need it to work properly, for backups
etc. I’d actually like to use Samba to share a home dir between my two
QNX machine, so I need it to work pretty much perfectly. Hopefully QSS
will fix this…
Is this just a UNIX Samba problem? Do Windows shares work OK?