no, i'm not taking it as an insult, but yes, they are shorter than 18".
i dont have any cables that long, but i wouldnt expect them to work at
all at ata100 if they were that long....(hence why i figured saying that
it works in the other OSs was also saying the cables were shorter than 18")
>>3) its not the ram, i checked it
this motherboard is an upgrade. the old motherboard/ram/processor
worked fine in all the linux's, as well as freebsd and beos. i put that
ram in there (pc133), and i still get dma errors. i also tried my
roommate's ddr ram (he used to use linux with it), and still the dma errors.
>>4) its not the harddrive, cdroms - they worked fine in linux before i
>>upgraded the mobo
yeah. in fact, they were never unplugged (except for obviously from the
motherboard) until i was testing the cables.
>>8) seems to be having real dma issues. BeOS doesnt use DMA, and i'm
>>pretty sure that FreeBSD wasnt either (because it wasnt familiar with
>>the chipset, so was just going thru the bios)
>what mode does it come up in? do you do some hdparm tweaking?
>anything in /proc/ide?
well, when freebsd boots it says a few lines about "Drive C: bios" or
something like that. i'm not really very familiar with it. but no, i
didnt use any special settings. its not exactly easy, but i can
probably get you the first few lines of dmesg if you think it'll help
>>9) *new* - the machine is not overheating, the hottest spot is at a cool
>57C is hardly cool, though it shouldn't cause problems.
last i saw, amd rates these chips at 95C, so 57 is downright chilly :)
>>now i'm not sure where the problem is, but it seems pretty clearly to me
>>that it is dma-related. neither BeOS or FreeBSD is trying to use dma,
>>and they work. i'm pretty sure windows is using dma, but its using the
>>drivers that came with the mobo. linux is trying to use dma using
>>drivers not written by ECS, and it doesnt work.
>udma or even mdma? if mdma, does hdparm -m settings effect it?
i'm not sure how to check, and i have a very difficult time even getting
to a shell in linux, because the damn thing keeps dma erroring about
reading the cd's. is there some boot-up settings i can feed it so it
wont try using dma at all?
>>or that there's some minor timing quirk (like a
>>race condition) in the linux driver that my computer just likes to hit?
>unlikley. in part because the sis driver, like most others,
>doesn't do much itself, since the interesting/subtle parts of
>doing ide are all done in generic code.
>but why do you mention timing? sure, the sis driver is hardly the most
>well tested (widely used) driver, so perhaps it fiddles a reg that
>needs a microsecond of "rest" afterwards.
i just mentioned timing, because in my (somewhat limited) experience
writing drivers, timing booboos tend to be the cause of lots of problems
(especially when timeouts are involved)
>>at this point, i'm tending to think that there's several versions of
>>sis735 floating around (similar to the maneuver that ensoniq pulled with
>>their sound cards) -- possibly even within the revisions of the k7s5a
>lspci /proc/pci will give you the revisions of the chipset components.
again, cant easily get to a command prompt in linux, making things like
this very difficult :)
i think the best thing is to try and find a startup parameter to prevent
it from using dma, and see if that works. anyone know how? :)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/