Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Eric S. Raymond]

I'm very pleased to be able to announce that the hang problem I reported on
the Tyan K7 Thunder dual-Athlon board last night seems to be resolved.  Thanks
to everybody on lkml who responded -- you did, in fact, provide the crucial
knowledge needed to solve this problem.

It appears the pre-2.4.8 versions of the emu10k1 driver that the SB
Live! uses have a problem -- they tend to cause PCI bus lockups when
the PCI bus is heavily loaded (e.g. by disk activity).  

The evidence for this is indirect but strong.  The hang happened in every
pre-2.4.8 configuration we tested if there was an SB Live! actually in the
machine.  It never happened if either 2.4.8 was running or the SB Live! was
removed.  This theory also accounts for our failure to observe hangs during
moderate to intense X GUI activity -- that traffic was going over the AGP
bus, and we had enough memory in the box that it never swapped.

Now that we seem to be out of the woods, I can cop to why I'm doing
qualification tests on bleeding-edge PCs.  I'm writing an article for
Linux Journal on building the ultimate Linux box.  I won't spoil the
surprise by telling you what else is in the machine, but I will tell
you that it is jaw-droppingly fast and sexy hardware and that you'll
get to read all about it before the end of the year.

In the meantime, here is my draft writeup on the hang problem:

<sect1 id='horror_story'><title>The Inevitable Horror Story</title>

<para>Sadly, life got much less pleasant for quite a while after that. We
started seeing mysterious hangs -- the machine would lock up hard and
random intervals, usually during disk I/O operations.  This is almost the
worst kind of problem to troubleshoot, as it leaves no clues other than the
bare fact of the machine's catatonia -- you get no oops message, and all
the state you might have used to post-mortem disappears when the machine is
reset.  The only kind of problem that's worse is one that adds
irreproducibility to the catatonia.  But fortunately, we found that doing
<command>make clean</command> or <command>make world</command> on an X
source tree produced the hang pretty reliably.</para>

<para>Approximately thirty hours of troubleshooting (interrupted by far too
little sleep) ensued as Gary and I tried to track down the problem.  We
formed and discarded lots of theories based on where we had not yet seen
the hang.  For a while we thought the problem only bit in console mode, not
in X mode. For another while we thought it happened only under SMP kernels.
For a third while we thought we could avoid it by compiling kernels for the
Pentium II rather than the Athlon. All these beliefs were eventually
falsified amidst much wailing and gnashing of teeth.</para>

<para>Once it became clear that there was a problem at or near the hardware
level, we still had a lot of hypotheses to choose from -- with all of them
having pretty unpleasant ramifications for our chances of qualifying this
box before I had to fly home.  Quite possibly the motherboard was bad.  Or
we might have been seeing thermal flakeouts due to insufficient cooling of
the motherboard chips or memory.</para>

<para>About eighteen hours in, just before we both crashed in exhaustion,
we posted the problem to the <email>linux-kernel</email> mailing list.  We
got a rather larger number of responses than we expected (nearly twenty)
within a few hours.  Several were quite helpful.  And the breakthrough came
when a couple of linux-kernel people confirmed that the SB Live! is a
frequent source of hangs and lockups on other fast PCI machines.  With a
few more hours of testing (during which our X source tree probably got
cleaned and rebuilt more times than is allowed by law) we satisfied
ourselves that the lockups stop happening when the SB Live! has been
summarily yanked from the machine.</para>

<para>The most helpful advice we got came from one Daniel T. Chen, who
reported that he had nailed some similar lockups to the SB Live! running
over a Via chipset -- and that they stopped when he upgraded to 2.4.8 and
the newest version of the emu10k1 driver.  So while Gary took a much-needed
break (and his wife and kids to a David Byrne concert), I built 2.4.8 (with
emu10k1.o hard-compiled in) and ran our torture test -- first with the SB
Live! omitted, and then with it in the machine.  No hang.  Victory!</para>

<para>Perhaps it's belaboring the obvious, but the way this problem got
resolved was yet another testimony to the power of open-source development
and the community that has evolved around it.  Once again, our
technology and our social machine complemented each other and delivered
the goods.</para>
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

What is a magician but a practicing theorist?
	-- Obi-Wan Kenobi, 'Return of the Jedi'

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Jeffrey Ingber]

> On 11 Aug 2001 22:52:32 -0400, Eric S. Raymond wrote:
 
> The evidence for this is indirect but strong.  The hang happened in every
> pre-2.4.8 configuration we tested if there was an SB Live! actually in the
> machine.  It never happened if either 2.4.8 was running or the SB Live! was
> removed.  This theory also accounts for our failure to observe hangs during

I've used ALSA for quite awhile for EMU10k1 (E-MU APS, not SBLive) and
have had no problems.  I noticed that the EMU10K1 driver was updated in
2.4.8 so I tried it.  I had a lockup four times during audio playback,
so I switched back to ALSA and now everything is stable once again.

Jeffrey H. Ingber (jhingber _at_ ix.netcom.com)

> 
> > moderate to intense X GUI activity -- that traffic was going over the AGP
> > bus, and we had enough memory in the box that it never swapped.
> > 
> > Now that we seem to be out of the woods, I can cop to why I'm doing
> > qualification tests on bleeding-edge PCs.  I'm writing an article for
> > Linux Journal on building the ultimate Linux box.  I won't spoil the
> > surprise by telling you what else is in the machine, but I will tell
> > you that it is jaw-droppingly fast and sexy hardware and that you'll
> > get to read all about it before the end of the year.
> > 
> > In the meantime, here is my draft writeup on the hang problem:
> > 
> > <sect1 id='horror_story'><title>The Inevitable Horror Story</title>
> > 
> > <para>Sadly, life got much less pleasant for quite a while after that. We
> > started seeing mysterious hangs -- the machine would lock up hard and
> > random intervals, usually during disk I/O operations.  This is almost the
> > worst kind of problem to troubleshoot, as it leaves no clues other than the
> > bare fact of the machine's catatonia -- you get no oops message, and all
> > the state you might have used to post-mortem disappears when the machine is
> > reset.  The only kind of problem that's worse is one that adds
> > irreproducibility to the catatonia.  But fortunately, we found that doing
> > <command>make clean</command> or <command>make world</command> on an X
> > source tree produced the hang pretty reliably.</para>
> > 
> > <para>Approximately thirty hours of troubleshooting (interrupted by far too
> > little sleep) ensued as Gary and I tried to track down the problem.  We
> > formed and discarded lots of theories based on where we had not yet seen
> > the hang.  For a while we thought the problem only bit in console mode, not
> > in X mode. For another while we thought it happened only under SMP kernels.
> > For a third while we thought we could avoid it by compiling kernels for the
> > Pentium II rather than the Athlon. All these beliefs were eventually
> > falsified amidst much wailing and gnashing of teeth.</para>
> > 
> > <para>Once it became clear that there was a problem at or near the hardware
> > level, we still had a lot of hypotheses to choose from -- with all of them
> > having pretty unpleasant ramifications for our chances of qualifying this
> > box before I had to fly home.  Quite possibly the motherboard was bad.  Or
> > we might have been seeing thermal flakeouts due to insufficient cooling of
> > the motherboard chips or memory.</para>
> > 
> > <para>About eighteen hours in, just before we both crashed in exhaustion,
> > we posted the problem to the <email>linux-kernel</email> mailing list.  We
> > got a rather larger number of responses than we expected (nearly twenty)
> > within a few hours.  Several were quite helpful.  And the breakthrough came
> > when a couple of linux-kernel people confirmed that the SB Live! is a
> > frequent source of hangs and lockups on other fast PCI machines.  With a
> > few more hours of testing (during which our X source tree probably got
> > cleaned and rebuilt more times than is allowed by law) we satisfied
> > ourselves that the lockups stop happening when the SB Live! has been
> > summarily yanked from the machine.</para>
> > 
> > <para>The most helpful advice we got came from one Daniel T. Chen, who
> > reported that he had nailed some similar lockups to the SB Live! running
> > over a Via chipset -- and that they stopped when he upgraded to 2.4.8 and
> > the newest version of the emu10k1 driver.  So while Gary took a much-needed
> > break (and his wife and kids to a David Byrne concert), I built 2.4.8 (with
> > emu10k1.o hard-compiled in) and ran our torture test -- first with the SB
> > Live! omitted, and then with it in the machine.  No hang.  Victory!</para>
> > 
> > <para>Perhaps it's belaboring the obvious, but the way this problem got
> > resolved was yet another testimony to the power of open-source development
> > and the community that has evolved around it.  Once again, our
> > technology and our social machine complemented each other and delivered
> > the goods.</para>
> > -- 
> > 		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
> > 
> > What is a magician but a practicing theorist?
> > 	-- Obi-Wan Kenobi, 'Return of the Jedi'
> > -
> > 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: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Alan Cox]

> I've used ALSA for quite awhile for EMU10k1 (E-MU APS, not SBLive) and
> have had no problems.  I noticed that the EMU10K1 driver was updated in
> 2.4.8 so I tried it.  I had a lockup four times during audio playback,
> so I switched back to ALSA and now everything is stable once again.

The in kernel one seemed fine. The 2.4.8 update one is definitely broken on
SMP boxes

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Manuel McLure]

On 2001.08.12 05:04 Alan Cox wrote:
> The in kernel one seemed fine. The 2.4.8 update one is definitely broken
> on
> SMP boxes

I'm getting 2.4.8 Oopsen that seem to be in emu10k1 code on UP - see my
message "2.4.8 oops in ksoftirqd_CPU0"...

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<manuel@mclure.org>     | and significant law, no man may kill a cat.
<http://www.mclure.org> |             -- H.P. Lovecraft

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Alan Cox]

> On 2001.08.12 05:04 Alan Cox wrote:
> > The in kernel one seemed fine. The 2.4.8 update one is definitely broken
> > on
> > SMP boxes
> 
> I'm getting 2.4.8 Oopsen that seem to be in emu10k1 code on UP - see my
> message "2.4.8 oops in ksoftirqd_CPU0"...

Yep. So far the new driver that Linus took from a non maintaier breaks

	SMP
	Some mixers
	Uniprocessor with some cards
	Surround sound (spews noise on cards)

so I think Linus should do the only sane thing - back it out. I'm backing
it out of -ac. Of my three boxes, one spews noise, one locks up smp and
one works.

Alan

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Nerijus Baliunas]

AC> Yep. So far the new driver that Linus took from a non maintaier breaks
AC> 
AC>         SMP
AC>         Some mixers
AC>         Uniprocessor with some cards
AC>         Surround sound (spews noise on cards)
AC> 
AC> so I think Linus should do the only sane thing - back it out. I'm backing
AC> it out of -ac. Of my three boxes, one spews noise, one locks up smp and
AC> one works.

But later there was a patch from maintainer (Rui Sousa). Besides, there were no
updates from maintainers for over a year, so I think "non maintainer" did a good
thing - at least maintainers started to send patches finally. Instead of backing out
I suggest for maintainers to send more patches...

Regards,
Nerijus

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Robert Love]

On 12 Aug 2001 22:30:39 +0200, Nerijus Baliunas wrote:
>> so I think Linus should do the only sane thing - back it out. I'm backing
>> it out of -ac. Of my three boxes, one spews noise, one locks up smp and
>> one works.
> 
> But later there was a patch from maintainer (Rui Sousa). Besides, there
> were no updates from maintainers for over a year, so I think
> "non maintainer" did a good thing - at least maintainers started to >
> send patches finally. Instead of backing out I suggest for maintainers
> to send more patches...

thank you :)

i think this is preferred to having a year-old revision in the kernel.

these problems (issues after Rui's update to my patch) are issues with
the driver itself, and hopefully they will be resolved now.  the number
of eyes looking at current code has grown greatly, now ...

certainly i did not intend for any issues with the driver update patch,
but some issues were fixed and many features were added (fwiw, i  have
no problems).

i suspect now the issues will be cleared up soon, and hopefully the
driver will see more frequent updates.

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

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Manuel McLure]

On 2001.08.12 13:15 Alan Cox wrote:
> > On 2001.08.12 05:04 Alan Cox wrote:
> > > The in kernel one seemed fine. The 2.4.8 update one is definitely
> broken
> > > on
> > > SMP boxes
> > 
> > I'm getting 2.4.8 Oopsen that seem to be in emu10k1 code on UP - see my
> > message "2.4.8 oops in ksoftirqd_CPU0"...
> 
> Yep. So far the new driver that Linus took from a non maintaier breaks
> 
> 	SMP
> 	Some mixers
> 	Uniprocessor with some cards
> 	Surround sound (spews noise on cards)
> 
> so I think Linus should do the only sane thing - back it out. I'm backing
> it out of -ac. Of my three boxes, one spews noise, one locks up smp and
> one works.

Does the CVS driver work? If it does I can try that one instead of the
in-kernel one.

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<manuel@mclure.org>     | and significant law, no man may kill a cat.
<http://www.mclure.org> |             -- H.P. Lovecraft

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Manuel McLure]

On 2001.08.12 13:35 Manuel McLure wrote:
> 
> On 2001.08.12 13:15 Alan Cox wrote:
> > Yep. So far the new driver that Linus took from a non maintaier breaks
> > 
> > 	SMP
> > 	Some mixers
> > 	Uniprocessor with some cards
> > 	Surround sound (spews noise on cards)
> > 
> > so I think Linus should do the only sane thing - back it out. I'm
> backing
> > it out of -ac. Of my three boxes, one spews noise, one locks up smp and
> > one works.
> 
> Does the CVS driver work? If it does I can try that one instead of the
> in-kernel one.

I've answered that one on my own - I installed today's CVS emu10k1 and got
another Oops:

ksymoops 2.4.0 on i686 2.4.6.  Options used
     -v /usr/src/linux-2.4.8/vmlinux (specified)
     -k ksyms.2.4.8 (specified)
     -l lsmod.2.4.8 (specified)
     -o /lib/modules/2.4.8 (specified)
     -m /usr/src/linux-2.4.8/System.map (specified)

Warning (compare_maps): mismatch on symbol tulip_max_interrupt_work  ,
tulip says d190236c, /lib/modules/2.4.8/kernel/drivers/net/tulip/tulip.o
says d190192c.  Ignoring /lib/modules/2.4.8/kernel/drivers/net/tulip/tulip.o
entry
Warning (compare_maps): mismatch on symbol tulip_rx_copybreak  , tulip says
d1902370, /lib/modules/2.4.8/kernel/drivers/net/tulip/tulip.o says
d1901930.  Ignoring /lib/modules/2.4.8/kernel/drivers/net/tulip/tulip.o
entry
Warning (compare_maps): mismatch on symbol usb_devfs_handle  , usbcore says
d18d12e0, /lib/modules/2.4.8/kernel/drivers/usb/usbcore.o says d18d0e00. 
Ignoring /lib/modules/2.4.8/kernel/drivers/usb/usbcore.o entry
Unable to handle kernel NULL pointer dereference at virtual address
00000000
d796940f
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<d796940f>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210082
eax: c60f4640   ebx: 00000000   ecx: 00000000   edx: 00000004
esi: 00200282   edi: 00000000   ebp: c02d0240   esp: caa2df70
ds: 0018   es: 0018   ss: 0018
Process cc1 (pid: 3337, stackpage=caa2d000)
Stack: 00000000 cf392ac4 00000000 c0116a34 c60f4640 00000001 c02d0280
fffffffe
       00200046 c01167fb c02d0280 caa2dfc4 00000000 c02cc900 c02744c8
c01082ac
       401a92c0 4015ba30 082f2378 bfffee98 c0106f54 401a92c0 00000004
082f2378
Call Trace: [<c0116a34>] [<c01167fb>] [<c01082ac>] [<c0106f54>]
Code: f6 03 02 75 04 56 9d eb 54 53 e8 e2 23 00 00 8d 44 24 04 50

>>EIP; d796940f <[emu10k1]emu10k1_waveout_bh+f/70>   <=====
Trace; c0116a34 <tasklet_hi_action+64/90>
Trace; c01167fb <do_softirq+4b/90>
Trace; c01082ac <do_IRQ+9c/b0>
Trace; c0106f54 <ret_from_intr+0/7>
Code;  d796940f <[emu10k1]emu10k1_waveout_bh+f/70>
00000000 <_EIP>:
Code;  d796940f <[emu10k1]emu10k1_waveout_bh+f/70>   <=====
   0:   f6 03 02                  testb  $0x2,(%ebx)   <=====
Code;  d7969412 <[emu10k1]emu10k1_waveout_bh+12/70>
   3:   75 04                     jne    9 <_EIP+0x9> d7969418
<[emu10k1]emu10k1_waveout_bh+18/70>
Code;  d7969414 <[emu10k1]emu10k1_waveout_bh+14/70>
   5:   56                        push   %esi
Code;  d7969415 <[emu10k1]emu10k1_waveout_bh+15/70>
   6:   9d                        popf
Code;  d7969416 <[emu10k1]emu10k1_waveout_bh+16/70>
   7:   eb 54                     jmp    5d <_EIP+0x5d> d796946c
<[emu10k1]emu10k1_waveout_bh+6c/70>
Code;  d7969418 <[emu10k1]emu10k1_waveout_bh+18/70>
   9:   53                        push   %ebx
Code;  d7969419 <[emu10k1]emu10k1_waveout_bh+19/70>
   a:   e8 e2 23 00 00            call   23f1 <_EIP+0x23f1> d796b800
