On Wed, Oct 20, 1999 at 07:40:36AM -0600, Axalon Bloodstone wrote:
> On Wed, 20 Oct 1999 [EMAIL PROTECTED] wrote:
>
> > > > 1) By default, Mandrake attempts to turn on DMA for available IDE devices.
> > > > Attempting to copy the contents of a CDROM to my hard drive, I encountered
> > > > the following errors:
> > >
> > > Um, no 6.1 shiped without the ide patch
> >
> > What does that mean?? My boot logs show "DMA" turned on for the hard drive
> > and CDROM. /etc/rc.d/init.d/mandrake_everytime DOES seem to affect whether
> > DMA is turned on at the end of the boot.
>
> It means that it didn't ship with DMA on by default.. (plz take note i
> didn't personaly package the kernel, but i did just double check)
> "
> kernel-2.2-i586.config:# CONFIG_IDEDMA_AUTO is not set
> "
> so the kernel is not the culpret.
>
> verifying /etc/rc.d/init.d/mandrake_everytime, is not so hard to test.
> comment out the actual "hdparm -q -d1 blah blah" and replace it with a
> touch /axalon.sux
>
> (for the extra paranoid it checks also for "nohdparm", opti will do other
> things also further along)
>
> 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.
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.
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
> > > > 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?
> (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?
> 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.
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.
--
Steve Philp
Network Administrator
Advance Packaging Corporation
[EMAIL PROTECTED]
