Problems with IDE on GA-7VAXP motherboard

No, I hadn't noticed that. hmm. However I have both tried with and without ACPI and APCI or whatever it is (One does stuff like APM and the other one does the irq routing among other things IIRC.) People have told me to both turn it on and off. Anyway, later on today I'm going to try using a minimal kernel built with no options I absolutely don't need to have to boot this thing. Might work.

dmseg attached.

Timothy C. McGrath

Linux version 2.4.21 (misty@oorodina) (gcc version 3.3 (Debian)) #2 Wed Jun 18 14:36:40 MDT 2003 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
BIOS-e820: 000000001fff0000 - 000000001fff3000 (ACPI NVS)
BIOS-e820: 000000001fff3000 - 0000000020000000 (ACPI data)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
511MB LOWMEM available.
found SMP MP-table at 000f4c50
hm, page 000f4000 reserved twice.
hm, page 000f5000 reserved twice.
hm, page 000f0000 reserved twice.
hm, page 000f1000 reserved twice.
On node 0 totalpages: 131056
zone(0): 4096 pages.
zone(1): 126960 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 Pentium(tm) Pro APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 1
Kernel command line: BOOT_IMAGE=old ro root=302 ide0=nodma,ide1=nodma,ide2=nodma,ide3=nodma
ide_setup: ide0=nodma,ide1=nodma,ide2=nodma,ide3=nodma -- BAD OPTION
Initializing CPU#0
Detected 2086.519 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 4154.98 BogoMIPS
Memory: 516092k/524224k available (1281k kernel code, 7744k reserved, 319k data, 268k init, 0k highmem) Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
CPU: CLK_CTL MSR was 60031223. Reprogramming to 20031223
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.

CPU:     After generic, caps: 0383fbff c1c3fbff 00000000 00000000
CPU:             Common caps: 0383fbff c1c3fbff 00000000 00000000
CPU: AMD Athlon(tm) XP 2600+ stepping 01

Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000000
ESR value after enabling vector: 00000000
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-15, 2-18, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 15.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................

IO APIC #2......
.... register #00: 02000000

.......    : physical APIC id: 02
.......    : Delivery Type: 0
.......    : LTS          : 0
.... register #01: 00178003
.......     : max redirection entries: 0017
.......     : PRQ implemented: 1
.......     : IO APIC version: 0003
.... IRQ redirection table:
 NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:   
 00 000 00  1    0    0   0   0    0    0    00
 01 001 01  0    0    0   0   0    1    1    39
 02 001 01  0    0    0   0   0    1    1    31
 03 001 01  0    0    0   0   0    1    1    41
 04 001 01  0    0    0   0   0    1    1    49
 05 000 00  1    0    0   0   0    0    0    00
 06 001 01  0    0    0   0   0    1    1    51
 07 001 01  0    0    0   0   0    1    1    59
 08 001 01  0    0    0   0   0    1    1    61
 09 001 01  0    0    0   0   0    1    1    69
 0a 000 00  1    0    0   0   0    0    0    00
 0b 000 00  1    0    0   0   0    0    0    00
 0c 001 01  0    0    0   0   0    1    1    71
 0d 001 01  0    0    0   0   0    1    1    79
 0e 001 01  0    0    0   0   0    1    1    81
 0f 000 00  1    0    0   0   0    0    0    00
 10 001 01  1    1    0   1   0    1    1    89
 11 001 01  1    1    0   1   0    1    1    91
 12 000 00  1    0    0   0   0    0    0    00
 13 001 01  1    1    0   1   0    1    1    99
 14 000 00  1    0    0   0   0    0    0    00
 15 000 00  1    0    0   0   0    0    0    00
 16 000 00  1    0    0   0   0    0    0    00
 17 000 00  1    0    0   0   0    0    0    00

IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ16 -> 0:16
IRQ17 -> 0:17
IRQ19 -> 0:19
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 2086.5624 MHz.
..... host bus clock speed is 333.8500 MHz.
cpu: 0, clocks: 3338500, slice: 1669250
CPU0<T0:3338496,T1:1669232,D:14,S:1669250,C:3338500>
mtrr: v1.40 (20010327) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xf9ea0, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router default [1106/3189] at 00:00.0
PCI->APIC IRQ transform: (B0,I9,P0) -> 17
PCI->APIC IRQ transform: (B0,I11,P0) -> 19
PCI->APIC IRQ transform: (B0,I12,P0) -> 16
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Journalled Block Device driver loaded
tbxface-0099 [01] Acpi_load_tables : ACPI Tables successfully loaded
Parsing Methods:............................................................................................................................................... 143 Control Methods found and parsed (501 nodes total)
ACPI Namespace successfully loaded at root c02e9540
ACPI: Core Subsystem version [20011018]
evxfevnt-0081 [-23] Acpi_enable : Transition to ACPI mode successful
Executing device _INI methods:.................................................
49 Devices found: 49 _STA, 1 _INI
Completing Region and Field initialization:...........................
17/22 Regions, 10/10 Fields initialized (501 nodes total)
ACPI: Subsystem enabled
ACPI: System firmware supports S0 S1 S4 S5
Processor[0]: C0 C1 C2, 2 throttling states
ACPI: Power Button (FF) found
ACPI: Multiple power buttons detected, ignoring fixed-feature
ACPI: Power Button (CM) found
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled
Linux Tulip driver version 0.9.15-pre12 (Aug 9, 2002)
tulip0: no phy info, aborting mtable build
eth0: Macronix 98715 PMAC rev 37 at 0xd800, 00:80:AD:7F:9D:9D, IRQ 16.
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 439M
agpgart: unsupported bridge
agpgart: no supported devices found.
[drm] Initialized tdfx 1.0.0 20010216 on minor 0
Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 00:11.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt8235 (rev 00) IDE UDMA133 controller on pci00:11.1

    ide0: BM-DMA at 0xe800-0xe807, BIOS settings: hda:DMA, hdb:pio

hda: WDC WD102AA, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: attached ide-disk driver.
hda: host protected area => 1
hda: 20044080 sectors (10263 MB) w/2048KiB Cache, CHS=1247/255/63 Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 >
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 268k freed
Adding Swap: 128516k swap-space (priority -1)
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,2), internal journal kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,5), internal journal
EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,6), internal journal
EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,7), internal journal
EXT3-fs: mounted filesystem with ordered data mode. kjournald starting. Commit interval 5 seconds
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,8), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
ttyS0: LSR safety check engaged!
ttyS0: LSR safety check engaged!
ttyS1: LSR safety check engaged!
ttyS1: LSR safety check engaged!
ttyS0: LSR safety check engaged!
ttyS1: LSR safety check engaged!
Adding Swap: 127992k swap-space (priority -2)

I believe I have nailed the problem to the wall. Your talk about the bios misdetecting the cable got me to thinking - I hadn't actually been able to see what the bios said it was configuring the disks attached to since lilo's menu came up microseconds later.

I still haven't bothered checking, however I believe the bios is on a very unhealthy volume of crack. :)

using hdparm -i /dev/hda shows the disk wasn't configured to do any pio mode or udma/dma mode at boot time. Strange, right?

Stranger when you do hdparm -I on the disk again and it shows the disk is set to use udma4 - and the disk only understands up to udma2! - now add in the fact I currently have a 40 wire cable connected to the disk and my brain starts frying :)

At a suggestion of a friend, I set the disk to use mdma2 - via the line:

hdparm -Xmdma2 -d1 /dev/hda

It worked, for all of two seconds. Remember, this is a WD drive. WD drives, or at least mine, like to screw up in pretty amazing ways when you turn dma on initially. Mine throws a screenful of CRC errors, causing the kernel to reset the ide channel. Oddly, I noticed that dma was still on despite the fact the channel had been reset - so I checked with -I again, only to find out now the disk was told to use udma*3*! - this wasn't getting me anywhere. >D Anyway, the simple fix was to force it to keep settings across a reset by doing:

hdparm -Xmdma2 -k1 -d1 /dev/hda

- I am no longer getting any hda: lost interrupt messages, nor am I
getting any errors at all about the disk losing data or getting
confused. It's running slower than I'm used to, as I used to run it in
ata66 mode, but MUCH faster than it was a day ago. :) All I need to do now is migrate the information from this disk to one of my maxtors and I'm all set. Finally, I can start setting this machine up. Note, I could get this disk to use ata66 again if I switched cables to the 80 wire variant - but I plan on replacing this disk asap anyway.

So, to summarize: The BIOS in the Gigabyte GA-7VAXP motherboard (and likely all variants using the same bios) is getting confused and misdetecting both the cable's abilities and the hard disks abilities, causing linux to have a very nasty fit when you try using it without manually changing the settings using hdparm.

I have not tried, nor will I likely try, setting the PIO modes up with this motherboard as I don't need to. However, it is very likely that the same problem occurs with dma disabled as with dma enabled - you need to manually reconfigure the hard disk and disk controller using hdparm to the correct values, or it just basically gets all confused and whines.

Also note, I tested this setup after configuring with hdparm in three
ways: First, I did a test using hdparm -t -T /dev/hda - Passed. A little slow, but understandable considering. Second, I did a simple test doing find / - this almost always caused the thing to throw a hda: lost interrupt before at some point or another. Passed. Finally, I'm currently doing a kernel compile. As I said, a P1 133 was outpacing this machine before. This is a AMD XP 2600+ - it's absolutely ludicrous for a P1 to outpace this thing, unless some unsane overclocker ... no, I don't want to encourage anyone. :P Anyway, even with the slow settings, the kernel compile is going quite nicely, and is going much faster than the P1 could ever hope to do.

Note that the bios in this motherboard does not support turning OFF dma support - the only options are 'auto' 'ata33' and 'ata66/100/133' - all of which don't appear to actually work. For instance, I have the bios set to ata33 right now as I write this, and despite this, it was still trying to set the disk up to use udma4!

A buggy bios a happy linux user does not make. :)

Thank you for all your help, time and effort. It was greatly appreciated.

Tim McGrath

Not very strange. Some disks even cannot report it. And, any disk if set to PIO only may not report any mode as active, since that is only applicable to DMA modes.

If you use hdparm -I and the drive reports udma4, it can understand udma4, since hdparm -I is straight from the drive's mouth.

That's a problem I assume. If the drive can do udma3 and higher, the chipset can do udma3 and higher, and you have a 40-wire cable and some bad luck, the BIOS or the driver may misdetect the cable and try to operate the drive at, most likely, udma4. This won't work, of course.

Don't do this. If your drive supports udma, then there is no reason to use mwdma. Ever. mwdma is not crc-protected and that can lead to drive data corruption, namely in the case where you seem to have cabling problems.

If you have a 40-wire cable, udma2 will work just fine on it. If you want a slower speed, use udma1 or udma0, which is the same speed as mwdma2, but is CRC protected and thanks to the udma signalling also more robust.

CRC errors in mwdma mode? Weird. Those CRC errors must've come from the drive itself - them not being transfer CRC errors but surface CRC errors. That's mean the drive is dying and you should be getting them in PIO mode as well

Note that the asterisk stays even after the drive is used back in PIO mode. The way to check if DMA is being used is hdparm /dev/hd*

Vojtech Pavlik
SuSE Labs, SuSE CR

Hmm. Interesting, as the information shown with -i matches what the disk supports, and -I matches what the controller supports. maybe a bug in hdparm, or perhaps I was using it incorrectly. I'll investigate.

again that's interesting as -i shows the max the disk can do is udma2 - and in fact, that *is* the max.

hrm. The BIOS detects I have a 40 wire cable, however tells the chipset
that I have an 80 wire cable. (Confirmed by checking /proc/ide/via) So, things are pretty f'd up in the BIOS, and I can't figure out why it's doing this. Not that it really matters now that I can get it to work *anyway* - but.

I was totally unaware of this. Thanks for the information!

OK, I wasn't aware udma2 worked on this type of cable, and was planning on switching back to the other 80 wire cable before I continued. Thanks.

I know a little more about this than you having dealt with this buggy drive for more than two years. Basically wd drives don't deal well with DMA as their hardware doesn't follow the spec - specifically, something in the crc handling is f'd up, so occasionally the drive will report a crc error that doesn't actually exist. And it will continue reporting crc errors infinitely until the ide channel and all devices on it are reset - which can be maddening at times when I'm playing quake, something tries to load a file and for two seconds my computer is frozen. Luckily due to the kernel's error handling, it can deal with this, and life goes on. I've never lost any data due to this hardware bug, it's just annoying. If you're in the market for a hard disk, I'd avoid Western Digital hard disks for this very reason - they're cheap for a reason. :)

The whole crc errors filling the screen thing - that's actually NORMAL for this disk when you initially turn dma on. It used to happen on the old system, so I was actually glad to see it happening again, because it meant things were working. The error messages weren't showing up in udma4 mode, and in fact it was acting as if dma was totally turned off... I guess because the disk doesn't understand udma4 at all.

