OSS Audio borked between 2.6.6 and 2.6.10

OSS Audio borked between 2.6.6 and 2.6.10

[Greg Stark]

OSS Audio doesn't work properly for Quake3 in 2.6.10 but it worked in 2.6.6.
In fact I have the same problems in 2.6.9-rc1 so I assume 2.6.9 is affected as
well. This is with the Intel i810 drivers. 

Quake3 just prints "dropping sound" over and over again and doesn't output any
sound in the actual game (the menus seem to work 50% of the time). I assume
this is related to Quake3's use of the memory mapped audio interface. Perhaps
it's never getting interrupts through the ioctl interface?

Here is the lspci info:

0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02)
	Subsystem: Asustek Computer, Inc. P4P800 Mainboard
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin B routed to IRQ 17
	Region 0: I/O ports at e800 [size=256]
	Region 1: I/O ports at ee80 [size=64]
	Region 2: Memory at f7fff400 (32-bit, non-prefetchable) [size=512]
	Region 3: Memory at f7fff000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

I tried it with pci=routeirq but no change.

The strace from quake running on the two kernels looks essentially identical.
Here are all the syscalls that look relevant from the 2.6.10. The output is
essentially identical for 2.6.6 except for the memory addresses, pid, and the
number of omitted read calls where the ellipses are. Note, that it *does*
print "sound system is muted" in 2.6.6 as well, but it works fine.


ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbffff718) = -1 ENOTTY (Inappropriate ioctl for device)
[pid  8904] write(2, "\n------- sound initialization --"..., 38
------- sound initialization -------
[pid  8904] open("/dev/dsp", O_RDWR)    = 19
[pid  8904] ioctl(19, SNDCTL_DSP_GETCAPS, 0xbffff774) = 0
[pid  8904] ioctl(19, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 0x81776ac) = 0
[pid  8904] ioctl(19, SNDCTL_DSP_STEREO, 0xbffff76c) = 0
[pid  8904] ioctl(19, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 0x88446b4) = 0
[pid  8904] ioctl(19, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, 0xbffff768) = 0
[pid  8904] ioctl(19, SNDCTL_DSP_GETOSPACE, 0xbffff780) = 0
[pid  8904] ioctl(19, SNDCTL_DSP_GETTRIGGER, 0xbffff76c) = 0
[pid  8904] ioctl(19, SNDCTL_DSP_GETTRIGGER, 0xbffff76c) = 0
[pid  8904] write(2, "sound system is muted\n", 22sound system is muted
[pid  8904] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
[pid  8904] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
[pid  8904] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
[pid  8904] ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig -icanon -echo ...}) = 0
[pid  8904] ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
[pid  8904] fcntl64(0, F_GETFL)         = 0x2 (flags O_RDWR)
[pid  8904] fcntl64(0, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] read(0, 0xbffef0cf, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] ioctl(19, SNDCTL_DSP_GETOPTR, 0xbffef264) = 0
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] read(0, 0xbffff5af, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] ioctl(19, SNDCTL_DSP_GETOPTR, 0xbffff744) = 0
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] read(0, 0xbffff5af, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] ioctl(19, SNDCTL_DSP_GETOPTR, 0xbffff744) = 0
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
...
[pid  8904] ioctl(19, SNDCTL_DSP_GETOPTR, 0xbffff744) = 0
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
...
[pid  8904] ioctl(19, SNDCTL_DSP_GETOPTR, 0xbffff744) = 0
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] read(0, 0xbfffb62f, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] read(0, 0xbfffdfcb, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] write(2, "dropping sound\n", 15dropping sound
[pid  8904] read(0, 0xbfffdfc3, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] write(2, "dropping sound\n", 15dropping sound
[pid  8904] read(0, 0xbfffdef3, 1)      = -1 EAGAIN (Resource temporarily unavailable)
[pid  8904] read(0, 0xbffff5af, 1)      = -1 EAGAIN (Resource temporarily unavailable)











The list of modules in 2.6.10

Module                  Size  Used by
vmnet                  30640  12 
parport_pc             37188  0 
parport                36552  1 parport_pc
vmmon                  48352  0 
binfmt_misc            12296  1 
ipv6                  243584  18 
8250                   24292  0 
serial_core            22784  1 8250
i2c_i801                8716  0 
hw_random               5908  0 
uhci_hcd               34188  0 
evdev                   9216  0 
ehci_hcd               44164  0 
usbcore               129656  3 uhci_hcd,ehci_hcd
snd_intel8x0           32032  0 
snd_ac97_codec         70752  1 snd_intel8x0
snd_pcm                95492  2 snd_intel8x0,snd_ac97_codec
snd_timer              25476  1 snd_pcm
snd_page_alloc         10116  2 snd_intel8x0,snd_pcm
bttv                  151760  0 
video_buf              22148  1 bttv
firmware_class         10240  1 bttv
i2c_algo_bit            9864  1 bttv
v4l2_common             6016  1 bttv
btcx_risc               5128  1 bttv
i2c_core               22784  3 i2c_i801,bttv,i2c_algo_bit
videodev               10112  1 bttv
md                     46032  0 
dm_mod                 58496  0 
gameport                4992  0 
snd_mpu401_uart         8192  0 
snd_rawmidi            24864  1 snd_mpu401_uart
snd_seq_device          8972  1 snd_rawmidi
snd                    54116  7 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device
mga                   118676  2 
intel_agp              21660  1 
agpgart                34092  2 intel_agp
sk98lin               162920  1 
i810_audio             37396  1 
ac97_codec             17804  1 i810_audio
rtc                    12872  0 

The list of modules in 2.6.6:

Module                  Size  Used by
vmnet                  31504  12 
parport_pc             28832  0 
parport                42312  1 parport_pc
vmmon                  49376  0 
binfmt_misc            11144  1 
ipv6                  254432  20 
8250                   23232  0 
serial_core            24320  1 8250
ehci_hcd               40836  0 
usbcore               116956  3 ehci_hcd
snd_intel8x0           28968  0 
snd_ac97_codec         64004  1 snd_intel8x0
snd_pcm                98976  1 snd_intel8x0
snd_timer              26628  1 snd_pcm
snd_page_alloc         11652  2 snd_intel8x0,snd_pcm
gameport                5248  1 snd_intel8x0
snd_mpu401_uart         8576  1 snd_intel8x0
snd_rawmidi            25248  1 snd_mpu401_uart
snd_seq_device          8456  1 snd_rawmidi
snd                    53860  7 snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_seq_device
bttv                  143468  0 
video_buf              21508  1 bttv
i2c_algo_bit            9992  1 bttv
v4l2_common             6528  1 bttv
btcx_risc               5128  1 bttv
i2c_core               23684  2 bttv,i2c_algo_bit
videodev                9984  1 bttv
md                     47560  0 
dm_mod                 43424  0 
mga                   104880  2 
intel_agp              17308  1 
agpgart                33964  2 intel_agp
sk98lin               167592  1 
i810_audio             30996  1 
ac97_codec             18828  1 i810_audio
rtc                    14152  0 



-- 
greg

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Patrick McFarland]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

On Saturday 12 March 2005 01:31 pm, Greg Stark wrote:
> OSS Audio doesn't work properly for Quake3 in 2.6.10 but it worked in
> 2.6.6. In fact I have the same problems in 2.6.9-rc1 so I assume 2.6.9 is
> affected as well. This is with the Intel i810 drivers.

Why are you not using ALSA?

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Greg Stark]

