Bug 25157 - System freeze after enabling ES1370 sound
Summary: System freeze after enabling ES1370 sound
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact: Brock Organ
Whiteboard: Florence Gold
Depends On:
TreeView+ depends on / blocked
Reported: 2001-01-28 22:09 UTC by Gene Czarcinski
Modified: 2005-10-31 22:00 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-01-30 00:06:19 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Gene Czarcinski 2001-01-28 22:09:47 UTC
I have an Ensoniq ES1370 adapter.  On my 7.0 system running kernel
2.4.0-0.37 (from early rawhide), sound works fine.  I installed beta3
(fisher).  After bootup, I used sndconfig to enble sound.  I then logged in
and enabled sound.  Although it worked (sort of) the quality was crappy and
moving the mouse was a problem.

I rebooted and logged in again.  This time (when it seemed that sound would
start) the system froze -- it took a hard reset to reboot.  I reinstalled
and tried again.  This time, when sound should have started, the system
powered off!

Comment 1 Jeremy Katz 2001-01-29 00:53:22 UTC
What were you playing sound with?  A bug came across lkml yesterday/today about
using xmms under 2.4.1-pre10 (which is included in ac11 which is what
2.4.0-0.99.11 is based on) due to running out of shm and locking up the machine.

Comment 2 Gene Czarcinski 2001-01-29 22:32:59 UTC
I was running standard KDE with sound enabled.  It also happened with gnome.

However, I found the following on the kernel list.  I have not tried the
suggested circumvension but this sounds like what happened to me.

Subject: Re: es1371 freezes 2.4.0 hard
Date: Sat, 27 Jan 2001 09:22:45 -0500
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: David Bustos <bustos@its.caltech.edu>

David Bustos wrote:
> Quoth Jeff Garzik on Thu, Jan 25, 2001 at 10:24:13AM -0500:
> > What happens if you remove the call to pci_enable_device() in the source
> > code, drivers/sound/es1371.c?
> That seems to do it.

Ok.  For a temporary fix, there ya go.

But removing pci_enable_device is incorrect; it merely avoids what
appears to be a bug with your Via irq routing.  Would it be possible for
you to edit linux/arch/i386/kernel/pci-i386.h, and change the line near
the top from
	#undef DEBUG
	#define DEBUG 1
and then send the output of 'dmesg -s 16384' to linux-kernel (and CC
me)?  That will dump your PCI IRQ routing information, among other

Step two, "modprobe es1371" with pci_enable_device -in- the code, and
with debugging enabled as described above.  IIRC it should print out a
few more lines of debugging information that will be helpful.  Since we
are dealing with a hard lock, these last few lines of debugging info
might have to be copied via a serial console, or by hand.

One last question... is this an SMP machine?  If so, let me know if
booting with "noapic" option on the command line fixes things.



Jeff Garzik       | "You see, in this world there's two kinds of
Building 1024     |  people, my friend: Those with loaded guns
MandrakeSoft      |  and those who dig. You dig."  --Blondie

Comment 3 Glen Foster 2001-01-30 00:06:15 UTC
This defect is considered MUST-FIX for Florence Gold release

Comment 4 Gene Czarcinski 2001-02-09 16:25:14 UTC
I installed the 2.4.0-0.99.23 smp kernel from rawhide 20010207.  This appears to
have fixed the problem since the system no longed freezes.

Therefore, I am marking this closed

Note You need to log in before you can comment on or make changes to this bug.