Yes, I did that, which is why I noticed dma was still enabled to my astonishment. Rather than get my hopes up, I checked what the drive was set to with -i, and nothing showed up - so I checked with -I and my eyebrow started twitching because it had neither stayed at the setting I'd set nor gone back to the setting it was at before.

I've never set up a hard disk with PIO modes before, so I'd like to hear any advice you have on that - currently whatever setup the hard disk is trying to use with dma off is malfunctioning in a grand manner, and I'd like to have a failsafe in case for whatever reason the hard disk throws the gauntlet down and refuses to do dma in the future for whatever reason.

Mostly, I want to know if what is listed by a -i/-I is assumed 'safe' to use. Certaintly I'm expecting you to say 'no, backup your data first before experimenting' so, you need not surprise me. However, any other advice you have would certaintly be appreciated. Also, I have a 486 with dma capable hard disks that has a non dma capable disk controller, so if I can get PIO modes working on it's hard disks it might speed things up slightly, who knows.

Thanks for your comments,
Timothy C. McGrath

Well, send me the output of your dmesg (only the IDE parts), /proc/ide/via, hdparm /dev/hd*, hdparm -i /dev/hd* and I'll write a commentary on what means what and what's the maximum speed the thing is expected to operate at.

Vojtech Pavlik
SuSE Labs, SuSE CR

Will do this tomorrow, need to sleep now. Thanks for the help :)

Timothy C. McGrath

Alright, minor update. I was messing around tonight not really expecting to get anywhere, and to my horror, saw a 'hda: lost interrupt' message. Again. So. Off I go, trying to figure out what is going on and what do I find out? You sir were totally right. even with the -k1 setting, the wd drive changes it's settings back to whatever it wants when it throws the crc errors. Which incidentally appears to be settings it shouldn't be capable of supporting, but... whatever. Anyway. A friend of mine (who I'm very grateful for putting up with me) helped me screw around with PIO modes, and we managed to get the disk working with dma off and PIO mode 4 enabled.

What was likely fooling me into thinking the drive was working properly is the enormous amount of ram my computer has now - I tend to forget that with almost 512MB free of ram, my disk cache can be absolutely enormous. Which of course means I can easily get fooled into thinking a disk operation is working perfectly fine when in fact the disk isn't even being touched at all.

it looks like I was very lucky with my original motherboard and that the wd drive was able to communicate at it's stock settings without having any special setup - otherwise, this entire assumption would never have happened - the disk worked perfectly fine with dma on my previous motherboard, which is why I was so surprised things broke so damn fast now.

So, the Gigabyte motherboard I'm using is still missetting the values for the hard disks - but on the other hand, my hard disk was also playing foul games.

I tested right after doing a reboot with the PIO4 settings, and it appears to be working just fine. My test consisted of a hdparm -t -T /dev/hda and also a tar c / > /dev/null for completeness. No problems.

I'll have more detailed information on my setup for you to look at fairly soon.

After I get the data moved off of it, I plan on sticking this WD drive into my 486, where it will happily work without any dma support at all. And it can stay there, for all I care. :)

Timothy C. McGrath

To my astonishment, everything is working now that I've had time to sort out all the problems.

What I had to do: First off, the WD drive was causing a lot of strange problems all by itself. Removing it from my computer made everything work a lot better - both maxtors have their DMA modes correctly detected and turned on at boot time, although I still manually prefer to turn them on and do small amounts of tuning myself using hdparm once the kernel starts.

Weird problems I've noticed include that the kernel and motherboard disagree with the CHS attributes of my larger disk, a 120GB maxtor 7200 rpm drive. I'm pretty sure the kernel is right, mostly because using the CHS settings the motherboard insists on cause braindamage in DOS, including but not limited to the partition table being misdetected, the files on the disk I copied there from linux to dos going missing, 6mb of 'bad sectors' when I try formatting the partition (Which goes away when I enter linux.) and when linux fscks the disk, it can find DOS's files and believes the disk has enormous filesystem corruption. Oddly enough, the 40GB maxtor hard disk I have (That incidentally originally came with the ps2 linux kit) is correctly detected.

I haven't yet tried fiddling with the motherboard's settings for the first hard disk - everything is still on auto, but I'm pretty sure there is nothing I can do to manually set the CHS, which will be a problem if I want to boot dos correctly. :( I've checked with maxtor's site, but their maxblast program only works in windows according to it, which is a pity since I don't have that installed here. I'll likely be forced to use dosemu, although right now I can neither get sound nor VGA/SVGA to work in it. *shrugs* I'm sure given enough time I can nail this too, although I'd love suggestions. ... Hmm, just had a thought. Worst case, I can make the 40GB disk have a dos partition and tell lilo to swap the disk appearance for dos when I want to run dos. ... I might go with that, actually.

Things that I've tried and haven't worked, include manually setting the CHS in lilo's append command - obviously this only works for the linux kernel. I've tried using grub as well, and it fixes the braindamage by itself - problem is according to what little I've read of grub's documentation there is no way to boot dos using it that I can see. If I'm wrong, please inform me where the documentation for doing it is located?

So. Problems with the Gigabyte GA-7VAXP motherboard I've found with linux and it's F11 variant of the bios include:

Western Digital drives go absofuckinglutely insane in linux, which actually isn't abnormal from what I've read - seems to be an issue more with the disk being insane in the first place, and telling the BIOS it can do things it not only can't do, but won't do, nor will the disk complain when you try to do them. If you have one of these disks, the only thing I can really say to you is to force dma OFF and experiment with PIO mode. Mode 4 worked on my hard disk, but yours might be different from mine, keep this in mind. Also note PIO mode is *slow* - unbelievably slow compared to DMA. If you are stuck with one of these disks, if you can return it and get your money back - do it. Otherwise, you might consider getting a different manufacturers hard disk - from what I've read using google.com about western digital disks and linux, they just plain don't work with dma in linux, and the company seems to have no plans on fixing this problem.

Large hard disks have their CHS values incorrectly detected.

Not including this, I've noted that the onboard fan that came with the board which cools the agp chipset (at least I think it does - has a 'AGP 8x' sticker on it) is starting to wear out. I'm sure I can find a replacement for it at radio shack, but I think it's a little silly for it to be wearing out already.

I can't really recommend this board to other people, especially as I haven't even tried enabling the other hard disk controller (which uses a promise bios and can do ATA/RAID) and the problems I've had with this motherboard were really absurd at some points. Also one of the things you WON'T see on websites trying to sell you this board is that the bios doesn't let you change important things - like memory timings, wether or not dma should be totally turned OFF to hard disks, among other things. I've not investigated yet, but I have a feeling I'm not going to be able to manually set the CHS either, which would be a pity. None of these things really makes a difference in linux, but on the other hand it makes it a lot easier to track down problems if you can force the bios to do the hard work for you when you're trying to figure out what's wrong with the machine. Trying to fix problems on this motherboard makes me feel half the time like I've got a hand tied behind my back. Another thing is that the manual tends to be in engrish, so it's a little hard to read at times. I won't be buying a gigabyte motherboard next time - they're nice and slick, have pretty pictures, have a easy to use bios, so long as you don't do things it doesn't understand, but although I like having an 'autodetect' mode, I also like being able to manually set the bios to do things. I had and still have this same type of problem with my IBM PS/1 2155-78C(SL-B) which was built almost ten years ago - it's silly to see people still building motherboards that don't have the ability for the user to set settings manually.

Timothy C. McGrath

Well, I just rebooted and checked - I can, in fact, set the CHS settings. However, not to the settings I need. ... Which explains nicely why my bios can't figure out what to do with my disk. Ah well, I tried.

Anyone with suggestions on how to get DOS booting and happy would be appreciated.

Tim McGrath

Maybe you can use dosemu under Linux instead?
http://www.dosemu.org

There is also GPLed DOS replacement, maybe it doesn't use CHS info, if it does you have source code available ;-).
http://www.freedos.org

--
Bartlomiej

Well, yes, it works - problem is I can't figure out how to get sound nor VGA/SVGA working in it, and I need both to play the games I use DOS for.

Nope, not even going to try that one - I've used it before and the last time I tried it, it had the same problems dos did. Not that it's a bad program or anything.

Thanks for trying to help. If you know how to get dosemu working with vga/svga and sound in linux console/x let me know.

Another option I'm going to try is booting off the 40GB disk I have instead of the 100GB disk - should work as the CHS info given by the bios agrees with the kernel.

We'll see.

Timothy C. McGrath

Put your Boot Sequence on "Floppy --> Anything else" and format a floppy with just plain DOS. :-)

Works for me every time.

Regards
Henning

Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
[email protected]        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire