All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Stark <gsstark@mit.edu>
To: Greg Stark <gsstark@MIT.EDU>
Cc: Greg Stark <gsstark@mit.edu>, Andrew Morton <akpm@osdl.org>,
	s0348365@sms.ed.ac.uk, linux-kernel@vger.kernel.org,
	pmcfarland@downeast.net
Subject: Re: OSS Audio borked between 2.6.6 and 2.6.10
Date: 14 Mar 2005 03:59:06 -0500	[thread overview]
Message-ID: <87u0nevc11.fsf@stark.xeocode.com> (raw)
In-Reply-To: <87zmx66b2b.fsf@stark.xeocode.com>


> Greg Stark <gsstark@MIT.EDU> writes:
> 
> > Andrew Morton <akpm@osdl.org> writes:
> > 
> > > Are you able to narrow it down to something more fine grained than "between
> > > 2.6.6 and 2.6.9-rc1"?
> > 
> > Er, I suppose I would have to build some more kernels. Ugh. Is there a good
> > place to start or do I have to just do a binary search?

Well, I built a slew of kernels but found it on the first reboot.

2.6.7 doesn't work.

I compiled the 2.6.6 drivers for 2.6.10 but they give ENODEV when I load them.




> 
> 2.6.7:
> 
> <jdgaston@snoqualmie.dp.intel.com>
> 	[PATCH] I2C: ICH6/6300ESB i2c support
> 	
> 	This patch adds DID support for ICH6 and 6300ESB to i2c-i801.c(SMBus).
> 	In order to add this support I needed to patch pci_ids.h with the SMBus
> 	DID's.  To keep things orginized I renumbered the ICH6 and ESB entries
> 	in pci_ids.h.  I then patched the piix IDE and i810 audio drivers to
> 	reflect the updated #define's.  I also removed an error from irq.c;
> 	there was a reference to a 6300ESB DID that does not exist.
> 
> <jgarzik@redhat.com>
> 	[sound/oss i810] pci id cleanups
> 	
> 	The driver defined its own PCI id constants.  Kill the majority,
> 	which were redundant, and move the rest to include/linux/pci_ids.h.
> 	
> 	Also, move open-coded tests for "new ICH" audio chips to a single
> 	helper function.  These tests were being patched with each new
> 	ICH motherboard from Intel, resulting in each new PCI id being added
> 	to several places in the driver.
> 	
> 	Note that, even though this should be a harmless patch, there
> 	exists the remote possibility that I mis-matched some of the
> 	PCI ids, as I only tested ICH5.
> 
> <herbert@gondor.apana.org.au>
> 	[sound/oss i810] fix wait queue race in drain_dac
> 	
> 	This particular one fixes a textbook race condition in drain_dac
> 	that causes it to timeout when it shouldn't.
> <herbert@gondor.apana.org.au>
> 	[sound/oss i810] fix race
> 	
> 	This patch fixes the value of swptr in case of an underrun/overrun.
> 	
> 	Overruns/underruns probably won't occur at all when the driver is
> 	fixed properly, but this doesn't hurt.
> 
> <herbert@gondor.apana.org.au>
> 	[sound/oss] remove bogus CIV_TO_LVI
> 	
> 	This patch removes a pair of bogus LVI assignments.  The explanation in
> 	the comment is wrong because the value of PCIB tells the hardware that
> 	the DMA buffer can be processed even if LVI == CIV.
> 	
> 	Setting LVI to CIV + 1 causes overruns when with short writes
> 	(something that vmware is very fond of).
> 
> <herbert@gondor.apana.org.au>
> 	[sound/oss i810] clean up with macros
> 	
> 	This patch adds a number macros to clean up the code.
> 
> <herbert@gondor.apana.org.au>
> 	[sound/oss i810] fix partial DMA transfers
> 	
> 	This patch fixes a longstanding bug in this driver where partial fragments
> 	are fed to the hardware.  Worse yet, those fragments are then extended
> 	while the hardware is doing DMA transfers causing all sorts of problems.
> 
> <herbert@gondor.apana.org.au>
> 	[sound/oss i810] fix playback SETTRIGGER
> 	
> 	This patch fixes SETTRIGGER with playback so that the LVI is always
> 	set and the DAC is always started.
> 
> <herbert@gondor.apana.org.au>
> 	[sound/oss i810] fix OSS fragments
> 	
> 	This patch makes userfragsize do what it's meant to do: do not start
> 	DAC/ADC until a full fragment is available.
> 
> <herbert@gondor.apana.org.au>
> 	[sound/oss i810] remove divides on playback
> 	
> 	This patch removes a couple of divides on the playback path.
> 
> <herbert@gondor.apana.org.au>
> 	[sound/oss i810] fix drain_dac loop when signals_allowed==0
> 	
> 	This patch fixes another bug in the drain_dac wait loop when it is
> 	called with signals_allowed == 0.
> 
> <herbert@gondor.apana.org.au>
> 	[sound/oss i810] fix reads/writes % 4 != 0
> 	
> 	This patch removes another bogus chunk of code that breaks when
> 	the application does a partial write.
> 	
> 	In particular, a read/write of x bytes where x % 4 != 0 will loop forever.
> 
> <herbert@gondor.apana.org.au>
> 	[sound/oss i810] fix deadlock in drain_dac
> 	
> 	This patch fixes a typo in a previous change that causes the driver
> 	to deadlock under SMP.

-- 
greg


  parent reply	other threads:[~2005-03-14  8:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-12 18:31 OSS Audio borked between 2.6.6 and 2.6.10 Greg Stark
2005-03-13  6:52 ` Patrick McFarland
2005-03-13 22:26   ` Greg Stark
2005-03-14  0:48     ` Martin Schlemmer
2005-03-14  1:03     ` Alistair John Strachan
2005-03-14  3:50       ` Greg Stark
2005-03-14  4:07         ` Andrew Morton
2005-03-14  4:42           ` Greg Stark
2005-03-14  4:55             ` Andrew Morton
2005-03-14  5:39             ` Greg Stark
2005-03-14  5:57               ` Andrew Morton
2005-03-14  6:21                 ` Greg Stark
2005-03-14  6:48                   ` Andrew Morton
2005-03-14  8:59               ` Greg Stark [this message]
2005-03-14  9:53                 ` Andrew Morton
2005-03-14 15:40                   ` Greg Stark
2005-03-14 15:52                     ` John W. Linville
2005-03-22  0:38                     ` Andrew Morton
2005-03-22  4:16                       ` Greg Stark
2005-03-14 15:33                 ` John W. Linville

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87u0nevc11.fsf@stark.xeocode.com \
    --to=gsstark@mit.edu \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmcfarland@downeast.net \
    --cc=s0348365@sms.ed.ac.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.