Patrick McFarland <pmcfarland@downeast.net> writes:

> On Saturday 12 March 2005 01:31 pm, Greg Stark wrote:
> > OSS Audio doesn't work properly for Quake3 in 2.6.10 but it worked in
> > 2.6.6. In fact I have the same problems in 2.6.9-rc1 so I assume 2.6.9 is
> > affected as well. This is with the Intel i810 drivers.
> 
> Why are you not using ALSA?

Well frankly because whenever I tried it it didn't work. The i810 drivers were
*completely* broken in the 2.6 kernel I original installed, 2.6.5 I think.

In any case I understood that Quake doesn't work with alsa drivers because it
depends on mmapped output which they don't support at all. Or something like
that. I gave up on them when I found OSS worked reliably.

Until someone broke it between 2.6.6 and 2.6.9. How likely are the 2.6.6
drivers to compile with 2.6.10? Is it worth trying?

-- 
greg

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 916 bytes --]

On Sun, 2005-03-13 at 17:26 -0500, Greg Stark wrote:
> Patrick McFarland <pmcfarland@downeast.net> writes:
> 
> > On Saturday 12 March 2005 01:31 pm, Greg Stark wrote:
> > > OSS Audio doesn't work properly for Quake3 in 2.6.10 but it worked in
> > > 2.6.6. In fact I have the same problems in 2.6.9-rc1 so I assume 2.6.9 is
> > > affected as well. This is with the Intel i810 drivers.
> > 
> > Why are you not using ALSA?
> 
> Well frankly because whenever I tried it it didn't work. The i810 drivers were
> *completely* broken in the 2.6 kernel I original installed, 2.6.5 I think.
> 
> In any case I understood that Quake doesn't work with alsa drivers because it
> depends on mmapped output which they don't support at all. Or something like
> that. I gave up on them when I found OSS worked reliably.
> 

Quake3 works fine here with alsa and the oss emulation ...


-- 
Martin Schlemmer


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Alistair John Strachan]

