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?

Oof. I just skimmed the Changelogs. It looks like the i810 OSS drivers got
quite a rototilling in 2.6.7 and 2.6.8. It also kind of sounds like they
needed it though.

>From the look of this I doubt the 2.6.6 drivers will build or load into
2.6.10.




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.



2.6.8:


<[EMAIL PROTECTED]>
        [sound/oss i810] add MMIO DSP support
        
        Enclosed is a patch for the i810_audio OSS driver to support using
        memory-mapped I/O for those chipsets that support it.
        
         o Added a family of macros -- I810_IOREADx() and I810_IOWRITEx() -- 
that
        key off the existing card->use_mmio flag to select between using 
readx/writex
        or inx/outx for I/O operations.
        
         o Converted existing inx/outx invocations to use
        I810_IOREADx/I810_IOWRITEx instead.
        
         o Changed GET_CIV(), GET_LVI, and CIV_TO_LVI() not only to use
        I810_IOREADx/I810_IOWRITEx but also to take "card" (i.e. struct 
i810_card)
        paramter.
        
         o Removed check for "Pure MMIO interfaces" in i810_probe() -- replaced 
w/
        (relocated) check for no I/O resources available.

<[EMAIL PROTECTED]>
        [sound/oss i810] misc small changes
        
        Attached is a second patch to account for (most of) Herbert Xu's
        comments.
        
        I have left-out the part about changing state->card to a
        local variable where it is used a lot.  Unfortunately, that usage is
        somewhat pervasive and I would prefer to make those changes in a 
separate
        patch -- after I have had a chance to do some testing.
        
        If you'd prefer one patch to account for the original plus these
        changes, let me know and I'll be happy to provide it.






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

Reply via email to