[bug report] NFS and uninterruptable wait states

[bug report] NFS and uninterruptable wait states

[Phillip Susi]

The other day I was trying to set up an NFS mount to my room mate's system, 
and ran into what I at least, call a bug.  When I tried to mount his NFS 
export, the mount command locked up, and would not die.  Not even a SIGKILL 
would do any good.  According to ps, the mount process was in the 'D' - 
uninterruptable wait state.  It also looked like the WCHAN was rpc_ 
something.  I think it was waiting for an rpc call to return in the D state, 
and it never did return.  The bug here is that it should NOT be waiting in 
the D state for something that could never happen.  For that matter, why 
should anything ever need to wait in an uninterruptable state?  Whenever you 
wait, you should expect the possibility of being interrupted, check for that 
when you wake up, and if you were, clean up and return so the signal can be 
processed.

Anyhow, about an hour later ( the mount process still stuck ) I figured out 
that the other machine was not running rpc.nfsd, though it was running 
rpc.mountd.  Once I started rpc.nfsd on the machine, the mount on my box 
finally returned ( and was terminated by the SIGKILL that I sent it an hour 
before ).

Could someone confirm that this is a bug, and explain why anything should 
ever need to wait in that state?

Re: [bug report] NFS and uninterruptable wait states

[Phillip Susi]

That's all well and good that the process won't get an error back, but imho, 
a process should *NEVER* be beyond the reach of a SIGKILL.  I mean, an 
unkillable process prevents a clean shutdown, doesn't it?  ( can't kill the 
process, can't unmount the filesystem ).  

On Monday 03 September 2001 03:50 pm, Doug McNaught wrote:
> Phillip Susi <psusi@cfl.rr.com> writes:
> > The other day I was trying to set up an NFS mount to my room mate's
> > system, and ran into what I at least, call a bug.  When I tried to mount
> > his NFS export, the mount command locked up, and would not die.  Not even
> > a SIGKILL would do any good.  According to ps, the mount process was in
> > the 'D' - uninterruptable wait state.  It also looked like the WCHAN was
> > rpc_ something.  I think it was waiting for an rpc call to return in the
> > D state, and it never did return.  The bug here is that it should NOT be
> > waiting in the D state for something that could never happen.  For that
> > matter, why should anything ever need to wait in an uninterruptable
> > state?  Whenever you wait, you should expect the possibility of being
> > interrupted, check for that when you wake up, and if you were, clean up
> > and return so the signal can be processed.
>
> NFS does this (wait in D state) by default in order to prevent naive
> applications from getting timeout errors that they're not equipped to
> handle--the idea being that, if an NFS server goes down, programs
> using it will simply freeze and recover once it returns, rather than
> getting a timeout error and possibly becoming confused.
>
> If you don't like this behavior, mount with 'soft' and/or 'intr'
> options--see the manpage.
>
> -Doug

Re: [bug report] NFS and uninterruptable wait states

[Peter Wächtler]

Phillip Susi wrote:
> 
[ "mount -tnfs" with hard has default ]
 
> Anyhow, about an hour later ( the mount process still stuck ) I figured out
> that the other machine was not running rpc.nfsd, though it was running
> rpc.mountd.  Once I started rpc.nfsd on the machine, the mount on my box
> finally returned ( and was terminated by the SIGKILL that I sent it an hour
> before ).
> 
> Could someone confirm that this is a bug, and explain why anything should
> ever need to wait in that state?
> 
Well, if you use the option "soft",then your process is interruptible.
>From a user standpoint, I don't understand the requirement of 'D' state.

Where this gets really impractical: commands like df or du will
hang forever (if the other end is out of your control).

Re: [bug report] NFS and uninterruptable wait states

[Peter Wächtler]

Peter Wächtler wrote:
> 
> Phillip Susi wrote:
> >
> [ "mount -tnfs" with hard has default ]
> 
> > Anyhow, about an hour later ( the mount process still stuck ) I figured out
> > that the other machine was not running rpc.nfsd, though it was running
> > rpc.mountd.  Once I started rpc.nfsd on the machine, the mount on my box
> > finally returned ( and was terminated by the SIGKILL that I sent it an hour
> > before ).
> >
> > Could someone confirm that this is a bug, and explain why anything should
> > ever need to wait in that state?
> >
> Well, if you use the option "soft",then your process is interruptible.
> From a user standpoint, I don't understand the requirement of 'D' state.
> 
> Where this gets really impractical: commands like df or du will
> hang forever (if the other end is out of your control).

Err, "intr" will give you interruptible state. "hard" will retry forever,
"soft" will timeout and give up .

sorry

Re: [bug report] NFS and uninterruptable wait states

[Doug McNaught]

Phillip Susi <psusi@cfl.rr.com> writes:

> The other day I was trying to set up an NFS mount to my room mate's system, 
> and ran into what I at least, call a bug.  When I tried to mount his NFS 
> export, the mount command locked up, and would not die.  Not even a SIGKILL 
> would do any good.  According to ps, the mount process was in the 'D' - 
> uninterruptable wait state.  It also looked like the WCHAN was rpc_ 
> something.  I think it was waiting for an rpc call to return in the D state, 
> and it never did return.  The bug here is that it should NOT be waiting in 
> the D state for something that could never happen.  For that matter, why 
> should anything ever need to wait in an uninterruptable state?  Whenever you 
> wait, you should expect the possibility of being interrupted, check for that 
> when you wake up, and if you were, clean up and return so the signal can be 
> processed.

NFS does this (wait in D state) by default in order to prevent naive
applications from getting timeout errors that they're not equipped to
handle--the idea being that, if an NFS server goes down, programs
using it will simply freeze and recover once it returns, rather than
getting a timeout error and possibly becoming confused.

If you don't like this behavior, mount with 'soft' and/or 'intr'
options--see the manpage.

-Doug
-- 
Free Dmitry Sklyarov! 
http://www.freesklyarov.org/ 

We will return to our regularly scheduled signature shortly.

Re: [bug report] NFS and uninterruptable wait states

[David Woodhouse]

doug@wireboard.com said:
>  NFS does this (wait in D state) by default in order to prevent naive
> applications from getting timeout errors that they're not equipped to
> handle--the idea being that, if an NFS server goes down, programs
> using it will simply freeze and recover once it returns, rather than
> getting a timeout error and possibly becoming confused. 

Timeouts are a completely separate issue, surely? Applications ought to be 
able to deal with getting a _signal_ during a system call, whatever happens.

IMO, sleeping in state TASK_UNINTERRUPTIBLE in any situation where you can't
prove that the wakeup _will_ happen and will happen _soon_ should be
considered a bug - it's almost always just because someone hasn't bothered
to implement the cleanup code required for dealing with being interrupted.

/me tries to work out why anyone would ever want filesystem accesses to be 
uninterruptible.

--
dwmw2

Re: [bug report] NFS and uninterruptable wait states

[Peter Wächtler]

David Woodhouse wrote:
> 
> doug@wireboard.com said:
> >  NFS does this (wait in D state) by default in order to prevent naive
> > applications from getting timeout errors that they're not equipped to
> > handle--the idea being that, if an NFS server goes down, programs
> > using it will simply freeze and recover once it returns, rather than
> > getting a timeout error and possibly becoming confused.
> 
> Timeouts are a completely separate issue, surely? Applications ought to be
> able to deal with getting a _signal_ during a system call, whatever happens.
> 
> IMO, sleeping in state TASK_UNINTERRUPTIBLE in any situation where you can't
> prove that the wakeup _will_ happen and will happen _soon_ should be
> considered a bug - it's almost always just because someone hasn't bothered
> to implement the cleanup code required for dealing with being interrupted.
> 
> /me tries to work out why anyone would ever want filesystem accesses to be
> uninterruptible.
> 
Because historically the 'D' meant "wait on _D_isk" 8-)

Re: [bug report] NFS and uninterruptable wait states

[David Woodhouse]

pwaechtler@loewe-komp.de said:
>  Because historically the 'D' meant "wait on _D_isk" 8-)

Waiting uninterruptibly on a local device is somewhat saner than waiting
uninterruptibly on a network server. If you ignore the cases where we end up
in D state waiting for a removable medium which has been removed, of course.

These days, disk technology is sufficiently complex that the cop-out of 
saying "nothing will ever go wrong, let's not bother to implement the 
cleanup code" is probably no longer appropriate even there.

--
dwmw2

Re: [bug report] NFS and uninterruptable wait states

[Doug McNaught]

Phillip Susi <psusi@cfl.rr.com> writes:

> That's all well and good that the process won't get an error back, but imho, 
> a process should *NEVER* be beyond the reach of a SIGKILL.  I mean, an 
> unkillable process prevents a clean shutdown, doesn't it?  ( can't kill the 
> process, can't unmount the filesystem ).  

D state has always meant unkillable.  If you don't like it, you now
know how to change it.

-Doug
-- 
Free Dmitry Sklyarov! 
http://www.freesklyarov.org/ 

We will return to our regularly scheduled signature shortly.

Re: [bug report] NFS and uninterruptable wait states

[Doug McNaught]

David Woodhouse <dwmw2@infradead.org> writes:

> /me tries to work out why anyone would ever want filesystem accesses to be 
> uninterruptible.

Hmmm, "because V6 did it that way"?  It was probably significantly
faster back in those days...

;)

-Doug
-- 
Free Dmitry Sklyarov! 
http://www.freesklyarov.org/ 

We will return to our regularly scheduled signature shortly.

Sound Blaster Live - OSS or Not?

[Thiago Vinhas de Moraes]

Hi!

I have a Sound Blaster Live! PCI that works pretty fine for me. 

I tried to run loki's Quake 3 Arena for Linux, and after several tries, I 
started to read the README file, and it said that Sound Blaster Live does not 
work as OSS. I found a reference to www.opensound.com, where they sell OSS 
drivers for Sound Blaster Live for $35.00 !! That's too much money for a 
sound driver! I've downloaded a trial, and it really worked to play Quake.

My question is: If the 2.4.9 kernel has support for Sound Blaster Live, why I 
have to pay for a damn non-GPL driver? Why it does not work to play games on 
linux?


Regards,
Thiago

Re: Sound Blaster Live - OSS or Not?

[Thiago Vinhas de Moraes]

Em Seg, 03 de Set de 2001 19:26, Tim Jansen escreveu:
> On Tuesday 04 September 2001 00:11, Thiago Vinhas de Moraes wrote:
> > I tried to run loki's Quake 3 Arena for Linux, and after several tries, I
> > started to read the README file, and it said that Sound Blaster Live does
> > not work as OSS. I found a reference to www.opensound.com, where they
> > sell OSS drivers for Sound Blaster Live for $35.00 !!
>
> Use the alsa driver from www.alsa-project.org
>
> bye...

Why isn't it on the kernel tree?

Re: Sound Blaster Live - OSS or Not?

[Tim Jansen]

On Tuesday 04 September 2001 00:11, Thiago Vinhas de Moraes wrote:
> I tried to run loki's Quake 3 Arena for Linux, and after several tries, I
> started to read the README file, and it said that Sound Blaster Live does
> not work as OSS. I found a reference to www.opensound.com, where they sell
> OSS drivers for Sound Blaster Live for $35.00 !! 

Use the alsa driver from www.alsa-project.org

bye...

Re: Sound Blaster Live - OSS or Not?

[Robert Love]

On Mon, 2001-09-03 at 18:26, Thiago Vinhas de Moraes wrote:
> > Use the alsa driver from www.alsa-project.org
> Why isn't it on the kernel tree?

Because ALSA is not in the kernel tree. ALSA is a completely different
sound system from OSS, and ALSA is not in the tree. Many find ALSA
superior, and suggest it replace OSS. ALSA may find its way into the
tree during 2.5.

Of note, I don't know why SBLive does not work w/o these drivers. SBLive
in the kernel tree is very functional, and the OSS version should work
fine (assuming the game works with OSS).

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net

Re: Sound Blaster Live - OSS or Not?

[Joel Jaeggli]

On Mon, 3 Sep 2001, Thiago Vinhas de Moraes wrote:

>
> Hi!
>
> I have a Sound Blaster Live! PCI that works pretty fine for me.
>
> I tried to run loki's Quake 3 Arena for Linux, and after several tries, I
> started to read the README file, and it said that Sound Blaster Live does not
> work as OSS. I found a reference to www.opensound.com, where they sell OSS
> drivers for Sound Blaster Live for $35.00 !! That's too much money for a
> sound driver! I've downloaded a trial, and it really worked to play Quake.
>
> My question is: If the 2.4.9 kernel has support for Sound Blaster Live, why I
> have to pay for a damn non-GPL driver? Why it does not work to play games on
> linux?

