lkml.org 
[lkml]   [2000]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectWeird combo: VIA vt82c586b+IBM djna-371800+Toshiba XM-5702b
Date
So here's the scoop:

I'm putting together this system for my sister to dual-boot Linux
(debian) and Windows 98. Originally, I had an IBM 1.7gig ata33 hard
drive in there, and everything worked fine. Then she decided she
wanted to have Windows on there and thus this required more hard drive
space (she's a student with growing needs) the hardware is as follows:

Soyo SY 5EMA+ Version 1.0 (updated the bios already to the latest found
on their website) motherboard
64 megs pc100 ram (1 stick)
18gig IBM DJNA-371800 ATA66 hard drive
Toshiba XM-5702b 12x ATAPI cdrom drive
AMD K6-2 450 cpu
Matrox Millenium PCI w/ 4megs video card

Kernel currently using:
2.4.0-test9 (final)
I have tried 2.2.17pre18 (or whatever's shipping with debian potato
these days)
and have also tried various patches (including the VIA 2.3 patch found
here on lkml) along with various other hdparm, etc hacks from lkml and
other places/suggestions.

So here's the problem:
the cpu's fine, the ram's fine, the hard drive performs like a porn
star (it's on the ata33 chain, i would prefer not to get a Promise
ata66 controller at this point in time and fix this bug instead.. yes,
i am stubborn), but the cdrom drive is wh0red: it gets detected just
fine upon bootup...
(using via82cxxx.c version 2.1d; 2.3 yields similar results):
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 39
VP_IDE: chipset revision 6
VP_IDE: VIA vt82c586b IDE UDMA33 controller on pci0:7.1
ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:pio
hda: IBM-DJNA-371800, ATA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
hdc: TOSHIBA CD-ROM XM-5702B, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 35195328 sectors (18020 MB) w/1966KiB Cache, CHS=2190/255/63,
UDMA(33)
hdc: ATAPI 12X CD-ROM drive, 256kB Cache, DMA
Uniform CD-ROM driver Revision: 3.11

But when I attempt to mount a cdrom or play a cd, or even close the
cdrom with eject -t, i get some errors:

# mount -t iso9660 /dev/hdc /cdrom
mount: block device /dev/hdc is write-protected, mounting read-only
mount: No medium found
# df | grep hdc
# cat /proc/mounts | grep hdc
# cat /proc/filesystems | grep iso9660
iso9660
# hdparm -I /dev/hdc

/dev/hdc:
hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdc: drive_cmd: error=0x04

/* Now right away, you're all sitting here going:
"CONFIG_IDEDISK_MULTI_MODE=y YOU MORON!!!" but i've already done that.
*/

Model=OTHSBI ADCR-MOX -M7520 B , FwRev=3072 ,
SerialNo=1900164787
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=256kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=yes, tPIO={min:180,w/IORDY:180}, tDMA={min:150,rec:150}
PIO modes: pio0 pio1 pio2 pio3
DMA modes: *sdma0 sdma1 sdma2 mdma0 mdma1
#

As you can see, the hard drive is the master on the primary ide
channel, and the cdrom drive is the master on the secondary ide
channel. I originally had the cdrom set as the slave on the primary
channel, but thought that putting it on a separate chain would
alleviate the problem. How wrong I was. :/ I have tried a few other
tests to track down the problem:
a) Took the Toshiba cdrom out, put the Lite-On 48x ATAPI cdrom from my
main workstation in there... works like a charm, but i'm not willing to
trade my 48x for her 12x... you know how it is ;)
b) Placed the Toshiba cdrom into my workstation, works just fine.
c) Tried different IDE cables. nada.
d) Set different PIO modes in the bios. nada.
e) Set the jumpers on the IBM hard drive to various settings, with
much-less-than-favourable results. (i.e.: 400 megs of space detected by
bios and kernel, etc)
f) Tried to install windows 98:
<begin pure evil>
MSCDEX Version 2.25
Copyright (C) Microsoft Corp. 1986-1995. All rights reserved.
Drive E: = Driver OEMCD001 unit 0

A:\>e:

E:\>dir

CDR101: Not ready reading drive E
Abort, Retry, Fail?r

CDR101: Not ready reading drive E
Abort, Retry, Fail?f

So there it is... I've essentially knocked this problem down to one of
two things (possibly both):
1) VIA made a buggy chipset
2) Toshiba engineers were smoking crack when they developed this 'Mode
Select 2' jumper set on the back of the cdrom drive.. 'Mode Select 1'
is for master/slave/cableselect, and I have no idea wtf the second mode
selection is for.. this has been driving me buggy for weeks now, and
I'm at the end of my wits here.. perhaps I should just stick the cdrom
in another system and get a different cdrom for my sister's puter, or
obtain an ata66 controller... obviously a new controller would yield
better results for the hard drive.. I've tried different jumper
settings on the cdrom drive with more disasterous results.. toshiba
yields NO documentation for this, search engines are clueless, and no
one seems to know a damn thing about this 'mode select 2' thing.. I'm
at the end of my wits here, LKML is my last refuge before I take
anymore action... If anyone has ANY advice short of the self-prescribed
solutions I've set in front of myself, please slap me upside the head
with them and call me charly. This is certainly a most rare case that
I would like to see avoided in the future. Like I said, if you require
further information, I will not hesitate to provide it. TIA

-Scott

--
.oO gnea at rochester dot rr dot com Oo.
.oO url: http://garson.org/~gnea Oo.

"You can tune a filesystem, but you can't tuna fish" -unknown

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.104 / U:0.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site