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):
Steps to Reproduce:
1. Play a track
2. Run scanimage -L
Actual Results: Playback loops briefly
Expected Results: Playback should be unaffected by scanimage
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
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
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
That makes both of us happy 8)