<[emu10k1]emu10k1_waveout_update+0/a0>
Code;  d796941e <[emu10k1]emu10k1_waveout_bh+1e/70>
   f:   8d 44 24 04               lea    0x4(%esp,1),%eax
Code;  d7969422 <[emu10k1]emu10k1_waveout_bh+22/70>
  13:   50                        push   %eax

Kernel panic: Aiee, killing interrupt handler!

3 warnings issued.  Results may not be reliable.


So back to 2.4.6 for me.

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<manuel@mclure.org>     | and significant law, no man may kill a cat.
<http://www.mclure.org> |             -- H.P. Lovecraft

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Linus Torvalds]

In article <20010812145953.A955@ulthar.internal.mclure.org> you write:
>
>I've answered that one on my own - I installed today's CVS emu10k1 and got
>another Oops:

The oops seems to be due to "wave_dev->woinst" being NULL.

Can you try just adding the line

	if (!woinst)
		return;

to the top of the function (just before the "spin_lock_irqsave()"). Does
that fix it for you?

		Linus

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Manuel McLure]

On 2001.08.12 15:24 Linus Torvalds wrote:
> In article <20010812145953.A955@ulthar.internal.mclure.org> you write:
> >
> >I've answered that one on my own - I installed today's CVS emu10k1 and
> got
> >another Oops:
> 
> The oops seems to be due to "wave_dev->woinst" being NULL.
> 
> Can you try just adding the line
> 
> 	if (!woinst)
> 		return;
> 
> to the top of the function (just before the "spin_lock_irqsave()"). Does
> that fix it for you?
> 
> 		Linus

So far so good - however I don't have a consistent way to reproduce this.
I'll just keep running and see if the Oops happens again.

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<manuel@mclure.org>     | and significant law, no man may kill a cat.
<http://www.mclure.org> |             -- H.P. Lovecraft

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Linus Torvalds]

On Sun, 12 Aug 2001, Manuel McLure wrote:
> >
> > Can you try just adding the line
> >
> > 	if (!woinst)
> > 		return;
> >
> > to the top of the function (just before the "spin_lock_irqsave()"). Does
> > that fix it for you?
> >
> > 		Linus
>
> So far so good - however I don't have a consistent way to reproduce this.
> I'll just keep running and see if the Oops happens again.

Mind trying an alternate approach: remove the "if (!woinst)" thing, and
instead move the line that initializes the tasklets down two lines
(there's two places, they look something like

                tasklet_init(&wiinst->timer.tasklet, emu10k1_wavein_bh,  (unsigned long) wave_dev);
                wave_dev->wiinst = wiinst;
                emu10k1_wavein_setformat(wave_dev, &wiinst->format);

and they _should_ do the "tasklet_init()" _after_ the other
initializations, ie move that line down a bit, like so:

                wave_dev->wiinst = wiinst;
                emu10k1_wavein_setformat(wave_dev, &wiinst->format);
                tasklet_init(&wiinst->timer.tasklet, emu10k1_wavein_bh, (unsigned long) wave_dev);

Does that also fix it?

And sure, I realize that you want to run it for a while..

		Linus

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Manuel McLure]

On 2001.08.12 15:59 Linus Torvalds wrote:

> Mind trying an alternate approach: remove the "if (!woinst)" thing, and
> instead move the line that initializes the tasklets down two lines
> (there's two places, they look something like
> 
>                 tasklet_init(&wiinst->timer.tasklet, emu10k1_wavein_bh, 
> (unsigned long) wave_dev);
>                 wave_dev->wiinst = wiinst;
>                 emu10k1_wavein_setformat(wave_dev, &wiinst->format);
> 
> and they _should_ do the "tasklet_init()" _after_ the other
> initializations, ie move that line down a bit, like so:
> 
>                 wave_dev->wiinst = wiinst;
>                 emu10k1_wavein_setformat(wave_dev, &wiinst->format);
>                 tasklet_init(&wiinst->timer.tasklet, emu10k1_wavein_bh,
> (unsigned long) wave_dev);
> 
> Does that also fix it?
> 
> And sure, I realize that you want to run it for a while..

Done - I'll post any Oops that might show up. No news will good news :-)

-- 
Manuel A. McLure KE6TAW | ...for in Ulthar, according to an ancient
<manuel@mclure.org>     | and significant law, no man may kill a cat.
<http://www.mclure.org> |             -- H.P. Lovecraft

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Paul G. Allen]

Call me dumb, but what was wrong with the SB Live! code in the 2.4.7
trees? Mine works fine and has since I first installed RH 7.1 on this
system. The only problem I had was when I compiled it into the kernel
(instead of compiling as a module), sound would not work and I could not
configure it with sndconfig.

PGA

-- 
Paul G. Allen
UNIX Admin II/Network Security
Akamai Technologies, Inc.
www.akamai.com

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Justin A]

The sblive(!) driver in 2.4.7 may very well work, but it doesn't come
close to supporting all the features that the card has.  Whether or
not 2.5 is the place to implement those features is a whole other
matter...

-Justin

On Sun, Aug 12, 2001 at 05:36:54PM -0700, Paul G. Allen wrote:
> Call me dumb, but what was wrong with the SB Live! code in the 2.4.7
> trees? Mine works fine and has since I first installed RH 7.1 on this
> system. The only problem I had was when I compiled it into the kernel
> (instead of compiling as a module), sound would not work and I could not
> configure it with sndconfig.
> 
> PGA
> 
> -- 
> Paul G. Allen
> UNIX Admin II/Network Security
> Akamai Technologies, Inc.
> www.akamai.com
> -
> 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: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Mike Frisch]

On 12 Aug 2001 17:36:54 -0700, Paul G. Allen wrote:
> Call me dumb, but what was wrong with the SB Live! code in the 2.4.7
> trees? Mine works fine and has since I first installed RH 7.1 on this
> system. The only problem I had was when I compiled it into the kernel
> (instead of compiling as a module), sound would not work and I could not
> configure it with sndconfig.

While the SB Live! code seemed to work flawlessly on my Intel BX board,
since moving to the A7A266 (ALi MaGiK based), I am pretty much convinced
it has been the cause of my intermittent lockup problems.  Without the
emu10k1 driver loaded, I cannot get the machine to lockup and everytime
it has locked up the sound card has been in use.

Right now, I am running the ALSA driver (as somebody else had
mentioned), but not enough yet to know if it's going to cause a problem.

Mike.

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Linus Torvalds]

In article <3B772126.F23DB1D7@randomlogic.com> you write:
>Call me dumb, but what was wrong with the SB Live! code in the 2.4.7
>trees? Mine works fine and has since I first installed RH 7.1 on this
>system. The only problem I had was when I compiled it into the kernel
>(instead of compiling as a module), sound would not work and I could not
>configure it with sndconfig.

Well, the fact that it didn't work when compiled into the kernel means
(for me), that it doesn't work at all.

Also, if you followed the other thread on the Tyan Thunder lockup,
you'll have noticed that it locked up under heavy PCI loads. At least on
that machine it stopped with the 2.4.8 driver.

Does the new driver not work for you? There seems to be a bug at close()
time, in that the driver uses "tasklet_unlock_wait()" instead of
"tasklet_kill()" to kill the tasklets, and that wouldn't work reliably.

Anything else you can find?

		Linus

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Paul G. Allen]

Linus Torvalds wrote:
> 
> In article <3B772126.F23DB1D7@randomlogic.com> you write:
> >Call me dumb, but what was wrong with the SB Live! code in the 2.4.7
> >trees? Mine works fine and has since I first installed RH 7.1 on this
> >system. The only problem I had was when I compiled it into the kernel
> >(instead of compiling as a module), sound would not work and I could not
> >configure it with sndconfig.
> 
> Well, the fact that it didn't work when compiled into the kernel means
> (for me), that it doesn't work at all.

It is annoying not to be able to compile it as part of the kernel, but
it works as a module. I had thought that the maintainer would fix this,
but as you noted, apparently there is no longer a maintainer.

> 
> Also, if you followed the other thread on the Tyan Thunder lockup,
> you'll have noticed that it locked up under heavy PCI loads. At least on
> that machine it stopped with the 2.4.8 driver.

I hadn't read the entire thread, but I did see that heavy loads seemed
to be a problem. I am running a GeForce 3 and when I play games or do
other graphics related things - I have a few OpenGL projects I've been
working on - I try sqeak every bit of detail and piece of "eye candy" I
can out of the system, as well as the best available sound. I'd say
running Quake 3 at 1600x1200x32 in multiplayer should be a heavy load on
everything, including PCI.

> 
> Does the new driver not work for you? There seems to be a bug at close()
> time, in that the driver uses "tasklet_unlock_wait()" instead of
> "tasklet_kill()" to kill the tasklets, and that wouldn't work reliably.
> 
> Anything else you can find?
> 

I had just gotten the 2.4.7-ac10 kernel compiled and tweaked when the
2.4.8 kernel was released. I haven't had a chance to install 2.4.8 yet,
it's next on my ToDo list. Until now (reference my other post about
possible UDMA/ATA issues) I haven't been able to get a stable system for
any length of time with any kernel (save for the 5 - 6 other, older,
linux machines I have here all running RH 6.0 - 6.2).

When I get a 2.4.8 kernel installed I'll see how that works.

PGA

-- 
Paul G. Allen
UNIX Admin II/Network Security
Akamai Technologies, Inc.
www.akamai.com

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Nicholas Knight]

On Sunday 12 August 2001 06:33 pm, Paul G. Allen wrote:
> Linus Torvalds wrote:
<snip>
> > Also, if you followed the other thread on the Tyan Thunder lockup,
> > you'll have noticed that it locked up under heavy PCI loads. At least
> > on that machine it stopped with the 2.4.8 driver.
>
> I hadn't read the entire thread, but I did see that heavy loads seemed
> to be a problem. I am running a GeForce 3 and when I play games or do
> other graphics related things - I have a few OpenGL projects I've been
> working on - I try sqeak every bit of detail and piece of "eye candy" I
> can out of the system, as well as the best available sound. I'd say
> running Quake 3 at 1600x1200x32 in multiplayer should be a heavy load
> on everything, including PCI.

Not neccisarily, the primary load when playing/displaying anything on a 
GeForce card is on the processor and the AGP bus, not the PCI, even the 
NIC wouldn't be putting too much load on PCI. If you had other 
configuration issues that Q3 accessing the HDD a lot, then you might have 
a high load on the PCI bus. (if you do, feel free to contact me 
privately, I may be able to help you tweak things so that you don't get a 
lot of HDD access under Q3)

<snip>

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Linus Torvalds]

On Sun, 12 Aug 2001, Alan Cox wrote:
>
> so I think Linus should do the only sane thing - back it out. I'm backing
> it out of -ac. Of my three boxes, one spews noise, one locks up smp and
> one works.

The problem with backing it out is that apparently nobody has tried to
really maintain it for a year, and if it gets backed out nobody will even
bother to try to fix it. So I'll let it be for a while, at least.

		Linus

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Alan Cox]

> The problem with backing it out is that apparently nobody has tried to
> really maintain it for a year, and if it gets backed out nobody will even
> bother to try to fix it. So I'll let it be for a while, at least.

I thought this was a stable kernel tree not 2.5 ?

Alan

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Dax Kelson]

On Sun, 12 Aug 2001, Alan Cox wrote:

> > The problem with backing it out is that apparently nobody has tried to
> > really maintain it for a year, and if it gets backed out nobody will even
> > bother to try to fix it. So I'll let it be for a while, at least.
>
> I thought this was a stable kernel tree not 2.5 ?
>
> Alan

Just a random data point.  The SB Live driver in 2.4.x through .7 worked
just fine on my card.  I haven't tried 2.4.8 yet.