sound support is hard... The folks at 4-front have the benefit of a
liscense from the vendor for their intelectual property property used in
the driver... That has two implications, The code is proprietary, and the
vendor must be paid... I don't imagine they're getting rich in the
business but if you have a card that has a chipset that is supported well
by them and poorly by the various other sound initiatives, you have to
decide wether it's worth it or not.

In any case your card is fairly well supported by the alsa-project... so
I'd recomend trying the alsa drivers

>
> Regards,
> Thiago
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
--------------------------------------------------------------------------
Joel Jaeggli				       joelja@darkwing.uoregon.edu
Academic User Services			     consult@gladstone.uoregon.edu
     PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E
--------------------------------------------------------------------------
It is clear that the arm of criticism cannot replace the criticism of
arms.  Karl Marx -- Introduction to the critique of Hegel's Philosophy of
the right, 1843.

Re: Sound Blaster Live - OSS or Not?

[machack]

I have been using the sblive kernel drivers for a year and have not had any 
problems with quake3.  the driver in 2.4.9 works well for me except my mic 
doesn't' want to work. 

On Monday 03 September 2001 07:03 pm, Joel Jaeggli wrote:
> On Mon, 3 Sep 2001, Thiago Vinhas de Moraes wrote:
> > Hi!
> >
> > I have a Sound Blaster Live! PCI that works pretty fine for me.
> >
> > I tried to run loki's Quake 3 Arena for Linux, and after several tries, I
> > started to read the README file, and it said that Sound Blaster Live does
> > not work as OSS. I found a reference to www.opensound.com, where they
> > sell OSS drivers for Sound Blaster Live for $35.00 !! That's too much
> > money for a sound driver! I've downloaded a trial, and it really worked
> > to play Quake.
> >
> > My question is: If the 2.4.9 kernel has support for Sound Blaster Live,
> > why I have to pay for a damn non-GPL driver? Why it does not work to play
> > games on linux?
>
> sound support is hard... The folks at 4-front have the benefit of a
> liscense from the vendor for their intelectual property property used in
> the driver... That has two implications, The code is proprietary, and the
> vendor must be paid... I don't imagine they're getting rich in the
> business but if you have a card that has a chipset that is supported well
> by them and poorly by the various other sound initiatives, you have to
> decide wether it's worth it or not.
>
> In any case your card is fairly well supported by the alsa-project... so
> I'd recomend trying the alsa drivers
>
> > Regards,
> > Thiago
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> > in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/

Re: Sound Blaster Live - OSS or Not?

[Garett Spencley]

On 3 Sep 2001, Robert Love wrote:

> On Mon, 2001-09-03 at 18:26, Thiago Vinhas de Moraes wrote:
> > > Use the alsa driver from www.alsa-project.org
> > Why isn't it on the kernel tree?
>
> Because ALSA is not in the kernel tree. ALSA is a completely different
> sound system from OSS, and ALSA is not in the tree. Many find ALSA
> superior, and suggest it replace OSS. ALSA may find its way into the
> tree during 2.5.
>
> Of note, I don't know why SBLive does not work w/o these drivers. SBLive
> in the kernel tree is very functional, and the OSS version should work
> fine (assuming the game works with OSS).
>
>

I'm also experiencing problems with Q3A and SB Live! It worked fine for
me before 2.4.9, but now with the "new" emu10k1 drivers it segfaults.

I already reported this earlier when 2.4.8-ac tree included the new
emu10k1 drivers but nothing came of it. Then Alan Cox reverted the drivers
and it worked fine. Now with 2.4.9 it segaults again.

I'll have to give the alsa drivers a try I guess.

-- 
Garett Spencley

I encourage you to encrypt e-mail sent to me using PGP
Public key at http://www.geocities.com/gspencley/public_key.txt
Key fingerprint: 8062 1A46 9719 C929 578C BB4E 7799 EC1A AB12 D3B9

Re: Sound Blaster Live - OSS or Not?

[Daryl F]

I use alsasound with this card. It is free! Just be sure to configure it
for OSS emulation. You can find the software at
http://www.alsa-project.org/

HTH,
Daryl

On Mon, 3 Sep 2001, Thiago Vinhas de Moraes wrote:

>
> Hi!
>
> I have a Sound Blaster Live! PCI that works pretty fine for me.
>
> I tried to run loki's Quake 3 Arena for Linux, and after several tries, I
> started to read the README file, and it said that Sound Blaster Live does not
> work as OSS. I found a reference to www.opensound.com, where they sell OSS
> drivers for Sound Blaster Live for $35.00 !! That's too much money for a
> sound driver! I've downloaded a trial, and it really worked to play Quake.
>
> My question is: If the 2.4.9 kernel has support for Sound Blaster Live, why I
> have to pay for a damn non-GPL driver? Why it does not work to play games on
> linux?
>
>
> Regards,
> Thiago
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Sound Blaster Live - OSS or Not?

[rui.p.m.sousa]

On Mon, 3 Sep 2001, Thiago Vinhas de Moraes wrote:

>
> Hi!
>
> I have a Sound Blaster Live! PCI that works pretty fine for me.
>
> I tried to run loki's Quake 3 Arena for Linux, and after several tries, I
> started to read the README file,

Some persons are reporting problems with Q3 (which mmap's /dev/dsp)
and the latest emu10k1 driver. Others (like me) don't see any problems.
Under investigation.

What Q3 version are you using?
Can you send me a strace of the Q3 startup?

> and it said that Sound Blaster Live does not
> work as OSS.

The driver definetely follows the OSS specification. If a problem was
found at Loki then it would be nice to have a detailed bug report...


Rui Sousa

> I found a reference to www.opensound.com, where they sell OSS
> drivers for Sound Blaster Live for $35.00 !! That's too much money for a
> sound driver! I've downloaded a trial, and it really worked to play Quake.
>
> My question is: If the 2.4.9 kernel has support for Sound Blaster Live, why I
> have to pay for a damn non-GPL driver? Why it does not work to play games on
> linux?
>
>
> Regards,
> Thiago
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: Sound Blaster Live - OSS or Not?

[Thiago Vinhas de Moraes]

[-- Attachment #1: Type: text/plain, Size: 1397 bytes --]

Em Ter, 04 de Set de 2001 09:09, rui.p.m.sousa@clix.pt escreveu:
> On Mon, 3 Sep 2001, Thiago Vinhas de Moraes wrote:
> > Hi!
> >
> > I have a Sound Blaster Live! PCI that works pretty fine for me.
> >
> > I tried to run loki's Quake 3 Arena for Linux, and after several tries, I
> > started to read the README file,
>
> Some persons are reporting problems with Q3 (which mmap's /dev/dsp)
> and the latest emu10k1 driver. Others (like me) don't see any problems.
> Under investigation.
>
> What Q3 version are you using?
> Can you send me a strace of the Q3 startup?
>
> > and it said that Sound Blaster Live does not
> > work as OSS.
>
> The driver definetely follows the OSS specification. If a problem was
> found at Loki then it would be nice to have a detailed bug report...

The strace log is attached to this message.
I really don't know how to make this work properly, since the only way I got 
Q3 to work with my SBLive was using the commercial OSS from opensound.com. 
The OSS/Free and the Alsa Project just give me the same output:

...loading 'scripts/organics.shader'
...loading 'scripts/sfx.shader'
...loading 'scripts/shrine.shader'
...loading 'scripts/skin.shader'
...loading 'scripts/sky.shader'
...loading 'scripts/test.shader'
----- finished R_Init -----
 
------- sound initialization -------
------------------------------------
Received signal 11, exiting...

Regards,
Thiago

[-- Attachment #2: q3error.log --]
[-- Type: text/plain, Size: 17980 bytes --]

execve("./q3demo", ["./q3demo"], [/* 36 vars */]) = 0
uname({sys="Linux", node="zeus.networx.com.br", ...}) = 0
brk(0)                                  = 0x80ca070
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=97651, ...}) = 0
old_mmap(NULL, 97651, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
close(3)                                = 0
open("/lib/libtermcap.so.2", O_RDONLY)  = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\16\0\000"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=12120, ...}) = 0
old_mmap(NULL, 15208, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002f000
mprotect(0x40032000, 2920, PROT_NONE)   = 0
old_mmap(0x40032000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 0x40032000
close(3)                                = 0
open("/lib/libdl.so.2", O_RDONLY)       = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\36\0\000"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=65873, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40033000
old_mmap(NULL, 12780, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40034000
mprotect(0x40037000, 492, PROT_NONE)    = 0
old_mmap(0x40037000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 0x40037000
close(3)                                = 0
open("/lib/i686/libc.so.6", O_RDONLY)   = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\307"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=5745438, ...}) = 0
old_mmap(NULL, 1283656, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40038000
mprotect(0x40168000, 38472, PROT_NONE)  = 0
old_mmap(0x40168000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12f000) = 0x40168000
old_mmap(0x4016e000, 13896, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4016e000
close(3)                                = 0
munmap(0x40017000, 97651)               = 0
getpid()                                = 1125
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3
close(3)                                = 0
brk(0)                                  = 0x80ca070
brk(0x80cb000)                          = 0x80cb000
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
brk(0x80cc000)                          = 0x80cc000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
brk(0x80cd000)                          = 0x80cd000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/usr/share/locale/locale.alias", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2601, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
read(3, "# Locale name alias data base.\n#"..., 4096) = 2601
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
brk(0x80ce000)                          = 0x80ce000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
brk(0x80cf000)                          = 0x80cf000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
brk(0x80d0000)                          = 0x80d0000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0x40017000, 4096)                = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/usr/lib/locale/pt_BR/LC_IDENTIFICATION", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=346, ...}) = 0
mmap2(NULL, 346, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40017000
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(3)                                = 0
open("/usr/lib/locale/pt_BR/LC_MEASUREMENT", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=28, ...}) = 0
mmap2(NULL, 28, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/usr/lib/locale/pt_BR/LC_TELEPHONE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 0
mmap2(NULL, 54, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40019000
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/usr/lib/locale/pt_BR/LC_ADDRESS", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=132, ...}) = 0
mmap2(NULL, 132, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001a000
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/usr/lib/locale/pt_BR/LC_NAME", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=67, ...}) = 0
mmap2(NULL, 67, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001b000
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(3)                                = 0
open("/usr/lib/locale/pt_BR/LC_PAPER", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=39, ...}) = 0
mmap2(NULL, 39, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001c000
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/usr/lib/locale/pt_BR/LC_MESSAGES", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
close(3)                                = 0
open("/usr/lib/locale/pt_BR/LC_MESSAGES/SYS_LC_MESSAGES", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=59, ...}) = 0
mmap2(NULL, 59, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001d000
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/usr/lib/locale/pt_BR/LC_MONETARY", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=295, ...}) = 0
mmap2(NULL, 295, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001e000
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(3)                                = 0
open("/usr/lib/locale/pt_BR/LC_COLLATE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=21499, ...}) = 0
mmap2(NULL, 21499, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4001f000
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/usr/lib/locale/pt_BR/LC_TIME", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2356, ...}) = 0
mmap2(NULL, 2356, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40025000
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(3)                                = 0
open("/usr/lib/locale/pt_BR/LC_NUMERIC", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=59, ...}) = 0
mmap2(NULL, 59, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40026000
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/usr/lib/locale/pt_BR/LC_CTYPE", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=173408, ...}) = 0
mmap2(NULL, 173408, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40172000
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
close(3)                                = 0
getuid32()                              = 0
getgid32()                              = 0
geteuid32()                             = 0
getegid32()                             = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
time(NULL)                              = 999623151
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
open("/etc/mtab", O_RDONLY)             = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=188, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40027000
read(3, "/dev/hda6 / reiserfs rw 0 0\nnone"..., 4096) = 188
close(3)                                = 0
munmap(0x40027000, 4096)                = 0
open("/proc/meminfo", O_RDONLY)         = 3
fstat64(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40027000
read(3, "        total:    used:    free:"..., 4096) = 573
close(3)                                = 0
munmap(0x40027000, 4096)                = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
uname({sys="Linux", node="zeus.networx.com.br", ...}) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
brk(0x80d1000)                          = 0x80d1000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
brk(0x80d2000)                          = 0x80d2000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
brk(0x80d3000)                          = 0x80d3000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
brk(0x80d4000)                          = 0x80d4000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
stat64("/usr/local/games/quake3", {st_mode=S_IFDIR|0755, st_size=256, ...}) = 0
stat64(".", {st_mode=S_IFDIR|0755, st_size=256, ...}) = 0
getpid()                                = 1125
getppid()                               = 1124
getpgrp()                               = 1124
rt_sigaction(SIGCHLD, {0x806fe10, [], 0x4000000}, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
open("./q3demo", O_RDONLY|O_LARGEFILE)  = 3
_llseek(3, 0, [0], SEEK_CUR)            = 0
read(3, "#!/bin/sh\n# Needed to make symli"..., 80) = 80
_llseek(3, 0, [0], SEEK_SET)            = 0
getrlimit(0x7, 0xbffff798)              = 0
dup2(3, 255)                            = 255
close(3)                                = 0
fcntl64(255, F_SETFD, FD_CLOEXEC)       = 0
fcntl64(255, F_GETFL)                   = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat64(255, {st_mode=S_IFREG|0755, st_size=168, ...}) = 0
_llseek(255, 0, [0], SEEK_CUR)          = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
brk(0x80d5000)                          = 0x80d5000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
read(255, "#!/bin/sh\n# Needed to make symli"..., 168) = 168
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
brk(0x80d6000)                          = 0x80d6000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
chdir("/usr/local/games/quake3")        = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [INT CHLD], [], 8) = 0
_llseek(255, -8, [160], SEEK_CUR)       = 0
fork()                                  = 1126
Q3 1.11 linux-i386 Dec  4 1999
rt_sigprocmask(SIG_BLOCK, ~[], [INT CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [INT CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_BLOCK, ~[], [CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGINT, {0x806f0c0, [], 0x4000000}, {SIG_DFL}, 8) = 0
wait4(-1, ----- FS_Startup -----
Current search path:
/root/.q3a/baseq3
./baseq3

----------------------

Running in restricted demo mode.

----- FS_Startup -----
Current search path:
/root/.q3a/demoq3
./demoq3/pak0.pk3 (1387 files)
./demoq3

----------------------
execing default.cfg
execing q3config.cfg
couldn't exec autoexec.cfg
----- Client Initialization -----
----- Initializing Renderer ----
-------------------------------
----- Client Initialization Complete -----
--- Common Initialization Complete ---
Opening IP socket: localhost:27960
Hostname: zeus.networx.com.br
Alias: zeus
IP: 192.168.0.4
----- R_Init -----
...loading libGL.so: Initializing OpenGL display
...setting mode 6: 1024 768
Using XFree86-VidModeExtension Version 2.0
XF86DGA Mouse (Version 2.0) initialized
XFree86-VidModeExtension Activated at 1024x768
Using 8/8/8 Color bits, 24 depth, 0 stencil display.
Initializing OpenGL extensions
...GL_S3_s3tc not found
...ignoring GL_EXT_texture_env_add
...using GL_ARB_multitexture
...using GL_EXT_compiled_vertex_array

GL_VENDOR: NVIDIA Corporation
GL_RENDERER: RIVA TNT/AGP/SSE
GL_VERSION: 1.2.2
GL_EXTENSIONS: GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_env_add GL_ARB_transpose_matrix GL_EXT_abgr GL_EXT_bgra GL_EXT_compiled_vertex_array GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_stencil_wrap GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_vertex_weighting GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_evaluators GL_NV_fog_distance GL_NV_packed_depth_stencil GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_SGIS_multitexture 
GL_MAX_TEXTURE_SIZE: 2048
GL_MAX_ACTIVE_TEXTURES_ARB: 2

PIXELFORMAT: color(24-bits) Z(24-bit) stencil(0-bits)
MODE: 6, 1024 x 768 fullscreen hz:N/A
GAMMA: software w/ 0 overbright bits
CPU: 
rendering primitives: single glDrawElements
texturemode: GL_LINEAR_MIPMAP_NEAREST
picmip: 1
texture bits: 0
multitexture: enabled
compiled vertex arrays: enabled
texenv add: disabled
compressed textures: disabled
Initializing Shaders
...loading 'scripts/base.shader'
...loading 'scripts/base_button.shader'
...loading 'scripts/base_floor.shader'
...loading 'scripts/base_light.shader'
...loading 'scripts/base_object.shader'
...loading 'scripts/base_support.shader'
...loading 'scripts/base_trim.shader'
...loading 'scripts/base_wall.shader'
...loading 'scripts/common.shader'
...loading 'scripts/ctf.shader'
...loading 'scripts/eerie.shader'
...loading 'scripts/gfx.shader'
...loading 'scripts/gothic_block.shader'
...loading 'scripts/gothic_floor.shader'
...loading 'scripts/gothic_light.shader'
...loading 'scripts/gothic_trim.shader'
...loading 'scripts/gothic_wall.shader'
...loading 'scripts/hell.shader'
...loading 'scripts/liquid.shader'
...loading 'scripts/menu.shader'
...loading 'scripts/models.shader'
...loading 'scripts/organics.shader'
...loading 'scripts/sfx.shader'
...loading 'scripts/shrine.shader'
...loading 'scripts/skin.shader'
...loading 'scripts/sky.shader'
...loading 'scripts/test.shader'
----- finished R_Init -----

------- sound initialization -------
------------------------------------
[WIFEXITED(s) && WEXITSTATUS(s) == 1], 0, NULL) = 1126
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
--- SIGCHLD (Child exited) ---
wait4(-1, 0xbffff3cc, WNOHANG, NULL)    = -1 ECHILD (No child processes)
sigreturn()                             = ? (mask now [])
rt_sigaction(SIGINT, {SIG_DFL}, {0x806f0c0, [], 0x4000000}, 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TTOU], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
read(255, "exit $?\n", 168)             = 8
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
_exit(1)                                = ?

Re: Sound Blaster Live - OSS or Not?

[rui.p.m.sousa]

On Tue, 4 Sep 2001, Thiago Vinhas de Moraes wrote:

Apparently your strace is of the sh script that runs q3a, not of q3a
itself.

One thing I noticed is that you are running an ancient version of quake
(v1.11). Since there are people successfully running Q3 can you try to
update to the latest (v1.29h) and see if that fixes the problem?


> Em Ter, 04 de Set de 2001 09:09, rui.p.m.sousa@clix.pt escreveu:
> > On Mon, 3 Sep 2001, Thiago Vinhas de Moraes wrote:
> > > Hi!
> > >
> > > I have a Sound Blaster Live! PCI that works pretty fine for me.
> > >
> > > I tried to run loki's Quake 3 Arena for Linux, and after several tries, I
> > > started to read the README file,
> >
> > Some persons are reporting problems with Q3 (which mmap's /dev/dsp)
> > and the latest emu10k1 driver. Others (like me) don't see any problems.
> > Under investigation.
> >
> > What Q3 version are you using?
> > Can you send me a strace of the Q3 startup?
> >
> > > and it said that Sound Blaster Live does not
> > > work as OSS.
> >
> > The driver definetely follows the OSS specification. If a problem was
> > found at Loki then it would be nice to have a detailed bug report...
>
> The strace log is attached to this message.
> I really don't know how to make this work properly, since the only way I got
> Q3 to work with my SBLive was using the commercial OSS from opensound.com.
> The OSS/Free and the Alsa Project just give me the same output:

This indicates a problem with quake not the sound driver. Two totally
diferent drivers with the same problem...(when they are known to work
for other users)

Rui

> ...loading 'scripts/organics.shader'
> ...loading 'scripts/sfx.shader'
> ...loading 'scripts/shrine.shader'
> ...loading 'scripts/skin.shader'
> ...loading 'scripts/sky.shader'
> ...loading 'scripts/test.shader'
> ----- finished R_Init -----
>
> ------- sound initialization -------
> ------------------------------------
> Received signal 11, exiting...
>
> Regards,
> Thiago

Re: [bug report] NFS and uninterruptable wait states

[Jan Hudec]

> Timeouts are a completely separate issue, surely? Applications ought to be 
> able to deal with getting a _signal_ during a system call, whatever happens.
> 
> IMO, sleeping in state TASK_UNINTERRUPTIBLE in any situation where you can't
> prove that the wakeup _will_ happen and will happen _soon_ should be
> considered a bug - it's almost always just because someone hasn't bothered
> to implement the cleanup code required for dealing with being interrupted.
> 
> /me tries to work out why anyone would ever want filesystem accesses to be 
> uninterruptible.

generic_file_read does wait_on_page, which sleeps uninteruptibly. This
shouldn't be too difficult to change (once the pages are linked to file's
memory_area, generic_read_file redoes readpage on the same pages and it's
up to readpage to find out, weather the request is still pending or timed
out)

Other problem is the RPC layer. If it should check signal_pending only on
timeouts, it;s simple. If it should also check while waiting, it has to be
able to recognise the interupted call. And this in turn brings the problem
of discarding data requested by interupted and not restarted calls (eg. when
the process was killed by the signal). There is the nasty case when request
is sent to the server and sending process dies while waitig. But the request
is eventualy replied and the reply must be handled somewhere.

You are right about not bothering with cleanup code. But it's not easy to
have the RPC layer right.

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb@ucw.cz>