Re: [PATCH, IDE] Blacklist CD-912E/ATK

From: kl
Date: Wed Nov 23 2005 - 06:16:57 EST

On Tue, Nov 22, 2005 at 08:26:19 +0000, Alan Cox wrote:

> > The drive is clearly broken. Adding blacklist to drivers/ide/ide-dma.c
> > for this model ("CD-912E/ATK") fixes this problem.

> That may be the case but knowing if th drive is the problem is more
> tricky.

By saying that drive is broken I meant "it never worked with DMA", at
least for me. Sorry for not being clear.

I have more to add -- IMHO blacklisting the drive doesn't fix the
problem, but just works around it. As I written in my original bug
report[1] I thought panic shouldn't happen anyway. I also noted that
kernels 2.4.* handle this situation gracefully, and pointed out that
the time between panic (in 2.6), and graceful recovery (in 2.4)
differs between kernels.


> Firstly try it on a different controller

I tested it on two controllers:
0000:00:07.1 IDE interface: Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II]
0000:00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)

Kernel panics as before on both of them.

> Secondly check for other firmware revisions
> Thirdly blacklist only your firmware rev if there are others

Here goes output of "hdparm -i" for said drive.

Model=CD-912E/ATK, FwRev=17A, SerialNo=
Config={ SpinMotCtl Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=DualPortCache, BuffSize=128kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=yes, tPIO={min:209,w/IORDY:180}, tDMA={min:150,rec:150}
PIO modes: pio0 pio1 pio2 pio3
DMA modes: sdma0 sdma1 sdma2 mdma0 *mdma1

As things are more clear now, I think there is no reason to search for
newer firmware for this drive? (This is Generic-IDE bug, right?)

> > hdc: DMA disabled
> > ------------[ cut here ]------------
> > kernel BUG at drivers/ide/ide-iops.c:949!
> > invalid operand: 0000 [#1]

> That is an IDE layer bug not a drive incompatibility. It may be one
> triggered the other but until the BUG the kernel was correctly behaving
> and had just turned off DMA anyway.

This is what I thought in the first place, and this is what I
suggested in my original bug report. Debian kernel mainainer shortened
the report somewhat, probably because it was too long and too boring.
Additionaly I incorrectly stated that blacklisting _fixes_ the
problem, which was even not what I personally thought. ;)

Sorry for that.

This signature intentionally says nothing.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at