On Wed, 20 Oct 1999 [EMAIL PROTECTED] wrote:
> > I am curious as to what MB and HD controler your useing.
>
> I'm using a Asus BP6 board with their onboard PIIX4. I am not using the
> Ultra66 interface for any of the devices. I have stocked the machine with 2
> Celeron 400's (not overclocked), 128M of RAM, and linux-compatible hardware.
Same board, same senerio, i can't get the first drive out of DMA mode
either
> Here's what /proc/pci says about the IDE interface:
>
> IDE interface: Intel 82371AB PIIX4 IDE (rev 1).
> Medium devsel. Fast back-to-back capable. Master Capable. Latency=32.
> I/O at 0xf000 [0xf001].
> Bus 0, device 7, function 2:
>
> The drives are a Quantum Bigfoot 6.4G hard drive and a Ricoh MP7040A CDRW.
>
> I have verified that the mandrake_everytime script does not affect the
> issue one way or the other. It must have been fsck-rage that made me think
> it did. One gets a little testy after three fsck's (including one that
> dropped me to the root prompt) within a 10 minute period.
Oh yeah also it's pretty apparent when it is in use, it prints one of
those "loading blah blah [ok]" messages (and i'm just now
remebering :) )
> I reset the BIOS to show UltraDMA being activated "Auto" and booted the
> machine. DMA was on for both the hard drive (/dev/hda) and the cdrom
> (/dev/hdd). The hard lockup occurred while copying from CDROM->HD.
>
> I rebooted the machine and reset the BIOS to "disable" UltraDMA for both
> interfaces and started Linux. The error messages still appear in
> /var/log/messages when attempting to copy from CDROM->HD. dmesg shows the
> following:
>
> hda: QUANTUM BIGFOOT_CY6480A, 6204MB w/67kB Cache, CHS=13446/15/63, DMA
> hdd: ATAPI 20X CD-ROM CD-R/RW drive, 2048kB Cache, DMA
>
> So, the kernel believes that the drives are still DMA-capable at boottime
> despite the BIOS switch.
>
> hdparm reports:
>
> /dev/hda:
> multcount = 0 (off)
> I/O support = 0 (default 16-bit)
> unmaskirq = 0 (off)
> using_dma = 1 (on)
> keepsettings = 0 (off)
> nowerr = 0 (off)
> readonly = 0 (off)
> readahead = 8 (on)
> geometry = 13446/15/63, sectors = 12706470, start = 0
>
> which seems to verify that somewhere along the way, DMA got enabled on the
> drives. /usr/doc/Documentation/Configure.help says that DMA is disabled by
> default unless the CONFIG_BLK_IDEDMA_AUTO is turned on. I have verifed that
> the option is not enabled in the default kernel-2.2-i586-smp.config (got
> more errors while installing the source package, good thing the machine
> didn't lock up).
>
> Here are the relevant installed kernel packages:
>
> kernel-2.2.13-4mdk
> kernel-headers-2.2.13-4mdk
> kernel-pcmcia-cs-2.2.13-4mdk
> kernel-smp-2.2.13-4mdk
> kernel-source-2.2.13-4mdk
I'm not sure howlong till the next ide patch is out for 2.2.13 hopefully
it'll fix this. also which error are you getting again 'hdX: lost
interupt' or the DMA timeout
> > > > > 2) Inability to compile a kernel. Attempting a 'make menuconfig' yields:
> > > > >
> > > > The cflags get put there by rpm, (there was a non fuctional %post to check
> > > > gcc --version for 2.95+, actualy it functions but only if gcc is
> > > > installed at the time) Have a gander at the src.rpm
> > >
> > > Fine, so how did it end up in the distribution if the only gcc package you
> > > ship is gcc-fr? How did it NOT get caught during testing? Surely SOMEONE
> > > must have tried to build a kernel! It's not like it's slightly broke, it
> > > just plain doesn't work. Blatantly!
> >
> > pgcc, gcc, and egcs, all provide a link gcc. this is whats being tested,
> > not specificly what compiler package is installed.
>
> Certainly a 'gcc --version' would have made more sense rather than the
> simple existence of a file that's going to exist no matter what, wouldn't
> you agree?
Well actualy thats exactly what it does, problem is it doesn't test if gcc
is there first, and its probably arse backwards I'd expect it to add the
flag if needed not remove it.
> > (again not my package, but) kernel is one of the exceptions that is not
> > compiled with pgcc, think it was egcs (chmouel,bero ?). I remeber it was
> > something to do with io ports
>
> So in order to compile the kernel, what package do I need? Why wasn't that
> package included in the distribution? Did you expect people NOT to compile
> their own kernels?
It's not like this is all that new of a problem (pgcc produceing flaky
code).
use egcs if you want exactly like was distributed
use pgcc if you don't care if the parallel ports work (could be other
problems also i quit testing at that point)
use gcc if your useing kernel-source from cooker, and want the fastest
posible code
> > Seems it will happen only on a clean install
> > also doesn't seem the gcc check was ever applyed to the cooker .spec
>
> Considering that Mandrake has been pretty vocal about "install don't
> upgrade", one would expect that someone at Mandrake had actually tried USING
> the resulting system.
I was useing it 18 hours a day for several weeks, i still (personaly)
stand by "just cause it works here, doesn't mean it will there"
> It's time for Mandrake to realize that those of us who buy our distributions
> expect a bit more than we would if it were handed to us free. We expect
> that our money will ensure that things are tested, packaged, and ready to use.
> If that is an unreasonable thing for me to expect from Mandrake, I'll gladly
> take my money elsewhere.
I'd like to point out that up untill not all that long ago there were but
a handfull of us. (some volunteers even)
I'd tend to hope it kept our hackers from starveing, but ok I'll give you
that one. Let me reassure you we are working to get to the testing on
the level with the corporate big boys.
Steve,
If you expected no bumps when we went from Redhat(c)+, to Redhat(c)
compatible, I really don't know what to tell you. It is going to be bumpy,
but no one will get bruised, promise..
--
MandrakeSoft http://www.mandrakesoft.com/
--Axalon