On Sunday 13 March 2005 22:26, you wrote:
> Patrick McFarland <pmcfarland@downeast.net> writes:
> > On Saturday 12 March 2005 01:31 pm, Greg Stark wrote:
> > > OSS Audio doesn't work properly for Quake3 in 2.6.10 but it worked in
> > > 2.6.6. In fact I have the same problems in 2.6.9-rc1 so I assume 2.6.9
> > > is affected as well. This is with the Intel i810 drivers.
> >
> > Why are you not using ALSA?
>
> Well frankly because whenever I tried it it didn't work. The i810 drivers
> were *completely* broken in the 2.6 kernel I original installed, 2.6.5 I
> think.
>
> In any case I understood that Quake doesn't work with alsa drivers because
> it depends on mmapped output which they don't support at all. Or something
> like that. I gave up on them when I found OSS worked reliably.

Quake3's doing something strange with the OSS devices. You can work around it 
in ALSA's OSS emulation by disabling the record features for the quake3.x86 
binary, and it should all work fine.

echo "quake3.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss
echo "quake3.x86 0 0 disable" > /proc/asound/card0/pcm0c/oss

(I gleamed the above from google.com, you might need to modify it slightly).

The intel8x0 driver is probably one of the most widely used ALSA drivers, so 
I'd hope it wasn't broken! My laptop uses the driver, it is superb.

-- 
Cheers,
Alistair.

personal:   alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:    CS/CSim Undergraduate
contact:    1F2 55 South Clerk Street,
            Edinburgh. EH8 9PP.

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Greg Stark]

Alistair John Strachan <s0348365@sms.ed.ac.uk> writes:

> The intel8x0 driver is probably one of the most widely used ALSA drivers, so 
> I'd hope it wasn't broken! 

I would have hoped so too at the time. Reporting it to the list didn't get any
response since it was already fixed upstream, but it took a while before it
was merged down to the linux tree.

Also, it seems chipsets can be wired up differently in different motherboards.
A driver can work perfectly for hundreds of boards and still fail on the same
chipset on another machine.

In any case "X code is broken" "why not use Y code instead" isn't really
productive. It's a good thing I was using the OSS drivers; if everyone used
the alsa drivers and nobody was testing the OSS drivers nobody would know they
were broken.

-- 
greg

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Andrew Morton]

Greg Stark <gsstark@mit.edu> wrote:
>
> In any case "X code is broken" "why not use Y code instead" isn't really
>  productive. It's a good thing I was using the OSS drivers; if everyone used
>  the alsa drivers and nobody was testing the OSS drivers nobody would know they
>  were broken.

I would agree with that.  If it's in the tree and the config system offers
it, it should work.  And if it _used_ to work, and no longer does so then
double bad.

Are you able to narrow it down to something more fine grained than "between
2.6.6 and 2.6.9-rc1"?

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Greg Stark]

Andrew Morton <akpm@osdl.org> writes:

> I would agree with that.  If it's in the tree and the config system offers
> it, it should work.  And if it _used_ to work, and no longer does so then
> double bad.

Er, yeah, it's not like this is a new card that some crufty old driver never
supported well. It worked fine in the past and got broke.

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

-- 
greg

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Andrew Morton]

Greg Stark <gsstark@mit.edu> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
> 
> > I would agree with that.  If it's in the tree and the config system offers
> > it, it should work.  And if it _used_ to work, and no longer does so then
> > double bad.
> 
> Er, yeah, it's not like this is a new card that some crufty old driver never
> supported well. It worked fine in the past and got broke.
> 
> > 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?
> 

I'd suggest the first step would be to take the driver(s) from a working
kernel, put them into a current tree and see if things start working again.

If that doesn't reveal anything then yes, it's down to binary searching.

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Greg Stark]

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?

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:

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



2.6.8:


<linville@redhat.com>
	[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.

<linville@redhat.com>
	[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

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Andrew Morton]

Greg Stark <gsstark@MIT.EDU> wrote:
>
>  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?
> 
>  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.

The 2.6.6 i810_audio.c compiles OK in current kernels with the below patch
applied.  

--- 25/sound/oss/i810_audio.c~a	2005-03-13 21:54:00.000000000 -0800
+++ 25-akpm/sound/oss/i810_audio.c	2005-03-13 21:56:29.000000000 -0800
@@ -1758,7 +1758,8 @@ static int i810_mmap(struct file *file, 
 	if (size > (PAGE_SIZE << dmabuf->buforder))
 		goto out;
 	ret = -EAGAIN;
-	if (remap_page_range(vma, vma->vm_start, virt_to_phys(dmabuf->rawbuf),
+	if (remap_pfn_range(vma, vma->vm_start,
+				virt_to_phys(dmabuf->rawbuf) >> PAGE_SHIFT,
 			     size, vma->vm_page_prot))
 		goto out;
 	dmabuf->mapped = 1;
@@ -3349,7 +3350,7 @@ static int i810_pm_suspend(struct pci_de
 			}
 		}
 	}
-	pci_save_state(dev,card->pm_save_state); /* XXX do we need this? */
+	pci_save_state(dev); /* XXX do we need this? */
 	pci_disable_device(dev); /* disable busmastering */
 	pci_set_power_state(dev,3); /* Zzz. */
 
@@ -3362,7 +3363,7 @@ static int i810_pm_resume(struct pci_dev
 	int num_ac97,i=0;
 	struct i810_card *card=pci_get_drvdata(dev);
 	pci_enable_device(dev);
-	pci_restore_state (dev,card->pm_save_state);
+	pci_restore_state (dev);
 
 	/* observation of a toshiba portege 3440ct suggests that the 
 	   hardware has to be more or less completely reinitialized from
_

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Greg Stark]

Andrew Morton <akpm@osdl.org> writes:

> The 2.6.6 i810_audio.c compiles OK in current kernels with the below patch
> applied.  

This would be a good time to learn the right way to do this: how do I build a
driver from a kernel tree without building the whole tree?

Like, if I copy the 2.6.6 drivers to a new directory outside a kernel tree, is
there some magic make command I can give it to point it at the 2.6.10 tree for
the build environment including make includes and header files?

-- 
greg

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Andrew Morton]

Greg Stark <gsstark@mit.edu> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
> 
> > The 2.6.6 i810_audio.c compiles OK in current kernels with the below patch
> > applied.  
> 
> This would be a good time to learn the right way to do this: how do I build a
> driver from a kernel tree without building the whole tree?

I don't think that's well supported for drivers which are already in-tree.

> Like, if I copy the 2.6.6 drivers to a new directory outside a kernel tree, is
> there some magic make command I can give it to point it at the 2.6.10 tree for
> the build environment including make includes and header files?

Suggest you simply copy the file into a 2.6.11 tree.

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Greg Stark]

> 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

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Andrew Morton]

Greg Stark <gsstark@MIT.EDU> wrote:
>
>  > 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.
> 

Herbert tells me that this might be fixed in 2.6.11.  Did you try that?

Re: OSS Audio borked between 2.6.6 and 2.6.10

[John W. Linville]

On Mon, Mar 14, 2005 at 03:59:06AM -0500, Greg Stark wrote:

> Well, I built a slew of kernels but found it on the first reboot.
> 
> 2.6.7 doesn't work.
 
> > 2.6.7:

> > 	[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).

Pretty sure this is/was the problem.  I found this to be causing
a problem with Wolfenstein: Enemy Territory.  The patch to reverse
this change appears to have been merged into 2.6.11.  I suggest you
try that one. :-)

Good luck!

John
-- 
John W. Linville
linville@tuxdriver.com

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Greg Stark]

Andrew Morton <akpm@osdl.org> writes:

> Herbert tells me that this might be fixed in 2.6.11.  Did you try that?

Nope. I'll try that. 


(Though I'm skeptical. It went from 2.6.6 to 2.6.10 without being noticed but
now it's fixed without any reports?)

-- 
greg

Re: OSS Audio borked between 2.6.6 and 2.6.10

[John W. Linville]

On Mon, Mar 14, 2005 at 10:40:27AM -0500, Greg Stark wrote:
> Andrew Morton <akpm@osdl.org> writes:
> 
> > Herbert tells me that this might be fixed in 2.6.11.  Did you try that?
> 
> Nope. I'll try that. 
> 
> 
> (Though I'm skeptical. It went from 2.6.6 to 2.6.10 without being noticed but
> now it's fixed without any reports?)

(Presuming that the Quake3 problem is the same as the Wolfenstein:
ET problem...)

It was reported as a problem with RHEL3.  When I discovered the fix,
I pushed it to the OSS drivers in 2.6.x as well.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Andrew Morton]

Greg Stark <gsstark@mit.edu> wrote:
>
> Andrew Morton <akpm@osdl.org> writes:
> 
> > Herbert tells me that this might be fixed in 2.6.11.  Did you try that?
> 
> Nope. I'll try that. 
> 

Did it work?

Re: OSS Audio borked between 2.6.6 and 2.6.10

[Greg Stark]

Andrew Morton <akpm@osdl.org> writes:

> Greg Stark <gsstark@mit.edu> wrote:
> >
> > Andrew Morton <akpm@osdl.org> writes:
> > 
> > > Herbert tells me that this might be fixed in 2.6.11.  Did you try that?
> > 
> > Nope. I'll try that. 
> 
> Did it work?

Oops, sorry I didn't get back. 
Yes. It works fine in 2.6.11.3
Thanks a lot for the help.

-- 
greg