> Greg Stark <[EMAIL PROTECTED]> writes: > > > Andrew Morton <[EMAIL PROTECTED]> 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: > > <[EMAIL PROTECTED]> > [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. > > <[EMAIL PROTECTED]> > [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. > > <[EMAIL PROTECTED]> > [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. > <[EMAIL PROTECTED]> > [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. > > <[EMAIL PROTECTED]> > [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). > > <[EMAIL PROTECTED]> > [sound/oss i810] clean up with macros > > This patch adds a number macros to clean up the code. > > <[EMAIL PROTECTED]> > [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. > > <[EMAIL PROTECTED]> > [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. > > <[EMAIL PROTECTED]> > [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. > > <[EMAIL PROTECTED]> > [sound/oss i810] remove divides on playback > > This patch removes a couple of divides on the playback path. > > <[EMAIL PROTECTED]> > [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. > > <[EMAIL PROTECTED]> > [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. > > <[EMAIL PROTECTED]> > [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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
