Red Hat Bugzilla – Bug 60470
(SCSI DC395)playback loops like a stuck record when checking for SCSI scanners
Last modified: 2007-04-18 12:40:40 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221 Description of problem: Bizarre one, this. If you check for scanners with "scanimage -L" when xmms is playing a track, it'll repeat a short loop like a stuck record while scanimage checks for SCSI devices. Oddly enough, all scanimage is doing at this point is parsing /proc/scsi/scsi. If it was actually scanning the SCSI bus, then I might have expected a dropout or something, but not a loop like this. The only thing I can think of is that xmms is reading into a ring buffer which is not being populated quickly enough to keep up with playback (although I haven't checked the source, so I could be wildly off base here). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Play a track 2. Run scanimage -L Actual Results: Playback loops briefly Expected Results: Playback should be unaffected by scanimage Additional info: This is a problem when playing both oggs and mp3s. It also only occurs when there's a valid scanner detected. If no devices are found, playback in unaffected
What sound driver?
xmms output plugin: OSS Driver 1.2.5 kernel driver: es1371 lspci gives: 00:12.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 08) Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort+ <MAbort+ >SERR- <PERR- Latency: 64 (3000ns min, 32000ns max) Interrupt: pin A routed to IRQ 12 Region 0: I/O ports at da00 [size=64] Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME-
It is indeed a ring buffer, and some of the old isa scsi cards burn enough cpu to cause this
Is it *only* ISA cards that do that? I'm using a PCI card (a Tekram DC395x). Admittedly, it's getting on a bit now, but still... More to the point, since it's only parsing /proc/scsi/scsi, which should already be in memory, why should the card itself have any bearing on it?
Thats very strange then. This happens typically with the cheap 8bit controllers that come with scanners. The /proc code does talk to the controller and use CPU, but on the 395 this should not be a factor at all
Of course, it's now working perfectly for me. D'oh! I see that when I originally logged the bug, I was running RH7.2. I'm running RH8 now, and can't reproduce the problem. I'm guessing that something changed in either the kernel or xmms between versions that fixed this...
That makes both of us happy 8)