Subject: kern/13428: pciide (i386/1.5.1) ignores config file flags on sd at atapibus
To: None <gnats-bugs@gnats.netbsd.org>
From: None <John.P.Darrow@wheaton.edu>
List: netbsd-bugs
Date: 07/10/2001 20:23:28
>Number:         13428
>Category:       kern
>Synopsis:       pciide (i386/1.5.1) ignores config file flags on atapi sd
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jul 10 18:21:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     John Darrow
>Release:        NetBSD-1.5.1 (20010704)
>Organization:
Computing Services, Wheaton College, Wheaton, IL
>Environment:
NetBSD jdarrowpiii.wheaton.edu 1.5.1 NetBSD 1.5.1 (JDARROW-pio0) #0: Tue Jul 10 17:04:08 CDT 2001     jdarrow@jdarrowpiii.wheaton.edu:/var/src/sys/arch/i386/compile/JDARROW-pio0 i386

>Description:
Background: I recently switched machines, and moved my atapi zip drive
from the old machine to the new one.  Once there, I was unable to mount
dos-formatted zip disks - they all had an unused h partition which
extended beyond the disk size in the (faked) disklabel, instead of the
MSDOS-type partition I had expected.  (I later found that this was
due to a HD-vs-floppy setting in the bios for the zip drive, which
didn't even show up as an option until I changed the bios from auto-
detecting the drive to manually setting it as a zip.)

While troubleshooting the above problem, one of the things I tried was
to hardcode the access mode settings for the drive.  A normal (flags
0000) kernel detected PIO mode 3, while the "Auto" in the bios seemed
to claim to detect only PIO 0, so I tried compiling a kernel with the
following lines:

sd7	at atapibus? drive ? flags 0x0ff8	# ATAPI disk drives
sd*	at atapibus? drive ? flags 0x0ff8	# ATAPI disk drives

According to the notes in the config file, this should force PIO mode
0, with DMA and Ultra DMA disabled.

However, I was surprised to see during boot:

pcib0 at pci0 dev 4 function 0
pcib0: Intel 82371AB PCI-to-ISA Bridge (PIIX4) (rev. 0x02)
pciide0 at pci0 dev 4 function 1: Intel 82371AB IDE controller (PIIX4) (rev. 0x01)
[...]
pciide0: secondary channel wired to compatibility mode
atapibus0 at pciide0 channel 1
sd7 at atapibus0 drive 0: <IOMEGA  ZIP 100       ATAPI       Flopp, , 13.A> type 0 direct removable
sd7: 98288 KB, 96 cyl, 64 head, 32 sec, 512 bytes/sect x 196576 sectors
sd7: 32-bit data port
[...]
sd7(pciide0:1:0): using PIO mode 3

Later boots, still with the same kernel, but with the zip set to Hard
Drive mode in the bios, showed the following:

sd7 at atapibus0 drive 0: <IOMEGA  ZIP 100       ATAPI, , 13.A> type 0 direct removable
sd7: 98304 KB, 96 cyl, 64 head, 32 sec, 512 bytes/sect x 196608 sectors
sd7: 32-bit data port
sd7(pciide0:1:0): using PIO mode 3

Either way, the flags line _should_ have forced PIO mode 0 only.

I did a diff of the compile dirs of a kernel with the flags vs. one
without, and it did show a difference in ioconf.c and the resulting
ioconf.o and netbsd files, corresponding to the presence of 0x0ff8 in
the locator.  However, the flag seems to be ignored during device
configuration on bootup.

>How-To-Repeat:
Put 'flags 0x0ff8' in your kernel config.  config && make depend && make
&& make install && reboot.  See "PIO mode 3".

>Fix:
Unknown.  While the bios let me fix the zip mounting problem, this new
machine also has problems with the cdrom drive (audio channels are
reversed, or at least the volume controls for them (no, it's not just
the audio cable, the front panel headphone jack is affected the same
way) and the track length does not feed through correctly to xmcd,
besides claiming Ultra-DMA support which it then has to downgrade) and
so I might end up swapping hardware again anyway.  *sigh*
>Release-Note:
>Audit-Trail:
>Unformatted: