Bug 60470
Summary: | (SCSI DC395)playback loops like a stuck record when checking for SCSI scanners | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Tethys <sta040> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED WORKSFORME | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | CC: | alan, notting |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-06-09 07:27:06 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tethys
2002-02-28 00:25:09 UTC
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) |