Dax

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Linus Torvalds]

In article <E15W3ZC-0006IC-00@the-village.bc.nu>,
Alan Cox  <alan@lxorguk.ukuu.org.uk> wrote:
>> The problem with backing it out is that apparently nobody has tried to
>> really maintain it for a year, and if it gets backed out nobody will even
>> bother to try to fix it. So I'll let it be for a while, at least.
>
>I thought this was a stable kernel tree not 2.5 ?

Well, considering that the _old_ driver is also not stable and doesn't
work on all machines, we're really screwed whichever way we turn. 

If the old driver was a known working one, this would be a no-brainer. 
As it is, the old driver doesn't work for people _either_ - but they
probably aren't piping up, because the old driver has been broken
forever. 

So we have a situation that the new driver works better on some
machines, and the old driver works better on others. The old driver will
obviously neevr get fixed (we've given it several years now), so the old
driver is _known_ to be terminally broken. The new driver is a question
mark in that regard.

So I'd rather give the new driver a chance, and see if people can get it
fixed.  For example, the oops that people have reported _seems_ to be
due to initializing the tasklet before actually having initialized all
the data structures the tasklet depends on.  It may well be that moving
the two "tasklet_init()"s down two lines would fix it.

		Linus

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Pavel Machek]

Hi!

> > The problem with backing it out is that apparently nobody has tried to
> > really maintain it for a year, and if it gets backed out nobody will even
> > bother to try to fix it. So I'll let it be for a while, at least.
> 
> I thought this was a stable kernel tree not 2.5 ?

Oops while *using* the driver seem to be much less severe than random
lockups when *NOT* using driver. According to ESR, 2.4.7 is doing the 
latter.
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Alan Cox]

> Oops while *using* the driver seem to be much less severe than random
> lockups when *NOT* using driver. According to ESR, 2.4.7 is doing the 
> latter.

And ESR is using a very early chipset with apic bugs out of the wazoo
that locks up anyway. So at the time lets say that wasnt useful data.
The 2.4.9 one seems to be better. The mixer is totally screwball but the
SMP lock seems to have gone away

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[rui.p.m.sousa]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1011 bytes --]


Alan Cox writes:

Did you have any lockups with non Athlon
motherboards?

>> On 2001.08.12 05:04 Alan Cox wrote:
>> > The in kernel one seemed fine. The 2.4.8 update one is definitely broken
>> > on
>> > SMP boxes
>> 
>> I'm getting 2.4.8 Oopsen that seem to be in emu10k1 code on UP - see my
>> message "2.4.8 oops in ksoftirqd_CPU0"...
> 
> Yep. So far the new driver that Linus took from a non maintaier breaks
> 
> 	SMP
> 	Some mixers
> 	Uniprocessor with some cards
> 	Surround sound (spews noise on cards)
> 
> so I think Linus should do the only sane thing - back it out. I'm backing
> it out of -ac. Of my three boxes, one spews noise, one locks up smp and
> one works.
> 
> Alan
> -
> 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/






--
Crie o seu Email Grátis no Clix em
http://registo.clix.pt/

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Alan Cox]

> But later there was a patch from maintainer (Rui Sousa). Besides, there were no
> updates from maintainers for over a year, so I think "non maintainer" did a good
> thing - at least maintainers started to send patches finally. Instead of backing out
> I suggest for maintainers to send more patches...

I've got an even better idea. Its called making major problematic device
changes and debugging them in _UNSTABLE_ kernel trees - like waiting until
2.5 starts. Otherwise 2.4 will never be stable.

Its one thing to take something like the early USB in a stable kernel and
update it because it certainly won't make it worse, and another to update
an emu10k1 driver that worked with one that doesn't work, needs different
user tools and locks all SMP boxes.

Alan

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Alan Cox]

> Does the new driver not work for you? There seems to be a bug at close()
> time, in that the driver uses "tasklet_unlock_wait()" instead of
> "tasklet_kill()" to kill the tasklets, and that wouldn't work reliably.

It hung my SMP box solid
It spews white noise on my box with surround speakers
And worked on the third

So I went back to the old one.

Alan

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[rui.p.m.sousa]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 748 bytes --]


Alan Cox writes:

>> Does the new driver not work for you? There seems to be a bug at close()
>> time, in that the driver uses "tasklet_unlock_wait()" instead of
>> "tasklet_kill()" to kill the tasklets, and that wouldn't work reliably.
> 
> It hung my SMP box solid
> It spews white noise on my box with surround speakers

Digital or analog speakers?

> And worked on the third
> 
> So I went back to the old one.
> 
> Alan
> -
> 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/






--
Crie o seu Email Grátis no Clix em
http://registo.clix.pt/

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Alan Cox]

> > Also, if you followed the other thread on the Tyan Thunder lockup,
> > you'll have noticed that it locked up under heavy PCI loads. At least on
> > that machine it stopped with the 2.4.8 driver.

No it merely made them less common. I think thats unrelated. Early AMD
chips had bugs, and the SB Live! is famous for triggering PCI bugs because
of the very unusual and tight PCI access patterns it generates - it was
the main trigger for the via audio corruption too (and the AMD chipset
shares common ancestry with the VIA..)

Alan

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Alan Cox]

> > It hung my SMP box solid
> > It spews white noise on my box with surround speakers
> 
> Digital or analog speakers?

Analogue four output - I didnt know you had digital out working 

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Tobias Ringstrom]

On Mon, 13 Aug 2001, Alan Cox wrote:

> > > It hung my SMP box solid
> > > It spews white noise on my box with surround speakers
> >
> > Digital or analog speakers?
>
> Analogue four output - I didnt know you had digital out working

Same for me, but I got rid of it by muting IGain (whatever that is),
and/or unplugging the microphone.

I did not investigate further.

/Tobias

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Anton Altaparmakov]

At 13:35 13/08/01, Alan Cox wrote:
> > > It hung my SMP box solid
> > > It spews white noise on my box with surround speakers
> >
> > Digital or analog speakers?
>
>Analogue four output - I didnt know you had digital out working

Digital output on my SB Live! has been working since before the original 
emu10k1 driver went into the kernel if my memory hasn't flipped a few bits (-;

And the old driver worked absolutely fine for that matter on my Dual 
Celeron workstation...

Haven't tried the new 2.4.8 emu10k1 addition yet, and considering you are 
reporting it hangs on smp it's probably a waste of time except to confirm 
the hangs...

Anton


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

RE: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Ryan C. Bonham]

Hi,

Ok I am going to stick my two cents in here.. I am not a Linux programmer,
and I am not going to pretend I am, but I do use Linux, have for quite some
time.. I am also implementing Linux in a business.. At home I use custom
built kernels, and play with experimental drivers, etc.. I patch/compile new
kernels all the time. I am running 2.4.8 at my house..(I have a sound
blaster live, and haven't had any problems with that...(all this is besides
the point)..

Anyways,  more to the point.. I don't see the problem with linus putting the
new driver in the 2.4.8 kernel.. Users who are compiling their own kernels,
know that a broken driver is a risk with any kernel.. And for the rest of
the users that rely on Redhat or another Dist company to provide kernels,
are fine, because I know Redhat won't package 2.4.8 with a broken sound
driver like that.. They will either fix (patch) it, or use 2.4.7.. As far as
this being a stable kernel release.. Ok that's true, so why not put it in
the AC tree and work out the bugs with there instead of Linus kernel..

So my basic question is; Alan, can you leave the new sound driver in your AC
kernels? Your kernels are great, and I would love to run them with the new
driver, even if it means I have to find some problems... 

Ok i am done putting my two cents in where it is't wanted :)

Ryan

> -----Original Message-----
> From: Linus Torvalds [mailto:torvalds@transmeta.com]
> Sent: Sunday, August 12, 2001 6:10 PM
> To: Alan Cox
> Cc: Manuel McLure; linux-kernel@vger.kernel.org
> Subject: Re: Hang problem on Tyan K7 Thunder resolved -- SB Live!
> heads-up
> 
> 
> 
> On Sun, 12 Aug 2001, Alan Cox wrote:
> >
> > so I think Linus should do the only sane thing - back it 
> out. I'm backing
> > it out of -ac. Of my three boxes, one spews noise, one 
> locks up smp and
> > one works.
> 
> The problem with backing it out is that apparently nobody has tried to
> really maintain it for a year, and if it gets backed out 
> nobody will even
> bother to try to fix it. So I'll let it be for a while, at least.
> 
> 		Linus
> 
> -
> 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: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Daniel T. Chen]

Or... you could use Alan's -ac patches with CVS checkouts from
opensource.creative.com, the "best of all 2.4 with sblive
worlds." ;) Coincidentally, this appeared earlier today:
-- snip --
Module name:    emu10k1
Changes by:     rsousa  01/08/13 07:42:32

Modified files:
        .              : audio.c 

Log message:
Corrected tasklet cleanup.
-- snip --

---
Dan Chen                 crimsun@email.unc.edu
GPG key: www.cs.unc.edu/~chenda/pubkey.gpg.asc

On Mon, 13 Aug 2001, Ryan C. Bonham wrote:

> So my basic question is; Alan, can you leave the new sound driver in your AC
> kernels? Your kernels are great, and I would love to run them with the new
> driver, even if it means I have to find some problems... 

Re: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Anton Altaparmakov]

At 13:35 13/08/01, Alan Cox wrote:
> > > It hung my SMP box solid
> > > It spews white noise on my box with surround speakers
> >
> > Digital or analog speakers?
>
>Analogue four output - I didnt know you had digital out working

To follow myself up: the new driver as found in 2.4.9-pre2 works fine for 
me on my GX440 dual celeron (Tyan Thunder Pro S1836DLUAN mobo). The driver 
is compiled into the kernel and I only tried digital output connected to a 
DTT2500 surround system.

No hangs while playing several mp3s (in X 4.0.3), seeking around them, etc. 
So the driver isn't all bad... It behaves exactly the same as the old one 
for my limited application test set.

Is it perhaps specific to the chipset and/or the actual type of SB Live 
card? - I have the original SB Live! (lspci -vvv output below).

Or does the hang only trigger when you do something specific? I could try 
to reproduce...

Anton

00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr+ Stepping- SERR+ FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort+ >SERR- <PERR-
         Latency: 64
         Region 0: Memory at e0000000 (32-bit, prefetchable) [size=256M]
         Capabilities: [a0] AGP version 1.0
                 Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
                 Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge (prog-if 
00 [Normal decode])
         Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
         Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64
         Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
         I/O behind bridge: 0000c000-0000cfff
         Memory behind bridge: fd300000-fe3fffff
         Prefetchable memory behind bridge: d9000000-dd0fffff
         BridgeCtl: Parity+ SERR- NoISA- VGA+ MAbort- >Reset- FastB2B+
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
         Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 0
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 
(prog-if 80 [Master])
         Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64
         Region 4: I/O ports at ffa0 [size=16]
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 
(prog-if 00 [UHCI])
         Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64
         Interrupt: pin D routed to IRQ 11
         Region 4: I/O ports at ef80 [size=32]
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
         Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Interrupt: pin ? routed to IRQ 9
00:10.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) 
(prog-if 00 [Normal decode])
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64, cache line size 08
         Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
         I/O behind bridge: 0000d000-0000dfff
         Memory behind bridge: fe400000-fe4fffff
         Prefetchable memory behind bridge: 00000000dd100000-00000000dd100000
         BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
         Capabilities: [dc] Power Management version 1
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=220mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
                 Bridge: PM- B3+
00:11.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] 
(rev 05)
         Subsystem: Intel Corporation 82558 10/100 with Wake on LAN
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64 (2000ns min, 14000ns max), cache line size 08
         Interrupt: pin A routed to IRQ 11
         Region 0: Memory at fd2ff000 (32-bit, prefetchable) [size=4K]
         Region 1: I/O ports at ef40 [size=32]
         Region 2: Memory at fea00000 (32-bit, non-prefetchable) [size=1M]
         Expansion ROM at fe900000 [disabled] [size=1M]
         Capabilities: [dc] Power Management version 1
                 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA 
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:12.0 SCSI storage controller: Adaptec AHA-2940U/UW / AHA-39xx / AIC-7895 
(rev 04)
         Subsystem: Adaptec AHA-2940U/2940UW Dual AHA-394xAU/AUW/AUWD AIC-7895B
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64 (2000ns min, 2000ns max), cache line size 08
         Interrupt: pin A routed to IRQ 10
         Region 0: I/O ports at e400 [disabled] [size=256]
         Region 1: Memory at febfe000 (32-bit, non-prefetchable) [size=4K]
         Expansion ROM at febe0000 [disabled] [size=64K]
         Capabilities: [dc] Power Management version 1
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:12.1 SCSI storage controller: Adaptec AHA-2940U/UW / AHA-39xx / AIC-7895 
(rev 04)
         Subsystem: Adaptec AHA-2940U/2940UW Dual AHA-394xAU/AUW/AUWD AIC-7895B
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64 (2000ns min, 2000ns max), cache line size 08
         Interrupt: pin B routed to IRQ 10
         Region 0: I/O ports at e800 [disabled] [size=256]
         Region 1: Memory at febff000 (32-bit, non-prefetchable) [size=4K]
         Capabilities: [dc] Power Management version 1
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:14.0 Multimedia controller: Sigma Designs, Inc. REALmagic Hollywood Plus 
DVD Decoder (rev 02)
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64
         Interrupt: pin A routed to IRQ 9
         Region 0: Memory at fe800000 (32-bit, non-prefetchable) [size=1M]
         Capabilities: [40] Power Management version 1
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 
04) (prog-if 00 [VGA])
         Subsystem: Matrox Graphics, Inc. Millennium G400 MAX/Dual Head 32Mb
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64 (4000ns min, 8000ns max), cache line size 08
         Interrupt: pin A routed to IRQ 10
         Region 0: Memory at da000000 (32-bit, prefetchable) [size=32M]
         Region 1: Memory at fe3fc000 (32-bit, non-prefetchable) [size=16K]
         Region 2: Memory at fd800000 (32-bit, non-prefetchable) [size=8M]
         Expansion ROM at fe3e0000 [disabled] [size=64K]
         Capabilities: [dc] Power Management version 2
                 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
         Capabilities: [f0] AGP version 2.0
                 Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
                 Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x1
02:05.0 Multimedia audio controller: Creative Labs SB Live! EMU10000 (rev 05)
         Subsystem: Creative Labs CT4620 SBLive!
         Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64 (500ns min, 5000ns max)
         Interrupt: pin A routed to IRQ 9
         Region 0: I/O ports at df80 [size=32]
         Capabilities: [dc] Power Management version 1
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
02:05.1 Input device controller: Creative Labs SB Live! (rev 05)
         Subsystem: Creative Labs Gameport Joystick
         Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64
         Region 0: I/O ports at dff0 [size=8]
         Capabilities: [dc] Power Management version 1
                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
02:06.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 11)
         Subsystem: Hauppauge computer works Inc.: Unknown device 13eb
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64 (4000ns min, 10000ns max)
         Interrupt: pin A routed to IRQ 5
         Region 0: Memory at dd1fe000 (32-bit, prefetchable) [size=4K]
         Capabilities: [44] Vital Product Data
         Capabilities: [4c] Power Management version 2
                 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
02:06.1 Multimedia controller: Brooktree Corporation Bt878 (rev 11)
         Subsystem: Hauppauge computer works Inc.: Unknown device 13eb
         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR+ FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
         Latency: 64 (1000ns min, 63750ns max)
         Interrupt: pin A routed to IRQ 5
         Region 0: Memory at dd1ff000 (32-bit, prefetchable) [size=4K]
         Capabilities: [44] Vital Product Data
         Capabilities: [4c] Power Management version 2
                 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-



-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

-
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/


-- 
   "Nothing succeeds like success." - Alexandre Dumas
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS Maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/

RE: Hang problem on Tyan K7 Thunder resolved -- SB Live! heads-up

[Ryan C. Bonham]

Ok, that true.. I could, and will if necessary.. But my point was, which I
didn't make that well,  wouldn't it make more sense to leave the new driver
in the AC builds, and test it there, especially if Alan doesn't like it in
Linus's 2.4.X tree.   Maybe not, I don't know.. 

> -----Original Message-----
> From: Daniel T. Chen [mailto:crimsun@email.unc.edu]
> Sent: Monday, August 13, 2001 2:58 PM
> To: Ryan C. Bonham
> Cc: Linus Torvalds; Alan Cox; linux-kernel@vger.kernel.org
> Subject: RE: Hang problem on Tyan K7 Thunder resolved -- SB Live!
> heads-up
> 
> 
> Or... you could use Alan's -ac patches with CVS checkouts from
> opensource.creative.com, the "best of all 2.4 with sblive
> worlds." ;) Coincidentally, this appeared earlier today:
> -- snip --
> Module name:    emu10k1
> Changes by:     rsousa  01/08/13 07:42:32
> 
> Modified files:
>         .              : audio.c 
> 
> Log message:
> Corrected tasklet cleanup.
> -- snip --
> 
> ---
> Dan Chen                 crimsun@email.unc.edu
> GPG key: www.cs.unc.edu/~chenda/pubkey.gpg.asc
> 
> On Mon, 13 Aug 2001, Ryan C. Bonham wrote:
> 
> > So my basic question is; Alan, can you leave the new sound 
> driver in your AC
> > kernels? Your kernels are great, and I would love to run 
> them with the new
> > driver, even if it means I have to find some problems... 
> 
>