public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox