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
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 || [email protected]
"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
Patrick McFarland <[email protected]> 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
On Sun, 2005-03-13 at 17:26 -0500, Greg Stark wrote:
> Patrick McFarland <[email protected]> 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
On Sunday 13 March 2005 22:26, you wrote:
> Patrick McFarland <[email protected]> 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.
Alistair John Strachan <[email protected]> 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
Greg Stark <[email protected]> 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"?
Andrew Morton <[email protected]> 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
Greg Stark <[email protected]> wrote:
>
> Andrew Morton <[email protected]> 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.
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
Greg Stark <[email protected]> wrote:
>
> 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.
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
_
Andrew Morton <[email protected]> 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
Greg Stark <[email protected]> wrote:
>
> Andrew Morton <[email protected]> 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.
> 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
Greg Stark <[email protected]> wrote:
>
> > 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.
>
Herbert tells me that this might be fixed in 2.6.11. Did you try that?
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
[email protected]
Andrew Morton <[email protected]> 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
On Mon, Mar 14, 2005 at 10:40:27AM -0500, Greg Stark wrote:
> Andrew Morton <[email protected]> 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
[email protected]
Greg Stark <[email protected]> wrote:
>
> Andrew Morton <[email protected]> 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?
Andrew Morton <[email protected]> writes:
> Greg Stark <[email protected]> wrote:
> >
> > Andrew Morton <[email protected]> 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