Hello,
I'm currently having troubles while trying to listen or rip cds audios.
`cdparanoia -Q` works fine
but `strace cdparanoia 1` hangs at :
ioctl(3, 0x530e
Then I have from `dmesg` :
hdc: lost interrupt
hdc: lost interrupt
(...)
hdc: lost interrupt
hdc: lost interrupt
The only thing I found in archives is :
" It seems like the 'lost interrupt' while
ripping audio CDs is specific to VIA based motherboards."
In fact, I have a VIA based motherboard :
VIA KT333 and VIA 8233A
I'm using Linux version 2.4.21 (gcc version 3.2.2) #2 Thu Jul 3 12:42:17
CEST 2003
Some infos from /proc/ide/ide1/hdc :
driver: ide-cdrom version 4.59-ac1
model: CRD-8322B
settings :
name value min max mode
---- ----- --- --- ----
breada_readahead 4 0 127 rw
current_speed 34 0 70 rw
dsc_overlap 0 0 1 rw
file_readahead 0 0 2097151 rw
init_speed 12 0 70 rw
io_32bit 1 0 3 rw
keepsettings 0 0 1 rw
max_kb_per_request 64 1 127 rw
nice1 1 0 1 rw
number 2 0 3 rw
pio_mode write-only 0 255 w
slow 0 0 1 rw
unmaskirq 1 0 1 rw
using_dma 1 0 1 rw
I tried setting using_dma 0, unmaskirq 0.
Otherwise, my cdrom works perfectly for data cds.
Please help me
--
C?dric Barboiron
C?dric Barboiron wrote:
> Hello,
>
> I'm currently having troubles while trying to listen or rip cds
> audios. `cdparanoia -Q` works fine but `strace cdparanoia 1` hangs
> at : ioctl(3, 0x530e
>
> Then I have from `dmesg` : hdc: lost interrupt hdc: lost interrupt (...)
>
> hdc: lost interrupt hdc: lost interrupt
>
> The only thing I found in archives is : " It seems like the 'lost
> interrupt' while ripping audio CDs is specific to VIA based
> motherboards."
>
> In fact, I have a VIA based motherboard : VIA KT333 and VIA 8233A
What kind of hard drive is it, with which kind of cable (40-line or
80-line), and what transfer mode is it running in?
These "lost interrupt" problems date back to UDMA-33. There were tons
of them early on, with several OSes, and if I'm not mistaken the
association seemed to be more with case cooling issues and ribbon
cables, rather than any particular chipset.
That *seemed* to be true in my case (and in my case), but I don't have
absolute knowledge of that because the problem was rare and impossible
to reproduce on demand. I had a VIA chipset, 82C586B, but there were
clear issues with case cooling, and the problem *seemed* to go away when
those issues were addressed. That *seemed* to be true for the other
cases (and cases) I read about, as well.
Maybe people with VIA chipsets tend to be reckless with their case
setups....
-- Jim Howard <[email protected]>
C?dric Barboiron wrote:
> Hello,
>
> I'm currently having troubles while trying to listen or rip cds audios.
> `cdparanoia -Q` works fine
> but `strace cdparanoia 1` hangs at :
> ioctl(3, 0x530e
>
> Then I have from `dmesg` :
> hdc: lost interrupt
> hdc: lost interrupt
> (...)
> hdc: lost interrupt
> hdc: lost interrupt
[ ... ]
> Some infos from /proc/ide/ide1/hdc :
> driver: ide-cdrom version 4.59-ac1
> model: CRD-8322B
Sorry, my brain must have been overheating, I missed this in my other
reply to your post, when I asked what drive.
Don't know if case cooling would have any bearing on this or not, but I
think I'll run some tests of my own. I seem to recall one incident
while I was unrolling a tarball off a CD onto a hard drive, that
happened to involve a VIA chipset. I'll see if I can reproduce the
incident.
-- Jim Howard <[email protected]>
[email protected] wrote:
> I seem to recall one incident while I was unrolling a tarball off a
> CD onto a hard drive, that happened to involve a VIA chipset.
I don't have a record of it, but as I remember, when that happened I had
APIC enabled in the BIOS. After that, I switched to PIC.
In this machine's BIOS Setup BIOS FEATURES SETUP screen, there's the line:
Interrupt Mode : PIC
The other option is APIC. Make sure it says PIC.
I think it was Alan Cox who pointed out that on single-processor systems
you need to have PIC, and not APIC enabled. And my kernel wasn't even
built with APIC support ("# CONFIG_X86_UP_APIC is not set").
APIC is a newer interrupt controller type, PIC is the orginal 8259A
type. These chipsets can emulate either type in hardware.
I don't know if that's your problem, but you might check.
-- Jim Howard <jiho@c-zone>
[email protected] wrote:
> I don't have a record of it, but as I remember, when that happened I had
> APIC enabled in the BIOS. After that, I switched to PIC.
>
> In this machine's BIOS Setup BIOS FEATURES SETUP screen, there's the line:
>
> Interrupt Mode : PIC
I'll try that tomorrow, but I don't remember I saw such an option in my
BIOS Setup.
Thanks for taking interest in my problem.
--
C?dric Barboiron
[email protected] wrote:
> In this machine's BIOS Setup BIOS FEATURES SETUP screen, there's the line:
>
> Interrupt Mode : PIC
>
> The other option is APIC. Make sure it says PIC.
I had the choice to enable or disable APIC.
I disabled it, and still get lost interrupts.
> These "lost interrupt" problems date back to UDMA-33.
I probably have _very_ old IDE cables.
--
C?dric BARBOIRON