Hi, I've mounted a second internal ATA hard drive (IBM DTLA-307030) in my B&W G3. After installing Linux (SuSE 7.0) onto this drive, I always get these strange kernel messages: kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC } I've never had these messages with the build in hard drive (IBM DTTA-350640). First I thought I configured the drives wrong. So I tried several configurations: 1 Master: DTTA-350640 blue connector of a 24" UltraATA cable Slave: DTLA-307030 gray connector of a 24" UltraATA cable 2 Master: DTTA-350640 black connector of a 24" UltraATA cable Slave: DTLA-307030 grey connector of a 24" UltraATA cable 3 Master: DTLA-307030 black connector of a 24" UltraATA cable Slave: DTTA-350640 gray connector of a 24" UltraATA cable 4 Then I changed UDMA Mode of the DTLA-307030 5 to 2 Now I don't know what else I can change to stop the messages. What is the meaning of them? Is this a serious error or sth. I shouldn't worry about? Thanks, Micha
On Sun, May 06, Michael Engel wrote:
Hi, I've mounted a second internal ATA hard drive (IBM DTLA-307030) in my B&W G3. After installing Linux (SuSE 7.0) onto this drive, I always get these strange kernel messages:
kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
I've never had these messages with the build in hard drive (IBM DTTA-350640). First I thought I configured the drives wrong. So I tried several configurations:
1 Master: DTTA-350640 blue connector of a 24" UltraATA cable Slave: DTLA-307030 gray connector of a 24" UltraATA cable
2 Master: DTTA-350640 black connector of a 24" UltraATA cable Slave: DTLA-307030 grey connector of a 24" UltraATA cable
3 Master: DTLA-307030 black connector of a 24" UltraATA cable Slave: DTTA-350640 gray connector of a 24" UltraATA cable
4 Then I changed UDMA Mode of the DTLA-307030 5 to 2
Now I don't know what else I can change to stop the messages. What is the meaning of them? Is this a serious error or sth. I shouldn't worry about?
What kernel do you use? I recommend the 2.4.2 kernel, the used CMD646 controller is broken and works only with 2.2.16 and 2.4.2. Gruss Olaf -- $ man clone BUGS Main feature not yet implemented...
Am Mit, 09 Mai 2001 schrieb Olaf Hering:
What kernel do you use? I recommend the 2.4.2 kernel, the used CMD646 controller is broken and works only with 2.2.16 and 2.4.2.
Gruss Olaf
Until now I tried 2.2.16, 2.2.18 and 2.4.2! I got a hint from Jochen Hoffmann. He told me they had similar problems with two IBM DTLA-305040 (same family as mine) on AMD K7 computers running SuSE 6.4. Kernel update from 2.2.18 to 2.2.19 solved his problem and as a work around he turned off dma support. So I installed 2.2.18 and 2.4.2 but the error messages still occurred. Then I turned off UDMA of the DTLA-307030 and for the first time these kernel messages disappeared (with kernel 2.2.16 or 2.4.2). It must be a data transfer problem. After shortening the UltraATA cable from 24" to 12" I turned on again UDMA Mode 2. It works well since five hours. I only get a nfsserver failure during bootup with kernel 2.4.2: Starting kernel based NFS serverlockdsvc: Invalid argument .....failed and a few new kernel messages: May 9 19:46:46 MacHu8 inetd[395]: swat/tcp (2): bind: Address already in use May 9 19:47:37 MacHu8 /usr/sbin/gpm[637]: Error in protocol I'm not sure why this cable shortening works. Why should a longer cable support one UDMA/33 drive and another on the same cable won't work? And what about my CMD646? In which way is it broken? Regards, Micha
On Wed, May 09, Michael Engel wrote:
It must be a data transfer problem. After shortening the UltraATA cable from 24" to 12" I turned on again UDMA Mode 2. It works well since five hours. I only get a nfsserver failure during bootup with kernel 2.4.2:
Starting kernel based NFS serverlockdsvc: Invalid argument .....failed
Its a bug in the startup script, redirect the stderr in rcnfsserver: checkproc -n lockd || \ /usr/sbin/rpc.lockd 2>/dev/null
and a few new kernel messages:
May 9 19:46:46 MacHu8 inetd[395]: swat/tcp (2): bind: Address already in use May 9 19:47:37 MacHu8 /usr/sbin/gpm[637]: Error in protocol
I have these messages from time to time, but the mouse still works. I will try to track it down.
I'm not sure why this cable shortening works. Why should a longer cable support one UDMA/33 drive and another on the same cable won't work? And what about my CMD646? In which way is it broken?
This statement was not clear enough. The cmd646 controller is hard to support and didnt work very well with 2.2.r 2.2.18 doesnt work at all here, 2.4 seems to work fine. I have no idea about the cable lenght, sorry. But if it solves your problem... Gruss Olaf -- $ man clone BUGS Main feature not yet implemented...
participants (2)
-
Michael Engel -
Olaf Hering